Re: [storm] iSCSI feature removal: SLP ?

"David Harrington" <ietfdbh@comcast.net> Mon, 05 July 2010 18:03 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 C69B628C0D7 for <storm@core3.amsl.com>; Mon, 5 Jul 2010 11:03:32 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 0.62
X-Spam-Level:
X-Spam-Status: No, score=0.62 tagged_above=-999 required=5 tests=[BAYES_50=0.001, RCVD_IN_SORBS_WEB=0.619]
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 B-n0Y-UR41M4 for <storm@core3.amsl.com>; Mon, 5 Jul 2010 11:03:31 -0700 (PDT)
Received: from qmta15.emeryville.ca.mail.comcast.net (qmta15.emeryville.ca.mail.comcast.net [76.96.27.228]) by core3.amsl.com (Postfix) with ESMTP id C16A028C0CF for <storm@ietf.org>; Mon, 5 Jul 2010 11:03:31 -0700 (PDT)
Received: from omta18.emeryville.ca.mail.comcast.net ([76.96.30.74]) by qmta15.emeryville.ca.mail.comcast.net with comcast id eHqb1e0041bwxycAFJ3Zfd; Mon, 05 Jul 2010 18:03:33 +0000
Received: from 23FX1C1 ([65.124.181.3]) by omta18.emeryville.ca.mail.comcast.net with comcast id eJ361e00104o4rD8eJ3Bhb; Mon, 05 Jul 2010 18:03:28 +0000
From: "David Harrington" <ietfdbh@comcast.net>
To: "'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>
Date: Mon, 5 Jul 2010 14:03:10 -0400
Message-ID: <5DD99D3E24204AC3841DF1CB3636E07E@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/NQgTpQkGTuoIDXxg8CAJSPrGA
In-Reply-To: <654733.53196.qm@smtp112.biz.mail.mud.yahoo.com>
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: Mon, 05 Jul 2010 18:03:32 -0000

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
>