[Ips] AD comments for iSCSI

[Allison Mankin <mankin@east.isi.edu>]

Folks,

The following are some AD comments on iSCSI which we would
like to have addressed before its IETF Last Call, presumably in
one more rev before the deadline.  Questions are welcome.

Onward and upward.

Allison
 
P.S. Congrats on the many drafts at or very close to 
IETF Last Call - the Transport Area is very fond of WGs that
come to their conclusions.  

---------

The comments, after a useful discussion with your chairs: 

(1) Naming.  Section 2.2.6.1 lists naming requirements
and uses "MUST" to impose them.  Most of these are not
requirements on implementations, rather they were design
requirements for iSCSI naming.  This section should
be rewritten to describe those requirements as important
properties of iSCSI naming, rather than of names in use,
An example of this being a big problem is the sentence about names
needing to be "reasonably easy to compare" which is a disaster as 
with a MUST next to it in the specifiction, while it was fine
for setting initial requirements.

In addition, there may an editorial problem in the URN
paragraph, as the current well-intentioned text could
imply more than was intended.  I will give you some future
AD guidance after checking with an expert reviewer if there
is an issue in this area.  Do not change the text now.

(2) Stringprep.  Some of the text in Section 2.2.6.2
overlaps and duplicates material in the iSCSI stringprep
draft.  This is a problem, as the iSCSI stringprep draft
should be a sufficient and complete specification of the
application of stringprep to iSCSI.  For example, listing
the dash, dot, and colon characters as acceptable duplicates
material in Sections 1 and 6.2 of the iSCSI stringprep draft.
If these characters are mentioned in this section of the
iSCSI draft, they should be described as reserved for use
in formatting iSCSI names, as the stringprep draft is the
appropriate place to specify them as allowed.

(3) Handling of Security Considerations.   Section 7's
introduction is almost exactly right, except that it should
make [SEC-IPS] more normative, by adding something like the
following after the "SHOULD NOT" sentince:
 "[SEC-IPS] specifies the mechanisms that must be used in order
 to mitigate risks fully described in that document." 
This makes the ips-security normative for use if you want
to deal with the threats.  I don't think 2119 MUST is called
for, but the idea comes across.

Although Section 7 gives a good guideline, and gets the right
stance about threats, with the addition of something like the
language suggested, the introduction of authentication in
in 2.2.3 gives very weak guidelines.  This language is a problem:
  
    >As part of the login process, the initiator and target MAY wish to 
    >authenticate each other and set a security association protocol for 
    >the session. This can occur in many different ways and is subject to 
    >negotiation. 

Make these MAYs stronger consistent with the rest of the specification.
It is strongly expressed elsewhere that in some form authentication
SHOULD be *used* in all circumstances.  The situations in which no 
authentication is needed are sufficiently narrow to fall under RFC 2119, 
Section 3's definition of "SHOULD":
 
   3. SHOULD  This word, or the adjective "RECOMMENDED", mean that
      there may exist valid reasons in particular circumstances to
      ignore a particular item, but the full implications must be
      understood and carefully weighed before choosing a 
      different course.


(4) Somewhere in Section 2, a paragraph is needed to explain iSCSI's
overall approach to SCSI Task Management.  The explanation is roughly:
- SAM-2 specifies task management as if the initiator and
	target interacted synchronously (e.g., as they do over
	a parallel SCSI bus).
- An iSCSI initiator and target interact asynchronously due
	to concurrency in the network and queuing of iSCSI
	commands received out of order (e.g., from different
	TCP connections) for in order delivery to the SCSI
	layer at the target.
- In order to meet SAM-2's expectation that initiators will
	see a synchronous view of task management, iSCSI
	specifies the protocol mechanisms and implementation
	requirements needed to present a synchronous view in
	the presence of the actual asynchrony involved.

This needs to be said in a simple introductory way beforehand
to explain why so much that seems to be SCSI's job is being
done by iSCSI.  It's pure writing/context, no new technical
content.

(5) The abstract needs to be rewritten.  The current abstract
does an ok job of describing iSCSI to a storage-knowledgeable
person, but should be expanded to provide a reasonable context
and motivation for iSCSI to a *network-knowledgeable* person
who may be encountering the *SCSI acronym for the first time.
In addition, references are not allowed in abstracts; please
delete the reference to "[SAM-2]".  It's ok to mention SAM-2
in the abstract, but not ok to have an actual document reference.

(6) The reference in the abstract is an example of a checklist
fault.  The chairs are checking the checklist, but if the editor
can also do this, it'd be good, as should every editor with a draft
in the working group.


_______________________________________________
Ips mailing list
Ips@ietf.org
https://www1.ietf.org/mailman/listinfo/ips