Return-Path: X-Original-To: peppermint-archive@optimus.ietf.org Delivered-To: ietfarch-peppermint-archive@core3.amsl.com Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id BEB3528C25A; Mon, 31 Mar 2008 20:06: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 3A9E428C202 for ; Mon, 31 Mar 2008 20:06:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.709 X-Spam-Level: X-Spam-Status: No, score=-1.709 tagged_above=-999 required=5 tests=[AWL=0.890, 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 JO1Da7XQu9io for ; Mon, 31 Mar 2008 20:06:12 -0700 (PDT) Received: from etmail.acmepacket.com (etmail.acmepacket.com [216.41.24.6]) by core3.amsl.com (Postfix) with ESMTP id 7370428C116 for ; Mon, 31 Mar 2008 20:06:07 -0700 (PDT) Received: from mail.acmepacket.com (216.41.24.7) by etmail.acmepacket.com (216.41.24.6) with Microsoft SMTP Server (TLS) id 8.1.240.5; Mon, 31 Mar 2008 23:05:39 -0400 Received: from mail.acmepacket.com ([216.41.24.7]) by mail.acmepacket.com ([216.41.24.7]) with mapi; Mon, 31 Mar 2008 23:05:39 -0400 From: Hadriel Kaplan To: Daryl Malas , "peppermint@ietf.org" Date: Mon, 31 Mar 2008 23:01:11 -0400 Thread-Topic: [PEPPERMINT] Proposed Updated Charter Thread-Index: AciTaz5+nL5X5hseRkSarzcft2yW4AAM15yg Message-ID: References: <160DE07A1C4F8E4AA2715DEC577DA49193647C@srvxchg3.cablelabs.com> In-Reply-To: <160DE07A1C4F8E4AA2715DEC577DA49193647C@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 Subject: Re: [PEPPERMINT] Proposed Updated Charter 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 Hey Daryl, Looks pretty good! Minor comments inline... > -----Original Message----- > From: peppermint-bounces@ietf.org [mailto:peppermint-bounces@ietf.org] On > Behalf Of Daryl Malas > ------------------------------------- > New revision: > > PROPOSED CHARTER FOR PEPPERMINT > > The IETF has been working on various aspects of session-based Multimedia > peering among SIP Service Providers (SSPs), 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 following working groups' work provides > the underlying context for much of the intended work within this > charter: > > ENUM, which is specifically chartered to develop protocols that involve > the translation of E.164 numbers to URIs. > > SPEERMINT, which has been chartered to develop requirements and best > current practices among real-time application SSPs and how such services > may interconnect across administrative boundaries. This work will > provide details of how Session Establishment Data (SED) is collected and > what this data is comprised of, the use of this data to properly > identify an optimal path to the destination user agent (UA), and the > secure manners in which this and the SIP session data is exchanged > between all of the peering functions. It is also recognizes peering > relationships become more complex as multiple peers are added to a > common relationship, these complex aspects and requirements of multiple, > yet common peering relationships are defined with the contexts of a > peering Federation. There are some grammatical errors in the last sentence above. I think you want to say: "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." Having said that, I'm not actually sure I agree with it. Just because I peer with Foo, and Foo peers with Bar, does not mean I and Bar are in a common Federation nor have a common relationship, except for that we're both peers of Foo. In other words I'm not convinced all relationships are transitive. Take, for example, an SSP X in Israel peering with SSP Y in Egypt, who peers with SSP Z in Iran. > The PEPPERMINT working group is chartered to define what data needs to > be exchanged among Multimedia administrative domains, and how that data Maybe change it to "SIP Multimedia administrative domains..."? > should be structured, provisioned, and propagated. These protocols would > be outside the normal scope of establishing various forms of a SIP > session. These administrative domains are of any practical size and > could be any type of SSP, such as recognized telephony carriers, > enterprises, end-user groups, and Federations. > > Data exchanges to facilitate session-based Multimedia Interconnection > are typically between various bilateral or multilateral client User > Agents and related Registries. I'm not sure I understand why the term "client User Agents" is used? A Proxy is not a User Agent, and neither is an ENUM server, for example. Or do you just mean it's a User Agent with respect to being the Agent of the data exchange? > Data exchanges could include bulk data > and/or real time updates. Typical data includes mappings of phone > numbers to URIs, policies surrounding admission to various points of > network interconnection, and various types of interconnect data. In > addition, there is a specific need for the exchange of such data between > the Registry and various types of network databases (e.g. Local Number > Portability (LNP), Calling Name (CNAM), etc.). > > 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, if possible. > > The final work product(s) from this working group will utilize and be > based on XML documents and XML document exchanges. > > --------------------------------------- > > Thanks...--Daryl > > > _______________________________________________ > 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 core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 12BF43A6961; Mon, 31 Mar 2008 19:26: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 C89E93A691E for ; Mon, 31 Mar 2008 19:26:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.599 X-Spam-Level: X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5AdKGVAFyBiu for ; Mon, 31 Mar 2008 19:26:21 -0700 (PDT) Received: from mail.songbird.com (mail.songbird.com [208.184.79.10]) by core3.amsl.com (Postfix) with ESMTP id C0D623A683F for ; Mon, 31 Mar 2008 19:26:20 -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 m312PJwE030304 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Mon, 31 Mar 2008 18:25:21 -0800 From: "Richard Shockey" To: "'DOLLY, MARTIN C, ATTLABS'" , References: <160DE07A1C4F8E4AA2715DEC577DA49193647C@srvxchg3.cablelabs.com> <28F05913385EAC43AF019413F674A0171246ED86@OCCLUST04EVS1.ugd.att.com> In-Reply-To: <28F05913385EAC43AF019413F674A0171246ED86@OCCLUST04EVS1.ugd.att.com> Date: Mon, 31 Mar 2008 22:25:47 -0400 Message-ID: <08ca01c8939f$b36a4b30$1a3ee190$@us> MIME-Version: 1.0 X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: AciTaz5+nL5X5hseRkSarzcft2yW4AALIH5QAAG9IjA= Content-language: en-us X-SongbirdInformation: support@songbird.com for more information X-Songbird: Clean X-Songbird-From: richard@shockey.us Subject: Re: [PEPPERMINT] Proposed Updated Charter 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 You are correct we did agree that for the time being this potential application was out of scope for the charter, or is it? I believe there was consensus that the first order charter would deal principally with SSP to Registry and Registry to localized cached servers. Is that your understanding as well? So If I understand this correctly your problem is with .. In line .. Please indicate what part of the text is objectionable etc or propose alternative text. In other words is a enterprise a SSP? Inquiring minds want to know. :-) > New revision: > > PROPOSED CHARTER FOR PEPPERMINT > > The IETF has been working on various aspects of session-based > Multimedia > peering among SIP Service Providers (SSPs), 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 following working groups' work provides > the underlying context for much of the intended work within this > charter: > > ENUM, which is specifically chartered to develop protocols that > involve > the translation of E.164 numbers to URIs. > > SPEERMINT, which has been chartered to develop requirements and best > current practices among real-time application SSPs and how such > services > may interconnect across administrative boundaries. This work will > provide details of how Session Establishment Data (SED) is collected > and > what this data is comprised of, the use of this data to properly > identify an optimal path to the destination user agent (UA), and the > secure manners in which this and the SIP session data is exchanged > between all of the peering functions. It is also recognizes peering > relationships become more complex as multiple peers are added to a > common relationship, these complex aspects and requirements of > multiple, > yet common peering relationships are defined with the contexts of a > peering Federation. > > The PEPPERMINT working group is chartered to define what data needs to > be exchanged among Multimedia administrative domains, and how that > data > should be structured, provisioned, and propagated. These protocols > would > be outside the normal scope of establishing various forms of a SIP > session. These administrative domains are of any practical size and > could be any type of SSP, such as recognized telephony carriers, > enterprises, end-user groups, and Federations. ^^^^^^^^^^^^^^^^^^^^^ Here..???? > > Data exchanges to facilitate session-based Multimedia Interconnection > are typically between various bilateral or multilateral client User > Agents and related Registries. Data exchanges could include bulk data > and/or real time updates. Typical data includes mappings of phone > numbers to URIs, policies surrounding admission to various points of > network interconnection, and various types of interconnect data. In > addition, there is a specific need for the exchange of such data > between > the Registry and various types of network databases (e.g. Local Number > Portability (LNP), Calling Name (CNAM), etc.). > > 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, if possible. > > The final work product(s) from this working group will utilize and be > based on XML documents and XML document exchanges. > > --------------------------------------- > > Thanks...--Daryl > > > _______________________________________________ > 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 _______________________________________________ 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 core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E50C73A693B; Mon, 31 Mar 2008 19:22:54 -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 3E16B3A68BF for ; Mon, 31 Mar 2008 19:22:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.676 X-Spam-Level: X-Spam-Status: No, score=-1.676 tagged_above=-999 required=5 tests=[AWL=0.923, 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 X1K+N38yLjKK for ; Mon, 31 Mar 2008 19:22:53 -0700 (PDT) Received: from etmail.acmepacket.com (etmail.acmepacket.com [216.41.24.6]) by core3.amsl.com (Postfix) with ESMTP id E8B853A693B for ; Mon, 31 Mar 2008 19:22:52 -0700 (PDT) Received: from mail.acmepacket.com (216.41.24.7) by etmail.acmepacket.com (216.41.24.6) with Microsoft SMTP Server (TLS) id 8.1.240.5; Mon, 31 Mar 2008 22:22:25 -0400 Received: from mail.acmepacket.com ([216.41.24.7]) by mail.acmepacket.com ([216.41.24.7]) with mapi; Mon, 31 Mar 2008 22:22:25 -0400 From: Hadriel Kaplan To: "DOLLY, MARTIN C, ATTLABS" , Daryl Malas , "peppermint@ietf.org" Date: Mon, 31 Mar 2008 22:17:55 -0400 Thread-Topic: [PEPPERMINT] Proposed Updated Charter Thread-Index: AciTaz5+nL5X5hseRkSarzcft2yW4AALIH5QAAEU7fA= Message-ID: References: <160DE07A1C4F8E4AA2715DEC577DA49193647C@srvxchg3.cablelabs.com> <28F05913385EAC43AF019413F674A0171246ED86@OCCLUST04EVS1.ugd.att.com> In-Reply-To: <28F05913385EAC43AF019413F674A0171246ED86@OCCLUST04EVS1.ugd.att.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US MIME-Version: 1.0 Subject: Re: [PEPPERMINT] Proposed Updated Charter 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 His proposed replacement text is only the second half of his email, which doesn't use the term "PBX" (thankfully). It does use the term "enterprises", but does not define the scope of that, nor does it imply any and all enterprises would be involved or how (which I think it's good to keep undefined). Examples would be an Enterprise using something out of PEPPERMINT itself to provision its own proxies/databases, for example with what service provider to use for what routes, or what SBE's to use to reach that service provider. Or a service provider might exchange some information with the Enterprise, or vice-versa, for similar information. The "enterprises" could be large corporations; or perhaps a service provider's own internal employee system, or their consumer voip service might be considered a separate, enterprise-type, from their other voip services/networks. -hadriel > -----Original Message----- > From: peppermint-bounces@ietf.org [mailto:peppermint-bounces@ietf.org] On > Behalf Of DOLLY, MARTIN C, ATTLABS > Sent: Monday, March 31, 2008 9:31 PM > To: Daryl Malas; peppermint@ietf.org > Subject: Re: [PEPPERMINT] Proposed Updated Charter > > Hello, > > As I stated in the meeting, reference to enterprise/PBXs should be > removed. If you think it should remain please give examples of the > provisioned information? > > Thanks, > > Martin > > -----Original Message----- > From: peppermint-bounces@ietf.org [mailto:peppermint-bounces@ietf.org] > On Behalf Of Daryl Malas > Sent: Monday, March 31, 2008 4:10 PM > To: peppermint@ietf.org > Subject: [PEPPERMINT] Proposed Updated Charter > > All, > > I was asked to re-write the charter using agreed upon SPEERMINT WG > defined terms. I also added/changed a few minor suggested details. The > update is below: > > ------------------------------------------ > Existing charter: > > PROPOSED CHARTER FOR PEPPERMINT > > The IETF has been working on various aspects of session-based Multimedia > Interconnection among administrative domains. In addition, the IETF has > done significant work on data exchanges among various network elements. > > ENUM is specifically chartered to develop protocols that involve the > translation of E.164 numbers to URI's. > > SPEERMINT has been chartered to develop best current practices among > real-time application service providers and how such services > interconnect across administrative boundaries. > > The PEPPERMINT work group is chartered to define what data needs to be > exchanged among Multimedia administrative domains, and how that data > should be structured provisioned and propagated. These protocols would > be outside the normal scope of establishing various forms of a SIP > session. These administrative domains are of any practical size and > could be service providers or enterprise SIP proxy's, such as PBX's. > > Data exchanges to facilitate session-based Multimedia Interconnection > are typically between various Client User Agents and Registries or > bilateral or multilateral Registry to Registry. Data exchanges could > include bulk data as well as real time updates. Typical data include > mappings of phone numbers to URIs, policies surrounding admission to > various points of network interconnection and various types of trunk > data. In addition, there is a specific need for redistribution of such > Registry data to various types of network databases. > > The working group will draw upon expert advice and ongoing consultation > from the ENUM, SPEERMINT and PROVREG working groups. The working group > may also reuse elements of RFC 4114, if possible. > > The final work product(s) from this working group will utilize and be > based on XML documents and XML document exchanges. > ------------------------------------- > New revision: > > PROPOSED CHARTER FOR PEPPERMINT > > The IETF has been working on various aspects of session-based Multimedia > peering among SIP Service Providers (SSPs), 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 following working groups' work provides > the underlying context for much of the intended work within this > charter: > > ENUM, which is specifically chartered to develop protocols that involve > the translation of E.164 numbers to URIs. > > SPEERMINT, which has been chartered to develop requirements and best > current practices among real-time application SSPs and how such services > may interconnect across administrative boundaries. This work will > provide details of how Session Establishment Data (SED) is collected and > what this data is comprised of, the use of this data to properly > identify an optimal path to the destination user agent (UA), and the > secure manners in which this and the SIP session data is exchanged > between all of the peering functions. It is also recognizes peering > relationships become more complex as multiple peers are added to a > common relationship, these complex aspects and requirements of multiple, > yet common peering relationships are defined with the contexts of a > peering Federation. > > The PEPPERMINT working group is chartered to define what data needs to > be exchanged among Multimedia administrative domains, and how that data > should be structured, provisioned, and propagated. These protocols would > be outside the normal scope of establishing various forms of a SIP > session. These administrative domains are of any practical size and > could be any type of SSP, such as recognized telephony carriers, > enterprises, end-user groups, and Federations. > > Data exchanges to facilitate session-based Multimedia Interconnection > are typically between various bilateral or multilateral client User > Agents and related Registries. Data exchanges could include bulk data > and/or real time updates. Typical data includes mappings of phone > numbers to URIs, policies surrounding admission to various points of > network interconnection, and various types of interconnect data. In > addition, there is a specific need for the exchange of such data between > the Registry and various types of network databases (e.g. Local Number > Portability (LNP), Calling Name (CNAM), etc.). > > 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, if possible. > > The final work product(s) from this working group will utilize and be > based on XML documents and XML document exchanges. > > --------------------------------------- > > Thanks...--Daryl > > > _______________________________________________ > 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 _______________________________________________ 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 core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 73B313A6A0D; Mon, 31 Mar 2008 18:31: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 0A0CE3A6A0D for ; Mon, 31 Mar 2008 18:31:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.747 X-Spam-Level: X-Spam-Status: No, score=-103.747 tagged_above=-999 required=5 tests=[AWL=2.852, 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 uvreFQBxFd5n for ; Mon, 31 Mar 2008 18:31:32 -0700 (PDT) Received: from mail121.messagelabs.com (mail121.messagelabs.com [216.82.241.195]) by core3.amsl.com (Postfix) with ESMTP id BDDE33A67A3 for ; Mon, 31 Mar 2008 18:31:31 -0700 (PDT) X-VirusChecked: Checked X-Env-Sender: mdolly@att.com X-Msg-Ref: server-9.tower-121.messagelabs.com!1207013488!21868446!1 X-StarScan-Version: 5.5.12.14.2; banners=-,-,- X-Originating-IP: [144.160.20.54] Received: (qmail 16679 invoked from network); 1 Apr 2008 01:31:28 -0000 Received: from sbcsmtp7.sbc.com (HELO mlpi135.enaf.sfdc.sbc.com) (144.160.20.54) by server-9.tower-121.messagelabs.com with AES256-SHA encrypted SMTP; 1 Apr 2008 01:31:28 -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 m311VSBJ011692 for ; Mon, 31 Mar 2008 21:31:28 -0400 Received: from OCCLUST04EVS1.ugd.att.com (ocst07.ugd.att.com [135.38.164.12]) by mlpi135.enaf.sfdc.sbc.com (8.14.0/8.14.0) with ESMTP id m311VHb0011658 for ; Mon, 31 Mar 2008 21:31:25 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Mon, 31 Mar 2008 20:31:16 -0500 Message-ID: <28F05913385EAC43AF019413F674A0171246ED86@OCCLUST04EVS1.ugd.att.com> In-Reply-To: <160DE07A1C4F8E4AA2715DEC577DA49193647C@srvxchg3.cablelabs.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [PEPPERMINT] Proposed Updated Charter Thread-Index: AciTaz5+nL5X5hseRkSarzcft2yW4AALIH5Q References: <160DE07A1C4F8E4AA2715DEC577DA49193647C@srvxchg3.cablelabs.com> From: "DOLLY, MARTIN C, ATTLABS" To: "Daryl Malas" , Subject: Re: [PEPPERMINT] Proposed Updated Charter 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 Hello, As I stated in the meeting, reference to enterprise/PBXs should be removed. If you think it should remain please give examples of the provisioned information? Thanks, Martin -----Original Message----- From: peppermint-bounces@ietf.org [mailto:peppermint-bounces@ietf.org] On Behalf Of Daryl Malas Sent: Monday, March 31, 2008 4:10 PM To: peppermint@ietf.org Subject: [PEPPERMINT] Proposed Updated Charter All, I was asked to re-write the charter using agreed upon SPEERMINT WG defined terms. I also added/changed a few minor suggested details. The update is below: ------------------------------------------ Existing charter: PROPOSED CHARTER FOR PEPPERMINT The IETF has been working on various aspects of session-based Multimedia Interconnection among administrative domains. In addition, the IETF has done significant work on data exchanges among various network elements. ENUM is specifically chartered to develop protocols that involve the translation of E.164 numbers to URI's. SPEERMINT has been chartered to develop best current practices among real-time application service providers and how such services interconnect across administrative boundaries. The PEPPERMINT work group is chartered to define what data needs to be exchanged among Multimedia administrative domains, and how that data should be structured provisioned and propagated. These protocols would be outside the normal scope of establishing various forms of a SIP session. These administrative domains are of any practical size and could be service providers or enterprise SIP proxy's, such as PBX's. Data exchanges to facilitate session-based Multimedia Interconnection are typically between various Client User Agents and Registries or bilateral or multilateral Registry to Registry. Data exchanges could include bulk data as well as real time updates. Typical data include mappings of phone numbers to URIs, policies surrounding admission to various points of network interconnection and various types of trunk data. In addition, there is a specific need for redistribution of such Registry data to various types of network databases. The working group will draw upon expert advice and ongoing consultation from the ENUM, SPEERMINT and PROVREG working groups. The working group may also reuse elements of RFC 4114, if possible. The final work product(s) from this working group will utilize and be based on XML documents and XML document exchanges. ------------------------------------- New revision: PROPOSED CHARTER FOR PEPPERMINT The IETF has been working on various aspects of session-based Multimedia peering among SIP Service Providers (SSPs), 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 following working groups' work provides the underlying context for much of the intended work within this charter: ENUM, which is specifically chartered to develop protocols that involve the translation of E.164 numbers to URIs. SPEERMINT, which has been chartered to develop requirements and best current practices among real-time application SSPs and how such services may interconnect across administrative boundaries. This work will provide details of how Session Establishment Data (SED) is collected and what this data is comprised of, the use of this data to properly identify an optimal path to the destination user agent (UA), and the secure manners in which this and the SIP session data is exchanged between all of the peering functions. It is also recognizes peering relationships become more complex as multiple peers are added to a common relationship, these complex aspects and requirements of multiple, yet common peering relationships are defined with the contexts of a peering Federation. The PEPPERMINT working group is chartered to define what data needs to be exchanged among Multimedia administrative domains, and how that data should be structured, provisioned, and propagated. These protocols would be outside the normal scope of establishing various forms of a SIP session. These administrative domains are of any practical size and could be any type of SSP, such as recognized telephony carriers, enterprises, end-user groups, and Federations. Data exchanges to facilitate session-based Multimedia Interconnection are typically between various bilateral or multilateral client User Agents and related Registries. Data exchanges could include bulk data and/or real time updates. Typical data includes mappings of phone numbers to URIs, policies surrounding admission to various points of network interconnection, and various types of interconnect data. In addition, there is a specific need for the exchange of such data between the Registry and various types of network databases (e.g. Local Number Portability (LNP), Calling Name (CNAM), etc.). 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, if possible. The final work product(s) from this working group will utilize and be based on XML documents and XML document exchanges. --------------------------------------- Thanks...--Daryl _______________________________________________ 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 core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 436373A6E01; Mon, 31 Mar 2008 13:34:20 -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 B58A73A6D82 for ; Mon, 31 Mar 2008 13:34:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.599 X-Spam-Level: X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Li4-F8sP5FPq for ; Mon, 31 Mar 2008 13:34:18 -0700 (PDT) Received: from mail.songbird.com (mail.songbird.com [208.184.79.10]) by core3.amsl.com (Postfix) with ESMTP id E39F53A6BB3 for ; Mon, 31 Mar 2008 13:34:18 -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 m2VKX901030449 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Mon, 31 Mar 2008 12:33:10 -0800 From: "Richard Shockey" To: "'Daryl Malas'" References: <160DE07A1C4F8E4AA2715DEC577DA49193647C@srvxchg3.cablelabs.com> In-Reply-To: <160DE07A1C4F8E4AA2715DEC577DA49193647C@srvxchg3.cablelabs.com> Date: Mon, 31 Mar 2008 16:33:40 -0400 Message-ID: <140101c8936e$82043aa0$860cafe0$@us> MIME-Version: 1.0 X-Mailer: Microsoft Office Outlook 12.0 Thread-index: AciTaz5+nL5X5hseRkSarzcft2yW4AAApq3w 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] Proposed Updated Charter 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 What do you think about goals and milestones? PROPOSED GOALS AND MILESTONES Requirements for Session Establishment Data (SED) data exchanges. Sept 08 ?? Provisioning of Session Establishment Data (SED) registries. Nov 08 Provisioning of Localized Session Establishment Data (SED) caches. Feb 09 Something like this? > -----Original Message----- > From: peppermint-bounces@ietf.org [mailto:peppermint-bounces@ietf.org] > On Behalf Of Daryl Malas > Sent: Monday, March 31, 2008 4:10 PM > To: peppermint@ietf.org > Subject: [PEPPERMINT] Proposed Updated Charter > > All, > > I was asked to re-write the charter using agreed upon SPEERMINT WG > defined terms. I also added/changed a few minor suggested details. > The > update is below: _______________________________________________ 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 core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 19AB73A6CBA; Mon, 31 Mar 2008 13:28:46 -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 B4E413A6B12 for ; Mon, 31 Mar 2008 13:28:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.599 X-Spam-Level: X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7ecbxIa-N4sz for ; Mon, 31 Mar 2008 13:28:43 -0700 (PDT) Received: from mail.songbird.com (mail.songbird.com [208.184.79.10]) by core3.amsl.com (Postfix) with ESMTP id AAF9A3A6AED for ; Mon, 31 Mar 2008 13:28:43 -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 m2VKRbGh025975 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Mon, 31 Mar 2008 12:27:38 -0800 From: "Richard Shockey" To: "'Daryl Malas'" , References: <160DE07A1C4F8E4AA2715DEC577DA49193647C@srvxchg3.cablelabs.com> In-Reply-To: <160DE07A1C4F8E4AA2715DEC577DA49193647C@srvxchg3.cablelabs.com> Date: Mon, 31 Mar 2008 16:28:08 -0400 Message-ID: <140001c8936d$bc38b350$34aa19f0$@us> MIME-Version: 1.0 X-Mailer: Microsoft Office Outlook 12.0 Thread-index: AciTaz5+nL5X5hseRkSarzcft2yW4AAAd1VQ Content-language: en-us X-SongbirdInformation: support@songbird.com for more information X-Songbird: Clean X-Songbird-From: richard@shockey.us Subject: Re: [PEPPERMINT] Proposed Updated Charter 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 Excellent ... I don't think we need to specifically call out LNP and CNAM, "Network databases" is sufficient. > > I was asked to re-write the charter using agreed upon SPEERMINT WG > defined terms. I also added/changed a few minor suggested details. > The > update is below: > > ------------------------------------------ > Existing charter: > > PROPOSED CHARTER FOR PEPPERMINT > > The IETF has been working on various aspects of session-based > Multimedia > Interconnection among administrative domains. In addition, the IETF > has > done significant work on data exchanges among various network > elements. > > ENUM is specifically chartered to develop protocols that involve the > translation of E.164 numbers to URI's. > > SPEERMINT has been chartered to develop best current practices among > real-time application service providers and how such services > interconnect across administrative boundaries. > > The PEPPERMINT work group is chartered to define what data needs to be > exchanged among Multimedia administrative domains, and how that data > should be structured provisioned and propagated. These protocols would > be outside the normal scope of establishing various forms of a SIP > session. These administrative domains are of any practical size and > could be service providers or enterprise SIP proxy's, such as PBX's. > > Data exchanges to facilitate session-based Multimedia Interconnection > are typically between various Client User Agents and Registries or > bilateral or multilateral Registry to Registry. Data exchanges could > include bulk data as well as real time updates. Typical data include > mappings of phone numbers to URIs, policies surrounding admission to > various points of network interconnection and various types of trunk > data. In addition, there is a specific need for redistribution of > such > Registry data to various types of network databases. > > The working group will draw upon expert advice and ongoing > consultation > from the ENUM, SPEERMINT and PROVREG working groups. The working group > may also reuse elements of RFC 4114, if possible. > > The final work product(s) from this working group will utilize and be > based on XML documents and XML document exchanges. > ------------------------------------- > New revision: > > PROPOSED CHARTER FOR PEPPERMINT > > The IETF has been working on various aspects of session-based > Multimedia > peering among SIP Service Providers (SSPs), 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 following working groups' work provides > the underlying context for much of the intended work within this > charter: > > ENUM, which is specifically chartered to develop protocols that > involve > the translation of E.164 numbers to URIs. > > SPEERMINT, which has been chartered to develop requirements and best > current practices among real-time application SSPs and how such > services > may interconnect across administrative boundaries. This work will > provide details of how Session Establishment Data (SED) is collected > and > what this data is comprised of, the use of this data to properly > identify an optimal path to the destination user agent (UA), and the > secure manners in which this and the SIP session data is exchanged > between all of the peering functions. It is also recognizes peering > relationships become more complex as multiple peers are added to a > common relationship, these complex aspects and requirements of > multiple, > yet common peering relationships are defined with the contexts of a > peering Federation. > > The PEPPERMINT working group is chartered to define what data needs to > be exchanged among Multimedia administrative domains, and how that > data > should be structured, provisioned, and propagated. These protocols > would > be outside the normal scope of establishing various forms of a SIP > session. These administrative domains are of any practical size and > could be any type of SSP, such as recognized telephony carriers, > enterprises, end-user groups, and Federations. > > Data exchanges to facilitate session-based Multimedia Interconnection > are typically between various bilateral or multilateral client User > Agents and related Registries. Data exchanges could include bulk data > and/or real time updates. Typical data includes mappings of phone > numbers to URIs, policies surrounding admission to various points of > network interconnection, and various types of interconnect data. In > addition, there is a specific need for the exchange of such data > between > the Registry and various types of network databases (e.g. Local Number > Portability (LNP), Calling Name (CNAM), etc.). > > 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, if possible. > > The final work product(s) from this working group will utilize and be > based on XML documents and XML document exchanges. > > --------------------------------------- > > Thanks...--Daryl > > > _______________________________________________ > 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 core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 7853428C3D8; Mon, 31 Mar 2008 13:10: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 BA47E28C3C8 for ; Mon, 31 Mar 2008 13:10:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.463 X-Spam-Level: X-Spam-Status: No, score=-0.463 tagged_above=-999 required=5 tests=[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 PxQLIUomL1N4 for ; Mon, 31 Mar 2008 13:10:22 -0700 (PDT) Received: from ondar.cablelabs.com (ondar.cablelabs.com [192.160.73.61]) by core3.amsl.com (Postfix) with ESMTP id 60AF33A6E2E for ; Mon, 31 Mar 2008 13:10:22 -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 m2VKAKO1023799 for ; Mon, 31 Mar 2008 14:10:20 -0600 Received: from srvxchg3.cablelabs.com (10.5.0.25) by kyzyl.cablelabs.com (F-Secure/fsigk_smtp/511/kyzyl.cablelabs.com); Mon, 31 Mar 2008 14:10:20 -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: Mon, 31 Mar 2008 14:10:20 -0600 Message-ID: <160DE07A1C4F8E4AA2715DEC577DA49193647C@srvxchg3.cablelabs.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [PEPPERMINT] Proposed Updated Charter Thread-Index: AciTaz5+nL5X5hseRkSarzcft2yW4A== From: "Daryl Malas" To: X-Approved: ondar Subject: [PEPPERMINT] Proposed Updated Charter 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 All, I was asked to re-write the charter using agreed upon SPEERMINT WG defined terms. I also added/changed a few minor suggested details. The update is below: ------------------------------------------ Existing charter: PROPOSED CHARTER FOR PEPPERMINT The IETF has been working on various aspects of session-based Multimedia Interconnection among administrative domains. In addition, the IETF has done significant work on data exchanges among various network elements. ENUM is specifically chartered to develop protocols that involve the translation of E.164 numbers to URI's. SPEERMINT has been chartered to develop best current practices among real-time application service providers and how such services interconnect across administrative boundaries. The PEPPERMINT work group is chartered to define what data needs to be exchanged among Multimedia administrative domains, and how that data should be structured provisioned and propagated. These protocols would be outside the normal scope of establishing various forms of a SIP session. These administrative domains are of any practical size and could be service providers or enterprise SIP proxy's, such as PBX's. Data exchanges to facilitate session-based Multimedia Interconnection are typically between various Client User Agents and Registries or bilateral or multilateral Registry to Registry. Data exchanges could include bulk data as well as real time updates. Typical data include mappings of phone numbers to URIs, policies surrounding admission to various points of network interconnection and various types of trunk data. In addition, there is a specific need for redistribution of such Registry data to various types of network databases. The working group will draw upon expert advice and ongoing consultation from the ENUM, SPEERMINT and PROVREG working groups. The working group may also reuse elements of RFC 4114, if possible. The final work product(s) from this working group will utilize and be based on XML documents and XML document exchanges. ------------------------------------- New revision: PROPOSED CHARTER FOR PEPPERMINT The IETF has been working on various aspects of session-based Multimedia peering among SIP Service Providers (SSPs), 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 following working groups' work provides the underlying context for much of the intended work within this charter: ENUM, which is specifically chartered to develop protocols that involve the translation of E.164 numbers to URIs. SPEERMINT, which has been chartered to develop requirements and best current practices among real-time application SSPs and how such services may interconnect across administrative boundaries. This work will provide details of how Session Establishment Data (SED) is collected and what this data is comprised of, the use of this data to properly identify an optimal path to the destination user agent (UA), and the secure manners in which this and the SIP session data is exchanged between all of the peering functions. It is also recognizes peering relationships become more complex as multiple peers are added to a common relationship, these complex aspects and requirements of multiple, yet common peering relationships are defined with the contexts of a peering Federation. The PEPPERMINT working group is chartered to define what data needs to be exchanged among Multimedia administrative domains, and how that data should be structured, provisioned, and propagated. These protocols would be outside the normal scope of establishing various forms of a SIP session. These administrative domains are of any practical size and could be any type of SSP, such as recognized telephony carriers, enterprises, end-user groups, and Federations. Data exchanges to facilitate session-based Multimedia Interconnection are typically between various bilateral or multilateral client User Agents and related Registries. Data exchanges could include bulk data and/or real time updates. Typical data includes mappings of phone numbers to URIs, policies surrounding admission to various points of network interconnection, and various types of interconnect data. In addition, there is a specific need for the exchange of such data between the Registry and various types of network databases (e.g. Local Number Portability (LNP), Calling Name (CNAM), etc.). 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, if possible. The final work product(s) from this working group will utilize and be based on XML documents and XML document exchanges. --------------------------------------- Thanks...--Daryl _______________________________________________ PEPPERMINT mailing list PEPPERMINT@ietf.org https://www.ietf.org/mailman/listinfo/peppermint Return-Path: X-Original-To: ietfarch-peppermint-archive@core3.amsl.com Delivered-To: ietfarch-peppermint-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8ECA43A6E53; Mon, 17 Mar 2008 11:38:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -100.578 X-Spam-Level: X-Spam-Status: No, score=-100.578 tagged_above=-999 required=5 tests=[AWL=-0.140, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_ORG=0.611, RDNS_NONE=0.1, 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 YYSh6YdgSPpX; Mon, 17 Mar 2008 11:38:17 -0700 (PDT) Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 3398D3A6ECC; Mon, 17 Mar 2008 11:38: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 EBB163A6E7E for ; Mon, 17 Mar 2008 11:38:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com 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 OLT7kXzMAmeG for ; Mon, 17 Mar 2008 11:38:04 -0700 (PDT) Received: from mail.songbird.com (mail.songbird.com [208.184.79.10]) by core3.amsl.com (Postfix) with ESMTP id 288303A6EDA for ; Mon, 17 Mar 2008 11:37: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 m2HIXo7B009722 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO) for ; Mon, 17 Mar 2008 10:33:52 -0800 From: "Richard Shockey" To: Date: Mon, 17 Mar 2008 14:34:10 -0400 Message-ID: <006001c8885d$8170d290$845277b0$@us> MIME-Version: 1.0 X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: AciIXX1Ir4EdHf5XQuGNRfdBQXWYLg== Content-Language: en-us X-SongbirdInformation: support@songbird.com for more information X-Songbird: Clean X-Songbird-From: richard@shockey.us Subject: [PEPPERMINT] Preliminary notes from the BOF 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 Many thanks to Jason Livingood for taking notes .. If you have additional recollection of issues etc let me know as I'll draft the minutes up. PEPPERMINT BoF IETF 71 Agenda ====== accepted Charter review ============== David: "may" use 4114 ... we "may" use a lot of things. Ken ??: agree we "may" use a lot of things - slippery slope. shockey proposes to remove reference to 4114 David Schwartz's concerns about "within" / "among" domains... currently says "across". David suggests to use "within" AND "among". Hadriel suggest "within" and "between". ??: Maybe have presentations first, and then look into the charter? Shockey: 2nd BoF already - identified that there is a problem here. Jon: concerned about the "among / between" and the paragraph below that as well.. "various" is not very precise.. doubt this is the right place to do this charter texting. don't think we can get that agreed here. David Schwartz speaking ============== motivation: many peering registries formed, etc.. 3 relationships. between registries, pushing up and pushing down. registry data prefix sub/super compatibility with ENUM resolution data - ownership information carrier of record, etc. bulk considerations logical operations on registry data other attributes: validity fee category... lots of data associated with a number - not neccessarily everthing in a registry. Adam Uzelac: Are there "views", depending on "who is asking"? Shockey: Would be attributes reflecting policy.. Hadriel: covers LUF _and_ LRF? David: _very_ good question - definitely a different problem set. Jon: Break all this into achievable chunks. Jean-Francois - ESPP ==================== effort on ENUM-SIP server provisioning specification - intended as input into the BoF only. Problem: how can back office services provision data out to addressing servers. used the netconf structure to identify high level requirements martin dolly: please expand beyond north america. Sean Kent ========= talking about design principles of ESPP. real time vs. bulk (file) based approach for larger changes. most people in the room understand the problem most of them thinks the IETF should work on this problem. Cullen: Try to get this down to as small as possible. Any ideas on how that could be defined? David: Maybe start with "northbound" provisioning first, and leave out registry-registry-Peering.. Jean-Francois: High level of charter is good - hope to not go into the same discussions as in SPEERMINT Daryl: agree with Jon - use the terminology from SPEERMINT - please! CHAIR additional notes: ======================= A. Confine first pass at Goals and Milestones to Domain to Registry and Registry to Local Cache B. Eliminate references to PBX interface ..at this time. Could be scoped in the future. C. Registry to Registry interface also in the future. 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: ietfarch-peppermint-archive@core3.amsl.com Delivered-To: ietfarch-peppermint-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 552D028C7A0; Thu, 13 Mar 2008 11:58:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -100.53 X-Spam-Level: X-Spam-Status: No, score=-100.53 tagged_above=-999 required=5 tests=[AWL=-0.093, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_ORG=0.611, RDNS_NONE=0.1, 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 4pwskLJl0v-6; Thu, 13 Mar 2008 11:58:26 -0700 (PDT) Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 589B43A6981; Thu, 13 Mar 2008 11:58: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 99FD33A6873 for ; Thu, 13 Mar 2008 11:58:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com 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 qlGD6pd7Ba9E for ; Thu, 13 Mar 2008 11:58:17 -0700 (PDT) Received: from agamemnon.swishmail.com (agamemnon.swishmail.com [64.39.51.26]) by core3.amsl.com (Postfix) with ESMTP id 30B9D3A6B5A for ; Thu, 13 Mar 2008 11:58:17 -0700 (PDT) Received: (qmail 43605 invoked by uid 89); 13 Mar 2008 18:55:58 -0000 Received: from unknown (HELO rhw) (65.203.166.36) by agamemnon.swishmail.com with SMTP; 13 Mar 2008 18:55:56 -0000 From: "Robert H. Walter" To: References: In-Reply-To: Date: Thu, 13 Mar 2008 14:55:45 -0400 Message-ID: <013501c8853b$d84cdde0$88e699a0$@com> MIME-Version: 1.0 X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: AciFKfR8o/rHh2lWSBa9etRmsJNOMgADDEUgAAETn3A= Content-Language: en-us Subject: Re: [PEPPERMINT] PEPPERMINT Digest, Vol 9, Issue 17 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 Hi Ken, Good to hear from you and thanks for the prompt response! I see the distinction... Might a real world example be? Enterprise ID = Comcast; Enterprise ID encoded in Client ID encoded Object ID = VeriSign Thanks, -RHW -----Original Message----- From: peppermint-bounces@ietf.org [mailto:peppermint-bounces@ietf.org] On Behalf Of Cartwright, Kenneth Sent: Thursday, March 13, 2008 2:33 PM To: peppermint@ietf.org Subject: Re: [PEPPERMINT] PEPPERMINT Digest, Vol 9, Issue 17 Hi Bob, Thanks for the feedback. After re-reading the sections of the document that your points relate to, I think your question is a good one and the language in the document on this subject could stand some improvement in clarity. But the document and the example that you refer to are actually correct, although not quite clear. The lack of clarity can create confusion between the ClientID portion of the ObjectId property and the EnterpriseID property. The ClientID portion of the ObjectID is an identifier that represents the "operational entity/source" responsible of the object in question (iow, the specific ESPP client) with the goal of creating uniqueness of the ObjectID property. This ClientID leverages the IANA Enterprise ID as the source of unique client IDs (which is then suffixed with a 2 digit identifier to allow for the occasion where there may be multiple ESPP clients operated by a single organization). The EnterpriseID property, on the other hand, is an identifier that represents the "business entity/source" that is responsible for the object in question. The Enterprise ID also leverages the IANA Enterprise ID as the source of unique identifiers. So, based on the above, it may hopefully be clear now why these two values are different in the example you refer to. ....taken an action to improve the language in the document. Ken -----Original Message----- From: peppermint-bounces@ietf.org [mailto:peppermint-bounces@ietf.org] On Behalf Of peppermint-request@ietf.org Sent: Thursday, March 13, 2008 12:50 PM To: peppermint@ietf.org Subject: PEPPERMINT Digest, Vol 9, Issue 17 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. ESPP Enterprise and Object IDs (Robert H. Walter) ---------------------------------------------------------------------- Message: 1 Date: Thu, 13 Mar 2008 12:47:15 -0400 From: "Robert H. Walter" Subject: [PEPPERMINT] ESPP Enterprise and Object IDs To: "Peppermint" Message-ID: <00b901c88529$e4b1ccb0$ae156610$@com> Content-Type: text/plain; charset="us-ascii" Hello, This email discusses the topic of ESPP Enterprise and Object Identifiers. The I-D draft-mule-peppermint-espp-protocol-01.txt states in section 4.1 the following: The globally unique name space for the assignment of an Enterprise ID is the open IANA Private Enterprise Number registry, . This is great! The next section of the draft indicates that the IANA Private Enterprise Number registry is a only a candidate space. My assumption is that the draft needs to be scrubbed and the "candidate" remark removed. If I interpret the section on ID [Page 13] correctly, an ID is a globally unique 64-bit unsigned integer identifier that is encoded with an 8 digit ESPP client identifier and a 12 digit object identifier that is unique to that ESPP client. Additionally, the ESPP client identifier is further broken down into a 1-6 digit Enterprise ID (EID) followed by a 2 digit client suffix. In earlier PacketCable revisions of the document, the ID was simply a sequence number that was relative to the Enterprise ID. This changed along the way to be globally unique identifier that includes the EID, however, the EID was not removed from the protocol. What is the intent of EID now that the ID encodes the EID, isn't it simply redundant? Finally, the I couldn't find an example in the draft where the and exhibited the documented behavior. For example in figure 12 [Page 25] the and are: 7845601000012345631 76544 I would expect them to be: 7654401000012345631 76544 Are the examples incorrect and need to be scrubbed, or is my understanding broken? Best Regards, Bob -------------- next part -------------- An HTML attachment was scrubbed... URL: http://www.ietf.org/pipermail/peppermint/attachments/20080313/bda5c91b/a ttachment.htm ------------------------------ _______________________________________________ PEPPERMINT mailing list PEPPERMINT@ietf.org https://www.ietf.org/mailman/listinfo/peppermint End of PEPPERMINT Digest, Vol 9, Issue 17 ***************************************** _______________________________________________ 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: ietfarch-peppermint-archive@core3.amsl.com Delivered-To: ietfarch-peppermint-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8625528C1CC; Thu, 13 Mar 2008 11:35:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.053 X-Spam-Level: X-Spam-Status: No, score=-101.053 tagged_above=-999 required=5 tests=[AWL=-0.616, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_ORG=0.611, RDNS_NONE=0.1, 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 gy2dJAzyX9Le; Thu, 13 Mar 2008 11:35:28 -0700 (PDT) Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D27C428C20D; Thu, 13 Mar 2008 11:35: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 3FBB628C187 for ; Thu, 13 Mar 2008 11:35:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com 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 ZSw6EVwUAESm for ; Thu, 13 Mar 2008 11:35:26 -0700 (PDT) Received: from osprey.verisign.com (osprey.verisign.com [216.168.239.75]) by core3.amsl.com (Postfix) with ESMTP id 15A3828C1AB for ; Thu, 13 Mar 2008 11:35:25 -0700 (PDT) Received: from dul1wnexcn01.vcorp.ad.vrsn.com (dul1wnexcn01.vcorp.ad.vrsn.com [10.170.12.138]) by osprey.verisign.com (8.13.6/8.13.4) with ESMTP id m2DIMeQb020300 for ; Thu, 13 Mar 2008 13:22:41 -0500 Received: from DUL1WNEXMB05.vcorp.ad.vrsn.com ([10.170.12.240]) by dul1wnexcn01.vcorp.ad.vrsn.com with Microsoft SMTPSVC(6.0.3790.3959); Thu, 13 Mar 2008 14:33:07 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Thu, 13 Mar 2008 14:33:02 -0400 Message-ID: In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: PEPPERMINT Digest, Vol 9, Issue 17 Thread-Index: AciFKfR8o/rHh2lWSBa9etRmsJNOMgADDEUg From: "Cartwright, Kenneth" To: X-OriginalArrivalTime: 13 Mar 2008 18:33:07.0436 (UTC) FILETIME=[AE9EBAC0:01C88538] Subject: Re: [PEPPERMINT] PEPPERMINT Digest, Vol 9, Issue 17 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 Hi Bob, Thanks for the feedback. After re-reading the sections of the document that your points relate to, I think your question is a good one and the language in the document on this subject could stand some improvement in clarity. But the document and the example that you refer to are actually correct, although not quite clear. The lack of clarity can create confusion between the ClientID portion of the ObjectId property and the EnterpriseID property. The ClientID portion of the ObjectID is an identifier that represents the "operational entity/source" responsible of the object in question (iow, the specific ESPP client) with the goal of creating uniqueness of the ObjectID property. This ClientID leverages the IANA Enterprise ID as the source of unique client IDs (which is then suffixed with a 2 digit identifier to allow for the occasion where there may be multiple ESPP clients operated by a single organization). The EnterpriseID property, on the other hand, is an identifier that represents the "business entity/source" that is responsible for the object in question. The Enterprise ID also leverages the IANA Enterprise ID as the source of unique identifiers. So, based on the above, it may hopefully be clear now why these two values are different in the example you refer to. ....taken an action to improve the language in the document. Ken -----Original Message----- From: peppermint-bounces@ietf.org [mailto:peppermint-bounces@ietf.org] On Behalf Of peppermint-request@ietf.org Sent: Thursday, March 13, 2008 12:50 PM To: peppermint@ietf.org Subject: PEPPERMINT Digest, Vol 9, Issue 17 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. ESPP Enterprise and Object IDs (Robert H. Walter) ---------------------------------------------------------------------- Message: 1 Date: Thu, 13 Mar 2008 12:47:15 -0400 From: "Robert H. Walter" Subject: [PEPPERMINT] ESPP Enterprise and Object IDs To: "Peppermint" Message-ID: <00b901c88529$e4b1ccb0$ae156610$@com> Content-Type: text/plain; charset="us-ascii" Hello, This email discusses the topic of ESPP Enterprise and Object Identifiers. The I-D draft-mule-peppermint-espp-protocol-01.txt states in section 4.1 the following: The globally unique name space for the assignment of an Enterprise ID is the open IANA Private Enterprise Number registry, . This is great! The next section of the draft indicates that the IANA Private Enterprise Number registry is a only a candidate space. My assumption is that the draft needs to be scrubbed and the "candidate" remark removed. If I interpret the section on ID [Page 13] correctly, an ID is a globally unique 64-bit unsigned integer identifier that is encoded with an 8 digit ESPP client identifier and a 12 digit object identifier that is unique to that ESPP client. Additionally, the ESPP client identifier is further broken down into a 1-6 digit Enterprise ID (EID) followed by a 2 digit client suffix. In earlier PacketCable revisions of the document, the ID was simply a sequence number that was relative to the Enterprise ID. This changed along the way to be globally unique identifier that includes the EID, however, the EID was not removed from the protocol. What is the intent of EID now that the ID encodes the EID, isn't it simply redundant? Finally, the I couldn't find an example in the draft where the and exhibited the documented behavior. For example in figure 12 [Page 25] the and are: 7845601000012345631 76544 I would expect them to be: 7654401000012345631 76544 Are the examples incorrect and need to be scrubbed, or is my understanding broken? Best Regards, Bob -------------- next part -------------- An HTML attachment was scrubbed... URL: http://www.ietf.org/pipermail/peppermint/attachments/20080313/bda5c91b/a ttachment.htm ------------------------------ _______________________________________________ PEPPERMINT mailing list PEPPERMINT@ietf.org https://www.ietf.org/mailman/listinfo/peppermint End of PEPPERMINT Digest, Vol 9, Issue 17 ***************************************** _______________________________________________ PEPPERMINT mailing list PEPPERMINT@ietf.org https://www.ietf.org/mailman/listinfo/peppermint Return-Path: X-Original-To: ietfarch-peppermint-archive@core3.amsl.com Delivered-To: ietfarch-peppermint-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 82C2728C1EE; Thu, 13 Mar 2008 09:49:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -100.344 X-Spam-Level: X-Spam-Status: No, score=-100.344 tagged_above=-999 required=5 tests=[AWL=0.092, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_ORG=0.611, HTML_MESSAGE=0.001, RDNS_NONE=0.1, 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 lQL6gfthqiUi; Thu, 13 Mar 2008 09:49:51 -0700 (PDT) Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 172023A6C39; Thu, 13 Mar 2008 09:49:51 -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 7C5D83A6AE9 for ; Thu, 13 Mar 2008 09:49:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com 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 8QyuKtbj+kUt for ; Thu, 13 Mar 2008 09:49:46 -0700 (PDT) Received: from agamemnon.swishmail.com (agamemnon.swishmail.com [64.39.51.26]) by core3.amsl.com (Postfix) with ESMTP id 9E9FB3A6CDC for ; Thu, 13 Mar 2008 09:49:45 -0700 (PDT) Received: (qmail 49339 invoked by uid 89); 13 Mar 2008 16:47:26 -0000 Received: from unknown (HELO rhw) (65.203.166.36) by agamemnon.swishmail.com with SMTP; 13 Mar 2008 16:47:26 -0000 From: "Robert H. Walter" To: "Peppermint" Date: Thu, 13 Mar 2008 12:47:15 -0400 Message-ID: <00b901c88529$e4b1ccb0$ae156610$@com> MIME-Version: 1.0 X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: AciFKeSGhdCRdTewSwGo3PL0ef2sYg== Content-Language: en-us Subject: [PEPPERMINT] ESPP Enterprise and Object IDs 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: multipart/mixed; boundary="===============0457511316==" Sender: peppermint-bounces@ietf.org Errors-To: peppermint-bounces@ietf.org This is a multipart message in MIME format. --===============0457511316== Content-Type: multipart/alternative; boundary="----=_NextPart_000_00BA_01C88508.5DA02CB0" Content-Language: en-us This is a multipart message in MIME format. ------=_NextPart_000_00BA_01C88508.5DA02CB0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Hello, This email discusses the topic of ESPP Enterprise and Object Identifiers. The I-D draft-mule-peppermint-espp-protocol-01.txt states in section 4.1 the following: The globally unique name space for the assignment of an Enterprise ID is the open IANA Private Enterprise Number registry, . This is great! The next section of the draft indicates that the IANA Private Enterprise Number registry is a only a candidate space. My assumption is that the draft needs to be scrubbed and the "candidate" remark removed. If I interpret the section on ID [Page 13] correctly, an ID is a globally unique 64-bit unsigned integer identifier that is encoded with an 8 digit ESPP client identifier and a 12 digit object identifier that is unique to that ESPP client. Additionally, the ESPP client identifier is further broken down into a 1-6 digit Enterprise ID (EID) followed by a 2 digit client suffix. In earlier PacketCable revisions of the document, the ID was simply a sequence number that was relative to the Enterprise ID. This changed along the way to be globally unique identifier that includes the EID, however, the EID was not removed from the protocol. What is the intent of EID now that the ID encodes the EID, isn't it simply redundant? Finally, the I couldn't find an example in the draft where the and exhibited the documented behavior. For example in figure 12 [Page 25] the and are: 7845601000012345631 76544 I would expect them to be: 7654401000012345631 76544 Are the examples incorrect and need to be scrubbed, or is my understanding broken? Best Regards, Bob ------=_NextPart_000_00BA_01C88508.5DA02CB0 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hello,

 

This email discusses the topic of ESPP Enterprise = and Object Identifiers.  The I-D draft-mule-peppermint-espp-protocol-01.txt = states in section 4.1 the following:

 

   The globally unique name space for the assignment of an Enterprise ID is = the

   open IANA Private Enterprise Number registry, = <http://www.iana.org/assignments/enterprise-numbers>.

 

This is great!  The next section of the draft = indicates that the IANA Private Enterprise Number registry is a only a candidate = space. My assumption is that the draft needs to be scrubbed and the = “candidate” remark removed.

 

If I interpret the section on ID [Page 13] = correctly, an ID is a globally unique 64-bit unsigned integer identifier that is encoded = with an 8 digit ESPP client identifier and a 12 digit object identifier that is = unique to that ESPP client.  Additionally, the ESPP client identifier is = further broken down into a  1-6 digit Enterprise ID (EID) followed by a 2 = digit client suffix.   In earlier PacketCable revisions of the document, = the ID was simply a sequence number that was relative to the Enterprise = ID.  This changed along the way to be globally unique identifier that includes the = EID, however, the EID was not removed from the protocol.  What is the = intent of EID now that the ID encodes the EID, isn’t it simply = redundant?  Finally, the I couldn’t find an example in the draft where the = <oId> and <eId> exhibited the documented behavior.  For example in = figure 12 [Page 25] the <oId> and <eId> are:

 

        =
<oId>7845601000012345631</oId>
 &nb=
sp;      =
<eId>76544</eId>

 

I would expect them to be:

 

        =
<oId>7654401000012345631</oId>
 &nb=
sp;      =
<eId>76544</eId>

 

Are the examples incorrect and need to be scrubbed, = or is my understanding broken?

 

Best Regards,

 

Bob

------=_NextPart_000_00BA_01C88508.5DA02CB0-- --===============0457511316== 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 --===============0457511316==-- Return-Path: X-Original-To: ietfarch-peppermint-archive@core3.amsl.com Delivered-To: ietfarch-peppermint-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 549FB28C723; Wed, 12 Mar 2008 12:16:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -100.636 X-Spam-Level: X-Spam-Status: No, score=-100.636 tagged_above=-999 required=5 tests=[AWL=-0.199, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_ORG=0.611, RDNS_NONE=0.1, 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 o7g4CGd0ScsN; Wed, 12 Mar 2008 12:16:45 -0700 (PDT) Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B24413A692B; Wed, 12 Mar 2008 12:16:45 -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 15B7F3A6C58 for ; Wed, 12 Mar 2008 12:16:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com 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 uCAqmKzziGED for ; Wed, 12 Mar 2008 12:16:43 -0700 (PDT) Received: from mail.bofh.priv.at (fardach.bofh.priv.at [88.198.34.164]) by core3.amsl.com (Postfix) with ESMTP id 34AD73A692B for ; Wed, 12 Mar 2008 12:16:43 -0700 (PDT) Received: from [213.129.239.197] (dhcp2.bofh.priv.at [213.129.239.197]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mail.bofh.priv.at (Postfix) with ESMTP id B5BEE4C67E; Wed, 12 Mar 2008 20:14:22 +0100 (CET) Message-ID: <47D82B8D.4070901@nic.at> Date: Wed, 12 Mar 2008 20:14:21 +0100 From: Otmar Lendl User-Agent: Thunderbird 2.0.0.12 (Windows/20080213) MIME-Version: 1.0 To: Richard Shockey References: <023e01c87e31$18c414e0$4a4c3ea0$@us> In-Reply-To: <023e01c87e31$18c414e0$4a4c3ea0$@us> Cc: PEPPERMINT@ietf.org Subject: Re: [PEPPERMINT] FINAL 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 Richard Shockey wrote: > Presentation of the proposed charter. 10 min ( see below ) Isn't that the main focus of the BoF? > > PROPOSED CHARTER FOR PEPPERMINT > > The IETF has been working on various aspects of session-based Multimedia > Interconnection among administrative domains. In addition, the IETF has done > significant work on data exchanges among various network elements. > > ENUM is specifically chartered to develop protocols that involve the > translation of E.164 numbers to URI's. > > SPEERMINT has been chartered to develop best current practices among > real-time application service providers and how such services interconnect > across administrative boundaries. > > The PEPPERMINT work group is chartered to define what data needs to be > exchanged among Multimedia administrative domains, and how that data should > be structured provisioned and propagated. These protocols would be outside > the normal scope of establishing various forms of a SIP session. These > administrative domains are of any practical size and could be service > providers or enterprise SIP proxy's, such as PBX's. Are we going to do provisioning and/or routing? Is there even a sharp line between these two terms? > Data exchanges to facilitate session-based Multimedia Interconnection are > typically between various Client User Agents and Registries or bilateral or > multilateral Registry to Registry. IMHO we should never ever consider data from user agents in peppermint. > Data exchanges could include bulk data > as well as real time updates. Typical data include mappings of phone numbers > to URIs, policies surrounding admission to various points of network > interconnection and various types of trunk data. In addition, there is a > specific need for redistribution of such Registry data to various types of > network databases. > > The working group will draw upon expert advice and ongoing consultation from > the ENUM, SPEERMINT and PROVREG working groups. The working group may also > reuse elements of RFC 4114, if possible. > > The final work product(s) from this working group will utilize and be based > on XML documents and XML document exchanges. /ol _______________________________________________ PEPPERMINT mailing list PEPPERMINT@ietf.org https://www.ietf.org/mailman/listinfo/peppermint Return-Path: X-Original-To: ietfarch-peppermint-archive@core3.amsl.com Delivered-To: ietfarch-peppermint-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 2B74428C817; Wed, 12 Mar 2008 12:08:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -99.756 X-Spam-Level: X-Spam-Status: No, score=-99.756 tagged_above=-999 required=5 tests=[AWL=0.681, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_ORG=0.611, RDNS_NONE=0.1, 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 4kM1Y4sfvOxo; Wed, 12 Mar 2008 12:08:12 -0700 (PDT) Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 06ACF28C818; Wed, 12 Mar 2008 12:07:05 -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 260D028C80D for ; Wed, 12 Mar 2008 12:07:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com 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 vzTtEbzEjPFY for ; Wed, 12 Mar 2008 12:06:59 -0700 (PDT) Received: from agamemnon.swishmail.com (agamemnon.swishmail.com [64.39.51.26]) by core3.amsl.com (Postfix) with ESMTP id AC19E28C88B for ; Wed, 12 Mar 2008 12:04:37 -0700 (PDT) Received: (qmail 41817 invoked by uid 89); 12 Mar 2008 19:02:17 -0000 Received: from unknown (HELO rhw) (65.203.166.36) by agamemnon.swishmail.com with SMTP; 12 Mar 2008 19:02:16 -0000 From: "Robert H. Walter" To: "Peppermint" Date: Wed, 12 Mar 2008 15:02:08 -0400 Message-ID: <027101c88473$91efb390$b5cf1ab0$@com> MIME-Version: 1.0 X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: AciEc5G8/pRWeNGeTpqOPmrkTXOhtA== Content-Language: en-us Subject: [PEPPERMINT] Public Identity, TNRange and LRN Objects Amoungts other things... 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 have many questions/comments regarding the ESPP draft documents, consequently, I will start with just a few of the simple ones and spread them topically over a series of threads. The first line of questions/comments will deal with Public Identity, TNRange and LRN Objects The introduction of draft-mule-peppermint-espp-protocol-01.txt states that: An ENUM-SIP addressing server is a session routing server which resolves telephone numbers or any type of public user addresses into routable Uniform Resource Identifiers (URIs) based on various rules and routing logic. [Page 2] The phrase "any type of public user addresses" feels ambiguous. I see the correlation to Public Identity in that its description states: A Public Identity may be a telephone number, an email address, or other identity as deemed appropriate. There is no correlation for TNRange or LRN. It's not clear how an ENUM-SIP addressing server will resolve an email address or other arbitrary identity that is not a telephone number to a set of URI's. What is the intent here? Is it acceptable for the ESPP server to simply refuse to process a public identity if it contains an identity that is not deemed appropriate by the ENUM-SIP addressing server? If so, what is the appropriate protocol response? Interestingly enough, the logical structure diagram appears to have been updated from an earlier PacketCable version to constrain the public identity to an LRN, though the XML object structure defines a "PubId" attribute as an arbitrary string of unspecified length. Am I interpreting this correctly? In the context of ESPP, I recommend that a public identity be constrained to a telephone number, not over-constrained to a 10-digit LRN or under-constrained to an ambiguous public user address of unspecified length. For example: A Public Identity is uniquely identified by a telephone number consisting of 1-31 hexadecimal (0-9, A-F) digits. What happens when two public identities have different eid/oid, but the same pubId value? Doesn't the pubId (i.e. telephone number) attribute need to be unique? Is the intent of the TNRange object to allow for arbitrary number ranges? For example 9788482830 - 9788482832 represent a range of three national telephone numbers. I ask this question because it places a potentially significant burden on the ESPP server implementation to expand the number ranges into individual telephone numbers. I recommend ESPP define number blocks instead of arbitrary ranges. Use of wildcard (best match) algorithms within the ENUM-SIP Addressing server eliminate the requirement to expand the blocks. Finally, the draft defines an LRN as the following: A 10-digit number that identifies the switching port for a local telephone exchange. LRN is used to support Local Number Portability in North America. An LRN is associated with a Service Area. [Page 12] This object is specifically associated with the US and Canadian national number portability implementation. I believe ESPP would be better served by defining a Routing Number (prefix)? In North America, the routing number would represent an NPA-NXX office code. There is little or no need to bring North American implementation semantics into the specification. If ESPP uses conventional number blocks verses arbitrary number ranges, I would argue, that the TNRange and LRN objects may be subsumed into a single RN object. This brings up the issue of national verses international numbering plans. The specification appears to intermix national verses international numbering without providing any context of when a public identity or TNRange is national or international. It feels like the specification is missing an important contextual element with regards to national verses international numbering. Please advise on how I should be thinking about this issue. Regards, Bob Walter NetNumber, Inc. +1-978-848-2831 _______________________________________________ PEPPERMINT mailing list PEPPERMINT@ietf.org https://www.ietf.org/mailman/listinfo/peppermint Return-Path: X-Original-To: ietfarch-peppermint-archive@core3.amsl.com Delivered-To: ietfarch-peppermint-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 443123A6E19; Wed, 12 Mar 2008 11:14:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -100.663 X-Spam-Level: X-Spam-Status: No, score=-100.663 tagged_above=-999 required=5 tests=[AWL=-0.227, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_ORG=0.611, HTML_MESSAGE=0.001, RDNS_NONE=0.1, 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 YpJ-ImV4VHUN; Wed, 12 Mar 2008 11:14:13 -0700 (PDT) Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 469F028C3E8; Wed, 12 Mar 2008 11:14: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 2819E3A6951 for ; Wed, 12 Mar 2008 11:14:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com 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 LYzhY5VZFFTM for ; Wed, 12 Mar 2008 11:14:07 -0700 (PDT) Received: from moutng.kundenserver.de (moutng.kundenserver.de [212.227.126.188]) by core3.amsl.com (Postfix) with ESMTP id 6531B3A6D78 for ; Wed, 12 Mar 2008 11:14:07 -0700 (PDT) Received: from dhcp-133b.ietf71.ietf.org (dhcp-133b.ietf71.ietf.org [130.129.19.59]) by mrelayeu.kundenserver.de (node=mrelayeu6) with ESMTP (Nemesis) id 0ML29c-1JZVQV3go5-0001YM; Wed, 12 Mar 2008 19:11:45 +0100 Message-Id: From: David Schwartz To: "PFAUTZ, PENN L, ATTCORP" In-Reply-To: <34DA635B184A644DA4588E260EC0A25A122BDAF0@ACCLUST02EVS1.ugd.att.com> Mime-Version: 1.0 (Apple Message framework v912) Date: Wed, 12 Mar 2008 14:11:41 -0400 References: <34DA635B184A644DA4588E260EC0A25A122BDAF0@ACCLUST02EVS1.ugd.att.com> X-Mailer: Apple Mail (2.912) X-Provags-ID: V01U2FsdGVkX18QmfIP+uLhdf5Uqse+ymW/kaEoR3MNe5eSXgS 3dVpb5haDrlVcH226B5MRLm5h2J49d4f3lqok6MO0rRsZ3opyM 3OnrUYfioUNe6Dbk1RuaQ== Cc: PEPPERMINT@ietf.org Subject: Re: [PEPPERMINT] re draft-schwartz-peppermint-consolidated-provisioning-problem-statement-00 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: multipart/mixed; boundary="===============1965052701==" Sender: peppermint-bounces@ietf.org Errors-To: peppermint-bounces@ietf.org --===============1965052701== Content-Type: multipart/alternative; boundary=Apple-Mail-1--594964955 --Apple-Mail-1--594964955 Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Hi Penn I do not want to get bogged down just yet with the "ownership" issue (a.k.a the e164 issue being debated elsewhere). I think its fair to assume that the outcome of that discussion will have consequences here. As for the fee structure, even in the bilateral scenario you describe (which I agree with by the way) you may still want to differentiate "free" from "transit". Thanks for the comments, D. On Mar 11, 2008, at 9:46 PM, PFAUTZ, PENN L, ATTCORP wrote: > I have a little trouble parsing the following in Section 3.2: > > In complex cases, several VSPs may claim some form of responsibility > for the same prefix. We can use the term "last hop" VSP to > describe > the VSP closest to the end-user of a phone number. The provider > who > was assigned a prefix by the national numbering authority is the > "first hop" VSP. The first hop VSP may have no way of knowing if > the > last hop VSP will include itself in the registry. > > This wouldn't seem to make sense in a number portability environment > that uses all call query (e.g., the US) where the prefix may be > routed (I won't say owned) by one VSP but ported out numbers route > directly to the serving VSP. > > Probably some formal indication of carrier-or-record status for a > number is needed if the registry is going to allow others entities > beyond the COR to provision records. > > Likewise, I have concerns about the fee category construct. While > this might be uniformly defined in the PSTN space I believe this may > move toward bilateral agreements in the NGN space. > > Penn Pfautz > > _______________________________________________ > PEPPERMINT mailing list > PEPPERMINT@ietf.org > https://www.ietf.org/mailman/listinfo/peppermint --Apple-Mail-1--594964955 Content-Type: text/html; charset=US-ASCII Content-Transfer-Encoding: quoted-printable Hi Penn

I do not want to get bogged down just yet = with the "ownership" issue (a.k.a the e164 issue being debated = elsewhere). I think its fair to assume that the outcome of that = discussion will have consequences here.

As for the fee structure, even in the = bilateral scenario you describe (which I agree with by the way) you may = still want to differentiate "free" from = "transit".

Thanks for the = comments,

D.

On = Mar 11, 2008, at 9:46 PM, PFAUTZ, PENN L, ATTCORP wrote:

=
I = have a little trouble parsing the following in Section = 3.2:
 
In complex cases, several VSPs may claim some form of = responsibility
   for the same prefix.  We can use the = term "last hop" VSP to describe
   the VSP closest to the = end-user of a phone number.  The provider who
   was = assigned a prefix by the national numbering authority is = the
   "first hop" VSP.  The first hop VSP may have no = way of knowing if the
   last hop VSP will include itself = in the registry.
 
This wouldn't seem to make sense in a = number portability environment that uses all call query (e.g., the US) = where the prefix may be
routed (I won't say = owned) by one VSP but ported out numbers route directly to the = serving VSP.
 
=
Probably some formal indication of = carrier-or-record status for a number is needed if the registry is going = to allow others entities beyond the COR to provision = records.
 
Likewise, I have concerns about the = fee category construct. While this might be uniformly defined in the = PSTN space I believe this may move toward bilateral agreements in = the NGN space.
 
=
Penn = Pfautz
 
= _______________________________________________
PEPPERMINT mailing = list
PEPPERMINT@ietf.org
https://www= .ietf.org/mailman/listinfo/peppermint

= --Apple-Mail-1--594964955-- --===============1965052701== 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 --===============1965052701==-- Return-Path: X-Original-To: ietfarch-peppermint-archive@core3.amsl.com Delivered-To: ietfarch-peppermint-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id ACF5C3A6EC8; Wed, 12 Mar 2008 09:25:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -100.275 X-Spam-Level: X-Spam-Status: No, score=-100.275 tagged_above=-999 required=5 tests=[AWL=0.161, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_ORG=0.611, HTML_MESSAGE=0.001, RDNS_NONE=0.1, 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 amrk0NaBoM4x; Wed, 12 Mar 2008 09:25:42 -0700 (PDT) Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8BA113A6EBB; Wed, 12 Mar 2008 09:25:42 -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 7912B28C1A2 for ; Wed, 12 Mar 2008 09:25:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com 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 Gmg6deBNV7sr for ; Wed, 12 Mar 2008 09:25:40 -0700 (PDT) Received: from mail.songbird.com (mail.songbird.com [208.184.79.10]) by core3.amsl.com (Postfix) with ESMTP id 4C79E28C521 for ; Wed, 12 Mar 2008 09:25:40 -0700 (PDT) Received: from rshockeyPC (dhcp-3172.ietf71.ietf.org [130.129.49.114]) (authenticated bits=0) by mail.songbird.com (8.12.11.20060308/8.12.11) with ESMTP id m2CGLsWV020350 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Wed, 12 Mar 2008 08:21:56 -0800 From: "Richard Shockey" To: "'David Schwartz'" References: <062B8EE81F2EC945A577C3EFAE1DD68E9961B8@mail.xconnect.net> In-Reply-To: <062B8EE81F2EC945A577C3EFAE1DD68E9961B8@mail.xconnect.net> Date: Wed, 12 Mar 2008 12:22:31 -0400 Message-ID: <0c4b01c8845d$469a9560$d3cfc020$@us> MIME-Version: 1.0 X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: AciEM1sbm6VsYDw8T2K8GFgYFJZ8AQAKXODQ 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] Proposed Charter Wording 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: multipart/mixed; boundary="===============0528807917==" Sender: peppermint-bounces@ietf.org Errors-To: peppermint-bounces@ietf.org This is a multipart message in MIME format. --===============0528807917== Content-Type: multipart/alternative; boundary="----=_NextPart_000_0C4C_01C8843B.BF88F560" Content-Language: en-us This is a multipart message in MIME format. ------=_NextPart_000_0C4C_01C8843B.BF88F560 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Well that is certainly something to review this afternoon. Scope will be the key issue the IESG looks at when evaluating whether or not to grant a charter. But we should all remember what the task this afternoon really is ..to demonstrate that A. There is a problem that needs to be fixed B. The problem is within the scope of the IETF and CAN be fixed. C. There is a sufficient number of people ready willing and able to fix the problem ( within a reasonable time frame) From: David Schwartz [mailto:dschwartz@xconnect.net] Sent: Wednesday, March 12, 2008 7:22 AM To: richard@shockey.us Cc: peppermint@ietf.org Subject: Proposed Charter Wording I know that we are trying to form consensus but as I was putting together my slides I kept on crashing into the words "among administrative domains" and recalling Hadriels comments in Vancouver regarding the difference between "within" and "among". I think it is important that this issue be debated today and put to rest once and for all or it will come back to bite us in the future. I am proposing to mention them both as follows (even if we first tackle the "within") ... "The PEPPERMINT working group is charted to define what data needs to be exchanged within and among Multimedia administrative domains (outside the normal scope of establishing various forms of a SIP session) and how that data should be structured provisioned and propagated." Any thoughts? D. ------=_NextPart_000_0C4C_01C8843B.BF88F560 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Proposed Charter Wording

Well that is certainly something to review this = afternoon. Scope will be the key issue the IESG looks at when evaluating whether or not = to grant a charter.

 

But we should all remember what the task this afternoon = really is ..to demonstrate that

 

A. There is a problem that needs to be fixed =

 

B. The problem is within the scope of the IETF and CAN be = fixed.

 

C. There is a sufficient number of people ready willing = and able to fix the problem ( within a reasonable time = frame)

 

From:= David = Schwartz [mailto:dschwartz@xconnect.net]
Sent: Wednesday, March 12, 2008 7:22 AM
To: richard@shockey.us
Cc: peppermint@ietf.org
Subject: Proposed Charter Wording

 

 

I know that we are trying to form = consensus but as I was putting together my slides I kept on crashing into the = words "among administrative domains" and recalling Hadriels comments = in Vancouver regarding the difference between "within" and "among".

I think it is important that this issue be debated today and put to rest = once and for all or it will come back to bite us in the future.

I am proposing to mention them both as follows (even if we first tackle = the "within") ...

"The PEPPERMINT working group is charted to define what data needs = to be exchanged within and among Multimedia administrative domains (outside = the normal scope of establishing various forms of a SIP session) and how = that data should be structured provisioned and propagated."

Any thoughts?

D.

------=_NextPart_000_0C4C_01C8843B.BF88F560-- --===============0528807917== 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 --===============0528807917==-- Return-Path: X-Original-To: ietfarch-peppermint-archive@core3.amsl.com Delivered-To: ietfarch-peppermint-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8A7DC3A6EA3; Wed, 12 Mar 2008 09:01:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.246 X-Spam-Level: X-Spam-Status: No, score=-101.246 tagged_above=-999 required=5 tests=[AWL=-0.810, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_ORG=0.611, HTML_MESSAGE=0.001, RDNS_NONE=0.1, 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 vkYTsfGWwyYf; Wed, 12 Mar 2008 09:01:31 -0700 (PDT) Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A39993A6E9E; Wed, 12 Mar 2008 09:01:31 -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 6806B3A682D for ; Tue, 11 Mar 2008 18:49:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com 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 sruxYJE2ddY5 for ; Tue, 11 Mar 2008 18:49:06 -0700 (PDT) Received: from mail203.messagelabs.com (mail203.messagelabs.com [216.82.254.243]) by core3.amsl.com (Postfix) with ESMTP id 82DC03A67EB for ; Tue, 11 Mar 2008 18:49:06 -0700 (PDT) X-VirusChecked: Checked X-Env-Sender: ppfautz@att.com X-Msg-Ref: server-2.tower-203.messagelabs.com!1205286402!8247855!1 X-StarScan-Version: 5.5.12.14.2; banners=-,-,- X-Originating-IP: [144.160.20.54] Received: (qmail 15530 invoked from network); 12 Mar 2008 01:46:43 -0000 Received: from sbcsmtp7.sbc.com (HELO mlpi135.enaf.sfdc.sbc.com) (144.160.20.54) by server-2.tower-203.messagelabs.com with AES256-SHA encrypted SMTP; 12 Mar 2008 01:46:43 -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 m2C1kjVn014655 for ; Tue, 11 Mar 2008 21:46:45 -0400 Received: from ACCLUST02EVS1.ugd.att.com (acst04.ugd.att.com [135.37.16.9]) by mlpi135.enaf.sfdc.sbc.com (8.14.0/8.14.0) with ESMTP id m2C1kcUV014630 for ; Tue, 11 Mar 2008 21:46:38 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Tue, 11 Mar 2008 21:46:36 -0400 Message-ID: <34DA635B184A644DA4588E260EC0A25A122BDAF0@ACCLUST02EVS1.ugd.att.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: re draft-schwartz-peppermint-consolidated-provisioning-problem-statement-00 Thread-Index: AciD4ugzoDf3CIBPTeCbzc6OreZ/RA== From: "PFAUTZ, PENN L, ATTCORP" To: X-Mailman-Approved-At: Wed, 12 Mar 2008 09:01:30 -0700 Subject: [PEPPERMINT] re draft-schwartz-peppermint-consolidated-provisioning-problem-statement-00 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: multipart/mixed; boundary="===============0566699030==" Sender: peppermint-bounces@ietf.org Errors-To: peppermint-bounces@ietf.org This is a multi-part message in MIME format. --===============0566699030== Content-class: urn:content-classes:message Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C883E2.E91E4209" This is a multi-part message in MIME format. ------_=_NextPart_001_01C883E2.E91E4209 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable I have a little trouble parsing the following in Section 3.2: =20 In complex cases, several VSPs may claim some form of responsibility for the same prefix. We can use the term "last hop" VSP to describe the VSP closest to the end-user of a phone number. The provider who was assigned a prefix by the national numbering authority is the "first hop" VSP. The first hop VSP may have no way of knowing if the last hop VSP will include itself in the registry. =20 This wouldn't seem to make sense in a number portability environment that uses all call query (e.g., the US) where the prefix may be routed (I won't say owned) by one VSP but ported out numbers route directly to the serving VSP. =20 Probably some formal indication of carrier-or-record status for a number is needed if the registry is going to allow others entities beyond the COR to provision records. =20 Likewise, I have concerns about the fee category construct. While this might be uniformly defined in the PSTN space I believe this may move toward bilateral agreements in the NGN space.=20 =20 Penn Pfautz =20 ------_=_NextPart_001_01C883E2.E91E4209 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable
I have = a little=20 trouble parsing the following in Section 3.2:
 
In complex cases, several VSPs may = claim some form=20 of responsibility
   for the same prefix.  We can use = the term=20 "last hop" VSP to describe
   the VSP closest to the = end-user of a=20 phone number.  The provider who
   was assigned a = prefix by=20 the national numbering authority is the
   "first hop" = VSP. =20 The first hop VSP may have no way of knowing if the
   last = hop VSP=20 will include itself in the registry.
 
This = wouldn't seem=20 to make sense in a number portability environment that uses all call = query=20 (e.g., the US) where the prefix may be
routed = (I won't say=20 owned) by one VSP but ported out numbers route directly to the = serving=20 VSP.
 
Probably some formal=20 indication of carrier-or-record status for a number is needed if the = registry is=20 going to allow others entities beyond the COR to provision=20 records.
 
Likewise, I=20 have concerns about the fee category construct. While this might be = uniformly=20 defined in the PSTN space I believe this may move toward bilateral=20 agreements in the NGN space.
 
Penn Pfautz
 
------_=_NextPart_001_01C883E2.E91E4209-- --===============0566699030== 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 --===============0566699030==-- Return-Path: X-Original-To: ietfarch-peppermint-archive@core3.amsl.com Delivered-To: ietfarch-peppermint-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 3FA5F28C4BF; Wed, 12 Mar 2008 08:36:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -100.117 X-Spam-Level: X-Spam-Status: No, score=-100.117 tagged_above=-999 required=5 tests=[AWL=0.320, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_ORG=0.611, RDNS_NONE=0.1, 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 NB-Us4QGQ9zW; Wed, 12 Mar 2008 08:36:44 -0700 (PDT) Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 886A028C6BA; Wed, 12 Mar 2008 08:36:44 -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 7AF7728C703 for ; Wed, 12 Mar 2008 08:36:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com 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 KOqlP9aryoFq for ; Wed, 12 Mar 2008 08:36:42 -0700 (PDT) Received: from mail.songbird.com (mail.songbird.com [208.184.79.10]) by core3.amsl.com (Postfix) with ESMTP id 8298028C6BA for ; Wed, 12 Mar 2008 08:36:42 -0700 (PDT) Received: from rshockeyPC (dhcp-3172.ietf71.ietf.org [130.129.49.114]) (authenticated bits=0) by mail.songbird.com (8.12.11.20060308/8.12.11) with ESMTP id m2CFXC4v026713 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO) for ; Wed, 12 Mar 2008 07:33:14 -0800 From: "Richard Shockey" To: Date: Wed, 12 Mar 2008 11:33:45 -0400 Message-ID: <038e01c88456$80aa2fb0$81fe8f10$@us> MIME-Version: 1.0 X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: AciEVkrMwTsLhWzYSxu2/7SLSHEzYw== Content-Language: en-us X-SongbirdInformation: support@songbird.com for more information X-Songbird: Clean X-Songbird-From: richard@shockey.us Subject: [PEPPERMINT] Meeting Materials 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 https://datatracker.ietf.org/meeting/71/materials.html 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: ietfarch-peppermint-archive@core3.amsl.com Delivered-To: ietfarch-peppermint-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 5788F28C251; Wed, 12 Mar 2008 06:55:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -100.439 X-Spam-Level: X-Spam-Status: No, score=-100.439 tagged_above=-999 required=5 tests=[AWL=-0.002, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_ORG=0.611, RDNS_NONE=0.1, 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 WP+z5rSMU6U6; Wed, 12 Mar 2008 06:55:16 -0700 (PDT) Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4DCFA3A6C15; Wed, 12 Mar 2008 06:55: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 6B8A03A6C15 for ; Wed, 12 Mar 2008 06:55:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com 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 buWUV9M-7yiX for ; Wed, 12 Mar 2008 06:55:10 -0700 (PDT) Received: from ondar.cablelabs.com (ondar.cablelabs.com [192.160.73.61]) by core3.amsl.com (Postfix) with ESMTP id DC3FB3A68CB for ; Wed, 12 Mar 2008 06:55:09 -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 m2CDrGG5005152; Wed, 12 Mar 2008 07:53:16 -0600 Received: from srvxchg3.cablelabs.com (10.5.0.25) by kyzyl.cablelabs.com (F-Secure/fsigk_smtp/511/kyzyl.cablelabs.com); Wed, 12 Mar 2008 07:53:16 -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: Wed, 12 Mar 2008 07:52:24 -0600 Message-ID: <9AAEDF491EF7CA48AB587781B8F5D7C6FA714B@srvxchg3.cablelabs.com> In-Reply-To: <34DA635B184A644DA4588E260EC0A25A122BDC3C@ACCLUST02EVS1.ugd.att.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [PEPPERMINT] ESPP drafts Thread-Index: AciERQWRkiFWOEQZTrmH5qIWnoIgMwAARfYg References: <34DA635B184A644DA4588E260EC0A25A122BDC3C@ACCLUST02EVS1.ugd.att.com> From: "Jean-Francois Mule" To: "PFAUTZ, PENN L, ATTCORP" , X-Approved: ondar Subject: Re: [PEPPERMINT] ESPP drafts 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="iso-8859-1" Content-Transfer-Encoding: quoted-printable Sender: peppermint-bounces@ietf.org Errors-To: peppermint-bounces@ietf.org Penn, Thank you for your comments. First let me say that these drafts are provided as an input to a BOF to = show a real need and an example of how a few folks viewed the provisioning = data problem for a particular entity (addressing/routing server). It is pr= ovided to help clarify the scope/charter items. = Some of your concerns are shared and this is why the data model allows f= or number ranges, individual TNs and any type of URI really (under "public = identity"). That said, to get this data model to meet the requirements tha= t some telephony groups have within SIP service providers in North America = (inside and outside cable really), LRNs were added into the mix during the = intermediary phase of moving away from PSTN-like management. More inline. Jean-Francois. > -----Original Message----- > From: peppermint-bounces@ietf.org [mailto:peppermint- > bounces@ietf.org] On Behalf Of PFAUTZ, PENN L, ATTCORP > Sent: Wednesday, March 12, 2008 7:29 AM > To: PEPPERMINT@ietf.org > Subject: [PEPPERMINT] ESPP drafts > = > Some high level comments on the ESPP drafts ( draft-mule- > peppermint-espp-requirements-00.txt and draft-mule-peppermint-espp- > protocol-01.txt) > = > I was a little surprised to see the focus on=A0 central office code- > based routing. While I understand this is the current basis of PSTN > number allocation and routing, I'm concerned about an approach that > perpetuates the code nexus. (E.164 I like, but the exchange code > arrangement creates a host of problems we should be trying to move > away from.) One of the good things about ENUM is the potential to > free us from these limitations while allowing us to make use of the > good parts of E.164 numbering. Point taken. I would note that the other draft presented today from David, Rohan, Alan a= nd Ed also very e.164 centric. The data model added LRNs because we had a = requirement from folks handling sip call routing to the PSTN that we should= accommodate the way they do things with LRNs today. Not visionary but jus= t reality. = = > A=A0couple of=A0nits re the use of LRNs as long as you're going down > the code routing path: first,=A0LRN is North American specific; > second you could just refer to the code prefix which would be more > general since=A0an LRN by definition uses an NPA-NXX code for which > the LRN assignee is the code holder in the LERG. In LRN-based > routing only the terminating switch cases about the XXXX portion of > the LRN. Yes = > I appreciate the attempt to deal with the data volume issues > represented by NAPTRs for each TN, but I have reservations about > the particular solution path. Perhaps a non-NAPTR URI record as > proposed by Patrik Faltstrom might be=A0 worth some consideration. Yes. We just tried to deal with what was available today. > There are at least two flies in the ointment of number aggregation: > number portability and the possibility that different numbers in a > range served by the same service provider might have different > characteristics that require different treatment. > In the US, for example, some carriers have more than one type of > network/service offer, e.g. wireless, TDM wireline, VoIP. These may > be served out of the same pool of numbers given numbering > resource=A0optimization regulations and cross-modal portability. > = > 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: ietfarch-peppermint-archive@core3.amsl.com Delivered-To: ietfarch-peppermint-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C811C28C703; Wed, 12 Mar 2008 06:31:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.276 X-Spam-Level: X-Spam-Status: No, score=-101.276 tagged_above=-999 required=5 tests=[AWL=-0.840, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_ORG=0.611, HTML_MESSAGE=0.001, RDNS_NONE=0.1, 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 yAzX+dCmFVAh; Wed, 12 Mar 2008 06:31:36 -0700 (PDT) Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C318528C6DD; Wed, 12 Mar 2008 06:31:32 -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 87C9228C6DD for ; Wed, 12 Mar 2008 06:31:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com 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 KDspDNJ1z-LE for ; Wed, 12 Mar 2008 06:31:30 -0700 (PDT) Received: from mail120.messagelabs.com (mail120.messagelabs.com [216.82.250.83]) by core3.amsl.com (Postfix) with ESMTP id 9E9F928C639 for ; Wed, 12 Mar 2008 06:31:25 -0700 (PDT) X-VirusChecked: Checked X-Env-Sender: ppfautz@att.com X-Msg-Ref: server-14.tower-120.messagelabs.com!1205328544!23422432!1 X-StarScan-Version: 5.5.12.14.2; banners=-,-,- X-Originating-IP: [144.160.20.54] Received: (qmail 31673 invoked from network); 12 Mar 2008 13:29:05 -0000 Received: from sbcsmtp7.sbc.com (HELO mlpi135.enaf.sfdc.sbc.com) (144.160.20.54) by server-14.tower-120.messagelabs.com with AES256-SHA encrypted SMTP; 12 Mar 2008 13:29:05 -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 m2CDT3tv021491 for ; Wed, 12 Mar 2008 09:29:04 -0400 Received: from ACCLUST02EVS1.ugd.att.com (acst04.ugd.att.com [135.37.16.9]) by mlpi135.enaf.sfdc.sbc.com (8.14.0/8.14.0) with ESMTP id m2CDSvjb021390 for ; Wed, 12 Mar 2008 09:28:57 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Wed, 12 Mar 2008 09:28:56 -0400 Message-ID: <34DA635B184A644DA4588E260EC0A25A122BDC3C@ACCLUST02EVS1.ugd.att.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: ESPP drafts Thread-Index: AciERQWRkiFWOEQZTrmH5qIWnoIgMw== From: "PFAUTZ, PENN L, ATTCORP" To: Subject: [PEPPERMINT] ESPP drafts 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: multipart/mixed; boundary="===============0563844982==" Sender: peppermint-bounces@ietf.org Errors-To: peppermint-bounces@ietf.org This is a multi-part message in MIME format. --===============0563844982== Content-class: urn:content-classes:message Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C88445.063ED7FC" This is a multi-part message in MIME format. ------_=_NextPart_001_01C88445.063ED7FC Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Some high level comments on the ESPP drafts ( draft-mule-peppermint-espp-requirements-00.txt and draft-mule-peppermint-espp-protocol-01.txt) =20 I was a little surprised to see the focus on central office code-based routing. While I understand this is the current basis of PSTN number allocation and routing, I'm concerned about an approach that perpetuates the code nexus. (E.164 I like, but the exchange code arrangement creates a host of problems we should be trying to move away from.) One of the good things about ENUM is the potential to free us from these limitations while allowing us to make use of the good parts of E.164 numbering. =20 A couple of nits re the use of LRNs as long as you're going down the code routing path: first, LRN is North American specific; second you could just refer to the code prefix which would be more general since an LRN by definition uses an NPA-NXX code for which the LRN assignee is the code holder in the LERG. In LRN-based routing only the terminating switch cases about the XXXX portion of the LRN. =20 I appreciate the attempt to deal with the data volume issues represented by NAPTRs for each TN, but I have reservations about the particular solution path. Perhaps a non-NAPTR URI record as proposed by Patrik Faltstrom might be worth some consideration. There are at least two flies in the ointment of number aggregation: number portability and the possibility that different numbers in a range served by the same service provider might have different characteristics that require different treatment. In the US, for example, some carriers have more than one type of network/service offer, e.g. wireless, TDM wireline, VoIP. These may be served out of the same pool of numbers given numbering resource optimization regulations and cross-modal portability.=20 Penn Pfautz AT&T National Access Management +1-732-420-4962 =20 ------_=_NextPart_001_01C88445.063ED7FC Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable
Some = high level=20 comments on the ESPP drafts (=20 draft-mule-peppermint-espp-requirements-00.txt and=20 draft-mule-peppermint-espp-protocol-01.txt)
 
I was = a little=20 surprised to see the focus on  central office code-based routing. = While I=20 understand this is the current basis of PSTN number allocation and = routing, I'm=20 concerned about an approach that perpetuates the code nexus. (E.164 I = like, but=20 the exchange code arrangement creates a host of problems we should be = trying to=20 move away from.) One of the good things about ENUM is the potential to = free us=20 from these limitations while allowing us to make use of the good parts = of E.164=20 numbering.
 
A couple=20 of nits re the use of LRNs as long as you're going down the code = routing=20 path: first, LRN is North American specific; second you could just = refer to=20 the code prefix which would be more general since an LRN by = definition uses=20 an NPA-NXX code for which the LRN assignee is the code holder in the = LERG. In=20 LRN-based routing only the terminating switch cases about the XXXX = portion of=20 the LRN.
 
I = appreciate the=20 attempt to deal with the data volume issues represented by NAPTRs for = each TN,=20 but I have reservations about the particular solution path. Perhaps a = non-NAPTR=20 URI record as proposed by Patrik Faltstrom might be  worth some=20 consideration. There are at least two flies in the ointment of number=20 aggregation: number portability and the possibility that different = numbers in a=20 range served by the same service provider might have different = characteristics=20 that require different treatment.
In the = US, for=20 example, some carriers have more than one type of network/service offer, = e.g.=20 wireless, TDM wireline, VoIP. These may be served out of the same pool = of=20 numbers given numbering resource optimization regulations and = cross-modal=20 portability.

Penn Pfautz
AT&T National Access=20 Management
+1-732-420-4962
 
------_=_NextPart_001_01C88445.063ED7FC-- --===============0563844982== 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 --===============0563844982==-- Return-Path: X-Original-To: ietfarch-peppermint-archive@core3.amsl.com Delivered-To: ietfarch-peppermint-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0E6B828C654; Wed, 12 Mar 2008 04:24:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -100.09 X-Spam-Level: X-Spam-Status: No, score=-100.09 tagged_above=-999 required=5 tests=[AWL=0.346, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_ORG=0.611, HTML_MESSAGE=0.001, RDNS_NONE=0.1, 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 RBPKYqs11Ixm; Wed, 12 Mar 2008 04:24:50 -0700 (PDT) Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E30DD28C629; Wed, 12 Mar 2008 04:24:50 -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 CFC6628C5DB for ; Wed, 12 Mar 2008 04:24:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com 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 r2WD3julgMjF for ; Wed, 12 Mar 2008 04:24:49 -0700 (PDT) Received: from xconnect.net (host81-149-118-212.in-addr.btopenworld.com [81.149.118.212]) by core3.amsl.com (Postfix) with ESMTP id 8DEAD3A686F for ; Wed, 12 Mar 2008 04:24:48 -0700 (PDT) X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Wed, 12 Mar 2008 11:22:28 -0000 Message-ID: <062B8EE81F2EC945A577C3EFAE1DD68E9961B8@mail.xconnect.net> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Proposed Charter Wording Thread-Index: AciEM1sbm6VsYDw8T2K8GFgYFJZ8AQ== From: "David Schwartz" To: Cc: peppermint@ietf.org Subject: [PEPPERMINT] Proposed Charter Wording 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: multipart/mixed; boundary="===============1269390349==" Sender: peppermint-bounces@ietf.org Errors-To: peppermint-bounces@ietf.org This is a multi-part message in MIME format. --===============1269390349== Content-class: urn:content-classes:message Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C88433.5B279AA9" This is a multi-part message in MIME format. ------_=_NextPart_001_01C88433.5B279AA9 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable I know that we are trying to form consensus but as I was putting = together my slides I kept on crashing into the words "among = administrative domains" and recalling Hadriels comments in Vancouver = regarding the difference between "within" and "among". I think it is important that this issue be debated today and put to rest = once and for all or it will come back to bite us in the future. I am proposing to mention them both as follows (even if we first tackle = the "within") ... "The PEPPERMINT working group is charted to define what data needs to be = exchanged within and among Multimedia administrative domains (outside = the normal scope of establishing various forms of a SIP session) and how = that data should be structured provisioned and propagated." Any thoughts? D. ------_=_NextPart_001_01C88433.5B279AA9 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Proposed Charter Wording

I know that we are trying to form consensus but as I = was putting together my slides I kept on crashing into the words = "among administrative domains" and recalling Hadriels comments = in Vancouver regarding the difference between "within" and = "among".

I think it is important that this issue be debated today and put to rest = once and for all or it will come back to bite us in the future.

I am proposing to mention them both as follows (even if we first tackle = the "within") ...

"The PEPPERMINT working group is charted to define what data needs = to be exchanged within and among Multimedia administrative domains = (outside the normal scope of establishing various forms of a SIP = session) and how that data should be structured provisioned and = propagated."

Any thoughts?

D.

------_=_NextPart_001_01C88433.5B279AA9-- --===============1269390349== 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 --===============1269390349==-- Return-Path: X-Original-To: ietfarch-peppermint-archive@core3.amsl.com Delivered-To: ietfarch-peppermint-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 3B5C128C5DD; Wed, 12 Mar 2008 02:31:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -100.041 X-Spam-Level: X-Spam-Status: No, score=-100.041 tagged_above=-999 required=5 tests=[AWL=0.395, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_ORG=0.611, HTML_MESSAGE=0.001, RDNS_NONE=0.1, 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 vLhbGRxWqVa1; Wed, 12 Mar 2008 02:31:39 -0700 (PDT) Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A6E0E3A6CC7; Wed, 12 Mar 2008 02:31:39 -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 755C728C56B for ; Wed, 12 Mar 2008 02:31:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com 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 gjEmvXFw8HnZ for ; Wed, 12 Mar 2008 02:31:36 -0700 (PDT) Received: from xconnect.net (host81-149-118-212.in-addr.btopenworld.com [81.149.118.212]) by core3.amsl.com (Postfix) with ESMTP id E2BD63A6DB7 for ; Wed, 12 Mar 2008 02:31:34 -0700 (PDT) X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="----_=_NextPart_001_01C88423.899EA377" Date: Wed, 12 Mar 2008 09:28:44 -0000 Message-ID: <062B8EE81F2EC945A577C3EFAE1DD68E9961B4@mail.xconnect.net> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: draft-schwartz-peppermint-problem-statement-01 Thread-Index: AciEI3dBgEiG3e3TSmSuK+p/8aMlmw== From: "David Schwartz" To: Subject: [PEPPERMINT] draft-schwartz-peppermint-problem-statement-01 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 multi-part message in MIME format. ------_=_NextPart_001_01C88423.899EA377 Content-Type: multipart/alternative; boundary="----_=_NextPart_002_01C88423.899EA377" ------_=_NextPart_002_01C88423.899EA377 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hi I wanted to incorporate some of the comments that I received on this = prior to discussions today so I generated an 01 version and am sending = via email (I will publish on publicly reachable web site later on today = as well). Since it is so close to the meeting I figured I would highlight = changes... Section 3.1 added a 3rd paragraph Section 3.2 changes to 1st and 5th paragraphs Section 4 changes to paragraph 2 Section 5 changes to "port-out" and "renumber" definitions Section 10 changes to paragraph 3 D. ------_=_NextPart_002_01C88423.899EA377 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable draft-schwartz-peppermint-problem-statement-01

Hi

I wanted to incorporate some of the comments that I received on this = prior to discussions today so I generated an 01 version and am sending = via email (I will publish on publicly reachable web site later on today = as well).

Since it is so close to the meeting I figured I would highlight = changes...

Section 3.1 added a 3rd paragraph
Section 3.2 changes to 1st and 5th paragraphs
Section 4 changes to paragraph 2
Section 5 changes to "port-out" and "renumber" = definitions
Section 10 changes to paragraph 3

D.

------_=_NextPart_002_01C88423.899EA377-- ------_=_NextPart_001_01C88423.899EA377 Content-Type: text/plain; name="consolidated-provisioning-v1.txt" Content-Transfer-Encoding: base64 Content-Description: consolidated-provisioning-v1.txt Content-Disposition: attachment; filename="consolidated-provisioning-v1.txt" CgoKTmV0d29yayBXb3JraW5nIEdyb3VwICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgIEQuIFNjaHdhcnR6CkludGVybmV0LURyYWZ0ICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgIFhDb25uZWN0IEdsb2JhbCBOZXR3b3JrcwpJbnRlbmRlZCBzdGF0dXM6ICBTdGFu ZGFyZHMgVHJhY2sgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIFIuIE1haHkKRXhwaXJl czogIFNlcHRlbWJlciAxMywgMjAwOCAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIFBs YW50cm9uaWNzCiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICBBLiBEdXJpYwogICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgVGVsaW8KICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIEUuIExld2lz CiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgTmV1U3RhcgogICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgTWFyY2ggMTIsIDIwMDgKCgogICAgICAgICAgICAgIENvbnNvbGlk YXRlZCBQcm92aXNpb25pbmcgUHJvYmxlbSBTdGF0ZW1lbnQKICAgICAgICAgICAgIGRyYWZ0LXNj aHdhcnR6LXBlcHBlcm1pbnQtcHJvYmxlbS1zdGF0ZW1lbnQtMDEKClN0YXR1cyBvZiB0aGlzIE1l bW8KCiAgIEJ5IHN1Ym1pdHRpbmcgdGhpcyBJbnRlcm5ldC1EcmFmdCwgZWFjaCBhdXRob3IgcmVw cmVzZW50cyB0aGF0IGFueQogICBhcHBsaWNhYmxlIHBhdGVudCBvciBvdGhlciBJUFIgY2xhaW1z IG9mIHdoaWNoIGhlIG9yIHNoZSBpcyBhd2FyZQogICBoYXZlIGJlZW4gb3Igd2lsbCBiZSBkaXNj bG9zZWQsIGFuZCBhbnkgb2Ygd2hpY2ggaGUgb3Igc2hlIGJlY29tZXMKICAgYXdhcmUgd2lsbCBi ZSBkaXNjbG9zZWQsIGluIGFjY29yZGFuY2Ugd2l0aCBTZWN0aW9uIDYgb2YgQkNQIDc5LgoKICAg SW50ZXJuZXQtRHJhZnRzIGFyZSB3b3JraW5nIGRvY3VtZW50cyBvZiB0aGUgSW50ZXJuZXQgRW5n aW5lZXJpbmcKICAgVGFzayBGb3JjZSAoSUVURiksIGl0cyBhcmVhcywgYW5kIGl0cyB3b3JraW5n IGdyb3Vwcy4gIE5vdGUgdGhhdAogICBvdGhlciBncm91cHMgbWF5IGFsc28gZGlzdHJpYnV0ZSB3 b3JraW5nIGRvY3VtZW50cyBhcyBJbnRlcm5ldC0KICAgRHJhZnRzLgoKICAgSW50ZXJuZXQtRHJh ZnRzIGFyZSBkcmFmdCBkb2N1bWVudHMgdmFsaWQgZm9yIGEgbWF4aW11bSBvZiBzaXggbW9udGhz CiAgIGFuZCBtYXkgYmUgdXBkYXRlZCwgcmVwbGFjZWQsIG9yIG9ic29sZXRlZCBieSBvdGhlciBk b2N1bWVudHMgYXQgYW55CiAgIHRpbWUuICBJdCBpcyBpbmFwcHJvcHJpYXRlIHRvIHVzZSBJbnRl cm5ldC1EcmFmdHMgYXMgcmVmZXJlbmNlCiAgIG1hdGVyaWFsIG9yIHRvIGNpdGUgdGhlbSBvdGhl ciB0aGFuIGFzICJ3b3JrIGluIHByb2dyZXNzLiIKCiAgIFRoZSBsaXN0IG9mIGN1cnJlbnQgSW50 ZXJuZXQtRHJhZnRzIGNhbiBiZSBhY2Nlc3NlZCBhdAogICBodHRwOi8vd3d3LmlldGYub3JnL2ll dGYvMWlkLWFic3RyYWN0cy50eHQuCgogICBUaGUgbGlzdCBvZiBJbnRlcm5ldC1EcmFmdCBTaGFk b3cgRGlyZWN0b3JpZXMgY2FuIGJlIGFjY2Vzc2VkIGF0CiAgIGh0dHA6Ly93d3cuaWV0Zi5vcmcv c2hhZG93Lmh0bWwuCgogICBUaGlzIEludGVybmV0LURyYWZ0IHdpbGwgZXhwaXJlIG9uIFNlcHRl bWJlciAxMywgMjAwOC4KCkNvcHlyaWdodCBOb3RpY2UKCiAgIENvcHlyaWdodCAoQykgVGhlIElF VEYgVHJ1c3QgKDIwMDgpLgoKQWJzdHJhY3QKCiAgIFRoaXMgZG9jdW1lbnQgZGVzY3JpYmVzIHRo ZSB0eXBlIG9mIGRhdGEgcHJvdmlzaW9uZWQgYW1vbmcgVm9pY2UKICAgU2VydmljZSBQcm92aWRl cnMgYW5kIHVuZGVyc2NvcmVzIHRoZSBuZWVkIGZvciBjbGVhcmx5IGRlZmluZWQKICAgc3RydWN0 dXJlcyBhbmQgaW50ZXJmYWNlcyB0byBmYWNpbGl0YXRlIHRoaXMgcHJvdmlzaW9uaW5nLiAgVGhp cyB3b3JrCgoKClNjaHdhcnR6LCBldCBhbC4gICAgICAgRXhwaXJlcyBTZXB0ZW1iZXIgMTMsIDIw MDggICAgICAgICAgICAgICBbUGFnZSAxXQoMCkludGVybmV0LURyYWZ0ICAgICAgICAgICBDb25z b2xpZGF0ZWQtUHJvdi1Qcm9iICAgICAgICAgICAgICAgTWFyY2ggMjAwOAoKCiAgIGlzIGluIHN1 cHBvcnQgb2YgdGhlIHNlcnZpY2UgcHJvdmlkZXIgcGVlcmluZyBhcyBkZWZpbmVkIGJ5IHRoZQog ICBTUEVFUk1JTlQgV0cuCgoKVGFibGUgb2YgQ29udGVudHMKCiAgIDEuICBJbnRyb2R1Y3Rpb24g LiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAgMwogICAy LiAgVGVybWlub2xvZ3kgIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAu IC4gLiAuIC4gIDQKICAgMy4gIFJlZ2lzdHJ5IERhdGEgIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAu IC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuICA0CiAgICAgMy4xLiAgSW5kZXgvS2V5IERhdGEgLiAu IC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAgNAogICAgIDMuMi4gIFJl c29sdXRpb24gRGF0YSAgLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4g IDUKICAgNC4gIFJlYWNoYWJpbGl0eSB2cy4gUm91dGluZyAuIC4gLiAuIC4gLiAuIC4gLiAuIC4g LiAuIC4gLiAuIC4gLiAuICA2CiAgIDUuICBPcGVyYXRpb25zIG9uIHRoZSBSZWdpc3RyeSBEYXRh ICAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAgNgogICA2LiAgT3RoZXIgQXRycmlidXRl cyAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gIDcKICAgNy4g IERhdGEgRW5jb2RpbmcgIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAu IC4gLiAuICA4CiAgIDguICBEYXRhIE1hbmFnZW1lbnQgIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAu IC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAgOAogICA5LiAgRGF0YSBQcm9wYWdhdGlvbiAuIC4gLiAu IC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gIDgKICAgMTAuIFF1ZXJ5aW5n IFRoZSBSZWdpc3RyeSAgLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuICA4 CiAgIDExLiBDb250cm9sICAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4g LiAuIC4gLiAuIC4gLiAgOQogICAxMi4gRXhpc3RpbmcgVGVjaG5vbG9naWVzICAuIC4gLiAuIC4g LiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gIDkKICAgMTMuIFNlY3VyaXR5IENvbnNpZGVy YXRpb25zICAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuICA5CiAgIDE0LiBJ QU5BIENvbnNpZGVyYXRpb25zICAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAu IC4gLiAxMAogICAxNS4gQWNrbm93bGVkZ2VtZW50cyAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAu IC4gLiAuIC4gLiAuIC4gLiAuIC4gMTAKICAgMTYuIFJlZmVyZW5jZXMgLiAuIC4gLiAuIC4gLiAu IC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIDEwCiAgICAgMTYuMS4gTm9ybWF0 aXZlIFJlZmVyZW5jZXMgLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAxMAog ICAgIDE2LjIuIEluZm9ybWF0aW9uYWwgUmVmZXJlbmNlcyAuIC4gLiAuIC4gLiAuIC4gLiAuIC4g LiAuIC4gLiAuIC4gMTAKICAgQXV0aG9ycycgQWRkcmVzc2VzIC4gLiAuIC4gLiAuIC4gLiAuIC4g LiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIDExCiAgIEludGVsbGVjdHVhbCBQcm9wZXJ0eSBh bmQgQ29weXJpZ2h0IFN0YXRlbWVudHMgLiAuIC4gLiAuIC4gLiAuIC4gLiAxMwoKCgoKCgoKCgoK CgoKCgoKCgoKCgoKClNjaHdhcnR6LCBldCBhbC4gICAgICAgRXhwaXJlcyBTZXB0ZW1iZXIgMTMs IDIwMDggICAgICAgICAgICAgICBbUGFnZSAyXQoMCkludGVybmV0LURyYWZ0ICAgICAgICAgICBD b25zb2xpZGF0ZWQtUHJvdi1Qcm9iICAgICAgICAgICAgICAgTWFyY2ggMjAwOAoKCjEuICBJbnRy b2R1Y3Rpb24KCiAgIFZvSVAgU2VydmljZSBQcm92aWRlcnMgKFZTUHMpIGVuZ2FnZSBpbiBwZWVy aW5nIHJlbGF0aW9uc2hpcHMgd2l0aAogICBvdGhlciBWU1BzIHRvIGNyZWF0ZSBkaXJlY3QgSVAt dG8tSVAgaW50ZXJjb25uZWN0aW9ucy4gIFRoZXNlCiAgIHJlbGF0aW9uc2hpcHMgcHJvdmlkZSBu ZXR3b3JrIHJlYWNoLCBncmVhdGVyIHRlY2huaWNhbCBjYXBhYmlsaXRpZXMKICAgYW5kIGVuaGFu Y2VkIGVjb25vbWljIGJlbmVmaXQgYmV5b25kIHRoYXQgYXZhaWxhYmxlIHdpdGggdGhlIFB1Ymxp YwogICBTd2l0Y2hlZCBUZWxlcGhvbmUgTmV0d29yayAoUFNUTiksIHdoaWxlIHByb3ZpZGluZyB0 aGUgc2VjdXJpdHkKICAgYmVuZWZpdCBwZXJjZWl2ZWQgdG8gZXhpc3QgaW4gdGhlIFBTVE4uCgog ICBCZWNhdXNlIHRoZSBidXNpbmVzcyBhbmQgb3BlcmF0aW9uYWwgbWFuYWdlbWVudCBvZiBodW5k cmVkcyBvcgogICB0aG91c2FuZHMgb2YgZGlyZWN0IHBlZXJpbmcgcmVsYXRpb25zaGlwcyBpcyBk aWZmaWN1bHQsIFZTUHMgb2Z0ZW4KICAgZW5saXN0IHRoZSBoZWxwIG9mIHBlZXJpbmcgZXhjaGFu Z2VzIHRvIGNlbnRyYWxpemUgKG9yIGFzc2lzdAogICBbSS1ELmlldGYtc3BlZXJtaW50LXRlcm1p bm9sb2d5XSB3aXRoKSB0aGUgbWFuYWdlbWVudCBvZiB0aGUKICAgcmVsYXRpb25zaGlwcy4gIE9u ZSBvZiB0aGUgY2VudHJhbCBmdW5jdGlvbnMgb2YgdGhlc2UgcGVlcmluZwogICBleGNoYW5nZXMg aXMgYSByZWdpc3RyeSBvZiBpZGVudGlmaWVycyAob2Z0ZW4gaW1wbGVtZW50ZWQgYXMgYQogICBw cml2YXRlIEVOVU0gdHJlZSkgYmFzZWQgb24gdGVsZXBob25lIG51bWJlcnMuICBUaGlzIGZ1bmN0 aW9uIGlzCiAgIGNhbGxlZCB0aGUgcGVlcmluZyBvciBudW1iZXJpbmcgcmVnaXN0cnkuICBWU1Bz IHBhcnRpY2lwYXRpbmcgaW4gdGhlCiAgIHBlZXJpbmcgZXhjaGFuZ2UgbXVzdCBwcm92aXNpb24g dGhlaXIgaWRlbnRpZmllcnMgaW50byB0aGUgcGVlcmluZwogICByZWdpc3RyeSB0byBhbGxvdyBv dGhlciBWU1BzIHdpdGggYWNjZXNzIHRvIHRoaXMgcmVnaXN0cnkgdG8gcXVlcnkKICAgYW5kIG9i dGFpbiB0aGUgY29ycmVjdCByZXNvbHV0aW9uIGZvciBhIGdpdmVuIG51bWJlci4gIExhY2sgb2Yg Y2xlYXIKICAgc3RhbmRhcmRzIGZvciB0aGlzIHByb3Zpc2lvbmluZyBzdGVwIGhhcyBnaXZlbiBy aXNlIHRvIG1hbnkKICAgcHJvcHJpZXRhcnkgYXBwcm9hY2hlcyB0aGF0IGFyZSByZW5kZXJpbmcg b3BlbiBwcm92aXNpb25pbmcKICAgY3VtYmVyc29tZSBhbmQgZXJyb3IgcHJvbmUuCgogICBWU1Ag cGVlcmluZyBpcyBub3QgdGhlIG9ubHkgZHJpdmVyIGZvciB0aGlzIHdvcmssIGhvd2V2ZXIuICBJ dCBpcwogICBxdWl0ZSBjb21tb24gdG9kYXkgZm9yIG9uZSBWU1AgdG8gcmVjZWl2ZSBudW1iZXIg cmVzb2x1dGlvbiBkYXRhIGZyb20KICAgYm90aCBhdXRob3JpdGF0aXZlIG9yIHJlZ3VsYXRvcnkg c291cmNlcyAoZS5nLiBhIG5hdGlvbmFsIHRlbGVwaG9uZQogICBudW1iZXIgcGxhbiBhZG1pbmlz dHJhdG9yKSBhbmQgY29tbWVyY2lhbCBvciBwcml2YXRlIHNvdXJjZXMuICBTaW5jZQogICBldmVu dHVhbGx5IGFsbCBvZiB0aGUgaW5mb3JtYXRpb24gcmVzaWRlcyBsb2NhbGx5LCB0aGUgVlNQIGlz CiAgIGludGVyZXN0ZWQgaW4gbWVyZ2luZyByZXNvbHV0aW9uIGRhdGEgYWNyb3NzIHBvdGVudGlh bGx5IGRpZmZlcmVudAogICBsb2NhbCBwbGF0Zm9ybXMgc28gYXMgdG8gYXZvaWQgbXVsdGlwbGUg cXVlcmllcyBmb3IgZWFjaCBjYWxsLiAgVG9kYXkKICAgdGhpcyBpcyB2aXJ0dWFsbHkgaW1wb3Nz aWJsZSB0byBkbyBpbiBhbiBlZmZpY2llbnQgYW5kIHN0YW5kYXJkCiAgIG1hbm5lciBkdWUgdG8g dGhlIHByb3ByaWV0YXJ5IG5hdHVyZSBvZiB0aGUgaW5kaXZpZHVhbCByZWdpc3RyeQogICBjb21w b25lbnRzLgoKICAgSW4gYWRkaXRpb24sIG1hbnkgcmVnaXN0cnkgbmV0d29yayBhcmNoaXRlY3R1 cmVzIGRpY3RhdGUgc3ViCiAgIHJlZ2lzdHJpZXMgZm9yIG92ZXJhbGwgcmVzaWxpZW5jZSBhbmQg cGVyZm9ybWFuY2UuICBUaGUgdHJhbnNmZXIgb2YKICAgcmVzb2x1dGlvbiBkYXRhIHRvIHRoZSBz dWIgcmVnaXN0cmllcyBpcyBub3QgeWV0IHN0YW5kYXJkaXplZCBhbmQKICAgcmVzdWx0cyBpbiB1 bm5lY2Vzc2FyeSBoYXJkd2FyZS9zb2Z0d2FyZSBjb21wb25lbnQgbG9jayBpbi4KCiAgIFRoaXMg ZG9jdW1lbnQgYXR0ZW1wdHMgdG8gZGVzY3JpYmUgdGhlIG1vc3QgY29tbW9uIGRhdGEgdGhhdCBu ZWVkcyB0bwogICBiZSBleGNoYW5nZWQgaW4gdGhlIGNhc2VzIGhpZ2hsaWdodGVkIGFib3ZlIHdp dGggdGhlIHVsdGltYXRlIGdvYWwKICAgYmVpbmcgdGhhdCBvZiBpZGVudGlmeWluZyB0aGUgZGF0 YSBzdHJ1Y3R1cmVzIGFuZCBpbnRlcmZhY2VzIHJlcXVpcmVkCiAgIHRvIHN1cHBvcnQgdGhlIGRh dGEgZXhjaGFuZ2Ugc2NlbmFyaW9zIHNwZWNpZmllZCBhYm92ZS4KCiAgIEFzIGEgZmluYWwgbm90 ZSBpdCBpcyBpbXBvcnRhbnQgdG8gc3RyZXNzIHRoYXQgd2hpbGUgRU5VTSBpcyBub3QKICAgbWVu dGlvbmVkIGV4cGxpY2l0bHkgaW4gdGhpcyBkb2N1bWVudCBzbyBhcyBub3QgdG8gYmlhcyB0aGUg b3V0Y29tZSwKICAgaXQgaXMgY2xlYXIgdGhhdCBpbiB0aGUgbWluaW11bSBhbGwgdGhlIGluZm9y bWF0aW9uIHByZXNlbnQgaW4gYQoKCgpTY2h3YXJ0eiwgZXQgYWwuICAgICAgIEV4cGlyZXMgU2Vw dGVtYmVyIDEzLCAyMDA4ICAgICAgICAgICAgICAgW1BhZ2UgM10KDApJbnRlcm5ldC1EcmFmdCAg ICAgICAgICAgQ29uc29saWRhdGVkLVByb3YtUHJvYiAgICAgICAgICAgICAgIE1hcmNoIDIwMDgK CgogICBOQVBUUiBSUiBtdXN0IGJlIGNhcHR1cmVkIGFzIHRoZSBpbmZvcm1hdGlvbiB0aGVyZWlu IGhhcyBiZWVuIHdlbGwKICAgdGhvdWdodCBvdXQgYW5kIGRldmlhdGluZyBmcm9tIHRoaXMgbWF5 IGN1cnRhaWwgZnV0dXJlIGdyb3d0aC4KICAgQWRkaXRpb25hbGx5LCB3aGlsZSBFLjE2NCBudW1i ZXJpbmcgaXMgbm90IG1lbnRpb25lZCBlaXRoZXIgZm9yIHRoZQogICBzYW1lIHJlYXNvbiwgaXQg aXMgY2xlYXIgdGhhdCBpbiBhbG1vc3QgYWxsIGNhc2VzIHRoZSBwcmVmaXhlcyB0aGF0CiAgIGFy ZSBiZWluZyBleGNoYW5nZWQgYXJlIGluIHRoZSBlLjE2NCBmb3JtYXQuCgoKMi4gIFRlcm1pbm9s b2d5CgogICBUaGUga2V5IHdvcmRzICJNVVNUIiwgIk1VU1QgTk9UIiwgIlJFUVVJUkVEIiwgIlNI QUxMIiwgIlNIQUxMIE5PVCIsCiAgICJTSE9VTEQiLCAiU0hPVUxEIE5PVCIsICJSRUNPTU1FTkRF RCIsICJNQVkiLCBhbmQgIk9QVElPTkFMIiBpbiB0aGlzCiAgIGRvY3VtZW50IGFyZSB0byBiZSBp bnRlcnByZXRlZCBhcyBkZXNjcmliZWQgaW4gW1JGQzIxMTldLgoKICAgVGVybXMgdXNlZCBvciBy ZWZlcnJlZCB0byBlbHNld2hlcmUgaW4gdGhlIGRvY3VtZW50IChpbmNsdWRpbmcgaW4gdGhlCiAg IGludHJvZHVjdGlvbik6CgogICBETlMgLSBEb21haW4gTmFtZSBTeXN0ZW0gW1JGQzEwMzRdCgog ICBSUiAtIFJlc291cmNlIFJlY29yZCBbUkZDMTAzNF0KCiAgIFRYVCAtIEROUyBUZXh0IHJlY29y ZCBbUkZDMTAzNV0KCiAgIE5BUFRSIC0gTmFtaW5nIEF1dGhvcml0eSBQb2ludGVyIHJlY29yZCBb UkZDMzQwM10KCiAgIEVQUCAtIEV4dGVuc2libGUgUHJvdmlzaW9uaW5nIFByb3RvY29sIFtSRkMz NzMwXQoKICAgRU5VTSAtIEUuMTY0IHRvIFVSSSBERERTIFtSRkMzNzYxXQoKICAgVVJJIC0gVW5p Zm9ybSBSZXNvdXJjZSBJZGVudGlmaWVycyBbUkZDMzk4Nl0KCiAgIFRMUyAtIFRyYW5zYWN0aW9u IExheWVyIFNlY3VyaXR5IFtSRkM0MzY2XQoKCjMuICBSZWdpc3RyeSBEYXRhCgogICBSZWdpc3Ry eSBEYXRhIGNvbnNpc3RzIG9mIGJvdGggSW5kZXggb3IgS2V5IGRhdGEgYW5kIFJlc29sdXRpb24g ZGF0YS4KCjMuMS4gIEluZGV4L0tleSBEYXRhCgogICBUaGUgb3JnYW5pemF0aW9uIG9mIHJlZ2lz dHJ5IGRhdGEgaXMgYmFzZWQgb24gc3BlY2lmaWMgcGhvbmUgbnVtYmVycwogICBvciBwaG9uZSBu dW1iZXIgcHJlZml4ZXMgKHdoaWNoIGNvdWxkIHJlcHJlc2VudCBibG9ja3Mgb2YgcGhvbmUKICAg bnVtYmVycywgcmVnaW9ucywgb3IgdGhlb3JldGljYWxseSB3aG9sZSBjb3VudHJpZXMpLiAgRm9y IGdlbmVyYWxpdHksCiAgIHdlIHdpbGwgdXNlIHRoZSB0ZXJtIHByZWZpeCB0byBpbmNsdWRlIGNv bXBsZXRlIHBob25lIG51bWJlcnMgYXMKICAgd2VsbC4gIFByZWZpeGVzIGFyZSB0aGUgaW5kZXgg b3Iga2V5IHVzZWQgZm9yIGFsbCByZWdpc3RyeQogICBtYW5pcHVsYXRpb24gYW5kIGxvb2t1cHMu ICBFdmVuIHRob3VnaCBzb21lIG9mIHRoZSBudW1iZXJzCiAgIHJlcHJlc2VudGVkIHdpdGhpbiB0 aGVzZSBwcmVmaXhlcyBtYXkgbm90IGJlIGdsb2JhbGx5IHJlYWNoYWJsZSwgdGhlCiAgIHByZWZp eCBpdHNlbGYgbmVlZHMgdG8gYmUgZ2xvYmFsbHkgbm9ybWFsaXplZCBiZWZvcmUgaXQgY2FuIGJl CiAgIGVudGVyZWQgaW50byBhIHJlZ2lzdHJ5LiAgVGhlc2UgZ2xvYmFsbHkgbm9ybWFsaXplZCBw cmVmaXhlcyBhbHdheXMKCgoKU2Nod2FydHosIGV0IGFsLiAgICAgICBFeHBpcmVzIFNlcHRlbWJl ciAxMywgMjAwOCAgICAgICAgICAgICAgIFtQYWdlIDRdCgwKSW50ZXJuZXQtRHJhZnQgICAgICAg ICAgIENvbnNvbGlkYXRlZC1Qcm92LVByb2IgICAgICAgICAgICAgICBNYXJjaCAyMDA4CgoKICAg YmVnaW4gd2l0aCBhIHBsdXMgKCspIGFuZCBhIHRlbGVwaG9uZSBjb3VudHJ5IGNvZGUuICAoTm90 ZSB0aGF0CiAgIHByZWZpeGVzIGluIHNvbWUgY291bnRyaWVzIGNhbiBjb250YWluIGhleGFkZWNp bWFsIGRpZ2l0cykuCgogICBTaW5jZSBwcmVmaXhlcyBoYXZlIHZhcmlhYmxlIGxlbmd0aHMsIGEg cHJvdmlzaW9uaW5nIHByb3RvY29sIG11c3QgYmUKICAgYWJsZSB0byBlbnRlciBkYXRhIGZvciBh IHN1Yi1wcmVmaXggb3Igc3VwZXItcHJlZml4IG9mIGFuIGV4aXN0aW5nCiAgIHJlY29yZC4gIEZv ciBleGFtcGxlLCBpdCBtdXN0IGJlIHBvc3NpYmxlIHRvIGVudGVyIHJlY29yZHMgYWJvdXQKICAg IisxMjAyNTU1IiBhbmQgIisxMjAyNTU1MTIzNCIgYXQgdGhlIHNhbWUgdGltZS4gIEZvciBsb29r dXBzLAogICBpbmZvcm1hdGlvbiBhYm91dCB0aGUgbW9zdCBzcGVjaWZpYyBwcmVmaXggd2lsbCBi ZSByZXR1cm5lZC4gIFRoaXMKICAgYWxsb3dzIGZvciBzb21lIG1lYXN1cmUgb2YgYWdncmVnYXRp b24uICBBbHNvLCBpbiBvcmRlciB0byBwcm92aWRlCiAgIG1heGltYWwgZmxleGliaWxpdHkgYSBw cm92aXNpb25pbmcgcHJvdG9jb2wgbXVzdCBwcm92aWRlIGEgbWVjaGFuaXNtCiAgIGZvciBzcGVj aWZ5aW5nIGJvdGggbWluaW11bSBhbmQgbWF4aW11bSBudW1iZXIgb2YgZGlnaXRzIGluIGEgcHJl Zml4LgoKICAgQ29uc2lkZXJhdGlvbiBtdXN0IGJlIGdpdmVuIHRvIG92ZXJsYXBwaW5nIHJhbmdl cyB3aXRoIHNhbWUgbGVuZ3RoIGFzCiAgIGZvciBleGFtcGxlIHdoZW4gb25lIHByZWZpeCBjb3Zl cnMgMTAwMCAtIDMwMDAgYW5kIGFub3RoZXIgY292ZXJzCiAgIDIwMDAgLSA0MDAwLgoKMy4yLiAg UmVzb2x1dGlvbiBEYXRhCgogICBGb3IgZWFjaCBwcmVmaXgsIHRoZXJlIGlzIGEgdmFyaWV0eSBv ZiBkYXRhIHRoYXQgY2FuIGJlIGV4Y2hhbmdlZC4KICAgVGhlIG1vc3QgaW1wb3J0YW50IHNldCBv ZiBkYXRhIGlkZW50aWZpZXMgdGhhdCBhIHNwZWNpZmljIFZTUCBpcwogICByZXNwb25zaWJsZSBm b3IgdGhlIHByZWZpeCBhbmQgaW4gbW9zdCBjYXNlcyB0aGUgVlNQIHByb3ZpZGVzIGEgU0lQCiAg IFVSSSB0aHJvdWdoIHdoaWNoIHRoaXMgcHJlZml4IGNhbiBiZSBhZGRyZXNzZWQuICBJdCBpcyBu b3QgYXNzdW1lZAogICB0aGF0IHRoaXMgU0lQIFVSSSBpcyByZWNoYWJlIHZpYSB0aGUgcHVibGlj IEludGVybmV0IHVzaW5nIHRoZSBSRkMKICAgMzI2MyBwcm9jZXNzLiAgSW5zdGVhZCBhIGZ1cnRo ZXIgcm91dGluZyBhbGdvcml0aG0gbWlnaHQgYmUgbmVlZGVkIHRvCiAgIGZpbmQgYSBzdXRhYmxl IG5leHQgaG9wIHRvd2FyZHMgdGhlIGRlc3RpbmF0aW9uIG5ldHdvcmsuCgogICBJbiBjb21wbGV4 IGNhc2VzLCBzZXZlcmFsIFZTUHMgbWF5IGNsYWltIHNvbWUgZm9ybSBvZiByZXNwb25zaWJpbGl0 eQogICBmb3IgdGhlIHNhbWUgcHJlZml4LiAgV2UgY2FuIHVzZSB0aGUgdGVybSAibGFzdCBob3Ai IFZTUCB0byBkZXNjcmliZQogICB0aGUgVlNQIGNsb3Nlc3QgdG8gdGhlIGVuZC11c2VyIG9mIGEg cGhvbmUgbnVtYmVyLiAgVGhlIHByb3ZpZGVyIHdobwogICB3YXMgYXNzaWduZWQgYSBwcmVmaXgg YnkgdGhlIG5hdGlvbmFsIG51bWJlcmluZyBhdXRob3JpdHkgaXMgdGhlCiAgICJmaXJzdCBob3Ai IFZTUC4gIFRoZSBmaXJzdCBob3AgVlNQIG1heSBoYXZlIG5vIHdheSBvZiBrbm93aW5nIGlmIHRo ZQogICBsYXN0IGhvcCBWU1Agd2lsbCBpbmNsdWRlIGl0c2VsZiBpbiB0aGUgcmVnaXN0cnkuICBU aGVyZWZvcmUgaXQgaXMKICAgaW1wb3J0YW50IHRoYXQgdGhlIHF1ZXJpZXIgY2FuIG9idGFpbiBi b3RoIHJlY29yZHMgYW5kIHVzZSB0aGUgbW9zdAogICBzcGVjaWZpYyBvbmUgd2hpY2ggY29udGFp bnMgcmVhY2hhYmlsaXR5IGluZm9ybWF0aW9uLgoKICAgSW4gbWFueSBjYXNlcywgY29tbWVyY2lh bCByZWdpc3RyaWVzIGFsc28gY29udGFpbiBpbmZvcm1hdGlvbiB1c2VkCiAgIGZvciBMb2NhbCBO dW1iZXIgUG9ydGFiaWxpdHkuICBFdmVuIGlmIGEgcHJlZml4IGlzIG5vdCByZWFjaGFibGUgZm9y CiAgIElQIHBlZXJpbmcsIGl0IGlzIHVzZWZ1bCB0byBwcm92aWRlIHRoZSAiZGlwcGVkIiBudW1i ZXIgYW5kIGNhcnJpZXIKICAgY29kZS4gIFRoaXMgaW5mb3JtYXRpb24gY291bGQgYmUgcHJvdmlk ZWQgYXMgYSB0ZWwgVVJJIHdpdGggdGhlCiAgIG51bWJlciBwb3J0YWJpbGl0eSBhdHRyaWJ1dGVz IGRlZmluZWQgaW4gUkZDIDQ3NjkgW1JGQzQ3NjldLgogICBMaWtld2lzZSBpdCBpcyB2ZXJ5IHVz ZWZ1bCB0byBrbm93IHRoYXQgYSBwcmVmaXggaXMga25vd24gbm90IHRvCiAgIGV4aXN0IGFueXdo ZXJlLgoKICAgTGlrZSBzdGF0ZWQgaW4gdGhlIGludHJvZHVjdGlvbiBpdCBpcyBpbXBlcmF0aXZl IHRoYXQgdGhlIG1pbmltYWwgc2V0CiAgIG9mIHJlc29sdXRpb24gZGF0YSBjb250YWluIGFsbCB0 aGUgaW5mb3JtYXRpb24gcmVxdWlyZWQgZm9yIGEgRE5TCiAgIE5BUFRSIFJSLgoKICAgVGhlIHBy b3RvY29sIHNob3VsZCBiZSBlYXNpbHkgZXh0ZW5kaWJsZSBpbiB3YXlzIHRoYXQgYW50aWNpcGF0 ZSB0aGUKCgoKU2Nod2FydHosIGV0IGFsLiAgICAgICBFeHBpcmVzIFNlcHRlbWJlciAxMywgMjAw OCAgICAgICAgICAgICAgIFtQYWdlIDVdCgwKSW50ZXJuZXQtRHJhZnQgICAgICAgICAgIENvbnNv bGlkYXRlZC1Qcm92LVByb2IgICAgICAgICAgICAgICBNYXJjaCAyMDA4CgoKICAgYWRkaXRpb24g b2YgbmV3IEVOVU0gc2VydmljZSBkZWZpbml0aW9ucy4gIFdoaWxlIHdlIGhhdmUKICAgeC1lbnVt c2VydmljZXMgdG9kYXkgdGhhdCBlbmFibGUgZWFzeSBmdXR1cmVwcm9vZmluZyBvZiBOQVBUUgog ICByZWNvcmRzLCBhcyBzdGF0ZWQgYWJvdmUgd2UgZG8gbm90IHdhbnQgdG8gcHJlanVkaWNlIEVO VU0gYXQgdGhpcwogICBzdGVwIGFuZCBoZW5jZSB3ZSBzaG91bGQganVzdCBtYWtlIHN1cmUgdGhh dCB3ZSBjYW4gdHJhbnNtaXQKICAgYXJiaXRyYXJ5IGF0dHJpYnV0ZS92YWx1ZSBwYWlycyBkdXJp bmcgdGhlIHByb3Zpc2lvbmluZyBzdGVwLgoKICAgT25lIGZpbmFsIG5vdGUuICBPbmUgb2YgdGhl IGNvbW1vbiAicmV3cml0ZSIgcnVsZXMgZm9yIHRoZSBVUkkgaW4KICAgTkFQVFIgUlJzIGZvciBl eGFtcGxlIGlzIG9mIHRoZSBmb3JtICJcMUBzb21laG9zdC5jb21wYW55LmV4YW1wbGUiCiAgIHdo ZXJlIHRoZSAiXDEiIHJlZmVycyB0byB0aGUgdGVsZXBob25lIG51bWJlciBiZWluZyBwcm9jZXNz ZWQuICBUaGlzCiAgIGtpbmQgb2Ygc2hvcnRoYW5kIHNob3VsZCBiZSBhdmFpbGFibGUgd2hlbiBw cm9jZXNzaW5nIHByZWZpeGVzIGluCiAgIGJ1bGsgcmVnYXJkbGVzcyBvZiB3aGV0aGVyIEVOVU0g d2lsbCBiZSB0aGUgcXVlcnkgcHJvdG9jb2wuCgoKNC4gIFJlYWNoYWJpbGl0eSB2cy4gUm91dGlu ZwoKICAgVGhlIGdvYWwgb2YgdGhlIHJlZ2lzdHJ5IGlzIHRvIHByb3ZpZGUgc3VmZmljaWVudCBp bmZvcm1hdGlvbiB0bwogICBpZGVudGlmeSBhIHJlc3BvbnNpYmxlIFZTUCBmb3IgYSBwcmVmaXgu ICBUaGUgcmVzcG9uc2libGUgVlNQIGNhbgogICBwcm92aWRlIGEgU0lQIFVSSSB0aGF0IGNhbiBi ZSBwcm94aWVkIG9yIHJlZGlyZWN0ZWQgYXMgZGVzaXJlZCBieSB0aGUKICAgVlNQLiAgSXQgaXMg aW1wb3J0YW50IHRvIG5vdGUgdGhhdCB0aGUgcmVnaXN0cnkgaXMgZXhwZWN0ZWQgdG8gcmV0dXJu CiAgIHRoZSBzYW1lIHJlc3BvbnNpYmlsaXR5IGRhdGEgZm9yIGFsbCBwYXJ0aWVzIHRoYXQgcXVl cnkgaXQuCgogICBSb3V0aW5nIGluZm9ybWF0aW9uIGlzIGFsc28gb3V0IG9mIHNjb3BlIG9mIHRo ZSByZWdpc3RyeSBwcm92aXNpb25pbmcKICAgcHJvYmxlbS4gIE9uY2UgdGhlIGNhbGwgb3JpZ2lu YXRpbmcgVlNQIGhhcyBsZWFybmVkIHRoZSBpZGVudGl0eSBvZgogICB0aGUgcmVzcG9uc2libGUg VlNQLCB0aGUgTy1WU1AgY2FuIHVzZSBhIHZhcmlldHkgb2YgdGVjaG5pcXVlcyB0bwogICByb3V0 ZSB0aGF0IHJlcXVlc3QuICBGb3IgZXhhbXBsZSwgdGhlIFZTUCBjb3VsZCB1c2UgVFJJUCBbUkZD MzIxOV0sIGEKICAgcHJpdmF0ZSBkYXRhYmFzZSwgb3IgYSBTSVAgbG9jYXRpb24gc2VydmVyLiAg U2luY2UgdGhpcyBpbmZvcm1hdGlvbgogICBpcyBoaWdobHkgZHluYW1pYywgaXQgaXMgaW5hcHBy b3ByaWF0ZSB0byBwcm92aXNpb24gaW4gYSByZWdpc3RyeS4KCgo1LiAgT3BlcmF0aW9ucyBvbiB0 aGUgUmVnaXN0cnkgRGF0YQoKICAgQmVsb3cgaXMgYSBsaXN0IG9mIGxvZ2ljYWwgb3BlcmF0aW9u cyBvbiB0aGUgcmVnaXN0cnkgZGF0YS4gIFBsZWFzZQogICBub3RlIHRoYXQgYXMgc3RhdGVkIGFi b3ZlIGEgcHJvdmlzaW9uaW5nIHByb3RvY29sIE1VU1QgYXBwbHkgdGhlc2UKICAgb3BlcmF0aW9u cyBlcXVhbGx5IHRvIGluZGl2aWR1YWwgcHJlZml4ZXMgYXMgd2VsbCBhcyBwcmVmaXggYmxvY2tz LgoKICAgQWRkOiAgQWRkIChyZXNwb25zaWJsZSBWU1ApIGRhdGEgYWJvdXQgYSBuZXcgcHJlZml4 IHRvIHRoZSByZWdpc3RyeS4KCiAgIERlbGV0ZTogIFJlbW92ZSBhIHByZWZpeCBmcm9tIHRoZSBy ZWdpc3RyeS4gIFNlbWFudGljYWxseSBpdCBtZWFucwogICB0aGF0IHRoZSBwcmVmaXggbm8gbG9u Z2VyIGV4aXN0cyBhbnl3aGVyZS4KCiAgIFBvcnQtb3V0OiAgVGhlIHNlbWFudGljcyBhcmUgdGhh dCB0aGUgcHJlZml4IHN0aWxsIGV4aXN0cywgYnV0IHRoYXQKICAgdGhlIHByZXZpb3VzIFZTUCBp cyBubyBsb25nZXIgcmVzcG9uc2libGUgZm9yIGl0LiAgV2hpbGUgc2ltaWxhciB0byBhCiAgIERl bGV0ZSwgb25lIGRpZmZlcmVuY2UgaXMgdGhhdCBpbiB0aGUgY2FzZSBvZiBEZWxldGUsIGZ1cnRo ZXIgcmVxdWVzdAogICBjYW4gZ2V0IG1hdGNoZWQgYnkgc3VwZXItcHJlZml4ZXMgZXhpc3Rpbmcg aW4gdGhlIHJlZ2lzdHJ5LCB3aGVyZWFzCiAgIGluIHRoZSBQb3J0LW91dCBjYXNlIHRoZSByZWdp c3RyeSB3aWxsIHJldHVybiAibm90LWZvdW5kIiBldmVuIGlmIGEKICAgY29udGFpbmluZyBwcmVm aXggZXhpc3RzLgoKICAgUG9ydC1JbjogIEEgcG9ydC1pbiBpcyBzaW1pbGFyIHRvIGFuIGFkZCwg YnV0IHRoZSBzZW1hbnRpY3MgYXJlIHRoYXQKCgoKU2Nod2FydHosIGV0IGFsLiAgICAgICBFeHBp cmVzIFNlcHRlbWJlciAxMywgMjAwOCAgICAgICAgICAgICAgIFtQYWdlIDZdCgwKSW50ZXJuZXQt RHJhZnQgICAgICAgICAgIENvbnNvbGlkYXRlZC1Qcm92LVByb2IgICAgICAgICAgICAgICBNYXJj aCAyMDA4CgoKICAgdGhlIHByZWZpeCB3YXMgcHJldmlvdXNseSBhc3NpZ25lZCB0byBhIGRpZmZl cmVudCBwcm92aWRlci4KCiAgIFRyYW5zZmVyOiAgQSB0cmFuc2ZlciBpcyBhIHBvcnQtb3V0IGFu ZCBwb3J0LWluIG9wZXJhdGlvbiBwZXJmb3JtZWQKICAgYXRvbWljYWxseS4gIFRoaXMgb3BlcmF0 aW9uIGluc3VyZXMgdGhhdCBsb29rdXBzIGRvIG5vdCBmYWlsIGZvciB0aGUKICAgdHJhbnNmZXJy ZWQgcHJlZml4IGR1cmluZyB0aGUgdHJhbnNmZXIuCgogICBSZW51bWJlcjogIEEgcmVudW1iZXIg b3BlcmF0aW9uIG9jY3VycyB3aGVuIGEgc3BlY2lmaWMgcHJlZml4IGlzCiAgIGNvbXBsZXRlbHkg Y2hhbmdlZCwgYnV0IHRoZSBkYXRhIGNvcnJlc3BvbmRpbmcgdG8gdGhlIHByZWZpeCBoYXMgbm90 CiAgIGNoYW5nZWQuICBUaGlzIHR5cGljYWxseSBoYXBwZW5zIHdoZW4gYSBwcmVmaXggaXMgbGVu Z3RoZW5lZC4gIEZvcgogICBleGFtcGxlLCB3aGVuIEZyYW5jZSBtb3ZlZCBmcm9tIGFuIDgtZGln aXQgdG8gYSAxMC1kaWdpdCBkaWFsIHBsYW4sCiAgIHRoZSBjb3JyZXNwb25kaW5nIGdsb2JhbGx5 IG5vcm1hbGl6ZWQgcHJlZml4IGZvciBhIFBhcmlzaWFuIHBob25lCiAgIG51bWJlciBoYWQgYSAx IGluc2VydGVkIGJldHdlZW4gdGhlIGNvdW50cnkgY29kZSBhbmQgdGhlIG9sZCBwcmVmaXguCiAg IFJlbnVtYmVyaW5nIGNvdWxkIGFsc28gYWNjb21wbGlzaCBwcmVmaXggc2hvcnRlbmluZyAoYWx0 aG91Z2ggdGhpcyBpcwogICBxdWl0ZSB1bmxpa2VseSB0byBvY2N1cikgb3IgcHJlZml4IHNwbGl0 dGluZyAoaW4gdGhlIHBhc3QgVW5pdGVkCiAgIFN0YXRlcyBhcmVhIGNvZGVzIHdoZXJlIHNwbGl0 IHdoZW4gdGhleSB3ZXJlIGV4aGF1c3RlZCkuICBUaGUKICAgc2VtYW50aWNzIGFyZSB0aGF0IHRo ZXJlIGlzICJuZXciIHByZWZpeCBhdmFpbGFibGUgZm9yIGV4aXRpbmcgZGF0YQogICBpbiByZWdp c3RyeSAobm8gY2hhbmdlIHRvICJvd25lcnNoaXAiKSB3aGljaCBpbnZhbGlkYXRlcyB0aGUgcHJl dmlvdXMKICAgcHJlZml4LgoKICAgTW9kaWZ5OiAgQSBtb2RpZnkgb3BlcmF0aW9uIG9jY3VycyB3 aGVuIHNvbWUgb3RoZXIgYXR0cmlidXRlIG9mIGEKICAgcHJlZml4IGlzIG1vZGlmaWVkIChmb3Ig ZXhhbXBsZSB0aGUgdGFyZ2V0IFVSSSB1c2VkIGZvcgogICByZWFjaGFiaWxpdHkpLgoKCjYuICBP dGhlciBBdHJyaWJ1dGVzCgogICBBbGwgdGhlIHJlZ2lzdHJ5IHJlY29yZHMgd2lsbCBuZWVkIHRv IGluY2x1ZGUgc29tZSBraW5kIG9mIHZhbGlkaXR5CiAgIGluZm9ybWF0aW9uLiAgVGhlIHByb3Zp c2lvbmluZyBwcm90b2NvbCBjYW4gaW5kaWNhdGUgdGhhdCBhIHJlY29yZCBpcwogICBub3QgdmFs aWQgYmVmb3JlIG9uZSBkYXRlIGFuZCB0aW1lIGFuZCBubyBsb25nZXIgdmFsaWQgYWZ0ZXIgYW5v dGhlcgogICBkYXRlIGFuZCB0aW1lLgoKICAgSW4gYWRkaXRpb24gdG8gcmVzcG9uc2liaWxpdHkg ZGF0YSwgd2UgaGF2ZSBpZGVudGlmaWVkIHRoZSBmb2xsb3dpbmcKICAgZXh0cmEgYXR0cmlidXRl cyBhcyBpbXBvcnRhbnQgb3IgaW50ZXJlc3Rpbmc6CgogICBSZWdhcmRsZXNzIG9mIHdoaWNoIHBy b3RvY29sIGlzIHVzZWQsIGlzc3VlcyB0aGF0IHNob3VsZCBiZSBhZGRyZXNzZWQKICAgaW5jbHVk ZToKCiAgIE51bWJlciB0eXBlICh1bmtub3duLCBJUCwgUFNUTiwgYm90aCkKCiAgIFBTVE4gY2Fy cmllciBjb2RlIChmb3IgbnVtYmVycyB3aXRoIG5vIElQIHJlYWNoYWJpbGl0eSkKCiAgIEZlZSBj YXRlZ29yeSAoZnJlZSwgbGFuZGxpbmUsIG1vYmlsZSwgcGF5KQoKICAgTWVkaWEgdHlwZXMgc3Vw cG9ydGVkICh2b2ljZSwgdmlkZW8sIG1lc3NhZ2UpCgogICBUaGVyZSBNVVNUIGJlIGEgbWVjaGFu aXNtIGZvciBhbiBhdWRpdCB0cmFpbCBhcyBpc3N1ZXMgb2Ygb3duZXJzaGlwCiAgIGFyZSBib3Vu ZCB0byBzdXJmYWNlIGFuZCBhIGNsZWFybHkgZGVmaW5lZCBtZWNoYW5pc20gZm9yIHRyYWNraW5n CiAgIGNoYW5nZXMgdG8gcmVnaXN0cnkgZGF0YSBpcyBlc3NlbnRpYWwuCgoKClNjaHdhcnR6LCBl dCBhbC4gICAgICAgRXhwaXJlcyBTZXB0ZW1iZXIgMTMsIDIwMDggICAgICAgICAgICAgICBbUGFn ZSA3XQoMCkludGVybmV0LURyYWZ0ICAgICAgICAgICBDb25zb2xpZGF0ZWQtUHJvdi1Qcm9iICAg ICAgICAgICAgICAgTWFyY2ggMjAwOAoKCjcuICBEYXRhIEVuY29kaW5nCgogICBTaW5jZSBkYXRh IG1heSBuZWVkIHRvIHRyYXZlcnNlIGFkbWluaXN0cmF0aXZlIGRvbWFpbiBib3VuZGFyaWVzIHNv bWUKICAgdGhvdWdodCBuZWVkcyB0byBiZSBnaXZlbiB0byB0aGUgcmVuZGVyaW5nIG9mIHRoZSBt ZXNzYWdlcyBpbgogICB0cmFuc21pc3Npb24uICBUaGUgZW5jb2RpbmcgbWVjaGFuaXNtIE1VU1Qg YmUgcm9idXN0IGFuZCBlYXN5IHRvCiAgIGRlc2lnbiBhbmQgdHJvdWJsZXNob290IHdpdGggYSBz dHJvbmcgYmlhcyB0b3dhcmRzIGFuIGV4aXN0aW5nIGFuZAogICB3aWRlbHkgcmVjb2duaXplZCBz dGFuZGFyZC4KCgo4LiAgRGF0YSBNYW5hZ2VtZW50CgogICBEdWUgdG8gdGhlIGVudHJlbmNobWVu dCBvZiBsZWdhY3kgc29mdHdhcmUgZGV2ZWxvcG1lbnQgcHJvY2Vzc2VzCiAgIChlLmcuICBTT0FQ L1hNTCwgV1NETCwgVExTKSBpdCBpcyBvZiB1dG1vc3QgaW1wb3J0YW5jZSB0aGF0IHdoYXRldmVy CiAgIGVtZXJnZXMgZnJvbSB0aGlzIFdHIHNob3VsZCBiZSBlYXN5IHRvIGltcGxlbWVudCB3aXRo IGV4aXN0aW5nCiAgIG1ldGhvZG9sb2dpZXMuCgoKOS4gIERhdGEgUHJvcGFnYXRpb24KCiAgIFRo ZSB0cmFuc3BvcnQgbGF5ZXIgaXMgc3RyaWN0bHkgcG9pbnQtdG8tcG9pbnQsIHdpdGggbm8gY2Fj aGluZyBvcgogICBmb3J3YXJkaW5nLgoKCjEwLiAgUXVlcnlpbmcgVGhlIFJlZ2lzdHJ5CgogICBU aGUgZGVmaW5pdGlvbiBvZiB0aGUgcmVnaXN0cnkgcXVlcnkgbWVjaGFuaXNtIGlzIG91dCBvZiBz Y29wZSBmb3IKICAgdGhlIFBFUFBFUk1JTlQgYWN0aXZpdHkuICBIb3dldmVyLCBpdCBpcyBoZWxw ZnVsIHRvIGtub3cgd2hhdAogICBtZWNoYW5pc21zIGFyZSBpbiBwb3B1bGFyIHVzZSB0byB1bmRl cnN0YW5kIHRoZSBuZWNlc3NhcnkgcHJvcGVydGllcwogICBmb3IgYSBwcm92aXNpb25pbmcgaW50 ZXJmYWNlLiAgQXQgcHJlc2VudCwgdGhlcmUgYXJlIHR3byB3ZWxsLWtub3duCiAgIG1ldGhvZHMg dXNlZCBieSBWU1BzIHRvIHF1ZXJ5IGEgcGVlcmluZyByZWdpc3RyeS4gIFRoZXNlIGFyZSBFTlVN CiAgIFtSRkMzNzYxXSBhbmQgU0lQIFtSRkMzMjYxXS4KCiAgIEVOVU0gaXMgc2ltcGx5IGEgbWV0 aG9kIG9mIHVzaW5nIEROUy4gIEl0IGFsbG93cyBhIFZTUCB0byBxdWVyeSBhCiAgIHJlZ2lzdHJ5 IHdpdGggYSB0ZWxlcGhvbmUgbnVtYmVyLCBhbiBFLjE2NCBudW1iZXIgaW4gbW9zdCBjYXNlcywg YW5kCiAgIHJldHJpZXZlIGEgbGlzdCBvZiBVUklzLCBlYWNoIHdpdGggYSBzcGVjaWZpYyBwcmVm ZXJlbmNlIG9yZGVyLgoKICAgV2hlbiBTSVAgaXMgdXNlZCBmb3IgdGhlIHF1ZXJ5IG1lY2hhbmlz bSwgdGhlIG51bWJlcmluZyByZWdpc3RyeQogICBmdW5jdGlvbnMgYXMgYSBTSVAgcmVkaXJlY3Qg cHJveHkgW1JGQzMyNjFdIC4gIFRoZSBpbnB1dCB0byB0aGlzCiAgIG1lY2hhbmlzbSBpcyBhIFVS SSBvciBtb3JlIGltcG9ydGFudGx5IHRoZSBVc2VySW5mbyBwYXJ0IG9mIHRoZSBVUkkKICAgY29u dGFpbmluZyB0aGUgbnVtYmVyIHRvIGJlIHF1ZXJpZWQuICBUaGUgcmVzcG9uc2UgcmV0dXJuZWQg YnkgdGhlCiAgIHByb3h5IGlzIGVpdGhlciBhbiBlcnJvciBjb2RlIGluZGljYXRpbmcgdGhlIGFi c2VuY2Ugb2YgaW5mb3JtYXRpb24KICAgYWJvdXQgdGhlIG51bWJlciBxdWVyaWVkIG9yIGEgcmVk aXJlY3QgcmVzcG9uc2UgKDNYWCkgY29udGFpbmluZyAxCiAgIChvciBtb3JlKSBDb250YWN0IEhl YWRlcnMgcmVwcmVzZW50aW5nIG93bmVyc2hpcCBpbmZvcm1hdGlvbiBhcwogICBkZXNjcmliZWQg YWJvdmUuCgoKCgoKCgpTY2h3YXJ0eiwgZXQgYWwuICAgICAgIEV4cGlyZXMgU2VwdGVtYmVyIDEz LCAyMDA4ICAgICAgICAgICAgICAgW1BhZ2UgOF0KDApJbnRlcm5ldC1EcmFmdCAgICAgICAgICAg Q29uc29saWRhdGVkLVByb3YtUHJvYiAgICAgICAgICAgICAgIE1hcmNoIDIwMDgKCgoxMS4gIENv bnRyb2wKCiAgIFNpbmNlIGl0IG1heSBiZSBwb3NzaWJsZSB0byBib3RoIHB1c2ggYW5kIHB1bGwg ZGF0YSBpdCBpcyBpbXBlcmF0aXZlCiAgIHRoYXQgYSB0aHJvdHRsaW5nIG1lY2hhbmlzbSBleGlz dCB0byBjb250cm9sIHRoZSBmbG93IG9mIGRhdGEKICAgZXhjaGFuZ2UgYXQgYWxsIGxldmVscy4K CgoxMi4gIEV4aXN0aW5nIFRlY2hub2xvZ2llcwoKICAgdGhlcmUgaGFzIGJlZW4gc29tZSBjb25z aWRlcmF0aW9uIHRvIEVQUCBleHRlbnNpb25zIGZvciBFTlVNCiAgIFtSRkM0MTE0XSwgYW5kIHdo eSBpdCBoYXMgbm90IGJlZW4gYWRvcHRlZCBhbmQgd2h5IGEgcmVxdWlyZW1lbnRzCiAgIGRvY3Vt ZW50IGlzIG5vdyBiZWluZyBwcm9kdWNlZCB0byBjb3ZlciB3aGF0IHdvdWxkIHNlZW1pbmdseSBi ZQogICBhZGRyZXNzZWQgYnkgdGhhdCBzb2x1dGlvbi4KCiAgIFRoZXJlIGFyZSB0d28gcmVhc29u cyBmb3IgRVBQIG5vdCBiZWluZyBhZG9wdGVkLiAgT25lIGlzIHRoYXQgaXQKICAgaXNuJ3QgY29t cGF0aWJsZSB3aXRoIGxlZ2FjeSBwYXJ0aWNpcGFudHMuICBUaGUgb3RoZXIgcmVhc29uIGlzIHRo YXQKICAgaXQgcmVxdWlyZXMgbW9yZSBpbXBsZW1lbnRhdGlvbiB3b3JrLgoKICAgTGVnYWN5IHBh cnRpY2lwYW50cyBoYXZlIGFuIGV4aXN0aW5nIGJhc2Ugb2Ygc29mdHdhcmUgZGV2ZWxvcG1lbnQK ICAgYnVpbHQgYXJvdW5kIFNPQVAvWE1MIGFuZCBXU0RMLCBhbmQgYXJlIGZhbWlsaWFyIHdpdGgg VExTLgogICBBcHByb2FjaGVzIHRvIEVOVU0gcmVnaXN0cnkgaW50ZXJmYWNlcyB0aGF0IHVzZSB0 aGVzZSB0b29scyB3aWxsCiAgIGJsZW5kIG1vcmUgZWFzaWx5IGludG8gdGhlIHNvZnR3YXJlIHBy b2R1Y3RzIGFscmVhZHkgaW4gdXNlIHRvIG1hbmFnZQogICB0ZWxlcGhvbmUgbnVtYmVycy4KCiAg IFRoZSB1c2Ugb2YgU09BUCBwZXJtaXRzIGF1dG9tYXRpYyBnZW5lcmF0aW9uIG9mIHNvZnR3YXJl IHRvIGhhbmRsZQogICB0aGUgY2xpZW50IHNpZGUgb2YgdGhlIGV4Y2hhbmdlLiAgRG9tYWluIG5h bWUgcmVnaXN0cmllcyBoYWQgdG8KICAgcHJvdmlkZSBzb2Z0d2FyZSB0b29sIGtpdHMgdG8gZ2l2 ZSB0byByZWdpc3RyYXJzIHRvIG1hdGNoIHRoaXMKICAgZnVuY3Rpb25hbGl0eS4gIFdoZW4gYSBj aGFuZ2UgaXMgbWFkZSB0byBFUFAsIHRoZXJlIHdpbGwgYmUgYSBsb3Qgb2YKICAgc29mdHdhcmUg ZXhjaGFuZ2VkLgoKICAgRnJvbSBleHBlcmllbmNlIHdpdGggYm90aCBFUFAgYW5kIFNPQVAgYmFz ZWQgYXBwcm9hY2hlcyB0byByZWdpc3RyeQogICBzb2Z0d2FyZSwgdGhlIFNPQVAgYmFzZWQgYXBw cm9hY2ggaXMgbXVjaCBlYXNpZXIgb24gdGhlIHNvZnR3YXJlCiAgIGVuZ2luZWVyaW5nIHByb2Nl c3MuICBUaGUgZGlmZmVyZW5jZSBiZXR3ZWVuIHRoZSBhcHByb2FjaGVzIGlzIG5vdAogICBzZWVu IGluIGEgcHJvdG9jb2wgYW5hbHlzaXMsIGJ1dCBpbiBhbiBhbmFseXNpcyBvZiBzb2Z0d2FyZQog ICBlbmdpbmVlcmluZy4KCgoxMy4gIFNlY3VyaXR5IENvbnNpZGVyYXRpb25zCgogICBTZWN1cml0 eSBpcyB0byBiZSBpbXBsZW1lbnRlZCBpbiB0aGUgYXBwbGljYXRpb25zIGV4Y2hhbmdpbmcgZGF0 YSwKICAgdGhlIHJlcXVpcmVtZW50cyBoZXJlIGFyZSBtZWFudCB0byBzYXkgdGhhdCByZWxldmFu dCBzZWN1cml0eSBkYXRhCiAgIHdpbGwgYmUgZXhjaGFuZ2VkIGluIHRoZSBidWlsZGluZyBvZiB0 aGUgdHJhbnNwb3J0LiAgU3BlY2lmaWNhbGx5LAogICBkYXRhIGludGVncml0eSwgYXV0aGVudGlj YXRpb24gYW5kIHNlY3JlY3kuICAoUGxlYXNlIG5vdGUgdGhhdCBhbGwKICAgdGhyZWUgb2YgdGhl c2UgY2FuIGJlIHByb3ZpZGVkIGJ5IHVzaW5nIFRMUywgd2l0aCB0aGUgY2VydGlmaWNhdGUKICAg aGFuZHNoYWtlIGJlaW5nIHVzZWQgYnkgdGhlIGFwcGxpY2F0aW9uIHRvIGNvbXBsZXRlIHRoZSBz ZWN1cml0eQogICBuZWVkcykuCgoKCgoKU2Nod2FydHosIGV0IGFsLiAgICAgICBFeHBpcmVzIFNl cHRlbWJlciAxMywgMjAwOCAgICAgICAgICAgICAgIFtQYWdlIDldCgwKSW50ZXJuZXQtRHJhZnQg ICAgICAgICAgIENvbnNvbGlkYXRlZC1Qcm92LVByb2IgICAgICAgICAgICAgICBNYXJjaCAyMDA4 CgoKMTQuICBJQU5BIENvbnNpZGVyYXRpb25zCgogICBOQQoKCjE1LiAgQWNrbm93bGVkZ2VtZW50 cwoKICAgTWFueSBvZiB0aGUgcG9pbnRzIG9mIGluZm9ybWF0aW9uIGluIHRoaXMgZG9jdW1lbnQg YXJlIHN1bW1hcml6YXRpb25zCiAgIG9mIG9iamVjdGl2ZXMgYW5kIHN0YXRlbWVudHMgbWFkZSBi eSBpbmRpdmlkdWFscyBvbiB0aGUgUEVQUEVSTUlOVAogICBhbmQgU1BFRVJNSU5UIG1haWxpbmcg bGlzdHMuICBXZSB3b3VsZCBhbHNvIGxpa2UgdG8gYWNrbm93bGVkZ2UKICAgSmVyZW15IEJhcmth biBhbmQgT3RtYXIgTGVuZGwgZm9yIHByb3ZpZGluZyBpbnNpZ2h0ZnVsIGlucHV0cyB0byB0aGUK ICAgb3JpZ2luYWwgZHJhZnQuICBJbmZvcm1hdGlvbiBvbiB0aGUgUEVQUEVSTUlOVCBtYWlsaW5n IGxpc3QgY2FuIGJlCiAgIGZvdW5kIGF0IGh0dHA6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0 aW5mby9wZXBwZXJtaW50LgoKCjE2LiAgUmVmZXJlbmNlcwoKMTYuMS4gIE5vcm1hdGl2ZSBSZWZl cmVuY2VzCgogICBbUkZDMjExOV0gIEJyYWRuZXIsIFMuLCAiS2V5IHdvcmRzIGZvciB1c2UgaW4g UkZDcyB0byBJbmRpY2F0ZQogICAgICAgICAgICAgIFJlcXVpcmVtZW50IExldmVscyIsIEJDUCAx NCwgUkZDIDIxMTksIE1hcmNoIDE5OTcuCgogICBbUkZDMzI2MV0gIFJvc2VuYmVyZywgSi4sIFNj aHVsenJpbm5lLCBILiwgQ2FtYXJpbGxvLCBHLiwgSm9obnN0b24sCiAgICAgICAgICAgICAgQS4s IFBldGVyc29uLCBKLiwgU3BhcmtzLCBSLiwgSGFuZGxleSwgTS4sIGFuZCBFLgogICAgICAgICAg ICAgIFNjaG9vbGVyLCAiU0lQOiBTZXNzaW9uIEluaXRpYXRpb24gUHJvdG9jb2wiLCBSRkMgMzI2 MSwKICAgICAgICAgICAgICBKdW5lIDIwMDIuCgoxNi4yLiAgSW5mb3JtYXRpb25hbCBSZWZlcmVu Y2VzCgogICBbUkZDMTAzNF0gIE1vY2thcGV0cmlzLCBQLiwgIkRvbWFpbiBuYW1lcyAtIGNvbmNl cHRzIGFuZCBmYWNpbGl0aWVzIiwKICAgICAgICAgICAgICBTVEQgMTMsIFJGQyAxMDM0LCBOb3Zl bWJlciAxOTg3LgoKICAgW1JGQzEwMzVdICBNb2NrYXBldHJpcywgUC4sICJEb21haW4gbmFtZXMg LSBpbXBsZW1lbnRhdGlvbiBhbmQKICAgICAgICAgICAgICBzcGVjaWZpY2F0aW9uIiwgU1REIDEz LCBSRkMgMTAzNSwgTm92ZW1iZXIgMTk4Ny4KCiAgIFtSRkMzNDAzXSAgTWVhbGxpbmcsIE0uLCAi RHluYW1pYyBEZWxlZ2F0aW9uIERpc2NvdmVyeSBTeXN0ZW0gKERERFMpCiAgICAgICAgICAgICAg UGFydCBUaHJlZTogVGhlIERvbWFpbiBOYW1lIFN5c3RlbSAoRE5TKSBEYXRhYmFzZSIsCiAgICAg ICAgICAgICAgUkZDIDM0MDMsIE9jdG9iZXIgMjAwMi4KCiAgIFtSRkMzMjE5XSAgUm9zZW5iZXJn LCBKLiwgU2FsYW1hLCBILiwgYW5kIE0uIFNxdWlyZSwgIlRlbGVwaG9ueQogICAgICAgICAgICAg IFJvdXRpbmcgb3ZlciBJUCAoVFJJUCkiLCBSRkMgMzIxOSwgSmFudWFyeSAyMDAyLgoKICAgW1JG QzM3MzBdICBIb2xsZW5iZWNrLCBTLiwgIkV4dGVuc2libGUgUHJvdmlzaW9uaW5nIFByb3RvY29s IChFUFApIiwKICAgICAgICAgICAgICBSRkMgMzczMCwgTWFyY2ggMjAwNC4KCiAgIFtSRkMzNzYx XSAgRmFsdHN0cm9tLCBQLiBhbmQgTS4gTWVhbGxpbmcsICJUaGUgRS4xNjQgdG8gVW5pZm9ybQog ICAgICAgICAgICAgIFJlc291cmNlIElkZW50aWZpZXJzIChVUkkpIER5bmFtaWMgRGVsZWdhdGlv biBEaXNjb3ZlcnkKICAgICAgICAgICAgICBTeXN0ZW0gKERERFMpIEFwcGxpY2F0aW9uIChFTlVN KSIsIFJGQyAzNzYxLCBBcHJpbCAyMDA0LgoKCgpTY2h3YXJ0eiwgZXQgYWwuICAgICAgIEV4cGly ZXMgU2VwdGVtYmVyIDEzLCAyMDA4ICAgICAgICAgICAgICBbUGFnZSAxMF0KDApJbnRlcm5ldC1E cmFmdCAgICAgICAgICAgQ29uc29saWRhdGVkLVByb3YtUHJvYiAgICAgICAgICAgICAgIE1hcmNo IDIwMDgKCgogICBbUkZDMzk4Nl0gIEJlcm5lcnMtTGVlLCBULiwgRmllbGRpbmcsIFIuLCBhbmQg TC4gTWFzaW50ZXIsICJVbmlmb3JtCiAgICAgICAgICAgICAgUmVzb3VyY2UgSWRlbnRpZmllciAo VVJJKTogR2VuZXJpYyBTeW50YXgiLCBTVEQgNjYsCiAgICAgICAgICAgICAgUkZDIDM5ODYsIEph bnVhcnkgMjAwNS4KCiAgIFtSRkM0MTE0XSAgSG9sbGVuYmVjaywgUy4sICJFLjE2NCBOdW1iZXIg TWFwcGluZyBmb3IgdGhlIEV4dGVuc2libGUKICAgICAgICAgICAgICBQcm92aXNpb25pbmcgUHJv dG9jb2wgKEVQUCkiLCBSRkMgNDExNCwgSnVuZSAyMDA1LgoKICAgW1JGQzQzNjZdICBCbGFrZS1X aWxzb24sIFMuLCBOeXN0cm9tLCBNLiwgSG9wd29vZCwgRC4sIE1pa2tlbHNlbiwgSi4sCiAgICAg ICAgICAgICAgYW5kIFQuIFdyaWdodCwgIlRyYW5zcG9ydCBMYXllciBTZWN1cml0eSAoVExTKQog ICAgICAgICAgICAgIEV4dGVuc2lvbnMiLCBSRkMgNDM2NiwgQXByaWwgMjAwNi4KCiAgIFtSRkM0 NzY5XSAgTGl2aW5nb29kLCBKLiBhbmQgUi4gU2hvY2tleSwgIklBTkEgUmVnaXN0cmF0aW9uIGZv ciBhbgogICAgICAgICAgICAgIEVudW1zZXJ2aWNlIENvbnRhaW5pbmcgUHVibGljIFN3aXRjaGVk IFRlbGVwaG9uZSBOZXR3b3JrCiAgICAgICAgICAgICAgKFBTVE4pIFNpZ25hbGluZyBJbmZvcm1h dGlvbiIsIFJGQyA0NzY5LCBOb3ZlbWJlciAyMDA2LgoKICAgW0ktRC5pZXRmLXNwZWVybWludC10 ZXJtaW5vbG9neV0KICAgICAgICAgICAgICBNYWxhcywgRC4gYW5kIEQuIE1heWVyLCAiU1BFRVJN SU5UIFRlcm1pbm9sb2d5IiwKICAgICAgICAgICAgICAgZHJhZnQtaWV0Zi1zcGVlcm1pbnQtdGVy bWlub2xvZ3ktMTUudHh0LCBOb3ZlbWJlciAyMDA3LgoKCkF1dGhvcnMnIEFkZHJlc3NlcwoKICAg RGF2aWQgU2Nod2FydHoKICAgWENvbm5lY3QgR2xvYmFsIE5ldHdvcmtzCiAgIE1hbGNoYSBUZWNo bm9sb2d5IFBhcmsKICAgQnVpbGRpbmcgIyAxCiAgIEplcnVzYWxlbSAgOTA5NjEKICAgSXNyYWVs CgogICBQaG9uZTogICs5NzIgNTIgMzQ3IDQ2NTYKICAgRW1haWw6ICBkc2Nod2FydHpAeGNvbm5l Y3QubmV0CiAgIFVSSTogICAgd3d3LmtheW90ZS5jb20KCgogICBSb2hhbiBNYWh5CiAgIFBsYW50 cm9uaWNzCgogICBFbWFpbDogIHJvaGFuQGVrYWJhbC5jb20KICAgVVJJOiAgICB3d3cucGxhbnRy b25pY3MuY29tCgoKICAgQWxhbiBEdXJpYwogICBUZWxpbwoKICAgRW1haWw6ICBhbGFuLmR1cmlj QHRlbGlvLm5vCiAgIFVSSTogICAgd3d3LnRlbGlvLm5vCgoKCgoKU2Nod2FydHosIGV0IGFsLiAg ICAgICBFeHBpcmVzIFNlcHRlbWJlciAxMywgMjAwOCAgICAgICAgICAgICAgW1BhZ2UgMTFdCgwK SW50ZXJuZXQtRHJhZnQgICAgICAgICAgIENvbnNvbGlkYXRlZC1Qcm92LVByb2IgICAgICAgICAg ICAgICBNYXJjaCAyMDA4CgoKICAgRWR3YXJkIExld2lzCiAgIE5ldVN0YXIKICAgNDYwMDAgQ2Vu dGVyIE9hayBQbGF6YQogICBCdWlsZGluZyAjIDEKICAgU3RlcmxpbmcsIFZBICAyMDE2NgogICBV U0EKCiAgIFBob25lOiAgKzEtNTcxLTQzNC01NDY4CiAgIEVtYWlsOiAgZWQubGV3aXNAbmV1c3Rh ci5iaXoKICAgVVJJOiAgICB3d3cubmV1c3Rhci5iaXoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoK CgoKCgoKCgoKCgoKCgoKCgpTY2h3YXJ0eiwgZXQgYWwuICAgICAgIEV4cGlyZXMgU2VwdGVtYmVy IDEzLCAyMDA4ICAgICAgICAgICAgICBbUGFnZSAxMl0KDApJbnRlcm5ldC1EcmFmdCAgICAgICAg ICAgQ29uc29saWRhdGVkLVByb3YtUHJvYiAgICAgICAgICAgICAgIE1hcmNoIDIwMDgKCgpGdWxs IENvcHlyaWdodCBTdGF0ZW1lbnQKCiAgIENvcHlyaWdodCAoQykgVGhlIElFVEYgVHJ1c3QgKDIw MDgpLgoKICAgVGhpcyBkb2N1bWVudCBpcyBzdWJqZWN0IHRvIHRoZSByaWdodHMsIGxpY2Vuc2Vz IGFuZCByZXN0cmljdGlvbnMKICAgY29udGFpbmVkIGluIEJDUCA3OCwgYW5kIGV4Y2VwdCBhcyBz ZXQgZm9ydGggdGhlcmVpbiwgdGhlIGF1dGhvcnMKICAgcmV0YWluIGFsbCB0aGVpciByaWdodHMu CgogICBUaGlzIGRvY3VtZW50IGFuZCB0aGUgaW5mb3JtYXRpb24gY29udGFpbmVkIGhlcmVpbiBh cmUgcHJvdmlkZWQgb24gYW4KICAgIkFTIElTIiBiYXNpcyBhbmQgVEhFIENPTlRSSUJVVE9SLCBU SEUgT1JHQU5JWkFUSU9OIEhFL1NIRSBSRVBSRVNFTlRTCiAgIE9SIElTIFNQT05TT1JFRCBCWSAo SUYgQU5ZKSwgVEhFIElOVEVSTkVUIFNPQ0lFVFksIFRIRSBJRVRGIFRSVVNUIEFORAogICBUSEUg SU5URVJORVQgRU5HSU5FRVJJTkcgVEFTSyBGT1JDRSBESVNDTEFJTSBBTEwgV0FSUkFOVElFUywg RVhQUkVTUwogICBPUiBJTVBMSUVELCBJTkNMVURJTkcgQlVUIE5PVCBMSU1JVEVEIFRPIEFOWSBX QVJSQU5UWSBUSEFUIFRIRSBVU0UgT0YKICAgVEhFIElORk9STUFUSU9OIEhFUkVJTiBXSUxMIE5P VCBJTkZSSU5HRSBBTlkgUklHSFRTIE9SIEFOWSBJTVBMSUVECiAgIFdBUlJBTlRJRVMgT0YgTUVS Q0hBTlRBQklMSVRZIE9SIEZJVE5FU1MgRk9SIEEgUEFSVElDVUxBUiBQVVJQT1NFLgoKCkludGVs bGVjdHVhbCBQcm9wZXJ0eQoKICAgVGhlIElFVEYgdGFrZXMgbm8gcG9zaXRpb24gcmVnYXJkaW5n IHRoZSB2YWxpZGl0eSBvciBzY29wZSBvZiBhbnkKICAgSW50ZWxsZWN0dWFsIFByb3BlcnR5IFJp Z2h0cyBvciBvdGhlciByaWdodHMgdGhhdCBtaWdodCBiZSBjbGFpbWVkIHRvCiAgIHBlcnRhaW4g dG8gdGhlIGltcGxlbWVudGF0aW9uIG9yIHVzZSBvZiB0aGUgdGVjaG5vbG9neSBkZXNjcmliZWQg aW4KICAgdGhpcyBkb2N1bWVudCBvciB0aGUgZXh0ZW50IHRvIHdoaWNoIGFueSBsaWNlbnNlIHVu ZGVyIHN1Y2ggcmlnaHRzCiAgIG1pZ2h0IG9yIG1pZ2h0IG5vdCBiZSBhdmFpbGFibGU7IG5vciBk b2VzIGl0IHJlcHJlc2VudCB0aGF0IGl0IGhhcwogICBtYWRlIGFueSBpbmRlcGVuZGVudCBlZmZv cnQgdG8gaWRlbnRpZnkgYW55IHN1Y2ggcmlnaHRzLiAgSW5mb3JtYXRpb24KICAgb24gdGhlIHBy b2NlZHVyZXMgd2l0aCByZXNwZWN0IHRvIHJpZ2h0cyBpbiBSRkMgZG9jdW1lbnRzIGNhbiBiZQog ICBmb3VuZCBpbiBCQ1AgNzggYW5kIEJDUCA3OS4KCiAgIENvcGllcyBvZiBJUFIgZGlzY2xvc3Vy ZXMgbWFkZSB0byB0aGUgSUVURiBTZWNyZXRhcmlhdCBhbmQgYW55CiAgIGFzc3VyYW5jZXMgb2Yg bGljZW5zZXMgdG8gYmUgbWFkZSBhdmFpbGFibGUsIG9yIHRoZSByZXN1bHQgb2YgYW4KICAgYXR0 ZW1wdCBtYWRlIHRvIG9idGFpbiBhIGdlbmVyYWwgbGljZW5zZSBvciBwZXJtaXNzaW9uIGZvciB0 aGUgdXNlIG9mCiAgIHN1Y2ggcHJvcHJpZXRhcnkgcmlnaHRzIGJ5IGltcGxlbWVudGVycyBvciB1 c2VycyBvZiB0aGlzCiAgIHNwZWNpZmljYXRpb24gY2FuIGJlIG9idGFpbmVkIGZyb20gdGhlIElF VEYgb24tbGluZSBJUFIgcmVwb3NpdG9yeSBhdAogICBodHRwOi8vd3d3LmlldGYub3JnL2lwci4K CiAgIFRoZSBJRVRGIGludml0ZXMgYW55IGludGVyZXN0ZWQgcGFydHkgdG8gYnJpbmcgdG8gaXRz IGF0dGVudGlvbiBhbnkKICAgY29weXJpZ2h0cywgcGF0ZW50cyBvciBwYXRlbnQgYXBwbGljYXRp b25zLCBvciBvdGhlciBwcm9wcmlldGFyeQogICByaWdodHMgdGhhdCBtYXkgY292ZXIgdGVjaG5v bG9neSB0aGF0IG1heSBiZSByZXF1aXJlZCB0byBpbXBsZW1lbnQKICAgdGhpcyBzdGFuZGFyZC4g IFBsZWFzZSBhZGRyZXNzIHRoZSBpbmZvcm1hdGlvbiB0byB0aGUgSUVURiBhdAogICBpZXRmLWlw ckBpZXRmLm9yZy4KCgpBY2tub3dsZWRnbWVudAoKICAgRnVuZGluZyBmb3IgdGhlIFJGQyBFZGl0 b3IgZnVuY3Rpb24gaXMgcHJvdmlkZWQgYnkgdGhlIElFVEYKICAgQWRtaW5pc3RyYXRpdmUgU3Vw cG9ydCBBY3Rpdml0eSAoSUFTQSkuCgoKCgoKU2Nod2FydHosIGV0IGFsLiAgICAgICBFeHBpcmVz IFNlcHRlbWJlciAxMywgMjAwOCAgICAgICAgICAgICAgW1BhZ2UgMTNdCgwK ------_=_NextPart_001_01C88423.899EA377 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_001_01C88423.899EA377-- Return-Path: X-Original-To: ietfarch-peppermint-archive@core3.amsl.com Delivered-To: ietfarch-peppermint-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 6B6AB28C578; Wed, 12 Mar 2008 00:30:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -99.311 X-Spam-Level: X-Spam-Status: No, score=-99.311 tagged_above=-999 required=5 tests=[AWL=0.525, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_ORG=0.611, HTML_MESSAGE=0.001, J_CHICKENPOX_32=0.6, RDNS_NONE=0.1, 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 3GjnrukiYilP; Wed, 12 Mar 2008 00:30:07 -0700 (PDT) Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E489A28C557; Wed, 12 Mar 2008 00:30:07 -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 1CF0028C549 for ; Wed, 12 Mar 2008 00:30:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com 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 3jRhJcDbwUwk for ; Wed, 12 Mar 2008 00:30:04 -0700 (PDT) Received: from xconnect.net (host81-149-118-212.in-addr.btopenworld.com [81.149.118.212]) by core3.amsl.com (Postfix) with ESMTP id CED3228C557 for ; Wed, 12 Mar 2008 00:30:03 -0700 (PDT) X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Wed, 12 Mar 2008 07:26:32 -0000 Message-ID: <062B8EE81F2EC945A577C3EFAE1DD68E9961B3@mail.xconnect.net> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [PEPPERMINT] some comments onconsolidated-provisioning-problem-statement-00 Thread-Index: AciDxB3lEYePwC7mQf2oYGCn1kaVmwATkcyj References: <20080311220602.GA24046@nic.at> From: "David Schwartz" To: "Otmar Lendl" , Subject: Re: [PEPPERMINT] some comments onconsolidated-provisioning-problem-statement-00 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: multipart/mixed; boundary="===============0785606631==" Sender: peppermint-bounces@ietf.org Errors-To: peppermint-bounces@ietf.org This is a multi-part message in MIME format. --===============0785606631== Content-class: urn:content-classes:message Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C88412.8F67892E" This is a multi-part message in MIME format. ------_=_NextPart_001_01C88412.8F67892E Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hi Otmar. Thanks for the input and nice catch with the 3XX redirect responses. D. -----Original Message----- From: peppermint-bounces@ietf.org on behalf of Otmar Lendl Sent: Tue 3/11/2008 10:06 PM To: peppermint@ietf.org Subject: [PEPPERMINT] some comments = onconsolidated-provisioning-problem-statement-00 =20 Some quick words on David's draft: Overall: very good draft. It captures the core concepts we need. >3.1. Index/Key Data > > The organization of registry data is based on specific phone numbers > or phone number prefixes (which could represent blocks of phone > numbers, regions, or theoretically whole countries). For = generality, > we will use the term prefix to include complete phone numbers as > well.=20 Good catch. That makes the data modelling easier and covers both open and closed numbering plans. > These globally normalized prefixes always > begin with a plus (+) and a telephone country code. =20 That's a good idea to make it clear that prefixes are fully qualified. Maybe tweak the language a bit: "..prefixes are always written with a leading + to avoid confusions"). > >3.2. Resolution Data > > For each prefix, there is a variety of data that can be exchanged. > The most important set of data identifies that a specific VSP is > responsible for the prefix and in most cases the VSP provides a SIP > URI through which this prefix can be reached. "reached" is maybe too strong. "addressed" might be better. Perhaps add here a sentence stating that it is _not_ assumed that this SIP URI is reachable via the public Internet using the RFC3263 process. Instead, a further routing algorithm might be needed to find a suitable next hop towards the destination network. > > Like stated in the introduction it is imperative that the minimal = set > of resolution data contain all the information required for a DNS > NAPTR RR. > I don't quite understand this sentence. Without specifying for which enum-service you want to construct a NAPTR, it's hard to describe the minimal set of data needed. > Additionally, as a future proofing mechanism it is recommended that > resolution data include a catchall (similar to a DNS TXT RR) for = data > that is not currently present in any ENUM service definitions. I don't quite get it. We have x- enumservices and quite generic uri-schemes like data:, so we can put anything into NAPTRs.=20 (which prejudices ENUM, which IMHO we shouldn't do at this step) As we're talking about the provisioning protocol, we just need to make sure we either can transmit arbitrary attribute/value pairs during the provisioning step. > One final note. One of the common "rewrite" rules for the URI in > NAPTR RRs for example is of the form "\1@somehost.company.example" > where the "\1" refers to the telephone number being processed. This > kind of shorthand should be available when processing prefixes in > bulk. "..regardless of whether ENUM will be the query protocol". >4. Reachability vs. Routing > > The goal of the registry is to provide sufficient information to > identify a responsible VSP for a prefix. The responsible VSP can > provide a SIP URI that can be proxied or redirected as desired by = the > VSP. It is important to note that the registry is expected to = return > the same responsibility data for all parties that query it. Nicely put. Good. > Routing information is also out of scope of the registry = provisioning > problem. Once a responsible VSP is contacted, that VSP can use a > variety of techniques to route that request. =20 hm. Shouldn't that be "Once the call originating VSP has learned the identity of the responsible VSP, the O-VSP can use a variety of techniques to route that request." ? > >5. Operations on the Registry Data > > Delete: Remove a prefix from the registry. Semantically it means > that the prefix no longer exists anywhere. > > Port-out: A port-out is similar to a delete, but could be logged > differently. The semantics are that the prefix still exists, but > that the previous VSP is no longer responsible for it. Perhaps note here that one difference between Delete and Port-out is that in the case of Delete, further request can get matched by super-prefixes existing in the registry, whereas in the Port-out case the registry will return "not-found" even if a containing prefix exists. >9. Data Propegation Propagation >10. Querying The Registry > > > When SIP is used for the query mechanism, the numbering registry > functions as a SIP redirect proxy [RFC3261] . The input to this > mechanism is a URI or more importantly the UserInfo part of the URI > containing the number to be queried. The response returned by the > proxy is either an error code indicating the absence of information > about the number queried or a redirect response (3XX) containing 1 > (or more) Contact Headers representing available routing options. Whoa, stop here.=20 In 4. you wrote that the registry contains ownership information, not routing information. /ol --=20 // 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 _______________________________________________ PEPPERMINT mailing list PEPPERMINT@ietf.org https://www.ietf.org/mailman/listinfo/peppermint ______________________________________________________________________ This email has been scanned by the MessageLabs Email Security System. For more information please visit http://www.messagelabs.com/email=20 ______________________________________________________________________ ------_=_NextPart_001_01C88412.8F67892E Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable RE: [PEPPERMINT] some comments = onconsolidated-provisioning-problem-statement-00

Hi Otmar.

Thanks for the input and nice catch with the 3XX redirect responses.

D.


-----Original Message-----
From: peppermint-bounces@ietf.org on behalf of Otmar Lendl
Sent: Tue 3/11/2008 10:06 PM
To: peppermint@ietf.org
Subject: [PEPPERMINT] some comments = onconsolidated-provisioning-problem-statement-00


Some quick words on David's draft:

Overall: very good draft. It captures the core concepts we need.


>3.1.  Index/Key Data
>
>   The organization of registry data is based on specific = phone numbers
>   or phone number prefixes (which could represent blocks = of phone
>   numbers, regions, or theoretically whole = countries).  For generality,
>   we will use the term prefix to include complete phone = numbers as
>   well.

Good catch. That makes the data modelling easier and covers both
open and closed numbering plans.

>           &nb= sp;           &nbs= p;     These globally normalized prefixes always
>   begin with a plus (+) and a telephone country = code. 

That's a good idea to make it clear that prefixes are fully = qualified.
Maybe tweak the language a bit: "..prefixes are always written with = a
leading + to avoid confusions").

>
>3.2.  Resolution Data
>
>   For each prefix, there is a variety of data that can be = exchanged.
>   The most important set of data identifies that a = specific VSP is
>   responsible for the prefix and in most cases the VSP = provides a SIP
>   URI through which this prefix can be reached.

"reached" is maybe too strong. "addressed" might be = better.

Perhaps add here a sentence stating that it is _not_ assumed that = this
SIP URI is reachable via the public Internet using the RFC3263 = process.
Instead, a further routing algorithm might be needed to find a = suitable
next hop towards the destination network.

>
>   Like stated in the introduction it is imperative that = the minimal set
>   of resolution data contain all the information required = for a DNS
>   NAPTR RR.
>

I don't quite understand this sentence. Without specifying for which
enum-service you want to construct a NAPTR, it's hard to describe
the minimal set of data needed.

>   Additionally, as a future proofing mechanism it is = recommended that
>   resolution data include a catchall (similar to a DNS = TXT RR) for data
>   that is not currently present in any ENUM service = definitions.


I don't quite get it. We have x- enumservices and quite generic
uri-schemes like data:, so we can put anything into NAPTRs.
(which prejudices ENUM, which IMHO we shouldn't do at this step)

As we're talking about the provisioning protocol, we just need to = make
sure we either can transmit arbitrary attribute/value pairs during = the
provisioning step.

>   One final note.  One of the common = "rewrite" rules for the URI in
>   NAPTR RRs for example is of the form = "\1@somehost.company.example"
>   where the "\1" refers to the telephone number = being processed.  This
>   kind of shorthand should be available when processing = prefixes in
>   bulk.

"..regardless of whether ENUM will be the query protocol".

>4.  Reachability vs. Routing
>
>   The goal of the registry is to provide sufficient = information to
>   identify a responsible VSP for a prefix.  The = responsible VSP can
>   provide a SIP URI that can be proxied or redirected as = desired by the
>   VSP.  It is important to note that the registry is = expected to return
>   the same responsibility data for all parties that query = it.

Nicely put. Good.

>   Routing information is also out of scope of the = registry provisioning
>   problem.  Once a responsible VSP is contacted, = that VSP can use a
>   variety of techniques to route that request. 

hm. Shouldn't that be "Once the call originating VSP has learned = the
identity of the responsible VSP, the O-VSP can use a variety of
techniques to route that request." ?

>
>5.  Operations on the Registry Data
>
>   Delete:  Remove a prefix from the registry.  = Semantically it means
>   that the prefix no longer exists anywhere.
>
>   Port-out:  A port-out is similar to a delete, but = could be logged
>   differently.  The semantics are that the prefix = still exists, but
>   that the previous VSP is no longer responsible for = it.

Perhaps note here that one difference between Delete and Port-out is
that in the case of Delete, further request can get matched by
super-prefixes existing in the registry, whereas in the Port-out = case
the registry will return "not-found" even if a containing = prefix exists.

>9.  Data Propegation

Propagation

>10.  Querying The Registry
>
>
>   When SIP is used for the query mechanism, the numbering = registry
>   functions as a SIP redirect proxy [RFC3261] .  The = input to this
>   mechanism is a URI or more importantly the UserInfo = part of the URI
>   containing the number to be queried.  The response = returned by the
>   proxy is either an error code indicating the absence of = information
>   about the number queried or a redirect response (3XX) = containing 1
>   (or more) Contact Headers representing available = routing options.

Whoa, stop here.

In 4. you wrote that the registry contains ownership information, = not
routing information.

/ol
--
// Otmar Lendl <lendl@nic.at>, 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
_______________________________________________
PEPPERMINT mailing list
PEPPERMINT@ietf.org
https://www.iet= f.org/mailman/listinfo/peppermint

______________________________________________________________________ This email has been scanned by the MessageLabs Email Security = System.
For more information please visit http://www.messagelabs.com/emai= l
______________________________________________________________________

------_=_NextPart_001_01C88412.8F67892E-- --===============0785606631== 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 --===============0785606631==-- Return-Path: X-Original-To: ietfarch-peppermint-archive@core3.amsl.com Delivered-To: ietfarch-peppermint-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 3B24F28C31A; Tue, 11 Mar 2008 15:08:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -99.872 X-Spam-Level: X-Spam-Status: No, score=-99.872 tagged_above=-999 required=5 tests=[AWL=-0.035, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_ORG=0.611, J_CHICKENPOX_32=0.6, RDNS_NONE=0.1, 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 v+JoalGOJas5; Tue, 11 Mar 2008 15:08:25 -0700 (PDT) Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B4A9F3A6E2B; Tue, 11 Mar 2008 15:08: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 AA2A73A6E2B for ; Tue, 11 Mar 2008 15:08:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com 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 ZekAx9tvEh2M for ; Tue, 11 Mar 2008 15:08:23 -0700 (PDT) Received: from labs.nic.at (nat.labs.nic.at [83.136.33.3]) by core3.amsl.com (Postfix) with ESMTP id C022A28C216 for ; Tue, 11 Mar 2008 15:08:22 -0700 (PDT) Received: from lendl by labs.nic.at with local (Exim 3.36 #1 (Debian)) id 1JZCbi-0006Fy-00 for ; Tue, 11 Mar 2008 23:06:02 +0100 Date: Tue, 11 Mar 2008 23:06:02 +0100 From: Otmar Lendl To: peppermint@ietf.org Message-ID: <20080311220602.GA24046@nic.at> Mail-Followup-To: Otmar Lendl , peppermint@ietf.org Mime-Version: 1.0 Content-Disposition: inline User-Agent: Mutt/1.5.9i Subject: [PEPPERMINT] some comments on consolidated-provisioning-problem-statement-00 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 quick words on David's draft: Overall: very good draft. It captures the core concepts we need. >3.1. Index/Key Data > > The organization of registry data is based on specific phone numbers > or phone number prefixes (which could represent blocks of phone > numbers, regions, or theoretically whole countries). For generality, > we will use the term prefix to include complete phone numbers as > well. Good catch. That makes the data modelling easier and covers both open and closed numbering plans. > These globally normalized prefixes always > begin with a plus (+) and a telephone country code. That's a good idea to make it clear that prefixes are fully qualified. Maybe tweak the language a bit: "..prefixes are always written with a leading + to avoid confusions"). > >3.2. Resolution Data > > For each prefix, there is a variety of data that can be exchanged. > The most important set of data identifies that a specific VSP is > responsible for the prefix and in most cases the VSP provides a SIP > URI through which this prefix can be reached. "reached" is maybe too strong. "addressed" might be better. Perhaps add here a sentence stating that it is _not_ assumed that this SIP URI is reachable via the public Internet using the RFC3263 process. Instead, a further routing algorithm might be needed to find a suitable next hop towards the destination network. > > Like stated in the introduction it is imperative that the minimal set > of resolution data contain all the information required for a DNS > NAPTR RR. > I don't quite understand this sentence. Without specifying for which enum-service you want to construct a NAPTR, it's hard to describe the minimal set of data needed. > Additionally, as a future proofing mechanism it is recommended that > resolution data include a catchall (similar to a DNS TXT RR) for data > that is not currently present in any ENUM service definitions. I don't quite get it. We have x- enumservices and quite generic uri-schemes like data:, so we can put anything into NAPTRs. (which prejudices ENUM, which IMHO we shouldn't do at this step) As we're talking about the provisioning protocol, we just need to make sure we either can transmit arbitrary attribute/value pairs during the provisioning step. > One final note. One of the common "rewrite" rules for the URI in > NAPTR RRs for example is of the form "\1@somehost.company.example" > where the "\1" refers to the telephone number being processed. This > kind of shorthand should be available when processing prefixes in > bulk. "..regardless of whether ENUM will be the query protocol". >4. Reachability vs. Routing > > The goal of the registry is to provide sufficient information to > identify a responsible VSP for a prefix. The responsible VSP can > provide a SIP URI that can be proxied or redirected as desired by the > VSP. It is important to note that the registry is expected to return > the same responsibility data for all parties that query it. Nicely put. Good. > Routing information is also out of scope of the registry provisioning > problem. Once a responsible VSP is contacted, that VSP can use a > variety of techniques to route that request. hm. Shouldn't that be "Once the call originating VSP has learned the identity of the responsible VSP, the O-VSP can use a variety of techniques to route that request." ? > >5. Operations on the Registry Data > > Delete: Remove a prefix from the registry. Semantically it means > that the prefix no longer exists anywhere. > > Port-out: A port-out is similar to a delete, but could be logged > differently. The semantics are that the prefix still exists, but > that the previous VSP is no longer responsible for it. Perhaps note here that one difference between Delete and Port-out is that in the case of Delete, further request can get matched by super-prefixes existing in the registry, whereas in the Port-out case the registry will return "not-found" even if a containing prefix exists. >9. Data Propegation Propagation >10. Querying The Registry > > > When SIP is used for the query mechanism, the numbering registry > functions as a SIP redirect proxy [RFC3261] . The input to this > mechanism is a URI or more importantly the UserInfo part of the URI > containing the number to be queried. The response returned by the > proxy is either an error code indicating the absence of information > about the number queried or a redirect response (3XX) containing 1 > (or more) Contact Headers representing available routing options. Whoa, stop here. In 4. you wrote that the registry contains ownership information, not routing information. /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 _______________________________________________ PEPPERMINT mailing list PEPPERMINT@ietf.org https://www.ietf.org/mailman/listinfo/peppermint Return-Path: X-Original-To: ietfarch-peppermint-archive@core3.amsl.com Delivered-To: ietfarch-peppermint-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 282D53A6DC1; Tue, 11 Mar 2008 14:58:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -99.858 X-Spam-Level: X-Spam-Status: No, score=-99.858 tagged_above=-999 required=5 tests=[AWL=-0.248, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_ORG=0.611, J_CHICKENPOX_32=0.6, RDNS_NONE=0.1, SARE_SUB_OBFU_Q1=0.227, 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 xx3ERtgbSHZD; Tue, 11 Mar 2008 14:58:18 -0700 (PDT) Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id EDF2A3A6BE7; Tue, 11 Mar 2008 14:58:17 -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 47CEB3A6BE7 for ; Tue, 11 Mar 2008 14:58:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com 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 P3+i9sX1W5vn for ; Tue, 11 Mar 2008 14:58:15 -0700 (PDT) Received: from labs.nic.at (nat.labs.nic.at [83.136.33.3]) by core3.amsl.com (Postfix) with ESMTP id E31AF3A6923 for ; Tue, 11 Mar 2008 14:58:14 -0700 (PDT) Received: from lendl by labs.nic.at with local (Exim 3.36 #1 (Debian)) id 1JZCRu-0006Ff-00 for ; Tue, 11 Mar 2008 22:55:54 +0100 Date: Tue, 11 Mar 2008 22:55:54 +0100 From: Otmar Lendl To: peppermint@ietf.org Message-ID: <20080311215554.GA24017@nic.at> Mail-Followup-To: Otmar Lendl , peppermint@ietf.org Mime-Version: 1.0 Content-Disposition: inline User-Agent: Mutt/1.5.9i Subject: [PEPPERMINT] Some comments on the ESPP reqs draft 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 haven't managed to fully read both drafts yet, so these are just first comments. >1. Introduction > > This document presents a set of use cases and protocol requirements > for an ENUM-SIP addressing Server Provisioning Protocol (ESPP). An > ENUM-SIP addressing server is a session routing server which resolves > telephone numbers or any type of public user addresses into routable > Uniform Resource Identifiers (URIs) based on various rules and > routing logic. Could you elaborate what you mean by "routable"? Suitable for RFC3263 processing? In which networks? > A provisioning protocol has been defined based on the requirements > summarized in this document ([CableLabs-ESPP]) and it is presented in > [I-D.espp-protocol]. A number of vendors have client and server > implementations of this protocol and two interoperability testing > events have been conducted to date. What is the aim of this draft (and the spec one)? Just document what cablelabs did? Ideas for peppermint? A solution of the general peppermint problem statement? > For example, two SIP service providers that respectively service the > New York-Manhattan and New-York Queens metropolitan areas agree to > peer. Can a service area just be served by a single SSP? Can they overlap? > Some of the session establishment data (SBEs, Service Areas, Routes) > is usually provisioned once for each cable operator with occasional > subsequent updates as interconnect points are added or changed. It > is provisioned independently from the provisioning of the elements > contained in Service Areas (TNs, TN Ranges, LRNs, or public > identities such as IM identifiers). This allows the rare process of > provisioning SBEs, service areas, etc. to be distinctly separate from > the continuous process of adding subscribers. It's a good idea to separate these two different types of information. (For my part, I think that should be two different protocols, but I'm glad that there is at least some sort of two-stage mapping in the design.) > Figure 1 illustrates how telephone numbers may be grouped logically > into service areas (which may not necessarily be based on > geographical boundaries). It also shows how each service area may be > reachable via signaling path border elements. I have a hard time understanding the data design (and the naming) behind ESPP. I'll try to go through the protocol specs later. >3.3. Backward Compatibility to Legacy Switch Translations > > The underlying data schema used to provision ENUM-SIP addressing > servers should be backward compatible with today's VoIP server > translations and legacy PSTN. This requirement arises from the fact > that some SIP service providers may wish to utilize the same number > translation data employed by their SIP servers or Call Management > Servers (CMS). > > For example, a SIP service provider's switch translation personnel, > who are responsible for managing CMS translations, are given > responsibility for managing the operator's ENUM data. Rather than > provisioning complete 10-digit numbers to a peer's ENUM server some > may choose to provision Location Routing Numbers (LRNs). This > decision is, in large part, due to the fact that, in some networks, > the trunk selection algorithm of the operator's CMS are based on LRNs > (NPA-NXX). The switch translation personnel choose to reuse LRNs > rather than taking responsibility for keeping a complete set of the > operator's numbers up to date. Phew, this is awefully NANP-specific. /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 _______________________________________________ PEPPERMINT mailing list PEPPERMINT@ietf.org https://www.ietf.org/mailman/listinfo/peppermint Return-Path: X-Original-To: ietfarch-peppermint-archive@core3.amsl.com Delivered-To: ietfarch-peppermint-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0A3DF3A6C23; Mon, 10 Mar 2008 15:24:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -99.099 X-Spam-Level: X-Spam-Status: No, score=-99.099 tagged_above=-999 required=5 tests=[AWL=-0.739, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_ORG=0.611, RDNS_NONE=0.1, SUBJ_ALL_CAPS=2.077, 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 w8jNcpmsinEL; Mon, 10 Mar 2008 15:24:14 -0700 (PDT) Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4ED913A6BF7; Mon, 10 Mar 2008 15:24:14 -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 E4C573A6BF7 for ; Mon, 10 Mar 2008 15:24:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com 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 4O-DRt85+W6C for ; Mon, 10 Mar 2008 15:24:13 -0700 (PDT) Received: from mail.songbird.com (mail.songbird.com [208.184.79.10]) by core3.amsl.com (Postfix) with ESMTP id 222B83A67FC for ; Mon, 10 Mar 2008 15:24:13 -0700 (PDT) Received: from rshockeyPC (dhcp-160d.ietf71.ietf.org [130.129.22.13]) (authenticated bits=0) by mail.songbird.com (8.12.11.20060308/8.12.11) with ESMTP id m2AML0G4001777 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO) for ; Mon, 10 Mar 2008 14:21:01 -0800 From: "Richard Shockey" To: Date: Mon, 10 Mar 2008 18:21:33 -0400 Message-ID: <050101c882fd$1f44d2c0$5dce7840$@us> MIME-Version: 1.0 X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: AciC/Rd7AIAgE7IwSG+q1/BNSgs99A== Content-language: en-us x-cr-hashedpuzzle: AhE7 A1eR Cu/h DyV9 D3Es EHzU ES4P Ejan Hied HlC3 I62q Jyge KI9L KnUy K5W3 LHK8; 1; cABlAHAAcABlAHIAbQBpAG4AdABAAGkAZQB0AGYALgBvAHIAZwA=; Sosha1_v1; 7; {F4B06937-4FAC-48D9-A8A2-467993F840BE}; cgBpAGMAaABhAHIAZABAAHMAaABvAGMAawBlAHkALgB1AHMA; Mon, 10 Mar 2008 22:21:31 GMT; UABMAEUAQQBTAEUAIABHAEUAVAAgAFkATwBVAFIAIABTAEwASQBEAEUAUwAgAFQATwAgAE0ARQA= x-cr-puzzleid: {F4B06937-4FAC-48D9-A8A2-467993F840BE} X-SongbirdInformation: support@songbird.com for more information X-Songbird: Clean X-Songbird-From: richard@shockey.us Subject: [PEPPERMINT] PLEASE GET YOUR SLIDES TO ME 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 ASAP .. 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: ietfarch-peppermint-archive@core3.amsl.com Delivered-To: ietfarch-peppermint-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 97D7828C5B8; Tue, 4 Mar 2008 11:51:42 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.045 X-Spam-Level: X-Spam-Status: No, score=0.045 tagged_above=-999 required=5 tests=[AWL=-1.595, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_ORG=0.611, RDNS_NONE=0.1, SUBJ_ALL_CAPS=2.077] 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 h3WZxmcuJEiw; Tue, 4 Mar 2008 11:51:40 -0800 (PST) Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id BED4F28C532; Tue, 4 Mar 2008 11:51:40 -0800 (PST) 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 9627828C57C for ; Tue, 4 Mar 2008 11:51:38 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com 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 pfbD-3Mpprcu for ; Tue, 4 Mar 2008 11:51:37 -0800 (PST) Received: from mail.songbird.com (mail.songbird.com [208.184.79.10]) by core3.amsl.com (Postfix) with ESMTP id 9A2BC28C532 for ; Tue, 4 Mar 2008 11:51:37 -0800 (PST) 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 m24JoXf7030213 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO) for ; Tue, 4 Mar 2008 11:50:35 -0800 From: "Richard Shockey" To: Date: Tue, 4 Mar 2008 14:51:10 -0500 Message-ID: <023e01c87e31$18c414e0$4a4c3ea0$@us> MIME-Version: 1.0 X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: Ach+MRfVs2Fw1X43SDqS3+kf7nPrzg== Content-Language: en-us X-SongbirdInformation: support@songbird.com for more information X-Songbird: Clean X-Songbird-From: richard@shockey.us Subject: [PEPPERMINT] FINAL 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 The only change from the previous draft agenda is that we will deal with the Problem Statement documents one after another. ************** IETF 71 PEPPERMINT BOF Agenda Provisioning Extensions in Peering Registries for Multimedia INTerconnection 1510-1610 Afternoon Session II Franklin 11/12 INT dna Detecting Network Attachment WG Franklin 5 OPS grow Global Routing Operations WG Franklin 3/4 RAI peppermint Provisioning Extensions in Peering Registries for Multimedia INTerconnection BOF Franklin 13 RTG isis IS-IS for IP Internets WG Salon I SEC ltans Long-Term Archive and Notary Services WG Franklin 5 SEC msec Multicast Security WG Chair(s): Richard Shockey Tom Creighton RAI Director(s): Jon Peterson jon.peterson@neustar.biz Cullen Jennings fluffy@cisco.com Agenda Bashing. Presentation of the proposed charter. 10 min ( see below ) 1. Title : Consolidated Provisioning Problem Statement Author(s) : D. Schwartz, R. Mahy, A. Duric, E. Lewis Filename : draft-schwartz-peppermint-consolidated-provisioning-problem-statement-00.txt Pages : 12 Date : 2008-2-11 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-schwartz-peppermint-consolidated-p rovisioning-problem-statement-00.txt 2. 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-00.txt Pages : 16 Date : 2008-02-18 This document presents use cases and protocol requirements for provisioning ENUM-SIP addressing servers. The provisioned data is used by an addressing server to return part of the session establishment data to SIP entities so that they can route SIP sessions to the target destinations. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-mule-peppermint-espp-requirements- 00.txt 3. Title : A Provisioning Protocol for ENUM-SIP Addressing Servers Author(s) : K. Cartwright, et al. Filename : draft-mule-peppermint-espp-protocol-01.txt Pages : 117 Date : 2008-02-25 This document defines a provisioning protocol for ENUM-SIP addressing servers. This protocol has been recently published as part of CableLabs(r) PacketCable(tm) specifications. It 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. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-mule-peppermint-espp-protocol-01.t xt General Discussion The Usual Questions. A. Is this a problem that the IETF needs to work on? B. Who wants to work on this problem? ************ Peppermint Proposed Charter Provisioning Extensions in Peering Registries for Multimedia Interconnection. Mailing Lists: peppermint@ietf.org General information about the mailing list is at: https://www1.ietf.org/mailman/listinfo/peppermint Temporary Area Directorate: Real Time Applications (RAI) Ultimate Area Directorate: TBD Chairs: TBD PROPOSED CHARTER FOR PEPPERMINT The IETF has been working on various aspects of session-based Multimedia Interconnection among administrative domains. In addition, the IETF has done significant work on data exchanges among various network elements. ENUM is specifically chartered to develop protocols that involve the translation of E.164 numbers to URI's. SPEERMINT has been chartered to develop best current practices among real-time application service providers and how such services interconnect across administrative boundaries. The PEPPERMINT work group is chartered to define what data needs to be exchanged among Multimedia administrative domains, and how that data should be structured provisioned and propagated. These protocols would be outside the normal scope of establishing various forms of a SIP session. These administrative domains are of any practical size and could be service providers or enterprise SIP proxy's, such as PBX's. Data exchanges to facilitate session-based Multimedia Interconnection are typically between various Client User Agents and Registries or bilateral or multilateral Registry to Registry. Data exchanges could include bulk data as well as real time updates. Typical data include mappings of phone numbers to URIs, policies surrounding admission to various points of network interconnection and various types of trunk data. In addition, there is a specific need for redistribution of such Registry data to various types of network databases. The working group will draw upon expert advice and ongoing consultation from the ENUM, SPEERMINT and PROVREG working groups. The working group may also reuse elements of RFC 4114, if possible. The final work product(s) from this working group will utilize and be based on XML documents and XML document exchanges. PROPOSED GOALS AND MILESTONES Requirements for Interconnection data exchanges. Sept 08 Provisioning of Interconnection data registries. Nov 08 Provisioning of Interconnection data caches. Feb 09 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: ietfarch-peppermint-archive@core3.amsl.com Delivered-To: ietfarch-peppermint-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0A7A528C256; Sat, 1 Mar 2008 10:51:52 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.968 X-Spam-Level: X-Spam-Status: No, score=-0.968 tagged_above=-999 required=5 tests=[AWL=-0.531, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_ORG=0.611, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id m-fozu66NZ4Z; Sat, 1 Mar 2008 10:51:46 -0800 (PST) Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8FBCE28C25E; Sat, 1 Mar 2008 10:51:46 -0800 (PST) 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 9C4FD28C11D for ; Sat, 1 Mar 2008 10:51:45 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com 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 XryzFDJ-B24q for ; Sat, 1 Mar 2008 10:51:40 -0800 (PST) Received: from sj-iport-3.cisco.com (sj-iport-3.cisco.com [171.71.176.72]) by core3.amsl.com (Postfix) with ESMTP id 0977F28C256 for ; Sat, 1 Mar 2008 10:51:40 -0800 (PST) Received: from sj-dkim-4.cisco.com ([171.71.179.196]) by sj-iport-3.cisco.com with ESMTP; 01 Mar 2008 10:51:32 -0800 Received: from sj-core-1.cisco.com (sj-core-1.cisco.com [171.71.177.237]) by sj-dkim-4.cisco.com (8.12.11/8.12.11) with ESMTP id m21IpWNY021757 for ; Sat, 1 Mar 2008 10:51:32 -0800 Received: from [192.168.4.177] (sjc-fluffy-vpn1.cisco.com [10.25.236.82]) by sj-core-1.cisco.com (8.12.10/8.12.6) with SMTP id m21IpPcD027052 for ; Sat, 1 Mar 2008 18:51:31 GMT Message-Id: From: Cullen Jennings To: peppermint@ietf.org Impp: xmpp:cullenfluffyjennings@jabber.org Mime-Version: 1.0 (Apple Message framework v919.2) Date: Sat, 1 Mar 2008 10:51:15 -0800 X-Mailer: Apple Mail (2.919.2) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=1815; t=1204397492; x=1205261492; c=relaxed/simple; s=sjdkim4002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=fluffy@cisco.com; z=From:=20Cullen=20Jennings=20 |Subject:=20Minor=20comments=20on=20draft-schwartz-peppermi nt-consolidated-provisioning-problem-statement-00 |Sender:=20; bh=mkmkUwxCcAKmbvD3fPene2lblQpbcjnfTkIGBctvJgs=; b=ePILdCFPhzMQexhrS3GHAcoW6IUnhsAjPpPbup+wNnwrxcTzUlvYjDQABL YyP787gCi4Av8UG4QLCVyPrvunXWHJfq2eeYMhnL29RoCoo/wCdtdsofyd1e 8EYHklFYqP; Authentication-Results: sj-dkim-4; header.From=fluffy@cisco.com; dkim=pass ( sig from cisco.com/sjdkim4002 verified; ); Subject: [PEPPERMINT] Minor comments on draft-schwartz-peppermint-consolidated-provisioning-problem-statement-00 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 My biggest complaint is your draft name is too long :-) Seriously I found this draft easy to understand and get what the problem was you were trying to solve - I like it. Few little things. Section 3.1, do you want to say anything about what happens when you have overlapping ranges with the same length. For example one prefix has 1000-3000 and the other other has 2900 to 3100. I have used stuff that selected the smallest range in that case - I don't know that is what you want but seems like a case that might motivate some requirements one way or the other. Section 3.2 para 5 - I would rephrase to say that the protocol should be easily extensible in ways that anticipate ways that ENUM will be extended or something like that. Comparing this to the DNS TXT RR record may cause some people allergic reaction that are not really what you want. Section 5 - the para on "Renumber". I'm not 100% clear what the requirements are here - can you say a bit more. What information at the semantic level would a renumber operation contain. Section 6 The Fee Category attributes got me a little worried. What would they mean and how would they be used. I imagine I would have no problems with these but I would want to be very careful. The idea of landline or mobile is starting to get pretty vague when we are talking about a SIP call to fluffy@cisco.com. I have serious worries about the Media types. I worry that this needs to be negotiated at the time of the call and that having it in a registry will hinder deployments of devices that support a wide variety of media types. Let's talk about this in Philadelphia some time and see if you can educate me on the requirements here. Cullen _______________________________________________ PEPPERMINT mailing list PEPPERMINT@ietf.org https://www.ietf.org/mailman/listinfo/peppermint