Operating the Network Service Header (NSH) with Next Protocol "None"
RFC 8393
Yes
No Objection
Note: This ballot was opened for revision 05 and is now closed.
Alvaro Retana Yes
Warren Kumari No Objection
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)
(Alia Atlas; former steering group member) Yes
(Adam Roach; former steering group member) No Objection
(Alexey Melnikov; former steering group member) No Objection
(Alissa Cooper; former steering group member) No Objection
(Ben Campbell; former steering group member) No Objection
(Benoît Claise; former steering group member) No Objection
(Deborah Brungard; former steering group member) No Objection
(Eric Rescorla; former steering group member) No Objection
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,
(Kathleen Moriarty; former steering group member) No Objection
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).
(Mirja Kühlewind; former steering group member) (was Discuss) No Objection
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.
(Spencer Dawkins; former steering group member) No Objection
(Suresh Krishnan; former steering group member) No Objection
(Terry Manderson; former steering group member) No Objection