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