Re: [tsvwg] Call for comments on the suggested publication timeline for draft-white-tsvwg-l4sops

[Ingemar Johansson S <[e-mail]>]

+1 

I think it makes much sense to wait with he publication for draft-white-tsvwg-l4sops until we have more data from the experiments.

/Ingemar

> -----Original Message-----
> From: tsvwg <[e-mail]> On Behalf Of
> [e-mail]
> Sent: Thursday, 24 March 2022 15:10
> To: [e-mail]
> Cc: [e-mail]
> Subject: Re: [tsvwg] Call for comments on the suggested publication timeline
> for draft-white-tsvwg-l4sops
> 
> Gorry,
> 
> I agree to Bob's proposal to wait with publication until some experimental
> experience has been reached.
> 
> Regards,
> 
> Ruediger
> 
> -----Ursprüngliche Nachricht-----
> Von: tsvwg <[e-mail]> Im Auftrag von Bob Briscoe
> Gesendet: Donnerstag, 24. März 2022 14:35
> An: Gorry Fairhurst <[e-mail]>
> Cc: [e-mail]
> Betreff: Re: [tsvwg] Call for comments on the suggested publication timeline
> for draft-white-tsvwg-l4sops
> 
> Gorry,
> 
> I can see the two sides of this.
> * Sebastian's point that publication could improve visibility for network and
> server operators is a good one.
> * But if I were on the IESG and asked to approve publication of operational
> guidance before there was any operational experience, I would be
> concerned.
> 
> Similarly, because some of the points in the draft do not have much real
> experience to back them up, they might have to be removed in order to get
> it approved for publication. For instance, we have been arguing about:
> * likely traffic patterns;
> * likelihood of shared queue Classic ECN being deployed;
> * likelihood of hash collisions
> * likelihood that good classic ECN bottleneck detection can be implemented;
> * likelihood that network equipment can be configured in certain ways; etc.
> etc.
> Without some real-world experience on these matters, I'm not sure what
> the value of this document as an RFC would be.
> 
> I think Sebastian's point might be slightly reworded to say this draft needs
> 'visible status'. Visibility comes from Internet discussion forums, blogs and
> articles. Not yet being published as an RFC doesn't really change visibility (e.g.
> anyone interested in the implications of QUIC would have read a draft
> without waiting for RFC publication).
> Rather, publication changes the status of the guidance once it is visible.
> 
> How about this compromise:
> * We agree now that this draft is intended to give guidance based on 'early'
> or 'initial' operational experience (e.g. 1 year), and aim to publish once there
> is some experience, but not wait until experience is exhaustive.
> * Where l4sops is cited in ecn-l4s-id (from the requirement on coexistence in
> Classic ECN AQMs), we edit to say explicitly that l4sops is being kept open as
> a living document for a short while to capture initial operational experience.
> 
> Then, if ecn-l4s-id is published as an RFC, the visible status of the coexistence
> issue ought to be no less than if two RFCs are published about it.
> And this extra explanation of the draftiness of the citation should make it
> more likely that people who need to read l4sops will understand its status
> and not dismiss it as "not worth reading yet".
> 
> HTH
> 
> 
> 
> Bob
> 
> On 21/03/2022 17:53, Greg White wrote:
> > Hi Gorry,
> >
> > A few points of clarification.
> >
> > The draft in question is actually https://datatracker.ietf.org/doc/draft-ietf-
> tsvwg-l4sops/
> >
> > Also, there remains one "ToDo" in the document that I briefly mentioned
> today, and for which I'm hoping to get input from the WG.  Aside from that
> one item, I'm not aware of any other areas where it is considered
> incomplete.
> >
> > Is the deadline for responses to your question possibly *April* 8?
> >
> > -Greg
> >
> >
> >
> > On 3/21/22, 8:28 AM, "tsvwg on behalf of Gorry Fairhurst" <tsvwg-
> [e-mail] on behalf of [e-mail]> wrote:
> >
> >      The presentation in TSVWG on Monday 21st March 2022 indicated that
> the
> >      authors thought the document was complete and ready for review. The
> >      chairs previously indicated that publication could be delayed to wait
> >      for initial experience.  The chairs would appreciate feedback, to help
> >      decide.
> >
> >      So, does the WG have a  preference regarding when to publish the L4S
> Ops
> >      draft:
> >
> >      (1)  If the work is thought complete, there could be value in having a
> >      frozen draft while experience is gained, this could be updated with
> >      initial experience, before requesting publication as an RFC.
> >
> >      (2) The WG would not intentionally delay the request for the IESG to
> >      publish: If the work is thought complete, then we can finish this draft
> >      and publish in the short-term. The WG retains the option to decide to
> >      subsequently publish an updated RFC in the future.
> >
> >      Please could send an email to tsvwg, or to the tsvwg chairs by 8th March
> >      2022.
> >
> >      Before any publication, the ID will be subject to normal review and WGLC
> >      comments.
> >
> >      Best wishes,
> >
> >      Gorry Fairhurst
> >      (tsvwg co-chair)
> >
> >
> 
> --
> __________________________________________________________
> ______
> Bob Briscoe                               https://protect2.fireeye.com/v1/url?k=31323334-
> 501d5122-313273af-454445555731-b0108c2709550a3a&q=1&e=c5e952cd-
> dfdb-4fee-babd-2c04232e13cd&u=http%3A%2F%2Fbobbriscoe.net%2F