Subject: Re: [AAA-DOCTORS] [OPS-DIR] FW: Internal WG Review: STORage Maintenance (storm)

From: "David Harrington" <[email-masked]>
Date: Fri, 1 May 2009 10:07:00 -0400

Hi,
inline. 

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] 
> Sent: Thursday, April 30, 2009 7:02 PM
> To: [email-masked]; [email-masked]; [email-masked]
> Cc: [email-masked]; [email-masked]; [email-masked]; 
> [email-masked]; [email-masked]
> Subject: RE: [OPS-DIR] FW: Internal WG Review: STORage 
> Maintenance (storm)
> 
> Let me start by acknowledging that David Harrington is right
> about the absence of operations and management in the charter.
> At a minimum, the new iSCSI features strongly suggest an
> updated version of the iSCSI MIB (RFC 4544), and I need to
> revise the draft charter to include that.  If David Harrington
> is willing to serve as a technical advisor to facilitate this
> update, that would be helpful.

Part of my concern is whether SNMP MIBs are the correct answer for
storage management. 
I do not know the answer to the question. Much of the charter
discusses bringing the 
IETF storage standards into compliance with implementation/deployment
reality.

I think the WG should also consider how to bring the storage MIBs into
compliance with
implementation/deployment reality. At a minimum, if new features are
added to the IETF storage
stanards, then the MIBs should also be updated. (I'll check with my
bosses to see if
they will support my acting as MIB/OPS technical advisor.)

But if the storage MIBs are not being used, and other management
standards are used for managing storage,
then maybe the IETF needs to acknowldge that reality and have our
standards accommodate that.

> 
> OTOH, I disagree with the suggestion that the WG "consider
> and document" ... "what changes might need to be made to
> utilize the existing non-IETF standards to manage the updated
> IETF storage standards".  IMHO, it is usually better to
> communicate the functional changes that the IETF is making
> in its protocols to other standards organizations that
> are responsible for related (e.g., management) standards.
> That enables those organizations to make any changes that
> they deem appropriate based on their expertise - in contrast,
> issuing explicit instructions to another standards organization
> has the potential to go over badly (IMHO).  The draft charter
> already contains references to working relationships with T10
> and T11 - it looks like it needs corresponding text for SNIA
> around the iSCSI HBA API and SMI-S support for iSCSI.

I think you misunderstood my intentions. If non-IETF standards for
management 
(SNIA SMI-S and T10/T11 HBA) are widely used in the real world, and
IETF management
standards are not widely used to manage iSCSI, FCIP, etc., then we
should 
consider how **our** standards - iSCSI, FCIP, storage MIBs, etc.,
should be
modified to work better with those widely-deployed non-IETF standards
for 
storage management. Or whether a combination of IETF management
standards (syslog,
netconf, and SNMP) would be more suitable than the SNMP-only approach.

If SCSI is usually managed using HBA and not SNMP, then we should
consider whether
**i**SCSI needs to be changed to allow consistent (both i* and non-i*)
SCSI management.
Maybe we need changes to iSCSI to make it compatible with SNMP and HBA
and SMI-S.

> 
> Not announcing the BoF on the IETF list was my oversight;
> that clearly should have been done prior to San Francisco.
> I'll work with Lars on ensuring that there is sufficiently
> broad IETF exposure and review of the proposed storm charter.

Thanks.

> 
> For the security concerns, please see RFC 3723 (Securing
> Block Storage Protocols over IP).  I expect that RFC to
> remain applicable to all of the revised protocols, with the
> overall approach being that security issues in technology that
> is standardized by another standards body are the responsibility
> of that standards body; would a statement to that effect (RFC
> 3723 expected to remain applicable, security issues in standards
> from other organizations remain the responsibility of those
> organizations) in the charter be helpful?  

Having such a statement would have made it clearer to people like me
who are not in the other organizations.

> 
> That said, I am surprised by what appears to be an inference
> that lack of mention of security in the charter implies that
> security may not be addressed at all.  All RFCs have to address
> security considerations, making security something that every
> IETF WG has to address, independent of whether security is
> explicitly mentioned in the WG charter.  If every WG charter
> now has to have a "Security Considerations" section, there are
> number of WG charters on the IETF web site that need updates
> ... surely the IESG has better things to do ;-).

I did not overlook that you would need to deal with Security
Considerations.

I did overlook RFC3723. There are lots of documents related to iSCSI 
and iFC and FCIP and iSNS and ... I simply haven't had time to study
all of them.

The problem I have is that I could not look at the documents from
INCITS 
to determine the status of security for SCSI/iSCSI and FC/FCIP, etc. 
I suspect the INCITS documents do not directly discuss iSCSI security.
My 
impression is T10/T11 focus on non-Internet connectivity, where
security
concerns/threats might be different than for Internet connectivity.

INCITS did make public their intention to update SAM-4 to address
security.
Apparently they think there is something that needs addressing.
But I don't know what they know, because they don't say what needs 
addressing and you don't say anything about upgrading security as you
upgrade the i* variations of the underlying protocols.
(Maybe the SAM-4 pretty picture of the architecture needs to be
updated
to show the security boxes. But the SAM-5 proposal simply doesn't say
what 
needs to be done, so i cnanto see if it is something simple or
something difficult
that could impact making storage accessible securely over the
Internet.)

> 
> Regarding SAM-5, the draft storm WG charter references SAM-4
> and not SAM-5 for a reason; SAM-5 is an out-of-scope moving
> target.  

Understood. I was not suggesting we should try for SAM-5
compatibility.

> FWIW, most SCSI (T10) security is not in the SAM
> standards, but rather in the SPC-4 standard (under development).
> For Fibre Channel (T11) security, see the FC-SP standard and
> the FC-SP-2 standard (under development).
> 
> That brings me to the T10 and T11 standards access concerns,
> which are real and something I need to work on.  INCITS, the
> parent organization of T10 and T11, imposed new document
> access restrictions within the past year.  I need to work
> with T10 and T11 on how to go about making the necessary
> standards documents available to IETF participants, starting
> with T10 (which meets next week).  I do not intend to ask
> the IESG for approval of the storm WG charter until the
> document access concerns are resolved.
> 
> Thanks,
> --David
>  
> 
> > -----Original Message-----
> > From: David Harrington [mailto:[email-masked]] 
> > Sent: Thursday, April 30, 2009 12:30 PM
> > To: 'Lars Eggert'; 'Ersue, Mehmet (NSN - DE/Munich)'
> > Cc: [email-masked]; [email-masked]; Black, David; 
> > [email-masked]; [email-masked]; 'IAB'
> > Subject: RE: [OPS-DIR] FW: Internal WG Review: STORage 
> > Maintenance (storm)
> > 
> > Hi,
> > 
> > I found that having the discussion for the STORM BOF on the
mailing
> > lists for (three) concluded WGs made it a bit obscure.
> > As far as I can tell by looking at those archives, there wasn't
much
> > discussion.
> > I will also note that the announcement of the craetion of the
storm
> > list seems to be have been only announced to the lists of the
three
> > concluded WGs. So if you weren't involved in the three earlier
WGs,
> > you might not have seen the announcement. 
> > 
> > I do think Mehmet has a point that many IETF people may not 
> have been
> > aware the discussion was happening.
> > 
> > As an OPSDIR member and MIB Doctor, I have already 
> expressed concerns
> > that operations and management is not being addressed in 
> the charter.
> > The chair helpfully responded with a short list of management
> > standards (SNIA SMI-S, SNIA SCSI HBA, INCITS FC HBA) that might
help
> > answer my questions. Unfortunately, I cannot access some of the
> > documents referenced because they are not freely available. 
> If I read
> > through a number of large standards I might be able to determine
for
> > myself what changes might need to be made to utilize the existing
> > non-IETF standards to manage the updated IETF storage standards. I
> > think I would rather see the WG consdier this and document 
> it, rather
> > than me (and any other user of the IETF technologies) having to
> > research this personally to know the answers. I would nto say my
> > concerns have been addressed.
> > 
> > As a SECDIR member, I have concerns that security may not be
gettng
> > addressed either, but it is hard for me to say that for sure since
I
> > cannot freely access the T10 and T11 documents that are the basis
of
> > the updates. I do not know whether the updated IETF storage 
> standards
> > will utilize IETF standards for security or non-IETF stndards for
> > security, or whether the WG is simply not going to address
security
> > issues since it is not mentioned in the charter. I note that the
> > charter calls for updating to SAM-4 level, and that T10 is
starting
> > new work on SAM-5, explicitly to address security. So does that
mean
> > security will not be addressed in the STORM WG?
> > 
> > I have not seen these discussions elsewhere. And Mehmet's concerns
> > seem to be relevant to that point.
> > 
> > Before the WG is created, I think the charter should be 
> explicit about
> > the what the WG will do to address how these Internet 
> protocols should
> > be operated and managed and secured.
> >  
> > David Harrington
> > [email-masked]
> > [email-masked]
> > [email-masked]
> > 
> > > -----Original Message-----
> > > From: [email-masked] 
> > > [mailto:[email-masked]] On Behalf Of Lars Eggert
> > > Sent: Tuesday, April 28, 2009 12:44 PM
> > > To: Ersue, Mehmet (NSN - DE/Munich)
> > > Cc: [email-masked]; [email-masked]; 
> > > [email-masked]; [email-masked]
> > > Subject: Re: [OPS-DIR] FW: Internal WG Review: STORage 
> > > Maintenance (storm)
> > > 
> > > Hi,
> > > 
> > > On 2009-4-28, at 12:29, Ersue, Mehmet (NSN - DE/Munich) wrote:
> > > > unfortunately I missed the Storm BoF in SF. I also was not
aware
> > of
> > > > the discussion on the maillists you mention.
> > > >
> > > > I made the experience that announcing a BoF maillist to IETF
and
> > > > forcing some discussion on this maillist with IETF member  
> > > > participation
> > > > is a good way to show IESG that there is measurable 
> IETF community
> > > > interest.
> > > 
> > > as David said below, there was discussion on the 
> > > still-existing RDDP,  
> > > IPS and IMSS lists, and the BOF went - in my opinion - 
> very well. I
> > 
> > > believe community interest has been demonstrated, which 
> is why we're
> > 
> > > going forward with a charter proposal.
> > > 
> > > > The huge amount of people in the session, which are sometimes
> > > > occasionally in the room and vote, usually disappear when 
> > > it comes to
> > > > maillist discussion. Also for our regular WG work the
decisions
> > have
> > > > to be confirmed on the maillist.
> > > >
> > > > As I said I believe this is an important and necessary
> > consolidation
> > > > work but should be discussed and accepted first in the IETF 
> > > community.
> > > 
> > > I don't quite know what to do with you comment. Are you 
> saying there
> > 
> > > hasn't been sufficient discussion to go forward with the 
> chartering?
> > 
> > > Or am I misunderstanding?
> > > 
> > > I'll also note that the community obviously still has time to 
> > > comment  
> > > - the charter is in internal I* review at this time, 
> after which it
> > 
> > > will go for public review.
> > > 
> > > Lars
> > > 
> > > >
> > > > Cheers,
> > > > Mehmet
> > > >
> > > >
> > > >> -----Original Message-----
> > > >> From: ext [email-masked] [mailto:[email-masked]]
> > > >> Sent: Tuesday, April 28, 2009 2:32 PM
> > > >> To: Ersue, Mehmet (NSN - DE/Munich)
> > > >> Cc: [email-masked]; [email-masked]
> > > >> Subject: RE: [OPS-DIR] FW: Internal WG Review: STORage
> > > >> Maintenance (storm)
> > > >>
> > > >> Mehmet,
> > > >>
> > > >> The storm list is completely new (it was only opened for
people
> > > >> to subscribe within the past few days).  The storm BOF in San
> > > >> Francisco was organized using the existing IPS, RDDP and IMSS
> > > >> mailing lists.  I suggest consulting the archives for those
> > > >> lists, particularly for the IPS list, where you should find a
> > > >> reasonable level of community interest.
> > > >>
> > > >> There is definite community interest in this work, and I have
> > > >> author commitments for drafts for all six work items listed
> > > >> in the charter - each of the "First version of" milestone
> > > >> dates in the proposed charter is based on discussion with an
> > > >> author or authors who believe that a first version of the
draft
> > > >> will be ready by that date.
> > > >>
> > > >> 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
> > > >> ----------------------------------------------------
> > > >>
> > > >>> -----Original Message-----
> > > >>> From: Romascanu, Dan (Dan) [mailto:[email-masked]]
> > > >>> Sent: Tuesday, April 28, 2009 6:33 AM
> > > >>> To: Ersue, Mehmet (NSN - DE/Munich)
> > > >>> Cc: Black, David
> > > >>> Subject: RE: [OPS-DIR] FW: Internal WG Review: STORage
> > > >>> Maintenance (storm)
> > > >>>
> > > >>> Mehmet,
> > > >>>
> > > >>> David Black ran the BOF in San Francisco. He should be able
> > > >> to provide
> > > >>> you information about the preparation work, level of 
> support and
> > > >>> interest from the community and initial drafts.
> > > >>>
> > > >>> Thanks for looking into this and for asking the questions.
> > > >>>
> > > >>> Dan
> > > >>>
> > > >>>
> > > >>>> -----Original Message-----
> > > >>>> From: Ersue, Mehmet (NSN - DE/Munich)
> > > >> [mailto:[email-masked]]
> > > >>>> Sent: Tuesday, April 28, 2009 1:29 PM
> > > >>>> To: Romascanu, Dan (Dan)
> > > >>>> Subject: RE: [OPS-DIR] FW: Internal WG Review: STORage
> > > >>>> Maintenance (storm)
> > > >>>>
> > > >>>>
> > > >>>> Hi Dan,
> > > >>>>
> > > >>>> I believe this is an important and necessary consolidation
> > work.
> > > >>>>
> > > >>>> I might have missed the discussion on another maillist but
> > > >>>> the storm maillist is pretty much new and I would have a
> > > >>>> better feeling if there were some mail traffic showing the
> > > >>>> interest of the community and/or an initial draft with an
> > > >>>> issues list for the justification of a new WG.
> > > >>>>
> > > >>>> Cheers,
> > > >>>> Mehmet
> > > >>>>
> > > >>>>
> > > >>>>> -----Original Message-----
> > > >>>>> From: [email-masked]
> > > >>>>> [mailto:[email-masked]] On Behalf Of ext 
> Romascanu,
> > > >>>>> Dan (Dan)
> > > >>>>> Sent: Monday, April 27, 2009 7:57 PM
> > > >>>>> To: [email-masked]; [email-masked]
> > > >>>>> Subject: [OPS-DIR] FW: Internal WG Review: STORage
> > > >>>> Maintenance (storm)
> > > >>>>>
> > > >>>>>
> > > >>>>>
> > > >>>>>
> > > >>>>> -----Original Message-----
> > > >>>>> From: [email-masked] 
> [mailto:[email-masked]] On
> > > >>>>> Behalf Of
> > > >>>>> IESG Secretary
> > > >>>>> Sent: Monday, April 27, 2009 8:54 PM
> > > >>>>> To: [email-masked]; [email-masked]
> > > >>>>> Cc: [email-masked]
> > > >>>>> Subject: Internal WG Review: STORage Maintenance (storm)
> > > >>>>>
> > > >>>>> A new IETF working group is being considered in the 
> Transport
> > > >>>>> Area.  The
> > > >>>>> draft charter for this working group is provided below for
> > > >>>> your review
> > > >>>>> and comment.
> > > >>>>>
> > > >>>>> Review time is one week.
> > > >>>>>
> > > >>>>> The IETF Secretariat
> > > >>>>>
> > > >>>>> STORage Maintenance (storm)
> > > >>>>> ----------------------------------
> > > >>>>>
> > > >>>>> Last Modified: 2009-04-25
> > > >>>>>
> > > >>>>> Current Status: Proposed Working Group
> > > >>>>>
> > > >>>>> Chairs:
> > > >>>>> - David L. Black <[email-masked]>
> > > >>>>> - tbd
> > > >>>>>
> > > >>>>> Transport Area Director(s):
> > > >>>>> - Magnus Westerlund <[email-masked]>
> > > >>>>> - Lars Eggert <[email-masked]>
> > > >>>>>
> > > >>>>> Transport Area Advisor:
> > > >>>>> - Lars Eggert <[email-masked]>
> > > >>>>>
> > > >>>>> Mailing Lists:
> > > >>>>> General Discussion: [email-masked]
> > > >>>>> To Subscribe: [email-masked]
> > > >>>>> In Body: (un)subscribe
> > > >>>>> Archive: 
> http://www.ietf.org/mail-archive/web/storm/index.html
> > > >>>>>
> > > >>>>> Description of Working Group:
> > > >>>>>
> > > >>>>> The IETF IPS (IP Storage) and RDDP (Remote Direct Data
> > > >> Placement)
> > > >>>>> working groups have produced a significant number of
> > > >>>> storage protocols
> > > >>>>> (e.g., iSCSI, iSER and FCIP) for which there is
significant
> > > >>>> usage. The
> > > >>>>> time has come to reflect feedback from implementation and
> > > >>> usage into
> > > >>>>> updated RFCs; this work may include:
> > > >>>>>
> > > >>>>> - Implementation-driven revisions and updates to existing
> > > >>> protocols
> > > >>>>> (i.e., updated RFCs that match the "running code").
> > > >>>>>
> > > >>>>> - Interoperability reports as needed for the resulting
> > > >>>>> revised protocols
> > > >>>>> that are appropriate for Draft Standard RFC status.
> > > >>>>>
> > > >>>>> - Minor protocol changes or additions. Backwards
> > > >> compatibility is
> > > >>>>> required.
> > > >>>>>
> > > >>>>> Significant changes to the existing protocol standards are
> > > >>>>> out of scope,
> > > >>>>> including any work on version 2 of any of these protocols.
> > > >>>>>
> > > >>>>> Stability is critical to the usage of these protocols, so
> > > >>> backwards
> > > >>>>> compatibility with existing implementations will be a
> > > >> requirement
> > > >>>>> imposed on for all protocol changes and additions. Note
> > > >>>> that this is a
> > > >>>>> requirement for implementation compatibility - if it is
the
> > > >>>> case that
> > > >>>>> all implementations of a protocol have done something
> > > >>> different than
> > > >>>>> what the RFC specifies, it is appropriate for a new RFC to
> > > >>>>> document what
> > > >>>>> the "running code" actually does and deprecate the
> > > >> unused original
> > > >>>>> behavior.
> > > >>>>>
> > > >>>>> Initial list of work items:
> > > >>>>>
> > > >>>>> (1) iSCSI: Combine RFCs 3720 (iSCSI), 3980 (NAA names),
> > > >> 4850 (node
> > > >>>>> architecture key) and 5048 (corrections/clarifications)
> > > >>>> into one draft
> > > >>>>> (3720bis), removing features that are not implemented in
> > > >>>>> practice. This
> > > >>>>> draft should be prepared so that it could become a Draft
> > > >>>> Standard RFC,
> > > >>>>> but it is up to the to decide whether to advance it to
> > > >>>> Draft Standard.
> > > >>>>>
> > > >>>>> (2) iSCSI: Add features to support SAM-4 (4th version
> > > >> of the SCSI
> > > >>>>> architecture) in a backwards-compatible fashion, as iSCSI
> > > >>>> is currently
> > > >>>>> based on SAM-2. This will be a separate draft from the
> > > >>>> iSCSI update in
> > > >>>>> the previous bullet. The Working group may add additional
> > > >>>> minor useful
> > > >>>>> iSCSI features to this draft.
> > > >>>>>
> > > >>>>> (3) FCIP: IP Protocol number 133 was allocated to a
> > > >>> precursor of the
> > > >>>>> FCIP protocol in 2000, but this allocated number is not
> > > >>>> used by FCIP.
> > > >>>>> The working group will consider whether this 
> allocated number
> > > >>>>> should be
> > > >>>>> returned to IANA for future reallocation.
> > > >>>>>
> > > >>>>> (4) iFCP: The Address Translation mode of iFCP needs to be
> > > >>>> deprecated
> > > >>>>> (SHOULD NOT implement or use), as there are significant
> > > >> technical
> > > >>>>> problems with its specification, and moreover, only the
> > Address
> > > >>>>> Transparent mode of iFCP is in use. This will be done via
a
> > > >>>>> short draft
> > > >>>>> that updates RFC 4172, and not via a complete rewrite of
> > > >>> RFC 4172. A
> > > >>>>> combined draft is expected that encompasses items 
> (3) and (4).
> > > >>>>>
> > > >>>>> (5) RDDP MPA: Good support for MPI applications requires a
> > > >>>>> small update
> > > >>>>> to the startup functionality to allow either end of the
> > > >>>> connection to
> > > >>>>> initiate.
> > > >>>>>
> > > >>>>> (6) iSER: Experience with Infiniband implementations
suggest
> > > >>>>> a few minor
> > > >>>>> updates to reflect what has been done in practice.
> > > >>>>>
> > > >>>>> The working group is expected to maintain good working
> > > >>> relationships
> > > >>>>> with INCITS Technical Committee T10 (SCSI standards) and
> > INCITS
> > > >>>>> Technical Committee T11 (Fibre Channel standards) via
> > > >> overlaps in
> > > >>>>> membership as opposed to appointment of formal liaisons.
> > > >>> The liaison
> > > >>>>> process (including IAB appointment of a liaison or
> > > >>>>> liaisons) remains available for use if needed.
> > > >>>>>
> > > >>>>> Goals and Milestones:
> > > >>>>>
> > > >>>>> June 2009 First version of FCIP protocol number and iFCP
> > Address
> > > >>>>> Translation mode draft
> > > >>>>>
> > > >>>>> July 2009 First version of iSCSI SAM-4 (and other) new
> > > >>>> features draft.
> > > >>>>>
> > > >>>>> Aug 2009 First version of RDDP MPA startup change draft
> > > >>>>>
> > > >>>>> Sep 2009 Working Group Last Call on FCIP protocol
> > > >> number and iFCP
> > > >>>>> address change draft
> > > >>>>>
> > > >>>>> Sep 2009 First version of combined iSCSI draft (3720bis)
> > > >>>>>
> > > >>>>> Oct 2009 First version of iSER update draft
> > > >>>>>
> > > >>>>> Oct 2009 Working Group Last Call on RDDP MPA startup
> > > >> change draft.
> > > >>>>>
> > > >>>>> Dec 2009 Functionally complete iSCSI SAM-4 (and other)
> > > >>> new features
> > > >>>>> draft.
> > > >>>>>
> > > >>>>> Feb 2010 Working Group Last Call on iSER update draft
> > > >>>>>
> > > >>>>> March 2010 Working Group Last Call on iSCSI SAM-4 (and
> > > >> other) new
> > > >>>>> features draft.
> > > >>>>>
> > > >>>>> April 2010 Working Group decision on whether to seek Draft
> > > >>>>> Standard RFC
> > > >>>>> status for the combined iSCSI draft (3720bis). [Note:
> > > >>>>> decision may be made significantly before this date.]
> > > >>>>>
> > > >>>>> Sep 2010 Working Group Last Call on combined iSCSI
> > > >> draft (3720bis)
> > > >>>>> _______________________________________________
> > > >>>>> OPS-DIR mailing list
> > > >>>>> [email-masked]
> > > >>>>> https://www.ietf.org/mailman/listinfo/ops-dir
> > > >>>>>
> > > >>>>
> > > >>>
> > > >>>
> > > >>
> > > 
> > > _______________________________________________
> > > OPS-DIR mailing list
> > > [email-masked]
> > > https://www.ietf.org/mailman/listinfo/ops-dir
> > > 
> > 
> > 
> > 
>

---

From: "David Harrington" <[email-masked]>
Date: Fri, 1 May 2009 11:44:23 -0400

Hi,

I would like to probe an apparent inconsistency.

> [...] I need to
> revise the draft charter to include that. 
 
> [...]

So you are surprised by the inference that security may not be
addressed
because all RFCs have to address security considerations.
You do not seem surprised by the same inference regarding OPS+MGMT.
So if the IESG does not mandate an OPS+MGMT considerations section,
just 
as they do for security, then in the absence of such a mandate it is
not 
surprising to infer that management will not be addressed unless it is
explicitly stated in the charter?

Did I understand your responses correctly?

dbh

---

From: [email-masked]
Date: Fri, 1 May 2009 12:16:16 -0400

David,

The source of the inconsistency is that the proposed STORM
charter has a concrete omission in the OPS+MGMT area, namely
an iSCSI MIB update, whereas I know of no corresponding
concrete omission in the security area.  IMHO, the charter
needs an update to correct that omission.

> just as they do for security, then in the absence of such a mandate
> it is not surprising to infer that management will not be addressed
> unless it is explicitly stated in the charter?

No - I fully expect the OPS+MGMT ADs to use pointed "Discuss"es
to ensure that any such issues are addressed, and a good WG chair
is out ahead of this class of issue.  This is not just about
OPS+MGMT - by way of analogy, as a member of the Transport
Directorate, I expect the Transport ADs to do likewise for
congestion control issues, independent of whether congestion
control is in a WG's charter or not (and a good WG chair is out
ahead of congestion control issues before they cause "Discuss"es).

Thanks,
--David

> Sent: Friday, May 01, 2009 11:44 AM
> To: Black, David; [email-masked]; [email-masked]
> [email-masked]

---

From: "Romascanu, Dan (Dan)" <[email-masked]>
Date: Fri, 1 May 2009 19:11:27 +0200

David (B),

DISCUSSes on the protocol documents are exactly at the oposite extremity
of the IETF process. They are certainly a good tool to address issues
when the document arrives at the IESG table for review and approval.
However, the operational and manageability issues need to be addressed
at each phase of the development of the protocol starting with the WG
chartering phase which we are now in.  Asking the questions that David
(H) is asking about how the storage technology is managed over the
Internet, looking at the MIB modules defined in the previous phase and
assessing whether they meet the operational needs, looking whether other
protocols may do a similar or better job, all these seem reasonable
issues to discuss now and catch in the future charter. Even the fact
that there seems to be lesser interest in doing further MIB work is an
indication of some kind that we need to address. 

Dan

> From: [email-masked] [mailto:[email-masked]] On 
> Behalf Of [email-masked]
> Sent: Friday, May 01, 2009 7:16 PM
> Cc: [email-masked]; [email-masked]; [email-masked]; 
> [email-masked]; [email-masked]
> > just as they do for security, then in the absence of such a 
> mandate it 
> > is not surprising to infer that management will not be addressed 
> No - I fully expect the OPS+MGMT ADs to use pointed 
> "Discuss"es to ensure that any such issues are addressed, and 
> a good WG chair is out ahead of this class of issue.  This is 
> not just about
> control is in a WG's charter or not (and a good WG chair is 
> out ahead of congestion control issues before they cause "Discuss"es).
> 
> Thanks,
> --David
>  
> 
> > Subject: RE: [OPS-DIR] FW: Internal WG Review: STORage Maintenance 
> > (storm)
> > 
> > Hi,
> > 
> > > Let me start by acknowledging that David Harrington is 
> right about 
> > > the absence of operations and management in the charter.
> > > [...] I need to
> > > That said, I am surprised by what appears to be an inference that 
> > > lack of mention of security in the charter implies that 
> security may 
> > > not be addressed at all.  All RFCs have to address security 
> > > considerations, making security something that every IETF 
> WG has to 
> > > address, independent of whether security is explicitly 
> mentioned in 
> > > the WG charter.  If every WG charter now has to have a "Security 
> > > Considerations" section, there are number of WG charters 
> on the IETF 
> > > web site that need updates ... surely the IESG has better 
> things to 
> > > do ;-).
> > 
> > addressed because all RFCs have to address security considerations.
> > just as they do for security, then in the absence of such a 
> mandate it 
> > is not surprising to infer that management will not be addressed

---

From: [email-masked]
Date: Fri, 1 May 2009 13:27:51 -0400

Dan,

I agree with almost everything you wrote (and I have a track
record of addressing issues from other areas in WGs that I've
run).  OTOH, I have a concern here in that the M in STORM
stands for "Maintenance" - there are a bunch of moderately
sized updates and cleanup that need to be done to the protocol
specs in this area.  Rightly or wrongly, I perceive the direction
of Dave H's questions as wanting to explore completely reworking
storage-related management.

While I like the idea of exploring that area in principle, I'm
concerned that a maintenance-oriented proposed TSV WG may not
be a particularly good forum for heavy-duty OPS+MGMT work.  Let
me suggest an OPS Directorate discussion as an alternative forum
in which to make progress on this - I expect to be in Stockholm
and would be happy to spend time on this in the meeting and/or
hallway discussion.  What do you think about this?

Thanks,
--David

> Sent: Friday, May 01, 2009 1:11 PM
> To: Black, David; [email-masked]; [email-masked]; 
> [email-masked]
> [email-masked]
> Maintenance

---

From: "Romascanu, Dan (Dan)" <[email-masked]>
Date: Fri, 1 May 2009 19:45:26 +0200

David,

Unless all the incremental changes you plan have no impact at all on
operations and manageability I would prefer that the issues be brought
up with the community that requested the formation of the WG and
addressed in the charter rather than postponed for a future discussion
in other frameworks (OPS-DIR would not be anyway the appropriate place,
as this is mainly a review team providing advice to the OPS ADs). Not
dealing with the manageability issues would mean that we create a delay
between the evolution of the technology and the MIB modules for
interoperable management. It would be OK to say management by SNMP is
not deployed but then the MIB RFCs could be made Historical and
something else recommended. It would be OK to write an Informational RFC
that explains how storage is operationally deployed and managed over the
Internet. It is not OK I think to ignore the issue. 

Dan

> Sent: Friday, May 01, 2009 8:28 PM
> To: Romascanu, Dan (Dan); [email-masked]; 
> [email-masked]; [email-masked]
> sized updates and cleanup that need to be done to the 
> protocol specs in this area.  Rightly or wrongly, I perceive 
> the direction of Dave H's questions as wanting to explore 
> completely reworking storage-related management.
> 
> While I like the idea of exploring that area in principle, 
> I'm concerned that a maintenance-oriented proposed TSV WG may 
> not be a particularly good forum for heavy-duty OPS+MGMT 
> work.  Let me suggest an OPS Directorate discussion as an 
> alternative forum in which to make progress on this - I 
> expect to be in Stockholm and would be happy to spend time on 
> this in the meeting and/or hallway discussion.  What do you 
> think about this?
> 
> Thanks,
> --David
> 
> 
> > DISCUSSes on the protocol documents are exactly at the oposite 
> > extremity of the IETF process. They are certainly a good tool to 
> > address issues when the document arrives at the IESG table 
> for review 
> > and approval.
> > assessing whether they meet the operational needs, looking whether 
> > other protocols may do a similar or better job, all these seem 
> > reasonable issues to discuss now and catch in the future 
> charter. Even 
> > the fact that there seems to be lesser interest in doing 
> further MIB 
> > work is an indication of some kind that we need to address.
> > 
> > Dan
> > 
> > 
> [mailto:[email-masked]] On Behalf 
> > > Of [email-masked]
> > > The source of the inconsistency is that the proposed 
> STORM charter 
> > > has a concrete omission in the OPS+MGMT area, namely an iSCSI MIB 
> > > update, whereas I know of no corresponding concrete 
> omission in the 
> > > security area.  IMHO, the charter needs an update to correct that 
> > > omission.
> > > 
> "Discuss"es to 
> > > ensure that any such issues are addressed, and a good WG chair is 
> > > out ahead of this class of issue.  This is not just about
> > > congestion control issues, independent of whether 
> congestion control 
> > > is in a WG's charter or not (and a good WG chair is out ahead of 
> > > congestion control issues before they cause
> > "Discuss"es).
> > > 
> > > Thanks,
> > > --David
> > >  
> > >

---

From: [email-masked]
Date: Fri, 1 May 2009 15:31:22 -0400

Dan,

I think we should distinguish two topics:

> interoperable management.

I agree with this, and it's my fault that the storm charter draft
fails to mention the need to update at least the iSCSI MIB RFC.
There may be a few additional MIBs that need attention - I'll check
on this.

> It would be OK to say management by SNMP is

This is a much broader topic, as it potentially affects something
like 15 MIB RFCs (produced by the ips and imss WGs), and involves
a *lot* of non-IETF technology.  I believe that most of these MIBs
are in use for various things (e.g., monitoring).  It is only this
broader topic that I am suggesting might benefit from some OPS
Directorate discussion.

Thanks,
--David

> Sent: Friday, May 01, 2009 1:45 PM

---

From: "David Harrington" <[email-masked]>
Date: Fri, 1 May 2009 15:33:58 -0400

Hi David (B),

> storage-related management.

Actually, I think that is partially right and partially wrong.
I do not know how large the differences are between the SAM-2
architectural
model and the SAM-4 architectural model, but I assume there are 
some significant differences that will be done as part of the
STORM "maintenance". 

The IETF has had a significant change in its philosophy of operations 
and management. When Randy Bush became an AD, he pushed hard to make
the
IETF understand that "write a MIB" was not a good solution for
real-world
management of Internet technologies. As a result the IETF started
working on 
standardizing additional protocols for management, such as syslog,
netconf, 
and ipfix. Basically, the IETF architecture/framework was changed.
We went from having a single MIB for all management purposes (and
effectively 
one protocol that accessed it) to multiple purpose-driven management
protocols. 
IETF did this because it was "time to reflect feedback from
implementation and usage".

If we are going to do maintenance to reflect the updated SAM
architecture, 
then I think we should also reflect the updated IETF Management
Framework.
I do not think it makes sense to blindly update the MIB modules
without 
considering whether MIB modules are still considered the best current
practice 
for all forms of Internet management. 

If the Internet storage industry has decided that SMI-S and T10 HBA
and T11 HBA 
make more sense for managing Internet storage than SNMP and MIB
modules, then, 
as the charter says, "The time has come to reflect feedback from
implementation 
and usage into updated RFCs". If syslog and snmp traps are used widely
for reporting
events, the updated RFCs should reflect that.

I do not propose that we develop Netconf/netmod modules, or that we
develop new SDEs 
for the syslog protocol. That can always be done as part of version 2
of any protocols, 
or even done as separate tasks.

OTOH, if updating to reflect SAM-4 is lees about "feedback from
implementation and usage"
and more about being consistent with emerging T10/T11 standards, then
I think the IETF storage
technology documents should RECOMMEND the IETF Proposed Standard
syslog for logging, and
the Proposed Standard netconf for configuration, and the Proposed
Standard ipfix for
information on IP flows, and SNMPv3 for monitoring, when these
standards-track protocols 
are appropriate, since they are now part of the updated IETF
architecture.

So I think the storage protocol RFCs should have their management
updated only to the degree 
of updating the RFCs to reflect implementation and usage, and to
reflect the updated IETF 
management framework.

David Harrington
[email-masked]
[email-masked]
[email-masked]

---

From: "Romascanu, Dan (Dan)" <[email-masked]>
Date: Fri, 1 May 2009 22:13:27 +0200

David,

See in-line. 

Regards,

Dan

> Sent: Friday, May 01, 2009 10:31 PM
> I agree with this, and it's my fault that the storm charter 
> draft fails to mention the need to update at least the iSCSI MIB RFC.
> There may be a few additional MIBs that need attention - I'll 
> check on this.
> 

This looks good. 

> > It would be OK to say management by SNMP is not deployed 
> but then the 
> > MIB RFCs could be made Historical and something else 
> recommended. It 
> > would be OK to write an Informational
> RFC
> This is a much broader topic, as it potentially affects 
> something like 15 MIB RFCs (produced by the ips and imss 
> WGs), and involves a *lot* of non-IETF technology.  I believe 
> that most of these MIBs are in use for various things (e.g., 
> monitoring).  It is only this broader topic that I am 
> suggesting might benefit from some OPS Directorate discussion.

Fine with this. Yet, it may be not necessarily an OPS-DIR discussion,
but maybe one for the open OPSAREA meeting, so that it can reach a
broader audience. 

Dan

---

From: [email-masked]
Date: Fri, 1 May 2009 17:31:09 -0400

Dan,

Many thanks - I think I may have just volunteered myself for
an OPSAREA time slot in Stockholm ...

Thanks,
--David

> Sent: Friday, May 01, 2009 4:13 PM
> > > It would be OK to say management by SNMP is not deployed but then
the 
> > > MIB RFCs could be made Historical and something else recommended.
It 
> > > would be OK to write an Informational RFC
> > > that explains how storage is operationally deployed and managed
over
> > > the Internet. It is not OK I think to ignore the issue. 
> >

---

From: [email-masked]
Date: Fri, 1 May 2009 17:34:01 -0400

David,

[ ... MIB & management discussion snipped, as Dan (AD) and I are
	in rough agreement on how to move forward on those topics ...]

> and iFCP and FCIP and iSNS and ... I simply haven't had time to study
> all of them.

I'll add some mention of RFC 3723 to the proposed charter.

INCITS 
> to determine the status of security for SCSI/iSCSI and FC/FCIP, etc. 

I wish you'd asked where to look for this information first, as
I've done a fair amount of work on security for both of these
technologies.  FWIW, I also do security work in the IETF -
RFC 5282 is a recent example.

For the status of security in SCSI and FC, the two documents to
look at are the working drafts of the SPC-4 and FC-SP-2 standards.
Both of these documents are publicly available, but (obviously)
the contents of each standard will change as the work progresses:

T10 SPC-4 Revision 18:
	http://www.t10.org/cgi-bin/ac.pl?t=f&f=spc4r18.pdf
T11 FC-SP-2 Version 2:
	http://www.t11.org/ftp/t11/pub/fc/sp-2/08-586v0.pdf

In addition, all of the proposal documents for both standards
efforts are publicly available (important for FC-SP-2, as there
is a lot of work that's not reflected in the current draft).

I have been a significant technical contributor to both standards
and would be happy to answer any questions that you have about
them.  Almost everything in these standards is above the level
of the IETF storage protocols and hence out of scope for the
proposed STORM WG (aside from being referenced if/as appropriate).

> security.  Apparently they think there is something that needs
> addressing.  But I don't know what they know, because they don't
> say what needs addressing 

Different organizations do things in different ways, and that
level of summation is not uncommon in INCITS project proposals
(in contrast, IETF WG charters tend to have a lot more details).

As an active member of T10 who works on security, my understanding
is that much of the explanation is:
- SAM-4 doesn't say anything about security (believe it or not,
	the word "security" does not occur in the standard).
- There is significant security functionality coming in SPC-4
	(cf. the draft referenced above).
- SAM-5 should be aligned with SPC-4, necessitating some
	security additions to the SCSI architecture.  See the
	SPC-4 draft for some idea of what's likely to be coming.

Thanks,
--David

> Sent: Friday, May 01, 2009 10:07 AM

---

From: [email-masked]
Date: Fri, 1 May 2009 17:41:58 -0400

David H,

> architectural model and the SAM-4 architectural model, but I
> assume there are some significant differences that will be done
> as part of the STORM "maintenance". 

I don't believe that's a good assumption.  This material was
discussed in the San Francisco STORM BOF and is in the
proceedings:

http://www.ietf.org/proceedings/09mar/slides/storm-3.pdf

Most of the items listed there are relatively small in scope.

[... remainder snipped ...]

Thanks,
--David

---

From: Lars Eggert <[email-masked]>
Date: Mon, 4 May 2009 10:02:56 +0300

Hi,

catching up on email after the long holiday weekend.

I agree with David Black that omitting to include a focused work item  
on updating the relevant storage MIBs in conjunction with updating the  
storage protocols was an oversight that we should correct in the next  
version of the STORM charter. None of the current work items struck me  
as having an obvious impact on manageability, which probably explains  
why this is so, and we should add a task to STORM that ensures that  
all maintenance changes are compatible with the current MIBs or where  
that isn't possible slightly update them.

I'm very hesitant to include any more fundamental work on operations  
and management of our suite of storage protocols in the STORM charter,  
because as David has pointed out, the goal is "maintenance" rather  
than "next major version". *If* the OPS community believes that major  
work is needed on the management aspects of IP storage, maybe it's  
time to bring back IMSS in some form?

Lars