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

From: Alexander Mayrhofer <[email-masked]>
Date: Wed, 23 Apr 2008 17:40:17 +0200

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-masked];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-masked]
https://www.ietf.org/mailman/listinfo/enum

---

From: "Richard Shockey" <[email-masked]>
Date: Thu, 24 Apr 2008 18:57:40 -0400

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

>  -----Original Message-----
>  From: [email-masked] [mailto:[email-masked]] On Behalf
>  Of Alexander Mayrhofer
>  Sent: Wednesday, April 23, 2008 11:40 AM
>  To: [email-masked]; [email-masked]
>  Subject: [Enum] Review of draft-yu-enumservice-sms-smpp
>  
>  
>  Hello Yu,
>

---

From: "Richard Shockey" <[email-masked]>
Date: Fri, 25 Apr 2008 14:05:04 -0400

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

>  Subject: Re: [Enum] Review of draft-yu-enumservice-sms-smpp
>  
>  >  i spent some time on reviewing your sms:smpp draft - i have a
>  couple
>  >  of
>  >  - Title: I'd recommend moving the "RFC 4355" part to the block on
>  top
>  >  of
>  >  part already allows parameters (namely, all "tel" URI parameters,
>  so
>  >  you
>  >  - The column (":") is not part of the URI scheme name. Please
>  remove
>  >  it
>  >  actually an implementation veriant in certain scenarios, but i
>  don't
>  >  see
>  >  - The URI scheme needs improvement. As mentioned above, i can't
>  find
>  >  the

---

From: Peter Koch <[email-masked]>
Date: Mon, 28 Apr 2008 16:39:16 +0200

> >  making this a WG document.

without any disrespect to the document under consideration:
Now that we have the "enum services" document in its final stages, wouldn't
it be better to use _this_ draft as one test case for "enum services" and thus,
with AD backing of course, not adopt it but use the procedure outlined in
"enum services" for review and evaluation?

The fact that this draft updates an existing registration might make it more
difficult, but would also be helpful in getting "enum services" done.

-Peter

---

From: "Richard Shockey" <[email-masked]>
Date: Mon, 28 Apr 2008 12:32:46 -0400

>  with AD backing of course, not adopt it but use the procedure outlined
>  in  "enum services" for review and evaluation?

That would be nice but how close are we to being ready to go to WGLC on the
Registration document? 

Would the Registration draft authors care to comment?

I'd hate to see a perfectly simple registration ID held up too long if
Registration/3761bis this were going to be dragged out past Dublin.

We do seem to have some trouble getting people to review and comment on RFC
3761 bis etc.. the two are somewhat tied together.

>  
>  The fact that this draft updates an existing registration might make
>  it more  difficult, but would also be helpful in getting "enum services"
done.

I'm certainly open minded here ... what does the WG want to do?

---

From: lconroy <[email-masked]>
Date: Tue, 29 Apr 2008 00:54:01 +0100

Hi Richard, folks,
  I'm neutral either way on trying to push this through or to
"do it properly" using rfc3761bis and the guide. You did say before
that we should "eat our own dog food" and use the new process, but
I understand the commercial imperative to get something out soon.

Also, choosing a track for James' SMS update depends on whether or not
the IESG will be enthusiastic to process the SMS update with the new
process (designed to put less load on them) just around the corner
- care to guess?

However, I'd hate to see 3761bis and the guide held up too long either.

IMHO, the Guide is pretty close to complete.
The only real question is whether or not we need to do a refreshed
"X- guide" soon. Either way, I think the "main" guide is ready to roll.

3761bis should be complete, and will have one more refresh at some point
to reflect the WGLC comments Alfred Hoenes gave us (which were not  
really
editorial, IIUC, so that could even be in Authors'48).

The authors on these docs have worked really hard to get them together.
I can't see any reason why they should be delayed in the WG.

Given the IESG comments on Experiences, do we need some clarification  
from
Jon on whether or not he thinks that these documents will be  
acceptable to
the IESG?
[3761bis has a chunk of text from Experiences, so I'm no longer sure  
quite
what's OK and what isn't]

all the best,
   Lawrence

---

From: "Richard Shockey" <[email-masked]>
Date: Mon, 28 Apr 2008 21:29:18 -0400

>  From: lconroy [mailto:[email-masked]]
>  Sent: Monday, April 28, 2008 7:54 PM
>  To: Richard Shockey
>  Cc: 'Peter Koch'; [email-masked]
>  Subject: Re: [Enum] Review of draft-yu-enumservice-sms-smpp WG ITEM?
>  
>  Hi Richard, folks,

It would make Dublin a lot easier to schedule. I'm terribly reluctant to go
for 2 hours since we have enough contentious issues to discuss and RAI will
be packed as usual.  I think we need to do our duty here and push out
3761bis and the Registration document to WGLC ASAP.

What is that going to take?

>  process (designed to put less load on them) just around the corner

No. Patrik and I are just lowly middle management here. We have no special
insight into the current internal religious rituals of the IESG. James draft
is IMHO pretty routine. My concern is process. If the 3761bis and
Registration get caught up in the IESG blender it could be a year or more
before real action. That is IMHO unacceptable. I thought the same with Jason
Livingoods draft on internal messaging. Just do it now,  but if we are close
to WGLC on Registration OK..but.  Where is the proper cut off point? At what
point do we say no more registration drafts until the new procedure is in
place. Peter Koch has a valid point, as usual.

>  "X- guide" soon. Either way, I think the "main" guide is ready to

Is this the consensus of the WG?  Should everyone take one last look at
3761bis and the Registration document? 

Is it appropriate to run the Registration document through David Conrad of
IANA for comments? 

Lawrence .. ?? Send a note to Dave that might help. He is IANA after all.

I'm only asking.
  
>  3761bis should be complete, and will have one more refresh at some
>  point to reflect the WGLC comments Alfred Hoenes gave us (which were not
>  really editorial, IIUC, so that could even be in Authors'48).
>  
>  The authors on these docs have worked really hard to get them
>  together.  I can't see any reason why they should be delayed in the WG.
>  
>  from  Jon on whether or not he thinks that these documents will be
>  acceptable to  the IESG?
>  quite  what's OK and what isn't]

At this point I don't think it's reasonable to ask the AD for pre guidance
on what they might or might not accept. All we can do as a WG is do our
best, throw the document over the transom and wait and see. 

Given that what is the plan?  Do you have a plan? Did you ever see the movie
'The Hunt for Red October'. "So what the plan?" ...you can fill in the rest
of the script.

I do have to express a certain exasperation that the WG has not given more
discussion to 3761bis etc. Though the Registration document has thoroughly
evolved, through WG discussion, into the fine product it is.