[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
RE: IESG comments on generalize MPLS documents
responses below...
Lou
At 05:15 PM 8/26/2002, Wijnen, Bert (Bert) wrote:
Thank you... some comments inline
> -----Original Message-----
> From: Lou Berger [<mailto:lberger@movaz.com>mailto:lberger@movaz.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
>
>
> Bert,
> 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.
>
> Lou
>
> 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:
> >
> ><draft-ietf-mpls-generalized-signaling-08.txt>
> >
[...]
>
> >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
component links.
> >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.
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?
[...]
> >
> >
> >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?
> >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
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
be included.
[...]
>
> ><draft-ietf-mpls-generalized-cr-ldp-06.txt>
> >
> >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
>
(<http://www.iana.org/assignments/ldp-namespaces>http://www.iana.org/assignments/ldp-namespaces)
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.
My understanding is that URLs are discouraged in RFCs, but if that's what
the IESG want's...
> >2. [RFC2119] reference is used, but it is not listed in Ref section
>
> okay.
>
Means that you have added it I assume ;-)
yes.
> >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.
> ><draft-ietf-mpls-generalized-rsvp-te-07.txt>
> >
> >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.
thanks.
> >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]
>
> yes.
I assume you meaning you updated it.
yes.
>
> >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.
>
> yes.
>
Still I wonder if some words are needed... or might make that clearer
for the novice reader.
given that the whole document is in the context of RSVP, I'm not sure what
more makes sense...
[...]
Lou