Re: last call before interop is resolved?

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"
>
>
>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

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