Re: Design teams

[Peter Chow <peter@interq.or.jp>]

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
--------------------------------------------------------------------