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

[<[e-mail]>]

Fernando,
 
> From: ipv6 [mailto:[e-mail]] On Behalf Of Fernando Gont
> Sent: Saturday, December 7, 2019 2:10 AM
> 
> 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.

It's not crystal clear to me what you are referring to.

If it's related to draft-ietf-spring-srv6-network-programming which is under WGLC, could you please comment as part of this  last call thread? And please quote the draft text that you are referring to. In particular the/all  "text that violates RFC8200".
So far your comments are: https://mailarchive.ietf.org/arch/browse/spring/?q=WGLC%20-%20draft-ietf-spring-srv6-network-programming&f_from=Fernando%20Gont  Hence as part of this last call, I'm not seen your "So I have requested folks (including INT and RTG ADs), that the document remove all text that violates RFC8200."
As of today, this document is under WGLC in the SPRING WG. So please review _the text from this document_ and comment in the SPRING WG.
Eventually, you will also have the opportunity to comment during IETF LC and to raise your points to the IESG. But your position will be stronger if you first comment during the WG LC.

If it's related to something else, e.g. some authors of SRv6 draft(s), please be more specific and refers to those drafts, rather than "folks at the spring".


Thank you,
--Bruno

> 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
> 
> 
> 
> 
> --------------------------------------------------------------------
> IETF IPv6 working group mailing list
> [e-mail]
> Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
> --------------------------------------------------------------------

_________________________________________________________________________________________________________________________

Ce message et ses pieces jointes peuvent contenir des informations confidentielles ou privilegiees et ne doivent donc
pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu ce message par erreur, veuillez le signaler
a l'expediteur et le detruire ainsi que les pieces jointes. Les messages electroniques etant susceptibles d'alteration,
Orange decline toute responsabilite si ce message a ete altere, deforme ou falsifie. Merci.

This message and its attachments may contain confidential or privileged information that may be protected by law;
they should not be distributed, used or copied without authorisation.
If you have received this email in error, please notify the sender and delete this message and its attachments.
As emails may be altered, Orange is not liable for messages that have been modified, changed or falsified.
Thank you.