[Enum] comments on draft-ietf-enum-3761bis-00

Hi Patrik!

It would be great if the draft would be correct formated - that would 
ease reading a lot.

Now to the draft:

> 1.2. Use for these mechanisms for private dialing plans
> 
> This document describes the operation of these mechanisms in the 
> context of numbers allocated according to the ITU-T recommendation 
> E.164. The same mechanisms might be used for private dialing plans. 
> 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 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".

To me it is not clear what this section addresses. Does it address 
"private ENUM" too? Private ENUM is usually used to have the official 
dialing plans in private scenarios. Thus removing the '+' is IMO not good.

Further, I'm not sure if an RFC should dictate usage of ENUM in private 
scenarios. A private scenario is private - it could use the RFC 
suggestions or not.

>2. The ENUM Application Specifications
> 
...
> the risk that collisions between E.164 numbers and non-E.164 numbers
> can occur. To mitigate this risk, the E2U portion of the service
> field MUST NOT be used for non-E.164 numbers.

I do not understand what this means. If an application incorrectly 
translates a dial string into an E.164 number, there is no difference 
than if the user would have typed a wrong number.

Further, this draft is about ENUM - E.164 to ....
Thus, I always thought per definition there can not be non E.164 numbers 
in e164.arpa.

> 4.1.  Example

Really nice formated :-|

> $ORIGIN  3.8.0.0.6.9.2.3.6.1.4.4.e164.arpa.
> 
>        NAPTR 10 100 (
>          "u"

            ^^^^
          I guess you mean "d" ?

>          "E2U+sip"
>          ""
>          3.8.0.0.6.9.2.3.6.1.4.4.e164.arpa. )
> 
>        NAPTR 10 101 (
>          "u"
            ^^^^
          I guess you mean "d" ?

>          "E2U+h323"
>          ""
>          3.8.0.0.6.9.2.3.6.1.4.4.e164.arpa.

                                            ^^^^
                           missing closing parenthesis
> 
>        NAPTR 10 102 "u"  "E2U+msg" "!^.*$!mailto:info@example.com!" .
 >
> _sip._e2u  IN URI 10 10 "sip:info@example.com"
> _h323._e2u IN URI 10 10 "h323:info@example.com"
> _msg._e2u  IN URI 10 10 "mailto:info@example.com"

IMO this example is very bad. It does not work with RFC3761 compliant 
resolvers. There should be also "u" NAPTRs to be compatible with old 
ENUM resolvers.

Further, the whole draft does not mention compatibility with RFC 3761. 
Using "d" NAPTRs breaks all existing ENUM applications as resolvers 
don't understand it.

I expect a least a section which discusses the compatibility issues, and 
reflect this discussion in the examples (similar the compatibility 
issues in RFC 3263).

I further miss a discussion about the difference of "u" and "d", and 
suggestion when they should be used. And why

Another important thing is that URI RRs can't be used with open dialing 
plans. Currently open dialing plans require the usage of wildcard 
NAPTRs. Introducing URI RRs will not allow to use wildcard NAPTRs. IMO 
this is an important aspect and should be mentioned in the draft.

regards
klaus

_______________________________________________
enum mailing list
enum@ietf.org
https://www1.ietf.org/mailman/listinfo/enum