Return-Path: X-Original-To: secdir@ietfa.amsl.com Delivered-To: secdir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8BA2B130DC0; Thu, 14 Feb 2019 16:21:04 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.998 X-Spam-Level: X-Spam-Status: No, score=-1.998 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zmoi9H989nSG; Thu, 14 Feb 2019 16:21:01 -0800 (PST) Received: from mail-ot1-x32e.google.com (mail-ot1-x32e.google.com [IPv6:2607:f8b0:4864:20::32e]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0A723128B36; Thu, 14 Feb 2019 16:21:01 -0800 (PST) Received: by mail-ot1-x32e.google.com with SMTP id 98so13832688oty.1; Thu, 14 Feb 2019 16:21:01 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=n922hV57y+jskmn52X15GpclegwaH6D8lBZZTCJYE24=; b=Yhrr4U9MeDYsUUwjQl+oMAsav05xrdLeJJAszWVf6MwxY0qNrG3qvr0+0eamRgzP+R EqLNn9+FJdpZDaDxHhDbqQoKgM8EVze6mG38LNT5C78uCZkcL2HkKdIMWfLP9pH00IiH YpuP8hwLxlyTXMmdvFbzZ48ZC/FjX6Mw2JCWqD2WI/Hf29iy4odRLHlPV8kwNcF9hJVE /vKa/qtOG+cFjvjC+tAfZIc6IWRGfgvvwIRMsib9JQ9UFScjq6XZr4GhYXEFSNWQF4Dc 1Xjpm8SgmKsIrkjVyu7Qy+qkGizQcTyYqTvxpxiTlp/MQm2pvGo5cbna1EXrFvPY4pX6 B55A== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=n922hV57y+jskmn52X15GpclegwaH6D8lBZZTCJYE24=; b=UWSTWR4WX824ku+5WxE+VSHNY6SApFGc4GonVtt/CJDke4vd6IUkLFE4ycAxqKtYiy 1A6C9TybuPFBha2LeZ/qO9Rp7tGB/6Qk9CjwEKoRhy8y1Q292W63PLISA8sUd5uiPrNj +JsNNghgl5VchnNr1QTdZUEcBlDfZtSC4yj0w/yDRbdoAif7zfxAJ0mZ4Zit/TggiFRN pNMp/sSljPEGAfg5mqgWnFuRHPx0ZOVc71ZP4QLaEjK+rTQn+d6hnIawV/NZoFlrMjZW AwE0004Y1+mG79DZTJamSt4S75QJmhjCugRRdLBzAj2zvqS8THongMf8GwMw9wPQD2MP MGwA== X-Gm-Message-State: AHQUAuZoZeg0lL+lyF5GWeDMsCdJYzUo8i896Vwbxhyo/ecx+/XK6Upe Ao39rqQDQ5nQlf2H7Y9lIM8N235BydGqzUKoV5YumyVt X-Google-Smtp-Source: AHgI3IahxqoxtK7P8N1B76QQHLY876x07NNjw+Llzu8lqLK32LR7JAlf8OefUxsG655XH5LcWB5gn962PYjmtF66tYc= X-Received: by 2002:a54:4391:: with SMTP id u17mr3951416oiv.111.1550190060271; Thu, 14 Feb 2019 16:21:00 -0800 (PST) MIME-Version: 1.0 References: <154886569351.10484.4703007670359734409@ietfa.amsl.com> In-Reply-To: From: Kathleen Moriarty Date: Thu, 14 Feb 2019 19:20:23 -0500 Message-ID: To: Mark Nottingham Cc: IETF SecDir , draft-nottingham-rfc5785bis.all@ietf.org, IETF Content-Type: multipart/alternative; boundary="000000000000e082890581e3bf46" Archived-At: Subject: Re: [secdir] Secdir last call review of draft-nottingham-rfc5785bis-08 X-BeenThere: secdir@ietf.org 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 00:21:05 -0000 --000000000000e082890581e3bf46 Content-Type: text/plain; charset="UTF-8" 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 wrote: > Hi Kathleen, > > Thanks for the thorough review. Responses below. > > > > On 31 Jan 2019, at 3:28 am, Kathleen Moriarty < > kathleen.moriarty.ietf@gmail.com> wrote: > > > > Reviewer: Kathleen Moriarty > > Review result: Has Nits > > > > 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 > > 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 "wellknown-uri-review@ietf.org" 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. > > > 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? > > 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. > > > 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. > Thank you! > > > > 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? > > > 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. > > 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. > I believe you are addressing this per the message exchange with Alexey. Thank you. > > > 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. > Thanks for the clarification here and the updates, that's helpful. Best regards, Kathleen > > > Cheers and thanks again, > > -- > Mark Nottingham https://www.mnot.net/ > > -- Best regards, Kathleen --000000000000e082890581e3bf46 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hi Mark,

Thanks for yo= ur response and agreed updates.=C2=A0 I'll cut out anything addressed a= nd what was addressed from Alexey's email to simplify.

<= div class=3D"gmail_quote">
On Mon, Feb= 4, 2019 at 6:30 PM Mark Nottingham <mn= ot@mnot.net> wrote:
Hi Kathleen,

Thanks for the thorough review. Responses below.


> On 31 Jan 2019, at 3:28 am, Kathleen Moriarty <kathleen.moriarty.ietf@gm= ail.com> wrote:
>
> Reviewer: Kathleen Moriarty
> Review result: Has Nits


> 3. Section 3.1 says:
> The "Well-Known URIs" registry is located at
>=C2=A0 =C2=A0"https://www.iana.org/assignm= ents/well-known-uris/".=C2=A0 Registration
>=C2=A0 =C2=A0requests can be made by following the instructions located= there or
>=C2=A0 =C2=A0by sending an email to the "wellknown-uri-review@ietf.org= " mailing
>=C2=A0 =C2=A0list.
>
> I'm not clear on the instructions as I follow the link to the regi= stry and
> there's a pointer to the RFC that this document will obsolete.=C2= =A0 I'm assuming
> that the reference will be replaced with this document.=C2=A0 Is that = the case or
> are there additional instructions than what will be included directly = in the
> registry?=C2=A0 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.=C2=A0 This document is also= going through
> a review process to update that registry, so if instructions were main= tained at
> the registry URL, what would be the review process to alter the instru= ctions?
> 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 regi= stering
> values not adding them).=C2=A0 If the sentence should be changed, I su= ggest
> something like:
>
>=C2=A0 =C2=A0The "Well-Known URIs" registry is located at
>=C2=A0 =C2=A0"https://www.iana.org/assignm= ents/well-known-uris/".=C2=A0 Registration
>=C2=A0 =C2=A0requests can be made by following the instructions in this= document and
>=C2=A0 =C2=A0sending the email to the "wellknown-uri-review@ietf.org&q= uot; mailing
>=C2=A0 =C2=A0list.

After extensive consultation with IANA regarding RFC8288's revision of = registration policy, the outcome was that this level of detail / instructio= n 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 w= ith the IESG as necessary.

Personally I was a bit surprised by this, but also relieved; getting this s= ort of thing *exactly* right in an RFC is difficult, and we need the flexib= ility to change things (e.g., we're currently using a Github issue queu= e to collect registration requests there, but that might change in the futu= re).


What would be helpful here would be so= me text in the document that asks IANA to add the instructions to the regis= try.=C2=A0 I'm hoping that more clearly states my question/request.=C2= =A0=C2=A0
=C2=A0

> 4. Question on Change controller: Is it possible to successfully make = a request
> through an experimental track RFC or standards track only?=C2=A0 If ex= perimental is
> allowed, can it only be provisional?

The registry is Specification Required, so an experimental RFC can indeed m= ake a registry. It can be 'standard' if it meets this bar: "Ot= her values can also be registered as permanent, if the Experts find that th= ey 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=C2=
=A0
=C2=A0 = =C2=A0 =C2=A0 =C2=A0be registered as "provisional".=C2=A0 = =C2=A0

By standards-defined, do you mean through s= pecification required in the IETF?


> 5. Section 3 has the following sentence:
>
>=C2=A0 =C2=A0General requirements for registered relation types are des= cribed in
>=C2=A0 =C2=A0Section 3.
>
> Did the document in a previous revision contain something in section 3= about
> registered relation types or am I missing something when reading secti= on 3
> (which is entirely possible)?=C2=A0 If it were there (or maybe was in = a previous
> revision), I'd expect to see it in the following paragraph, but co= uld see the
> above text being dropped as an answer to this question as well (unless= I am
> missing something):
>
>=C2=A0 =C2=A0It MAY also contain additional information, such as the sy= ntax of
>=C2=A0 =C2=A0additional path components, query strings and/or fragment = identifiers
>=C2=A0 =C2=A0to be appended to the well-known URI, or protocol-specific= details
>=C2=A0 =C2=A0(e.g., HTTP [RFC7231] method handling).

Section 3 puts requirements on choosing a registered name, both syntactical= ly and with a more general SHOULD about how to choose a good name.

OK, can you clarify in the text what you mean b= y registered relation type or have that sentence say registered name instea= d of relation type since that is the only time registered relation type app= ears in the document?=C2=A0 I think that would help the reader.
<= br>



> 6. Section 3.1:=C2=A0 Is the following referring to IETF standards-tra= ck documents
> or could other standards from other SDOs (or some other constraint) be= included?
>
>=C2=A0 =C2=A0Standards-defined values have a status of "permanent&= quot;.=C2=A0 Other values
>=C2=A0 =C2=A0can also be registered as permanent, if the Experts find t= hat they
>=C2=A0 =C2=A0are in use, in consultation with the community.=C2=A0 Othe= r values should
>=C2=A0 =C2=A0be registered as "provisional".

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

Th= ank you!=C2=A0


> 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?
>
>=C2=A0 =C2=A0Provisional entries can be removed by the Experts if - in<= br> >=C2=A0 =C2=A0consultation with the community - the Experts find that th= ey are not
>=C2=A0 =C2=A0in use.=C2=A0 The Experts can change a provisional entry&#= 39;s status to
>=C2=A0 =C2=A0permanent 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?


I'm rushing a bit right now, so sorry. I think th= e adjustment to the text above may help solve this.=C2=A0 I'm happy to = look at your revised version to see if I think it may not be clear enough f= or some readers.=C2=A0 Thanks.
=C2=A0
> 7. Section 5.1 second paragraph has the following text:
>
>=C2=A0 =C2=A0Well-known URIs are registered on the advice of one or mor= e experts
>=C2=A0 =C2=A0(appointed by the IESG or their delegate), with a Specific= ation
>=C2=A0 =C2=A0Required (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
>
>=C2=A0 =C2=A0Well-known URIs are registered on the advice of one or mor= e experts
>=C2=A0 =C2=A0(appointed by the IESG), with a Specification
>=C2=A0 =C2=A0Required (using terminology from [RFC8126]).
>
> There's no provision for the IESG to delegate assignment of an exp= ert.=C2=A0 IESG
> member often consult working group chairs and experts, but the assignm= ent is
> currently performed by the IESG unless RFC8126 gets updated.

My understanding is that this level of detail is unnecessary in the registe= ring document, as the IESG has the power to delegate naturally. If this nee= ds 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.=C2=A0 Thank you.=



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

We've been processing registration requests as normal throughout the de= velopment period of this draft. When a registration request appears to viol= ate the intent of 5785 but is OK by 5785bis (which we believe represents em= erging consensus), I (wearing the Expert hat) have escalated them to the AD= s to confirm an exception.

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

The second bullet shouldn't interfere with that.
<= br>
Thanks for the clarification here and the updates, that's= helpful.

Best regards,
Kathleen=C2=A0


Cheers and thanks again,

--
Mark Nottingham=C2=A0 =C2=A0https://www.mnot.net/



--

Best regards,
Kathleen
--000000000000e082890581e3bf46--