RE: IESG comments on generalize MPLS documents

["Wijnen, Bert (Bert)" <[e-mail]>]

Thank you... some comments inline

> -----Original Message-----
> From: Lou Berger [mailto:[e-mail]]
> 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