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

> I'm pretty sure it was you that made the comment about the DNS software
> you're using is custom written, it would be almost silly to pre-populate
> a database with all the possible combinations when most are the same 
etc.

There are cases where the Send-N records could be completely automatically 
synthesised in real-time.

In the UK case, however, each carrier is expecting to secondary 
significant portions of the database into their own DNS servers.

We don't expect those carriers to perform the same synthesis, therefore 
the Send-N's are expeced to be pre-populated as real RRs in the zone file. 
 They'll be available in IXFRs just like any other RR.

> Someone else, maybe it was you mentioned this was meta information, your
> reasoning for keeping this in NAPTR space is to reduce lookups, fair
> enough, so still do it under a new RR type, and return this in the
> additional section along with NAPTR records in the answer section.
>
> If you aren't going to pre-populate a DNS database (like BIND) then
> where is the issue with sticking it under some other RR type?

This idea of using the Additional Section and why it was rejected was 
mentioned a couple of days ago.

There was a lot of concern from the WG as to whether Send-N would change 
any semantics of DNS (specifically wildcards, of course).  IMHO, making a 
change which relies on non-standard behaviour in any server would do just 
that.

The UK CDB operator may well use customised DNS server software, but its 
behaviour as currently proposed will look completely standard to the 
outside world.  We also can't expect all of the carriers who are 
secondarying the zones to have to run customised DNS server software with 
special Additional Section handling.

FWIW, I think Lawrence is onto something when he suggested a separate DDDS 
service (albeit in the same tree).  I'd like to hear what others think of 
that.
 
Ray