Agree with the objection. I don't see how this can progress in the current state and situation and decisions in this WG being made earlier on this.
Thanks, Melchior On Fri, Oct 1, 2021 at 10: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 >
_______________________________________________ spring mailing list spring@ietf.org https://www.ietf.org/mailman/listinfo/spring
