On 5/9/19 16:34, Ole Troan wrote: > Joel, > >> Part of the reason we write restrictions and requirements into RFCs is so >> that we do not have to repeat the arguments. >> >> If the proponents of the insertion have arguments for why it is now okay, >> they need to make those arguments. And they need to make sure that the >> discussion is taken to the relevant working groups. The burden should not >> be on those who are asking that attention be paid to existing RFCs. > > As far as I know, but I'm trying to stay away from the actual proposals and > argue this generally, no-one is proposing to update the RFC8200 header > insertion text. > What people are proposing are for specific domains. And given that, I believe > people need to argue the technical merits of those specific proposals. > As opposed to throwing the "law book" around.
Se, please let me recap the history on this topic, for those that missed it: 1) EH insertion was originally proposed on the basis that RFC2460 wasn't clear whether it was allowed or not. 2) Since we were doing rfc2460bis (now RFC8200), we incorporated text into RFC8200 so that nobody could claim that the IPv6 spec is not clear on this topic. 3) Now there's at least one I-D in spring that ignores RFC8200, and proposes EH-insertion as if it was allowed, essentially circumventing RFC8200, and IETF consensus. I don't think it's in the spring wg's charter to specify how IPv6 works. It should be done in 6man (or not even, because that's a major modification, and not really "maintenance"). The only book I'm throwing is: proposals from big vendors should follow the same procedures as those from mere mortals that don't happen to work for a big vendor. -- Fernando Gont SI6 Networks e-mail: fg...@si6networks.com PGP Fingerprint: 6666 31C6 D484 63B2 8FB1 E3C4 AE25 0D55 1D4E 7492 _______________________________________________ spring mailing list spring@ietf.org https://www.ietf.org/mailman/listinfo/spring
