Subject: Re: [Enum] ENUM Working Group Last call on ENUM Implementation Experiences

From: Peter Koch <[email-masked]>
Date: Tue, 11 Apr 2006 20:20:31 +0200

On Wed, Mar 29, 2006 at 09:37:53AM -0500, Richard Shockey wrote:

> http://www.ietf.org/internet-drafts/draft-ietf-enum-experiences-04.txt
> 
> 
> The intent of the last call is to solicit comments before submitting the
> ID to the IESG as a Proposed Standard.

the document claims to be 'advisory', so I assume the intended status is
"Informational".

Still, I do not feel the draft is ready to go. It has a terminology
issue, uses normative keywords without clear intention, and does not apply
the robustness principle symmetrically.

1) Terminology

   The term 'zone' is used where 'domain', 'owner', or indeed 'zone' might
   be correct, depending on context. This occurs throughout the document,
   but it's not a simple search&replace exercise.

2) 'Normative' Keywords

   The abstract says the document is advisory and is reporting potential
   pitfalls. Section one again says the document is advisory and does
   not make the capitalized words 'normative', but gives little advice
   how to read them. In the security considerations section the
   observations and recommendations are named 'clarifications'.

3) Asymmetric application of the robustness principle

   Section 2 references the robustness principle; the 'recommendations'
   put most of the burden on the server side while at the same time
   allowing the client to 'bend' the rules, e.g.:

   3.3: Servers "SHOULD" use '!' ... Clients "MAY" discard NAPTRs that
        do not use '!'

   The appropriate advice to the client would be to learn that there are
   other possible RegExp delimiters.

There are also some nits (e.g. there's no truncated error response (6.2))
and some changes needed to the - mostly new - text in chapter 6.
My personal feeling is that the EDNS0 discussion is too lengthy, as is that
of inhomogeneous TTLs in an RRSet. More to the point, the 'recommendation'
"All servers involved in ENUM resolution MUST support EDNS0" is not
justified. While I'd agree that every name server should support EDNS0 plus
a reasonable packet size, a MUST is appropriate only for those serving
(XXL) NAPTR RRSets.
The discussion of ANY queries in 6.5 should go into a separate section
since it has little to do with TTLs. The motion is fine, though.

Now if you've read this far you might think i dislike the draft. I do not.
There are many valuable observations and food for future work
(i.e. clarifications) in here that will help operators and implementors.

I've left out some details here to meet the deadline. Those are still on my
paper copy and i'll post or send them separately. And of course i'm happy
to be pointed to earlier discussions i might have missed.

-Peter

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

---

From: Jim Reid <[email-masked]>
Date: Tue, 11 Apr 2006 20:40:52 +0100

On Apr 11, 2006, at 19:20, Peter Koch wrote:

> More to the point, the 'recommendation'

Peter, you're completely wrong about this. Sorry.

A MUST for EDNS) is appropriate -- I'd say it's absolutely critical  
-- for anything involved in ENUM lookups.

First off, even a modest NAPTR RRset will comfortably exceed a 512  
byte payload. My ENUM zone (3.2.5.2.5.8.8.9.6.1.4.4.e164.arpa)  
contains 6 NAPTR RRs. Which is on the low side for reasonable usage.  
[Somehere around 10 NAPTRs seems likely to be the typical size of a  
real-world RRset.] My zone's RRset doesn't even include several  
mainstream URIs (like sms, mms, http or mailto) or funky ordering  
stuff for cute call routing: divert to voicemail, don't call my GSM,  
etc, etc. This lookup gets a 507 byte response. And that's with  
dropping potentially useful data from the Additional Section as well  
as optimal label compression. With EDNS0, the Additional Section  
isn't "truncated" and the full response is 602 bytes.

Secondly, you have confused serving NAPTR RRsets with *resolving*  
them. Serving ENUM zones is just one part of the picture: and  
probably not the one that has the biggest operational impact. The  
draft says "All servers involved in ENUM resolution". The client  
doing the lookup or the server resolving that ENUM lookup does not  
have a priori knowledge of the size of the target zone's NAPTR RRset.  
It does not know if that zone has a small, "average" or XXL sized  
RRset. So the client and resolving server should plan for the worst.  
Or at least the typical ENUM response.

Mandating EDNS0 with good buffer sizes is not only essential and  
prudent, it's just an application of the "be liberal in what you  
receive" principle.

Even at 6 NAPTRs -- which is by no means XXL sized -- using EDNS0 is  
a Big Big Win. It saves truncation and TCP retries. Or more lookups  
to get the data that could/should have been in the Additional  
Section. That extra latency is bad news, especially on things like  
GPRS networks.

We will have to sort this out over a few beers at RIPE52. :-)

---

From: Peter Koch <[email-masked]>
Date: Wed, 12 Apr 2006 15:17:35 +0200

Jim,

> contains 6 NAPTR RRs. Which is on the low side for reasonable usage.  

just as a data point, not to argue about the 'reasonable' size: under +49
the average number of NAPTRs in an RRSet is a little above 2, with very few
going beyond 5 and the largest having 14 NAPTR RRs.

> as optimal label compression. With EDNS0, the Additional Section  

Compression is mandatory and there's not much useful in the additional
section in this case, given today's anti-poisoning measures.

> isn't "truncated" and the full response is 602 bytes.

No doubt there's a gain (for size, no real one here) with EDNS0 and we are
in violent agreement that EDNS0 is just 'state of the art' (more precisely:
EDNS0 _and_ reasonable buffer size).

> have a priori knowledge of the size of the target zone's NAPTR RRset.  

There are servers 'involved in ENUM resolution' that don't even serve NAPTR
RRSets and depending on your setup you might be able to know how large NAPTR
responses will grow. Again agreed, i do not think aiming at 512 is reasonable
in the latter case.

> prudent, it's just an application of the "be liberal in what you  

Supporting EDNS0 is just good practice, but the arguments did not support
the claim. Anyway, how can i argue against a non-normative 'MUST'?

> Even at 6 NAPTRs -- which is by no means XXL sized -- using EDNS0 is  

Sorry for being lazy w.r.t. "XXL" -- i meant that to indicate an RRSet
bringing the response > 512 octets.

> Section. That extra latency is bad news, especially on things like  

Cool, tell that the low TTL advocates. The additional section doesn't
solve the problem, though.

> We will have to sort this out over a few beers at RIPE52. :-)

That sounds intersting enough to postpone further detailed discussion :-)

-Peter

---

From: Richard Shockey <[email-masked]>
Date: Mon, 17 Apr 2006 13:31:50 -0400

> On Tue, Apr 11, 2006 at 08:40:52PM +0100, Jim Reid wrote:

The document is in last call ..its still not clear to me what changes, if any 
you are suggesting.

-- 

Richard Shockey, Director - Member of Technical Staff
NeuStar Inc.
46000 Center Oak Plaza  -   Sterling, VA  20166
sip:rshockey(at)iptel.org   sip:57141(at)fwd.pulver.com
PSTN Office +1 571.434.5651 PSTN Mobile +1 703.593.2683
<mailto:richard(at)shockey.us> or
<mailto:richard.shockey(at)neustar.biz>
<http://www.neustar.biz> ; <http://www.enum.org>
<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<

---

From: Richard Shockey <[email-masked]>
Date: Wed, 26 Apr 2006 11:09:52 -0400

> On Tue, Apr 11, 2006 at 08:40:52PM +0100, Jim Reid wrote:

Gentlemen I'm not getting s sense of resolution here. The Experiences 04 draft 
has gone through last call and if there are revisions required to satisfy 
consensus we need to resolve those issues ASAP.

Peter what do you want the authors to do?

The chairs would like to get this draft into the hands of the IESG as soon as 
possible.

--