Re: [spring] We don't seem to be following our processes (Re: Network Programming - Penultimate Segment Popping)

[Fernando Gont <[e-mail]>]

On 6/12/19 20:55, [e-mail] 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: [e-mail]
PGP Fingerprint: 6666 31C6 D484 63B2 8FB1 E3C4 AE25 0D55 1D4E 7492