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
