Re: [tsvwg] plan for L4S issue #29

[Wesley Eddy <[e-mail]>]

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.