Summary: Has a BLOCK. Has enough positions to pass once BLOCK positions are resolved.
Ballot question: "Is this charter ready for external review?"
This proposed charter has minimal text on security concerns, asserting that the scope is limited to a single trust domain and only applying a weak requirement to "strive to identify and address" security considerations brought up by its technologies. The text concerning a single trust domain seems to implicitly assume that there is thus no need for cryptographic assurance of the integrity and/or authenticity of origin for route information, a position whose accuracy remains unclear to me. A commitment to "strive" to do something is hardly any commitment at all, in that failing to do that thing remains consistent with the commitment. Additionally, the current charter text includes some security-related items, noting that "there are a number of serious security concerns with source routing at the IP layer", committing to define the SRv6 header so that blind attacks are never possible (and with options to provide additional security in some networks), and committing to provide a security analysis for each protocol being developed. Has anything changed in the intervening five years to render these items unnecessary? I don't see any justification for why these commitments are being abandoned.
I'm balloting No Objection, but hope that people look at the SPRING/IPPM interaction I mentioned below. Otherwise, this is mostly editorial. I'm not sure who or what finds it advantageous to use loose routing in this text - "Full explicit control (through loose or strict path specification) can be achieved in a network comprising only SPRING nodes, however SPRING nodes must inter-operate through loose routing in existing networks and may find it advantageous to use loose routing for other network applications." I THINK the reference is to a SPRING node, which doesn't make a lot of sense to me, but I'm guessing. Does everyone else know what "specificities" are meant here? "o Operation, Administration and Management (OAM), and traffic accounting in networks with SR-MPLS and SRv6 data planes in the case where SR introduces specificities compared to MPLS or IPv6 technologies." and "o Performance Management (PM) and monitoring in networks with SR-MPLS and SRv6 data planes in the case where SR introduces specificities compared to MPLS or IPv6 technologies." On "Performance Management and monitoring", I note that https://datatracker.ietf.org/doc/draft-ietf-ippm-ioam-data/ includes Segment Routing as one of its targeted encapsulations. IPPM is Mirja's working group as of about a month ago, but I'm wondering what the overlap might be. Is this something the two groups/ADs have talked about? It might be less surprising to readers if the working group names under "Specific expected interactions" were capitalized.
Can you please add 6man as a co-ordination working group for the SRv6 Network programming item as well
I am looking forward to hearing answers to/followup discussion of Benjamin's DISCUSS.