Subject: [Enum] I-D Action:draft-ietf-enum-enumservices-guide-05.txt

From: [email-masked]
Date: Mon, 22 Oct 2007 12:00:02 -0400

A New Internet-Draft is available from the on-line Internet-Drafts directories.
This draft is a work item of the Telephone Number Mapping Working Group of the IETF.

	Title           : Guide and Template for IANA Registrations of Enumservices
	Author(s)       : B. Hoeneisen, et al.
	Filename        : draft-ietf-enum-enumservices-guide-05.txt
	Pages           : 23
	Date            : 2007-10-22

This document provides a guide to and template for the creation of
new IANA registrations of ENUM (E.164 Number Mapping) services.  It
is also to be used for updates of existing IANA registrations.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-enum-enumservices-guide-05.txt

To remove yourself from the I-D Announcement list, send a message to
[email-masked] with the word unsubscribe in the body of 
the message.
You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce
to change your subscription settings.

Internet-Drafts are also available by anonymous FTP. Login with the 
username "anonymous" and a password of your e-mail address. After 
logging in, type "cd internet-drafts" and then
	"get draft-ietf-enum-enumservices-guide-05.txt".

A list of Internet-Drafts directories can be found in
http://www.ietf.org/shadow.html
or ftp://ftp.ietf.org/ietf/1shadow-sites.txt

Internet-Drafts can also be obtained by e-mail.

Send a message to:
	[email-masked].
In the body type:
	"FILE /internet-drafts/draft-ietf-enum-enumservices-guide-05.txt".

NOTE:   The mail server at ietf.org can return the document in
	MIME-encoded form by using the "mpack" utility.  To use this
	feature, insert the command "ENCODING mime" before the "FILE"
	command.  To decode the response(s), you will need "munpack" or
	a MIME-compliant mail reader.  Different MIME-compliant mail readers
	exhibit different behavior, especially when dealing with
	"multipart" MIME messages (i.e. documents which have been split
	up into multiple messages), so check your local documentation on
	how to manipulate these messages.

Below is the data which will enable a MIME compliant mail reader
implementation to automatically retrieve the ASCII version of the
Internet-Draft.
_______________________________________________
enum mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/enum

---

From: Peter Koch <[email-masked]>
Date: Mon, 22 Oct 2007 23:33:11 +0200

> 	Filename        : draft-ietf-enum-enumservices-guide-05.txt

{NIT: use of "<?rfc symrefs='yes'?>" in the xml2rfc source might have lead
      to less changes in the diff and usually makes references easier to
      comprehend}

The ASCII art I like, but I still think the document tries to reinvent the
wheel by designing a specific review process instead of using the available
choices.  It also might produce strange corner cases, e.g. where it
demands the proposed service be submitted as "individual submission",
which could even exclude a WG from the proposing a new service (well,
there's a solution to that, but why not get it right in the first place).

The proposal mixes "Designated Expert" (in 2434bis terms) with "IETF Review"
by maintaining the requirement that any ENUMservice be published as a
BCP, Standards Track or Experimental RFC.  The draft in question would
be an excellent opportunity to relax that.

IMHO the ENUM service registration should be based on "Expert Review" plus
"RFC required" with additional guiding information provided to the
Expert-to-be by the various obligatory sections currently present in the
template.

-Peter

---

From: Bernie Hoeneisen <[email-masked]>
Date: Tue, 23 Oct 2007 13:02:03 +0200 (CEST)

Hi Peter

Thanks for your feedback. We'll take it into consideration for the next 
update, which hopefully is ready before the upcoming submission deadline.

Comments inline.

> choices.

I agree with you. We are certainly trying to allign it with existing 
processes for IANA registrations. We did not have the time so far to study 
those in detail.

> It also might produce strange corner cases, e.g. where it

What exactly do you mean here?

> The proposal mixes "Designated Expert" (in 2434bis terms) with "IETF Review"

I am aware of the mixing part, which certainly needs to be sorted out. 
There is also the open issue at which time in the process the expert comes 
into action.

> be an excellent opportunity to relax that.

What would be your concrete proposal for relaxing?

> Expert-to-be by the various obligatory sections currently present in the

I agree with you. We are trying to map this into a proper process.

cheers,
  Bernie

---

From: "Richard Shockey" <[email-masked]>
Date: Tue, 23 Oct 2007 23:49:48 -0400

Peter thank you for taking the time to comment here... I thought we decided
that we would use existing procedures here and not reinvent the wheel.

http://www3.ietf.org/proceedings/07jul/minutes/enum.txt

Expert Review certainly with the option to require IESG review via a RFC.

>  -----Original Message-----
>  From: Peter Koch [mailto:[email-masked]]
>  Sent: Monday, October 22, 2007 5:33 PM
>  To: [email-masked]
>  Subject: Re: [Enum] I-D Action:draft-ietf-enum-enumservices-guide-
>  05.txt
>

---

From: Bernie Hoeneisen <[email-masked]>
Date: Wed, 24 Oct 2007 11:10:26 +0200 (CEST)

> that we would use existing procedures here and not reinvent the wheel.

Rich, Peter:
Which of the existing procedures do you have in mind?

Jason:
As the original text for the procdure now proposed in the I-D was 
contributed by you, did you take the idea from an existing 
registration procedure?

cheers,
  Bernie

---

From: "Richard Shockey" <[email-masked]>
Date: Thu, 25 Oct 2007 14:59:31 -0400

Well there are multiple IANA procedures for doing this. .what I thought we
wanted to do was select the procedure from the best practices here. The new
URI scheme registration for instance.

[15] Hansen, T, et al., "The "Guidelines and Registration Procedures for New
URI Schemes", RFC 4395, February 2006

I think one thing we should do is check with David Conrad the GM IANA for
input. I spoke to him in Chicago specifically about providing a little
expert guidance of what works and what doesn't.

>  From: Bernie Hoeneisen [mailto:[email-masked]]
>  Sent: Wednesday, October 24, 2007 5:10 AM
>  To: Richard Shockey
>  Cc: [email-masked]; 'Peter Koch'; Livingood, Jason
>  Subject: RE: [Enum] I-D Action:draft-ietf-enum-enumservices-guide-
>  05.txt
>  
>  >>From [email-masked] Thu Oct 25 15:04:02 2007
From: "Richard Shockey" <[email-masked]>
To: <[email-masked]>
Date: Thu, 25 Oct 2007 14:59:31 -0400
Subject: [Enum] FW: I-D Action:draft-hoeneisen-enum-x-service-regs-02.txt 

Bernie I'll send a note to Internet Drafts that this is a WG document.

You might want to rename future versions.

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] 
Sent: Tuesday, October 23, 2007 7:30 AM
To: [email-masked]
Subject: I-D Action:draft-hoeneisen-enum-x-service-regs-02.txt 

A New Internet-Draft is available from the on-line Internet-Drafts
directories.

	Title           : Registration of Enumservices for experimental,
private or trial use
	Author(s)       : B. Hoeneisen
	Filename        : draft-hoeneisen-enum-x-service-regs-02.txt
	Pages           : 8
	Date            : 2007-10-23

This document provides a guide to the creation of new IANA registrations of
experimental, private or trial ENUM (E.164 Number
Mapping) services.  It is also to be used for updates of those experimental,
private or trial Enumservice (X-Enumservice) registrations.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-hoeneisen-enum-x-service-regs-02.t
xt

To remove yourself from the I-D Announcement list, send a message to
[email-masked] with the word unsubscribe in the body of the
message.
You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce
to change your subscription settings.

Internet-Drafts are also available by anonymous FTP. Login with the username
"anonymous" and a password of your e-mail address. After logging in, type
"cd internet-drafts" and then
	"get draft-hoeneisen-enum-x-service-regs-02.txt".

A list of Internet-Drafts directories can be found in
http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt

Send a message to:
	[email-masked].
In the body type:
	"FILE /internet-drafts/draft-hoeneisen-enum-x-service-regs-02.txt".

	"multipart" MIME mes  -----Original Message-----
>  >> > 	Title           : Guide and Template for IANA Registrations
of
>  >>  Enumservices
>  >>  {NIT: use of "<?rfc symrefs='yes'?>" in the xml2rfc source might
>  have
>  >>  lead
>  >>        to less changes in the diff and usually makes references
>  easier
>  >>  to
>  >>        comprehend}
>  >>
>  >>  The ASCII art I like, but I still think the document tries to
>  reinvent
>  >>  the
>  >>  The proposal mixes "Designated Expert" (in 2434bis terms) with
>  "IETF
>  >>  Review"
>  >>  IMHO the ENUM service registration should be based on "Expert
>  Review"
>  >>  plus
>  >>  Expert-to-be by the various obligatory sections currently present
>  in
>  >>  the
>  >>  template.
>  >>
>  >>  -Peter
>  >>

sages (i.e. documents which have been split
	up into multiple messages), so check your local documentation on
	how to manipulate these messages.

---

From: "Richard Shockey" <[email-masked]>
Date: Thu, 25 Oct 2007 14:59:31 -0400

of

---

From: lconroy <[email-masked]>
Date: Fri, 26 Oct 2007 00:59:47 +0100

Esteemed chair, folks,

  OK - I'll rise to this.
Is your preference for the URI scheme process (of RFC 4395) that you
believe that the requirements spelt out in the URI scheme process are
appropriate for Enumservices?

The URI scheme process has a very high barrier to entry - see in  
particular
section 2.1 of RFC 4395. This seems to me to be wildly inappropriate for
Enumservices that will be used in specific access controlled  
environments
like carrier or federated ENUM.
Section 3 of that document would seem to be ideal for X- Enumservices or
ones that are going to be used in controlled environments.
However, section 5.2 point 4 ("as needed to bring it into line with the
guidelines given in this document") seems to apply the same rules for  
*both*
permanent and provisional registrations. As written, that's an  
awfully high bar.

Looking at the real issues with Enumservices so far, it seems to me  
that most
of writing an Enumservice specification is straightforward.
Putting text strings into a NAPTR and decoding it *should* be simple  
by now.
Defining a complete specification for the textual syntax is easy.  
It's been
done many times.
The trick is describing what happens if a program (or a person) uses  
this NAPTR.

Enumservices will continue to need a domain expert to review them  
(preferably
NOT the authors :), to handle the very important job of deciding if  
some poor
sod can understand what happens if you use this Enumservice and  
believing that
the same poor sod can implement based on the specification.

Given that new Enumservices may well be used in fairly esoteric  
environments
(e.g. closed systems in one country or another), selecting an expert  
who is
familiar (or even aware) of the intended environment is not going to  
be easy.
[IMHO, environments around the world differ markedly. What makes  
sense to
  a person with experience on one Continent will be wrong for someone  
else]

My biggest concern with all of these procedures is that there are  
simply not
enough domain experts active in this WG (and certainly outside this  
WG) to
form a pool of reviewers. We may end up with some very busy people  
struggling
to cover Enumservice uses and environments with which they are not  
familiar.
Although it doesn't mention it in 4395, I ASSUME that (like 2929bis),  
the
IESG designates the pool of experts.

However, I have no idea how IANA is expected to select the designated  
expert for
a given Enumservice document, unless we ASSUME that any Enumservice  
must make sense
to everyone and be used anywhere. If we DO make that assumption, that  
would be a pity.
If we don't assume that all Enumservices must have "clear utility to  
the broad
Internet community", then the putative mailing list is going to have  
to give some
guidance, otherwise IANA is going to be lumbered with a *very* hard  
selection job.

all the best,
   Lawrence