IESG comments on generalize MPLS documents

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

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