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

----- Original Message From: <[email protected]>

>> 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?)  This seems bad practice to me.  Ideally there would be 
some authorative data set that was the input to the scripts and the whole 
process would be automated.

So the pros and cons of the relative form seem to be:-

Benefits of keeping relative form:
- Might use less (disk) space (although I don't think so).
- Easy to migrate an existing number prefix to another one without 
re-running a script.

Benefits of getting rid of relative form:
- (disk) space is not that important.
- Avoids encouraging bad practice of tweaking output of script processes.
- Gets rid of the wildcard issue (I'm still don't understand whether this is 
a real issue, but as a minimum it saves list bandwidth!)
- Means clients have only one type of result to process (absolute) rather 
than two (which requires more testing etc).

So, when a number plan does change (of the sort I'm used to in the UK 
anyway), knocking up another set of zones seems a trivially unimportant 
thing to optimize compared to all the other things that have to happen when 
such a change takes place (such as informing all the users, re-printing 
directories, installing IVRs that say "we'll route you this time, but in 
future you should dial this number..." and so on).

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

Regards,

Pete.
--
=============================================
Pete Cordell
Codalogic
=============================================