Re: [storm] iSCSI feature removal: SLP ?

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

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: [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
> > >
> 
>