Re: Send-N draft: draft-bellis-enum-send-n-02 published

On Fri, Jul 04, 2008 at 02:08:20AM +0100, Eleanor McHugh wrote:

> a. it solves the number length problem in ENUM

may I ask for a description of this problem?  What is the input and what is the
desired output?

> b. it allows the shape of portions of the DNS tree to be specified and  
> validated

The problem here is that it doesn't buy you much in the general DNS case.
There you face the fact that hierarchy in the name space does neither
follow nor imply administrative hierarchy (or control, if you wish).
So, while under certain circumstances you might be able to make statements
about the current shape of the tree, you're likely not in a position to
communicate rules.  For this reason finding a use case could become hard.

However, the situtation is slightly different in the case of ENUM since
there is some hierarchy in the e.164 space.  However, the applicability
is dependent on which part of the tree you're in since the rules,
including who actually sets the lengths of certain number ranges, vary
by country.

> I've missed something in my interpretation of the send-n draft as I  
> don't see how using a non-NAPTR resource to achieve the same effect  
> makes any difference. In both cases the RR is making statements about  
> the shape of the tree beneath the current level.

From a DNS perspective, another RR type would be cleaner; however, the
question is whether you're actually describing a property of the DNS or
a property of the data that is put into the DNS.  This may sound like
splitting hairs, but the length and completeness issues are around
the e.164 numbers, not necessarily the DNS representation, even though there
is a very straightforward mapping.  Anyway, the basic reason use of NAPTR
(with which I've voiced my discomfort before) is that that's what you
ask for so it can "nicely" be put into the DNS repsonse.  Another RR type
would have to be asked for explicitly _or_ some DNS rules would have to
be changed (or gravity, whatever comes easier) to insert this new RR type
(or any one, the problem isn't the novelty of the type) into the additional
information of the response.  This is yet another example where DNS is
that ultimater best fit for ENUM/I-ENUM, just needs these little tewaks ...

-Peter