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

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?
>   - 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.

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