Re: [storm] iSCSI feature removal: SLP ?

["Mallikarjun Chadalapaka" <[e-mail]>]

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: [e-mail] [mailto:[e-mail]] On Behalf Of
> David Harrington
> Sent: Monday, July 05, 2010 11:03 AM
> To: 'Mark S. Edwards'; [e-mail]
> 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: [e-mail] [mailto:[e-mail]]
> > On Behalf Of Mark S. Edwards
> > Sent: Wednesday, June 23, 2010 6:23 PM
> > To: [e-mail]
> > 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, [e-mail] 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: [e-mail] [mailto:[e-mail]] On
> > > > Behalf
> > >Of Mark S. Edwards
> > > > Sent: Monday, June 07, 2010 7:00 AM
> > > > To: [e-mail]
> > > > 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, [e-mail] 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
> > > > >[phone]             FAX: [phone]
> > > > >[e-mail]        Mobile: [phone]
> > > > >----------------------------------------------------
> > > >
> > > > _______________________________________________
> > > > storm mailing list
> > > > [e-mail]
> > > > https://www.ietf.org/mailman/listinfo/storm
> >
> > _______________________________________________
> > storm mailing list
> > [e-mail]
> > https://www.ietf.org/mailman/listinfo/storm
> >
> 
> _______________________________________________
> storm mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/storm