Subject: AW: [Enum] I-D ACTION:draft-ietf-enum-rfc2916bis-04.txt

From: "Stastny Richard" <[email-masked]>
Date: Wed, 5 Mar 2003 05:17:57 +0100

Hi Rich and MM,
 
was it really necessary to introduce so much new text in 04? I hoped to have
rfc2916bis from the table soon, but with all this new text in section 1.3, 2.4, 2.5, 2.6
and wherever else I have a problem. I need to discuss and understand the impact of all these issues
so IMHO it is not yet possible to have a last call now.
 
So I also agree to hold off last call until SFO.
 
best regards
Richard Stastny

	-----Ursprüngliche Nachricht----- 
	Von: Richard Shockey [mailto:[email-masked]] 
	Gesendet: Di 04.03.2003 16:00 
	An: Michael Mealling; [email-masked] 
	Cc: 
	Betreff: Re: [Enum] I-D ACTION:draft-ietf-enum-rfc2916bis-04.txt

	At 09:45 AM 3/4/2003 -0500, Michael Mealling wrote:
	>Just before I sent this out there were some additional comments
	>concerning the DNSSEC issue. I decided not to put my proposed text in
	>there since I think the issue probably needs some (hopefully short)
	>discussion in the meeting. As far as I can tell once that text is
	>changed the document should be done (although I would like some more
	>examples)...
	
	OK .. thats fine with me ...we'll hold off any last call until after
	SF  I'm assuming now that we need an 05.

	
	Richard Shockey, Senior Manager, Strategic Technology Initiatives
	NeuStar Inc.
	46000 Center Oak Plaza  -   Sterling, VA  20166
	Voice +1 571.434.5651 Cell : +1 314.503.0640,  Fax: +1 815.333.1237
	<mailto:[email-masked]> or <mailto:[email-masked]>
	  <http://www.neustar.biz> ; <http://www.enum.org>
	<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<
	
	_______________________________________________
	enum mailing list
	[email-masked]
	https://www1.ietf.org/mailman/listinfo/enum

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

---

From: Michael Mealling <[email-masked]>
Date: 05 Mar 2003 09:50:00 -0500

On Tue, 2003-03-04 at 23:17, Stastny Richard wrote:
> was it really necessary to introduce so much new text in 04? 

It was based on issues people brought up on the list so as the document
author I'm duty bound to reflect list consensus in the document.Plus
some sections (like 1.3) were simply incorrect but needed more text to
explain what the real issue was.

None of the changes are substantive. Nothing technical has changed with
how ENUM works at all. Just explanatory text.

> I hoped to have

Feel free to bug me directly if you have questions about the new text...

-MM

---

From: "Conroy, Lawrence (SMTP)" <[email-masked]>
Date: Wed, 5 Mar 2003 15:34:30 +0000

At 9:50 am -0500 5/3/03, Michael Mealling wrote:
<snip>
>Plus some sections (like 1.3) were simply incorrect but needed more text to

Hi Michael, Folks,
   I'm intrigued  - what about section 1.3 of rfc2916bis-03.txt was
wrong and has been corrected by this version?

all the best,
   Lawrence

---

From: Michael Mealling <[email-masked]>
Date: 05 Mar 2003 10:42:37 -0500

> wrong and has been corrected by this version?

It was the interaction between the Order and Preference fields. The old
1.3 simply said 'order' need not be preserved when it really meant
Preference. The intent of the old 1.3 was to allow a client to pick the
most appropriate record for their application. Which is what the
Preference field is for. The Order field has to be adhered to since DNS
records can be in any order. The key point in 1.3 is this:

   The Order field in the NAPTR is a
   request from the holder of the E.164 number that the records be
   handled in a specifc way.  The Preference field is merely a
   suggestion from that E.164 holder that one record might be better
   than another.  A client implementing ENUM MUST adhere to the Order
   field but can simply take the Preference value "on advisement" as
   part of a client context specific selection method.

Which means that in many cases, most ENUM zone entries will all have the
same Order but with different Preferences. But in the cases where there
is a difference then the client still has to take Order into account
first.

-MM

---

From: "Conroy, Lawrence (SMTP)" <[email-masked]>
Date: Wed, 5 Mar 2003 16:00:26 +0000

>is a difference then the client still has to take Order into account

Hi Michael, folks,
   Well...
That's not all that the new improved 1.3 says, or it would be two sentences
or three sentences long:
"The ORDER field value in a set of NAPTRs MUST be used to select the order
in which these NAPTRs are processed. The PREFERENCE field acts as a 
recommendation
and so may be over-ridden based on local policies that are not the subject of
standardisation; thus the PREFERENCE field MAY be used to select between NAPTRs
holding the same ORDER field value".

For reference, the 1.3 from 2916bis-03 doesn't mention the ORDER field at all:
"
    The preference field in the NAPTR is a request from the holder of the
    E.164 in what order the records are to be used.  It is to be noted
    that the party looking up the records MAY apply a local policy for in
    what order the records are to be used based on a combination of the
    service fields and URI schemes.  This overrides the MUST requirement
    in the DDDS algorithm.
"

I wonder if we're adding in text on "End System" policy; wouldn't this
be better in a subsequent BCP rather than a Protocol Standard document?

all the best,
   Lawrence
-- 
-----------------------------------------------------------------------
Roke Manor Research    : This information is provided "as is" and is not
<mailto:[email-masked]>: intended to create any contractual or legal
<tel:+441794833666>    : relationship.
_______________________________________________
enum mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/enum

---

From: Michael Mealling <[email-masked]>
Date: 05 Mar 2003 11:22:03 -0500

> That's not all that the new improved 1.3 says, or it would be two sentences

One thing I've learned is that if you don't explain why you make such a
statement everyone believes its just your personal opinion. All of the
rest of the text explains why Order and Preference are the way they are.

> recommendation and so may be over-ridden based on local policies that are not the subject of

Sure. That's the conclusion. But without understanding why the DDDS has
them you really wouldn't be able to understand why that requirement is
what it is. And when some people read these things they assume that
since they don't see any harm that there isn't any.

>     service fields and URI schemes.  This overrides the MUST requirement

Actually it does. It uses the term 'order' as the 4th word in the 2nd
line. After talking to those that wrote 1.3 it became obvious that what
1.3 said and what it was intended to mean were two different things.
Plus it just wasn't clear at all which MUST was being overridden.

> be better in a subsequent BCP rather than a Protocol Standard document?

NO. This stuff is extremely important to how the DDDS algorithm works
and is based on many other applications that ENUM is extremely similar
to. At this point many here have extremely simplistic views of what
their ENUM applications will be like. But I can guarantee you that they
won't remain that simplistic for very long. If this core algorithm stuff
isn't right then the future pain will be horrible.

-MM