[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
IESG comments on generalize MPLS documents
- To: "Ccamp-wg (E-mail)" <ccamp@ops.ietf.org>
- Subject: IESG comments on generalize MPLS documents
- From: "Wijnen, Bert (Bert)" <bwijnen@lucent.com>
- Date: Mon, 12 Aug 2002 17:35:34 +0200
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