preperation for Enumservices guide discussion

Dear ENUM WG

This is to prepare yourself for the discussion and decision making about 
draft-ietf-enum-enumservices-guide-06 during the meeting in Vancouver.

We have 3 questions that we want a FINAL decision about before the end 
of the ENUM WG session in Vancouver (Or, at least after a couple of 
pints over the course of the week).

   * * *

Issue 1) Which is the process we are gone specify for future ENUM 
service registrations?

      A) Author -> IESG -> Expert Review -> IESG -> IANA -> Publication

      B) Author -> Expert Review -> IESG -> IANA -> Publication

      C) Author -> IANA -> Expert Review -> IANA -> Publication

      D) Author -> IESG -> IANA -> Expert Review -> IANA -> Publication


A) would require the least changes from well defined processes in the 
IETF and it does not require major changes of RFC 3761. The 
responsibilities are rather clear. But it puts more burden on the IESG.

B) is the one documented in the current revision of 
draft-ietf-enum-enumservices-guide-06.txt. This is a new process, not 
spread in the IETF. Responsibilities are anything but clear.

C) If we want to apply such a simple process for Enumservice 
registrations, a major change in RFC 3761 is needed, as RFC 3761 states:
"Enumservice registrations needs to be Standards Track, Experimental or 
BCP". But this process would be the most lightweiht one.

D) At the moment I do not see any compelling reason to use such a process.


   * * *

Issue 2) Subtypes and URI schemes

The question here is how URI schemes and Enumservice type/subypes may be 
combined when defining an Enumservice. We have the following options (if 
you have other ideas, speak up NOW):

a) Only one URI scheme per subtype?

b) Only allow more than one URI scheme per subtype, if one is the normal 
and the other the secure variant (e.g. sip and sips).

c) Allow any number of URI schemes with and subtype?

d) Allow only those URI schemes to be combined in one subtype that are 
mandatory to implement for all clients?

Details:

The problem with combining URI schemes and subtypes is that clients must 
not "look at the URI scheme" before they select a NAPTR - they can only 
look at type/subtype. So in case we allow the mixture of URI schemes 
into subtype, and not all of them are mandatory, a client can end up 
choosing the "wrong" NAPTR, because it doesn't support the URI scheme. 
For example, consider the following situation:

- The protocol/service itself can use URI schemes "fooA", "fooB", 
"fooC", with "fooC" not mandatory to implement.
- Client supports URI schemes "fooA", "fooB".
- The Enumservice defines the type "x-service" to allow all three URI 
schemes.
- There are two NAPTRs, one with "better" preferrence has "x-service -> 
fooC", and the other one has "x-service -> fooA".
- The client now somehow plays "russian roulette" - because it can't 
look at the URI schemes in the records, and once it has chosen one 
record, it can't "go back". So if it chooses the first record, it can't 
make use of the service, because fooC is not supported.

Currently, we have option b) in the draft. None of those solutions is 
perfect, as some might require revising existing Enumservices.

* * *

Issue 3) Are we going to include the Enumservice classification in the 
IANA template for ENUM service registrations?

That is the classification of "procotol" / "data format" / "application" 
Enumservice.

* * *

Please think about it and comment latest at the ENUM WG in vancouver or 
hold peace forever...

cheers,
   Alex and Bernie