Subject: [Crisp] ENUM use cases for draft-ietf-crisp-iris-dchk-04.txt

From: Alexander Mayrhofer <[email-masked]>
Date: Fri, 10 Feb 2006 10:45:22 +0100

Hi,

i'm trying to apply certain ENUM use cases to the dchk-Draft, and would 
appreciate your opinions about them.

Contrary to "flat" domain registries (which means that they always operate 
on the same delegation levels [example.com vs. example2.com]), ENUM can have 
"overlapping" registrations. (eg. registries in countries with variable 
E.164 number lengths have to deal with delegation on different levels in the 
DNS tree).

Therefore, a domain name can not only be blocked by a exact match, but also 
by more/less specific label chains.

Same is true even in countries with closed numbering plans if an ENUM 
registry opts for number block type records, so that a single  record (be 
that a NS/CNAME style delegation, or a wildcard NAPTR record for "fat" 
registries) covers a whole range of numbers (eg. 100 numbers).

In both cases, a dchk query would not only need to consider the exact domain 
label, but rather more and less specifics as well, since they could prevent 
a registration of the domain in question.

eg. if the registry already contains a wildcard for *.1.2.3.4.e164.arpa, a 
dchk for 0.1.2.3.4.e164.arpa would need to indicate that the DNS space of 
this record is already occupied (same for eg. 2.3.4.e164.arpa), ideally 
pointing to the "blocking" domain object.

It could even become more complicated: Consider the case of a "fat" registry 
(which means that all NAPTRs are hold within the registry itself), where 
block allocations are represented by wildcard records, BUT numbers may be 
ported out from those blocks by the creation of more specific NAPTR records 
_within_ this block, even by other clients.

Example:

- Number block +43123 is represented in the registry by a NAPTR wildcard at 
*.3.2.1.3.4.e164.arpa (created by client A)
- client B checks for number +431234, because this number is to be ported 
out by a "more specific" NAPTR.
- dchk should indicate that there is already a less specific block, but, 
however, due to registry policy registration of the more specific number is 
nevertheless possible (or, not possible, depending even on more complicated 
policy).

So, i'd appreciate your input on the following questions:

- What status should be returned in case a domain name is blocked by a "more 
specific" or a "less specific" domain name?
   - for the case "registration not possible"
   - for the case "registration nevertheless possible"

- Which element would be used to return the "offending" domain in case of a 
"blocking" delegation: <domainVariant> does not exactly seem to fit 
(tailored for IDN?), <iris:seeAlso> seems to be a bit too generic for this...

- How can a registry indicate to a client that although the domain is 
question is "blocked" by a less specific record (eg. wildcard) it may be 
registered anyways (the "more complicated" case mentioned above)?

Please let me know if anything is unclear, and needs to be elaborated.

thanks,

Alex Mayrhofer
enum.at

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

---

From: Andrew Newton <[email-masked]>
Date: Fri, 10 Feb 2006 05:54:15 -0500

Hi Alex,

My comments in-line:

On Feb 10, 2006, at 4:45 AM, Alexander Mayrhofer wrote:
>
> eg. if the registry already contains a wildcard for *. 
> 1.2.3.4.e164.arpa, a dchk for 0.1.2.3.4.e164.arpa would need to  
> indicate that the DNS space of this record is already occupied  
> (same for eg. 2.3.4.e164.arpa), ideally pointing to the "blocking"  
> domain object.

I think we need to be careful with terminology here.  What can be put  
into DNS is a superset of what can be put into a DNS registration  
system.  A registry may not allow registrations at a level where  
there exists a wildcard, but that is not the case for DNS itself.

In forward domain registration systems, it is also not typical to  
allow a wildcard to block a registration.

> - What status should be returned in case a domain name is blocked  
> by a "more specific" or a "less specific" domain name?
> - Which element would be used to return the "offending" domain in  
> case of a "blocking" delegation: <domainVariant> does not exactly  
> seem to fit (tailored for IDN?), <iris:seeAlso> seems to be a bit  
> too generic for this...
>
> - How can a registry indicate to a client that although the domain  
> is question is "blocked" by a less specific record (eg. wildcard)  
> it may be registered anyways (the "more complicated" case mentioned  
> above)?
>

I think the simple answer is that DCHK was not designed for this.   
The use case for DCHK is simple domain availability in the forward  
DNS . DCHK was originally introduced in the same draft with LWZ  
because the intent was to have a very fast service (we subsequently  
decoupled them draft-wise because of the confusion that they could  
only be used together).  It is a proper subset of DREG, and the  
intent is that registries could advertise the lightweight  
availability service in S-NAPTR on boxes different from the heavier  
weight DREG (this is a strategy that some domain registries use today).

Of course, there are ways to overload the semantics in DCHK to get  
what you want using things like the <other> status and <seeAlso>.   
But my feeling is that what you want is far enough from the forward  
domain availability check use case that using DCHK would work but it  
would not be pretty.  It sounds to me that you have outlined a good  
need for an ECHK or identified a new use case for EREG2.

-andy