Generalized Multi-Protocol Label Switching (GMPLS) Extensions for Synchronous Optical Network (SONET) and Synchronous Digital Hierarchy (SDH) Control
draft-ietf-ccamp-rfc3946bis-01
Yes
(Ross Callon)
No Objection
(Bill Fenner)
(Cullen Jennings)
(Dan Romascanu)
(David Kessens)
(Jari Arkko)
(Jon Peterson)
(Lars Eggert)
(Lisa Dusseault)
(Magnus Westerlund)
(Mark Townsley)
(Sam Hartman)
(Ted Hardie)
Abstain
Note: This ballot was opened for revision 01 and is now closed.
Ross Callon Former IESG member
Yes
Yes
()
Unknown
Bill Fenner Former IESG member
No Objection
No Objection
()
Unknown
Brian Carpenter Former IESG member
No Objection
No Objection
(2006-05-09)
Unknown
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.
Cullen Jennings Former IESG member
No Objection
No Objection
()
Unknown
Dan Romascanu Former IESG member
No Objection
No Objection
()
Unknown
David Kessens Former IESG member
No Objection
No Objection
()
Unknown
Jari Arkko Former IESG member
No Objection
No Objection
()
Unknown
Jon Peterson Former IESG member
No Objection
No Objection
()
Unknown
Lars Eggert Former IESG member
No Objection
No Objection
()
Unknown
Lisa Dusseault Former IESG member
No Objection
No Objection
()
Unknown
Magnus Westerlund Former IESG member
No Objection
No Objection
()
Unknown
Mark Townsley Former IESG member
No Objection
No Objection
()
Unknown
Sam Hartman Former IESG member
No Objection
No Objection
()
Unknown
Ted Hardie Former IESG member
No Objection
No Objection
()
Unknown
Russ Housley Former IESG member
(was Discuss, Abstain, Discuss)
Abstain
Abstain
(2006-05-11)
Unknown
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.