Hi Joel, All, I may not have been as clear and accurate in my previous communication as I thought I was.
I agree that the proposed charter provides sufficient detail to understand what is within or outside its scope. We can consider that aspect of the discussion resolved. However, my concern is that "WG engagement" is not formally specified within the IETF framework. I understand the intention is to establish a SPRING wiki to clarify what is meant by "WG engagement." I am worried that a wiki lacks formal change control and does not have oversight from the IESG. It is also unclear whether "WG engagement" needs to be demonstrated by *all* front-page authors of a draft or if compliance by a single author (potentially being contributor on the last page) is sufficient. Additionally, who will be responsible for enforcing this? Could this approach be susceptible to manipulation, allowing a few individuals perceived as "WG engaged" to be added to all author lists indiscriminately? I am concerned that without formal recognition within the IETF of what "WG engagement" means and how it is enforced, there is potential for the procedure to be exploited, increasing the risk of appeals. I believe it is the responsibility of the SPRING chairs to ensure the effective operation of the Working Group in this regard, and I remain unconvinced that adding the line "The SPRING WG will manage its specific work items based on WG engagement and successful adoption" in the charter helps achieve this objective. G/ -----Original Message----- From: Joel Halpern <jmh.dir...@joelhalpern.com> Sent: Thursday, November 14, 2024 6:37 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 are two sides to the engagement text question. On one side, the text does indeed restrict what the WG will do. We are explicitly stating that the4 WG will not work on topics which do not have engageemnt, even if they are otherwise in the charter. That recognizes the reality that if the WG doesn't care then we as chairs can't meaningfully call rough consensus. Silence is not consent. It also recognizes teh reality that in this working group, there is no shortage of documents to work on. The other side is that engagement does not permit the WG to venture outside the work limits defined in the chart. Apparently, that is not clear. If you can suggest wording that will improve that, it would be helpful. We are not asking for a blank check. (I would hope that no working group makes such a request.) If this is not want you are concerned about, then I apologize and have to ak for clarification. Yours, Joel On 11/14/2024 12:14 PM, Gunter van de Velde (Nokia) wrote: > 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
