Re: Review of draft-yu-enumservice-sms-smpp WG ITEM?

I'm going to assume silence as consent .....


>  Subject: Re: [Enum] Review of draft-yu-enumservice-sms-smpp
>  
>  So I'm assuming for purposes of argument that there is no objection to
>  making this a WG document.
>  
>  >  -----Original Message-----
>  >  From: [email protected] [mailto:[email protected]] On
>  Behalf
>  >  Of Alexander Mayrhofer
>  >  Sent: Wednesday, April 23, 2008 11:40 AM
>  >  To: [email protected]; [email protected]
>  >  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;[email protected];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
>  >  [email protected]
>  >  https://www.ietf.org/mailman/listinfo/enum
>  
>  _______________________________________________
>  enum mailing list
>  [email protected]
>  https://www.ietf.org/mailman/listinfo/enum