Subject: [Enum] draft-ietf-enum-combined-01

From: [email-masked]
Date: Sun, 29 Oct 2006 15:37:38 -0500

I was wondering about the example in section 7 of
draft-ietf-enum-combined-01 -- the E.164 number is +44..., but the EBL
record shown has domain name "infrastructure.3.4.e164.arpa", which
would be for country code +43.

Also, it occurs to me that the infrastructure ENUM records could be
grouped under, say, "(country code).infrastructure.e164.arpa".  That
would require an additional DNS delegation for each country code with
infrastructure ENUM, but the delegation would be authenticated the
same way that user ENUM subtrees are currently delegated.  Presumably
there is a reason that this scheme is inferior to what is presented in
the I-D, but I don't see any discussion of alternatives in the I-D.

Dale

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

---

From: lconroy <[email-masked]>
Date: Sun, 29 Oct 2006 21:54:38 +0000

Hi Dale, folks,
Re. the examples - Yup - the EBL needs to be changed from +43 to +44

This is a reflection of a current issue with example telephone numbers:
Ofcom has defined ranges of "telephone numbers for drama use"  
reserved in
the U.K., so these tend to turn up in I-Ds/RFCs.

Not all Countries have had the forethought to institute such ranges, so
the Ofcom ones tend to turn up in I-Ds/RFCs as they will not be in  
service.
[Whether International call attempts to these numbers work quite as  
expected
  is left as an exercise for the terminally bored - however, no-one  
will answer]

(apologies in advance for lax description below - I hope you all get  
the point)
----
AFAICT, there is an IAB agreement for e164.arpa. with the ITU
The ITU has defined (interim) procedures in place to delegate
/assign control of <CC>.e164.arpa. to the appropriate member
(i.e. the Country associated with the <cc>).

Defining the procedures for <cc>.<chooseAnAgreedLabelHere>.e164.arpa.  
will
undoubtedly involve ITU study group 2, many trips to Geneva, and a  
great deal
of time. Isn't dealing with the FCC hard enough?

That's why the process of doing just that IS referenced in the I-D  
(as the
"long term solution" [9]). Don't expect it to happen overnight, though.

----
all the best,
   Lawrence

---

From: [email-masked]
Date: Sun, 29 Oct 2006 17:30:52 -0500

From: lconroy <[email-masked]>

   Defining the procedures for
   <cc>.<chooseAnAgreedLabelHere>.e164.arpa.  will undoubtedly involve
   ITU study group 2, many trips to Geneva, and a great deal of
   time. Isn't dealing with the FCC hard enough?

You're saying that doing such a delegation would require a further
agreement with the ITU?

   That's why the process of doing just that IS referenced in the I-D
   (as the "long term solution" [9]).

Perhaps the significance of "long term solution" could be spelled out
in a bit more detail?

Dale

---

From: Jim Reid <[email-masked]>
Date: Sun, 29 Oct 2006 23:27:47 +0000

> You're saying that doing such a delegation would require a further

Yes, he surely is. Please look at the IANA Considerations Section of  
RFC3761. Then review the liaison statements and other documents  
between ITU-T, IAB and RIPE NCC.

---

From: "Stastny Richard" <[email-masked]>
Date: Mon, 30 Oct 2006 10:09:27 +0100

Hi Dale,

thanx for detecting the typo, of course the entry should be
infrastructure.4.4.e164.arpa

> Perhaps the significance of "long term solution" could be spelled out

IMO the significance is spelled out enough in the last two paragraphs
of the Introduction and the reason for introducing the interim solution
in section 3.

Regards
Richard

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]]
> Sent: Sunday, October 29, 2006 11:31 PM
> To: [email-masked]
> Subject: Re: [Enum] draft-ietf-enum-combined-01
>