Re: registries and designated experts

"Martin J. Dürst" <duerst@it.aoyama.ac.jp> Mon, 18 June 2012 11:43 UTC

Return-Path: <duerst@it.aoyama.ac.jp>
X-Original-To: ietf@ietfa.amsl.com
Delivered-To: ietf@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4558321F8507 for <ietf@ietfa.amsl.com>; Mon, 18 Jun 2012 04:43:57 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -99.555
X-Spam-Level:
X-Spam-Status: No, score=-99.555 tagged_above=-999 required=5 tests=[AWL=0.235, BAYES_00=-2.599, HELO_EQ_JP=1.244, HOST_EQ_JP=1.265, MIME_8BIT_HEADER=0.3, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 44ddsMyqkPzt for <ietf@ietfa.amsl.com>; Mon, 18 Jun 2012 04:43:56 -0700 (PDT)
Received: from scintmta02.scbb.aoyama.ac.jp (scintmta02.scbb.aoyama.ac.jp [133.2.253.34]) by ietfa.amsl.com (Postfix) with ESMTP id 5332C21F84DD for <ietf@ietf.org>; Mon, 18 Jun 2012 04:43:47 -0700 (PDT)
Received: from scmse02.scbb.aoyama.ac.jp ([133.2.253.231]) by scintmta02.scbb.aoyama.ac.jp (secret/secret) with SMTP id q5IBhXr2007349 for <ietf@ietf.org>; Mon, 18 Jun 2012 20:43:33 +0900
Received: from (unknown [133.2.206.133]) by scmse02.scbb.aoyama.ac.jp with smtp id 65e6_0845_d4f990b0_b93a_11e1_bfbd_001d096c5782; Mon, 18 Jun 2012 20:43:32 +0900
Received: from [IPv6:::1] ([133.2.210.1]:52111) by itmail.it.aoyama.ac.jp with [XMail 1.22 ESMTP Server] id <S15D427B> for <ietf@ietf.org> from <duerst@it.aoyama.ac.jp>; Mon, 18 Jun 2012 20:43:33 +0900
Message-ID: <4FDF1462.5000506@it.aoyama.ac.jp>
Date: Mon, 18 Jun 2012 20:43:30 +0900
From: =?UTF-8?B?Ik1hcnRpbiBKLiBEw7xyc3Qi?= <duerst@it.aoyama.ac.jp>
Organization: Aoyama Gakuin University
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US; rv:1.9.1.9) Gecko/20100722 Eudora/3.0.4
MIME-Version: 1.0
To: Stephen Farrell <stephen.farrell@cs.tcd.ie>
Subject: Re: registries and designated experts
References: <4FCDD499.7060206@it.aoyama.ac.jp><4FCDE96E.5000109@cs.tcd.ie> <4FD7083A.6080502@it.aoyama.ac.jp><4FD74FFC.3050905@stpeter.im><6.2.5.6.2.20120612073602.09c8cbb8@resistor.net><4FD786DC.4090403@gmail.com><B416CA36462A3CA8C721BDF5@JcK-HP8200.jck.com> <4FD849A9.7000708@gmail.com> <EDC652A26FB23C4EB6384A4584434A0407B53CA1@307622ANEX5.global.avaya.com> <201206131248.q5DCmSL6028424@cichlid.raleigh.ibm.com> <4FDDD3B7.20507@it.aoyama.ac.jp> <4FDDDC8E.2060001@cs.tcd.ie>
In-Reply-To: <4FDDDC8E.2060001@cs.tcd.ie>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 8bit
Cc: Thomas Narten <narten@us.ibm.com>, John C Klensin <john-ietf@jck.com>, ietf@ietf.org, SM <sm@resistor.net>
X-BeenThere: ietf@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: IETF-Discussion <ietf.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/ietf>, <mailto:ietf-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/ietf>
List-Post: <mailto:ietf@ietf.org>
List-Help: <mailto:ietf-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/ietf>, <mailto:ietf-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 18 Jun 2012 11:43:57 -0000

Hello Stephen,

On 2012/06/17 22:33, Stephen Farrell wrote:
>
> Martin,
>
> On 06/17/2012 01:55 PM, "Martin J. Dürst" wrote:
>> This time, the situation was somewhat reversed: The expert approved the
>> registration, and this fact was then used as a claim that IETF Last Call
>> comments on the item registered were no longer appropriate.
>
> I'm sorry, but that's just not accurate. The specific comment (of
> yours) was to the effect that two registrations should become
> one.

[Minor detail: It was about merging two schemes. Merging the 
registrations is a consequence of merging the schemes, but not the core 
issue.]


> I believe its fair to say that that is something one
> could have expected to be raised on the uri-review list, given
> the comments typically sent to that list, and the comments we
> got there on our I-D,

I agree that, as you say below, it would have been better if the issue 
had been raised earlier. But that's the same all over the place; it 
would often have been better if an issue got raised earlier during WG 
discussion rather than later, during WG discussion rather than in WGLC, 
during WGLC rather than in IETF LC, during IETF LC rather than in IESG 
review, and so on. I also agree that nobody would have been surprised if 
such an issue had been brought up on the uri-review list.

But that's different from expecting a specific issue to be brought up in 
a specific place, and only there.

> and so I brought that up when you (who
> often comment on that list), only raised this during IETF LC.

[Minor detail: I don't consider myself a "frequent" contributor to that 
list. But of course frequency is relative.]

First: I mentioned the issue that having two different encodings (base64 
and base16) of the same data was a non-starter *way* earlier. If you 
didn't read that, or don't remember that anymore, it's not my fault.

Second: As explained earlier, my comments were part of an Apps 
Directorate review. When I'm doing an Apps Directorate review, I'm 
setting away time for that explicitly, and try to do a really thorough 
job, with a wide perspective. I can do that because I'm only doing one 
of these every few months. This is quite different from a registration 
mailing list where I'm not the Designated Expert, and can't devote that 
much time to each and every registration that comes by.

The Apps Directorate review is also intended to help the Apps ADs. I'd 
expect that they want to know everything that a reviewer thinks is 
relevant, rather than the reviewer suppressing stuff because he happens 
to be on a registration mailing list on that specific topic and didn't 
have time to look at the draft when it was passing by on that list.


> At no point did I claim that IETF LC comments were no longer
> appropriate, and indeed I've been responding al all IETF LC
> comments on their merits, including this one of yours.

You didn't explicitly claim that IETF LC comments were no longer 
appropriate. And you were indeed quite responsive to many of the issues 
brought up, including many other issues that one could reasonably expect 
to be brought up on the uri-review@ietf.org mailing list (scheme syntax 
issues, escaping/encoding issues,...), and where you didn't say that 
these should have been brought up earlier.

But for that one specific issue, you kept telling me things like 
"second-guessing the designated expert at this stage seems contrary to 
the registration requirements", "process-wise ... your main comment is 
late", "let's not ignore the fact that the uri-review list had sight of 
this at the end of April", and so on.

On my side, this definitely felt very much like "your comment is 
inappropriate at this time" rather than just "would have been great if 
we got this earlier".


> But,
> yes, I do think that your specific issue (essentially, not doing
> one of the registrations) would have been better raised
> earlier on uri-review, and as the one asking for the registrations
> it does feel like having to jump through the same bureaucratic
> hoops a second time.

There are a lot of hoops at the IETF. WG discussion, WG LC, registration 
reviews where applicable, IETF LC, IESG review,.... It would be good if 
we could do with less, but I guess they are all there for a reason.


> However, perhaps there is a generic issue in that its not clear
> whether one is doing paperwork or getting substantive technical
> review when one requests a registration, at least to the
> uri-review list. I'm not sure how many other *-review lists
> might have the same situation.

Quite a few, I guess. I see three main reasons for this:

1) The description of what the Designated Expert should check and what 
not is not clear enough. [For URI/IRI schemes, the IRI WG is working on 
an update to RFC 4395, and yours as well as everybody else's comments 
are highly appreciated.]

2) Many registries have been criticized for being too strict, leading to 
situations where labels are being used without being registered. As a 
result of that, the review has shifted from "is this really absolutely 
needed" in the direction of "make sure this isn't explicitly harmful". 
[This is in particular the case for quite a few registries in the Apps 
Area; it may be quite different in the Security Area, in particular for 
things such as cryptographic algorithms.]

3) The Designated Expert, and even more the other people on these 
mailing lists, are all volunteers, and most have a day job.

While 1) and 2) may eventually be addressed by updating the registry 
guidelines, 3) is difficult to fix.


> That could be clarified I guess.

As said above, the IRI WG is working on an update of RFC 4395, and 
everybody's comments, including yours, are highly appreciated


> If that list is just to check
> the paperwork, then I'd guess that pretty much all technical
> comment ought be re-directed elsewhere.

I'd describe the purpose of the list more as "make sure the basic 
paperwork is okay, make sure this is not overly harmful, and provide a 
place for technical input". There are many people on that list that can 
give technical advice, and quite a bit of it is usually appreciated, so 
I don't see why we should exclude it.


> If that list is for
> substantive technical review, then seeing frequent contributors
> to that list first bringing up issues at IETF LC would seem
> noteworthy. (I'm not saying such issues ought be ignored, but
> they maybe ought be treated as we would the case of a WG
> participant making comments on a topic only after WGLC.)

I strongly disagree here. The purpose of registration is not the same as 
the purpose of IETF standardization. There are many registries that 
contain stuff that "just happened" outside the IETF and would never have 
a chance in the IETF, but nevertheless a label is in use and it is 
better to get it registered than to deny registration. This may be (just 
guessing) different for security stuff such as cryptographic algorithms. 
But it definitely applies to many Apps Area related registries (MIME 
media types, charsets, URI/IRI schemes, and so on).

Also, a mailing list associated with a registry is not the same as a WG 
mailing list. A WG is chartered with creating something new. The main 
motivation for WG participants is to shape that "something new", and 
most aspects of a proposal will be discussed explicitly on the WG list. 
Lurking or occasional participation should indeed not be specially rewarded.

On the other hand, registration mailing lists are essentially "pro bono" 
efforts, both for the Designated Expert(s) as well as for every other 
participant. It would be highly inappropriate to disadvantage these 
volunteer participants in the same way as WG lurkers.

Regards,    Martin.