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

Mark Nottingham <> Fri, 15 February 2019 06:52 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id ACB18130E7E; Thu, 14 Feb 2019 22:52:56 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2.7
X-Spam-Status: No, score=-2.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: (amavisd-new); dkim=pass (2048-bit key) header.b=E3PQiQG1; dkim=pass (2048-bit key) header.b=6yaSYl+D
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id Bqj_CjWIzpXF; Thu, 14 Feb 2019 22:52:53 -0800 (PST)
Received: from ( []) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 3D2B4129741; Thu, 14 Feb 2019 22:52:53 -0800 (PST)
Received: from compute3.internal (compute3.nyi.internal []) by mailout.west.internal (Postfix) with ESMTP id 0D4E62FEE; Fri, 15 Feb 2019 01:52:51 -0500 (EST)
Received: from mailfrontend1 ([]) by compute3.internal (MEProxy); Fri, 15 Feb 2019 01:52:52 -0500
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; h= content-type:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; s=fm1; bh=Q VdyvwgP5lJSDMQzSCdoc4SdXstsZM1l3fTZwmur2hI=; b=E3PQiQG128b2oZFbK iW1bWLQQSRKBml0eeu0P14Qpo7v4oPQxQQB2ttAA1PtXplKMxp73a36WCML2FxCZ mGxsxe/xqN1/f8eimoTD2WFOBCNgKhjXegYzTOxhhsGJTqOQKdcemwr41mVWiOV9 H8EGZ8xXO6yVYyFflrEQ+iUT4oXPv4EQGLBbmtktNzvelMC4Z14OR63tEs17zb3a +uZetOHoHhW70LSSIxx9KdLbrIpmOiDDlqcSoH+lNG+uBReq+4St2LfhsUgOzM3e /67YIXQbCsu9S+sK0VqyIXpjykPaDExec5Uvn9SWMsyAuK1hR5RG6MHnAzONf7y+ Q6Euw==
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=; h=cc:content-transfer-encoding:content-type :date:from:in-reply-to:message-id:mime-version:references :subject:to:x-me-proxy:x-me-proxy:x-me-sender:x-me-sender :x-sasl-enc; s=fm2; bh=QVdyvwgP5lJSDMQzSCdoc4SdXstsZM1l3fTZwmur2 hI=; b=6yaSYl+DDrCDvZBeWwvgqWS2hCQmoPbhg9AcTn4zbvfqN1X/RnKWWWtf2 RqKCuuWCJigAYqhuTEirNcmYHMhFzCEMKV7+X/nhjlkCW/cs4TDb7JdmPhJY9/BY GFzSC3alUmSy6eW/ru23mz8UE4kAGwOjlZt0hD011FQqapZsl+gvg6BtuB117qXW qNJocq2FA3FAhsQUkMlRZpjK0S7plnAT4Uh/OWhrszynIXmT8oSe6ODvagTcfeOn umHP1xG9p1PudPnbxHgWns5maiuYwv2r2Xwx0py0aQJWn7ISE1aQler8XZMi3LOB 5qU9rvXJGom7/e2DqyodLKRGMdKvw==
X-ME-Sender: <xms:wmFmXJpC5K2U59bCQ5wPxEpssa4L16UW_x65eG7IIG-sGj79vlNk1g>
X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgedtledruddtiedgleejucetufdoteggodetrfdotf fvucfrrhhofhhilhgvmecuhfgrshhtofgrihhlpdfquhhtnecuuegrihhlohhuthemucef tddtnecusecvtfgvtghiphhivghnthhsucdlqddutddtmdenucfjughrpegtggfuhfgjff fgkfhfvffosehtqhhmtdhhtddvnecuhfhrohhmpeforghrkhcupfhothhtihhnghhhrghm uceomhhnohhtsehmnhhothdrnhgvtheqnecuffhomhgrihhnpehmnhhothdrnhgvthdpih grnhgrrdhorhhgnecukfhppedugeegrddufeeirddujeehrddvkeenucfrrghrrghmpehm rghilhhfrhhomhepmhhnohhtsehmnhhothdrnhgvthenucevlhhushhtvghrufhiiigvpe dt
X-ME-Proxy: <xmx:wmFmXGyo5YbgCpxbnT88tfxsDR0txdowAJ7muMAedaFWzM6gIbUbUw> <xmx:wmFmXAjuHYjTD8_789UFuMwkoNHmLHAdPDVaJFiAm0mrGZL93aQFdA> <xmx:wmFmXBeBwtZXcqTYtOCdXJ52RX3FM8Qp__DuaROB4_YtboaR4BffQA> <xmx:w2FmXI_TX5cNt-A-6yu7FcgblEo1xxyriV1fSfZhCDrRhZ_rZEPU1g>
Received: from (unknown []) by (Postfix) with ESMTPA id 29E3BE4438; Fri, 15 Feb 2019 01:52:47 -0500 (EST)
Content-Type: text/plain; charset="us-ascii"
Mime-Version: 1.0 (Mac OS X Mail 12.2 \(3445.102.3\))
From: Mark Nottingham <>
In-Reply-To: <>
Date: Fri, 15 Feb 2019 17:52:44 +1100
Cc: IETF SecDir <>,, IETF <>
Content-Transfer-Encoding: quoted-printable
Message-Id: <>
References: <> <> <>
To: Kathleen Moriarty <>
X-Mailer: Apple Mail (2.3445.102.3)
Archived-At: <>
Subject: Re: [secdir] Secdir last call review of draft-nottingham-rfc5785bis-08
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Security Area Directorate <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Fri, 15 Feb 2019 06:52:57 -0000

Cutting down to specific replies --

> On 15 Feb 2019, at 11:20 am, Kathleen Moriarty <> wrote:
>> > 3. Section 3.1 says:
>> > The "Well-Known URIs" registry is located at
>> >   "".  Registration
>> >   requests can be made by following the instructions located there or
>> >   by sending an email to the "" 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
>> >   "".  Registration
>> >   requests can be made by following the instructions in this document and
>> >   sending the email to the "" 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