Re: [storm] iSCSI feature removal: SLP ?

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

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:[e-mail]]
> Sent: Tuesday, July 06, 2010 12:06 PM
> To: 'Mallikarjun Chadalapaka'; 'Mark S. Edwards'; [e-mail]
> 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:[e-mail]]
> > Sent: Tuesday, July 06, 2010 12:27 PM
> > To: 'David Harrington'; 'Mark S. Edwards'; [e-mail]
> > 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: [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
> >