Subject: [Enum] Section 1.2 & 2 of 3761bis

From: Bernie Hoeneisen <[email-masked]>
Date: Wed, 19 May 2010 10:06:11 +0200 (CEST)

Moved from E2MD:

On Tue, 18 May 2010, Lawrence Conroy wrote (in context of E2MD):

> [Assuming we can roll back some of the more arcane restrictions
> in section 1.2 of rfc3761bis and the bit moved into the second
> paragraph of the intro of section 2].

As Gonzalo already pointed out this part of 3761bis needs revision before
it goes to IESG.

Section 1.2. appears at best "confusing"...or should I rather say 
"broken", as it mixes up private ENUM instances that are based on the 
E.164 dial plan and those private instances that do not use E.164 numbers.

    If these mechanisms are re-used, the suffix used for the private
    dialing plan MUST NOT be e164.arpa, to avoid conflict with this
    specification.  Parties to the private dialing plan will need to know
    the suffix used by their private dialing plan for correct operation
    of these mechanisms.  Further, the application unique string used
    SHOULD be the full number as specified, but without the leading '+',
    and such private use MUST NOT be called "ENUM" because the leading
    "E" in this acronym explicitly stands for "E.164".

Section 2 on the other hand makes it practically impossible to use ENUM 
with non-E.164 numbering plans:

   To mitigate this risk, the "E2U" token MUST NOT
   provisioned in domains associated with non-E.164 numbers.

Furthermore I am not sure if the introcuction section is the right place 
to make mandatory statements. IMHO It should be rather an applicability 
statement section or similar.

Note: I understand you inherited this part from RFC 3761.

cheers,
  Bernie

---

From: Patrik Fältström <[email-masked]>
Date: Wed, 19 May 2010 11:23:39 +0300

On 19 maj 2010, at 11.06, Bernie Hoeneisen <[email-masked]>  
wrote:

> Section 2 on the other hand makes it practically impossible to use  
> ENUM with non-E.164 numbering plans:
>

It all depends on what we mean by ENUM. We do not agree if ENUM stands  
only for the technology (look things up in dns, given some root) or  
only when the root is e164.arpa.

I thought we had this discussion in the enum wg, and concluded that  
enum (without any prefix or suffix) always implies use of e164.arpa.

Other things are called infrastructure enum, enum-like, use of enum  
technology, private enum or such.

Which I think is what the text quoted says.

    Patrik

---

From: Lawrence Conroy <[email-masked]>
Date: Wed, 19 May 2010 11:50:14 +0100

Hi Patrik, folks,
 That's my problem -- there are two elements: the technology (mapping phone numbers to domain names within SOME apex) and the IAB/ITU-T+IANA agreement on e164.arpa.
The technology is usable regardless of whether it's in public or within a private federated net, or using an alternative root, or ...

This is not just a name (ENUM == use of this technology in public within the e164.arpa apex). It's also who or what can use the technology.
This matters for Send-N and Unused, where there may be records elsewhere that in leaf zones associated with E.164 numbers.

The technology is common; the restrictions on E.164 numbers are tied to the IAB agreement. We have a mixture of the two.

all the best,
  Lawrence

On 19 May 2010, at 09:23, Patrik Fältström wrote:

> On 19 maj 2010, at 11.06, Bernie Hoeneisen <[email-masked]> wrote:
> 
>> Section 2 on the other hand makes it practically impossible to use ENUM with non-E.164 numbering plans:
>> 
> It all depends on what we mean by ENUM. We do not agree if ENUM stands only for the technology (look things up in dns, given some root) or only when the root is e164.arpa.
> 
> I thought we had this discussion in the enum wg, and concluded that enum (without any prefix or suffix) always implies use of e164.arpa.
> 
> Other things are called infrastructure enum, enum-like, use of enum technology, private enum or such.
>

---

From: Lawrence Conroy <[email-masked]>
Date: Wed, 19 May 2010 23:57:38 +0100

Hi again Patrik, Bernie, folks,

Patrik? -- help needed.

The issue in section 2 of RFC 3761 (bis) that it doe not have the intended effect as specified.

It is perfectly possible to have E2U NAPTRs in other domains -- an ENUM domain can hold a non-terminal NAPTR that points to any other domain. That domain can hold E2U NAPTRs. Thus:
     $ORIGIN 3.8.0.0.6.9.2.3.6.1.4.4.e164.arpa.
      NAPTR 100 50 "" "" ""    .

     $ORIGIN example.com.
      NAPTR 100 50 "u" "E2U+sip"
          "!^(\\+441632960083)$!sip:\\[email-masked]!"    .
...

This seems valid, BUT it doesn't match the text -- example.com. is certainly NOT associated with an E.164 number, but could hold NAPTRs that were discovered as part of an ENUM query on the E.164 number +44-1632-960083

I would like to re-write this paragraph, as I do not believe that this block on reasonable use was the intention of the last sentence.
i.e. I think it's wrong as written.

I've looked back through the ML archives, and I didn't get the impression that this was was was intended. (I sure don't remember it that way).

I also think this paragraph is broken in other ways; it conflates ENUM domains (i.e. input is an E.164 number, key is within the e164.arpa apex) with E2U NAPTRs, dialling plans with number plans, and diallable numbers with assigned numbers in a number plan, and ...)

Comments?

all the best,
  Lawrence

On 19 May 2010, at 11:50, Lawrence Conroy wrote:

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

---

From: Patrik Fältström <[email-masked]>
Date: Thu, 20 May 2010 06:49:03 +0200

> I also think this paragraph is broken in other ways; it conflates ENUM domains (i.e. input is an E.164 number, key is within the e164.arpa apex) with E2U NAPTRs, dialling plans with number plans, a…

It is an example, and it says it is possible to have E2U NAPTR in other domains, which is true.

Examples are non-normative.

I do not see any problems with the text.

   Patrik

---

From: Bernie Hoeneisen <[email-masked]>
Date: Fri, 21 May 2010 22:36:52 +0200 (CEST)

Hi Lawrence

IMHO whatever makes the text more clear and/or understandable is worth a 
revision (as we have more than enough confusion in the ENUM field...). 
Besides this also Gonzalo found an issue there during his AD review.

I suggest you to send your proposed changes to the ENUM list and give 
others a couple of days for feedback on it.

cheers,
  Bernie

On Wed, 19 May 2010, Lawrence Conroy wrote:

> This seems valid, BUT it doesn't match the text -- example.com. is 
> certainly NOT associated with an E.164 number, but could hold NAPTRs 
> that were discovered as part of an ENUM query on the E.164 number 
> +44-1632-960083
>
> I would like to re-write this paragraph, as I do not believe that this 
> block on reasonable use was the intention of the last sentence. i.e. I 
> think it's wrong as written.
>
> I've looked back through the ML archives, and I didn't get the 
> impression that this was was was intended. (I sure don't remember it 
> that way).
>
> I also think this paragraph is broken in other ways; it conflates ENUM 
> domains (i.e. input is an E.164 number, key is within the e164.arpa 
> apex) with E2U NAPTRs, dialling plans with number plans, and diallable 
> numbers with assigned numbers in a number plan, and ...)
>
> Comments?
>
> all the best,
>  Lawrence
>
>