+1

srihari…


On 06/10/21, 12:26 AM spring on behalf of Ron Bonica from 
spring-boun...@ietf.org<mailto:spring-boun...@ietf.org> on behalf of 
rbonica=40juniper....@dmarc.ietf.org<mailto:rbonica=40juniper....@dmarc.ietf.org>
 said >

[External Email. Be cautious of content]

Jim,

The call for adoption has already been posted. There is no way to put that 
toothpaste back into its tube. However, I strongly recommend against such calls 
for adoption in the future.

Normally, the authors of a document are encouraged to answer technical 
questions as a condition of adoption. Bullet points 1, 2, and 4 in the call for 
adoption defer that requirement until WG last call. Could this be why technical 
questions are not being addressed during the call for adoption.

In some extreme conditions, it may be necessary to modify the usual call for 
adoption procedure. But these exceptional conditions have not been articulated.

It is unfortunate that two of the three working group chairs are also 
co-authors of the draft. While there may not have been any impropriety, the 
appearance of impropriety is difficult to avoid.

                                                                                
               Ron




Juniper Business Use Only
From: spring <spring-boun...@ietf.org> On Behalf Of James Guichard
Sent: Monday, October 4, 2021 11:10 AM
To: ext-andrew.als...@liquidtelecom.com <andrew.als...@liquidtelecom.com>; 
SPRING WG <spring@ietf.org>
Cc: spring-cha...@ietf.org
Subject: Re: [spring] WG Adoption call for 
https://datatracker.ietf.org/doc/draft-filsfilscheng-spring-srv6-srh-compression/

[External Email. Be cautious of content]

Andrew,

As stated in our email of September 9th, the chairs communicated that the 
working group reached rough (quite clear) consensus for standardizing one data 
plane solution to compress segment routing over IPv6. In addition to this there 
was an inclination toward using the CSID document as the basis for our work in 
this area. The chairs recognized that there was however disagreement as to 
whether this document, having multiple SRv6 EndPoint behaviors, could be 
considered consistent with the working group consensus for a single data plane 
solution. This issue quite clearly needed to be addressed, and the chairs, 
recognizing that the working group is keen to make progress in this area, had 
the option of trying to resolve the issue prior to issuing an adoption call, or 
give the working group the opportunity to express their opinions as part of a 
call for adoption.

Those who feel that we need to resolve the consistency issue before adoption, 
as with those who think this is not a good basis for the WG work, are free and 
expected to object to the WG adopting the document. That is distinct from 
objecting to the chairs issuing the adoption call.

In essence, the chairs have combined the question of when to resolve 
consistency and the question of whether this document is a good basis for the 
WG into one call.

Yours,

Jim, Bruno & Joel


From: Andrew Alston 
<andrew.als...@liquidtelecom.com<mailto:andrew.als...@liquidtelecom.com>>
Sent: Friday, October 1, 2021 4:21 PM
To: James Guichard 
<james.n.guich...@futurewei.com<mailto:james.n.guich...@futurewei.com>>; SPRING 
WG <spring@ietf.org<mailto:spring@ietf.org>>
Cc: spring-cha...@ietf.org<mailto:spring-cha...@ietf.org>
Subject: Re: WG Adoption call for 
https://datatracker.ietf.org/doc/draft-filsfilscheng-spring-srv6-srh-compression/<https://urldefense.com/v3/__https:/datatracker.ietf.org/doc/draft-filsfilscheng-spring-srv6-srh-compression/__;!!NEt6yMaO-gk!Wo2L5Y1OVAJbbyDPRZ7dWsotqBhY-LONV9NDUcg4SQ5bQ6nh9yrYbjvxGq8IwyM$>

Sorry – but – I’m a little confused here.

Because the way I look at this – the working group clearly stated that they 
wished for a single behavior – and this – does not deliver that – it is two 
separate behaviors.  As such – I see this call for adoption – irrespective of 
the merits or lack thereof of the draft, as a clear defiance of the stated will 
of the working group.

This is simply does not fit into the definition of bottom up approach in my 
opinion – and if this is the way that the chairs wish to proceed – then the 
only way to do that and still fit within the bottom up approach is to first ask 
this working group for its consensus to deviate from the single behacvior 
approach that the working group agreed to.

As such – I must  strongly and unequivocally object to this call for adoption

Andrew

From: spring <spring-boun...@ietf.org<mailto:spring-boun...@ietf.org>> on 
behalf of James Guichard 
<james.n.guich...@futurewei.com<mailto:james.n.guich...@futurewei.com>>
Date: Friday, 1 October 2021 at 17:05
To: SPRING WG <spring@ietf.org<mailto:spring@ietf.org>>
Cc: spring-cha...@ietf.org<mailto:spring-cha...@ietf.org> 
<spring-cha...@ietf.org<mailto:spring-cha...@ietf.org>>
Subject: [spring] WG Adoption call for 
https://datatracker.ietf.org/doc/draft-filsfilscheng-spring-srv6-srh-compression/<https://urldefense.com/v3/__https:/datatracker.ietf.org/doc/draft-filsfilscheng-spring-srv6-srh-compression/__;!!NEt6yMaO-gk!UgHfCuOO1iLosaFP2WimwZG0wZs8K4M207wL2s4XLjVA17cIwtD6MEEk4Y63Kp0-$>
Dear WG:

The chairs would like to express their appreciation for all the responses 
received to our emails with reference to how the working group wishes to move 
forward with respect to a solution for SRv6 compression.

The apparent inclination of the working group is to use 
https://datatracker.ietf.org/doc/draft-filsfilscheng-spring-srv6-srh-compression/<https://urldefense.com/v3/__https:/nam11.safelinks.protection.outlook.com/?url=https*3A*2F*2Fdatatracker.ietf.org*2Fdoc*2Fdraft-filsfilscheng-spring-srv6-srh-compression*2F&data=04*7C01*7Cjames.n.guichard*40futurewei.com*7C5e0d0fdb84404b53517108d98519075f*7C0fee8ff2a3b240189c753a1d5591fedc*7C1*7C0*7C637687164816496052*7CUnknown*7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0*3D*7C1000&sdata=*2BVsL9*2BHgyiQLb7*2FoAY437Vek4bhHWMrl3KdoTPbAnGU*3D&reserved=0__;JSUlJSUlJSUlJSUlJSUlJSUlJSUlJQ!!NEt6yMaO-gk!UgHfCuOO1iLosaFP2WimwZG0wZs8K4M207wL2s4XLjVA17cIwtD6MEEk4fN3O0eM$>
 as the basis for its compression standardization work. That is part of what 
this email attempts to confirm.

Because of the above the chairs would like to issue a 2-week WG call for 
adoption ending October 15th for 
https://datatracker.ietf.org/doc/draft-filsfilscheng-spring-srv6-srh-compression/<https://urldefense.com/v3/__https:/nam11.safelinks.protection.outlook.com/?url=https*3A*2F*2Fdatatracker.ietf.org*2Fdoc*2Fdraft-filsfilscheng-spring-srv6-srh-compression*2F&data=04*7C01*7Cjames.n.guichard*40futurewei.com*7C5e0d0fdb84404b53517108d98519075f*7C0fee8ff2a3b240189c753a1d5591fedc*7C1*7C0*7C637687164816506046*7CUnknown*7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0*3D*7C1000&sdata=67Ot32mHEqz0JXCc01*2BuI6I1WPOzrwrCTEp3rp9cVE8*3D&reserved=0__;JSUlJSUlJSUlJSUlJSUlJSUlJSU!!NEt6yMaO-gk!UgHfCuOO1iLosaFP2WimwZG0wZs8K4M207wL2s4XLjVA17cIwtD6MEEk4dinC8Ry$>
 but with some clear guidelines as follows. By expressing support for adoption 
of this document you are fully aware of and are acknowledging that:


1.       The SPRING working group is adopting a document that has multiple SRv6 
Endpoint behaviors.

2.       The document is a “living” document; it may change as it goes through 
review and analysis by the SPRING working group.

3.       All open discussion points raised on our mailing list MUST be 
addressed BEFORE said document is allowed to progress from the working group to 
publication. A list of these discussion points will be documented in the WG 
document and maintained by the document editor in conjunction with the chairs.

4.       If this document is adopted by the working group, the chairs specify 
as part of the adoption call that the following text describing an open issue 
be added to the document in the above-described open issues section:

·         "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.".

Please consider the above guidelines as you decide on whether to support or not 
this WG adoption. Please express clearly your reasoning for support/non-support 
as well as any open discussion points you would like addressed should the 
document be adopted into the working group.

Thanks!

Jim, Bruno & Joel


_______________________________________________
spring mailing list
spring@ietf.org
https://www.ietf.org/mailman/listinfo/spring

Reply via email to