Domain Subobjects for Resource Reservation Protocol - Traffic Engineering (RSVP-TE)
RFC 7898
Yes
No Objection
Note: This ballot was opened for revision 03 and is now closed.
Alvaro Retana No Objection
(Deborah Brungard; former steering group member) Yes
(Alissa Cooper; former steering group member) No Objection
(Barry Leiba; former steering group member) No Objection
In Section 5.1, to be consistent with how IANA prefers registry URLs to be specified, please remove the string "/rsvp-parameters.xhtml" from the three IANA URLs. I'll also note that IANA doesn't guarantee the persistence of the URL fragment identifiers (the end of the URL that starts with "#"). You might discuss with IANA whether it's OK to leave them, or better to remove those URLs.
(Ben Campbell; former steering group member) No Objection
(Benoît Claise; former steering group member) No Objection
(Jari Arkko; former steering group member) No Objection
(Joel Jaeggli; former steering group member) No Objection
(Kathleen Moriarty; former steering group member) No Objection
(Martin Stiemerling; former steering group member) No Objection
(Spencer Dawkins; former steering group member) No Objection
In this text: The new subobjects introduced by this document will not be understood by legacy implementations. If one of the subobjects is received in a RSVP-TE object that does not understand it, it will behave as described in [RFC3209] and [RFC4874]. I think something is confused. Do RSVP-TE objects understand subobjects? Or is this The new subobjects introduced by this document will not be understood by legacy implementations. If a legacy implementations receives one of the subobjects in an RSVP-TE object that it does not understand, the legacy implementation will behave as described in [RFC3209] and [RFC4874]. correct?
(Stephen Farrell; former steering group member) No Objection
(Terry Manderson; former steering group member) No Objection