Subject: [rddp] Mock WG Last Call on DDP & RDMAP drafts

From: [email-masked]
Date: Tue, 13 Jan 2004 01:21:18 -0500

WG members,

During the rest of January, please review the DDP and
RDMAP drafts:

draft-ietf-rddp-ddp-01.txt
draft-ietf-rddp-rdmap-01.txt

While I can't do an actual WG Last Call on these drafts
until the security draft is close to done, this would
be a good time to check everything else about those
drafts.  Editorial comments can be sent directly to
the principal authors, technical comments need to go
to the list.  The goal is to have versions of the drafts
for Seoul that are ready-to-go except for security-related
issues.

Thanks,
--David (rddp WG chair)

----------------------------------------------------
David L. Black, Senior Technologist
EMC Corporation, 176 South St., Hopkinton, MA  01748
+1 (508) 293-7953             FAX: +1 (508) 293-7786
[email-masked]        Mobile: +1 (978) 394-7754
----------------------------------------------------

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

---

From: Caitlin Bestler <[email-masked]>
Date: Thu, 15 Jan 2004 20:37:55 -0600

I have a minor concern on the The DDP Error Codes
defined in section  9.2 (and used in the RDMAP
terminate message). In general terms, the draft
should clarify that a given packet may have error
conditions that comply with more than one of the
error codes listed, and in that case the implementation
may select any of the correct error codes, even if it
is not the "best" error code.

My specific concern is with the distinction between
"Invalid STag" and "STag not associated with DDP Stream".
It implies that an STag can be "valid", but just not
on the current stream. For many implementations and
local interfaces that is indeed a valid distinction.
However, it should be made clear that the existence
of distinct error codes does not mandate that design.

If the STag is not valid on the specific stream for
the use attempted, the implementation should be free
to simply use the "STag not associated with DDP Stream"
error regardless of whether the STag is valid for other
uses possibly on other DDP Streams.

Indeed, a better description of the error would be
"STag is not valid for use attempted."

The rationale:

1)	Providing any information about other streams is a
	violation of generally accepted security practices.
	Differentiating between "Invalid STag" and "STag
	not valid here" is akin to differentiating between
	"no such user" and "wrong password".
2)	STag validation may be scoped to the DDP Stream
	and/or Protection Domain. Determining whether or
	not the STag is valid *anywhere* may require
	additional work.
3) STag validation may be handled distinctly for
	RDMA Read Responses, in which case the receiver
	only knows that the STag supplied is invalid as
	an RDMA Read Response on this DDP Stream at this
	moment.

Similarly, for untagged buffer errors: if the MSN
is out of range an implementation may or may not
know

-- 
Caitlin Bestler - [email-masked] - http://asomi.com/