[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
RE: IESG comments on generalize MPLS documents
Thank you... some comments inline
> -----Original Message-----
> From: Lou Berger [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.
> >
> >general issues, for all 3 documents:
> >
> >1. All 3 documents still have some 15 or so people on the front
> > page. I have pushed back on this several times, in the end
> > I did go along (against my knowing better) and issued IETF
> > Last Call and put them on the IESG agenda. But I had warned
> > that you would most probably get push back from IESG again.
> > You now have a firm (IESG) rejection.
> >
> > The docs will not be considered again unless you comply
> > with the guidelines in section "Author overload" in
> >
> ><http://www.rfc-editor.org/policy.html>http://www.rfc-editor.
> org/policy.html
>
> all but editor(s) removed from front page, also reformatted to match
> draft-rfc-editor-rfc2223bis-02.txt.
>
> >2. The titles/abstracts have too many acronyms that have not
> > been expaned/explained. See also the "Choosing titles" and
> > "abstract" sections in
> >
> ><http://www.rfc-editor.org/policy.html>http://www.rfc-editor.
> org/policy.html
> > I believe that the RFC-Editor wants these acronyms expanded:
> > SONET/SDH, ADM, CR-LDP, RSVP, RSVP-TE
>
> Done.
>
> >3. We need an IPR section according to RFC2026, sect 10.4
> > probably statements (A) and (B).
> >(
>
> Added.
>
> >4. I found that in some documents you use SONET/SDH while
> > in others you use SDH/SONET and yet in other you use
> > bother forms. Is there maybe one "best form" and if so
> > can we stick to that. I just bring this up since you
> > need to go through an editing cycle anyway.
>
> SONET/SDH is now used. One location was changed.
>
> >Comments per document:
> >
> ><draft-ietf-mpls-generalized-signaling-08.txt>
> >
> >1. References must be split in normative and informative
> > I had mentioned this before!
>
> Done.
>
> >2. IANA considerations is insufficient. I had mentioned this before!
> > You must specify:
> > - which namespace(s) you want the IANA to start administering
> > - the rules/guidelines to be used when IANA must make
> > new assignments/registrations in such namespace(s)
> > (this probably will result in a reference to RFC2434)
> > - you must list which assignments IANA needs to register right
> > away from the start (as specified in this document). That is,
> > do not make it an IANA task to try to figure out which pieces
> > make up which namespace and which exact assignments need to
> > be made.
>
> done.
>
>
> >3. You are using MUST and SHOULD language and such.
> > Seems you need to add something about that in the intro
> > and add a reference to RFC2119 (as you also do in the
> > other 2 documents)
>
> done.
>
> >4. last para of sect 1, you use [LDP, CR-LDP, RSVP-TE] as
> > a reference, but those are not listed in ref section.
> > although some of them are listed as [RFCxxxx] in the ref
> > section. May want to get that in sync.
>
> done.
>
> >5. From section 3.1.1 (last para) I get the impressing that
> > [GMPLS-RTG] is a normative reference. What is the status
> > of that document?
>
> The reference was broken (no values in document GMPLS-RTG).
> Values are now explicitly listed.
>
> >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
> >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.
> >8. sect 3.2.1 and sect 6.1
> > would it make sense to change
> > Label: Variable
> > into something like
> > Label: Variable number of bit
> > or
> > Label: variable length
>
> sure, why not...
>
> >9. Sect 9.1 1st sentence
> > s/there as an/there is an/
>
> thanks.
>
> >10. Sect 9.2 2nd sentence
> > s/failure the limits/failure that limits/
>
> thanks.
>
> >12. LSP is not defined before use.
>
> Fixed.
>
> >
> >
> >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
> >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
>
> >15. In the ref section you have:
> > [RECOVERY] Sharma, et al "A Framework for MPLS-based Recovery,"
> > draft-ieft-mpls-recovery-frmwrk-02.txt, March, 2001
> > But it is never referenced!
>
> dropped!
>
> ><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) 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
>
> okay.
>
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
> >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.
> >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.
> >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.
>
> >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.
> > Although in sect 2.1.2 you talk about "Int-serv objects"
> > Here you may want to add a reference to the doc that
> > describes the "Peak Data Rate field of the Int-serv objects"
>
> sure...
>
> >6. Why does LDP need to be mentioned in this doc at all?
>
> removed.
>
> >Bert
>
Thanks,
Bert