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
