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 <[email protected]> On Behalf Of James Guichard
Sent: Friday, October 1, 2021 5:05 PM
To: SPRING WG <[email protected]>
Cc: [email protected]
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:
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
[email protected]
https://www.ietf.org/mailman/listinfo/spring
