Re: [tsvwg] plan for L4S issue #29

["Rodney W. Grimes" <[e-mail]>]

Comment at end.

> On 10/1/2020 8:13 AM, Pete Heist wrote:
> > On Tue, 2020-09-29 at 22:48 +0000, Greg White wrote:
> >> In my opinion, Issue 29 can be closed. RFC3168 detection should
> >> continue to evolve and should be referenced in the Operational
> >> Guidance draft, but fallback should not be required in the
> >> experimental protocol drafts for the reasons outlined in Issue 29,
> >> and on the mailing list.
> > In my opinion, the issues with bottleneck detection and fallback should
> > be fixed, since this was the proposed way to provide safety for the
> > alternate meaning of CE being introduced.
> >
> > The question of whether or not to proceed with these issues still open
> > sounds like a separate one, but it seems like closing issues without
> > fixing them would make it hard for someone who wanted to review and
> > understand what issues are still open.
> 
> 
> I agree.? Open issues,? research questions, and future work are often 
> explained in a section of the Exp. RFCs.? This is better than just the 
> tracker, since it's right inside the published document.? That has been 
> something we've done in the past, like in Section 7 of RFC 8290 and 
> Section 7 of RFC 8033, as pertinent examples.? I think similar should be 
> expected in this case.? I don't think Section 6 of the ecn-l4s-id draft 
> is yet as detailed as I'd hope for yet this regard.
> 
> Adding description of this issue to an appropriate place in the document 
> suite sounds like a good next step.? The issue is understood and people 
> doing implementation & deployment seem to be accepting this condition 
> for now, but would probably want to improve it.

I do not accept that as a given.  If the people doing implementainos &
deployment where even aware of this situation it would not of taken
the testing by Pete Heist to uncover the issue.

With that said, perhaps documenting this clearly in the drafts would
at least raise the awareness of this issue with L4S for its proponents.

-- 
Rod Grimes                                                 [e-mail]