Re: I-D Action: New draft - draft-bellis-enum-send-n-00

On 2008/04/04 11:04, "Clive D.W. Feather" <[email protected]> wrote:
> Otmar Lendl said:
> > Wouldn't it be easier to use absolute values here?

The reason for my comment just was that absolute values play much
better with wildcards than relative ones.

> (2) Making it relative means that the record value depends only on records
> lower down the tree, not where the record is in the tree. If it's absolute,
> then moving a sub-tree could alter the required value.

Correct. You certainly will not manually edit the zone file anyway, but
instead generate it from a database. Thus the change in send-n records
is just a side effect of the changes you need to make in the backend database. 

> For example, my home telephone exchange has changed over the years from
>         +44 954 8xxxx
>     to  +44 954 78xxxx
>     to  +44 1954 78xxxx
> The latter change also involved an overlap period.
> 
> Under this proposal, the send-n record corresponding to the xxxx is
> "pstndata:send-n/4-4" in all three cases. With your proposal, it would have
> to alter from:
>         pstndata:send-n/10-10
>     to  pstndata:send-n/11-11
>     to  pstndata:send-n/12-12

One changed send-n record as you move over 10^4 other records. 

> (3) The present proposal matches what the device consuming the record
> actually needs to do. The above send-n record could be reached after I dial
> any of:
>     78
>     0195478
>     0044195478
> In these three cases, the device needs a total of 6, 11, or 14 digits, but
> in each case your proposal means it gets a record saying 12 digits. The
> original proposal says it needs to get 4 more digits, which is always
> correct.

Whoa, stop here.

You're talking dial-plans now, not numbering-plans. 

As others have noted, we don't do dial-plans with ENUM.

/ol
-- 
// Otmar Lendl <[email protected]>, T: +43 1 5056416 - 33, F: - 933
// nic.at Internet Verwaltungs- und Betriebsgesellschaft m.b.H
// http://www.nic.at/  LG Salzburg, FN 172568b, Sitz: Salzburg