Subject: [Enum] draft-ietf-enum-e164-dns-02.txt: IANA Considerations

From: Hong Liu <[email-masked]>
Date: Sun, 23 Jul 2000 22:21:42 -0400

Patrik,

I noticed a completely new section in draft-enum-e164-dns-02.txt as
compared to draft-enum-e164-dns-00.txt:

"4. IANA considerations

   IANA is to create the E164.ARPA domain in the ARPA zone, and
   delegate names in the zone to parties according to the ITU
   recommendation E.164. The names allocated should be hierarchically
   allocated according to the description in this document, and the
   codes assigned in the E.164 recommendation by ITU.

   Delegations should be done after Expert Review, and the IESG will
   appoint a designated expert. "

Since this is a new section (and a non-trivial one), I would like to
start some discussions on the list before the IESG last call period
expires. Would you please clarify the intent of this section? I
personally have some concerns, but I would like to understand your
points first.

Thanks in advance for the clarifications,

--Hong

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

---

From: Patrik Fältström <[email-masked]>
Date: Sun, 23 Jul 2000 19:43:34 -0700

>personally have some concerns, but I would like to understand your

That IANA is to register that domain in the ARPA zone. It is up to 
IANA to come up with exactly how that is done. My personal guess is 
that IANA will delegate e164.arpa to ITU and let ITU take care of the 
subdelegation. IANA is though not part of the IETF and we can not 
tell IANA to do something more specific than this.

The actual wording in the I-D is verified with various parties, and 
especially IAB which is the party which instructed this wg to use 
this specific domain.

So, there is MUCH more thinking behind the text already than just 
words from my head. I am happy to answer more questions about it, but 
I would not think it will change much, due to the consensus which 
exists in IAB etc about the text. ITU is also informed, as is DoC and 
ICANN, and everyone belive this is the path that should be taken.

I can explain more in Pittsburgh.

    paf

---

From: Dave Crocker <[email-masked]>
Date: Wed, 26 Jul 2000 15:53:44 -0700

Thought it might be worth adding a bit of technically mundane trivia, into 
all this high falutin' policy debate:

The algorithm in section 2 of the document would be better -- less work for 
the programmer, but with the same semantics -- if dots were added AFTER the 
string number reversal.

Hence I suggest swapping steps 4 and 5.

The Current step 5 should probably also say "Reverse the order" rather than 
"Change the order" in order (pun?) to be precise.

We now return you to your regularly scheduled Argument Of Great Significance...

d/

---

From: "Nicholas Sauriol" <[email-masked]>
Date: Thu, 27 Jul 2000 07:52:40 -0400

I have to agree with Dave on this one. Altough I'm sure most programmers
would make the change anyways, it seems logical to have it written in the
way it will be used.

My apologies for the following question, I joined the group rather
late, but why remove extra characters and than the '+' in 2 steps, as opposed
to simply removing all non-numerical characters?

Dave Crocker wrote:

Thought it might be worth adding a bit of technically
mundane trivia, into

The algorithm in section 2 of the document would be better -- less work
for

the programmer, but with the same semantics -- if dots were added AFTER
the

string number reversal.

The Current step 5 should probably also say "Reverse the order" rather
than

d/

enum mailing list

[email-masked]

--

Nicholas
Sauriol

1.613.763.1978

Succession
Solutions

www.nortelnetworks.com

Nortel Networks
Confidential

---

From: Patrik Fältström <[email-masked]>
Date: Thu, 27 Jul 2000 04:57:31 -0700

At 07.52 -0400 00-07-27, Nicholas Sauriol wrote:
>late, but why remove extra characters and than the '+' in 2 steps, 
>as opposed to simply removing all non-numerical characters?

Because I wanted to keep the '+' for the algorithm in the NAPTR. One 
might in some other (similar) solutions have other characters in the 
phone number which the regular expression works on.

   paf