Re: [Enum] draft-bellis-enum-send-n-00

[Otmar Lendl <lendl at nic.at>]

On 2008/04/04 12:04, Jim Reid <jim at rfc1035.com> wrote:
> On Apr 3, 2008, at 20:16, Roy Arends wrote:
> > On Apr 3, 2008, at 1:35 PM, Jim Reid wrote:
> >> On Apr 3, 2008, at 08:05, Duane wrote:
> 
> > Technically you could have a wildcard here, but it just makes no  
> > sense doesn't it?
> 
> There may be circumstances where a wildcard will be needed. For  
> instance when there are other NAPTRs besides this funky send-n  
> service type at a given owner name.
> 
> Even though I despise wildcards, it's not unreasonable to have a  
> construct like:
> 	*.<area-code-and-other-goop>.e164.arpa. NAPTR ... "<some-sip:-URI>" ..
> to direct all numbers in a block to a specific end-point. Or maybe  
> there are a bunch of wildcard NAPTRs, one for each specific service.  

This is a common deployment for all countries with open numbering plans,
as the organization creating these records do not necessarily know the
length of all the numbers in its own block.

> If this scheme is deployed or needed, it can't be done if this send-n  
> proposal goes ahead in its current form and there has to be one of  
> these send-n NAPTRs as well. This is why I suggest a new RRtype  
> that's specifically designed for encoding numbering schemes instead  
> of a NAPTR.

I might be completely off here, but my dim recollection about the
working of wildcards tells me that it doesn't matter one jota whether
you mix wildcards of type FOO with "normal" records of type FOO or with
"normal" records of type BAR. In any case, once there is *any* record
at a certain sub-domain, the wildcard from above does no longer apply.
(Actually, it's even worse, read RFC 4592 and look for the discussion of
"empty non-terminals". We had a lot of fun with that during our I-ENUM
trial.)

As I see it, you can mix

  *.<area-code-and-other-goop>.e164.arpa. NAPTR ... "<some-sip:-URI>" ..
    <area-code-and-other-goop>.e164.arpa. NAPTR ... "send-n/" ..

but neither

     *.<area-code-and-other-goop>.e164.arpa. NAPTR ... "<some-sip:-URI>" ..
 1.2.3.<area-code-and-other-goop>.e164.arpa. NAPTR ... "send-n/" ..

nor

     *.<area-code-and-other-goop>.e164.arpa. NAPTR ... "<some-sip:-URI>" ..
 1.2.3.<area-code-and-other-goop>.e164.arpa. WHATEVER ... "send-n/" ..

In both cases you'd need to add

      3.<area-code-and-other-goop>.e164.arpa. NAPTR ... "<some-sip:-URI>" ..
    *.3.<area-code-and-other-goop>.e164.arpa. NAPTR ... "<some-sip:-URI>" ..
    2.3.<area-code-and-other-goop>.e164.arpa. NAPTR ... "<some-sip:-URI>" ..
  *.2.3.<area-code-and-other-goop>.e164.arpa. NAPTR ... "<some-sip:-URI>" ..
  1.2.3.<area-code-and-other-goop>.e164.arpa. NAPTR ... "<some-sip:-URI>" ..
*.1.2.3.<area-code-and-other-goop>.e164.arpa. NAPTR ... "<some-sip:-URI>" ..

in order to get the desired resolution behaviour for the call routing.

The wildcard issue is thus irrelevant to the question of whether the
"send-n" application should use NAPTRs or a different RRTYPE.

/ol
-- 
// Otmar Lendl <lendl at nic.at>, T: +43 1 5056416 - 33, F: - 933
// nic.at Internet Verwaltungs- und Betriebsgesellschaft m.b.H
// http://www.nic.at/  LG Salzburg, FN 172568b, Sitz: Salzburg
_______________________________________________
enum mailing list
enum at ietf.org
https://www.ietf.org/mailman/listinfo/enum