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 36BAF28C510; Tue, 1 Apr 2008 09:14: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 A471228C4E1 for ; Tue, 1 Apr 2008 09:14:24 -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 tRkes8yNyWe3 for ; Tue, 1 Apr 2008 09:14:22 -0700 (PDT) Received: from ondar.cablelabs.com (ondar.cablelabs.com [192.160.73.61]) by core3.amsl.com (Postfix) with ESMTP id 3124C28C567 for ; Tue, 1 Apr 2008 09:12:49 -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 m31GCjeI002071; Tue, 1 Apr 2008 10:12:45 -0600 Received: from srvxchg3.cablelabs.com (10.5.0.25) by kyzyl.cablelabs.com (F-Secure/fsigk_smtp/511/kyzyl.cablelabs.com); Tue, 1 Apr 2008 10:12:45 -0700 (MST) X-Virus-Status: clean(F-Secure/fsigk_smtp/511/kyzyl.cablelabs.com) X-Mimeole: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Tue, 1 Apr 2008 10:12:45 -0600 Message-ID: <160DE07A1C4F8E4AA2715DEC577DA491936498@srvxchg3.cablelabs.com> In-Reply-To: <28F05913385EAC43AF019413F674A0171246ED96@OCCLUST04EVS1.ugd.att.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [PEPPERMINT] Proposed Updated Charter Thread-Index: AciTaz5+nL5X5hseRkSarzcft2yW4AALIH5QABwqvqAAAInooAACFJrA References: <160DE07A1C4F8E4AA2715DEC577DA49193647C@srvxchg3.cablelabs.com><28F05913385EAC43AF019413F674A0171246ED86@OCCLUST04EVS1.ugd.att.com><160DE07A1C4F8E4AA2715DEC577DA491936492@srvxchg3.cablelabs.com> <28F05913385EAC43AF019413F674A0171246ED96@OCCLUST04EVS1.ugd.att.com> From: "Daryl Malas" To: "DOLLY, MARTIN C, ATTLABS" , X-Approved: ondar 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 Martin, I do not disagree with your perspective; however, my point is the defined processes should not be different. If the processes are not different (or perhaps have 1 additional "dip switch"), then I still think it can be encompassed within an SSP. --Daryl -----Original Message----- From: peppermint-bounces@ietf.org [mailto:peppermint-bounces@ietf.org] On Behalf Of DOLLY, MARTIN C, ATTLABS Sent: Tuesday, April 01, 2008 9:13 AM To: Daryl Malas; peppermint@ietf.org Subject: Re: [PEPPERMINT] Proposed Updated Charter Daryl, I view AT&T differently depending on whether I am accessing them intranet versus as an AT&T customer, so I do not see them as being the same. In the intranet case, it is the AT&T IT department that controls everything, which is different than when I am a customer of AT&T. Martin -----Original Message----- From: Daryl Malas [mailto:D.Malas@cablelabs.com] Sent: Tuesday, April 01, 2008 11:01 AM To: DOLLY, MARTIN C, ATTLABS; peppermint@ietf.org Subject: RE: [PEPPERMINT] Proposed Updated Charter Hello Martin, I feel it is appropriate to include enterprises within the context of an SSP. Per the definition of an SSP, an enterprise provides SIP services to its customers (employees), in much the same an operator would. This is the intention within the charter update below. --Daryl -----Original Message----- From: DOLLY, MARTIN C, ATTLABS [mailto:mdolly@att.com] Sent: Monday, March 31, 2008 7: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 40F2928C1D4; Tue, 1 Apr 2008 09:04:02 -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 2358B28C1D4 for ; Tue, 1 Apr 2008 09:04:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.878 X-Spam-Level: X-Spam-Status: No, score=-1.878 tagged_above=-999 required=5 tests=[AWL=0.721, 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 Ee9pm0WzcsvT for ; Tue, 1 Apr 2008 09:03:52 -0700 (PDT) Received: from ihemail4.lucent.com (ihemail4.lucent.com [135.245.0.39]) by core3.amsl.com (Postfix) with ESMTP id 2BB6A3A6E08 for ; Tue, 1 Apr 2008 09:02:48 -0700 (PDT) Received: from ilexp02.ndc.lucent.com (h135-3-39-2.lucent.com [135.3.39.2]) by ihemail4.lucent.com (8.13.8/IER-o) with ESMTP id m31G2aLF025210; Tue, 1 Apr 2008 11:02:36 -0500 (CDT) Received: from DEEXP01.de.lucent.com ([135.248.187.65]) by ilexp02.ndc.lucent.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 1 Apr 2008 11:02:31 -0500 Received: from DEEXC1U01.de.lucent.com ([135.248.187.20]) by DEEXP01.de.lucent.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 1 Apr 2008 18:02:29 +0200 X-MIMEOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Tue, 1 Apr 2008 18:02:28 +0200 Message-ID: <5D1A7985295922448D5550C94DE2918001D9F512@DEEXC1U01.de.lucent.com> In-Reply-To: <28F05913385EAC43AF019413F674A0171246ED87@OCCLUST04EVS1.ugd.att.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [PEPPERMINT] Proposed Updated Charter Thread-index: AciTaz5+nL5X5hseRkSarzcft2yW4AALIH5QAAEU7fAAExRccAAKO1Ng References: <160DE07A1C4F8E4AA2715DEC577DA49193647C@srvxchg3.cablelabs.com><28F05913385EAC43AF019413F674A0171246ED86@OCCLUST04EVS1.ugd.att.com> <28F05913385EAC43AF019413F674A0171246ED87@OCCLUST04EVS1.ugd.att.com> From: "DRAGE, Keith \(Keith\)" To: "DOLLY, MARTIN C, ATTLABS" , "Hadriel Kaplan" , "Daryl Malas" , X-OriginalArrivalTime: 01 Apr 2008 16:02:29.0117 (UTC) FILETIME=[C935F2D0:01C89411] X-Scanned-By: MIMEDefang 2.57 on 135.245.2.39 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 Just to note that the reason that this text appeared in the first place was in response to a question I asked about the size of systems to be addressed. The smaller the systems that this becomes appropriate for, the more we move into enterprise land, and out of that of the big public network operators (although this is a generalisation as there are many enterprise networks bigger that some public networks). So it is range of system size I want to see represented in the text if we are really stuck on terminology. Regards Keith > -----Original Message----- > From: peppermint-bounces@ietf.org > [mailto:peppermint-bounces@ietf.org] On Behalf Of DOLLY, > MARTIN C, ATTLABS > Sent: Tuesday, April 01, 2008 12:08 PM > To: Hadriel Kaplan; Daryl Malas; peppermint@ietf.org > Subject: Re: [PEPPERMINT] Proposed Updated Charter > > Hadriel, > > I do not agree with your example, yet. Can you be a little > more specific, as to what information peppermint would provide here? > > Thanks, > > Martin > > -----Original Message----- > From: Hadriel Kaplan [mailto:HKaplan@acmepacket.com] > Sent: Monday, March 31, 2008 10:18 PM > To: DOLLY, MARTIN C, ATTLABS; Daryl Malas; peppermint@ietf.org > Subject: RE: [PEPPERMINT] Proposed Updated Charter > > 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 > _______________________________________________ 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 0E2F13A6F36; Tue, 1 Apr 2008 08:38:52 -0700 (PDT) X-Original-To: peppermint@core3.amsl.com Delivered-To: peppermint@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 765783A6EED for ; Tue, 1 Apr 2008 08:38:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2fL2X+lzVw9P for ; Tue, 1 Apr 2008 08:38:45 -0700 (PDT) Received: from peregrine.verisign.com (peregrine.verisign.com [216.168.239.74]) by core3.amsl.com (Postfix) with ESMTP id CA97928C4C1 for ; Tue, 1 Apr 2008 08:36:05 -0700 (PDT) Received: from dul1wnexcn03.vcorp.ad.vrsn.com (dul1wnexcn03.vcorp.ad.vrsn.com [10.170.12.113]) by peregrine.verisign.com (8.13.6/8.13.4) with ESMTP id m31FOtaS007241 for ; Tue, 1 Apr 2008 11:24:55 -0400 Received: from DUL1WNEXMB05.vcorp.ad.vrsn.com ([10.170.12.240]) by dul1wnexcn03.vcorp.ad.vrsn.com with Microsoft SMTPSVC(6.0.3790.3959); Tue, 1 Apr 2008 16:36:03 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Tue, 1 Apr 2008 11:36:02 -0400 Message-ID: In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: PEPPERMINT Digest, Vol 9, Issue 21 Thread-Index: AciTa1/VS/uoyeLOTu+ulL4bRwuXZQAlaP7w From: "Cartwright, Kenneth" To: X-OriginalArrivalTime: 01 Apr 2008 15:36:03.0225 (UTC) FILETIME=[17F20890:01C8940E] Subject: Re: [PEPPERMINT] PEPPERMINT Digest, Vol 9, Issue 21 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 Daryl, Looks good. I've offered some possible modifications for consideration. They are in-line and delimited by ">>>>KJCStart" and ">>>>KJCEnd". Ken -----Original Message----- From: peppermint-bounces@ietf.org [mailto:peppermint-bounces@ietf.org] On Behalf Of peppermint-request@ietf.org Sent: Monday, March 31, 2008 4:10 PM To: peppermint@ietf.org Subject: PEPPERMINT Digest, Vol 9, Issue 21 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. Proposed Updated Charter (Daryl Malas) ---------------------------------------------------------------------- Message: 1 Date: Mon, 31 Mar 2008 14:10:20 -0600 From: "Daryl Malas" Subject: [PEPPERMINT] Proposed Updated Charter To: Message-ID: <160DE07A1C4F8E4AA2715DEC577DA49193647C@srvxchg3.cablelabs.com> Content-Type: text/plain; charset="us-ascii" 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: >>>>KJCStart You may consider altering the wording of the above sentence to read as follows: The ENUM and SPEERMINT working groups provide the underlying context for much of the intended work that the SPEERMINT working group will undertake. >>>>KJCEnd 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. >>>>KJCStart You may consider altering the wording of the above two sentences to read as follows: The ENUM working group is specifically chartered to develop protocols that involve the translation of E.164 numbers to URIs. While the SPEERMINT working group has been chartered to develop requirements and best current practices among real-time application SSPs and to describe how such services may best interconnect across administrative boundaries. >>>>KJCEnd 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. >>>>KJCStart In the above sentences when you say "this work" I believe you are referring to the work of SPEERMINT, as apposed to the work of SPEERMINT. So you may consider this tweaked version of the two sentences above: More specifically, SPEERMINT will provide details of how Session Establishment Data (SED) is collected, what comprises SED, how SED should be used to properly identify an optimal path to a destination user agent (UA), and the secure manners in which SED and the SIP session data is exchanged between the peering functions. >>>>KJCEnd 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. >>>>KJCStart While I understand what you are saying in the above sentence, I'm not certain of your intent in adding it here, as a sentence that rides on the end of your synopsis of the role of the SPEERMINT working group. Imho, this sentence may be un-necessary in this document. You may consider removing it, recognizing that this idea is/willBe addressed and fleshed out in a requirements document or some other document that can do it justice. >>>>KJCEnd 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.). >>>>KJCStart You may consider rewording the above as follows: The PEPPERMINT working group is chartered with a scope that is orthogonal to SPEERMINT and ENUM. The work tasks within the scope of PEPPERMINT will be designed to build from the work of SPEERMINT and ENUM to identify and define the data structures and provisioning protocol(s) that facilitate the provisioning data exchanges among Multimedia administrative domains. These administrative domains may be of any practical size and could be any type of SSP, such as recognized telephony carriers, enterprises, end-user groups, or Federations. Data exchanges among these administrative domains may be bi-lateral or multi-lateral in nature, and could include bulk updates and/or more granular real-time updates. Typical data includes the mapping of phone numbers to URIs, policies surrounding admission to various points of network interconnection, and various other 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.). >>>>KJCEnd 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. >>>KJCStart During the previous IETF in Vancouver, on the mailing list, and at the most recent IETF in Phily there were opinions expressed that attempting to pre-determine the list of candidate data structures and protocols was probably un-necessary for the purposes of the charter and an open ended activity. I also feel that just listing the possible candidates in the charter does not best capture the intended goal, which is to facilitate the requirements and progress of the working group. While I don't feel that this is a major issue, I am of this opinion. So you may consider that the above few sentences could be re-worded as follows, which I think better states the goal while not attempting to pre-determine the best list of candidates that may meet the goal: The working group will draw upon expert advice and on-going consultation from the ENUM and SPEERMINT working groups. The working group will also consider reusing appropriate pre-existing data structures, protocols, and technologies that are determined to meet the requirements of and facilitate the progress of the working group. >>>>KJCEnd --------------------------------------- Thanks...--Daryl ------------------------------ _______________________________________________ PEPPERMINT mailing list PEPPERMINT@ietf.org https://www.ietf.org/mailman/listinfo/peppermint End of PEPPERMINT Digest, Vol 9, Issue 21 ***************************************** _______________________________________________ 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 37A2828C41F; Tue, 1 Apr 2008 08: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 AED113A6EC0 for ; Tue, 1 Apr 2008 08:28:44 -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=[AWL=0.000, 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 RyavQwIyjGu6 for ; Tue, 1 Apr 2008 08:28:43 -0700 (PDT) Received: from ondar.cablelabs.com (ondar.cablelabs.com [192.160.73.61]) by core3.amsl.com (Postfix) with ESMTP id 118D83A6F49 for ; Tue, 1 Apr 2008 08:28:15 -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 m31FSBHT030377; Tue, 1 Apr 2008 09:28:11 -0600 Received: from srvxchg3.cablelabs.com (10.5.0.25) by kyzyl.cablelabs.com (F-Secure/fsigk_smtp/511/kyzyl.cablelabs.com); Tue, 1 Apr 2008 09:28:11 -0700 (MST) X-Virus-Status: clean(F-Secure/fsigk_smtp/511/kyzyl.cablelabs.com) X-Mimeole: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Tue, 1 Apr 2008 09:28:11 -0600 Message-ID: <160DE07A1C4F8E4AA2715DEC577DA491936496@srvxchg3.cablelabs.com> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [PEPPERMINT] Proposed Updated Charter Thread-Index: AciTaz5+nL5X5hseRkSarzcft2yW4AALIH5QAAEU7fAAExRccAAHl2dgAAF0pEA= References: <160DE07A1C4F8E4AA2715DEC577DA49193647C@srvxchg3.cablelabs.com> <28F05913385EAC43AF019413F674A0171246ED86@OCCLUST04EVS1.ugd.att.com> <28F05913385EAC43AF019413F674A0171246ED87@OCCLUST04EVS1.ugd.att.com> From: "Daryl Malas" To: "Hadriel Kaplan" , "DOLLY, MARTIN C, ATTLABS" , X-Approved: ondar 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 Hadriel, I agree it should be within the scope to consider an enterprise's use of the outcome of PEPPERMINT, but it is not PEPPERMINT's job to determine the formation of enterprises within varying peering architectures. At best, this would be done within SPEERMINT, and some architectures and peering considerations for enterprises are already documented within SPEERMINT artifacts. --Daryl -----Original Message----- From: Hadriel Kaplan [mailto:HKaplan@acmepacket.com] Sent: Tuesday, April 01, 2008 9:20 AM To: DOLLY, MARTIN C, ATTLABS; Daryl Malas; peppermint@ietf.org Subject: RE: [PEPPERMINT] Proposed Updated Charter Imagine a big enterprise, having multiple branch offices, lots of user agents and proxies/servers/whatever. They may want calls within a branch to stay in the branch, calls between certain branches to go over the public Internet, calls between other branches to use leased lines or VPNs, calls between other branches to use the PSTN or ESN-type TDM network, etc. So they could potentially use an outcome of PEPPERMINT to dynamically provision their servers/proxies in the various branches with such routing data, and make changes as employees or groups are added or move branches. OR another example is suppose this big enterprise connects to multiple service providers or federations, perhaps different ones for different branches - the providers or federations can dynamically inform the enterprise or its branches of which ingress points can be used for what routes, with potentially some other attributes yet to be defined. That way as the provider/federation adds or removes ingress points or routes, it can do so in a more automated fashion. I think, but I'm not sure, that including enterprises in the charter does not mean to say any of those things would happen, or that PEPPERMINT would actually define such uses explicitly/separately, or that they have to give special consideration to such - just that it's within the scope of the WG's purview to do so. Is that correct? -hadriel > -----Original Message----- > From: DOLLY, MARTIN C, ATTLABS [mailto:mdolly@att.com] > > I do not agree with your example, yet. Can you be a little more > specific, as to what information peppermint would provide here? > > Thanks, > > Martin > > -----Original Message----- > From: Hadriel Kaplan [mailto:HKaplan@acmepacket.com] > Sent: Monday, March 31, 2008 10:18 PM > To: DOLLY, MARTIN C, ATTLABS; Daryl Malas; peppermint@ietf.org > Subject: RE: [PEPPERMINT] Proposed Updated Charter > > 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 > _______________________________________________ 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 6A4CF3A6EBC; Tue, 1 Apr 2008 08:24:08 -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 C07EE3A6E88 for ; Tue, 1 Apr 2008 08:24:07 -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 heCZ7e4zJTKB for ; Tue, 1 Apr 2008 08:24:06 -0700 (PDT) Received: from ondar.cablelabs.com (ondar.cablelabs.com [192.160.73.61]) by core3.amsl.com (Postfix) with ESMTP id A1F743A6E63 for ; Tue, 1 Apr 2008 08:24:06 -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 m31FO49N030052; Tue, 1 Apr 2008 09:24:04 -0600 Received: from srvxchg3.cablelabs.com (10.5.0.25) by kyzyl.cablelabs.com (F-Secure/fsigk_smtp/511/kyzyl.cablelabs.com); Tue, 1 Apr 2008 09:24:04 -0700 (MST) X-Virus-Status: clean(F-Secure/fsigk_smtp/511/kyzyl.cablelabs.com) X-Mimeole: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Tue, 1 Apr 2008 09:24:03 -0600 Message-ID: <160DE07A1C4F8E4AA2715DEC577DA491936495@srvxchg3.cablelabs.com> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [PEPPERMINT] Proposed Updated Charter Thread-Index: AciTaz5+nL5X5hseRkSarzcft2yW4AAM15ygABsjLrA= References: <160DE07A1C4F8E4AA2715DEC577DA49193647C@srvxchg3.cablelabs.com> From: "Daryl Malas" To: "Hadriel Kaplan" , X-Approved: ondar 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 Comments in-line... -----Original Message----- From: Hadriel Kaplan [mailto:HKaplan@acmepacket.com] Sent: Monday, March 31, 2008 9:01 PM To: Daryl Malas; peppermint@ietf.org Subject: RE: [PEPPERMINT] Proposed Updated Charter 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." [DM] Agreed...I will fix this. 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. [DM] Okay, I am not sure how you read "indirect" peering into that sentence. Also, just because you are a member of a federation does not suddenly give you a "golden key" to peer with everyone within it. The point of the sentence is to indicate there are potential complexities to be considered within PEPPERMINT when peers are in multilateral relationships. It should not be PEPPERMINT to determine what those architectural complexities are. These are discussed, documented, and determined within SPEERMINT; however, based on these complexities, PEPPERMINT will need to take into consideration the provisioning of data within a Federation. It will be, potentially, different than a single bi-lateral peering arrangement. > 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..."? [DM] I would rather suggest "SIP-enabled 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? [DM] I would suggest "client User Agents" is changed to "SIP User Agents", but a proxy would not be provisioned within an ENUM server as an end-point. A B2BUA, otherwise known as a UA to SIP, would be. > 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 BE2B83A6AF7; Tue, 1 Apr 2008 08:20: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 A86B53A6C34 for ; Tue, 1 Apr 2008 08:20:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.79 X-Spam-Level: X-Spam-Status: No, score=-1.79 tagged_above=-999 required=5 tests=[AWL=0.809, 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 Ot0sH+pPU1bG for ; Tue, 1 Apr 2008 08:20:43 -0700 (PDT) Received: from etmail.acmepacket.com (etmail.acmepacket.com [216.41.24.6]) by core3.amsl.com (Postfix) with ESMTP id 392133A6ADF for ; Tue, 1 Apr 2008 08:20:43 -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; Tue, 1 Apr 2008 11:20:15 -0400 Received: from mail.acmepacket.com ([216.41.24.7]) by mail.acmepacket.com ([216.41.24.7]) with mapi; Tue, 1 Apr 2008 11:20:15 -0400 From: Hadriel Kaplan To: "DOLLY, MARTIN C, ATTLABS" , Daryl Malas , "peppermint@ietf.org" Date: Tue, 1 Apr 2008 11:20:14 -0400 Thread-Topic: [PEPPERMINT] Proposed Updated Charter Thread-Index: AciTaz5+nL5X5hseRkSarzcft2yW4AALIH5QAAEU7fAAExRccAAHl2dg Message-ID: References: <160DE07A1C4F8E4AA2715DEC577DA49193647C@srvxchg3.cablelabs.com> <28F05913385EAC43AF019413F674A0171246ED86@OCCLUST04EVS1.ugd.att.com> <28F05913385EAC43AF019413F674A0171246ED87@OCCLUST04EVS1.ugd.att.com> In-Reply-To: <28F05913385EAC43AF019413F674A0171246ED87@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 Imagine a big enterprise, having multiple branch offices, lots of user agents and proxies/servers/whatever. They may want calls within a branch to stay in the branch, calls between certain branches to go over the public Internet, calls between other branches to use leased lines or VPNs, calls between other branches to use the PSTN or ESN-type TDM network, etc. So they could potentially use an outcome of PEPPERMINT to dynamically provision their servers/proxies in the various branches with such routing data, and make changes as employees or groups are added or move branches. OR another example is suppose this big enterprise connects to multiple service providers or federations, perhaps different ones for different branches - the providers or federations can dynamically inform the enterprise or its branches of which ingress points can be used for what routes, with potentially some other attributes yet to be defined. That way as the provider/federation adds or removes ingress points or routes, it can do so in a more automated fashion. I think, but I'm not sure, that including enterprises in the charter does not mean to say any of those things would happen, or that PEPPERMINT would actually define such uses explicitly/separately, or that they have to give special consideration to such - just that it's within the scope of the WG's purview to do so. Is that correct? -hadriel > -----Original Message----- > From: DOLLY, MARTIN C, ATTLABS [mailto:mdolly@att.com] > > I do not agree with your example, yet. Can you be a little more > specific, as to what information peppermint would provide here? > > Thanks, > > Martin > > -----Original Message----- > From: Hadriel Kaplan [mailto:HKaplan@acmepacket.com] > Sent: Monday, March 31, 2008 10:18 PM > To: DOLLY, MARTIN C, ATTLABS; Daryl Malas; peppermint@ietf.org > Subject: RE: [PEPPERMINT] Proposed Updated Charter > > 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 > _______________________________________________ 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 1B44D3A6D1E; Tue, 1 Apr 2008 08:15: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 6508C3A6D1E for ; Tue, 1 Apr 2008 08:15:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Kvf21vkfhn2x for ; Tue, 1 Apr 2008 08:15:11 -0700 (PDT) Received: from mailsrv.ams.gblxint.com (unknown-230-det.globalcrossing.com [64.208.159.230]) by core3.amsl.com (Postfix) with ESMTP id 152713A6C34 for ; Tue, 1 Apr 2008 08:15:11 -0700 (PDT) Received: from w3uspdy20.ams.gblxint.com (w3uspdy20.ams.gblxint.com [10.60.51.55]) by mailsrv.ams.gblxint.com (Postfix) with ESMTP id 2BFCD99CB; Tue, 1 Apr 2008 11:15:09 -0400 (EDT) Received: from EVS2.ams.gblxint.com ([10.60.51.58]) by w3uspdy20.ams.gblxint.com with Microsoft SMTPSVC(6.0.3790.3959); Tue, 1 Apr 2008 11:15:08 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Tue, 1 Apr 2008 11:14:19 -0400 Message-ID: In-Reply-To: <28F05913385EAC43AF019413F674A0171246ED87@OCCLUST04EVS1.ugd.att.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [PEPPERMINT] Proposed Updated Charter Thread-Index: AciTaz5+nL5X5hseRkSarzcft2yW4AALIH5QAAEU7fAAExRccAAIXq+w References: <160DE07A1C4F8E4AA2715DEC577DA49193647C@srvxchg3.cablelabs.com><28F05913385EAC43AF019413F674A0171246ED86@OCCLUST04EVS1.ugd.att.com> <28F05913385EAC43AF019413F674A0171246ED87@OCCLUST04EVS1.ugd.att.com> From: "Uzelac, Adam" To: "DOLLY, MARTIN C, ATTLABS" , "Hadriel Kaplan" , "Daryl Malas" , X-OriginalArrivalTime: 01 Apr 2008 15:15:08.0644 (UTC) FILETIME=[2C282A40:01C8940B] 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 I completely agree with Hadriel and believe that an enterprise most certainly is one example of a SSP. An enterprise would logically like to dictate to the world how others should send multimedia sessions to it. For instance, they may want to dictate that all SIP communications for its SIP administrative domain traverse another SSP (like L3, Global Crossing, Comcast, etc) - maybe to perform some form of Signaling or Media message handling like handling security certificates - and in doing so would provision the SBEs of the L3, GC, Comcast as the "Next-hop" the world should use to communicate with them. This seems very logical and empowering to the enterprise. It should also be noted that enterprises are specifically called out and included in SPEERMINT work. Adam > -----Original Message----- > From: peppermint-bounces@ietf.org > [mailto:peppermint-bounces@ietf.org] On Behalf Of DOLLY, > MARTIN C, ATTLABS > Sent: Tuesday, April 01, 2008 7:08 AM > To: Hadriel Kaplan; Daryl Malas; peppermint@ietf.org > Subject: Re: [PEPPERMINT] Proposed Updated Charter > > Hadriel, > > I do not agree with your example, yet. Can you be a little > more specific, as to what information peppermint would provide here? > > Thanks, > > Martin > > -----Original Message----- > From: Hadriel Kaplan [mailto:HKaplan@acmepacket.com] > Sent: Monday, March 31, 2008 10:18 PM > To: DOLLY, MARTIN C, ATTLABS; Daryl Malas; peppermint@ietf.org > Subject: RE: [PEPPERMINT] Proposed Updated Charter > > 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 > _______________________________________________ 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 B91B228C4B8; Tue, 1 Apr 2008 08:14: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 9FB6128C4C8 for ; Tue, 1 Apr 2008 08:14:16 -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 PY1WmxNfWR+X for ; Tue, 1 Apr 2008 08:14:15 -0700 (PDT) Received: from ondar.cablelabs.com (ondar.cablelabs.com [192.160.73.61]) by core3.amsl.com (Postfix) with ESMTP id 9833A28C4AA for ; Tue, 1 Apr 2008 08:14:15 -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 m31FEBKO029177; Tue, 1 Apr 2008 09:14:12 -0600 Received: from srvxchg3.cablelabs.com (10.5.0.25) by kyzyl.cablelabs.com (F-Secure/fsigk_smtp/511/kyzyl.cablelabs.com); Tue, 1 Apr 2008 09:14:11 -0700 (MST) X-Virus-Status: clean(F-Secure/fsigk_smtp/511/kyzyl.cablelabs.com) X-Mimeole: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Tue, 1 Apr 2008 09:14:11 -0600 Message-ID: <160DE07A1C4F8E4AA2715DEC577DA491936494@srvxchg3.cablelabs.com> In-Reply-To: <08ca01c8939f$b36a4b30$1a3ee190$@us> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [PEPPERMINT] Proposed Updated Charter Thread-Index: AciTaz5+nL5X5hseRkSarzcft2yW4AALIH5QAAG9IjAAGufI8A== References: <160DE07A1C4F8E4AA2715DEC577DA49193647C@srvxchg3.cablelabs.com><28F05913385EAC43AF019413F674A0171246ED86@OCCLUST04EVS1.ugd.att.com> <08ca01c8939f$b36a4b30$1a3ee190$@us> From: "Daryl Malas" To: "Richard Shockey" , "DOLLY, MARTIN C, ATTLABS" , X-Approved: ondar 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 Richard, Enterprise peering is within the scope of SPEERMINT, and I think they should be considered within the general term of SIP Service Provider. "A SIP Service Provider (or SSP) is an entity that provides session services utilizing SIP signaling to its customers." IMHO, based on the above excerpt from the Terminology draft definition of an SSP, I do not see why an enterprise cannot be considered within this definition. Their customers are their employees, whom they are providing session services to. --Daryl -----Original Message----- From: peppermint-bounces@ietf.org [mailto:peppermint-bounces@ietf.org] On Behalf Of Richard Shockey Sent: Monday, March 31, 2008 8:26 PM To: 'DOLLY, MARTIN C, ATTLABS'; peppermint@ietf.org Subject: Re: [PEPPERMINT] Proposed Updated Charter 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 _______________________________________________ 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 28FE53A6C2A; Tue, 1 Apr 2008 08:13:21 -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 438033A69F3 for ; Tue, 1 Apr 2008 08:13:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.835 X-Spam-Level: X-Spam-Status: No, score=-103.835 tagged_above=-999 required=5 tests=[AWL=2.764, 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 1FHJM4kvINyy for ; Tue, 1 Apr 2008 08:13:18 -0700 (PDT) Received: from mail203.messagelabs.com (mail203.messagelabs.com [216.82.254.243]) by core3.amsl.com (Postfix) with ESMTP id 0C0003A6C2A for ; Tue, 1 Apr 2008 08:13:18 -0700 (PDT) X-VirusChecked: Checked X-Env-Sender: mdolly@att.com X-Msg-Ref: server-15.tower-203.messagelabs.com!1207062791!11713252!1 X-StarScan-Version: 5.5.12.14.2; banners=-,-,- X-Originating-IP: [144.160.20.54] Received: (qmail 21530 invoked from network); 1 Apr 2008 15:13:11 -0000 Received: from sbcsmtp7.sbc.com (HELO mlpi135.enaf.sfdc.sbc.com) (144.160.20.54) by server-15.tower-203.messagelabs.com with AES256-SHA encrypted SMTP; 1 Apr 2008 15:13:11 -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 m31FDEXn010278 for ; Tue, 1 Apr 2008 11:13:14 -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 m31FDBLn010237 for ; Tue, 1 Apr 2008 11:13:11 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Tue, 1 Apr 2008 10:13:10 -0500 Message-ID: <28F05913385EAC43AF019413F674A0171246ED96@OCCLUST04EVS1.ugd.att.com> In-Reply-To: <160DE07A1C4F8E4AA2715DEC577DA491936492@srvxchg3.cablelabs.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [PEPPERMINT] Proposed Updated Charter Thread-Index: AciTaz5+nL5X5hseRkSarzcft2yW4AALIH5QABwqvqAAAInooA== References: <160DE07A1C4F8E4AA2715DEC577DA49193647C@srvxchg3.cablelabs.com> <28F05913385EAC43AF019413F674A0171246ED86@OCCLUST04EVS1.ugd.att.com> <160DE07A1C4F8E4AA2715DEC577DA491936492@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 Daryl, I view AT&T differently depending on whether I am accessing them intranet versus as an AT&T customer, so I do not see them as being the same. In the intranet case, it is the AT&T IT department that controls everything, which is different than when I am a customer of AT&T. Martin -----Original Message----- From: Daryl Malas [mailto:D.Malas@cablelabs.com] Sent: Tuesday, April 01, 2008 11:01 AM To: DOLLY, MARTIN C, ATTLABS; peppermint@ietf.org Subject: RE: [PEPPERMINT] Proposed Updated Charter Hello Martin, I feel it is appropriate to include enterprises within the context of an SSP. Per the definition of an SSP, an enterprise provides SIP services to its customers (employees), in much the same an operator would. This is the intention within the charter update below. --Daryl -----Original Message----- From: DOLLY, MARTIN C, ATTLABS [mailto:mdolly@att.com] Sent: Monday, March 31, 2008 7: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 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 3C39728C1C4; Tue, 1 Apr 2008 08:09:01 -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 DE20528C16F for ; Tue, 1 Apr 2008 08:08:59 -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 NAxDLIEDrSMu for ; Tue, 1 Apr 2008 08:08:58 -0700 (PDT) Received: from ondar.cablelabs.com (ondar.cablelabs.com [192.160.73.61]) by core3.amsl.com (Postfix) with ESMTP id B251D3A6AF7 for ; Tue, 1 Apr 2008 08:08:58 -0700 (PDT) Received: from kyzyl.cablelabs.com (kyzyl [10.253.0.7]) by ondar.cablelabs.com (8.14.2/8.14.2) with ESMTP id m31F8s4i028799; Tue, 1 Apr 2008 09:08:55 -0600 Received: from srvxchg3.cablelabs.com (10.5.0.25) by kyzyl.cablelabs.com (F-Secure/fsigk_smtp/511/kyzyl.cablelabs.com); Tue, 1 Apr 2008 09:08:54 -0700 (MST) X-Virus-Status: clean(F-Secure/fsigk_smtp/511/kyzyl.cablelabs.com) X-Mimeole: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Tue, 1 Apr 2008 09:08:54 -0600 Message-ID: <160DE07A1C4F8E4AA2715DEC577DA491936493@srvxchg3.cablelabs.com> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [PEPPERMINT] Proposed Updated Charter Thread-Index: AciTaz5+nL5X5hseRkSarzcft2yW4AALIH5QAAEU7fAAG0u54A== References: <160DE07A1C4F8E4AA2715DEC577DA49193647C@srvxchg3.cablelabs.com> <28F05913385EAC43AF019413F674A0171246ED86@OCCLUST04EVS1.ugd.att.com> From: "Daryl Malas" To: "Hadriel Kaplan" , "DOLLY, MARTIN C, ATTLABS" , X-Approved: ondar 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 Hadriel, This was the intention. Thanks, Daryl -----Original Message----- From: Hadriel Kaplan [mailto:HKaplan@acmepacket.com] Sent: Monday, March 31, 2008 8:18 PM To: DOLLY, MARTIN C, ATTLABS; Daryl Malas; peppermint@ietf.org Subject: RE: [PEPPERMINT] Proposed Updated Charter 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 A27C328C4D2; Tue, 1 Apr 2008 08:05:03 -0700 (PDT) X-Original-To: peppermint@core3.amsl.com Delivered-To: peppermint@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A4BC628C4A1 for ; Tue, 1 Apr 2008 08:05:02 -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 MbU+egqIj-KA for ; Tue, 1 Apr 2008 08:05:01 -0700 (PDT) Received: from ondar.cablelabs.com (ondar.cablelabs.com [192.160.73.61]) by core3.amsl.com (Postfix) with ESMTP id 36F3528C547 for ; Tue, 1 Apr 2008 08:01:15 -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 m31F1BAr028058; Tue, 1 Apr 2008 09:01:11 -0600 Received: from srvxchg3.cablelabs.com (10.5.0.25) by kyzyl.cablelabs.com (F-Secure/fsigk_smtp/511/kyzyl.cablelabs.com); Tue, 1 Apr 2008 09:01:11 -0700 (MST) X-Virus-Status: clean(F-Secure/fsigk_smtp/511/kyzyl.cablelabs.com) X-Mimeole: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Tue, 1 Apr 2008 09:01:11 -0600 Message-ID: <160DE07A1C4F8E4AA2715DEC577DA491936492@srvxchg3.cablelabs.com> In-Reply-To: <28F05913385EAC43AF019413F674A0171246ED86@OCCLUST04EVS1.ugd.att.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [PEPPERMINT] Proposed Updated Charter Thread-Index: AciTaz5+nL5X5hseRkSarzcft2yW4AALIH5QABwqvqA= References: <160DE07A1C4F8E4AA2715DEC577DA49193647C@srvxchg3.cablelabs.com> <28F05913385EAC43AF019413F674A0171246ED86@OCCLUST04EVS1.ugd.att.com> From: "Daryl Malas" To: "DOLLY, MARTIN C, ATTLABS" , X-Approved: ondar 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 Martin, I feel it is appropriate to include enterprises within the context of an SSP. Per the definition of an SSP, an enterprise provides SIP services to its customers (employees), in much the same an operator would. This is the intention within the charter update below. --Daryl -----Original Message----- From: DOLLY, MARTIN C, ATTLABS [mailto:mdolly@att.com] Sent: Monday, March 31, 2008 7: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 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 D39C428C1A0; Tue, 1 Apr 2008 04:08: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 0A8BD28C205 for ; Tue, 1 Apr 2008 04:08:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.777 X-Spam-Level: X-Spam-Status: No, score=-103.777 tagged_above=-999 required=5 tests=[AWL=2.822, 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 ghDzbdoQPsKA for ; Tue, 1 Apr 2008 04:08:31 -0700 (PDT) Received: from mail121.messagelabs.com (mail121.messagelabs.com [216.82.241.195]) by core3.amsl.com (Postfix) with ESMTP id 6AECD3A6D76 for ; Tue, 1 Apr 2008 04:08:31 -0700 (PDT) X-VirusChecked: Checked X-Env-Sender: mdolly@att.com X-Msg-Ref: server-6.tower-121.messagelabs.com!1207048107!20982860!1 X-StarScan-Version: 5.5.12.14.2; banners=-,-,- X-Originating-IP: [144.160.20.54] Received: (qmail 29165 invoked from network); 1 Apr 2008 11:08:28 -0000 Received: from sbcsmtp7.sbc.com (HELO mlpi135.enaf.sfdc.sbc.com) (144.160.20.54) by server-6.tower-121.messagelabs.com with AES256-SHA encrypted SMTP; 1 Apr 2008 11:08: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 m31B8REC019272 for ; Tue, 1 Apr 2008 07:08:27 -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 m31B8K5Z019227 for ; Tue, 1 Apr 2008 07:08:20 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Tue, 1 Apr 2008 06:08:19 -0500 Message-ID: <28F05913385EAC43AF019413F674A0171246ED87@OCCLUST04EVS1.ugd.att.com> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [PEPPERMINT] Proposed Updated Charter Thread-Index: AciTaz5+nL5X5hseRkSarzcft2yW4AALIH5QAAEU7fAAExRccA== References: <160DE07A1C4F8E4AA2715DEC577DA49193647C@srvxchg3.cablelabs.com> <28F05913385EAC43AF019413F674A0171246ED86@OCCLUST04EVS1.ugd.att.com> From: "DOLLY, MARTIN C, ATTLABS" To: "Hadriel Kaplan" , "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 Hadriel, I do not agree with your example, yet. Can you be a little more specific, as to what information peppermint would provide here? Thanks, Martin -----Original Message----- From: Hadriel Kaplan [mailto:HKaplan@acmepacket.com] Sent: Monday, March 31, 2008 10:18 PM To: DOLLY, MARTIN C, ATTLABS; Daryl Malas; peppermint@ietf.org Subject: RE: [PEPPERMINT] Proposed Updated Charter 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 C9CD63A6A08; Mon, 28 Apr 2008 09:21:35 -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 78AFE3A6826 for ; Mon, 28 Apr 2008 09:21:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.449 X-Spam-Level: X-Spam-Status: No, score=-3.449 tagged_above=-999 required=5 tests=[AWL=0.150, 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 4LAKaCJ5Qd3O for ; Mon, 28 Apr 2008 09:21:33 -0700 (PDT) Received: from mail.songbird.com (mail.songbird.com [208.184.79.10]) by core3.amsl.com (Postfix) with ESMTP id 8484A3A6C55 for ; Mon, 28 Apr 2008 09:21:24 -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 m3SGJq2o012991 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Mon, 28 Apr 2008 09:19:54 -0700 From: "Richard Shockey" To: , References: <125b01c89fe6$14f823c0$3ee86b40$@us> <6F1F1385-8781-491A-9FEA-C9AC440B0D65@voxeo.com> <042601c8a028$78390d40$68ab27c0$@us> In-Reply-To: Date: Mon, 28 Apr 2008 12:20:26 -0400 Message-ID: <04bd01c8a94b$c5d94110$518bc330$@us> MIME-Version: 1.0 X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: AcipO/KyN3AxXTciQjqCv2fgsJEexAADyK8Q Content-Language: en-us X-SongbirdInformation: support@songbird.com for more information X-Songbird: Clean X-Songbird-From: richard@shockey.us Subject: Re: [PEPPERMINT] DRINKS PROPOSED Charter ..comments please. 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 think that is a perfectly reasonable idea, but the task at hand is to get a charter approved. I don't think there would be a problem with a place holder. > -----Original Message----- > From: peppermint-bounces@ietf.org [mailto:peppermint-bounces@ietf.org] > On Behalf Of Ray.Bellis@nominet.org.uk > Sent: Monday, April 28, 2008 7:28 AM > To: peppermint@ietf.org > Subject: Re: [PEPPERMINT] DRINKS PROPOSED Charter ..comments please. > > > > DY> Do you see the data to be exchanged to also include > information > > > using in billing? > > > > IMHO no .. that would be a charter stretch I personally believe the > > AD's/IESG would not accept, at this time. Remember this is a new WG. > The > > first order of business is to produce results based on a limited set > of > > initial tasks. On the basis of initial WG success it is always > possible > to > > build on success to take on other tasks the WG deems useful. > > Richard, > > Could we consider at least allowing for some sort of opaque identifier > to > represent billing information, with the mapping between that > identifier > and "real" billing information "to be defined later, possibly > elsewhere" ? > > kind regards, > > Ray > > -- > Ray Bellis, MA(Oxon) > Senior Researcher in Advanced Projects, Nominet > e: ray@nominet.org.uk, t: +44 1865 332211 > _______________________________________________ > 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 C89273A6E98; Mon, 28 Apr 2008 07:28:03 -0700 (PDT) X-Original-To: peppermint@core3.amsl.com Delivered-To: peppermint@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 45EC228C0EC for ; Mon, 28 Apr 2008 04:27:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mdfooQQO11GP for ; Mon, 28 Apr 2008 04:27:34 -0700 (PDT) Received: from mx4.nominet.org.uk (mx4.nominet.org.uk [213.248.199.24]) by core3.amsl.com (Postfix) with ESMTP id 390703A6AC9 for ; Mon, 28 Apr 2008 04:27:33 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.25,716,1199664000"; d="scan'208";a="657476" Received: from notes1.nominet.org.uk ([213.248.197.128]) by mx4.nominet.org.uk with ESMTP; 28 Apr 2008 12:27:36 +0100 In-Reply-To: <042601c8a028$78390d40$68ab27c0$@us> References: <125b01c89fe6$14f823c0$3ee86b40$@us> <6F1F1385-8781-491A-9FEA-C9AC440B0D65@voxeo.com> <042601c8a028$78390d40$68ab27c0$@us> To: peppermint@ietf.org MIME-Version: 1.0 X-Mailer: Lotus Notes Build VMac_Beta85_20080115_MM2 January 15, 2008 Message-ID: From: Ray.Bellis@nominet.org.uk Date: Mon, 28 Apr 2008 12:27:35 +0100 X-MIMETrack: Serialize by Router on notes1/Nominet(Release 7.0.1FP1 | May 25, 2006) at 28/04/2008 12:27:35 PM, Serialize complete at 28/04/2008 12:27:35 PM X-Mailman-Approved-At: Mon, 28 Apr 2008 07:28:02 -0700 Subject: Re: [PEPPERMINT] DRINKS PROPOSED Charter ..comments please. 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 > > DY> Do you see the data to be exchanged to also include information > > using in billing? > > IMHO no .. that would be a charter stretch I personally believe the > AD's/IESG would not accept, at this time. Remember this is a new WG. The > first order of business is to produce results based on a limited set of > initial tasks. On the basis of initial WG success it is always possible to > build on success to take on other tasks the WG deems useful. Richard, Could we consider at least allowing for some sort of opaque identifier to represent billing information, with the mapping between that identifier and "real" billing information "to be defined later, possibly elsewhere" ? kind regards, Ray -- Ray Bellis, MA(Oxon) Senior Researcher in Advanced Projects, Nominet e: ray@nominet.org.uk, t: +44 1865 332211 _______________________________________________ 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 091DD3A6D59; Thu, 24 Apr 2008 14:03:57 -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 2193628C2BA for ; Thu, 24 Apr 2008 14:03:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.562 X-Spam-Level: X-Spam-Status: No, score=-0.562 tagged_above=-999 required=5 tests=[AWL=0.268, BAYES_00=-2.599, HELO_EQ_AT=0.424, HOST_EQ_AT=0.745, J_CHICKENPOX_32=0.6] 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 r4lvkBAbltEQ for ; Thu, 24 Apr 2008 14:03:53 -0700 (PDT) Received: from labs.nic.at (nat.labs.nic.at [83.136.33.3]) by core3.amsl.com (Postfix) with ESMTP id 0E31A3A6C2C for ; Thu, 24 Apr 2008 14:03:52 -0700 (PDT) Received: from lendl by labs.nic.at with local (Exim 3.36 #1 (Debian)) id 1Jp8bj-0000vm-00 for ; Thu, 24 Apr 2008 23:03:55 +0200 Date: Thu, 24 Apr 2008 23:03:55 +0200 From: Otmar Lendl To: "peppermint@ietf.org" Message-ID: <20080424210354.GA3472@nic.at> Mail-Followup-To: Otmar Lendl , "peppermint@ietf.org" References: <092B2658AAB56A4D80836399A4C4703104526DBE@ASHEVS002.mcilink.com> <160DE07A1C4F8E4AA2715DEC577DA491936566@srvxchg3.cablelabs.com> <092B2658AAB56A4D80836399A4C4703104526E1F@ASHEVS002.mcilink.com> <160DE07A1C4F8E4AA2715DEC577DA491936569@srvxchg3.cablelabs.com> <092B2658AAB56A4D80836399A4C4703104527139@ASHEVS002.mcilink.com> <"092B2658AAB56A4D80836399A4C47031037DD575"@ASHEVS002.mcilink.com> <100c01c8a61e$fdddf270$f999d750$@us> <092B2658AAB56A4D80836399A4C47031037DD579@ASHEVS002.mcilink.com> Mime-Version: 1.0 Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.9i Subject: Re: [PEPPERMINT] DRINKS PROPOSED Charter ..comments please. 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 On 2008/04/24 18:04, Hadriel Kaplan wrote: > > So to use the earlier analogy they do say "we're building a car", but > that car could be a minivan or pickup - but it's not going to be a > plane or boat. We're not building a car. We're building a gearbox. Some scoping regarding whether this gearbox is for a race-car or for a truck might be helpful, though. /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: 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 4F79228C148; Thu, 24 Apr 2008 11:37: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 9D06A3A67A7 for ; Thu, 24 Apr 2008 11:37:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.449 X-Spam-Level: X-Spam-Status: No, score=-3.449 tagged_above=-999 required=5 tests=[AWL=0.150, 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 y1EPrmrtjNRl for ; Thu, 24 Apr 2008 11:37:18 -0700 (PDT) Received: from mail.songbird.com (mail.songbird.com [208.184.79.10]) by core3.amsl.com (Postfix) with ESMTP id D1DED3A6D0C for ; Thu, 24 Apr 2008 11:36:31 -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 m3OIZMYT006447 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Thu, 24 Apr 2008 11:35:23 -0700 From: "Richard Shockey" To: "'David Schwartz'" , "'Hadriel Kaplan'" References: <125b01c89fe6$14f823c0$3ee86b40$@us> <20080419210654.GA30568@nic.at> <20080420211101.GA32096@nic.at> <1a6601c8a3dd$49ca8c50$dd5fa4f0$@us> <20080422144452.GA582@nic.at> <14b501c8a495$758aeb60$60a0c220$@us> <160DE07A1C4F8E4AA2715DEC577DA49193654F@srvxchg3.cablelabs.com> <154801c8a49b$22fbc2b0$68f34810$@us> <160DE07A1C4F8E4AA2715DEC577DA491936564@srvxchg3.cablelabs.com> <092B2658AAB56A4D80836399A4C4703104526DBE@ASHEVS002.mcilink.com> <160DE07A1C4F8E4AA2715DEC577DA491936566@srvxchg3.cablelabs.com> <092B2658AAB56A4D80836399A4C4703104526E1F@ASHEVS002.mcilink.com> <160DE07A1C4F8E4AA2715DEC577DA491936569@srvxchg3.cablelabs.com> <092B2658AAB56A4D80836399A4C4703104527139@ASHEVS002.mcilink.com> <"092B265 8AAB56A4D80836! 399A4C47031037DD575"@AS HEVS002.mcilink.com> <100c01c8a61e$fdddf270$f999d750$@us> <092B2658AAB56A4D80836399A4C47031037DD579@ASHEVS002.mcilink.com> <6CD59B58-979D-4850-B940-4AF55B7FDCB8@xconnect.net> In-Reply-To: <6CD59B58-979D-4850-B940-4AF55B7FDCB8@xconnect.net> Date: Thu, 24 Apr 2008 14:36:09 -0400 Message-ID: <155601c8a63a$11ff09e0$35fd1da0$@us> MIME-Version: 1.0 X-Mailer: Microsoft Office Outlook 12.0 thread-index: AcimNSobSTVk+l2OSN+TGI0FHKcAYwAALNgA Content-Language: en-us X-SongbirdInformation: support@songbird.com for more information X-Songbird: Clean X-Songbird-From: richard@shockey.us Cc: 'Daryl Malas' , peppermint@ietf.org Subject: Re: [PEPPERMINT] DRINKS PROPOSED Charter ..comments please. 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 > > There has been much talk here about "going off the reservation" and > what the IESG will or won't approve. > > I think it would be helpful if one (or both) of the ADs would please > chime in here as to why there is a need to bound the solution space > when there are some valid arguments being presented on this list as to > why this is not a good idea. The AD's don't need to explain themselves. You don't seem to be listening here. All proposed WG charters must, within reason, clearly bound the scope of the problem they want to solve and what aspect of the problem they want to tackle first. At least in the beginning. The scope of work in the initial charter will be bounded, period. End of story. That is the IETF process. What don't you understand? This is what you do to get a charter approved in the IESG. The IETF has way too many examples of WG that go "wandering off the reservation" and try and tackle problems either tangential or impossible to solve or create work that goes on endlessly. What Daryl and I, as existing WG chairs, among others are reflecting is very practical experience how this process works. Find a problem, narrowly define the scope of the solution, fix the problem (incrementally, if possible), declare victory, go home. Ask any IETF WG chair about this. > > While no one wants to boil the ocean it may be a waste of time if all > we want to do is catch a small tuna. First you have to buy a hook than put the hook in the water .... we ran two successful BOF's pretty everyone including the AD's "get it". > > I think the discussion on this topic proves 2 things: > > 1 the great interest in the topic > 2 the different outlooks on the problem > > While I have nothing intrinsic against the proposed text one cannot > deny its limiting and in light of some of the resistance on the list - > maybe counterproductive at this point. We have come this far. We are very close to a implementable first charter and this discussion on whether there _should_ be limits on what the proposed WG should or should not do is definitely becoming counterproductive. The only useful discussion is what those limits actually are. > _______________________________________________ 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 8CB043A6AA3; Thu, 24 Apr 2008 11:02:10 -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 AAF073A69BA for ; Thu, 24 Apr 2008 11:02:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.011 X-Spam-Level: X-Spam-Status: No, score=0.011 tagged_above=-999 required=5 tests=[AWL=0.300, BAYES_00=-2.599, HELO_EQ_DE=0.35, RCVD_IN_BL_SPAMCOP_NET=1.96] 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 BJpEJOaM45jy for ; Thu, 24 Apr 2008 11:02:04 -0700 (PDT) Received: from moutng.kundenserver.de (moutng.kundenserver.de [212.227.126.179]) by core3.amsl.com (Postfix) with ESMTP id E34903A6C4E for ; Thu, 24 Apr 2008 11:02:03 -0700 (PDT) Received: from [172.16.28.58] ([80.250.149.60]) by mrelayeu.kundenserver.de (node=mrelayeu0) with ESMTP (Nemesis) id 0MKwh2-1Jp5la1uJC-0007kH; Thu, 24 Apr 2008 20:01:57 +0200 References: <125b01c89fe6$14f823c0$3ee86b40$@us> <20080419210654.GA30568@nic.at> <20080420211101.GA32096@nic.at> <1a6601c8a3dd$49ca8c50$dd5fa4f0$@us> <20080422144452.GA582@nic.at> <14b501c8a495$758aeb60$60a0c220$@us> <160DE07A1C4F8E4AA2715DEC577DA49193654F@srvxchg3.cablelabs.com> <154801c8a49b$22fbc2b0$68f34810$@us> <160DE07A1C4F8E4AA2715DEC577DA491936564@srvxchg3.cablelabs.com> <092B2658AAB56A4D80836399A4C4703104526DBE@ASHEVS002.mcilink.com> <160DE07A1C4F8E4AA2715DEC577DA491936566@srvxchg3.cablelabs.com> <092B2658AAB56A4D80836399A4C4703104526E1F@ASHEVS002.mcilink.com> <160DE07A1C4F8E4AA2715DEC577DA491936569@srvxchg3.cablelabs.com> <092B2658AAB56A4D80836399A4C4703104527139@ASHEVS002.mcilink.com> <"092B265 8AAB56A4D808363 99A4C47031037DD575"@ASHEVS002.mcilink.com> <100c01c8a61e$fdddf270$f999d750$@us> <092B2658AAB56A4D80836399A4C47031037DD579@ASHEVS002.mcilink.com> Message-Id: <6CD59B58-979D-4850-B940-4AF55B7FDCB8@xconnect.net> From: David Schwartz To: Hadriel Kaplan In-Reply-To: X-Mailer: iPhone Mail (3A109a) Mime-Version: 1.0 (iPhone Mail 3A109a) Date: Thu, 24 Apr 2008 21:01:45 +0300 X-Provags-ID: V01U2FsdGVkX19eNCBuSyYjT4OeV6sIkSOaMNiGqAWQ5eD4cF4 qPDPiWHrJr3TaxzmqpJ80oiRBnDCGjv2Nam43vj0uCATRIk3FV IDKvTt3/LGYA2gSNj01XQ== Cc: "peppermint@ietf.org" , Daryl Malas Subject: Re: [PEPPERMINT] DRINKS PROPOSED Charter ..comments please. 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 There has been much talk here about "going off the reservation" and what the IESG will or won't approve. I think it would be helpful if one (or both) of the ADs would please chime in here as to why there is a need to bound the solution space when there are some valid arguments being presented on this list as to why this is not a good idea. While no one wants to boil the ocean it may be a waste of time if all we want to do is catch a small tuna. I think the discussion on this topic proves 2 things: 1 the great interest in the topic 2 the different outlooks on the problem While I have nothing intrinsic against the proposed text one cannot deny its limiting and in light of some of the resistance on the list - maybe counterproductive at this point. ADs? On Apr 24, 2008, at 7:31 PM, Hadriel Kaplan wrote: > > I agree that it is constraining the solution to some degree, but I > think what Richard has said is we're going to need to do that a bit > to get this past the IESG. My guess is they're just worried we > might try to take on too much or overstep the IETF's comfort zone. > > The terms described so far though are fairly generic, and I think > one can claim a lot of things would fall under those terms. > > So to use the earlier analogy they do say "we're building a car", > but that car could be a minivan or pickup - but it's not going to be > a plane or boat. If a mechanism we choose happens to be Chitty- > Chitty Bang-Bang, that's ok and I'm not even sure we'd have to > revisit the charter to accept that type of solution; but the current > charter's just saying it's not in our scope to try to build that > type of vehicle at the outset. > > If we find that this scope is too constrictive, then we can always > revisit and change the charter. I don't think there will be too > much disagreement to changing that if the SSP community needs > something more. And if there is disagreement to that, well... it's > fairly pointless to create a mechanism that won't be used. (not that > the IETF hasn't done that a hundred times :) > > -hadriel > _______________________________________________ > 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 D37013A6B7E; Thu, 24 Apr 2008 09:39:18 -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 143CF3A6BA0 for ; Thu, 24 Apr 2008 09:39:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.559 X-Spam-Level: X-Spam-Status: No, score=-2.559 tagged_above=-999 required=5 tests=[AWL=0.040, 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 kef7cxB4gMal for ; Thu, 24 Apr 2008 09:39:17 -0700 (PDT) Received: from etmail.acmepacket.com (etmail.acmepacket.com [216.41.24.6]) by core3.amsl.com (Postfix) with ESMTP id C92953A6B0F for ; Thu, 24 Apr 2008 09:39:16 -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.263.0; Thu, 24 Apr 2008 12:38:49 -0400 Received: from mail.acmepacket.com ([216.41.24.7]) by mail.acmepacket.com ([216.41.24.7]) with mapi; Thu, 24 Apr 2008 12:38:49 -0400 From: Hadriel Kaplan To: Richard Shockey , "peppermint@ietf.org" Date: Thu, 24 Apr 2008 12:36:07 -0400 Thread-Topic: DRINKS PROPOSED Charter Version 02 Thread-Index: Acild5bQIMI2yamUS/eNn2gBoulzzQAEsfqAAAwJVRAAEfJPwAAFPVwwAALbrRAAATsvIAAASCjw Message-ID: References: <125b01c89fe6$14f823c0$3ee86b40$@us><20080419210654.GA30568@nic.at><20080420211101.GA32096@nic.at> <1a6601c8a3dd$49ca8c50$dd5fa4f0$@us><20080422144452.GA582@nic.at><14b501c8a495$758aeb60$60a0c220$@us><160DE07A1C4F8E4AA2715DEC577DA49193654F@srvxchg3.cablelabs.com><154801c8a49b$22fbc2b0$68f34810$@us><160DE07A1C4F8E4AA2715DEC577DA491936564@srvxchg3.cablelabs.com><092B2658AAB56A4D80836399A4C4703104526DBE@ASHEVS002.mcilink.com><160DE07A1C4F8E4AA2715DEC577DA491936566@srvxchg3.cablelabs.com><092B2658AAB56A4D80836399A4C4703104526E1F@ASHEVS002.mcilink.com><160DE07A1C4F8E4AA2715DEC577DA491936569@srvxchg3.cablelabs.com><092B2658AAB56A4D80836399A4C4703104527139@ASHEVS002.mcilink.com><059501c8a58b$e4899c40$ad9cd4c0$@us> <34DA635B184A644DA4588E260EC0A25A129FD159@ACCLUST02EVS1.ugd.att.com> <0e3001c8a617$c151eed0$43f5cc70$@us> <116501c8a628$c38a69f0$4a9f3dd0$@us> In-Reply-To: <116501c8a628$c38a69f0$4a9f3dd0$@us> 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] DRINKS PROPOSED Charter Version 02 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 Looks good to me, fwiw. -hadriel > -----Original Message----- > From: Richard Shockey [mailto:richard@shockey.us] > Sent: Thursday, April 24, 2008 12:32 PM > To: Hadriel Kaplan; 'PFAUTZ, PENN L, ATTCORP'; 'Dwight, Timothy M (Tim)'; > 'Daryl Malas'; 'Otmar Lendl'; peppermint@ietf.org > Subject: DRINKS PROPOSED Charter Version 02 > > > I like Penn's calling for Targets ... so this is what I've got now. > > Flame away .. > > ***** > > > Proposed Charter > > > DRINKS Data for Reachability of Inter/tra-NetworK SIP > > > Current Status: Proposed Working Group > > > Mailing Lists: > > peppermint@ietf.org > > > General information about the mailing list is at: > > https://www1.ietf.org/mailman/listinfo/peppermint > > > Area Directorate: Real Time Applications (RAI) > > > RAI Director(s): > > Jon Peterson jon.peterson@neustar.biz > Cullen Jennings fluffy@cisco.com > > Chairs: TBD > > > PROPOSED CHARTER FOR PEPPERMINT > > The IETF has been working on various aspects of SIP-enabled Multimedia > administrative domains among SIP Service Providers (SSP's). SSP's are > entities that provide session services utilizing SIP signaling to their > customers. In addition, the IETF has done significant work on data > exchanges > among various network elements. > > The DRINKS working group is chartered with a scope that is orthogonal to > SPEERMINT and ENUM. The protocol work of DRINKS will be designed to build > from the work of SPEERMINT and ENUM to identify and define the data > structures and data exchange protocol(s) among SIP based Multimedia > administrative domains. > > The ENUM working group is specifically chartered to develop protocols that > involve the translation of E.164 numbers to URIs. While the SPEERMINT > working group has been chartered to develop requirements and best current > practices among real-time application SSPs and to describe how such > services > may best interconnect across administrative boundaries. > > These administrative domains may be of any practical size and could be any > type of SSP, such as recognized telephony carriers, enterprises, end-user > groups, or Federations. Data exchanges among these administrative domains > may be bi-lateral or multi-lateral in nature, and could include bulk > updates > and/or more granular real-time updates. > > Administrative domains may exchange data through the use of an external > registry to aggregate data from multiple administrative domains or > multiple > data providers into a single view. > > The DRINKS WG will provide details of how Session Establishment Data (SED) > is collected, what comprises SED, how SED should be used to properly > identify an optimal path to a destination SIP user agent (UA),either > internally or externally to the SSP. In addition DRINKS will insure that > the > SED and the SIP session data is securely exchanged between the peering > functions. > > Typical SED data might include: > > + Routes > - Destination SIP/SIPS/TEL URI Egress and Ingress Routes > - Relevant route names, identifiers, and services > - Attributes affecting route selection > - PSTN database information > > + Targets > - Individual, ranges, or groups of user-agent identifiers > - Target aggregation entities (e.g. service areas) and > target-to-aggregate associations > > + Treatment Profiles > - Priority > - Location > > Potential SED Data types not in scope will be session rating or other > billing or pricing information between SSP's > > The working group will draw upon expert advice and on-going consultation > from the ENUM and SPEERMINT working groups, and also the XML Directorate. > The working group will consider the reuse of elements of RFC 4114. > > The final work product(s) from this working group will utilize and be > based > on XML documents and XML document exchanges. > > > > PROPOSED GOALS AND MILESTONES > > > Requirements for Session Establishment Data (SED) data exchanges. -- Sept > 08 > > > Exchanging of Session Establishment Data (SED) from data providers to > registries or between bi/multi-lateral partners. -- Nov 08 > > Exchange of Session Establishment Data (SED) from registries to Location > Routing Function databases. --- Feb 09 _______________________________________________ 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 439FA28C245; Thu, 24 Apr 2008 09:34: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 46BCD28C10A for ; Thu, 24 Apr 2008 09:34:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.556 X-Spam-Level: X-Spam-Status: No, score=-2.556 tagged_above=-999 required=5 tests=[AWL=0.043, 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 yMq3E28cfTni for ; Thu, 24 Apr 2008 09:34:41 -0700 (PDT) Received: from etmail.acmepacket.com (etmail.acmepacket.com [216.41.24.6]) by core3.amsl.com (Postfix) with ESMTP id 06E9528C2CA for ; Thu, 24 Apr 2008 09:34:12 -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.263.0; Thu, 24 Apr 2008 12:33:44 -0400 Received: from mail.acmepacket.com ([216.41.24.7]) by mail.acmepacket.com ([216.41.24.7]) with mapi; Thu, 24 Apr 2008 12:33:44 -0400 From: Hadriel Kaplan To: "Dwight, Timothy M (Tim)" , Richard Shockey , "PFAUTZ, PENN L, ATTCORP" , Daryl Malas , Otmar Lendl , "peppermint@ietf.org" Date: Thu, 24 Apr 2008 12:31:02 -0400 Thread-Topic: [PEPPERMINT] DRINKS PROPOSED Charter ..comments please. Thread-Index: Acild5bQIMI2yamUS/eNn2gBoulzzQAEsfqAAAwJVRAAEfJPwAAFPVwwAABjOUAAATE9EAAA1rogAAFSCTA= Message-ID: References: <125b01c89fe6$14f823c0$3ee86b40$@us> <20080419210654.GA30568@nic.at> <20080420211101.GA32096@nic.at> <1a6601c8a3dd$49ca8c50$dd5fa4f0$@us> <20080422144452.GA582@nic.at> <14b501c8a495$758aeb60$60a0c220$@us> <160DE07A1C4F8E4AA2715DEC577DA49193654F@srvxchg3.cablelabs.com> <154801c8a49b$22fbc2b0$68f34810$@us> <160DE07A1C4F8E4AA2715DEC577DA491936564@srvxchg3.cablelabs.com> <092B2658AAB56A4D80836399A4C4703104526DBE@ASHEVS002.mcilink.com> <160DE07A1C4F8E4AA2715DEC577DA491936566@srvxchg3.cablelabs.com> <092B2658AAB56A4D80836399A4C4703104526E1F@ASHEVS002.mcilink.com> <160DE07A1C4F8E4AA2715DEC577DA491936569@srvxchg3.cablelabs.com> <092B2658AAB56A4D80836399A4C4703104527139@ASHEVS002.mcilink.com> <"092B265 8AAB56A4D80836399A4C47031037DD575"@ASHEVS002.mcilink.com> <100c01c8a61e$fdddf270$f999d750$@us> <092B2658AAB56A4D80836399A4C47031037DD579@ASHEVS002.mcilink.com> In-Reply-To: <092B2658AAB56A4D80836399A4C47031037DD579@ASHEVS002.mcilink.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] DRINKS PROPOSED Charter ..comments please. 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 agree that it is constraining the solution to some degree, but I think what Richard has said is we're going to need to do that a bit to get this past the IESG. My guess is they're just worried we might try to take on too much or overstep the IETF's comfort zone. The terms described so far though are fairly generic, and I think one can claim a lot of things would fall under those terms. So to use the earlier analogy they do say "we're building a car", but that car could be a minivan or pickup - but it's not going to be a plane or boat. If a mechanism we choose happens to be Chitty-Chitty Bang-Bang, that's ok and I'm not even sure we'd have to revisit the charter to accept that type of solution; but the current charter's just saying it's not in our scope to try to build that type of vehicle at the outset. If we find that this scope is too constrictive, then we can always revisit and change the charter. I don't think there will be too much disagreement to changing that if the SSP community needs something more. And if there is disagreement to that, well... it's fairly pointless to create a mechanism that won't be used. (not that the IETF hasn't done that a hundred times :) -hadriel _______________________________________________ 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 BAB6B3A6D04; Thu, 24 Apr 2008 09:34:27 -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 B094D28C30A for ; Thu, 24 Apr 2008 09:34:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.432 X-Spam-Level: X-Spam-Status: No, score=-3.432 tagged_above=-999 required=5 tests=[AWL=0.167, 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 z9sk+i2v6dN7 for ; Thu, 24 Apr 2008 09:34:25 -0700 (PDT) Received: from mail.songbird.com (mail.songbird.com [208.184.79.10]) by core3.amsl.com (Postfix) with ESMTP id 74AA33A6BF0 for ; Thu, 24 Apr 2008 09:32:38 -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 m3OGVKUP023058 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Thu, 24 Apr 2008 09:31:21 -0700 From: "Richard Shockey" To: "'Hadriel Kaplan'" , "'PFAUTZ, PENN L, ATTCORP'" , "'Dwight, Timothy M \(Tim\)'" , "'Daryl Malas'" , "'Otmar Lendl'" , References: <125b01c89fe6$14f823c0$3ee86b40$@us><20080419210654.GA30568@nic.at><20080420211101.GA32096@nic.at> <1a6601c8a3dd$49ca8c50$dd5fa4f0$@us><20080422144452.GA582@nic.at><14b501c8a495$758aeb60$60a0c220$@us><160DE07A1C4F8E4AA2715DEC577DA49193654F@srvxchg3.cablelabs.com><154801c8a49b$22fbc2b0$68f34810$@us><160DE07A1C4F8E4AA2715DEC577DA491936564@srvxchg3.cablelabs.com><092B2658AAB56A4D80836399A4C4703104526DBE@ASHEVS002.mcilink.com><160DE07A1C4F8E4AA2715DEC577DA491936566@srvxchg3.cablelabs.com><092B2658AAB56A4D80836399A4C4703104526E1F@ASHEVS002.mcilink.com><160DE07A1C4F8E4AA2715DEC577DA491936569@srvxchg3.cablelabs.com><092B2658AAB56A4D80836399A4C4703104527139@ASHEVS002.mcilink.com><059501c8a58b$e4899c40$ad9cd4c0$@us> <34DA635B184A644DA4588E260EC0A25A129FD159@ACCLUST02EVS1.ugd.att.com> <0e3001c8a617$c151eed0$43f5cc70$@us> In-Reply-To: Date: Thu, 24 Apr 2008 12:32:07 -0400 Message-ID: <116501c8a628$c38a69f0$4a9f3dd0$@us> MIME-Version: 1.0 X-Mailer: Microsoft Office Outlook 12.0 thread-index: Acild5bQIMI2yamUS/eNn2gBoulzzQAEsfqAAAwJVRAAEfJPwAAFPVwwAALbrRAAATsvIA== Content-Language: en-us X-SongbirdInformation: support@songbird.com for more information X-Songbird: Clean X-Songbird-From: richard@shockey.us Subject: [PEPPERMINT] DRINKS PROPOSED Charter Version 02 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 like Penn's calling for Targets ... so this is what I've got now. Flame away .. ***** Proposed Charter DRINKS Data for Reachability of Inter/tra-NetworK SIP Current Status: Proposed Working Group Mailing Lists: peppermint@ietf.org General information about the mailing list is at: https://www1.ietf.org/mailman/listinfo/peppermint Area Directorate: Real Time Applications (RAI) RAI Director(s): Jon Peterson jon.peterson@neustar.biz Cullen Jennings fluffy@cisco.com Chairs: TBD PROPOSED CHARTER FOR PEPPERMINT The IETF has been working on various aspects of SIP-enabled Multimedia administrative domains among SIP Service Providers (SSP's). SSP's are entities that provide session services utilizing SIP signaling to their customers. In addition, the IETF has done significant work on data exchanges among various network elements. The DRINKS working group is chartered with a scope that is orthogonal to SPEERMINT and ENUM. The protocol work of DRINKS will be designed to build from the work of SPEERMINT and ENUM to identify and define the data structures and data exchange protocol(s) among SIP based Multimedia administrative domains. The ENUM working group is specifically chartered to develop protocols that involve the translation of E.164 numbers to URIs. While the SPEERMINT working group has been chartered to develop requirements and best current practices among real-time application SSPs and to describe how such services may best interconnect across administrative boundaries. These administrative domains may be of any practical size and could be any type of SSP, such as recognized telephony carriers, enterprises, end-user groups, or Federations. Data exchanges among these administrative domains may be bi-lateral or multi-lateral in nature, and could include bulk updates and/or more granular real-time updates. Administrative domains may exchange data through the use of an external registry to aggregate data from multiple administrative domains or multiple data providers into a single view. The DRINKS WG will provide details of how Session Establishment Data (SED) is collected, what comprises SED, how SED should be used to properly identify an optimal path to a destination SIP user agent (UA),either internally or externally to the SSP. In addition DRINKS will insure that the SED and the SIP session data is securely exchanged between the peering functions. Typical SED data might include: + Routes - Destination SIP/SIPS/TEL URI Egress and Ingress Routes - Relevant route names, identifiers, and services - Attributes affecting route selection - PSTN database information + Targets - Individual, ranges, or groups of user-agent identifiers - Target aggregation entities (e.g. service areas) and target-to-aggregate associations + Treatment Profiles - Priority - Location Potential SED Data types not in scope will be session rating or other billing or pricing information between SSP's The working group will draw upon expert advice and on-going consultation from the ENUM and SPEERMINT working groups, and also the XML Directorate. The working group will consider the reuse of elements of RFC 4114. The final work product(s) from this working group will utilize and be based on XML documents and XML document exchanges. PROPOSED GOALS AND MILESTONES Requirements for Session Establishment Data (SED) data exchanges. -- Sept 08 Exchanging of Session Establishment Data (SED) from data providers to registries or between bi/multi-lateral partners. -- Nov 08 Exchange of Session Establishment Data (SED) from registries to Location Routing Function databases. --- Feb 09 _______________________________________________ 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 D207B28C0E6; Thu, 24 Apr 2008 09:05:37 -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 2EDB13A6B3E for ; Thu, 24 Apr 2008 09:05:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xk1Rc-0zY5KD for ; Thu, 24 Apr 2008 09:05:35 -0700 (PDT) Received: from ashesmtp03.verizonbusiness.com (ASHESMTP03.verizonbusiness.com [198.4.8.167]) by core3.amsl.com (Postfix) with ESMTP id 6D0793A6B3D for ; Thu, 24 Apr 2008 09:05:32 -0700 (PDT) Received: from dgismtp04.wcomnet.com ([166.38.58.144]) by firewall.verizonbusiness.com (Sun Java(tm) System Messaging Server 6.3-5.02 (built Oct 12 2007; 32bit)) with ESMTP id <0JZU00B2R7DC1400@firewall.verizonbusiness.com> for peppermint@ietf.org; Thu, 24 Apr 2008 16:05:36 +0000 (GMT) Received: from dgismtp04.wcomnet.com ([127.0.0.1]) by dgismtp04.mcilink.com (iPlanet Messaging Server 5.2 HotFix 2.08 (built Sep 22 2005)) with SMTP id <0JZU00C277DC3J@dgismtp04.mcilink.com> for peppermint@ietf.org; Thu, 24 Apr 2008 16:05:36 +0000 (GMT) Received: from ASHSRV141.mcilink.com ([153.39.68.167]) by dgismtp04.mcilink.com (iPlanet Messaging Server 5.2 HotFix 2.08 (built Sep 22 2005)) with ESMTP id <0JZU00BDY7DB7U@dgismtp04.mcilink.com> for peppermint@ietf.org; Thu, 24 Apr 2008 16:05:36 +0000 (GMT) Received: from ASHEVS002.mcilink.com ([153.39.71.1]) by ASHSRV141.mcilink.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 24 Apr 2008 16:05:34 +0000 Date: Thu, 24 Apr 2008 16:05:21 +0000 From: "Dwight, Timothy M (Tim)" In-reply-to: <100c01c8a61e$fdddf270$f999d750$@us> To: Richard Shockey , "PFAUTZ, PENN L, ATTCORP" , Hadriel Kaplan , Daryl Malas , Otmar Lendl , peppermint@ietf.org Message-id: <092B2658AAB56A4D80836399A4C47031037DD579@ASHEVS002.mcilink.com> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message Thread-topic: [PEPPERMINT] DRINKS PROPOSED Charter ..comments please. Thread-index: Acild5bQIMI2yamUS/eNn2gBoulzzQAEsfqAAAwJVRAAEfJPwAAFPVwwAABjOUAAATE9EAAA1rog X-MS-Has-Attach: X-MS-TNEF-Correlator: References: <125b01c89fe6$14f823c0$3ee86b40$@us> <20080419210654.GA30568@nic.at> <20080420211101.GA32096@nic.at> <1a6601c8a3dd$49ca8c50$dd5fa4f0$@us> <20080422144452.GA582@nic.at> <14b501c8a495$758aeb60$60a0c220$@us> <160DE07A1C4F8E4AA2715DEC577DA49193654F@srvxchg3.cablelabs.com> <154801c8a49b$22fbc2b0$68f34810$@us> <160DE07A1C4F8E4AA2715DEC577DA491936564@srvxchg3.cablelabs.com> <092B2658AAB56A4D80836399A4C4703104526DBE@ASHEVS002.mcilink.com> <160DE07A1C4F8E4AA2715DEC577DA491936566@srvxchg3.cablelabs.com> <092B2658AAB56A4D80836399A4C4703104526E1F@ASHEVS002.mcilink.com> <160DE07A1C4F8E4AA2715DEC577DA491936569@srvxchg3.cablelabs.com> <092B2658AAB56A4D80836399A4C4703104527139@ASHEVS002.mcilink.com> <"092B265 8AAB56A4D80836399A4C47031037DD575"@ASHEVS002.mcilink.com> <100c01c8a61e$fdddf270$f999d750$@us> X-OriginalArrivalTime: 24 Apr 2008 16:05:34.0996 (UTC) FILETIME=[07811540:01C8A625] Subject: Re: [PEPPERMINT] DRINKS PROPOSED Charter ..comments please. 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, > > > > Richard, > > > > It is precisely because this is a bounding exercise, and specifically a > > bound placed on potential solutions, that this is a concern. We are > > trying to define the solution before defining the problem. > > No there is no definition of the solution here. Remember that is the IETF. > It is a requirement of new WG's that the scope of the proposed work be > properly bounded so that WG do not go "wandering off the reservation". It > not about defining the solution as much as defining what the > WG will NOT do. To define what the solution will not be, is to constrain the solution. That's my point. Is it not sufficient, to keep the WG "on the reservation", to constrain the problem space (rather than the solution space)? Obviously you have more IETF experience than me, but in my experience when working groups struggle it's more often because they lack clarity with respect to the problem they're trying to solve. > > Basically I find this debate contradictory. If the text starting > > "Typical SED data types might include..." below is truly meant only as > > examples that might or might not be part of the eventual solution > > developed by the WG, then it doesn't bound squat. > > I beg to differ. In the context of IETF WG charters this is perfectly > acceptable problem scoping. It does not propose a data model. We are in violent agreemnt that the *problem* needs to be scoped. But the text in question says nothing about the *problem*. It only proposes "typical SED data types". Whether you consider that a data model or not (sure looks like one to me) I don't see how it constrains the problem. > > and it doesn't accomplish anything, let's > > delete it and declare victory. To your question at the end, this is my proposal. > > If on the other hand its intent is to > > function on a bound on potential solutions, then it's disingenuous to > > refer to it as "Typical" and say it "might" include... more honest > > words would be something like "the WG will be strongly incented to use the > > following data model...". To which I would object. > > > Well what is your proposed WG scope text? See above. > Again (with some frustration) ... if anyone has a problem > with the current > text then they had better come up with what they propose at > the alternative. > I'm simply going to ignore any more objections that do not > propose real > alternatives to the text. I'm sure we can all agree to ignore each other. I'm not sure what that accomplishes. > > > > > > Tim > > > > > > > -----Original Message----- > > > From: Richard Shockey [mailto:richard@shockey.us] > > > Sent: Thursday, April 24, 2008 9:31 AM > > > To: 'PFAUTZ, PENN L, ATTCORP'; 'Hadriel Kaplan'; Dwight, > > > Timothy M (Tim); 'Daryl Malas'; 'Otmar Lendl'; > peppermint@ietf.org > > > Subject: RE: [PEPPERMINT] DRINKS PROPOSED Charter > ..comments please. > > > > > > I think we are all talking past each other here .. this is a > > > charter. This > > > is about what we might do not what we will do.. This is > a bounding > > > excersise. > > > > > > What I have now is > > > > > > ************** > > > > > > More specifically, DRINKS will provide details of how Session > > > Establishment > > > Data (SED) is collected, what comprises SED, how SED > should be used > > to > > > properly identify an optimal path to a destination SIP user > > > agent (UA), and > > > the secure manners in which SED and the SIP session data is > > exchanged > > > between the peering functions. > > > > > > > > > Typical SED data types might include: > > > > > > + Routes > > > - Destination SIP/SIPS/TEL URI Egress and Ingress Routes > > > - Relevant route names, identifiers, and services > > > - NAPTR context and associations > > > - PSTN database information > > > > > > + Service Areas > > > - Individual, ranges, or groups of ENUMservice identifiers > > > - Route associations > > > > > > + Treatment Profiles > > > - Priority > > > - Location > > > > > > Potential SED Data types not in scope will be session rating or > > other > > > billing or pricing information between SSP's > > > > > > ************** > > > > > > > > > > > > > > > > > > > -----Original Message----- > > > > From: PFAUTZ, PENN L, ATTCORP [mailto:ppfautz@att.com] > > > > Sent: Thursday, April 24, 2008 8:02 AM > > > > To: Hadriel Kaplan; Richard Shockey; Dwight, Timothy M (Tim); > > Daryl > > > > Malas; Otmar Lendl; peppermint@ietf.org > > > > Subject: RE: [PEPPERMINT] DRINKS PROPOSED Charter > > > ..comments please. > > > > > > > > Putting the Service Area concept in the charter still gives me > > > > heartburn. If Drinks is about more than ESPP that doesn't > > > make sense. > > > > If > > > > you want to introduce the concept of some aggregate > later, after > > > > robust > > > > discussion, fine. Not all of us are ready to drink > the kool-aid. > > > > > > > > > > > > Penn Pfautz > > > > > > > > -----Original Message----- > > > > From: peppermint-bounces@ietf.org > > > [mailto:peppermint-bounces@ietf.org] > > > > On Behalf Of Hadriel Kaplan > > > > Sent: Wednesday, April 23, 2008 11:45 PM > > > > To: Richard Shockey; 'Dwight, Timothy M (Tim)'; 'Daryl > > > Malas'; 'Otmar > > > > Lendl'; peppermint@ietf.org > > > > Subject: Re: [PEPPERMINT] DRINKS PROPOSED Charter > > > ..comments please. > > > > > > > > > > > > > -----Original Message----- > > > > > From: Richard Shockey [mailto:richard@shockey.us] > > > > > > > > > > No one is proposing a solution. We are describing > that we do > > not > > > > propose > > > > > exchanging data on Collateralized Debt Instruments > and Mortgage > > > > Interest > > > > > Swaps among SSP's > > > > > > > > Sure, I'm all in favor of getting a charter approved > > > post-haste. Even > > > > if it means my ideas for "Mortgage Interest eXchanges" > > > (MIX) will have > > > > to wait for a charter update. (too bad too, 'cause a > > > draft-drinks-mix > > > > would have been a recipe for success in my opinion) > > > > > > > > But seriously, how "detailed" do we need to be in the charter > > > > regarding > > > > this data? I think Daryl's proposed data with some > minor nits is > > > > broad > > > > enough not to cause heartburn later, while not letting us > > > get drunk in > > > > the possibilities. :) > > > > > > > > How about this: > > > > > > > > [begin] > > > > The scope will be limited to defining the following > > > criteria necessary > > > > for a SSP to respond with the necessary Session Establishment > > Data > > > > (SED) > > > > for both internal and external purposes: > > > > > > > > + Routes > > > > - Destination SIP/SIPS/TEL URI Egress > and Ingress > > > > Routes > > > > - Relevant route names, identifiers, > and services > > > > - Attributes affecting route selection > > > > + Service Areas > > > > - Individual, ranges, or groups of user-agent > > > > identifiers > > > > - Route-to-service-area associations > > > > + Treatment Profiles > > > > - Priority > > > > - Location > > > > > > > > The mechanism(s) chosen should be extensible, in case > additional > > > > criteria are deemed necessary to achieve the goals of > the WG in > > the > > > > future. > > > > [end] > > > > > > > > -hadriel > > > > _______________________________________________ > > > > 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 4A73228C263; Thu, 24 Apr 2008 08:59:15 -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 A6AB728C263 for ; Thu, 24 Apr 2008 08:59:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.553 X-Spam-Level: X-Spam-Status: No, score=-2.553 tagged_above=-999 required=5 tests=[AWL=0.046, 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 BnHrSXfBVg9Q for ; Thu, 24 Apr 2008 08:59:13 -0700 (PDT) Received: from etmail.acmepacket.com (etmail.acmepacket.com [216.41.24.6]) by core3.amsl.com (Postfix) with ESMTP id C33E328C253 for ; Thu, 24 Apr 2008 08:59:13 -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.263.0; Thu, 24 Apr 2008 11:58:46 -0400 Received: from mail.acmepacket.com ([216.41.24.7]) by mail.acmepacket.com ([216.41.24.7]) with mapi; Thu, 24 Apr 2008 11:58:46 -0400 From: Hadriel Kaplan To: Richard Shockey , "'PFAUTZ, PENN L, ATTCORP'" , "'Dwight, Timothy M (Tim)'" , 'Daryl Malas' , 'Otmar Lendl' , "peppermint@ietf.org" Date: Thu, 24 Apr 2008 11:56:03 -0400 Thread-Topic: [PEPPERMINT] DRINKS PROPOSED Charter ..comments please. Thread-Index: Acild5bQIMI2yamUS/eNn2gBoulzzQAEsfqAAAwJVRAAEfJPwAAFPVwwAALbrRA= Message-ID: References: <125b01c89fe6$14f823c0$3ee86b40$@us><20080419210654.GA30568@nic.at><20080420211101.GA32096@nic.at> <1a6601c8a3dd$49ca8c50$dd5fa4f0$@us><20080422144452.GA582@nic.at><14b501c8a495$758aeb60$60a0c220$@us><160DE07A1C4F8E4AA2715DEC577DA49193654F@srvxchg3.cablelabs.com><154801c8a49b$22fbc2b0$68f34810$@us><160DE07A1C4F8E4AA2715DEC577DA491936564@srvxchg3.cablelabs.com><092B2658AAB56A4D80836399A4C4703104526DBE@ASHEVS002.mcilink.com><160DE07A1C4F8E4AA2715DEC577DA491936566@srvxchg3.cablelabs.com><092B2658AAB56A4D80836399A4C4703104526E1F@ASHEVS002.mcilink.com><160DE07A1C4F8E4AA2715DEC577DA491936569@srvxchg3.cablelabs.com><092B2658AAB56A4D80836399A4C4703104527139@ASHEVS002.mcilink.com><059501c8a58b$e4899c40$ad9cd4c0$@us> <34DA635B184A644DA4588E260EC0A25A129FD159@ACCLUST02EVS1.ugd.att.com> <0e3001c8a617$c151eed0$43f5cc70$@us> In-Reply-To: <0e3001c8a617$c151eed0$43f5cc70$@us> 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] DRINKS PROPOSED Charter ..comments please. X-BeenThere: peppermint@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Provisioning Extensions in Peering Registries for Multimedia INTerconnection List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: peppermint-bounces@ietf.org Errors-To: peppermint-bounces@ietf.org > -----Original Message----- > From: Richard Shockey [mailto:richard@shockey.us] > > ************** > > More specifically, DRINKS will provide details of how Session > Establishment > Data (SED) is collected, what comprises SED, how SED should be used to > properly identify an optimal path to a destination SIP user agent (UA), > and > the secure manners in which SED and the SIP session data is exchanged > between the peering functions. > > > Typical SED data types might include: > > + Routes > - Destination SIP/SIPS/TEL URI Egress and Ingress Routes > - Relevant route names, identifiers, and services > - NAPTR context and associations > - PSTN database information I think we agreed to remove the "NAPTR" line from this. No? > + Service Areas > - Individual, ranges, or groups of ENUMservice identifiers > - Route associations I'm not quite sure what you mean by "ENUMservice identifiers" with regards to individual, ranges, or groups. I mean I know what an "ENUMservice" is per RFC 3761, I just have no idea what it has to do with a "service area", or what "ranges or groups" of them would mean. Also, "Route associations" is not a well-known term as far as I know. I *think* what you guys mean here is: + Service Areas - Individual, ranges, or groups of user-agent identifiers - Route-to-service-area associations > + Treatment Profiles > - Priority > - Location > > Potential SED Data types not in scope will be session rating or other > billing or pricing information between SSP's > > ************** > > _______________________________________________ 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 B289628C263; Thu, 24 Apr 2008 08:55: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 D676228C26B for ; Thu, 24 Apr 2008 08:55:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.599 X-Spam-Level: X-Spam-Status: No, score=-106.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id j1LGeB0VVxOD for ; Thu, 24 Apr 2008 08:55:23 -0700 (PDT) Received: from mail120.messagelabs.com (mail120.messagelabs.com [216.82.250.83]) by core3.amsl.com (Postfix) with ESMTP id DD27A28C275 for ; Thu, 24 Apr 2008 08:55:22 -0700 (PDT) X-VirusChecked: Checked X-Env-Sender: ppfautz@att.com X-Msg-Ref: server-3.tower-120.messagelabs.com!1209052526!30859814!1 X-StarScan-Version: 5.5.12.14.2; banners=-,-,- X-Originating-IP: [144.160.20.54] Received: (qmail 12045 invoked from network); 24 Apr 2008 15:55:27 -0000 Received: from sbcsmtp7.sbc.com (HELO mlpi135.enaf.sfdc.sbc.com) (144.160.20.54) by server-3.tower-120.messagelabs.com with AES256-SHA encrypted SMTP; 24 Apr 2008 15:55:27 -0000 Received: from enaf.sfdc.sbc.com (localhost.localdomain [127.0.0.1]) by mlpi135.enaf.sfdc.sbc.com (8.14.0/8.14.0) with ESMTP id m3OFtQn8022422; Thu, 24 Apr 2008 11:55:26 -0400 Received: from ACCLUST02EVS1.ugd.att.com (acst03.ugd.att.com [135.37.16.8]) by mlpi135.enaf.sfdc.sbc.com (8.14.0/8.14.0) with ESMTP id m3OFtLoo022376; Thu, 24 Apr 2008 11:55:21 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Thu, 24 Apr 2008 11:55:16 -0400 Message-ID: <34DA635B184A644DA4588E260EC0A25A129FD51D@ACCLUST02EVS1.ugd.att.com> In-Reply-To: <71A631B65B636B4D878D4CAD5BB68DD6107FFA38@rrc-dte-exs02.dte.telcordia.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [PEPPERMINT] DRINKS PROPOSED Charter ..comments please. Thread-Index: Acild5bQIMI2yamUS/eNn2gBoulzzQAEsfqAAAwJVRAAEfJPwAAFPVwwAAJ/GDAAAG/eAA== References: <125b01c89fe6$14f823c0$3ee86b40$@us><20080419210654.GA30568@nic.at><20080420211101.GA32096@nic.at><1a6601c8a3dd$49ca8c50$dd5fa4f0$@us><20080422144452.GA582@nic.at><14b501c8a495$758aeb60$60a0c220$@us><160DE07A1C4F8E4AA2715DEC577DA49193654F@srvxchg3.cablelabs.com><154801c8a49b$22fbc2b0$68f34810$@us><160DE07A1C4F8E4AA2715DEC577DA491936564@srvxchg3.cablelabs.com><092B2658AAB56A4D80836399A4C4703104526DBE@ASHEVS002.mcilink.com><160DE07A1C4F8E4AA2715DEC577DA491936566@srvxchg3.cablelabs.com><092B2658AAB56A4D80836399A4C4703104526E1F@ASHEVS002.mcilink.com><160DE07A1C4F8E4AA2715DEC577DA491936569@srvxchg3.cablelabs.com><092B2658AAB56A4D80836399A4C4703104527139@ASHEVS002.mcilink.com><059501c8a58b$e4899c40$ad9cd4c0$@us><34DA635B184A644DA4588E260EC0A25A129FD159@ACCLUST02EVS1.ugd.att.com> <0e3001c8a617$c151eed0$43f5cc70$@us> <71A631B65B636B4D878D4CAD5BB68DD6107FFA38@rrc-dte-exs02.dte.telcordia.com> From: "PFAUTZ, PENN L, ATTCORP" To: "Guyton, Deborah A" , "Richard Shockey" , "Hadriel Kaplan" , "Dwight, Timothy M (Tim)" , "Daryl Malas" , "Otmar Lendl" , Subject: Re: [PEPPERMINT] DRINKS PROPOSED Charter ..comments please. 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 How about... The scope will be limited to defining the following criteria necessary for a SSP to respond with the necessary Session Establishment Data (SED) for both internal and external purposes: + Routes - Destination SIP/SIPS/TEL URI Egress and Ingress Routes - Relevant route names, identifiers, and services - Attributes affecting route selection + Targets - Individual, ranges, or groups of user-agent identifiers - Target aggregation entities (e.g. service areas) and target-to-aggregate associations + Treatment Profiles - Priority - Location The mechanism(s) chosen should be extensible, in case additional criteria are deemed necessary to achieve the goals of the WG in the future. Penn Pfautz AT&T National Access Management +1-732-420-4962 _______________________________________________ PEPPERMINT mailing list PEPPERMINT@ietf.org https://www.ietf.org/mailman/listinfo/peppermint Return-Path: X-Original-To: peppermint-archive@optimus.ietf.org Delivered-To: ietfarch-peppermint-archive@core3.amsl.com Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E518F3A6C47; Thu, 24 Apr 2008 08:41:52 -0700 (PDT) X-Original-To: peppermint@core3.amsl.com Delivered-To: peppermint@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 91EE53A67A8 for ; Thu, 24 Apr 2008 08:41:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id QEwy5i4nbK49 for ; Thu, 24 Apr 2008 08:41:50 -0700 (PDT) Received: from dnsmx1pya.telcordia.com (dnsmx1pya.telcordia.com [128.96.20.31]) by core3.amsl.com (Postfix) with ESMTP id 2F01A3A68B8 for ; Thu, 24 Apr 2008 08:41:48 -0700 (PDT) Received: from rrc-dte-ieg01.cc.telcordia.com (rrc-dte-ieg01.cc.telcordia.com [128.96.20.22]) by dnsmx1pya.telcordia.com (8.11.7+Sun/8.9.3) with SMTP id m3OFfn802287; Thu, 24 Apr 2008 11:41:49 -0400 (EDT) Received: from rrc-dte-exbh02.dte.telcordia.com ([128.96.109.16]) by rrc-dte-ieg01.cc.telcordia.com (SMSSMTP 4.1.9.35) with SMTP id M2008042411414621676 ; Thu, 24 Apr 2008 11:41:46 -0400 Received: from rrc-dte-exs02.dte.telcordia.com ([128.96.109.15]) by rrc-dte-exbh02.dte.telcordia.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 24 Apr 2008 11:41:47 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Thu, 24 Apr 2008 11:41:45 -0400 Message-ID: <71A631B65B636B4D878D4CAD5BB68DD6107FFA38@rrc-dte-exs02.dte.telcordia.com> In-Reply-To: <0e3001c8a617$c151eed0$43f5cc70$@us> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [PEPPERMINT] DRINKS PROPOSED Charter ..comments please. Thread-Index: Acild5bQIMI2yamUS/eNn2gBoulzzQAEsfqAAAwJVRAAEfJPwAAFPVwwAAJ/GDA= References: <125b01c89fe6$14f823c0$3ee86b40$@us><20080419210654.GA30568@nic.at><20080420211101.GA32096@nic.at><1a6601c8a3dd$49ca8c50$dd5fa4f0$@us><20080422144452.GA582@nic.at><14b501c8a495$758aeb60$60a0c220$@us><160DE07A1C4F8E4AA2715DEC577DA49193654F@srvxchg3.cablelabs.com><154801c8a49b$22fbc2b0$68f34810$@us><160DE07A1C4F8E4AA2715DEC577DA491936564@srvxchg3.cablelabs.com><092B2658AAB56A4D80836399A4C4703104526DBE@ASHEVS002.mcilink.com><160DE07A1C4F8E4AA2715DEC577DA491936566@srvxchg3.cablelabs.com><092B2658AAB56A4D80836399A4C4703104526E1F@ASHEVS002.mcilink.com><160DE07A1C4F8E4AA2715DEC577DA491936569@srvxchg3.cablelabs.com><092B2658AAB56A4D80836399A4C4703104527139@ASHEVS002.mcilink.com><059501c8a58b$e4899c40$ad9cd4c0$@us><34DA635B184A644DA4588E260EC0A25A129FD159@ACCLUST02EVS1.ugd.att.com> <0e3001c8a617$c151eed0$43f5cc70$@us> From: "Guyton, Deborah A" To: "Richard Shockey" , "PFAUTZ, PENN L, ATTCORP" , "Hadriel Kaplan" , "Dwight, Timothy M \(Tim\)" , "Daryl Malas" , "Otmar Lendl" , X-OriginalArrivalTime: 24 Apr 2008 15:41:47.0476 (UTC) FILETIME=[B4A2D140:01C8A621] Subject: Re: [PEPPERMINT] DRINKS PROPOSED Charter ..comments please. X-BeenThere: peppermint@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Provisioning Extensions in Peering Registries for Multimedia INTerconnection List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: peppermint-bounces@ietf.org Errors-To: peppermint-bounces@ietf.org I believe this provides a description of data or data concepts at a reasonable level to bound the charter. Debbie Guyton -----Original Message----- From: peppermint-bounces@ietf.org [mailto:peppermint-bounces@ietf.org] On Behalf Of Richard Shockey Sent: Thursday, April 24, 2008 10:31 AM To: 'PFAUTZ, PENN L, ATTCORP'; 'Hadriel Kaplan'; 'Dwight, Timothy M (Tim)'; 'Daryl Malas'; 'Otmar Lendl'; peppermint@ietf.org Subject: Re: [PEPPERMINT] DRINKS PROPOSED Charter ..comments please. I think we are all talking past each other here .. this is a charter. This is about what we might do not what we will do.. This is a bounding excersise. What I have now is ************** More specifically, DRINKS will provide details of how Session Establishment Data (SED) is collected, what comprises SED, how SED should be used to properly identify an optimal path to a destination SIP user agent (UA), and the secure manners in which SED and the SIP session data is exchanged between the peering functions. Typical SED data types might include: + Routes - Destination SIP/SIPS/TEL URI Egress and Ingress Routes - Relevant route names, identifiers, and services - NAPTR context and associations - PSTN database information + Service Areas - Individual, ranges, or groups of ENUMservice identifiers - Route associations + Treatment Profiles - Priority - Location Potential SED Data types not in scope will be session rating or other billing or pricing information between SSP's ************** > -----Original Message----- > From: PFAUTZ, PENN L, ATTCORP [mailto:ppfautz@att.com] > Sent: Thursday, April 24, 2008 8:02 AM > To: Hadriel Kaplan; Richard Shockey; Dwight, Timothy M (Tim); Daryl > Malas; Otmar Lendl; peppermint@ietf.org > Subject: RE: [PEPPERMINT] DRINKS PROPOSED Charter ..comments please. > > Putting the Service Area concept in the charter still gives me > heartburn. If Drinks is about more than ESPP that doesn't make sense. > If > you want to introduce the concept of some aggregate later, after > robust > discussion, fine. Not all of us are ready to drink the kool-aid. > > > Penn Pfautz > > -----Original Message----- > From: peppermint-bounces@ietf.org [mailto:peppermint-bounces@ietf.org] > On Behalf Of Hadriel Kaplan > Sent: Wednesday, April 23, 2008 11:45 PM > To: Richard Shockey; 'Dwight, Timothy M (Tim)'; 'Daryl Malas'; 'Otmar > Lendl'; peppermint@ietf.org > Subject: Re: [PEPPERMINT] DRINKS PROPOSED Charter ..comments please. > > > > -----Original Message----- > > From: Richard Shockey [mailto:richard@shockey.us] > > > > No one is proposing a solution. We are describing that we do not > propose > > exchanging data on Collateralized Debt Instruments and Mortgage > Interest > > Swaps among SSP's > > Sure, I'm all in favor of getting a charter approved post-haste. Even > if it means my ideas for "Mortgage Interest eXchanges" (MIX) will have > to wait for a charter update. (too bad too, 'cause a draft-drinks-mix > would have been a recipe for success in my opinion) > > But seriously, how "detailed" do we need to be in the charter > regarding > this data? I think Daryl's proposed data with some minor nits is > broad > enough not to cause heartburn later, while not letting us get drunk in > the possibilities. :) > > How about this: > > [begin] > The scope will be limited to defining the following criteria necessary > for a SSP to respond with the necessary Session Establishment Data > (SED) > for both internal and external purposes: > > + Routes > - Destination SIP/SIPS/TEL URI Egress and Ingress > Routes > - Relevant route names, identifiers, and services > - Attributes affecting route selection > + Service Areas > - Individual, ranges, or groups of user-agent > identifiers > - Route-to-service-area associations > + Treatment Profiles > - Priority > - Location > > The mechanism(s) chosen should be extensible, in case additional > criteria are deemed necessary to achieve the goals of the WG in the > future. > [end] > > -hadriel > _______________________________________________ > 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 CF3743A6BA0; Thu, 24 Apr 2008 08:22:56 -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 B3F123A6BA0 for ; Thu, 24 Apr 2008 08:22:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.412 X-Spam-Level: X-Spam-Status: No, score=-3.412 tagged_above=-999 required=5 tests=[AWL=0.188, 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 DTGgbMhytlWe for ; Thu, 24 Apr 2008 08:22:54 -0700 (PDT) Received: from mail.songbird.com (mail.songbird.com [208.184.79.10]) by core3.amsl.com (Postfix) with ESMTP id 9036E3A6B13 for ; Thu, 24 Apr 2008 08:22:54 -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 m3OFLVTg006926 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Thu, 24 Apr 2008 08:21:32 -0700 From: "Richard Shockey" To: "'Dwight, Timothy M \(Tim\)'" , "'PFAUTZ, PENN L, ATTCORP'" , "'Hadriel Kaplan'" , "'Daryl Malas'" , "'Otmar Lendl'" , References: <125b01c89fe6$14f823c0$3ee86b40$@us> <20080419210654.GA30568@nic.at> <20080420211101.GA32096@nic.at> <1a6601c8a3dd$49ca8c50$dd5fa4f0$@us> <20080422144452.GA582@nic.at> <14b501c8a495$758aeb60$60a0c220$@us> <160DE07A1C4F8E4AA2715DEC577DA49193654F@srvxchg3.cablelabs.com> <154801c8a49b$22fbc2b0$68f34810$@us> <160DE07A1C4F8E4AA2715DEC577DA491936564@srvxchg3.cablelabs.com> <092B2658AAB56A4D80836399A4C4703104526DBE@ASHEVS002.mcilink.com> <160DE07A1C4F8E4AA2715DEC577DA491936566@srvxchg3.cablelabs.com> <092B2658AAB56A4D80836399A4C4703104526E1F@ASHEVS002.mcilink.com> <160DE07A1C4F8E4AA2715DEC577DA491936569@srvxchg3.cablelabs.com> <092B2658AAB56A4D80836399A4C4703104527139@ASHEVS002.mcilink.com> <"34DA635 B184A644DA4588! E260EC0A25A129FD159"@AC CLUST02EVS1.ugd.att.com> <0e3001c8a617$c151eed0$43f5cc70$@us> <092B2658AAB56A4D80836399A4C47031037DD575@ASHEVS002.mcilink.com> In-Reply-To: <092B2658AAB56A4D80836399A4C47031037DD575@ASHEVS002.mcilink.com> Date: Thu, 24 Apr 2008 11:22:19 -0400 Message-ID: <100c01c8a61e$fdddf270$f999d750$@us> MIME-Version: 1.0 X-Mailer: Microsoft Office Outlook 12.0 thread-index: Acild5bQIMI2yamUS/eNn2gBoulzzQAEsfqAAAwJVRAAEfJPwAAFPVwwAABjOUAAATE9EA== Content-Language: en-us X-SongbirdInformation: support@songbird.com for more information X-Songbird: Clean X-Songbird-From: richard@shockey.us Subject: Re: [PEPPERMINT] DRINKS PROPOSED Charter ..comments please. 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, > > It is precisely because this is a bounding exercise, and specifically > a > bound placed on potential solutions, that this is a concern. We are > trying to define the solution before defining the problem. No there is no definition of the solution here. Remember that is the IETF. It is a requirement of new WG's that the scope of the proposed work be properly bounded so that WG do not go "wandering off the reservation". It not about defining the solution as much as defining what the WG will NOT do. > > Basically I find this debate contradictory. If the text starting > "Typical SED data types might include..." below is truly meant only as > examples that might or might not be part of the eventual solution > developed by the WG, then it doesn't bound squat. I beg to differ. In the context of IETF WG charters this is perfectly acceptable problem scoping. It does not propose a data model. So since its > inclusion is controversial, Remember we only deal with "rough consensus" here. and it doesn't accomplish anything, let's > delete it and declare victory. If on the other hand its intent is to > function on a bound on potential solutions, then it's disingenuous to > refer to it as "Typical" and say it "might" include... more honest > words > would be something like "the WG will be strongly incented to use the > following data model...". To which I would object. Well what is your proposed WG scope text? Again (with some frustration) ... if anyone has a problem with the current text then they had better come up with what they propose at the alternative. I'm simply going to ignore any more objections that do not propose real alternatives to the text. > > Tim > > > > -----Original Message----- > > From: Richard Shockey [mailto:richard@shockey.us] > > Sent: Thursday, April 24, 2008 9:31 AM > > To: 'PFAUTZ, PENN L, ATTCORP'; 'Hadriel Kaplan'; Dwight, > > Timothy M (Tim); 'Daryl Malas'; 'Otmar Lendl'; peppermint@ietf.org > > Subject: RE: [PEPPERMINT] DRINKS PROPOSED Charter ..comments please. > > > > I think we are all talking past each other here .. this is a > > charter. This > > is about what we might do not what we will do.. This is a bounding > > excersise. > > > > What I have now is > > > > ************** > > > > More specifically, DRINKS will provide details of how Session > > Establishment > > Data (SED) is collected, what comprises SED, how SED should be used > to > > properly identify an optimal path to a destination SIP user > > agent (UA), and > > the secure manners in which SED and the SIP session data is > exchanged > > between the peering functions. > > > > > > Typical SED data types might include: > > > > + Routes > > - Destination SIP/SIPS/TEL URI Egress and Ingress Routes > > - Relevant route names, identifiers, and services > > - NAPTR context and associations > > - PSTN database information > > > > + Service Areas > > - Individual, ranges, or groups of ENUMservice identifiers > > - Route associations > > > > + Treatment Profiles > > - Priority > > - Location > > > > Potential SED Data types not in scope will be session rating or > other > > billing or pricing information between SSP's > > > > ************** > > > > > > > > > > > > > -----Original Message----- > > > From: PFAUTZ, PENN L, ATTCORP [mailto:ppfautz@att.com] > > > Sent: Thursday, April 24, 2008 8:02 AM > > > To: Hadriel Kaplan; Richard Shockey; Dwight, Timothy M (Tim); > Daryl > > > Malas; Otmar Lendl; peppermint@ietf.org > > > Subject: RE: [PEPPERMINT] DRINKS PROPOSED Charter > > ..comments please. > > > > > > Putting the Service Area concept in the charter still gives me > > > heartburn. If Drinks is about more than ESPP that doesn't > > make sense. > > > If > > > you want to introduce the concept of some aggregate later, after > > > robust > > > discussion, fine. Not all of us are ready to drink the kool-aid. > > > > > > > > > Penn Pfautz > > > > > > -----Original Message----- > > > From: peppermint-bounces@ietf.org > > [mailto:peppermint-bounces@ietf.org] > > > On Behalf Of Hadriel Kaplan > > > Sent: Wednesday, April 23, 2008 11:45 PM > > > To: Richard Shockey; 'Dwight, Timothy M (Tim)'; 'Daryl > > Malas'; 'Otmar > > > Lendl'; peppermint@ietf.org > > > Subject: Re: [PEPPERMINT] DRINKS PROPOSED Charter > > ..comments please. > > > > > > > > > > -----Original Message----- > > > > From: Richard Shockey [mailto:richard@shockey.us] > > > > > > > > No one is proposing a solution. We are describing that we do > not > > > propose > > > > exchanging data on Collateralized Debt Instruments and Mortgage > > > Interest > > > > Swaps among SSP's > > > > > > Sure, I'm all in favor of getting a charter approved > > post-haste. Even > > > if it means my ideas for "Mortgage Interest eXchanges" > > (MIX) will have > > > to wait for a charter update. (too bad too, 'cause a > > draft-drinks-mix > > > would have been a recipe for success in my opinion) > > > > > > But seriously, how "detailed" do we need to be in the charter > > > regarding > > > this data? I think Daryl's proposed data with some minor nits is > > > broad > > > enough not to cause heartburn later, while not letting us > > get drunk in > > > the possibilities. :) > > > > > > How about this: > > > > > > [begin] > > > The scope will be limited to defining the following > > criteria necessary > > > for a SSP to respond with the necessary Session Establishment > Data > > > (SED) > > > for both internal and external purposes: > > > > > > + Routes > > > - Destination SIP/SIPS/TEL URI Egress and Ingress > > > Routes > > > - Relevant route names, identifiers, and services > > > - Attributes affecting route selection > > > + Service Areas > > > - Individual, ranges, or groups of user-agent > > > identifiers > > > - Route-to-service-area associations > > > + Treatment Profiles > > > - Priority > > > - Location > > > > > > The mechanism(s) chosen should be extensible, in case additional > > > criteria are deemed necessary to achieve the goals of the WG in > the > > > future. > > > [end] > > > > > > -hadriel > > > _______________________________________________ > > > 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 2CADD3A6859; Thu, 24 Apr 2008 07:52:27 -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 812963A6C8D for ; Thu, 24 Apr 2008 07:52:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ImRgnuZ7hnSp for ; Thu, 24 Apr 2008 07:52:20 -0700 (PDT) Received: from omzesmtp02a.verizonbusiness.com (omzesmtp02a.verizonbusiness.com [199.249.25.198]) by core3.amsl.com (Postfix) with ESMTP id AA63F3A6859 for ; Thu, 24 Apr 2008 07:52:20 -0700 (PDT) Received: from pmismtp05.wcomnet.com ([166.37.158.165]) by firewall.verizonbusiness.com (Sun Java(tm) System Messaging Server 6.3-5.02 (built Oct 12 2007; 32bit)) with ESMTP id <0JZU0013Y3YJFJ00@firewall.verizonbusiness.com> for peppermint@ietf.org; Thu, 24 Apr 2008 14:52:09 +0000 (GMT) Received: from pmismtp05.wcomnet.com ([127.0.0.1]) by pmismtp05.mcilink.com (iPlanet Messaging Server 5.2 HotFix 2.08 (built Sep 22 2005)) with SMTP id <0JZU007313YSCB@pmismtp05.mcilink.com> for peppermint@ietf.org; Thu, 24 Apr 2008 14:52:05 +0000 (GMT) Received: from ASHSRV140.mcilink.com ([153.39.68.166]) by pmismtp05.mcilink.com (iPlanet Messaging Server 5.2 HotFix 2.08 (built Sep 22 2005)) with ESMTP id <0JZU0067W3YGX5@pmismtp05.mcilink.com> for peppermint@ietf.org; Thu, 24 Apr 2008 14:52:02 +0000 (GMT) Received: from ASHEVS002.mcilink.com ([153.39.71.1]) by ASHSRV140.mcilink.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 24 Apr 2008 14:51:55 +0000 Date: Thu, 24 Apr 2008 14:51:47 +0000 From: "Dwight, Timothy M (Tim)" In-reply-to: <0e3001c8a617$c151eed0$43f5cc70$@us> To: Richard Shockey , "PFAUTZ, PENN L, ATTCORP" , Hadriel Kaplan , Daryl Malas , Otmar Lendl , peppermint@ietf.org Message-id: <092B2658AAB56A4D80836399A4C47031037DD575@ASHEVS002.mcilink.com> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message Thread-topic: [PEPPERMINT] DRINKS PROPOSED Charter ..comments please. Thread-index: Acild5bQIMI2yamUS/eNn2gBoulzzQAEsfqAAAwJVRAAEfJPwAAFPVwwAABjOUA= X-MS-Has-Attach: X-MS-TNEF-Correlator: References: <125b01c89fe6$14f823c0$3ee86b40$@us> <20080419210654.GA30568@nic.at> <20080420211101.GA32096@nic.at> <1a6601c8a3dd$49ca8c50$dd5fa4f0$@us> <20080422144452.GA582@nic.at> <14b501c8a495$758aeb60$60a0c220$@us> <160DE07A1C4F8E4AA2715DEC577DA49193654F@srvxchg3.cablelabs.com> <154801c8a49b$22fbc2b0$68f34810$@us> <160DE07A1C4F8E4AA2715DEC577DA491936564@srvxchg3.cablelabs.com> <092B2658AAB56A4D80836399A4C4703104526DBE@ASHEVS002.mcilink.com> <160DE07A1C4F8E4AA2715DEC577DA491936566@srvxchg3.cablelabs.com> <092B2658AAB56A4D80836399A4C4703104526E1F@ASHEVS002.mcilink.com> <160DE07A1C4F8E4AA2715DEC577DA491936569@srvxchg3.cablelabs.com> <092B2658AAB56A4D80836399A4C4703104527139@ASHEVS002.mcilink.com> <"34DA635 B184A644DA4588E260EC0A25A129FD159"@ACCLUST02EVS1.ugd.att.com> <0e3001c8a617$c151eed0$43f5cc70$@us> X-OriginalArrivalTime: 24 Apr 2008 14:51:55.0281 (UTC) FILETIME=[BD261810:01C8A61A] Subject: Re: [PEPPERMINT] DRINKS PROPOSED Charter ..comments please. 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, It is precisely because this is a bounding exercise, and specifically a bound placed on potential solutions, that this is a concern. We are trying to define the solution before defining the problem. Basically I find this debate contradictory. If the text starting "Typical SED data types might include..." below is truly meant only as examples that might or might not be part of the eventual solution developed by the WG, then it doesn't bound squat. So since its inclusion is controversial, and it doesn't accomplish anything, let's delete it and declare victory. If on the other hand its intent is to function on a bound on potential solutions, then it's disingenuous to refer to it as "Typical" and say it "might" include... more honest words would be something like "the WG will be strongly incented to use the following data model...". To which I would object. Tim > -----Original Message----- > From: Richard Shockey [mailto:richard@shockey.us] > Sent: Thursday, April 24, 2008 9:31 AM > To: 'PFAUTZ, PENN L, ATTCORP'; 'Hadriel Kaplan'; Dwight, > Timothy M (Tim); 'Daryl Malas'; 'Otmar Lendl'; peppermint@ietf.org > Subject: RE: [PEPPERMINT] DRINKS PROPOSED Charter ..comments please. > > I think we are all talking past each other here .. this is a > charter. This > is about what we might do not what we will do.. This is a bounding > excersise. > > What I have now is > > ************** > > More specifically, DRINKS will provide details of how Session > Establishment > Data (SED) is collected, what comprises SED, how SED should be used to > properly identify an optimal path to a destination SIP user > agent (UA), and > the secure manners in which SED and the SIP session data is exchanged > between the peering functions. > > > Typical SED data types might include: > > + Routes > - Destination SIP/SIPS/TEL URI Egress and Ingress Routes > - Relevant route names, identifiers, and services > - NAPTR context and associations > - PSTN database information > > + Service Areas > - Individual, ranges, or groups of ENUMservice identifiers > - Route associations > > + Treatment Profiles > - Priority > - Location > > Potential SED Data types not in scope will be session rating or other > billing or pricing information between SSP's > > ************** > > > > > > > -----Original Message----- > > From: PFAUTZ, PENN L, ATTCORP [mailto:ppfautz@att.com] > > Sent: Thursday, April 24, 2008 8:02 AM > > To: Hadriel Kaplan; Richard Shockey; Dwight, Timothy M (Tim); Daryl > > Malas; Otmar Lendl; peppermint@ietf.org > > Subject: RE: [PEPPERMINT] DRINKS PROPOSED Charter > ..comments please. > > > > Putting the Service Area concept in the charter still gives me > > heartburn. If Drinks is about more than ESPP that doesn't > make sense. > > If > > you want to introduce the concept of some aggregate later, after > > robust > > discussion, fine. Not all of us are ready to drink the kool-aid. > > > > > > Penn Pfautz > > > > -----Original Message----- > > From: peppermint-bounces@ietf.org > [mailto:peppermint-bounces@ietf.org] > > On Behalf Of Hadriel Kaplan > > Sent: Wednesday, April 23, 2008 11:45 PM > > To: Richard Shockey; 'Dwight, Timothy M (Tim)'; 'Daryl > Malas'; 'Otmar > > Lendl'; peppermint@ietf.org > > Subject: Re: [PEPPERMINT] DRINKS PROPOSED Charter > ..comments please. > > > > > > > -----Original Message----- > > > From: Richard Shockey [mailto:richard@shockey.us] > > > > > > No one is proposing a solution. We are describing that we do not > > propose > > > exchanging data on Collateralized Debt Instruments and Mortgage > > Interest > > > Swaps among SSP's > > > > Sure, I'm all in favor of getting a charter approved > post-haste. Even > > if it means my ideas for "Mortgage Interest eXchanges" > (MIX) will have > > to wait for a charter update. (too bad too, 'cause a > draft-drinks-mix > > would have been a recipe for success in my opinion) > > > > But seriously, how "detailed" do we need to be in the charter > > regarding > > this data? I think Daryl's proposed data with some minor nits is > > broad > > enough not to cause heartburn later, while not letting us > get drunk in > > the possibilities. :) > > > > How about this: > > > > [begin] > > The scope will be limited to defining the following > criteria necessary > > for a SSP to respond with the necessary Session Establishment Data > > (SED) > > for both internal and external purposes: > > > > + Routes > > - Destination SIP/SIPS/TEL URI Egress and Ingress > > Routes > > - Relevant route names, identifiers, and services > > - Attributes affecting route selection > > + Service Areas > > - Individual, ranges, or groups of user-agent > > identifiers > > - Route-to-service-area associations > > + Treatment Profiles > > - Priority > > - Location > > > > The mechanism(s) chosen should be extensible, in case additional > > criteria are deemed necessary to achieve the goals of the WG in the > > future. > > [end] > > > > -hadriel > > _______________________________________________ > > 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 B134A3A6A18; Thu, 24 Apr 2008 07:44:18 -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 377143A694B for ; Thu, 24 Apr 2008 07:44:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.313 X-Spam-Level: X-Spam-Status: No, score=-0.313 tagged_above=-999 required=5 tests=[AWL=0.150, BAYES_00=-2.599, HELO_EQ_MODEMCABLE=0.768, HOST_EQ_MODEMCABLE=1.368] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id A8vU6UNsLCYB for ; Thu, 24 Apr 2008 07:44:15 -0700 (PDT) Received: from ondar.cablelabs.com (ondar.cablelabs.com [192.160.73.61]) by core3.amsl.com (Postfix) with ESMTP id 7C4233A6A18 for ; Thu, 24 Apr 2008 07:44:15 -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 m3OEiHxU029486; Thu, 24 Apr 2008 08:44:17 -0600 Received: from srvxchg3.cablelabs.com (10.5.0.25) by kyzyl.cablelabs.com (F-Secure/fsigk_smtp/511/kyzyl.cablelabs.com); Thu, 24 Apr 2008 08:44:17 -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: Thu, 24 Apr 2008 08:44:17 -0600 Message-ID: <160DE07A1C4F8E4AA2715DEC577DA491936574@srvxchg3.cablelabs.com> In-Reply-To: <0e3001c8a617$c151eed0$43f5cc70$@us> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [PEPPERMINT] DRINKS PROPOSED Charter ..comments please. Thread-Index: Acild5bQIMI2yamUS/eNn2gBoulzzQAEsfqAAAwJVRAAEfJPwAAFPVwwAAB/vOA= References: <125b01c89fe6$14f823c0$3ee86b40$@us><20080419210654.GA30568@nic.at><20080420211101.GA32096@nic.at> <1a6601c8a3dd$49ca8c50$dd5fa4f0$@us><20080422144452.GA582@nic.at><14b501c8a495$758aeb60$60a0c220$@us><160DE07A1C4F8E4AA2715DEC577DA49193654F@srvxchg3.cablelabs.com><154801c8a49b$22fbc2b0$68f34810$@us><160DE07A1C4F8E4AA2715DEC577DA491936564@srvxchg3.cablelabs.com><092B2658AAB56A4D80836399A4C4703104526DBE@ASHEVS002.mcilink.com><160DE07A1C4F8E4AA2715DEC577DA491936566@srvxchg3.cablelabs.com><092B2658AAB56A4D80836399A4C4703104526E1F@ASHEVS002.mcilink.com><160DE07A1C4F8E4AA2715DEC577DA491936569@srvxchg3.cablelabs.com><092B2658AAB56A4D80836399A4C4703104527139@ASHEVS002.mcilink.com><059501c8a58b$e4899c40$ad9cd4c0$@us> <34DA635B184A644DA4588E260EC0A25A129FD159@ACCLUST02EVS1.ugd.att.com> <0e3001c8a617$c151eed0$43f5cc70$@us> From: "Daryl Malas" To: "Richard Shockey" , "PFAUTZ, PENN L, ATTCORP" , "Hadriel Kaplan" , "Dwight, Timothy M (Tim)" , "Otmar Lendl" , X-Approved: ondar Subject: Re: [PEPPERMINT] DRINKS PROPOSED Charter ..comments please. 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 If there is a problem with the term "Service Areas", then change it to something else. I am not hung up on that term. It just seems to make logical sense in my mind. Call it "Non-descript pools of logical identifiers that may provide value to a relative locale". :-) IMO, I think the addition below is clear and provides relevant bounds with which to work in. --Daryl -----Original Message----- From: Richard Shockey [mailto:richard@shockey.us] Sent: Thursday, April 24, 2008 8:31 AM To: 'PFAUTZ, PENN L, ATTCORP'; 'Hadriel Kaplan'; 'Dwight, Timothy M (Tim)'; Daryl Malas; 'Otmar Lendl'; peppermint@ietf.org Subject: RE: [PEPPERMINT] DRINKS PROPOSED Charter ..comments please. I think we are all talking past each other here .. this is a charter. This is about what we might do not what we will do.. This is a bounding excersise. What I have now is ************** More specifically, DRINKS will provide details of how Session Establishment Data (SED) is collected, what comprises SED, how SED should be used to properly identify an optimal path to a destination SIP user agent (UA), and the secure manners in which SED and the SIP session data is exchanged between the peering functions. Typical SED data types might include: + Routes - Destination SIP/SIPS/TEL URI Egress and Ingress Routes - Relevant route names, identifiers, and services - NAPTR context and associations - PSTN database information + Service Areas - Individual, ranges, or groups of ENUMservice identifiers - Route associations + Treatment Profiles - Priority - Location Potential SED Data types not in scope will be session rating or other billing or pricing information between SSP's ************** > -----Original Message----- > From: PFAUTZ, PENN L, ATTCORP [mailto:ppfautz@att.com] > Sent: Thursday, April 24, 2008 8:02 AM > To: Hadriel Kaplan; Richard Shockey; Dwight, Timothy M (Tim); Daryl > Malas; Otmar Lendl; peppermint@ietf.org > Subject: RE: [PEPPERMINT] DRINKS PROPOSED Charter ..comments please. > > Putting the Service Area concept in the charter still gives me > heartburn. If Drinks is about more than ESPP that doesn't make sense. > If > you want to introduce the concept of some aggregate later, after > robust discussion, fine. Not all of us are ready to drink the > kool-aid. > > > Penn Pfautz > > -----Original Message----- > From: peppermint-bounces@ietf.org > [mailto:peppermint-bounces@ietf.org] > On Behalf Of Hadriel Kaplan > Sent: Wednesday, April 23, 2008 11:45 PM > To: Richard Shockey; 'Dwight, Timothy M (Tim)'; 'Daryl Malas'; 'Otmar > Lendl'; peppermint@ietf.org > Subject: Re: [PEPPERMINT] DRINKS PROPOSED Charter ..comments please. > > > > -----Original Message----- > > From: Richard Shockey [mailto:richard@shockey.us] > > No one is > proposing a solution. We are describing that we do not propose > > exchanging data on Collateralized Debt Instruments and Mortgage > Interest > Swaps among SSP's > > Sure, I'm all in favor of getting a charter approved post-haste. > Even if it means my ideas for "Mortgage Interest eXchanges" (MIX) > will have to wait for a charter update. (too bad too, 'cause a > draft-drinks-mix would have been a recipe for success in my opinion) > > But seriously, how "detailed" do we need to be in the charter > regarding this data? I think Daryl's proposed data with some minor > nits is broad enough not to cause heartburn later, while not letting > us get drunk in the possibilities. :) > > How about this: > > [begin] > The scope will be limited to defining the following criteria > necessary for a SSP to respond with the necessary Session > Establishment Data > (SED) > for both internal and external purposes: > > + Routes > - Destination SIP/SIPS/TEL URI Egress and Ingress > Routes > - Relevant route names, identifiers, and services > - Attributes affecting route selection > + Service Areas > - Individual, ranges, or groups of user-agent > identifiers > - Route-to-service-area associations > + Treatment Profiles > - Priority > - Location > > The mechanism(s) chosen should be extensible, in case additional > criteria are deemed necessary to achieve the goals of the WG in the > future. > [end] > > -hadriel > _______________________________________________ > 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 8D6103A6CA8; Thu, 24 Apr 2008 07:31:56 -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 DB8673A69C7 for ; Thu, 24 Apr 2008 07:31:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.385 X-Spam-Level: X-Spam-Status: No, score=-3.385 tagged_above=-999 required=5 tests=[AWL=0.214, 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 kYNsKnn03Q8H for ; Thu, 24 Apr 2008 07:31:46 -0700 (PDT) Received: from mail.songbird.com (mail.songbird.com [208.184.79.10]) by core3.amsl.com (Postfix) with ESMTP id C0B4A3A67A8 for ; Thu, 24 Apr 2008 07:30:48 -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 m3OEThnn000881 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Thu, 24 Apr 2008 07:29:44 -0700 From: "Richard Shockey" To: "'PFAUTZ, PENN L, ATTCORP'" , "'Hadriel Kaplan'" , "'Dwight, Timothy M \(Tim\)'" , "'Daryl Malas'" , "'Otmar Lendl'" , References: <125b01c89fe6$14f823c0$3ee86b40$@us><20080419210654.GA30568@nic.at><20080420211101.GA32096@nic.at> <1a6601c8a3dd$49ca8c50$dd5fa4f0$@us><20080422144452.GA582@nic.at><14b501c8a495$758aeb60$60a0c220$@us><160DE07A1C4F8E4AA2715DEC577DA49193654F@srvxchg3.cablelabs.com><154801c8a49b$22fbc2b0$68f34810$@us><160DE07A1C4F8E4AA2715DEC577DA491936564@srvxchg3.cablelabs.com><092B2658AAB56A4D80836399A4C4703104526DBE@ASHEVS002.mcilink.com><160DE07A1C4F8E4AA2715DEC577DA491936566@srvxchg3.cablelabs.com><092B2658AAB56A4D80836399A4C4703104526E1F@ASHEVS002.mcilink.com><160DE07A1C4F8E4AA2715DEC577DA491936569@srvxchg3.cablelabs.com><092B2658AAB56A4D80836399A4C4703104527139@ASHEVS002.mcilink.com><059501c8a58b$e4899c40$ad9cd4c0$@us> <34DA635B184A644DA4588E260EC0A25A129FD159@ACCLUST02EVS1.ugd.att.com> In-Reply-To: <34DA635B184A644DA4588E260EC0A25A129FD159@ACCLUST02EVS1.ugd.att.com> Date: Thu, 24 Apr 2008 10:30:31 -0400 Message-ID: <0e3001c8a617$c151eed0$43f5cc70$@us> MIME-Version: 1.0 X-Mailer: Microsoft Office Outlook 12.0 thread-index: Acild5bQIMI2yamUS/eNn2gBoulzzQAEsfqAAAwJVRAAEfJPwAAFPVww Content-Language: en-us X-SongbirdInformation: support@songbird.com for more information X-Songbird: Clean X-Songbird-From: richard@shockey.us Subject: Re: [PEPPERMINT] DRINKS PROPOSED Charter ..comments please. 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 think we are all talking past each other here .. this is a charter. This is about what we might do not what we will do.. This is a bounding excersise. What I have now is ************** More specifically, DRINKS will provide details of how Session Establishment Data (SED) is collected, what comprises SED, how SED should be used to properly identify an optimal path to a destination SIP user agent (UA), and the secure manners in which SED and the SIP session data is exchanged between the peering functions. Typical SED data types might include: + Routes - Destination SIP/SIPS/TEL URI Egress and Ingress Routes - Relevant route names, identifiers, and services - NAPTR context and associations - PSTN database information + Service Areas - Individual, ranges, or groups of ENUMservice identifiers - Route associations + Treatment Profiles - Priority - Location Potential SED Data types not in scope will be session rating or other billing or pricing information between SSP's ************** > -----Original Message----- > From: PFAUTZ, PENN L, ATTCORP [mailto:ppfautz@att.com] > Sent: Thursday, April 24, 2008 8:02 AM > To: Hadriel Kaplan; Richard Shockey; Dwight, Timothy M (Tim); Daryl > Malas; Otmar Lendl; peppermint@ietf.org > Subject: RE: [PEPPERMINT] DRINKS PROPOSED Charter ..comments please. > > Putting the Service Area concept in the charter still gives me > heartburn. If Drinks is about more than ESPP that doesn't make sense. > If > you want to introduce the concept of some aggregate later, after > robust > discussion, fine. Not all of us are ready to drink the kool-aid. > > > Penn Pfautz > > -----Original Message----- > From: peppermint-bounces@ietf.org [mailto:peppermint-bounces@ietf.org] > On Behalf Of Hadriel Kaplan > Sent: Wednesday, April 23, 2008 11:45 PM > To: Richard Shockey; 'Dwight, Timothy M (Tim)'; 'Daryl Malas'; 'Otmar > Lendl'; peppermint@ietf.org > Subject: Re: [PEPPERMINT] DRINKS PROPOSED Charter ..comments please. > > > > -----Original Message----- > > From: Richard Shockey [mailto:richard@shockey.us] > > > > No one is proposing a solution. We are describing that we do not > propose > > exchanging data on Collateralized Debt Instruments and Mortgage > Interest > > Swaps among SSP's > > Sure, I'm all in favor of getting a charter approved post-haste. Even > if it means my ideas for "Mortgage Interest eXchanges" (MIX) will have > to wait for a charter update. (too bad too, 'cause a draft-drinks-mix > would have been a recipe for success in my opinion) > > But seriously, how "detailed" do we need to be in the charter > regarding > this data? I think Daryl's proposed data with some minor nits is > broad > enough not to cause heartburn later, while not letting us get drunk in > the possibilities. :) > > How about this: > > [begin] > The scope will be limited to defining the following criteria necessary > for a SSP to respond with the necessary Session Establishment Data > (SED) > for both internal and external purposes: > > + Routes > - Destination SIP/SIPS/TEL URI Egress and Ingress > Routes > - Relevant route names, identifiers, and services > - Attributes affecting route selection > + Service Areas > - Individual, ranges, or groups of user-agent > identifiers > - Route-to-service-area associations > + Treatment Profiles > - Priority > - Location > > The mechanism(s) chosen should be extensible, in case additional > criteria are deemed necessary to achieve the goals of the WG in the > future. > [end] > > -hadriel > _______________________________________________ > 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 C42393A6AC4; Thu, 24 Apr 2008 06:35:21 -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 0A55C3A6C7B for ; Thu, 24 Apr 2008 06:35:18 -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 nytuj-DvSNdy for ; Thu, 24 Apr 2008 06:35:12 -0700 (PDT) Received: from mail.songbird.com (mail.songbird.com [208.184.79.10]) by core3.amsl.com (Postfix) with ESMTP id 737973A6B5E for ; Thu, 24 Apr 2008 06:35:12 -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 m3ODY7xV017128 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Thu, 24 Apr 2008 06:34:09 -0700 From: "Richard Shockey" To: "'Hadriel Kaplan'" , "'Dwight, Timothy M \(Tim\)'" , "'Daryl Malas'" , "'Otmar Lendl'" , References: <125b01c89fe6$14f823c0$3ee86b40$@us> <20080419210654.GA30568@nic.at> <20080420211101.GA32096@nic.at> <1a6601c8a3dd$49ca8c50$dd5fa4f0$@us> <20080422144452.GA582@nic.at> <14b501c8a495$758aeb60$60a0c220$@us> <160DE07A1C4F8E4AA2715DEC577DA49193654F@srvxchg3.cablelabs.com> <154801c8a49b$22fbc2b0$68f34810$@us> <160DE07A1C4F8E4AA2715DEC577DA491936564@srvxchg3.cablelabs.com> <092B2658AAB56A4D80836399A4C4703104526DBE@ASHEVS002.mcilink.com> <160DE07A1C4F8E4AA2715DEC577DA491936566@srvxchg3.cablelabs.com> <092B2658AAB56A4D80836399A4C4703104526E1F@ASHEVS002.mcilink.com> <160DE07A1C4F8E4AA2715DEC577DA491936569@srvxchg3.cablelabs.com> <092B2658AAB56A4D80836399A4C4703104527139@ASHEVS002.mcilink.com> <059501c8a58b$e4899c40$a! d9cd4c0$@us> In-Reply-To: Date: Thu, 24 Apr 2008 09:34:55 -0400 Message-ID: <026401c8a60f$fd86a880$f893f980$@us> MIME-Version: 1.0 X-Mailer: Microsoft Office Outlook 12.0 thread-index: Acild5bQIMI2yamUS/eNn2gBoulzzQAEsfqAAAwJVRAAFUqZ4A== Content-Language: en-us X-SongbirdInformation: support@songbird.com for more information X-Songbird: Clean X-Songbird-From: richard@shockey.us Subject: Re: [PEPPERMINT] DRINKS PROPOSED Charter ..comments please. X-BeenThere: peppermint@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Provisioning Extensions in Peering Registries for Multimedia INTerconnection List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: peppermint-bounces@ietf.org Errors-To: peppermint-bounces@ietf.org > > > -----Original Message----- > > From: Richard Shockey [mailto:richard@shockey.us] > > > > No one is proposing a solution. We are describing that we do not > propose > > exchanging data on Collateralized Debt Instruments and Mortgage > Interest > > Swaps among SSP's > > Sure, I'm all in favor of getting a charter approved post-haste. Even > if it means my ideas for "Mortgage Interest eXchanges" (MIX) will have > to wait for a charter update. (too bad too, 'cause a draft-drinks-mix > would have been a recipe for success in my opinion) Good very good ... cant wait to see the draft .. > > But seriously, how "detailed" do we need to be in the charter > regarding this data? I think Daryl's proposed data with some minor > nits is broad enough not to cause heartburn later, while not letting > us get drunk in the possibilities. :) > > How about this: > > [begin] > The scope will be limited to defining the following criteria necessary > for a SSP to respond with the necessary Session Establishment Data > (SED) for both internal and external purposes: > > + Routes > - Destination SIP/SIPS/TEL URI Egress and Ingress > Routes > - Relevant route names, identifiers, and services > - Attributes affecting route selection > + Service Areas > - Individual, ranges, or groups of user-agent > identifiers > - Route-to-service-area associations > + Treatment Profiles > - Priority > - Location > > The mechanism(s) chosen should be extensible, in case additional > criteria are deemed necessary to achieve the goals of the WG in the > future. > [end] And I'll add the sentence on or rating and billing data. Works for me ... > > -hadriel _______________________________________________ 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 420C33A6B77; Thu, 24 Apr 2008 05:02: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 777C33A6B3E for ; Thu, 24 Apr 2008 05:02:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.599 X-Spam-Level: X-Spam-Status: No, score=-106.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zvi4cu7rcoWD for ; Thu, 24 Apr 2008 05:02:31 -0700 (PDT) Received: from mail120.messagelabs.com (mail120.messagelabs.com [216.82.250.83]) by core3.amsl.com (Postfix) with ESMTP id 4E97A3A68DF for ; Thu, 24 Apr 2008 05:02:31 -0700 (PDT) X-VirusChecked: Checked X-Env-Sender: ppfautz@att.com X-Msg-Ref: server-3.tower-120.messagelabs.com!1209038554!30827425!1 X-StarScan-Version: 5.5.12.14.2; banners=-,-,- X-Originating-IP: [144.160.20.54] Received: (qmail 6750 invoked from network); 24 Apr 2008 12:02:35 -0000 Received: from sbcsmtp7.sbc.com (HELO mlpi135.enaf.sfdc.sbc.com) (144.160.20.54) by server-3.tower-120.messagelabs.com with AES256-SHA encrypted SMTP; 24 Apr 2008 12:02:35 -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 m3OC2YqV029525; Thu, 24 Apr 2008 08:02:34 -0400 Received: from ACCLUST02EVS1.ugd.att.com (acst03.ugd.att.com [135.37.16.8]) by mlpi135.enaf.sfdc.sbc.com (8.14.0/8.14.0) with ESMTP id m3OC2VMc029509; Thu, 24 Apr 2008 08:02:31 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Thu, 24 Apr 2008 08:02:29 -0400 Message-ID: <34DA635B184A644DA4588E260EC0A25A129FD159@ACCLUST02EVS1.ugd.att.com> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [PEPPERMINT] DRINKS PROPOSED Charter ..comments please. Thread-Index: Acild5bQIMI2yamUS/eNn2gBoulzzQAEsfqAAAwJVRAAEfJPwA== References: <125b01c89fe6$14f823c0$3ee86b40$@us><20080419210654.GA30568@nic.at><20080420211101.GA32096@nic.at> <1a6601c8a3dd$49ca8c50$dd5fa4f0$@us><20080422144452.GA582@nic.at><14b501c8a495$758aeb60$60a0c220$@us><160DE07A1C4F8E4AA2715DEC577DA49193654F@srvxchg3.cablelabs.com><154801c8a49b$22fbc2b0$68f34810$@us><160DE07A1C4F8E4AA2715DEC577DA491936564@srvxchg3.cablelabs.com><092B2658AAB56A4D80836399A4C4703104526DBE@ASHEVS002.mcilink.com><160DE07A1C4F8E4AA2715DEC577DA491936566@srvxchg3.cablelabs.com><092B2658AAB56A4D80836399A4C4703104526E1F@ASHEVS002.mcilink.com><160DE07A1C4F8E4AA2715DEC577DA491936569@srvxchg3.cablelabs.com><092B2658AAB56A4D80836399A4C4703104527139@ASHEVS002.mcilink.com><059501c8a58b$e4899c40$ad9cd4c0$@us> From: "PFAUTZ, PENN L, ATTCORP" To: "Hadriel Kaplan" , "Richard Shockey" , "Dwight, Timothy M (Tim)" , "Daryl Malas" , "Otmar Lendl" , Subject: Re: [PEPPERMINT] DRINKS PROPOSED Charter ..comments please. 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 Putting the Service Area concept in the charter still gives me heartburn. If Drinks is about more than ESPP that doesn't make sense. If you want to introduce the concept of some aggregate later, after robust discussion, fine. Not all of us are ready to drink the kool-aid. Penn Pfautz -----Original Message----- From: peppermint-bounces@ietf.org [mailto:peppermint-bounces@ietf.org] On Behalf Of Hadriel Kaplan Sent: Wednesday, April 23, 2008 11:45 PM To: Richard Shockey; 'Dwight, Timothy M (Tim)'; 'Daryl Malas'; 'Otmar Lendl'; peppermint@ietf.org Subject: Re: [PEPPERMINT] DRINKS PROPOSED Charter ..comments please. > -----Original Message----- > From: Richard Shockey [mailto:richard@shockey.us] > > No one is proposing a solution. We are describing that we do not propose > exchanging data on Collateralized Debt Instruments and Mortgage Interest > Swaps among SSP's Sure, I'm all in favor of getting a charter approved post-haste. Even if it means my ideas for "Mortgage Interest eXchanges" (MIX) will have to wait for a charter update. (too bad too, 'cause a draft-drinks-mix would have been a recipe for success in my opinion) But seriously, how "detailed" do we need to be in the charter regarding this data? I think Daryl's proposed data with some minor nits is broad enough not to cause heartburn later, while not letting us get drunk in the possibilities. :) How about this: [begin] The scope will be limited to defining the following criteria necessary for a SSP to respond with the necessary Session Establishment Data (SED) for both internal and external purposes: + Routes - Destination SIP/SIPS/TEL URI Egress and Ingress Routes - Relevant route names, identifiers, and services - Attributes affecting route selection + Service Areas - Individual, ranges, or groups of user-agent identifiers - Route-to-service-area associations + Treatment Profiles - Priority - Location The mechanism(s) chosen should be extensible, in case additional criteria are deemed necessary to achieve the goals of the WG in the future. [end] -hadriel _______________________________________________ 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 F273F3A697C; Wed, 23 Apr 2008 21:17:08 -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 3D3AA3A697C for ; Wed, 23 Apr 2008 21:17:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.486 X-Spam-Level: X-Spam-Status: No, score=-1.486 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_DE=0.35, SARE_RECV_BEZEQINT_B=0.763] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Fc0YMT1n70-g for ; Wed, 23 Apr 2008 21:17:07 -0700 (PDT) Received: from moutng.kundenserver.de (moutng.kundenserver.de [212.227.126.183]) by core3.amsl.com (Postfix) with ESMTP id 246433A690B for ; Wed, 23 Apr 2008 21:17:07 -0700 (PDT) Received: from [10.0.1.198] (bzq-219-131-200.static.bezeqint.net [62.219.131.200]) by mrelayeu.kundenserver.de (node=mrelayeu8) with ESMTP (Nemesis) id 0ML31I-1JostC21uM-0003Ic; Thu, 24 Apr 2008 06:16:57 +0200 References: <125b01c89fe6$14f823c0$3ee86b40$@us> <20080419210654.GA30568@nic.at> <20080420211101.GA32096@nic.at> <1a6601c8a3dd$49ca8c50$dd5fa4f0$@us> <20080422144452.GA582@nic.at> <14b501c8a495$758aeb60$60a0c220$@us> <160DE07A1C4F8E4AA2715DEC577DA49193654F@srvxchg3.cablelabs.com> <154801c8a49b$22fbc2b0$68f34810$@us> <160DE07A1C4F8E4AA2715DEC577DA491936564@srvxchg3.cablelabs.com> <092B2658AAB56A4D80836399A4C4703104526DBE@ASHEVS002.mcilink.com> <160DE07A1C4F8E4AA2715DEC577DA491936566@srvxchg3.cablelabs.com> <092B2658AAB56A4D80836399A4C4703104526E1F@ASHEVS002.mcilink.com> <160DE07A1C4F8E4AA2715DEC577DA491936569@srvxchg3.cablelabs.com> <092B2658AAB56A4D80836399A4C4703104527139@ASHEVS002.mcilink.com> <059501c8a58b$e4899c40$ad 9cd4c0$@us> Message-Id: From: David Schwartz To: Hadriel Kaplan In-Reply-To: X-Mailer: iPhone Mail (3A109a) Mime-Version: 1.0 (iPhone Mail 3A109a) Date: Thu, 24 Apr 2008 07:16:47 +0300 X-Provags-ID: V01U2FsdGVkX1+t6AyYsUjmtlDw9GRXR40zwM00hpmodEbRgYD D/xXwkUUbWJ0oWZiwFGq+GtthMRtX9Z9pl5kUPbNZT6ZleRbUy 0NhWLEUwYeGSWWaQVx+Vw== Cc: "peppermint@ietf.org" , Daryl Malas Subject: Re: [PEPPERMINT] DRINKS PROPOSED Charter ..comments please. 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 Since I have been on vacation I have yet to read this entire thread so I may have missed something. Isn't defining the actual data something that should be done in a requirements doc? I think that your first paragraph (up to the ':') is all we need right now. "routes", "service areas" ( which BTW have never been defined in a terminology draft) and "treatment profiles" should be dealt with later. Just keep it short and sweet. My 1.5 cents D. On Apr 24, 2008, at 6:45 AM, Hadriel Kaplan wrote: > >> -----Original Message----- >> From: Richard Shockey [mailto:richard@shockey.us] >> >> No one is proposing a solution. We are describing that we do not >> propose >> exchanging data on Collateralized Debt Instruments and Mortgage >> Interest >> Swaps among SSP's > > Sure, I'm all in favor of getting a charter approved post-haste. > Even if it means my ideas for "Mortgage Interest eXchanges" (MIX) > will have to wait for a charter update. (too bad too, 'cause a > draft-drinks-mix would have been a recipe for success in my opinion) > > But seriously, how "detailed" do we need to be in the charter > regarding this data? I think Daryl's proposed data with some minor > nits is broad enough not to cause heartburn later, while not letting > us get drunk in the possibilities. :) > > How about this: > > [begin] > The scope will be limited to defining the following criteria > necessary for a SSP to respond with the necessary Session > Establishment Data (SED) for both internal and external purposes: > > + Routes > - Destination SIP/SIPS/TEL URI Egress and Ingress > Routes > - Relevant route names, identifiers, and services > - Attributes affecting route selection > + Service Areas > - Individual, ranges, or groups of user-agent > identifiers > - Route-to-service-area associations > + Treatment Profiles > - Priority > - Location > > The mechanism(s) chosen should be extensible, in case additional > criteria are deemed necessary to achieve the goals of the WG in the > future. > [end] > > -hadriel > _______________________________________________ > 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 ACF243A67E1; Wed, 23 Apr 2008 20:48:21 -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 8097B3A6815 for ; Wed, 23 Apr 2008 20:48:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.549 X-Spam-Level: X-Spam-Status: No, score=-2.549 tagged_above=-999 required=5 tests=[AWL=0.050, 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 RSryy5WRTCoZ for ; Wed, 23 Apr 2008 20:48:19 -0700 (PDT) Received: from etmail.acmepacket.com (etmail.acmepacket.com [216.41.24.6]) by core3.amsl.com (Postfix) with ESMTP id 8C9B03A67E1 for ; Wed, 23 Apr 2008 20:48:19 -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.263.0; Wed, 23 Apr 2008 23:47:52 -0400 Received: from mail.acmepacket.com ([216.41.24.7]) by mail.acmepacket.com ([216.41.24.7]) with mapi; Wed, 23 Apr 2008 23:47:52 -0400 From: Hadriel Kaplan To: Richard Shockey , "'Dwight, Timothy M (Tim)'" , 'Daryl Malas' , 'Otmar Lendl' , "peppermint@ietf.org" Date: Wed, 23 Apr 2008 23:45:09 -0400 Thread-Topic: [PEPPERMINT] DRINKS PROPOSED Charter ..comments please. Thread-Index: Acild5bQIMI2yamUS/eNn2gBoulzzQAEsfqAAAwJVRA= Message-ID: References: <125b01c89fe6$14f823c0$3ee86b40$@us> <20080419210654.GA30568@nic.at> <20080420211101.GA32096@nic.at> <1a6601c8a3dd$49ca8c50$dd5fa4f0$@us> <20080422144452.GA582@nic.at> <14b501c8a495$758aeb60$60a0c220$@us> <160DE07A1C4F8E4AA2715DEC577DA49193654F@srvxchg3.cablelabs.com> <154801c8a49b$22fbc2b0$68f34810$@us> <160DE07A1C4F8E4AA2715DEC577DA491936564@srvxchg3.cablelabs.com> <092B2658AAB56A4D80836399A4C4703104526DBE@ASHEVS002.mcilink.com> <160DE07A1C4F8E4AA2715DEC577DA491936566@srvxchg3.cablelabs.com> <092B2658AAB56A4D80836399A4C4703104526E1F@ASHEVS002.mcilink.com> <160DE07A1C4F8E4AA2715DEC577DA491936569@srvxchg3.cablelabs.com> <092B2658AAB56A4D80836399A4C4703104527139@ASHEVS002.mcilink.com> <059501c8a58b$e4899c40$ad9cd4c0$@us> In-Reply-To: <059501c8a58b$e4899c40$ad9cd4c0$@us> 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] DRINKS PROPOSED Charter ..comments please. X-BeenThere: peppermint@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Provisioning Extensions in Peering Registries for Multimedia INTerconnection List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: peppermint-bounces@ietf.org Errors-To: peppermint-bounces@ietf.org > -----Original Message----- > From: Richard Shockey [mailto:richard@shockey.us] > > No one is proposing a solution. We are describing that we do not propose > exchanging data on Collateralized Debt Instruments and Mortgage Interest > Swaps among SSP's Sure, I'm all in favor of getting a charter approved post-haste. Even if it means my ideas for "Mortgage Interest eXchanges" (MIX) will have to wait for a charter update. (too bad too, 'cause a draft-drinks-mix would have been a recipe for success in my opinion) But seriously, how "detailed" do we need to be in the charter regarding this data? I think Daryl's proposed data with some minor nits is broad enough not to cause heartburn later, while not letting us get drunk in the possibilities. :) How about this: [begin] The scope will be limited to defining the following criteria necessary for a SSP to respond with the necessary Session Establishment Data (SED) for both internal and external purposes: + Routes - Destination SIP/SIPS/TEL URI Egress and Ingress Routes - Relevant route names, identifiers, and services - Attributes affecting route selection + Service Areas - Individual, ranges, or groups of user-agent identifiers - Route-to-service-area associations + Treatment Profiles - Priority - Location The mechanism(s) chosen should be extensible, in case additional criteria are deemed necessary to achieve the goals of the WG in the future. [end] -hadriel _______________________________________________ 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 6B51B3A6E48; Wed, 23 Apr 2008 14:49:38 -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 E97123A6AC1 for ; Wed, 23 Apr 2008 14:49:36 -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 kW8MxDRya4eh for ; Wed, 23 Apr 2008 14:49:35 -0700 (PDT) Received: from mail.songbird.com (mail.songbird.com [208.184.79.10]) by core3.amsl.com (Postfix) with ESMTP id E0A8C3A6E55 for ; Wed, 23 Apr 2008 14:49:35 -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 m3NLmVd7029703 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Wed, 23 Apr 2008 14:48:33 -0700 From: "Richard Shockey" To: "'Dwight, Timothy M \(Tim\)'" , "'Daryl Malas'" , "'Hadriel Kaplan'" , "'Otmar Lendl'" , References: <125b01c89fe6$14f823c0$3ee86b40$@us> <20080419210654.GA30568@nic.at> <20080420211101.GA32096@nic.at> <1a6601c8a3dd$49ca8c50$dd5fa4f0$@us> <20080422144452.GA582@nic.at> <14b501c8a495$758aeb60$60a0c220$@us> <160DE07A1C4F8E4AA2715DEC577DA49193654F@srvxchg3.cablelabs.com> <154801c8a49b$22fbc2b0$68f34810$@us> <160DE07A1C4F8E4AA2715DEC577DA491936564@srvxchg3.cablelabs.com> <092B2658AAB56A4D80836399A4C4703104526DBE@ASHEVS002.mcilink.com> <160DE07A1C4F8E4AA2715DEC577DA491936566@srvxchg3.cablelabs.com> <092B2658AAB56A4D80836399A4C4703104526E1F@ASHEVS002.mcilink.com> <160DE07A1C4F8E4AA2715DEC577DA491936569@srvxchg3.cablelabs.com> <092B2658AAB56A4D80836399A4C4703104527139@ASHEVS002.mcilink.com> In-Reply-To: <092B2658AAB56A4D80836399A4C4703104527139@ASHEVS002.mcilink.com> Date: Wed, 23 Apr 2008 17:49:20 -0400 Message-ID: <059501c8a58b$e4899c40$ad9cd4c0$@us> MIME-Version: 1.0 X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: Acild5bQIMI2yamUS/eNn2gBoulzzQAEsfqA Content-Language: en-us X-SongbirdInformation: support@songbird.com for more information X-Songbird: Clean X-Songbird-From: richard@shockey.us Subject: Re: [PEPPERMINT] DRINKS PROPOSED Charter ..comments please. 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 > > Daryl, > > > How do we know that a proposed data model supports anything useful? > > > > I assume that proponents of a particular model will have some use > > case(s) in mind. So why not state them explicitly? But not in a WG charter ... eyes on the prize here folks. We can get a charter approved pretty quickly and form the WG if the scope of what we propose to do _first_ is sufficiently bounded. > > > > [DM] Instead of explicitly defining the model at this point, I > believe > > we are trying to describe well-understood characteristics of > > the model. > > That sounds fine. But maybe we're talking past each other. I'm > responding to what appears to me to be a much more specific proposal, > that the supported data look something like this: I think the operative term is "supported data MAY include" . > > + Routes > - Destination SIP/SIPS/TEL URI Egress and Ingress > Routes > - Relevant route names, identifiers, and services > - NAPTR context and associations > > + Service Areas > - Individual, ranges, or groups of ENUMservice > identifiers > - Route associations > > + Treatment Profiles > - Priority > - Location > > That looks like a data model to me. Now I'm getting confused. So BTW will have to be included. " Data types not in scope will be session rating or other billing information between SSP's" Are we getting close here? > > > > Then we can discuss whether the resulting set of problems to be > > solved, is sufficient (and sufficiently bounded). > > > > [DM] IMHO, this BoF would not have had 2 successful sessions, and > have > > multiple drafts already proposed if the problem statement was > > not pretty well understood. > > Is it written down anywhere? > > > > To me this is simply an issue of determining requirements before we > > settle on an implementation. Settling on an implementation (data > model) > > first, will have the effect of bounding the set of requirements we > might > > satisfy. But doesn't that seem backward? > > > > [DM] If you say you need to build a car...then you say we are going > to > > limit the scope to a seat, an engine, and some wheels; is that > > describing the implementation model? All we said is...we need to > build > > a protocol (as described)...let's limit the scope to some SIP, some > way > > to identify user agents, and some way to know how to get between > > them...have we described the implementation model already? > > In saying you need to build a car, you are defining the solution not > the > problem. What are the requirements? It may turn out that you need a > pickup truck or (gasp) a minivan, not a car. > > I think the limitations in scope you state here, are better than those > implied by what I construe as a data model, above. They're at least > directionally correct, meaning we are moving away from a proposed > solution and toward an understanding of the requirements. No one is proposing a solution. We are describing that we do not propose exchanging data on Collateralized Debt Instruments and Mortgage Interest Swaps among SSP's > > I also agree that we need both requirements and bounds on the solution > space (which is what I think you mean by scope). I think the two have > to mature at the same time though. What I'm sensing here is that one > (bounds on solution space) is out in front of the other (explicit > definition of requirements). That's what makes me uneasy. For > example > right now I'd agree that we will only use IETF protocols. Until I > understand the requirements better I don't know that I'd accept a > restriction that SIP be the only protocol. SIP is certainly not the only protocol nor is ENUM the only query mechanism. If someone wants to use DRINKS for the exchange of H.323 gateway information they certainly can. > > tim _______________________________________________ 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 119683A6D34; Wed, 23 Apr 2008 12:24:56 -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 621EE3A6D34 for ; Wed, 23 Apr 2008 12:24:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id m-6hsF59MNQm for ; Wed, 23 Apr 2008 12:24:51 -0700 (PDT) Received: from ashesmtp03.verizonbusiness.com (ASHESMTP03.verizonbusiness.com [198.4.8.167]) by core3.amsl.com (Postfix) with ESMTP id 6539A3A6DDD for ; Wed, 23 Apr 2008 12:24:51 -0700 (PDT) Received: from dgismtp02.mcilink.com ([166.38.58.142]) by firewall.verizonbusiness.com (Sun Java(tm) System Messaging Server 6.3-5.02 (built Oct 12 2007; 32bit)) with ESMTP id <0JZS00DB6LXKT700@firewall.verizonbusiness.com> for peppermint@ietf.org; Wed, 23 Apr 2008 19:24:56 +0000 (GMT) Received: from dgismtp02.mcilink.com ([127.0.0.1]) by dgismtp02.mcilink.com (iPlanet Messaging Server 5.2 HotFix 2.08 (built Sep 22 2005)) with SMTP id <0JZS000L3LXKCY@dgismtp02.mcilink.com> for peppermint@ietf.org; Wed, 23 Apr 2008 19:24:56 +0000 (GMT) Received: from ASHSRV140.mcilink.com ([153.39.68.166]) by dgismtp02.mcilink.com (iPlanet Messaging Server 5.2 HotFix 2.08 (built Sep 22 2005)) with ESMTP id <0JZS00NBDLXJ4K@dgismtp02.mcilink.com> for peppermint@ietf.org; Wed, 23 Apr 2008 19:24:55 +0000 (GMT) Received: from ASHEVS002.mcilink.com ([153.39.71.1]) by ASHSRV140.mcilink.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 23 Apr 2008 19:24:55 +0000 Date: Wed, 23 Apr 2008 19:24:54 +0000 From: "Dwight, Timothy M (Tim)" In-reply-to: <160DE07A1C4F8E4AA2715DEC577DA491936569@srvxchg3.cablelabs.com> To: Daryl Malas , Hadriel Kaplan , Richard Shockey , Otmar Lendl , peppermint@ietf.org Message-id: <092B2658AAB56A4D80836399A4C4703104527139@ASHEVS002.mcilink.com> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message Thread-topic: [PEPPERMINT] DRINKS PROPOSED Charter ..comments please. Thread-index: Acikh2EScAYa3BvkRuqoFaN0JnBW6gAAkqtQAAKgAAAAAJ+XUAAA2ISwABUcBLAAGvG54AABAsIgAACdg7AAACqXoAAATdLAAABSiDAAA31i0A== X-MS-Has-Attach: X-MS-TNEF-Correlator: References: <125b01c89fe6$14f823c0$3ee86b40$@us> <20080419210654.GA30568@nic.at> <20080420211101.GA32096@nic.at> <1a6601c8a3dd$49ca8c50$dd5fa4f0$@us> <20080422144452.GA582@nic.at> <14b501c8a495$758aeb60$60a0c220$@us> <160DE07A1C4F8E4AA2715DEC577DA49193654F@srvxchg3.cablelabs.com> <154801c8a49b$22fbc2b0$68f34810$@us> <160DE07A1C4F8E4AA2715DEC577DA491936564@srvxchg3.cablelabs.com> <092B2658AAB56A4D80836399A4C4703104526DBE@ASHEVS002.mcilink.com> <160DE07A1C4F8E4AA2715DEC577DA491936566@srvxchg3.cablelabs.com> <092B2658AAB56A4D80836399A4C4703104526E1F@ASHEVS002.mcilink.com> <160DE07A1C4F8E4AA2715DEC577DA491936569@srvxchg3.cablelabs.com> X-OriginalArrivalTime: 23 Apr 2008 19:24:55.0731 (UTC) FILETIME=[B63EA830:01C8A577] Subject: Re: [PEPPERMINT] DRINKS PROPOSED Charter ..comments please. 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 Daryl, > How do we know that a proposed data model supports anything useful? > > I assume that proponents of a particular model will have some use > case(s) in mind. So why not state them explicitly? > > [DM] Instead of explicitly defining the model at this point, I believe > we are trying to describe well-understood characteristics of > the model. That sounds fine. But maybe we're talking past each other. I'm responding to what appears to me to be a much more specific proposal, that the supported data look something like this: + Routes - Destination SIP/SIPS/TEL URI Egress and Ingress Routes - Relevant route names, identifiers, and services - NAPTR context and associations + Service Areas - Individual, ranges, or groups of ENUMservice identifiers - Route associations + Treatment Profiles - Priority - Location That looks like a data model to me. > Then we can discuss whether the resulting set of problems to be > solved, is sufficient (and sufficiently bounded). > > [DM] IMHO, this BoF would not have had 2 successful sessions, and have > multiple drafts already proposed if the problem statement was > not pretty well understood. Is it written down anywhere? > To me this is simply an issue of determining requirements before we > settle on an implementation. Settling on an implementation (data model) > first, will have the effect of bounding the set of requirements we might > satisfy. But doesn't that seem backward? > > [DM] If you say you need to build a car...then you say we are going to > limit the scope to a seat, an engine, and some wheels; is that > describing the implementation model? All we said is...we need to build > a protocol (as described)...let's limit the scope to some SIP, some way > to identify user agents, and some way to know how to get between > them...have we described the implementation model already? In saying you need to build a car, you are defining the solution not the problem. What are the requirements? It may turn out that you need a pickup truck or (gasp) a minivan, not a car. I think the limitations in scope you state here, are better than those implied by what I construe as a data model, above. They're at least directionally correct, meaning we are moving away from a proposed solution and toward an understanding of the requirements. I also agree that we need both requirements and bounds on the solution space (which is what I think you mean by scope). I think the two have to mature at the same time though. What I'm sensing here is that one (bounds on solution space) is out in front of the other (explicit definition of requirements). That's what makes me uneasy. For example right now I'd agree that we will only use IETF protocols. Until I understand the requirements better I don't know that I'd accept a restriction that SIP be the only protocol. tim _______________________________________________ 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 147A43A6E0B; Wed, 23 Apr 2008 12:05:22 -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 B5B2228C239 for ; Wed, 23 Apr 2008 12:05:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.292 X-Spam-Level: X-Spam-Status: No, score=-0.292 tagged_above=-999 required=5 tests=[AWL=0.171, 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 w1J277YEBkJI for ; Wed, 23 Apr 2008 12:05:17 -0700 (PDT) Received: from ondar.cablelabs.com (ondar.cablelabs.com [192.160.73.61]) by core3.amsl.com (Postfix) with ESMTP id 48F8A28C1E7 for ; Wed, 23 Apr 2008 12:05:01 -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 m3NJ55nK024680; Wed, 23 Apr 2008 13:05:05 -0600 Received: from srvxchg3.cablelabs.com (10.5.0.25) by kyzyl.cablelabs.com (F-Secure/fsigk_smtp/511/kyzyl.cablelabs.com); Wed, 23 Apr 2008 13:05:05 -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, 23 Apr 2008 13:05:05 -0600 Message-ID: <160DE07A1C4F8E4AA2715DEC577DA49193656B@srvxchg3.cablelabs.com> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [PEPPERMINT] DRINKS PROPOSED Charter ..comments please. Thread-Index: Acikh2EScAYa3BvkRuqoFaN0JnBW6gAAkqtQAAKgAAAAAJ+XUAAA2ISwABUcBLAAGvG54AABAsIgAACdg7AAACqXoAAATdLAAACd5GAAA6+psA== References: <125b01c89fe6$14f823c0$3ee86b40$@us> <20080419210654.GA30568@nic.at> <20080420211101.GA32096@nic.at> <1a6601c8a3dd$49ca8c50$dd5fa4f0$@us> <20080422144452.GA582@nic.at> <14b501c8a495$758aeb60$60a0c220$@us> <160DE07A1C4F8E4AA2715DEC577DA49193654F@srvxchg3.cablelabs.com> <154801c8a49b$22fbc2b0$68f34810$@us> <160DE07A1C4F8E4AA2715DEC577DA491936564@srvxchg3.cablelabs.com> <092B2658AAB56A4D80836399A4C4703104526DBE@ASHEVS002.mcilink.com> <160DE07A1C4F8E4AA2715DEC577DA491936566@srvxchg3.cablelabs.com> <092B2658AAB56A4D80836399A4C4703104526E1F@ASHEVS002.mcilink.com> From: "Daryl Malas" To: "Hadriel Kaplan" , "Dwight, Timothy M (Tim)" , X-Approved: ondar Subject: Re: [PEPPERMINT] DRINKS PROPOSED Charter ..comments please. 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 Guys, I apologize if my previous comments came across as a little frustrated with the discussion. I am just concerned we will continue to go around and around on nuances without moving forward. We should/must take the time we need to make sure everyone is "generally" moving in the same direction. We do not want a situation where some do not understand the purpose of the working group; however, I think sometimes we can nit pick things too much. I just don't want to be discussing the charter for another 6 months, and if you think that is exaggerated; there are plenty of examples in the IETF to point at...you can start with the speermint terminology draft. ;-) I just want to avoid arguing the differences between a sofa and a couch. :-) --Daryl -----Original Message----- From: Hadriel Kaplan [mailto:HKaplan@acmepacket.com] Sent: Wednesday, April 23, 2008 11:27 AM To: Dwight, Timothy M (Tim); Daryl Malas; peppermint@ietf.org Subject: RE: [PEPPERMINT] DRINKS PROPOSED Charter ..comments please. Yeah I'm with Tim on this - this does seem like putting the cart before the horse. I have no doubt we will get use-cases and data-types that will cause debate in the WG, but that's partly what a WG is there to decide, no? I don't think it will take too long to reject ones there isn't interest in, and we haven't needed to be able to point to a charter to say "out of scope" to do that usually in other WG's. If there are ones brought forth there *is* interest in, then we can either spend time in a WG arguing over them, or spend the same amount of time arguing about it before a WG is formed. At least with doing it in the WG, we can make progress on the ones that are less contentious. Also, I don't think the type of data we've been talking about is going to constrain much anyway. Items named "Routes", "relevant route names, identifiers, and services", and "route associations" are broad/generic enough to cover a whole lotta stuff. We'll read into them what we want to read into them. -hadriel > -----Original Message----- > From: Dwight, Timothy M (Tim) > [mailto:timothy.dwight@verizonbusiness.com] > Sent: Wednesday, April 23, 2008 1:00 PM > To: Daryl Malas; Hadriel Kaplan; Richard Shockey; Otmar Lendl; > peppermint@ietf.org > Subject: RE: [PEPPERMINT] DRINKS PROPOSED Charter ..comments please. > > Well, limiting the scope sounds good. But on what basis do we limit it? > How do we know that a proposed data model supports anything useful? > > I assume that proponents of a particular model will have some use > case(s) in mind. So why not state them explicitly? Then we can > discuss whether the resulting set of problems to be solved, is > sufficient (and sufficiently bounded). > > To me this is simply an issue of determining requirements before we > settle on an implementation. Settling on an implementation (data > model) first, will have the effect of bounding the set of requirements > we might satisfy. But doesn't that seem backward? > > Tim > > > > -----Original Message----- > > From: Daryl Malas [mailto:D.Malas@cablelabs.com] > > Sent: Wednesday, April 23, 2008 11:48 AM > > To: Dwight, Timothy M (Tim); Hadriel Kaplan; Richard Shockey; Otmar > > Lendl; peppermint@ietf.org > > Subject: RE: [PEPPERMINT] DRINKS PROPOSED Charter ..comments please. > > > > I think the purpose here is to contain the scope of the charter. > > The subsequent use cases will then be limited to the scope of the charter. > > If you do not clearly define the scope, then the use cases can run > > all over the place. If this occurs, it just creates many years of > > debate, a very frustrated set of co-chairs and working group. > > > > I think this is the right approach, but we need to be careful to > > balance putting enough detail in to clearly contain the scope > > without too much detail as to make the charter a working group > > draft. > > > > --Daryl > > > > -----Original Message----- > > From: Dwight, Timothy M (Tim) > > [mailto:timothy.dwight@verizonbusiness.com] > > Sent: Wednesday, April 23, 2008 10:43 AM > > To: Hadriel Kaplan; Daryl Malas; Richard Shockey; Otmar Lendl; > > peppermint@ietf.org > > Subject: RE: [PEPPERMINT] DRINKS PROPOSED Charter ..comments please. > > > > Do we have to determine the data model now? This seems premature > > when we've not yet considered use cases. > > > > Tim > > > > > > > -----Original Message----- > > > From: peppermint-bounces@ietf.org > > > [mailto:peppermint-bounces@ietf.org] On Behalf Of Hadriel Kaplan > > > Sent: Wednesday, April 23, 2008 11:34 AM > > > To: Daryl Malas; Richard Shockey; Otmar Lendl; peppermint@ietf.org > > > Subject: Re: [PEPPERMINT] DRINKS PROPOSED Charter ..comments please. > > > > > > > > > > > > > -----Original Message----- > > > > From: Daryl Malas [mailto:D.Malas@cablelabs.com] > > > > > > > > I recommend we further simplify: > > > > > > > > The scope will be limited to defining the following > > > criteria necessary > > > > for a SSP to respond with the necessary Session > > > Establishment Data (SED) > > > > for both internal and external purposes: > > > > > > OK, so here you're defining the minimal data needed to be > > exchanged by > > > > > DRINKS, in order for an SSP to provide SED - right? > > > > > > > > > > + Routes > > > > - Destination SIP/SIPS/TEL URI Egress and > > > Ingress Routes > > > > - Relevant route names, identifiers, and services > > > > - NAPTR context and associations > > > > > > When you exchange data, it may be in the form of a NAPTR in > > syntax and > > > > > maybe even semantics, but it's not really a "NAPTR" DNS entry - it > > > just happens to be that you chose to format the resultant route > > > information in the form of a NAPTR. So I think the word "NAPTR" > > > shouldn't be in the charter's list of data to be exchanged. We > > > may just happen to use that format in the end for the data, but > > > there's nothing about the data that demands it. (and in fact I > > > personally think it's confusing and misleading to be using that > > specific format > > > in the data exchange directly, but we can argue about that later > > > :) > > > > > > > > > > + Service Areas > > > > - Individual, ranges, or groups of ENUMservice > > > > identifiers > > > > - Route associations > > > > > > I don't know what a "Route association" is? > > > > > > > > > > + Treatment Profiles > > > > - Priority > > > > - Location > > > > > > I note this doesn't directly include originating or source > > > information, which is fairly essential to SIP routing, afaict. Is > > > that something you'd classify under "route associations" or > > "treatment > > > > > profiles", or do you specifically not want that in the charter? > > > > > > -hadriel > > > _______________________________________________ > > > 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 7608A28C339; Wed, 23 Apr 2008 10:30:36 -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 BB5C63A6AD0 for ; Wed, 23 Apr 2008 10:30:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.544 X-Spam-Level: X-Spam-Status: No, score=-2.544 tagged_above=-999 required=5 tests=[AWL=0.055, 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 u-da62KKrn4z for ; Wed, 23 Apr 2008 10:30:34 -0700 (PDT) Received: from etmail.acmepacket.com (etmail.acmepacket.com [216.41.24.6]) by core3.amsl.com (Postfix) with ESMTP id 658AE3A6DAF for ; Wed, 23 Apr 2008 10:30:34 -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.263.0; Wed, 23 Apr 2008 13:30:08 -0400 Received: from mail.acmepacket.com ([216.41.24.7]) by mail.acmepacket.com ([216.41.24.7]) with mapi; Wed, 23 Apr 2008 13:30:08 -0400 From: Hadriel Kaplan To: "Dwight, Timothy M (Tim)" , Daryl Malas , "peppermint@ietf.org" Date: Wed, 23 Apr 2008 13:27:24 -0400 Thread-Topic: [PEPPERMINT] DRINKS PROPOSED Charter ..comments please. Thread-Index: Acikh2EScAYa3BvkRuqoFaN0JnBW6gAAkqtQAAKgAAAAAJ+XUAAA2ISwABUcBLAAGvG54AABAsIgAACdg7AAACqXoAAATdLAAACd5GA= Message-ID: References: <125b01c89fe6$14f823c0$3ee86b40$@us> <20080419210654.GA30568@nic.at> <20080420211101.GA32096@nic.at> <1a6601c8a3dd$49ca8c50$dd5fa4f0$@us> <20080422144452.GA582@nic.at> <14b501c8a495$758aeb60$60a0c220$@us> <160DE07A1C4F8E4AA2715DEC577DA49193654F@srvxchg3.cablelabs.com> <154801c8a49b$22fbc2b0$68f34810$@us> <160DE07A1C4F8E4AA2715DEC577DA491936564@srvxchg3.cablelabs.com> <092B2658AAB56A4D80836399A4C4703104526DBE@ASHEVS002.mcilink.com> <160DE07A1C4F8E4AA2715DEC577DA491936566@srvxchg3.cablelabs.com> <092B2658AAB56A4D80836399A4C4703104526E1F@ASHEVS002.mcilink.com> In-Reply-To: <092B2658AAB56A4D80836399A4C4703104526E1F@ASHEVS002.mcilink.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] DRINKS PROPOSED Charter ..comments please. 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 Yeah I'm with Tim on this - this does seem like putting the cart before the horse. I have no doubt we will get use-cases and data-types that will cause debate in the WG, but that's partly what a WG is there to decide, no? I don't think it will take too long to reject ones there isn't interest in, and we haven't needed to be able to point to a charter to say "out of scope" to do that usually in other WG's. If there are ones brought forth there *is* interest in, then we can either spend time in a WG arguing over them, or spend the same amount of time arguing about it before a WG is formed. At least with doing it in the WG, we can make progress on the ones that are less contentious. Also, I don't think the type of data we've been talking about is going to constrain much anyway. Items named "Routes", "relevant route names, identifiers, and services", and "route associations" are broad/generic enough to cover a whole lotta stuff. We'll read into them what we want to read into them. -hadriel > -----Original Message----- > From: Dwight, Timothy M (Tim) [mailto:timothy.dwight@verizonbusiness.com] > Sent: Wednesday, April 23, 2008 1:00 PM > To: Daryl Malas; Hadriel Kaplan; Richard Shockey; Otmar Lendl; > peppermint@ietf.org > Subject: RE: [PEPPERMINT] DRINKS PROPOSED Charter ..comments please. > > Well, limiting the scope sounds good. But on what basis do we limit it? > How do we know that a proposed data model supports anything useful? > > I assume that proponents of a particular model will have some use > case(s) in mind. So why not state them explicitly? Then we can discuss > whether the resulting set of problems to be solved, is sufficient (and > sufficiently bounded). > > To me this is simply an issue of determining requirements before we > settle on an implementation. Settling on an implementation (data model) > first, will have the effect of bounding the set of requirements we might > satisfy. But doesn't that seem backward? > > Tim > > > > -----Original Message----- > > From: Daryl Malas [mailto:D.Malas@cablelabs.com] > > Sent: Wednesday, April 23, 2008 11:48 AM > > To: Dwight, Timothy M (Tim); Hadriel Kaplan; Richard Shockey; > > Otmar Lendl; peppermint@ietf.org > > Subject: RE: [PEPPERMINT] DRINKS PROPOSED Charter ..comments please. > > > > I think the purpose here is to contain the scope of the charter. The > > subsequent use cases will then be limited to the scope of the charter. > > If you do not clearly define the scope, then the use cases can run all > > over the place. If this occurs, it just creates many years > > of debate, a > > very frustrated set of co-chairs and working group. > > > > I think this is the right approach, but we need to be careful > > to balance > > putting enough detail in to clearly contain the scope without too much > > detail as to make the charter a working group draft. > > > > --Daryl > > > > -----Original Message----- > > From: Dwight, Timothy M (Tim) > > [mailto:timothy.dwight@verizonbusiness.com] > > Sent: Wednesday, April 23, 2008 10:43 AM > > To: Hadriel Kaplan; Daryl Malas; Richard Shockey; Otmar Lendl; > > peppermint@ietf.org > > Subject: RE: [PEPPERMINT] DRINKS PROPOSED Charter ..comments please. > > > > Do we have to determine the data model now? This seems premature when > > we've not yet considered use cases. > > > > Tim > > > > > > > -----Original Message----- > > > From: peppermint-bounces@ietf.org > > > [mailto:peppermint-bounces@ietf.org] On Behalf Of Hadriel Kaplan > > > Sent: Wednesday, April 23, 2008 11:34 AM > > > To: Daryl Malas; Richard Shockey; Otmar Lendl; peppermint@ietf.org > > > Subject: Re: [PEPPERMINT] DRINKS PROPOSED Charter ..comments please. > > > > > > > > > > > > > -----Original Message----- > > > > From: Daryl Malas [mailto:D.Malas@cablelabs.com] > > > > > > > > I recommend we further simplify: > > > > > > > > The scope will be limited to defining the following > > > criteria necessary > > > > for a SSP to respond with the necessary Session > > > Establishment Data (SED) > > > > for both internal and external purposes: > > > > > > OK, so here you're defining the minimal data needed to be > > exchanged by > > > > > DRINKS, in order for an SSP to provide SED - right? > > > > > > > > > > + Routes > > > > - Destination SIP/SIPS/TEL URI Egress and > > > Ingress Routes > > > > - Relevant route names, identifiers, and services > > > > - NAPTR context and associations > > > > > > When you exchange data, it may be in the form of a NAPTR in > > syntax and > > > > > maybe even semantics, but it's not really a "NAPTR" DNS entry - it > > > just happens to be that you chose to format the resultant route > > > information in the form of a NAPTR. So I think the word "NAPTR" > > > shouldn't be in the charter's list of data to be exchanged. We may > > > just happen to use that format in the end for the data, but there's > > > nothing about the data that demands it. (and in fact I personally > > > think it's confusing and misleading to be using that > > specific format > > > in the data exchange directly, but we can argue about that later :) > > > > > > > > > > + Service Areas > > > > - Individual, ranges, or groups of ENUMservice > > > > identifiers > > > > - Route associations > > > > > > I don't know what a "Route association" is? > > > > > > > > > > + Treatment Profiles > > > > - Priority > > > > - Location > > > > > > I note this doesn't directly include originating or source > > > information, which is fairly essential to SIP routing, afaict. Is > > > that something you'd classify under "route associations" or > > "treatment > > > > > profiles", or do you specifically not want that in the charter? > > > > > > -hadriel > > > _______________________________________________ > > > 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 E41513A6C37; Wed, 23 Apr 2008 10:28: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 C690C3A6B66 for ; Wed, 23 Apr 2008 10:28:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.349 X-Spam-Level: X-Spam-Status: No, score=-3.349 tagged_above=-999 required=5 tests=[AWL=0.250, 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 qsKuTV1nSwLS for ; Wed, 23 Apr 2008 10:28:11 -0700 (PDT) Received: from mail.songbird.com (mail.songbird.com [208.184.79.10]) by core3.amsl.com (Postfix) with ESMTP id C8B003A6A32 for ; Wed, 23 Apr 2008 10:28:11 -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 m3NHR653010555 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Wed, 23 Apr 2008 10:27:07 -0700 From: "Richard Shockey" To: "'Dwight, Timothy M \(Tim\)'" , "'Daryl Malas'" , "'Hadriel Kaplan'" , "'Otmar Lendl'" , References: <125b01c89fe6$14f823c0$3ee86b40$@us> <20080419210654.GA30568@nic.at> <20080420211101.GA32096@nic.at> <1a6601c8a3dd$49ca8c50$dd5fa4f0$@us> <20080422144452.GA582@nic.at> <14b501c8a495$758aeb60$60a0c220$@us> <160DE07A1C4F8E4AA2715DEC577DA49193654F@srvxchg3.cablelabs.com> <154801c8a49b$22fbc2b0$68f34810$@us> <160DE07A1C4F8E4AA2715DEC577DA491936564@srvxchg3.cablelabs.com> <092B2658AAB56A4D80836399A4C4703104526DBE@ASHEVS002.mcilink.com> <160DE07A1C4F8E4AA2715DEC577DA491936566@srvxchg3.cablelabs.com> <092B2658AAB56A4D80836399A4C4703104526E1F@ASHEVS002.mcilink.com> In-Reply-To: <092B2658AAB56A4D80836399A4C4703104526E1F@ASHEVS002.mcilink.com> Date: Wed, 23 Apr 2008 13:27:56 -0400 Message-ID: <106201c8a567$5f85fc10$1e91f430$@us> MIME-Version: 1.0 X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: AcilY1jJn1nDbtieQI+5dO73ynHtaAAA7y8Q Content-Language: en-us X-SongbirdInformation: support@songbird.com for more information X-Songbird: Clean X-Songbird-From: richard@shockey.us Subject: Re: [PEPPERMINT] DRINKS PROPOSED Charter ..comments please. X-BeenThere: peppermint@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Provisioning Extensions in Peering Registries for Multimedia INTerconnection List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: peppermint-bounces@ietf.org Errors-To: peppermint-bounces@ietf.org > -----Original Message----- > From: Dwight, Timothy M (Tim) > [mailto:timothy.dwight@verizonbusiness.com] > Sent: Wednesday, April 23, 2008 1:00 PM > To: Daryl Malas; Hadriel Kaplan; Richard Shockey; Otmar Lendl; > peppermint@ietf.org > Subject: RE: [PEPPERMINT] DRINKS PROPOSED Charter ..comments please. > > Well, limiting the scope sounds good. But on what basis do we limit > it? As a practical matter we limit WG scope to what the AD's are prepared accept. In reality we are not limiting ourselves at all ..only limiting what we attempt to do first. > How do we know that a proposed data model supports anything useful? > > I assume that proponents of a particular model will have some use > case(s) in mind. So why not state them explicitly? Then we can > discuss > whether the resulting set of problems to be solved, is sufficient (and > sufficiently bounded). > > To me this is simply an issue of determining requirements before we > settle on an implementation. Settling on an implementation (data > model) > first, will have the effect of bounding the set of requirements we > might > satisfy. But doesn't that seem backward? > > Tim > > > > -----Original Message----- > > From: Daryl Malas [mailto:D.Malas@cablelabs.com] > > Sent: Wednesday, April 23, 2008 11:48 AM > > To: Dwight, Timothy M (Tim); Hadriel Kaplan; Richard Shockey; > > Otmar Lendl; peppermint@ietf.org > > Subject: RE: [PEPPERMINT] DRINKS PROPOSED Charter ..comments please. > > > > I think the purpose here is to contain the scope of the charter. > The > > subsequent use cases will then be limited to the scope of the > charter. > > If you do not clearly define the scope, then the use cases can run > all > > over the place. If this occurs, it just creates many years > > of debate, a > > very frustrated set of co-chairs and working group. > > > > I think this is the right approach, but we need to be careful > > to balance > > putting enough detail in to clearly contain the scope without too > much > > detail as to make the charter a working group draft. > > > > --Daryl > > > > -----Original Message----- > > From: Dwight, Timothy M (Tim) > > [mailto:timothy.dwight@verizonbusiness.com] > > Sent: Wednesday, April 23, 2008 10:43 AM > > To: Hadriel Kaplan; Daryl Malas; Richard Shockey; Otmar Lendl; > > peppermint@ietf.org > > Subject: RE: [PEPPERMINT] DRINKS PROPOSED Charter ..comments please. > > > > Do we have to determine the data model now? This seems premature > when > > we've not yet considered use cases. > > > > Tim > > > > > > > -----Original Message----- > > > From: peppermint-bounces@ietf.org > > > [mailto:peppermint-bounces@ietf.org] On Behalf Of Hadriel Kaplan > > > Sent: Wednesday, April 23, 2008 11:34 AM > > > To: Daryl Malas; Richard Shockey; Otmar Lendl; peppermint@ietf.org > > > Subject: Re: [PEPPERMINT] DRINKS PROPOSED Charter ..comments > please. > > > > > > > > > > > > > -----Original Message----- > > > > From: Daryl Malas [mailto:D.Malas@cablelabs.com] > > > > > > > > I recommend we further simplify: > > > > > > > > The scope will be limited to defining the following > > > criteria necessary > > > > for a SSP to respond with the necessary Session > > > Establishment Data (SED) > > > > for both internal and external purposes: > > > > > > OK, so here you're defining the minimal data needed to be > > exchanged by > > > > > DRINKS, in order for an SSP to provide SED - right? > > > > > > > > > > + Routes > > > > - Destination SIP/SIPS/TEL URI Egress and > > > Ingress Routes > > > > - Relevant route names, identifiers, and > services > > > > - NAPTR context and associations > > > > > > When you exchange data, it may be in the form of a NAPTR in > > syntax and > > > > > maybe even semantics, but it's not really a "NAPTR" DNS entry - it > > > just happens to be that you chose to format the resultant route > > > information in the form of a NAPTR. So I think the word "NAPTR" > > > shouldn't be in the charter's list of data to be exchanged. We > may > > > just happen to use that format in the end for the data, but > there's > > > nothing about the data that demands it. (and in fact I personally > > > think it's confusing and misleading to be using that > > specific format > > > in the data exchange directly, but we can argue about that later > :) > > > > > > > > > > + Service Areas > > > > - Individual, ranges, or groups of ENUMservice > > > > identifiers > > > > - Route associations > > > > > > I don't know what a "Route association" is? > > > > > > > > > > + Treatment Profiles > > > > - Priority > > > > - Location > > > > > > I note this doesn't directly include originating or source > > > information, which is fairly essential to SIP routing, afaict. Is > > > that something you'd classify under "route associations" or > > "treatment > > > > > profiles", or do you specifically not want that in the charter? > > > > > > -hadriel > > > _______________________________________________ > > > 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 E961B3A69DD; Wed, 23 Apr 2008 10:13:40 -0700 (PDT) X-Original-To: peppermint@core3.amsl.com Delivered-To: peppermint@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 033283A6E0B for ; Wed, 23 Apr 2008 10:13:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.263 X-Spam-Level: X-Spam-Status: No, score=-0.263 tagged_above=-999 required=5 tests=[AWL=0.200, 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 t3TUzwNc+XQZ for ; Wed, 23 Apr 2008 10:13:35 -0700 (PDT) Received: from ondar.cablelabs.com (ondar.cablelabs.com [192.160.73.61]) by core3.amsl.com (Postfix) with ESMTP id D8E9F3A69DD for ; Wed, 23 Apr 2008 10:13:34 -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 m3NHDdeU015621; Wed, 23 Apr 2008 11:13:39 -0600 Received: from srvxchg3.cablelabs.com (10.5.0.25) by kyzyl.cablelabs.com (F-Secure/fsigk_smtp/511/kyzyl.cablelabs.com); Wed, 23 Apr 2008 11:13:39 -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, 23 Apr 2008 11:13:39 -0600 Message-ID: <160DE07A1C4F8E4AA2715DEC577DA491936569@srvxchg3.cablelabs.com> In-Reply-To: <092B2658AAB56A4D80836399A4C4703104526E1F@ASHEVS002.mcilink.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [PEPPERMINT] DRINKS PROPOSED Charter ..comments please. Thread-Index: Acikh2EScAYa3BvkRuqoFaN0JnBW6gAAkqtQAAKgAAAAAJ+XUAAA2ISwABUcBLAAGvG54AABAsIgAACdg7AAACqXoAAATdLAAABSiDA= References: <125b01c89fe6$14f823c0$3ee86b40$@us> <20080419210654.GA30568@nic.at> <20080420211101.GA32096@nic.at> <1a6601c8a3dd$49ca8c50$dd5fa4f0$@us> <20080422144452.GA582@nic.at> <14b501c8a495$758aeb60$60a0c220$@us> <160DE07A1C4F8E4AA2715DEC577DA49193654F@srvxchg3.cablelabs.com> <154801c8a49b$22fbc2b0$68f34810$@us> <160DE07A1C4F8E4AA2715DEC577DA491936564@srvxchg3.cablelabs.com> <092B2658AAB56A4D80836399A4C4703104526DBE@ASHEVS002.mcilink.com> <160DE07A1C4F8E4AA2715DEC577DA491936566@srvxchg3.cablelabs.com> <092B2658AAB56A4D80836399A4C4703104526E1F@ASHEVS002.mcilink.com> From: "Daryl Malas" To: "Dwight, Timothy M (Tim)" , "Hadriel Kaplan" , "Richard Shockey" , "Otmar Lendl" , X-Approved: ondar Subject: Re: [PEPPERMINT] DRINKS PROPOSED Charter ..comments please. 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 Comments in-line... -----Original Message----- From: Dwight, Timothy M (Tim) [mailto:timothy.dwight@verizonbusiness.com] Sent: Wednesday, April 23, 2008 11:00 AM To: Daryl Malas; Hadriel Kaplan; Richard Shockey; Otmar Lendl; peppermint@ietf.org Subject: RE: [PEPPERMINT] DRINKS PROPOSED Charter ..comments please. Well, limiting the scope sounds good. But on what basis do we limit it? [DM] For starters, we limited it as the charter already spells out... "The DRINKS working group is chartered with a scope that is orthogonal to SPEERMINT and ENUM. The protocol work OF DRINKS will be designed to build from the work of SPEERMINT and ENUM to identify and define the data structures and data exchange protocol(s) among SIP based Multimedia administrative domains. These administrative domains may be of any practical size and could be any type of SSP, such as recognized telephony carriers, enterprises, end-user groups, or Federations. Data exchanges among these administrative domains may be bi-lateral or multi-lateral in nature, and could include bulk updates and/or more granular real-time updates. Typical data includes the mapping of phone numbers to URIs, policies surrounding admission to various points of network interconnection, and various other types of interconnect data. In addition, there is a specific need for the exchange of such data between the Registry and various types of PSTN network databases. The working group will draw upon expert advice and on-going consultation from the ENUM and SPEERMINT working groups, and also the XML Directorate. The working group will consider the reuse of elements of RFC 4114. The final work product(s) from this working group will utilize and be based on XML documents and XML document exchanges." How do we know that a proposed data model supports anything useful? I assume that proponents of a particular model will have some use case(s) in mind. So why not state them explicitly? [DM] Instead of explicitly defining the model at this point, I believe we are trying to describe well-understood characteristics of the model. Then we can discuss whether the resulting set of problems to be solved, is sufficient (and sufficiently bounded). [DM] IMHO, this BoF would not have had 2 successful sessions, and have multiple drafts already proposed if the problem statement was not pretty well understood. To me this is simply an issue of determining requirements before we settle on an implementation. Settling on an implementation (data model) first, will have the effect of bounding the set of requirements we might satisfy. But doesn't that seem backward? [DM] If you say you need to build a car...then you say we are going to limit the scope to a seat, an engine, and some wheels; is that describing the implementation model? All we said is...we need to build a protocol (as described)...let's limit the scope to some SIP, some way to identify user agents, and some way to know how to get between them...have we described the implementation model already? Tim > -----Original Message----- > From: Daryl Malas [mailto:D.Malas@cablelabs.com] > Sent: Wednesday, April 23, 2008 11:48 AM > To: Dwight, Timothy M (Tim); Hadriel Kaplan; Richard Shockey; Otmar > Lendl; peppermint@ietf.org > Subject: RE: [PEPPERMINT] DRINKS PROPOSED Charter ..comments please. > > I think the purpose here is to contain the scope of the charter. The > subsequent use cases will then be limited to the scope of the charter. > If you do not clearly define the scope, then the use cases can run all > over the place. If this occurs, it just creates many years of debate, > a very frustrated set of co-chairs and working group. > > I think this is the right approach, but we need to be careful to > balance putting enough detail in to clearly contain the scope without > too much detail as to make the charter a working group draft. > > --Daryl > > -----Original Message----- > From: Dwight, Timothy M (Tim) > [mailto:timothy.dwight@verizonbusiness.com] > Sent: Wednesday, April 23, 2008 10:43 AM > To: Hadriel Kaplan; Daryl Malas; Richard Shockey; Otmar Lendl; > peppermint@ietf.org > Subject: RE: [PEPPERMINT] DRINKS PROPOSED Charter ..comments please. > > Do we have to determine the data model now? This seems premature when > we've not yet considered use cases. > > Tim > > > > -----Original Message----- > > From: peppermint-bounces@ietf.org > > [mailto:peppermint-bounces@ietf.org] On Behalf Of Hadriel Kaplan > > Sent: Wednesday, April 23, 2008 11:34 AM > > To: Daryl Malas; Richard Shockey; Otmar Lendl; peppermint@ietf.org > > Subject: Re: [PEPPERMINT] DRINKS PROPOSED Charter ..comments please. > > > > > > > > > -----Original Message----- > > > From: Daryl Malas [mailto:D.Malas@cablelabs.com] > > > > > > I recommend we further simplify: > > > > > > The scope will be limited to defining the following > > criteria necessary > > > for a SSP to respond with the necessary Session > > Establishment Data (SED) > > > for both internal and external purposes: > > > > OK, so here you're defining the minimal data needed to be > exchanged by > > > DRINKS, in order for an SSP to provide SED - right? > > > > > > > + Routes > > > - Destination SIP/SIPS/TEL URI Egress and > > Ingress Routes > > > - Relevant route names, identifiers, and services > > > - NAPTR context and associations > > > > When you exchange data, it may be in the form of a NAPTR in > syntax and > > > maybe even semantics, but it's not really a "NAPTR" DNS entry - it > > just happens to be that you chose to format the resultant route > > information in the form of a NAPTR. So I think the word "NAPTR" > > shouldn't be in the charter's list of data to be exchanged. We may > > just happen to use that format in the end for the data, but there's > > nothing about the data that demands it. (and in fact I personally > > think it's confusing and misleading to be using that > specific format > > in the data exchange directly, but we can argue about that later :) > > > > > > > + Service Areas > > > - Individual, ranges, or groups of ENUMservice > > > identifiers > > > - Route associations > > > > I don't know what a "Route association" is? > > > > > > > + Treatment Profiles > > > - Priority > > > - Location > > > > I note this doesn't directly include originating or source > > information, which is fairly essential to SIP routing, afaict. Is > > that something you'd classify under "route associations" or > "treatment > > > profiles", or do you specifically not want that in the charter? > > > > -hadriel > > _______________________________________________ > > 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 6BB043A6A32; Wed, 23 Apr 2008 09:59:59 -0700 (PDT) X-Original-To: peppermint@core3.amsl.com Delivered-To: peppermint@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 752E83A6A32 for ; Wed, 23 Apr 2008 09:59:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xBOrudEcxoZk for ; Wed, 23 Apr 2008 09:59:57 -0700 (PDT) Received: from omzesmtp03a.verizonbusiness.com (omzesmtp03a.verizonbusiness.com [199.249.25.201]) by core3.amsl.com (Postfix) with ESMTP id 748B63A6937 for ; Wed, 23 Apr 2008 09:59:57 -0700 (PDT) Received: from pmismtp04.wcomnet.com ([166.37.158.164]) by firewall.verizonbusiness.com (Sun Java(tm) System Messaging Server 6.3-5.02 (built Oct 12 2007; 32bit)) with ESMTP id <0JZS00A21F82RC00@firewall.verizonbusiness.com> for peppermint@ietf.org; Wed, 23 Apr 2008 17:00:02 +0000 (GMT) Received: from pmismtp04.wcomnet.com ([127.0.0.1]) by pmismtp04.mcilink.com (iPlanet Messaging Server 5.2 HotFix 2.08 (built Sep 22 2005)) with SMTP id <0JZS00FI5F829P@pmismtp04.mcilink.com> for peppermint@ietf.org; Wed, 23 Apr 2008 17:00:02 +0000 (GMT) Received: from ASHSRV140.mcilink.com ([153.39.68.166]) by pmismtp04.mcilink.com (iPlanet Messaging Server 5.2 HotFix 2.08 (built Sep 22 2005)) with ESMTP id <0JZS00EE6F7WCY@pmismtp04.mcilink.com> for peppermint@ietf.org; Wed, 23 Apr 2008 17:00:01 +0000 (GMT) Received: from ASHEVS002.mcilink.com ([153.39.71.1]) by ASHSRV140.mcilink.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 23 Apr 2008 16:59:56 +0000 Date: Wed, 23 Apr 2008 16:59:54 +0000 From: "Dwight, Timothy M (Tim)" In-reply-to: <160DE07A1C4F8E4AA2715DEC577DA491936566@srvxchg3.cablelabs.com> To: Daryl Malas , Hadriel Kaplan , Richard Shockey , Otmar Lendl , peppermint@ietf.org Message-id: <092B2658AAB56A4D80836399A4C4703104526E1F@ASHEVS002.mcilink.com> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message Thread-topic: [PEPPERMINT] DRINKS PROPOSED Charter ..comments please. Thread-index: Acikh2EScAYa3BvkRuqoFaN0JnBW6gAAkqtQAAKgAAAAAJ+XUAAA2ISwABUcBLAAGvG54AABAsIgAACdg7AAACqXoAAATdLA X-MS-Has-Attach: X-MS-TNEF-Correlator: References: <125b01c89fe6$14f823c0$3ee86b40$@us> <20080419210654.GA30568@nic.at> <20080420211101.GA32096@nic.at> <1a6601c8a3dd$49ca8c50$dd5fa4f0$@us> <20080422144452.GA582@nic.at> <14b501c8a495$758aeb60$60a0c220$@us> <160DE07A1C4F8E4AA2715DEC577DA49193654F@srvxchg3.cablelabs.com> <154801c8a49b$22fbc2b0$68f34810$@us> <160DE07A1C4F8E4AA2715DEC577DA491936564@srvxchg3.cablelabs.com> <092B2658AAB56A4D80836399A4C4703104526DBE@ASHEVS002.mcilink.com> <160DE07A1C4F8E4AA2715DEC577DA491936566@srvxchg3.cablelabs.com> X-OriginalArrivalTime: 23 Apr 2008 16:59:56.0077 (UTC) FILETIME=[74D8CDD0:01C8A563] Subject: Re: [PEPPERMINT] DRINKS PROPOSED Charter ..comments please. 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 Well, limiting the scope sounds good. But on what basis do we limit it? How do we know that a proposed data model supports anything useful? I assume that proponents of a particular model will have some use case(s) in mind. So why not state them explicitly? Then we can discuss whether the resulting set of problems to be solved, is sufficient (and sufficiently bounded). To me this is simply an issue of determining requirements before we settle on an implementation. Settling on an implementation (data model) first, will have the effect of bounding the set of requirements we might satisfy. But doesn't that seem backward? Tim > -----Original Message----- > From: Daryl Malas [mailto:D.Malas@cablelabs.com] > Sent: Wednesday, April 23, 2008 11:48 AM > To: Dwight, Timothy M (Tim); Hadriel Kaplan; Richard Shockey; > Otmar Lendl; peppermint@ietf.org > Subject: RE: [PEPPERMINT] DRINKS PROPOSED Charter ..comments please. > > I think the purpose here is to contain the scope of the charter. The > subsequent use cases will then be limited to the scope of the charter. > If you do not clearly define the scope, then the use cases can run all > over the place. If this occurs, it just creates many years > of debate, a > very frustrated set of co-chairs and working group. > > I think this is the right approach, but we need to be careful > to balance > putting enough detail in to clearly contain the scope without too much > detail as to make the charter a working group draft. > > --Daryl > > -----Original Message----- > From: Dwight, Timothy M (Tim) > [mailto:timothy.dwight@verizonbusiness.com] > Sent: Wednesday, April 23, 2008 10:43 AM > To: Hadriel Kaplan; Daryl Malas; Richard Shockey; Otmar Lendl; > peppermint@ietf.org > Subject: RE: [PEPPERMINT] DRINKS PROPOSED Charter ..comments please. > > Do we have to determine the data model now? This seems premature when > we've not yet considered use cases. > > Tim > > > > -----Original Message----- > > From: peppermint-bounces@ietf.org > > [mailto:peppermint-bounces@ietf.org] On Behalf Of Hadriel Kaplan > > Sent: Wednesday, April 23, 2008 11:34 AM > > To: Daryl Malas; Richard Shockey; Otmar Lendl; peppermint@ietf.org > > Subject: Re: [PEPPERMINT] DRINKS PROPOSED Charter ..comments please. > > > > > > > > > -----Original Message----- > > > From: Daryl Malas [mailto:D.Malas@cablelabs.com] > > > > > > I recommend we further simplify: > > > > > > The scope will be limited to defining the following > > criteria necessary > > > for a SSP to respond with the necessary Session > > Establishment Data (SED) > > > for both internal and external purposes: > > > > OK, so here you're defining the minimal data needed to be > exchanged by > > > DRINKS, in order for an SSP to provide SED - right? > > > > > > > + Routes > > > - Destination SIP/SIPS/TEL URI Egress and > > Ingress Routes > > > - Relevant route names, identifiers, and services > > > - NAPTR context and associations > > > > When you exchange data, it may be in the form of a NAPTR in > syntax and > > > maybe even semantics, but it's not really a "NAPTR" DNS entry - it > > just happens to be that you chose to format the resultant route > > information in the form of a NAPTR. So I think the word "NAPTR" > > shouldn't be in the charter's list of data to be exchanged. We may > > just happen to use that format in the end for the data, but there's > > nothing about the data that demands it. (and in fact I personally > > think it's confusing and misleading to be using that > specific format > > in the data exchange directly, but we can argue about that later :) > > > > > > > + Service Areas > > > - Individual, ranges, or groups of ENUMservice > > > identifiers > > > - Route associations > > > > I don't know what a "Route association" is? > > > > > > > + Treatment Profiles > > > - Priority > > > - Location > > > > I note this doesn't directly include originating or source > > information, which is fairly essential to SIP routing, afaict. Is > > that something you'd classify under "route associations" or > "treatment > > > profiles", or do you specifically not want that in the charter? > > > > -hadriel > > _______________________________________________ > > 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 7B63D3A6D3F; Wed, 23 Apr 2008 09:48:27 -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 1C3453A6D3F for ; Wed, 23 Apr 2008 09:48:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.223 X-Spam-Level: X-Spam-Status: No, score=-0.223 tagged_above=-999 required=5 tests=[AWL=0.240, 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 Sbn7nIapN67V for ; Wed, 23 Apr 2008 09:48:25 -0700 (PDT) Received: from ondar.cablelabs.com (ondar.cablelabs.com [192.160.73.61]) by core3.amsl.com (Postfix) with ESMTP id 363BD3A68CC for ; Wed, 23 Apr 2008 09:48:25 -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 m3NGmTaC013579; Wed, 23 Apr 2008 10:48:30 -0600 Received: from srvxchg3.cablelabs.com (10.5.0.25) by kyzyl.cablelabs.com (F-Secure/fsigk_smtp/511/kyzyl.cablelabs.com); Wed, 23 Apr 2008 10:48:29 -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, 23 Apr 2008 10:48:29 -0600 Message-ID: <160DE07A1C4F8E4AA2715DEC577DA491936566@srvxchg3.cablelabs.com> In-Reply-To: <092B2658AAB56A4D80836399A4C4703104526DBE@ASHEVS002.mcilink.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [PEPPERMINT] DRINKS PROPOSED Charter ..comments please. Thread-Index: Acikh2EScAYa3BvkRuqoFaN0JnBW6gAAkqtQAAKgAAAAAJ+XUAAA2ISwABUcBLAAGvG54AABAsIgAACdg7AAACqXoA== References: <125b01c89fe6$14f823c0$3ee86b40$@us> <20080419210654.GA30568@nic.at> <20080420211101.GA32096@nic.at> <1a6601c8a3dd$49ca8c50$dd5fa4f0$@us> <20080422144452.GA582@nic.at> <14b501c8a495$758aeb60$60a0c220$@us> <160DE07A1C4F8E4AA2715DEC577DA49193654F@srvxchg3.cablelabs.com> <154801c8a49b$22fbc2b0$68f34810$@us> <160DE07A1C4F8E4AA2715DEC577DA491936564@srvxchg3.cablelabs.com> <092B2658AAB56A4D80836399A4C4703104526DBE@ASHEVS002.mcilink.com> From: "Daryl Malas" To: "Dwight, Timothy M (Tim)" , "Hadriel Kaplan" , "Richard Shockey" , "Otmar Lendl" , X-Approved: ondar Subject: Re: [PEPPERMINT] DRINKS PROPOSED Charter ..comments please. 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 think the purpose here is to contain the scope of the charter. The subsequent use cases will then be limited to the scope of the charter. If you do not clearly define the scope, then the use cases can run all over the place. If this occurs, it just creates many years of debate, a very frustrated set of co-chairs and working group. I think this is the right approach, but we need to be careful to balance putting enough detail in to clearly contain the scope without too much detail as to make the charter a working group draft. --Daryl -----Original Message----- From: Dwight, Timothy M (Tim) [mailto:timothy.dwight@verizonbusiness.com] Sent: Wednesday, April 23, 2008 10:43 AM To: Hadriel Kaplan; Daryl Malas; Richard Shockey; Otmar Lendl; peppermint@ietf.org Subject: RE: [PEPPERMINT] DRINKS PROPOSED Charter ..comments please. Do we have to determine the data model now? This seems premature when we've not yet considered use cases. Tim > -----Original Message----- > From: peppermint-bounces@ietf.org > [mailto:peppermint-bounces@ietf.org] On Behalf Of Hadriel Kaplan > Sent: Wednesday, April 23, 2008 11:34 AM > To: Daryl Malas; Richard Shockey; Otmar Lendl; peppermint@ietf.org > Subject: Re: [PEPPERMINT] DRINKS PROPOSED Charter ..comments please. > > > > > -----Original Message----- > > From: Daryl Malas [mailto:D.Malas@cablelabs.com] > > > > I recommend we further simplify: > > > > The scope will be limited to defining the following > criteria necessary > > for a SSP to respond with the necessary Session > Establishment Data (SED) > > for both internal and external purposes: > > OK, so here you're defining the minimal data needed to be exchanged by > DRINKS, in order for an SSP to provide SED - right? > > > > + Routes > > - Destination SIP/SIPS/TEL URI Egress and > Ingress Routes > > - Relevant route names, identifiers, and services > > - NAPTR context and associations > > When you exchange data, it may be in the form of a NAPTR in syntax and > maybe even semantics, but it's not really a "NAPTR" DNS entry - it > just happens to be that you chose to format the resultant route > information in the form of a NAPTR. So I think the word "NAPTR" > shouldn't be in the charter's list of data to be exchanged. We may > just happen to use that format in the end for the data, but there's > nothing about the data that demands it. (and in fact I personally > think it's confusing and misleading to be using that specific format > in the data exchange directly, but we can argue about that later :) > > > > + Service Areas > > - Individual, ranges, or groups of ENUMservice > > identifiers > > - Route associations > > I don't know what a "Route association" is? > > > > + Treatment Profiles > > - Priority > > - Location > > I note this doesn't directly include originating or source > information, which is fairly essential to SIP routing, afaict. Is > that something you'd classify under "route associations" or "treatment > profiles", or do you specifically not want that in the charter? > > -hadriel > _______________________________________________ > 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 0CFF83A69DD; Wed, 23 Apr 2008 09:45:10 -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 5DD753A68E0 for ; Wed, 23 Apr 2008 09:45:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.163 X-Spam-Level: X-Spam-Status: No, score=-0.163 tagged_above=-999 required=5 tests=[AWL=0.300, 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 0WoagqR+EYS1 for ; Wed, 23 Apr 2008 09:45:03 -0700 (PDT) Received: from ondar.cablelabs.com (ondar.cablelabs.com [192.160.73.61]) by core3.amsl.com (Postfix) with ESMTP id DF70E3A6B55 for ; Wed, 23 Apr 2008 09:45:02 -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 m3NGj7nF013275; Wed, 23 Apr 2008 10:45:07 -0600 Received: from srvxchg3.cablelabs.com (10.5.0.25) by kyzyl.cablelabs.com (F-Secure/fsigk_smtp/511/kyzyl.cablelabs.com); Wed, 23 Apr 2008 10:45:07 -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, 23 Apr 2008 10:45:06 -0600 Message-ID: <160DE07A1C4F8E4AA2715DEC577DA491936565@srvxchg3.cablelabs.com> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [PEPPERMINT] DRINKS PROPOSED Charter ..comments please. Thread-Index: Acikh2EScAYa3BvkRuqoFaN0JnBW6gAAkqtQAAKgAAAAAJ+XUAAA2ISwABUcBLAAGvG54AABAsIgAACmdHA= References: <125b01c89fe6$14f823c0$3ee86b40$@us><20080419210654.GA30568@nic.at><20080420211101.GA32096@nic.at><1a6601c8a3dd$49ca8c50$dd5fa4f0$@us><20080422144452.GA582@nic.at> <14b501c8a495$758aeb60$60a0c220$@us> <160DE07A1C4F8E4AA2715DEC577DA49193654F@srvxchg3.cablelabs.com> <154801c8a49b$22fbc2b0$68f34810$@us> <160DE07A1C4F8E4AA2715DEC577DA491936564@srvxchg3.cablelabs.com> From: "Daryl Malas" To: "Hadriel Kaplan" , "Richard Shockey" , "Otmar Lendl" , X-Approved: ondar Subject: Re: [PEPPERMINT] DRINKS PROPOSED Charter ..comments please. 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 Comments in-line... -----Original Message----- From: Hadriel Kaplan [mailto:HKaplan@acmepacket.com] Sent: Wednesday, April 23, 2008 10:34 AM To: Daryl Malas; Richard Shockey; Otmar Lendl; peppermint@ietf.org Subject: RE: [PEPPERMINT] DRINKS PROPOSED Charter ..comments please. > -----Original Message----- > From: Daryl Malas [mailto:D.Malas@cablelabs.com] > > I recommend we further simplify: > > The scope will be limited to defining the following criteria necessary > for a SSP to respond with the necessary Session Establishment Data > (SED) for both internal and external purposes: OK, so here you're defining the minimal data needed to be exchanged by DRINKS, in order for an SSP to provide SED - right? [DM] Yes. > + Routes > - Destination SIP/SIPS/TEL URI Egress and Ingress Routes > - Relevant route names, identifiers, and services > - NAPTR context and associations When you exchange data, it may be in the form of a NAPTR in syntax and maybe even semantics, but it's not really a "NAPTR" DNS entry - it just happens to be that you chose to format the resultant route information in the form of a NAPTR. So I think the word "NAPTR" shouldn't be in the charter's list of data to be exchanged. We may just happen to use that format in the end for the data, but there's nothing about the data that demands it. (and in fact I personally think it's confusing and misleading to be using that specific format in the data exchange directly, but we can argue about that later :) [DM] Ok...do not use NAPTR. > + Service Areas > - Individual, ranges, or groups of ENUMservice > identifiers > - Route associations I don't know what a "Route association" is? [DM] This is associating a "Service Area" to an Ingress or Egress Route as will be defined in the previous point "Routes". > + Treatment Profiles > - Priority > - Location I note this doesn't directly include originating or source information, which is fairly essential to SIP routing, afaict. Is that something you'd classify under "route associations" or "treatment profiles", or do you specifically not want that in the charter? [DM] The purpose is source or destination information is defined under "Routes". Treatment is then applied under Treatment Profiles. -hadriel _______________________________________________ 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 1D05A3A6B84; Wed, 23 Apr 2008 09:42:38 -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 5B2E928C1E2 for ; Wed, 23 Apr 2008 09:42:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8ICZo9XXH1mY for ; Wed, 23 Apr 2008 09:42:36 -0700 (PDT) Received: from omzesmtp03a.verizonbusiness.com (omzesmtp03a.verizonbusiness.com [199.249.25.201]) by core3.amsl.com (Postfix) with ESMTP id 78D1F28C203 for ; Wed, 23 Apr 2008 09:42:36 -0700 (PDT) Received: from dgismtp04.wcomnet.com ([166.38.58.144]) by firewall.verizonbusiness.com (Sun Java(tm) System Messaging Server 6.3-5.02 (built Oct 12 2007; 32bit)) with ESMTP id <0JZS009G2EF5JR00@firewall.verizonbusiness.com> for peppermint@ietf.org; Wed, 23 Apr 2008 16:42:41 +0000 (GMT) Received: from dgismtp04.wcomnet.com ([127.0.0.1]) by dgismtp04.mcilink.com (iPlanet Messaging Server 5.2 HotFix 2.08 (built Sep 22 2005)) with SMTP id <0JZS00HLEEF504@dgismtp04.mcilink.com> for peppermint@ietf.org; Wed, 23 Apr 2008 16:42:41 +0000 (GMT) Received: from ASHSRV141.mcilink.com ([153.39.68.167]) by dgismtp04.mcilink.com (iPlanet Messaging Server 5.2 HotFix 2.08 (built Sep 22 2005)) with ESMTP id <0JZS00H03EF4LY@dgismtp04.mcilink.com> for peppermint@ietf.org; Wed, 23 Apr 2008 16:42:41 +0000 (GMT) Received: from ASHEVS002.mcilink.com ([153.39.71.1]) by ASHSRV141.mcilink.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 23 Apr 2008 16:42:37 +0000 Date: Wed, 23 Apr 2008 16:42:36 +0000 From: "Dwight, Timothy M (Tim)" In-reply-to: To: Hadriel Kaplan , Daryl Malas , Richard Shockey , Otmar Lendl , peppermint@ietf.org Message-id: <092B2658AAB56A4D80836399A4C4703104526DBE@ASHEVS002.mcilink.com> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message Thread-topic: [PEPPERMINT] DRINKS PROPOSED Charter ..comments please. Thread-index: Acikh2EScAYa3BvkRuqoFaN0JnBW6gAAkqtQAAKgAAAAAJ+XUAAA2ISwABUcBLAAGvG54AABAsIgAACdg7A= X-MS-Has-Attach: X-MS-TNEF-Correlator: References: <125b01c89fe6$14f823c0$3ee86b40$@us> <20080419210654.GA30568@nic.at> <20080420211101.GA32096@nic.at> <1a6601c8a3dd$49ca8c50$dd5fa4f0$@us> <20080422144452.GA582@nic.at> <14b501c8a495$758aeb60$60a0c220$@us> <160DE07A1C4F8E4AA2715DEC577DA49193654F@srvxchg3.cablelabs.com> <154801c8a49b$22fbc2b0$68f34810$@us> <160DE07A1C4F8E4AA2715DEC577DA491936564@srvxchg3.cablelabs.com> X-OriginalArrivalTime: 23 Apr 2008 16:42:37.0126 (UTC) FILETIME=[09957660:01C8A561] Subject: Re: [PEPPERMINT] DRINKS PROPOSED Charter ..comments please. 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 Do we have to determine the data model now? This seems premature when we've not yet considered use cases. Tim > -----Original Message----- > From: peppermint-bounces@ietf.org > [mailto:peppermint-bounces@ietf.org] On Behalf Of Hadriel Kaplan > Sent: Wednesday, April 23, 2008 11:34 AM > To: Daryl Malas; Richard Shockey; Otmar Lendl; peppermint@ietf.org > Subject: Re: [PEPPERMINT] DRINKS PROPOSED Charter ..comments please. > > > > > -----Original Message----- > > From: Daryl Malas [mailto:D.Malas@cablelabs.com] > > > > I recommend we further simplify: > > > > The scope will be limited to defining the following > criteria necessary > > for a SSP to respond with the necessary Session > Establishment Data (SED) > > for both internal and external purposes: > > OK, so here you're defining the minimal data needed to be > exchanged by DRINKS, in order for an SSP to provide SED - right? > > > > + Routes > > - Destination SIP/SIPS/TEL URI Egress and > Ingress Routes > > - Relevant route names, identifiers, and services > > - NAPTR context and associations > > When you exchange data, it may be in the form of a NAPTR in > syntax and maybe even semantics, but it's not really a > "NAPTR" DNS entry - it just happens to be that you chose to > format the resultant route information in the form of a > NAPTR. So I think the word "NAPTR" shouldn't be in the > charter's list of data to be exchanged. We may just happen > to use that format in the end for the data, but there's > nothing about the data that demands it. (and in fact I > personally think it's confusing and misleading to be using > that specific format in the data exchange directly, but we > can argue about that later :) > > > > + Service Areas > > - Individual, ranges, or groups of ENUMservice > > identifiers > > - Route associations > > I don't know what a "Route association" is? > > > > + Treatment Profiles > > - Priority > > - Location > > I note this doesn't directly include originating or source > information, which is fairly essential to SIP routing, > afaict. Is that something you'd classify under "route > associations" or "treatment profiles", or do you specifically > not want that in the charter? > > -hadriel > _______________________________________________ > 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 7DA543A6C6A; Wed, 23 Apr 2008 09:37: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 981E13A6BE8 for ; Wed, 23 Apr 2008 09:37:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.539 X-Spam-Level: X-Spam-Status: No, score=-2.539 tagged_above=-999 required=5 tests=[AWL=0.060, 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 InsJM7WcLE8b for ; Wed, 23 Apr 2008 09:37:11 -0700 (PDT) Received: from etmail.acmepacket.com (etmail.acmepacket.com [216.41.24.6]) by core3.amsl.com (Postfix) with ESMTP id AE0953A6A4F for ; Wed, 23 Apr 2008 09:37:11 -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.263.0; Wed, 23 Apr 2008 12:36:45 -0400 Received: from mail.acmepacket.com ([216.41.24.7]) by mail.acmepacket.com ([216.41.24.7]) with mapi; Wed, 23 Apr 2008 12:36:45 -0400 From: Hadriel Kaplan To: Daryl Malas , Richard Shockey , Otmar Lendl , "peppermint@ietf.org" Date: Wed, 23 Apr 2008 12:34:00 -0400 Thread-Topic: [PEPPERMINT] DRINKS PROPOSED Charter ..comments please. Thread-Index: Acikh2EScAYa3BvkRuqoFaN0JnBW6gAAkqtQAAKgAAAAAJ+XUAAA2ISwABUcBLAAGvG54AABAsIg Message-ID: References: <125b01c89fe6$14f823c0$3ee86b40$@us><20080419210654.GA30568@nic.at><20080420211101.GA32096@nic.at> <1a6601c8a3dd$49ca8c50$dd5fa4f0$@us><20080422144452.GA582@nic.at> <14b501c8a495$758aeb60$60a0c220$@us> <160DE07A1C4F8E4AA2715DEC577DA49193654F@srvxchg3.cablelabs.com> <154801c8a49b$22fbc2b0$68f34810$@us> <160DE07A1C4F8E4AA2715DEC577DA491936564@srvxchg3.cablelabs.com> In-Reply-To: <160DE07A1C4F8E4AA2715DEC577DA491936564@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] DRINKS PROPOSED Charter ..comments please. X-BeenThere: peppermint@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Provisioning Extensions in Peering Registries for Multimedia INTerconnection List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: peppermint-bounces@ietf.org Errors-To: peppermint-bounces@ietf.org > -----Original Message----- > From: Daryl Malas [mailto:D.Malas@cablelabs.com] > > I recommend we further simplify: > > The scope will be limited to defining the following criteria necessary > for a SSP to respond with the necessary Session Establishment Data (SED) > for both internal and external purposes: OK, so here you're defining the minimal data needed to be exchanged by DRINKS, in order for an SSP to provide SED - right? > + Routes > - Destination SIP/SIPS/TEL URI Egress and Ingress Routes > - Relevant route names, identifiers, and services > - NAPTR context and associations When you exchange data, it may be in the form of a NAPTR in syntax and maybe even semantics, but it's not really a "NAPTR" DNS entry - it just happens to be that you chose to format the resultant route information in the form of a NAPTR. So I think the word "NAPTR" shouldn't be in the charter's list of data to be exchanged. We may just happen to use that format in the end for the data, but there's nothing about the data that demands it. (and in fact I personally think it's confusing and misleading to be using that specific format in the data exchange directly, but we can argue about that later :) > + Service Areas > - Individual, ranges, or groups of ENUMservice > identifiers > - Route associations I don't know what a "Route association" is? > + Treatment Profiles > - Priority > - Location I note this doesn't directly include originating or source information, which is fairly essential to SIP routing, afaict. Is that something you'd classify under "route associations" or "treatment profiles", or do you specifically not want that in the charter? -hadriel _______________________________________________ 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 5C6303A6C22; Wed, 23 Apr 2008 09:25: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 85B293A6C22 for ; Wed, 23 Apr 2008 09:25:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.532 X-Spam-Level: X-Spam-Status: No, score=-2.532 tagged_above=-999 required=5 tests=[AWL=0.067, 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 CjaV1LFqWORc for ; Wed, 23 Apr 2008 09:25:11 -0700 (PDT) Received: from etmail.acmepacket.com (etmail.acmepacket.com [216.41.24.6]) by core3.amsl.com (Postfix) with ESMTP id 89A9B3A6979 for ; Wed, 23 Apr 2008 09:25:11 -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.263.0; Wed, 23 Apr 2008 12:24:45 -0400 Received: from mail.acmepacket.com ([216.41.24.7]) by mail.acmepacket.com ([216.41.24.7]) with mapi; Wed, 23 Apr 2008 12:24:45 -0400 From: Hadriel Kaplan To: Otmar Lendl , Richard Shockey Date: Wed, 23 Apr 2008 12:22:00 -0400 Thread-Topic: [PEPPERMINT] DRINKS PROPOSED Charter ..comments please. Thread-Index: AcilWF1uhhY+C3oyQsiygXff0KnW7wAAYTGA Message-ID: References: <125b01c89fe6$14f823c0$3ee86b40$@us> <20080419210654.GA30568@nic.at> <20080420211101.GA32096@nic.at> <1a6601c8a3dd$49ca8c50$dd5fa4f0$@us> <14b501c8a495$758aeb60$60a0c220$@us> <160DE07A1C4F8E4AA2715DEC577DA49193654F@srvxchg3.cablelabs.com> <154801c8a49b$22fbc2b0$68f34810$@us> <0c9501c8a552$480c0df0$d82429d0$@us> <20080423154056.GA2316@nic.at> In-Reply-To: <20080423154056.GA2316@nic.at> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US MIME-Version: 1.0 Cc: 'Daryl Malas' , "peppermint@ietf.org" Subject: Re: [PEPPERMINT] DRINKS PROPOSED Charter ..comments please. X-BeenThere: peppermint@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Provisioning Extensions in Peering Registries for Multimedia INTerconnection List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: peppermint-bounces@ietf.org Errors-To: peppermint-bounces@ietf.org > -----Original Message----- > From: Otmar Lendl [mailto:lendl@labs.nic.at] On Behalf Of Otmar Lendl > Sent: Wednesday, April 23, 2008 11:41 AM > > On 2008/04/23 16:04, Richard Shockey wrote: > > > > > > More specifically, the SED is the set of parameters that the local > > > SSP needs to complete the call, through its egress SBE's, and may > > > include: > > > > Number ranges? > > As it is defined, SED is what you get from the mapping step, not the > mapping itself. > > Number ranges (or individual numbers) are the key under which SED is > stored. > > (In the case where ENUM is the access protocol, SED would be whatever is > contained in the NAPTR. The number ranges don't appear there, they are > only relevant for selecting the right NAPTR records from the DNS tree.) Yes exactly - afaik, the SED is the result of the lookup, vs. the keys for the lookup; but a couple people actually sent me email asking why number ranges weren't in the list, so maybe that's not a common definition. (and the keys do overlap with the results) In reading the terminology draft it sure sounds like SED is returned by the LRF, not used for LUF/LRF lookups. I think though what you're looking for is a minimal list of the data which needs to be exchanged between providers or between provider-regstry? (ie, the both lookup keys and results) Then I think a starting list would be like: . Destination matching criteria, possibly of one or more of the following: o An E.164 number, number range, or prefix o A domain name or FQDN . One or more originating qualifiers, possibly including one or more of the following o A source SIP/SIPS/TEL URI match filter o A source domain identified as an SSP-ID o Source geographic or topological identifiers . A SIP next-hop/next-hop-group to send the request to, possibly including one or more of the following: o Fully Qualified Domain Name (FQDN) o Learned/static SIP Route headers for the peer SSP . A resolved terminating domain identifier, which may include: o The terminating domain identified as a Domain Name o The terminating domain identified as an SSP-ID o One or more parameters indicating ported number resolution . Optional resource control parameters such as o Resource priority value(s) for the call o Geographic or topological identifiers Note there are plenty of other matching criteria used today, such as time of day, originating and destination trunk groups, method type, session type, media type, codec types, etc. But I'm hoping we can avoid those for now. -hadriel _______________________________________________ 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 491E83A6C0E; Wed, 23 Apr 2008 09:22: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 2B34C3A6DD8 for ; Wed, 23 Apr 2008 09:22:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.137 X-Spam-Level: X-Spam-Status: No, score=0.137 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_00=-2.599, HELO_EQ_MODEMCABLE=0.768, HOST_EQ_MODEMCABLE=1.368, J_CHICKENPOX_32=0.6] 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 j9IaI3CJmwID for ; Wed, 23 Apr 2008 09:22:34 -0700 (PDT) Received: from ondar.cablelabs.com (ondar.cablelabs.com [192.160.73.61]) by core3.amsl.com (Postfix) with ESMTP id 414CF28C2F4 for ; Wed, 23 Apr 2008 09:21:52 -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 m3NGLuT0011583; Wed, 23 Apr 2008 10:21:56 -0600 Received: from srvxchg3.cablelabs.com (10.5.0.25) by kyzyl.cablelabs.com (F-Secure/fsigk_smtp/511/kyzyl.cablelabs.com); Wed, 23 Apr 2008 10:21:56 -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, 23 Apr 2008 10:21:56 -0600 Message-ID: <160DE07A1C4F8E4AA2715DEC577DA491936564@srvxchg3.cablelabs.com> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [PEPPERMINT] DRINKS PROPOSED Charter ..comments please. Thread-Index: Acikh2EScAYa3BvkRuqoFaN0JnBW6gAAkqtQAAKgAAAAAJ+XUAAA2ISwABUcBLAAGvG54A== References: <125b01c89fe6$14f823c0$3ee86b40$@us><20080419210654.GA30568@nic.at><20080420211101.GA32096@nic.at> <1a6601c8a3dd$49ca8c50$dd5fa4f0$@us><20080422144452.GA582@nic.at> <14b501c8a495$758aeb60$60a0c220$@us> <160DE07A1C4F8E4AA2715DEC577DA49193654F@srvxchg3.cablelabs.com> <154801c8a49b$22fbc2b0$68f34810$@us> From: "Daryl Malas" To: "Hadriel Kaplan" , "Richard Shockey" , "Otmar Lendl" , X-Approved: ondar Subject: Re: [PEPPERMINT] DRINKS PROPOSED Charter ..comments please. 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 recommend we further simplify: The scope will be limited to defining the following criteria necessary for a SSP to respond with the necessary Session Establishment Data (SED) for both internal and external purposes: + Routes - Destination SIP/SIPS/TEL URI Egress and Ingress Routes - Relevant route names, identifiers, and services - NAPTR context and associations + Service Areas - Individual, ranges, or groups of ENUMservice identifiers - Route associations + Treatment Profiles - Priority - Location --Daryl -----Original Message----- From: Hadriel Kaplan [mailto:HKaplan@acmepacket.com] Sent: Tuesday, April 22, 2008 11:20 PM To: Richard Shockey; Daryl Malas; 'Otmar Lendl'; peppermint@ietf.org Subject: RE: [PEPPERMINT] DRINKS PROPOSED Charter ..comments please. Huh. So we need to bound the data being exchanged - got that. But the tricky part about this is picking what data now, without yet getting into the arguments of how this will work. For example, the type of "SED" data described in section 3.3 of terminology draft is not that high on the list of things I would expect to be exchanged or resolved by a LUF or LRF query. Well... that's not totally true, but it's not sufficient data to make peering work at the SBE-SBE connection level, and some of those particular connection-specific details frankly aren't dynamic that way (ie, per route) and probably shouldn't/couldn't be. What about something more like: Session Establishment Data, or SED, is the data used to route a call to the next hop domain's ingress point, on its way to the called terminating domain. A domain's ingress point can be thought of as the location derived from the NAPTR/SRV/A record [1] that resulted from the resolution of the SIP URI. More specifically, the SED is the set of parameters that the local SSP needs to complete the call, through its egress SBE's, and may include: . A destination SIP/SIPS/TEL URI . A SIP next-hop/next-hop-group to send the request to, possibly including one or more of the following: o Fully Qualified Domain Name (FQDN) o Trunk Group and Context (IPTEL WG) o Learned/static SIP Route headers for the peer SSP . A resolved terminating domain identifier, which may include: o The terminating domain identified as a Domain Name o The terminating domain identified as an SSP-ID o One or more parameters indicating ported number resolution . Optional resource control parameters such as o Resource priority value(s) for the call o Geographic or topological identifiers -hadriel > -----Original Message----- > From: Richard Shockey [mailto:richard@shockey.us] > > Basically the subject headers are sufficient for what we should be > looking at. But with specific exclusions... rating information, for > instance, should explicitly be excluded from a first pass at a WG > charter. > > ***************** > > 3.3. Session Establishment Data > > Session Establishment Data, or SED, is the data used to route a call > to the next hop associated with the called domain's ingress point. A > domain's ingress point can be thought of as the location derived from > the NAPTR/SRV/A record [1] that resulted from the resolution of the > SIP URI. > > More specifically, the SED is the set of parameters that the outgoing > SBEs need to complete the call, and may include: > > . A destination SIP URI > > . A SIP proxy or ingress SBE to send the INVITE to, including > > o Fully Qualified Domain Name (FQDN) > > o Port > > o Transport Protocol (UDP/TCP/TLS [9/10/11]) > > . Security Parameters, including > > o TLS certificate to use > > o TLS certificate to expect > > o TLS certificate verification setting > > . Optional resource control parameters such as > > o Limits on the total number of call initiations to a peer > > o Limits on SIP transactions/second > > > > > > > --Daryl > > > > -----Original Message----- > > From: peppermint-bounces@ietf.org > > [mailto:peppermint-bounces@ietf.org] > > On Behalf Of Richard Shockey > > Sent: Tuesday, April 22, 2008 10:25 AM > > To: 'Hadriel Kaplan'; 'Otmar Lendl'; peppermint@ietf.org > > Subject: Re: [PEPPERMINT] DRINKS PROPOSED Charter ..comments please. > > > > Thank you Hadriel. > > > > Now after some conversations with our AD, I think we are in good > > shape with the charter as its currently written including the rename. > > > > There is some clarification in the text I'll fix however there is a > > strong suggestion that that we specify a more detailed list of SED > > data to be addressed. That means expanding out this sentence below > > somewhat. > > We don't need a exhaustive list only a list that sufficiently > > bounds the work to be undertaken. In other words, the AD don't > > want us wandering off the reservation. > > > > "Typical SED data includes the mapping of phone numbers to URIs, > > policies surrounding admission to various points of network > > interconnection, and various other types of interconnect data." > > > > Anyone want to suggest some text? > > > > > -----Original Message----- > > > From: peppermint-bounces@ietf.org > > > [mailto:peppermint-bounces@ietf.org] > > > On Behalf Of Hadriel Kaplan > > > Sent: Tuesday, April 22, 2008 11:19 AM > To: Otmar Lendl; > > peppermint@ietf.org > Subject: Re: [PEPPERMINT] DRINKS PROPOSED > > Charter ..comments please. > > > > > > Hi Otmar, > > > I don't disagree with some or many of our points, but I don't > > think > we need to hash them out for the charter. I think we can > > discuss > these in the actual WG, after the charter is approved. > > Nothing in > the charter limits our ability to do that as far as I can tell. > > > (right?) > > > > > > -hadriel > > > > > > > > > > -----Original Message----- > > > > From: peppermint-bounces@ietf.org [mailto:peppermint- > > > bounces@ietf.org] On > Behalf Of Otmar Lendl > Sent: Tuesday, > > April > 22, 2008 10:45 AM > To: peppermint@ietf.org > Subject: > > Re: > > > [PEPPERMINT] DRINKS PROPOSED Charter ..comments please. > > > > > > > > On 2008/04/21 20:04, Richard Shockey wrote: > > > > > > > > > > > > > > These administrative domains may be of any practical > > size > > > > > and > > > could be any type of SSP, such as recognized > > telephony > carriers, > > enterprises, > > > end- user > > > > > > > > groups, or > > > > > Federations. > > > > > > > > > > > > > > > > > > I think we have a problem here. IMHO we should not mix > > single > > > > > SSPs > > > (carriers, enterprises) with groups of SSPs > > > (federations). This > > > will bite us when doing the protocol > > > design. > > > > > > > > > > Why will this bit us? > > > > > > > > Because a SSP can be a member of multiple federations. Now, if > > you > > > > > plan > to build a registry similar to a LERG/NPAC database, then > > > you'll have to > deal with multiple federations inserting data > > about > > > > > the same numbers. > > > > > > > > That's the point where the registry moves from a store of > > > authoritative > information of "who owns a number" and perhaps > > "what > is the URI for the > number" to a distribution mechanism > > of routing > announcements, where > there can be multiple > > possible records > (=routes) per destination. > > > > > > > > This has a profound impact on the overall design. Imagine that > > a > domain > registry allows the provisioning of records > > concerning a > domain by > multiple registrars at the same time. > > Yes, it's possible > to build > a system based on this premise, > > but we need to make this > explicit. > > > > > > > > > > > I don't think that sentence restricts it, since it says > > > "could > > > > be" and we can later decide to restrict it > > further, > but yeah it's > > > > weird to think of a Federation > > as being an > SSP. > > > > > > > > > > > > Then let's take "federations" out of this definition NOW. > > > > > > > > > > I'm not convinced this is a problem. Frankly its splitting > > hairs > > > > > > > on terminology. I don't understand why a federations could > > not be > > > > > > > considered a SSP? But if there is consensus on taking it out .. > > > OK. > > > > > > > > A federation is defined as a set of SSPs. > > > > > > > > Any terminology where "X" and "set of X" is of the same type > > is > > likely to be flawed. (e.g. a "a flock of birds" cannot be a > > "bird") > > > > > > > > The notion of 'a registry' is well understood in this context. > > > Namely a > > > > > "trusted source of data" which multiple SSP internally or > > > externally may > > draw data from. Instead of SSP bi-laterally > > > exchanging data, which is > OK, > > SSP could use a registry to > > > aggregate their data for re- distribution. No > > different from > > > Domain Name operations or Centralized Numbering Databases > > > > like > the NPAC or the UK NICC. > > > > > > > > Fine. Then what about describing this in the charter properly. > > e.g. > > > by > > > > > > > > Administrative domains may exchange data directly between > > each > other > or might use an external registry (perhaps > > operated by a > federation) > > to aggregate data from multiple > > administrative domains into > a > single view. > > > > > > > > > A registry may be the 'trusted source of data' internal to > > the > network > as > > well that redistributes data to local > > databases or > caches. This is the > way > > the world works > > today in phone > networks. > > > > > > > > > > > > So the aim of peppermint^Wdrinks is to move the PSTN thinking > > and > > databases into an IP based setting? Will this be anything > > more than > > > > > just > porting the concepts behind LERG/NPAC/NICC/... to SIP? > > > > > > > > Will there be any innovation in call routing, or are we just > > > replacing > aging provisioning protocols with new ones, while > > > retaining the > dependency on unloved fat registries? > > > > > > > > As we're saying good-bye to the end2end principle for VoIP > > routing, > > > > > > is falling back to the PSTN way of routing calls really the > > path > > the IETF should be choosing? > > > > > > > > > > > > Other open questions: > > > > > > > > * Will DRINKS just consider "push" style provisioning protocols, > > > > or will DRINKS also look at on-demand lookup protocols towards > > > > these registries? > > > > > > > > * Speermint has separated out the LUF (who owns the destination?) > > > > from the LRF (What's my SED towards the destination network?). > > > > > > > > Given the fact that DRINKS is supposed to build upon speermint, > > > > can you make clear whether DRINKS is about the LUF or the LRF? > > > > > > > > Or are we mixing up these things *again*? > > > > > > > > > > > > That is sorely missing in speermint. > > > > > > > > > > > > > > Isn't that Speermint's role to do? (I'm not clear on > > that > either) > > > > > > > > Do you see such an item in the > > speermint milestones? I don't. > > > > > > > > > > > > IMHO we need something like RFC 1034 for the whole > > speermint / > > > > > > > > peppermint setup. > > > > > > > > > Well Hadriel is right ... that is a Speermint issue. > > > > > > > > So you want to define a set protocols without having a > > reference > > > > > > scenario against which to test whether the protocols do what we > > want? > > > > > > > > Good plan. > > > > > > > > As it has worked so brilliantly for speermint, we have to > > replicate > > > > > > it in DRINKs as well, don't we? > > > > > > > > /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 > > > _______________________________________________ > > > 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 7C9A228C30C; Wed, 23 Apr 2008 08:43:02 -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 2807D28C2F3 for ; Wed, 23 Apr 2008 08:43:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.508 X-Spam-Level: X-Spam-Status: No, score=-0.508 tagged_above=-999 required=5 tests=[AWL=0.322, BAYES_00=-2.599, HELO_EQ_AT=0.424, HOST_EQ_AT=0.745, J_CHICKENPOX_32=0.6] 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 V3r1BHLwQzV8 for ; Wed, 23 Apr 2008 08:42:57 -0700 (PDT) Received: from labs.nic.at (nat.labs.nic.at [83.136.33.3]) by core3.amsl.com (Postfix) with ESMTP id E386928C30C for ; Wed, 23 Apr 2008 08:41:00 -0700 (PDT) Received: from lendl by labs.nic.at with local (Exim 3.36 #1 (Debian)) id 1Joh5c-0000bX-00; Wed, 23 Apr 2008 17:40:56 +0200 Date: Wed, 23 Apr 2008 17:40:56 +0200 From: Otmar Lendl To: Richard Shockey Message-ID: <20080423154056.GA2316@nic.at> Mail-Followup-To: Otmar Lendl , Richard Shockey , 'Hadriel Kaplan' , 'Daryl Malas' , peppermint@ietf.org References: <125b01c89fe6$14f823c0$3ee86b40$@us> <20080419210654.GA30568@nic.at> <20080420211101.GA32096@nic.at> <1a6601c8a3dd$49ca8c50$dd5fa4f0$@us> <14b501c8a495$758aeb60$60a0c220$@us> <160DE07A1C4F8E4AA2715DEC577DA49193654F@srvxchg3.cablelabs.com> <154801c8a49b$22fbc2b0$68f34810$@us> <0c9501c8a552$480c0df0$d82429d0$@us> Mime-Version: 1.0 Content-Disposition: inline In-Reply-To: <0c9501c8a552$480c0df0$d82429d0$@us> User-Agent: Mutt/1.5.9i Cc: 'Daryl Malas' , 'Hadriel Kaplan' , peppermint@ietf.org Subject: Re: [PEPPERMINT] DRINKS PROPOSED Charter ..comments please. 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 On 2008/04/23 16:04, Richard Shockey wrote: > > > > More specifically, the SED is the set of parameters that the local > > SSP needs to complete the call, through its egress SBE's, and may > > include: > > Number ranges? As it is defined, SED is what you get from the mapping step, not the mapping itself. Number ranges (or individual numbers) are the key under which SED is stored. (In the case where ENUM is the access protocol, SED would be whatever is contained in the NAPTR. The number ranges don't appear there, they are only relevant for selecting the right NAPTR records from the DNS tree.) /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: 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 BA9CF3A6DC1; Wed, 23 Apr 2008 07:57:18 -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 F2A193A6DC1 for ; Wed, 23 Apr 2008 07:57:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.059 X-Spam-Level: X-Spam-Status: No, score=-3.059 tagged_above=-999 required=5 tests=[AWL=-0.060, BAYES_00=-2.599, J_CHICKENPOX_32=0.6, 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 RMncq91IRmES for ; Wed, 23 Apr 2008 07:57:15 -0700 (PDT) Received: from mail.songbird.com (mail.songbird.com [208.184.79.10]) by core3.amsl.com (Postfix) with ESMTP id 670753A6D80 for ; Wed, 23 Apr 2008 07:57:15 -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 m3NEu6Qe019871 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Wed, 23 Apr 2008 07:56:08 -0700 From: "Richard Shockey" To: "'Hadriel Kaplan'" , "'Daryl Malas'" , "'Otmar Lendl'" , References: <125b01c89fe6$14f823c0$3ee86b40$@us> <20080419210654.GA30568@nic.at> <20080420211101.GA32096@nic.at> <1a6601c8a3dd$49ca8c50$dd5fa4f0$@us> <20080422144452.GA582@nic.at> <14b501c8a495$758aeb60$60a0c220$@us> <160DE07A1C4F8E4AA2715DEC577DA49193654F@srvxchg3.cablelabs.com> <154801c8a49b$22fbc2b0$68f34810$@us> In-Reply-To: Date: Wed, 23 Apr 2008 10:56:56 -0400 Message-ID: <0c9501c8a552$480c0df0$d82429d0$@us> MIME-Version: 1.0 X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: Acikh2EScAYa3BvkRuqoFaN0JnBW6gAAkqtQAAKgAAAAAJ+XUAAA2ISwABUcBLAAGLMoAA== Content-Language: en-us X-SongbirdInformation: support@songbird.com for more information X-Songbird: Clean X-Songbird-From: richard@shockey.us Subject: Re: [PEPPERMINT] DRINKS PROPOSED Charter ..comments please. 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 > > Huh. So we need to bound the data being exchanged - got that. But > the tricky part about this is picking what data now, without yet > getting into the arguments of how this will work. Well at this stage of WG formation the issue for the AD's is that we not attempt to boil the ocean only select a range of SED Data types necessary to establish a session aka the baby steps. Of course as we get into the weeds here we may find other things that are important. What I suspect is equally important for the charter is to list what is to be specifically excluded, such as rating information. What else PKI? For example, the > type of "SED" data described in section 3.3 of terminology draft is > not that high on the list of things I would expect to be exchanged or > resolved by a LUF or LRF query. > > Well... that's not totally true, but it's not sufficient data to make > peering work at the SBE-SBE connection level, and some of those > particular connection-specific details frankly aren't dynamic that way > (ie, per route) and probably shouldn't/couldn't be. > > What about something more like: This is a excellent list BTW. > > Session Establishment Data, or SED, is the data used to route a > call > to the next hop domain's ingress point, on its way to the called > terminating domain. A domain's ingress point can be thought of as > the > location derived from the NAPTR/SRV/A record [1] that resulted from > the resolution of the SIP URI. > > More specifically, the SED is the set of parameters that the local > SSP needs to complete the call, through its egress SBE's, and may > include: Number ranges? > > . A destination SIP/SIPS/TEL URI > > . A SIP next-hop/next-hop-group to send the request to, possibly > including one or more of the following: > > o Fully Qualified Domain Name (FQDN) > > o Trunk Group and Context (IPTEL WG) > > o Learned/static SIP Route headers for the peer SSP > > . A resolved terminating domain identifier, which may include: > > o The terminating domain identified as a Domain Name > > o The terminating domain identified as an SSP-ID > > o One or more parameters indicating ported number > resolution > > . Optional resource control parameters such as > > o Resource priority value(s) for the call > > o Geographic or topological identifiers > > > -hadriel > > > > -----Original Message----- > > From: Richard Shockey [mailto:richard@shockey.us] > > > > Basically the subject headers are sufficient for what we should be > looking > > at. But with specific exclusions... rating information, for > instance, > > should > > explicitly be excluded from a first pass at a WG charter. > > > > ***************** > > > > 3.3. Session Establishment Data > > > > Session Establishment Data, or SED, is the data used to route a > call > > to the next hop associated with the called domain's ingress > point. A > > domain's ingress point can be thought of as the location derived > from > > the NAPTR/SRV/A record [1] that resulted from the resolution of > the > > SIP URI. > > > > More specifically, the SED is the set of parameters that the > outgoing > > SBEs need to complete the call, and may include: > > > > . A destination SIP URI > > > > . A SIP proxy or ingress SBE to send the INVITE to, including > > > > o Fully Qualified Domain Name (FQDN) > > > > o Port > > > > o Transport Protocol (UDP/TCP/TLS [9/10/11]) > > > > . Security Parameters, including > > > > o TLS certificate to use > > > > o TLS certificate to expect > > > > o TLS certificate verification setting > > > > . Optional resource control parameters such as > > > > o Limits on the total number of call initiations to a > peer > > > > o Limits on SIP transactions/second > > > > > > > > > > > > --Daryl > > > > > > -----Original Message----- > > > From: peppermint-bounces@ietf.org [mailto:peppermint- > bounces@ietf.org] > > > On Behalf Of Richard Shockey > > > Sent: Tuesday, April 22, 2008 10:25 AM > > > To: 'Hadriel Kaplan'; 'Otmar Lendl'; peppermint@ietf.org > > > Subject: Re: [PEPPERMINT] DRINKS PROPOSED Charter ..comments > please. > > > > > > Thank you Hadriel. > > > > > > Now after some conversations with our AD, I think we are in good > shape > > > with the charter as its currently written including the rename. > > > > > > There is some clarification in the text I'll fix however there is > a > > > strong suggestion that that we specify a more detailed list of > SED > > > data > > > to be addressed. That means expanding out this sentence below > > > somewhat. > > > We don't need a exhaustive list only a list that sufficiently > bounds > > > the > > > work to be undertaken. In other words, the AD don't want us > wandering > > > off the reservation. > > > > > > "Typical SED data includes the mapping of phone numbers to URIs, > > > policies surrounding admission to various points of network > > > interconnection, and various other types of interconnect data." > > > > > > Anyone want to suggest some text? > > > > > > > -----Original Message----- > > > > From: peppermint-bounces@ietf.org > > > > [mailto:peppermint-bounces@ietf.org] > > > > On Behalf Of Hadriel Kaplan > > > > Sent: Tuesday, April 22, 2008 11:19 AM > > > > To: Otmar Lendl; peppermint@ietf.org > > > > Subject: Re: [PEPPERMINT] DRINKS PROPOSED Charter ..comments > > > please. > > > > > > > > Hi Otmar, > > > > I don't disagree with some or many of our points, but I don't > think > > > > we need to hash them out for the charter. I think we can > discuss > > > > these in the actual WG, after the charter is approved. > Nothing in > > > > the charter limits our ability to do that as far as I can > tell. > > > > (right?) > > > > > > > > -hadriel > > > > > > > > > > > > > -----Original Message----- > > > > > From: peppermint-bounces@ietf.org [mailto:peppermint- > > > > bounces@ietf.org] On > Behalf Of Otmar Lendl > Sent: Tuesday, > > > April > > > > 22, 2008 10:45 AM > To: peppermint@ietf.org > Subject: Re: > > > > [PEPPERMINT] DRINKS PROPOSED Charter ..comments please. > > > > > > > > > > On 2008/04/21 20:04, Richard Shockey > wrote: > > > > > > > > > > > > > > > > These administrative domains may be of any > practical > > > size > > > > > > > and > > > could be any type of SSP, such as recognized > telephony > > > > carriers, > > enterprises, > > > end- user > > > > > > > groups, > > > or > > > > > > > Federations. > > > > > > > > > > > > > > > > > > > > > I think we have a problem here. IMHO we should not mix > > > single > > > > > > > SSPs > > > (carriers, enterprises) with groups of SSPs > > > > (federations). This > > > will bite us when doing the > protocol > > > > design. > > > > > > > > > > > > Why will this bit us? > > > > > > > > > > Because a SSP can be a member of multiple federations. Now, > if > > > you > > > > > > > plan > to build a registry similar to a LERG/NPAC database, > then > > > > you'll have to > deal with multiple federations inserting > data > > > about > > > > > > > the same numbers. > > > > > > > > > > That's the point where the registry moves from a store of > > > > authoritative > information of "who owns a number" and perhaps > > > "what > > > > is the URI for the > number" to a distribution mechanism of > > > routing > > > > announcements, where > there can be multiple possible records > > > > (=routes) per destination. > > > > > > > > > > This has a profound impact on the overall design. Imagine > that a > > > > domain > registry allows the provisioning of records > concerning a > > > > domain by > multiple registrars at the same time. Yes, it's > > > possible > > > > to build > a system based on this premise, but we need to make > this > > > > explicit. > > > > > > > > > > > > > I don't think that sentence restricts it, since it > says > > > > "could > > > > be" and we can later decide to restrict it > further, > > > > but yeah it's > > > > weird to think of a Federation as > being an > > > > SSP. > > > > > > > > > > > > > > Then let's take "federations" out of this definition > NOW. > > > > > > > > > > > > I'm not convinced this is a problem. Frankly its splitting > > > hairs > > > > > > > > > on terminology. I don't understand why a federations could > not > > > be > > > > > > > > > considered a SSP? But if there is consensus on taking it > out .. > > > > OK. > > > > > > > > > > A federation is defined as a set of SSPs. > > > > > > > > > > Any terminology where "X" and "set of X" is of the same type > is > > > > > > > > likely to be flawed. (e.g. a "a flock of birds" cannot be a > "bird") > > > > > > > > > > > > > The notion of 'a registry' is well understood in this > context. > > > > Namely a > > > > > > "trusted source of data" which multiple SSP internally or > > > > externally may > > draw data from. Instead of SSP bi-laterally > > > > exchanging data, which is > OK, > > SSP could use a registry > to > > > > aggregate their data for re- distribution. No > > different > from > > > > Domain Name operations or Centralized Numbering Databases > > > like > > > > the NPAC or the UK NICC. > > > > > > > > > > Fine. Then what about describing this in the charter > properly. > > > e.g. > > > > by > > > > > > > > > > Administrative domains may exchange data directly between > each > > > > other > or might use an external registry (perhaps operated > by a > > > > federation) > > > > > to aggregate data from multiple administrative domains into > > > > > a > > > > single view. > > > > > > > > > > > A registry may be the 'trusted source of data' internal to > the > > > > network > as > > well that redistributes data to local > databases > > > or > > > > caches. This is the > way > > the world works today in phone > > > > networks. > > > > > > > > > > > > > > > So the aim of peppermint^Wdrinks is to move the PSTN > thinking and > > > > > databases into an IP based setting? Will this be anything > more > > > than > > > > > > > just > porting the concepts behind LERG/NPAC/NICC/... to SIP? > > > > > > > > > > Will there be any innovation in call routing, or are we just > > > > replacing > aging provisioning protocols with new ones, while > > > > retaining the > dependency on unloved fat registries? > > > > > > > > > > As we're saying good-bye to the end2end principle for VoIP > > > routing, > > > > > > > > is falling back to the PSTN way of routing calls really the > path > > > > > > > > the IETF should be choosing? > > > > > > > > > > > > > > > Other open questions: > > > > > > > > > > * Will DRINKS just consider "push" style provisioning > protocols, > > > > > or will DRINKS also look at on-demand lookup protocols > towards > > > > > these registries? > > > > > > > > > > * Speermint has separated out the LUF (who owns the > destination?) > > > > > from the LRF (What's my SED towards the destination > network?). > > > > > > > > > > Given the fact that DRINKS is supposed to build upon > speermint, > > > > > can you make clear whether DRINKS is about the LUF or the > LRF? > > > > > > > > > > Or are we mixing up these things *again*? > > > > > > > > > > > > > > That is sorely missing in speermint. > > > > > > > > > > > > > > > > Isn't that Speermint's role to do? (I'm not clear on > that > > > > either) > > > > > > > > > > > > > > Do you see such an item in the speermint milestones? I > > > don't. > > > > > > > > > > > > > > IMHO we need something like RFC 1034 for the whole > speermint > > > / > > > > > > > > > > peppermint setup. > > > > > > > > > > > Well Hadriel is right ... that is a Speermint issue. > > > > > > > > > > So you want to define a set protocols without having a > reference > > > > > > > > > > > scenario against which to test whether the protocols do what we > > > want? > > > > > > > > > > Good plan. > > > > > > > > > > As it has worked so brilliantly for speermint, we have to > > > replicate > > > > > > > > it in DRINKs as well, don't we? > > > > > > > > > > /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 > > > > _______________________________________________ > > > > 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 F19633A6D6F; Tue, 22 Apr 2008 22:23: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 EEEA23A6D6F for ; Tue, 22 Apr 2008 22:23:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.261 X-Spam-Level: X-Spam-Status: No, score=-2.261 tagged_above=-999 required=5 tests=[AWL=-0.262, BAYES_00=-2.599, J_CHICKENPOX_32=0.6] 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 px5U9BQb8wUU for ; Tue, 22 Apr 2008 22:23:37 -0700 (PDT) Received: from etmail.acmepacket.com (etmail.acmepacket.com [216.41.24.6]) by core3.amsl.com (Postfix) with ESMTP id 69FE43A6E5A for ; Tue, 22 Apr 2008 22:23:37 -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.263.0; Wed, 23 Apr 2008 01:23:10 -0400 Received: from mail.acmepacket.com ([216.41.24.7]) by mail.acmepacket.com ([216.41.24.7]) with mapi; Wed, 23 Apr 2008 01:23:09 -0400 From: Hadriel Kaplan To: Richard Shockey , 'Daryl Malas' , 'Otmar Lendl' , "peppermint@ietf.org" Date: Wed, 23 Apr 2008 01:20:25 -0400 Thread-Topic: [PEPPERMINT] DRINKS PROPOSED Charter ..comments please. Thread-Index: Acikh2EScAYa3BvkRuqoFaN0JnBW6gAAkqtQAAKgAAAAAJ+XUAAA2ISwABUcBLA= Message-ID: References: <125b01c89fe6$14f823c0$3ee86b40$@us> <20080419210654.GA30568@nic.at> <20080420211101.GA32096@nic.at> <1a6601c8a3dd$49ca8c50$dd5fa4f0$@us> <20080422144452.GA582@nic.at> <14b501c8a495$758aeb60$60a0c220$@us> <160DE07A1C4F8E4AA2715DEC577DA49193654F@srvxchg3.cablelabs.com> <154801c8a49b$22fbc2b0$68f34810$@us> In-Reply-To: <154801c8a49b$22fbc2b0$68f34810$@us> 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] DRINKS PROPOSED Charter ..comments please. 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 Huh. So we need to bound the data being exchanged - got that. But the tricky part about this is picking what data now, without yet getting into the arguments of how this will work. For example, the type of "SED" data described in section 3.3 of terminology draft is not that high on the list of things I would expect to be exchanged or resolved by a LUF or LRF query. Well... that's not totally true, but it's not sufficient data to make peering work at the SBE-SBE connection level, and some of those particular connection-specific details frankly aren't dynamic that way (ie, per route) and probably shouldn't/couldn't be. What about something more like: Session Establishment Data, or SED, is the data used to route a call to the next hop domain's ingress point, on its way to the called terminating domain. A domain's ingress point can be thought of as the location derived from the NAPTR/SRV/A record [1] that resulted from the resolution of the SIP URI. More specifically, the SED is the set of parameters that the local SSP needs to complete the call, through its egress SBE's, and may include: . A destination SIP/SIPS/TEL URI . A SIP next-hop/next-hop-group to send the request to, possibly including one or more of the following: o Fully Qualified Domain Name (FQDN) o Trunk Group and Context (IPTEL WG) o Learned/static SIP Route headers for the peer SSP . A resolved terminating domain identifier, which may include: o The terminating domain identified as a Domain Name o The terminating domain identified as an SSP-ID o One or more parameters indicating ported number resolution . Optional resource control parameters such as o Resource priority value(s) for the call o Geographic or topological identifiers -hadriel > -----Original Message----- > From: Richard Shockey [mailto:richard@shockey.us] > > Basically the subject headers are sufficient for what we should be looking > at. But with specific exclusions... rating information, for instance, > should > explicitly be excluded from a first pass at a WG charter. > > ***************** > > 3.3. Session Establishment Data > > Session Establishment Data, or SED, is the data used to route a call > to the next hop associated with the called domain's ingress point. A > domain's ingress point can be thought of as the location derived from > the NAPTR/SRV/A record [1] that resulted from the resolution of the > SIP URI. > > More specifically, the SED is the set of parameters that the outgoing > SBEs need to complete the call, and may include: > > . A destination SIP URI > > . A SIP proxy or ingress SBE to send the INVITE to, including > > o Fully Qualified Domain Name (FQDN) > > o Port > > o Transport Protocol (UDP/TCP/TLS [9/10/11]) > > . Security Parameters, including > > o TLS certificate to use > > o TLS certificate to expect > > o TLS certificate verification setting > > . Optional resource control parameters such as > > o Limits on the total number of call initiations to a peer > > o Limits on SIP transactions/second > > > > > > > --Daryl > > > > -----Original Message----- > > From: peppermint-bounces@ietf.org [mailto:peppermint-bounces@ietf.org] > > On Behalf Of Richard Shockey > > Sent: Tuesday, April 22, 2008 10:25 AM > > To: 'Hadriel Kaplan'; 'Otmar Lendl'; peppermint@ietf.org > > Subject: Re: [PEPPERMINT] DRINKS PROPOSED Charter ..comments please. > > > > Thank you Hadriel. > > > > Now after some conversations with our AD, I think we are in good shape > > with the charter as its currently written including the rename. > > > > There is some clarification in the text I'll fix however there is a > > strong suggestion that that we specify a more detailed list of SED > > data > > to be addressed. That means expanding out this sentence below > > somewhat. > > We don't need a exhaustive list only a list that sufficiently bounds > > the > > work to be undertaken. In other words, the AD don't want us wandering > > off the reservation. > > > > "Typical SED data includes the mapping of phone numbers to URIs, > > policies surrounding admission to various points of network > > interconnection, and various other types of interconnect data." > > > > Anyone want to suggest some text? > > > > > -----Original Message----- > > > From: peppermint-bounces@ietf.org > > > [mailto:peppermint-bounces@ietf.org] > > > On Behalf Of Hadriel Kaplan > > > Sent: Tuesday, April 22, 2008 11:19 AM > > > To: Otmar Lendl; peppermint@ietf.org > > > Subject: Re: [PEPPERMINT] DRINKS PROPOSED Charter ..comments > > please. > > > > > > Hi Otmar, > > > I don't disagree with some or many of our points, but I don't think > > > we need to hash them out for the charter. I think we can discuss > > > these in the actual WG, after the charter is approved. Nothing in > > > the charter limits our ability to do that as far as I can tell. > > > (right?) > > > > > > -hadriel > > > > > > > > > > -----Original Message----- > > > > From: peppermint-bounces@ietf.org [mailto:peppermint- > > > bounces@ietf.org] On > Behalf Of Otmar Lendl > Sent: Tuesday, > > April > > > 22, 2008 10:45 AM > To: peppermint@ietf.org > Subject: Re: > > > [PEPPERMINT] DRINKS PROPOSED Charter ..comments please. > > > > > > > > On 2008/04/21 20:04, Richard Shockey wrote: > > > > > > > > > > > > > > These administrative domains may be of any practical > > size > > > > > and > > > could be any type of SSP, such as recognized telephony > > > carriers, > > enterprises, > > > end- user > > > > > > groups, > > or > > > > > Federations. > > > > > > > > > > > > > > > > > > I think we have a problem here. IMHO we should not mix > > single > > > > > SSPs > > > (carriers, enterprises) with groups of SSPs > > > (federations). This > > > will bite us when doing the protocol > > > design. > > > > > > > > > > Why will this bit us? > > > > > > > > Because a SSP can be a member of multiple federations. Now, if > > you > > > > > plan > to build a registry similar to a LERG/NPAC database, then > > > you'll have to > deal with multiple federations inserting data > > about > > > > > the same numbers. > > > > > > > > That's the point where the registry moves from a store of > > > authoritative > information of "who owns a number" and perhaps > > "what > > > is the URI for the > number" to a distribution mechanism of > > routing > > > announcements, where > there can be multiple possible records > > > (=routes) per destination. > > > > > > > > This has a profound impact on the overall design. Imagine that a > > > domain > registry allows the provisioning of records concerning a > > > domain by > multiple registrars at the same time. Yes, it's > > possible > > > to build > a system based on this premise, but we need to make this > > > explicit. > > > > > > > > > > > I don't think that sentence restricts it, since it says > > > "could > > > > be" and we can later decide to restrict it further, > > > but yeah it's > > > > weird to think of a Federation as being an > > > SSP. > > > > > > > > > > > > Then let's take "federations" out of this definition NOW. > > > > > > > > > > I'm not convinced this is a problem. Frankly its splitting > > hairs > > > > > > > on terminology. I don't understand why a federations could not > > be > > > > > > > considered a SSP? But if there is consensus on taking it out .. > > > OK. > > > > > > > > A federation is defined as a set of SSPs. > > > > > > > > Any terminology where "X" and "set of X" is of the same type is > > > > > > likely to be flawed. (e.g. a "a flock of birds" cannot be a "bird") > > > > > > > > > > The notion of 'a registry' is well understood in this context. > > > Namely a > > > > > "trusted source of data" which multiple SSP internally or > > > externally may > > draw data from. Instead of SSP bi-laterally > > > exchanging data, which is > OK, > > SSP could use a registry to > > > aggregate their data for re- distribution. No > > different from > > > Domain Name operations or Centralized Numbering Databases > > like > > > the NPAC or the UK NICC. > > > > > > > > Fine. Then what about describing this in the charter properly. > > e.g. > > > by > > > > > > > > Administrative domains may exchange data directly between each > > > other > or might use an external registry (perhaps operated by a > > > federation) > > > > to aggregate data from multiple administrative domains into > > > a > > > single view. > > > > > > > > > A registry may be the 'trusted source of data' internal to the > > > network > as > > well that redistributes data to local databases > > or > > > caches. This is the > way > > the world works today in phone > > > networks. > > > > > > > > > > > > So the aim of peppermint^Wdrinks is to move the PSTN thinking and > > > > databases into an IP based setting? Will this be anything more > > than > > > > > just > porting the concepts behind LERG/NPAC/NICC/... to SIP? > > > > > > > > Will there be any innovation in call routing, or are we just > > > replacing > aging provisioning protocols with new ones, while > > > retaining the > dependency on unloved fat registries? > > > > > > > > As we're saying good-bye to the end2end principle for VoIP > > routing, > > > > > > is falling back to the PSTN way of routing calls really the path > > > > > > the IETF should be choosing? > > > > > > > > > > > > Other open questions: > > > > > > > > * Will DRINKS just consider "push" style provisioning protocols, > > > > or will DRINKS also look at on-demand lookup protocols towards > > > > these registries? > > > > > > > > * Speermint has separated out the LUF (who owns the destination?) > > > > from the LRF (What's my SED towards the destination network?). > > > > > > > > Given the fact that DRINKS is supposed to build upon speermint, > > > > can you make clear whether DRINKS is about the LUF or the LRF? > > > > > > > > Or are we mixing up these things *again*? > > > > > > > > > > > > That is sorely missing in speermint. > > > > > > > > > > > > > > Isn't that Speermint's role to do? (I'm not clear on that > > > either) > > > > > > > > > > > > Do you see such an item in the speermint milestones? I > > don't. > > > > > > > > > > > > IMHO we need something like RFC 1034 for the whole speermint > > / > > > > > > > > peppermint setup. > > > > > > > > > Well Hadriel is right ... that is a Speermint issue. > > > > > > > > So you want to define a set protocols without having a reference > > > > > > > > scenario against which to test whether the protocols do what we > > want? > > > > > > > > Good plan. > > > > > > > > As it has worked so brilliantly for speermint, we have to > > replicate > > > > > > it in DRINKs as well, don't we? > > > > > > > > /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 > > > _______________________________________________ > > > 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 F061E28C2D7; Tue, 22 Apr 2008 10:07:01 -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 2216D3A6BB6 for ; Tue, 22 Apr 2008 10:07:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.999 X-Spam-Level: X-Spam-Status: No, score=-2.999 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, J_CHICKENPOX_32=0.6, 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 yeuTJo77dcyb for ; Tue, 22 Apr 2008 10:06:54 -0700 (PDT) Received: from mail.songbird.com (mail.songbird.com [208.184.79.10]) by core3.amsl.com (Postfix) with ESMTP id DDE0F3A6841 for ; Tue, 22 Apr 2008 10:06:54 -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 m3MH5mxk003281 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Tue, 22 Apr 2008 10:05:49 -0700 From: "Richard Shockey" To: "'Daryl Malas'" , "'Hadriel Kaplan'" , "'Otmar Lendl'" , References: <125b01c89fe6$14f823c0$3ee86b40$@us> <20080419210654.GA30568@nic.at> <20080420211101.GA32096@nic.at> <1a6601c8a3dd$49ca8c50$dd5fa4f0$@us> <20080422144452.GA582@nic.at> <14b501c8a495$758aeb60$60a0c220$@us> <160DE07A1C4F8E4AA2715DEC577DA49193654F@srvxchg3.cablelabs.com> In-Reply-To: <160DE07A1C4F8E4AA2715DEC577DA49193654F@srvxchg3.cablelabs.com> Date: Tue, 22 Apr 2008 13:05:57 -0400 Message-ID: <154801c8a49b$22fbc2b0$68f34810$@us> MIME-Version: 1.0 X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: Acikh2EScAYa3BvkRuqoFaN0JnBW6gAAkqtQAAKgAAAAAJ+XUAAA2ISw Content-Language: en-us X-SongbirdInformation: support@songbird.com for more information X-Songbird: Clean X-Songbird-From: richard@shockey.us Subject: Re: [PEPPERMINT] DRINKS PROPOSED Charter ..comments please. 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, > > I would assume the description in Section 3.3 of the Speermint > terminology draft is not substantial enough in provide a scope of SED > relative to DRINKS? This is my working assumption from the AD's.. some general concepts as you point out, but also scoping out what is NOT to be included. This is classic WG bounding. No wondering off the reservation. First crawl then walk. I would assume the described aspects of SED would > need to be provisioned and shared as necessary between peers. We can > definitely get more granular, but I didn't know if this would work at > a high level. Basically the subject headers are sufficient for what we should be looking at. But with specific exclusions... rating information, for instance, should explicitly be excluded from a first pass at a WG charter. ***************** 3.3. Session Establishment Data Session Establishment Data, or SED, is the data used to route a call to the next hop associated with the called domain's ingress point. A domain's ingress point can be thought of as the location derived from the NAPTR/SRV/A record [1] that resulted from the resolution of the SIP URI. More specifically, the SED is the set of parameters that the outgoing SBEs need to complete the call, and may include: . A destination SIP URI . A SIP proxy or ingress SBE to send the INVITE to, including o Fully Qualified Domain Name (FQDN) o Port o Transport Protocol (UDP/TCP/TLS [9/10/11]) . Security Parameters, including o TLS certificate to use o TLS certificate to expect o TLS certificate verification setting . Optional resource control parameters such as o Limits on the total number of call initiations to a peer o Limits on SIP transactions/second > > --Daryl > > -----Original Message----- > From: peppermint-bounces@ietf.org [mailto:peppermint-bounces@ietf.org] > On Behalf Of Richard Shockey > Sent: Tuesday, April 22, 2008 10:25 AM > To: 'Hadriel Kaplan'; 'Otmar Lendl'; peppermint@ietf.org > Subject: Re: [PEPPERMINT] DRINKS PROPOSED Charter ..comments please. > > Thank you Hadriel. > > Now after some conversations with our AD, I think we are in good shape > with the charter as its currently written including the rename. > > There is some clarification in the text I'll fix however there is a > strong suggestion that that we specify a more detailed list of SED > data > to be addressed. That means expanding out this sentence below > somewhat. > We don't need a exhaustive list only a list that sufficiently bounds > the > work to be undertaken. In other words, the AD don't want us wandering > off the reservation. > > "Typical SED data includes the mapping of phone numbers to URIs, > policies surrounding admission to various points of network > interconnection, and various other types of interconnect data." > > Anyone want to suggest some text? > > > -----Original Message----- > > From: peppermint-bounces@ietf.org > > [mailto:peppermint-bounces@ietf.org] > > On Behalf Of Hadriel Kaplan > > Sent: Tuesday, April 22, 2008 11:19 AM > > To: Otmar Lendl; peppermint@ietf.org > > Subject: Re: [PEPPERMINT] DRINKS PROPOSED Charter ..comments > please. > > > > Hi Otmar, > > I don't disagree with some or many of our points, but I don't think > > we need to hash them out for the charter. I think we can discuss > > these in the actual WG, after the charter is approved. Nothing in > > the charter limits our ability to do that as far as I can tell. > > (right?) > > > > -hadriel > > > > > > > -----Original Message----- > > > From: peppermint-bounces@ietf.org [mailto:peppermint- > > bounces@ietf.org] On > Behalf Of Otmar Lendl > Sent: Tuesday, > April > > 22, 2008 10:45 AM > To: peppermint@ietf.org > Subject: Re: > > [PEPPERMINT] DRINKS PROPOSED Charter ..comments please. > > > > > > On 2008/04/21 20:04, Richard Shockey wrote: > > > > > > > > > > > > These administrative domains may be of any practical > size > > > and > > > could be any type of SSP, such as recognized telephony > > carriers, > > enterprises, > > > end- user > > > > > > groups, > or > > > Federations. > > > > > > > > > > > > > > > I think we have a problem here. IMHO we should not mix > single > > > SSPs > > > (carriers, enterprises) with groups of SSPs > > (federations). This > > > will bite us when doing the protocol > > design. > > > > > > > > Why will this bit us? > > > > > > Because a SSP can be a member of multiple federations. Now, if > you > > > plan > to build a registry similar to a LERG/NPAC database, then > > you'll have to > deal with multiple federations inserting data > about > > > the same numbers. > > > > > > That's the point where the registry moves from a store of > > authoritative > information of "who owns a number" and perhaps > "what > > is the URI for the > number" to a distribution mechanism of > routing > > announcements, where > there can be multiple possible records > > (=routes) per destination. > > > > > > This has a profound impact on the overall design. Imagine that a > > domain > registry allows the provisioning of records concerning a > > domain by > multiple registrars at the same time. Yes, it's > possible > > to build > a system based on this premise, but we need to make this > > explicit. > > > > > > > > > I don't think that sentence restricts it, since it says > > "could > > > > be" and we can later decide to restrict it further, > > but yeah it's > > > > weird to think of a Federation as being an > > SSP. > > > > > > > > > > Then let's take "federations" out of this definition NOW. > > > > > > > > I'm not convinced this is a problem. Frankly its splitting > hairs > > > > > on terminology. I don't understand why a federations could not > be > > > > > considered a SSP? But if there is consensus on taking it out .. > > OK. > > > > > > A federation is defined as a set of SSPs. > > > > > > Any terminology where "X" and "set of X" is of the same type is > > > > likely to be flawed. (e.g. a "a flock of birds" cannot be a "bird") > > > > > > > The notion of 'a registry' is well understood in this context. > > Namely a > > > > "trusted source of data" which multiple SSP internally or > > externally may > > draw data from. Instead of SSP bi-laterally > > exchanging data, which is > OK, > > SSP could use a registry to > > aggregate their data for re- distribution. No > > different from > > Domain Name operations or Centralized Numbering Databases > > like > > the NPAC or the UK NICC. > > > > > > Fine. Then what about describing this in the charter properly. > e.g. > > by > > > > > > Administrative domains may exchange data directly between each > > other > or might use an external registry (perhaps operated by a > > federation) > > > to aggregate data from multiple administrative domains into > > a > > single view. > > > > > > > A registry may be the 'trusted source of data' internal to the > > network > as > > well that redistributes data to local databases > or > > caches. This is the > way > > the world works today in phone > > networks. > > > > > > > > > So the aim of peppermint^Wdrinks is to move the PSTN thinking and > > > databases into an IP based setting? Will this be anything more > than > > > just > porting the concepts behind LERG/NPAC/NICC/... to SIP? > > > > > > Will there be any innovation in call routing, or are we just > > replacing > aging provisioning protocols with new ones, while > > retaining the > dependency on unloved fat registries? > > > > > > As we're saying good-bye to the end2end principle for VoIP > routing, > > > > is falling back to the PSTN way of routing calls really the path > > > > the IETF should be choosing? > > > > > > > > > Other open questions: > > > > > > * Will DRINKS just consider "push" style provisioning protocols, > > > or will DRINKS also look at on-demand lookup protocols towards > > > these registries? > > > > > > * Speermint has separated out the LUF (who owns the destination?) > > > from the LRF (What's my SED towards the destination network?). > > > > > > Given the fact that DRINKS is supposed to build upon speermint, > > > can you make clear whether DRINKS is about the LUF or the LRF? > > > > > > Or are we mixing up these things *again*? > > > > > > > > > > That is sorely missing in speermint. > > > > > > > > > > > > Isn't that Speermint's role to do? (I'm not clear on that > > either) > > > > > > > > > > Do you see such an item in the speermint milestones? I > don't. > > > > > > > > > > IMHO we need something like RFC 1034 for the whole speermint > / > > > > > > peppermint setup. > > > > > > > Well Hadriel is right ... that is a Speermint issue. > > > > > > So you want to define a set protocols without having a reference > > > > > scenario against which to test whether the protocols do what we > want? > > > > > > Good plan. > > > > > > As it has worked so brilliantly for speermint, we have to > replicate > > > > it in DRINKs as well, don't we? > > > > > > /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 > > _______________________________________________ > > 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 0A1D128C4C7; Tue, 22 Apr 2008 10:05: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 8B05A3A6E06 for ; Tue, 22 Apr 2008 10:05:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.137 X-Spam-Level: X-Spam-Status: No, score=0.137 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_MODEMCABLE=0.768, HOST_EQ_MODEMCABLE=1.368, J_CHICKENPOX_32=0.6] 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 0c+xQHVGej+l for ; Tue, 22 Apr 2008 10:05:33 -0700 (PDT) Received: from ondar.cablelabs.com (ondar.cablelabs.com [192.160.73.61]) by core3.amsl.com (Postfix) with ESMTP id 5FD4428C507 for ; Tue, 22 Apr 2008 10:03:12 -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 m3MH3Iru018934; Tue, 22 Apr 2008 11:03:18 -0600 Received: from srvxchg3.cablelabs.com (10.5.0.25) by kyzyl.cablelabs.com (F-Secure/fsigk_smtp/511/kyzyl.cablelabs.com); Tue, 22 Apr 2008 11:03:18 -0700 (MST) X-Virus-Status: clean(F-Secure/fsigk_smtp/511/kyzyl.cablelabs.com) X-Mimeole: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Tue, 22 Apr 2008 11:03:18 -0600 Message-ID: <160DE07A1C4F8E4AA2715DEC577DA491936553@srvxchg3.cablelabs.com> In-Reply-To: <20080422144452.GA582@nic.at> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [PEPPERMINT] DRINKS PROPOSED Charter ..comments please. Thread-Index: Acikh3N2EjipjBMfRKeIgOJpIR1ymQAEVPtg References: <125b01c89fe6$14f823c0$3ee86b40$@us><20080419210654.GA30568@nic.at><20080420211101.GA32096@nic.at><1a6601c8a3dd$49ca8c50$dd5fa4f0$@us> <20080422144452.GA582@nic.at> From: "Daryl Malas" To: "Otmar Lendl" , X-Approved: ondar Subject: Re: [PEPPERMINT] DRINKS PROPOSED Charter ..comments please. 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 Otmar, First, let me say I do have a lot of respect for your perspective on this work as it relates to both DRINKS and SPEERMINT; however, I have heard the discussion relating to "are we simply setting up peering to look, taste, and feel just like the PSTN" many, many times. I would like to assert two comments regarding this endless discussion. First, let's take a look at the PSTN...while the PSTN is not the most perfect approach to voice communications, it has been refined and improved over the past 100 years. I am not quite convinced in the past 10 - 15 years, we can adequately say all aspects of the PSTN are junk and we should come up with a new method to solve the world's communication problems. Instead, I recommend we (and, I think we are) take a look at the problems that have been solved by many intelligent people over a 100 years and continue to ask ourselves (as they likely did) how can we make this better. Making an approach more efficient and optimal does not necessarily mean throwing it out completely. Second, within yours (and others) arguments, I have only heard of 3 total approaches to this "problem": email model, IP routing model, and PSTN model. All of these models are still based on known approaches to resolving the "peering" (or effective exchanging of data) issue as a whole. Is our goal to try and make peering look like any one of these, should it take the best approaches from each of them, or should we throw all 3 of them out and try something new? I do not have the answer to that question, but I think we need to be careful to not regularly take the liberty of shooting down very well defined, thought out models. Change is NOT always good, unless the outcome has been proven (either via solid theory or proof) to be positive in consideration of the scale of the situation. I apologize if this has come across as a rant, but every time I see this discussion thread; I've thought about writing some of my opinions down. I finally just took the opportunity to do so. I hope this makes sense. Thanks, Daryl -----Original Message----- From: peppermint-bounces@ietf.org [mailto:peppermint-bounces@ietf.org] On Behalf Of Otmar Lendl Sent: Tuesday, April 22, 2008 8:45 AM To: peppermint@ietf.org Subject: Re: [PEPPERMINT] DRINKS PROPOSED Charter ..comments please. On 2008/04/21 20:04, Richard Shockey wrote: > > > > > > These administrative domains may be of any practical size and > > could be any type of SSP, such as recognized telephony carriers, > enterprises, > > end- user > > > > > groups, or Federations. > > > > > > I think we have a problem here. IMHO we should not mix single SSPs > > (carriers, enterprises) with groups of SSPs (federations). This > > will bite us when doing the protocol design. > > Why will this bit us? Because a SSP can be a member of multiple federations. Now, if you plan to build a registry similar to a LERG/NPAC database, then you'll have to deal with multiple federations inserting data about the same numbers. That's the point where the registry moves from a store of authoritative information of "who owns a number" and perhaps "what is the URI for the number" to a distribution mechanism of routing announcements, where there can be multiple possible records (=routes) per destination. This has a profound impact on the overall design. Imagine that a domain registry allows the provisioning of records concerning a domain by multiple registrars at the same time. Yes, it's possible to build a system based on this premise, but we need to make this explicit. > > > I don't think that sentence restricts it, since it says "could > > > be" and we can later decide to restrict it further, but yeah it's > > > weird to think of a Federation as being an SSP. > > > > Then let's take "federations" out of this definition NOW. > > I'm not convinced this is a problem. Frankly its splitting hairs on > terminology. I don't understand why a federations could not be > considered a SSP? But if there is consensus on taking it out .. OK. A federation is defined as a set of SSPs. Any terminology where "X" and "set of X" is of the same type is likely to be flawed. (e.g. a "a flock of birds" cannot be a "bird") > The notion of 'a registry' is well understood in this context. Namely > a "trusted source of data" which multiple SSP internally or externally > may draw data from. Instead of SSP bi-laterally exchanging data, which > is OK, SSP could use a registry to aggregate their data for > re-distribution. No different from Domain Name operations or > Centralized Numbering Databases like the NPAC or the UK NICC. Fine. Then what about describing this in the charter properly. e.g. by Administrative domains may exchange data directly between each other or might use an external registry (perhaps operated by a federation) to aggregate data from multiple administrative domains into a single view. > A registry may be the 'trusted source of data' internal to the network > as well that redistributes data to local databases or caches. This is > the way the world works today in phone networks. So the aim of peppermint^Wdrinks is to move the PSTN thinking and databases into an IP based setting? Will this be anything more than just porting the concepts behind LERG/NPAC/NICC/... to SIP? Will there be any innovation in call routing, or are we just replacing aging provisioning protocols with new ones, while retaining the dependency on unloved fat registries? As we're saying good-bye to the end2end principle for VoIP routing, is falling back to the PSTN way of routing calls really the path the IETF should be choosing? Other open questions: * Will DRINKS just consider "push" style provisioning protocols, or will DRINKS also look at on-demand lookup protocols towards these registries? * Speermint has separated out the LUF (who owns the destination?) from the LRF (What's my SED towards the destination network?). Given the fact that DRINKS is supposed to build upon speermint, can you make clear whether DRINKS is about the LUF or the LRF? Or are we mixing up these things *again*? > > > > That is sorely missing in speermint. > > > > > > Isn't that Speermint's role to do? (I'm not clear on that > > either) > > > > Do you see such an item in the speermint milestones? I don't. > > > > IMHO we need something like RFC 1034 for the whole speermint / > > peppermint setup. > Well Hadriel is right ... that is a Speermint issue. So you want to define a set protocols without having a reference scenario against which to test whether the protocols do what we want? Good plan. As it has worked so brilliantly for speermint, we have to replicate it in DRINKs as well, don't we? /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 _______________________________________________ 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 9EF1F28C451; Tue, 22 Apr 2008 09:46:21 -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 355A528C27C for ; Tue, 22 Apr 2008 09:46:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.137 X-Spam-Level: X-Spam-Status: No, score=0.137 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_MODEMCABLE=0.768, HOST_EQ_MODEMCABLE=1.368, J_CHICKENPOX_32=0.6] 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 z3jsbwlWad5y for ; Tue, 22 Apr 2008 09:46:18 -0700 (PDT) Received: from ondar.cablelabs.com (ondar.cablelabs.com [192.160.73.61]) by core3.amsl.com (Postfix) with ESMTP id 75C463A6E10 for ; Tue, 22 Apr 2008 09:45:51 -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 m3MGjvYY017407; Tue, 22 Apr 2008 10:45:57 -0600 Received: from srvxchg3.cablelabs.com (10.5.0.25) by kyzyl.cablelabs.com (F-Secure/fsigk_smtp/511/kyzyl.cablelabs.com); Tue, 22 Apr 2008 10:45:57 -0700 (MST) X-Virus-Status: clean(F-Secure/fsigk_smtp/511/kyzyl.cablelabs.com) X-Mimeole: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Tue, 22 Apr 2008 10:45:57 -0600 Message-ID: <160DE07A1C4F8E4AA2715DEC577DA491936552@srvxchg3.cablelabs.com> In-Reply-To: <20080422144452.GA582@nic.at> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [PEPPERMINT] DRINKS PROPOSED Charter ..comments please. Thread-Index: Acikh3N2EjipjBMfRKeIgOJpIR1ymQAEIr8w References: <125b01c89fe6$14f823c0$3ee86b40$@us><20080419210654.GA30568@nic.at><20080420211101.GA32096@nic.at><1a6601c8a3dd$49ca8c50$dd5fa4f0$@us> <20080422144452.GA582@nic.at> From: "Daryl Malas" To: "Otmar Lendl" , X-Approved: ondar Subject: Re: [PEPPERMINT] DRINKS PROPOSED Charter ..comments please. 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 Otmar, Keep in mind, there is no limitation for federations to peer, much like SSPs. Therefore, to use your bird analogy, two flocks can peer and two birds could peer. You are right, a flock is not a bird; however, the provisioning and exchanging of the data should be very similar if not identical in methodology between the two distinct entities. --Daryl -----Original Message----- From: peppermint-bounces@ietf.org [mailto:peppermint-bounces@ietf.org] On Behalf Of Otmar Lendl Sent: Tuesday, April 22, 2008 8:45 AM To: peppermint@ietf.org Subject: Re: [PEPPERMINT] DRINKS PROPOSED Charter ..comments please. On 2008/04/21 20:04, Richard Shockey wrote: > > > > > > These administrative domains may be of any practical size and > > could be any type of SSP, such as recognized telephony carriers, > enterprises, > > end- user > > > > > groups, or Federations. > > > > > > I think we have a problem here. IMHO we should not mix single SSPs > > (carriers, enterprises) with groups of SSPs (federations). This > > will bite us when doing the protocol design. > > Why will this bit us? Because a SSP can be a member of multiple federations. Now, if you plan to build a registry similar to a LERG/NPAC database, then you'll have to deal with multiple federations inserting data about the same numbers. That's the point where the registry moves from a store of authoritative information of "who owns a number" and perhaps "what is the URI for the number" to a distribution mechanism of routing announcements, where there can be multiple possible records (=routes) per destination. This has a profound impact on the overall design. Imagine that a domain registry allows the provisioning of records concerning a domain by multiple registrars at the same time. Yes, it's possible to build a system based on this premise, but we need to make this explicit. > > > I don't think that sentence restricts it, since it says "could > > > be" and we can later decide to restrict it further, but yeah it's > > > weird to think of a Federation as being an SSP. > > > > Then let's take "federations" out of this definition NOW. > > I'm not convinced this is a problem. Frankly its splitting hairs on > terminology. I don't understand why a federations could not be > considered a SSP? But if there is consensus on taking it out .. OK. A federation is defined as a set of SSPs. Any terminology where "X" and "set of X" is of the same type is likely to be flawed. (e.g. a "a flock of birds" cannot be a "bird") > The notion of 'a registry' is well understood in this context. Namely > a "trusted source of data" which multiple SSP internally or externally > may draw data from. Instead of SSP bi-laterally exchanging data, which > is OK, SSP could use a registry to aggregate their data for > re-distribution. No different from Domain Name operations or > Centralized Numbering Databases like the NPAC or the UK NICC. Fine. Then what about describing this in the charter properly. e.g. by Administrative domains may exchange data directly between each other or might use an external registry (perhaps operated by a federation) to aggregate data from multiple administrative domains into a single view. > A registry may be the 'trusted source of data' internal to the network > as well that redistributes data to local databases or caches. This is > the way the world works today in phone networks. So the aim of peppermint^Wdrinks is to move the PSTN thinking and databases into an IP based setting? Will this be anything more than just porting the concepts behind LERG/NPAC/NICC/... to SIP? Will there be any innovation in call routing, or are we just replacing aging provisioning protocols with new ones, while retaining the dependency on unloved fat registries? As we're saying good-bye to the end2end principle for VoIP routing, is falling back to the PSTN way of routing calls really the path the IETF should be choosing? Other open questions: * Will DRINKS just consider "push" style provisioning protocols, or will DRINKS also look at on-demand lookup protocols towards these registries? * Speermint has separated out the LUF (who owns the destination?) from the LRF (What's my SED towards the destination network?). Given the fact that DRINKS is supposed to build upon speermint, can you make clear whether DRINKS is about the LUF or the LRF? Or are we mixing up these things *again*? > > > > That is sorely missing in speermint. > > > > > > Isn't that Speermint's role to do? (I'm not clear on that > > either) > > > > Do you see such an item in the speermint milestones? I don't. > > > > IMHO we need something like RFC 1034 for the whole speermint / > > peppermint setup. > Well Hadriel is right ... that is a Speermint issue. So you want to define a set protocols without having a reference scenario against which to test whether the protocols do what we want? Good plan. As it has worked so brilliantly for speermint, we have to replicate it in DRINKs as well, don't we? /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 _______________________________________________ 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 569BD3A6E89; Tue, 22 Apr 2008 09:37: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 E3C183A6E7F for ; Tue, 22 Apr 2008 09:37:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.137 X-Spam-Level: X-Spam-Status: No, score=0.137 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_MODEMCABLE=0.768, HOST_EQ_MODEMCABLE=1.368, J_CHICKENPOX_32=0.6] 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 YiN+Dw9BUdrj for ; Tue, 22 Apr 2008 09:37:15 -0700 (PDT) Received: from ondar.cablelabs.com (ondar.cablelabs.com [192.160.73.61]) by core3.amsl.com (Postfix) with ESMTP id 6F58E28C4F6 for ; Tue, 22 Apr 2008 09:36:04 -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 m3MGa8gm016515; Tue, 22 Apr 2008 10:36:08 -0600 Received: from srvxchg3.cablelabs.com (10.5.0.25) by kyzyl.cablelabs.com (F-Secure/fsigk_smtp/511/kyzyl.cablelabs.com); Tue, 22 Apr 2008 10:36:08 -0700 (MST) X-Virus-Status: clean(F-Secure/fsigk_smtp/511/kyzyl.cablelabs.com) X-Mimeole: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Tue, 22 Apr 2008 10:36:08 -0600 Message-ID: <160DE07A1C4F8E4AA2715DEC577DA49193654F@srvxchg3.cablelabs.com> In-Reply-To: <14b501c8a495$758aeb60$60a0c220$@us> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [PEPPERMINT] DRINKS PROPOSED Charter ..comments please. Thread-Index: Acikh2EScAYa3BvkRuqoFaN0JnBW6gAAkqtQAAKgAAAAAJ+XUA== References: <125b01c89fe6$14f823c0$3ee86b40$@us> <20080419210654.GA30568@nic.at> <20080420211101.GA32096@nic.at> <1a6601c8a3dd$49ca8c50$dd5fa4f0$@us> <20080422144452.GA582@nic.at> <14b501c8a495$758aeb60$60a0c220$@us> From: "Daryl Malas" To: "Richard Shockey" , "Hadriel Kaplan" , "Otmar Lendl" , X-Approved: ondar Subject: Re: [PEPPERMINT] DRINKS PROPOSED Charter ..comments please. 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, I would assume the description in Section 3.3 of the Speermint terminology draft is not substantial enough in provide a scope of SED relative to DRINKS? I would assume the described aspects of SED would need to be provisioned and shared as necessary between peers. We can definitely get more granular, but I didn't know if this would work at a high level. --Daryl -----Original Message----- From: peppermint-bounces@ietf.org [mailto:peppermint-bounces@ietf.org] On Behalf Of Richard Shockey Sent: Tuesday, April 22, 2008 10:25 AM To: 'Hadriel Kaplan'; 'Otmar Lendl'; peppermint@ietf.org Subject: Re: [PEPPERMINT] DRINKS PROPOSED Charter ..comments please. Thank you Hadriel. Now after some conversations with our AD, I think we are in good shape with the charter as its currently written including the rename. There is some clarification in the text I'll fix however there is a strong suggestion that that we specify a more detailed list of SED data to be addressed. That means expanding out this sentence below somewhat. We don't need a exhaustive list only a list that sufficiently bounds the work to be undertaken. In other words, the AD don't want us wandering off the reservation. "Typical SED data includes the mapping of phone numbers to URIs, policies surrounding admission to various points of network interconnection, and various other types of interconnect data." Anyone want to suggest some text? > -----Original Message----- > From: peppermint-bounces@ietf.org > [mailto:peppermint-bounces@ietf.org] > On Behalf Of Hadriel Kaplan > Sent: Tuesday, April 22, 2008 11:19 AM > To: Otmar Lendl; peppermint@ietf.org > Subject: Re: [PEPPERMINT] DRINKS PROPOSED Charter ..comments please. > > Hi Otmar, > I don't disagree with some or many of our points, but I don't think > we need to hash them out for the charter. I think we can discuss > these in the actual WG, after the charter is approved. Nothing in > the charter limits our ability to do that as far as I can tell. > (right?) > > -hadriel > > > > -----Original Message----- > > From: peppermint-bounces@ietf.org [mailto:peppermint- > bounces@ietf.org] On > Behalf Of Otmar Lendl > Sent: Tuesday, April > 22, 2008 10:45 AM > To: peppermint@ietf.org > Subject: Re: > [PEPPERMINT] DRINKS PROPOSED Charter ..comments please. > > > > On 2008/04/21 20:04, Richard Shockey wrote: > > > > > > > > > > These administrative domains may be of any practical size > and > > > could be any type of SSP, such as recognized telephony > carriers, > > enterprises, > > > end- user > > > > > > groups, or > Federations. > > > > > > > > > > > > I think we have a problem here. IMHO we should not mix single > SSPs > > > (carriers, enterprises) with groups of SSPs > (federations). This > > > will bite us when doing the protocol > design. > > > > > > Why will this bit us? > > > > Because a SSP can be a member of multiple federations. Now, if you > plan > to build a registry similar to a LERG/NPAC database, then > you'll have to > deal with multiple federations inserting data about > the same numbers. > > > > That's the point where the registry moves from a store of > authoritative > information of "who owns a number" and perhaps "what > is the URI for the > number" to a distribution mechanism of routing > announcements, where > there can be multiple possible records > (=routes) per destination. > > > > This has a profound impact on the overall design. Imagine that a > domain > registry allows the provisioning of records concerning a > domain by > multiple registrars at the same time. Yes, it's possible > to build > a system based on this premise, but we need to make this > explicit. > > > > > > > I don't think that sentence restricts it, since it says > "could > > > > be" and we can later decide to restrict it further, > but yeah it's > > > > weird to think of a Federation as being an > SSP. > > > > > > > > Then let's take "federations" out of this definition NOW. > > > > > > I'm not convinced this is a problem. Frankly its splitting hairs > > > on terminology. I don't understand why a federations could not be > > > considered a SSP? But if there is consensus on taking it out .. > OK. > > > > A federation is defined as a set of SSPs. > > > > Any terminology where "X" and "set of X" is of the same type is > > likely to be flawed. (e.g. a "a flock of birds" cannot be a "bird") > > > > The notion of 'a registry' is well understood in this context. > Namely a > > > "trusted source of data" which multiple SSP internally or > externally may > > draw data from. Instead of SSP bi-laterally > exchanging data, which is > OK, > > SSP could use a registry to > aggregate their data for re- distribution. No > > different from > Domain Name operations or Centralized Numbering Databases > > like > the NPAC or the UK NICC. > > > > Fine. Then what about describing this in the charter properly. e.g. > by > > > > Administrative domains may exchange data directly between each > other > or might use an external registry (perhaps operated by a > federation) > > to aggregate data from multiple administrative domains into > a > single view. > > > > > A registry may be the 'trusted source of data' internal to the > network > as > > well that redistributes data to local databases or > caches. This is the > way > > the world works today in phone > networks. > > > > > > So the aim of peppermint^Wdrinks is to move the PSTN thinking and > > databases into an IP based setting? Will this be anything more than > just > porting the concepts behind LERG/NPAC/NICC/... to SIP? > > > > Will there be any innovation in call routing, or are we just > replacing > aging provisioning protocols with new ones, while > retaining the > dependency on unloved fat registries? > > > > As we're saying good-bye to the end2end principle for VoIP routing, > > is falling back to the PSTN way of routing calls really the path > > the IETF should be choosing? > > > > > > Other open questions: > > > > * Will DRINKS just consider "push" style provisioning protocols, > > or will DRINKS also look at on-demand lookup protocols towards > > these registries? > > > > * Speermint has separated out the LUF (who owns the destination?) > > from the LRF (What's my SED towards the destination network?). > > > > Given the fact that DRINKS is supposed to build upon speermint, > > can you make clear whether DRINKS is about the LUF or the LRF? > > > > Or are we mixing up these things *again*? > > > > > > > > That is sorely missing in speermint. > > > > > > > > > > Isn't that Speermint's role to do? (I'm not clear on that > either) > > > > > > > > Do you see such an item in the speermint milestones? I don't. > > > > > > > > IMHO we need something like RFC 1034 for the whole speermint / > > > > peppermint setup. > > > > > Well Hadriel is right ... that is a Speermint issue. > > > > So you want to define a set protocols without having a reference > > scenario against which to test whether the protocols do what we want? > > > > Good plan. > > > > As it has worked so brilliantly for speermint, we have to replicate > > it in DRINKs as well, don't we? > > > > /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 > _______________________________________________ > 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 A07E528C314; Tue, 22 Apr 2008 09:28:21 -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 AADC628C2D6 for ; Tue, 22 Apr 2008 09:28:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.999 X-Spam-Level: X-Spam-Status: No, score=-2.999 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, J_CHICKENPOX_32=0.6, 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 Jij624d+jwI5 for ; Tue, 22 Apr 2008 09:28:19 -0700 (PDT) Received: from mail.songbird.com (mail.songbird.com [208.184.79.10]) by core3.amsl.com (Postfix) with ESMTP id 8D56828C45B for ; Tue, 22 Apr 2008 09:26:16 -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 m3MGP9JN007712 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Tue, 22 Apr 2008 09:25:10 -0700 From: "Richard Shockey" To: "'Hadriel Kaplan'" , "'Otmar Lendl'" , References: <125b01c89fe6$14f823c0$3ee86b40$@us> <20080419210654.GA30568@nic.at> <20080420211101.GA32096@nic.at> <1a6601c8a3dd$49ca8c50$dd5fa4f0$@us> <20080422144452.GA582@nic.at> In-Reply-To: Date: Tue, 22 Apr 2008 12:25:18 -0400 Message-ID: <14b501c8a495$758aeb60$60a0c220$@us> MIME-Version: 1.0 X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: Acikh2EScAYa3BvkRuqoFaN0JnBW6gAAkqtQAAKgAAA= Content-Language: en-us X-SongbirdInformation: support@songbird.com for more information X-Songbird: Clean X-Songbird-From: richard@shockey.us Subject: Re: [PEPPERMINT] DRINKS PROPOSED Charter ..comments please. 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 Thank you Hadriel. Now after some conversations with our AD, I think we are in good shape with the charter as its currently written including the rename. There is some clarification in the text I'll fix however there is a strong suggestion that that we specify a more detailed list of SED data to be addressed. That means expanding out this sentence below somewhat. We don't need a exhaustive list only a list that sufficiently bounds the work to be undertaken. In other words, the AD don't want us wandering off the reservation. "Typical SED data includes the mapping of phone numbers to URIs, policies surrounding admission to various points of network interconnection, and various other types of interconnect data." Anyone want to suggest some text? > -----Original Message----- > From: peppermint-bounces@ietf.org [mailto:peppermint-bounces@ietf.org] > On Behalf Of Hadriel Kaplan > Sent: Tuesday, April 22, 2008 11:19 AM > To: Otmar Lendl; peppermint@ietf.org > Subject: Re: [PEPPERMINT] DRINKS PROPOSED Charter ..comments please. > > Hi Otmar, > I don't disagree with some or many of our points, but I don't think we > need to hash them out for the charter. I think we can discuss these > in the actual WG, after the charter is approved. Nothing in the > charter limits our ability to do that as far as I can tell. (right?) > > -hadriel > > > > -----Original Message----- > > From: peppermint-bounces@ietf.org [mailto:peppermint- > bounces@ietf.org] On > > Behalf Of Otmar Lendl > > Sent: Tuesday, April 22, 2008 10:45 AM > > To: peppermint@ietf.org > > Subject: Re: [PEPPERMINT] DRINKS PROPOSED Charter ..comments please. > > > > On 2008/04/21 20:04, Richard Shockey wrote: > > > > > > > > > > These administrative domains may be of any practical size > and > > > > could be any type of SSP, such as recognized telephony > carriers, > > > enterprises, > > > > end- user > > > > > > > groups, or Federations. > > > > > > > > > > > > I think we have a problem here. IMHO we should not mix single > SSPs > > > > (carriers, enterprises) with groups of SSPs (federations). This > > > > will bite us when doing the protocol design. > > > > > > Why will this bit us? > > > > Because a SSP can be a member of multiple federations. Now, if you > plan > > to build a registry similar to a LERG/NPAC database, then you'll > have to > > deal with multiple federations inserting data about the same > numbers. > > > > That's the point where the registry moves from a store of > authoritative > > information of "who owns a number" and perhaps "what is the URI for > the > > number" to a distribution mechanism of routing announcements, where > > there can be multiple possible records (=routes) per destination. > > > > This has a profound impact on the overall design. Imagine that a > domain > > registry allows the provisioning of records concerning a domain by > > multiple registrars at the same time. Yes, it's possible to build > > a system based on this premise, but we need to make this explicit. > > > > > > > I don't think that sentence restricts it, since it says > "could > > > > > be" and we can later decide to restrict it further, but yeah > it's > > > > > weird to think of a Federation as being an SSP. > > > > > > > > Then let's take "federations" out of this definition NOW. > > > > > > I'm not convinced this is a problem. Frankly its splitting hairs > > > on terminology. I don't understand why a federations could not be > > > considered a SSP? But if there is consensus on taking it out .. > OK. > > > > A federation is defined as a set of SSPs. > > > > Any terminology where "X" and "set of X" is of the same type is > > likely to be flawed. (e.g. a "a flock of birds" cannot be a "bird") > > > > > The notion of 'a registry' is well understood in this context. > Namely a > > > "trusted source of data" which multiple SSP internally or > externally may > > > draw data from. Instead of SSP bi-laterally exchanging data, which > is > > OK, > > > SSP could use a registry to aggregate their data for re- > distribution. No > > > different from Domain Name operations or Centralized Numbering > Databases > > > like the NPAC or the UK NICC. > > > > Fine. Then what about describing this in the charter properly. e.g. > by > > > > Administrative domains may exchange data directly between each > other > > or might use an external registry (perhaps operated by a > federation) > > to aggregate data from multiple administrative domains into > > a single view. > > > > > A registry may be the 'trusted source of data' internal to the > network > > as > > > well that redistributes data to local databases or caches. This is > the > > way > > > the world works today in phone networks. > > > > > > So the aim of peppermint^Wdrinks is to move the PSTN thinking and > > databases into an IP based setting? Will this be anything more than > just > > porting the concepts behind LERG/NPAC/NICC/... to SIP? > > > > Will there be any innovation in call routing, or are we just > replacing > > aging provisioning protocols with new ones, while retaining the > > dependency on unloved fat registries? > > > > As we're saying good-bye to the end2end principle for VoIP routing, > > is falling back to the PSTN way of routing calls really the path > > the IETF should be choosing? > > > > > > Other open questions: > > > > * Will DRINKS just consider "push" style provisioning protocols, > > or will DRINKS also look at on-demand lookup protocols towards > > these registries? > > > > * Speermint has separated out the LUF (who owns the destination?) > > from the LRF (What's my SED towards the destination network?). > > > > Given the fact that DRINKS is supposed to build upon speermint, > > can you make clear whether DRINKS is about the LUF or the LRF? > > > > Or are we mixing up these things *again*? > > > > > > > > That is sorely missing in speermint. > > > > > > > > > > Isn't that Speermint's role to do? (I'm not clear on that > either) > > > > > > > > Do you see such an item in the speermint milestones? I don't. > > > > > > > > IMHO we need something like RFC 1034 for the whole speermint / > > > > peppermint setup. > > > > > Well Hadriel is right ... that is a Speermint issue. > > > > So you want to define a set protocols without having a reference > > scenario against which to test whether the protocols do what we > want? > > > > Good plan. > > > > As it has worked so brilliantly for speermint, we have to replicate > > it in DRINKs as well, don't we? > > > > /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 > _______________________________________________ > 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 463283A69C9; Tue, 22 Apr 2008 08:19:10 -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 D412C3A6D39 for ; Tue, 22 Apr 2008 08:19:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.299 X-Spam-Level: X-Spam-Status: No, score=-2.299 tagged_above=-999 required=5 tests=[AWL=-0.300, BAYES_00=-2.599, J_CHICKENPOX_32=0.6] 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 CU7pBYPbep2a for ; Tue, 22 Apr 2008 08:19:03 -0700 (PDT) Received: from etmail.acmepacket.com (etmail.acmepacket.com [216.41.24.6]) by core3.amsl.com (Postfix) with ESMTP id 079863A68D2 for ; Tue, 22 Apr 2008 08:19:02 -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.263.0; Tue, 22 Apr 2008 11:18:37 -0400 Received: from mail.acmepacket.com ([216.41.24.7]) by mail.acmepacket.com ([216.41.24.7]) with mapi; Tue, 22 Apr 2008 11:18:37 -0400 From: Hadriel Kaplan To: Otmar Lendl , "peppermint@ietf.org" Date: Tue, 22 Apr 2008 11:18:36 -0400 Thread-Topic: [PEPPERMINT] DRINKS PROPOSED Charter ..comments please. Thread-Index: Acikh2EScAYa3BvkRuqoFaN0JnBW6gAAkqtQ Message-ID: References: <125b01c89fe6$14f823c0$3ee86b40$@us> <20080419210654.GA30568@nic.at> <20080420211101.GA32096@nic.at> <1a6601c8a3dd$49ca8c50$dd5fa4f0$@us> <20080422144452.GA582@nic.at> In-Reply-To: <20080422144452.GA582@nic.at> 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] DRINKS PROPOSED Charter ..comments please. 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 Otmar, I don't disagree with some or many of our points, but I don't think we need to hash them out for the charter. I think we can discuss these in the actual WG, after the charter is approved. Nothing in the charter limits our ability to do that as far as I can tell. (right?) -hadriel > -----Original Message----- > From: peppermint-bounces@ietf.org [mailto:peppermint-bounces@ietf.org] On > Behalf Of Otmar Lendl > Sent: Tuesday, April 22, 2008 10:45 AM > To: peppermint@ietf.org > Subject: Re: [PEPPERMINT] DRINKS PROPOSED Charter ..comments please. > > On 2008/04/21 20:04, Richard Shockey wrote: > > > > > > > > These administrative domains may be of any practical size and > > > could be any type of SSP, such as recognized telephony carriers, > > enterprises, > > > end- user > > > > > > groups, or Federations. > > > > > > > > > I think we have a problem here. IMHO we should not mix single SSPs > > > (carriers, enterprises) with groups of SSPs (federations). This > > > will bite us when doing the protocol design. > > > > Why will this bit us? > > Because a SSP can be a member of multiple federations. Now, if you plan > to build a registry similar to a LERG/NPAC database, then you'll have to > deal with multiple federations inserting data about the same numbers. > > That's the point where the registry moves from a store of authoritative > information of "who owns a number" and perhaps "what is the URI for the > number" to a distribution mechanism of routing announcements, where > there can be multiple possible records (=routes) per destination. > > This has a profound impact on the overall design. Imagine that a domain > registry allows the provisioning of records concerning a domain by > multiple registrars at the same time. Yes, it's possible to build > a system based on this premise, but we need to make this explicit. > > > > > I don't think that sentence restricts it, since it says "could > > > > be" and we can later decide to restrict it further, but yeah it's > > > > weird to think of a Federation as being an SSP. > > > > > > Then let's take "federations" out of this definition NOW. > > > > I'm not convinced this is a problem. Frankly its splitting hairs > > on terminology. I don't understand why a federations could not be > > considered a SSP? But if there is consensus on taking it out .. OK. > > A federation is defined as a set of SSPs. > > Any terminology where "X" and "set of X" is of the same type is > likely to be flawed. (e.g. a "a flock of birds" cannot be a "bird") > > > The notion of 'a registry' is well understood in this context. Namely a > > "trusted source of data" which multiple SSP internally or externally may > > draw data from. Instead of SSP bi-laterally exchanging data, which is > OK, > > SSP could use a registry to aggregate their data for re-distribution. No > > different from Domain Name operations or Centralized Numbering Databases > > like the NPAC or the UK NICC. > > Fine. Then what about describing this in the charter properly. e.g. by > > Administrative domains may exchange data directly between each other > or might use an external registry (perhaps operated by a federation) > to aggregate data from multiple administrative domains into > a single view. > > > A registry may be the 'trusted source of data' internal to the network > as > > well that redistributes data to local databases or caches. This is the > way > > the world works today in phone networks. > > > So the aim of peppermint^Wdrinks is to move the PSTN thinking and > databases into an IP based setting? Will this be anything more than just > porting the concepts behind LERG/NPAC/NICC/... to SIP? > > Will there be any innovation in call routing, or are we just replacing > aging provisioning protocols with new ones, while retaining the > dependency on unloved fat registries? > > As we're saying good-bye to the end2end principle for VoIP routing, > is falling back to the PSTN way of routing calls really the path > the IETF should be choosing? > > > Other open questions: > > * Will DRINKS just consider "push" style provisioning protocols, > or will DRINKS also look at on-demand lookup protocols towards > these registries? > > * Speermint has separated out the LUF (who owns the destination?) > from the LRF (What's my SED towards the destination network?). > > Given the fact that DRINKS is supposed to build upon speermint, > can you make clear whether DRINKS is about the LUF or the LRF? > > Or are we mixing up these things *again*? > > > > > > That is sorely missing in speermint. > > > > > > > > Isn't that Speermint's role to do? (I'm not clear on that either) > > > > > > Do you see such an item in the speermint milestones? I don't. > > > > > > IMHO we need something like RFC 1034 for the whole speermint / > > > peppermint setup. > > > Well Hadriel is right ... that is a Speermint issue. > > So you want to define a set protocols without having a reference > scenario against which to test whether the protocols do what we want? > > Good plan. > > As it has worked so brilliantly for speermint, we have to replicate > it in DRINKs as well, don't we? > > /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 _______________________________________________ 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 9708B28C1B0; Tue, 22 Apr 2008 07:44:56 -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 3F3B13A69DB for ; Tue, 22 Apr 2008 07:44:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.428 X-Spam-Level: X-Spam-Status: No, score=-0.428 tagged_above=-999 required=5 tests=[AWL=0.402, BAYES_00=-2.599, HELO_EQ_AT=0.424, HOST_EQ_AT=0.745, J_CHICKENPOX_32=0.6] 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 UfAsFAYgpMl0 for ; Tue, 22 Apr 2008 07:44:49 -0700 (PDT) Received: from labs.nic.at (nat.labs.nic.at [83.136.33.3]) by core3.amsl.com (Postfix) with ESMTP id 44EF53A6A8E for ; Tue, 22 Apr 2008 07:44:48 -0700 (PDT) Received: from lendl by labs.nic.at with local (Exim 3.36 #1 (Debian)) id 1JoJjo-0000Kl-00 for ; Tue, 22 Apr 2008 16:44:52 +0200 Date: Tue, 22 Apr 2008 16:44:52 +0200 From: Otmar Lendl To: peppermint@ietf.org Message-ID: <20080422144452.GA582@nic.at> Mail-Followup-To: Otmar Lendl , peppermint@ietf.org References: <125b01c89fe6$14f823c0$3ee86b40$@us> <20080419210654.GA30568@nic.at> <20080420211101.GA32096@nic.at> <1a6601c8a3dd$49ca8c50$dd5fa4f0$@us> Mime-Version: 1.0 Content-Disposition: inline In-Reply-To: <1a6601c8a3dd$49ca8c50$dd5fa4f0$@us> User-Agent: Mutt/1.5.9i Subject: Re: [PEPPERMINT] DRINKS PROPOSED Charter ..comments please. 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 On 2008/04/21 20:04, Richard Shockey wrote: > > > > > > These administrative domains may be of any practical size and > > could be any type of SSP, such as recognized telephony carriers, > enterprises, > > end- user > > > > > groups, or Federations. > > > > > > I think we have a problem here. IMHO we should not mix single SSPs > > (carriers, enterprises) with groups of SSPs (federations). This > > will bite us when doing the protocol design. > > Why will this bit us? Because a SSP can be a member of multiple federations. Now, if you plan to build a registry similar to a LERG/NPAC database, then you'll have to deal with multiple federations inserting data about the same numbers. That's the point where the registry moves from a store of authoritative information of "who owns a number" and perhaps "what is the URI for the number" to a distribution mechanism of routing announcements, where there can be multiple possible records (=routes) per destination. This has a profound impact on the overall design. Imagine that a domain registry allows the provisioning of records concerning a domain by multiple registrars at the same time. Yes, it's possible to build a system based on this premise, but we need to make this explicit. > > > I don't think that sentence restricts it, since it says "could > > > be" and we can later decide to restrict it further, but yeah it's > > > weird to think of a Federation as being an SSP. > > > > Then let's take "federations" out of this definition NOW. > > I'm not convinced this is a problem. Frankly its splitting hairs > on terminology. I don't understand why a federations could not be > considered a SSP? But if there is consensus on taking it out .. OK. A federation is defined as a set of SSPs. Any terminology where "X" and "set of X" is of the same type is likely to be flawed. (e.g. a "a flock of birds" cannot be a "bird") > The notion of 'a registry' is well understood in this context. Namely a > "trusted source of data" which multiple SSP internally or externally may > draw data from. Instead of SSP bi-laterally exchanging data, which is OK, > SSP could use a registry to aggregate their data for re-distribution. No > different from Domain Name operations or Centralized Numbering Databases > like the NPAC or the UK NICC. Fine. Then what about describing this in the charter properly. e.g. by Administrative domains may exchange data directly between each other or might use an external registry (perhaps operated by a federation) to aggregate data from multiple administrative domains into a single view. > A registry may be the 'trusted source of data' internal to the network as > well that redistributes data to local databases or caches. This is the way > the world works today in phone networks. So the aim of peppermint^Wdrinks is to move the PSTN thinking and databases into an IP based setting? Will this be anything more than just porting the concepts behind LERG/NPAC/NICC/... to SIP? Will there be any innovation in call routing, or are we just replacing aging provisioning protocols with new ones, while retaining the dependency on unloved fat registries? As we're saying good-bye to the end2end principle for VoIP routing, is falling back to the PSTN way of routing calls really the path the IETF should be choosing? Other open questions: * Will DRINKS just consider "push" style provisioning protocols, or will DRINKS also look at on-demand lookup protocols towards these registries? * Speermint has separated out the LUF (who owns the destination?) from the LRF (What's my SED towards the destination network?). Given the fact that DRINKS is supposed to build upon speermint, can you make clear whether DRINKS is about the LUF or the LRF? Or are we mixing up these things *again*? > > > > That is sorely missing in speermint. > > > > > > Isn't that Speermint's role to do? (I'm not clear on that either) > > > > Do you see such an item in the speermint milestones? I don't. > > > > IMHO we need something like RFC 1034 for the whole speermint / > > peppermint setup. > Well Hadriel is right ... that is a Speermint issue. So you want to define a set protocols without having a reference scenario against which to test whether the protocols do what we want? Good plan. As it has worked so brilliantly for speermint, we have to replicate it in DRINKs as well, don't we? /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: 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 BFA903A6DA3; Mon, 21 Apr 2008 11:49: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 5F19E3A68AF for ; Mon, 21 Apr 2008 11:49:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.311 X-Spam-Level: X-Spam-Status: No, score=0.311 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_DE=0.35, J_CHICKENPOX_32=0.6, RCVD_IN_BL_SPAMCOP_NET=1.96] 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 URnATYE9CyKt for ; Mon, 21 Apr 2008 11:49:43 -0700 (PDT) Received: from moutng.kundenserver.de (moutng.kundenserver.de [212.227.126.183]) by core3.amsl.com (Postfix) with ESMTP id A679B28C43F for ; Mon, 21 Apr 2008 11:49:32 -0700 (PDT) Received: from [172.16.19.170] ([80.250.149.60]) by mrelayeu.kundenserver.de (node=mrelayeu0) with ESMTP (Nemesis) id 0MKwh2-1Jo14t1oPa-0007O9; Mon, 21 Apr 2008 20:49:33 +0200 References: <125b01c89fe6$14f823c0$3ee86b40$@us> <20080419210654.GA30568@nic.at> <20080420211101.GA32096@nic.at> <1a6601c8a3dd$49ca8c50$dd5fa4f0$@us> Message-Id: <5D2DD357-8CA9-44E2-87D7-07CA506F1144@xconnect.net> From: David Schwartz To: Richard Shockey In-Reply-To: <1a6601c8a3dd$49ca8c50$dd5fa4f0$@us> X-Mailer: iPhone Mail (3A109a) Mime-Version: 1.0 (iPhone Mail 3A109a) Date: Mon, 21 Apr 2008 21:49:03 +0300 X-Provags-ID: V01U2FsdGVkX18lKy4tda2VnyIs2i6VmYbNmoN38j29RsAXO3d hwcBv53KX2FMNRDhpAqbyjml7I+fYE0dki3y2uIS4CrXEs2/W3 JtHocghrrAbxWOfnQ8LMQ== Cc: "peppermint@ietf.org" , Hadriel Kaplan Subject: Re: [PEPPERMINT] DRINKS PROPOSED Charter ..comments please. 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 This is getting silly. If you take out federations you may as well take out enterprises as well. It never ceases to amaze me how one little word keeps making so many people feel uneasy. I am against removing it. D. On Apr 21, 2008, at 9:26 PM, "Richard Shockey" wrote: > >> >> This makes sense. >> >>>>> These administrative domains may be of any practical size and >> could be any type of SSP, such as recognized telephony carriers, > enterprises, >> end- >>>> user >>>>> groups, or Federations. >>>> >>>> I think we have a problem here. IMHO we should not mix single SSPs >>>> (carriers, enterprises) with groups of SSPs (federations). This >> will bite us when doing the protocol design. > > Why will this bit us? > > >>> >>> I don't think that sentence restricts it, since it says "could be" >> and >>> we can later decide to restrict it further, but yeah it's weird to >>> think of a Federation as being an SSP. >> >> Then let's take "federations" out of this definition NOW. > > I'm not convinced this is a problem. Frankly its splitting hairs on > terminology. I don't understand why a federations could not be > considered a > SSP? But if there is consensus on taking it out .. OK. > > >> >>>> Whoa, hold your horses. >>>> "the Registry?" >>> >>> That should be "a registry". >>> >>>> Nothing up to here requires a Registry. From the preceding >> paragraph: >>>> we're dealing with "bi-lateral or multi-lateral data exchanges". >> If> > > two SSPs have a bi-lateral data exchange, they don't need a >> Registry. "multi-lateral" exchanges could also be facilitated by a >> simple >> data replicator, similar to the role of "route reflectors" in BGP. > > Right .. > >>> >>> I had the same worry as you, but I think we'd just say "a registry" >> is> simply consumed inside one or both of the SSP's. I've always >> assumed >>> a registry is simply a data store for LUF data - there could be many >>> such data stores, and their data is either internal or external to >> an SSP or both. For a bilateral peering model, SSP1 needs to learn >> the >>> LUF data from SSP2's internal registry, and SSP2 needs to learn the >>> LUF data from SSP1's internal registry. >> >> A "registry" within a SSP is simply a "database". The word "registry" >> implies some kind of centralized database (with a provisioning and an >> access protocol). If that is not what we have in mind here, then we >> need to avoid the word "registry". > > NO. > > The notion of 'a registry' is well understood in this context. > Namely a > "trusted source of data" which multiple SSP internally or externally > may > draw data from. Instead of SSP bi-laterally exchanging data, which > is OK, > SSP could use a registry to aggregate their data for re- > distribution. No > different from Domain Name operations or Centralized Numbering > Databases > like the NPAC or the UK NICC. > > A registry may be the 'trusted source of data' internal to the > network as > well that redistributes data to local databases or caches. This is > the way > the world works today in phone networks. A SSP may need to aggregate > multiple data sources' in to a internal registry for distribution to > localized databases, typically known as Service Control Points in PSTN > speak.. > > Which is different than a database is a structured format for > organizing and > maintaining information that can be easily retrieved. > > There is a very logical difference between the notion of a registry > and a > database. > >> >>>>> PROPOSED GOALS AND MILESTONES >>>> >>>> What about writing a >>>> High-level description of the overall VoIP routing architecture, >>>> players and data-flows. >>>> first? >>>> >>>> That is sorely missing in speermint. >>> >>> Isn't that Speermint's role to do? (I'm not clear on that either) >> >> Do you see such an item in the speermint milestones? I don't. >> >> IMHO we need something like RFC 1034 for the whole speermint / >> peppermint setup. > > > Well Hadriel is right ... that is a Speermint issue. > > And I've sent the last revision to the AD's for comments. We'll see > what > they have to say. > > >> >> /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 > > _______________________________________________ > 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 A20A73A6968; Mon, 21 Apr 2008 11:27: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 35D0728C1CF for ; Mon, 21 Apr 2008 11:27:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.999 X-Spam-Level: X-Spam-Status: No, score=-2.999 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, J_CHICKENPOX_32=0.6, 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 EurdBkntRZRF for ; Mon, 21 Apr 2008 11:27:47 -0700 (PDT) Received: from mail.songbird.com (mail.songbird.com [208.184.79.10]) by core3.amsl.com (Postfix) with ESMTP id 8B51A3A67F2 for ; Mon, 21 Apr 2008 11:27:47 -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 m3LIQiYo032270 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Mon, 21 Apr 2008 11:26:46 -0700 From: "Richard Shockey" To: "'Otmar Lendl'" , "'Hadriel Kaplan'" References: <125b01c89fe6$14f823c0$3ee86b40$@us> <20080419210654.GA30568@nic.at> <20080420211101.GA32096@nic.at> In-Reply-To: <20080420211101.GA32096@nic.at> Date: Mon, 21 Apr 2008 14:26:58 -0400 Message-ID: <1a6601c8a3dd$49ca8c50$dd5fa4f0$@us> MIME-Version: 1.0 X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: AcijK3FPBN3Qc+3TRVWyMsvGNB7SkgArpncg 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] DRINKS PROPOSED Charter ..comments please. 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 > > This makes sense. > > > > > These administrative domains may be of any practical size and > could be any type of SSP, such as recognized telephony carriers, enterprises, > end- > > > user > > > > groups, or Federations. > > > > > > I think we have a problem here. IMHO we should not mix single SSPs > > > (carriers, enterprises) with groups of SSPs (federations). This > will bite us when doing the protocol design. Why will this bit us? > > > > I don't think that sentence restricts it, since it says "could be" > and > > we can later decide to restrict it further, but yeah it's weird to > > think of a Federation as being an SSP. > > Then let's take "federations" out of this definition NOW. I'm not convinced this is a problem. Frankly its splitting hairs on terminology. I don't understand why a federations could not be considered a SSP? But if there is consensus on taking it out .. OK. > > > > Whoa, hold your horses. > > > "the Registry?" > > > > That should be "a registry". > > > > > Nothing up to here requires a Registry. From the preceding > paragraph: > > > we're dealing with "bi-lateral or multi-lateral data exchanges". > If> > > two SSPs have a bi-lateral data exchange, they don't need a > Registry. "multi-lateral" exchanges could also be facilitated by a simple > data replicator, similar to the role of "route reflectors" in BGP. Right .. > > > > I had the same worry as you, but I think we'd just say "a registry" > is> simply consumed inside one or both of the SSP's. I've always assumed > > a registry is simply a data store for LUF data - there could be many > > such data stores, and their data is either internal or external to > an SSP or both. For a bilateral peering model, SSP1 needs to learn the > > LUF data from SSP2's internal registry, and SSP2 needs to learn the > > LUF data from SSP1's internal registry. > > A "registry" within a SSP is simply a "database". The word "registry" > implies some kind of centralized database (with a provisioning and an > access protocol). If that is not what we have in mind here, then we > need to avoid the word "registry". NO. The notion of 'a registry' is well understood in this context. Namely a "trusted source of data" which multiple SSP internally or externally may draw data from. Instead of SSP bi-laterally exchanging data, which is OK, SSP could use a registry to aggregate their data for re-distribution. No different from Domain Name operations or Centralized Numbering Databases like the NPAC or the UK NICC. A registry may be the 'trusted source of data' internal to the network as well that redistributes data to local databases or caches. This is the way the world works today in phone networks. A SSP may need to aggregate multiple data sources' in to a internal registry for distribution to localized databases, typically known as Service Control Points in PSTN speak.. Which is different than a database is a structured format for organizing and maintaining information that can be easily retrieved. There is a very logical difference between the notion of a registry and a database. > > > > > PROPOSED GOALS AND MILESTONES > > > > > > What about writing a > > > High-level description of the overall VoIP routing architecture, > > > players and data-flows. > > > first? > > > > > > That is sorely missing in speermint. > > > > Isn't that Speermint's role to do? (I'm not clear on that either) > > Do you see such an item in the speermint milestones? I don't. > > IMHO we need something like RFC 1034 for the whole speermint / > peppermint setup. Well Hadriel is right ... that is a Speermint issue. And I've sent the last revision to the AD's for comments. We'll see what they have to say. > > /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 _______________________________________________ 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 703F13A6F2A; Mon, 21 Apr 2008 06:54: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 5E3053A6F42 for ; Mon, 21 Apr 2008 06:54:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.999 X-Spam-Level: X-Spam-Status: No, score=-3.999 tagged_above=-999 required=5 tests=[BAYES_50=0.001, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id skOyGw9wi3ST for ; Mon, 21 Apr 2008 06:54:46 -0700 (PDT) Received: from zrtps0kp.nortel.com (zrtps0kp.nortel.com [47.140.192.56]) by core3.amsl.com (Postfix) with ESMTP id 6C3C53A6C59 for ; Mon, 21 Apr 2008 06:54:46 -0700 (PDT) Received: from zcarhxm0.corp.nortel.com (zcarhxm0.corp.nortel.com [47.129.230.95]) by zrtps0kp.nortel.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id m3LDsnp10354; Mon, 21 Apr 2008 13:54:49 GMT X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Mon, 21 Apr 2008 09:54:26 -0400 Message-ID: In-Reply-To: <20080420211312.GB32096@nic.at> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [PEPPERMINT] New name for the WG... consensus desired Thread-Index: AcijK5kqD5d6h2pyTxyoD7uYEZ2cJQAiuv0Q References: <021601c89aa8$c0a9b5f0$41fd21d0$@us> <20080420211312.GB32096@nic.at> From: "James McEachern" To: Subject: Re: [PEPPERMINT] New name for the WG... consensus desired X-BeenThere: peppermint@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Provisioning Extensions in Peering Registries for Multimedia INTerconnection List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: peppermint-bounces@ietf.org Errors-To: peppermint-bounces@ietf.org > -----Original Message----- > From: peppermint-bounces@ietf.org [mailto:peppermint-bounces@ietf.org] > On Behalf Of Otmar Lendl > Sent: Sunday, April 20, 2008 5:13 PM > To: peppermint@ietf.org > Subject: Re: [PEPPERMINT] New name for the WG... consensus desired > "drinks" is fine except that it is quite unsuitable for targetted > googling. > > I'd prefer some word which is not as common. Interestingly, if you Google "drinks IETF" the top item already points to this charter discussion. _______________________________________________ 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 54DF028C247; Sun, 20 Apr 2008 14:14:40 -0700 (PDT) X-Original-To: peppermint@core3.amsl.com Delivered-To: peppermint@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 754E13A6A9D for ; Sun, 20 Apr 2008 14:14:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.227 X-Spam-Level: X-Spam-Status: No, score=-0.227 tagged_above=-999 required=5 tests=[AWL=0.603, BAYES_00=-2.599, HELO_EQ_AT=0.424, HOST_EQ_AT=0.745, J_CHICKENPOX_32=0.6] 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 whKtdO2qWlsM for ; Sun, 20 Apr 2008 14:14:34 -0700 (PDT) Received: from labs.nic.at (nat.labs.nic.at [83.136.33.3]) by core3.amsl.com (Postfix) with ESMTP id 5955E28C401 for ; Sun, 20 Apr 2008 14:13:07 -0700 (PDT) Received: from lendl by labs.nic.at with local (Exim 3.36 #1 (Debian)) id 1JngqW-0008MC-00 for ; Sun, 20 Apr 2008 23:13:12 +0200 Date: Sun, 20 Apr 2008 23:13:12 +0200 From: Otmar Lendl To: peppermint@ietf.org Message-ID: <20080420211312.GB32096@nic.at> Mail-Followup-To: Otmar Lendl , peppermint@ietf.org References: <021601c89aa8$c0a9b5f0$41fd21d0$@us> Mime-Version: 1.0 Content-Disposition: inline In-Reply-To: <021601c89aa8$c0a9b5f0$41fd21d0$@us> User-Agent: Mutt/1.5.9i Subject: Re: [PEPPERMINT] New name for the WG... consensus desired 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 On 2008/04/10 03:04, Richard Shockey wrote: > In some serious off line discussions, there was a suggestion that PEPPERMINT > might not be the most appropriate WG name since the concept of provisioning > has very specific context in teleco world. > > What we are dealing with is data exchanges. > > Hense the suggestion of a new WG name > > DRINKS > > Data for Reachability of Inter/tra-NetworK SIP > > Personally I think this is a perfect IETF WG name and meets all the > criterion of cuteness, banality, etc. and extremely appropriate given the > venue of a probably first meeting ..Dublin . "drinks" is fine except that it is quite unsuitable for targetted googling. I'd prefer some word which is not as common. /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: 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 8458228C420; Sun, 20 Apr 2008 14:14: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 CE25728C41F for ; Sun, 20 Apr 2008 14:14:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.377 X-Spam-Level: X-Spam-Status: No, score=0.377 tagged_above=-999 required=5 tests=[AWL=1.207, BAYES_00=-2.599, HELO_EQ_AT=0.424, HOST_EQ_AT=0.745, J_CHICKENPOX_32=0.6] 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 9WAA6Q80yqGU for ; Sun, 20 Apr 2008 14:14:13 -0700 (PDT) Received: from labs.nic.at (nat.labs.nic.at [83.136.33.3]) by core3.amsl.com (Postfix) with ESMTP id 3F9B728C169 for ; Sun, 20 Apr 2008 14:10:59 -0700 (PDT) Received: from lendl by labs.nic.at with local (Exim 3.36 #1 (Debian)) id 1JngoP-0008M6-00; Sun, 20 Apr 2008 23:11:01 +0200 Date: Sun, 20 Apr 2008 23:11:01 +0200 From: Otmar Lendl To: Hadriel Kaplan Message-ID: <20080420211101.GA32096@nic.at> Mail-Followup-To: Otmar Lendl , Hadriel Kaplan , "peppermint@ietf.org" References: <125b01c89fe6$14f823c0$3ee86b40$@us> <20080419210654.GA30568@nic.at> Mime-Version: 1.0 Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.9i Cc: "peppermint@ietf.org" Subject: Re: [PEPPERMINT] DRINKS PROPOSED Charter ..comments please. 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 On 2008/04/20 06:04, Hadriel Kaplan wrote: > > Is an "administrative domain" usually the same as a SSP? > > My interpretation of an "administrative domain" is just a set of > SIP resources under control of a single administrator entity. So > for example, a set of proxies in an Enterprise acme.com may be one > administrative domain; or it may be that ny.acme.com is a distinct > administrative domain from dc.acme.com or wien.acme.com. In other > words, yes I think an SSP is an administrative domain, and is a > similar concept as BGP AS's (but obviously orthogonal to actual > BGP AS's). It is likely we will have to define how to identify an > administrative domain for the purposes of a protocol, but we can do > that in the docs if we need to. This makes sense. > > > These administrative domains may be of any practical size and could be > > any > > > type of SSP, such as recognized telephony carriers, enterprises, end- > > user > > > groups, or Federations. > > > > I think we have a problem here. IMHO we should not mix single SSPs > > (carriers, enterprises) with groups of SSPs (federations). This will > > bite us when doing the protocol design. > > I don't think that sentence restricts it, since it says "could be" and > we can later decide to restrict it further, but yeah it's weird to > think of a Federation as being an SSP. Then let's take "federations" out of this definition NOW. > > Whoa, hold your horses. > > "the Registry?" > > That should be "a registry". > > > Nothing up to here requires a Registry. From the preceding paragraph: > > we're dealing with "bi-lateral or multi-lateral data exchanges". If > > two SSPs have a bi-lateral data exchange, they don't need a Registry. > > "multi-lateral" exchanges could also be facilitated by a simple data > > replicator, similar to the role of "route reflectors" in BGP. > > I had the same worry as you, but I think we'd just say "a registry" is > simply consumed inside one or both of the SSP's. I've always assumed > a registry is simply a data store for LUF data - there could be many > such data stores, and their data is either internal or external to an > SSP or both. For a bilateral peering model, SSP1 needs to learn the > LUF data from SSP2's internal registry, and SSP2 needs to learn the > LUF data from SSP1's internal registry. A "registry" within a SSP is simply a "database". The word "registry" implies some kind of centralized database (with a provisioning and an access protocol). If that is not what we have in mind here, then we need to avoid the word "registry". > > > PROPOSED GOALS AND MILESTONES > > > > What about writing a > > High-level description of the overall VoIP routing architecture, > > players and data-flows. > > first? > > > > That is sorely missing in speermint. > > Isn't that Speermint's role to do? (I'm not clear on that either) Do you see such an item in the speermint milestones? I don't. IMHO we need something like RFC 1034 for the whole speermint / peppermint setup. /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: 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 BD2133A6A46; Sat, 19 Apr 2008 21:44: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 CD8393A6AC2 for ; Sat, 19 Apr 2008 21:44:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6lgYKgzCBTWN for ; Sat, 19 Apr 2008 21:44:42 -0700 (PDT) Received: from etmail.acmepacket.com (etmail.acmepacket.com [216.41.24.6]) by core3.amsl.com (Postfix) with ESMTP id 9CF743A6A46 for ; Sat, 19 Apr 2008 21:44:42 -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.263.0; Sun, 20 Apr 2008 00:44:16 -0400 Received: from mail.acmepacket.com ([216.41.24.7]) by mail.acmepacket.com ([216.41.24.7]) with mapi; Sun, 20 Apr 2008 00:44:16 -0400 From: Hadriel Kaplan To: Otmar Lendl , "peppermint@ietf.org" Date: Sun, 20 Apr 2008 00:42:05 -0400 Thread-Topic: [PEPPERMINT] DRINKS PROPOSED Charter ..comments please. Thread-Index: AciiYUMKGQEWxJjpQ2m7p0oYjZ+mKQAO7xCg Message-ID: References: <125b01c89fe6$14f823c0$3ee86b40$@us> <20080419210654.GA30568@nic.at> In-Reply-To: <20080419210654.GA30568@nic.at> 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] DRINKS PROPOSED Charter ..comments please. X-BeenThere: peppermint@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Provisioning Extensions in Peering Registries for Multimedia INTerconnection List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: peppermint-bounces@ietf.org Errors-To: peppermint-bounces@ietf.org > -----Original Message----- > From: peppermint-bounces@ietf.org [mailto:peppermint-bounces@ietf.org] On > Behalf Of Otmar Lendl > > > > PROPOSED CHARTER FOR PEPPERMINT > > > > The IETF has been working on various aspects of SIP-enabled Multimedia > > administrative domains among SIP Service Providers (SSPs. SSP's are > entities > > that provide session services utilizing SIP signaling to their > customers. In > > addition, the IETF has done significant work on data exchanges among > various > > network elements. > > As these term are central to this charter, can you clarify: > Are "administrative domains" meant as equivalents to "autonomous > systems" in the BGP context? > Is an "administrative domain" usually the same as a SSP? My interpretation of an "administrative domain" is just a set of SIP resources under control of a single administrator entity. So for example, a set of proxies in an Enterprise acme.com may be one administrative domain; or it may be that ny.acme.com is a distinct administrative domain from dc.acme.com or wien.acme.com. In other words, yes I think an SSP is an administrative domain, and is a similar concept as BGP AS's (but obviously orthogonal to actual BGP AS's). It is likely we will have to define how to identify an administrative domain for the purposes of a protocol, but we can do that in the docs if we need to. > > These administrative domains may be of any practical size and could be > any > > type of SSP, such as recognized telephony carriers, enterprises, end- > user > > groups, or Federations. > > I think we have a problem here. IMHO we should not mix single SSPs > (carriers, enterprises) with groups of SSPs (federations). This will > bite us when doing the protocol design. I don't think that sentence restricts it, since it says "could be" and we can later decide to restrict it further, but yeah it's weird to think of a Federation as being an SSP. > > Data exchanges among these administrative domains > > may be bi-lateral or multi-lateral in nature, and could include bulk > updates > > and/or more granular real-time updates. > > > > Typical data includes the mapping of phone numbers to URIs, policies > > surrounding admission to various points of network interconnection, and > > various other types of interconnect data. In addition, there is a > specific > > need for the exchange of such data between the Registry and various > types of > > PSTN network databases. > > Whoa, hold your horses. > "the Registry?" That should be "a registry". > Nothing up to here requires a Registry. From the preceding paragraph: > we're dealing with "bi-lateral or multi-lateral data exchanges". If > two SSPs have a bi-lateral data exchange, they don't need a Registry. > "multi-lateral" exchanges could also be facilitated by a simple data > replicator, similar to the role of "route reflectors" in BGP. I had the same worry as you, but I think we'd just say "a registry" is simply consumed inside one or both of the SSP's. I've always assumed a registry is simply a data store for LUF data - there could be many such data stores, and their data is either internal or external to an SSP or both. For a bilateral peering model, SSP1 needs to learn the LUF data from SSP2's internal registry, and SSP2 needs to learn the LUF data from SSP1's internal registry. > > PROPOSED GOALS AND MILESTONES > > What about writing a > High-level description of the overall VoIP routing architecture, > players and data-flows. > first? > > That is sorely missing in speermint. Isn't that Speermint's role to do? (I'm not clear on that either) -hadriel _______________________________________________ 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 924583A68FF; Sat, 19 Apr 2008 14:07:00 -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 4EDCC3A68FF for ; Sat, 19 Apr 2008 14:06:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.584 X-Spam-Level: * X-Spam-Status: No, score=1.584 tagged_above=-999 required=5 tests=[BAYES_40=-0.185, HELO_EQ_AT=0.424, HOST_EQ_AT=0.745, J_CHICKENPOX_32=0.6] 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 xIPY1262W3Do for ; Sat, 19 Apr 2008 14:06:58 -0700 (PDT) Received: from labs.nic.at (nat.labs.nic.at [83.136.33.3]) by core3.amsl.com (Postfix) with ESMTP id DE3073A688B for ; Sat, 19 Apr 2008 14:06:52 -0700 (PDT) Received: from lendl by labs.nic.at with local (Exim 3.36 #1 (Debian)) id 1JnKGs-00083w-00 for ; Sat, 19 Apr 2008 23:06:54 +0200 Date: Sat, 19 Apr 2008 23:06:54 +0200 From: Otmar Lendl To: peppermint@ietf.org Message-ID: <20080419210654.GA30568@nic.at> Mail-Followup-To: Otmar Lendl , peppermint@ietf.org References: <125b01c89fe6$14f823c0$3ee86b40$@us> Mime-Version: 1.0 Content-Disposition: inline In-Reply-To: <125b01c89fe6$14f823c0$3ee86b40$@us> User-Agent: Mutt/1.5.9i Subject: Re: [PEPPERMINT] DRINKS PROPOSED Charter ..comments please. 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 more feedback: On 2008/04/16 19:04, Richard Shockey wrote: > > Chairs: TBD > > > PROPOSED CHARTER FOR PEPPERMINT > > The IETF has been working on various aspects of SIP-enabled Multimedia > administrative domains among SIP Service Providers (SSPs. SSP's are entities > that provide session services utilizing SIP signaling to their customers. In > addition, the IETF has done significant work on data exchanges among various > network elements. As these term are central to this charter, can you clarify: Are "administrative domains" meant as equivalents to "autonomous systems" in the BGP context? Is an "administrative domain" usually the same as a SSP? > The ENUM and SPEERMINT working groups provide the underlying context for > much of the intended work that the DRINKS working group will undertake.: > > The ENUM working group is specifically chartered to develop protocols that > involve the translation of E.164 numbers to URIs. While the SPEERMINT > working group has been chartered to develop requirements and best current > practices among real-time application SSPs and to describe how such services > may best interconnect across administrative boundaries. > > More specifically, SPEERMINT will provide details of how Session > Establishment Data (SED) is collected, what comprises SED, how SED should be > used to properly identify an optimal path to a destination SIP user agent > (UA), and the secure manners in which SED and the SIP session data is > exchanged between the peering functions. > > It is also recognized that peering relationships become more complex as > multiple peers are added to a common relationship; these complex aspects and > requirements are defined within the contexts of a peering Federation. > > The DRINKS working group is chartered with a scope that is orthogonal to > SPEERMINT and ENUM. The protocol work OF DRINKS will be designed to build lowercase "OF". > from the work of SPEERMINT and ENUM to identify and define the data > structures and data exchange protocol(s) among SIP based Multimedia > administrative domains. > > These administrative domains may be of any practical size and could be any > type of SSP, such as recognized telephony carriers, enterprises, end-user > groups, or Federations. I think we have a problem here. IMHO we should not mix single SSPs (carriers, enterprises) with groups of SSPs (federations). This will bite us when doing the protocol design. User/numbers are always uniquely tied to a single SSP. This is the owner of that number. Or, in BGP speak, the origin. Federations do not have that property: as a SSP can be a member in multiple federations, his numbers/users appear in the data-set of more than one federation. Whenever these federation announce their routes to a yet another SSPs, it will get conflicting information. This doesn't jive with the "let's do simple registry provisioning" tone of this document. > Data exchanges among these administrative domains > may be bi-lateral or multi-lateral in nature, and could include bulk updates > and/or more granular real-time updates. > > Typical data includes the mapping of phone numbers to URIs, policies > surrounding admission to various points of network interconnection, and > various other types of interconnect data. In addition, there is a specific > need for the exchange of such data between the Registry and various types of > PSTN network databases. Whoa, hold your horses. "the Registry?" Nothing up to here requires a Registry. From the preceding paragraph: we're dealing with "bi-lateral or multi-lateral data exchanges". If two SSPs have a bi-lateral data exchange, they don't need a Registry. "multi-lateral" exchanges could also be facilitated by a simple data replicator, similar to the role of "route reflectors" in BGP. Yes, given your background, I can see why you assume that a "Registry" needs to be part of the solution, but this not a given at all. A "Registry" is just one potential solution. We should not prejudice that in the charter. > The working group will draw upon expert advice and on-going consultation > from the ENUM and SPEERMINT working groups, and also the XML Directorate. > The working group will consider the reuse of elements of RFC 4114. > > The final work product(s) from this working group will utilize and be based > on XML documents and XML document exchanges. > > PROPOSED GOALS AND MILESTONES > What about writing a High-level description of the overall VoIP routing architecture, players and data-flows. first? That is sorely missing in speermint. > > Requirements for Session Establishment Data (SED) data exchanges. > Sept 08 > > Provisioning of Session Establishment Data (SED) registries. > Nov 08 See comment re: registries above. > > Provisioning of Localized Session Establishment Data (SED) caches. > /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: 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 D6AB83A695F; Thu, 17 Apr 2008 07:21:27 -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 EF3BD3A67D5 for ; Thu, 17 Apr 2008 07:21:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.367 X-Spam-Level: X-Spam-Status: No, score=-2.367 tagged_above=-999 required=5 tests=[AWL=0.232, 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 b32JCCRBpUQz for ; Thu, 17 Apr 2008 07:21:26 -0700 (PDT) Received: from etmail.acmepacket.com (etmail.acmepacket.com [216.41.24.6]) by core3.amsl.com (Postfix) with ESMTP id 7206A3A68B4 for ; Thu, 17 Apr 2008 07:21:00 -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.263.0; Thu, 17 Apr 2008 10:21:08 -0400 Received: from mail.acmepacket.com ([216.41.24.7]) by mail.acmepacket.com ([216.41.24.7]) with mapi; Thu, 17 Apr 2008 10:21:08 -0400 From: Hadriel Kaplan To: Richard Shockey , "peppermint@ietf.org" Date: Thu, 17 Apr 2008 10:21:29 -0400 Thread-Topic: [PEPPERMINT] DRINKS PROPOSED Charter ..comments please. Thread-Index: Acif5hOzmNYlp/X0SiGV1jnC6pF21gABRFUAAANtXGAAJz+R4A== Message-ID: References: <125b01c89fe6$14f823c0$3ee86b40$@us> <173c01c89ff9$2302fa90$6908efb0$@us> In-Reply-To: <173c01c89ff9$2302fa90$6908efb0$@us> 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] DRINKS PROPOSED Charter ..comments please. X-BeenThere: peppermint@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Provisioning Extensions in Peering Registries for Multimedia INTerconnection List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: peppermint-bounces@ietf.org Errors-To: peppermint-bounces@ietf.org > -----Original Message----- > From: peppermint-bounces@ietf.org [mailto:peppermint-bounces@ietf.org] On > Behalf Of Richard Shockey > > Is this better. > > Requirements for Session Establishment Data (SED) data exchanges. > Sept 08 Yup, that's a good one. > Exchanging of Session Establishment Data (SED) from data providers to data > registries. > Nov 08 I think I can read that a couple different ways, but I'm ok with it. > Exchanging of Localized Session Establishment Data (SED) from data > registries to Lookup Function or Location Routing Function databases. > Feb 09 I think the term "data registries" is quite ambiguous, but I actually like that property of it, so I'm good with this too. :) -hadriel _______________________________________________ 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 2F84F3A6A58; Wed, 16 Apr 2008 18:15: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 2ED403A6A58 for ; Wed, 16 Apr 2008 18:15:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.513 X-Spam-Level: X-Spam-Status: No, score=-3.513 tagged_above=-999 required=5 tests=[AWL=0.086, 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 dC153xSuB1wF for ; Wed, 16 Apr 2008 18:15:27 -0700 (PDT) Received: from mail.songbird.com (mail.songbird.com [208.184.79.10]) by core3.amsl.com (Postfix) with ESMTP id 5F8BA28C492 for ; Wed, 16 Apr 2008 18:15:26 -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 m3H1EGIq017895 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Wed, 16 Apr 2008 18:14:19 -0700 From: "Richard Shockey" To: "'Dan York'" References: <125b01c89fe6$14f823c0$3ee86b40$@us> <6F1F1385-8781-491A-9FEA-C9AC440B0D65@voxeo.com> In-Reply-To: <6F1F1385-8781-491A-9FEA-C9AC440B0D65@voxeo.com> Date: Wed, 16 Apr 2008 21:15:01 -0400 Message-ID: <042601c8a028$78390d40$68ab27c0$@us> MIME-Version: 1.0 X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: AcigGarJ5xxLl6XYTXyOut8Je+tn9gADNUcA 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] DRINKS PROPOSED Charter ..comments please. 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, > > I do have one VERY serious problem with this revised charter. If the > group name is changed to DRINKS, then I will have lost my opportunity > to submit an Internet-Draft titled "draft-york-peppermint-pattie"[1]. > Although I suppose the new name does allow everyone to join in the > creative naming fun... I can just see... "draft-shockey-drinks-too- > many-sips"... "draft-bond-drinks-sip-shaken-not-stirred"... "draft- > kaplan-drinks-sips-with-no-identity-challenge"... Alas this is true .. I will no longer be known a Peppermint Patty but only as the Bartender, something I can professionally live with since in a earlier life I was a professional in the field. Again we must consider our overall obligations to the IETF for cute WG naming which we both agree will inspire much inspired document naming and hopefully some April 1 RFC's. Whatever it takes ... > > Seriously, it looks good overall and does make sense to change the > name. I do like how the charter makes it clear how DRINKS relates to > ENUM and SPEERMINT. Thanks are due not to me but to Daryl and Ken that did most of the heavy lifting. I was only the charter editor, if a somewhat bad typist. > > Outside of the nits Hadriel already pointed out, I'll only add a few > points embedded with "DY>": > > > > The DRINKS working group is chartered with a scope that is > > orthogonal to > > SPEERMINT and ENUM. The protocol work OF DRINKS will be designed to > > build > > DY> "OF" should be lowercase. TKS ..will do .. > > > Typical data includes the mapping of phone numbers to URIs, policies > > surrounding admission to various points of network interconnection, > > and > > various other types of interconnect data. In addition, there is a > > specific > > need for the exchange of such data between the Registry and various > > types of > > PSTN network databases. > > DY> Will you be changing this per Hadriel's comment to "a Registry"? Again yes you are correct the proper term is to "a" registry. > > DY> Do you see the data to be exchanged to also include information > using in billing? IMHO no .. that would be a charter stretch I personally believe the AD's/IESG would not accept, at this time. Remember this is a new WG. The first order of business is to produce results based on a limited set of initial tasks. On the basis of initial WG success it is always possible to build on success to take on other tasks the WG deems useful. > > DY> I see nothing in the charter about ensuring that the data is > exchanged securely between the various administrative domains but I > would assume this is a necessary requirement. Is that just an > implicit assumption that security will be covered in the Requirements > document? (i.e. no explicit statement is necessary in the charter?) A excellent point but all IETF WG documents have a explicit requirement to define any security issues associated with the protocol being defined. Therefore, as you point out, there is no explicit requirement to define security requirements in the charter. > > Regards, > Dan > > [1] For those outside North America who have perhaps never sampled the > candy, see: http://en.wikipedia.org/wiki/York_Peppermint_Pattie > -- > Dan York, CISSP, Director of Emerging Communication Technology > Office of the CTO Voxeo Corporation dyork@voxeo.com > Phone: +1-407-455-5859 Skype: danyork http://www.voxeo.com > Blogs: http://blogs.voxeo.com http://www.disruptivetelephony.com > > Build voice applications based on open standards. > Find out how at http://www.voxeo.com/free > > _______________________________________________ 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 D4D913A6B86; Wed, 16 Apr 2008 16:29: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 4B6DB3A6B86 for ; Wed, 16 Apr 2008 16:29:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.715 X-Spam-Level: X-Spam-Status: No, score=-1.715 tagged_above=-999 required=5 tests=[AWL=0.884, 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 ER7Q2MIT6DYx for ; Wed, 16 Apr 2008 16:29:23 -0700 (PDT) Received: from voxeo.com (mmail.voxeo.com [66.193.54.208]) by core3.amsl.com (Postfix) with ESMTP id 12CD63A6AED for ; Wed, 16 Apr 2008 16:29:22 -0700 (PDT) Received: from pc-00144.lodestar2.dyndns.org (account dyork [75.68.245.43] verified) by voxeo.com (CommuniGate Pro SMTP 5.1.14) with ESMTPSA id 30082199; Wed, 16 Apr 2008 23:29:57 +0000 Message-Id: <6F1F1385-8781-491A-9FEA-C9AC440B0D65@voxeo.com> From: Dan York To: Richard Shockey In-Reply-To: <125b01c89fe6$14f823c0$3ee86b40$@us> Mime-Version: 1.0 (Apple Message framework v919.2) Date: Wed, 16 Apr 2008 19:29:55 -0400 References: <125b01c89fe6$14f823c0$3ee86b40$@us> X-Mailer: Apple Mail (2.919.2) Cc: peppermint@ietf.org Subject: Re: [PEPPERMINT] DRINKS PROPOSED Charter ..comments please. 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, I do have one VERY serious problem with this revised charter. If the group name is changed to DRINKS, then I will have lost my opportunity to submit an Internet-Draft titled "draft-york-peppermint-pattie"[1]. Although I suppose the new name does allow everyone to join in the creative naming fun... I can just see... "draft-shockey-drinks-too- many-sips"... "draft-bond-drinks-sip-shaken-not-stirred"... "draft- kaplan-drinks-sips-with-no-identity-challenge"... Seriously, it looks good overall and does make sense to change the name. I do like how the charter makes it clear how DRINKS relates to ENUM and SPEERMINT. Outside of the nits Hadriel already pointed out, I'll only add a few points embedded with "DY>": > > The DRINKS working group is chartered with a scope that is > orthogonal to > SPEERMINT and ENUM. The protocol work OF DRINKS will be designed to > build DY> "OF" should be lowercase. > Typical data includes the mapping of phone numbers to URIs, policies > surrounding admission to various points of network interconnection, > and > various other types of interconnect data. In addition, there is a > specific > need for the exchange of such data between the Registry and various > types of > PSTN network databases. DY> Will you be changing this per Hadriel's comment to "a Registry"? DY> Do you see the data to be exchanged to also include information using in billing? DY> I see nothing in the charter about ensuring that the data is exchanged securely between the various administrative domains but I would assume this is a necessary requirement. Is that just an implicit assumption that security will be covered in the Requirements document? (i.e. no explicit statement is necessary in the charter?) Regards, Dan [1] For those outside North America who have perhaps never sampled the candy, see: http://en.wikipedia.org/wiki/York_Peppermint_Pattie -- Dan York, CISSP, Director of Emerging Communication Technology Office of the CTO Voxeo Corporation dyork@voxeo.com Phone: +1-407-455-5859 Skype: danyork http://www.voxeo.com Blogs: http://blogs.voxeo.com http://www.disruptivetelephony.com Build voice applications based on open standards. Find out how at http://www.voxeo.com/free _______________________________________________ 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 7CC5A3A6D33; Wed, 16 Apr 2008 12:36:00 -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 B1F6028C0DE for ; Wed, 16 Apr 2008 12:35:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.576 X-Spam-Level: X-Spam-Status: No, score=-3.576 tagged_above=-999 required=5 tests=[AWL=0.023, 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 EzpNIeVivsEz for ; Wed, 16 Apr 2008 12:35:59 -0700 (PDT) Received: from mail.songbird.com (mail.songbird.com [208.184.79.10]) by core3.amsl.com (Postfix) with ESMTP id 2674B28C1A7 for ; Wed, 16 Apr 2008 12:35:58 -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 m3GJZRKb018877 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Wed, 16 Apr 2008 12:35:29 -0700 From: "Richard Shockey" To: "'Hadriel Kaplan'" , References: <125b01c89fe6$14f823c0$3ee86b40$@us> In-Reply-To: Date: Wed, 16 Apr 2008 15:36:14 -0400 Message-ID: <173c01c89ff9$2302fa90$6908efb0$@us> MIME-Version: 1.0 X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: Acif5hOzmNYlp/X0SiGV1jnC6pF21gABRFUAAANtXGA= Content-Language: en-us X-SongbirdInformation: support@songbird.com for more information X-Songbird: Clean X-Songbird-From: richard@shockey.us Subject: Re: [PEPPERMINT] DRINKS PROPOSED Charter ..comments please. 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 TKS ... in line ... > > > > PROPOSED GOALS AND MILESTONES > > > > > > Requirements for Session Establishment Data (SED) data exchanges. > > Sept 08 > > > > Provisioning of Session Establishment Data (SED) registries. > > Nov 08 > > I think you mean "Data model of SED Registries"? (I'm not really quite > sure what this milestone is?) > > > Provisioning of Localized Session Establishment Data (SED) caches. > > I think you mean "Exchanging Session Establishment Data (SED) between > Lookup Function or Location Routing Function Databases." Is this better. Requirements for Session Establishment Data (SED) data exchanges. Sept 08 Exchanging of Session Establishment Data (SED) from data providers to data registries. Nov 08 Exchanging of Localized Session Establishment Data (SED) from data registries to Lookup Function or Location Routing Function databases. Feb 09 > > -hadriel _______________________________________________ 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 716CB3A6C0B; Wed, 16 Apr 2008 11:52:38 -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 683F328C179 for ; Wed, 16 Apr 2008 11:52:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.361 X-Spam-Level: X-Spam-Status: No, score=-2.361 tagged_above=-999 required=5 tests=[AWL=0.238, 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 PUpZMXcUJ2KP for ; Wed, 16 Apr 2008 11:52:32 -0700 (PDT) Received: from etmail.acmepacket.com (etmail.acmepacket.com [216.41.24.6]) by core3.amsl.com (Postfix) with ESMTP id 2344A3A6C9D for ; Wed, 16 Apr 2008 11:51:54 -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.263.0; Wed, 16 Apr 2008 14:46:52 -0400 Received: from mail.acmepacket.com ([216.41.24.7]) by mail.acmepacket.com ([216.41.24.7]) with mapi; Wed, 16 Apr 2008 14:05:33 -0400 From: Hadriel Kaplan To: Richard Shockey , "peppermint@ietf.org" Date: Wed, 16 Apr 2008 14:06:47 -0400 Thread-Topic: [PEPPERMINT] DRINKS PROPOSED Charter ..comments please. Thread-Index: Acif5hOzmNYlp/X0SiGV1jnC6pF21gABRFUA Message-ID: References: <125b01c89fe6$14f823c0$3ee86b40$@us> In-Reply-To: <125b01c89fe6$14f823c0$3ee86b40$@us> 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] DRINKS PROPOSED Charter ..comments please. X-BeenThere: peppermint@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Provisioning Extensions in Peering Registries for Multimedia INTerconnection List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: peppermint-bounces@ietf.org Errors-To: peppermint-bounces@ietf.org > -----Original Message----- > From: peppermint-bounces@ietf.org [mailto:peppermint-bounces@ietf.org] On > ************************ > DRINKS Proposed Charter > Data for Reachability of Inter/tra-NetworK SIP > Current Status: Proposed Working Group > > Mailing Lists: > peppermint@ietf.org We'll need a new mailing list name (or alias) for drinks@ietf.org. :) > General information about the mailing list is at: > https://www1.ietf.org/mailman/listinfo/peppermint > > > Area Directorate: Real Time Applications (RAI) > RAI Director(s): > Jon Peterson jon.peterson@neustar.biz > Cullen Jennings fluffy@cisco.com > Chairs: TBD > > PROPOSED CHARTER FOR PEPPERMINT > > The IETF has been working on various aspects of SIP-enabled Multimedia > administrative domains among SIP Service Providers (SSPs. SSP's are Typo: "(SSPs" should be "(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 ENUM and SPEERMINT working groups provide the underlying context for > much of the intended work that the DRINKS working group will undertake.: Remove last period, or last colon. > The ENUM working group is specifically chartered to develop protocols that > involve the translation of E.164 numbers to URIs. While the SPEERMINT > working group has been chartered to develop requirements and best current > practices among real-time application SSPs and to describe how such > services > may best interconnect across administrative boundaries. > > More specifically, SPEERMINT will provide details of how Session > Establishment Data (SED) is collected, what comprises SED, how SED should > be > used to properly identify an optimal path to a destination SIP user agent > (UA), and the secure manners in which SED and the SIP session data is > exchanged between the peering functions. > > It is also recognized that peering relationships become more complex as > multiple peers are added to a common relationship; these complex aspects > and > requirements are defined within the contexts of a peering Federation. > > The DRINKS working group is chartered with a scope that is orthogonal to > SPEERMINT and ENUM. The protocol work OF DRINKS will be designed to build > from the work of SPEERMINT and ENUM to identify and define the data > structures and data exchange protocol(s) among SIP based Multimedia > administrative domains. > > These administrative domains may be of any practical size and could be any > type of SSP, such as recognized telephony carriers, enterprises, end-user > groups, or Federations. Data exchanges among these administrative domains > may be bi-lateral or multi-lateral in nature, and could include bulk > updates > and/or more granular real-time updates. > > Typical data includes the mapping of phone numbers to URIs, policies > surrounding admission to various points of network interconnection, and > various other types of interconnect data. In addition, there is a > specific > need for the exchange of such data between the Registry and various types > of > PSTN network databases. Is there only one Registry? ;) Change "the Registry" to "a Registry". > The working group will draw upon expert advice and on-going consultation > from the ENUM and SPEERMINT working groups, and also the XML Directorate. > The working group will consider the reuse of elements of RFC 4114. > > The final work product(s) from this working group will utilize and be > based > on XML documents and XML document exchanges. > > > > PROPOSED GOALS AND MILESTONES > > > Requirements for Session Establishment Data (SED) data exchanges. > Sept 08 > > Provisioning of Session Establishment Data (SED) registries. > Nov 08 I think you mean "Data model of SED Registries"? (I'm not really quite sure what this milestone is?) > Provisioning of Localized Session Establishment Data (SED) caches. I think you mean "Exchanging Session Establishment Data (SED) between Lookup Function or Location Routing Function Databases." -hadriel _______________________________________________ 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 4091E3A6F95; Wed, 16 Apr 2008 10:19:40 -0700 (PDT) X-Original-To: peppermint@core3.amsl.com Delivered-To: peppermint@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 08E863A6AAE for ; Wed, 16 Apr 2008 10:19:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.574 X-Spam-Level: X-Spam-Status: No, score=-3.574 tagged_above=-999 required=5 tests=[AWL=0.025, 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 bJX5ucggexn8 for ; Wed, 16 Apr 2008 10:19:38 -0700 (PDT) Received: from mail.songbird.com (mail.songbird.com [208.184.79.10]) by core3.amsl.com (Postfix) with ESMTP id 216A83A6939 for ; Wed, 16 Apr 2008 10:19:38 -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 m3GHJ3E1011498 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO) for ; Wed, 16 Apr 2008 10:19:04 -0700 From: "Richard Shockey" To: Date: Wed, 16 Apr 2008 13:19:50 -0400 Message-ID: <125b01c89fe6$14f823c0$3ee86b40$@us> MIME-Version: 1.0 X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: Acif5hOzmNYlp/X0SiGV1jnC6pF21g== Content-Language: en-us X-SongbirdInformation: support@songbird.com for more information X-Songbird: Clean X-Songbird-From: richard@shockey.us Subject: [PEPPERMINT] DRINKS PROPOSED Charter ..comments please. 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 think I have incorporated most of the comments received to date based on Darlys first draft. More are certainly needed. Specifically thanks to Ken Cartwright who made excellent grammatical suggestions. ************************ DRINKS Proposed Charter Data for Reachability of Inter/tra-NetworK SIP Current Status: Proposed Working Group Mailing Lists: peppermint@ietf.org General information about the mailing list is at: https://www1.ietf.org/mailman/listinfo/peppermint Area Directorate: Real Time Applications (RAI) RAI Director(s): Jon Peterson jon.peterson@neustar.biz Cullen Jennings fluffy@cisco.com Chairs: TBD PROPOSED CHARTER FOR PEPPERMINT The IETF has been working on various aspects of SIP-enabled Multimedia administrative domains among SIP Service Providers (SSPs. SSP's are entities that provide session services utilizing SIP signaling to their customers. In addition, the IETF has done significant work on data exchanges among various network elements. The ENUM and SPEERMINT working groups provide the underlying context for much of the intended work that the DRINKS working group will undertake.: The ENUM working group is specifically chartered to develop protocols that involve the translation of E.164 numbers to URIs. While the SPEERMINT working group has been chartered to develop requirements and best current practices among real-time application SSPs and to describe how such services may best interconnect across administrative boundaries. More specifically, SPEERMINT will provide details of how Session Establishment Data (SED) is collected, what comprises SED, how SED should be used to properly identify an optimal path to a destination SIP user agent (UA), and the secure manners in which SED and the SIP session data is exchanged between the peering functions. It is also recognized that peering relationships become more complex as multiple peers are added to a common relationship; these complex aspects and requirements are defined within the contexts of a peering Federation. The DRINKS working group is chartered with a scope that is orthogonal to SPEERMINT and ENUM. The protocol work OF DRINKS will be designed to build from the work of SPEERMINT and ENUM to identify and define the data structures and data exchange protocol(s) among SIP based Multimedia administrative domains. These administrative domains may be of any practical size and could be any type of SSP, such as recognized telephony carriers, enterprises, end-user groups, or Federations. Data exchanges among these administrative domains may be bi-lateral or multi-lateral in nature, and could include bulk updates and/or more granular real-time updates. Typical data includes the mapping of phone numbers to URIs, policies surrounding admission to various points of network interconnection, and various other types of interconnect data. In addition, there is a specific need for the exchange of such data between the Registry and various types of PSTN network databases. The working group will draw upon expert advice and on-going consultation from the ENUM and SPEERMINT working groups, and also the XML Directorate. The working group will consider the reuse of elements of RFC 4114. The final work product(s) from this working group will utilize and be based on XML documents and XML document exchanges. 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. Richard Shockey Director, Member of the Technical Staff NeuStar 46000 Center Oak Plaza - Sterling, VA 20166 PSTN Office +1 571.434.5651 PSTN Mobile: +1 703.593.2683 _______________________________________________ PEPPERMINT mailing list PEPPERMINT@ietf.org https://www.ietf.org/mailman/listinfo/peppermint Return-Path: X-Original-To: peppermint-archive@optimus.ietf.org Delivered-To: ietfarch-peppermint-archive@core3.amsl.com Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 301BE28C34D; Mon, 14 Apr 2008 08:47:08 -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 C338128C346 for ; Mon, 14 Apr 2008 08:47:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.582 X-Spam-Level: X-Spam-Status: No, score=0.582 tagged_above=-999 required=5 tests=[AWL=0.445, BAYES_00=-2.599, HELO_EQ_MODEMCABLE=0.768, HOST_EQ_MODEMCABLE=1.368, J_CHICKENPOX_32=0.6] 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 pcnv9sDdF1kA for ; Mon, 14 Apr 2008 08:47:02 -0700 (PDT) Received: from ondar.cablelabs.com (ondar.cablelabs.com [192.160.73.61]) by core3.amsl.com (Postfix) with ESMTP id 1307228C344 for ; Mon, 14 Apr 2008 08:46:36 -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 m3EFl6hQ024108; Mon, 14 Apr 2008 09:47:06 -0600 Received: from srvxchg3.cablelabs.com (10.5.0.25) by kyzyl.cablelabs.com (F-Secure/fsigk_smtp/511/kyzyl.cablelabs.com); Mon, 14 Apr 2008 09:47:06 -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, 14 Apr 2008 09:46:53 -0600 Message-ID: <9AAEDF491EF7CA48AB587781B8F5D7C6010F1FA0@srvxchg3.cablelabs.com> In-Reply-To: <20080414144539.GA25892@nic.at> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [PEPPERMINT] Some comments on ESPP Thread-Index: AciePlN7X5cbLw0KQTW9z6CURRQMgAAB9Q8w References: <20080414144539.GA25892@nic.at> From: "Jean-Francois Mule" To: "Otmar Lendl" X-Approved: ondar Cc: peppermint@ietf.org Subject: Re: [PEPPERMINT] Some comments on ESPP 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 Otmar, Bob, Paul, and all of your who sent comments/issues re: ESPP Internet-Drafts: Thank you for the detailed comments. This is exactly the type of review comments we were hoping to get. Along with the other co-authors, we're taking notes of these comments and we plan to review them and send an aggregated response. Some comments may lead to bug fixes in the I-Ds, new email threads, etc. In the meantime, just wanted to ack the receipt of these and say thanks for taking the time to read this. More later. Jean-Francois. > -----Original Message----- > From: peppermint-bounces@ietf.org [mailto:peppermint- > bounces@ietf.org] On Behalf Of Otmar Lendl > Sent: Monday, April 14, 2008 8:46 AM > To: peppermint@ietf.org > Subject: [PEPPERMINT] Some comments on ESPP > > > I've meant to send a detailed review of ESPP for a while now, some > fragements of which have be languishing in my draft-mail folder. > > To get things moving, here are my (incomplete) notes on ESPP: > > --------------------- > > I've now read the ESPP drafts; these are valuable contributions > both > to the peppermint bof, als well as to the speermint WG. > > There are some good ideas in ESPP, as well as (IMHO) problems. > > First of all, let's take a look at the data model which underpin > ESPP: > > ----- > > +------------ > ----+ > A Route is associated with |NAPTR: > | > +----------------+ zero or more SBE NAPTRs. > |id,enterpriseId,| > | |--------------------------->|order,pref, > | > |Route: | NAPTRs associated with > |flags,svcs,regx,| > |id,enterpriseId,| Routes are not User or TN > |repl,extension | > |routeName, | specific. The user portion +------------ > ----+ > |isLnService, | of the regex will be "\\1". > |sbeNAPTRs, | +------------ > ----+ > |extension | |Egress > Route: | > | |<--------------------------- > |id,enterpriseId,| > +----------------+ An EgressRoute is > |routeIds,pref, | > ^ associated with zero or |svcs, > | > A Service Area | more Routes. > |regxRewriteRule,| > is associated | |extension > | > with 1 or more | +------------ > ----+ > Routes | > +----------------+ > |Service Area: | > |id,enterpriseId,| > +--->|ServiceAreaName,|<---+ > | |routeIds, | | > | |extension | | > | +----------------+ | > |An LRN is |A TNRange is |A Public > |associated |associated |Identify is > |with only 1 |with only 1 |associated > |Service |Service |with zero or > |Area. |Area. |1 Service Area. > | | | > +--------------++--------------++--------------+ +------------ > --+ > |LRN: ||TNRange: ||Public | |NAPTR: > | > |id, ||id, ||Identity: | |id, > | > |enterpriseId, ||enterpriseId, ||id, | > |enterpriseId, | > |lrn, ||tnRangeStart, ||enterpriseId, |-->|order,pref, > | > |serviceAreaId,||tnRangeEnd, ||lrn, | |flags,svcs, > | > |extension ||serviceAreaId,||serviceAreaId,| |regx,repl, > | > | ||extension ||extension | |extension > | > +--------------++--------------++--------------+ +------------ > --+ > | > A Public Identity | Multiple Public > is associated with | Identities can > zero or 1 Private | be associated > Identity | with 1 Private > | Identity > | > | > | > | > | > V > +----------------+ > |Private | > |Identity: | > |id, | > |enterpriseId, | > |privateIdentity,| > |extension | > +----------------+ > ----- > > As I view this design, it has two parts: > > (1) Mapping endpoint addresses to ServiceAreas > (2) Routing information for ServiceAreas > > This separation is a good idea. You should never attach routing > information directly to phone numbers. You first apply some mapping > step > to an aggregation object, to which the routing information is > attached. > > As the draft notes, the potential update-patterns are different in > these two areas. > > The information in (1) is potentially *huge*; changes are caused by > the normal churn of customers between providers. This will be a > steady > stream of updates (without hard realtime requirements), punctured > by > occasional bulk updates (network grooming, mergers, ...) plus large > initial data loads. > > This is basically a classic example of a directory: the information > is > independent on who is asking, data-set is huge, update frequency > harmless. > > Comparing (1) to > draft-schwartz-peppermint-consolidated-provisioning-problem- > statement-00 > I find a very good match: This is exactly what David & co describe > in > their draft. > > The upper part in the diagram, i.e. (2), is different. This is > routing data, > pure and simple. > > Here is the point, where I can't follow the authors of ESPP: You > don't > "provision" inter-provider routing table entries. That's telco- > thinking. > That is maybe IP routing of the 80's. Having a human enter a such a > route into the ESPP system sounds to me like adding a static route > to an > IP router. > > Yes, you do that on the customer facing interface, but you cetainly > don't do that on a peering router. On a peering router, you > configure > the basic parameters of a routing protocol: where are the peers, > which > routes to announce, and which conditions learned routes must > fulfill. > Manual traffic engineering is done by tweaking the routing > protocol, > weighing routes differently based on various criteria, but *never* > by > hardcoding routes into the system. > > I may be oversensitive to the difference between "provisioning" and > "routing", but this is crucial towards the direction of speermint > and > peppermint. > > ---- > > Other comments: > > * ServiceArea > > As I wrote above, the concept is sound. We need such an aggregation > scheme. I'm a bit worried, though, that the "ServiceArea" term is > quite > specific to the US cable landscape with operators serving > geographically > disjunct regions. > > What about a scenario where multiple operators serve the same area, > with number porting between them. ServiceArea "Brooklyn" thus isn't > specific to a single carrier. I'm not quite sure how that fits into > this scheme. > > * NAPTR > > A provisioning protocol should not be overly tied to the specifics > of > the query protocol. I'd feel more comfortable with a provision > system > which deals with generic routing information. Whether that > information > is then passed to the switches by means of an ENUM response, or via > dumping some sort of proprietary database into the switches should > be of > no concern to the provisioning. > > NAPTRs are a quirk of the ENUM protocol. They are not the most > natural > data format for routing information. > > * Transit > > I won't make myself popular by bringing this up, but we need to > keep the > requirements of provisioning transit in the back of our head. > > Like it or not, but we will have to be prepared for it. > > What would that mean for ESPP? > > I see two basic approaches to implement transit with ESPP: > > a) The transit operator announces mappings and routes towards the > destination network as they were part of his own network. Perhaps > with a > special ServiceArea designation, but otherwise no changes. > > b) The transit operator re-injects number->ServiceArea mappings > unchanged into the other ESPP domain, and only creates new Route > objects > announcing the path via this transit operator. > > In both cases, it will happen that potential source networks see > competing announcements towards a destination. As I have read ESPP, > this > has not been considered. > > /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 _______________________________________________ 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 A35A23A695A; Mon, 14 Apr 2008 07:45:57 -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 1B01028C311 for ; Mon, 14 Apr 2008 07:45:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.99 X-Spam-Level: X-Spam-Status: No, score=-0.99 tagged_above=-999 required=5 tests=[AWL=-0.160, BAYES_00=-2.599, HELO_EQ_AT=0.424, HOST_EQ_AT=0.745, J_CHICKENPOX_32=0.6] 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 VhU25VDn5QQm for ; Mon, 14 Apr 2008 07:45:55 -0700 (PDT) Received: from labs.nic.at (nat.labs.nic.at [83.136.33.3]) by core3.amsl.com (Postfix) with ESMTP id 8A9B33A6BED for ; Mon, 14 Apr 2008 07:45:11 -0700 (PDT) Received: from lendl by labs.nic.at with local (Exim 3.36 #1 (Debian)) id 1JlPwB-0006kI-00 for ; Mon, 14 Apr 2008 16:45:39 +0200 Date: Mon, 14 Apr 2008 16:45:39 +0200 From: Otmar Lendl To: peppermint@ietf.org Message-ID: <20080414144539.GA25892@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 ESPP 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've meant to send a detailed review of ESPP for a while now, some fragements of which have be languishing in my draft-mail folder. To get things moving, here are my (incomplete) notes on ESPP: --------------------- I've now read the ESPP drafts; these are valuable contributions both to the peppermint bof, als well as to the speermint WG. There are some good ideas in ESPP, as well as (IMHO) problems. First of all, let's take a look at the data model which underpin ESPP: ----- +----------------+ A Route is associated with |NAPTR: | +----------------+ zero or more SBE NAPTRs. |id,enterpriseId,| | |--------------------------->|order,pref, | |Route: | NAPTRs associated with |flags,svcs,regx,| |id,enterpriseId,| Routes are not User or TN |repl,extension | |routeName, | specific. The user portion +----------------+ |isLnService, | of the regex will be "\\1". |sbeNAPTRs, | +----------------+ |extension | |Egress Route: | | |<---------------------------|id,enterpriseId,| +----------------+ An EgressRoute is |routeIds,pref, | ^ associated with zero or |svcs, | A Service Area | more Routes. |regxRewriteRule,| is associated | |extension | with 1 or more | +----------------+ Routes | +----------------+ |Service Area: | |id,enterpriseId,| +--->|ServiceAreaName,|<---+ | |routeIds, | | | |extension | | | +----------------+ | |An LRN is |A TNRange is |A Public |associated |associated |Identify is |with only 1 |with only 1 |associated |Service |Service |with zero or |Area. |Area. |1 Service Area. | | | +--------------++--------------++--------------+ +--------------+ |LRN: ||TNRange: ||Public | |NAPTR: | |id, ||id, ||Identity: | |id, | |enterpriseId, ||enterpriseId, ||id, | |enterpriseId, | |lrn, ||tnRangeStart, ||enterpriseId, |-->|order,pref, | |serviceAreaId,||tnRangeEnd, ||lrn, | |flags,svcs, | |extension ||serviceAreaId,||serviceAreaId,| |regx,repl, | | ||extension ||extension | |extension | +--------------++--------------++--------------+ +--------------+ | A Public Identity | Multiple Public is associated with | Identities can zero or 1 Private | be associated Identity | with 1 Private | Identity | | | | | V +----------------+ |Private | |Identity: | |id, | |enterpriseId, | |privateIdentity,| |extension | +----------------+ ----- As I view this design, it has two parts: (1) Mapping endpoint addresses to ServiceAreas (2) Routing information for ServiceAreas This separation is a good idea. You should never attach routing information directly to phone numbers. You first apply some mapping step to an aggregation object, to which the routing information is attached. As the draft notes, the potential update-patterns are different in these two areas. The information in (1) is potentially *huge*; changes are caused by the normal churn of customers between providers. This will be a steady stream of updates (without hard realtime requirements), punctured by occasional bulk updates (network grooming, mergers, ...) plus large initial data loads. This is basically a classic example of a directory: the information is independent on who is asking, data-set is huge, update frequency harmless. Comparing (1) to draft-schwartz-peppermint-consolidated-provisioning-problem-statement-00 I find a very good match: This is exactly what David & co describe in their draft. The upper part in the diagram, i.e. (2), is different. This is routing data, pure and simple. Here is the point, where I can't follow the authors of ESPP: You don't "provision" inter-provider routing table entries. That's telco-thinking. That is maybe IP routing of the 80's. Having a human enter a such a route into the ESPP system sounds to me like adding a static route to an IP router. Yes, you do that on the customer facing interface, but you cetainly don't do that on a peering router. On a peering router, you configure the basic parameters of a routing protocol: where are the peers, which routes to announce, and which conditions learned routes must fulfill. Manual traffic engineering is done by tweaking the routing protocol, weighing routes differently based on various criteria, but *never* by hardcoding routes into the system. I may be oversensitive to the difference between "provisioning" and "routing", but this is crucial towards the direction of speermint and peppermint. ---- Other comments: * ServiceArea As I wrote above, the concept is sound. We need such an aggregation scheme. I'm a bit worried, though, that the "ServiceArea" term is quite specific to the US cable landscape with operators serving geographically disjunct regions. What about a scenario where multiple operators serve the same area, with number porting between them. ServiceArea "Brooklyn" thus isn't specific to a single carrier. I'm not quite sure how that fits into this scheme. * NAPTR A provisioning protocol should not be overly tied to the specifics of the query protocol. I'd feel more comfortable with a provision system which deals with generic routing information. Whether that information is then passed to the switches by means of an ENUM response, or via dumping some sort of proprietary database into the switches should be of no concern to the provisioning. NAPTRs are a quirk of the ENUM protocol. They are not the most natural data format for routing information. * Transit I won't make myself popular by bringing this up, but we need to keep the requirements of provisioning transit in the back of our head. Like it or not, but we will have to be prepared for it. What would that mean for ESPP? I see two basic approaches to implement transit with ESPP: a) The transit operator announces mappings and routes towards the destination network as they were part of his own network. Perhaps with a special ServiceArea designation, but otherwise no changes. b) The transit operator re-injects number->ServiceArea mappings unchanged into the other ESPP domain, and only creates new Route objects announcing the path via this transit operator. In both cases, it will happen that potential source networks see competing announcements towards a destination. As I have read ESPP, this has not been considered. /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: 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 3AD0728C0E8; Fri, 11 Apr 2008 13:43:22 -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 94AC73A6D9F for ; Fri, 11 Apr 2008 13:43:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id u79sXKjAjbSg for ; Fri, 11 Apr 2008 13:43:19 -0700 (PDT) Received: from peregrine.verisign.com (peregrine.verisign.com [216.168.239.74]) by core3.amsl.com (Postfix) with ESMTP id 927AF3A6C98 for ; Fri, 11 Apr 2008 13:43:19 -0700 (PDT) Received: from dul1wnexcn02.vcorp.ad.vrsn.com (dul1wnexcn02.vcorp.ad.vrsn.com [10.170.12.139]) by peregrine.verisign.com (8.13.6/8.13.4) with ESMTP id m3BKWFaJ022171 for ; Fri, 11 Apr 2008 16:32:15 -0400 Received: from DUL1WNEXMB05.vcorp.ad.vrsn.com ([10.170.12.240]) by dul1wnexcn02.vcorp.ad.vrsn.com with Microsoft SMTPSVC(6.0.3790.3959); Fri, 11 Apr 2008 16:43:42 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Fri, 11 Apr 2008 16:43:41 -0400 Message-ID: In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: PEPPERMINT Digest, Vol 10, Issue 18 Thread-Index: AciaqNZPHt9raabXTzq/4/tjIHoC3AAcXYEQAA6UmbAAJmR2EAAB8qVgAAedpoA= From: "Cartwright, Kenneth" To: X-OriginalArrivalTime: 11 Apr 2008 20:43:42.0779 (UTC) FILETIME=[BAD3F0B0:01C89C14] Subject: Re: [PEPPERMINT] PEPPERMINT Digest, Vol 10, Issue 18 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'm not implying provisioning isn't in scope - I'm implying provisioning isn't constraining the scope" Ahhh, perfect. Got it. Ken. -----Original Message----- From: Hadriel Kaplan [mailto:HKaplan@acmepacket.com] Sent: Friday, April 11, 2008 4:37 PM To: Cartwright, Kenneth; peppermint@ietf.org Subject: RE: PEPPERMINT Digest, Vol 10, Issue 18 Right, but I'm not implying provisioning isn't in scope - I'm implying provisioning isn't constraining the scope. In other words, provisioning is a specific subset form of "data exchange", and "data exchange" does not have to be provisioning. To make this more concrete, I'll use an example: ESPP. Not that we are or are not going to use any form of ESPP, but it was presented as one possible example to show that the chartered work is technically do-able. ESPP, as defined, certainly could be used for true "provisioning" as most people mean that term. But the minute the information pushed/pulled by ESPP is not authoritative to the client - i.e., if it can be modified, post-processed, manipulated, filtered, ignored, etc., it ceases to be provisioning in the common sense of the word. (or at least causes confusion to people who use "provisioning" in the authoritative sense, as one would do from an Element Management System, for example) And ESPP may well have that lesser-control semantic when really used. Thus, I think it's safer if we ignore the loaded term, and just define the actual requirements we want/need in the WG itself. -hadriel > -----Original Message----- > From: peppermint-bounces@ietf.org [mailto:peppermint-bounces@ietf.org] > On Behalf Of Cartwright, Kenneth > Sent: Friday, April 11, 2008 12:16 PM > To: peppermint@ietf.org > Subject: Re: [PEPPERMINT] PEPPERMINT Digest, Vol 10, Issue 18 > > Thanks for this background. That helps somewhat. So once I see the > next version of the charter I'll better understand what you mean by > the statement "Peppermint is not provisioning, or at least not how > they mean that word". This statement certainly surprises me, which > means that there is certainly a disconnect somewhere (and maybe that > "somewhere" is > me) that needs to be addressed. The presentations and discussions > that I've observed at both of the BOFs, and my reading of the charter, > makes it clear, to me at least, that provisioning (as I use the word) > is definitely in the scope of the WG. If it's not then that is, > needless to say, a vital item for the charter to make clear, imho. > > Ken > _______________________________________________ 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 ABF263A6B05; Fri, 11 Apr 2008 13:33: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 ABB693A6B05 for ; Fri, 11 Apr 2008 13:33:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.323 X-Spam-Level: X-Spam-Status: No, score=-2.323 tagged_above=-999 required=5 tests=[AWL=0.276, 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 RsCsevKKqa5H for ; Fri, 11 Apr 2008 13:33:37 -0700 (PDT) Received: from etmail.acmepacket.com (etmail.acmepacket.com [216.41.24.6]) by core3.amsl.com (Postfix) with ESMTP id A78123A6984 for ; Fri, 11 Apr 2008 13:33:37 -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; Fri, 11 Apr 2008 16:33:32 -0400 Received: from mail.acmepacket.com ([216.41.24.7]) by mail.acmepacket.com ([216.41.24.7]) with mapi; Fri, 11 Apr 2008 16:33:32 -0400 From: Hadriel Kaplan To: "Cartwright, Kenneth" , "peppermint@ietf.org" Date: Fri, 11 Apr 2008 16:36:33 -0400 Thread-Topic: PEPPERMINT Digest, Vol 10, Issue 18 Thread-Index: AciaqNZPHt9raabXTzq/4/tjIHoC3AAcXYEQAA6UmbAAJmR2EAAB8qVg Message-ID: References: In-Reply-To: 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] PEPPERMINT Digest, Vol 10, Issue 18 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 Right, but I'm not implying provisioning isn't in scope - I'm implying provisioning isn't constraining the scope. In other words, provisioning is a specific subset form of "data exchange", and "data exchange" does not have to be provisioning. To make this more concrete, I'll use an example: ESPP. Not that we are or are not going to use any form of ESPP, but it was presented as one possible example to show that the chartered work is technically do-able. ESPP, as defined, certainly could be used for true "provisioning" as most people mean that term. But the minute the information pushed/pulled by ESPP is not authoritative to the client - i.e., if it can be modified, post-processed, manipulated, filtered, ignored, etc., it ceases to be provisioning in the common sense of the word. (or at least causes confusion to people who use "provisioning" in the authoritative sense, as one would do from an Element Management System, for example) And ESPP may well have that lesser-control semantic when really used. Thus, I think it's safer if we ignore the loaded term, and just define the actual requirements we want/need in the WG itself. -hadriel > -----Original Message----- > From: peppermint-bounces@ietf.org [mailto:peppermint-bounces@ietf.org] On > Behalf Of Cartwright, Kenneth > Sent: Friday, April 11, 2008 12:16 PM > To: peppermint@ietf.org > Subject: Re: [PEPPERMINT] PEPPERMINT Digest, Vol 10, Issue 18 > > Thanks for this background. That helps somewhat. So once I see the > next version of the charter I'll better understand what you mean by the > statement "Peppermint is not provisioning, or at least not how they mean > that word". This statement certainly surprises me, which means that > there is certainly a disconnect somewhere (and maybe that "somewhere" is > me) that needs to be addressed. The presentations and discussions that > I've observed at both of the BOFs, and my reading of the charter, makes > it clear, to me at least, that provisioning (as I use the word) is > definitely in the scope of the WG. If it's not then that is, needless > to say, a vital item for the charter to make clear, imho. > > Ken > _______________________________________________ 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 8737F3A6ABA; Fri, 11 Apr 2008 09:15: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 6F1A63A695C for ; Fri, 11 Apr 2008 09:15:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id aYiqFpPqDax9 for ; Fri, 11 Apr 2008 09:15:40 -0700 (PDT) Received: from peregrine.verisign.com (peregrine.verisign.com [216.168.239.74]) by core3.amsl.com (Postfix) with ESMTP id DD62E3A6E76 for ; Fri, 11 Apr 2008 09:15:39 -0700 (PDT) Received: from dul1wnexcn02.vcorp.ad.vrsn.com (dul1wnexcn02.vcorp.ad.vrsn.com [10.170.12.139]) by peregrine.verisign.com (8.13.6/8.13.4) with ESMTP id m3BG4Zdf006320 for ; Fri, 11 Apr 2008 12:04:35 -0400 Received: from DUL1WNEXMB05.vcorp.ad.vrsn.com ([10.170.12.240]) by dul1wnexcn02.vcorp.ad.vrsn.com with Microsoft SMTPSVC(6.0.3790.3959); Fri, 11 Apr 2008 12:16:02 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Fri, 11 Apr 2008 12:16:01 -0400 Message-ID: In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: PEPPERMINT Digest, Vol 10, Issue 18 Thread-Index: AciaqNZPHt9raabXTzq/4/tjIHoC3AAcXYEQAA6UmbAAJmR2EA== From: "Cartwright, Kenneth" To: X-OriginalArrivalTime: 11 Apr 2008 16:16:02.0627 (UTC) FILETIME=[563B3930:01C89BEF] Subject: Re: [PEPPERMINT] PEPPERMINT Digest, Vol 10, Issue 18 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 Thanks for this background. That helps somewhat. So once I see the next version of the charter I'll better understand what you mean by the statement "Peppermint is not provisioning, or at least not how they mean that word". This statement certainly surprises me, which means that there is certainly a disconnect somewhere (and maybe that "somewhere" is me) that needs to be addressed. The presentations and discussions that I've observed at both of the BOFs, and my reading of the charter, makes it clear, to me at least, that provisioning (as I use the word) is definitely in the scope of the WG. If it's not then that is, needless to say, a vital item for the charter to make clear, imho. Ken -----Original Message----- From: Hadriel Kaplan [mailto:HKaplan@acmepacket.com] Sent: Thursday, April 10, 2008 6:05 PM To: Cartwright, Kenneth; peppermint@ietf.org Subject: RE: PEPPERMINT Digest, Vol 10, Issue 18 Right, so it was entirely off-line, and the reason I started it that way was because I didn't want to cause any possible disruption to this group getting its charter approved and WG formed. So I basically consulted with the BoF chairs and a few other folks to see if they felt (1) it wasn't important what the name was, or (2) if it would be better to let sleeping dogs lie. Normally I wouldn't care about such things, because like you, I know the charter is what matters. I like the current charter just fine. But in the last 3 weeks I have had to explain to at least 6 people that Peppermint is not provisioning, or at least not how they mean that word. (of the 6 people, 3 attend the IETF and are active in the RAI area) So methinks it safer/better if we can avoid that term and its baggage. We could argue about what the term truly means, and whether the current charter truly means it, and so on. But if we just remove the term and leave the charter as is, we can argue about the specific requirements and proposals based on the charter in the WG after it's formed, rather than that particular term's definition now or even then. (because I bet if you ask two people what it means you'll get three answers :) As to the DRINK vs. PEPPERMINT - I also came up with alternative expansions for "Peppermint" that avoided the term provisioning, as well as a few alternative new names, and DRINKS seemed to wet people's thirst for a new name. ;) -hadriel > -----Original Message----- > From: peppermint-bounces@ietf.org [mailto:peppermint-bounces@ietf.org] > On Behalf Of Cartwright, Kenneth > Sent: Thursday, April 10, 2008 11:08 AM > To: peppermint@ietf.org > Subject: Re: [PEPPERMINT] PEPPERMINT Digest, Vol 10, Issue 18 > > First off, it's good to know that the off-line discussions were > "serious". :-) Secondly, I went back a couple weeks through the > PEPPERMINT emails in my inbox but did not find mention of this subject > of the term "provisioning" being problematic. SO I guess this subject > occurred entirely offline. If not, can you please refer to an > approximate date where this was captured in a PEPPERMINT email, > perhaps I missed it. If the discussion was entirely off-line can you > please just provide a sentence or two on the reasoning? > > I would guess that the reasoning may be something along these lines: > > 1) The term provisioning is ill defined. > 2) The term provisioning may be interpreted by some as too limiting or > too broad. > 3) Depending on ones definition of "provisioning", the WG may work on > items that have nothing to do with provisioning. > > However, while the above points may be accurate, I'm not sure how > changing the WG name from "PEPPERMINT" to "DRINKS" helps in a > meaningful manner. It seems that the content of the WG Charter is > more important in providing the necessary clarity than the name of the WG. > > In short, my $.02 is that changing the name of the WG from PEPPERMINT > to DRINKS is just fine. But, more importantly, I'd like to see how > this name change impacts the content of the Charter. > > Ken > > -----Original Message----- > From: peppermint-bounces@ietf.org [mailto:peppermint-bounces@ietf.org] > On Behalf Of peppermint-request@ietf.org > Sent: Wednesday, April 09, 2008 9:18 PM > To: peppermint@ietf.org > Subject: PEPPERMINT Digest, Vol 10, Issue 18 > > 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. New name for the WG... consensus desired (Richard Shockey) > > > ---------------------------------------------------------------------- > > Message: 1 > Date: Wed, 9 Apr 2008 21:18:13 -0400 > From: "Richard Shockey" > Subject: [PEPPERMINT] New name for the WG... consensus desired > To: > Message-ID: <021601c89aa8$c0a9b5f0$41fd21d0$@us> > Content-Type: text/plain; charset="US-ASCII" > > In some serious off line discussions, there was a suggestion that > PEPPERMINT might not be the most appropriate WG name since the concept > of provisioning has very specific context in teleco world. > > What we are dealing with is data exchanges. > > Hense the suggestion of a new WG name > > DRINKS > > Data for Reachability of Inter/tra-NetworK SIP > > Personally I think this is a perfect IETF WG name and meets all the > criterion of cuteness, banality, etc. and extremely appropriate given > the venue of a probably first meeting ..Dublin . > > We'd like to get a consensus if the change of name is appropriate. > > > > 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 > > > End of PEPPERMINT Digest, Vol 10, Issue 18 > ****************************************** > _______________________________________________ > 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 9F5BD3A6BE3; Thu, 10 Apr 2008 16:45: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 A985D3A690B for ; Thu, 10 Apr 2008 16:45:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.498 X-Spam-Level: X-Spam-Status: No, score=-3.498 tagged_above=-999 required=5 tests=[AWL=0.101, 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 3EqbqBZvF5W9 for ; Thu, 10 Apr 2008 16:45:30 -0700 (PDT) Received: from mail.songbird.com (mail.songbird.com [208.184.79.10]) by core3.amsl.com (Postfix) with ESMTP id 93E0E3A69B6 for ; Thu, 10 Apr 2008 16:45:25 -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 m3ANigaM009117 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Thu, 10 Apr 2008 16:44:44 -0700 From: "Richard Shockey" To: "'Hadriel Kaplan'" , "'Cartwright, Kenneth'" , References: In-Reply-To: Date: Thu, 10 Apr 2008 19:45:17 -0400 Message-ID: <027801c89b64$eff86f10$cfe94d30$@us> MIME-Version: 1.0 X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: AciaqNZPHt9raabXTzq/4/tjIHoC3AAcXYEQAA6UmbAAA+c6YA== Content-Language: en-us X-SongbirdInformation: support@songbird.com for more information X-Songbird: Clean X-Songbird-From: richard@shockey.us Subject: Re: [PEPPERMINT] PEPPERMINT Digest, Vol 10, Issue 18 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 Thanks Hadriel ..for this public explanation. As I pointed out earlier this distinction of provisioning vs data exchanges seems semantically trivial but is not. Your experiences in describing the WG clearly indicated a potential problem. The whole conversation is important to Daryl who hopefully will have v2 of the draft charter shortly. I would very much like to wrap up the charter discussion very shortly so we can submit something to the RAI AD's in a timely fashion. In any event we can submit both WG names to the IESG but I have a suspicion which one the will prefer. :-) > -----Original Message----- > From: peppermint-bounces@ietf.org [mailto:peppermint-bounces@ietf.org] > On Behalf Of Hadriel Kaplan > Sent: Thursday, April 10, 2008 6:05 PM > To: Cartwright, Kenneth; peppermint@ietf.org > Subject: Re: [PEPPERMINT] PEPPERMINT Digest, Vol 10, Issue 18 > > > Right, so it was entirely off-line, and the reason I started it that > way was because I didn't want to cause any possible disruption to this > group getting its charter approved and WG formed. So I basically > consulted with the BoF chairs and a few other folks to see if they > felt (1) it wasn't important what the name was, or (2) if it would be > better to let sleeping dogs lie. > > Normally I wouldn't care about such things, because like you, I know > the charter is what matters. I like the current charter just fine. > But in the last 3 weeks I have had to explain to at least 6 people > that Peppermint is not provisioning, or at least not how they mean > that word. (of the 6 people, 3 attend the IETF and are active in the > RAI area) So methinks it safer/better if we can avoid that term and > its baggage. > > We could argue about what the term truly means, and whether the > current charter truly means it, and so on. But if we just remove the > term and leave the charter as is, we can argue about the specific > requirements and proposals based on the charter in the WG after it's > formed, rather than that particular term's definition now or even > then. (because I bet if you ask two people what it means you'll get > three answers :) > > As to the DRINK vs. PEPPERMINT - I also came up with alternative > expansions for "Peppermint" that avoided the term provisioning, as > well as a few alternative new names, and DRINKS seemed to wet people's > thirst for a new name. ;) > > -hadriel > > > > -----Original Message----- > > From: peppermint-bounces@ietf.org [mailto:peppermint- > bounces@ietf.org] On > > Behalf Of Cartwright, Kenneth > > Sent: Thursday, April 10, 2008 11:08 AM > > To: peppermint@ietf.org > > Subject: Re: [PEPPERMINT] PEPPERMINT Digest, Vol 10, Issue 18 > > > > First off, it's good to know that the off-line discussions were > > "serious". :-) Secondly, I went back a couple weeks through the > > PEPPERMINT emails in my inbox but did not find mention of this > subject > > of the term "provisioning" being problematic. SO I guess this > subject > > occurred entirely offline. If not, can you please refer to an > > approximate date where this was captured in a PEPPERMINT email, > perhaps > > I missed it. If the discussion was entirely off-line can you please > > just provide a sentence or two on the reasoning? > > > > I would guess that the reasoning may be something along these lines: > > > > 1) The term provisioning is ill defined. > > 2) The term provisioning may be interpreted by some as too limiting > or > > too broad. > > 3) Depending on ones definition of "provisioning", the WG may work > on > > items that have nothing to do with provisioning. > > > > However, while the above points may be accurate, I'm not sure how > > changing the WG name from "PEPPERMINT" to "DRINKS" helps in a > meaningful > > manner. It seems that the content of the WG Charter is more > important > > in providing the necessary clarity than the name of the WG. > > > > In short, my $.02 is that changing the name of the WG from > PEPPERMINT to > > DRINKS is just fine. But, more importantly, I'd like to see how > this > > name change impacts the content of the Charter. > > > > Ken > > > > -----Original Message----- > > From: peppermint-bounces@ietf.org [mailto:peppermint- > bounces@ietf.org] > > On Behalf Of peppermint-request@ietf.org > > Sent: Wednesday, April 09, 2008 9:18 PM > > To: peppermint@ietf.org > > Subject: PEPPERMINT Digest, Vol 10, Issue 18 > > > > 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. New name for the WG... consensus desired (Richard Shockey) > > > > > > -------------------------------------------------------------------- > -- > > > > Message: 1 > > Date: Wed, 9 Apr 2008 21:18:13 -0400 > > From: "Richard Shockey" > > Subject: [PEPPERMINT] New name for the WG... consensus desired > > To: > > Message-ID: <021601c89aa8$c0a9b5f0$41fd21d0$@us> > > Content-Type: text/plain; charset="US-ASCII" > > > > In some serious off line discussions, there was a suggestion that > > PEPPERMINT might not be the most appropriate WG name since the > concept > > of provisioning has very specific context in teleco world. > > > > What we are dealing with is data exchanges. > > > > Hense the suggestion of a new WG name > > > > DRINKS > > > > Data for Reachability of Inter/tra-NetworK SIP > > > > Personally I think this is a perfect IETF WG name and meets all the > > criterion of cuteness, banality, etc. and extremely appropriate > given > > the venue of a probably first meeting ..Dublin . > > > > We'd like to get a consensus if the change of name is appropriate. > > > > > > > > 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 > > > > > > End of PEPPERMINT Digest, Vol 10, Issue 18 > > ****************************************** > > _______________________________________________ > > 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 365A03A6C60; Thu, 10 Apr 2008 15:05:36 -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 7C62F3A6D5C for ; Thu, 10 Apr 2008 15:05:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.315 X-Spam-Level: X-Spam-Status: No, score=-2.315 tagged_above=-999 required=5 tests=[AWL=0.284, 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 e5wBKNNi3mR6 for ; Thu, 10 Apr 2008 15:05:30 -0700 (PDT) Received: from etmail.acmepacket.com (etmail.acmepacket.com [216.41.24.6]) by core3.amsl.com (Postfix) with ESMTP id C50B128C1FD for ; Thu, 10 Apr 2008 15:05: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; Thu, 10 Apr 2008 18:05:00 -0400 Received: from mail.acmepacket.com ([216.41.24.7]) by mail.acmepacket.com ([216.41.24.7]) with mapi; Thu, 10 Apr 2008 18:04:58 -0400 From: Hadriel Kaplan To: "Cartwright, Kenneth" , "peppermint@ietf.org" Date: Thu, 10 Apr 2008 18:05:10 -0400 Thread-Topic: PEPPERMINT Digest, Vol 10, Issue 18 Thread-Index: AciaqNZPHt9raabXTzq/4/tjIHoC3AAcXYEQAA6UmbA= Message-ID: References: In-Reply-To: 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] PEPPERMINT Digest, Vol 10, Issue 18 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 Right, so it was entirely off-line, and the reason I started it that way was because I didn't want to cause any possible disruption to this group getting its charter approved and WG formed. So I basically consulted with the BoF chairs and a few other folks to see if they felt (1) it wasn't important what the name was, or (2) if it would be better to let sleeping dogs lie. Normally I wouldn't care about such things, because like you, I know the charter is what matters. I like the current charter just fine. But in the last 3 weeks I have had to explain to at least 6 people that Peppermint is not provisioning, or at least not how they mean that word. (of the 6 people, 3 attend the IETF and are active in the RAI area) So methinks it safer/better if we can avoid that term and its baggage. We could argue about what the term truly means, and whether the current charter truly means it, and so on. But if we just remove the term and leave the charter as is, we can argue about the specific requirements and proposals based on the charter in the WG after it's formed, rather than that particular term's definition now or even then. (because I bet if you ask two people what it means you'll get three answers :) As to the DRINK vs. PEPPERMINT - I also came up with alternative expansions for "Peppermint" that avoided the term provisioning, as well as a few alternative new names, and DRINKS seemed to wet people's thirst for a new name. ;) -hadriel > -----Original Message----- > From: peppermint-bounces@ietf.org [mailto:peppermint-bounces@ietf.org] On > Behalf Of Cartwright, Kenneth > Sent: Thursday, April 10, 2008 11:08 AM > To: peppermint@ietf.org > Subject: Re: [PEPPERMINT] PEPPERMINT Digest, Vol 10, Issue 18 > > First off, it's good to know that the off-line discussions were > "serious". :-) Secondly, I went back a couple weeks through the > PEPPERMINT emails in my inbox but did not find mention of this subject > of the term "provisioning" being problematic. SO I guess this subject > occurred entirely offline. If not, can you please refer to an > approximate date where this was captured in a PEPPERMINT email, perhaps > I missed it. If the discussion was entirely off-line can you please > just provide a sentence or two on the reasoning? > > I would guess that the reasoning may be something along these lines: > > 1) The term provisioning is ill defined. > 2) The term provisioning may be interpreted by some as too limiting or > too broad. > 3) Depending on ones definition of "provisioning", the WG may work on > items that have nothing to do with provisioning. > > However, while the above points may be accurate, I'm not sure how > changing the WG name from "PEPPERMINT" to "DRINKS" helps in a meaningful > manner. It seems that the content of the WG Charter is more important > in providing the necessary clarity than the name of the WG. > > In short, my $.02 is that changing the name of the WG from PEPPERMINT to > DRINKS is just fine. But, more importantly, I'd like to see how this > name change impacts the content of the Charter. > > Ken > > -----Original Message----- > From: peppermint-bounces@ietf.org [mailto:peppermint-bounces@ietf.org] > On Behalf Of peppermint-request@ietf.org > Sent: Wednesday, April 09, 2008 9:18 PM > To: peppermint@ietf.org > Subject: PEPPERMINT Digest, Vol 10, Issue 18 > > 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. New name for the WG... consensus desired (Richard Shockey) > > > ---------------------------------------------------------------------- > > Message: 1 > Date: Wed, 9 Apr 2008 21:18:13 -0400 > From: "Richard Shockey" > Subject: [PEPPERMINT] New name for the WG... consensus desired > To: > Message-ID: <021601c89aa8$c0a9b5f0$41fd21d0$@us> > Content-Type: text/plain; charset="US-ASCII" > > In some serious off line discussions, there was a suggestion that > PEPPERMINT might not be the most appropriate WG name since the concept > of provisioning has very specific context in teleco world. > > What we are dealing with is data exchanges. > > Hense the suggestion of a new WG name > > DRINKS > > Data for Reachability of Inter/tra-NetworK SIP > > Personally I think this is a perfect IETF WG name and meets all the > criterion of cuteness, banality, etc. and extremely appropriate given > the venue of a probably first meeting ..Dublin . > > We'd like to get a consensus if the change of name is appropriate. > > > > 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 > > > End of PEPPERMINT Digest, Vol 10, Issue 18 > ****************************************** > _______________________________________________ > 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 C600928C1C8; Thu, 10 Apr 2008 08:07: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 A0B153A6C62 for ; Thu, 10 Apr 2008 08:07:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DXJT8hwYblzB for ; Thu, 10 Apr 2008 08:07:15 -0700 (PDT) Received: from osprey.verisign.com (osprey.verisign.com [216.168.239.75]) by core3.amsl.com (Postfix) with ESMTP id 6623D3A6D17 for ; Thu, 10 Apr 2008 08:07:15 -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 m3AEuEtK031216 for ; Thu, 10 Apr 2008 10:56:15 -0400 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, 10 Apr 2008 11:07:35 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Thu, 10 Apr 2008 11:07:34 -0400 Message-ID: In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: PEPPERMINT Digest, Vol 10, Issue 18 Thread-Index: AciaqNZPHt9raabXTzq/4/tjIHoC3AAcXYEQ From: "Cartwright, Kenneth" To: X-OriginalArrivalTime: 10 Apr 2008 15:07:35.0411 (UTC) FILETIME=[9BBA0C30:01C89B1C] Subject: Re: [PEPPERMINT] PEPPERMINT Digest, Vol 10, Issue 18 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 First off, it's good to know that the off-line discussions were "serious". :-) Secondly, I went back a couple weeks through the PEPPERMINT emails in my inbox but did not find mention of this subject of the term "provisioning" being problematic. SO I guess this subject occurred entirely offline. If not, can you please refer to an approximate date where this was captured in a PEPPERMINT email, perhaps I missed it. If the discussion was entirely off-line can you please just provide a sentence or two on the reasoning? I would guess that the reasoning may be something along these lines: 1) The term provisioning is ill defined. 2) The term provisioning may be interpreted by some as too limiting or too broad. 3) Depending on ones definition of "provisioning", the WG may work on items that have nothing to do with provisioning. However, while the above points may be accurate, I'm not sure how changing the WG name from "PEPPERMINT" to "DRINKS" helps in a meaningful manner. It seems that the content of the WG Charter is more important in providing the necessary clarity than the name of the WG. In short, my $.02 is that changing the name of the WG from PEPPERMINT to DRINKS is just fine. But, more importantly, I'd like to see how this name change impacts the content of the Charter. Ken -----Original Message----- From: peppermint-bounces@ietf.org [mailto:peppermint-bounces@ietf.org] On Behalf Of peppermint-request@ietf.org Sent: Wednesday, April 09, 2008 9:18 PM To: peppermint@ietf.org Subject: PEPPERMINT Digest, Vol 10, Issue 18 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. New name for the WG... consensus desired (Richard Shockey) ---------------------------------------------------------------------- Message: 1 Date: Wed, 9 Apr 2008 21:18:13 -0400 From: "Richard Shockey" Subject: [PEPPERMINT] New name for the WG... consensus desired To: Message-ID: <021601c89aa8$c0a9b5f0$41fd21d0$@us> Content-Type: text/plain; charset="US-ASCII" In some serious off line discussions, there was a suggestion that PEPPERMINT might not be the most appropriate WG name since the concept of provisioning has very specific context in teleco world. What we are dealing with is data exchanges. Hense the suggestion of a new WG name DRINKS Data for Reachability of Inter/tra-NetworK SIP Personally I think this is a perfect IETF WG name and meets all the criterion of cuteness, banality, etc. and extremely appropriate given the venue of a probably first meeting ..Dublin . We'd like to get a consensus if the change of name is appropriate. 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 End of PEPPERMINT Digest, Vol 10, Issue 18 ****************************************** _______________________________________________ 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 847253A6D60; Thu, 10 Apr 2008 06:01: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 E0B263A6A37 for ; Thu, 10 Apr 2008 06:01:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.598 X-Spam-Level: X-Spam-Status: No, score=-2.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id OcDRHus235v0 for ; Thu, 10 Apr 2008 06:01:25 -0700 (PDT) Received: from voxeo.com (mmail.voxeo.com [66.193.54.208]) by core3.amsl.com (Postfix) with ESMTP id 538933A6EC0 for ; Thu, 10 Apr 2008 06:01:22 -0700 (PDT) Received: from [172.16.99.204] (account dyork [172.16.99.204] verified) by voxeo.com (CommuniGate Pro SMTP 5.1.14) with ESMTPSA id 29897870; Thu, 10 Apr 2008 13:01:42 +0000 In-Reply-To: <060e01c89ac4$e3ced670$ab6c8350$@us> References: <021601c89aa8$c0a9b5f0$41fd21d0$@us> <05b401c89abb$50588700$f1099500$@us> <060e01c89ac4$e3ced670$ab6c8350$@us> Mime-Version: 1.0 (Apple Message framework v753) Message-Id: <3A5F91B2-2531-40D7-8637-550BAF24DF1C@voxeo.com> From: Dan York Date: Thu, 10 Apr 2008 09:01:41 -0400 To: Richard Shockey X-Mailer: Apple Mail (2.753) Cc: peppermint@ietf.org, 'Hadriel Kaplan' Subject: Re: [PEPPERMINT] New name for the WG... consensus desired 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="===============0523461622==" Sender: peppermint-bounces@ietf.org Errors-To: peppermint-bounces@ietf.org --===============0523461622== Content-Type: multipart/alternative; boundary=Apple-Mail-5--255448635 --Apple-Mail-5--255448635 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed On Apr 10, 2008, at 12:39 AM, Richard Shockey wrote: >> Oh sure, blame me! You were the one who liked DRINKS! :) > > Very true I like DRINKS. I like lots of DRINKS. > > Seriously, I was only giving proper credit where credit is due. The > point > you made on "provisioning" terminology is in fact valid in the > context of > what this WG wants to accomplish and your unique and deliciously > elegant > solution for WG naming you propose is equally valid. > > Clarity in intent and purpose is vital to a correct charter and WG > definition. This is exactly what we are supposed to do in the IETF. > That the > WG name you proposed is both comic and sublime is only a bonus. +1 (now that I understand the suggestion is serious) The PEPPERMINT name always seemed a bit of a stretch to me (not that DRINKS isn't!). This *might* also ease some of the confusion with SPEERMINT, at least in terms of people *talking* about the two groups. Dan (who wonders if there is some image out there of Peppermint Patty drinking...) -- Dan York, CISSP, Director of Emerging Communication Technology Office of the CTO Voxeo Corporation dyork@voxeo.com Phone: +1-407-455-5859 Skype: danyork http://www.voxeo.com Blogs: http://blogs.voxeo.com http://www.disruptivetelephony.com Build voice applications based on open standards. Find out how at http://www.voxeo.com/free --Apple-Mail-5--255448635 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=ISO-8859-1
On Apr 10, = 2008, at 12:39 AM, Richard Shockey wrote:
=A0Oh= sure, blame me!=A0 You were the one who liked DRINKS! :)
=

Very true I like DRINKS.=A0 I like lots of = DRINKS.

Seriously, I was only giving proper credit where = credit is due. The point
you made on = "provisioning" terminology is in fact valid in the context of
what this WG wants to accomplish and your unique and = deliciously elegant
solution for WG naming you = propose is equally valid.=A0

Clarity in = intent and purpose is vital to a correct charter and WG
definition. This is exactly what we are supposed to = do in the IETF. That the
WG name you = proposed is both comic and sublime is only a bonus.
=

+1 =A0(now that I understand the = suggestion is serious)

The PEPPERMINT name = always seemed =A0a bit of a stretch to me (not that DRINKS isn't!). = =A0This *might* also ease some of the confusion with SPEERMINT, at least = in terms of people *talking* about the two = groups.

Dan (who wonders if there is some image = out there of Peppermint Patty drinking...)

--=A0
Dan York, = CISSP, Director of Emerging Communication Technology
Office of the CTO=A0 =A0=A0Voxeo Corporation=A0=A0 =A0=A0dyork@voxeo.com
Phone: +1-407-455-5859=A0=A0Skype: danyork=A0=A0http://www.voxeo.com

Build voice applications based on open = standards.





= --Apple-Mail-5--255448635-- --===============0523461622== 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 --===============0523461622==-- 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 2035A3A6AA9; Thu, 10 Apr 2008 05:53:27 -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 8C5103A6AA9 for ; Thu, 10 Apr 2008 05:53:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.87 X-Spam-Level: X-Spam-Status: No, score=-1.87 tagged_above=-999 required=5 tests=[AWL=0.729, 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 le0mwXPigzd1 for ; Thu, 10 Apr 2008 05:53:24 -0700 (PDT) Received: from ebru.winwebhosting.com (ebru.winwebhosting.com [74.54.111.226]) by core3.amsl.com (Postfix) with ESMTP id A420D3A6A05 for ; Thu, 10 Apr 2008 05:53:24 -0700 (PDT) Received: from neustargw.va.neustar.com ([209.173.53.233] helo=BROSLT61xp) by ebru.winwebhosting.com with esmtpa (Exim 4.68) (envelope-from ) id 1JjwHd-0008Sb-Ov; Thu, 10 Apr 2008 07:53:41 -0500 From: "Brian Rosen" To: "'Richard Shockey'" , "'Hadriel Kaplan'" , References: <021601c89aa8$c0a9b5f0$41fd21d0$@us><05b401c89abb$50588700$f1099500$@us> <060e01c89ac4$e3ced670$ab6c8350$@us> Date: Thu, 10 Apr 2008 08:53:42 -0400 Message-ID: <08cf01c89b09$e9cb60d0$640fa8c0@cis.neustar.com> MIME-Version: 1.0 X-Mailer: Microsoft Office Outlook 11 In-Reply-To: <060e01c89ac4$e3ced670$ab6c8350$@us> X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3198 thread-index: AciaqL8NQw5z05/6Q7mUPqnYbDON8gADhf1QAAD9lgAAABonwAAB5b/QABGlrTA= X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - ebru.winwebhosting.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - brianrosen.net X-Source: X-Source-Args: X-Source-Dir: Subject: Re: [PEPPERMINT] New name for the WG... consensus desired 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 This change request wouldn't be related to your recently bestowed nom de plume would it... Peppermint Patty? Brian -----Original Message----- From: peppermint-bounces@ietf.org [mailto:peppermint-bounces@ietf.org] On Behalf Of Richard Shockey Sent: Thursday, April 10, 2008 12:40 AM To: 'Hadriel Kaplan'; peppermint@ietf.org Subject: Re: [PEPPERMINT] New name for the WG... consensus desired > > > Oh sure, blame me! You were the one who liked DRINKS! :) Very true I like DRINKS. I like lots of DRINKS. Seriously, I was only giving proper credit where credit is due. The point you made on "provisioning" terminology is in fact valid in the context of what this WG wants to accomplish and your unique and deliciously elegant solution for WG naming you propose is equally valid. Clarity in intent and purpose is vital to a correct charter and WG definition. This is exactly what we are supposed to do in the IETF. That the WG name you proposed is both comic and sublime is only a bonus. > I wouldn't have raised it if it weren't for all the people I talk to > about it getting confused with provisioning, and having to spend time > starting off conversations with "well, it says provisioning, but...". You saw a problem you raised it, you were right to raise it. Many of us agree. Problem solved. > :-P > _______________________________________________ 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 8FB223A6D63; Wed, 9 Apr 2008 21:39: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 C31773A6E22 for ; Wed, 9 Apr 2008 21:39:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.489 X-Spam-Level: X-Spam-Status: No, score=-3.489 tagged_above=-999 required=5 tests=[AWL=0.110, 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 esd7Z6hd7n3y for ; Wed, 9 Apr 2008 21:39:49 -0700 (PDT) Received: from mail.songbird.com (mail.songbird.com [208.184.79.10]) by core3.amsl.com (Postfix) with ESMTP id 12F9E3A6D63 for ; Wed, 9 Apr 2008 21:39:49 -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 m3A4d10U005525 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Wed, 9 Apr 2008 21:39:04 -0700 From: "Richard Shockey" To: "'Hadriel Kaplan'" , References: <021601c89aa8$c0a9b5f0$41fd21d0$@us> <05b401c89abb$50588700$f1099500$@us> In-Reply-To: Date: Thu, 10 Apr 2008 00:39:37 -0400 Message-ID: <060e01c89ac4$e3ced670$ab6c8350$@us> MIME-Version: 1.0 X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: AciaqL8NQw5z05/6Q7mUPqnYbDON8gADhf1QAAD9lgAAABonwAAB5b/Q Content-language: en-us X-SongbirdInformation: support@songbird.com for more information X-Songbird: Clean X-Songbird-From: richard@shockey.us Subject: Re: [PEPPERMINT] New name for the WG... consensus desired 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 > > > Oh sure, blame me! You were the one who liked DRINKS! :) Very true I like DRINKS. I like lots of DRINKS. Seriously, I was only giving proper credit where credit is due. The point you made on "provisioning" terminology is in fact valid in the context of what this WG wants to accomplish and your unique and deliciously elegant solution for WG naming you propose is equally valid. Clarity in intent and purpose is vital to a correct charter and WG definition. This is exactly what we are supposed to do in the IETF. That the WG name you proposed is both comic and sublime is only a bonus. > I wouldn't have raised it if it weren't for all the people I talk to > about it getting confused with provisioning, and having to spend time > starting off conversations with "well, it says provisioning, but...". You saw a problem you raised it, you were right to raise it. Many of us agree. Problem solved. > :-P > _______________________________________________ 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 B408C3A6882; Wed, 9 Apr 2008 20:37:58 -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 AFE6D3A6882 for ; Wed, 9 Apr 2008 20:37:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.312 X-Spam-Level: X-Spam-Status: No, score=-2.312 tagged_above=-999 required=5 tests=[AWL=0.287, 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 181NxbOhrbwq for ; Wed, 9 Apr 2008 20:37:55 -0700 (PDT) Received: from etmail.acmepacket.com (etmail.acmepacket.com [216.41.24.6]) by core3.amsl.com (Postfix) with ESMTP id B44C23A6828 for ; Wed, 9 Apr 2008 20:37:55 -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; Wed, 9 Apr 2008 23:37:47 -0400 Received: from mail.acmepacket.com ([216.41.24.7]) by mail.acmepacket.com ([216.41.24.7]) with mapi; Wed, 9 Apr 2008 23:37:47 -0400 From: Hadriel Kaplan To: Richard Shockey , "peppermint@ietf.org" Date: Wed, 9 Apr 2008 23:34:37 -0400 Thread-Topic: [PEPPERMINT] New name for the WG... consensus desired Thread-Index: AciaqL8NQw5z05/6Q7mUPqnYbDON8gADhf1QAAD9lgAAABonwA== Message-ID: References: <021601c89aa8$c0a9b5f0$41fd21d0$@us> <05b401c89abb$50588700$f1099500$@us> In-Reply-To: <05b401c89abb$50588700$f1099500$@us> 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] New name for the WG... consensus desired 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 Oh sure, blame me! You were the one who liked DRINKS! :) I wouldn't have raised it if it weren't for all the people I talk to about it getting confused with provisioning, and having to spend time starting off conversations with "well, it says provisioning, but...". :-P -hadriel > -----Original Message----- > From: Richard Shockey [mailto:richard@shockey.us] > > I would like to point out, for the record, that Hadriel Kaplan correctly > pointed out the semantic issue with provisioning terminology in the WG > title > and charter and suggested the new WG name. > > A most useful contribution. > > . > > > > +1 > > I am all in favor of avoiding the "provisioning" term, even if it > > drives us to DRINK(s). > > > > -hadriel _______________________________________________ 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 9A2833A6833; Wed, 9 Apr 2008 20:31:15 -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 3DC073A6810 for ; Wed, 9 Apr 2008 20:31:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.478 X-Spam-Level: X-Spam-Status: No, score=-3.478 tagged_above=-999 required=5 tests=[AWL=0.121, 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 bNN7l2gM+nmq for ; Wed, 9 Apr 2008 20:31:13 -0700 (PDT) Received: from mail.songbird.com (mail.songbird.com [208.184.79.10]) by core3.amsl.com (Postfix) with ESMTP id 997D03A6806 for ; Wed, 9 Apr 2008 20:31:10 -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 m3A3UTHx010176 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Wed, 9 Apr 2008 20:30:31 -0700 From: "Richard Shockey" To: "'Hadriel Kaplan'" , References: <021601c89aa8$c0a9b5f0$41fd21d0$@us> In-Reply-To: Date: Wed, 9 Apr 2008 23:31:05 -0400 Message-ID: <05b401c89abb$50588700$f1099500$@us> MIME-Version: 1.0 X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: AciaqL8NQw5z05/6Q7mUPqnYbDON8gADhf1QAAD9lgA= Content-language: en-us X-SongbirdInformation: support@songbird.com for more information X-Songbird: Clean X-Songbird-From: richard@shockey.us Subject: Re: [PEPPERMINT] New name for the WG... consensus desired 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 would like to point out, for the record, that Hadriel Kaplan correctly pointed out the semantic issue with provisioning terminology in the WG title and charter and suggested the new WG name. A most useful contribution. . > > +1 > I am all in favor of avoiding the "provisioning" term, even if it > drives us to DRINK(s). > > -hadriel _______________________________________________ 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 F00A33A6C75; Wed, 9 Apr 2008 20:17:04 -0700 (PDT) X-Original-To: peppermint@core3.amsl.com Delivered-To: peppermint@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id DFA6C3A6D48 for ; Wed, 9 Apr 2008 20:17:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.465 X-Spam-Level: X-Spam-Status: No, score=-3.465 tagged_above=-999 required=5 tests=[AWL=0.134, 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 DU4LyZ3+naCV for ; Wed, 9 Apr 2008 20:17:03 -0700 (PDT) Received: from mail.songbird.com (mail.songbird.com [208.184.79.10]) by core3.amsl.com (Postfix) with ESMTP id 2E1C93A6C75 for ; Wed, 9 Apr 2008 20:17:03 -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 m3A3GG7l003404 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Wed, 9 Apr 2008 20:16:19 -0700 From: "Richard Shockey" To: "'DOLLY, MARTIN C, ATTLABS'" , References: <021601c89aa8$c0a9b5f0$41fd21d0$@us> <28F05913385EAC43AF019413F674A0171246EE34@OCCLUST04EVS1.ugd.att.com> In-Reply-To: <28F05913385EAC43AF019413F674A0171246EE34@OCCLUST04EVS1.ugd.att.com> Date: Wed, 9 Apr 2008 23:16:52 -0400 Message-ID: <052301c89ab9$548a34b0$fd9e9e10$@us> MIME-Version: 1.0 X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: AciaqL8NQw5z05/6Q7mUPqnYbDON8gABEbDAAAMQCcA= Content-language: en-us X-SongbirdInformation: support@songbird.com for more information X-Songbird: Clean X-Songbird-From: richard@shockey.us Subject: Re: [PEPPERMINT] New name for the WG... consensus desired 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 Obviously the WG would be BYOB. > -----Original Message----- > From: DOLLY, MARTIN C, ATTLABS [mailto:mdolly@att.com] > Sent: Wednesday, April 09, 2008 9:50 PM > To: Richard Shockey; peppermint@ietf.org > Subject: RE: [PEPPERMINT] New name for the WG... consensus desired > > I do not think I could turn down a DRINK(S)... > > -----Original Message----- > From: peppermint-bounces@ietf.org [mailto:peppermint-bounces@ietf.org] > On Behalf Of Richard Shockey > Sent: Wednesday, April 09, 2008 9:18 PM > To: peppermint@ietf.org > Subject: [PEPPERMINT] New name for the WG... consensus desired > > In some serious off line discussions, there was a suggestion that > PEPPERMINT > might not be the most appropriate WG name since the concept of > provisioning > has very specific context in teleco world. > > What we are dealing with is data exchanges. > > Hense the suggestion of a new WG name > > DRINKS > > Data for Reachability of Inter/tra-NetworK SIP > > Personally I think this is a perfect IETF WG name and meets all the > criterion of cuteness, banality, etc. and extremely appropriate given > the > venue of a probably first meeting ..Dublin . > > We'd like to get a consensus if the change of name is appropriate. > > > > 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 _______________________________________________ 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 CA6933A6AD2; Wed, 9 Apr 2008 20:16: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 010CF3A6AD2 for ; Wed, 9 Apr 2008 20:16:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.448 X-Spam-Level: X-Spam-Status: No, score=-3.448 tagged_above=-999 required=5 tests=[AWL=0.150, BAYES_00=-2.599, HTML_MESSAGE=0.001, 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 uZSvVDsHbgOQ for ; Wed, 9 Apr 2008 20:16:30 -0700 (PDT) Received: from mail.songbird.com (mail.songbird.com [208.184.79.10]) by core3.amsl.com (Postfix) with ESMTP id 0E9B23A6833 for ; Wed, 9 Apr 2008 20:16: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 m3A3Fkgs003122 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Wed, 9 Apr 2008 20:15:48 -0700 From: "Richard Shockey" To: "'Maharishi, Manjul'" , References: <768BEB5E70C897468D015E23EDCC304E01544717@dul1wnexmb01.vcorp.ad.vrsn.com> In-Reply-To: <768BEB5E70C897468D015E23EDCC304E01544717@dul1wnexmb01.vcorp.ad.vrsn.com> Date: Wed, 9 Apr 2008 23:16:22 -0400 Message-ID: <051e01c89ab9$4242a3f0$c6c7ebd0$@us> MIME-Version: 1.0 X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: AciaqL8NQw5z05/6Q7mUPqnYbDON8gABEbDAAAC+jfsAAku/4A== Content-language: en-us X-SongbirdInformation: support@songbird.com for more information X-Songbird: Clean X-Songbird-From: richard@shockey.us Subject: Re: [PEPPERMINT] New name for the WG... consensus desired 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="===============0356086227==" Sender: peppermint-bounces@ietf.org Errors-To: peppermint-bounces@ietf.org This is a multipart message in MIME format. --===============0356086227== Content-Type: multipart/alternative; boundary="----=_NextPart_000_051F_01C89A97.BB312B00" Content-language: en-us This is a multipart message in MIME format. ------=_NextPart_000_051F_01C89A97.BB312B00 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit Who said this was a joke? From: Maharishi, Manjul [mailto:mmaharishi@verisign.com] Sent: Wednesday, April 09, 2008 10:10 PM To: Richard Shockey; peppermint@ietf.org Subject: Re: [PEPPERMINT] New name for the WG... consensus desired Rich, You are seriously late for the April fools day jokes ....when I last checked my calendar, it was already the 9th :) Manjul Maharishi Sr.Mgr. R&D IPE VeriSign Sent from Goodlink -----Original Message----- From: DOLLY, MARTIN C, ATTLABS [mailto:mdolly@att.com] Sent: Wednesday, April 09, 2008 09:49 PM Eastern Standard Time To: Richard Shockey; peppermint@ietf.org Subject: Re: [PEPPERMINT] New name for the WG... consensus desired I do not think I could turn down a DRINK(S)... -----Original Message----- From: peppermint-bounces@ietf.org [mailto:peppermint-bounces@ietf.org] On Behalf Of Richard Shockey Sent: Wednesday, April 09, 2008 9:18 PM To: peppermint@ietf.org Subject: [PEPPERMINT] New name for the WG... consensus desired In some serious off line discussions, there was a suggestion that PEPPERMINT might not be the most appropriate WG name since the concept of provisioning has very specific context in teleco world. What we are dealing with is data exchanges. Hense the suggestion of a new WG name DRINKS Data for Reachability of Inter/tra-NetworK SIP Personally I think this is a perfect IETF WG name and meets all the criterion of cuteness, banality, etc. and extremely appropriate given the venue of a probably first meeting ..Dublin . We'd like to get a consensus if the change of name is appropriate. 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 _______________________________________________ PEPPERMINT mailing list PEPPERMINT@ietf.org https://www.ietf.org/mailman/listinfo/peppermint ------=_NextPart_000_051F_01C89A97.BB312B00 Content-Type: text/html; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable Re: [PEPPERMINT] New name for the WG... consensus desired

Who said this was a joke?

 

 

From:= Maharishi, = Manjul [mailto:mmaharishi@verisign.com]
Sent: Wednesday, April 09, 2008 10:10 PM
To: Richard Shockey; peppermint@ietf.org
Subject: Re: [PEPPERMINT] New name for the WG... consensus = desired

 

Rich,

You are seriously late for the April fools day jokes ....when I last = checked my calendar, it was already the 9th :)

Manjul Maharishi
Sr.Mgr. R&D IPE
VeriSign

Sent from Goodlink

 -----Original Message-----
From:   DOLLY, MARTIN C, ATTLABS [mailto:mdolly@att.com]
Sent:   Wednesday, April 09, 2008 09:49 PM Eastern Standard = Time
To:     Richard Shockey; peppermint@ietf.org
Subject:        Re: [PEPPERMINT] New = name for the WG... consensus desired

I do not think I could turn down a DRINK(S)...

-----Original Message-----
From: peppermint-bounces@ietf.org [mailto:peppermint-bounces@iet= f.org]
On Behalf Of Richard Shockey
Sent: Wednesday, April 09, 2008 9:18 PM
To: peppermint@ietf.org
Subject: [PEPPERMINT] New name for the WG... consensus desired

In some serious off line discussions, there was a suggestion that
PEPPERMINT
might not be the most appropriate WG name since the concept of
provisioning
has very specific context in teleco world.

What we are dealing with is data exchanges.

Hense the suggestion of a new WG name

DRINKS

Data for Reachability of Inter/tra-NetworK SIP

Personally I think this is a perfect IETF WG name and meets all the
criterion of cuteness, banality, etc. and extremely appropriate = given
the
venue of a probably first meeting ..Dublin .

We'd like to get a consensus if the change of name is appropriate.



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
<mailto:richard(at)shockey.us>= ;
<mailto:richard.shockey(at)= neustar.biz>



_______________________________________________
PEPPERMINT mailing list
PEPPERMINT@ietf.org
https://www.iet= f.org/mailman/listinfo/peppermint
_______________________________________________
PEPPERMINT mailing list
PEPPERMINT@ietf.org
https://www.iet= f.org/mailman/listinfo/peppermint

------=_NextPart_000_051F_01C89A97.BB312B00-- --===============0356086227== 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 --===============0356086227==-- 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 A4B163A686B; Wed, 9 Apr 2008 20:16: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 305853A686B for ; Wed, 9 Apr 2008 20:16:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.309 X-Spam-Level: X-Spam-Status: No, score=-2.309 tagged_above=-999 required=5 tests=[AWL=0.290, 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 zcJqQTdII7Ep for ; Wed, 9 Apr 2008 20:16:03 -0700 (PDT) Received: from etmail.acmepacket.com (etmail.acmepacket.com [216.41.24.6]) by core3.amsl.com (Postfix) with ESMTP id 5860E3A6806 for ; Wed, 9 Apr 2008 20:16:03 -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; Wed, 9 Apr 2008 23:15:54 -0400 Received: from mail.acmepacket.com ([216.41.24.7]) by mail.acmepacket.com ([216.41.24.7]) with mapi; Wed, 9 Apr 2008 23:15:54 -0400 From: Hadriel Kaplan To: Richard Shockey , "peppermint@ietf.org" Date: Wed, 9 Apr 2008 23:12:43 -0400 Thread-Topic: [PEPPERMINT] New name for the WG... consensus desired Thread-Index: AciaqL8NQw5z05/6Q7mUPqnYbDON8gADhf1Q Message-ID: References: <021601c89aa8$c0a9b5f0$41fd21d0$@us> In-Reply-To: <021601c89aa8$c0a9b5f0$41fd21d0$@us> 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] New name for the WG... consensus desired X-BeenThere: peppermint@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Provisioning Extensions in Peering Registries for Multimedia INTerconnection List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: peppermint-bounces@ietf.org Errors-To: peppermint-bounces@ietf.org > -----Original Message----- > From: peppermint-bounces@ietf.org [mailto:peppermint-bounces@ietf.org] On > Behalf Of Richard Shockey > What we are dealing with is data exchanges. > Hense the suggestion of a new WG name > DRINKS > Data for Reachability of Inter/tra-NetworK SIP > Personally I think this is a perfect IETF WG name and meets all the > criterion of cuteness, banality, etc. and extremely appropriate given the > venue of a probably first meeting ..Dublin . > We'd like to get a consensus if the change of name is appropriate. +1 I am all in favor of avoiding the "provisioning" term, even if it drives us to DRINK(s). -hadriel _______________________________________________ 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 414E53A6C36; Wed, 9 Apr 2008 19:09:56 -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 4F4803A6C36 for ; Wed, 9 Apr 2008 19:09:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.598 X-Spam-Level: X-Spam-Status: No, score=-6.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0kkHqo1yuCt0 for ; Wed, 9 Apr 2008 19:09:54 -0700 (PDT) Received: from osprey.verisign.com (osprey.verisign.com [216.168.239.75]) by core3.amsl.com (Postfix) with ESMTP id 23BC43A6810 for ; Wed, 9 Apr 2008 19:09:54 -0700 (PDT) Received: from dul1wnexcn03.vcorp.ad.vrsn.com (dul1wnexcn03.vcorp.ad.vrsn.com [10.170.12.113]) by osprey.verisign.com (8.13.6/8.13.4) with ESMTP id m3A1wpO8002567; Wed, 9 Apr 2008 21:58:51 -0400 Received: from dul1wnexmb01.vcorp.ad.vrsn.com ([10.170.12.134]) by dul1wnexcn03.vcorp.ad.vrsn.com with Microsoft SMTPSVC(6.0.3790.3959); Thu, 10 Apr 2008 03:10:10 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Wed, 9 Apr 2008 22:10:08 -0400 Message-ID: <768BEB5E70C897468D015E23EDCC304E01544717@dul1wnexmb01.vcorp.ad.vrsn.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [PEPPERMINT] New name for the WG... consensus desired Thread-Index: AciaqL8NQw5z05/6Q7mUPqnYbDON8gABEbDAAAC+jfs= From: "Maharishi, Manjul" To: "Richard Shockey" , X-OriginalArrivalTime: 10 Apr 2008 02:10:10.0601 (UTC) FILETIME=[0140E190:01C89AB0] Subject: Re: [PEPPERMINT] New name for the WG... consensus desired 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="===============1969759771==" Sender: peppermint-bounces@ietf.org Errors-To: peppermint-bounces@ietf.org This is a multi-part message in MIME format. --===============1969759771== Content-class: urn:content-classes:message Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C89AAF.FFC25442" This is a multi-part message in MIME format. ------_=_NextPart_001_01C89AAF.FFC25442 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Rich, You are seriously late for the April fools day jokes ....when I last = checked my calendar, it was already the 9th :) Manjul Maharishi Sr.Mgr. R&D IPE VeriSign Sent from Goodlink -----Original Message----- From: DOLLY, MARTIN C, ATTLABS [mailto:mdolly@att.com] Sent: Wednesday, April 09, 2008 09:49 PM Eastern Standard Time To: Richard Shockey; peppermint@ietf.org Subject: Re: [PEPPERMINT] New name for the WG... consensus desired I do not think I could turn down a DRINK(S)...=20 -----Original Message----- From: peppermint-bounces@ietf.org [mailto:peppermint-bounces@ietf.org] On Behalf Of Richard Shockey Sent: Wednesday, April 09, 2008 9:18 PM To: peppermint@ietf.org Subject: [PEPPERMINT] New name for the WG... consensus desired In some serious off line discussions, there was a suggestion that PEPPERMINT might not be the most appropriate WG name since the concept of provisioning has very specific context in teleco world. What we are dealing with is data exchanges. Hense the suggestion of a new WG name=20 DRINKS=20 Data for Reachability of Inter/tra-NetworK SIP Personally I think this is a perfect IETF WG name and meets all the criterion of cuteness, banality, etc. and extremely appropriate given the venue of a probably first meeting ..Dublin . We'd like to get a consensus if the change of name is appropriate. Richard Shockey Director, Member of the Technical Staff NeuStar 46000 Center Oak Plaza - Sterling, VA 20166 PSTN Office +1 571.434.5651=20 PSTN Mobile: +1 703.593.2683 =20 _______________________________________________ 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 ------_=_NextPart_001_01C89AAF.FFC25442 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Re: [PEPPERMINT] New name for the WG... consensus desired

Rich,

You are seriously late for the April fools day jokes ....when I last = checked my calendar, it was already the 9th :)

Manjul Maharishi
Sr.Mgr. R&D IPE
VeriSign

Sent from Goodlink

 -----Original Message-----
From:   DOLLY, MARTIN C, ATTLABS [mailto:mdolly@att.com]
Sent:   Wednesday, April 09, 2008 09:49 PM Eastern Standard = Time
To:     Richard Shockey; peppermint@ietf.org
Subject:        Re: [PEPPERMINT] New = name for the WG... consensus desired

I do not think I could turn down a DRINK(S)...

-----Original Message-----
From: peppermint-bounces@ietf.org [mailto:peppermint-bounces@iet= f.org]
On Behalf Of Richard Shockey
Sent: Wednesday, April 09, 2008 9:18 PM
To: peppermint@ietf.org
Subject: [PEPPERMINT] New name for the WG... consensus desired

In some serious off line discussions, there was a suggestion that
PEPPERMINT
might not be the most appropriate WG name since the concept of
provisioning
has very specific context in teleco world.

What we are dealing with is data exchanges.

Hense the suggestion of a new WG name

DRINKS

Data for Reachability of Inter/tra-NetworK SIP

Personally I think this is a perfect IETF WG name and meets all the
criterion of cuteness, banality, etc. and extremely appropriate = given
the
venue of a probably first meeting ..Dublin .

We'd like to get a consensus if the change of name is appropriate.



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
<mailto:richard(at)shockey.us>= ;
<mailto:richard.shockey(at)= neustar.biz>



_______________________________________________
PEPPERMINT mailing list
PEPPERMINT@ietf.org
https://www.iet= f.org/mailman/listinfo/peppermint
_______________________________________________
PEPPERMINT mailing list
PEPPERMINT@ietf.org
https://www.iet= f.org/mailman/listinfo/peppermint

------_=_NextPart_001_01C89AAF.FFC25442-- --===============1969759771== 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 --===============1969759771==-- 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 20D843A6BC0; Wed, 9 Apr 2008 18:49:33 -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 5DC1D3A6B00 for ; Wed, 9 Apr 2008 18:49:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -104.01 X-Spam-Level: X-Spam-Status: No, score=-104.01 tagged_above=-999 required=5 tests=[AWL=2.589, 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 K114T2ofjwWF for ; Wed, 9 Apr 2008 18:49:30 -0700 (PDT) Received: from mail121.messagelabs.com (mail121.messagelabs.com [216.82.241.195]) by core3.amsl.com (Postfix) with ESMTP id 5D3203A6BC0 for ; Wed, 9 Apr 2008 18:49:29 -0700 (PDT) X-VirusChecked: Checked X-Env-Sender: mdolly@att.com X-Msg-Ref: server-7.tower-121.messagelabs.com!1207792188!26308674!1 X-StarScan-Version: 5.5.12.14.2; banners=-,-,- X-Originating-IP: [144.160.20.54] Received: (qmail 21991 invoked from network); 10 Apr 2008 01:49:48 -0000 Received: from sbcsmtp7.sbc.com (HELO mlpi135.enaf.sfdc.sbc.com) (144.160.20.54) by server-7.tower-121.messagelabs.com with AES256-SHA encrypted SMTP; 10 Apr 2008 01:49:48 -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 m3A1nlZ9025124; Wed, 9 Apr 2008 21:49:47 -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 m3A1nkxL025120; Wed, 9 Apr 2008 21:49:46 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Wed, 9 Apr 2008 20:49:46 -0500 Message-ID: <28F05913385EAC43AF019413F674A0171246EE34@OCCLUST04EVS1.ugd.att.com> In-Reply-To: <021601c89aa8$c0a9b5f0$41fd21d0$@us> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [PEPPERMINT] New name for the WG... consensus desired Thread-Index: AciaqL8NQw5z05/6Q7mUPqnYbDON8gABEbDA References: <021601c89aa8$c0a9b5f0$41fd21d0$@us> From: "DOLLY, MARTIN C, ATTLABS" To: "Richard Shockey" , Subject: Re: [PEPPERMINT] New name for the WG... consensus desired 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 do not think I could turn down a DRINK(S)... -----Original Message----- From: peppermint-bounces@ietf.org [mailto:peppermint-bounces@ietf.org] On Behalf Of Richard Shockey Sent: Wednesday, April 09, 2008 9:18 PM To: peppermint@ietf.org Subject: [PEPPERMINT] New name for the WG... consensus desired In some serious off line discussions, there was a suggestion that PEPPERMINT might not be the most appropriate WG name since the concept of provisioning has very specific context in teleco world. What we are dealing with is data exchanges. Hense the suggestion of a new WG name DRINKS Data for Reachability of Inter/tra-NetworK SIP Personally I think this is a perfect IETF WG name and meets all the criterion of cuteness, banality, etc. and extremely appropriate given the venue of a probably first meeting ..Dublin . We'd like to get a consensus if the change of name is appropriate. 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 _______________________________________________ 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 8353B3A6B00; Wed, 9 Apr 2008 18:18: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 E65D43A6B00 for ; Wed, 9 Apr 2008 18:18:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.392 X-Spam-Level: X-Spam-Status: No, score=-2.392 tagged_above=-999 required=5 tests=[AWL=-1.207, BAYES_40=-0.185, 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 TIlAxQyP92hH for ; Wed, 9 Apr 2008 18:18:27 -0700 (PDT) Received: from mail.songbird.com (mail.songbird.com [208.184.79.10]) by core3.amsl.com (Postfix) with ESMTP id 468FD3A6841 for ; Wed, 9 Apr 2008 18:18:27 -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 m3A1HaRT008278 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO) for ; Wed, 9 Apr 2008 18:17:38 -0700 From: "Richard Shockey" To: Date: Wed, 9 Apr 2008 21:18:13 -0400 Message-ID: <021601c89aa8$c0a9b5f0$41fd21d0$@us> MIME-Version: 1.0 X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: AciaqL8NQw5z05/6Q7mUPqnYbDON8g== Content-language: en-us X-SongbirdInformation: support@songbird.com for more information X-Songbird: Clean X-Songbird-From: richard@shockey.us Subject: [PEPPERMINT] New name for the WG... consensus desired 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 In some serious off line discussions, there was a suggestion that PEPPERMINT might not be the most appropriate WG name since the concept of provisioning has very specific context in teleco world. What we are dealing with is data exchanges. Hense the suggestion of a new WG name DRINKS Data for Reachability of Inter/tra-NetworK SIP Personally I think this is a perfect IETF WG name and meets all the criterion of cuteness, banality, etc. and extremely appropriate given the venue of a probably first meeting ..Dublin . We'd like to get a consensus if the change of name is appropriate. Richard Shockey Director, Member of the Technical Staff NeuStar 46000 Center Oak Plaza - Sterling, VA 20166 PSTN Office +1 571.434.5651 PSTN Mobile: +1 703.593.2683 _______________________________________________ PEPPERMINT mailing list PEPPERMINT@ietf.org https://www.ietf.org/mailman/listinfo/peppermint Return-Path: X-Original-To: peppermint-archive@optimus.ietf.org Delivered-To: ietfarch-peppermint-archive@core3.amsl.com Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0B7EE3A6B0B; Tue, 1 Apr 2008 14:37: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 A228A3A69A9 for ; Tue, 1 Apr 2008 14:37:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.903 X-Spam-Level: X-Spam-Status: No, score=-1.903 tagged_above=-999 required=5 tests=[AWL=0.696, 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 Yecr3FTXhXb8 for ; Tue, 1 Apr 2008 14:37:11 -0700 (PDT) Received: from etmail.acmepacket.com (etmail.acmepacket.com [216.41.24.6]) by core3.amsl.com (Postfix) with ESMTP id C4A2828C170 for ; Tue, 1 Apr 2008 14:37:11 -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; Tue, 1 Apr 2008 17:36:44 -0400 Received: from mail.acmepacket.com ([216.41.24.7]) by mail.acmepacket.com ([216.41.24.7]) with mapi; Tue, 1 Apr 2008 17:36:44 -0400 From: Hadriel Kaplan To: Daryl Malas , "peppermint@ietf.org" Date: Tue, 1 Apr 2008 17:36:44 -0400 Thread-Topic: [PEPPERMINT] Proposed Updated Charter Thread-Index: AciTaz5+nL5X5hseRkSarzcft2yW4AAM15ygABsjLrAADMOp4A== Message-ID: References: <160DE07A1C4F8E4AA2715DEC577DA49193647C@srvxchg3.cablelabs.com> <160DE07A1C4F8E4AA2715DEC577DA491936495@srvxchg3.cablelabs.com> In-Reply-To: <160DE07A1C4F8E4AA2715DEC577DA491936495@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 > -----Original Message----- > From: Daryl Malas [mailto:D.Malas@cablelabs.com] > > > > Data exchanges to facilitate session-based Multimedia Interconnection > > are typically between various bilateral or multilateral client User > > Agents and related Registries. > > [HK] 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? > > [DM] I would suggest "client User Agents" is changed to "SIP User > Agents", but a proxy would not be provisioned within an ENUM server as > an end-point. A B2BUA, otherwise known as a UA to SIP, would be. I don't know what you mean by "a proxy would not be provisioned within an ENUM server as an end-point". Clearly there may not be an E.164 phone number/NAPTr entry representing a proxy (although interestingly in some cases there are, but I digress), but the next-hop defined by the regex replacement hostname could well be a proxy. Or it could be a b2bua, or SBE, or whatever hybrid intermediate hop type exists. Or it could be a final endpoint UAS. Regardless, the part I'm concerned with is that the paragraph says the data exchange is typically between various UA's and related registries. I *think* what you mean by that is that the data is typically exchanged between various LUF and/or LRF functional nodes (e.g., enum DB, proxy, b2bua, sbe, etc.)? -hadriel _______________________________________________ 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 C54DC3A6989; Tue, 1 Apr 2008 14:25: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 B0F6F28C3F4 for ; Tue, 1 Apr 2008 14:25:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.883 X-Spam-Level: X-Spam-Status: No, score=-1.883 tagged_above=-999 required=5 tests=[AWL=0.716, 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 B7TZEChJAqHv for ; Tue, 1 Apr 2008 14:25:45 -0700 (PDT) Received: from etmail.acmepacket.com (etmail.acmepacket.com [216.41.24.6]) by core3.amsl.com (Postfix) with ESMTP id B1D0628C477 for ; Tue, 1 Apr 2008 14:25:36 -0700 (PDT) Received: from mail.acmepacket.com (216.41.24.7) by etmail.acmepacket.com (216.41.24.6) with Microsoft SMTP Server (TLS) id 8.1.240.5; Tue, 1 Apr 2008 17:25:09 -0400 Received: from mail.acmepacket.com ([216.41.24.7]) by mail.acmepacket.com ([216.41.24.7]) with mapi; Tue, 1 Apr 2008 17:25:09 -0400 From: Hadriel Kaplan To: Daryl Malas , "peppermint@ietf.org" Date: Tue, 1 Apr 2008 17:25:09 -0400 Thread-Topic: [PEPPERMINT] Proposed Updated Charter Thread-Index: AciTaz5+nL5X5hseRkSarzcft2yW4AAM15ygABsjLrAADJF7gA== Message-ID: References: <160DE07A1C4F8E4AA2715DEC577DA49193647C@srvxchg3.cablelabs.com> <160DE07A1C4F8E4AA2715DEC577DA491936495@srvxchg3.cablelabs.com> In-Reply-To: <160DE07A1C4F8E4AA2715DEC577DA491936495@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 > -----Original Message----- > From: Daryl Malas [mailto:D.Malas@cablelabs.com] > > [DM] Okay, I am not sure how you read "indirect" peering into that > sentence. Also, just because you are a member of a federation does not > suddenly give you a "golden key" to peer with everyone within it. The > point of the sentence is to indicate there are potential complexities to > be considered within PEPPERMINT when peers are in multilateral > relationships. It should not be PEPPERMINT to determine what those > architectural complexities are. These are discussed, documented, and > determined within SPEERMINT; however, based on these complexities, > PEPPERMINT will need to take into consideration the provisioning of data > within a Federation. It will be, potentially, different than a single > bi-lateral peering arrangement. Totally agree on that - I just read it from your first version, as implying such would be the case. I'm cool with this. -hadriel _______________________________________________ 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 799613A6BC8; Tue, 1 Apr 2008 14:20:56 -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 12D3C3A6C34 for ; Tue, 1 Apr 2008 14:20:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.862 X-Spam-Level: X-Spam-Status: No, score=-1.862 tagged_above=-999 required=5 tests=[AWL=0.737, 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 Q6SDaW2s1xp0 for ; Tue, 1 Apr 2008 14:20:54 -0700 (PDT) Received: from etmail.acmepacket.com (etmail.acmepacket.com [216.41.24.6]) by core3.amsl.com (Postfix) with ESMTP id 9409E28C406 for ; Tue, 1 Apr 2008 14:20:19 -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; Tue, 1 Apr 2008 17:19:52 -0400 Received: from mail.acmepacket.com ([216.41.24.7]) by mail.acmepacket.com ([216.41.24.7]) with mapi; Tue, 1 Apr 2008 17:19:52 -0400 From: Hadriel Kaplan To: Daryl Malas , "DOLLY, MARTIN C, ATTLABS" , "peppermint@ietf.org" Date: Tue, 1 Apr 2008 17:19:52 -0400 Thread-Topic: [PEPPERMINT] Proposed Updated Charter Thread-Index: AciTaz5+nL5X5hseRkSarzcft2yW4AALIH5QAAEU7fAAExRccAAHl2dgAAF0pEAADCZzMA== Message-ID: References: <160DE07A1C4F8E4AA2715DEC577DA49193647C@srvxchg3.cablelabs.com> <28F05913385EAC43AF019413F674A0171246ED86@OCCLUST04EVS1.ugd.att.com> <28F05913385EAC43AF019413F674A0171246ED87@OCCLUST04EVS1.ugd.att.com> <160DE07A1C4F8E4AA2715DEC577DA491936496@srvxchg3.cablelabs.com> In-Reply-To: <160DE07A1C4F8E4AA2715DEC577DA491936496@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 > -----Original Message----- > From: Daryl Malas [mailto:D.Malas@cablelabs.com] > > Hadriel, > > I agree it should be within the scope to consider an enterprise's use of > the outcome of PEPPERMINT, but it is not PEPPERMINT's job to determine > the formation of enterprises within varying peering architectures. At > best, this would be done within SPEERMINT, and some architectures and > peering considerations for enterprises are already documented within > SPEERMINT artifacts. I'm confused - did I imply such would be PEPPERMINT's job? I certainly didn't mean to if I did. -hadriel > -----Original Message----- > From: Hadriel Kaplan [mailto:HKaplan@acmepacket.com] > Sent: Tuesday, April 01, 2008 9:20 AM > To: DOLLY, MARTIN C, ATTLABS; Daryl Malas; peppermint@ietf.org > Subject: RE: [PEPPERMINT] Proposed Updated Charter > > > Imagine a big enterprise, having multiple branch offices, lots of user > agents and proxies/servers/whatever. They may want calls within a > branch to stay in the branch, calls between certain branches to go over > the public Internet, calls between other branches to use leased lines or > VPNs, calls between other branches to use the PSTN or ESN-type TDM > network, etc. So they could potentially use an outcome of PEPPERMINT to > dynamically provision their servers/proxies in the various branches with > such routing data, and make changes as employees or groups are added or > move branches. > > OR another example is suppose this big enterprise connects to multiple > service providers or federations, perhaps different ones for different > branches - the providers or federations can dynamically inform the > enterprise or its branches of which ingress points can be used for what > routes, with potentially some other attributes yet to be defined. That > way as the provider/federation adds or removes ingress points or routes, > it can do so in a more automated fashion. > > I think, but I'm not sure, that including enterprises in the charter > does not mean to say any of those things would happen, or that > PEPPERMINT would actually define such uses explicitly/separately, or > that they have to give special consideration to such - just that it's > within the scope of the WG's purview to do so. Is that correct? > > -hadriel > > > > -----Original Message----- > > From: DOLLY, MARTIN C, ATTLABS [mailto:mdolly@att.com] > > > > I do not agree with your example, yet. Can you be a little more > > specific, as to what information peppermint would provide here? > > > > Thanks, > > > > Martin > > > > -----Original Message----- > > From: Hadriel Kaplan [mailto:HKaplan@acmepacket.com] > > Sent: Monday, March 31, 2008 10:18 PM > > To: DOLLY, MARTIN C, ATTLABS; Daryl Malas; peppermint@ietf.org > > Subject: RE: [PEPPERMINT] Proposed Updated Charter > > > > 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 > > _______________________________________________ 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 8973E28C5DB; Tue, 1 Apr 2008 13:58:55 -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 9412828C5EF for ; Tue, 1 Apr 2008 13:58:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id EsfOhveID+Uq for ; Tue, 1 Apr 2008 13:58:31 -0700 (PDT) Received: from mailgate.siemenscomms.co.uk (mailgate.siemenscomms.co.uk [195.171.110.225]) by core3.amsl.com (Postfix) with ESMTP id EE69A28C620 for ; Tue, 1 Apr 2008 13:57:24 -0700 (PDT) Received: from GBNTHT12009MSX.gb002.siemens.net ([137.223.219.235]) by siemenscomms.co.uk (PMDF V6.3-x14 #31430) with ESMTP id <0JYN0036DZJLZ4@siemenscomms.co.uk> for peppermint@ietf.org; Tue, 01 Apr 2008 21:57:22 +0100 (BST) Date: Tue, 01 Apr 2008 21:57:16 +0100 From: "Elwell, John" In-reply-to: <103201c8941a$9784ea30$c68ebe90$@us> To: Richard Shockey , "DRAGE, Keith (Keith)" , "DOLLY, MARTIN C, ATTLABS" , Hadriel Kaplan , Daryl Malas , peppermint@ietf.org Message-id: <0D5F89FAC29E2C41B98A6A762007F5D09156B3@GBNTHT12009MSX.gb002.siemens.net> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft Exchange V6.5 Thread-Topic: [PEPPERMINT] Proposed Updated Charter Thread-Index: AciTaz5+nL5X5hseRkSarzcft2yW4AALIH5QAAEU7fAAExRccAAKO1NgAAI7ZDAACBeY0A== Content-class: urn:content-classes:message X-MS-Has-Attach: X-MS-TNEF-Correlator: References: <160DE07A1C4F8E4AA2715DEC577DA49193647C@srvxchg3.cablelabs.com> <28F05913385EAC43AF019413F674A0171246ED86@OCCLUST04EVS1.ugd.att.com> <28F05913385EAC43AF019413F674A0171246ED87@OCCLUST04EVS1.ugd.att.com> <5D1A7985295922448D5550C94DE2918001D9F512@DEEXC1U01.de.lucent.com> <103201c8941a$9784ea30$c68ebe90$@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 Replying to all who have commented on the enterprise question, I would not want the charter or the deliverables to explicitly exclude enterprises. There will be different sizes of enterprises, and if some of the work of PEPPERMINT turns out to be suitable for use within and between larger enterprises and between enterprises and carriers, I would not want to preclude that. John > -----Original Message----- > From: peppermint-bounces@ietf.org > [mailto:peppermint-bounces@ietf.org] On Behalf Of Richard Shockey > Sent: 01 April 2008 18:05 > To: 'DRAGE, Keith (Keith)'; 'DOLLY, MARTIN C, ATTLABS'; > 'Hadriel Kaplan'; 'Daryl Malas'; peppermint@ietf.org > Subject: Re: [PEPPERMINT] Proposed Updated Charter > > I agree with you Keith. > > There is no reason here to get into a Talmudic discussion of > what is and is > not a SSP. > > But with that said there is probably no reason to actually > call out the > enterprise either in the charter. In this peculiar case "size does not > matter." > > > -----Original Message----- > > From: peppermint-bounces@ietf.org > [mailto:peppermint-bounces@ietf.org] > > On Behalf Of DRAGE, Keith (Keith) > > Sent: Tuesday, April 01, 2008 12:02 PM > > To: DOLLY, MARTIN C, ATTLABS; Hadriel Kaplan; Daryl Malas; > > peppermint@ietf.org > > Subject: Re: [PEPPERMINT] Proposed Updated Charter > > > > Just to note that the reason that this text appeared in the first > > place > > was in response to a question I asked about the size of > systems to be > > addressed. > > > > The smaller the systems that this becomes appropriate for, > the more we > > move into enterprise land, and out of that of the big > public network > > operators (although this is a generalisation as there are many > > enterprise networks bigger that some public networks). > > > > So it is range of system size I want to see represented in > the text if > > we are really stuck on terminology. > > > > Regards > > > > Keith > > > > > -----Original Message----- > > > From: peppermint-bounces@ietf.org > > > [mailto:peppermint-bounces@ietf.org] On Behalf Of DOLLY, > > > MARTIN C, ATTLABS > > > Sent: Tuesday, April 01, 2008 12:08 PM > > > To: Hadriel Kaplan; Daryl Malas; peppermint@ietf.org > > > Subject: Re: [PEPPERMINT] Proposed Updated Charter > > > > > > Hadriel, > > > > > > I do not agree with your example, yet. Can you be a little > > > more specific, as to what information peppermint would provide > > here? > > > > > > Thanks, > > > > > > Martin > > > > > > -----Original Message----- > > > From: Hadriel Kaplan [mailto:HKaplan@acmepacket.com] > > > Sent: Monday, March 31, 2008 10:18 PM > > > To: DOLLY, MARTIN C, ATTLABS; Daryl Malas; peppermint@ietf.org > > > Subject: RE: [PEPPERMINT] Proposed Updated Charter > > > > > > 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 > > > > > _______________________________________________ > > 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 324A328C524; Tue, 1 Apr 2008 10:07:58 -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 531FF28C554 for ; Tue, 1 Apr 2008 10:07:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.499 X-Spam-Level: X-Spam-Status: No, score=-3.499 tagged_above=-999 required=5 tests=[AWL=0.100, 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 vHUtJPjMnQJe for ; Tue, 1 Apr 2008 10:07:40 -0700 (PDT) Received: from mail.songbird.com (mail.songbird.com [208.184.79.10]) by core3.amsl.com (Postfix) with ESMTP id A9C8728C51F for ; Tue, 1 Apr 2008 10:07:22 -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 m31H532d011827 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Tue, 1 Apr 2008 09:05:05 -0800 From: "Richard Shockey" To: "'DRAGE, Keith \(Keith\)'" , "'DOLLY, MARTIN C, ATTLABS'" , "'Hadriel Kaplan'" , "'Daryl Malas'" , References: <160DE07A1C4F8E4AA2715DEC577DA49193647C@srvxchg3.cablelabs.com><28F05913385EAC43AF019413F674A0171246ED86@OCCLUST04EVS1.ugd.att.com> <28F05913385EAC43AF019413F674A0171246ED87@OCCLUST04EVS1.ugd.att.com> <5D1A7985295922448D5550C94DE2918001D9F512@DEEXC1U01.de.lucent.com> In-Reply-To: <5D1A7985295922448D5550C94DE2918001D9F512@DEEXC1U01.de.lucent.com> Date: Tue, 1 Apr 2008 13:05:28 -0400 Message-ID: <103201c8941a$9784ea30$c68ebe90$@us> MIME-Version: 1.0 X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: AciTaz5+nL5X5hseRkSarzcft2yW4AALIH5QAAEU7fAAExRccAAKO1NgAAI7ZDA= 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 I agree with you Keith. There is no reason here to get into a Talmudic discussion of what is and is not a SSP. But with that said there is probably no reason to actually call out the enterprise either in the charter. In this peculiar case "size does not matter." > -----Original Message----- > From: peppermint-bounces@ietf.org [mailto:peppermint-bounces@ietf.org] > On Behalf Of DRAGE, Keith (Keith) > Sent: Tuesday, April 01, 2008 12:02 PM > To: DOLLY, MARTIN C, ATTLABS; Hadriel Kaplan; Daryl Malas; > peppermint@ietf.org > Subject: Re: [PEPPERMINT] Proposed Updated Charter > > Just to note that the reason that this text appeared in the first > place > was in response to a question I asked about the size of systems to be > addressed. > > The smaller the systems that this becomes appropriate for, the more we > move into enterprise land, and out of that of the big public network > operators (although this is a generalisation as there are many > enterprise networks bigger that some public networks). > > So it is range of system size I want to see represented in the text if > we are really stuck on terminology. > > Regards > > Keith > > > -----Original Message----- > > From: peppermint-bounces@ietf.org > > [mailto:peppermint-bounces@ietf.org] On Behalf Of DOLLY, > > MARTIN C, ATTLABS > > Sent: Tuesday, April 01, 2008 12:08 PM > > To: Hadriel Kaplan; Daryl Malas; peppermint@ietf.org > > Subject: Re: [PEPPERMINT] Proposed Updated Charter > > > > Hadriel, > > > > I do not agree with your example, yet. Can you be a little > > more specific, as to what information peppermint would provide > here? > > > > Thanks, > > > > Martin > > > > -----Original Message----- > > From: Hadriel Kaplan [mailto:HKaplan@acmepacket.com] > > Sent: Monday, March 31, 2008 10:18 PM > > To: DOLLY, MARTIN C, ATTLABS; Daryl Malas; peppermint@ietf.org > > Subject: RE: [PEPPERMINT] Proposed Updated Charter > > > > 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 > > > _______________________________________________ > 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