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

From: "Jean-Francois Mule" <[email-masked]>
Date: Mon, 14 Nov 2005 08:48:08 -0700

Here are a couple of comments on the enum-edns0 draft to follow up on the question I raised at the mike last week. 

--- 1. Update to RFC3761 and MUST requirements
To recap the mike interaction, I asked a question on the level of requirements for the client and server side. Olafur Gudmundsson then stated that EDNS0 must be implemented.

EDNS0 does seem a necessary addition to ENUM clients and servers but before doing so by updating 3761 and adding normative MUST requirements, I would recommend we get more info & experience on its implementation by ENUM clients and DNS server folks.
The question of 'backward compatibility' between ENUM DNS entities that do not support EDNS0 (those implementations compliant with both the obsoleted RFC2976 and 3761) and the ones that do support EDNS0 (this ID or the 3761-update) should also be expanded in the draft.

My original comment was motivated by the following posting on EDNS0 interop testing on dnsext:
http://ops.ietf.org/lists/namedroppers/namedroppers.2005/msg00842.html
I did ping both co-authors and there has been no update on this EDNS0 testing draft. This is where I think we need more implementation feedback.

--- 2. 'backward compatibility' with ENUM DNS entities
Olafur and I did chat after the ENUM wg meeting, especially around the question of backward compatibility. Here is what transpired:
   - consider adding some text in the draft to recommend how long enum DNS clients supporting eDNS0 should cache the server's maximum payload size (see RFC2671, 4.5.4),
   - consider adding some informative text around anycast DNS server clouds (all enum servers belonging to an anycast group should support eDNS0 or none; after playing the scenarios, having a mix of both will likely result in some client confusion).
I copy Olafur so he can add anything I've missed. Hope this helps.

--- 3. Additional notes
I wonder what the impact of supporting EDNS0 is on enum server performance in the case where clients use max payload sizes without any good guidance, especially since servers should not cache the client's maximum payload size (this may be another reason for recommending a reasonable max payload size for clients to support and advertise).

Finally, you should consider adding some simple examples of enum RRsets that cause the DNS response to be truncated.

Jean-François
[email-masked]

> -----Original Message-----
> From: Patrik Fältström [mailto:[email-masked]]
> Sent: Sunday, November 06, 2005 10:50 AM
> To: lconroy
> Cc: IETF ENUM WG; Jim Reid; Peter Koch
> Subject: Re: [Enum] Re: I-D ACTION:draft-conroy-enum-edns0-01.txt
> 
> On 6 nov 2005, at 05.16, lconroy wrote:
> 
> > 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".
> 
> 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
> 
> _______________________________________________
> enum mailing list
> [email-masked]
> https://www1.ietf.org/mailman/listinfo/enum

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