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

From: John C Klensin <[email-masked]>
Date: Sun, 29 Mar 2015 16:05:41 -0400

(reposting -- the IETF mail system apparently didn't like the
"implicit" copy to apps-discuss)

--On Sunday, March 29, 2015 15:05 +0100 Alexey Melnikov
<[email-masked]> wrote:

> On 27/03/2015 19:29, Barry Leiba wrote:
>>> I will send email responses to the feedback received with
>>> what we did. I may not get those out today though. But I
>>> think the doc should be ready for the IESG telechat.
>> Thanks.  I've issued the ballot; I'll wait to change the
>> state until I hear that your co-authors & shepherd are OK
>> with it.
> This is almost perfect :-).
> 
> A couple of comments:
>...
> Here is a real world example of a problem with this text. SIDR
> WG decided to use rsync protocol, they needed to use rsync
> URIs. rsync URIs are currently provisional, defined in an
> Informational RFC.  So this text is basically saying that
> under the new rule the registration have to be upgraded to
> Permanent, allowing the expert reviewer (no disrespect to
> Graham or his future replacement) to be a person that blocks
> consensus of a WG to use a particular technology. I find this
> to be problematic.
> 
> Do people agree that this is problematic?

Yes.

At the risk of tossing a spanner toward the works, one more
issue that seems to me very significant:

Larry Masinter has raised several issues in the URNBIS WG in
which he claims that draft-ietf-appsawg-uri-scheme-reg
constrains what that WG is proposing to do with URNs [1].  I
also believe that some of his comments mix up registration of
schemes (e.g., "urn:") with registrations of URN namespaces and
NIDs  I think those issues need to be considered in that WG.
However, procedurally, it seems to me that either:

(1) Existing registrations are existing registrations and any
updates to them are grandfathered, i.e., whatever
draft-ietf-appsawg-uri-scheme-reg says is not applicable to the
original or updated registration of any URI scheme registered or
deployed before it is approved and published.  That obviously
includes the revised URN registration contemplated by
draft-ietf-urnbis-rfc2141bis-urn.

(2) We have a mess on our hands in which not only do the
mandates of different WGs overlap but in which an area WG that
is not noted for very intense reviews can constrain and override
the work of more topic-focused (and, therefore, presumably more
expert on their own topics) WGs and other efforts.  This is
particularly problematic in the case of URIs, where parallel
(and not entirely consistent) work is going on to further
develop specific URI schemes (URNs being only one such example)
and groups outside the IETF (including WHATWG and W3C groups)
with coordination processes that are still being negotiated and
in groups that are heavily dependent on URIs and URI handling
(certainly including HTTPbis).  

If it is applicable to existing registrations and ongoing work
in other WGs, this spec is even more problematic because it is
heavily dependent on details of RFC 3986, a specification whose
exact meaning, implications, and consequences continue to be
debated and which is a candidate for preemption or replacement
by those other bodies.

I suggest that any IESG action on
draft-ietf-appsawg-uri-scheme-reg be deferred until which of the
above principles applies can be clarified (and clarified in the
document) and, if the second option is chosen, that formal
reviews and impact assessments be sought from all active WGs
that are involved with or use URIs as well as from W3C.

Sorry to be raising this so late in the process, but it never
occurred to me that anyone would claim that
draft-ietf-appsawg-uri-scheme-reg constrained other IETF WGs,
standards-track updates to existing registrations that were made
as the result of standards actions, etc.  Since that claim has
now been made, and made by one of the authors of the new draft
who presumably understands the intent, a "wait a minute"
response seems necessary.

     john

[1]
http://www.ietf.org/mail-archive/web/urn/current/msg02873.html

---

From: Graham Klyne <[email-masked]>
Date: Tue, 31 Mar 2015 19:10:38 +0100

>> Do people agree that this is problematic?

To a point, but I think it should be resolvable (I'm responding without 
cross-checking the original or revised registration procedure).

Under the circumstances that a WG has achieved consensus to use a particular 
scheme, I think there's sufficient grounds to upgrade its registration to 
permanent.  I think a request to do so should come from the WG concerned (I 
think that's doable within the current and new spec), and preferably as part of 
the IANA considerations for the spec that uses it.  That would bring the issue 
to DE's attention with appropriate context.

I don't think think this gives the DE any greater power of veto than they 
already have with respect to a WG consensus request to register a new permanent 
scheme.

#g
--

> _______________________________________________
> apps-discuss mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/apps-discuss
>

---

From: Graham Klyne <[email-masked]>
Date: Tue, 31 Mar 2015 19:10:38 +0100

#g
--

---

From: Alexey Melnikov <[email-masked]>
Date: Wed, 1 Apr 2015 02:40:25 +0100

Hi,

> On 31 Mar 2015, at 19:10, Graham Klyne <[email-masked]> wrote:
> 
> To a point, but I think it should be resolvable (I'm responding without cross-checking the original or revised registration procedure).
> 
> Under the circumstances that a WG has achieved consensus to use a particular scheme, I think there's sufficient grounds to upgrade its registration to permanent.  I think a request to do so should come from the WG concerned (I think that's doable within the current and new spec), and preferably as part of the IANA considerations for the spec that uses it.  That would bring the issue to DE's attention with appropriate context.
> 
> I don't think think this gives the DE any greater power of veto than they already have with respect to a WG consensus request to register a new permanent scheme.

I would think slightly more comfortable if the document has a paragraph discussing the above (pretty much using what you said).

But if others don't think this is an issue, I will let it go.

---

From: Alexey Melnikov <[email-masked]>
Date: Wed, 1 Apr 2015 02:40:25 +0100

Hi,