Status of DLB's technical comments

[Black_David@emc.com]

Based on list discussion and what's now on Julian's
web site, here's what I think the status of my technical
comments are.  Most of these are resolved, and many thanks
to Julian for his patient slog through these.  At a high
level, I think T.6, T.15, T.38 and T.39 are still open
(see recent separate email on T.38 and T.39).  I think
T.9, T.12, and T.30 are resolved, but the resolutions
require technical changes to what's currently in the
working draft.  All the rest are resolved, in some
cases with editorial changes requested in the following
list:

T.1 - T.3.  Fixes are ok with me.

T.4 (2.2.6.3.1 .iqn - needs date unammbiguous) - Almost fixed.
	In the following text:

	     This date MUST be a date 
           during which the naming authority owned the domain name used 
           in this format, and SHOULD be the date on which the domain 
           name was acquired by this naming authority. 

	the requirement that the domain naming authority owned the
	domain name at 00:01 GMT needs to be subject to the MUST, so the
	new text would read:

	     This date MUST be a month in which domain name used in this
format
           was owned by the naming authority at 00:01 GMT on the first
           day of the month, and SHOULD be the first month for which this
           was the case.

T.5 (Synch and Steering bloated - for what we choose)
	New text is fine.  I sympathize with Julian's comment on the
	wasted effort here - *please* save that text, as it may be
	useful elsewhere (e.g., RDDP WG architecture document).

T.6 (Clarify text in 2.3 about discovery)
	I'm satisfied with the change of MAY to MUST with a list of
	the PDUs that are allowed on a discovery session, but whether
	to allow PDUs other than Send Targets and Logout on discovery
	sessions is an open issue.  I don't care about this issue - I
	just want to see the MUST with a small list of what's allowed.

T.7 (Portal defined by IP address does work through NAPT)
	No text change appears to have been made.  I agree that this
	is a model issue that does not affect protocol
	operation, but use of an IP address to identify
	a network portal does need to take account of NAPTs.  How about
	adding a statement that the IP addresses and TCP ports used to
	identify Network Portals are only assured to be valid identifiers
	within the containing Network Entity.  They may not be valid or
	unique elsewhere due to the possible presence of Network Address
	Translators, Network Address Port Translators, private networks,
	etc.

T.8 - Fix is ok with me.

T.9 (SCSI port name inapropriate)
	No change has been made to the working draft.  This should follow
	the agreement on the list to make the SCSI port name a string
	via conversion of ISID and TSIH to hex ASCII.  Not fixed, but
	the fix appears to have been agreed to on the list.  I agree with
	the comments on the list that the maximum string length of a
	SCSI port name should be 255 bytes.

T.10, T.11 - Fixes are ok with me.

T.12 (large-numerical-value does not cover lower than 2**64)
	List appears to have agreed that defining this in terms of
	allowed range rather than the actual value transmitted is
	the right thing to do.  I agree.

T.13 (clarify when 64k has to be supported)
	Text fix isn't quite right, as in using "e.g.", it fails to
	define "very long authentication items".  It needs to explicitly
	say that the only authentication methods that use very long
	authentication are the SPKM methods in Section 10.3, so the
	64k limit applies only when SPKM methods are offered or accepted
	on a connection.

T.14 - Fixes are ok with me.

T.15 (Make TPGT return on login MUST always)
	Changes made, but still open on the list, new working text
	contains some typos.

T.16 (Second connection issue)
	Section 4.3.4 change to use SHOULD is fine.  Swapping order of
	Sections 4 and 5 should remove the confusion about the text in
	the current Section 5.

T.17, T.18 - Fixes are ok with me.

T.19 (Conservative reuse in 8.1.1 SHOULD is appropriate)
	SHOULD is fine with me unless someone else wants to argue for MUST.

T.20, T.21 - Fixes are ok with me.

T.22 (Padding replace SHOULD with MUST be sent as 0)
	No change made - ok with me, consider this comment withdrawn.

T.23 and T.24 - Fixes are ok with me.

T.25 (Task reassign may need LUN)
	No change made.  Not adding the LUN is ok with me.

T.26 (Add Task Reassign to list of responses)
	Fix contains a typo, and the resulting list now contains all
	task management functions and hence could be replaced by a
	statement that the response is always sent.

T.27 - Fix is ok with me.

T.28 (Concern about discarding)
	Discussed on list, issue turned out to be editorial.  Picking up
	latest text based on Mallikarjun's modification of my proposed
	new text will resolve this.

T.29 - Fix is ok with me.

T.30 (Resegmenting may come as a surprize - suggested a different request)
	Ouch - the new SNACK type code was inserted in the middle of the
	sequence making this change not backwards compatible with earlier
	versions. 	Please use 3 for the new R-Data SNACK and leave 0, 1
	and 2 unchanged from -14.

	I am ok with the Initiator deciding whether it needs a new
	Response and using the existing Status SNACK mechanism to get it -
	that's definitely cleaner than my proposed abuse of the service
	response code.  The current working draft uses a MAY for the
	initiator requesting a status retransmit - I prefer Mallikarjun's
	proposal on the list that the initiator MUST discard the first
	Response PDU and MUST use a Status SNACK to get one that is certain

	to reflect any resegmentation.  I still disagree with Mallikarjun
	about the new R-Data SNACK type code - I would prefer to see this
	code used so that the initiator is clearly aware that it is in a
	situation where it MUST request status retransmission.  Getting
	this wrong risks returning incomplete data on a READ.

T.31 (Operational Error Level instead of supported)
	Fixed text is ok with me.  There may be an open issue on the list
	concerning whether some sort of "ErrorRecoveryLevel 0.5" is
permitted.

T.32 - T.36 - Fixed text is ok with me.

T.37 (Unsolicited data inclarity)
	Julian says "Already spec'd in 2.2.4", and it is.  Please add
	references to Section 2.2.4 to the descriptions of the InitialR2T
	and BidiInitialR2T keys.  This will be particularly effective if
	Section 2.2.4 is split into subsections as Brian Forbes has
suggested.

T.38 (IANA Text)
	Fixed text is ok, but will cause port 3260 to be abandoned by iSCSI
	for a port to be assigned by IANA at some indefinite time in the
	future.  As I said in the comment, I think sticking with 3260 is
	better.  I'll send a separate email to raise this issue on the list.

T.39 (IANA registry for keys)
	Yes, this or something is needed, otherwise two vendors might
	assign different meanings to the value CRC64K resulting in
	a nasty interoperability failure.

	I just realized that we have a key namespace usage issue and
	possible key value namespace usage issues.  Separate post coming
	on this topic.

Thanks,
--David
	
---------------------------------------------------
David L. Black, Senior Technologist
EMC Corporation, 42 South St., Hopkinton, MA  01748
+1 (508) 249-6449            FAX: +1 (508) 497-8018
black_david@emc.com       Mobile: +1 (978) 394-7754
---------------------------------------------------