Operating the Network Service Header (NSH) with Next Protocol "None"
draft-farrel-sfc-convent-06
Yes
(Alia Atlas)
(Alvaro Retana)
No Objection
(Adam Roach)
(Alexey Melnikov)
(Alissa Cooper)
(Ben Campbell)
(Benoît Claise)
(Deborah Brungard)
(Spencer Dawkins)
(Suresh Krishnan)
(Terry Manderson)
Note: This ballot was opened for revision 05 and is now closed.
Warren Kumari
No Objection
Comment
(2018-02-07 for -05)
Unknown
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 IESG member
Yes
Yes
(for -05)
Unknown
Alvaro Retana Former IESG member
Yes
Yes
(for -05)
Unknown
Adam Roach Former IESG member
No Objection
No Objection
(for -05)
Unknown
Alexey Melnikov Former IESG member
No Objection
No Objection
(for -05)
Unknown
Alissa Cooper Former IESG member
No Objection
No Objection
(for -05)
Unknown
Ben Campbell Former IESG member
No Objection
No Objection
(for -05)
Unknown
Benoît Claise Former IESG member
No Objection
No Objection
(for -05)
Unknown
Deborah Brungard Former IESG member
No Objection
No Objection
(for -05)
Unknown
Eric Rescorla Former IESG member
No Objection
No Objection
(2018-02-06 for -05)
Unknown
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 IESG member
No Objection
No Objection
(2018-02-07 for -05)
Unknown
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 IESG member
(was Discuss)
No Objection
No Objection
(2018-03-12)
Unknown
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 IESG member
No Objection
No Objection
(for -05)
Unknown
Suresh Krishnan Former IESG member
No Objection
No Objection
(for -05)
Unknown
Terry Manderson Former IESG member
No Objection
No Objection
(for -05)
Unknown