Re: alias BoF - laugh test

["James Kempf" <kempf@docomolabs-usa.com>]

Is this intended to discuss the trigtran work also? Trigtran has already had
two BOFs but I noticed that they were on the draft agenda up until two days
ago. Also, a few of the recommended reading drafts seem to be from trigtran.

The security focus for transport intermediaries seems reasonable, though I
am undecided about its importance. My personal technical feeling is that
people make too much of wireless links being different in the area of basic
transport and not enough in areas where they really are different, like
handover, and that this might be another instance. Many cases of people
wanting wireless intermediaries result from particular access network
architectures that have different assumptions than the Internet about how a
network should be architected (like, for example, that end to end it not so
important).

However, I will save further technical comments for the BOF.

            jak

----- Original Message ----- 
From: "Peterson, Jon" <jon.peterson@neustar.biz>
To: <iesg@ietf.org>; <iab@ietf.org>
Sent: Thursday, June 19, 2003 1:08 AM
Subject: alias BoF - laugh test


>
> A big night for laugh tests...
>
> This BoF is a successor to the intersec BoF, with a slightly expanded
scope.
>
> - J
>
> ----------------------
>
> (alias) Access Link Intermediaries Assisting Services
>
> chairs: Hui-Lan Lu (Lucent), Kevin Fall (Intel/UC Berkeley)
>
> Several types of access links in widespread use for Internet connectivity
> today have characteristics that affect the operation Internet protocols
and
> services. Low-bandwidth, high latency links patched over telephone lines
via
> modems are one common example. Radio links in wireless networks (such as
> GSM, IS-95, GPRS and 802.11) are another example. These links often have
> undesirable characteristics such as high loss, high delay and low
> reliability.
>
> Transport intermediaries have been used to enhance the performance of
> problematic links in the past (see RFC 3135). This BoF investigates
further
> work in support of transport intermediaries that provide assistance to
> access links, including (but not exclusively) wireless links, primarily in
> the areas of security protocol interaction with transport intermediaries
and
> response to changing link conditions. In particular, existing
intermediaries
> used for these purposes interfere with IPSec and may weaken overall
> end-to-end security - work is therefore necessary to determine how to
> request, authenticate and authorize the services of intermediaries, and
when
> possible to mitigate the interference of intermediaries in security.
>
> This work focuses on support for TCP initially but does not preclude
> consideration of other transport-layer protocols. The relationship of
> transport intermediaries to devices constrained by OPES and UNSAF is also
> critical to the architectural framework.
>
> Reading:
>
>
http://www.ietf.org/internet-drafts/draft-faynberg-intermediary-transport-00
> .txt
> (Note that a revised version of this draft will be available soon.)
>
http://www.ietf.org/internet-drafts/draft-dawkins-trigtran-framework-00.txt
> http://www.ietf.org/internet-drafts/draft-dawkins-trigtran-probstmt-01.txt
>
>
>