Re: #148: Reasonable Assurances and H2C

[Julian Reschke <[e-mail]>]

On 2016-02-27 23:10, Mark Nottingham wrote:
>
>> 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.
> """

Sounds right to me.

Best regards, Julian