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

[Paul Kyzivat <pkyzivat at cisco.com>]

IMO this would be more appealing if the higher level entries (fewer 
digits) were authoritative at least for the minimum number of digits. 
Thus there would then be no further queries until at least that many 
digits were received.

	Paul

Clive D.W. Feather wrote:
> 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.
> 
_______________________________________________
enum mailing list
enum at ietf.org
https://www.ietf.org/mailman/listinfo/enum