Re: [Enum] [IANA #171390] Revision of IANA Enumservice registry (fwd)

Bernie Hoeneisen <bernie@ietf.hoeneisen.ch> Mon, 06 October 2008 17:34 UTC

Return-Path: <enum-bounces@ietf.org>
X-Original-To: enum-archive@megatron.ietf.org
Delivered-To: ietfarch-enum-archive@core3.amsl.com
Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id AF63D3A6A28; Mon, 6 Oct 2008 10:34:33 -0700 (PDT)
X-Original-To: enum@core3.amsl.com
Delivered-To: enum@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id DB9743A6A28 for <enum@core3.amsl.com>; Mon, 6 Oct 2008 10:34:32 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.328
X-Spam-Level:
X-Spam-Status: No, score=-2.328 tagged_above=-999 required=5 tests=[AWL=0.271, BAYES_00=-2.599]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Aqx2E7utRJqS for <enum@core3.amsl.com>; Mon, 6 Oct 2008 10:34:31 -0700 (PDT)
Received: from GIC-VDL-228-151.as16215.net (gic-vdl-228-151.as16215.net [82.195.228.151]) by core3.amsl.com (Postfix) with ESMTP id 33C053A67FC for <enum@ietf.org>; Mon, 6 Oct 2008 10:34:30 -0700 (PDT)
Received: from localhost ([127.0.0.1]) by GIC-VDL-228-151.as16215.net with esmtp (Exim 4.63) (envelope-from <bernie@ietf.hoeneisen.ch>) id 1Kmtyc-0002R4-0S for enum@ietf.org; Mon, 06 Oct 2008 19:34:34 +0200
Date: Mon, 06 Oct 2008 19:34:31 +0200
From: Bernie Hoeneisen <bernie@ietf.hoeneisen.ch>
X-X-Sender: bhoeneis@GIC-VDL-228-151.as16215.net
To: IETF ENUM list <enum@ietf.org>
Message-ID: <alpine.DEB.0.82.0810061932030.26092@GIC-VDL-228-151.as16215.net>
MIME-Version: 1.0
X-SA-Exim-Connect-IP: 127.0.0.1
X-SA-Exim-Mail-From: bernie@ietf.hoeneisen.ch
X-SA-Exim-Scanned: No (on GIC-VDL-228-151.as16215.net); SAEximRunCond expanded to false
Subject: Re: [Enum] [IANA #171390] Revision of IANA Enumservice registry (fwd)
X-BeenThere: enum@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: Enum Discussion List <enum.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/enum>, <mailto:enum-request@ietf.org?subject=unsubscribe>
List-Archive: <https://www.ietf.org/mailman/private/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>
Content-Transfer-Encoding: 7bit
Content-Type: text/plain; charset="us-ascii"; Format="flowed"
Sender: enum-bounces@ietf.org
Errors-To: enum-bounces@ietf.org

---------- Forwarded message ----------
Date: Sun, 5 Oct 2008 19:18:34 +0200 (CEST)
From: Bernie Hoeneisen <bernie@ietf.hoeneisen.ch>
To: Michelle Cotton via RT <iana-issues@icann.org>
Cc: IETF ENUM list <enum@ietf.org>, marc.blanchet@viagenie.ca,
     simon.perreault@viagenie.ca
Subject: Re: [IANA #171390] Revision of IANA Enumservice registry

Hi Michelle

Thanks for your timely answer. My comments inline.

On Fri, 3 Oct 2008,  Michelle Cotton via RT wrote:

--------

1)

> If someone writes a document to add a new registration to the enum-services 
> registry, it would be great if they included in their document an XML chunk 
> that IANA would simply cut and paste in the registry itself after the 
> registration is approved. The spec itself does not have to be in XML.

If you provide us with an example, we'd be more than happy to include an XML 
chunk to -13. (See also 5) further below)

--------

2)

> In section 11.1.2., I understand that it is requested that IANA archive the 
> specification in the cases of it not being an RFC.  Will IANA need to make 
> that document public or just archive it for purposes of inquires and 
> registration?

As per -12, the latter applies. It is just an escrow copy, in case the 
specification is lost or it is unclear, which version applies.

It might be a good idea to address this escrow copy stuff in rfc5226bis, as DNS 
folks have the same problem...

--------

3)

> I see the use "Authors" frequently.  We mainly use the term "Requester".

Hmmm...The Author of the specification is the Requester of the registration. 
I'll have to think about.

--------

4)

> The expert review process in this document is slightly different than the one 
> that IANA currently uses.  For most registries, requests are sent to IANA, we 
> forward the request to the expert for review, after the approval IANA 
> registers the parameter and then notifies the requester of the completed 
> registration.

Do these IANA registries also use "Specification Required" as per RFC 5226?

I see your point. The document attempts to ensure both requirements: "Expert 
Review" and "Specification Required".

In other words, before IANA can add the Enumservice to the Registry, there 
needs to be a Specification according to RFC 5226. Usually this is not the case 
at the time the expert reviews the Enumservice. Expert Review might result in 
changes.

> In this case, the expert is approving the template and it appears they also 
> have to approve the specification after it is published?  It seems a bit 
> fuzzy to me.
> Or is this the case where the expert my assist in making the template better 
> before it gets finalization in a document? If that is the case, then IANA 
> will have to go to the expert twice in this case?  Once for the enumservice 
> template, and then second to verify the specification has been published.

After the Experts have approved the specification it is published somewhere. 
After publication, IANA gets a request to add the Enumservice to the Registry.

No further Expert Review is needed at that point in time, but it needs to be 
ensured the published version is the same as the one approved earlier by the 
Experts (and the requirements for "Specification Required" according to RFC 
5226 are met).

I am not really happy with this part of the process, but I see no alternative 
to ensure publication according to RFC 5226. Please tell us, if you see a 
better way to acomplish the same goal.

I have a feeling, this is an issue for rfc5226bis...

-----------

5)

> Also, for the document, having the xml chunk for the registration itself 
> would be very useful. We can help with providing what that should look like 
> as we convert the registry in the next few weeks.

As the IANA template of the Enumservice registry is about to change, I 
recommend to wait.

draft-hoeneisen-enum-enumservices-transition-01 is addressing these changes for 
the existing services. If we get an example of an XML chunk, we'll publish a 
revision of the enumservices-transition I-D, which will include all existing 
registrations (including the template changes) as XML chunks.

----------

cheers,
  Bernie
_______________________________________________
enum mailing list
enum@ietf.org
https://www.ietf.org/mailman/listinfo/enum