Re: [apps-discuss] FW: New Version Notification - draft-ietf-appsawg-uri-scheme-reg-05.txt

Graham Klyne <gk@ninebynine.org> Sat, 04 April 2015 16:07 UTC

Return-Path: <gk@ninebynine.org>
X-Original-To: apps-discuss@ietfa.amsl.com
Delivered-To: apps-discuss@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B32BF1B2BE8 for <apps-discuss@ietfa.amsl.com>; Sat, 4 Apr 2015 09:07:16 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.2
X-Spam-Level:
X-Spam-Status: No, score=-4.2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3] autolearn=ham
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 NK75nypLr_nG for <apps-discuss@ietfa.amsl.com>; Sat, 4 Apr 2015 09:07:13 -0700 (PDT)
Received: from relay11.mail.ox.ac.uk (relay11.mail.ox.ac.uk [129.67.1.162]) by ietfa.amsl.com (Postfix) with ESMTP id B73B61B2BE7 for <apps-discuss@ietf.org>; Sat, 4 Apr 2015 09:07:13 -0700 (PDT)
Received: from smtp4.mail.ox.ac.uk ([129.67.1.207]) by relay11.mail.ox.ac.uk with esmtp (Exim 4.80) (envelope-from <gk@ninebynine.org>) id 1YeQbI-0005BJ-aa for apps-discuss@ietf.org; Sat, 04 Apr 2015 17:07:12 +0100
Received: from host109-152-232-46.range109-152.btcentralplus.com ([109.152.232.46] helo=cheery.atuin.ninebynine.org) by smtp4.mail.ox.ac.uk with esmtpsa (TLS1.2:DHE_RSA_AES_128_CBC_SHA1:128) (Exim 4.80) (envelope-from <gk@ninebynine.org>) id 1YeQbI-0002eh-DY for apps-discuss@ietf.org; Sat, 04 Apr 2015 17:07:12 +0100
Message-ID: <55200C35.1000708@ninebynine.org>
Date: Sat, 04 Apr 2015 17:07:17 +0100
From: Graham Klyne <gk@ninebynine.org>
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:31.0) Gecko/20100101 Thunderbird/31.3.0
MIME-Version: 1.0
To: apps-discuss@ietf.org
References: <AA97D55A3E3E06CE73D24AFA@JcK-HP8200.jck.com> <551AE31E.1070009@ninebynine.org> <306B3AB5-02E3-4958-9D05-4E4FF82AD114@isode.com> <266EAB2393341CF1F491F327@JcK-HP8200.jck.com> <551D0C47.5090603@ninebynine.org> <C3838203B5FC4AD3EC2B6082@JcK-HP8200.jck.com>
In-Reply-To: <C3838203B5FC4AD3EC2B6082@JcK-HP8200.jck.com>
Content-Type: text/plain; charset="windows-1252"; format="flowed"
Content-Transfer-Encoding: 7bit
X-Oxford-Username: zool0635
Archived-At: <http://mailarchive.ietf.org/arch/msg/apps-discuss/gog9OgpnQNesAl2qCzm_X3njEmo>
Subject: Re: [apps-discuss] FW: New Version Notification - draft-ietf-appsawg-uri-scheme-reg-05.txt
X-BeenThere: apps-discuss@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: General discussion of application-layer protocols <apps-discuss.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/apps-discuss>, <mailto:apps-discuss-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/apps-discuss/>
List-Post: <mailto:apps-discuss@ietf.org>
List-Help: <mailto:apps-discuss-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/apps-discuss>, <mailto:apps-discuss-request@ietf.org?subject=subscribe>
X-List-Received-Date: Sat, 04 Apr 2015 16:07:16 -0000

John,

>> You mean
>> https://tools.ietf.org/html/draft-ietf-urnbis-rfc2141bis-urn-1
>> 1#section-7.2 ?
>
> Yes.
>
>> I'm seeing:
>>
>> "For namespaces or their definitions that are intended to
>> become standards
>>      or normative components of standards, the output of the
>> Expert Review
>>      process is intended to be a report, rather than
>> instructions to IANA
>>      to take action (see below)."
>>
>> and
>>
>> "If standardization is anticipated, the designated
>>          experts will prepare a report and forward it to the
>> appropriate
>>          standards approval body (the IESG in the case of the
>> IETF) and
>>          IANA will register the requested NID only after
>> receiving
>>          directions from that body and a copy of the expert
>> review report."
>>
>> I'm OK with this in principle but have a couple of possible
>> concerns:
>>
>> 1. "prepare a report" starts to sound a bit heavyweight.
>
> I didn't like it either, but it was the best I could come up
> with when I was writing that.  Better wording would be welcome.

Let's see:

...

"For namespaces or their definitions that are intended to become standards or 
normative components of standards, the output of the Expert Review process is 
intended to be a report, rather than instructions to IANA to take action (see 
below)."

I think this may be redundant.  When a request for registration is made, there 
are three possible outcomes:

1. DE says it's OK, in which case IANA makes the entry as requested.  I don't 
see any need to change this.  No "report" appears to be needed in this case.

2. DE has a problem with the request, in which case the reasons are fed back to 
the submitter (which may be an IETF working group or some other standards body). 
  I think this corresponds to your "report".

3. DE has reservations and recommends registration with additional "health 
warning".  In practice, this does not happen until there has been some dialogue 
following (2).

...

"If standardization is anticipated, the designated experts will prepare a report 
and forward it to the appropriate standards approval body (the IESG in the case 
of the IETF) and IANA will register the requested NID only after receiving 
directions from that body and a copy of the expert review report."

I'm finding there's devil in the detail here.  I think the effect of this would 
be (a) to complicate the process, and (b) to reduce the DE's discretion to 
recommend acceptance of a straitforward registration request.

If standardization is anticipated, I look for some indication that the standards 
process (IETF or otherwise) is being followed appropriately, and that is 
sufficiently well advanced (e.g., in the IETF, passing last call for Proposed 
Standard.);  in practice, if the approval for standards action is not yet 
achieved, I recommend provisional registration until that point.

So my suggestion would be, rather than to actually change the procedure to 
introduce formally defined lines of reporting, to provide some guidelines for 
anticipated standards submissions; e.g.

"If standardization is anticipated, the working group or individuals concerned 
are advised to submit an early permanent registration request, rather than 
waiting until the standardization process has run its course.  IANA will pass 
this to the DE who may recommend provisional registration until the 
specification is approved as a standard.  This will provide opportunity for 
feedback while specification development and review is still active, and the 
submitter(s) are still in a position to respond to any issues that might be 
raised.  If and when the specification is approved as a standard, the submitters 
should submit a request to change the registration status to permanent."

I think something like this can work for any standardization organization or 
process and, in conjunction with the previous text suggested, positions the DE 
as part of the review process rather than a gatekeeper with power of veto over 
the standards process.

(I note that, currently, there is an arrangement that IANA will send me an early 
review request when an IETF  document goes to last call with a URI scheme 
registration request, so that my comments can be fed into the last call 
discussions.  But this wouldn't work so easily for other standards organizations.)

> However, unlike the URI registration case in which the
> presumption is that any formal standards process would be within
> the IETF, the URN namespace registration text anticipates
> handing off final review and approval to what the media type
> registration procedure calls "recognized standards bodies" when
> the namespaces themselves are under the control of those bodies.

Actually, that's my understanding of the URI scheme registration process.  For 
example, I would expect to give careful consideration to a permanent scheme 
proposed by a W3C working group.

> In some of those cases, especially if the DE concludes that the
> registration proposal is a hopeless mess, a "report" is going to
> be precisely what is needed.  My hope is that we can avoid any
> tendencies to overspecify that but the motivation is the same as
> it was with media types: if a namespace registration shows up
> that involves highly technical matters that are under the
> control of, or standardized by, some competent and recognized
> standards body or scientific group, having the IETF demonstrate
> community ignorance by debating the issues is not helpful to
> anyone.

That's pretty much what happens now.  Maybe there's scope for some additional 
guidance, e.g.

"If the DE feels unable to recommend acceptance of a requested permanent 
registration, they should respond to IANA stating this, along with their reasons 
and, if possible, what changes the submitter might be able offer to improve the 
submission, which IANA in term will relay to the submitter.  In cases where some 
discussion seems needed, the DE can also respond directly to the contact named 
in the submission (also advising IANA of this).  In such situations, the scheme 
may be registered provisionally while discussions are in progress."

I think this could cover pretty much the additional points and scenarios you 
discuss below.  There has already been some "corridor discussion" that including 
more helpful guidance might be more effective than creating a more detailed 
process (this was some time ago, and not much has happened since; we started to 
create a guidance FAQ on the IETF Wiki, but that initiative fizzled out.).  I 
also try to frame the DE's input as "recommendation" rather than "instruction" 
to IANA.

>>    If
>> we can be clear that a "report" may be a short email at the
>> level of "this is fine" or "I have concerns with <foo> and
>> <bar>" then it's OK.  But if you envisage something more
>> formal then that could (from my perspective) seriously impair
>> my ability to perform the DE role.
>
> See above.  I would hope that whatever reporting would occur
> would be appropriate to the circumstances.  Certainly, under the
> obvious circumstances (and remembering that the issue of
> delegation to other standards bodies is presumably not an issue
> for URI scheme registrations), "this is fine", "I don't see any
> issues", etc., would be perfectly reasonable "reports".
>
> Again, text suggestions for the URN namespace version of this
> would be very welcome.
>
>> 2. I am not sure that it is appropriate for the IETF to have a
>> procedure that requires us to become formally involved in the
>> machinations of external standards bodies.  We already have
>> and recommend submissions to the URI-review list, and the
>> registration procedures already operate to promote dialog with
>> external bodies (or individuals) who wish to make permanent
>> registrations, so I'm unconvinced that greater formality is
>> needed vis-a-vis interaction with external standards bodies.
>
> First, what was anticipated was closer to a delegation and
> handoff rather than "involved with the machinations".  Second,
> we've had provisions equivalent to this for many years (see,
> e.g., the discussion in Section 2.1.5 of RFC 2048).  The
> thinking that drove that model ran something like this: Suppose
> the IAU decided it need a media type for subplanetary objects or
> IUPAC decided it needed one for chemical synthesis of some
> flavor.  Noting that examples like that are actually far more
> likely for URN namespaces than for media types, while an Expert
> Review (and, if appropriate, advice) about whether the template
> was adequate and whether suggestions about format or syntax were
> in order, IETF debates about what objects or processes were to
> be included in the namespace or how they were to be named would
> not be helpful and might turn into a public embarrassment.
> Consider ISBNs as an example: I would hope that a Designated
> Expert would offer advice about the tradeoffs between allowing
> NSS strings both with and without hyphens, including those
> involving the two not being equal when comparisons were made
> using generic URI rules with no scheme-specific information or
> generic URN rules with no namespace-specific information.  It
> seems to me that neither of those is a showstopper that should
> block NID registration, but there should be an informed choice
> made and that the International ISBN Agency should make it, not
> the IETF (or the Designated Expert).
>
> Again, I am _not_ suggesting this is the right model for URI
> schemes even though, if things continue in the directions they
> seem to be going in lately, I can image some sort of deal being
> worked out between the IETF and W3C.
>
>> What I might do is suggest that external standards bodies make
>> initial registration requests early/ier in their process so
>> that they can receive and respond to feedback while there is
>> still scope to do so within the constraints of their process.
>> For example, to submit a permanent registration request early
>> on the understanding that it may initially be accepted
>> provisionally, and upgraded to permanent as and when any
>> concerns raised are resolved (including progression to the
>> appropriate status by the requesting organization).
>
> For URI schemes, I'm going to continue to try to not have an
> opinion.  For a variety of other registration activities,
> including DNS RRTYPEs and media types and I believe URN
> namespaces, I suggest that "provisional" or similar vocabulary
> has not worked out well because things get registered and
> deployed and then, when the time comes to standardize or make
> them permanent, the claim is made that they cannot be altered
> without causing serious disruption.  I am reminded that similar
> behavior sequences were part of what caused RFC 6648.

Well, I think that's always a tension.  Implementers will implement, then 
deploy!  The (perceived) failure of the old 'X-' convention was a big part of 
what lead to this more open, tiered style of registry.

#g
--