Re: #148: Reasonable Assurances and H2C

[Mark Nottingham <[e-mail]>]

> On 28 Feb 2016, at 3:43 AM, Barry Leiba <[e-mail]> wrote:
> 
>>> Yeh, why is "that updates this document" there?  Why do readers of
>>> this document have to know about means that are provided in other
>>> documents, such that "updates" is needed?
>> 
>> We wanted to assure that any other way to establish reasonable assurances
>> had sufficient vetting, and that someone reading this spec could find all the
>> different ways to establish reasonable assurances.
>> 
>> Any additional insights (hopefully in non-question form)?
> 
> Hm, I'm assume that wasn't meant to be snarky, though it sounds it.  I
> needed to ask the question in order to answer the original question.

No, it was not; apologies for giving the impression.


> The way to assure the vetting is to say that they must be Standards
> Track.  Experimental documents might or might not get sufficient
> vetting.
> 
> The way to ensure that people who read this spec can find all the
> extensions is to make a registry.  Extensions shouldn't generally be
> "updating" the original spec.
> 
> So...
> You can decide how you think the vetting will be accomplished, but if
> you want it to be easy to find the new mechanisms, have this document
> set up a registry and say that new mechanisms MUST be registered
> there.  Then there's no concern about any "updates" rules with respect
> to documents from other than Standards Track sources.

A registry doesn't feel right because this isn't a protocol element. This isn't an extension in the usual sense; it's a controlled loosening of the spec's (security-sensitive) requirements.

However, it doesn't seem like 'updates' is the right way to do this either. Upon reflection, I wonder if we really need either property (at least in such a rigorous form); people will find the mechanisms if they get implemented, and we've been happy to have OppSec as Experimental.

Anyone have a problem with dropping this?

"""
Other means of establishing them MUST be documented in an RFC that updates this specification.
"""

Cheers,


--
Mark Nottingham   https://www.mnot.net/