Re: Send-n, rat holes and real issues

Peter

> > 2.  The views of some people that overlapped dialling should not be 
used 
> > cannot be tackled by this draft.  It exists, it is used and that is 
that. 
> 
> Well, yes, but the question remains whether this issue is to be solved 
within
> I-ENUM or before I-ENUM-Queries are generated or whether this is an 
issue
> at all.

You cannot legislate overlap dialling away by protocol design.  People 
have already said they will use it and the implications of that are clear. 
 If you want to say "I would rather we lived with the extra lookups than 
agree to send-n" then that is fine - it is basically an answer to d) 
below. 

BTW this is all ENUM not just I-ENUM.

> > 3.  According to all the DNS experts the treatment of wildcards is not 
an 
> > issue.
> 
> I'd rephrase that to say that I'd see no protocol issues (... "breaks" 
...),
> but there might remain operational challenges.  However, this is closely
> related to (c) below.

Fine by me.

> > a. Whether or not we need a more general mechanism to describe the 
shape 
> > of the tree rather than the something just for ENUM?  Also expressed 
as 
> > whether there should be meta-data in the tree about the tree (and 
whether 
> > NAPTR is a good way to do that)?
> 
> Likely out of scope for this WG.

I agree entirely it would be if that is the way the answer went.  But we 
first need to agree whether to go this way or something more specific like 
send-n or whether to do nothing.

> > d. Is the trade off between extra records vs reduced lookups worth it?
> 
> Where this includes the question what that trade-off actually is.  Also,
> this isn't just about "extra records", it is also about cluttering the 
tree.

I meant that as well in the phrase "extra records".  There are lots of 
reasons people might not want the extra records.

Jay