[Enum] Review of draft-yu-enumservice-sms-smpp
Alexander Mayrhofer <alexander.mayrhofer@enum.at> Wed, 23 April 2008 15:40 UTC
Return-Path: <enum-bounces@ietf.org>
X-Original-To: enum-archive@megatron.ietf.org
Delivered-To: ietfarch-enum-archive@core3.amsl.com
Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 2C7793A6E3C; Wed, 23 Apr 2008 08:40:28 -0700 (PDT)
X-Original-To: enum@core3.amsl.com
Delivered-To: enum@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8C9FF3A6AAB for <enum@core3.amsl.com>; Wed, 23 Apr 2008 08:40:26 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.299
X-Spam-Level:
X-Spam-Status: No, score=-2.299 tagged_above=-999 required=5 tests=[AWL=-0.300, BAYES_00=-2.599, J_CHICKENPOX_34=0.6]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id j4YZvTB2C37h for <enum@core3.amsl.com>; Wed, 23 Apr 2008 08:40:25 -0700 (PDT)
Received: from kahua.nona.net (pahula.nona.net [193.80.224.123]) by core3.amsl.com (Postfix) with ESMTP id F0D9F3A6A4F for <enum@ietf.org>; Wed, 23 Apr 2008 08:40:24 -0700 (PDT)
Received: from [10.10.0.113] ([::ffff:83.136.33.3]) (AUTH: PLAIN axelm, TLS: TLSv1/SSLv3,256bits,AES256-SHA) by pahula with esmtp; Wed, 23 Apr 2008 17:25:27 +0200 id 000100B5.480F54E7.00002ED4
Message-ID: <480F5861.3050006@enum.at>
Date: Wed, 23 Apr 2008 17:40:17 +0200
From: Alexander Mayrhofer <alexander.mayrhofer@enum.at>
Organization: enum.at GmbH
User-Agent: Thunderbird 2.0.0.12 (Windows/20080213)
MIME-Version: 1.0
To: james.yu@neustar.biz, enum@ietf.org
Subject: [Enum] Review of draft-yu-enumservice-sms-smpp
X-BeenThere: enum@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: Enum Discussion List <enum.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/enum>, <mailto:enum-request@ietf.org?subject=unsubscribe>
List-Post: <mailto:enum@ietf.org>
List-Help: <mailto:enum-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/enum>, <mailto:enum-request@ietf.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: enum-bounces@ietf.org
Errors-To: enum-bounces@ietf.org
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@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@ietf.org https://www.ietf.org/mailman/listinfo/enum
- [Enum] Review of draft-yu-enumservice-sms-smpp Alexander Mayrhofer
- Re: [Enum] Review of draft-yu-enumservice-sms-smpp Richard Shockey
- Re: [Enum] Review of draft-yu-enumservice-sms-smp… Richard Shockey
- Re: [Enum] Review of draft-yu-enumservice-sms-smp… Peter Koch
- Re: [Enum] Review of draft-yu-enumservice-sms-smp… Richard Shockey
- Re: [Enum] Review of draft-yu-enumservice-sms-smp… lconroy
- Re: [Enum] Review of draft-yu-enumservice-sms-smp… Richard Shockey
- Re: [Enum] Review of draft-yu-enumservice-sms-smp… Bernie Hoeneisen
- Re: [Enum] Review of draft-yu-enumservice-sms-smpp Yu, James
- Re: [Enum] Review of draft-yu-enumservice-sms-smp… Bernie Hoeneisen
- [Enum] Scheduling Enum WG meeting Dublin (was Re:… Bernie Hoeneisen
- Re: [Enum] Scheduling Enum WG meeting Dublin (was… Richard Shockey