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 protected]>
*Sent:* Friday, November 5, 2021 1:39 PM
*To:* Darren Dukes (ddukes); [email protected]
*Subject:* Re: [spring] Conclusion of Adoption call for
draft-filsfilscheng-spring-srv6-srh-compression
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:
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/>>
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/>>
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 protected]> 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/>>
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/>>
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/>>.
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 protected]
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>>
