Subject: [Enum] NAPTRs for invalid Numbers

From: "Stastny Richard" <[email-masked]>
Date: Wed, 26 Mar 2003 17:54:29 +0100

Hi -MM,
 
I think we have a point here which needs clarification, thats why I renamed the thread.

>Hmm.... let me state this differently: E2U NAPTR records MUST not be
>inserted for numbers that are inconsistent with the numbering plan it
>appears under. I.e. if a number is invalid according to the numbering
>plan it must be invalid for ENUM as well. Is that better?

I like your second sentence insofar, that a number invalid according
to the numbering plan must also be invalid for -now it comes- for
ENUM delegation to ENUM Subscriber.
 
The problem here is that rfc2916bis is talking nowhere about admin issues and 
ENUM subscribers.
 
Now I come to the issue of NAPTRs for invalid numbers.
 
In the existing phone system you get an indication if you dial an invalid or incomplete number.
We have thought about if we can emulate this convinience to the user also in ENUM.
 
One possibility is e.g. to provide wild card NAPTRs in invalid number ranges pointing
to e.g. an annoncement.  This NAPTRs would never be inserted by ENUM Subscribers,
but by the Tier 1 Registry.
 
Therefore I have some problems with your above statement.
 
Any comments?
 
Richard
_______________________________________________
enum mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/enum

---

From: Michael Mealling <[email-masked]>
Date: 26 Mar 2003 12:10:06 -0500

> ENUM delegation to ENUM Subscriber.

Just say an E2U specific NAPTR record. That was the consensus I heard.
Anything beyond that simple statement was out scope.

> Therefore I have some problems with your above statement.

When Jon and I were talking about this before last week I suggested at
one point a new enumservice called 'notavalidnumber' which could
designate non-valid but existing nodes so that clients would have a
better ability to detect real errors. The reason we rejected it was that
it would bring up all sorts of issues associated with what those
intermediate nodes meant, how else could you use them, etc. And that
would cause this document to never get published. 

So my suggestion is to make a simple statement of it being out of scope
with a statement similar to what I say above. We publish this document
and then those that care can go off and figure out what records at
intermediate nodes means more concretely....

I'm just not comfortable with holding this document up while we
investigate what this approach might mean, both from a protocol stand
point and from a regulatory/admin standpoint....

-MM

---

From: Richard Shockey <[email-masked]>
Date: Wed, 26 Mar 2003 12:59:22 -0500

>intermediate nodes means more concretely....

I certainly support this conclusion ....

>point and from a regulatory/admin standpoint....

Precisely ... this document needs to be completed and into last call as 
soon as practical.

Richard Shockey, Senior Manager, Strategic Technology Initiatives
NeuStar Inc.
46000 Center Oak Plaza  -   Sterling, VA  20166
Voice +1 571.434.5651 Cell : +1 314.503.0640,  Fax: +1 815.333.1237
<mailto:[email-masked]> or <mailto:[email-masked]>
  <http://www.neustar.biz> ; <http://www.enum.org>
<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<