RE: Design teams

["Hollenbeck, Scott" <shollenbeck@verisign.com>]

UDP Con: Delivery not guaranteed, undesirable in a high volume system where
transactional integrity is important.

I may think of more as time goes on ;-)

<Scott/>

-----Original Message-----
From: Bill Manning
To: peter@interq.or.jp
Cc: yu.zhu@i-dns.net; ietf-provreg@cafax.se
Sent: 3/21/01 3:03 PM
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