RE: [rddp] Draft DC minutes

Black_David@emc.com Tue, 23 November 2004 01:25 UTC

Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA16868 for <rddp-web-archive@ietf.org>; Mon, 22 Nov 2004 20:25:10 -0500 (EST)
Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CWPUC-0006XB-Ch for rddp-web-archive@ietf.org; Mon, 22 Nov 2004 20:28:52 -0500
Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CWPIw-0002HN-CI; Mon, 22 Nov 2004 20:17:14 -0500
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CWP4J-0007QU-3Y for rddp@megatron.ietf.org; Mon, 22 Nov 2004 20:02:07 -0500
Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA14496 for <rddp@ietf.org>; Mon, 22 Nov 2004 20:02:06 -0500 (EST)
From: Black_David@emc.com
Received: from mailhub.lss.emc.com ([168.159.2.31]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CWP7q-0003T8-UT for rddp@ietf.org; Mon, 22 Nov 2004 20:05:48 -0500
Received: from mxic2.corp.emc.com (mxic2.corp.emc.com [128.221.12.9]) by mailhub.lss.emc.com (Switch-3.1.6/Switch-3.1.6) with ESMTP id iAN1235L012004 for <rddp@ietf.org>; Mon, 22 Nov 2004 20:02:03 -0500 (EST)
Received: by mxic2.corp.emc.com with Internet Mail Service (5.5.2653.19) id <VPLCBNTG>; Mon, 22 Nov 2004 20:02:02 -0500
Message-ID: <B459CE1AFFC52D4688B2A5B842CA35EA07E5CB3F@corpmx14.corp.emc.com>
To: rddp@ietf.org
Subject: RE: [rddp] Draft DC minutes
Date: Mon, 22 Nov 2004 20:02:02 -0500
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: text/plain
X-PMX-Version: 4.6.1.107272, Antispam-Core: 4.6.1.106808, Antispam-Data: 2004.11.22.29
X-PerlMx-Spam: Gauge=, SPAM=7%, Report='EMC_FROM_0 -0, __TLG_EMC_ENVFROM_0 0, __IMS_MSGID 0, __HAS_MSGID 0, __SANE_MSGID 0, NO_REAL_NAME 0, __TO_MALFORMED_2 0, __MIME_VERSION 0, __ANY_IMS_MUA 0, __IMS_MUA 0, __HAS_X_MAILER 0, __CT_TEXT_PLAIN 0, __CT 0, __MIME_TEXT_ONLY 0'
X-Spam-Score: 0.3 (/)
X-Scan-Signature: 202a3ece0492a8c7e7c8672d5214398f
X-BeenThere: rddp@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: "IETF Remote Direct Data Placement \(rddp\) WG" <rddp.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/rddp>, <mailto:rddp-request@ietf.org?subject=unsubscribe>
List-Post: <mailto:rddp@ietf.org>
List-Help: <mailto:rddp-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/rddp>, <mailto:rddp-request@ietf.org?subject=subscribe>
Sender: rddp-bounces@ietf.org
Errors-To: rddp-bounces@ietf.org
X-Spam-Score: 0.3 (/)
X-Scan-Signature: 2bf730a014b318fd3efd65b39b48818c

Having seen no comments, these are now the final minutes
that will be sent to the secretariat for the proceedings,
and the sense of the room decisions from DC are now the
rough consensus of the RDDP WG.

Thanks,
--David

> -----Original Message-----
> From: rddp-bounces@ietf.org [mailto:rddp-bounces@ietf.org] On 
> Behalf Of Black_David@emc.com
> Sent: Monday, November 15, 2004 7:16 PM
> To: rddp@ietf.org
> Subject: [rddp] Draft DC minutes
> 
> This is also an opportunity for anyone on the list
> to object to decisions taken in DC - they're flagged
> in [square brackets].  In the absence of objection,
> those decisions are the rough consensus of the RDDP WG.
> Also note that "?" is a bullet in this (Microsoft
> strikes again ...), it does not introduce a question
> or open issue - those are indicated by "?" after a
> word (generally end of a line of text).
> 
> Thanks,
> --David
> 
> RDDP Minutes - 61st IETF Meeting DRAFT
> 11/8/2004
> Washington D.C.
> --------------------------------
> 
> Thanks to Hemal V. Shah for taking the minutes
> 
> *	Agenda bashing
> 
> *	Status of drafts (from all authors)
> 	o	Problem statement has been in RFC editor queue.
> 	o	Architecture document very close to being in RFC editor
queue.
> 	o	RDMAP/DDP drafts are not ready for WG last call at this
point.
> 		Security sections need to be checked for MUST implement
> 		IPsec (RFC 3723). Only open issues are security
requirements.
> 	o	Applicability draft (when to use SCTP versus TCP) in
process.
> 	o	Once we have security requirements in RDMAP/DDP drafts, then
> 		security, DDP, and RDMAP drafts will go to the first round
> 		of WG Last Call.  
> 	o	Second batch of last calls will be MPA, SCTP, and
> Applicability.
> 
> *	Security draft (Presenter: Jim Pinkerton) [B]
> 	o	Major changes
> 		?	Quickly iterated -03, -04, and -05 in one month.
> 		?	Changed the draft to be standards track
> 		?	Resolved several TBDs: channel binding, connection
hijacking,
> 				finished summary tables of attacks in
appendix
> 		?	New or substantially revised appendices: appendix A
is
> 			normative, appendices B & C are informative.
> 	o	Major new normative statements
> 		?	Most RECOMMENDED statements were changed to
MUST/MAY.
> 		?	IPsec is MUST implement and OPTIONAL to use
> 		?	Resource manager
> 			*	MUST be used if a scarce resource
> 			*	MUST NOT assume shared partial mutual trust
> 	o	Planned changes to -06 draft
> 		?	Resolve some more TBDs.
> 		?	Need review.
> 
> *	RDMAP Security issues (Presenter: Renato Recio) [C]
> 	o	RDMAP and DDP drafts need to have security requirements.
> 	o	Approach
> 		?	List out informative text
> 		?	Summary of RDMAP specific security requirements
> 		?	Security services for RDMAP
> 	o	Security Model and general assumptions
> 		?	Mainly list the attacks, attack types, and
resources.
> 			Details are in RDMA security draft.
> 	o	RDMAP specific security requirements
> 		?	Privileged resource manager requirements
> 	o	There are some requirements that might be added to RDMAP and
> 			RDMA security drafts
> 	o	Need to revise MUST requirement on firmware load in RDMA
> 			security draft.
> 	o	List of normative requirements will be sent to the
reflector.
> 	o	Email discussion on the reflector on the normative text.
> 	o	DDP draft will address the requirements on the list through
> 			the discussions and then it will be added to the
draft.
> 
> *	MPA (Presenter: Paul Culley) [D]
> 	o	Issues
> 		?	Need to add text from the security draft
> 		?	Marker pointer clarification
> 		?	Minor clarification of meaning of "connection
establishment"
> 	o	Zero-markers
> 		?	Where do the non-zero markers of the FPDU point to?
> 			*	ULPDU_length
> 			*	Or Zero-marker
> 		?	Marker should point to ULPDU_length instead of start
of
> 			FPDU-Hdr [sense of room]
> 	o	IPsec requirement is it needed in MPA?
> 		?	Need to cross-reference requirement from DDP.
> 			*	Safest thing to do is have MPA list IPsec as
MUST
> 				implement and optional to use.  Derived from
DDP
> 				requirement as DDP is the only protocol that
can
> 				be above MPA.  [no objection]
> 
> *	SCTP mapping (Presenter: Caitlin Bestler) [E]
> 	o	Main changes
> 		?	Updated to new boilerplate (e.g., IPR)
> 		?	SCTP/MPA differences noted
> 			*	Size of private data 512 B for SCTP mapping
> 			*	MPA requires first FPDU come from initiating
side
> 			*	In MPA spec, we need specify that MPA MUST
allow
> 				private data up to 512B.
> 		?	Session control changed to align with MPA
> 			*	Only one exchange per side. Eliminated
negotiate
> 				message.
> 			*	Added explicit reject message.
> 		?	Dealt with small PDUs
> 
> *	iWARP interoperability w/RDMAC versions + APIs (Presenter: John
Carrier) [F]
> 	o	Interoperability on the wire
> 		?	RDMAC/IETF RDMAP/DDP protocols have same semantics
and
> 			wire protocol format, but they both use different
versions.
> 		?	No standard way for ULPs to exchange version
information that
> 			could be used to configure the RNICs
> 		?	If IETF implementation decides to turn markers off,
then IETF
> 			RNIC won't interoperate with RDMAC RNIC.
> 	o	Interoperability above RDDP
> 		?	Discussion on standardizing private data format -
Not appropriate
> 			to specify ULP data format [sense of room]
> 		?	Add a requirement on that version information should
be
> 			available to ULP [sense of room]
> 		?	No consensus on the private data format.
> 			*	Worry around breaking the existing
implementations.
> 		?	Within a week, the text on the interoperability will
be generated 
> 			and sent to list.  It'll be headed for appendices of
the
> 			MPA, DDP, and RDMAP protocol drafts. [no objection]
> 
> *	Next steps
> 	o	Revise security draft.
> 	o	Add appropriate security requirements in DDP & RDMAP.
> 
> *	Meeting adjourned @ 9:30pm on November 8, 2004.
> 
> _______________________________________________
> rddp mailing list
> rddp@ietf.org
> https://www1.ietf.org/mailman/listinfo/rddp
> 

_______________________________________________
rddp mailing list
rddp@ietf.org
https://www1.ietf.org/mailman/listinfo/rddp