Generalized Multi-Protocol Label Switching (GMPLS) Extensions for Synchronous Optical Network (SONET) and Synchronous Digital Hierarchy (SDH) Control
RFC 4606

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

(Ross Callon) Yes

(Jari Arkko) No Objection

(Brian Carpenter) No Objection

Comment (2006-05-09)
No email
send info
Suggest changing the first sentence of the IANA Considerations:

OLD:
  Three values have been defined by IANA for this document. 

NEW: 
  Three values defined by IANA for RFC 3946 now apply to this document.

(Lisa Dusseault) No Objection

(Lars Eggert) No Objection

(Bill Fenner) No Objection

(Ted Hardie) No Objection

(Sam Hartman) No Objection

(Cullen Jennings) No Objection

(David Kessens) No Objection

(Jon Peterson) No Objection

(Dan Romascanu) No Objection

(Mark Townsley) No Objection

Magnus Westerlund No Objection

(Russ Housley) (was Discuss, Abstain, Discuss) Abstain

Comment (2006-05-11)
No email
send info
  
  This document provides minor clarification to RFC 3946, but there is
  not a summary of the changes.  This usually appears as a separate
  section or subsection in an update to an earlier RFC.

  The comments in Bernard Aboba's SecDir Review caused me to do some
  digging.  Thanks to him for highlighting the reference.  The Security
  Considerations of this document refer to RFC 3209, and the Security
  Considerations (Section 6) of RFC 3209 says:
  >
  > In principle these extensions to RSVP pose no security exposures over
  > and above RFC 2205[1].  However, there is a slight change in the
  > trust model.  Traffic sent on a normal RSVP session can be filtered
  > according to source and destination addresses as well as port
  > numbers.  In this specification, filtering occurs only on the basis
  > of an incoming label.  For this reason an administration may wish to
  > limit the domain over which LSP tunnels can be established.  This can
  > be accomplished by setting filters on various ports to deny action on
  > a RSVP path message with a SESSION object of type LSP_TUNNEL_IPv4 (7)
  > or LSP_TUNNEL_IPv6 (8).
  >
  Is there a change in trust model in this document too?  I do not think
  so.  The structure of the security considerations in this document,
  which is essentially five references, is confusing.  It is not clear
  which considerations really apply to this document.  I am asking for
  clarity.