Re: [Enum] draft-bellis-enum-send-n-00

["Clive D.W. Feather" <clive at demon.net>]

Dale.Worley at comcast.net said:
> It seems undesirable to not allow the send-n record to be usable as a
> wildcard.  The reason is that if one has a partial dial string that
> has not already been processed for send-n information, the only way to
> check if there is a relevant send-n record is to do DNS lookups on all
> prefixes of the string.  That results in a lot of DNS lookups, which
> is what the send-n mechanism was to avoid in the first place.

If the record holds relative lengths, as currently specified, a wildcard
won't work: it matches records at different levels in the tree, and these
need different send-n values.

To ensure that no unnecessary lookups happen, you do need to put a send-n
record in every intermediate node of the tree. In practice, though, if
people follow an algorithm like the one in my earlier message today, many
of these won't be needed and it might be acceptable to leave the others
out.

However, with a fully-provisioned sub-tree, the total number of send-n
records is less than 11% of the number of end records.

For example, if the root contains a record "send-n/6-15", then the part of
the UK tree corresponding to London contains:

    +4420xx            send-n/6-6        37 such records
    +4420xxxxxxxx      endpoints         up to 23 million such records

Even if we fill in the gaps, we get:

    +4420x             send-n/7-7         5 such records
    +4420xxx           send-n/5-5       273 such records
    +4420xxxx          send-n/4-4      2395 such records
    +4420xxxxx         send-n/3-3     23950 such records
    +4420xxxxxx        send-n/2-2    239500 such records
    +4420xxxxxxx       send-n/1-1   2395000 such records

The last set is the only one that's significant in size, but it only grows
as real data gets added (so in the absolute worse case, where exactly one
number from each block of 10 is in the database, it's the same number of
records as the real data).

> The second issue is the use of the maximum number of digitsmax -- if
> the owner of a higher-level node sets digitsmax, it can prevent the
> delegated owner of a subtree from using more digits.

This is a slight issue, yes. However, if the device uses subsequent send-ns
to override previous ones, it can be mitigated to some extent.

I accept that a certain amount of trust in the tree management is necessary.

> Or rather, the
> subtree can use more digits as long as the caller doesn't attempt to
> use send-n to determine the end of the dial string.  Indeed, it's not
> clear that digitsmax saves DNS queires in any practical case.  So
> maybe digitsmax should be removed.

It was intended as a way for the device to know that there's no point
accepting more digits and digging deeper into the tree. I accept that some
extra wording is probably needed.

-- 
Clive D.W. Feather  | Work:  <clive at demon.net>   | Tel:    +44 20 8495 6138
Internet Expert     | Home:  <clive at davros.org>  | Fax:    +44 870 051 9937
Demon Internet      | WWW: http://www.davros.org | Mobile: +44 7973 377646
THUS plc            |                            |
_______________________________________________
enum mailing list
enum at ietf.org
https://www.ietf.org/mailman/listinfo/enum