From lconroy@insensate.co.uk Sat May 2 07:39:36 2009 Return-Path: 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 E689D3A6D86 for ; Sat, 2 May 2009 07:39:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=-0.001, BAYES_00=-2.599, NORMAL_HTTP_TO_IP=0.001] 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 qXq2kKa7t0kK for ; Sat, 2 May 2009 07:39:35 -0700 (PDT) Received: from insensate.co.uk (ghost.insensate.co.uk [213.152.49.121]) by core3.amsl.com (Postfix) with ESMTP id 710893A6D7D for ; Sat, 2 May 2009 07:39:33 -0700 (PDT) Received: from [127.0.0.1] (localhost [127.0.0.1]) by insensate.co.uk (Postfix) with ESMTP id C8AB611B986; Sat, 2 May 2009 15:41:18 +0100 (BST) Message-Id: <635004FB-361A-4917-B2BE-09F6666B7ECD@insensate.co.uk> From: Lawrence Conroy To: IETF ENUM list Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v930.3) Date: Sat, 2 May 2009 15:40:56 +0100 X-Mailer: Apple Mail (2.930.3) Cc: paf@cisco.com, sob@harvard.edu Subject: [Enum] Proposed tweak to section 2 of 3761 X-BeenThere: enum@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Enum Discussion List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 02 May 2009 14:39:37 -0000 Hi Folks, I have just had yet another developer confused with DDDS and RFC3761 and the way that key/FQDN generation is described for ENUM. This confusion is caused exclusively by the text currently in 3761 section 2, and I ask the WG if they would mind this being changed into English for the next spin of 3761 (as proposed at the end of this mail). I'd prefer to avoid having to to raise an erratum against 3761 first. [In rfc3761bis, I believe that the equivalent change is to move all but the last two paragraphs of 2.4.1 into 2.2 (and renumber the following sub-sections)] Comments? all the best, Lawrence p.s. I am unsure of Michael's email address so couldn't ping him. If anyone know this, could you pass this on? -------- Background: DDDS has some useful definitions in RFC3402 ss 2, describing the AUS and the First Well Known Rule, and the Rule Database. The definitions are: Application Unique String A string that is the initial input to a DDDS application. The lexical structure of this string must imply a unique delegation path, which is analyzed and traced by the repeated selection and application of Rewrite Rules. First Well Known Rule This is a rewrite rule that is defined by the application and not actually in the Rule Database. It is used to produce the first valid key. Rule Database Any store of Rules such that a unique key can identify a set of Rules that specify the delegation step used when that particular Key is used. Section 4 of RFC 3402 expands on these, defining what must be specified for a DDDS application (like E2U). Application Unique String: This is the only string that the rewrite rules will apply to. The string must have some regular structure and be unique within the application such that anyone applying Rules taken from the same Database will end up with the same Keys. For example, the URI Resolution application defines the Application Unique String to be a URI. No application is allowed to define an Application Unique String such that the Key obtained by a rewrite rule is treated as the Application Unique String for input to a new rule. This leads to sendmail style rewrite rules which are fragile and error prone. The one single exception to this is when an Application defines some flag or state where the rules for that application are suspended and a new DDDS Application or some other arbitrary set of rules take over. If this is the case then, by definition, none of these rules apply. One such case can be found in the URI Resolution application which defines the 'p' flag which states that the next step is 'protocol specific' and thus outside of the scope of DDDS. First Well Known Rule: This is the first rule that, when applied to the Application Unique String, produces the first valid Key. It can be expressed in the same form as a Rule or it can be something more complex. For example, the URI Resolution application might specify that the rule is that the sequence of characters in the URI up to but not including the first colon (the URI scheme) is the first Key. Valid Databases: The application can define which Databases are valid. For each Database the Application must define how the First Well Known Rule's output (the first Key) is turned into something that is valid for that Database. For example, the URI Resolution application could use the Domain Name System (DNS) as a Database. The operation for turning this first Key into something that was valid for the database would be to to turn it into some DNS-valid domain-name. Additionally, for each Database an Application defines, it must also specify what the valid character sets are that will produce the correct Keys. In the URI Resolution example shown here, the character set of a URI is 7 bit ASCII which matches fairly well with DNS's 8 bit limitation on characters in its zone files. -- So... In the definition of the E2U DDDS application (as specified in 3761 and soon to be updated in rfc3761bis): - you might expect some defined pre-processing of a passed telephone number to make a "canonical form" Application Unique String so that "the lexical structure of this string" implies "a unique delegation path". - you might expect the first well known rule to be specified so that the telephone number/AUS can be converted into a key in the rules database; in the case of DNS, that is going to be an owner or Fully Qualified Domain Name. - you might also expect that the database is defined as DNS, with NAPTRs as the records that carry the DDDS Rules. What is currently in RFC 3761 (sections 2.1, 2.2, and 2.4 respectively) is at best confusing, and may be incorrect as written. 2.1: The AUS definition is clear. 2.2: The First Well Known Rule is not right; it is shown as identity, which does not generate a valid key into DNS (a FQDN). 2.4: The Database Definition includes a conversion step that will, if followed, be applied to ALL terms that will be converted into a FQDN, including the output of non-terminal Rules. That works for the AUS with the current identity First Well Known Rule, but it breaks badly when given the output of a non-terminal NAPTR. Adding a caveat to section 2.4 is not the right approach, and HAS caused entirely unnecessary confusion. It's like adding a second ear to the fish. It may make it symmetrical, but the real solution is not to have the mess in the first place. What one would have expected in the first well known rule is that it takes the AUS and converts it into a FQDN, by stripping all characters except digits (step 1), reversing the sequence of the characters (step 3), interspersing dots (step 2) and then appending the apex (step 4). The Database definition then only needs to refer to 3403. The steps are not appropriate in this section, as E2U uses DNS and NAPTRs in exactly the same way as any other. -------- What I propose to fix this is: The First Well Known Rule section inherits the FQDN generation steps from section 2.4. For convenience, I'd suggest that steps 2 and 3 are swapped. Every implementation I've seen does it that way, as it's quicker. The Database definition would have the first paragraph only. The last two paragraphs of the current section 2.4 could stay there; these are merely notes. Proposed text for the start of section 2 (up to but excluding 2.4.1) follows (with changes indicated by arrows): ---------------------------------------------------------------- ---------------------------------------------------------------- 2. The ENUM Application Specifications This template defines the ENUM DDDS Application according to the rules and requirements found in [7]. The DDDS database used by this Application is found in [2] which is the document that defines the NAPTR DNS Resource Record type. ENUM is only applicable for E.164 numbers. ENUM compliant applications MUST only query DNS for what it believes is an E.164 number. Since there are numerous dialing plans which can change over time, it is probably impossible for a client application to have perfect knowledge about every valid and dialable E.164 number. Therefore a client application, doing everything within its power, can end up with what it thinks is a syntactically correct E.164 number which in reality is not actually valid or dialable. This implies that applications MAY send DNS queries when, for example, a user mistypes a number in a user interface. Because of this, there is the risk that collisions between E.164 numbers and non-E.164 numbers can occur. To mitigate this risk, the E2U portion of the service field MUST NOT be used for non-E.164 numbers. 2.1. Application Unique String The Application Unique String is a fully qualified E.164 number minus any non-digit characters except for the '+' character which appears at the beginning of the number. The "+" is kept to provide a well understood anchor for the AUS in order to distinguish it from other telephone numbers that are not part of the E.164 namespace. For example, the E.164 number could start out as "+44-116-496-0348". To ensure that no syntactic sugar is allowed into the AUS, all non- digits except for "+" are removed, yielding "+441164960348". 2.2. First Well Known Rule ----> The First Well Known Rule for this Application converts the Application Unique String (AUS) into a key for the Rules Database, which in this case is the DNS, so this key is a domain name. The output of this rule is the same as the input. The E.164 namespace and this Applications database are organized in such a way that it is possible to go directly from the name to the smallest granularity of the namespace directly from the name itself. The first well known rule merely maps from the pre-processed telephone number into the ENUM namespace as reflected within the DNS. In order to convert the AUS to a unique key in this Database the string is converted into a domain-name according to this algorithm: 1. Remove all characters with the exception of the digits. For example, the AUS is "+442079460148". This step would simply remove the leading "+", producing "442079460148". 2. Reverse the order of the digits. Example: "841064970244" 3. Put dots (".") between each digit. Example: 8.4.1.0.6.4.9.7.0.2.4.4 4. Append the string ".e164.arpa" to the end. Example: 8.4.1.0.6.4.9.7.0.2.4.4.e164.arpa <---- This domain-name is the key used to request NAPTR records which may contain the end result or, if the flags field is blank, produces new keys in the form of domain-names from the DNS. 2.3. Expected Output The output of the last DDDS loop is a Uniform Resource Identifier in its absolute form according to the 'absoluteURI' production in the Collected ABNF found in RFC2396 [4]. 2.4. Valid Databases At present only one DDDS Database is specified for this Application. "Dynamic Delegation Discovery System (DDDS) Part Three: The DNS Database" (RFC 3403) [2] specifies a DDDS Database that uses the NAPTR DNS resource record to contain the rewrite rules. The Keys for this database are encoded as domain-names. ----> <---- Some nameserver implementations attempt to be intelligent about items that are inserted into the additional information section of a given DNS response. For example, BIND will attempt to determine if it is authoritative for a domain whenever it encodes one into a packet. If it is, then it will insert any A records it finds for that domain into the additional information section of the answer until the packet reaches the maximum length allowed. It is therefore potentially useful for a client to check for this additional information. It is also easy to contemplate an ENUM enhanced nameserver that understand the actual contents of the NAPTR records it is serving and inserts more appropriate information into the additional information section of the response. Thus, DNS servers MAY interpret Flag values and use that information to include appropriate resource records in the Additional Information portion of the DNS packet. Clients are encouraged to check for additional information but are not required to do so. See the Additional Information Processing section of RFC 3403 [2], Section 4.2 for more information on NAPTR records and the Additional Information section of a DNS response packet. The character set used to encode the substitution expression is UTF- 8. The allowed input characters are all those characters that are allowed anywhere in an E.164 number. The characters allowed to be in a Key are those that are currently defined for DNS domain-names. ---------------------------------------------------------------- ---------------------------------------------------------------- From rfc-editor@rfc-editor.org Mon May 4 16:44:53 2009 Return-Path: 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 51D7C28C1F0; Mon, 4 May 2009 16:44:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -17.215 X-Spam-Level: X-Spam-Status: No, score=-17.215 tagged_above=-999 required=5 tests=[AWL=0.384, BAYES_00=-2.599, USER_IN_DEF_WHITELIST=-15] 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 H7NnRDLgCHJX; Mon, 4 May 2009 16:44:46 -0700 (PDT) Received: from bosco.isi.edu (bosco.isi.edu [128.9.168.207]) by core3.amsl.com (Postfix) with ESMTP id 4F9D43A6B05; Mon, 4 May 2009 16:44:46 -0700 (PDT) Received: by bosco.isi.edu (Postfix, from userid 70) id 6C37C29B2A8; Mon, 4 May 2009 16:43:02 -0700 (PDT) To: ietf-announce@ietf.org, rfc-dist@rfc-editor.org From: rfc-editor@rfc-editor.org Message-Id: <20090504234302.6C37C29B2A8@bosco.isi.edu> Date: Mon, 4 May 2009 16:43:02 -0700 (PDT) Cc: enum@ietf.org, rfc-editor@rfc-editor.org Subject: [Enum] RFC 5527 on Combined User and Infrastructure ENUM in the e164.arpa Tree X-BeenThere: enum@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Enum Discussion List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 04 May 2009 23:44:53 -0000 A new Request for Comments is now available in online RFC libraries. RFC 5527 Title: Combined User and Infrastructure ENUM in the e164.arpa Tree Author: M. Haberler, O. Lendl, R. Stastny Status: Informational Date: May 2009 Mailbox: ietf@mah.priv.at, otmar.lendl@enum.at, richardstastny@gmail.com Pages: 10 Characters: 20733 Updates/Obsoletes/SeeAlso: None I-D Tag: draft-ietf-enum-combined-09.txt URL: http://www.rfc-editor.org/rfc/rfc5527.txt This memo defines an interim solution for Infrastructure ENUM in order to allow a combined User and Infrastructure ENUM implementation in e164.arpa as a national choice. This interim solution will be deprecated after implementation of the long-term solution. This memo provides information for the Internet community. This document is a product of the Telephone Number Mapping Working Group of the IETF. INFORMATIONAL: This memo provides information for the Internet community. It does not specify an Internet standard of any kind. Distribution of this memo is unlimited. This announcement is sent to the IETF-Announce and rfc-dist lists. To subscribe or unsubscribe, see http://www.ietf.org/mailman/listinfo/ietf-announce http://mailman.rfc-editor.org/mailman/listinfo/rfc-dist For searching the RFC series, see http://www.rfc-editor.org/rfcsearch.html. For downloading RFCs, see http://www.rfc-editor.org/rfc.html. Requests for special distribution should be addressed to either the author of the RFC in question, or to rfc-editor@rfc-editor.org. Unless specifically noted otherwise on the RFC itself, all RFCs are for unlimited distribution. The RFC Editor Team USC/Information Sciences Institute From root@core3.amsl.com Mon May 4 17:45:05 2009 Return-Path: X-Original-To: enum@ietf.org Delivered-To: enum@core3.amsl.com Received: by core3.amsl.com (Postfix, from userid 0) id A78EC28C18D; Mon, 4 May 2009 17:45:01 -0700 (PDT) From: Internet-Drafts@ietf.org To: i-d-announce@ietf.org Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 Message-Id: <20090505004505.A78EC28C18D@core3.amsl.com> Date: Mon, 4 May 2009 17:45:01 -0700 (PDT) Cc: enum@ietf.org Subject: [Enum] I-D Action:draft-ietf-enum-3761bis-04.txt X-BeenThere: enum@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Enum Discussion List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 05 May 2009 00:45:05 -0000 --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Telephone Number Mapping Working Group of the IETF. Title : The E.164 to Uniform Resource Identifiers (URI) Dynamic Delegation Discovery System (DDDS) Application (ENUM) Author(s) : S. Bradner, et al. Filename : draft-ietf-enum-3761bis-04.txt Pages : 22 Date : 2009-05-04 This document discusses the use of the Domain Name System (DNS) for the storage of E.164 numbers, and for resolving them into URIs that can be used for (for example) telephony call setup. This document also describes how the DNS can be used to identify the services associated with an E.164 number. This document obsoletes RFC 3761. Copyright and License Notice Copyright (c) 2009 IETF Trust and the persons identified as the document authors. All rights reserved. This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents in effect on the date of publication of this document (http://trustee.ietf.org/license-info). Please review these documents carefully, as they describe your rights and restrictions with respect to this document. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-enum-3761bis-04.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Message/External-body; name="draft-ietf-enum-3761bis-04.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2009-05-04173425.I-D@ietf.org> --NextPart-- From D.Malas@cablelabs.com Tue May 12 15:30:10 2009 Return-Path: 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 10BF93A6A2F for ; Tue, 12 May 2009 15:30:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.35 X-Spam-Level: X-Spam-Status: No, score=-0.35 tagged_above=-999 required=5 tests=[AWL=0.113, BAYES_00=-2.599, HELO_EQ_MODEMCABLE=0.768, HOST_EQ_MODEMCABLE=1.368] 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 dTez-zoNtgNH for ; Tue, 12 May 2009 15:30:09 -0700 (PDT) Received: from ondar.cablelabs.com (ondar.cablelabs.com [192.160.73.61]) by core3.amsl.com (Postfix) with ESMTP id F2A0A3A6842 for ; Tue, 12 May 2009 15:30:08 -0700 (PDT) Received: from kyzyl.cablelabs.com (kyzyl [10.253.0.7]) by ondar.cablelabs.com (8.14.3/8.14.3) with ESMTP id n4CMVdkY014094; Tue, 12 May 2009 16:31:39 -0600 Received: from srvxchg3.cablelabs.com (10.5.0.25) by kyzyl.cablelabs.com (F-Secure/fsigk_smtp/511/kyzyl.cablelabs.com); Tue, 12 May 2009 16:31:39 -0700 (MST) X-Virus-Status: clean(F-Secure/fsigk_smtp/511/kyzyl.cablelabs.com) Received: from 10.4.1.45 ([10.4.1.45]) by srvxchg3.cablelabs.com ([10.5.0.25]) via Exchange Front-End Server webmail.cablelabs.com ([10.253.0.8]) with Microsoft Exchange Server HTTP-DAV ; Tue, 12 May 2009 22:31:39 +0000 User-Agent: Microsoft-Entourage/12.17.0.090302 Date: Tue, 12 May 2009 16:31:38 -0600 From: Daryl Malas To: Richard Shockey , "'IETF ENUM WG'" Message-ID: Thread-Topic: [Enum] WG: New Draft: Trunk Group Use in ENUM RESTART - Second request for guidence Thread-Index: AcmpUkn18LDs6jcbRDuU+5gveAaRQwZW8G/QAW3h/9ACuvWRJg== In-Reply-To: <00c101c9c866$9acf5c30$d06e1490$@us> Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit X-Approved: ondar Subject: Re: [Enum] WG: New Draft: Trunk Group Use in ENUM RESTART - Second request for guidence X-BeenThere: enum@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Enum Discussion List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 12 May 2009 22:30:10 -0000 Richard, Well, I guess I will throw my hat in the ring. As an author of the proposed draft, I think this is a valuable draft for the industry. If I am the only one, then I guess the draft is irrelevant. Regards, Daryl On 4/28/09 7:05 PM, "Richard Shockey" wrote: > Second call .. what is WG consensus here? > > This is not a silence is consent issue. It requires a form of decision. > > (Chair hat off) I've made my personal sentiments clear. We all thought this > was a useful WG item. Some folks have come to us with a cleaner form of > dealing with the use case that does not require a formal enumservice > registration. It has wide applicability. Better to create a BCP or > Informational than let multiple implementations go off in all sorts of non > interoperable directions. > > What does the WG want to do or do you want the chairs to decide? We are not > going to have a meeting in Stockholm over this. > > >> -----Original Message----- >> From: enum-bounces@ietf.org [mailto:enum-bounces@ietf.org] On Behalf >> Of Richard Shockey >> Sent: Tuesday, April 21, 2009 2:29 PM >> To: 'Peter Koch'; 'IETF ENUM WG' >> Subject: Re: [Enum] WG: New Draft: Trunk Group Use in ENUM RESTART >> >> >> I'd like to take up where we left off on this subject and determine >> what the WG consensus is on dealing with this issue. >> >> There is consensus that this is a item we had on the WG plate that has >> real applicability to applications in use and clarification on how these >> parameters should be represented in ENUM queries is a "good thing". >> >> The first question is then do we essentially adopt this new draft as a >> WG item and quickly move it forward? >> >> The second is as what Informational or BCP? >> >> >>> I have no expertise on the subject matter, but would like to share >>> some observations on process: >>> >>> On Fri, Mar 06, 2009 at 02:22:03PM +0000, Lawrence Conroy wrote: >>> >>>> beware - *who* gets to decide if a WG draft is dead? >>> >>> usually that's a WG consensus, either explicitly or by lack of >> motion >>> as to >>> be determined by the chairs. In this case however, it seems that >> the >>> WG >>> (or those in the WG who actively follow the matter) have changed >> their >>> mind >>> about the direction of the draft. Posting a new I-D was one way, >> but >>> if the >>> WG consensus is that the solution proposed in >>> "IANA Registration for an Enumservice Trunkgroup" is no longer the >>> right one >>> and instead a parameter to the SIP URI, as proposed in Trunk Group >> Use >>> in ENUM >>> will do better, then WG consensus could just direct the editors to >> re- >>> write >>> accordingly. Now, it seems that the editors change on the fly, >> too, >>> but that's >>> up to the chairs (well, and any new editors) anyway. >>> >>>> Also, why is putting this new stuff in the clutches of a sleeping >>>> WG (or an inchoate one) going to make it any faster getting any >> BCP >>>> through the IETF/IESG process? Does anyone remember IPTEL? >>> >>> I am a bit nervous about "fast tracking" in the last minute and the >>> status of BCP. The former seldomly works out, but the current >> work item >>> needs to get off the WG's plate anyway. The latter doesn't seem >> necessary, >>> especially since we're about to re-classify all (or many of) those >>> Proposed Standards anyway. A purely Informational document would >> do, and >> is >>> definitely more lightweight. The draft would be an Informational >>> addendum to RFC 3764, which it needs to reference normatively. >>> >>> The draft itself, however, isn't really clear about the intended >>> status >>> "IANA Registration for an Enumservice Trunkgroup". This document >> is a >>> normative >>> reference although it seems to have outlived its usefulness and >>> actually the >>> registration in there is kind of revoked. >>> However, the "trunk" ENUM service doesn't yet appear in >>> if my pattern >> matching >>> skills >>> suffice. So, instead of pursuing the old draft and immediately >>> revoking the >>> registration (or declaring it a no go), the new (well, "revised") >>> draft >>> should just state the new intended method of using trunk groups in >>> ENUM >>> and incorporate verbatim the relevant parts of the earlier draft >>> (without >>> suggesting there actually _is_ a valid ENUM servcie registration) >> in >>> an >>> appendix. >>> It wouldn't be the first time an IETF WG started an effort to do >> FOO >>> and the >>> document ends with the title "Why not to FOO". >>> >>> I'm not sure I follow the rationale in the first paragraph of >> section >>> 1.2, >>> it feels like it's superseded by the newly born 5483 -- >>> congratulations, by >>> the way. >>> > > _______________________________________________ > enum mailing list > enum@ietf.org > https://www.ietf.org/mailman/listinfo/enum ----------------- Daryl Malas CableLabs (o) +1 303 661 3302 (f) +1 303 661 9199 mailto:d.malas@cablelabs.com From richard@shockey.us Wed May 13 15:12:59 2009 Return-Path: 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 738E53A6A7C for ; Wed, 13 May 2009 15:12:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.864 X-Spam-Level: X-Spam-Status: No, score=-1.864 tagged_above=-999 required=5 tests=[AWL=0.401, BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334] 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 u4Jsy6Q7DADe for ; Wed, 13 May 2009 15:12:51 -0700 (PDT) Received: from outbound-mail-113.bluehost.com (outbound-mail-113.bluehost.com [69.89.24.3]) by core3.amsl.com (Postfix) with SMTP id A0AE93A67D1 for ; Wed, 13 May 2009 15:12:51 -0700 (PDT) Received: (qmail 22761 invoked by uid 0); 13 May 2009 22:14:24 -0000 Received: from unknown (HELO box462.bluehost.com) (74.220.219.62) by outboundproxy3.bluehost.com with SMTP; 13 May 2009 22:14:24 -0000 DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=default; d=shockey.us; h=Received:From:To:References:In-Reply-To:Subject:Date:Message-ID:MIME-Version:Content-Type:Content-Transfer-Encoding:X-Mailer:Thread-Index:Content-Language:X-Identified-User; b=jo47mbStTNFZBsl4r+fTObNiTCMuuOTTnGj0TP2TNDn/EuYYq7V8I9vAWZ//yyU7O6m43zJyO6huZ088Vrcc58r7MQX1j3hWFBskaYrgh5Xvfxhs2xksSMXBje268C5c; Received: from pool-173-66-69-164.washdc.fios.verizon.net ([173.66.69.164] helo=rshockeyPC) by box462.bluehost.com with esmtpa (Exim 4.69) (envelope-from ) id 1M4MiV-0006mi-PF; Wed, 13 May 2009 16:14:24 -0600 From: "Richard Shockey" To: "'Daryl Malas'" , "'IETF ENUM WG'" References: <00c101c9c866$9acf5c30$d06e1490$@us> In-Reply-To: Date: Wed, 13 May 2009 18:14:01 -0400 Message-ID: <02b701c9d418$1fa3c560$5eeb5020$@us> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: AcmpUkn18LDs6jcbRDuU+5gveAaRQwZW8G/QAW3h/9ACuvWRJgAxe3yg Content-Language: en-us X-Identified-User: {3286:box462.bluehost.com:shockeyu:shockey.us} {sentby:smtp auth 173.66.69.164 authed with richard+shockey.us} Subject: Re: [Enum] WG: New Draft: Trunk Group Use in ENUM RESTART - Second request for guidence X-BeenThere: enum@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Enum Discussion List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 13 May 2009 22:12:59 -0000 No ..I wouldn't say that. This was always a very very specialized draft dealing with a very particular type of PSTN data and its obvious the WG members are off to other things. Of course some of us have had to deal with the Infrastructure ENUM issues ..but that is another sad story. Yes the liaison is coming. IMHO silence on this is consent and my strong advise to you is to go ahead and rewrite the document with all of the comments so far and submit it as a WG document. The chairs will have to approve that we'll come back to the list and see then if silence prevails we can kill the old draft and we'll just see what happens then. If not then you will have my personal support to submit it to the IESG as a individual submission. > -----Original Message----- > From: Daryl Malas [mailto:d.malas@cablelabs.com] > Sent: Tuesday, May 12, 2009 6:32 PM > To: Richard Shockey; 'IETF ENUM WG' > Subject: Re: [Enum] WG: New Draft: Trunk Group Use in ENUM RESTART - > Second request for guidence > > Richard, > > Well, I guess I will throw my hat in the ring. As an author of the > proposed > draft, I think this is a valuable draft for the industry. If I am the > only > one, then I guess the draft is irrelevant. > > Regards, > > Daryl > > > On 4/28/09 7:05 PM, "Richard Shockey" wrote: > > > Second call .. what is WG consensus here? > > > > This is not a silence is consent issue. It requires a form of > decision. > > > > (Chair hat off) I've made my personal sentiments clear. We all > thought this > > was a useful WG item. Some folks have come to us with a cleaner form > of > > dealing with the use case that does not require a formal enumservice > > registration. It has wide applicability. Better to create a BCP or > > Informational than let multiple implementations go off in all sorts > of non > > interoperable directions. > > > > What does the WG want to do or do you want the chairs to decide? We > are not > > going to have a meeting in Stockholm over this. > > > > > >> -----Original Message----- > >> From: enum-bounces@ietf.org [mailto:enum-bounces@ietf.org] On > Behalf > >> Of Richard Shockey > >> Sent: Tuesday, April 21, 2009 2:29 PM > >> To: 'Peter Koch'; 'IETF ENUM WG' > >> Subject: Re: [Enum] WG: New Draft: Trunk Group Use in ENUM RESTART > >> > >> > >> I'd like to take up where we left off on this subject and > determine > >> what the WG consensus is on dealing with this issue. > >> > >> There is consensus that this is a item we had on the WG plate that > has > >> real applicability to applications in use and clarification on how > these > >> parameters should be represented in ENUM queries is a "good > thing". > >> > >> The first question is then do we essentially adopt this new draft > as a > >> WG item and quickly move it forward? > >> > >> The second is as what Informational or BCP? > >> > >> > >>> I have no expertise on the subject matter, but would like to > share > >>> some observations on process: > >>> > >>> On Fri, Mar 06, 2009 at 02:22:03PM +0000, Lawrence Conroy wrote: > >>> > >>>> beware - *who* gets to decide if a WG draft is dead? > >>> > >>> usually that's a WG consensus, either explicitly or by lack of > >> motion > >>> as to > >>> be determined by the chairs. In this case however, it seems that > >> the > >>> WG > >>> (or those in the WG who actively follow the matter) have changed > >> their > >>> mind > >>> about the direction of the draft. Posting a new I-D was one way, > >> but > >>> if the > >>> WG consensus is that the solution proposed in > >>> "IANA Registration for an Enumservice Trunkgroup" is no longer > the > >>> right one > >>> and instead a parameter to the SIP URI, as proposed in Trunk > Group > >> Use > >>> in ENUM > >>> will do better, then WG consensus could just direct the editors > to > >> re- > >>> write > >>> accordingly. Now, it seems that the editors change on the fly, > >> too, > >>> but that's > >>> up to the chairs (well, and any new editors) anyway. > >>> > >>>> Also, why is putting this new stuff in the clutches of a sleeping > >>>> WG (or an inchoate one) going to make it any faster getting any > >> BCP > >>>> through the IETF/IESG process? Does anyone remember IPTEL? > >>> > >>> I am a bit nervous about "fast tracking" in the last minute and > the > >>> status of BCP. The former seldomly works out, but the current > >> work item > >>> needs to get off the WG's plate anyway. The latter doesn't seem > >> necessary, > >>> especially since we're about to re-classify all (or many of) > those > >>> Proposed Standards anyway. A purely Informational document would > >> do, and > >> is > >>> definitely more lightweight. The draft would be an Informational > >>> addendum to RFC 3764, which it needs to reference normatively. > >>> > >>> The draft itself, however, isn't really clear about the intended > >>> status > >>> "IANA Registration for an Enumservice Trunkgroup". This document > >> is a > >>> normative > >>> reference although it seems to have outlived its usefulness and > >>> actually the > >>> registration in there is kind of revoked. > >>> However, the "trunk" ENUM service doesn't yet appear in > >>> if my pattern > >> matching > >>> skills > >>> suffice. So, instead of pursuing the old draft and immediately > >>> revoking the > >>> registration (or declaring it a no go), the new (well, "revised") > >>> draft > >>> should just state the new intended method of using trunk groups > in > >>> ENUM > >>> and incorporate verbatim the relevant parts of the earlier draft > >>> (without > >>> suggesting there actually _is_ a valid ENUM servcie registration) > >> in > >>> an > >>> appendix. > >>> It wouldn't be the first time an IETF WG started an effort to do > >> FOO > >>> and the > >>> document ends with the title "Why not to FOO". > >>> > >>> I'm not sure I follow the rationale in the first paragraph of > >> section > >>> 1.2, > >>> it feels like it's superseded by the newly born 5483 -- > >>> congratulations, by > >>> the way. > >>> > > > > _______________________________________________ > > enum mailing list > > enum@ietf.org > > https://www.ietf.org/mailman/listinfo/enum > > > ----------------- > Daryl Malas > CableLabs > (o) +1 303 661 3302 > (f) +1 303 661 9199 > mailto:d.malas@cablelabs.com > From bernie@ietf.hoeneisen.ch Thu May 14 00:02:42 2009 Return-Path: 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 9F75F3A6B9A for ; Thu, 14 May 2009 00:02:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.557 X-Spam-Level: X-Spam-Status: No, score=-2.557 tagged_above=-999 required=5 tests=[AWL=0.042, BAYES_00=-2.599] 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 fFeA61OIC8-a for ; Thu, 14 May 2009 00:02:41 -0700 (PDT) Received: from softronics.hoeneisen.ch (softronics.hoeneisen.ch [62.2.86.178]) by core3.amsl.com (Postfix) with ESMTP id 061903A6B51 for ; Thu, 14 May 2009 00:02:40 -0700 (PDT) Received: from localhost ([127.0.0.1]) by softronics.hoeneisen.ch with esmtp (Exim 4.69) (envelope-from ) id 1M4Uz7-0001bJ-7M; Thu, 14 May 2009 09:04:05 +0200 Date: Thu, 14 May 2009 09:04:05 +0200 (CEST) From: Bernie Hoeneisen X-X-Sender: bhoeneis@softronics.hoeneisen.ch To: Richard Shockey In-Reply-To: <02b701c9d418$1fa3c560$5eeb5020$@us> Message-ID: References: <00c101c9c866$9acf5c30$d06e1490$@us> <02b701c9d418$1fa3c560$5eeb5020$@us> User-Agent: Alpine 2.00 (DEB 1167 2008-08-23) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-SA-Exim-Connect-IP: 127.0.0.1 X-SA-Exim-Mail-From: bernie@ietf.hoeneisen.ch X-SA-Exim-Scanned: No (on softronics.hoeneisen.ch); SAEximRunCond expanded to false Cc: 'IETF ENUM WG' , 'Daryl Malas' Subject: Re: [Enum] WG: New Draft: Trunk Group Use in ENUM RESTART - Second request for guidence X-BeenThere: enum@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Enum Discussion List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 14 May 2009 07:02:42 -0000 Hi Rich et al. On Wed, 13 May 2009, Richard Shockey wrote: > IMHO silence on this is consent I do disagree with you that silence on this is consent. On top of that many people have expressed their critical opinions earlier on this list. IMHO this draft should go forward outside the ENUM WG as we are shutting it down. cheers, Bernie > and my strong advise to you is to go ahead > and rewrite the document with all of the comments so far and submit it as a > WG document. The chairs will have to approve that we'll come back to the > list and see then if silence prevails we can kill the old draft and we'll > just see what happens then. If not then you will have my personal support to > submit it to the IESG as a individual submission. > >> -----Original Message----- >> From: Daryl Malas [mailto:d.malas@cablelabs.com] >> Sent: Tuesday, May 12, 2009 6:32 PM >> To: Richard Shockey; 'IETF ENUM WG' >> Subject: Re: [Enum] WG: New Draft: Trunk Group Use in ENUM RESTART - >> Second request for guidence >> >> Richard, >> >> Well, I guess I will throw my hat in the ring. As an author of the >> proposed >> draft, I think this is a valuable draft for the industry. If I am the >> only >> one, then I guess the draft is irrelevant. >> >> Regards, >> >> Daryl >> >> >> On 4/28/09 7:05 PM, "Richard Shockey" wrote: >> >> > Second call .. what is WG consensus here? >> > >> > This is not a silence is consent issue. It requires a form of >> decision. >> > >> > (Chair hat off) I've made my personal sentiments clear. We all >> thought this >> > was a useful WG item. Some folks have come to us with a cleaner form >> of >> > dealing with the use case that does not require a formal enumservice >> > registration. It has wide applicability. Better to create a BCP or >> > Informational than let multiple implementations go off in all sorts >> of non >> > interoperable directions. >> > >> > What does the WG want to do or do you want the chairs to decide? We >> are not >> > going to have a meeting in Stockholm over this. >> > >> > >> >> -----Original Message----- >> >> From: enum-bounces@ietf.org [mailto:enum-bounces@ietf.org] On >> Behalf >> >> Of Richard Shockey >> >> Sent: Tuesday, April 21, 2009 2:29 PM >> >> To: 'Peter Koch'; 'IETF ENUM WG' >> >> Subject: Re: [Enum] WG: New Draft: Trunk Group Use in ENUM RESTART >> >> >> >> >> >> I'd like to take up where we left off on this subject and >> determine >> >> what the WG consensus is on dealing with this issue. >> >> >> >> There is consensus that this is a item we had on the WG plate that >> has >> >> real applicability to applications in use and clarification on how >> these >> >> parameters should be represented in ENUM queries is a "good >> thing". >> >> >> >> The first question is then do we essentially adopt this new draft >> as a >> >> WG item and quickly move it forward? >> >> >> >> The second is as what Informational or BCP? >> >> >> >> >> >>> I have no expertise on the subject matter, but would like to >> share >> >>> some observations on process: >> >>> >> >>> On Fri, Mar 06, 2009 at 02:22:03PM +0000, Lawrence Conroy wrote: >> >>> >> >>>> beware - *who* gets to decide if a WG draft is dead? >> >>> >> >>> usually that's a WG consensus, either explicitly or by lack of >> >> motion >> >>> as to >> >>> be determined by the chairs. In this case however, it seems that >> >> the >> >>> WG >> >>> (or those in the WG who actively follow the matter) have changed >> >> their >> >>> mind >> >>> about the direction of the draft. Posting a new I-D was one way, >> >> but >> >>> if the >> >>> WG consensus is that the solution proposed in >> >>> "IANA Registration for an Enumservice Trunkgroup" is no longer >> the >> >>> right one >> >>> and instead a parameter to the SIP URI, as proposed in Trunk >> Group >> >> Use >> >>> in ENUM >> >>> will do better, then WG consensus could just direct the editors >> to >> >> re- >> >>> write >> >>> accordingly. Now, it seems that the editors change on the fly, >> >> too, >> >>> but that's >> >>> up to the chairs (well, and any new editors) anyway. >> >>> >> >>>> Also, why is putting this new stuff in the clutches of a sleeping >> >>>> WG (or an inchoate one) going to make it any faster getting any >> >> BCP >> >>>> through the IETF/IESG process? Does anyone remember IPTEL? >> >>> >> >>> I am a bit nervous about "fast tracking" in the last minute and >> the >> >>> status of BCP. The former seldomly works out, but the current >> >> work item >> >>> needs to get off the WG's plate anyway. The latter doesn't seem >> >> necessary, >> >>> especially since we're about to re-classify all (or many of) >> those >> >>> Proposed Standards anyway. A purely Informational document would >> >> do, and >> >> is >> >>> definitely more lightweight. The draft would be an Informational >> >>> addendum to RFC 3764, which it needs to reference normatively. >> >>> >> >>> The draft itself, however, isn't really clear about the intended >> >>> status >> >>> "IANA Registration for an Enumservice Trunkgroup". This document >> >> is a >> >>> normative >> >>> reference although it seems to have outlived its usefulness and >> >>> actually the >> >>> registration in there is kind of revoked. >> >>> However, the "trunk" ENUM service doesn't yet appear in >> >>> if my pattern >> >> matching >> >>> skills >> >>> suffice. So, instead of pursuing the old draft and immediately >> >>> revoking the >> >>> registration (or declaring it a no go), the new (well, "revised") >> >>> draft >> >>> should just state the new intended method of using trunk groups >> in >> >>> ENUM >> >>> and incorporate verbatim the relevant parts of the earlier draft >> >>> (without >> >>> suggesting there actually _is_ a valid ENUM servcie registration) >> >> in >> >>> an >> >>> appendix. >> >>> It wouldn't be the first time an IETF WG started an effort to do >> >> FOO >> >>> and the >> >>> document ends with the title "Why not to FOO". >> >>> >> >>> I'm not sure I follow the rationale in the first paragraph of >> >> section >> >>> 1.2, >> >>> it feels like it's superseded by the newly born 5483 -- >> >>> congratulations, by >> >>> the way. >> >>> >> > >> > _______________________________________________ >> > enum mailing list >> > enum@ietf.org >> > https://www.ietf.org/mailman/listinfo/enum >> >> >> ----------------- >> Daryl Malas >> CableLabs >> (o) +1 303 661 3302 >> (f) +1 303 661 9199 >> mailto:d.malas@cablelabs.com >> > > > _______________________________________________ > enum mailing list > enum@ietf.org > https://www.ietf.org/mailman/listinfo/enum > From pk@DENIC.DE Thu May 14 01:11:15 2009 Return-Path: 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 416AA3A6FD0 for ; Thu, 14 May 2009 01:11:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.974 X-Spam-Level: X-Spam-Status: No, score=-5.974 tagged_above=-999 required=5 tests=[AWL=0.275, BAYES_00=-2.599, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_MED=-4] 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 vi4DwZ53-Y-9 for ; Thu, 14 May 2009 01:11:14 -0700 (PDT) Received: from office.denic.de (gw-office.denic.de [81.91.160.182]) by core3.amsl.com (Postfix) with ESMTP id 487E33A6EFF for ; Thu, 14 May 2009 01:10:43 -0700 (PDT) Received: from unknown.office.denic.de ([10.122.65.182]) by office.denic.de with esmtp id 1M4W35-0001mQ-3j; Thu, 14 May 2009 10:12:15 +0200 Received: by unknown.office.denic.de (Postfix, from userid 501) id D3C5C178F22; Thu, 14 May 2009 10:12:14 +0200 (CEST) Date: Thu, 14 May 2009 10:12:13 +0200 From: Peter Koch To: IETF ENUM WG Message-ID: <20090514081213.GA8060@unknown.office.denic.de> Mail-Followup-To: IETF ENUM WG References: <00c101c9c866$9acf5c30$d06e1490$@us> <02b701c9d418$1fa3c560$5eeb5020$@us> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.4.2.1i Subject: Re: [Enum] WG: New Draft: Trunk Group Use in ENUM RESTART - Second request for guidence X-BeenThere: enum@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Enum Discussion List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 14 May 2009 08:11:15 -0000 On Thu, May 14, 2009 at 09:04:05AM +0200, Bernie Hoeneisen wrote: > I do disagree with you that silence on this is consent. On top of that > many people have expressed their critical opinions earlier on this list. I have to agree with Bernie here. For a formal adoption it makes sense to have at least some volunteers lined up to do the review, unless one is prepared to continue with the "silence is consent" approach. > IMHO this draft should go forward outside the ENUM WG as we are > shutting it down. Yes, but: draft-ietf-enum-trunkgroup-00.txt, although expired, still is on the WG's plate. So, I think the right questions to ask are 1) Is anybody but the authors/editors of the respective drafts believes the WG should say anything in this direction (trunk groups). [But see the "price tag" under (4)] 2) Do you agree to abandon the approach in draft-ietf-enum-trunkgroup-00.txt? 3) Is the content of draft-malas-enum-trunk-sip-00.txt a better start instead? 4) Is anybody willing to review draft-malas-enum-trunk-sip-00.txt? Then publish draft-malas-enum-trunk-sip-00.txt as draft-ietf-enum-trunkgroup-01.txt, changing the intended state to Informational. To start answering the question with the caveat already mentioned in , the registration proposed in draft-ietf-enum-trunkgroup-00.txt doesn't really look like an ENUM service. From that perspective, the approach proposed in draft-malas-enum-trunk-sip-00.txt appears more straight forward to me. However, I think the draft needs more review and it should be clearer on its core statement; right now it is structured so much as a counter proposal to draft-ietf-enum-trunkgroup-00.txt, so it doesn't really stand on its own feet -- which is fine for a "-00". In summary, I'd abstain from (1), answer yes to (2) and (3) and would do (4) as far as my non experience with the core subject matter allows. -Peter From bernie@ietf.hoeneisen.ch Thu May 14 01:27:02 2009 Return-Path: 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 369683A6D2D for ; Thu, 14 May 2009 01:27:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.561 X-Spam-Level: X-Spam-Status: No, score=-2.561 tagged_above=-999 required=5 tests=[AWL=0.038, BAYES_00=-2.599] 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 hf1Ena+N6Vi8 for ; Thu, 14 May 2009 01:27:01 -0700 (PDT) Received: from softronics.hoeneisen.ch (softronics.hoeneisen.ch [62.2.86.178]) by core3.amsl.com (Postfix) with ESMTP id 6E74F3A68BA for ; Thu, 14 May 2009 01:27:01 -0700 (PDT) Received: from localhost ([127.0.0.1]) by softronics.hoeneisen.ch with esmtp (Exim 4.69) (envelope-from ) id 1M4WIq-0001g0-WB; Thu, 14 May 2009 10:28:33 +0200 Date: Thu, 14 May 2009 10:28:32 +0200 (CEST) From: Bernie Hoeneisen X-X-Sender: bhoeneis@softronics.hoeneisen.ch To: Richard Shockey In-Reply-To: Message-ID: References: <00c101c9c866$9acf5c30$d06e1490$@us> <02b701c9d418$1fa3c560$5eeb5020$@us> User-Agent: Alpine 2.00 (DEB 1167 2008-08-23) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-SA-Exim-Connect-IP: 127.0.0.1 X-SA-Exim-Mail-From: bernie@ietf.hoeneisen.ch X-SA-Exim-Scanned: No (on softronics.hoeneisen.ch); SAEximRunCond expanded to false Cc: 'IETF ENUM WG' , 'Daryl Malas' Subject: Re: [Enum] WG: New Draft: Trunk Group Use in ENUM RESTART - Second request for guidence X-BeenThere: enum@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Enum Discussion List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 14 May 2009 08:27:02 -0000 Some addition to my earlier post: Recently a new WG DISPATCH has been established in the RAI area, exately for cases as this one. I suggest to divert this draft to DISPATCH and await guidance from there. In addition we should officially discontinue the work on the old variant. cheers, Bernie On Thu, 14 May 2009, Bernie Hoeneisen wrote: > Hi Rich et al. > > On Wed, 13 May 2009, Richard Shockey wrote: > >> IMHO silence on this is consent > > I do disagree with you that silence on this is consent. On top of that many > people have expressed their critical opinions earlier on this list. > > IMHO this draft should go forward outside the ENUM WG as we are shutting it > down. > > cheers, > Bernie > From alexander.mayrhofer@enum.at Thu May 14 01:35:00 2009 Return-Path: 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 79D703A6CB7 for ; Thu, 14 May 2009 01:35:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 2.563 X-Spam-Level: ** X-Spam-Status: No, score=2.563 tagged_above=-999 required=5 tests=[BAYES_40=-0.185, FH_HOST_EQ_D_D_D_D=0.765, HELO_MISMATCH_NET=0.611, HOST_EQ_STATICB=1.372] 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 QGu-pGam7taT for ; Thu, 14 May 2009 01:34:59 -0700 (PDT) Received: from kahua.nona.net (static.88-198-7-53.clients.your-server.de [88.198.7.53]) by core3.amsl.com (Postfix) with ESMTP id 9BECF3A6BFC for ; Thu, 14 May 2009 01:34:58 -0700 (PDT) Received: from [192.168.2.58] ([::ffff:218.208.119.2]) (AUTH: PLAIN axelm, TLS: TLSv1/SSLv3,256bits,AES256-SHA) by moana with esmtp; Thu, 14 May 2009 10:36:27 +0200 id 00045982.4A0BD80C.000043E7 Message-ID: <4A0BD7C8.5050903@enum.at> Date: Thu, 14 May 2009 10:35:20 +0200 From: Alexander Mayrhofer Organization: enum.at GmbH User-Agent: Thunderbird 2.0.0.21 (Windows/20090302) MIME-Version: 1.0 To: enum@ietf.org Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [Enum] WG: New Draft: Trunk Group Use in ENUM RESTART - Secondrequest for guidence X-BeenThere: enum@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Enum Discussion List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 14 May 2009 08:35:00 -0000 Richard, fellow WG members, I agree with Peter, as i think the real question is whether the WG want to continue pursue the draft-ietf-enum-trunkgroup ENUMservice or not. The question whether the group wants to adopt the draft-malas-enum-trunk-sip is seperate from that - but i like the way that Peter proposed. > 1) Is anybody but the authors/editors of the respective drafts believes the WG > should say anything in this direction (trunk groups). [But see the "price tag" > under (4)] I think it is somehow *related* to ENUM because of the Enumservice that we are trying to get rid. Otherwise, i don't see why it would fit into ENUM. For example, it might well fit into DISPATCH as well? > 2) Do you agree to abandon the approach in draft-ietf-enum-trunkgroup-00.txt? Yes > 3) Is the content of draft-malas-enum-trunk-sip-00.txt a better start instead? Yes > 4) Is anybody willing to review draft-malas-enum-trunk-sip-00.txt? If it becomes an ENUM WG document, i might have to, being the secretary of the ENUM WG. > Then publish draft-malas-enum-trunk-sip-00.txt as draft-ietf-enum-trunkgroup-01.txt, > changing the intended state to Informational. I would prefer if the WG concensus would be to remove draft-ietf-enum-trunkgroup from the WG "menu" entirely, and documenting the decision in draft-malas-enum-trunk-sip, but find a WG that suits better such SIP operational issues than the ENUM group. The solution that Peter proposed is also viable, if authors and chairs believe that's a faster way. I just don't think the WG should accept new work, given it's current status of being slowly move to the pathology department. Just to make clear: Content-wise, i definitely prefer the solution proposed in draft-malas-enum-trunk-sip. I'm just not entirely happy with the sloppy process. Alex From richard@shockey.us Thu May 14 06:34:48 2009 Return-Path: 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 BE3753A6C2B for ; Thu, 14 May 2009 06:34:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.876 X-Spam-Level: X-Spam-Status: No, score=-1.876 tagged_above=-999 required=5 tests=[AWL=0.389, BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334] 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 kFw0O6tYrKpr for ; Thu, 14 May 2009 06:34:47 -0700 (PDT) Received: from outbound-mail-101.bluehost.com (outbound-mail-101.bluehost.com [69.89.22.11]) by core3.amsl.com (Postfix) with SMTP id B65453A68DD for ; Thu, 14 May 2009 06:34:47 -0700 (PDT) Received: (qmail 15553 invoked by uid 0); 14 May 2009 13:36:20 -0000 Received: from unknown (HELO box462.bluehost.com) (74.220.219.62) by outboundproxy3.bluehost.com with SMTP; 14 May 2009 13:36:20 -0000 DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=default; d=shockey.us; h=Received:From:To:References:In-Reply-To:Subject:Date:Message-ID:MIME-Version:Content-Type:Content-Transfer-Encoding:X-Mailer:Thread-Index:Content-Language:X-Identified-User; b=EOw0bxhalDuj2xiOYX8GI/jQbHSI7nbWclhlIPM/QbNlbkQXAjOTPrTYQtr2xCzILBRkYP/D+rfdRQykIilqNHJQM65pkYt34mATLuEOIrdsfa26tTwplRoGzgJlyt8l; Received: from pool-173-66-69-164.washdc.fios.verizon.net ([173.66.69.164] helo=rshockeyPC) by box462.bluehost.com with esmtpa (Exim 4.69) (envelope-from ) id 1M4b6i-0005qm-AH; Thu, 14 May 2009 07:36:20 -0600 From: "Richard Shockey" To: "'Alexander Mayrhofer'" , References: <4A0BD7C8.5050903@enum.at> In-Reply-To: <4A0BD7C8.5050903@enum.at> Date: Thu, 14 May 2009 09:35:45 -0400 Message-ID: <017901c9d498$e31e6fb0$a95b4f10$@us> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: AcnUbxcNO9ZGiUOLQyODY7VhiyLbWAAKarEw Content-Language: en-us X-Identified-User: {3286:box462.bluehost.com:shockeyu:shockey.us} {sentby:smtp auth 173.66.69.164 authed with richard+shockey.us} Subject: Re: [Enum] WG: New Draft: Trunk Group Use in ENUM RESTART - Secondrequest for guidence X-BeenThere: enum@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Enum Discussion List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 14 May 2009 13:34:48 -0000 Well at least I got someone on the list to finally comment .. :-) Its not going into DISPATCH .it will never see the light of day. > -----Original Message----- > From: enum-bounces@ietf.org [mailto:enum-bounces@ietf.org] On Behalf > Of Alexander Mayrhofer > Sent: Thursday, May 14, 2009 4:35 AM > To: enum@ietf.org > Subject: Re: [Enum] WG: New Draft: Trunk Group Use in ENUM RESTART - > Secondrequest for guidence > > > Richard, fellow WG members, > > I agree with Peter, as i think the real question is whether the WG > want > to continue pursue the draft-ietf-enum-trunkgroup ENUMservice or not. > > The question whether the group wants to adopt the > draft-malas-enum-trunk-sip is seperate from that - but i like the way > that Peter proposed. > > > 1) Is anybody but the authors/editors of the respective drafts > believes the WG > > should say anything in this direction (trunk groups). [But see > the "price tag" > > under (4)] > > I think it is somehow *related* to ENUM because of the Enumservice > that > we are trying to get rid. Otherwise, i don't see why it would fit into > ENUM. For example, it might well fit into DISPATCH as well? > > > 2) Do you agree to abandon the approach in draft-ietf-enum- > trunkgroup-00.txt? > > Yes > > > 3) Is the content of draft-malas-enum-trunk-sip-00.txt a better > start instead? > > Yes > > > 4) Is anybody willing to review draft-malas-enum-trunk-sip-00.txt? > > If it becomes an ENUM WG document, i might have to, being the > secretary > of the ENUM WG. > > > Then publish draft-malas-enum-trunk-sip-00.txt as draft-ietf-enum- > trunkgroup-01.txt, > > changing the intended state to Informational. > > I would prefer if the WG concensus would be to remove > draft-ietf-enum-trunkgroup from the WG "menu" entirely, and > documenting > the decision in draft-malas-enum-trunk-sip, but find a WG that suits > better such SIP operational issues than the ENUM group. > > The solution that Peter proposed is also viable, if authors and chairs > believe that's a faster way. I just don't think the WG should accept > new > work, given it's current status of being slowly move to the pathology > department. > > Just to make clear: Content-wise, i definitely prefer the solution > proposed in draft-malas-enum-trunk-sip. I'm just not entirely happy > with > the sloppy process. > > Alex > > _______________________________________________ > enum mailing list > enum@ietf.org > https://www.ietf.org/mailman/listinfo/enum From richard@shockey.us Thu May 14 06:57:23 2009 Return-Path: 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 6E4073A6D2D for ; Thu, 14 May 2009 06:57:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.887 X-Spam-Level: X-Spam-Status: No, score=-2.887 tagged_above=-999 required=5 tests=[AWL=1.378, BAYES_00=-2.599, GB_I_LETTER=-2, IP_NOT_FRIENDLY=0.334] 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 M22pe8gBlKcp for ; Thu, 14 May 2009 06:57:22 -0700 (PDT) Received: from outbound-mail-121.bluehost.com (outbound-mail-121.bluehost.com [67.222.38.21]) by core3.amsl.com (Postfix) with SMTP id 394993A6C3F for ; Thu, 14 May 2009 06:57:22 -0700 (PDT) Received: (qmail 23469 invoked by uid 0); 14 May 2009 13:58:55 -0000 Received: from unknown (HELO box462.bluehost.com) (74.220.219.62) by outboundproxy4.bluehost.com with SMTP; 14 May 2009 13:58:55 -0000 DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=default; d=shockey.us; h=Received:From:To:References:In-Reply-To:Subject:Date:Message-ID:MIME-Version:Content-Type:Content-Transfer-Encoding:X-Mailer:Thread-Index:Content-Language:X-Identified-User; b=HyNaEIdkeE2FXx2lm5OV0qPbC1tfkPocaMRyvbW7S9I1Uw84aAnlbhnSuCZtzQ0+JkD62SQiJdT6El39fGLkTQFXDe5lozChFZiXQzFz6iKRrB7gfPqIYjpj9aBDMWj2; Received: from pool-173-66-69-164.washdc.fios.verizon.net ([173.66.69.164] helo=rshockeyPC) by box462.bluehost.com with esmtpa (Exim 4.69) (envelope-from ) id 1M4bSY-0003Ig-Aq; Thu, 14 May 2009 07:58:55 -0600 From: "Richard Shockey" To: "'Alexander Mayrhofer'" , References: <4A0BD7C8.5050903@enum.at> In-Reply-To: <4A0BD7C8.5050903@enum.at> Date: Thu, 14 May 2009 09:58:18 -0400 Message-ID: <01a101c9d49c$0a510b80$1ef32280$@us> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: AcnUbxcNO9ZGiUOLQyODY7VhiyLbWAAKgBYA Content-Language: en-us X-Identified-User: {3286:box462.bluehost.com:shockeyu:shockey.us} {sentby:smtp auth 173.66.69.164 authed with richard+shockey.us} Subject: Re: [Enum] WG: New Draft: Trunk Group Use in ENUM RESTART - Secondrequest for guidence X-BeenThere: enum@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Enum Discussion List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 14 May 2009 13:57:23 -0000 > To: enum@ietf.org > Subject: Re: [Enum] WG: New Draft: Trunk Group Use in ENUM RESTART - > Secondrequest for guidence > > > Richard, fellow WG members, > > I agree with Peter, as i think the real question is whether the WG > want > to continue pursue the draft-ietf-enum-trunkgroup ENUMservice or not. Well my original intent was to 'clear the queue' so to speak and I'm personally convinced this is an important draft to document. Its starting to deploy now. I apologize if I had to 'shake the tree' so to speak to get someone to finally answer the question on what to do. > The question whether the group wants to adopt the > draft-malas-enum-trunk-sip is seperate from that - but i like the way > that Peter proposed. Its fine with me as well. > > > 1) Is anybody but the authors/editors of the respective drafts > believes the WG > > should say anything in this direction (trunk groups). [But see > the "price tag" > > under (4)] > > I think it is somehow *related* to ENUM because of the Enumservice > that we are trying to get rid. Otherwise, i don't see why it would fit into > ENUM. For example, it might well fit into DISPATCH as well? IMHO it's a individual draft or a ENUM WG draft I would not suggest to the authors to go down the DISPATCH path. I currently have limited confidence in the way DISPATCH will operate until proven otherwise. I'm personally pretty disgusted actually. You have seen SIPPING flipped to DISPATCH. So whats the difference except you have new chairs and not really new chairs at that. > > > 2) Do you agree to abandon the approach in draft-ietf-enum- > trunkgroup-00.txt? > > Yes As the co-author yes. As for Informational vs BCP I can live with informational but I'll let Daryl comment on that. > > > 3) Is the content of draft-malas-enum-trunk-sip-00.txt a better > start instead? > > Yes Yes Either would work but this malas 00 IMHO is a much simpler approach and would work equally as well. The document needs to be rewritten but that is a wordsmithing issue. > > > 4) Is anybody willing to review draft-malas-enum-trunk-sip-00.txt? > > If it becomes an ENUM WG document, i might have to, being the > secretary > of the ENUM WG. > > > Then publish draft-malas-enum-trunk-sip-00.txt as draft-ietf-enum- > trunkgroup-01.txt, > > changing the intended state to Informational. > > I would prefer if the WG concensus would be to remove > draft-ietf-enum-trunkgroup from the WG "menu" entirely, and > documenting the decision in draft-malas-enum-trunk-sip, but find a WG that suits > better such SIP operational issues than the ENUM group. Not going to happen. SPEERMINT wont take it and it the new RAI org is IMHO just a reshuffling of the deck chairs. Pick your ship. Its here or individual submission. > > The solution that Peter proposed is also viable, if authors and chairs > believe that's a faster way. I just don't think the WG should accept > new work, given it's current status of being slowly move to the pathology > department. IMHO finishing the work here with a single document the right way to go. Lets clear the issue off the table. I don't like pushing off work to some other WG that we should have completed ourselves. That's not right. We agreed to do this in the first place, lets finish it. > > Just to make clear: Content-wise, i definitely prefer the solution > proposed in draft-malas-enum-trunk-sip. I'm just not entirely happy > with the sloppy process. Well it got caught is the process. It nothing new for WG's. You want bad process I can talk about my current discussions with the IAB over the liaison letter to SG2 over Infrastructure ENUM. > > Alex > > _______________________________________________ > enum mailing list > enum@ietf.org > https://www.ietf.org/mailman/listinfo/enum From lconroy@insensate.co.uk Thu May 14 10:03:07 2009 Return-Path: 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 3073C28C21B for ; Thu, 14 May 2009 10:03:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599] 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 JUFyGp7NO6Fu for ; Thu, 14 May 2009 10:03:05 -0700 (PDT) Received: from insensate.co.uk (ghost.insensate.co.uk [213.152.49.121]) by core3.amsl.com (Postfix) with ESMTP id F13A928C2D9 for ; Thu, 14 May 2009 10:01:28 -0700 (PDT) Received: from [127.0.0.1] (localhost [127.0.0.1]) by insensate.co.uk (Postfix) with ESMTP id C154C11E611; Thu, 14 May 2009 18:03:45 +0100 (BST) Message-Id: <5AE93C14-AEC1-4811-A55C-C05753AE5955@insensate.co.uk> From: Lawrence Conroy To: Richard Shockey In-Reply-To: <02b701c9d418$1fa3c560$5eeb5020$@us> Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v930.3) Date: Thu, 14 May 2009 18:02:59 +0100 References: <00c101c9c866$9acf5c30$d06e1490$@us> <02b701c9d418$1fa3c560$5eeb5020$@us> X-Mailer: Apple Mail (2.930.3) Cc: 'IETF ENUM WG' , 'Daryl Malas' Subject: Re: [Enum] WG: New Draft: Trunk Group Use in ENUM RESTART - Second request for guidence X-BeenThere: enum@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Enum Discussion List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 14 May 2009 17:03:07 -0000 Hi Richard, folks, Maybe I wasn't clear in my March 3rd mail; IMHO, the original idea using a separate Enumservice is irrecoverable. I join the crowd asking the WG chairs to declare it dead. From experience of Experiences in the IESG, this *new* item should be Informational, NOT BCP. Customers can pull this out the final doc as a requirement regardless of its track. I asked this in March, and I repeat - why isn't this a candidate for Individual or AD-sponsored? all the best, Lawrence On 13 May 2009, at 23:14, Richard Shockey wrote: > No ..I wouldn't say that. > > This was always a very very specialized draft dealing with a very > particular > type of PSTN data and its obvious the WG members are off to other > things. > > Of course some of us have had to deal with the Infrastructure ENUM > issues > ..but that is another sad story. Yes the liaison is coming. > > IMHO silence on this is consent and my strong advise to you is to go > ahead > and rewrite the document with all of the comments so far and submit > it as a > WG document. The chairs will have to approve that we'll come back to > the > list and see then if silence prevails we can kill the old draft and > we'll > just see what happens then. If not then you will have my personal > support to > submit it to the IESG as a individual submission. > >> -----Original Message----- >> From: Daryl Malas [mailto:d.malas@cablelabs.com] >> Sent: Tuesday, May 12, 2009 6:32 PM >> To: Richard Shockey; 'IETF ENUM WG' >> Subject: Re: [Enum] WG: New Draft: Trunk Group Use in ENUM RESTART - >> Second request for guidence >> >> Richard, >> >> Well, I guess I will throw my hat in the ring. As an author of the >> proposed >> draft, I think this is a valuable draft for the industry. If I am >> the >> only >> one, then I guess the draft is irrelevant. >> >> Regards, >> >> Daryl >> >> >> On 4/28/09 7:05 PM, "Richard Shockey" wrote: >> >>> Second call .. what is WG consensus here? >>> >>> This is not a silence is consent issue. It requires a form of >> decision. >>> >>> (Chair hat off) I've made my personal sentiments clear. We all >> thought this >>> was a useful WG item. Some folks have come to us with a cleaner form >> of >>> dealing with the use case that does not require a formal enumservice >>> registration. It has wide applicability. Better to create a BCP or >>> Informational than let multiple implementations go off in all sorts >> of non >>> interoperable directions. >>> >>> What does the WG want to do or do you want the chairs to decide? We >> are not >>> going to have a meeting in Stockholm over this. >>> >>> >>>> -----Original Message----- >>>> From: enum-bounces@ietf.org [mailto:enum-bounces@ietf.org] On >> Behalf >>>> Of Richard Shockey >>>> Sent: Tuesday, April 21, 2009 2:29 PM >>>> To: 'Peter Koch'; 'IETF ENUM WG' >>>> Subject: Re: [Enum] WG: New Draft: Trunk Group Use in ENUM RESTART >>>> >>>> >>>> I'd like to take up where we left off on this subject and >> determine >>>> what the WG consensus is on dealing with this issue. >>>> >>>> There is consensus that this is a item we had on the WG plate that >> has >>>> real applicability to applications in use and clarification on how >> these >>>> parameters should be represented in ENUM queries is a "good >> thing". >>>> >>>> The first question is then do we essentially adopt this new draft >> as a >>>> WG item and quickly move it forward? >>>> >>>> The second is as what Informational or BCP? >>>> >>>> >>>>> I have no expertise on the subject matter, but would like to >> share >>>>> some observations on process: >>>>> >>>>> On Fri, Mar 06, 2009 at 02:22:03PM +0000, Lawrence Conroy wrote: >>>>> >>>>>> beware - *who* gets to decide if a WG draft is dead? >>>>> >>>>> usually that's a WG consensus, either explicitly or by lack of >>>> motion >>>>> as to >>>>> be determined by the chairs. In this case however, it seems that >>>> the >>>>> WG >>>>> (or those in the WG who actively follow the matter) have changed >>>> their >>>>> mind >>>>> about the direction of the draft. Posting a new I-D was one way, >>>> but >>>>> if the >>>>> WG consensus is that the solution proposed in >>>>> "IANA Registration for an Enumservice Trunkgroup" is no longer >> the >>>>> right one >>>>> and instead a parameter to the SIP URI, as proposed in Trunk >> Group >>>> Use >>>>> in ENUM >>>>> will do better, then WG consensus could just direct the editors >> to >>>> re- >>>>> write >>>>> accordingly. Now, it seems that the editors change on the fly, >>>> too, >>>>> but that's >>>>> up to the chairs (well, and any new editors) anyway. >>>>> >>>>>> Also, why is putting this new stuff in the clutches of a sleeping >>>>>> WG (or an inchoate one) going to make it any faster getting any >>>> BCP >>>>>> through the IETF/IESG process? Does anyone remember IPTEL? >>>>> >>>>> I am a bit nervous about "fast tracking" in the last minute and >> the >>>>> status of BCP. The former seldomly works out, but the current >>>> work item >>>>> needs to get off the WG's plate anyway. The latter doesn't seem >>>> necessary, >>>>> especially since we're about to re-classify all (or many of) >> those >>>>> Proposed Standards anyway. A purely Informational document would >>>> do, and >>>> is >>>>> definitely more lightweight. The draft would be an Informational >>>>> addendum to RFC 3764, which it needs to reference normatively. >>>>> >>>>> The draft itself, however, isn't really clear about the intended >>>>> status >>>>> "IANA Registration for an Enumservice Trunkgroup". This document >>>> is a >>>>> normative >>>>> reference although it seems to have outlived its usefulness and >>>>> actually the >>>>> registration in there is kind of revoked. >>>>> However, the "trunk" ENUM service doesn't yet appear in >>>>> if my pattern >>>> matching >>>>> skills >>>>> suffice. So, instead of pursuing the old draft and immediately >>>>> revoking the >>>>> registration (or declaring it a no go), the new (well, "revised") >>>>> draft >>>>> should just state the new intended method of using trunk groups >> in >>>>> ENUM >>>>> and incorporate verbatim the relevant parts of the earlier draft >>>>> (without >>>>> suggesting there actually _is_ a valid ENUM servcie registration) >>>> in >>>>> an >>>>> appendix. >>>>> It wouldn't be the first time an IETF WG started an effort to do >>>> FOO >>>>> and the >>>>> document ends with the title "Why not to FOO". >>>>> >>>>> I'm not sure I follow the rationale in the first paragraph of >>>> section >>>>> 1.2, >>>>> it feels like it's superseded by the newly born 5483 -- >>>>> congratulations, by >>>>> the way. >>>>> >>> >>> _______________________________________________ >>> enum mailing list >>> enum@ietf.org >>> https://www.ietf.org/mailman/listinfo/enum >> >> >> ----------------- >> Daryl Malas >> CableLabs >> (o) +1 303 661 3302 >> (f) +1 303 661 9199 >> mailto:d.malas@cablelabs.com >> > > > _______________________________________________ > enum mailing list > enum@ietf.org > https://www.ietf.org/mailman/listinfo/enum From richard@shockey.us Thu May 14 14:41:45 2009 Return-Path: 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 CC64A28C2D0 for ; Thu, 14 May 2009 14:41:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.925 X-Spam-Level: X-Spam-Status: No, score=-1.925 tagged_above=-999 required=5 tests=[AWL=0.340, BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334] 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 dhx630CBBYWr for ; Thu, 14 May 2009 14:41:44 -0700 (PDT) Received: from outbound-mail-125.bluehost.com (outbound-mail-125.bluehost.com [67.222.38.25]) by core3.amsl.com (Postfix) with SMTP id 6E3A728C313 for ; Thu, 14 May 2009 14:40:57 -0700 (PDT) Received: (qmail 30853 invoked by uid 0); 14 May 2009 21:42:30 -0000 Received: from unknown (HELO box462.bluehost.com) (74.220.219.62) by outboundproxy4.bluehost.com with SMTP; 14 May 2009 21:42:30 -0000 DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=default; d=shockey.us; h=Received:From:To:References:In-Reply-To:Subject:Date:Message-ID:MIME-Version:Content-Type:Content-Transfer-Encoding:X-Mailer:Thread-Index:Content-Language:X-Identified-User; b=Q+GFT6g2/xX2aFwO1SVjSdLYaClKcbnB8a5fh0wpJ8jrZ/j8SfW+aoIpR2lmroSPlMpRNK+jS5TbRlibOq/AgO6SzNDOV7oECvsIa5VsupqKlmDZRx7sATRNejkMGAFa; Received: from pool-173-66-69-164.washdc.fios.verizon.net ([173.66.69.164] helo=rshockeyPC) by box462.bluehost.com with esmtpa (Exim 4.69) (envelope-from ) id 1M4ihC-0002kl-1f; Thu, 14 May 2009 15:42:30 -0600 From: "Richard Shockey" To: "'Lawrence Conroy'" , References: <00c101c9c866$9acf5c30$d06e1490$@us> <02b701c9d418$1fa3c560$5eeb5020$@us> <97674A36-2672-4D32-9147-89CCE899571F@insensate.co.uk> In-Reply-To: <97674A36-2672-4D32-9147-89CCE899571F@insensate.co.uk> Date: Thu, 14 May 2009 17:42:27 -0400 Message-ID: <00e601c9d4dc$e146b190$a3d414b0$@us> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: AcnUtEomqiR+L9G/QrWxSA3V45l16gAJ5ZeA Content-Language: en-us X-Identified-User: {3286:box462.bluehost.com:shockeyu:shockey.us} {sentby:smtp auth 173.66.69.164 authed with richard+shockey.us} Subject: Re: [Enum] WG: New Draft: Trunk Group Use in ENUM RESTART - Second request for guidence X-BeenThere: enum@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Enum Discussion List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 14 May 2009 21:41:45 -0000 > > Hi Richard, folks, > Maybe I wasn't clear in my March 3rd mail; IMHO, the original idea > using a separate Enumservice is irrecoverable. > I join the crowd asking the WG chairs to declare it dead. OK ..its dead. Let me find the pearl handled revolver. > > From experience of Experiences in the IESG, this *new* item should be > Informational, NOT BCP. Customers can pull this out the final doc as a requirement regardless > of its track. Ultimately I don't have a problem with Informational though technically I think it falls under the sort of draft that is ultimately a BCP but I don't want to belabor the point. What is important is there is documentation on this particular type of usage or operators and vendors will attempt to implement all sorts of silly things. > > I asked this in March, and I repeat - why isn't this a candidate for > Individual or AD-sponsored? Because it was a WG item to begin with and IMHO we should not, to use a US colloquialism, be "buck-passers" as in the "buck stops here". > > all the best, > Lawrence > > On 13 May 2009, at 23:14, Richard Shockey wrote: > > No ..I wouldn't say that. > > > > This was always a very very specialized draft dealing with a very > > particular > > type of PSTN data and its obvious the WG members are off to other > > things. > > > > Of course some of us have had to deal with the Infrastructure ENUM > > issues > > ..but that is another sad story. Yes the liaison is coming. > > > > IMHO silence on this is consent and my strong advise to you is to go > > ahead > > and rewrite the document with all of the comments so far and submit > > it as a > > WG document. The chairs will have to approve that we'll come back to > > the > > list and see then if silence prevails we can kill the old draft and > > we'll > > just see what happens then. If not then you will have my personal > > support to > > submit it to the IESG as a individual submission. > > > >> -----Original Message----- > >> From: Daryl Malas [mailto:d.malas@cablelabs.com] > >> Sent: Tuesday, May 12, 2009 6:32 PM > >> To: Richard Shockey; 'IETF ENUM WG' > >> Subject: Re: [Enum] WG: New Draft: Trunk Group Use in ENUM RESTART > - > >> Second request for guidence > >> > >> Richard, > >> > >> Well, I guess I will throw my hat in the ring. As an author of the > >> proposed > >> draft, I think this is a valuable draft for the industry. If I am > >> the > >> only > >> one, then I guess the draft is irrelevant. > >> > >> Regards, > >> > >> Daryl > >> > >> > >> On 4/28/09 7:05 PM, "Richard Shockey" wrote: > >> > >>> Second call .. what is WG consensus here? > >>> > >>> This is not a silence is consent issue. It requires a form of > >> decision. > >>> > >>> (Chair hat off) I've made my personal sentiments clear. We all > >> thought this > >>> was a useful WG item. Some folks have come to us with a cleaner > form > >> of > >>> dealing with the use case that does not require a formal > enumservice > >>> registration. It has wide applicability. Better to create a BCP or > >>> Informational than let multiple implementations go off in all > sorts > >> of non > >>> interoperable directions. > >>> > >>> What does the WG want to do or do you want the chairs to decide? > We > >> are not > >>> going to have a meeting in Stockholm over this. > >>> > >>> > >>>> -----Original Message----- > >>>> From: enum-bounces@ietf.org [mailto:enum-bounces@ietf.org] On > >> Behalf > >>>> Of Richard Shockey > >>>> Sent: Tuesday, April 21, 2009 2:29 PM > >>>> To: 'Peter Koch'; 'IETF ENUM WG' > >>>> Subject: Re: [Enum] WG: New Draft: Trunk Group Use in ENUM > RESTART > >>>> > >>>> > >>>> I'd like to take up where we left off on this subject and > >> determine > >>>> what the WG consensus is on dealing with this issue. > >>>> > >>>> There is consensus that this is a item we had on the WG plate > that > >> has > >>>> real applicability to applications in use and clarification on > how > >> these > >>>> parameters should be represented in ENUM queries is a "good > >> thing". > >>>> > >>>> The first question is then do we essentially adopt this new draft > >> as a > >>>> WG item and quickly move it forward? > >>>> > >>>> The second is as what Informational or BCP? > >>>> > >>>> > >>>>> I have no expertise on the subject matter, but would like to > >> share > >>>>> some observations on process: > >>>>> > >>>>> On Fri, Mar 06, 2009 at 02:22:03PM +0000, Lawrence Conroy wrote: > >>>>> > >>>>>> beware - *who* gets to decide if a WG draft is dead? > >>>>> > >>>>> usually that's a WG consensus, either explicitly or by lack of > >>>> motion > >>>>> as to > >>>>> be determined by the chairs. In this case however, it seems > that > >>>> the > >>>>> WG > >>>>> (or those in the WG who actively follow the matter) have changed > >>>> their > >>>>> mind > >>>>> about the direction of the draft. Posting a new I-D was one > way, > >>>> but > >>>>> if the > >>>>> WG consensus is that the solution proposed in > >>>>> "IANA Registration for an Enumservice Trunkgroup" is no longer > >> the > >>>>> right one > >>>>> and instead a parameter to the SIP URI, as proposed in Trunk > >> Group > >>>> Use > >>>>> in ENUM > >>>>> will do better, then WG consensus could just direct the editors > >> to > >>>> re- > >>>>> write > >>>>> accordingly. Now, it seems that the editors change on the fly, > >>>> too, > >>>>> but that's > >>>>> up to the chairs (well, and any new editors) anyway. > >>>>> > >>>>>> Also, why is putting this new stuff in the clutches of a > sleeping > >>>>>> WG (or an inchoate one) going to make it any faster getting any > >>>> BCP > >>>>>> through the IETF/IESG process? Does anyone remember IPTEL? > >>>>> > >>>>> I am a bit nervous about "fast tracking" in the last minute and > >> the > >>>>> status of BCP. The former seldomly works out, but the current > >>>> work item > >>>>> needs to get off the WG's plate anyway. The latter doesn't seem > >>>> necessary, > >>>>> especially since we're about to re-classify all (or many of) > >> those > >>>>> Proposed Standards anyway. A purely Informational document > would > >>>> do, and > >>>> is > >>>>> definitely more lightweight. The draft would be an > Informational > >>>>> addendum to RFC 3764, which it needs to reference normatively. > >>>>> > >>>>> The draft itself, however, isn't really clear about the intended > >>>>> status > >>>>> "IANA Registration for an Enumservice Trunkgroup". This > document > >>>> is a > >>>>> normative > >>>>> reference although it seems to have outlived its usefulness and > >>>>> actually the > >>>>> registration in there is kind of revoked. > >>>>> However, the "trunk" ENUM service doesn't yet appear in > >>>>> if my pattern > >>>> matching > >>>>> skills > >>>>> suffice. So, instead of pursuing the old draft and immediately > >>>>> revoking the > >>>>> registration (or declaring it a no go), the new (well, > "revised") > >>>>> draft > >>>>> should just state the new intended method of using trunk groups > >> in > >>>>> ENUM > >>>>> and incorporate verbatim the relevant parts of the earlier draft > >>>>> (without > >>>>> suggesting there actually _is_ a valid ENUM servcie > registration) > >>>> in > >>>>> an > >>>>> appendix. > >>>>> It wouldn't be the first time an IETF WG started an effort to do > >>>> FOO > >>>>> and the > >>>>> document ends with the title "Why not to FOO". > >>>>> > >>>>> I'm not sure I follow the rationale in the first paragraph of > >>>> section > >>>>> 1.2, > >>>>> it feels like it's superseded by the newly born 5483 -- > >>>>> congratulations, by > >>>>> the way. > >>>>> > >>> > >>> _______________________________________________ > >>> enum mailing list > >>> enum@ietf.org > >>> https://www.ietf.org/mailman/listinfo/enum > >> > >> > >> ----------------- > >> Daryl Malas > >> CableLabs > >> (o) +1 303 661 3302 > >> (f) +1 303 661 9199 > >> mailto:d.malas@cablelabs.com > >> > > > > > > _______________________________________________ > > enum mailing list > > enum@ietf.org > > https://www.ietf.org/mailman/listinfo/enum From D.Malas@cablelabs.com Fri May 15 10:12:48 2009 Return-Path: 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 11CC23A6C55 for ; Fri, 15 May 2009 10:12:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.357 X-Spam-Level: X-Spam-Status: No, score=-1.357 tagged_above=-999 required=5 tests=[AWL=1.106, BAYES_00=-2.599, GB_I_LETTER=-2, HELO_EQ_MODEMCABLE=0.768, HOST_EQ_MODEMCABLE=1.368] 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 ZaE+kDTZ6BAh for ; Fri, 15 May 2009 10:12:47 -0700 (PDT) Received: from ondar.cablelabs.com (ondar.cablelabs.com [192.160.73.61]) by core3.amsl.com (Postfix) with ESMTP id 1184E3A6981 for ; Fri, 15 May 2009 10:12:47 -0700 (PDT) Received: from kyzyl.cablelabs.com (kyzyl [10.253.0.7]) by ondar.cablelabs.com (8.14.3/8.14.3) with ESMTP id n4FHED8r014276; Fri, 15 May 2009 11:14:13 -0600 Received: from srvxchg3.cablelabs.com (10.5.0.25) by kyzyl.cablelabs.com (F-Secure/fsigk_smtp/511/kyzyl.cablelabs.com); Fri, 15 May 2009 11:14:13 -0700 (MST) X-Virus-Status: clean(F-Secure/fsigk_smtp/511/kyzyl.cablelabs.com) Received: from 10.4.10.173 ([10.4.10.173]) by srvxchg3.cablelabs.com ([10.5.0.25]) via Exchange Front-End Server webmail.cablelabs.com ([10.253.0.8]) with Microsoft Exchange Server HTTP-DAV ; Fri, 15 May 2009 17:14:13 +0000 User-Agent: Microsoft-Entourage/12.17.0.090302 Date: Fri, 15 May 2009 11:14:12 -0600 From: Daryl Malas To: Richard Shockey , "'Alexander Mayrhofer'" , , Message-ID: Thread-Topic: [Enum] WG: New Draft: Trunk Group Use in ENUM RESTART - Secondrequest for guidence Thread-Index: AcnUbxcNO9ZGiUOLQyODY7VhiyLbWAAKgBYAADneX6Y= In-Reply-To: <01a101c9d49c$0a510b80$1ef32280$@us> Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit X-Approved: ondar Subject: Re: [Enum] WG: New Draft: Trunk Group Use in ENUM RESTART - Secondrequest for guidence X-BeenThere: enum@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Enum Discussion List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 15 May 2009 17:12:48 -0000 All, I personally think it should be considered as a BCP. The main purpose is to not simply "suggest" the use of the parameters in the SIP URI NAPTR, but rather to say "it really, really should be done this way. In fact, if you do not do it this way, then you will likely be out of compatibility with most implementations." I think this is the best way to ensure industry consistency. This being said, if there is consensus to push it forward as Informational, it is better to be documented than not at all, in my opinion. Don, you commented before on this draft, do you have a perspective on the value of this draft moving forward relative to the discussion? Regards, Daryl On 5/14/09 7:58 AM, "Richard Shockey" wrote: > >> To: enum@ietf.org >> Subject: Re: [Enum] WG: New Draft: Trunk Group Use in ENUM RESTART - >> Secondrequest for guidence >> >> >> Richard, fellow WG members, >> >> I agree with Peter, as i think the real question is whether the WG >> want >> to continue pursue the draft-ietf-enum-trunkgroup ENUMservice or not. > > Well my original intent was to 'clear the queue' so to speak and I'm > personally convinced this is an important draft to document. Its starting to > deploy now. I apologize if I had to 'shake the tree' so to speak to get > someone to finally answer the question on what to do. > >> The question whether the group wants to adopt the >> draft-malas-enum-trunk-sip is seperate from that - but i like the way >> that Peter proposed. > > Its fine with me as well. > >> >>> 1) Is anybody but the authors/editors of the respective drafts >> believes the WG >>> should say anything in this direction (trunk groups). [But see >> the "price tag" >>> under (4)] >> >> I think it is somehow *related* to ENUM because of the Enumservice >> that we are trying to get rid. Otherwise, i don't see why it would fit > into >> ENUM. For example, it might well fit into DISPATCH as well? > > IMHO it's a individual draft or a ENUM WG draft I would not suggest to the > authors to go down the DISPATCH path. I currently have limited confidence in > the way DISPATCH will operate until proven otherwise. I'm personally pretty > disgusted actually. You have seen SIPPING flipped to DISPATCH. So whats the > difference except you have new chairs and not really new chairs at that. > >> >>> 2) Do you agree to abandon the approach in draft-ietf-enum- >> trunkgroup-00.txt? >> >> Yes > > As the co-author yes. As for Informational vs BCP I can live with > informational but I'll let Daryl comment on that. > >> >>> 3) Is the content of draft-malas-enum-trunk-sip-00.txt a better >> start instead? >> >> Yes > > Yes Either would work but this malas 00 IMHO is a much simpler approach and > would work equally as well. The document needs to be rewritten but that is a > wordsmithing issue. > >> >>> 4) Is anybody willing to review draft-malas-enum-trunk-sip-00.txt? >> >> If it becomes an ENUM WG document, i might have to, being the >> secretary >> of the ENUM WG. >> >>> Then publish draft-malas-enum-trunk-sip-00.txt as draft-ietf-enum- >> trunkgroup-01.txt, >>> changing the intended state to Informational. >> >> I would prefer if the WG concensus would be to remove >> draft-ietf-enum-trunkgroup from the WG "menu" entirely, and >> documenting the decision in draft-malas-enum-trunk-sip, but find a WG > that suits >> better such SIP operational issues than the ENUM group. > > Not going to happen. SPEERMINT wont take it and it the new RAI org is IMHO > just a reshuffling of the deck chairs. Pick your ship. > > Its here or individual submission. > > >> >> The solution that Peter proposed is also viable, if authors and chairs >> believe that's a faster way. I just don't think the WG should accept >> new work, given it's current status of being slowly move to the > pathology >> department. > > IMHO finishing the work here with a single document the right way to go. > Lets clear the issue off the table. I don't like pushing off work to some > other WG that we should have completed ourselves. That's not right. We > agreed to do this in the first place, lets finish it. > > >> >> Just to make clear: Content-wise, i definitely prefer the solution >> proposed in draft-malas-enum-trunk-sip. I'm just not entirely happy >> with the sloppy process. > > > Well it got caught is the process. It nothing new for WG's. You want bad > process I can talk about my current discussions with the IAB over the > liaison letter to SG2 over Infrastructure ENUM. > >> >> Alex >> >> _______________________________________________ >> enum mailing list >> enum@ietf.org >> https://www.ietf.org/mailman/listinfo/enum > > _______________________________________________ > enum mailing list > enum@ietf.org > https://www.ietf.org/mailman/listinfo/enum ----------------- Daryl Malas CableLabs (o) +1 303 661 3302 (f) +1 303 661 9199 mailto:d.malas@cablelabs.com From DTroshynski@acmepacket.com Thu May 21 18:25:38 2009 Return-Path: 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 9BAE43A6CE0 for ; Thu, 21 May 2009 18:25:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.599 X-Spam-Level: X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[AWL=1.000, BAYES_00=-2.599, GB_I_LETTER=-2] 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 jf+DaS24M8vT for ; Thu, 21 May 2009 18:25:37 -0700 (PDT) Received: from etmail.acmepacket.com (etmail.acmepacket.com [216.41.24.6]) by core3.amsl.com (Postfix) with ESMTP id DBC6D3A6CC9 for ; Thu, 21 May 2009 18:25:36 -0700 (PDT) Received: from mail.acmepacket.com (216.41.24.7) by etmail.acmepacket.com (216.41.24.6) with Microsoft SMTP Server (TLS) id 8.1.340.0; Thu, 21 May 2009 21:26:42 -0400 Received: from mail.acmepacket.com ([127.0.0.1]) by mail ([127.0.0.1]) with mapi; Thu, 21 May 2009 21:26:42 -0400 From: Don Troshynski To: Daryl Malas , Richard Shockey , 'Alexander Mayrhofer' , "enum@ietf.org" Date: Thu, 21 May 2009 21:26:58 -0400 Thread-Topic: [Enum] WG: New Draft: Trunk Group Use in ENUM RESTART - Secondrequest for guidence Thread-Index: AcnUbxcNO9ZGiUOLQyODY7VhiyLbWAAKgBYAADneX6YBPoILwA== Message-ID: References: <01a101c9d49c$0a510b80$1ef32280$@us> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [Enum] WG: New Draft: Trunk Group Use in ENUM RESTART - Secondrequest for guidence X-BeenThere: enum@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Enum Discussion List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 22 May 2009 01:25:38 -0000 All, After some thought, I think there is value in maneuvering this document tow= ard a BCP. It will take some work -- in my opinion, the debate involving a= draft service type should be removed. There is room to consider this a BC= P because there exists the potential for different interpretations of the h= andling of trunk group information. Should such information be interpreted= locally to the ENUM client or added to the RURI for downstream handling? = Is this a matter of local policy? =20 Also consider that if application of the technique in actual networks is a = litmus test, there is enough precedent out there to consider this a BCP. Don -----Original Message----- From: Daryl Malas [mailto:d.malas@cablelabs.com]=20 Sent: Friday, May 15, 2009 1:14 PM To: Richard Shockey; 'Alexander Mayrhofer'; enum@ietf.org; Don Troshynski Subject: Re: [Enum] WG: New Draft: Trunk Group Use in ENUM RESTART - Second= request for guidence All, I personally think it should be considered as a BCP. The main purpose is t= o not simply "suggest" the use of the parameters in the SIP URI NAPTR, but rather to say "it really, really should be done this way. In fact, if you do not do it this way, then you will likely be out of compatibility with most implementations." I think this is the best way to ensure industry consistency. This being said, if there is consensus to push it forward as Informational, it is better to be documented than not at all, in my opinion= . Don, you commented before on this draft, do you have a perspective on the value of this draft moving forward relative to the discussion? Regards, Daryl On 5/14/09 7:58 AM, "Richard Shockey" wrote: >=20 >> To: enum@ietf.org >> Subject: Re: [Enum] WG: New Draft: Trunk Group Use in ENUM RESTART - >> Secondrequest for guidence >> =20 >> =20 >> Richard, fellow WG members, >> =20 >> I agree with Peter, as i think the real question is whether the WG >> want >> to continue pursue the draft-ietf-enum-trunkgroup ENUMservice or not. >=20 > Well my original intent was to 'clear the queue' so to speak and I'm > personally convinced this is an important draft to document. Its starting= to > deploy now. I apologize if I had to 'shake the tree' so to speak to get > someone to finally answer the question on what to do. > =20 >> The question whether the group wants to adopt the >> draft-malas-enum-trunk-sip is seperate from that - but i like the way >> that Peter proposed. >=20 > Its fine with me as well. >=20 >> =20 >>> 1) Is anybody but the authors/editors of the respective drafts >> believes the WG >>> should say anything in this direction (trunk groups). [But see >> the "price tag" >>> under (4)] >> =20 >> I think it is somehow *related* to ENUM because of the Enumservice >> that we are trying to get rid. Otherwise, i don't see why it would fit > into >> ENUM. For example, it might well fit into DISPATCH as well? >=20 > IMHO it's a individual draft or a ENUM WG draft I would not suggest to th= e > authors to go down the DISPATCH path. I currently have limited confidence= in > the way DISPATCH will operate until proven otherwise. I'm personally pret= ty > disgusted actually. You have seen SIPPING flipped to DISPATCH. So whats t= he > difference except you have new chairs and not really new chairs at that. >=20 >> =20 >>> 2) Do you agree to abandon the approach in draft-ietf-enum- >> trunkgroup-00.txt? >> =20 >> Yes >=20 > As the co-author yes. As for Informational vs BCP I can live with > informational but I'll let Daryl comment on that. >=20 >> =20 >>> 3) Is the content of draft-malas-enum-trunk-sip-00.txt a better >> start instead? >> =20 >> Yes >=20 > Yes Either would work but this malas 00 IMHO is a much simpler approach a= nd > would work equally as well. The document needs to be rewritten but that i= s a > wordsmithing issue. >=20 >> =20 >>> 4) Is anybody willing to review draft-malas-enum-trunk-sip-00.txt? >> =20 >> If it becomes an ENUM WG document, i might have to, being the >> secretary >> of the ENUM WG. >> =20 >>> Then publish draft-malas-enum-trunk-sip-00.txt as draft-ietf-enum- >> trunkgroup-01.txt, >>> changing the intended state to Informational. >> =20 >> I would prefer if the WG concensus would be to remove >> draft-ietf-enum-trunkgroup from the WG "menu" entirely, and >> documenting the decision in draft-malas-enum-trunk-sip, but find a WG > that suits >> better such SIP operational issues than the ENUM group. >=20 > Not going to happen. SPEERMINT wont take it and it the new RAI org is IMH= O > just a reshuffling of the deck chairs. Pick your ship. >=20 > Its here or individual submission. >=20 >=20 >> =20 >> The solution that Peter proposed is also viable, if authors and chairs >> believe that's a faster way. I just don't think the WG should accept >> new work, given it's current status of being slowly move to the > pathology >> department. >=20 > IMHO finishing the work here with a single document the right way to go. > Lets clear the issue off the table. I don't like pushing off work to some > other WG that we should have completed ourselves. That's not right. We > agreed to do this in the first place, lets finish it. >=20 >=20 >> =20 >> Just to make clear: Content-wise, i definitely prefer the solution >> proposed in draft-malas-enum-trunk-sip. I'm just not entirely happy >> with the sloppy process. >=20 >=20 > Well it got caught is the process. It nothing new for WG's. You want bad > process I can talk about my current discussions with the IAB over the > liaison letter to SG2 over Infrastructure ENUM. >=20 >> =20 >> Alex >> =20 >> _______________________________________________ >> enum mailing list >> enum@ietf.org >> https://www.ietf.org/mailman/listinfo/enum >=20 > _______________________________________________ > enum mailing list > enum@ietf.org > https://www.ietf.org/mailman/listinfo/enum ----------------- Daryl Malas CableLabs (o) +1 303 661 3302 (f) +1 303 661 9199 mailto:d.malas@cablelabs.com From bernie@ietf.hoeneisen.ch Fri May 22 00:04:57 2009 Return-Path: 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 D5E833A68BC for ; Fri, 22 May 2009 00:04:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.567 X-Spam-Level: X-Spam-Status: No, score=-3.567 tagged_above=-999 required=5 tests=[AWL=1.033, BAYES_00=-2.599, GB_I_LETTER=-2] 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 k-ZXkYnvrpqf for ; Fri, 22 May 2009 00:04:54 -0700 (PDT) Received: from softronics.hoeneisen.ch (softronics.hoeneisen.ch [62.2.86.178]) by core3.amsl.com (Postfix) with ESMTP id 191583A6781 for ; Fri, 22 May 2009 00:04:53 -0700 (PDT) Received: from localhost ([127.0.0.1]) by softronics.hoeneisen.ch with esmtp (Exim 4.69) (envelope-from ) id 1M7Opn-0001vs-FA; Fri, 22 May 2009 09:06:27 +0200 Date: Fri, 22 May 2009 09:06:27 +0200 (CEST) From: Bernie Hoeneisen X-X-Sender: bhoeneis@softronics.hoeneisen.ch To: Don Troshynski In-Reply-To: Message-ID: References: <01a101c9d49c$0a510b80$1ef32280$@us> User-Agent: Alpine 2.00 (DEB 1167 2008-08-23) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-SA-Exim-Connect-IP: 127.0.0.1 X-SA-Exim-Mail-From: bernie@ietf.hoeneisen.ch X-SA-Exim-Scanned: No (on softronics.hoeneisen.ch); SAEximRunCond expanded to false Cc: "enum@ietf.org" Subject: Re: [Enum] WG: New Draft: Trunk Group Use in ENUM RESTART - Secondrequest for guidence X-BeenThere: enum@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Enum Discussion List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 22 May 2009 07:04:57 -0000 Hi Don et al. IMHO it doesn't matter at this point in time whether it will be BCP or informational at the end of the day. The more important question is find a proper home for this work: I propose this home to be SPEERMINT. This work, YMMV, is much closer to the SPEERMINT WG charter than to the ENUM WG charter. In case SPEERMINT won't take it, it's up to DISPATCH to decide on this. cheers, Bernie On Thu, 21 May 2009, Don Troshynski wrote: > All, > > After some thought, I think there is value in maneuvering this document toward a BCP. It will take some work -- in my opinion, the debate involving a draft service type should be removed. There is room to consider this a BCP because there exists the potential for different interpretations of the handling of trunk group information. Should such information be interpreted locally to the ENUM client or added to the RURI for downstream handling? Is this a matter of local policy? > > Also consider that if application of the technique in actual networks is a litmus test, there is enough precedent out there to consider this a BCP. > > Don > > -----Original Message----- > From: Daryl Malas [mailto:d.malas@cablelabs.com] > Sent: Friday, May 15, 2009 1:14 PM > To: Richard Shockey; 'Alexander Mayrhofer'; enum@ietf.org; Don Troshynski > Subject: Re: [Enum] WG: New Draft: Trunk Group Use in ENUM RESTART - Secondrequest for guidence > > All, > > I personally think it should be considered as a BCP. The main purpose is to > not simply "suggest" the use of the parameters in the SIP URI NAPTR, but > rather to say "it really, really should be done this way. In fact, if you > do not do it this way, then you will likely be out of compatibility with > most implementations." I think this is the best way to ensure industry > consistency. This being said, if there is consensus to push it forward as > Informational, it is better to be documented than not at all, in my opinion. > > Don, you commented before on this draft, do you have a perspective on the > value of this draft moving forward relative to the discussion? > > Regards, > > Daryl > > > On 5/14/09 7:58 AM, "Richard Shockey" wrote: > >> >>> To: enum@ietf.org >>> Subject: Re: [Enum] WG: New Draft: Trunk Group Use in ENUM RESTART - >>> Secondrequest for guidence >>> >>> >>> Richard, fellow WG members, >>> >>> I agree with Peter, as i think the real question is whether the WG >>> want >>> to continue pursue the draft-ietf-enum-trunkgroup ENUMservice or not. >> >> Well my original intent was to 'clear the queue' so to speak and I'm >> personally convinced this is an important draft to document. Its starting to >> deploy now. I apologize if I had to 'shake the tree' so to speak to get >> someone to finally answer the question on what to do. >> >>> The question whether the group wants to adopt the >>> draft-malas-enum-trunk-sip is seperate from that - but i like the way >>> that Peter proposed. >> >> Its fine with me as well. >> >>> >>>> 1) Is anybody but the authors/editors of the respective drafts >>> believes the WG >>>> should say anything in this direction (trunk groups). [But see >>> the "price tag" >>>> under (4)] >>> >>> I think it is somehow *related* to ENUM because of the Enumservice >>> that we are trying to get rid. Otherwise, i don't see why it would fit >> into >>> ENUM. For example, it might well fit into DISPATCH as well? >> >> IMHO it's a individual draft or a ENUM WG draft I would not suggest to the >> authors to go down the DISPATCH path. I currently have limited confidence in >> the way DISPATCH will operate until proven otherwise. I'm personally pretty >> disgusted actually. You have seen SIPPING flipped to DISPATCH. So whats the >> difference except you have new chairs and not really new chairs at that. >> >>> >>>> 2) Do you agree to abandon the approach in draft-ietf-enum- >>> trunkgroup-00.txt? >>> >>> Yes >> >> As the co-author yes. As for Informational vs BCP I can live with >> informational but I'll let Daryl comment on that. >> >>> >>>> 3) Is the content of draft-malas-enum-trunk-sip-00.txt a better >>> start instead? >>> >>> Yes >> >> Yes Either would work but this malas 00 IMHO is a much simpler approach and >> would work equally as well. The document needs to be rewritten but that is a >> wordsmithing issue. >> >>> >>>> 4) Is anybody willing to review draft-malas-enum-trunk-sip-00.txt? >>> >>> If it becomes an ENUM WG document, i might have to, being the >>> secretary >>> of the ENUM WG. >>> >>>> Then publish draft-malas-enum-trunk-sip-00.txt as draft-ietf-enum- >>> trunkgroup-01.txt, >>>> changing the intended state to Informational. >>> >>> I would prefer if the WG concensus would be to remove >>> draft-ietf-enum-trunkgroup from the WG "menu" entirely, and >>> documenting the decision in draft-malas-enum-trunk-sip, but find a WG >> that suits >>> better such SIP operational issues than the ENUM group. >> >> Not going to happen. SPEERMINT wont take it and it the new RAI org is IMHO >> just a reshuffling of the deck chairs. Pick your ship. >> >> Its here or individual submission. >> >> >>> >>> The solution that Peter proposed is also viable, if authors and chairs >>> believe that's a faster way. I just don't think the WG should accept >>> new work, given it's current status of being slowly move to the >> pathology >>> department. >> >> IMHO finishing the work here with a single document the right way to go. >> Lets clear the issue off the table. I don't like pushing off work to some >> other WG that we should have completed ourselves. That's not right. We >> agreed to do this in the first place, lets finish it. >> >> >>> >>> Just to make clear: Content-wise, i definitely prefer the solution >>> proposed in draft-malas-enum-trunk-sip. I'm just not entirely happy >>> with the sloppy process. >> >> >> Well it got caught is the process. It nothing new for WG's. You want bad >> process I can talk about my current discussions with the IAB over the >> liaison letter to SG2 over Infrastructure ENUM. >> >>> >>> Alex >>> >>> _______________________________________________ >>> enum mailing list >>> enum@ietf.org >>> https://www.ietf.org/mailman/listinfo/enum >> >> _______________________________________________ >> enum mailing list >> enum@ietf.org >> https://www.ietf.org/mailman/listinfo/enum > > > ----------------- > Daryl Malas > CableLabs > (o) +1 303 661 3302 > (f) +1 303 661 9199 > mailto:d.malas@cablelabs.com > > > _______________________________________________ > enum mailing list > enum@ietf.org > https://www.ietf.org/mailman/listinfo/enum > From richard@shockey.us Fri May 22 06:57:50 2009 Return-Path: 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 DF0193A677D for ; Fri, 22 May 2009 06:57:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.935 X-Spam-Level: X-Spam-Status: No, score=-2.935 tagged_above=-999 required=5 tests=[AWL=1.330, BAYES_00=-2.599, GB_I_LETTER=-2, IP_NOT_FRIENDLY=0.334] 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 ONJqHUpXYLLL for ; Fri, 22 May 2009 06:57:49 -0700 (PDT) Received: from outbound-mail-317.bluehost.com (outbound-mail-317.bluehost.com [67.222.54.10]) by core3.amsl.com (Postfix) with SMTP id 7002C3A6827 for ; Fri, 22 May 2009 06:57:49 -0700 (PDT) Received: (qmail 26016 invoked by uid 0); 22 May 2009 13:59:28 -0000 Received: from unknown (HELO box462.bluehost.com) (74.220.219.62) by outboundproxy6.bluehost.com with SMTP; 22 May 2009 13:59:28 -0000 DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=default; d=shockey.us; h=Received:From:To:Cc:References:In-Reply-To:Subject:Date:Message-ID:MIME-Version:Content-Type:Content-Transfer-Encoding:X-Mailer:Thread-Index:Content-Language:X-Identified-User; b=QdrKyUTdpfebsGz/MxY7y/fsqAJYaKmL0DlXkQsgoXz2YYjacZWKRqSoHB80SFnB5D6FL6S0KeVyG24qtYknS3YienB4/VYPC67tO+yL68E6j7vMAy0oPcSMiyY4cSY9; Received: from pool-173-66-69-164.washdc.fios.verizon.net ([173.66.69.164] helo=rshockeyPC) by box462.bluehost.com with esmtpa (Exim 4.69) (envelope-from ) id 1M7VHT-0005oT-Ep; Fri, 22 May 2009 07:59:28 -0600 From: "Richard Shockey" To: "'Bernie Hoeneisen'" , "'Don Troshynski'" References: <01a101c9d49c$0a510b80$1ef32280$@us> In-Reply-To: Date: Fri, 22 May 2009 09:59:24 -0400 Message-ID: <00f501c9dae5$843d5df0$8cb819d0$@us> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: Acnaq9l+e0VtF4ExQk6Tjhpo4bIQSQAOKHAQ Content-Language: en-us X-Identified-User: {3286:box462.bluehost.com:shockeyu:shockey.us} {sentby:smtp auth 173.66.69.164 authed with richard+shockey.us} Cc: enum@ietf.org Subject: Re: [Enum] WG: New Draft: Trunk Group Use in ENUM RESTART - Secondrequest for guidence X-BeenThere: enum@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Enum Discussion List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 22 May 2009 13:57:51 -0000 Chair hat off .. > Hi Don et al. > > IMHO it doesn't matter at this point in time whether it will be BCP or > informational at the end of the day. Yes it is important Bernie. BCP has a greater weight than Informational the burden of proof is very different. BCP clearly requires extensive community review. > > The more important question is find a proper home for this work: I > propose this home to be SPEERMINT. NO .. Bernie you did not listen the SPEERMINT chairs do not want it there. Its not in their charter. This work, YMMV, is much closer to > the > SPEERMINT WG charter than to the ENUM WG charter. In case SPEERMINT > won't take it, it's up to DISPATCH to decide on this. NO again. Why do you want to kill this? The WG agreed to do it. I don't understand this procedure argument at all. DISPATCH right now is a black hole that no one understands how it will work. This is a perfectly simple draft with a perfectly simple solution that needs to be clarified so people can deploy it correctly. IMHO the expertise is here in ENUM not in DISPATCH ..or SPEERMINT. > > cheers, > Bernie > > > On Thu, 21 May 2009, Don Troshynski wrote: > > > All, > > > > After some thought, I think there is value in maneuvering this > document toward a BCP. It will take some work -- in my opinion, the > debate involving a draft service type should be removed. There is > room to consider this a BCP because there exists the potential for > different interpretations of the handling of trunk group information. > Should such information be interpreted locally to the ENUM client or > added to the RURI for downstream handling? Is this a matter of local > policy? > > > > Also consider that if application of the technique in actual > networks is a litmus test, there is enough precedent out there to > consider this a BCP. > > > > Don > > > > -----Original Message----- > > From: Daryl Malas [mailto:d.malas@cablelabs.com] > > Sent: Friday, May 15, 2009 1:14 PM > > To: Richard Shockey; 'Alexander Mayrhofer'; enum@ietf.org; Don > Troshynski > > Subject: Re: [Enum] WG: New Draft: Trunk Group Use in ENUM RESTART - > Secondrequest for guidence > > > > All, > > > > I personally think it should be considered as a BCP. The main > purpose is to > > not simply "suggest" the use of the parameters in the SIP URI NAPTR, > but > > rather to say "it really, really should be done this way. In fact, > if you > > do not do it this way, then you will likely be out of compatibility > with > > most implementations." I think this is the best way to ensure > industry > > consistency. This being said, if there is consensus to push it > forward as > > Informational, it is better to be documented than not at all, in my > opinion. > > > > Don, you commented before on this draft, do you have a perspective > on the > > value of this draft moving forward relative to the discussion? > > > > Regards, > > > > Daryl > > > > > > On 5/14/09 7:58 AM, "Richard Shockey" wrote: > > > >> > >>> To: enum@ietf.org > >>> Subject: Re: [Enum] WG: New Draft: Trunk Group Use in ENUM > RESTART - > >>> Secondrequest for guidence > >>> > >>> > >>> Richard, fellow WG members, > >>> > >>> I agree with Peter, as i think the real question is whether the > WG > >>> want > >>> to continue pursue the draft-ietf-enum-trunkgroup ENUMservice or > not. > >> > >> Well my original intent was to 'clear the queue' so to speak and > I'm > >> personally convinced this is an important draft to document. Its > starting to > >> deploy now. I apologize if I had to 'shake the tree' so to speak to > get > >> someone to finally answer the question on what to do. > >> > >>> The question whether the group wants to adopt the > >>> draft-malas-enum-trunk-sip is seperate from that - but i like the > way > >>> that Peter proposed. > >> > >> Its fine with me as well. > >> > >>> > >>>> 1) Is anybody but the authors/editors of the respective drafts > >>> believes the WG > >>>> should say anything in this direction (trunk groups). [But see > >>> the "price tag" > >>>> under (4)] > >>> > >>> I think it is somehow *related* to ENUM because of the > Enumservice > >>> that we are trying to get rid. Otherwise, i don't see why it > would fit > >> into > >>> ENUM. For example, it might well fit into DISPATCH as well? > >> > >> IMHO it's a individual draft or a ENUM WG draft I would not suggest > to the > >> authors to go down the DISPATCH path. I currently have limited > confidence in > >> the way DISPATCH will operate until proven otherwise. I'm > personally pretty > >> disgusted actually. You have seen SIPPING flipped to DISPATCH. So > whats the > >> difference except you have new chairs and not really new chairs at > that. > >> > >>> > >>>> 2) Do you agree to abandon the approach in draft-ietf-enum- > >>> trunkgroup-00.txt? > >>> > >>> Yes > >> > >> As the co-author yes. As for Informational vs BCP I can live with > >> informational but I'll let Daryl comment on that. > >> > >>> > >>>> 3) Is the content of draft-malas-enum-trunk-sip-00.txt a better > >>> start instead? > >>> > >>> Yes > >> > >> Yes Either would work but this malas 00 IMHO is a much simpler > approach and > >> would work equally as well. The document needs to be rewritten but > that is a > >> wordsmithing issue. > >> > >>> > >>>> 4) Is anybody willing to review draft-malas-enum-trunk-sip- > 00.txt? > >>> > >>> If it becomes an ENUM WG document, i might have to, being the > >>> secretary > >>> of the ENUM WG. > >>> > >>>> Then publish draft-malas-enum-trunk-sip-00.txt as draft-ietf- > enum- > >>> trunkgroup-01.txt, > >>>> changing the intended state to Informational. > >>> > >>> I would prefer if the WG concensus would be to remove > >>> draft-ietf-enum-trunkgroup from the WG "menu" entirely, and > >>> documenting the decision in draft-malas-enum-trunk-sip, but find > a WG > >> that suits > >>> better such SIP operational issues than the ENUM group. > >> > >> Not going to happen. SPEERMINT wont take it and it the new RAI org > is IMHO > >> just a reshuffling of the deck chairs. Pick your ship. > >> > >> Its here or individual submission. > >> > >> > >>> > >>> The solution that Peter proposed is also viable, if authors and > chairs > >>> believe that's a faster way. I just don't think the WG should > accept > >>> new work, given it's current status of being slowly move to the > >> pathology > >>> department. > >> > >> IMHO finishing the work here with a single document the right way > to go. > >> Lets clear the issue off the table. I don't like pushing off work > to some > >> other WG that we should have completed ourselves. That's not right. > We > >> agreed to do this in the first place, lets finish it. > >> > >> > >>> > >>> Just to make clear: Content-wise, i definitely prefer the > solution > >>> proposed in draft-malas-enum-trunk-sip. I'm just not entirely > happy > >>> with the sloppy process. > >> > >> > >> Well it got caught is the process. It nothing new for WG's. You > want bad > >> process I can talk about my current discussions with the IAB over > the > >> liaison letter to SG2 over Infrastructure ENUM. > >> > >>> > >>> Alex > >>> > >>> _______________________________________________ > >>> enum mailing list > >>> enum@ietf.org > >>> https://www.ietf.org/mailman/listinfo/enum > >> > >> _______________________________________________ > >> enum mailing list > >> enum@ietf.org > >> https://www.ietf.org/mailman/listinfo/enum > > > > > > ----------------- > > Daryl Malas > > CableLabs > > (o) +1 303 661 3302 > > (f) +1 303 661 9199 > > mailto:d.malas@cablelabs.com > > > > > > _______________________________________________ > > enum mailing list > > enum@ietf.org > > https://www.ietf.org/mailman/listinfo/enum > > > _______________________________________________ > enum mailing list > enum@ietf.org > https://www.ietf.org/mailman/listinfo/enum From fluffy@cisco.com Sun May 24 09:01:20 2009 Return-Path: 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 C560D28C137 for ; Sun, 24 May 2009 09:01:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.471 X-Spam-Level: X-Spam-Status: No, score=-106.471 tagged_above=-999 required=5 tests=[AWL=-0.172, BAYES_00=-2.599, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] 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 I1Y6kN6lyZoY for ; Sun, 24 May 2009 09:01:20 -0700 (PDT) Received: from sj-iport-1.cisco.com (sj-iport-1.cisco.com [171.71.176.70]) by core3.amsl.com (Postfix) with ESMTP id 0EEE73A68B2 for ; Sun, 24 May 2009 09:01:20 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.41,240,1241395200"; d="scan'208";a="189687126" Received: from sj-dkim-2.cisco.com ([171.71.179.186]) by sj-iport-1.cisco.com with ESMTP; 24 May 2009 16:03:00 +0000 Received: from sj-core-4.cisco.com (sj-core-4.cisco.com [171.68.223.138]) by sj-dkim-2.cisco.com (8.12.11/8.12.11) with ESMTP id n4OG30hn010192; Sun, 24 May 2009 09:03:00 -0700 Received: from [192.168.4.177] (rcdn-fluffy-8711.cisco.com [10.99.9.18]) by sj-core-4.cisco.com (8.13.8/8.13.8) with ESMTP id n4OG2xXa011014; Sun, 24 May 2009 16:02:59 GMT From: Cullen Jennings To: Richard Shockey , =?ISO-8859-1?Q?Patrik_F=E4ltstr=F6m?= In-Reply-To: <11bb01c8c71e$77a0c3b0$66e24b10$@us> Impp: xmpp:cullenfluffyjennings@jabber.org References: <11bb01c8c71e$77a0c3b0$66e24b10$@us> Message-Id: <003FB3B5-8F2B-430D-8262-4BD1426A423E@cisco.com> Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v935.3) Date: Sun, 24 May 2009 10:02:58 -0600 X-Mailer: Apple Mail (2.935.3) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=1448; t=1243180980; x=1244044980; c=relaxed/simple; s=sjdkim2002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=fluffy@cisco.com; z=From:=20Cullen=20Jennings=20 |Subject:=20Re=3A=20ENUM=20WG=20Request=20for=20Publication =20-=20draft-ietf-enum-3761bis-03 |Sender:=20; bh=sA7a2Ws4YlnT//fkw40SQxsMruwiKwreEEepomOcU8E=; b=HHqXIDp29CwZ/o8v111SHAkPu3DN0KIyYXMbLF8TySU9K243MOFnxPYDZC vC8EuuKoELAPHv5db7buW6Ib9bvtyzsB25lhO8wEq1iIiGGefr0nZMznSzpG OYIQi8uJZx; Authentication-Results: sj-dkim-2; header.From=fluffy@cisco.com; dkim=pass ( sig from cisco.com/sjdkim2002 verified; ); Cc: enum@ietf.org Subject: Re: [Enum] ENUM WG Request for Publication - draft-ietf-enum-3761bis-03 X-BeenThere: enum@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Enum Discussion List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 24 May 2009 16:01:20 -0000 Is there a proto write up for this document? On Jun 5, 2008, at 9:11 AM, Richard Shockey wrote: > This is a request for publication on one ENUM WG document. > > > Title : The E.164 to Uniform Resource Identifiers (URI) > Dynamic Delegation Discovery System (DDDS) Application (ENUM) > Author(s) : S. Bradner, et al. > Filename : draft-ietf-enum-3761bis-03.txt > Pages : 22 > Date : 2008-03-31 > > This document discusses the use of the Domain Name System (DNS) for > the > storage of E.164 numbers, and for resolving them into URIs that can > be used > for (for example) telephony call setup. This document also > describes how > the DNS can be used to identify the services associated with an E.164 > number. This document obsoletes RFC 3761. > > > A URL for this Internet-Draft is: > http://www.ietf.org/internet-drafts/draft-ietf-enum-3761bis-03.txt > > > A three week WG last call on this document concluded on June 5 2008. > > The document listed above is being considered for Proposed Standard > status. > > This document has been extensively discussed during 2006-2008. > > > Richard Shockey > Director, Member of the Technical Staff > NeuStar > 46000 Center Oak Plaza - Sterling, VA 20166 > PSTN Office +1 571.434.5651 > PSTN Mobile: +1 703.593.2683 > > > > From peter@denic.de Sun May 24 09:23:31 2009 Return-Path: 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 40ACE3A6D6D for ; Sun, 24 May 2009 09:23:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.933 X-Spam-Level: X-Spam-Status: No, score=-5.933 tagged_above=-999 required=5 tests=[AWL=0.316, BAYES_00=-2.599, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_MED=-4] 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 GgyNTwEhVp4g for ; Sun, 24 May 2009 09:23:30 -0700 (PDT) Received: from office.denic.de (gw-office.denic.de [81.91.160.182]) by core3.amsl.com (Postfix) with ESMTP id 5FD0A3A6C0D for ; Sun, 24 May 2009 09:23:30 -0700 (PDT) Received: from x27.adm.denic.de ([10.122.64.128]) by office.denic.de with esmtp id 1M8GVZ-0008Ti-Ab; Sun, 24 May 2009 18:25:09 +0200 Received: from localhost by x27.adm.denic.de with local id 1M8GS1-0005ef-DE; Sun, 24 May 2009 18:21:29 +0200 Date: Sun, 24 May 2009 18:21:29 +0200 From: Peter Koch To: IETF ENUM WG Message-ID: <20090524162129.GA13914@x27.adm.denic.de> Mail-Followup-To: IETF ENUM WG References: <01a101c9d49c$0a510b80$1ef32280$@us> <00f501c9dae5$843d5df0$8cb819d0$@us> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <00f501c9dae5$843d5df0$8cb819d0$@us> User-Agent: Mutt/1.4.2.3i Sender: Peter Koch Subject: Re: [Enum] WG: New Draft: Trunk Group Use in ENUM RESTART - Secondrequest for guidence X-BeenThere: enum@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Enum Discussion List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 24 May 2009 16:23:31 -0000 On Fri, May 22, 2009 at 09:59:24AM -0400, Richard Shockey wrote: I agree with Bernie that the category is the second decision to make, but ... > Yes it is important Bernie. BCP has a greater weight than Informational the > burden of proof is very different. BCP clearly requires extensive community > review. ... this is the wrong (i.e., reverse) approach. First, if you are concerned about review, you can have IETF wide Last Call for Informational documents, as well, even though it is not mandatory. Second, organizing review and increasing its quality are up to the editors and the chairs, regardless of the document category. If I understand correctly, the technique under discussion is to be applied mostly if not solely to Infrastructure ENUM? Also, we're reducing the registration process for ENUM services from Standards Track to Expert Review. Both indicate to me that BCP is inappropriate because of the lack of breadth. > NO again. Why do you want to kill this? The WG agreed to do it. I don't Could you point me to that declaration of consensus, please? > understand this procedure argument at all. DISPATCH right now is a black > hole that no one understands how it will work. This is a perfectly simple > draft with a perfectly simple solution that needs to be clarified so people > can deploy it correctly. > > IMHO the expertise is here in ENUM not in DISPATCH ..or SPEERMINT. There's some irony here in that even though it's all so simple, we don't really see discussion of the contents of the draft ... -Peter (who pleas guilty as charged) From bernie@ietf.hoeneisen.ch Mon May 25 08:46:32 2009 Return-Path: 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 33C633A67C0 for ; Mon, 25 May 2009 08:46:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.635 X-Spam-Level: X-Spam-Status: No, score=-2.635 tagged_above=-999 required=5 tests=[AWL=-0.036, BAYES_00=-2.599] 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 f-cCKOtl2WBI for ; Mon, 25 May 2009 08:46:31 -0700 (PDT) Received: from softronics.hoeneisen.ch (softronics.hoeneisen.ch [62.2.86.178]) by core3.amsl.com (Postfix) with ESMTP id 83CE53A6C01 for ; Mon, 25 May 2009 08:46:30 -0700 (PDT) Received: from localhost ([127.0.0.1]) by softronics.hoeneisen.ch with esmtp (Exim 4.69) (envelope-from ) id 1M8cPD-0007bC-7I; Mon, 25 May 2009 17:48:03 +0200 Date: Mon, 25 May 2009 17:48:03 +0200 (CEST) From: Bernie Hoeneisen X-X-Sender: bhoeneis@softronics.hoeneisen.ch To: Richard Shockey In-Reply-To: <00f501c9dae5$843d5df0$8cb819d0$@us> Message-ID: References: <01a101c9d49c$0a510b80$1ef32280$@us> <00f501c9dae5$843d5df0$8cb819d0$@us> User-Agent: Alpine 2.00 (DEB 1167 2008-08-23) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; format=flowed; charset=US-ASCII X-SA-Exim-Connect-IP: 127.0.0.1 X-SA-Exim-Mail-From: bernie@ietf.hoeneisen.ch X-SA-Exim-Scanned: No (on softronics.hoeneisen.ch); SAEximRunCond expanded to false Cc: IETF ENUM list , 'Don Troshynski' Subject: Re: [Enum] WG: New Draft: Trunk Group Use in ENUM RESTART - Secondrequest for guidence X-BeenThere: enum@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Enum Discussion List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 25 May 2009 15:46:32 -0000 Hi Rich et al. On Fri, 22 May 2009, Richard Shockey wrote: >> IMHO it doesn't matter at this point in time whether it will be BCP or >> informational at the end of the day. > > Yes it is important Bernie. BCP has a greater weight than Informational the > burden of proof is very different. BCP clearly requires extensive community > review. Before "Publication Requested" this does not matter too much. >> The more important question is find a proper home for this work: I >> propose this home to be SPEERMINT. > > NO .. Bernie you did not listen the SPEERMINT chairs do not want it there. I am not aware of any statement of rejection from SPEERMINT chair side. At least Jason stated something different compared to what you claim. On Thu, 05 Mar 2009, Jason Livingood wrote: I'm willing to consider it but only if the ENUM WG chairs feel strongly that this should come over to us. If you guys can process it rapidly, and feel it is within your scope, then go for it. If you are not sure it is totally in-scope and you expect to shut down soon so that you cannot move the document ahead, then we could fit this in as an "implementer-specific" document. That's a long way of saying we can help if you like, but it's really up to you and Patrik. :-) > Its not in their charter. As stated earlier (YMMV), I believe this is closer to the SPEERMINT charter than to the ENUM charter. From the SPEERMINT charter: The most focused deliverables of SPEERMINT are best current practices regarding exchange of real-time sessions among VoIP and other real-time application service providers and, in particular, how such calls are routed. >>In case SPEERMINT won't take it, it's up to DISPATCH to decide on this. > > NO again. Why do you want to kill this? I never stated any intention to kill this. What leads you to such a assumption? Note: Stating "the work shall be carried out elsewhere" is different from "I don't want the work to be done at all". > The WG agreed to do it. I do not recall the ENUM WG taking on the new approach as a WG item. > I don't understand this procedure argument at all. DISPATCH right now is > a black hole that no one understands how it will work. Note: DISPATCH is not chartered to carry out work, but to decide where work is carried out best within the RAI area. > This is a perfectly simple draft with a perfectly simple solution that > needs to be clarified so people can deploy it correctly. Well, I am not aware of any I-D that looked simple in the beginning to stay as simple until the end...usually the opposite is the case. BTW: What is your schedule to close the ENUM WG? cheers, Bernie From lconroy@insensate.co.uk Tue May 26 04:09:44 2009 Return-Path: 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 001693A7088 for ; Tue, 26 May 2009 04:09:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599] 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 ecSQsbPnE8JM for ; Tue, 26 May 2009 04:09:43 -0700 (PDT) Received: from insensate.co.uk (ghost.insensate.co.uk [213.152.49.121]) by core3.amsl.com (Postfix) with ESMTP id 0F8C43A7071 for ; Tue, 26 May 2009 04:09:42 -0700 (PDT) Received: from [127.0.0.1] (localhost [127.0.0.1]) by insensate.co.uk (Postfix) with ESMTP id CF2E81215A9 for ; Tue, 26 May 2009 12:11:33 +0100 (BST) Message-Id: From: Lawrence Conroy To: IETF ENUM WG Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v935.3) Date: Tue, 26 May 2009 12:11:22 +0100 X-Mailer: Apple Mail (2.935.3) Subject: [Enum] Trunk group document & Charter X-BeenThere: enum@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Enum Discussion List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 26 May 2009 11:09:44 -0000 Hi Folks, I think we're agreed that the old Enumservice is dead. Richard shot it with his pearl-handled revolver. Looking at the ENUM WG charter, which is what any good WG should do... - I note point 4 of the ENUM WG charter: This document proposes using RFC 3761-like technology to store and deliver other information about services addressed by E.164 numbers. It is certainly focussed on PSTN call routing and signalling data. => This document fits right into that point, IMHO. - I also note, however, ENUM charter point 6, paragraph 2: This is no longer about an Enumservice (thank goodness). => Have the AD(s) approved this *non-Enumservice* item? I didn't see any mail to that effect on list. As we haven't HAD a WG meeting since this change in the document, there has been no chance for them to mention this agreement there either. ---- Assuming that this agreement does turn up on list, & the ADs don't want the ENUM WG to stop working just yet... Who is willing to work on the problem? The authors have asked for help (I guess, from domain experts) on the new process proposed in the document. People on this ENUM list SHOULD have the right domain expertise -- this is all about Naming and addressing. It also involves routing. That kinda implies to me that there will be appropriate domain expertise amongst people on the SPEERMINT list. So .. regardless of the target document status (it really doesn't matter at this point), is anyone going to help? I'd suggest that assistance is requested via the SPEERMINT list **as well**, but focussing on ENUM list members... I will try to review the document. Anyone else? all the best, Lawrence From wwwrun@core3.amsl.com Tue May 26 07:12:28 2009 Return-Path: X-Original-To: enum@ietf.org Delivered-To: enum@core3.amsl.com Received: by core3.amsl.com (Postfix, from userid 30) id 8C93128C24D; Tue, 26 May 2009 07:12:28 -0700 (PDT) X-idtracker: yes To: IETF-Announce From: The IESG Message-Id: <20090526141228.8C93128C24D@core3.amsl.com> Date: Tue, 26 May 2009 07:12:28 -0700 (PDT) Cc: enum@ietf.org Subject: [Enum] Last Call: draft-ietf-enum-3761bis (The E.164 to Uniform Resource Identifiers (URI) Dynamic Delegation Discovery System (DDDS) Application (ENUM)) to Proposed Standard X-BeenThere: enum@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: ietf@ietf.org List-Id: Enum Discussion List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 26 May 2009 14:12:28 -0000 The IESG has received a request from the Telephone Number Mapping WG (enum) to consider the following document: - 'The E.164 to Uniform Resource Identifiers (URI) Dynamic Delegation Discovery System (DDDS) Application (ENUM) ' as a Proposed Standard The IESG plans to make a decision in the next few weeks, and solicits final comments on this action. Please send substantive comments to the ietf@ietf.org mailing lists by 2009-06-09. Exceptionally, comments may be sent to iesg@ietf.org instead. In either case, please retain the beginning of the Subject line to allow automated sorting. The file can be obtained via http://www.ietf.org/internet-drafts/draft-ietf-enum-3761bis-04.txt IESG discussion can be tracked via https://datatracker.ietf.org/public/pidtracker.cgi?command=view_id&dTag=15412&rfc_flag=0 From wwwrun@core3.amsl.com Tue May 26 07:13:57 2009 Return-Path: X-Original-To: enum@ietf.org Delivered-To: enum@core3.amsl.com Received: by core3.amsl.com (Postfix, from userid 30) id 2E57328C22C; Tue, 26 May 2009 07:13:56 -0700 (PDT) X-idtracker: yes To: IETF-Announce From: The IESG Message-Id: <20090526141357.2E57328C22C@core3.amsl.com> Date: Tue, 26 May 2009 07:13:57 -0700 (PDT) Cc: enum@ietf.org Subject: [Enum] Last Call: draft-ietf-enum-enumservices-guide (IANA Registration of Enumservices: Guide, Template and IANA Considerations) to Proposed Standard X-BeenThere: enum@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: ietf@ietf.org List-Id: Enum Discussion List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 26 May 2009 14:13:57 -0000 The IESG has received a request from the Telephone Number Mapping WG (enum) to consider the following document: - 'IANA Registration of Enumservices: Guide, Template and IANA Considerations ' as a Proposed Standard The IESG plans to make a decision in the next few weeks, and solicits final comments on this action. Please send substantive comments to the ietf@ietf.org mailing lists by 2009-06-09. Exceptionally, comments may be sent to iesg@ietf.org instead. In either case, please retain the beginning of the Subject line to allow automated sorting. The file can be obtained via http://www.ietf.org/internet-drafts/draft-ietf-enum-enumservices-guide-16.txt IESG discussion can be tracked via https://datatracker.ietf.org/public/pidtracker.cgi?command=view_id&dTag=14322&rfc_flag=0 From wwwrun@core3.amsl.com Tue May 26 07:27:59 2009 Return-Path: X-Original-To: enum@ietf.org Delivered-To: enum@core3.amsl.com Received: by core3.amsl.com (Postfix, from userid 30) id A0A6F3A70DD; Tue, 26 May 2009 07:27:59 -0700 (PDT) X-idtracker: yes To: IETF-Announce From: The IESG Message-Id: <20090526142759.A0A6F3A70DD@core3.amsl.com> Date: Tue, 26 May 2009 07:27:59 -0700 (PDT) Cc: enum@ietf.org Subject: [Enum] Last Call: draft-ietf-enum-iax (IANA Registration for IAX Enumservice) to Proposed Standard X-BeenThere: enum@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: ietf@ietf.org List-Id: Enum Discussion List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 26 May 2009 14:27:59 -0000 The IESG has received a request from the Telephone Number Mapping WG (enum) to consider the following document: - 'IANA Registration for IAX Enumservice ' as a Proposed Standard The IESG plans to make a decision in the next few weeks, and solicits final comments on this action. Please send substantive comments to the ietf@ietf.org mailing lists by 2009-06-09. Exceptionally, comments may be sent to iesg@ietf.org instead. In either case, please retain the beginning of the Subject line to allow automated sorting. The file can be obtained via http://www.ietf.org/internet-drafts/draft-ietf-enum-iax-05.txt IESG discussion can be tracked via https://datatracker.ietf.org/public/pidtracker.cgi?command=view_id&dTag=14273&rfc_flag=0 From pk@DENIC.DE Tue May 26 09:56:16 2009 Return-Path: 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 87E363A70F6; Tue, 26 May 2009 09:56:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.967 X-Spam-Level: X-Spam-Status: No, score=-5.967 tagged_above=-999 required=5 tests=[AWL=0.282, BAYES_00=-2.599, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_MED=-4] 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 1jepJxybvftO; Tue, 26 May 2009 09:56:15 -0700 (PDT) Received: from office.denic.de (gw-office.denic.de [81.91.160.182]) by core3.amsl.com (Postfix) with ESMTP id 7A8373A69FE; Tue, 26 May 2009 09:55:51 -0700 (PDT) Received: from unknown.office.denic.de ([10.122.65.182]) by office.denic.de with esmtp id 1M8zxN-0003YP-AN; Tue, 26 May 2009 18:56:53 +0200 Received: by unknown.office.denic.de (Postfix, from userid 501) id 2B5841841CE; Tue, 26 May 2009 18:56:53 +0200 (CEST) Date: Tue, 26 May 2009 18:56:52 +0200 From: Peter Koch To: The IESG Message-ID: <20090526165652.GC42439@unknown.office.denic.de> Mail-Followup-To: The IESG , enum@ietf.org References: <20090526142759.A0A6F3A70DD@core3.amsl.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20090526142759.A0A6F3A70DD@core3.amsl.com> User-Agent: Mutt/1.4.2.1i Cc: enum@ietf.org Subject: Re: [Enum] Last Call: draft-ietf-enum-iax (IANA Registration for IAX Enumservice) to Proposed Standard X-BeenThere: enum@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Enum Discussion List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 26 May 2009 16:56:16 -0000 On Tue, May 26, 2009 at 07:27:59AM -0700, The IESG wrote: > The IESG has received a request from the Telephone Number Mapping WG > (enum) to consider the following document: > > - 'IANA Registration for IAX Enumservice ' > as a Proposed Standard > The file can be obtained via > http://www.ietf.org/internet-drafts/draft-ietf-enum-iax-05.txt the primary reason why this draft is aiming at Proposed Standard is that the current regime as of RFC 3761 sets this threshold (or Experimental or BCP) for ENUM service registration. However, the draft has a normative reference to draft-guy-iax-05.txt, aiming at Informational (NIT: the draft itself mentions Informational, too). I've raised this in previous WG discussions. Either a downref exemption is requested - then it needs to be mentioned - or draft-guy-iax-05.txt is expected to go to Standards Track and the ENUM service registration has to wait. Since draft-ietf-enum-enumservices-guide-16.txt is now in Last Call, and provided it gets approved, it might just be easier to withdraw the LC for the iax ENUM service and instead process it under the new rules of Expert Review. That also means there's little reason for said downref exemption. NIT: the NAPTR representations should really use standard DNS parentheses for line continuation instead of "\". -Peter From pk@DENIC.DE Tue May 26 10:22:39 2009 Return-Path: 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 BF32C3A70A1 for ; Tue, 26 May 2009 10:22:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.974 X-Spam-Level: X-Spam-Status: No, score=-5.974 tagged_above=-999 required=5 tests=[AWL=0.275, BAYES_00=-2.599, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_MED=-4] 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 sW9MmEawmAyw for ; Tue, 26 May 2009 10:22:36 -0700 (PDT) Received: from office.denic.de (gw-office.denic.de [81.91.160.182]) by core3.amsl.com (Postfix) with ESMTP id 65D7A3A70F8 for ; Tue, 26 May 2009 10:22:36 -0700 (PDT) Received: from unknown.office.denic.de ([10.122.65.182]) by office.denic.de with esmtp id 1M90Nh-0003sH-PC; Tue, 26 May 2009 19:24:05 +0200 Received: by unknown.office.denic.de (Postfix, from userid 501) id 9CA7E18426A; Tue, 26 May 2009 19:24:05 +0200 (CEST) Date: Tue, 26 May 2009 19:24:05 +0200 From: Peter Koch To: Lawrence Conroy Message-ID: <20090526172405.GD42439@unknown.office.denic.de> Mail-Followup-To: Lawrence Conroy , IETF ENUM WG References: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.4.2.1i Cc: IETF ENUM WG Subject: [Enum] Meeting [Re: Trunk group document & Charter] X-BeenThere: enum@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Enum Discussion List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 26 May 2009 17:22:39 -0000 On Tue, May 26, 2009 at 12:11:22PM +0100, Lawrence Conroy wrote: > I didn't see any mail to that effect on list. As we haven't HAD a > WG meeting since this change in the document, there has been no > chance for them to mention this agreement there either. speaking of which -- are we going to have a session in Stockholm to do the final WG cleanup? -Peter From richard@shockey.us Tue May 26 10:56:56 2009 Return-Path: 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 ADF4F3A69C5 for ; Tue, 26 May 2009 10:56:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.97 X-Spam-Level: X-Spam-Status: No, score=-1.97 tagged_above=-999 required=5 tests=[AWL=0.295, BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334] 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 w4HXt--Zt4Ub for ; Tue, 26 May 2009 10:56:55 -0700 (PDT) Received: from outbound-mail-153.bluehost.com (outbound-mail-153.bluehost.com [67.222.39.33]) by core3.amsl.com (Postfix) with SMTP id CD2A43A6949 for ; Tue, 26 May 2009 10:56:55 -0700 (PDT) Received: (qmail 21143 invoked by uid 0); 26 May 2009 17:58:36 -0000 Received: from unknown (HELO box462.bluehost.com) (74.220.219.62) by outboundproxy5.bluehost.com with SMTP; 26 May 2009 17:58:36 -0000 DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=default; d=shockey.us; h=Received:From:To:Cc:References:In-Reply-To:Subject:Date:Message-ID:MIME-Version:Content-Type:Content-Transfer-Encoding:X-Mailer:Thread-Index:Content-Language:X-Identified-User; b=ZkoYyKccqSWzxNRzSjP6zKwY0qKoUnxbABSj9cqUrfxOYPM8i1s2dYwmoS89xXs+wu3Gp3lz5IpdBmHqRQUVS/OnNGC4PxaQn+eCUq72waVfHLOl5kEy8rKAFrxvCspz; Received: from pool-173-66-69-164.washdc.fios.verizon.net ([173.66.69.164] helo=rshockeyPC) by box462.bluehost.com with esmtpa (Exim 4.69) (envelope-from ) id 1M90v6-0001md-KZ; Tue, 26 May 2009 11:58:36 -0600 From: "Richard Shockey" To: "'Peter Koch'" , "'Lawrence Conroy'" References: <20090526172405.GD42439@unknown.office.denic.de> In-Reply-To: <20090526172405.GD42439@unknown.office.denic.de> Date: Tue, 26 May 2009 13:58:22 -0400 Message-ID: <022501c9de2b$8ffafb40$aff0f1c0$@us> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: AcneJtDNTAFFMRxdRzaR0HT/YBRpsAAA6DXQ Content-Language: en-us X-Identified-User: {3286:box462.bluehost.com:shockeyu:shockey.us} {sentby:smtp auth 173.66.69.164 authed with richard+shockey.us} Cc: 'IETF ENUM WG' Subject: Re: [Enum] Meeting [Re: Trunk group document & Charter] X-BeenThere: enum@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Enum Discussion List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 26 May 2009 17:56:56 -0000 What would we do in Stockholm? What would be the agenda? I can't imagine asking the AD for a slot given there is very little to discuss unless there are large objections to 3761bis and the registration draft. Cullen and Bob are cooperating by getting the last items off the table. There is the CNAM draft but that that is a separate issue involving what is the URI type. The WG already approved it. We did hum on trunkgroup as a WG item ..I think it was Philadelphia I just need to find the note from the various meeting minutes. > -----Original Message----- > From: enum-bounces@ietf.org [mailto:enum-bounces@ietf.org] On Behalf > Of Peter Koch > Sent: Tuesday, May 26, 2009 1:24 PM > To: Lawrence Conroy > Cc: IETF ENUM WG > Subject: [Enum] Meeting [Re: Trunk group document & Charter] > > On Tue, May 26, 2009 at 12:11:22PM +0100, Lawrence Conroy wrote: > > > I didn't see any mail to that effect on list. As we haven't HAD a > > WG meeting since this change in the document, there has been no > > chance for them to mention this agreement there either. > > speaking of which -- are we going to have a session in Stockholm to do > the > final WG cleanup? > > -Peter > _______________________________________________ > enum mailing list > enum@ietf.org > https://www.ietf.org/mailman/listinfo/enum From lconroy@insensate.co.uk Tue May 26 11:17:25 2009 Return-Path: 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 49AFE3A6C17 for ; Tue, 26 May 2009 11:17:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599] 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 Qqth3iYAnCEO for ; Tue, 26 May 2009 11:17:24 -0700 (PDT) Received: from insensate.co.uk (ghost.insensate.co.uk [213.152.49.121]) by core3.amsl.com (Postfix) with ESMTP id 2825A3A6B69 for ; Tue, 26 May 2009 11:17:03 -0700 (PDT) Received: from [127.0.0.1] (localhost [127.0.0.1]) by insensate.co.uk (Postfix) with ESMTP id B6569121772; Tue, 26 May 2009 19:18:49 +0100 (BST) Message-Id: From: Lawrence Conroy To: Richard Shockey In-Reply-To: <022501c9de2b$8ffafb40$aff0f1c0$@us> Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v935.3) Date: Tue, 26 May 2009 19:18:38 +0100 References: <20090526172405.GD42439@unknown.office.denic.de> <022501c9de2b$8ffafb40$aff0f1c0$@us> X-Mailer: Apple Mail (2.935.3) Cc: 'IETF ENUM WG' , 'Peter Koch' Subject: Re: [Enum] Meeting [Re: Trunk group document & Charter] X-BeenThere: enum@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Enum Discussion List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 26 May 2009 18:17:25 -0000 Hi Richard, Peter, folks, yes we did (I do remember - likewise, can't recall which meeting though). However, that was for the Enumservice that you just shot, which is within the exclusive remit of the WG. BUT... ----> For the new approach to TG, and looking at point 6 para 2 of the ENUM Charter, it's the AD that hums. <---- As for any potential meeting -- I suspect that there would have been a good half hour's worth of useful discussion just on the trunk group draft(s) and iax. [particularly with regard to the way forward using the enumservice- guide] The TG draft has raised a bunch of process issues, and having a friendly AD in the house would have helped (i.e. to anoint it officially as appropriate under 6.2). all the best, Lawrence On 26 May 2009, at 18:58, Richard Shockey wrote: > We did hum on trunkgroup as a WG item ..I think it was Philadelphia > I just > need to find the note from the various meeting minutes. From bernie@ietf.hoeneisen.ch Tue May 26 11:23:03 2009 Return-Path: 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 BA5A528C22A for ; Tue, 26 May 2009 11:23:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.507 X-Spam-Level: X-Spam-Status: No, score=-2.507 tagged_above=-999 required=5 tests=[AWL=0.092, BAYES_00=-2.599] 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 3rXmEXoz7wID for ; Tue, 26 May 2009 11:23:03 -0700 (PDT) Received: from softronics.hoeneisen.ch (softronics.hoeneisen.ch [62.2.86.178]) by core3.amsl.com (Postfix) with ESMTP id 79B403A6FDD for ; Tue, 26 May 2009 11:23:03 -0700 (PDT) Received: from localhost ([127.0.0.1]) by softronics.hoeneisen.ch with esmtp (Exim 4.69) (envelope-from ) id 1M91KO-0000ea-0l for enum@ietf.org; Tue, 26 May 2009 20:24:44 +0200 Date: Tue, 26 May 2009 20:24:44 +0200 (CEST) From: Bernie Hoeneisen X-X-Sender: bhoeneis@softronics.hoeneisen.ch To: IETF ENUM list Message-ID: User-Agent: Alpine 2.00 (DEB 1167 2008-08-23) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-SA-Exim-Connect-IP: 127.0.0.1 X-SA-Exim-Mail-From: bernie@ietf.hoeneisen.ch X-SA-Exim-Scanned: No (on softronics.hoeneisen.ch); SAEximRunCond expanded to false Subject: Re: [Enum] Meeting [Re: Trunk group document & Charter] X-BeenThere: enum@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Enum Discussion List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 26 May 2009 18:23:03 -0000 On Tue, 26 May 2009, Richard Shockey wrote: > What would we do in Stockholm? What would be the agenda? Some topics that come into my mind and might be worth discussing: - Status of "unused"? - What to do about the milestone: "ENUM Privacy and Security Considerations as an Informational"? - What should be the proper home of Trunk Group? ENUM or SPEERMINT, or let DISPATCH decide on a new home? - Where will ENUM issues be handled after closure of the ENUM WG? - more...? > We did hum on trunkgroup as a WG item ..I think it was Philadelphia I just > need to find the note from the various meeting minutes. 1) The WG has never approved the currently discussed variant 2) In any case such work requires AD approval, as the ENUM charter says: Other than Enumservices, all proposed deliverables of the working group will be discussed with and approved by the Area Directors I am not aware of any AD approval. cheers, Bernie From lconroy@insensate.co.uk Tue May 26 11:52:50 2009 Return-Path: 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 7F5FF3A69CB for ; Tue, 26 May 2009 11:52:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599] 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 zIB71lNt+gf5 for ; Tue, 26 May 2009 11:52:49 -0700 (PDT) Received: from insensate.co.uk (ghost.insensate.co.uk [213.152.49.121]) by core3.amsl.com (Postfix) with ESMTP id 85EC43A6DA5 for ; Tue, 26 May 2009 11:52:48 -0700 (PDT) Received: from [IPv6???1] (localhost [127.0.0.1]) by insensate.co.uk (Postfix) with ESMTP id 8DCFF121827; Tue, 26 May 2009 19:54:40 +0100 (BST) Message-Id: <2A348BF3-388B-4248-B8A6-B208C8A3D75B@insensate.co.uk> From: Lawrence Conroy To: IETF ENUM WG Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v935.3) Date: Tue, 26 May 2009 19:54:29 +0100 X-Mailer: Apple Mail (2.935.3) Cc: paf@cisco.com Subject: [Enum] 3761bis pre-LC comments X-BeenThere: enum@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Enum Discussion List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 26 May 2009 18:52:50 -0000 Hi Esteemed co-chair and co-author of 3761, folks, Re. "large objections to 3761bis ..." I already mentioned this, but there has been no comment on (or off) list, so I repeat it. It IS important, so I'd appreciate some response. I think we NEED to change section 2. The current version is incorrect for anything but terminal rules. For the rationale, see my original post on 2nd May: Since that point, I have polished the proposed text, so here's what I think is a sensible and necessary replacement -- the changes are to the current section 2.2 and 2.4 intro. The 2.4 sub-sections have just been re-numbered and I've also zapped a couple of typos. I suggest that this could be rolled into the next version along with any other changes reflecting LC or IESG comments (there is always another version in that phase, I know it :). Comments please? all the best, Lawrence --------------------------------------------------------------------------- 2.1. Application Unique String The Application Unique String (AUS) is a fully qualified E.164 number minus any non-digit characters except for the '+' character which appears at the beginning of the number. The '+' is kept to provide a well understood anchor for the AUS in order to distinguish it from other telephone numbers that are not part of the E.164 namespace. For example, the E.164 number could start out as "+44-116-496-0348". To ensure that no syntactic sugar is allowed into the AUS, all non- digits except for '+' are removed, yielding "+441164960348". 2.2. First Well Known Rule The First Well Known Rule converts an Application Unique String (AUS) into an initial key into the the Application's Rules Database. For ENUM, the rules database is the DNS, so this key is a domain name. In order to convert the AUS to a unique key in this database the string is converted into a domain name according to this algorithm: 1. Remove all characters with the exception of the digits. For example, given the E.164 number "+44-20-7946-0148", this step would simply remove the leading '+', producing "442079460148". 2. Reverse the order of the digits. Example: "841064970244" 3. Put dots ('.') between each digit. Example: "4.4.2.0.7.9.4.6.0.1.4.8" 4. Append the string ".e164.arpa." to the end. Example: 8.4.1.0.6.4.9.7.0.2.4.4.e164.arpa. The E.164 namespace and this Application's database are organized in such a way that it is possible to go directly from the name to the smallest granularity of the namespace directly from the name itself, so no further processing is required to generate the initial key. This domain name is used to request NAPTR records. Each of these records may contain the end result or, if its flags field is empty, produces a new key in the form of a domain name that is used to request further NAPTR records from the DNS. 2.3. Expected Output The output of the last DDDS loop is a Uniform Resource Identifier in its absolute form according to the 'absoluteURI' production in the Collected ABNF found in RFC 3986[RFC3986]. 2.4. Valid Databases At present only one DDDS Database is specified for this Application. "Dynamic Delegation Discovery System (DDDS) Part Three: The DNS Database" [RFC3403] specifies a DDDS Database that uses the NAPTR DNS resource record to contain the rewrite rules. The Keys for this database are encoded as domain names. The character set used to encode the substitution expression is UTF-8. The allowed input characters are all those characters that are allowed anywhere in an E.164 number. The characters allowed to be in a Key are those that are currently defined for DNS domain names. 2.4.1. Optional Name Server Additional Section Processing Some nameserver implementations attempt to be intelligent about items that are inserted into the additional information section of a given DNS response. For example, BIND will attempt to determine if it is authoritative for a domain whenever it encodes one into a packet. If it is, then it will insert any A records it finds for that domain into the additional information section of the answer until the packet reaches the maximum length allowed. It is therefore potentially useful for a client to check for this additional information. It is also easy to contemplate an ENUM enhanced nameserver that understands the actual contents of the NAPTR records it is serving and inserts more appropriate information into the additional information section of the response. Thus, DNS servers MAY interpret Flag values and use that information to include appropriate resource records in the Additional Information portion of the DNS packet. Clients are encouraged to check for additional information but are not required to do so. See the Additional Information Processing section of RFC 3403 [RFC3403], Section 4.2 for more information on NAPTR records and the Additional Information section of a DNS response packet. 2.4.2. Flags This Database contains a field that contains flags that signal when the DDDS algorithm has finished. At this time only one flag, "U", is defined. This means that this Rule is the last one and that the output of the Rule is a URI [RFC3986]. See RFC 3404 [RFC3404]. If a client encounters a record with an unknown flag, it MUST ignore it and move to the next Rule. This test takes precedence over any ordering since flags can control the interpretation placed on fields. A novel flag might change the interpretation of the regexp and/or replacement fields such that it is impossible to determine if a record matched a given target. If this flag is not present then this rule is non-terminal. If a Rule is non-terminal then clients MUST use the Key produced by this Rewrite Rule as the new Key in the DDDS loop (i.e., causing the client to query for new NAPTR records at the domain name that is the result of this Rule). 2.4.3. Services Parameters Service Parameters for this Application take the following form and are found in the Service field of the NAPTR record that holds a terminal rule. Where the NAPTR holds a non-terminal Rule, the Services field SHOULD be empty, and clients SHOULD ignore its content. service-field = "E2U" 1*(servicespec) servicespec = "+" enumservice enumservice = type 0*(subtypespec) subtypespec = ":" subtype type = 1*32(ALPHA / DIGIT / "-") subtype = 1*32(ALPHA / DIGIT / "-") In other words, a non-optional "E2U" (used to denote ENUM only Rewrite Rules in order to mitigate record collisions) followed by one or more Enumservices which indicate the class of functionality a given end point offers. Each Enumservice is indicated by an initial '+' character. 2.4.3.1. ENUM Services Enumservices may be specified and registered via the process defined in "Guide and Template for IANA Registrations of Enumservices" [SV_GUIDE]. This registration process is not open to any Enumservice that has '-' as the second character in its type string. In particular, this registration process is not open to Enumservice types starting with the facet "X-". This "X-" facet is reserved for experimental or trial use, and any such Enumservices cannot be registered using the normal process. Finally, any Enumservice type that starts with the facet "P-" is intended for use exclusively on private networks. As such, NAPTRs containing Enumservice types starting "P-" should not be seen on the global Internet. Even if an ENUM client recognizes and can engage in the Enumservice, it may be incapable of resolving the URI generated by the containing NAPTR. These Enumservices WILL NOT be registered. Such Enumservices MUST NOT be provisioned in any system that provides answers to DNS queries for NAPTR resource record sets from entities outside the private network context in which these Enumservices are intended for use. Unless an ENUM client is sure that it is connected to the private network for which these NAPTRs are provisioned and intended, it MUST discard any NAPTR with an Enumservice type that starts with the "P-" facet. 2.4.3.2. Compound NAPTRs and Implicit ORDER/REFERENCE Values It is possible to have more than one Enumservice associated with a single NAPTR. These Enumservices share the same Regexp field and so generate the same URI. Such a "compound" NAPTR could well be used to indicate a mobile phone that supports both "voice:tel" and "sms:tel" Enumservices. The Services field in that case would be "E2U+voice:tel+sms:tel". A compound NAPTR can be treated as a set of NAPTRs that each hold a single Enumservice. These reconstructed NAPTRs share the same ORDER and PREFERENCE/PRIORITY field values but should be treated as if each had a logically different priority. ENUM clients SHOULD process the Enumservices within a compound NAPTR in a left-to-right sequence. ENUM provisioning systems SHOULD assume that such a processing order will be used and provision the Enumservices within a compound NAPTR accordingly. --------------------------------------------------------------------------- From richard@shockey.us Tue May 26 12:05:05 2009 Return-Path: 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 DE08528C263 for ; Tue, 26 May 2009 12:05:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.233 X-Spam-Level: X-Spam-Status: No, score=-1.233 tagged_above=-999 required=5 tests=[AWL=-0.457, BAYES_05=-1.11, IP_NOT_FRIENDLY=0.334] 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 Rst333xhN+Oj for ; Tue, 26 May 2009 12:05:05 -0700 (PDT) Received: from outbound-mail-15.bluehost.com (outbound-mail-15.bluehost.com [69.89.18.115]) by core3.amsl.com (Postfix) with SMTP id 6ADE028C274 for ; Tue, 26 May 2009 12:04:15 -0700 (PDT) Received: (qmail 27369 invoked by uid 0); 26 May 2009 19:05:56 -0000 Received: from unknown (HELO box462.bluehost.com) (74.220.219.62) by outboundproxy1.bluehost.com with SMTP; 26 May 2009 19:05:56 -0000 DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=default; d=shockey.us; h=Received:From:To:Cc:References:In-Reply-To:Subject:Date:Message-ID:MIME-Version:Content-Type:Content-Transfer-Encoding:X-Mailer:Thread-Index:Content-Language:X-Identified-User; b=U/KGfnVKZggsyAzGbiq4+uobQe5SU3Mo87MwYd4cVTIVDt4hebpwiCBiucGme0dP+aLEqz50XevJXxmLPnJjNgNlmEG11xxlIfU7Ksc68WhtmdqKYTjSZNQ5123U+QK8; Received: from pool-173-66-69-164.washdc.fios.verizon.net ([173.66.69.164] helo=rshockeyPC) by box462.bluehost.com with esmtpa (Exim 4.69) (envelope-from ) id 1M91yG-00030s-Dq; Tue, 26 May 2009 13:05:56 -0600 From: "Richard Shockey" To: "'Bernie Hoeneisen'" References: <20090526172405.GD42439@unknown.office.denic.de> <022501c9de2b$8ffafb40$aff0f1c0$@us> In-Reply-To: Date: Tue, 26 May 2009 15:05:42 -0400 Message-ID: <026e01c9de34$f7dd9750$e798c5f0$@us> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: AcneLplir1ZoPKccQJ2FiE3SvD9YcQABe3+A Content-Language: en-us X-Identified-User: {3286:box462.bluehost.com:shockeyu:shockey.us} {sentby:smtp auth 173.66.69.164 authed with richard+shockey.us} Cc: 'IETF ENUM WG' Subject: Re: [Enum] Meeting [Re: Trunk group document & Charter] X-BeenThere: enum@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Enum Discussion List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 26 May 2009 19:05:06 -0000 > On Tue, 26 May 2009, Richard Shockey wrote: > > > What would we do in Stockholm? What would be the agenda? > > Some topics that come into my mind and might be worth discussing: > > - Status of "unused"? Does anyone care? > > - What to do about the milestone: > "ENUM Privacy and Security Considerations as an Informational"? Another one of mine. Died due to lack of interest. > > - What should be the proper home of Trunk Group? > ENUM or SPEERMINT, or let DISPATCH decide on a new home? A meeting to decide this???? > > - Where will ENUM issues be handled after closure of the ENUM WG? That is a AD issue ...the list remains open no matter what. > > - more...? > > > > We did hum on trunkgroup as a WG item ..I think it was Philadelphia > I just > > need to find the note from the various meeting minutes. > > 1) The WG has never approved the currently discussed variant > > 2) In any case such work requires AD approval, as the ENUM charter > says: > > Other than Enumservices, all proposed deliverables of the > working > group will be discussed with and approved by the Area Directors > > I am not aware of any AD approval. We'll hear from them shortly. > > > cheers, > Bernie From fluffy@cisco.com Thu May 28 18:51:44 2009 Return-Path: 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 3CE043A6BBC for ; Thu, 28 May 2009 18:51:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.571 X-Spam-Level: X-Spam-Status: No, score=-106.571 tagged_above=-999 required=5 tests=[AWL=0.028, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] 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 ofpyVkrM-e6G for ; Thu, 28 May 2009 18:51:43 -0700 (PDT) Received: from sj-iport-6.cisco.com (sj-iport-6.cisco.com [171.71.176.117]) by core3.amsl.com (Postfix) with ESMTP id 69C133A6831 for ; Thu, 28 May 2009 18:51:43 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.41,268,1241395200"; d="scan'208";a="312691350" Received: from sj-dkim-4.cisco.com ([171.71.179.196]) by sj-iport-6.cisco.com with ESMTP; 29 May 2009 01:53:26 +0000 Received: from sj-core-5.cisco.com (sj-core-5.cisco.com [171.71.177.238]) by sj-dkim-4.cisco.com (8.12.11/8.12.11) with ESMTP id n4T1rQCo023195; Thu, 28 May 2009 18:53:26 -0700 Received: from [192.168.4.177] (rcdn-fluffy-8711.cisco.com [10.99.9.18]) by sj-core-5.cisco.com (8.13.8/8.13.8) with ESMTP id n4T1rPpC013584; Fri, 29 May 2009 01:53:26 GMT Message-Id: <3488F382-51CB-4994-8CA4-3DE1040B06F5@cisco.com> From: Cullen Jennings To: enum@ietf.org Impp: xmpp:cullenfluffyjennings@jabber.org Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v935.3) Date: Thu, 28 May 2009 19:53:25 -0600 X-Mailer: Apple Mail (2.935.3) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=1611; t=1243562006; x=1244426006; c=relaxed/simple; s=sjdkim4002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=fluffy@cisco.com; z=From:=20Cullen=20Jennings=20 |Subject:=20Future=20outlook=20for=20ENUM=20WG |Sender:=20; bh=LfYf6lsKu3mIGrc37udyugI8zpOa9sju/LtlyZYPRaw=; b=HF/hBXu+EtFx4YbibtT5Hv3MdeFwO/aB+hBnbQ29XP8j4cPX/KZ49wdi2d QiipuL+gKlelEe8yjt6GOtZyAXkPaJvNoHCv9FtB4n+14KdwTRGayApUeP3f KZQ90phpYF; Authentication-Results: sj-dkim-4; header.From=fluffy@cisco.com; dkim=pass ( sig from cisco.com/sjdkim4002 verified; ); Cc: enum-chairs@tools.ietf.org Subject: [Enum] Future outlook for ENUM WG X-BeenThere: enum@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Enum Discussion List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 29 May 2009 01:51:44 -0000 With the publication of the 3761bis, and the enum services guide, I view the key work of this WG pretty much done and hope to close the WG when the current things in the queue get approved. This does not mean I don't expect more ENUM registrations and extensions - I do expect many but we should have the expertise to handles these without a WG. The enum services guide is the key thing to both make it easier to create a registration and provide the advice to make sure that an we get it right and only require the resources of an good expert review instead of a whole WG. This does lead to the topic of what about trunk groups. The key questions for me as an AD are: 1) are there people that have a need for the trunk groups in enum 2) are there solutions that are architecturally sane and not going to cause harm 3) is the approach in draft-malas-enum-trunk-sip the right one to use as starting point for the solution 4) where does the expertise exist to make sure the right people are involved with the discussions and review Right now I don't know enough to be able to answer these but my current leaning is 1) probably yes 2) yes 3) probably yes - seems like bulk of folks prefer draft-malas to draft- ietf-enum-trunkgroup 4) If the answers to the above are yes, where to do the work is easy to figure out and no big deal. We will have a place to do the work. It is very unlikely it would be done as an enum WG document but I have no problem with having the discussion happening on enum list for now. Cullen