Dear Ron, The IETF is not writing de jure standards. In fact reality is quite different, and the Internet evolves the way it does somewhat independently of what documents the IETF produces. In fact I know of no networking products (or deployments) that follow the intent and spirit of RFC8200. I challenge to point me to one! ;-)
Let me quote Tony Li's response to Fernando's escalation email to the architecture list: "The fact of the matter is that the IETF is completely helpless to prevent such things. True, it can block standardization, but if the market wants it, the market will drive it and all that the IETF does is to make itself irrelevant to the process." My suggestion to Fernando was to argue the issues on technical merit. Can you please explain why you don't do that? - Does it break end to end transparency? - Can end host protect their traffic with encryption or do the proposed mechanisms break that? - How is PMTUD, ICMP errors, AH being handled? - Does it break intereroperability? Best regards, Ole > On 4 Sep 2019, at 20:27, Ron Bonica <rbon...@juniper.net> wrote: > > Ole, > > Yes, a deep breath and some introspection are always a good thing. > > First, I think that we need to make a distinction between the "spirit" and > "letter" of the law. Next, we need to make a statement regarding good > engineering practice. > > RFC 8200 mandates some things. For example, In an IPv6 header, the source > address must precede the destination address. Any attempt to reverse those > two would violate the letter of the law. > > By contrast, RFC 8200 strongly suggests other things. For example, transit > nodes should not insert or delete extension headers. In general, these > suggestions should be heeded. But exemptions can be granted, on a > case-by-case basis, given that the motivation is strong, the risk is minimal, > and there are no viable alternatives. > > For better or worse, RFC 8200 does not use RFC 2119 language. So it is > difficult to distinguish between the spirit and letter of the law. I think > that is the genesis of the current debate. > > Beyond that, we need to make a statement regarding good engineering practice. > If a technology violates the spirit of RFC 8200 once, with good reason, that > is fine. If it violates the spirit of RFC 8200 twice, we should all start > asking questions. If it violates the spirit of RFC 8200 three times, and > promises to do so again in the future, we should start to question whether > that technology is building on RFC 8200 or trying to redefine it. > > Ron > > > > Juniper Business Use Only > > -----Original Message----- > From: Ole Troan <otr...@employees.org> > Sent: Wednesday, September 4, 2019 2:58 AM > To: Fernando Gont <ferna...@gont.com.ar> > Cc: Suresh Krishnan <suresh.krish...@gmail.com>; Ron Bonica > <rbon...@juniper.net>; spring@ietf.org; 6...@ietf.org; > draft-voyer-6man-extension-header-insertion > <draft-voyer-6man-extension-header-insert...@ietf.org>; > draft-ietf-spring-srv6-network-programming > <draft-ietf-spring-srv6-network-programm...@ietf.org> > Subject: Re: Question about SRv6 Insert function > > [ snip ] > I would prefer that we calmed down a bit on the protocol policing. > > [ snip ] _______________________________________________ spring mailing list spring@ietf.org https://www.ietf.org/mailman/listinfo/spring
