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

["Ersue, Mehmet (NSN - DE/Munich)" <[e-mail]>]

David Harrington wrote:
> Hi David,
> 
> Are the existing storage MIB modules used widely in the industry? 
> Are the existing storage MIB modules used at all in the industry? 
> If not, should the WG ask that they be declared historic?
> If not, what management is actually used for the IETF storage
> protocols?
> Does this require standardization to improve interoperability?
> 
> What management is used for the underlying T10/T11 standards?
> Should the Internet versions of these protocols use the same
> management?
> If so, are there any specific changes to our storage protocols that
> need to be made to do so?
> 
> The IETF has standardized syslog and netconf and ipfix and capwap
> since the original versions of the IETF storage standards were
> developed. Would any of these new IETF management standards be more
> appropriate for addressing specific needs of storage management? 

This is an important consideration. It should be analyzed and noted why 
'new IETF management standards' are not appropriate for addressing 
specific needs of storage management. IETF is interested to use existing

protocols as much as possible.

Regards,
Mehmet

 
> The storage industry has been developing rapidly since the IETF
> storage protocols were developed. Virtualization, cloud computing,
> online backup, data deduplication, federated filesystems, power
> consumption issues have all become important considerations in data
> center operations and management. Do the management strategies for
> operating IETF storage protocols need to be updated to support
> emerging trends in the storage industry? 
> 
> The proposed charter does not seem to address operability and
> manageability of the IETF storage protocols in the current Internet
> environment and current storage environments.
> 
> Shouldn't that be part of the work of this WG?
> 
> David Harrington
> [e-mail]
> [e-mail]
> [e-mail]
> 
> > -----Original Message-----
> > From: [e-mail] [mailto:[e-mail]] 
> > Sent: Tuesday, April 28, 2009 8:20 AM
> > To: [e-mail]; [e-mail]; 
> > [e-mail]; [e-mail]
> > Cc: [e-mail]
> > Subject: RE: [OPS-DIR] FW: Internal WG Review: STORage 
> > Maintenance (storm)
> > 
> > I think it would be reasonable for the proposed storm WG to do MIB
> > work, but I am not aware of current interest in this activity.  If
> > you're interested and volunteering to do this, please let me know
> ...
> > 
> > Thanks,
> > --David
> >  
> > 
> > > -----Original Message-----
> > > From: [e-mail] 
> > > [mailto:[e-mail]] On Behalf Of David Harrington
> > > Sent: Monday, April 27, 2009 10:10 PM
> > > To: 'Romascanu, Dan (Dan)'; [e-mail]; [e-mail]
> > > Subject: Re: [OPS-DIR] FW: Internal WG Review: STORage 
> > > Maintenance (storm)
> > > 
> > > Will the storm BOF address updating the MIB modules or address
> > > managing the protocols in other ways?
> > > 
> > > dbh 
> > > 
> > > > -----Original Message-----
> > > > From: [e-mail] 
> > > > [mailto:[e-mail]] On Behalf Of Romascanu, 
> > Dan (Dan)
> > > > Sent: Monday, April 27, 2009 1:57 PM
> > > > To: [e-mail]; [e-mail]
> > > > Subject: [OPS-DIR] FW: Internal WG Review: STORage Maintenance
> > > (storm)
> > > > 
> > > >  
> > > > 
> > > > -----Original Message-----
> > > > From: [e-mail] [mailto:[e-mail]] On 
> > > > Behalf Of
> > > > IESG Secretary
> > > > Sent: Monday, April 27, 2009 8:54 PM
> > > > To: [e-mail]; [e-mail]
> > > > Cc: [e-mail]
> > > > 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 <[e-mail]>
> > > > - tbd
> > > > 
> > > > Transport Area Director(s):
> > > > - Magnus Westerlund <[e-mail]>
> > > > - Lars Eggert <[e-mail]>
> > > > 
> > > > Transport Area Advisor:
> > > > - Lars Eggert <[e-mail]>
> > > > 
> > > > Mailing Lists:
> > > > General Discussion: [e-mail]
> > > > To Subscribe: [e-mail]
> > > > 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
> > > > [e-mail]
> > > > https://www.ietf.org/mailman/listinfo/ops-dir
> > > > 
> > > 
> > > _______________________________________________
> > > OPS-DIR mailing list
> > > [e-mail]
> > > https://www.ietf.org/mailman/listinfo/ops-dir
> > > 
> > > 
> > 
> 
> _______________________________________________
> OPS-DIR mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/ops-dir
>