+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 > <mailto:andrew.als...@liquidtelecom.com>> > Date: Friday, 1 October 2021 at 23:21 > 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> > <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://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/ > > <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/ > > <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: > > The SPRING working group is adopting a document that has multiple SRv6 > Endpoint behaviors. > The document is a “living” document; it may change as it goes through review > and analysis by the SPRING working group. > 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. > 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
