[rddp] rddp Yokohama minutes

[[e-mail]]

Since there have been no comments, the DRAFT minutes
are the final minutes.  Thanks, --David

> -----Original Message-----
> From: [e-mail] [mailto:[e-mail]]
> Sent: Tuesday, July 23, 2002 3:38 PM
> To: [e-mail]
> Subject: [rddp] rddp Yokohama DRAFT minutes
> 
> 
> Thanks to Mike Smith for taking notes.  Here are
> the draft minutes.  Please comment either privately
> or to the list - the final minutes will be sent to
> the secretariat around the end of this week.
> 
> Thanks,
> --David
> 
> IETF Remote Direct Data Placement (rddp) WG - DRAFT
> Meeting minutes - July 18, 2002, Yokohama, Japan
> -------------------------------------------------
> 
> Chair: David L. Black ([e-mail])
> 
> -- Agenda Bashing and Administrivia
> 
> rddp is now an IETF Working Group, formed based on the ROI
> (RDMA Over the Internet) BOFs in Salt Lake City and Minneapolis.
> 
> The mailing list is up and running at [e-mail].  To subscribe,
> send email to [e-mail].  Use of the rdma list at Yahoo
> Groups for IETF work has ceased.
> 
> -- Charter and Goal/Milestone review and discussion
> 
> The official WG charter is available at:
> 
> 	http://www.ietf.org/html.charters/rddp-charter.html
> 
> The four work items on the charter encompass the entire scope of
> the WG's activities.  TCP framing was deliberately omitted from that
> list - TCP framing work belongs in the Transport Area (tsvwg)
> WG. The rddp WG is not permitted to standardize changes to transport
> protocols - it may recommend (minor) SCTP specification changes to
> the tsvwg WG, but TCP specification changes are not permitted.
> The rddp WG has a rechartering scheduled for March 2003 whose
> outcome (e.g., whether the WG will be allowed to continue) will
> be based to a large extent on the progress made between now and then.
> 
> The rddp WG is expected to work on mapping its functionality to both
> SCTP and TCP - see the charter.  Work to apply RDDP mechanisms to
> protocols other than SCTP and TCP is outside the current charter -
> those interested in such work, including generic IP-layer mechanisms
> applicable to all protocols that use IP, should submit Internet-Drafts
> as a basis for further discussion.  The planned WG draft mapping RDDP
> to TCP is currently intended to become an Informational RFC 
> rather than
> a standards track RFC - any decision to change this is best done
> with a draft in hand, so consideration will be deferred to the rddp
> WG rechartering currently scheduled for March 2003.  On the
> subject of compatibility with proprietary interconnects/protocols
> that already support RDDP-like functionality (often called RDMA), the
> guidance from the Area Director is that the WG should not go out of
> its way to be incompatible, but likewise, heroic efforts motivated
> solely by such compatibility are also inadvisable.
> 
> The RDMA Consortium (www.rdmaconsortium.org) was brought up.  This
> industry consortium was organized to work on providing functionality
> over TCP, and has a goal of transferring its work to the IETF 
> and putting
> itself out of business.  The RDMA consortium was formed at a 
> time where
> there was some confusion over whether and to what extent the IETF
> would permit RDDP work over TCP - that confusion has now been resolved
> by the rddp WG charter (such work is permitted, but SCTP comes first).
> The WG chair will work with the RDMA consortium towards their goal
> of moving their work into the IETF.  It should be understood that
> "the fix is not in" - while the RDMA Consortium is very 
> likely to submit
> drafts describing its work, that does not preclude others from writing
> drafts on the same or similar topics for consideration by the WG.
> 
> -- RDMA Concerns Draft (draft-black-rdma-concerns-00.txt)
> 
> This draft was based on concerns arising from the Minneapolis BOF
> and evolved to its current form via discussion at an end2end Research
> Group meeting.  This draft is input to the rddp WG, and is 
> not expected
> to become an RFC.
> 
> The topic of potential Intellectual Property Rights issues was raised.
> The only official way to notify the IETF of such issues is to send an
> IPR notice to the IETF - mailing list discussions are not "official
> notice".  If anyone knows of an IPR claim for which they 
> believe a notice
> should have been sent to the IETF but was not, a private email should
> be sent to the WG chair as an initial step.
> 
> An issue was raised about the absence of "application 
> integrity" from the
> RDMA concerns draft - in addition to "system integrity" concerns, the
> overwrites made possible by RDDP functionality open up 
> potential attacks on
> applications via overwriting data between the time that an application
> checks the data and the time that the application makes use 
> of the data.
> This concern will be included in the -01 version of the RDMA 
> concerns draft.
> 
> -- Problem Statement and Requirements drafts
> 	(draft-romanow-rdma-over-ip-problem-statement-00.txt)
> 	(draft-talpey-rdma-over-ip-requirements-00.txt)
> 
> -01 versions of both drafts with minor revisions should hit the
> Internet-Draft servers shortly after the Yokohama meeting week.
> 
> The rddp WG is tasked to produce a problem statement/architecture
> draft along with specifications of an RDDP protocol and an 
> RDDP control
> protocol (for RDMA functionality) and mappings of those protocols to
> SCTP and TCP .  The problem statement draft will be expanded with
> architecture text to become the first of these drafts (one possible
> source is draft-bailey-roi-ddp-rdma-arch-00.txt).  Randy Stewart has
> a draft (draft-stewart-sctp-roi-00.txt) that could serve as the basis
> for the mapping to SCTP.
> 
> There was a discussion about the relationship between RDDP 
> operation sizes
> (as invoked by protocols above RDDP) and transport segment 
> sizes (based on
> network Path MTU).  These sizes ought to be independent, which entails
> segmentation and reassembly in the RDDP layer with the goal 
> of providing
> an RDDP header in each transport segment; SCTP's ability to 
> operate without
> SCTP fragmentation helps, but there are some unavoidable 
> situations in the
> face of Path MTU changes where transport segments may have to be sent
> without an RDDP header in each segment. 
> 
> -- Other Business and/or Discussion
> 
> The division of work for applying RDDP to various protocols 
> will probably
> be similar to the way that the IETF handles MIBs - the rddp WG will do
> the basic work to define the RDDP mechanisms, and then other WGs will
> handle application/mapping to their respective protocols.  For the
> specific case of SRP (SCSI RDMA Protocol), the IP Storage (ips) WG is
> one possible place to do that application/mapping work even though
> the protocol is specified by T10.
> 
> For interface specifications (e.g., application interface to RDDP
> implemented in hardware), drafts are welcome (including the envisioned
> division of functionality between hardware and software), but the IETF
> has not generally been enthusiastic about specifying APIs and 
> the like,
> and does not use API specifications to drive protocol definitions. 
> The RDMA Consortium is currently working on verbs (abstract 
> API definition),
> and it may be appropriate to allow that work to continue there rather
> than transferring it to the IETF.  
> 
> _______________________________________________
> rddp mailing list
> [e-mail]
> https://www1.ietf.org/mailman/listinfo/rddp
> 

_______________________________________________
rddp mailing list
[e-mail]
https://www1.ietf.org/mailman/listinfo/rddp