Skip to main content

Encoding of Attributes for Multiprotocol Label Switching (MPLS) Label Switched Path (LSP) Establishment Using Resource ReserVation Protocol-Traffic Engineering (RSVP-TE)
draft-ietf-mpls-rsvpte-attributes-05

Yes

(Alex Zinin)

No Objection

(Allison Mankin)
(Bert Wijnen)
(Bill Fenner)
(David Kessens)
(Jon Peterson)
(Margaret Cullen)
(Mark Townsley)
(Sam Hartman)
(Scott Hollenbeck)

Note: This ballot was opened for revision 05 and is now closed.

Alex Zinin Former IESG member
(was Discuss, Yes) Yes
Yes () Unknown

                            
Allison Mankin Former IESG member
No Objection
No Objection () Unknown

                            
Bert Wijnen Former IESG member
No Objection
No Objection () Unknown

                            
Bill Fenner Former IESG member
No Objection
No Objection () Unknown

                            
Brian Carpenter Former IESG member
(was Discuss) No Objection
No Objection (2005-03-21) Unknown
Comprehensibility comments from Gen-ART reviewer:

Document: draft-ietf-mpls-rsvpte-attributes-04.txt
Review: John Loughney
Date: 2 mars 2005
...
Additionally, I had a lot of trouble actually parsing much of the document,
I am not going to site every single instance, but some examples are listed
below.  I think an editorial pass is needed to enhance the comprehensibility
of the text.

Minor comments
1) Way too much acronyms in the abstract ...
2) Took me several reads to be able to parse the following text:

    .... Because of the nature of the TLV
    construction the object is flexible and allows the future definition
    of:
    - further bit flags if further, distinct uses are discovered
    - arbitrary options and attributes parameters carried as individual
      TLVs.

suggest:

    The new RSVP-TE message object is quite flexible, due to the use of the
    TLV format and allows:
    - future specification of bit flags
    - additional options and atttribute paramerters carried in TLV format.

"if further, distinct uses are discovered" and "arbitrary options and attributes"
sounds like an open invitation for folks to invent new things without good reason ...

3) This text was confusing:

4.2 Generic Processing Rules for Path Messages

  An LSR that does not support this object will pass it on unaltered
  because of the C-Num.

suggest:

4.2 Generic Processing Rules for Path Messages

  An LSR that does not support this object is required to pass it on unaltered,
  as the C-Num indicates that the LSR should pass the object on transparently.
David Kessens Former IESG member
No Objection
No Objection () Unknown

                            
Jon Peterson Former IESG member
No Objection
No Objection () Unknown

                            
Margaret Cullen Former IESG member
No Objection
No Objection () Unknown

                            
Mark Townsley Former IESG member
(was No Record, Discuss) No Objection
No Objection () Unknown

                            
Russ Housley Former IESG member
(was Discuss) No Objection
No Objection (2005-03-02) Unknown
  Section 1.1 says:
  >
  > The RSVP-TE signaling protocol also forms the basis of a signaling
  > protocol for Generalized MPLS (GMPLS) as described in [RFC3471] and
  > [RFC3473]. The extensions described in this document are intended to
  > be equally applicable to MPLS and GMPLS.
  >
  I would like to see the title and abstract reflect this situation.
Sam Hartman Former IESG member
No Objection
No Objection () Unknown

                            
Scott Hollenbeck Former IESG member
No Objection
No Objection () Unknown