Re: I-D Action:draft-ietf-enum-enumservices-guide-05.txt

Bernie,

On Tue, Oct 23, 2007 at 01:02:03PM +0200, Bernie Hoeneisen wrote:

apologies for the late response.

> >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).
> 
> What exactly do you mean here?

_if_ the registration procedure would involve an I-D, why require the
"individual submission" path?  Imagine some WG came up with a new ENUM service,
so they should be allowed to work on that as a WG document.  Of course,
I understand the desire to relieve the ENUM WG from processing all services,
but that should be achieved differently.

> 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.

As far as IANA is concerned, RFC 2434 and its successor should be clear.

> >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.
> 
> What would be your concrete proposal for relaxing?

It seems the WG feels that registration of ENUM services should be easier,
while at the same time maintaining some review.  Since in contrast to, say,
port numbers, the space for service identifiers isn't really scarce, there
needs to be some rationale behind a regime on the registration:

1) Avoid confusion by identical or similar services offered under different
   service names to assist correct use

2) Avoid the use of ENUM services in a way that is incompatible with the
   ENUM model or has other indesired side effects

3) While the identifier space is huge, space in the NAPTR RRSet probably
   isn't, so there is some pressure to avoid the "1000 flowers".

If one accepts this reasoning, then there are two issues. First, access
to the specification needs to be permanently secured and second, the
specification must be reviewed, desirably short of full standrads track.

This seems to suggest relaxing the Standards/Experimental requirement
towards, e.g., "RFC published", which explicitly includes Informational
and also "Expert Review (Designated Expert)" to take load off the IESG.
Richard in a later thraed suggested a closer look at RFC 4395 and I think
that's an excellent idea.  URI schemes are probably closer to ENUM services
than MIME types.

-Peter