Re: registries and designated experts

John C Klensin <john-ietf@jck.com> Wed, 13 June 2012 21:50 UTC

Return-Path: <john-ietf@jck.com>
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 D8F9821F84D6 for <ietf@ietfa.amsl.com>; Wed, 13 Jun 2012 14:50:43 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.599
X-Spam-Level:
X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, 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 K4cysAyyfaB9 for <ietf@ietfa.amsl.com>; Wed, 13 Jun 2012 14:50:43 -0700 (PDT)
Received: from bsa2.jck.com (ns.jck.com [70.88.254.51]) by ietfa.amsl.com (Postfix) with ESMTP id 38AAF21F84D5 for <ietf@ietf.org>; Wed, 13 Jun 2012 14:50:43 -0700 (PDT)
Received: from [198.252.137.115] (helo=JcK-HP8200.jck.com) by bsa2.jck.com with esmtp (Exim 4.71 (FreeBSD)) (envelope-from <john-ietf@jck.com>) id 1SevMK-000KUX-KG; Wed, 13 Jun 2012 17:44:12 -0400
Date: Wed, 13 Jun 2012 17:50:30 -0400
From: John C Klensin <john-ietf@jck.com>
To: Thomas Narten <narten@us.ibm.com>, "Romascanu, Dan (Dan)" <dromasca@avaya.com>
Subject: Re: registries and designated experts
Message-ID: <21E957EA9B7C80B51E88AE22@JcK-HP8200.jck.com>
In-Reply-To: <201206131248.q5DCmSL6028424@cichlid.raleigh.ibm.com>
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>
X-Mailer: Mulberry/4.0.8 (Win32)
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Content-Disposition: inline
Cc: SM <sm@resistor.net>, ietf@ietf.org
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: Wed, 13 Jun 2012 21:50:44 -0000

--On Wednesday, June 13, 2012 08:48 -0400 Thomas Narten
<narten@us.ibm.com> wrote:

>> Maybe an IESG statement on this respect can help here.
> 
> Is the existing text in RFC 5226 not sufficient? It contains
> extensive text about the purpose and role of designated
> experts, and was revised substantially the last time around to
> try and find a good middle ground between being overly
> prescriptive and giving experts a "blank check" to do what
> they want.
> 
> Nothing in the discussion I've seen so far in this thread
> seems at odds with or beyond what is already in RFC 5226 (but
> I may be biased).

Thomas,

FWIW, I think 5226 is ok, but that the community, especially the
community who write "Designated Experts" need to pay a little
more attention to a few phrases there than has sometimes been
the case.  For example, 5226 says:

	"Ideally, the designated expert follows specific review
	criteria as documented with the protocol that creates or
	uses the namespace."

and 

	"Experts are expected to apply applicable documented
	review or vetting procedures, or in the absence of
	documented criteria, follow generally accepted norms,
	e.g., those in Section 3.3."

My impression is that people have perhaps too often skipped
specifying specific guidelines or criteria in their definitions,
leaving the experts to fall back on good sense and the last half
of Section 3.3.  That isn't necessarily bad but can easily lead
to misunderstandings if there is actually controversy about a
proposed registration.  So I'd recommend that  the community pay
a bit more attention during Last Call to whether enough (or too
much) guidance is specified than has often been the case in the
past where we argue protocol details and do a lot of nit-picking
but mostly ignore IANA Considerations sections.

That doesn't require changes to 5226.  But, if 5226 is every
revised, it might be well to check to see if the emphasis in
what it says about this issue is in line with what we want.

    john