Domain Subobjects for Resource Reservation Protocol - Traffic Engineering (RSVP-TE)
RFC 7898

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

(Deborah Brungard) Yes

(Jari Arkko) No Objection

(Ben Campbell) No Objection

(Benoît Claise) No Objection

(Alissa Cooper) No Objection

(Spencer Dawkins) No Objection

Comment (2015-11-16 for -03)
No email
send info
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) No Objection

(Joel Jaeggli) No Objection

(Barry Leiba) No Objection

Comment (2015-11-18 for -03)
No email
send info
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.

(Terry Manderson) No Objection

(Kathleen Moriarty) No Objection

Alvaro Retana No Objection

(Martin Stiemerling) No Objection