[spring] Conclusion of Adoption call for draft-filsfilscheng-spring-srv6-srh-compression

["Joel M. Halpern" <[e-mail]>]

With apologies to the working group for the delay, this email formally 
ends the adoption call that was announced at
https://mailarchive.ietf.org/arch/msg/spring/-tvDZ5biRXvfLlyJ8IMtX-7EUp4/
for draft-filsfilscheng-spring-srv6-srh-compression

The conclusion is somewhat unusual, so please read carefully.

First, let me thank all of the working group participants for their 
active and energetic participation in this call.  That is what we need.

In terms of the rough consensus of the feedback we received, the rough 
consensus of the working group is that we should adopt this document.
Due to process concerns, I am placing two caveats on this adoption, one 
of which can be easily dealt with by the authors, and one of which will 
cause some delay.

The SPRING working group chairs sent a policy statement last March
https://mailarchive.ietf.org/arch/msg/spring/vCc9Ckvwu5HA-RCleV712dsA5OA/
which calls attention to the issue of conflict between working group 
efforts and existing PS or BCP RFCs.  This policy applies to the subject 
document.  It is my judgment that the issues raised regarding whether 
this work complies with RFC 4291 require adherence to this policy.
As such, we need a draft in front of 6man (the responsible working group 
for RFC 4291) that addresses the raised disconnect.
fortunately, we have been told that the 6man chairs and area directors 
are appointing authors for just such a document to address the issue of 
the relationship of C-SIDs with RFC 4291.
Therefore, I will not be approving posting of the working group draft 
until the author team has posted an initial take for 6man consumption of 
such a draft. Once they have posted that draft, I will approve posting 
of a working group ID with the addition according to the next caveat.

As per the statement in the adoption call, as part of adoption the 
document is required to have a section (an appendix seems the most 
appropriate, but placement will be up to the editors) on open issues. As 
there is a lot of controversy about the open issues, and about how to 
describe them, I am providing text (below) for that section.   Once the 
draft is posted as a working group draft, the working group will of 
course own the text, and WG rough consensus can change the text.  Also, 
once we have a WG draft I will arrange to get an issue tracker to make 
sure we keep track of all the issues, not just the major ones in the 
open issues section of the document.

Expected text on Open Issues:

Open Issues:

Issues raised during and after the adoption call for this draft are 
tracked in an issue tracker. The remainder of this section identifies 
the most significant open issues, from the adoption call, for the 
working group to keep track of.

As a reminder to those reading this section, this document is a work in 
progress, and subject to change by the working group.  As noted at the 
front of this document, "It is inappropriate to use Internet-Drafts as 
reference material"

o Given that the working group has said that it wants to standardize one
data plane solution, and given that the document contains multiple SRv6
EndPoint behaviors that some WG members have stated are multiple data
plane solutions, the working group will address whether this is valid
and coherent with its one data plane solution objective.

o As reminded in the conclusion of the adoption call, this document is 
subject to the policy announced by the SPRING chairs in 
https://mailarchive.ietf.org/arch/msg/spring/vCc9Ckvwu5HA-RCleV712dsA5OA/.
In particular, this means that this document can not go to WG last call 
until 6man completes handling of an Internet Draft that deals with the 
relationship of C-SIDs to RFC 4291.  It is hoped and expected that said 
resolution will be a WG last call and document approval in 6man of a 
document providing for the way that C-SIDs use the IPv6 destination 
address field.