On Thu, 27 Feb 2020 at 07:09, john leddy.net <j...@leddy.net> wrote: > > The understanding at IETF98 with rfc2460 moving to rfc8200 was that any > tightening in header processing language was to get to an adopted standard > and NOT to be used as club to bludgeon innovation by a small group of loud > hummers. >
If you think I'm against innovation with IPv6, then you haven't seen my IPv6 formal and functional anycast address proposal - https://tools.ietf.org/html/draft-smith-6man-form-func-anycast-addresses-01. draft-ietf-spring-srv6-network-programming-10 doesn't say "Updates RFC8200", nor does it provide any technical justification for PSP, including comparison with the existing alternative. As RFC 8200 is also one of only 92 full Internet Standards, and of course has met the required criteria to be promoted to full Internet Standard, fundamental changes to it have to be very significantly justified and considered. The SPRING WG are also supposed to be actively trying to avoid such changes. From the charter: "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." (+1 to everybody reading RFC 7282) Regards, Mark "Loud Hammer" Smith. "What you allow, you encourage." - Michael Josephson. > > > On February 26, 2020 at 2:15 PM Warren Kumari <war...@kumari.net> wrote: > > > > > > 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> 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> wrote: > > > > > > > > Zafar, > > > > > > > >> On Feb 26, 2020, at 9:43 AM, Zafar Ali (zali) > > > >> <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 > > > > Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 > > > > -------------------------------------------------------------------- > > > > > > -------------------------------------------------------------------- > > > IETF IPv6 working group mailing list > > > 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 > > _______________________________________________ > spring mailing list > spring@ietf.org > https://www.ietf.org/mailman/listinfo/spring _______________________________________________ spring mailing list spring@ietf.org https://www.ietf.org/mailman/listinfo/spring
