[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Enum] 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: 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
_______________________________________________
enum mailing list
enum at ietf.org
https://www.ietf.org/mailman/listinfo/enum