RE: last call before interop is resolved?

"Caitlin Bestler" <[email protected]> Fri, 3 Dec 2004 11:34:28 -0800
Newsgroups gmane.ietf.rddp
Message-ID <[email protected]>
I agree. The *most* that we might have to change is to make it clear
that an
iWARP implementation *may* choose to interoperate with the RDMAC
versions,
and that there is nothing in the main drafts that forbids this.
 
The requirements on what is a "valid" version number is the only thing
that
might have to be clarified, so I think it is doable. I also do not think
it is
necessary, since interoperability is extra functionality which has no
impact
on the pure IETF protocol. But it is better to be clear that more
liberal interpretation
of "valid" that enables interoperability *is* legitimate and even ever
so slightly
encouraged (but probably not to the level of a "should").
 


________________________________

	From: [email protected] [mailto:[email protected]] On
Behalf Of Jim Pinkerton
	Sent: Friday, December 03, 2004 5:52 AM
	To: [email protected]
	Subject: [rddp] last call before interop is resolved?
	
	

	 

	I am very concerned that the current path we're on is to try to
do last call before we close on the interop issues with the RDMA
Consortium protocols. To me this would be a mistake because it
effectively fragments the market when in fact we have a very concrete
interop proposal on the table that appears to be holding water, which
has very specific text change recommendations that appear to be
straightforward to put into the specs.

	 

	Can we quickly get through the interop changes to MPA/DDP/RDMAP?
Seems like the only outstanding issue raised so far is what is the exact
text used in the RDMAP/DDP specs on what is a "valid" version number
(i.e. do we leave it up to the vendor, or do we state something more
explicit). That seems like a pretty small outstanding issue? 

	 

	Further, it seems like we should be able to get out updated
drafts within a few days which incorporate the recommendations, and the
recommendations do not have significant complexity to implement in the
normative body of the specs (unlike the outstanding issue of normative
statements in the security chapters of DDP/RDMAP (!!).

	 

	 

	Jim

_______________________________________________
rddp mailing list
[email protected]
https://www1.ietf.org/mailman/listinfo/rddp