Re: [p2pi] Information in an ALTO protocol

Lisa Dusseault <ldusseault@commerce.net> Wed, 27 August 2008 16:52 UTC

Return-Path: <p2pi-bounces@ietf.org>
X-Original-To: p2pi-archive@ietf.org
Delivered-To: ietfarch-p2pi-archive@core3.amsl.com
Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C2CB23A691F; Wed, 27 Aug 2008 09:52:05 -0700 (PDT)
X-Original-To: p2pi@core3.amsl.com
Delivered-To: p2pi@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 31C3D3A682B for <p2pi@core3.amsl.com>; Wed, 27 Aug 2008 09:52:04 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.65
X-Spam-Level:
X-Spam-Status: No, score=-0.65 tagged_above=-999 required=5 tests=[AWL=1.950, 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 HLWN3ssACzuj for <p2pi@core3.amsl.com>; Wed, 27 Aug 2008 09:52:03 -0700 (PDT)
Received: from gateout01.mbox.net (gateout01.mbox.net [165.212.64.21]) by core3.amsl.com (Postfix) with ESMTP id 083F23A68F4 for <p2pi@ietf.org>; Wed, 27 Aug 2008 09:52:02 -0700 (PDT)
Received: from gateout01.mbox.net (gwsmtp.usa.net [165.212.65.102]) by gateout01.mbox.net (Postfix) with ESMTP id 6DD8ECD60B; Wed, 27 Aug 2008 16:51:02 +0000 (GMT)
Received: from GW1.EXCHPROD.USA.NET [165.212.116.254] by gateout01.mbox.net via smtad (C8.MAIN.3.45S) with ESMTP id XID788mHAqzc6421Xo1; Wed, 27 Aug 2008 16:51:02 -0000
X-USANET-Source: 165.212.116.254 IN ldusseault@commerce.net GW1.EXCHPROD.USA.NET
X-USANET-MsgId: XID788mHAqzc6421Xo1
Received: from [10.1.1.130] ([157.22.41.236]) by GW1.EXCHPROD.USA.NET over TLS secured channel with Microsoft SMTPSVC(6.0.3790.3959); Wed, 27 Aug 2008 10:51:01 -0600
Message-Id: <91D210DB-C42D-4430-A46C-B6CE10AEA4AE@commerce.net>
From: Lisa Dusseault <ldusseault@commerce.net>
To: David R Oran <oran@cisco.com>
In-Reply-To: <BEEA9A6E-26F6-4314-B4B5-EB6396BA3DCF@cisco.com>
Mime-Version: 1.0 (Apple Message framework v928.1)
Date: Wed, 27 Aug 2008 09:51:00 -0700
References: <489B498B.4040804@telecomitalia.it> <20080811143531.GA18911@net.t-labs.tu-berlin.de> <E3361EDE-EDC6-4EF0-9249-B87B6C2D349C@nokia.com> <df9ced400808110837n57c79866se83369300812975e@mail.gmail.com> <20080811165443.GB18911@net.t-labs.tu-berlin.de> <1219070969.6961.37.camel@bart2> <48AAD5EF.5030303@alcatel-lucent.com> <BEEA9A6E-26F6-4314-B4B5-EB6396BA3DCF@cisco.com>
X-Mailer: Apple Mail (2.928.1)
X-OriginalArrivalTime: 27 Aug 2008 16:51:02.0159 (UTC) FILETIME=[16A7E1F0:01C90865]
Cc: p2pi@ietf.org
Subject: Re: [p2pi] Information in an ALTO protocol
X-BeenThere: p2pi@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: P2P Infrastructure Discussion <p2pi.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/p2pi>, <mailto:p2pi-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/pipermail/p2pi>
List-Post: <mailto:p2pi@ietf.org>
List-Help: <mailto:p2pi-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/p2pi>, <mailto:p2pi-request@ietf.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: p2pi-bounces@ietf.org
Errors-To: p2pi-bounces@ietf.org

On Aug 25, 2008, at 12:25 PM, David R Oran wrote:
>
> Many client/server protocols are were initially designed to be
> strictly two party, with no architectural support for proxies or other
> stateful intermediaries (HTTP and RTSP come to mind...there are likely
> many others).
>
> It may behoove us to build proxy capability into ALTO from day 1,
> since it will almost inevitably have to be added later at some level
> of pain, perhaps large, and almost assuredly some undesirable security
> tradeoffs.

You're making the assumption now, that ALTO will need to add proxies  
or intermediaries ("will almost inevitability").  I don't really have  
evidence that you're wrong about that, but I also don't see the use  
cases right now.  Do you have anything specific in mind?

>
>
> This probably involves at least the following:
> - separating our end-to-end from ho--by hop (transport layer?)  
> security
> - clear data model separation between things used to "route" requests
> and things used to interpret queries.
> - a flexible addressing model
> - a way to aggregate and summarize in responses

These are good architectural principles to remember while writing and  
reviewing drafts, assuming they can be followed without falling into  
the trap of designing the be-all and end-all system.

-- Lisa

>
>
> and likely a bunch of other considerations I'm missing in the above.
>
> DaveO.
>
>> Thanks,
>>
>> - vijay
>> -- 
>> Vijay K. Gurbani, Bell Laboratories, Alcatel-Lucent
>> 2701 Lucent Lane, Rm. 9F-546, Lisle, Illinois 60532 (USA)
>> Email: vkg@{alcatel-lucent.com,bell-labs.com,acm.org}
>> WWW:   http://www.alcatel-lucent.com/bell-labs
>> _______________________________________________
>> p2pi mailing list
>> p2pi@ietf.org
>> https://www.ietf.org/mailman/listinfo/p2pi
>
> _______________________________________________
> p2pi mailing list
> p2pi@ietf.org
> https://www.ietf.org/mailman/listinfo/p2pi
>

_______________________________________________
p2pi mailing list
p2pi@ietf.org
https://www.ietf.org/mailman/listinfo/p2pi