Re: [PEPPERMINT] DRINKS PROPOSED Charter ..comments please.
"Daryl Malas" <D.Malas@cablelabs.com> Tue, 22 April 2008 17:05 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 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 <peppermint@core3.amsl.com>; 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 <peppermint@core3.amsl.com>; 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 <peppermint@ietf.org>; 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><E6C2E8958BA59A4FB960963D475F7AC30BD035B4EF@mail.acmepacket.com><20080420211101.GA32096@nic.at><1a6601c8a3dd$49ca8c50$dd5fa4f0$@us> <20080422144452.GA582@nic.at>
From: Daryl Malas <D.Malas@cablelabs.com>
To: 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
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 <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] 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