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

From: "Romascanu, Dan (Dan)" <[email-masked]>
Date: Mon, 27 Apr 2009 19:57:03 +0200

-----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)

---

From: "David Harrington" <[email-masked]>
Date: Mon, 27 Apr 2009 22:10:28 -0400

Will the storm BOF address updating the MIB modules or address
managing the protocols in other ways?

dbh 

> From: [email-masked] 
> [mailto:[email-masked]] On Behalf Of Romascanu, Dan (Dan)
> Sent: Monday, April 27, 2009 1:57 PM
> To: [email-masked]; [email-masked]
> Subject: [OPS-DIR] FW: Internal WG Review: STORage Maintenance
(storm)
> _______________________________________________
> OPS-DIR mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/ops-dir
>

---

From: "David Harrington" <[email-masked]>
Date: Tue, 28 Apr 2009 09:18:34 -0400

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? 

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
[email-masked]
[email-masked]
[email-masked]

> From: [email-masked] [mailto:[email-masked]] 
> Sent: Tuesday, April 28, 2009 8:20 AM
> To: [email-masked]; [email-masked]; 
> [email-masked]; [email-masked]
> Cc: [email-masked]
> 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
> > [mailto:[email-masked]] On Behalf Of David Harrington
> > Sent: Monday, April 27, 2009 10:10 PM
> > To: 'Romascanu, Dan (Dan)'; [email-masked]; [email-masked]
> > Subject: Re: [OPS-DIR] FW: Internal WG Review: STORage 
> > Maintenance (storm)
> > 
> > > (e.g., iSCSI, iSER and FCIP) for which there is significant
usage.
> > The
> > > imposed on for all protocol changes and additions. Note 
> that this is
> > a
> > > draft should be prepared so that it could become a Draft
Standard
> > RFC,
> > > based on SAM-2. This will be a separate draft from the 
> iSCSI update
> > in
> > > to the startup functionality to allow either end of the
connection
> > to

---

From: [email-masked]
Date: Tue, 28 Apr 2009 08:20:23 -0400

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

---

From: "Ersue, Mehmet (NSN - DE/Munich)" <[email-masked]>
Date: Tue, 28 Apr 2009 18:30:32 +0200

> 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

---

From: [email-masked]
Date: Tue, 28 Apr 2009 16:48:22 -0400

David,

> need to be made to do so?

The MIB modules are used to varying degrees.  As for other
storage management standards, start with these three:

[SNIA SMI-S]
  http://www.snia.org/forums/smi/tech_programs/smis_home/
[SNIA iSCSI HBA API]
  http://www.snia.org/tech_activities/standards/curr_standards/ima/
[INCITS T11 FC HBA API]
  http://www.nssn.org/search/DetailResults.aspx?docid=338714&selnode=

> appropriate for addressing specific needs of storage management? 

I would suggest that a familiarity with storage management
standards, starting with the above three, would be a useful step
towards answering that question.

> Shouldn't that be part of the work of this WG?

Sure, assuming that there's interest in that work - are you
volunteering to work on this?

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

---

From: "David Harrington" <[email-masked]>
Date: Thu, 30 Apr 2009 08:02:04 -0400

Hi,

SAM-4 compatibility is an explicit goal of the charter.
The T10 website says "Only T10 members are permitted to access this
document"

Will the SAM-4 documents be made freely available to
members/participants of the STORM WG?

dbh

(storm)

---

From: [email-masked]
Date: Thu, 30 Apr 2009 08:16:10 -0400

David,

Yes, something needs to be done to make this happen, thanks
for the reminder.

T10 meets next week - I'll need to talk to the responsible people
next week in order to figure out how to go about this, as the
rules that cause this inaccessibility were imposed on T10 from
above by INCITS.

I will have a solution to this problem before the IESG is asked
to approve the storm WG charter.

Thanks,
--David

> Sent: Thursday, April 30, 2009 8:02 AM
> Cc: 'IAB'; [email-masked]

---

From: "Romascanu, Dan (Dan)" <[email-masked]>
Date: Thu, 30 Apr 2009 14:51:10 +0200

> Sent: Tuesday, April 28, 2009 11:48 PM
> To: [email-masked]; Romascanu, Dan (Dan); 
> Cc: [email-masked]; [email-masked]
> standards, starting with the above three, would be a useful 
> step towards answering that question.
> 

It is not that simple :-)

David Harrington is asking I believe the right questions concerning the
operations aspects manageability of the technology - these questions
need to be asked any time a new technology or extensions of existing
technologies are being proposed for standardization over the Internet.
These questions need to be answered before a working group can be
chartered - it is up to the folks proposing a new charter to explain how
the operational aspects and the manageability of the IETF storage
protocols will be dealt with by the new WG. 

Dan