Re: [storm] UML, Model and Terminology

Hi Mallikarjun,

> > The UML, model and terminology mapping in Sections 3-5 need to be done
> 
> I am not 100% sure about what you mean - are you saying there's more work
> that needs to be done here?  If so, can you please call it out?

No, I meant to say that the work is needed as part of what we're doing on iSCSI - the work appears to be sufficient in its current form.

> The authors' original rationale for including the iSCSI UML modeling,
> including aligning the iSCSI concepts to SAM UML classes, in this draft was
> that it's appropriately tackled in a SAM-4/5 mapping draft as IIRC SCSI UML
> modeling didn't exist in pre-SAM-4.  But OTOH, as you note, the modeling
> here is really generic with no SAM-4-specific content on the iSCSI side.  So
> I guess I'm OK to move it to the consolidated draft.

As part of doing that, I would move the change that allows an iSCSI node to contain both initiator and target functionality to the consolidated draft.

Thanks,
--David

> -----Original Message-----
> From: Mallikarjun Chadalapaka [mailto:cbm@chadalapaka.com]
> Sent: Monday, March 08, 2010 1:44 AM
> To: Black, David; storm@ietf.org
> Subject: UML, Model and Terminology
> 
> Hi David,
> 
> > The UML, model and terminology mapping in Sections 3-5 need to be done
> 
> I am not 100% sure about what you mean - are you saying there's more work
> that needs to be done here?  If so, can you please call it out?
> 
> >(RFC 3720 does not permit this, but I suspect that to be an
> > oversight as opposed to intentional).
> 
> Yes, I believe that to be the case - we had not planned to disallow
> initiator+target implementations.  I will take the action item to address it
> in the next revision of the consolidated draft.
> 
> > I wonder whether this material would be
> > better moved to the consolidated iSCSI draft
> 
> The authors' original rationale for including the iSCSI UML modeling,
> including aligning the iSCSI concepts to SAM UML classes, in this draft was
> that it's appropriately tackled in a SAM-4/5 mapping draft as IIRC SCSI UML
> modeling didn't exist in pre-SAM-4.  But OTOH, as you note, the modeling
> here is really generic with no SAM-4-specific content on the iSCSI side.  So
> I guess I'm OK to move it to the consolidated draft.
> 
> Thanks.
> 
> Mallikarjun
> 
> 
> 
> > -----Original Message-----
> > From: storm-bounces@ietf.org [mailto:storm-bounces@ietf.org] On Behalf Of
> > Black_David@emc.com
> > Sent: Wednesday, February 24, 2010 2:34 PM
> > To: storm@ietf.org
> > Cc: Black_David@emc.com
> > Subject: [storm] Comments on draft-ietf-storm-iscsi-sam-00.txt
> >
> > <WG Co-Chair hat OFF>
> >
> > With the WG last call on the iFCP-related drafts completed (summary
> message
> > coming soon from Tom), it's time to turn attention to this draft.  This
> draft
> > has been subject to significant review from a number of
> iSCSI-knowledgeable
> > people prior to submission, so it's in very good shape for a -00 draft.
> >
> > I have a few comments, mostly intended to start discussion.  To respond to
> > this message, please pick one of the comments below to respond to in a
> single
> > email message, and CHANGE THE SUBJECT LINE of the email.
> >
> > [1] UML, model and terminology mapping.
> >
> > The UML, model and terminology mapping in Sections 3-5 need to be done,
> and in
> > particular it's crucial to permit the device structure example shown at
> the
> > end of Section 5 (RFC 3720 does not permit this, but I suspect that to be
> an
> > oversight as opposed to intentional).  I wonder whether this material
> would be
> > better moved to the consolidated iSCSI draft, as that may be a more
> > appropriate home for it; that decision does not need to be made now.
> >
> > [2] RFC 3720 change summary
> >
> > I would like to see a "Summary of Changes to RFC 3720" section, this could
> be
> > accomplished by expanding Section 2.3 to list the specific changes, which
> are:
> >
> > - iSCSI Node may contain both initiator and target functionality (Section
> 5)
> >
> > - PRI field for SCSI Command Priority added to SCSI Command PDU (Section
> > 7.1.1)
> > - Status Qualifier field added to SCSI Response PDU (Section 7.2.1)
> > - Sense data may be returned (via Autosense) for any SCSI status, not
> > 	just CHECK CONDITION (Section 7.2.2)
> > - Four new task management functions: QUERY TASK, QUERY TASK SET, I_T
> NEXUS
> > RESET,
> > 	QUERY ASYNCHRONOUS EVENT (Section 8.2).
> > - New "function succeeded" response code for the new task management
> functions
> > (Section 8.3.1)
> > - New PDUFormatForSAMUpdate text key to negotiate iSCSI support for the
> above
> > features (except for "iSCSI node may contain both initiator and target
> > functionality", which should be allowed no matter what, IMHO).
> >
> > [3] Section 9.1.1.  I don't like the phrase "RFC compliance level" and
> suggest
> > replacing the "This key ..." paragraph with
> >
> > 	This key is used to negotiate presence of iSCSI support for the
> features
> > defined in this RFC.
> >
> > I strongly suggest moving the "Note that ..." paragraph from Section 9.1.1
> to
> > Section 6.  I would also add an example. Here's a possible example that
> should
> > help illuminate the distinction between SCSI and iSCSI errors:
> > - An iSCSI implementation may negotiate this new key to "Yes" but respond
> to
> > the new task management functions with a "Task management function not
> > supported" (that response reports a SCSI error that prevents the function
> from
> > being performed).
> > - In contrast but if that key is negotiated to "Yes", an iSCSI
> implementation
> > must not reject a Task Management Function Request PDU that requests one
> of
> > the new task management functions (that reject reports an iSCSI protocol
> > error).
> >
> > [4] Nit: "compliant"
> >
> > I don't like use of this word in RFCs, but this is an editorial matter of
> > taste.  Here are a couple of suggested rewordings that I think also
> improve
> > clarity:
> >
> > - Section 7.1.1
> > OLD
> >    As defined in Section 10, iSCSI PDU Formats of [RFC3720],
> >    compliant senders already set this field to zero.
> > NEW
> >    Section 10 of [RFC3720] requires that senders set this field to zero.
> >
> > - Section 8.2
> > OLD
> >    Any compliant sender MUST NOT send these task management function
> >    requests unless ...
> > NEW
> >    These task management function request MUST NOT be sent unless ...
> >
> > [5] Minor Nit: text key name
> >
> > While PDUFormatForSAMUpdate is not the key name I would have chosen, I
> didn't
> > put in all the time and effort to write this draft ;-).  That key name is
> ok
> > with me.
> >
> > I'll plan to review this draft again when it gets to WG Last Call ...
> >
> > Thanks,
> > --David
> > ----------------------------------------------------
> > David L. Black, Distinguished Engineer
> > EMC Corporation, 176 South St., Hopkinton, MA  01748
> > +1 (508) 293-7953             FAX: +1 (508) 293-7786
> > black_david@emc.com        Mobile: +1 (978) 394-7754
> > ----------------------------------------------------
> >
> > _______________________________________________
> > storm mailing list
> > storm@ietf.org
> > https://www.ietf.org/mailman/listinfo/storm
> 