Operating the Network Service Header (NSH) with Next Protocol "None"
RFC 8393

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

(Alia Atlas) Yes

Alvaro Retana Yes

Deborah Brungard No Objection

(Ben Campbell) No Objection

(Benoît Claise) No Objection

Alissa Cooper No Objection

(Spencer Dawkins) No Objection

(Suresh Krishnan) No Objection

Warren Kumari No Objection

Comment (2018-02-07 for -05)
No email
send info
In a comment vying for least useful comment ever:
'Packets are classified at the SFC network ingress boundaries by
   Classifiers (section 4.4 of [RFC7665]) and have an NSH applied to
   them."
I suspect this should be "and have *a* NSH applied to them".
(hey, I did warn you)

(Mirja Kühlewind) (was Discuss) No Objection

Comment (2018-03-12)
No email
send info
Thanks for addressing my discuss by adding a new section on congestion management! I was still hoping to see more concrete guidance e.g. simlar to what RFC8085 recommends: "... not sending on average more than one UDP datagram per RTT to a destination". However, this might not be suitable for all sfc use cases and therefore the high level guidance as now provided might be sufficient as well.

-----
Old comment
------
I think this document should update RFC8300 as it does not only register an new protocol but also changes some of the process for this specific case.

(Terry Manderson) No Objection

(Alexey Melnikov) No Objection

(Kathleen Moriarty) No Objection

Comment (2018-02-07 for -05)
No email
send info
Thanks for the security considerations, I think these look good for what this document should address adding the possible considerations for metadata only NSH.  Integrity protection, authentication and other things lacking in SFC and NSH should be addressed in other documents (and it's sadly not, but this isn't the document for that).

(Eric Rescorla) No Objection

Comment (2018-02-06 for -05)
No email
send info
   The need to protect the metadata is not modified by this document and
   forms part of the NSH definition found in [I-D.ietf-sfc-nsh].
Nit: I wouldn't limit this to encryption. If you care about integrity/data origin authentication, then encryption may not supply that,

(Adam Roach) No Objection