Hi Spring WG colleagues, I am really concerned at the attempts made to drag this WGLC out further. Let me summarize why.
1. The only sticking point that I am aware of (since I’ve been following all discussions closely) is about the claim being made by some members that PSP violates RFC8200. Most of the WG members that are actually developing and deploying SRv6 claim otherwise. In the end, it depends on how each person is interpreting the RFC8200 text. It’s been debated ad nauseam – there is nothing more/new that I see coming. It will continue to remain an endless loop unless a closure is called on it – question is when during the draft progression and who does this? 2. When all the arguments have already been answered during the earlier part of the WGLC, they are still being repeated as if they were not answered and new ones are being made up (and I fear this continues until WGLC closure). I see Pablo and others have answered them. So there is just (1) above that remains. 3. I even see recent attempts to associate PSP with the “insertion debate” and arguments like PMTUD (that is relevant for PSP). The authors of SRv6 have followed the spirit of the IETF consensus building process by removing all those aspects related to SRH insertion and placed them in a separate draft that is now contingent on its counterpart draft on SRH insertion achieving consensus in 6man. I can’t understand the motivation of those attempting to bring SRH insertion into the WGLC for this document – is it to slow down or derail SRv6 work in Spring? 4. Finally, there is this argument to move PSP out of this draft to allow the document to progress. Besides (1) there is no technical case being made for this request. PSP (though an optional flavor in the spec), is strongly desired by many of us working on SRv6 – implementors and operators who have deployed. It is only right that we at IETF document what is really out there and relevant in the industry – not lower the standards down to the least common denominator when there is a non-technical opposition. In the end, all that remains is a (religious?) interpretation of RFC8200 text against PSP that stands in the way of the completion of the WGLC. Therefore, it is time for us (Spring WG) to NOW call this WGLC to end. Thanks, Ketan From: ipv6 <ipv6-boun...@ietf.org> On Behalf Of li_zhenqi...@hotmail.com Sent: 27 February 2020 08:57 To: war...@kumari.net; John Leddy <j...@leddy.net> Cc: spring@ietf.org; 6...@ietf.org; Bob Hinden <bob.hin...@gmail.com>; Zafar Ali (zali) <zali=40cisco....@dmarc.ietf.org> Subject: Re: Re: [spring] Request to close the LC and move forward//RE: WGLC - draft-ietf-spring-srv6-network-programming Based on the value of this doc, it deserves an extension of WGLC, even a second WGLC. It is obvious that some technical isssues and comments are still boiled in this list. So, in my opinion I am afraid that the WGLC can not reach the rough consensus that the doc is ready to move forward. Since the issues are mainly ralated to the flavor section, why not extract this part from this main doc to a separate doc and try to move the main doc forward. We can discuss the separate flavor doc further. Best Regards, Zhenqiang Li ________________________________ li_zhenqi...@hotmail.com<mailto:li_zhenqi...@hotmail.com> From: Warren Kumari<mailto:war...@kumari.net> Date: 2020-02-27 03:15 To: John Leddy<mailto:j...@leddy.net> CC: SPRING WG List<mailto:spr...@ietf..org>; 6...@ietf.org<mailto:6...@ietf.org>; Bob Hinden<mailto:bob.hin...@gmail.com>; Zafar Ali \(zali\)<mailto:zali=40cisco....@dmarc.ietf.org> Subject: Re: [spring] Request to close the LC and move forward//RE: WGLC - draft-ietf-spring-srv6-network-programming I would suggest that people read RFC 7282 - "On Consensus and Humming in the IETF", especially Sections 3 & 6 (it is a short document, you should read the whole thing, but pay special attention to these sections). It doesn't really matter how many people say +1 for moving it forwards -- if there are valid technical objections these have to be dealt with - and I think that the relationship with RFC8200 falling into this category... W On Wed, Feb 26, 2020 at 2:01 PM John Leddy <j...@leddy.net<mailto:j...@leddy.net>> wrote: > > +1 in support of moving the document forward. > > John Leddy > > Sent from my iPhone > > > On Feb 26, 2020, at 10:22 AM, Bob Hinden > > <bob.hin...@gmail.com<mailto:bob.hin...@gmail.com>> wrote: > > > > Zafar, > > > >> On Feb 26, 2020, at 9:43 AM, Zafar Ali (zali) > >> <zali=40cisco....@dmarc.ietf.org<mailto:zali=40cisco....@dmarc.ietf.org>> > >> wrote: > >> > >> +1, > >> > >> Just to add, in the spirit of IETF https://www.ietf.org/how/runningcode/ … > >> implementation, commercial deployment and Inter-op status has been > >> documented in > >> https://datatracker.ietf.org/doc/draft-matsushima-spring-srv6-deployment-status/ > > > > I think the proper question is there a consensus to advance this document. > > > > There seems to be questions about its relationship with RFC8200. I am not > > seeing this as being resolved. > > > > Bob > > > > > > > > -------------------------------------------------------------------- > > IETF IPv6 working group mailing list > > i...@ietf.org<mailto:i...@ietf.org> > > Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 > > -------------------------------------------------------------------- > > -------------------------------------------------------------------- > IETF IPv6 working group mailing list > i...@ietf.org<mailto:i...@ietf.org> > Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 > -------------------------------------------------------------------- -- I don't think the execution is relevant when it was obviously a bad idea in the first place. This is like putting rabid weasels in your pants, and later expressing regret at having chosen those particular rabid weasels and that pair of pants. ---maf -------------------------------------------------------------------- IETF IPv6 working group mailing list i...@ietf.org<mailto:i...@ietf.org> Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 --------------------------------------------------------------------
_______________________________________________ spring mailing list spring@ietf.org https://www.ietf.org/mailman/listinfo/spring
