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

On Jun 28, 2008, at 2:03 AM, Duane wrote:

> Roy Arends wrote:
>
>> In DNS, the concept of Wildcard Domain Names only exist in the
>> authoritative server. Since you quoted a response message, these  
>> records
>> may be the result of wildcard domain name processing on the server,  
>> but
>> are certainly not "wild cards" nor wildcard domain name.
>
> You say potato I say well who cares,

I think it is important to disambiguate statements that seem to cause  
confusion amongst the readers. This is not per se a noble goal, but  
actually a requirement to gain consensus later. I would like to know  
exactly what causes resentment against a certain proposal, even when  
it takes a bit dissecting.

> the point is he was welcome to try
> the query for himself, the \\1 (dig adds the extra slash) and the .*  
> in
> the NAPTR record should have tipped him off to the fact it was a  
> wild card.

I thought you were referring to wildcard domain names, as in RFC 4592.

>> Please re-read what Ray said: "those NAPTRs would hide any wildcard
>> send-N record higher up".
>
> If I do the same query for +44800\d{1,10} and the results would be the
> same, yet if a send-n appears at a more specific location the result
> wouldn't be the same.
>
>> Given that Ray could not have known that you actually used an  
>> expanded
>> wildcard domain name, but assumed
>> that these are regular, unexpanded Resource Records, he asserted that
>> you would have a wildcard domain name at an ancestor name.
>
> Again, he was free to re-do the query himself if he did not understand
> what I was expressing, this isn't supposed to be rocket science but
> there is clearly a fundamental lack of understanding here as to the
> effect of send-n by its proponents.

The odd thing about your statement is that you seem to be convinced of  
a "fundamental lack of understanding to the effect of send-n by its  
proponents", but you then try to educate those "proponents" in a  
fairly hostile, divisive way. This combination does not help your  
case, and for the rest of the list, it is kind of weary to read.

>> This is silly. This doesn't "break" wildcards. This is EXACTLY how
>> wildcard domain name processing should behave, i.e. an existent  
>> name has
>> precedence over a wildcard domain name at an ancestor domain.
>
> *sigh* You guys

For the record: I am neither a "proponant or an opponant" of the  
proposed technology. I became part of this discussion because I though  
I could weed out some of the confusion about wildcards in the domain  
name system. In my mind, even with my limited knowledge of the DNS,  
and even less about ENUM, I thought that there is a certain alarmist  
tone in stating that 'send-n breaks wildcards'. It is at least  
ambiguous, as I have showed above.

> can keep pushing this all you want but you so far
> haven't shown why this shoul be accepted it has the potential to
> substantially increase load on DNS and cause looping all of which  
> would
> need to be dealt with as special cases and even if it was passed as a
> NAPTR type the DNS guys would most certainly have a beef with all the
> additional queries.

There is already a warning in the send-n draft about the combined use  
of send-n records and wildcards.

> As I said before this seems to be more like a routing protocol,
> something in the domain of BGP where everyone has a complete view of  
> the
> dial plan and updates are broadcast as they happen.
>
>>> so it's more than obvious that those in charge of this
>>> decision making process in my opinion do not have the necessary
>>> technical skills to be making this kind of decision,
>>
>> This assertion is too ad hominem. Please be polite.
>
> I've tried to be, but that doesn't seem to be working, so I thought a
> slightly more strongly worded email might have more of an impact, I
> guess I was being naive in assuming what I was expressing was being
> understood.

Well, if you feel that you are being misunderstood, wording your email  
more strongly does not help, and might even have an adverse effect.

regards,

Roy