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
