iSCSI: Towards Urgent Pointer Consensus

[Black_David@emc.com]

With my WG co-chair hat on, and in an attempt to
make progress towards consensus on this.

The only text that seems to have a chance of gaining
rough consensus on the list is Daniel Smith's:

  "During login, if the target requests use of the Urgent Pointer (UP) then
  this should be taken as meaning that the target will operate more 
  efficiently when the UP is used.  The initiator should make an effort to
use
  the UP.  If it is unable (or unwilling, because of user intervention*) to 
  use the UP then it must indicate its non-compliance to the target."

and likewise for target sending to the initiator,
although I would substitute "SHOULD" for "should
make an effort to", and change "must indicate its
non-compliance" to "MUST indicate its inability".

In other words for each sender-receiver pair
(initiator sending to target and v.v.), the sender
SHOULD implement Urgent support, and the receiver MAY
choose to request use of it via a negotiation
mechanism that gets both sides to agree on use
or non-use of the mechanism.

[NB: For those not familiar with this area
of IETF lingo, in general any use of MUST,
SHALL, SHOULD, MAY, OPTIONAL, RECOMMENDED,
REQUIRED, MUST NOT, SHALL NOT, or SHOULD NOT
as capitalized words intends the meanings
defined in RFC 2119.  This is always the
case in standards track RFCs, and is a
common email convention.  Please see
RFC 2119 for a complete explanation.]

I understand that there are people on the list who
want to see MUST used to require implementation and/or
use of Urgent support.  That is unlikely to happen
for two reasons:

(1) The WG rough consensus on the list still rejects
	this position.  From a consensus standpoint, if
	a sufficient set of people want to insist on
	MUST, we'll have to take this issue to San Diego.

(2) Based on the discussion to date, the advocates
	of the Urgent mechanism have not met the
	burden required by RFC 2119 to use MUST. 
	Section 6 of RFC 2119 says:

   Imperatives of the type defined in this memo must be used with care
   and sparingly.  In particular, they MUST only be used where it is
   actually required for interoperation or to limit behavior which has
   potential for causing harm (e.g., limiting retransmissions)  For
   example, they must not be used to try to impose a particular method
   on implementors where the method is not required for
   interoperability.

	I think a fair characterization of the discussion to
	date is that the Urgent mechanism is a potentially
	important optimization for a certain class of
	implementations.  This falls significantly short of
	the RFC-2119 criteria for MUST.

	Unless something changes, I don't see how your WG chairs
	are going to be able to defend MUST to the ADs and IESG,
	and in practice, we'll probably have our work cut out for
	us defending the SHOULD in Daniel's text.

Beyond this, I have a couple of remarks about the
conduct of the discussion:

- I want to specifically thank and encourage Randall
	Stewart and Dick Gahan for working through some
	of the details of how well the mechanism is
	likely to work and what's at stake in specific
	situations.  This sort of detailed analysis is
	useful in illuminating the value/utility of
	proposed mechanisms such as this one.
- On the other hand, I want to discourage general
	"end of the world"-ish pronouncements that
	iSCSI will "fail" in some sense if this or that
	isn't done precisely as the poster wants.
	Such messages are not helpful, and should be
	cut down to the technical points that the
	sender wishes to contribute to the discussion.

This is not a consensus call, yet, but rather a
summary of status and hopefully a hint or two about
what it'll take to get to consensus.

Thanks,
--David

---------------------------------------------------
David L. Black, Senior Technologist
EMC Corporation, 42 South St., Hopkinton, MA  01748
+1 (508) 435-1000 x75140     FAX: +1 (508) 497-8500
black_david@emc.com       Mobile: +1 (978) 394-7754
---------------------------------------------------