[spring] Éric Vyncke's No Objection on draft-ietf-spring-srv6-network-programming-19: (with COMMENT)

[Éric Vyncke via Datatracker <[e-mail]>]

É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.