Re: IESG comments on generalize MPLS documents

[Zhi-Wei Lin <[e-mail]>]

Hi all,

Seems that most comments are editorial in nature. I like to get some 
inputs from the GMPLS doc's editor/authors as to when these 
modifications can be made and submitted? Some time frame would be 
greatly appreciated!

Thanks
Zhi


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
>
>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
>   I believe that the RFC-Editor wants these acronyms expanded:
>     SONET/SDH, ADM, CR-LDP, RSVP, RSVP-TE
>
>3. We need an IPR section according to RFC2026, sect 10.4
>   probably statements (A) and (B).
>
>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.
>
>Comments per document:
>
><draft-ietf-mpls-generalized-signaling-08.txt>
>
>1. References must be split in normative and informative
>   I had mentioned this before!
>
>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.
>
>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)
>
>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.
>
>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?
>
>6. From section 9.1.1 towards the end, I get the impression
>   that [MPLS-UNNUM] is normative too? Status?
>
>
>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?
>
>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
>
>9. Sect 9.1 1st sentence
>   s/there as an/there is an/
>
>10. Sect 9.2 2nd sentence
>    s/failure the limits/failure that limits/
>
>12. LSP is not defined before use.
>
>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?
>
>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).
>
>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!
>
><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.
>
>2. [RFC2119] reference is used, but it is not listed in Ref section
>
>3. you have a ref to [MPLS-TE] but it is not listed
>   in ref section.
>
>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?
>  
>5. Since LDP spec (RFC3036) has statement D of sect 10 of rfc2026
>   in its IPR section, maybe that applies to this spec too?
>
><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.
>
>2. I wonder if Sect 5 actually tells us that this doc is "updating
>   RFC3209"  cause you are "revising" the definitions.
>
>3. Section 4.3 has ref to [RSVP]. That is not in ref section.,
>   I guess you mean [RFC2205]
>
>4. In sect 8.1.2 you have a ref to [MPLS-TE] but it is not listed
>   in ref section.
>
>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.
>   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"
>
>6. Why does LDP need to be mentioned in this doc at all?
>
>Bert 
>
>  
>