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

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



On 25 Oct 2007, at 19:59, Richard Shockey wrote:
> 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.
>
>>  -----Original Message-----
>>  From: Bernie Hoeneisen [mailto:[email protected]]
>>  Sent: Wednesday, October 24, 2007 5:10 AM
>>  To: Richard Shockey
>>  Cc: [email protected]; 'Peter Koch'; Livingood, Jason
>>  Subject: RE: [Enum] I-D Action:draft-ietf-enum-enumservices-guide-
>>  05.txt
>>
>>  On Tue, 23 Oct 2007, Richard Shockey wrote:
>>
>>> 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.
>>
>>
>>  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
>>
>>
>>> 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 protected]]
>>>>  Sent: Monday, October 22, 2007 5:33 PM
>>>>  To: [email protected]
>>>>  Subject: Re: [Enum] I-D Action:draft-ietf-enum-enumservices-guide-
>>>>  05.txt
>>>>
>>>>  On Mon, Oct 22, 2007 at 12:00:02PM -0400, [email protected]
>>>>  wrote:
>>>>
>>>>> 	Title           : Guide and Template for IANA Registrations
> of
>>>>  Enumservices
>>>>> 	Author(s)       : B. Hoeneisen, et al.
>>>>> 	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
>>>>
>>>>  _______________________________________________
>>>>  enum mailing list
>>>>  [email protected]
>>>>  https://www1.ietf.org/mailman/listinfo/enum
>>>
>>>
>>> _______________________________________________
>>> enum mailing list
>>> [email protected]
>>> https://www1.ietf.org/mailman/listinfo/enum
>>>
>>
>>  _______________________________________________
>>  enum mailing list
>>  [email protected]
>>  https://www1.ietf.org/mailman/listinfo/enum
>
>
> _______________________________________________
> enum mailing list
> [email protected]
> https://www1.ietf.org/mailman/listinfo/enum