Re: [storm] iSCSI feature removal: SLP ?

"David Harrington" <ietfdbh@comcast.net> Wed, 07 July 2010 00:32 UTC

Return-Path: <ietfdbh@comcast.net>
X-Original-To: storm@core3.amsl.com
Delivered-To: storm@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E87783A67CF for <storm@core3.amsl.com>; Tue, 6 Jul 2010 17:32:44 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.699
X-Spam-Level:
X-Spam-Status: No, score=-1.699 tagged_above=-999 required=5 tests=[AWL=0.900, BAYES_00=-2.599]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NLrYvaEUquVt for <storm@core3.amsl.com>; Tue, 6 Jul 2010 17:32:39 -0700 (PDT)
Received: from qmta13.westchester.pa.mail.comcast.net (qmta13.westchester.pa.mail.comcast.net [76.96.59.243]) by core3.amsl.com (Postfix) with ESMTP id BAF423A6781 for <storm@ietf.org>; Tue, 6 Jul 2010 17:32:36 -0700 (PDT)
Received: from omta18.westchester.pa.mail.comcast.net ([76.96.62.90]) by qmta13.westchester.pa.mail.comcast.net with comcast id enz91e00B1wpRvQ5DoYg9q; Wed, 07 Jul 2010 00:32:40 +0000
Received: from 23FX1C1 ([67.189.235.106]) by omta18.westchester.pa.mail.comcast.net with comcast id eoYf1e0072JQnJT3eoYfPj; Wed, 07 Jul 2010 00:32:40 +0000
From: "David Harrington" <ietfdbh@comcast.net>
To: "'Mallikarjun Chadalapaka'" <cbm@chadalapaka.com>, "'Mark S. Edwards'" <marke@muttsnuts.com>, <storm@ietf.org>
References: <C2D311A6F086424F99E385949ECFEBCB02162B4B@CORPUSMX80B.corp.emc.com><690958.35528.qm@smtp111.biz.mail.re2.yahoo.com><C2D311A6F086424F99E385949ECFEBCB02A28E1D@CORPUSMX80B.corp.emc.com><473934.13068.qm@smtp114.biz.mail.mud.yahoo.com><C2D311A6F086424F99E385949ECFEBCB02ED59ED@CORPUSMX80B.corp.emc.com> <654733.53196.qm@smtp112.biz.mail.mud.yahoo.com> <5DD99D3E24204AC3841DF1CB3636E07E@23FX1C1> <SNT131-ds181D2EAC49B1B0CB3C577A0B20@phx.gbl> <753F1F25CD664126B1E5F4FDA475E0F4@23FX1C1> <SNT131-ds6A96521A02AAB7C221279A0B20@phx.gbl> <52C10943EC2A469293EF93CF6BEDCB1C@23FX1C1> <SNT131-ds19B6C3D8310BBE3809D34AA0B20@phx.gbl>
Date: Tue, 6 Jul 2010 20:32:40 -0400
Message-ID: <A7D7E33289134245B2D86BCE88A38208@23FX1C1>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
X-Mailer: Microsoft Office Outlook 11
Thread-Index: AcsTIrSaYI/NQgTpQkGTuoIDXxg8CAJSPrGAAC68c9AABGooMAAKPweQAADWz+AAAHRdQAABUWoQ
In-Reply-To: <SNT131-ds19B6C3D8310BBE3809D34AA0B20@phx.gbl>
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.5931
Subject: Re: [storm] iSCSI feature removal: SLP ?
X-BeenThere: storm@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: Storage Maintenance WG <storm.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/storm>, <mailto:storm-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/storm>
List-Post: <mailto:storm@ietf.org>
List-Help: <mailto:storm-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/storm>, <mailto:storm-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 07 Jul 2010 00:32:45 -0000

Ah. That, and the answer from Mark, answer my question very well.

thanks,
dbh 

> -----Original Message-----
> From: Mallikarjun Chadalapaka [mailto:cbm@chadalapaka.com] 
> Sent: Tuesday, July 06, 2010 7:59 PM
> To: 'David Harrington'; 'Mark S. Edwards'; storm@ietf.org
> Subject: RE: [storm] iSCSI feature removal: SLP ?
> 
> Hi David,
> 
> iSCSI protocol has a built-in discovery protocol called 
> "SendTargets" - based on text key exchanges.  All iSCSI 
> targets MUST support the Discovery sessions to transact the 
> SendTargets protocol on, as well as the SendTargets operation 
> itself.  So we have a required interoperability baseline for 
> discovery.  The debate on the list has been around what 
> mechanisms if any SHOULD be additionally required - and iSNS 
> fits the "SHOULD" bill.  So I believe we're covered overall.
> 
> Thanks.
> 
> Mallikarjun
> 
> 
> 
> 
> > -----Original Message-----
> > From: David Harrington [mailto:ietfdbh@comcast.net]
> > Sent: Tuesday, July 06, 2010 4:49 PM
> > To: 'Mallikarjun Chadalapaka'; 'Mark S. Edwards'; storm@ietf.org
> > Subject: RE: [storm] iSCSI feature removal: SLP ?
> > 
> > Hi,
> > 
> > yes. you now understand what I was looking for, and the new text
is 
> > much better.
> > 
> > I expect we will be asked why iSNS is not MUST implement, 
> to ensure a 
> > minimum level of interoperability, since that seems to have 
> achieved 
> > implementer rough consensus. I support having one mchanism as 
> > MUST-implement to make interoperability more likely. Then, 
> if desired, 
> > implementers can support additional mechanisms.
> > 
> > Other than a desire to not hurt the feelings of a few die-hard 
> > supporters of other mechanisms, why is iSNS not a MUST 
> implement, to 
> > ensure a minimum level of interoperability, since that 
> seems to have 
> > achieved implementer rough consensus. I support having one 
> mechanism 
> > as MUST-implement to ensure interoperability. Then, if desired, 
> > implementers can support additional mechanisms.
> > 
> > dbh
> > 
> > > -----Original Message-----
> > > From: Mallikarjun Chadalapaka [mailto:cbm@chadalapaka.com]
> > > Sent: Tuesday, July 06, 2010 7:25 PM
> > > To: 'David Harrington'; 'Mark S. Edwards'; storm@ietf.org
> > > Subject: RE: [storm] iSCSI feature removal: SLP ?
> > >
> > > Hi David,
> > >
> > > Thanks for the detailed note, I now understand your perspective.
> > >
> > > Here is the text that I have crafted based on all the 
> inputs so far.  
> > > Does that look reasonable?
> > >
> > > iSCSI equipment that needs discovery functions beyond
SendTargets 
> > > SHOULD implement iSNS (see [RFC4171]) for extended discovery 
> > > management capabilities and interoperability.  Although
[RFC3721] 
> > > implies an SLP implementation requirement, SLP has not 
> been widely 
> > > implemented or deployed for use with iSCSI in practice.
> > > iSCSI implementations therefore SHOULD NOT rely on SLP-based 
> > > discovery interoperability.
> > >
> > > Thanks.
> > >
> > > Mallikarjun
> > >
> > > > -----Original Message-----
> > > > From: David Harrington [mailto:ietfdbh@comcast.net]
> > > > Sent: Tuesday, July 06, 2010 12:06 PM
> > > > To: 'Mallikarjun Chadalapaka'; 'Mark S. Edwards';
storm@ietf.org
> > > > Subject: RE: [storm] iSCSI feature removal: SLP ?
> > > >
> > > > Hi,
> > > >
> > > > I made a suggested change as a contributor because I didn't
want
> > to
> > > > come down with the force of an AD Evaluation. That will come
> > later.
> > > > But there are some things I know will not make it through IESG

> > > > Evaluation, and the IESG is actually working to document
> > > some of the
> > > > things for which we commonly reject a document. The use of
> > > non-RFC2119
> > > > language to specify compliance is a common cause for
DISCUSSes.
> > > >
> > > > The storm WG is something of a cross-SDO effort, and that
> > > might lead
> > > > to some lack of understanding of IETF process, and IESG common

> > > > complaints. Let me be sure you understand my objection.
> > > >
> > > > The IETF does not support "not almost must" compliance
language.
> > > > We want our standards to be clear and unambiguous.
> > > > Therefore, we have RFC2119 compliance keywords, such as
> > > SHOULD NOT and
> > > > NOT RECOMMENDED.
> > > > What you are proposing sounds to me like a SHOULD NOT, or a
NOT
> > > > RECOMMENDED:
> > > >
> > > > 4. SHOULD NOT   This phrase, or the phrase "NOT
> > > RECOMMENDED" mean that
> > > >    there may exist valid reasons in particular
> > > circumstances when the
> > > >    particular behavior is acceptable or even useful, 
> but the full
> > > >    implications should be understood and the case carefully
> > weighed
> > > >    before implementing any behavior described with this label.
> > > >
> > > > The full implications appear to be that nobody seems to
> > > implement SLP,
> > > > and therefore the SLP part of your implementation will not 
> > > > interoperate with many other existing implementations. 
> Therefore, 
> > > > implementing SLP appears to be NOT RECOMMENDED. I am not
> > > telling you
> > > > that you must say it is NOT RECOMMENDED; I am telling 
> you that you
> > 
> > > > should clarify the compliance requirement that represents
> > > WG consensus
> > > > using RFC2119 language, so the requirement is clear and
> > unambiguous.
> > > >
> > > > As Responsible AD for the storm WG, I need to champion your
> > > documents
> > > > during IESG Evaluation. If you submit a document to me that
> > > says, "for
> > > > compliance, SLP is no longer almost must", then I will almost 
> > > > certainly tell you to revise it before I will champion the
> > document
> > > > for you. The WG advice SHOULD be written using RFC2119 
> language, 
> > > > because if you don't and I send the document for IESG
> > > Evaluation, we
> > > > will all waste lots of time debating with the other IESG
> > > members when
> > > > they raise DISCUSSes questioning why we are not using
> > > RFC2119 keywords
> > > > to describe the compliance rules.
> > > >
> > > > Does that explain my objection to non-RFC2119 language better?
> > > > This will also apply to other WG documents, especially those
on
> > the
> > > > standards track.
> > > >
> > > > dbh
> > > >
> > > >
> > > > > -----Original Message-----
> > > > > From: Mallikarjun Chadalapaka [mailto:cbm@chadalapaka.com]
> > > > > Sent: Tuesday, July 06, 2010 12:27 PM
> > > > > To: 'David Harrington'; 'Mark S. Edwards'; storm@ietf.org
> > > > > Subject: RE: [storm] iSCSI feature removal: SLP ?
> > > > >
> > > > > Hi David and all,
> > > > >
> > > > > With deployment experience, we now know that the original
> > "almost
> > > > > must"
> > > > > recommendation is not valid (ignoring the fact that it
> > > was contained
> > > > > in an Informational RFC).
> > > > >
> > > > > But OTOH, we do not have to say "SHOULD NOT" implement
> > > SLP either,
> > > > > which IMHO is overly constraining and thus unwarranted.
> > > > >
> > > > > At this point, I plan to make it clear in the 
> consolidated draft
> > 
> > > > > that SLP is not an "almost must" requirement, along 
> the lines of
> > 
> > > > > what DavidB/Mark had proposed.
> > > > >
> > > > > Please let me know if that is not agreeable to anyone.
> > > > >
> > > > > Thanks.
> > > > >
> > > > > Mallikarjun
> > > > >
> > > > >
> > > > >
> > > > > > -----Original Message-----
> > > > > > From: storm-bounces@ietf.org
> > > > > [mailto:storm-bounces@ietf.org] On Behalf
> > > > > > Of David Harrington
> > > > > > Sent: Monday, July 05, 2010 11:03 AM
> > > > > > To: 'Mark S. Edwards'; storm@ietf.org
> > > > > > Subject: Re: [storm] iSCSI feature removal: SLP ?
> > > > > >
> > > > > > Hi,
> > > > > >
> > > > > > I think "recommendation is no longer valid" is
> > > equivalent to "NOT
> > > > > > RECOMMENDED" which is equivalent to "SHOULD NOT".
> > > > > >
> > > > > > So I recommend "SHOULD NOT" (or if you prefer,
> > > rewording to "NOT
> > > > > > RECOMMENDED").
> > > > > >
> > > > > > dbh (as contributor)
> > > > > >
> > > > > > > -----Original Message-----
> > > > > > > From: storm-bounces@ietf.org
> > > [mailto:storm-bounces@ietf.org] On
> > > > > > > Behalf Of Mark S. Edwards
> > > > > > > Sent: Wednesday, June 23, 2010 6:23 PM
> > > > > > > To: storm@ietf.org
> > > > > > > Subject: Re: [storm] iSCSI feature removal: SLP ?
> > > > > > >
> > > > > > > Looks ok to me.  I was trying to be diplomatic in 
> case there
> > > > were
> > > > > > > any SLP diehards out there waiting to be offended.
> > > > > > >
> > > > > > > But since none have appeared over the parapet the hammer
> > > > approach
> > > > > > > that effectively deprecates SLP as an
> > > interoperability mechanism
> > > >
> > > > > > > suits me.
> > > > > > >
> > > > > > > I agree that we should not specifically prohibit it's
> > > > > use, after all
> > > > > > > people are free to create and use any discovery
mechanism
> > > > > they wish
> > > > > > > for their own purposes.  Could be SLP, could be LDAP
> > > or "Fred's
> > > > > > > Bird-Brained Resource Locator", none should be
explicitly
> > > > barred.
> > > > > > >
> > > > > > > Mark.
> > > > > > >
> > > > > > >
> > > > > > > At 21:25 23/06/2010, david.black@emc.com wrote:
> > > > > > > >Mark,
> > > > > > > >
> > > > > > > > > So if pushed I'd write something like:
> > > > > > > > >
> > > > > > > > > "iSCSI equipment that need discovery functions
beyond
> > > > > > SendTargets
> > > > > > > > > should implement iSNS for extended discovery 
> management
> > > > > > > capabilities
> > > > > > > > > and maximum interoperability."
> > > > > > > > >
> > > > > > > > > Since any unit that implements SLP or even LDAP as a
> > > > > discovery
> > > > > > > > > mechanism is not going to interoperate with 
> the majority
> > > > > > > of systems,
> > > > > > > > > I'd hesitate to even mention them.  However, if
> > > anyone feels
> > > >
> > > > > > > > > strongly that SLP deserves some mention, then by all
> > means
> > > > do
> > > > > > so,
> > > > > > > > > just please don't assert it too strongly.
> > > > > > > > >
> > > > > > > > > One final point.  Given that iSNS has won the 
> consensus
> > > > > > > argument, is
> > > > > > > > > there a case for turning the "should' in the
> > > above sentence
> > > > to
> > > > > > > >"SHOULD" ?
> > > > > > > >
> > > > > > > >Yes, I would use "SHOULD" plus I would add text to say:
> > > > > > > >
> > > > > > > >         SLP has not been widely implemented or
deployed
> > for
> > > > use
> > > > > > with
> > > > > > > >         iSCSI, therefore RFC 3121's recommendation
> > > that SLP be
> > > > > > > >         implemented is no longer valid.
> > > > > > > >
> > > > > > > >This is one of those situations in which subtlety
> > > does not win
> > > > > > style
> > > > > > > >points (IMHO) but I don't think we need a
recommendation
> > > > > that SLP
> > > > > > > >"SHOULD NOT" be implemented.  In addition (as noted
> > > below), RFC
> > > > > > 3721
> > > > > > > >would need to be added to the list of RFCs that are
> > > > > updated by the
> > > > > > > >combined iSCSI Internet-Draft.
> > > > > > > >
> > > > > > > >Any objections?
> > > > > > > >
> > > > > > > >Thanks,
> > > > > > > >--David
> > > > > > > >
> > > > > > > >
> > > > > > > > > -----Original Message-----
> > > > > > > > > From: storm-bounces@ietf.org
> > > > > [mailto:storm-bounces@ietf.org] On
> > > > > > > > > Behalf
> > > > > > > >Of Mark S. Edwards
> > > > > > > > > Sent: Monday, June 07, 2010 7:00 AM
> > > > > > > > > To: storm@ietf.org
> > > > > > > > > Subject: Re: [storm] iSCSI feature removal: SLP ?
> > > > > > > > >
> > > > > > > > > Sorry for the delay.
> > > > > > > > >
> > > > > > > > > As you say, RFC3721 was more about guidance and was
> > > > > > > written before
> > > > > > > > > there was any deployment experience.  At 
> least the text
> > > > > > > says 'should'
> > > > > > > > > rather than 'SHOULD'.  It might be nicer to all
> > > round if it
> > > > > > could
> > > > > > > > > just be removed and no extended discovery mechanism
be
> > > > > > mentioned,
> > > > > > > > > but we have realities to consider such as an 
> iSCSI array
> > > > > > > won't get
> > > > > > > > > Microsoft certification unless it supports at least
> > > > > basic iSNS -
> > > > > >
> > > > > > > > > running code and consensus.
> > > > > > > > >
> > > > > > > > > The one good thing we have now is that iSNS is
> > > indeed now an
> > > > > > IETF
> > > > > > > > > protocol (RFC 4171) and the original argument for
SLP
> > was
> > > > that
> > > > > > it
> > > > > > > > > was an existing RFC.  So the argument for using SLP
> > ahead
> > > > > > > of iSNS is
> > > > > > > > > no longer relevant.
> > > > > > > > >
> > > > > > > > > So if pushed I'd write something like:
> > > > > > > > >
> > > > > > > > > "iSCSI equipment that need discovery functions
beyond
> > > > > > SendTargets
> > > > > > > > > should implement iSNS for extended discovery 
> management
> > > > > > > capabilities
> > > > > > > > > and maximum interoperability."
> > > > > > > > >
> > > > > > > > > Since any unit that implements SLP or even LDAP as a
> > > > > discovery
> > > > > > > > > mechanism is not going to interoperate with 
> the majority
> > > > > > > of systems,
> > > > > > > > > I'd hesitate to even mention them.  However, if
> > > anyone feels
> > > >
> > > > > > > > > strongly that SLP deserves some mention, then by all
> > means
> > > > do
> > > > > > so,
> > > > > > > > > just please don't assert it too strongly.
> > > > > > > > >
> > > > > > > > > One final point.  Given that iSNS has won the 
> consensus
> > > > > > > argument, is
> > > > > > > > > there a case for turning the "should' in the
> > > above sentence
> > > > to
> > > > > > > >"SHOULD" ?
> > > > > > > > >
> > > > > > > > > Mark.
> > > > > > > > >
> > > > > > > > >
> > > > > > > > > At 23:54 21/05/2010, Black_David@emc.com wrote:
> > > > > > > > > > > Regarding the feature removal discussion, can
> > > I add SLP
> > > > to
> > > > > > the
> > > > > > > >list ?
> > > > > > > > > > >
> > > > > > > > > > > The RFC 3721 states
> > > > > > > > > > >
> > > > > > > > > > > "iSCSI equipment that
> > > > > > > > > > >        need discovery functions beyond
SendTargets
> > > > > > > should at least
> > > > > > > > > > >        implement SLP, and then consider iSNS
when
> > > > extended
> > > > > > > >discovery
> > > > > > > > > > >        management capabilities are 
> required such as
> > in
> > > > > > larger
> > > > > > > >storage
> > > > > > > > > > >        networks.  It should be noted that 
> since iSNS
> > > > will
> > > > > > > > > > > support
> > > > > > > >SLP,
> > > > > > > > > > >        iSNS can be used to help manage 
> the discovery
> > > > > > > information
> > > > > > > >returned
> > > > > > > > > > >        by SLP."
> > > > > > > > > > >
> > > > > > > > > > > The implication is that targets and initiators
> > should
> > > > > > > expect to
> > > > > > > >find
> > > > > > > > > > > support for SLP before considering iSNS.
> > > > > > > > > > >
> > > > > > > > > > > I remember our first iSCSI appliance and we
spent
> > > > > > > ages trying to
> > > > > > > >get
> > > > > > > > > > > SLP working because it the above wording
> > > > > effectively made it
> > > > > >
> > > > > > > > > > > mandatory.  SLP turned out to be a complete
> > > bust and was
> > > > > > > >effectively
> > > > > > > > > > > killed off when Microsoft refused to support
> > > it in their
> > > >
> > > > > > > > > > > initiator and in their target logo tests.
> > > > > > > > > > >
> > > > > > > > > > > The result is that today I doubt you could find
a
> > > > > target or
> > > > > > > >initiator
> > > > > > > > > > > out there supporting SLP.
> > > > > > > > > > >
> > > > > > > > > > > For anybody that does still implement SLP we
could
> > > > change
> > > > > > the
> > > > > > > >wording
> > > > > > > > > > > for SLP a little to remove the implied 
> hierarchy, or
> > > > > > > just admit
> > > > > > > >that
> > > > > > > > > > > running code has created IETF consensus.
> > > > > > > > > >
> > > > > > > > > >This is interesting.  RFC 3720 (main iSCSI spec)
> > > > > never mentions
> > > > > >
> > > > > > > > > >SLP.  RFC 3721 is not a Standards Track RFC, but
> > > > > that's not a
> > > > > > > > > >reason not to update it (if people will excuse the
> > > > > > > double negative).
> > > > > > > > > >
> > > > > > > > > >So, Mark, could you send an email to the list with
> > > > > > > proposed text on
> > > > > > > > > >SLP that you'd like to see in the new consolidated
> > iSCSI
> > > > > > > draft (no
> > > > > > > > > >more than a few sentences, please)?  If that text
(as
> > > > > > > revised) is
> > > > > > > > > >acceptable to the WG, the result would go 
> into the new
> > > > > > > consolidated
> > > > > > > > > >iSCSI draft, and RFC 3721 would be added to 
> the list of
> > > > > > > RFCs that
> > > > > > > > > >are being updated by that draft.
> > > > > > > > > >
> > > > > > > > > >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
> > > > > > >
> > > > > > > _______________________________________________
> > > > > > > storm mailing list
> > > > > > > storm@ietf.org
> > > > > > > https://www.ietf.org/mailman/listinfo/storm
> > > > > > >
> > > > > >
> > > > > > _______________________________________________
> > > > > > storm mailing list
> > > > > > storm@ietf.org
> > > > > > https://www.ietf.org/mailman/listinfo/storm
> > > > >
> > >
> > >
> 
>