Return-Path: X-Original-To: peppermint-archive@optimus.ietf.org Delivered-To: ietfarch-peppermint-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 335FD3A6C06; Wed, 30 Jul 2008 19:51:28 -0700 (PDT) X-Original-To: peppermint@core3.amsl.com Delivered-To: peppermint@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 29F4D3A6A3B; Wed, 30 Jul 2008 19:51:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.099 X-Spam-Level: X-Spam-Status: No, score=-2.099 tagged_above=-999 required=5 tests=[AWL=0.150, BAYES_00=-2.599, HELO_EQ_DE=0.35] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zojYiyLeO2Mt; Wed, 30 Jul 2008 19:51:19 -0700 (PDT) Received: from moutng.kundenserver.de (moutng.kundenserver.de [212.227.126.187]) by core3.amsl.com (Postfix) with ESMTP id 793453A6898; Wed, 30 Jul 2008 19:51:16 -0700 (PDT) Received: from [172.16.10.191] ([130.129.65.91]) by mrelayeu.kundenserver.de (node=mrelayeu5) with ESMTP (Nemesis) id 0ML25U-1KOOGI293I-0000d8; Thu, 31 Jul 2008 04:51:31 +0200 Message-Id: <870CBC1E-0940-4F53-BF6F-52266410C03B@xconnect.net> From: David Schwartz To: "PFAUTZ, PENN L, ATTCORP" In-Reply-To: <217D89990A7AE44ABBC261434F79372859BF06@gaalpa1msgusr7a.ugd.att.com> Mime-Version: 1.0 (Apple Message framework v924) Date: Thu, 31 Jul 2008 03:51:29 +0100 References: <20080707170002.03A5E3A68D7@core3.amsl.com> <217D89990A7AE44ABBC261434F79372859BF06@gaalpa1msgusr7a.ugd.att.com> X-Mailer: Apple Mail (2.924) X-Provags-ID: V01U2FsdGVkX189u9oR+K2V0X+TXhU5hxvYvbcgFZzOg6PopP5 k6wLgMm8QWUuCci/ttPRU9shKXMhrPHW+cJ9D0coh9e4ps/C/D cqQJlR6MFcXn39Y4B+0Jw== Cc: drinks@ietf.org, peppermint@ietf.org Subject: Re: [PEPPERMINT] I-D Action:draft-ietf-drinks-cons-rqts-00.txt X-BeenThere: peppermint@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Provisioning Extensions in Peering Registries for Multimedia INTerconnection List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed"; DelSp="yes" Sender: peppermint-bounces@ietf.org Errors-To: peppermint-bounces@ietf.org Hi Penn - sorry for VERY late response on this :( inline... On Jul 7, 2008, at 8:04 PM, PFAUTZ, PENN L, ATTCORP wrote: > Some initial comments re this draft: > 1. Section 3.1 Index/Key Data states that "for lookup information > about > the most specific prefix will be returned." While this might be > desirable in some cases, I could image others where a larger set of > records might be desired. It also seems out of scope for DRINKS > since it > speaks to retrieval rather than provisioning. DS: Technically you are right. This is simply introduced to extract necessary information that may need to be provided to accommodate this retrieval. > > 2. I'm troubled by the "first hop" "last hop" provider terminology in > Section 3.2. The way it is used in this section seems to imply that > there is some VSP closer to the end user than the VSP assigned the > number prefix. This *might* be under some circumstances, e.g., where a > non-facilities based provider obtains its numbers through wholesale, > but > is not the most general case. If multiple VSP records are allowed then > it would seem some means of identifying which is which is required. DS: So now that I have thoroughly re-read all the drafts that are being presented tomorrow I am more convinced that this is correct. There is very little discussion about transit providers. The discussion that does exist (Debbie started going in the right direction on this, and the espp folks addressed this to some extent in a response to Otmar) centers around a transit provider being able to "use the system as well" to provision his stuff. Problem is, in most cases, its not "as well" but "in addition" necessitating conflict resolution provisioning data (which I did not see anyone define). This differentiation between "next hop" and "last hop" is meant to highlight this distinction. > > 3. w/r/t number portability info (Section 3.2) carrier code is only > one > type of NP info employed in the PSTN. Some more general terminology > should be employed. DS: Absolutely. In fact I am somewhat guilty as well of the common north american tilt on most of these documents. But your question only highlights in my mind the SCREAMING NEED for a terminology draft in DRINKS. Many of the things described in all documents are being referred to by proprietary names leading to mass confusion. Daryl - Please help !!! > > 4. Section 4 states that routing information is out of scope of the > registry provisioning problem. I'm not sure I agree. > In some arrangements routing information might well be expected to > come > from a Registry and so need to be provisioned. I believe a number of > existing private registries provide routing information today. The > information *might* be relatively dynamic but it might not. Perhaps I > misunderstand how the term "routing information" is intended here. DS: Here too I agree with you and in fact, Hadriel has an interesting draft on this. This doc was unfortunately not updated sufficiently by me prior to this IETF due to severe lack of time to work on this. We should discuss tomorrow. Thanks for comments. > > > > Penn Pfautz > AT&T National Access Management > +1-732-420-4962 > > _______________________________________________ > PEPPERMINT mailing list > PEPPERMINT@ietf.org > https://www.ietf.org/mailman/listinfo/peppermint _______________________________________________ PEPPERMINT mailing list PEPPERMINT@ietf.org https://www.ietf.org/mailman/listinfo/peppermint Return-Path: X-Original-To: peppermint-archive@optimus.ietf.org Delivered-To: ietfarch-peppermint-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E2FC93A6AD5; Mon, 14 Jul 2008 10:21:11 -0700 (PDT) X-Original-To: peppermint@core3.amsl.com Delivered-To: peppermint@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D8FA63A68C9; Mon, 14 Jul 2008 10:21:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.408 X-Spam-Level: X-Spam-Status: No, score=-2.408 tagged_above=-999 required=5 tests=[AWL=0.191, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9kwAfrMCvgpH; Mon, 14 Jul 2008 10:21:10 -0700 (PDT) Received: from mail.songbird.com (unknown [IPv6:2001:470:1:76:2c0:9fff:fe3e:4009]) by core3.amsl.com (Postfix) with ESMTP id 880453A6A3B; Mon, 14 Jul 2008 10:21:09 -0700 (PDT) Received: from rshockeyPC (neustargw.va.neustar.com [209.173.53.233]) (authenticated bits=0) by mail.songbird.com (8.12.11.20060308/8.12.11) with ESMTP id m6EHIU95006254 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Mon, 14 Jul 2008 10:18:46 -0700 From: "Richard Shockey" To: , Date: Mon, 14 Jul 2008 13:19:01 -0400 Message-ID: <153e01c8e5d5$c8b18110$5a148330$@us> MIME-Version: 1.0 X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: Acjl0PcADnrxea/hRpG8b4DXJXDorQABLDGw Content-Language: en-us X-SongbirdInformation: support@songbird.com for more information X-Songbird: Clean X-Songbird-From: richard@shockey.us Subject: [PEPPERMINT] FW: I-D Action:draft-mule-peppermint-espp-protocol-02.txt X-BeenThere: peppermint@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Provisioning Extensions in Peering Registries for Multimedia INTerconnection List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: peppermint-bounces@ietf.org Errors-To: peppermint-bounces@ietf.org -----Original Message----- From: i-d-announce-bounces@ietf.org [mailto:i-d-announce-bounces@ietf.org] On Behalf Of Internet-Drafts@ietf.org Sent: Monday, July 14, 2008 12:45 PM To: i-d-announce@ietf.org Subject: I-D Action:draft-mule-peppermint-espp-protocol-02.txt A New Internet-Draft is available from the on-line Internet-Drafts directories. Title : A Provisioning Protocol for ENUM-SIP Addressing Servers Author(s) : K. Cartwright, et al. Filename : draft-mule-peppermint-espp-protocol-02.txt Pages : 121 Date : 2008-07-14 This document defines a provisioning protocol for ENUM-SIP addressing servers. An ENUM-SIP addressing server is a host that acts as Lookup Function in session peering to determine the target domain of a given SIP request and it may also act as a Location Routing Function to develop the location of the SIP signaling entity in that target domain. This protocol allows SIP service providers to provision and manage session establishment data used by SIP network elements to route SIP sessions to the target destinations which may be served by the SIP service provider's own internal network or by a session peering partner. The data provisioned into an ENUM-SIP addressing server is queried by SIP entities using ENUM or SIP. This version of the protocol integrates comments received on the IETF peppermint and drinks mailing lists before July 2008. This document is an Internet-Draft and the protocol it describes is subject to technical changes that may make this version incompatible with future versions defined in Internet-Drafts. It is expected that the authors will continue to update this protocol based on the drinks working group requirements on the session establishment data. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-mule-peppermint-espp-protocol-02.t xt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. _______________________________________________ PEPPERMINT mailing list PEPPERMINT@ietf.org https://www.ietf.org/mailman/listinfo/peppermint Return-Path: X-Original-To: peppermint-archive@optimus.ietf.org Delivered-To: ietfarch-peppermint-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8938D28C2FF; Mon, 14 Jul 2008 10:07:23 -0700 (PDT) X-Original-To: peppermint@core3.amsl.com Delivered-To: peppermint@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id EC7F928C2FF; Mon, 14 Jul 2008 10:07:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.376 X-Spam-Level: X-Spam-Status: No, score=-2.376 tagged_above=-999 required=5 tests=[AWL=0.223, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xrvcGoF-qb4W; Mon, 14 Jul 2008 10:07:21 -0700 (PDT) Received: from mail.songbird.com (unknown [IPv6:2001:470:1:76:2c0:9fff:fe3e:4009]) by core3.amsl.com (Postfix) with ESMTP id D8D623A6B72; Mon, 14 Jul 2008 10:06:06 -0700 (PDT) Received: from rshockeyPC (neustargw.va.neustar.com [209.173.53.233]) (authenticated bits=0) by mail.songbird.com (8.12.11.20060308/8.12.11) with ESMTP id m6EH3laS029475 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Mon, 14 Jul 2008 10:04:03 -0700 From: "Richard Shockey" To: , Date: Mon, 14 Jul 2008 13:04:16 -0400 Message-ID: <107501c8e5d3$ba4ce1c0$2ee6a540$@us> MIME-Version: 1.0 X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: AcjlzZm2apBd1a+wThm5E+PZxvP8wwABf/pw Content-Language: en-us X-SongbirdInformation: support@songbird.com for more information X-Songbird: Clean X-Songbird-From: richard@shockey.us Subject: [PEPPERMINT] FW: I-D Action:draft-mule-peppermint-espp-requirements-01.txt X-BeenThere: peppermint@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Provisioning Extensions in Peering Registries for Multimedia INTerconnection List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: peppermint-bounces@ietf.org Errors-To: peppermint-bounces@ietf.org -----Original Message----- From: i-d-announce-bounces@ietf.org [mailto:i-d-announce-bounces@ietf.org] On Behalf Of Internet-Drafts@ietf.org Sent: Monday, July 14, 2008 12:15 PM To: i-d-announce@ietf.org Subject: I-D Action:draft-mule-peppermint-espp-requirements-01.txt A New Internet-Draft is available from the on-line Internet-Drafts directories. Title : Provisioning Protocol Requirements for ENUM-SIP Addressing Servers Author(s) : T. Creighton, J. Mule Filename : draft-mule-peppermint-espp-requirements-01.txt Pages : 18 Date : 2008-07-14 This document presents use cases and protocol requirements for provisioning ENUM-SIP addressing servers. The provisioned data is used by the addressing server to return session establishment data for SIP entities to route SIP requests to the target destinations. An ENUM-SIP addressing server acts as a Lookup Function in session peering to determine the target domain of a given SIP request. It may also act as a Location Routing Function to develop the location of the SIP signaling entity in the target domain. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-mule-peppermint-espp-requirements- 01.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. _______________________________________________ PEPPERMINT mailing list PEPPERMINT@ietf.org https://www.ietf.org/mailman/listinfo/peppermint Return-Path: X-Original-To: peppermint-archive@optimus.ietf.org Delivered-To: ietfarch-peppermint-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 7D2E528C11C; Thu, 10 Jul 2008 11:39:03 -0700 (PDT) X-Original-To: peppermint@core3.amsl.com Delivered-To: peppermint@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A079B3A6890; Thu, 10 Jul 2008 11:39:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zV5wfL4gUicT; Thu, 10 Jul 2008 11:39:00 -0700 (PDT) Received: from mail.ogud.com (hlid.ogud.com [66.92.146.160]) by core3.amsl.com (Postfix) with ESMTP id 306AC3A68D8; Thu, 10 Jul 2008 11:39:00 -0700 (PDT) Received: from [204.74.78.201] (mail.md.ogud.com [10.20.30.6]) by mail.ogud.com (8.13.1/8.13.1) with ESMTP id m6AId8CI003908; Thu, 10 Jul 2008 14:39:09 -0400 (EDT) (envelope-from Ed.Lewis@neustar.biz) Mime-Version: 1.0 Message-Id: In-Reply-To: <9AAEDF491EF7CA48AB587781B8F5D7C6012900C9@srvxchg3.cablelabs.com> References: <9AAEDF491EF7CA48AB587781B8F5D7C6012900C9@srvxchg3.cablelabs.com> Date: Thu, 10 Jul 2008 11:35:36 -0700 To: "Jean-Francois Mule" From: Edward Lewis Cc: drinks@ietf.org, peppermint@ietf.org, Edward Lewis Subject: Re: [PEPPERMINT] Comparison of Requirements Documents X-BeenThere: peppermint@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Provisioning Extensions in Peering Registries for Multimedia INTerconnection List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed" Sender: peppermint-bounces@ietf.org Errors-To: peppermint-bounces@ietf.org At 15:33 -0600 7/8/08, Jean-Francois Mule wrote: >> From: peppermint-bounces@ietf.org [mailto:peppermint- >> bounces@ietf.org] On Behalf Of Edward Lewis >> Sent: Monday, June 30, 2008 1:08 PM >> topics that included in both and where the two requirements had >> different emphasis. I don't think there is any outright >> contradiction between the two. > >I'm not sure what you meant by "different emphasis". "Different emphasis" refers to what is documented. For example, ESPP emphasizes file operations, the consolidated has a requirement that emphasizes individual transactions. Different emphasis is not different direction, not a conflict, but is a reflection (also) of what was chosen to be placed in the document. Neither requirement documents is all encompassing at this point, although the ESPP document is more mature and has an implementation to back it. >The ESPP protocol requirements were modeled after the NETCONF ones (at >least in terms of the document outline). That's not in the references of the ESPP document. >No. It should be possible to use a file-based mechanism to provision a >large amount of data for sunrise use cases. If you look at ESPP >closely, the concept of operations based on transactional records does >exist. Section 4.2 is "File", 4.1 is "Connection" but starts "The protocol MUST support a file-based, bulk delivery mechanism". Not to say ESPP does not do interactive - I don't see it in the requirements, at least not highlighted. Recall that the context here is the requirement document, not the protocol (document). >> this, >> as well as a hard coded limit on the size limit.) > >Implementations prevail. We came to the conclusion that to be testable, >those requirements better be bound in terms of how big of a file sent >via SCP a server must be able to accept and process. It also gives an >indication to sysadmins and operators for where they should not go in >file sizes. The idea is to split the files into multiples after a >certain limit. >I see nothing wrong with that, quite the contrary when you start to look >at code. My experience with hard limits is in the DNS protocol, as well as the address space in IPv6. In DNS there was a 512 byte limit in UDP message segments with no nod towards expandability until EDNS0 came along. The installed base of pre-EDNS0 code made the transition difficult. With IPv6, one of the things that could have made coexistence with IPv4 possible was to allow the address field to be variable length, or at least special case in a short address of 32 bits. Generalizing from these cases, hard limits in specs trigger flags in me - even if there is merit in the limit as stated. >> ESPP describes designing an efficient protocol, i.e., being able to >> apply one set of data to many numbers. (But when I boiled the >> requirements down, I didn't see this idea - maybe it was in the >> protocol.) > >Can you elaborate and quote text so we (authors of ESPP) can provide >more context. For example, the consolidated specs mention the "\1" shorthand. (On the other hand, ESPP strives to not be tied to NAPTR as consolidated assumes.) What is not in the ESPP requirements is any requirement that syntax of the updates accommodate rules/profiles/macros, call them what you will. Again, let me stress - I'm not saying ESPP lacks this, it's just not something I saw in the document. >ESPP goes into details about how each object in the DB is identified >with eID and oIDs, something Kent went over in a thread with Bob Walter >some time ago. The reason I cited the documents I commented on was to say "this is what I am talking about." I hope that the result of 'the thread you cite' makes it's way into the next document cycle. >> Consolidated explicitly mentions numbers being reassigned and the >> impact of that on database entries and responses. > >What is the requirement on the protocol here (as opposed to the >operational aspects of number reassignments)? For example, the dip requirements (and: >> Consolidated requires dip indications, temporal validity, number >> "ownership" and other ancillary data. ) >> It's obvious that the two teams that developed the documents had >> different emphasis on what to include in a list or requirements. > >Based on the above, this is not obvious to me. E.g., you mention that ESPP does interactive operations, not just file based, and that file based is for sunrise. This wasn't made apparent in the requirement document. In the Consolidated document, we did include more about interactive operations. That doesn't mean one (emphasis) is better than the other. It's just a measure of what is chosen to be put into words. >> Even with the ESPP requirements document being rather mature (as >> well as being accompanied by a protocol specification), there is a need >> to combine the two documents. > >That I agree with. All's well that ends well. -- -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Edward Lewis +1-571-434-5468 NeuStar Never confuse activity with progress. Activity pays more. _______________________________________________ PEPPERMINT mailing list PEPPERMINT@ietf.org https://www.ietf.org/mailman/listinfo/peppermint Return-Path: X-Original-To: peppermint-archive@optimus.ietf.org Delivered-To: ietfarch-peppermint-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 1B18328C1B8; Wed, 9 Jul 2008 13:59:13 -0700 (PDT) X-Original-To: peppermint@core3.amsl.com Delivered-To: peppermint@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 204803A69F4 for ; Tue, 8 Jul 2008 14:18:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id z1ZRCals1kqt for ; Tue, 8 Jul 2008 14:18:04 -0700 (PDT) Received: from exprod7og114.obsmtp.com (exprod7ob114.obsmtp.com [64.18.2.214]) by core3.amsl.com (Postfix) with ESMTP id C4BFD3A689C for ; Tue, 8 Jul 2008 14:18:02 -0700 (PDT) Received: from source ([64.89.228.228]) (using TLSv1) by exprod7ob114.postini.com ([64.18.6.12]) with SMTP; Tue, 08 Jul 2008 14:18:12 PDT Received: from webmail.nominum.com (webmail.nominum.com [64.89.228.50]) (using TLSv1 with cipher RC4-MD5 (128/128 bits)) (Client CN "webmail.nominum.com", Issuer "Go Daddy Secure Certification Authority" (verified OK)) by shell-ng.nominum.com (Postfix) with ESMTP id 3AA031A8203; Tue, 8 Jul 2008 14:18:12 -0700 (PDT) (envelope-from Ted.Lemon@nominum.com) Received: from exchange-01.WIN.NOMINUM.COM ([64.89.228.50]) by exchange-01.WIN.NOMINUM.COM ([64.89.228.50]) with mapi; Tue, 8 Jul 2008 14:18:11 -0700 From: Ted Lemon To: Jean-Francois Mule , "Ray.Bellis@nominet.org.uk" Date: Tue, 8 Jul 2008 14:18:09 -0700 Thread-Topic: [PEPPERMINT] Data model for "reachability data" and naming/terminology for group of addresses Thread-Index: AcjXm8RtuZYmIK/fS+aPfBbSQ+ncXAJojV7QAAB2HmA= Message-ID: <1A6237355F59494CB8CD9791D7F9D1D9059CF18E@exchange-01.WIN.NOMINUM.COM> References: <9AAEDF491EF7CA48AB587781B8F5D7C601216A72@srvxchg3.cablelabs.com> <9AAEDF491EF7CA48AB587781B8F5D7C6012900C4@srvxchg3.cablelabs.com> In-Reply-To: <9AAEDF491EF7CA48AB587781B8F5D7C6012900C4@srvxchg3.cablelabs.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US MIME-Version: 1.0 X-Mailman-Approved-At: Wed, 09 Jul 2008 13:59:12 -0700 Cc: "peppermint@ietf.org" Subject: Re: [PEPPERMINT] Data model for "reachability data" and naming/terminology for group of addresses X-BeenThere: peppermint@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Provisioning Extensions in Peering Registries for Multimedia INTerconnection List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: peppermint-bounces@ietf.org Errors-To: peppermint-bounces@ietf.org > I believe so. Would folks prefer Destination Group then? As a relative neophyte, it's more obvious to me what "Destination Group" means than what "Service Area" means. So I think it's somewhat preferable, although there's nothing fundamentally wrong with "Service Area." I think it's because "Destination Group" implies logical locality, whereas "Service Area" implies physical locality. _______________________________________________ PEPPERMINT mailing list PEPPERMINT@ietf.org https://www.ietf.org/mailman/listinfo/peppermint Return-Path: X-Original-To: peppermint-archive@optimus.ietf.org Delivered-To: ietfarch-peppermint-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 22F423A683F; Wed, 9 Jul 2008 08:27:24 -0700 (PDT) X-Original-To: peppermint@core3.amsl.com Delivered-To: peppermint@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id CEC153A69AA for ; Wed, 9 Jul 2008 08:27:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id aAwElhNlXBsm for ; Wed, 9 Jul 2008 08:27:21 -0700 (PDT) Received: from peregrine.verisign.com (peregrine.verisign.com [216.168.239.74]) by core3.amsl.com (Postfix) with ESMTP id BCBF23A683F for ; Wed, 9 Jul 2008 08:27:21 -0700 (PDT) Received: from dul1wnexcn02.vcorp.ad.vrsn.com (dul1wnexcn02.vcorp.ad.vrsn.com [10.170.12.139]) by peregrine.verisign.com (8.13.6/8.13.4) with ESMTP id m69FRdNs012396 for ; Wed, 9 Jul 2008 11:27:39 -0400 Received: from DUL1WNEXMB05.vcorp.ad.vrsn.com ([10.170.12.240]) by dul1wnexcn02.vcorp.ad.vrsn.com with Microsoft SMTPSVC(6.0.3790.3959); Wed, 9 Jul 2008 11:27:33 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Wed, 9 Jul 2008 11:27:32 -0400 Message-ID: In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: PEPPERMINT Digest, Vol 13, Issue 8 Thread-Index: AcjhP5XCawX84g/eTLqOhrCpbN3GCQAmBPoA From: "Cartwright, Kenneth" To: X-OriginalArrivalTime: 09 Jul 2008 15:27:33.0280 (UTC) FILETIME=[4EE3DA00:01C8E1D8] Subject: Re: [PEPPERMINT] PEPPERMINT Digest, Vol 13, Issue 8 X-BeenThere: peppermint@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Provisioning Extensions in Peering Registries for Multimedia INTerconnection List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: peppermint-bounces@ietf.org Errors-To: peppermint-bounces@ietf.org Fwiw, I like the term "Destination Group" as one to supplant what ESPP had labeled as a "Service Area". And the way that "Destination Group" is described by Ray tracks with the way that, I believe, ESPP defines and uses "Service Areas". Ken -----Original Message----- From: peppermint-bounces@ietf.org [mailto:peppermint-bounces@ietf.org] On Behalf Of peppermint-request@ietf.org Sent: Tuesday, July 08, 2008 5:14 PM To: peppermint@ietf.org Subject: PEPPERMINT Digest, Vol 13, Issue 8 Send PEPPERMINT mailing list submissions to peppermint@ietf.org To subscribe or unsubscribe via the World Wide Web, visit https://www.ietf.org/mailman/listinfo/peppermint or, via email, send a message with subject or body 'help' to peppermint-request@ietf.org You can reach the person managing the list at peppermint-owner@ietf.org When replying, please edit your Subject line so it is more specific than "Re: Contents of PEPPERMINT digest..." Today's Topics: 1. Re: Data model for "reachability data" and naming/terminology for group of addresses (Jean-Francois Mule) ---------------------------------------------------------------------- Message: 1 Date: Tue, 8 Jul 2008 15:13:53 -0600 From: "Jean-Francois Mule" Subject: Re: [PEPPERMINT] Data model for "reachability data" and naming/terminology for group of addresses To: Cc: peppermint@ietf.org Message-ID: <9AAEDF491EF7CA48AB587781B8F5D7C6012900C4@srvxchg3.cablelabs.com> Content-Type: text/plain; charset="us-ascii" Ray, Thank you for the comments and sorry for the delay in responding. More inline. Jean-Francois. Ray wrote: > Can you elaborate on what a "Service Area" / "Address Group" > actually is? It is basically a way to logically group user addresses that can be - reached via a given Signaling path Border Element (SBE), - reached via a domain from which SIP servers can be located (a la rfc3263) Folks often picture this by saying it is a group of users reachable via a common (SIP) 'route'. > In the UK for our Central Numbering Database we've developed a concept > of a "Destination Group" - that being all those numbers (or > destinations) > which are supposed to be routed identically. Is that the same thing? I believe so. Would folks prefer Destination Group then? > Note however that this does not mean that every originating carrier > has to route them to the same place as every other carrier. > > For example if Carrier A (a terminating carrier) has: > > DG1 = (a, b) > DG2 = (c, d) > > then originating Carrier B routes destinations in DG1 to a particular > interconnect, and routes DG2 to some other interconnect. However > Carrier C might have completely different interconnects with Carrier > A. > > In the UK model the actual interconnect addresses are private > information bilaterally agreed between carriers. > > kind regards, > > Ray ------------------------------ _______________________________________________ PEPPERMINT mailing list PEPPERMINT@ietf.org https://www.ietf.org/mailman/listinfo/peppermint End of PEPPERMINT Digest, Vol 13, Issue 8 ***************************************** _______________________________________________ PEPPERMINT mailing list PEPPERMINT@ietf.org https://www.ietf.org/mailman/listinfo/peppermint Return-Path: X-Original-To: peppermint-archive@optimus.ietf.org Delivered-To: ietfarch-peppermint-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B5C6D3A6979; Tue, 8 Jul 2008 15:38:34 -0700 (PDT) X-Original-To: peppermint@core3.amsl.com Delivered-To: peppermint@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 6B66B3A684B for ; Tue, 8 Jul 2008 15:38:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.413 X-Spam-Level: X-Spam-Status: No, score=-0.413 tagged_above=-999 required=5 tests=[AWL=0.050, BAYES_00=-2.599, HELO_EQ_MODEMCABLE=0.768, HOST_EQ_MODEMCABLE=1.368] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wbvBdEq9hdEJ for ; Tue, 8 Jul 2008 15:38:32 -0700 (PDT) Received: from ondar.cablelabs.com (ondar.cablelabs.com [192.160.73.61]) by core3.amsl.com (Postfix) with ESMTP id AEE0B3A6A9E for ; Tue, 8 Jul 2008 15:38:32 -0700 (PDT) Received: from kyzyl.cablelabs.com (kyzyl [10.253.0.7]) by ondar.cablelabs.com (8.14.2/8.14.2) with ESMTP id m68McgQc002532; Tue, 8 Jul 2008 16:38:42 -0600 Received: from srvxchg3.cablelabs.com (10.5.0.25) by kyzyl.cablelabs.com (F-Secure/fsigk_smtp/511/kyzyl.cablelabs.com); Tue, 8 Jul 2008 16:38:42 -0700 (MST) X-Virus-Status: clean(F-Secure/fsigk_smtp/511/kyzyl.cablelabs.com) X-Mimeole: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Tue, 8 Jul 2008 16:38:31 -0600 Message-ID: <9AAEDF491EF7CA48AB587781B8F5D7C6012900E8@srvxchg3.cablelabs.com> In-Reply-To: <1A6237355F59494CB8CD9791D7F9D1D9059CF18E@exchange-01.WIN.NOMINUM.COM> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [PEPPERMINT] Data model for "reachability data" andnaming/terminology for group of addresses Thread-Index: AcjXm8RtuZYmIK/fS+aPfBbSQ+ncXAJojV7QAAB2HmAAAq8zQA== References: <9AAEDF491EF7CA48AB587781B8F5D7C601216A72@srvxchg3.cablelabs.com> <9AAEDF491EF7CA48AB587781B8F5D7C6012900C4@srvxchg3.cablelabs.com> <1A6237355F59494CB8CD9791D7F9D1D9059CF18E@exchange-01.WIN.NOMINUM.COM> From: "Jean-Francois Mule" To: "Ted Lemon" X-Approved: ondar Cc: peppermint@ietf.org Subject: Re: [PEPPERMINT] Data model for "reachability data" andnaming/terminology for group of addresses X-BeenThere: peppermint@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Provisioning Extensions in Peering Registries for Multimedia INTerconnection List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: peppermint-bounces@ietf.org Errors-To: peppermint-bounces@ietf.org Ted wrote: > As a relative neophyte, it's more obvious to me what "Destination > Group" means than what "Service Area" means. So I think it's > somewhat preferable, although there's nothing fundamentally wrong > with "Service Area." I think it's because "Destination Group" > implies logical locality, whereas "Service Area" implies physical > locality. Yes. I would also note that this "Destination Group" is close to what Debbie Guyton in draft-guyton-drinks-registry-data-00.txt calls a "Dial Code to Destinations" for logical groupings of dial codes. Jean-Francois. _______________________________________________ PEPPERMINT mailing list PEPPERMINT@ietf.org https://www.ietf.org/mailman/listinfo/peppermint Return-Path: X-Original-To: peppermint-archive@optimus.ietf.org Delivered-To: ietfarch-peppermint-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 2FCFF3A677E; Tue, 8 Jul 2008 14:55:52 -0700 (PDT) X-Original-To: peppermint@core3.amsl.com Delivered-To: peppermint@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A4FC63A677E for ; Tue, 8 Jul 2008 14:55:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.388 X-Spam-Level: X-Spam-Status: No, score=-0.388 tagged_above=-999 required=5 tests=[AWL=0.075, BAYES_00=-2.599, HELO_EQ_MODEMCABLE=0.768, HOST_EQ_MODEMCABLE=1.368] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Ihc60DIhNBI6 for ; Tue, 8 Jul 2008 14:55:50 -0700 (PDT) Received: from ondar.cablelabs.com (ondar.cablelabs.com [192.160.73.61]) by core3.amsl.com (Postfix) with ESMTP id D95113A6767 for ; Tue, 8 Jul 2008 14:55:50 -0700 (PDT) Received: from kyzyl.cablelabs.com (kyzyl [10.253.0.7]) by ondar.cablelabs.com (8.14.2/8.14.2) with ESMTP id m68Ltpn3032038 for ; Tue, 8 Jul 2008 15:55:51 -0600 Received: from srvxchg3.cablelabs.com (10.5.0.25) by kyzyl.cablelabs.com (F-Secure/fsigk_smtp/511/kyzyl.cablelabs.com); Tue, 8 Jul 2008 15:55:51 -0700 (MST) X-Virus-Status: clean(F-Secure/fsigk_smtp/511/kyzyl.cablelabs.com) X-Mimeole: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Tue, 8 Jul 2008 15:55:38 -0600 Message-ID: <9AAEDF491EF7CA48AB587781B8F5D7C6012900D2@srvxchg3.cablelabs.com> In-Reply-To: <20080707170002.03A5E3A68D7@core3.amsl.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: I-D Action:draft-ietf-drinks-cons-rqts-00.txt Thread-Index: AcjgVCls3hU4Cbh4Sy2Oz4MLDYZuSQA8JxLA References: <20080707170002.03A5E3A68D7@core3.amsl.com> From: "Jean-Francois Mule" To: X-Approved: ondar Subject: Re: [PEPPERMINT] I-D Action:draft-ietf-drinks-cons-rqts-00.txt X-BeenThere: peppermint@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Provisioning Extensions in Peering Registries for Multimedia INTerconnection List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: peppermint-bounces@ietf.org Errors-To: peppermint-bounces@ietf.org The online diff tool shows that 6 lines have changed between draft-schwartz-peppermint-problem-statement-00.txt and draft-ietf-drinks-cons-rqts-00.txt: 6 lines... And if you remove the ID name change, the change in dates and a semi column lost somewhere, it comes down to zero change have exactly 6 lines. I thought we had a BoF in Philly and that some wg discussions happen between then and now. No other comments. Jean-Francois. > -----Original Message----- > From: i-d-announce-bounces@ietf.org [mailto:i-d-announce- > bounces@ietf.org] On Behalf Of Internet-Drafts@ietf.org > Sent: Monday, July 07, 2008 11:00 AM > To: i-d-announce@ietf.org > Cc: peppermint@ietf.org > Subject: I-D Action:draft-ietf-drinks-cons-rqts-00.txt > > A New Internet-Draft is available from the on-line Internet-Drafts > directories. > This draft is a work item of the Data for Reachability of > Inter/tra-NetworK SIP Working Group of the IETF. > > > Title : Consolidated Provisioning Problem Statement > Author(s) : D. Schwartz, et al. > Filename : draft-ietf-drinks-cons-rqts-00.txt > Pages : 12 > Date : 2008-07-07 > > This document describes the type of data provisioned among Voice > Service Providers and underscores the need for clearly defined > structures and interfaces to facilitate this provisioning. This > work > is in support of the service provider peering as defined by the > SPEERMINT WG. > > A URL for this Internet-Draft is: > http://www.ietf.org/internet-drafts/draft-ietf-drinks-cons-rqts- > 00.txt > > Internet-Drafts are also available by anonymous FTP at: > ftp://ftp.ietf.org/internet-drafts/ > > Below is the data which will enable a MIME compliant mail reader > implementation to automatically retrieve the ASCII version of the > Internet-Draft. _______________________________________________ PEPPERMINT mailing list PEPPERMINT@ietf.org https://www.ietf.org/mailman/listinfo/peppermint Return-Path: X-Original-To: peppermint-archive@optimus.ietf.org Delivered-To: ietfarch-peppermint-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 6A9B528C334; Tue, 8 Jul 2008 14:33:25 -0700 (PDT) X-Original-To: peppermint@core3.amsl.com Delivered-To: peppermint@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 6007C28C334; Tue, 8 Jul 2008 14:33:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.363 X-Spam-Level: X-Spam-Status: No, score=-0.363 tagged_above=-999 required=5 tests=[AWL=0.100, BAYES_00=-2.599, HELO_EQ_MODEMCABLE=0.768, HOST_EQ_MODEMCABLE=1.368] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id P-rOYJ8HzeXw; Tue, 8 Jul 2008 14:33:23 -0700 (PDT) Received: from ondar.cablelabs.com (ondar.cablelabs.com [192.160.73.61]) by core3.amsl.com (Postfix) with ESMTP id 55B5328C331; Tue, 8 Jul 2008 14:33:23 -0700 (PDT) Received: from kyzyl.cablelabs.com (kyzyl [10.253.0.7]) by ondar.cablelabs.com (8.14.2/8.14.2) with ESMTP id m68LXXQl030531; Tue, 8 Jul 2008 15:33:33 -0600 Received: from srvxchg3.cablelabs.com (10.5.0.25) by kyzyl.cablelabs.com (F-Secure/fsigk_smtp/511/kyzyl.cablelabs.com); Tue, 8 Jul 2008 15:33:33 -0700 (MST) X-Virus-Status: clean(F-Secure/fsigk_smtp/511/kyzyl.cablelabs.com) X-Mimeole: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Tue, 8 Jul 2008 15:33:21 -0600 Message-ID: <9AAEDF491EF7CA48AB587781B8F5D7C6012900C9@srvxchg3.cablelabs.com> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [PEPPERMINT] Comparison of Requirements Documents Thread-Index: Acja5LB75cQug5NbT2S3kRCAc5oCiwGWwB0Q References: From: "Jean-Francois Mule" To: "Edward Lewis" , , X-Approved: ondar Subject: Re: [PEPPERMINT] Comparison of Requirements Documents X-BeenThere: peppermint@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Provisioning Extensions in Peering Registries for Multimedia INTerconnection List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: peppermint-bounces@ietf.org Errors-To: peppermint-bounces@ietf.org Ed, See inline. Jean-Francois. > -----Original Message----- > From: peppermint-bounces@ietf.org [mailto:peppermint- > bounces@ietf.org] On Behalf Of Edward Lewis > Sent: Monday, June 30, 2008 1:08 PM > To: peppermint@ietf.org; drinks@ietf.org > Subject: [PEPPERMINT] Comparison of Requirements Documents > > I've been taking a look at two requirements documents, the ESPP > Requirements and the Consolidated Provisioning Statement. I > realize > (or have been told) that a new set of ESPP documents is coming out, > so I'll avoid getting into specifics. The goal is to have a > "Unified" (we've already used "Consolidated") requirements document > for the WG. > > BTW, the documents I'm comparing are these: > http://tools.ietf.org/html/draft-mule-peppermint-espp-requirements- > 00 > http://tools.ietf.org/html/draft-schwartz-peppermint-consolidated- > provisioning-problem-statement-00 > > This comparison list is not very detailed, I wanted to identify the > topics that included in both and where the two requirements had > different emphasis. I don't think there is any outright > contradiction between the two. I'm not sure what you meant by "different emphasis". > Both documents describe a protocol running over SOAP/XML, WDSL, TLS > and HTTP and being easily integrated into the current provisioning > systems. The ESPP protocol requirements were modeled after the NETCONF ones (at least in terms of the document outline). > Both recognize that there a telephone number (E164) to URI mapping > happening, with NAPTR as a major vehicle (but not sole vehicle). > > Both mention a need to make the transactions auditable, including > logs. > > Consolidated mentions multiple kinds of sources of data, ESPP > refers > to multiple clients. This could be interpreted as an equivalent > statement. > > ESPP explicitly states that operation is based on files (as opposed > to records). (I'd question the file name requirements based on No. It should be possible to use a file-based mechanism to provision a large amount of data for sunrise use cases. If you look at ESPP closely, the concept of operations based on transactional records does exist. > this, > as well as a hard coded limit on the size limit.) Implementations prevail. We came to the conclusion that to be testable, those requirements better be bound in terms of how big of a file sent via SCP a server must be able to accept and process. It also gives an indication to sysadmins and operators for where they should not go in file sizes. The idea is to split the files into multiples after a certain limit. I see nothing wrong with that, quite the contrary when you start to look at code. > ESPP describes designing an efficient protocol, i.e., being able to > apply one set of data to many numbers. (But when I boiled the > requirements down, I didn't see this idea - maybe it was in the > protocol.) Can you elaborate and quote text so we (authors of ESPP) can provide more context. > ESPP has a specific data model in mind (which is being discussed in > recent mail), and a capacity of the order of the size of the PSTN > number range(s). Again, the purpose of those things is just to give a number to give implementers an idea of the scale and performance requirements. > > ESPP includes some protocol maintenance stuff (versioning numbers). > > Consolidated has requirements on the database being addressable > (any element). ESPP goes into details about how each object in the DB is identified with eID and oIDs, something Kent went over in a thread with Bob Walter some time ago. > Consolidated explicitly includes prefixs (for ranges) and min/max > lengths. ESPP has TN ranges and LRNs which we agreed should be changed to prefix to make it more generally applicable. > Consolidated explicitly mentions numbers being reassigned and the > impact of that on database entries and responses. What is the requirement on the protocol here (as opposed to the operational aspects of number reassignments)? > Consolidated requires dip indications, temporal validity, number > "ownership" and other ancillary data. > > Consolidated requires a catchall record, a \1 shorthand. > > Consolidated has requirements on the transport as being end-to-end > only (no caching) and having flow control. > > It's obvious that the two teams that developed the documents had > different emphasis on what to include in a list or requirements. Based on the above, this is not obvious to me. > Even with the ESPP requirements document being rather mature (as > well > as being accompanied by a protocol specification), there is a need > to > combine the two documents. That I agree with. > I don't believe that the result will be > radically different from either, just more complete. > > > -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- > =-=-=-=- > Edward Lewis +1-571- > 434-5468 > NeuStar > > Never confuse activity with progress. Activity pays more. > > -- > -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- > =-=-=-=- > Edward Lewis +1-571- > 434-5468 > NeuStar > > Never confuse activity with progress. Activity pays more. > _______________________________________________ > PEPPERMINT mailing list > PEPPERMINT@ietf.org > https://www.ietf.org/mailman/listinfo/peppermint _______________________________________________ PEPPERMINT mailing list PEPPERMINT@ietf.org https://www.ietf.org/mailman/listinfo/peppermint Return-Path: X-Original-To: peppermint-archive@optimus.ietf.org Delivered-To: ietfarch-peppermint-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id EB35F3A6AF4; Tue, 8 Jul 2008 14:13:59 -0700 (PDT) X-Original-To: peppermint@core3.amsl.com Delivered-To: peppermint@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 33CBC3A6ABC for ; Tue, 8 Jul 2008 14:13:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.313 X-Spam-Level: X-Spam-Status: No, score=-0.313 tagged_above=-999 required=5 tests=[AWL=0.150, BAYES_00=-2.599, HELO_EQ_MODEMCABLE=0.768, HOST_EQ_MODEMCABLE=1.368] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KQel4vftkS9y for ; Tue, 8 Jul 2008 14:13:58 -0700 (PDT) Received: from ondar.cablelabs.com (ondar.cablelabs.com [192.160.73.61]) by core3.amsl.com (Postfix) with ESMTP id 767FD3A6AF4 for ; Tue, 8 Jul 2008 14:13:58 -0700 (PDT) Received: from kyzyl.cablelabs.com (kyzyl [10.253.0.7]) by ondar.cablelabs.com (8.14.2/8.14.2) with ESMTP id m68LE89I029081; Tue, 8 Jul 2008 15:14:08 -0600 Received: from srvxchg3.cablelabs.com (10.5.0.25) by kyzyl.cablelabs.com (F-Secure/fsigk_smtp/511/kyzyl.cablelabs.com); Tue, 8 Jul 2008 15:14:08 -0700 (MST) X-Virus-Status: clean(F-Secure/fsigk_smtp/511/kyzyl.cablelabs.com) X-Mimeole: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Tue, 8 Jul 2008 15:13:53 -0600 Message-ID: <9AAEDF491EF7CA48AB587781B8F5D7C6012900C4@srvxchg3.cablelabs.com> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [PEPPERMINT] Data model for "reachability data" and naming/terminology for group of addresses Thread-Index: AcjXm8RtuZYmIK/fS+aPfBbSQ+ncXAJojV7Q References: <9AAEDF491EF7CA48AB587781B8F5D7C601216A72@srvxchg3.cablelabs.com> From: "Jean-Francois Mule" To: X-Approved: ondar Cc: peppermint@ietf.org Subject: Re: [PEPPERMINT] Data model for "reachability data" and naming/terminology for group of addresses X-BeenThere: peppermint@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Provisioning Extensions in Peering Registries for Multimedia INTerconnection List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: peppermint-bounces@ietf.org Errors-To: peppermint-bounces@ietf.org Ray, Thank you for the comments and sorry for the delay in responding. More inline. Jean-Francois. Ray wrote: > Can you elaborate on what a "Service Area" / "Address Group" > actually is? It is basically a way to logically group user addresses that can be - reached via a given Signaling path Border Element (SBE), - reached via a domain from which SIP servers can be located (a la rfc3263) Folks often picture this by saying it is a group of users reachable via a common (SIP) 'route'. > In the UK for our Central Numbering Database we've developed a > concept of > a "Destination Group" - that being all those numbers (or > destinations) > which are supposed to be routed identically. Is that the same > thing? I believe so. Would folks prefer Destination Group then? > Note however that this does not mean that every originating carrier > has to > route them to the same place as every other carrier. > > For example if Carrier A (a terminating carrier) has: > > DG1 = (a, b) > DG2 = (c, d) > > then originating Carrier B routes destinations in DG1 to a > particular > interconnect, and routes DG2 to some other interconnect. However > Carrier > C might have completely different interconnects with Carrier A. > > In the UK model the actual interconnect addresses are private > information > bilaterally agreed between carriers. > > kind regards, > > Ray _______________________________________________ PEPPERMINT mailing list PEPPERMINT@ietf.org https://www.ietf.org/mailman/listinfo/peppermint Return-Path: X-Original-To: peppermint-archive@optimus.ietf.org Delivered-To: ietfarch-peppermint-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id EF2303A6A1C; Mon, 7 Jul 2008 12:06:12 -0700 (PDT) X-Original-To: peppermint@core3.amsl.com Delivered-To: peppermint@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 238883A6A1C for ; Mon, 7 Jul 2008 12:06:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.599 X-Spam-Level: X-Spam-Status: No, score=-106.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mCj7gqmxxtsj for ; Mon, 7 Jul 2008 12:06:10 -0700 (PDT) Received: from mail120.messagelabs.com (mail120.messagelabs.com [216.82.250.83]) by core3.amsl.com (Postfix) with ESMTP id 838A73A6AC4 for ; Mon, 7 Jul 2008 12:05:48 -0700 (PDT) X-VirusChecked: Checked X-Env-Sender: ppfautz@att.com X-Msg-Ref: server-15.tower-120.messagelabs.com!1215457524!11212477!1 X-StarScan-Version: 5.5.12.14.2; banners=-,-,- X-Originating-IP: [144.160.20.54] Received: (qmail 15553 invoked from network); 7 Jul 2008 19:05:27 -0000 Received: from sbcsmtp7.sbc.com (HELO mlpi135.enaf.sfdc.sbc.com) (144.160.20.54) by server-15.tower-120.messagelabs.com with AES256-SHA encrypted SMTP; 7 Jul 2008 19:05:27 -0000 Received: from enaf.sfdc.sbc.com (localhost.localdomain [127.0.0.1]) by mlpi135.enaf.sfdc.sbc.com (8.14.0/8.14.0) with ESMTP id m67J4tWC022726 for ; Mon, 7 Jul 2008 15:05:18 -0400 Received: from gaalpa1msgusr7a.ugd.att.com (gaalpa1msgusr7a.ugd.att.com [135.53.26.15]) by mlpi135.enaf.sfdc.sbc.com (8.14.0/8.14.0) with ESMTP id m67J48hT022075 for ; Mon, 7 Jul 2008 15:04:40 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Mon, 7 Jul 2008 15:04:27 -0400 Message-ID: <217D89990A7AE44ABBC261434F79372859BF06@gaalpa1msgusr7a.ugd.att.com> In-Reply-To: <20080707170002.03A5E3A68D7@core3.amsl.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [PEPPERMINT] I-D Action:draft-ietf-drinks-cons-rqts-00.txt thread-index: AcjgV3vwxY5USGDiTWWbSz3+E5tcqgAChzFw References: <20080707170002.03A5E3A68D7@core3.amsl.com> From: "PFAUTZ, PENN L, ATTCORP" To: Subject: Re: [PEPPERMINT] I-D Action:draft-ietf-drinks-cons-rqts-00.txt X-BeenThere: peppermint@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Provisioning Extensions in Peering Registries for Multimedia INTerconnection List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: peppermint-bounces@ietf.org Errors-To: peppermint-bounces@ietf.org Some initial comments re this draft: 1. Section 3.1 Index/Key Data states that "for lookup information about the most specific prefix will be returned." While this might be desirable in some cases, I could image others where a larger set of records might be desired. It also seems out of scope for DRINKS since it speaks to retrieval rather than provisioning. 2. I'm troubled by the "first hop" "last hop" provider terminology in Section 3.2. The way it is used in this section seems to imply that there is some VSP closer to the end user than the VSP assigned the number prefix. This *might* be under some circumstances, e.g., where a non-facilities based provider obtains its numbers through wholesale, but is not the most general case. If multiple VSP records are allowed then it would seem some means of identifying which is which is required. 3. w/r/t number portability info (Section 3.2) carrier code is only one type of NP info employed in the PSTN. Some more general terminology should be employed. 4. Section 4 states that routing information is out of scope of the registry provisioning problem. I'm not sure I agree. In some arrangements routing information might well be expected to come from a Registry and so need to be provisioned. I believe a number of existing private registries provide routing information today. The information *might* be relatively dynamic but it might not. Perhaps I misunderstand how the term "routing information" is intended here. Penn Pfautz AT&T National Access Management +1-732-420-4962 _______________________________________________ PEPPERMINT mailing list PEPPERMINT@ietf.org https://www.ietf.org/mailman/listinfo/peppermint Return-Path: X-Original-To: peppermint-archive@optimus.ietf.org Delivered-To: ietfarch-peppermint-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 283E83A6A1C; Mon, 7 Jul 2008 10:32:37 -0700 (PDT) X-Original-To: peppermint@ietf.org Delivered-To: peppermint@core3.amsl.com Received: by core3.amsl.com (Postfix, from userid 0) id 03A5E3A68D7; Mon, 7 Jul 2008 10:00:01 -0700 (PDT) From: Internet-Drafts@ietf.org To: i-d-announce@ietf.org Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 Message-Id: <20080707170002.03A5E3A68D7@core3.amsl.com> Date: Mon, 7 Jul 2008 10:00:02 -0700 (PDT) X-Mailman-Approved-At: Mon, 07 Jul 2008 10:32:35 -0700 Cc: peppermint@ietf.org Subject: [PEPPERMINT] I-D Action:draft-ietf-drinks-cons-rqts-00.txt X-BeenThere: peppermint@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Provisioning Extensions in Peering Registries for Multimedia INTerconnection List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: peppermint-bounces@ietf.org Errors-To: peppermint-bounces@ietf.org --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Data for Reachability of Inter/tra-NetworK SIP Working Group of the IETF. Title : Consolidated Provisioning Problem Statement Author(s) : D. Schwartz, et al. Filename : draft-ietf-drinks-cons-rqts-00.txt Pages : 12 Date : 2008-07-07 This document describes the type of data provisioned among Voice Service Providers and underscores the need for clearly defined structures and interfaces to facilitate this provisioning. This work is in support of the service provider peering as defined by the SPEERMINT WG. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-drinks-cons-rqts-00.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Message/External-body; name="draft-ietf-drinks-cons-rqts-00.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2008-07-07095704.I-D@ietf.org> --NextPart Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ PEPPERMINT mailing list PEPPERMINT@ietf.org https://www.ietf.org/mailman/listinfo/peppermint --NextPart-- Return-Path: X-Original-To: peppermint-archive@optimus.ietf.org Delivered-To: ietfarch-peppermint-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id F0E4F3A6970; Sat, 5 Jul 2008 11:08:16 -0700 (PDT) X-Original-To: peppermint@core3.amsl.com Delivered-To: peppermint@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 83A513A6970; Sat, 5 Jul 2008 11:08:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.486 X-Spam-Level: X-Spam-Status: No, score=-1.486 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_DE=0.35, SARE_RECV_BEZEQINT_B=0.763] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WL1-Fy04Nrnb; Sat, 5 Jul 2008 11:08:14 -0700 (PDT) Received: from moutng.kundenserver.de (moutng.kundenserver.de [212.227.126.171]) by core3.amsl.com (Postfix) with ESMTP id 8AA4D3A689F; Sat, 5 Jul 2008 11:08:11 -0700 (PDT) Received: from [10.0.1.198] (bzq-219-150-62.static.bezeqint.net [62.219.150.62]) by mrelayeu.kundenserver.de (node=mrelayeu5) with ESMTP (Nemesis) id 0ML25U-1KFCB70zpg-0006KO; Sat, 05 Jul 2008 20:08:11 +0200 Message-Id: From: David Schwartz To: "Richard Shockey" In-Reply-To: <0a3e01c8de02$e8a22360$b9e66a20$@us> Mime-Version: 1.0 (Apple Message framework v924) Date: Sat, 5 Jul 2008 21:08:08 +0300 References: <0a3e01c8de02$e8a22360$b9e66a20$@us> X-Mailer: Apple Mail (2.924) X-Provags-ID: V01U2FsdGVkX19ADM9/UvwGjfCm920JlerTDyGilGrEIwXQghu SvbBJgZFsXugJrAf8dwGCugvMgfu1vNJ5lyzy6NaXho7LJ2aOO +kaQNSS9ajLTjh4Uh6n0A== Cc: drinks@ietf.org, peppermint@ietf.org Subject: Re: [PEPPERMINT] [drinks] FW: I-D Action:draft-kaplan-drinks-lrf-requirements-00.txt X-BeenThere: peppermint@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Provisioning Extensions in Peering Registries for Multimedia INTerconnection List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed"; DelSp="yes" Sender: peppermint-bounces@ietf.org Errors-To: peppermint-bounces@ietf.org Can anyone provide me a link to the Session Location Routing Protocol (SLRP) Overview document mentioned in the informative references? Thanks, D. On Jul 4, 2008, at 9:21 PM, Richard Shockey wrote: > New agenda item... > > -----Original Message----- > From: i-d-announce-bounces@ietf.org [mailto:i-d-announce-bounces@ietf.org > ] > On Behalf Of Internet-Drafts@ietf.org > Sent: Friday, July 04, 2008 11:30 AM > To: i-d-announce@ietf.org > Subject: I-D Action:draft-kaplan-drinks-lrf-requirements-00.txt > > A New Internet-Draft is available from the on-line Internet-Drafts > directories. > > Title : Location Routing Function Requirements > Author(s) : H. Kaplan > Filename : draft-kaplan-drinks-lrf-requirements-00.txt > Pages : 7 > Date : 2008-07-04 > > This document describes the requirements for a Location Routing > Function > Protocol, for inter and intra-domain SIP session routing. > > A URL for this Internet-Draft is: > http://www.ietf.org/internet-drafts/draft-kaplan-drinks-lrf-requirements-00 > . > txt > > Internet-Drafts are also available by anonymous FTP at: > ftp://ftp.ietf.org/internet-drafts/ > > Below is the data which will enable a MIME compliant mail reader > implementation to automatically retrieve the ASCII version of the > Internet-Draft. > Content-Type: text/plain > Content-ID: <2008-07-04081839.I-D@ietf.org> > > _______________________________________________ > drinks mailing list > drinks@ietf.org > https://www.ietf.org/mailman/listinfo/drinks _______________________________________________ PEPPERMINT mailing list PEPPERMINT@ietf.org https://www.ietf.org/mailman/listinfo/peppermint Return-Path: X-Original-To: peppermint-archive@optimus.ietf.org Delivered-To: ietfarch-peppermint-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 3BD213A6B0F; Fri, 4 Jul 2008 11:24:40 -0700 (PDT) X-Original-To: peppermint@core3.amsl.com Delivered-To: peppermint@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 848793A6A6C; Fri, 4 Jul 2008 11:24:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7KBwWGIEMhRz; Fri, 4 Jul 2008 11:24:37 -0700 (PDT) Received: from mail.songbird.com (unknown [IPv6:2001:470:1:76:2c0:9fff:fe3e:4009]) by core3.amsl.com (Postfix) with ESMTP id 44C9A3A69D6; Fri, 4 Jul 2008 11:24:37 -0700 (PDT) Received: from rshockeyPC (h-68-165-240-38.mclnva23.covad.net [68.165.240.38]) (authenticated bits=0) by mail.songbird.com (8.12.11.20060308/8.12.11) with ESMTP id m64IL4Y7030320 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Fri, 4 Jul 2008 11:21:21 -0700 From: "Richard Shockey" To: Date: Fri, 4 Jul 2008 14:21:48 -0400 Message-ID: <0a3e01c8de02$e8a22360$b9e66a20$@us> MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="----=_NextPart_000_0A3F_01C8DDE1.61908360" X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: Acjd6sXCGY+xTXgMQQm3TELN69qNugAF/u7g Content-Language: en-us X-SongbirdInformation: support@songbird.com for more information X-Songbird: Clean X-Songbird-From: richard@shockey.us Cc: peppermint@ietf.org Subject: [PEPPERMINT] FW: I-D Action:draft-kaplan-drinks-lrf-requirements-00.txt X-BeenThere: peppermint@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Provisioning Extensions in Peering Registries for Multimedia INTerconnection List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: peppermint-bounces@ietf.org Errors-To: peppermint-bounces@ietf.org This is a multipart message in MIME format. ------=_NextPart_000_0A3F_01C8DDE1.61908360 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit New agenda item... -----Original Message----- From: i-d-announce-bounces@ietf.org [mailto:i-d-announce-bounces@ietf.org] On Behalf Of Internet-Drafts@ietf.org Sent: Friday, July 04, 2008 11:30 AM To: i-d-announce@ietf.org Subject: I-D Action:draft-kaplan-drinks-lrf-requirements-00.txt A New Internet-Draft is available from the on-line Internet-Drafts directories. Title : Location Routing Function Requirements Author(s) : H. Kaplan Filename : draft-kaplan-drinks-lrf-requirements-00.txt Pages : 7 Date : 2008-07-04 This document describes the requirements for a Location Routing Function Protocol, for inter and intra-domain SIP session routing. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-kaplan-drinks-lrf-requirements-00. txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. ------=_NextPart_000_0A3F_01C8DDE1.61908360 Content-Type: Message/External-body; name="draft-kaplan-drinks-lrf-requirements-00.txt" Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename="draft-kaplan-drinks-lrf-requirements-00.txt" Content-Type: text/plain Content-ID: <2008-07-04081839.I-D@ietf.org> ------=_NextPart_000_0A3F_01C8DDE1.61908360 Content-Type: text/plain; name="ATT02226.txt" Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename="ATT02226.txt" _______________________________________________ I-D-Announce mailing list I-D-Announce@ietf.org https://www.ietf.org/mailman/listinfo/i-d-announce Internet-Draft directories: http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt ------=_NextPart_000_0A3F_01C8DDE1.61908360 Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ PEPPERMINT mailing list PEPPERMINT@ietf.org https://www.ietf.org/mailman/listinfo/peppermint ------=_NextPart_000_0A3F_01C8DDE1.61908360-- Return-Path: X-Original-To: peppermint-archive@optimus.ietf.org Delivered-To: ietfarch-peppermint-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 91C9C3A693C; Thu, 3 Jul 2008 10:22:23 -0700 (PDT) X-Original-To: peppermint@core3.amsl.com Delivered-To: peppermint@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 446913A693C; Thu, 3 Jul 2008 10:22:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ps+wlDbCySZL; Thu, 3 Jul 2008 10:22:21 -0700 (PDT) Received: from mail.songbird.com (unknown [IPv6:2001:470:1:76:2c0:9fff:fe3e:4009]) by core3.amsl.com (Postfix) with ESMTP id 93A403A68D3; Thu, 3 Jul 2008 10:22:20 -0700 (PDT) Received: from rshockeyPC (neustargw.va.neustar.com [209.173.53.233]) (authenticated bits=0) by mail.songbird.com (8.12.11.20060308/8.12.11) with ESMTP id m63HJ2ro013703 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Thu, 3 Jul 2008 10:19:18 -0700 From: "Richard Shockey" To: Date: Thu, 3 Jul 2008 13:19:41 -0400 Message-ID: <00bc01c8dd31$0debeac0$29c3c040$@us> MIME-Version: 1.0 X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: AcjdMPrq3K8K/8RlQkCUP4shfApiRA== Content-Language: en-us X-SongbirdInformation: support@songbird.com for more information X-Songbird: Clean X-Songbird-From: richard@shockey.us Cc: peppermint@ietf.org Subject: [PEPPERMINT] FIRST cut at DRINKS agenda. X-BeenThere: peppermint@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Provisioning Extensions in Peering Registries for Multimedia INTerconnection List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: peppermint-bounces@ietf.org Errors-To: peppermint-bounces@ietf.org IETF 72 DRINKS Agenda Data for Reachability of Inter/tra-NetworK SIP (drinks) Chair(s): Richard Shockey richard.shockey@neustar.biz Alexander Mayrhofer WG Secretary TBD .. RAI Director(s): Jon Peterson jon.peterson@neustar.biz Cullen Jennings fluffy@cisco.com RAI Area Advisor: Jon Peterson jon.peterson@neustar.biz Agenda Bashing. 1. Discussion of Consolidated Requirements Documents. 2. Revised ESPP documents 3. Contribution from Debbie Guyton Telcordia .. ******************************************** Approved DRINKS WG Charter : The IETF has been working on various aspects of SIP-enabled Multimedia administrative domains among SIP Service Providers (SSP's). SSP's are entities that provide session services utilizing SIP signaling to their customers. In addition, the IETF has done significant work on data exchanges among various network elements. The ENUM and SPEERMINT working groups provide the underlying context for much of the intended work that the DRINKS working group will undertake. The ENUM working group is specifically chartered to develop protocols that involve the translation of E.164 numbers to URIs. While the SPEERMINT working group has been chartered to develop requirements and best current practices among real-time application SSPs and to describe how such services may best interconnect across administrative boundaries. Specifically, DRINKS will provide details of how Session Establishment Data (SED) is collected, what comprises SED, how SED should be used to properly identify an optimal path to a destination SIP user agent (UA), either internally or externally to the SSP. For the initial iteration of this charter, the SED data is assumed to be fields that might be provisioned for ENUM, with limited exceptions. If the working group would like to work on data types unrelated to ENUM registries and databases, the WG will recharter. In addition DRINKS will ensure that the SED and the SIP session data securely exchanged between the peering functions. Typical SED data might include: + Routes - Destination SIP/SIPS/TEL URI Egress and Ingress Routes - Relevant route names, identifiers, and services - Attributes affecting route selection - PSTN database information + Targets - Individual, ranges, or groups of user-agent identifiers - Target aggregation entities (e.g. service areas) and target-to-aggregate associations + Treatment Profiles - Priority - Location Potential SED Data types not in scope will be session rating or other billing or pricing information between SSP's. It is also recognized that peering relationships become more complex as multiple peers are added to a common relationship; these complex aspects and requirements are defined within the contexts of a peering Federation. The DRINKS working group is chartered with a scope that is orthogonal to SPEERMINT and ENUM. The protocol work of DRINKS will be designed to build from the work of SPEERMINT and ENUM to identify and define the data structures and data exchange protocol(s) among SIP based Multimedia administrative domains. These administrative domains may be of any practical size and could be any type of SSP, such as recognized telephony carriers, enterprises, end-user groups, or Federations. Data exchanges among these administrative domains may be bi-lateral or multi-lateral in nature, and could include bulk updates and/or more granular real-time updates. Administrative domains may exchange data directly between each other or might use an external registry to aggregate data from multiple administrative domains or multiple data providers into a single view. The working group will draw upon expert advice and on-going consultation from the ENUM and SPEERMINT working groups, and also the XML Directorate. The working group will consider the reuse of elements of RFC 4114. The final work product(s) from this working group will utilize and be based on XML documents and XML document exchanges. GOALS AND MILESTONES Nov 08 - WGLC for Requirements for Session Establishment Data (SED) data exchanges (Proposed Standard). Dec 08 - IESG Submission for Requirements for Session Establishment Data (SED) data exchanges. Jan 09 - WGLC for Exchanging of Session Establishment Data (SED) from data providers to registries or between bi/multi-lateral partners (Proposed standard). Feb 09 IESG Submission for Exchanging of Session Establishment Data (SED) from data providers to registries or between bi/multi-lateral partners. Mar 09 - WGLC for Exchange of Session Establishment Data (SED) from registries to Location Routing Function databases (Proposed Status). Apr 09 - IESG Submission for Exchange of Session Establishment Data (SED) from registries to Location Routing Function databases. 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 _______________________________________________ PEPPERMINT mailing list PEPPERMINT@ietf.org https://www.ietf.org/mailman/listinfo/peppermint Return-Path: X-Original-To: peppermint-archive@optimus.ietf.org Delivered-To: ietfarch-peppermint-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id BDC723A6AEB; Thu, 3 Jul 2008 10:18:40 -0700 (PDT) X-Original-To: peppermint@core3.amsl.com Delivered-To: peppermint@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 2CA613A6833; Thu, 3 Jul 2008 10:18:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gTrAQn-k8JVk; Thu, 3 Jul 2008 10:18:38 -0700 (PDT) Received: from mail.songbird.com (unknown [IPv6:2001:470:1:76:2c0:9fff:fe3e:4009]) by core3.amsl.com (Postfix) with ESMTP id 0D0283A69A7; Thu, 3 Jul 2008 10:18:37 -0700 (PDT) Received: from rshockeyPC (neustargw.va.neustar.com [209.173.53.233]) (authenticated bits=0) by mail.songbird.com (8.12.11.20060308/8.12.11) with ESMTP id m63HFu5H011702 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Thu, 3 Jul 2008 10:16:12 -0700 From: "Richard Shockey" To: "'IETF ENUM WG'" , , Date: Thu, 3 Jul 2008 13:16:36 -0400 Message-ID: <00bb01c8dd30$9f21cba0$dd6562e0$@us> MIME-Version: 1.0 X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: AcjdMIwsKUuNx9DXQEujyZptauCWzQ== Content-Language: en-us X-SongbirdInformation: support@songbird.com for more information X-Songbird: Clean X-Songbird-From: richard@shockey.us Subject: [PEPPERMINT] REMINDER ... Internet DRAFT cut off dates... X-BeenThere: peppermint@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Provisioning Extensions in Peering Registries for Multimedia INTerconnection List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: peppermint-bounces@ietf.org Errors-To: peppermint-bounces@ietf.org July 7, Monday - Internet Draft Cut-off for initial document (-00) submission by 17:00 PDT (24:00 UTC/GMT), upload using IETF ID Submission Tool. July 14, Monday - Internet Draft final submission cut-off by 17:00 PDT (24:00 UTC/GMT), upload using IETF ID Submission Tool. 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 _______________________________________________ PEPPERMINT mailing list PEPPERMINT@ietf.org https://www.ietf.org/mailman/listinfo/peppermint Return-Path: X-Original-To: peppermint-archive@optimus.ietf.org Delivered-To: ietfarch-peppermint-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B467A3A6D15; Thu, 3 Jul 2008 10:02:04 -0700 (PDT) X-Original-To: peppermint@core3.amsl.com Delivered-To: peppermint@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E4D5B3A6D05; Thu, 3 Jul 2008 10:02:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zo9mnqVet-Nu; Thu, 3 Jul 2008 10:02:03 -0700 (PDT) Received: from mail.songbird.com (unknown [IPv6:2001:470:1:76:2c0:9fff:fe3e:4009]) by core3.amsl.com (Postfix) with ESMTP id 8CE6D3A6D0E; Thu, 3 Jul 2008 10:01:30 -0700 (PDT) Received: from rshockeyPC (h-68-165-240-38.mclnva23.covad.net [68.165.240.38]) (authenticated bits=0) by mail.songbird.com (8.12.11.20060308/8.12.11) with ESMTP id m5SM5Zff028585 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Sat, 28 Jun 2008 15:05:52 -0700 From: "Richard Shockey" To: References: In-Reply-To: Date: Sat, 28 Jun 2008 18:06:10 -0400 Message-ID: <139201c8d96b$46f1f810$d4d5e830$@us> MIME-Version: 1.0 X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: AcjYdgYC1riHqF76S5qVo/SKKZ4p1wA9R3yQ Content-Language: en-us X-SongbirdInformation: support@songbird.com for more information X-Songbird: Clean X-Songbird-From: richard@shockey.us Cc: peppermint@ietf.org Subject: Re: [PEPPERMINT] test test test X-BeenThere: peppermint@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Provisioning Extensions in Peering Registries for Multimedia INTerconnection List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: peppermint-bounces@ietf.org Errors-To: peppermint-bounces@ietf.org > -----Original Message----- > From: Richard Shockey [mailto:richard@shockey.us] > Sent: Friday, June 27, 2008 12:51 PM > To: 'drinks@ietf.org' > Cc: 'peppermint@ietf.org' > Subject: test test test > > This is a test of the new list please ignore. > > 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 > > > _______________________________________________ PEPPERMINT mailing list PEPPERMINT@ietf.org https://www.ietf.org/mailman/listinfo/peppermint