MPLS Transport Encapsulation for the Service Function Chaining (SFC) Network Service Header (NSH)
RFC 8596

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

Deborah Brungard Yes

Alissa Cooper No Objection

Benjamin Kaduk (was Discuss) No Objection

Comment (2019-03-24)
Thank you for resolving my DISCUSS point!

(Mirja K├╝hlewind) No Objection

Comment (2019-03-12 for -03)
Not sure about the document's intended status as informational. The doc does not specify a new protocol but it does give normative instructions on the used of protocols. However, I leave this decision to the responsible AD and WG.

(Alexey Melnikov) No Objection

Alvaro Retana No Objection

Comment (2019-03-13 for -03)
No email
send info
I also would have expected this document to be in the Standards Track.

(Adam Roach) No Objection

Martin Vigoureux No Objection

Comment (2019-03-14 for -03)
Without having looked before I was thinking this was Standard Track, I'm surprised it is not.

You say:
   1.  Push zero or more labels that are interpreted by the destination
       MPLS node on to the packet, 
and then say:
   The receiving MPLS node then pops the SFF Label (and any labels
   beneath it)
So it looks like that any label which might have been pushed before the SFF label is/are simply ignored at the other end.
I'm not asking for the behaviour to be specified and I understand that strictly speaking the text is not forbidding something to happen based on these labels but still it might be useful to explicitly say that these labels may be processed.