From enum-bounces@ietf.org Wed Jan 02 12:00:12 2008 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1JA6wf-0002lq-DW; Wed, 02 Jan 2008 11:59:57 -0500 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1JA6we-0002j1-1a for enum@ietf.org; Wed, 02 Jan 2008 11:59:56 -0500 Received: from mail.songbird.com ([208.184.79.10]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1JA6wd-0006an-IY for enum@ietf.org; Wed, 02 Jan 2008 11:59:55 -0500 Received: from rshockeyPC (h-68-165-240-35.mclnva23.covad.net [68.165.240.35]) (authenticated bits=0) by mail.songbird.com (8.12.11.20060308/8.12.11) with ESMTP id m02Gwpqd028587 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Wed, 2 Jan 2008 08:59:09 -0800 From: "Richard Shockey" To: Date: Wed, 2 Jan 2008 11:58:43 -0500 Message-ID: <01e801c84d60$c94ec140$5bec43c0$@us> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 Thread-Index: Aca3xY1iIc3tIYqQTKyYngbYZG9Jtg== Content-Language: en-us X-SongbirdInformation: support@songbird.com for more information X-Songbird: Clean X-Songbird-From: richard@shockey.us X-Spam-Score: 0.0 (/) X-Scan-Signature: 3e15cc4fdc61d7bce84032741d11c8e5 Cc: 'Cullen Jennings' , =?iso-8859-1?Q?'=22Patrik_F=E4ltstr=F6m=22'?= , "'Peterson, Jon'" Subject: [Enum] ENUM Working Group Last Call on document draft-ietf-enum-softswitch-req-01.txt X-BeenThere: enum@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: richard@shockey.us List-Id: Enum Discussion List List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: enum-bounces@ietf.org Title : ENUM-based Softswitch Requirement Author(s) : J. Lim, et al. Filename : draft-ietf-enum-softswitch-req-01.txt Pages : 17 Date : 2007-10-24 This document describes experiences of operational requirements and several considerations for ENUM-based softswitches concerning call routing between two Korean VoIP carriers, gained during the ENUM pre- commercial trial hosted by National Internet Development Agency of Korea (NIDA) in 2006. These experiences show that an interim solution can maintain the stability of on-going commercial softswitch system operations during the initial stage of ENUM service, where the DNS does not have sufficient data for the majority of calls. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-enum-softswitch-req-01.txt The intent of the last call is to solicit comments before submitting the ID to the IESG as Informational. The purpose of a working group Last Call is in the style of "speak now or forever hold your peace" in case there are fundamental objections which have not gotten previous or adequate discussion, or minor errors which need correction. Work group last call will extend for approximately 2 weeks or so from today Jan 2 through Jan 21. We can modify that if new issues come up. Richard Shockey Director, Member of the Technical Staff NeuStar 46000 Center Oak Plaza - Sterling, VA 20166 sip:rshockey(at)iptel.org sip:57141@fwd.pulver.com PSTN Office +1 571.434.5651 PSTN Mobile: +1 703.593.2683 _______________________________________________ enum mailing list enum@ietf.org https://www1.ietf.org/mailman/listinfo/enum _______________________________________________ enum mailing list enum@ietf.org https://www1.ietf.org/mailman/listinfo/enum From enum-bounces@ietf.org Wed Jan 02 12:00:19 2008 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1JA6x1-00034S-52; Wed, 02 Jan 2008 12:00:19 -0500 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1JA6wr-0002xN-7Q for enum@ietf.org; Wed, 02 Jan 2008 12:00:09 -0500 Received: from mail.songbird.com ([208.184.79.10]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1JA6wq-0006bB-Oi for enum@ietf.org; Wed, 02 Jan 2008 12:00:09 -0500 Received: from rshockeyPC (h-68-165-240-35.mclnva23.covad.net [68.165.240.35]) (authenticated bits=0) by mail.songbird.com (8.12.11.20060308/8.12.11) with ESMTP id m02Gwpqe028587 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Wed, 2 Jan 2008 08:59:19 -0800 From: "Richard Shockey" To: Date: Wed, 2 Jan 2008 11:59:11 -0500 Message-ID: <01ef01c84d60$ce4b2710$6ae17530$@us> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 Thread-Index: Aca3xY1iIc3tIYqQTKyYngbYZG9Jtg== Content-Language: en-us X-SongbirdInformation: support@songbird.com for more information X-Songbird: Clean X-Songbird-From: richard@shockey.us X-Spam-Score: 0.0 (/) X-Scan-Signature: 538aad3a3c4f01d8b6a6477ca4248793 Cc: 'Cullen Jennings' , =?iso-8859-1?Q?'=22Patrik_F=E4ltstr=F6m=22'?= , "'Peterson, Jon'" Subject: [Enum] ENUM Working Group Last Call on document draft-ietf-enum-vmsg-01.txt X-BeenThere: enum@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: richard@shockey.us List-Id: Enum Discussion List List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: enum-bounces@ietf.org The intent of the last call is to solicit comments before submitting the ID to the IESG as a Proposed Standard. The purpose of a working group Last Call is in the style of "speak now or forever hold your peace" in case there are fundamental objections which have not gotten previous or adequate discussion, or minor errors which need correction. Title : IANA Registration of Enumservices for Voice and Video Messaging Author(s) : J. Livingood, D. Troshynski Filename : draft-ietf-enum-vmsg-01.txt Pages : 27 Date : 2007-12-18 This document registers the Enumservice named "vmsg", which is used to facilitate the real-time routing of voice and/or video communications to a messaging system. This vmsg Enumservice registers three Enumservice types; "voicemsg", "videomsg", and "unifmsg". A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-enum-vmsg-01.txt Work group last call will extend for approximately 2 weeks or so from today Jan 2 through Jan 21. We can modify that if new issues come up. Richard Shockey Director, Member of the Technical Staff NeuStar 46000 Center Oak Plaza - Sterling, VA 20166 sip:rshockey(at)iptel.org sip:57141@fwd.pulver.com PSTN Office +1 571.434.5651 PSTN Mobile: +1 703.593.2683 _______________________________________________ enum mailing list enum@ietf.org https://www1.ietf.org/mailman/listinfo/enum _______________________________________________ enum mailing list enum@ietf.org https://www1.ietf.org/mailman/listinfo/enum From enum-bounces@ietf.org Wed Jan 02 17:24:18 2008 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1JAC0R-0001j1-1v; Wed, 02 Jan 2008 17:24:11 -0500 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1JAC0Q-0001ht-0F for enum@ietf.org; Wed, 02 Jan 2008 17:24:10 -0500 Received: from nat.labs.nic.at ([83.136.33.3] helo=labs.nic.at) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1JAC0P-0006pa-3D for enum@ietf.org; Wed, 02 Jan 2008 17:24:09 -0500 Received: from lendl by labs.nic.at with local (Exim 3.36 #1 (Debian)) id 1JAC0J-0000ju-00; Wed, 02 Jan 2008 23:24:03 +0100 Date: Wed, 2 Jan 2008 23:24:03 +0100 From: Otmar Lendl To: Paul Erkkila Subject: Re: [Enum] New I-D:draft-kaplan-enum-source-uri-00.txt Message-ID: <20080102222403.GA2792@nic.at> Mail-Followup-To: Otmar Lendl , Paul Erkkila , Hadriel Kaplan , "enum@ietf.org" , "Robert H. Walter" , "Creighton, Tom" , Raja Gopal References: <20071212150130.GA14079@nic.at> <475FFD7C.80907@erkkila.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <475FFD7C.80907@erkkila.org> User-Agent: Mutt/1.5.9i X-Spam-Score: 0.0 (/) X-Scan-Signature: e8a67952aa972b528dd04570d58ad8fe Cc: "enum@ietf.org" , "Robert H. Walter" , "Creighton, Tom" , Raja Gopal , Hadriel Kaplan X-BeenThere: enum@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Enum Discussion List List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: enum-bounces@ietf.org On 2007/12/12 16:12, Paul Erkkila wrote: > Otmar Lendl wrote: > > > > > > Yes, the incremental change ist not that big. The question remains: > > > > Have we now reached the point where we should stop fiddling with the > > DNS protocol and should instead look for a directory lookup protocol > > which was designed from the beginning to support authenticated and > > complex queries returning structured data? > > LDAP? > I've been mulling over this question during the holidays. I've come to the following conclusion: The DNS (as well as LDAP) is primarily designed as a directory service. It is a protocol to query a database for records conforming to a specific question. The intelligence on how to interpret the data and what to do with this information (possibly combined with data learned from other sources) is in the device which asked the query. In terms of VoIP: the call routing algorithm runs inside the soft-switch. ENUM is just one input into this algorithm. What I see in various proposals here in the WG (starting with the trunk-ID draft ) and most clearly from this draft is a different approach to the overall architecture: The soft-switch should be dumb, all call routing decisions are out-sourced to the ENUM DNS servers. They do capacity planning, source-dependent routing and all the peering logic. If you take this approach, then of course the soft-switch needs to somehow communicate all the basics of that call to the ENUM DNS server so that it can make the correct call routing decision. Such "out-source the logic" approaches are not new. Network equipment handling dial-up sessions or DSL logins have been doing that for years. The protocol of choice for such applications has been RADIUS (perhaps now supplanted by DIAMETER). RADIUS supports almost arbitrary key-value pairs in the query: All the information the dumb switch has can thus be easily packed into the query. The same holds for the answer: it can instruct the soft-switch in detail what to do with the call. --- Yes, of course it is possible to pack that on top of the DNS and build tricky algorithms into the DNS response generation (Akamai and all the DNS-based load-balancer vendors have been doing that for years), but given the potentially large set of background information the server needs in order to run its algorithm (which has to be included in the query) plus the need to return a more complex answer than just a URI make the DNS a bad choice for the query protocol. LDAP is only a marginally better choice. It, too, is a "give me the information you have which matches XYZ"-protocol and not a "I have a customer request with these parameters, please tell me what to do" kind of protocol. /ol -- // Otmar Lendl , T: +43 1 5056416 - 33, F: - 933 // nic.at Internet Verwaltungs- und Betriebsgesellschaft m.b.H // http://www.nic.at/ LG Salzburg, FN 172568b, Sitz: Salzburg _______________________________________________ enum mailing list enum@ietf.org https://www1.ietf.org/mailman/listinfo/enum From enum-bounces@ietf.org Fri Jan 04 10:56:16 2008 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1JAots-0006IE-OJ; Fri, 04 Jan 2008 10:56:00 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1JAotr-000661-9Z for enum@ietf.org; Fri, 04 Jan 2008 10:55:59 -0500 Received: from hlid.ogud.com ([66.92.146.160] helo=ogud.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1JAotq-0006ly-Ry for enum@ietf.org; Fri, 04 Jan 2008 10:55:59 -0500 Received: from [192.168.1.104] (hlid.ogud.com [66.92.146.160]) by ogud.com (8.13.1/8.13.1) with ESMTP id m04FtnaA064292; Fri, 4 Jan 2008 10:55:50 -0500 (EST) (envelope-from Ed.Lewis@neustar.biz) Mime-Version: 1.0 Message-Id: Date: Fri, 4 Jan 2008 10:55:46 -0500 To: enum@ietf.org From: Edward Lewis Content-Type: text/plain; charset="us-ascii" ; format="flowed" X-Scanned-By: MIMEDefang 2.63 on 66.92.146.160 X-Spam-Score: -0.0 (/) X-Scan-Signature: ea4ac80f790299f943f0a53be7e1a21a Cc: ed.lewis@neustar.biz Subject: [Enum] enum services registry question X-BeenThere: enum@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Enum Discussion List List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: enum-bounces@ietf.org On http://www.iana.org/assignments/enum-services, most/some/recent entries lack an explicit reference to an RFC for the definition. All have some reference, the early ones (pre-RFC 4002) IANA (or someone) put in an RFC tag at the end of the registration record but in the later ones the reference is more oblique, such as this: # Enumservice Name: "XMPP" # Enumservice Type: "xmpp" # Enumservice Subtype: n/a # URI Schemes: "xmpp" # Functional Specification: # This Enumservice indicates that the resource identified is an XMPP # entity. # Security Considerations: see Section 6 of [RFC4979] # Intended Usage: COMMON # Author: (don't want to make it seem I'm picking on just this entry ;)) The only reference to an RFC here and in others is in the Security Considerations. I'd suggest that registrants make an explicit statement in the functional specification area indicating the RFC (number available when published of course) with the full specification. -- -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Edward Lewis +1-571-434-5468 NeuStar Think glocally. Act confused. _______________________________________________ enum mailing list enum@ietf.org https://www1.ietf.org/mailman/listinfo/enum From enum-bounces@ietf.org Fri Jan 04 14:40:55 2008 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1JAsPB-0003xi-RT; Fri, 04 Jan 2008 14:40:33 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1JAsPA-0003xH-53 for enum@ietf.org; Fri, 04 Jan 2008 14:40:32 -0500 Received: from medel.switch.ch ([2001:620:0:14:214:4fff:fe75:4774]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1JAsP6-0002jM-Eg for enum@ietf.org; Fri, 04 Jan 2008 14:40:32 -0500 Received: from [130.59.6.129] (helo=machb.switch.ch) by medel.switch.ch with esmtps (TLSv1:AES256-SHA:256) (Exim 4.67) (envelope-from ) id 1JAsP4-0002PA-Mo; Fri, 04 Jan 2008 20:40:26 +0100 Date: Fri, 4 Jan 2008 20:39:41 +0100 (CET) From: Bernie Hoeneisen X-X-Sender: bhoeneis@machb To: Edward Lewis Subject: Re: [Enum] enum services registry question In-Reply-To: Message-ID: References: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-SWITCH-SCANNER: bypassed X-Spam-Score: 0.0 (/) X-Scan-Signature: 7d33c50f3756db14428398e2bdedd581 Cc: enum@ietf.org X-BeenThere: enum@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Enum Discussion List List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: enum-bounces@ietf.org Hi Ed On Fri, 4 Jan 2008, Edward Lewis wrote: > [...] > The only reference to an RFC here and in others is in the Security > Considerations. Intersting catch. We can take this into consideration for the updated IANA Enumservices registration template. > I'd suggest that registrants make an explicit statement in the functional > specification area indicating the RFC (number available when published of > course) with the full specification. There will be additional fun to figure out, how this will work with the new regime (as decided in Vancouver), where an RFC will no longer be required for registering an Enumservice... cheers, Bernie _______________________________________________ enum mailing list enum@ietf.org https://www1.ietf.org/mailman/listinfo/enum From enum-bounces@ietf.org Fri Jan 04 14:46:15 2008 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1JAsUe-0005pK-MA; Fri, 04 Jan 2008 14:46:12 -0500 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1JAsUd-0005nM-8e for enum@ietf.org; Fri, 04 Jan 2008 14:46:11 -0500 Received: from services.erkkila.org ([24.97.94.217] helo=erkkila.org) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1JAsUc-0007oF-H4 for enum@ietf.org; Fri, 04 Jan 2008 14:46:11 -0500 Received: from [10.1.1.25] (t61pee.erkkila.org [::ffff:10.1.1.25]) (AUTH: PLAIN pee@erkkila.org, TLS: TLSv1/SSLv3,256bits,AES256-SHA) by erkkila.org with esmtp; Fri, 04 Jan 2008 19:46:09 +0000 id 001F70E3.477E8D01.00001538 Message-ID: <477E8D01.9040801@erkkila.org> Date: Fri, 04 Jan 2008 14:46:09 -0500 From: Paul Erkkila User-Agent: Thunderbird 2.0.0.9 (X11/20071031) MIME-Version: 1.0 To: Otmar Lendl , Paul Erkkila , Hadriel Kaplan , "enum@ietf.org" , "Robert H. Walter" , "Creighton, Tom" , Raja Gopal Subject: Re: [Enum] New I-D:draft-kaplan-enum-source-uri-00.txt References: <20071212150130.GA14079@nic.at> <475FFD7C.80907@erkkila.org> <20080102222403.GA2792@nic.at> In-Reply-To: <20080102222403.GA2792@nic.at> X-Enigmail-Version: 0.95.5 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 37af5f8fbf6f013c5b771388e24b09e7 Cc: X-BeenThere: enum@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Enum Discussion List List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: enum-bounces@ietf.org Some comments inline to add to the discussion but no real content :). Otmar Lendl wrote: > On 2007/12/12 16:12, Paul Erkkila wrote: >> Otmar Lendl wrote: >>> >>> Yes, the incremental change ist not that big. The question remains: >>> >>> Have we now reached the point where we should stop fiddling with the >>> DNS protocol and should instead look for a directory lookup protocol >>> which was designed from the beginning to support authenticated and >>> complex queries returning structured data? >> LDAP? >> > > I've been mulling over this question during the holidays. I've come > to the following conclusion: (Conclusion 1: That you need more hobbies ;) ) > > The DNS (as well as LDAP) is primarily designed as a directory service. > It is a protocol to query a database for records conforming to a > specific question. The intelligence on how to interpret the data and > what to do with this information (possibly combined with data learned > from other sources) is in the device which asked the query. > > In terms of VoIP: the call routing algorithm runs inside the > soft-switch. ENUM is just one input into this algorithm. I see what you are getting at here (at least I think I do). However I think the term "soft-switch" is overloaded to the point where the argument changes depending on the definition. (If I have an edge device (proxy/other) that is capable of gathering routing and policy information, and using that to make next hop determination does that make it a soft-switch? Or does it have to be a singleton entity for a particular network with state information? Not really an argument for the ENUM group :) ) > > What I see in various proposals here in the WG (starting with the > trunk-ID draft ) and most clearly from this draft is a different > approach to the overall architecture: The soft-switch should be dumb, > all call routing decisions are out-sourced to the ENUM DNS servers. > They do capacity planning, source-dependent routing and all the peering > logic. If you take this approach, then of course the soft-switch needs > to somehow communicate all the basics of that call to the ENUM DNS > server so that it can make the correct call routing decision. I'm not confident this is exactly what is going on but it is certainly a valid view of the data. One possibility is what we are seeing is the natural bounce between the single "core" routing model and "edge only" routing model, with a good dose of single vs multiple query and single vs multiple route decision per network argument thrown in to confuse things even more. Speaking from experience with a single query and for the most part single routing view VoIP network there is no simple answer, and the sweet spot will be different for every network, and maybe even every different type of flow in that network. This draft is useful in all of these cases when ENUM is used as on of the inputs to the routing decision. It allows the entity doing the ENUM query to be more specific with its query and hopefully get a more specific answer, which should reduce the total amount of global resources used to properly route a particular session. > > Such "out-source the logic" approaches are not new. Network equipment > handling dial-up sessions or DSL logins have been doing that for years. > The protocol of choice for such applications has been RADIUS (perhaps > now supplanted by DIAMETER). RADIUS supports almost arbitrary key-value > pairs in the query: All the information the dumb switch has can thus > be easily packed into the query. The same holds for the answer: it can > instruct the soft-switch in detail what to do with the call. > > --- > > Yes, of course it is possible to pack that on top of the DNS and build > tricky algorithms into the DNS response generation (Akamai and all the > DNS-based load-balancer vendors have been doing that for years), but > given the potentially large set of background information the server > needs in order to run its algorithm (which has to be included in the > query) plus the need to return a more complex answer than just a URI > make the DNS a bad choice for the query protocol. My gut feeling is that there has been a great benefit to communications as a whole from the examples you've picked above even if they are doing things outside of the original intent. (I have not fully digested the comments from Olafur so I'm not sure how they would fit here). It is possible adding these types of extensions to the DNS above the "holy trinity" for a query would benefit other applications as well. Then again it might crush the whole thing ;). > > LDAP is only a marginally better choice. It, too, is a "give me the > information you have which matches XYZ"-protocol and not a "I have a > customer request with these parameters, please tell me what to do" > kind of protocol. > > /ol My only input here is that some of the benefits (delegation/caching) of DNS might be lost with transition to another protocol . In the case of this draft though that might be OK. Since it is aimed at more or less private interconnects there is already a configuration requirement for the DNS servers and the appropriate roots to query. This draft and surrounding discussion have certainly stimulated my thinking about the current state of things as we work on replacements for the pieces of the SS7 network(s). The draft is a step forward in that direction if we assume the replacement will be based around ENUM. -pee _______________________________________________ enum mailing list enum@ietf.org https://www1.ietf.org/mailman/listinfo/enum From enum-bounces@ietf.org Fri Jan 04 14:50:36 2008 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1JAsYr-0001sS-TS; Fri, 04 Jan 2008 14:50:33 -0500 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1JAsYq-0001ig-0f for enum@ietf.org; Fri, 04 Jan 2008 14:50:32 -0500 Received: from hlid.ogud.com ([66.92.146.160] helo=ogud.com) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1JAsYp-0007zh-12 for enum@ietf.org; Fri, 04 Jan 2008 14:50:31 -0500 Received: from [192.168.1.104] (hlid.ogud.com [66.92.146.160]) by ogud.com (8.13.1/8.13.1) with ESMTP id m04JoN6s069234; Fri, 4 Jan 2008 14:50:24 -0500 (EST) (envelope-from Ed.Lewis@neustar.biz) Mime-Version: 1.0 Message-Id: In-Reply-To: References: Date: Fri, 4 Jan 2008 14:50:15 -0500 To: Bernie Hoeneisen From: Edward Lewis Subject: Re: [Enum] enum services registry question Content-Type: text/plain; charset="us-ascii" ; format="flowed" X-Scanned-By: MIMEDefang 2.63 on 66.92.146.160 X-Spam-Score: 0.0 (/) X-Scan-Signature: 7655788c23eb79e336f5f8ba8bce7906 Cc: enum@ietf.org, Edward Lewis X-BeenThere: enum@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Enum Discussion List List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: enum-bounces@ietf.org At 20:39 +0100 1/4/08, Bernie Hoeneisen wrote: >There will be additional fun to figure out, how this will work with the new >regime (as decided in Vancouver), where an RFC will no longer be required >for registering an Enumservice... Heh, well, I'd settle for any kind of reference for the enumservices *and* the URI schemes! Consider this a lesson learned from IANA registrations of DNS parameters. We have some RR types (http://www.iana.org/assignments/dns-parameters) defined only by a human - a name and an email address. It takes a good bit of googling to find any notes stuffed in other, non-IETF, corners of the net-universe to find the specifications. Even having sent fixes to IANA hasn't (completely) rectified the problem of missing documents and broken references. -- -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Edward Lewis +1-571-434-5468 NeuStar Think glocally. Act confused. _______________________________________________ enum mailing list enum@ietf.org https://www1.ietf.org/mailman/listinfo/enum From enum-bounces@ietf.org Mon Jan 07 08:08:16 2008 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1JBri2-0008Dy-Sw; Mon, 07 Jan 2008 08:08:06 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1JBri1-0008CT-4A for enum@ietf.org; Mon, 07 Jan 2008 08:08:05 -0500 Received: from medel.switch.ch ([2001:620:0:14:214:4fff:fe75:4775]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1JBrhy-0005i1-Tp for enum@ietf.org; Mon, 07 Jan 2008 08:08:05 -0500 Received: from [130.59.6.129] (helo=machb.switch.ch) by medel.switch.ch with esmtps (TLSv1:AES256-SHA:256) (Exim 4.67) (envelope-from ) id 1JBrhx-00010V-U6 for enum@ietf.org; Mon, 07 Jan 2008 14:08:01 +0100 Date: Mon, 7 Jan 2008 11:27:37 +0100 (CET) From: Bernie Hoeneisen X-X-Sender: bhoeneis@machb To: Edward Lewis Subject: Re: [Enum] enum services registry question In-Reply-To: Message-ID: References: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed ReSent-Date: Mon, 7 Jan 2008 14:07:02 +0100 (CET) ReSent-From: Bernie Hoeneisen ReSent-To: enum@ietf.org ReSent-Subject: Re: [Enum] enum services registry question ReSent-Message-ID: X-SWITCH-SCANNER: bypassed X-Spam-Score: 0.0 (/) X-Scan-Signature: b280b4db656c3ca28dd62e5e0b03daa8 Cc: enum@ietf.org, narten@us.ibm.com, Harald@Alvestrand.no X-BeenThere: enum@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Enum Discussion List List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: enum-bounces@ietf.org Errors-To: enum-bounces@ietf.org Hi Ed, http://tools.ietf.org/id/draft-narten-iana-considerations-rfc2434bis-08.txt gives some guidance in this (section 4.1.): Specification required - Values and their meaning must be documented in an RFC or other permanent and readily available public specification, in sufficient detail so that interoperability between independent implementations is possible. When used, Specification Required also implies usage of a Designated Expert, who will review the public specification and evaluate whether it is sufficiently clear to allow interoperable implementations. The intention behind "permanent and readily available" is that a document can be reasonably be expected to easily be found long after IANA assignment of the requested value. Publication of an RFC is the ideal means of achieving this requirement. [...] The term "permanent and readily available public specification" states the intension, but I think it is a bit vague, when it comes to what qualifies to this term. Furthermore it does not say much about the change management of such a specification. To be on the safe side, I guess we should ensure that a copy of the specification (as reviewed by expert) is always maintained at IANA, unless there is an RFC (that can be simply referenced). On the other hand, this looks like an issue to be solved on rfc2434bis level. (I therefore have CC:ed the authors of rfc2434bis to this email.) Propsosal: Unless there is some better solution proposed, I'll put a section "reference" to the new IANA template in draft-ietf-enum-enumservices-guide. There can be either a reference to the RFC or an IANA internal reference to the version of the specification after approval by the experts. Makes sense? cheers, Bernie PS: It would be quite a bit easier, if we decided on "RFC required" instead...;-) On Fri, 4 Jan 2008, Edward Lewis wrote: > At 20:39 +0100 1/4/08, Bernie Hoeneisen wrote: > >> There will be additional fun to figure out, how this will work with the new >> regime (as decided in Vancouver), where an RFC will no longer be required >> for registering an Enumservice... > > Heh, well, I'd settle for any kind of reference for the enumservices *and* > the URI schemes! > > Consider this a lesson learned from IANA registrations of DNS parameters. We > have some RR types (http://www.iana.org/assignments/dns-parameters) defined > only by a human - a name and an email address. It takes a good bit of > googling to find any notes stuffed in other, non-IETF, corners of the > net-universe to find the specifications. Even having sent fixes to IANA > hasn't (completely) rectified the problem of missing documents and broken > references. > -- > -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- > Edward Lewis +1-571-434-5468 > NeuStar > > Think glocally. Act confused. > > _______________________________________________ > enum mailing list > enum@ietf.org > https://www1.ietf.org/mailman/listinfo/enum > _______________________________________________ enum mailing list enum@ietf.org https://www1.ietf.org/mailman/listinfo/enum From enum-bounces@ietf.org Mon Jan 07 08:13:50 2008 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1JBrnX-0002Lm-8j; Mon, 07 Jan 2008 08:13:47 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1JBpDd-0000p7-7F for enum@ietf.org; Mon, 07 Jan 2008 05:28:34 -0500 Received: from medel.switch.ch ([2001:620:0:14:214:4fff:fe75:4774]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1JBpDa-0002Gi-On for enum@ietf.org; Mon, 07 Jan 2008 05:28:33 -0500 Received: from [130.59.6.129] (helo=machb.switch.ch) by medel.switch.ch with esmtps (TLSv1:AES256-SHA:256) (Exim 4.67) (envelope-from ) id 1JBpDY-0006LZ-RQ; Mon, 07 Jan 2008 11:28:28 +0100 Date: Mon, 7 Jan 2008 11:27:37 +0100 (CET) From: Bernie Hoeneisen X-X-Sender: bhoeneis@machb To: Edward Lewis Subject: Re: [Enum] enum services registry question In-Reply-To: Message-ID: References: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-SWITCH-SCANNER: bypassed X-Spam-Score: 0.0 (/) X-Scan-Signature: b280b4db656c3ca28dd62e5e0b03daa8 X-Mailman-Approved-At: Mon, 07 Jan 2008 08:13:46 -0500 Cc: enum@ietf.org, narten@us.ibm.com, Harald@Alvestrand.no X-BeenThere: enum@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Enum Discussion List List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: enum-bounces@ietf.org Hi Ed, http://tools.ietf.org/id/draft-narten-iana-considerations-rfc2434bis-08.txt gives some guidance in this (section 4.1.): Specification required - Values and their meaning must be documented in an RFC or other permanent and readily available public specification, in sufficient detail so that interoperability between independent implementations is possible. When used, Specification Required also implies usage of a Designated Expert, who will review the public specification and evaluate whether it is sufficiently clear to allow interoperable implementations. The intention behind "permanent and readily available" is that a document can be reasonably be expected to easily be found long after IANA assignment of the requested value. Publication of an RFC is the ideal means of achieving this requirement. [...] The term "permanent and readily available public specification" states the intension, but I think it is a bit vague, when it comes to what qualifies to this term. Furthermore it does not say much about the change management of such a specification. To be on the safe side, I guess we should ensure that a copy of the specification (as reviewed by expert) is always maintained at IANA, unless there is an RFC (that can be simply referenced). On the other hand, this looks like an issue to be solved on rfc2434bis level. (I therefore have CC:ed the authors of rfc2434bis to this email.) Propsosal: Unless there is some better solution proposed, I'll put a section "reference" to the new IANA template in draft-ietf-enum-enumservices-guide. There can be either a reference to the RFC or an IANA internal reference to the version of the specification after approval by the experts. Makes sense? cheers, Bernie PS: It would be quite a bit easier, if we decided on "RFC required" instead...;-) On Fri, 4 Jan 2008, Edward Lewis wrote: > At 20:39 +0100 1/4/08, Bernie Hoeneisen wrote: > >> There will be additional fun to figure out, how this will work with the new >> regime (as decided in Vancouver), where an RFC will no longer be required >> for registering an Enumservice... > > Heh, well, I'd settle for any kind of reference for the enumservices *and* > the URI schemes! > > Consider this a lesson learned from IANA registrations of DNS parameters. We > have some RR types (http://www.iana.org/assignments/dns-parameters) defined > only by a human - a name and an email address. It takes a good bit of > googling to find any notes stuffed in other, non-IETF, corners of the > net-universe to find the specifications. Even having sent fixes to IANA > hasn't (completely) rectified the problem of missing documents and broken > references. > -- > -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- > Edward Lewis +1-571-434-5468 > NeuStar > > Think glocally. Act confused. > > _______________________________________________ > enum mailing list > enum@ietf.org > https://www1.ietf.org/mailman/listinfo/enum > _______________________________________________ enum mailing list enum@ietf.org https://www1.ietf.org/mailman/listinfo/enum From enum-bounces@ietf.org Mon Jan 07 09:00:45 2008 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1JBsWn-00085i-Cd; Mon, 07 Jan 2008 09:00:33 -0500 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1JBsWm-00085d-99 for enum@ietf.org; Mon, 07 Jan 2008 09:00:32 -0500 Received: from hlid.ogud.com ([66.92.146.160] helo=ogud.com) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1JBsWl-00086g-Is for enum@ietf.org; Mon, 07 Jan 2008 09:00:32 -0500 Received: from [192.168.1.104] (hlid.ogud.com [66.92.146.160]) by ogud.com (8.13.1/8.13.1) with ESMTP id m07E0BIa010556; Mon, 7 Jan 2008 09:00:12 -0500 (EST) (envelope-from Ed.Lewis@neustar.biz) Mime-Version: 1.0 Message-Id: In-Reply-To: References: Date: Mon, 7 Jan 2008 08:54:18 -0500 To: Bernie Hoeneisen From: Edward Lewis Subject: Re: [Enum] enum services registry question Content-Type: text/plain; charset="us-ascii" ; format="flowed" X-Spam-Score: 0.0 (/) X-Scan-Signature: 25620135586de10c627e3628c432b04a Cc: enum@ietf.org, narten@us.ibm.com, Edward Lewis , Harald@Alvestrand.no X-BeenThere: enum@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Enum Discussion List List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: enum-bounces@ietf.org At 11:27 +0100 1/7/08, Bernie Hoeneisen wrote: >The term "permanent and readily available public specification" states >the intension, but I think it is a bit vague, when it comes to what >qualifies to this term. Furthermore it does not say much about the change >management of such a specification. > >To be on the safe side, I guess we should ensure that a copy of the >specification (as reviewed by expert) is always maintained at IANA, >unless there is an RFC (that can be simply referenced). This is the specific situation I have run into. There is a DNS RR type - as far as I know no one uses - called ATMA. It was developed and then documented by the ATM Forum. The document was available on the ATM Forum's website. The ATM Forum ceased operations quite a while ago and became part of, hmmm, some other organization whose name now escapes me. Within the last year I exchanged email with members there but after being promised a response to a question about getting the document published under the name of the IETF the "line went dead." So today we have an entry in the DNS RR type registry that has no reliable definition. I haven't gotten permission from the successor organization to copy the document into the RFCs. IANA is not equipped to archive documents so they can't just arrange to host the document - two issues, one is the mechanics and the other is the intellectual property. We are also stuck without the ability to obsolete the registration because no one is willing to declare it dead without knowing who is using it. So far what I've described is just a paperwork and bookkeeping migraine headache. The reason I ever started to look into this was when I was asked to write DNSSEC code separate from any other implementation (in the 90's) and tried to research DNS from the specifications and not "what would BIND do?" When asked if my code handled "all the types" I wanted to be sure of the answer. If you were to build an implementation from scratch, that's when it matters. (I realize I'm not throwing out a solution. This is a reflection of my experience in DNS and why I stopped to make the comment.) >On the other hand, this looks like an issue to be solved on rfc2434bis >level. (I therefore have CC:ed the authors of rfc2434bis to this email.) Do you have a URL for that document? >Propsosal: > > Unless there is some better solution proposed, I'll put a section > "reference" to the new IANA template in > draft-ietf-enum-enumservices-guide. > There can be either a reference to the RFC or an IANA internal reference > to the version of the specification after approval by the experts. > >Makes sense? The issue is the "IANA internal reference" as I mentioned before. >PS: It would be quite a bit easier, if we decided on "RFC required" >instead...;-) It certainly would be easier, but that means the RFC-Editor and IETF are creating a monopoly on what goes into IANA. I believe that is undesired by the powers that be. (I think the same was said in the DNS group talking about their IANA instructions "bis" document.) -- -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Edward Lewis +1-571-434-5468 NeuStar Think glocally. Act confused. _______________________________________________ enum mailing list enum@ietf.org https://www1.ietf.org/mailman/listinfo/enum From enum-bounces@ietf.org Mon Jan 07 10:16:23 2008 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1JBti1-0002cB-S0; Mon, 07 Jan 2008 10:16:13 -0500 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1JBti0-0002c4-76 for enum@ietf.org; Mon, 07 Jan 2008 10:16:12 -0500 Received: from hlid.ogud.com ([66.92.146.160] helo=ogud.com) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1JBthz-0001RO-Q7 for enum@ietf.org; Mon, 07 Jan 2008 10:16:12 -0500 Received: from [192.168.1.104] (hlid.ogud.com [66.92.146.160]) by ogud.com (8.13.1/8.13.1) with ESMTP id m07FFx62011123; Mon, 7 Jan 2008 10:16:01 -0500 (EST) (envelope-from Ed.Lewis@neustar.biz) Mime-Version: 1.0 Message-Id: In-Reply-To: <33A24DCD2DC32148AD9C2C3298CB037A017088C3@FHDP1CCMXCV02.us.one.verizon.com > References: <092B2658AAB56A4D80836399A4C4703102E04C19@ASHEVS002.mcilink.com> <33A24DCD2DC32148AD9C2C3298CB037A017088C3@FHDP1CCMXCV02.us.one.verizon.com > Date: Mon, 7 Jan 2008 10:15:56 -0500 To: From: Edward Lewis Content-Type: text/plain; charset="us-ascii" ; format="flowed" X-Scanned-By: MIMEDefang 2.63 on 66.92.146.160 X-Spam-Score: 0.0 (/) X-Scan-Signature: 79899194edc4f33a41f49410777972f8 Cc: narten@us.ibm.com, enum@ietf.org, Ed.Lewis@neustar.biz, Harald@Alvestrand.no, bernie.hoeneisen@switch.ch, andrew.g.malis@verizon.com, timothy.dwight@verizon.com Subject: [Enum] RE: ATM/Frame Relay/MPLS Forum (L2 Forum?) issue X-BeenThere: enum@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Enum Discussion List List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: enum-bounces@ietf.org (For the sake of closure of the story on the ENUM list.) Thanks. Now I'll go huddle with the IANA folks. At 10:02 -0500 1/7/08, wrote: ... >Ed, > >The IP/MPLS Forum is now the permanent online repository for the ATM >Forum specifications. There is no problem with IANA downloading the >document and making it publicly available in perpetuity if they so >choose - just have them let me know by email if they end up doing so. >Does this work for you (or for them)? -- -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Edward Lewis +1-571-434-5468 NeuStar Think glocally. Act confused. _______________________________________________ enum mailing list enum@ietf.org https://www1.ietf.org/mailman/listinfo/enum From enum-bounces@ietf.org Mon Jan 07 14:10:09 2008 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1JBxMJ-0006Bq-Bv; Mon, 07 Jan 2008 14:10:03 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1JBxMI-0006Bk-4i for enum@ietf.org; Mon, 07 Jan 2008 14:10:02 -0500 Received: from hlid.ogud.com ([66.92.146.160] helo=ogud.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1JBxMH-0006kH-N7 for enum@ietf.org; Mon, 07 Jan 2008 14:10:02 -0500 Received: from [192.168.1.104] (hlid.ogud.com [66.92.146.160]) by ogud.com (8.13.1/8.13.1) with ESMTP id m07J9nGq013083; Mon, 7 Jan 2008 14:09:51 -0500 (EST) (envelope-from Ed.Lewis@neustar.biz) Mime-Version: 1.0 Message-Id: In-Reply-To: References: Date: Mon, 7 Jan 2008 14:09:45 -0500 To: Bernie Hoeneisen From: Edward Lewis Subject: Re: [Enum] enum services registry question Content-Type: text/plain; charset="us-ascii" ; format="flowed" X-Scanned-By: MIMEDefang 2.63 on 66.92.146.160 X-Spam-Score: -0.0 (/) X-Scan-Signature: ffa9dfbbe7cc58b3fa6b8ae3e57b0aa3 Cc: enum@ietf.org, narten@us.ibm.com, Edward Lewis , Harald@Alvestrand.no X-BeenThere: enum@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Enum Discussion List List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: enum-bounces@ietf.org At 19:27 +0100 1/7/08, Bernie Hoeneisen wrote: >(BTW: This URL was already in my last email....) And yet somehow I missed it. Maybe I slept through reading the start of the message. ;) >I don't think it is impossible to convince IANA to maintain such a document >base. However, this certainly needs to be discussed with IANA and the >authors of rfc2434bis. We will see, that other document I talked about will be a test case (for me). >I do not see a monopoly issue here. AFAIK everybody can publish an >informational RFC as an individual submission and I do not see a valid >reason for the RFC editor to object an Enumservice registration document. >Or do I miss anything here? Not everyone is willing to brave the slings and arrows of the IETF process. -- -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Edward Lewis +1-571-434-5468 NeuStar Think glocally. Act confused. _______________________________________________ enum mailing list enum@ietf.org https://www1.ietf.org/mailman/listinfo/enum From enum-bounces@ietf.org Mon Jan 07 14:32:25 2008 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1JBxhw-0000LM-IO; Mon, 07 Jan 2008 14:32:24 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1JBxhv-0000L4-7b for enum@ietf.org; Mon, 07 Jan 2008 14:32:23 -0500 Received: from medel.switch.ch ([2001:620:0:14:214:4fff:fe75:4775]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1JBxhs-0007C3-BG for enum@ietf.org; Mon, 07 Jan 2008 14:32:23 -0500 Received: from [130.59.6.129] (helo=machb.switch.ch) by medel.switch.ch with esmtps (TLSv1:AES256-SHA:256) (Exim 4.67) (envelope-from ) id 1JBxhr-0001vJ-Bo for enum@ietf.org; Mon, 07 Jan 2008 20:32:19 +0100 Date: Mon, 7 Jan 2008 19:27:40 +0100 (CET) From: Bernie Hoeneisen X-X-Sender: bhoeneis@machb To: Edward Lewis Subject: Re: [Enum] enum services registry question In-Reply-To: Message-ID: References: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed ReSent-Date: Mon, 7 Jan 2008 20:31:15 +0100 (CET) ReSent-From: Bernie Hoeneisen ReSent-To: enum@ietf.org ReSent-Subject: Re: [Enum] enum services registry question ReSent-Message-ID: X-SWITCH-SCANNER: bypassed X-Spam-Score: 0.0 (/) X-Scan-Signature: a7d6aff76b15f3f56fcb94490e1052e4 Cc: enum@ietf.org, narten@us.ibm.com, Harald@Alvestrand.no X-BeenThere: enum@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Enum Discussion List List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: enum-bounces@ietf.org Errors-To: enum-bounces@ietf.org Hi Ed, On Mon, 7 Jan 2008, Edward Lewis wrote: > At 11:27 +0100 1/7/08, Bernie Hoeneisen wrote: >> On the other hand, this looks like an issue to be solved on rfc2434bis >> level. (I therefore have CC:ed the authors of rfc2434bis to this email.) > > Do you have a URL for that document? http://tools.ietf.org/id/draft-narten-iana-considerations-rfc2434bis-08.txt (BTW: This URL was already in my last email....) >> Propsosal: >> >> Unless there is some better solution proposed, I'll put a section >> "reference" to the new IANA template in >> draft-ietf-enum-enumservices-guide. >> There can be either a reference to the RFC or an IANA internal reference >> to the version of the specification after approval by the experts. > > The issue is the "IANA internal reference" as I mentioned before. I don't think it is impossible to convince IANA to maintain such a document base. However, this certainly needs to be discussed with IANA and the authors of rfc2434bis. >> PS: It would be quite a bit easier, if we decided on "RFC required" >> instead...;-) > > It certainly would be easier, but that means the RFC-Editor and IETF are > creating a monopoly on what goes into IANA. I believe that is undesired by > the powers that be. (I think the same was said in the DNS group talking > about their IANA instructions "bis" document.) I do not see a monopoly issue here. AFAIK everybody can publish an informational RFC as an individual submission and I do not see a valid reason for the RFC editor to object an Enumservice registration document. Or do I miss anything here? cheers, Bernie _______________________________________________ enum mailing list enum@ietf.org https://www1.ietf.org/mailman/listinfo/enum From enum-bounces@ietf.org Mon Jan 07 16:17:09 2008 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1JBzL1-0007ZA-DY; Mon, 07 Jan 2008 16:16:51 -0500 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1JBzL0-0007Z2-Vq for enum@ietf.org; Mon, 07 Jan 2008 16:16:51 -0500 Received: from hlid.ogud.com ([66.92.146.160] helo=ogud.com) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1JBzL0-0007TA-A9 for enum@ietf.org; Mon, 07 Jan 2008 16:16:50 -0500 Received: from [192.168.1.104] (hlid.ogud.com [66.92.146.160]) by ogud.com (8.13.1/8.13.1) with ESMTP id m07LGW3a013942; Mon, 7 Jan 2008 16:16:33 -0500 (EST) (envelope-from Ed.Lewis@neustar.biz) Mime-Version: 1.0 Message-Id: In-Reply-To: <200801072049.m07Kn9ov025767@cichlid.raleigh.ibm.com> References: <200801072049.m07Kn9ov025767@cichlid.raleigh.ibm.com> Date: Mon, 7 Jan 2008 16:16:06 -0500 To: Thomas Narten , enum@ietf.org From: Edward Lewis Subject: Re: [Enum] enum services registry question Content-Type: text/plain; charset="us-ascii" ; format="flowed" X-Spam-Score: 0.0 (/) X-Scan-Signature: 41c17b4b16d1eedaa8395c26e9a251c4 Cc: Edward Lewis , Bernie Hoeneisen , Harald@Alvestrand.no X-BeenThere: enum@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Enum Discussion List List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: enum-bounces@ietf.org (If you want to skip my embellishment of the DNS case, here's the last paragraph, which relates back to ENUM.) The goal is to be able to look at IANA for parameters and then find definitions of each via resolvable references. For ENUM, a reference to an RFC (if that is the vehicle) ought to be explicit. If it is another document, a fully fledged reference (not just a URL) is helpful. And if it matters over the long haul, there should be someone making sure the registrations are up to date. At 15:49 -0500 1/7/08, Thomas Narten wrote: >And we should only do this if we are worried that a >particular document is important and might "go away" at some point in >the future. Is the document in question of this type? In the situation I have described, the document has not been changing, is not in danger of being retired, and has been and continues to be publicly available. The problem has been that the entry in the IANA registry has never pointed to the document nor has the entry been tracking the transfer of the document from one organization to another. It's not the document, it's the static nature of the registration that is the issue. The desire to have IANA only refer to RFCs lies in the shared fates of the IETF and IANA. If one goes down, the other certainly will know about it. Other organizations are capable of accomplishing what the IETF does (specifically here putting documents in public spaces for perpetuity) but there may or may not be enough cross-activity to maintain the registration. I should add, specific to my case, it's not a matter of the URL changing. The IANA registration doesn't even have the title of the document, only the personal name of the author and the email address I suppose the request came in on. I had to track the document down by googling his name to find current employment, topic, etc., etc., and then maintain this searching over the years of while trying to get IANA to retain the information. Even now, IANA still doesn't publish any more than the person's name and a defunct email address - despite my sending them notes on this. Sorry to go on - this isn't an ENUM issue, but it is my experience with protocol parameter registries when the rules are not tight enough. What would fix the case I am drawing upon is either mirroring all needed documents, maintaining liveness on all references (and at least have titles!), and or the ability to mark a registration as "historic" if there is no published reference publicly available. (Really, I don't hold grudges or anything - I just don't want to see the same problem pop up with ENUM.) BTW, the same DNS RR registry has other problematic registration references in which the issue isn't cross-organization. There are a few that are defined by retired internet drafts retrievable from those who maintain such things on their own. The goal is to be able to look at IANA for parameters and then find definitions of each via resolvable references. For ENUM, a reference to an RFC (if that is the vehicle) ought to be explicit. If it is another document, a fully fledged reference (not just a URL) is helpful. And if it matters over the long haul, there should be someone making sure the registrations are up to date. -- -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Edward Lewis +1-571-434-5468 NeuStar Think glocally. Act confused. _______________________________________________ enum mailing list enum@ietf.org https://www1.ietf.org/mailman/listinfo/enum From enum-bounces@ietf.org Mon Jan 07 20:27:42 2008 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1JC3Fc-0006sk-3j; Mon, 07 Jan 2008 20:27:32 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1JBtVk-0002M6-4i for enum@ietf.org; Mon, 07 Jan 2008 10:03:32 -0500 Received: from sacmail4.verizon.com ([192.76.84.42]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1JBtVg-0007WS-JB for enum@ietf.org; Mon, 07 Jan 2008 10:03:32 -0500 Received: from smtpftw3.verizon.com (smtpftw3.verizon.com [138.83.140.92]) by sacmail4.verizon.com (8.13.7+Sun/8.13.3) with ESMTP id m07F33Tp003875; Mon, 7 Jan 2008 10:03:03 -0500 (EST) Received: from ftwintrmemf2.verizon.com (ftwintrmemf2.verizon.com [138.83.131.184]) by smtpftw3.verizon.com (8.13.3/8.13.3) with ESMTP id m07F33du020339; Mon, 7 Jan 2008 10:03:03 -0500 (EST) Received: from ftwintrmemf2.verizon.com (unknown [127.0.0.1]) by ftwintrmemf2.verizon.com (Symantec Mail Security) with ESMTP id 09A5D528002; Mon, 7 Jan 2008 10:03:03 -0500 (EST) X-AuditID: 8a5383b8-afb06bb000000632-01-47823f26f839 Received: from coregate2.verizon.com (unknown [138.83.34.48]) by ftwintrmemf2.verizon.com (EMF) with ESMTP id 513804E4005; Mon, 7 Jan 2008 10:03:02 -0500 (EST) Received: from FHDP1CCMXCG02.us.one.verizon.com ([166.68.240.34]) by coregate2.verizon.com (8.13.3/8.13.3) with ESMTP id m07F2ft3007936; Mon, 7 Jan 2008 09:02:59 -0600 (CST) Received: from FHDP1CCMXCV02.us.one.verizon.com ([166.68.240.12]) by FHDP1CCMXCG02.us.one.verizon.com with Microsoft SMTPSVC(6.0.3790.3959); Mon, 7 Jan 2008 10:02:56 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Mon, 7 Jan 2008 10:02:53 -0500 Message-ID: <33A24DCD2DC32148AD9C2C3298CB037A017088C3@FHDP1CCMXCV02.us.one.verizon.com> In-Reply-To: <092B2658AAB56A4D80836399A4C4703102E04C19@ASHEVS002.mcilink.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: ATM/Frame Relay/MPLS Forum (L2 Forum?) issue thread-index: AchRNb1m2+WAHZ/NRUec1b4I4lUigwAAiF4AAAC2GMA= References: <092B2658AAB56A4D80836399A4C4703102E04C19@ASHEVS002.mcilink.com> From: To: , X-OriginalArrivalTime: 07 Jan 2008 15:02:56.0254 (UTC) FILETIME=[628191E0:01C8513E] X-Brightmail-Tracker: AAAAAA== X-Spam-Score: 0.0 (/) X-Scan-Signature: 7da5a831c477fb6ef97f379a05fb683c X-Mailman-Approved-At: Mon, 07 Jan 2008 20:27:31 -0500 Cc: narten@us.ibm.com, Harald@Alvestrand.no, bernie.hoeneisen@switch.ch, andrew.g.malis@verizon.com, enum@ietf.org Subject: [Enum] RE: ATM/Frame Relay/MPLS Forum (L2 Forum?) issue X-BeenThere: enum@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Enum Discussion List List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: enum-bounces@ietf.org Sorry for the resend - Outlook screwed up Ed's email address on my first try. - Andy Tim, Thanks for forwarding Ed's email. The document discussed below is publicly available at http://www.ipmplsforum.org/ftp/pub/approved-specs/af-dans-0152.000.pdf . Ed, The IP/MPLS Forum is now the permanent online repository for the ATM Forum specifications. There is no problem with IANA downloading the document and making it publicly available in perpetuity if they so choose - just have them let me know by email if they end up doing so. Does this work for you (or for them)? I do not anticipate any further changes to this specification, which was published in July 2000. Please let me know if I can be of any further assistance. Cheers, Andy Malis ChaFrom enum-bounces@ietf.org Mon Jan 07 20:27:42 2008 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1JC3Fc-0006sk-3j; Mon, 07 Jan 2008 20:27:32 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1JBtVk-0002M6-4i for enum@ietf.org; Mon, 07 Jan 2008 10:03:32 -0500 Received: from sacmail4.verizon.com ([192.76.84.42]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1JBtVg-0007WS-JB for enum@ietf.org; Mon, 07 Jan 2008 10:03:32 -0500 Received: from smtpftw3.verizon.com (smtpftw3.verizon.com [138.83.140.92]) by sacmail4.verizon.com (8.13.7+Sun/8.13.3) with ESMTP id m07F33Tp003875; Mon, 7 Jan 2008 10:03:03 -0500 (EST) Received: from ftwintrmemf2.verizon.com (ftwintrmemf2.verizon.com [138.83.131.184]) by smtpftw3.verizon.com (8.13.3/8.13.3) with ESMTP id m07F33du020339; Mon, 7 Jan 2008 10:03:03 -0500 (EST) Received: from ftwintrmemf2.verizon.com (unknown [127.0.0.1]) by ftwintrmemf2.verizon.com (Symantec Mail Security) with ESMTP id 09A5D528002; Mon, 7 Jan 2008 10:03:03 -0500 (EST) X-AuditID: 8a5383b8-afb06bb000000632-01-47823f26f839 Received: from coregate2.verizon.com (unknown [138.83.34.48]) by ftwintrmemf2.verizon.com (EMF) with ESMTP id 513804E4005; Mon, 7 Jan 2008 10:03:02 -0500 (EST) Received: from FHDP1CCMXCG02.us.one.verizon.com ([166.68.240.34]) by coregate2.verizon.com (8.13.3/8.13.3) with ESMTP id m07F2ft3007936; Mon, 7 Jan 2008 09:02:59 -0600 (CST) Received: from FHDP1CCMXCV02.us.one.verizon.com ([166.68.240.12]) by FHDP1CCMXCG02.us.one.verizon.com with Microsoft SMTPSVC(6.0.3790.3959); Mon, 7 Jan 2008 10:02:56 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Mon, 7 Jan 2008 10:02:53 -0500 Message-ID: <33A24DCD2DC32148AD9C2C3298CB037A017088C3@FHDP1CCMXCV02.us.one.verizon.com> In-Reply-To: <092B2658AAB56A4D80836399A4C4703102E04C19@ASHEVS002.mcilink.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: ATM/Frame Relay/MPLS Forum (L2 Forum?) issue thread-index: AchRNb1m2+WAHZ/NRUec1b4I4lUigwAAiF4AAAC2GMA= References: <092B2658AAB56A4D80836399A4C4703102E04C19@ASHEVS002.mcilink.com> From: To: , X-OriginalArrivalTime: 07 Jan 2008 15:02:56.0254 (UTC) FILETIME=[628191E0:01C8513E] X-Brightmail-Tracker: AAAAAA== X-Spam-Score: 0.0 (/) X-Scan-Signature: 7da5a831c477fb6ef97f379a05fb683c X-Mailman-Approved-At: Mon, 07 Jan 2008 20:27:31 -0500 Cc: narten@us.ibm.com, Harald@Alvestrand.no, bernie.hoeneisen@switch.ch, andrew.g.malis@verizon.com, enum@ietf.org Subject: [Enum] RE: ATM/Frame Relay/MPLS Forum (L2 Forum?) issue X-BeenThere: enum@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Enum Discussion List List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: enum-bounces@ietf.org Sorry for the resend - Outlook screwed up Ed's email address on my first try. - Andy Tim, Thanks for forwarding Ed's email. The document discussed below is publicly available at http://www.ipmplsforum.org/ftp/pub/approved-specs/af-dans-0152.000.pdf . Ed, The IP/MPLS Forum is now the permanent online repository for the ATM Forum specifications. There is no problem with IANA downloading the document and making it publicly available in perpetuity if they so choose - just have them let me know by email if they end up doing so. Does this work for you (or for them)? I do not anticipate any further changes to this specification, which was published in July 2000. Please let me know if I can be of any further assistance. Cheers, Andy Malis Chair and President, IP/MPLS Forum www.ipmplsforum.org -----Original Message----- From: Dwight, Timothy M (Tim) [mailto:timothy.dwight@verizonbusiness.com]=20 Sent: Monday, January 07, 2008 9:18 AM To: Malis, Andrew G. (Andy) Subject: ATM/Frame Relay/MPLS Forum (L2 Forum?) issue Andy, Looks like there's an issue with making one of the old ATM Forum specifications (for a type of DNS resource record) publicly available. Can you help Ed out? Tim -----Original Message----- From: Edward Lewis [mailto:Ed.Lewis@neustar.biz]=20 Sent: Monday, January 07, 2008 7:54 AM To: Bernie Hoeneisen Cc: enum@ietf.org; narten@us.ibm.com; Edward Lewis; Harald@Alvestrand.no Subject: Re: [Enum] enum services registry question At 11:27 +0100 1/7/08, Bernie Hoeneisen wrote: >The term "permanent and readily available public specification" states >the intension, but I think it is a bit vague, when it comes to what >qualifies to this term. Furthermore it does not say much about the change >management of such a specification. > >To be on the safe side, I guess we should ensure that a copy of the >specification (as reviewed by expert) is always maintained at IANA, >unless there is an RFC (that can be simply referenced). This is the specific situation I have run into. There is a DNS RR=20 type - as far as I know no one uses - called ATMA. It was developed=20 and then documented by the ATM Forum. The document was available on=20 the ATM Forum's website. The ATM Forum ceased operations quite a while ago and became part of,=20 hmmm, some other organization whose name now escapes me. Within the=20 last year I exchanged email with members there but after being=20 promised a response to a question about getting the document=20 published under the name of the IETF the "line went dead." So today we have an entry in the DNS RR type registry that has no=20 reliable definition. I haven't gotten permission from the successor=20 organization to copy the document into the RFCs. IANA is not=20 equipped to archive documents so they can't just arrange to host the=20 document - two issues, one is the mechanics and the other is the=20 intellectual property. We are also stuck without the ability to=20 obsolete the registration because no one is willing to declare it=20 dead without knowing who is using it. So far what I've described is just a paperwork and bookkeeping=20 migraine headache. The reason I ever started to look into this was=20 when I was asked to write DNSSEC code separate from any other=20 implementation (in the 90's) and tried to research DNS from the=20 specifications and not "what would BIND do?" When asked if my code=20 handled "all the types" I wanted to be sure of the answer. If you were to build an implementation from scratch, that's when it matters. (I realize I'm not throwing out a solution. This is a reflection of=20 my experience in DNS and why I stopped to make the comment.) >On the other hand, this looks like an issue to be solved on rfc2434bis >level. (I therefore have CC:ed the authors of rfc2434bis to this email.) Do you have a URL for that document? >Propsosal: > > Unless there is some better solution proposed, I'll put a section > "reference" to the new IANA template in > draft-ietf-enum-enumservices-guide. > There can be either a reference to the RFC or an IANA internal reference > to the version of the specification after approval by the experts. > >Makes sense? The issue is the "IANA internal reference" as I mentioned before. >PS: It would be quite a bit easier, if we decided on "RFC required" >instead...;-) It certainly would be easier, but that means the RFC-Editor and IETF=20 are creating a monopoly on what goes into IANA. I believe that is=20 undesired by the powers that be. (I think the same was said in the=20 DNS group talking about their IANA instructions "bis" document.) --=20 -=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-= =3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D -=3D- Edward Lewis +1-571-434-5468 NeuStar Think glocally. Act confused. _ir and President, IP/MPLS Forum www.ipmplsforum.org -----Original Message----- From: Dwight, Timothy M (Tim) [mailto:timothy.dwight@verizonbusiness.com]=20 Sent: Monday, January 07, 2008 9:18 AM To: Malis, Andrew G. (Andy) Subject: ATM/Frame Relay/MPLS Forum (L2 Forum?) issue Andy, Looks like there's an issue with making one of the old ATM Forum specifications (for a type of DNS resource record) publicly available. Can you help Ed out? Tim -----Original Message----- From: Edward Lewis [mailto:Ed.Lewis@neustar.biz]=20 Sent: Monday, January 07, 2008 7:54 AM To: Bernie Hoeneisen Cc: enum@ietf.org; narten@us.ibm.com; Edward Lewis; Harald@Alvestrand.no Subject: Re: [Enum] enum services registry question At 11:27 +0100 1/7/08, Bernie Hoeneisen wrote: >The term "permanent and readily available public specification" states >the intension, but I think it is a bit vague, when it comes to what >qualifies to this term. Furthermore it does not say much about the change >management of such a specification. > >To be on the safe side, I guess we should ensure that a copy of the >specification (as reviewed by expert) is always maintained at IANA, >unless there is an RFC (that can be simply referenced). This is the specific situation I have run into. There is a DNS RR=20 type - as far as I know no one uses - called ATMA. It was developed=20 and then documented by the ATM Forum. The document was available on=20 the ATM Forum's website. The ATM Forum ceased operations quite a while ago and became part of,=20 hmmm, some other organization whose name now escapes me. Within the=20 last year I exchanged email with members there but after being=20 promised a response to a question about getting the document=20 published under the name of the IETF the "line went dead." So today we have an entry in the DNS RR type registry that has no=20 reliable definition. I haven't gotten permission from the successor=20 organization to copy the document into the RFCs. IANA is not=20 equipped to archive documents so they can't just arrange to host the=20 document - two issues, one is the mechanics and the other is the=20 intellectual property. We are also stuck without the ability to=20 obsolete the registration because no one is willing to declare it=20 dead without knowing who is using it. So far what I've described is just a paperwork and bookkeeping=20 migraine headache. The reason I ever started to look into this was=20 when I was asked to write DNSSEC code separate from any other=20 implementation (in the 90's) and tried to research DNS from the=20 specifications and not "what would BIND do?" When asked if my code=20 handled "all the types" I wanted to be sure of the answer. If you were to build an implementation from scratch, that's when it matters. (I realize I'm not throwing out a solution. This is a reflection of=20 my experience in DNS and why I stopped to make the comment.) >On the other hand, this looks like an issue to be solved on rfc2434bis >level. (I therefore have CC:ed the authors of rfc2434bis to this email.) Do you have a URL for that document? >Propsosal: > > Unless there is some better solution proposed, I'll put a section > "reference" to the new IANA template in > draft-ietf-enum-enumservices-guide. > There can be either a reference to the RFC or an IANA internal reference > to the version of the specification after approval by the experts. > >Makes sense? The issue is the "IANA internal reference" as I mentioned before. >PS: It would be quite a bit easier, if we decided on "RFC required" >instead...;-) It certainly would be easier, but that means the RFC-Editor and IETF=20 are creating a monopoly on what goes into IANA. I believe that is=20 undesired by the powers that be. (I think the same was said in the=20 DNS group talking about their IANA instructions "bis" document.) --=20 -=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-= =3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D -=3D- Edward Lewis +1-571-434-5468 NeuStar Think glocally. Act confused. _______________________________________________ enum mailing list enum@ietf.org https://www1.ietf.org/mailman/listinfo/enum _______________________________________________ enum mailing list enum@ietf.org https://www1.ietf.org/mailman/listinfo/enum From enum-bounces@ietf.org Mon Jan 07 20:27:42 2008 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1JC3Fb-0006sf-SC; Mon, 07 Jan 2008 20:27:31 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1JBtRL-00080r-JA for enum@ietf.org; Mon, 07 Jan 2008 09:58:59 -0500 Received: from sacmail2.verizon.com ([192.76.84.41]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1JBtRK-0007S6-OQ for enum@ietf.org; Mon, 07 Jan 2008 09:58:59 -0500 Received: from smtpftw3.verizon.com (smtpftw3.verizon.com [138.83.140.92]) by sacmail2.verizon.com (8.13.7+Sun/8.13.3) with ESMTP id m07EwlNa012595; Mon, 7 Jan 2008 09:58:47 -0500 (EST) Received: from tpaintrmemf3.verizon.com (tpaintrmemf3.verizon.com [138.83.67.58]) by smtpftw3.verizon.com (8.13.3/8.13.3) with ESMTP id m07EwkTZ012141; Mon, 7 Jan 2008 09:58:46 -0500 (EST) Received: from tpaintrmemf3.verizon.com (unknown [127.0.0.1]) by tpaintrmemf3.verizon.com (Symantec Mail Security) with ESMTP id EB121528004; Mon, 7 Jan 2008 09:58:45 -0500 (EST) X-AuditID: 8a53433a-adb81bb000000944-30-47823e256f23 Received: from coregate1.verizon.com (unknown [138.83.34.22]) by tpaintrmemf3.verizon.com (EMF) with ESMTP id BD9794E400A; Mon, 7 Jan 2008 09:58:45 -0500 (EST) Received: from FHDP1CCMXCG02.us.one.verizon.com ([166.68.240.34]) by coregate1.verizon.com (8.13.3/8.13.3) with ESMTP id m07EwSDB018445; Mon, 7 Jan 2008 08:58:44 -0600 (CST) Received: from FHDP1CCMXCV02.us.one.verizon.com ([166.68.240.12]) by FHDP1CCMXCG02.us.one.verizon.com with Microsoft SMTPSVC(6.0.3790.3959); Mon, 7 Jan 2008 09:58:38 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Mon, 7 Jan 2008 09:58:33 -0500 Message-ID: <33A24DCD2DC32148AD9C2C3298CB037A017088BD@FHDP1CCMXCV02.us.one.verizon.com> In-Reply-To: <092B2658AAB56A4D80836399A4C4703102E04C19@ASHEVS002.mcilink.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: ATM/Frame Relay/MPLS Forum (L2 Forum?) issue thread-index: AchRNb1m2+WAHZ/NRUec1b4I4lUigwAAiF4AAAC2GMA= References: <092B2658AAB56A4D80836399A4C4703102E04C19@ASHEVS002.mcilink.com> From: To: X-OriginalArrivalTime: 07 Jan 2008 14:58:38.0779 (UTC) FILETIME=[C90A00B0:01C8513D] X-Brightmail-Tracker: AAAAAA== X-Spam-Score: 0.0 (/) X-Scan-Signature: a1852b4f554b02e7e4548cc7928acc1f X-Mailman-Approved-At: Mon, 07 Jan 2008 20:27:31 -0500 Cc: narten@us.ibm.com, enum@ietf.org, IMCEAMAILTO-Ed+2ELewis+40neustar+2Ebiz@vzcorp.com, Harald@Alvestrand.no, bernie.hoeneisen@switch.ch, andrew.g.malis@verizon.com Subject: [Enum] RE: ATM/Frame Relay/MPLS Forum (L2 Forum?) issue X-BeenThere: enum@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Enum Discussion List List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: enum-bounces@ietf.org Tim, Thanks for forwarding Ed's email. The document discussed below is publicly available at http://www.ipmplsforum.org/ftp/pub/approved-specs/af-dans-0152.000.pdf . Ed, The IP/MPLS Forum is now the permanent online repository for the ATM Forum specifications. There is no problem with IANA downloading the document and making it publicly available in perpetuity if they so choose - just have them let me know by email if they end up doing so. Does this work for you (or f______________________________________________ enum mailing list enum@ietf.org https://www1.ietf.org/mailman/listinfo/enum _______________________________________________ enum mailing list enum@ietf.org https://www1.ietf.org/mailman/listinfo/enum From enum-bounces@ietf.org Mon Jan 07 20:27:42 2008 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1JC3Fb-0006sf-SC; Mon, 07 Jan 2008 20:27:31 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1JBtRL-00080r-JA for enum@ietf.org; Mon, 07 Jan 2008 09:58:59 -0500 Received: from sacmail2.verizon.com ([192.76.84.41]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1JBtRK-0007S6-OQ for enum@ietf.org; Mon, 07 Jan 2008 09:58:59 -0500 Received: from smtpftw3.verizon.com (smtpftw3.verizon.com [138.83.140.92]) by sacmail2.verizon.com (8.13.7+Sun/8.13.3) with ESMTP id m07EwlNa012595; Mon, 7 Jan 2008 09:58:47 -0500 (EST) Received: from tpaintrmemf3.verizon.com (tpaintrmemf3.verizon.com [138.83.67.58]) by smtpftw3.verizon.com (8.13.3/8.13.3) with ESMTP id m07EwkTZ012141; Mon, 7 Jan 2008 09:58:46 -0500 (EST) Received: from tpaintrmemf3.verizon.com (unknown [127.0.0.1]) by tpaintrmemf3.verizon.com (Symantec Mail Security) with ESMTP id EB121528004; Mon, 7 Jan 2008 09:58:45 -0500 (EST) X-AuditID: 8a53433a-adb81bb000000944-30-47823e256f23 Received: from coregate1.verizon.com (unknown [138.83.34.22]) by tpaintrmemf3.verizon.com (EMF) with ESMTP id BD9794E400A; Mon, 7 Jan 2008 09:58:45 -0500 (EST) Received: from FHDP1CCMXCG02.us.one.verizon.com ([166.68.240.34]) by coregate1.verizon.com (8.13.3/8.13.3) with ESMTP id m07EwSDB018445; Mon, 7 Jan 2008 08:58:44 -0600 (CST) Received: from FHDP1CCMXCV02.us.one.verizon.com ([166.68.240.12]) by FHDP1CCMXCG02.us.one.verizon.com with Microsoft SMTPSVC(6.0.3790.3959); Mon, 7 Jan 2008 09:58:38 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Mon, 7 Jan 2008 09:58:33 -0500 Message-ID: <33A24DCD2DC32148AD9C2C3298CB037A017088BD@FHDP1CCMXCV02.us.one.verizon.com> In-Reply-To: <092B2658AAB56A4D80836399A4C4703102E04C19@ASHEVS002.mcilink.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: ATM/Frame Relay/MPLS Forum (L2 Forum?) issue thread-index: AchRNb1m2+WAHZ/NRUec1b4I4lUigwAAiF4AAAC2GMA= References: <092B2658AAB56A4D80836399A4C4703102E04C19@ASHEVS002.mcilink.com> From: To: X-OriginalArrivalTime: 07 Jan 2008 14:58:38.0779 (UTC) FILETIME=[C90A00B0:01C8513D] X-Brightmail-Tracker: AAAAAA== X-Spam-Score: 0.0 (/) X-Scan-Signature: a1852b4f554b02e7e4548cc7928acc1f X-Mailman-Approved-At: Mon, 07 Jan 2008 20:27:31 -0500 Cc: narten@us.ibm.com, enum@ietf.org, IMCEAMAILTO-Ed+2ELewis+40neustar+2Ebiz@vzcorp.com, Harald@Alvestrand.no, bernie.hoeneisen@switch.ch, andrew.g.malis@verizon.com Subject: [Enum] RE: ATM/Frame Relay/MPLS Forum (L2 Forum?) issue X-BeenThere: enum@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Enum Discussion List List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: enum-bounces@ietf.org Tim, Thanks for forwarding Ed's email. The document discussed below is publicly available at http://www.ipmplsforum.org/ftp/pub/approved-specs/af-dans-0152.000.pdf . Ed, The IP/MPLS Forum is now the permanent online repository for the ATM Forum specifications. There is no problem with IANA downloading the document and making it publicly available in perpetuity if they so choose - just have them let me know by email if they end up doing so. Does this work for you (or for them)? I do not anticipate any further changes to this specification, which was published in July 2000. Please let me know if I can be of any further assistance. Cheers, Andy Malis Chair and President, IP/MPLS Forum www.ipmplsforum.org -----Original Message----- From: Dwight, Timothy M (Tim) [mailto:timothy.dwight@verizonbusiness.com]=20 Sent: Monday, January 07, 2008 9:18 AM To: Malis, Andrew G. (Andy) Subject: ATM/Frame Relay/MPLS Forum (L2 Forum?) issue Andy, Looks like there's an issue with making one of the old ATM Forum specifications (for a type of DNS resource record) publicly available. Can you help Ed out? Tim -----Original Message----- From: Edward Lewis [mailto:Ed.Lewis@neustar.biz]=20 Sent: Monday, January 07, 2008 7:54 AM To: Bernie Hoeneisen Cc: enum@ietf.org; narten@us.ibm.com; Edward Lewis; Harald@Alvestrand.no Subject: Re: [Enum] enum services registry question At 11:27 +0100 1/7/08, Bernie Hoeneisen wrote: >The term "permanent and readily available public specification" states >the intension, but I think it is a bit vague, when it comes to what >qualifies to this term. Furthermore it does not say much about the change >management of such a specification. > >To be on the safe side, I guess we should ensure that a copy of the >specification (as reviewed by expert) is always maintained at IANA, >unless there is an RFC (that can be simply referenced). This is the specific situation I have run into. There is a DNS RR=20 type - as far as I know no one uses - called ATMA. It was developed=20 and then documented by the ATM Forum. The document was available on=20 the ATM Forum's website. The ATM Forum ceased operations quite a while ago and became part of,=20 hmmm, some other organization whose name now escapes me. Within the=20 last year I exchanged email with members there but after being=20 promised a response to a question about getting the document=20 published under the name of the IETF the "line went dead." So today we have an entry in the DNS RR type registry that has no=20 reliable definition. I haven't gotten permission from the successor=20 organization to copy the document into the RFCs. IANA is not=20 equipped to archive documents so they can't just arrange to host the=20 document - two issues, one is the mechanics and the other is the=20 intellectual property. We are also stuck without the ability to=20 obsolete the registration because no one is willing to declare it=20 dead without knowing who is using it. So far what I've described is just a paperwork and bookkeeping=20 migraine headache. The reason I ever started to look into this was=20 when I was asked to write DNSSEC code separate from any other=20 implementation (in the 90's) and tried to research DNS from the=20 specifications and not "what would BIND do?" When asked if my code=20 handled "all the types" I wanted to be sure of the answer. If you were to build an implementation from scratch, that's when it matters. (I realize I'm not throwing out a solution. This is a reflection of=20 my experience in DNS and why I stopped to make the comment.) >On the other hand, this looks like an issue to be solved on rfc2434bis >level. (I therefore have CC:ed the authors of rfc2434bis to this email.) Do you have a URL for that document? >Propsosal: > > Unless there is some better solution proposed, I'll put a section > "reference" to the new IANA template in > draft-ietf-enum-enumservices-guide. > There can be either a reference to the RFC or an IANA internal reference > to the version of the specification after approval by the experts. > >Makes sense? The issue is the "IANA internal reference" as I mentioned before. >PS: It would be quite a bit easier, if we decided on "RFC required" >instead...;-) It certainly would be easier, but that means the RFC-Editor and IETF=20 are creating a monopoly on what goes into IANA. I believe that is=20 undesired by the powers that be. (I think the same was said in the=20 DNS group talking about their IANA instructions "bis" document.) --=20 -=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=or them)? I do not anticipate any further changes to this specification, which was published in July 2000. Please let me know if I can be of any further assistance. Cheers, Andy Malis Chair and President, IP/MPLS Forum www.ipmplsforum.org -----Original Message----- From: Dwight, Timothy M (Tim) [mailto:timothy.dwight@verizonbusiness.com]=20 Sent: Monday, January 07, 2008 9:18 AM To: Malis, Andrew G. (Andy) Subject: ATM/Frame Relay/MPLS Forum (L2 Forum?) issue Andy, Looks like there's an issue with making one of the old ATM Forum specifications (for a type of DNS resource record) publicly available. Can you help Ed out? Tim -----Original Message----- From: Edward Lewis [mailto:Ed.Lewis@neustar.biz]=20 Sent: Monday, January 07, 2008 7:54 AM To: Bernie Hoeneisen Cc: enum@ietf.org; narten@us.ibm.com; Edward Lewis; Harald@Alvestrand.no Subject: Re: [Enum] enum services registry question At 11:27 +0100 1/7/08, Bernie Hoeneisen wrote: >The term "permanent and readily available public specification" states >the intension, but I think it is a bit vague, when it comes to what >qualifies to this term. Furthermore it does not say much about the change >management of such a specification. > >To be on the safe side, I guess we should ensure that a copy of the >specification (as reviewed by expert) is always maintained at IANA, >unless there is an RFC (that can be simply referenced). This is the specific situation I have run into. There is a DNS RR=20 type - as far as I know no one uses - called ATMA. It was developed=20 and then documented by the ATM Forum. The document was available on=20 the ATM Forum's website. The ATM Forum ceased operations quite a while ago and became part of,=20 hmmm, some other organization whose name now escapes me. Within the=20 last year I exchanged email with members there but after being=20 promised a response to a question about getting the document=20 published under the name of the IETF the "line went dead." So today we have an entry in the DNS RR type registry that has no=20 reliable definition. I haven't gotten permission from the successor=20 organization to copy the document into the RFCs. IANA is not=20 equipped to archive documents so they can't just arrange to host the=20 document - two issues, one is the mechanics and the other is the=20 intellectual property. We are also stuck without the ability to=20 obsolete the registration because no one is willing to declare it=20 dead without knowing who is using it. So far what I've described is just a paperwork and bookkeeping=20 migraine headache. The reason I ever started to look into this was=20 when I was asked to write DNSSEC code separate from any other=20 implementation (in the 90's) and tried to research DNS from the=20 specifications and not "what would BIND do?" When asked if my code=20 handled "all the types" I wanted to be sure of the answer. If you were to build an implementation from scratch, that's when it matters. (I realize I'm not throwing out a solution. This is a reflection of=20 my experience in DNS and why I stopped to make the comment.) >On the other hand, this looks like an issue to be solved on rfc2434bis >level. (I therefore have CC:ed the authors of rfc2434bis to this email.) Do you have a URL for that document? >Propsosal: > > Unless there is some better solution proposed, I'll put a section > "reference" to the new IANA template in > draft-ietf-enum-enumservices-guide. > There can be either a reference to the RFC or an IANA internal reference > to the version of the specification after approval by the experts. > >Makes sense? The issue is the "IANA internal reference" as I mentioned before. >PS: It would be quite a bit easier, if we decided on "RFC required" >instead...;-) It certainly would be easier, but that means the RFC-Editor and IETF=20 are creating a monopoly on what goes into IANA. I believe that is=20 undesired by the powers that be. (I think the same was said in the=20 DNS group talking about their IANA instructions "bis" document.) --=20 -=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-= =3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D -=3D- Edward Lewis +1-571-434-5468 NeuStar Think glocally. Act confused. _______________________________________________ enum mailing list enum@ietf.org https://www1.ietf.org/mailman/listinfo/enum _______________________________________________ enum mailing list enum@ietf.org https://www1.ietf.org/mailman/listinfo/enum 3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-= =3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D -=3D- Edward Lewis +1-571-434-5468 NeuStar Think glocally. Act confused. _______________________________________________ enum mailing list enum@ietf.org https://www1.ietf.org/mailman/listinfo/enum _______________________________________________ enum mailing list enum@ietf.org https://www1.ietf.org/mailman/listinfo/enum From enum-bounces@ietf.org Mon Jan 07 20:28:41 2008 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1JC3Gj-0000My-5B; Mon, 07 Jan 2008 20:28:41 -0500 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1JByuJ-0004Ef-4j for enum@ietf.org; Mon, 07 Jan 2008 15:49:15 -0500 Received: from e32.co.us.ibm.com ([32.97.110.150]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1JByuI-0006gK-IK for enum@ietf.org; Mon, 07 Jan 2008 15:49:15 -0500 Received: from d03relay02.boulder.ibm.com (d03relay02.boulder.ibm.com [9.17.195.227]) by e32.co.us.ibm.com (8.13.8/8.13.8) with ESMTP id m07JkYJX001943 for ; Mon, 7 Jan 2008 14:46:34 -0500 Received: from d03av02.boulder.ibm.com (d03av02.boulder.ibm.com [9.17.195.168]) by d03relay02.boulder.ibm.com (8.13.8/8.13.8/NCO v8.7) with ESMTP id m07KnDRO169042 for ; Mon, 7 Jan 2008 13:49:13 -0700 Received: from d03av02.boulder.ibm.com (loopback [127.0.0.1]) by d03av02.boulder.ibm.com (8.12.11.20060308/8.13.3) with ESMTP id m07KnDoG031197 for ; Mon, 7 Jan 2008 13:49:13 -0700 Received: from cichlid.raleigh.ibm.com (wecm-9-67-135-64.wecm.ibm.com [9.67.135.64]) by d03av02.boulder.ibm.com (8.12.11.20060308/8.12.11) with ESMTP id m07KnBiZ031075 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 7 Jan 2008 13:49:12 -0700 Received: from cichlid.raleigh.ibm.com (cichlid-new [127.0.0.1]) by cichlid.raleigh.ibm.com (8.14.2/8.12.5) with ESMTP id m07Kn9ov025767; Mon, 7 Jan 2008 15:49:10 -0500 Message-Id: <200801072049.m07Kn9ov025767@cichlid.raleigh.ibm.com> To: Bernie Hoeneisen Subject: Re: [Enum] enum services registry question In-reply-to: References: Comments: In-reply-to Bernie Hoeneisen message dated "Mon, 07 Jan 2008 11:27:37 +0100." Date: Mon, 07 Jan 2008 15:49:09 -0500 From: Thomas Narten X-Spam-Score: 0.0 (/) X-Scan-Signature: f607d15ccc2bc4eaf3ade8ffa8af02a0 X-Mailman-Approved-At: Mon, 07 Jan 2008 20:28:40 -0500 Cc: enum@ietf.org, Harald@Alvestrand.no, Edward Lewis X-BeenThere: enum@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Enum Discussion List List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: enum-bounces@ietf.org Bernie Hoeneisen writes: > Hi Ed, > http://tools.ietf.org/id/draft-narten-iana-considerations-rfc2434bis-08.txt > gives some guidance in this (section 4.1.): > Specification required - Values and their meaning must be > documented in an RFC or other permanent and readily > available public specification, in sufficient detail so > that interoperability between independent implementations > is possible. When used, Specification Required also implies > usage of a Designated Expert, who will review the public > specification and evaluate whether it is sufficiently clear > to allow interoperable implementations. The intention > behind "permanent and readily available" is that a document > can be reasonably be expected to easily be found long after > IANA assignment of the requested value. Publication of an > RFC is the ideal means of achieving this requirement. [...] FWIW: the next version of this document expands on the above by adding: The intention behind "permanent and readily available" is that a document can reasonably be expected to be findable and retrievable long after IANA assignment of the requested value. Publication of an RFC is an ideal means of achieving this requirement, but Specification Required is intended to also cover the case of a document published outside of the RFC path. For RFC publication, the normal RFC review process is expected to provide the necessary review for interoperability, though the Designated Expert may be a particularly well-qualified person to perform such a review. > The term "permanent and readily available public specification" states the > intension, but I think it is a bit vague, when it comes to what qualifies > to this term. Furthermore it does not say much about the change management > of such a specification. Correct. We can't know in advance which documents (that have already been pubished somehow) meet the test, so some common sense is needed. If a document is already published somewhere, and it is clear that the publication is permanent, there is really no need to also have a copy available elsewhere. It would be OK to do so, but it should not be required. > To be on the safe side, I guess we should ensure that a copy of the > specification (as reviewed by expert) is always maintained at IANA, > unless there is an RFC (that can be simply referenced). I'm not opposed to this, but I also think we need to remember that the IETF is not the only ogranization capable of publishing documents "permanently". And we should only do this if we are worried that a particular document is important and might "go away" at some point in the future. Is the document in question of this type? Thomas _______________________________________________ enum mailing list enum@ietf.org https://www1.ietf.org/mailman/listinfo/enum From enum-bounces@ietf.org Tue Jan 08 02:12:45 2008 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1JC8d2-0000Q5-5a; Tue, 08 Jan 2008 02:12:04 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1JC8d0-00009W-JI for enum@ietf.org; Tue, 08 Jan 2008 02:12:02 -0500 Received: from eikenes.alvestrand.no ([158.38.152.233]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1JC8cy-0001Cl-Qk for enum@ietf.org; Tue, 08 Jan 2008 02:12:02 -0500 Received: from localhost (eikenes.alvestrand.no [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id 0328E25971B; Tue, 8 Jan 2008 08:11:57 +0100 (CET) Received: from eikenes.alvestrand.no ([127.0.0.1]) by localhost (eikenes.alvestrand.no [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 03961-01; Tue, 8 Jan 2008 08:11:52 +0100 (CET) Received: from [192.168.1.54] (162.80-203-220.nextgentel.com [80.203.220.162]) by eikenes.alvestrand.no (Postfix) with ESMTP id 62083259714; Tue, 8 Jan 2008 08:11:52 +0100 (CET) Message-ID: <4783221D.4040809@alvestrand.no> Date: Tue, 08 Jan 2008 08:11:25 +0100 From: Harald Alvestrand User-Agent: Thunderbird 1.5.0.14pre (X11/20071023) MIME-Version: 1.0 To: Thomas Narten Subject: Re: [Enum] enum services registry question References: <200801072049.m07Kn9ov025767@cichlid.raleigh.ibm.com> In-Reply-To: <200801072049.m07Kn9ov025767@cichlid.raleigh.ibm.com> X-Enigmail-Version: 0.94.2.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Virus-Scanned: by amavisd-new at alvestrand.no X-Spam-Score: 0.0 (/) X-Scan-Signature: 769a46790fb42fbb0b0cc700c82f7081 Cc: enum@ietf.org, Edward Lewis , Bernie Hoeneisen X-BeenThere: enum@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Enum Discussion List List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: enum-bounces@ietf.org Thomas Narten skrev: > Bernie Hoeneisen writes: > > >> The term "permanent and readily available public specification" states the >> intension, but I think it is a bit vague, when it comes to what qualifies >> to this term. Furthermore it does not say much about the change management >> of such a specification. >> > > Correct. We can't know in advance which documents (that have already > been pubished somehow) meet the test, so some common sense is > needed. If a document is already published somewhere, and it is clear > that the publication is permanent, there is really no need to also > have a copy available elsewhere. It would be OK to do so, but it > should not be required. > > >> To be on the safe side, I guess we should ensure that a copy of the >> specification (as reviewed by expert) is always maintained at IANA, >> unless there is an RFC (that can be simply referenced). >> > > I'm not opposed to this, but I also think we need to remember that the > IETF is not the only ogranization capable of publishing documents > "permanently". And we should only do this if we are worried that a > particular document is important and might "go away" at some point in > the future. Is the document in question of this type? > I think there are 2 failure modes we're trying to guard against here: 1) Being totally unable to find the specification underlying a codepoint. In these Google-infested times, that's rarely going to be a problem. 2) Having 2 people holding incompatible versions of the specification both claiming that "THIS is the specification that was registered". In that case, any stable identifier (ISBN number, standards organization + document serial number, author + spec name + date....) will do to adjudicate the case. So I think the stability of the identifier is critical. Having a copy of the document is also nice. Harald _______________________________________________ enum mailing list enum@ietf.org https://www1.ietf.org/mailman/listinfo/enum From enum-bounces@ietf.org Tue Jan 08 04:30:16 2008 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1JCAmT-0000RF-0E; Tue, 08 Jan 2008 04:29:57 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1JCAmR-0000R7-Gy for enum@ietf.org; Tue, 08 Jan 2008 04:29:55 -0500 Received: from medel.switch.ch ([130.59.108.39]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1JCAmP-0003UC-SI for enum@ietf.org; Tue, 08 Jan 2008 04:29:55 -0500 Received: from [130.59.6.129] (helo=machb.switch.ch) by medel.switch.ch with esmtps (TLSv1:AES256-SHA:256) (Exim 4.67) (envelope-from ) id 1JCAik-0007Oi-Mm; Tue, 08 Jan 2008 10:26:06 +0100 Date: Tue, 8 Jan 2008 10:25:14 +0100 (CET) From: Bernie Hoeneisen X-X-Sender: bhoeneis@machb To: Harald Alvestrand Subject: Re: [Enum] enum services registry question In-Reply-To: <4783221D.4040809@alvestrand.no> Message-ID: References: <200801072049.m07Kn9ov025767@cichlid.raleigh.ibm.com> <4783221D.4040809@alvestrand.no> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-SWITCH-SCANNER: bypassed X-Spam-Score: 0.0 (/) X-Scan-Signature: 52f7a77164458f8c7b36b66787c853da Cc: Thomas Narten , enum@ietf.org, Edward Lewis X-BeenThere: enum@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Enum Discussion List List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: enum-bounces@ietf.org Hi Harald Thanks for the excellent summary. However, it covers just the cases, when there is already a problem. I'd rather like to see _avoiding_ such problems or confusions in the first place. Thus, I'd prefer to make it _clear_ from the beginning, which specification applies. This leads to an URL pointing to a stable place of the spec. A stable place is certainly fullfilled in the RFC case. Also many other (standards) organizations have such means. But there are always cases, where maintaining a copy of the spec locally is more than just a nice-to-have. IMHO the best place for this would be IANA. To be on the safe side, IANA maintaining a copy of every spec related to a IANA codepoint looks like a good idea to me. cheers, Bernie On Tue, 8 Jan 2008, Harald Alvestrand wrote: > Thomas Narten skrev: >> Bernie Hoeneisen writes: >> >> >>> The term "permanent and readily available public specification" states the >>> intension, but I think it is a bit vague, when it comes to what qualifies >>> to this term. Furthermore it does not say much about the change management >>> of such a specification. >>> >> >> Correct. We can't know in advance which documents (that have already >> been pubished somehow) meet the test, so some common sense is >> needed. If a document is already published somewhere, and it is clear >> that the publication is permanent, there is really no need to also >> have a copy available elsewhere. It would be OK to do so, but it >> should not be required. >> >> >>> To be on the safe side, I guess we should ensure that a copy of the >>> specification (as reviewed by expert) is always maintained at IANA, >>> unless there is an RFC (that can be simply referenced). >>> >> >> I'm not opposed to this, but I also think we need to remember that the >> IETF is not the only ogranization capable of publishing documents >> "permanently". And we should only do this if we are worried that a >> particular document is important and might "go away" at some point in >> the future. Is the document in question of this type? >> > I think there are 2 failure modes we're trying to guard against here: > > 1) Being totally unable to find the specification underlying a > codepoint. In these Google-infested times, that's rarely going to be a > problem. > > 2) Having 2 people holding incompatible versions of the specification > both claiming that "THIS is the specification that was registered". In > that case, any stable identifier (ISBN number, standards organization + > document serial number, author + spec name + date....) will do to > adjudicate the case. > > So I think the stability of the identifier is critical. Having a copy of > the document is also nice. > > Harald _______________________________________________ enum mailing list enum@ietf.org https://www1.ietf.org/mailman/listinfo/enum From enum-bounces@ietf.org Tue Jan 08 09:59:05 2008 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1JCFuk-0006dz-Iq; Tue, 08 Jan 2008 09:58:50 -0500 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1JCFui-0006dQ-E0 for enum@ietf.org; Tue, 08 Jan 2008 09:58:48 -0500 Received: from hlid.ogud.com ([66.92.146.160] helo=ogud.com) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1JCFuh-0005TN-Mn for enum@ietf.org; Tue, 08 Jan 2008 09:58:48 -0500 Received: from [10.31.32.165] (hlid.ogud.com [66.92.146.160]) by ogud.com (8.13.1/8.13.1) with ESMTP id m08EwS5p026533; Tue, 8 Jan 2008 09:58:28 -0500 (EST) (envelope-from Ed.Lewis@neustar.biz) Mime-Version: 1.0 Message-Id: In-Reply-To: References: <200801072049.m07Kn9ov025767@cichlid.raleigh.ibm.com> <4783221D.4040809@alvestrand.no> Date: Tue, 8 Jan 2008 09:50:16 -0500 To: Bernie Hoeneisen From: Edward Lewis Subject: Re: [Enum] enum services registry question Content-Type: text/plain; charset="us-ascii" ; format="flowed" X-Spam-Score: 0.0 (/) X-Scan-Signature: 386e0819b1192672467565a524848168 Cc: Thomas Narten , Harald Alvestrand , Edward Lewis , enum@ietf.org X-BeenThere: enum@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Enum Discussion List List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: enum-bounces@ietf.org Thanks Harald, for the summary. I hadn't thought of your second point, but that is true, without a clearly defined reference if there are two purported definitions it may not be clear which is the legitimate one. I was told, by a librarian-type person, some years ago that URLs are not really good references. They are good ways to locate something but there are too many variable in the resolution of a URL to make it ever considered stable. I've been biased by that claim against ever saying that a URL is sufficient. Does IANA archive documents now? I certainly would like that but I don't know if it is within the scope of the contracted-role they have. In any case, the enumservices registry ought to have references that are traceable as well as pointers to available copies of the documents. At 10:25 +0100 1/8/08, Bernie Hoeneisen wrote: >Hi Harald > >Thanks for the excellent summary. > >However, it covers just the cases, when there is already a problem. >I'd rather like to see _avoiding_ such problems or confusions in the >first place. Thus, I'd prefer to make it _clear_ from the beginning, >which specification applies. This leads to an URL pointing to a >stable place of the spec. A stable place is certainly fullfilled in >the RFC case. Also many other (standards) organizations have such >means. But there are always cases, where maintaining a copy of the >spec locally is more than just a nice-to-have. IMHO the best place >for this would be IANA. To be on the safe side, IANA maintaining a >copy of every spec related to a IANA codepoint looks like a good >idea to me. > >cheers, > Bernie > >On Tue, 8 Jan 2008, Harald Alvestrand wrote: > >> Thomas Narten skrev: >>> Bernie Hoeneisen writes: >>> >>> >>>> The term "permanent and readily available public specification" states the >>>> intension, but I think it is a bit vague, when it comes to what qualifies >>>> to this term. Furthermore it does not say much about the change management >>>> of such a specification. >>>> >>> >>> Correct. We can't know in advance which documents (that have already >>> been pubished somehow) meet the test, so some common sense is >>> needed. If a document is already published somewhere, and it is clear >>> that the publication is permanent, there is really no need to also >>> have a copy available elsewhere. It would be OK to do so, but it >>> should not be required. >>> >>> >>>> To be on the safe side, I guess we should ensure that a copy of the >>>> specification (as reviewed by expert) is always maintained at IANA, >>>> unless there is an RFC (that can be simply referenced). >>>> >>> >>> I'm not opposed to this, but I also think we need to remember that the >>> IETF is not the only ogranization capable of publishing documents >>> "permanently". And we should only do this if we are worried that a >>> particular document is important and might "go away" at some point in >>> the future. Is the document in question of this type? >>> >> I think there are 2 failure modes we're trying to guard against here: >> >> 1) Being totally unable to find the specification underlying a >> codepoint. In these Google-infested times, that's rarely going to be a >> problem. >> >> 2) Having 2 people holding incompatible versions of the specification >> both claiming that "THIS is the specification that was registered". In >> that case, any stable identifier (ISBN number, standards organization + >> document serial number, author + spec name + date....) will do to >> adjudicate the case. >> >> So I think the stability of the identifier is critical. Having a copy of >> the document is also nice. >> >> Harald -- -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Edward Lewis +1-571-434-5468 NeuStar Think glocally. Act confused. _______________________________________________ enum mailing list enum@ietf.org https://www1.ietf.org/mailman/listinfo/enum From enum-bounces@ietf.org Tue Jan 08 10:20:28 2008 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1JCGFI-0004BG-Pq; Tue, 08 Jan 2008 10:20:04 -0500 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1JCGFH-0004B9-D9 for enum@ietf.org; Tue, 08 Jan 2008 10:20:03 -0500 Received: from medel.switch.ch ([130.59.108.39]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1JCGFG-0005vD-Iv for enum@ietf.org; Tue, 08 Jan 2008 10:20:02 -0500 Received: from [130.59.6.129] (helo=machb.switch.ch) by medel.switch.ch with esmtps (TLSv1:AES256-SHA:256) (Exim 4.67) (envelope-from ) id 1JCGBc-0007IB-87 for enum@ietf.org; Tue, 08 Jan 2008 16:16:16 +0100 Date: Tue, 8 Jan 2008 16:15:23 +0100 (CET) From: Bernie Hoeneisen X-X-Sender: bhoeneis@machb To: enum@ietf.org Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-SWITCH-SCANNER: bypassed X-Spam-Score: 0.0 (/) X-Scan-Signature: 52e1467c2184c31006318542db5614d5 Subject: [Enum] 3761bis and enumservices-guide X-BeenThere: enum@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Enum Discussion List List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: enum-bounces@ietf.org Hi, Trying to finish the enumservices-guide, we came accross some conflicts/overlaps between 3761bis and enumservices-guide. So far I have identified the following issues: 1) IANA registration template: - Shall we keep it in 3761bis and update it? - Shall we move all the IANA staff over to enumservices-guide? - Changes so far are: - adding a "Enumservice Class" - adding a reference (URL?) to the specification - no longer RFC required, but specification required 2) references between RCF3761, 3761bis and enumservices-guide - Leads to a publication timing issue - Status of enumservices-guide might need to be promoted to standards track (not just bcp) - This is also dependent on 1) 3) For the experimental services, the ABNF needs to be corrected to explicitly allow 'X-' prefix. There might be some more issues, but I guess the above are the major ones to be resolved. Any opinions? cheers, Bernie _______________________________________________ enum mailing list enum@ietf.org https://www1.ietf.org/mailman/listinfo/enum From enum-bounces@ietf.org Tue Jan 08 17:09:02 2008 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1JCMcl-00069O-W9; Tue, 08 Jan 2008 17:08:43 -0500 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1JCMck-00069J-Bh for enum@ietf.org; Tue, 08 Jan 2008 17:08:42 -0500 Received: from mail.songbird.com ([208.184.79.10]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1JCMcj-0008CX-Sy for enum@ietf.org; Tue, 08 Jan 2008 17:08:42 -0500 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 m08M7xk2031035 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Tue, 8 Jan 2008 14:08:03 -0800 From: "Richard Shockey" To: "'Bernie Hoeneisen'" , References: In-Reply-To: Subject: RE: [Enum] 3761bis and enumservices-guide Date: Tue, 8 Jan 2008 17:08:11 -0500 Message-ID: <07fd01c85242$f7a69db0$e6f3d910$@us> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: AchSCeT8Py8pZfflQy2UaPDNxLKNIAAOMaFQ Content-Language: en-us X-SongbirdInformation: support@songbird.com for more information X-Songbird: Clean X-Songbird-From: richard@shockey.us X-Spam-Score: 0.0 (/) X-Scan-Signature: 5a9a1bd6c2d06a21d748b7d0070ddcb8 Cc: X-BeenThere: enum@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Enum Discussion List List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: enum-bounces@ietf.org IMHO the entire IANA registration process should be moved to the Enumservices guide and that that the document should be proposed standard. Anyone else care to comment? 3761 bis can then refer to this RFC. > -----Original Message----- > From: Bernie Hoeneisen [mailto:bhoeneis@switch.ch] > Sent: Tuesday, January 08, 2008 10:15 AM > To: enum@ietf.org > Subject: [Enum] 3761bis and enumservices-guide > > Hi, > > Trying to finish the enumservices-guide, we came accross some > conflicts/overlaps between 3761bis and enumservices-guide. > > > So far I have identified the following issues: > > > 1) IANA registration template: > - Shall we keep it in 3761bis and update it? > - Shall we move all the IANA staff over to enumservices-guide? > - Changes so far are: > - adding a "Enumservice Class" > - adding a reference (URL?) to the specification > - no longer RFC required, but specification required > > > 2) references between RCF3761, 3761bis and enumservices-guide > - Leads to a publication timing issue > - Status of enumservices-guide might need to be promoted to > standards > track (not just bcp) > - This is also dependent on 1) > > > 3) For the experimental services, the ABNF needs to be corrected to > explicitly allow 'X-' prefix. > > > There might be some more issues, but I guess the above are the major > ones to be > resolved. > > Any opinions? > > cheers, > Bernie > > _______________________________________________ > enum mailing list > enum@ietf.org > https://www1.ietf.org/mailman/listinfo/enum _______________________________________________ enum mailing list enum@ietf.org https://www1.ietf.org/mailman/listinfo/enum From enum-bounces@ietf.org Tue Jan 15 08:29:45 2008 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1JElrA-0004p6-Gc; Tue, 15 Jan 2008 08:29:32 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1JElr9-0004oz-CH for enum@ietf.org; Tue, 15 Jan 2008 08:29:31 -0500 Received: from medel.switch.ch ([2001:620:0:14:214:4fff:fe75:4774]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1JElr7-0004Qt-8V for enum@ietf.org; Tue, 15 Jan 2008 08:29:31 -0500 Received: from [130.59.6.129] (helo=machb.switch.ch) by medel.switch.ch with esmtps (TLSv1:AES256-SHA:256) (Exim 4.67) (envelope-from ) id 1JElr6-0002b7-RB for enum@ietf.org; Tue, 15 Jan 2008 14:29:28 +0100 Date: Tue, 15 Jan 2008 14:24:43 +0100 (CET) From: Bernie Hoeneisen X-X-Sender: bhoeneis@machb To: Thomas Narten In-Reply-To: <200801072049.m07Kn9ov025767@cichlid.raleigh.ibm.com> Message-ID: References: <200801072049.m07Kn9ov025767@cichlid.raleigh.ibm.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed ReSent-Date: Tue, 15 Jan 2008 14:28:05 +0100 (CET) ReSent-From: Bernie Hoeneisen ReSent-To: enum@ietf.org ReSent-Subject: Poll: external references in Enumservice Registrations (was: enum services registry question) ReSent-Message-ID: X-SWITCH-SCANNER: bypassed X-Spam-Score: 0.0 (/) X-Scan-Signature: a7d2e37451f7f22841e3b6f40c67db0f Cc: enum@ietf.org, Harald@Alvestrand.no, Edward Lewis Subject: [Enum] Poll: external references in Enumservice Registrations (was: enum services registry question) X-BeenThere: enum@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Enum Discussion List List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: enum-bounces@ietf.org Errors-To: enum-bounces@ietf.org Dear ENUM list, Below a summary on the issue and the options to go forward with the enumservices-guide I-D concerning external references. Please send your options until the end of this week to this list, so that we can go on with the enumservices-guide I-D! As a consequence of the "specification required" decision, there needs to be a means to ensure permanent storage of the specification, if not RFC. Options: 1) Leave the issue totally to the narten I-D and IANA. Don't deal with it in enumservices-guide I-D. 2) In case the specification is not published as RFC, instruct IANA to store a copy of the specification as rewiewed by expert. (Results in either reference to RFC or IANA internal reference.) Require such a reference in the IANA template for Enumservice registrations. 3) Add an exact (external) reference to specification in the IANA template for Enumservice registrations. Leave the rest to the narten I-D. In case no other opinion is stated to the list until the end of this week, I'll take it as ENUM WG consensus and move on with option 3). Questions? Comments? Opinions? cheers, Bernie On Mon, 7 Jan 2008, Thomas Narten wrote: > Bernie Hoeneisen writes: > >> Hi Ed, > >> http://tools.ietf.org/id/draft-narten-iana-considerations-rfc2434bis-08.txt >> gives some guidance in this (section 4.1.): > >> Specification required - Values and their meaning must be >> documented in an RFC or other permanent and readily >> available public specification, in sufficient detail so >> that interoperability between independent implementations >> is possible. When used, Specification Required also implies >> usage of a Designated Expert, who will review the public >> specification and evaluate whether it is sufficiently clear >> to allow interoperable implementations. The intention >> behind "permanent and readily available" is that a document >> can be reasonably be expected to easily be found long after >> IANA assignment of the requested value. Publication of an >> RFC is the ideal means of achieving this requirement. [...] > > FWIW: the next version of this document expands on the above by > adding: > > The intention > behind "permanent and readily available" is that a document > can reasonably be expected to be findable and retrievable > long after IANA assignment of the requested value. > Publication of an RFC is an ideal means of achieving this > requirement, but Specification Required is intended to also > cover the case of a document published outside of the RFC > path. For RFC publication, the normal RFC review process is > expected to provide the necessary review for > interoperability, though the Designated Expert may be a > particularly well-qualified person to perform such a > review. > > >> The term "permanent and readily available public specification" states the >> intension, but I think it is a bit vague, when it comes to what qualifies >> to this term. Furthermore it does not say much about the change management >> of such a specification. > > Correct. We can't know in advance which documents (that have already > been pubished somehow) meet the test, so some common sense is > needed. If a document is already published somewhere, and it is clear > that the publication is permanent, there is really no need to also > have a copy available elsewhere. It would be OK to do so, but it > should not be required. > >> To be on the safe side, I guess we should ensure that a copy of the >> specification (as reviewed by expert) is always maintained at IANA, >> unless there is an RFC (that can be simply referenced). > > I'm not opposed to this, but I also think we need to remember that the > IETF is not the only ogranization capable of publishing documents > "permanently". And we should only do this if we are worried that a > particular document is important and might "go away" at some point in > the future. Is the document in question of this type? > > Thomas > > _______________________________________________ > enum mailing list > enum@ietf.org > https://www1.ietf.org/mailman/listinfo/enum > _______________________________________________ enum mailing list enum@ietf.org https://www1.ietf.org/mailman/listinfo/enum From enum-bounces@ietf.org Tue Jan 15 08:40:31 2008 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1JEm1k-0007b1-4q; Tue, 15 Jan 2008 08:40:28 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1JEm1i-0007Zs-Ku for enum@ietf.org; Tue, 15 Jan 2008 08:40:26 -0500 Received: from eikenes.alvestrand.no ([158.38.152.233]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1JEm1h-0004am-3c for enum@ietf.org; Tue, 15 Jan 2008 08:40:26 -0500 Received: from localhost (eikenes.alvestrand.no [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id 511072596C7; Tue, 15 Jan 2008 14:40:24 +0100 (CET) Received: from eikenes.alvestrand.no ([127.0.0.1]) by localhost (eikenes.alvestrand.no [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 18009-07; Tue, 15 Jan 2008 14:40:17 +0100 (CET) Received: from [127.0.0.1] (eikenes.alvestrand.no [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id DDCF32596DF; Tue, 15 Jan 2008 14:40:16 +0100 (CET) Message-ID: <478CB7C0.6010606@alvestrand.no> Date: Tue, 15 Jan 2008 14:40:16 +0100 From: Harald Alvestrand User-Agent: Thunderbird 1.5.0.14pre (X11/20071022) MIME-Version: 1.0 To: Bernie Hoeneisen Subject: Re: [Enum] Poll: external references in Enumservice Registrations References: <200801072049.m07Kn9ov025767@cichlid.raleigh.ibm.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Scanned: by amavisd-new at alvestrand.no X-Spam-Score: 0.0 (/) X-Scan-Signature: 7d33c50f3756db14428398e2bdedd581 Cc: Thomas Narten , enum@ietf.org, Edward Lewis X-BeenThere: enum@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Enum Discussion List List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: enum-bounces@ietf.org Bernie Hoeneisen wrote: > > Options: > > 1) Leave the issue totally to the narten I-D and IANA. > Don't deal with it in enumservices-guide I-D. > > 2) In case the specification is not published as RFC, instruct IANA to > store a copy of the specification as rewiewed by expert. > (Results in either reference to RFC or IANA internal reference.) > Require such a reference in the IANA template for Enumservice > registrations. > > 3) Add an exact (external) reference to specification in the IANA > template for Enumservice registrations. Leave the rest to the narten I-D. > > > In case no other opinion is stated to the list until the end of this > week, I'll take it as ENUM WG consensus and move on with option 3). 3). _______________________________________________ enum mailing list enum@ietf.org https://www1.ietf.org/mailman/listinfo/enum From enum-bounces@ietf.org Tue Jan 15 09:10:58 2008 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1JEmV7-0002sv-Ui; Tue, 15 Jan 2008 09:10:49 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1JEmV7-0002sq-E9 for enum@ietf.org; Tue, 15 Jan 2008 09:10:49 -0500 Received: from ams-iport-1.cisco.com ([144.254.224.140]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1JEmV7-00052P-4G for enum@ietf.org; Tue, 15 Jan 2008 09:10:49 -0500 X-IronPort-AV: E=Sophos;i="4.24,287,1196636400"; d="scan'208";a="3051927" Received: from ams-dkim-1.cisco.com ([144.254.224.138]) by ams-iport-1.cisco.com with ESMTP; 15 Jan 2008 15:10:48 +0100 Received: from ams-core-1.cisco.com (ams-core-1.cisco.com [144.254.224.150]) by ams-dkim-1.cisco.com (8.12.11/8.12.11) with ESMTP id m0FEAm49031467; Tue, 15 Jan 2008 15:10:48 +0100 Received: from xbh-ams-332.emea.cisco.com (xbh-ams-332.cisco.com [144.254.231.87]) by ams-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id m0FEAego014607; Tue, 15 Jan 2008 14:10:40 GMT Received: from xfe-ams-332.cisco.com ([144.254.231.73]) by xbh-ams-332.emea.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 15 Jan 2008 15:10:40 +0100 Received: from junior.frobbit.se ([10.61.66.151]) by xfe-ams-332.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 15 Jan 2008 15:10:39 +0100 Message-Id: <31ECFEF3-6D47-4A9F-A513-4DAB764BA488@cisco.com> From: =?ISO-8859-1?Q?Patrik_F=E4ltstr=F6m?= To: Harald Alvestrand In-Reply-To: <478CB7C0.6010606@alvestrand.no> Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v915) Subject: Re: [Enum] Poll: external references in Enumservice Registrations Date: Tue, 15 Jan 2008 15:10:38 +0100 References: <200801072049.m07Kn9ov025767@cichlid.raleigh.ibm.com> <478CB7C0.6010606@alvestrand.no> X-Mailer: Apple Mail (2.915) X-OriginalArrivalTime: 15 Jan 2008 14:10:39.0748 (UTC) FILETIME=[684EBC40:01C85780] DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=445; t=1200406248; x=1201270248; c=relaxed/simple; s=amsdkim1002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=paf@cisco.com; z=From:=20=3D?ISO-8859-1?Q?Patrik_F=3DE4ltstr=3DF6m?=3D=20

|Subject:=20Re=3A=20[Enum]=20Poll=3A=20external=20reference s=20in=20Enumservice=20Registrations |Sender:=20; bh=iYhG+k5MJpeB3639/zuuZO+vRuAonxZpxOhVUTwVL7Q=; b=fwKo9cmyhADkTY5PYwUningVnnQqDIcFQ7neq2KOizzLDX0JhdUOyNbyHo nUTHDyx5YXsIHPWuTwkR/Xih0TV8IgdAJh3383WzbStXj/UmG7yn8HrotPVt 0mP1Ugyr7T; Authentication-Results: ams-dkim-1; header.From=paf@cisco.com; dkim=pass ( sig from cisco.com/amsdkim1002 verified; ); X-Spam-Score: -4.0 (----) X-Scan-Signature: de4f315c9369b71d7dd5909b42224370 Cc: Thomas Narten , enum@ietf.org, Edward Lewis , Bernie Hoeneisen X-BeenThere: enum@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Enum Discussion List List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: enum-bounces@ietf.org On 15 jan 2008, at 14.40, Harald Alvestrand wrote: >> 3) Add an exact (external) reference to specification in the IANA >> template for Enumservice registrations. Leave the rest to the >> narten I-D. >> >> >> In case no other opinion is stated to the list until the end of >> this week, I'll take it as ENUM WG consensus and move on with >> option 3). > 3). As a wg participant, yes I also think (3) is best. paf _______________________________________________ enum mailing list enum@ietf.org https://www1.ietf.org/mailman/listinfo/enum From enum-bounces@ietf.org Tue Jan 15 10:31:28 2008 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1JEnl4-0003TS-23; Tue, 15 Jan 2008 10:31:22 -0500 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1JEnl3-0003TM-Iz for enum@ietf.org; Tue, 15 Jan 2008 10:31:21 -0500 Received: from hlid.ogud.com ([66.92.146.160] helo=ogud.com) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1JEnl3-0004fn-4i for enum@ietf.org; Tue, 15 Jan 2008 10:31:21 -0500 Received: from [192.168.1.106] (hlid.ogud.com [66.92.146.160]) by ogud.com (8.13.1/8.13.1) with ESMTP id m0FFV6LP092814; Tue, 15 Jan 2008 10:31:08 -0500 (EST) (envelope-from Ed.Lewis@neustar.biz) Mime-Version: 1.0 Message-Id: In-Reply-To: References: <200801072049.m07Kn9ov025767@cichlid.raleigh.ibm.com> Date: Tue, 15 Jan 2008 10:24:30 -0500 To: Bernie Hoeneisen From: Edward Lewis Content-Type: text/plain; charset="us-ascii" ; format="flowed" X-Scanned-By: MIMEDefang 2.63 on 66.92.146.160 X-Spam-Score: 0.0 (/) X-Scan-Signature: ffa9dfbbe7cc58b3fa6b8ae3e57b0aa3 Cc: Thomas Narten , enum@ietf.org, Edward Lewis , Harald@Alvestrand.no Subject: [Enum] Re: Poll: external references in Enumservice Registrations (was: enum services registry question) X-BeenThere: enum@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Enum Discussion List List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: enum-bounces@ietf.org At 14:24 +0100 1/15/08, Bernie Hoeneisen wrote: >3) Add an exact (external) reference to specification in the IANA >template for Enumservice registrations. Leave the rest to the narten I-D. Number 3. >Questions? Comments? Opinions? I would add this: if the document is not an RFC then IANA will hold in escrow a copy of the document. Not republish it, but have a copy available in case the document is no longer accessible via other means. This is the path we will take for the DNS document I wrote about. If the document is static, that's sufficient. If the document is still alive, then IANA ought to hold in escrow the latest copy. (How IANA is alerted to get a new copy I'm not saying now.) -- -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Edward Lewis +1-571-434-5468 NeuStar Think glocally. Act confused. _______________________________________________ enum mailing list enum@ietf.org https://www1.ietf.org/mailman/listinfo/enum From enum-bounces@ietf.org Tue Jan 15 11:03:37 2008 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1JEoG3-0002mi-Pr; Tue, 15 Jan 2008 11:03:23 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1JEoG3-0002mc-CC for enum@ietf.org; Tue, 15 Jan 2008 11:03:23 -0500 Received: from medel.switch.ch ([2001:620:0:14:214:4fff:fe75:4774]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1JEoG1-0006qW-I9 for enum@ietf.org; Tue, 15 Jan 2008 11:03:23 -0500 Received: from [130.59.6.129] (helo=machb.switch.ch) by medel.switch.ch with esmtps (TLSv1:AES256-SHA:256) (Exim 4.67) (envelope-from ) id 1JEoFs-0006sr-H4; Tue, 15 Jan 2008 17:03:12 +0100 Date: Tue, 15 Jan 2008 17:02:01 +0100 (CET) From: Bernie Hoeneisen X-X-Sender: bhoeneis@machb To: Edward Lewis Subject: Re: [Enum] Re: Poll: external references in Enumservice Registrations (was: enum services registry question) In-Reply-To: Message-ID: References: <200801072049.m07Kn9ov025767@cichlid.raleigh.ibm.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-SWITCH-SCANNER: bypassed X-Spam-Score: 0.0 (/) X-Scan-Signature: 97adf591118a232206bdb5a27b217034 Cc: Thomas Narten , enum@ietf.org, Harald@Alvestrand.no X-BeenThere: enum@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Enum Discussion List List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: enum-bounces@ietf.org Hi Ed, Thomas, Harald et al. Interesting approach IANA to hold an escrow copy. I would suggest, that this should go to draft-narten-iana-considerations-rfc2434bis as it is an issue that applies to all cases with "specification required". What do the authors of rfc2434bis (Thomas, Harald) think about? cheers, Bernie On Tue, 15 Jan 2008, Edward Lewis wrote: > At 14:24 +0100 1/15/08, Bernie Hoeneisen wrote: > >> 3) Add an exact (external) reference to specification in the IANA >> template for Enumservice registrations. Leave the rest to the narten I-D. > > Number 3. > >> Questions? Comments? Opinions? > > I would add this: if the document is not an RFC then IANA will hold in escrow > a copy of the document. Not republish it, but have a copy available in case > the document is no longer accessible via other means. > > This is the path we will take for the DNS document I wrote about. > > If the document is static, that's sufficient. If the document is still > alive, then IANA ought to hold in escrow the latest copy. (How IANA is > alerted to get a new copy I'm not saying now.) _______________________________________________ enum mailing list enum@ietf.org https://www1.ietf.org/mailman/listinfo/enum From enum-bounces@ietf.org Tue Jan 15 19:07:08 2008 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1JEvnt-0000mP-2e; Tue, 15 Jan 2008 19:06:49 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1JEvns-0000mG-9g; Tue, 15 Jan 2008 19:06:48 -0500 Received: from ns1.neustar.com ([2001:503:c779:1a::9c9a:108a]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1JEvns-0001Rk-3G; Tue, 15 Jan 2008 19:06:48 -0500 Received: from stiedprstage1.ietf.org (stiedprstage1.va.neustar.com [10.31.47.10]) by ns1.neustar.com (Postfix) with ESMTP id 0118026E60; Wed, 16 Jan 2008 00:06:48 +0000 (GMT) Received: from ietf by stiedprstage1.ietf.org with local (Exim 4.43) id 1JEvnr-0007rF-TW; Tue, 15 Jan 2008 19:06:47 -0500 X-test-idtracker: no To: IETF-Announce From: The IESG Message-Id: Date: Tue, 15 Jan 2008 19:06:47 -0500 X-Spam-Score: -1.4 (-) X-Scan-Signature: d6b246023072368de71562c0ab503126 Cc: enum@ietf.org Subject: [Enum] Last Call: draft-ietf-enum-experiences (ENUM Implementation Issues and Experiences) to Informational RFC X-BeenThere: enum@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: ietf@ietf.org List-Id: Enum Discussion List List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: enum-bounces@ietf.org The IESG has received a request from the Telephone Number Mapping WG (enum) to consider the following document: - 'ENUM Implementation Issues and Experiences ' as an Informational RFC The IESG plans to make a decision in the next few weeks, and solicits final comments on this action. Please send substantive comments to the ietf@ietf.org mailing lists by 2008-01-29. Exceptionally, comments may be sent to iesg@ietf.org instead. In either case, please retain the beginning of the Subject line to allow automated sorting. The file can be obtained via http://www.ietf.org/internet-drafts/draft-ietf-enum-experiences-08.txt IESG discussion can be tracked via https://datatracker.ietf.org/public/pidtracker.cgi?command=view_id&dTag=11979&rfc_flag=0 _______________________________________________ enum mailing list enum@ietf.org https://www1.ietf.org/mailman/listinfo/enum From enum-bounces@ietf.org Sat Jan 19 11:45:00 2008 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1JGGoG-0002QV-Oh; Sat, 19 Jan 2008 11:44:44 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1JGGoE-0002QN-QS for enum@ietf.org; Sat, 19 Jan 2008 11:44:42 -0500 Received: from newdev.eecs.harvard.edu ([140.247.60.212]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1JGGoE-0002DE-Jm for enum@ietf.org; Sat, 19 Jan 2008 11:44:42 -0500 Received: by newdev.eecs.harvard.edu (Postfix, from userid 501) id B355871449E; Sat, 19 Jan 2008 11:44:30 -0500 (EST) To: enum@ietf.org Subject: RE: [Enum] 3761bis and enumservices-guide Message-Id: <20080119164430.B355871449E@newdev.eecs.harvard.edu> Date: Sat, 19 Jan 2008 11:44:30 -0500 (EST) From: sob@harvard.edu (Scott O. Bradner) X-Spam-Score: 0.0 (/) X-Scan-Signature: d17f825e43c9aed4fd65b7edddddec89 X-BeenThere: enum@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Enum Discussion List List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: enum-bounces@ietf.org Bernie suggests: > IMHO the entire IANA registration process should be moved to the > Enumservices guide and that that the document should be proposed standard. that makes sense to me so I'll pull the "Registration mechanism for Enumservices" section from 3761bis Scott _______________________________________________ enum mailing list enum@ietf.org https://www1.ietf.org/mailman/listinfo/enum From enum-bounces@ietf.org Sun Jan 20 12:21:43 2008 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1JGdrQ-0003n0-Ub; Sun, 20 Jan 2008 12:21:32 -0500 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1JGdrP-0003mu-MS for enum@ietf.org; Sun, 20 Jan 2008 12:21:31 -0500 Received: from mail.songbird.com ([208.184.79.10]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1JGdrP-0004XR-3y for enum@ietf.org; Sun, 20 Jan 2008 12:21:31 -0500 Received: from rshockeyPC (h-68-165-240-35.mclnva23.covad.net [68.165.240.35]) (authenticated bits=0) by mail.songbird.com (8.12.11.20060308/8.12.11) with ESMTP id m0KHKspl010923 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO) for ; Sun, 20 Jan 2008 09:20:56 -0800 From: "Richard Shockey" To: Date: Sun, 20 Jan 2008 12:21:19 -0500 Message-ID: <000001c85b88$e0a63d10$a1f2b730$@us> MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: AchZjwbWiOqfgPcQRveEVZK6ql7/egB+dMGw Content-Language: en-us X-Spam-Score: 0.0 (/) X-Scan-Signature: f60d0f7806b0c40781eee6b9cd0b2135 Subject: [Enum] FW: Internet-Drafts Submission Cutoff Dates for the 71st IETF Meeting in Philadelphia, PA, USA X-BeenThere: enum@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Enum Discussion List List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: enum-bounces@ietf.org -----Original Message----- From: ietf-secretariat@ietf.org [mailto:ietf-secretariat@ietf.org]=20 Sent: Friday, January 18, 2008 12:00 AM To: ietf-announce@ietf.org Subject: Internet-Drafts Submission Cutoff Dates for the 71st IETF = Meeting in Philadelphia, PA, USA There are two (2) Internet-Draft cutoff dates for the 71st=20 IETF Meeting in Philadelphia, PA, USA: February 18th: Cutoff Date for Initial (i.e., version -00)=20 Internet-Draft Submissions=20 All initial Internet-Drafts (version -00) must be submitted by Monday,=20 February 18th at 9:00 AM ET (14:00 UTC/GMT).The only exception is for version -00 WG drafts that replace existing non-WG drafts. Such drafts may be submitted until the cutoff date for version -01 and higher drafts. As always, all initial submissions with a filename beginning with=20 "draft-ietf" must be approved by the appropriate WG Chair before they=20 can be processed or announced. The Secretariat would appreciate=20 receiving WG Chair approval by Monday, February 11th at 9:00 AM ET = (14:00 UTC/GMT). February (14:00 UTC/GMT): Cutoff Date for Revised (i.e., version -01 = and higher)=20 Internet-Draft Submissions=20 All revised Internet-Drafts (version -01 and higher) must be submitted=20 by Monday, February 25th at 9:00 AM ET (14:00 UTC/GMT). Initial and revised Internet-Drafts received after their respective=20 cutoff dates will not be made available in the Internet-Drafts=20 directory or announced until on or after Monday, March 10th at 9:00=20 AM ET (13:00 UTC/GMT), when Internet-Draft posting resumes. Please do = not wait until=20 the last minute to submit. The Secretariat encourages you to submit your Internet-Drafts via the=20 Internet-Draft Submission Tool (IDST) = https://datatracker.ietf.org/idst/upload.cgi.=20 If you are unable to do so, then you may still submit your Internet- Drafts manually by sending them to internet-drafts@ietf.org. If you=20 are submitting a version -00 WG draft that replaces non-WG draft, then=20 you must submit it manually as the current IDST cannot handle=20 replacements. Please be sure to state that one draft replaces another=20 in the cover note that accompanies your submission. Also, please note=20 that the IDST will not accept drafts submitted after their respective=20 cutoff dates. Thank you for your understanding and cooperation. If you have any=20 questions or concerns, then please send a message to=20 internet-drafts@ietf.org. The IETF Secretariat FYI: The Internet-Draft cutoff dates as well as other significant dates for the 71st IETF Meeting can be found at = http://www.ietf.org/meetings/71-cutoff_dates.html. _______________________________________________ IETF-Announce mailing list IETF-Announce@ietf.org https://www1.ietf.org/mailman/listinfo/ietf-announce _______________________________________________ enum mailing list enum@ietf.org https://www1.ietf.org/mailman/listinfo/enum From enum-bounces@ietf.org Mon Jan 21 07:06:46 2008 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1JGvQG-0001cx-WC; Mon, 21 Jan 2008 07:06:41 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1JGvQF-0001cr-Sb for enum@ietf.org; Mon, 21 Jan 2008 07:06:39 -0500 Received: from medel.switch.ch ([2001:620:0:14:214:4fff:fe75:4774]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1JGvQE-00031K-1E for enum@ietf.org; Mon, 21 Jan 2008 07:06:39 -0500 Received: from [130.59.6.129] (helo=machb.switch.ch) by medel.switch.ch with esmtps (TLSv1:AES256-SHA:256) (Exim 4.67) (envelope-from ) id 1JGvQA-0003HR-Bd; Mon, 21 Jan 2008 13:06:34 +0100 Date: Mon, 21 Jan 2008 13:05:10 +0100 (CET) From: Bernie Hoeneisen X-X-Sender: bhoeneis@machb To: enum@ietf.org In-Reply-To: Message-ID: References: <200801072049.m07Kn9ov025767@cichlid.raleigh.ibm.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-SWITCH-SCANNER: bypassed X-Spam-Score: 0.0 (/) X-Scan-Signature: 50a516d93fd399dc60588708fd9a3002 Cc: Thomas Narten , Harald@Alvestrand.no Subject: [Enum] Consensus found on external references in Enumservice Registrations X-BeenThere: enum@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Enum Discussion List List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: enum-bounces@ietf.org Dear ENUM WG We can declare consensus on option numer 3). Still open issue: Will 'draft-narten-iana-considerations-rfc2434bis' deal with the escrow copy stuff, or do we need to handle this in enumservices-guide (as well as e.g. Ed in the DNS extensions document and so on)? cheers, Bernie On Tue, 15 Jan 2008, Bernie Hoeneisen wrote: > Hi Ed, Thomas, Harald et al. > > Interesting approach IANA to hold an escrow copy. > > I would suggest, that this should go to > draft-narten-iana-considerations-rfc2434bis > as it is an issue that applies to all cases with "specification required". > > What do the authors of rfc2434bis (Thomas, Harald) think about? > > cheers, > Bernie > > > On Tue, 15 Jan 2008, Edward Lewis wrote: > >> At 14:24 +0100 1/15/08, Bernie Hoeneisen wrote: >> >>> 3) Add an exact (external) reference to specification in the IANA >>> template for Enumservice registrations. Leave the rest to the narten I-D. >> >> Number 3. >> >>> Questions? Comments? Opinions? >> >> I would add this: if the document is not an RFC then IANA will hold in >> escrow a copy of the document. Not republish it, but have a copy available >> in case the document is no longer accessible via other means. >> >> This is the path we will take for the DNS document I wrote about. >> >> If the document is static, that's sufficient. If the document is still >> alive, then IANA ought to hold in escrow the latest copy. (How IANA is >> alerted to get a new copy I'm not saying now.) _______________________________________________ enum mailing list enum@ietf.org https://www1.ietf.org/mailman/listinfo/enum From enum-bounces@ietf.org Mon Jan 21 07:19:46 2008 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1JGvcu-0001au-8q; Mon, 21 Jan 2008 07:19:44 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1JGvcs-0001aY-Mt for enum@ietf.org; Mon, 21 Jan 2008 07:19:42 -0500 Received: from medel.switch.ch ([2001:620:0:14:214:4fff:fe75:4775]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1JGvcr-0003Ew-1O for enum@ietf.org; Mon, 21 Jan 2008 07:19:42 -0500 Received: from [130.59.6.129] (helo=machb.switch.ch) by medel.switch.ch with esmtps (TLSv1:AES256-SHA:256) (Exim 4.67) (envelope-from ) id 1JGvcp-0004C8-5c; Mon, 21 Jan 2008 13:19:39 +0100 Date: Mon, 21 Jan 2008 13:18:15 +0100 (CET) From: Bernie Hoeneisen X-X-Sender: bhoeneis@machb To: enum@ietf.org Subject: RE: [Enum] 3761bis and enumservices-guide In-Reply-To: <20080119164430.B355871449E@newdev.eecs.harvard.edu> Message-ID: References: <20080119164430.B355871449E@newdev.eecs.harvard.edu> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-SWITCH-SCANNER: bypassed X-Spam-Score: 0.0 (/) X-Scan-Signature: 9182cfff02fae4f1b6e9349e01d62f32 Cc: "Scott O. Bradner" X-BeenThere: enum@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Enum Discussion List List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: enum-bounces@ietf.org Dear ENUM WG Any Objections? Please state any comments latest by the end of this week. If no objections received until Friday, 25 Jan, we'll implement this to the enumservices-guide I-D. cheers, Bernie On Sat, 19 Jan 2008, Scott O. Bradner wrote: > Rich Shockey suggests: >> IMHO the entire IANA registration process should be moved to the >> Enumservices guide and that that the document should be proposed standard. > that makes sense to me > > so I'll pull the "Registration mechanism for Enumservices" section > from 3761bis > > Scott _______________________________________________ enum mailing list enum@ietf.org https://www1.ietf.org/mailman/listinfo/enum From enum-bounces@ietf.org Mon Jan 21 14:27:09 2008 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1JH2IQ-0001G8-0k; Mon, 21 Jan 2008 14:27:02 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1JH2IO-00018e-GK; Mon, 21 Jan 2008 14:27:00 -0500 Received: from mail.songbird.com ([208.184.79.10]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1JH2IN-000241-W7; Mon, 21 Jan 2008 14:27:00 -0500 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 m0LJPYUJ023588 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Mon, 21 Jan 2008 11:25:36 -0800 From: "Richard Shockey" To: , Date: Mon, 21 Jan 2008 14:25:49 -0500 Message-ID: <025801c85c63$727f6b50$577e41f0$@us> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 Thread-Index: AcbidRrsdNW+DQs8QJaqMDsmeXxplw== Content-Language: en-us X-Spam-Score: -1.0 (-) X-Scan-Signature: 769a46790fb42fbb0b0cc700c82f7081 Cc: 'Cullen Jennings' , =?iso-8859-1?Q?'=22Patrik_F=E4ltstr=F6m=22'?= , "'Peterson, Jon'" Subject: [Enum] ENUM WG Request for Publication - draft-ietf-enum-vmsg-01.txt X-BeenThere: enum@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: richard@shockey.us List-Id: Enum Discussion List List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: enum-bounces@ietf.org This is a request for publication on one ENUM WG document. T Title : IANA Registration of Enumservices for Voice and Video Messaging Author(s) : J. Livingood, D. Troshynski Filename : draft-ietf-enum-vmsg-01.txt Pages : 27 Date : 2007-12-18 This document registers the Enumservice named "vmsg", which is used to facilitate the real-time routing of voice and/or video communications to a messaging system. This vmsg Enumservice registers three Enumservice types; "voicemsg", "videomsg", and "unifmsg". A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-enum-vmsg-01.txt A two week WG last call on this document concluded on January 21. The document listed above is being considered for Proposed Standard. This document has been extensively discussed during 2007. Richard Shockey Director, Member of the Technical Staff NeuStar 46000 Center Oak Plaza - Sterling, VA 20166 sip:rshockey(at)iptel.org sip:5651(at)neustarlab.biz PSTN Office +1 571.434.5651 PSTN Mobile: +1 703.593.2683 _______________________________________________ enum mailing list enum@ietf.org https://www1.ietf.org/mailman/listinfo/enum _______________________________________________ enum mailing list enum@ietf.org https://www1.ietf.org/mailman/listinfo/enum From enum-bounces@ietf.org Mon Jan 21 14:29:37 2008 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1JH2Ks-0001we-P5; Mon, 21 Jan 2008 14:29:34 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1JH2Kr-0001wL-C1; Mon, 21 Jan 2008 14:29:33 -0500 Received: from mail.songbird.com ([208.184.79.10]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1JH2Kq-0002Fe-Um; Mon, 21 Jan 2008 14:29:33 -0500 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 m0LJSrZW024656 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Mon, 21 Jan 2008 11:28:55 -0800 From: "Richard Shockey" To: , Date: Mon, 21 Jan 2008 14:29:13 -0500 Message-ID: <025e01c85c63$e8a22fc0$b9e68f40$@us> MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 Thread-Index: AcbidRrsdNW+DQs8QJaqMDsmeXxplw== Content-Language: en-us X-Spam-Score: -1.0 (-) X-Scan-Signature: a7d6aff76b15f3f56fcb94490e1052e4 Cc: 'Cullen Jennings' , =?US-ASCII?Q?'=22Patrik_Faltstrom=22'?= , "'Peterson, Jon'" Subject: [Enum] ENUM WG Request for Publication - draft-ietf-enum-softswitch-req-01.txt X-BeenThere: enum@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: richard@shockey.us List-Id: Enum Discussion List List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: enum-bounces@ietf.org This is a request for publication on one ENUM WG document. Title : ENUM-based Softswitch Requirement Author(s) : J. Lim, et al. Filename : draft-ietf-enum-softswitch-req-01.txt Pages : 17 Date : 2007-10-24 This document describes experiences of operational requirements and several considerations for ENUM-based softswitches concerning call routing between two Korean VoIP carriers, gained during the ENUM pre- commercial trial hosted by National Internet Development Agency of Korea (NIDA) in 2006. These experiences show that an interim solution can maintain the stability of on-going commercial softswitch system operations during the initial stage of ENUM service, where the DNS does not have sufficient data for the majority of calls. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-enum-softswitch-req-01.txt A two week WG last call on this document concluded on January 21. The document listed above is being considered for Informational status. This document has been extensively discussed during 2006-2007. 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://www1.ietf.org/mailman/listinfo/enum From enum-bounces@ietf.org Tue Jan 22 19:12:39 2008 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1JHTE3-0001Ms-Li; Tue, 22 Jan 2008 19:12:19 -0500 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1JHTE2-0001Mi-N6 for enum@ietf.org; Tue, 22 Jan 2008 19:12:18 -0500 Received: from mail.songbird.com ([208.184.79.10]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1JHTE2-0007xz-9J for enum@ietf.org; Tue, 22 Jan 2008 19:12:18 -0500 Received: from rshockeyPC ([12.8.180.122]) (authenticated bits=0) by mail.songbird.com (8.12.11.20060308/8.12.11) with ESMTP id m0N0BgiP016904 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO) for ; Tue, 22 Jan 2008 16:11:43 -0800 From: "Richard Shockey" To: Date: Tue, 22 Jan 2008 19:11:50 -0500 Message-ID: <0b1101c85d54$8edb6c80$ac924580$@us> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 12.0 thread-index: AchdVIzl0mwTyohrRSy2OnxfMA0Ylw== Content-Language: en-us X-Spam-Score: 0.0 (/) X-Scan-Signature: 7d33c50f3756db14428398e2bdedd581 Subject: [Enum] Agenda for philidelphia? X-BeenThere: enum@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Enum Discussion List List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: enum-bounces@ietf.org I looking over things I'm not sure we really need two hours. >From what we have is to finalize (once and for all) issues surrounding the enum registration document and 3761bis. Its going to be a tight fit for the RAI AD's so unless anyone can think of something else I'll attempt to modify our request to one 1 hour session only. 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://www1.ietf.org/mailman/listinfo/enum From enum-bounces@ietf.org Mon Jan 28 11:21:58 2008 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1JJWk0-0000gA-4E; Mon, 28 Jan 2008 11:21:48 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1JJWjz-0000g5-4U for enum@ietf.org; Mon, 28 Jan 2008 11:21:47 -0500 Received: from mail.songbird.com ([208.184.79.10]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1JJWjy-0003aq-OO for enum@ietf.org; Mon, 28 Jan 2008 11:21:47 -0500 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 m0SGL7GT013578 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO) for ; Mon, 28 Jan 2008 08:21:08 -0800 From: "Richard Shockey" To: References: <0b1101c85d54$8edb6c80$ac924580$@us> In-Reply-To: <0b1101c85d54$8edb6c80$ac924580$@us> Date: Mon, 28 Jan 2008 11:21:31 -0500 Message-ID: <025801c861c9$d856b120$89041360$@us> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: AchdVIzl0mwTyohrRSy2OnxfMA0YlwEdGcFg Content-Language: en-us X-Spam-Score: -1.0 (-) X-Scan-Signature: 08170828343bcf1325e4a0fb4584481c Subject: [Enum] Agenda for IETF 71 Philidelphia X-BeenThere: enum@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Enum Discussion List List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: enum-bounces@ietf.org As of this point we only have three items to discuss. A. RFC 3761bis revisions. B. Finalization of Enumservice registration procedure. C. New business? http://www.ietf.org/internet-drafts/draft-kaplan-enum-source-uri-00.txt If that is all we have I think we can wrap things up in one hour. Any thoughts? _______________________________________________ enum mailing list enum@ietf.org https://www1.ietf.org/mailman/listinfo/enum From enum-bounces@ietf.org Mon Jan 28 11:34:02 2008 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1JJWvj-0007Gz-7C; Mon, 28 Jan 2008 11:33:55 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1JJWvi-0007Gt-B0 for enum@ietf.org; Mon, 28 Jan 2008 11:33:54 -0500 Received: from pahula.nona.net ([193.80.224.123] helo=kahua.nona.net) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1JJWvg-0003kZ-PK for enum@ietf.org; Mon, 28 Jan 2008 11:33:54 -0500 Received: from [10.10.0.113] ([::ffff:83.136.33.3]) (AUTH: PLAIN axelm, TLS: TLSv1/SSLv3,256bits,AES256-SHA) by pahula with esmtp; Mon, 28 Jan 2008 17:33:50 +0100 id 0000C0DD.479E03EE.00005EDE Message-ID: <479E03E1.6010204@enum.at> Date: Mon, 28 Jan 2008 17:33:37 +0100 From: Alexander Mayrhofer Organization: enum.at GmbH User-Agent: Thunderbird 2.0.0.9 (Windows/20071031) MIME-Version: 1.0 To: enum@ietf.org Subject: Re: [Enum] Agenda for IETF 71 Philidelphia Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 52e1467c2184c31006318542db5614d5 X-BeenThere: enum@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Enum Discussion List List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: enum-bounces@ietf.org As of this point we only have three items to discuss. > A. RFC 3761bis revisions. > >B. Finalization of Enumservice registration procedure. > >C. New business? > >http://www.ietf.org/internet-drafts/draft-kaplan-enum-source-uri-00.txt > > >If that is all we have I think we can wrap things up in one hour. Any >thoughts? Well, I'd be _really_ happy if we can "finalize" the registration procedure - but as it seems now, the whole registration stuff is going into that document, and 3761bis will only contain a reference to that. I'm unsure whether discussion in the WG session itself would be productive - but i'd really appreciate if a few core WG members could commit themselves to a couple of bar discussion sessions about the registration process during IETF 71. The registration document might also change a lot once we see a first version of 3761bis. Besides that, the following things come to my mind: - Status of the infrastructure docs / discussion? Any words from IAB/IESG? - Status of the remaining WG docs? cheers alex _______________________________________________ enum mailing list enum@ietf.org https://www1.ietf.org/mailman/listinfo/enum From enum-bounces@ietf.org Mon Jan 28 14:46:24 2008 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1JJZvn-0001D6-MH; Mon, 28 Jan 2008 14:46:11 -0500 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1JJZvm-0001CX-45 for enum@ietf.org; Mon, 28 Jan 2008 14:46:10 -0500 Received: from mail.songbird.com ([208.184.79.10]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1JJZvl-0007GG-KH for enum@ietf.org; Mon, 28 Jan 2008 14:46:10 -0500 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 m0SJjP84029905 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Mon, 28 Jan 2008 11:45:27 -0800 From: "Richard Shockey" To: "'Alexander Mayrhofer'" , References: <479E03E1.6010204@enum.at> In-Reply-To: <479E03E1.6010204@enum.at> Subject: RE: [Enum] Agenda for IETF 71 Philidelphia Date: Mon, 28 Jan 2008 14:45:48 -0500 Message-ID: <076b01c861e6$62d99c60$288cd520$@us> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: Achhy36UNdEpJftrQc6abzu/V2j9nAAGehvA Content-Language: en-us X-Spam-Score: 0.0 (/) X-Scan-Signature: 8b431ad66d60be2d47c7bfeb879db82c Cc: "'Peterson, Jon'" X-BeenThere: enum@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Enum Discussion List List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: enum-bounces@ietf.org In line .. > Well, > > I'd be _really_ happy if we can "finalize" the registration procedure > - > but as it seems now, the whole registration stuff is going into that > document, and 3761bis will only contain a reference to that. I'm > unsure > whether discussion in the WG session itself would be productive - but > i'd really appreciate if a few core WG members could commit themselves > to a couple of bar discussion sessions about the registration process > during IETF 71. I would not have a problem with that. > > The registration document might also change a lot once we see a first > version of 3761bis. I would doubt that 3761 bis would trigger any substantive changes in the registration document but we will see. > > Besides that, the following things come to my mind: > > - Status of the infrastructure docs / discussion? Any words from > IAB/IESG? I have some information that we will know the status of the infrastructure documents before Philadelphia but the AD's have to address that ( Jon? )and they can render their opinions/decisions here on the list. We will not need to cover them in the WG meeting. The WG has done its job. > - Status of the remaining WG docs? Of course. > > cheers > > alex > > > > _______________________________________________ > enum mailing list > enum@ietf.org > https://www1.ietf.org/mailman/listinfo/enum _______________________________________________ enum mailing list enum@ietf.org https://www1.ietf.org/mailman/listinfo/enum From enuioqftc@yahoo.com Thu Jan 31 17:59:51 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 4724428C0D7 for ; Thu, 31 Jan 2008 17:59:51 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Amavis-Alert: BAD HEADER, Non-encoded 8-bit data (char AE hex): Subject: SALE 73% OFF on VIAGRA\256 \n X-Spam-Flag: YES X-Spam-Score: 81.992 X-Spam-Level: **************************************************************** X-Spam-Status: Yes, score=81.992 tagged_above=-999 required=5 tests=[BAYES_99=3.5, DRUGS_ERECTILE=1, DRUG_ED_CAPS=0.322, HTML_IMAGE_ONLY_20=1.546, HTML_MESSAGE=1, HTML_SHORT_LINK_IMG_3=0.001, MIME_8BIT_HEADER=0.3, MIME_HTML_ONLY=1.457, RCVD_IN_PBL=0.905, RCVD_IN_SORBS_DUL=0.877, SUBJECT_NEEDS_ENCODING=0.001, URIBL_BLACK=20, URIBL_JP_SURBL=10, URIBL_RHS_DOB=1.083, URIBL_SBL=20, URIBL_SC_SURBL=10, URIBL_WS_SURBL=10] X-Spam-Report: * 3.5 BAYES_99 BODY: Bayesian spam probability is 99 to 100% * [score: 1.0000] * 0.3 DRUG_ED_CAPS BODY: Mentions an E.D. drug * 1.5 HTML_IMAGE_ONLY_20 BODY: HTML: images with 1600-2000 bytes of words * 1.0 HTML_MESSAGE BODY: HTML included in message * 1.5 MIME_HTML_ONLY BODY: Message only has text/html MIME parts * 20 URIBL_BLACK Contains an URL listed in the URIBL blacklist * [URIs: swinhertare.com] * 10 URIBL_WS_SURBL Contains an URL listed in the WS SURBL blocklist * [URIs: swinhertare.com] * 10 URIBL_JP_SURBL Contains an URL listed in the JP SURBL blocklist * [URIs: swinhertare.com] * 10 URIBL_SC_SURBL Contains an URL listed in the SC SURBL blocklist * [URIs: swinhertare.com] * 1.1 URIBL_RHS_DOB Contains an URI of a new domain (Day Old Bread) * [URIs: swinhertare.com] * 0.9 RCVD_IN_SORBS_DUL RBL: SORBS: sent directly from dynamic IP address * [200.88.133.136 listed in dnsbl.sorbs.net] * 0.9 RCVD_IN_PBL RBL: Received via a relay in Spamhaus PBL * [200.88.133.136 listed in zen.spamhaus.org] * 20 URIBL_SBL Contains an URL listed in the SBL blocklist * [URIs: swinhertare.com] * 0.0 HTML_SHORT_LINK_IMG_3 HTML is very short with a linked image * 1.0 DRUGS_ERECTILE Refers to an erectile drug * 0.3 MIME_8BIT_HEADER Message header contains 8-bit character * 0.0 SUBJECT_NEEDS_ENCODING SUBJECT_NEEDS_ENCODING Received: from core3.amsl.com ([127.0.0.1]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id y0yqjcQawGAU for ; Thu, 31 Jan 2008 17:59:50 -0800 (PST) Received: from tdev133-136.codetel.net.do (tdev133-136.codetel.net.do [200.88.133.136]) by core3.amsl.com (Postfix) with SMTP id 02CA728C2DF for ; Thu, 31 Jan 2008 17:58:55 -0800 (PST) Content-Return: allowed X-Mailer: CME-V6.5.4.3; MSN Received: (qmail 25295 by uid 801); Thu, 31 Jan 2008 10:00:28 -0400 Message-Id: <20080131060028.25297.qmail@tdev133-136.codetel.net.do> To: Subject: ***SPAM*** 81.992 (5) SALE 73% OFF on =?iso-8859-1?Q?VIAGRA=AE?= From: MIME-Version: 1.0 Content-Type: text/html; charset="ISO-8859-1" Content-Transfer-Encoding: 7bit Date: Thu, 31 Jan 2008 17:58:55 -0800 (PST)


From zhdvmoymov368810@mail.yahoo.com.hk Thu Jan 31 21:48:59 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 B933E3A67FB for ; Thu, 31 Jan 2008 21:48:59 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: YES X-Spam-Score: 51.429 X-Spam-Level: *************************************************** X-Spam-Status: Yes, score=51.429 tagged_above=-999 required=5 tests=[AWL=-0.261, BAYES_99=3.5, CHARSET_FARAWAY_HEADER=3.2, DOS_OE_TO_MX=2.75, FH_RELAY_NODNS=1.451, FORGED_MUA_OUTLOOK=3.116, FORGED_OUTLOOK_HTML=0.001, FORGED_OUTLOOK_TAGS=0.001, HTML_IMAGE_ONLY_08=1.787, HTML_MESSAGE=1, HTML_MIME_NO_HTML_TAG=0.097, IP_LINK_PLUS=0.001, MANGLED_NAIL=2.3, MIME_8BIT_HEADER=0.3, MIME_HTML_ONLY=1.457, MISSING_MIMEOLE=0.001, MSOE_MID_WRONG_CASE=0.82, NORMAL_HTTP_TO_IP=0.001, RAZOR2_CF_RANGE_51_100=0.5, RAZOR2_CF_RANGE_E8_51_100=1.5, RAZOR2_CHECK=0.5, RCVD_IN_BL_SPAMCOP_NET=1.96, RCVD_IN_PBL=0.905, RDNS_NONE=0.1, RELAY_IS_221=2.222, TVD_SPACE_RATIO=2.219, URIBL_SBL=20, WEIRD_PORT=0.001] X-Spam-Report: * 3.5 BAYES_99 BODY: Bayesian spam probability is 99 to 100% * [score: 1.0000] * 2.2 RELAY_IS_221 RELAY_IS_221 * 1.5 FH_RELAY_NODNS We could not determine your Reverse DNS * 3.2 CHARSET_FARAWAY_HEADER A foreign language charset used in headers * 2.3 MANGLED_NAIL BODY: mangled nail * 0.0 NORMAL_HTTP_TO_IP URI: Uses a dotted-decimal IP address in URL * 0.0 IP_LINK_PLUS URI: Dotted-decimal IP address followed by CGI * 0.0 WEIRD_PORT URI: Uses non-standard port number for HTTP * 1.0 HTML_MESSAGE BODY: HTML included in message * 1.8 HTML_IMAGE_ONLY_08 BODY: HTML: images with 400-800 bytes of words * 2.2 TVD_SPACE_RATIO BODY: TVD_SPACE_RATIO * 1.5 MIME_HTML_ONLY BODY: Message only has text/html MIME parts * 1.5 RAZOR2_CF_RANGE_E8_51_100 Razor2 gives engine 8 confidence level * above 50% * [cf: 100] * 0.5 RAZOR2_CHECK Listed in Razor2 (http://razor.sf.net/) * 0.5 RAZOR2_CF_RANGE_51_100 Razor2 gives confidence level above 50% * [cf: 100] * 0.9 RCVD_IN_PBL RBL: Received via a relay in Spamhaus PBL * [221.213.16.126 listed in zen.spamhaus.org] * 20 URIBL_SBL Contains an URL listed in the SBL blocklist * [URIs: 219.84.167.230] * 2.0 RCVD_IN_BL_SPAMCOP_NET RBL: Received via a relay in bl.spamcop.net * [Blocked - see ] * 0.1 RDNS_NONE Delivered to trusted network by a host with no rDNS * 0.3 MIME_8BIT_HEADER Message header contains 8-bit character * 0.8 MSOE_MID_WRONG_CASE MSOE_MID_WRONG_CASE * 0.0 FORGED_OUTLOOK_HTML Outlook can't send HTML message only * 0.0 MISSING_MIMEOLE Message has X-MSMail-Priority, but no X-MimeOLE * 0.1 HTML_MIME_NO_HTML_TAG HTML-only message, but there is no HTML tag * 0.0 FORGED_OUTLOOK_TAGS Outlook can't send HTML in this format * 3.1 FORGED_MUA_OUTLOOK Forged mail pretending to be from MS Outlook * 2.8 DOS_OE_TO_MX Delivered direct to MX with OE headers * -0.3 AWL AWL: From: address is in the auto white-list Received: from core3.amsl.com ([127.0.0.1]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id i19VHFBvLndQ for ; Thu, 31 Jan 2008 21:48:59 -0800 (PST) Received: from yahoo.com.sg (unknown [221.213.16.126]) by core3.amsl.com (Postfix) with SMTP id 306C83A67AE for ; Thu, 31 Jan 2008 21:48:55 -0800 (PST) From: "GaoBO" Subject: ***SPAM*** 51.429 (5) =?Big5?B?r6yxeqZit3OquqRApn6ovbBduUK+7rNx?= To: enum-archive@ietf.org Content-Type: text/html Date: Fri, 1 Feb 2008 13:32:03 +0800 MIME-Version: 1.0 X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1158 Message-Id: <20080201054856.306C83A67AE@core3.amsl.com> enum-archive§A¦n!!!
 

¦n¤[¨Sµ¹±z¹q¸Ü¤F,¤µ¤Ñµ¹§A±H­Ó¯º¸Ü§a!!! 

·|»¡¸Ü£xÆxÄM 

¦³¤Ñ¦³£|¤H­n¥h¦Y¶º,¶i¥h®É¦³°¦·|»¡¸Ü£xÆNÄM,·|»¡:ÅwªïÆ[Á{,¥X¥h®É·|»¡:ÁÂÁÂÆ[Á{,¨º£|¤Hı£x«Ü¦nª±,´N¤@ª½¶i¶i¥X¥X,

ÆxÄM´N¤@ª½»¡:ÅwªïÆ[Á{.ÁÂÁÂÆ[Á{,¤§«áÆxÄM´N¥Í®ð£{,¥L´N¸ò¦ÑÁó»¡ :¦ÑÁ󦳤H¦bª±§A³¾ ....= =

«¢«¢!!!¦³·N«ä§a!!!°O±o¦³ªÅ¥´³q¹q¸Üµ¹§Ú®@!!!   LiLi

From vtx.vil@starhotels.it Thu Jan 31 23:06:43 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 199463A683F for ; Thu, 31 Jan 2008 23:06:43 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: YES X-Spam-Score: 28.417 X-Spam-Level: **************************** X-Spam-Status: Yes, score=28.417 tagged_above=-999 required=5 tests=[BAYES_99=3.5, FH_HELO_EQ_D_D_D_D=1.597, FH_HOST_EQ_D_D_D_D=0.765, FM_DDDD_TIMES_2=1.999, HELO_DYNAMIC_DHCP=1.398, HELO_DYNAMIC_IPADDR=2.426, HELO_EQ_CPE=0.5, HOST_EQ_CPE=0.979, NORMAL_HTTP_TO_IP=0.001, RAZOR2_CHECK=0.5, RCVD_BAD_ID=2.837, RCVD_ILLEGAL_IP=1.908, RCVD_IN_BL_SPAMCOP_NET=1.96, RCVD_IN_PBL=0.905, RCVD_IN_SORBS_DUL=0.877, RCVD_IN_XBL=3.033, RDNS_DYNAMIC=0.1, UNRESOLVED_TEMPLATE=3.132] X-Spam-Report: * 3.5 BAYES_99 BODY: Bayesian spam probability is 99 to 100% * [score: 1.0000] * 0.5 HELO_EQ_CPE HELO_EQ_CPE * 0.8 FH_HOST_EQ_D_D_D_D Host starts with d-d-d-d * 2.4 HELO_DYNAMIC_IPADDR Relay HELO'd using suspicious hostname (IP addr * 1) * 1.0 HOST_EQ_CPE HOST_EQ_CPE * 1.4 HELO_DYNAMIC_DHCP Relay HELO'd using suspicious hostname (DHCP) * 1.6 FH_HELO_EQ_D_D_D_D Helo is d-d-d-d * 2.8 RCVD_BAD_ID RCVD_BAD_ID * 3.1 UNRESOLVED_TEMPLATE Headers contain an unresolved template * 1.9 RCVD_ILLEGAL_IP Received: contains illegal IP address * 0.0 NORMAL_HTTP_TO_IP URI: Uses a dotted-decimal IP address in URL * 0.5 RAZOR2_CHECK Listed in Razor2 (http://razor.sf.net/) * 0.9 RCVD_IN_SORBS_DUL RBL: SORBS: sent directly from dynamic IP address * [74.64.117.172 listed in dnsbl.sorbs.net] * 0.9 RCVD_IN_PBL RBL: Received via a relay in Spamhaus PBL * [74.64.117.172 listed in zen.spamhaus.org] * 3.0 RCVD_IN_XBL RBL: Received via a relay in Spamhaus XBL * 2.0 RCVD_IN_BL_SPAMCOP_NET RBL: Received via a relay in bl.spamcop.net * [Blocked - see ] * 2.0 FM_DDDD_TIMES_2 Dual helo + host eq d_d_d_d * 0.1 RDNS_DYNAMIC Delivered to trusted network by host with * dynamic-looking rDNS Received: from core3.amsl.com ([127.0.0.1]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id eTxLQR3NJIGc for ; Thu, 31 Jan 2008 23:06:41 -0800 (PST) Received: from cpe-74-64-117-172.nyc.res.rr.com (cpe-74-64-117-172.nyc.res.rr.com [74.64.117.172]) by core3.amsl.com (Postfix) with SMTP id 7CC5A3A681E for ; Thu, 31 Jan 2008 23:06:39 -0800 (PST) Received: from [227.94.176.182] (helo=adfhx) by cpe-74-64-117-172.nyc.res.rr.com with smtp (Exim 4.62 (FreeBSD)) id 1JLX%E-0002i2-Lc; Fri, 1 Feb 2008 02:10:02 -0500 Message-ID: <47A2C5B4.1060202@starhotels.it> Date: Fri, 1 Feb 2008 02:09:40 -0500 From: User-Agent: Thunderbird 2.0.0.6 (Windows/20070728) MIME-Version: 1.0 To: enum-archive@ietf.org Subject: ***SPAM*** 28.417 (5) Wrapped in Your Arms Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit A Token of My Love http://220.122.46.197/ From arrington_to@flash.net Thu Jan 31 23:47:00 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 3FFAF3A6879; Thu, 31 Jan 2008 23:47:00 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: YES X-Spam-Score: 91.902 X-Spam-Level: **************************************************************** X-Spam-Status: Yes, score=91.902 tagged_above=-999 required=5 tests=[BAYES_99=3.5, BODY_ENHANCEMENT=0.309, BODY_ENHANCEMENT2=0.001, FH_RELAY_NODNS=1.451, HELO_MISMATCH_NET=0.611, MONEY_BACK=0.001, RAZOR2_CF_RANGE_51_100=0.5, RAZOR2_CF_RANGE_E8_51_100=1.5, RAZOR2_CHECK=0.5, RCVD_IN_BL_SPAMCOP_NET=1.96, RCVD_IN_DSBL=0.961, RCVD_IN_SORBS_WEB=0.619, RCVD_IN_XBL=3.033, RDNS_NONE=0.1, SARE_ADULT2=1.42, SARE_ENLRGYOUR=1.02, SARE_OBFU_PENIS_SUB=3.333, URIBL_AB_SURBL=10, URIBL_BLACK=20, URIBL_JP_SURBL=10, URIBL_OB_SURBL=10, URIBL_RHS_DOB=1.083, URIBL_SC_SURBL=10, URIBL_WS_SURBL=10] X-Spam-Report: * 3.5 BAYES_99 BODY: Bayesian spam probability is 99 to 100% * [score: 1.0000] * 1.5 FH_RELAY_NODNS We could not determine your Reverse DNS * 3.3 SARE_OBFU_PENIS_SUB subject has obfuscated spammer topic * 0.0 MONEY_BACK BODY: Money back guarantee * 0.3 BODY_ENHANCEMENT BODY: Information on growing body parts * 1.0 SARE_ENLRGYOUR BODY: Talks about "enlarging" something * 1.4 SARE_ADULT2 BODY: Contains adult material * 0.0 BODY_ENHANCEMENT2 BODY: Information on getting larger body parts * 1.5 RAZOR2_CF_RANGE_E8_51_100 Razor2 gives engine 8 confidence level * above 50% * [cf: 100] * 0.5 RAZOR2_CHECK Listed in Razor2 (http://razor.sf.net/) * 0.5 RAZOR2_CF_RANGE_51_100 Razor2 gives confidence level above 50% * [cf: 100] * 20 URIBL_BLACK Contains an URL listed in the URIBL blacklist * [URIs: gjoaawwe.com] * 10 URIBL_AB_SURBL Contains an URL listed in the AB SURBL blocklist * [URIs: gjoaawwe.com] * 10 URIBL_WS_SURBL Contains an URL listed in the WS SURBL blocklist * [URIs: gjoaawwe.com] * 10 URIBL_JP_SURBL Contains an URL listed in the JP SURBL blocklist * [URIs: gjoaawwe.com] * 10 URIBL_OB_SURBL Contains an URL listed in the OB SURBL blocklist * [URIs: gjoaawwe.com] * 10 URIBL_SC_SURBL Contains an URL listed in the SC SURBL blocklist * [URIs: gjoaawwe.com] * 1.1 URIBL_RHS_DOB Contains an URI of a new domain (Day Old Bread) * [URIs: gjoaawwe.com] * 3.0 RCVD_IN_XBL RBL: Received via a relay in Spamhaus XBL * [125.242.37.101 listed in zen.spamhaus.org] * 2.0 RCVD_IN_BL_SPAMCOP_NET RBL: Received via a relay in bl.spamcop.net * [Blocked - see ] * 0.6 RCVD_IN_SORBS_WEB RBL: SORBS: sender is a abuseable web server * [125.242.37.101 listed in dnsbl.sorbs.net] * 1.0 RCVD_IN_DSBL RBL: Received via a relay in list.dsbl.org * [] * 0.1 RDNS_NONE Delivered to trusted network by a host with no rDNS * 0.6 HELO_MISMATCH_NET HELO_MISMATCH_NET Received: from core3.amsl.com ([127.0.0.1]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JIffSNDyFp9p; Thu, 31 Jan 2008 23:46:59 -0800 (PST) Received: from usa.net (unknown [125.242.37.101]) by core3.amsl.com (Postfix) with ESMTP id 214983A6870; Thu, 31 Jan 2008 23:46:57 -0800 (PST) Date: Fri, 01 Feb 2008 06:50:12 +0000 Subject: ***SPAM*** 91.902 (5) Add up to 4 inches to yours penzis 78a MIME-Version: 1.0 Message-ID: <1201848612.7503@flash.net> From: "Shawna Arrington" To: enum@ietf.org, enum-admin@ietf.org, enum-archive@ietf.org, enum-request@ietf.org Content-Type: text/plain; charset="iso-8859-2" Content-Transfer-Encoding: 8bit Dear enum@ietf.org http://gjoaawwe.com Do you want Enlarge your Penis? » Gain 3+ Inches In Length. 100% Money Back Guarantee. » *3 FREE Bottles Of ManSter !! http://gjoaawwe.com Thanks Ann Moore enum@ietf.org wrote: > Add up to 4 inches to yours penis k13c1i18pf- out me now http://gjoaawwe.com/w.php