Hi Zahed, I have updated the charter text so if you are happy please update your ballot accordingly.
Jim From: Zaheduzzaman Sarker <zahed.sarker.i...@gmail.com> Date: Wednesday, November 27, 2024 at 11:42 AM To: Alvaro Retana <aretana.i...@gmail.com> Cc: spring@ietf.org <spring@ietf.org>, The IESG <i...@ietf.org>, spring-cha...@ietf.org <spring-cha...@ietf.org> Subject: Re: Zaheduzzaman Sarker's Block on charter-ietf-spring-02-01: (with BLOCK) Looks excellent to me. Thanks Alvaro!! // Zahed On Wed, 27 Nov 2024 at 17:06, Alvaro Retana <aretana.i...@gmail.com<mailto:aretana.i...@gmail.com>> wrote: On November 27, 2024 at 3:54:14 AM, Zaheduzzaman Sarker wrote: Zahed: Hi! ... > I think the following would be helpful to understand the intention better . > it's a suggestion only and should depict what I am after, free to > amend/reject. > > -- The SPRING WG is responsible for protocol-independent general architecture > or framework work. The protocol specific modification of, or extension to the > existing architecture, data planes, or control or management plane protocols > should be carried out in the WGs responsible for the same. Those work would > be benefited by coordinating with the spring working group, if necessary, > those work can be carried out in the SPRING WG after agreement with all the > relevant WGs chairs and responsible ADs. -- The paragraph with the long sentence talks about avoiding modifications, while the next paragraph is about scoping. Suggestion: OLD> The work in the SPRING WG should avoid modification to existing data planes that would make them incompatible with existing deployments. Where possible, existing control and management plane protocols must be used within existing architectures to implement the SPRING function. Any modification of -or extension to- existing architectures, data planes, or control or management plane protocols should be carried out in the WGs responsible for the architecture, data plane, or control or management plane protocol being modified and in coordination with the SPRING WG, but may be done in SPRING WG after agreement with all the relevant WG chairs and responsible Area Directors. The SPRING WG defines procedures that allow an SR node to steer a packet through an SR Policy instantiated as an ordered list of instructions called segments without needing per-path state information at transit nodes. A network comprising only SR nodes can achieve full path control (through loose or strict path specification). However, SR nodes must interoperate through loose routing in existing networks. NEW> The work in the SPRING WG should avoid modification to existing data planes that would make them incompatible with existing deployments. Existing protocols must be used within existing architectures to implement the SPRING function where possible. Any modification or extension of existing architectures, data planes, or protocols should be carried out in the WGs responsible for them and in coordination with the SPRING WG. Alternatively, after agreement among the relevant WG chairs and Area Directors, such work may be done in the SPRING WG. The SPRING WG defines protocol-independent procedures that allow an SR node to steer a packet... I simplified the initial paragraph following your suggestions and added the protocol-independent part to the second one. Thoughts? Thanks! Alvaro.
_______________________________________________ spring mailing list -- spring@ietf.org To unsubscribe send an email to spring-le...@ietf.org
