Thanks for the updates, now it is a YES from me!! //Zahed
On Sun, Dec 1, 2024 at 10:48 PM James Guichard < james.n.guich...@futurewei.com> wrote: > 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> > 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
