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

From: "Stastny Richard" <[email-masked]>
Date: Wed, 19 Mar 2003 22:18:54 +0100

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

---

From: Michael Mealling <[email-masked]>
Date: 25 Mar 2003 14:46:30 -0500

> collissions, the flag E2U in the service field MUST NOT be used for

It is very possible...

> 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…

The fact that you insert '.' in between each number by the definition of
how the DNS works, you have created an intermediate node at each and
every point. 6.5.6.9.1.8.5.8.7.6.1.e164.arpa has 10 levels of
intermediate DNS nodes. They're not valid according to ENUM but they are
valid DNS labels and as such there is a non-zero chance that a client,
not knowing anything about the US numbering plan, would query
for a NAPTR record for some portion of that hierarchy. 

You may come to the conclusion that such a thing might be illegal but
that's because you've been thinking about this for a while and you
approach if from the standpoint of "that which is not explicitly allowed
is illegal". Typical Internet developers use the "conservative in what
you send, liberal in what you receive" method. That means many will read
it just the opposite: "that which is not explicitly disallowed will be
found 'in the wild' and thus is mandatory". If it is illegal then what's
the harm of saying it explicitly?

-MM

---

From: "Conroy, Lawrence (SMTP)" <[email-masked]>
Date: Tue, 25 Mar 2003 23:09:57 +0000

Hi Michael, Richard St, Folks,
   First, glad to hear that the Portable came back to life, Michael.
Hmm....
What I meant (and I suspect Richard means, although he may just have
heatstroke from Copacabana :), was that if the T1 holds NS entries
only for the domains associated with "full" E.164 numbers, then there
won't be any domains pointed to that are not associated with a "full"
E.164 number.

This seems to be the plan I've seen in the existing Admin documents.
The only time there could be an issue is if the T1 had an NS record
for a domain logically associated with an "incomplete" number, and
the zone file for that domain included E2U NAPTRs. (see end **).

An "end user" Registrant will not be allowed to register such a domain,
so it's all the fault of the evil Administration that has handed out
this domain to one of their agents who has put a NAPTR into it.

I can guess that the collective ITU/ETSI/<choose your evil empire here>
comment is going to be "none of your business", because it's a domain
that they have allocated for their own use, not an "end user" Registrant.

So...by doing this we are telling ITU/<blah blah> what they cannot put
into "their" domains. Interesting...

I reiterate that we can and should ADVISE Administrations what they
SHOULD and SHOULD NOT put into their domains, but that's another doc.

I'm all for being liberal with what we accept, and don't like this
prohibition. Thus, can we reduce this from its current MUST NOT?

The only folk who will be in the position to install a E2U NAPTR
into domains associated with these apparently "incomplete" E.164
numbers are Administrations or their agents, where the benighted
Administration has chosen to have NS'd out these "intermediate"
domains, so it isn't a problem for us mere mortal Registrants.

** BTW, Richard St, did the esteemed French delegation propose such
a split out for +33 at some point? I couldn't quite understand their
proposal, and am unaware of any other proposal to have such a separate
NS at the "number block" level rather than the full/leaf number level.

all the best,
   Lawrence

In response to this that, at 2:46 pm -0500 25/3/03, Michael Mealling wrote:
>>  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.
>>
>

-- 
-----------------------------------------------------------------------
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