Éric Vyncke has entered the following ballot position for draft-ietf-spring-srv6-network-programming-19: No Objection
When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html for more information about IESG DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: https://datatracker.ietf.org/doc/draft-ietf-spring-srv6-network-programming/ ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- Thank you for the work put into this document. Thank you also for having edited the document based on the INT-DIR review by Brian Haberman (thank you Brian for the detailed review!) and replying to Brian's review. https://datatracker.ietf.org/doc/review-ietf-spring-srv6-network-programming-18-intdir-telechat-haberman-2020-09-14/ Please find below a couple of non-blocking COMMENT points and nits. I hope that this helps to improve the document, Regards, -éric == COMMENTS == -- Section 3 -- There is some text copied from section 4.3 from RFC 8754. But, even if it seems obvious that the behaviors specified in this document _ONLY_ apply when "A FIB entry that represents a locally instantiated SRv6 SID", I suggest to spell it out to avoid any ambiguity. -- Section 3.2 -- I am a little ambivalent with Brian's point about the location of the given examples. On one hand, those real case examples of SID allocation are really helpful to understand the impact of allocation; on the other hand, it is usual to move examples in appendix. Curious to see if other IESG members have other point of view. In the last short example (this one could stay in the current location), should the value of F and A be stated? They are obvious from the used SID value of course, but, let's be complete ? -- Section 3.3 -- Please follow RFC 5952 and write all IPv6 in lowercase. -- Section 4.2 and 4.3 -- As "End.X" and "End.T" behaviors are variants of the "End" behavior, does the section 4.1.1 (Upper-Layer Header) also apply ? -- Section 4.9 -- For consistency with previous behavior descriptions of End.DT[46], I suggest to mention that 143 has been reserved by IANA. == NITS == -- Section 2 -- In the bullet list, there are a couple of missing '.' at the end of the list items. -- Section 3 -- "longest-prefix-match lookup on the packets destination address" "packets" should probably be singular. In "IPv6 subnet allocated for SRv6 SIDs by the operator", should it rather be "prefix" than "subnet" ? -- Section 3.2 -- Strongly suggest to be consistent with the use of "IANA Endpoint Behavior codepoint" as sometimes it is shortened into "IANA Behavior" (also unsure whether the "IANA" qualification is really useful here) -- Section 4.2 -- "one for the bundle(LAG)" Link Aggregation has not been expanded before and I am not sure whether the 'LAG' adds anything to the paragraph. -- Section 4.16 -- Should PSP, USP, USD be expanded in the short introduction of this section ? -- Section 8 -- The usual location of the security considerations is after all specification section, so, it should be after the 'control plane' section. _______________________________________________ spring mailing list [email protected] https://www.ietf.org/mailman/listinfo/spring
