Subject: RE: [Enum] partial numbers proposed text changes

From: "Peterson, Jon" <[email-masked]>
Date: Wed, 19 Mar 2003 16:47:34 -0500

While I agree that this normative statement is very much in the spirit of
ENUM as defined in 1.2, there was enough confusion about this (simple)
matter that I think this last sentence is very much worth keeping. It is not
directly entailed by 1.2, and I think future readers of RFC2916bis might be
confused about whether or not this is possible.

Jon Peterson
NeuStar, Inc.

> -----Original Message-----
> From: Stastny Richard [mailto:[email-masked]]
> Sent: Wednesday, March 19, 2003 1:19 PM
> To: Michael Mealling; [email-masked]
> Subject: AW: [Enum] partial numbers proposed text changes
> 
> 
> I propose the last sentence of the text to be deleted, 
> because this is not possible anyway:
>  
> "Because of this risk for
> collissions, the flag E2U in the service field MUST NOT be used for
> non-E.164 numbers."
> 
> Reason: 
> 
> According to the delegation policy within e164.arpa only 
> domains mapping to valid E164 numbers may be created within 
> the e164.arpa tree anyway. It is therefore not possible to 
> create a domain with non-E164 within e164.arpa in the first 
> place. Therefore there is no way to enter a NAPTR with E2U in 
> such a non existing domain.
> 
> regards
> 
> Richard
> 
> 
> 	-----Ursprüngliche Nachricht----- 
> 	Von: Michael Mealling [mailto:[email-masked]] 
> 	Gesendet: So 16.02.2003 19:51 
> 	An: [email-masked] 
> 	Cc: 
> 	Betreff: [Enum] partial numbers proposed text changes
> 	
> 	
> 
> 	The two issues that were discussed in the meeting were 
> DNSSEC wording
> 	and partial E.164 numbers. I'm addressing them 
> seperately for thread
> 	management. This message concerns the partial numbers 
> issue only. The
> 	proposed changes are to delete Section 2.6 entirely. 
> The following text
> 	is added as a second paragraph to the beginning of Section 2:
> 	
> 	--
> 	ENUM is only applicable for E.164 numbers. ENUM 
> compliant applications
> 	MUST only query DNS for what it believes is an E.164 
> number. This
> 	implies applications MAY send DNS queries when, for 
> example, a user
> 	mistypes a number in a user interface. Because of this risk for
> 	collissions, the flag E2U in the service field MUST NOT 
> be used for
> 	non-E.164 numbers.
> 	--
> 	
> 	There was a good deal of concensus over this text. 
> There was some
> 	attempt to explain further the meaning of the word 
> 'believes' and how
> 	that interacted with the actual E.164 standard. The 
> gist was that the
> 	application should make an effort to ensure that the 
> number is valid
> 	according to the E.164 specification. Since it is 
> impossible for an
> 	application to have perfect knowledge of all numbering 
> plans, the word
> 	'believe' means that the application has done its best effort to
> 	sanitize the numbers it queries for. The document 
> authors are looking
> 	for text from those that correctly expresses this 
> concept in a way that
> 	preserves the overall concept expressed in the above text.
> 	
> 	_______________________________________________
> 	enum mailing list
> 	[email-masked]
> 	https://www1.ietf.org/mailman/listinfo/enum
> 	
> 
> _______________________________________________
> 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: "Conroy, Lawrence (SMTP)" <[email-masked]>
Date: Sun, 23 Mar 2003 10:34:36 +0000

>confused about whether or not this is possible.

<snip>
>  > such a non existing domain.

To which I add:

Hi Jetsetters, folks,
Whilst I understand Jon's concerns, Richard does make a good point.

Given the agreements for e164.arpa., no end user will be allowed to
register a domain associated with an incomplete number. It won't happen.
Thus, putting in this comment may confuse, in that some folk might
think that such a Registration *is* possible, given the proposed
prohibition.

My point at the meeting was that regulatory authorities or their agents
might envisage using a NAPTR in an intermediate node, **** if such a
node exists as a separate entity****.

Any prohibition would be based on our current assumptions on how ENUM
will be used, and that any domain within e164.arpa. would be under
the control of a potential "end user" Registrant rather than being
within the control of a National Numbering Authority or its agents.

From the proposals for ENUM Administration I've seen, there IS no
intermediate node, with a T1 pointing to (T2) servers authoritative
for domains that are associated ONLY with "fully qualified" (i.e.
E.164) numbers.

However, IF an administration wants to insert domains that would
logically be associated with "incomplete" (i.e. NOT E.164) numbers,
then (i) it's a national admin issue and so their choice - we can't
stop them, and (ii) these would not be under the control of an ENUM
"End User//Registrant". We might as well put prohibitions on what
can go into the "co.uk." domain - this will certainly NOT be a domain
that will be free for folk to Register either.

We may need some document(s) advising what is sensible (or not) for
a National Administration to do, and what the technical implications
are by their actions, but 2916 is NOT that document, IMHO.

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: 25 Mar 2003 14:36:59 -0500

> think that such a Registration *is* possible, given the proposed

The agreements for e164.arpa may be ignored at lower tiers within the
infrastructure either knowingly or unknowingly. Saying people will think
you can do something when the document specifically says you can't
suggests we shouldn't write a specification at all....

> node exists as a separate entity****.

It does exist. By virtue of the fact that you insert '.' in between each
node, it does exist with respect to DNS. And if it exists people can and
will insert records into those domains. What we're trying to do is
maintain someway for a client to be able to tell the difference.

> for domains that are associated ONLY with "fully qualified" (i.e.

But as others have said before, we have to write these documents so that
they're at least somewhat prescient. If we can see where some may assume
that something can be done and we realize it can be a problem, it is our
responsibility to make sure it doesn't happen. 

> that will be free for folk to Register either.

Correct. What we are trying to define is what a client can expect. If we
can't say that E2U NAPTR records are verbotten for intermediate nodes
then a client has no way of knowing when it makes a mistake.

> are by their actions, but 2916 is NOT that document, IMHO.

The extreme minimalist approach you're suggesting is very dangerous. I
tried that with the original DDDS specs and was a disaster. Over the
years we've learned one truism: implementors will be willing to read one
document, maybe two, thus, you really need to put the most important
client side caveats into the main document or they'll be hopelessly
screwed up. IMHO, this is a very important one to get right.

I think the statement as suggested is fine, excpet for some possible
explanation of what the word 'believes' means....

-MM

---

From: Dave Crocker <[email-masked]>
Date: Wed, 26 Mar 2003 08:38:21 -0800

Folks,

Tuesday, March 25, 2003, 11:36:59 AM, you wrote:

MM> But as others have said before, we have to write these documents so that
MM> they're at least somewhat prescient. If we can see where some may assume
MM> that something can be done and we realize it can be a problem, it is our
MM> responsibility to make sure it doesn't happen. 

My understanding, at the meeting, was that partial numbers were entirely
outside the scope of this working group.

if you want to anticipate that someone might do partial numbers, then
just add a sentence that says that they are outside the scope of the
specification.

"outside" means outside.  as in, nothing to do with.

have have thereby acknowledged the possible future action, but done so
in a way that leaves no one confused.

d/
--
 Dave Crocker <mailto:[email-masked]>
 Brandenburg InternetWorking <http://www.brandenburg.com>
 Sunnyvale, CA  USA <tel:+1.408.246.8253>, <fax:+1.866.358.5301>

---

From: Michael Mealling <[email-masked]>
Date: 26 Mar 2003 11:57:37 -0500

> in a way that leaves no one confused.

With the exception that you have now created a case where a client
cannot know when it is 'in scope' and thus within its rights to expect
compliant behavior and when it is 'out of scope'. I'm not attempting to
make any statements about 'partial numbers' themselves other than to
define them so they can be declared out of scope syntactically. Right
now there is no way to tell what the 'scope' actually is from a client
implementation...

-MM

---

From: Dave Crocker <[email-masked]>
Date: Wed, 26 Mar 2003 00:54:11 -0800

Folks,

d/

---

From: Dave Crocker <[email-masked]>
Date: Wed, 26 Mar 2003 16:04:33 -0800

Michael,

Wednesday, March 26, 2003, 8:57:37 AM, you wrote:
MM> With the exception that you have now created a case where a client
MM> cannot know when it is 'in scope' and thus within its rights to expect
MM> compliant behavior and when it is 'out of scope'. I'm not attempting to
MM> make any statements about 'partial numbers' themselves other than to
MM> define them so they can be declared out of scope syntactically. Right
MM> now there is no way to tell what the 'scope' actually is from a client
MM> implementation...

not sure how to process your note.

scope is about specifications, not implementations.  client software
does not determine whether something is in scope.  the DEVELOPER of
client software has to know.

so, my suggestion reduces to simply having the specification state:

  some of you out there might be wondering about the use of partial
  numbers.  now that we have mentioned that fact, you know that we know
  about it.  however, partial numbers are outside the scope of this
  specification.  therefore this specification does not discuss them.
  it does not prohibit them.  it does not enable them.  it has nothing
  to do with them.

  in other words, if you are interested in doing partial numbers, look
  for some other specification to read, because you won't find anything
  about them, here.

(and if the above started sounding like a Monty Python routine, i must
say that it was not intentional.)

d/