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
