Subject: RE: profiles - a way to simplify iSCSI

From: [email-masked]
Date: Thu, 21 Jun 2001 19:23:28 -0400

> iSCSI keeps getting richer in negotiable parameters/features.
> Although flexibility is a great thing every new negotiable
> parameter/feature get us all worrying about:
> 
>    what it will break when used in combination with other
>    parameters/features
>    how are we going to test that all our combinations work as we think
that
>    they are specified
>    are we understanding/specifying the combinations the same way as
anybody
>    else

All worthy questions, but I think one important one
is left out - Why does iSCSI have so many negotiable
parameters/features? This leads into ...

> I assume that many of you are wondering, as I do, if all this flexibility
> is really worth it's price.

If it leads to implementations that fail to
interoperate, the answer is "no".

> Would the community not be better served by specifying profiles that are a
> complete-and-invariable combination of features and very small set of
> numerical parameters?

I think it's incumbent on the WG to reduce the amount
of flexibility by removing things and restricting
implementation flexibility (e.g., specifying that for a
certain set of features implementations MUST support
all of the features in the set if they support any one
of them).  This belongs in the main body of the
specification, not a separate profile.  See RFC 2119
for the appropriate terms to use in specifying requirements
for implementations.

IMHO, if a specification requires profiles in order to
obtain interoperable implementations, then the specification
itself is insufficiently precise and needs to be tightened
in order to merit approval as a proposed standard RFC.

It's time to start thinking about what we can take out ...

Writing as an IPS WG co-chair,
--David

---------------------------------------------------
David L. Black, Senior Technologist
EMC Corporation, 42 South St., Hopkinton, MA  01748
+1 (508) 435-1000 x75140     FAX: +1 (508) 497-8500
[email-masked]       Mobile: +1 (978) 394-7754
---------------------------------------------------

---

From: Scott Bradner <[email-masked]>
Date: Thu, 21 Jun 2001 21:41:46 -0400 (EDT)

note that this AD would not support publishing a IPS protocol that 
includes profiles - it is my opinion that the existance of profiles
indicates a failed standards process in most cases

Scott

---

From: "Robert Griswold" <[email-masked]>
Date: Fri, 22 Jun 2001 09:19:47 -0500

Julian:

Well, drawing on my experience from the consumer storage specs
(ATA/ATAPI/MMC), profiles and features lead to huge interoperability
problems.  The issue for robust (full featured) targets and initiators
is they have to chase down every single interpretation of feature sets,
some that they don't even care about, so the devices are not caught in
transport or command sequences they have no idea about.  I am in
agreement with David Black and others who have specified that the iSCSI
transport needs simplicity rather than complexity; I fear that providing
still more optional implementations would lead to more problems.  If we
believe the hype from the press, then iSCSI will make for cheap targets,
which means fast product schedules and low engineering and test coverage
from companies that could ship millions of little iSCSI boxes.  A
tighter iSCSI specification might help keep some of these potential
interoperability problems from becoming wildfires.

Bob

Robert Griswold
Technologist
Crossroads Systems, Inc.
512-928-7272

 -----Original Message-----
From: 	[email-masked] [mailto:[email-masked]] 
Sent:	Thursday, June 21, 2001 12:15 PM
To:	[email-masked]
Subject:	profiles - a way to simplify iSCSI

Dear colleagues,

I assume that many of you are wondering, as I do, if all this
flexibility
is really worth it's price.
Would the community not be better served by specifying profiles that are
a
complete-and-invariable combination of features and very small set of
numerical parameters?

I would start with 2 profiles:

   the minimal profile (only basic features)
   the maximum profile (all the features)

and then (only if we are strongly convinced it is needed) add a middle
point.

Please comment,
Julo

---

From: "Robert Griswold" <[email-masked]>
Date: Fri, 22 Jun 2001 13:29:21 -0500

Julo:

That is exactly what the MMC and ATA/ATAPI specifications do, the
declare the basics; options and required, then group them into
functional profiles or feature sets.  Setting off minimums, maximums and
middle ranges will create classes and sub-classes of implementations.
This will force those who don't create end-node targets to have deep
understandings of problems associated with feature set
misinterpretations, and convert un-implemented commands and responses
for different levels of feature implementation.  I am all for making it
easier, and if this group can make it easier and more reliable with this
effort, then I am up to learning all about it.  My past experience tells
me this could be difficult.  I will attempt an unbiased watching of this
as it develops.  Good Luck.

Bob

Robert Griswold
Technologist
Crossroads Systems, Inc.
512-928-7272

 -----Original Message-----
From: 	[email-masked] [mailto:[email-masked]] 
Sent:	Friday, June 22, 2001 10:15 AM
To:	[email-masked]
Subject:	RE: profiles - a way to simplify iSCSI

Robert,

Profiles are meant INSTEAD -OF not in addition to the current set of
features.
I appreciate your concerns but I think that I must have misstated the
profile intention.
A profile will be an exact mapping of a set of functions we have today.
As such it will be SIMPLER both to implement and test.

Julo

"Robert Griswold" <[email-masked]> on 22-06-2001 17:19:47

Please respond to "Robert Griswold" <[email-masked]>

To:   Julian Satran/Haifa/IBM@IBMIL
cc:   [email-masked]
Subject:  RE: profiles - a way to simplify iSCSI

Julian:

Bob

Robert Griswold
Technologist
Crossroads Systems, Inc.
512-928-7272

 -----Original Message-----
From:     [email-masked] [mailto:[email-masked]]
Sent:     Thursday, June 21, 2001 12:15 PM
To:  [email-masked]
Subject:  profiles - a way to simplify iSCSI

Dear colleagues,

Please comment,
Julo

---

From: [email-masked]
Date: Fri, 22 Jun 2001 10:32:09 +0300

David,

I would like to clarify a semantic nit before a go to your more substantive
questions.
I do not mean that we have to introduce profiles (as some other RFCs have)
as accompanying docs but rather make 2 or 3 profiles part of iSCSI and have
them REPLACE the plethora or features we have now and will contain a fixed
set of capabilities (e.g. a device that declares itself profile 0 has only
the features mandatory to implement while a device that declares itself
profile-x has all the mandatory and optional features).

As for why do we have so many things that can be negotiated - I think we
have less than many other standards but we  have to face the fact that
different segments of our community target different parts of the SCSI
solutions domain
and each of the have legitimate concerns about functions and price.

Julo

[email-masked] on 22-06-2001 02:23:28

Please respond to [email-masked]

To:   Julian Satran/Haifa/IBM@IBMIL, [email-masked]
cc:
Subject:  RE: profiles - a way to simplify iSCSI

that
anybody

a

---

From: Scott Bradner <[email-masked]>
Date: Fri, 22 Jun 2001 19:13:25 -0400 (EDT)

there seems to be a misunderstanding somewhere - I was trying to say
nicely that a IPS protocol that has to have profiles would not pass
the IESG but I guess I was too nice - 

I expect that teh IESG would return any such proposal to the WG for
rework if such a proposal makes it to the IESG

i.e the discussion in the followintg posting is not a productive path
to be following

Scott

(one of the TSV area directors)

-----

---

From: "John Hufferd" <[email-masked]>
Date: Fri, 22 Jun 2001 11:12:41 -0700

I have been traveling so I did not put my 2 cents in before now.
First it is not yet understood what is actually needed and what is not
important until things actually get built.  At that time the industry will
begin to consolidate around  the really valuable "Optional to implement".
Like was mentioned on this thread, it is the really  vocal minority that
will yell until an option is included, and the silent majority will go
about building what makes since for their customers.  Further, the silent
majority will remain just that, silent and are not much help when we try to
cut back on options.

An example of this is all the people that complained about the SW
implementations that had to add extra code and path length to support the
Markers.  Now the important thing is that, all the real SW implementations
that are currently being done are being given away for Free by the various
Storage and Routers vendors, or as part of a free option from an OS.  I
know of no one that plans on selling an iSCSI SW iSCSI implementation.
Therefore, in the real world, the folks that were complaining, were not
going to implement a SW iSCSI version, anyway.  They were just debating for
effect.  And this has been causing some disarray in the HW iSCSI HBAs (Host
Buss Adapters) arena.  There is probably no way to stop this, and if we
attempt to do that, by defining profiles, in the IETF, it will just cause
the debates to start all over again.  Many of us, I am sure, were glad to
have moved on to other topics when a contentious item was made an option,
since we knew we were not going to implement it, and doubted if in the real
world anyone would.  Some of us felt that either the option would not be
implemented by two or more vendors, or if it was, the market place would
make it go away.  The IETF process will address the issue of less then two
implementations, and one of the purposes of the SNIA IP Storage Forum and
Technical Workgroup is to help define the marketing needs and the profiles
that meet these needs.

Now let me explain about the marketing needs and their related profiles.
As an example there maybe an important market that addresses, iSCSI needs
within a Business Secure Campus.  There maybe lots of vendors that have
products that fit that market, but several vendors may have decided to have
a low price point, and not include optional items that would be especially
valuable in the Wide Area Market, but not needed in a Business Secure
Campus (e.g. extra RAM).  This set of vendors might feel that they could
meet their revenue goals by focusing only on Business Secure Campuses.
Therefore, they might want to define a set of profiles that would permit
them to meet their targeted market.

I do think we need to clearly define the "Must implement" and that these
must be the Minimum Profile.  However, it is not clear to me that we need
to have profiles defined by the IETF.  If profiles are needed anywhere they
should be produced as part of the SNIA IP Storage (iSCSI) Technical
WorkGroup's response to what the SNIA IP Storage Forum Defines to be a
targeted marketing need.  (Those, profiles can then be used in conformance
test at UNH.)  I do not think that profiles should be part of the IETF
work.

I agree that we should not have more options than will be actually built,
however, the IETF process probably limits this to a great extent.  Also, I
would hate to see us get into the rancorous debates that will follow when
we try to limit options, I do not think we added them wily nilly and that
each one, at the time, seemed to be of value to some set of vocal people.
So I suggest that we be very careful when we try to trim the Options, and
then only those that we know do not make since to any potential profile.

.
.
.
John L. Hufferd
Senior Technical Staff Member (STSM)
IBM/SSG San Jose Ca
(408) 256-0403, Tie: 276-0403,  eFax: (408) 904-4688
Internet address: [email-masked]

---

From: "Borison, Frankie" <[email-masked]>
Date: Sat, 23 Jun 2001 14:21:56 -0700

How do I get off this mailing list???

-----Original Message-----
From: Scott Bradner [mailto:[email-masked]]
Sent: Friday, June 22, 2001 4:13 PM
To: [email-masked]
Subject: Re: profiles - a way to simplify iSCSI

Scott

-----

---

From: [email-masked]
Date: Wed, 27 Jun 2001 16:25:06 +0300

Scott,

I assumed (rightfully) that we are talking about "different profiles".
What I had in mind was more of a "set of levels".

Level 0 - only mandatory feature.
Level 1 = Level 0 + all the optional

A profile 0 device will talk to any device as if is a profile 0 (not using
any optionals).
A profile 1 can talk using profile 1 features only to a profile 1 but it
can talk also to a profile 0
by avoiding all the optionals.

The gain is in simplifying testing and predicting feature interaction (at
the cost of flexibility).

Regards,
Julo

Scott Bradner <[email-masked]> on 27-06-2001 13:51:44

Please respond to Scott Bradner <[email-masked]>

> Could you shed some light about the reasons behind this.

its very straight forward - if you have profiles then it may become
common that one ips devide will not be able to interopoerate with anothe
ips device because they implemented different profiles - see X.400
for a worked example

Scott

---

From: [email-masked]
Date: Wed, 27 Jun 2001 04:56:58 +0300

Scott,

Could you shed some light about the reasons behind this.
Are we talking about the same thing or are we just using a word with two
different meanings?

Julo

________________

                [Date Prev][Date Next][Thread Prev][Thread Next][Date    
                Index][Thread Index]                                     
                Re: profiles - a way to simplify iSCSI                   
 SORT BY:                                                                
                     To: [email-masked]                                 
                     Subject: Re: profiles - a way to simplify iSCSI     
 LIST                From: Scott Bradner <[email-masked]>               
 ORDER               Date: Fri, 22 Jun 2001 19:13:25 -0400 (EDT)         
 THREAD              Sender: [email-masked]                       
 AUTHOR                                                                  
 SUBJECT                                                                 
                                                                         
 SEARCH         there seems to be a misunderstanding somewhere - I was   
                trying to say                                            
                nicely that a IPS protocol that has to have profiles     
                would not pass                                           
                the IESG but I guess I was too nice -                    
 IPS HOME                                                                
                I expect that teh IESG would return any such proposal to 
                the WG for                                               
                rework if such a proposal makes it to the IESG           
                                                                         
                i.e the discussion in the followintg posting is not a    
                productive path                                          
                to be following                                          

                Scott                                                    

                -----                                                    
                From [email-masked] Fri Jun 22 17:05:13 2001      
                X-Authentication-Warning: ece.cmu.edu: majordom set      
                sender to [email-masked] using -f                 
                Date: Fri, 22 Jun 2001 15:59:06 -0500                    
                From: Mark Bakke <[email-masked]>                      
                X-Mailer: Mozilla 4.72 [en] (X11; U; Linux               
                2.2.16-3.uid32 i686)                                     
                X-Accept-Language: en, de                                
                MIME-Version: 1.0                                        
                To: [email-masked]                                      
                Subject: Re: profiles - a way to simplify iSCSI          
                References: <                                            
                [email-masked] 
                > <[email-masked]>                          
                Content-Type: text/plain; charset=us-ascii               
                Content-Transfer-Encoding: 7bit                          
                Sender: [email-masked]                            
                Precedence: bulk                                         
                                                                         
                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.pd 
                f                                                        
                >                                                        
                > 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                                          
                > [email-masked]                                       
                > 763.398.1054                                           
                                                                         
                --                                                       
                Mark A. Bakke                                            
                Cisco Systems                                            
                [email-masked]                                         
                763.398.1054                                             

                     Prev by Date: Re: profiles - a way to simplify      
                     iSCSI                                               
                     Next by Date: Re: profiles - a way to simplify      
                     iSCSI                                               
                     Prev by thread: Re: profiles - a way to simplify    
                     iSCSI                                               
                     Next by thread: Re: profiles - a way to simplify    
                     iSCSI                                               
                     Index(es):                                          
                          Date                                           
                          Thread                                         

           Home                                                          

           Last updated: Sat Jun 23 14:16:50 2001                        
           5155 messages in chronological order