[storm] RDMAP opcodes - proposal

[<[e-mail]>]

After thinking about the RDMAP opcode situation over the weekend, I have a proposed course of action.  Please comment, as I would like to move on this fairly quickly in order to get both the MPA Peer Connect and RDMAP registries drafts approved by the IESG.

There are 8 currently unused RDMAP opcodes.  The RDMAP extensions draft will use 4 of them, and setting aside 1 more for test/experimentation leaves 3.  I'm not comfortable committing to a course of action that consumes more than half of the unused opcodes without taking a good hard look at the alternatives and consequences.  Hence I propose to do the following:

(1) Defer allocation of text/experimentation RDMAP opcode to RDMAP extensions draft, which is already going to allocate RDMAP opcodes.

(2) As part of discussion of the RDMAP extensions draft, consider the 2 reserved (and currently unused) bits that are adjacent to the RDMAP opcode field.  Although any use of those bits requires modifying RFC 5040 (RDMAP), that's a reasonable thing for the RDMAP extensions draft to do *if* it won't cause serious implementation problems.

(3) As part of the discussion of the reserved bits, the following questions should be addressed:
- Does the RDMAP extensions draft need 4 opcodes?  For example, would 2 opcodes
	plus use of one of the reserved bits as a direction bit (Request/Response)
	for those two opcodes be a better approach?
- Should 4 or 8 of the currently unused 4-bit RDMAP opcodes be turned into 6-bit
	opcodes by including the two reserved bits?

Implementation concerns matter to this discussion, as they may constrain practical use of those 2 reserved bits.  By deferring allocation of the test/experimentation opcode, we keep our options open for this discussion.

Does this sound like a reasonable plan?

Thanks,
--David
----------------------------------------------------
David L. Black, Distinguished Engineer
EMC Corporation, 176 South St., Hopkinton, MA  01748
[phone]             FAX: [phone]
[e-mail]        Mobile: [phone]
----------------------------------------------------