[secdir] Secdir last call review of draft-nottingham-rfc5785bis-08

Kathleen Moriarty <Kathleen.Moriarty.ietf@gmail.com> Wed, 30 January 2019 16:28 UTC

Return-Path: <Kathleen.Moriarty.ietf@gmail.com>
X-Original-To: secdir@ietf.org
Delivered-To: secdir@ietfa.amsl.com
Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 8E681131228; Wed, 30 Jan 2019 08:28:13 -0800 (PST)
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 7bit
From: Kathleen Moriarty <Kathleen.Moriarty.ietf@gmail.com>
To: secdir@ietf.org
Cc: draft-nottingham-rfc5785bis.all@ietf.org, ietf@ietf.org
X-Test-IDTracker: no
X-IETF-IDTracker: 6.90.0
Auto-Submitted: auto-generated
Precedence: bulk
Message-ID: <154886569351.10484.4703007670359734409@ietfa.amsl.com>
Date: Wed, 30 Jan 2019 08:28:13 -0800
Archived-At: <https://mailarchive.ietf.org/arch/msg/secdir/JU5lW5iwYu5oiogaLelnLo9zuDA>
Subject: [secdir] Secdir last call review of draft-nottingham-rfc5785bis-08
X-BeenThere: secdir@ietf.org
X-Mailman-Version: 2.1.29
List-Id: Security Area Directorate <secdir.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/secdir>, <mailto:secdir-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/secdir/>
List-Post: <mailto:secdir@ietf.org>
List-Help: <mailto:secdir-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/secdir>, <mailto:secdir-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 30 Jan 2019 16:28:14 -0000

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

   Applications that wish to mint new well-known URIs MUST register
   them, following the procedures in Section 5.1 and the following requirements.

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 "wellknown-uri-review@ietf.org" mailing

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 "wellknown-uri-review@ietf.org" mailing

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?

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

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

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.

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:

   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.

8. Section 5.1:  (additional context for #5)

Text adjustments in section 3 similar to what was proposed above may help avoid
confusion when someone reaches this text on requirements in section 3 so that
they are grouped and called out specifically as requirements. (No change
suggested here, but rather just expanding on the desire for clarification

   The Experts' primary considerations in evaluating registration
   requests are:

   o  Conformance to the requirements in Section 3

   o  The availability and stability of the specifying document

   o  The considerations outlined in Section 4

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

10.  For the IESG: Are there plans to name a second expert in case Mark isn't


I hope you find these comments helpful to further clarify the text of this

Thank you,