Subject: Re: [Enum] Re: I-D ACTION:draft-conroy-enum-edns0-01.txt

From: Patrik Fältström <[email-masked]>
Date: Sat, 5 Nov 2005 16:23:57 -0800

On 27 okt 2005, at 07.07, Jim Reid wrote:

> Well if it's not done in that way through some sort of standards- 
> track RFC, what other approach would you suggest? IMO without such  
> a document, implementors have nothing to go on. If there's nothing  
> that says "you've got to support EDNS0" (and explains why), there's  
> a good chance EDNS0 support won't make it into ENUM-aware handsets.  
> Making EDNS0 support mandatory should mean it doesn't get dropped  
> from the feature set in the OS for these types of embedded devices.  
> ie Unless someone/something tells those developers to put in EDNS0,  
> they won't.

My view is that EDNS0 is a requirement for *DNS* operation for a  
while, so I think anyone running DNS should support EDNS0, and  
because of that, I would like to see an RFC talking about  
"requirements for running DNS in the year 2005". Then other important  
things can be added as well. Such as an explanation for the "unknown  
RR types", support for DNSSEC etc.

Not specifically for ENUM.

     paf

_______________________________________________
enum mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/enum

---

From: Jim Reid <[email-masked]>
Date: Sun, 6 Nov 2005 10:21:18 +0000

On Nov 6, 2005, at 00:23, Patrik Fältström wrote:

>> that says "you've got to support EDNS0" (and explains why),  
>> there's a good chance EDNS0 support won't make it into ENUM-aware  
>> handsets. Making EDNS0 support mandatory should mean it doesn't  
>> get dropped from the feature set in the OS for these types of  
>> embedded devices. ie Unless someone/something tells those  
>> developers to put in EDNS0, they won't.
>
> "requirements for running DNS in the year 2005". Then other  
> important things can be added as well. Such as an explanation for  
> the "unknown RR types", support for DNSSEC etc.

I agree this is needed. However it can wait IMO. Manufacturers are  
now gearing up to ship ENUM-aware handsets. Unless the IETF produces  
a "use EDNS0" RFC very soon, these devices won't have EDNS0 support.  
It would be better to fix that immediate concern now and then have  
dnsop work on the longer-term problems. The all-singing, all-dancing  
RFC you/we want will take at least a year to produce, probably more.  
Assuming dnsop chooses to accept that work item. That'll be too long  
because the ENUM-in-handsets train will have left the station by then.

The draft is principally an exercise in damage limitation. We all  
agree I hope that EDNS0 for ENUM is a Very Good Thing. So it should  
be non-controversial for the WG to push out an RFC which requires EDNS0.
I'm surprised and a little disappointed at the push-back the draft  
has received. The choice here is stark: let the draft through (warts  
and all) or else deal with the DNS consequences of millions of ENUM- 
aware devices causing billions of truncated responses and TCP  
retries. Which of these options does the WG want to take?
_______________________________________________
enum mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/enum

---

From: lconroy <[email-masked]>
Date: Sun, 6 Nov 2005 13:16:46 +0000

Hi Patrik, Jim, Peter, Folks,
  This is curious - we're wildly agreeing.

Perhaps the draft should have a preface stating
- "You need to understand DNS in order to do ENUM.
   These are some of the important items you MUST
   have in order for this to work well".

AFAICT, ENUM differs from "traditional" uses of DNS
only in the size of the responses it will elicit
being larger than the average.
Thus it would be VERY good if there was a generic
DNSOPS document to spell out to everyone that:
   "there are already tools to deal with this, these
    are what they are, and you MUST use them if you
    don't want to break things"

However, this is a general issue and will/should
take time. For now, we have a specific issue with
a cohort of DNS traffic that is distinctly different
from traditional messages, and for which these items
need to be raised.

I will be VERY happy if this proposed RFC is obsoleted
by a DNSOPS one (as soon as you can), in the same way
that RFC3226 was, in effect, obsoleted by inclusion
in later specifications.

However, for now, please can we do exactly what was
done for DNSSEC/IPV6 and produce an "RFC3226-like"
RFC so that folk know to "do what is needed". It's
not like we have a shortage of RFC numbers and we
need to be careful about giving people too much to
read - they only read the examples, anyway.

Thus, if this is not wrong/broken (and I don't think
it is), please can we progress it now to give DNSOPS
a chance to do their job?

all the best,
   Lawrence

On 6 Nov 2005, at 10:21, Jim Reid wrote:
>>> track RFC, what other approach would you suggest? IMO without  
>>> such a document, implementors have nothing to go on. If there's  
>>> nothing that says "you've got to support EDNS0" (and explains  
>>> why), there's a good chance EDNS0 support won't make it into ENUM- 
>>> aware handsets. Making EDNS0 support mandatory should mean it  
>>> doesn't get dropped from the feature set in the OS for these  
>>> types of embedded devices. ie Unless someone/something tells  
>>> those developers to put in EDNS0, they won't.
>>
> now gearing up to ship ENUM-aware handsets. Unless the IETF  
> produces a "use EDNS0" RFC very soon, these devices won't have  
> EDNS0 support. It would be better to fix that immediate concern now  
> and then have dnsop work on the longer-term problems. The all- 
> singing, all-dancing RFC you/we want will take at least a year to  
> produce, probably more. Assuming dnsop chooses to accept that work  
> item. That'll be too long because the ENUM-in-handsets train will  
> have left the station by then.
>
> has received. The choice here is stark: let the draft through  
> (warts and all) or else deal with the DNS consequences of millions  
> of ENUM-aware devices causing billions of truncated responses and  
> TCP retries. Which of these options does the WG want to take?

---

From: Patrik Fältström <[email-masked]>
Date: Sun, 6 Nov 2005 09:49:22 -0800

On 6 nov 2005, at 02.21, Jim Reid wrote:

> The choice here is stark: let the draft through (warts and all) or  
> else deal with the DNS consequences of millions of ENUM-aware  
> devices causing billions of truncated responses and TCP retries.  
> Which of these options does the WG want to take?

I want the DNS wg's in the IETF make the decision, because I see a  
risk there will be a BCP on how to run DNS and one on how to run DNS  
"and you happen to deal with ENUM queries".

You point at handsets. What about the resolver the handset is using?  
Should we force all DNS operators in the world also read the ENUM DNS- 
operational RFC?

I am only saying "go to the dnsop wg and have a document on how to  
run DNS *NOW*".

     paf

---

From: Patrik Fältström <[email-masked]>
Date: Sun, 6 Nov 2005 09:50:11 -0800

>   have in order for this to work well".

And the effective way of doing this is to point at a "BCP for how to  
run DNS in 2005".

Let me talk with the DNSOP wg chairs asap.

    paf