Re: Thought experiment [Re: Quality of Directorate reviews]

[Keith Moore <[e-mail]>]

On 11/7/19 2:44 PM, Nico Williams wrote:

>> If we want there to be a prototype "just for testing" status, it should
>> probably be called something other than Proposed - the name has come to mean
>> something else in IETF context.   And we should deliberately change one or
> We have it: it's Experimental.  But it's essentially seen as a negative,
> thus underused.

Experimental doesn't imply that there's an intention to standardize a 
protocol, though this does happen in rare cases.

Though now that I think about it, the right way to denote prototype 
status is probably to designate specific Internet-Drafts rather than to 
publish them as RFCs.   RFC publication isn't designed for temporary 
documents.

>> more protocol elements to make the standard incompatible with
>> already-deployed implementations.   The trick would be to keep that
>> information from leaking out beforehand.    Maybe give the RSE /N/ options
>> for things to change that are selected at random, similarly to the way
>> nomcoms are selected.
> Are you proposing that there be a required backwards-incompatible change
> so as to force... what exactly?  That the old thing does not get
> deployed?  I assume it will mostly discourage use of the new track.

The purpose is to remove some of the incentives to deploy protocol 
implementations before they're approved, while still allowing 
implementations and meaningful interoperability tests. When things are 
prematurely deployed it puts pressure on the WG and/or IESG to accept 
specifications that have significant flaws. It can also harm IETF's 
reputation when implementations don't meet the specification or don't 
interoperate.

> The risk with deploying prototypes is that a backwards-incompatible
> change will be needed, so perhaps early reviews should focus only on
> identifying features at risk of such changes and requiring that the
> experimental protocol cover upgrades or reduce the risk.
IMO one of the primary reasons for early reviews is to learn as early as 
possible whether an intended direction or protocol design choice would 
create or exacerbate tussles that could be addressed, and/or have 
adverse effects on other interests that might compel a different 
direction or choice.    It goes beyond "identifying features" because 
it's not always individual features that cause the conflicts.
>> But my guess is that the only way to get buy-in for Prototype specifications
>> would be to convincingly promise faster development.
> Yes.  That includes faster RFC-Editor turnarounds.  If we remove the
> other bottlenecs, then RFC-Editor queue time will become the next
> bottleneck to address.

I was thinking earlier today that the biggest waster of time and energy 
might be when IETF invests years of volunteer effort on specifications 
that turn out to be not very useful.   Even worse might be when IETF 
increases complexity (of implementations, operations, etc.) that doesn't 
result in a tremendous benefit to the Internet user community.

(It's easy to pay more attention to things that are easily measured, 
than those that are not, even though the easily measured quantities 
might not be the most relevant ones.)

Keith