Label Switched Path (LSP) Attribute in the Explicit Route Object (ERO)
RFC 7570

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

(Adrian Farrel) Yes

(Jari Arkko) No Objection

(Alia Atlas) No Objection

(Richard Barnes) No Objection

(Benoît Claise) No Objection

(Spencer Dawkins) No Objection

Comment (2015-03-10 for -04)
No email
send info
I'll leave this as a comment. If it's important, a RTG AD can say so ...

In this text:

   If a node is processing an ERO Hop Attributes subobject and does not
   support handling of the subobject it will behave as described in
   [RFC3209] when an unrecognized ERO subobject is encountered.  This
   node will return a PathErr with error code "Routing Error" and error
   value "Bad EXPLICIT_ROUTE object" with the EXPLICIT_ROUTE object
   included, truncated (on the left) to the offending unrecognized
   subobject.

The behavior is a bit different from what I thought was the corresponding text in [RFC3209]:

      It is anticipated that new subobjects may be defined over time.  A
   node which encounters an unrecognized subobject during its normal ERO
   processing sends a PathErr with the error code "Routing Error" and
   error value of "Bad Explicit Route Object" toward the sender.  The
   EXPLICIT_ROUTE object is included, truncated (on the left) to the
   offending subobject.  The presence of an unrecognized subobject which
                         ^
          I'm not seeing ^ this part reproduced in the draft
                         
   is not encountered in a node's ERO processing SHOULD be ignored.  It
   is passed forward along with the rest of the remaining ERO stack.
   
I'm no RSVP-TE jockey, but I would have thought if you behaved as in [RFC3209], you would have done everything in that paragraph ... and obviously, I only compared these because the description was imported by reference AND sort-of-by value at the same time. 

Maybe providing only the reference, as you do in the next couple of instances would be better?

(Stephen Farrell) No Objection

(Brian Haberman) No Objection

Comment (2015-03-10 for -04)
No email
send info
Some suggested changes:

- Section 2 : s/The ERO Hop Attributes subobject MAY be carried/The ERO Hop Attributes subobject is carried/

- Section 3.1 : s/The RRO Hop Attributes subobject MAY be carried/The RRO Hop Attributes subobject is carried/

- Each requested IANA action should use a unique identifier (e.g., TBA-1, TBA-2) rather than a generic TBA.  That simplifies IANA's job.

(Joel Jaeggli) No Objection

Barry Leiba No Objection

(Ted Lemon) No Objection

(Kathleen Moriarty) No Objection

(Pete Resnick) No Objection

Comment (2015-03-11 for -04)
No email
send info
Similar to Brian's comment:

2.2:

s/One or more TLVs MAY be present in each object/Each object MAY contain one or more TLVs

s/The Attribute Flags TLV defined in [RFC5420] MAY be carried in an ERO Hop Attributes Subobject/The Attribute Flags TLV defined in [RFC5420] are carried in an ERO Hop Attributes Subobject.

3.2.2/3.2.3: s/MAY/can

(Martin Stiemerling) No Objection