From enum-bounces@ietf.org Wed Oct 1 10:31:25 2008 Return-Path: X-Original-To: enum-archive@megatron.ietf.org Delivered-To: ietfarch-enum-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8F5763A6A85; Wed, 1 Oct 2008 10:31:25 -0700 (PDT) X-Original-To: enum@core3.amsl.com Delivered-To: enum@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A6DC23A6A85 for ; Wed, 1 Oct 2008 10:31:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.386 X-Spam-Level: X-Spam-Status: No, score=-2.386 tagged_above=-999 required=5 tests=[AWL=0.213, 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 BBenWCghzISi for ; Wed, 1 Oct 2008 10:31:19 -0700 (PDT) Received: from mail.songbird.com (unknown [IPv6:2001:470:1:76:2c0:9fff:fe3e:4009]) by core3.amsl.com (Postfix) with ESMTP id 49E993A699C for ; Wed, 1 Oct 2008 10:31:19 -0700 (PDT) Received: from rshockeyPC (neustargw.va.neustar.com [209.173.53.233]) (authenticated bits=0) by mail.songbird.com (8.12.11.20060308/8.12.11) with ESMTP id m91HS26M011670 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO) for ; Wed, 1 Oct 2008 10:28:18 -0700 From: "Richard Shockey" To: Date: Wed, 1 Oct 2008 13:29:03 -0400 Message-ID: <01cb01c923eb$45fb17a0$d1f146e0$@us> MIME-Version: 1.0 X-Mailer: Microsoft Office Outlook 12.0 thread-index: AcixUphCrQNxun4USEeHYKE4dfnbnxyl38Fg Content-Language: en-us X-SongbirdInformation: support@songbird.com for more information X-Songbird: Clean X-Songbird-From: richard@shockey.us Subject: [Enum] FW: I-D ACTION:draft-ietf-enum-enumservice-sms-smpp-01.txt WGLC ???? 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: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: enum-bounces@ietf.org Errors-To: enum-bounces@ietf.org In our desire to clean up the document queue... are we ready for WGLC on this? -----Original Message----- From: i-d-announce-bounces@ietf.org [mailto:i-d-announce-bounces@ietf.org] On Behalf Of Internet-Drafts@ietf.org Sent: Thursday, May 08, 2008 5:30 PM To: i-d-announce@ietf.org Cc: enum@ietf.org Subject: I-D ACTION:draft-ietf-enum-enumservice-sms-smpp-01.txt 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 : IANA Registrations of Enumservice "sms:smpp" and "smpp" URI Author(s) : J. Yu Filename : draft-ietf-enum-enumservice-sms-smpp-01.txt Pages : 12 Date : 2008-5-8 This document updates RFC 4355 by registering a new enumservice subtype "smpp" under the existing type "sms" using the URI scheme "smpp" as per the IANA registration process defined in RFC 3761 and draft-ietf-enum-enumservices-guide-07 and registers a new URI scheme "smpp" according to the URI registration procedure in RFC 4395. This enumservice subtype indicates that the remote resource identified by the URI can receive short messages using the Short Message Peer-to-Peer Protocol (SMPP). A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-enum-enumservice-sms-smpp-01. 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. _______________________________________________ enum mailing list enum@ietf.org https://www.ietf.org/mailman/listinfo/enum From enum-bounces@ietf.org Thu Oct 2 01:56:28 2008 Return-Path: X-Original-To: enum-archive@megatron.ietf.org Delivered-To: ietfarch-enum-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 88F1D3A6A9C; Thu, 2 Oct 2008 01:56:28 -0700 (PDT) X-Original-To: enum@core3.amsl.com Delivered-To: enum@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 64C083A6A9C for ; Thu, 2 Oct 2008 01:56:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.599 X-Spam-Level: X-Spam-Status: No, score=-5.599 tagged_above=-999 required=5 tests=[AWL=0.650, 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 Jn18Lo8RjaIz for ; Thu, 2 Oct 2008 01:56:24 -0700 (PDT) Received: from office.denic.de (gw-office.denic.de [81.91.160.182]) by core3.amsl.com (Postfix) with ESMTP id DC4723A691D for ; Thu, 2 Oct 2008 01:56:23 -0700 (PDT) Received: from denic.de ([10.122.65.106]) by office.denic.de with esmtp id 1KlJyO-0000ts-LV; Thu, 02 Oct 2008 10:55:48 +0200 Received: by unknown.office.denic.de (Postfix, from userid 501) id 871F6828962; Thu, 2 Oct 2008 10:55:48 +0200 (CEST) Date: Thu, 2 Oct 2008 10:55:48 +0200 From: Peter Koch To: IETF ENUM WG Message-ID: <20081002085548.GB36818@unknown.office.denic.de> Mail-Followup-To: IETF ENUM WG References: <01cb01c923eb$45fb17a0$d1f146e0$@us> Mime-Version: 1.0 Content-Disposition: inline In-Reply-To: <01cb01c923eb$45fb17a0$d1f146e0$@us> User-Agent: Mutt/1.4.2.1i Subject: Re: [Enum] FW: I-D ACTION:draft-ietf-enum-enumservice-sms-smpp-01.txt WGLC ???? 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: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: enum-bounces@ietf.org Errors-To: enum-bounces@ietf.org On Wed, Oct 01, 2008 at 01:29:03PM -0400, Richard Shockey wrote: > In our desire to clean up the document queue... are we ready for WGLC on > this? > Title : IANA Registrations of Enumservice > "sms:smpp" and "smpp" URI > Author(s) : J. Yu > Filename : draft-ietf-enum-enumservice-sms-smpp-01.txt I understand the draft updates an existing registration, as stated in This document updates RFC 4355 [4] by registering a new enumservice subtype "smpp" under the existing type "sms" using the URI scheme "smpp" as per the IANA registration process defined in RFC 3761 [2] and draft-ietf-enum-enumservices-guide-07 [12] and registers a new URI scheme "smpp" according to the URI registration procedure in RFC 4395 [5]. but how can it refer to both Enumservice registration procedures at the same time? Isn't this an update that can wait until after approval of the Enumservice guidelines or is a standards track document really intended? My reading of the example in section 6 is that it actually contains the specification for the "smpp:" URI resolution. The extra abbreviations section is uncommon for RFCs and since most of the abbreviations are pretty well expanded in the text within proper context (SRV=Service only makes sense if you have the RR type in mind), I'd doubt its necessity. -Peter _______________________________________________ enum mailing list enum@ietf.org https://www.ietf.org/mailman/listinfo/enum From enum-bounces@ietf.org Fri Oct 3 01:15:22 2008 Return-Path: X-Original-To: enum-archive@megatron.ietf.org Delivered-To: ietfarch-enum-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 24A523A6A9E; Fri, 3 Oct 2008 01:15:22 -0700 (PDT) X-Original-To: enum@core3.amsl.com Delivered-To: enum@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 43EE13A6A9E for ; Fri, 3 Oct 2008 01:15:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.349 X-Spam-Level: X-Spam-Status: No, score=-4.349 tagged_above=-999 required=5 tests=[AWL=-0.750, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] 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 Uf1dLT4-4QRJ for ; Fri, 3 Oct 2008 01:15:20 -0700 (PDT) Received: from mail.swisscom.com (outmail20.swisscom.com [138.190.32.10]) by core3.amsl.com (Postfix) with ESMTP id 1874C3A67E3 for ; Fri, 3 Oct 2008 01:15:19 -0700 (PDT) Received: by mrz.swissptt.ch; Fri, 3 Oct 2008 10:15:20 +0200 (MEST) From: To: Date: Fri, 3 Oct 2008 10:15:16 +0200 Thread-Topic: [IANA #197380] No IANA feedback for draft-ietf-enum-enumservices-guide-12 received Thread-Index: Ackj8CPVBFBgIiC5SwC5F37I/EpdsQBPj41Q Message-ID: <57582E8F684F0447BEA7762D5F71AFB10E7C090E29@sg000004.corproot.net> References: <57582E8F684F0447BEA7762D5F71AFB10E7C0908DC@sg000004.corproot.net> In-Reply-To: Accept-Language: en-US, de-CH Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US, de-CH MIME-Version: 1.0 X-OriginalArrivalTime: 03 Oct 2008 08:15:18.0446 (UTC) FILETIME=[2C0CBCE0:01C92530] Cc: enum@ietf.org Subject: Re: [Enum] [IANA #197380] No IANA feedback for draft-ietf-enum-enumservices-guide-12 received 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: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: enum-bounces@ietf.org Errors-To: enum-bounces@ietf.org Hi Michelle Thanks for your answer. To summarize, in Ticket [IANA #171390] there are basically two open issues: 1) How should the specification look, if an IANA Registry is in XML? 2) Is the process as currently described in draft-ietf-enum-enumservices-guide-12 suitable for IANA? (We made some major changes since our talk in Dublin.) We would appreciate your answer to these two questions by the end of this week. cheers, Bernie -----Original Message----- From: Michelle Cotton via RT [mailto:iana-issues@icann.org] Sent: Wednesday, October 01, 2008 8:02 PM To: Hoeneisen Bernhard, SCS-NIT-DEV-PDI-ACE-INV; jaap@NLnetLabs.nl Subject: [IANA #197380] No IANA feedback for draft-ietf-enum-enumservices-guide-12 received Bernie, I will see if it will be possible to have the XML format for enumservices ready by the end of this week. I will let you know by Friday. As you mention in your message to the ENUM WG, if need be we can have it in the old format and we will convert the registry at a later time. Thank you for your patience. Look for a message from me by Friday. Michelle Cotton IANA On Tue Sep 30 21:19:56 2008, Bernhard.Hoeneisen@swisscom.com wrote: > Dear ENUM WG > > In Dublin we have been asked to use the new XMLized policy for IANA > registrations of Enumservices. According to my knowledge, there is > neither documentation nor an example on how this is done. > > I have sent IANA a draft proposal containing an XML schema and asked > for guidance on how a specification for an XML Registry should look > like. I also stressed out the fact that the document was in WG LC. > > Result: So far, no answer at all :-( > > Does anybody have direct connections to IANA and could remind them to > resolv the issues collected in ticket [IANA #171390] ASAP? > > I there is no answer from IANA by the end of this week, we'll go on > with the old-style IANA Registry for Enumservices (i.e. forget about > XML Registry). > Does anybody have an issue with this approach? Any better proposals on > how to get out of this lock? > > cheers, > Bernie > > _______________________________________________ enum mailing list enum@ietf.org https://www.ietf.org/mailman/listinfo/enum From enum-bounces@ietf.org Fri Oct 3 06:34:07 2008 Return-Path: X-Original-To: enum-archive@megatron.ietf.org Delivered-To: ietfarch-enum-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 590313A6839; Fri, 3 Oct 2008 06:34:07 -0700 (PDT) X-Original-To: enum@core3.amsl.com Delivered-To: enum@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id CCDC43A6839 for ; Fri, 3 Oct 2008 06:34:05 -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=[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 UnCxbr2mVq4C for ; Fri, 3 Oct 2008 06:34:04 -0700 (PDT) Received: from kahua.nona.net (pahula.nona.net [193.80.224.123]) by core3.amsl.com (Postfix) with ESMTP id 9DE503A6821 for ; Fri, 3 Oct 2008 06:34:04 -0700 (PDT) Received: from [10.10.0.114] ([::ffff:83.136.33.3]) (AUTH: PLAIN axelm, TLS: TLSv1/SSLv3,256bits,AES256-SHA) by pahula with esmtp; Fri, 03 Oct 2008 15:34:26 +0200 id 000380B5.48E61F62.00001417 Message-ID: <48E61F55.8070300@enum.at> Date: Fri, 03 Oct 2008 15:34:13 +0200 From: Alexander Mayrhofer Organization: enum.at GmbH User-Agent: Thunderbird 2.0.0.17 (Windows/20080914) MIME-Version: 1.0 To: enum@ietf.org Subject: [Enum] review of draft-ietf-enum-enumservice-smpp-01 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: , Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed" Sender: enum-bounces@ietf.org Errors-To: enum-bounces@ietf.org Hi, I've done a review of the SMPP Enumservice draft. In short, there are a couple of formatting nits, plus there are some content issues, mostly with the URI scheme definition. For some of the topics, i'm definitely far away from being an expert, so i suggest additional review from URI and SMPP experts. Considering the Enumservice itself, the draft is pretty straightforward - however, i feel the smpp URI definition is very weak. comments in detail: - NITS: There are a bunch of formatting problems with the draft, most notably the missing page breaks. Please see http://tools.ietf.org/idnits?url=http://tools.ietf.org/id/draft-ietf-enum-enumservice-sms-smpp-01.txt - I'm not an expert at all on GSM systems. I'd appreciate if someone more familiar with SMS could review the introduction and the use cases. - I don't think that "RFC 4355 allows subtypes to be defined.." (section 4). It would be better to say that "RFC 4355 defines the Subtypes "tel" and "mailto" for the "sms" Type Enumservice. This document extends the "sms" Type by adding the "smpp" Subtype to that set of services" (or something along those lines) - Secion 4 should also refer to the Formal Syntax of the Enumservice (it does only for the URI scheme) - As said above, i'd appreciate an SMS expert to review the use cases. Additionally, i'm confused by the paragraph that starts at the very end of "page" 5, and spans to the top of "page" 6. It looks as if there is either some text lost between those two parts, or some text has been copied there accidentially from somewhere else.. - "Example" - I don't see the dereferencing of the URI scheme specified anywhere else. I don't think an example is sufficient for that - please add specification on how a smpp URI is dereferenced to the respective section. - From what i know, URI scheme registrations also require some text on how URIs are compared. I can't find any text about this in the draft either. - The "Security considerations" of the Enumservice describes an assumption of an use case, not actual security risks and measures. There should be some text like "an SMPP URI might reveal internal network elements and relations between numbers and operators... etc...", because that would describe the threat rather than the assumed scenario to mitigate that risk. Same for the second paragraph, which doesn't mention risks, but describes an usage scenario. The Enumservice security considerations should also only list considerations that are specific to the use within ENUM, not general URI scheme considerations. - The URI scheme is heavily underspecified. For example, even though the "headers" component is described in RFC 3261, there is no functional description of how those headers are actually used in SMPP (from what i know, SMPP doesn't provide a concept of "Headers". RFC 3261 says: "Headers: Header fields to be included in a request constructed from the URI." That simply does not fit into the SMPP concept - therefore the specification is extremely weak. Same for the "userinfo". Also, the "parameter" component might require a registry (compare the hassle with the "tel" URI...) I don't see how an implementor would be able to correctly implement handling the "smpp" URI with the information that is currently contained in the document - which in turn might make interopability much harder, because of a variety of interpretations of URI components... I do suggest that the author contacts the URI-review list, and discusses the draft with the list members. To conclude, the Enumservice registration looks ready for WGLC, the URI scheme definition IMHO definitely does not (but i don't see the expertise for that within the ENUM working group, which is a different issue). comments? Alex _______________________________________________ enum mailing list enum@ietf.org https://www.ietf.org/mailman/listinfo/enum From enum-bounces@ietf.org Fri Oct 3 10:48:33 2008 Return-Path: X-Original-To: enum-archive@megatron.ietf.org Delivered-To: ietfarch-enum-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id DBBCC28C149; Fri, 3 Oct 2008 10:48:33 -0700 (PDT) X-Original-To: enum@core3.amsl.com Delivered-To: enum@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8F4ED28C149 for ; Fri, 3 Oct 2008 10:48:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.28 X-Spam-Level: X-Spam-Status: No, score=-0.28 tagged_above=-999 required=5 tests=[AWL=0.183, 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 JdNVeQqoiLeZ for ; Fri, 3 Oct 2008 10:48:31 -0700 (PDT) Received: from paoakoavas09.cable.comcast.com (paoakoavas09.cable.comcast.com [208.17.35.58]) by core3.amsl.com (Postfix) with ESMTP id A1A9E28C14C for ; Fri, 3 Oct 2008 10:48:30 -0700 (PDT) Received: from ([24.40.15.118]) by paoakoavas09.cable.comcast.com with ESMTP id KP-NTF18.61084728; Fri, 03 Oct 2008 13:48:43 -0400 Received: from PACDCEXCMB04.cable.comcast.com ([24.40.15.86]) by PACDCEXCSMTP04.cable.comcast.com with Microsoft SMTPSVC(6.0.3790.3959); Fri, 3 Oct 2008 13:48:44 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Fri, 3 Oct 2008 13:48:42 -0400 Message-ID: <45AEC6EF95942140888406588E1A660205B9E37F@PACDCEXCMB04.cable.comcast.com> In-Reply-To: <57582E8F684F0447BEA7762D5F71AFB10E7C0908D2@sg000004.corproot.net> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Enum] Working Group Last Call on enumservices guide 12 Thread-Index: AckcEgSpQoF6wwV7Rs2i3lBTpgGldwHDWpswAAMfS7AAlQLL0A== References: <09d901c91031$74145020$5c3cf060$@us><20080921174528.GA12658@x27.adm.denic.de><0e6a01c92320$00675f30$01361d90$@us> <57582E8F684F0447BEA7762D5F71AFB10E7C0908D2@sg000004.corproot.net> From: "Livingood, Jason" To: , , X-OriginalArrivalTime: 03 Oct 2008 17:48:44.0361 (UTC) FILETIME=[4792BB90:01C92580] Cc: Alexander Mayrhofer Subject: Re: [Enum] Working Group Last Call on enumservices guide 12 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: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: enum-bounces@ietf.org Errors-To: enum-bounces@ietf.org Bernie & Rich - I can take another turn of the document to handle this. Jason > -----Original Message----- > From: enum-bounces@ietf.org [mailto:enum-bounces@ietf.org] On > Behalf Of Bernhard.Hoeneisen@swisscom.com > Sent: Tuesday, September 30, 2008 2:54 PM > To: richard@shockey.us; enum@ietf.org > Subject: Re: [Enum] Working Group Last Call on enumservices guide 12 > > Hi Rich > > We'll certainly consider Peter's feedback and issue a revision -13. > > As I expressed in Dublin, Swisscom is not supporting me for > this work any longer, so I'll have to do it all in my > freetime. (And freetime is precious at the moment as there is > also all my NomCom work to be done in my freetime.) Therefore > it might take a while. > > I hope we can issue -13 soon, but unfortunately these are my > boundary conditions... > > cheers, > Bernie > > > -----Original Message----- > From: enum-bounces@ietf.org [mailto:enum-bounces@ietf.org] On > Behalf Of Richard Shockey > Sent: Tuesday, September 30, 2008 7:14 PM > To: 'Peter Koch'; 'IETF ENUM WG' > Subject: Re: [Enum] Working Group Last Call on enumservices guide 12 > > [...] > > In any event WGLC is now over. I'm wondering if the authors > want to incorporate any of Peter's suggestions into a 13 > version before the chairs request publication. > _______________________________________________ > 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 enum-bounces@ietf.org Fri Oct 3 12:55:47 2008 Return-Path: X-Original-To: enum-archive@megatron.ietf.org Delivered-To: ietfarch-enum-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 5A8D43A6859; Fri, 3 Oct 2008 12:55:47 -0700 (PDT) X-Original-To: enum@core3.amsl.com Delivered-To: enum@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 699903A6859 for ; Fri, 3 Oct 2008 12:55:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.457 X-Spam-Level: X-Spam-Status: No, score=-2.457 tagged_above=-999 required=5 tests=[AWL=0.142, 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 yfXBNFDsEVld for ; Fri, 3 Oct 2008 12:55:44 -0700 (PDT) Received: from mail.songbird.com (unknown [IPv6:2001:470:1:76:2c0:9fff:fe3e:4009]) by core3.amsl.com (Postfix) with ESMTP id 3C1DB3A683A for ; Fri, 3 Oct 2008 12:55:42 -0700 (PDT) Received: from rshockeyPC (neustargw.va.neustar.com [209.173.53.233]) (authenticated bits=0) by mail.songbird.com (8.12.11.20060308/8.12.11) with ESMTP id m93JpDPo004744 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Fri, 3 Oct 2008 12:51:34 -0700 From: "Richard Shockey" To: "'Livingood, Jason'" , , References: <09d901c91031$74145020$5c3cf060$@us><20080921174528.GA12658@x27.adm.denic.de><0e6a01c92320$00675f30$01361d90$@us> <57582E8F684F0447BEA7762D5F71AFB10E7C0908D2@sg000004.corproot.net> <45AEC6EF95942140888406588E1A660205B9E37F@PACDCEXCMB04.cable.comcast.com> In-Reply-To: <45AEC6EF95942140888406588E1A660205B9E37F@PACDCEXCMB04.cable.comcast.com> Date: Fri, 3 Oct 2008 15:52:10 -0400 Message-ID: <01f101c92591$b39daaf0$1ad900d0$@us> MIME-Version: 1.0 X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: AckcEgSpQoF6wwV7Rs2i3lBTpgGldwHDWpswAAMfS7AAlQLL0AAEVw+A Content-Language: en-us X-SongbirdInformation: support@songbird.com for more information X-Songbird: Clean X-Songbird-From: richard@shockey.us Cc: 'Alexander Mayrhofer' , =?iso-8859-1?Q?'Patrik_F=E4ltstr=F6m'?= Subject: Re: [Enum] Working Group Last Call on enumservices guide 12 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: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: enum-bounces@ietf.org Errors-To: enum-bounces@ietf.org Works for the chairs... we'll request publication as soon as a 13 crosses the wire. We're trying to clear the queue. > -----Original Message----- > From: Livingood, Jason [mailto:Jason_Livingood@cable.comcast.com] > Sent: Friday, October 03, 2008 1:49 PM > To: Bernhard.Hoeneisen@swisscom.com; richard@shockey.us; enum@ietf.org > Cc: Alexander Mayrhofer > Subject: RE: [Enum] Working Group Last Call on enumservices guide 12 > > Bernie & Rich - > > I can take another turn of the document to handle this. > > Jason > > > -----Original Message----- > > From: enum-bounces@ietf.org [mailto:enum-bounces@ietf.org] On > > Behalf Of Bernhard.Hoeneisen@swisscom.com > > Sent: Tuesday, September 30, 2008 2:54 PM > > To: richard@shockey.us; enum@ietf.org > > Subject: Re: [Enum] Working Group Last Call on enumservices guide 12 > > > > Hi Rich > > > > We'll certainly consider Peter's feedback and issue a revision -13. > > > > As I expressed in Dublin, Swisscom is not supporting me for > > this work any longer, so I'll have to do it all in my > > freetime. (And freetime is precious at the moment as there is > > also all my NomCom work to be done in my freetime.) Therefore > > it might take a while. > > > > I hope we can issue -13 soon, but unfortunately these are my > > boundary conditions... > > > > cheers, > > Bernie > > > > > > -----Original Message----- > > From: enum-bounces@ietf.org [mailto:enum-bounces@ietf.org] On > > Behalf Of Richard Shockey > > Sent: Tuesday, September 30, 2008 7:14 PM > > To: 'Peter Koch'; 'IETF ENUM WG' > > Subject: Re: [Enum] Working Group Last Call on enumservices guide 12 > > > > [...] > > > > In any event WGLC is now over. I'm wondering if the authors > > want to incorporate any of Peter's suggestions into a 13 > > version before the chairs request publication. > > _______________________________________________ > > 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 enum-bounces@ietf.org Fri Oct 3 13:34:02 2008 Return-Path: X-Original-To: enum-archive@megatron.ietf.org Delivered-To: ietfarch-enum-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 9D02128C2B7; Fri, 3 Oct 2008 13:34:02 -0700 (PDT) X-Original-To: enum@core3.amsl.com Delivered-To: enum@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B537428C2AC; Fri, 3 Oct 2008 13:34:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -17.419 X-Spam-Level: X-Spam-Status: No, score=-17.419 tagged_above=-999 required=5 tests=[AWL=0.180, 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 D1a7jyE+LB4N; Fri, 3 Oct 2008 13:34:00 -0700 (PDT) Received: from bosco.isi.edu (bosco.isi.edu [128.9.168.207]) by core3.amsl.com (Postfix) with ESMTP id DA64628C17E; Fri, 3 Oct 2008 13:34:00 -0700 (PDT) Received: by bosco.isi.edu (Postfix, from userid 70) id B0D6615F9EC; Fri, 3 Oct 2008 13:34:30 -0700 (PDT) To: ietf-announce@ietf.org, rfc-dist@rfc-editor.org From: rfc-editor@rfc-editor.org Message-Id: <20081003203430.B0D6615F9EC@bosco.isi.edu> Date: Fri, 3 Oct 2008 13:34:30 -0700 (PDT) Cc: enum@ietf.org, rfc-editor@rfc-editor.org Subject: [Enum] RFC 5346 on Operational Requirements for ENUM-Based Softswitch Use 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: , MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: enum-bounces@ietf.org Errors-To: enum-bounces@ietf.org A new Request for Comments is now available in online RFC libraries. RFC 5346 Title: Operational Requirements for ENUM-Based Softswitch Use Author: J. Lim, W. Kim, C. Park, L. Conroy Status: Informational Date: October 2008 Mailbox: jhlim@nida.or.kr, wkim@nida.or.kr, ckp@nida.or.kr, lconroy@insensate.co.uk Pages: 14 Characters: 31050 Updates/Obsoletes/SeeAlso: None I-D Tag: draft-ietf-enum-softswitch-req-04.txt URL: http://www.rfc-editor.org/rfc/rfc5346.txt This document describes experiences of operational requirements and several considerations for ENUM-based softswitches concerning call routing between two Korean Voice over IP (VoIP) carriers, gained during the ENUM pre-commercial trial hosted by the National Internet Development Agency of Korea (NIDA) in 2006. These experiences show that an interim solution can maintain the stability of ongoing commercial softswitch system operations during the initial stage of ENUM service, where the DNS does not have sufficient data for the majority of calls. 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 _______________________________________________ enum mailing list enum@ietf.org https://www.ietf.org/mailman/listinfo/enum From enum-bounces@ietf.org Fri Oct 3 15:28:29 2008 Return-Path: X-Original-To: enum-archive@megatron.ietf.org Delivered-To: ietfarch-enum-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 46EB53A6968; Fri, 3 Oct 2008 15:28:29 -0700 (PDT) X-Original-To: enum@core3.amsl.com Delivered-To: enum@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id ED5973A6968 for ; Fri, 3 Oct 2008 15:28:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.311 X-Spam-Level: X-Spam-Status: No, score=-0.311 tagged_above=-999 required=5 tests=[AWL=0.152, 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 dIAbWZBpgIn8 for ; Fri, 3 Oct 2008 15:28:27 -0700 (PDT) Received: from paoakoavas09.cable.comcast.com (paoakoavas09.cable.comcast.com [208.17.35.58]) by core3.amsl.com (Postfix) with ESMTP id 03C543A6923 for ; Fri, 3 Oct 2008 15:28:26 -0700 (PDT) Received: from ([24.40.15.118]) by paoakoavas09.cable.comcast.com with ESMTP id KP-NTF18.61101138; Fri, 03 Oct 2008 18:28:41 -0400 Received: from PACDCEXCMB04.cable.comcast.com ([24.40.15.86]) by PACDCEXCSMTP04.cable.comcast.com with Microsoft SMTPSVC(6.0.3790.3959); Fri, 3 Oct 2008 18:28:41 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Fri, 3 Oct 2008 18:28:28 -0400 Message-ID: <45AEC6EF95942140888406588E1A660205B9E38B@PACDCEXCMB04.cable.comcast.com> In-Reply-To: <01f101c92591$b39daaf0$1ad900d0$@us> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Enum] Working Group Last Call on enumservices guide 12 Thread-Index: AckcEgSpQoF6wwV7Rs2i3lBTpgGldwHDWpswAAMfS7AAlQLL0AAEVw+AAAVzY/A= References: <09d901c91031$74145020$5c3cf060$@us><20080921174528.GA12658@x27.adm.denic.de><0e6a01c92320$00675f30$01361d90$@us> <57582E8F684F0447BEA7762D5F71AFB10E7C0908D2@sg000004.corproot.net> <45AEC6EF95942140888406588E1A660205B9E37F@PACDCEXCMB04.cable.comcast.com> <01f101c92591$b39daaf0$1ad900d0$@us> From: "Livingood, Jason" To: "Richard Shockey" , , X-OriginalArrivalTime: 03 Oct 2008 22:28:41.0796 (UTC) FILETIME=[639FE840:01C925A7] Cc: Alexander Mayrhofer , =?iso-8859-1?Q?Patrik_F=E4ltstr=F6m?= Subject: Re: [Enum] Working Group Last Call on enumservices guide 12 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: , Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Sender: enum-bounces@ietf.org Errors-To: enum-bounces@ietf.org I just sent my revision to Alex and Bernie and I sent one open question to = you, Rich, that we may need help with. Also, I have one open question with my co-authors on whether to drop the XM= L Template Appendix or not. Depending upon the outcome of each of these questions, a quick revision can= be made next week and we'll submit the -13 then. Regards Jason > -----Original Message----- > From: Richard Shockey [mailto:richard@shockey.us] = > Sent: Friday, October 03, 2008 3:52 PM > To: Livingood, Jason; Bernhard.Hoeneisen@swisscom.com; enum@ietf.org > Cc: 'Alexander Mayrhofer'; 'Patrik F=E4ltstr=F6m' > Subject: RE: [Enum] Working Group Last Call on enumservices guide 12 > = > Works for the chairs... we'll request publication as soon as = > a 13 crosses the wire. > = > We're trying to clear the queue. > = > > -----Original Message----- > > From: Livingood, Jason [mailto:Jason_Livingood@cable.comcast.com] > > Sent: Friday, October 03, 2008 1:49 PM > > To: Bernhard.Hoeneisen@swisscom.com; richard@shockey.us; = > > enum@ietf.org > > Cc: Alexander Mayrhofer > > Subject: RE: [Enum] Working Group Last Call on = > enumservices guide 12 > > = > > Bernie & Rich - > > = > > I can take another turn of the document to handle this. > > = > > Jason > > = > > > -----Original Message----- > > > From: enum-bounces@ietf.org [mailto:enum-bounces@ietf.org] On > = > > Behalf Of Bernhard.Hoeneisen@swisscom.com > Sent: Tuesday, = > September = > > 30, 2008 2:54 PM > To: richard@shockey.us; enum@ietf.org = > > Subject: = > > Re: [Enum] Working Group Last Call on enumservices guide 12 = > > > Hi = > > Rich > > We'll certainly consider Peter's feedback and issue a = > > revision -13. > > > > > > As I expressed in Dublin, Swisscom is not supporting me = > for > this = > > work any longer, so I'll have to do it all in my > freetime. (And = > > freetime is precious at the moment as there is > also all = > my NomCom = > > work to be done in my freetime.) Therefore > it might take a while. > > > > > > I hope we can issue -13 soon, but unfortunately these are my > = > > boundary conditions... > > > > > > cheers, > > > Bernie > > > > > > > > > -----Original Message----- > > > From: enum-bounces@ietf.org [mailto:enum-bounces@ietf.org] On > = > > Behalf Of Richard Shockey > Sent: Tuesday, September 30, = > 2008 7:14 PM = > > > To: 'Peter Koch'; 'IETF ENUM WG' > > > Subject: Re: [Enum] Working Group Last Call on = > enumservices guide = > > 12 > > [...] > > In any event WGLC is now over. I'm = > wondering if = > > the authors > want to incorporate any of Peter's = > suggestions into a = > > 13 > version before the chairs request publication. > > > _______________________________________________ > > > 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 enum-bounces@ietf.org Sun Oct 5 07:06:48 2008 Return-Path: X-Original-To: enum-archive@megatron.ietf.org Delivered-To: ietfarch-enum-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 27D1D3A67F5; Sun, 5 Oct 2008 07:06:48 -0700 (PDT) X-Original-To: enum@core3.amsl.com Delivered-To: enum@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 9E0C328C120 for ; Fri, 3 Oct 2008 13:48:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.307 X-Spam-Level: X-Spam-Status: No, score=-1.307 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, MISSING_HEADERS=1.292] 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 DNGIXGtAUq4q for ; Fri, 3 Oct 2008 13:48:05 -0700 (PDT) Received: from request.iana.org (request.iana.org [208.77.188.221]) by core3.amsl.com (Postfix) with ESMTP id C93693A685E for ; Fri, 3 Oct 2008 13:48:05 -0700 (PDT) Received: from request.iana.org (localhost.localdomain [127.0.0.1]) by request.iana.org (8.13.8/8.13.8) with ESMTP id m93KlZCh018787; Fri, 3 Oct 2008 13:47:35 -0700 Received: (from apache@localhost) by request.iana.org (8.13.8/8.13.8/Submit) id m93KlZY2018786; Fri, 3 Oct 2008 20:47:35 GMT From: "Michelle Cotton via RT" In-Reply-To: References: <57582E8F684F0447BEA7762D5F71AFB10E7C0908DC@sg000004.corproot.net> <57582E8F684F0447BEA7762D5F71AFB10E7C090E29@sg000004.corproot.net> Message-ID: Precedence: bulk X-RT-Loop-Prevention: IANA RT-Ticket: IANA #171390 Managed-by: RT 3.8.1 (http://www.bestpractical.com/rt/) RT-Originator: michelle.cotton@icann.org MIME-Version: 1.0 X-RT-Original-Encoding: utf-8 Date: Fri, 3 Oct 2008 20:47:35 +0000 X-Mailman-Approved-At: Sun, 05 Oct 2008 07:06:47 -0700 Cc: enum@ietf.org, marc.blanchet@viagenie.ca, simon.perreault@viagenie.ca Subject: [Enum] [IANA #171390] FW: Revision of IANA Enumservice registry X-BeenThere: enum@ietf.org X-Mailman-Version: 2.1.9 Reply-To: iana-issues@icann.org List-Id: Enum Discussion List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: enum-bounces@ietf.org Errors-To: enum-bounces@ietf.org Hi Bernie, I've chatted with our XML folks helping us with the conversions. (They are copied on this message) They will begin converting the current registry next week. See more responses inline below. On Fri Oct 03 08:15:52 2008, Bernhard.Hoeneisen@swisscom.com wrote: > Hi Michelle > > Thanks for your answer. > > To summarize, in Ticket [IANA #171390] there are basically two open > issues: > > 1) How should the specification look, if an IANA Registry is in XML? If someone writes a document to add a new registration to the enum-services registry, it would be great if they included in their document an XML chunk that IANA would simply cut and paste in the registry itself after the registration is approved. The spec itself does not have to be in XML. > > 2) Is the process as currently described in draft-ietf-enum- > enumservices-guide-12 suitable for IANA? (We made some major > changes since our talk in Dublin.) I've reviewed version 12 of the document. All seems pretty good. I do have the following comments: In section 11.1.2., I understand that it is requested that IANA archive the specification in the cases of it not being an RFC. Will IANA need to make that document public or just archive it for purposes of inquires and registration? I see the use "Authors" frequently. We mainly use the term "Requester". The expert review process in this document is slightly different than the one that IANA currently uses. For most registries, requests are sent to IANA, we forward the request to the expert for review, after the approval IANA registers the parameter and then notifies the requester of the completed registration. In this case, the expert is approving the template and it appears they also have to approve the specification after it is published? It seems a bit fuzzy to me. Or is this the case where the expert my assist in making the template better before it gets finalization in a document? If that is the case, then IANA will have to go to the expert twice in this case? Once for the enumservice template, and then second to verify the specification has been published. Tell me if I'm mistaken in my understanding of the instructions. :) Also, for the document, having the xml chunk for the registration itself would be very useful. We can help with providing what that should look like as we convert the registry in the next few weeks. > > We would appreciate your answer to these two questions by the end of > this week. > > cheers, > Bernie > I hope this helps. Please let us know if you have any further questions. Best regards, Michelle IANA _______________________________________________ enum mailing list enum@ietf.org https://www.ietf.org/mailman/listinfo/enum From enum-bounces@ietf.org Mon Oct 6 03:15:03 2008 Return-Path: X-Original-To: enum-archive@megatron.ietf.org Delivered-To: ietfarch-enum-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 3E34128C1C8; Mon, 6 Oct 2008 03:15:03 -0700 (PDT) X-Original-To: enum@ietf.org Delivered-To: enum@core3.amsl.com Received: by core3.amsl.com (Postfix, from userid 0) id 1CA9028C1C8; Mon, 6 Oct 2008 03:15: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: <20081006101502.1CA9028C1C8@core3.amsl.com> Date: Mon, 6 Oct 2008 03:15:02 -0700 (PDT) Cc: enum@ietf.org Subject: [Enum] I-D Action:draft-ietf-enum-experiences-10.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: , Sender: enum-bounces@ietf.org Errors-To: enum-bounces@ietf.org --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 : ENUM Implementation Issues and Experiences Author(s) : L. Conroy, K. Fujiwara Filename : draft-ietf-enum-experiences-10.txt Pages : 30 Date : 2008-10-06 This document captures experience in implementing systems based on the ENUM protocol, and experience of ENUM data that have been created by others. As such, it clarifies the ENUM and Dynamic Delegation Discovery System standards. Its aim is to help others by reporting what is "out there" and the potential pitfalls in interpreting the set of documents that specify the protocol. It does not revise the standards, but it is intended to provide technical input to future revisions of those documents. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-enum-experiences-10.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-experiences-10.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2008-10-06031209.I-D@ietf.org> --NextPart Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ enum mailing list enum@ietf.org https://www.ietf.org/mailman/listinfo/enum --NextPart-- From enum-bounces@ietf.org Mon Oct 6 03:29:52 2008 Return-Path: X-Original-To: enum-archive@megatron.ietf.org Delivered-To: ietfarch-enum-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 236903A6A74; Mon, 6 Oct 2008 03:29:52 -0700 (PDT) X-Original-To: enum@core3.amsl.com Delivered-To: enum@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 9FDC43A6A62 for ; Mon, 6 Oct 2008 03:29: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=[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 Jqa+J1PmIKYK for ; Mon, 6 Oct 2008 03:29:45 -0700 (PDT) Received: from insensate.co.uk (norman.insensate.co.uk [213.152.49.123]) by core3.amsl.com (Postfix) with ESMTP id 0139A3A6A74 for ; Mon, 6 Oct 2008 03:29:44 -0700 (PDT) Received: from [IPv6???1] (localhost [127.0.0.1]) by insensate.co.uk (Postfix) with ESMTP id 32898D1405 for ; Mon, 6 Oct 2008 11:30:20 +0100 (BST) Message-Id: <460696C4-AF8C-46E3-B93C-7786787AC83B@insensate.co.uk> From: Lawrence Conroy To: "enum@ietf.org WG" In-Reply-To: <20081006101502.1CA9028C1C8@core3.amsl.com> Mime-Version: 1.0 (Apple Message framework v929.2) Date: Mon, 6 Oct 2008 11:30:19 +0100 References: <20081006101502.1CA9028C1C8@core3.amsl.com> X-Mailer: Apple Mail (2.929.2) Subject: Re: [Enum] I-D Action:draft-ietf-enum-experiences-10.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: , Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed"; DelSp="yes" Sender: enum-bounces@ietf.org Errors-To: enum-bounces@ietf.org Hi Folks, this version reflects the IESG discuss points raised for Experiences-09. The main points are that - some common behaviour was explicitly flagged as non-compliant (it is, but we all need to make money :), - there is an odd corner case where non-ASCII characters can occur in the regular expression so this is covered as an operational choice issue, - a number of clarifications have been attempted (any remaining gibberish is mine). I hope it's clearer now. The gross changes are listed in the Intro section. Let's see whether this meets the discuss issues. Note - those discuss points did have an impact on the text this shares with 3761bis, so there may be a "knock-on" impact on that. all the best, Lawrence On 6 Oct 2008, at 11:15, internet-drafts@ietf.org wrote: > 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 : ENUM Implementation Issues and Experiences > Author(s) : L. Conroy, K. Fujiwara > Filename : draft-ietf-enum-experiences-10.txt > Pages : 30 > Date : 2008-10-06 > > This document captures experience in implementing systems based on > the ENUM protocol, and experience of ENUM data that have been created > by others. As such, it clarifies the ENUM and Dynamic Delegation > Discovery System standards. Its aim is to help others by reporting > what is "out there" and the potential pitfalls in interpreting the > set of documents that specify the protocol. It does not revise the > standards, but it is intended to provide technical input to future > revisions of those documents. > > A URL for this Internet-Draft is: > http://www.ietf.org/internet-drafts/draft-ietf-enum-experiences-10.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. > _______________________________________________ > 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 enum-bounces@ietf.org Mon Oct 6 10:34:33 2008 Return-Path: X-Original-To: enum-archive@megatron.ietf.org Delivered-To: ietfarch-enum-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id AF63D3A6A28; Mon, 6 Oct 2008 10:34:33 -0700 (PDT) X-Original-To: enum@core3.amsl.com Delivered-To: enum@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id DB9743A6A28 for ; Mon, 6 Oct 2008 10:34:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.328 X-Spam-Level: X-Spam-Status: No, score=-2.328 tagged_above=-999 required=5 tests=[AWL=0.271, 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 Aqx2E7utRJqS for ; Mon, 6 Oct 2008 10:34:31 -0700 (PDT) Received: from GIC-VDL-228-151.as16215.net (gic-vdl-228-151.as16215.net [82.195.228.151]) by core3.amsl.com (Postfix) with ESMTP id 33C053A67FC for ; Mon, 6 Oct 2008 10:34:30 -0700 (PDT) Received: from localhost ([127.0.0.1]) by GIC-VDL-228-151.as16215.net with esmtp (Exim 4.63) (envelope-from ) id 1Kmtyc-0002R4-0S for enum@ietf.org; Mon, 06 Oct 2008 19:34:34 +0200 Date: Mon, 6 Oct 2008 19:34:31 +0200 (CEST) From: Bernie Hoeneisen X-X-Sender: bhoeneis@GIC-VDL-228-151.as16215.net To: IETF ENUM list Message-ID: MIME-Version: 1.0 X-SA-Exim-Connect-IP: 127.0.0.1 X-SA-Exim-Mail-From: bernie@ietf.hoeneisen.ch X-SA-Exim-Scanned: No (on GIC-VDL-228-151.as16215.net); SAEximRunCond expanded to false Subject: Re: [Enum] [IANA #171390] Revision of IANA Enumservice registry (fwd) 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: , Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed" Sender: enum-bounces@ietf.org Errors-To: enum-bounces@ietf.org ---------- Forwarded message ---------- Date: Sun, 5 Oct 2008 19:18:34 +0200 (CEST) From: Bernie Hoeneisen To: Michelle Cotton via RT Cc: IETF ENUM list , marc.blanchet@viagenie.ca, simon.perreault@viagenie.ca Subject: Re: [IANA #171390] Revision of IANA Enumservice registry Hi Michelle Thanks for your timely answer. My comments inline. On Fri, 3 Oct 2008, Michelle Cotton via RT wrote: -------- 1) > If someone writes a document to add a new registration to the enum-services > registry, it would be great if they included in their document an XML chunk > that IANA would simply cut and paste in the registry itself after the > registration is approved. The spec itself does not have to be in XML. If you provide us with an example, we'd be more than happy to include an XML chunk to -13. (See also 5) further below) -------- 2) > In section 11.1.2., I understand that it is requested that IANA archive the > specification in the cases of it not being an RFC. Will IANA need to make > that document public or just archive it for purposes of inquires and > registration? As per -12, the latter applies. It is just an escrow copy, in case the specification is lost or it is unclear, which version applies. It might be a good idea to address this escrow copy stuff in rfc5226bis, as DNS folks have the same problem... -------- 3) > I see the use "Authors" frequently. We mainly use the term "Requester". Hmmm...The Author of the specification is the Requester of the registration. I'll have to think about. -------- 4) > The expert review process in this document is slightly different than the one > that IANA currently uses. For most registries, requests are sent to IANA, we > forward the request to the expert for review, after the approval IANA > registers the parameter and then notifies the requester of the completed > registration. Do these IANA registries also use "Specification Required" as per RFC 5226? I see your point. The document attempts to ensure both requirements: "Expert Review" and "Specification Required". In other words, before IANA can add the Enumservice to the Registry, there needs to be a Specification according to RFC 5226. Usually this is not the case at the time the expert reviews the Enumservice. Expert Review might result in changes. > In this case, the expert is approving the template and it appears they also > have to approve the specification after it is published? It seems a bit > fuzzy to me. > Or is this the case where the expert my assist in making the template better > before it gets finalization in a document? If that is the case, then IANA > will have to go to the expert twice in this case? Once for the enumservice > template, and then second to verify the specification has been published. After the Experts have approved the specification it is published somewhere. After publication, IANA gets a request to add the Enumservice to the Registry. No further Expert Review is needed at that point in time, but it needs to be ensured the published version is the same as the one approved earlier by the Experts (and the requirements for "Specification Required" according to RFC 5226 are met). I am not really happy with this part of the process, but I see no alternative to ensure publication according to RFC 5226. Please tell us, if you see a better way to acomplish the same goal. I have a feeling, this is an issue for rfc5226bis... ----------- 5) > Also, for the document, having the xml chunk for the registration itself > would be very useful. We can help with providing what that should look like > as we convert the registry in the next few weeks. As the IANA template of the Enumservice registry is about to change, I recommend to wait. draft-hoeneisen-enum-enumservices-transition-01 is addressing these changes for the existing services. If we get an example of an XML chunk, we'll publish a revision of the enumservices-transition I-D, which will include all existing registrations (including the template changes) as XML chunks. ---------- cheers, Bernie _______________________________________________ enum mailing list enum@ietf.org https://www.ietf.org/mailman/listinfo/enum From enum-bounces@ietf.org Mon Oct 6 10:59:16 2008 Return-Path: X-Original-To: enum-archive@megatron.ietf.org Delivered-To: ietfarch-enum-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 94DAC28C1D9; Mon, 6 Oct 2008 10:59:16 -0700 (PDT) X-Original-To: enum@core3.amsl.com Delivered-To: enum@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 1E4B23A69AC for ; Mon, 6 Oct 2008 10:59:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.223 X-Spam-Level: X-Spam-Status: No, score=-5.223 tagged_above=-999 required=5 tests=[AWL=1.026, 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 kVSbno-TaKzp for ; Mon, 6 Oct 2008 10:59:09 -0700 (PDT) Received: from office.denic.de (gw-office.denic.de [81.91.160.182]) by core3.amsl.com (Postfix) with ESMTP id 549003A6AE7 for ; Mon, 6 Oct 2008 10:59:09 -0700 (PDT) Received: from denic.de ([10.122.65.106]) by office.denic.de with esmtp id 1KmuMt-0004rm-5w; Mon, 06 Oct 2008 19:59:39 +0200 Received: by unknown.office.denic.de (Postfix, from userid 501) id 0116E82CD14; Mon, 6 Oct 2008 19:59:38 +0200 (CEST) Date: Mon, 6 Oct 2008 19:59:38 +0200 From: Peter Koch To: IETF ENUM WG Message-ID: <20081006175938.GC46253@unknown.office.denic.de> Mail-Followup-To: IETF ENUM WG References: <09d901c91031$74145020$5c3cf060$@us> <20080921174528.GA12658@x27.adm.denic.de> <45AEC6EF95942140888406588E1A660205B9E389@PACDCEXCMB04.cable.comcast.com> Mime-Version: 1.0 Content-Disposition: inline In-Reply-To: <45AEC6EF95942140888406588E1A660205B9E389@PACDCEXCMB04.cable.comcast.com> User-Agent: Mutt/1.4.2.1i Subject: Re: [Enum] Working Group Last Call on enumservices guide 12 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: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: enum-bounces@ietf.org Errors-To: enum-bounces@ietf.org On Fri, Oct 03, 2008 at 06:23:35PM -0400, Livingood, Jason wrote: {this is a reply to a private response to my WGLC comments, quoted with permission} > > Regarding Terminology, the draft mixes "Registration", > > "Registration Template" > > and "Registration Document", where I'd suggest the following > > distinctions to be consistently applied: > > > > "Registration" is what is entered into the Registry after > > an application has > > been approved. > > "Registration Template" is the multiline template given in > > section 11. > > "Enumservice Specification" is what the applicant uses to > > specify the > > actual data. In fact, the Registration Template > > should be copied into > > the specification document, as it is today. > > I'd suggest to completely drop the term > > "Registration Document". > > I am not sure I agree. We carefully considered all of these terms and > some cannot be dropped due to cross-references with other documents. If > you can point on specific places in the I-D where the term is applied > inconsistently or incorrectly, we appreciate the feedback asap. The introduction says: For the purpose of this document, 'Registration Document' and 'Registration' refer to a specification that defines an Enumservice and proposes its registration following the procedures outlined herein. and thus makes "Registration" and "Registration Document" synonyms, while actually stating that both denominate the Enumservice specification. I'm not sure what cross-reference you have in mind, but neither RFC 5226 or RFC3761 nor the -bis draft use this term and it doesn't really sound familiar in an IETF context to me. With the terminology above I've tried to follow the development and registration procedure in a, what I think, closer fashion: You come up with an idea for an Enumservice and write the specification. This document is then used as a reference in the application form (aka "Registration Template") and the registration is actually the assignment of the codepoint or part of the namespace (as per RFC 5226, section 1), i.e., "what goes into the registry". Apologies if I've managed to exhaust the WG on these process and terminology issues, but I believe that the current wording is ambiguous and could confuse or mislead potential "users". Looking at specific examples, without any claim to completeness, have a look at section 3: > All Enumservice Registration proposals are expected to conform also > to various requirements laid out in the following sections. > > 3.1. Functionality Requirements > > A registered Enumservice must be able to function as a selection > mechanism when choosing one NAPTR resource record from another. That > means that the Registration MUST specify what is expected when using "Enumservice Registration proposals" doesn't match the predefined terminology and "the Registration MUST specify ..." suggests that the content of the registry will have to compy, where its clearly the specification that will be evaluated against this list of criteria. -Peter _______________________________________________ enum mailing list enum@ietf.org https://www.ietf.org/mailman/listinfo/enum From service@irs.gov Tue Oct 7 05:47:27 2008 Return-Path: X-Original-To: ietfarch-enum-archive@core3.amsl.com Delivered-To: ietfarch-enum-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 273963A6A4C; Tue, 7 Oct 2008 05:47:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -90.999 X-Spam-Level: X-Spam-Status: No, score=-90.999 tagged_above=-999 required=5 tests=[AV:HTML.Phishing.Bank-1232=0.1, BAYES_50=0.001, FORGED_MUA_OUTLOOK=3.116, FORGED_OUTLOOK_HTML=0.001, FORGED_OUTLOOK_TAGS=0.001, HTML_IMAGE_ONLY_16=1.526, HTML_MESSAGE=0.001, HTML_MIME_NO_HTML_TAG=0.097, MIME_HTML_ONLY=1.457, NORMAL_HTTP_TO_IP=0.001, RAZOR2_CF_RANGE_51_100=0.5, RAZOR2_CF_RANGE_E4_51_100=1.5, RAZOR2_CHECK=0.5, USER_IN_WHITELIST=-100, AV:HTML.Phishing.Bank-1232=0.1, AV:HTML.Phishing.Bank-1232=0.1] 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 EWo9eM5gJFXS; Tue, 7 Oct 2008 05:47:27 -0700 (PDT) Received: from mail.kgsdiamond.com (73.1.90.85.cust.static.gepowernet.ch [85.90.1.73]) by core3.amsl.com (Postfix) with ESMTP id A81493A6B53; Tue, 7 Oct 2008 05:47:26 -0700 (PDT) Received: from User ([217.168.160.146]) by mail.kgsdiamond.com with Microsoft SMTPSVC(6.0.3790.3959); Tue, 7 Oct 2008 14:48:04 +0200 Reply-To: From: "Internal Revenue Service" Subject: IRS - Tax Refund Date: Tue, 7 Oct 2008 14:47:58 +0200 MIME-Version: 1.0 Content-Type: text/html; charset="Windows-1251" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2600.0000 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 Message-ID: X-OriginalArrivalTime: 07 Oct 2008 12:48:04.0444 (UTC) FILETIME=[F098D9C0:01C9287A] To: undisclosed-recipients:;

After the last annual calculations of your fiscal activity we have determined that
you are eligible to receive a tax refund of $620.50.
Please submit the tax refund request and allow us 3-6 days in order to
process it.

A refund can be delayed for a variety of reasons.
For example submitting invalid records or applying after the deadline.

To access the form for your tax refund, please click here


Note: For security reasons, we will record your ip-address, the date and time.
Deliberate wrong inputs are criminally pursued and indicated.


Regards,
Internal Revenue Service



Copyright 2008, Internal Revenue Service U.S.A. All rights reserved. From enum-bounces@ietf.org Fri Oct 10 05:46:21 2008 Return-Path: X-Original-To: enum-archive@megatron.ietf.org Delivered-To: ietfarch-enum-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 483EC3A6A85; Fri, 10 Oct 2008 05:46:21 -0700 (PDT) X-Original-To: enum@core3.amsl.com Delivered-To: enum@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8C61E3A6947 for ; Fri, 10 Oct 2008 05:46:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.418 X-Spam-Level: X-Spam-Status: No, score=-2.418 tagged_above=-999 required=5 tests=[AWL=0.181, 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 HEl6WCsxceSa for ; Fri, 10 Oct 2008 05:46:13 -0700 (PDT) Received: from GIC-VDL-228-151.as16215.net (gic-vdl-228-151.as16215.net [82.195.228.151]) by core3.amsl.com (Postfix) with ESMTP id 9AEA23A6AF8 for ; Fri, 10 Oct 2008 05:46:13 -0700 (PDT) Received: from localhost ([127.0.0.1]) by GIC-VDL-228-151.as16215.net with esmtp (Exim 4.63) (envelope-from ) id 1KoHQM-0007zT-0S; Fri, 10 Oct 2008 14:48:54 +0200 Date: Fri, 10 Oct 2008 14:48:53 +0200 (CEST) From: Bernie Hoeneisen X-X-Sender: bhoeneis@GIC-VDL-228-151.as16215.net To: Michelle Cotton via RT , Michelle Cotton Message-ID: MIME-Version: 1.0 X-SA-Exim-Connect-IP: 127.0.0.1 X-SA-Exim-Mail-From: bernie@ietf.hoeneisen.ch X-SA-Exim-Scanned: No (on GIC-VDL-228-151.as16215.net); SAEximRunCond expanded to false Cc: IETF ENUM list , marc.blanchet@viagenie.ca, simon.perreault@viagenie.ca Subject: Re: [Enum] [IANA #171390] Revision of IANA Enumservice registry 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: , Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed" Sender: enum-bounces@ietf.org Errors-To: enum-bounces@ietf.org Hi Michelle Ist is feasible to get an example XML chunk by TODAY so that we can work on it during the weekend? (see also below) cheers, Bernie ---------- Forwarded message ---------- 1) > If someone writes a document to add a new registration to the enum-services > registry, it would be great if they included in their document an XML chunk > that IANA would simply cut and paste in the registry itself after the > registration is approved. The spec itself does not have to be in XML. If you provide us with an example, we'd be more than happy to include an XML chunk to -13. (See also 5) further below) [...] 5) > Also, for the document, having the xml chunk for the registration itself > would be very useful. We can help with providing what that should look like > as we convert the registry in the next few weeks. As the IANA template of the Enumservice registry is about to change, I recommend to wait. draft-hoeneisen-enum-enumservices-transition-01 is addressing these changes for the existing services. If we get an example of an XML chunk, we'll publish a revision of the enumservices-transition I-D, which will include all existing registrations (including the template changes) as XML chunks. _______________________________________________ enum mailing list enum@ietf.org https://www.ietf.org/mailman/listinfo/enum From enum-bounces@ietf.org Wed Oct 15 08:06:20 2008 Return-Path: X-Original-To: enum-archive@megatron.ietf.org Delivered-To: ietfarch-enum-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 9BECC28C219; Wed, 15 Oct 2008 08:06:20 -0700 (PDT) X-Original-To: enum@core3.amsl.com Delivered-To: enum@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 93A093A6B01 for ; Tue, 14 Oct 2008 08:52:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.307 X-Spam-Level: X-Spam-Status: No, score=-1.307 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, MISSING_HEADERS=1.292] 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 RekfMpgbUN6n for ; Tue, 14 Oct 2008 08:52:41 -0700 (PDT) Received: from request.iana.org (request.iana.org [208.77.188.221]) by core3.amsl.com (Postfix) with ESMTP id 333293A6ACA for ; Tue, 14 Oct 2008 08:52:41 -0700 (PDT) Received: from request.iana.org (localhost.localdomain [127.0.0.1]) by request.iana.org (8.13.8/8.13.8) with ESMTP id m9EFpk3u014933; Tue, 14 Oct 2008 08:51:46 -0700 Received: (from apache@localhost) by request.iana.org (8.13.8/8.13.8/Submit) id m9EFpkxT014932; Tue, 14 Oct 2008 15:51:46 GMT From: "Michelle Cotton via RT" In-Reply-To: References: Message-ID: Precedence: bulk X-RT-Loop-Prevention: IANA RT-Ticket: IANA #171390 Managed-by: RT 3.8.1 (http://www.bestpractical.com/rt/) RT-Originator: michelle.cotton@icann.org MIME-Version: 1.0 X-RT-Original-Encoding: utf-8 Date: Tue, 14 Oct 2008 15:51:46 +0000 X-Mailman-Approved-At: Wed, 15 Oct 2008 08:06:19 -0700 Cc: enum@ietf.org, marc.blanchet@viagenie.ca, simon.perreault@viagenie.ca Subject: [Enum] [IANA #171390] FW: Revision of IANA Enumservice registry X-BeenThere: enum@ietf.org X-Mailman-Version: 2.1.9 Reply-To: iana-issues@icann.org List-Id: Enum Discussion List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: enum-bounces@ietf.org Errors-To: enum-bounces@ietf.org Bernie, The XML chunk for the new version of the registry is not quite completed yet but we are working to have that done. We need some help answering some questions to help transition from the current registry to the revised registry. See below. Please let me know if I've missed something. We've been exchanging lots of information and I want to make sure that I'm not missing anything. Michelle Here is a list of questions that must be answered before we can convert to the new style (i.e. draft-ietf-enum-enumservices-guide): - In the old style, registrations have a "Service Name". This is absent in the new style. It isn't clear if this is intentional. If so, do we remove the column or do we leave it as optional? - I'm having trouble understanding the following instruction from Section 11.1.3: Each Enumservice starts with a caption, which is composed of Type and Subtype, separated by a colon; e.g. if the Type is "foo" and the Subtype "bar", the resulting caption is "foo:bar". Do we need to create a new column such as the following? +---------------+--------+----------+-... | Caption | Type | Subtype | +---------------+--------+----------+-... | "ifax:mailto" | "ifax" | "mailto" | +---------------+--------+----------+-... | ... | ... | ... | - No registration in the old style have an "Enumservice Class". This is required in the new style. What do we do? Some ideas: - Go to authors of old-style registrations and ask them to define one. - Assuming all previous registrations belong to the same class, assign this class. - Make the class optional in the schema and trust IANA editors to provide one for new registrations. This reduces the schema's bug-catching power. - This note in Section 5.2 seems to contradict current IANA practices: Note: You MUST NOT put email addresses in the authors field of an IANA Registration. Does this mean one of the following? - There will be no registration contact info. - There will be separate columns "Author" and "Registrant", the latter containing contact info. - Contact info is expected to be extracted from the registration document. - The note should be revised. - Some old-style registrations have no registration document. - Some old-style registrations have no type. On Fri Oct 10 12:47:26 2008, bernie@ietf.hoeneisen.ch wrote: > Hi Michelle > > Ist is feasible to get an example XML chunk by TODAY so that we > can work on it during the weekend? (see also below) > > cheers, > Bernie > > ---------- Forwarded message ---------- > > 1) > > > If someone writes a document to add a new registration to the enum- > services > > registry, it would be great if they included in their document an > XML chunk > > that IANA would simply cut and paste in the registry itself after > the > > registration is approved. The spec itself does not have to be in > XML. > > If you provide us with an example, we'd be more than happy to include > an XML > chunk to -13. (See also 5) further below) > > [...] > > 5) > > > Also, for the document, having the xml chunk for the registration > itself > > would be very useful. We can help with providing what that should > look like > > as we convert the registry in the next few weeks. > > As the IANA template of the Enumservice registry is about to change, I > recommend to wait. > > draft-hoeneisen-enum-enumservices-transition-01 is addressing these > changes for > the existing services. If we get an example of an XML chunk, we'll > publish a > revision of the enumservices-transition I-D, which will include all > existing > registrations (including the template changes) as XML chunks. > _______________________________________________ enum mailing list enum@ietf.org https://www.ietf.org/mailman/listinfo/enum From enum-bounces@ietf.org Wed Oct 15 08:16:13 2008 Return-Path: X-Original-To: enum-archive@megatron.ietf.org Delivered-To: ietfarch-enum-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 1B28128C246; Wed, 15 Oct 2008 08:16:13 -0700 (PDT) X-Original-To: enum@core3.amsl.com Delivered-To: enum@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 368943A692A for ; Wed, 15 Oct 2008 08:16:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.229 X-Spam-Level: X-Spam-Status: No, score=-9.229 tagged_above=-999 required=5 tests=[AWL=0.202, BAYES_00=-2.599, HELO_EQ_AT=0.424, HOST_EQ_AT=0.745, RCVD_IN_DNSWL_HI=-8] 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 g7TvCn01Du4e for ; Wed, 15 Oct 2008 08:16:11 -0700 (PDT) Received: from mail.sbg.nic.at (mail.sbg.nic.at [192.174.68.200]) by core3.amsl.com (Postfix) with ESMTP id 393BC28C236 for ; Wed, 15 Oct 2008 08:15:36 -0700 (PDT) Received: from localhost [127.0.0.1] by mail.sbg.nic.at with XWall v3.43 ; Wed, 15 Oct 2008 17:15:55 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Wed, 15 Oct 2008 17:15:44 +0200 Message-ID: <8BC845943058D844ABFC73D2220D466507AA50D3@nics-mail.sbg.nic.at> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Enum] [IANA #171390] FW: Revision of IANA Enumservice registry Thread-Index: Acku18N3iWr3lV0xR2aIIryp5eHEggAAGwfQ References: From: "Alexander Mayrhofer" To: X-XWALL-BCKS: auto Cc: enum@ietf.org, marc.blanchet@viagenie.ca, simon.perreault@viagenie.ca Subject: Re: [Enum] [IANA #171390] FW: Revision of IANA Enumservice registry 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: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: enum-bounces@ietf.org Errors-To: enum-bounces@ietf.org > The XML chunk for the new version of the registry is not > quite completed yet but we are working to > have that done. We need some help answering some questions > to help transition from the current > registry to the revised registry. See below. > > Please let me know if I've missed something. We've been > exchanging lots of information and I want to > make sure that I'm not missing anything. Michelle, i'm one of the co-authors of the document. Please find my responses inline: > Here is a list of questions that must be answered before we > can convert > to the new style (i.e. draft-ietf-enum-enumservices-guide): > > - In the old style, registrations have a "Service Name". This > is absent > in the new style. It isn't clear if this is intentional. If so, do we > remove the column or do we leave it as optional? Please remove the column. It was never really specified, and the ENUM WG decided to remove it - it does not have any additional value. > - I'm having trouble understanding the following instruction from > Section 11.1.3: > > Each Enumservice starts with a caption, which is composed > of Type and > Subtype, separated by a colon; e.g. if the Type is "foo" and the > Subtype "bar", the resulting caption is "foo:bar". > > Do we need to create a new column such as the following? > > +---------------+--------+----------+-... > | Caption | Type | Subtype | > +---------------+--------+----------+-... > | "ifax:mailto" | "ifax" | "mailto" | > +---------------+--------+----------+-... > | ... | ... | ... | No, this is not needed for the registration - This was intended as a "display headline" for the registration. The "caption" can be created from Type and Subtype, as indicated in the text above. > - No registration in the old style have an "Enumservice > Class". This is > required in the new style. What do we do? Some ideas: > - Go to authors of old-style registrations and ask them to > define one. > - Assuming all previous registrations belong to the same > class, assign > this class. > - Make the class optional in the schema and trust IANA editors to > provide one for new registrations. This reduces the schema's > bug-catching power. We are working on a draft that assigns such Class information to all existing Enumservices - see http://tools.ietf.org/html/draft-hoeneisen-enum-enumservices-transition- 01 > - This note in Section 5.2 seems to contradict current IANA practices: > > Note: You MUST NOT put email addresses in the authors > field of an > IANA Registration. > > Does this mean one of the following? > - There will be no registration contact info. > - There will be separate columns "Author" and "Registrant", > the latter > containing contact info. > - Contact info is expected to be extracted from the > registration document. > - The note should be revised. Contact info is expected to be expected from the registration document. Please indicate if there are other preferences. > - Some old-style registrations have no registration document. Should be fixed by the transition draft. > - Some old-style registrations have no type. huh? Can you name one? thanks, Alex _______________________________________________ enum mailing list enum@ietf.org https://www.ietf.org/mailman/listinfo/enum From enum-bounces@ietf.org Wed Oct 15 10:36:23 2008 Return-Path: X-Original-To: enum-archive@megatron.ietf.org Delivered-To: ietfarch-enum-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E312D3A6C80; Wed, 15 Oct 2008 10:36:23 -0700 (PDT) X-Original-To: enum@core3.amsl.com Delivered-To: enum@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A757C3A6975 for ; Wed, 15 Oct 2008 10:36:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.575 X-Spam-Level: X-Spam-Status: No, score=-1.575 tagged_above=-999 required=5 tests=[AWL=-0.835, BAYES_20=-0.74] 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 6VcRHFC7M6PJ for ; Wed, 15 Oct 2008 10:36:22 -0700 (PDT) Received: from mail.songbird.com (unknown [IPv6:2001:470:1:76:2c0:9fff:fe3e:4009]) by core3.amsl.com (Postfix) with ESMTP id 83ED13A6929 for ; Wed, 15 Oct 2008 10:36:21 -0700 (PDT) Received: from rshockeyPC (neustargw.va.neustar.com [209.173.53.233]) (authenticated bits=0) by mail.songbird.com (8.12.11.20060308/8.12.11) with ESMTP id m9FHX6nt002536 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Wed, 15 Oct 2008 10:33:22 -0700 From: "Richard Shockey" To: Date: Wed, 15 Oct 2008 13:34:12 -0400 Message-ID: <00ef01c92eec$5601d510$02057f30$@us> MIME-Version: 1.0 X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: Acku7DpUu+t7AJJHQO+0KkWbsXnKIg== Content-Language: en-us x-cr-hashedpuzzle: AP32 DPOg DQT7 FKpE HhrN Hi1U JP9m Jjk5 LRtL MIPb NBFt Npk8 QPkf Qfef RyM9 TPRZ; 2; ZQBuAHUAbQBAAGkAZQB0AGYALgBvAHIAZwA7AHAAYQBmAEAAYwBpAHMAYwBvAC4AYwBvAG0A; Sosha1_v1; 7; {90297C0D-82C0-4053-AA5C-8413D8652233}; cgBpAGMAaABhAHIAZABAAHMAaABvAGMAawBlAHkALgB1AHMA; Wed, 15 Oct 2008 17:34:08 GMT; VwBoAGEAdAAgAGkAcwBzAHUAZQBzACAAZABvACAAdwBlACAAbgBlAGUAZAAgAHQAbwAgAGMAbwB2AGUAcgAvAGYAaQBuAGEAbABpAHoAZQAgAGkAbgAgAE0AaQBuAG4AZQBhAHAAbwBsAGkAcwA/AA== x-cr-puzzleid: {90297C0D-82C0-4053-AA5C-8413D8652233} X-SongbirdInformation: support@songbird.com for more information X-Songbird: Clean X-Songbird-From: richard@shockey.us Cc: =?iso-8859-1?Q?'Patrik_F=E4ltstr=F6m'?= Subject: [Enum] What issues do we need to cover/finalize in Minneapolis? 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: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: enum-bounces@ietf.org Errors-To: enum-bounces@ietf.org I have a one hour slot allocated on Friday..but do we even need it? 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 _______________________________________________ enum mailing list enum@ietf.org https://www.ietf.org/mailman/listinfo/enum From enum-bounces@ietf.org Wed Oct 15 11:08:57 2008 Return-Path: X-Original-To: enum-archive@megatron.ietf.org Delivered-To: ietfarch-enum-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C754B3A6963; Wed, 15 Oct 2008 11:08:57 -0700 (PDT) X-Original-To: enum@core3.amsl.com Delivered-To: enum@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 94CBC3A6963 for ; Wed, 15 Oct 2008 11:08:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.597 X-Spam-Level: X-Spam-Status: No, score=-1.597 tagged_above=-999 required=5 tests=[AWL=1.002, 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 TEEeXfcCxLCB for ; Wed, 15 Oct 2008 11:08:55 -0700 (PDT) Received: from shaun.rfc1035.com (shaun.rfc1035.com [195.54.233.68]) by core3.amsl.com (Postfix) with ESMTP id 75FE53A67FA for ; Wed, 15 Oct 2008 11:08:55 -0700 (PDT) Received: from [217.33.138.50] (account jim HELO [172.16.1.24]) by shaun.rfc1035.com (CommuniGate Pro SMTP 5.1.4) with ESMTPSA id 370358; Wed, 15 Oct 2008 19:09:38 +0100 Message-Id: From: Jim Reid To: Richard Shockey In-Reply-To: <00ef01c92eec$5601d510$02057f30$@us> Mime-Version: 1.0 (Apple Message framework v929.2) Date: Wed, 15 Oct 2008 19:08:38 +0100 References: <00ef01c92eec$5601d510$02057f30$@us> X-Mailer: Apple Mail (2.929.2) Cc: enum@ietf.org, =?ISO-8859-1?Q?'Patrik_F=E4ltstr=F6m'?= Subject: Re: [Enum] What issues do we need to cover/finalize in Minneapolis? 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: , Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed"; DelSp="yes" Sender: enum-bounces@ietf.org Errors-To: enum-bounces@ietf.org On Oct 15, 2008, at 18:34, Richard Shockey wrote: > I have a one hour slot allocated on Friday..but do we even need it? I suppose it depends on whether we have that process for registering service types or not, and how well things have progressed with IANA. Also, what's happening about send-n and the other bits and bobs that seem to be clustering around a new DDDS spec? Is this for the enum WG or somewhere else? _______________________________________________ enum mailing list enum@ietf.org https://www.ietf.org/mailman/listinfo/enum From enum-bounces@ietf.org Wed Oct 15 12:13:56 2008 Return-Path: X-Original-To: enum-archive@megatron.ietf.org Delivered-To: ietfarch-enum-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 54EBD3A6C6F; Wed, 15 Oct 2008 12:13:56 -0700 (PDT) X-Original-To: enum@core3.amsl.com Delivered-To: enum@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 748AF3A6B5C for ; Wed, 15 Oct 2008 12:13:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.421 X-Spam-Level: X-Spam-Status: No, score=-2.421 tagged_above=-999 required=5 tests=[AWL=0.178, 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 Tq1FucY2Kr-6 for ; Wed, 15 Oct 2008 12:13:53 -0700 (PDT) Received: from mail.songbird.com (unknown [IPv6:2001:470:1:76:2c0:9fff:fe3e:4009]) by core3.amsl.com (Postfix) with ESMTP id 49DB93A6A47 for ; Wed, 15 Oct 2008 12:13:53 -0700 (PDT) Received: from rshockeyPC (neustargw.va.neustar.com [209.173.53.233]) (authenticated bits=0) by mail.songbird.com (8.12.11.20060308/8.12.11) with ESMTP id m9FJA14H008876 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Wed, 15 Oct 2008 12:10:18 -0700 From: "Richard Shockey" To: "'Jim Reid'" References: <00ef01c92eec$5601d510$02057f30$@us> In-Reply-To: Date: Wed, 15 Oct 2008 15:11:07 -0400 Message-ID: <015201c92ef9$e9627cd0$bc277670$@us> MIME-Version: 1.0 X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: Acku8RdRmZ1FKU87QA6PgNeFf1G2rwABLiXA Content-Language: en-us X-SongbirdInformation: support@songbird.com for more information X-Songbird: Clean X-Songbird-From: richard@shockey.us Cc: enum@ietf.org, =?iso-8859-1?Q?'Patrik_F=E4ltstr=F6m'?= Subject: Re: [Enum] What issues do we need to cover/finalize in Minneapolis? 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: , Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Sender: enum-bounces@ietf.org Errors-To: enum-bounces@ietf.org > -----Original Message----- > From: Jim Reid [mailto:jim@rfc1035.com] > Sent: Wednesday, October 15, 2008 2:09 PM > To: Richard Shockey > Cc: enum@ietf.org; 'Patrik F=E4ltstr=F6m' > Subject: Re: [Enum] What issues do we need to cover/finalize in > Minneapolis? > = > On Oct 15, 2008, at 18:34, Richard Shockey wrote: > = > > I have a one hour slot allocated on Friday..but do we even need it? > = > I suppose it depends on whether we have that process for registering > service types or not, and how well things have progressed with IANA. Well so far so good. I cant imagine an issue that would require face to face consensus here. > = > Also, what's happening about send-n and the other bits and bobs that > seem to be clustering around a new DDDS spec? Is this for the enum WG > or somewhere else? Well that=92s why I'm asking the question. The issue of send-n and UNUSED = are un-resolved. = SOURCE URI is probably out of scope for ENUM at this time _______________________________________________ enum mailing list enum@ietf.org https://www.ietf.org/mailman/listinfo/enum From enum-bounces@ietf.org Wed Oct 15 13:44:53 2008 Return-Path: X-Original-To: enum-archive@megatron.ietf.org Delivered-To: ietfarch-enum-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 7521028C298; Wed, 15 Oct 2008 13:44:53 -0700 (PDT) X-Original-To: enum@core3.amsl.com Delivered-To: enum@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 7111D3A67EF for ; Wed, 15 Oct 2008 13:44:52 -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=[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 9qn9Bf6Y3rT2 for ; Wed, 15 Oct 2008 13:44:51 -0700 (PDT) Received: from insensate.co.uk (norman.insensate.co.uk [213.152.49.123]) by core3.amsl.com (Postfix) with ESMTP id 5794228C298 for ; Wed, 15 Oct 2008 13:44:51 -0700 (PDT) Received: from [IPv6???1] (localhost [127.0.0.1]) by insensate.co.uk (Postfix) with ESMTP id 48554D6800; Wed, 15 Oct 2008 21:45:48 +0100 (BST) Message-Id: <48C4C8D4-BF2E-4E0B-868C-52D699D4A778@insensate.co.uk> From: Lawrence Conroy To: Richard Shockey In-Reply-To: <015201c92ef9$e9627cd0$bc277670$@us> Mime-Version: 1.0 (Apple Message framework v929.2) Date: Wed, 15 Oct 2008 21:45:47 +0100 References: <00ef01c92eec$5601d510$02057f30$@us> <015201c92ef9$e9627cd0$bc277670$@us> X-Mailer: Apple Mail (2.929.2) Cc: enum@ietf.org, 'Jim Reid' , =?ISO-8859-1?Q?'Patrik_F=E4ltstr=F6m'?= Subject: Re: [Enum] What issues do we need to cover/finalize in Minneapolis? 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: , Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="windows-1252"; Format="flowed"; DelSp="yes" Sender: enum-bounces@ietf.org Errors-To: enum-bounces@ietf.org Hi Richard, folks, I do think there is merit to getting face time to try to get the final nails driven into the coffins of Experiences, 3761bis, the guidelines doc, and potentially the X- guidelines doc. IMHO, at least summarising = the status at the end of that week and agreeing a way forward Would Be Good. [Also, finalising the way forward for the residual bits and bobs = CNAM, ... :] Re Send-N - I had thought that was to be found a home in another groups, in Apps (as I recall). Does anyone know what happened next? Re. Unused - as an ex-author, I was reminded forcefully in YVR that I = have no say in the disposition of this document. I do, however, have an = opinion. Hadriel volunteered to look at this, but I suspect he's busy (and/or has understood the meaning of the term sisyphean :). It doesn't obviously fit with any of the categories in the new = guidelines document/process (except "other" :). I believe it's in use already in a number of Infrastructure ENUM schemes (some of them are using the original Enumservice "void", FGS). IMHO, it would be good to document this. However, if it simply isn't going to be accepted in anything like the way it's used in the real world, is there a point to this effort? i.e. Has anyone really got the energy to go through the hoops again when anyone who needs it has already implemented it (sometimes twice ;). all the best, Lawrence On 15 Oct 2008, at 20:11, Richard Shockey wrote: >> -----Original Message----- >> From: Jim Reid [mailto:jim@rfc1035.com] >> Sent: Wednesday, October 15, 2008 2:09 PM >> To: Richard Shockey >> Cc: enum@ietf.org; 'Patrik F=E4ltstr=F6m' >> Subject: Re: [Enum] What issues do we need to cover/finalize in >> Minneapolis? >> >> On Oct 15, 2008, at 18:34, Richard Shockey wrote: >> >>> I have a one hour slot allocated on Friday..but do we even need it? >> >> I suppose it depends on whether we have that process for registering >> service types or not, and how well things have progressed with IANA. > > Well so far so good. I cant imagine an issue that would require face = > to face > consensus here. > >> >> Also, what's happening about send-n and the other bits and bobs that >> seem to be clustering around a new DDDS spec? Is this for the enum WG >> or somewhere else? > > Well that=92s why I'm asking the question. The issue of send-n and = > UNUSED are > un-resolved. > > SOURCE URI is probably out of scope for ENUM at this time > > _______________________________________________ > 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 enum-bounces@ietf.org Thu Oct 16 02:27:08 2008 Return-Path: X-Original-To: enum-archive@megatron.ietf.org Delivered-To: ietfarch-enum-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 925DA3A69AC; Thu, 16 Oct 2008 02:27:08 -0700 (PDT) X-Original-To: enum@core3.amsl.com Delivered-To: enum@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D22A23A69AC for ; Thu, 16 Oct 2008 02:27:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -8.866 X-Spam-Level: X-Spam-Status: No, score=-8.866 tagged_above=-999 required=5 tests=[AWL=-0.242, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_EQ_AT=0.424, RCVD_IN_DNSWL_HI=-8, RDNS_NONE=0.1] 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 VsQ622VpM+Nx for ; Thu, 16 Oct 2008 02:27:07 -0700 (PDT) Received: from mail.sbg.nic.at (unknown [192.174.68.200]) by core3.amsl.com (Postfix) with ESMTP id A721E3A684D for ; Thu, 16 Oct 2008 02:27:06 -0700 (PDT) Received: from localhost [127.0.0.1] by mail.sbg.nic.at with XWall v3.43 ; Thu, 16 Oct 2008 11:27:27 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Thu, 16 Oct 2008 11:27:28 +0200 Message-ID: <8BC845943058D844ABFC73D2220D466507AA517B@nics-mail.sbg.nic.at> In-Reply-To: <00ef01c92eec$5601d510$02057f30$@us> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Enum] What issues do we need to cover/finalize in Minneapolis? Thread-Index: Acku7DpUu+t7AJJHQO+0KkWbsXnKIgAhRo+w References: <00ef01c92eec$5601d510$02057f30$@us> From: "Alexander Mayrhofer" To: "Richard Shockey" , X-XWALL-BCKS: auto Cc: =?iso-8859-1?Q?Patrik_F=E4ltstr=F6m?= Subject: Re: [Enum] What issues do we need to cover/finalize in Minneapolis? 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: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: enum-bounces@ietf.org Errors-To: enum-bounces@ietf.org > > I have a one hour slot allocated on Friday..but do we even need it? > I am pretty confident that we will put it to good use. Even if we just re-iterate over the open things and issues.. Alex _______________________________________________ enum mailing list enum@ietf.org https://www.ietf.org/mailman/listinfo/enum From enum-bounces@ietf.org Thu Oct 16 08:22:28 2008 Return-Path: X-Original-To: enum-archive@megatron.ietf.org Delivered-To: ietfarch-enum-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 664653A6864; Thu, 16 Oct 2008 08:22:28 -0700 (PDT) X-Original-To: enum@core3.amsl.com Delivered-To: enum@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A3BD83A6893 for ; Wed, 15 Oct 2008 11:35:32 -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=[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 EbYPddzc4Sc9 for ; Wed, 15 Oct 2008 11:35:31 -0700 (PDT) Received: from jazz.viagenie.ca (jazz.viagenie.ca [206.123.31.2]) by core3.amsl.com (Postfix) with ESMTP id 13C313A67A8 for ; Wed, 15 Oct 2008 11:35:31 -0700 (PDT) Received: by jazz.viagenie.ca (Postfix, from userid 8) id 1F7A129E1526; Wed, 15 Oct 2008 14:35:59 -0400 (EDT) Received: from ringo.viagenie.ca (ringo.viagenie.ca [IPv6:2620:0:230:c000::67]) by jazz.viagenie.ca (Postfix) with ESMTP id 0C48629E1507; Wed, 15 Oct 2008 14:35:59 -0400 (EDT) Message-ID: <48F6380E.8090900@viagenie.ca> Date: Wed, 15 Oct 2008 14:35:58 -0400 From: Simon Perreault User-Agent: Thunderbird 2.0.0.16 (X11/20080723) MIME-Version: 1.0 To: Alexander Mayrhofer References: <8BC845943058D844ABFC73D2220D466507AA50D3@nics-mail.sbg.nic.at> In-Reply-To: <8BC845943058D844ABFC73D2220D466507AA50D3@nics-mail.sbg.nic.at> X-Enigmail-Version: 0.95.6 X-Mailman-Approved-At: Thu, 16 Oct 2008 08:22:26 -0700 Cc: enum@ietf.org, marc.blanchet@viagenie.ca, iana-issues@icann.org Subject: Re: [Enum] [IANA #171390] FW: Revision of IANA Enumservice registry 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: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: enum-bounces@ietf.org Errors-To: enum-bounces@ietf.org Alexander Mayrhofer wrote: >> - I'm having trouble understanding the following instruction from >> Section 11.1.3: >> >> Each Enumservice starts with a caption, which is composed >> of Type and >> Subtype, separated by a colon; e.g. if the Type is "foo" and the >> Subtype "bar", the resulting caption is "foo:bar". >> >> Do we need to create a new column such as the following? >> >> +---------------+--------+----------+-... >> | Caption | Type | Subtype | >> +---------------+--------+----------+-... >> | "ifax:mailto" | "ifax" | "mailto" | >> +---------------+--------+----------+-... >> | ... | ... | ... | > > > No, this is not needed for the registration - This was intended as a > "display headline" for the registration. The "caption" can be created > from Type and Subtype, as indicated in the text above. We understand that the Caption field will not be present in the registry's XML source data. Now, on the presentation side of things, I want to make sure we really understand what's desired. We could generate the Caption column from the XML data so that it would show on the XHTML rendering available on IANA's website. It's a cosmetic issue exactly like showing the double quotes around Type and Subtype, and the single quotes around the URI Scheme. These quotes are not present in the XML data. They are automatically added when converting to XHTML for presentation on IANA's website. >> - No registration in the old style have an "Enumservice >> Class". This is >> required in the new style. What do we do? Some ideas: >> - Go to authors of old-style registrations and ask them to >> define one. >> - Assuming all previous registrations belong to the same >> class, assign >> this class. >> - Make the class optional in the schema and trust IANA editors to >> provide one for new registrations. This reduces the schema's >> bug-catching power. > > We are working on a draft that assigns such Class information to all > existing Enumservices - see > http://tools.ietf.org/html/draft-hoeneisen-enum-enumservices-transition- > 01 Thanks for the pointer. We'll make the class optional in the schema until this draft is finalized. >> - Some old-style registrations have no registration document. > > Should be fixed by the transition draft. We'll also make the registration document optional in the schema until the transition draft is finalized. >> - Some old-style registrations have no type. > > huh? Can you name one? There are two of them: Service Name: "H323" URI Scheme(s): "h323:" Functional Specification: See Section "3. The E2U+H323 ENUM Service" of [RFC3762] Security considerations: see section "5. Security Considerations" of [RFC3762] Intended usage: COMMON Author: Orit Levin [RFC3762] Service Name: "pres" URI Scheme(s): "pres:" Functional Specification: see Section 4 of [RFC3953] Security considerations: see Section 6 of [RFC3953] Intended usage: COMMON Author: Jon Peterson (jon.peterson&neustar.biz) Any other information that the author deems interesting: See Section 3 of [RFC3953] [RFC3953] -- Please try Numb, a STUN/TURN server implementation. Free access at http://numb.viagenie.ca/. _______________________________________________ enum mailing list enum@ietf.org https://www.ietf.org/mailman/listinfo/enum From enum-bounces@ietf.org Thu Oct 16 08:22:28 2008 Return-Path: X-Original-To: enum-archive@megatron.ietf.org Delivered-To: ietfarch-enum-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A8ECD3A6945; Thu, 16 Oct 2008 08:22:28 -0700 (PDT) X-Original-To: enum@core3.amsl.com Delivered-To: enum@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 73FB83A690E for ; Wed, 15 Oct 2008 13:30:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.361 X-Spam-Level: X-Spam-Status: No, score=-6.361 tagged_above=-999 required=5 tests=[AWL=0.237, BAYES_00=-2.599, HTML_MESSAGE=0.001, 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 XpdPZ44PnY0f for ; Wed, 15 Oct 2008 13:30:29 -0700 (PDT) Received: from EXPFE100-1.exc.icann.org (expfe100-1.exc.icann.org [64.78.22.236]) by core3.amsl.com (Postfix) with ESMTP id A1A623A68F8 for ; Wed, 15 Oct 2008 13:30:29 -0700 (PDT) Received: from EXVPMBX100-1.exc.icann.org ([64.78.22.233]) by EXPFE100-1.exc.icann.org ([64.78.22.236]) with mapi; Wed, 15 Oct 2008 13:31:26 -0700 From: Michelle Cotton To: "enum@ietf.org" , "bernie@hoeneisen.ch" , "alexander.mayrhofer@nic.at" Date: Wed, 15 Oct 2008 13:31:19 -0700 Thread-Topic: Example XML chunk for enum-services [IANA #171390] Thread-Index: Acku8ElFCApkOQ0tRASkK9ksHFeurwAFLF4J Message-ID: In-Reply-To: <48F63048.4060603@viagenie.ca> Accept-Language: en-US Content-Language: en X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US MIME-Version: 1.0 X-Mailman-Approved-At: Thu, 16 Oct 2008 08:22:26 -0700 Cc: Simon Perreault , Marc Blanchet , "rt-comment@icann.org" Subject: [Enum] Example XML chunk for enum-services [IANA #171390] 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: , Content-Type: multipart/mixed; boundary="===============0641261358==" Sender: enum-bounces@ietf.org Errors-To: enum-bounces@ietf.org --===============0641261358== Content-Language: en Content-Type: multipart/alternative; boundary="_000_C51BA1271F0A1michellecottonicannorg_" --_000_C51BA1271F0A1michellecottonicannorg_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Bernie, all. >From draft-ietf-enum-enumservices-guide-12, Section 5.2, below is an exampl= e of what the XML chunk could look like. Protocol-based foo bar bar bars This Enumservice indicates that the resource identified can be addressed by the associated URI in order to foo the bar. [...] See , Section 7. COMMON Further information free text... John Doe ACME Corp. mailto:jdoe@example.com 2008-10-10 Jane Dale ACME Corp. mailto:jdale@example.com 2008-10-10 Fields having "N/A" as value should instead simply be omitted in XML. We did notice in the document it says "Note: You MUST NOT put email address= es in the authors field of an IANA Registration." I would prefer a "Registrant" and a "Registrant E-mail". Then a separate "= Specification" where it points to the document and that is where a person c= ould get the contact info for the authors. What are your thoughts on that? Is it possible to have the document reflec= t those? Thanks, Michelle Cotton IANA --_000_C51BA1271F0A1michellecottonicannorg_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Example XML chunk for enum-services [IANA #171390] Bernie, all.

>From draft-ietf-enum-enumservices-guide-12, Section 5.2, below is an exampl= e of what the XML chunk could look like.

<record>
  <class>Protocol-based</class>
  <type>foo</type>
  <subtype>bar</subtype>
  <scheme>bar</scheme>
  <scheme>bars</scheme>
  <spec>
    This Enumservice indicates that the resource identi= fied can be
    addressed by the associated URI in order to foo the= bar. [...]
  </spec>
  <security>See <xref type=3D"rfc" data=3D&quo= t;rfc9999"/>, Section 7.</security>
  <usage>COMMON</usage>
  <xref type=3D"rfc" data=3D"rfc9999"/>=
  <xref type=3D"person" data=3D"John_Doe"/= >
  <xref type=3D"person" data=3D"Jane_Dale"= />
  <info>Further information free text...</info>
</record>

<person id=3D"John_Doe">
  <name>John Doe</name>
  <org>ACME Corp.</org>
  <uri>mail= to:jdoe@example.com</uri>
  <updated>2008-10-10</updated>
</person>
<person id=3D"Jane_Dale">
  <name>Jane Dale</name>
  <org>ACME Corp.</org>
  <uri>mai= lto:jdale@example.com</uri>
  <updated>2008-10-10</updated>
</person>

Fields having "N/A" as value should instead simply be omitted in = XML.

We did notice in the document it says "= Note: You MUST NOT put email addresses in the authors field of an IANA Regi= stration."
I would prefer a "Registrant" and a "Registrant E-mail"= .  Then a separate "Specification" where it points to the do= cument and that is where a person could get the contact info for the author= s.
What are your thoughts on that?  Is it possible to have the document r= eflect those?

Thanks,

Michelle Cotton
IANA



 --_000_C51BA1271F0A1michellecottonicannorg_-- --===============0641261358== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ enum mailing list enum@ietf.org https://www.ietf.org/mailman/listinfo/enum --===============0641261358==-- From enum-bounces@ietf.org Thu Oct 16 08:22:45 2008 Return-Path: X-Original-To: enum-archive@megatron.ietf.org Delivered-To: ietfarch-enum-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id F13453A69E6; Thu, 16 Oct 2008 08:22:44 -0700 (PDT) X-Original-To: enum@core3.amsl.com Delivered-To: enum@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 686B13A69E6 for ; Thu, 16 Oct 2008 08:22:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.949 X-Spam-Level: X-Spam-Status: No, score=-4.949 tagged_above=-999 required=5 tests=[AWL=1.650, BAYES_00=-2.599, 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 vk60rL7WEtaq for ; Thu, 16 Oct 2008 08:22:43 -0700 (PDT) Received: from mx4.nominet.org.uk (mx4.nominet.org.uk [213.248.199.24]) by core3.amsl.com (Postfix) with ESMTP id 03D893A69AB for ; Thu, 16 Oct 2008 08:22:42 -0700 (PDT) DomainKey-Signature: s=main.dk.nominet.selector; d=nominet.org.uk; c=nofws; q=dns; h=X-IronPort-AV:Received:In-Reply-To:To:Cc:Subject: MIME-Version:X-Mailer:Message-ID:From:Date:X-MIMETrack: Content-Type; b=HfWNVFbGJuIsYyJTzrtkQm91EV5VsG1oXFlSolA3QNir9OI/GVxWrEOl aG8tvecZOZp23ZFROSysD/zyR3ZZYf1rr2ZNBhdXMud/TJld9Kfmhvfyc ABfZJcpmCrEgH22; DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=nominet.org.uk; i=Ray.Bellis@nominet.org.uk; q=dns/txt; s=main.dkim.nominet.selector; t=1224170625; x=1255706625; h=from:sender:reply-to:subject:date:message-id:to:cc: mime-version:content-transfer-encoding:content-id: content-description:resent-date:resent-from:resent-sender: resent-to:resent-cc:resent-message-id:in-reply-to: references:list-id:list-help:list-unsubscribe: list-subscribe:list-post:list-owner:list-archive; z=From:=20Ray.Bellis@nominet.org.uk|Subject:=20Re:=20[Enum ]=20What=20issues=20do=20we=20need=20to=20cover/finalize =20in=20Minneapolis?|Date:=20Thu,=2016=20Oct=202008=2016: 23:40=20+0100|Message-ID:=20|To:=20Lawre nce=20Conroy=20|Cc:=20enum@ietf. org|MIME-Version:=201.0|In-Reply-To:=20<48C4C8D4-BF2E-4E0 B-868C-52D699D4A778@insensate.co.uk>; bh=aLf8SHQgISwLKYKy8p9EE7EygA74DHIi5Dp8/Ysmsfg=; b=tmoJfus5/74LH7RmvZJ5Nb2sWQCuWLxI9h2okFHUNXu4gtzeT6kMHPNY yiXlpvorbOHP6w59HcIO8FORj8Dh1LZC4UMdEj9/+QXEuFxBoVh083+oM E0Iudni11rBICVm; X-IronPort-AV: E=Sophos;i="4.33,423,1220223600"; d="scan'208";a="6296469" Received: from notes1.nominet.org.uk ([213.248.197.128]) by mx4.nominet.org.uk with ESMTP; 16 Oct 2008 16:23:41 +0100 In-Reply-To: <48C4C8D4-BF2E-4E0B-868C-52D699D4A778@insensate.co.uk> To: Lawrence Conroy MIME-Version: 1.0 X-Mailer: Lotus Notes Release 7.0.3 September 26, 2007 Message-ID: From: Ray.Bellis@nominet.org.uk Date: Thu, 16 Oct 2008 16:23:40 +0100 X-MIMETrack: Serialize by Router on notes1/Nominet(Release 7.0.1FP1 | May 25, 2006) at 16/10/2008 04:23:41 PM, Serialize complete at 16/10/2008 04:23:41 PM Cc: enum@ietf.org Subject: Re: [Enum] What issues do we need to cover/finalize in Minneapolis? 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: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: enum-bounces@ietf.org Errors-To: enum-bounces@ietf.org > Re Send-N - I had thought that was to be found a home in another groups, > in Apps (as I recall). Does anyone know what happened next? Jon promised to shepherd this and I've been seeking guidance from him on how to progress it but so far without response. Ray _______________________________________________ enum mailing list enum@ietf.org https://www.ietf.org/mailman/listinfo/enum From enum-bounces@ietf.org Thu Oct 16 09:43:00 2008 Return-Path: X-Original-To: enum-archive@megatron.ietf.org Delivered-To: ietfarch-enum-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 275923A6B56; Thu, 16 Oct 2008 09:43:00 -0700 (PDT) X-Original-To: enum@core3.amsl.com Delivered-To: enum@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 5A6473A6B56 for ; Thu, 16 Oct 2008 09:42:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.634 X-Spam-Level: X-Spam-Status: No, score=-5.634 tagged_above=-999 required=5 tests=[AWL=0.615, 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 XgD30BJA142z for ; Thu, 16 Oct 2008 09:42:58 -0700 (PDT) Received: from office.denic.de (gw-office.denic.de [81.91.160.182]) by core3.amsl.com (Postfix) with ESMTP id 7DCC33A6A9A for ; Thu, 16 Oct 2008 09:42:58 -0700 (PDT) Received: from denic.de ([10.122.65.106]) by office.denic.de with esmtp id 1KqVx7-00016W-2z; Thu, 16 Oct 2008 18:43:57 +0200 Received: by unknown.office.denic.de (Postfix, from userid 501) id 0373A83A2D6; Thu, 16 Oct 2008 18:43:56 +0200 (CEST) Date: Thu, 16 Oct 2008 18:43:56 +0200 From: Peter Koch To: IETF ENUM WG Message-ID: <20081016164356.GG59733@unknown.office.denic.de> Mail-Followup-To: IETF ENUM WG References: <00ef01c92eec$5601d510$02057f30$@us> Mime-Version: 1.0 Content-Disposition: inline In-Reply-To: <00ef01c92eec$5601d510$02057f30$@us> User-Agent: Mutt/1.4.2.1i Subject: Re: [Enum] What issues do we need to cover/finalize in Minneapolis? 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: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: enum-bounces@ietf.org Errors-To: enum-bounces@ietf.org On Wed, Oct 15, 2008 at 01:34:12PM -0400, Richard Shockey wrote: > > I have a one hour slot allocated on Friday..but do we even need it? my impression in Dublin was that we were rather short of time. While there are mostly procedural and organizational questions left, I'm pretty sure we can usefully fill at least this one hour. There's the question of "beta testing" the Enumservices guidlines, minor remaining tweaks to the draft itself as well as dealing with x-services. Also a summary and status discussion for a couple of the documents marked as 'active' or 'in iesg review' could be helpful for the WG to be able to agree on a schedule for winding down. Also, I'm tempted to propose a moratorium for adopting new or modified Enumservices. -Peter _______________________________________________ enum mailing list enum@ietf.org https://www.ietf.org/mailman/listinfo/enum From enum-bounces@ietf.org Thu Oct 16 11:31:31 2008 Return-Path: X-Original-To: enum-archive@megatron.ietf.org Delivered-To: ietfarch-enum-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B5E213A68BA; Thu, 16 Oct 2008 11:31:31 -0700 (PDT) X-Original-To: enum@core3.amsl.com Delivered-To: enum@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 3AA333A684C for ; Thu, 16 Oct 2008 11:31:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.451 X-Spam-Level: X-Spam-Status: No, score=-2.451 tagged_above=-999 required=5 tests=[AWL=0.148, 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 P-YvPC5z5s8t for ; Thu, 16 Oct 2008 11:31:29 -0700 (PDT) Received: from mail.songbird.com (unknown [IPv6:2001:470:1:76:2c0:9fff:fe3e:4009]) by core3.amsl.com (Postfix) with ESMTP id 0492F3A67D4 for ; Thu, 16 Oct 2008 11:31:28 -0700 (PDT) Received: from rshockeyPC (neustargw.va.neustar.com [209.173.53.233]) (authenticated bits=0) by mail.songbird.com (8.12.11.20060308/8.12.11) with ESMTP id m9GIQlae018971 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Thu, 16 Oct 2008 11:27:03 -0700 From: "Richard Shockey" To: "'Peter Koch'" , "'IETF ENUM WG'" References: <00ef01c92eec$5601d510$02057f30$@us> <20081016164356.GG59733@unknown.office.denic.de> In-Reply-To: <20081016164356.GG59733@unknown.office.denic.de> Date: Thu, 16 Oct 2008 14:27:48 -0400 Message-ID: <003c01c92fbd$03191670$094b4350$@us> MIME-Version: 1.0 X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: AckvrkZ6QTSvAkvXTPyHfiUCueKc8QADnC3A Content-Language: en-us X-SongbirdInformation: support@songbird.com for more information X-Songbird: Clean X-Songbird-From: richard@shockey.us Cc: =?iso-8859-1?Q?'Patrik_F=E4ltstr=F6m'?= Subject: Re: [Enum] What issues do we need to cover/finalize in Minneapolis? Agenda items ?? 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: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: enum-bounces@ietf.org Errors-To: enum-bounces@ietf.org OK ... I'm convinced ... if we have relevant agenda items please forward them to the chairs so we can process started. > -----Original Message----- > From: enum-bounces@ietf.org [mailto:enum-bounces@ietf.org] On Behalf > Of Peter Koch > Sent: Thursday, October 16, 2008 12:44 PM > To: IETF ENUM WG > Subject: Re: [Enum] What issues do we need to cover/finalize in > Minneapolis? > > On Wed, Oct 15, 2008 at 01:34:12PM -0400, Richard Shockey wrote: > > > > I have a one hour slot allocated on Friday..but do we even need it? > > my impression in Dublin was that we were rather short of time. While > there are mostly procedural and organizational questions left, I'm > pretty sure we can usefully fill at least this one hour. > > There's the question of "beta testing" the Enumservices guidlines, > minor remaining tweaks to the draft itself as well as dealing with > x-services. Also a summary and status discussion for a couple of the > documents marked as 'active' or 'in iesg review' could be helpful > for the WG to be able to agree on a schedule for winding down. > > Also, I'm tempted to propose a moratorium for adopting new or modified > Enumservices. > > -Peter > _______________________________________________ > 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 enum-bounces@ietf.org Fri Oct 17 05:16:28 2008 Return-Path: X-Original-To: enum-archive@megatron.ietf.org Delivered-To: ietfarch-enum-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 76F563A6AA4; Fri, 17 Oct 2008 05:16:28 -0700 (PDT) X-Original-To: enum@core3.amsl.com Delivered-To: enum@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 2D2E43A6827 for ; Fri, 17 Oct 2008 05:16:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.464 X-Spam-Level: X-Spam-Status: No, score=-2.464 tagged_above=-999 required=5 tests=[AWL=0.135, 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 c9AjLazWCycv for ; Fri, 17 Oct 2008 05:16:26 -0700 (PDT) Received: from GIC-VDL-228-151.as16215.net (gic-vdl-228-151.as16215.net [82.195.228.151]) by core3.amsl.com (Postfix) with ESMTP id 4443C3A6AA4 for ; Fri, 17 Oct 2008 05:16:25 -0700 (PDT) Received: from localhost ([127.0.0.1]) by GIC-VDL-228-151.as16215.net with esmtp (Exim 4.63) (envelope-from ) id 1KqoHK-00059r-R2; Fri, 17 Oct 2008 14:18:02 +0200 Date: Fri, 17 Oct 2008 14:18:02 +0200 (CEST) From: Bernie Hoeneisen X-X-Sender: bhoeneis@GIC-VDL-228-151.as16215.net To: Michelle Cotton via RT , Michelle Cotton In-Reply-To: Message-ID: References: MIME-Version: 1.0 X-SA-Exim-Connect-IP: 127.0.0.1 X-SA-Exim-Mail-From: bernie@ietf.hoeneisen.ch X-SA-Exim-Scanned: No (on GIC-VDL-228-151.as16215.net); SAEximRunCond expanded to false Cc: IETF ENUM list Subject: Re: [Enum] [IANA #171390] Revision of IANA Enumservice registry (fwd) 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: , Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed" Sender: enum-bounces@ietf.org Errors-To: enum-bounces@ietf.org Hi Michelle Thanks your the help with the XML stuff. (Alex, my co-author, will track the XML issue for the time being.) There is one more question I'd like get your opinion on: You expressed, that the process specified in draft-ietf-enum-enumservices-guide-12 is new to IANA. (Below you can find the background information on why I've proposed it that way.) Is the process as specified in draft-ietf-enum-enumservices-guide-12 fine with you? Or do you have an idea on how to make it simpler, still meeting the requirements? Could you provide us with an answer by today? cheers, Bernie On Mon, 5 Oct 2008, Bernie Hoeneisen wrote: > >On Fri, 3 Oct 2008, Michelle Cotton via RT wrote: >> >> The expert review process in this document is slightly different than the >> one that IANA currently uses. For most registries, requests are sent to >> IANA, we forward the request to the expert for review, after the approval >> IANA registers the parameter and then notifies the requester of the >> completed registration. > > Do these IANA registries also use "Specification Required" as per RFC 5226? > > I see your point. The document attempts to ensure both requirements: "Expert > Review" and "Specification Required". > > In other words, before IANA can add the Enumservice to the Registry, there > needs to be a Specification according to RFC 5226. Usually this is not the > case at the time the expert reviews the Enumservice. Expert Review might > result in changes. > >> In this case, the expert is approving the template and it appears they also >> have to approve the specification after it is published? It seems a bit >> fuzzy to me. >> Or is this the case where the expert my assist in making the template >> better before it gets finalization in a document? If that is the case, then >> IANA will have to go to the expert twice in this case? Once for the >> enumservice template, and then second to verify the specification has been >> published. > > After the Experts have approved the specification it is published somewhere. > After publication, IANA gets a request to add the Enumservice to the > Registry. > > No further Expert Review is needed at that point in time, but it needs to be > ensured the published version is the same as the one approved earlier by the > Experts (and the requirements for "Specification Required" according to RFC > 5226 are met). > > I am not really happy with this part of the process, but I see no alternative > to ensure publication according to RFC 5226. Please tell us, if you see a > better way to acomplish the same goal. > > I have a feeling, this is an issue for rfc5226bis... _______________________________________________ enum mailing list enum@ietf.org https://www.ietf.org/mailman/listinfo/enum From enum-bounces@ietf.org Sat Oct 18 12:48:52 2008 Return-Path: X-Original-To: enum-archive@megatron.ietf.org Delivered-To: ietfarch-enum-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 758B73A683A; Sat, 18 Oct 2008 12:48:52 -0700 (PDT) X-Original-To: enum@core3.amsl.com Delivered-To: enum@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C211D3A6B12 for ; Fri, 17 Oct 2008 14:11:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.307 X-Spam-Level: X-Spam-Status: No, score=-1.307 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, MISSING_HEADERS=1.292] 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 CG4D-Dm8h7gz for ; Fri, 17 Oct 2008 14:11:51 -0700 (PDT) Received: from request.iana.org (request.iana.org [208.77.188.221]) by core3.amsl.com (Postfix) with ESMTP id DAD603A6B09 for ; Fri, 17 Oct 2008 14:11:51 -0700 (PDT) Received: from request.iana.org (localhost.localdomain [127.0.0.1]) by request.iana.org (8.13.8/8.13.8) with ESMTP id m9HLBuOW013167 for ; Fri, 17 Oct 2008 14:11:56 -0700 Received: (from apache@localhost) by request.iana.org (8.13.8/8.13.8/Submit) id m9HLBuAn013166; Fri, 17 Oct 2008 21:11:56 GMT From: "Michelle Cotton via RT" In-Reply-To: References: Message-ID: Precedence: bulk X-RT-Loop-Prevention: IANA RT-Ticket: IANA #171390 Managed-by: RT 3.8.1 (http://www.bestpractical.com/rt/) RT-Originator: michelle.cotton@icann.org Cc: enum@ietf.org MIME-Version: 1.0 X-RT-Original-Encoding: utf-8 Date: Fri, 17 Oct 2008 21:11:56 +0000 X-Mailman-Approved-At: Sat, 18 Oct 2008 12:48:51 -0700 Subject: [Enum] [IANA #171390] FW: Revision of IANA Enumservice registry X-BeenThere: enum@ietf.org X-Mailman-Version: 2.1.9 Reply-To: iana-issues@icann.org List-Id: Enum Discussion List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: enum-bounces@ietf.org Errors-To: enum-bounces@ietf.org On Fri Oct 17 12:18:01 2008, bernie@ietf.hoeneisen.ch wrote: > Hi Michelle > > Thanks your the help with the XML stuff. (Alex, my co-author, will > track > the XML issue for the time being.) Great, we look forward to finishing that up with Alex. > > There is one more question I'd like get your opinion on: You > expressed, > that the process specified in draft-ietf-enum-enumservices-guide-12 is > new > to IANA. (Below you can find the background information on why I've > proposed it that way.) > > Is the process as specified in draft-ietf-enum-enumservices-guide-12 > fine > with you? Or do you have an idea on how to make it simpler, still > meeting > the requirements? > > Could you provide us with an answer by today? > > cheers, > Bernie > Bernie, I have reviewed the IANA Considerations section in version 12 of the document once more. Most everything does seem ok. I do have a couple comments. I still feel the review described here does not exactly follow what is described in RFC5226, so it might be worth stating that it follows RFC 5226 with some additional procedures. When a registration is first reviewed by an expert and then is approved. IANA will notify the author (requester). At that time, it seems that the registration is then put "on hold" waiting for the publication of the specification. When IANA has these requests in our ticketing system, is it sufficient to put this request as "waiting on the requester" as IANA waits to be informed the spec has been published? Is there a time limit of how long IANA waits? This means IANA will have a ticket open for a long time in our queue. Also. For section 11.2, does IANA really need to make the xml2rfc template public or is having it in this document enough? Also, will you be adding the "chunk" for the registry when it is finalized for future registrations? Hope this review helps. Michelle Cotton IANA > > On Mon, 5 Oct 2008, Bernie Hoeneisen wrote: > > > >On Fri, 3 Oct 2008, Michelle Cotton via RT wrote: > >> > >> The expert review process in this document is slightly different > than the > >> one that IANA currently uses. For most registries, requests are > sent to > >> IANA, we forward the request to the expert for review, after the > approval > >> IANA registers the parameter and then notifies the requester of the > >> completed registration. > > > > Do these IANA registries also use "Specification Required" as per > RFC 5226? > > > > I see your point. The document attempts to ensure both requirements: > "Expert > > Review" and "Specification Required". > > > > In other words, before IANA can add the Enumservice to the Registry, > there > > needs to be a Specification according to RFC 5226. Usually this is > not the > > case at the time the expert reviews the Enumservice. Expert Review > might > > result in changes. > > > >> In this case, the expert is approving the template and it appears > they also > >> have to approve the specification after it is published? It seems > a bit > >> fuzzy to me. > >> Or is this the case where the expert my assist in making the > template > >> better before it gets finalization in a document? If that is the > case, then > >> IANA will have to go to the expert twice in this case? Once for > the > >> enumservice template, and then second to verify the specification > has been > >> published. > > > > After the Experts have approved the specification it is published > somewhere. > > After publication, IANA gets a request to add the Enumservice to the > > Registry. > > > > No further Expert Review is needed at that point in time, but it > needs to be > > ensured the published version is the same as the one approved > earlier by the > > Experts (and the requirements for "Specification Required" according > to RFC > > 5226 are met). > > > > I am not really happy with this part of the process, but I see no > alternative > > to ensure publication according to RFC 5226. Please tell us, if you > see a > > better way to acomplish the same goal. > > > > I have a feeling, this is an issue for rfc5226bis... > _______________________________________________ enum mailing list enum@ietf.org https://www.ietf.org/mailman/listinfo/enum From enum-bounces@ietf.org Mon Oct 20 00:17:18 2008 Return-Path: X-Original-To: enum-archive@megatron.ietf.org Delivered-To: ietfarch-enum-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D68D73A68F4; Mon, 20 Oct 2008 00:17:18 -0700 (PDT) X-Original-To: enum@core3.amsl.com Delivered-To: enum@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 864F13A68FF for ; Mon, 20 Oct 2008 00:17:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.73 X-Spam-Level: X-Spam-Status: No, score=-0.73 tagged_above=-999 required=5 tests=[AWL=-0.900, BAYES_50=0.001, HELO_EQ_AT=0.424, HOST_EQ_AT=0.745, RCVD_IN_DNSWL_LOW=-1] 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 0Bl+eZrBDExg for ; Mon, 20 Oct 2008 00:17:17 -0700 (PDT) Received: from mail.bofh.priv.at (fardach.bofh.priv.at [88.198.34.164]) by core3.amsl.com (Postfix) with ESMTP id B81C13A68F4 for ; Mon, 20 Oct 2008 00:17:17 -0700 (PDT) Received: from [10.10.0.105] (nat.labs.nic.at [83.136.33.3]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mail.bofh.priv.at (Postfix) with ESMTP id 539244C065; Mon, 20 Oct 2008 09:18:22 +0200 (CEST) Message-ID: <48FC30C0.5020903@nic.at> Date: Mon, 20 Oct 2008 09:18:24 +0200 From: Otmar Lendl User-Agent: Thunderbird 2.0.0.17 (Windows/20080914) MIME-Version: 1.0 To: enum@ietf.org References: <00ef01c92eec$5601d510$02057f30$@us> In-Reply-To: <00ef01c92eec$5601d510$02057f30$@us> Cc: jon.peterson@neustar.biz Subject: Re: [Enum] What issues do we need to cover/finalize in Minneapolis? 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: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: enum-bounces@ietf.org Errors-To: enum-bounces@ietf.org Richard Shockey wrote: > I have a one hour slot allocated on Friday..but do we even need it? Although, strictly speaking, this is no longer WG business: Can we have an update on what's holding up the i-enum (combined and plain) documents? Publication request was 2007-01-22. We're approaching the two-year anniversary. /ol -- // Otmar Lendl , T: +43 1 5056416 - 33, F: - 933 // _______________________________________________ enum mailing list enum@ietf.org https://www.ietf.org/mailman/listinfo/enum From enum-bounces@ietf.org Mon Oct 20 08:04:58 2008 Return-Path: X-Original-To: enum-archive@megatron.ietf.org Delivered-To: ietfarch-enum-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A05B23A6AE5; Mon, 20 Oct 2008 08:04:58 -0700 (PDT) X-Original-To: enum@core3.amsl.com Delivered-To: enum@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 801AD3A688E for ; Sun, 19 Oct 2008 16:37:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.53 X-Spam-Level: X-Spam-Status: No, score=-2.53 tagged_above=-999 required=5 tests=[AWL=0.069, 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 vQ7CBjCeJgBU for ; Sun, 19 Oct 2008 16:37:18 -0700 (PDT) Received: from GIC-VDL-228-151.as16215.net (gic-vdl-228-151.as16215.net [82.195.228.151]) by core3.amsl.com (Postfix) with ESMTP id 585ED3A67B6 for ; Sun, 19 Oct 2008 16:37:16 -0700 (PDT) Received: from localhost ([127.0.0.1]) by GIC-VDL-228-151.as16215.net with esmtp (Exim 4.63) (envelope-from ) id 1Krhrq-0007uH-RT; Mon, 20 Oct 2008 01:39:26 +0200 Date: Mon, 20 Oct 2008 01:39:26 +0200 (CEST) From: Bernie Hoeneisen X-X-Sender: bhoeneis@GIC-VDL-228-151.as16215.net To: Michelle Cotton via RT In-Reply-To: Message-ID: References: MIME-Version: 1.0 X-SA-Exim-Connect-IP: 127.0.0.1 X-SA-Exim-Mail-From: bernie@hoeneisen.ch X-SA-Exim-Scanned: No (on GIC-VDL-228-151.as16215.net); SAEximRunCond expanded to false X-Mailman-Approved-At: Mon, 20 Oct 2008 08:04:58 -0700 Cc: IETF ENUM list Subject: Re: [Enum] [IANA #171390] FW: Revision of IANA Enumservice registry 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: , Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed" Sender: enum-bounces@ietf.org Errors-To: enum-bounces@ietf.org Michelle, Thanks for your fast feedback. I have changed the document to make it more clear, i.e. I made a difference between RFC specs and other specs. RFC specs follow the normal IETF procedures, non-RFC specs are handled slightly different (as outlined below). The XML2RFC template is no longer part of the document, so no worries here. The only comment I have not addressed (yet) is the time limit. Does this really have to be specified? If yes, what would be good figure? cheers, Bernie > Bernie, I have reviewed the IANA Considerations section in version 12 of the > document once more. Most everything does seem ok. > I do have a couple comments. > > I still feel the review described here does not exactly follow what is described > in RFC5226, so it might be worth stating that it follows RFC 5226 with some > additional procedures. > > When a registration is first reviewed by an expert and then is approved. IANA > will notify the author (requester). At that time, it seems that the > registration is then put "on hold" waiting for the publication of the > specification. When IANA has these requests in our ticketing system, is it > sufficient to put this request as "waiting on the requester" as IANA waits to be > informed the spec has been published? Is there a time limit of how long IANA > waits? This means IANA will have a ticket open for a long time in our queue. > > Also. For section 11.2, does IANA really need to make the xml2rfc template > public or is having it in this document enough? Also, will you be adding the > "chunk" for the registry when it is finalized for future registrations? > > Hope this review helps. > > Michelle Cotton > IANA _______________________________________________ enum mailing list enum@ietf.org https://www.ietf.org/mailman/listinfo/enum From enum-bounces@ietf.org Mon Oct 20 13:57:08 2008 Return-Path: X-Original-To: enum-archive@megatron.ietf.org Delivered-To: ietfarch-enum-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id F18EB3A6ADC; Mon, 20 Oct 2008 13:57:07 -0700 (PDT) X-Original-To: enum@core3.amsl.com Delivered-To: enum@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 9A5CF3A6AF4 for ; Mon, 20 Oct 2008 13:57:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.307 X-Spam-Level: X-Spam-Status: No, score=-1.307 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, MISSING_HEADERS=1.292] 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 WCrUfRNOdFwL for ; Mon, 20 Oct 2008 13:57:05 -0700 (PDT) Received: from request.iana.org (request.iana.org [208.77.188.221]) by core3.amsl.com (Postfix) with ESMTP id DF9673A6AF3 for ; Mon, 20 Oct 2008 13:57:05 -0700 (PDT) Received: from request.iana.org (localhost.localdomain [127.0.0.1]) by request.iana.org (8.13.8/8.13.8) with ESMTP id m9KKvIcb012998 for ; Mon, 20 Oct 2008 13:57:18 -0700 Received: (from apache@localhost) by request.iana.org (8.13.8/8.13.8/Submit) id m9KKvIQb012997; Mon, 20 Oct 2008 20:57:18 GMT From: "Michelle Cotton via RT" In-Reply-To: References: Message-ID: Precedence: bulk X-RT-Loop-Prevention: IANA RT-Ticket: IANA #171390 Managed-by: RT 3.8.1 (http://www.bestpractical.com/rt/) RT-Originator: michelle.cotton@icann.org Cc: enum@ietf.org MIME-Version: 1.0 X-RT-Original-Encoding: utf-8 Date: Mon, 20 Oct 2008 20:57:18 +0000 Subject: [Enum] [IANA #171390] FW: Revision of IANA Enumservice registry X-BeenThere: enum@ietf.org X-Mailman-Version: 2.1.9 Reply-To: iana-issues@icann.org List-Id: Enum Discussion List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: enum-bounces@ietf.org Errors-To: enum-bounces@ietf.org Hello Bernie, Will there be a version 13 to look at? I just checked and didn't see one. I didn't see any response to how IANA will categorize the request's stages as far as our tracking goes so hopefully what I outlined below as ok (as far as waiting on requester). For the time limit, it is a bit hard... So if the documentation is going to be in the form of an RFC, maybe the ticket should just be closed after the registration is approved by the expert, as the addition of the service name would follow the normal RFC publication process and be part of the approval. The only thing is that the expert would need to review it as part of the approval. For the other types of documentation, it really depends on how long other types of documents take to get published. We could just resolve the request after the expert approves the template. Then open a new request when the documentation has been published and then have the expert do the second review then. What are your thoughts? Thanks, Michelle On Sun Oct 19 23:38:55 2008, bernie@hoeneisen.ch wrote: > Michelle, > > Thanks for your fast feedback. > > I have changed the document to make it more clear, i.e. I made a > difference between RFC specs and other specs. RFC specs follow the > normal > IETF procedures, non-RFC specs are handled slightly different (as > outlined > below). > > The XML2RFC template is no longer part of the document, so no worries > here. > > The only comment I have not addressed (yet) is the time limit. Does > this really have to be specified? If yes, what would be good figure? > > cheers, > Bernie > > > > > Bernie, I have reviewed the IANA Considerations section in version > 12 of the > > document once more. Most everything does seem ok. > > I do have a couple comments. > > > > I still feel the review described here does not exactly follow what > is described > > in RFC5226, so it might be worth stating that it follows RFC 5226 > with some > > additional procedures. > > > > When a registration is first reviewed by an expert and then is > approved. IANA > > will notify the author (requester). At that time, it seems that the > > registration is then put "on hold" waiting for the publication of > the > > specification. When IANA has these requests in our ticketing system, > is it > > sufficient to put this request as "waiting on the requester" as IANA > waits to be > > informed the spec has been published? Is there a time limit of how > long IANA > > waits? This means IANA will have a ticket open for a long time in > our queue. > > > > Also. For section 11.2, does IANA really need to make the xml2rfc > template > > public or is having it in this document enough? Also, will you be > adding the > > "chunk" for the registry when it is finalized for future > registrations? > > > > Hope this review helps. > > > > Michelle Cotton > > IANA > _______________________________________________ enum mailing list enum@ietf.org https://www.ietf.org/mailman/listinfo/enum From enum-bounces@ietf.org Tue Oct 21 02:07:19 2008 Return-Path: X-Original-To: enum-archive@megatron.ietf.org Delivered-To: ietfarch-enum-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id CEA273A6B3C; Tue, 21 Oct 2008 02:07:19 -0700 (PDT) X-Original-To: enum@core3.amsl.com Delivered-To: enum@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4C58A3A6B3C for ; Tue, 21 Oct 2008 02:07:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -8.825 X-Spam-Level: X-Spam-Status: No, score=-8.825 tagged_above=-999 required=5 tests=[AWL=-0.201, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_EQ_AT=0.424, RCVD_IN_DNSWL_HI=-8, RDNS_NONE=0.1] 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 t1CPAa1JGRND for ; Tue, 21 Oct 2008 02:07:17 -0700 (PDT) Received: from mail.sbg.nic.at (unknown [192.174.68.200]) by core3.amsl.com (Postfix) with ESMTP id 654AF3A6B2B for ; Tue, 21 Oct 2008 02:07:15 -0700 (PDT) Received: from localhost [127.0.0.1] by mail.sbg.nic.at with XWall v3.43 ; Tue, 21 Oct 2008 11:08:27 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Tue, 21 Oct 2008 11:08:26 +0200 Message-ID: <8BC845943058D844ABFC73D2220D466507AA5552@nics-mail.sbg.nic.at> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Example XML chunk for enum-services [IANA #171390] Thread-Index: Acku8ElFCApkOQ0tRASkK9ksHFeurwAFLF4JARVM8kA= References: <48F63048.4060603@viagenie.ca> From: "Alexander Mayrhofer" To: "Michelle Cotton" , , X-XWALL-BCKS: auto Cc: Simon Perreault , Marc Blanchet , rt-comment@icann.org Subject: Re: [Enum] Example XML chunk for enum-services [IANA #171390] 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: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: enum-bounces@ietf.org Errors-To: enum-bounces@ietf.org Hello Michelle, thanks for the suggested XML chunk. Generally, is there any suggestion on namespace/schema of that XML? i'm well aware that this is right now a chunk, but defining a namespace would allow to define a schema. more comments inline. > I'd rather suggest to name that "top" element "" - "record" seems too generic to me. > Protocol-based > foo > bar Fine with me. Those elements could be restricted fairly well in a schema - type as well as subtype are limited to 32 alpha/digit/dash characters. class would be a choice of possible values. > bar > bars I would rather call that "urischeme", but "scheme" is good enough, i think. > > This Enumservice indicates that the resource identified can be > addressed by the associated URI in order to foo the bar. [...] > hmm.. the naming of the element somehow would clash with the "specification reference" listed below. maybe rename that to "functionalspec" to make it clear? [see below for the "further info" element on content issue..] > See , Section > 7. fine with me. > COMMON Fine, would be easy to restrict it to the allowed values > I think that the reference to the specification deserves to be highlighted, i would suggest using something like the "security" element outlined above, for example: See BTW, how would one reference documents of other SDOs? like in XML2RFC templates? > > Fine with me - my question is what the relation between person objects and enumservices would be - would the person be a seperate object, or simple embedded in the Enumservice registration XML document? > Further information free text... There is an issue here, wich also applies to the "spec" element above - we have Enumservices registrations which use "markup" in those fields - bullet lists, paragraphs, etc. If we just allow plaintext here (which would be the simplest version) we would lose existing information. However, personally i think that such information should rather be contained in the registration document itself rather than the registry entry - > > > > John Doe > ACME Corp. > mailto:jdoe@example.com > 2008-10-10 > > > Jane Dale > ACME Corp. > mailto:jdale@example.com > 2008-10-10 > > > Fields having "N/A" as value should instead simply be omitted in XML. > > We did notice in the document it says "Note: You MUST NOT put > email addresses in the authors field of an IANA Registration." > I would prefer a "Registrant" and a "Registrant E-mail". > Then a separate "Specification" where it points to the > document and that is where a person could get the contact > info for the authors. > What are your thoughts on that? Is it possible to have the > document reflect those? I *think* the idea of not allowing an email address in the "author" field was that this information was supposed to be taken from the specification document's "authors" section. I'm happy to include the "person" information that you have outlined above, especially if there are other registries that make use of that scheme as well. Any comments? Alex _______________________________________________ enum mailing list enum@ietf.org https://www.ietf.org/mailman/listinfo/enum From enum-bounces@ietf.org Fri Oct 31 13:22:33 2008 Return-Path: X-Original-To: enum-archive@megatron.ietf.org Delivered-To: ietfarch-enum-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 1AEB53A6817; Fri, 31 Oct 2008 13:22:33 -0700 (PDT) X-Original-To: enum@core3.amsl.com Delivered-To: enum@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 82D123A6817 for ; Fri, 31 Oct 2008 13:22:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.335 X-Spam-Level: X-Spam-Status: No, score=0.335 tagged_above=-999 required=5 tests=[BAYES_50=0.001, 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 CqEQK2Li7kyd for ; Fri, 31 Oct 2008 13:22:31 -0700 (PDT) Received: from outbound-mail-136.bluehost.com (outbound-mail-136.bluehost.com [67.222.39.26]) by core3.amsl.com (Postfix) with SMTP id 96D7E3A679C for ; Fri, 31 Oct 2008 13:22:31 -0700 (PDT) Received: (qmail 7176 invoked by uid 0); 31 Oct 2008 20:22:28 -0000 Received: from unknown (HELO box462.bluehost.com) (74.220.219.62) by outboundproxy4.bluehost.com with SMTP; 31 Oct 2008 20:22:28 -0000 DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=default; d=shockey.us; h=Received:From:To:Subject:Date:Message-ID:MIME-Version:Content-Type:Content-Transfer-Encoding:X-Mailer:Thread-Index:Content-Language:X-Identified-User; b=kxLBJv5VdnInBMxTF1rYOnUTQ1uPyx5eBuN89P42zr0gvjJHOCwVX9y4k4NcBBuPNp0JMbfNo5mKwX6xClJtwQUTF6xf2epm2l7VZVPD/jGthfkbQXDtiWNz5wNrF+Ra; Received: from neustargw.va.neustar.com ([209.173.53.233] helo=rshockeyPC) by box462.bluehost.com with esmtpa (Exim 4.69) (envelope-from ) id 1Kw0Vn-0007eE-GB for enum@ietf.org; Fri, 31 Oct 2008 14:22:28 -0600 From: "Richard Shockey" To: Date: Fri, 31 Oct 2008 16:22:22 -0400 Message-ID: <007201c93b96$622784a0$26768de0$@us> MIME-Version: 1.0 X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: Ack7lmGAXhnEMZr6Su2HXnHsz5YSkw== Content-Language: en-us X-Identified-User: {3286:box462.bluehost.com:shockeyu:shockey.us} {sentby:smtp auth 209.173.53.233 authed with richard+shockey.us} Subject: [Enum] REMINDER ENUM WG agenda items. 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: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: enum-bounces@ietf.org Errors-To: enum-bounces@ietf.org If anyone wants specific time in MN for a agenda item ..now it the time to mail the chairs with your request. 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 _______________________________________________ enum mailing list enum@ietf.org https://www.ietf.org/mailman/listinfo/enum From enum-bounces@ietf.org Fri Oct 31 15:19:10 2008 Return-Path: X-Original-To: enum-archive@megatron.ietf.org Delivered-To: ietfarch-enum-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A8E4D3A6A64; Fri, 31 Oct 2008 15:19:10 -0700 (PDT) X-Original-To: enum@core3.amsl.com Delivered-To: enum@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E1F163A6A64 for ; Fri, 31 Oct 2008 15:19:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.832 X-Spam-Level: X-Spam-Status: No, score=-1.832 tagged_above=-999 required=5 tests=[AWL=0.433, 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 A9k-73qHKboz for ; Fri, 31 Oct 2008 15:19:09 -0700 (PDT) Received: from outbound-mail-137.bluehost.com (outbound-mail-137.bluehost.com [67.222.39.27]) by core3.amsl.com (Postfix) with SMTP id 153BB3A6839 for ; Fri, 31 Oct 2008 15:19:09 -0700 (PDT) Received: (qmail 20334 invoked by uid 0); 31 Oct 2008 22:19:06 -0000 Received: from unknown (HELO box462.bluehost.com) (74.220.219.62) by outboundproxy4.bluehost.com with SMTP; 31 Oct 2008 22:19:06 -0000 DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=default; d=shockey.us; h=Received:From:To:Subject:Date:Message-ID:MIME-Version:Content-Type:Content-Transfer-Encoding:X-Mailer:Thread-Index:Content-Language:X-Identified-User; b=Iu3Bv0yqyJKfu5kpJ5c+sLVBiecDLtBUzMQsXBIunxrSWlU0RXZsnH9z9jTsjc6cBV3XoICzYGQXWPT1lp3/dpmosg8PdCFBxzIUQHsZte7lTZ3HooEqf89zRjy7SHfW; Received: from pool-173-66-41-150.washdc.fios.verizon.net ([173.66.41.150] helo=rshockeyPC) by box462.bluehost.com with esmtpa (Exim 4.69) (envelope-from ) id 1Kw2Kf-0000Oe-Mq for enum@ietf.org; Fri, 31 Oct 2008 16:19:05 -0600 From: "Richard Shockey" To: Date: Fri, 31 Oct 2008 18:18:59 -0400 Message-ID: <003601c93ba6$ace8aef0$06ba0cd0$@us> MIME-Version: 1.0 X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: Ack7enpCHFL4AWZ3Rdmm4h0+/TWj+gALCszQ Content-Language: en-us X-Identified-User: {3286:box462.bluehost.com:shockeyu:shockey.us} {sentby:smtp auth 173.66.41.150 authed with richard+shockey.us} Subject: [Enum] FW: 73rd IETF - Final Agenda 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: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: enum-bounces@ietf.org Errors-To: enum-bounces@ietf.org -----Original Message----- From: ietf-announce-bounces@ietf.org [mailto:ietf-announce-bounces@ietf.org] On Behalf Of IETF Secretariat Sent: Friday, October 31, 2008 1:02 PM To: IETF Announcement list Cc: irsg@isi.edu; wgchairs@ietf.org; bofchairs@ietf.org Subject: 73rd IETF - Final Agenda 73rd IETF Meeting - Minneapolis, MN November 16-21, 2008 Host: Google The final agenda has been posted. Please note that changes to the agenda may still occur. You can view the agenda at: https://datatracker.ietf.org/meeting/73/agenda.html The social event will be held at GameWorks, you can get more information on the social event and purchase your ticket at: http://www.ietf.org/meetings/73/73-social.html The Hilton Minneapolis and Holiday Inn guest room blocks are now sold out but there are still rooms available at the Marquette Hotel. The Marquette has extended their cutoff date to November 10. Early-Bird registration cutoff is Friday, 7 November at 17:00 PDT (01:00 Saturday, November 8 UTC/GMT). After that time, the registration fee will increase by $150 USD to $785 USD. Only 16 days until the Minneapolis IETF! Online registration for the IETF meeting is at: http://www.ietf.org/meetings/73/ _______________________________________________ IETF-Announce mailing list IETF-Announce@ietf.org https://www.ietf.org/mailman/listinfo/ietf-announce _______________________________________________ enum mailing list enum@ietf.org https://www.ietf.org/mailman/listinfo/enum