On 6/12/19 20:55, otr...@employees.org wrote: >> * polling the mailing list instead of deciding (on your own) that the >> group wants to work on EH insertion, and, > > Which decision are you referring to? > I have certainly never decided that working group wants to work on header > insertion.
This is your note: https://mailarchive.ietf.org/arch/msg/ipv6/j177aiqH6G4XNTWWrRfpsV23IVg Then I re-asked: https://mailarchive.ietf.org/arch/msg/ipv6/12Qwp_eeQT2EmbUrSxBLL5HTcnM But you didn't respond. Suresh clarified there had not been any sort of adoption call: https://mailarchive.ietf.org/arch/msg/ipv6/Db6_SGfmeIDzaE56Ps5kUDCYEzY Then again we were debating the topic here: https://mailarchive.ietf.org/arch/msg/ipv6/56w4LQzYtkut43A46ADhW3dWT-Y The reality is that there has not been a call for adoption for any of these two documents. So.. I'm not sure what a say may the wg have on documents that are individual documents. On that ground, RFC8200 represents IETF consensus. And the spring documents should be complying with it. TO be honest, I have no idea what there is to debate here. > With regards to the documents, I believe I clarified the statement of the > working group seeing no reason why both documents couldn't be continue to be > worked on. The wg doesn't have a say on individual documents. So, yes, both documents can continue to be worked on as much as I can continue "working" on my BBQ. Whatever the opinion of the wg, authors can work on individual I-Ds as much as they please. For the wg to have a say, I guess there has to be a conversation about adoption. But such conversation hasn't taken place. (Me, myself, I'd find it amusing to see the wg have two documents, one that says "this is evil", and another about "doing evil" :-) But that's of course a personal view). > Those documents are not adopted, nor has any decision about adoption been > made, nor is any adoption call of those documents planned. > > I certainly don't want us as a group or myself personally to be working on > header insertion. > You might not be alone, but you certainly keep repeatedly forcing the working > group to consider the issue. And here we go again, for the Nth time: a big part of this thread came up because folks at the spring are violating our specs. So I have requested folks (including INT and RTG ADs), that the document remove all text that violates RFC8200. But then we see all this body of imagination of how they are not violating RFC8200 (when they are), you talking about the topic being nuanced and about "limited domains", etc. >> * complying with existing specifications unless there's formal consensus >> for them to be formally updated. > > I believe I have responded multiple times to this point. > I do not in principle see a conflict with specifying how header insertion can > work in a specific case, > and the text in RFC8200. I would strongly oppose updating RFC8200, since > header insertion is clearly > something that can only apply in specific use cases. You have a spec that explicitly forbids it, with as strong of a wording as available (it's not a "MUST NOT", because you and others opposed to having rfc2460bis employ RFC2119 language). EH-insertion goes against an explicitly forbidden behavior. Is not that you are playing in the MAY or SHOULD area. So an update is warranted if this is to happen. So yes, if you want to go against the spec, you have to update it. I don't think we publish specs for folks to then come an note why they have decided to violate them. And to the ocassional RFC reader, it will be a bit of a mess to sail through a bunch of documents where some specify behavior, and others simply do what they please. A formal update is also warranted because, otherwise, if I read RFC8200 (and there's no metadata that points to EH-insertion), I can assume that this packet mangling doesn't occur. But then if the same organization (IETF) publishes another document that says how to mangle with IPv6 packets, without any formal update of RFC8200, I have nothing signaling me to read it. Thanks, -- 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
