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
> 