iSCSI TUF/PDU alignment - Procedural matters

[Black_David@emc.com]

With my WG Co-Chair hat firmly on, it's time to clear up a few questions
about IETF procedures on this topic:

> The point about the iSCSI charter is interesting, do others feel that
> the segmentation requirements for TUF/PDU Alignment disqualify it from
> consideration for iSCSI?

If "consideration" means "detailed specification of TUF/PDU alignment in
the iSCSI draft", then it is disqualified.  A reference to the tsvwg draft
on TUF/PDU alignment should be ok, but the strongest possible reference is
"MAY", and the proposal below to move all material about iSCSI use of
TUF/PDU alignment into a separate draft would be a better approach (hint).

> Extending into the realm of complete guesswork, I imagine that even if
> iSCSI couldn't reference TUF AT ALL, it would probably be pretty easy
> to produce an IRFC (or another XRFC?) that defined the use of TUF with
> iSCSI.  Certainly writing the draft would be easy, I'm less clear how
> it might progress to RFC status.

Such a draft would have to use a normative reference to the TUF/PDU
Alignment
specification, and hence could only become an Experimental RFC.  Writing
such a draft with that goal in mind would be fine, and would provide a
good home for any text keys/values that people want to use to negotiate
TUF/PDU alignment for iSCSI.

> If we could guarantee that, hardware-accelerated receivers could use a
> TCP header option to indicate start-of-frame in this segment, and be
> done with it.  I'd even to go to bat with the transport-area
> representative, arguing that the ratio of iSCSI PDUs to expected drops
> is  ``small enough'' that using that portion of the limited TCP option
> space for non-SACK usage was in fact a good trade-off.

That's a TSVWG topic, please take it up there rather than here on the
IPS list.

Responses to and questions about this email should be sent directly
to me, please do not reply to the list.  I'll post clarifications
if they're important, but these sort of procedural discussions are
not a good use of list bandwidth.

Thanks,
--David
---------------------------------------------------
David L. Black, Senior Technologist
EMC Corporation, 42 South St., Hopkinton, MA  01748
+1 (508) 249-6449 *NEW*      FAX: +1 (508) 497-8500
black_david@emc.com         Cell: +1 (978) 394-7754
---------------------------------------------------