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

From: Mark Nottingham <[email-masked]>
Date: Tue, 5 Feb 2019 10:30:46 +1100

Hi Kathleen,

Thanks for the thorough review. Responses below.

> On 31 Jan 2019, at 3:28 am, Kathleen Moriarty <[email-masked]> wrote:
> 
> Reviewer: Kathleen Moriarty
> Review result: Has Nits
> 
> Thank you, Mark and others for your work on this document to update the
> specification.  My comments are mainly requests for clarity in the document and
> text suggestions are provided to hopefully make this as easy as possible.
> 
> 1. Section 3: Nit:
> In my opinion, the flow would be improved if the third paragraph came before
> the current second paragraph.
> 
> 2. Could you provide a transitional sentence between the current second
> paragraph and the instructions that follow since the current second paragraph
> points to following section 5.1 for instructions, but paragraph 4+ include
> instructions or guidance followed by additional helpful information.  I think a
> slight adjustment as follows to accomplish this would be quite helpful to the
> reader:
> 
>   Applications that wish to mint new well-known URIs MUST register
>   them, following the procedures in Section 5.1 and the following requirements.

All of the above incorporated, the latter with a minor adjustment. Thanks.

> 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 "[email-masked]" 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 "[email-masked]" 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).

> 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."

> 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.

> 6. Section 3.1:  Is the following referring to IETF standards-track documents
> or could other standards from other SDOs (or some other constraint) be included?
> 
>   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".

The intent was values defined by Open Standards, in the sense of RFC2026, 7.1.1. I'll clarify this, thanks.

> I'm guessing a standards track RFC is not necessary for standards track because
> of the next paragraph in this section, but maybe some added text would help to
> clarify the above paragraph?
> 
>   Provisional entries can be removed by the Experts if - in
>   consultation with the community - the Experts find that they are not
>   in use.  The Experts can change a provisional entry's status to
>   permanent at any time.

Except for the issue above, I don't see how this is unclear; if a value is defined by a standard, it is automatically permanent, but other values can be as well, as per the text. Can you suggest text?

> 7. Section 5.1 second paragraph has the following text:
> 
>   Well-known URIs are registered on the advice of one or more experts
>   (appointed by the IESG or their delegate), with a Specification
>   Required (using terminology from [RFC8126]).
> 
> This should read as follows according to RFC8126 section 5.2.1:
> https://tools.ietf.org/html/rfc8126#section-5.2.1
> 
>   Well-known URIs are registered on the advice of one or more experts
>   (appointed by the IESG), with a Specification
>   Required (using terminology from [RFC8126]).
> 
> There's no provision for the IESG to delegate assignment of an expert.  IESG
> member often consult working group chairs and experts, but the assignment is
> currently performed by the IESG unless RFC8126 gets updated.

My understanding is that this level of detail is unnecessary in the registering document, as the IESG has the power to delegate naturally. If this needs to be specified explicitly, that should be done in a revision of RFC8126 section 5.2.1, not here.

> 9. Section 5.1:
> There may be additional information I am not aware of, hence the following
> clarifying questions. Is there a hold on the registry from now until this
> document is published?  Could an expert receive a request prior to publication
> where they feel the right status is "provisional" and is timely (cannot wait
> until after actions for this document are complete)?  I'm asking because of the
> following text and the answer may be yes, there is a hold, but I am not seeing
> where one is listed.  Since the expert can update the registry at any time, is
> the second bullet necessary (could it cause problems)?
> 
>   Upon publication, IANA should:
> 
>   o  Replace all references to RFC 5988 in that registry have been
>      replaced with references to this document.
> 
>   o  Update the status of all existing registrations to "permanent".

We've been processing registration requests as normal throughout the development period of this draft. When a registration request appears to violate the intent of 5785 but is OK by 5785bis (which we believe represents emerging consensus), I (wearing the Expert hat) have escalated them to the ADs to confirm an exception.

Part of the urgency in getting this document published is that I'm uncomfortable with that, and of course it's onerous for all concerned.

The second bullet shouldn't interfere with that.

Cheers and thanks again,

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

---

From: Alexey Melnikov <[email-masked]>
Date: Tue, 05 Feb 2019 11:00:50 +0000

Hi all,
On one specific issue raised by Kathleen:

> > On 31 Jan 2019, at 3:28 am, Kathleen Moriarty <[email-masked]> wrote:

 (snip)

> My understanding is that this level of detail is unnecessary in the 
> registering document, as the IESG has the power to delegate naturally. 
> If this needs to be specified explicitly, that should be done in a 
> revision of RFC8126 section 5.2.1, not here.

Mark, I think you are actually agreeing that the part "or their delegate" can be deleted, as this can happen naturally during IESG deliberations. While nothing prevents IESG from asking a third party to pick an expert, IESG has never done this and the final authority to decide stays with IESG.

Best Regards,
Alexey

---

From: Mark Nottingham <[email-masked]>
Date: Wed, 6 Feb 2019 09:26:16 +1100

> On 5 Feb 2019, at 10:00 pm, Alexey Melnikov <[email-masked]> wrote:
> 
[snip]
> Mark, I think you are actually agreeing that the part "or their delegate" can be deleted, as this can happen naturally during IESG deliberations. While nothing prevents IESG from asking a third par…

Ah - I missed that, my apologies. Fixed.

---

From: Kathleen Moriarty <[email-masked]>
Date: Thu, 14 Feb 2019 19:20:23 -0500

Hi Mark,

Thanks for your response and agreed updates.  I'll cut out anything
addressed and what was addressed from Alexey's email to simplify.

On Mon, Feb 4, 2019 at 6:30 PM Mark Nottingham <[email-masked]> wrote:

> 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.

> 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:

By standards-defined, do you mean through specification required in the
IETF?

> 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.

> 7.1.1. I'll clarify this, thanks.

Thank you!

> Except for the issue above, I don't see how this is unclear; if a value is
> defined by a standard, it is automatically permanent, but other values can
> be as well, as per the text. Can you suggest text?
>
>
> I'm rushing a bit right now, so sorry. I think the adjustment to the text
above may help solve this.  I'm happy to look at your revised version to
see if I think it may not be clear enough for some readers.  Thanks.

> registering document, as the IESG has the power to delegate naturally. If
> this needs to be specified explicitly, that should be done in a revision of
> RFC8126 section 5.2.1, not here.
>

I believe you are addressing this per the message exchange with Alexey.
Thank you.

> We've been processing registration requests as normal throughout the
> development period of this draft. When a registration request appears to
> violate the intent of 5785 but is OK by 5785bis (which we believe
> represents emerging consensus), I (wearing the Expert hat) have escalated
> them to the ADs to confirm an exception.
>
> Part of the urgency in getting this document published is that I'm
> uncomfortable with that, and of course it's onerous for all concerned.
>

Thanks for the clarification here and the updates, that's helpful.

Best regards,
Kathleen

-- 

Best regards,
Kathleen

---

From: Mark Nottingham <[email-masked]>
Date: Fri, 15 Feb 2019 17:52:44 +1100

Cutting down to specific replies --

> On 15 Feb 2019, at 11:20 am, Kathleen Moriarty <[email-masked]> wrote:
>> 
>> > 3. Section 3.1 says:
> 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).

> 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".
"""

> 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,

---

From: Barry Leiba <[email-masked]>
Date: Fri, 15 Feb 2019 09:59:38 -0500

> 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).

What I think Kathleen is asking isn’t to have the document specify the
registration details, but to make sure the registry header does.  The
document says to use the instructions in the registry, but there are no
instructions in the registry.  Either the document has to bootstrap that by
giving an initial set of instruction to put there, or the registry has to
have registration instructions that we can sanity-check now.  It doesn’t.

If the document says to see the registry for registration instructions,
there had better be instructions there, no?

Barry

---

From: Mark Nottingham <[email-masked]>
Date: Mon, 18 Feb 2019 13:16:31 +1100

> On 16 Feb 2019, at 1:59 am, Barry Leiba <[email-masked]> wrote:
> 
> 
> What I think Kathleen is asking isn’t to have the document specify the registration details, but to make sure the registry header does.  The document says to use the instructions in the registry, but there are no instructions in the registry.  Either the document has to bootstrap that by giving an initial set of instruction to put there, or the registry has to have registration instructions that we can sanity-check now.  It doesn’t.
> 
> If the document says to see the registry for registration instructions, there had better be instructions there, no?

Yes, but if we put the instructions in the RFC, people are likely to follow them -- even when they have been changed down the line. Also, it creates confusion as to whether it's necessary to update the RFC if they change.

The text we're discussing is sourced from RC8288:
  https://tools.ietf.org/html/rfc8288#section-4.2
... which didn't have any such discussion around it. If we're going to continue this, I'd like to hear from IANA itself about what level of instruction it'd like. As I've said, the last time around (8288), I got feedback from them that such a level of detail in the RFC was counterproductive, and that we could trust folks -- and our process -- to do the right thing.

Regards,

---

From: Barry Leiba <[email-masked]>
Date: Sun, 17 Feb 2019 21:35:39 -0500

> Yes, but if we put the instructions in the RFC, people are likely to follow them -- even when they have been
> changed down the line. Also, it creates confusion as to whether it's necessary to update the RFC if they change.
>
> ... which didn't have any such discussion around it. If we're going to continue this, I'd like to hear from IANA
> itself about what level of instruction it'd like. As I've said, the last time around (8288), I got feedback from them
> that such a level of detail in the RFC was counterproductive, and that we could trust folks -- and our
> process -- to do the right thing.

I agree with all that, but that still misses the point:
When someone reads in the RFC that they should follow the instructions
in the registry, and they go look at the registry and see nothing,
what are they to do?

b

---

From: Mark Nottingham <[email-masked]>
Date: Mon, 18 Feb 2019 13:37:24 +1100

> On 18 Feb 2019, at 1:35 pm, Barry Leiba <[email-masked]> wrote:
> 

Because, by the time this becomes an RFC, I (the expert of the registry, IESG still willing), will work with IANA to get that set up. Probably during AUTH48.

---

From: Barry Leiba <[email-masked]>
Date: Sun, 17 Feb 2019 21:50:05 -0500

> Because, by the time this becomes an RFC, I (the expert of the registry, IESG still willing), will
> work with IANA to get that set up. Probably during AUTH48.

It would be nice if that were already done, but I'm good with that
assurance.  Kathleen?

b

---

From: Mark Nottingham <[email-masked]>
Date: Mon, 18 Feb 2019 13:58:04 +1100

> It would be nice if that were already done, but I'm good with that

It seemed rash to set up the new process before the document was approved.

Cheers,

---

From: Kathleen Moriarty <[email-masked]>
Date: Mon, 18 Feb 2019 12:07:28 -0500

> It seemed rash to set up the new process before the document was approved.

I'll leave it up to the current ADs, but having text that says something
like:

"The instructions included below are the initial set  to be used by IANA
and entered on the registry.  Subsequent updates will be made directly to
the registry, therefore that set is considered authoritative."

Would be helpful to avoid confusion.

Best regards,
Kathleen

-- 

Best regards,
Kathleen

---

From: Julian Reschke <[email-masked]>
Date: Mon, 18 Feb 2019 19:14:26 +0100

On 18.02.2019 18:07, Kathleen Moriarty wrote:
> 
> 
> On Sun, Feb 17, 2019 at 9:58 PM Mark Nottingham <[email-masked] 
> <mailto:[email-masked]>> wrote:
> 
>     On 18 Feb 2019, at 1:50 pm, Barry Leiba <[email-masked]
>     <mailto:[email-masked]>> wrote:
>      >
> and entered on the registry.  Subsequent updates will be made directly 
> to the registry, therefore that set is considered authoritative."
> 

...and mark that section for removal before publication as RFC.

Best regards, Julian