[tsvwg] dispute (Re: Results of consensus call on ECT(1) usage)

[Paul Vixie <[e-mail]>]

On Friday, 22 May 2020 02:32:45 UTC Wesley Eddy wrote:
> ...
> 
> Result of consensus call: TSVWG has interest in working on a low-latency
> service using ECT(1) as an input (e.g. L4S) in preference to working on
> enabling high-fidelity congestion control using ECT(1) as an network
> output signal (e.g. SCE). The chairs see strong support for this
> direction, including significant interest from network operators and
> vendors.

the relevant section of RFC 2026 is as follows:

> 6.5.1 Working Group Disputes
> 
>    An individual (whether a participant in the relevant Working Group or
>    not) may disagree with a Working Group recommendation based on his or
>    her belief that either (a) his or her own views have not been
>    adequately considered by the Working Group, or (b) the Working Group
>    has made an incorrect technical choice which places the quality
>    and/or integrity of the Working Group's product(s) in significant
>    jeopardy.  The first issue is a difficulty with Working Group
>    process;  the latter is an assertion of technical error.  These two
>    types of disagreement are quite different, but both are handled by
>    the same process of review.

on a personal note, my own expressed position was, that if something had to be 
done it should be an input not an output. so, the chairs' declared result is 
compatible with what i said. therefore i'm not claiming that my own views were 
not adequately considered (a, above). rather, i'd concerned about (b) above.

this choice was not made based on technical merit, by the chair's own 
description (quoted above). both the rough consensus and the running code 
looked to me more like choice 3 ("more testing"). what the operators and 
vendors who can afford to attend these meetings are interested in, may differ 
from the community's long term interests.

>    A person who disagrees with a Working Group recommendation shall
>    always first discuss the matter with the Working Group's chair(s),
>    who may involve other members of the Working Group (or the Working
>    Group as a whole) in the discussion.

we are "here." i hope the chairs can explain why choice 3, more testing, was 
not the rough consensus they think they witnessed, and also, how the time 
value of a choice of 1 or 2 "now" is higher than the merit value of getting to 
an evidence-based consensus "later".

>    If the disagreement cannot be resolved in this way, any of the
>    parties involved may bring it to the attention of the Area
>    Director(s) for the area in which the Working Group is chartered.
>    The Area Director(s) shall attempt to resolve the dispute.
>    
>    If the disagreement cannot be resolved by the Area Director(s) any of
>    the parties involved may then appeal to the IESG as a whole.  The
>    IESG shall then review the situation and attempt to resolve it in a
>    manner of its own choosing.
>    
>    If the disagreement is not resolved to the satisfaction of the
>    parties at the IESG level, any of the parties involved may appeal the
>    decision to the IAB.  The IAB shall then review the situation and
>    attempt to resolve it in a manner of its own choosing.

i think a challenge was inevitable no matter what outcome was designated as 
the consensus, and that this probably is a matter to be settled by IETF as a 
body rather than by this working group in isolation.

-- 
Paul