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

Tidying up along the thread. This isn't a major issue, but ...

Pete Cordell said:
>>>understood.  Since that is an optimization for a provisioning issue of
>>>- to me - unclear frequency of occurence, would much be lost with using
>>>the absolute value only?
>> Personally I'm not sure.  Clive thinks relative is useful.
> From what I understand of this issue, the relative form of send-n just does 
> not seem worth the grief.  It's already been said that the zone files (or 
> what ever the preferred DNS input will be) will be automatically generated 
> by some sort of automated process such as a script.  So, pre-number move at 
> some point a script will be used to generate a set of zone files.  When the 
> new number plan comes along it seems just as easy to re-build a new set of 
> zones based on the new number plan using the same script.
> 
> I'm probably looking at it too simplistically, but, because a script can so 
> readily generate a zone file for any given input, the only benefit I can 
> see for the relative form is that it allows someone to manually tweak an 
> existing zone.  (What would they do?  Copy an existing set, and then edit 
> the $ORGIN line?)

What I had in mind was to use DNAME.

So, if 01954 8xxxx is migrating to 01954 78xxxx, you would go:

$ORIGIN 4.5.9.1.4.4.e164.arpa.
8.7  DNAME  8

0.0.0.0.8  NAPTR ....
1.0.0.0.8  NAPTR ....
etc.

The send-n records would only work in this case if they were relative.

> I would therefore strongly encourage the authors to drop the relative form 
> of send-n.

It still seems sensible to me, but I'm not going to die in the ditch over
it.

-- 
Clive D.W. Feather  | Work:  <[email protected]>   | Tel:    +44 20 8495 6138
Internet Expert     | Home:  <[email protected]>  | Fax:    +44 870 051 9937
Demon Internet      | WWW: http://www.davros.org | Mobile: +44 7973 377646
THUS plc            |                            |