[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
RE: IESG comments on generalize MPLS documents
At 05:15 PM 8/26/2002, Wijnen, Bert (Bert) wrote:
Thank you... some comments inline
> -----Original Message-----
> From: Lou Berger [<mailto:firstname.lastname@example.org>mailto:email@example.com]
> Sent: maandag 26 augustus 2002 21:50
> To: Wijnen, Bert (Bert)
> Cc: Ccamp-wg (E-mail)
> Subject: Re: IESG comments on generalize MPLS documents
> A preview of the updates has been distributed to the
> co-contributors. I'll submit the updates on Wednesday AM. Detailed
> responses are in-line below.
> At 11:35 AM 8/12/2002, Wijnen, Bert (Bert) wrote:
> >The IESG did review/discuss these documents recently:
> >o Generalized MPLS - Signaling Functional Description
> > <draft-ietf-mpls-generalized-signaling-08.txt>
> >o Generalized MPLS Signaling - CR-LDP Extensions'
> > <draft-ietf-mpls-generalized-cr-ldp-06.txt>
> >o Generalized MPLS Signaling - RSVP-TE Extensions
> > <draft-ietf-mpls-generalized-rsvp-te-07.txt>
> >As a result I as the responsible AD must hand them back
> >to the editors/authors/wg. Here are the issues/concerns.
> >Comments per document:
> >6. From section 9.1.1 towards the end, I get the impression
> > that [MPLS-UNNUM] is normative too? Status?
> one reference has been removed, the other is still there. I think
> informative is accurate for the new text.
Will check when I see the text
IP Address: 32 bits
The IP address field may carry either an IP address of a
link, or an IP address associated with the router ID,
where router ID may be the value carried in the router ID
TLV of routing.
Interface ID: 32 bits
For type 3 usage, the Interface ID carries an interface
identifier, see [MPLS-UNNUM].
For types 4 and 5, the Interface ID indicates a bundled
component link. The special value 0xFFFFFFFF can be used
to indicate the same label is to be valid across all
If this is a "less serious" comment, then I can use my judgement as
editor. (which I've done.) If this an IESG requirement then I'll make
whatever change is required. Is there a required change from the IESG here?
> >some less serious, but now that you are at it anyway...
> >7. Intro lists 4 types of interfaces (PSC, TDM, LSC, PSC)
> > Architecture doc (still and I-D) lists L2SC as well.
> > Would it not be better if they are in sync?
> L2SC is really a sub/special-case of PSC. Other documents also don't
> explicitly call it out.
The Architecture doc DOES spell it out.
When I read "Architecture" then I always think it is gudining any other
documents in that space.
> >13. the document could have been 5 pages shorter if it had not
> > bothered to explain how it is different from "old" MPLS,
> > and just concentrated on what it was doing.
> > I guess a ptr to the old MPLS doc would have been sufficient?
> I think we should just keep this as is.
So you are asking me to defend that in the IESG.
Not sure how successfull I will be. Up to you to take the risk
same comment. Is there a required change from the IESG here?
I'm happy to do this. I went to add more text and found the text that I
was going to add was already present. Please propose some text and it'll
> >14. Cannot implement section 9 (interface identification) - the
> > info on which end's interfaces are being talked about, and
> > how one end identifies which of its interfaces match
> > corresponding interfaces at the other end simply doesn't
> > seem to be there.
> > (generalized-rsvp-te specifies that the downstream interface
> > is sent in a PATH message.....this is a matchup, but not sure
> > which way it matches).
> The whole document can only be implemented when combined with
> one of the protocol specific documents. I think the 21 responses
> to the implementation survey speaks for itself. (Also, this
> document does clearly states: "In all cases the choice of the data
> interface is indicated by the upstream node using addresses and
> identifiers used by the upstream node.")
So maybe adding a note to it to explain that might alleviate the
concern. Of course I can try to defend based on the 21 responses,
that is indeed a strong point. But often adding a one or wto line
explanation helps to fuse the push back
My understanding is that URLs are discouraged in RFCs, but if that's what
the IESG want's...
> >1. IANA asks:
> > Seems OK but which registry should these assignments
> > be going in.
> > So please specify.
> Took me a second to figure out what was needed here, the
> reference was
> broken (said 3031 not 3036.) With a proper reference, the registry
should be clear.
I would strongly recommend to also add that web ptr. It will Help
IANA a lot, and it will just smooth the further processing of the
document. It also helps later readers to quickly find the place
where values are registered.
> >2. [RFC2119] reference is used, but it is not listed in Ref section
Means that you have added it I assume ;-)
> >3. you have a ref to [MPLS-TE] but it is not listed
> > in ref section.
> broken reference removed, and text fixed.
> >4. IANA Considerations starts with:
> > This draft uses the LDP [RFC 3031] name spaces, which require
> > assignment for the following TLVs.
> > Do you mean to reference 3036 instead of 3031?
> yes. same issue as comment 1.
same as above. pls add the web ptr to the registry
sure, it's the same sentence (do you want it twice?)
> >5. Since LDP spec (RFC3036) has statement D of sect 10 of rfc2026
> > in its IPR section, maybe that applies to this spec too?
> I'm not aware of such claims with respect to this draft so I
> cannot make this statement. Has the IESG been notified of
> such a claim?
I was just asking if you are aware. I am not aware of it. I would
think that you as authors might know better than I cause you work
daily in this space.
> >1. This doc says "just use IPsec". A clearer statement is needed,
> > specifying the necessary IPsec selectors (per RFC 2401) and the
> > way the cryptographically protected endpoints are related to
> > the authorization model, i.e., who can do what.
> can you provide an example of what you'd like to see?
I am checking with Security ADs.
> >2. I wonder if Sect 5 actually tells us that this doc is "updating
> > RFC3209" cause you are "revising" the definitions.
> now says "...is being extended..."
Well, that is nice playing with words. I think you understand my
real question. But... since it gets registered by IANA (if I
understand it correctly) I guess this is OK, cause IANA will
register the RFC in the registry so that people can find this.
Actually, I'm not sure what your point was...
> >3. Section 4.3 has ref to [RSVP]. That is not in ref section.,
> > I guess you mean [RFC2205]
I assume you meaning you updated it.
given that the whole document is in the context of RSVP, I'm not sure what
more makes sense...
> >4. In sect 8.1.2 you have a ref to [MPLS-TE] but it is not listed
> > in ref section.
> removed and text updated. (was a broken reference)
> >less serious but since you are at it anyway...
> >5. Once you start reading section 2. how do you know that these
> > are "RSVP objects" ?? I guess it is implicit.
Still I wonder if some words are needed... or might make that clearer
for the novice reader.