Re: [Enum] Review of draft-yu-enumservice-sms-smpp

["Richard Shockey" <richard at shockey.us>]

So I'm assuming for purposes of argument that there is no objection to
making this a WG document.

>  -----Original Message-----
>  From: enum-bounces at ietf.org [mailto:enum-bounces at ietf.org] On Behalf
>  Of Alexander Mayrhofer
>  Sent: Wednesday, April 23, 2008 11:40 AM
>  To: james.yu at neustar.biz; enum at ietf.org
>  Subject: [Enum] Review of draft-yu-enumservice-sms-smpp
>  
>  
>  Hello Yu,
>  
>  i spent some time on reviewing your sms:smpp draft - i have a couple
>  of
>  comments (i probably missed some details, but given the early stage of
>  the draft, i guess we'll go through more reviewing anyway..)
>  
>  I like the idea, i understand that it makes sense. However, i don't
>  think this is neccessarily limited to private use... For example,
>  we're
>  running our own SMPP server for the number range +4359966, and i don't
>  see why i wouldn't publish a corresponding ENUM record even in User
>  ENUM
>  ... (we're limiting access on the SMPP layer, of course).
>  
>  There are some minor things, but also some major content issues, i've
>  listed them in the order i noticed them...
>  
>  
>  - Title: I'd recommend moving the "RFC 4355" part to the block on top
>  of
>  the draft, so that it says "Updates: RFC 4355 (if approved)". I'd also
>  change the title into "IANA registration of the 'smpp' URI scheme and
>  the 'smpp' subtype for the 'sms' Enumservice" (or the other way round,
>  mentioning the Enumservice first)
>  
>  - The draft does not have proper page breaks.
>  
>  - Maybe you could merge "Conventions" and "Abbreviations" into a
>  "Terminology" section, and put it in front of the Introdcution, which
>  would save you expanding all the terms in the intro.
>  
>  - There should be an informative reference to X.25
>  
>  - The ABNF reference is outdated in the text (2234), but ok in the
>  references (RFC 5234)
>  
>  - Section 5 ("use of..") is not just about the URI scheme, also about
>  the Enumservice. Maybe just rename that to "Use Cases" or "Use Case
>  Examples". Disclaimer: I didn't go thorugh the use cases themselves
>  because i'm not that deep into SMS delivery :-)
>  
>  - I'm missing a description of the dereference process of an "smpp"
>  URI.
>  For example: What is the exact process of determining the final (IP
>  level) destination (and port) from an "hostpart":
>  
>     - Does it make use of NAPTR lookups, or SRV lookups?
>     - What is the default port, if not defined?
>     - How can one specify a port? in the "hostpart"?
>  
>  The "hostpart" that you say is "imported from RFC 3261" is not
>  specified
>  in 3261... it occurs once in the text, but is never specified...
>  
>  In addition, the "telephone-subscriber" that you import into the
>  "user"
>  part already allows parameters (namely, all "tel" URI parameters, so
>  you
>  do essentially allow _two_ sets of parameters, like
>  
>  smpp:+4359966;cic=+1-6789;npdi at smpp.example.com;parameterXY=bla
>  
>  Does that make sense, and is this intended? If it is intended, what
>  are
>  the semantics of the "user" parameters... I'm unsure whether this is
>  actually allowed by the URI ABNF itself...
>  
>  - Would it be possible to make note of the "Application Class" subtype
>  in the Enumservice Registration itself? i think it would be a "Common
>  Application" Enumservice as in 4.2.4 of the Enumservice guide draft..
>  
>  - The column (":") is not part of the URI scheme name. Please remove
>  it
>  from the URI scheme part of the registration template.
>  
>  - I'm not happy with the last sentence of the "security
>  considerations"
>  section of the Enumservice template (limiting access to the DNS). I
>  think that might also trigger a lot of headwind from the DNS guys.
>  It's
>  actually an implementation veriant in certain scenarios, but i don't
>  see
>  why that would need to be included in the registration template.
>  
>  - The URI scheme needs improvement. As mentioned above, i can't find
>  the
>  "hostpart" definition, the "telephone-subscriber" import adds
>  parameter
>  space with unclear semantics, and i'm missing clear dereferencing
>  instructions.
>  
>  - If you define parameters for the SMPP URI, you will probably need to
>  define a registry for them (remember what happened to the tel: URI -
>  they needed to add a registry in a seperate document
>  http://www.ietf.org/internet-drafts/draft-ietf-iptel-tel-reg-05.txt)
>  
>  - References: I think a couple of references can be moved to
>  informative
>  status.
>  
>  hope that helps!
>  
>  cheers
>  
>  Alex
>  _______________________________________________
>  enum mailing list
>  enum at ietf.org
>  https://www.ietf.org/mailman/listinfo/enum

_______________________________________________
enum mailing list
enum at ietf.org
https://www.ietf.org/mailman/listinfo/enum