Subject: [Enum] process questions arising from draft-pfautz-lind-enum-carrier-user-00.txt

From: lconroy <[email-masked]>
Date: Thu, 09 Jun 2005 08:21:43 -0400

Hi Folks,
Discussion of the Principle behind this Enumservice registration 
(apparently to "move out" the squatters so that there is room for 
carriers as well) will have to wait. I can see that there are benefits 
for some to such a clearance, so I await *convincing* arguments from 
others with interest.

Here I'm concerned purely with the Process issues::
RFC3761 defines the template for specification of Enumservices.
One of the items required for an Enumservice registration document is 
the
expected output/URI.

See section 2.4.2.1, section 3. (introductory paragraph), section 3.1.1 
(note
the MUST).

Considering <draft-pfautz-lind-enum-carrier-user-00.txt>:
These Enumservices do not have a RegExp field (in accordance with 
RFC3403,
section 4.1, subsection REPLACEMENT, 2nd paragraph).
However, as there is no RegExp field in non-terminal NAPTRs, there is 
no place for "that very NAPTR" to hold text used to generate a URI.

Whilst RFC3402 and 3403 do not specifically preclude a non-empty 
Service field in a non-terminal NAPTR, 3761 puts MUST-level 
requirements on registration of an Enumservice token to be used in a 
NAPTR used for the E2U (ENUM) DDDS Application. This registration 
document would appear not to meet these requirements.

So... Process Questions::
Do we change 3761 to remove the requirement from 3761 section 3.1.1 
paragraph 2 (and the other sections)?
If not, then how can ANY Enumservice registration for use with 
non-terminal NAPTRs match the requirements of 3761?

all the best,
  Lawrence
---------------------------------------
lawrence conroy    |tel:+44-1794-833666
_______________________________________________
enum mailing list
enum at ietf.org
https://www1.ietf.org/mailman/listinfo/enum