Re: [PEPPERMINT] DRINKS PROPOSED Charter ..comments please.
"Daryl Malas" <D.Malas@cablelabs.com> Wed, 23 April 2008 16:22 UTC
Return-Path: <peppermint-bounces@ietf.org>
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 <peppermint@core3.amsl.com>; 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 <peppermint@core3.amsl.com>; 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 <peppermint@ietf.org>; 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: <E6C2E8958BA59A4FB960963D475F7AC30BD045B4DE@mail.acmepacket.com>
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><E6C2E8958BA59A4FB960963D475F7AC30BD035B4EF@mail.acmepacket.com><20080420211101.GA32096@nic.at> <1a6601c8a3dd$49ca8c50$dd5fa4f0$@us><20080422144452.GA582@nic.at><E6C2E8958BA59A4FB960963D475F7AC30BD045ABC4@mail.acmepacket.com> <14b501c8a495$758aeb60$60a0c220$@us> <160DE07A1C4F8E4AA2715DEC577DA49193654F@srvxchg3.cablelabs.com> <154801c8a49b$22fbc2b0$68f34810$@us> <E6C2E8958BA59A4FB960963D475F7AC30BD045B4DE@mail.acmepacket.com>
From: Daryl Malas <D.Malas@cablelabs.com>
To: Hadriel Kaplan <HKaplan@acmepacket.com>, Richard Shockey <richard@shockey.us>, Otmar Lendl <lendl@nic.at>, peppermint@ietf.org
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 <peppermint.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/peppermint>, <mailto:peppermint-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/pipermail/peppermint>
List-Post: <mailto:peppermint@ietf.org>
List-Help: <mailto:peppermint-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/peppermint>, <mailto:peppermint-request@ietf.org?subject=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 <richard@shockey.us> 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. > > > > > > > > <tongue in cheek> > > > > 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? > > > > </t-i-c> > > > > > > > > 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 <lendl@nic.at>, T: +43 1 5056416 - 33, F: - 933 > > > > // nic.at Internet Verwaltungs- und Betriebsgesellschaft m.b.H > > > // > http://www.nic.at/ LG Salzburg, FN 172568b, Sitz: Salzburg > > > > _______________________________________________ > > > > PEPPERMINT mailing list > > > > PEPPERMINT@ietf.org > > > > https://www.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] DRINKS PROPOSED Charter ..comments p… Richard Shockey
- Re: [PEPPERMINT] DRINKS PROPOSED Charter ..commen… Hadriel Kaplan
- Re: [PEPPERMINT] DRINKS PROPOSED Charter ..commen… Richard Shockey
- Re: [PEPPERMINT] DRINKS PROPOSED Charter ..commen… Dan York
- Re: [PEPPERMINT] DRINKS PROPOSED Charter ..commen… Richard Shockey
- Re: [PEPPERMINT] DRINKS PROPOSED Charter ..commen… Hadriel Kaplan
- Re: [PEPPERMINT] DRINKS PROPOSED Charter ..commen… Otmar Lendl
- Re: [PEPPERMINT] DRINKS PROPOSED Charter ..commen… Hadriel Kaplan
- Re: [PEPPERMINT] DRINKS PROPOSED Charter ..commen… Otmar Lendl
- Re: [PEPPERMINT] DRINKS PROPOSED Charter ..commen… Richard Shockey
- Re: [PEPPERMINT] DRINKS PROPOSED Charter ..commen… David Schwartz
- Re: [PEPPERMINT] DRINKS PROPOSED Charter ..commen… Otmar Lendl
- Re: [PEPPERMINT] DRINKS PROPOSED Charter ..commen… Hadriel Kaplan
- Re: [PEPPERMINT] DRINKS PROPOSED Charter ..commen… Richard Shockey
- Re: [PEPPERMINT] DRINKS PROPOSED Charter ..commen… Daryl Malas
- Re: [PEPPERMINT] DRINKS PROPOSED Charter ..commen… Daryl Malas
- Re: [PEPPERMINT] DRINKS PROPOSED Charter ..commen… Daryl Malas
- Re: [PEPPERMINT] DRINKS PROPOSED Charter ..commen… Richard Shockey
- Re: [PEPPERMINT] DRINKS PROPOSED Charter ..commen… Hadriel Kaplan
- Re: [PEPPERMINT] DRINKS PROPOSED Charter ..commen… Richard Shockey
- Re: [PEPPERMINT] DRINKS PROPOSED Charter ..commen… Otmar Lendl
- Re: [PEPPERMINT] DRINKS PROPOSED Charter ..commen… Daryl Malas
- Re: [PEPPERMINT] DRINKS PROPOSED Charter ..commen… Hadriel Kaplan
- Re: [PEPPERMINT] DRINKS PROPOSED Charter ..commen… Hadriel Kaplan
- Re: [PEPPERMINT] DRINKS PROPOSED Charter ..commen… Dwight, Timothy M (Tim)
- Re: [PEPPERMINT] DRINKS PROPOSED Charter ..commen… Daryl Malas
- Re: [PEPPERMINT] DRINKS PROPOSED Charter ..commen… Daryl Malas
- Re: [PEPPERMINT] DRINKS PROPOSED Charter ..commen… Dwight, Timothy M (Tim)
- Re: [PEPPERMINT] DRINKS PROPOSED Charter ..commen… Daryl Malas
- Re: [PEPPERMINT] DRINKS PROPOSED Charter ..commen… Richard Shockey
- Re: [PEPPERMINT] DRINKS PROPOSED Charter ..commen… Hadriel Kaplan
- Re: [PEPPERMINT] DRINKS PROPOSED Charter ..commen… Daryl Malas
- Re: [PEPPERMINT] DRINKS PROPOSED Charter ..commen… Dwight, Timothy M (Tim)
- Re: [PEPPERMINT] DRINKS PROPOSED Charter ..commen… Richard Shockey
- Re: [PEPPERMINT] DRINKS PROPOSED Charter ..commen… Hadriel Kaplan
- Re: [PEPPERMINT] DRINKS PROPOSED Charter ..commen… David Schwartz
- Re: [PEPPERMINT] DRINKS PROPOSED Charter ..commen… PFAUTZ, PENN L, ATTCORP
- Re: [PEPPERMINT] DRINKS PROPOSED Charter ..commen… Richard Shockey
- Re: [PEPPERMINT] DRINKS PROPOSED Charter ..commen… Richard Shockey
- Re: [PEPPERMINT] DRINKS PROPOSED Charter ..commen… Daryl Malas
- Re: [PEPPERMINT] DRINKS PROPOSED Charter ..commen… Dwight, Timothy M (Tim)
- Re: [PEPPERMINT] DRINKS PROPOSED Charter ..commen… Richard Shockey
- Re: [PEPPERMINT] DRINKS PROPOSED Charter ..commen… Guyton, Deborah A
- Re: [PEPPERMINT] DRINKS PROPOSED Charter ..commen… PFAUTZ, PENN L, ATTCORP
- Re: [PEPPERMINT] DRINKS PROPOSED Charter ..commen… Hadriel Kaplan
- Re: [PEPPERMINT] DRINKS PROPOSED Charter ..commen… Dwight, Timothy M (Tim)
- [PEPPERMINT] DRINKS PROPOSED Charter Version 02 Richard Shockey
- Re: [PEPPERMINT] DRINKS PROPOSED Charter ..commen… Hadriel Kaplan
- Re: [PEPPERMINT] DRINKS PROPOSED Charter Version … Hadriel Kaplan
- Re: [PEPPERMINT] DRINKS PROPOSED Charter ..commen… David Schwartz
- Re: [PEPPERMINT] DRINKS PROPOSED Charter ..commen… Richard Shockey
- Re: [PEPPERMINT] DRINKS PROPOSED Charter ..commen… Otmar Lendl
- Re: [PEPPERMINT] DRINKS PROPOSED Charter ..commen… Ray.Bellis
- Re: [PEPPERMINT] DRINKS PROPOSED Charter ..commen… Richard Shockey