Hi Joel, I understand that introducing "WG engagement" is a novel approach to focus the Working Group's efforts on documents actively being developed by engaged editors and contributors. It's a reasonable idea to give this a try and observe how the experiment unfolds.
However, I believe a charter must be precise and accurate in defining what is within or outside its scope. Without a formal understanding of what "WG engagement" entails, it remains unclear what the Working Group agrees to work on or exclude. I have no objection if the group uses a WG engagement metric to decide whether to adopt a draft. Nevertheless, I'm not convinced that ambiguous requirements should be part of a charter, especially when they are not clearly understood from the charter text itself. I find that descriptions on a wiki are volatile, with limited restrictions and change control mechanisms, whereas charters undergo a formal change control process. Not having a clear understanding of what "WG engagement" exactly means by reading the charter makes me uneasy about who decides what is in or out of scope. You wrote: "PS: I would comment on your concern about a confusing paragraph, but I am having trouble figuring otu what you changed. As that topic took us some work, clarification of old / new in some fashion would help me." GV> to update the WG a quick summary of the re-edit discussion Joel and myself had offline. Joel confirms that he could accept the suggested text proposed. Be well, G/ -----Original Message----- From: Joel Halpern <j...@joelhalpern.com> Sent: Thursday, November 14, 2024 3:51 PM To: Gunter van de Velde (Nokia) <gunter.van_de_ve...@nokia.com>; The IESG <i...@ietf.org> Cc: spring-cha...@ietf.org; spring@ietf.org Subject: Re: [spring] Gunter Van de Velde's Block on charter-ietf-spring-02-01: (with BLOCK and COMMENT) CAUTION: This is an external email. Please be very careful when clicking links or opening attachments. See the URL nok.it/ext for additional information. There appear to be three aspects to your concern about engagement. First, in order to be clear about what we mean, it is simply too long and detailed to include in the charter. Second, we have circulated to the WG and once the charter is approved will put in the WG wiki a detailed description of what we mean by engagement and how it relates to the various steps in WG policy. Third, and probably most important, the text about WG engagement is not intended in any way to expand the remit of the WG. Rather, it is a further limitation within the requirement that work be in-charter for the working group. Yours, Joel PS: I would comment on your concern about a confusing paragraph, but I am having trouble figuring otu what you changed. As that topic took us some work, clarification of old / new in some fashion would help me. Thanks. On 11/14/2024 8:54 AM, Gunter Van de Velde via Datatracker wrote: > Gunter Van de Velde has entered the following ballot position for > charter-ietf-spring-02-01: Block > > When responding, please keep the subject line intact and reply to all > email addresses included in the To and CC lines. (Feel free to cut > this introductory paragraph, however.) > > > > The document, along with other ballot positions, can be found here: > https://datatracker.ietf.org/doc/charter-ietf-spring/ > > > > ---------------------------------------------------------------------- > BLOCK: > ---------------------------------------------------------------------- > > "The SPRING WG will manage its specific work items based on WG > engagement and successful adoption." > > Without a formal understanding of what 'WG engagement' precisely > means, the boundaries of this text are unclear to me. It appears to be > an open interpretation that is highly susceptible to bias in > determining what constitutes 'WG engagement.' Without a clear > definition, I cannot dismiss the impression that the scope of SPRING work > items could potentially be manipulated. > > > ---------------------------------------------------------------------- > COMMENT: > ---------------------------------------------------------------------- > > For me the 2nd paragraph reads rather complex. What about following proposal: > > <>start proposed snip<> > Work within the SPRING Working Group (WG) should avoid modifications > to existing data planes that would render them incompatible with > current deployments. Where possible, existing control and management > plane protocols must be employed within established architectures to > implement the SPRING technology. Any modifications or extensions to > existing architectures, data planes, or control and management plane > protocols should be undertaken in the WGs responsible for those > architectures or protocols, and in coordination with the SPRING WG. > However, such modifications may be conducted within the SPRING WG > after obtaining agreement from all relevant WG chairs and the > responsible Area Directors. <>end proposed snip<> > > In the following charter text: > > " > By default, Segment Routing operates within a trusted domain and > requires the enforcement of a strict boundary to prevent Segment > Routing packets from entering the trusted domain [rfc8402]. > " > > Should it be documented that the purpose is to prevent packets from > entering and originating within the trusted domain? If we assume that > no external packets are allowed to enter, then what is the rationale > for preventing packets from leaving the trusted domain? Is there a use > case for packets exiting the trusted domain? > > > > _______________________________________________ > spring mailing list -- spring@ietf.org To unsubscribe send an email to > spring-le...@ietf.org _______________________________________________ spring mailing list -- spring@ietf.org To unsubscribe send an email to spring-le...@ietf.org
