Dallas minutes

These are the final minutes - the differences from the 
DRAFT version are primarily better explanations.

Having seen no comment on the mailing list, the items
labeled as "sense of the room" below are now the rough
consensus of the IPS Working Group.

Thanks
--David (IPS WG chair).

IP Storage (ips) WG Meeting Minutes
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 drafts are published as RFCs or are in the 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
protocol
		service invocation interface to SCSI transport.

	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 may be a reluctance to deal with multiple connections
		in a single SCSI 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 (can be done without change to
		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 - will look at combining
acks
		to these events on multiple LUNs for a single target into a
		single Nop-out.
		
	Sense of the room: Clarifications are good - they will not introduce
		cross-nexus dependencies on the RESET task management
functions.

	Sense of 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 - Mallikarjun will follow up with Rob
		Elliott (SAS expert).

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, *then*
		IPsec SHOULD be used.

	Long discussion of abuse (key used to trigger logic specific to
		implementation at other end - Javascript had serious
problems
		with this for browsers) and need to use wording in the draft
		to discourage such abuse.

	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.).  No decisions made - drafts will be
considered
	if/when they appear.

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?

	Note: Post-meeting followup - I took this topic up with the IETF
	Security Area Directors.  Their initial guidance is that the IETF
	Security Area would not look favorably on use of SHA-256 with CHAP,
	and they suggest use of SASL in preference to EAP.  SASL would also
	provide a means of cleaning up some issues around how the Kerberos
	and SPKM mechanisms are currently specified for iSCSI (RFC 3720).


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