GMPLS Segment Recovery
RFC 4873

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

(Ross Callon) Yes

(Jari Arkko) No Objection

(Brian Carpenter) No Objection

(Lars Eggert) No Objection

(Bill Fenner) No Objection

Comment (2006-10-25)
No email
send info
Reference to draft-lang-ccamp-gmpls-recovery-e2e-signaling should probably be updated to draft-ietf-ccamp-gmpls-recovery-e2e-signaling via RFC Editor note so it doesn't hang waiting for a document that will never come.

(Ted Hardie) No Objection

(Sam Hartman) No Objection

(Russ Housley) No Objection

Comment (2006-10-24)
No email
send info
  From SecDir Review by Ran Canetti:

  There is the need to authenticate RSVP communication that is not
  hop-by-hop (hbh). (Note: This authentication is not for the purpose of
  end-to-end contents integrity, but rather to protect the RSVP protocol
  from spoofing and resource grabbing by outsiders.) RFC 3437, which
  uses non-hbh RSVP communication, contains an off-hand suggestion to
  use generic IPsec for this communication (since RFC 2747 doesn't
  apply). But the suggestion is not nearly detailed enough to be of real
  standards value.

  What about compromised RSVP routers? This concern is not mentioned in
  any RSVP-related RFC that I saw. What is the damage that can be done by
  a compromised router? How can this damage be limited/contained? What is
  the extent to which a compromised RSVP router can damage non-RSVP
  traffic? Also, what about false advertisements by RSVP routers? Can
  clients verify that they get the bandwidth allocation they paid for?

(Cullen Jennings) No Objection

(David Kessens) No Objection

(Jon Peterson) No Objection

(Dan Romascanu) No Objection

(Mark Townsley) No Objection

Magnus Westerlund No Objection