Re: Design teams

["Zhu Yu" <yu.zhu@i-dns.net>]

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