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

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

Alvaro Retana Yes

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)

(Alia Atlas; former steering group member) Yes

Yes ( for -05)
No email
send info

(Adam Roach; former steering group member) No Objection

No Objection ( for -05)
No email
send info

(Alexey Melnikov; former steering group member) No Objection

No Objection ( for -05)
No email
send info

(Alissa Cooper; former steering group member) No Objection

No Objection ( for -05)
No email
send info

(Ben Campbell; former steering group member) No Objection

No Objection ( for -05)
No email
send info

(Benoît Claise; former steering group member) No Objection

No Objection ( for -05)
No email
send info

(Deborah Brungard; former steering group member) No Objection

No Objection ( for -05)
No email
send info

(Eric Rescorla; former steering group member) No Objection

No Objection (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,

(Kathleen Moriarty; former steering group member) No Objection

No Objection (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).

(Mirja Kühlewind; former steering group member) (was Discuss) No Objection

No Objection (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.

(Spencer Dawkins; former steering group member) No Objection

No Objection ( for -05)
No email
send info

(Suresh Krishnan; former steering group member) No Objection

No Objection ( for -05)
No email
send info

(Terry Manderson; former steering group member) No Objection

No Objection ( for -05)
No email
send info