iSCSI draft status

[Black_David@emc.com]

Folks,

Since I've received off-line questions, and the info
available in the IESG draft tracker is not completely
clear, let me explain my current understanding of the
status of the main iSCSI draft at the IESG.  NOTE:
please do NOT reply to the list on this - all questions/
requests for clarification should be sent to me directly.

In the IESG ballot at:

https://www1.ietf.org/IESG/EVALUATIONS/draft-ietf-ips-iscsi.bal

Randy Bush's comments are erroneously recorded as being
against the main iSCSI draft.  They are in fact against
the boot draft, as indicated by Allison Mankin's Jan 3rd
comment in the main comment log (sorry, static URL not
available, look up the iSCSI draft in the tracker at:
https://datatracker.ietf.org/public/pidtracker.cgi
and click on its DETAIL button to see this).  Randy's
comments on the boot draft (which actually come from the
operations directorate) are sufficiently extensive that a
major new revision of that draft will be required.  More
to come on this, as I'm focusing on the main iSCSI draft
for now.

For the main iSCSI draft, that leaves only Steve Bellovin's
comments, which appear to be tractable - while I have not
worked through the details, my intent is to work directly
with Julian to prepare a new -20 version that addresses
these comments and get it back to the IESG in the very near
future (days).  The IESG can reballot the main iSCSI draft
by itself (i.e., does not have to wait for the more extensive
work that will be needed on the boot draft), and with luck
that can happen this month.

Based on a first pass through Steve's comments, most of them
are editorial.  For the ones that aren't, here's what will
be done to resolve them:

- Decline the suggestion to add underscore ("_") as an allowed
	character in iSCSI names.  I've seen no request in the
	WG to allow this, and naming has been stable enough for
	long enough that this change seems undesirable.
- Rewrite the text that implies that several milliseconds is an
	acceptable iSCSI timeout to avoid that implication.  That's
	much shorter than typical TCP timeouts, and having iSCSI
	give up/retry before TCP doesn't make a lot of sense.
	This text is implementation guidance - it doesn't impose
	any MUST/SHOULD requirements on implementers.
- Delete the text that allows an offer of "None" plus extension
	authentication algorithms for AuthMethod.  The requirement
	will be that CHAP MUST be offered if any extension algorithm
	is offered.  An offer of only "None" plus extension algorithms
	basically requires implementation a proprietary method if
	the counterpart wants to use authentication, and that's
	not kosher.

This email is more of a report than an invitation to discussion, as
I believe the above three bullets are sufficiently minor that we don't
need to go through list discussion/consensus.  I'd ask anyone who
disagrees with any of the above three bullets or with my view that
list discussion is not necessary to send me a note directly *off*
the list, as once list discussion starts, delays to draft revision
may be unavoidable.

The observant reader will note that one of Steve's two crucial
comments (regarding CHAP secrets and reflection attacks) isn't
covered above - that's going to require some additional off-line
work, so stay tuned - I'm sending this now in the belief that
getting the above info out promptly is more important than
getting the complete comment resolution done.

Thanks,
--David

----------------------------------------------------
David L. Black, Senior Technologist
EMC Corporation, 176 South St., Hopkinton, MA  01748
+1 (508) 293-7953 **NEW**     FAX: +1 (508) 293-7786
black_david@emc.com        Mobile: +1 (978) 394-7754
----------------------------------------------------