Re: [storm] iSCSI feature removal: SLP ?

["David Harrington" <[e-mail]>]

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

thanks,
dbh 

> -----Original Message-----
> From: Mallikarjun Chadalapaka [mailto:[e-mail]] 
> Sent: Tuesday, July 06, 2010 7:59 PM
> To: 'David Harrington'; 'Mark S. Edwards'; [e-mail]
> 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:[e-mail]]
> > Sent: Tuesday, July 06, 2010 4:49 PM
> > To: 'Mallikarjun Chadalapaka'; 'Mark S. Edwards'; [e-mail]
> > 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:[e-mail]]
> > > Sent: Tuesday, July 06, 2010 7:25 PM
> > > To: 'David Harrington'; 'Mark S. Edwards'; [e-mail]
> > > 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:[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: +1 (508)
293-7786
> > > > > > > > > >[e-mail]        Mobile: +1 (978)
394-7754
> > > > > > > > >
>----------------------------------------------------
> > > > > > > > >
> > > > > > > > > _______________________________________________
> > > > > > > > > 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
> > > > >
> > >
> > >
> 
>