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

Klaus,

If one uses e164.arpa as domain suffix, then you must use only E.164
numbers as input.

If one wants other than E.164 number as input, then use another domain
suffix and don't use "+" as private number prefix.

If one violates the above, collisions and bad things happen.

:)

Mike

> -----Original Message-----
> From: Klaus Darilion [mailto:klaus.mailinglists@pernau.at] 
> Sent: Thursday, October 19, 2006 7:58 AM
> To: enum@ietf.org
> Subject: [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
> 

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