To:
peter@interq.or.jp (Peter Chow)
Cc:
yu.zhu@i-dns.net (Zhu Yu), ietf-provreg@cafax.se
From:
Bill Manning <bmanning@isi.edu>
Date:
Wed, 21 Mar 2001 12:03:23 -0800 (PST)
In-Reply-To:
<Pine.GSO.3.96LJ1.1b7.1010322023357.11792E-100000@imap.interq.or.jp> from "Peter Chow" at Mar 22, 2001 02:35:16 AM
Sender:
owner-ietf-provreg@cafax.se
Subject:
Re: Design teams
UDP-Pro: low-overhead/lightweight - The fastest transport protocol. desireable for high-volume systems. UDP-Cons: bare-bones - needs a fair amount of application development/API work. "Small" size before fragmentation, however fallback can be to use TCP (with all the TCP checks) % % Zhu, % % Both you and Bill expressed some concerns regarding the lack of support % for UDP. Can either of you summarize the pros and cons of UDP so the % transport team have the benefit of your input? % % On Thu, 22 Mar 2001, Zhu Yu wrote: % % > Yes. % > We got many things to be clarified first % > % > I think the dependancies among 3 design teams will cause confusion and % > conflicts. % > (I am with protocal design team.) % > For example, if I want a connectless transportation scheme, should % > transportation team % > come out with it? How about our protocal support both connection and % > connectionless? % > % > For the role of security team. % > Since it is not clear now where (protocal level or transportation level or % > both?) to put the % > secutiry scheme in, the security teams seem to have no job to do now. % > If we let security come out a scheme, our team and transportation team will % > have to wait % > their result.. % > % > So I think we should clarify such basic things first. Otherwise it seems % > confusing and difficult % > to go on with.. % > % > Hope we can have time slot this afternoon after IDN WG meeting.. % > % > % > ZY % > ----- Original Message ----- % > From: "Edward Lewis" <lewis@tislabs.com> % > To: <ietf-provreg@cafax.se> % > Cc: <lewis@tislabs.com> % > Sent: Wednesday, March 21, 2001 11:26 PM % > Subject: Design teams % > % > % > > First, I would like to set a target date of March 30 for the design teams % > > to submit to the mailing list a set of issues and opinions (so far) so the % > > WG can provide some feedback. This isn't intended to be a deadline for % > the % > > design teams, but a midpoint check on progress. (The "set of issues" can % > > be similar to what was put on screen yesterday, but this time in text.) % > > % > > For the security team, there is one item that seems to need addressing. % > We % > > need to identify the threats that the RRP will have to be defended % > against. % > > Traffic inspection, modification, etc. are documented means of attack. % > > What I have in mind are identification of ways that the RRP may be abused % > > (requesting unauthorized actions, leakage of contact data to spammers, % > > etc.). I do think that we need a better understanding of the 'privacy' % > > issue before declaring it of scope of the protocol. By identifying the % > > threats we can determine which "security" services are needed. % > > % > > For the protocol and transport teams, I'd like there to be some addressing % > > of how the choice of transport will impact the protocol. E.g., if one % > > transport layer offers a security service to the protocol and another % > > transport does not, how will the protocol know to adapt. % > > % > > [1] - Regarding my comment about authorization vs. authentication. IMHO, % > > Authorization is more germaine to the problem here because we want to know % > > if the client (whomever they are) is allowed to request an action. Of % > > course, to make an authoriztion determination, you do need to perform some % > > authenication first. % > > % > > -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=--=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- % > > Edward Lewis NAI Labs % > > Phone: +1 443-259-2352 Email: lewis@tislabs.com % > > % > > Dilbert is an optimist. % > > % > > Opinions expressed are property of my evil twin, not my employer. % > > % > > % > % % -------------------------------------------------------------------- % _/_/_/ Peter Chow Chief Technical Advisor % _/_/_/ peter@interq.ad.jp interQ Inc. - System Division % _/_/_/ ICQ: 41931890 Shibuya Infoss Tower 10F % _/_/_/ (tel)+81-3-5456-2555 20-1 Sakuragaoka, Shibuya-ku % _/_/_/ (fax)+81-3-5456-2556 Tokyo, Japan % _/_/_/ http://www.interq.ad.jp/ 150-0031 % -------------------------------------------------------------------- % -- --bill