Re: profiles - a way to simplify iSCSI

[Mark Bakke <mbakke@cisco.com>]

Just noticed that we did not include descriptions for the
columns in the spreadsheet.  Here they are:

1st column - Section number of an internet-draft version
of this spreadsheet, which we will generate if needed.

2nd column - Category; we divided up the different features
into some categories that made sense to us.  The first set
is common to all iSCSI implementations; the second and third
are for those features that apply just to targets or initiators.

3rd column - Feature; short description of each feature.

4th column - Reference; a reference to the section number of the
iSCSI document that best describes the feature and its status.

5th column - Status.

   M = Mandatory
   O = Optional
   R = Recommended (we have none of these now)
   X = Prohibited (we have none of these, either)

   If numbers appear after the status, e.g. M:4.5, it means that
   the feature is mandatory if the feature numbered 4.5 is
   implemented.  I just noticed that some of our numbers had changed,
   so a few of these might still be typos.

6th column - Value.  This is used if the feature is more than just
a check box; for instance, if an implementation supports "Data Digest - Other",
it is used to indicate some reference to what "other" means.

Hope this helps,

Mark

Mark Bakke wrote:
> 
> We've been thinking about how to profile iSCSI implementations
> as well, and Paul Congdon, Matthew Burbridge (both of HP) and
> I have come up with a spreadsheet that sort of follows the PICS
> pro-forma that the IEEE folks use.  Anyway, it appears that this
> might be a useful thing to start discussing.  We have attempted
> to list the major mandatory and optional features, but have not
> had enough review time yet to guarantee that it exactly matches
> the spec, so comments are welcome.
> 
> Julian has placed it on his web page at:
> 
> http://www.haifa.il.ibm.com/satran/ips/iSCSIv6_PICs-5.pdf
> 
> I apologize that this is not in internet-draft form, or if this
> list is not exactly the right place to do this.  However, I think
> that it will help show the sheer number of optional features we
> are faced with, and may help us prioritize what must stay in the
> protocol, and what we could live without in the interest of
> simplicity.
> 
> Hopefully, this will help.
> 
> --
> Mark
> 
> --
> Mark A. Bakke
> Cisco Systems
> mbakke@cisco.com
> 763.398.1054

-- 
Mark A. Bakke
Cisco Systems
mbakke@cisco.com
763.398.1054