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

[Alexander Mayrhofer <[e-mail]>]

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
[e-mail]
https://www1.ietf.org/mailman/listinfo/crisp