Re: IESG comments on generalize MPLS documents

[Lou Berger <[e-mail]>]

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.

>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.

>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.

>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.")


>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.

>2. [RFC2119] reference is used, but it is not listed in Ref section

okay.

>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.

>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?

><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?

>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..."

>3. Section 4.3 has ref to [RSVP]. That is not in ref section.,
>    I guess you mean [RFC2205]

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.

>    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