[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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.

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