Generalized Multi-Protocol Label Switching (GMPLS) Signaling Extensions for G.709 Optical Transport Networks Control
RFC 4328

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

(Alex Zinin; former steering group member) Yes

Yes ( for -)
No email
send info

(Allison Mankin; former steering group member) No Objection

No Objection (2005-01-06 for -)
No email
send info
For clarity, all the documents should reference Extra Data as
in the terminology doc  (they vary among Extra data, extra-data, Extra Data, 
and extra data) and the first use of the term should reference the terminology
doc.

(Bert Wijnen; former steering group member) (was Discuss) No Objection

No Objection ()
No email
send info

(Bill Fenner; former steering group member) No Objection

No Objection ( for -)
No email
send info

(David Kessens; former steering group member) No Objection

No Objection ( for -)
No email
send info

(Harald Alvestrand; former steering group member) No Objection

No Objection (2005-01-06 for -)
No email
send info
Reviewed by Spencer Dawkins, Gen-ART

His review:

This document is almost ready for publication as Proposed Standard. I
have one question, in 4.1:


- In 4.1, some of the "not significant" bits "SHOULD be set to 0" -
  don't we usually "MUST be set to 0, SHOULD ignore on receipt" in
  similar cases?

Minor Nits:

- The first paragraph of section 2 dumps a BUNCH of unexpanded
  acronyms on the reader! Some are expanded two or three sentences
  later, but the effect is confusing. Maybe a list of acronyms and
  expansions as part of the first sentence? I hate to inflict a
  request for ASCII art on the editor at last call time, but if these
  entities could be presented as a protocol stack (at least some are
  described as "protocol layers"), that would help, too.

- In 4.2, s/only one of label can appear/only one label can appear/

Spencer got feedback from the authors; from the dialogue, I conclude that the issues are not show-stoppers.

(Jon Peterson; former steering group member) No Objection

No Objection ( for -)
No email
send info

(Margaret Cullen; former steering group member) No Objection

No Objection ( for -)
No email
send info

(Russ Housley; former steering group member) No Objection

No Objection (2005-01-03 for -)
No email
send info
  Please move the note about not replicating the content of the ITU-T
  OTN Recommendations in this document out of the abstract.  Please
  put it the introduction.

  Section 7 says:
  >    
  > This draft introduces no new security considerations to [RFC3473]. 
  > GMPLS security is described in section 11 of [RFC3471] and refers 
  > to [RFC3209] for RSVP-TE. 
  >
  The first reference is needed.  However, references to RFC 3471 and
  RFC 3209 are quite indirect.  The security considerations in these
  documents point to other documents without adding much else.  Perhaps
  the level of indirection can be removed.

(Sam Hartman; former steering group member) No Objection

No Objection (2005-01-04 for -)
No email
send info
If revisions are required, section 3.1 should gain an explanation of
why a technology-dependent spec needs to revise the
technology-independent part of GMPLS.  I assume there is a good reason
for this and so will not hold up the document only on this issue.

(Scott Hollenbeck; former steering group member) No Objection

No Objection ( for -)
No email
send info

(Ted Hardie; former steering group member) No Objection

No Objection (2005-01-04 for -)
No email
send info
In Section 3.2.1, the draft gives the following table:

3.2.1 Signal Type (ST) 
 
   This field (8 bits) indicates the type of G.709 Elementary Signal 
   that comprises the requested LSP. The permitted values are: 

    Value     Type 
      -----     ---- 
        0       Irrelevant 
        1       ODU1 (i.e. 2.5 Gbps)  
        2       ODU2 (i.e. 10  Gbps)    
        3       ODU3 (i.e. 40  Gbps) 
        4       Reserved (for future use)  
        5       Reserved (for future use) 
        6       OCh at 2.5 Gbps 
        7       OCh at 10  Gbps  
        8       OCh at 40  Gbps 
        9-255   Reserved (for future use) 

This does not seem to match anything in the IANA consideration section;
I assume this is because these are defined by the ITU spec.  It might be
worth making that explicit; I believe we also tend to use "ignored" rather
than irrelevant.

(Thomas Narten; former steering group member) No Objection

No Objection ( for -)
No email
send info