Subject: [rddp] last call before interop is resolved?

From: "Jim Pinkerton" <[email-masked]>
Date: Fri, 3 Dec 2004 05:51:31 -0800

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-masked]
https://www1.ietf.org/mailman/listinfo/rddp

---

From: Michael Krause <[email-masked]>
Date: Sat, 04 Dec 2004 14:35:14 -0800

I concur.  We need to get a good handle on interoperability since there 
will be a time differential between the two sets of specs relative to 
deployment.  The draft proposal makes a good start on how to document the 
minor changes required to resolve this issue.  Therefore, we should drive 
to get closure no later than January which should have minimum impact on 
last call.

Mike

At 05:51 AM 12/3/2004, Jim Pinkerton wrote:
>Content-class: urn:content-classes:message
>Content-Type: multipart/alternative;
>         boundary="----_=_NextPart_001_01C4D93F.32F78B0F"
>
>
>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.
>
>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
>
>
>