Andrew, To your point D and in response to others that have expressed the same concern.
The chairs have already discussed this and are very aware of, and will conform to, IETF process. As a co-author of the document in question I will of course recuse myself from the decision process for adoption of the document into the working group. This was never in question but let me make that point very clear now so that there is no further confusion or concern that the chairs will not follow standard procedures. Jim From: Andrew Alston <andrew.als...@liquidtelecom.com> Sent: Friday, October 8, 2021 11:23 AM To: James Guichard <james.n.guich...@futurewei.com>; SPRING WG <spring@ietf.org> Cc: spring-cha...@ietf.org Subject: RE: WG Adoption call for https://datatracker.ietf.org/doc/draft-filsfilscheng-spring-srv6-srh-compression/ Figured I would weigh in here once again - and try and summarize the way I see things. 1. The working group found consensus on a single behavior - this document contains 3 - if that consensus is to be changed - let it be changed by the working group before we walk down this path. 2. The charter of the spring working group is very clear - it states: Any modification of -or extension to- existing architectures, data planes, or control or management plane protocols should be carried out in the WGs responsible for the architecture, data plane, or control or management plane protocol being modified and in coordination with the SPRING WG, but may be done in SPRING WG after agreement with all the relevant WG chairs and responsible area directors. I have yet to see each agreement voiced by these parties. 1. There is technical dispute over the overloading of addresses and the use of IPv6 addresses in this manner, and if the excuse of limited domain is valid to get away with this - this has not been resolved 2. Two out of the three working group chairs who are actively involved in calling for the adoption of this document are co-authors of said document and have not recused themselves and stated they will not take part in decisions regarding its progression - the term - conflict of interest - was created for such situations 3. There have been suggestions on this list about splitting g-srv6 out - so that it can proceed, since it does NOT seem to run afoul of (B) and then if the working group sees fit to agree to change the view on single behavior, the csid parts could be processed separately should the chairs and ad's involved in the INT group agree - this suggestion has never had a full response or a reason why this is either impractical or should not go ahead - and under the definition of rough consensus therefore stands as an unaddressed issued. I am kinda shocked in a situation where almost any one of these points would be sufficient to act as a blocker - we are still walking down this path - I lament the lack of adherence to the bottom up approach that I am seeing here, and the disregard shown towards clear conflicts of interest, particularly where there are scenarios under which we could all progress that would resolve half of the issues above. Let us act in a way that is in adherence to the bottom-up approach, respects working group consensus, avoids conflicts of interest, follows the charter and eventually ends up in a place where distrust in the process is allowed to fester. Thanks Andrew From: spring <spring-boun...@ietf.org<mailto:spring-boun...@ietf.org>> On Behalf Of James Guichard Sent: Friday, October 1, 2021 5:05 PM To: SPRING WG <spring@ietf.org<mailto:spring@ietf.org>> Cc: 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/ 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://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%7Cd73ddcb23a224377961208d98a6f85d1%7C0fee8ff2a3b240189c753a1d5591fedc%7C1%7C0%7C637693033882878589%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=qVc1JtbYU0DHrh6XcbfMARecW8yLiL05zpsx1itMk2o%3D&reserved=0> 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://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%7Cd73ddcb23a224377961208d98a6f85d1%7C0fee8ff2a3b240189c753a1d5591fedc%7C1%7C0%7C637693033882888583%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=g%2FGrcz5fBZwMzF9dCU1GE%2BuuY3HBu%2BhUvRCsQmUuJFk%3D&reserved=0> 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
