Subject: Re: [storm] iSCSI feature removal: SLP ?

From: "David Harrington" <[email-masked]>
Date: Mon, 5 Jul 2010 14:03:10 -0400

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: [email-masked] [mailto:[email-masked]] 
> On Behalf Of Mark S. Edwards
> Sent: Wednesday, June 23, 2010 6:23 PM
> To: [email-masked]
> 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, [email-masked] 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: [email-masked] [mailto:[email-masked]] On 
> > > Behalf
> >Of Mark S. Edwards
> > > Sent: Monday, June 07, 2010 7:00 AM
> > > To: [email-masked]
> > > 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, [email-masked] 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
> > > >[email-masked]        Mobile: +1 (978) 394-7754
> > > >----------------------------------------------------
> > >
> > > _______________________________________________
> > > storm mailing list
> > > [email-masked]
> > > https://www.ietf.org/mailman/listinfo/storm
> 
> _______________________________________________
> storm mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/storm
>

---

From: "Mallikarjun Chadalapaka" <[email-masked]>
Date: Tue, 6 Jul 2010 09:26:38 -0700

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

> From: [email-masked] [mailto:[email-masked]] On Behalf Of
> David Harrington
> Sent: Monday, July 05, 2010 11:03 AM
> To: 'Mark S. Edwards'; [email-masked]

---

From: "David Harrington" <[email-masked]>
Date: Tue, 6 Jul 2010 15:06:07 -0400

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

> From: Mallikarjun Chadalapaka [mailto:[email-masked]] 
> Sent: Tuesday, July 06, 2010 12:27 PM
> To: 'David Harrington'; 'Mark S. Edwards'; [email-masked]
> Subject: RE: [storm] iSCSI feature removal: SLP ?
> 
> Hi David and all,
> 
> 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.
> 
> > From: [email-masked] 
> [mailto:[email-masked]] On Behalf 
> > Of David Harrington
> > > Behalf Of Mark S. Edwards
were 
> > > any SLP diehards out there waiting to be offended.
> > >
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.

---

From: "Mallikarjun Chadalapaka" <[email-masked]>
Date: Tue, 6 Jul 2010 16:25:00 -0700

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

> From: David Harrington [mailto:[email-masked]]
> Sent: Tuesday, July 06, 2010 12:06 PM
> To: 'Mallikarjun Chadalapaka'; 'Mark S. Edwards'; [email-masked]

---

From: "David Harrington" <[email-masked]>
Date: Tue, 6 Jul 2010 19:48:52 -0400

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

> Sent: Tuesday, July 06, 2010 7:25 PM
> 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
> 

> > > 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.
> > >
> [mailto:[email-masked]] On 
> > > > > > > strongly that SLP deserves some mention, then by all
means
> > do
> > > > > > > there a case for turning the "should' in the 
> above sentence
> > to
> > > > > >"SHOULD" ?
> > > > > >
> > > > > >         SLP has not been widely implemented or deployed
for
> > use
> > > > > > > protocol (RFC 4171) and the original argument for SLP
was
> > > > > > > strongly that SLP deserves some mention, then by all
means
> > do
> > > > > > > there a case for turning the "should' in the 
> above sentence
> > to
> > > > > >"SHOULD" ?
> > > > > > >
> > > > > > > Mark.
> > > > > > >
> > > > > > >
> > > > > > > > > Regarding the feature removal discussion, can 
> I add SLP
> > to
> > > > the
> > > > > >list ?
> > > > > > > > >
> > > > > > > > > The RFC 3721 states
> > > > > > > > >
> > > > > > > > > "iSCSI equipment that

---

From: "Mallikarjun Chadalapaka" <[email-masked]>
Date: Tue, 6 Jul 2010 16:58:45 -0700

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

> Sent: Tuesday, July 06, 2010 4:49 PM

---

From: "Mark S. Edwards" <[email-masked]>
Date: Wed, 07 Jul 2010 01:05:28 +0100

David,

Thanks for your input regarding word smithing.

To answer your question on the subject of why iSNS is not a MUST 
implement, iSCSI already has a MUST implement discovery mechanism 
called 'SendTargets' as an explicit part of the iSCSI protocol.

iSNS, SLP and anything else were listed as additional mechanisms that 
could be implemented if the vendor wished to expand their 
implementation's discovery capabilities.  The original RFC wording 
heavily implied that SLP was the best/first mechanism to implement in 
such a case.  The argument way back then was that there was an 
existing RFC for SLP and iSNS was 'yet another discovery mechanism' 
being dreamed up by the WG.

Time has moved on, iSNS became an RFC and running code in the real 
world shunned SLP in favour of iSNS.  This discussion has been about 
stopping any confusion that new implementors may have in the future 
about which additional discovery mechanisms to use.  We have a 
mandatory discovery mechanism in iSCSI, this is all about the text 
for recommending what additional mechanism(s) to use.

Hope that answers your questions.

Mark.

---

From: "David Harrington" <[email-masked]>
Date: Tue, 6 Jul 2010 20:32:40 -0400

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

thanks,
dbh 

> Sent: Tuesday, July 06, 2010 7:59 PM
> 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
> 
> 
> 
> 
> > > Here is the text that I have crafted based on all the 
> inputs so far.  
> > > Does that look reasonable?
> > >
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 
> > > > I made a suggested change as a contributor because I didn't
want

> > > > This will also apply to other WG documents, especially those
on
> > > > > > > >points (IMHO) but I don't think we need a
recommendation
> > > > > that SLP
> > > > > > > > > > >        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,
> > > > > > > > > > > The result is that today I doubt you could find
a
> > > > > target or
> > > > > > > > > > > For anybody that does still implement SLP we
could
> > > > change