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

Hi Duane,
  What Ray has raised (and is not addressed by your mails) is why
this is a NAPTR. It's like this because the client makes one query
- for DNS type 35 - and gets back not only this one but also any
Send-N answers.

Thus, if the client has the correct number of digits already (e.g.
the end user has an en-bloc phone and has entered the full number
before hitting the send button), the final answer comes out with
a single query.
Thus for that [common] case, there is NO DNS QUERY OVERHEAD at all.
That feature is more than good - it's crucial if this is deployed
in a real telecom net. DNS scales, but elapsed time is still important.

----
I am puzzled, however, by this long and peregrinating thread.
There is one question that seems to have been missed - does this need
to be an E2U NAPTR, or instead could it use another DDDS Application
(i.e. use a different collision-avoidance string)?
There is nothing in 3761 (or 3761bis) that says that E2U NAPTRs are
the only ones that can appear in a domain under e164.arpa.
If this were another DDDS Application, any Send-N will come back in
the same DNS response to a type 35 question. There would continue to
be no overhead for the en bloc case.
There would, however, be more flexibility, instead of being constrained
with a comedy URI. Public ENUM clients will automatically discard any
such NAPTR in the RRSet as it doesn't have the right collision-avoidance
string (E2U) -- assuming that the client is not totally broken.

So... what's wrong with moving this (and maybe other PSTN-internal
meta-information specifications) into their own DDDS Application?

all the best,
   Lawrence

On 18 Jul 2008, at 10:03, Duane wrote:
> [email protected] wrote:
>
>> If someone can propose a way to use a new RR-type which works with an
>> optimal number of packets (i.e. 1) rather than size of packets then  
>> I'm
>> open to it.
>
> You use the new DNS RR in the same way(s) you are proposing to use a
> NAPTR record. As I said in my previous email, a new RR type wouldn't
> have all the regex/text processing overhead so using binary parsing
> would speed things up considerably.
>
>>> DNS Type SENDN ID to be assigned by IANA, packet structure:
>>>
>>> 0 1 2 3 4 5 6 7
>>> +-+-+-+-+-+-+-+-+
>>> |MinDig |MaxDig |
>>> +-+-+-+-+-+-+-+-+
>>>
>>> Since the maximum length can only be 15 this fits perfectly inside a
>>> nibble :)
>>
>> Except for flags to indicate absolute vs relative :)
>
> 0 1 2 3 4 5 6 7 8 9 a b c d e f
> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
> |MinDig |MaxDig |F|0|0|0|0|0|0|0|
> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>
> Anything else?
>
> -- 
>
> Best regards,
> Duane
> _______________________________________________
> enum mailing list
> [email protected]
> https://www.ietf.org/mailman/listinfo/enum