Dear WG chairs, I agree with Greg Mirsky that the adoption guidelines are confusing and contradictory.
Bullet #1 states that by expressing support for adoption the WG member is agreeing to adoption of a document that has multiple SRv6 compression solutions. On the other hand bullet #4 states that if the draft is adopted that the following text excerpt below should be added to as an open issue 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.". This sentence is very confusing as the WG chairs agree that the WG has consensus on a single solution to avoid interoperability, and the WG chairs acknowledge that some WG members feel that the multiple flavors are actually multiple solutions, how is it possible that the WG would address that this is as valid and coherent with one date plane solution as the objective. The valid and coherent part of how a multiple data plane solution or flavor meets the single data plane objective is contradictory. I believe what is stated here by the chairs is exactly what should have been cleared up prior to the adoption call, but now as the adoption call has started would be cleared up during the adoption call process. This is somewhat of a chess game as to which way to have proceeded, but I think getting this cleared up prior to the call for adoption would have been better for the WG. All WG members that feel strongly that the two endpoint flavors are two distinctly different solutions will stick to their guns and support not adopting the document. All WG members that are Ok with two solutions versus a single SRV6 compression solution will chose to adopt the draft. The down side of not resolving this issue prior to adoption call is that there is a chance the many that felt strongly for a single solution as risk of interoperability issues as all vendors due to cost may not want to implement multiple compression solutions and may not all pick the same compression solution. So there could be a unanimous vote to not adopt as this goes against the WG consensus on a single data plane solution. I agree that is not a major risk going this route as the draft would be kicked back to the authors to revise and pick one of the flavors to put forward for adoption. The flip side is we are back to the drawing board with the DT on WG consensus on a compression solution to agree to for an adoption call. Kind Regards Gyan On Fri, Oct 1, 2021 at 4:55 PM Tony Li <tony...@tony.li> wrote: > > +1 > > I object to the adoption. > > Tony > > > On Oct 1, 2021, at 1:43 PM, Andrew Alston < > Andrew.Alston=40liquidtelecom....@dmarc.ietf.org> wrote: > > Just to add to this, > > I am one of the people who clearly stated that I didn’t think a single > solution was the right answer here – and I stated my reasoning clearly on > this list. I still believe that – however – I recognize that the > foundation of the IETF is found in the bottom up consensus approach – and > when the working group has demonstrated such clear consensus – to defy that > – is to defy what makes the IETF the IETF. > > So – While I still believe in multiple solutions – irrespective of that – > I find this call appalling – because as much as I believe in multiple > solutions – the working group consensus should be sacrosanct. > > Andrew > > > > *From: *Andrew Alston <andrew.als...@liquidtelecom.com> > *Date: *Friday, 1 October 2021 at 23:21 > *To: *James Guichard <james.n.guich...@futurewei.com>, SPRING WG < > spring@ietf.org> > *Cc: *spring-cha...@ietf.org <spring-cha...@ietf.org> > *Subject: *Re: WG Adoption call for > https://datatracker.ietf.org/doc/draft-filsfilscheng-spring-srv6-srh-compression/ > 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> on behalf of James Guichard < > james.n.guich...@futurewei.com> > *Date: *Friday, 1 October 2021 at 17:05 > *To: *SPRING WG <spring@ietf.org> > *Cc: *spring-cha...@ietf.org <spring-cha...@ietf.org> > *Subject: *[spring] WG Adoption call for > https://datatracker.ietf.org/doc/draft-filsfilscheng-spring-srv6-srh-compression/ > 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/ > 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/ > 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 > > > _______________________________________________ > spring mailing list > spring@ietf.org > https://www.ietf.org/mailman/listinfo/spring > -- <http://www.verizon.com/> *Gyan Mishra* *Network Solutions A**rchitect * *Email gyan.s.mis...@verizon.com <gyan.s.mis...@verizon.com>* *M 301 502-1347*
_______________________________________________ spring mailing list spring@ietf.org https://www.ietf.org/mailman/listinfo/spring
