[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Google
  Web www.spinics.net

STORM BOF - Draft minutes



See below - these are a bit on the long side, as a lot of
ground was covered in the BOF.  Many thanks to Paul Koning
for helping to take notes.

We did not actually have a jabber scribe providing running
commentary in the jabber room - the assumption/hope was that
everyone in the jabber room was listening to the audio feed.
If that was a bad assumption, please send me an email
directly, and we'll do better in the future.

The overall conclusion of the BOF is that a new STORM
(STORage Maintenance) WG should be formed to pursue
essentially the program of work in the draft charter that
I sent to the lists earlier.  There will be a new
storm@xxxxxxxx mailing list for this WG.

As all decisions in IETF meetings are confirmed on mailing
lists, now is the time to speak up if:
- anyone thinks that a WG should not be formed, or
- anyone thinks that one or more of the work items on the
	draft charter (see minutes) should not be done.
I will also be contacting some people directly to try to
ensure that there is at least one Internet-Draft author
for each work item.

Please also provide any other corrections to the minutes
(either to the list or directly to me).

Thanks,
--David


Transport Area (TSV) BOF: STORM (STORage Maintenance)
THURSDAY, March 26, 2009, 0900-1130 Morning Session I
IETF San Francisco Meetings
=======================================================

BOF chair: David L. Black, EMC (black_david@xxxxxxx)

Minutes - Initial Draft
----------------------

--- Administrivia ----
  - Note Well (projected)
  - Blue Sheets (circulated)
  - Scribes (minutes, jabber)
	Jabber room was initially not functioning, but was fixed shortly
	after BOF started
  - Purpose of BOF: Question #1: Should an IETF WG be formed?

--- Agenda Bashing ---
Agenda was bashed to add discussion of possibly related work in T11
(Fibre Channel Standards Organization).  The T11 vice chair (and acting
chair) was present to discuss the item.

-- Draft charter: Initial presentation ---
Charter presented, no text bashed.

Discussion of possible iSCSI-related work
  - Consolidated iSCSI RFC
  - Whether to take iSCSI to Draft Standard status, including
	implementation report
  - SAM-4 feature addition

Extensive discussion indicated clear strong interest in the SAM-4
feature addition and interest in consolidating the iSCSI RFCs into a
single document that could go to Draft Standard status.  The resulting
plan is to have two drafts:
	1) An rfc3720bis draft that consolidates and prunes the
	   current iSCSI RFCs based on current implementations.  The
	   intent is that this draft be suitable for Draft Standard
status.
	2) A "new features" draft that adds (in a backwards compatible
	   fashion) minor new features, starting with the new SAM-4
	   features. This draft would be intended for Proposed Standard
	   status, and all of its contents would be optional and
negotiable
	   (e.g., via text keys at iSCSI login).
The "new features" draft would not be limited to SAM-4 features, but all
additions would need to be minor.  IETF procedures would allow
everything
to be rolled into one document that could be taken to Draft Standard
status after a 6 month waiting period at Proposed Standard, but the
sense
of the discussion was that the above two-document plan is the better
course of action, and that only widely implemented features in current
implementations should be considered for a Draft Standard RFC.

The BOF chair prefers that the decision as to whether to take iSCSI to
Draft Standard status be deferred, and will write charter text to allow
this, but not require it.  Among the reasons for this are the amount of
work involved and potential interactions with other RFC documents that
are currently at Proposed Standard status.

It seems to make better sense to specify iSCSI support for all new
SAM-4 features (as other SCSI transports, such as FCP [SCSI over Fibre
Channel] and SAS [Serial Attach SCSI]) have done, rather than only
specify selected SAM-4 features.  iSCSI could then define multiple text
keys to allow support for these features (or groups of them) to be
separately negotiated.

IETF coordination with T10 is planned to be handled informally.  At
least David Black (BOF chair) and Fred Knight (one of the presenters on
the SAM-4 topic) are active T10 participants who can facilitate this
coordination.  The formal IETF mechanisms for liaison with other
organizations appear unlikely to be needed.

--- FC encapsulation-related work (possible) ---
  - iFCP Address Translation obsolescence
  - FC(IP) IP Protocol Number

Both of these appear to be good ideas.  The BOF chair is prepared to
write the Internet-Draft for the first item, and the second item is
for the WG to investigate whether IP Protocol number 133 (allocated
for Fibre Channel in 2000) is unused and should be returned to IANA
for future reassignment.

	- Related T11 activity (RDDP over Ethernet)

T11 is the standards organization for Fibre Channel. A proposal has
been submitted to T11 for it to work on hosting the RDDP (aka iWARP)
protocols on Ethernet directly via IP, see T11 document 09-141v0:
	http://www.t11.org/ftp/t11/admin/project_proposals/09-141v0.pdf

The design proposed in that document appears to require allocation of
an IP Protocol number.  That can only be done by the IESG, and appears
unlikely, as the proposed DCRP protocol is not intended to run over
public networks like the Internet, has no congestion control and no
security.  UDP encapsulation may be a more plausible way forward, but
there is a track record of protocols intended for closed networks
"escaping" into the broader Internet.

The BOF chair (David Black) is also a member of the IETF Transport
Directorate and a T11 participant - he will take these concerns to the
T11 meetings next week and express a desire for significant consultation
between T11 and the IETF before T11 moves this work moves forward.
The responsible Transport AD (Lars Eggert) concurs with and supports
this course of action.

--- RDDP-related work (possible) ---
  - MPA startup change for MPI

There has been a lot of support for this relatively contained
proposed work item on the mailing list.

--- iSER-related work (possible) ---
  - Clarifications arising from InfiniBand and other use of iSER

There has been support on the mailing list for this proposed work
item.

--- Any other proposed work items ---
Nothing additional proposed.

--- Draft charter: Text bashing, round 2 ---
No further bashing.

--- WG formation discussion  ---
Clear interest in forming a WG, with a desire to limit travel.

Work item discussion took a bit longer.  Different people are
interested in different work items.  A discussion of whether any
work items should be deleted from the initial list in the charter
did not identify any to be deleted, but acknowledged the BOF chair's
preference to not have the charter commit up front to taking iSCSI
to Draft Standard status.  With that change, the "rough consensus"
of the meeting (supported by some comments in the jabber room and
emails sent to the list) is that a WG should be formed to take on
essentially the plan of work in the draft charter.

Discussion about travel and meetings reflected a concern about
travel in current economic conditions and a desire to conduct as
much work as possible on the mailing list.  Beyond that, face-to-
face meetings are sometimes needed to resolve issues and make
progress - in line with current IETF practice, if a meeting is
needed during an IETF meeting week, it'll be scheduled without
significant consideration of where that IETF meeting is located.
The expected default for the WG will be to not meet face-to-face
unless there are clear issues that require a meeting.

Interim meetings were suggested as a possibility, but there does
not appear to be a geographic concentration of interested people;
the BOF chair is aware of likely participants on both coasts of
the US, China, Switzerland and Israel.  Iceland was half-heartedly
suggested as approximately equally inconvenient for all concerned.

--- Mailing List Usage ---

Organization of the BOF was conducted on the existing ips@xxxxxxxx
and rddp@xxxxxxxx mailing lists, with the imss@xxxxxxxx list cc:'d.

After some discussion, the mailing list plan going forward is:
- Form new storm@xxxxxxxx mailing list for new STORM WG.
- Announce this list on the IMSS, IPS and RDDP lists, inviting
	people to subscribe to the new STORM list.
- No further STORM-related activity on the IMSS list after this
	announcement (and perhaps a few reminders).
- Set IPS and RDDP auto-responders to indicate existence of STORM
	list.
- After some period of time, close down the RDDP list, ask the
	IETF secretariat to set up an auto-responder for email to
	rddp@xxxxxxxx indicating that storm@xxxxxxxx should be used.
- Leave IPS list open with auto-responders modified as above.
- Leave IMSS list as it currently is.

--- Milestones ---
In order to have a charter that can be approved, milestones are
needed.  A small amount of discussion yielded the following guidelines:
- Small stuff  (e.g., MPA fix) should make it to Working Group Last Call
	(WG LC) this year
- Other larger things (e.g., SAM-4) may need until latter part of next
	year to reach WG LC.
- iSCSI: The consolidated iSCSI draft may be a 2 year project, but there
	should be a decent draft in about 1 year.
- The charter will allow lazy evaluation of decision about whether to
	take iSCSI to Draft Standard, and hence not propose any
milestones
	for that.

--- Next steps ---
- BOF chair to revise charter (with milestones) and send to mailing
	lists for review.
- Assuming no significant objections to WG creation are raised, the
	secretariat will be asked to create a storm@xxxxxxxx mailing
list.
- The actual storm WG formation request will probably go to the Area
	Director (Lars) for presentation to the IESG in about a month.

14 names on blue sheet, about 8 additional jabber room participants.
_______________________________________________
Ips mailing list
Ips@xxxxxxxx
https://www.ietf.org/mailman/listinfo/ips

[IETF]     [Linux iSCSI]     [Linux SCSI]     [Linux Resources]     [Yosemite News]     [IETF Announcements]     [IETF Discussion]     [SCSI]

Add to Google Powered by Linux