Subject: RE: [Enum] draft-ietf-enum-void-02 --> First Question - Agreement on SOLUTION Void?

From: "Livingood, Jason" <[email-masked]>
Date: Mon, 6 Nov 2006 19:36:48 -0500

So if we have agreement / consensus on the problem statement, then the
next obvious step is to determine if the solution recommended by the
void service is the right one.  My question is, if not void, then what?

A SP could register their inactive TNs with SIP URIs that go to a
special URI that plays back an announcement that the number is inactive,
such as sip:[email-masked] or sip:[email-masked] (where
that URI is used for ALL inactive numbers).  In both cases,
communication is initiated from the caller to this URI, and the
terminating side would then have to trigger and play an announcement
(but it would otherwise look like a normally completed call). 

I think the use of void potentially gives the call originator at the
network edge access to this information more directly, potentially
obviating the need to even attempt a call.  In general, I kind of like
being able to figure that sort of stuff out at the egde / point of
origination.  So I like that about the void proposal.

Are there other methods that people think could solve for this problem?

I am a bit more ambivalent about the contact address (email addr or http
URL), but this may be useful for some clients and applications that I
don't yet see a use case for yet.

Perhaps another concern is the name of the service being VOID.  Perhaps
some take that to mean that the query was invalid in some manner?  If
so, perhaps it could be called INACTIVE or something like that
instead...

Also, I'd suggest the authors consider removal of this text in section
7, as I'd suggest that I am not sure SPs would actually do this and I
think regular SIP mechanisms can handle these scenarios:
"This could be done for a variety of reasons.  The number could have
been delegated to an end user who has chosen to insert this record: for
instance it's in an ENUM or VoIP only number block and the end user's
SIP gateway is out of service."

In general, I also find the rest of section 7 confusing and that may
also explain some of the issues raised on the I-D.

Jason

> A service provider has a number block of, for example, 
> +1-215-981-XXXX, where XXXX is -0000 to -9999.  That SP has 
> issued 50% of these numbers to individual subscribers and the 
> other 50% have not been.  These are not neatly distributed 
> within the block, as subscribers choose their numbers so the 
> active numbers end up being randomly distributed in the block. 
> 
> If the SP registers SIP URIs for all of the active TNs then 
> those calls will work and terminate just fine.  If a TN is 
> not registered then, since it is inactive, then if a person 
> dials one of the unregistered TNs then you have to wait for 
> NXDOMAIN response.  In that case, most softswitches / proxies 
> will then do legacy lookups (LNP, LERG, etc.).  The downside 
> is two-fold: greater post-dial delay than is necessary, and 
> having to rely on legacy call lookup tools (which may have 
> associated costs).  There should be a way instead to stop the 
> call routing progression immediately if you know that the TN 
> is inactive, thus triggering back the code for a number not 
> in service network announcement to a caller.
> 
> Is this a correct understanding of one of the issues the 
> authors are trying to identify in the problem statement?
> 
> Jason

_______________________________________________
enum mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/enum

---

From: "Richard Shockey" <[email-masked]>
Date: Tue, 7 Nov 2006 14:37:57 -0500

In line.. Chair hat off..

> -----Original Message-----
> From: Livingood, Jason [mailto:[email-masked]]
> Sent: Monday, November 06, 2006 7:37 PM
> To: [email-masked]
> Subject: RE: [Enum] draft-ietf-enum-void-02 --> First Question - Agreement
> onSOLUTION Void?
> 

Yes..

> don't yet see a use case for yet.

I'd certainly like to understand this use case better.

> so, perhaps it could be called INACTIVE or something like that

The general use case to me seems to revolve around what is the status of a
particular TN within the network at a particular point in time.

Now that begs the question of how do you express status with the caveat that
the DNS is not very good at expressing highly dynamic data.

I agree the term void may have been a contributing factor to the confusion
in the IESG on what this draft was trying to accomplish.

My own personal thinking of what the appropriate enumservice for this
problem should be is something along the lines of 

E2U+status:text   where the URI is a text URI   text:inactive

We could define as text a limited number of status condition potentially
including compound status with semicolon separators. 

Just a thought but it has simplicity easy to parse and is extensible if
someone thinks of something else like  text:inactive;SPID=6666

---

From: "Stastny Richard" <[email-masked]>
Date: Tue, 7 Nov 2006 21:10:15 +0100

>E2U+status:text   where the URI is a text URI   text:inactive
 
What about an URN as Otmar proposed?
 
Richard

________________________________

Von: Richard Shockey [mailto:[email-masked]]
Gesendet: Di 07.11.2006 20:37
An: 'Livingood, Jason'; [email-masked]
Betreff: RE: [Enum] draft-ietf-enum-void-02 --> First Question - AgreementonSOLUTION Void?

Yes..

---

From: "Stastny Richard" <[email-masked]>
Date: Tue, 7 Nov 2006 21:14:31 +0100

>someone thinks of something else like  text:inactive;SPID=6666

Could you please start thinking global
There is currently no global SPIDs
 
So who is defining them?
 
If the SPID is needed at all, the pointer to a webpage or an email address
works as well
 
Richard

Yes..

---

From: "Richard Shockey" <[email-masked]>
Date: Tue, 7 Nov 2006 15:30:01 -0500

NO. NO URN's

NAPTR Records are URI's

3761 is The E.164 to Uniform Resource Identifiers (URI)
     Dynamic Delegation Discovery System (DDDS) Application (ENUM)

> From: Stastny Richard [mailto:[email-masked]]
> Sent: Tuesday, November 07, 2006 3:10 PM
> To: [email-masked]; Livingood, Jason; [email-masked]
> Subject: Re: [Enum] draft-ietf-enum-void-02 --> First Question -
> AgreementonSOLUTION Void?
>

---

From: "Richard Shockey" <[email-masked]>
Date: Tue, 7 Nov 2006 15:31:33 -0500

Please ..I was only using that as example of something some one MIGHT want
to try. 

I know there are no global SIPD's.

For the purposes of this draft I think limiting the response to 

unallocated (not existent)

unassigned (not existent)

inactive (inactive -= out-of-service- barred - etc)

is sufficient. I just want the URI syntax for status conditions to
_eventually_ be extensible. Which is why something like E2U+status:[uri]
makes sense but I'm not totally sold on this.

The more I think about it what you are proposing with the http and email
address is something entirely different than what is actually needed. What
you are discussing is essentially TN ownership which is not line (number)
status. That I increasingly think that this point to carrier of record via
http or smtp should be its own URI scheme.

We know what the problem is lets keep the solution very very simple, even if
that means starting over from scratch.

  _____  

Sent: Tuesday, November 07, 2006 3:15 PM

So who is defining them?

Richard

  _____  

Betreff: RE: [Enum] draft-ietf-enum-void-02 --> First Question -

Yes..

---

From: "Pfautz, Penn L, GBLAM" <[email-masked]>
Date: Tue, 7 Nov 2006 15:34:30 -0500

I'm not fundamentally against the void concept and I do recognize it
addresses a problem I too would like to solve. But I think there needs
to be some discussion in the draft of whether there might be some
limitations in use. For example, I think American regulators would be
concerned that, if carriers of record habitually populated such records
in open DNS, they would be data-mined for unlisted numbers. I agree the
info is available via war dialing but that's still harder than just
being able to use DNS queries. 
So, while something like void would be appropriate in some environments
(no issues in a secured carrier access only root) it might raise issues
in others.

Penn

---

From: "Stastny Richard" <[email-masked]>
Date: Tue, 7 Nov 2006 21:38:03 +0100

>NAPTR Records are URI's

Is this chair cap off or on ?

---

From: Otmar Lendl <[email-masked]>
Date: Tue, 7 Nov 2006 21:45:07 +0100

> NAPTR Records are URI's

http://www.ietf.org/rfc/rfc2396.txt

----
1.2. URI, URL, and URN

   A URI can be further classified as a locator, a name, or both.  The
   term "Uniform Resource Locator" (URL) refers to the subset of URI
   that identify resources via a representation of their primary access
   mechanism (e.g., their network "location"), rather than identifying
   the resource by name or by some other attribute(s) of that resource.
   The term "Uniform Resource Name" (URN) refers to the subset of URI
   that are required to remain globally unique and persistent even when
   the resource ceases to exist or becomes unavailable.
----

Thus any URN is also a URI.

/ol
-- 
< Otmar Lendl ([email-masked]) | nic.at Systems Engineer >

---

From: "Richard Shockey" <[email-masked]>
Date: Tue, 7 Nov 2006 15:47:27 -0500

> From: Pfautz, Penn L, GBLAM [mailto:[email-masked]]
> Sent: Tuesday, November 07, 2006 3:35 PM
> To: Stastny Richard; [email-masked]; Livingood, Jason; [email-masked]
> Subject: [Enum] RE:draft-ietf-enum-void-02 --> my problem
> 

Penn this is an excellent point. I completely agree this is a requirement
for a rewritten draft.

This would certainly help the IESG understand where the requirement would
come from.

It has been my experience that the operators who want to use such a void our
status URI are essentially building private ENUM infrastructure systems
where the data exposed between consenting service providers is exchanged
through a trusted registry operation or other our of band mechanism and
fully cached in their local ENUM DNS server infrastructure aka the IP-SCP.
This permits the originating carrier the opportunity to avoid unnecessary
INVITES to the terminating peering partner etc.

---

From: "Richard Shockey" <[email-masked]>
Date: Tue, 7 Nov 2006 15:48:12 -0500

ON ..see RFC 3761 that says URI not URN's.

> Sent: Tuesday, November 07, 2006 3:38 PM
> To: [email-masked]; Livingood, Jason; [email-masked]
> Subject: Re: [Enum] draft-ietf-enum-void-02 --> First Question-

---

From: "Richard Shockey" <[email-masked]>
Date: Tue, 7 Nov 2006 16:01:27 -0500

Ok but I not convinced this is the application to start down the road
changing what is expected from the rewrite. 

No other registered Enumservices uses URN's and frankly this application
does not IMHO justify starting down that road any more than I really want to
see documents about non-terminal NAPTR records until some one comes up with
a specific use case and enumservice registration that justifies it.

I think we had consensus that this rewrite needs to be simple fast and
quick. If you want to complicate the rewrite of void-03 with an issue like
incorporating URN's this then we're probably headed back to square one.

> From: Otmar Lendl [mailto:[email-masked]]
> Sent: Tuesday, November 07, 2006 3:45 PM
> To: Richard Shockey
> Cc: 'Stastny Richard'; 'Livingood, Jason'; [email-masked]

---

From: "Stastny Richard" <[email-masked]>
Date: Tue, 7 Nov 2006 21:59:07 +0100

So why do you need SPID. This is also line ownership
 
and what about unallocated blocks?
you need a SPID for the FCC too
 
And I do not know if line status is what you want
line active or inactive may change quite rapidly
 
Richard

Von: Richard Shockey [mailto:[email-masked]]
Gesendet: Di 07.11.2006 21:31
An: Stastny Richard; 'Livingood, Jason'; [email-masked]
Betreff: RE: [Enum] draft-ietf-enum-void-02 --> First Question - AgreementonSOLUTION Void?

Please ..I was only using that as example of something some one MIGHT want to try. 

is sufficient. I just want the URI syntax for status conditions to _eventually_ be extensible. Which is why something like E2U+status:[uri] makes sense but I'm not totally sold on this.

The more I think about it what you are proposing with the http and email address is something entirely different than what is actually needed. What you are discussing is essentially TN ownership which is not line (number) status. That I increasingly think that this point to carrier of record via http or smtp should be its own URI scheme.

We know what the problem is lets keep the solution very very simple, even if that means starting over from scratch.

From: Stastny Richard [mailto:[email-masked]] 
Sent: Tuesday, November 07, 2006 3:15 PM
To: [email-masked]; Livingood, Jason; [email-masked]
Subject: Re: [Enum] draft-ietf-enum-void-02 --> First Question - AgreementonSOLUTION Void?

So who is defining them?

Richard

Yes..

---

From: "Stastny Richard" <[email-masked]>
Date: Tue, 7 Nov 2006 22:03:01 +0100

You should not forget 
1. void is optional
2.it may be very useful also in private ENUMs
 
Richard

Von: Pfautz, Penn L, GBLAM [mailto:[email-masked]]
Gesendet: Di 07.11.2006 21:34
An: Stastny Richard; [email-masked]; Livingood, Jason; [email-masked]
Betreff: RE:draft-ietf-enum-void-02 --> my problem

Penn

---

From: "Pfautz, Penn L, GBLAM" <[email-masked]>
Date: Tue, 7 Nov 2006 16:12:27 -0500

Richard:
I agree with both points but would feel better if the draft addressed
the issue and pointed to potentially limits on
The environments in which it might be used as was done, for example in
the cnam drafts.

Penn 

-----Original Message-----
From: Stastny Richard [mailto:[email-masked]] 
Sent: Tuesday, November 07, 2006 4:03 PM
To: Pfautz, Penn L, GBLAM; [email-masked]; Livingood, Jason;
[email-masked]
Subject: Re: draft-ietf-enum-void-02 --> my problem

You should not forget 
1. void is optional
 
Richard

Penn

---

From: "Stastny Richard" <[email-masked]>
Date: Tue, 7 Nov 2006 22:25:23 +0100

ok, we add something in the security section
 
Richard

Von: Pfautz, Penn L, GBLAM [mailto:[email-masked]]
Gesendet: Di 07.11.2006 22:12
An: Stastny Richard; [email-masked]; Livingood, Jason; [email-masked]
Betreff: RE: draft-ietf-enum-void-02 --> my problem

Richard:

Penn

-----Original Message-----
From: Stastny Richard [mailto:[email-masked]]
Sent: Tuesday, November 07, 2006 4:03 PM
To: Pfautz, Penn L, GBLAM; [email-masked]; Livingood, Jason;
[email-masked]

You should not forget
1. void is optional

Richard

Penn

---

From: Otmar Lendl <[email-masked]>
Date: Tue, 7 Nov 2006 22:41:12 +0100

On 2006/11/07 20:11, Richard Shockey <[email-masked]> wrote:
[...]

> someone thinks of something else like  text:inactive;SPID=6666

As mentioned before, the basic idea seems fine. I'm just a bit confused
about the text: URI. I can't find that URI scheme at 
http://www.iana.org/assignments/uri-schemes.html

Did you mean data:?

/ol

---

From: Alexander Mayrhofer <[email-masked]>
Date: Wed, 08 Nov 2006 00:33:17 +0100

> E2U+status:text   where the URI is a text URI   text:inactive

just a short note: That could aid to the confusion, because one could get
the impression that if this is a mobile number for which the "text" (SMS)
service is disabled...

However, that could actually be a feature (collides with eg. SIP's
negotiation capabilites)...

Alex

---

From: "Richard Shockey" <[email-masked]>
Date: Tue, 7 Nov 2006 18:43:02 -0500

HUMMM  You're right, there is only the data URI... I could have sworn I saw
text some where .. but the default mode of data is ASCII text

> Sent: Tuesday, November 07, 2006 4:41 PM
> To: Richard Shockey
> Cc: 'Livingood, Jason'; [email-masked]

---

From: lconroy <[email-masked]>
Date: Tue, 7 Nov 2006 23:46:23 +0000

Hi Folks,
  OK - you have filled up my mailbox, now it's your turn.
(i)   I checked - 3761 does not say anything about URNs, so they are  
not banned.
(ii)  what text: URI? Otmar's data: is the nearest legal option, but  
it sure is ugly.
       Getting rid of the http: or mailto: seems unwise, as they are  
valid URIs.
       I hope you all at least agree that there should be some URI in  
a NAPTR, right?

(iii) For unassigned/unallocated numbers, who exactly gets to  
populate the (user) ENUM zone?

It must be the election fever over there...

all the best,
   Lawrence

---

From: Alexander Mayrhofer <[email-masked]>
Date: Wed, 08 Nov 2006 00:54:46 +0100

lconroy wrote:
> (iii) For unassigned/unallocated numbers, who exactly gets to populate
> the (user) ENUM zone?

it cannot be delegated. An upright assignment is one of the requirements for
ENUM validation and hence delegation.

So, this service would mainly apply to "infrastructure" and "private" use,
HOWEVER, a registry might decide (or be instructed by the local NRA) to also
add such records into the tier 1 zone itself to cover "black holes" in the
numbering plan ...

would eg. work perfectly for unassigned area codes in the NANP...

cheers

Alex

---

From: "Stastny Richard" <[email-masked]>
Date: Wed, 8 Nov 2006 01:12:44 +0100

I think this is not a text URI it is data URI
 
E2U+status:data "!^.*$!data:,unassigned!"
 
Richard

Von: Alexander Mayrhofer [mailto:[email-masked]]
Gesendet: Mi 08.11.2006 00:33
An: [email-masked]
Cc: [email-masked]; 'Livingood, Jason'
Betreff: Re: [Enum] draft-ietf-enum-void-02 --> First Question - AgreementonSOLUTION Void?

Alex

---

From: "Richard Shockey" <[email-masked]>
Date: Tue, 7 Nov 2006 19:16:23 -0500

> From: lconroy [mailto:[email-masked]]
> Sent: Tuesday, November 07, 2006 6:46 PM
> To: Otmar Lendl; Richard Shockey
> Cc: [email-masked]; Jason Livingood

It's the best we can get right now and Jason and I are using it in the CNAM
draft.

If you do URI I's suspect a pushback from the IESG to respin the document
..the consensus is to finish this project.

> populate the (user) ENUM zone?

We put text in there suggested by Penn Pfautz that this data is generally
restricted ..yada yada similar to what Jason and I did in the PSTN LNP
draft.

This data is not expected to be used in the public ENUM tree.

---

From: Alexander Mayrhofer <[email-masked]>
Date: Wed, 08 Nov 2006 01:15:13 +0100

> E2U+status:data "!^.*$!data:,unassigned!"

Fine with me. However, in that case i'd leave out the subtype of the
Enumservice. It does not add any value.

Alex

---

From: "Richard Shockey" <[email-masked]>
Date: Tue, 7 Nov 2006 19:17:49 -0500

Looks right to me ..

> Sent: Tuesday, November 07, 2006 7:13 PM
> To: Alexander Mayrhofer; [email-masked]
> Cc: [email-masked]; Livingood, Jason

---

From: lconroy <[email-masked]>
Date: Wed, 8 Nov 2006 00:30:54 +0000

Hi Alex, folks,
  Actually, yes it does add something.
data: need not be the only possible URI scheme ever associated with a  
"status" Enumservice,
and from the mangled audio someone said in the ENUM meeting that  
extensibility should
be considered.

all the best,
   Lawrence

---

From: "Richard Shockey" <[email-masked]>
Date: Tue, 7 Nov 2006 19:30:50 -0500

Hi Alex, folks,

all the best,
   Lawrence

---

From: "Richard Shockey" <[email-masked]>
Date: Tue, 7 Nov 2006 19:30:50 -0500

I agree it does no harm.

> Sent: Tuesday, November 07, 2006 7:20 PM
> To: Alexander Mayrhofer
> Cc: [email-masked]; [email-masked]; Livingood, Jason
> I like to have the URI in the ENUMservice
> you never know what comes next, it is extensible
> 
> Richard
> 
> Gesendet: Mi 08.11.2006 01:15
> An: Stastny Richard
> Cc: [email-masked]; [email-masked]; Livingood, Jason

i"
Cc: [email-masked], "'Livingood, Jason'" <[email-masked]>
Reply-To: [email-masked]

I agree it does no harm.

> Sent: Tuesday, November 07, 2006 7:20 PM
> To: Alexander Mayrhofer
> Cc: [email-masked]; [email-masked]; Livingood, Jason
> I like to have the URI in the ENUMservice
> you never know what comes next, it is extensible
> 
> Richard
> 
> Gesendet: Mi 08.11.2006 01:15
> An: Stastny Richard
> Cc: [email-masked]; [email-masked]; Livingood, Jason

---

From: Alexander Mayrhofer <[email-masked]>
Date: Wed, 08 Nov 2006 01:32:03 +0100

> you never know what comes next, it is extensible

We could still extend it, even if we start first without an subtype. afaik
it is perfectly legal to mix subtypes with non-existing subtype in a single
type definition. The "empty" subtype is not special among them, it's not a
"fallback" (correct my guys if i'm wrong).

eg. if we would extend the "status" later we'd probably have:

E2U+status		data:
E2U+status:pstn 	(whatever)
E2U+status:ngn        (whatever)
...

... or whatever. I'm just hesitating to "burn" one of the Enumservice
distinguishing options by putting redundant information into it in the first
place.

Alex

---

From: lconroy <[email-masked]>
Date: Wed, 8 Nov 2006 00:40:58 +0000

Hi Richard, folks,
  Scanning the list, I'm not sure that it's easy to make that  
consensus call.

 From this side of the World, it looks more there's a proposal for a  
different
Enumservice called "status", with (a) different URI scheme.

This new Enumservice would focus on one of the use cases covered in  
VOID,
would have different restrictions on use, and would be designed to avoid
any "pushback" that VOID received.

It would apparently not have the equivalent of section 7 of VOID, and so
would be not exactly useful in an open numbering plan environment.

If it looks like a duck, it quacks like a duck, it probably isn't VOID.

all the best
   Lawrence

> ..the consensus is to finish this project.
<snip>

---

From: "Richard Shockey" <[email-masked]>
Date: Tue, 7 Nov 2006 19:51:42 -0500

OK ..well if that's what you want I'm sure Jason or I or someone can whip up
a substitute draft dealing with the specific issues of number "status" in
about 2 hours. Since the subject matter is within already approved WG
document scope [I'll check with the AD's] but IMHO it could instantly be
made a WG item and go to last call probably within a week.

Is that what you want? Split status issues from void?

It really doesn't matter to me one way or another ..I'm trying to facilitate
fixing a problem.

> Sent: Tuesday, November 07, 2006 7:41 PM
> To: [email-masked]
> Cc: [email-masked]; 'Jason Livingood'; 'Otmar Lendl'

---

From: "Stastny Richard" <[email-masked]>
Date: Wed, 8 Nov 2006 01:54:44 +0100

No I do not thinks so
 
It is the same Enumservice with a different name

It does not is provide the ownership
(which may also provided in data, but you may not need to retrieve
this infomation via ENUM, you may also get it via the NRAs webpage)

It provides a possibiltiy to distingish between unallocated, unassigned and inactive
(I have no idea who needs this, but who cares)
 
The issue with the "enclosing zone" is still there:
this should stay in the document as not recommended possibility
for fixed lentgh numbering plans, but as useful in varialble
numbering plans
 
Richard

Von: lconroy [mailto:[email-masked]]
Gesendet: Mi 08.11.2006 01:40
An: [email-masked]
Cc: [email-masked]; 'Jason Livingood'; 'Otmar Lendl'
Betreff: Re: [Enum] draft-ietf-enum-void-02 --> First Question - AgreementonSOLUTION Void?

Hi Richard, folks,

all the best
   Lawrence

<snip>

---

From: Alexander Mayrhofer <[email-masked]>
Date: Wed, 08 Nov 2006 01:53:33 +0100

> would be not exactly useful in an open numbering plan environment.

alex whispers: *wildcard*

ducks, and runs away. :)

---

From: "Stastny Richard" <[email-masked]>
Date: Wed, 8 Nov 2006 01:59:31 +0100

Do not run away ;-)
 
wildcard only works in Infrastructure ENUM having only a tier 1
 
If we want to have an ENUMservice ONLY for Infrastructure ENUM - fine
 
But IMO it should also work in User ENUM
 
So we could add text saying that the "enclosing zone" is only required in User ENUM
in Infrastructure ENUM this could also be done with wildcards
 
Richard

Von: Alexander Mayrhofer [mailto:[email-masked]]
Gesendet: Mi 08.11.2006 01:53
An: lconroy
Cc: [email-masked]; 'Otmar Lendl'; 'Jason Livingood'; [email-masked]
Betreff: Re: [Enum] draft-ietf-enum-void-02 --> First Question - AgreementonSOLUTION Void?

ducks, and runs away. :)

---

From: Jim Reid <[email-masked]>
Date: Wed, 8 Nov 2006 01:09:55 +0000

> for fixed lentgh numbering plans, but as useful in varialble

Even with a fixed numbering plan, the problem of finding the closest  
encloser remains: eg delegations on an "area code" basis or to a DDI  
block. When there are a fixed number of labels (digits in this case)  
in some domain name this tells you nothing about the number of  
delegations that could exist within that domain name or where those  
delegations occur.

BTW people, I've changed the subject header to make it more  
appropriate to this thread. Please try to do this for all the other  
threads that have exploded off "draft-ietf-enum-void-02 --> First  
Question - Agreement on Problem Statement?" :-)

---

From: Jim Reid <[email-masked]>
Date: Wed, 8 Nov 2006 01:28:23 +0000

> in Infrastructure ENUM this could also be done with wildcards

I would not support this. It is far from clear whether the need to  
find the enclosing zone is only a problem for User ENUM. My gut feel  
is it isn't. Current thinking for Infrastructure ENUM or Enterprise  
ENUM might focus around monolithic centralised systems. That may  
change later. So tossing the closest encloser issue away at this  
stage may well return to haunt the WG. A generalised solution that  
isn't specific to one flavour of ENUM is the way forward IMO.

My views about DNS wildcarding are well known and don't need to be  
repeated here. Putting text in the draft that says "you can do this  
with wildcards" is just bad. Should the draft enumerate all the other  
silly and ill-advised ways of solving this problem as well? Where  
should the line be drawn? More importantly if the draft contains this  
sort of text, clueless bozos will interpret that as meaning "the IETF  
says it's perfectly OK to use wildcarding to handle this problem" and  
deploy that approach.

---

From: "Stastny Richard" <[email-masked]>
Date: Wed, 8 Nov 2006 01:20:19 +0100

Richard

Alex

---

From: [email-masked]
Date: Fri, 10 Nov 2006 11:58:45 -0500

From: Jim Reid <[email-masked]>

   My views about DNS wildcarding are well known and don't need to be  
   repeated here. Putting text in the draft that says "you can do this  
   with wildcards" is just bad.

I'm starting to notice that DNS wildcards seem to almost solve some
interesting problems, except they don't.

One that we've been looking into is for an organization to set up its
own internal ENUM tree containing only record that forward ENUM
lookups to appropriate external ENUM trees.  This allows the
organization to, say, by default route everything to a service
provider's private ENUM tree, extract subtrees to be routed via the
internal network, extract other subtrees to be routed to a different
service provider, etc.

It would seem that the way to do this is to set up DNS wildcard NAPTRs
at the root of each subtree which is treated differently from its
containing subtree.

As another case, there is a proposal at this IETF to insert special
DNS records at the root of each national ENUM subtree.  It would be
wonderful if a query for that record type, directed to an ENUM domain
name, would return the nearest record going up the tree, and wildcards
would seem to be the way to do this.

Except that DNS wildcards don't work this way -- the effect of a
wildcard on a domain name "under" it is canceled if there is any DNS
record for any of the intermediate domains.

What I'm hoping is that there's a known solution for this problem, of
getting "the FOO record for this domain or the nearest ancestor record
that has a FOO record".

Dale

---

From: [email-masked]
Date: Fri, 10 Nov 2006 11:58:45 -0500

Dale

---

From: Otmar Lendl <[email-masked]>
Date: Fri, 10 Nov 2006 19:01:14 +0100

> interesting problems, except they don't.

They solve *some* problems, and while doing that give you enough rope
to hang yourself trying to extend a working solution to other problems.

> at the root of each subtree which is treated differently from its

Non-terminal NAPTR are tempting for that, e.g.

  *.1.2.3.4.5.e164.arpa. "" "" 0 0 "" some.other.domain.

  In that case, we don't loose the Application Unique String, but
  we do loose the information what labels the wildcard subsumed.

  If some.other.domain uses simple NAPTR records, than all numbers under
  +54321 will map to the same URI. That's likely not to be what you want to
  happen.

  (Besides, almost no one has implemented NTNs yet.)

Thus this is not a valid option.

> would seem to be the way to do this.

Yes, the EBL record sounds fine for your application.

> getting "the FOO record for this domain or the nearest ancestor record

As mentioned before, wildcards do work for very specific problems.
Deploying them into generic tree which can contain other records
is asking for ugly surprises.

So, in your case, if you create your own private tree where you
control the full tree (which is best put into one zone, thus no
NS-style delegation) and if you only put wildcarded EBL records
in there, then IMHO you're quite safe.

The only issue you have to worry about then is the effect of
"empty non-terminals" on wildcards (see RFC 4592). Example:

If you have these two wildcards in your zone:

          *.6.7.8.9.e164.example
*.1.2.3.4.5.6.7.8.9.e164.example

then e.g.

0.0.0.0.4.5.6.7.8.9.e164.example
will not be match the *.6.7.8.9.e164.example wildcard.

The Austrian I-ENUM trial encountered this issue as well. We solved it
by auto-generating appropriate records. That's a rather short perl-
script with loads the DNS tree, walks the tree to generate the needed
entries and spits out a fixed version of the zonefile.

Please send email if you want to have a copy.

/ol

---

From: [email-masked]
Date: Fri, 10 Nov 2006 23:42:05 -0500

From: Otmar Lendl <[email-masked]>

	     *.6.7.8.9.e164.example

   then e.g.

Yes, but this requires being able to predict what the E.164 numbers
are in advance, or at least, a close approximation of the numbering
plan.  And it generates as many DNS records as there are E.164 numbers
in the subtree, which is likely to be millions, rather than the number
of subtrees with different treatments, which is likely to be around
10.  I suppose in an I-ENUM situation, the carriers are already fully
informed about the numbering plan, and may expect to have a separate
NAPTR record for every number in-use, but if it's just to route ENUM
lookups to one of a set of external service providers, it's not
efficient.

Dale