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

Hi Ray, folks,
  Speaking of red herrings...

Re. D3S as a dump - are TXT records better than NAPTRs? ROFL
AFAICT, the logic here is that NAPTRs hold PoinTeRs, whilst data: allows
"final" data to be inserted. Then again, so does pstndata:. The names  
have
been changed, but the story is the same. It seems to me that Send-N is  
*NOT*
final data to be processed, but merely holds meta-data to assist in the
process. Whether that meta-data in Send-N is useful or needed in  
practice
is a reasonable question, but arguing that this is the same as replacing
TXT with NAPTRs (or that TXT is better) is not, IMHO.

Re. NTNs - these will have the effect of causing another lookup - that's
what they're intended to do. IMHO, there should be NO other impact at  
all.
You might want to point out that extra lookups are bad as they do cause
delays/extra traffic, but that is a general issue for infrastructure  
use.
Send-N seems to me to be no different. There will either be an NTN loop
or there will (eventually) be a target domain. That target domain either
includes E2U NAPTRs or it doesn't. You process those E2U NAPTRs or  
give up.
Done. This is bog standard stuff and is the case for any D3S  
application.

Regarding "collision avoidance" - this is covered in 3402 section 5,  
in 3403
section 3, and in 3761 section 2.4.2.
Why on earth would one need to cover it again in this Enumservice  
Specification
unless it is a particular problem for Send-N? I don't believe that is  
the case.
I would be surprised if anyone provisioned these in DNS node that also  
had
NAPTRs from other D3S applications - ENUM uses its separate tree as  
one means
for collision avoidance, and that's is broken if U-NAPTRs or 3263- 
style NAPTRs
are put there.

Regarding whether NAPTRs or another RR type should be used - NAPTRs  
seem to
have been chosen as there isn't a need for a further lookup once a  
terminal
node has been reached - any extraneous Send-N NAPTRs come along for  
the ride
when looking up a URI for communications. Thus for correctly entered  
numbers,
only one ENUM query is made. That's good, IMHO.

Please let's focus on whether or not Send-N solves a problem, whether  
the cure
is worse than the disease,  and whether the particular URI form is  
appropriate.

The rest of this thread is going to make the (Outside) Dublin meeting  
go on
for days, and we have only an hour :(.

all the best,
   Lawrence

On 3 Jul 2008, at 13:47, [email protected] wrote:
> Peter - following up this comment again:
>> Apologies.  NAPTR is becoming the TXT RR for enum; everything can  
>> be put
>> in there so conveniently, especially using "data" type URIs.   
>> That's not
>> what NAPTR was designed for.
>
> I wonder where this concern about NAPTR becoming a dumping ground  
> for data
> has come from?
>
> The whole DDDS architecture is *supposed* to be a generic database  
> lookup
> system, albeit one that has its origins in ENUM.  The only  
> implementation
> of DDDS that I'm aware of is RFC3403, and *that* is what specifies  
> NAPTR
> records, not the ENUM RFCs.
>
> One *could* write a Send-N U-NAPTR Application that sits in its own  
> DNS
> tree that happens to represent the structure of some other DNS  
> tree.  That
> might not be so controversial, but it would *still* be using NAPTR
> records.
>
> As it happens, though, it's actually possible to put the data in the
> *same* DNS tree, albeit there are a couple of special edge cases  
> that have
> to be taken into consideration.
>
> Ray