review of draft-ietf-enum-enumservice-smpp-01

Hi,

I've done a review of the SMPP Enumservice draft. In short, there are a 
couple of formatting nits, plus there are some content issues, mostly 
with the URI scheme definition. For some of the topics, i'm definitely 
far away from being an expert, so i suggest additional review from URI 
and SMPP experts.

Considering the Enumservice itself, the draft is pretty straightforward 
- however, i feel the smpp URI definition is very weak.

comments in detail:

- NITS: There are a bunch of formatting problems with the draft, most 
notably the missing page breaks. Please see

http://tools.ietf.org/idnits?url=http://tools.ietf.org/id/draft-ietf-enum-enumservice-sms-smpp-01.txt

- I'm not an expert at all on GSM systems. I'd appreciate if someone 
more familiar with SMS could review the introduction and the use cases.

- I don't think that "RFC 4355 allows subtypes to be defined.." (section 
4). It would be better to say that "RFC 4355 defines the Subtypes "tel" 
and "mailto" for the "sms" Type Enumservice. This document extends the 
"sms" Type by adding the "smpp" Subtype to that set of services" (or 
something along those lines)

- Secion 4 should also refer to the Formal Syntax of the Enumservice (it 
does only for the URI scheme)

- As said above, i'd appreciate an SMS expert to review the use cases. 
Additionally, i'm confused by the paragraph that starts at the very end 
of "page" 5, and spans to the top of "page" 6. It looks as if there is 
either some text lost between those two parts, or some text has been 
copied there accidentially from somewhere else..

- "Example" - I don't see the dereferencing of the URI scheme specified 
anywhere else. I don't think an example is sufficient for that - please 
add specification on how a smpp URI is dereferenced to the respective 
section.

- From what i know, URI scheme registrations also require some text on 
how URIs are compared. I can't find any text about this in the draft either.

- The "Security considerations" of the Enumservice describes an 
assumption of an use case, not actual security risks and measures. There 
should be some text like "an SMPP URI might reveal internal network 
elements and relations between numbers and operators... etc...", because 
that would describe the threat rather than the assumed scenario to 
mitigate that risk. Same for the second paragraph, which doesn't mention 
risks, but describes an usage scenario. The Enumservice security 
considerations should also only list considerations that are specific to 
the use within ENUM, not general URI scheme considerations.

- The URI scheme is heavily underspecified. For example, even though the 
"headers" component is described in RFC 3261, there is no functional 
description of how those headers are actually used in SMPP (from what i 
know, SMPP doesn't provide a concept of "Headers". RFC 3261 says:

  "Headers: Header fields to be included in a request constructed
          from the URI."


That simply does not fit into the SMPP concept - therefore the 
specification is extremely weak.

Same for the "userinfo".

Also, the "parameter" component might require a registry (compare the 
hassle with the "tel" URI...)

I don't see how an implementor would be able to correctly implement 
handling the "smpp" URI with the information that is currently contained 
in the document - which in turn might make interopability much harder, 
because of a variety of interpretations of URI components...

I do suggest that the author contacts the URI-review list, and discusses 
the draft with the list members.

To conclude, the Enumservice registration looks ready for WGLC, the URI 
scheme definition IMHO definitely does not (but i don't see the 
expertise for that within the ENUM working group, which is a different 
issue).

comments?

Alex