DRAFT Dallas minutes

Send comments and corrections to me.  This is also the
opportunity for any objections to the Sense of the room
decisions recorded below - they will become the rough
consensus of the IPS WG in the absence of objections.

Thanks,
--David

IP Storage (ips) WG Meeting Minutes - DRAFT
Monday, March 20, 1300-1500
Dallas, Texas
-----------------------------------

Administrivia, agenda bashing, draft status review, etc. - 15 min
		David L. Black, EMC (chair)
	Blue sheets
	Note Well
	Draft status:
	  - Most published as RFCs or in RFC Editor's queue
	  - iSNS MIB Last Call is done.  Minor revision needed to deal
			with comments from WG's MIB expert, should submit to
			ADs/IESG in next few months.
	  - Implementers Guide will probably go to WG Last call sometime
			in 2007.  It's ok for this to remain open for a
while.
	Milestones - see charter on web site.

iSCSI Implementer's Guide: Mallikarjun Chadalapaka, HP - 1 hour
	(draft-ietf-ips-iscsi-impl-guide-02.txt)

	Includes proposed revisions/extensions to SCSI task set management

	(1) Response Ordering issue - multiple connections may reorder
		responses from target to initiator.  Often not a problem but
		sometimes SCSI cares (e.g., multi-task abort, ACA).

	-> Proposed solution: Response Fence to tell iSCSI when response
		ordering is necessary.  Assume that it is always needed for
		multi-task management and ACA.  Would be part of SAM
interface
		to SCSI transport (task management attribute).
	Task management already requires this for multi-task operations,
		proposal is to generalize this in the specification so that
		it can be defined once, used in multiple places, and made
		available to T10 (SCSI standards org) to specify it in other
		places where it is needed.

	Discussion: This may be difficult to get into SAM-x via T10.
		There will be reluctance to deal with multiple connections
in
		a single session (I_T Nexus).

	Sense of the room: Response Fence will be added to implementers
guide
		as a general mechanism to deal with SCSI situations that
need
		it.  Say that ACA and multi-task management always need it.
		Can be discussed w/T10, but we're not relying on T10 to pick
		this up.

	(2) Task Management - Want to speed-up multi-task abort (ABORT TASK
		SET, and especially CLEAR TASK SET).  Currently have to wait
		for transfers to complete and status acks to come back.

	-> Proposed solution: Provide faster TMF completion by avoiding
		waits for other initiators and avoiding wait for other tasks
		on same initiator (requires new key to negotiate latter, as
		it involves sending per-LUN async events to cause early
		transfer teardown vs. current approach of waiting for
		transfers to 	complete).  Nop-out used to ack async events
		- can combine acks to these events into a single Nop-out.
		
	Sense of room: Clarifications are good - they will not introduce
		cross-nexus dependencies on the RESET task management
functions.

	Sense of the room: New key is useful - put it into draft, allow
responder
		to come back with Yes, No, or Not Understood.  SHOULD vs.
		MAY decision deferred until we have draft text reflecting
this.
		This new key may be related to new T10 data transfer abort
		service in SAM for SAS.

iSNS MIB: David Black (WG chair) for Scott Kipp, McData - 10 min
	(draft-ietf-ips-isns-mib-08.txt)

	Scope reduced to read-only monitoring of server only.

iSCSI X#NodeArchitecture Key: Dave Wysochanski, Network Appliance - 30 min
	(draft-wysochanski-xkey-iscsi-support-00.txt)

	Asking for a standard key to allow implementation to say what
version
		of software, etc. it is running.  It's easy to get log from
one's
		own product, but harder to get the log from the other side.

	Declarative key (each side declares it once and may not redeclare
it).

	Security - need to say that if confidentiality is an issue, use
IPsec.

	Long discussion of abuse, and need to use wording in the draft to
		discourage it.

	Decision: Draft accepted as WG draft, security and abuse text to be
		worked out, starting on list.  New milestone will be added
to
		charter.

Discovery Extension Discussion - John Hufferd, Brocade - 5 min
	Preference, dealing with multi-<something> environments containing
	things like InfiniBand and 10 Gigabit Ethernet

	Seems like a good thing, particularly for protocol flavor supported
	(iWarp, InfiniBand, etc.)

iSCSI Security Mechanisms: WG Members - time remaining (if any)

	The IETF Security Area has requested that IETF Working Groups plan
	to transition away from usage of MD5.  iSCSI CHAP currently uses
	MD5 in a fashion not directly threatened by the hash collision
	results known for MD5.  It's not clear what to do next - SHA-1
	has been registered for CHAP, SHA-256 has not, and RADIUS servers
	won't support either.  Perhaps something in EAP is appropriate.
	The question that needs to be answered is: What should the next
	iSCSI authentication mechanism be to supersede the current
	CHAP/MD5?


_______________________________________________
Ips mailing list
[email protected]
https://www1.ietf.org/mailman/listinfo/ips