Re: Secdir last call review of draft-nottingham-rfc5785bis-08

[Mark Nottingham <[e-mail]>]

Cutting down to specific replies --

> On 15 Feb 2019, at 11:20 am, Kathleen Moriarty <[e-mail]> wrote:
>> 
>> > 3. Section 3.1 says:
>> > The "Well-Known URIs" registry is located at
>> >   "https://www.iana.org/assignments/well-known-uris/".  Registration
>> >   requests can be made by following the instructions located there or
>> >   by sending an email to the "[e-mail]" mailing
>> >   list.
>> > 
>> > I'm not clear on the instructions as I follow the link to the registry and
>> > there's a pointer to the RFC that this document will obsolete.  I'm assuming
>> > that the reference will be replaced with this document.  Is that the case or
>> > are there additional instructions than what will be included directly in the
>> > registry?  If they are repeated (I don't see an IANA request for that action),
>> > that is fine, but I think it's a little confusing to send someone to that link
>> > if they are already reading this document.  This document is also going through
>> > a review process to update that registry, so if instructions were maintained at
>> > the registry URL, what would be the review process to alter the instructions? 
>> > I'm assuming that this sentence just should be removed, but if not, I'd like to
>> > understand the update process for that registry (instructions for registering
>> > values not adding them).  If the sentence should be changed, I suggest
>> > something like:
>> > 
>> >   The "Well-Known URIs" registry is located at
>> >   "https://www.iana.org/assignments/well-known-uris/".  Registration
>> >   requests can be made by following the instructions in this document and
>> >   sending the email to the "[e-mail]" mailing
>> >   list.
>> 
>> After extensive consultation with IANA regarding RFC8288's revision of registration policy, the outcome was that this level of detail / instruction is unnecessary; the text at the top of a registry page can be tweaked by the Experts by asking IANA, and if they have concerns they can take it up with the IESG as necessary.
>> 
>> Personally I was a bit surprised by this, but also relieved; getting this sort of thing *exactly* right in an RFC is difficult, and we need the flexibility to change things (e.g., we're currently using a Github issue queue to collect registration requests there, but that might change in the future).
> 
> What would be helpful here would be some text in the document that asks IANA to add the instructions to the registry.  I'm hoping that more clearly states my question/request.  

Based on previous interactions with them, my understanding is that they do *not* want this level of specificity in the defining documents. Also, your text priorities the mailing list as the submission mechanism, when the preferred mechanism is likely to be an issue queue (as we've done for 8288).


>>  > 4. Question on Change controller: Is it possible to successfully make a request
>> > through an experimental track RFC or standards track only?  If experimental is
>> > allowed, can it only be provisional?
>> 
>> The registry is Specification Required, so an experimental RFC can indeed make a registry. It can be 'standard' if it meets this bar: "Other values can also be registered as permanent, if the Experts find that they are in use, in consultation with the community."
>> 
>> 
>> I think the text that had me ask this question was the following:
>> 
>>    Standards-defined values have a status of "permanent".  Other values
>>    can also be registered as permanent, if the Experts find that they
>>    are in use, in consultation with the community.  Other values should 
>> 
>>        be registered as "provisional".   
> 
> By standards-defined, do you mean through specification required in the IETF?

The current text is:

"""
Values defined by standards-track RFCs and other open standards (in the sense of {{?RFC206, Section 7.1.1}}) have a status of "permanent".
"""

>> > 5. Section 3 has the following sentence:
>> > 
>> >   General requirements for registered relation types are described in
>> >   Section 3.
>> > 
>> > Did the document in a previous revision contain something in section 3 about
>> > registered relation types or am I missing something when reading section 3
>> > (which is entirely possible)?  If it were there (or maybe was in a previous
>> > revision), I'd expect to see it in the following paragraph, but could see the
>> > above text being dropped as an answer to this question as well (unless I am
>> > missing something):
>> > 
>> >   It MAY also contain additional information, such as the syntax of
>> >   additional path components, query strings and/or fragment identifiers
>> >   to be appended to the well-known URI, or protocol-specific details
>> >   (e.g., HTTP [RFC7231] method handling).
>> 
>> Section 3 puts requirements on choosing a registered name, both syntactically and with a more general SHOULD about how to choose a good name.
> 
> OK, can you clarify in the text what you mean by registered relation type or have that sentence say registered name instead of relation type since that is the only time registered relation type appears in the document?  I think that would help the reader.

Sorry, that was a cut-and-paste error; I've updated to say "registered values."

Cheers and thanks again,

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