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

From: "Darren Dukes (ddukes)" <[email-masked]>
Date: Fri, 5 Nov 2021 14:17:51 +0000

Hello Joel,

I want to make note of two suggestions, I’m copying the list for record keeping only.

1 – The second bullet (beginning with “As reminded”) should include the link to the questions asked of the 6man chairs/ADs https://mailarchive.ietf.org/arch/msg/ipv6/merG-RgtA3shloDqpyRk-xWHniw/ and their response https://mailarchive.ietf.org/arch/msg/spring/z_3nbdwVQ_V66ZqkV-ZhIg7kakA/<https://mailarchive.ietf.org/arch/msg/ipv6/3k8_1JgKGtnLsfsVf65qvReNuLc/>

2 – About the requirements for a document identifying the “relationship of C-SIDs with RFC 4291.”.  The word “C-SIDs” should be changed to “SRv6 SIDs” in the sentences when such a document is discussed.  This would better match the 6man chairs/ADs response:

“To summarize: we do not object to C-SID behavior work continuing in SPRING, we simply need a clarifying document described in [A].”

And

“[A] A separate 6MAN document to clarify and categorize SRv6 SIDs is needed.”

Thanks

  Darren

On 2021-10-31, 11:37 AM, "spring" <[email-masked]> wrote:

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.

_______________________________________________
spring mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/spring

---

From: "Joel M. Halpern" <[email-masked]>
Date: Fri, 5 Nov 2021 13:39:35 -0400

Darren, while I appreciate your requests, I must decline both requests.

On he first request, the bullet is derived from the stated SPRING chairs 
policy, as was announced to the working group and is cited in the 
adoption conclusion.  It is not reliant on the charter item, the 
question I asked 6man about the charter item, nor the answer that 6man 
provided.

On the second, the issue for holding up posting of the adopted document 
(and potentially holding up last call on the document, assuming as I do 
that we will get that far), is about this document.  Which is about 
C-SIDs.  If 6man chooses to address the larger SID question in their 
document, that is their call.  Our dependence is on the C-SID part of 
that.  I have been told C-SID will be dealt with in that.  In the 
unlikely event that no document dealing with the relationship of C-SIDs 
to RFC 4291 appears, then we will work out how to get one, as that is 
what we need to advance work on this compression document.

Yours,
Joel

On 11/5/2021 10:17 AM, Darren Dukes (ddukes) wrote:
> 1 – The second bullet (beginning with “As reminded”) should include the 
> link to the questions asked of the 6man chairs/ADs 
> https://mailarchive.ietf.org/arch/msg/ipv6/merG-RgtA3shloDqpyRk-xWHniw/ 
> <https://mailarchive.ietf.org/arch/msg/ipv6/merG-RgtA3shloDqpyRk-xWHniw/> and 
> their response 
> https://mailarchive.ietf.org/arch/msg/spring/z_3nbdwVQ_V66ZqkV-ZhIg7kakA/ <https://mailarchive.ietf.org/arch/msg/ipv6/3k8_1JgKGtnLsfsVf65qvReNuLc/>
> 
> 2 – About the requirements for a document identifying the “relationship 
> of C-SIDs with RFC 4291.”.  The word “C-SIDs” should be changed to “SRv6 
> SIDs” in the sentences when such a document is discussed.  This would 
> better match the 6man chairs/ADs response:
> 
> “To summarize: we do not object to C-SID behavior work continuing in 
> SPRING, we simply need a clarifying document described in [A].”
> 
> And
> 
> https://mailarchive.ietf.org/arch/msg/spring/-tvDZ5biRXvfLlyJ8IMtX-7EUp4/<https://mailarchive.ietf.org/arch/msg/spring/-tvDZ5biRXvfLlyJ8IMtX-7EUp4/>
> https://mailarchive.ietf.org/arch/msg/spring/vCc9Ckvwu5HA-RCleV712dsA5OA/<https://mailarchive.ietf.org/arch/msg/spring/vCc9Ckvwu5HA-RCleV712dsA5OA/>
> https://mailarchive.ietf.org/arch/msg/spring/vCc9Ckvwu5HA-RCleV712dsA5OA/<https://mailarchive.ietf.org/arch/msg/spring/vCc9Ckvwu5HA-RCleV712dsA5OA/>.
> https://www.ietf.org/mailman/listinfo/spring<https://www.ietf.org/mailman/listinfo/spring>
>

---

From: Robert Raszuk <[email-masked]>
Date: Fri, 5 Nov 2021 19:46:43 +0100

Dear Joel,

It is clear that your personal view of the relevance of SID ARG content to
IPv6 address differs from the view of many WG participants.

To be very clear - whatever SPRING WG decides to put into SID ARG field it
is completely orthogonal to IPv6 community as it has completely nothing to
do with IPv6 addressing architecture. That is based on approved RFC 8986.

We can call it c-sid, sid++, sid/4, rainbow and I am sure the list will
grow with time. The entire concept of SRv6 NP is that the data plane will
also need to be programmable. And yes at segment endpoints to properly
process SRv6 packets plain IPv6 data plane support is not sufficient. SRv6
data plane must be in place.

I think looking from the beginning of this discussions to me it is obvious
that SRv6 should not be positioned as extension of IPv6 data plane. To me
this is new data plane however made in a backwards compatible way with IPv6
for the transit nodes.

Kind regards,
Robert

On Fri, Nov 5, 2021 at 6:39 PM Joel M. Halpern <[email-masked]> wrote:

> https://mailarchive.ietf.org/arch/msg/spring/z_3nbdwVQ_V66ZqkV-ZhIg7kakA/
> <https://mailarchive.ietf.org/arch/msg/ipv6/3k8_1JgKGtnLsfsVf65qvReNuLc/>
> >
> https://mailarchive.ietf.org/arch/msg/spring/-tvDZ5biRXvfLlyJ8IMtX-7EUp4/<
> https://mailarchive.ietf.org/arch/msg/spring/-tvDZ5biRXvfLlyJ8IMtX-7EUp4/>
> https://mailarchive.ietf.org/arch/msg/spring/vCc9Ckvwu5HA-RCleV712dsA5OA/<
> https://mailarchive.ietf.org/arch/msg/spring/vCc9Ckvwu5HA-RCleV712dsA5OA/>
> https://mailarchive.ietf.org/arch/msg/spring/vCc9Ckvwu5HA-RCleV712dsA5OA/<
> >.
> > https://www.ietf.org/mailman/listinfo/spring<
> https://www.ietf.org/mailman/listinfo/spring>
> >
>

---

From: "Joel M. Halpern" <[email-masked]>
Date: Fri, 5 Nov 2021 15:01:38 -0400

Robert, as far as I can tell, no one other than you believes that "SRv6 
should not be positioned as extension of IPv6 data plane."  The SRH was 
approved by 6man, whose only remit is the IPv6 data plane.   Many 
descriptions of SRv6 describe it as providing segment routing to IPv6. 
  And all SRv6 packets when carried on Ethernet use the IPv6 Ethertype.

By any measure I can see, SRv6 is part of IPv6.  Just as SR-MPLS is part 
of MPLS.  It is relevant that SRv6 in my understanding changes the 
forwarding behavior of IPv6, and C-SID changes it significantly more. 
But that doe snot mean it is not an extension of IPv6.

More importantly in terms of the adoption call, the issue of the 
relationship between C-SIDs and RFC 4291 was raised in such a way that I 
concluded that even if I did not agree with the issue I would have to 
recognize that it needed to be addressed.

Yours,
Joel

On 11/5/2021 2:46 PM, Robert Raszuk wrote:
> Dear Joel,
> 
> It is clear that your personal view of the relevance of SID ARG content 
> to IPv6 address differs from the view of many WG participants.
> 
> To be very clear - whatever SPRING WG decides to put into SID ARG field 
> it is completely orthogonal to IPv6 community as it has completely 
> nothing to do with IPv6 addressing architecture. That is based on 
> approved RFC 8986.
> 
> grow with time. The entire concept of SRv6 NP is that the data plane 
> will also need to be programmable. And yes at segment endpoints to 
> properly process SRv6 packets plain IPv6 data plane support is not 
> sufficient. SRv6 data plane must be in place.
> 
> I think looking from the beginning of this discussions to me it is 
> obvious that SRv6 should not be positioned as extension of IPv6 data 
> plane. To me this is new data plane however made in a 
> backwards compatible way with IPv6 for the transit nodes.
> 
> Kind regards,
> Robert
> 
> 
> On Fri, Nov 5, 2021 at 6:39 PM Joel M. Halpern <[email-masked] 
> <mailto:[email-masked]>> wrote:
> 
>      > I want to make note of two suggestions, I’m copying the list for
>     record
>      > keeping only.
>      >
>     <https://mailarchive.ietf.org/arch/msg/ipv6/merG-RgtA3shloDqpyRk-xWHniw/>
> 
>      >
>     <https://mailarchive.ietf.org/arch/msg/ipv6/merG-RgtA3shloDqpyRk-xWHniw/
>     <https://mailarchive.ietf.org/arch/msg/ipv6/merG-RgtA3shloDqpyRk-xWHniw/>>
>     and
>      > their response
>      >
>     <https://mailarchive.ietf.org/arch/msg/spring/z_3nbdwVQ_V66ZqkV-ZhIg7kakA/>
>     <https://mailarchive.ietf.org/arch/msg/ipv6/3k8_1JgKGtnLsfsVf65qvReNuLc/
>     <https://mailarchive.ietf.org/arch/msg/ipv6/3k8_1JgKGtnLsfsVf65qvReNuLc/>>
>      >
>      > On 2021-10-31, 11:37 AM, "spring" <[email-masked]
>     <mailto:[email-masked]>> wrote:
>      >
>      >
>      >
>     <https://mailarchive.ietf.org/arch/msg/spring/-tvDZ5biRXvfLlyJ8IMtX-7EUp4/><https://mailarchive.ietf.org/arch/msg/spring/-tvDZ5biRXvfLlyJ8IMtX-7EUp4/
>     <https://mailarchive.ietf.org/arch/msg/spring/-tvDZ5biRXvfLlyJ8IMtX-7EUp4/>>
>     <https://mailarchive.ietf.org/arch/msg/spring/vCc9Ckvwu5HA-RCleV712dsA5OA/><https://mailarchive.ietf.org/arch/msg/spring/vCc9Ckvwu5HA-RCleV712dsA5OA/
>     <https://mailarchive.ietf.org/arch/msg/spring/vCc9Ckvwu5HA-RCleV712dsA5OA/>>
>     <https://mailarchive.ietf.org/arch/msg/spring/vCc9Ckvwu5HA-RCleV712dsA5OA/><https://mailarchive.ietf.org/arch/msg/spring/vCc9Ckvwu5HA-RCleV712dsA5OA/
>     <https://mailarchive.ietf.org/arch/msg/spring/vCc9Ckvwu5HA-RCleV712dsA5OA/>>.
>      > [email-masked] <mailto:[email-masked]>
>     <https://www.ietf.org/mailman/listinfo/spring><https://www.ietf.org/mailman/listinfo/spring
>     <https://www.ietf.org/mailman/listinfo/spring>>
>      >
> 
>     [email-masked] <mailto:[email-masked]>
>     <https://www.ietf.org/mailman/listinfo/spring>
>

---

From: Robert Raszuk <[email-masked]>
Date: Fri, 5 Nov 2021 20:26:12 +0100

Ok Joel - final question from me on this.

Do you believe that **SRv6 data plane** exists or it does not exist and all
we are dealing with is **IPv6** data plane** with some SRv6 extensions made
to it ? Notice that the SPRING WG charter clearly talks about SRv6 data
plane(s).

I think this is fundamental and not only for C-SID draft, but for any other
future SPRING WG document to be produced.

Thx,
R.

On Fri, Nov 5, 2021 at 8:01 PM Joel M. Halpern <[email-masked]> wrote:

> >     <
> https://mailarchive.ietf.org/arch/msg/ipv6/merG-RgtA3shloDqpyRk-xWHniw/>
> >
> >      >
> >     <
> >     <
> https://mailarchive.ietf.org/arch/msg/ipv6/merG-RgtA3shloDqpyRk-xWHniw/>>
> >     and
> >      > their response
> >      >
> >
> >     <
> https://mailarchive.ietf.org/arch/msg/spring/z_3nbdwVQ_V66ZqkV-ZhIg7kakA/>
> >     <
> https://mailarchive.ietf.org/arch/msg/ipv6/3k8_1JgKGtnLsfsVf65qvReNuLc/
> >     <
> https://mailarchive.ietf.org/arch/msg/ipv6/3k8_1JgKGtnLsfsVf65qvReNuLc/>>
> >      >
> >      > “[A] A separate 6MAN document to clarify and categorize SRv6 SIDs
> is
> >      > needed.”
> >      >
> >      > Thanks
> >      >
> >      > Darren
> >      >
> >     <
> ><
> >     <
> >     <
> ><
> >     <
> >     <
> ><
> >     <
> >     <https://www.ietf.org/mailman/listinfo/spring><

---

From: Joel Halpern Direct <[email-masked]>
Date: Fri, 5 Nov 2021 15:34:13 -0400

As I understand the words, the SRv6 dataplane is that part of the IPv6 
dataplane that is using SRv6.  (If it were not for reduced mode, it 
would be that part that uses the SRH.)

Yours,
Joel

On 11/5/2021 3:26 PM, Robert Raszuk wrote:
> Do you believe that **SRv6 data plane** exists or it does not exist and 
> all we are dealing with is **IPv6**data plane** with some SRv6 
> extensions made to it ? Notice that the SPRING WG charter clearly talks 
> about SRv6 data plane(s).
> 
> I think this is fundamental and not only for C-SID draft, but for any 
> other future SPRING WG document to be produced.
> 
> Thx,
> R.
> 
> 
> 
> 
> 
> 
> 
> On Fri, Nov 5, 2021 at 8:01 PM Joel M. Halpern <[email-masked] 
>      > On Fri, Nov 5, 2021 at 6:39 PM Joel M. Halpern
>     <[email-masked] <mailto:[email-masked]>
>      > <mailto:[email-masked] <mailto:[email-masked]>>> wrote:
>      >
>      >      > Hello Joel,
>      >      >
>      >      > I want to make note of two suggestions, I’m copying the
>     list for
>      >     record
>      >      > keeping only.
>      >      >
>      >      > 1 – The second bullet (beginning with “As reminded”) should
>      >     include the
>      >      > link to the questions asked of the 6man chairs/ADs
>      >      >
>      >
>       <https://mailarchive.ietf.org/arch/msg/ipv6/merG-RgtA3shloDqpyRk-xWHniw/ <https://mailarchive.ietf.org/arch/msg/ipv6/merG-RgtA3shloDqpyRk-xWHniw/>>
>      >
>      >      >
>      >   
>       <https://mailarchive.ietf.org/arch/msg/ipv6/merG-RgtA3shloDqpyRk-xWHniw/ <https://mailarchive.ietf.org/arch/msg/ipv6/merG-RgtA3shloDqpyRk-xWHniw/>
>      >   
>       <https://mailarchive.ietf.org/arch/msg/ipv6/merG-RgtA3shloDqpyRk-xWHniw/ <https://mailarchive.ietf.org/arch/msg/ipv6/merG-RgtA3shloDqpyRk-xWHniw/>>>
>      >     and
>      >      > their response
>      >      >
>      >
>       <https://mailarchive.ietf.org/arch/msg/spring/z_3nbdwVQ_V66ZqkV-ZhIg7kakA/ <https://mailarchive.ietf.org/arch/msg/spring/z_3nbdwVQ_V66ZqkV-ZhIg7kakA/>>
>      >   
>       <https://mailarchive.ietf.org/arch/msg/ipv6/3k8_1JgKGtnLsfsVf65qvReNuLc/ <https://mailarchive.ietf.org/arch/msg/ipv6/3k8_1JgKGtnLsfsVf65qvReNuLc/>
>      >   
>       <https://mailarchive.ietf.org/arch/msg/ipv6/3k8_1JgKGtnLsfsVf65qvReNuLc/ <https://mailarchive.ietf.org/arch/msg/ipv6/3k8_1JgKGtnLsfsVf65qvReNuLc/>>>
>      >      >
>      >      > 2 – About the requirements for a document identifying the
>      >     “relationship
>      >      > of C-SIDs with RFC 4291.”.  The word “C-SIDs” should be
>     changed
>      >     to “SRv6
>      >      > SIDs” in the sentences when such a document is discussed. 
>     This
>      >     would
>      >      > better match the 6man chairs/ADs response:
>      >      >
>      >      > “To summarize: we do not object to C-SID behavior work
>     continuing in
>      >      > SPRING, we simply need a clarifying document described in
>     [A].”
>      >      >
>      >      > And
>      >      >
>      >      > “[A] A separate 6MAN document to clarify and categorize
>     SRv6 SIDs is
>      >      > needed.”
>      >      >
>      >      > Thanks
>      >      >
>      >      > Darren
>      >      >
>      >      > On 2021-10-31, 11:37 AM, "spring" <[email-masked]
>     <mailto:[email-masked]>
>      >     <mailto:[email-masked]
>     <mailto:[email-masked]>>> wrote:
>      >      >
>      >      >
>      >      >
>      >      > 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/>
>      >   
>       <https://mailarchive.ietf.org/arch/msg/spring/-tvDZ5biRXvfLlyJ8IMtX-7EUp4/ <https://mailarchive.ietf.org/arch/msg/spring/-tvDZ5biRXvfLlyJ8IMtX-7EUp4/>><https://mailarchive.ietf.org/arch/msg/spring/-tvDZ5biRXvfLlyJ8IMtX-7EUp4/ <https://mailarchive.ietf.org/arch/msg/spring/-tvDZ5biRXvfLlyJ8IMtX-7EUp4/>
>      >   
>       <https://mailarchive.ietf.org/arch/msg/spring/-tvDZ5biRXvfLlyJ8IMtX-7EUp4/ <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/>
>      >   
>       <https://mailarchive.ietf.org/arch/msg/spring/vCc9Ckvwu5HA-RCleV712dsA5OA/ <https://mailarchive.ietf.org/arch/msg/spring/vCc9Ckvwu5HA-RCleV712dsA5OA/>><https://mailarchive.ietf.org/arch/msg/spring/vCc9Ckvwu5HA-RCleV712dsA5OA/ <https://mailarchive.ietf.org/arch/msg/spring/vCc9Ckvwu5HA-RCleV712dsA5OA/>
>      >   
>       <https://mailarchive.ietf.org/arch/msg/spring/vCc9Ckvwu5HA-RCleV712dsA5OA/ <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/>
>      >   
>       <https://mailarchive.ietf.org/arch/msg/spring/vCc9Ckvwu5HA-RCleV712dsA5OA/ <https://mailarchive.ietf.org/arch/msg/spring/vCc9Ckvwu5HA-RCleV712dsA5OA/>><https://mailarchive.ietf.org/arch/msg/spring/vCc9Ckvwu5HA-RCleV712dsA5OA/ <https://mailarchive.ietf.org/arch/msg/spring/vCc9Ckvwu5HA-RCleV712dsA5OA/>
>      >   
>       <https://mailarchive.ietf.org/arch/msg/spring/vCc9Ckvwu5HA-RCleV712dsA5OA/ <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.
>      >      >
>      >      > _______________________________________________
>      >      > spring mailing list
>      >      > [email-masked] <mailto:[email-masked]>
>     <mailto:[email-masked] <mailto:[email-masked]>>
>      >      > https://www.ietf.org/mailman/listinfo/spring
>      >     <https://www.ietf.org/mailman/listinfo/spring
>     <https://www.ietf.org/mailman/listinfo/spring>><https://www.ietf.org/mailman/listinfo/spring
>      >     <https://www.ietf.org/mailman/listinfo/spring
>     <https://www.ietf.org/mailman/listinfo/spring>>>
>      >      >
>      >
>      > [email-masked] <mailto:[email-masked]> <mailto:[email-masked]
>     <mailto:[email-masked]>>
>      >     <https://www.ietf.org/mailman/listinfo/spring

---

From: "Darren Dukes (ddukes)" <[email-masked]>
Date: Sat, 6 Nov 2021 04:11:15 +0000

Hi Joel,

There may be some misunderstandings. Let me try to clarify.

My first suggestion was to add links to the Second bullet in the appendix. Can you read it again please? The response appears unrelated.

Regarding the response to my second suggestion, I suggest we should be technically correct in the issue description and use “the relationship of SRv6 Sid’s to rfc4291”. While SPRINGs concern was CSID, we asked 6man chairs and ADs about that, and the response was as quoted - a clarifying document for SRv6 SIDs. If we are to track this, we should reflect the answers given and remaining issue, would you agree?

Sincerely
  Darren.
________________________________
From: Joel M. Halpern <[email-masked]>
Sent: Friday, November 5, 2021 1:39 PM
To: Darren Dukes (ddukes); [email-masked]
Subject: Re: [spring] Conclusion of Adoption call for draft-filsfilscheng-spring-srv6-srh-compression

Yours,
Joel

---

From: "Joel M. Halpern" <[email-masked]>
Date: Sat, 6 Nov 2021 01:05:43 -0400

I presume I am misunderstanding something about your requests.

Your first request is that I add to the second open issue links to the 
question I asked 6man, and the answer they provided.  I replied that was 
inappropriate as the topic which leads to the second open issue is not 
that question and answer (which was based on the SPRING charter text), 
but rather the open issue is based on the SPRING policy the SPRING 
chairs described last March, to which I linked.  Since the open issue 
itself is not based on the Q&A, I don't understand why you want that 
exchanged linked from the issue.  You now say that my answer is 
non-responsive.  Since it appears responsive to me, I do not understand 
your comment.

(At this point I should also add that I hope that my efforts to find 
different ways to explain this does not create confusion by accident. 
The above and the below are not in intended in any way to change either 
by prior answer, or more importantly the original announcement.)

Similarly, you then assert that it is technically correct to say that 
the technical issue driving the open issue for this document is the 
general issue of SID compatibility with RFC 4291.  I understand that 
6man is looking at the general issue.  However, the block for this 
document is the C-SID relationship.   It may be that the 6man more 
general work will also affect this document.  If so, we will deal with 
that.  But the blocking question that I understand from the SPRING 
policy is the interaction of this document with RFC 4291.

You seem to be inviting me to declare a halt on all SRv6 related work 
until 6man makes progress.  As that question is not relevant to this 
document, I am not going there.

Given that you chose to repeat your questions, as I said above I presume 
you see another perspective.  If you care to explain, I will listen. 
But I do not currently see any reason to change the text requested for 
the open issues section.

Yours,
Joel

On 11/6/2021 12:11 AM, Darren Dukes (ddukes) wrote:
> My first suggestion was to add links to the Second bullet in the 
> appendix. Can you read it again please? The response appears unrelated.
> 
> Regarding the response to my second suggestion, I suggest we should be 
> technically correct in the issue description and use “the relationship 
> of SRv6 Sid’s to rfc4291”. While SPRINGs concern was CSID, we asked 6man 
> chairs and ADs about that, and the response was as quoted - a clarifying 
> document for SRv6 SIDs. If we are to track this, we should reflect the 
> answers given and remaining issue, would you agree?
> 
> Sincerely
>    Darren.
> ------------------------------------------------------------------------
> *From:* Joel M. Halpern <[email-masked]>
> *Sent:* Friday, November 5, 2021 1:39 PM
> *To:* Darren Dukes (ddukes); [email-masked]
> *Subject:* Re: [spring] Conclusion of Adoption call for 
> draft-filsfilscheng-spring-srv6-srh-compression
>> https://mailarchive.ietf.org/arch/msg/spring/z_3nbdwVQ_V66ZqkV-ZhIg7kakA/ <https://mailarchive.ietf.org/arch/msg/spring/z_3nbdwVQ_V66ZqkV-ZhIg7kakA/> 
> <https://mailarchive.ietf.org/arch/msg/spring/-tvDZ5biRXvfLlyJ8IMtX-7EUp4/<https://mailarchive.ietf.org/arch/msg/spring/-tvDZ5biRXvfLlyJ8IMtX-7EUp4/>>
> <https://mailarchive.ietf.org/arch/msg/spring/vCc9Ckvwu5HA-RCleV712dsA5OA/<https://mailarchive.ietf.org/arch/msg/spring/vCc9Ckvwu5HA-RCleV712dsA5OA/>>
> <https://mailarchive.ietf.org/arch/msg/spring/vCc9Ckvwu5HA-RCleV712dsA5OA/<https://mailarchive.ietf.org/arch/msg/spring/vCc9Ckvwu5HA-RCleV712dsA5OA/>>.
> <https://www.ietf.org/mailman/listinfo/spring<https://www.ietf.org/mailman/listinfo/spring>>
>>