[v6ops] Re: [EXTERNAL] Re: Fwd: The V6OPS WG has placed draft-cc-v6ops-wlcg-flow-label-marking in state "Call For Adoption By WG Issued"

["Dale W. Carder" <[e-mail]>]

Thus spake Brian E Carpenter ([e-mail]) on Thu, Aug 15, 2024 at 10:25:53AM +1200:
> Hi,
> 
> I am very strongly convinced that this draft should be published as an RFC. I am on the fence whether it should be published as an IETF stream Informational RFC or as an Independent stream Informational RFC. Since we know that most people don't read the boilerplate anyway, it hardly matters.
> 
> Although this work bends the rules of RFC 6437, the implementers were (to my personal knowledge) aware of the issues from the start, allowed for some entropy bits, and most important have actually shown a use case for 20 largely underused bits in the IPv6 header. This is a use case that is worth publishing, and I can imagine it leading to reconsideration of some of the rules in RFC 6437. That's why it belongs in the RFC series.
> 
> Note that RFC 6294 was published in the Independent Stream; that's a precedent. For more of the tortured history of the flow label, see RFC 6436.

First off, a lot of thanks go to Brian for helping us along the way.  

In my view as an author, we have a pretty pragmatic document...  More or
less it's we're trying to solve problems with what exists today and if
you were to see this behavior on the wire, this is what's going on.
There's a lot of room for future work, and that is also what I hope we
can help motivate.  We are limited by today's kernels, socket api
features, as well as what today's routers can actually extract from a
packet and send to us as telemetry for instance with IPFIX.

Dale

 
> On 15-Aug-24 06:05, Tommy Jensen wrote:
> > +1, I oppose the WG adopting this.
> > 
> > I do think having the I-D published individually would make for a nice reference for any standards updates ("this is an example of where this document's mechanism is needed and why"). The concrete numbers are especially insightful to justify design trade-offs and defaults values. That said, maybe it does not even need to make it to RFC publication if, as a draft, it can be used by the WG to motivate a standards-friendly solution that can be adopted and published by the WG instead.
> > 
> > This seems like something we should discuss at 121 either way.
> > 
> > Thanks,
> > Tommy
> > ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------
> > *From:* Tom Herbert <tom=[e-mail]>
> > *Sent:* Tuesday, August 13, 2024 3:21 PM
> > *To:* Mark Smith <[e-mail]>
> > *Cc:* IPv6 Operations <[e-mail]>
> > *Subject:* [EXTERNAL] [v6ops] Re: Fwd: The V6OPS WG has placed draft-cc-v6ops-wlcg-flow-label-marking in state "Call For Adoption By WG Issued"
> > [You don't often get email from tom=[e-mail]. Learn why this is important at https://aka.ms/LearnAboutSenderIdentification <https://aka.ms/LearnAboutSenderIdentification> ]
> > 
> > On Tue, Aug 13, 2024 at 3:06 PM Mark Smith <[e-mail]> wrote:
> > > 
> > > Hi,
> > > 
> > > I don't support adoption for a number of reasons.
> > > 
> > > Firstly, and the main reason, v6ops working group adoption means the
> > > document becomes a product of the WG, rather than just the authors.
> > > 
> > > As this ID is documenting violations of IETF Standard Track RFC 6437,
> > > it becoming a v6ops WG document means that the v6ops WG is tacitly
> > > endorsing RFC 6437 violation, even if published as Informational.
> > > 
> > > It becoming a WG document also suggests there is further work to be
> > > done on it by the WG, not just the authors. What further work on this
> > > ID is there the v6ops WG to do?
> > > 
> > > If the IETF is the best place to publish it, why can't it be published
> > > as an Independent Submission, avoiding v6ops tacit endorsement and any
> > > WG publication overheads.
> > 
> > Mark,
> > 
> > I tend to agree. The proposal is for a very limited use case, and the
> > draft acknowledges that the correct mechanism to carry such data would
> > be Destination Options. IMO, the community would be better served by
> > the WG working on fixing the problems of extension header deployment
> > instead of pursuing workarounds like this. Independent Submission
> > seems appropriate.
> > 
> > Tom
> > 
> > > 
> > > Why can't it be published as an academic paper outside of the IETF,
> > > further avoiding the IETF RFC publication costs?
> > > 
> > > Regards,
> > > Mark.
> > > 
> > > On Wed, 14 Aug 2024 at 04:27, Nick Buraglio
> > > <[e-mail]> wrote:
> > > >
> > > >
> > > > This call for adoption is wrapping up. If anyone else would like to comment, please read the draft and provide feedback by tomorrow.
> > > > Below is the current state:
> > > >
> > > > | [draft-cc-v6ops-wlcg-flow-label-marking](https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fdatatracker.ietf.org%2Fdoc%2Fdraft-cc-v6ops-wlcg-flow-label-marking%2F&data=05%7C02%7CJensen.Thomas%40microsoft.com%7C2739959a19694bc2afc808dcbbe66575%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C638591845444934751%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C0%7C%7C%7C&sdata=1bDguBEr3SLbHqMkqAznDR0QH5LBbceSPR9UPoFMymY%3D&reserved=0)  |             | Adoption Called 05-Aug-2024                        | Adoption Ending 19-August-2024 |
> > > > | ------------------------------------------------------------------------------------------------------------------ | ----------- | -------------------------------------------------- | ------------------------------ |
> > > > | Support                                                                                                            | Opposed     | Comments                                           | Comments Addressed             |
> > > > | Brian Carpenter                                                                                                    |             | discussion of deviations from RFC 6437 is helpful. |                                |
> > > > | Tim Winters                                                                                                        |             |                                                    |                                |
> > > > | Nick Buraglio                                                                                                      |             |                                                    |                                |
> > > > |                                                                                                                    | Tom Herbert | Feels is too specific                              | Yes                            |
> > > > | David Farmer                                                                                                       |             |                                                    |
> > > >
> > > >
> > > > I believe Tom had his concerns addressed but I never saw explicit support after.
> > > > If anyone else would like to comment, please read the draft and provide feedback by tomorrow.
> > > >
> > > > nb
> > > >
> > > >
> > > > On Mon, Aug 5, 2024 at 2:13 PM David Farmer <[e-mail]> wrote:
> > > >>
> > > >>
> > > >> I support adoption.
> > > >>
> > > >> On Mon, Aug 5, 2024 at 13:35 Nick Buraglio <[e-mail]> wrote:
> > > >>>
> > > >>> All,
> > > >>> We'd like to wrap this adoption call up. As of now we don't have a lot
> > > >>> of input, but it is mostly positive. Please read and comment.  Current
> > > >>> state:
> > > >>>
> > > >>> ### draft-cc-v6ops-wlcg-flow-label-marking
> > > >>> #### Adoption Called 06-July-2024
> > > >>> * Support - Comments - Comments Addressed
> > > >>> Brian Carpenter - discussion of deviations from RFC 6437 is helpful.
> > > >>> Tim Winters
> > > >>> Nick Buraglio
> > > >>>
> > > >>>  * Opposed - Comments - Comments Addressed
> > > >>> Tom Herbert - Feels is too specific - no
> > > >>>
> > > >>>
> > > >>> ---------- Forwarded message ---------
> > > >>> From: IETF Secretariat <[e-mail]>
> > > >>> Date: Sat, Jul 6, 2024 at 5:09 PM
> > > >>> Subject: The V6OPS WG has placed
> > > >>> draft-cc-v6ops-wlcg-flow-label-marking in state "Call For Adoption By
> > > >>> WG Issued"
> > > >>> To: <[e-mail]>,
> > > >>> <[e-mail]>, <[e-mail]>
> > > >>>
> > > >>>
> > > >>>
> > > >>> The V6OPS WG has placed draft-cc-v6ops-wlcg-flow-label-marking in state
> > > >>> Call For Adoption By WG Issued (entered by Nick Buraglio)
> > > >>>
> > > >>> The document is available at
> > > >>> https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fdatatracker.ietf.org%2Fdoc%2Fdraft-cc-v6ops-wlcg-flow-label-marking%2F&data=05%7C02%7CJensen.Thomas%40microsoft.com%7C2739959a19694bc2afc808dcbbe66575%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C638591845444948480%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C0%7C%7C%7C&sdata=TrSIGAQFjZ0PjpNduXVqjQrgX0Ze%2FiOOUU1EQiovloU%3D&reserved=0 <https://datatracker.ietf.org/doc/draft-cc-v6ops-wlcg-flow-label-marking/>
> > > >>>
> > > >>> _______________________________________________
> > > >>> v6ops mailing list -- [e-mail]
> > > >>> To unsubscribe send an email to [e-mail]
> > > >
> > > > _______________________________________________
> > > > v6ops mailing list -- [e-mail]
> > > > To unsubscribe send an email to [e-mail]
> > > 
> > > _______________________________________________
> > > v6ops mailing list -- [e-mail]
> > > To unsubscribe send an email to [e-mail]
> > 
> > _______________________________________________
> > v6ops mailing list -- [e-mail]
> > To unsubscribe send an email to [e-mail]
> > 
> > _______________________________________________
> > v6ops mailing list -- [e-mail]
> > To unsubscribe send an email to [e-mail]
> _______________________________________________
> v6ops mailing list -- [e-mail]
> To unsubscribe send an email to [e-mail]