Ballot for draft-farrel-sfc-convent
Yes
No Objection
Note: This ballot was opened for revision 05 and is now closed.
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)
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,
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).
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.