Re: Section 1.2 & 2 of 3761bis

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:

> 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 protected]!"    .
> ...
>
> 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:
>
>> 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 protected]> wrote:
>>>
>>>> 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.
>>>
>>> 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
>>>
>>
>> _______________________________________________
>> enum mailing list
>> [email protected]
>> https://www.ietf.org/mailman/listinfo/enum
>
>

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