Generalized Multi-Protocol Label Switching (GMPLS) Extensions for Synchronous Optical Network (SONET) and Synchronous Digital Hierarchy (SDH) Control
draft-ietf-ccamp-rfc3946bis-01

[Ballot comment]
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.

[Ballot comment]
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.

[Ballot discuss]
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.

[Ballot discuss]
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.

IANA Last Call Comments:
Upon approval of this document the IANA will update the reference for the following:

Two RSVP C-Types in registry:
http://www.iana.org/assignments/rsvp-parameters
- A SONET/SDH SENDER_TSPEC object: Class = 12, C-Type = 4
- A SONET/SDH FLOWSPEC object: Class = 9, C-Type = 4

One LDP TLV Type in registry:
http://www.iana.org/assignments/ldp-namespaces
- A type field for the SONET/SDH Traffic Parameters TLV

There are some registries in section 2.1 and section 3. There is also a registry and a
value registration in appendix 1. Does the IANA have to do anything with regards to these
registries? Or is changing the references for the rsvp and ldp parameters the ONLY IANA
Action?

This is a relatively minor update to RFC3946. One change is to correct an error (so that the text says what was originally intended -- which is what most but not all implemeters had already understood). The other changes are to add clarification. There are very few changes from 3946, and all are straightforward. There are multiple existing implementations of RFC3946 and this bis. The deltas on RFC 3946 have been discussed with the OIF.