Subject: Re: [Enum] Review of draft-yu-enumservice-sms-smpp WG ITEM?

From: Bernie Hoeneisen <[email-masked]>
Date: Thu, 1 May 2008 11:26:26 +0200 (CEST)

Hi Rich et al.

**  This concerns all autors of existing and upcoming
**  Enumservice registrations

As author of the Enumservice Registration I-D, I can state that this I-D 
is certainly mature enough to be used as a guideline and test case for any 
upcoming Enumservice registration.

The remaining open issues mainly concern administrative and procedural 
stuff such as down-refs, escrow copy at IANA, X- vs. P-.

These issues are definitely not in the way of using the Enumservice 
Registration I-D as a guideline for upcoming ENUMservice registrations. 
The technical content is close to final and has been stable for quite a 
while.

Thus, authors of Enumservice registrations, from now on please use

   http://tools.ietf.org/html/draft-ietf-enum-enumservices-guide

for writing up and updating your proposals.

Using the stucture described in this I-D will make the reviewer's life 
much easier and, as a result, you may get your document through faster.

cheers,
  Bernie

On Mon, 28 Apr 2008, Richard Shockey wrote:

>>  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?
>
> 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?
_______________________________________________
enum mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/enum

---

From: "Yu, James" <[email-masked]>
Date: Wed, 30 Apr 2008 12:24:57 -0400

Alex,

Thanks for the comments.   Please see the responses below that begin
with [YU].

James

-----Original Message-----
From: Alexander Mayrhofer [mailto:[email-masked]] 
Sent: Wednesday, April 23, 2008 11:40 AM
To: Yu, James; [email-masked]
Subject: 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)

[YU] The title is changed to  - IANA Registrations of Enumservice
"sms:smpp" and "smpp" URI

- The draft does not have proper page breaks.

[YU] Will check.

- 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.

[YU] "Abbreviations" section will become section 2.

- There should be an informative reference to X.25

[YU] Will add.

- The ABNF reference is outdated in the text (2234), but ok in the 
references (RFC 5234)

[YU] Will correct.

- 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 :-)

[YU] Will change to "Use Cases".

- 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...

[YU] In Section 6, SRV RR lookup is added in the example.   The default
port for SMPP is 2775.   "hostpart" should be "hostport".

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...

[YU] Will define "user" parameter.

- 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..

[YU] Will change to "Common Application".

- The column (":") is not part of the URI scheme name. Please remove it 
from the URI scheme part of the registration template.

[YU] Will remove ":".

- 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.

[YU] Will remove.

- 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.

[YU] Will improve. 

- 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)

[YU] Will write a separate I-D.

- References: I think a couple of references can be moved to informative

status.

[YU] Will move some.

hope that helps!

cheers

Alex

---

From: Bernie Hoeneisen <[email-masked]>
Date: Fri, 9 May 2008 21:33:57 +0200 (CEST)

Hi Lawrence et al.

On Tue, 29 Apr 2008, lconroy wrote:

> 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.

We jmade clear in Service Guide [draft-ietf-enum-enumservices-guide-09], 
that Service Guide is only about "regular" Enumservice registrations, and 
therefore does not include "X-" registrations.

As you know, "X-" registrations are handled in a separate document 
<draft-ietf-enum-x-service-regs>, which does neither hold up RFC3761bis 
nor Service Guide. I'll update (or rather completely rewrite) it soon as 
Service Guide seems to be pretty stable by now.

cheers,
  Bernie

---

From: Bernie Hoeneisen <[email-masked]>
Date: Fri, 9 May 2008 21:45:41 +0200 (CEST)

Hi Rich

On Mon, 28 Apr 2008, Richard Shockey wrote:

> 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.

I am a bit worried about having to tight schedule during the ENUM WG 
meeting in Dublin. As the new topics might eat time we need to finalize 
Service Guide and RFC3761bis. I really hope we can get both documents done 
within the next weeks.

Also bear in mind, that Dublin might be the last meeting I can attend 
personally. I'll change my employer by the beginning of July and it is 
rather unsure, whether or not I will be able to participate IETF meetings 
in future.

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

Good idea! Who is taking care (i.e. holder of the Action Point) about this 
step? Author(s) or chair(s)?

cheers,
  Bernie

---

From: "Richard Shockey" <[email-masked]>
Date: Tue, 13 May 2008 11:21:04 -0400

>  Service Guide and RFC3761bis. I really hope we can get both documents

So what are we waiting for .. again .. are we done yet?   Should I issue
WGLC for 3761bis .. no one wants to answer the question.

>  step? Author(s) or chair(s)?

You are nominated seconded and confirmed ... I've added Dave to the thread
...