SORT BY:

LIST ORDER
THREAD
AUTHOR
SUBJECT


SEARCH

IPS HOME


    [Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

    FW: [Ips] AD comments for iSCSI



    Hi all,
    
    These are some comments from Allison Mankin.
    Forwarding, in case you did not receive directly.
    
    Elizabeth Rodriguez
    IPS co-chair
    
    -----Original Message-----
    From: ips-admin@ietf.org [mailto:ips-admin@ietf.org] On Behalf Of
    Allison Mankin
    Sent: Sunday, October 27, 2002 5:48 PM
    To: ips@ietf.org
    Cc: black_david@emc.com; erodrigu@brocade.com; sob@harvard.edu;
    mankin@psg.com
    Subject: [Ips] AD comments for iSCSI
    
    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
    
    
    
    


Home

Last updated: Mon Oct 28 01:18:59 2002
11986 messages in chronological order