Re: [Enum] Enumservice registrations

Lawrence Conroy <lconroy@insensate.co.uk> Mon, 05 March 2012 14:07 UTC

Return-Path: <lconroy@insensate.co.uk>
X-Original-To: enum@ietfa.amsl.com
Delivered-To: enum@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 98C7E21F861B for <enum@ietfa.amsl.com>; Mon, 5 Mar 2012 06:07:30 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.318
X-Spam-Level:
X-Spam-Status: No, score=-2.318 tagged_above=-999 required=5 tests=[AWL=0.281, BAYES_00=-2.599]
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 eNwhRnGFyoiS for <enum@ietfa.amsl.com>; Mon, 5 Mar 2012 06:07:30 -0800 (PST)
Received: from insensate.co.uk (ghost.insensate.co.uk [213.152.49.121]) by ietfa.amsl.com (Postfix) with ESMTP id 04EBD21F85B7 for <enum@ietf.org>; Mon, 5 Mar 2012 06:07:24 -0800 (PST)
Received: from localhost (localhost [127.0.0.1]) by insensate.co.uk (Postfix) with ESMTP id 63AA959DC51; Mon, 5 Mar 2012 14:07:23 +0000 (GMT)
X-Virus-Scanned: amavisd-new at insensate.co.uk
Received: from insensate.co.uk ([127.0.0.1]) by localhost (psyche.insensate.co.uk [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id A30aML7IMI4z; Mon, 5 Mar 2012 14:07:22 +0000 (GMT)
Received: from [127.0.0.1] (localhost [127.0.0.1]) by insensate.co.uk (Postfix) with ESMTP id 8211D59DC46; Mon, 5 Mar 2012 14:07:22 +0000 (GMT)
Mime-Version: 1.0 (Apple Message framework v1084)
Content-Type: text/plain; charset="us-ascii"
From: Lawrence Conroy <lconroy@insensate.co.uk>
In-Reply-To: <20120305125142.GG22296@x27.adm.denic.de>
Date: Mon, 05 Mar 2012 14:07:22 +0000
Content-Transfer-Encoding: quoted-printable
Message-Id: <FF343D20-76E0-4A94-A860-5DBD8BBFB845@insensate.co.uk>
References: <2A45B5D5-FEAD-4813-96D3-55FA757ADD8C@insensate.co.uk> <20120305125142.GG22296@x27.adm.denic.de>
To: Peter Koch <pk@DENIC.DE>
X-Mailer: Apple Mail (2.1084)
Cc: IETF ENUM list <enum@ietf.org>
Subject: Re: [Enum] Enumservice registrations
X-BeenThere: enum@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Enum Discussion List <enum.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/enum>, <mailto:enum-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/enum>
List-Post: <mailto:enum@ietf.org>
List-Help: <mailto:enum-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/enum>, <mailto:enum-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 05 Mar 2012 14:07:30 -0000

On 5 Mar 2012, at 12:51, Peter Koch wrote:
> On Sat, Mar 03, 2012 at 12:06:33PM +0000, Lawrence Conroy wrote:
>> So ...
>> Can someone ensure at least that I-Ds for Enumservices are ALWAYS/Automatically sent to the enum mailing list?
>> (i.e., if it's an Enumservice, the enum mailing list is an interested party)
> 
> i'd suggest not to install any magic or automated action here.  Maybe the process
> wasn't followed, but then we do probably not know what the current status
> of the draft is.  Ideally, it would benefit from review on this list even as a -00,
> but in that regard there's nothing wrong with further discussion.  Automated action
> would lead to undesired effects and also educate authors in the wrong direction.
> 
> -Peter

To which I reply:
Hi Peter, Richard, folks,
 Fair enough.
This was *not* a dig at these specific authors -- lord knows I've made enough mistakes and had drafts not marked for the WG in which they were being considered, let alone this case where there are two separate groups that have an interest.

I do recall some confusion in the past that was caused by lack of communication between groups when NAPTRs were being [re-]defined.
The URN folk went their way, the ENUM-URI folk went their way with the SIP folk roughly in allignment, and as for (u)SNAPTRs folk, they were somewhere else again.
I contend that coordination between those groups would have made life easier for all, and certainly would have led to fewer bugs in ENUM code from people looking at examples in entirely unrelated drafts (and so made my life easier).

Given that even the best of us (i.e., me :), make mistakes, how that coordination is arranged at an early enough state to make life easy for the authors is the trick.
Taking your point, automation is the wrong kind of education; conversely, so are cattle prods.
Let's see if this is a common issue (especially with Richard's dark threats of tilting at the E2MD windmill again).

all the best,
  Lawrence