[Idr] Adam Roach's Discuss on draft-ietf-idr-bgp-prefix-sid-25: (with DISCUSS)

[Adam Roach <[e-mail]>]

Adam Roach has entered the following ballot position for
draft-ietf-idr-bgp-prefix-sid-25: Discuss

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-idr-bgp-prefix-sid/



----------------------------------------------------------------------
DISCUSS:
----------------------------------------------------------------------

The removal of IPv6 support from this document without it having a normative
dependency on a document that describes use with IPv6 addresses causes me
quite a bit of concern, on two fronts. I'm willing to be convinced that I'm
off in the weeds, but right now I don't think we can publish the document.

First: while I understand that the working group's intentions are genuine,
this sets us up for a "fail unsafe" situation; if the working group, for
whatever reason, does not progress the IPv6 counterpart of this protocol to an
RFC, then the publication of this document will (retroactively) be in
contravention of the architectural advice issued by the IAB:

https://www.iab.org/documents/correspondence-reports-documents/2016-2/iab-statement-on-ipv6/

The second issue is the precedent of publishing an IPv4-only document in 2018,
at a time that we're aggressively trying to ensure that everyone is designing
their protocols in a way that supports IPv6 addresses. Even with a plan to fix
the lack of IPv6 support, the publication of the document itself sets a bad
example.

I think the first issue could be solved by holding this document until at least
a skeletal IPv6 approach is documented, and then creating a normative dependency
from this document to that one. The second issue could be addressed by
indicating that IPv6 is out of scope of this document only because it is
addressed in [RFC xxxx] (the aforementioned IPv6 document).