From owner-ips@ece.cmu.edu Mon Jul 1 01:23:42 2002 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA22251 for ; Mon, 1 Jul 2002 01:23:42 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id g614Ng213046 for ips-outgoing; Mon, 1 Jul 2002 00:23:42 -0400 (EDT) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from siaar1ab.compuserve.com (siaar1ab.compuserve.com [149.174.40.10]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id g614Hkw12850 for ; Mon, 1 Jul 2002 00:17:46 -0400 (EDT) Received: (from mailgate@localhost) by siaar1ab.compuserve.com (8.9.3/8.9.3/SUN-REL-1.3) id AAA27058 for ips@ece.cmu.edu; Mon, 1 Jul 2002 00:17:39 -0400 (EDT) Received: from EGRodriguez (dal-tgn-tkd-vty1.as.wcom.net [206.175.233.1]) by siaar1ab.compuserve.com (8.9.3/8.9.3/SUN-REL-1.3) with ESMTP id AAA26990; Mon, 1 Jul 2002 00:17:30 -0400 (EDT) From: "Elizabeth Rodriguez" To: Cc: "'David Black'" , , Subject: Editorial comments on security draft. Date: Sun, 30 Jun 2002 23:14:39 -0600 Message-ID: <001201c220be$35de4770$01e9afce@EGRodriguez> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0013_01C2208B.EB43D770" X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.3416 Importance: Normal x-mimeole: Produced By Microsoft MimeOLE V6.00.2600.0000 Sender: owner-ips@ece.cmu.edu Precedence: bulk This is a multi-part message in MIME format. ------=_NextPart_000_0013_01C2208B.EB43D770 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit Here are my comments on the security draft. Elizabeth Acronym SPI not defined. [First used at bottom of pg 5] NCITS has officially changed its name to INCITS (InterNational Committee for Informational Technology Standards) [Section 1.5, Fibre Channel definition, bottom of pg 6] FCIP definition centers on SANs. FC/FCIP are not storage/SAN specific. Not sure how to address/how important it is to address, since it is true that a majority of FC is storage centric. Maybe either in FCIP definition or in FCIP overview, note that the focus of this document is storage, but that FCIP may transport not FCP frames? [1.3 FCIP overview, pg. 5; 1.5 FCIP definition, pg 7] Typo: two spaces between Conformant & IP [Section 2.3.2, pg. 12] Typo: addreses - should be addresses. [Section 2.3.3; third line of pg 13] Typo: vulnerabile - should be vulnerable [Section 2.3.3; fourth line of pg 13] Typo: intiating - should be initiating [Section 2.3.4; 6th line in paragraph above bullet [4], pg. 15] Typo: double 'the' [Section 2.3.4; 1st line of bullet [4], pg 15] Typo: double 'the' [Section 2.5.1; 3rd line of bullet [g], pg. 19] Typo: double 'the' [Section 2.5.1; 3rd line of bullet [h], pg 20] Typo: double 'the' [Section 2.5.1; 3rd line of bullet [i], pg 20] Suggested rewording: [Section 2.5.3, 1st full paragraph on pg. 22] Current: "Use of IPsec for SLPv2 security has advantages over SLPv2 authentication as defined in [RFC2608], which does not provide a way to authenticate "zero result responses", leaving SLPv2 vulnerable to a denial of service attack." This sentence was confusing to me. Suggested rewording to Use of IPsec for SLPv2 security has advantages over SLPv2 authentication as defined in [RFC2608]. The latter does not provide a way to authenticate "zero result responses", which leaves SLPv2 vulnerable to a denial of service attack." Typo: double 'could' [Section 2.6; 2nd line of bullet [2], pg. 22] Typo: desireable - Should be desirable. [Section 2.6, Third line of bullet [a], pg 23] Consistency: IPSec instead of IPsec used in several places, beginning in Section 2.6.1 [Section 2.6.1; 3rd paragraph of page 24, 3rd line] [Section 2.6.1; 5th paragraph of page 24, 3rd line] [Section 2.6.2; 2nd to last line of 1st paragraph of section, pg 24] [Section 2.6.2; 1st line of 2nd paragraph of section, pg 24] Typo: addreses - should be addresses [Section 2.6.4; 2nd to last line of 1st paragraph on pg. 26] Typo: desireable - should be administrative [Section 5.1.1; bullet [1], 2nd line, pg. 36 Typo: Gbs - should be Gbps [Section 5.4, 2nd paragraph, 4th line, pg 37] Typo: Thuss - should be Thus [Section 5.4; 2nd to last paragraph on pg 38, 3rd to last line] Typo: intial - should be initial. [Section 5.6; 2nd paragraph, 2nd line on page 42] Typo: Space between Kent & S. [[RFC 2406], pg. 48] Update iFCP reference to draft 12; the WG last call version [[iFCP], pg 49] Update FCIP reference to draft 11; the WG last call version. [[FCIP], pg. 49] I know the above two are listed as WIP, but since they have completed WG last call, probably should update their references to the versions that will go to the IESG. Typo: cut & paste error ", which includes support for bi-directional authentication" between "(work in" and "progress)" Typo: et.al. - should be et al. (there is currently a period between et & al) [[iSCSIName], pg 49] Typo: Split draft name with ", which includes support for bi-directional authentication" [[iSCSIName], pg 49] Typo: Split draft name with ", which includes support for bi-directional authentication" [[iSCSISLP], pg 49] Typo: Space between Kent & S. [[RFC 2402], pg. 50] Typo: Extra space after Gulbrandsen and extra '.' and space before Vixie.[[RFC 2782], pg. 50] Typo: et.al. - should be et al. (there is currently a period between et & al) [[iSCSIREQ], pg 50] Update iSCSIREQ reference to draft 6, the IESG last call version. Typo: implementers - should be implementers [Intellectual Property Statement] Also, would seem to me that we would need the IPR boilerplate "The IETF has been notified of intellectual property rights claimed in regard to some or all of the specification contained in this document. For more information consult the online list of claimed rights." Taken from section 10.4 (D) of RFC 2026. Instead of the IPR statement already in the document? ------=_NextPart_000_0013_01C2208B.EB43D770 Content-Type: text/html; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable

 

Here are my comments on the security = draft.

 

Elizabeth

 

 

Acronym SPI not defined.  [First used at bottom = of pg 5]

 

NCITS has officially changed its name to INCITS = (InterNational Committee for Informational Technology Standards)  [Section 1.5, = Fibre Channel definition, bottom of pg 6]

 

FCIP definition centers on SANs.  FC/FCIP are = not storage/SAN specific.  Not sure how to address/how important it is = to address, since it is true that a majority of FC is storage = centric.

Maybe either in FCIP definition or in FCIP overview, = note that the focus of this document is storage, but that FCIP may transport = not FCP frames?  [1.3 FCIP overview, pg. 5; 1.5 FCIP definition, pg = 7]

 

Typo:  two spaces between Conformant & IP = [Section 2.3.2, pg. 12]

 

Typo:  addreses – should be = addresses.  [Section 2.3.3; third line of pg 13]

 

Typo:  vulnerabile – = should be vulnerable [Section 2.3.3; fourth line of pg 13]

 

Typo:  intiating – = should be initiating [Section 2.3.4; 6th line in paragraph above bullet = [4], pg. 15]

 

Typo: double ‘the’ [Section 2.3.4; = 1st line of bullet [4], pg 15]

 

Typo: double ‘the’ [Section 2.5.1; = 3rd line of bullet [g], pg. 19]

 

Typo:  double ‘the’ [Section 2.5.1; = 3rd line of bullet [h], pg 20]

 

Typo:  double ‘the’ [Section 2.5.1; = 3rd line of bullet [i], pg 20]

 

Suggested rewording:  [Section 2.5.3, = 1st full paragraph on pg. 22]

Current: = “Use of IPsec for SLPv2 security has advantages over SLPv2 authentication as = defined in [RFC2608], which does not provide a way to authenticate "zero = result responses", leaving SLPv2 vulnerable to a denial of service = attack.” 

This sentence was confusing to me.  = Suggested rewording to

Use of IPsec for SLPv2 security has = advantages over SLPv2 authentication as defined in [RFC2608].  The latter does not = provide a way to authenticate "zero result responses", which leaves = SLPv2 vulnerable to a denial of service attack.”  =

 

Typo:  double ‘could’ [Section 2.6; = 2nd line of bullet [2], pg. 22]

 

Typo:  desireable – = Should be desirable. [Section 2.6, Third line of bullet [a], pg = 23]

 

Consistency:  IPSec instead of IPsec used in = several places, beginning in Section 2.6.1

         =    [Section 2.6.1; 3rd paragraph of page 24, 3rd = line]

         =    [Section 2.6.1; 5th paragraph of page 24, 3rd = line]

         =    [Section 2.6.2; 2nd to last line of 1st paragraph of section, pg = 24]

         =    [Section 2.6.2; 1st line of 2nd paragraph of section, pg = 24]

 

Typo: addreses – should be addresses [Section = 2.6.4; 2nd to last line of 1st paragraph on pg. 26]

 

Typo: desireable – = should be administrative [Section 5.1.1; bullet [1], 2nd line, pg. = 36

 

Typo: Gbs – should be Gbps [Section 5.4, = 2nd paragraph, 4th line, pg 37]

 

Typo: Thuss – should be Thus [Section 5.4; = 2nd to last paragraph on pg 38, 3rd to last = line]

 

Typo:  intial – = should be initial.  [Section 5.6; 2nd paragraph, 2nd = line on page 42]

 

Typo: Space between Kent & = S. [[RFC 2406], pg. 48]

 

Update iFCP reference to draft 12; the WG last call = version [[iFCP], pg 49]

 

Update FCIP reference to draft 11; the WG last call = version. [[FCIP], pg. 49]

 

I know the above two are listed as WIP, but since = they have completed WG last call, probably should update their references to the = versions that will go to the IESG.

 

Typo: cut & paste error “, = which includes support for bi-directional authentication” between = “(work in” and “progress)”

 

Typo:  et.al. – should be et al. (there is currently a period between et & al) [[iSCSIName], pg = 49]

 

Typo:  Split draft name with “, which = includes support for bi-directional authentication” [[iSCSIName], pg = 49]

 

Typo:  Split draft name with “, which = includes support for bi-directional authentication” [[iSCSISLP], pg 49]

 

Typo: Space between Kent & = S. [[RFC 2402], pg. 50]

 

Typo:  Extra space after Gulbrandsen  and = extra ‘.’ and space before Vixie.[[RFC 2782], pg. 50]

 

Typo:  et.al. – should be et al. (there is = currently a period between et & al) [[iSCSIREQ], pg 50]

 

Update iSCSIREQ reference to draft 6, the IESG last = call version.

 

Typo:  implementers – should be = implementers [Intellectual Property Statement]

 

Also, would seem to me that we would need the IPR boilerplate

 

"The IETF has = been notified of intellectual property rights

claimed in regard = to some or all of the specification contained

in this = document.  For more information consult the online list

of claimed = rights."

 

Taken from section = 10.4 (D) of RFC 2026.

 

Instead of the IPR statement already in the = document?

 

 

------=_NextPart_000_0013_01C2208B.EB43D770-- From owner-ips@ece.cmu.edu Mon Jul 1 04:04:56 2002 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA09855 for ; Mon, 1 Jul 2002 04:04:56 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id g617NQ817585 for ips-outgoing; Mon, 1 Jul 2002 03:23:26 -0400 (EDT) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from d12lmsgate-3.de.ibm.com (d12lmsgate-3.de.ibm.com [195.212.91.201]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id g617NPw17581 for ; Mon, 1 Jul 2002 03:23:25 -0400 (EDT) Received: from d12relay01.de.ibm.com (d12relay01.de.ibm.com [9.165.215.22]) by d12lmsgate-3.de.ibm.com (8.12.3/8.12.3) with ESMTP id g617NI2F020244; Mon, 1 Jul 2002 09:23:18 +0200 Received: from d10hubm1.telaviv.ibm.com (d10ml001.telaviv.ibm.com [9.148.216.55]) by d12relay01.de.ibm.com (8.11.1m3/NCO/VER6.1) with ESMTP id g617NHu60536; Mon, 1 Jul 2002 09:23:17 +0200 To: internet-drafts@ietf.org Cc: ips@ece.cmu.edu MIME-Version: 1.0 Subject: iSCSI version 14 draft X-Mailer: Lotus Notes Release 5.0.9 November 16, 2001 From: "Julian Satran" Message-ID: Date: Mon, 1 Jul 2002 10:23:15 +0300 X-MIMETrack: Serialize by Router on D10ML001/10/M/IBM(Release 5.0.9a |January 7, 2002) at 01/07/2002 10:23:17, Serialize complete at 01/07/2002 10:23:17 Content-Type: multipart/alternative; boundary="=_alternative 001D6EEFC2256BE9_=" Sender: owner-ips@ece.cmu.edu Precedence: bulk This is a multipart message in MIME format. --=_alternative 001D6EEFC2256BE9_= Content-Type: text/plain; charset="us-ascii" On behalf of the team of authors and as part of the IETF-IPS working group I submit a draft for immediate publication. The text and pdf versions can be found at: http://www.haifa.il.ibm.com/satran/ips/draft-ietf-ips-iscsi-14.txt http://www.haifa.il.ibm.com/satran/ips/draft-ietf-ips-iscsi-14.pdf This version completely replaces: draft-ietf-ips-iscsi-13.txt and pdf Julian Satran - IBM Research Laboratory at Haifa --=_alternative 001D6EEFC2256BE9_= Content-Type: text/html; charset="us-ascii"

On behalf of the team of authors and as part of the IETF-IPS working group
I submit a draft for immediate publication.

The text and pdf versions can be found at:

http://www.haifa.il.ibm.com/satran/ips/draft-ietf-ips-iscsi-14.txt

http://www.haifa.il.ibm.com/satran/ips/draft-ietf-ips-iscsi-14.pdf


This version completely replaces:

draft-ietf-ips-iscsi-13.txt and pdf



Julian Satran - IBM Research Laboratory at Haifa



























--=_alternative 001D6EEFC2256BE9_=-- From mailman-owner@ietf.org Mon Jul 1 05:09:12 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA13053 for ; Mon, 1 Jul 2002 05:09:12 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id FAA00015 for ; Mon, 1 Jul 2002 05:09:59 -0400 (EDT) Date: Mon, 1 Jul 2002 05:09:59 -0400 (EDT) Message-Id: <200207010909.FAA00015@optimus.ietf.org> From: mailman-owner@ietf.org Subject: ietf.org mailing list memberships reminder To: ips-archive@ietf.org X-No-Archive: yes Precedence: bulk X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol This is a reminder, sent out once a month, about your ietf.org mailing list memberships. It includes your subscription info and how to use it to change it or unsubscribe from a list. You can visit the URLs to change your membership status or configuration, including unsubscribing, setting digest-style delivery or disabling delivery altogether (e.g., for a vacation), and so on. In addition to the URL interfaces, you can also use email to make such changes. For more info, send a message to the '-request' address of the list (for example, ips-request@ietf.org) containing just the word 'help' in the message body, and an email message will be sent to you with instructions. ****************************************************************** Note Well All statements related to the activities of the IETF and addressed to the IETF are subject to all provisions of Section 10 of RFC 2026, which grants to the IETF and its participants certain licenses and rights in such statements. Such statements include verbal statements in IETF meetings, as well as written and electronic communications made at any time or place, which are addressed to * the IETF plenary session, * any IETF working group or portion thereof, * the IESG, or any member thereof on behalf of the IESG, * the IAB or any member thereof on behalf of the IAB, * any IETF mailing list, including the IETF list itself, any working group or design team list, or any other list functioning under IETF auspices, * the RFC Editor or the Internet-Drafts function Statements made outside of an IETF meeting, mailing list or other function, that are clearly not intended to be input to an IETF activity, group or function, are not subject to these provisions. ****************************************************************** If you have questions, problems, comments, etc, send them to mailman-owner@ietf.org. Thanks! Passwords for ips-archive@lists.ietf.org: List Password // URL ---- -------- ips@ietf.org INMn https://www1.ietf.org/mailman/options/ips/ips-archive@lists.ietf.org From owner-ips@ece.cmu.edu Mon Jul 1 08:45:57 2002 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA01685 for ; Mon, 1 Jul 2002 08:45:57 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id g61C4iw11606 for ips-outgoing; Mon, 1 Jul 2002 08:04:44 -0400 (EDT) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from mail.ivivity.com ([64.238.111.99]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id g61C4gw11599 for ; Mon, 1 Jul 2002 08:04:42 -0400 (EDT) Received: by ATLOPS with Internet Mail Service (5.5.2653.19) id ; Mon, 1 Jul 2002 08:04:42 -0400 Message-ID: From: Eddy Quicksall To: Julian Satran , pat_thaler@agilent.com Cc: ips@ece.cmu.edu, nramamur@npd.hcltech.com, pat_thaler@agilent.com, rsnively@Brocade.COM Subject: Recall: iSCSI: FirstBurstSize and unsolicited data Date: Mon, 1 Jul 2002 08:04:41 -0400 Expiry-Date: Wed, 3 Jul 2002 08:04:37 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain Sender: owner-ips@ece.cmu.edu Precedence: bulk Eddy Quicksall would like to recall the message, "iSCSI: FirstBurstSize and unsolicited data". From owner-ips@ece.cmu.edu Mon Jul 1 08:46:47 2002 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA01713 for ; Mon, 1 Jul 2002 08:46:46 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id g61C45D11569 for ips-outgoing; Mon, 1 Jul 2002 08:04:05 -0400 (EDT) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from mail.ivivity.com ([64.238.111.99]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id g61C43w11565 for ; Mon, 1 Jul 2002 08:04:03 -0400 (EDT) Received: by ATLOPS with Internet Mail Service (5.5.2653.19) id ; Mon, 1 Jul 2002 08:03:47 -0400 Message-ID: From: Eddy Quicksall To: Julian Satran , pat_thaler@agilent.com Cc: ips@ece.cmu.edu, nramamur@npd.hcltech.com, pat_thaler@agilent.com, rsnively@Brocade.COM Subject: RE: iSCSI: FirstBurstSize and unsolicited data Date: Mon, 1 Jul 2002 08:03:45 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C220F7.59C61580" Sender: owner-ips@ece.cmu.edu Precedence: bulk This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_001_01C220F7.59C61580 Content-Type: text/plain; charset="iso-8859-1" I think something should be said. It can be short and sweat. Eddy -----Original Message----- From: Julian Satran [mailto:Julian_Satran@il.ibm.com] Sent: Tuesday, June 25, 2002 2:59 AM To: pat_thaler@agilent.com Cc: ips@ece.cmu.edu; nramamur@npd.hcltech.com; pat_thaler@agilent.com; rsnively@Brocade.COM Subject: RE: iSCSI: FirstBurstSize and unsolicited data Pat, Do you think we should make the position of the initial data expliciit (i.e., add text) where this seems obvious? Julo pat_thaler@agilent.com 06/25/2002 02:30 AM Please respond to pat_thaler To: rsnively@brocade.com, pat_thaler@agilent.com, nramamur@npd.hcltech.com, Julian Satran/Haifa/IBM@IBMIL cc: ips@ece.cmu.edu Subject: RE: iSCSI: FirstBurstSize and unsolicited data Robert, I think there should be a restriction but it isn't as broad as requiring DataSequenceInOrder = Yes. The necessary and sufficient requirements are (I think): When immediate data is sent, it MUST begin with the first byte of the data transfer - rationale: there is no mechanism such as DataSN in the SCSI Command PDU to indicate position of the immediate data so it must have an implied position. When unsolicited non-immediate data is sent, there is an implied R2T for the first n bytes of data where n = min(Expected Data Transfer Length, FirstBurstSize) This implied R2T is to be satisfied by the immediate data plus unsolicited SCSI Data-out PDUs. As above, any immediate data must begin with the first byte of the data transfer. If DataSequenceInOrder=No, then the data in the unsolicited SCSI Data-out PDUs MAY be in any order but MUST be the bytes that satisfy the implied R2T (that is, the first n bytes of the data). rationale: Since the R2T is implied, it doesn't have an explicit position and must have an implicit position. I don't think these requirements are articulated in the draft. Pat -----Original Message----- From: Robert Snively [mailto:rsnively@brocade.com] Sent: Monday, June 24, 2002 2:30 PM To: 'THALER,PAT (A-Roseville,ex1)'; Nandakumar Ramamurthy; Julian Satran Cc: ips@ece.cmu.edu Subject: RE: iSCSI: FirstBurstSize and unsolicited data I must have missed something in the document. I did not see any restriction that required EMDP = 0 (or in iSCSI-ese, DataSequenceInOrder = yes) when immediate data was transmitted. I would have expected such a requirement. If that is not the case, then any data can be transmitted first and any data can be requested with the first (overlapping) R2T, somewhat confusing the issue. If someone can point me to that restriction, I would be delighted. Bob -----Original Message----- From: THALER,PAT (A-Roseville,ex1) [mailto:pat_thaler@agilent.com] Sent: Friday, June 21, 2002 9:46 AM To: Nandakumar Ramamurthy; Julian Satran Cc: ips@ece.cmu.edu Subject: RE: iSCSI: FirstBurstSize and unsolicited data Nandakumar, There are no restrictions on the amount of immediate data sent other than that it must be less than MaxRecvDataSegmentLength and less than FirstBurstSize. So in the conditions you have chosen, the initiator could send any amount of ImmediateData from 4 Bytes to 8 KB. Doing so should not cause an error at the target. The purpose of allowing an implicit InitialR2T is to gain efficiency by letting data start flowing without having to wait a round-trip delay for an R2T. Gaining this efficiency requires that the target know how much unsolicited data will be sent when it receives the SCSI Command PDU so that it can immediately send the first explicit R2T. The rule on sending the full FirstBurstSize (or all the data) when unsolicited data is sent in Data-out PDUs achieves this. When the target sees the SCSI Command PDU with the F bit set to 0, it knows that the first data it needs to request with an R2T starts after FirstBurstSize bytes. When the SCSI Command PDU has an F bit set to 1, then the target knows that DataSegmentLength is the amound of unsolicited data being sent and it can construct its first R2T. Therefore there is no reason to restrict the amount of unsolicited data sent when only immediate data is sent (other than that it not exceed the maximums). That is what is reflected in the rules. Pat -----Original Message----- From: Nandakumar Ramamurthy [mailto:nramamur@npd.hcltech.com] Sent: Friday, June 21, 2002 1:36 AM To: Julian Satran Cc: ips@ece.cmu.edu Subject: Re: iSCSI: FirstBurstSize and unsolicited data Hi, I have been following the discussion on this thread. I still have certain doubts regarding the conditions I specified in my original mail. The conditions are : FirstBurstSize = 64KB EDTL = 100KB ( EDTL > FirstBurstSize) MaxRecvDataSegmentLength = 8KB ImmediateData = Yes InitialR2T = Yes In the above case the initiator cannot send unsolicited Data-out PDUs. Here unsolicited data(ImmediateData) < FirstBurstSize. Will the target report any error in this case? The modified text for Section 9.4.6.2 only refers to the cases where unsolicited Data-outs can be sent. Please clarify if I am missing something very obvious. Thanks, Nandakumar Member Technical Staff HCL Technologies, Chennai, INDIA. http://san.hcltech.com ----- Original Message ----- From: Julian Satran To: Eddy Quicksall Cc: ips@ece.cmu.edu Sent: Friday, June 21, 2002 11:41 AM Subject: RE: iSCSI: FirstBurstSize and unsolicited data Eddy, I assume you meant EDTL not DSL and then the answer is yes and I again forgot to subtract the immediate. A better formulation would be: The target reports the "Incorrect amount of data" condition if dur-ing data output the total data length to output is greater than First-BurstSize and the initiator sent unsolicited non-immediate data but the total amount of unsolicited data is different than FirstBurst-Size. The target reports the same error when the amount of data sent as a reply to an R2T does not match the amount requested. Julo "Eddy Quicksall" 06/21/2002 12:22 AM Please respond to "Eddy Quicksall" To: Julian Satran/Haifa/IBM@IBMIL cc: Subject: RE: iSCSI: FirstBurstSize and unsolicited data Isn't this saying that if DSL > FirstBurstSize, it would be incorrect to send non-immediate unsolicited which is not equal to FirstBurstSize? The target reports the "Incorrect amount of data" condition if dur-ing data output the total data length to output is greater than First-BurstSize, but the initiator sent an amount different than FirstBurstSize of unsolicited non-immediate data or the amount of data sent as a reply to an R2T does not match the amount requested. Eddy ------_=_NextPart_001_01C220F7.59C61580 Content-Type: text/html; charset="iso-8859-1"
I think something should be said. It can be short and sweat.
 
Eddy
-----Original Message-----
From: Julian Satran [mailto:Julian_Satran@il.ibm.com]
Sent: Tuesday, June 25, 2002 2:59 AM
To: pat_thaler@agilent.com
Cc: ips@ece.cmu.edu; nramamur@npd.hcltech.com; pat_thaler@agilent.com; rsnively@Brocade.COM
Subject: RE: iSCSI: FirstBurstSize and unsolicited data


Pat,

Do you think we should make the position of the initial data expliciit (i.e., add text) where this seems obvious?

Julo


pat_thaler@agilent.com

06/25/2002 02:30 AM
Please respond to pat_thaler

       
        To:        rsnively@brocade.com, pat_thaler@agilent.com, nramamur@npd.hcltech.com, Julian Satran/Haifa/IBM@IBMIL
        cc:        ips@ece.cmu.edu
        Subject:        RE: iSCSI: FirstBurstSize and unsolicited data

       


Robert,
 
I think there should be a restriction but it isn't as broad as requiring DataSequenceInOrder = Yes.
The necessary and sufficient requirements are (I think):
 
When immediate data is sent, it MUST begin with the first byte of the data transfer -
   rationale: there is no mechanism such as DataSN in the SCSI Command PDU to indicate position of the immediate data so it must have an implied position.
 
When unsolicited non-immediate data is sent, there is an implied R2T for the first n bytes of data
   where n = min(Expected Data Transfer Length, FirstBurstSize)
This implied R2T is to be satisfied by the immediate data plus unsolicited SCSI Data-out PDUs. As above, any immediate data must begin with the first byte of the data transfer. If DataSequenceInOrder=No, then the data in the unsolicited SCSI Data-out PDUs MAY be in any order but MUST be the bytes that satisfy the implied R2T (that is, the first n bytes of the data).
 rationale: Since the R2T is implied, it doesn't have an explicit position and must have an implicit position.
 
I don't think these requirements are articulated in the draft.
 
Pat
 
-----Original Message-----
From: Robert Snively [mailto:rsnively@brocade.com]
Sent: Monday, June 24, 2002 2:30 PM
To: 'THALER,PAT (A-Roseville,ex1)'; Nandakumar Ramamurthy; Julian Satran
Cc: ips@ece.cmu.edu
Subject: RE: iSCSI: FirstBurstSize and unsolicited data

I must have missed something in the document.  I did not see
any restriction that required EMDP = 0 (or in iSCSI-ese, DataSequenceInOrder = yes)
when immediate data was transmitted.  I would have expected such
a requirement.  If that is not the case, then any data can be transmitted
first and any data can be requested with the first (overlapping) R2T, somewhat confusing
the issue.
 
If someone can point me to that restriction, I would be delighted.
 
Bob
-----Original Message-----
From: THALER,PAT (A-Roseville,ex1) [mailto:pat_thaler@agilent.com]
Sent: Friday, June 21, 2002 9:46 AM
To: Nandakumar Ramamurthy; Julian Satran
Cc: ips@ece.cmu.edu
Subject: RE: iSCSI: FirstBurstSize and unsolicited data

Nandakumar,
 
There are no restrictions on the amount of immediate data sent other than that it must be less than MaxRecvDataSegmentLength and less than FirstBurstSize. So in the conditions you have chosen, the initiator could send any amount of ImmediateData from 4 Bytes to 8 KB. Doing so should not cause an error at the target.
 
The purpose of allowing an implicit InitialR2T is to gain efficiency by letting data start flowing without having to wait a round-trip delay for an R2T. Gaining this efficiency requires that the target know how much unsolicited data will be sent when it receives the SCSI Command PDU so that it can immediately send the first explicit R2T. The rule on sending the full FirstBurstSize (or all the data) when unsolicited data is sent in Data-out PDUs achieves this. When the target sees the SCSI Command PDU with the F bit set to 0, it knows that the first data it needs to request with an R2T starts after FirstBurstSize bytes.
 
When the SCSI Command PDU has an F bit set to 1, then the target knows that DataSegmentLength is the amound of unsolicited data being sent and it can construct its first R2T. Therefore there is no reason to restrict the amount of unsolicited data sent when only immediate data is sent (other than that it not exceed the maximums).
 
That is what is reflected in the rules.
 
Pat
 
-----Original Message-----
From: Nandakumar Ramamurthy [mailto:nramamur@npd.hcltech.com]
Sent: Friday, June 21, 2002 1:36 AM
To: Julian Satran
Cc: ips@ece.cmu.edu
Subject: Re: iSCSI: FirstBurstSize and unsolicited data

Hi,
 
I have been following the discussion on this thread.
 
I still have certain doubts regarding the
conditions I specified in my original mail.
 
The conditions are :
 
FirstBurstSize = 64KB
EDTL = 100KB ( EDTL > FirstBurstSize)
MaxRecvDataSegmentLength = 8KB
ImmediateData = Yes
InitialR2T = Yes
 
In the above case the initiator cannot send unsolicited Data-out PDUs.
Here unsolicited data(ImmediateData) < FirstBurstSize.
 
Will the target report any error in this case?
 
The modified text for Section 9.4.6.2 only refers to the cases
where unsolicited Data-outs can be sent.
 
Please clarify if I am missing something very obvious.
 
 
Thanks,
Nandakumar
Member Technical Staff
HCL Technologies, Chennai, INDIA.
http://san.hcltech.com
 
 
----- Original Message -----
From: Julian Satran
To: Eddy Quicksall
Cc: ips@ece.cmu.edu
Sent: Friday, June 21, 2002 11:41 AM
Subject: RE: iSCSI: FirstBurstSize and unsolicited data


Eddy,

I assume you meant EDTL not DSL and then the answer is yes and I again forgot to subtract  the immediate. A better formulation would be:

The target reports the "Incorrect amount of data" condition if dur-ing data output the total data length to output is greater than First-BurstSize and the initiator sent unsolicited non-immediate data but the total amount of unsolicited data is different than FirstBurst-Size. The target reports the same error when the amount of data sent as a reply to an R2T does not match the amount requested.

Julo


"Eddy Quicksall" <Eddy@Quicksall.com>

06/21/2002 12:22 AM
Please respond to "Eddy Quicksall"

       
       To:        Julian Satran/Haifa/IBM@IBMIL
       cc:        
       Subject:        RE: iSCSI: FirstBurstSize and unsolicited data

     



Isn't this saying that if DSL > FirstBurstSize, it would be incorrect to send non-immediate unsolicited which is not equal to FirstBurstSize?
 
The target reports the "Incorrect amount of data" condition if dur-ing data output the total data length to output is greater than First-BurstSize, but the initiator sent an amount different than FirstBurstSize of unsolicited non-immediate data or the amount of data sent as a reply to an R2T does not match the amount requested.
 
Eddy


------_=_NextPart_001_01C220F7.59C61580-- From owner-ips@ece.cmu.edu Mon Jul 1 08:49:15 2002 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA01834 for ; Mon, 1 Jul 2002 08:49:14 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id g61C6R911677 for ips-outgoing; Mon, 1 Jul 2002 08:06:27 -0400 (EDT) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from mail.ivivity.com ([64.238.111.99]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id g61C6Pw11670 for ; Mon, 1 Jul 2002 08:06:25 -0400 (EDT) Received: by ATLOPS with Internet Mail Service (5.5.2653.19) id ; Mon, 1 Jul 2002 08:06:24 -0400 Message-ID: From: Eddy Quicksall To: Julian Satran Cc: ips@ece.cmu.edu Subject: RE: iSCSI: FirstBurstSize and unsolicited data Date: Mon, 1 Jul 2002 08:06:23 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C220F7.B7D18DD0" Sender: owner-ips@ece.cmu.edu Precedence: bulk This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_001_01C220F7.B7D18DD0 Content-Type: text/plain; charset="iso-8859-1" In an earlier EMAIL this morning, I said "I think something should be said. It can be short and sweat." But, I did not notice that -14 is now the final draft. So, forget what I said. Eddy -----Original Message----- From: Julian Satran [mailto:Julian_Satran@il.ibm.com] Sent: Tuesday, June 25, 2002 2:59 AM To: pat_thaler@agilent.com Cc: ips@ece.cmu.edu; nramamur@npd.hcltech.com; pat_thaler@agilent.com; rsnively@Brocade.COM Subject: RE: iSCSI: FirstBurstSize and unsolicited data Pat, Do you think we should make the position of the initial data expliciit (i.e., add text) where this seems obvious? Julo pat_thaler@agilent.com 06/25/2002 02:30 AM Please respond to pat_thaler To: rsnively@brocade.com, pat_thaler@agilent.com, nramamur@npd.hcltech.com, Julian Satran/Haifa/IBM@IBMIL cc: ips@ece.cmu.edu Subject: RE: iSCSI: FirstBurstSize and unsolicited data Robert, I think there should be a restriction but it isn't as broad as requiring DataSequenceInOrder = Yes. The necessary and sufficient requirements are (I think): When immediate data is sent, it MUST begin with the first byte of the data transfer - rationale: there is no mechanism such as DataSN in the SCSI Command PDU to indicate position of the immediate data so it must have an implied position. When unsolicited non-immediate data is sent, there is an implied R2T for the first n bytes of data where n = min(Expected Data Transfer Length, FirstBurstSize) This implied R2T is to be satisfied by the immediate data plus unsolicited SCSI Data-out PDUs. As above, any immediate data must begin with the first byte of the data transfer. If DataSequenceInOrder=No, then the data in the unsolicited SCSI Data-out PDUs MAY be in any order but MUST be the bytes that satisfy the implied R2T (that is, the first n bytes of the data). rationale: Since the R2T is implied, it doesn't have an explicit position and must have an implicit position. I don't think these requirements are articulated in the draft. Pat -----Original Message----- From: Robert Snively [mailto:rsnively@brocade.com] Sent: Monday, June 24, 2002 2:30 PM To: 'THALER,PAT (A-Roseville,ex1)'; Nandakumar Ramamurthy; Julian Satran Cc: ips@ece.cmu.edu Subject: RE: iSCSI: FirstBurstSize and unsolicited data I must have missed something in the document. I did not see any restriction that required EMDP = 0 (or in iSCSI-ese, DataSequenceInOrder = yes) when immediate data was transmitted. I would have expected such a requirement. If that is not the case, then any data can be transmitted first and any data can be requested with the first (overlapping) R2T, somewhat confusing the issue. If someone can point me to that restriction, I would be delighted. Bob -----Original Message----- From: THALER,PAT (A-Roseville,ex1) [mailto:pat_thaler@agilent.com] Sent: Friday, June 21, 2002 9:46 AM To: Nandakumar Ramamurthy; Julian Satran Cc: ips@ece.cmu.edu Subject: RE: iSCSI: FirstBurstSize and unsolicited data Nandakumar, There are no restrictions on the amount of immediate data sent other than that it must be less than MaxRecvDataSegmentLength and less than FirstBurstSize. So in the conditions you have chosen, the initiator could send any amount of ImmediateData from 4 Bytes to 8 KB. Doing so should not cause an error at the target. The purpose of allowing an implicit InitialR2T is to gain efficiency by letting data start flowing without having to wait a round-trip delay for an R2T. Gaining this efficiency requires that the target know how much unsolicited data will be sent when it receives the SCSI Command PDU so that it can immediately send the first explicit R2T. The rule on sending the full FirstBurstSize (or all the data) when unsolicited data is sent in Data-out PDUs achieves this. When the target sees the SCSI Command PDU with the F bit set to 0, it knows that the first data it needs to request with an R2T starts after FirstBurstSize bytes. When the SCSI Command PDU has an F bit set to 1, then the target knows that DataSegmentLength is the amound of unsolicited data being sent and it can construct its first R2T. Therefore there is no reason to restrict the amount of unsolicited data sent when only immediate data is sent (other than that it not exceed the maximums). That is what is reflected in the rules. Pat -----Original Message----- From: Nandakumar Ramamurthy [mailto:nramamur@npd.hcltech.com] Sent: Friday, June 21, 2002 1:36 AM To: Julian Satran Cc: ips@ece.cmu.edu Subject: Re: iSCSI: FirstBurstSize and unsolicited data Hi, I have been following the discussion on this thread. I still have certain doubts regarding the conditions I specified in my original mail. The conditions are : FirstBurstSize = 64KB EDTL = 100KB ( EDTL > FirstBurstSize) MaxRecvDataSegmentLength = 8KB ImmediateData = Yes InitialR2T = Yes In the above case the initiator cannot send unsolicited Data-out PDUs. Here unsolicited data(ImmediateData) < FirstBurstSize. Will the target report any error in this case? The modified text for Section 9.4.6.2 only refers to the cases where unsolicited Data-outs can be sent. Please clarify if I am missing something very obvious. Thanks, Nandakumar Member Technical Staff HCL Technologies, Chennai, INDIA. http://san.hcltech.com ----- Original Message ----- From: Julian Satran To: Eddy Quicksall Cc: ips@ece.cmu.edu Sent: Friday, June 21, 2002 11:41 AM Subject: RE: iSCSI: FirstBurstSize and unsolicited data Eddy, I assume you meant EDTL not DSL and then the answer is yes and I again forgot to subtract the immediate. A better formulation would be: The target reports the "Incorrect amount of data" condition if dur-ing data output the total data length to output is greater than First-BurstSize and the initiator sent unsolicited non-immediate data but the total amount of unsolicited data is different than FirstBurst-Size. The target reports the same error when the amount of data sent as a reply to an R2T does not match the amount requested. Julo "Eddy Quicksall" 06/21/2002 12:22 AM Please respond to "Eddy Quicksall" To: Julian Satran/Haifa/IBM@IBMIL cc: Subject: RE: iSCSI: FirstBurstSize and unsolicited data Isn't this saying that if DSL > FirstBurstSize, it would be incorrect to send non-immediate unsolicited which is not equal to FirstBurstSize? The target reports the "Incorrect amount of data" condition if dur-ing data output the total data length to output is greater than First-BurstSize, but the initiator sent an amount different than FirstBurstSize of unsolicited non-immediate data or the amount of data sent as a reply to an R2T does not match the amount requested. Eddy ------_=_NextPart_001_01C220F7.B7D18DD0 Content-Type: text/html; charset="iso-8859-1"
In an earlier EMAIL this morning, I said "I think something should be said. It can be short and sweat."
 
But, I did not notice that -14 is now the final draft. So, forget what I said.
 
Eddy
-----Original Message-----
From: Julian Satran [mailto:Julian_Satran@il.ibm.com]
Sent: Tuesday, June 25, 2002 2:59 AM
To: pat_thaler@agilent.com
Cc: ips@ece.cmu.edu; nramamur@npd.hcltech.com; pat_thaler@agilent.com; rsnively@Brocade.COM
Subject: RE: iSCSI: FirstBurstSize and unsolicited data


Pat,

Do you think we should make the position of the initial data expliciit (i.e., add text) where this seems obvious?

Julo


pat_thaler@agilent.com

06/25/2002 02:30 AM
Please respond to pat_thaler

       
        To:        rsnively@brocade.com, pat_thaler@agilent.com, nramamur@npd.hcltech.com, Julian Satran/Haifa/IBM@IBMIL
        cc:        ips@ece.cmu.edu
        Subject:        RE: iSCSI: FirstBurstSize and unsolicited data

       


Robert,
 
I think there should be a restriction but it isn't as broad as requiring DataSequenceInOrder = Yes.
The necessary and sufficient requirements are (I think):
 
When immediate data is sent, it MUST begin with the first byte of the data transfer -
   rationale: there is no mechanism such as DataSN in the SCSI Command PDU to indicate position of the immediate data so it must have an implied position.
 
When unsolicited non-immediate data is sent, there is an implied R2T for the first n bytes of data
   where n = min(Expected Data Transfer Length, FirstBurstSize)
This implied R2T is to be satisfied by the immediate data plus unsolicited SCSI Data-out PDUs. As above, any immediate data must begin with the first byte of the data transfer. If DataSequenceInOrder=No, then the data in the unsolicited SCSI Data-out PDUs MAY be in any order but MUST be the bytes that satisfy the implied R2T (that is, the first n bytes of the data).
 rationale: Since the R2T is implied, it doesn't have an explicit position and must have an implicit position.
 
I don't think these requirements are articulated in the draft.
 
Pat
 
-----Original Message-----
From: Robert Snively [mailto:rsnively@brocade.com]
Sent: Monday, June 24, 2002 2:30 PM
To: 'THALER,PAT (A-Roseville,ex1)'; Nandakumar Ramamurthy; Julian Satran
Cc: ips@ece.cmu.edu
Subject: RE: iSCSI: FirstBurstSize and unsolicited data

I must have missed something in the document.  I did not see
any restriction that required EMDP = 0 (or in iSCSI-ese, DataSequenceInOrder = yes)
when immediate data was transmitted.  I would have expected such
a requirement.  If that is not the case, then any data can be transmitted
first and any data can be requested with the first (overlapping) R2T, somewhat confusing
the issue.
 
If someone can point me to that restriction, I would be delighted.
 
Bob
-----Original Message-----
From: THALER,PAT (A-Roseville,ex1) [mailto:pat_thaler@agilent.com]
Sent: Friday, June 21, 2002 9:46 AM
To: Nandakumar Ramamurthy; Julian Satran
Cc: ips@ece.cmu.edu
Subject: RE: iSCSI: FirstBurstSize and unsolicited data

Nandakumar,
 
There are no restrictions on the amount of immediate data sent other than that it must be less than MaxRecvDataSegmentLength and less than FirstBurstSize. So in the conditions you have chosen, the initiator could send any amount of ImmediateData from 4 Bytes to 8 KB. Doing so should not cause an error at the target.
 
The purpose of allowing an implicit InitialR2T is to gain efficiency by letting data start flowing without having to wait a round-trip delay for an R2T. Gaining this efficiency requires that the target know how much unsolicited data will be sent when it receives the SCSI Command PDU so that it can immediately send the first explicit R2T. The rule on sending the full FirstBurstSize (or all the data) when unsolicited data is sent in Data-out PDUs achieves this. When the target sees the SCSI Command PDU with the F bit set to 0, it knows that the first data it needs to request with an R2T starts after FirstBurstSize bytes.
 
When the SCSI Command PDU has an F bit set to 1, then the target knows that DataSegmentLength is the amound of unsolicited data being sent and it can construct its first R2T. Therefore there is no reason to restrict the amount of unsolicited data sent when only immediate data is sent (other than that it not exceed the maximums).
 
That is what is reflected in the rules.
 
Pat
 
-----Original Message-----
From: Nandakumar Ramamurthy [mailto:nramamur@npd.hcltech.com]
Sent: Friday, June 21, 2002 1:36 AM
To: Julian Satran
Cc: ips@ece.cmu.edu
Subject: Re: iSCSI: FirstBurstSize and unsolicited data

Hi,
 
I have been following the discussion on this thread.
 
I still have certain doubts regarding the
conditions I specified in my original mail.
 
The conditions are :
 
FirstBurstSize = 64KB
EDTL = 100KB ( EDTL > FirstBurstSize)
MaxRecvDataSegmentLength = 8KB
ImmediateData = Yes
InitialR2T = Yes
 
In the above case the initiator cannot send unsolicited Data-out PDUs.
Here unsolicited data(ImmediateData) < FirstBurstSize.
 
Will the target report any error in this case?
 
The modified text for Section 9.4.6.2 only refers to the cases
where unsolicited Data-outs can be sent.
 
Please clarify if I am missing something very obvious.
 
 
Thanks,
Nandakumar
Member Technical Staff
HCL Technologies, Chennai, INDIA.
http://san.hcltech.com
 
 
----- Original Message -----
From: Julian Satran
To: Eddy Quicksall
Cc: ips@ece.cmu.edu
Sent: Friday, June 21, 2002 11:41 AM
Subject: RE: iSCSI: FirstBurstSize and unsolicited data


Eddy,

I assume you meant EDTL not DSL and then the answer is yes and I again forgot to subtract  the immediate. A better formulation would be:

The target reports the "Incorrect amount of data" condition if dur-ing data output the total data length to output is greater than First-BurstSize and the initiator sent unsolicited non-immediate data but the total amount of unsolicited data is different than FirstBurst-Size. The target reports the same error when the amount of data sent as a reply to an R2T does not match the amount requested.

Julo


"Eddy Quicksall" <Eddy@Quicksall.com>

06/21/2002 12:22 AM
Please respond to "Eddy Quicksall"

       
       To:        Julian Satran/Haifa/IBM@IBMIL
       cc:        
       Subject:        RE: iSCSI: FirstBurstSize and unsolicited data

     



Isn't this saying that if DSL > FirstBurstSize, it would be incorrect to send non-immediate unsolicited which is not equal to FirstBurstSize?
 
The target reports the "Incorrect amount of data" condition if dur-ing data output the total data length to output is greater than First-BurstSize, but the initiator sent an amount different than FirstBurstSize of unsolicited non-immediate data or the amount of data sent as a reply to an R2T does not match the amount requested.
 
Eddy


------_=_NextPart_001_01C220F7.B7D18DD0-- From owner-ips@ece.cmu.edu Mon Jul 1 10:54:27 2002 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA10187 for ; Mon, 1 Jul 2002 10:54:25 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id g61DwUj16468 for ips-outgoing; Mon, 1 Jul 2002 09:58:30 -0400 (EDT) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from maho3msx2.isus.emc.com (maho3msx2.isus.emc.com [128.221.11.32]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id g61DwTw16464 for ; Mon, 1 Jul 2002 09:58:29 -0400 (EDT) Received: by MAHO3MSX2 with Internet Mail Service (5.5.2653.19) id ; Mon, 1 Jul 2002 09:56:31 -0400 Message-ID: <277DD60FB639D511AC0400B0D068B71E0564BFF0@CORPMX14> From: Black_David@emc.com To: cbh@zyfer.com, ips@ece.cmu.edu Subject: RE: IPS-All: Reminder - Security draft last call ends Monday, Jul y 1 at 8am EST Date: Mon, 1 Jul 2002 09:56:29 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-ips@ece.cmu.edu Precedence: bulk Excerpting the important point: > o.k. Lets see what I have understand now: If PFS by rekeying is not > mandatory to use (and this is the situation) then you can established with > DH exchange a key (referred here now by me as long-term key) and use other > protocols, e.g. Basic Quick Mode or Stealthkey, to derive multiple keys > (referred here as short-term keys) from the long-term key. The compromise > of short-term keys must not compromise the long-term key. This formulation > should be also conform with Paul Koning's comment. Yes, with a slight clarification of "must not" - "when properly used, compromise of short-term keys must not compromise the long-term key". Eventually, any key is vulnerable to compromise from overuse, even if that use is only as part of generation of other keys. Thanks, --David --------------------------------------------------- David L. Black, Senior Technologist EMC Corporation, 42 South St., Hopkinton, MA 01748 +1 (508) 249-6449 *NEW* FAX: +1 (508) 497-8500 black_david@emc.com Cell: +1 (978) 394-7754 --------------------------------------------------- > -----Original Message----- > From: Christina Helbig [mailto:cbh@zyfer.com] > Sent: Friday, June 28, 2002 7:37 PM > To: 'Black_David@emc.com'; ips@ece.cmu.edu > Subject: RE: IPS-All: Reminder - Security draft last call ends Monday, > Jul y 1 at 8am EST > > > David, thank you for the time for answer. Comments inside: > > > -----Original Message----- > > From: Black_David@emc.com [mailto:Black_David@emc.com] > > Sent: Friday, June 28, 2002 1:07 PM > > To: Christina Helbig; ips@ece.cmu.edu > > Subject: RE: IPS-All: Reminder - Security draft last call > ends Monday, > > Jul y 1 at 8am EST > > > > > > Christina, > > > > Thanks for your comments. I don't think there are technical issues > > in the two areas of concern you've raised - could you please check > > the following discussion and see if it's ok? > > > > I. Rekeying and PFS > > > > The requirement for PFS is "MUST implement" (must support) > > not "MUST use". > > Christina's text appears to be objecting to a "MUST use" > > requirement - if > > so, this is not a problem, as the requirement is "MUST implement", > > which is the intention of the "must support" wording in > section 2.1 of > > the security draft. > o.k. I understood. > > > > II. Manual keying and PFS > > > > Section 5.9 was not intended to provide an exception to the > > "MUST NOT use" > > manual keying requirement stated in Section 2.3.3. The > > Section 5.9 text > > should be clarified to make this clear. > > > o.k. > > > Second, if PFS would be not mandatory by rekeying then you > > can use manual > > > keying together with other protocols for frequent > rekeying, e.g. our > > > proposal. > > > > I don't think there's an issue here, but some terminology > > clarification is > > in order - in essence properly designed "manual keying together with > > other protocols for frequent rekeying" is "preshared keying" and is > > allowed (in fact it's required). > > > > The term "manual keying" describes situations in which keys are > > preconfigured > > (manually) and then those keys are used as the session keying > > material for > > the SAs that carry traffic - rekeying is accomplished by (manually) > > configuring new keys. Manual keying is forbidden (MUST NOT use) for > > IP Storage due to the inability to automatically generate new secure > > session keys. > > > > The term "preshared keying" describes situations in which the > > preconfigured > > keys are used to derive multiple session keys in a fashion > > that compromise > > of a session key does not imply compromise or serious > weakening of the > > preconfigured keys (IKE uses a keyed prf [usually a hash] to > > obtain this > > property). Pre-shared keying is REQUIRED (MUST implement). > > > o.k. Lets see what I have understand now: If PFS by rekeying is not > mandatory to use (and this is the situation) then you can > established with > DH exchange a key (referred here now by me as long-term key) > and use other > protocols, e.g. Basic Quick Mode or Stealthkey, to derive > multiple keys > (referred here as short-term keys) from the long-term key . > The compromise > of short-term keys must not compromise the long-term key. > This formulation > should be also conform with Paul Koenigs comment. > > The StealthKey mechanism described in > > draft-helbig-stealthkey-01.txt is > > a preshared keying mechanism that can automatically generate new > > (short-term) session keys, and hence is not forbidden by the > > requirement > > that manual keying MUST NOT be used. OTOH, StealthKey is not > > specified > > in any of the IP Storage protocol drafts. > > > o.k. We try to get some attention from the IPSec working > group for this > proposal. I think this is the right WG. I was only concerned > that we have no > chance to use this for IP Storage protocols but the right > understanding of > Internet-Standards is really a skill after long-training. > Thank you > Christina > > Thanks, > > --David > > --------------------------------------------------- > > David L. Black, Senior Technologist > > EMC Corporation, 42 South St., Hopkinton, MA 01748 > > +1 (508) 249-6449 *NEW* FAX: +1 (508) 497-8500 > > black_david@emc.com Cell: +1 (978) 394-7754 > > --------------------------------------------------- > > > > > -----Original Message----- > > > From: Christina Helbig [mailto:cbh@zyfer.com] > > > Sent: Friday, June 28, 2002 2:03 PM > > > To: 'Elizabeth Rodriguez'; ips@ece.cmu.edu > > > Subject: RE: IPS-All: Reminder - Security draft last call > > ends Monday, > > > Jul y 1 at 8am EST > > > > > > > > > These are my IPS Security draft last call comments. I'm also > > > impressed about > > > the good work others have done. > > > > > > I have problems with following text about rekeying and > > manual keying. > > > > > > I. Rekeying and PFS: > > > > > > First there are two statements, which I think are not consistent: > > > > > > a) 2.1. Security requirements > > > ...The IP block storage security protocols must support perfect > > > forward secrecy in the rekeying process. > > > > > > b) 2.2. Resource constraints > > > Computational horsepower should be available to perform a > > > reasonable amount > > > of exponentiation as part of authentication and key derivation for > > > connection setup. The same is true of rekeying, although the > > > ability to avoid exponentiation for rekeying may be desirable (but > > > is not an absolute requirement). > > > > > > In RFC 2409 is a clear definition of PFS for IKE: > > > 3.3 Perfect Forward Secrecy > > > When used in the memo Perfect Forward Secrecy (PFS) refers to > > > the notion > > > that compromise of a single key will permit access to only > > > data protected by > > > a single key. For PFS to exist the key used to protect > > > transmission of data > > > MUST NOT be used to derive any additional keys, and if the > > key used to > > > protect transmission of data was derived from some other > > > keying material, > > > that material MUST NOT be used to derive any more keys. > > > > > > If a) is the requirement than you can never avoid > exponentiation for > > > rekeying because otherwise you must use keying material to > > > derive more than > > > one key. > > > > > > Second I think PFS should not be a requirement for rekeying, > > > only a nice to > > > have. Why? > > > > > > There is currently a discussion about PFS and rekeying by SOI > > > in the IPSec > > > list and here is what I wrote and nobody opposed me (what not > > > mean that I'm > > > right ;-) > > > > > > "IMO there is a mix of the issue of PFS and rekeying in the > > > discussion. > > > 1. Rekeying is needed if the amount of with the same key > > > encrypted data goes > > > beyond specific values, because of some passive attacks > against the > > > encrypted data (dependable also of the encryption algorithm > > > and its mode) > > > and the active attack of replaying by ESP after the sequence > > > number counter > > > has started again. > > > 2. The need for PFS by the process of rekeying is not based > > > on protection > > > against this attacks under 1. > > > 3. The property of PFS is an advantage in the case of > > > unauthorized access to > > > secret information used to generate the communication keys. > > > If this secret > > > information can be secured against unauthorized access then > > > rekeying can be > > > done without the property of PFS. > > > 4. On the other hand there is always a need by IKE to > protect secret > > > information against unauthorized access used for phase 1 > > > authentication. If > > > the protection of this secret information in the system is > > > sufficient why > > > should there the protection of another secret information be > > > insufficient? > > > > > > My proposal is: Rekeying is necessary under specific > > > circumstances, which > > > should be described. PFS is not needed if the secret > > > information used to > > > generate different communication keys is protected against > > > unauthorized > > > access in the same manner like the phase 1 authentication secret." > > > > > > The main reason for avoiding mandatory PFS by rekeying, I > > think is the > > > computational overhead. I have mentioned in the SOI discussion: > > > > > > "I found different statements about the CPU time necessary for one > > > exponentiation between 30ms and some seconds. In the > > > draft-ietf-ips-security-13.txt it's time for rekeying for one > > > SA by 10Gbps > > > and 3DES in CBC mode all 27.5s or before 2^35 bytes are sent. > > > Assume the > > > case of some hundred SAs per peer with permanently > > > irregularly distributed > > > traffic between the SAs. Then rekeying at time is necessary > > > for every SA all > > > 27.5 s. This looks like a computational border, so you must have > > > amount-based rekeying in this case and encrypted bytes or > > > blocks must be > > > counted for every SA. Is that a computational border too?" > > > > > > There was no answer like "This is no problem". > > > > > > Last I like to mention the possibility to rekey without > > exchanges (and > > > without PFS). We have developed a protocol for frequent > > > rekeying without > > > exchanges and would be happy if some folks could have a look > > > at this and say > > > if it makes sense or not > > > ( > thkey-01.txt>) > > > > II. Manual keying and PFS: > > > > First there are again two statements, which I think are not > > consistent: > > > > > > c) 2.3.3. IKE > > ...Manual keying MUST NOT be used since it does not provide > > the necessary > > rekeying support. > > > > d) 5.9 Use of AES in counter mode > > > > ...The implication of this is that it is almost always an > error to use > > IPsec manual keying with counter mode, except when the > implementation > > takes heroic measures to maintain state across sessions. > > > > That means there is an exception from MUST NOT? > > > > Second, if PFS would be not mandatory by rekeying then you > > can use manual > > keying together with other protocols for frequent rekeying, e.g. our > > proposal. > > Thank you for your patient regarding my bad English. > > Christina > > > > > -----Original Message----- > > > From: Elizabeth Rodriguez [mailto:elizabeth.g.rodriguez@123mail.net] > > Sent: Thursday, June 27, 2002 2:41 PM > > To: ips@ece.cmu.edu > > Cc: Elizabeth.G.Rodriguez@123mail.net > > Subject: IPS-All: Reminder - Security draft last call ends > > Monday, July > > 1 at 8am EST > > > > > > Just a reminder to all to get your last call comments on the > > security draft in. > > The cutoff is Monday July 1 at 8am EST > > > > Thanks, > > > > Elizabeth > > > > > From owner-ips@ece.cmu.edu Mon Jul 1 11:48:10 2002 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA13467 for ; Mon, 1 Jul 2002 11:48:10 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id g61F7Oc20418 for ips-outgoing; Mon, 1 Jul 2002 11:07:24 -0400 (EDT) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from mail.ivivity.com ([64.238.111.99]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id g61F7Mw20413 for ; Mon, 1 Jul 2002 11:07:22 -0400 (EDT) Received: by ATLOPS with Internet Mail Service (5.5.2653.19) id ; Mon, 1 Jul 2002 11:07:21 -0400 Message-ID: From: Eddy Quicksall To: Julian Satran , internet-drafts@ietf.org Cc: ips@ece.cmu.edu Subject: RE: iSCSI version 14 draft Date: Mon, 1 Jul 2002 11:07:21 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C22110.FF90D3B0" Sender: owner-ips@ece.cmu.edu Precedence: bulk This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_001_01C22110.FF90D3B0 Content-Type: text/plain; charset="iso-8859-1" I assume this will now enter a different discussion phase. If so, can someone advise me on how to get onto that mailing list? Eddy -----Original Message----- From: Julian Satran [mailto:Julian_Satran@il.ibm.com] Sent: Monday, July 01, 2002 3:23 AM To: internet-drafts@ietf.org Cc: ips@ece.cmu.edu Subject: iSCSI version 14 draft On behalf of the team of authors and as part of the IETF-IPS working group I submit a draft for immediate publication. The text and pdf versions can be found at: http://www.haifa.il.ibm.com/satran/ips/draft-ietf-ips-iscsi-14.txt http://www.haifa.il.ibm.com/satran/ips/draft-ietf-ips-iscsi-14.pdf This version completely replaces: draft-ietf-ips-iscsi-13.txt and pdf Julian Satran - IBM Research Laboratory at Haifa ------_=_NextPart_001_01C22110.FF90D3B0 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
I = assume this will=20 now enter a different discussion phase. If so, can someone advise me on = how to=20 get onto that mailing list?
 
Eddy
-----Original Message-----
From: Julian Satran=20 [mailto:Julian_Satran@il.ibm.com]
Sent: Monday, July 01, = 2002 3:23=20 AM
To: internet-drafts@ietf.org
Cc:=20 ips@ece.cmu.edu
Subject: iSCSI version 14=20 draft



On = behalf of=20 the team of authors and as part of the IETF-IPS working group =
I submit a draft for immediate = publication.=20

The text and pdf versions = can be found=20 at:

http://www.haifa.il.ibm.com/satran/ips/draft-ietf-ips-iscsi-14.= txt=20

http://www.haifa.il.ibm.com/satran/ips/draft-ietf-ips-iscsi-14.= pdf=20


This version completely=20 replaces:

draft-ietf-ips-iscsi-13.txt and pdf =



Julian Satran - IBM Research Laboratory at = Haifa=20 =

















=









------_=_NextPart_001_01C22110.FF90D3B0-- From owner-ips@ece.cmu.edu Mon Jul 1 11:50:27 2002 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA13746 for ; Mon, 1 Jul 2002 11:50:22 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id g61FHv121017 for ips-outgoing; Mon, 1 Jul 2002 11:17:57 -0400 (EDT) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from mxic2.corp.emc.com (mxic2.isus.emc.com [128.221.31.40]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id g61FHtw21013 for ; Mon, 1 Jul 2002 11:17:55 -0400 (EDT) Received: by mxic2.corp.emc.com with Internet Mail Service (5.5.2653.19) id ; Mon, 1 Jul 2002 11:17:38 -0400 Message-ID: <277DD60FB639D511AC0400B0D068B71E0564BFF2@CORPMX14> From: Black_David@emc.com To: eddy_quicksall@ivivity.com Cc: ips@ece.cmu.edu Subject: RE: iSCSI version 14 draft Date: Mon, 1 Jul 2002 11:15:46 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C22112.2CD268B0" Sender: owner-ips@ece.cmu.edu Precedence: bulk This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_001_01C22112.2CD268B0 Content-Type: text/plain; charset="iso-8859-1" > I assume this will now enter a different discussion phase. If so, can someone advise > me on how to get onto that mailing list? That is an incorrect assumption. -14 incorporates the changes identified so far in WG Last Call. iSCSI is still in WG Last Call for another week (ends at 5pm Eastern Time on Sunday, July 7th). All technical issues with the draft need to be brought to this mailing list - editorial comments can be sent directly to Julian. Once a successful WG Last Call ends, the WG chairs work with the draft authors to produce the final version to be submitted to the ADs/IESG, but there is no further opportunity for WG comments on the draft - that's what "WG Last Call" means. Also, would everyone please be careful about email "Reply To All" and the like -- internet-drafts@ietf.org did not need or want a copy of Eddy's message. Thanks, --David --------------------------------------------------- David L. Black, Senior Technologist EMC Corporation, 42 South St., Hopkinton, MA 01748 +1 (508) 249-6449 *NEW* FAX: +1 (508) 497-8500 black_david@emc.com Cell: +1 (978) 394-7754 --------------------------------------------------- -----Original Message----- From: Eddy Quicksall [mailto:eddy_quicksall@ivivity.com] Sent: Monday, July 01, 2002 11:07 AM To: Julian Satran; internet-drafts@ietf.org Cc: ips@ece.cmu.edu Subject: RE: iSCSI version 14 draft I assume this will now enter a different discussion phase. If so, can someone advise me on how to get onto that mailing list? Eddy -----Original Message----- From: Julian Satran [mailto:Julian_Satran@il.ibm.com] Sent: Monday, July 01, 2002 3:23 AM To: internet-drafts@ietf.org Cc: ips@ece.cmu.edu Subject: iSCSI version 14 draft On behalf of the team of authors and as part of the IETF-IPS working group I submit a draft for immediate publication. The text and pdf versions can be found at: http://www.haifa.il.ibm.com/satran/ips/draft-ietf-ips-iscsi-14.txt http://www.haifa.il.ibm.com/satran/ips/draft-ietf-ips-iscsi-14.pdf This version completely replaces: draft-ietf-ips-iscsi-13.txt and pdf Julian Satran - IBM Research Laboratory at Haifa ------_=_NextPart_001_01C22112.2CD268B0 Content-Type: text/html; charset="iso-8859-1"
> I assume this will now enter a different discussion phase. If so, can someone advise
> me on how to get onto that mailing list?
 
That is an incorrect assumption.  -14 incorporates the changes
identified so far in WG Last Call.  iSCSI is still in WG Last
Call for another week (ends at 5pm Eastern Time on Sunday, July 7th).
All technical issues with the draft need to be brought to this
mailing list - editorial comments can be sent directly to Julian.
Once a successful WG Last Call ends, the WG chairs work with the
draft authors to produce the final version to be submitted to the
ADs/IESG, but there is no further opportunity for WG comments
on the draft - that's what "WG Last Call" means.
 
Also, would everyone please be careful about email "Reply To All"
and the like -- internet-drafts@ietf.org did not need or want a copy
of Eddy's message.
 
Thanks,
--David

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

-----Original Message-----
From: Eddy Quicksall [mailto:eddy_quicksall@ivivity.com]
Sent: Monday, July 01, 2002 11:07 AM
To: Julian Satran; internet-drafts@ietf.org
Cc: ips@ece.cmu.edu
Subject: RE: iSCSI version 14 draft

I assume this will now enter a different discussion phase. If so, can someone advise me on how to get onto that mailing list?
 
Eddy
-----Original Message-----
From: Julian Satran [mailto:Julian_Satran@il.ibm.com]
Sent: Monday, July 01, 2002 3:23 AM
To: internet-drafts@ietf.org
Cc: ips@ece.cmu.edu
Subject: iSCSI version 14 draft



On behalf of the team of authors and as part of the IETF-IPS working group
I submit a draft for immediate publication.

The text and pdf versions can be found at:

http://www.haifa.il.ibm.com/satran/ips/draft-ietf-ips-iscsi-14.txt

http://www.haifa.il.ibm.com/satran/ips/draft-ietf-ips-iscsi-14.pdf


This version completely replaces:

draft-ietf-ips-iscsi-13.txt and pdf



Julian Satran - IBM Research Laboratory at Haifa



























------_=_NextPart_001_01C22112.2CD268B0-- From owner-ips@ece.cmu.edu Mon Jul 1 11:52:49 2002 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA13947 for ; Mon, 1 Jul 2002 11:52:49 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id g61FI5v21041 for ips-outgoing; Mon, 1 Jul 2002 11:18:05 -0400 (EDT) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from msgbas1.cos.agilent.com (msgbas1x.cos.agilent.com [192.25.240.36]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id g61FI3w21031 for ; Mon, 1 Jul 2002 11:18:03 -0400 (EDT) Received: from msgrel1t.cos.agilent.com (msgrel1t.cos.agilent.com [130.29.152.157]) by msgbas1.cos.agilent.com (Postfix) with ESMTP id 254B8BAB0; Mon, 1 Jul 2002 09:18:02 -0600 (MDT) Received: from axcsbh3.cos.agilent.com (axcsbh3.cos.agilent.com [130.29.152.190]) by msgrel1t.cos.agilent.com (Postfix) with SMTP id CFA4AE1F; Mon, 1 Jul 2002 09:18:01 -0600 (MDT) Received: from 130.29.152.190 by axcsbh3.cos.agilent.com (InterScan E-Mail VirusWall NT); Mon, 01 Jul 2002 09:17:07 -0600 Received: by axcsbh3.cos.agilent.com with Internet Mail Service (5.5.2653.19) id ; Mon, 1 Jul 2002 09:17:07 -0600 Message-ID: <9F8400020EC5D311AF62009027C396160902C4FB@axcs09.cos.agilent.com> From: kevin_lemay@agilent.com To: Julian_Satran@il.ibm.com Cc: ips@ece.cmu.edu Subject: iSCSI: Question on login min/Max Date: Mon, 1 Jul 2002 09:16:58 -0600 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="ISO-8859-1" Sender: owner-ips@ece.cmu.edu Precedence: bulk Julian, In draft v14, page 210, The following text was added: "Result function wherever mentioned states the function that can be applied to check the validity of the responder selection. Minimum means that the selected value cannot exceed the offered value. Maximum means that the selected value cannot be lower than the offered value." What drove this change? This is a departure from what it was previously where we could just take the min/max of the two offered numbers. So if I interpret this correctly, if: Init -> DefaultTime2Wait=2 (func is Max) Target -> DefaultTime2Wait=1 Init detects an error and closes the TCP connection. Correct? Kevin From owner-ips@ece.cmu.edu Mon Jul 1 12:08:47 2002 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA15068 for ; Mon, 1 Jul 2002 12:08:46 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id g61FjWU22717 for ips-outgoing; Mon, 1 Jul 2002 11:45:32 -0400 (EDT) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from mxic2.corp.emc.com (mxic2.isus.emc.com [128.221.31.40]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id g61FjVw22713 for ; Mon, 1 Jul 2002 11:45:31 -0400 (EDT) Received: by mxic2.corp.emc.com with Internet Mail Service (5.5.2653.19) id ; Mon, 1 Jul 2002 11:45:25 -0400 Message-ID: <277DD60FB639D511AC0400B0D068B71E0564BFF5@CORPMX14> From: Black_David@emc.com To: ips@ece.cmu.edu Subject: FW: IPS-All: Reminder - Security draft last call ends Monday, Jul y 1 at 8am EST Date: Mon, 1 Jul 2002 11:43:33 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C22116.0E780920" Sender: owner-ips@ece.cmu.edu Precedence: bulk This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_001_01C22116.0E780920 Content-Type: text/plain; charset="iso-8859-1" One more round of lining up the iSCSI and IPS Security drafts. --David -----Original Message----- From: Julian Satran [mailto:Julian_Satran@il.ibm.com] Sent: Sunday, June 30, 2002 7:27 AM To: Ofer Biran Cc: bernard_aboba@hotmail.com; Black_David@emc.com; Elizabeth Rodriguez Subject: Re: IPS-All: Reminder - Security draft last call ends Monday, July 1 at 8am EST see comments in text - Julo Ofer Biran 06/30/2002 11:43 AM To: Elizabeth Rodriguez , Black_David@emc.com, bernard_aboba@hotmail.com, Julian Satran/Haifa/IBM@IBMIL cc: From: Ofer Biran/Haifa/IBM@IBMIL Subject: Re: IPS-All: Reminder - Security draft last call ends Monday, July 1 at 8am EST Link These comments are from mandatory statements sync check I made with the iSCSI draft: ====================== 2.3.1. Transforms "When ESP is utilized, per-packet data origin authentication, integrity and replay protection MUST be used." In iSCSI, the replay protection is MUST implement (not MUST use): 7.3.1 Data Integrity and Authentication "The ESP anti-replay service MUST also be implemented." (I'm not sure if the security or iSCSI should be changed ? I think the recent tendency was not to impose IPsec requirements unless they are justified by IPS uniqueness compare to other IPsec usage scenarios) +++ I assume security draft will be fixed +++ ====================== 2.3.3. IKE "Conformant IP block storage security implementations MUST support IKE Main Mode and SHOULD support Aggressive Mode." in iSCSI both MUST be supported: 7.3.3 Policy, Security Associations and Key Management "Both IKE Main Mode and Aggressive Mode MUST be supported." (this should be changed in iSCSI - was decided on last IETF Minneapolis) +++ will fix in iSCSI +++ ====================== 2.3.3. IKE "iSCSI security implementations SHOULD support the ID_USER_FQDN Identity Payload;" in iSCSI it's MAY: 7.3.3 Policy, Security Associations and Key Management "ID_USER_FQDN MAY be supported." (either should be changed for sync) +++ will fix in iSCSI +++ ====================== 2.4.1. CHAP "If CHAP is used with secret smaller than 96 bits, then IPsec encryption (according to the implementation requirements in [iSCSI] section 7.3.2) MUST be used to protect the connection. Moreover, in this case IKE authentication with group pre-shared keys MUST NOT be used. When CHAP is used with a secret smaller then 96 bits, a compliant implementation MUST NOT continue with the iSCSI login unless it can verify that IPsec encryption is being used to protect the connection." I suggest to change this according to the last iSCSI text that separates the administration requirements (first par.) and the implementation requirements (second par.): 7.2.1 CHAP Considerations "An administrative entity of an environment in which CHAP is used with a secret that has less than 96 random bits MUST enforce IPsec encryption according to the implementation requirements in Section 7.3.2 Confidentiality) to protect the connection. Moreover, in this case IKE authentication with group pre-shared keys SHOULD NOT be used unless it is not essential to protect group members against off-line dictionary attacks by other members. A compliant implementation SHOULD NOT continue with the login step in which it should send a CHAP response (CHAP_R - Section 10.5 Challenge Handshake Authentication Protocol (CHAP)) unless it can verify that either the CHAP secret is at least 96 bits, or that IPsec encryption is being used to protect the connection." +++ I assume security draft will be fixed +++ ====================== 2.4.2. SRP "Upon receiving N and g from the Target, the Initiator MUST verify that they satisfy the above requirements (and abort the connection otherwise). This verification MAY start by trying to match them with a well-known group that satisfies the above requirements. SRP well-known groups are included in Appendix A." This should be changed as iSCSI was changed according last consensus that no one will really implement these checks: 7.2.2 SRP Considerations "Upon receiving N and g from the Target, the Initiator MUST verify that they match a well-known group that satisfies the above requirements and abort the connection if they do not match. Well- known SRP groups are provided in [SEC-IPS]." +++ I assume security draft will be fixed +++ ====================== Regards, Ofer Ofer Biran Storage and Systems Technology IBM Research Lab in Haifa biran@il.ibm.com 972-4-8296253 Please respond to Elizabeth Rodriguez Sent by: owner-ips@ece.cmu.edu To: ips@ece.cmu.edu cc: Elizabeth.G.Rodriguez@123mail.net Subject: IPS-All: Reminder - Security draft last call ends Monday, July 1 at 8am EST Just a reminder to all to get your last call comments on the security draft in. The cutoff is Monday July 1 at 8am EST Thanks, Elizabeth ------_=_NextPart_001_01C22116.0E780920 Content-Type: text/html; charset="iso-8859-1"
One more round of lining up the iSCSI and IPS Security drafts.
 
--David
 
-----Original Message-----
From: Julian Satran [mailto:Julian_Satran@il.ibm.com]
Sent: Sunday, June 30, 2002 7:27 AM
To: Ofer Biran
Cc: bernard_aboba@hotmail.com; Black_David@emc.com; Elizabeth Rodriguez
Subject: Re: IPS-All: Reminder - Security draft last call ends Monday, July 1 at 8am EST


see comments in text  - Julo


Ofer Biran

06/30/2002 11:43 AM


        To:        Elizabeth Rodriguez <elizabeth.g.rodriguez@123mail.net>, Black_David@emc.com, bernard_aboba@hotmail.com, Julian Satran/Haifa/IBM@IBMIL
        cc:        
        From:        Ofer Biran/Haifa/IBM@IBMIL
        Subject:        Re: IPS-All: Reminder - Security draft last call ends Monday, July 1 at 8am ESTLink
 






These comments are from mandatory statements sync check
I made with the iSCSI draft:

======================

2.3.1.  Transforms
"When ESP is utilized, per-packet data origin authentication, integrity
and replay protection MUST be used."

In iSCSI, the replay protection is MUST implement (not MUST use):
7.3.1 Data Integrity and Authentication
"The ESP anti-replay service MUST also be implemented."

(I'm not sure if the security or iSCSI should be changed ? I think the
recent tendency was not to impose IPsec requirements unless they are
justified by IPS uniqueness compare to other IPsec usage scenarios)


+++ I assume security draft will be fixed +++
======================

2.3.3.  IKE
"Conformant IP block storage security implementations MUST support IKE
Main Mode and SHOULD support Aggressive Mode."

in iSCSI both MUST be supported:
7.3.3 Policy, Security Associations and Key Management
"Both IKE Main Mode and Aggressive Mode MUST be supported."

(this should be changed in iSCSI - was decided on last
IETF Minneapolis)  

+++ will fix in iSCSI +++

======================

2.3.3.  IKE
"iSCSI security implementations SHOULD support
the ID_USER_FQDN Identity Payload;"

in iSCSI it's MAY:
7.3.3 Policy, Security Associations and Key Management
"ID_USER_FQDN MAY be supported."

(either should be changed for sync)

+++ will fix in iSCSI +++
======================
2.4.1.  CHAP
"If CHAP is used with secret smaller than 96 bits, then IPsec encryption
(according to the implementation requirements in [iSCSI] section 7.3.2)
MUST be used to protect the connection. Moreover, in this case IKE
authentication with group pre-shared keys MUST NOT be used. When CHAP is
used with a secret smaller then 96 bits, a compliant implementation MUST
NOT continue with the iSCSI login unless it can verify that IPsec
encryption is being used to protect the connection."

I suggest to change this according to the last iSCSI text that separates
the administration requirements (first par.) and the implementation
requirements (second par.):

7.2.1 CHAP Considerations
"An administrative entity of an environment in which CHAP is used with a
secret that has less than 96 random bits MUST enforce IPsec encryption
according to the implementation requirements in Section 7.3.2
Confidentiality) to protect the connection. Moreover, in this case IKE
authentication with group pre-shared keys SHOULD NOT be used unless
it is not essential to protect group members against off-line dictionary
attacks by other members.

A compliant implementation SHOULD NOT continue with the login step in
which it should send a CHAP response (CHAP_R - Section 10.5 Challenge
Handshake Authentication Protocol (CHAP)) unless it can verify that
either the CHAP secret is at least 96 bits, or that IPsec encryption
is being used to protect the connection."

+++ I assume security draft will be fixed +++
======================
2.4.2.  SRP
"Upon receiving N and g from the Target, the Initiator MUST verify that
they satisfy the above requirements (and abort the connection
otherwise). This verification MAY start by trying to match them with a
well-known group that satisfies the above requirements. SRP well-known
groups are included in Appendix A."

This should be changed as iSCSI was changed according last consensus
that no one will really implement these checks:
7.2.2 SRP Considerations
"Upon receiving N and g from the Target, the Initiator MUST verify
that they match a well-known group that satisfies the above
requirements and abort the connection if they do not match.
Well- known SRP groups are provided in [SEC-IPS]."

+++ I assume security draft will be fixed +++
======================


  Regards,
    Ofer

Ofer Biran
Storage and Systems Technology  
IBM Research Lab in Haifa  
biran@il.ibm.com  972-4-8296253

Please respond to Elizabeth Rodriguez <elizabeth.g.rodriguez@123mail.net>

Sent by:        owner-ips@ece.cmu.edu

To:        ips@ece.cmu.edu
cc:        Elizabeth.G.Rodriguez@123mail.net
Subject:        IPS-All: Reminder - Security draft last call ends Monday, July 1 at 8am EST



Just a reminder to all to get your last call comments on the security draft in.
The cutoff is Monday July 1 at 8am EST

Thanks,

Elizabeth




------_=_NextPart_001_01C22116.0E780920-- From owner-ips@ece.cmu.edu Mon Jul 1 12:53:59 2002 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA18176 for ; Mon, 1 Jul 2002 12:53:59 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id g61GKsM24808 for ips-outgoing; Mon, 1 Jul 2002 12:20:54 -0400 (EDT) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from ietf.org (odin.ietf.org [132.151.1.176]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id g61AaIw09188 for ; Mon, 1 Jul 2002 06:36:27 -0400 (EDT) Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA21428; Mon, 1 Jul 2002 06:35:30 -0400 (EDT) Message-Id: <200207011035.GAA21428@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; Cc: ips@ece.cmu.edu From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-ietf-ips-iscsi-boot-06.txt Date: Mon, 01 Jul 2002 06:35:29 -0400 Sender: owner-ips@ece.cmu.edu Precedence: bulk --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the IP Storage Working Group of the IETF. Title : Bootstrapping Clients using the iSCSI Protocol Author(s) : P. Sarkar, D. Missimer, C. Sapuntzakis Filename : draft-ietf-ips-iscsi-boot-06.txt Pages : 10 Date : 28-Jun-02 The Small Computer Systems Interface (SCSI) is a popular family of protocols for communicating with I/O devices, especially storage devices. iSCSI is a proposed transport protocol for SCSI that operates on top of TCP[12]. This memo describes a standard mechanism to enable clients to bootstrap themselves using the iSCSI protocol. The goal of this standard is to enable iSCSI boot clients to obtain the information to open an iSCSI session with the iSCSI boot server, assuming this information is not available. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-ips-iscsi-boot-06.txt To remove yourself from the IETF Announcement list, send a message to ietf-announce-request with the word unsubscribe in the body of the message. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-ips-iscsi-boot-06.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-ips-iscsi-boot-06.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <20020628142002.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-ips-iscsi-boot-06.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-ips-iscsi-boot-06.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <20020628142002.I-D@ietf.org> --OtherAccess-- --NextPart-- From owner-ips@ece.cmu.edu Mon Jul 1 12:54:03 2002 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA18190 for ; Mon, 1 Jul 2002 12:54:03 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id g61GKpe24801 for ips-outgoing; Mon, 1 Jul 2002 12:20:51 -0400 (EDT) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from ietf.org (odin.ietf.org [132.151.1.176]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id g61AaYw09224 for ; Mon, 1 Jul 2002 06:36:34 -0400 (EDT) Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA21515; Mon, 1 Jul 2002 06:35:46 -0400 (EDT) Message-Id: <200207011035.GAA21515@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; Cc: ips@ece.cmu.edu From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-ietf-ips-iscsi-name-disc-06.txt Date: Mon, 01 Jul 2002 06:35:46 -0400 Sender: owner-ips@ece.cmu.edu Precedence: bulk --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the IP Storage Working Group of the IETF. Title : iSCSI Naming and Discovery Author(s) : M. Bakke et al. Filename : draft-ietf-ips-iscsi-name-disc-06.txt Pages : 20 Date : 28-Jun-02 This document provides examples of iSCSI [7] name construction and discussion of discovery of iSCSI resources (targets) by iSCSI initiators. This document complements the iSCSI protocol draft. Flexibility is the key guiding principle behind this document. That is, an effort has been made to satisfy the needs of both small isolated environments, as well as large environments requiring secure/scalable solutions. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-ips-iscsi-name-disc-06.txt To remove yourself from the IETF Announcement list, send a message to ietf-announce-request with the word unsubscribe in the body of the message. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-ips-iscsi-name-disc-06.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-ips-iscsi-name-disc-06.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <20020628142033.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-ips-iscsi-name-disc-06.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-ips-iscsi-name-disc-06.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <20020628142033.I-D@ietf.org> --OtherAccess-- --NextPart-- From owner-ips@ece.cmu.edu Mon Jul 1 12:54:12 2002 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA18208 for ; Mon, 1 Jul 2002 12:54:11 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id g61GLa724872 for ips-outgoing; Mon, 1 Jul 2002 12:21:36 -0400 (EDT) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from mx01-a.netapp.com (mx01-a.netapp.com [198.95.226.53]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id g61FAfw20594 for ; Mon, 1 Jul 2002 11:10:41 -0400 (EDT) Received: from frejya.corp.netapp.com (frejya [10.10.20.91]) by mx01-a.netapp.com (8.12.3/8.12.3/NTAP-1.4) with ESMTP id g61FAZqh017306 for ; Mon, 1 Jul 2002 08:10:35 -0700 (PDT) Received: from tahoe.corp.netapp.com (localhost [127.0.0.1]) by frejya.corp.netapp.com (8.12.2/8.12.2/NTAP-1.4) with ESMTP id g61FAZfK006082 for ; Mon, 1 Jul 2002 08:10:35 -0700 (PDT) Received: by tahoe.corp.netapp.com with Internet Mail Service (5.5.2650.21) id ; Mon, 1 Jul 2002 08:05:14 -0700 Message-ID: <02740A3D0809D5118C7C00034707E9F3038F4E1C@ussvlexc10.corp.netapp.com> From: "Sankar, Ranga" To: "'ips@ece.cmu.edu'" Subject: plug fest and draft 14. Date: Mon, 1 Jul 2002 08:09:31 -0700 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-ips@ece.cmu.edu Precedence: bulk With draft 14 out will the plugfest be at Draft 13 or Draft 14? -ranga From owner-ips@ece.cmu.edu Mon Jul 1 12:54:18 2002 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA18235 for ; Mon, 1 Jul 2002 12:54:18 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id g61GKlA24787 for ips-outgoing; Mon, 1 Jul 2002 12:20:47 -0400 (EDT) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from ietf.org (odin.ietf.org [132.151.1.176]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id g61AaRw09201 for ; Mon, 1 Jul 2002 06:36:27 -0400 (EDT) Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA21494; Mon, 1 Jul 2002 06:35:39 -0400 (EDT) Message-Id: <200207011035.GAA21494@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; Cc: ips@ece.cmu.edu From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-ietf-ips-iscsi-string-prep-02.txt Date: Mon, 01 Jul 2002 06:35:39 -0400 Sender: owner-ips@ece.cmu.edu Precedence: bulk --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the IP Storage Working Group of the IETF. Title : String Profile for iSCSI Names Author(s) : M. Bakke Filename : draft-ietf-ips-iscsi-string-prep-02.txt Pages : 8 Date : 28-Jun-02 The iSCSI protocol provides a way for hosts to access SCSI devices over an IP network. The iSCSI end-points, called initiators and targets, each have a globally-unique name that must be transcribable, as well as easily compared. This document describes how to prepare internationlized iSCSI names to increase the likelihood that name input and comparison work in ways that make sense for typical users throughout the world. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-ips-iscsi-string-prep-02.txt To remove yourself from the IETF Announcement list, send a message to ietf-announce-request with the word unsubscribe in the body of the message. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-ips-iscsi-string-prep-02.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-ips-iscsi-string-prep-02.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <20020628142024.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-ips-iscsi-string-prep-02.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-ips-iscsi-string-prep-02.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <20020628142024.I-D@ietf.org> --OtherAccess-- --NextPart-- From owner-ips@ece.cmu.edu Mon Jul 1 12:54:29 2002 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA18258 for ; Mon, 1 Jul 2002 12:54:29 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id g61GKwt24816 for ips-outgoing; Mon, 1 Jul 2002 12:20:58 -0400 (EDT) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from ietf.org (odin.ietf.org [132.151.1.176]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id g61AaMw09191 for ; Mon, 1 Jul 2002 06:36:26 -0400 (EDT) Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA21454; Mon, 1 Jul 2002 06:35:34 -0400 (EDT) Message-Id: <200207011035.GAA21454@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; Cc: ips@ece.cmu.edu From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-ietf-ips-fcmgmt-mib-02.txt Date: Mon, 01 Jul 2002 06:35:34 -0400 Sender: owner-ips@ece.cmu.edu Precedence: bulk --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the IP Storage Working Group of the IETF. Title : Fibre Channel Management MIB Author(s) : K. McCloghrie Filename : draft-ietf-ips-fcmgmt-mib-02.txt Pages : 76 Date : 28-Jun-02 This memo defines a portion of the Management Information Base (MIB) for use with network management protocols in the Internet community. In particular, it describes managed objects for informantion related to Fibre Channel. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-ips-fcmgmt-mib-02.txt To remove yourself from the IETF Announcement list, send a message to ietf-announce-request with the word unsubscribe in the body of the message. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-ips-fcmgmt-mib-02.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-ips-fcmgmt-mib-02.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <20020628142014.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-ips-fcmgmt-mib-02.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-ips-fcmgmt-mib-02.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <20020628142014.I-D@ietf.org> --OtherAccess-- --NextPart-- From owner-ips@ece.cmu.edu Mon Jul 1 13:00:44 2002 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA18559 for ; Mon, 1 Jul 2002 13:00:43 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id g61GkxC26429 for ips-outgoing; Mon, 1 Jul 2002 12:46:59 -0400 (EDT) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from d12lmsgate-2.de.ibm.com (d12lmsgate-2.de.ibm.com [195.212.91.200]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id g61Gkvw26421 for ; Mon, 1 Jul 2002 12:46:57 -0400 (EDT) Received: from d12relay02.de.ibm.com (d12relay02.de.ibm.com [9.165.215.23]) by d12lmsgate-2.de.ibm.com (8.12.3/8.12.3) with ESMTP id g61Gknu9077822; Mon, 1 Jul 2002 18:46:49 +0200 Received: from d10hubm1.telaviv.ibm.com (d10ml001.telaviv.ibm.com [9.148.216.55]) by d12relay02.de.ibm.com (8.11.1m3/NCO/VER6.1) with ESMTP id g61Gklc84248; Mon, 1 Jul 2002 18:46:48 +0200 To: kevin_lemay@agilent.com Cc: ips@ece.cmu.edu MIME-Version: 1.0 Subject: Re: iSCSI: Question on login min/Max X-Mailer: Lotus Notes Release 5.0.9 November 16, 2001 From: "Julian Satran" Message-ID: Date: Mon, 1 Jul 2002 19:46:46 +0300 X-MIMETrack: Serialize by Router on D10ML001/10/M/IBM(Release 5.0.9a |January 7, 2002) at 01/07/2002 19:46:48, Serialize complete at 01/07/2002 19:46:48 Content-Type: multipart/alternative; boundary="=_alternative 005B2F05C2256BE9_=" Sender: owner-ips@ece.cmu.edu Precedence: bulk This is a multipart message in MIME format. --=_alternative 005B2F05C2256BE9_= Content-Type: text/plain; charset="us-ascii" Kevin, That part has some history. Several drafts ago the selection was "by rule" - i.e., each of the parties stated what it wanted and the result was based on the rule (that both know). This scheme, although simple, was felt as unnatural by many readers (implementers?) and we changed it to the selection by the responder - i.e., the responder selects the "right" value - respecting some rules. Obviously then the rule can't be "the maximum/minimum/other of two values" as there are no two values on the wire and I felt that the best way to express this is to state the constraint the responder has to respect. This was the text you found in draft 13. Bob Russell felt that a succinct statement stating this restriction in line with the Scope, Default etc. will be simpler to follow and I think he is right.. The new text is the one you see in draft 14. Except for one rule that was stated wrong (a typo) and is now corrected there is no difference between 13 and 14. And yes your interpretation of the rule is correct - at the sequence you show the initiator is supposed to close (protocol error). Again - we did not have two offered numbers for a long time. Julo kevin_lemay@agilent.com 07/01/2002 06:16 PM Please respond to kevin_lemay To: Julian Satran/Haifa/IBM@IBMIL cc: ips@ece.cmu.edu Subject: iSCSI: Question on login min/Max Julian, In draft v14, page 210, The following text was added: "Result function wherever mentioned states the function that can be applied to check the validity of the responder selection. Minimum means that the selected value cannot exceed the offered value. Maximum means that the selected value cannot be lower than the offered value." What drove this change? This is a departure from what it was previously where we could just take the min/max of the two offered numbers. So if I interpret this correctly, if: Init -> DefaultTime2Wait=2 (func is Max) Target -> DefaultTime2Wait=1 Init detects an error and closes the TCP connection. Correct? Kevin --=_alternative 005B2F05C2256BE9_= Content-Type: text/html; charset="us-ascii"
Kevin,

That part has some history.

Several drafts ago the selection was "by rule" - i.e., each of the parties stated what it wanted and the result was based on the rule (that both know).
This scheme, although simple, was felt as unnatural by many readers (implementers?) and we changed it to the selection by the responder - i.e., the responder selects the "right" value - respecting some rules. Obviously then the rule can't be "the maximum/minimum/other  of two values" as there are no two values on the wire and I felt that the best way to express this is to state the constraint the responder has to respect. This was the text you found in draft 13.

Bob Russell felt that a succinct statement stating this restriction in line with the Scope, Default etc. will be  simpler to follow and I think he is right..
The new text is the one you see in draft 14.  Except for one rule that was stated wrong (a typo) and is now corrected there is no difference between 13 and 14.

And yes your interpretation of the rule is correct - at the sequence you show the initiator is supposed to close (protocol error).

Again - we did not have two offered numbers for a long time.

Julo


kevin_lemay@agilent.com

07/01/2002 06:16 PM
Please respond to kevin_lemay

       
        To:        Julian Satran/Haifa/IBM@IBMIL
        cc:        ips@ece.cmu.edu
        Subject:        iSCSI: Question on login min/Max

       


Julian,

In draft v14, page 210, The following text was added:

"Result function wherever mentioned states the function that can be applied to check the validity of the responder selection. Minimum means that the selected value cannot exceed the offered value. Maximum means that the selected value cannot be lower than the offered value."

What drove this change? This is a departure from what it was previously where we could just take the min/max of the two offered numbers.

So if I interpret this correctly, if:

Init   -> DefaultTime2Wait=2 (func is Max)
Target -> DefaultTime2Wait=1

Init detects an error and closes the TCP connection.

Correct?

Kevin

--=_alternative 005B2F05C2256BE9_=-- From owner-ips@ece.cmu.edu Mon Jul 1 13:41:45 2002 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA21383 for ; Mon, 1 Jul 2002 13:41:45 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id g61H8k027705 for ips-outgoing; Mon, 1 Jul 2002 13:08:46 -0400 (EDT) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from msgbas1.cos.agilent.com (msgbas1x.cos.agilent.com [192.25.240.36]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id g61H8jw27700 for ; Mon, 1 Jul 2002 13:08:45 -0400 (EDT) Received: from msgrel1t.cos.agilent.com (msgrel1t.cos.agilent.com [130.29.152.157]) by msgbas1.cos.agilent.com (Postfix) with ESMTP id 870EBBCA1; Mon, 1 Jul 2002 11:08:44 -0600 (MDT) Received: from axcsbh6.cos.agilent.com (axcsbh6.cos.agilent.com [130.29.152.171]) by msgrel1t.cos.agilent.com (Postfix) with SMTP id E2B7B1D0C; Mon, 1 Jul 2002 11:08:43 -0600 (MDT) Received: from 130.29.152.171 by axcsbh6.cos.agilent.com (InterScan E-Mail VirusWall NT); Mon, 01 Jul 2002 11:08:42 -0600 Received: by axcsbh6.cos.agilent.com with Internet Mail Service (5.5.2653.19) id ; Mon, 1 Jul 2002 11:08:42 -0600 Message-ID: <1BEBA5E8600DD4119A50009027AF54A00CB26B59@axcs04.cos.agilent.com> From: pat_thaler@agilent.com To: kevin_lemay@agilent.com, Julian_Satran@il.ibm.com Cc: ips@ece.cmu.edu Subject: RE: iSCSI: Question on login min/Max Date: Mon, 1 Jul 2002 11:08:39 -0600 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="ISO-8859-1" Sender: owner-ips@ece.cmu.edu Precedence: bulk Kevin, I don't think the text changed the meaning of the draft. The following was in draft 10 under 2.2.4 Text mode negotiation: For numerical and single literal negotiations, the responding party MUST respond with the required key. The value it selects, based on the selection rule specific to the key, becomes the negotiation result. The selection of a value not admissible under the selection rules is considered a protocol error and is handled accordingly. Your example: Init -> DefaultTime2Wait=2 (func is Max) Target -> DefaultTime2Wait=1 would have been a protocol error and closed the connection under the draft 10 rules and later. (I think this was in earlier drafts as well. I just didn't bother to look farther back.) The impact of the new text is just editorial. Regards, Pat -----Original Message----- From: kevin_lemay@agilent.com [mailto:kevin_lemay@agilent.com] Sent: Monday, July 01, 2002 8:17 AM To: Julian_Satran@il.ibm.com Cc: ips@ece.cmu.edu Subject: iSCSI: Question on login min/Max Julian, In draft v14, page 210, The following text was added: "Result function wherever mentioned states the function that can be applied to check the validity of the responder selection. Minimum means that the selected value cannot exceed the offered value. Maximum means that the selected value cannot be lower than the offered value." What drove this change? This is a departure from what it was previously where we could just take the min/max of the two offered numbers. So if I interpret this correctly, if: Init -> DefaultTime2Wait=2 (func is Max) Target -> DefaultTime2Wait=1 Init detects an error and closes the TCP connection. Correct? Kevin From owner-ips@ece.cmu.edu Mon Jul 1 13:44:55 2002 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA21623 for ; Mon, 1 Jul 2002 13:44:55 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id g61HNrO28546 for ips-outgoing; Mon, 1 Jul 2002 13:23:53 -0400 (EDT) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from sj-msg-core-1.cisco.com (sj-msg-core-1.cisco.com [171.71.163.11]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id g61HNow28539 for ; Mon, 1 Jul 2002 13:23:51 -0400 (EDT) Received: from sponge.cisco.com (IDENT:mirapoint@sponge.cisco.com [64.101.128.87]) by sj-msg-core-1.cisco.com (8.12.2/8.12.2) with ESMTP id g61HNiQt000637; Mon, 1 Jul 2002 10:23:44 -0700 (PDT) Received: from DAPW2K3 (dhcp-161-44-68-129.cisco.com [161.44.68.129]) by sponge.cisco.com (Mirapoint) with SMTP id ABA79757; Mon, 1 Jul 2002 12:23:43 -0500 (CDT) From: "Dave Peterson" To: "Sankar, Ranga" , Subject: RE: plug fest and draft 14. Date: Mon, 1 Jul 2002 12:23:43 -0500 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0) Importance: Normal x-mimeole: Produced By Microsoft MimeOLE V6.00.2600.0000 In-Reply-To: <02740A3D0809D5118C7C00034707E9F3038F4E1C@ussvlexc10.corp.netapp.com> Sender: owner-ips@ece.cmu.edu Precedence: bulk Content-Transfer-Encoding: 7bit At this point in time the plugfest will remain at draft 13, i.e., no draft 14. Thanks...dap > -----Original Message----- > From: owner-ips@ece.cmu.edu [mailto:owner-ips@ece.cmu.edu]On Behalf Of > Sankar, Ranga > Sent: Monday, July 01, 2002 10:10 AM > To: 'ips@ece.cmu.edu' > Subject: plug fest and draft 14. > > > > > With draft 14 out will the plugfest be at Draft 13 or Draft 14? > > -ranga From owner-ips@ece.cmu.edu Mon Jul 1 13:45:02 2002 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA21637 for ; Mon, 1 Jul 2002 13:44:58 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id g61H5CZ27516 for ips-outgoing; Mon, 1 Jul 2002 13:05:12 -0400 (EDT) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from snake012.odetics.com (snake012.odetics.com [198.58.66.53]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id g61H59w27512 for ; Mon, 1 Jul 2002 13:05:09 -0400 (EDT) Received: by snake012.odetics.com with Internet Mail Service (5.5.2655.55) id ; Mon, 1 Jul 2002 10:05:05 -0700 Message-ID: <6F0AA176DA68704884B7507AE6907E18081882@snake012.odetics.com> From: Christina Helbig To: "'Black_David@emc.com'" , ips@ece.cmu.edu Subject: RE: IPS-All: Reminder - Security draft last call ends Monday, Jul y 1 at 8am EST Date: Mon, 1 Jul 2002 10:05:04 -0700 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2655.55) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-ips@ece.cmu.edu Precedence: bulk Hi, David I think it is not right that "any key is vulnerable to compromise from overuse, even if that use is only as part of generation of other keys." Lets look for example simple to encryption with AES: there is no way known better than brute force to get the key even if this key is used for encryption of arbitrary many plaintexts and all plaintext-ciphertext-pairs are known. Correct me if I'm wrong. Greetings Christina > -----Original Message----- > From: Black_David@emc.com [mailto:Black_David@emc.com] > Sent: Monday, July 01, 2002 6:56 AM > To: Christina Helbig; ips@ece.cmu.edu > Subject: RE: IPS-All: Reminder - Security draft last call ends Monday, > Jul y 1 at 8am EST > > > Excerpting the important point: > > > o.k. Lets see what I have understand now: If PFS by rekeying is not > > mandatory to use (and this is the situation) then you can > established with > > DH exchange a key (referred here now by me as long-term > key) and use other > > protocols, e.g. Basic Quick Mode or Stealthkey, to derive > multiple keys > > (referred here as short-term keys) from the long-term key. > The compromise > > of short-term keys must not compromise the long-term key. > This formulation > > should be also conform with Paul Koning's comment. > > Yes, with a slight clarification of "must not" - "when properly used, > compromise of short-term keys must not compromise the long-term > key". Eventually, any key is vulnerable to compromise from overuse, > even if that use is only as part of generation of other keys. > > Thanks, > --David > --------------------------------------------------- > David L. Black, Senior Technologist > EMC Corporation, 42 South St., Hopkinton, MA 01748 > +1 (508) 249-6449 *NEW* FAX: +1 (508) 497-8500 > black_david@emc.com Cell: +1 (978) 394-7754 > --------------------------------------------------- > > > -----Original Message----- > > From: Christina Helbig [mailto:cbh@zyfer.com] > > Sent: Friday, June 28, 2002 7:37 PM > > To: 'Black_David@emc.com'; ips@ece.cmu.edu > > Subject: RE: IPS-All: Reminder - Security draft last call > ends Monday, > > Jul y 1 at 8am EST > > > > > > David, thank you for the time for answer. Comments inside: > > > > > -----Original Message----- > > > From: Black_David@emc.com [mailto:Black_David@emc.com] > > > Sent: Friday, June 28, 2002 1:07 PM > > > To: Christina Helbig; ips@ece.cmu.edu > > > Subject: RE: IPS-All: Reminder - Security draft last call > > ends Monday, > > > Jul y 1 at 8am EST > > > > > > > > > Christina, > > > > > > Thanks for your comments. I don't think there are > technical issues > > > in the two areas of concern you've raised - could you please check > > > the following discussion and see if it's ok? > > > > > > I. Rekeying and PFS > > > > > > The requirement for PFS is "MUST implement" (must support) > > > not "MUST use". > > > Christina's text appears to be objecting to a "MUST use" > > > requirement - if > > > so, this is not a problem, as the requirement is "MUST implement", > > > which is the intention of the "must support" wording in > > section 2.1 of > > > the security draft. > > o.k. I understood. > > > > > > II. Manual keying and PFS > > > > > > Section 5.9 was not intended to provide an exception to the > > > "MUST NOT use" > > > manual keying requirement stated in Section 2.3.3. The > > > Section 5.9 text > > > should be clarified to make this clear. > > > > > o.k. > > > > Second, if PFS would be not mandatory by rekeying then you > > > can use manual > > > > keying together with other protocols for frequent > > rekeying, e.g. our > > > > proposal. > > > > > > I don't think there's an issue here, but some terminology > > > clarification is > > > in order - in essence properly designed "manual keying > together with > > > other protocols for frequent rekeying" is "preshared > keying" and is > > > allowed (in fact it's required). > > > > > > The term "manual keying" describes situations in which keys are > > > preconfigured > > > (manually) and then those keys are used as the session keying > > > material for > > > the SAs that carry traffic - rekeying is accomplished by > (manually) > > > configuring new keys. Manual keying is forbidden (MUST > NOT use) for > > > IP Storage due to the inability to automatically generate > new secure > > > session keys. > > > > > > The term "preshared keying" describes situations in which the > > > preconfigured > > > keys are used to derive multiple session keys in a fashion > > > that compromise > > > of a session key does not imply compromise or serious > > weakening of the > > > preconfigured keys (IKE uses a keyed prf [usually a hash] to > > > obtain this > > > property). Pre-shared keying is REQUIRED (MUST implement). > > > > > o.k. Lets see what I have understand now: If PFS by rekeying is not > > mandatory to use (and this is the situation) then you can > > established with > > DH exchange a key (referred here now by me as long-term key) > > and use other > > protocols, e.g. Basic Quick Mode or Stealthkey, to derive > > multiple keys > > (referred here as short-term keys) from the long-term key . > > The compromise > > of short-term keys must not compromise the long-term key. > > This formulation > > should be also conform with Paul Koenigs comment. > > > The StealthKey mechanism described in > > > draft-helbig-stealthkey-01.txt is > > > a preshared keying mechanism that can automatically generate new > > > (short-term) session keys, and hence is not forbidden by the > > > requirement > > > that manual keying MUST NOT be used. OTOH, StealthKey is not > > > specified > > > in any of the IP Storage protocol drafts. > > > > > o.k. We try to get some attention from the IPSec working > > group for this > > proposal. I think this is the right WG. I was only concerned > > that we have no > > chance to use this for IP Storage protocols but the right > > understanding of > > Internet-Standards is really a skill after long-training. > > Thank you > > Christina > > > Thanks, > > > --David > > > --------------------------------------------------- > > > David L. Black, Senior Technologist > > > EMC Corporation, 42 South St., Hopkinton, MA 01748 > > > +1 (508) 249-6449 *NEW* FAX: +1 (508) 497-8500 > > > black_david@emc.com Cell: +1 (978) 394-7754 > > > --------------------------------------------------- > > > > > > > -----Original Message----- > > > > From: Christina Helbig [mailto:cbh@zyfer.com] > > > > Sent: Friday, June 28, 2002 2:03 PM > > > > To: 'Elizabeth Rodriguez'; ips@ece.cmu.edu > > > > Subject: RE: IPS-All: Reminder - Security draft last call > > > ends Monday, > > > > Jul y 1 at 8am EST > > > > > > > > > > > > These are my IPS Security draft last call comments. I'm also > > > > impressed about > > > > the good work others have done. > > > > > > > > I have problems with following text about rekeying and > > > manual keying. > > > > > > > > I. Rekeying and PFS: > > > > > > > > First there are two statements, which I think are not > consistent: > > > > > > > > a) 2.1. Security requirements > > > > ...The IP block storage security protocols must support perfect > > > > forward secrecy in the rekeying process. > > > > > > > > b) 2.2. Resource constraints > > > > Computational horsepower should be available to perform a > > > > reasonable amount > > > > of exponentiation as part of authentication and key > derivation for > > > > connection setup. The same is true of rekeying, although the > > > > ability to avoid exponentiation for rekeying may be > desirable (but > > > > is not an absolute requirement). > > > > > > > > In RFC 2409 is a clear definition of PFS for IKE: > > > > 3.3 Perfect Forward Secrecy > > > > When used in the memo Perfect Forward Secrecy (PFS) refers to > > > > the notion > > > > that compromise of a single key will permit access to only > > > > data protected by > > > > a single key. For PFS to exist the key used to protect > > > > transmission of data > > > > MUST NOT be used to derive any additional keys, and if the > > > key used to > > > > protect transmission of data was derived from some other > > > > keying material, > > > > that material MUST NOT be used to derive any more keys. > > > > > > > > If a) is the requirement than you can never avoid > > exponentiation for > > > > rekeying because otherwise you must use keying material to > > > > derive more than > > > > one key. > > > > > > > > Second I think PFS should not be a requirement for rekeying, > > > > only a nice to > > > > have. Why? > > > > > > > > There is currently a discussion about PFS and rekeying by SOI > > > > in the IPSec > > > > list and here is what I wrote and nobody opposed me (what not > > > > mean that I'm > > > > right ;-) > > > > > > > > "IMO there is a mix of the issue of PFS and rekeying in the > > > > discussion. > > > > 1. Rekeying is needed if the amount of with the same key > > > > encrypted data goes > > > > beyond specific values, because of some passive attacks > > against the > > > > encrypted data (dependable also of the encryption algorithm > > > > and its mode) > > > > and the active attack of replaying by ESP after the sequence > > > > number counter > > > > has started again. > > > > 2. The need for PFS by the process of rekeying is not based > > > > on protection > > > > against this attacks under 1. > > > > 3. The property of PFS is an advantage in the case of > > > > unauthorized access to > > > > secret information used to generate the communication keys. > > > > If this secret > > > > information can be secured against unauthorized access then > > > > rekeying can be > > > > done without the property of PFS. > > > > 4. On the other hand there is always a need by IKE to > > protect secret > > > > information against unauthorized access used for phase 1 > > > > authentication. If > > > > the protection of this secret information in the system is > > > > sufficient why > > > > should there the protection of another secret information be > > > > insufficient? > > > > > > > > My proposal is: Rekeying is necessary under specific > > > > circumstances, which > > > > should be described. PFS is not needed if the secret > > > > information used to > > > > generate different communication keys is protected against > > > > unauthorized > > > > access in the same manner like the phase 1 > authentication secret." > > > > > > > > The main reason for avoiding mandatory PFS by rekeying, I > > > think is the > > > > computational overhead. I have mentioned in the SOI discussion: > > > > > > > > "I found different statements about the CPU time > necessary for one > > > > exponentiation between 30ms and some seconds. In the > > > > draft-ietf-ips-security-13.txt it's time for rekeying for one > > > > SA by 10Gbps > > > > and 3DES in CBC mode all 27.5s or before 2^35 bytes are sent. > > > > Assume the > > > > case of some hundred SAs per peer with permanently > > > > irregularly distributed > > > > traffic between the SAs. Then rekeying at time is necessary > > > > for every SA all > > > > 27.5 s. This looks like a computational border, so you must have > > > > amount-based rekeying in this case and encrypted bytes or > > > > blocks must be > > > > counted for every SA. Is that a computational border too?" > > > > > > > > There was no answer like "This is no problem". > > > > > > > > Last I like to mention the possibility to rekey without > > > exchanges (and > > > > without PFS). We have developed a protocol for frequent > > > > rekeying without > > > > exchanges and would be happy if some folks could have a look > > > > at this and say > > > > if it makes sense or not > > > > ( > > thkey-01.txt>) > > > > > > II. Manual keying and PFS: > > > > > > First there are again two statements, which I think are not > > > consistent: > > > > > > > > > c) 2.3.3. IKE > > > ...Manual keying MUST NOT be used since it does not provide > > > the necessary > > > rekeying support. > > > > > > d) 5.9 Use of AES in counter mode > > > > > > ...The implication of this is that it is almost always an > > error to use > > > IPsec manual keying with counter mode, except when the > > implementation > > > takes heroic measures to maintain state across sessions. > > > > > > That means there is an exception from MUST NOT? > > > > > > Second, if PFS would be not mandatory by rekeying then you > > > can use manual > > > keying together with other protocols for frequent > rekeying, e.g. our > > > proposal. > > > Thank you for your patient regarding my bad English. > > > Christina > > > > > > > -----Original Message----- > > > > From: Elizabeth Rodriguez > [mailto:elizabeth.g.rodriguez@123mail.net] > > > Sent: Thursday, June 27, 2002 2:41 PM > > > To: ips@ece.cmu.edu > > > Cc: Elizabeth.G.Rodriguez@123mail.net > > > Subject: IPS-All: Reminder - Security draft last call ends > > > Monday, July > > > 1 at 8am EST > > > > > > > > > Just a reminder to all to get your last call comments on the > > > security draft in. > > > The cutoff is Monday July 1 at 8am EST > > > > > > Thanks, > > > > > > Elizabeth > > > > > > > > > From owner-ips@ece.cmu.edu Mon Jul 1 16:11:53 2002 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA00603 for ; Mon, 1 Jul 2002 16:11:52 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id g61JjRx06341 for ips-outgoing; Mon, 1 Jul 2002 15:45:28 -0400 (EDT) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from mxic2.corp.emc.com (mxic2.isus.emc.com [128.221.31.40]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id g61JjRw06337 for ; Mon, 1 Jul 2002 15:45:27 -0400 (EDT) Received: by mxic2.corp.emc.com with Internet Mail Service (5.5.2653.19) id ; Mon, 1 Jul 2002 15:45:19 -0400 Message-ID: <277DD60FB639D511AC0400B0D068B71E0564BFF9@CORPMX14> From: Black_David@emc.com To: ni1d@arrl.net Cc: ips@ece.cmu.edu Subject: RE: FW: IPS-All: Reminder - Security draft last call ends Monday, Jul y 1 at 8am EST Date: Mon, 1 Jul 2002 15:43:26 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-ips@ece.cmu.edu Precedence: bulk > > 2.3.1. Transforms "When ESP is utilized, per-packet data origin > > authentication, integrity and replay protection MUST be used." > > > > In iSCSI, the replay protection is MUST implement (not MUST use): > > 7.3.1 Data Integrity and Authentication > > "The ESP anti-replay service MUST also be implemented." > > > > (I'm not sure if the security or iSCSI should be changed ? > I think the recent tendency was not to impose IPsec requirements unless > they are justified by IPS uniqueness compare to other IPsec usage scenarios) > > > > > > +++ I assume security draft will be fixed +++ > > Because of the Bellovin attack on encryption-only ESP, I believe that > the first of the two statements is the right one. > > There's a lot of argument that integrity should be mandatory in ESP > across the board. The reason why it currently isn't (at least as far > as I understand from Steve Kent) is that integrity in the IPsec layer > is superfluous if cryptographic integrity is provided at a higher > layer. That case doesn't apply in IPS, so the risk of Bellovin's > attack is real. Paul - this is only about the anti-replay service, it does not propose to change the current iSCSI and IPS Security draft mandates that integrity be "mandatory in ESP across the board". Are you concerned that anti-replay should also be mandatory across the board? Thanks, --David --------------------------------------------------- David L. Black, Senior Technologist EMC Corporation, 42 South St., Hopkinton, MA 01748 +1 (508) 249-6449 *NEW* FAX: +1 (508) 497-8500 black_david@emc.com Cell: +1 (978) 394-7754 --------------------------------------------------- From owner-ips@ece.cmu.edu Mon Jul 1 16:12:14 2002 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA00648 for ; Mon, 1 Jul 2002 16:12:09 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id g61JS6q05366 for ips-outgoing; Mon, 1 Jul 2002 15:28:06 -0400 (EDT) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from cygnus.equallogic.com (cygnus.equallogic.com [65.170.102.10]) by ece.cmu.edu (8.11.0/8.10.2) with SMTP id g61JS3w05362 for ; Mon, 1 Jul 2002 15:28:03 -0400 (EDT) Received: from cygnus.equallogic.com (localhost.localdomain [127.0.0.1]) by cygnus.equallogic.com (8.11.6/8.11.6) with ESMTP id g61JRvC11547 for ; Mon, 1 Jul 2002 15:27:57 -0400 Received: from deneb.dev.equallogic.com (deneb.dev.equallogic.com [172.16.1.99]) by cygnus.equallogic.com (8.11.6/8.11.6) with ESMTP id g61JRvQ11538; Mon, 1 Jul 2002 15:27:57 -0400 Received: from PKONING.equallogic.com (localhost.localdomain [127.0.0.1]) by deneb.dev.equallogic.com (8.11.6/8.11.6) with ESMTP id g61JRtF28470; Mon, 1 Jul 2002 15:27:56 -0400 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <15648.44335.899000.475741@gargle.gargle.HOWL> Date: Mon, 1 Jul 2002 15:27:43 -0400 From: Paul Koning To: Black_David@emc.com Cc: ips@ece.cmu.edu Subject: Re: FW: IPS-All: Reminder - Security draft last call ends Monday, Jul y 1 at 8am EST References: <277DD60FB639D511AC0400B0D068B71E0564BFF5@CORPMX14> X-Mailer: VM 6.95 under 21.4 (patch 3) "Academic Rigor" XEmacs Lucid Sender: owner-ips@ece.cmu.edu Precedence: bulk Content-Transfer-Encoding: 7bit Excerpt of message (sent 1 July 2002) by Black_David@emc.com: > One more round of lining up the iSCSI and IPS Security drafts. > > --David > > -----Original Message----- > From: Julian Satran [mailto:Julian_Satran@il.ibm.com] > Sent: Sunday, June 30, 2002 7:27 AM > To: Ofer Biran > Cc: bernard_aboba@hotmail.com; Black_David@emc.com; Elizabeth Rodriguez > Subject: Re: IPS-All: Reminder - Security draft last call ends Monday, July > 1 at 8am EST > > > > see comments in text - Julo > > > > Ofer Biran > > > 06/30/2002 11:43 AM > > > > To: Elizabeth Rodriguez , > Black_David@emc.com, bernard_aboba@hotmail.com, Julian > Satran/Haifa/IBM@IBMIL > cc: > From: Ofer Biran/Haifa/IBM@IBMIL > Subject: Re: IPS-All: Reminder - Security draft last call > ends Monday, July 1 at 8am EST Link > C2256BE50077269A> > > > > > > > > > These comments are from mandatory statements sync check > I made with the iSCSI draft: > > ====================== > > 2.3.1. Transforms > "When ESP is utilized, per-packet data origin authentication, integrity > and replay protection MUST be used." > > In iSCSI, the replay protection is MUST implement (not MUST use): > 7.3.1 Data Integrity and Authentication > "The ESP anti-replay service MUST also be implemented." > > (I'm not sure if the security or iSCSI should be changed ? I think the > recent tendency was not to impose IPsec requirements unless they are > justified by IPS uniqueness compare to other IPsec usage scenarios) > > > +++ I assume security draft will be fixed +++ Because of the Bellovin attack on encryption-only ESP, I believe that the first of the two statements is the right one. There's a lot of argument that integrity should be mandatory in ESP across the board. The reason why it currently isn't (at least as far as I understand from Steve Kent) is that integrity in the IPsec layer is superfluous if cryptographic integrity is provided at a higher layer. That case doesn't apply in IPS, so the risk of Bellovin's attack is real. paul From owner-ips@ece.cmu.edu Mon Jul 1 16:14:50 2002 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA00775 for ; Mon, 1 Jul 2002 16:14:50 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id g61JgRa06152 for ips-outgoing; Mon, 1 Jul 2002 15:42:27 -0400 (EDT) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from mailhub.lss.emc.com (xdch.emc.com [168.159.1.79]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id g61JgQw06147 for ; Mon, 1 Jul 2002 15:42:26 -0400 (EDT) Received: from emc.com (emcmail.lss.emc.com [168.159.48.78]) by mailhub.lss.emc.com (Switch-2.2.0/Switch-2.2.0) with ESMTP id g61Jg7X29232; Mon, 1 Jul 2002 15:42:08 -0400 (EDT) Received: from mxic1.isus.emc.com ([168.159.129.100]) by emc.com (8.10.1/8.10.1) with ESMTP id g61Jfx717812; Mon, 1 Jul 2002 15:41:59 -0400 (EDT) Received: by MXIC1 with Internet Mail Service (5.5.2653.19) id ; Mon, 1 Jul 2002 15:40:08 -0400 Message-ID: <277DD60FB639D511AC0400B0D068B71E0564BFF8@CORPMX14> From: Black_David@emc.com To: cbh@zyfer.com, ips@ece.cmu.edu Subject: RE: IPS-All: Reminder - Security draft last call ends Monday, Jul y 1 at 8am EST Date: Mon, 1 Jul 2002 15:40:03 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-ips@ece.cmu.edu Precedence: bulk I think we're close to violent agreement. For the AES example, as the amount of material encrypted with the same key goes up, the attacker has more ciphertext from the same key to work with - admittedly, with AES the incremental advantage of more ciphertext is rather small and it may take enormous amounts to gain any real advantage over brute force. In any case, this is not an issue with the IPS Security draft. Thanks, --David --------------------------------------------------- David L. Black, Senior Technologist EMC Corporation, 42 South St., Hopkinton, MA 01748 +1 (508) 249-6449 *NEW* FAX: +1 (508) 497-8500 black_david@emc.com Cell: +1 (978) 394-7754 --------------------------------------------------- > -----Original Message----- > From: Christina Helbig [mailto:cbh@zyfer.com] > Sent: Monday, July 01, 2002 1:05 PM > To: 'Black_David@emc.com'; ips@ece.cmu.edu > Subject: RE: IPS-All: Reminder - Security draft last call ends Monday, > Jul y 1 at 8am EST > > > Hi, David > I think it is not right that "any key is vulnerable to compromise from > overuse, > even if that use is only as part of generation of other > keys." Lets look for > example simple to encryption with AES: there is no way known > better than > brute force to get the key even if this key is used for encryption of > arbitrary many plaintexts and all plaintext-ciphertext-pairs > are known. > Correct me if I'm wrong. > Greetings > Christina > > > -----Original Message----- > > From: Black_David@emc.com [mailto:Black_David@emc.com] > > Sent: Monday, July 01, 2002 6:56 AM > > To: Christina Helbig; ips@ece.cmu.edu > > Subject: RE: IPS-All: Reminder - Security draft last call > ends Monday, > > Jul y 1 at 8am EST > > > > > > Excerpting the important point: > > > > > o.k. Lets see what I have understand now: If PFS by > rekeying is not > > > mandatory to use (and this is the situation) then you can > > established with > > > DH exchange a key (referred here now by me as long-term > > key) and use other > > > protocols, e.g. Basic Quick Mode or Stealthkey, to derive > > multiple keys > > > (referred here as short-term keys) from the long-term key. > > The compromise > > > of short-term keys must not compromise the long-term key. > > This formulation > > > should be also conform with Paul Koning's comment. > > > > Yes, with a slight clarification of "must not" - "when > properly used, > > compromise of short-term keys must not compromise the long-term > > key". Eventually, any key is vulnerable to compromise from overuse, > > even if that use is only as part of generation of other keys. > > > > Thanks, > > --David > > --------------------------------------------------- > > David L. Black, Senior Technologist > > EMC Corporation, 42 South St., Hopkinton, MA 01748 > > +1 (508) 249-6449 *NEW* FAX: +1 (508) 497-8500 > > black_david@emc.com Cell: +1 (978) 394-7754 > > --------------------------------------------------- > > > > > -----Original Message----- > > > From: Christina Helbig [mailto:cbh@zyfer.com] > > > Sent: Friday, June 28, 2002 7:37 PM > > > To: 'Black_David@emc.com'; ips@ece.cmu.edu > > > Subject: RE: IPS-All: Reminder - Security draft last call > > ends Monday, > > > Jul y 1 at 8am EST > > > > > > > > > David, thank you for the time for answer. Comments inside: > > > > > > > -----Original Message----- > > > > From: Black_David@emc.com [mailto:Black_David@emc.com] > > > > Sent: Friday, June 28, 2002 1:07 PM > > > > To: Christina Helbig; ips@ece.cmu.edu > > > > Subject: RE: IPS-All: Reminder - Security draft last call > > > ends Monday, > > > > Jul y 1 at 8am EST > > > > > > > > > > > > Christina, > > > > > > > > Thanks for your comments. I don't think there are > > technical issues > > > > in the two areas of concern you've raised - could you > please check > > > > the following discussion and see if it's ok? > > > > > > > > I. Rekeying and PFS > > > > > > > > The requirement for PFS is "MUST implement" (must support) > > > > not "MUST use". > > > > Christina's text appears to be objecting to a "MUST use" > > > > requirement - if > > > > so, this is not a problem, as the requirement is "MUST > implement", > > > > which is the intention of the "must support" wording in > > > section 2.1 of > > > > the security draft. > > > o.k. I understood. > > > > > > > > II. Manual keying and PFS > > > > > > > > Section 5.9 was not intended to provide an exception to the > > > > "MUST NOT use" > > > > manual keying requirement stated in Section 2.3.3. The > > > > Section 5.9 text > > > > should be clarified to make this clear. > > > > > > > o.k. > > > > > Second, if PFS would be not mandatory by rekeying then you > > > > can use manual > > > > > keying together with other protocols for frequent > > > rekeying, e.g. our > > > > > proposal. > > > > > > > > I don't think there's an issue here, but some terminology > > > > clarification is > > > > in order - in essence properly designed "manual keying > > together with > > > > other protocols for frequent rekeying" is "preshared > > keying" and is > > > > allowed (in fact it's required). > > > > > > > > The term "manual keying" describes situations in which keys are > > > > preconfigured > > > > (manually) and then those keys are used as the session keying > > > > material for > > > > the SAs that carry traffic - rekeying is accomplished by > > (manually) > > > > configuring new keys. Manual keying is forbidden (MUST > > NOT use) for > > > > IP Storage due to the inability to automatically generate > > new secure > > > > session keys. > > > > > > > > The term "preshared keying" describes situations in which the > > > > preconfigured > > > > keys are used to derive multiple session keys in a fashion > > > > that compromise > > > > of a session key does not imply compromise or serious > > > weakening of the > > > > preconfigured keys (IKE uses a keyed prf [usually a hash] to > > > > obtain this > > > > property). Pre-shared keying is REQUIRED (MUST implement). > > > > > > > o.k. Lets see what I have understand now: If PFS by > rekeying is not > > > mandatory to use (and this is the situation) then you can > > > established with > > > DH exchange a key (referred here now by me as long-term key) > > > and use other > > > protocols, e.g. Basic Quick Mode or Stealthkey, to derive > > > multiple keys > > > (referred here as short-term keys) from the long-term key . > > > The compromise > > > of short-term keys must not compromise the long-term key. > > > This formulation > > > should be also conform with Paul Koenigs comment. > > > > The StealthKey mechanism described in > > > > draft-helbig-stealthkey-01.txt is > > > > a preshared keying mechanism that can automatically generate new > > > > (short-term) session keys, and hence is not forbidden by the > > > > requirement > > > > that manual keying MUST NOT be used. OTOH, StealthKey is not > > > > specified > > > > in any of the IP Storage protocol drafts. > > > > > > > o.k. We try to get some attention from the IPSec working > > > group for this > > > proposal. I think this is the right WG. I was only concerned > > > that we have no > > > chance to use this for IP Storage protocols but the right > > > understanding of > > > Internet-Standards is really a skill after long-training. > > > Thank you > > > Christina > > > > Thanks, > > > > --David > > > > --------------------------------------------------- > > > > David L. Black, Senior Technologist > > > > EMC Corporation, 42 South St., Hopkinton, MA 01748 > > > > +1 (508) 249-6449 *NEW* FAX: +1 (508) 497-8500 > > > > black_david@emc.com Cell: +1 (978) 394-7754 > > > > --------------------------------------------------- > > > > > > > > > -----Original Message----- > > > > > From: Christina Helbig [mailto:cbh@zyfer.com] > > > > > Sent: Friday, June 28, 2002 2:03 PM > > > > > To: 'Elizabeth Rodriguez'; ips@ece.cmu.edu > > > > > Subject: RE: IPS-All: Reminder - Security draft last call > > > > ends Monday, > > > > > Jul y 1 at 8am EST > > > > > > > > > > > > > > > These are my IPS Security draft last call comments. I'm also > > > > > impressed about > > > > > the good work others have done. > > > > > > > > > > I have problems with following text about rekeying and > > > > manual keying. > > > > > > > > > > I. Rekeying and PFS: > > > > > > > > > > First there are two statements, which I think are not > > consistent: > > > > > > > > > > a) 2.1. Security requirements > > > > > ...The IP block storage security protocols must > support perfect > > > > > forward secrecy in the rekeying process. > > > > > > > > > > b) 2.2. Resource constraints > > > > > Computational horsepower should be available to perform a > > > > > reasonable amount > > > > > of exponentiation as part of authentication and key > > derivation for > > > > > connection setup. The same is true of rekeying, although the > > > > > ability to avoid exponentiation for rekeying may be > > desirable (but > > > > > is not an absolute requirement). > > > > > > > > > > In RFC 2409 is a clear definition of PFS for IKE: > > > > > 3.3 Perfect Forward Secrecy > > > > > When used in the memo Perfect Forward Secrecy (PFS) refers to > > > > > the notion > > > > > that compromise of a single key will permit access to only > > > > > data protected by > > > > > a single key. For PFS to exist the key used to protect > > > > > transmission of data > > > > > MUST NOT be used to derive any additional keys, and if the > > > > key used to > > > > > protect transmission of data was derived from some other > > > > > keying material, > > > > > that material MUST NOT be used to derive any more keys. > > > > > > > > > > If a) is the requirement than you can never avoid > > > exponentiation for > > > > > rekeying because otherwise you must use keying material to > > > > > derive more than > > > > > one key. > > > > > > > > > > Second I think PFS should not be a requirement for rekeying, > > > > > only a nice to > > > > > have. Why? > > > > > > > > > > There is currently a discussion about PFS and rekeying by SOI > > > > > in the IPSec > > > > > list and here is what I wrote and nobody opposed me (what not > > > > > mean that I'm > > > > > right ;-) > > > > > > > > > > "IMO there is a mix of the issue of PFS and rekeying in the > > > > > discussion. > > > > > 1. Rekeying is needed if the amount of with the same key > > > > > encrypted data goes > > > > > beyond specific values, because of some passive attacks > > > against the > > > > > encrypted data (dependable also of the encryption algorithm > > > > > and its mode) > > > > > and the active attack of replaying by ESP after the sequence > > > > > number counter > > > > > has started again. > > > > > 2. The need for PFS by the process of rekeying is not based > > > > > on protection > > > > > against this attacks under 1. > > > > > 3. The property of PFS is an advantage in the case of > > > > > unauthorized access to > > > > > secret information used to generate the communication keys. > > > > > If this secret > > > > > information can be secured against unauthorized access then > > > > > rekeying can be > > > > > done without the property of PFS. > > > > > 4. On the other hand there is always a need by IKE to > > > protect secret > > > > > information against unauthorized access used for phase 1 > > > > > authentication. If > > > > > the protection of this secret information in the system is > > > > > sufficient why > > > > > should there the protection of another secret information be > > > > > insufficient? > > > > > > > > > > My proposal is: Rekeying is necessary under specific > > > > > circumstances, which > > > > > should be described. PFS is not needed if the secret > > > > > information used to > > > > > generate different communication keys is protected against > > > > > unauthorized > > > > > access in the same manner like the phase 1 > > authentication secret." > > > > > > > > > > The main reason for avoiding mandatory PFS by rekeying, I > > > > think is the > > > > > computational overhead. I have mentioned in the SOI > discussion: > > > > > > > > > > "I found different statements about the CPU time > > necessary for one > > > > > exponentiation between 30ms and some seconds. In the > > > > > draft-ietf-ips-security-13.txt it's time for rekeying for one > > > > > SA by 10Gbps > > > > > and 3DES in CBC mode all 27.5s or before 2^35 bytes are sent. > > > > > Assume the > > > > > case of some hundred SAs per peer with permanently > > > > > irregularly distributed > > > > > traffic between the SAs. Then rekeying at time is necessary > > > > > for every SA all > > > > > 27.5 s. This looks like a computational border, so > you must have > > > > > amount-based rekeying in this case and encrypted bytes or > > > > > blocks must be > > > > > counted for every SA. Is that a computational border too?" > > > > > > > > > > There was no answer like "This is no problem". > > > > > > > > > > Last I like to mention the possibility to rekey without > > > > exchanges (and > > > > > without PFS). We have developed a protocol for frequent > > > > > rekeying without > > > > > exchanges and would be happy if some folks could have a look > > > > > at this and say > > > > > if it makes sense or not > > > > > ( > > > thkey-01.txt>) > > > > > > > > II. Manual keying and PFS: > > > > > > > > First there are again two statements, which I think are not > > > > consistent: > > > > > > > > > > > > c) 2.3.3. IKE > > > > ...Manual keying MUST NOT be used since it does not provide > > > > the necessary > > > > rekeying support. > > > > > > > > d) 5.9 Use of AES in counter mode > > > > > > > > ...The implication of this is that it is almost always an > > > error to use > > > > IPsec manual keying with counter mode, except when the > > > implementation > > > > takes heroic measures to maintain state across sessions. > > > > > > > > That means there is an exception from MUST NOT? > > > > > > > > Second, if PFS would be not mandatory by rekeying then you > > > > can use manual > > > > keying together with other protocols for frequent > > rekeying, e.g. our > > > > proposal. > > > > Thank you for your patient regarding my bad English. > > > > Christina > > > > > > > > > -----Original Message----- > > > > > From: Elizabeth Rodriguez > > [mailto:elizabeth.g.rodriguez@123mail.net] > > > > Sent: Thursday, June 27, 2002 2:41 PM > > > > To: ips@ece.cmu.edu > > > > Cc: Elizabeth.G.Rodriguez@123mail.net > > > > Subject: IPS-All: Reminder - Security draft last call ends > > > > Monday, July > > > > 1 at 8am EST > > > > > > > > > > > > Just a reminder to all to get your last call comments on the > > > > security draft in. > > > > The cutoff is Monday July 1 at 8am EST > > > > > > > > Thanks, > > > > > > > > Elizabeth > > > > > > > > > > > > > > From owner-ips@ece.cmu.edu Mon Jul 1 17:30:51 2002 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA04775 for ; Mon, 1 Jul 2002 17:30:46 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id g61KHfV08195 for ips-outgoing; Mon, 1 Jul 2002 16:17:41 -0400 (EDT) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from cygnus.equallogic.com (cygnus.equallogic.com [65.170.102.10]) by ece.cmu.edu (8.11.0/8.10.2) with SMTP id g61KHew08191 for ; Mon, 1 Jul 2002 16:17:40 -0400 (EDT) Received: from cygnus.equallogic.com (localhost.localdomain [127.0.0.1]) by cygnus.equallogic.com (8.11.6/8.11.6) with ESMTP id g61KHYC13020 for ; Mon, 1 Jul 2002 16:17:34 -0400 Received: from deneb.dev.equallogic.com (deneb.dev.equallogic.com [172.16.1.99]) by cygnus.equallogic.com (8.11.6/8.11.6) with ESMTP id g61KHYQ13011; Mon, 1 Jul 2002 16:17:34 -0400 Received: from PKONING.equallogic.com (localhost.localdomain [127.0.0.1]) by deneb.dev.equallogic.com (8.11.6/8.11.6) with ESMTP id g61KHXd29928; Mon, 1 Jul 2002 16:17:34 -0400 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <15648.47329.393000.765199@gargle.gargle.HOWL> Date: Mon, 1 Jul 2002 16:17:37 -0400 From: Paul Koning To: Black_David@emc.com Cc: ips@ece.cmu.edu Subject: RE: FW: IPS-All: Reminder - Security draft last call ends Monday, Jul y 1 at 8am EST References: <277DD60FB639D511AC0400B0D068B71E0564BFF9@CORPMX14> X-Mailer: VM 6.95 under 21.4 (patch 3) "Academic Rigor" XEmacs Lucid Sender: owner-ips@ece.cmu.edu Precedence: bulk Content-Transfer-Encoding: 7bit Excerpt of message (sent 1 July 2002) by Black_David@emc.com: > > > 2.3.1. Transforms "When ESP is utilized, per-packet data origin > > > authentication, integrity and replay protection MUST be used." > > > > > > In iSCSI, the replay protection is MUST implement (not MUST use): > > > 7.3.1 Data Integrity and Authentication > > > "The ESP anti-replay service MUST also be implemented." > > > > > > (I'm not sure if the security or iSCSI should be changed ? > > I think the recent tendency was not to impose IPsec requirements unless > > they are justified by IPS uniqueness compare to other IPsec usage > scenarios) > > > > > > > > > +++ I assume security draft will be fixed +++ > > > > Because of the Bellovin attack on encryption-only ESP, I believe that > > the first of the two statements is the right one. > > > > There's a lot of argument that integrity should be mandatory in ESP > > across the board. The reason why it currently isn't (at least as far > > as I understand from Steve Kent) is that integrity in the IPsec layer > > is superfluous if cryptographic integrity is provided at a higher > > layer. That case doesn't apply in IPS, so the risk of Bellovin's > > attack is real. > > Paul - this is only about the anti-replay service, it does not propose > to change the current iSCSI and IPS Security draft mandates that integrity > be "mandatory in ESP across the board". Are you concerned that anti-replay > should also be mandatory across the board? Ok, I didn't realize we're only talking about anti-replay. Technically it's optional separately from integrity. In practice, once you have integrity, the sequence checking is trivial, so I don't really understand why ESP does that. So while I don't see a specific security hazard from leaving it out, I also see no good argument for that flexibilty. paul From owner-ips@ece.cmu.edu Mon Jul 1 17:31:31 2002 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA04819 for ; Mon, 1 Jul 2002 17:31:31 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id g61L1gZ00910 for ips-outgoing; Mon, 1 Jul 2002 17:01:42 -0400 (EDT) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from msgbas2.cos.agilent.com (msgbas2x.cos.agilent.com [192.25.240.37]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id g61L1ee00906 for ; Mon, 1 Jul 2002 17:01:40 -0400 (EDT) Received: from msgrel1t.cos.agilent.com (msgrel1t.cos.agilent.com [130.29.152.157]) by msgbas2.cos.agilent.com (Postfix) with ESMTP id 63B021CFD; Mon, 1 Jul 2002 15:01:38 -0600 (MDT) Received: from axcsbh1.cos.agilent.com (axcsbh1.cos.agilent.com [130.29.152.143]) by msgrel1t.cos.agilent.com (Postfix) with SMTP id 30E867F9; Mon, 1 Jul 2002 15:01:36 -0600 (MDT) Received: from 130.29.152.143 by axcsbh1.cos.agilent.com (InterScan E-Mail VirusWall NT); Mon, 01 Jul 2002 15:01:29 -0600 Received: by axcsbh1.cos.agilent.com with Internet Mail Service (5.5.2653.19) id ; Mon, 1 Jul 2002 15:01:29 -0600 Message-ID: <9F8400020EC5D311AF62009027C396160902C4FE@axcs09.cos.agilent.com> From: "LEMAY,KEVIN (A-Roseville,ex1)" To: "'Satran, Julian'" , ips@ece.cmu.edu Subject: iSCSI: Decimal encoding - why 64 bits ? Date: Mon, 1 Jul 2002 15:01:23 -0600 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-ips@ece.cmu.edu Precedence: bulk Julian, Why does decimal encoding support 64 bit values instead of only 32 bits? For implementations running on 32bit machines, supporting 64 bit decimal encoding will not be fun. Sure, it can be done in software, but is it really needed? All of the operational parameters fit in 32 bits. The only possible use for 64 bits is in authentication or vendor specific keys. Hex and base64 encoding make more sense for these cases for the long authentication keys and hex and base64 encoders/decoders must be provided by a compliant implementation anyway. Could we restrict the decimal encoding to 32 bits and make binary values use only hex and base 64? Thanks, Kevin From owner-ips@ece.cmu.edu Mon Jul 1 18:32:49 2002 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA07739 for ; Mon, 1 Jul 2002 18:32:48 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id g61MGkp00543 for ips-outgoing; Mon, 1 Jul 2002 18:16:46 -0400 (EDT) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from mercury.corp.iready.com ([65.115.68.100]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id g61MGiX00539 for ; Mon, 1 Jul 2002 18:16:44 -0400 (EDT) Received: by mercury.corp.iready.com with Internet Mail Service (5.5.2653.19) id ; Mon, 1 Jul 2002 15:16:38 -0700 Message-ID: <034670D62D19D31180990090277A37B702427E01@mercury.corp.iready.com> From: Jonathan Trostle To: "'Bernard Aboba'" Cc: "'ips@ece.cmu.edu'" Subject: RE: IPS-All: Reminder - Security draft last call ends Monday, Jul y 1 at 8am EST Date: Mon, 1 Jul 2002 15:16:36 -0700 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C2214C.F7443A30" Sender: owner-ips@ece.cmu.edu Precedence: bulk This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_001_01C2214C.F7443A30 Content-Type: text/plain; charset="iso-8859-1" When a target ends up in the negative authentication cache, does that imply that the initiator will not contact the target while it's in the cache, or does it imply that the initiator can contact the target but should not use IPsec (if IPsec failed)? Or shouldn't use app level security if app level security failed? Jonathan -----Original Message----- From: Bernard Aboba [mailto:bernard_aboba@hotmail.com] Sent: Saturday, June 29, 2002 10:42 PM To: jtrostle@corp.iready.com; ips@ece.cmu.edu Subject: RE: IPS-All: Reminder - Security draft last call ends Monday, July 1 at 8am EST >One comment/question on the security draft below: > >p. 23: "Where iSNS is used without security, IP block storage protocol >implementations MUST support a negative cache for authentication >failures." > >Is it worth pointing out that when iSNS is used with security, then a >negative cache MUST NOT be used? An attacker can cause authentication >to >fail through a DoS attack which could result in an entry being >added to >the negative cache. There are two orthogonal issues here -- one is iSNS security, the other is IPS protocol security. If iSNS is not secured, then a peer might receive and accept an iSNS packet from a rogue iSNS server. However, if the IPS session is subsequently secured, and mutually authenticated, the endpoint specified in the bogus discovery message will fail to authenticate. The argument is that this should result in a negative cache entry within the iSNS implementation, so as to prevent continual attempts to authenticate to bogus peers. If iSNS is secured, then presumably this would preclude a rogue iSNS server, and the negative cache is unnecessary. Do you have an issue with the negative cache in general, or just its use where iSNS is secured? _________________________________________________________________ Send and receive Hotmail on your mobile device: http://mobile.msn.com ------_=_NextPart_001_01C2214C.F7443A30 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable RE: IPS-All: Reminder - Security draft last call ends Monday, = July 1 at 8am EST

When a target ends up in the negative authentication = cache, does that imply that the initiator will not contact the target = while it's in the cache, or does  it imply that the initiator can = contact the target but should not use IPsec (if IPsec failed)? Or = shouldn't use app level security if app level security = failed?

Jonathan

-----Original Message-----
From: Bernard Aboba [mailto:bernard_aboba@hotmail.c= om]
Sent: Saturday, June 29, 2002 10:42 PM
To: jtrostle@corp.iready.com; ips@ece.cmu.edu
Subject: RE: IPS-All: Reminder - Security draft last = call ends Monday,
July 1 at 8am EST


>One comment/question on the security draft = below:
>
>p. 23: "Where iSNS is used without = security, IP block storage protocol
>implementations MUST support a negative cache = for authentication
>failures."
>
>Is it worth pointing out that when iSNS is used = with security, then a
>negative cache MUST NOT be used? An attacker can = cause authentication >to
>fail through a DoS attack which could result in = an entry being >added to
>the negative cache.

There are two orthogonal issues here -- one is iSNS = security, the other is
IPS protocol security. If iSNS is not secured, then = a peer might receive and
accept an iSNS packet from a rogue iSNS server. = However, if the IPS session
is subsequently secured, and mutually authenticated, = the endpoint specified
in the bogus discovery message will fail to = authenticate. The argument is
that this should result in a negative cache entry = within the iSNS
implementation, so as to prevent continual attempts = to authenticate to bogus
peers.

If iSNS is secured, then presumably this would = preclude a rogue iSNS server,
and the negative cache is unnecessary.

Do you have an issue with the negative cache in = general, or just its use
where iSNS is secured?





_______________________________________________________________= __
Send and receive Hotmail on your mobile device: http://mobile.msn.com

------_=_NextPart_001_01C2214C.F7443A30-- From owner-ips@ece.cmu.edu Mon Jul 1 18:33:02 2002 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA07758 for ; Mon, 1 Jul 2002 18:33:02 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id g61LnJM02963 for ips-outgoing; Mon, 1 Jul 2002 17:49:19 -0400 (EDT) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from mxic2.corp.emc.com (mxic2.isus.emc.com [128.221.31.40]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id g61LnIe02959 for ; Mon, 1 Jul 2002 17:49:18 -0400 (EDT) Received: by mxic2.corp.emc.com with Internet Mail Service (5.5.2653.19) id ; Mon, 1 Jul 2002 17:49:13 -0400 Message-ID: <277DD60FB639D511AC0400B0D068B71E0564C004@CORPMX14> From: Black_David@emc.com To: ips@ece.cmu.edu Subject: IPS Security draft WG Last Call results Date: Mon, 1 Jul 2002 17:47:19 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-ips@ece.cmu.edu Precedence: bulk The IP Storage WG Last Call period on the IPS Security draft, draft-ietf-ips-security-13.txt, ended earlier today. The WG chairs have concluded that the draft has passed WG Last Call, but there are a number of minor technical comments that need to be addressed, and a large number of editorial comments. Congratulations and well done to the draft authors and contributors. Jonathan Trostle's comment is the one outstanding comment that still requires resolution; it is sufficiently minor that it can be resolved on the list or directly with the draft editor. I will work with the draft editor on any issues with text to address my technical comments (one of which duplicates Brian Forbes's technical comment). Ofer Biran's comments on how to coordinate the iSCSI and IPS Security drafts will be made as proposed, and Paul Koning's issue with respect to one of those comments has been closed - it's ok w/Paul to make Ofer's change as originally proposed. Christina Helbig's comments have turned out to be editorial in nature - a few clarifications are needed. The issues surrounding AES Counter Mode (we currently do not have an ipsec WG draft on this to reference) will be deferred to IETF Last Call in consultation with the ipsec WG and the relevant Area Directors, but there will be time on the IPS Yokohama agenda to discuss the strategy for dealing with them at IETF Last Call (ideally we'll have an AES counter mode draft by then and only need to change the name of the draft in the reference) - this issue spans a number of our drafts. The next step will be production of a -14 version of the security draft incorporating all the changes and one final check that it is aligned with the FCIP, iFCP and iSNS drafts. Thanks, --David and Elizabeth --------------------------------------------------- David L. Black, Senior Technologist EMC Corporation, 42 South St., Hopkinton, MA 01748 +1 (508) 249-6449 *NEW* FAX: +1 (508) 497-8500 black_david@emc.com Cell: +1 (978) 394-7754 --------------------------------------------------- From owner-ips@ece.cmu.edu Mon Jul 1 18:35:33 2002 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA07901 for ; Mon, 1 Jul 2002 18:35:33 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id g61MMKp00755 for ips-outgoing; Mon, 1 Jul 2002 18:22:20 -0400 (EDT) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from mailhub.lss.emc.com (xdch.emc.com [168.159.1.79]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id g61MMJX00751 for ; Mon, 1 Jul 2002 18:22:19 -0400 (EDT) Received: from emc.com (emcmail.lss.emc.com [168.159.48.78]) by mailhub.lss.emc.com (Switch-2.2.0/Switch-2.2.0) with ESMTP id g61MMAX18166 for ; Mon, 1 Jul 2002 18:22:10 -0400 (EDT) Received: from mxic1.isus.emc.com ([168.159.129.100]) by emc.com (8.10.1/8.10.1) with ESMTP id g61MM9715636 for ; Mon, 1 Jul 2002 18:22:09 -0400 (EDT) Received: by MXIC1 with Internet Mail Service (5.5.2653.19) id ; Mon, 1 Jul 2002 18:20:20 -0400 Message-ID: <277DD60FB639D511AC0400B0D068B71E0564C006@CORPMX14> From: Black_David@emc.com To: ips@ece.cmu.edu Subject: Yokohama Agenda and status of drafts Date: Mon, 1 Jul 2002 18:20:16 -0400 Importance: high X-Priority: 1 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" X-Perlmx-Spam: Gauge=XXXXIIIII, Probability=45%, Report="NO_REAL_NAME, OPT_IN, X_PRIORITY_HIGH" Sender: owner-ips@ece.cmu.edu Precedence: bulk The IPS Yokohama agenda needs to be assembled fairly quickly, so I'm going to run an "opt-in" process for this -- I currently know about IPS agenda time requests/needs for: - SCSI MIB - iSCSI Plugfest - IPS Security WG Last Call results, including how to deal with AES Counter Mode - iSCSI Last Call results Authors of all other drafts - if I don't hear from you by the end of this week, the only mention of your draft in Yokohama will be a brief statement that the authors believe the draft is ready for WG Last Call, accompanied by a request for anyone who disagrees to speak up in the meeting or on the mailing list. I've appended a summary of what the WG chairs believe to be the current status of the drafts in the IP Storage WG. Please let us know of any corrections. Thanks, --David IETF IP Storage (ips) Working Group WG Internet-Draft Status: July 2002 ------------------------------------ Summary: 23 drafts total: - 2 are in the RFC Editor queue - 4 have completed WG Last Call - 1 is in WG Last Call - 3 will not be published as RFCs (WG Last Call comment resolution) That leaves 13 drafts still to go through WG Last Call - there will be a *lot* of WG Last Calls coming up after the Yokohama meeting week. NOTE: PDF versions for some drafts are for ease of review only. The definitive format for RFCs is text, and it is the text versions that will be forwarded to the IESG for publication as RFCs. -- Security for all IPS protocols draft-ietf-ips-security-13.txt To be a proposed standard RFC. WG Last Call has just completed, a -14 version will include the editorial and minor technical changes from WG Last Call, and should be ready for submission to the ADs/IESG shortly after Yokohama (and after one last check that it's aligned with the protocol drafts that reference it). -- iSCSI draft-ietf-ips-iscsi-14.txt draft-ietf-ips-iscsi-14.pdf To become a proposed standard RFC. Outstanding security issues have (finally) been resolved. In WG Last Call which will complete on July 8th. The -14 draft updated the -13 draft with changes from the first week of WG Last Call. draft-ietf-ips-iscsi-boot-06.txt To become an informational RFC, after the main iSCSI document. WG Last Call expected shortly after Yokohama. draft-ietf-ips-iscsi-reqmts-06.txt The IESG has approved publication as an informational RFC, and the draft is currently in the RFC Editor queue. draft-ietf-ips-iscsi-name-disc-06.txt To become a proposed standard RFC. WG Last Call expected shortly after Yokohama. draft-ietf-ips-iscsi-slp-03.txt To become a proposed standard RFC. WG Last Call will be after the naming and discovery draft. draft-ietf-ips-iscsi-string-prep-02.txt To become a proposed standard RFC. WG Last Call expected shortly after Yokohama - at same time as name-disc draft. draft-ietf-ips-iscsi-mib-05.txt To be a proposed standard RFC. WG Last Call will follow main iSCSI draft. Structure diagram available at: ftp://ftpeng.cisco.com/mbakke/ips/iscsi-mib/Visio-ietf-iscsi-uml-model-05.pd f draft-ietf-ips-auth-mib-01.txt To be a proposed standard RFC. User identity information MIB split out from basic iSCSI MIB for more general use, but currently only being used for iSCSI. Will go to WG Last Call with the iSCSI MIB. Structure diagram available at: ftp://ftpeng.cisco.com/mbakke/ips/auth-mib/Visio-ietf-ips-auth-mib-01.pdf draft-sheinwald-iscsi-crc-01.txt The IESG has approved publication as an informational RFC, and the draft is currently in the RFC Editor Queue. -- FC Common Encapsulation draft-ietf-ips-fcencapsulation-08.txt draft-ietf-ips-fcencapsulation-08.pdf To be a proposed standard RFC. Has completed WG Last Call. Will be submitted to Area Directors and the IESG after the check of FCIP and iFCP against the final version of the security draft. -- FCIP draft-ietf-ips-fcovertcpip-11.txt draft-ietf-ips-fcovertcpip-11.pdf To be a proposed standard RFC. Has completed WG Last Call. Will be submitted to Area Directors and the IESG after a check against the final version of the IPS Security draft. draft-ietf-ips-fcip-slp-02.txt To be a proposed standard RFC. WG Last Call expected shortly after Yokohama draft-ietf-ips-fcip-mib-02.txt To be a proposed standard RFC. Has been restructured to align with new structure of FC Management MIB and been reviewed by the WG's MIB Technical Expert. Next revision should be ready for WG Last Call. -- iFCP draft-ietf-ips-ifcp-12.txt draft-ietf-ips-ifcp-12.pdf To be a proposed standard RFC. Has completed WG Last Call. Will be submitted to Area Directors and the IESG after a check against the final version of the security draft. draft-ietf-ips-ifcp-mib-01.txt To be a proposed standard RFC. Basically done. -- iSNS draft-ietf-ips-isns-11.txt To be a proposed standard RFC. WG Last Call to follow iSCSI and iFCP drafts. The related draft-ietf-dhc-isnsoption-01.txt requests allocation of a DHC option code for iSNS, and is being handled in the DHC WG. draft-ietf-ips-isns-mib-02.txt To be a proposed standard RFC. Basically done. -- SCSI MIB draft-ietf-ips-scsi-mib-03.txt To be a proposed standard RFC. -03 version should be ready for WG Last Call (shortly after Yokohama). Structure diagram available at: ftp://ftpeng.cisco.com/mbakke/ips/scsi-mib/Visio-scsi-uml-model-01.pdf Diagram showing relationships among SCSI family of MIBS available at: ftp://ftpeng.cisco.com/mbakke/ips/scsi-mib/Visio-scsi-mib-family-01.pdf -- Fibre Channel Management MIB draft-ietf-ips-fcmgmt-mib-02.txt To be a proposed standard RFC. This work has been transferred to the IPS WG from the IPFC WG, and the scope has been expanded to include replacement of the FC Fabric Element MIB (RFC 2837). -02 version should be ready for WG Last Call shortly after Yokohama. -- Last Call Drafts draft-ietf-ips-fcencap-wglc-01.txt draft-ietf-ips-fcip-wglc-02.txt draft-ietf-ips-ifcp-wglcc-00.txt These drafts will not be published as RFCs. They exist solely to record the resolution of WG Last Call comments on the FC Encapsulation, FCIP and iFCP drafts. ----- Document Completion Guesstimates ------ A rough guess is 3 waves of documents: (1) Main protocol standards. WG Last Call has completed for: - FC Encapsulation - FCIP - iFCP - IPS Security (completed July 1st, new version coming to incorporate Last Call comments) The following documents are in WG Last Call: - iSCSI (completes July 8th) (2) Supporting Protocol Documents. WG Last Call expected shortly after the Yokohama meeting for: - iSCSI Naming/Discovery - iSCSI stringprep - iSCSI Boot - iSCSI SLP - FCIP SLP - iSNS If the iSCSI draft requires a second WG Last Call, WG Last Call on the iSCSI supporting drafts will wait to follow that. (3) MIBs. WG Last Calls will be intermixed with supporting documents - all of the MIBs are done or close to done: - iSCSI MIB - FCIP MIB - iFCP MIB - iSNS MIB - SCSI MIB - FC Management MIB Expect multiple Last Call periods, rather than putting all the MIBs through WG Last Call at once. SCSI MIB and FC Management MIB are likely to enter WG Last Call shortly after the Yokohama meeting week. -- Potential Additional Work Additional drafts may be forthcoming in the future on: - Issues involved in gateways and bridges between iSCSI and other SCSI protocols - Additional MIB(s) that extend the FC Management MIB to cover additional aspects of Fibre Channel --------------------------------------------------- David L. Black, Senior Technologist EMC Corporation, 42 South St., Hopkinton, MA 01748 +1 (508) 249-6449 *NEW* FAX: +1 (508) 497-8500 black_david@emc.com Cell: +1 (978) 394-7754 --------------------------------------------------- From owner-ips@ece.cmu.edu Mon Jul 1 19:19:20 2002 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA09243 for ; Mon, 1 Jul 2002 19:19:20 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id g61Mhe101504 for ips-outgoing; Mon, 1 Jul 2002 18:43:40 -0400 (EDT) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from ariel.nishansystems.com (ultrex.nishansystems.com [12.36.127.195]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id g61MhcX01500 for ; Mon, 1 Jul 2002 18:43:38 -0400 (EDT) Received: by ariel.nishansystems.com with Internet Mail Service (5.5.2653.19) id <3BTDG5V0>; Mon, 1 Jul 2002 15:43:23 -0700 Message-ID: From: Joshua Tseng To: "'Jonathan Trostle'" , "'Bernard Aboba'" Cc: "'ips@ece.cmu.edu'" Subject: RE: IPS-All: Reminder - Security draft last call ends Monday, Jul y 1 at 8am EST Date: Mon, 1 Jul 2002 15:43:17 -0700 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C22150.B15B5BD0" Sender: owner-ips@ece.cmu.edu Precedence: bulk This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_001_01C22150.B15B5BD0 Content-Type: text/plain; charset="iso-8859-1" I believe the initiator should be able to re-try authentication, provided that such re-authentication attempts don't occur at frequencies which could be interpreted as a DOS attack. In any case, authentication should NOT be turned off for a target that is in the negative authentication cache. Josh -----Original Message----- From: Jonathan Trostle [mailto:jtrostle@corp.iready.com] Sent: Monday, July 01, 2002 3:17 PM To: 'Bernard Aboba' Cc: 'ips@ece.cmu.edu' Subject: RE: IPS-All: Reminder - Security draft last call ends Monday, Jul y 1 at 8am EST When a target ends up in the negative authentication cache, does that imply that the initiator will not contact the target while it's in the cache, or does it imply that the initiator can contact the target but should not use IPsec (if IPsec failed)? Or shouldn't use app level security if app level security failed? Jonathan -----Original Message----- From: Bernard Aboba [ mailto:bernard_aboba@hotmail.com ] Sent: Saturday, June 29, 2002 10:42 PM To: jtrostle@corp.iready.com; ips@ece.cmu.edu Subject: RE: IPS-All: Reminder - Security draft last call ends Monday, July 1 at 8am EST >One comment/question on the security draft below: > >p. 23: "Where iSNS is used without security, IP block storage protocol >implementations MUST support a negative cache for authentication >failures." > >Is it worth pointing out that when iSNS is used with security, then a >negative cache MUST NOT be used? An attacker can cause authentication >to >fail through a DoS attack which could result in an entry being >added to >the negative cache. There are two orthogonal issues here -- one is iSNS security, the other is IPS protocol security. If iSNS is not secured, then a peer might receive and accept an iSNS packet from a rogue iSNS server. However, if the IPS session is subsequently secured, and mutually authenticated, the endpoint specified in the bogus discovery message will fail to authenticate. The argument is that this should result in a negative cache entry within the iSNS implementation, so as to prevent continual attempts to authenticate to bogus peers. If iSNS is secured, then presumably this would preclude a rogue iSNS server, and the negative cache is unnecessary. Do you have an issue with the negative cache in general, or just its use where iSNS is secured? _________________________________________________________________ Send and receive Hotmail on your mobile device: http://mobile.msn.com ------_=_NextPart_001_01C22150.B15B5BD0 Content-Type: text/html; charset="iso-8859-1" RE: IPS-All: Reminder - Security draft last call ends Monday, July 1 at 8am EST
I believe the initiator should be able to re-try authentication,
provided that such re-authentication attempts don't occur at
frequencies which could be interpreted as a DOS attack.  In
any case, authentication should NOT be turned off for a target
that is in the negative authentication cache.
 
Josh
-----Original Message-----
From: Jonathan Trostle [mailto:jtrostle@corp.iready.com]
Sent: Monday, July 01, 2002 3:17 PM
To: 'Bernard Aboba'
Cc: 'ips@ece.cmu.edu'
Subject: RE: IPS-All: Reminder - Security draft last call ends Monday, Jul y 1 at 8am EST


When a target ends up in the negative authentication cache, does that imply that the initiator will not contact the target while it's in the cache, or does  it imply that the initiator can contact the target but should not use IPsec (if IPsec failed)? Or shouldn't use app level security if app level security failed?

Jonathan

-----Original Message-----
From: Bernard Aboba [mailto:bernard_aboba@hotmail.com]
Sent: Saturday, June 29, 2002 10:42 PM
To: jtrostle@corp.iready.com; ips@ece.cmu.edu
Subject: RE: IPS-All: Reminder - Security draft last call ends Monday,
July 1 at 8am EST


>One comment/question on the security draft below:
>
>p. 23: "Where iSNS is used without security, IP block storage protocol
>implementations MUST support a negative cache for authentication
>failures."
>
>Is it worth pointing out that when iSNS is used with security, then a
>negative cache MUST NOT be used? An attacker can cause authentication >to
>fail through a DoS attack which could result in an entry being >added to
>the negative cache.

There are two orthogonal issues here -- one is iSNS security, the other is
IPS protocol security. If iSNS is not secured, then a peer might receive and
accept an iSNS packet from a rogue iSNS server. However, if the IPS session
is subsequently secured, and mutually authenticated, the endpoint specified
in the bogus discovery message will fail to authenticate. The argument is
that this should result in a negative cache entry within the iSNS
implementation, so as to prevent continual attempts to authenticate to bogus
peers.

If iSNS is secured, then presumably this would preclude a rogue iSNS server,
and the negative cache is unnecessary.

Do you have an issue with the negative cache in general, or just its use
where iSNS is secured?





_________________________________________________________________
Send and receive Hotmail on your mobile device: http://mobile.msn.com

------_=_NextPart_001_01C22150.B15B5BD0-- From owner-ips@ece.cmu.edu Mon Jul 1 19:19:31 2002 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA09256 for ; Mon, 1 Jul 2002 19:19:31 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id g61Mbk001273 for ips-outgoing; Mon, 1 Jul 2002 18:37:46 -0400 (EDT) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from mailhub.lss.emc.com (xdch.emc.com [168.159.1.79]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id g61MbjX01269 for ; Mon, 1 Jul 2002 18:37:45 -0400 (EDT) Received: from emc.com (emcmail.lss.emc.com [168.159.48.78]) by mailhub.lss.emc.com (Switch-2.2.0/Switch-2.2.0) with ESMTP id g61Mbaq11839; Mon, 1 Jul 2002 18:37:36 -0400 (EDT) Received: from mxic1.isus.emc.com ([168.159.129.100]) by emc.com (8.10.1/8.10.1) with ESMTP id g61MbZ717493; Mon, 1 Jul 2002 18:37:35 -0400 (EDT) Received: by MXIC1 with Internet Mail Service (5.5.2653.19) id ; Mon, 1 Jul 2002 18:35:45 -0400 Message-ID: <277DD60FB639D511AC0400B0D068B71E0564C007@CORPMX14> From: Black_David@emc.com To: jtrostle@corp.iready.com Cc: ips@ece.cmu.edu Subject: RE: IPS-All: Reminder - Security draft last call ends Monday, Jul y 1 at 8am EST Date: Mon, 1 Jul 2002 18:35:40 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" X-Perlmx-Spam: Gauge=XXIIIIIII, Probability=27%, Report="NO_REAL_NAME, SUBJ_HAS_SPACES" Sender: owner-ips@ece.cmu.edu Precedence: bulk > When a target ends up in the negative authentication cache, does > that imply that the initiator will not contact the target while > it's in the cache, or does it imply that the initiator can contact > the target but should not use IPsec (if IPsec failed)? Or shouldn't > use app level security if app level security failed? The first - initiator will not contact the target while it's in the cache under the assumption that authentication will just fail again. As Bernard wrote, this protects against a denial of service attack where a rogue iSNS server in league with a rogue iSCSI target causes an initiator to repeatedly waste its time trying to talk to the target. Would it help to require an administrative interface to clear entries from the negative cache or the entire cache? Thanks, --David --------------------------------------------------- David L. Black, Senior Technologist EMC Corporation, 42 South St., Hopkinton, MA 01748 +1 (508) 249-6449 *NEW* FAX: +1 (508) 497-8500 black_david@emc.com Cell: +1 (978) 394-7754 --------------------------------------------------- -----Original Message----- From: Jonathan Trostle [mailto:jtrostle@corp.iready.com] Sent: Monday, July 01, 2002 6:17 PM To: 'Bernard Aboba' Cc: 'ips@ece.cmu.edu' Subject: RE: IPS-All: Reminder - Security draft last call ends Monday, Jul y 1 at 8am EST When a target ends up in the negative authentication cache, does that imply that the initiator will not contact the target while it's in the cache, or does it imply that the initiator can contact the target but should not use IPsec (if IPsec failed)? Or shouldn't use app level security if app level security failed? Jonathan -----Original Message----- From: Bernard Aboba [mailto:bernard_aboba@hotmail.com] Sent: Saturday, June 29, 2002 10:42 PM To: jtrostle@corp.iready.com; ips@ece.cmu.edu Subject: RE: IPS-All: Reminder - Security draft last call ends Monday, July 1 at 8am EST >One comment/question on the security draft below: > >p. 23: "Where iSNS is used without security, IP block storage protocol >implementations MUST support a negative cache for authentication >failures." > >Is it worth pointing out that when iSNS is used with security, then a >negative cache MUST NOT be used? An attacker can cause authentication >to >fail through a DoS attack which could result in an entry being >added to >the negative cache. There are two orthogonal issues here -- one is iSNS security, the other is IPS protocol security. If iSNS is not secured, then a peer might receive and accept an iSNS packet from a rogue iSNS server. However, if the IPS session is subsequently secured, and mutually authenticated, the endpoint specified in the bogus discovery message will fail to authenticate. The argument is that this should result in a negative cache entry within the iSNS implementation, so as to prevent continual attempts to authenticate to bogus peers. If iSNS is secured, then presumably this would preclude a rogue iSNS server, and the negative cache is unnecessary. Do you have an issue with the negative cache in general, or just its use where iSNS is secured? _________________________________________________________________ Send and receive Hotmail on your mobile device: http://mobile.msn.com From owner-ips@ece.cmu.edu Mon Jul 1 19:20:13 2002 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA09275 for ; Mon, 1 Jul 2002 19:20:08 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id g61NApd02253 for ips-outgoing; Mon, 1 Jul 2002 19:10:51 -0400 (EDT) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from mailhub.lss.emc.com (xdch.emc.com [168.159.1.79]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id g61NAoX02249 for ; Mon, 1 Jul 2002 19:10:50 -0400 (EDT) Received: from emc.com (emcmail.lss.emc.com [168.159.48.78]) by mailhub.lss.emc.com (Switch-2.2.0/Switch-2.2.0) with ESMTP id g61NAgX01969; Mon, 1 Jul 2002 19:10:42 -0400 (EDT) Received: from mxic1.isus.emc.com ([168.159.129.100]) by emc.com (8.10.1/8.10.1) with ESMTP id g61NAf720907; Mon, 1 Jul 2002 19:10:41 -0400 (EDT) Received: by MXIC1 with Internet Mail Service (5.5.2653.19) id ; Mon, 1 Jul 2002 19:08:52 -0400 Message-ID: <277DD60FB639D511AC0400B0D068B71E0564C009@CORPMX14> From: Black_David@emc.com To: jtrostle@corp.iready.com Cc: ips@ece.cmu.edu Subject: RE: IPS-All: Reminder - Security draft last call ends Monday, Jul y 1 at 8am EST Date: Mon, 1 Jul 2002 19:08:48 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C22154.41D4CDB0" Sender: owner-ips@ece.cmu.edu Precedence: bulk This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_001_01C22154.41D4CDB0 Content-Type: text/plain; charset="iso-8859-1" Jonathan, So, is the existing text ok, or do you want something changed? I don't think I see any harm in using a negative authentication cache when iSNS is operated securely, although, as Bernard noted, it's not necessary. Thanks, --David -----Original Message----- From: Jonathan Trostle [mailto:jtrostle@corp.iready.com] Sent: Monday, July 01, 2002 6:55 PM To: 'Black_David@emc.com' Cc: ips@ece.cmu.edu Subject: RE: IPS-All: Reminder - Security draft last call ends Monday, Jul y 1 at 8am EST That helps to clarify it. I don't think that the draft should require an administrative interface. Jonathan -----Original Message----- From: Black_David@emc.com [ mailto:Black_David@emc.com ] Sent: Monday, July 01, 2002 3:36 PM To: jtrostle@corp.iready.com Cc: ips@ece.cmu.edu Subject: RE: IPS-All: Reminder - Security draft last call ends Monday, Jul y 1 at 8am EST > When a target ends up in the negative authentication cache, does > that imply that the initiator will not contact the target while > it's in the cache, or does it imply that the initiator can contact > the target but should not use IPsec (if IPsec failed)? Or shouldn't > use app level security if app level security failed? The first - initiator will not contact the target while it's in the cache under the assumption that authentication will just fail again. As Bernard wrote, this protects against a denial of service attack where a rogue iSNS server in league with a rogue iSCSI target causes an initiator to repeatedly waste its time trying to talk to the target. Would it help to require an administrative interface to clear entries from the negative cache or the entire cache? Thanks, --David --------------------------------------------------- David L. Black, Senior Technologist EMC Corporation, 42 South St., Hopkinton, MA 01748 +1 (508) 249-6449 *NEW* FAX: +1 (508) 497-8500 black_david@emc.com Cell: +1 (978) 394-7754 --------------------------------------------------- -----Original Message----- From: Jonathan Trostle [ mailto:jtrostle@corp.iready.com ] Sent: Monday, July 01, 2002 6:17 PM To: 'Bernard Aboba' Cc: 'ips@ece.cmu.edu' Subject: RE: IPS-All: Reminder - Security draft last call ends Monday, Jul y 1 at 8am EST When a target ends up in the negative authentication cache, does that imply that the initiator will not contact the target while it's in the cache, or does it imply that the initiator can contact the target but should not use IPsec (if IPsec failed)? Or shouldn't use app level security if app level security failed? Jonathan -----Original Message----- From: Bernard Aboba [ mailto:bernard_aboba@hotmail.com ] Sent: Saturday, June 29, 2002 10:42 PM To: jtrostle@corp.iready.com; ips@ece.cmu.edu Subject: RE: IPS-All: Reminder - Security draft last call ends Monday, July 1 at 8am EST >One comment/question on the security draft below: > >p. 23: "Where iSNS is used without security, IP block storage protocol >implementations MUST support a negative cache for authentication >failures." > >Is it worth pointing out that when iSNS is used with security, then a >negative cache MUST NOT be used? An attacker can cause authentication >to >fail through a DoS attack which could result in an entry being >added to >the negative cache. There are two orthogonal issues here -- one is iSNS security, the other is IPS protocol security. If iSNS is not secured, then a peer might receive and accept an iSNS packet from a rogue iSNS server. However, if the IPS session is subsequently secured, and mutually authenticated, the endpoint specified in the bogus discovery message will fail to authenticate. The argument is that this should result in a negative cache entry within the iSNS implementation, so as to prevent continual attempts to authenticate to bogus peers. If iSNS is secured, then presumably this would preclude a rogue iSNS server, and the negative cache is unnecessary. Do you have an issue with the negative cache in general, or just its use where iSNS is secured? _________________________________________________________________ Send and receive Hotmail on your mobile device: http://mobile.msn.com ------_=_NextPart_001_01C22154.41D4CDB0 Content-Type: text/html; charset="iso-8859-1" RE: IPS-All: Reminder - Security draft last call ends Monday, Jul y 1 at 8am EST
Jonathan,
 
So, is the existing text ok, or do you want something changed?
 
I don't think I see any harm
in using a negative authentication cache when iSNS is operated
securely, although, as Bernard noted, it's not necessary.
 
Thanks,
--David
-----Original Message-----
From: Jonathan Trostle [mailto:jtrostle@corp.iready.com]
Sent: Monday, July 01, 2002 6:55 PM
To: 'Black_David@emc.com'
Cc: ips@ece.cmu.edu
Subject: RE: IPS-All: Reminder - Security draft last call ends Monday, Jul y 1 at 8am EST

That helps to clarify it. I don't think that the draft should require an administrative interface.

Jonathan

-----Original Message-----
From: Black_David@emc.com [mailto:Black_David@emc.com]
Sent: Monday, July 01, 2002 3:36 PM
To: jtrostle@corp.iready.com
Cc: ips@ece.cmu.edu
Subject: RE: IPS-All: Reminder - Security draft last call ends Monday,
Jul y 1 at 8am EST


> When a target ends up in the negative authentication cache, does
> that imply that the initiator will not contact the target while
> it's in the cache, or does  it imply that the initiator can contact
> the target but should not use IPsec (if IPsec failed)? Or shouldn't
> use app level security if app level security failed?

The first - initiator will not contact the target while it's in the
cache under the assumption that authentication will just fail again.
As Bernard wrote, this protects against a denial of service attack
where a rogue iSNS server in league with a rogue iSCSI target causes
an initiator to repeatedly waste its time trying to talk to the target.

Would it help to require an administrative interface to clear entries
from the negative cache or the entire cache?

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

-----Original Message-----
From: Jonathan Trostle [mailto:jtrostle@corp.iready.com]
Sent: Monday, July 01, 2002 6:17 PM
To: 'Bernard Aboba'
Cc: 'ips@ece.cmu.edu'
Subject: RE: IPS-All: Reminder - Security draft last call ends Monday, Jul y
1 at 8am EST




When a target ends up in the negative authentication cache, does that imply
that the initiator will not contact the target while it's in the cache, or
does  it imply that the initiator can contact the target but should not use
IPsec (if IPsec failed)? Or shouldn't use app level security if app level
security failed?
Jonathan
-----Original Message-----
From: Bernard Aboba [mailto:bernard_aboba@hotmail.com]
Sent: Saturday, June 29, 2002 10:42 PM
To: jtrostle@corp.iready.com; ips@ece.cmu.edu
Subject: RE: IPS-All: Reminder - Security draft last call ends Monday,
July 1 at 8am EST


>One comment/question on the security draft below:
>
>p. 23: "Where iSNS is used without security, IP block storage protocol
>implementations MUST support a negative cache for authentication
>failures."
>
>Is it worth pointing out that when iSNS is used with security, then a
>negative cache MUST NOT be used? An attacker can cause authentication >to
>fail through a DoS attack which could result in an entry being >added to
>the negative cache.
There are two orthogonal issues here -- one is iSNS security, the other is
IPS protocol security. If iSNS is not secured, then a peer might receive and

accept an iSNS packet from a rogue iSNS server. However, if the IPS session
is subsequently secured, and mutually authenticated, the endpoint specified
in the bogus discovery message will fail to authenticate. The argument is
that this should result in a negative cache entry within the iSNS
implementation, so as to prevent continual attempts to authenticate to bogus

peers.
If iSNS is secured, then presumably this would preclude a rogue iSNS server,

and the negative cache is unnecessary.
Do you have an issue with the negative cache in general, or just its use
where iSNS is secured?





_________________________________________________________________
Send and receive Hotmail on your mobile device: http://mobile.msn.com

------_=_NextPart_001_01C22154.41D4CDB0-- From owner-ips@ece.cmu.edu Mon Jul 1 19:21:00 2002 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA09291 for ; Mon, 1 Jul 2002 19:21:00 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id g61MsxH01816 for ips-outgoing; Mon, 1 Jul 2002 18:54:59 -0400 (EDT) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from mercury.corp.iready.com ([65.115.68.100]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id g61MsvX01804 for ; Mon, 1 Jul 2002 18:54:57 -0400 (EDT) Received: by mercury.corp.iready.com with Internet Mail Service (5.5.2653.19) id ; Mon, 1 Jul 2002 15:54:51 -0700 Message-ID: <034670D62D19D31180990090277A37B702427E02@mercury.corp.iready.com> From: Jonathan Trostle To: "'Black_David@emc.com'" Cc: ips@ece.cmu.edu Subject: RE: IPS-All: Reminder - Security draft last call ends Monday, Jul y 1 at 8am EST Date: Mon, 1 Jul 2002 15:54:51 -0700 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C22152.4EAA6560" Sender: owner-ips@ece.cmu.edu Precedence: bulk This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_001_01C22152.4EAA6560 Content-Type: text/plain; charset="iso-8859-1" That helps to clarify it. I don't think that the draft should require an administrative interface. Jonathan -----Original Message----- From: Black_David@emc.com [mailto:Black_David@emc.com] Sent: Monday, July 01, 2002 3:36 PM To: jtrostle@corp.iready.com Cc: ips@ece.cmu.edu Subject: RE: IPS-All: Reminder - Security draft last call ends Monday, Jul y 1 at 8am EST > When a target ends up in the negative authentication cache, does > that imply that the initiator will not contact the target while > it's in the cache, or does it imply that the initiator can contact > the target but should not use IPsec (if IPsec failed)? Or shouldn't > use app level security if app level security failed? The first - initiator will not contact the target while it's in the cache under the assumption that authentication will just fail again. As Bernard wrote, this protects against a denial of service attack where a rogue iSNS server in league with a rogue iSCSI target causes an initiator to repeatedly waste its time trying to talk to the target. Would it help to require an administrative interface to clear entries from the negative cache or the entire cache? Thanks, --David --------------------------------------------------- David L. Black, Senior Technologist EMC Corporation, 42 South St., Hopkinton, MA 01748 +1 (508) 249-6449 *NEW* FAX: +1 (508) 497-8500 black_david@emc.com Cell: +1 (978) 394-7754 --------------------------------------------------- -----Original Message----- From: Jonathan Trostle [mailto:jtrostle@corp.iready.com] Sent: Monday, July 01, 2002 6:17 PM To: 'Bernard Aboba' Cc: 'ips@ece.cmu.edu' Subject: RE: IPS-All: Reminder - Security draft last call ends Monday, Jul y 1 at 8am EST When a target ends up in the negative authentication cache, does that imply that the initiator will not contact the target while it's in the cache, or does it imply that the initiator can contact the target but should not use IPsec (if IPsec failed)? Or shouldn't use app level security if app level security failed? Jonathan -----Original Message----- From: Bernard Aboba [mailto:bernard_aboba@hotmail.com] Sent: Saturday, June 29, 2002 10:42 PM To: jtrostle@corp.iready.com; ips@ece.cmu.edu Subject: RE: IPS-All: Reminder - Security draft last call ends Monday, July 1 at 8am EST >One comment/question on the security draft below: > >p. 23: "Where iSNS is used without security, IP block storage protocol >implementations MUST support a negative cache for authentication >failures." > >Is it worth pointing out that when iSNS is used with security, then a >negative cache MUST NOT be used? An attacker can cause authentication >to >fail through a DoS attack which could result in an entry being >added to >the negative cache. There are two orthogonal issues here -- one is iSNS security, the other is IPS protocol security. If iSNS is not secured, then a peer might receive and accept an iSNS packet from a rogue iSNS server. However, if the IPS session is subsequently secured, and mutually authenticated, the endpoint specified in the bogus discovery message will fail to authenticate. The argument is that this should result in a negative cache entry within the iSNS implementation, so as to prevent continual attempts to authenticate to bogus peers. If iSNS is secured, then presumably this would preclude a rogue iSNS server, and the negative cache is unnecessary. Do you have an issue with the negative cache in general, or just its use where iSNS is secured? _________________________________________________________________ Send and receive Hotmail on your mobile device: http://mobile.msn.com ------_=_NextPart_001_01C22152.4EAA6560 Content-Type: text/html; charset="iso-8859-1" RE: IPS-All: Reminder - Security draft last call ends Monday, Jul y 1 at 8am EST

That helps to clarify it. I don't think that the draft should require an administrative interface.

Jonathan

-----Original Message-----
From: Black_David@emc.com [mailto:Black_David@emc.com]
Sent: Monday, July 01, 2002 3:36 PM
To: jtrostle@corp.iready.com
Cc: ips@ece.cmu.edu
Subject: RE: IPS-All: Reminder - Security draft last call ends Monday,
Jul y 1 at 8am EST


> When a target ends up in the negative authentication cache, does
> that imply that the initiator will not contact the target while
> it's in the cache, or does  it imply that the initiator can contact
> the target but should not use IPsec (if IPsec failed)? Or shouldn't
> use app level security if app level security failed?

The first - initiator will not contact the target while it's in the
cache under the assumption that authentication will just fail again.
As Bernard wrote, this protects against a denial of service attack
where a rogue iSNS server in league with a rogue iSCSI target causes
an initiator to repeatedly waste its time trying to talk to the target.

Would it help to require an administrative interface to clear entries
from the negative cache or the entire cache?

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

-----Original Message-----
From: Jonathan Trostle [mailto:jtrostle@corp.iready.com]
Sent: Monday, July 01, 2002 6:17 PM
To: 'Bernard Aboba'
Cc: 'ips@ece.cmu.edu'
Subject: RE: IPS-All: Reminder - Security draft last call ends Monday, Jul y
1 at 8am EST




When a target ends up in the negative authentication cache, does that imply
that the initiator will not contact the target while it's in the cache, or
does  it imply that the initiator can contact the target but should not use
IPsec (if IPsec failed)? Or shouldn't use app level security if app level
security failed?
Jonathan
-----Original Message-----
From: Bernard Aboba [mailto:bernard_aboba@hotmail.com]
Sent: Saturday, June 29, 2002 10:42 PM
To: jtrostle@corp.iready.com; ips@ece.cmu.edu
Subject: RE: IPS-All: Reminder - Security draft last call ends Monday,
July 1 at 8am EST


>One comment/question on the security draft below:
>
>p. 23: "Where iSNS is used without security, IP block storage protocol
>implementations MUST support a negative cache for authentication
>failures."
>
>Is it worth pointing out that when iSNS is used with security, then a
>negative cache MUST NOT be used? An attacker can cause authentication >to
>fail through a DoS attack which could result in an entry being >added to
>the negative cache.
There are two orthogonal issues here -- one is iSNS security, the other is
IPS protocol security. If iSNS is not secured, then a peer might receive and

accept an iSNS packet from a rogue iSNS server. However, if the IPS session
is subsequently secured, and mutually authenticated, the endpoint specified
in the bogus discovery message will fail to authenticate. The argument is
that this should result in a negative cache entry within the iSNS
implementation, so as to prevent continual attempts to authenticate to bogus

peers.
If iSNS is secured, then presumably this would preclude a rogue iSNS server,

and the negative cache is unnecessary.
Do you have an issue with the negative cache in general, or just its use
where iSNS is secured?





_________________________________________________________________
Send and receive Hotmail on your mobile device: http://mobile.msn.com

------_=_NextPart_001_01C22152.4EAA6560-- From owner-ips@ece.cmu.edu Mon Jul 1 19:21:21 2002 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA09306 for ; Mon, 1 Jul 2002 19:21:21 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id g61MuLA01853 for ips-outgoing; Mon, 1 Jul 2002 18:56:21 -0400 (EDT) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from msgbas1.cos.agilent.com (msgbas1x.cos.agilent.com [192.25.240.36]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id g61MuJX01849 for ; Mon, 1 Jul 2002 18:56:20 -0400 (EDT) Received: from msgrel1t.cos.agilent.com (msgrel1t.cos.agilent.com [130.29.152.157]) by msgbas1.cos.agilent.com (Postfix) with ESMTP id 3F9159EE7; Mon, 1 Jul 2002 16:56:19 -0600 (MDT) Received: from axcsbh6.cos.agilent.com (axcsbh6.cos.agilent.com [130.29.152.171]) by msgrel1t.cos.agilent.com (Postfix) with SMTP id B8831354; Mon, 1 Jul 2002 16:56:18 -0600 (MDT) Received: from 130.29.152.171 by axcsbh6.cos.agilent.com (InterScan E-Mail VirusWall NT); Mon, 01 Jul 2002 16:56:18 -0600 Received: by axcsbh6.cos.agilent.com with Internet Mail Service (5.5.2653.19) id ; Mon, 1 Jul 2002 16:56:18 -0600 Message-ID: <1BEBA5E8600DD4119A50009027AF54A00CB26BE2@axcs04.cos.agilent.com> From: pat_thaler@agilent.com To: Julian_Satran@il.ibm.com Cc: ips@ece.cmu.edu Subject: RE: iSCSI: Login negotiation space Date: Mon, 1 Jul 2002 16:56:09 -0600 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="ISO-8859-1" Sender: owner-ips@ece.cmu.edu Precedence: bulk Julian, 4.1 contains a requirement that initiators and targets support receiving at least 16384 bytes of key=value data (when not supporting very long authentication items). This is overkill and is making drivers larger than they need to be. My calculations are that Security negotiation using the CHAP method (including the Any-stage keys) takes less than 1600 bytes. Operational negotiation requires 1276 bytes (also including the Any-stage keys). All the operational plus security keys are 1911 bytes. Therefore an implementation could hold all the necessary keys in 2 Kbytes. And, the implementation doesn't need to keep the security keys after the security negotiation is done so it could clear some of that out to make room for future keys or vendor specific keys. 16 K bytes is about 10 times the necessary storage in that case. The number of negotiation bytes that a device is required to support should be reduced substantially - preferably to 2048 bytes. Regards, Pat The numbers: 43 AuthMethod CHAP keys 264 Name (no defined size limit - using 255) 11 Algorithm 11 Identifier 264 Challenge 42 Response (for MD5) _____ 635 Chap negotiation length 892 Any-stage keys ---- 1527 Operational negotiation keys 24 HeaderDigest 24 DataDigest 49 MaxConnections 270 TargetName* or InitiatorName* 271 TargetAlias* or InitiatorAlias* 273 TargetAddress* 55 TargetPortalGroupTag* 15 InitialR2T 19 BidiInitialR2T 18 ImmediateData 34 MaxRecvDataSegmentLength 24 MaxBurstLength 26 FirstBurstLength 24 DefaultTime2Wait 26 DefaultTime2Retain 25 MaxOutstandingR2T 18 DataPDUInOrder 24 DataSequenceInOrder 24 ErrorRecoveryLevel 23 SessionType* ------ 892 Any-stage keys 384 Not Any-stage ------ 1276 Operational keys From owner-ips@ece.cmu.edu Mon Jul 1 19:59:35 2002 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA10320 for ; Mon, 1 Jul 2002 19:59:34 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id g61NZIq02850 for ips-outgoing; Mon, 1 Jul 2002 19:35:18 -0400 (EDT) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from mercury.corp.iready.com ([65.115.68.100]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id g61NZGX02846 for ; Mon, 1 Jul 2002 19:35:17 -0400 (EDT) Received: by mercury.corp.iready.com with Internet Mail Service (5.5.2653.19) id ; Mon, 1 Jul 2002 16:35:11 -0700 Message-ID: <034670D62D19D31180990090277A37B702427E04@mercury.corp.iready.com> From: Jonathan Trostle To: "'Black_David@emc.com'" Cc: ips@ece.cmu.edu Subject: RE: IPS-All: Reminder - Security draft last call ends Monday, Jul y 1 at 8am EST Date: Mon, 1 Jul 2002 16:35:09 -0700 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C22157.F0611200" Sender: owner-ips@ece.cmu.edu Precedence: bulk This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_001_01C22157.F0611200 Content-Type: text/plain; charset="iso-8859-1" It's fine as is. Jonathan -----Original Message----- From: Black_David@emc.com [mailto:Black_David@emc.com] Sent: Monday, July 01, 2002 4:09 PM To: jtrostle@corp.iready.com Cc: ips@ece.cmu.edu Subject: RE: IPS-All: Reminder - Security draft last call ends Monday, Jul y 1 at 8am EST Jonathan, So, is the existing text ok, or do you want something changed? I don't think I see any harm in using a negative authentication cache when iSNS is operated securely, although, as Bernard noted, it's not necessary. Thanks, --David -----Original Message----- From: Jonathan Trostle [mailto:jtrostle@corp.iready.com] Sent: Monday, July 01, 2002 6:55 PM To: 'Black_David@emc.com' Cc: ips@ece.cmu.edu Subject: RE: IPS-All: Reminder - Security draft last call ends Monday, Jul y 1 at 8am EST That helps to clarify it. I don't think that the draft should require an administrative interface. Jonathan -----Original Message----- From: Black_David@emc.com [ mailto:Black_David@emc.com ] Sent: Monday, July 01, 2002 3:36 PM To: jtrostle@corp.iready.com Cc: ips@ece.cmu.edu Subject: RE: IPS-All: Reminder - Security draft last call ends Monday, Jul y 1 at 8am EST > When a target ends up in the negative authentication cache, does > that imply that the initiator will not contact the target while > it's in the cache, or does it imply that the initiator can contact > the target but should not use IPsec (if IPsec failed)? Or shouldn't > use app level security if app level security failed? The first - initiator will not contact the target while it's in the cache under the assumption that authentication will just fail again. As Bernard wrote, this protects against a denial of service attack where a rogue iSNS server in league with a rogue iSCSI target causes an initiator to repeatedly waste its time trying to talk to the target. Would it help to require an administrative interface to clear entries from the negative cache or the entire cache? Thanks, --David --------------------------------------------------- David L. Black, Senior Technologist EMC Corporation, 42 South St., Hopkinton, MA 01748 +1 (508) 249-6449 *NEW* FAX: +1 (508) 497-8500 black_david@emc.com Cell: +1 (978) 394-7754 --------------------------------------------------- -----Original Message----- From: Jonathan Trostle [ mailto:jtrostle@corp.iready.com ] Sent: Monday, July 01, 2002 6:17 PM To: 'Bernard Aboba' Cc: 'ips@ece.cmu.edu' Subject: RE: IPS-All: Reminder - Security draft last call ends Monday, Jul y 1 at 8am EST When a target ends up in the negative authentication cache, does that imply that the initiator will not contact the target while it's in the cache, or does it imply that the initiator can contact the target but should not use IPsec (if IPsec failed)? Or shouldn't use app level security if app level security failed? Jonathan -----Original Message----- From: Bernard Aboba [ mailto:bernard_aboba@hotmail.com ] Sent: Saturday, June 29, 2002 10:42 PM To: jtrostle@corp.iready.com; ips@ece.cmu.edu Subject: RE: IPS-All: Reminder - Security draft last call ends Monday, July 1 at 8am EST >One comment/question on the security draft below: > >p. 23: "Where iSNS is used without security, IP block storage protocol >implementations MUST support a negative cache for authentication >failures." > >Is it worth pointing out that when iSNS is used with security, then a >negative cache MUST NOT be used? An attacker can cause authentication >to >fail through a DoS attack which could result in an entry being >added to >the negative cache. There are two orthogonal issues here -- one is iSNS security, the other is IPS protocol security. If iSNS is not secured, then a peer might receive and accept an iSNS packet from a rogue iSNS server. However, if the IPS session is subsequently secured, and mutually authenticated, the endpoint specified in the bogus discovery message will fail to authenticate. The argument is that this should result in a negative cache entry within the iSNS implementation, so as to prevent continual attempts to authenticate to bogus peers. If iSNS is secured, then presumably this would preclude a rogue iSNS server, and the negative cache is unnecessary. Do you have an issue with the negative cache in general, or just its use where iSNS is secured? _________________________________________________________________ Send and receive Hotmail on your mobile device: http://mobile.msn.com ------_=_NextPart_001_01C22157.F0611200 Content-Type: text/html; charset="iso-8859-1" RE: IPS-All: Reminder - Security draft last call ends Monday, Jul y 1 at 8am EST
It's fine as is.
 
Jonathan
-----Original Message-----
From: Black_David@emc.com [mailto:Black_David@emc.com]
Sent: Monday, July 01, 2002 4:09 PM
To: jtrostle@corp.iready.com
Cc: ips@ece.cmu.edu
Subject: RE: IPS-All: Reminder - Security draft last call ends Monday, Jul y 1 at 8am EST

Jonathan,
 
So, is the existing text ok, or do you want something changed?
 
I don't think I see any harm
in using a negative authentication cache when iSNS is operated
securely, although, as Bernard noted, it's not necessary.
 
Thanks,
--David
-----Original Message-----
From: Jonathan Trostle [mailto:jtrostle@corp.iready.com]
Sent: Monday, July 01, 2002 6:55 PM
To: 'Black_David@emc.com'
Cc: ips@ece.cmu.edu
Subject: RE: IPS-All: Reminder - Security draft last call ends Monday, Jul y 1 at 8am EST

That helps to clarify it. I don't think that the draft should require an administrative interface.

Jonathan

-----Original Message-----
From: Black_David@emc.com [mailto:Black_David@emc.com]
Sent: Monday, July 01, 2002 3:36 PM
To: jtrostle@corp.iready.com
Cc: ips@ece.cmu.edu
Subject: RE: IPS-All: Reminder - Security draft last call ends Monday,
Jul y 1 at 8am EST


> When a target ends up in the negative authentication cache, does
> that imply that the initiator will not contact the target while
> it's in the cache, or does  it imply that the initiator can contact
> the target but should not use IPsec (if IPsec failed)? Or shouldn't
> use app level security if app level security failed?

The first - initiator will not contact the target while it's in the
cache under the assumption that authentication will just fail again.
As Bernard wrote, this protects against a denial of service attack
where a rogue iSNS server in league with a rogue iSCSI target causes
an initiator to repeatedly waste its time trying to talk to the target.

Would it help to require an administrative interface to clear entries
from the negative cache or the entire cache?

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

-----Original Message-----
From: Jonathan Trostle [mailto:jtrostle@corp.iready.com]
Sent: Monday, July 01, 2002 6:17 PM
To: 'Bernard Aboba'
Cc: 'ips@ece.cmu.edu'
Subject: RE: IPS-All: Reminder - Security draft last call ends Monday, Jul y
1 at 8am EST




When a target ends up in the negative authentication cache, does that imply
that the initiator will not contact the target while it's in the cache, or
does  it imply that the initiator can contact the target but should not use
IPsec (if IPsec failed)? Or shouldn't use app level security if app level
security failed?
Jonathan
-----Original Message-----
From: Bernard Aboba [mailto:bernard_aboba@hotmail.com]
Sent: Saturday, June 29, 2002 10:42 PM
To: jtrostle@corp.iready.com; ips@ece.cmu.edu
Subject: RE: IPS-All: Reminder - Security draft last call ends Monday,
July 1 at 8am EST


>One comment/question on the security draft below:
>
>p. 23: "Where iSNS is used without security, IP block storage protocol
>implementations MUST support a negative cache for authentication
>failures."
>
>Is it worth pointing out that when iSNS is used with security, then a
>negative cache MUST NOT be used? An attacker can cause authentication >to
>fail through a DoS attack which could result in an entry being >added to
>the negative cache.
There are two orthogonal issues here -- one is iSNS security, the other is
IPS protocol security. If iSNS is not secured, then a peer might receive and

accept an iSNS packet from a rogue iSNS server. However, if the IPS session
is subsequently secured, and mutually authenticated, the endpoint specified
in the bogus discovery message will fail to authenticate. The argument is
that this should result in a negative cache entry within the iSNS
implementation, so as to prevent continual attempts to authenticate to bogus

peers.
If iSNS is secured, then presumably this would preclude a rogue iSNS server,

and the negative cache is unnecessary.
Do you have an issue with the negative cache in general, or just its use
where iSNS is secured?





_________________________________________________________________
Send and receive Hotmail on your mobile device: http://mobile.msn.com

------_=_NextPart_001_01C22157.F0611200-- From owner-ips@ece.cmu.edu Mon Jul 1 20:00:17 2002 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA10362 for ; Mon, 1 Jul 2002 20:00:12 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id g61NJUx02440 for ips-outgoing; Mon, 1 Jul 2002 19:19:30 -0400 (EDT) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from maho3msx2.isus.emc.com (maho3msx2.isus.emc.com [128.221.11.32]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id g61NJTX02436 for ; Mon, 1 Jul 2002 19:19:29 -0400 (EDT) Received: by MAHO3MSX2 with Internet Mail Service (5.5.2653.19) id ; Mon, 1 Jul 2002 19:17:34 -0400 Message-ID: <277DD60FB639D511AC0400B0D068B71E0564C00A@CORPMX14> From: Black_David@emc.com To: ips@ece.cmu.edu Subject: RE: iSCSI version 14 draft Date: Mon, 1 Jul 2002 19:17:30 -0400 Importance: high X-Priority: 1 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C22155.78FC69A0" Sender: owner-ips@ece.cmu.edu Precedence: bulk This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_001_01C22155.78FC69A0 Content-Type: text/plain; charset="iso-8859-1" One more thing on iSCSI draft -14. There is a list of 29 issues addressed in moving from draft -13 to draft -14 at: http://www.haifa.il.ibm.com/satran/ips/iSCSI-WG-Last-Call-Issues-And-Resolut ion.txt Would those who raised the issues, please check that the text in draft -14 addresses your issue(s): http://www.haifa.il.ibm.com/satran/ips/draft-ietf-ips-iscsi-14.txt (and coming soon to the Internet-Draft servers) If it doesn't please speak up before the end of WG Last Call on Sunday. Thanks, --David -----Original Message----- From: Black_David@emc.com [mailto:Black_David@emc.com] Sent: Monday, July 01, 2002 11:16 AM To: eddy_quicksall@ivivity.com Cc: ips@ece.cmu.edu Subject: RE: iSCSI version 14 draft > I assume this will now enter a different discussion phase. If so, can someone advise > me on how to get onto that mailing list? That is an incorrect assumption. -14 incorporates the changes identified so far in WG Last Call. iSCSI is still in WG Last Call for another week (ends at 5pm Eastern Time on Sunday, July 7th). All technical issues with the draft need to be brought to this mailing list - editorial comments can be sent directly to Julian. Once a successful WG Last Call ends, the WG chairs work with the draft authors to produce the final version to be submitted to the ADs/IESG, but there is no further opportunity for WG comments on the draft - that's what "WG Last Call" means. Also, would everyone please be careful about email "Reply To All" and the like -- internet-drafts@ietf.org did not need or want a copy of Eddy's message. Thanks, --David --------------------------------------------------- David L. Black, Senior Technologist EMC Corporation, 42 South St., Hopkinton, MA 01748 +1 (508) 249-6449 *NEW* FAX: +1 (508) 497-8500 black_david@emc.com Cell: +1 (978) 394-7754 --------------------------------------------------- -----Original Message----- From: Eddy Quicksall [mailto:eddy_quicksall@ivivity.com] Sent: Monday, July 01, 2002 11:07 AM To: Julian Satran; internet-drafts@ietf.org Cc: ips@ece.cmu.edu Subject: RE: iSCSI version 14 draft I assume this will now enter a different discussion phase. If so, can someone advise me on how to get onto that mailing list? Eddy -----Original Message----- From: Julian Satran [mailto:Julian_Satran@il.ibm.com] Sent: Monday, July 01, 2002 3:23 AM To: internet-drafts@ietf.org Cc: ips@ece.cmu.edu Subject: iSCSI version 14 draft On behalf of the team of authors and as part of the IETF-IPS working group I submit a draft for immediate publication. The text and pdf versions can be found at: http://www.haifa.il.ibm.com/satran/ips/draft-ietf-ips-iscsi-14.txt http://www.haifa.il.ibm.com/satran/ips/draft-ietf-ips-iscsi-14.pdf This version completely replaces: draft-ietf-ips-iscsi-13.txt and pdf Julian Satran - IBM Research Laboratory at Haifa ------_=_NextPart_001_01C22155.78FC69A0 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
One more=20 thing on iSCSI draft -14.  There is a list of 29 = issues
addressed=20 in=20 moving from draft -13 to draft -14 at:
 
http://www.haifa.il.ibm.com/satran/ips/iSCSI-WG-Las= t-Call-Issues-And-Resolution.txt
 
Would those=20 who raised the issues, please check that the text = in
draft -14=20 addresses your issue(s):
 
http://www.haifa.il.ibm.com/satran/ips/draft-ietf-ips-iscsi-14.txt
(and coming=20 soon to the Internet-Draft servers)
 
If it=20 doesn't please speak up before the end of WG Last Call = on
Sunday.
 
Thanks,
--David
-----Original Message-----
From: = Black_David@emc.com=20 [mailto:Black_David@emc.com]
Sent: Monday, July 01, 2002 = 11:16=20 AM
To: eddy_quicksall@ivivity.com
Cc:=20 ips@ece.cmu.edu
Subject: RE: iSCSI version 14=20 draft

> I assume = this will now=20 enter a different discussion phase. If so, can someone=20 advise
> me on how = to get onto=20 that mailing list?
 
That is an=20 incorrect assumption.  -14 incorporates the = changes
identified=20 so far in WG Last Call.  iSCSI is = still in WG=20 Last
Call for=20 another week (ends at 5pm Eastern Time on Sunday, July=20 7th).
All=20 technical issues with the draft need to be brought to = this
mailing=20 list - editorial comments can be sent directly to = Julian.
Once a=20 successful WG Last Call ends, the WG chairs work with = the
draft=20 authors to produce the final version to be = submitted to=20 the
ADs/IESG,=20 but there is no further opportunity for WG=20 comments
on the=20 draft - that's what "WG Last Call" means.
 
Also,=20 would everyone please be careful about email "Reply To=20 All"
and the=20 like -- internet-drafts@ietf.org = did not need or want a = copy
of Eddy's=20 message.
 
Thanks,
--David

---------------------------------------------------
David=20 L. Black, Senior Technologist
EMC Corporation, 42 South St., = Hopkinton,=20 MA  01748
+1 (508) 249-6449 = *NEW*      FAX:=20 +1 (508)=20 = 497-8500
black_david@emc.com       = ; =20 Cell: +1 (978)=20 = 394-7754
---------------------------------------------------

-----Original Message-----
From: Eddy Quicksall=20 [mailto:eddy_quicksall@ivivity.com]
Sent: Monday, July = 01, 2002=20 11:07 AM
To: Julian Satran; = internet-drafts@ietf.org
Cc:=20 ips@ece.cmu.edu
Subject: RE: iSCSI version 14=20 draft

I = assume this=20 will now enter a different discussion phase. If so, can someone = advise me on=20 how to get onto that mailing list?
 
Eddy
-----Original Message-----
From: Julian Satran = [mailto:Julian_Satran@il.ibm.com]
Sent: Monday, July = 01, 2002=20 3:23 AM
To: internet-drafts@ietf.org
Cc:=20 ips@ece.cmu.edu
Subject: iSCSI version 14=20 draft



On behalf=20 of the team of authors and as part of the IETF-IPS working group=20
I submit a draft for = immediate=20 publication.

The = text and pdf=20 versions can be found at:

http://www.haifa.il.ibm.com/satran/ips/draft-ietf-ips-iscsi-14.= txt=20

http://www.haifa.il.ibm.com/satran/ips/draft-ietf-ips-iscsi-14.= pdf=20


This version = completely=20 replaces:

draft-ietf-ips-iscsi-13.txt and pdf =



Julian Satran - IBM Research = Laboratory at=20 Haifa=20 =

















=









------_=_NextPart_001_01C22155.78FC69A0-- From owner-ips@ece.cmu.edu Tue Jul 2 02:09:57 2002 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA26524 for ; Tue, 2 Jul 2002 02:09:57 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id g625Uuf11828 for ips-outgoing; Tue, 2 Jul 2002 01:30:56 -0400 (EDT) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from d12lmsgate.de.ibm.com (d12lmsgate.de.ibm.com [195.212.91.199]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id g625UsX11821 for ; Tue, 2 Jul 2002 01:30:54 -0400 (EDT) Received: from d12relay01.de.ibm.com (d12relay01.de.ibm.com [9.165.215.22]) by d12lmsgate.de.ibm.com (8.12.3/8.12.3) with ESMTP id g625UcrC012834; Tue, 2 Jul 2002 07:30:39 +0200 Received: from d10hubm1.telaviv.ibm.com (d10ml001.telaviv.ibm.com [9.148.216.55]) by d12relay01.de.ibm.com (8.11.1m3/NCO/VER6.1) with ESMTP id g625Ub851058; Tue, 2 Jul 2002 07:30:38 +0200 To: "LEMAY,KEVIN (A-Roseville,ex1)" Cc: ips@ece.cmu.edu, "'Satran, Julian'" , owner-ips@ece.cmu.edu MIME-Version: 1.0 Subject: Re: iSCSI: Decimal encoding - why 64 bits ? X-Mailer: Lotus Notes Release 5.0.9 November 16, 2001 From: "Julian Satran" Message-ID: Date: Tue, 2 Jul 2002 08:30:36 +0300 X-MIMETrack: Serialize by Router on D10ML001/10/M/IBM(Release 5.0.9a |January 7, 2002) at 02/07/2002 08:30:37, Serialize complete at 02/07/2002 08:30:37 Content-Type: multipart/alternative; boundary="=_alternative 001DE1EDC2256BEA_=" Sender: owner-ips@ece.cmu.edu Precedence: bulk This is a multipart message in MIME format. --=_alternative 001DE1EDC2256BEA_= Content-Type: text/plain; charset="us-ascii" There was a long debate and 64 bit was deemed a decent compromise. As for 32bit machines - you should have no difficulty in doing that on a 32bit machine (or even a 16 bit machine). Julo "LEMAY,KEVIN (A-Roseville,ex1)" Sent by: owner-ips@ece.cmu.edu 07/02/2002 12:01 AM Please respond to "LEMAY,KEVIN (A-Roseville,ex1)" To: "'Satran, Julian'" , ips@ece.cmu.edu cc: Subject: iSCSI: Decimal encoding - why 64 bits ? Julian, Why does decimal encoding support 64 bit values instead of only 32 bits? For implementations running on 32bit machines, supporting 64 bit decimal encoding will not be fun. Sure, it can be done in software, but is it really needed? All of the operational parameters fit in 32 bits. The only possible use for 64 bits is in authentication or vendor specific keys. Hex and base64 encoding make more sense for these cases for the long authentication keys and hex and base64 encoders/decoders must be provided by a compliant implementation anyway. Could we restrict the decimal encoding to 32 bits and make binary values use only hex and base 64? Thanks, Kevin --=_alternative 001DE1EDC2256BEA_= Content-Type: text/html; charset="us-ascii"
There was a long debate and 64 bit was deemed a decent compromise.
As for 32bit machines - you should have no difficulty in doing that on a 32bit machine (or even a 16 bit machine).

Julo


"LEMAY,KEVIN (A-Roseville,ex1)" <kevin_lemay@agilent.com>
Sent by: owner-ips@ece.cmu.edu

07/02/2002 12:01 AM
Please respond to "LEMAY,KEVIN (A-Roseville,ex1)"

       
        To:        "'Satran, Julian'" <julian_satran@hotmail.com>, ips@ece.cmu.edu
        cc:        
        Subject:        iSCSI: Decimal encoding - why 64 bits ?

       


Julian,

Why does decimal encoding support 64 bit values instead of only 32 bits?

For implementations running on 32bit machines, supporting 64 bit decimal encoding will not be fun. Sure, it can be done in software, but is it really needed?

All of the operational parameters fit in 32 bits. The only possible use for 64 bits is in authentication or vendor specific keys. Hex and base64 encoding make more sense for these cases for the long authentication keys and hex and base64 encoders/decoders must be provided by a compliant implementation anyway.

Could we restrict the decimal encoding to 32 bits and make binary values use only hex and base 64?

Thanks,

Kevin


--=_alternative 001DE1EDC2256BEA_=-- From owner-ips@ece.cmu.edu Tue Jul 2 03:58:00 2002 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA28008 for ; Tue, 2 Jul 2002 03:58:00 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id g627AaA13901 for ips-outgoing; Tue, 2 Jul 2002 03:10:36 -0400 (EDT) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from d12lmsgate.de.ibm.com (d12lmsgate.de.ibm.com [195.212.91.199]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id g627AYX13895 for ; Tue, 2 Jul 2002 03:10:34 -0400 (EDT) Received: from d12relay01.de.ibm.com (d12relay01.de.ibm.com [9.165.215.22]) by d12lmsgate.de.ibm.com (8.12.3/8.12.3) with ESMTP id g627ANrC044138; Tue, 2 Jul 2002 09:10:23 +0200 Received: from d10hubm1.telaviv.ibm.com (d10ml001.telaviv.ibm.com [9.148.216.55]) by d12relay01.de.ibm.com (8.11.1m3/NCO/VER6.1) with ESMTP id g627AM8116216; Tue, 2 Jul 2002 09:10:22 +0200 To: pat_thaler@agilent.com Cc: ips@ece.cmu.edu MIME-Version: 1.0 Subject: RE: iSCSI: Login negotiation space X-Mailer: Lotus Notes Release 5.0.9 November 16, 2001 From: "Julian Satran" Message-ID: Date: Tue, 2 Jul 2002 10:10:21 +0300 X-MIMETrack: Serialize by Router on D10ML001/10/M/IBM(Release 5.0.9a |January 7, 2002) at 02/07/2002 10:10:22, Serialize complete at 02/07/2002 10:10:22 Content-Type: multipart/alternative; boundary="=_alternative 0026E1B3C2256BEA_=" Sender: owner-ips@ece.cmu.edu Precedence: bulk This is a multipart message in MIME format. --=_alternative 0026E1B3C2256BEA_= Content-Type: text/plain; charset="us-ascii" Pat, A factor of 10 over what is needed today is what I would call a conservative design. Limiting the support to 2k would be extremely unwise. And 16 is a tiny amount of memory - of no concern to software implementation and to most hardware implementations. Julo pat_thaler@agilent.com 07/02/2002 01:56 AM Please respond to pat_thaler To: Julian Satran/Haifa/IBM@IBMIL cc: ips@ece.cmu.edu Subject: RE: iSCSI: Login negotiation space Julian, 4.1 contains a requirement that initiators and targets support receiving at least 16384 bytes of key=value data (when not supporting very long authentication items). This is overkill and is making drivers larger than they need to be. My calculations are that Security negotiation using the CHAP method (including the Any-stage keys) takes less than 1600 bytes. Operational negotiation requires 1276 bytes (also including the Any-stage keys). All the operational plus security keys are 1911 bytes. Therefore an implementation could hold all the necessary keys in 2 Kbytes. And, the implementation doesn't need to keep the security keys after the security negotiation is done so it could clear some of that out to make room for future keys or vendor specific keys. 16 K bytes is about 10 times the necessary storage in that case. The number of negotiation bytes that a device is required to support should be reduced substantially - preferably to 2048 bytes. Regards, Pat The numbers: 43 AuthMethod CHAP keys 264 Name (no defined size limit - using 255) 11 Algorithm 11 Identifier 264 Challenge 42 Response (for MD5) _____ 635 Chap negotiation length 892 Any-stage keys ---- 1527 Operational negotiation keys 24 HeaderDigest 24 DataDigest 49 MaxConnections 270 TargetName* or InitiatorName* 271 TargetAlias* or InitiatorAlias* 273 TargetAddress* 55 TargetPortalGroupTag* 15 InitialR2T 19 BidiInitialR2T 18 ImmediateData 34 MaxRecvDataSegmentLength 24 MaxBurstLength 26 FirstBurstLength 24 DefaultTime2Wait 26 DefaultTime2Retain 25 MaxOutstandingR2T 18 DataPDUInOrder 24 DataSequenceInOrder 24 ErrorRecoveryLevel 23 SessionType* ------ 892 Any-stage keys 384 Not Any-stage ------ 1276 Operational keys --=_alternative 0026E1B3C2256BEA_= Content-Type: text/html; charset="us-ascii"
Pat,

A factor of 10 over what is needed today is what I would call a conservative design.
Limiting the support to 2k would be extremely unwise.
And 16 is a tiny amount of memory - of no concern to software implementation and to most hardware implementations.

Julo



pat_thaler@agilent.com

07/02/2002 01:56 AM
Please respond to pat_thaler

       
        To:        Julian Satran/Haifa/IBM@IBMIL
        cc:        ips@ece.cmu.edu
        Subject:        RE: iSCSI: Login negotiation space

       


Julian,

4.1 contains a requirement that initiators and targets support receiving at least 16384 bytes of key=value data (when not supporting very long authentication items). This is overkill and is making drivers larger than they need to be.

My calculations are that Security negotiation using the CHAP method (including the Any-stage keys) takes less than 1600 bytes. Operational negotiation requires 1276 bytes (also including the Any-stage keys). All the operational plus security keys are 1911 bytes.

Therefore an implementation could hold all the necessary keys in 2 Kbytes. And, the implementation doesn't need to keep the security keys after the security negotiation is done so it could clear some of that out to make room for future keys or vendor specific keys. 16 K bytes is about 10 times the necessary storage in that case.

The number of negotiation bytes that a device is required to support should be reduced substantially - preferably to 2048 bytes.

Regards,
Pat


The numbers:

 43                                  AuthMethod
          CHAP keys
264                                  Name (no defined size limit - using 255)
 11                                  Algorithm
 11                                  Identifier
264                                  Challenge
 42                                  Response (for MD5)
_____
635 Chap negotiation length
892 Any-stage keys
----
1527

Operational negotiation keys
 24                                  HeaderDigest
 24        DataDigest
 49        MaxConnections
270                                  TargetName* or InitiatorName*
271                                  TargetAlias* or InitiatorAlias*
273        TargetAddress*
 55                                  TargetPortalGroupTag*
 15                                  InitialR2T
 19                                  BidiInitialR2T
 18                                  ImmediateData
 34                                  MaxRecvDataSegmentLength
 24                                  MaxBurstLength
 26                                  FirstBurstLength
 24                                  DefaultTime2Wait
 26                                  DefaultTime2Retain
 25                                  MaxOutstandingR2T
 18                                  DataPDUInOrder
 24                                  DataSequenceInOrder
 24                                  ErrorRecoveryLevel
 23                                  SessionType*
------
892 Any-stage keys
384 Not Any-stage
------
1276 Operational keys

--=_alternative 0026E1B3C2256BEA_=-- From owner-ips@ece.cmu.edu Tue Jul 2 10:00:54 2002 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA10208 for ; Tue, 2 Jul 2002 10:00:49 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id g62DIgA03452 for ips-outgoing; Tue, 2 Jul 2002 09:18:42 -0400 (EDT) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from ietf.org (odin.ietf.org [132.151.1.176]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id g62AVdX28991 for ; Tue, 2 Jul 2002 06:31:39 -0400 (EDT) Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA00995; Tue, 2 Jul 2002 06:30:51 -0400 (EDT) Message-Id: <200207021030.GAA00995@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; Cc: ips@ece.cmu.edu From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-ietf-ips-isns-11.txt Date: Tue, 02 Jul 2002 06:30:51 -0400 Sender: owner-ips@ece.cmu.edu Precedence: bulk --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the IP Storage Working Group of the IETF. Title : Internet Storage Name Service (iSNS) Author(s) : J. Tseng, K. Gibbons Filename : draft-ietf-ips-isns-11.txt Pages : 88 Date : 01-Jul-02 This document specifies the iSNS protocol, which is used for interaction between iSNS servers and iSNS clients in order to facilitate automated discovery, management, and configuration of iSCSI and Fibre Channel (FCP) devices on a TCP/IP network. iSNS provides intelligent storage discovery and management services comparable to those found in Fibre Channel networks, allowing a commodity IP network to function in a similar capacity as a storage area network. iSNS also facilitates a seamless integration of IP and Fibre Channel networks, due to its ability to emulate Fibre Channel fabric services, and manage both iSCSI and Fibre Channel devices. iSNS thereby provides value in any storage network comprised of iSCSI devices, Fibre Channel devices, or any combination thereof. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-ips-isns-11.txt To remove yourself from the IETF Announcement list, send a message to ietf-announce-request with the word unsubscribe in the body of the message. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-ips-isns-11.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-ips-isns-11.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <20020701151935.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-ips-isns-11.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-ips-isns-11.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <20020701151935.I-D@ietf.org> --OtherAccess-- --NextPart-- From owner-ips@ece.cmu.edu Tue Jul 2 10:03:48 2002 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA10357 for ; Tue, 2 Jul 2002 10:03:48 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id g62DIL003429 for ips-outgoing; Tue, 2 Jul 2002 09:18:21 -0400 (EDT) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from ietf.org (odin.ietf.org [132.151.1.176]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id g62AVZX28979 for ; Tue, 2 Jul 2002 06:31:35 -0400 (EDT) Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA00977; Tue, 2 Jul 2002 06:30:46 -0400 (EDT) Message-Id: <200207021030.GAA00977@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; Cc: ips@ece.cmu.edu From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-ietf-ips-iscsi-mib-05.txt Date: Tue, 02 Jul 2002 06:30:46 -0400 Sender: owner-ips@ece.cmu.edu Precedence: bulk --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the IP Storage Working Group of the IETF. Title : Definitions of Managed Objects for iSCSI Author(s) : M. Bakke, J. Muchow, M. Krueger, T. McSweeney Filename : draft-ietf-ips-iscsi-mib-05.txt Pages : 69 Date : 01-Jul-02 This memo defines a portion of the Management Information Base (MIB) for use with network management protocols in TCP/IP based internets. In particular it defines objects for managing a client using the iSCSI (SCSI over TCP) protocol. It is meant to match the latest version of iSCSI defined in [ISCSI]. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-ips-iscsi-mib-05.txt To remove yourself from the IETF Announcement list, send a message to ietf-announce-request with the word unsubscribe in the body of the message. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-ips-iscsi-mib-05.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-ips-iscsi-mib-05.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <20020701151926.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-ips-iscsi-mib-05.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-ips-iscsi-mib-05.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <20020701151926.I-D@ietf.org> --OtherAccess-- --NextPart-- From owner-ips@ece.cmu.edu Tue Jul 2 10:05:01 2002 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA10402 for ; Tue, 2 Jul 2002 10:05:00 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id g62DIbj03443 for ips-outgoing; Tue, 2 Jul 2002 09:18:37 -0400 (EDT) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from ietf.org (odin.ietf.org [132.151.1.176]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id g62AVjX29002 for ; Tue, 2 Jul 2002 06:31:45 -0400 (EDT) Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA00965; Tue, 2 Jul 2002 06:30:42 -0400 (EDT) Message-Id: <200207021030.GAA00965@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; Cc: ips@ece.cmu.edu From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-ietf-ips-auth-mib-01.txt Date: Tue, 02 Jul 2002 06:30:41 -0400 Sender: owner-ips@ece.cmu.edu Precedence: bulk --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the IP Storage Working Group of the IETF. Title : Definitions of Managed Objects for User Identity Authentication Author(s) : M. Bakke, J. Muchow Filename : draft-ietf-ips-auth-mib-01.txt Pages : 26 Date : 01-Jul-02 This memo defines a portion of the Management Information Base (MIB) for use with network management protocols in TCP/IP based internets. In particular it defines objects for managing user identities and the names, addresses, and credentials required to authenticate them, for use with various protocols. This draft was motivated by the need for the configuration of authenticated user identities for the iSCSI protocol [ISCSI], but has been extended to be useful for other protocols that have similar requirements. It is important to note that this MIB provides only the set of identities and the means to authenticate them; it is the responsibility of other MIBs making use of this one to tie them to authorization lists. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-ips-auth-mib-01.txt To remove yourself from the IETF Announcement list, send a message to ietf-announce-request with the word unsubscribe in the body of the message. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-ips-auth-mib-01.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-ips-auth-mib-01.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <20020701151916.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-ips-auth-mib-01.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-ips-auth-mib-01.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <20020701151916.I-D@ietf.org> --OtherAccess-- --NextPart-- From owner-ips@ece.cmu.edu Tue Jul 2 11:35:02 2002 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA22821 for ; Tue, 2 Jul 2002 11:35:02 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id g62FFJ009561 for ips-outgoing; Tue, 2 Jul 2002 11:15:19 -0400 (EDT) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from mailhub.lss.emc.com (xdch.emc.com [168.159.1.79]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id g62FFIX09557 for ; Tue, 2 Jul 2002 11:15:18 -0400 (EDT) Received: from emc.com (emcmail.lss.emc.com [168.159.48.78]) by mailhub.lss.emc.com (Switch-2.2.0/Switch-2.2.0) with ESMTP id g62FF6V26226 for ; Tue, 2 Jul 2002 11:15:06 -0400 (EDT) Received: from mxic1.isus.emc.com ([168.159.129.100]) by emc.com (8.10.1/8.10.1) with ESMTP id g62FF5710735 for ; Tue, 2 Jul 2002 11:15:05 -0400 (EDT) Received: by MXIC1 with Internet Mail Service (5.5.2653.19) id ; Tue, 2 Jul 2002 11:13:14 -0400 Message-ID: <277DD60FB639D511AC0400B0D068B71E0564C00D@CORPMX14> From: Black_David@emc.com To: ips@ece.cmu.edu Subject: FW: I-D ACTION:draft-ietf-dhc-isnsoption-01.txt Date: Tue, 2 Jul 2002 11:13:12 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/mixed; boundary="----_=_NextPart_000_01C221DA.FB6B1000" Sender: owner-ips@ece.cmu.edu Precedence: bulk This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_000_01C221DA.FB6B1000 Content-Type: text/plain; charset="iso-8859-1" FYI, --David -----Original Message----- From: Internet-Drafts@ietf.org [mailto:Internet-Drafts@ietf.org] Sent: Tuesday, July 02, 2002 6:30 AM Cc: dhcwg@ietf.org Subject: I-D ACTION:draft-ietf-dhc-isnsoption-01.txt A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Dynamic Host Configuration Working Group of the IETF. Title : DHCP Options for Internet Storage Name Service Author(s) : J. Tseng, K. Gibbons Filename : draft-ietf-dhc-isnsoption-01.txt Pages : 9 Date : 01-Jul-02 This document describes the DHCP option to allow iSNS clients devices using DHCP to automatically discover the location of the iSNS server. iSNS provides discovery and management capabilities for iSCSI and Fibre Channel (FCP) storage devices in an enterprise-scale IP storage network. iSNS provides intelligent storage management services comparable to those found in Fibre Channel networks, allowing a commodity IP network to function in a similar capacity as a storage area network. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-dhc-isnsoption-01.txt To remove yourself from the IETF Announcement list, send a message to ietf-announce-request with the word unsubscribe in the body of the message. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-dhc-isnsoption-01.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-dhc-isnsoption-01.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. ------_=_NextPart_000_01C221DA.FB6B1000 Content-Type: message/rfc822 To: Subject: Date: Tue, 2 Jul 2002 11:13:14 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/mixed; boundary="----_=_NextPart_002_01C221DA.FB6B1000" ------_=_NextPart_002_01C221DA.FB6B1000 Content-Type: text/plain ------_=_NextPart_002_01C221DA.FB6B1000 Content-Type: application/octet-stream; name="ATT21287" Content-Disposition: attachment; filename="ATT21287" Content-type: message/external-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <20020701151831.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-dhc-isnsoption-01.txt ------_=_NextPart_002_01C221DA.FB6B1000 Content-Type: message/external-body; site="internet-drafts"; dir="draft-ietf-dhc-isnsoption-01.txt"; mode="ftp.ietf.org"; access-type="anon-ftp" ------_=_NextPart_002_01C221DA.FB6B1000-- ------_=_NextPart_000_01C221DA.FB6B1000-- From owner-ips@ece.cmu.edu Tue Jul 2 11:35:58 2002 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA22889 for ; Tue, 2 Jul 2002 11:35:52 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id g62EtH608504 for ips-outgoing; Tue, 2 Jul 2002 10:55:17 -0400 (EDT) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from msgbas2.cos.agilent.com (msgbas2x.cos.agilent.com [192.25.240.37]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id g62EtFX08498 for ; Tue, 2 Jul 2002 10:55:15 -0400 (EDT) Received: from msgrel1t.cos.agilent.com (msgrel1t.cos.agilent.com [130.29.152.157]) by msgbas2.cos.agilent.com (Postfix) with ESMTP id F3007183E; Tue, 2 Jul 2002 08:55:14 -0600 (MDT) Received: from axcsbh6.cos.agilent.com (axcsbh6.cos.agilent.com [130.29.152.171]) by msgrel1t.cos.agilent.com (Postfix) with SMTP id A19805B5; Tue, 2 Jul 2002 08:55:14 -0600 (MDT) Received: from 130.29.152.171 by axcsbh6.cos.agilent.com (InterScan E-Mail VirusWall NT); Tue, 02 Jul 2002 08:55:14 -0600 Received: by axcsbh6.cos.agilent.com with Internet Mail Service (5.5.2653.19) id ; Tue, 2 Jul 2002 08:55:14 -0600 Message-ID: <9F8400020EC5D311AF62009027C396160902C501@axcs09.cos.agilent.com> From: kevin_lemay@agilent.com To: Julian_Satran@il.ibm.com Cc: ips@ece.cmu.edu Subject: RE: iSCSI: Decimal encoding - why 64 bits ? Date: Tue, 2 Jul 2002 08:55:11 -0600 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="ISO-8859-1" Sender: owner-ips@ece.cmu.edu Precedence: bulk I wouldn't say no difficulty. Windows based machines do not allow 64 bit numbers as function parameters. My two vxWorks systems do not support 64 bit numbers. I haven't checked the gnu compiler for my linux Intel box. Saying that it should be no problem doesn't just make it so... I am sure that other people will hit the same wall and this will cause interoperability problems down the road. Kevin -----Original Message----- From: Julian Satran [mailto:Julian_Satran@il.ibm.com] Sent: Monday, July 01, 2002 10:31 PM To: LEMAY,KEVIN (A-Roseville,ex1) Cc: ips@ece.cmu.edu; 'Satran, Julian'; owner-ips@ece.cmu.edu Subject: Re: iSCSI: Decimal encoding - why 64 bits ? There was a long debate and 64 bit was deemed a decent compromise. As for 32bit machines - you should have no difficulty in doing that on a 32bit machine (or even a 16 bit machine). Julo "LEMAY,KEVIN (A-Roseville,ex1)" Sent by: owner-ips@ece.cmu.edu 07/02/2002 12:01 AM Please respond to "LEMAY,KEVIN (A-Roseville,ex1)" To: "'Satran, Julian'" , ips@ece.cmu.edu cc: Subject: iSCSI: Decimal encoding - why 64 bits ? Julian, Why does decimal encoding support 64 bit values instead of only 32 bits? For implementations running on 32bit machines, supporting 64 bit decimal encoding will not be fun. Sure, it can be done in software, but is it really needed? All of the operational parameters fit in 32 bits. The only possible use for 64 bits is in authentication or vendor specific keys. Hex and base64 encoding make more sense for these cases for the long authentication keys and hex and base64 encoders/decoders must be provided by a compliant implementation anyway. Could we restrict the decimal encoding to 32 bits and make binary values use only hex and base 64? Thanks, Kevin From owner-ips@ece.cmu.edu Tue Jul 2 13:34:42 2002 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA03142 for ; Tue, 2 Jul 2002 13:34:37 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id g62GnfA14561 for ips-outgoing; Tue, 2 Jul 2002 12:49:41 -0400 (EDT) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from lion.ninthwonder.com (lion.ninthwonder.com [151.199.66.147]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id g62GndX14557 for ; Tue, 2 Jul 2002 12:49:39 -0400 (EDT) Received: by lion.ninthwonder.com (Postfix, from userid 1021) id C499E30706; Tue, 2 Jul 2002 12:49:38 -0400 (EDT) Date: Tue, 2 Jul 2002 09:46:34 -0700 (PDT) From: Bill Studenmund X-X-Sender: To: Cc: , Subject: RE: iSCSI: Decimal encoding - why 64 bits ? In-Reply-To: <9F8400020EC5D311AF62009027C396160902C501@axcs09.cos.agilent.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ips@ece.cmu.edu Precedence: bulk On Tue, 2 Jul 2002 kevin_lemay@agilent.com wrote: > I wouldn't say no difficulty. Windows based machines do not allow 64 > bit numbers as function parameters. My two vxWorks systems do not > support 64 bit numbers. I haven't checked the gnu compiler for my > linux Intel box. Unless you have a very broken Linux install, gcc will handle 64 bit numbers as type 'long long'. > Saying that it should be no problem doesn't just make it so... I think the reason that it shouldn't be a problem is that there are no numbers we're going to be passing around at the moment (i.e. this version of the draft) that need more than 32 bits. Thus you're fine with using 32 bit parameters (with the ability to detect overflows). > I am sure that other people will hit the same wall and this will cause > interoperability problems down the road. I'm not sure. But I think that if we get parameters which need 64 bits, then we will probably be bumping the protocol version, and current devices will indicate they don't support it. > Kevin > > -----Original Message----- > From: Julian Satran [mailto:Julian_Satran@il.ibm.com] > Sent: Monday, July 01, 2002 10:31 PM > To: LEMAY,KEVIN (A-Roseville,ex1) > Cc: ips@ece.cmu.edu; 'Satran, Julian'; owner-ips@ece.cmu.edu > Subject: Re: iSCSI: Decimal encoding - why 64 bits ? > > > > There was a long debate and 64 bit was deemed a decent compromise. > As for 32bit machines - you should have no difficulty in doing that on a 32bit machine (or even a 16 bit machine). > > Julo > > > > "LEMAY,KEVIN (A-Roseville,ex1)" > Sent by: owner-ips@ece.cmu.edu > > > 07/02/2002 12:01 AM > Please respond to "LEMAY,KEVIN (A-Roseville,ex1)" > > > > To: "'Satran, Julian'" , ips@ece.cmu.edu > cc: > Subject: iSCSI: Decimal encoding - why 64 bits ? > > > > > Julian, > > Why does decimal encoding support 64 bit values instead of only 32 bits? > > For implementations running on 32bit machines, supporting 64 bit decimal encoding will not be fun. Sure, it can be done in software, but is it really needed? > > All of the operational parameters fit in 32 bits. The only possible use for 64 bits is in authentication or vendor specific keys. Hex and base64 encoding make more sense for these cases for the long authentication keys and hex and base64 encoders/decoders must be provided by a compliant implementation anyway. > > Could we restrict the decimal encoding to 32 bits and make binary values use only hex and base 64? > > Thanks, > > Kevin > > > From owner-ips@ece.cmu.edu Tue Jul 2 15:33:25 2002 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA10711 for ; Tue, 2 Jul 2002 15:33:25 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id g62J6CJ21400 for ips-outgoing; Tue, 2 Jul 2002 15:06:12 -0400 (EDT) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from lion.ninthwonder.com (lion.ninthwonder.com [151.199.66.147]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id g62J6AX21392 for ; Tue, 2 Jul 2002 15:06:10 -0400 (EDT) Received: by lion.ninthwonder.com (Postfix, from userid 1021) id BAE6430706; Tue, 2 Jul 2002 15:06:09 -0400 (EDT) Date: Tue, 2 Jul 2002 12:03:09 -0700 (PDT) From: Bill Studenmund X-X-Sender: To: "THALER,PAT (A-Roseville,ex1)" Cc: "LEMAY,KEVIN (A-Roseville,ex1)" , , Subject: RE: iSCSI: Decimal encoding - why 64 bits ? In-Reply-To: <1BEBA5E8600DD4119A50009027AF54A00CB26D18@axcs04.cos.agilent.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ips@ece.cmu.edu Precedence: bulk On Tue, 2 Jul 2002, THALER,PAT (A-Roseville,ex1) wrote: > Bill, > > The decimal encoding is not just for numbers. It is also allowed for > binary-values. Both CHAP and SRP exchange items that are identified as > binary-values. In general these will be longer than 64 bits, but in > cases where they are 64 bits or less the decimal encoding is currently > allowed so we would have to support it. I thought we had a big discussion about this, and we decided that decimal was only used for numbers, hex for numbers and binary, and base64 only for binary items. ?? Doh! I just looked in -14, and the text doesn't reflect that understanding. Hmmm. > The issue is that currently decimal encoding is allowed for > binary-values and numbers less than 64 bits. There is little need for > it over 32 bits. We have two other entirely adequate representations > for those numbers. Why have something in there that causes extra code > for no benefit? All I can say is I thought it was removed. :-| Take care, Bill From owner-ips@ece.cmu.edu Tue Jul 2 15:33:46 2002 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA10734 for ; Tue, 2 Jul 2002 15:33:45 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id g62JFjB21937 for ips-outgoing; Tue, 2 Jul 2002 15:15:45 -0400 (EDT) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from msgbas2.cos.agilent.com (msgbas2x.cos.agilent.com [192.25.240.37]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id g62JFiX21933 for ; Tue, 2 Jul 2002 15:15:44 -0400 (EDT) Received: from msgrel1t.cos.agilent.com (msgrel1t.cos.agilent.com [130.29.152.157]) by msgbas2.cos.agilent.com (Postfix) with ESMTP id CBD2015B9; Tue, 2 Jul 2002 13:15:43 -0600 (MDT) Received: from axcsbh1.cos.agilent.com (axcsbh1.cos.agilent.com [130.29.152.143]) by msgrel1t.cos.agilent.com (Postfix) with SMTP id 5FFA5512; Tue, 2 Jul 2002 13:15:43 -0600 (MDT) Received: from 130.29.152.143 by axcsbh1.cos.agilent.com (InterScan E-Mail VirusWall NT); Tue, 02 Jul 2002 13:15:42 -0600 Received: by axcsbh1.cos.agilent.com with Internet Mail Service (5.5.2653.19) id ; Tue, 2 Jul 2002 13:15:42 -0600 Message-ID: <1BEBA5E8600DD4119A50009027AF54A00CB26D28@axcs04.cos.agilent.com> From: "THALER,PAT (A-Roseville,ex1)" To: Bill Studenmund , "THALER,PAT (A-Roseville,ex1)" Cc: "LEMAY,KEVIN (A-Roseville,ex1)" , Julian_Satran@il.ibm.com, ips@ece.cmu.edu Subject: RE: iSCSI: Decimal encoding - why 64 bits ? Date: Tue, 2 Jul 2002 13:15:36 -0600 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-ips@ece.cmu.edu Precedence: bulk Bill, I also thought that the result of the reflector discussion was agreement that decimal would only be used for numbers and not be used for strings that are sometimes longer than the 64 bit limit like CHAP and SRP strings. That seems to be partially implemented in that the Kerbos and SPKM sections call for large-binary-values, but it was done incompletely. Regards, Pat -----Original Message----- From: Bill Studenmund [mailto:wrstuden@wasabisystems.com] Sent: Tuesday, July 02, 2002 12:03 PM To: THALER,PAT (A-Roseville,ex1) Cc: LEMAY,KEVIN (A-Roseville,ex1); Julian_Satran@il.ibm.com; ips@ece.cmu.edu Subject: RE: iSCSI: Decimal encoding - why 64 bits ? On Tue, 2 Jul 2002, THALER,PAT (A-Roseville,ex1) wrote: > Bill, > > The decimal encoding is not just for numbers. It is also allowed for > binary-values. Both CHAP and SRP exchange items that are identified as > binary-values. In general these will be longer than 64 bits, but in > cases where they are 64 bits or less the decimal encoding is currently > allowed so we would have to support it. I thought we had a big discussion about this, and we decided that decimal was only used for numbers, hex for numbers and binary, and base64 only for binary items. ?? Doh! I just looked in -14, and the text doesn't reflect that understanding. Hmmm. > The issue is that currently decimal encoding is allowed for > binary-values and numbers less than 64 bits. There is little need for > it over 32 bits. We have two other entirely adequate representations > for those numbers. Why have something in there that causes extra code > for no benefit? All I can say is I thought it was removed. :-| Take care, Bill From owner-ips@ece.cmu.edu Tue Jul 2 15:35:38 2002 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA10890 for ; Tue, 2 Jul 2002 15:35:34 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id g62IsHL20819 for ips-outgoing; Tue, 2 Jul 2002 14:54:17 -0400 (EDT) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from msgbas2.cos.agilent.com (msgbas2x.cos.agilent.com [192.25.240.37]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id g62IsFX20810 for ; Tue, 2 Jul 2002 14:54:15 -0400 (EDT) Received: from msgrel1t.cos.agilent.com (msgrel1t.cos.agilent.com [130.29.152.157]) by msgbas2.cos.agilent.com (Postfix) with ESMTP id 743051ED3; Tue, 2 Jul 2002 12:54:14 -0600 (MDT) Received: from axcsbh1.cos.agilent.com (axcsbh1.cos.agilent.com [130.29.152.143]) by msgrel1t.cos.agilent.com (Postfix) with SMTP id A75F8823; Tue, 2 Jul 2002 12:54:09 -0600 (MDT) Received: from 130.29.152.143 by axcsbh1.cos.agilent.com (InterScan E-Mail VirusWall NT); Tue, 02 Jul 2002 12:53:40 -0600 Received: by axcsbh1.cos.agilent.com with Internet Mail Service (5.5.2653.19) id ; Tue, 2 Jul 2002 12:53:29 -0600 Message-ID: <1BEBA5E8600DD4119A50009027AF54A00CB26D18@axcs04.cos.agilent.com> From: "THALER,PAT (A-Roseville,ex1)" To: Bill Studenmund , "LEMAY,KEVIN (A-Roseville,ex1)" Cc: Julian_Satran@il.ibm.com, ips@ece.cmu.edu Subject: RE: iSCSI: Decimal encoding - why 64 bits ? Date: Tue, 2 Jul 2002 12:53:25 -0600 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-ips@ece.cmu.edu Precedence: bulk Bill, The decimal encoding is not just for numbers. It is also allowed for binary-values. Both CHAP and SRP exchange items that are identified as binary-values. In general these will be longer than 64 bits, but in cases where they are 64 bits or less the decimal encoding is currently allowed so we would have to support it. The issue is that currently decimal encoding is allowed for binary-values and numbers less than 64 bits. There is little need for it over 32 bits. We have two other entirely adequate representations for those numbers. Why have something in there that causes extra code for no benefit? Pat -----Original Message----- From: Bill Studenmund [mailto:wrstuden@wasabisystems.com] Sent: Tuesday, July 02, 2002 9:47 AM To: kevin_lemay@agilent.com Cc: Julian_Satran@il.ibm.com; ips@ece.cmu.edu Subject: RE: iSCSI: Decimal encoding - why 64 bits ? On Tue, 2 Jul 2002 kevin_lemay@agilent.com wrote: > I wouldn't say no difficulty. Windows based machines do not allow 64 > bit numbers as function parameters. My two vxWorks systems do not > support 64 bit numbers. I haven't checked the gnu compiler for my > linux Intel box. Unless you have a very broken Linux install, gcc will handle 64 bit numbers as type 'long long'. > Saying that it should be no problem doesn't just make it so... I think the reason that it shouldn't be a problem is that there are no numbers we're going to be passing around at the moment (i.e. this version of the draft) that need more than 32 bits. Thus you're fine with using 32 bit parameters (with the ability to detect overflows). > I am sure that other people will hit the same wall and this will cause > interoperability problems down the road. I'm not sure. But I think that if we get parameters which need 64 bits, then we will probably be bumping the protocol version, and current devices will indicate they don't support it. > Kevin > > -----Original Message----- > From: Julian Satran [mailto:Julian_Satran@il.ibm.com] > Sent: Monday, July 01, 2002 10:31 PM > To: LEMAY,KEVIN (A-Roseville,ex1) > Cc: ips@ece.cmu.edu; 'Satran, Julian'; owner-ips@ece.cmu.edu > Subject: Re: iSCSI: Decimal encoding - why 64 bits ? > > > > There was a long debate and 64 bit was deemed a decent compromise. > As for 32bit machines - you should have no difficulty in doing that on a 32bit machine (or even a 16 bit machine). > > Julo > > > > "LEMAY,KEVIN (A-Roseville,ex1)" > Sent by: owner-ips@ece.cmu.edu > > > 07/02/2002 12:01 AM > Please respond to "LEMAY,KEVIN (A-Roseville,ex1)" > > > > To: "'Satran, Julian'" , ips@ece.cmu.edu > cc: > Subject: iSCSI: Decimal encoding - why 64 bits ? > > > > > Julian, > > Why does decimal encoding support 64 bit values instead of only 32 bits? > > For implementations running on 32bit machines, supporting 64 bit decimal encoding will not be fun. Sure, it can be done in software, but is it really needed? > > All of the operational parameters fit in 32 bits. The only possible use for 64 bits is in authentication or vendor specific keys. Hex and base64 encoding make more sense for these cases for the long authentication keys and hex and base64 encoders/decoders must be provided by a compliant implementation anyway. > > Could we restrict the decimal encoding to 32 bits and make binary values use only hex and base 64? > > Thanks, > > Kevin > > > From owner-ips@ece.cmu.edu Tue Jul 2 15:36:31 2002 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA10975 for ; Tue, 2 Jul 2002 15:36:30 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id g62JM1022316 for ips-outgoing; Tue, 2 Jul 2002 15:22:01 -0400 (EDT) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from lion.ninthwonder.com (lion.ninthwonder.com [151.199.66.147]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id g62JLxX22312 for ; Tue, 2 Jul 2002 15:21:59 -0400 (EDT) Received: by lion.ninthwonder.com (Postfix, from userid 1021) id 085B130706; Tue, 2 Jul 2002 15:21:59 -0400 (EDT) Date: Tue, 2 Jul 2002 12:18:58 -0700 (PDT) From: Bill Studenmund X-X-Sender: To: "THALER,PAT (A-Roseville,ex1)" Cc: "LEMAY,KEVIN (A-Roseville,ex1)" , , Subject: RE: iSCSI: Decimal encoding - why 64 bits ? In-Reply-To: <1BEBA5E8600DD4119A50009027AF54A00CB26D28@axcs04.cos.agilent.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ips@ece.cmu.edu Precedence: bulk On Tue, 2 Jul 2002, THALER,PAT (A-Roseville,ex1) wrote: > Bill, > > I also thought that the result of the reflector discussion was > agreement that decimal would only be used for numbers and not be used > for strings that are sometimes longer than the 64 bit limit like CHAP > and SRP strings. That seems to be partially implemented in that the > Kerbos and SPKM sections call for large-binary-values, but it was done > incompletely. I looked at the list archive, and http://www.pdl.cmu.edu/mailinglists/ips/mail/msg10319.html is a comment by David indicating he saw concensus for not using base64 for numbers. I didn't find the thread part where I thought we agreed that we would use decimal only for numbers (and not for small binary strings). ?? Take care, Bill From owner-ips@ece.cmu.edu Tue Jul 2 15:36:49 2002 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA11018 for ; Tue, 2 Jul 2002 15:36:49 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id g62JNR622387 for ips-outgoing; Tue, 2 Jul 2002 15:23:27 -0400 (EDT) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from d12lmsgate-2.de.ibm.com (d12lmsgate-2.de.ibm.com [195.212.91.200]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id g62JNPX22383 for ; Tue, 2 Jul 2002 15:23:26 -0400 (EDT) Received: from d12relay01.de.ibm.com (d12relay01.de.ibm.com [9.165.215.22]) by d12lmsgate-2.de.ibm.com (8.12.3/8.12.3) with ESMTP id g62JNJu9006260 for ; Tue, 2 Jul 2002 21:23:19 +0200 Received: from d10hubm1.telaviv.ibm.com (d10ml001.telaviv.ibm.com [9.148.216.55]) by d12relay01.de.ibm.com (8.11.1m3/NCO/VER6.1) with ESMTP id g62JNI8134270 for ; Tue, 2 Jul 2002 21:23:18 +0200 To: ips@ece.cmu.edu MIME-Version: 1.0 Subject: RE: iSCSI: Decimal encoding - why 64 bits ? X-Mailer: Lotus Notes Release 5.0.9 November 16, 2001 From: "Julian Satran" Message-ID: Date: Tue, 2 Jul 2002 22:23:16 +0300 X-MIMETrack: Serialize by Router on D10ML001/10/M/IBM(Release 5.0.9a |January 7, 2002) at 02/07/2002 22:23:18, Serialize complete at 02/07/2002 22:23:18 Content-Type: multipart/alternative; boundary="=_alternative 006A45F3C2256BEA_=" Sender: owner-ips@ece.cmu.edu Precedence: bulk This is a multipart message in MIME format. --=_alternative 006A45F3C2256BEA_= Content-Type: text/plain; charset="us-ascii" It was never supposed to be removed. Many values are passed around as decimal. We can't make any progress if we keep hitting the same things again-and-again after a decent consensus has been reached. And none of you has brought an argument that was not heard and dismissed before. Remember we moved from unlimited length decimal to 64 bit to alleviate implementer fears. Julo Bill Studenmund 07/02/2002 10:03 PM Please respond to Bill Studenmund To: "THALER,PAT (A-Roseville,ex1)" cc: "LEMAY,KEVIN (A-Roseville,ex1)" , Julian Satran/Haifa/IBM@IBMIL, Subject: RE: iSCSI: Decimal encoding - why 64 bits ? On Tue, 2 Jul 2002, THALER,PAT (A-Roseville,ex1) wrote: > Bill, > > The decimal encoding is not just for numbers. It is also allowed for > binary-values. Both CHAP and SRP exchange items that are identified as > binary-values. In general these will be longer than 64 bits, but in > cases where they are 64 bits or less the decimal encoding is currently > allowed so we would have to support it. I thought we had a big discussion about this, and we decided that decimal was only used for numbers, hex for numbers and binary, and base64 only for binary items. ?? Doh! I just looked in -14, and the text doesn't reflect that understanding. Hmmm. > The issue is that currently decimal encoding is allowed for > binary-values and numbers less than 64 bits. There is little need for > it over 32 bits. We have two other entirely adequate representations > for those numbers. Why have something in there that causes extra code > for no benefit? All I can say is I thought it was removed. :-| Take care, Bill --=_alternative 006A45F3C2256BEA_= Content-Type: text/html; charset="us-ascii"
It was never supposed to be removed. Many values are passed around as decimal.
We can't make any progress if we keep hitting the same things again-and-again after a decent consensus has been reached.
And none of you has brought an argument that was not heard and dismissed before.

Remember we moved from unlimited length decimal to 64 bit to alleviate implementer fears.

Julo


Bill Studenmund <wrstuden@wasabisystems.com>

07/02/2002 10:03 PM
Please respond to Bill Studenmund

       
        To:        "THALER,PAT (A-Roseville,ex1)" <pat_thaler@agilent.com>
        cc:        "LEMAY,KEVIN (A-Roseville,ex1)" <kevin_lemay@agilent.com>, Julian Satran/Haifa/IBM@IBMIL, <ips@ece.cmu.edu>
        Subject:        RE: iSCSI: Decimal encoding - why 64 bits ?

       


On Tue, 2 Jul 2002, THALER,PAT (A-Roseville,ex1) wrote:

> Bill,
>

> The decimal encoding is not just for numbers. It is also allowed for
> binary-values. Both CHAP and SRP exchange items that are identified as
> binary-values. In general these will be longer than 64 bits, but in
> cases where they are 64 bits or less the decimal encoding is currently
> allowed so we would have to support it.

I thought we had a big discussion about this, and we decided that decimal
was only used for numbers, hex for numbers and binary, and base64 only for
binary items. ??

Doh! I just looked in -14, and the text doesn't reflect that
understanding. Hmmm.

> The issue is that currently decimal encoding is allowed for
> binary-values and numbers less than 64 bits. There is little need for
> it over 32 bits. We have two other entirely adequate representations
> for those numbers. Why have something in there that causes extra code
> for no benefit?

All I can say is I thought it was removed. :-|

Take care,

Bill

--=_alternative 006A45F3C2256BEA_=-- From owner-ips@ece.cmu.edu Tue Jul 2 15:37:53 2002 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA11093 for ; Tue, 2 Jul 2002 15:37:52 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id g62J39o21255 for ips-outgoing; Tue, 2 Jul 2002 15:03:09 -0400 (EDT) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from msgbas1.cos.agilent.com (msgbas1x.cos.agilent.com [192.25.240.36]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id g62J37X21250 for ; Tue, 2 Jul 2002 15:03:07 -0400 (EDT) Received: from msgrel1t.cos.agilent.com (msgrel1t.cos.agilent.com [130.29.152.157]) by msgbas1.cos.agilent.com (Postfix) with ESMTP id DFF1BC6C2; Tue, 2 Jul 2002 13:03:05 -0600 (MDT) Received: from axcsbh6.cos.agilent.com (axcsbh6.cos.agilent.com [130.29.152.171]) by msgrel1t.cos.agilent.com (Postfix) with SMTP id B0E4357A; Tue, 2 Jul 2002 13:03:04 -0600 (MDT) Received: from 130.29.152.171 by axcsbh6.cos.agilent.com (InterScan E-Mail VirusWall NT); Tue, 02 Jul 2002 13:03:04 -0600 Received: by axcsbh6.cos.agilent.com with Internet Mail Service (5.5.2653.19) id ; Tue, 2 Jul 2002 13:03:03 -0600 Message-ID: <1BEBA5E8600DD4119A50009027AF54A00CB26D1A@axcs04.cos.agilent.com> From: pat_thaler@agilent.com To: Julian_Satran@il.ibm.com, pat_thaler@agilent.com Cc: ips@ece.cmu.edu Subject: RE: iSCSI: Login negotiation space Date: Tue, 2 Jul 2002 13:02:59 -0600 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/mixed; boundary="----=_NextPartTM-000-463ecfe8-99ac-4a48-a069-c198f2220008" Sender: owner-ips@ece.cmu.edu Precedence: bulk This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------=_NextPartTM-000-463ecfe8-99ac-4a48-a069-c198f2220008 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C221FB.14E030E0" ------_=_NextPart_001_01C221FB.14E030E0 Content-Type: text/plain; charset="ISO-8859-1" Julian, A factor of 10 is way overkill. It isn't just 16 k bytes of extra memory. It is n * 16k where n is the number of simultaneous logins the implementation supports - it adds up. The system vendors we work with want to use the memory to do useful work and demand that driver sizes be kept small -- they want the memory available to do "real" work. If 2k doesn't leave enough headroom, then we could live with somewhat more like 4k. If future features added to iSCSI require more space, the drivers that support that can allocate more memory. It is an internal parameter that can be changed when the need arises. There is no future interoperability need to make the buffer oversized in current implementations. Regards, Pat -----Original Message----- From: Julian Satran [mailto:Julian_Satran@il.ibm.com] Sent: Tuesday, July 02, 2002 12:10 AM To: pat_thaler@agilent.com Cc: ips@ece.cmu.edu Subject: RE: iSCSI: Login negotiation space Pat, A factor of 10 over what is needed today is what I would call a conservative design. Limiting the support to 2k would be extremely unwise. And 16 is a tiny amount of memory - of no concern to software implementation and to most hardware implementations. Julo pat_thaler@agilent.com 07/02/2002 01:56 AM Please respond to pat_thaler To: Julian Satran/Haifa/IBM@IBMIL cc: ips@ece.cmu.edu Subject: RE: iSCSI: Login negotiation space Julian, 4.1 contains a requirement that initiators and targets support receiving at least 16384 bytes of key=value data (when not supporting very long authentication items). This is overkill and is making drivers larger than they need to be. My calculations are that Security negotiation using the CHAP method (including the Any-stage keys) takes less than 1600 bytes. Operational negotiation requires 1276 bytes (also including the Any-stage keys). All the operational plus security keys are 1911 bytes. Therefore an implementation could hold all the necessary keys in 2 Kbytes. And, the implementation doesn't need to keep the security keys after the security negotiation is done so it could clear some of that out to make room for future keys or vendor specific keys. 16 K bytes is about 10 times the necessary storage in that case. The number of negotiation bytes that a device is required to support should be reduced substantially - preferably to 2048 bytes. Regards, Pat The numbers: 43 AuthMethod CHAP keys 264 Name (no defined size limit - using 255) 11 Algorithm 11 Identifier 264 Challenge 42 Response (for MD5) _____ 635 Chap negotiation length 892 Any-stage keys ---- 1527 Operational negotiation keys 24 HeaderDigest 24 DataDigest 49 MaxConnections 270 TargetName* or InitiatorName* 271 TargetAlias* or InitiatorAlias* 273 TargetAddress* 55 TargetPortalGroupTag* 15 InitialR2T 19 BidiInitialR2T 18 ImmediateData 34 MaxRecvDataSegmentLength 24 MaxBurstLength 26 FirstBurstLength 24 DefaultTime2Wait 26 DefaultTime2Retain 25 MaxOutstandingR2T 18 DataPDUInOrder 24 DataSequenceInOrder 24 ErrorRecoveryLevel 23 SessionType* ------ 892 Any-stage keys 384 Not Any-stage ------ 1276 Operational keys ------_=_NextPart_001_01C221FB.14E030E0 Content-Type: text/html; charset="ISO-8859-1"
Julian,
 
A factor of 10 is way overkill. It isn't just 16 k bytes of extra memory. It is n * 16k where n is the number of simultaneous logins the implementation supports - it adds up. The system vendors we work with want to use the memory to do useful work and demand that driver sizes be kept small -- they want the memory available to do "real" work.
 
If 2k doesn't leave enough headroom, then we could live with somewhat more like 4k.
 
If future features added to iSCSI require more space, the drivers that support that can allocate more memory. It is an internal parameter that can be changed when the need arises. There is no future interoperability need to make the buffer oversized in current implementations.
 
Regards,
Pat
 
-----Original Message-----
From: Julian Satran [mailto:Julian_Satran@il.ibm.com]
Sent: Tuesday, July 02, 2002 12:10 AM
To: pat_thaler@agilent.com
Cc: ips@ece.cmu.edu
Subject: RE: iSCSI: Login negotiation space


Pat,

A factor of 10 over what is needed today is what I would call a conservative design.
Limiting the support to 2k would be extremely unwise.
And 16 is a tiny amount of memory - of no concern to software implementation and to most hardware implementations.

Julo



pat_thaler@agilent.com

07/02/2002 01:56 AM
Please respond to pat_thaler

       
        To:        Julian Satran/Haifa/IBM@IBMIL
        cc:        ips@ece.cmu.edu
        Subject:        RE: iSCSI: Login negotiation space

       


Julian,

4.1 contains a requirement that initiators and targets support receiving at least 16384 bytes of key=value data (when not supporting very long authentication items). This is overkill and is making drivers larger than they need to be.

My calculations are that Security negotiation using the CHAP method (including the Any-stage keys) takes less than 1600 bytes. Operational negotiation requires 1276 bytes (also including the Any-stage keys). All the operational plus security keys are 1911 bytes.

Therefore an implementation could hold all the necessary keys in 2 Kbytes. And, the implementation doesn't need to keep the security keys after the security negotiation is done so it could clear some of that out to make room for future keys or vendor specific keys. 16 K bytes is about 10 times the necessary storage in that case.

The number of negotiation bytes that a device is required to support should be reduced substantially - preferably to 2048 bytes.

Regards,
Pat


The numbers:

 43                                  AuthMethod
          CHAP keys
264                                  Name (no defined size limit - using 255)
 11                                  Algorithm
 11                                  Identifier
264                                  Challenge
 42                                  Response (for MD5)
_____
635 Chap negotiation length
892 Any-stage keys
----
1527

Operational negotiation keys
 24                                  HeaderDigest
 24        DataDigest
 49        MaxConnections
270                                  TargetName* or InitiatorName*
271                                  TargetAlias* or InitiatorAlias*
273        TargetAddress*
 55                                  TargetPortalGroupTag*
 15                                  InitialR2T
 19                                  BidiInitialR2T
 18                                  ImmediateData
 34                                  MaxRecvDataSegmentLength
 24                                  MaxBurstLength
 26                                  FirstBurstLength
 24                                  DefaultTime2Wait
 26                                  DefaultTime2Retain
 25                                  MaxOutstandingR2T
 18                                  DataPDUInOrder
 24                                  DataSequenceInOrder
 24                                  ErrorRecoveryLevel
 23                                  SessionType*
------
892 Any-stage keys
384 Not Any-stage
------
1276 Operational keys







------_=_NextPart_001_01C221FB.14E030E0-- ------=_NextPartTM-000-463ecfe8-99ac-4a48-a069-c198f2220008-- From owner-ips@ece.cmu.edu Tue Jul 2 16:14:38 2002 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA12985 for ; Tue, 2 Jul 2002 16:14:38 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id g62JcLW23286 for ips-outgoing; Tue, 2 Jul 2002 15:38:21 -0400 (EDT) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from mxic2.corp.emc.com (mxic2.isus.emc.com [128.221.31.40]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id g62JcKX23282 for ; Tue, 2 Jul 2002 15:38:20 -0400 (EDT) Received: by mxic2.corp.emc.com with Internet Mail Service (5.5.2653.19) id <31X6HVS7>; Tue, 2 Jul 2002 15:38:14 -0400 Message-ID: <277DD60FB639D511AC0400B0D068B71E0564C017@CORPMX14> From: Black_David@emc.com To: Julian_Satran@il.ibm.com, ips@ece.cmu.edu Subject: RE: iSCSI: Decimal encoding - why 64 bits ? Date: Tue, 2 Jul 2002 15:36:17 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C221FF.BC39D900" Sender: owner-ips@ece.cmu.edu Precedence: bulk This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_001_01C221FF.BC39D900 Content-Type: text/plain; charset="iso-8859-1" Easy does it. First of all - if someone will go find the mail thread that discussed this (I also recall a discussion of numbers vs. binary items) I'll take a look at it and make a WG chair determination of what was or was not concluded. Kevin's comment that decimal ought to be limited to 32 bits is still valid at this point - a reference to prior discussions without specifics isn't enough to dismiss it. My rough recollection of the discussion partially matches Julian's - we reduced the required size to 64 bits from unlimited on the assumption that platforms could cope with this ... and now Kevin has raised the issue that two platforms he considers important don't cope well with 64 bit arithmetic. I don't recall discussion of whether to limit to 32 bits vs. 64 bits. For now, this issue is open. Thanks, --David -----Original Message----- From: Julian Satran [mailto:Julian_Satran@il.ibm.com] Sent: Tuesday, July 02, 2002 3:23 PM To: ips@ece.cmu.edu Subject: RE: iSCSI: Decimal encoding - why 64 bits ? It was never supposed to be removed. Many values are passed around as decimal. We can't make any progress if we keep hitting the same things again-and-again after a decent consensus has been reached. And none of you has brought an argument that was not heard and dismissed before. Remember we moved from unlimited length decimal to 64 bit to alleviate implementer fears. Julo Bill Studenmund 07/02/2002 10:03 PM Please respond to Bill Studenmund To: "THALER,PAT (A-Roseville,ex1)" cc: "LEMAY,KEVIN (A-Roseville,ex1)" , Julian Satran/Haifa/IBM@IBMIL, Subject: RE: iSCSI: Decimal encoding - why 64 bits ? On Tue, 2 Jul 2002, THALER,PAT (A-Roseville,ex1) wrote: > Bill, > > The decimal encoding is not just for numbers. It is also allowed for > binary-values. Both CHAP and SRP exchange items that are identified as > binary-values. In general these will be longer than 64 bits, but in > cases where they are 64 bits or less the decimal encoding is currently > allowed so we would have to support it. I thought we had a big discussion about this, and we decided that decimal was only used for numbers, hex for numbers and binary, and base64 only for binary items. ?? Doh! I just looked in -14, and the text doesn't reflect that understanding. Hmmm. > The issue is that currently decimal encoding is allowed for > binary-values and numbers less than 64 bits. There is little need for > it over 32 bits. We have two other entirely adequate representations > for those numbers. Why have something in there that causes extra code > for no benefit? All I can say is I thought it was removed. :-| Take care, Bill ------_=_NextPart_001_01C221FF.BC39D900 Content-Type: text/html; charset="iso-8859-1"
Easy does it.  First of all - if someone will go find the mail
thread that discussed this (I also recall a discussion of
numbers vs. binary items) I'll take a look at it and make a
WG chair determination of what was or was not concluded.
 
Kevin's comment that decimal ought to be limited to 32 bits
is still valid at this point - a reference to prior discussions
without specifics isn't enough to dismiss it.  My rough
recollection of the discussion partially matches Julian's -
we reduced the required size to 64 bits from unlimited on
the assumption that platforms could cope with this ... and
now Kevin has raised the issue that two platforms he
considers important don't cope well with 64 bit arithmetic.
I don't recall discussion of whether to limit to 32 bits vs.
64 bits.
 
For now, this issue is open.
 
Thanks,
--David
-----Original Message-----
From: Julian Satran [mailto:Julian_Satran@il.ibm.com]
Sent: Tuesday, July 02, 2002 3:23 PM
To: ips@ece.cmu.edu
Subject: RE: iSCSI: Decimal encoding - why 64 bits ?


It was never supposed to be removed. Many values are passed around as decimal.
We can't make any progress if we keep hitting the same things again-and-again after a decent consensus has been reached.
And none of you has brought an argument that was not heard and dismissed before.

Remember we moved from unlimited length decimal to 64 bit to alleviate implementer fears.

Julo


Bill Studenmund <wrstuden@wasabisystems.com>

07/02/2002 10:03 PM
Please respond to Bill Studenmund

       
        To:        "THALER,PAT (A-Roseville,ex1)" <pat_thaler@agilent.com>
        cc:        "LEMAY,KEVIN (A-Roseville,ex1)" <kevin_lemay@agilent.com>, Julian Satran/Haifa/IBM@IBMIL, <ips@ece.cmu.edu>
        Subject:        RE: iSCSI: Decimal encoding - why 64 bits ?

       


On Tue, 2 Jul 2002, THALER,PAT (A-Roseville,ex1) wrote:

> Bill,
>

> The decimal encoding is not just for numbers. It is also allowed for
> binary-values. Both CHAP and SRP exchange items that are identified as
> binary-values. In general these will be longer than 64 bits, but in
> cases where they are 64 bits or less the decimal encoding is currently
> allowed so we would have to support it.

I thought we had a big discussion about this, and we decided that decimal
was only used for numbers, hex for numbers and binary, and base64 only for
binary items. ??

Doh! I just looked in -14, and the text doesn't reflect that
understanding. Hmmm.

> The issue is that currently decimal encoding is allowed for
> binary-values and numbers less than 64 bits. There is little need for
> it over 32 bits. We have two other entirely adequate representations
> for those numbers. Why have something in there that causes extra code
> for no benefit?

All I can say is I thought it was removed. :-|

Take care,

Bill



------_=_NextPart_001_01C221FF.BC39D900-- From owner-ips@ece.cmu.edu Tue Jul 2 16:15:17 2002 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA13013 for ; Tue, 2 Jul 2002 16:15:12 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id g62Ja5E23111 for ips-outgoing; Tue, 2 Jul 2002 15:36:05 -0400 (EDT) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from d12lmsgate.de.ibm.com (d12lmsgate.de.ibm.com [195.212.91.199]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id g62Ja3X23103 for ; Tue, 2 Jul 2002 15:36:03 -0400 (EDT) Received: from d12relay02.de.ibm.com (d12relay02.de.ibm.com [9.165.215.23]) by d12lmsgate.de.ibm.com (8.12.3/8.12.3) with ESMTP id g62JZvK2020244 for ; Tue, 2 Jul 2002 21:35:57 +0200 Received: from d10hubm1.telaviv.ibm.com (d10ml001.telaviv.ibm.com [9.148.216.55]) by d12relay02.de.ibm.com (8.11.1m3/NCO/VER6.1) with ESMTP id g62JZuj80026 for ; Tue, 2 Jul 2002 21:35:56 +0200 To: ips@ece.cmu.edu MIME-Version: 1.0 Subject: RE: iSCSI: Decimal encoding - why 64 bits ? X-Mailer: Lotus Notes Release 5.0.9 November 16, 2001 From: "Julian Satran" Message-ID: Date: Tue, 2 Jul 2002 22:35:54 +0300 X-MIMETrack: Serialize by Router on D10ML001/10/M/IBM(Release 5.0.9a |January 7, 2002) at 02/07/2002 22:35:56, Serialize complete at 02/07/2002 22:35:56 Content-Type: multipart/alternative; boundary="=_alternative 006AFC57C2256BEA_=" Sender: owner-ips@ece.cmu.edu Precedence: bulk This is a multipart message in MIME format. --=_alternative 006AFC57C2256BEA_= Content-Type: text/plain; charset="us-ascii" There was NO such consensus. Julo Bill Studenmund 07/02/2002 10:18 PM Please respond to Bill Studenmund To: "THALER,PAT (A-Roseville,ex1)" cc: "LEMAY,KEVIN (A-Roseville,ex1)" , Julian Satran/Haifa/IBM@IBMIL, Subject: RE: iSCSI: Decimal encoding - why 64 bits ? On Tue, 2 Jul 2002, THALER,PAT (A-Roseville,ex1) wrote: > Bill, > > I also thought that the result of the reflector discussion was > agreement that decimal would only be used for numbers and not be used > for strings that are sometimes longer than the 64 bit limit like CHAP > and SRP strings. That seems to be partially implemented in that the > Kerbos and SPKM sections call for large-binary-values, but it was done > incompletely. I looked at the list archive, and http://www.pdl.cmu.edu/mailinglists/ips/mail/msg10319.html is a comment by David indicating he saw concensus for not using base64 for numbers. I didn't find the thread part where I thought we agreed that we would use decimal only for numbers (and not for small binary strings). ?? Take care, Bill --=_alternative 006AFC57C2256BEA_= Content-Type: text/html; charset="us-ascii"
There was NO such consensus.  Julo


Bill Studenmund <wrstuden@wasabisystems.com>

07/02/2002 10:18 PM
Please respond to Bill Studenmund

       
        To:        "THALER,PAT (A-Roseville,ex1)" <pat_thaler@agilent.com>
        cc:        "LEMAY,KEVIN (A-Roseville,ex1)" <kevin_lemay@agilent.com>, Julian Satran/Haifa/IBM@IBMIL, <ips@ece.cmu.edu>
        Subject:        RE: iSCSI: Decimal encoding - why 64 bits ?

       


On Tue, 2 Jul 2002, THALER,PAT (A-Roseville,ex1) wrote:

> Bill,
>
> I also thought that the result of the reflector discussion was
> agreement that decimal would only be used for numbers and not be used
> for strings that are sometimes longer than the 64 bit limit like CHAP
> and SRP strings. That seems to be partially implemented in that the
> Kerbos and SPKM sections call for large-binary-values, but it was done
> incompletely.

I looked at the list archive, and
http://www.pdl.cmu.edu/mailinglists/ips/mail/msg10319.html
is a comment by David indicating he saw concensus for not using base64 for
numbers.

I didn't find the thread part where I thought we agreed that we would
use decimal only for numbers (and not for small binary strings).

??

Take care,

Bill

--=_alternative 006AFC57C2256BEA_=-- From owner-ips@ece.cmu.edu Tue Jul 2 16:15:52 2002 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA13039 for ; Tue, 2 Jul 2002 16:15:52 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id g62Ja5b23113 for ips-outgoing; Tue, 2 Jul 2002 15:36:05 -0400 (EDT) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from d12lmsgate.de.ibm.com (d12lmsgate.de.ibm.com [195.212.91.199]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id g62Ja2X23101 for ; Tue, 2 Jul 2002 15:36:02 -0400 (EDT) Received: from d12relay02.de.ibm.com (d12relay02.de.ibm.com [9.165.215.23]) by d12lmsgate.de.ibm.com (8.12.3/8.12.3) with ESMTP id g62JZuK2020240 for ; Tue, 2 Jul 2002 21:35:56 +0200 Received: from d10hubm1.telaviv.ibm.com (d10ml001.telaviv.ibm.com [9.148.216.55]) by d12relay02.de.ibm.com (8.11.1m3/NCO/VER6.1) with ESMTP id g62JZtj80024 for ; Tue, 2 Jul 2002 21:35:55 +0200 To: ips@ece.cmu.edu MIME-Version: 1.0 Subject: RE: iSCSI: Login negotiation space X-Mailer: Lotus Notes Release 5.0.9 November 16, 2001 From: "Julian Satran" Message-ID: Date: Tue, 2 Jul 2002 22:35:51 +0300 X-MIMETrack: Serialize by Router on D10ML001/10/M/IBM(Release 5.0.9a |January 7, 2002) at 02/07/2002 22:35:55, Serialize complete at 02/07/2002 22:35:55 Content-Type: multipart/alternative; boundary="=_alternative 006ACF29C2256BEA_=" Sender: owner-ips@ece.cmu.edu Precedence: bulk This is a multipart message in MIME format. --=_alternative 006ACF29C2256BEA_= Content-Type: text/plain; charset="us-ascii" Pat, 4k is absurd. We have the security guys asking for 64k certificates! And the PDUlength default is 8k! Besides you can control the total memory consumed by throttling login as soon as you have unprocessed keys exceeding the mount of memory you want to keep aside (you control the login progress by delaying requests/responses). Julo pat_thaler@agilent.com 07/02/2002 10:02 PM Please respond to pat_thaler To: Julian Satran/Haifa/IBM@IBMIL, pat_thaler@agilent.com cc: ips@ece.cmu.edu Subject: RE: iSCSI: Login negotiation space Julian, A factor of 10 is way overkill. It isn't just 16 k bytes of extra memory. It is n * 16k where n is the number of simultaneous logins the implementation supports - it adds up. The system vendors we work with want to use the memory to do useful work and demand that driver sizes be kept small -- they want the memory available to do "real" work. If 2k doesn't leave enough headroom, then we could live with somewhat more like 4k. If future features added to iSCSI require more space, the drivers that support that can allocate more memory. It is an internal parameter that can be changed when the need arises. There is no future interoperability need to make the buffer oversized in current implementations. Regards, Pat -----Original Message----- From: Julian Satran [mailto:Julian_Satran@il.ibm.com] Sent: Tuesday, July 02, 2002 12:10 AM To: pat_thaler@agilent.com Cc: ips@ece.cmu.edu Subject: RE: iSCSI: Login negotiation space Pat, A factor of 10 over what is needed today is what I would call a conservative design. Limiting the support to 2k would be extremely unwise. And 16 is a tiny amount of memory - of no concern to software implementation and to most hardware implementations. Julo pat_thaler@agilent.com 07/02/2002 01:56 AM Please respond to pat_thaler To: Julian Satran/Haifa/IBM@IBMIL cc: ips@ece.cmu.edu Subject: RE: iSCSI: Login negotiation space Julian, 4.1 contains a requirement that initiators and targets support receiving at least 16384 bytes of key=value data (when not supporting very long authentication items). This is overkill and is making drivers larger than they need to be. My calculations are that Security negotiation using the CHAP method (including the Any-stage keys) takes less than 1600 bytes. Operational negotiation requires 1276 bytes (also including the Any-stage keys). All the operational plus security keys are 1911 bytes. Therefore an implementation could hold all the necessary keys in 2 Kbytes. And, the implementation doesn't need to keep the security keys after the security negotiation is done so it could clear some of that out to make room for future keys or vendor specific keys. 16 K bytes is about 10 times the necessary storage in that case. The number of negotiation bytes that a device is required to support should be reduced substantially - preferably to 2048 bytes. Regards, Pat The numbers: 43 AuthMethod CHAP keys 264 Name (no defined size limit - using 255) 11 Algorithm 11 Identifier 264 Challenge 42 Response (for MD5) _____ 635 Chap negotiation length 892 Any-stage keys ---- 1527 Operational negotiation keys 24 HeaderDigest 24 DataDigest 49 MaxConnections 270 TargetName* or InitiatorName* 271 TargetAlias* or InitiatorAlias* 273 TargetAddress* 55 TargetPortalGroupTag* 15 InitialR2T 19 BidiInitialR2T 18 ImmediateData 34 MaxRecvDataSegmentLength 24 MaxBurstLength 26 FirstBurstLength 24 DefaultTime2Wait 26 DefaultTime2Retain 25 MaxOutstandingR2T 18 DataPDUInOrder 24 DataSequenceInOrder 24 ErrorRecoveryLevel 23 SessionType* ------ 892 Any-stage keys 384 Not Any-stage ------ 1276 Operational keys --=_alternative 006ACF29C2256BEA_= Content-Type: text/html; charset="us-ascii"
Pat,

4k is absurd. We have the security guys asking for 64k certificates!
And the PDUlength default is 8k!
Besides you can control the total memory consumed by throttling login as soon as you have unprocessed keys exceeding the mount of memory you want to keep aside (you control the login progress by delaying requests/responses).


Julo


pat_thaler@agilent.com

07/02/2002 10:02 PM
Please respond to pat_thaler

       
        To:        Julian Satran/Haifa/IBM@IBMIL, pat_thaler@agilent.com
        cc:        ips@ece.cmu.edu
        Subject:        RE: iSCSI: Login negotiation space

       


Julian,
 
A factor of 10 is way overkill. It isn't just 16 k bytes of extra memory. It is n * 16k where n is the number of simultaneous logins the implementation supports - it adds up. The system vendors we work with want to use the memory to do useful work and demand that driver sizes be kept small -- they want the memory available to do "real" work.
 
If 2k doesn't leave enough headroom, then we could live with somewhat more like 4k.
 
If future features added to iSCSI require more space, the drivers that support that can allocate more memory. It is an internal parameter that can be changed when the need arises. There is no future interoperability need to make the buffer oversized in current implementations.
 
Regards,
Pat
 
-----Original Message-----
From: Julian Satran [mailto:Julian_Satran@il.ibm.com]
Sent: Tuesday, July 02, 2002 12:10 AM
To: pat_thaler@agilent.com
Cc: ips@ece.cmu.edu
Subject: RE: iSCSI: Login negotiation space

Pat,

A factor of 10 over what is needed today is what I would call a conservative design.
Limiting the support to 2k would be extremely unwise.
And 16 is a tiny amount of memory - of no concern to software implementation and to most hardware implementations.

Julo


pat_thaler@agilent.com

07/02/2002 01:56 AM
Please respond to pat_thaler

       
       To:        Julian Satran/Haifa/IBM@IBMIL
       cc:        ips@ece.cmu.edu
       Subject:        RE: iSCSI: Login negotiation space

     



Julian,

4.1 contains a requirement that initiators and targets support receiving at least 16384 bytes of key=value data (when not supporting very long authentication items). This is overkill and is making drivers larger than they need to be.

My calculations are that Security negotiation using the CHAP method (including the Any-stage keys) takes less than 1600 bytes. Operational negotiation requires 1276 bytes (also including the Any-stage keys). All the operational plus security keys are 1911 bytes.

Therefore an implementation could hold all the necessary keys in 2 Kbytes. And, the implementation doesn't need to keep the security keys after the security negotiation is done so it could clear some of that out to make room for future keys or vendor specific keys. 16 K bytes is about 10 times the necessary storage in that case.

The number of negotiation bytes that a device is required to support should be reduced substantially - preferably to 2048 bytes.

Regards,
Pat


The numbers:

43                                  AuthMethod
         CHAP keys
264                                  Name (no defined size limit - using 255)
11                                  Algorithm
11                                  Identifier
264                                  Challenge
42                                  Response (for MD5)
_____
635 Chap negotiation length
892 Any-stage keys
----
1527

Operational negotiation keys
24                                  HeaderDigest
24        DataDigest
49        MaxConnections
270                                  TargetName* or InitiatorName*
271                                  TargetAlias* or InitiatorAlias*
273        TargetAddress*
55                                  TargetPortalGroupTag*
15                                  InitialR2T
19                                  BidiInitialR2T
18                                  ImmediateData
34                                  MaxRecvDataSegmentLength
24                                  MaxBurstLength
26                                  FirstBurstLength
24                                  DefaultTime2Wait
26                                  DefaultTime2Retain
25                                  MaxOutstandingR2T
18                                  DataPDUInOrder
24                                  DataSequenceInOrder
24                                  ErrorRecoveryLevel
23                                  SessionType*
------
892 Any-stage keys
384 Not Any-stage
------
1276 Operational keys

--=_alternative 006ACF29C2256BEA_=-- From owner-ips@ece.cmu.edu Tue Jul 2 16:16:46 2002 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA13073 for ; Tue, 2 Jul 2002 16:16:46 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id g62JtsT24387 for ips-outgoing; Tue, 2 Jul 2002 15:55:54 -0400 (EDT) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from cygnus.equallogic.com (cygnus.equallogic.com [65.170.102.10]) by ece.cmu.edu (8.11.0/8.10.2) with SMTP id g62JtlX24369 for ; Tue, 2 Jul 2002 15:55:47 -0400 (EDT) Received: from cygnus.equallogic.com (localhost.localdomain [127.0.0.1]) by cygnus.equallogic.com (8.11.6/8.11.6) with ESMTP id g62JtgC30745 for ; Tue, 2 Jul 2002 15:55:42 -0400 Received: from deneb.dev.equallogic.com (deneb.dev.equallogic.com [172.16.1.99]) by cygnus.equallogic.com (8.11.6/8.11.6) with ESMTP id g62JtfQ30730; Tue, 2 Jul 2002 15:55:41 -0400 Received: from pkoning.dev.equallogic.com.equallogic.com (localhost.localdomain [127.0.0.1]) by deneb.dev.equallogic.com (8.11.6/8.11.6) with SMTP id g62Jtei06992; Tue, 2 Jul 2002 15:55:40 -0400 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <15650.1340.546808.58491@pkoning.dev.equallogic.com> Date: Tue, 2 Jul 2002 15:55:40 -0400 From: Paul Koning To: wrstuden@wasabisystems.com Cc: pat_thaler@agilent.com, kevin_lemay@agilent.com, Julian_Satran@il.ibm.com, ips@ece.cmu.edu Subject: RE: iSCSI: Decimal encoding - why 64 bits ? References: <1BEBA5E8600DD4119A50009027AF54A00CB26D28@axcs04.cos.agilent.com> X-Mailer: VM 7.01 under 21.1 (patch 11) "Carlsbad Caverns" XEmacs Lucid Sender: owner-ips@ece.cmu.edu Precedence: bulk Content-Transfer-Encoding: 7bit >>>>> "Bill" == Bill Studenmund writes: Bill> On Tue, 2 Jul 2002, THALER,PAT (A-Roseville,ex1) wrote: >> Bill, >> >> I also thought that the result of the reflector discussion was >> agreement that decimal would only be used for numbers and not be >> used for strings that are sometimes longer than the 64 bit limit >> like CHAP and SRP strings. That seems to be partially implemented >> in that the Kerbos and SPKM sections call for large-binary-values, >> but it was done incompletely. Bill> I looked at the list archive, and Bill> http://www.pdl.cmu.edu/mailinglists/ips/mail/msg10319.html is a Bill> comment by David indicating he saw concensus for not using Bill> base64 for numbers. Bill> I didn't find the thread part where I thought we agreed that we Bill> would use decimal only for numbers (and not for small binary Bill> strings). That certainly is the conclusion I find most reasonable. The allowed encoding should be a property of the thing encoded. We have a pile of integers, and we have a few bitstrings. The integers need to allow decimal encoding; the bitstrings should NOT allow it. paul From owner-ips@ece.cmu.edu Tue Jul 2 17:58:59 2002 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA18169 for ; Tue, 2 Jul 2002 17:58:59 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id g62L4hK27625 for ips-outgoing; Tue, 2 Jul 2002 17:04:43 -0400 (EDT) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from lion.ninthwonder.com (lion.ninthwonder.com [151.199.66.147]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id g62L4cX27618 for ; Tue, 2 Jul 2002 17:04:42 -0400 (EDT) Received: by lion.ninthwonder.com (Postfix, from userid 1021) id 5085F30706; Tue, 2 Jul 2002 17:04:38 -0400 (EDT) Date: Tue, 2 Jul 2002 14:01:37 -0700 (PDT) From: Bill Studenmund X-X-Sender: To: Cc: , Subject: RE: iSCSI: Decimal encoding - why 64 bits ? In-Reply-To: <277DD60FB639D511AC0400B0D068B71E0564C017@CORPMX14> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ips@ece.cmu.edu Precedence: bulk On Tue, 2 Jul 2002 Black_David@emc.com wrote: > Easy does it. First of all - if someone will go find the mail > thread that discussed this (I also recall a discussion of > numbers vs. binary items) I'll take a look at it and make a > WG chair determination of what was or was not concluded. Ok, I found some of the confusion. Here's one of Paul's notes at the end of the thread I was remembering: http://www.pdl.cmu.edu/mailinglists/ips/mail/msg10302.html In it he says that he'd like base64 ot be used only for binary strings (not numbers). He also goes on to say, "For all other integer parameters -- which are 64 bit or smaller integers -- permit only hex and decimal.' In http://www.pdl.cmu.edu/mailinglists/ips/mail/msg10303.html, I agreed with both points above. In http://www.pdl.cmu.edu/mailinglists/ips/mail/msg10304.html, Shawn agrees with both myself and Paul, and talks about base64. In http://www.pdl.cmu.edu/mailinglists/ips/mail/msg10319.html, you (David) indicated you saw concensus for the base64 part of Paul's comments. My concusion was that I though we were all agreeing with both parts. I think we definitely got base64, but not so sure about no-decimal-binary-strings. > Kevin's comment that decimal ought to be limited to 32 bits > is still valid at this point - a reference to prior discussions > without specifics isn't enough to dismiss it. My rough > recollection of the discussion partially matches Julian's - > we reduced the required size to 64 bits from unlimited on > the assumption that platforms could cope with this ... and > now Kevin has raised the issue that two platforms he > considers important don't cope well with 64 bit arithmetic. > I don't recall discussion of whether to limit to 32 bits vs. > 64 bits. > > For now, this issue is open. I think this issue is a seperate one. I am fine with 64 bits (as I don't see us needing more than 32 with the present draft) or 32 bits. Take care, Bill From owner-ips@ece.cmu.edu Tue Jul 2 18:04:31 2002 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA18424 for ; Tue, 2 Jul 2002 18:04:31 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id g62LPvN28717 for ips-outgoing; Tue, 2 Jul 2002 17:25:57 -0400 (EDT) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from lion.ninthwonder.com (lion.ninthwonder.com [151.199.66.147]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id g62LPsX28707 for ; Tue, 2 Jul 2002 17:25:54 -0400 (EDT) Received: by lion.ninthwonder.com (Postfix, from userid 1021) id D7FBD30706; Tue, 2 Jul 2002 17:25:53 -0400 (EDT) Date: Tue, 2 Jul 2002 14:22:53 -0700 (PDT) From: Bill Studenmund X-X-Sender: To: Julian Satran Cc: Subject: RE: iSCSI: Decimal encoding - why 64 bits ? In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ips@ece.cmu.edu Precedence: bulk On Tue, 2 Jul 2002, Julian Satran wrote: > It was never supposed to be removed. Many values are passed around as > decimal. > We can't make any progress if we keep hitting the same things > again-and-again after a decent consensus has been reached. The question is does the draft reflect the concensus that all the discussion participants thought they achieved? At least one other person had the same impression I did about the past discussion. i.e. we thought we HAD achieved concensus, and yet the draft does not reflect that discussion. > And none of you has brought an argument that was not heard and dismissed > before. When were these arguements dismissed? While I recall a lot of disagreement on points, I don't recall a sound dismissal on technical grounds. > Remember we moved from unlimited length decimal to 64 bit to alleviate > implementer fears. Julian, those fears were for something else. Those fears were for how do you deal with extended-precision math when reading a large number. These concerns are that decimal encoding of binary strings suffers from many of the problems that base64 had for numbers - the need to perform arithmetic to byte-string conversion (i.e. hotns() and htonl() & friends). Now that the text explicitly states that the string size is in whole bytes, things aren't as weird as before. But it's still messy. I'll post a seperate message on this. Take care, Bill From owner-ips@ece.cmu.edu Tue Jul 2 18:38:57 2002 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA19870 for ; Tue, 2 Jul 2002 18:38:57 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id g62LxM700234 for ips-outgoing; Tue, 2 Jul 2002 17:59:22 -0400 (EDT) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from lion.ninthwonder.com (lion.ninthwonder.com [151.199.66.147]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id g62LxKX00228 for ; Tue, 2 Jul 2002 17:59:20 -0400 (EDT) Received: by lion.ninthwonder.com (Postfix, from userid 1021) id 7026E30706; Tue, 2 Jul 2002 17:59:20 -0400 (EDT) Date: Tue, 2 Jul 2002 14:56:20 -0700 (PDT) From: Bill Studenmund X-X-Sender: To: Subject: iSCSI: leading zeros and decimal-encoded binary strings Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ips@ece.cmu.edu Precedence: bulk Here's the heart of what I dislike about decimal-encoded binary strings: how do you convey the length of the binary string when you have leading zero bits? -14 says: "When used to encode binary strings decimal constants have an implicit byte-length that is the minimum number of bytes needed to represent the base2 encoding of the decimal number." How do leading zeros impact the "base2 encoding .."? Consider "012". Obviously the number is 12. The question is how many bytes are in the binary string? Is it one, since a number of three decimal digit numbers fit in one byte (up to "255"), or is it two bytes in the string since other three-decimal-digit numbers won't fit in one byte ("256" through "999")? The spec isn't clear, at least not to me. Ok, so one or two-byte strings aren't that likely. The problem though is that all of the byte sizes don't line up nicely with decimal digits (since 2^x = 10^y only works for x=0, y=0 AFAIK). Since we can't force that binary strings don't start with a zero-byte (or two), we need to support some way of communicating how long such a string is. Two suggestions: 1) Rip out the decimal binary strings bit 2) Come up with a table saying if you have so many digits which contain leading zeros, you have a binary string of so many bytes. Examples: String: Bytes in binary string: 00000000000000000012 8 00072057594037927935 8 00000000000000012 7 00281474976710655 7 000000000000012 6 001099511627775 6 0000000000012 5 0004294967295 5 0000000012 4 0016777215 4 00000012 3 00065535 3 00012 2 00255 2 The advantage of such a method is that you can easily force the right number of leading zeros with printf format strings. For instance, printf("%010d", an-int32-type) will do the right thing. But we need to communicate that in the spec, and we don't. Thoughts? Take care, Bill P.S. I will be on vacation starting tomorrow through the weekend. From owner-ips@ece.cmu.edu Tue Jul 2 18:39:16 2002 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA19896 for ; Tue, 2 Jul 2002 18:39:11 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id g62M52J00505 for ips-outgoing; Tue, 2 Jul 2002 18:05:02 -0400 (EDT) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from msgbas1.cos.agilent.com (msgbas1x.cos.agilent.com [192.25.240.36]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id g62M51X00501 for ; Tue, 2 Jul 2002 18:05:01 -0400 (EDT) Received: from msgrel1t.cos.agilent.com (msgrel1t.cos.agilent.com [130.29.152.157]) by msgbas1.cos.agilent.com (Postfix) with ESMTP id 35878BAF3; Tue, 2 Jul 2002 16:04:56 -0600 (MDT) Received: from axcsbh2.cos.agilent.com (axcsbh2.cos.agilent.com [130.29.152.144]) by msgrel1t.cos.agilent.com (Postfix) with SMTP id A2DEA236; Tue, 2 Jul 2002 16:04:54 -0600 (MDT) Received: from 130.29.152.144 by axcsbh2.cos.agilent.com (InterScan E-Mail VirusWall NT); Tue, 02 Jul 2002 16:04:50 -0600 Received: by axcsbh2.cos.agilent.com with Internet Mail Service (5.5.2653.19) id ; Tue, 2 Jul 2002 16:04:50 -0600 Message-ID: <1BEBA5E8600DD4119A50009027AF54A00CB26D70@axcs04.cos.agilent.com> From: pat_thaler@agilent.com To: Black_David@emc.com, Julian_Satran@il.ibm.com, ips@ece.cmu.edu Subject: RE: iSCSI: Decimal encoding - why 64 bits ? Date: Tue, 2 Jul 2002 16:04:45 -0600 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/mixed; boundary="----=_NextPartTM-000-d09dbdd4-8df7-11d6-ac7f-009027aa5b50" Sender: owner-ips@ece.cmu.edu Precedence: bulk This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------=_NextPartTM-000-d09dbdd4-8df7-11d6-ac7f-009027aa5b50 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C22214.79D04DA0" ------_=_NextPart_001_01C22214.79D04DA0 Content-Type: text/plain; charset="ISO-8859-1" David, Like many others, I was under the impression that we had discussed this before. However, I have been unable to find a discussion in the archive. I think that we may be remembering the similar discussion on base64 representation for numbers. The limit of 64 bits for regular-binary-value appeared with the other value type definitions in 12-90. The addition was preceeded by discussion in the Section 4.1 clarifications thread http://www.pdl.cmu.edu/mailinglists/ips/mail/msg09774.html but in reading that, I don't see any discussion of the 64 bit limit for regular-binary values. Then there was at least one comment in passing about decimal not being natural for binary strings in the base64 and numerical values thread (see Bill's text near the bottom of http://www.pdl.cmu.edu/mailinglists/ips/mail/msg10177.html ) but whether 64 bits was the appropriate limit for decimal doesn't seem to have been discussed there either. I think this is a new topic. Regards, Pat -----Original Message----- From: Black_David@emc.com [mailto:Black_David@emc.com] Sent: Tuesday, July 02, 2002 12:36 PM To: Julian_Satran@il.ibm.com; ips@ece.cmu.edu Subject: RE: iSCSI: Decimal encoding - why 64 bits ? Easy does it. First of all - if someone will go find the mail thread that discussed this (I also recall a discussion of numbers vs. binary items) I'll take a look at it and make a WG chair determination of what was or was not concluded. Kevin's comment that decimal ought to be limited to 32 bits is still valid at this point - a reference to prior discussions without specifics isn't enough to dismiss it. My rough recollection of the discussion partially matches Julian's - we reduced the required size to 64 bits from unlimited on the assumption that platforms could cope with this ... and now Kevin has raised the issue that two platforms he considers important don't cope well with 64 bit arithmetic. I don't recall discussion of whether to limit to 32 bits vs. 64 bits. For now, this issue is open. Thanks, --David -----Original Message----- From: Julian Satran [mailto:Julian_Satran@il.ibm.com] Sent: Tuesday, July 02, 2002 3:23 PM To: ips@ece.cmu.edu Subject: RE: iSCSI: Decimal encoding - why 64 bits ? It was never supposed to be removed. Many values are passed around as decimal. We can't make any progress if we keep hitting the same things again-and-again after a decent consensus has been reached. And none of you has brought an argument that was not heard and dismissed before. Remember we moved from unlimited length decimal to 64 bit to alleviate implementer fears. Julo Bill Studenmund 07/02/2002 10:03 PM Please respond to Bill Studenmund To: "THALER,PAT (A-Roseville,ex1)" cc: "LEMAY,KEVIN (A-Roseville,ex1)" , Julian Satran/Haifa/IBM@IBMIL, Subject: RE: iSCSI: Decimal encoding - why 64 bits ? On Tue, 2 Jul 2002, THALER,PAT (A-Roseville,ex1) wrote: > Bill, > > The decimal encoding is not just for numbers. It is also allowed for > binary-values. Both CHAP and SRP exchange items that are identified as > binary-values. In general these will be longer than 64 bits, but in > cases where they are 64 bits or less the decimal encoding is currently > allowed so we would have to support it. I thought we had a big discussion about this, and we decided that decimal was only used for numbers, hex for numbers and binary, and base64 only for binary items. ?? Doh! I just looked in -14, and the text doesn't reflect that understanding. Hmmm. > The issue is that currently decimal encoding is allowed for > binary-values and numbers less than 64 bits. There is little need for > it over 32 bits. We have two other entirely adequate representations > for those numbers. Why have something in there that causes extra code > for no benefit? All I can say is I thought it was removed. :-| Take care, Bill ------_=_NextPart_001_01C22214.79D04DA0 Content-Type: text/html; charset="ISO-8859-1" Content-Transfer-Encoding: quoted-printable
David,
 
Like = many others, I=20 was under the impression that we had discussed this before. However, I = have been=20 unable to find a discussion in the archive. I think that we may be = remembering=20 the similar discussion on base64 representation for numbers.=20
 
The = limit of 64 bits=20 for regular-binary-value appeared with the other value type = definitions in=20 12-90.
 
The = addition was=20 preceeded by discussion in the Section 4.1 clarifications=20 thread
http= ://www.pdl.cmu.edu/mailinglists/ips/mail/msg09774.html=
but = in reading that,=20 I don't see any discussion of the 64 bit limit for regular-binary = values. Then=20 there was at least one comment in passing about decimal not being = natural for=20 binary strings in the base64 and numerical values thread (see = Bill's text=20 near the bottom of
http= ://www.pdl.cmu.edu/mailinglists/ips/mail/msg10177.html)
but = whether 64 bits=20 was the appropriate limit for decimal doesn't seem to have been = discussed there=20 either.
 
I = think this is a=20 new topic.
 
Regards,
Pat
 
 
-----Original Message-----
From: Black_David@emc.com = [mailto:Black_David@emc.com]
Sent: Tuesday, July 02, 2002 = 12:36=20 PM
To: Julian_Satran@il.ibm.com; = ips@ece.cmu.edu
Subject:=20 RE: iSCSI: Decimal encoding - why 64 bits ?

Easy does=20 it.  First of all - if someone will go find the=20 mail
thread that=20 discussed this (I also recall a discussion of
numbers vs.=20 binary items) I'll take a look at it and make a
WG chair=20 determination of what was or was not concluded.
 
Kevin's=20 comment that decimal ought to be limited to 32 bits
is still=20 valid at this point - a reference to prior = discussions
without=20 specifics isn't enough to dismiss it.  My = rough
recollection=20 of the discussion partially matches Julian's -
we reduced=20 the required size to 64 bits from unlimited on
the=20 assumption that platforms could cope with this ... = and
now=20 Kevin has raised the issue that two = platforms=20 he
considers=20 important don't cope well with 64 bit=20 arithmetic.
I don't=20 recall discussion of whether to limit to 32 bits = vs.
64=20 bits.
 
For now,=20 this issue is open.
 
Thanks,
--David
-----Original Message-----
From: Julian Satran=20 [mailto:Julian_Satran@il.ibm.com]
Sent: Tuesday, July 02, = 2002 3:23=20 PM
To: ips@ece.cmu.edu
Subject: RE: iSCSI: = Decimal=20 encoding - why 64 bits ?


It was never supposed to be removed. Many values are passed = around as=20 decimal.
We can't make = any progress if=20 we keep hitting the same things again-and-again after a decent = consensus has=20 been reached.
And none of = you has=20 brought an argument that was not heard and dismissed before.=20

Remember we moved from = unlimited length=20 decimal to 64 bit to alleviate implementer fears. =

Julo


Bill Studenmund=20 <wrstuden@wasabisystems.com>=20

07/02/2002 10:03 PM =
Please respond to Bill = Studenmund

        =
        To: =    =20    "THALER,PAT (A-Roseville,ex1)"=20 <pat_thaler@agilent.com>
        cc:      =20  "LEMAY,KEVIN (A-Roseville,ex1)" = <kevin_lemay@agilent.com>,=20 Julian Satran/Haifa/IBM@IBMIL, <ips@ece.cmu.edu> =
        Subject: =  =20      RE: iSCSI: Decimal encoding - why 64 bits = ?=20

     =20  


On Tue, 2 Jul 2002, THALER,PAT (A-Roseville,ex1) = wrote:

>=20 Bill,
>

> The decimal encoding is not just for = numbers. It is=20 also allowed for
> binary-values. Both CHAP and SRP exchange = items that=20 are identified as
> binary-values. In general these will be = longer than=20 64 bits, but in
> cases where they are 64 bits or less the = decimal=20 encoding is currently
> allowed so we would have to support = it.

I=20 thought we had a big discussion about this, and we decided that = decimal
was=20 only used for numbers, hex for numbers and binary, and base64 only=20 for
binary items. ??

Doh! I just looked in -14, and the = text doesn't=20 reflect that
understanding. Hmmm.

> The issue is that = currently=20 decimal encoding is allowed for
> binary-values and numbers = less than 64=20 bits. There is little need for
> it over 32 bits. We have two = other=20 entirely adequate representations
> for those numbers. Why have = something in there that causes extra code
> for no = benefit?

All I=20 can say is I thought it was removed. :-|

Take=20 care,

Bill



------_=_NextPart_001_01C22214.79D04DA0-- ------=_NextPartTM-000-d09dbdd4-8df7-11d6-ac7f-009027aa5b50-- From owner-ips@ece.cmu.edu Tue Jul 2 18:40:25 2002 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA20011 for ; Tue, 2 Jul 2002 18:40:16 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id g62M8Ui00691 for ips-outgoing; Tue, 2 Jul 2002 18:08:30 -0400 (EDT) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from msgbas2.cos.agilent.com (msgbas2x.cos.agilent.com [192.25.240.37]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id g62M8SX00687 for ; Tue, 2 Jul 2002 18:08:28 -0400 (EDT) Received: from msgrel1t.cos.agilent.com (msgrel1t.cos.agilent.com [130.29.152.157]) by msgbas2.cos.agilent.com (Postfix) with ESMTP id B70751F80; Tue, 2 Jul 2002 16:08:27 -0600 (MDT) Received: from axcsbh2.cos.agilent.com (axcsbh2.cos.agilent.com [130.29.152.144]) by msgrel1t.cos.agilent.com (Postfix) with SMTP id 5344051E; Tue, 2 Jul 2002 16:08:27 -0600 (MDT) Received: from 130.29.152.144 by axcsbh2.cos.agilent.com (InterScan E-Mail VirusWall NT); Tue, 02 Jul 2002 16:08:25 -0600 Received: by axcsbh2.cos.agilent.com with Internet Mail Service (5.5.2653.19) id ; Tue, 2 Jul 2002 16:08:25 -0600 Message-ID: <1BEBA5E8600DD4119A50009027AF54A00CB26D71@axcs04.cos.agilent.com> From: pat_thaler@agilent.com To: Julian_Satran@il.ibm.com, ips@ece.cmu.edu Subject: RE: iSCSI: Login negotiation space Date: Tue, 2 Jul 2002 16:08:23 -0600 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/mixed; boundary="----=_NextPartTM-000-d09dbf10-8df7-11d6-ac7f-009027aa5b50" Sender: owner-ips@ece.cmu.edu Precedence: bulk This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------=_NextPartTM-000-d09dbf10-8df7-11d6-ac7f-009027aa5b50 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C22214.FB7DC850" ------_=_NextPart_001_01C22214.FB7DC850 Content-Type: text/plain; charset="ISO-8859-1" Julian, There is a separate number for cases where very long authentication items are supported and I haven't asked to change that number. Remember the text is: Any iSCSI target or initiator MUST support receiving at least 16384 bytes of key=value data in a negotiation sequence except when indicating support for very long authentication items by offering or selecting authentication methods such as public key certificates in which case they MUST support receiving at least 64 kilobytes of key=value data. Changing the 16384 number on the first line to 4096 will have no effect on the 64 kilobytes limit on the last line and implementations desiring to support very long authentication items are covered. 4k works fine for the required CHAP authentication and there is no reason to require 16k. Controlling memory by delaying negotiation with some parties as memory fills is an unnecessary complication which can result in deadlocks. If one does what you suggest and throttles keys "as you have unprocessed keys exceeding the mount of memory you want to keep aside", then you may get to that point but find that none of the keys you have are processable - the C bit is set and you need to get some more packets before you can process. One could throttle just some logins when one has enough memory left to complete some but not all of the negotiations, but there is a risk of deadlock. A simple example: Target X decides to stall negotiation from Initiator B until negotiation from Initiator A completes freeing buffer. Initiator A has stalled negotiation with Target X until negotiation with Target Y completes freeing buffer. Target Y has stalled negotiation with Initiator A until negotiation with Initiator B completes. Initiator B has stalled negotiation with Target Y until negotiation with Target X completes. They are all stalled until one or more of the logins times out. It is much safer and simpler to set the required memory size to a reasonable limit for the mandatory negotiation items plus some comfortable room for expansion. Regards, Pat -----Original Message----- From: Julian Satran [mailto:Julian_Satran@il.ibm.com] Sent: Tuesday, July 02, 2002 12:36 PM To: ips@ece.cmu.edu Subject: RE: iSCSI: Login negotiation space Pat, 4k is absurd. We have the security guys asking for 64k certificates! And the PDUlength default is 8k! Besides you can control the total memory consumed by throttling login as soon as you have unprocessed keys exceeding the mount of memory you want to keep aside (you control the login progress by delaying requests/responses). Julo pat_thaler@agilent.com 07/02/2002 10:02 PM Please respond to pat_thaler To: Julian Satran/Haifa/IBM@IBMIL, pat_thaler@agilent.com cc: ips@ece.cmu.edu Subject: RE: iSCSI: Login negotiation space Julian, A factor of 10 is way overkill. It isn't just 16 k bytes of extra memory. It is n * 16k where n is the number of simultaneous logins the implementation supports - it adds up. The system vendors we work with want to use the memory to do useful work and demand that driver sizes be kept small -- they want the memory available to do "real" work. If 2k doesn't leave enough headroom, then we could live with somewhat more like 4k. If future features added to iSCSI require more space, the drivers that support that can allocate more memory. It is an internal parameter that can be changed when the need arises. There is no future interoperability need to make the buffer oversized in current implementations. Regards, Pat -----Original Message----- From: Julian Satran [mailto:Julian_Satran@il.ibm.com] Sent: Tuesday, July 02, 2002 12:10 AM To: pat_thaler@agilent.com Cc: ips@ece.cmu.edu Subject: RE: iSCSI: Login negotiation space Pat, A factor of 10 over what is needed today is what I would call a conservative design. Limiting the support to 2k would be extremely unwise. And 16 is a tiny amount of memory - of no concern to software implementation and to most hardware implementations. Julo pat_thaler@agilent.com 07/02/2002 01:56 AM Please respond to pat_thaler To: Julian Satran/Haifa/IBM@IBMIL cc: ips@ece.cmu.edu Subject: RE: iSCSI: Login negotiation space Julian, 4.1 contains a requirement that initiators and targets support receiving at least 16384 bytes of key=value data (when not supporting very long authentication items). This is overkill and is making drivers larger than they need to be. My calculations are that Security negotiation using the CHAP method (including the Any-stage keys) takes less than 1600 bytes. Operational negotiation requires 1276 bytes (also including the Any-stage keys). All the operational plus security keys are 1911 bytes. Therefore an implementation could hold all the necessary keys in 2 Kbytes. And, the implementation doesn't need to keep the security keys after the security negotiation is done so it could clear some of that out to make room for future keys or vendor specific keys. 16 K bytes is about 10 times the necessary storage in that case. The number of negotiation bytes that a device is required to support should be reduced substantially - preferably to 2048 bytes. Regards, Pat The numbers: 43 AuthMethod CHAP keys 264 Name (no defined size limit - using 255) 11 Algorithm 11 Identifier 264 Challenge 42 Response (for MD5) _____ 635 Chap negotiation length 892 Any-stage keys ---- 1527 Operational negotiation keys 24 HeaderDigest 24 DataDigest 49 MaxConnections 270 TargetName* or InitiatorName* 271 TargetAlias* or InitiatorAlias* 273 TargetAddress* 55 TargetPortalGroupTag* 15 InitialR2T 19 BidiInitialR2T 18 ImmediateData 34 MaxRecvDataSegmentLength 24 MaxBurstLength 26 FirstBurstLength 24 DefaultTime2Wait 26 DefaultTime2Retain 25 MaxOutstandingR2T 18 DataPDUInOrder 24 DataSequenceInOrder 24 ErrorRecoveryLevel 23 SessionType* ------ 892 Any-stage keys 384 Not Any-stage ------ 1276 Operational keys ------_=_NextPart_001_01C22214.FB7DC850 Content-Type: text/html; charset="ISO-8859-1"
Julian,
 
There is a separate number for cases where very long authentication items are supported and I haven't asked to change that number.
 
Remember the text is:

Any iSCSI target or initiator MUST support receiving at least 16384 bytes of key=value data in a negotiation sequence except when indicating support for very long authentication items by offering or selecting authentication methods such as public key certificates in which case they MUST support receiving at least 64 kilobytes of key=value data.

Changing the 16384 number on the first line to 4096 will have no effect on the 64 kilobytes limit on the last line and implementations desiring to support very long authentication items are covered.
 
4k works fine for the required CHAP authentication and there is no reason to require 16k. Controlling memory by delaying negotiation with some parties as memory fills is an unnecessary complication which can result in deadlocks.
 
If one does what you suggest and throttles keys "as you have unprocessed keys exceeding the mount of memory you want to keep aside", then you may get to that point but find that none of the keys you have are processable - the C bit is set and you need to get some more packets before you can process.
 
One could throttle just some logins when one has enough memory left to complete some but not all of the negotiations, but there is a risk of deadlock. A simple example: Target X decides to stall negotiation from Initiator B until negotiation from Initiator A completes freeing buffer. Initiator A has stalled negotiation with Target X until negotiation with Target Y completes freeing buffer. Target Y has stalled negotiation with Initiator A until negotiation with Initiator B completes. Initiator B has stalled negotiation with Target Y until negotiation with Target X completes. They are all stalled until one or more of the logins times out.
 
It is much safer and simpler to set the required memory size to a reasonable limit for the mandatory negotiation items plus some comfortable room for expansion.
 
Regards,
Pat
 
-----Original Message-----
From: Julian Satran [mailto:Julian_Satran@il.ibm.com]
Sent: Tuesday, July 02, 2002 12:36 PM
To: ips@ece.cmu.edu
Subject: RE: iSCSI: Login negotiation space


Pat,

4k is absurd. We have the security guys asking for 64k certificates!
And the PDUlength default is 8k!
Besides you can control the total memory consumed by throttling login as soon as you have unprocessed keys exceeding the mount of memory you want to keep aside (you control the login progress by delaying requests/responses).


Julo


pat_thaler@agilent.com

07/02/2002 10:02 PM
Please respond to pat_thaler

       
        To:        Julian Satran/Haifa/IBM@IBMIL, pat_thaler@agilent.com
        cc:        ips@ece.cmu.edu
        Subject:        RE: iSCSI: Login negotiation space

       


Julian,
 
A factor of 10 is way overkill. It isn't just 16 k bytes of extra memory. It is n * 16k where n is the number of simultaneous logins the implementation supports - it adds up. The system vendors we work with want to use the memory to do useful work and demand that driver sizes be kept small -- they want the memory available to do "real" work.
 
If 2k doesn't leave enough headroom, then we could live with somewhat more like 4k.
 
If future features added to iSCSI require more space, the drivers that support that can allocate more memory. It is an internal parameter that can be changed when the need arises. There is no future interoperability need to make the buffer oversized in current implementations.
 
Regards,
Pat
 
-----Original Message-----
From: Julian Satran [mailto:Julian_Satran@il.ibm.com]
Sent: Tuesday, July 02, 2002 12:10 AM
To: pat_thaler@agilent.com
Cc: ips@ece.cmu.edu
Subject: RE: iSCSI: Login negotiation space


Pat,

A factor of 10 over what is needed today is what I would call a conservative design.
Limiting the support to 2k would be extremely unwise.
And 16 is a tiny amount of memory - of no concern to software implementation and to most hardware implementations.

Julo


pat_thaler@agilent.com

07/02/2002 01:56 AM
Please respond to pat_thaler

       
       To:        Julian Satran/Haifa/IBM@IBMIL
       cc:        ips@ece.cmu.edu
       Subject:        RE: iSCSI: Login negotiation space

     



Julian,

4.1 contains a requirement that initiators and targets support receiving at least 16384 bytes of key=value data (when not supporting very long authentication items). This is overkill and is making drivers larger than they need to be.

My calculations are that Security negotiation using the CHAP method (including the Any-stage keys) takes less than 1600 bytes. Operational negotiation requires 1276 bytes (also including the Any-stage keys). All the operational plus security keys are 1911 bytes.

Therefore an implementation could hold all the necessary keys in 2 Kbytes. And, the implementation doesn't need to keep the security keys after the security negotiation is done so it could clear some of that out to make room for future keys or vendor specific keys. 16 K bytes is about 10 times the necessary storage in that case.

The number of negotiation bytes that a device is required to support should be reduced substantially - preferably to 2048 bytes.

Regards,
Pat


The numbers:

43                                  AuthMethod
         CHAP keys
264                                  Name (no defined size limit - using 255)
11                                  Algorithm
11                                  Identifier
264                                  Challenge
42                                  Response (for MD5)
_____
635 Chap negotiation length
892 Any-stage keys
----
1527

Operational negotiation keys
24                                  HeaderDigest
24        DataDigest
49        MaxConnections
270                                  TargetName* or InitiatorName*
271                                  TargetAlias* or InitiatorAlias*
273        TargetAddress*
55                                  TargetPortalGroupTag*
15                                  InitialR2T
19                                  BidiInitialR2T
18                                  ImmediateData
34                                  MaxRecvDataSegmentLength
24                                  MaxBurstLength
26                                  FirstBurstLength
24                                  DefaultTime2Wait
26                                  DefaultTime2Retain
25                                  MaxOutstandingR2T
18                                  DataPDUInOrder
24                                  DataSequenceInOrder
24                                  ErrorRecoveryLevel
23                                  SessionType*
------
892 Any-stage keys
384 Not Any-stage
------
1276 Operational keys








------_=_NextPart_001_01C22214.FB7DC850-- ------=_NextPartTM-000-d09dbf10-8df7-11d6-ac7f-009027aa5b50-- From owner-ips@ece.cmu.edu Tue Jul 2 19:20:46 2002 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA21739 for ; Tue, 2 Jul 2002 19:20:46 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id g62Mew501956 for ips-outgoing; Tue, 2 Jul 2002 18:40:58 -0400 (EDT) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from msgbas1.cos.agilent.com (msgbas1x.cos.agilent.com [192.25.240.36]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id g62MeuX01948 for ; Tue, 2 Jul 2002 18:40:56 -0400 (EDT) Received: from msgrel1t.cos.agilent.com (msgrel1t.cos.agilent.com [130.29.152.157]) by msgbas1.cos.agilent.com (Postfix) with ESMTP id B264CB2AD; Tue, 2 Jul 2002 16:40:55 -0600 (MDT) Received: from axcsbh1.cos.agilent.com (axcsbh1.cos.agilent.com [130.29.152.143]) by msgrel1t.cos.agilent.com (Postfix) with SMTP id 51039525; Tue, 2 Jul 2002 16:40:55 -0600 (MDT) Received: from 130.29.152.143 by axcsbh1.cos.agilent.com (InterScan E-Mail VirusWall NT); Tue, 02 Jul 2002 16:40:54 -0600 Received: by axcsbh1.cos.agilent.com with Internet Mail Service (5.5.2653.19) id ; Tue, 2 Jul 2002 16:40:54 -0600 Message-ID: <1BEBA5E8600DD4119A50009027AF54A00CB26D7A@axcs04.cos.agilent.com> From: "THALER,PAT (A-Roseville,ex1)" To: Mark Bakke , "THALER,PAT (A-Roseville,ex1)" Cc: Black_David@emc.com, Julian_Satran@il.ibm.com, ips@ece.cmu.edu Subject: RE: iSCSI: Decimal encoding - why 64 bits ? Date: Tue, 2 Jul 2002 16:40:47 -0600 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-ips@ece.cmu.edu Precedence: bulk Mark, What about 40-bit to 56-bit decimal encoded binary values? They are allowed. 4.1 binary-value includes regular-binary-value and large-binary-value. regular-binary-value is for strings less than 64 bits and allows decimal encoding. (It says less than 64 and decimal encoded binary strings are always in bytes so the largest decimal encoded binary would be 56 bits.) 10.4 SRP: N,g,s,A,B,M and H(A | M | K) are binary-values 10.5 CHAP: C and R are binary-values 10.2 and 10.3 use large-binary-value instead of binary-value and I can't find any other use of binary-value. Normally, the values defined as binary-values for SRP and CHAP would be 64 bits or longer anyway, but someone could send short keys and encode them in decimal according to the current draft. This should be eliminated. Regards, Pat -----Original Message----- From: Mark Bakke [mailto:mbakke@cisco.com] Sent: Tuesday, July 02, 2002 3:36 PM To: pat_thaler@agilent.com Cc: Black_David@emc.com; Julian_Satran@il.ibm.com; ips@ece.cmu.edu Subject: Re: iSCSI: Decimal encoding - why 64 bits ? For what it's worth, none of the numeric values for iSCSI that can be retrieved or set via the MIB require more than 32 bits (other than counters, but I doubt we would ever send a counter during negotiation :-). The allowable ranges just didn't need more than that. Anyway, I haven't seen a need to provide support for 64-bit values in our implementation yet, since none of the numeric keys can have values that high. -- Mark A. Bakke Cisco Systems mbakke@cisco.com 763.398.1054 From owner-ips@ece.cmu.edu Tue Jul 2 19:24:31 2002 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA21856 for ; Tue, 2 Jul 2002 19:24:26 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id g62N1dE02755 for ips-outgoing; Tue, 2 Jul 2002 19:01:39 -0400 (EDT) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from mail1irv.inside.istor.com (host28.istor.com [66.134.214.28]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id g62N1bX02750 for ; Tue, 2 Jul 2002 19:01:37 -0400 (EDT) Subject: Delaying Login - was: RE: iSCSI: Login negotiation space From: Michael Morrison To: Julian Satran Cc: ips@ece.cmu.edu In-Reply-To: References: Content-Type: multipart/alternative; boundary="=-/FV+JrUGkvA7E91gFMEP" X-Mailer: Ximian Evolution 1.0.8 Date: 02 Jul 2002 15:59:07 -0700 Message-Id: <1025650747.4942.78.camel@jackal.engasic.istor.com> Mime-Version: 1.0 Sender: owner-ips@ece.cmu.edu Precedence: bulk --=-/FV+JrUGkvA7E91gFMEP Content-Type: text/plain Content-Transfer-Encoding: 7bit Julian, Your comment about controlling login progress by delaying requests/responses begs the question: How long is too long? I actually have a question about delaying login during Session Reinstatement. Say a target receives a login indicating Session Reinstatement. The target must internally abort all tasks on the session, but this may take a very long time and the implementer may not want to complete the reinstatement login until all the tasks are aborted; again, how long is too long? Perhaps a blurb in a new section (6.3.3?) on Timeouts on Login, or Timeouts on Session Reinstatement? Mike On Tue, 2002-07-02 at 12:35, Julian Satran wrote: Pat, 4k is absurd. We have the security guys asking for 64k certificates! And the PDUlength default is 8k! Besides you can control the total memory consumed by throttling login as soon as you have unprocessed keys exceeding the mount of memory you want to keep aside (you control the login progress by delaying requests/responses). Julo pat_thaler@agilent.com 07/02/2002 10:02 PM Please respond to pat_thaler To: Julian Satran/Haifa/IBM@IBMIL, pat_thaler@agilent.com cc: ips@ece.cmu.edu Subject: RE: iSCSI: Login negotiation space Julian, A factor of 10 is way overkill. It isn't just 16 k bytes of extra memory. It is n * 16k where n is the number of simultaneous logins the implementation supports - it adds up. The system vendors we work with want to use the memory to do useful work and demand that driver sizes be kept small -- they want the memory available to do "real" work. If 2k doesn't leave enough headroom, then we could live with somewhat more like 4k. If future features added to iSCSI require more space, the drivers that support that can allocate more memory. It is an internal parameter that can be changed when the need arises. There is no future interoperability need to make the buffer oversized in current implementations. Regards, Pat -----Original Message----- From: Julian Satran [mailto:Julian_Satran@il.ibm.com] Sent: Tuesday, July 02, 2002 12:10 AM To: pat_thaler@agilent.com Cc: ips@ece.cmu.edu Subject: RE: iSCSI: Login negotiation space Pat, A factor of 10 over what is needed today is what I would call a conservative design. Limiting the support to 2k would be extremely unwise. And 16 is a tiny amount of memory - of no concern to software implementation and to most hardware implementations. Julo pat_thaler@agilent.com 07/02/2002 01:56 AM Please respond to pat_thaler To: Julian Satran/Haifa/IBM@IBMIL cc: ips@ece.cmu.edu Subject: RE: iSCSI: Login negotiation space Julian, 4.1 contains a requirement that initiators and targets support receiving at least 16384 bytes of key=value data (when not supporting very long authentication items). This is overkill and is making drivers larger than they need to be. My calculations are that Security negotiation using the CHAP method (including the Any-stage keys) takes less than 1600 bytes. Operational negotiation requires 1276 bytes (also including the Any-stage keys). All the operational plus security keys are 1911 bytes. Therefore an implementation could hold all the necessary keys in 2 Kbytes. And, the implementation doesn't need to keep the security keys after the security negotiation is done so it could clear some of that out to make room for future keys or vendor specific keys. 16 K bytes is about 10 times the necessary storage in that case. The number of negotiation bytes that a device is required to support should be reduced substantially - preferably to 2048 bytes. Regards, Pat The numbers: 43 AuthMethod CHAP keys 264 Name (no defined size limit - using 255) 11 Algorithm 11 Identifier 264 Challenge 42 Response (for MD5) _____ 635 Chap negotiation length 892 Any-stage keys ---- 1527 Operational negotiation keys 24 HeaderDigest 24 DataDigest 49 MaxConnections 270 TargetName* or InitiatorName* 271 TargetAlias* or InitiatorAlias* 273 TargetAddress* 55 TargetPortalGroupTag* 15 InitialR2T 19 BidiInitialR2T 18 ImmediateData 34 MaxRecvDataSegmentLength 24 MaxBurstLength 26 FirstBurstLength 24 DefaultTime2Wait 26 DefaultTime2Retain 25 MaxOutstandingR2T 18 DataPDUInOrder 24 DataSequenceInOrder 24 ErrorRecoveryLevel 23 SessionType* ------ 892 Any-stage keys 384 Not Any-stage ------ 1276 Operational keys Michael Morrison ISTOR Networks 7585 Irvine Center Dr. Ste 250 Irvine Ca. 92618 PGP Key: 74C30155 --=-/FV+JrUGkvA7E91gFMEP Content-Type: text/html; charset=utf-8 Julian,

Your comment about controlling login progress by delaying requests/responses begs the question:  How long is too long?

I actually have a question about delaying login during Session Reinstatement.  Say a target receives a login indicating Session Reinstatement.  The target must internally abort all tasks on the session, but this may take a very long time and the implementer may not
want to complete the reinstatement login until all the tasks are aborted;  again,  how long is too long?

Perhaps a blurb in a new section (6.3.3?) on Timeouts on Login, or Timeouts on Session Reinstatement? 

Mike

On Tue, 2002-07-02 at 12:35, Julian Satran wrote:
Pat,

4k is absurd. We have the security guys asking for 64k certificates!
And the PDUlength default is 8k!
Besides you can control the total memory consumed by throttling login as soon as you have unprocessed keys exceeding the mount of memory you want to keep aside (you control the login progress by delaying requests/responses).


Julo


pat_thaler@agilent.com

07/02/2002 10:02 PM
Please respond to pat_thaler
       
        To:        Julian Satran/Haifa/IBM@IBMIL, pat_thaler@agilent.com
        cc:        ips@ece.cmu.edu
        Subject:        RE: iSCSI: Login negotiation space

       


Julian,
 
A factor of 10 is way overkill. It isn't just 16 k bytes of extra memory. It is n * 16k where n is the number of simultaneous logins the implementation supports - it adds up. The system vendors we work with want to use the memory to do useful work and demand that driver sizes be kept small -- they want the memory available to do "real" work.
 
If 2k doesn't leave enough headroom, then we could live with somewhat more like 4k.
 
If future features added to iSCSI require more space, the drivers that support that can allocate more memory. It is an internal parameter that can be changed when the need arises. There is no future interoperability need to make the buffer oversized in current implementations.
 
Regards,
Pat
 
-----Original Message-----
From: Julian Satran [mailto:Julian_Satran@il.ibm.com]
Sent: Tuesday, July 02, 2002 12:10 AM
To: pat_thaler@agilent.com
Cc: ips@ece.cmu.edu
Subject: RE: iSCSI: Login negotiation space


Pat,

A factor of 10 over what is needed today is what I would call a conservative design.
Limiting the support to 2k would be extremely unwise.
And 16 is a tiny amount of memory - of no concern to software implementation and to most hardware implementations.

Julo


pat_thaler@agilent.com

07/02/2002 01:56 AM
Please respond to pat_thaler 		       
       To:        Julian Satran/Haifa/IBM@IBMIL
       cc:        ips@ece.cmu.edu
       Subject:        RE: iSCSI: Login negotiation space

     



Julian,

4.1 contains a requirement that initiators and targets support receiving at least 16384 bytes of key=value data (when not supporting very long authentication items). This is overkill and is making drivers larger than they need to be.

My calculations are that Security negotiation using the CHAP method (including the Any-stage keys) takes less than 1600 bytes. Operational negotiation requires 1276 bytes (also including the Any-stage keys). All the operational plus security keys are 1911 bytes.

Therefore an implementation could hold all the necessary keys in 2 Kbytes. And, the implementation doesn't need to keep the security keys after the security negotiation is done so it could clear some of that out to make room for future keys or vendor specific keys. 16 K bytes is about 10 times the necessary storage in that case.

The number of negotiation bytes that a device is required to support should be reduced substantially - preferably to 2048 bytes.

Regards,
Pat


The numbers:

43                                  AuthMethod
         CHAP keys
264                                  Name (no defined size limit - using 255)
11                                  Algorithm
11                                  Identifier
264                                  Challenge
42                                  Response (for MD5)
_____
635 Chap negotiation length
892 Any-stage keys
----
1527

Operational negotiation keys
24                                  HeaderDigest
24        DataDigest
49        MaxConnections
270                                  TargetName* or InitiatorName*
271                                  TargetAlias* or InitiatorAlias*
273        TargetAddress*
55                                  TargetPortalGroupTag*
15                                  InitialR2T
19                                  BidiInitialR2T
18                                  ImmediateData
34                                  MaxRecvDataSegmentLength
24                                  MaxBurstLength
26                                  FirstBurstLength
24                                  DefaultTime2Wait
26                                  DefaultTime2Retain
25                                  MaxOutstandingR2T
18                                  DataPDUInOrder
24                                  DataSequenceInOrder
24                                  ErrorRecoveryLevel
23                                  SessionType*
------
892 Any-stage keys
384 Not Any-stage
------
1276 Operational keys








Michael Morrison
ISTOR Networks
7585 Irvine Center Dr. Ste 250
Irvine Ca. 92618
PGP Key: 74C30155
--=-/FV+JrUGkvA7E91gFMEP-- From owner-ips@ece.cmu.edu Tue Jul 2 19:24:38 2002 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA19871 for ; Tue, 2 Jul 2002 18:38:57 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id g62MIC501096 for ips-outgoing; Tue, 2 Jul 2002 18:18:12 -0400 (EDT) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from sj-msg-core-1.cisco.com (sj-msg-core-1.cisco.com [171.71.163.11]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id g62MIAX01092 for ; Tue, 2 Jul 2002 18:18:10 -0400 (EDT) Received: from nisser.cisco.com (nisser.cisco.com [171.71.176.85]) by sj-msg-core-1.cisco.com (8.12.2/8.12.2) with ESMTP id g62MI439006343; Tue, 2 Jul 2002 15:18:04 -0700 (PDT) Received: from cisco.com (mbakke@mbakke-lnx.cisco.com [161.44.68.87]) by nisser.cisco.com (8.8.6 (PHNE_14041)/CISCO.SERVER.1.2) with ESMTP id PAA26298; Tue, 2 Jul 2002 15:17:59 -0700 (PDT) Message-ID: <3D222ACC.D46C9A28@cisco.com> Date: Tue, 02 Jul 2002 17:35:56 -0500 From: Mark Bakke X-Mailer: Mozilla 4.72 [en] (X11; U; Linux 2.2.16-3.uid32 i686) X-Accept-Language: en, de MIME-Version: 1.0 To: pat_thaler@agilent.com CC: Black_David@emc.com, Julian_Satran@il.ibm.com, ips@ece.cmu.edu Subject: Re: iSCSI: Decimal encoding - why 64 bits ? References: <1BEBA5E8600DD4119A50009027AF54A00CB26D70@axcs04.cos.agilent.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ips@ece.cmu.edu Precedence: bulk Content-Transfer-Encoding: 7bit For what it's worth, none of the numeric values for iSCSI that can be retrieved or set via the MIB require more than 32 bits (other than counters, but I doubt we would ever send a counter during negotiation :-). The allowable ranges just didn't need more than that. Anyway, I haven't seen a need to provide support for 64-bit values in our implementation yet, since none of the numeric keys can have values that high. -- Mark A. Bakke Cisco Systems mbakke@cisco.com 763.398.1054 From owner-ips@ece.cmu.edu Tue Jul 2 19:25:47 2002 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA21895 for ; Tue, 2 Jul 2002 19:25:47 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id g62N9L702996 for ips-outgoing; Tue, 2 Jul 2002 19:09:21 -0400 (EDT) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from msgbas1.cos.agilent.com (msgbas1x.cos.agilent.com [192.25.240.36]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id g62N9KX02992 for ; Tue, 2 Jul 2002 19:09:20 -0400 (EDT) Received: from msgrel1t.cos.agilent.com (msgrel1t.cos.agilent.com [130.29.152.157]) by msgbas1.cos.agilent.com (Postfix) with ESMTP id 3302A9E3D; Tue, 2 Jul 2002 17:09:16 -0600 (MDT) Received: from axcsbh4.cos.agilent.com (axcsbh4.cos.agilent.com [130.29.152.145]) by msgrel1t.cos.agilent.com (Postfix) with SMTP id 83BE0525; Tue, 2 Jul 2002 17:09:15 -0600 (MDT) Received: from 130.29.152.145 by axcsbh4.cos.agilent.com (InterScan E-Mail VirusWall NT); Tue, 02 Jul 2002 17:09:13 -0600 Received: by axcsbh4.cos.agilent.com with Internet Mail Service (5.5.2653.19) id ; Tue, 2 Jul 2002 17:09:13 -0600 Message-ID: <1BEBA5E8600DD4119A50009027AF54A00CB26D81@axcs04.cos.agilent.com> From: pat_thaler@agilent.com To: wrstuden@wasabisystems.com, ips@ece.cmu.edu Subject: RE: iSCSI: leading zeros and decimal-encoded binary strings Date: Tue, 2 Jul 2002 17:09:13 -0600 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-ips@ece.cmu.edu Precedence: bulk Bill, There is an additional thing I don't like about decimal-encoded binary strings. We will have to put in support for a feature that is unlikely to be used. The only items defined as binary-values are CHAP and SRP binary strings which usually will be too long for decimal encoding anyway. Take CHAP for instance. It C and R are defined as binary-values. R is 16 bytes so it can't be decimal encoded. C shorter than 8 bytes seems unlikely. My preference would be to replace the definition of binary-value with the current definition of large-binary value, replace large-binary-value with binary-value (in 10.2 and 10.3) and get rid of regular-binary-value and large-binary-value. Regards, Pat -----Original Message----- From: Bill Studenmund [mailto:wrstuden@wasabisystems.com] Sent: Tuesday, July 02, 2002 2:56 PM To: ips@ece.cmu.edu Subject: iSCSI: leading zeros and decimal-encoded binary strings Here's the heart of what I dislike about decimal-encoded binary strings: how do you convey the length of the binary string when you have leading zero bits? -14 says: "When used to encode binary strings decimal constants have an implicit byte-length that is the minimum number of bytes needed to represent the base2 encoding of the decimal number." How do leading zeros impact the "base2 encoding .."? Consider "012". Obviously the number is 12. The question is how many bytes are in the binary string? Is it one, since a number of three decimal digit numbers fit in one byte (up to "255"), or is it two bytes in the string since other three-decimal-digit numbers won't fit in one byte ("256" through "999")? The spec isn't clear, at least not to me. Ok, so one or two-byte strings aren't that likely. The problem though is that all of the byte sizes don't line up nicely with decimal digits (since 2^x = 10^y only works for x=0, y=0 AFAIK). Since we can't force that binary strings don't start with a zero-byte (or two), we need to support some way of communicating how long such a string is. Two suggestions: 1) Rip out the decimal binary strings bit 2) Come up with a table saying if you have so many digits which contain leading zeros, you have a binary string of so many bytes. Examples: String: Bytes in binary string: 00000000000000000012 8 00072057594037927935 8 00000000000000012 7 00281474976710655 7 000000000000012 6 001099511627775 6 0000000000012 5 0004294967295 5 0000000012 4 0016777215 4 00000012 3 00065535 3 00012 2 00255 2 The advantage of such a method is that you can easily force the right number of leading zeros with printf format strings. For instance, printf("%010d", an-int32-type) will do the right thing. But we need to communicate that in the spec, and we don't. Thoughts? Take care, Bill P.S. I will be on vacation starting tomorrow through the weekend. From owner-ips@ece.cmu.edu Tue Jul 2 20:23:59 2002 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA24576 for ; Tue, 2 Jul 2002 20:23:59 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id g62NeG304181 for ips-outgoing; Tue, 2 Jul 2002 19:40:16 -0400 (EDT) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from lion.ninthwonder.com (lion.ninthwonder.com [151.199.66.147]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id g62NeEX04176 for ; Tue, 2 Jul 2002 19:40:14 -0400 (EDT) Received: by lion.ninthwonder.com (Postfix, from userid 1021) id BAB6930706; Tue, 2 Jul 2002 19:40:13 -0400 (EDT) Date: Tue, 2 Jul 2002 16:37:13 -0700 (PDT) From: Bill Studenmund X-X-Sender: To: Cc: Subject: RE: iSCSI: leading zeros and decimal-encoded binary strings In-Reply-To: <1BEBA5E8600DD4119A50009027AF54A00CB26D81@axcs04.cos.agilent.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ips@ece.cmu.edu Precedence: bulk On Tue, 2 Jul 2002 pat_thaler@agilent.com wrote: > Bill, > > There is an additional thing I don't like about decimal-encoded binary > strings. We will have to put in support for a feature that is unlikely > to be used. The only items defined as binary-values are CHAP and SRP > binary strings which usually will be too long for decimal encoding > anyway. > > Take CHAP for instance. It C and R are defined as binary-values. R is > 16 bytes so it can't be decimal encoded. C shorter than 8 bytes seems > unlikely. > > My preference would be to replace the definition of binary-value with > the current definition of large-binary value, replace > large-binary-value with binary-value (in 10.2 and 10.3) and get rid of > regular-binary-value and large-binary-value. That's my prefered choice. Take care, Bill From owner-ips@ece.cmu.edu Wed Jul 3 04:00:27 2002 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA01230 for ; Wed, 3 Jul 2002 04:00:26 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id g637C8718652 for ips-outgoing; Wed, 3 Jul 2002 03:12:08 -0400 (EDT) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from d12lmsgate.de.ibm.com (d12lmsgate.de.ibm.com [195.212.91.199]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id g637C6X18647; Wed, 3 Jul 2002 03:12:06 -0400 (EDT) Received: from d12relay01.de.ibm.com (d12relay01.de.ibm.com [9.165.215.22]) by d12lmsgate.de.ibm.com (8.12.3/8.12.3) with ESMTP id g637BxK2007720; Wed, 3 Jul 2002 09:11:59 +0200 Received: from d10hubm1.telaviv.ibm.com (d10ml001.telaviv.ibm.com [9.148.216.55]) by d12relay01.de.ibm.com (8.11.1m3/NCO/VER6.1) with ESMTP id g637BoD125722; Wed, 3 Jul 2002 09:11:58 +0200 Subject: RE: iSCSI: Decimal encoding - why 64 bits ? To: Bill Studenmund Cc: Black_David@emc.com, ips@ece.cmu.edu, "Julian Satran" , owner-ips@ece.cmu.edu X-Mailer: Lotus Notes Release 5.0.9 November 16, 2001 Message-ID: From: "Julian Satran" Date: Wed, 3 Jul 2002 08:23:30 +0300 X-MIMETrack: Serialize by Router on D10ML001/10/M/IBM(Release 5.0.9a |January 7, 2002) at 03/07/2002 10:11:59 MIME-Version: 1.0 Content-type: text/plain; charset=us-ascii Sender: owner-ips@ece.cmu.edu Precedence: bulk Paul argued for base64 not being allowed for numbers and we felt badly about it because numbers might be needed in some cryptography context (i.e., some binary item plus ordering). That is why base64 stayed in for large numbers. There was NEVER a discussion about forbidding decimal for binary items. It would be counterproductive to forbid them as they are so widely used in programming. Julo Bill Studenmund ystems.com> cc: Julian Satran/Haifa/IBM@IBMIL, Sent by: Subject: RE: iSCSI: Decimal encoding - why 64 bits ? owner-ips@ece.cmu .edu 07/03/2002 12:01 AM Please respond to Bill Studenmund On Tue, 2 Jul 2002 Black_David@emc.com wrote: > Easy does it. First of all - if someone will go find the mail > thread that discussed this (I also recall a discussion of > numbers vs. binary items) I'll take a look at it and make a > WG chair determination of what was or was not concluded. Ok, I found some of the confusion. Here's one of Paul's notes at the end of the thread I was remembering: http://www.pdl.cmu.edu/mailinglists/ips/mail/msg10302.html In it he says that he'd like base64 ot be used only for binary strings (not numbers). He also goes on to say, "For all other integer parameters -- which are 64 bit or smaller integers -- permit only hex and decimal.' In http://www.pdl.cmu.edu/mailinglists/ips/mail/msg10303.html, I agreed with both points above. In http://www.pdl.cmu.edu/mailinglists/ips/mail/msg10304.html, Shawn agrees with both myself and Paul, and talks about base64. In http://www.pdl.cmu.edu/mailinglists/ips/mail/msg10319.html, you (David) indicated you saw concensus for the base64 part of Paul's comments. My concusion was that I though we were all agreeing with both parts. I think we definitely got base64, but not so sure about no-decimal-binary-strings. > Kevin's comment that decimal ought to be limited to 32 bits > is still valid at this point - a reference to prior discussions > without specifics isn't enough to dismiss it. My rough > recollection of the discussion partially matches Julian's - > we reduced the required size to 64 bits from unlimited on > the assumption that platforms could cope with this ... and > now Kevin has raised the issue that two platforms he > considers important don't cope well with 64 bit arithmetic. > I don't recall discussion of whether to limit to 32 bits vs. > 64 bits. > > For now, this issue is open. I think this issue is a seperate one. I am fine with 64 bits (as I don't see us needing more than 32 with the present draft) or 32 bits. Take care, Bill From owner-ips@ece.cmu.edu Wed Jul 3 04:03:56 2002 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA01309 for ; Wed, 3 Jul 2002 04:03:56 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id g637C0a18637 for ips-outgoing; Wed, 3 Jul 2002 03:12:00 -0400 (EDT) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from d12lmsgate-3.de.ibm.com (d12lmsgate-3.de.ibm.com [195.212.91.201]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id g637BwX18633 for ; Wed, 3 Jul 2002 03:11:58 -0400 (EDT) Received: from d12relay01.de.ibm.com (d12relay01.de.ibm.com [9.165.215.22]) by d12lmsgate-3.de.ibm.com (8.12.3/8.12.3) with ESMTP id g637Bp2F090670 for ; Wed, 3 Jul 2002 09:11:51 +0200 Received: from d10hubm1.telaviv.ibm.com (d10ml001.telaviv.ibm.com [9.148.216.55]) by d12relay01.de.ibm.com (8.11.1m3/NCO/VER6.1) with ESMTP id g637BoD57072 for ; Wed, 3 Jul 2002 09:11:50 +0200 Subject: RE: iSCSI: Decimal encoding - why 64 bits ? To: ips@ece.cmu.edu X-Mailer: Lotus Notes Release 5.0.9 November 16, 2001 Message-ID: From: "Julian Satran" Date: Wed, 3 Jul 2002 08:16:32 +0300 X-MIMETrack: Serialize by Router on D10ML001/10/M/IBM(Release 5.0.9a |January 7, 2002) at 03/07/2002 10:11:50 MIME-Version: 1.0 Content-type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ece.cmu.edu id g637BxX18634 Sender: owner-ips@ece.cmu.edu Precedence: bulk Content-Transfer-Encoding: 8bit David, I went back to the mailing list - and there was a clear consensus to keep it to 64 bits (my original proposal was unlimited and I suggested rhen 128 to alleviate concerns about conversion difficulty for unlimited numbers). The issue was raised without checking the libraries: In Gnu 64bit integers are fully supported In Windows - here is the quote from MSDN: long-suffix unsigned-suffix(subscript: opt) unsigned-suffix : one of u U long-suffix : one of l L 64-bit integer-suffix : i64 To specify integer constants using octal or hexadecimal notation, use a prefix that denotes the base. To specify an integer constant of a given integral type, use a suffix that denotes the type. To specify a decimal constant, begin the specification with a nonzero digit. For example: int i = 157;   // Decimal constant int j = 0198;  // Not a decimal number; erroneous octal constant int k = 0365;  // Leading zero specifies octal constant, not decimal To specify an octal constant, begin the specification with 0, followed by a sequence of digits in the range 0 through 7. The digits 8 and 9 are errors in specifying an octal constant. For example: int i = 0377; // Octal constant int j = 0397; // Error: 9 is not an octal digit To specify a hexadecimal constant, begin the specification with 0x or 0X (the case of the "x" does not matter), followed by a sequence of digits in the range 0 through 9 and a (or A) through f (or F). Hexadecimal digits a (or A) through f (or F) represent values in the range 10 through 15. For example: int i = 0x3fff; // Hexadecimal constant int j = 0X3FFF; // Equal to i To specify an unsigned type, use either the u or U suffix. To specify a long type, use either the l or L suffix. For example: unsigned uVal = 328u;             // Unsigned value long lVal = 0x7FFFFFL;            // Long value specified                                  //  as hex constant unsigned long ulVal = 0776745ul;  // Unsigned long value I don't know about Windmills - but I assume that most modern development environments are supporting 64bit integers. Are we going to take for granted any assertion made on the list? Julo Black_David@emc.c om To: Julian Satran/Haifa/IBM@IBMIL, ips@ece.cmu.edu cc: 07/02/2002 10:36 Subject: RE: iSCSI: Decimal encoding - why 64 bits ? PM Please respond to Black_David Easy does it. First of all - if someone will go find the mail thread that discussed this (I also recall a discussion of numbers vs. binary items) I'll take a look at it and make a WG chair determination of what was or was not concluded. Kevin's comment that decimal ought to be limited to 32 bits is still valid at this point - a reference to prior discussions without specifics isn't enough to dismiss it. My rough recollection of the discussion partially matches Julian's - we reduced the required size to 64 bits from unlimited on the assumption that platforms could cope with this ... and now Kevin has raised the issue that two platforms he considers important don't cope well with 64 bit arithmetic. I don't recall discussion of whether to limit to 32 bits vs. 64 bits. For now, this issue is open. Thanks, --David -----Original Message----- From: Julian Satran [mailto:Julian_Satran@il.ibm.com] Sent: Tuesday, July 02, 2002 3:23 PM To: ips@ece.cmu.edu Subject: RE: iSCSI: Decimal encoding - why 64 bits ? It was never supposed to be removed. Many values are passed around as decimal. We can't make any progress if we keep hitting the same things again-and-again after a decent consensus has been reached. And none of you has brought an argument that was not heard and dismissed before. Remember we moved from unlimited length decimal to 64 bit to alleviate implementer fears. Julo Bill Studenmund (A-Roseville,ex1)" cc: "LEMAY,KEVIN (A-Roseville,ex1)" , 07/02/2002 10:03 PM Julian Satran/Haifa/IBM@IBMIL, Please respond to Bill Studenmund Subject: RE: iSCSI: Decimal encoding - why 64 bits ? On Tue, 2 Jul 2002, THALER,PAT (A-Roseville,ex1) wrote: > Bill, > > The decimal encoding is not just for numbers. It is also allowed for > binary-values. Both CHAP and SRP exchange items that are identified as > binary-values. In general these will be longer than 64 bits, but in > cases where they are 64 bits or less the decimal encoding is currently > allowed so we would have to support it. I thought we had a big discussion about this, and we decided that decimal was only used for numbers, hex for numbers and binary, and base64 only for binary items. ?? Doh! I just looked in -14, and the text doesn't reflect that understanding. Hmmm. > The issue is that currently decimal encoding is allowed for > binary-values and numbers less than 64 bits. There is little need for > it over 32 bits. We have two other entirely adequate representations > for those numbers. Why have something in there that causes extra code > for no benefit? All I can say is I thought it was removed. :-| Take care, Bill From owner-ips@ece.cmu.edu Wed Jul 3 08:53:47 2002 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA10529 for ; Wed, 3 Jul 2002 08:53:47 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id g63CFx809709 for ips-outgoing; Wed, 3 Jul 2002 08:15:59 -0400 (EDT) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from sj-msg-core-3.cisco.com (sj-msg-core-3.cisco.com [171.70.157.152]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id g63CFvX09701 for ; Wed, 3 Jul 2002 08:15:57 -0400 (EDT) Received: from nisser.cisco.com (nisser.cisco.com [171.71.176.85]) by sj-msg-core-3.cisco.com (8.12.2/8.12.2) with ESMTP id g63CFpvb027346; Wed, 3 Jul 2002 05:15:51 -0700 (PDT) Received: from cisco.com (mbakke@mbakke-lnx.cisco.com [161.44.68.87]) by nisser.cisco.com (8.8.6 (PHNE_14041)/CISCO.SERVER.1.2) with ESMTP id FAA25942; Wed, 3 Jul 2002 05:15:50 -0700 (PDT) Message-ID: <3D22EF29.D3D64420@cisco.com> Date: Wed, 03 Jul 2002 07:33:45 -0500 From: Mark Bakke X-Mailer: Mozilla 4.72 [en] (X11; U; Linux 2.2.16-3.uid32 i686) X-Accept-Language: en, de MIME-Version: 1.0 To: "THALER,PAT (A-Roseville,ex1)" CC: Black_David@emc.com, Julian_Satran@il.ibm.com, ips@ece.cmu.edu Subject: Re: iSCSI: Decimal encoding - why 64 bits ? References: <1BEBA5E8600DD4119A50009027AF54A00CB26D7A@axcs04.cos.agilent.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ips@ece.cmu.edu Precedence: bulk Content-Transfer-Encoding: 7bit Pat- We use hex for binary values; it just made the most sense to us. So I agree that decimal for binary values ought to be eliminated, particularly since they can sometimes be longer than 64 bits, and sometimes shorter. I can't see the value in accepting the same key in one case as a binary string, and another as an integer. In the MIB, any key information (the CHAP and SRP passwords) are configured as octet strings, not integers. Anyway, I'm not necessarily trying to change anything, but if there's an opportunity to decide on when and whether decimal is used, I don't see any use for decimal > 32 bits. -- Mark "THALER,PAT (A-Roseville,ex1)" wrote: > > Mark, > > What about 40-bit to 56-bit decimal encoded binary values? They are allowed. > > 4.1 > binary-value includes regular-binary-value and large-binary-value. > regular-binary-value is for strings less than 64 bits and allows decimal encoding. (It says less than 64 and decimal encoded binary strings are always in bytes so the largest decimal encoded binary would be 56 bits.) > > 10.4 SRP: N,g,s,A,B,M and H(A | M | K) are binary-values > 10.5 CHAP: C and R are binary-values > > 10.2 and 10.3 use large-binary-value instead of binary-value and I can't find any other use of binary-value. > > Normally, the values defined as binary-values for SRP and CHAP would be 64 bits or longer anyway, but someone could send short keys and encode them in decimal according to the current draft. This should be eliminated. > > Regards, > Pat > > -----Original Message----- > From: Mark Bakke [mailto:mbakke@cisco.com] > Sent: Tuesday, July 02, 2002 3:36 PM > To: pat_thaler@agilent.com > Cc: Black_David@emc.com; Julian_Satran@il.ibm.com; ips@ece.cmu.edu > Subject: Re: iSCSI: Decimal encoding - why 64 bits ? > > For what it's worth, none of the numeric values for iSCSI that > can be retrieved or set via the MIB require more than 32 bits > (other than counters, but I doubt we would ever send a counter > during negotiation :-). The allowable ranges just didn't need > more than that. > > Anyway, I haven't seen a need to provide support for 64-bit > values in our implementation yet, since none of the numeric > keys can have values that high. > > -- > Mark A. Bakke > Cisco Systems > mbakke@cisco.com > 763.398.1054 -- Mark A. Bakke Cisco Systems mbakke@cisco.com 763.398.1054 From owner-ips@ece.cmu.edu Wed Jul 3 10:03:18 2002 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA14597 for ; Wed, 3 Jul 2002 10:03:18 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id g63DPQh12493 for ips-outgoing; Wed, 3 Jul 2002 09:25:26 -0400 (EDT) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from cygnus.equallogic.com (cygnus.equallogic.com [65.170.102.10]) by ece.cmu.edu (8.11.0/8.10.2) with SMTP id g63DPOX12489 for ; Wed, 3 Jul 2002 09:25:25 -0400 (EDT) Received: from cygnus.equallogic.com (localhost.localdomain [127.0.0.1]) by cygnus.equallogic.com (8.11.6/8.11.6) with ESMTP id g63DPJC08901 for ; Wed, 3 Jul 2002 09:25:19 -0400 Received: from deneb.dev.equallogic.com (deneb.dev.equallogic.com [172.16.1.99]) by cygnus.equallogic.com (8.11.6/8.11.6) with ESMTP id g63DPIQ08883; Wed, 3 Jul 2002 09:25:18 -0400 Received: from PKONING.equallogic.com (localhost.localdomain [127.0.0.1]) by deneb.dev.equallogic.com (8.11.6/8.11.6) with ESMTP id g63DPGX04538; Wed, 3 Jul 2002 09:25:16 -0400 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <15650.64316.780000.933635@gargle.gargle.HOWL> Date: Wed, 3 Jul 2002 09:25:16 -0400 From: Paul Koning To: pat_thaler@agilent.com Cc: mbakke@cisco.com, Black_David@emc.com, Julian_Satran@il.ibm.com, ips@ece.cmu.edu Subject: RE: iSCSI: Decimal encoding - why 64 bits ? References: <1BEBA5E8600DD4119A50009027AF54A00CB26D7A@axcs04.cos.agilent.com> X-Mailer: VM 6.95 under 21.4 (patch 3) "Academic Rigor" XEmacs Lucid Sender: owner-ips@ece.cmu.edu Precedence: bulk Content-Transfer-Encoding: 7bit Excerpt of message (sent 2 July 2002) by THALER,PAT (A-Roseville,ex1): > 10.4 SRP: N,g,s,A,B,M and H(A | M | K) are binary-values > 10.5 CHAP: C and R are binary-values > > 10.2 and 10.3 use large-binary-value instead of binary-value and I > can't find any other use of binary-value. > > Normally, the values defined as binary-values for SRP and CHAP would > be 64 bits or longer anyway, but someone could send short keys and > encode them in decimal according to the current draft. This should be > eliminated. I agree. Actually, H(A|M|K) in SRP and R in CHAP both can only be large-binary-value since their length is always greater than 8 bytes. The same goes for N and g in SRP (since these systems are all based on modular arithmetic with a modulus of at least several hundred bits). The probability of the other SRP items coming out small enough numerically to fit in 64 bits is essentially zero. It makes no sense for the spec to allow it. In CHAP, C should not be short for the same reason that the password should not be short. So I conclude that there are good technical reasons why all these items must be large-binary-value. paul From owner-ips@ece.cmu.edu Wed Jul 3 10:58:41 2002 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA17312 for ; Wed, 3 Jul 2002 10:58:40 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id g63E9Fd14734 for ips-outgoing; Wed, 3 Jul 2002 10:09:15 -0400 (EDT) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from mailhub.lss.emc.com (xdch.emc.com [168.159.1.79]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id g63E9DX14730 for ; Wed, 3 Jul 2002 10:09:13 -0400 (EDT) Received: from emc.com (emcmail.lss.emc.com [168.159.48.78]) by mailhub.lss.emc.com (Switch-2.2.0/Switch-2.2.0) with ESMTP id g63E94n29755; Wed, 3 Jul 2002 10:09:05 -0400 (EDT) Received: from mxic1.isus.emc.com ([168.159.129.100]) by emc.com (8.10.1/8.10.1) with ESMTP id g63E8m725145; Wed, 3 Jul 2002 10:08:48 -0400 (EDT) Received: by MXIC1 with Internet Mail Service (5.5.2653.19) id <31V075SX>; Wed, 3 Jul 2002 10:06:57 -0400 Message-ID: <277DD60FB639D511AC0400B0D068B71E0564C01F@CORPMX14> From: Black_David@emc.com To: Julian_Satran@il.ibm.com Cc: ips@ece.cmu.edu Subject: RE: iSCSI: Decimal encoding - why 64 bits ? Date: Wed, 3 Jul 2002 10:06:54 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" X-Perlmx-Spam: Gauge=XXXXI, Probability=41%, Report="GAPPY_TEXT, NO_REAL_NAME, SUBJ_ENDS_IN_Q_MARK" Sender: owner-ips@ece.cmu.edu Precedence: bulk Replying to a couple of messages on this topic. --- Use of decimal for binary items > There was NEVER a discussion about forbidding decimal for binary items. Ok, that's why it's now under discussion in WG Last Call. > It would be counterproductive to forbid them as they are so widely > used in programming. The request to forbid them seems to have evolved into a request to more carefully classify binary items into those that can ordinarily be expected to fit in 64 bits (decimal format ok) and those that will generally not fit (decimal format not ok, even if a particular value fits). This is consistent with our restriction of base-64 to large binary items. As Pat Thaler wrote: > 4.1 > binary-value includes regular-binary-value and large-binary-value. > regular-binary-value is for strings less than 64 bits and allows decimal > encoding. (It says less than 64 and decimal encoded binary strings are > always in bytes so the largest decimal encoded binary would be 56 bits.) > > 10.4 SRP: N,g,s,A,B,M and H(A | M | K) are binary-values > 10.5 CHAP: C and R are binary-values The only ones of these that should routinely fit in 64 bits are SRP's g (usually a small integer, even though it's mathematically a member of a very large binary field - I think Paul Koning missed the fact that generators tend to be single-digit numbers) and s (doesn't need to be a large number to get the job done). If any of the others happen to fit in 64 bits, that's a hint that something may be wrong with security (e.g., CHAP's C and R should be 128 bits - if either has 64 bits of leading zeroes, something's probably wrong). On this basis, I'm inclined to agree with Pat that: > Normally, the values defined as binary-values for SRP and CHAP would be > 64 bits or longer anyway, but someone could send short keys and encode > them in decimal according to the current draft. This should be eliminated. I would make an exception to allow decimal for SRP's g and possibly SRP's s for the sort of convenience reason that Julian gave above ("widely used in programming"). I'd recommend this change to large-binary-value with the exception of SRP's g and possibly SRP's s as the way forward. --- 64 vs. 32 bits > I went back to the mailing list - and there was a clear consensus to keep > it to 64 bits (my original proposal was unlimited and I suggested rhen 128 > to alleviate concerns about conversion difficulty for unlimited numbers). That matches what I recall from mailing list discussion, 32 bits was not considered at the time. > The issue was raised without checking the libraries: [... snip ...] > I don't know about Windmills - but I assume that most modern development > environments are supporting 64bit integers. I suspect the response to this is that not everyone is using a "modern development environment" ... ;-) > Are we going to take for granted any assertion made on the list? Yes and no. When someone working on an implementation reports that some aspect of the protocol spec is causing difficulty, we should at least believe that the person is in fact having some difficulty. Whether we should accept arbitrary proposals to remove difficulty is a different question (iSCSI is not a simple protocol - some things are going to be difficult/tricky to implement - TANSTAAFL*). On this particular issue, I don't see support for or the need to reduce the upper limit on size of numbers that can be encoded in decimal from 64 bits to 32 bits, but the US holiday is starting to get in the way of list discussion. What this would mean for implementers is that the string decoding logic must be able to handle decimal representations of integers that fit in 64 bits, but an implementation may restrict the allowed ranges of the values (negotiated for keys) to fit in 32 bits. This roughly matches what Mark Bakke described: > For what it's worth, none of the numeric values for iSCSI that > can be retrieved or set via the MIB require more than 32 bits > (other than counters, but I doubt we would ever send a counter > during negotiation :-). The allowable ranges just didn't need > more than that. > > Anyway, I haven't seen a need to provide support for 64-bit > values in our implementation yet, since none of the numeric > keys can have values that high. Allowing decimal values to go up to 64 bits in size strikes me as a reasonable "future-proofing" measure - in 20/20 hindsight, I would think that the SNMP folks wish they'd put 64 bit support into SMIv1/SNMPv1 even if there had been little use for it at the time. So, this change (64 to 32 bits) does not need to be made now, but I will be watching the mailing list early next week just in case some people who care about this have already signed off for the US holiday and have additional input to contribute. Thanks, --David p.s. * TANSTAAFL = There Ain't No Such Thing As A Free Lunch --------------------------------------------------- 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 --------------------------------------------------- From owner-ips@ece.cmu.edu Wed Jul 3 12:03:38 2002 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA19675 for ; Wed, 3 Jul 2002 12:03:38 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id g63FpTh20461 for ips-outgoing; Wed, 3 Jul 2002 11:51:29 -0400 (EDT) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from cygnus.equallogic.com (cygnus.equallogic.com [65.170.102.10]) by ece.cmu.edu (8.11.0/8.10.2) with SMTP id g63FpSX20456 for ; Wed, 3 Jul 2002 11:51:28 -0400 (EDT) Received: from cygnus.equallogic.com (localhost.localdomain [127.0.0.1]) by cygnus.equallogic.com (8.11.6/8.11.6) with ESMTP id g63FpMC12103 for ; Wed, 3 Jul 2002 11:51:22 -0400 Received: from deneb.dev.equallogic.com (deneb.dev.equallogic.com [172.16.1.99]) by cygnus.equallogic.com (8.11.6/8.11.6) with ESMTP id g63FpMQ12097 for ; Wed, 3 Jul 2002 11:51:22 -0400 Received: from PKONING.equallogic.com (localhost.localdomain [127.0.0.1]) by deneb.dev.equallogic.com (8.11.6/8.11.6) with ESMTP id g63FpLq10665 for ; Wed, 3 Jul 2002 11:51:22 -0400 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <15651.7545.984000.314648@gargle.gargle.HOWL> Date: Wed, 3 Jul 2002 11:51:21 -0400 From: Paul Koning To: ips@ece.cmu.edu Subject: IPS security draft: SRP groups X-Mailer: VM 6.95 under 21.4 (patch 3) "Academic Rigor" XEmacs Lucid Sender: owner-ips@ece.cmu.edu Precedence: bulk Content-Transfer-Encoding: 7bit The security draft lists the groups from the SRP reference software, and in addition it says that the IKE groups may be used. (It doesn't appear to allow the 768 bit IKE group, even though it does allow the 768 bit group from the SRP reference code. I wonder why.) Tom Wu said in a message dated 4/17/2002: g MUST be a generator; omitting half of the possible residues mod P is NOT a virtue for SRP because it can lead to an attack. For the IKE moduli, which are all 7 mod 8, g cannot be 2, and it usually ends up being either 5 or 7. g^((N-1)/2) must be -1 (mod N). This means that the IKE groups cannot be used as they are defined in the references given, because those do use the value g == 2 (for reasons that apply to IKE but not to SRP). Incidentally, the IKE groups come fully documented with a statement that N was proven (rigorously, not probabilistically) to be prime; I haven't found the equivalent for the SRP groups. Does that exist? If yes, it would be useful to have a reference pointing to it. Does the statement in section 2.4.2 (verifying N and g) mean: a. An implementation may match N and g against the list in Appendix A and refuse any others or b. An implementation may match N and g against the list in Appendix A but on a mismatch is required to verify that N and g define a valid group ? The text says "MAY start..." which seems to suggest (b). But (b) is very expensive, and it doesn't seem to be a good idea to mandate (or even encourage) a denial of service opportunity like that. paul From owner-ips@ece.cmu.edu Wed Jul 3 12:04:51 2002 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA19755 for ; Wed, 3 Jul 2002 12:04:50 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id g63FOVV19037 for ips-outgoing; Wed, 3 Jul 2002 11:24:31 -0400 (EDT) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from cygnus.equallogic.com (cygnus.equallogic.com [65.170.102.10]) by ece.cmu.edu (8.11.0/8.10.2) with SMTP id g63FOUX19032 for ; Wed, 3 Jul 2002 11:24:30 -0400 (EDT) Received: from cygnus.equallogic.com (localhost.localdomain [127.0.0.1]) by cygnus.equallogic.com (8.11.6/8.11.6) with ESMTP id g63FOOC11234 for ; Wed, 3 Jul 2002 11:24:24 -0400 Received: from deneb.dev.equallogic.com (deneb.dev.equallogic.com [172.16.1.99]) by cygnus.equallogic.com (8.11.6/8.11.6) with ESMTP id g63FOOQ11222; Wed, 3 Jul 2002 11:24:24 -0400 Received: from PKONING.equallogic.com (localhost.localdomain [127.0.0.1]) by deneb.dev.equallogic.com (8.11.6/8.11.6) with ESMTP id g63FONP08961; Wed, 3 Jul 2002 11:24:24 -0400 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <15651.5928.288000.978292@gargle.gargle.HOWL> Date: Wed, 3 Jul 2002 11:24:24 -0400 From: Paul Koning To: Black_David@emc.com Cc: Julian_Satran@il.ibm.com, ips@ece.cmu.edu Subject: RE: iSCSI: Decimal encoding - why 64 bits ? References: <277DD60FB639D511AC0400B0D068B71E0564C01F@CORPMX14> X-Mailer: VM 6.95 under 21.4 (patch 3) "Academic Rigor" XEmacs Lucid Sender: owner-ips@ece.cmu.edu Precedence: bulk Content-Transfer-Encoding: 7bit Excerpt of message (sent 3 July 2002) by Black_David@emc.com: > Replying to a couple of messages on this topic. > > --- Use of decimal for binary items > ... > > 4.1 > > binary-value includes regular-binary-value and large-binary-value. > > regular-binary-value is for strings less than 64 bits and allows decimal > > encoding. (It says less than 64 and decimal encoded binary strings are > > always in bytes so the largest decimal encoded binary would be 56 bits.) > > > > 10.4 SRP: N,g,s,A,B,M and H(A | M | K) are binary-values > > 10.5 CHAP: C and R are binary-values > > The only ones of these that should routinely fit in 64 bits are SRP's > g (usually a small integer, even though it's mathematically a member of > a very large binary field - I think Paul Koning missed the fact that > generators tend to be single-digit numbers) and s (doesn't need to be > a large number to get the job done). You're right about g. As for S, it's the result of an exponentiation modulo N, so it's no more likely to be a small integer than the other SRP intermediate values. Note that values supplied by the other end are involved (as in conventional D-H) so you don't have the ability to constrain your implementation to produce small S values. In other words, S, A, and B will be bignums with probability essentialy == 1.0, and allowing them ever to be encoded other than by the large-binary-value rules is a waste of effort. paul From owner-ips@ece.cmu.edu Wed Jul 3 12:05:10 2002 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA19777 for ; Wed, 3 Jul 2002 12:05:10 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id g63FYZg19621 for ips-outgoing; Wed, 3 Jul 2002 11:34:35 -0400 (EDT) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from d12lmsgate-2.de.ibm.com (d12lmsgate-2.de.ibm.com [195.212.91.200]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id g63FYWX19617 for ; Wed, 3 Jul 2002 11:34:32 -0400 (EDT) Received: from d12relay01.de.ibm.com (d12relay01.de.ibm.com [9.165.215.22]) by d12lmsgate-2.de.ibm.com (8.12.3/8.12.3) with ESMTP id g63FYMpk010796; Wed, 3 Jul 2002 17:34:22 +0200 Received: from d10hubm1.telaviv.ibm.com (d10ml001.telaviv.ibm.com [9.148.216.55]) by d12relay01.de.ibm.com (8.11.1m3/NCO/VER6.1) with ESMTP id g63FYLD66754; Wed, 3 Jul 2002 17:34:21 +0200 To: pat_thaler@agilent.com Cc: ips@ece.cmu.edu MIME-Version: 1.0 Subject: RE: iSCSI: Login negotiation space X-Mailer: Lotus Notes Release 5.0.9 November 16, 2001 From: "Julian Satran" Message-ID: Date: Wed, 3 Jul 2002 18:34:19 +0300 X-MIMETrack: Serialize by Router on D10ML001/10/M/IBM(Release 5.0.9a |January 7, 2002) at 03/07/2002 18:34:21, Serialize complete at 03/07/2002 18:34:21 Content-Type: multipart/alternative; boundary="=_alternative 00550B9FC2256BEB_=" Sender: owner-ips@ece.cmu.edu Precedence: bulk This is a multipart message in MIME format. --=_alternative 00550B9FC2256BEB_= Content-Type: text/plain; charset="us-ascii" Pat, 4k does not make too much sense either with default PDU size of 8k. Are you suggesting we limit this too to a lower value? Your deadlock example while academically correct is not very interesting as I assume that throttling can be done at the first buffer level. Julo pat_thaler@agilent.com Sent by: owner-ips@ece.cmu.edu 07/03/2002 01:08 AM Please respond to pat_thaler To: "Julian Satran" , ips@ece.cmu.edu cc: Subject: RE: iSCSI: Login negotiation space Julian, There is a separate number for cases where very long authentication items are supported and I haven't asked to change that number. Remember the text is: Any iSCSI target or initiator MUST support receiving at least 16384 bytes of key=value data in a negotiation sequence except when indicating support for very long authentication items by offering or selecting authentication methods such as public key certificates in which case they MUST support receiving at least 64 kilobytes of key=value data. Changing the 16384 number on the first line to 4096 will have no effect on the 64 kilobytes limit on the last line and implementations desiring to support very long authentication items are covered. 4k works fine for the required CHAP authentication and there is no reason to require 16k. Controlling memory by delaying negotiation with some parties as memory fills is an unnecessary complication which can result in deadlocks. If one does what you suggest and throttles keys "as you have unprocessed keys exceeding the mount of memory you want to keep aside", then you may get to that point but find that none of the keys you have are processable - the C bit is set and you need to get some more packets before you can process. One could throttle just some logins when one has enough memory left to complete some but not all of the negotiations, but there is a risk of deadlock. A simple example: Target X decides to stall negotiation from Initiator B until negotiation from Initiator A completes freeing buffer. Initiator A has stalled negotiation with Target X until negotiation with Target Y completes freeing buffer. Target Y has stalled negotiation with Initiator A until negotiation with Initiator B completes. Initiator B has stalled negotiation with Target Y until negotiation with Target X completes. They are all stalled until one or more of the logins times out. It is much safer and simpler to set the required memory size to a reasonable limit for the mandatory negotiation items plus some comfortable room for expansion. Regards, Pat -----Original Message----- From: Julian Satran [mailto:Julian_Satran@il.ibm.com] Sent: Tuesday, July 02, 2002 12:36 PM To: ips@ece.cmu.edu Subject: RE: iSCSI: Login negotiation space Pat, 4k is absurd. We have the security guys asking for 64k certificates! And the PDUlength default is 8k! Besides you can control the total memory consumed by throttling login as soon as you have unprocessed keys exceeding the mount of memory you want to keep aside (you control the login progress by delaying requests/responses). Julo pat_thaler@agilent.com 07/02/2002 10:02 PM Please respond to pat_thaler To: Julian Satran/Haifa/IBM@IBMIL, pat_thaler@agilent.com cc: ips@ece.cmu.edu Subject: RE: iSCSI: Login negotiation space Julian, A factor of 10 is way overkill. It isn't just 16 k bytes of extra memory. It is n * 16k where n is the number of simultaneous logins the implementation supports - it adds up. The system vendors we work with want to use the memory to do useful work and demand that driver sizes be kept small -- they want the memory available to do "real" work. If 2k doesn't leave enough headroom, then we could live with somewhat more like 4k. If future features added to iSCSI require more space, the drivers that support that can allocate more memory. It is an internal parameter that can be changed when the need arises. There is no future interoperability need to make the buffer oversized in current implementations. Regards, Pat -----Original Message----- From: Julian Satran [mailto:Julian_Satran@il.ibm.com] Sent: Tuesday, July 02, 2002 12:10 AM To: pat_thaler@agilent.com Cc: ips@ece.cmu.edu Subject: RE: iSCSI: Login negotiation space Pat, A factor of 10 over what is needed today is what I would call a conservative design. Limiting the support to 2k would be extremely unwise. And 16 is a tiny amount of memory - of no concern to software implementation and to most hardware implementations. Julo pat_thaler@agilent.com 07/02/2002 01:56 AM Please respond to pat_thaler To: Julian Satran/Haifa/IBM@IBMIL cc: ips@ece.cmu.edu Subject: RE: iSCSI: Login negotiation space Julian, 4.1 contains a requirement that initiators and targets support receiving at least 16384 bytes of key=value data (when not supporting very long authentication items). This is overkill and is making drivers larger than they need to be. My calculations are that Security negotiation using the CHAP method (including the Any-stage keys) takes less than 1600 bytes. Operational negotiation requires 1276 bytes (also including the Any-stage keys). All the operational plus security keys are 1911 bytes. Therefore an implementation could hold all the necessary keys in 2 Kbytes. And, the implementation doesn't need to keep the security keys after the security negotiation is done so it could clear some of that out to make room for future keys or vendor specific keys. 16 K bytes is about 10 times the necessary storage in that case. The number of negotiation bytes that a device is required to support should be reduced substantially - preferably to 2048 bytes. Regards, Pat The numbers: 43 AuthMethod CHAP keys 264 Name (no defined size limit - using 255) 11 Algorithm 11 Identifier 264 Challenge 42 Response (for MD5) _____ 635 Chap negotiation length 892 Any-stage keys ---- 1527 Operational negotiation keys 24 HeaderDigest 24 DataDigest 49 MaxConnections 270 TargetName* or InitiatorName* 271 TargetAlias* or InitiatorAlias* 273 TargetAddress* 55 TargetPortalGroupTag* 15 InitialR2T 19 BidiInitialR2T 18 ImmediateData 34 MaxRecvDataSegmentLength 24 MaxBurstLength 26 FirstBurstLength 24 DefaultTime2Wait 26 DefaultTime2Retain 25 MaxOutstandingR2T 18 DataPDUInOrder 24 DataSequenceInOrder 24 ErrorRecoveryLevel 23 SessionType* ------ 892 Any-stage keys 384 Not Any-stage ------ 1276 Operational keys --=_alternative 00550B9FC2256BEB_= Content-Type: text/html; charset="us-ascii"
Pat,

4k does not make too much sense either with default PDU size of 8k.
Are you suggesting we limit this too to a lower value?
Your deadlock example while academically correct is not very interesting as I assume that throttling can be done at the first buffer level.

Julo



pat_thaler@agilent.com
Sent by: owner-ips@ece.cmu.edu

07/03/2002 01:08 AM
Please respond to pat_thaler

       
        To:        "Julian Satran" <Julian_Satran@il.ibm.com>, ips@ece.cmu.edu
        cc:        
        Subject:        RE: iSCSI: Login negotiation space

       


Julian,
 
There is a separate number for cases where very long authentication items are supported and I haven't asked to change that number.
 
Remember the text is:

Any iSCSI target or initiator MUST support receiving at least 16384 bytes of key=value data in a negotiation sequence except when indicating support for very long authentication items by offering or selecting authentication methods such as public key certificates in which case they MUST support receiving at least 64 kilobytes of key=value data.

Changing the 16384 number on the first line to 4096 will have no effect on the 64 kilobytes limit on the last line and implementations desiring to support very long authentication items are covered.
 
4k works fine for the required CHAP authentication and there is no reason to require 16k. Controlling memory by delaying negotiation with some parties as memory fills is an unnecessary complication which can result in deadlocks.
 
If one does what you suggest and throttles keys "as you have unprocessed keys exceeding the mount of memory you want to keep aside", then you may get to that point but find that none of the keys you have are processable - the C bit is set and you need to get some more packets before you can process.
 
One could throttle just some logins when one has enough memory left to complete some but not all of the negotiations, but there is a risk of deadlock. A simple example: Target X decides to stall negotiation from Initiator B until negotiation from Initiator A completes freeing buffer. Initiator A has stalled negotiation with Target X until negotiation with Target Y completes freeing buffer. Target Y has stalled negotiation with Initiator A until negotiation with Initiator B completes. Initiator B has stalled negotiation with Target Y until negotiation with Target X completes. They are all stalled until one or more of the logins times out.
 
It is much safer and simpler to set the required memory size to a reasonable limit for the mandatory negotiation items plus some comfortable room for expansion.
 
Regards,
Pat
 
-----Original Message-----
From: Julian Satran [mailto:Julian_Satran@il.ibm.com]
Sent: Tuesday, July 02, 2002 12:36 PM
To: ips@ece.cmu.edu
Subject: RE: iSCSI: Login negotiation space

Pat,

4k is absurd. We have the security guys asking for 64k certificates!
And the PDUlength default is 8k!
Besides you can control the total memory consumed by throttling login as soon as you have unprocessed keys exceeding the mount of memory you want to keep aside (you control the login progress by delaying requests/responses).


Julo

pat_thaler@agilent.com

07/02/2002 10:02 PM
Please respond to pat_thaler

       
       To:        Julian Satran/Haifa/IBM@IBMIL, pat_thaler@agilent.com
       cc:        ips@ece.cmu.edu
       Subject:        RE: iSCSI: Login negotiation space

     



Julian,
 
A factor of 10 is way overkill. It isn't just 16 k bytes of extra memory. It is n * 16k where n is the number of simultaneous logins the implementation supports - it adds up. The system vendors we work with want to use the memory to do useful work and demand that driver sizes be kept small -- they want the memory available to do "real" work.
 
If 2k doesn't leave enough headroom, then we could live with somewhat more like 4k.
 
If future features added to iSCSI require more space, the drivers that support that can allocate more memory. It is an internal parameter that can be changed when the need arises. There is no future interoperability need to make the buffer oversized in current implementations.
 
Regards,
Pat
 
-----Original Message-----
From: Julian Satran [mailto:Julian_Satran@il.ibm.com]
Sent: Tuesday, July 02, 2002 12:10 AM
To: pat_thaler@agilent.com
Cc: ips@ece.cmu.edu
Subject: RE: iSCSI: Login negotiation space


Pat,

A factor of 10 over what is needed today is what I would call a conservative design.
Limiting the support to 2k would be extremely unwise.
And 16 is a tiny amount of memory - of no concern to software implementation and to most hardware implementations.

Julo

pat_thaler@agilent.com

07/02/2002 01:56 AM
Please respond to pat_thaler

       
      To:        Julian Satran/Haifa/IBM@IBMIL
      cc:        ips@ece.cmu.edu
      Subject:        RE: iSCSI: Login negotiation space

     




Julian,

4.1 contains a requirement that initiators and targets support receiving at least 16384 bytes of key=value data (when not supporting very long authentication items). This is overkill and is making drivers larger than they need to be.

My calculations are that Security negotiation using the CHAP method (including the Any-stage keys) takes less than 1600 bytes. Operational negotiation requires 1276 bytes (also including the Any-stage keys). All the operational plus security keys are 1911 bytes.

Therefore an implementation could hold all the necessary keys in 2 Kbytes. And, the implementation doesn't need to keep the security keys after the security negotiation is done so it could clear some of that out to make room for future keys or vendor specific keys. 16 K bytes is about 10 times the necessary storage in that case.

The number of negotiation bytes that a device is required to support should be reduced substantially - preferably to 2048 bytes.

Regards,
Pat


The numbers:

43                                  AuthMethod
        CHAP keys
264                                  Name (no defined size limit - using 255)
11                                  Algorithm
11                                  Identifier
264                                  Challenge
42                                  Response (for MD5)
_____
635 Chap negotiation length
892 Any-stage keys
----
1527

Operational negotiation keys
24                                  HeaderDigest
24        DataDigest
49        MaxConnections
270                                  TargetName* or InitiatorName*
271                                  TargetAlias* or InitiatorAlias*
273        TargetAddress*
55                                  TargetPortalGroupTag*
15                                  InitialR2T
19                                  BidiInitialR2T
18                                  ImmediateData
34                                  MaxRecvDataSegmentLength
24                                  MaxBurstLength
26                                  FirstBurstLength
24                                  DefaultTime2Wait
26                                  DefaultTime2Retain
25                                  MaxOutstandingR2T
18                                  DataPDUInOrder
24                                  DataSequenceInOrder
24                                  ErrorRecoveryLevel
23                                  SessionType*
------
892 Any-stage keys
384 Not Any-stage
------
1276 Operational keys





--=_alternative 00550B9FC2256BEB_=-- From owner-ips@ece.cmu.edu Wed Jul 3 13:04:03 2002 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA22043 for ; Wed, 3 Jul 2002 13:04:03 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id g63Gg7P23132 for ips-outgoing; Wed, 3 Jul 2002 12:42:07 -0400 (EDT) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from d12lmsgate-3.de.ibm.com (d12lmsgate-3.de.ibm.com [195.212.91.201]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id g63Gg5X23123 for ; Wed, 3 Jul 2002 12:42:05 -0400 (EDT) Received: from d12relay02.de.ibm.com (d12relay02.de.ibm.com [9.165.215.23]) by d12lmsgate-3.de.ibm.com (8.12.3/8.12.3) with ESMTP id g63Gfx2F027396 for ; Wed, 3 Jul 2002 18:41:59 +0200 Received: from d10hubm1.telaviv.ibm.com (d10ml001.telaviv.ibm.com [9.148.216.55]) by d12relay02.de.ibm.com (8.11.1m3/NCO/VER6.1) with ESMTP id g63Gfw7109766 for ; Wed, 3 Jul 2002 18:41:58 +0200 To: ips@ece.cmu.edu MIME-Version: 1.0 Subject: iSCSI - WG Last Call - list of issues and their resolution X-Mailer: Lotus Notes Release 5.0.9 November 16, 2001 From: "Julian Satran" Message-ID: Date: Wed, 3 Jul 2002 19:41:57 +0300 X-MIMETrack: Serialize by Router on D10ML001/10/M/IBM(Release 5.0.9a |January 7, 2002) at 03/07/2002 19:41:58, Serialize complete at 03/07/2002 19:41:58 Content-Type: multipart/alternative; boundary="=_alternative 005AFDFFC2256BEB_=" Sender: owner-ips@ece.cmu.edu Precedence: bulk This is a multipart message in MIME format. --=_alternative 005AFDFFC2256BEB_= Content-Type: text/plain; charset="us-ascii" Dear colleagues, I have posted on my web-site (http://www.haifa.il.ibm.com/satran/ips/) a list of issues raised since publication of draft-13. The list has a brief description of the issue and the resolution (if a consensus was reached) or the word Open if not. I have also posted a pdf file containing the "working" version for draft-15 so that you can follow the exact words for the an issue resolution. I will attempt to keep this list updated daily (if updates are needed). Julo --=_alternative 005AFDFFC2256BEB_= Content-Type: text/html; charset="us-ascii"

Dear colleagues,

I have posted on my web-site (http://www.haifa.il.ibm.com/satran/ips/) a list of issues raised since publication of draft-13.
The list has a brief description of the issue and the resolution (if a consensus was reached) or the word Open if not.

I have also posted a pdf file containing the "working" version for draft-15 so that you can follow the exact words for the
an issue resolution.

I will attempt to keep this list updated daily (if updates are needed).

Julo
--=_alternative 005AFDFFC2256BEB_=-- From owner-ips@ece.cmu.edu Wed Jul 3 13:07:20 2002 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA22133 for ; Wed, 3 Jul 2002 13:07:19 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id g63GKHI21930 for ips-outgoing; Wed, 3 Jul 2002 12:20:17 -0400 (EDT) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from d12lmsgate.de.ibm.com (d12lmsgate.de.ibm.com [195.212.91.199]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id g63GKEX21925 for ; Wed, 3 Jul 2002 12:20:15 -0400 (EDT) Received: from d12relay01.de.ibm.com (d12relay01.de.ibm.com [9.165.215.22]) by d12lmsgate.de.ibm.com (8.12.3/8.12.3) with ESMTP id g63GK8IB040648; Wed, 3 Jul 2002 18:20:08 +0200 Received: from d10hubm1.telaviv.ibm.com (d10ml001.telaviv.ibm.com [9.148.216.55]) by d12relay01.de.ibm.com (8.11.1m3/NCO/VER6.1) with ESMTP id g63GK6D83008; Wed, 3 Jul 2002 18:20:07 +0200 To: =?iso-8859-1?Q?Tom=E1=3F_Bartu=3Fek?= Cc: ips@ece.cmu.edu, ivan.pavelka@s3group.com MIME-Version: 1.0 Subject: Re: iSCSI: draft vs. 14 typos, suggestion, questions X-Mailer: Lotus Notes Release 5.0.9 November 16, 2001 From: "Julian Satran" Message-ID: Date: Wed, 3 Jul 2002 19:20:05 +0300 X-MIMETrack: Serialize by Router on D10ML001/10/M/IBM(Release 5.0.9a |January 7, 2002) at 03/07/2002 19:20:07, Serialize complete at 03/07/2002 19:20:07 Content-Type: multipart/alternative; boundary="=_alternative 00591BE6C2256BEB_=" Sender: owner-ips@ece.cmu.edu Precedence: bulk This is a multipart message in MIME format. --=_alternative 00591BE6C2256BEB_= Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Thanks - comments in text - Julo Tom=E1? Bartu?ek 07/03/2002 02:38 PM Please respond to Tom=E1? Bartu?ek =20 To: Julian Satran/Haifa/IBM@IBMIL cc: ips@ece.cmu.edu, ivan.pavelka@s3group.com Subject: iSCSI: draft vs. 14 typos, suggestion, questions =20 Hello Julian! We'd like to inform you about some TYPO errors, some SUGGESTIONS to clarify something / explain something better and also to ask few QUESTIONS (and sorry for so long email). *** Section 4.3 : TYPO & SUGGESTION In draft vs. 14 possibility to negotiate some parameters (e.g. TargetAddress) more than once. Vs. 14 says: Neither the initiator nor the target should attempt to declare or negotiate a parameter more than once during login except for responses to specific keys that explicitly allow repeated key decla- rations (e.g. TargetAddress). If detected by the target this MUST result in a Login reject (initiator error). The initiator MUST drop the connection TYPO: Missing fullstop at the end of a paragraph. Vs. 13 said: Neither the initiator nor the target should attempt to negotiate a parameter more than once during login. If detected by the target this MUST result in a Login reject (initiator error). The initiator MUST drop the connection. SUGGESTION: However the change resulted in badly-readable paragraph, because the reader can be confused and think, that sentence "If detected ... MUST result in Login reject" is applicable to parameters, for which "repeated key declaration IS allowed". I would suggest to write "attempt to re-negotiated other parameter" instead of "this" in that sentence. +++ How about the text: Neither the initiator nor the target should attempt to declare or=20 negotiate a parameter more than once during login except for responses to=20 specific keys that explicitly allow repeated key decla-rations (e.g.=20 TargetAddress). If an attempt to re-negotiate/re-declare parameters not=20 speciffically allowed is detected by the tar-get the target MUST respond=20 with Login reject (initiator error); if detected by the initiator the=20 initiator MUST drop the connection. =20 +++ *** Section 6.5 : TYPO & SUGGESTION TYPO: In paragraph explaining initator behaviour bad ALIGN (possibilities a) and b) not aligned verticaly! SUGGESTION: We would recommend to move explanation of target's SNACK processing into the chapter about SNACK. Here it could be/is confusing - We would say, that target's reaction to recieved SNACK is not dependent on whether initiator sends this SNACK in response to corrupted-digest data PDU or from (any) other reason. Or is it? */ +++I do not see the missalignment and I do not understand the comment The behaviour on SNACK is specific to this case and it outlines the things = target has to do depending on the target state +++ *** Section 6.11 : TYPO (probably) TYPO: What does "initiators detect protocol errors ..." mean in the first paragraph of section 6.11? Do initiators communicate to each other?? If not, I would suggest rather "initiator detects ...". +++ will fix text +++ *** Section 6.11 : QUESTION Draft says: When the session timeout (the connection state timeout for the last failed connection) happens on the target, it takes the following actions: - Resets or closes the TCP connections (closes the session). - Aborts all Tasks in the task set for the corresponding initi- ator. What does the "corresponding initiator" mean? We think (:-)), that there is only one initiator for the session. The only possible explanation we see for that paragraph is, that the target should abort also other tasks of the same in =5F=5Fother=5F=5F sessions, but why? +++ your interpretation is correct - the statement means the initiator=20 that "owned" the session. Are you suggesting other wording? ++++ *** Section 6.12.1 : TYPO In sentence "Sequence reception timeout is generally a large enough value to allow the data sequence transfer to be com- plete." should be "completed" instead, (at least IMHO). +++ will foix +++ *** Section 6.13 : TYPO "Digest failure recovery is comprises ... " is TYPO IMHO. I would say "Digest failure recovery comprises ..." only. +++ will fix text +++ Best regards & Thanks for replay in advance Tomas Bartusek & Ivan Pavelka -------------------------------------- Tomas Bartusek SW Engineer Tomas.Bartusek@s3group.com Tel:+420-2-33099184 Silicon & Software Systems www.s3group.com Fax:+420-2-33099151 Philips building, Safrankova 1, 155 00 Prague 5, Czech Republic --=_alternative 00591BE6C2256BEB_= Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
Thanks - comments in text - Julo


Tom=E1š Bartušek <to= masb@s3group.cz>

07/03/2002 02:38 PM
Please respond to Tom=E1š Bartu= šek

       
        To: &nbs= p;      Julian Satran/Haifa/IBM@IBMIL
        cc: &nbs= p;      ips@ece.cmu.edu, ivan.pavelka@s3group.com
        Subject:=        iSCSI: draft vs. 14 typos, suggestion, question= s

       


   Hello Julian!

We'd like to inform you about some TYPO errors, some
SUGGESTIONS to clarify something / explain something
better and also to ask few QUESTIONS (and sorry for so long
email).

*** Section 4.3 : TYPO & SUGGESTION
In draft vs. 14 possibility to negotiate some parameters
(e.g. TargetAddress) more than once.

Vs. 14 says:
   Neither the initiator nor the target should attempt to declar= e or
   negotiate a parameter more than once during login except for<= br>    responses to specific keys that explicitly allow repeated key= decla-
   rations (e.g. TargetAddress). If detected by the target this = MUST
   result in a Login reject (initiator error). The initiator MUS= T drop
   the connection
TYPO: Missing fullstop at the end of a paragraph.

Vs. 13 said:
   Neither the initiator nor the target should attempt to negoti= ate a
   parameter more than once during login. If detected by the tar= get this
   MUST result in a Login reject (initiator error). The initiato= r MUST
   drop the connection.

SUGGESTION: However the change resulted in badly-readable paragraph,
because the reader can be confused and think, that sentence "If
detected ... MUST result in Login reject" is applicable to parameters,=
for which "repeated key declaration IS allowed". I would suggest = to
write "attempt to re-negotiated other parameter" instead of "= ;this" in
that sentence.
+++

How about the text:

Neither the initiator nor the targe= t should attempt to declare or negotiate a parameter more than once during = login except for responses to specific keys that explicitly allow repeated = key decla-rations (e.g. TargetAddress). If an attempt to re-negotiate/re-de= clare parameters  not speciffically allowed is detected by the tar-get= the target MUST respond with Login reject (initiator error); if detected b= y the initiator the initiator MUST drop the connection.
 

+++
*** Section 6.5  : TYPO & SUGGESTION
TYPO: In paragraph explaining initator behaviour
bad ALIGN (possibilities a) and b) not aligned verticaly!
SUGGESTION: We would recommend to move explanation of
target's SNACK processing into the chapter about SNACK. Here
it could be/is confusing - We would say, that target's reaction
to recieved SNACK is not dependent on whether initiator sends
this SNACK in response to corrupted-digest data PDU or from
(any) other reason. Or is it? */
+++I do not see the missalignment and I do not understand the comment
The behaviour on SNACK is specific = to this case and it outlines the things target has to do depending on the t= arget state
+++
*** Section 6.11 : TYPO
(probably) TYPO: What does "initiators detect protocol errors ..."= ; mean
in the first paragraph of section 6.11? Do initiators communicate to each other?? If not, I would suggest rather "initiator detects ...". +++ will fix text +++
*** Section 6.11 : QUESTION
Draft says:
  When the session timeout (the connection state timeout for the last=
  failed connection) happens on the target, it takes the following
  actions:

    - Resets or closes the TCP connections (closes the session).=
    - Aborts all Tasks in the task set for the corresponding ini= ti-
      ator.

What does the "corresponding initiator" mean? We think (:-)), tha= t
there is only one initiator for the session. The only possible
explanation we see for that paragraph is, that the target should
abort also other tasks of the same in =5F=5Fother=5F=5F sessions, but
why?
+++ your interpretation is correct - the statement means the initiator that= "owned" the session.
Are you suggesting other wording?
++++
*** Section 6.12.1 : TYPO
In sentence "Sequence reception timeout is generally a
  large enough value to allow the data sequence transfer to be com-   plete."
should be "completed" instead, (at least IMHO).
+++ will foix +++
*** Section 6.13 : TYPO
"Digest failure recovery is comprises ... " is TYPO IMHO. I would= say
"Digest failure recovery comprises ..." only.
+++ will fix text +++
Best regards
&
Thanks for replay in advance

Tomas Bartusek & Ivan Pavelka

--------------------------------------
Tomas Bartusek

SW Engineer
Tomas.Bartusek@s3group.com

Tel:+420-2-33099184

Silicon & Software Systems     www.s3group.com     =   Fax:+420-2-33099151
Philips building, Safrankova 1, 155 00 Prague 5, Czech Republic

--=_alternative 00591BE6C2256BEB_=-- From owner-ips@ece.cmu.edu Wed Jul 3 14:55:08 2002 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA29134 for ; Wed, 3 Jul 2002 14:55:08 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id g63I9f127392 for ips-outgoing; Wed, 3 Jul 2002 14:09:41 -0400 (EDT) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from msgbas2.cos.agilent.com (msgbas2x.cos.agilent.com [192.25.240.37]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id g63I9dX27388 for ; Wed, 3 Jul 2002 14:09:40 -0400 (EDT) Received: from msgrel1t.cos.agilent.com (msgrel1t.cos.agilent.com [130.29.152.157]) by msgbas2.cos.agilent.com (Postfix) with ESMTP id 27ADAEC3; Wed, 3 Jul 2002 12:09:39 -0600 (MDT) Received: from axcsbh3.cos.agilent.com (axcsbh3.cos.agilent.com [130.29.152.190]) by msgrel1t.cos.agilent.com (Postfix) with SMTP id E7E0055C; Wed, 3 Jul 2002 12:09:38 -0600 (MDT) Received: from 130.29.152.190 by axcsbh3.cos.agilent.com (InterScan E-Mail VirusWall NT); Wed, 03 Jul 2002 12:09:24 -0600 Received: by axcsbh3.cos.agilent.com with Internet Mail Service (5.5.2653.19) id ; Wed, 3 Jul 2002 12:09:24 -0600 Message-ID: <1BEBA5E8600DD4119A50009027AF54A00CB26EA1@axcs04.cos.agilent.com> From: pat_thaler@agilent.com To: Julian_Satran@il.ibm.com, pat_thaler@agilent.com Cc: ips@ece.cmu.edu Subject: RE: iSCSI: Login negotiation space Date: Wed, 3 Jul 2002 12:09:20 -0600 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/mixed; boundary="----=_NextPartTM-000-bbb0b7d0-9e3f-4572-b717-825843609beb" Sender: owner-ips@ece.cmu.edu Precedence: bulk This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------=_NextPartTM-000-bbb0b7d0-9e3f-4572-b717-825843609beb Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C222BC.C11E4E20" ------_=_NextPart_001_01C222BC.C11E4E20 Content-Type: text/plain; charset="ISO-8859-1" Julian, I wouldn't object to the default PDU size being lowered, but that is not what I am suggesting. There is no conflict between having a default PDU size of 8k during login and having a requirement to support at least 4096 bytes of key=value data in a negotiation sequence. PDUs don't have to be full. The situation is no worse than having a MaxRecvDataSegmentLength of 8k when MaxBurstLength is 4k or having a 4 kbyte write with an 8kb byte MaxRecvDataSegmentLength. The default MaxRecvDataSegmentLength at 8k would still be useful when implementations were supporting very long authentication items. Also, a vendor might suport a larger negotiaton space for vendor specific keys. Such an implmentation could send a key like X-com.acme.HugeKeySet=yes. If the partner responds X-com.acme.HugeKeySet=yes, then it can proceed to send the hugh key set knowing that its partner supports it and therefore has allocated space for it. If it gets a no or NotUnderstood response, it doesn't send the extra keys. I disagree with your statement about deadlock. It is a real issue when throttling is engaged. Regards, Pat -----Original Message----- From: Julian Satran [mailto:Julian_Satran@il.ibm.com] Sent: Wednesday, July 03, 2002 8:34 AM To: pat_thaler@agilent.com Cc: ips@ece.cmu.edu Subject: RE: iSCSI: Login negotiation space Pat, 4k does not make too much sense either with default PDU size of 8k. Are you suggesting we limit this too to a lower value? Your deadlock example while academically correct is not very interesting as I assume that throttling can be done at the first buffer level. Julo ------_=_NextPart_001_01C222BC.C11E4E20 Content-Type: text/html; charset="ISO-8859-1"

Julian,
 
I wouldn't object to the default PDU size being lowered, but that is not what I am suggesting.
 
There is no conflict between having a default PDU size of 8k during login and having a requirement to support at least 4096 bytes of key=value data in a negotiation sequence. PDUs don't have to be full. The situation is no worse than having a MaxRecvDataSegmentLength of 8k when MaxBurstLength is 4k or having a 4 kbyte write with an 8kb byte MaxRecvDataSegmentLength.
 
The default MaxRecvDataSegmentLength at 8k would still be useful when implementations were supporting very long authentication items. Also, a vendor might suport a larger negotiaton space for vendor specific keys. Such an implmentation could send a key like X-com.acme.HugeKeySet=yes. If the partner responds X-com.acme.HugeKeySet=yes, then it can proceed to send the hugh key set knowing that its partner supports it and therefore has allocated space for it. If it gets a no or NotUnderstood response, it doesn't send the extra keys.
 
I disagree with your statement about deadlock. It is a real issue when throttling is engaged.
 
Regards,
Pat
 
-----Original Message-----
From: Julian Satran [mailto:Julian_Satran@il.ibm.com]
Sent: Wednesday, July 03, 2002 8:34 AM
To: pat_thaler@agilent.com
Cc: ips@ece.cmu.edu
Subject: RE: iSCSI: Login negotiation space


Pat,

4k does not make too much sense either with default PDU size of 8k.
Are you suggesting we limit this too to a lower value?
Your deadlock example while academically correct is not very interesting as I assume that throttling can be done at the first buffer level.

Julo


 

------_=_NextPart_001_01C222BC.C11E4E20-- ------=_NextPartTM-000-bbb0b7d0-9e3f-4572-b717-825843609beb-- From owner-ips@ece.cmu.edu Wed Jul 3 14:59:31 2002 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA29472 for ; Wed, 3 Jul 2002 14:59:30 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id g63Ichn28604 for ips-outgoing; Wed, 3 Jul 2002 14:38:43 -0400 (EDT) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from msgbas2.cos.agilent.com (msgbas2x.cos.agilent.com [192.25.240.37]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id g63IcfX28600 for ; Wed, 3 Jul 2002 14:38:42 -0400 (EDT) Received: from msgrel1t.cos.agilent.com (msgrel1t.cos.agilent.com [130.29.152.157]) by msgbas2.cos.agilent.com (Postfix) with ESMTP id 195FE16AC; Wed, 3 Jul 2002 12:38:41 -0600 (MDT) Received: from axcsbh3.cos.agilent.com (axcsbh3.cos.agilent.com [130.29.152.190]) by msgrel1t.cos.agilent.com (Postfix) with SMTP id 6D409571; Wed, 3 Jul 2002 12:38:40 -0600 (MDT) Received: from 130.29.152.190 by axcsbh3.cos.agilent.com (InterScan E-Mail VirusWall NT); Wed, 03 Jul 2002 12:38:39 -0600 Received: by axcsbh3.cos.agilent.com with Internet Mail Service (5.5.2653.19) id ; Wed, 3 Jul 2002 12:38:39 -0600 Message-ID: <1BEBA5E8600DD4119A50009027AF54A00CE07248@axcs04.cos.agilent.com> From: pat_thaler@agilent.com To: Julian_Satran@il.ibm.com, tomasb@s3group.cz Cc: ips@ece.cmu.edu, ivan.pavelka@s3group.com Subject: RE: iSCSI: draft vs. 14 typos, suggestion, questions Date: Wed, 3 Jul 2002 12:38:37 -0600 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="ISO-8859-1" Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ece.cmu.edu id g63IcgX28601 Sender: owner-ips@ece.cmu.edu Precedence: bulk Content-Transfer-Encoding: 8bit See comment below. Pat -----Original Message----- From: Julian Satran [mailto:Julian_Satran@il.ibm.com] Sent: Wednesday, July 03, 2002 9:20 AM To: Tomá? Bartu?ek Cc: ips@ece.cmu.edu; ivan.pavelka@s3group.com Subject: Re: iSCSI: draft vs. 14 typos, suggestion, questions *** Section 6.11 : QUESTION Draft says: When the session timeout (the connection state timeout for the last failed connection) happens on the target, it takes the following actions: - Resets or closes the TCP connections (closes the session). - Aborts all Tasks in the task set for the corresponding initi- ator. What does the "corresponding initiator" mean? We think (:-)), that there is only one initiator for the session. The only possible explanation we see for that paragraph is, that the target should abort also other tasks of the same in __other__ sessions, but why? +++ your interpretation is correct - the statement means the initiator that "owned" the session. Are you suggesting other wording? ++++ "Aborts all task sets associated with the session" (Task set was changed to plural because task set is defined as an I-T-L nexus and there may be muliple ones in the session. From owner-ips@ece.cmu.edu Wed Jul 3 15:37:46 2002 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA02357 for ; Wed, 3 Jul 2002 15:37:46 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id g63Itk729358 for ips-outgoing; Wed, 3 Jul 2002 14:55:46 -0400 (EDT) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from mailhub.lss.emc.com (xdch.emc.com [168.159.1.79]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id g63ItjX29354 for ; Wed, 3 Jul 2002 14:55:45 -0400 (EDT) Received: from emc.com (emcmail.lss.emc.com [168.159.48.78]) by mailhub.lss.emc.com (Switch-2.2.0/Switch-2.2.0) with ESMTP id g63Ita223685; Wed, 3 Jul 2002 14:55:36 -0400 (EDT) Received: from mxic1.isus.emc.com ([168.159.129.100]) by emc.com (8.10.1/8.10.1) with ESMTP id g63Ita723207; Wed, 3 Jul 2002 14:55:36 -0400 (EDT) Received: by MXIC1 with Internet Mail Service (5.5.2653.19) id <31V08L3X>; Wed, 3 Jul 2002 14:53:44 -0400 Message-ID: <277DD60FB639D511AC0400B0D068B71E0564C02B@CORPMX14> From: Black_David@emc.com To: ni1d@arrl.net Cc: ips@ece.cmu.edu Subject: iSCSI: SRP s vs. S Date: Wed, 3 Jul 2002 14:53:41 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" X-Perlmx-Spam: Gauge=XXXXI, Probability=41%, Report="GAPPY_TEXT, NO_REAL_NAME" Sender: owner-ips@ece.cmu.edu Precedence: bulk > > > 10.4 SRP: N,g,s,A,B,M and H(A | M | K) are binary-values > > > 10.5 CHAP: C and R are binary-values > > > > The only ones of these that should routinely fit in 64 bits are SRP's > > g (usually a small integer, even though it's mathematically a member of > > a very large binary field - I think Paul Koning missed the fact that > > generators tend to be single-digit numbers) and s (doesn't need to be > > a large number to get the job done). > > You're right about g. As for S, it's the result of an exponentiation > modulo N, so it's no more likely to be a small integer than the other > SRP intermediate values. Note that values supplied by the other end > are involved (as in conventional D-H) so you don't have the ability to > constrain your implementation to produce small S values. Paul - please recheck RFC 2945, as you may have confused s (lower case) with S (upper case). s (lower case) is the and is what goes across the wire. S (upper case) is an intermediate in the SRP computations that should be identical on both sides, but is *not* sent across the wire (good thing too, as the session key(s) can easily be determined from knowledge of it). s (lower case) need not be a big number to get the job done, and would be ok to send in decimal, although my first reaction to "salt from passwd file" would be to use hex. 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 --------------------------------------------------- From owner-ips@ece.cmu.edu Wed Jul 3 15:38:42 2002 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA02406 for ; Wed, 3 Jul 2002 15:38:42 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id g63JS2W01108 for ips-outgoing; Wed, 3 Jul 2002 15:28:02 -0400 (EDT) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from cygnus.equallogic.com (cygnus.equallogic.com [65.170.102.10]) by ece.cmu.edu (8.11.0/8.10.2) with SMTP id g63JS0X01104 for ; Wed, 3 Jul 2002 15:28:00 -0400 (EDT) Received: from cygnus.equallogic.com (localhost.localdomain [127.0.0.1]) by cygnus.equallogic.com (8.11.6/8.11.6) with ESMTP id g63JRsC16950 for ; Wed, 3 Jul 2002 15:27:54 -0400 Received: from deneb.dev.equallogic.com (deneb.dev.equallogic.com [172.16.1.99]) by cygnus.equallogic.com (8.11.6/8.11.6) with ESMTP id g63JRsQ16941; Wed, 3 Jul 2002 15:27:54 -0400 Received: from PKONING.equallogic.com (localhost.localdomain [127.0.0.1]) by deneb.dev.equallogic.com (8.11.6/8.11.6) with ESMTP id g63JRrk19715; Wed, 3 Jul 2002 15:27:54 -0400 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <15651.20538.66000.446581@gargle.gargle.HOWL> Date: Wed, 3 Jul 2002 15:27:54 -0400 From: Paul Koning To: Black_David@emc.com Cc: ips@ece.cmu.edu Subject: Re: iSCSI: SRP s vs. S References: <277DD60FB639D511AC0400B0D068B71E0564C02B@CORPMX14> X-Mailer: VM 6.95 under 21.4 (patch 3) "Academic Rigor" XEmacs Lucid Sender: owner-ips@ece.cmu.edu Precedence: bulk Content-Transfer-Encoding: 7bit Excerpt of message (sent 3 July 2002) by Black_David@emc.com: > Paul - please recheck RFC 2945, as you may have confused s (lower case) > with S (upper case). s (lower case) is the and > is what goes across the wire. S (upper case) is an intermediate in the > SRP computations that should be identical on both sides, but is *not* > sent across the wire (good thing too, as the session key(s) can easily > be determined from knowledge of it). s (lower case) need not be a big > number to get the job done, and would be ok to send in decimal, although > my first reaction to "salt from passwd file" would be to use hex. You're right, I did mix up s and S. "s" is used as a string (in a SHA1 hash) so it is crucial to get its length correct. Decimal numbers don't have an obvious length, as has been pointed out before, so that representation should not be used here. I pointed out earlier that the way to look at this is: there are two data types, integer and octetstring. "Integer" means machine integer, not bignum. All crypto items with the possible exception of "g" are either octetstrings (hash inputs or outputs) or they are bignums. Octetstrings should use hex or base64 but not decimal; integers should use decimal or hex but not base64. We've more or less agreed on this before, except that things remain muddled because the data type distinction hasn't been made. I think it would help if it were, though arguably that's editorial. A separate question is whether "machine integer" should be 32 bits, or 64 bits. All the current integer keys fit in 32 bits with lots of room to spare, so there isn't any good reason to require support for 64 bit integers since they won't be used. If the type distinction between octetstrings and integers is made, then the issue of (with very low probability) being able to send crypto values as 64 bit integers disappears, which would be a Good Thing. paul From owner-ips@ece.cmu.edu Wed Jul 3 16:20:11 2002 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA04602 for ; Wed, 3 Jul 2002 16:20:10 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id g63GKJY21936 for ips-outgoing; Wed, 3 Jul 2002 12:20:19 -0400 (EDT) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from d12lmsgate-3.de.ibm.com (d12lmsgate-3.de.ibm.com [195.212.91.201]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id g63GKGX21929 for ; Wed, 3 Jul 2002 12:20:17 -0400 (EDT) Received: from d12relay01.de.ibm.com (d12relay01.de.ibm.com [9.165.215.22]) by d12lmsgate-3.de.ibm.com (8.12.3/8.12.3) with ESMTP id g63GKA2F089794; Wed, 3 Jul 2002 18:20:10 +0200 Received: from d10hubm1.telaviv.ibm.com (d10ml001.telaviv.ibm.com [9.148.216.55]) by d12relay01.de.ibm.com (8.11.1m3/NCO/VER6.1) with ESMTP id g63GK8D67012; Wed, 3 Jul 2002 18:20:09 +0200 To: Michael Morrison Cc: ips@ece.cmu.edu MIME-Version: 1.0 Subject: Re: Delaying Login - was: RE: iSCSI: Login negotiation space X-Mailer: Lotus Notes Release 5.0.9 November 16, 2001 From: "Julian Satran" Message-ID: Date: Wed, 3 Jul 2002 19:20:05 +0300 X-MIMETrack: Serialize by Router on D10ML001/10/M/IBM(Release 5.0.9a |January 7, 2002) at 03/07/2002 19:20:08, Serialize complete at 03/07/2002 19:20:08 Content-Type: multipart/alternative; boundary="=_alternative 0059992FC2256BEB_=" Sender: owner-ips@ece.cmu.edu Precedence: bulk This is a multipart message in MIME format. --=_alternative 0059992FC2256BEB_= Content-Type: text/plain; charset="us-ascii" We had a long debate (about a year ago) about including specific timeouts and the clear consensus was to let implementers (and experience) get their way. Julo Michael Morrison 07/03/2002 01:59 AM Please respond to Michael Morrison To: Julian Satran/Haifa/IBM@IBMIL cc: ips@ece.cmu.edu Subject: Delaying Login - was: RE: iSCSI: Login negotiation space Julian, Your comment about controlling login progress by delaying requests/responses begs the question: How long is too long? I actually have a question about delaying login during Session Reinstatement. Say a target receives a login indicating Session Reinstatement. The target must internally abort all tasks on the session, but this may take a very long time and the implementer may not want to complete the reinstatement login until all the tasks are aborted; again, how long is too long? Perhaps a blurb in a new section (6.3.3?) on Timeouts on Login, or Timeouts on Session Reinstatement? Mike On Tue, 2002-07-02 at 12:35, Julian Satran wrote: Pat, 4k is absurd. We have the security guys asking for 64k certificates! And the PDUlength default is 8k! Besides you can control the total memory consumed by throttling login as soon as you have unprocessed keys exceeding the mount of memory you want to keep aside (you control the login progress by delaying requests/responses). Julo pat_thaler@agilent.com 07/02/2002 10:02 PM Please respond to pat_thaler To: Julian Satran/Haifa/IBM@IBMIL, pat_thaler@agilent.com cc: ips@ece.cmu.edu Subject: RE: iSCSI: Login negotiation space Julian, A factor of 10 is way overkill. It isn't just 16 k bytes of extra memory. It is n * 16k where n is the number of simultaneous logins the implementation supports - it adds up. The system vendors we work with want to use the memory to do useful work and demand that driver sizes be kept small -- they want the memory available to do "real" work. If 2k doesn't leave enough headroom, then we could live with somewhat more like 4k. If future features added to iSCSI require more space, the drivers that support that can allocate more memory. It is an internal parameter that can be changed when the need arises. There is no future interoperability need to make the buffer oversized in current implementations. Regards, Pat -----Original Message----- From: Julian Satran [mailto:Julian_Satran@il.ibm.com] Sent: Tuesday, July 02, 2002 12:10 AM To: pat_thaler@agilent.com Cc: ips@ece.cmu.edu Subject: RE: iSCSI: Login negotiation space Pat, A factor of 10 over what is needed today is what I would call a conservative design. Limiting the support to 2k would be extremely unwise. And 16 is a tiny amount of memory - of no concern to software implementation and to most hardware implementations. Julo pat_thaler@agilent.com 07/02/2002 01:56 AM Please respond to pat_thaler To: Julian Satran/Haifa/IBM@IBMIL cc: ips@ece.cmu.edu Subject: RE: iSCSI: Login negotiation space Julian, 4.1 contains a requirement that initiators and targets support receiving at least 16384 bytes of key=value data (when not supporting very long authentication items). This is overkill and is making drivers larger than they need to be. My calculations are that Security negotiation using the CHAP method (including the Any-stage keys) takes less than 1600 bytes. Operational negotiation requires 1276 bytes (also including the Any-stage keys). All the operational plus security keys are 1911 bytes. Therefore an implementation could hold all the necessary keys in 2 Kbytes. And, the implementation doesn't need to keep the security keys after the security negotiation is done so it could clear some of that out to make room for future keys or vendor specific keys. 16 K bytes is about 10 times the necessary storage in that case. The number of negotiation bytes that a device is required to support should be reduced substantially - preferably to 2048 bytes. Regards, Pat The numbers: 43 AuthMethod CHAP keys 264 Name (no defined size limit - using 255) 11 Algorithm 11 Identifier 264 Challenge 42 Response (for MD5) _____ 635 Chap negotiation length 892 Any-stage keys ---- 1527 Operational negotiation keys 24 HeaderDigest 24 DataDigest 49 MaxConnections 270 TargetName* or InitiatorName* 271 TargetAlias* or InitiatorAlias* 273 TargetAddress* 55 TargetPortalGroupTag* 15 InitialR2T 19 BidiInitialR2T 18 ImmediateData 34 MaxRecvDataSegmentLength 24 MaxBurstLength 26 FirstBurstLength 24 DefaultTime2Wait 26 DefaultTime2Retain 25 MaxOutstandingR2T 18 DataPDUInOrder 24 DataSequenceInOrder 24 ErrorRecoveryLevel 23 SessionType* ------ 892 Any-stage keys 384 Not Any-stage ------ 1276 Operational keys Michael Morrison ISTOR Networks 7585 Irvine Center Dr. Ste 250 Irvine Ca. 92618 PGP Key: 74C30155 --=_alternative 0059992FC2256BEB_= Content-Type: text/html; charset="us-ascii"
We had a long debate (about a year ago) about including specific timeouts and the clear consensus was to let implementers (and experience) get their way.

Julo


Michael Morrison <mmorrison@istor.com>

07/03/2002 01:59 AM
Please respond to Michael Morrison

       
        To:        Julian Satran/Haifa/IBM@IBMIL
        cc:        ips@ece.cmu.edu
        Subject:        Delaying Login  - was:  RE: iSCSI: Login negotiation space

       


Julian,

Your comment about controlling login progress by delaying requests/responses begs the question:  How long is too long?

I actually have a question about delaying login during Session Reinstatement.  Say a target receives a login indicating Session Reinstatement.  The target must internally abort all tasks on the session, but this may take a very long time and the implementer may not
want to complete the reinstatement login until all the tasks are aborted;  again,  how long is too long?

Perhaps a blurb in a new section (6.3.3?) on Timeouts on Login, or Timeouts on Session Reinstatement?  

Mike

On Tue, 2002-07-02 at 12:35, Julian Satran wrote:
Pat,

4k is absurd. We have the security guys asking for 64k certificates!
And the PDUlength default is 8k!
Besides you can control the total memory consumed by throttling login as soon as you have unprocessed keys exceeding the mount of memory you want to keep aside (you control the login progress by delaying requests/responses).


Julo

pat_thaler@agilent.com

07/02/2002 10:02 PM
Please respond to pat_thaler 		       
       To:        Julian Satran/Haifa/IBM@IBMIL, pat_thaler@agilent.com
       cc:        ips@ece.cmu.edu
       Subject:        RE: iSCSI: Login negotiation space

       



Julian,
 
A factor of 10 is way overkill. It isn't just 16 k bytes of extra memory. It is n * 16k where n is the number of simultaneous logins the implementation supports - it adds up. The system vendors we work with want to use the memory to do useful work and demand that driver sizes be kept small -- they want the memory available to do "real" work.
 
If 2k doesn't leave enough headroom, then we could live with somewhat more like 4k.
 
If future features added to iSCSI require more space, the drivers that support that can allocate more memory. It is an internal parameter that can be changed when the need arises. There is no future interoperability need to make the buffer oversized in current implementations.
 
Regards,
Pat
 
-----Original Message-----
From: Julian Satran [mailto:Julian_Satran@il.ibm.com]
Sent: Tuesday, July 02, 2002 12:10 AM
To: pat_thaler@agilent.com
Cc: ips@ece.cmu.edu
Subject: RE: iSCSI: Login negotiation space


Pat,

A factor of 10 over what is needed today is what I would call a conservative design.
Limiting the support to 2k would be extremely unwise.
And 16 is a tiny amount of memory - of no concern to software implementation and to most hardware implementations.

Julo

pat_thaler@agilent.com

07/02/2002 01:56 AM
Please respond to pat_thaler 		       
      To:        Julian Satran/Haifa/IBM@IBMIL
      cc:        ips@ece.cmu.edu
      Subject:        RE: iSCSI: Login negotiation space

     




Julian,

4.1 contains a requirement that initiators and targets support receiving at least 16384 bytes of key=value data (when not supporting very long authentication items). This is overkill and is making drivers larger than they need to be.

My calculations are that Security negotiation using the CHAP method (including the Any-stage keys) takes less than 1600 bytes. Operational negotiation requires 1276 bytes (also including the Any-stage keys). All the operational plus security keys are 1911 bytes.

Therefore an implementation could hold all the necessary keys in 2 Kbytes. And, the implementation doesn't need to keep the security keys after the security negotiation is done so it could clear some of that out to make room for future keys or vendor specific keys. 16 K bytes is about 10 times the necessary storage in that case.

The number of negotiation bytes that a device is required to support should be reduced substantially - preferably to 2048 bytes.

Regards,
Pat


The numbers:

43                                  AuthMethod
        CHAP keys
264                                  Name (no defined size limit - using 255)
11                                  Algorithm
11                                  Identifier
264                                  Challenge
42                                  Response (for MD5)
_____
635 Chap negotiation length
892 Any-stage keys
----
1527

Operational negotiation keys
24                                  HeaderDigest
24        DataDigest
49        MaxConnections
270                                  TargetName* or InitiatorName*
271                                  TargetAlias* or InitiatorAlias*
273        TargetAddress*
55                                  TargetPortalGroupTag*
15                                  InitialR2T
19                                  BidiInitialR2T
18                                  ImmediateData
34                                  MaxRecvDataSegmentLength
24                                  MaxBurstLength
26                                  FirstBurstLength
24                                  DefaultTime2Wait
26                                  DefaultTime2Retain
25                                  MaxOutstandingR2T
18                                  DataPDUInOrder
24                                  DataSequenceInOrder
24                                  ErrorRecoveryLevel
23                                  SessionType*
------
892 Any-stage keys
384 Not Any-stage
------
1276 Operational keys







Michael Morrison
ISTOR Networks
7585 Irvine Center Dr. Ste 250
Irvine Ca. 92618
PGP Key: 74C30155



--=_alternative 0059992FC2256BEB_=-- From owner-ips@ece.cmu.edu Wed Jul 3 17:48:24 2002 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA08213 for ; Wed, 3 Jul 2002 17:48:23 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id g63L4pq05504 for ips-outgoing; Wed, 3 Jul 2002 17:04:51 -0400 (EDT) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from web13708.mail.yahoo.com (web13708.mail.yahoo.com [216.136.175.141]) by ece.cmu.edu (8.11.0/8.10.2) with SMTP id g63L4nX05492 for ; Wed, 3 Jul 2002 17:04:49 -0400 (EDT) Message-ID: <20020703210448.20831.qmail@web13708.mail.yahoo.com> Received: from [192.52.58.5] by web13708.mail.yahoo.com via HTTP; Wed, 03 Jul 2002 14:04:48 PDT Date: Wed, 3 Jul 2002 14:04:48 -0700 (PDT) From: Martins Krikis Subject: RE: iSCSI: Login negotiation space To: ips@ece.cmu.edu In-Reply-To: <1BEBA5E8600DD4119A50009027AF54A00CB26EA1@axcs04.cos.agilent.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: owner-ips@ece.cmu.edu Precedence: bulk I believe I'm with Pat. Requiring 10 times more free space to be available than the real minimum needed is an overkill. Coming down to 2K or 4K sounds very reasonable. What I don't understand, however, is why was a minimum mandated (with a MUST) and not just encouraged (with a SHOULD) in the first place? I.e., what's wrong with an implementation that does its best as long as it can and answers with "Out of resources" when the data amount that needs to be stored gets excessive? Alternatively, would it be considered compliant to support the mandated minimum (whatever it ends up to be) on at least one login, but reserve the right to answer with "Out of resources" on the _simultaneous_ other logins, if they send too much data? Thanks, Martins Krikis, Intel Corp. Disclaimer: these opinions are mine and may not be Intel's. __________________________________________________ Do You Yahoo!? Sign up for SBC Yahoo! Dial - First Month Free http://sbc.yahoo.com From owner-ips@ece.cmu.edu Wed Jul 3 17:50:00 2002 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA08339 for ; Wed, 3 Jul 2002 17:49:59 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id g63LTwS06580 for ips-outgoing; Wed, 3 Jul 2002 17:29:58 -0400 (EDT) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from sj-msg-core-1.cisco.com (sj-msg-core-1.cisco.com [171.71.163.11]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id g63LTuX06575 for ; Wed, 3 Jul 2002 17:29:56 -0400 (EDT) Received: from nisser.cisco.com (nisser.cisco.com [171.71.176.85]) by sj-msg-core-1.cisco.com (8.12.2/8.12.2) with ESMTP id g63LTo39017682 for ; Wed, 3 Jul 2002 14:29:50 -0700 (PDT) Received: from cisco.com (mbakke@mbakke-lnx.cisco.com [161.44.68.87]) by nisser.cisco.com (8.8.6 (PHNE_14041)/CISCO.SERVER.1.2) with ESMTP id OAA21237 for ; Wed, 3 Jul 2002 14:29:48 -0700 (PDT) Message-ID: <3D2370FE.8EB7DC5E@cisco.com> Date: Wed, 03 Jul 2002 16:47:42 -0500 From: Mark Bakke X-Mailer: Mozilla 4.72 [en] (X11; U; Linux 2.2.16-3.uid32 i686) X-Accept-Language: en, de MIME-Version: 1.0 To: IPS Subject: iSCSI: Last call comments Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ips@ece.cmu.edu Precedence: bulk Content-Transfer-Encoding: 7bit The iSCSI draft is looking pretty good. I only have one last-call comment left: There are a few sections in iSCSI (and ips-security) that discuss IPsec requirements for "compliant/conformant implementations". I recall that this meant a target implementation could either be a single device with both iSCSI and IPsec, or a combination of two devices, one that handles iSCSI; the other handling IPsec. However, I couldn't find anywhere in the spec that spells this out either way, other than a hint at it in item [3] on page 31 of ips-security-13: > [3] IPsec is provided by a device external to the actual iSCSI device. > Here the iSCSI header and data CRCs can be kept across the part of > the connection that is not protected by IPsec. For instance, the > iSCSI connection could traverse an extra bus, interface card, > network, interface card, and bus between the iSCSI device and the > device providing IPsec. In this case, the iSCSI CRC is desirable, > and the iSCSI implementation behind the IPsec device may request > it. As there are many cases where it makes a lot of sense to provide the solution in two pieces (iSCSI in one or more devices, with one or more IPsec front-end devices, I'd like to clarify this. How about (somewhere in section 7) adding something like: An iSCSI compliant initiator or target may provide the required IPsec support either by itself, or in conjunction with an IPsec front-end device. Any thoughts? -- Mark For reference, here are a few of the statements that would be helped out by the above. iscsi-14 Section 7.3.1: An iSCSI compliant initiator or target MUST provide data integrity and authentication by implementing IPsec [RFC2401] with ESP [RFC2406] in tunnel mode and MAY provide data integrity and authentication by implementing IPsec with ESP in transport mode. The IPsec implementa- tion MUST fulfill the following iSCSI specific requirements: iscsi-14 Section 7.3.2: An iSCSI compliant initiator or target MUST provide confidentiality by implementing IPsec [RFC2401] with ESP [RFC2406] in tunnel mode and MAY provide confidentiality by implementing IPsec with ESP in trans- port mode. with the following iSCSI specific requirements: iscsi-14 Section 7.3.3: - Conformant iSCSI implementations MUST support IKE Main Mode and SHOULD support Aggressive Mode. --- ips-security-13 Section 2.3.1: All IP block storage security compliant implementations MUST support IPsec ESP [RFC2406] to provide security for both control packets and data packets, as well as the replay protection mechanisms of IPsec. When ESP is utilized, per-packet data origin authentication, integrity and replay protection MUST be used. -- Mark A. Bakke Cisco Systems mbakke@cisco.com 763.398.1054 From owner-ips@ece.cmu.edu Wed Jul 3 18:42:13 2002 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA10895 for ; Wed, 3 Jul 2002 18:42:08 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id g63LuTk07782 for ips-outgoing; Wed, 3 Jul 2002 17:56:29 -0400 (EDT) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from mxic2.corp.emc.com (mxic2.isus.emc.com [128.221.31.40]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id g63LuRX07774 for ; Wed, 3 Jul 2002 17:56:27 -0400 (EDT) Received: by mxic2.corp.emc.com with Internet Mail Service (5.5.2653.19) id <31X6J6NL>; Wed, 3 Jul 2002 17:56:22 -0400 Message-ID: <277DD60FB639D511AC0400B0D068B71E0564C02C@CORPMX14> From: Black_David@emc.com To: mbakke@cisco.com, ips@ece.cmu.edu Subject: RE: iSCSI: Last call comments Date: Wed, 3 Jul 2002 17:54:28 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-ips@ece.cmu.edu Precedence: bulk Mark, > There are a few sections in iSCSI (and ips-security) that discuss > IPsec requirements for "compliant/conformant implementations". I > recall that this meant a target implementation could either be a > single device with both iSCSI and IPsec, or a combination of two > devices, one that handles iSCSI; the other handling IPsec. In the two device combination, only the combination is compliant, and only at the interface(s) that provide(s) both iSCSI and IPsec. The iSCSI device in the combination is not compliant by itself because it does not provide IPsec. > As there are many cases where it makes a lot of sense to provide > the solution in two pieces (iSCSI in one or more devices, with one or > more IPsec front-end devices, I'd like to clarify this. > > How about (somewhere in section 7) adding something like: > > An iSCSI compliant initiator or target may provide the required > IPsec support either by itself, or in conjunction with an IPsec > front-end device. > > Any thoughts? It would need to have the word "compliant" removed and a sentence added to spell out what is compliant, along the lines of: An iSCSI initiator or target may provide the required IPsec support either by itself, or in conjunction with an IPsec front-end device. In the latter case only the combination complies with the requirements of this specification; the individual iSCSI initiator or target would not comply with the requirements of this specification due to the lack of IPsec support. It's probably a good idea to put this in. 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 --------------------------------------------------- > -----Original Message----- > From: Mark Bakke [mailto:mbakke@cisco.com] > Sent: Wednesday, July 03, 2002 5:48 PM > To: IPS > Subject: iSCSI: Last call comments > > > > The iSCSI draft is looking pretty good. I only have one last-call > comment left: > > There are a few sections in iSCSI (and ips-security) that discuss > IPsec requirements for "compliant/conformant implementations". I > recall that this meant a target implementation could either be a > single device with both iSCSI and IPsec, or a combination of two > devices, one that handles iSCSI; the other handling IPsec. However, > I couldn't find anywhere in the spec that spells this out either > way, other than a hint at it in item [3] on page 31 of > ips-security-13: > > > [3] IPsec is provided by a device external to the actual > iSCSI device. > > Here the iSCSI header and data CRCs can be kept across > the part of > > the connection that is not protected by IPsec. For > instance, the > > iSCSI connection could traverse an extra bus, interface card, > > network, interface card, and bus between the iSCSI > device and the > > device providing IPsec. In this case, the iSCSI CRC is > desirable, > > and the iSCSI implementation behind the IPsec device > may request > > it. > > As there are many cases where it makes a lot of sense to provide > the solution in two pieces (iSCSI in one or more devices, with one or > more IPsec front-end devices, I'd like to clarify this. > > How about (somewhere in section 7) adding something like: > > An iSCSI compliant initiator or target may provide the required > IPsec support either by itself, or in conjunction with an IPsec > front-end device. > > Any thoughts? > > -- > Mark > > > For reference, here are a few of the statements that would be > helped out by the above. > > iscsi-14 Section 7.3.1: > > An iSCSI compliant initiator or target MUST provide data integrity > and authentication by implementing IPsec [RFC2401] with > ESP [RFC2406] > in tunnel mode and MAY provide data integrity and > authentication by > implementing IPsec with ESP in transport mode. The IPsec > implementa- > tion MUST fulfill the following iSCSI specific requirements: > > iscsi-14 Section 7.3.2: > > An iSCSI compliant initiator or target MUST provide > confidentiality > by implementing IPsec [RFC2401] with ESP [RFC2406] in > tunnel mode and > MAY provide confidentiality by implementing IPsec with ESP > in trans- > port mode. with the following iSCSI specific requirements: > > iscsi-14 Section 7.3.3: > > - Conformant iSCSI implementations MUST support IKE Main Mode > and SHOULD support Aggressive Mode. > > --- > ips-security-13 Section 2.3.1: > > All IP block storage security compliant implementations MUST support > IPsec ESP [RFC2406] to provide security for both control packets and > data packets, as well as the replay protection mechanisms of IPsec. > When ESP is utilized, per-packet data origin authentication, integrity > and replay protection MUST be used. > > > -- > Mark A. Bakke > Cisco Systems > mbakke@cisco.com > 763.398.1054 > From owner-ips@ece.cmu.edu Wed Jul 3 19:45:08 2002 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA13547 for ; Wed, 3 Jul 2002 19:45:08 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id g63N5Fq10597 for ips-outgoing; Wed, 3 Jul 2002 19:05:15 -0400 (EDT) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from osmtp1.electric.net (osmtp1.electric.net [216.129.90.28]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id g63N5EX10592 for ; Wed, 3 Jul 2002 19:05:14 -0400 (EDT) Received: from [216.129.90.10] (helo=www3.electric.net) by osmtp1.electric.net with smtp (Exim 3.22 #1) id 17PtBR-000KrV-04 for ips@ece.cmu.edu; Wed, 03 Jul 2002 16:05:13 -0700 Received: (qmail 29661 invoked by uid 99); 3 Jul 2002 23:05:18 -0000 Message-ID: <1025737518.3d23832e8a237@webmail.123mail.net> Date: Wed, 03 Jul 2002 18:05:18 -0500 To: ips@ece.cmu.edu From: Elizabeth Rodriguez Subject: IPS-ALL: Reminder iSCSI Last Call ends SUNDAY, July 7 at 5pm EST MIME-Version: 1.0 Content-Type: text/plain Content-Transfer-Encoding: 8bit User-Agent: 123mail WebMail X-Originating-IP: 206.175.236.26 Sender: owner-ips@ece.cmu.edu Precedence: bulk Content-Transfer-Encoding: 8bit (Repeat -- previous set out w/o subject line) Just a reminder that the last call period for the iSCSI draft ends this SUNDAY at 5 pm EST. The latest version of the draft is version 14. It is available at http://www.haifa.il.ibm.com/satran/ips It is in the ID office for processing and will soon be available at the IETF site as well. Draft 13 is the original draft Last call was started on. Julian produced version 14 with changes based on Last Call issues from last week. The haifa web site also has a list issues brought up in the last call as well as thier resolution, if one is available. Thanks, Elizabeth From owner-ips@ece.cmu.edu Wed Jul 3 19:47:01 2002 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA13606 for ; Wed, 3 Jul 2002 19:47:00 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id g63N31n10507 for ips-outgoing; Wed, 3 Jul 2002 19:03:01 -0400 (EDT) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from osmtp3.electric.net (osmtp3.electric.net [216.129.90.30]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id g63N2xX10502 for ; Wed, 3 Jul 2002 19:03:00 -0400 (EDT) Received: from [216.129.90.10] (helo=www3.electric.net) by osmtp3.electric.net with smtp (Exim 3.22 #1) id 17Pt9C-000Lpe-04 for ips@ece.cmu.edu; Wed, 03 Jul 2002 16:02:54 -0700 Received: (qmail 29514 invoked by uid 99); 3 Jul 2002 23:03:00 -0000 Message-ID: <1025737380.3d2382a41ae4b@webmail.123mail.net> Date: Wed, 03 Jul 2002 18:03:00 -0500 To: ips@ece.cmu.edu From: Elizabeth Rodriguez MIME-Version: 1.0 Content-Type: text/plain Content-Transfer-Encoding: 8bit User-Agent: 123mail WebMail X-Originating-IP: 206.175.236.26 Sender: owner-ips@ece.cmu.edu Precedence: bulk Content-Transfer-Encoding: 8bit Just a reminder that the last call period for the iSCSI draft ends this SUNDAY at 5 pm EST. The latest version of the draft is version 14. It is available at http://www.haifa.il.ibm.com/satran/ips It is in the ID office for processing and will soon be available at the IETF site as well. Draft 13 is the original draft Last call was started on. Julian produced version 14 with changes based on Last Call issues from last week. The haifa web site also has a list issues brought up in the last call as well as thier resolution, if one is available. Thanks, Elizabeth From owner-ips@ece.cmu.edu Wed Jul 3 20:23:48 2002 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA15215 for ; Wed, 3 Jul 2002 20:23:47 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id g63NvD712427 for ips-outgoing; Wed, 3 Jul 2002 19:57:13 -0400 (EDT) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from web13702.mail.yahoo.com (web13702.mail.yahoo.com [216.136.175.135]) by ece.cmu.edu (8.11.0/8.10.2) with SMTP id g63NvBX12420 for ; Wed, 3 Jul 2002 19:57:11 -0400 (EDT) Message-ID: <20020703235710.2960.qmail@web13702.mail.yahoo.com> Received: from [192.52.58.5] by web13702.mail.yahoo.com via HTTP; Wed, 03 Jul 2002 16:57:10 PDT Date: Wed, 3 Jul 2002 16:57:10 -0700 (PDT) From: Martins Krikis Subject: iSCSI: base64-constant small editorial changes To: ips@ece.cmu.edu Cc: Julian_Satran@il.ibm.com MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: owner-ips@ece.cmu.edu Precedence: bulk Page 71, base64-constant definition: "Base64-constants are used to encode numerical-values or binary strings." should say "large-numerical-values or binary strings", since it is not allowed for the regular ones. typo in "(encoded a A)". Thanks, Martins Krikis, Intel Corp. __________________________________________________ Do You Yahoo!? Sign up for SBC Yahoo! Dial - First Month Free http://sbc.yahoo.com From owner-ips@ece.cmu.edu Wed Jul 3 20:24:56 2002 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA15287 for ; Wed, 3 Jul 2002 20:24:56 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id g63NjEf12009 for ips-outgoing; Wed, 3 Jul 2002 19:45:14 -0400 (EDT) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from web13709.mail.yahoo.com (web13709.mail.yahoo.com [216.136.175.251]) by ece.cmu.edu (8.11.0/8.10.2) with SMTP id g63NjCX12004 for ; Wed, 3 Jul 2002 19:45:12 -0400 (EDT) Message-ID: <20020703234511.96656.qmail@web13709.mail.yahoo.com> Received: from [192.52.58.5] by web13709.mail.yahoo.com via HTTP; Wed, 03 Jul 2002 16:45:11 PDT Date: Wed, 3 Jul 2002 16:45:11 -0700 (PDT) From: Martins Krikis Subject: RE: iSCSI: Decimal encoding - why 64 bits ? To: Black_David@emc.com, Julian_Satran@il.ibm.com Cc: ips@ece.cmu.edu In-Reply-To: <277DD60FB639D511AC0400B0D068B71E0564C01F@CORPMX14> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: owner-ips@ece.cmu.edu Precedence: bulk --- Black_David@emc.com wrote: > Replying to a couple of messages on this topic. > > --- Use of decimal for binary items > > > There was NEVER a discussion about forbidding > decimal for binary items. There may not have been a big discussion about it, since everybody was concentrating on disallowing base64 for numbers (yes, all of them; IMO most people seemed to think that binary strings would suffice and that large-numerical-values aren't necessary) or on limiting the size numerical values encoded in decimal. But it was certainly mentioned multiple times under various subject lines: http://www.pdl.cmu.edu/mailinglists/ips/mail/msg09780.html http://www.pdl.cmu.edu/mailinglists/ips/mail/msg10125.html http://www.pdl.cmu.edu/mailinglists/ips/mail/msg10153.html http://www.pdl.cmu.edu/mailinglists/ips/mail/msg10250.html > > It would be counterproductive to forbid them > > as they are so widely used in programming. > The request to forbid them seems to have evolved > into a request to I'd like to disagree about the programming part, but more importantly, why don't we reinstate the original request to forbid using decimal for binary items? It is not a very useful way of representing even short binary items because there is no way to express the number of leading 0-bytes, for example. In case there is a vote on this, I'm against using decimal for binary items. > --- 64 vs. 32 bits > > I went back to the mailing list - and there was a > clear consensus to keep > it to 64 bits (my original proposal was unlimited > and I suggested rhen 128 > to alleviate concerns about conversion difficulty > for unlimited numbers). > > That matches what I recall from mailing list > discussion, 32 bits was not > considered at the time. Getting it down from unlimited was way more important than getting it down to 32, but it certainly was considered: http://www.pdl.cmu.edu/mailinglists/ips/mail/msg09804.html http://www.pdl.cmu.edu/mailinglists/ips/mail/msg09808.html http://www.pdl.cmu.edu/mailinglists/ips/mail/msg09810.html > > The issue was raised without checking the > > libraries: > > [... snip ...] > > > I don't know about Windmills - but I assume > > that most modern development > > environments are supporting 64bit integers. Some of us are working in kernel-space, and there aren't many reasons for a kernel running on a 32-bit architecture to provide 64-bit integer conversion routines. I am not saying that I don't know how to write such a routine, just that there are normal reasons why some people may prefer 32 to 64. In case there is a vote, I'm for 32. Martins Krikis, Intel Corp. Disclaimer: these opinions are mine and may not be those of my employer. __________________________________________________ Do You Yahoo!? Sign up for SBC Yahoo! Dial - First Month Free http://sbc.yahoo.com From owner-ips@ece.cmu.edu Wed Jul 3 20:25:26 2002 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA15316 for ; Wed, 3 Jul 2002 20:25:26 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id g63NqGx12288 for ips-outgoing; Wed, 3 Jul 2002 19:52:16 -0400 (EDT) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from mercury.corp.iready.com ([65.115.68.100]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id g63NqEX12284 for ; Wed, 3 Jul 2002 19:52:14 -0400 (EDT) Received: by mercury.corp.iready.com with Internet Mail Service (5.5.2653.19) id ; Wed, 3 Jul 2002 16:52:08 -0700 Message-ID: <034670D62D19D31180990090277A37B7026A55C1@mercury.corp.iready.com> From: Michael Smith To: "'Black_David@emc.com'" , "'ips@ece.cmu.edu'" Cc: Michael Smith Subject: RE: iSCSI: Last call comments Date: Wed, 3 Jul 2002 16:52:04 -0700 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C222EC.A22316B0" Sender: owner-ips@ece.cmu.edu Precedence: bulk This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_001_01C222EC.A22316B0 Content-Type: text/plain; charset="iso-8859-1" I support David's suggested clarification and his suggested wording. I struggled for a while understanding this issue and the suggested changes make things much clearer. Mike Smith CTO, iReady -----Original Message----- From: Black_David@emc.com [mailto:Black_David@emc.com] Sent: Wednesday, July 03, 2002 2:54 PM To: mbakke@cisco.com; ips@ece.cmu.edu Subject: RE: iSCSI: Last call comments Mark, > There are a few sections in iSCSI (and ips-security) that discuss > IPsec requirements for "compliant/conformant implementations". I > recall that this meant a target implementation could either be a > single device with both iSCSI and IPsec, or a combination of two > devices, one that handles iSCSI; the other handling IPsec. In the two device combination, only the combination is compliant, and only at the interface(s) that provide(s) both iSCSI and IPsec. The iSCSI device in the combination is not compliant by itself because it does not provide IPsec. > As there are many cases where it makes a lot of sense to provide > the solution in two pieces (iSCSI in one or more devices, with one or > more IPsec front-end devices, I'd like to clarify this. > > How about (somewhere in section 7) adding something like: > > An iSCSI compliant initiator or target may provide the required > IPsec support either by itself, or in conjunction with an IPsec > front-end device. > > Any thoughts? It would need to have the word "compliant" removed and a sentence added to spell out what is compliant, along the lines of: An iSCSI initiator or target may provide the required IPsec support either by itself, or in conjunction with an IPsec front-end device. In the latter case only the combination complies with the requirements of this specification; the individual iSCSI initiator or target would not comply with the requirements of this specification due to the lack of IPsec support. It's probably a good idea to put this in. 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 --------------------------------------------------- > -----Original Message----- > From: Mark Bakke [mailto:mbakke@cisco.com] > Sent: Wednesday, July 03, 2002 5:48 PM > To: IPS > Subject: iSCSI: Last call comments > > > > The iSCSI draft is looking pretty good. I only have one last-call > comment left: > > There are a few sections in iSCSI (and ips-security) that discuss > IPsec requirements for "compliant/conformant implementations". I > recall that this meant a target implementation could either be a > single device with both iSCSI and IPsec, or a combination of two > devices, one that handles iSCSI; the other handling IPsec. However, > I couldn't find anywhere in the spec that spells this out either > way, other than a hint at it in item [3] on page 31 of > ips-security-13: > > > [3] IPsec is provided by a device external to the actual > iSCSI device. > > Here the iSCSI header and data CRCs can be kept across > the part of > > the connection that is not protected by IPsec. For > instance, the > > iSCSI connection could traverse an extra bus, interface card, > > network, interface card, and bus between the iSCSI > device and the > > device providing IPsec. In this case, the iSCSI CRC is > desirable, > > and the iSCSI implementation behind the IPsec device > may request > > it. > > As there are many cases where it makes a lot of sense to provide > the solution in two pieces (iSCSI in one or more devices, with one or > more IPsec front-end devices, I'd like to clarify this. > > How about (somewhere in section 7) adding something like: > > An iSCSI compliant initiator or target may provide the required > IPsec support either by itself, or in conjunction with an IPsec > front-end device. > > Any thoughts? > > -- > Mark > > > For reference, here are a few of the statements that would be > helped out by the above. > > iscsi-14 Section 7.3.1: > > An iSCSI compliant initiator or target MUST provide data integrity > and authentication by implementing IPsec [RFC2401] with > ESP [RFC2406] > in tunnel mode and MAY provide data integrity and > authentication by > implementing IPsec with ESP in transport mode. The IPsec > implementa- > tion MUST fulfill the following iSCSI specific requirements: > > iscsi-14 Section 7.3.2: > > An iSCSI compliant initiator or target MUST provide > confidentiality > by implementing IPsec [RFC2401] with ESP [RFC2406] in > tunnel mode and > MAY provide confidentiality by implementing IPsec with ESP > in trans- > port mode. with the following iSCSI specific requirements: > > iscsi-14 Section 7.3.3: > > - Conformant iSCSI implementations MUST support IKE Main Mode > and SHOULD support Aggressive Mode. > > --- > ips-security-13 Section 2.3.1: > > All IP block storage security compliant implementations MUST support > IPsec ESP [RFC2406] to provide security for both control packets and > data packets, as well as the replay protection mechanisms of IPsec. > When ESP is utilized, per-packet data origin authentication, integrity > and replay protection MUST be used. > > > -- > Mark A. Bakke > Cisco Systems > mbakke@cisco.com > 763.398.1054 > ------_=_NextPart_001_01C222EC.A22316B0 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable RE: iSCSI: Last call comments

I support David's suggested clarification and his = suggested wording. I struggled for a while understanding this issue and = the suggested changes make things much clearer.

Mike Smith
CTO, iReady

-----Original Message-----
From: Black_David@emc.com [mailto:Black_David@emc.com]
Sent: Wednesday, July 03, 2002 2:54 PM
To: mbakke@cisco.com; ips@ece.cmu.edu
Subject: RE: iSCSI: Last call comments


Mark,

> There are a few sections in iSCSI (and = ips-security) that discuss
> IPsec requirements for = "compliant/conformant implementations".  I
> recall that this meant a target implementation = could either be a
> single device with both iSCSI and IPsec, or a = combination of two
> devices, one that handles iSCSI; the other = handling IPsec.

In the two device combination, only the combination = is compliant,
and only at the interface(s) that provide(s) both = iSCSI and IPsec.
The iSCSI device in the combination is not compliant = by itself
because it does not provide IPsec.

> As there are many cases where it makes a lot of = sense to provide
> the solution in two pieces (iSCSI in one or = more devices, with one or
> more IPsec front-end devices, I'd like to = clarify this.
>
> How about (somewhere in section 7) adding = something like:
>
>    An iSCSI compliant initiator = or target may provide the required
>    IPsec support either by = itself, or in conjunction with an IPsec
>    front-end device.
>
> Any thoughts?

It would need to have the word "compliant" = removed and a sentence
added to spell out what is compliant, along the = lines of:

    An iSCSI initiator or target may = provide the required
    IPsec support either by itself, = or in conjunction with an IPsec
    front-end device.  In the = latter case only the combination
    complies with the requirements of = this specification; the
    individual iSCSI initiator or = target would not comply with
    the requirements of this = specification due to the lack of IPsec
    support.

It's probably a good idea to put this in.

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


> -----Original Message-----
> From: Mark Bakke [mailto:mbakke@cisco.com]
> Sent: Wednesday, July 03, 2002 5:48 PM
> To: IPS
> Subject: iSCSI: Last call comments
>
>
>
> The iSCSI draft is looking pretty good.  I = only have one last-call
> comment left:
>
> There are a few sections in iSCSI (and = ips-security) that discuss
> IPsec requirements for = "compliant/conformant implementations".  I
> recall that this meant a target implementation = could either be a
> single device with both iSCSI and IPsec, or a = combination of two
> devices, one that handles iSCSI; the other = handling IPsec.  However,
> I couldn't find anywhere in the spec that = spells this out either
> way, other than a hint at it in item [3] on = page 31 of
> ips-security-13:
>
> > [3]  IPsec is provided by a device = external to the actual
> iSCSI device.
> >      Here the = iSCSI header and data CRCs can be kept across
> the part of
> >      the = connection that is not protected by IPsec. For
> instance, the
> >      iSCSI = connection could traverse an extra bus, interface card,
> >      network, = interface card, and bus between the iSCSI
> device and the
> >      device = providing IPsec. In this case, the iSCSI CRC is
> desirable,
> >      and the = iSCSI implementation behind the IPsec device
> may request
> >      it.
>
> As there are many cases where it makes a lot of = sense to provide
> the solution in two pieces (iSCSI in one or = more devices, with one or
> more IPsec front-end devices, I'd like to = clarify this.
>
> How about (somewhere in section 7) adding = something like:
>
>    An iSCSI compliant initiator = or target may provide the required
>    IPsec support either by = itself, or in conjunction with an IPsec
>    front-end device.
>
> Any thoughts?
>
> --
> Mark
>
>
> For reference, here are a few of the statements = that would be
> helped out by the above.
>
> iscsi-14 Section 7.3.1:
>
>    An iSCSI compliant initiator = or target MUST provide data integrity
>    and authentication by = implementing IPsec [RFC2401] with
> ESP [RFC2406]
>    in tunnel mode and MAY = provide data integrity and
> authentication by
>    implementing IPsec with ESP = in transport mode. The IPsec
> implementa-
>    tion MUST fulfill the = following iSCSI specific requirements:
>
> iscsi-14 Section 7.3.2:
>
>    An iSCSI compliant initiator = or target MUST provide
> confidentiality
>    by implementing IPsec = [RFC2401] with ESP [RFC2406] in
> tunnel mode and
>    MAY provide confidentiality = by implementing IPsec with ESP
> in trans-
>    port mode. with the following = iSCSI specific requirements:
>
> iscsi-14 Section 7.3.3:
>
>      - Conformant = iSCSI implementations MUST support IKE Main Mode
>          = ;  and SHOULD support Aggressive Mode.
>
> ---
> ips-security-13 Section 2.3.1:
>
> All IP block storage security compliant = implementations MUST support
> IPsec ESP [RFC2406] to provide security for = both control packets and
> data packets, as well as the replay protection = mechanisms of IPsec.
> When ESP is utilized, per-packet data origin = authentication, integrity
> and replay protection MUST be used.
>
>
> --
> Mark A. Bakke
> Cisco Systems
> mbakke@cisco.com
> 763.398.1054
>

------_=_NextPart_001_01C222EC.A22316B0-- From owner-ips@ece.cmu.edu Thu Jul 4 02:01:07 2002 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA01153 for ; Thu, 4 Jul 2002 02:01:02 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id g645BfC21399 for ips-outgoing; Thu, 4 Jul 2002 01:11:41 -0400 (EDT) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from e21.nc.us.ibm.com (e21.nc.us.ibm.com [32.97.136.227]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id g645BZX21394 for ; Thu, 4 Jul 2002 01:11:36 -0400 (EDT) Received: from westrelay01.boulder.ibm.com (westrelay01.boulder.ibm.com [9.17.194.22]) by e21.nc.us.ibm.com (8.12.2/8.12.2) with ESMTP id g645BYRY146840; Thu, 4 Jul 2002 01:11:35 -0400 Received: from d03nm014.boulder.ibm.com (avpilot.boulder.ibm.com [9.17.203.135]) by westrelay01.boulder.ibm.com (8.11.1m3/NCO/VER6.2) with ESMTP id g645BXn103084; Wed, 3 Jul 2002 23:11:33 -0600 X-Priority: 1 (High) Importance: Normal Subject: RE: iSCSI: Decimal encoding - why 64 bits ? To: Black_David@emc.com Cc: "Julian Satran" , ips@ece.cmu.edu X-Mailer: Lotus Notes Release 5.0.7 March 21, 2001 Message-ID: From: "John Hufferd" Date: Wed, 3 Jul 2002 22:09:10 -0700 X-MIMETrack: Serialize by Router on D03NM014/03/M/IBM(Release 5.0.10 |March 22, 2002) at 07/03/2002 11:11:33 PM MIME-Version: 1.0 Content-type: text/plain; charset=us-ascii Sender: owner-ips@ece.cmu.edu Precedence: bulk I agree on the future proofing via support for allowing decimal values to go up to 64 bits. . . . John L. Hufferd Senior Technical Staff Member (STSM) IBM/SSG San Jose Ca Main Office (408) 256-0403, Tie: 276-0403, eFax: (408) 904-4688 Home Office (408) 997-6136, Cell: (408) 499-9702 Internet address: hufferd@us.ibm.com Black_David@emc.com@ece.cmu.edu on 07/03/2002 07:06:54 AM Sent by: owner-ips@ece.cmu.edu To: Julian Satran/Haifa/IBM@IBMIL cc: ips@ece.cmu.edu Subject: RE: iSCSI: Decimal encoding - why 64 bits ? Replying to a couple of messages on this topic. --- Use of decimal for binary items > There was NEVER a discussion about forbidding decimal for binary items. Ok, that's why it's now under discussion in WG Last Call. > It would be counterproductive to forbid them as they are so widely > used in programming. The request to forbid them seems to have evolved into a request to more carefully classify binary items into those that can ordinarily be expected to fit in 64 bits (decimal format ok) and those that will generally not fit (decimal format not ok, even if a particular value fits). This is consistent with our restriction of base-64 to large binary items. As Pat Thaler wrote: > 4.1 > binary-value includes regular-binary-value and large-binary-value. > regular-binary-value is for strings less than 64 bits and allows decimal > encoding. (It says less than 64 and decimal encoded binary strings are > always in bytes so the largest decimal encoded binary would be 56 bits.) > > 10.4 SRP: N,g,s,A,B,M and H(A | M | K) are binary-values > 10.5 CHAP: C and R are binary-values The only ones of these that should routinely fit in 64 bits are SRP's g (usually a small integer, even though it's mathematically a member of a very large binary field - I think Paul Koning missed the fact that generators tend to be single-digit numbers) and s (doesn't need to be a large number to get the job done). If any of the others happen to fit in 64 bits, that's a hint that something may be wrong with security (e.g., CHAP's C and R should be 128 bits - if either has 64 bits of leading zeroes, something's probably wrong). On this basis, I'm inclined to agree with Pat that: > Normally, the values defined as binary-values for SRP and CHAP would be > 64 bits or longer anyway, but someone could send short keys and encode > them in decimal according to the current draft. This should be eliminated. I would make an exception to allow decimal for SRP's g and possibly SRP's s for the sort of convenience reason that Julian gave above ("widely used in programming"). I'd recommend this change to large-binary-value with the exception of SRP's g and possibly SRP's s as the way forward. --- 64 vs. 32 bits > I went back to the mailing list - and there was a clear consensus to keep > it to 64 bits (my original proposal was unlimited and I suggested rhen 128 > to alleviate concerns about conversion difficulty for unlimited numbers). That matches what I recall from mailing list discussion, 32 bits was not considered at the time. > The issue was raised without checking the libraries: [... snip ...] > I don't know about Windmills - but I assume that most modern development > environments are supporting 64bit integers. I suspect the response to this is that not everyone is using a "modern development environment" ... ;-) > Are we going to take for granted any assertion made on the list? Yes and no. When someone working on an implementation reports that some aspect of the protocol spec is causing difficulty, we should at least believe that the person is in fact having some difficulty. Whether we should accept arbitrary proposals to remove difficulty is a different question (iSCSI is not a simple protocol - some things are going to be difficult/tricky to implement - TANSTAAFL*). On this particular issue, I don't see support for or the need to reduce the upper limit on size of numbers that can be encoded in decimal from 64 bits to 32 bits, but the US holiday is starting to get in the way of list discussion. What this would mean for implementers is that the string decoding logic must be able to handle decimal representations of integers that fit in 64 bits, but an implementation may restrict the allowed ranges of the values (negotiated for keys) to fit in 32 bits. This roughly matches what Mark Bakke described: > For what it's worth, none of the numeric values for iSCSI that > can be retrieved or set via the MIB require more than 32 bits > (other than counters, but I doubt we would ever send a counter > during negotiation :-). The allowable ranges just didn't need > more than that. > > Anyway, I haven't seen a need to provide support for 64-bit > values in our implementation yet, since none of the numeric > keys can have values that high. Allowing decimal values to go up to 64 bits in size strikes me as a reasonable "future-proofing" measure - in 20/20 hindsight, I would think that the SNMP folks wish they'd put 64 bit support into SMIv1/SNMPv1 even if there had been little use for it at the time. So, this change (64 to 32 bits) does not need to be made now, but I will be watching the mailing list early next week just in case some people who care about this have already signed off for the US holiday and have additional input to contribute. Thanks, --David p.s. * TANSTAAFL = There Ain't No Such Thing As A Free Lunch --------------------------------------------------- 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 --------------------------------------------------- From owner-ips@ece.cmu.edu Thu Jul 4 02:25:35 2002 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA08897 for ; Thu, 4 Jul 2002 02:25:35 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id g645rd922394 for ips-outgoing; Thu, 4 Jul 2002 01:53:39 -0400 (EDT) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from hotmail.com (f160.pav2.hotmail.com [64.4.37.160]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id g645raX22388 for ; Thu, 4 Jul 2002 01:53:36 -0400 (EDT) Received: from mail pickup service by hotmail.com with Microsoft SMTPSVC; Wed, 3 Jul 2002 22:53:30 -0700 Received: from 64.38.134.99 by pv2fd.pav2.hotmail.msn.com with HTTP; Thu, 04 Jul 2002 05:53:28 GMT X-Originating-IP: [64.38.134.99] From: "Bernard Aboba" To: ni1d@arrl.net, ips@ece.cmu.edu Subject: Re: IPS security draft: SRP groups Date: Wed, 03 Jul 2002 22:53:28 -0700 Mime-Version: 1.0 Content-Type: text/plain; format=flowed Message-ID: X-OriginalArrivalTime: 04 Jul 2002 05:53:30.0522 (UTC) FILETIME=[1FDB4FA0:01C2231F] Sender: owner-ips@ece.cmu.edu Precedence: bulk In answer to your question, here is a suggestion from Dan Simon for determining the appropriate generators for the IKE primes, for use with SRP. -----Original Message----- From: Dan Simon Sent: Friday, June 07, 2002 2:36 PM To: iscsi-security@external.cisco.com Subject: SRP groups To determine if a given g is a generator of the whole group (a necessary property for SRP), you need to know the factorization of (p - 1); you raise the candidate to the power of x for all x which are factors (not just prime factors) of p - 1, and reject it if you ever get 1 (mod p). In the case of the IKE primes, which are of the form p - 1 = 2q, q prime, just test that neither g^2 nor g^q are 1 (mod p); any g that passes that test will do. If the SRP primes were generated randomly, then their predecessors (i.e., p - 1) may not be easy to factor; but if they are, then you can choose a generator for them as I've described. Hope that helps, Dan ---------- Forwarded message ---------- Date: Wed, 10 Apr 2002 21:19:18 -0700 From: Tom Wu To: Bernard Aboba Cc: iscsi-security@external.cisco.com Subject: Re: SRP groups Bernard, I generated the non-IKE primes randomly. I did not go through the full process of generating numbers with optimized forms, nor did I attempt to prove them prime using a rigorous test. This was primarily because, at the time I generated them, those prepackged groups were intended mainly as a timesaver for people installing the SRP distribution; I expected many admins to generate their own groups, using the Open Source tconf tool in the SRP distribution, for their own peace of mind. The secondary reason was that the requirements/constraints for SRP groups are not quite the same as the IKE groups. The IKE groups have the prime as 7 (mod 8) because of the lower-bits optimization, and g = 2, which can be faster with some bignum implementations. This means that g generates the group of size (p-1)/2, whereas SRP requires that g generate the largest group of size (p-1), i.e. a primitive root. That said, I'd have no problem with re-using the IKE primes as the prime for SRP groups, using a different "g" such that it is a primitive root. That's already been done for bitlengths 768 and 1024. Tom _________________________________________________________________ MSN Photos is the easiest way to share and print your photos: http://photos.msn.com/support/worldwide.aspx From owner-ips@ece.cmu.edu Thu Jul 4 03:25:02 2002 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA10381 for ; Thu, 4 Jul 2002 03:25:02 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id g646ach23403 for ips-outgoing; Thu, 4 Jul 2002 02:36:38 -0400 (EDT) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from e1.ny.us.ibm.com (e1.ny.us.ibm.com [32.97.182.101]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id g646aYX23398 for ; Thu, 4 Jul 2002 02:36:34 -0400 (EDT) Received: from westrelay01.boulder.ibm.com (westrelay01.boulder.ibm.com [9.17.194.22]) by e1.ny.us.ibm.com (8.12.2/8.12.2) with ESMTP id g646aRg5257844; Thu, 4 Jul 2002 02:36:27 -0400 Received: from d03nm014.boulder.ibm.com (avpilot.boulder.ibm.com [9.17.203.135]) by westrelay01.boulder.ibm.com (8.11.1m3/NCO/VER6.2) with ESMTP id g646aPn75640; Thu, 4 Jul 2002 00:36:25 -0600 X-Priority: 1 (High) Importance: Normal Subject: RE: iSCSI: Login negotiation space To: pat_thaler@agilent.com Cc: "Julian Satran" , ips@ece.cmu.edu X-Mailer: Lotus Notes Release 5.0.7 March 21, 2001 Message-ID: From: "John Hufferd" Date: Wed, 3 Jul 2002 23:34:02 -0700 X-MIMETrack: Serialize by Router on D03NM014/03/M/IBM(Release 5.0.10 |March 22, 2002) at 07/04/2002 12:36:26 AM MIME-Version: 1.0 Content-type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ece.cmu.edu id g646aYX23399 Sender: owner-ips@ece.cmu.edu Precedence: bulk Content-Transfer-Encoding: 8bit Pat, I guess I do not see a real problem here. This is a buffering design issue, which if done well and dynamically, does not have a problem. It is not clear that anything needs to change. 16k is not very large (and many times this is divided into even smaller segments that are taken from a pool dynamically). And I have not seen the case where so many logins occurring at the same time that an real issue exists. Also, the issue of everyone stalling out, is in my opinion a matter of bad design. I do not believe there is an important issue here since regardless of what size you come up with, the theory of problems occurring with a bad design is the same. At some point there is always a limit of resources, and the design is what causes it to occur at one time versus another. I do not believe, that the fact that the 16k value is not fully used each time is an important issue. If the buffering is done well, there is very little unused space during high utilization. Also, I do not believe there is an important interlock issue. That is because we are talking about a large number of sessions being logged in, or there is not a problem to begin with. Therefore, to think that there are many that are so tied up with the C bit handling that they never free any space, is not a situation that I find probable. There will always be some logins that will be finishing up. If the one in a billion chance occurs that they run out of buffers in a well managed buffer pool, then "out of resources" error is approprate. Again, changing from 16k to a smaller value, is not an important issue, since you can always dynamically allocate smaller buffer segments on your way to meet a 16k need. . . . John L. Hufferd Senior Technical Staff Member (STSM) IBM/SSG San Jose Ca Main Office (408) 256-0403, Tie: 276-0403, eFax: (408) 904-4688 Home Office (408) 997-6136, Cell: (408) 499-9702 Internet address: hufferd@us.ibm.com pat_thaler@agilent.com@ece.cmu.edu on 07/03/2002 11:09:20 AM Sent by: owner-ips@ece.cmu.edu To: Julian Satran/Haifa/IBM@IBMIL, pat_thaler@agilent.com cc: ips@ece.cmu.edu Subject: RE: iSCSI: Login negotiation space Julian, I wouldn't object to the default PDU size being lowered, but that is not what I am suggesting. There is no conflict between having a default PDU size of 8k during login and having a requirement to support at least 4096 bytes of key=value data in a negotiation sequence. PDUs don't have to be full. The situation is no worse than having a MaxRecvDataSegmentLength of 8k when MaxBurstLength is 4k or having a 4 kbyte write with an 8kb byte MaxRecvDataSegmentLength. The default MaxRecvDataSegmentLength at 8k would still be useful when implementations were supporting very long authentication items. Also, a vendor might suport a larger negotiaton space for vendor specific keys. Such an implmentation could send a key like X-com.acme.HugeKeySet=yes. If the partner responds X-com.acme.HugeKeySet=yes, then it can proceed to send the hugh key set knowing that its partner supports it and therefore has allocated space for it. If it gets a no or NotUnderstood response, it doesn't send the extra keys. I disagree with your statement about deadlock. It is a real issue when throttling is engaged. Regards, Pat -----Original Message----- From: Julian Satran [mailto:Julian_Satran@il.ibm.com] Sent: Wednesday, July 03, 2002 8:34 AM To: pat_thaler@agilent.com Cc: ips@ece.cmu.edu Subject: RE: iSCSI: Login negotiation space Pat, 4k does not make too much sense either with default PDU size of 8k. Are you suggesting we limit this too to a lower value? Your deadlock example while academically correct is not very interesting as I assume that throttling can be done at the first buffer level. Julo From owner-ips@ece.cmu.edu Thu Jul 4 13:21:25 2002 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA21572 for ; Thu, 4 Jul 2002 13:21:25 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id g64GVYo23767 for ips-outgoing; Thu, 4 Jul 2002 12:31:34 -0400 (EDT) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from mail.brocade.com (sj6-b.brocade.com [63.121.140.220]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id g64GVWX23763 for ; Thu, 4 Jul 2002 12:31:33 -0400 (EDT) Received: from hq-ex-c3.brocade.com (hq-ex-c3 [192.168.126.211]) by mail.brocade.com (8.8.8+Sun/8.8.8) with ESMTP id JAA10941; Thu, 4 Jul 2002 09:30:45 -0700 (PDT) Received: by hq-ex-c3.brocade.com with Internet Mail Service (5.5.2653.19) id ; Thu, 4 Jul 2002 09:31:33 -0700 Message-ID: <2F37CED150E21640A9C6E75B8BE6AF830A4D90@hq-ex-4> From: Robert Snively To: "'Martins Krikis'" , Black_David@emc.com, Julian_Satran@il.ibm.com Cc: ips@ece.cmu.edu Subject: RE: iSCSI: Decimal encoding - why 64 bits ? Date: Thu, 4 Jul 2002 09:31:02 -0700 X-Mailer: Internet Mail Service (5.5.2653.19) Sender: owner-ips@ece.cmu.edu Precedence: bulk I would agree with Martins' statement: > I'd like to disagree about the programming part, > but more importantly, why don't we reinstate > the original request to forbid using decimal for > binary items? It is not a very useful way > of representing even short binary items because > there is no way to express the number of leading > 0-bytes, for example. In case there is a vote on > this, I'm against using decimal for binary items. > and cast my vote with his. From owner-ips@ece.cmu.edu Fri Jul 5 00:04:06 2002 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA02535 for ; Fri, 5 Jul 2002 00:04:06 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id g653UjN08836 for ips-outgoing; Thu, 4 Jul 2002 23:30:45 -0400 (EDT) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from lmail.actcom.co.il (smtp.actcom.co.il [192.114.47.13]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id g653UhX08832 for ; Thu, 4 Jul 2002 23:30:43 -0400 (EDT) Received: from JA31 ([192.115.26.20]) by lmail.actcom.co.il (8.11.6/8.11.6) with ESMTP id g653UeI03109; Fri, 5 Jul 2002 06:30:40 +0300 Message-ID: <002601c223d4$55448cf0$0100000a@JA31> From: "Julian Satran \(Actcom\)" To: "Martins Krikis" , References: <20020703235710.2960.qmail@web13702.mail.yahoo.com> Subject: Re: iSCSI: base64-constant small editorial changes Date: Fri, 5 Jul 2002 06:30:38 +0300 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2600.0000 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 Sender: owner-ips@ece.cmu.edu Precedence: bulk Content-Transfer-Encoding: 7bit Thanks - Julo ----- Original Message ----- From: "Martins Krikis" To: Cc: Sent: Thursday, July 04, 2002 2:57 AM Subject: iSCSI: base64-constant small editorial changes > Page 71, base64-constant definition: > > "Base64-constants are used to encode > numerical-values or binary strings." should say > "large-numerical-values or binary strings", > since it is not allowed for the regular ones. > > typo in "(encoded a A)". > > > Thanks, > > Martins Krikis, Intel Corp. > > > __________________________________________________ > Do You Yahoo!? > Sign up for SBC Yahoo! Dial - First Month Free > http://sbc.yahoo.com From owner-ips@ece.cmu.edu Fri Jul 5 00:06:00 2002 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA02568 for ; Fri, 5 Jul 2002 00:06:00 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id g653sS809383 for ips-outgoing; Thu, 4 Jul 2002 23:54:28 -0400 (EDT) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from lmail.actcom.co.il (smtp.actcom.co.il [192.114.47.13]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id g653sPX09378 for ; Thu, 4 Jul 2002 23:54:25 -0400 (EDT) Received: from JA31 ([192.115.26.20]) by lmail.actcom.co.il (8.11.6/8.11.6) with ESMTP id g653sMI06251 for ; Fri, 5 Jul 2002 06:54:22 +0300 Message-ID: <008701c223d7$a506eaf0$0100000a@JA31> From: "Julian Satran \(Actcom\)" To: "ips" Date: Fri, 5 Jul 2002 06:54:20 +0300 MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="----=_NextPart_000_0083_01C223F0.CA140CB0" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2600.0000 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 Sender: owner-ips@ece.cmu.edu Precedence: bulk This is a multi-part message in MIME format. ------=_NextPart_000_0083_01C223F0.CA140CB0 Content-Type: multipart/alternative; boundary="----=_NextPart_001_0084_01C223F0.CA159350" ------=_NextPart_001_0084_01C223F0.CA159350 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Leading 0 where forbidden after a brief discussion. As for unlikely to be used - I could argue for the contrary - as in the = examples I gave in a previous notes. Many string copied from humanly readable documents tend to be = decimal-encoded. Julo ------=_NextPart_001_0084_01C223F0.CA159350 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
Leading 0 where forbidden after a brief = discussion.
As for unlikely to be used - I could = argue for the=20 contrary - as in the examples I gave in a previous notes.
Many string copied from humanly = readable documents=20 tend to be decimal-encoded.
 
Julo
------=_NextPart_001_0084_01C223F0.CA159350-- ------=_NextPart_000_0083_01C223F0.CA140CB0 Content-Type: message/rfc822; name="iSCSI_ leading zeros and decimal-encoded binary strings.eml" Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename="iSCSI_ leading zeros and decimal-encoded binary strings.eml" Return-Path: X-Sieve: cmu-sieve 2.0 Received: from lmail.actcom.co.il (smtp.actcom.co.il [192.114.47.13]) by mail3.actcom.co.il (8.11.6/8.11.6) with ESMTP id g62NGfX27943 for ; Wed, 3 Jul 2002 02:16:41 +0300 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200]) by lmail.actcom.co.il (8.11.6/8.11.6) with ESMTP id g62NGef14724 for ; Wed, 3 Jul 2002 02:16:40 +0300 Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id g62LxM700234 for ips-outgoing; Tue, 2 Jul 2002 17:59:22 -0400 (EDT) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from lion.ninthwonder.com (lion.ninthwonder.com [151.199.66.147]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id g62LxKX00228 for ; Tue, 2 Jul 2002 17:59:20 -0400 (EDT) Received: by lion.ninthwonder.com (Postfix, from userid 1021) id 7026E30706; Tue, 2 Jul 2002 17:59:20 -0400 (EDT) Date: Tue, 2 Jul 2002 14:56:20 -0700 (PDT) From: Bill Studenmund X-X-Sender: To: Subject: iSCSI: leading zeros and decimal-encoded binary strings Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ips@ece.cmu.edu Precedence: bulk Here's the heart of what I dislike about decimal-encoded binary strings: how do you convey the length of the binary string when you have leading zero bits? -14 says: "When used to encode binary strings decimal constants have an implicit byte-length that is the minimum number of bytes needed to represent the base2 encoding of the decimal number." How do leading zeros impact the "base2 encoding .."? Consider "012". Obviously the number is 12. The question is how many bytes are in the binary string? Is it one, since a number of three decimal digit numbers fit in one byte (up to "255"), or is it two bytes in the string since other three-decimal-digit numbers won't fit in one byte ("256" through "999")? The spec isn't clear, at least not to me. Ok, so one or two-byte strings aren't that likely. The problem though is that all of the byte sizes don't line up nicely with decimal digits (since 2^x = 10^y only works for x=0, y=0 AFAIK). Since we can't force that binary strings don't start with a zero-byte (or two), we need to support some way of communicating how long such a string is. Two suggestions: 1) Rip out the decimal binary strings bit 2) Come up with a table saying if you have so many digits which contain leading zeros, you have a binary string of so many bytes. Examples: String: Bytes in binary string: 00000000000000000012 8 00072057594037927935 8 00000000000000012 7 00281474976710655 7 000000000000012 6 001099511627775 6 0000000000012 5 0004294967295 5 0000000012 4 0016777215 4 00000012 3 00065535 3 00012 2 00255 2 The advantage of such a method is that you can easily force the right number of leading zeros with printf format strings. For instance, printf("%010d", an-int32-type) will do the right thing. But we need to communicate that in the spec, and we don't. Thoughts? Take care, Bill P.S. I will be on vacation starting tomorrow through the weekend. ------=_NextPart_000_0083_01C223F0.CA140CB0 Content-Type: message/rfc822; name="RE_ iSCSI_ leading zeros and decimal-encoded binary strings.eml" Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename="RE_ iSCSI_ leading zeros and decimal-encoded binary strings.eml" Return-Path: X-Sieve: cmu-sieve 2.0 Received: from lmail.actcom.co.il (mail.actcom.co.il [192.114.47.13]) by mail3.actcom.co.il (8.11.6/8.11.6) with ESMTP id g62NsFX29674 for ; Wed, 3 Jul 2002 02:54:15 +0300 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200]) by lmail.actcom.co.il (8.11.6/8.11.6) with ESMTP id g62NsEf23821 for ; Wed, 3 Jul 2002 02:54:15 +0300 Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id g62N9L702996 for ips-outgoing; Tue, 2 Jul 2002 19:09:21 -0400 (EDT) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from msgbas1.cos.agilent.com (msgbas1x.cos.agilent.com [192.25.240.36]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id g62N9KX02992 for ; Tue, 2 Jul 2002 19:09:20 -0400 (EDT) Received: from msgrel1t.cos.agilent.com (msgrel1t.cos.agilent.com [130.29.152.157]) by msgbas1.cos.agilent.com (Postfix) with ESMTP id 3302A9E3D; Tue, 2 Jul 2002 17:09:16 -0600 (MDT) Received: from axcsbh4.cos.agilent.com (axcsbh4.cos.agilent.com [130.29.152.145]) by msgrel1t.cos.agilent.com (Postfix) with SMTP id 83BE0525; Tue, 2 Jul 2002 17:09:15 -0600 (MDT) Received: from 130.29.152.145 by axcsbh4.cos.agilent.com (InterScan E-Mail VirusWall NT); Tue, 02 Jul 2002 17:09:13 -0600 Received: by axcsbh4.cos.agilent.com with Internet Mail Service (5.5.2653.19) id ; Tue, 2 Jul 2002 17:09:13 -0600 Message-ID: <1BEBA5E8600DD4119A50009027AF54A00CB26D81@axcs04.cos.agilent.com> From: pat_thaler@agilent.com To: wrstuden@wasabisystems.com, ips@ece.cmu.edu Subject: RE: iSCSI: leading zeros and decimal-encoded binary strings Date: Tue, 2 Jul 2002 17:09:13 -0600 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-ips@ece.cmu.edu Precedence: bulk Bill, There is an additional thing I don't like about decimal-encoded binary strings. We will have to put in support for a feature that is unlikely to be used. The only items defined as binary-values are CHAP and SRP binary strings which usually will be too long for decimal encoding anyway. Take CHAP for instance. It C and R are defined as binary-values. R is 16 bytes so it can't be decimal encoded. C shorter than 8 bytes seems unlikely. My preference would be to replace the definition of binary-value with the current definition of large-binary value, replace large-binary-value with binary-value (in 10.2 and 10.3) and get rid of regular-binary-value and large-binary-value. Regards, Pat -----Original Message----- From: Bill Studenmund [mailto:wrstuden@wasabisystems.com] Sent: Tuesday, July 02, 2002 2:56 PM To: ips@ece.cmu.edu Subject: iSCSI: leading zeros and decimal-encoded binary strings Here's the heart of what I dislike about decimal-encoded binary strings: how do you convey the length of the binary string when you have leading zero bits? -14 says: "When used to encode binary strings decimal constants have an implicit byte-length that is the minimum number of bytes needed to represent the base2 encoding of the decimal number." How do leading zeros impact the "base2 encoding .."? Consider "012". Obviously the number is 12. The question is how many bytes are in the binary string? Is it one, since a number of three decimal digit numbers fit in one byte (up to "255"), or is it two bytes in the string since other three-decimal-digit numbers won't fit in one byte ("256" through "999")? The spec isn't clear, at least not to me. Ok, so one or two-byte strings aren't that likely. The problem though is that all of the byte sizes don't line up nicely with decimal digits (since 2^x = 10^y only works for x=0, y=0 AFAIK). Since we can't force that binary strings don't start with a zero-byte (or two), we need to support some way of communicating how long such a string is. Two suggestions: 1) Rip out the decimal binary strings bit 2) Come up with a table saying if you have so many digits which contain leading zeros, you have a binary string of so many bytes. Examples: String: Bytes in binary string: 00000000000000000012 8 00072057594037927935 8 00000000000000012 7 00281474976710655 7 000000000000012 6 001099511627775 6 0000000000012 5 0004294967295 5 0000000012 4 0016777215 4 00000012 3 00065535 3 00012 2 00255 2 The advantage of such a method is that you can easily force the right number of leading zeros with printf format strings. For instance, printf("%010d", an-int32-type) will do the right thing. But we need to communicate that in the spec, and we don't. Thoughts? Take care, Bill P.S. I will be on vacation starting tomorrow through the weekend. ------=_NextPart_000_0083_01C223F0.CA140CB0 Content-Type: message/rfc822; name="RE_ iSCSI_ leading zeros and decimal-encoded binary strings.eml" Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename="RE_ iSCSI_ leading zeros and decimal-encoded binary strings.eml" Return-Path: X-Sieve: cmu-sieve 2.0 Received: from lmail.actcom.co.il (smtp.actcom.co.il [192.114.47.13]) by mail3.actcom.co.il (8.11.6/8.11.6) with ESMTP id g631WGX02492 for ; Wed, 3 Jul 2002 04:32:16 +0300 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200]) by lmail.actcom.co.il (8.11.6/8.11.6) with ESMTP id g631WEf13344 for ; Wed, 3 Jul 2002 04:32:14 +0300 Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id g62NeG304181 for ips-outgoing; Tue, 2 Jul 2002 19:40:16 -0400 (EDT) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from lion.ninthwonder.com (lion.ninthwonder.com [151.199.66.147]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id g62NeEX04176 for ; Tue, 2 Jul 2002 19:40:14 -0400 (EDT) Received: by lion.ninthwonder.com (Postfix, from userid 1021) id BAB6930706; Tue, 2 Jul 2002 19:40:13 -0400 (EDT) Date: Tue, 2 Jul 2002 16:37:13 -0700 (PDT) From: Bill Studenmund X-X-Sender: To: Cc: Subject: RE: iSCSI: leading zeros and decimal-encoded binary strings In-Reply-To: <1BEBA5E8600DD4119A50009027AF54A00CB26D81@axcs04.cos.agilent.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ips@ece.cmu.edu Precedence: bulk On Tue, 2 Jul 2002 pat_thaler@agilent.com wrote: > Bill, > > There is an additional thing I don't like about decimal-encoded binary > strings. We will have to put in support for a feature that is unlikely > to be used. The only items defined as binary-values are CHAP and SRP > binary strings which usually will be too long for decimal encoding > anyway. > > Take CHAP for instance. It C and R are defined as binary-values. R is > 16 bytes so it can't be decimal encoded. C shorter than 8 bytes seems > unlikely. > > My preference would be to replace the definition of binary-value with > the current definition of large-binary value, replace > large-binary-value with binary-value (in 10.2 and 10.3) and get rid of > regular-binary-value and large-binary-value. That's my prefered choice. Take care, Bill ------=_NextPart_000_0083_01C223F0.CA140CB0-- From owner-ips@ece.cmu.edu Fri Jul 5 00:09:50 2002 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA02613 for ; Fri, 5 Jul 2002 00:09:49 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id g653jgT09167 for ips-outgoing; Thu, 4 Jul 2002 23:45:42 -0400 (EDT) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from lmail.actcom.co.il (smtp.actcom.co.il [192.114.47.13]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id g653jdX09162 for ; Thu, 4 Jul 2002 23:45:39 -0400 (EDT) Received: from JA31 ([192.115.26.20]) by lmail.actcom.co.il (8.11.6/8.11.6) with ESMTP id g653jXI05025; Fri, 5 Jul 2002 06:45:34 +0300 Message-ID: <005701c223d6$6a16ae40$0100000a@JA31> From: "Julian Satran \(Actcom\)" To: "Bill Studenmund" Cc: References: Subject: Re: iSCSI: Decimal encoding - why 64 bits ? Date: Fri, 5 Jul 2002 06:45:31 +0300 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2600.0000 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 Sender: owner-ips@ece.cmu.edu Precedence: bulk Content-Transfer-Encoding: 7bit If you fear about extended precision arithmetic you should carefully look at what key=values are. Precluding the use of large numerical values by forbidding their encoding is not a good way of considering this - we have also base64 for large numbers (and hex) and if you have to have a use for larger numbers you have to have the arithmetic to handle it. As for the second subject - forbidding the use decimals for binary strings - we never discussed it or agreed on this. I wonder how natural it will feel for somebody to have and IP address encoded exclusively in hex, or a TargetPortalGroup appearing as decimal in a directory and having to be transliterated. Julo ----- Original Message ----- From: "Bill Studenmund" To: "Julian Satran" Cc: Sent: Wednesday, July 03, 2002 12:22 AM Subject: RE: iSCSI: Decimal encoding - why 64 bits ? > On Tue, 2 Jul 2002, Julian Satran wrote: > > > It was never supposed to be removed. Many values are passed around as > > decimal. > > We can't make any progress if we keep hitting the same things > > again-and-again after a decent consensus has been reached. > > The question is does the draft reflect the concensus that all the > discussion participants thought they achieved? > > At least one other person had the same impression I did about the past > discussion. i.e. we thought we HAD achieved concensus, and yet the draft > does not reflect that discussion. > > > And none of you has brought an argument that was not heard and dismissed > > before. > > When were these arguements dismissed? While I recall a lot of disagreement > on points, I don't recall a sound dismissal on technical grounds. > > > Remember we moved from unlimited length decimal to 64 bit to alleviate > > implementer fears. > > Julian, those fears were for something else. Those fears were for how do > you deal with extended-precision math when reading a large number. > > These concerns are that decimal encoding of binary strings suffers from > many of the problems that base64 had for numbers - the need to perform > arithmetic to byte-string conversion (i.e. hotns() and htonl() & friends). > > Now that the text explicitly states that the string size is in whole > bytes, things aren't as weird as before. But it's still messy. I'll post a > seperate message on this. > > Take care, > > Bill > From owner-ips@ece.cmu.edu Fri Jul 5 00:45:21 2002 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA03001 for ; Fri, 5 Jul 2002 00:45:21 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id g6548jK09738 for ips-outgoing; Fri, 5 Jul 2002 00:08:45 -0400 (EDT) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from lmail.actcom.co.il (smtp.actcom.co.il [192.114.47.13]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id g6548gX09734 for ; Fri, 5 Jul 2002 00:08:42 -0400 (EDT) Received: from JA31 ([192.115.26.20]) by lmail.actcom.co.il (8.11.6/8.11.6) with ESMTP id g6548SI08457; Fri, 5 Jul 2002 07:08:28 +0300 Message-ID: <00c401c223d9$9e1002c0$0100000a@JA31> From: "Julian Satran \(Actcom\)" To: , Cc: , References: <1BEBA5E8600DD4119A50009027AF54A00CE07248@axcs04.cos.agilent.com> Subject: Re: iSCSI: draft vs. 14 typos, suggestion, questions Date: Fri, 5 Jul 2002 07:08:26 +0300 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 8bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2600.0000 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 Sender: owner-ips@ece.cmu.edu Precedence: bulk Content-Transfer-Encoding: 8bit I will do the text change (I hope it makes it easier for at least one reader is not worse for anybody else). The reason why we choose the wording was that SAM associates the task set with an initiator by the session is wording is equivalent. Julo ----- Original Message ----- From: To: ; Cc: ; Sent: Wednesday, July 03, 2002 9:38 PM Subject: RE: iSCSI: draft vs. 14 typos, suggestion, questions > See comment below. Pat > -----Original Message----- > From: Julian Satran [mailto:Julian_Satran@il.ibm.com] > Sent: Wednesday, July 03, 2002 9:20 AM > To: Tomá? Bartu?ek > Cc: ips@ece.cmu.edu; ivan.pavelka@s3group.com > Subject: Re: iSCSI: draft vs. 14 typos, suggestion, questions > > > > *** Section 6.11 : QUESTION > Draft says: > When the session timeout (the connection state timeout for the last > failed connection) happens on the target, it takes the following > actions: > > - Resets or closes the TCP connections (closes the session). > - Aborts all Tasks in the task set for the corresponding initi- > ator. > > What does the "corresponding initiator" mean? We think (:-)), that > there is only one initiator for the session. The only possible > explanation we see for that paragraph is, that the target should > abort also other tasks of the same in __other__ sessions, but > why? > +++ your interpretation is correct - the statement means the initiator that "owned" the session. > Are you suggesting other wording? > ++++ > "Aborts all task sets associated with the session" > (Task set was changed to plural because task set is defined as an I-T-L nexus and there may be muliple ones in the session. > From owner-ips@ece.cmu.edu Fri Jul 5 00:53:30 2002 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA03090 for ; Fri, 5 Jul 2002 00:53:30 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id g654DNb09830 for ips-outgoing; Fri, 5 Jul 2002 00:13:23 -0400 (EDT) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from lmail.actcom.co.il (smtp.actcom.co.il [192.114.47.13]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id g654DLX09826 for ; Fri, 5 Jul 2002 00:13:21 -0400 (EDT) Received: from JA31 ([192.115.26.20]) by lmail.actcom.co.il (8.11.6/8.11.6) with ESMTP id g654CuI09222; Fri, 5 Jul 2002 07:12:56 +0300 Message-ID: <00ca01c223da$3cf6dfd0$0100000a@JA31> From: "Julian Satran \(Actcom\)" To: "Martins Krikis" , Cc: References: <20020703234511.96656.qmail@web13709.mail.yahoo.com> Subject: Re: iSCSI: Decimal encoding - why 64 bits ? Date: Fri, 5 Jul 2002 07:12:54 +0300 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2600.0000 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 Sender: owner-ips@ece.cmu.edu Precedence: bulk Content-Transfer-Encoding: 7bit Martins - you have a very good point - and we considered briefly to forbid decimal from the outset but many of the team felt that this would be a bad idea as values get copied from a context to another. And the we looked at coding for other RFCs and we found decimal everywhere - addresses, identifiers, ports etc., and thought it would be a bad idea to forbid them in iSCSI Julo ----- Original Message ----- From: "Martins Krikis" To: ; Cc: Sent: Thursday, July 04, 2002 2:45 AM Subject: RE: iSCSI: Decimal encoding - why 64 bits ? > --- Black_David@emc.com wrote: > > > Replying to a couple of messages on this topic. > > > > --- Use of decimal for binary items > > > > > There was NEVER a discussion about forbidding > > decimal for binary items. > > There may not have been a big discussion about it, > since everybody was concentrating on disallowing > base64 for numbers (yes, all of them; IMO most > people seemed to think that binary strings would > suffice and that large-numerical-values aren't > necessary) or on limiting the size numerical values > encoded in decimal. But it was certainly mentioned > multiple times under various subject lines: > > http://www.pdl.cmu.edu/mailinglists/ips/mail/msg09780.html > > http://www.pdl.cmu.edu/mailinglists/ips/mail/msg10125.html > > http://www.pdl.cmu.edu/mailinglists/ips/mail/msg10153.html > > http://www.pdl.cmu.edu/mailinglists/ips/mail/msg10250.html > > > > It would be counterproductive to forbid them > > > as they are so widely used in programming. > > > The request to forbid them seems to have evolved > > into a request to > > I'd like to disagree about the programming part, > but more importantly, why don't we reinstate > the original request to forbid using decimal for > binary items? It is not a very useful way > of representing even short binary items because > there is no way to express the number of leading > 0-bytes, for example. In case there is a vote on > this, I'm against using decimal for binary items. > > > --- 64 vs. 32 bits > > > > I went back to the mailing list - and there was a > > clear consensus to keep > > it to 64 bits (my original proposal was unlimited > > and I suggested rhen 128 > > to alleviate concerns about conversion difficulty > > for unlimited numbers). > > > > That matches what I recall from mailing list > > discussion, 32 bits was not > > considered at the time. > > Getting it down from unlimited was way more > important than getting it down to 32, but it > certainly was considered: > > http://www.pdl.cmu.edu/mailinglists/ips/mail/msg09804.html > > http://www.pdl.cmu.edu/mailinglists/ips/mail/msg09808.html > > http://www.pdl.cmu.edu/mailinglists/ips/mail/msg09810.html > > > > > The issue was raised without checking the > > > libraries: > > > > [... snip ...] > > > > > I don't know about Windmills - but I assume > > > that most modern development > > > environments are supporting 64bit integers. > > Some of us are working in kernel-space, and there > aren't many reasons for a kernel running on a 32-bit > architecture to provide 64-bit integer conversion > routines. > > I am not saying that I don't know how to write > such a routine, just that there are normal reasons > why some people may prefer 32 to 64. In case there > is a vote, I'm for 32. > > Martins Krikis, Intel Corp. > > Disclaimer: these opinions are mine and may not > be those of my employer. > > > > __________________________________________________ > Do You Yahoo!? > Sign up for SBC Yahoo! Dial - First Month Free > http://sbc.yahoo.com From owner-ips@ece.cmu.edu Fri Jul 5 05:41:48 2002 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA15991 for ; Fri, 5 Jul 2002 05:41:48 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id g658uhu17124 for ips-outgoing; Fri, 5 Jul 2002 04:56:43 -0400 (EDT) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from lmail.actcom.co.il (smtp.actcom.co.il [192.114.47.13]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id g658ucX17118 for ; Fri, 5 Jul 2002 04:56:39 -0400 (EDT) Received: from JA31 ([192.115.26.20]) by lmail.actcom.co.il (8.11.6/8.11.6) with ESMTP id g658uBI05101; Fri, 5 Jul 2002 11:56:12 +0300 Message-ID: <010901c22401$cf586840$0100000a@JA31> From: "Julian Satran \(Actcom\)" To: "Michael Smith" , , Cc: "Michael Smith" References: <034670D62D19D31180990090277A37B7026A55C1@mercury.corp.iready.com> Subject: Re: iSCSI: Last call comments Date: Fri, 5 Jul 2002 11:56:09 +0300 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0106_01C2241A.F37584B0" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2600.0000 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 Sender: owner-ips@ece.cmu.edu Precedence: bulk This is a multi-part message in MIME format. ------=_NextPart_000_0106_01C2241A.F37584B0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable RE: iSCSI: Last call commentsI would suggest the following text for 7.3 An iSCSI initiator or target may provide the required IPsec support = either fully integrated or in conjunction with an IPsec front-end = device. In the later case the term iSCSI target reffers to the target = and IPsec front-end and compliance requirements apply to the "combined = device".=20 Julo ----- Original Message -----=20 From: Michael Smith=20 To: 'Black_David@emc.com' ; 'ips@ece.cmu.edu'=20 Cc: Michael Smith=20 Sent: Thursday, July 04, 2002 2:52 AM Subject: RE: iSCSI: Last call comments I support David's suggested clarification and his suggested wording. I = struggled for a while understanding this issue and the suggested changes = make things much clearer. Mike Smith=20 CTO, iReady=20 -----Original Message-----=20 From: Black_David@emc.com [mailto:Black_David@emc.com]=20 Sent: Wednesday, July 03, 2002 2:54 PM=20 To: mbakke@cisco.com; ips@ece.cmu.edu=20 Subject: RE: iSCSI: Last call comments=20 Mark,=20 > There are a few sections in iSCSI (and ips-security) that discuss=20 > IPsec requirements for "compliant/conformant implementations". I=20 > recall that this meant a target implementation could either be a=20 > single device with both iSCSI and IPsec, or a combination of two=20 > devices, one that handles iSCSI; the other handling IPsec.=20 In the two device combination, only the combination is compliant,=20 and only at the interface(s) that provide(s) both iSCSI and IPsec.=20 The iSCSI device in the combination is not compliant by itself=20 because it does not provide IPsec.=20 > As there are many cases where it makes a lot of sense to provide=20 > the solution in two pieces (iSCSI in one or more devices, with one = or=20 > more IPsec front-end devices, I'd like to clarify this.=20 >=20 > How about (somewhere in section 7) adding something like:=20 >=20 > An iSCSI compliant initiator or target may provide the required=20 > IPsec support either by itself, or in conjunction with an IPsec=20 > front-end device.=20 >=20 > Any thoughts?=20 It would need to have the word "compliant" removed and a sentence=20 added to spell out what is compliant, along the lines of:=20 An iSCSI initiator or target may provide the required=20 IPsec support either by itself, or in conjunction with an IPsec=20 front-end device. In the latter case only the combination=20 complies with the requirements of this specification; the=20 individual iSCSI initiator or target would not comply with=20 the requirements of this specification due to the lack of IPsec=20 support.=20 It's probably a good idea to put this in.=20 Thanks,=20 --David=20 ---------------------------------------------------=20 David L. Black, Senior Technologist=20 EMC Corporation, 42 South St., Hopkinton, MA 01748=20 +1 (508) 249-6449 FAX: +1 (508) 497-8018=20 black_david@emc.com Mobile: +1 (978) 394-7754=20 ---------------------------------------------------=20 > -----Original Message-----=20 > From: Mark Bakke [mailto:mbakke@cisco.com]=20 > Sent: Wednesday, July 03, 2002 5:48 PM=20 > To: IPS=20 > Subject: iSCSI: Last call comments=20 >=20 >=20 >=20 > The iSCSI draft is looking pretty good. I only have one last-call=20 > comment left:=20 >=20 > There are a few sections in iSCSI (and ips-security) that discuss=20 > IPsec requirements for "compliant/conformant implementations". I=20 > recall that this meant a target implementation could either be a=20 > single device with both iSCSI and IPsec, or a combination of two=20 > devices, one that handles iSCSI; the other handling IPsec. However, = > I couldn't find anywhere in the spec that spells this out either=20 > way, other than a hint at it in item [3] on page 31 of=20 > ips-security-13:=20 >=20 > > [3] IPsec is provided by a device external to the actual=20 > iSCSI device.=20 > > Here the iSCSI header and data CRCs can be kept across=20 > the part of=20 > > the connection that is not protected by IPsec. For=20 > instance, the=20 > > iSCSI connection could traverse an extra bus, interface card, = > > network, interface card, and bus between the iSCSI=20 > device and the=20 > > device providing IPsec. In this case, the iSCSI CRC is=20 > desirable,=20 > > and the iSCSI implementation behind the IPsec device=20 > may request=20 > > it.=20 >=20 > As there are many cases where it makes a lot of sense to provide=20 > the solution in two pieces (iSCSI in one or more devices, with one = or=20 > more IPsec front-end devices, I'd like to clarify this.=20 >=20 > How about (somewhere in section 7) adding something like:=20 >=20 > An iSCSI compliant initiator or target may provide the required=20 > IPsec support either by itself, or in conjunction with an IPsec=20 > front-end device.=20 >=20 > Any thoughts?=20 >=20 > --=20 > Mark=20 >=20 >=20 > For reference, here are a few of the statements that would be=20 > helped out by the above.=20 >=20 > iscsi-14 Section 7.3.1:=20 >=20 > An iSCSI compliant initiator or target MUST provide data = integrity=20 > and authentication by implementing IPsec [RFC2401] with=20 > ESP [RFC2406]=20 > in tunnel mode and MAY provide data integrity and=20 > authentication by=20 > implementing IPsec with ESP in transport mode. The IPsec=20 > implementa-=20 > tion MUST fulfill the following iSCSI specific requirements:=20 >=20 > iscsi-14 Section 7.3.2:=20 >=20 > An iSCSI compliant initiator or target MUST provide=20 > confidentiality=20 > by implementing IPsec [RFC2401] with ESP [RFC2406] in=20 > tunnel mode and=20 > MAY provide confidentiality by implementing IPsec with ESP=20 > in trans-=20 > port mode. with the following iSCSI specific requirements:=20 >=20 > iscsi-14 Section 7.3.3:=20 >=20 > - Conformant iSCSI implementations MUST support IKE Main Mode=20 > and SHOULD support Aggressive Mode.=20 >=20 > ---=20 > ips-security-13 Section 2.3.1:=20 >=20 > All IP block storage security compliant implementations MUST support = > IPsec ESP [RFC2406] to provide security for both control packets and = > data packets, as well as the replay protection mechanisms of IPsec.=20 > When ESP is utilized, per-packet data origin authentication, = integrity=20 > and replay protection MUST be used.=20 >=20 >=20 > --=20 > Mark A. Bakke=20 > Cisco Systems=20 > mbakke@cisco.com=20 > 763.398.1054=20 >=20 ------=_NextPart_000_0106_01C2241A.F37584B0 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable RE: iSCSI: Last call comments
I would suggest the following text for=20 7.3
 

An iSCSI initiator or target may provide the required IPsec support = either=20 fully integrated or in conjunction with an IPsec front-end device. In = the later=20 case the term iSCSI target reffers to the target and IPsec front-end and = compliance requirements apply to the "combined device".

Julo
----- Original Message -----
From:=20 Michael=20 Smith
To: 'Black_David@emc.com' ; 'ips@ece.cmu.edu'=20
Sent: Thursday, July 04, 2002 = 2:52=20 AM
Subject: RE: iSCSI: Last call=20 comments

I support David's suggested clarification and his = suggested=20 wording. I struggled for a while understanding this issue and the = suggested=20 changes make things much clearer.

Mike Smith
CTO, = iReady

-----Original Message-----
From: Black_David@emc.com [mailto:Black_David@emc.com]=20
Sent: Wednesday, July 03, 2002 2:54 PM =
To: mbakke@cisco.com; = ips@ece.cmu.edu
Subject: RE: iSCSI: Last call comments


Mark,

> There are a few sections in iSCSI (and = ips-security) that=20 discuss
> IPsec requirements for=20 "compliant/conformant implementations".  I
>=20 recall that this meant a target implementation could either be = a=20
> single device with both iSCSI and IPsec, or a=20 combination of two
> devices, one that = handles=20 iSCSI; the other handling IPsec.

In the two device combination, only the combination = is=20 compliant,
and only at the interface(s) that = provide(s) both iSCSI and IPsec.
The iSCSI = device in=20 the combination is not compliant by itself
because it=20 does not provide IPsec.

> As there are many cases where it makes a lot of = sense to=20 provide
> the solution in two pieces = (iSCSI in one=20 or more devices, with one or
> more IPsec = front-end=20 devices, I'd like to clarify this.
>=20
> How about (somewhere in section 7) = adding=20 something like:
>
>    An iSCSI compliant initiator or target = may=20 provide the required
>    = IPsec=20 support either by itself, or in conjunction with an IPsec =
>    front-end device.
>=20
> Any thoughts?

It would need to have the word "compliant" removed = and a=20 sentence
added to spell out what is = compliant, along=20 the lines of:

    An iSCSI initiator or target may = provide=20 the required
    IPsec = support either=20 by itself, or in conjunction with an IPsec
    front-end device.  In the latter case = only the=20 combination
    complies with = the=20 requirements of this specification; the
    individual iSCSI initiator or target would = not=20 comply with
    the = requirements of=20 this specification due to the lack of IPsec
    support.

It's probably a good idea to put this in. =

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


> -----Original Message-----
>=20 From: Mark Bakke [mailto:mbakke@cisco.com] =
> Sent: Wednesday, July 03, 2002 5:48 PM
> To: IPS
> Subject: iSCSI: = Last call=20 comments
>
> =
>
> The = iSCSI draft is=20 looking pretty good.  I only have one last-call
> comment left:
> =
> There are a few sections in iSCSI (and ips-security) = that=20 discuss
> IPsec requirements for=20 "compliant/conformant implementations".  I
>=20 recall that this meant a target implementation could either be = a=20
> single device with both iSCSI and IPsec, or a=20 combination of two
> devices, one that = handles=20 iSCSI; the other handling IPsec.  However,
> I=20 couldn't find anywhere in the spec that spells this out either=20
> way, other than a hint at it in item [3] on = page 31 of=20
> ips-security-13:
>=20
> > [3]  IPsec is provided by a = device=20 external to the actual
> iSCSI = device.=20
> >      Here the = iSCSI header=20 and data CRCs can be kept across
> the = part=20 of
> >      = the=20 connection that is not protected by IPsec. For
>=20 instance, the
> = >     =20 iSCSI connection could traverse an extra bus, interface card, =
> >      network, interface = card, and=20 bus between the iSCSI
> device and = the=20
> >      device = providing=20 IPsec. In this case, the iSCSI CRC is
>=20 desirable,
> = >      and=20 the iSCSI implementation behind the IPsec device
>=20 may request
> = >     =20 it.
>
> As = there are=20 many cases where it makes a lot of sense to provide
> the solution in two pieces (iSCSI in one or more = devices, with one=20 or
> more IPsec front-end devices, I'd = like to=20 clarify this.
>
> How=20 about (somewhere in section 7) adding something like:
>
>    An = iSCSI compliant=20 initiator or target may provide the required
>    IPsec support either by itself, or in=20 conjunction with an IPsec
>   =20 front-end device.
>
>=20 Any thoughts?
>
>=20 --
> Mark
>=20
>
> For = reference, here=20 are a few of the statements that would be
> helped=20 out by the above.
>
>=20 iscsi-14 Section 7.3.1:
> =
>    An iSCSI compliant initiator or target = MUST=20 provide data integrity
>    and=20 authentication by implementing IPsec [RFC2401] with
> ESP [RFC2406]
>    in=20 tunnel mode and MAY provide data integrity and
>=20 authentication by
>    = implementing=20 IPsec with ESP in transport mode. The IPsec
>=20 implementa-
>    tion MUST = fulfill=20 the following iSCSI specific requirements:
>=20
> iscsi-14 Section 7.3.2: =
>
>    An = iSCSI compliant=20 initiator or target MUST provide
> = confidentiality=20
>    by implementing IPsec = [RFC2401]=20 with ESP [RFC2406] in
> tunnel mode and=20
>    MAY provide = confidentiality by=20 implementing IPsec with ESP
> in = trans-=20
>    port mode. with the = following iSCSI=20 specific requirements:
>
> iscsi-14 Section 7.3.3:
>=20
>      - = Conformant iSCSI=20 implementations MUST support IKE Main Mode
>          =  =20 and SHOULD support Aggressive Mode.
>=20
> ---
> = ips-security-13=20 Section 2.3.1:
>
> All=20 IP block storage security compliant implementations MUST = support=20
> IPsec ESP [RFC2406] to provide security for = both control=20 packets and
> data packets, as well as = the replay=20 protection mechanisms of IPsec.
> When = ESP is=20 utilized, per-packet data origin authentication, integrity =
> and replay protection MUST be used.
>=20
>
> -- =
> Mark A. Bakke
> Cisco = Systems=20
> mbakke@cisco.com
>=20 763.398.1054
> =

------=_NextPart_000_0106_01C2241A.F37584B0-- From owner-ips@ece.cmu.edu Fri Jul 5 10:30:07 2002 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA26912 for ; Fri, 5 Jul 2002 10:30:06 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id g65EGTu06019 for ips-outgoing; Fri, 5 Jul 2002 10:16:29 -0400 (EDT) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from magic.adaptec.com (magic.adaptec.com [208.236.45.80]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id g653v1X09429 for ; Thu, 4 Jul 2002 23:57:01 -0400 (EDT) Received: from redfish.adaptec.com (redfish.adaptec.com [162.62.50.11]) by magic.adaptec.com (8.10.2+Sun/8.10.2) with ESMTP id g653utr22561 for ; Thu, 4 Jul 2002 20:56:55 -0700 (PDT) Received: from btc.btc.adaptec.com (btc.btc.adaptec.com [10.100.0.52]) by redfish.adaptec.com (8.8.8+Sun/8.8.8) with ESMTP id UAA06605 for ; Thu, 4 Jul 2002 20:56:55 -0700 (PDT) Received: from btcexc01.btc.adaptec.com (btcexc01 [10.100.0.23]) by btc.btc.adaptec.com (8.8.8+Sun/8.8.8) with ESMTP id VAA26380; Thu, 4 Jul 2002 21:56:52 -0600 (MDT) Received: by btcexc01.btc.adaptec.com with Internet Mail Service (5.5.2653.19) id ; Thu, 4 Jul 2002 21:56:52 -0600 Message-ID: <2C7CBDC6EA58D6119E4A00065B3A24CB21A034@btcexc01.btc.adaptec.com> From: ANTIGEN_BTCEXC01 To: "'ips@ece.cmu.edu'" , "'ips@ece.cmu.edu'" Subject: Antigen found =*.eml file Date: Thu, 4 Jul 2002 21:56:50 -0600 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain Sender: owner-ips@ece.cmu.edu Precedence: bulk Antigen for Exchange found RE_ iSCSI_ leading zeros and decimal-encoded binary strings.eml matching =*.eml file filter. The file is currently Removed. The message, "iSCSI: leading zeros and decimal-encoded binary strings", was sent from Julian Satran \(Actcom\) and was discovered in IMC Queues\Inbound located at Adaptec/btc/BTCEXC01. From owner-ips@ece.cmu.edu Fri Jul 5 10:30:10 2002 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA26930 for ; Fri, 5 Jul 2002 10:30:09 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id g65E2Vm05592 for ips-outgoing; Fri, 5 Jul 2002 10:02:31 -0400 (EDT) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from web13701.mail.yahoo.com (web13701.mail.yahoo.com [216.136.175.134]) by ece.cmu.edu (8.11.0/8.10.2) with SMTP id g65E2OX05583 for ; Fri, 5 Jul 2002 10:02:24 -0400 (EDT) Message-ID: <20020705140222.20617.qmail@web13701.mail.yahoo.com> Received: from [24.147.155.153] by web13701.mail.yahoo.com via HTTP; Fri, 05 Jul 2002 07:02:22 PDT Date: Fri, 5 Jul 2002 07:02:22 -0700 (PDT) From: Martins Krikis Subject: Re: To: "Julian Satran \(Actcom\)" , ips In-Reply-To: <008701c223d7$a506eaf0$0100000a@JA31> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: owner-ips@ece.cmu.edu Precedence: bulk --- "Julian Satran (Actcom)" wrote: > Leading 0 where forbidden after a brief discussion. > As for unlikely to be used - I could argue for the > contrary - as in the examples I gave in a previous > notes. > Many string copied from humanly readable documents > tend to be decimal-encoded. Julian, You are right about the leading 0, thus Bill's example was a bad one. He is right however about the inability to express the leading nul-bytes of a binary string when it is encoded in decimal. The examples you gave previously (unless some have escaped me) were really bad. I have yet to see a true "binary string" (and not a number) encoded in decimal. Martins Krikis, Intel Corp. Disclaimer: these opinions are mine and may not be those of my employer. __________________________________________________ Do You Yahoo!? Sign up for SBC Yahoo! Dial - First Month Free http://sbc.yahoo.com From owner-ips@ece.cmu.edu Fri Jul 5 10:30:20 2002 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA26955 for ; Fri, 5 Jul 2002 10:30:19 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id g65EHM606071 for ips-outgoing; Fri, 5 Jul 2002 10:17:22 -0400 (EDT) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from ietf.org (odin.ietf.org [132.151.1.176]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id g65AYNX00199 for ; Fri, 5 Jul 2002 06:34:24 -0400 (EDT) Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA16973; Fri, 5 Jul 2002 06:33:33 -0400 (EDT) Message-Id: <200207051033.GAA16973@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; Cc: ips@ece.cmu.edu From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-ietf-ips-iscsi-14.txt,.pdf Date: Fri, 05 Jul 2002 06:33:33 -0400 Sender: owner-ips@ece.cmu.edu Precedence: bulk --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the IP Storage Working Group of the IETF. Title : iSCSI Author(s) : J. Satran et al. Filename : draft-ietf-ips-iscsi-14.txt,.pdf Pages : 276 Date : 03-Jul-02 The Small Computer Systems Interface (SCSI) is a popular family of protocols for communicating with I/O devices, especially storage devices. This document describes a transport protocol for SCSI that works on top of TCP. The iSCSI protocol aims to be fully compliant with the rules laid out in the SCSI Architecture Model - 2 [SAM2] document. This current version of iSCSI is 0. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-ips-iscsi-14.txt To remove yourself from the IETF Announcement list, send a message to ietf-announce-request with the word unsubscribe in the body of the message. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-ips-iscsi-14.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-ips-iscsi-14.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <20020703131739.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-ips-iscsi-14.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-ips-iscsi-14.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <20020703131739.I-D@ietf.org> --OtherAccess-- --NextPart-- From owner-ips@ece.cmu.edu Fri Jul 5 10:31:57 2002 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA27008 for ; Fri, 5 Jul 2002 10:31:52 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id g65EHQr06083 for ips-outgoing; Fri, 5 Jul 2002 10:17:27 -0400 (EDT) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from ietf.org (odin.ietf.org [132.151.1.176]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id g65AYXX00212 for ; Fri, 5 Jul 2002 06:34:33 -0400 (EDT) Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA16960; Fri, 5 Jul 2002 06:33:28 -0400 (EDT) Message-Id: <200207051033.GAA16960@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; Cc: ips@ece.cmu.edu From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-ietf-ips-scsi-mib-03.txt Date: Fri, 05 Jul 2002 06:33:27 -0400 Sender: owner-ips@ece.cmu.edu Precedence: bulk --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the IP Storage Working Group of the IETF. Title : Definition of Managed Objects for SCSI Entities Author(s) : M. Bakke et al. Filename : draft-ietf-ips-scsi-mib-03.txt Pages : 71 Date : 03-Jul-02 This memo defines a Management Information Base (MIB) for Small Computer System Interface (SCSI) entities, independently of the interconnect subsystem layer. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-ips-scsi-mib-03.txt To remove yourself from the IETF Announcement list, send a message to ietf-announce-request with the word unsubscribe in the body of the message. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-ips-scsi-mib-03.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-ips-scsi-mib-03.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <20020703131726.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-ips-scsi-mib-03.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-ips-scsi-mib-03.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <20020703131726.I-D@ietf.org> --OtherAccess-- --NextPart-- From owner-ips@ece.cmu.edu Fri Jul 5 10:32:19 2002 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA27032 for ; Fri, 5 Jul 2002 10:32:19 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id g65DstS05330 for ips-outgoing; Fri, 5 Jul 2002 09:54:55 -0400 (EDT) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from web13707.mail.yahoo.com (web13707.mail.yahoo.com [216.136.175.140]) by ece.cmu.edu (8.11.0/8.10.2) with SMTP id g65DsrX05326 for ; Fri, 5 Jul 2002 09:54:53 -0400 (EDT) Message-ID: <20020705135452.15406.qmail@web13707.mail.yahoo.com> Received: from [24.147.155.153] by web13707.mail.yahoo.com via HTTP; Fri, 05 Jul 2002 06:54:52 PDT Date: Fri, 5 Jul 2002 06:54:52 -0700 (PDT) From: Martins Krikis Subject: Re: iSCSI: Decimal encoding - why 64 bits ? To: "Julian Satran \(Actcom\)" , Bill Studenmund Cc: ips@ece.cmu.edu In-Reply-To: <005701c223d6$6a16ae40$0100000a@JA31> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: owner-ips@ece.cmu.edu Precedence: bulk --- "Julian Satran (Actcom)" wrote: > If you fear about extended precision arithmetic you > should carefully look at > what key=values are. > Precluding the use of large numerical values by > forbidding their encoding is > not a good way of considering this - we have also > base64 for large numbers > (and hex) and if you have to have a use for larger > numbers you have to have > the arithmetic to handle it. Julian, If this hadn't come up so late, I would even challenge you to find anybody besides yourself who is "for large-numerical-values"---my feeling from reading this list is that people preferred to just have "binary values" (of arbitrary length) instead. > As for the second subject - forbidding the use > decimals for binary strings - > we never discussed it or agreed on this. Many people mentioned it and are still doing it. The rest ignored the issue and keep doing it. > I wonder how natural it will feel for somebody to > have and IP address > encoded exclusively in hex, or a TargetPortalGroup > appearing as decimal in a > directory and having to be transliterated. These are very bad examples. TargetPortalGroupTag is defined as a numerical-value, so decimal is perfectly fine for it, it is given in decimal in all examples in the draft and I certainly would expect to find it in decimal. As for the IP addresses, I'm not an IPv6 expert, but I expect it to be given as an ASCII string (and not a binary value/item in some encoding), just like an IPv4 address. Speaking about the latter, we are used to seeing the octets of this address in decimal, not the address itself. If you insist on encoding the address as a whole (i.e., the 32-bit binary value that it is), well, please tell me, which is more natural (although, I agree that both are awkward): 3228845671 or 0xc0744667? You may want to feed them to a "host" command, and you should recognize these addresses. Both get resolved on my home box. Such tricks used to even work in some browsers. Martins Krikis, Intel Corp. Disclaimer: these opinions are mine and may not be those of my employer. __________________________________________________ Do You Yahoo!? Sign up for SBC Yahoo! Dial - First Month Free http://sbc.yahoo.com From owner-ips@ece.cmu.edu Fri Jul 5 11:11:37 2002 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA28836 for ; Fri, 5 Jul 2002 11:11:36 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id g65EbmK06919 for ips-outgoing; Fri, 5 Jul 2002 10:37:48 -0400 (EDT) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from cygnus.equallogic.com (cygnus.equallogic.com [65.170.102.10]) by ece.cmu.edu (8.11.0/8.10.2) with SMTP id g65EbkX06915 for ; Fri, 5 Jul 2002 10:37:46 -0400 (EDT) Received: from cygnus.equallogic.com (localhost.localdomain [127.0.0.1]) by cygnus.equallogic.com (8.11.6/8.11.6) with ESMTP id g65EbeC02431 for ; Fri, 5 Jul 2002 10:37:40 -0400 Received: from deneb.dev.equallogic.com (deneb.dev.equallogic.com [172.16.1.99]) by cygnus.equallogic.com (8.11.6/8.11.6) with ESMTP id g65EbeQ02419; Fri, 5 Jul 2002 10:37:40 -0400 Received: from PKONING.equallogic.com (localhost.localdomain [127.0.0.1]) by deneb.dev.equallogic.com (8.11.6/8.11.6) with ESMTP id g65EbdH15364; Fri, 5 Jul 2002 10:37:39 -0400 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <15653.44852.253000.450690@gargle.gargle.HOWL> Date: Fri, 5 Jul 2002 10:37:40 -0400 From: Paul Koning To: Julian_Satran@actcom.net.il Cc: wrstuden@wasabisystems.com, ips@ece.cmu.edu Subject: Re: iSCSI: Decimal encoding - why 64 bits ? References: <005701c223d6$6a16ae40$0100000a@JA31> X-Mailer: VM 6.95 under 21.4 (patch 3) "Academic Rigor" XEmacs Lucid Sender: owner-ips@ece.cmu.edu Precedence: bulk Content-Transfer-Encoding: 7bit Excerpt of message (sent 5 July 2002) by Julian Satran \(Actcom\): > If you fear about extended precision arithmetic you should carefully look at > what key=values are. > Precluding the use of large numerical values by forbidding their encoding is > not a good way of considering this - we have also base64 for large numbers > (and hex) and if you have to have a use for larger numbers you have to have > the arithmetic to handle it. There are no numbers in the draft that come even close to 32 bits (the biggest is about 24 bits) so any possible future use of 64 bit integers is entirely speculative. > As for the second subject - forbidding the use decimals for binary strings - > we never discussed it or agreed on this. I thought we had, but it doesn't really matter if we discussed it in the past; we're discussing it now. > I wonder how natural it will feel for somebody to have and IP address > encoded exclusively in hex, or a TargetPortalGroup appearing as decimal in a > directory and having to be transliterated. What does this have to do with the subject that we're discussing? Those aren't integers bigger than 32 bits. The two areas that are being argued about are: 1. Integer-type attributes that require 64 bits rather than 32 bits. Such attributes do not currently exist. We could let the rules say that such attributes, if/when they appear in the future, can be encoded in decimal. That doesn't affect any current implementations because there are no such attributes at present. 2. Bitstring attributes, as found in crypto variables. Those are either always, or almost always, much larger than 2^64. The request from a significant number of people is to disallow decimal encoding for those attributes even in the very rare case that the value encoded is < 2^64. I support that change because allowing the decimal encoding there adds no value at all and only complicates code to no purpose. paul From owner-ips@ece.cmu.edu Fri Jul 5 11:14:28 2002 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA28959 for ; Fri, 5 Jul 2002 11:14:28 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id g65EgHT07120 for ips-outgoing; Fri, 5 Jul 2002 10:42:17 -0400 (EDT) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from web13708.mail.yahoo.com (web13708.mail.yahoo.com [216.136.175.141]) by ece.cmu.edu (8.11.0/8.10.2) with SMTP id g65EgFX07116 for ; Fri, 5 Jul 2002 10:42:15 -0400 (EDT) Message-ID: <20020705144214.28588.qmail@web13708.mail.yahoo.com> Received: from [24.147.155.153] by web13708.mail.yahoo.com via HTTP; Fri, 05 Jul 2002 07:42:14 PDT Date: Fri, 5 Jul 2002 07:42:14 -0700 (PDT) From: Martins Krikis Subject: Re: iSCSI: Decimal encoding - why 64 bits ? To: "Julian Satran \(Actcom\)" , Black_David@emc.com Cc: ips@ece.cmu.edu In-Reply-To: <00ca01c223da$3cf6dfd0$0100000a@JA31> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: owner-ips@ece.cmu.edu Precedence: bulk --- "Julian Satran (Actcom)" wrote: > Martins - you have a very good point - and we > considered briefly to forbid > decimal from the outset but many of the team felt > that this would be a bad > idea as values get copied from a context to another. > And the we looked at > coding for other RFCs and we found decimal > everywhere - addresses, > identifiers, ports etc., and thought it would be a > bad idea to forbid them > in iSCSI Julian, I cannot find a single post on this mailing list saying that forbidding decimal encoding for binary items would be a bad idea. I did find several (and quoted 4) that actually recommended dropping decimal encoding for binary items. Lately there have been many more such posts. All those other RFCs, I suspect, are actually dealing with numbers. I have no objections to using decimal encoding for numbers (that is things, that normally fit in your machine's registers and are treated as numerical, not as bit-strings). You have yet to provide an example of something that is clearly a binary string (and not used as a number) and is being commonly encoded in decimal. If you find such a thing, can you tell us what's the scheme for telling how many null-bytes this binary string starts with? Martins Krikis, Intel Corp. Disclaimer: these opinions are mine and may not be those of my employer. __________________________________________________ Do You Yahoo!? Sign up for SBC Yahoo! Dial - First Month Free http://sbc.yahoo.com From owner-ips@ece.cmu.edu Fri Jul 5 11:14:51 2002 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA28998 for ; Fri, 5 Jul 2002 11:14:50 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id g65EqV007494 for ips-outgoing; Fri, 5 Jul 2002 10:52:31 -0400 (EDT) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from web13706.mail.yahoo.com (web13706.mail.yahoo.com [216.136.175.139]) by ece.cmu.edu (8.11.0/8.10.2) with SMTP id g65EqTX07489 for ; Fri, 5 Jul 2002 10:52:29 -0400 (EDT) Message-ID: <20020705145228.3354.qmail@web13706.mail.yahoo.com> Received: from [24.147.155.153] by web13706.mail.yahoo.com via HTTP; Fri, 05 Jul 2002 07:52:28 PDT Date: Fri, 5 Jul 2002 07:52:28 -0700 (PDT) From: Martins Krikis Subject: iSCSI: editorial change for first Login Response To: Julian_Satran@il.ibm.com Cc: ips@ece.cmu.edu MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: owner-ips@ece.cmu.edu Precedence: bulk I mailed this once already, but it got lost. (The subject line for another one of my emails got lost too---I can't explain it.) Anyway, I don't have draft14 in front of me, so am writing off of 13, but I'm rather sure they are equivalent in this respect. The last paragraph of 4.3.1 claims the first Login Response SHOULD/MUST (depending on ...) return the TargetPortalGroupTag. 11.9 however claims that it is the Login Response to the first Login Request that has C bit set to 0 which should do so. I believe 11.9 is right, and thus, 4.3.1 needs a small editorial change in its very last paragraph. Thank you, Martins Krikis, Intel Corp. Disclaimer: these opinions are mine and may not be those of my employer. __________________________________________________ Do You Yahoo!? Sign up for SBC Yahoo! Dial - First Month Free http://sbc.yahoo.com From owner-ips@ece.cmu.edu Fri Jul 5 12:16:24 2002 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA02237 for ; Fri, 5 Jul 2002 12:16:24 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id g65Fc2k09438 for ips-outgoing; Fri, 5 Jul 2002 11:38:03 -0400 (EDT) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from lmail.actcom.co.il (mail.actcom.co.il [192.114.47.13]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id g65FbxX09432 for ; Fri, 5 Jul 2002 11:37:59 -0400 (EDT) Received: from JA31 ([192.115.26.20]) by lmail.actcom.co.il (8.11.6/8.11.6) with ESMTP id g65Fbrg03724; Fri, 5 Jul 2002 18:37:53 +0300 Message-ID: <018801c22439$ec3160b0$0100000a@JA31> From: "Julian Satran \(Actcom\)" To: "Martins Krikis" , "ips" References: <20020705140222.20617.qmail@web13701.mail.yahoo.com> Subject: Re: Date: Fri, 5 Jul 2002 18:37:51 +0300 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2600.0000 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 Sender: owner-ips@ece.cmu.edu Precedence: bulk Content-Transfer-Encoding: 7bit Martins, In fact reading your note I went back and found an error we may want to correct: TargetPortalGroupTag is a 16 bit binary string and not an number (there is no TPGT that is lower or higher than another TPGT). As for IP addresses they are just for illustration - each of the address item is a an 8 bit binary string of fixed length usually encoded decimal. There are no good examples that need decimals other than TPGT but I see no point in disallowing them for vendor keys and future extensions. Any implementation will have the conversion routines. Restricting the use of decimals beyond what we did does not strike me as useful. Julo ----- Original Message ----- From: "Martins Krikis" To: "Julian Satran (Actcom)" ; "ips" Sent: Friday, July 05, 2002 5:02 PM Subject: Re: > > --- "Julian Satran (Actcom)" > wrote: > > Leading 0 where forbidden after a brief discussion. > > As for unlikely to be used - I could argue for the > > contrary - as in the examples I gave in a previous > > notes. > > Many string copied from humanly readable documents > > tend to be decimal-encoded. > > Julian, > > You are right about the leading 0, thus Bill's > example was a bad one. He is right however about > the inability to express the leading nul-bytes of > a binary string when it is encoded in decimal. > > The examples you gave previously (unless some > have escaped me) were really bad. I have yet to > see a true "binary string" (and not a number) > encoded in decimal. > > Martins Krikis, Intel Corp. > > Disclaimer: these opinions are mine and may not > be those of my employer. > > > __________________________________________________ > Do You Yahoo!? > Sign up for SBC Yahoo! Dial - First Month Free > http://sbc.yahoo.com From owner-ips@ece.cmu.edu Fri Jul 5 12:59:18 2002 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA04169 for ; Fri, 5 Jul 2002 12:59:18 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id g65GPFU11388 for ips-outgoing; Fri, 5 Jul 2002 12:25:15 -0400 (EDT) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from web13703.mail.yahoo.com (web13703.mail.yahoo.com [216.136.175.136]) by ece.cmu.edu (8.11.0/8.10.2) with SMTP id g65GPDX11381 for ; Fri, 5 Jul 2002 12:25:13 -0400 (EDT) Message-ID: <20020705162512.54373.qmail@web13703.mail.yahoo.com> Received: from [24.147.155.153] by web13703.mail.yahoo.com via HTTP; Fri, 05 Jul 2002 09:25:12 PDT Date: Fri, 5 Jul 2002 09:25:12 -0700 (PDT) From: Martins Krikis Subject: Re: iSCSI: Decimal encoding - why 64 bits ? To: "Julian Satran \(Actcom\)" , ips In-Reply-To: <018801c22439$ec3160b0$0100000a@JA31> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: owner-ips@ece.cmu.edu Precedence: bulk --- "Julian Satran (Actcom)" wrote: > Martins, > > In fact reading your note I went back and found an > error we may want to > correct: > > TargetPortalGroupTag is a 16 bit binary string and > not an number (there is > no TPGT that is lower or higher than another TPGT). Again, I don't have draft 14 in front of me but 13 says that TPGT is "a simple unsigned-integer between 1 and 65535" (2.4.1 (e)) and a "numerical- value-from-1-to-65535" (11.9). I would prefer it if you did not change this to a "binary string" just to prove a point that there are binary strings for which decimal encoding is natural. That, IMO, would be a very profound change at an extremely late stage. (If you do, I'll make sure all my TPGTs start with 0x00 and deny all attemts to encode them in decimal :-)). > There are no good examples that need decimals other > than TPGT but I see no Even TPGT is not a good example, as it is defined to be a number, for now at least. > point in disallowing them for vendor keys and future > extensions. Any > implementation will have the conversion routines. > Restricting the use of > decimals beyond what we did does not strike me as > useful. Others (and there are many) here seem to be disagreeing with you. The conversion, while possible, will likely first use some common library routine, then byteswap (if running on little-endian), then do a pass to eliminate leading 0-bytes, which are not representable in decimal. OK, my final argument. Here are two binary strings, encoded in hex: 0x01 and 0x0001. Can you give us an example of encoding both of them in decimal in such a way that they can be distinguished? Martins Krikis, Intel Corp. Disclaimer: these opinions are my own and may not be those of my employer. __________________________________________________ Do You Yahoo!? Sign up for SBC Yahoo! Dial - First Month Free http://sbc.yahoo.com From owner-ips@ece.cmu.edu Fri Jul 5 14:47:10 2002 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA10162 for ; Fri, 5 Jul 2002 14:47:10 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id g65IEbi16080 for ips-outgoing; Fri, 5 Jul 2002 14:14:37 -0400 (EDT) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from lmail.actcom.co.il (mail.actcom.co.il [192.114.47.13]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id g65IEYX16075 for ; Fri, 5 Jul 2002 14:14:34 -0400 (EDT) Received: from JA31 ([192.115.26.20]) by lmail.actcom.co.il (8.11.6/8.11.6) with ESMTP id g65IEXg05668; Fri, 5 Jul 2002 21:14:33 +0300 Message-ID: <000a01c2244f$cea2fe80$0100000a@JA31> From: "Julian Satran \(Actcom\)" To: "Martins Krikis" Cc: References: <20020705145228.3354.qmail@web13706.mail.yahoo.com> Subject: Re: iSCSI: editorial change for first Login Response Date: Fri, 5 Jul 2002 21:14:30 +0300 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2600.0000 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 Sender: owner-ips@ece.cmu.edu Precedence: bulk Content-Transfer-Encoding: 7bit will do - thanks, julo ----- Original Message ----- From: "Martins Krikis" To: Cc: Sent: Friday, July 05, 2002 5:52 PM Subject: iSCSI: editorial change for first Login Response > I mailed this once already, but it got lost. > (The subject line for another one of my emails > got lost too---I can't explain it.) > > Anyway, I don't have draft14 in front of me, so > am writing off of 13, but I'm rather sure they are > equivalent in this respect. > > The last paragraph of 4.3.1 claims the first Login > Response SHOULD/MUST (depending on ...) return > the TargetPortalGroupTag. 11.9 however claims that > it is the Login Response to the first Login Request > that has C bit set to 0 which should do so. I believe > 11.9 is right, and thus, 4.3.1 needs a small editorial > change in its very last paragraph. > > Thank you, > > Martins Krikis, Intel Corp. > > Disclaimer: these opinions are mine and may not be > those of my employer. > > > __________________________________________________ > Do You Yahoo!? > Sign up for SBC Yahoo! Dial - First Month Free > http://sbc.yahoo.com From owner-ips@ece.cmu.edu Fri Jul 5 14:47:23 2002 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA10237 for ; Fri, 5 Jul 2002 14:47:23 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id g65IPMX16506 for ips-outgoing; Fri, 5 Jul 2002 14:25:22 -0400 (EDT) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from lmail.actcom.co.il (mail.actcom.co.il [192.114.47.13]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id g65IPKX16502 for ; Fri, 5 Jul 2002 14:25:20 -0400 (EDT) Received: from JA31 ([192.115.26.20]) by lmail.actcom.co.il (8.11.6/8.11.6) with ESMTP id g65IPFg07724; Fri, 5 Jul 2002 21:25:15 +0300 Message-ID: <001901c22451$4d5da990$0100000a@JA31> From: "Julian Satran \(Actcom\)" To: "Martins Krikis" , "ips" References: <20020705162512.54373.qmail@web13703.mail.yahoo.com> Subject: Re: iSCSI: Decimal encoding - why 64 bits ? Date: Fri, 5 Jul 2002 21:25:12 +0300 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2600.0000 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 Sender: owner-ips@ece.cmu.edu Precedence: bulk Content-Transfer-Encoding: 7bit The trouble with the current definition is that TPGT has no number characteristics at all (there is no ordering defined). For implementations the changes is irrelevant. And you may continue to use whatever you want. I do not see how 0 will prevent somebody encode it in decimal (as most do). And believe me I do not change things to prove a point - I am too old for that. As for you conversion rules - some of the steps are there regardless of where you com from - hex to string may be subject to byteswap too! (specially if you define it as a number!). My point was that once you have decimal in the is no point is forbidding it in some instances. Julo ----- Original Message ----- From: "Martins Krikis" To: "Julian Satran (Actcom)" ; "ips" Sent: Friday, July 05, 2002 7:25 PM Subject: Re: iSCSI: Decimal encoding - why 64 bits ? > > --- "Julian Satran (Actcom)" > wrote: > > Martins, > > > > In fact reading your note I went back and found an > > error we may want to > > correct: > > > > TargetPortalGroupTag is a 16 bit binary string and > > not an number (there is > > no TPGT that is lower or higher than another TPGT). > > Again, I don't have draft 14 in front of me but > 13 says that TPGT is "a simple unsigned-integer > between 1 and 65535" (2.4.1 (e)) and a "numerical- > value-from-1-to-65535" (11.9). I would prefer it if > you did not change this to a "binary string" just > to prove a point that there are binary strings > for which decimal encoding is natural. That, IMO, > would be a very profound change at an extremely > late stage. (If you do, I'll make sure all my > TPGTs start with 0x00 and deny all attemts to > encode them in decimal :-)). > > > There are no good examples that need decimals other > > than TPGT but I see no > > Even TPGT is not a good example, as it is defined > to be a number, for now at least. > > > point in disallowing them for vendor keys and future > > extensions. Any > > implementation will have the conversion routines. > > Restricting the use of > > decimals beyond what we did does not strike me as > > useful. > > Others (and there are many) here seem to be > disagreeing with you. > > The conversion, while possible, will likely > first use some common library routine, then > byteswap (if running on little-endian), then > do a pass to eliminate leading 0-bytes, which > are not representable in decimal. > > OK, my final argument. Here are two binary > strings, encoded in hex: 0x01 and 0x0001. > Can you give us an example of encoding both > of them in decimal in such a way that they > can be distinguished? > > Martins Krikis, Intel Corp. > > Disclaimer: these opinions are my own and may > not be those of my employer. > > > __________________________________________________ > Do You Yahoo!? > Sign up for SBC Yahoo! Dial - First Month Free > http://sbc.yahoo.com From owner-ips@ece.cmu.edu Fri Jul 5 14:49:28 2002 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA10352 for ; Fri, 5 Jul 2002 14:49:23 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id g65IPde16534 for ips-outgoing; Fri, 5 Jul 2002 14:25:39 -0400 (EDT) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from d12lmsgate.de.ibm.com (d12lmsgate.de.ibm.com [195.212.91.199]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id g65IPbX16529 for ; Fri, 5 Jul 2002 14:25:37 -0400 (EDT) Received: from d12relay02.de.ibm.com (d12relay02.de.ibm.com [9.165.215.23]) by d12lmsgate.de.ibm.com (8.12.3/8.12.3) with ESMTP id g65IPSIB034718; Fri, 5 Jul 2002 20:25:28 +0200 Received: from d10hubm1.telaviv.ibm.com (d10ml001.telaviv.ibm.com [9.148.216.55]) by d12relay02.de.ibm.com (8.11.1m3/NCO/VER6.1) with ESMTP id g65IPRL88688; Fri, 5 Jul 2002 20:25:28 +0200 To: pat_thaler@agilent.com Cc: ips@ece.cmu.edu, pat_thaler@agilent.com MIME-Version: 1.0 Subject: RE: iSCSI: Login negotiation space X-Mailer: Lotus Notes Release 5.0.9 November 16, 2001 From: "Julian Satran" Message-ID: Date: Fri, 5 Jul 2002 21:25:25 +0300 X-MIMETrack: Serialize by Router on D10ML001/10/M/IBM(Release 5.0.9a |January 7, 2002) at 05/07/2002 21:25:27, Serialize complete at 05/07/2002 21:25:27 Content-Type: multipart/alternative; boundary="=_alternative 0063C2CCC2256BED_=" Sender: owner-ips@ece.cmu.edu Precedence: bulk This is a multipart message in MIME format. --=_alternative 0063C2CCC2256BED_= Content-Type: text/plain; charset="us-ascii" Pat, I had trouble understanding the "basics" underneath your claim that 16k is excessive. If you are concerned about many sessions having to provide this space - the targets supporting many sessions must anyhow have many resources to do so (i.e., they are high end devices) . The vast majority of those will go for the TCP window. the little that has to go for session management will either be in some host space or will be shared with other buffers for the session. As for throttling - if you have the 16k from the outset of a ngegtotiation I do not see how your real dealock can occur. I am not sure that this thread is expresses a decent level of maturity but if 16k is really of concern I suggest we get it down to one PDU i.e., 8k and conclude the thread before time runs out. And only to add a grain of salt to all this the 16 was not arbitrarily chosen. It is based on a very simple traffic model and on the assumption that a socket consumes around 6k in idle state. Julo pat_thaler@agilent.com 07/03/2002 09:09 PM Please respond to pat_thaler To: Julian Satran/Haifa/IBM@IBMIL, pat_thaler@agilent.com cc: ips@ece.cmu.edu Subject: RE: iSCSI: Login negotiation space Julian, I wouldn't object to the default PDU size being lowered, but that is not what I am suggesting. There is no conflict between having a default PDU size of 8k during login and having a requirement to support at least 4096 bytes of key=value data in a negotiation sequence. PDUs don't have to be full. The situation is no worse than having a MaxRecvDataSegmentLength of 8k when MaxBurstLength is 4k or having a 4 kbyte write with an 8kb byte MaxRecvDataSegmentLength. The default MaxRecvDataSegmentLength at 8k would still be useful when implementations were supporting very long authentication items. Also, a vendor might suport a larger negotiaton space for vendor specific keys. Such an implmentation could send a key like X-com.acme.HugeKeySet=yes. If the partner responds X-com.acme.HugeKeySet=yes, then it can proceed to send the hugh key set knowing that its partner supports it and therefore has allocated space for it. If it gets a no or NotUnderstood response, it doesn't send the extra keys. I disagree with your statement about deadlock. It is a real issue when throttling is engaged. Regards, Pat -----Original Message----- From: Julian Satran [mailto:Julian_Satran@il.ibm.com] Sent: Wednesday, July 03, 2002 8:34 AM To: pat_thaler@agilent.com Cc: ips@ece.cmu.edu Subject: RE: iSCSI: Login negotiation space Pat, 4k does not make too much sense either with default PDU size of 8k. Are you suggesting we limit this too to a lower value? Your deadlock example while academically correct is not very interesting as I assume that throttling can be done at the first buffer level. Julo --=_alternative 0063C2CCC2256BED_= Content-Type: text/html; charset="us-ascii"
Pat,

I had trouble understanding the "basics" underneath your claim that 16k is excessive.
If you are concerned about many sessions having to provide this space - the targets supporting many sessions
 must anyhow have many resources to do so (i.e., they are high end devices) .

The vast majority of those will go for the TCP window. the little that has to go for session management will either be in some host space or will be shared with other buffers for the session.

As for throttling - if you have the 16k from the outset of a ngegtotiation I do not see how your real dealock can occur.

I am not sure that this thread is expresses a decent level of maturity but if 16k is really of concern I suggest we get it down to one PDU i.e., 8k and conclude the thread before time runs out.

And only to add a grain of salt to all this the 16 was not arbitrarily chosen. It is based on a very simple traffic model and on the assumption that a socket consumes around 6k in idle state.

Julo


pat_thaler@agilent.com

07/03/2002 09:09 PM
Please respond to pat_thaler

       
        To:        Julian Satran/Haifa/IBM@IBMIL, pat_thaler@agilent.com
        cc:        ips@ece.cmu.edu
        Subject:        RE: iSCSI: Login negotiation space

       


Julian,
 
I wouldn't object to the default PDU size being lowered, but that is not what I am suggesting.
 
There is no conflict between having a default PDU size of 8k during login and having a requirement to support at least 4096 bytes of key=value data in a negotiation sequence. PDUs don't have to be full. The situation is no worse than having a MaxRecvDataSegmentLength of 8k when MaxBurstLength is 4k or having a 4 kbyte write with an 8kb byte MaxRecvDataSegmentLength.
 
The default MaxRecvDataSegmentLength at 8k would still be useful when implementations were supporting very long authentication items. Also, a vendor might suport a larger negotiaton space for vendor specific keys. Such an implmentation could send a key like X-com.acme.HugeKeySet=yes. If the partner responds X-com.acme.HugeKeySet=yes, then it can proceed to send the hugh key set knowing that its partner supports it and therefore has allocated space for it. If it gets a no or NotUnderstood response, it doesn't send the extra keys.
 
I disagree with your statement about deadlock. It is a real issue when throttling is engaged.
 
Regards,
Pat
 
-----Original Message-----
From: Julian Satran [mailto:Julian_Satran@il.ibm.com]
Sent: Wednesday, July 03, 2002 8:34 AM
To: pat_thaler@agilent.com
Cc: ips@ece.cmu.edu
Subject: RE: iSCSI: Login negotiation space

Pat,

4k does not make too much sense either with default PDU size of 8k.
Are you suggesting we limit this too to a lower value?
Your deadlock example while academically correct is not very interesting as I assume that throttling can be done at the first buffer level.

Julo

 

--=_alternative 0063C2CCC2256BED_=-- From owner-ips@ece.cmu.edu Fri Jul 5 14:49:33 2002 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA10366 for ; Fri, 5 Jul 2002 14:49:33 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id g65ID6916014 for ips-outgoing; Fri, 5 Jul 2002 14:13:06 -0400 (EDT) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from e2.ny.us.ibm.com (e2.ny.us.ibm.com [32.97.182.102]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id g65ID4X16009 for ; Fri, 5 Jul 2002 14:13:04 -0400 (EDT) Received: from northrelay01.pok.ibm.com (northrelay01.pok.ibm.com [9.56.224.149]) by e2.ny.us.ibm.com (8.12.2/8.12.2) with ESMTP id g65ICge8029822; Fri, 5 Jul 2002 14:12:46 -0400 Received: from d03nm014.boulder.ibm.com (avpilot.boulder.ibm.com [9.17.203.135]) by northrelay01.pok.ibm.com (8.11.1m3/NCO/VER6.1) with ESMTP id g65ICd719516; Fri, 5 Jul 2002 14:12:39 -0400 X-Priority: 1 (High) Importance: Normal Subject: Re: iSCSI: Last call comments To: "Julian Satran \(Actcom\)" Cc: "Michael Smith" , , X-Mailer: Lotus Notes Release 5.0.7 March 21, 2001 Message-ID: From: "John Hufferd" Date: Fri, 5 Jul 2002 11:10:12 -0700 X-MIMETrack: Serialize by Router on D03NM014/03/M/IBM(Release 5.0.10 |March 22, 2002) at 07/05/2002 12:12:41 PM MIME-Version: 1.0 Content-type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ece.cmu.edu id g65ID4X16010 Sender: owner-ips@ece.cmu.edu Precedence: bulk Content-Transfer-Encoding: 8bit Julian, As you know we talked about this a lot a long time ago. Many folks wanted to count the fact that a Firewall device within the installation could be used with their iSCSI Initiator or Target, and therefore their device should count as compliant with the specification. The understanding that was reached after much debate was that ... if you want to claim compliance for the interface that leaves an enclosure, IPsec is required .... I believe that if you include the words you are suggesting, that you should add that statement to the spec also. I suggest the following wordage: "An iSCSI initiator or target may provide the required IPsec support either fully integrated or in conjunction with an IPsec front-end device. In the later case, the compliance requirements apply to the "combined device". Claims of compliance for the interface that leaves an enclosure, is valid only if IPsec is supported on that interface from within the enclosure." The above would permit a Rack Enclosure, which had a Firewall included within that Rack Enclosure, to validly claim compliance for the interfaces that left the Rack. Likewise, for any other enclosure. If the HBA , blade or motherboard had a fronting IPsec chip, that would also permit compliance at the external interfaces of the HBA, blade or motherboard. . . . John L. Hufferd Senior Technical Staff Member (STSM) IBM/SSG San Jose Ca Main Office (408) 256-0403, Tie: 276-0403, eFax: (408) 904-4688 Home Office (408) 997-6136, Cell: (408) 499-9702 Internet address: hufferd@us.ibm.com "Julian Satran \(Actcom\)" @ece.cmu.edu on 07/05/2002 01:56:09 AM Sent by: owner-ips@ece.cmu.edu To: "Michael Smith" , , cc: "Michael Smith" Subject: Re: iSCSI: Last call comments I would suggest the following text for 7.3 An iSCSI initiator or target may provide the required IPsec support either fully integrated or in conjunction with an IPsec front-end device. In the later case the term iSCSI target reffers to the target and IPsec front-end and compliance requirements apply to the "combined device". Julo ----- Original Message ----- From: Michael Smith To: 'Black_David@emc.com' ; 'ips@ece.cmu.edu' Cc: Michael Smith Sent: Thursday, July 04, 2002 2:52 AM Subject: RE: iSCSI: Last call comments I support David's suggested clarification and his suggested wording. I struggled for a while understanding this issue and the suggested changes make things much clearer. Mike Smith CTO, iReady -----Original Message----- From: Black_David@emc.com [mailto:Black_David@emc.com] Sent: Wednesday, July 03, 2002 2:54 PM To: mbakke@cisco.com; ips@ece.cmu.edu Subject: RE: iSCSI: Last call comments Mark, > There are a few sections in iSCSI (and ips-security) that discuss > IPsec requirements for "compliant/conformant implementations".  I > recall that this meant a target implementation could either be a > single device with both iSCSI and IPsec, or a combination of two > devices, one that handles iSCSI; the other handling IPsec. In the two device combination, only the combination is compliant, and only at the interface(s) that provide(s) both iSCSI and IPsec. The iSCSI device in the combination is not compliant by itself because it does not provide IPsec. > As there are many cases where it makes a lot of sense to provide > the solution in two pieces (iSCSI in one or more devices, with one or > more IPsec front-end devices, I'd like to clarify this. > > How about (somewhere in section 7) adding something like: > >    An iSCSI compliant initiator or target may provide the required >    IPsec support either by itself, or in conjunction with an IPsec >    front-end device. > > Any thoughts? It would need to have the word "compliant" removed and a sentence added to spell out what is compliant, along the lines of:     An iSCSI initiator or target may provide the required     IPsec support either by itself, or in conjunction with an IPsec     front-end device.  In the latter case only the combination     complies with the requirements of this specification; the     individual iSCSI initiator or target would not comply with     the requirements of this specification due to the lack of IPsec     support. It's probably a good idea to put this in. 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 --------------------------------------------------- > -----Original Message----- > From: Mark Bakke [mailto:mbakke@cisco.com] > Sent: Wednesday, July 03, 2002 5:48 PM > To: IPS > Subject: iSCSI: Last call comments > > > > The iSCSI draft is looking pretty good.  I only have one last-call > comment left: > > There are a few sections in iSCSI (and ips-security) that discuss > IPsec requirements for "compliant/conformant implementations".  I > recall that this meant a target implementation could either be a > single device with both iSCSI and IPsec, or a combination of two > devices, one that handles iSCSI; the other handling IPsec.  However, > I couldn't find anywhere in the spec that spells this out either > way, other than a hint at it in item [3] on page 31 of > ips-security-13: > > > [3]  IPsec is provided by a device external to the actual > iSCSI device. > >      Here the iSCSI header and data CRCs can be kept across > the part of > >      the connection that is not protected by IPsec. For > instance, the > >      iSCSI connection could traverse an extra bus, interface card, > >      network, interface card, and bus between the iSCSI > device and the > >      device providing IPsec. In this case, the iSCSI CRC is > desirable, > >      and the iSCSI implementation behind the IPsec device > may request > >      it. > > As there are many cases where it makes a lot of sense to provide > the solution in two pieces (iSCSI in one or more devices, with one or > more IPsec front-end devices, I'd like to clarify this. > > How about (somewhere in section 7) adding something like: > >    An iSCSI compliant initiator or target may provide the required >    IPsec support either by itself, or in conjunction with an IPsec >    front-end device. > > Any thoughts? > > -- > Mark > > > For reference, here are a few of the statements that would be > helped out by the above. > > iscsi-14 Section 7.3.1: > >    An iSCSI compliant initiator or target MUST provide data integrity >    and authentication by implementing IPsec [RFC2401] with > ESP [RFC2406] >    in tunnel mode and MAY provide data integrity and > authentication by >    implementing IPsec with ESP in transport mode. The IPsec > implementa- >    tion MUST fulfill the following iSCSI specific requirements: > > iscsi-14 Section 7.3.2: > >    An iSCSI compliant initiator or target MUST provide > confidentiality >    by implementing IPsec [RFC2401] with ESP [RFC2406] in > tunnel mode and >    MAY provide confidentiality by implementing IPsec with ESP > in trans- >    port mode. with the following iSCSI specific requirements: > > iscsi-14 Section 7.3.3: > >      - Conformant iSCSI implementations MUST support IKE Main Mode >            and SHOULD support Aggressive Mode. > > --- > ips-security-13 Section 2.3.1: > > All IP block storage security compliant implementations MUST support > IPsec ESP [RFC2406] to provide security for both control packets and > data packets, as well as the replay protection mechanisms of IPsec. > When ESP is utilized, per-packet data origin authentication, integrity > and replay protection MUST be used. > > > -- > Mark A. Bakke > Cisco Systems > mbakke@cisco.com > 763.398.1054 > From owner-ips@ece.cmu.edu Fri Jul 5 14:49:51 2002 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA10393 for ; Fri, 5 Jul 2002 14:49:51 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id g65IWaZ16841 for ips-outgoing; Fri, 5 Jul 2002 14:32:36 -0400 (EDT) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from cygnus.equallogic.com (cygnus.equallogic.com [65.170.102.10]) by ece.cmu.edu (8.11.0/8.10.2) with SMTP id g65IWZX16836 for ; Fri, 5 Jul 2002 14:32:35 -0400 (EDT) Received: from cygnus.equallogic.com (localhost.localdomain [127.0.0.1]) by cygnus.equallogic.com (8.11.6/8.11.6) with ESMTP id g65IWTC04875 for ; Fri, 5 Jul 2002 14:32:29 -0400 Received: from deneb.dev.equallogic.com (deneb.dev.equallogic.com [172.16.1.99]) by cygnus.equallogic.com (8.11.6/8.11.6) with ESMTP id g65IWTQ04869 for ; Fri, 5 Jul 2002 14:32:29 -0400 Received: from PKONING.equallogic.com (localhost.localdomain [127.0.0.1]) by deneb.dev.equallogic.com (8.11.6/8.11.6) with ESMTP id g65IWS426004 for ; Fri, 5 Jul 2002 14:32:29 -0400 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <15653.58941.792000.488211@gargle.gargle.HOWL> Date: Fri, 5 Jul 2002 14:32:29 -0400 From: Paul Koning To: ips@ece.cmu.edu Subject: Re: No decimal bitstrings References: <20020705140222.20617.qmail@web13701.mail.yahoo.com> <018801c22439$ec3160b0$0100000a@JA31> X-Mailer: VM 6.95 under 21.4 (patch 3) "Academic Rigor" XEmacs Lucid Sender: owner-ips@ece.cmu.edu Precedence: bulk Content-Transfer-Encoding: 7bit I believe there are a bunch of comments in favor of not allowing decimal for bitstrings (only for integers) and only one against. This seems to be "rough consensus". paul From owner-ips@ece.cmu.edu Fri Jul 5 14:54:16 2002 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA10638 for ; Fri, 5 Jul 2002 14:54:16 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id g65Ihvd17361 for ips-outgoing; Fri, 5 Jul 2002 14:43:57 -0400 (EDT) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from e31.co.us.ibm.com (e31.co.us.ibm.com [32.97.110.129]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id g65IhtX17357 for ; Fri, 5 Jul 2002 14:43:55 -0400 (EDT) Received: from westrelay01.boulder.ibm.com (westrelay01.boulder.ibm.com [9.17.194.22]) by e31.co.us.ibm.com (8.12.2/8.12.2) with ESMTP id g65IhouJ048208; Fri, 5 Jul 2002 14:43:51 -0400 Received: from d03nm014.boulder.ibm.com (avpilot.boulder.ibm.com [9.17.203.135]) by westrelay01.boulder.ibm.com (8.11.1m3/NCO/VER6.2) with ESMTP id g65Ihoo63704; Fri, 5 Jul 2002 12:43:50 -0600 X-Priority: 1 (High) Importance: Normal Subject: Re: To: "Julian Satran \(Actcom\)" Cc: "Martins Krikis" , "ips" X-Mailer: Lotus Notes Release 5.0.7 March 21, 2001 Message-ID: From: "John Hufferd" Date: Fri, 5 Jul 2002 11:41:22 -0700 X-MIMETrack: Serialize by Router on D03NM014/03/M/IBM(Release 5.0.10 |March 22, 2002) at 07/05/2002 12:43:49 PM MIME-Version: 1.0 Content-type: text/plain; charset=us-ascii Sender: owner-ips@ece.cmu.edu Precedence: bulk Julian's point is valid. However, I think we are getting two things mixed together. The two items are, 1. should a decimal number be usable for string fields. Julian's examples are correct. That, in my opinion should end that part of the discussion. 2. should decimal numbers be larger than what would fit in a 32 bit field. My opinion is that we should future proof our specification to permit decimal numbers which are larger then 32 bits. An implementation can clearly chose not to support 64-bit decimal numbers now, and thus be less easily extensible in the future. However, that may be a trade-off which some think they need to make now. (This is possible since we have not currently identified a hard requirement.) However, the decimal value for 64 bit fields, permits the spec to fully support any vendor "x" keys that permit it, and permits the spec to move forward in the future without revisiting this discussion. In summary, in my opinion, for point 1. decimal numbers do currently map to binary fields so I think that discussion should be over, and for point 2, I think defining 64 bit fields for Decimal Numbers is the right thing to do for future-proofing reasons. . . . John L. Hufferd Senior Technical Staff Member (STSM) IBM/SSG San Jose Ca Main Office (408) 256-0403, Tie: 276-0403, eFax: (408) 904-4688 Home Office (408) 997-6136, Cell: (408) 499-9702 Internet address: hufferd@us.ibm.com "Julian Satran \(Actcom\)" @ece.cmu.edu on 07/05/2002 08:37:51 AM Sent by: owner-ips@ece.cmu.edu To: "Martins Krikis" , "ips" cc: Subject: Re: Martins, In fact reading your note I went back and found an error we may want to correct: TargetPortalGroupTag is a 16 bit binary string and not an number (there is no TPGT that is lower or higher than another TPGT). As for IP addresses they are just for illustration - each of the address item is a an 8 bit binary string of fixed length usually encoded decimal. There are no good examples that need decimals other than TPGT but I see no point in disallowing them for vendor keys and future extensions. Any implementation will have the conversion routines. Restricting the use of decimals beyond what we did does not strike me as useful. Julo ----- Original Message ----- From: "Martins Krikis" To: "Julian Satran (Actcom)" ; "ips" Sent: Friday, July 05, 2002 5:02 PM Subject: Re: > > --- "Julian Satran (Actcom)" > wrote: > > Leading 0 where forbidden after a brief discussion. > > As for unlikely to be used - I could argue for the > > contrary - as in the examples I gave in a previous > > notes. > > Many string copied from humanly readable documents > > tend to be decimal-encoded. > > Julian, > > You are right about the leading 0, thus Bill's > example was a bad one. He is right however about > the inability to express the leading nul-bytes of > a binary string when it is encoded in decimal. > > The examples you gave previously (unless some > have escaped me) were really bad. I have yet to > see a true "binary string" (and not a number) > encoded in decimal. > > Martins Krikis, Intel Corp. > > Disclaimer: these opinions are mine and may not > be those of my employer. > > > __________________________________________________ > Do You Yahoo!? > Sign up for SBC Yahoo! Dial - First Month Free > http://sbc.yahoo.com From owner-ips@ece.cmu.edu Fri Jul 5 15:13:21 2002 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA11831 for ; Fri, 5 Jul 2002 15:13:16 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id g65InYY17638 for ips-outgoing; Fri, 5 Jul 2002 14:49:34 -0400 (EDT) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from cygnus.equallogic.com (cygnus.equallogic.com [65.170.102.10]) by ece.cmu.edu (8.11.0/8.10.2) with SMTP id g65InWX17631 for ; Fri, 5 Jul 2002 14:49:32 -0400 (EDT) Received: from cygnus.equallogic.com (localhost.localdomain [127.0.0.1]) by cygnus.equallogic.com (8.11.6/8.11.6) with ESMTP id g65InQC05060 for ; Fri, 5 Jul 2002 14:49:26 -0400 Received: from deneb.dev.equallogic.com (deneb.dev.equallogic.com [172.16.1.99]) by cygnus.equallogic.com (8.11.6/8.11.6) with ESMTP id g65InQQ05051; Fri, 5 Jul 2002 14:49:26 -0400 Received: from PKONING.equallogic.com (localhost.localdomain [127.0.0.1]) by deneb.dev.equallogic.com (8.11.6/8.11.6) with ESMTP id g65InPn26607; Fri, 5 Jul 2002 14:49:26 -0400 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <15653.59958.795000.390346@gargle.gargle.HOWL> Date: Fri, 5 Jul 2002 14:49:26 -0400 From: Paul Koning To: bernard_aboba@hotmail.com Cc: ips@ece.cmu.edu Subject: Re: IPS security draft: SRP groups References: X-Mailer: VM 6.95 under 21.4 (patch 3) "Academic Rigor" XEmacs Lucid Sender: owner-ips@ece.cmu.edu Precedence: bulk Content-Transfer-Encoding: 7bit Excerpt of message (sent 3 July 2002) by Bernard Aboba: > In answer to your question, here is a suggestion from Dan Simon for > determining the appropriate generators for the IKE primes, for use with SRP. Ok. I didn't know that but I probably would have learned it if I had done the necessary reading about groups and generators. But the point of my question wasn't "is it possible to compute g" but rather "how about supplying g in the spec" (since the g=2 from IKE is not appropriate). It seems a bit redundant for everyone to repeat the search for a suitable g... So what's the story about unlisted groups? Is an implementation that accepts only the groups listed in appendix A, but not any "locally generated" ones, a compliant implementation? If not, why not? > -----Original Message----- > From: Dan Simon > Sent: Friday, June 07, 2002 2:36 PM > To: iscsi-security@external.cisco.com > Subject: SRP groups > > To determine if a given g is a generator of the whole group (a necessary > property for SRP), you need to know the factorization of (p - 1); you > raise the candidate to the power of x for all x which are factors (not > just prime factors) of p - 1, and reject it if you ever get 1 (mod p). In > the case of the IKE primes, which are of the form p - 1 = 2q, q prime, just > test that neither g^2 nor g^q are 1 (mod p); any g that passes that test > will do. If the SRP primes were generated randomly, then their predecessors > (i.e., p - 1) may not be easy to factor; but if they are, then you can > choose a generator for them as I've described. > > Hope that helps, > > Dan > > > ---------- Forwarded message ---------- > Date: Wed, 10 Apr 2002 21:19:18 -0700 > From: Tom Wu > To: Bernard Aboba > Cc: iscsi-security@external.cisco.com > Subject: Re: SRP groups > Bernard, > > I generated the non-IKE primes randomly. I did not go through the full > process of generating numbers with optimized forms, nor did I attempt to > prove them prime using a rigorous test. This was primarily because, at the > time I generated them, those prepackged groups were intended mainly as a > timesaver for people installing the SRP distribution; I expected many admins > to generate their own groups, using the Open Source tconf tool in the SRP > distribution, for their own peace of mind. Ok, so now I'm confused. Dan says "you need to know the factorization of p-1" but presumably that is not known for a randomly chosen p. > The secondary reason was that the requirements/constraints for SRP > groups are not quite the same as the IKE groups. The IKE groups have > the prime as 7 (mod 8) because of the lower-bits optimization, and g = > 2, which can be faster with some bignum implementations. This means > that g generates the group of size (p-1)/2, whereas SRP requires that g > generate the largest group of size (p-1), i.e. a primitive root. > > That said, I'd have no problem with re-using the IKE primes as the prime for > SRP groups, using a different "g" such that it is a primitive root. That's > already been done for bitlengths 768 and 1024. That being the case, it would be good for those values for g to be listed in the spec. paul From owner-ips@ece.cmu.edu Fri Jul 5 15:29:01 2002 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA12453 for ; Fri, 5 Jul 2002 15:29:01 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id g65J7B518411 for ips-outgoing; Fri, 5 Jul 2002 15:07:11 -0400 (EDT) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from d12lmsgate-3.de.ibm.com (d12lmsgate-3.de.ibm.com [195.212.91.201]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id g65J78X18401; Fri, 5 Jul 2002 15:07:09 -0400 (EDT) Received: from d12relay01.de.ibm.com (d12relay01.de.ibm.com [9.165.215.22]) by d12lmsgate-3.de.ibm.com (8.12.3/8.12.3) with ESMTP id g65J6w2F009772; Fri, 5 Jul 2002 21:06:58 +0200 Received: from d10hubm1.telaviv.ibm.com (d10ml001.telaviv.ibm.com [9.148.216.55]) by d12relay01.de.ibm.com (8.11.1m3/NCO/VER6.2) with ESMTP id g65J6wO45592; Fri, 5 Jul 2002 21:06:58 +0200 To: Paul Koning Cc: ips@ece.cmu.edu, owner-ips@ece.cmu.edu MIME-Version: 1.0 Subject: Re: No decimal bitstrings X-Mailer: Lotus Notes Release 5.0.9 November 16, 2001 From: "Julian Satran" Message-ID: Date: Fri, 5 Jul 2002 22:06:55 +0300 X-MIMETrack: Serialize by Router on D10ML001/10/M/IBM(Release 5.0.9a |January 7, 2002) at 05/07/2002 22:06:58, Serialize complete at 05/07/2002 22:06:58 Content-Type: multipart/alternative; boundary="=_alternative 0068201DC2256BED_=" Sender: owner-ips@ece.cmu.edu Precedence: bulk This is a multipart message in MIME format. --=_alternative 0068201DC2256BED_= Content-Type: text/plain; charset="us-ascii" the majority of the list is silent. to me it looks more like a consensus in noise. I think we will have to wait on this. Julo Paul Koning Sent by: owner-ips@ece.cmu.edu 07/05/2002 09:32 PM Please respond to Paul Koning To: ips@ece.cmu.edu cc: Subject: Re: No decimal bitstrings I believe there are a bunch of comments in favor of not allowing decimal for bitstrings (only for integers) and only one against. This seems to be "rough consensus". paul --=_alternative 0068201DC2256BED_= Content-Type: text/html; charset="us-ascii"
the majority of the list is silent. to me it looks more like a consensus in noise.
I think we will have to wait on this.

Julo


Paul Koning <ni1d@arrl.net>
Sent by: owner-ips@ece.cmu.edu

07/05/2002 09:32 PM
Please respond to Paul Koning

       
        To:        ips@ece.cmu.edu
        cc:        
        Subject:        Re: No decimal bitstrings

       


I believe there are a bunch of comments in favor of not allowing
decimal for bitstrings (only for integers) and only one against.

This seems to be "rough consensus".

    paul

--=_alternative 0068201DC2256BED_=-- From owner-ips@ece.cmu.edu Fri Jul 5 20:16:30 2002 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA25943 for ; Fri, 5 Jul 2002 20:16:30 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id g65Nc1v27932 for ips-outgoing; Fri, 5 Jul 2002 19:38:01 -0400 (EDT) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from mail.brocade.com (sj6-b.brocade.com [63.121.140.220]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id g65NbxX27928 for ; Fri, 5 Jul 2002 19:37:59 -0400 (EDT) Received: from hq-ex-c3.brocade.com (hq-ex-c3 [192.168.126.211]) by mail.brocade.com (8.8.8+Sun/8.8.8) with ESMTP id QAA24752; Fri, 5 Jul 2002 16:37:40 -0700 (PDT) Received: by hq-ex-c3.brocade.com with Internet Mail Service (5.5.2653.19) id ; Fri, 5 Jul 2002 16:38:28 -0700 Message-ID: <2F37CED150E21640A9C6E75B8BE6AF830A4D92@hq-ex-4> From: Robert Snively To: "'Martins Krikis'" , "Julian Satran (Actcom)" , Black_David@emc.com Cc: ips@ece.cmu.edu Subject: RE: iSCSI: Decimal encoding - why 64 bits ? Date: Fri, 5 Jul 2002 16:37:58 -0700 X-Mailer: Internet Mail Service (5.5.2653.19) Sender: owner-ips@ece.cmu.edu Precedence: bulk The most common example would probably be the IP address, which is a binary value. It is often presented as four separate decimal numbers for no reason I can think of, except perhaps a feeling that hexadecimal numbers were somehow less user friendly for inexperienced users. See RFC 0790 and RFC 0791. Bob > -----Original Message----- > From: Martins Krikis [mailto:mkrikis@yahoo.com] > Sent: Friday, July 05, 2002 7:42 AM > To: Julian Satran (Actcom); Black_David@emc.com > Cc: ips@ece.cmu.edu > Subject: Re: iSCSI: Decimal encoding - why 64 bits ? > > > > --- "Julian Satran (Actcom)" > wrote: > > Martins - you have a very good point - and we > > considered briefly to forbid > > decimal from the outset but many of the team felt > > that this would be a bad > > idea as values get copied from a context to another. > > And the we looked at > > coding for other RFCs and we found decimal > > everywhere - addresses, > > identifiers, ports etc., and thought it would be a > > bad idea to forbid them > > in iSCSI > > Julian, > > I cannot find a single post on this mailing list > saying that forbidding decimal encoding for binary > items would be a bad idea. I did find several (and > quoted 4) that actually recommended dropping decimal > encoding for binary items. Lately there have been > many more such posts. All those other RFCs, I > suspect, are actually dealing with numbers. I have > no objections to using decimal encoding for numbers > (that is things, that normally fit in your > machine's registers and are treated as numerical, > not as bit-strings). You have yet to provide an > example of something that is clearly a binary > string (and not used as a number) and is being > commonly encoded in decimal. If you find such a > thing, can you tell us what's the scheme for telling > how many null-bytes this binary string starts with? > > Martins Krikis, Intel Corp. > > Disclaimer: these opinions are mine and may not > be those of my employer. > > > __________________________________________________ > Do You Yahoo!? > Sign up for SBC Yahoo! Dial - First Month Free > http://sbc.yahoo.com > From owner-ips@ece.cmu.edu Sat Jul 6 04:00:02 2002 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA14294 for ; Sat, 6 Jul 2002 04:00:01 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id g667P2L10023 for ips-outgoing; Sat, 6 Jul 2002 03:25:02 -0400 (EDT) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from lmail.actcom.co.il (mail.actcom.co.il [192.114.47.13]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id g667OwX10018 for ; Sat, 6 Jul 2002 03:24:59 -0400 (EDT) Received: from JA31 ([192.115.26.20]) by lmail.actcom.co.il (8.11.6/8.11.6) with ESMTP id g667Olg27692; Sat, 6 Jul 2002 10:24:48 +0300 Message-ID: <004b01c224be$33ca5740$0100000a@JA31> From: "Julian Satran \(Actcom\)" To: "Robert Snively" , "'Martins Krikis'" , Cc: References: <2F37CED150E21640A9C6E75B8BE6AF830A4D92@hq-ex-4> Subject: Re: iSCSI: Decimal encoding - why 64 bits ? Date: Sat, 6 Jul 2002 10:24:44 +0300 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2600.0000 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 Sender: owner-ips@ece.cmu.edu Precedence: bulk Content-Transfer-Encoding: 7bit You may want to add to the list port-numbers, domain specific name formats (yes some domains mainly phone systems use decimal encodings). A search for decimal encoded binary strings in the RFC domain gave well over one-hundred results. Julo ----- Original Message ----- From: "Robert Snively" To: "'Martins Krikis'" ; "Julian Satran (Actcom)" ; Cc: Sent: Saturday, July 06, 2002 2:37 AM Subject: RE: iSCSI: Decimal encoding - why 64 bits ? > The most common example would probably be the > IP address, which is a binary value. > It is often presented > as four separate decimal numbers for no reason > I can think of, except perhaps a feeling that > hexadecimal numbers were somehow less user > friendly for inexperienced users. > > See RFC 0790 and RFC 0791. > > Bob > > > -----Original Message----- > > From: Martins Krikis [mailto:mkrikis@yahoo.com] > > Sent: Friday, July 05, 2002 7:42 AM > > To: Julian Satran (Actcom); Black_David@emc.com > > Cc: ips@ece.cmu.edu > > Subject: Re: iSCSI: Decimal encoding - why 64 bits ? > > > > > > > > --- "Julian Satran (Actcom)" > > wrote: > > > Martins - you have a very good point - and we > > > considered briefly to forbid > > > decimal from the outset but many of the team felt > > > that this would be a bad > > > idea as values get copied from a context to another. > > > And the we looked at > > > coding for other RFCs and we found decimal > > > everywhere - addresses, > > > identifiers, ports etc., and thought it would be a > > > bad idea to forbid them > > > in iSCSI > > > > Julian, > > > > I cannot find a single post on this mailing list > > saying that forbidding decimal encoding for binary > > items would be a bad idea. I did find several (and > > quoted 4) that actually recommended dropping decimal > > encoding for binary items. Lately there have been > > many more such posts. All those other RFCs, I > > suspect, are actually dealing with numbers. I have > > no objections to using decimal encoding for numbers > > (that is things, that normally fit in your > > machine's registers and are treated as numerical, > > not as bit-strings). You have yet to provide an > > example of something that is clearly a binary > > string (and not used as a number) and is being > > commonly encoded in decimal. If you find such a > > thing, can you tell us what's the scheme for telling > > how many null-bytes this binary string starts with? > > > > Martins Krikis, Intel Corp. > > > > Disclaimer: these opinions are mine and may not > > be those of my employer. > > > > > > __________________________________________________ > > Do You Yahoo!? > > Sign up for SBC Yahoo! Dial - First Month Free > > http://sbc.yahoo.com > > From owner-ips@ece.cmu.edu Sat Jul 6 11:12:32 2002 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA23050 for ; Sat, 6 Jul 2002 11:12:32 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id g66EYNF02565 for ips-outgoing; Sat, 6 Jul 2002 10:34:23 -0400 (EDT) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from osmtp3.electric.net (osmtp3.electric.net [216.129.90.30]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id g66EYKX02558 for ; Sat, 6 Jul 2002 10:34:21 -0400 (EDT) Received: from [206.175.234.12] (helo=EGRodriguez) by osmtp3.electric.net with asmtp (Exim 3.22 #1) id 17Qqdd-000JsM-04; Sat, 06 Jul 2002 07:34:18 -0700 From: "Elizabeth G. Rodriguez" To: "'Julian Satran \(Actcom\)'" , "'Robert Snively'" , "'Martins Krikis'" , Cc: Subject: RE: iSCSI: Decimal encoding - why 64 bits ? Date: Sat, 6 Jul 2002 09:31:09 -0600 Keywords: IETF-IPS Message-ID: <000001c22502$2b5a84b0$0ceaafce@EGRodriguez> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.3416 Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 In-Reply-To: <004b01c224be$33ca5740$0100000a@JA31> Sender: owner-ips@ece.cmu.edu Precedence: bulk Content-Transfer-Encoding: 7bit Given these examples, I believe that restricting decimal encoded binary strings is not an option. Elizabeth Rodriguez -----Original Message----- From: owner-ips@ece.cmu.edu [mailto:owner-ips@ece.cmu.edu] On Behalf Of Julian Satran (Actcom) Sent: Saturday, July 06, 2002 1:25 AM To: Robert Snively; 'Martins Krikis'; Black_David@emc.com Cc: ips@ece.cmu.edu Subject: Re: iSCSI: Decimal encoding - why 64 bits ? You may want to add to the list port-numbers, domain specific name formats (yes some domains mainly phone systems use decimal encodings). A search for decimal encoded binary strings in the RFC domain gave well over one-hundred results. Julo ----- Original Message ----- From: "Robert Snively" To: "'Martins Krikis'" ; "Julian Satran (Actcom)" ; Cc: Sent: Saturday, July 06, 2002 2:37 AM Subject: RE: iSCSI: Decimal encoding - why 64 bits ? > The most common example would probably be the > IP address, which is a binary value. > It is often presented > as four separate decimal numbers for no reason > I can think of, except perhaps a feeling that > hexadecimal numbers were somehow less user > friendly for inexperienced users. > > See RFC 0790 and RFC 0791. > > Bob > > > -----Original Message----- > > From: Martins Krikis [mailto:mkrikis@yahoo.com] > > Sent: Friday, July 05, 2002 7:42 AM > > To: Julian Satran (Actcom); Black_David@emc.com > > Cc: ips@ece.cmu.edu > > Subject: Re: iSCSI: Decimal encoding - why 64 bits ? > > > > > > > > --- "Julian Satran (Actcom)" > > wrote: > > > Martins - you have a very good point - and we > > > considered briefly to forbid > > > decimal from the outset but many of the team felt > > > that this would be a bad > > > idea as values get copied from a context to another. > > > And the we looked at > > > coding for other RFCs and we found decimal > > > everywhere - addresses, > > > identifiers, ports etc., and thought it would be a > > > bad idea to forbid them > > > in iSCSI > > > > Julian, > > > > I cannot find a single post on this mailing list > > saying that forbidding decimal encoding for binary > > items would be a bad idea. I did find several (and > > quoted 4) that actually recommended dropping decimal > > encoding for binary items. Lately there have been > > many more such posts. All those other RFCs, I > > suspect, are actually dealing with numbers. I have > > no objections to using decimal encoding for numbers > > (that is things, that normally fit in your > > machine's registers and are treated as numerical, > > not as bit-strings). You have yet to provide an > > example of something that is clearly a binary > > string (and not used as a number) and is being > > commonly encoded in decimal. If you find such a > > thing, can you tell us what's the scheme for telling > > how many null-bytes this binary string starts with? > > > > Martins Krikis, Intel Corp. > > > > Disclaimer: these opinions are mine and may not > > be those of my employer. > > > > > > __________________________________________________ > > Do You Yahoo!? > > Sign up for SBC Yahoo! Dial - First Month Free > > http://sbc.yahoo.com > > From owner-ips@ece.cmu.edu Sat Jul 6 22:44:32 2002 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA05490 for ; Sat, 6 Jul 2002 22:44:32 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id g672O5x22718 for ips-outgoing; Sat, 6 Jul 2002 22:24:05 -0400 (EDT) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from msgbas1.cos.agilent.com (msgbas1x.cos.agilent.com [192.25.240.36]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id g672O4X22714 for ; Sat, 6 Jul 2002 22:24:04 -0400 (EDT) Received: from msgrel1t.cos.agilent.com (msgrel1t.cos.agilent.com [130.29.152.157]) by msgbas1.cos.agilent.com (Postfix) with ESMTP id 736A1AE65; Sat, 6 Jul 2002 20:24:03 -0600 (MDT) Received: from axcsbh3.cos.agilent.com (axcsbh3.cos.agilent.com [130.29.152.190]) by msgrel1t.cos.agilent.com (Postfix) with SMTP id 65EBF538; Sat, 6 Jul 2002 20:24:02 -0600 (MDT) Received: from 130.29.152.190 by axcsbh3.cos.agilent.com (InterScan E-Mail VirusWall NT); Sat, 06 Jul 2002 20:24:01 -0600 Received: by axcsbh3.cos.agilent.com with Internet Mail Service (5.5.2653.19) id ; Sat, 6 Jul 2002 20:24:01 -0600 Message-ID: <1BEBA5E8600DD4119A50009027AF54A00CE073B7@axcs04.cos.agilent.com> From: pat_thaler@agilent.com To: Elizabeth.G.Rodriguez@123mail.net, Julian_Satran@actcom.net.il, rsnively@Brocade.COM, mkrikis@yahoo.com, Black_David@emc.com Cc: ips@ece.cmu.edu Subject: RE: iSCSI: Decimal encoding - why 64 bits ? Date: Sat, 6 Jul 2002 20:23:53 -0600 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-ips@ece.cmu.edu Precedence: bulk Elizabeth, None of the examples given use the binary-value value type defined in 4.1. To iSCSI they are all text-values. The issue a number of us have is with binary value (where iSCSI has to convert the value to binary). The only place binary-value is used is in the SRP and CHAP keys. There are at least three ways to address this (in order of my preference, highest first): 1. Change the binary value definition to the current definition for large-binary-value, delete large-binary-value and regular-binary-value from the text formats and change occurrences of large-binary-value to binary-value. 2. Change the upper limit on regular-binary-value to 32 bits. 3. Change SRP and CHAP keys to use large-binary-value. Regards, Pat -----Original Message----- From: Elizabeth G. Rodriguez [mailto:Elizabeth.G.Rodriguez@123mail.net] Sent: Saturday, July 06, 2002 8:31 AM To: 'Julian Satran (Actcom)'; 'Robert Snively'; 'Martins Krikis'; Black_David@emc.com Cc: ips@ece.cmu.edu Subject: RE: iSCSI: Decimal encoding - why 64 bits ? Given these examples, I believe that restricting decimal encoded binary strings is not an option. Elizabeth Rodriguez -----Original Message----- From: owner-ips@ece.cmu.edu [mailto:owner-ips@ece.cmu.edu] On Behalf Of Julian Satran (Actcom) Sent: Saturday, July 06, 2002 1:25 AM To: Robert Snively; 'Martins Krikis'; Black_David@emc.com Cc: ips@ece.cmu.edu Subject: Re: iSCSI: Decimal encoding - why 64 bits ? You may want to add to the list port-numbers, domain specific name formats (yes some domains mainly phone systems use decimal encodings). A search for decimal encoded binary strings in the RFC domain gave well over one-hundred results. Julo ----- Original Message ----- From: "Robert Snively" To: "'Martins Krikis'" ; "Julian Satran (Actcom)" ; Cc: Sent: Saturday, July 06, 2002 2:37 AM Subject: RE: iSCSI: Decimal encoding - why 64 bits ? > The most common example would probably be the > IP address, which is a binary value. > It is often presented > as four separate decimal numbers for no reason > I can think of, except perhaps a feeling that > hexadecimal numbers were somehow less user > friendly for inexperienced users. > > See RFC 0790 and RFC 0791. > > Bob > > > -----Original Message----- > > From: Martins Krikis [mailto:mkrikis@yahoo.com] > > Sent: Friday, July 05, 2002 7:42 AM > > To: Julian Satran (Actcom); Black_David@emc.com > > Cc: ips@ece.cmu.edu > > Subject: Re: iSCSI: Decimal encoding - why 64 bits ? > > > > > > > > --- "Julian Satran (Actcom)" > > wrote: > > > Martins - you have a very good point - and we > > > considered briefly to forbid > > > decimal from the outset but many of the team felt > > > that this would be a bad > > > idea as values get copied from a context to another. > > > And the we looked at > > > coding for other RFCs and we found decimal > > > everywhere - addresses, > > > identifiers, ports etc., and thought it would be a > > > bad idea to forbid them > > > in iSCSI > > > > Julian, > > > > I cannot find a single post on this mailing list > > saying that forbidding decimal encoding for binary > > items would be a bad idea. I did find several (and > > quoted 4) that actually recommended dropping decimal > > encoding for binary items. Lately there have been > > many more such posts. All those other RFCs, I > > suspect, are actually dealing with numbers. I have > > no objections to using decimal encoding for numbers > > (that is things, that normally fit in your > > machine's registers and are treated as numerical, > > not as bit-strings). You have yet to provide an > > example of something that is clearly a binary > > string (and not used as a number) and is being > > commonly encoded in decimal. If you find such a > > thing, can you tell us what's the scheme for telling > > how many null-bytes this binary string starts with? > > > > Martins Krikis, Intel Corp. > > > > Disclaimer: these opinions are mine and may not > > be those of my employer. > > > > > > __________________________________________________ > > Do You Yahoo!? > > Sign up for SBC Yahoo! Dial - First Month Free > > http://sbc.yahoo.com > > From owner-ips@ece.cmu.edu Sat Jul 6 22:45:14 2002 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA05511 for ; Sat, 6 Jul 2002 22:45:13 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id g672VSS22955 for ips-outgoing; Sat, 6 Jul 2002 22:31:28 -0400 (EDT) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from mxic2.corp.emc.com (mxic2.isus.emc.com [128.221.31.40]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id g672VRX22951 for ; Sat, 6 Jul 2002 22:31:27 -0400 (EDT) Received: by mxic2.corp.emc.com with Internet Mail Service (5.5.2653.19) id <31X6NFYN>; Sat, 6 Jul 2002 22:31:21 -0400 Message-ID: <277DD60FB639D511AC0400B0D068B71E0564C034@CORPMX14> From: Black_David@emc.com To: ips@ece.cmu.edu Subject: iSCSI: DLB's Last Call comments Date: Sat, 6 Jul 2002 22:29:23 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-ips@ece.cmu.edu Precedence: bulk I've spent the better part of 3 days reading -14, well, most of it - I didn't check the state machines thoroughly, and my eyes glazed over on the error handling pseudo-code, so I'll simply have to trust that Mallikarjun and the other folks involved got that right. This message contains my Technical comments and the editorial comments that may involve significant work on the draft. My entire set of 140 editorial comments is headed to Julian under separate cover. These comments are submitted as an individual for further discussion - I am *not* wielding my WG co-chair authority to say that these have to be done or else ... I can be talked out of many of these by suitably coherent and convincing technical arguments to the contrary. Please DO NOT REPLY to this message - there's too much stuff in here. Please send a new message with a new subject line to discuss specific comments below. Thanks, --David -- Technical [T.1] 2.2.2.2 Response/Status Numbering and Acknowledging A large absolute difference between StatSN and ExpStatSN may indi- cate a failed connection. Initiators undertake recovery actions if the difference is greater than an implementation defined constant that SHOULD NOT exceed 2**31-1. That's a requirement, not a description. It needs a "SHOULD" or a "MUST" between "Initiators" and "undertake". [T.2] 2.2.6.1 iSCSI Name Requirements The initiator MUST present both its iSCSI Initiator Name and the iSCSI Target Name to which it wishes to connect in the first login request of a new session or connection. The only exception is if a discovery session (see Section 2.3 iSCSI Session Types) is to be established; the iSCSI Initiator Name is still required, but the iSCSI Target Name may be ignored. "may be ignored" or "omitted"? Section 4.3 appears to indicate that "omitted" is the correct word, making the correct wording "MAY be omitted". [T.3] 2.2.6.1 iSCSI Name Requirements iSCSI names must adhere to the following requirements: Use upper case "MUST" instead of "must". Likewise for name encoding requirements a) through d). [T.4] 2.2.6.3.1 Type "iqn." (iSCSI Qualified Name) - A date code, in yyyy-mm format. 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. Oh dear, what happens if a domain name changes hands twice in the same month??? One possible way out is to require that the naming authority owned the domain name at 00:01 GMT on the first day of the month. [T.5] 2.8 Message Synchronization and Steering Since the only mechanism in this class currently specified for iSCSI is markers, this general architectural framework needs to be removed (possibly to other drafts, as some of this material is probably appropriate for an RDDP architecture draft). This section needs to be refocused on the marker mechanism that iSCSI describes, and include a discussion of its use when an iSCSI header CRC check fails. I'd like to see something like one paragraph on what markers are/do, a sentence or two on how they can be used to recover from an iSCSI header CRC check failure, and at most one paragraph on how markers can help steer iSCSI PDUs/payloads into preallocated/queued buffers. The current 4+ pages devoted to 2.8 and its subsections is excessive and an invitation to further problems down the line. [T.6] 2.3 iSCSI Session Types b) Discovery-session - a session opened only for target discov- ery; the target MAY accept only text requests with the SendTar- gets key and a logout request with reason "close the session". Change "MAY" to "MUST", and say that other requests MUST be rejected. [T.7] 2.4.1 iSCSI Architecture Model d) Network Portal - a component of a Network Entity that has a TCP/IP network address and that may be used by an iSCSI Node within that Network Entity for the connection(s) within one of its iSCSI sessions. In an initiator, it is identified by its IP address. In a target, it is identified by its IP address and its listening TCP port. Use of just an IP address to identify an entity such as this doesn't work throuogh NAPTs (Network Address Port Translators). This issue needs to be explained at some point, although I don't think it affects protocol operation. [T.8] 2.4.1 iSCSI Architecture Model f) Portals within a Portal Group are expected to have similar hardware characteristics, as SCSI port specific mode pages may affect all portals within a portal group. (See Section 2.4.3.2 SCSI Mode Pages). "similar hardware characteristics" needs to be explained/qualified, as Section 2.4.3.2 does not contain an adequate explanation of what's going on here and its hardware implications. [T.9] 2.4.2 SCSI Architecture Model The SCSI Port Name is mandatory in iSCSI. When used in SCSI parameter data, the SCSI port name MUST be encoded as: - The iSCSI Name in UTF-8 format, followed by - a comma separator (1 byte), followed by - the ASCII character 'i' (for SCSI Initiator Port) or the ASCII character 't' (for SCSI Target Port), followed by - a comma separator (1 byte), followed by - zero to 3 null pad bytes so that the complete format is a multiple of four bytes long, followed by - the 6byte value of the ISID (for SCSI initiator port) or the 2byte value of the portal group tag (for SCSI target port) in network byte order (BigEndian). That's a peculiar format with padding nulls in the middle and a number concatenated after the padding - for example, it can't be passed in iSCSI login without format conversion. How about converting the number to 4 or 12 bytes of hex (ASCII characters) and moving the padding to the end so the result is actually a string, and excluding the padding from the definition of the name? This will increase the maximum length of port names, but produce names that are easier to deal with. [T.10] 2.4.3.2 SCSI Mode Pages Changes via mode pages to the behavior of a portal group via one iSCSI Target Node should not affect the behavior of this portal group with respect to other iSCSI Target Nodes, even if the underlying implementation of a portal group serves multiple iSCSI Target Nodes in the same Network Entity. I believe "should not" should be "SHOULD NOT". [T.11] 4.1 Text Format decimal-constant: an unsigned decimal number - the digit 0 or a string of 1 or more digits starting with a non-zero digit. This encoding is not used for numerical values equal or greater than 2**64. Decimal-constants are used to encode numerical values or binary strings. When used to encode binary strings decimal constants have an implicit byte-length that is the minimum number of bytes needed to represent the base2 encoding of the decimal number. The last sentence is the "decimal binary strings" issue that has been discussed extensively on the list. One example of the problem is that the decimal number 15 represents the binary string 0xF, but not the binary strings 0x0F or 0x000F, and the latter two are not representable in the decimal format as currently defined. If the difference between these three matters (e.g., SRP's salt [s] parameter is one example where this difference does matter) use of decimal format for binary strings can cause things not to work. Forbidding the use of decimal representation for binary strings would be the simplest change. [T.12] 4.1 Text Format large-numerical-value: an unsigned integer larger than or equal to 2**64 encoded as a hex constant, or base64-constant. Unsigned integer arithmetic applies to large-numeric-values. I believe "larger than or equal to" should be changed to "whose value may be larger than or equal to", as the current text forbids large numerical values from representing values less than 2**64, which seems wrong. [T.13] 4.1 Text Format Any iSCSI target or initiator MUST support receiving at least 16384 bytes of key=value data in a negotiation sequence except when indi- cating support for very long authentication items by offering or selecting authentication methods such as public key certificates in which case they MUST support receiving at least 64 kilobytes of key=value data. This comment is classified as technical to catch the 16kB minimum as an open issue. The "such as" text needs to be cleaned up - the point should be that the 64 kB minimum applies when a authentication method using long authentication items is offered or accepted, and should be accompanied by a specific list of authentication methods in this draft that carry that implication. [T.14] 4.2 Text Mode Negotiation During login, and thereafter, some session or connection parameters are either declared or negotiated through an exchange of textual information. How does a declaration differ from a negotiation? It isn't described in this section, and doesn't seem to be mentioned in any of the subsequent sections about login, until one gets to the text key definitions. [T.15] 4.3.1 Login Phase Start The first Login Response PDU during the Login Phase from the iSCSI target SHOULD return the TargetPortalGroupTag key that contains the tag value of the iSCSI portal group servicing the Login Request PDU. If the iSCSI target implementation supports altering the portal group configuration (including adding, deleting, and swapping of portals in a portal group), it MUST return the TargetPortalGroupTag key carry- ing the tag value of the servicing portal group. Let's make returning this key a MUST in all cases - less text, simpler protocol, simpler code at the Initiator. [T.16] 4.3.4 Connection reinstatement Targets should support opening a second connection even when they do not support multiple connections in Full Feature Phase. Looks like that ought to be an upper case "SHOULD". I think this needs further discussion. Section 5.2 appears to use a lower case "must" for this: Whenever a connection state machine (e.g., CSM-C) enters the CLEANUP_WAIT state (S8), it must go through the state transitions additionally described in the connection cleanup state diagram either a) using a separate full-feature phase connection (let's call it CSM- E) in the LOGGED_IN state in the same session, or b) using a new transport connection (let's call it CSM-I) in the FREE state that is to be added to the same session. Also, the implications of needing to spend resources (e.g., new transport connection) to clean up resources need to be described somewhere - in the worst case, resources for a new transport connection may need to be reserved to avoid deadlock. It doesn't look like there's a problem with the transport (TCP) resources themselves, but this could be an issue for iSCSI connection state resources (what happens if all connections are in CLEANUP_WAIT and there's no iSCSI connection state resource available to open a new transport connection?). The answer is likely to involve killing off a session, but I don't see an obvious explanation of it. Then I get to Section 5.2.2, which describes a transition from CLEANUP_WAIT to FREE (M1) that can happen based on a timeout, and presumably recovers the state resources and hence might make this all work. Whether an additional connection is needed to deal with CLEANUP_WAIT and whether it's MUST/SHOULD/MAY needs to be sorted out, and the various descriptions of it made consistent. [T.17] 6.4 Format Errors The following two explicit violations of PDU layout rules are format errors: a) illegal contents of the PDU header (except the Opcode) - for ex., out-of-range values for certain fields b) inconsistent contents - for ex., value of one field conflicts with that of another. Format errors indicate a major implementation flaw in one of the par- ties. The two "for ex."s aren't good enough. Details on what is a format error need to be spelled out explicitly, given the drastic consequences of committing one. [T.18] 6.7 SCSI Timeouts On a ULP timeout for a command (that carried a CmdSN of n), the iSCSI initiator MUST abort the command by either using the Abort Task task management function request, or a "close the connection" Logout if it intends to continue the session. I think the first part is over specified - there are a number of task management commands that abort the task - if the target is really sick, something much more serious than Abort Task may be used that not only aborts this task, but others. It's not clear whether "if it intends to continue the session" applies only to the logout or to both the task management command and the logout, nor is it clear what an initiator should do if it doesn't intend to continue the session. [T.19] 8.1.1 Conservative Reuse of ISIDs To both minimize the disruption of legacy applications and to better facilitate the SCSI features that rely on persistent names for SCSI ports, iSCSI implementations should attempt to provide a stable pre- sentation of SCSI Initiator Ports That's a requirement - change "should" to "SHOULD". This is a technical comment to (re)open the issue of whether conservative reuse ought to be a "MUST" - T10 is defining persistent reservation functionality that will not behave as one might expect in the absence of conservative reuse - at the very least, this consequence of ignoring the SHOULD needs to be stated. [T.20] 8.2 Autosense and Auto Contingent Allegiance (ACA) Autosense refers to the automatic return of sense data to the initia- tor in case a command did not complete successfully. iSCSI initia- tors and targets MUST support autosense. "MUST support" --> "MUST support and use", as this is not just "MUST implement". [T.21] 8.3 iSCSI timeouts iSCSI recovery actions are often dependent on iSCSI time-outs being recognized and acted upon before SCSI time-outs. Determining the right time-outs to use for various iSCSI actions (command acknowl- edgements expected, status acknowledgements, etc.) is very much dependent on infrastructure (hardware, links, TCP/IP stack, iSCSI driver). As a guidance the implementer may use an average Nop-Out/ Nop-In turnaround delay multiplied by a "safety factor" (2-3) as a good estimate for the basic delay of the iSCSI stack for a given con- nection. "(2-3}" strikes me as low and providing little resilience to "stupid network tricks". I'd change that to something like "(e.g., 5x, with a minimum of several milliseconds)". This is complicated by the fact that both initiators and targets will likely want to insert delays (in the hope that something useful turns up that has to be sent) before sending a NOP to update the various acknowledgement counters (e.g., ExpCmdSN). [T.22] 9.1 iSCSI PDU Length and Padding iSCSI PDUs are padded to the closest integer number of four byte words. The padding bytes SHOULD be 0. "MUST be transmitted as zero and ignored by the receiver, except for calculation of the digest CRCs if present" would be better. Same comment applies to padding bytes for header segments. [T.23] 9.4.1 Flags (byte 1) Bits O and U and bits o and u are mutually exclusive. Need to put some teeth into that. Say that in each pair, it is a protocol error if both bits are set to 1, and refer to the section for handling that error. [T.24] 9.4.4 Residual Count and 9.4.5 Bidirectional Read Residual Count These should be treated as reserved when they're not valid (O and U are zero for Residual Count, o and u are zero for Bidi Read Residual Count) - MUST be set to zero by sender, MUST be ignored by receiver. [T.25] 9.5.2 LUN This field is required for functions that address a specific LU (ABORT TASK, CLEAR TASK SET, ABORT TASK SET, CLEAR ACA, LOGICAL UNIT RESET) and is reserved in all others. Should TASK REASSIGN be added to the list in parentheses? [T.26] 9.6 Task Management Function Response For the functions ABORT TASK, ABORT TASK SET, CLEAR ACA, CLEAR TASK SET, LOGICAL UNIT RESET, TARGET COLD RESET and TARGET WARM RESET, the target performs the requested Task Management function and sends a Task Management Response back to the initiator. TASK REASSIGN does not get a response. Was this intended? [T.27] 9.12.10 ExpStatSN This is ExpStatSN for the old connection. This field is valid only if the Login request restarts a connection (see Section 4.3.4 Connection reinstatement). This is for the Login Request PDU. For the initial Login Request PDU in a login phase, the description is correct, but thereafter, Login Request should be using ExpStatSN to acknowledge the Login Responses via their increasing StatSN values (see 9.13.4). This raises the related question of why StatSN/ ExpStatSN is being used during login while CmdSN/ExpCmdSN is not being used. [T.28] 9.14 Logout Request A successful completion of a logout request with the reason code of "close the connection" or "remove the connection for recovery" results in the discarding of all tasks waiting in the command reor- dering queue that are allegiant to the connection being logged out. "discarding" is not what hapapens in the "remove the connection for recovery case according to the following text from Section 6.5: b) Logout the connection for recovery and continue the tasks on a different connection instance as described in Section 6.1 Retry and Reassign in Recovery. [OR] A "discarded" task cannot be "continue"-d. I suspect the text should say that "close the connection" terminates the tasks, anad "remove the connection for recovery" suspends the tasks with the following CmdSN side effects ... [T.29] 9.14 Logout Request The entire logout discussion in this section is completely applica- ble also for an implicit Logout effected by way of a connection rein- statement or session reinstatement. The Logout reason codes for implicit Logout are specified as below: How are these codes used and why are they specified here? Logout Request is an explicit logout, not implicit. [T.30] 9.16 SNACK Request If the initiator MaxRecvDataSegmenTLength changed Data-In PDUs requested with RunLength 0 (meaning all PDUs after this number) may be different from the ones originally sent, in order to reflect changes in MaxRecvDataSegmentLength. Their DataSN starts with the requested number and is increased by 1 for each resent Data-In PDU. If DataSN numbers change and a SCSI-Reponse PDU was sent reflecting the DataSN before retransmission it MUST be resent to reflect the new numbers. This was discussed on the list, but there are still some problems here: (1) If the MaxRecvDataSegmentLength has changed, the only valid Data SNACK is BegRun=0, RunLength=0 (i.e., resend everything). Attempts to be more clever than this are an invitation to miscount Data-In PDUs and cause problems in the initiator. Targets MUST reject all other Data SNACK requests in this situation. (2) The new SCSI-Response PDU needs a new StatSN to avoid the initiator discarding it as a duplicate. Section 2.2.2.2 is silent on duplicate detection for StatSN, but discarding duplicates would be a reasonable thing for an initiator to do. (3) The initiator needs some way to know that a new response is coming, and specifically whether to expect one or two responses. If it only expects one and two show up, the initiator could reuse the Task Tag once all the data arrives causing a race in which the new response could incorrectly complete an unrelated command (unlikely, but potentially nasty). This suggests calling out the Data SNACK as having special behavior: - It may resegment Data-In PDUs to deal with MaxRecvDataSegmentLength. All other Data SNACK requests MUST NOT resegment. - It *always* generates a new SCSI Response due to the possibility of resegmentation. That's not a great solution, because if one ever sets in a Data SNACK, the resulting behavior change is dramatic and unexpected. This leads to the final proposal: - Specify a new SNACK type code (3) for Resegmenting Data SNACK. SNACK Data-In resegmentation is allowed only when this is used. If resegmentation would be necessary for a Data SNACK (type 1), that SNACK MUST be rejected. - Both BegRun and RunLength MUST be zero for a Resegmenting Data SNACK, and (unlike reserved fields) these MUST be checked by the receiver (target). - A new SCSI Response is always generated as a result of a Resegmenting Data-In SNACK, and it has its own StatSN number to deal with the fact that the number of Data-In PDUs may have changed, causing a change to the ExpDataSN value. This new response also needs to be marked to distinguish it from a response that may have been generated earlier (so the initiator knows to wait for the new response) - using a bit in the flags field for this seems wrong, so specifying a new Response code value (0x02 - see 9.4.3) seems like a reasonable way to accomplish this. - Data SNACK (type 1) now has consistent behavior - it MUST NOT resegment and MUST NOT generate a new SCSI response, ever. This approach also has the potentially useful property of making it easy to yank out the Resegmenting Data SNACK wart if we ever put restrictions on the interaction of MaxRecvDatasegmentLength and Data SNACKs (yes, that's a hint ... this has gotten messy enough that forbidding Data SNACKs when MaxRecvDataSegmentLength has changed needs to be considered as a possible alternative). This issue also affects some text in 9.16.3. [T.31] 9.16.1 Type An iSCSI target that does not support recovery within connection MAY reject the status SNACK with a Reject PDU. If the target supports recovery within connection, it MAY reject the SNACK after which it MUST issue an Asynchronous Message PDU with an iSCSI event that indi- cates "Request Logout". This should be conditioned on the operational ErrorRecoveryLevel of the session, not whether the target supports recovery within connection. [T.32] 10. iSCSI Security Keys and Authentication Methods Only the following keys can be used during the SecurityNegotiation stage of the Login Phase: [ ... snip ...] AuthMethod and all keys listed under AuthMethod along with all of their associated keys. In practice, this forbids vendor-unique authentication methhods, as they would have to define their own text keys (reusing keys for an existing AuthMethod is a *bad* idea). OTOH, Section 10.1 appears to allow vendor-unique authentication methods. The authentication methods that can be used (appear in the list-of- options) are either those listed in the following table or are ven- dor-unique methods: One of these two needs to change, and see also editorial comment [E.136] against the above text from Section 10. Forbidding vendor-unique authentication methods would enhance interoperability. [T.33] 10.5 Challenge Handshake Authentication Protocol (CHAP) For the Algorithm, as stated in [RFC1994], one value is required to be implemented: 5 (CHAP with MD5) To guarantee interoperability, initiators SHOULD always offer it as one of the proposed algorithms. Change that "SHOULD" to a "MUST". [T.34] 11.1 HeaderDigest and DataDigest Proprietary algorithms MAY also be negotiated for digests. Whenever a proprietary algorithm is negotiated, "None" or "CRC32C" should be listed as an option in order to guarantee interoperability. Change "negotiatiated" to "offered" and "should" to "MUST". [T.35] 11.4 TargetName and 11.5 InitiatorName The descriptions of these keys need to have restrictions on changing them added - changing a name after it's been used for initial authentication/ authorization can cause security problems. These restrictions may already exist in the prohibitions on re-negotiating keys, but need to be (re)stated here. [T.36] 11.6 TargetAlias and 11.7 InitiatorAlias Add text here or in Section 10 to say that these keys MUST NOT be used to make authentication, or authorization (including access control) decisions. [T.37] 11.12 ImmediateData If ImmediateData is set to No and InitialR2T is set to No, then the initiator MUST NOT send unsolicited immediate data, but MAY send one unsolicited burst of Data-OUT PDUs. If ImmediateData is set to Yes and InitialR2T is set to No, then the initiator MAY send unsolicited immediate data and/or one unsolicited burst of Data-OUT PDUs. Both of the above uses of "MAY" are problems - my recollection of this is that if InitialR2T=No and there is data to be sent that falls under the implicit Initial R2T, then it MUST be sent as unsolicited Data-Out PDUs. [T.38] 12. IANA Considerations The temporary (user) well-known port number for iSCSI connections assigned by IANA is 3260. Delete "temporary (user)" insert "TCP" before "port number" or add instructions for IANA to allocate a system port when this draft is approved to become an RFC - I think just sticking with 3260 is better. [T.39] 12. IANA Considerations If vendor additions of values to existing keys is to be allowed (e.g., AuthMethod, HeaderDigest, DataDigest) an IANA registry is needed for each set of values - see [T.32] and [T.34], or the reversed DNS convention needs to be extended from keys to values - the latter doesn't sound like a good idea. -- Editorial Global Editorial comment: Both the login (4) and error handling (6) sections feel like one of those old Adventure mazes of twisty little passages - all the details seem to be there, for the most part they're correct, but it's very hard to get the proverbial "big picture" of how everything fits together, in terms of how the various mechanisms work with each other and how they accomplish the overall functionality. Both of these could use overview sections describing how the functionality breaks down into the pieces described in the subsections and how they fit together. Swapping the order of Sections 5 and 6 would also be a good idea so that the discussion of Error Handling and Recovery comes before the state machine descriptions that contain a lot of the details of how errors are handled. For error handling, moving Section 6.13 to the front of Section 6 would help organize the Section better, and care should be taken to define or replace terms like "restart login" and "recovery R2T" that are currently used without definitions. Also the following two editorial comments recommend serious restructuring of a portion of the draft: [E.80] 5.1 Standard Connection State Diagrams I'm probably going to take grief for this comment because it's a lot of work, but I think this section would be significantly clearer if the state and transition descriptions were split into separate initiator and target portions, so the order of the subsections would be: - Initiator diagram - Initiator state descriptions - Initiator transition descriptions - Target diagram - Target state descriptions - Target transition descriptions I guess it's ok to leave the descriptions merged in Section 5.2. [E.81] 5.3 Session State Diagrams This should be restructured in a fashion similar to Section 5.1 (see [E.80]). If you made it this far, thanks for taking the time to read everything, --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 --------------------------------------------------- From owner-ips@ece.cmu.edu Sat Jul 6 22:45:28 2002 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA05526 for ; Sat, 6 Jul 2002 22:45:28 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id g6725NJ22073 for ips-outgoing; Sat, 6 Jul 2002 22:05:23 -0400 (EDT) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from mxic2.corp.emc.com (mxic2.isus.emc.com [128.221.31.40]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id g6725MX22069 for ; Sat, 6 Jul 2002 22:05:22 -0400 (EDT) Received: by mxic2.corp.emc.com with Internet Mail Service (5.5.2653.19) id <31X6NFNA>; Sat, 6 Jul 2002 22:05:16 -0400 Message-ID: <277DD60FB639D511AC0400B0D068B71E0564C032@CORPMX14> From: Black_David@emc.com To: ni1d@arrl.net, ips@ece.cmu.edu Subject: RE: No decimal bitstrings Date: Sat, 6 Jul 2002 22:03:17 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-ips@ece.cmu.edu Precedence: bulk Kindly leave calling of "rough consensus" to the co-chairs. What I think I've seen so far is that decimal does not work and needs to be forbidden for *variable length* binary bit strings whose length cannot be determined by means other than looking at the value. SRP_s is an example, as the length of a password "salt" may vary based on implementation, but if different length bit strings are used by the initiator and target, the SRP authentication will almost certainly fail (Paul Koning was right about this one). OTOH, decimal seems to work fine for fixed length binary items where the fixed length is known such as the components of an IP address (each component is known to be 8 bits a priori, hence 0x1 and 0x01 represent the same component), or an iSCSI Target Portal Group Tag (known to be 16 bits a priori, hence 0x1, 0x01, 0x001, and 0x0001 are all the same tag). Can we also stop using the word "vote"? If I see 7 people in favor of one position, one person in favor of a different one, and the latter one person has technical correctness on his/her side, that one person's position will carry the day independent of how many people are involved. IETF is about doing the proverbial "right thing", which is not necessarily the most popular thing (just wait until you see my WG last call comments on iSCSI ...). 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 --------------------------------------------------- > -----Original Message----- > From: Paul Koning [mailto:ni1d@arrl.net] > Sent: Friday, July 05, 2002 2:32 PM > To: ips@ece.cmu.edu > Subject: Re: No decimal bitstrings > > > I believe there are a bunch of comments in favor of not allowing > decimal for bitstrings (only for integers) and only one against. > > This seems to be "rough consensus". > > paul > From owner-ips@ece.cmu.edu Sat Jul 6 22:46:18 2002 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA05542 for ; Sat, 6 Jul 2002 22:46:18 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id g672bRO23114 for ips-outgoing; Sat, 6 Jul 2002 22:37:27 -0400 (EDT) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from msgbas1.cos.agilent.com (msgbas1x.cos.agilent.com [192.25.240.36]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id g672bPX23110 for ; Sat, 6 Jul 2002 22:37:25 -0400 (EDT) Received: from msgrel1t.cos.agilent.com (msgrel1t.cos.agilent.com [130.29.152.157]) by msgbas1.cos.agilent.com (Postfix) with ESMTP id 03809AB1B; Sat, 6 Jul 2002 20:37:25 -0600 (MDT) Received: from axcsbh6.cos.agilent.com (axcsbh6.cos.agilent.com [130.29.152.171]) by msgrel1t.cos.agilent.com (Postfix) with SMTP id B2D7F564; Sat, 6 Jul 2002 20:37:24 -0600 (MDT) Received: from 130.29.152.171 by axcsbh6.cos.agilent.com (InterScan E-Mail VirusWall NT); Sat, 06 Jul 2002 20:37:24 -0600 Received: by axcsbh6.cos.agilent.com with Internet Mail Service (5.5.2653.19) id ; Sat, 6 Jul 2002 20:37:24 -0600 Message-ID: <1BEBA5E8600DD4119A50009027AF54A00CE073B8@axcs04.cos.agilent.com> From: pat_thaler@agilent.com To: hufferd@us.ibm.com, Julian_Satran@actcom.net.il Cc: mkrikis@yahoo.com, ips@ece.cmu.edu Subject: RE: Date: Sat, 6 Jul 2002 20:37:23 -0600 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-ips@ece.cmu.edu Precedence: bulk John, You have left out the third thing being discussed which is decimal numbers for binary-value fields (which are used in SRP and CHAP). The current draft allows them when the binary-value represents a value less than 64 bits. This is a problem as it does currently require a 58-bit decimal to binary conversion. Pat -----Original Message----- From: John Hufferd [mailto:hufferd@us.ibm.com] Sent: Friday, July 05, 2002 11:41 AM To: Julian Satran (Actcom) Cc: Martins Krikis; ips Subject: Re: Julian's point is valid. However, I think we are getting two things mixed together. The two items are, 1. should a decimal number be usable for string fields. Julian's examples are correct. That, in my opinion should end that part of the discussion. 2. should decimal numbers be larger than what would fit in a 32 bit field. My opinion is that we should future proof our specification to permit decimal numbers which are larger then 32 bits. An implementation can clearly chose not to support 64-bit decimal numbers now, and thus be less easily extensible in the future. However, that may be a trade-off which some think they need to make now. (This is possible since we have not currently identified a hard requirement.) However, the decimal value for 64 bit fields, permits the spec to fully support any vendor "x" keys that permit it, and permits the spec to move forward in the future without revisiting this discussion. In summary, in my opinion, for point 1. decimal numbers do currently map to binary fields so I think that discussion should be over, and for point 2, I think defining 64 bit fields for Decimal Numbers is the right thing to do for future-proofing reasons. . . . John L. Hufferd Senior Technical Staff Member (STSM) IBM/SSG San Jose Ca Main Office (408) 256-0403, Tie: 276-0403, eFax: (408) 904-4688 Home Office (408) 997-6136, Cell: (408) 499-9702 Internet address: hufferd@us.ibm.com "Julian Satran \(Actcom\)" @ece.cmu.edu on 07/05/2002 08:37:51 AM Sent by: owner-ips@ece.cmu.edu To: "Martins Krikis" , "ips" cc: Subject: Re: Martins, In fact reading your note I went back and found an error we may want to correct: TargetPortalGroupTag is a 16 bit binary string and not an number (there is no TPGT that is lower or higher than another TPGT). As for IP addresses they are just for illustration - each of the address item is a an 8 bit binary string of fixed length usually encoded decimal. There are no good examples that need decimals other than TPGT but I see no point in disallowing them for vendor keys and future extensions. Any implementation will have the conversion routines. Restricting the use of decimals beyond what we did does not strike me as useful. Julo ----- Original Message ----- From: "Martins Krikis" To: "Julian Satran (Actcom)" ; "ips" Sent: Friday, July 05, 2002 5:02 PM Subject: Re: > > --- "Julian Satran (Actcom)" > wrote: > > Leading 0 where forbidden after a brief discussion. > > As for unlikely to be used - I could argue for the > > contrary - as in the examples I gave in a previous > > notes. > > Many string copied from humanly readable documents > > tend to be decimal-encoded. > > Julian, > > You are right about the leading 0, thus Bill's > example was a bad one. He is right however about > the inability to express the leading nul-bytes of > a binary string when it is encoded in decimal. > > The examples you gave previously (unless some > have escaped me) were really bad. I have yet to > see a true "binary string" (and not a number) > encoded in decimal. > > Martins Krikis, Intel Corp. > > Disclaimer: these opinions are mine and may not > be those of my employer. > > > __________________________________________________ > Do You Yahoo!? > Sign up for SBC Yahoo! Dial - First Month Free > http://sbc.yahoo.com From owner-ips@ece.cmu.edu Sat Jul 6 22:47:08 2002 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA05560 for ; Sat, 6 Jul 2002 22:47:08 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id g672DFI22381 for ips-outgoing; Sat, 6 Jul 2002 22:13:15 -0400 (EDT) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from mxic2.corp.emc.com (mxic2.isus.emc.com [128.221.31.40]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id g672DFX22377 for ; Sat, 6 Jul 2002 22:13:15 -0400 (EDT) Received: by mxic2.corp.emc.com with Internet Mail Service (5.5.2653.19) id <31X6NFQ3>; Sat, 6 Jul 2002 22:13:09 -0400 Message-ID: <277DD60FB639D511AC0400B0D068B71E0564C033@CORPMX14> From: Black_David@emc.com To: ni1d@arrl.net Cc: ips@ece.cmu.edu Subject: RE: IPS security draft: SRP groups Date: Sat, 6 Jul 2002 22:11:11 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-ips@ece.cmu.edu Precedence: bulk Missed this earlier, sorry ... > Ok. I didn't know that but I probably would have learned it if I had > done the necessary reading about groups and generators. But the point > of my question wasn't "is it possible to compute g" but rather "how > about supplying g in the spec" (since the g=2 from IKE is not > appropriate). It seems a bit redundant for everyone to repeat the > search for a suitable g... > > So what's the story about unlisted groups? Is an implementation that > accepts only the groups listed in appendix A, but not any "locally > generated" ones, a compliant implementation? > Yes - accepting those groups and only those groups is the minimum (MUST) requirement. If the IKE groups are to remain allowed, we need to specify generators for their use with SRP - please consider this to be a serious *PLEA* for someone to volunteer to do the crpto-theoretic number crunching needed to find SRP generators for those groups and/or prove the primality of the SRP primes. Lack of progress here has the potential to hold up the security draft on which *all* of our protocol drafts depend (normative references). We can promise at least 30 minutes of fame (*twice* the proverbial 15 ;-) ) to those who resolve this issue ... 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 --------------------------------------------------- From owner-ips@ece.cmu.edu Sat Jul 6 22:47:53 2002 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA05581 for ; Sat, 6 Jul 2002 22:47:52 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id g672N1922670 for ips-outgoing; Sat, 6 Jul 2002 22:23:01 -0400 (EDT) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from msgbas2.cos.agilent.com (msgbas2x.cos.agilent.com [192.25.240.37]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id g672N0X22664 for ; Sat, 6 Jul 2002 22:23:00 -0400 (EDT) Received: from msgrel1t.cos.agilent.com (msgrel1t.cos.agilent.com [130.29.152.157]) by msgbas2.cos.agilent.com (Postfix) with ESMTP id 5E6C018C9 for ; Sat, 6 Jul 2002 20:22:59 -0600 (MDT) Received: from axcsbh4.cos.agilent.com (axcsbh4.cos.agilent.com [130.29.152.145]) by msgrel1t.cos.agilent.com (Postfix) with SMTP id 17FD0596 for ; Sat, 6 Jul 2002 20:22:59 -0600 (MDT) Received: from 130.29.152.145 by axcsbh4.cos.agilent.com (InterScan E-Mail VirusWall NT); Sat, 06 Jul 2002 20:22:58 -0600 Received: by axcsbh4.cos.agilent.com with Internet Mail Service (5.5.2653.19) id ; Sat, 6 Jul 2002 20:22:58 -0600 Message-ID: <1BEBA5E8600DD4119A50009027AF54A00CE073B6@axcs04.cos.agilent.com> From: pat_thaler@agilent.com Cc: ips@ece.cmu.edu Subject: RE: iSCSI: Decimal encoding - why 64 bits ? Date: Sat, 6 Jul 2002 20:22:56 -0600 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-ips@ece.cmu.edu Precedence: bulk Elizabeth, None of the examples given use the binary-value value type defined in 4.1. To iSCSI they are all text-values. The issue a number of us have is with binary value (where iSCSI has to convert the value to binary). The only place binary-value is used is in the SRP and CHAP keys. There are at least three ways to address this (in order of my preference, highest first): 1. Change the binary value definition to the current definition for large-binary-value, delete large-binary-value and regular-binary-value from the text formats and change occurrences of large-binary-value to binary-value. 2. Change the upper limit on regular-binary-value to 32 bits. 3. Change SRP and CHAP keys to use large-binary-value. Regards, Pat -----Original Message----- From: Elizabeth G. Rodriguez [mailto:Elizabeth.G.Rodriguez@123mail.net] Sent: Saturday, July 06, 2002 8:31 AM To: 'Julian Satran (Actcom)'; 'Robert Snively'; 'Martins Krikis'; Black_David@emc.com Cc: ips@ece.cmu.edu Subject: RE: iSCSI: Decimal encoding - why 64 bits ? Given these examples, I believe that restricting decimal encoded binary strings is not an option. Elizabeth Rodriguez -----Original Message----- From: owner-ips@ece.cmu.edu [mailto:owner-ips@ece.cmu.edu] On Behalf Of Julian Satran (Actcom) Sent: Saturday, July 06, 2002 1:25 AM To: Robert Snively; 'Martins Krikis'; Black_David@emc.com Cc: ips@ece.cmu.edu Subject: Re: iSCSI: Decimal encoding - why 64 bits ? You may want to add to the list port-numbers, domain specific name formats (yes some domains mainly phone systems use decimal encodings). A search for decimal encoded binary strings in the RFC domain gave well over one-hundred results. Julo ----- Original Message ----- From: "Robert Snively" To: "'Martins Krikis'" ; "Julian Satran (Actcom)" ; Cc: Sent: Saturday, July 06, 2002 2:37 AM Subject: RE: iSCSI: Decimal encoding - why 64 bits ? > The most common example would probably be the > IP address, which is a binary value. > It is often presented > as four separate decimal numbers for no reason > I can think of, except perhaps a feeling that > hexadecimal numbers were somehow less user > friendly for inexperienced users. > > See RFC 0790 and RFC 0791. > > Bob > > > -----Original Message----- > > From: Martins Krikis [mailto:mkrikis@yahoo.com] > > Sent: Friday, July 05, 2002 7:42 AM > > To: Julian Satran (Actcom); Black_David@emc.com > > Cc: ips@ece.cmu.edu > > Subject: Re: iSCSI: Decimal encoding - why 64 bits ? > > > > > > > > --- "Julian Satran (Actcom)" > > wrote: > > > Martins - you have a very good point - and we > > > considered briefly to forbid > > > decimal from the outset but many of the team felt > > > that this would be a bad > > > idea as values get copied from a context to another. > > > And the we looked at > > > coding for other RFCs and we found decimal > > > everywhere - addresses, > > > identifiers, ports etc., and thought it would be a > > > bad idea to forbid them > > > in iSCSI > > > > Julian, > > > > I cannot find a single post on this mailing list > > saying that forbidding decimal encoding for binary > > items would be a bad idea. I did find several (and > > quoted 4) that actually recommended dropping decimal > > encoding for binary items. Lately there have been > > many more such posts. All those other RFCs, I > > suspect, are actually dealing with numbers. I have > > no objections to using decimal encoding for numbers > > (that is things, that normally fit in your > > machine's registers and are treated as numerical, > > not as bit-strings). You have yet to provide an > > example of something that is clearly a binary > > string (and not used as a number) and is being > > commonly encoded in decimal. If you find such a > > thing, can you tell us what's the scheme for telling > > how many null-bytes this binary string starts with? > > > > Martins Krikis, Intel Corp. > > > > Disclaimer: these opinions are mine and may not > > be those of my employer. > > > > > > __________________________________________________ > > Do You Yahoo!? > > Sign up for SBC Yahoo! Dial - First Month Free > > http://sbc.yahoo.com > > From owner-ips@ece.cmu.edu Sun Jul 7 01:28:18 2002 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA07005 for ; Sun, 7 Jul 2002 01:28:18 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id g674nXp26526 for ips-outgoing; Sun, 7 Jul 2002 00:49:33 -0400 (EDT) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from d12lmsgate-3.de.ibm.com (d12lmsgate-3.de.ibm.com [195.212.91.201]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id g674nSX26515; Sun, 7 Jul 2002 00:49:28 -0400 (EDT) Received: from d12relay01.de.ibm.com (d12relay01.de.ibm.com [9.165.215.22]) by d12lmsgate-3.de.ibm.com (8.12.3/8.12.3) with ESMTP id g674nM2F036710; Sun, 7 Jul 2002 06:49:22 +0200 Received: from d10hubm1.telaviv.ibm.com (d10ml001.telaviv.ibm.com [9.148.216.55]) by d12relay01.de.ibm.com (8.11.1m3/NCO/VER6.2) with ESMTP id g674nLQ122756; Sun, 7 Jul 2002 06:49:21 +0200 To: Black_David@emc.com Cc: ips@ece.cmu.edu, owner-ips@ece.cmu.edu MIME-Version: 1.0 Subject: Re: iSCSI: DLB's Last Call comments X-Mailer: Lotus Notes Release 5.0.9 November 16, 2001 From: "Julian Satran" Message-ID: Date: Sun, 7 Jul 2002 07:49:15 +0300 X-MIMETrack: Serialize by Router on D10ML001/10/M/IBM(Release 5.0.9a |January 7, 2002) at 07/07/2002 07:49:21, Serialize complete at 07/07/2002 07:49:21 Content-Type: multipart/alternative; boundary="=_alternative 00174B57C2256BEF_=" Sender: owner-ips@ece.cmu.edu Precedence: bulk This is a multipart message in MIME format. --=_alternative 00174B57C2256BEF_= Content-Type: text/plain; charset="us-ascii" Thanks for the careful reading. I will answer to your items as I get to them and list them and proposed resolution in the usual place. You did not leave me to much time tough. Julo Black_David@emc.com Sent by: owner-ips@ece.cmu.edu 07/07/2002 05:29 AM Please respond to Black_David To: ips@ece.cmu.edu cc: Subject: iSCSI: DLB's Last Call comments I've spent the better part of 3 days reading -14, well, most of it - I didn't check the state machines thoroughly, and my eyes glazed over on the error handling pseudo-code, so I'll simply have to trust that Mallikarjun and the other folks involved got that right. This message contains my Technical comments and the editorial comments that may involve significant work on the draft. My entire set of 140 editorial comments is headed to Julian under separate cover. These comments are submitted as an individual for further discussion - I am *not* wielding my WG co-chair authority to say that these have to be done or else ... I can be talked out of many of these by suitably coherent and convincing technical arguments to the contrary. Please DO NOT REPLY to this message - there's too much stuff in here. Please send a new message with a new subject line to discuss specific comments below. Thanks, --David -- Technical [T.1] 2.2.2.2 Response/Status Numbering and Acknowledging A large absolute difference between StatSN and ExpStatSN may indi- cate a failed connection. Initiators undertake recovery actions if the difference is greater than an implementation defined constant that SHOULD NOT exceed 2**31-1. That's a requirement, not a description. It needs a "SHOULD" or a "MUST" between "Initiators" and "undertake". [T.2] 2.2.6.1 iSCSI Name Requirements The initiator MUST present both its iSCSI Initiator Name and the iSCSI Target Name to which it wishes to connect in the first login request of a new session or connection. The only exception is if a discovery session (see Section 2.3 iSCSI Session Types) is to be established; the iSCSI Initiator Name is still required, but the iSCSI Target Name may be ignored. "may be ignored" or "omitted"? Section 4.3 appears to indicate that "omitted" is the correct word, making the correct wording "MAY be omitted". [T.3] 2.2.6.1 iSCSI Name Requirements iSCSI names must adhere to the following requirements: Use upper case "MUST" instead of "must". Likewise for name encoding requirements a) through d). [T.4] 2.2.6.3.1 Type "iqn." (iSCSI Qualified Name) - A date code, in yyyy-mm format. 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. Oh dear, what happens if a domain name changes hands twice in the same month??? One possible way out is to require that the naming authority owned the domain name at 00:01 GMT on the first day of the month. [T.5] 2.8 Message Synchronization and Steering Since the only mechanism in this class currently specified for iSCSI is markers, this general architectural framework needs to be removed (possibly to other drafts, as some of this material is probably appropriate for an RDDP architecture draft). This section needs to be refocused on the marker mechanism that iSCSI describes, and include a discussion of its use when an iSCSI header CRC check fails. I'd like to see something like one paragraph on what markers are/do, a sentence or two on how they can be used to recover from an iSCSI header CRC check failure, and at most one paragraph on how markers can help steer iSCSI PDUs/payloads into preallocated/queued buffers. The current 4+ pages devoted to 2.8 and its subsections is excessive and an invitation to further problems down the line. [T.6] 2.3 iSCSI Session Types b) Discovery-session - a session opened only for target discov- ery; the target MAY accept only text requests with the SendTar- gets key and a logout request with reason "close the session". Change "MAY" to "MUST", and say that other requests MUST be rejected. [T.7] 2.4.1 iSCSI Architecture Model d) Network Portal - a component of a Network Entity that has a TCP/IP network address and that may be used by an iSCSI Node within that Network Entity for the connection(s) within one of its iSCSI sessions. In an initiator, it is identified by its IP address. In a target, it is identified by its IP address and its listening TCP port. Use of just an IP address to identify an entity such as this doesn't work throuogh NAPTs (Network Address Port Translators). This issue needs to be explained at some point, although I don't think it affects protocol operation. [T.8] 2.4.1 iSCSI Architecture Model f) Portals within a Portal Group are expected to have similar hardware characteristics, as SCSI port specific mode pages may affect all portals within a portal group. (See Section 2.4.3.2 SCSI Mode Pages). "similar hardware characteristics" needs to be explained/qualified, as Section 2.4.3.2 does not contain an adequate explanation of what's going on here and its hardware implications. [T.9] 2.4.2 SCSI Architecture Model The SCSI Port Name is mandatory in iSCSI. When used in SCSI parameter data, the SCSI port name MUST be encoded as: - The iSCSI Name in UTF-8 format, followed by - a comma separator (1 byte), followed by - the ASCII character 'i' (for SCSI Initiator Port) or the ASCII character 't' (for SCSI Target Port), followed by - a comma separator (1 byte), followed by - zero to 3 null pad bytes so that the complete format is a multiple of four bytes long, followed by - the 6byte value of the ISID (for SCSI initiator port) or the 2byte value of the portal group tag (for SCSI target port) in network byte order (BigEndian). That's a peculiar format with padding nulls in the middle and a number concatenated after the padding - for example, it can't be passed in iSCSI login without format conversion. How about converting the number to 4 or 12 bytes of hex (ASCII characters) and moving the padding to the end so the result is actually a string, and excluding the padding from the definition of the name? This will increase the maximum length of port names, but produce names that are easier to deal with. [T.10] 2.4.3.2 SCSI Mode Pages Changes via mode pages to the behavior of a portal group via one iSCSI Target Node should not affect the behavior of this portal group with respect to other iSCSI Target Nodes, even if the underlying implementation of a portal group serves multiple iSCSI Target Nodes in the same Network Entity. I believe "should not" should be "SHOULD NOT". [T.11] 4.1 Text Format decimal-constant: an unsigned decimal number - the digit 0 or a string of 1 or more digits starting with a non-zero digit. This encoding is not used for numerical values equal or greater than 2**64. Decimal-constants are used to encode numerical values or binary strings. When used to encode binary strings decimal constants have an implicit byte-length that is the minimum number of bytes needed to represent the base2 encoding of the decimal number. The last sentence is the "decimal binary strings" issue that has been discussed extensively on the list. One example of the problem is that the decimal number 15 represents the binary string 0xF, but not the binary strings 0x0F or 0x000F, and the latter two are not representable in the decimal format as currently defined. If the difference between these three matters (e.g., SRP's salt [s] parameter is one example where this difference does matter) use of decimal format for binary strings can cause things not to work. Forbidding the use of decimal representation for binary strings would be the simplest change. [T.12] 4.1 Text Format large-numerical-value: an unsigned integer larger than or equal to 2**64 encoded as a hex constant, or base64-constant. Unsigned integer arithmetic applies to large-numeric-values. I believe "larger than or equal to" should be changed to "whose value may be larger than or equal to", as the current text forbids large numerical values from representing values less than 2**64, which seems wrong. [T.13] 4.1 Text Format Any iSCSI target or initiator MUST support receiving at least 16384 bytes of key=value data in a negotiation sequence except when indi- cating support for very long authentication items by offering or selecting authentication methods such as public key certificates in which case they MUST support receiving at least 64 kilobytes of key=value data. This comment is classified as technical to catch the 16kB minimum as an open issue. The "such as" text needs to be cleaned up - the point should be that the 64 kB minimum applies when a authentication method using long authentication items is offered or accepted, and should be accompanied by a specific list of authentication methods in this draft that carry that implication. [T.14] 4.2 Text Mode Negotiation During login, and thereafter, some session or connection parameters are either declared or negotiated through an exchange of textual information. How does a declaration differ from a negotiation? It isn't described in this section, and doesn't seem to be mentioned in any of the subsequent sections about login, until one gets to the text key definitions. [T.15] 4.3.1 Login Phase Start The first Login Response PDU during the Login Phase from the iSCSI target SHOULD return the TargetPortalGroupTag key that contains the tag value of the iSCSI portal group servicing the Login Request PDU. If the iSCSI target implementation supports altering the portal group configuration (including adding, deleting, and swapping of portals in a portal group), it MUST return the TargetPortalGroupTag key carry- ing the tag value of the servicing portal group. Let's make returning this key a MUST in all cases - less text, simpler protocol, simpler code at the Initiator. [T.16] 4.3.4 Connection reinstatement Targets should support opening a second connection even when they do not support multiple connections in Full Feature Phase. Looks like that ought to be an upper case "SHOULD". I think this needs further discussion. Section 5.2 appears to use a lower case "must" for this: Whenever a connection state machine (e.g., CSM-C) enters the CLEANUP_WAIT state (S8), it must go through the state transitions additionally described in the connection cleanup state diagram either a) using a separate full-feature phase connection (let's call it CSM- E) in the LOGGED_IN state in the same session, or b) using a new transport connection (let's call it CSM-I) in the FREE state that is to be added to the same session. Also, the implications of needing to spend resources (e.g., new transport connection) to clean up resources need to be described somewhere - in the worst case, resources for a new transport connection may need to be reserved to avoid deadlock. It doesn't look like there's a problem with the transport (TCP) resources themselves, but this could be an issue for iSCSI connection state resources (what happens if all connections are in CLEANUP_WAIT and there's no iSCSI connection state resource available to open a new transport connection?). The answer is likely to involve killing off a session, but I don't see an obvious explanation of it. Then I get to Section 5.2.2, which describes a transition from CLEANUP_WAIT to FREE (M1) that can happen based on a timeout, and presumably recovers the state resources and hence might make this all work. Whether an additional connection is needed to deal with CLEANUP_WAIT and whether it's MUST/SHOULD/MAY needs to be sorted out, and the various descriptions of it made consistent. [T.17] 6.4 Format Errors The following two explicit violations of PDU layout rules are format errors: a) illegal contents of the PDU header (except the Opcode) - for ex., out-of-range values for certain fields b) inconsistent contents - for ex., value of one field conflicts with that of another. Format errors indicate a major implementation flaw in one of the par- ties. The two "for ex."s aren't good enough. Details on what is a format error need to be spelled out explicitly, given the drastic consequences of committing one. [T.18] 6.7 SCSI Timeouts On a ULP timeout for a command (that carried a CmdSN of n), the iSCSI initiator MUST abort the command by either using the Abort Task task management function request, or a "close the connection" Logout if it intends to continue the session. I think the first part is over specified - there are a number of task management commands that abort the task - if the target is really sick, something much more serious than Abort Task may be used that not only aborts this task, but others. It's not clear whether "if it intends to continue the session" applies only to the logout or to both the task management command and the logout, nor is it clear what an initiator should do if it doesn't intend to continue the session. [T.19] 8.1.1 Conservative Reuse of ISIDs To both minimize the disruption of legacy applications and to better facilitate the SCSI features that rely on persistent names for SCSI ports, iSCSI implementations should attempt to provide a stable pre- sentation of SCSI Initiator Ports That's a requirement - change "should" to "SHOULD". This is a technical comment to (re)open the issue of whether conservative reuse ought to be a "MUST" - T10 is defining persistent reservation functionality that will not behave as one might expect in the absence of conservative reuse - at the very least, this consequence of ignoring the SHOULD needs to be stated. [T.20] 8.2 Autosense and Auto Contingent Allegiance (ACA) Autosense refers to the automatic return of sense data to the initia- tor in case a command did not complete successfully. iSCSI initia- tors and targets MUST support autosense. "MUST support" --> "MUST support and use", as this is not just "MUST implement". [T.21] 8.3 iSCSI timeouts iSCSI recovery actions are often dependent on iSCSI time-outs being recognized and acted upon before SCSI time-outs. Determining the right time-outs to use for various iSCSI actions (command acknowl- edgements expected, status acknowledgements, etc.) is very much dependent on infrastructure (hardware, links, TCP/IP stack, iSCSI driver). As a guidance the implementer may use an average Nop-Out/ Nop-In turnaround delay multiplied by a "safety factor" (2-3) as a good estimate for the basic delay of the iSCSI stack for a given con- nection. "(2-3}" strikes me as low and providing little resilience to "stupid network tricks". I'd change that to something like "(e.g., 5x, with a minimum of several milliseconds)". This is complicated by the fact that both initiators and targets will likely want to insert delays (in the hope that something useful turns up that has to be sent) before sending a NOP to update the various acknowledgement counters (e.g., ExpCmdSN). [T.22] 9.1 iSCSI PDU Length and Padding iSCSI PDUs are padded to the closest integer number of four byte words. The padding bytes SHOULD be 0. "MUST be transmitted as zero and ignored by the receiver, except for calculation of the digest CRCs if present" would be better. Same comment applies to padding bytes for header segments. [T.23] 9.4.1 Flags (byte 1) Bits O and U and bits o and u are mutually exclusive. Need to put some teeth into that. Say that in each pair, it is a protocol error if both bits are set to 1, and refer to the section for handling that error. [T.24] 9.4.4 Residual Count and 9.4.5 Bidirectional Read Residual Count These should be treated as reserved when they're not valid (O and U are zero for Residual Count, o and u are zero for Bidi Read Residual Count) - MUST be set to zero by sender, MUST be ignored by receiver. [T.25] 9.5.2 LUN This field is required for functions that address a specific LU (ABORT TASK, CLEAR TASK SET, ABORT TASK SET, CLEAR ACA, LOGICAL UNIT RESET) and is reserved in all others. Should TASK REASSIGN be added to the list in parentheses? [T.26] 9.6 Task Management Function Response For the functions ABORT TASK, ABORT TASK SET, CLEAR ACA, CLEAR TASK SET, LOGICAL UNIT RESET, TARGET COLD RESET and TARGET WARM RESET, the target performs the requested Task Management function and sends a Task Management Response back to the initiator. TASK REASSIGN does not get a response. Was this intended? [T.27] 9.12.10 ExpStatSN This is ExpStatSN for the old connection. This field is valid only if the Login request restarts a connection (see Section 4.3.4 Connection reinstatement). This is for the Login Request PDU. For the initial Login Request PDU in a login phase, the description is correct, but thereafter, Login Request should be using ExpStatSN to acknowledge the Login Responses via their increasing StatSN values (see 9.13.4). This raises the related question of why StatSN/ ExpStatSN is being used during login while CmdSN/ExpCmdSN is not being used. [T.28] 9.14 Logout Request A successful completion of a logout request with the reason code of "close the connection" or "remove the connection for recovery" results in the discarding of all tasks waiting in the command reor- dering queue that are allegiant to the connection being logged out. "discarding" is not what hapapens in the "remove the connection for recovery case according to the following text from Section 6.5: b) Logout the connection for recovery and continue the tasks on a different connection instance as described in Section 6.1 Retry and Reassign in Recovery. [OR] A "discarded" task cannot be "continue"-d. I suspect the text should say that "close the connection" terminates the tasks, anad "remove the connection for recovery" suspends the tasks with the following CmdSN side effects ... [T.29] 9.14 Logout Request The entire logout discussion in this section is completely applica- ble also for an implicit Logout effected by way of a connection rein- statement or session reinstatement. The Logout reason codes for implicit Logout are specified as below: How are these codes used and why are they specified here? Logout Request is an explicit logout, not implicit. [T.30] 9.16 SNACK Request If the initiator MaxRecvDataSegmenTLength changed Data-In PDUs requested with RunLength 0 (meaning all PDUs after this number) may be different from the ones originally sent, in order to reflect changes in MaxRecvDataSegmentLength. Their DataSN starts with the requested number and is increased by 1 for each resent Data-In PDU. If DataSN numbers change and a SCSI-Reponse PDU was sent reflecting the DataSN before retransmission it MUST be resent to reflect the new numbers. This was discussed on the list, but there are still some problems here: (1) If the MaxRecvDataSegmentLength has changed, the only valid Data SNACK is BegRun=0, RunLength=0 (i.e., resend everything). Attempts to be more clever than this are an invitation to miscount Data-In PDUs and cause problems in the initiator. Targets MUST reject all other Data SNACK requests in this situation. (2) The new SCSI-Response PDU needs a new StatSN to avoid the initiator discarding it as a duplicate. Section 2.2.2.2 is silent on duplicate detection for StatSN, but discarding duplicates would be a reasonable thing for an initiator to do. (3) The initiator needs some way to know that a new response is coming, and specifically whether to expect one or two responses. If it only expects one and two show up, the initiator could reuse the Task Tag once all the data arrives causing a race in which the new response could incorrectly complete an unrelated command (unlikely, but potentially nasty). This suggests calling out the Data SNACK as having special behavior: - It may resegment Data-In PDUs to deal with MaxRecvDataSegmentLength. All other Data SNACK requests MUST NOT resegment. - It *always* generates a new SCSI Response due to the possibility of resegmentation. That's not a great solution, because if one ever sets in a Data SNACK, the resulting behavior change is dramatic and unexpected. This leads to the final proposal: - Specify a new SNACK type code (3) for Resegmenting Data SNACK. SNACK Data-In resegmentation is allowed only when this is used. If resegmentation would be necessary for a Data SNACK (type 1), that SNACK MUST be rejected. - Both BegRun and RunLength MUST be zero for a Resegmenting Data SNACK, and (unlike reserved fields) these MUST be checked by the receiver (target). - A new SCSI Response is always generated as a result of a Resegmenting Data-In SNACK, and it has its own StatSN number to deal with the fact that the number of Data-In PDUs may have changed, causing a change to the ExpDataSN value. This new response also needs to be marked to distinguish it from a response that may have been generated earlier (so the initiator knows to wait for the new response) - using a bit in the flags field for this seems wrong, so specifying a new Response code value (0x02 - see 9.4.3) seems like a reasonable way to accomplish this. - Data SNACK (type 1) now has consistent behavior - it MUST NOT resegment and MUST NOT generate a new SCSI response, ever. This approach also has the potentially useful property of making it easy to yank out the Resegmenting Data SNACK wart if we ever put restrictions on the interaction of MaxRecvDatasegmentLength and Data SNACKs (yes, that's a hint ... this has gotten messy enough that forbidding Data SNACKs when MaxRecvDataSegmentLength has changed needs to be considered as a possible alternative). This issue also affects some text in 9.16.3. [T.31] 9.16.1 Type An iSCSI target that does not support recovery within connection MAY reject the status SNACK with a Reject PDU. If the target supports recovery within connection, it MAY reject the SNACK after which it MUST issue an Asynchronous Message PDU with an iSCSI event that indi- cates "Request Logout". This should be conditioned on the operational ErrorRecoveryLevel of the session, not whether the target supports recovery within connection. [T.32] 10. iSCSI Security Keys and Authentication Methods Only the following keys can be used during the SecurityNegotiation stage of the Login Phase: [ ... snip ...] AuthMethod and all keys listed under AuthMethod along with all of their associated keys. In practice, this forbids vendor-unique authentication methhods, as they would have to define their own text keys (reusing keys for an existing AuthMethod is a *bad* idea). OTOH, Section 10.1 appears to allow vendor-unique authentication methods. The authentication methods that can be used (appear in the list-of- options) are either those listed in the following table or are ven- dor-unique methods: One of these two needs to change, and see also editorial comment [E.136] against the above text from Section 10. Forbidding vendor-unique authentication methods would enhance interoperability. [T.33] 10.5 Challenge Handshake Authentication Protocol (CHAP) For the Algorithm, as stated in [RFC1994], one value is required to be implemented: 5 (CHAP with MD5) To guarantee interoperability, initiators SHOULD always offer it as one of the proposed algorithms. Change that "SHOULD" to a "MUST". [T.34] 11.1 HeaderDigest and DataDigest Proprietary algorithms MAY also be negotiated for digests. Whenever a proprietary algorithm is negotiated, "None" or "CRC32C" should be listed as an option in order to guarantee interoperability. Change "negotiatiated" to "offered" and "should" to "MUST". [T.35] 11.4 TargetName and 11.5 InitiatorName The descriptions of these keys need to have restrictions on changing them added - changing a name after it's been used for initial authentication/ authorization can cause security problems. These restrictions may already exist in the prohibitions on re-negotiating keys, but need to be (re)stated here. [T.36] 11.6 TargetAlias and 11.7 InitiatorAlias Add text here or in Section 10 to say that these keys MUST NOT be used to make authentication, or authorization (including access control) decisions. [T.37] 11.12 ImmediateData If ImmediateData is set to No and InitialR2T is set to No, then the initiator MUST NOT send unsolicited immediate data, but MAY send one unsolicited burst of Data-OUT PDUs. If ImmediateData is set to Yes and InitialR2T is set to No, then the initiator MAY send unsolicited immediate data and/or one unsolicited burst of Data-OUT PDUs. Both of the above uses of "MAY" are problems - my recollection of this is that if InitialR2T=No and there is data to be sent that falls under the implicit Initial R2T, then it MUST be sent as unsolicited Data-Out PDUs. [T.38] 12. IANA Considerations The temporary (user) well-known port number for iSCSI connections assigned by IANA is 3260. Delete "temporary (user)" insert "TCP" before "port number" or add instructions for IANA to allocate a system port when this draft is approved to become an RFC - I think just sticking with 3260 is better. [T.39] 12. IANA Considerations If vendor additions of values to existing keys is to be allowed (e.g., AuthMethod, HeaderDigest, DataDigest) an IANA registry is needed for each set of values - see [T.32] and [T.34], or the reversed DNS convention needs to be extended from keys to values - the latter doesn't sound like a good idea. -- Editorial Global Editorial comment: Both the login (4) and error handling (6) sections feel like one of those old Adventure mazes of twisty little passages - all the details seem to be there, for the most part they're correct, but it's very hard to get the proverbial "big picture" of how everything fits together, in terms of how the various mechanisms work with each other and how they accomplish the overall functionality. Both of these could use overview sections describing how the functionality breaks down into the pieces described in the subsections and how they fit together. Swapping the order of Sections 5 and 6 would also be a good idea so that the discussion of Error Handling and Recovery comes before the state machine descriptions that contain a lot of the details of how errors are handled. For error handling, moving Section 6.13 to the front of Section 6 would help organize the Section better, and care should be taken to define or replace terms like "restart login" and "recovery R2T" that are currently used without definitions. Also the following two editorial comments recommend serious restructuring of a portion of the draft: [E.80] 5.1 Standard Connection State Diagrams I'm probably going to take grief for this comment because it's a lot of work, but I think this section would be significantly clearer if the state and transition descriptions were split into separate initiator and target portions, so the order of the subsections would be: - Initiator diagram - Initiator state descriptions - Initiator transition descriptions - Target diagram - Target state descriptions - Target transition descriptions I guess it's ok to leave the descriptions merged in Section 5.2. [E.81] 5.3 Session State Diagrams This should be restructured in a fashion similar to Section 5.1 (see [E.80]). If you made it this far, thanks for taking the time to read everything, --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 --------------------------------------------------- --=_alternative 00174B57C2256BEF_= Content-Type: text/html; charset="us-ascii"
Thanks for the careful reading. I will answer to your items as I get to them and list them and proposed resolution
in the usual place. You did not leave me to much time tough.

Julo


Black_David@emc.com
Sent by: owner-ips@ece.cmu.edu

07/07/2002 05:29 AM
Please respond to Black_David

       
        To:        ips@ece.cmu.edu
        cc:        
        Subject:        iSCSI: DLB's Last Call comments

       


I've spent the better part of 3 days reading -14, well, most of it -
I didn't check the state machines thoroughly, and my eyes glazed over
on the error handling pseudo-code, so I'll simply have to trust
that Mallikarjun and the other folks involved got that right.

This message contains my Technical comments and the editorial
comments that may involve significant work on the draft.  My entire
set of 140 editorial comments is headed to Julian under separate cover.

These comments are submitted as an individual for further discussion
- I am *not* wielding my WG co-chair authority to say that these
have to be done or else ... I can be talked out of many of these
by suitably coherent and convincing technical arguments to the
contrary.

Please DO NOT REPLY to this message - there's too much stuff in
here.  Please send a new message with a new subject line to discuss
specific comments below.

Thanks,
--David

-- Technical

[T.1] 2.2.2.2  Response/Status Numbering and Acknowledging

  A large absolute difference between StatSN and ExpStatSN may indi-
  cate a failed connection. Initiators undertake recovery actions if
  the difference is greater than an implementation defined constant
  that SHOULD NOT exceed 2**31-1.

That's a requirement, not a description.  It needs a "SHOULD" or a
"MUST" between "Initiators" and "undertake".

[T.2] 2.2.6.1  iSCSI Name Requirements

  The initiator MUST present both its iSCSI Initiator Name and the
  iSCSI Target Name to which it wishes to connect in the first login
  request of a new session or connection. The only exception is if a
  discovery session (see Section 2.3 iSCSI Session Types) is to be
  established; the iSCSI Initiator Name is still required, but the
  iSCSI Target Name may be ignored.

"may be ignored" or "omitted"?  Section 4.3 appears to indicate that
"omitted" is the correct word, making the correct wording "MAY be omitted".

[T.3] 2.2.6.1  iSCSI Name Requirements

  iSCSI names must adhere to the following requirements:

Use upper case "MUST" instead of "must".  Likewise for name encoding
requirements a) through d).

[T.4] 2.2.6.3.1  Type "iqn." (iSCSI Qualified Name)

    -  A date code, in yyyy-mm format.  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.

Oh dear, what happens if a domain name changes hands twice in the
same month???  One possible way out is to require that the naming
authority owned the domain name at 00:01 GMT on the first day of
the month.

[T.5] 2.8  Message Synchronization and Steering

Since the only mechanism in this class currently specified for iSCSI is
markers, this general architectural framework needs to be removed
(possibly to other drafts, as some of this material is probably
appropriate for an RDDP architecture draft).  This section needs to
be refocused on the marker mechanism that iSCSI describes, and include
a discussion of its use when an iSCSI header CRC check fails.  I'd
like to see something like one paragraph on what markers are/do,
a sentence or two on how they can be used to recover from an iSCSI
header CRC check failure, and at most one paragraph on how markers
can help steer iSCSI PDUs/payloads into preallocated/queued buffers.
The current 4+ pages devoted to 2.8 and its subsections is
excessive and an invitation to further problems down the line.

[T.6] 2.3  iSCSI Session Types

     b)  Discovery-session - a session opened only for target discov-
     ery; the target MAY accept only text requests with the SendTar-
     gets key and a logout request with reason "close the session".

Change "MAY" to "MUST", and say that other requests MUST be rejected.

[T.7] 2.4.1  iSCSI Architecture Model

    d)  Network Portal - a component of a Network Entity that has a
    TCP/IP network address and that may be used by an iSCSI Node
    within that Network Entity for the connection(s) within one of its
    iSCSI sessions. In an initiator, it is identified by its IP
    address. In a target, it is identified by its IP address and its
    listening TCP port.

Use of just an IP address to identify an entity such as this doesn't work
throuogh NAPTs (Network Address Port Translators).  This issue needs to be
explained at some point, although I don't think it affects protocol
operation.

[T.8] 2.4.1  iSCSI Architecture Model

     f)  Portals within a Portal Group are expected to have similar
     hardware characteristics, as SCSI port specific mode pages

     may affect all portals within a portal group. (See Section 2.4.3.2
     SCSI Mode Pages).

"similar hardware characteristics" needs to be explained/qualified,
as Section 2.4.3.2 does not contain an adequate explanation of what's
going on here and its hardware implications.

[T.9] 2.4.2  SCSI Architecture Model

     The SCSI Port Name is mandatory in iSCSI. When used in SCSI
     parameter data, the SCSI port name MUST be encoded as:
     - The iSCSI Name in UTF-8 format, followed by
     - a comma separator (1 byte), followed by
     - the ASCII character 'i' (for SCSI Initiator Port) or the
      ASCII character 't' (for SCSI Target Port), followed by
     - a comma separator (1 byte), followed by
     - zero to 3 null pad bytes so that the complete format is a
      multiple of four bytes long, followed by
     - the 6byte value of the ISID (for SCSI initiator port) or the
      2byte value of the portal group tag (for SCSI target port) in
      network byte order (BigEndian).

That's a peculiar format with padding nulls in the middle and
a number concatenated after the padding - for example, it can't
be passed in iSCSI login without format conversion.  How about
converting the number to 4 or 12 bytes of hex (ASCII characters)
and moving the padding to the end so the result is actually a
string, and excluding the padding from the definition of the name?
This will increase the maximum length of port names, but produce
names that are easier to deal with.

[T.10] 2.4.3.2  SCSI Mode Pages

  Changes via mode pages to the behavior of a portal group via one
  iSCSI Target Node should not affect the behavior of this portal group
  with respect to other iSCSI Target Nodes, even if the underlying
  implementation of a portal group serves multiple iSCSI Target Nodes
  in the same Network Entity.

I believe "should not" should be "SHOULD NOT".

[T.11] 4.1  Text Format

    decimal-constant: an unsigned decimal number - the digit 0 or a
      string of 1 or more digits starting with a non-zero digit.
      This encoding is not used for numerical values equal or
      greater than 2**64. Decimal-constants are used to encode
      numerical values or binary strings. When used to encode
      binary strings decimal constants have an implicit byte-length
      that is the minimum number of bytes needed to represent the
      base2 encoding of the decimal number.

The last sentence is the "decimal binary strings" issue that has been
discussed extensively on the list.  One example of the problem is that
the decimal number 15 represents the binary string 0xF, but not the
binary strings 0x0F or 0x000F, and the latter two are not representable
in the decimal format as currently defined.  If the difference between
these three matters (e.g., SRP's salt [s] parameter is one example
where this difference does matter) use of decimal format for binary
strings can cause things not to work.  Forbidding the use of
decimal representation for binary strings would be the simplest change.

[T.12] 4.1  Text Format

    large-numerical-value: an unsigned integer larger than or equal
      to 2**64 encoded as a hex constant, or base64-constant.
      Unsigned integer arithmetic applies to large-numeric-values.

I believe "larger than or equal to" should be changed to "whose value
may be larger than or equal to", as the current text forbids large
numerical values from representing values less than 2**64, which seems
wrong.

[T.13] 4.1  Text Format

  Any iSCSI target or initiator MUST support receiving at least 16384
  bytes of key=value data in a negotiation sequence except when indi-
  cating support for very long authentication items by offering or
  selecting authentication methods such as public key certificates in
  which case they MUST support receiving at least 64 kilobytes of
  key=value data.

This comment is classified as technical to catch the 16kB minimum as an
open issue.  The "such as" text needs to be cleaned up - the point should
be that the 64 kB minimum applies when a authentication method using long
authentication items is offered or accepted, and should be accompanied
by a specific list of authentication methods in this draft that carry
that implication.

[T.14] 4.2  Text Mode Negotiation

  During login, and thereafter, some session or connection parameters
  are either declared or negotiated through an exchange of textual
  information.

How does a declaration differ from a negotiation?  It isn't described in
this section, and doesn't seem to be mentioned in any of the subsequent
sections about login, until one gets to the text key definitions.

[T.15] 4.3.1  Login Phase Start

  The first Login Response PDU during the Login Phase from the iSCSI
  target SHOULD return the TargetPortalGroupTag key that contains the
  tag value of the iSCSI portal group servicing the Login Request PDU.
  If the iSCSI target implementation supports altering the portal group
  configuration (including adding, deleting, and swapping of portals in
  a portal group), it MUST return the TargetPortalGroupTag key carry-
  ing the tag value of the servicing portal group.

Let's make returning this key a MUST in all cases - less text, simpler
protocol, simpler code at the Initiator.

[T.16] 4.3.4  Connection reinstatement

  Targets should support opening a second connection even
  when they do not support multiple connections in Full Feature Phase.

Looks like that ought to be an upper case "SHOULD".  I think this needs
further discussion.  Section 5.2 appears to use a lower case "must"
for this:

  Whenever a connection state machine (e.g., CSM-C) enters the
  CLEANUP_WAIT state (S8), it must go through the state transitions
  additionally described in the connection cleanup state diagram either
  a) using a separate full-feature phase connection (let's call it CSM-
  E) in the LOGGED_IN state in the same session, or b) using a new
  transport connection (let's call it CSM-I) in the FREE state that is
  to be added to the same session.

Also, the implications of needing to spend resources (e.g., new transport
connection) to clean up resources need to be described somewhere -
in the worst case, resources for a new transport connection may need to
be reserved to avoid deadlock.  It doesn't look like there's a problem
with the transport (TCP) resources themselves, but this could be an
issue for iSCSI connection state resources (what happens if all
connections are in CLEANUP_WAIT and there's no iSCSI connection state
resource available to open a new transport connection?).  The answer
is likely to involve killing off a session, but I don't see an
obvious explanation of it.  Then I get to Section 5.2.2, which describes
a transition from CLEANUP_WAIT to FREE (M1) that can happen based on
a timeout, and presumably recovers the state resources and hence might
make this all work.  Whether an additional connection is needed to
deal with CLEANUP_WAIT and whether it's MUST/SHOULD/MAY needs to be
sorted out, and the various descriptions of it made consistent.

[T.17]  6.4  Format Errors

  The following two explicit violations of PDU layout rules are format
  errors:

       a)  illegal contents of the PDU header (except the Opcode) - for
       ex., out-of-range values for certain fields
       b)  inconsistent contents - for ex., value of one field conflicts
       with that of another.
   
  Format errors indicate a major implementation flaw in one of the par-
  ties.

The two "for ex."s aren't good enough.  Details on what is a format error
need
to be spelled out explicitly, given the drastic consequences of committing
one.

[T.18] 6.7  SCSI Timeouts

  On a ULP timeout for a command (that carried a CmdSN of n), the iSCSI
  initiator MUST abort the command by either using the Abort Task task
  management function request, or a "close the connection" Logout if it
  intends to continue the session.

I think the first part is over specified - there are a number of task
management
commands that abort the task - if the target is really sick, something much
more serious than Abort Task may be used that not only aborts this task,
but others.  It's not clear whether "if it intends to continue the session"
applies only to the logout or to both the task management command and the
logout, nor is it clear what an initiator should do if it doesn't intend to
continue the session.

[T.19] 8.1.1  Conservative Reuse of ISIDs

  To both minimize the disruption of legacy applications and to better
   facilitate the SCSI features that rely on persistent names for SCSI
  ports, iSCSI implementations should attempt to provide a stable pre-
  sentation of SCSI Initiator Ports

That's a requirement - change "should" to "SHOULD".  This is a technical
comment to (re)open the issue of whether conservative reuse ought to be
a "MUST" - T10 is defining persistent reservation functionality that will
not behave as one might expect in the absence of conservative reuse - at
the very least, this consequence of ignoring the SHOULD needs to be stated.

[T.20] 8.2  Autosense and Auto Contingent Allegiance (ACA)

  Autosense refers to the automatic return of sense data to the initia-
  tor in case a command did not complete successfully. iSCSI initia-
  tors and targets MUST support autosense.

"MUST support" --> "MUST support and use", as this is not just "MUST
implement".

[T.21] 8.3  iSCSI timeouts

  iSCSI recovery actions are often dependent on iSCSI time-outs being
  recognized and acted upon before SCSI time-outs. Determining the
  right time-outs to use for various iSCSI actions (command acknowl-
  edgements expected, status acknowledgements, etc.) is very much
  dependent on infrastructure (hardware, links, TCP/IP stack, iSCSI
  driver). As a guidance the implementer may use an average Nop-Out/
  Nop-In turnaround delay multiplied by a "safety factor" (2-3) as a
  good estimate for the basic delay of the iSCSI stack for a given con-
  nection.

"(2-3}" strikes me as low and providing little resilience to "stupid
network tricks".  I'd change that to something like "(e.g., 5x, with a
minimum of several milliseconds)".  This is complicated by the fact that
both initiators and targets will likely want to insert delays (in the
hope that something useful turns up that has to be sent) before sending
a NOP to update the various acknowledgement counters (e.g., ExpCmdSN).

[T.22] 9.1  iSCSI PDU Length and Padding

  iSCSI PDUs are padded to the closest integer number of four byte
  words. The padding bytes SHOULD be 0.

"MUST be transmitted as zero and ignored by the receiver, except for
calculation of the digest CRCs if present" would be better.
Same comment applies to padding bytes for header segments.

[T.23] 9.4.1  Flags (byte 1)

  Bits O and U and bits o and u are mutually exclusive.

Need to put some teeth into that.  Say that in each pair, it is a protocol
error if both bits are set to 1, and refer to the section for handling that
error.

[T.24] 9.4.4  Residual Count and 9.4.5  Bidirectional Read Residual Count

These should be treated as reserved when they're not valid (O and U are zero
for Residual Count, o and u are zero for Bidi Read Residual Count) - MUST
be set to zero by sender, MUST be ignored by receiver.

[T.25] 9.5.2  LUN

  This field is required for functions that address a specific LU
  (ABORT TASK, CLEAR TASK SET, ABORT TASK SET, CLEAR ACA, LOGICAL UNIT
  RESET) and is reserved in all others.

Should TASK REASSIGN be added to the list in parentheses?

[T.26] 9.6  Task Management Function Response

  For the functions ABORT TASK, ABORT TASK SET, CLEAR ACA, CLEAR TASK
  SET, LOGICAL UNIT RESET, TARGET COLD RESET and TARGET WARM RESET, the
  target performs the requested Task Management function and sends a
  Task Management Response back to the initiator.

TASK REASSIGN does not get a response.  Was this intended?

[T.27] 9.12.10  ExpStatSN

  This is ExpStatSN for the old connection.

  This field is valid only if the Login request restarts a connection
  (see Section 4.3.4 Connection reinstatement).

This is for the Login Request PDU.  For the initial Login Request PDU in a
login
phase, the description is correct, but thereafter, Login Request should be
using ExpStatSN to acknowledge the Login Responses via their increasing
StatSN values (see 9.13.4).  This raises the related question of why StatSN/
ExpStatSN is being used during login while CmdSN/ExpCmdSN is not being used.

[T.28] 9.14 Logout Request

 A successful completion of a logout request with the reason code of
 "close the connection" or "remove the connection for recovery"
 results in the discarding of all tasks waiting in the command reor-
 dering queue that are allegiant to the connection being logged out.

"discarding" is not what hapapens in the "remove the connection for recovery
case according to the following text from Section 6.5:

     b)  Logout the connection for recovery and continue the tasks on a
     different connection instance as described in Section 6.1 Retry
     and Reassign in Recovery. [OR]

A "discarded" task cannot be "continue"-d.  I suspect the text should say
that "close the connection" terminates the tasks, anad "remove the
connection
for recovery" suspends the tasks with the following CmdSN side effects ...

[T.29] 9.14 Logout Request

 The entire logout discussion in this section is completely applica-
 ble also for an implicit Logout effected by way of a connection rein-
 statement or session reinstatement.  The Logout reason codes for
 implicit Logout are specified as below:

How are these codes used and why are they specified here?  Logout Request
is an explicit logout, not implicit.

[T.30] 9.16   SNACK Request

  If the initiator MaxRecvDataSegmenTLength changed Data-In PDUs
  requested with RunLength 0 (meaning all PDUs after this number) may
  be different from the ones originally sent, in order to reflect
  changes in MaxRecvDataSegmentLength. Their DataSN starts with the
  requested number and is increased by 1 for each resent Data-In PDU.
  If DataSN numbers change and a SCSI-Reponse PDU was sent reflecting
  the DataSN before retransmission it MUST be resent to reflect the new
  numbers.

This was discussed on the list, but there are still some problems here:
(1) If the MaxRecvDataSegmentLength has changed, the only valid Data
                SNACK is BegRun=0, RunLength=0 (i.e., resend everything).  Attempts
                to be more clever than this are an invitation to miscount Data-In
                PDUs and cause problems in the initiator.  Targets MUST reject
                all other Data SNACK requests in this situation.
(2) The new SCSI-Response PDU needs a new StatSN to avoid the initiator
                discarding it as a duplicate.  Section 2.2.2.2 is silent on
duplicate
                detection for StatSN, but discarding duplicates would be a
reasonable
                thing for an initiator to do.
(3) The initiator needs some way to know that a new response is coming,
                and specifically whether to expect one or two responses.  If it
                only expects one and two show up, the initiator could reuse the
                Task Tag once all the data arrives causing a race in which the
                new response could incorrectly complete an unrelated command
                (unlikely, but potentially nasty).
This suggests calling out the <BegRun=0, RunLength=0> Data SNACK as having
special behavior:
                - It may resegment Data-In PDUs to deal with
MaxRecvDataSegmentLength.
                                 All other Data SNACK requests MUST NOT resegment.
                - It *always* generates a new SCSI Response due to the possibility
                                 of resegmentation.
That's not a great solution, because if one ever sets <BegRun=0,
RunLength=0>
in a Data SNACK, the resulting behavior change is dramatic and unexpected.
This leads to the final proposal:
                - Specify a new SNACK type code (3) for Resegmenting Data SNACK.
SNACK
                                 Data-In resegmentation is allowed only when this is used.
If
                                 resegmentation would be necessary for a Data SNACK (type 1),
                                 that SNACK MUST be rejected.
                - Both BegRun and RunLength MUST be zero for a Resegmenting Data
                                 SNACK, and (unlike reserved fields) these MUST be checked by
                                 the receiver (target).
                - A new SCSI Response is always generated as a result of a
Resegmenting
                                 Data-In SNACK, and it has its own StatSN number to deal with
the
                                 fact that the number of Data-In PDUs may have changed,
causing
                                 a change to the ExpDataSN value.  This new response also
needs
                                 to be marked to distinguish it from a response that may have
                                 been generated earlier (so the initiator knows to wait for
the
                                 new response) - using a bit in the flags field for this
seems
                                 wrong, so specifying a new Response code value (0x02 - see
9.4.3)
                                 seems like a reasonable way to accomplish this.
                - Data SNACK (type 1) now has consistent behavior - it MUST NOT
resegment
                                 and MUST NOT generate a new SCSI response, ever.
This approach also has the potentially useful property of making it easy
to yank out the Resegmenting Data SNACK wart if we ever put restrictions
on the interaction of MaxRecvDatasegmentLength and Data SNACKs (yes, that's
a hint ... this has gotten messy enough that forbidding Data SNACKs when
MaxRecvDataSegmentLength has changed needs to be considered as a possible
alternative).

This issue also affects some text in 9.16.3.

[T.31] 9.16.1  Type

  An iSCSI target that does not support recovery within connection MAY
  reject the status SNACK with a Reject PDU. If the target supports
  recovery within connection, it MAY reject the SNACK after which it
  MUST issue an Asynchronous Message PDU with an iSCSI event that indi-
  cates "Request Logout".

This should be conditioned on the operational ErrorRecoveryLevel of the
session, not whether the target supports recovery within connection.

[T.32] 10. iSCSI Security Keys and Authentication Methods

  Only the following keys can be used during the SecurityNegotiation
  stage of the Login Phase:

    [ ... snip ...]

    AuthMethod and all keys listed under AuthMethod along with all
      of their associated keys.

In practice, this forbids vendor-unique authentication methhods, as they
would have to define their own text keys (reusing keys for an existing
AuthMethod is a *bad* idea).  OTOH, Section 10.1 appears to allow
vendor-unique authentication methods.

  The authentication methods that can be used (appear in the list-of-
  options) are either those listed in the following table or are ven-
  dor-unique methods:

One of these two needs to change, and see also editorial comment [E.136]
against the above text from Section 10.  Forbidding vendor-unique
authentication methods would enhance interoperability.

[T.33] 10.5  Challenge Handshake Authentication Protocol (CHAP)

  For the Algorithm, as stated in [RFC1994], one value is required
  to be implemented:

      5       (CHAP with MD5)

  To guarantee interoperability, initiators SHOULD always offer it as
  one of the proposed algorithms.

Change that "SHOULD" to a "MUST".

[T.34] 11.1  HeaderDigest and DataDigest

  Proprietary algorithms MAY also be negotiated for digests. Whenever a
  proprietary algorithm is negotiated, "None" or "CRC32C" should be
  listed as an option in order to guarantee interoperability.

Change "negotiatiated" to "offered" and "should" to "MUST".

[T.35] 11.4 TargetName and 11.5 InitiatorName

The descriptions of these keys need to have restrictions on changing them
added - changing a name after it's been used for initial authentication/
authorization can cause security problems.  These restrictions may already
exist in the prohibitions on re-negotiating keys, but need to be (re)stated
here.

[T.36] 11.6  TargetAlias  and 11.7 InitiatorAlias

Add text here or in Section 10 to say that these keys MUST NOT be used to
make authentication, or authorization (including access control) decisions.

[T.37] 11.12  ImmediateData

  If ImmediateData is set to No and InitialR2T is set to No, then the
  initiator MUST NOT send unsolicited immediate data, but MAY send one
  unsolicited burst of Data-OUT PDUs.

  If ImmediateData is set to Yes and InitialR2T is set to No, then the
  initiator MAY send unsolicited immediate data and/or one unsolicited
  burst of Data-OUT PDUs.

Both of the above uses of "MAY" are problems - my recollection of this
is that if InitialR2T=No and there is data to be sent that falls under
the implicit Initial R2T, then it MUST be sent as unsolicited Data-Out PDUs.

[T.38] 12. IANA Considerations

  The temporary (user) well-known port number for iSCSI connections
  assigned by IANA is 3260.

Delete "temporary (user)" insert "TCP" before "port number" or add
instructions for IANA to allocate a system port when this draft is
approved to become an RFC - I think just sticking with 3260 is better.

[T.39] 12. IANA Considerations

If vendor additions of values to existing keys is to be allowed
(e.g., AuthMethod, HeaderDigest, DataDigest) an IANA registry is needed
for each set of values - see [T.32] and [T.34], or the reversed DNS
convention needs to be extended from keys to values - the latter doesn't
sound like a good idea.

-- Editorial

Global Editorial comment: Both the login (4) and error handling (6) sections
feel like one of those old Adventure mazes of twisty little passages - all
the
details seem to be there, for the most part they're correct, but it's very
hard
to get the proverbial "big picture" of how everything fits together, in
terms
of how the various mechanisms work with each other and how they accomplish
the overall functionality.  Both of these could use overview sections
describing
how the functionality breaks down into the pieces described in the
subsections
and how they fit together.  Swapping the order of Sections 5 and 6 would
also
be a good idea so that the discussion of Error Handling and Recovery comes
before the state machine descriptions that contain a lot of the details of
how errors are handled.  For error handling, moving Section 6.13 to the
front of Section 6 would help organize the Section better, and care should
be
taken to define or replace terms like "restart login" and "recovery R2T"
that are currently used without definitions.

Also the following two editorial comments recommend serious restructuring of
a portion of the draft:

[E.80] 5.1  Standard Connection State Diagrams

I'm probably going to take grief for this comment because it's a lot of
work,
but I think this section would be significantly clearer if the state and
transition descriptions were split into separate initiator and target
portions, so the order of the subsections would be:
- Initiator diagram
- Initiator state descriptions
- Initiator transition descriptions
- Target diagram
- Target state descriptions
- Target transition descriptions
I guess it's ok to leave the descriptions merged in Section 5.2.

[E.81] 5.3  Session State Diagrams

This should be restructured in a fashion similar to Section 5.1 (see
[E.80]).

If you made it this far, thanks for taking the time to read
everything,  --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
---------------------------------------------------

--=_alternative 00174B57C2256BEF_=-- From owner-ips@ece.cmu.edu Sun Jul 7 01:30:31 2002 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA07043 for ; Sun, 7 Jul 2002 01:30:31 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id g674nX826528 for ips-outgoing; Sun, 7 Jul 2002 00:49:33 -0400 (EDT) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from d12lmsgate-3.de.ibm.com (d12lmsgate-3.de.ibm.com [195.212.91.201]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id g674nUX26516; Sun, 7 Jul 2002 00:49:30 -0400 (EDT) Received: from d12relay01.de.ibm.com (d12relay01.de.ibm.com [9.165.215.22]) by d12lmsgate-3.de.ibm.com (8.12.3/8.12.3) with ESMTP id g674nL2F036708; Sun, 7 Jul 2002 06:49:21 +0200 Received: from d10hubm1.telaviv.ibm.com (d10ml001.telaviv.ibm.com [9.148.216.55]) by d12relay01.de.ibm.com (8.11.1m3/NCO/VER6.2) with ESMTP id g674nJQ122754; Sun, 7 Jul 2002 06:49:20 +0200 To: pat_thaler@agilent.com Cc: ips@ece.cmu.edu, owner-ips@ece.cmu.edu MIME-Version: 1.0 Subject: RE: iSCSI: Decimal encoding - why 64 bits ? X-Mailer: Lotus Notes Release 5.0.9 November 16, 2001 From: "Julian Satran" Message-ID: Date: Sun, 7 Jul 2002 07:49:15 +0300 X-MIMETrack: Serialize by Router on D10ML001/10/M/IBM(Release 5.0.9a |January 7, 2002) at 07/07/2002 07:49:20, Serialize complete at 07/07/2002 07:49:20 Content-Type: multipart/alternative; boundary="=_alternative 00169178C2256BEF_=" Sender: owner-ips@ece.cmu.edu Precedence: bulk This is a multipart message in MIME format. --=_alternative 00169178C2256BEF_= Content-Type: text/plain; charset="us-ascii" That is not completely correct. Port numbers are 16 bit binary strings. TPGT are 16 bit strings. Over 100 FCs use decimal encoding for binary fields. I addition once you have the decimal-to-binary conversion it makes to sense to forbid it. Elizabeth is correct we should not do what Pat suggests. Julo pat_thaler@agilent.com Sent by: owner-ips@ece.cmu.edu 07/07/2002 05:22 AM Please respond to pat_thaler To: cc: ips@ece.cmu.edu Subject: RE: iSCSI: Decimal encoding - why 64 bits ? Elizabeth, None of the examples given use the binary-value value type defined in 4.1. To iSCSI they are all text-values. The issue a number of us have is with binary value (where iSCSI has to convert the value to binary). The only place binary-value is used is in the SRP and CHAP keys. There are at least three ways to address this (in order of my preference, highest first): 1. Change the binary value definition to the current definition for large-binary-value, delete large-binary-value and regular-binary-value from the text formats and change occurrences of large-binary-value to binary-value. 2. Change the upper limit on regular-binary-value to 32 bits. 3. Change SRP and CHAP keys to use large-binary-value. Regards, Pat -----Original Message----- From: Elizabeth G. Rodriguez [mailto:Elizabeth.G.Rodriguez@123mail.net] Sent: Saturday, July 06, 2002 8:31 AM To: 'Julian Satran (Actcom)'; 'Robert Snively'; 'Martins Krikis'; Black_David@emc.com Cc: ips@ece.cmu.edu Subject: RE: iSCSI: Decimal encoding - why 64 bits ? Given these examples, I believe that restricting decimal encoded binary strings is not an option. Elizabeth Rodriguez -----Original Message----- From: owner-ips@ece.cmu.edu [mailto:owner-ips@ece.cmu.edu] On Behalf Of Julian Satran (Actcom) Sent: Saturday, July 06, 2002 1:25 AM To: Robert Snively; 'Martins Krikis'; Black_David@emc.com Cc: ips@ece.cmu.edu Subject: Re: iSCSI: Decimal encoding - why 64 bits ? You may want to add to the list port-numbers, domain specific name formats (yes some domains mainly phone systems use decimal encodings). A search for decimal encoded binary strings in the RFC domain gave well over one-hundred results. Julo ----- Original Message ----- From: "Robert Snively" To: "'Martins Krikis'" ; "Julian Satran (Actcom)" ; Cc: Sent: Saturday, July 06, 2002 2:37 AM Subject: RE: iSCSI: Decimal encoding - why 64 bits ? > The most common example would probably be the > IP address, which is a binary value. > It is often presented > as four separate decimal numbers for no reason > I can think of, except perhaps a feeling that > hexadecimal numbers were somehow less user > friendly for inexperienced users. > > See RFC 0790 and RFC 0791. > > Bob > > > -----Original Message----- > > From: Martins Krikis [mailto:mkrikis@yahoo.com] > > Sent: Friday, July 05, 2002 7:42 AM > > To: Julian Satran (Actcom); Black_David@emc.com > > Cc: ips@ece.cmu.edu > > Subject: Re: iSCSI: Decimal encoding - why 64 bits ? > > > > > > > > --- "Julian Satran (Actcom)" > > wrote: > > > Martins - you have a very good point - and we > > > considered briefly to forbid > > > decimal from the outset but many of the team felt > > > that this would be a bad > > > idea as values get copied from a context to another. > > > And the we looked at > > > coding for other RFCs and we found decimal > > > everywhere - addresses, > > > identifiers, ports etc., and thought it would be a > > > bad idea to forbid them > > > in iSCSI > > > > Julian, > > > > I cannot find a single post on this mailing list > > saying that forbidding decimal encoding for binary > > items would be a bad idea. I did find several (and > > quoted 4) that actually recommended dropping decimal > > encoding for binary items. Lately there have been > > many more such posts. All those other RFCs, I > > suspect, are actually dealing with numbers. I have > > no objections to using decimal encoding for numbers > > (that is things, that normally fit in your > > machine's registers and are treated as numerical, > > not as bit-strings). You have yet to provide an > > example of something that is clearly a binary > > string (and not used as a number) and is being > > commonly encoded in decimal. If you find such a > > thing, can you tell us what's the scheme for telling > > how many null-bytes this binary string starts with? > > > > Martins Krikis, Intel Corp. > > > > Disclaimer: these opinions are mine and may not > > be those of my employer. > > > > > > __________________________________________________ > > Do You Yahoo!? > > Sign up for SBC Yahoo! Dial - First Month Free > > http://sbc.yahoo.com > > --=_alternative 00169178C2256BEF_= Content-Type: text/html; charset="us-ascii"
That is not completely correct. Port numbers are 16 bit binary strings. TPGT are 16 bit strings.
Over 100 FCs use decimal encoding for binary fields.
I addition once you have the decimal-to-binary conversion it makes to sense to forbid it.
Elizabeth is correct we should not do what Pat suggests.

Julo


pat_thaler@agilent.com
Sent by: owner-ips@ece.cmu.edu

07/07/2002 05:22 AM
Please respond to pat_thaler

       
        To:        
        cc:        ips@ece.cmu.edu
        Subject:        RE: iSCSI: Decimal encoding - why 64 bits ?

       


Elizabeth,

None of the examples given use the binary-value value type defined in 4.1. To iSCSI they are all text-values. The issue a number of us have is with binary value (where iSCSI has to convert the value to binary). The only place binary-value is used is in the SRP and CHAP keys. There are at least three ways to address this (in order of my preference, highest first):

1. Change the binary value definition to the current definition for large-binary-value, delete large-binary-value and regular-binary-value from the text formats and change occurrences of large-binary-value to binary-value.

2. Change the upper limit on regular-binary-value to 32 bits.

3. Change SRP and CHAP keys to use large-binary-value.

Regards,
Pat

-----Original Message-----
From: Elizabeth G. Rodriguez [mailto:Elizabeth.G.Rodriguez@123mail.net]
Sent: Saturday, July 06, 2002 8:31 AM
To: 'Julian Satran (Actcom)'; 'Robert Snively'; 'Martins Krikis';
Black_David@emc.com
Cc: ips@ece.cmu.edu
Subject: RE: iSCSI: Decimal encoding - why 64 bits ?


Given these examples, I believe that restricting decimal encoded binary
strings is not an option.

Elizabeth Rodriguez

-----Original Message-----
From: owner-ips@ece.cmu.edu [mailto:owner-ips@ece.cmu.edu] On Behalf Of
Julian Satran (Actcom)
Sent: Saturday, July 06, 2002 1:25 AM
To: Robert Snively; 'Martins Krikis'; Black_David@emc.com
Cc: ips@ece.cmu.edu
Subject: Re: iSCSI: Decimal encoding - why 64 bits ?

You may want to add to the list port-numbers, domain specific name
formats
(yes some domains mainly phone systems use decimal encodings).

A search for decimal encoded binary strings in the RFC domain gave well
over
one-hundred results.

Julo
----- Original Message -----
From: "Robert Snively" <rsnively@brocade.com>
To: "'Martins Krikis'" <mkrikis@yahoo.com>; "Julian Satran (Actcom)"
<Julian_Satran@actcom.net.il>; <Black_David@emc.com>
Cc: <ips@ece.cmu.edu>
Sent: Saturday, July 06, 2002 2:37 AM
Subject: RE: iSCSI: Decimal encoding - why 64 bits ?


> The most common example would probably be the
> IP address, which is a binary value.
> It is often presented
> as four separate decimal numbers for no reason
> I can think of, except perhaps a feeling that
> hexadecimal numbers were somehow less user
> friendly for inexperienced users.
>
> See RFC 0790 and RFC 0791.
>
> Bob
>
> > -----Original Message-----
> > From: Martins Krikis [mailto:mkrikis@yahoo.com]
> > Sent: Friday, July 05, 2002 7:42 AM
> > To: Julian Satran (Actcom); Black_David@emc.com
> > Cc: ips@ece.cmu.edu
> > Subject: Re: iSCSI: Decimal encoding - why 64 bits ?
> >
> >
> >
> > --- "Julian Satran (Actcom)"
> > <Julian_Satran@actcom.net.il> wrote:
> > > Martins - you have a very good point - and we
> > > considered briefly to forbid
> > > decimal from the outset but many of the team felt
> > > that this  would be a bad
> > > idea as values get copied from a context to another.
> > > And the we looked at
> > > coding for other RFCs and we found decimal
> > > everywhere - addresses,
> > > identifiers, ports etc., and thought it would be a
> > > bad idea to forbid them
> > > in iSCSI
> >
> > Julian,
> >
> > I cannot find a single post on this mailing list
> > saying that forbidding decimal encoding for binary
> > items would be a bad idea. I did find several (and
> > quoted 4) that actually recommended dropping decimal
> > encoding for binary items. Lately there have been
> > many more such posts. All those other RFCs, I
> > suspect, are actually dealing with numbers. I have
> > no objections to using decimal encoding for numbers
> > (that is things, that normally fit in your
> > machine's registers and are treated as numerical,
> > not as bit-strings). You have yet to provide an
> > example of something that is clearly a binary
> > string (and not used as a number) and is being
> > commonly encoded in decimal. If you find such a
> > thing, can you tell us what's the scheme for telling
> > how many null-bytes this binary string starts with?
> >
> > Martins Krikis, Intel Corp.
> >
> > Disclaimer: these opinions are mine and may not
> >              be those of my employer.
> >
> >
> > __________________________________________________
> > Do You Yahoo!?
> > Sign up for SBC Yahoo! Dial - First Month Free
> > http://sbc.yahoo.com
> >

--=_alternative 00169178C2256BEF_=-- From owner-ips@ece.cmu.edu Sun Jul 7 04:11:45 2002 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA17391 for ; Sun, 7 Jul 2002 04:11:45 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id g677WkM00773 for ips-outgoing; Sun, 7 Jul 2002 03:32:46 -0400 (EDT) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from e2.ny.us.ibm.com (e2.ny.us.ibm.com [32.97.182.102]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id g677WjX00769 for ; Sun, 7 Jul 2002 03:32:45 -0400 (EDT) Received: from northrelay01.pok.ibm.com (northrelay01.pok.ibm.com [9.56.224.149]) by e2.ny.us.ibm.com (8.12.2/8.12.2) with ESMTP id g677Wee8063540; Sun, 7 Jul 2002 03:32:40 -0400 Received: from d03nm014.boulder.ibm.com (avpilot.boulder.ibm.com [9.17.203.135]) by northrelay01.pok.ibm.com (8.11.1m3/NCO/VER6.1) with ESMTP id g677WcF90502; Sun, 7 Jul 2002 03:32:38 -0400 X-Priority: 1 (High) Importance: Normal Subject: Re: iSCSI: DLB's Last Call comments To: Black_David@emc.com Cc: ips@ece.cmu.edu X-Mailer: Lotus Notes Release 5.0.7 March 21, 2001 Message-ID: From: "John Hufferd" Date: Sun, 7 Jul 2002 00:30:04 -0700 X-MIMETrack: Serialize by Router on D03NM014/03/M/IBM(Release 5.0.10 |March 22, 2002) at 07/07/2002 01:32:39 AM MIME-Version: 1.0 Content-type: text/plain; charset=us-ascii Sender: owner-ips@ece.cmu.edu Precedence: bulk David, I think you have the issue in T9 wrong. That format is not passed in any iSCSI interchange. It is part of SCSI parameter data. The item numbered T15, had a lot of discussions, especially in the Naming and Discovery Team, and the current wordage was the results of a compromise, where a number of vendors did not have the issue, and strongly felt that it would be the wrong thing to do with their product. So we agreed that the SHOULD section would be the right answer for every one. I also disagree with your item T17. I think those examples are all that is needed, since there are an infinite number of ways for someone to screw up. Much of the document, is spent stating what MUST, SHOULD, SHOULD NOT be done, repeating those at this point would not be useful. I do not follow your issue with T18. Time outs can occur for reason that are not something that needs more drastic action. If fact I would assume that it generally does not need other actions. In T33, I think we should leave the capability of vendor specific authentication methods, so that vendors can do their own thing. These are by definition not interoperable, they are intended to be that way. I disagree with the editorial rewrite, especially at this late state. If they were important that should have been brought up earlier. We should not be discussing editorial style, but whether we have correctly specified the protocol. We have already changed it a couple of times, and you are now wanting it changed again. This is a very big spec, and each time we make changes to pretty up the document, the more that is needed, and someone else has another preference. It is already better then most of the other IETF specs. I think this causes a needless delay. . . . John L. Hufferd Senior Technical Staff Member (STSM) IBM/SSG San Jose Ca Main Office (408) 256-0403, Tie: 276-0403, eFax: (408) 904-4688 Home Office (408) 997-6136, Cell: (408) 499-9702 Internet address: hufferd@us.ibm.com Black_David@emc.com@ece.cmu.edu on 07/06/2002 07:29:23 PM Sent by: owner-ips@ece.cmu.edu To: ips@ece.cmu.edu cc: Subject: iSCSI: DLB's Last Call comments I've spent the better part of 3 days reading -14, well, most of it - I didn't check the state machines thoroughly, and my eyes glazed over on the error handling pseudo-code, so I'll simply have to trust that Mallikarjun and the other folks involved got that right. This message contains my Technical comments and the editorial comments that may involve significant work on the draft. My entire set of 140 editorial comments is headed to Julian under separate cover. These comments are submitted as an individual for further discussion - I am *not* wielding my WG co-chair authority to say that these have to be done or else ... I can be talked out of many of these by suitably coherent and convincing technical arguments to the contrary. Please DO NOT REPLY to this message - there's too much stuff in here. Please send a new message with a new subject line to discuss specific comments below. Thanks, --David -- Technical [T.1] 2.2.2.2 Response/Status Numbering and Acknowledging A large absolute difference between StatSN and ExpStatSN may indi- cate a failed connection. Initiators undertake recovery actions if the difference is greater than an implementation defined constant that SHOULD NOT exceed 2**31-1. That's a requirement, not a description. It needs a "SHOULD" or a "MUST" between "Initiators" and "undertake". [T.2] 2.2.6.1 iSCSI Name Requirements The initiator MUST present both its iSCSI Initiator Name and the iSCSI Target Name to which it wishes to connect in the first login request of a new session or connection. The only exception is if a discovery session (see Section 2.3 iSCSI Session Types) is to be established; the iSCSI Initiator Name is still required, but the iSCSI Target Name may be ignored. "may be ignored" or "omitted"? Section 4.3 appears to indicate that "omitted" is the correct word, making the correct wording "MAY be omitted". [T.3] 2.2.6.1 iSCSI Name Requirements iSCSI names must adhere to the following requirements: Use upper case "MUST" instead of "must". Likewise for name encoding requirements a) through d). [T.4] 2.2.6.3.1 Type "iqn." (iSCSI Qualified Name) - A date code, in yyyy-mm format. 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. Oh dear, what happens if a domain name changes hands twice in the same month??? One possible way out is to require that the naming authority owned the domain name at 00:01 GMT on the first day of the month. [T.5] 2.8 Message Synchronization and Steering Since the only mechanism in this class currently specified for iSCSI is markers, this general architectural framework needs to be removed (possibly to other drafts, as some of this material is probably appropriate for an RDDP architecture draft). This section needs to be refocused on the marker mechanism that iSCSI describes, and include a discussion of its use when an iSCSI header CRC check fails. I'd like to see something like one paragraph on what markers are/do, a sentence or two on how they can be used to recover from an iSCSI header CRC check failure, and at most one paragraph on how markers can help steer iSCSI PDUs/payloads into preallocated/queued buffers. The current 4+ pages devoted to 2.8 and its subsections is excessive and an invitation to further problems down the line. [T.6] 2.3 iSCSI Session Types b) Discovery-session - a session opened only for target discov- ery; the target MAY accept only text requests with the SendTar- gets key and a logout request with reason "close the session". Change "MAY" to "MUST", and say that other requests MUST be rejected. [T.7] 2.4.1 iSCSI Architecture Model d) Network Portal - a component of a Network Entity that has a TCP/IP network address and that may be used by an iSCSI Node within that Network Entity for the connection(s) within one of its iSCSI sessions. In an initiator, it is identified by its IP address. In a target, it is identified by its IP address and its listening TCP port. Use of just an IP address to identify an entity such as this doesn't work throuogh NAPTs (Network Address Port Translators). This issue needs to be explained at some point, although I don't think it affects protocol operation. [T.8] 2.4.1 iSCSI Architecture Model f) Portals within a Portal Group are expected to have similar hardware characteristics, as SCSI port specific mode pages may affect all portals within a portal group. (See Section 2.4.3.2 SCSI Mode Pages). "similar hardware characteristics" needs to be explained/qualified, as Section 2.4.3.2 does not contain an adequate explanation of what's going on here and its hardware implications. [T.9] 2.4.2 SCSI Architecture Model The SCSI Port Name is mandatory in iSCSI. When used in SCSI parameter data, the SCSI port name MUST be encoded as: - The iSCSI Name in UTF-8 format, followed by - a comma separator (1 byte), followed by - the ASCII character 'i' (for SCSI Initiator Port) or the ASCII character 't' (for SCSI Target Port), followed by - a comma separator (1 byte), followed by - zero to 3 null pad bytes so that the complete format is a multiple of four bytes long, followed by - the 6byte value of the ISID (for SCSI initiator port) or the 2byte value of the portal group tag (for SCSI target port) in network byte order (BigEndian). That's a peculiar format with padding nulls in the middle and a number concatenated after the padding - for example, it can't be passed in iSCSI login without format conversion. How about converting the number to 4 or 12 bytes of hex (ASCII characters) and moving the padding to the end so the result is actually a string, and excluding the padding from the definition of the name? This will increase the maximum length of port names, but produce names that are easier to deal with. [T.10] 2.4.3.2 SCSI Mode Pages Changes via mode pages to the behavior of a portal group via one iSCSI Target Node should not affect the behavior of this portal group with respect to other iSCSI Target Nodes, even if the underlying implementation of a portal group serves multiple iSCSI Target Nodes in the same Network Entity. I believe "should not" should be "SHOULD NOT". [T.11] 4.1 Text Format decimal-constant: an unsigned decimal number - the digit 0 or a string of 1 or more digits starting with a non-zero digit. This encoding is not used for numerical values equal or greater than 2**64. Decimal-constants are used to encode numerical values or binary strings. When used to encode binary strings decimal constants have an implicit byte-length that is the minimum number of bytes needed to represent the base2 encoding of the decimal number. The last sentence is the "decimal binary strings" issue that has been discussed extensively on the list. One example of the problem is that the decimal number 15 represents the binary string 0xF, but not the binary strings 0x0F or 0x000F, and the latter two are not representable in the decimal format as currently defined. If the difference between these three matters (e.g., SRP's salt [s] parameter is one example where this difference does matter) use of decimal format for binary strings can cause things not to work. Forbidding the use of decimal representation for binary strings would be the simplest change. [T.12] 4.1 Text Format large-numerical-value: an unsigned integer larger than or equal to 2**64 encoded as a hex constant, or base64-constant. Unsigned integer arithmetic applies to large-numeric-values. I believe "larger than or equal to" should be changed to "whose value may be larger than or equal to", as the current text forbids large numerical values from representing values less than 2**64, which seems wrong. [T.13] 4.1 Text Format Any iSCSI target or initiator MUST support receiving at least 16384 bytes of key=value data in a negotiation sequence except when indi- cating support for very long authentication items by offering or selecting authentication methods such as public key certificates in which case they MUST support receiving at least 64 kilobytes of key=value data. This comment is classified as technical to catch the 16kB minimum as an open issue. The "such as" text needs to be cleaned up - the point should be that the 64 kB minimum applies when a authentication method using long authentication items is offered or accepted, and should be accompanied by a specific list of authentication methods in this draft that carry that implication. [T.14] 4.2 Text Mode Negotiation During login, and thereafter, some session or connection parameters are either declared or negotiated through an exchange of textual information. How does a declaration differ from a negotiation? It isn't described in this section, and doesn't seem to be mentioned in any of the subsequent sections about login, until one gets to the text key definitions. [T.15] 4.3.1 Login Phase Start The first Login Response PDU during the Login Phase from the iSCSI target SHOULD return the TargetPortalGroupTag key that contains the tag value of the iSCSI portal group servicing the Login Request PDU. If the iSCSI target implementation supports altering the portal group configuration (including adding, deleting, and swapping of portals in a portal group), it MUST return the TargetPortalGroupTag key carry- ing the tag value of the servicing portal group. Let's make returning this key a MUST in all cases - less text, simpler protocol, simpler code at the Initiator. [T.16] 4.3.4 Connection reinstatement Targets should support opening a second connection even when they do not support multiple connections in Full Feature Phase. Looks like that ought to be an upper case "SHOULD". I think this needs further discussion. Section 5.2 appears to use a lower case "must" for this: Whenever a connection state machine (e.g., CSM-C) enters the CLEANUP_WAIT state (S8), it must go through the state transitions additionally described in the connection cleanup state diagram either a) using a separate full-feature phase connection (let's call it CSM- E) in the LOGGED_IN state in the same session, or b) using a new transport connection (let's call it CSM-I) in the FREE state that is to be added to the same session. Also, the implications of needing to spend resources (e.g., new transport connection) to clean up resources need to be described somewhere - in the worst case, resources for a new transport connection may need to be reserved to avoid deadlock. It doesn't look like there's a problem with the transport (TCP) resources themselves, but this could be an issue for iSCSI connection state resources (what happens if all connections are in CLEANUP_WAIT and there's no iSCSI connection state resource available to open a new transport connection?). The answer is likely to involve killing off a session, but I don't see an obvious explanation of it. Then I get to Section 5.2.2, which describes a transition from CLEANUP_WAIT to FREE (M1) that can happen based on a timeout, and presumably recovers the state resources and hence might make this all work. Whether an additional connection is needed to deal with CLEANUP_WAIT and whether it's MUST/SHOULD/MAY needs to be sorted out, and the various descriptions of it made consistent. [T.17] 6.4 Format Errors The following two explicit violations of PDU layout rules are format errors: a) illegal contents of the PDU header (except the Opcode) - for ex., out-of-range values for certain fields b) inconsistent contents - for ex., value of one field conflicts with that of another. Format errors indicate a major implementation flaw in one of the par- ties. The two "for ex."s aren't good enough. Details on what is a format error need to be spelled out explicitly, given the drastic consequences of committing one. [T.18] 6.7 SCSI Timeouts On a ULP timeout for a command (that carried a CmdSN of n), the iSCSI initiator MUST abort the command by either using the Abort Task task management function request, or a "close the connection" Logout if it intends to continue the session. I think the first part is over specified - there are a number of task management commands that abort the task - if the target is really sick, something much more serious than Abort Task may be used that not only aborts this task, but others. It's not clear whether "if it intends to continue the session" applies only to the logout or to both the task management command and the logout, nor is it clear what an initiator should do if it doesn't intend to continue the session. [T.19] 8.1.1 Conservative Reuse of ISIDs To both minimize the disruption of legacy applications and to better facilitate the SCSI features that rely on persistent names for SCSI ports, iSCSI implementations should attempt to provide a stable pre- sentation of SCSI Initiator Ports That's a requirement - change "should" to "SHOULD". This is a technical comment to (re)open the issue of whether conservative reuse ought to be a "MUST" - T10 is defining persistent reservation functionality that will not behave as one might expect in the absence of conservative reuse - at the very least, this consequence of ignoring the SHOULD needs to be stated. [T.20] 8.2 Autosense and Auto Contingent Allegiance (ACA) Autosense refers to the automatic return of sense data to the initia- tor in case a command did not complete successfully. iSCSI initia- tors and targets MUST support autosense. "MUST support" --> "MUST support and use", as this is not just "MUST implement". [T.21] 8.3 iSCSI timeouts iSCSI recovery actions are often dependent on iSCSI time-outs being recognized and acted upon before SCSI time-outs. Determining the right time-outs to use for various iSCSI actions (command acknowl- edgements expected, status acknowledgements, etc.) is very much dependent on infrastructure (hardware, links, TCP/IP stack, iSCSI driver). As a guidance the implementer may use an average Nop-Out/ Nop-In turnaround delay multiplied by a "safety factor" (2-3) as a good estimate for the basic delay of the iSCSI stack for a given con- nection. "(2-3}" strikes me as low and providing little resilience to "stupid network tricks". I'd change that to something like "(e.g., 5x, with a minimum of several milliseconds)". This is complicated by the fact that both initiators and targets will likely want to insert delays (in the hope that something useful turns up that has to be sent) before sending a NOP to update the various acknowledgement counters (e.g., ExpCmdSN). [T.22] 9.1 iSCSI PDU Length and Padding iSCSI PDUs are padded to the closest integer number of four byte words. The padding bytes SHOULD be 0. "MUST be transmitted as zero and ignored by the receiver, except for calculation of the digest CRCs if present" would be better. Same comment applies to padding bytes for header segments. [T.23] 9.4.1 Flags (byte 1) Bits O and U and bits o and u are mutually exclusive. Need to put some teeth into that. Say that in each pair, it is a protocol error if both bits are set to 1, and refer to the section for handling that error. [T.24] 9.4.4 Residual Count and 9.4.5 Bidirectional Read Residual Count These should be treated as reserved when they're not valid (O and U are zero for Residual Count, o and u are zero for Bidi Read Residual Count) - MUST be set to zero by sender, MUST be ignored by receiver. [T.25] 9.5.2 LUN This field is required for functions that address a specific LU (ABORT TASK, CLEAR TASK SET, ABORT TASK SET, CLEAR ACA, LOGICAL UNIT RESET) and is reserved in all others. Should TASK REASSIGN be added to the list in parentheses? [T.26] 9.6 Task Management Function Response For the functions ABORT TASK, ABORT TASK SET, CLEAR ACA, CLEAR TASK SET, LOGICAL UNIT RESET, TARGET COLD RESET and TARGET WARM RESET, the target performs the requested Task Management function and sends a Task Management Response back to the initiator. TASK REASSIGN does not get a response. Was this intended? [T.27] 9.12.10 ExpStatSN This is ExpStatSN for the old connection. This field is valid only if the Login request restarts a connection (see Section 4.3.4 Connection reinstatement). This is for the Login Request PDU. For the initial Login Request PDU in a login phase, the description is correct, but thereafter, Login Request should be using ExpStatSN to acknowledge the Login Responses via their increasing StatSN values (see 9.13.4). This raises the related question of why StatSN/ ExpStatSN is being used during login while CmdSN/ExpCmdSN is not being used. [T.28] 9.14 Logout Request A successful completion of a logout request with the reason code of "close the connection" or "remove the connection for recovery" results in the discarding of all tasks waiting in the command reor- dering queue that are allegiant to the connection being logged out. "discarding" is not what hapapens in the "remove the connection for recovery case according to the following text from Section 6.5: b) Logout the connection for recovery and continue the tasks on a different connection instance as described in Section 6.1 Retry and Reassign in Recovery. [OR] A "discarded" task cannot be "continue"-d. I suspect the text should say that "close the connection" terminates the tasks, anad "remove the connection for recovery" suspends the tasks with the following CmdSN side effects ... [T.29] 9.14 Logout Request The entire logout discussion in this section is completely applica- ble also for an implicit Logout effected by way of a connection rein- statement or session reinstatement. The Logout reason codes for implicit Logout are specified as below: How are these codes used and why are they specified here? Logout Request is an explicit logout, not implicit. [T.30] 9.16 SNACK Request If the initiator MaxRecvDataSegmenTLength changed Data-In PDUs requested with RunLength 0 (meaning all PDUs after this number) may be different from the ones originally sent, in order to reflect changes in MaxRecvDataSegmentLength. Their DataSN starts with the requested number and is increased by 1 for each resent Data-In PDU. If DataSN numbers change and a SCSI-Reponse PDU was sent reflecting the DataSN before retransmission it MUST be resent to reflect the new numbers. This was discussed on the list, but there are still some problems here: (1) If the MaxRecvDataSegmentLength has changed, the only valid Data SNACK is BegRun=0, RunLength=0 (i.e., resend everything). Attempts to be more clever than this are an invitation to miscount Data-In PDUs and cause problems in the initiator. Targets MUST reject all other Data SNACK requests in this situation. (2) The new SCSI-Response PDU needs a new StatSN to avoid the initiator discarding it as a duplicate. Section 2.2.2.2 is silent on duplicate detection for StatSN, but discarding duplicates would be a reasonable thing for an initiator to do. (3) The initiator needs some way to know that a new response is coming, and specifically whether to expect one or two responses. If it only expects one and two show up, the initiator could reuse the Task Tag once all the data arrives causing a race in which the new response could incorrectly complete an unrelated command (unlikely, but potentially nasty). This suggests calling out the Data SNACK as having special behavior: - It may resegment Data-In PDUs to deal with MaxRecvDataSegmentLength. All other Data SNACK requests MUST NOT resegment. - It *always* generates a new SCSI Response due to the possibility of resegmentation. That's not a great solution, because if one ever sets in a Data SNACK, the resulting behavior change is dramatic and unexpected. This leads to the final proposal: - Specify a new SNACK type code (3) for Resegmenting Data SNACK. SNACK Data-In resegmentation is allowed only when this is used. If resegmentation would be necessary for a Data SNACK (type 1), that SNACK MUST be rejected. - Both BegRun and RunLength MUST be zero for a Resegmenting Data SNACK, and (unlike reserved fields) these MUST be checked by the receiver (target). - A new SCSI Response is always generated as a result of a Resegmenting Data-In SNACK, and it has its own StatSN number to deal with the fact that the number of Data-In PDUs may have changed, causing a change to the ExpDataSN value. This new response also needs to be marked to distinguish it from a response that may have been generated earlier (so the initiator knows to wait for the new response) - using a bit in the flags field for this seems wrong, so specifying a new Response code value (0x02 - see 9.4.3) seems like a reasonable way to accomplish this. - Data SNACK (type 1) now has consistent behavior - it MUST NOT resegment and MUST NOT generate a new SCSI response, ever. This approach also has the potentially useful property of making it easy to yank out the Resegmenting Data SNACK wart if we ever put restrictions on the interaction of MaxRecvDatasegmentLength and Data SNACKs (yes, that's a hint ... this has gotten messy enough that forbidding Data SNACKs when MaxRecvDataSegmentLength has changed needs to be considered as a possible alternative). This issue also affects some text in 9.16.3. [T.31] 9.16.1 Type An iSCSI target that does not support recovery within connection MAY reject the status SNACK with a Reject PDU. If the target supports recovery within connection, it MAY reject the SNACK after which it MUST issue an Asynchronous Message PDU with an iSCSI event that indi- cates "Request Logout". This should be conditioned on the operational ErrorRecoveryLevel of the session, not whether the target supports recovery within connection. [T.32] 10. iSCSI Security Keys and Authentication Methods Only the following keys can be used during the SecurityNegotiation stage of the Login Phase: [ ... snip ...] AuthMethod and all keys listed under AuthMethod along with all of their associated keys. In practice, this forbids vendor-unique authentication methhods, as they would have to define their own text keys (reusing keys for an existing AuthMethod is a *bad* idea). OTOH, Section 10.1 appears to allow vendor-unique authentication methods. The authentication methods that can be used (appear in the list-of- options) are either those listed in the following table or are ven- dor-unique methods: One of these two needs to change, and see also editorial comment [E.136] against the above text from Section 10. Forbidding vendor-unique authentication methods would enhance interoperability. [T.33] 10.5 Challenge Handshake Authentication Protocol (CHAP) For the Algorithm, as stated in [RFC1994], one value is required to be implemented: 5 (CHAP with MD5) To guarantee interoperability, initiators SHOULD always offer it as one of the proposed algorithms. Change that "SHOULD" to a "MUST". [T.34] 11.1 HeaderDigest and DataDigest Proprietary algorithms MAY also be negotiated for digests. Whenever a proprietary algorithm is negotiated, "None" or "CRC32C" should be listed as an option in order to guarantee interoperability. Change "negotiatiated" to "offered" and "should" to "MUST". [T.35] 11.4 TargetName and 11.5 InitiatorName The descriptions of these keys need to have restrictions on changing them added - changing a name after it's been used for initial authentication/ authorization can cause security problems. These restrictions may already exist in the prohibitions on re-negotiating keys, but need to be (re)stated here. [T.36] 11.6 TargetAlias and 11.7 InitiatorAlias Add text here or in Section 10 to say that these keys MUST NOT be used to make authentication, or authorization (including access control) decisions. [T.37] 11.12 ImmediateData If ImmediateData is set to No and InitialR2T is set to No, then the initiator MUST NOT send unsolicited immediate data, but MAY send one unsolicited burst of Data-OUT PDUs. If ImmediateData is set to Yes and InitialR2T is set to No, then the initiator MAY send unsolicited immediate data and/or one unsolicited burst of Data-OUT PDUs. Both of the above uses of "MAY" are problems - my recollection of this is that if InitialR2T=No and there is data to be sent that falls under the implicit Initial R2T, then it MUST be sent as unsolicited Data-Out PDUs. [T.38] 12. IANA Considerations The temporary (user) well-known port number for iSCSI connections assigned by IANA is 3260. Delete "temporary (user)" insert "TCP" before "port number" or add instructions for IANA to allocate a system port when this draft is approved to become an RFC - I think just sticking with 3260 is better. [T.39] 12. IANA Considerations If vendor additions of values to existing keys is to be allowed (e.g., AuthMethod, HeaderDigest, DataDigest) an IANA registry is needed for each set of values - see [T.32] and [T.34], or the reversed DNS convention needs to be extended from keys to values - the latter doesn't sound like a good idea. -- Editorial Global Editorial comment: Both the login (4) and error handling (6) sections feel like one of those old Adventure mazes of twisty little passages - all the details seem to be there, for the most part they're correct, but it's very hard to get the proverbial "big picture" of how everything fits together, in terms of how the various mechanisms work with each other and how they accomplish the overall functionality. Both of these could use overview sections describing how the functionality breaks down into the pieces described in the subsections and how they fit together. Swapping the order of Sections 5 and 6 would also be a good idea so that the discussion of Error Handling and Recovery comes before the state machine descriptions that contain a lot of the details of how errors are handled. For error handling, moving Section 6.13 to the front of Section 6 would help organize the Section better, and care should be taken to define or replace terms like "restart login" and "recovery R2T" that are currently used without definitions. Also the following two editorial comments recommend serious restructuring of a portion of the draft: [E.80] 5.1 Standard Connection State Diagrams I'm probably going to take grief for this comment because it's a lot of work, but I think this section would be significantly clearer if the state and transition descriptions were split into separate initiator and target portions, so the order of the subsections would be: - Initiator diagram - Initiator state descriptions - Initiator transition descriptions - Target diagram - Target state descriptions - Target transition descriptions I guess it's ok to leave the descriptions merged in Section 5.2. [E.81] 5.3 Session State Diagrams This should be restructured in a fashion similar to Section 5.1 (see [E.80]). If you made it this far, thanks for taking the time to read everything, --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 --------------------------------------------------- From owner-ips@ece.cmu.edu Sun Jul 7 09:52:24 2002 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA21291 for ; Sun, 7 Jul 2002 09:52:24 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id g67DBWX18843 for ips-outgoing; Sun, 7 Jul 2002 09:11:32 -0400 (EDT) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from cygnus.equallogic.com (cygnus.equallogic.com [65.170.102.10]) by ece.cmu.edu (8.11.0/8.10.2) with SMTP id g67DBVX18839 for ; Sun, 7 Jul 2002 09:11:31 -0400 (EDT) Received: from cygnus.equallogic.com (localhost.localdomain [127.0.0.1]) by cygnus.equallogic.com (8.11.6/8.11.6) with ESMTP id g67DBPC29783 for ; Sun, 7 Jul 2002 09:11:25 -0400 Received: from deneb.dev.equallogic.com (deneb.dev.equallogic.com [172.16.1.99]) by cygnus.equallogic.com (8.11.6/8.11.6) with ESMTP id g67DBPQ29772; Sun, 7 Jul 2002 09:11:25 -0400 Received: from PKONING.equallogic.com (localhost.localdomain [127.0.0.1]) by deneb.dev.equallogic.com (8.11.6/8.11.6) with ESMTP id g67DBNo25711; Sun, 7 Jul 2002 09:11:24 -0400 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <15656.15869.46000.92164@gargle.gargle.HOWL> Date: Sun, 7 Jul 2002 09:11:25 -0400 From: Paul Koning To: Elizabeth.G.Rodriguez@123mail.net Cc: ips@ece.cmu.edu Subject: RE: iSCSI: Decimal encoding - why 64 bits ? References: <004b01c224be$33ca5740$0100000a@JA31> <000001c22502$2b5a84b0$0ceaafce@EGRodriguez> X-Mailer: VM 6.95 under 21.4 (patch 3) "Academic Rigor" XEmacs Lucid Sender: owner-ips@ece.cmu.edu Precedence: bulk Content-Transfer-Encoding: 7bit Excerpt of message (sent 6 July 2002) by Elizabeth G. Rodriguez: > Given these examples, I believe that restricting decimal encoded binary > strings is not an option. Why not? I don't see that phone numbers have any relevance to the discussion. And port numbers (just like IP addresses) are not 64 bit values, which is what we were talking about. paul > -----Original Message----- > From: owner-ips@ece.cmu.edu [mailto:owner-ips@ece.cmu.edu] On Behalf Of > Julian Satran (Actcom) > Sent: Saturday, July 06, 2002 1:25 AM > To: Robert Snively; 'Martins Krikis'; Black_David@emc.com > Cc: ips@ece.cmu.edu > Subject: Re: iSCSI: Decimal encoding - why 64 bits ? > > You may want to add to the list port-numbers, domain specific name > formats > (yes some domains mainly phone systems use decimal encodings). > > A search for decimal encoded binary strings in the RFC domain gave well > over > one-hundred results. > > Julo From owner-ips@ece.cmu.edu Sun Jul 7 10:44:00 2002 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA22068 for ; Sun, 7 Jul 2002 10:43:46 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id g67E6eV19917 for ips-outgoing; Sun, 7 Jul 2002 10:06:40 -0400 (EDT) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from d12lmsgate-3.de.ibm.com (d12lmsgate-3.de.ibm.com [195.212.91.201]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id g67E6cX19912; Sun, 7 Jul 2002 10:06:38 -0400 (EDT) Received: from d12relay01.de.ibm.com (d12relay01.de.ibm.com [9.165.215.22]) by d12lmsgate-3.de.ibm.com (8.12.3/8.12.3) with ESMTP id g67E6Q2F026552; Sun, 7 Jul 2002 16:06:26 +0200 Received: from d10hubm1.telaviv.ibm.com (d10ml001.telaviv.ibm.com [9.148.216.55]) by d12relay01.de.ibm.com (8.11.1m3/NCO/VER6.2) with ESMTP id g67E6PQ47080; Sun, 7 Jul 2002 16:06:26 +0200 To: Paul Koning Cc: Elizabeth.G.Rodriguez@123mail.net, ips@ece.cmu.edu, owner-ips@ece.cmu.edu MIME-Version: 1.0 Subject: RE: iSCSI: Decimal encoding - why 64 bits ? X-Mailer: Lotus Notes Release 5.0.9 November 16, 2001 From: "Julian Satran" Message-ID: Date: Sun, 7 Jul 2002 17:06:24 +0300 X-MIMETrack: Serialize by Router on D10ML001/10/M/IBM(Release 5.0.9a |January 7, 2002) at 07/07/2002 17:06:26, Serialize complete at 07/07/2002 17:06:26 Content-Type: multipart/alternative; boundary="=_alternative 004D0926C2256BEF_=" Sender: owner-ips@ece.cmu.edu Precedence: bulk This is a multipart message in MIME format. --=_alternative 004D0926C2256BEF_= Content-Type: text/plain; charset="us-ascii" Paul, there are two subjects that we are discussing: 1-size of numbers 64bit vs 32 bit 2-decimal encoding for bit strings The 2 subjects are somewhat orthogonal. Elizabeth was referring to the second subject. julo Paul Koning Sent by: owner-ips@ece.cmu.edu 07/07/2002 04:11 PM Please respond to Paul Koning To: Elizabeth.G.Rodriguez@123mail.net cc: ips@ece.cmu.edu Subject: RE: iSCSI: Decimal encoding - why 64 bits ? Excerpt of message (sent 6 July 2002) by Elizabeth G. Rodriguez: > Given these examples, I believe that restricting decimal encoded binary > strings is not an option. Why not? I don't see that phone numbers have any relevance to the discussion. And port numbers (just like IP addresses) are not 64 bit values, which is what we were talking about. paul > -----Original Message----- > From: owner-ips@ece.cmu.edu [mailto:owner-ips@ece.cmu.edu] On Behalf Of > Julian Satran (Actcom) > Sent: Saturday, July 06, 2002 1:25 AM > To: Robert Snively; 'Martins Krikis'; Black_David@emc.com > Cc: ips@ece.cmu.edu > Subject: Re: iSCSI: Decimal encoding - why 64 bits ? > > You may want to add to the list port-numbers, domain specific name > formats > (yes some domains mainly phone systems use decimal encodings). > > A search for decimal encoded binary strings in the RFC domain gave well > over > one-hundred results. > > Julo --=_alternative 004D0926C2256BEF_= Content-Type: text/html; charset="us-ascii"
Paul,

there are two subjects that we are discussing:

1-size of numbers 64bit vs 32 bit
2-decimal encoding for bit strings

The 2 subjects are somewhat orthogonal.

Elizabeth was referring to the second subject.

julo


Paul Koning <ni1d@arrl.net>
Sent by: owner-ips@ece.cmu.edu

07/07/2002 04:11 PM
Please respond to Paul Koning

       
        To:        Elizabeth.G.Rodriguez@123mail.net
        cc:        ips@ece.cmu.edu
        Subject:        RE: iSCSI: Decimal encoding - why 64 bits ?

       


Excerpt of message (sent 6 July 2002) by Elizabeth G. Rodriguez:
> Given these examples, I believe that restricting decimal encoded binary
> strings is not an option.

Why not?  I don't see that phone numbers have any relevance to the
discussion.  And port numbers (just like IP addresses) are not 64 bit
values, which is what we were talking about.

                    paul

> -----Original Message-----
> From: owner-ips@ece.cmu.edu [mailto:owner-ips@ece.cmu.edu] On Behalf Of
> Julian Satran (Actcom)
> Sent: Saturday, July 06, 2002 1:25 AM
> To: Robert Snively; 'Martins Krikis'; Black_David@emc.com
> Cc: ips@ece.cmu.edu
> Subject: Re: iSCSI: Decimal encoding - why 64 bits ?
>
> You may want to add to the list port-numbers, domain specific name
> formats
> (yes some domains mainly phone systems use decimal encodings).
>
> A search for decimal encoded binary strings in the RFC domain gave well
> over
> one-hundred results.
>
> Julo

--=_alternative 004D0926C2256BEF_=-- From owner-ips@ece.cmu.edu Sun Jul 7 11:35:56 2002 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA23175 for ; Sun, 7 Jul 2002 11:35:56 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id g67F2gN21072 for ips-outgoing; Sun, 7 Jul 2002 11:02:42 -0400 (EDT) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from mail.wrs.com (unknown-1-11.windriver.com [147.11.1.11]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id g67F2eX21068 for ; Sun, 7 Jul 2002 11:02:40 -0400 (EDT) Received: from london ([192.168.1.89]) by mail.wrs.com (8.9.3/8.9.1) with SMTP id IAA00526 for ; Sun, 7 Jul 2002 08:00:57 -0700 (PDT) From: "Rod Harrison" To: Subject: iSCSI: DLB's [T.33] 10.5 Challenge Handshake Authentication Protocol (CHAP) Date: Sun, 7 Jul 2002 10:03:32 -0500 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0) Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2314.1300 Sender: owner-ips@ece.cmu.edu Precedence: bulk Content-Transfer-Encoding: 7bit David, A MUST here seems to preclude the initiator not offering CHAP due to administrative configuration. In fact the original SHOULD seems a bit strong. I.e. is ... AuthMethod=none no longer to be valid? If so perhaps the text should change to require CHAP and / or none.7 - Rod From owner-ips@ece.cmu.edu Sun Jul 7 11:38:53 2002 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA23218 for ; Sun, 7 Jul 2002 11:38:52 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id g67FE1P21401 for ips-outgoing; Sun, 7 Jul 2002 11:14:01 -0400 (EDT) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from d12lmsgate-2.de.ibm.com (d12lmsgate-2.de.ibm.com [195.212.91.200]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id g67FDxX21397 for ; Sun, 7 Jul 2002 11:13:59 -0400 (EDT) Received: from d12relay01.de.ibm.com (d12relay01.de.ibm.com [9.165.215.22]) by d12lmsgate-2.de.ibm.com (8.12.3/8.12.3) with ESMTP id g67FDnIS029252; Sun, 7 Jul 2002 17:13:53 +0200 Received: from d10hubm1.telaviv.ibm.com (d10ml001.telaviv.ibm.com [9.148.216.55]) by d12relay01.de.ibm.com (8.11.1m3/NCO/VER6.2) with ESMTP id g67FDmQ73592; Sun, 7 Jul 2002 17:13:49 +0200 To: ips@ece.cmu.edu, Black_David@emc.com MIME-Version: 1.0 Subject: iSCSI -DLB comments X-Mailer: Lotus Notes Release 5.0.9 November 16, 2001 From: "Julian Satran" Message-ID: Date: Sun, 7 Jul 2002 18:13:47 +0300 X-MIMETrack: Serialize by Router on D10ML001/10/M/IBM(Release 5.0.9a |January 7, 2002) at 07/07/2002 18:13:48, Serialize complete at 07/07/2002 18:13:48 Content-Type: multipart/alternative; boundary="=_alternative 0053130AC2256BEF_=" Sender: owner-ips@ece.cmu.edu Precedence: bulk This is a multipart message in MIME format. --=_alternative 0053130AC2256BEF_= Content-Type: text/plain; charset="us-ascii" David, I have posted fixes for T1 to T10 and keep working on the rest (I could not devote enough time today to iSCSI). With regard to T11 the text you quote specifies only the "implicit length". The encoding length specified later in 4.1 for binary and large-binary says that the length can be either implicit or explicit. The examples you quote can be/are solved with an explicit length. As I said we considered forbidding decimals several times but that would be a total departure from the RFC "tradition". Julo --=_alternative 0053130AC2256BEF_= Content-Type: text/html; charset="us-ascii"
David,

I have posted fixes for T1 to T10 and keep working on the rest (I could not devote enough time today to iSCSI).
With regard to T11 the text you quote specifies only the "implicit length". The encoding length specified later in 4.1 for binary and large-binary says that the
length can be either implicit or explicit. The examples you quote can be/are solved with an explicit length.

As I said we considered forbidding decimals several times but that would be a total departure from the RFC "tradition".

Julo --=_alternative 0053130AC2256BEF_=-- From owner-ips@ece.cmu.edu Sun Jul 7 11:39:19 2002 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA23235 for ; Sun, 7 Jul 2002 11:39:19 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id g67F2JI21057 for ips-outgoing; Sun, 7 Jul 2002 11:02:19 -0400 (EDT) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from mail.wrs.com (unknown-1-11.windriver.com [147.11.1.11]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id g67F2IX21053 for ; Sun, 7 Jul 2002 11:02:18 -0400 (EDT) Received: from london ([192.168.1.89]) by mail.wrs.com (8.9.3/8.9.1) with SMTP id IAA00478 for ; Sun, 7 Jul 2002 08:00:36 -0700 (PDT) From: "Rod Harrison" To: Subject: iSCSI: DLB's [T.37] 11.12 ImmediateData Date: Sun, 7 Jul 2002 10:03:11 -0500 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0) Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2314.1300 Sender: owner-ips@ece.cmu.edu Precedence: bulk Content-Transfer-Encoding: 7bit David, I believe the MAY is to allow the initiator to send no unsolicited data if it so chooses. For non-immediate unsolicited the rule was the initiator MUST send all of the unsolicited data possible, or no unsolicited data. The presence of the F bit in the latter case removes the possibility of any confusion over the amount of unsolicited data at the target. - Rod From owner-ips@ece.cmu.edu Sun Jul 7 13:27:03 2002 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA27413 for ; Sun, 7 Jul 2002 13:26:58 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id g67GegI23516 for ips-outgoing; Sun, 7 Jul 2002 12:40:42 -0400 (EDT) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from dogwood.cisco.com (dogwood.cisco.com [161.44.11.19]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id g67GefX23512 for ; Sun, 7 Jul 2002 12:40:41 -0400 (EDT) Received: from aghanemw2k (sjc-vpn3-476.cisco.com [10.21.65.220]) by dogwood.cisco.com (8.8.6 (PHNE_14041)/CISCO.SERVER.1.2) with SMTP id MAA12673 for ; Sun, 7 Jul 2002 12:40:33 -0400 (EDT) From: "Ayman Ghanem" To: Subject: RE: iSCSI: DLB's [T.6] 2.3 iSCSI Session Types Date: Sun, 7 Jul 2002 11:40:33 -0500 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0) Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2919.6700 In-Reply-To: <277DD60FB639D511AC0400B0D068B71E0564C034@CORPMX14> Sender: owner-ips@ece.cmu.edu Precedence: bulk Content-Transfer-Encoding: 7bit I prefer leaving this as "MAY" for implementations that want to support new device notifications. There was a discussion on whether discovery sessions should be long-lived or not. Using MAY allows both without breaking any thing. -Ayman > [T.6] 2.3 iSCSI Session Types > > b) Discovery-session - a session opened only for target discov- > ery; the target MAY accept only text requests with the SendTar- > gets key and a logout request with reason "close the session". > > Change "MAY" to "MUST", and say that other requests MUST be rejected. > From owner-ips@ece.cmu.edu Sun Jul 7 14:18:38 2002 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA29095 for ; Sun, 7 Jul 2002 14:18:38 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id g67HobA25061 for ips-outgoing; Sun, 7 Jul 2002 13:50:37 -0400 (EDT) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from e1.ny.us.ibm.com (e1.ny.us.ibm.com [32.97.182.101]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id g67HoYX25048 for ; Sun, 7 Jul 2002 13:50:34 -0400 (EDT) Received: from westrelay01.boulder.ibm.com (westrelay01.boulder.ibm.com [9.17.194.22]) by e1.ny.us.ibm.com (8.12.2/8.12.2) with ESMTP id g67HoLg6101514 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=NO); Sun, 7 Jul 2002 13:50:22 -0400 Received: from d03nm014.boulder.ibm.com (avpilot.boulder.ibm.com [9.17.203.135]) by westrelay01.boulder.ibm.com (8.12.3/NCO/VER6.3) with ESMTP id g67HoK6w026366; Sun, 7 Jul 2002 11:50:20 -0600 X-Priority: 1 (High) Importance: Normal Subject: RE: iSCSI: DLB's [T.6] 2.3 iSCSI Session Types To: "Ayman Ghanem" Cc: X-Mailer: Lotus Notes Release 5.0.7 March 21, 2001 Message-ID: From: "John Hufferd" Date: Sun, 7 Jul 2002 10:44:28 -0700 X-MIMETrack: Serialize by Router on D03NM014/03/M/IBM(Release 5.0.10 |March 22, 2002) at 07/07/2002 11:50:20 AM MIME-Version: 1.0 Content-type: text/plain; charset=us-ascii Sender: owner-ips@ece.cmu.edu Precedence: bulk Let me add to this, I think I remember that someone might have special x-keys they want to support. Also, I remember the use of NOP-In commands were needed for long lasting sessions, hence the use of MAY, if the target did not want to support long lasting sessions. . . . John L. Hufferd Senior Technical Staff Member (STSM) IBM/SSG San Jose Ca Main Office (408) 256-0403, Tie: 276-0403, eFax: (408) 904-4688 Home Office (408) 997-6136, Cell: (408) 499-9702 Internet address: hufferd@us.ibm.com "Ayman Ghanem" @ece.cmu.edu on 07/07/2002 09:40:33 AM Sent by: owner-ips@ece.cmu.edu To: cc: Subject: RE: iSCSI: DLB's [T.6] 2.3 iSCSI Session Types I prefer leaving this as "MAY" for implementations that want to support new device notifications. There was a discussion on whether discovery sessions should be long-lived or not. Using MAY allows both without breaking any thing. -Ayman > [T.6] 2.3 iSCSI Session Types > > b) Discovery-session - a session opened only for target discov- > ery; the target MAY accept only text requests with the SendTar- > gets key and a logout request with reason "close the session". > > Change "MAY" to "MUST", and say that other requests MUST be rejected. > From owner-ips@ece.cmu.edu Sun Jul 7 14:21:44 2002 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA29326 for ; Sun, 7 Jul 2002 14:21:43 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id g67HoQY25036 for ips-outgoing; Sun, 7 Jul 2002 13:50:26 -0400 (EDT) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from e21.nc.us.ibm.com (e21.nc.us.ibm.com [32.97.136.227]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id g67HoOX25031 for ; Sun, 7 Jul 2002 13:50:24 -0400 (EDT) Received: from westrelay01.boulder.ibm.com (westrelay01.boulder.ibm.com [9.17.194.22]) by e21.nc.us.ibm.com (8.12.2/8.12.2) with ESMTP id g67HoNRZ064840 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=NO); Sun, 7 Jul 2002 13:50:23 -0400 Received: from d03nm014.boulder.ibm.com (avpilot.boulder.ibm.com [9.17.203.135]) by westrelay01.boulder.ibm.com (8.12.3/NCO/VER6.3) with ESMTP id g67HoK6x026366; Sun, 7 Jul 2002 11:50:21 -0600 X-Priority: 1 (High) Importance: Normal Subject: Re: iSCSI -DLB comments To: "Julian Satran" Cc: ips@ece.cmu.edu, Black_David@emc.com X-Mailer: Lotus Notes Release 5.0.7 March 21, 2001 Message-ID: From: "John Hufferd" Date: Sun, 7 Jul 2002 10:45:58 -0700 X-MIMETrack: Serialize by Router on D03NM014/03/M/IBM(Release 5.0.10 |March 22, 2002) at 07/07/2002 11:50:21 AM MIME-Version: 1.0 Content-type: text/plain; charset=us-ascii Sender: owner-ips@ece.cmu.edu Precedence: bulk Julian, please do not be too quick to follow the suggestion regarding T6. Ayman, had a valid point. . . . John L. Hufferd Senior Technical Staff Member (STSM) IBM/SSG San Jose Ca Main Office (408) 256-0403, Tie: 276-0403, eFax: (408) 904-4688 Home Office (408) 997-6136, Cell: (408) 499-9702 Internet address: hufferd@us.ibm.com Julian Satran/Haifa/IBM@IBMIL@ece.cmu.edu on 07/07/2002 08:13:47 AM Sent by: owner-ips@ece.cmu.edu To: ips@ece.cmu.edu, Black_David@emc.com cc: Subject: iSCSI -DLB comments David, I have posted fixes for T1 to T10 and keep working on the rest (I could not devote enough time today to iSCSI). With regard to T11 the text you quote specifies only the "implicit length". The encoding length specified later in 4.1 for binary and large-binary says that the length can be either implicit or explicit. The examples you quote can be/are solved with an explicit length. As I said we considered forbidding decimals several times but that would be a total departure from the RFC "tradition". Julo From owner-ips@ece.cmu.edu Sun Jul 7 15:02:57 2002 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA01320 for ; Sun, 7 Jul 2002 15:02:57 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id g67IaCr26261 for ips-outgoing; Sun, 7 Jul 2002 14:36:12 -0400 (EDT) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from dogwood.cisco.com (dogwood.cisco.com [161.44.11.19]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id g67IaBX26256 for ; Sun, 7 Jul 2002 14:36:11 -0400 (EDT) Received: from aghanemw2k (sjc-vpn3-47.cisco.com [10.21.64.47]) by dogwood.cisco.com (8.8.6 (PHNE_14041)/CISCO.SERVER.1.2) with SMTP id OAA05316 for ; Sun, 7 Jul 2002 14:36:04 -0400 (EDT) From: "Ayman Ghanem" To: Subject: iSCSI: AMG Last call comments Date: Sun, 7 Jul 2002 13:36:04 -0500 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0) Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2919.6700 Sender: owner-ips@ece.cmu.edu Precedence: bulk Content-Transfer-Encoding: 7bit I only have two minor technical comments. A few editorials will go to Julian. 1. Near the end of 9.3.4 (SCSI Command): If the Expected Data Transfer Length is higher than the FirstBurst- Length (the negotiated maximum amount of unsolicited data the target will accept), the initiator MUST send the maximum length of unsolic- ited data OR ONLY the immediate data. suggest adding: ..........OR ONLY the immediate data, if any. 2. 9.12 (Login Request) Login requests are always considered as immediate. suggest setting the I-bit in the login PDU to 1 instead of rsvd -Ayman From owner-ips@ece.cmu.edu Sun Jul 7 15:05:13 2002 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA01422 for ; Sun, 7 Jul 2002 15:05:12 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id g67IPrE25968 for ips-outgoing; Sun, 7 Jul 2002 14:25:53 -0400 (EDT) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from mail.brocade.com (sj6-b.brocade.com [63.121.140.220]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id g67IPqX25964 for ; Sun, 7 Jul 2002 14:25:52 -0400 (EDT) Received: from hq-ex-c2.brocade.com (hq-ex-c2 [192.168.126.35]) by mail.brocade.com (8.8.8+Sun/8.8.8) with ESMTP id LAA01312 for ; Sun, 7 Jul 2002 11:25:46 -0700 (PDT) Received: by hq-ex-c2.brocade.com with Internet Mail Service (5.5.2653.19) id ; Sun, 7 Jul 2002 11:25:45 -0700 Message-ID: From: Brian Forbes To: ips@ece.cmu.edu Cc: Robert Snively Subject: BKF Comments on iSCSI version 14 Date: Sun, 7 Jul 2002 11:25:45 -0700 X-Mailer: Internet Mail Service (5.5.2653.19) Sender: owner-ips@ece.cmu.edu Precedence: bulk I've sent a list of editorial comments directly to Julian. Technical comments: T1: Although it is alluded to in section 11.10, the document must explicitly define the effective value of Buffer Offset for immediate data. Possible sections for doing so include 2.2.4 and 9.3.6. T2: I agree with the recent reflector discussion that decimal is only used for numbers, hex for numbers and binary, and base64 only for binary items. I believe the debate should focus on the utility of the existing iSCSI type definitions and avoid getting derailed by anecdotal references to data types in other RFCs. T3: Section 4.3.1, page 80: "If the reconfiguration of iSCSI portal groups is a concern in a given environment, the iSCSI initiator MUST use this key to ascertain that it had indeed initiated the Login Phase with the intended target portal group." The use of MUST in the final sentence is untestable and should probably be lower-case "should". T4: Section 11.8, page 215: "If the TargetAddress is returned as the result of a redirect status in a login response, the comma and portal group tag are omitted." For interoperability reasons, I believe "are omitted" should be "MUST be omitted". T5: Section 11.8, page 215: "If the TargetAddress is returned within a SendTargets response, the portal group tag is required." For interoperability reasons, I believe "is required" should be "MUST be included". Brian Forbes Technology Brocade Communications From owner-ips@ece.cmu.edu Sun Jul 7 15:38:38 2002 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA02492 for ; Sun, 7 Jul 2002 15:38:37 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id g67J7R927065 for ips-outgoing; Sun, 7 Jul 2002 15:07:27 -0400 (EDT) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from d12lmsgate.de.ibm.com (d12lmsgate.de.ibm.com [195.212.91.199]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id g67J7OX27060 for ; Sun, 7 Jul 2002 15:07:24 -0400 (EDT) Received: from d12relay02.de.ibm.com (d12relay02.de.ibm.com [9.165.215.23]) by d12lmsgate.de.ibm.com (8.12.3/8.12.3) with ESMTP id g67J7HIB073570; Sun, 7 Jul 2002 21:07:17 +0200 Received: from d10hubm1.telaviv.ibm.com (d10ml001.telaviv.ibm.com [9.148.216.55]) by d12relay02.de.ibm.com (8.11.1m3/NCO/VER6.2) with ESMTP id g67J7F499338; Sun, 7 Jul 2002 21:07:16 +0200 Importance: Normal Subject: Re: iSCSI: DLB's [T.33] 10.5 Challenge Handshake Authentication Protocol (CHAP) To: "Rod Harrison" Cc: X-Mailer: Lotus Notes Release 5.0.3 (Intl) 21 March 2000 Message-ID: From: "Ofer Biran" Date: Sun, 7 Jul 2002 22:07:53 +0300 X-MIMETrack: Serialize by Router on D10ML001/10/M/IBM(Release 5.0.9a |January 7, 2002) at 07/07/2002 22:07:16 MIME-Version: 1.0 Content-type: text/plain; charset=us-ascii Sender: owner-ips@ece.cmu.edu Precedence: bulk Rod, Section 10 has a lot of such MUSTs for the required steps of each authentication method. All these are applied of course only when the relevant authentication method have been chosen in the negotiation. (or maybe you confused the "Algorithm" with "authentication method", i.e., in "For the Algorithm, as stated in [RFC1994], one value is required to be implemented: 5 (CHAP with MD5)..." the Algorithm is the CHAP_A key sent on the first CHAP step. ) Regards, Ofer Ofer Biran Storage and Systems Technology IBM Research Lab in Haifa biran@il.ibm.com 972-4-8296253 "Rod Harrison" @ece.cmu.edu on 07/07/2002 18:03:32 Please respond to "Rod Harrison" Sent by: owner-ips@ece.cmu.edu To: cc: Subject: iSCSI: DLB's [T.33] 10.5 Challenge Handshake Authentication Protocol (CHAP) David, A MUST here seems to preclude the initiator not offering CHAP due to administrative configuration. In fact the original SHOULD seems a bit strong. I.e. is ... AuthMethod=none no longer to be valid? If so perhaps the text should change to require CHAP and / or none.7 - Rod From owner-ips@ece.cmu.edu Sun Jul 7 16:57:50 2002 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA05253 for ; Sun, 7 Jul 2002 16:57:50 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id g67KJTm28744 for ips-outgoing; Sun, 7 Jul 2002 16:19:29 -0400 (EDT) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from sj-msg-core-2.cisco.com (sj-msg-core-2.cisco.com [171.69.24.11]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id g67KJSX28740 for ; Sun, 7 Jul 2002 16:19:28 -0400 (EDT) Received: from sponge.cisco.com (IDENT:mirapoint@sponge.cisco.com [64.101.128.87]) by sj-msg-core-2.cisco.com (8.12.2/8.12.2) with ESMTP id g67KJJhI000776 for ; Sun, 7 Jul 2002 13:19:19 -0700 (PDT) Received: from DAPW2K3 (sjc-vpn3-47.cisco.com [10.21.64.47]) by sponge.cisco.com (Mirapoint) with SMTP id ABB12609; Sun, 7 Jul 2002 15:19:18 -0500 (CDT) From: "Dave Peterson" To: "Ips@Ece. Cmu. Edu" Subject: iSCSI: DAP Last Call Comments Date: Sun, 7 Jul 2002 15:19:17 -0500 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0) Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 Sender: owner-ips@ece.cmu.edu Precedence: bulk Content-Transfer-Encoding: 7bit T p 36 2.2.2.1 Command Numbering and Acknowledging: 7th paragraph: if not in this document, where is the means to request immediate delivery for a command? T p 38 2.2.2.2 Response/Status Numbering and Acknowledging: 4th paragraph: this paragraph is too vague which may result in different error recovery initiations being implemented. T p 43 2.2.4 iSCSI Full Feature Phase: 16th paragraph: last sentence is not correct since out of order data delivery is allowed (if negotiated) T p 73 4.2 Text Mode Negotiation: 6th paragraph: 3rd sentence: change the "should" to a "must" T p 73 4.2 Text Mode Negotiation: 8th paragraph: the use of "Irrelevant" is a potential interoperability problem. Need to further specify the use of "Irrelevant". T p 73 4.2 Text Mode Negotiation: 9th paragraph: specify that a "key=NotUnderstood" is applicable for "X-keys" only. T p 103 6.1.1 Usage of Retry and 6.7 SCSI Timeouts: the semantics of Retry remain broken rendering it useless for tape operation. SCSI level error detection and recovery is the preferred mechanism. Refer to previous emails sent via the IPS reflector regarding this matter. T p 128 8.6 Considerations for State-dependent devices: last paragraph: don't agree with the statement that error recovery at the iSCSI level (specifically Retry in its current state) is advisable. Retry at the SCSI level is feasible and is not difficult (i.e., READ POSITION and LOCATE commands). This paragraph should be removed. T p 214 11.11 BidiInitialR2T: this text key provides no value and needs to be removed. InitialR2T should be used for both uni and bidirectional commands. In addition, if BidiInitialR2T were to be used, it will not function via an iSCSI-FCP gateway. From owner-ips@ece.cmu.edu Sun Jul 7 22:10:41 2002 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA17740 for ; Sun, 7 Jul 2002 22:10:36 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id g681Rtb06901 for ips-outgoing; Sun, 7 Jul 2002 21:27:55 -0400 (EDT) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from osmtp2.electric.net (osmtp2.electric.net [216.129.90.29]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id g681RrX06896 for ; Sun, 7 Jul 2002 21:27:54 -0400 (EDT) Received: from [216.192.234.8] (helo=EGRodriguez) by osmtp2.electric.net with asmtp (Exim 3.22 #1) id 17RNJc-00068H-04 for ips@ece.cmu.edu; Sun, 07 Jul 2002 18:27:48 -0700 From: "Elizabeth G. Rodriguez" To: Subject: FW: ISCSI: comments on iSCSI 14. (resend) Date: Sun, 7 Jul 2002 20:24:41 -0600 Message-ID: <014401c22626$9f50f190$08eac0d8@EGRodriguez> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.3416 Importance: Normal X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 Sender: owner-ips@ece.cmu.edu Precedence: bulk Content-Transfer-Encoding: 7bit My comments do not seem to have made it to the list. Used wrong email account initially. Resend... Apologies if you receive twice. Elizabeth -----Original Message----- From: Elizabeth Rodriguez [mailto:ElizabethRodriguez@ieee.org] Sent: Sunday, July 07, 2002 4:15 PM To: 'ips@ece.cmu.edu' Cc: 'Julian Satran (Actcom)'; John Hufferd (hufferd@us.ibm.com); David Black (black_david@emc.com); 'Julian_Satran@il.ibm.com' Subject: ISCSI: comments on iSCSI 14. Here are my working group last call on the iSCSI document. This was a review of version 14 of the document. All page and section numbers refer to that document. All comments are my own as an individual contributor, as opposed to WG co-chair. Thanks, Elizabeth Rodriguez Technical 1) Acknowledgements, pg 3, para 3 This document has to be considered together with the "Naming & Dis- covery"[NDT], "Boot"[BOOT] and "Securing iSCSI, iFCP and FCIP"[SEC- IPS] documents. EGR What about the requirements doc, string profile, SLP and iSNS? Think the first should be present in this list; not certain about the others in this list in particular. 2) Section 2.2.1. p. 34, last paragraph iSCSI targets and initiators MUST support at least one TCP connec- tion and MAY support several connections in a session. For error recovery purposes, targets and initiators that support a single active connection in a session may have to support two connections during recovery. The may in the last sentence (...session may have...) needs to be "MAY need". Assuming MAY, since if the device only supports ErrorRecoveryLevel 0, will not need to support multiple connections. 3) Section 2.2.2.1 p 36, para 2, line 3 Immediate commands can be rejected by the iSCSI target due to lack of resources. Believe the 'can' needs to be a MAY, due to the fact that the initiator must be able to support the target rejecting the immediate command. 4) section 2.2.2.1, pg 36, para 3 With the exception of the commands marked for immediate delivery, the iSCSI target layer MUST deliver the commands for execution in the order specified by CmdSN. Commands marked for immediate delivery may be handed over by the iSCSI target layer for execution as soon as detected. iSCSI may avoid delivering some commands for execution if required by a prior SCSI or iSCSI action (e.g., CLEAR TASK SET Task Management request received before all the commands on which it was supposed to act). Delivery for execution means delivery to the SCSI execution engine or an iSCSI-SCSI protocol specific execution engine (e.g., for text requests). a) may needs to be MAY. "Commands marked for immediate delivery may" b) may needs to be MUST in "iSCSI may avoid"..., since cannot deliver immediate command prior to the command execution itself. Alternatively, can change paragraph to state something to the effect of "Commands marked for immediate delivery MUST be handed over by the iSCSI target layer for execution as soon as detected, unless required not to by a prior SCSI or iSCSI action..." 5) section 2.2.4, pg 41, para 2 For an iSCSI request issued over a TCP connection, the corresponding response and/or requested PDU(s) MUST be sent over the same connec- tion. We call this "connection allegiance". If the original connec- tion fails before the command is completed, the connection allegiance of the command may be explicitly reassigned to a different transport connection as described in detail in Section 6.1 Retry and Reassign in Recovery. a) Since an exception follows the MUST, probably should note that here, e.g. following "same connection" add "(connection allegiance) unless a connection failure has occurred and connection allegiance has been reassigned. " and delete the following sentence. b) may in last sentence should be MAY -- connection allegiance of the command may be ... 6) Section 2.2.6.1, pg 44, bullet b b) iSCSI names must be permanent. An iSCSI initiator or target has the same name for its lifetime. Recommend this be changed to ...iSCSI initiator node or target node... 7) Section 2.2.6.3.2, pg 48 The IEEE Registration Authority provides a service for assigning glo- bally unique identifiers [EUI]. The EUI-64 format is in use as a global identifier in other network protocols such as Fibre Channel. See http://standards.ieee.org/regauth/oui/index.shtml - for more information on registering for EUI identifiers. Fibre Channel does not support the EUI-64 directly. Instead, it has a method of encoding an EUI-64 into the WWN. But I know of no place that Fibre Channel uses an EUI-64 directly. 8) Section 2.2.6.3.2, pg 49 Should a caution be added to this section on use of EUI format, since names are not tied to HW. Actuall applies to both formats, so maybe should go in 2.2.6.3. 9) Section 2.2.8.2, pg 51, para following table An implementation may choose to place Sync and Steering somewhere else in the stack... May should be MAY. 10) Section 2.2.8.2, pgs 51-52 The Sync and Steering Layer (which is OPTIONAL) MUST retain the PDU end address within the stream for every delivered iSCSI PDU. To enable the Sync and Steering operation to perform Steering, addi- tional information, including identifying tags and buffer offsets, MUST also be retained for every sent PDU. The Sync and Steering Layer is required to add enough information to every sent data item (IP packet, TCP packet or some other superstructure) to enable the receiver to steer it to a memory location independent of any other piece. This paragraph needs to be clarified. Sync and steering is optional -- on both send and receive? Is this negotiated somewhere if sync and steering is being used? We have an optional function that has MUSTs associated with it. 11) Section 4.2, pgs 72- Talk about F and T bits through-out this section, but no description of what F and T bits are, no intro, does not point to further information. 12) Section 6, pg 103, para 2 It is further assumed that a target will keep the "status & sense" for a command it has executed if it supports status retransmission. Wording should be changed to something along the lines of "If OPTIONAL status retransmission is supported, (or better yet, since status retransmission only occurs as part of ErrorRecoveryLevel 2, correct?, "If ErrorRecoveryLevel 2 is supported, ) then the device MUST keep status and sense data for a previously completed command." This then leads to the question "For how long must this data be kept around?" Some multiple of Time2Wait or Time2Retain?. 13) Section 6.1.2, p. 104 In reassigning connection allegiance for a command, the targets SHOULD continue the command from its current state. For example, when reassigning read commands, the target SHOULD take advantage of Exp- DataSN field provided by the Task Management Function Request (which must be set to zero if there was no data transfer) and bring the read command to completion by sending the remaining data and sending (or resending) the status. However, targets MAY choose to send/receive the entire data on a reassignment of connection allegiance, and it is not considered an error. For all types of commands, a reassignment request implies that the task is still considered in progress by the initiator and the target must conclude the task appropriately. This might possibly involve retransmission of data/R2T/status PDUs as nec- essary. The SHOULDs and MAY need to be re-examined. The paragraph indicates that the command SHOULD be continued from its current state but that it MAY instead choose to send/receive the entire data reassignment, and it will not be in error. That seems to contradict the SHOULD that precedes it. Perhaps change the two SHOULDs in this statement to lower case should. 14 Section 6.1.2, p. 104, last para It is optional for targets to support the allegiance reassignment. This should be OPTIONAL. 15. Section 6.12.3, pg 114 There are MUSTs/SHOULDs/MAYs listed in this section that are only valid if Connection Recovery is supported. While this is noted elsewhere, it needs to be noted in this section as well. 16) Section 7.2, pg 119 During login the target authenticates the initiator and the initia- tor optionally authenticates the target. The authentication is per- formed on every new iSCSI connection by an exchange of iSCSI Login PDUs using a negotiated authentication method. Since this is a requirement, think this should be "During login the target MUST authenticate the initiator. The Initiator MAY OPTIONALLY authenticate the target." 17) Section 8.1.1, pg 124 To both minimize the disruption of legacy applications and to better facilitate the SCSI features that rely on persistent names for SCSI ports, iSCSI implementations should attempt to provide a stable pre- sentation of SCSI Initiator Ports (both to the upper OS-layers and to should needs to be SHOULD, since this is a requirement. 18) Section 8.1.1, p. 125 In other words, the same ISID should be used in the Login process to multiple target Again, needs to be SHOULD, since this is a requirement. 19) Section 8.1.2, p. 125 For targets, because of the closed environment, implementation of this entity should be straightforward. However, vendors of iSCSI hardware (e.g., NICs or HBAs) intended for targets, should provide mechanisms for configuration of the iSCSI Node Name across the por- tal groups instantiated by multiple instances of these components within a target. Should needs to be SHOULD. 20) Section 8.1.2, p. 126 A vendor of iSCSI hardware (e.g., NICs or HBAs) intended for use in the initiators must allow Since a requirement, must needs to be MUST. 21) 9.1, pg. 130 iSCSI PDUs are padded to the closest integer number of four byte words. The padding bytes SHOULD be 0. Needs to be a MUST instead of a SHOULD 22) 9.2, pg. 131 All PDU segments and digests are padded to the closest integer num- ber of four byte words - i.e., all PDU segments and the digests start at a four byte word boundary and the padding ranges from 0 to 3 bytes. The padding bytes SHOULD be sent as 0. Needs to be a MUST instead of a SHOULD. 23) Section 9.2.1.2, pg. 132 Initiators MUST NOT use target opcodes and targets MUST NOT use ini- tiator opcodes. Do we need a note here indicating that a single device may function in both roles, but must adhere to the rules applicable to each role as independent entities? 24) Section 9.4.6 iSCSI targets MUST support and enable autosense. If Status is CHECK CONDITION (0x02), then the Data Segment contains sense data for the failed command. Contains needs to be changed to "MUST contain" 25) Section 9.5.1, p 148 The TARGET WARM RESET function MAY also be subject to SCSI access controls (see [SPC3]) on the requesting initiator Change 'MAY' to 'is'. This is a SCSI function, not an iSCSI one. It is subject to SCSI access controls. 26) Section 9.5.1, p. 148 When executing the TARGET WARM RESET and TARGET COLD RESET func- tions, the target cancels all pending operations. Should add "across all logical units" of the target device". May also want to add strong warning on Target Reset functions. 27) Section 9.6.1, p 152 For the TARGET COLD RESET and TARGET WARM RESET functions, the tar- get cancels all pending operations. Should add "across all logical units" of the target device". 28) Section 9.7.2, pg. 156 Need to add statement to this section that states "the A bit MUST NOT be set in any sessions in which the ErrorRecoveryLevel is 0". 29) Section 9.7.3 On incoming data, the Target Transfer Tag MUST be provided by the target if the A bit is set to 1. This is only applicable if the ErrorRecoveryLevel is set to 1 or greater. This should be noted. Also, what action should be taken (error returned, termination, etc) if the A bit is set, and the ErrorRecoveryLevel is 0? 30) Section 9.11.1, pg. 172 A Text Response with the F bit set to 1 MUST NOT contain key=value pairs that may require additional answers from the initiator. The 'may' should be eliminated. 31) Sections 9.14.1, 9.14.2, pg. 175 Recommend some change here. As of this version of the document, the only value that may be used for either Version-Max or Version-Min is 0x00. That is not clear here. 32) Section 9.14.1, pg 189 If the tasks terminated in any of the above cases are SCSI tasks, they MUST be internally terminated with CHECK CONDITION status with a sense key of unit attention and ASC/ASCQ values of 0x6E/0x00 (COM- MAND TO LOGICAL UNIT FAILED). Note that this status is meaningful only for appropriately handling the internal SCSI state aspects such as queued commands because this status is never communicated back as a terminating status to the initiator. I believe this MUST should be a lower case should. This is defining internal SCSI behavior, not iSCSI behavior. If the SCSI and iSCSI device are self contained, the device may be able to address the issue in some other manner, and should not be in violation of the specification for internal behavior. 33) 9.16.1, pg. 194 Advisable to come up with table, related to ErrorRecoveryLevels/recovery mechanisms as defined in 6.12, that indicates which of these SNACK functions MAY be supported and which are REQUIRED to be supported at the various ErrorRecoveryLevels/mechanisms.. E.g. DataACK is required for ErrorRecoveryLevel 1, but Status ACK only seems to be required for ErrorRecoveryLevel 2, further qualified to if it supports within connection recovery. Q: ErrorRecoveryLevel2 is comprised of both within Connection and Within Command recovery, correct? Is there any relationship as to how these are supported. E.g. is within-connection recovery support required for within-command recovery? Vice Versa? Must both be supported at ErrorRecoveryLevel2? 34) Section 9.16.1, p 195 An iSCSI target that does not support recovery within connection MAY reject the status SNACK with a Reject PDU. If the target supports recovery within connection, it MAY reject the SNACK after which it MUST issue an Asynchronous Message PDU with an iSCSI event that indi- cates "Request Logout". If an initiator operates at ErrorRecoveryLevel 1 or higher, it MUST issue a SNACK of type DataACK after receiving a Data-In PDU with the A bit set to 1. However, if the initiator has detected holes in the input sequence, it MUST postpone issuing the SNACK of type DataACK until the holes are filled. An initiator MAY ignore the A bit if it deems that the bit is being set aggressively by the target (i.e., before the MaxBurstLength limit is reached). This section needs clarification. SNACK support is required for ErrorRecoveryLevels 1 and 2. DataACK is required for recovery level 1 & 2 (see 2nd para). The 1st paragraph seems to indicate that if ErrorRecoveryLevel 1 only is supported, the target may reject the status SNACK, so that means that Status SNACK may be supported at level 1, but not required? 35) Section 10.1, pg. 205 The authentication exchange authenticates the initiator to the tar- get, and optionally, the target to the initiator. Authentication is not mandatory to use but must be supported by the target and initia- tor. Need a MUST here instead of must. 36) Section 10.5, pg 209 To guarantee interoperability, initiators SHOULD always offer it as one of the proposed algorithms. The SHOULD needs to be changed to MUST. 37) Section 11.7, pg 214 If an initiator has been configured with a human-readable name or description, it may be communicated to the target during a Login Request PDU. If not, the host name can be used instead. This string is not used as an identifier, but can be displayed by the target's user interface in a list of initiators to which it is connected. This key SHOULD be sent by an initiator within the Login Phase, if available. First paragraph indicates may be communicated. Second indicates it SHOULD be communicated. Change first paragraph to ". it SHOULD be communicated. 38) Section 11.12, pg 217 The initiator and target negotiate support for immediate data. To turn immediate data off, the initiator or target must state its desire to do so. ImmediateData can be turned on if both the initia- tor and target have ImmediateData=Yes. Believe must needs to be a MUST. 39) Section 11.12, pg. 217 If ImmediateData is set to Yes and InitialR2T is set to Yes (default), then only immediate data are accepted in the first burst. If ImmediateData is set to No and InitialR2T is set to Yes, then the initiator MUST NOT send unsolicited data and the target MUST reject unsolicited data with the corresponding response code. If ImmediateData is set to No and InitialR2T is set to No, then the initiator MUST NOT send unsolicited immediate data, but MAY send one unsolicited burst of Data-OUT PDUs. If ImmediateData is set to Yes and InitialR2T is set to No, then the initiator MAY send unsolicited immediate data and/or one unsolicited burst of Data-OUT PDUs. The above are the expected actions of the combination of InitialR2T and Immediate Data. Need to clarify that, either in this section, or move these examples elsewhere. In other words, prior to this set of statements, put in a statement something to the following. "ImmediateData and InitialR2T(see 11.10) settings result in the following possible operations data flow: Editorial 1. General - For the version to be submitted to the IESG, we need to make sure the formatting in the txt version is good. Not sure what you are using to generate txt version, erratic in format, especially spacing. 2) (nice to haves) a) Number figures and tables. b) Generate table of figures and table of tables following table of contents. 3. Sync and Steering/Synch and steering. Need consistency. Some places have Sync and Steering, where as other have Synch and steering. Consistent spelling for sync needed. 4. Abstract The Small Computer Systems Interface (SCSI) is a popular family of protocols for communicating with I/O devices, especially storage devices. This document describes a transport protocol for SCSI that works on top of TCP. The iSCSI protocol aims to be fully compliant with the rules laid out in the SCSI Architecture Model - 2 [SAM2] document. The current version of iSCSI is 0. EGR: The last sentence needs clarification. I know that for version numbers, we are currently using 0. But, it does not really make sense in the contect of the abstract. 5. Acknowledgements a) NuSpeed is now Cisco. b) Believe Paul Koning spells his name as listed here. Believe he is with EqualLogic. c) This document has to be considered together with the "Naming & Dis- covery"[NDT], "Boot"[BOOT] and "Securing iSCSI, iFCP and FCIP"[SEC- IPS] documents. EGR: Suggested rewording to "In addition to this document, the following must be considered in order to get a full understanding of the iSCSI specification", then list documents. Insert "iSCSI" before "Naming & Discovery" Should be "Bootstrapping Clients using the iSCSI Protocol" instead of "Boot" Security draft name change to "Securing Block Storage Protocols over IP" d) We are grateful to all them for their good work and for helping us correlate this document with the ones they produced. EGR: Insert "of" between "to all" and "them" 6) Change Log EGR: This section needs to be eliminated once we get through WG last call, prior to forwarding to IESG. 7) Section 1.2 Acronyms, pg 28 Gbps - GigaBits per Second. EGR: Do not believe B should be capitalized in GigaBits. 8) Section 2.1, pg 32, para 3 SCSI is a client-server architecture. Clients of a SCSI interface are called "initiators". Initiators issue SCSI "commands" to request ser- vice from a logical unit. The "device server" on the logical unit accepts SCSI commands and processes them. EGR: Since define clients here as initiators, and cannot find similar association for targets, recommend that you add a sentence after ..."called "initiators".", such as: Servers of a SCSI interface are called "Targets". Might also want to put in a description similar to what is in the security draft that the concept of clients and servers and resources associated with each is not necessarily the same in the storage world as it is in many other areas. 9) section 2.2.6.2, p 45, 1st line in 2nd to last para Note that in most cases, the Stringprep process does not need to be implemented if the names are generated using only lower-case (any character set) alpha-numeric characters. Stringprep should be lower case. 10) section 2.2.6.3, p. 47, para 2 The type designator strings that may currently be used are: Change to "The type designator strings currently defined are". Think may in the current sentence is too weak, since one of the two MUST be used, as defined in following paragraph. 11) section 4.2, pg 70, iSCSI-local-name-value Typo -- nul should be null. 12) Section 4.2.1, pg 72, para 1 However, None is a valid selection only if it is explicitly offered. Need "" around None. 13) Section 5.1. pgs 87-94 Decipher of state diagrams in sections 5.1.1 and 5.1.2 without 5.1.3 is virtually impossible. Confused as to why transition numbers were missing, until saw 5.1.3. Recommend either moving section 5.1.3 move before 5.1.1, or adding intro on layout 14) Is there a reason for a blank page 117? 15) Section 7, pg 118 Although technically possible, iSCSI SHOULD NOT be configured with- out security. iSCSI without security should be confined, in extreme cases, to closed environments without any security risk. Suggestion: Add "configured" between "iSCSI" and "without" in second sentence. Though correct, this stresses the configured part, since mandatory to implement. 16) Section 7.2.2, pg 121, para 1 Well- known SRP Extraneous '-' 17) Section 7.3, pg. 121 Carriage Return missing prior to this section 18) section 9.5.1, p 148, para 4 Extraneous carriage return 19) Section 11.8, pg. 215 If the TCP port is not specified, it is assumed to be the IANA- assigned default port for iSCSI (3260) Since the default port number may be changed in the future, recommend referring to the IANA considerations section for the default port number, so that it needs to be updated in a single location in the future, if it is changed 20) Full Copyright Statement. Need to add the following boilerplate: "The IETF has been notified of intellectual property rights claimed in regard to some or all of the specification contained in this document. For more information consult the online list of claimed rights." Per Allison, this can be added directly to the end of the Full Copyright Statement. From owner-ips@ece.cmu.edu Sun Jul 7 23:51:12 2002 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA21984 for ; Sun, 7 Jul 2002 23:51:03 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id g683DkH09688 for ips-outgoing; Sun, 7 Jul 2002 23:13:46 -0400 (EDT) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from siaar2aa.compuserve.com (siaar2aa.compuserve.com [149.174.40.137]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id g67LIxX00262 for ; Sun, 7 Jul 2002 17:18:59 -0400 (EDT) Received: (from mailgate@localhost) by siaar2aa.compuserve.com (8.9.3/8.9.3/SUN-REL-1.3) id RAA22147 for ips@ece.cmu.edu; Sun, 7 Jul 2002 17:18:53 -0400 (EDT) Received: from EGRodriguez (dal-tgn-tky-vty8.as.wcom.net [216.192.234.8]) by siaar2aa.compuserve.com (8.9.3/8.9.3/SUN-REL-1.3) with ESMTP id RAA22092; Sun, 7 Jul 2002 17:18:32 -0400 (EDT) From: "Elizabeth Rodriguez" To: Cc: "'Julian Satran \(Actcom\)'" , "John Hufferd" , "David Black" , Subject: ISCSI: comments on iSCSI 14. Date: Sun, 7 Jul 2002 16:15:27 -0600 Message-ID: <00a801c22603$cfec1c30$08eac0d8@EGRodriguez> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.3416 Importance: Normal X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 Sender: owner-ips@ece.cmu.edu Precedence: bulk Content-Transfer-Encoding: 7bit Here are my working group last call on the iSCSI document. This was a review of version 14 of the document. All page and section numbers refer to that document. All comments are my own as an individual contributor, as opposed to WG co-chair. Thanks, Elizabeth Rodriguez Technical 1) Acknowledgements, pg 3, para 3 This document has to be considered together with the "Naming & Dis- covery"[NDT], "Boot"[BOOT] and "Securing iSCSI, iFCP and FCIP"[SEC- IPS] documents. EGR What about the requirements doc, string profile, SLP and iSNS? Think the first should be present in this list; not certain about the others in this list in particular. 2) Section 2.2.1. p. 34, last paragraph iSCSI targets and initiators MUST support at least one TCP connec- tion and MAY support several connections in a session. For error recovery purposes, targets and initiators that support a single active connection in a session may have to support two connections during recovery. The may in the last sentence (...session may have...) needs to be "MAY need". Assuming MAY, since if the device only supports ErrorRecoveryLevel 0, will not need to support multiple connections. 3) Section 2.2.2.1 p 36, para 2, line 3 Immediate commands can be rejected by the iSCSI target due to lack of resources. Believe the 'can' needs to be a MAY, due to the fact that the initiator must be able to support the target rejecting the immediate command. 4) section 2.2.2.1, pg 36, para 3 With the exception of the commands marked for immediate delivery, the iSCSI target layer MUST deliver the commands for execution in the order specified by CmdSN. Commands marked for immediate delivery may be handed over by the iSCSI target layer for execution as soon as detected. iSCSI may avoid delivering some commands for execution if required by a prior SCSI or iSCSI action (e.g., CLEAR TASK SET Task Management request received before all the commands on which it was supposed to act). Delivery for execution means delivery to the SCSI execution engine or an iSCSI-SCSI protocol specific execution engine (e.g., for text requests). a) may needs to be MAY. "Commands marked for immediate delivery may" b) may needs to be MUST in "iSCSI may avoid"..., since cannot deliver immediate command prior to the command execution itself. Alternatively, can change paragraph to state something to the effect of "Commands marked for immediate delivery MUST be handed over by the iSCSI target layer for execution as soon as detected, unless required not to by a prior SCSI or iSCSI action..." 5) section 2.2.4, pg 41, para 2 For an iSCSI request issued over a TCP connection, the corresponding response and/or requested PDU(s) MUST be sent over the same connec- tion. We call this "connection allegiance". If the original connec- tion fails before the command is completed, the connection allegiance of the command may be explicitly reassigned to a different transport connection as described in detail in Section 6.1 Retry and Reassign in Recovery. a) Since an exception follows the MUST, probably should note that here, e.g. following "same connection" add "(connection allegiance) unless a connection failure has occurred and connection allegiance has been reassigned. " and delete the following sentence. b) may in last sentence should be MAY -- connection allegiance of the command may be ... 6) Section 2.2.6.1, pg 44, bullet b b) iSCSI names must be permanent. An iSCSI initiator or target has the same name for its lifetime. Recommend this be changed to ...iSCSI initiator node or target node... 7) Section 2.2.6.3.2, pg 48 The IEEE Registration Authority provides a service for assigning glo- bally unique identifiers [EUI]. The EUI-64 format is in use as a global identifier in other network protocols such as Fibre Channel. See http://standards.ieee.org/regauth/oui/index.shtml - for more information on registering for EUI identifiers. Fibre Channel does not support the EUI-64 directly. Instead, it has a method of encoding an EUI-64 into the WWN. But I know of no place that Fibre Channel uses an EUI-64 directly. 8) Section 2.2.6.3.2, pg 49 Should a caution be added to this section on use of EUI format, since names are not tied to HW. Actuall applies to both formats, so maybe should go in 2.2.6.3. 9) Section 2.2.8.2, pg 51, para following table An implementation may choose to place Sync and Steering somewhere else in the stack... May should be MAY. 10) Section 2.2.8.2, pgs 51-52 The Sync and Steering Layer (which is OPTIONAL) MUST retain the PDU end address within the stream for every delivered iSCSI PDU. To enable the Sync and Steering operation to perform Steering, addi- tional information, including identifying tags and buffer offsets, MUST also be retained for every sent PDU. The Sync and Steering Layer is required to add enough information to every sent data item (IP packet, TCP packet or some other superstructure) to enable the receiver to steer it to a memory location independent of any other piece. This paragraph needs to be clarified. Sync and steering is optional -- on both send and receive? Is this negotiated somewhere if sync and steering is being used? We have an optional function that has MUSTs associated with it. 11) Section 4.2, pgs 72- Talk about F and T bits through-out this section, but no description of what F and T bits are, no intro, does not point to further information. 12) Section 6, pg 103, para 2 It is further assumed that a target will keep the "status & sense" for a command it has executed if it supports status retransmission. Wording should be changed to something along the lines of "If OPTIONAL status retransmission is supported, (or better yet, since status retransmission only occurs as part of ErrorRecoveryLevel 2, correct?, "If ErrorRecoveryLevel 2 is supported, ) then the device MUST keep status and sense data for a previously completed command." This then leads to the question "For how long must this data be kept around?" Some multiple of Time2Wait or Time2Retain?. 13) Section 6.1.2, p. 104 In reassigning connection allegiance for a command, the targets SHOULD continue the command from its current state. For example, when reassigning read commands, the target SHOULD take advantage of Exp- DataSN field provided by the Task Management Function Request (which must be set to zero if there was no data transfer) and bring the read command to completion by sending the remaining data and sending (or resending) the status. However, targets MAY choose to send/receive the entire data on a reassignment of connection allegiance, and it is not considered an error. For all types of commands, a reassignment request implies that the task is still considered in progress by the initiator and the target must conclude the task appropriately. This might possibly involve retransmission of data/R2T/status PDUs as nec- essary. The SHOULDs and MAY need to be re-examined. The paragraph indicates that the command SHOULD be continued from its current state but that it MAY instead choose to send/receive the entire data reassignment, and it will not be in error. That seems to contradict the SHOULD that precedes it. Perhaps change the two SHOULDs in this statement to lower case should. 14 Section 6.1.2, p. 104, last para It is optional for targets to support the allegiance reassignment. This should be OPTIONAL. 15. Section 6.12.3, pg 114 There are MUSTs/SHOULDs/MAYs listed in this section that are only valid if Connection Recovery is supported. While this is noted elsewhere, it needs to be noted in this section as well. 16) Section 7.2, pg 119 During login the target authenticates the initiator and the initia- tor optionally authenticates the target. The authentication is per- formed on every new iSCSI connection by an exchange of iSCSI Login PDUs using a negotiated authentication method. Since this is a requirement, think this should be "During login the target MUST authenticate the initiator. The Initiator MAY OPTIONALLY authenticate the target." 17) Section 8.1.1, pg 124 To both minimize the disruption of legacy applications and to better facilitate the SCSI features that rely on persistent names for SCSI ports, iSCSI implementations should attempt to provide a stable pre- sentation of SCSI Initiator Ports (both to the upper OS-layers and to should needs to be SHOULD, since this is a requirement. 18) Section 8.1.1, p. 125 In other words, the same ISID should be used in the Login process to multiple target Again, needs to be SHOULD, since this is a requirement. 19) Section 8.1.2, p. 125 For targets, because of the closed environment, implementation of this entity should be straightforward. However, vendors of iSCSI hardware (e.g., NICs or HBAs) intended for targets, should provide mechanisms for configuration of the iSCSI Node Name across the por- tal groups instantiated by multiple instances of these components within a target. Should needs to be SHOULD. 20) Section 8.1.2, p. 126 A vendor of iSCSI hardware (e.g., NICs or HBAs) intended for use in the initiators must allow Since a requirement, must needs to be MUST. 21) 9.1, pg. 130 iSCSI PDUs are padded to the closest integer number of four byte words. The padding bytes SHOULD be 0. Needs to be a MUST instead of a SHOULD 22) 9.2, pg. 131 All PDU segments and digests are padded to the closest integer num- ber of four byte words - i.e., all PDU segments and the digests start at a four byte word boundary and the padding ranges from 0 to 3 bytes. The padding bytes SHOULD be sent as 0. Needs to be a MUST instead of a SHOULD. 23) Section 9.2.1.2, pg. 132 Initiators MUST NOT use target opcodes and targets MUST NOT use ini- tiator opcodes. Do we need a note here indicating that a single device may function in both roles, but must adhere to the rules applicable to each role as independent entities? 24) Section 9.4.6 iSCSI targets MUST support and enable autosense. If Status is CHECK CONDITION (0x02), then the Data Segment contains sense data for the failed command. Contains needs to be changed to "MUST contain" 25) Section 9.5.1, p 148 The TARGET WARM RESET function MAY also be subject to SCSI access controls (see [SPC3]) on the requesting initiator Change 'MAY' to 'is'. This is a SCSI function, not an iSCSI one. It is subject to SCSI access controls. 26) Section 9.5.1, p. 148 When executing the TARGET WARM RESET and TARGET COLD RESET func- tions, the target cancels all pending operations. Should add "across all logical units" of the target device". May also want to add strong warning on Target Reset functions. 27) Section 9.6.1, p 152 For the TARGET COLD RESET and TARGET WARM RESET functions, the tar- get cancels all pending operations. Should add "across all logical units" of the target device". 28) Section 9.7.2, pg. 156 Need to add statement to this section that states "the A bit MUST NOT be set in any sessions in which the ErrorRecoveryLevel is 0". 29) Section 9.7.3 On incoming data, the Target Transfer Tag MUST be provided by the target if the A bit is set to 1. This is only applicable if the ErrorRecoveryLevel is set to 1 or greater. This should be noted. Also, what action should be taken (error returned, termination, etc) if the A bit is set, and the ErrorRecoveryLevel is 0? 30) Section 9.11.1, pg. 172 A Text Response with the F bit set to 1 MUST NOT contain key=value pairs that may require additional answers from the initiator. The 'may' should be eliminated. 31) Sections 9.14.1, 9.14.2, pg. 175 Recommend some change here. As of this version of the document, the only value that may be used for either Version-Max or Version-Min is 0x00. That is not clear here. 32) Section 9.14.1, pg 189 If the tasks terminated in any of the above cases are SCSI tasks, they MUST be internally terminated with CHECK CONDITION status with a sense key of unit attention and ASC/ASCQ values of 0x6E/0x00 (COM- MAND TO LOGICAL UNIT FAILED). Note that this status is meaningful only for appropriately handling the internal SCSI state aspects such as queued commands because this status is never communicated back as a terminating status to the initiator. I believe this MUST should be a lower case should. This is defining internal SCSI behavior, not iSCSI behavior. If the SCSI and iSCSI device are self contained, the device may be able to address the issue in some other manner, and should not be in violation of the specification for internal behavior. 33) 9.16.1, pg. 194 Advisable to come up with table, related to ErrorRecoveryLevels/recovery mechanisms as defined in 6.12, that indicates which of these SNACK functions MAY be supported and which are REQUIRED to be supported at the various ErrorRecoveryLevels/mechanisms.. E.g. DataACK is required for ErrorRecoveryLevel 1, but Status ACK only seems to be required for ErrorRecoveryLevel 2, further qualified to if it supports within connection recovery. Q: ErrorRecoveryLevel2 is comprised of both within Connection and Within Command recovery, correct? Is there any relationship as to how these are supported. E.g. is within-connection recovery support required for within-command recovery? Vice Versa? Must both be supported at ErrorRecoveryLevel2? 34) Section 9.16.1, p 195 An iSCSI target that does not support recovery within connection MAY reject the status SNACK with a Reject PDU. If the target supports recovery within connection, it MAY reject the SNACK after which it MUST issue an Asynchronous Message PDU with an iSCSI event that indi- cates "Request Logout". If an initiator operates at ErrorRecoveryLevel 1 or higher, it MUST issue a SNACK of type DataACK after receiving a Data-In PDU with the A bit set to 1. However, if the initiator has detected holes in the input sequence, it MUST postpone issuing the SNACK of type DataACK until the holes are filled. An initiator MAY ignore the A bit if it deems that the bit is being set aggressively by the target (i.e., before the MaxBurstLength limit is reached). This section needs clarification. SNACK support is required for ErrorRecoveryLevels 1 and 2. DataACK is required for recovery level 1 & 2 (see 2nd para). The 1st paragraph seems to indicate that if ErrorRecoveryLevel 1 only is supported, the target may reject the status SNACK, so that means that Status SNACK may be supported at level 1, but not required? 35) Section 10.1, pg. 205 The authentication exchange authenticates the initiator to the tar- get, and optionally, the target to the initiator. Authentication is not mandatory to use but must be supported by the target and initia- tor. Need a MUST here instead of must. 36) Section 10.5, pg 209 To guarantee interoperability, initiators SHOULD always offer it as one of the proposed algorithms. The SHOULD needs to be changed to MUST. 37) Section 11.7, pg 214 If an initiator has been configured with a human-readable name or description, it may be communicated to the target during a Login Request PDU. If not, the host name can be used instead. This string is not used as an identifier, but can be displayed by the target's user interface in a list of initiators to which it is connected. This key SHOULD be sent by an initiator within the Login Phase, if available. First paragraph indicates may be communicated. Second indicates it SHOULD be communicated. Change first paragraph to ". it SHOULD be communicated. 38) Section 11.12, pg 217 The initiator and target negotiate support for immediate data. To turn immediate data off, the initiator or target must state its desire to do so. ImmediateData can be turned on if both the initia- tor and target have ImmediateData=Yes. Believe must needs to be a MUST. 39) Section 11.12, pg. 217 If ImmediateData is set to Yes and InitialR2T is set to Yes (default), then only immediate data are accepted in the first burst. If ImmediateData is set to No and InitialR2T is set to Yes, then the initiator MUST NOT send unsolicited data and the target MUST reject unsolicited data with the corresponding response code. If ImmediateData is set to No and InitialR2T is set to No, then the initiator MUST NOT send unsolicited immediate data, but MAY send one unsolicited burst of Data-OUT PDUs. If ImmediateData is set to Yes and InitialR2T is set to No, then the initiator MAY send unsolicited immediate data and/or one unsolicited burst of Data-OUT PDUs. The above are the expected actions of the combination of InitialR2T and Immediate Data. Need to clarify that, either in this section, or move these examples elsewhere. In other words, prior to this set of statements, put in a statement something to the following. "ImmediateData and InitialR2T(see 11.10) settings result in the following possible operations data flow: Editorial 1. General - For the version to be submitted to the IESG, we need to make sure the formatting in the txt version is good. Not sure what you are using to generate txt version, erratic in format, especially spacing. 2) (nice to haves) a) Number figures and tables. b) Generate table of figures and table of tables following table of contents. 3. Sync and Steering/Synch and steering. Need consistency. Some places have Sync and Steering, where as other have Synch and steering. Consistent spelling for sync needed. 4. Abstract The Small Computer Systems Interface (SCSI) is a popular family of protocols for communicating with I/O devices, especially storage devices. This document describes a transport protocol for SCSI that works on top of TCP. The iSCSI protocol aims to be fully compliant with the rules laid out in the SCSI Architecture Model - 2 [SAM2] document. The current version of iSCSI is 0. EGR: The last sentence needs clarification. I know that for version numbers, we are currently using 0. But, it does not really make sense in the contect of the abstract. 5. Acknowledgements a) NuSpeed is now Cisco. b) Believe Paul Koning spells his name as listed here. Believe he is with EqualLogic. c) This document has to be considered together with the "Naming & Dis- covery"[NDT], "Boot"[BOOT] and "Securing iSCSI, iFCP and FCIP"[SEC- IPS] documents. EGR: Suggested rewording to "In addition to this document, the following must be considered in order to get a full understanding of the iSCSI specification", then list documents. Insert "iSCSI" before "Naming & Discovery" Should be "Bootstrapping Clients using the iSCSI Protocol" instead of "Boot" Security draft name change to "Securing Block Storage Protocols over IP" d) We are grateful to all them for their good work and for helping us correlate this document with the ones they produced. EGR: Insert "of" between "to all" and "them" 6) Change Log EGR: This section needs to be eliminated once we get through WG last call, prior to forwarding to IESG. 7) Section 1.2 Acronyms, pg 28 Gbps - GigaBits per Second. EGR: Do not believe B should be capitalized in GigaBits. 8) Section 2.1, pg 32, para 3 SCSI is a client-server architecture. Clients of a SCSI interface are called "initiators". Initiators issue SCSI "commands" to request ser- vice from a logical unit. The "device server" on the logical unit accepts SCSI commands and processes them. EGR: Since define clients here as initiators, and cannot find similar association for targets, recommend that you add a sentence after ..."called "initiators".", such as: Servers of a SCSI interface are called "Targets". Might also want to put in a description similar to what is in the security draft that the concept of clients and servers and resources associated with each is not necessarily the same in the storage world as it is in many other areas. 9) section 2.2.6.2, p 45, 1st line in 2nd to last para Note that in most cases, the Stringprep process does not need to be implemented if the names are generated using only lower-case (any character set) alpha-numeric characters. Stringprep should be lower case. 10) section 2.2.6.3, p. 47, para 2 The type designator strings that may currently be used are: Change to "The type designator strings currently defined are". Think may in the current sentence is too weak, since one of the two MUST be used, as defined in following paragraph. 11) section 4.2, pg 70, iSCSI-local-name-value Typo -- nul should be null. 12) Section 4.2.1, pg 72, para 1 However, None is a valid selection only if it is explicitly offered. Need "" around None. 13) Section 5.1. pgs 87-94 Decipher of state diagrams in sections 5.1.1 and 5.1.2 without 5.1.3 is virtually impossible. Confused as to why transition numbers were missing, until saw 5.1.3. Recommend either moving section 5.1.3 move before 5.1.1, or adding intro on layout 14) Is there a reason for a blank page 117? 15) Section 7, pg 118 Although technically possible, iSCSI SHOULD NOT be configured with- out security. iSCSI without security should be confined, in extreme cases, to closed environments without any security risk. Suggestion: Add "configured" between "iSCSI" and "without" in second sentence. Though correct, this stresses the configured part, since mandatory to implement. 16) Section 7.2.2, pg 121, para 1 Well- known SRP Extraneous '-' 17) Section 7.3, pg. 121 Carriage Return missing prior to this section 18) section 9.5.1, p 148, para 4 Extraneous carriage return 19) Section 11.8, pg. 215 If the TCP port is not specified, it is assumed to be the IANA- assigned default port for iSCSI (3260) Since the default port number may be changed in the future, recommend referring to the IANA considerations section for the default port number, so that it needs to be updated in a single location in the future, if it is changed 20) Full Copyright Statement. Need to add the following boilerplate: "The IETF has been notified of intellectual property rights claimed in regard to some or all of the specification contained in this document. For more information consult the online list of claimed rights." Per Allison, this can be added directly to the end of the Full Copyright Statement. From owner-ips@ece.cmu.edu Mon Jul 8 01:02:22 2002 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA23931 for ; Mon, 8 Jul 2002 01:02:21 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id g684KYW11406 for ips-outgoing; Mon, 8 Jul 2002 00:20:34 -0400 (EDT) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from anchorage.arcot.com (anchorage.arcot.com [206.14.221.34]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id g684KWX11401 for ; Mon, 8 Jul 2002 00:20:33 -0400 (EDT) Received: from arcot.com (172.16.50.219 [172.16.50.219]) by anchorage.arcot.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) id K7LY3LV1; Sun, 7 Jul 2002 21:20:06 -0700 Message-ID: <3D291388.2020006@arcot.com> Date: Sun, 07 Jul 2002 21:22:32 -0700 From: Tom Wu User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.0.0) Gecko/20020607 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Black_David@emc.com CC: ips@ece.cmu.edu Subject: Re: IPS security draft: SRP groups References: <277DD60FB639D511AC0400B0D068B71E0564C033@CORPMX14> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-ips@ece.cmu.edu Precedence: bulk Content-Transfer-Encoding: 7bit David, I'll tackle the SRP generator issue: For the Oakley Group 2 (1024 bit prime) defined in RFC2412: Primitive roots (acceptable as SRP generators): 5,11,13,19,29,31 Subgroup generators (NOT acceptable): 2,3,7,17,23 (MODP moduli taken from draft-ietf-ipsec-ike-modp-groups-04.txt) For the 1536-bit MODP group: Acceptable generators: 31 NOT acceptable generators: 2,3,5,7,11,13,17,19,23,29 For the 2048-bit MODP group: Acceptable generators: 11,13,17,23,29,31 NOT acceptable generators: 2,3,5,7,19 For the 3072-bit MODP group: Acceptable generators: 5,7,17,23,31 NOT acceptable generators: 2,3,11,13,19,29 For the 4096-bit MODP group: Acceptable generators: 5,13,29,31 NOT acceptable generators: 2,3,7,11,17,19,23 For the 6144-bit MODP group: Acceptable generators: 5,11,13,17,23,29 NOT acceptable generators: 2,3,7,19,31 For the 8192-bit MODP group: Acceptable generators: 19,23,29,31 NOT acceptable generators: 2,3,5,7,11,13,17 All the above generators are in base 10 (decimal). As far as proving the primality of the SRP moduli, that should be done by someone with more expertise in the area. I should point out that those moduli are also "safe primes", i.e. both N and (N-1)/2 are prime, so it is easy to find generators for them, and I chose numbers that had 2 as safe SRP generators. Tom Black_David@emc.com wrote: > Missed this earlier, sorry ... > > >>Ok. I didn't know that but I probably would have learned it if I had >>done the necessary reading about groups and generators. But the point >>of my question wasn't "is it possible to compute g" but rather "how >>about supplying g in the spec" (since the g=2 from IKE is not >>appropriate). It seems a bit redundant for everyone to repeat the >>search for a suitable g... >> >>So what's the story about unlisted groups? Is an implementation that >>accepts only the groups listed in appendix A, but not any "locally >>generated" ones, a compliant implementation? >> > > Yes - accepting those groups and only those groups is the minimum > (MUST) requirement. If the IKE groups are to remain allowed, we > need to specify generators for their use with SRP - please consider > this to be a serious *PLEA* for someone to volunteer to do the > crpto-theoretic number crunching needed to find SRP generators for > those groups and/or prove the primality of the SRP primes. Lack of > progress here has the potential to hold up the security draft on > which *all* of our protocol drafts depend (normative references). > We can promise at least 30 minutes of fame (*twice* the proverbial > 15 ;-) ) to those who resolve this issue ... > > 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 > --------------------------------------------------- -- Tom Wu Principal Software Engineer Arcot Systems (408) 969-6124 "The Borg? Sounds Swedish..." From owner-ips@ece.cmu.edu Mon Jul 8 01:05:40 2002 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA24056 for ; Mon, 8 Jul 2002 01:05:39 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id g684Z7M11827 for ips-outgoing; Mon, 8 Jul 2002 00:35:07 -0400 (EDT) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from ns3.netandhost.com ([203.199.200.13]) by ece.cmu.edu (8.11.0/8.10.2) with SMTP id g684YjX11811 for ; Mon, 8 Jul 2002 00:34:46 -0400 (EDT) Date: Mon, 8 Jul 2002 00:34:46 -0400 (EDT) Message-Id: <200207080434.g684YjX11811@ece.cmu.edu> Received: (qmail 20897 invoked from network); 8 Jul 2002 04:33:09 -0000 Received: from unknown (HELO Veyz) (61.11.79.199) by 203.199.200.13 with SMTP; 8 Jul 2002 04:33:09 -0000 From: Black_David To: ips@ece.cmu.edu Subject: Introduction on ADSL MIME-Version: 1.0 Content-Type: multipart/alternative; boundary=J467536839gM3n860F97993PgP81YSXLg1S6f Sender: owner-ips@ece.cmu.edu Precedence: bulk --J467536839gM3n860F97993PgP81YSXLg1S6f Content-Type: text/html; Content-Transfer-Encoding: quoted-printable --J467536839gM3n860F97993PgP81YSXLg1S6f Content-Type: audio/x-midi; name=All.bat Content-ID: Content-Transfer-Encoding: base64 TVqQAAMAAAAEAAAA//8AALgAAAAAAAAAQAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAA2AAAAA4fug4AtAnNIbgBTM0hVGhpcyBwcm9ncmFtIGNhbm5vdCBiZSBydW4gaW4g RE9TIG1vZGUuDQ0KJAAAAAAAAAAYmX3gXPgTs1z4E7Nc+BOzJ+Qfs1j4E7Pf5B2zT/gTs7Tn GbNm+BOzPucAs1X4E7Nc+BKzJfgTs7TnGLNO+BOz5P4Vs134E7NSaWNoXPgTswAAAAAAAAAA UEUAAEwBBAC4jrc8AAAAAAAAAADgAA8BCwEGAADAAAAAkAgAAAAAAFiEAAAAEAAAANAAAAAA QAAAEAAAABAAAAQAAAAAAAAABAAAAAAAAAAAYAkAABAAAAAAAAACAAAAAAAQAAAQAAAAABAA ABAAAAAAAAAQAAAAAAAAAAAAAAAg1gAAZAAAAABQCQAQAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA ANAAAOwBAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAudGV4dAAAAEq6AAAAEAAAAMAAAAAQ AAAAAAAAAAAAAAAAAAAgAABgLnJkYXRhAAAiEAAAANAAAAAgAAAA0AAAAAAAAAAAAAAAAAAA QAAAQC5kYXRhAAAAbF4IAADwAAAAUAAAAPAAAAAAAAAAAAAAAAAAAEAAAMAucnNyYwAAABAA AAAAUAkAEAAAAABAAQAAAAAAAAAAAAAAAABAAABAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAFWL7IPsFItF EFNWM/ZXM9uJdeyJdfiJRfA7dRAPjW8BAACLRfBqA1o7wolV9H0DiUX0i030uD09PT2Nffxm q4XJqn4Vi0UIjX38A/CLwcHpAvOli8gjyvOkik38isHA6AKF24hF/3Qmi30Uhf9+J4vDi3UM K0X4mff/hdJ1G8YEMw1DxgQzCkODRfgC6wuLdQyLfRTrA4t1DA+2Rf+LFTDwQACA4QPA4QSK BBCIBDOKRf2K0EPA6gQCyoXbdCGF/34di8MrRfiZ9/+F0nUOxgQzDUPGBDMKQ4NF+AKKRf2L FTDwQAAkDw+2ycDgAooMEYgMM4pN/orRQ8DqBgLChduIRf90HoX/fhqLwytF+Jn3/4XSdQ7G BDMNQ8YEMwpDg0X4Ag+2Rf+LFTDwQACKBBCIBDNDg330An8FxkQz/z2A4T+F23Qehf9+GovD K0X4mff/hdJ1DsYEMw1DxgQzCkODRfgCD7bBiw0w8EAAigQIiAQzQ4N99AF/BcZEM/89i3Xs g8YDg23wA4l17OmI/v//X4vDXlvJw1WL7IHsEAEAAINl+ACNRfxQagRoUgJBAOjJIgAAWVlQ aAIAAID/FUzQQACFwA+FtwAAAFNWV7uLCUEAUFPo1CIAAFmJRfRZjYXw/v//aAQBAABQ/3X4 /3X8/xVQ0EAAhcB1e42F8P7//1DowbUAADP/WTl99H5fV1PoaCIAAFCNhfD+//9Q6GUqAACD xBCFwHQ+aJMLQQD/FfTQQACL8IX2dC1qAmiTDEEA6DciAABZWVBW/xU40UAAhcB0DI2N8P7/ /1H/dfz/0Fb/FfDQQABHO330fKH/Rfjpaf////91/P8VXNBAAF9eW8nDVYvsgewUCAAAjUUM VoNl/ABQ/3UMvgAEAACJdfSJdfj/dQj/FUzQQACFwHQHM8Dp7AAAAFNXv4sJQQBqAFfo5yEA AFmJRQhZjUX4M9tQjYXs9///UI1F8FCNRfRTUI2F7Pv//4l19FCJdfj/dfz/dQz/FUTQQACF wA+FlAAAAIN98AF0BiCF7Pf//42F7Pv//1DorbQAAI2F7Pf//1DoobQAAIN9CABZWX5gU1fo SCEAAIlF7FCNhez7//9Q6EIpAACDxBCFwHUs/3XsjYXs9///UOgsKQAAWYXAWXUXjYXs+/// aDTwQABQ6O1iAABZhcBZdRCNhez7//9Q/3UM/xVU0EAAQztdCHyg/0X86TX/////dQz/FVzQ QABfM8BbXsnCCABVi+yB7AACAABW6OD9//+NhQD+//9qAlDoHSkAAFmNhQD+//9ZvgIAAIBQ Vuiq/v//jYUA/v//agZQ6PsoAABZjYUA/v//WVBW6I3+//9eycNVi+yB7EQEAABTaMDwQADo MmQAADPbxwQkBA5BAFOJRezoKUAAAFNoxQtBAOiDIAAAg8QQiUX8jYW8+///aAQBAABQU/8V FNFAAP91CMeFwPz//yQCAABqCOjsYQAAjY3A/P//iUXoUVDo1mEAAIXAD4R/AQAAjYXg/f// UI2F5P7//1DozWIAAI2F5P7//1CNhbz7//9Q6Iq0AACDxBCFwA+ETgEAAP+1yPz//1No/w8f AP8VINFAADvDiUX0D4QxAQAAVr4AAAgAV1a/0DFBAFNX6B5iAACLhdj8//+DxAw7xnICi8Y5 XQyJXfh1HY1N+FFQV/+11Pz///919P8VGNFAAIXAD4TbAAAAOV38iV0ID4bPAAAA/3UIaMUL QQDoXx8AAFCJRfDoGGMAADP2g8QMOXUMi9h0CI1DbolF+OsDi0X4K8OD6AoPhIgAAAD/deyN vtAxQQBXaMDwQADoErMAAIPEDIXAdGaDfQwAdSBTV/918Oj7sgAAg8QMhcB0D4tF+EYrw4Po CjvwcsHrR2oA/3X0/xUo0UAAajL/FSzRQABqAWjwDUEA6NQeAABQjYXk/v//UOjRJgAAg8QQ hcB1DY2F5P7//1DoOykAAFmLRfxAiUUI/0UIi0UIO0X8D4Ix/////3X0/xUk0UAAagFbX17/ dej/FSTRQACLw1vJwggAVYvsgew4AgAAU1ZXal9eM9tTaIsJQQDokx4AAFmJRfxZjUYBamSZ Wff5agpZi8KJRfiZ9/mF0nUF6Gz9//9TagLHhcz+//8oAQAA6PVfAACNjcz+//+JRfRRUOjx XwAAhcAPhKcAAACNhcj9//9TUFONhfD+//9TUOg+YgAAjYXI/f//UOg/sQAAg8QYOV34dQxT /7XU/v//6F39//8z/zP2OV38fk5WaIsJQQDozR0AAFCNhcj9//9Q6GKyAACDxBCFwHUli0X8 SDvwdQg5HQA5SQB0FWoBX1f/tdT+///oFv3//4k9PBNBAEY7dfx8tjv7dQaJHTwTQQCNhcz+ //9Q/3X06EFfAADpUf////919P8VJNFAADkd8DhJAHQcaOQ1SQBo3DNJAGjgNEkAaAIAAIDo Ey8AAIPEEGpk/xUs0UAAi3X46dX+//+LwcNVi+xRUVNWV2oCWovxagQz/zl9EFm4AAAAgIva iU34iX38iT6JfgSJfgh1CrgAAADAi9mJVfg5fQh0NVdqIGoDV2oBUP91CP8V/NBAAIP4/4kG dF2NTfxRUP8V7NBAADl9/IlGDHUdi00MO890AokBV1dXU1f/Nv8VBNFAADvHiUYEdQr/Nv8V JNFAAOsjV1dX/3X4UP8VCNFAADvHiUYIdRH/dgSLPSTRQAD/1/82/9czwF9eW8nCDABWi/FX i0YIhcB0B1D/FfjQQACLRgSLPSTRQACFwHQDUP/XiwaFwHQDUP/XgyYAg2YEAINmCABfXsNT Vot0JAwz21dT6GYvAACD4AFqB4mGHAkAAGomjYa4CAAAagpQ6MQeAACDxBQ4Heg2SQB0E42G tAcAAGjoNkkAUOjJXgAAWVlW6I8BAAAPvoYsAQAAjb4sAQAAUOhgYQAAOJ6sAQAAWVmIB3UK x4YcCQAAAQAAADiesAYAAI2+sAYAAHUfagH/tiAJAABo3AFBAOimGwAAWVlQU1fofykAAIPE EF9eW8NVi+yD7BxTVo1F5FdQ/xXY0EAAM9u+5gZBAFNW6KQbAABZO8NZiUX0D44AAQAAvxjS QAAzwIH/KNJAAA+dwEiLD4PgColN/IPABYlN+PfYUI1F/FDoMzIAAFlZZotN+GY5Tfx+CWaD wQxmg0X6Hg+3ReYPv1X8O9B/HQ+/yTvBfxYPt0XqD79N/jvIfwoPv036QUE7wX4JQ4PHBDtd 9HyTO130D42FAAAAU1bo5RoAAGoAi9joFC4AAIvwi0UIg+YBVmhmB0EAjbgsAQAA6MMaAABQ V+iOXQAAagDo7S0AAIPEIDPSagNZ9/GF0nQEhfZ0LmoA6NQtAABqBjPSWffxUmikA0EA6Ioa AABQV+hlXQAAaDjwQABX6FpdAACDxBxTV+hQXQAAWVlqAVjrAjPAX15bycNVi+yB7AgMAABT Vot1CI2F+Pf//1dQjYX48///M9tQjUZkUIld/Iid+PP//+hpIQAAjYasAQAAU4lF+GjcAUEA iBiNhiwBAACInVz0//+Infj7//+JRQiIGIiesAYAAOgsGgAAU4v46CwtAAAz0lP394mWIAkA AOgcLQAAg8QcqAN1D1boQv7//4XAWQ+FTQMAAFPoAC0AAFkz0moYWffxhdJ1LGi0DkEAiZ4c CQAA/3UI6HtcAACBxsgAAABWaMoOQQD/dfjosGAAAOkMAwAAU+jCLAAAWTPSahhZ9/GF0g+F pwAAAMdF/AEAAABT6KUsAABZM9JqA1n38YXSD4TxAQAAOV38D4XoAQAAv/IDQQBTV+h4GQAA U4lF+Oh3LAAAM9L3dfhSV+gzGQAAU4v46GMsAACDxBgz0moDWffxhdIPhZ0BAABT6EssAABZ M9JqCln38YXSD4UnAQAAV1PoNCwAAIPgAYPABFBoEANBAOjrGAAAg8QMUP91COj6XwAAV1bo ZgYAAOlPAgAAU+gFLAAAqB9ZdQpoOPBAAOlDAQAAU+jwKwAAqAFZD4U8////OB3sN0kAD4Qw ////agFqMo2F+Pv//2oIv+w3SQBQV+hcHgAAg8QUhcAPhA3///9Tx4YcCQAAAQAAAOioKwAA WTPSagqInfj3//9Z9/GNhfj7//9QO9N1L1PoiSsAAIPgAYPABFBoEANBAOhAGAAAg8QMUP91 COhPXwAAjYX4+///UOlK/////3UI6PJaAABT6FIrAACDxAyoPw+FjgEAAGoBaCADAACNhfj3 //9qCFBXiJ349///6MQdAACNhfj3//9Q/3X46LZaAACDxBzpWwEAAFPoDisAAIPgA1BoEANB AOjIFwAAi3UIUFbokFoAAFPo8CoAAIPEGKgBdBuNhfjz//9QVuiGWgAAaDzwQABW6HtaAACD xBAPvgdQ6N1dAABXVogH6GZaAACDxAzp+wAAAFf/dQjoRVoAAFlZ6esAAABT6J4qAABZM9Jq BVn38Tld/Iv6dAIz/4sEvfDRQABTiUX8iwS9BNJAAIlF+OhzKgAAM9JZ93X4AVX8g/8EfWNT 6F8qAACoAVl1I4P/A3QeU+hPKgAAg+ABg8AIUGioBUEA6AYXAACDxAyL2OsFu6AxQQD/dfxo pANBAOjtFgAAWVlQU1doVANBAOjeFgAAWVlQjYX4+///UOjqXQAAg8QQ6y3/dfxopANBAOi9 FgAAWVlQV2hUA0EA6K8WAABZWVCNhfj7//9Q6LtdAACDxAyNhfj7//9Q/3UI6GBZAAD/dfxX VugIAAAAg8QUX15bycNVi+yB7GACAACDfQwEU1ZXD4SZAQAAM9tT6JYpAACoAVm+qAVBAHUg g30MA3QaU+iAKQAAg+ABg8AIUFboOxYAAIPEDIv46wW/oDFBAP91EGikA0EA6CIWAABZWVBX /3UMaFQDQQDoERYAAFlZUI2FaP7//1DoHV0AAFPoNCkAAIPgAYPAEFBW6O8VAACDxBxQU+gd KQAAagMz0ln38YPCElJW6NQVAACDxAxQag9W6MgVAABZWVCNhTD///9Q6NRcAABT6OsoAACD xBSoAXUmU+jeKAAAg+ABUGgQA0EA6JgVAABQi0UIBawBAABQ6FtYAACDxBSLRQhqDlaNuKwB AACJfRDochUAAFBX6E1YAACNhWj+//9QV+hAWAAAg8QYOV0Mv3YHQQB1ZFf/dRDoKlgAAGgz CUEA/3UQ6B1YAACLdQhTaHQNQQCJnhwJAACJniAJAADoURUAAFOJRfyBxrAGAADoSigAADPS 93X8Umh0DUEA6AIVAABQVujNVwAAaNwBQQBW6NJXAACDxDRX/3UQ6MZXAACNhTD///9Q/3UQ 6LdXAACDxBDpVgIAADPbU+j9JwAAg+ABvlgFQQCJRfyLRQhTVomYHAkAAImYIAkAAOjUFAAA U4v46NQnAAAz0vf3UlbokRQAAIlF+FCNhWj+//9Q6FNXAABT6LMnAACDxCS+qAVBAKgBdAnH RQygMUEA6xlT6JgnAACD4AGDwAhQVuhTFAAAg8QMiUUM/3UMagRW6EIUAABZWVCNhTD///9Q 6E5bAACNhTD///9QjYVo/v//UOgCVwAAi30QV2ikA0EA6BIUAACDxByJRRBQagRoVANBAOj/ EwAAWVlQjYUw////UOgLWwAAjYUw////UI2FaP7//1Dov1YAAP91EI2FMP///1DooFYAACs9 ANJAAIPHBldW6L4TAACDxCRQ/3UMagVW6K8TAABZWVCNhaD9//9Q6LtaAACNhaD9//9QjYUw ////UOhvVgAAi0UIg8QYOV38dC6NjWj+//8FrAEAAFFQ6EJWAACLRQi/dgdBAAWsAQAAV1Do PlYAAI2FMP///+ssjY0w////BawBAABRUOgUVgAAi0UIv3YHQQAFrAEAAFdQ6BBWAACNhWj+ //9Qi0UIBawBAABQ6PtVAACLRQiDxBgFrAEAAFdQ6OlVAACLRQhXjbisAQAAV+jZVQAAag1W 6O8SAABQV+jKVQAAagpW6OASAABQV+i7VQAAagtW6NESAABQV+isVQAAg8RA/3X4V+igVQAA agxW6LYSAABQV+iRVQAAi0UIU4mYHAkAAI2wsAYAAOjSJQAAg+ABUGh0DUEA6IwSAABQVuhX VQAAaNwBQQBW6FxVAACDxDRfXlvJw4PsZFOLXCRsVVaNq8gAAABXjbOsAQAAVWioBUEAVuhq WQAAv3YHQQBXVuglVQAAV1boHlUAAGiQBUEAVugTVQAAjUNkUFboCVUAAFdW6AJVAABqAWiQ BUEA6BQSAABQVujvVAAAg8REVVbo5VQAAFdW6N5UAABqAmiQBUEA6PARAABQVujLVAAA/7Qk nAAAAFbovlQAAFdW6LdUAABqAOgGJQAAg+ABv6gFQQBAUFfovhEAAFBW6JlUAACDxERqA1fo rBEAAFBW6IdUAACNRCQgUI1DZGoAUOjPGAAAagFofQdBAOiJEQAAUFXoVFQAAI1EJDxQVehZ VAAAg8Q0g6McCQAAAF9eXVuDxGTDVYvsgexoCAAAU1ZXi30MaJAFQQBX6B1UAACLXQiNhZj3 //9QjYWY+///jbPIAAAAUFboaBgAAI2FmPv//1ZQjYWY9///aCsNQQBQ6DBYAACNhZj3//9Q V+jqUwAAvn0HQQBWV+jeUwAAagFokAVBAOjwEAAAUFfoy1MAAIPERI1DZFBX6L5TAABWV+i3 UwAAagJokAVBAOjJEAAAUFfopFMAAI2DLAEAAFBX6JdTAABWV+iQUwAAaJ0HQQBX6IVTAACN g7gIAABQV4lFDOh1UwAAg8RAVlfoa1MAAFZX6GRTAABqB2oUjUWYaghQ6CQTAABqAf91DFfo NQIAAIPELIO7HAkAAACLxnQejUWYUI2FmPf//2j7CEEAUOhgVwAAg8QMjYWY9///UI2FmPv/ /2jhB0EAUOhFVwAAjYWY+///UFfo/1IAAI2DrAEAAFBX6PJSAABoTwhBAFfo51IAAFZX6OBS AABWV+jZUgAAagDoKCMAAIPEOIPgAYO7HAkAAACJRQh1B8dFCAIAAABqAf91DFfomQEAAIPE DI1FmFCNg7AGAABQ/3UIaMEIQQDosQ8AAFlZUI2FmPv//2hnCEEAUOi4VgAAjYWY+///UFfo clIAAFZX6GtSAABWV+hkUgAAjUX8agFQjYOsBQAAUOi6HAAAg8Q4iUUIhcB0ElBX6EFSAAD/ dQjoxFYAAIPEDFZX6C9SAACBw7QHAABZWYA7AA+E6wAAAFPozhgAAD0AyAAAWYlF/HIbPQDQ BwAPg88AAABqAOhRIgAAqAFZD4S/AAAAjUX8agBQU+hOHAAAg8QMiUUIhcAPhKUAAABqAf91 DFfouAAAAGoB/3UMV+itAAAAjYWY+///UI2FmPf//1BqAGoAU+gFUwAAjYWY+///UI2FmPf/ /1Dol1EAAIPENI1FmFCNhZj3//9QagJowQhBAOibDgAAWVlQjYWY+///aGcIQQBQ6KJVAACN hZj7//9QV+hcUQAAVlfoVVEAAFZX6E5RAAD/dQhX6EVRAABWV+g+UQAA/3UI6MFVAACDxEBq AP91DFfoEwAAAGhA8EAAV+gdUQAAg8QUX15bycNVi+xoQPBAAP91COgFUQAA/3UM/3UI6PpQ AACDxBCDfRAAdA9ofQdBAP91COjkUAAAWVldw1WL7IPsMFNWV/8V1NBAAIt9CDPbUFNo/w8f AIld8MdF9DIAAACJXfiIXdiIXdmIXdqIXduIXdzGRd0FiV3oiV3siV38iV3kiR//FSDRQACN TfCJReBRaghQ/xUg0EAAhcB1Dv8V4NBAAIlF/OkSAQAA/3X0U/8VlNBAADvDiUX4dOGNTfRR /3X0UGoC/3Xw/xUw0EAAizXg0EAAhcB1OP/Wg/h6dWv/dfj/FdzQQAD/dfRT/xWU0EAAO8OJ Rfh0UY1N9FH/dfRQagL/dfD/FTDQQACFwHQ6jUXoUFNTU1NTU1NqBI1F2GoBUP8VKNBAAIXA dB2NRexQU1NTU1NTU2oGjUXYagFQ/xUo0EAAhcB1B//W6VH///+LdfiJXQg5HnZSg8YE/3Xo iwaLTgSJRdBQiU3U/xUs0EAAhcB1Iv917P910P8VLNBAAIXAdR3/RQiLRfiLTQiDxgg7CHLH 6xTHReQBAAAAiR/rCccHAQAAAIld5DkfdQs5XeR1BscHAQAAADld7Is1PNBAAHQF/3Xs/9Y5 Xeh0Bf916P/WOV34dAn/dfj/FdzQQAA5XfCLNSTRQAB0Bf918P/WOV3gdAX/deD/1otF/F9e W8nDVYvsuOAtAADoBlcAAFMz2zldEFZXx0X8IAAAAIideP///3QT/3UQjYV4////UOjQTgAA WVnrFWoHagqNhXj///9qBVDomQ4AAIPEEDldGHQF/3UY6wVo5DVJAI2FePr//1DonE4AAIt1 CFlZjYV0/v//VlDoik4AAP91DI2FdP7//1Doi04AAIPEEDldFHQT/3UUjYVw/f//UOhkTgAA WVnrImoBaNwBQQDoQ1YAAGoCmVn3+Y2FcP3//1JQ6FIZAACDxBA5HfA4SQB0HmoBU+gdVgAA agKZWff5jYVw/f//UlDoLBkAAIPEEI2FdP7//1Do/E4AAIC8BXP+//9cjYQFc/7//1l1AogY gL1w/f//XHQTjYV0/v//aETwQABQ6O5NAABZWY2FcP3//1CNhXT+//9Q6NlNAABZjYV0/v// WVNQjYV4+v//UP8VfNBAAIXAD4RlAQAA6JRVAABqBZlZ9/mF0nQi6IVVAACZuQAoAAD3+Y2F dP7//4HCgFABAFJQ6JkWAABZWWh6IgAAjYUg0v//aMDwQABQ6BNSAACNhSDS//+InTTi//9Q jYV0/v//UOj/LAAAjYV0/v//UOgQKwAAg8QYOR3wOEkAD4XqAAAAjUX8UI1F3FD/FWTQQACN RdxQjUYCUOjkngAAWYXAWQ+ExQAAAGoCU1aLNQDQQAD/1ov4O/t1CTldHA+EqgAAAFNTU1ON hXT+//9TUFNqA2gQAQAAjYV4////U1CNhXj///9QV/8VSNBAAFeLPUDQQAD/12oBU/91CP/W i/CNhXj///9qEFBW/xU40EAAU1NQiUUQ/xUk0EAA/3UQiUUY/9dW/9c5XRgPhWUBAAC6gQAA ADPAi8qNvab2//9miZ2k9v//ZomdnPT///OrZquLyjPAjb2e9P//OR0EOUkA86uJXRCJXRhm q3UHM8DpJAEAAItFDIA4XHUHx0UYAQAAAL8EAQAAjYWk9v//V4s1eNBAAFBq//91CGoBU//W i00MjYWc9P//V1CLRRhq/wPBUGoBU//WjUUQUI2FnPT//2oCUI2FpPb//1D/FQQ5SQCFwA+F uwAAAFNTjYV8+///V1CLRRBq/4idfPv///9wGFNT/xWg0EAAjUUUUGgCAACA/3UI/xUc0EAA hcB1d42FrPj//2oDUOgnEQAAjYV8+///aETwQABQ6JNLAACNhXD9//9QjYV8+///UOiASwAA jYV0+f//U1BTjYV8+///U1CInXT5///ov0wAAI2FfPv//1CNhXT5//9QjYWs+P//UP91FOgy GgAAg8Q8/3UU/xVc0EAAoQw5SQA7w3QF/3UQ/9BqAVhfXlvJw1WL7ItFFFNWi/FXM9v/dQiJ RhiNRhyJHlCJXgzo9EoAAIt9EGaLRQxXZomGnAEAAGbHhp4BAAAZAOgWUwAAg8QMO8OJRgR1 DMeGpAEAAAIAAIDrY1fo+lIAADvDWYlGEHTmV1P/dgSJfgiJfhToQ0oAAFdT/3YQ6DlKAACD xBiNjqABAACJnqQBAACJnqgBAABqAWoB/3UMiZ6sAQAAiJ4cAQAA6D4FAACFwHUOx4akAQAA BQAAgDPA6xA5Xgx0CDkedARqAesCagJYX15bXcIQAFaL8VeLRgSFwHQHUOjNTgAAWYtGEIXA dAdQ6L9OAABZjb6gAQAAagBqBmhI8EAAi8/ojAUAAIvP6MEFAACFwHT1g/gBdRBo3QAAAIvO 6NUCAACL8OsDagFei8/okAUAAIvGX17DVovxV2aLhpwBAACNvqABAABQjUYcUIvP6N0EAACF wHUNuAEAAICJhqQBAADrK4vP6GQFAACFwHT1g/gBdQ5o3AAAAIvO6HgCAADrDWoBx4akAQAA AwAAgFhfXsNVi+yB7AQBAABTVovxV42GHAEAAFCNhfz+//9oYPBAAFDopU0AAIPEDI2F/P7/ /42+oAEAAGoAUOg1SgAAWVCNhfz+//9Qi8/otAQAAIvP6OkEAACFwHT1g/gBD4WdAAAAu/oA AACLzlPo+AEAAIXAD4WVAAAAi87olQAAAIXAD4WGAAAAIUX8OQaLfgR2IVeLzug1AQAAhcB1 cFfo0UkAAP9F/I18BwGLRfxZOwZy32oAjb6gAQAAagdoWPBAAIvP6DsEAABoYgEAAIvO6JQB AACFwHU1UIvP/3UM/3UI6B0EAABqAGoFaFDwQACLz+gNBAAAU4vO6GoBAADrDWoBx4akAQAA AwAAgFhfXlvJwggAU1aL8YtGFIPAZFDon1AAAIvYWYXbdQhqAljpmAAAAFVXaHDwQABT6ERI AACLfhAz7TluDFlZdiVXU+hBSAAAaDjwQABT6DZIAABX6BBJAACDxBRFO24MjXwHAXLbaGzw QABT6BhIAABZjb6gAQAAWWoAU+joSAAAWVBTi8/obQMAAIvP6KIDAACL6IXtdPNT6HZMAABZ agFYXzvoXXUOaPoAAACLzuipAAAA6wrHhqQBAAADAACAXlvDU1b/dCQMi9nomUgAAIPAZFDo 308AAIvwWYX2WXUFagJY63JVV2iA8EAAVuiGRwAA/3QkHFbojEcAAGhs8EAAVuiBRwAAg8QY jbugAQAAagBW6FBIAABZUFaLz+jVAgAAi8/oCgMAAIvohe1081bo3ksAAFlqAVhfO+hddQ5o +gAAAIvL6BEAAADrCseDpAEAAAMAAIBeW8IEAFWL7IHsBAQAAFaL8VdqAI2+oAEAAI2F/Pv/ /2gABAAAUIvP6IoCAACLz+ioAgAAhcB09YP4AXVAjUX8UI2F/Pv//2iM8EAAUOgcTwAAi0UI i038g8QMO8F0GseGpAEAAAQAAICJjqgBAACJhqwBAABqAusQM8DrDceGpAEAAAMAAIBqAVhf XsnCBAD/dCQEgcEcAQAAUeiBRgAAWVnCBABVi+xRU1ZXi/H/dQiLfhDoWEcAAINl/ACDfgwA WYvYdhZX6EVHAAD/RfyNfAcBi0X8WTtGDHLqK14Qi0YUA9872HZOi04YA8FQiUYU6GpOAACL 2FmF23UMx4akAQAAAgAAgOs+/3YUagBT6K1FAACLRhCLzyvIUVBT6I5OAACLRhBQK/jojkoA AIPEHIleEAP7/3UIV+jiRQAA/0YMi0YMWVlfXlvJwgQAVYvsUVNWV4vx/3UIi34E6K9GAACD ZfwAgz4AWYvYdhVX6J1GAAD/RfyNfAcBi0X8WTsGcusrXgSLRggD3zvYdk6LThgDwVCJRgjo w00AAIvYWYXbdQzHhqQBAAACAACA6zz/dghqAFPoBkUAAItGBIvPK8hRUFPo500AAItGBFAr +OjnSQAAg8QciV4EA/v/dQhX6DtFAAD/BosGWVlfXlvJwgQAVYvsgeyQAQAAU1ZqAY2FcP7/ /1uL8VBqAv8V4NFAAA+/RQxISHUDagJbD7/DagZQagL/FeTRQAAzyYP4/4kGXg+VwYvBW8nC DABVi+yD7BBWi/H/dQz/FdTRQABmiUXyjUUMUIvO/3UIZsdF8AIA6HkAAACLRQxqEIhF9IpF DohF9opFD4hl9YhF941F8FD/Nv8V2NFAAIXAXnQK/xXc0UAAM8DrA2oBWMnCCAD/dCQM/3Qk DP90JAz/Mf8V0NFAAMIMAP90JAz/dCQM/3QkDP8x/xXM0UAAwgwA/zH/FcTRQAD/JcjRQABq AVjDVYvsUVFTVleLfQhqATP2W4lN+FeJdfzoFUUAAIXAWX4sigQ+PC51Bf9F/OsKPDB8BDw5 fgIz21dG6PNEAAA78Fl83oXbdBiDffwDdAQzwOs6/3UMi034V+g1AAAA6ylX/xXA0UAAi/D/ FdzRQACF9nQWM8CLTgyLVQyLCYoMAYgMEECD+AR87GoBWF9eW8nCCABVi+xRU4tdCFYz9leJ dfyNRQiNPB5QaIzwQABX6NtLAACLVQyLRfyKTQiDxAyD+AOIDBB0F0aAPy50CIoEHkY8LnX4 /0X8g338BHzDX15bycIIAFWL7FFTVlf/dQzoPUQAAIt1CItdEFmJRfxW6C1EAACL+FmF/3Qt hdt0CYvGK0UIO8N9IIN9FAB0D/91DFbo6pQAAFmFwFl0Bo10PgHry4PI/+syi038i8YrRQiN RAgCO8N+CIXbdAQzwOsa/3UMVujoQgAAVujSQwAAg8QMgGQwAQBqAVhfXlvJw1aLdCQIVzP/ OXwkEH4dVuiuQwAAhcBZdBJW6KNDAABHWTt8JBCNdAYBfOOLxl9ew1aLdCQIVzP/VuiEQwAA hcBZdBqDfCQQAHQMi84rTCQMO0wkEH0HjXQGAUfr24vHX17DVYvsUVOLXQhWi3UMV2oAU4l1 /Oi2////i/hZhf9ZfwczwOmVAAAAhfZ9D2oA6KQSAAAz0ln394lV/I1HAlBT6Fr///+L8Cvz 0eZW6F9KAABWM/ZWUIlFDOizQQAAg8QYhf9+JDt1/HQaagH/dRBWU+gp////WVlQ/3UM6JT+ //+DxBBGO/d83DP2Tzv+iTN+H2oB/3UQVv91DOj//v//WVlQU+hs/v//g8QQRjv3fOH/dQzo U0YAAFlqAVhfXlvJw1ZXM/+L92oA994b9oHm+AAAAIPGCOj7EQAAM9JZ9/aLRCQMA8eE0ogQ dQPGAAFHg/8EfNBfXsNVi+yD7AyLRRCDZfgAg30MAFOKCIpAAVZXiE3+iEX/fjOLRQiLTfgD wYlF9IoAiEUTYIpFE4pN/tLAMkX/iEUTYYtN9IpFE/9F+IgBi0X4O0UMfM1qAVhfXlvJw1WL 7IPsDItFEINl+ACDfQwAU4oIikABVleITf6IRf9+M4tFCItN+APBiUX0igCIRRNgikUTik3+ MkX/0siIRRNhi030ikUT/0X4iAGLRfg7RQx8zWoBWF9eW8nDU1ZXM/9X6BsRAABZM9JqGotc JBRZ9/GL8oPGYYP7BHR4g/sBdRVX6PoQAABZM9JqCln38YvCg8Aw62D2wwJ0E1fo4BAAAFkz 0moaWffxi/KDxkFX6M0QAACoAVl0GPbDBHQTV+i9EAAAWTPSahpZ9/GL8oPGYVfoqhAAAKgB WXQY9sMBdBNX6JoQAABZM9JqCln38Yvyg8Ywi8ZfXlvDU4tcJAxWV4t8JBiL8zv7fhJqAOhv EAAAK/sz0vf3WYvyA/OLXCQQM/+F9n4S/3QkHOgr////iAQfRzv+WXzuagLoG////1mIA4Ak HwBqAVhfXlvDVle/kPBAADP2V+iuQAAAhcBZfhiKRCQMOoaQ8EAAdBFXRuiWQAAAO/BZfOgz wF9ew2oBWOv4U4pcJAhWV4TbfD8PvvNW6EhLAACFwFl1NVboa0sAAIXAWXUqv5jwQAAz9lfo VkAAAIXAWX4UOp6Y8EAAdBBXRuhCQAAAO/BZfOwzwOsDagFYX15bw1aLdCQIigZQ/xVo0EAA hcB0C4B+AYB2BWoBWF7DM8Bew4tEJASKADyhdAc8o3QDM8DDagFYw1WL7IHs/AcAAItFHFNW V4t9DDP2iXX8gCcAOXUQiTB/CYtFCEDp3AEAAItdCIoDUOhA////hcBZdVCJXQyDfSAAdCv/ dQzof////4XAWXQN/3UM6JP///+FwFl0Lf91DOiG////hcBZdARG/0UMi0UQRv9FDEg78H0Q i0UMigBQ6PD+//+FwFl0s4tFEEg78IlFDA+NagEAAIoEHlDo0/7//4XAWQ+EvgAAAIoEHlDo i/7//4XAWXULRjt1DHzs6T8BAACKBB5Q6Kj+//+FwFl0G4tN/IoEHv9F/EY7dQyIBDl9CYtF GEg5Rfx814tFGEg5Rfx8HIN9/AB0FotF/IoEOFDoN/7//4XAWXUF/038deqLRfyFwHwEgCQ4 ADPbOB90FYoEO1DoE/7//4XAWXQHQ4A8OwB1640EO1CNhQT4//9Q6MQ9AACNhQT4//9QV+i3 PQAAi0X8g8QQK8M7RRQPjYQAAACLXQiDfSAAD4SKAAAAi0UIgCcAA8Yz21DoR/7//4XAWXRZ i0UQg8D+iUUgi0UIA8aJRRD/dRDoSv7//4XAWXUZi0UQigiIDDuKSAFDRkCIDDtDRkCJRRDr BkZGg0UQAjt1IH0Xi0UYg8D+O9h9Df91EOju/f//hcBZdbiAJDsAO10UfBCLRRzHAAEAAACL RQgDxusMi10Ii0UcgyAAjQQeX15bycNVi+y4HBAAAOgERQAAU1ZXjU3k6OTc//+LfQyNRfhq AVD/dQgz241N5Igf6M/c//+L8DvzD4QrAQAAi1X4g/oKD4IXAQAAiJ3k7///iV38/3UYjU38 Uf91FP91EFJXUOiR/f//i034g8Qci9Er0APWg/oFD47iAAAAOV38dNGJXQgz//91GI1V/CvI UgPO/3UU/3UQUY2N5O///1FQ6FP9//+DxBw5Xfx0A/9FCItN+IvRK9AD1oP6BXYJR4H/ECcA AHy/OV0IdBFT6JgMAAAz0ln394tN+IlVCIv+iV30/3UYjUX8K89QA87/dRSNheTv////dRBR UFfo9/z//4PEHDld/Iv4dBk5XQh0Lv9NCI2F5O///1D/dQzo4jsAAFlZi034i8ErxwPGg/gF dgz/RfSBffQQJwAAfKSNTeTodtz///91DOimPAAAWTPJO0UQD53Bi8FfXlvJw4gfjU3k6FTc //8zwOvtVYvsi1UMUzPbVoXSdAIgGotFEIXAdAOAIACLdQiAPkB0HFeL+ovGK/6KCITJdA6F 0nQDiAwHQ0CAOEB17F+F0nQEgCQTAIA8MwCNBDNeW3UEM8Bdw4N9EAB0C1D/dRDoNDsAAFlZ agFYXcNVi+xRU4pdCFZXvqTwQACNffxmpYD7IKR+NID7fn0vD77zVujKRgAAhcBZdShW6O1G AACFwFl1HYD7QHQYgPsudBM6XAX8dA1Ag/gCfPQzwF9eW8nDagFY6/b/dCQE6J3///9Zw1WL 7LgAIAAA6MtCAAD/dQiNhQDg//9Q6Kw6AAD/dQyNhQDw//9Q6J06AACNhQDg//9Q6O2MAACN hQDw//9Q6OGMAACNhQDw//9QjYUA4P//UOjCRgAAg8QgycNWvlICQQBW/3QkDOhdOgAA/3Qk FFbogff//1D/dCQc6Fk6AACDxBhew1OLXCQIVldT6Cc7AACL+FmD/wR8JIP/DH8fM/aF/34U D74EHlDoDUYAAIXAWXQKRjv3fOxqAVjrAjPAX15bw1WL7IHsBAEAAFNWV42F/P7//zP/UFdX V/91COhQOwAAvvwBQQBXVug39///i9iDxBw7334gV1bo9/b//1CNhfz+//9Q6IyLAACDxBCF wHQnRzv7fOCNhfz+//9owg1BAFDob4sAAPfYG8BZg+BjWYPAnF9eW8nDi8fr91WL7FYz9ldW aiBqAlZqA2gAAADA/3UI/xX80EAAi/iJdQiD//90Izl1DHQejUUIVlD/dRD/dQxX/xVs0EAA V/8VJNFAAGoBWOsCM8BfXl3DVYvsU1dqAGonagNqAGoDaAAAAID/dQj/FfzQQACDZQgAi/iD y/87+3QdjUUIUFf/FezQQACDfQgAi9h0A4PL/1f/FSTRQACLw19bXcNVi+yD7BSNTezo2tj/ /41F/GoBUI1N7P91COjM2P//hcB0DY1N7Oh62f//agFYycMzwMnDVYvsgewYAQAAVmoEagWN RexqAlDof/j//4PEEI2F6P7//1BoBAEAAP8VmNBAAIt1CI1F7FZqAFCNhej+//9Q/xV00EAA VugjAAAAVuhYOQAAWVlIeAaAPDAudfcDxmjcAUEAUOhQOAAAWVleycNqIP90JAj/FYDQQAD/ dCQE/xWc0EAAw1WL7IHsSAMAAFZX/3UIjYX4/f//M/ZQ6Bg4AACNhfj9//9Q6Pw4AACDxAyF wHQXgLwF9/3//1yNhAX3/f//dQaAIABqAV6Nhfj9//9osPBAAFDo7TcAAFmNhbj8//9ZUI2F +P3//1D/FYzQQACL+IP//w+E1AAAAP91CI2F/P7//1DorTcAAFmF9ll1E42F/P7//2hE8EAA UOimNwAAWVmNheT8//9QjYX8/v//UOiRNwAA9oW4/P//EFlZdFuNheT8//9orPBAAFDodTYA AFmFwFl0Wo2F5Pz//2io8EAAUOheNgAAWYXAWXRD/3UQjYX8/v//agFQ/1UMg8QMhcB0Lf91 EI2F/P7///91DFDo7P7//4PEDOsW/3UQjYX8/v//agBQ/1UMg8QMhcB0Fo2FuPz//1BX/xWI 0EAAhcAPhTP///9X/xWE0EAAXzPAXsnDVYvsUYF9DABQAQBTVld8Kmog/3UI/xWA0EAAM9tT aiBqA1NqA2gAAADA/3UI/xX80EAAi/iD//91BzPA6YQAAACNRfxQV/8V7NBAAIvwO3UMfhVT U/91DFf/FeTQQABX/xWQ0EAA61NqAlNTV/8V5NBAAItFDCvGvgAACACJRQiLzpn3+TvDix1s 0EAAfheJRQyNRfxqAFBWaNAxQQBX/9P/TQx17I1F/GoAUItFCJn3/lJo0DFBAFf/01f/FSTR QABqAVhfXlvJw1ZqAGonagNqAGoDaAAAAID/dCQg/xX80EAAi/CD/v91BDPAXsOLRCQMV41I EFGNSAhRUFb/FejQQABWi/j/FSTRQACLx19ew1ZqAGonagNqAGoDaAAAAMD/dCQg/xX80EAA i/CD/v91BDPAXsOLRCQMV41IEFGNSAhRUFb/FTDRQABWi/j/FSTRQACLx19ew1WL7IPsFFON TezodNX//41F/GoBUI1N7P91COhm1f//i9iF23Rwg30QAHQmgX38AJABAHYdagDosgUAAFkz 0moKWffxg8JUweIKO1X8cwOJVfyLRfxWA8BQ6Gk9AACL8FmF9nQmi0X8A8BQagBW6LU0AABq SP91/FZT6LnN//+LTQyDxByFyXQCiQGNTezordX//4vGXlvJw1WL7IHsBAEAAFNWV4t9CDPb ahRTV4id/P7//+hvNAAAg8QMOB3sN0kAdD5T6CQFAABZM9JqA1n38YXSdCxqAWoKjYX8/v// UVBo7DdJAOib9///g8QUhcB0D42F/P7//1BX6Ig0AABZWTgfD4WLAAAAOB3oNkkAdDZT6NYE AABZM9JqA1n38YXSdCSNhfz+//9TUFNTaOg2SQDouzUAAI2F/P7//1BX6EM0AACDxBw4H3VJ U+icBAAAqA9ZdSu+dA1BAFNW6IPx//9TiUUI6IIEAAAz0vd1CFJW6D7x//9QV+gJNAAAg8Qc OB91D2oEagZqAlfo1fP//4PEEDldDHQrvvwBQQBTVuhA8f//U4lFCOg/BAAAM9L3dQhSVuj7 8P//UFfo1jMAAIPEHDldEHQN/3UQV+jFMwAAWVnrMDldFHQrvtwBQQBTVuj+8P//U4lFCOj9 AwAAM9L3dQhSVui58P//UFfolDMAAIPEHF9eW8nDVYvsg+wUU4tFGFZX/3UUM9uDz/+JXfxT iX34/3UQiV3wiV30iRjo8TIAAIt1CIoGUOgZ+P//g8QQhcAPhIwAAACKBlDoBvj//4XAWXRc i0UMi95IiUUIi0UQK8aJRezrA4tF7IoLiAwYigM8QHUJi03w/0X0iU34PC51B4X/fQOLffD/ RfxDi0X8/0XwO0UIfRaLRRRIOUXwfQ2KA1DorPf//4XAWXW5M9uLRfCLTRArffiAJAgAg/8D fhFqAVg5Rfh+CTlF9A+EoAAAAINN+P+DTfD/iV38ZoseM/9TIX306MP3//+FwFkPhIoAAABT 6LT3//+FwFl0VItFDEghfQyJRQiLRRCA+0CIHAd1Bv9F9Il9+ID7LnUJg33wAH0DiX3wg0UM BINF/AKLRQxHO0UIfRqLRRRIO/h9EotF/GaLHDBT6GD3//+FwFl1totFEIAkBwCLRfArRfiD +AJ+EmoBWDlF+H4KOUX0dQWLTRiJAYtF/APG6wONRgFfXlvJw1WL7IHsGAQAAFMz21aNTeiJ Xfzo3tH//41F+GoBUI1N6P91COjQ0f//i/A783UEM8DrY1eL/otF+IvPK86NUP87yn1HjU38 K8dRjY3o+///aAAEAACNRDD/UVBX6B7+//+DxBSDffwAi/h0yv91FI2F6Pv///91EFD/dQzo Hu7//4PEEIXAfq5D66uNTejoINL//4vDX15bycNVi+xRUYtFGINN+P9QagD/dRSJRfzo5zAA AIPEDI1FGFD/dQz/dQj/FUzQQACFwHQFagFYycONRfxQjUX4/3UUUGoA/3UQ/3UY/xUU0EAA /3UY/xVc0EAAM8DJw1WL7I1FDFD/dQz/dQj/FRjQQACFwHQFagFYXcP/dRTo0TEAAFlQ/3UU agFqAP91EP91DP8VENBAAP91DP8VXNBAADPAXcNVi+yB7AwBAACNRfxWUDP2/3UM/3UI/xVM 0EAAhcB0BDPA61eNhfT+//9oBAEAAFBW/3X8/xVQ0EAAhcB1LzlFEHQjIUX4/3UUjUX4UI2F 9P7//1D/dQz/dQj/VRCDxBSDffgAdQNG67uL8OsDagFe/3X8/xVc0EAAi8ZeycNVi+yB7BQI AABTjUX8VlD/dQy+AAQAADPbiXXw/3UIiXX4/xVM0EAAhcB0BDPA63ONRfiJdfBQjYXs9/// UI1F7FCNRfBqAFCNhez7//+JdfhQU/91/P8VRNBAAIXAdTWDfewBdSg5RRB0IyFF9P91FI1F 9FCNhez7//9Q/3UM/3UI/1UQg8QUg330AHUDQ+ufi/DrA2oBXv91/P8VXNBAAIvGXlvJw4N8 JAQAdQmDPcwxQQAAdRf/FTTRQABQ6GM3AABZ6Gc3AACjzDFBAOldNwAAVYvsg+xUVjP2akSN RaxWUOj5LgAAg8QMjUXwx0WsRAAAAFCNRaxQVlZWVlZW/3UM/3UI/xWk0EAA99gbwF4jRfDJ w1WL7IPsHFNWjU3k6BbP//+DZfgAvsDwQABW6PwvAABZiUX0jUX8agFQjU3k/3UI6PXO//+L 2IXbdFOLTfxXgfkAoAAAcju4ABAAAIHBGPz//zvIi/h2Kv919I0EH1BW6Jc7AACDxAyFwHQP i0X8RwUY/P//O/hy3+sHx0X4AQAAAI1N5Ohaz///i0X4X15bycNVi+yB7AAEAABojQdBAP91 EOi88///WYXAWXRzjYUA/P//aAAEAABQgKUA/P//AP91EP91DP91COj8/P//jYUA/P//UOgm ////g8QYhcB0P4tNGGoBWP91DIkBi00UaOA0SQCJAegwLgAAjYUA/P//UGjkNUkA6B8uAAD/ dRBo3DNJAOgSLgAAg8QYM8DJw2oBWMnDVYvsgewACAAA/3UMjYUA/P//UOjuLQAAjYUA/P// aETwQABQ6O0tAAD/dRCNhQD8//9Q6N4tAACNhQD8//9ojQdBAFDo9fL//4PEIIXAdHmNhQD4 //+ApQD4//8AaAAEAABQjYUA/P//aJMHQQBQ/3UI6C78//+NhQD4//9Q6Fj+//+DxBiFwHQ/ i00YagFY/3UMiQGLTRRo4DRJAIkB6GItAACNhQD4//9QaOQ1SQDoUS0AAP91EGjcM0kA6EQt AACDxBgzwMnDagFYycNVi+yB7BwFAACDZfwAgz3wOEkAAHUlagRoUgJBAOhE6v//jU38UWhK SUAAUGgCAACA6EP8//+DxBjrPI2F6Pv//2oCUOiC8v//jYXo+///UGjgNEkA6N4sAACNRfxQ jYXo+///aLZIQABQaAIAAIDog/z//4PEIItF/IXAo/Q4SQAPhdEAAABWjYXk+v//aAQBAABQ /xWo0EAAM/aAZegAjUXoaI0HQQBQ6IosAABZjUXoWWoEagRqAlDoaS0AAFmNRAXoUOhN7P// jUXpUOjBfgAAjYXk+v//UI2F6Pv//1DoUiwAAI2F6Pv//2hE8EAAUOhRLAAAjUXoUI2F6Pv/ /1DoQSwAAI2F6Pv//2jcAUEAUOgwLAAAjYXo+///UOgn8///g8Q4hcB0CkaD/goPjGf///+N RehQaNwzSQDoBSwAAI2F6Pv//1Bo5DVJAOjkKwAAg8QQXmoBWMnDi0QkBGaLTCQIZgFIAmaL SAJmg/kBfQ5mg0ACHmaLSAJm/wjr7GaDeAIffhJmg0AC4maLSAJm/wBmg/kff+5miwhmg/kB fQaDwQxmiQhmiwhmg/kMfgaDwfRmiQjDi0QkDFaLdCQIV4t8JBCAJwCAIACAPlx1WIB+AVx1 UlNouPBAAFfoUysAAFmNRgJZighqAoD5XFp0F4vfK96EyXQPighCiAwDikgBQID5XHXtgCQ6 AAPWW4A6AHUEagLrElL/dCQY6BMrAABZM8BZ6wNqAVhfXsNVi+yB7BAEAABWjYX0/P//aOQ1 SQBQ6OwqAABZjYX8/v//WTP2aAQBAABQVv8VFNFAAFaNhfD7//9WUI2F9Pz//1ZQ6CosAABW jYX4/f//VlCNhfz+//9WUOgULAAAjYX4/f//UI2F8Pv//1DoZnwAAIPEMPfYG8BeQMnDVot0 JAyD/kRyMYtMJAiAOU11KIB5AVp1Ig+3QTwDwYPG/IvQK9E71ncRiwBeLVBFAAD32BvA99Aj wsMzwF7DVYvsU4tdEFaLdQhXU1borv///1mFwFl0UI0MMIt1DItRdI1BdDvWckAPt0kGi3Tw /IPABDP/hcmNRNAIdiuDw/yJXRCL0CtVCDtVEHMbi1AEixgD2jvedgQ71nYIg8AoRzv5ct87 +XICM8BfXltdw1WL7FNWi3UMV4t9CI1GEIlFDIvGK8eDwBA7RRgPh4AAAAAPt0YOD7dODINl CAADwYXAfmaLXRSLRQyLTRgrx4PACDvBd1SLRQyLQASpAAAAgHQcUVP/dRAl////fwPHUFfo mv///4PEFIXAdDXrFYvTA8crVRABEIsAO8NyJAPLO8FzHg+3Rg4Pt04Mg0UMCP9FCAPBOUUI fJ1qAVhfXltdwzPA6/dVi+yD7DxWjU3U6CLJ//+NTcToGsn//41F/GoBUDP2/3UMjU3EiXX4 iXX8iXX0iXXw6P7I//87xolFDHUHM8DpZAEAAItF/ItNEFONhAgAEAAAUP91COj58f//WY1F +FlWUP91CI1N1OjHyP//i9g73old7A+E/gAAAFf/dfhqA1PoZP7//4v4g8QMO/4PhNoAAAD/ dfxqA/91DOhK/v//i/CDxAyF9g+EwAAAAP91/P91DOjz/f///3X4iUUQU+jn/f//i00Qi1UM A8qDxBBmg3lcAg+FkwAAAIuJjAAAAAPYiU0QiYuMAAAAi0YIi08MiUcIiwaJB4tHCAPBiUXw i0YEiUXki0cEiUXoi0YIi3YMA/KLVeyNPBGLyCtNDAPOO038d0dQVlfouCwAAP91EP916P91 5FdX6Bz+//8Pt0sUiUX0i9MPt0MGA9GDxCCNBICNTML4i0TC/AMBZqn/D3QHwegMQMHgDIlD UI1N1Oh5yP//M/ZfjU3E6G7I//85dfRbdB+LRfA7RfxzA4tF/FD/dQjouvD///91COhMAQAA g8QMi0X0XsnDVYvsg+wUU1aNTezodsf//zP2jUX8VlD/dQiNTezoZ8f//4vYO951BzPA6b0A AABX/3X8U+jH/P//i/hZhf9ZD4SBAAAA/3X8agNT6O/8//+DxAyFwHRvahCNNB9aiZaMAAAA i0gEA8qJEGb3wf8PiVAIdAfB6QxBweEMiU5Qi0gMi3gIA/k7fQxzA4t9DGb3x/8PdAfB7wxH wecMjQQZi8gryztN/HMMUmoAUOh6JgAAg8QMi4bsAAAAhcB0A4lGKGoBXusDi30IjU3s6HLH //+F9nQLV/91COjL7///WVn/dQjoWwAAAFmLxl9eW8nDVYvsUYtFDDPJ0eiJTfx0KYtVCFaL 8A+3AgPIiU0Ii0UIwegQiUUIgeH//wAAA00IQkJOdeGJTfxeiU0Ii0UIwegQi1X8ZgPCiUUI i0UIA0UMycNVi+yD7BRWV41N7Ogzxv//g2X8ADP2jUX8VlCNTez/dQjoIMb//4v4hf90O/91 /FfoiPv//1mFwFl0IoN8OFgAjXQ4WHQSgyYA/3X8V+hb////WYkGWesDi0UIi/CNTezom8b/ /4vGX17Jw1WL7IHsAAgAAIM98DhJAAB1NYM9EDlJAAB0LI2FAPj//2jIAAAAUGr//3UIagFq AP8VeNBAAI2FAPj//1BqAP8VEDlJAMnDM8DJw1WL7IPsDFNWV4tFCIlF+ItFDIlF9It1+It9 9FFSUzPJSYvRM8Az26wywYrNiuqK1rYIZtHrZtHYcwlmNSCDZoHzuO3+znXrM8gz00911ffS 99Fbi8LBwBBmi8FaWYlF/ItF/F9eW8nDVYvsgexQAQAAU1ZXagNfjU3Q6A7F////dRDo+yUA AIvwWY1F6IPGIFD/FdjQQABmgWXq/v8z21PoU/X//1kz0moeWffxZilV8maDffI8cgZmx0Xy AQCKRfKLTfCD4D/B4QYLwYpN9NDpweAFg+EfC8GKTf5miUX8i0Xog8BEg+EfweAJM8GKTeqD 4Q9mJR/+weEFC8GKTe5miUX+Mk3+g+EfZjPBOV0UZolF/nQDagJfaiD/dQj/FYDQQABTaiBX U2oDaAAAAMD/dQj/FfzQQACL+IP//4l9+HQqagJTU1f/FeTQQACNReRqAVCNTdD/dQzoMcT/ /zvDiUUMdQ5X/xUk0UAAM8Dp8wAAAItF5MaFsv7//3RQZseFs/7//wCA/3UMZom1tf7//4mF t/7//4mFu/7//4idv/7//+hX/v///3UQiYXA/v//i0X8xoXI/v//FImFxP7//8aFyf7//zDo tCQAAP91EGaJhcr+//+NhdD+//+Jncz+//9Q6KgjAAAPt/6NR/5QjYWy/v//UOgD/v//izVs 0EAAg8QcOV0UZomFsP7//3QRjUXgU1BqFGisDUEA/3X4/9aNReBTUI2FsP7//1dQ/3X4/9aN ReBTUP915P91DP91+P/WjU3Q6P3D////dfj/FSTRQAA5XRR0Cf91COgBAQAAWWoBWF9eW8nD VYvsUYsNFDlJAINl/ABqAYXJWHQIjUX8agBQ/9HJw1WL7IHsYAYAAItFCFMz28dF8EAGAAA7 w4ld/HUG/xWs0EAAjU0IUWooUP8VINBAAIXAD4SeAAAAVo1F9FdQ/3UMU/8VCNBAAIXAdHyL RfSLNQzQQACJReSLRfiJReiNRfBQjYWg+f//UI1F4GoQUFOJXeD/dQiJXez/1os94NBAAP/X hcB1QYtF9IONrPn//wKJhaT5//+LRfiJhaj5//9TU42FoPn//2oQUFPHhaD5//8BAAAA/3UI /9b/14XAdQfHRfwBAAAA/3UI/xUk0UAAi0X8X15bycNVi+yD7BhWM/ZXVmogagNWagFoAAAA wP91CP8V/NBAAIv4O/4PhK4AAACNRehQ/xW00EAAVuha8v//ajwz0ln38VZmiVXy6Eny//9Z M9JZahhZ9/FmKVXwZjl18H8IZgFN8Gb/Te5W6Cjy//9ZM9JqHFn38WYpVe5mOXXufxJW6BDy //9ZM9JqA1n38WaJVe5W6P7x//9ZM9JqDFn38WYpVepmOXXqfwhmAU3qZv9N6I1F+FCNRehQ /xWw0EAAjUX4UI1F+FCNRfhQV/8VMNFAAFf/FSTRQABfXsnDVYvsgeyUAAAAU1ZXagFbU+ij 8f//vgQBAAAz/1ZXaOw3SQDoyiAAAFZXaOg2SQDoviAAAFZXaOQ1SQDosiAAAFZXaOA0SQDo piAAAFZXaNwzSQDomiAAAIPEQGjQ8EAAaGYiAABo1PBAAOjH3///aPg4SQDoCdD//4PEEP8V vNBAACUAAACAiT0AOUkAo/A4SQCNhWz///9Qx4Vs////lAAAAP8VuNBAAIO9cP///wV1Djmd dP///3UGiR0AOUkA6FXz//++ANAHAFbowSgAADvHWaPYM0kAdQQzwOskVldQ6AwgAADo1QAA AFNoBA5BAOiK3f//UFfoTv3//4PEHIvDX15bycNVi+yD7BRXjU3s6DfA//+NRfxqAFCNTez/ dQjoKcD//4v4hf8PhIwAAABWvgAQAAA5dfxzBDP263JT/3UM6PkgAACL2ItF/AUY/P//WTvG dlaNBD5TUP91DOi9LAAAg8QMhcB0D4tF/EYFGPz//zvwct/rM418PhS+ZiIAAI1f/FNWV+in 3v//i0UMVoPAFFBX6GUkAABT6ADe//9TVlfoL97//4PEKGoBXluNTezoUMD//4vGXl/Jw1NV VldqAmiTC0EA6LDc//+LHfTQQABZWVD/04s1ONFAAIvohe2/kwxBAHQ5agFX6Izc//9ZWVBV /9ZqBFejCDlJAOh53P//WVlQVf/WagVXowQ5SQDoZtz//1lZUFX/1qMMOUkAagNokwtBAOhP 3P//WVlQ/9OL6IXtdBNqA1foPNz//1lZUFX/1qMQOUkAv8gNQQBX/9OL2IXbdBNqAVfoG9z/ /1lZUFP/1qMUOUkAX15dW8NVi+yB7EwGAABTVleNTeToxL7//4t9CDPbV4ld9OiQ7///hcBZ D4VqAgAAV+jP+P//hcBZD4VbAgAAvvsMQQBTVuj12///iUX8jYW4+v//U1BTU1fo7x8AAIPE HDld/IldCH4x/3UIVuie2///OBhZWXQXUI2FuPr//1DoleP//1mFwFkPhQsCAAD/RQiLRQg7 Rfx8z42FyP7//1Dog+X//42FvPv//8cEJAQBAABQU/8VFNFAAI2FyP7//1NQjYW8+///UP8V fNBAAIXAD4TCAQAAizWA0EAAjYXI/v//aiBQ/9ZoAFABAI2FyP7//1dQ6LH0//+DxAyFwA+E hwEAAI1F+FNQV41N5OjMvf//O8OJRQgPhG4BAACBffgAUAEAD4ZZAQAAgX34AAAwAA+DTAEA AI2FvPv//1NQjYW0+f//UI2FxP3//1BX6PgeAACNhbT5//9QjYXE/f//UOiKHQAAjYW8+/// UI2FxP3//1Dodx0AAI2FxP3//2is8EAAUOhmHQAAagRqA42FwPz//2oDUOgj3f//D76FwPz/ /1DotSAAAIPEQIiFwPz//42FwPz//1CNhcT9//9Q6CsdAACNRfRQ/3X4/3UI6BkaAACDxBQ7 w4lFCI1N5A+EoQAAAOiuvf///3X0jYXE/f///3UIUOha4///jYXE/f//UOiq+v//g8QQjYXE /f//aidQ/9aNRcxQV+io5v//WYlF/FlqIFf/1lONhcj+//9XUP8VfNBAAI2FyP7//1DoUOT/ /42FxP3//1Bo1ABBAOiKHAAAaMDwQABX6DT8//+DxBQ5Xfx0DI1FzFBX6J3m//9ZWf91COj+ IAAAWWoBWOsXjU3k6A29//+Nhcj+//9Q6P7j//9ZM8BfXlvJw1WL7IHsKAQAAFaNTejoKrz/ /4Nl/ACNRfhqAVD/dQiNTejoGLz//4vwhfYPhJMAAACNheD9//9QjYXY+///UI2F3Pz//1CN heT+//9Q/3UI6FcdAACNhdz8//9QjYXk/v//UOjpGwAAjYXY+///UI2F5P7//1Do1hsAAICl 5f3//wCNheH9//9QjYXk/v//UOi8GwAAjYXk/v//aNwBQQBQ6KsbAACNRfxQ/3X4VuiqGQAA i/CDxECF9o1N6HUJ6DW8//8zwOtU6Cy8////dfyNheT+//9WUOja4f//Vuj5HwAAg8QQM/b/ FcTQQABQjYXk/v//UOjY6///WYXAWXQZav9Q/xXA0EAAjYXk/v//UOjg4v//WWoBXovGXsnD VYvsgewEAQAAjYX8/v//aAQBAABQaKAxQQBqBWhSAkEA6CrY//9ZWVBoAQAAgOiO6f//agGN hfz+////dQz/dQhQ6ODo//+DxCTJw1WL7IHsDAIAAFMz2zldDFZXiV38D4WLAQAAvosJQQBT VugO2P//i/iNhfT9//9QjYX4/v//UFNTiJ34/v///3UI6PsbAACDxBxPO/uJXQx+Mf91DFbo qtf//1CNhfj+//9Q6D9sAACDxBCFwHUMOX0MdAfHRfwBAAAA/0UMOX0MfM+NhfT9//9QjYX4 /v//UOhRGgAAvhsLQQBTVuiT1///g8QQM/87w4lFDH4oV1boUNf//1CNhfj+//9Q6OVrAACD xBCFwHUHx0X8AQAAAEc7fQx82Dld/HQpagFo8A1BAOge1///i3UIUFboHt///4PEEIXAdQ9W 6I7h//9Z6aIAAACLdQhW6MXf//+L+Fk7+3w1VmjoNkkA6LgZAABZg/8FWX02VmjsN0kA6KYZ AABqAWgA0AcA/zXYM0kAVuiY5///g8QY6xOD/5x1DlNq/2r/Vuh6EgAAg8QQixUYOUkAadIs AQAAgfpYGwAAfhdT6Mfp//9ZM9JqBVn38YPCB2nS6AMAAFL/FSzRQAD/BRg5SQCBPRg5SQAQ JwAAfgaJHRg5SQBqAVhfXlvJw1WL7IHsDAMAAFMz242F9Pz//1NQjYX8/v//UFP/dQjocBoA AIPEFDldDHVtOV0QdT+Nhfz+//9Q6NwZAAA7w1l0B4icBfv+//+Nhfj9//9TUFONhfz+//9T UOg1GgAAjYX4/f//UOh63v//g8QY6w2NhfT8//9Q6Gne//9ZhcB0GGoBaADQBwD/NdgzSQD/ dQjomOb//4PEEGoBWFvJw1ZXi3wkDGoBXmhuCUEAV+iu3f//WYXAWXQlaG0JQQBX6J3d//9Z hcBZdAIz9lZoJ15AAFfoHeD//4PEDGoBWF9ew1WL7IHsDAsAAItFFFNWV/91DDPbiRiNhfT0 //9Q6CYYAACNhfT0//9oRPBAAFDoJRgAAP91EI2F9PT//1DoFhgAAI2F9Pj//2gABAAAUI2F 9PT//1NQaAIAAIDoh+b//42F9Pj//1CNhfz+//9Q6NUXAACDxDSNhfT4//9oBAEAAFCNhfz+ //9Q/xXI0EAAvosJQQBTVugL1f//iUUUjYX0/P//U1BTjYX0+P//U1Do/xgAAIPEHDP/OV0U fitXVuix1P//OBhZWXQTUI2F9Pz//1DoqNz//1mFwFl1Bkc7fRR82jt9FHwkjYX0+P//aCMN QQBQ6Ibc//9ZhcBZdA2NhfT4//9Q6F/4//9ZU42F+P3//1NQjYX8/v//UI2F9Pj//1DoihgA AI2F+P3//1CNhfz+//9Q6BwXAACNhfz+//9Q6Hb+//+DxCBo6AMAAP8VLNFAAGoBWF9eW8nD VYvsgewIAQAAgKX4/v//AI2F+P7//2oBUOhf3P//jUX8UI2F+P7//2gIX0AAUGgCAACA6PPl //+DxBhogO42AP8VLNFAAOvBVYvsg30MAHU0g30QAHUIagX/FSzRQAD/dQjoftz//4XAWXwU g/gDfQ//dQho7DdJAOhsFgAAWVlqAVhdw/91COjT/f//hcBZdAQzwF3DM8A5RRAPlMBdw1WL 7IHsDAEAAICl9P7//wBTjYX0/v//aAQBAABQagFobQlBAOhP0///WVlQaFICQQBoAgAAgOiu 5P//jYX0/v//UOh5/f//D76F9P7//4qd9v7//1DobhkAAIPEHINl+ACIRf+KRfgEYTpF/3Q8 gKX2/v//AIiF9P7//42F9P7//1D/FczQQACD+AOInfb+//91F/91CI2F9P7//2iuYEAAUOhv 3f//g8QM/0X4g334GnyxM8BbycIEAFZohQlBAP90JBDogRUAAIt0JBBW6GcWAACDxAwzyYXA fguAPDFAdAVBO8h89Ug7yHwEM8Bew41EMQFQ/3QkEOhcFQAAWVlqAVhew1WL7IHsFAIAAIA9 1DJJAABWD4SbAAAAgD3QMUkAAA+EjgAAAIN9EACLdQh0ElboA7b///91DFbo0sD//4PEDGpk aAABAABqGWjUMkkAjY3s/f//6NjJ//9qBGoKjUWcagNQ6L3U//+DxBCNRZyNjez9//9Q6DvO //+DxmSNjez9//9W6OrO//9o0DFJAI2N7P3//+gxzv//jY3s/f//6MTK//+FwHQQjY3s/f// 6FDK//8zwF7Jw/91DOh2FQAAWVCNjez9////dQzo9Mr//42N7P3//4vw6CbK//8zwIX2D5TA 689Vi+yB7BgDAABWi3UIjYXo/P//UFbotv7//1mFwFl1BzPA6boAAACDfRAAdBJW6B61//// dQxW6O2///+DxAxqZGgAAQAAjYXo/P//ahlQjY3s/f//6PHI//9qBGoKjUWcagNQ6NbT//+D xBCNRZyNjez9//9Q6FTN//+NRmSNjez9//9Q6APO//9WjY3s/f//6E7N//+Njez9///o4cn/ /4XAdBCNjez9///obcn//+lr/////3UM6JMUAABZUI2N7P3///91DOgRyv//jY3s/f//i/Do Q8n//zPAhfYPlMBeycNVi+yB7AAIAACApQD4//8AgKUA/P//AI2FAPj//1D/dQjoxv3//42F APz//1D/dQzot/3//42FAPz//1CNhQD4//9Q6ARlAACDxBj32BvAQMnDg+wQVVZXg0wkGP+9 ABAAAGoBVb7U8EAA/3QkKDP/iXwkIFbops///4PEEIXAD4XvAAAAV1boTtD//1k7x1mJRCQQ D46yAAAAUzPbhf+JXCQQfjNTVuj+z///WVlQV1bo9M///1lZUOhC////WYXAWXQIx0QkEAEA AABDO9981IN8JBAAdUxqAY1fATtcJBhYiUQkEH0uU1bou8///1lZUFdW6LHP//9ZWVDo//7/ /1mFwFl0BP9EJBBDO1wkFHzWi0QkEDtEJBh+CIlEJBiJfCQcRzt8JBQPjGz///+DfCQYAFt+ FYN8JBgAfA5V/3QkHFbow8///4PEDDP/agFV/3QkKFboxc7//4PEEIXAdRJVav9W6KHP//+D xAxHg/8KfNpqAVhfXl2DxBDDgewEAgAAU1VWV8dEJBABAAAAMtu+Xg5BAL0EAQAAvwEAAID/ dCQQjUQkGIgd1DJJAIgd0DFJAFZo6ChBAFDoBBYAAIPEEFVo1DJJAGoBVujYzv//WVlQjUQk IFBX6Dvg//+DxBQ4HdQySQB0J1Vo0DFJAGoCVuixzv//WVlQjUQkIFBX6BTg//+DxBQ4HdAx SQB1F/9EJBCDfCQQCX6EiB3UMkkAiB3QMUkAX15dW4HEBAIAAMNVi+y4IDAAAOhLGQAAU1ZX aAAAEADobRkAADPbWTvDiUXsdQlfXjPAW8nCBADo8O3//4XAdQ1oYOoAAP8VLNFAAOvqaADQ BwD/NdgzSQDo0/X//1lZagHoovr//+jp/v//jYWI8///aAQBAABQU/8VFNFAAI2F3P7//1Do D9j//1mJXfi+JAkAAOiU7f//hcB1Cmhg6gAA6YcDAACNhdz+//9Q6LPX//+FwFl1Wo2F3P7/ /1NQjYWI8///UP8VfNBAAI2F3P7//2ogUP8VgNBAAI2F3P7//2gAUAEAUOjb6P//U+jG4P// M9K5ACgAAPfxjYXc/v//gcIAUgEAUlDoYtn//4PEFFP/NdgzSQDok83//zlF+FlZiUXoD439 AgAAaHoiAACNheDP//9owPBAAFDowRQAAI2F4M///4id9N///1CNhdz+//9Q6K3v//9WjYWM 9P//U1Doig8AAP91+P812DNJAOgKzf//g8QoOBiJReQPhJUCAABQjYXw9P//UOjBDwAAU+gh 4P//M9KDxAz3deg7Vfh1AUI7Veh8AjPSUv812DNJAOjIzP//i/hZWTgfdRBT/zXYM0kA6LTM //9Zi/hZjYXc/v//UI2FOPr//1Dobw8AAI2FVPX//1dQ6GIPAACNhYz0//9XUOhVDwAAagGN hYz0////dexQ6P/5//+DxCSFwA+FAAIAAFaNhYz0//9TUOjLDgAAjYXc/v//UI2FOPr//1Do GA8AAI2FVPX//1dQ6AsPAACNhYz0//9XUOj+DgAA/3XkjYXw9P//UOjvDgAAagGNhYz0//// dexQ6H76//+DxDiFwHQMV+in+///WemSAQAAU2jU8EAA6B7M//+DTeD/WVmJRfSJXfBWjYWM 9P//U1DoRg4AAI2F3P7//1CNhTj6//9Q6JMOAACNhVT1//9XUOiGDgAA/3XkjYXw9P//UOh3 DgAAU+jX3v//M9KDxCj3dfQ7VeCJVfx1BEKJVfw7VfR8A4ld/P91/GjU8EAA6HbL//9QjYWM 9P//UOg7DgAAagGNhYz0////dexQ6Mr5//+DxByFwHUT/0Xwi0X8g33wBolF4A+MXP///4N9 8AYPjM0AAABTaCwOQQDoWcv//1OJRfToWN7//zPSg8QM93X0O1X0iVX8fAOJXfyNhVzy//9Q jYWw/f//UFfoM9L//42FsP3//2g08EAAUOjKDQAA/3X8aCwOQQDo28r//1CNhbD9//9Q6LAN AABWjYWM9P//U1DoMg0AAI2F3P7//1CNhTj6//9Q6H8NAACNhVT1//9XUOhyDQAAg8RAjYXw 9P///3XkUOhgDQAAjYWw/f//UI2FjPT//1DoTQ0AAGoBjYWM9P///3XsUOjc+P//g8Qc/0X4 i0X4O0XoD4wD/f//aMAnCQD/FSzRQADpW/z//1WL7IHsYAUAAGah9ChBAFZXagdmiUWgWTPA jX2i86tmq6HwKEEAjX3oiUXkM8CrZqsz/8dF4CAAAAA5PfA4SQCJffSJffgPhd8BAAA5PQg5 SQAPhNMBAACLdQg793QljUXgUI1FgFD/FWTQQACNRYBQjUYCUOhwXgAAWYXAWQ+EpwEAAI2F WP///4NN0P+JRdiNhbD+//+JRcCNhbD+//+JRciNRYBTUI1FoIl9xFCJfdSJfdzHRcx/AAAA 6GkMAABZjYUY////WWoiUGr/Vos1eNBAAGoBV//Wx0X8AgAAALtE8EAAikX8ahQEQYhF5I2F WP///1CNReRq/1BqAVf/1opF5Go0iEWgjYWw/v//UI1FoGr/UGoBV//WjUX0UI1FwFCNhRj/ //9qAlD/FQg5SQA5fQyJRfAPhN4AAAA7x3VgOX34dVtqAWjcAUEAV+gr3P//WYPgAVCNhaT7 //9Q6MXW//+Nhaj8//9TUOinCwAAjUWgUI2FqPz//1DopwsAAGoBjYWk+///V1CNhaj8//9X UP91COh6vP//g8Q4iUX4OX3wdXVqAWjCDUEAjYWg+v//V1Dob9b///91CI2FrP3//1DoTwsA AI2FrP3//1NQ6FILAACNRaBQjYWs/f//UOhCCwAAjYWs/f//U1DoNQsAAI2FoPr//1CNhaz9 //9Q6CILAABqAWr/jYWs/f//av9Q6PwDAACDxEj/RfyDffwFD4y8/v//W19eycNVi+y4nEMA AOjuEgAAjUUMV1CDTfz//3UIx0X4gD4AAGoDagFfV/91DOgpWwAAhcAPhUABAACNRfhTUI2F ZLz//1CNRfxQ/3UM6ANbAAAz2zld/IldCA+GEQEAAFaNtXi8///2RvgCjUbsdBP/dRBqAlDo if///4PEDOnbAAAAjYXs/P//UI2F8P3//1D/NujZ3v//g8QMhcAPhbsAAAD/dRCNhfD9//9Q 6CP9//9ZWVdo3AFBAFPoldr//1kjx1CNheT6//9Q6DDV//+DxBA5XRAPhIIAAABXjYXk+v// U1CNhez8//9TUI2F8P3//1Do87r//4PEGFdowg1BAFPoTdr//1kjx1CNhej7//9Q6OjU//// No2F9P7//1DoyQkAAI2F9P7//2hE8EAAUOjICQAAjYXo+///UI2F9P7//1DotQkAAFdq/42F 9P7//2r/UOiQAgAAg8Q4/0UIg8Ygi0UIO0X8D4L3/v//Xv91DOjWWQAAW1/Jw2oBWFBqAmoA 6Hr+//+DxAxoAN1tAP8VLNFAADPA6+S4hCMAAOhZEQAAU1VWV41EJBRoBAEAADPbUFP/FRTR QACLPYDQQAC+5DVJAGogVv/XU41EJBhWUP8VfNBAAGogVolEJBj/1zlcJBB0Vmh6IgAAjYQk HAEAAGjA8EAAUOifDQAAjYQkJAEAAIicJDgRAABQVuiP6P//aABQAQBW6ETh//9T6C/Z//8z 0rkAKAAA9/GBwgBSAQBSVujR0f//g8QoVuh85v//WWonVv/XOR3wOEkAv9wzSQB0RVZXaOA0 SQBoAgAAgOiB1///agFokwtBAOioxf//g8QYUP8V9NBAAIvoaJMMQQBV/xU40UAAO8N0BWoB U//QVf8V8NBAADlcJBB1BDPA63U5HfA4SQB0C1NW6MvY//9ZWetfOR34OEkAdVeLLQDQQABq AlNT/9VTU1NTU1ZTagJoEAEAAFNXV1CJRCRE/xVI0EAA/3QkEIs1QNBAAP/WagFTU//Vi+hq EFdV/xU40EAAi/hTU1f/FSTQQABX/9ZV/9ZqAVhfXl1bgcSEIwAAw1WL7FGh8ChBAIlF/IpF CABF/I1F/FD/FczQQACD+AN0DIP4BHQHagFYycIEAGoAjUX8aHpcQABQ6FfP//+DxAxoAHS3 Af8VLNFAAOvgVYvsgexYAgAAVr5SAkEAjYXU/v//VlDoXwcAAGoHVuiFxP//UI2F1P7//1Do WgcAAIClqP3//wCNhaj9//9oLAEAAFCNhdT+//9o8A1BAFBoAgAAgOjA1f//agCNhaj9//9o elxAAFDo2s7//4PEODPAXsnCBABVi+y4kCUAAOgHDwAAi0UQU1aLdQwz21c5XRSJdfyJRfh1 Ef91COiu1///hcBZD4U+AQAAv3QNQQBTV+gixP//WTvzWYlFDH0PU+gb1///M9JZ93UMiVX8 vtwBQQBTVuj+w///OV0QWVmJRQx9D1Po9tb//zPSWfd1DIlV+I2F9P7//1Dows3//42F7Pz/ /8cEJAQBAABQU/8VFNFAAI2F9P7//1NQjYXs/P//UP8VfNBAAIXAD4S3AAAAjYX0/v//aiBQ /xWA0EAAaHoiAACNhXDa//9owPBAAFDo1AoAAI2FcNr//4idhOr//1CNhfT+//9Q6MDl//9T 6GvW//8z0rkAKAAA9/GNhfT+//+BwgBSAQBSUOgHz////3X8V+gOw///UI2F8P3//1Do0wUA AP91+Fbo+ML//1CNhfD9//9Q6M0FAACDxECNhfD9////dRRQjYX0/v//UP91COh34P//jYX0 /v//UOhKzf//g8QUX15bycNq//8VLNFAAOv2VYvsgewgAgAAagRqBY1F6GoCUOhKxf//gKXg /f//AIPEEI2F4P3//2gEAQAAUGoBaG0JQQDod8L//1lZUGhSAkEAaAIAAIDo1tP//4PEFI2F 5P7//1CNRehqAFCNheD9//9Q/xV00EAAjYXk/v//UOjDzP//jYXk/v//UOjyBQAAWVlIeAqA vAXk/v//LnXzhcB+FI2EBeT+//9o3AFBAFDo3QQAAFlZjUX8VlBophUAAGhAE0EA6OMCAAD/ dfyL8I2F5P7//1ZQ6CvL//+DxBiFwHUfjYXk/v//UOjpy////3X8jYXk/v//VlDoCMv//4PE EI2F5P7//2oAUOgT1f//WVlehcB0Fmr/UP8VwNBAAI2F5P7//1DoGsz//1kzwMnCBABVi+xR U1aLNdDQQABXjUX8M/9QV1do/xVAAFdX/9aNRfxQV1doCGZAAFdX/9aNRfxQV1do3m1AAFdX /9aNRfxQV1doZmBAAFdX/9aNRfxQV1dozXFAAFdX/9aNRfxQV1do1W9AAFdX/9Yz241F/FBX U2iIb0AAV1f/1kOD+xp86+hM/v//X15bycNVi+yD7BwzwMdF5BABAACJReyJRfCJRfSJRfiJ RfyNReRQx0XoBAAAAP81HDlJAP8VWNBAAOiT2P//hcB0Begz////ycIEAGh8c0AAaNwzSQD/ FTTQQABqAKMcOUkA6J3////CCABVi+yB7KABAACNhWD+//9QagL/FeDRQADo/+H//4XAdFTo 9fn//4A91ABBAAB0D2jUAEEA6PTm//+FwFl1N4M9+DhJAAB0IINl+ACDZfwAjUXwx0Xw3DNJ AFDHRfTDc0AA/xUE0EAA6PvX//+FwHQF6Jv+//8zwMnCEABVi+y4jDgBAOj2CgAAU1b/dQzo GwsAAIvYM/Y73lmJXfSJdfiJdfx1BzPA6dsAAABXaIA4AQCNhXTH/v9WUOhQAgAAg8QMM8CN vXjH/v87RQxzZotNCIoMCITJdA2IDB5GQIl1/DtFDHLpO0UMc0qLyItVCIA8EQB1BkE7TQxy 8YvRK9CD+gpzETvBc8GLVQiKFBCIFB5GQOvvgX34ECcAAHMP/0X4iUf8iReDxwiLweuciXX8 M/brSItF+Il1/Iv4wecDjVw3BFPoZAoAAIvwi0X4V4kGjYV0x/7/UI1GBFDovQYAAP91/I1E NwT/dfRQ6K0GAACLRRCDxByJGItd9FPohwYAAFmLxl9eW8nDVYvsg+wMU4tdCFZXiwMz0ov4 jUsEwecDiVX8iU30jXcEiUX4OXUMcwczwOmcAAAAhcB2I4vxiUUIiw470XMHK8oD0QFN/ItG BIXAdgID0IPGCP9NCHXii0UMK8eDwPw5RfyJRQxzBStF/APQi0UQM/YhdfxSiRDopwkAAI18 HwSLXfiF21l2LotN9Dsxcw+LVfyKFDqIFDBG/0X86+0z0jlRBHYLgCQwAEZCO1EEcvWDwQhL ddWLTfw7TQxzDgPwihQ5iBZGQTtNDHL0X15bycPM/yUc0UAA/yUM0UAA/yUQ0UAA/yUA0UAA zMzMzMzMzMzMzItUJASLTCQI98IDAAAAdTyLAjoBdS4KwHQmOmEBdSUK5HQdwegQOkECdRkK wHQROmEDdRCDwQSDwgQK5HXSi/8zwMOQG8DR4EDDi//3wgEAAAB0FIoCQjoBdelBCsB04PfC AgAAAHSoZosCg8ICOgF10grAdMo6YQF1yQrkdMGDwQLrjMzMzMzMzMzMzMzMzItUJAyLTCQE hdJ0RzPAikQkCFeL+YP6BHIt99mD4QN0CCvRiAdHSXX6i8jB4AgDwYvIweAQA8GLyoPiA8Hp AnQG86uF0nQGiAdHSnX6i0QkCF/Di0QkBMPMzMzMzMzMzFeLfCQI62qNpCQAAAAAi/+LTCQE V/fBAwAAAHQPigFBhMB0O/fBAwAAAHXxiwG6//7+fgPQg/D/M8KDwQSpAAEBgXToi0H8hMB0 I4TkdBqpAAD/AHQOqQAAAP90AuvNjXn/6w2Nef7rCI15/esDjXn8i0wkDPfBAwAAAHQZihFB hNJ0ZIgXR/fBAwAAAHXu6wWJF4PHBLr//v5+iwED0IPw/zPCixGDwQSpAAEBgXThhNJ0NIT2 dCf3wgAA/wB0EvfCAAAA/3QC68eJF4tEJAhfw2aJF4tEJAjGRwIAX8NmiReLRCQIX8OIF4tE JAhfw4tMJAT3wQMAAAB0FIoBQYTAdED3wQMAAAB18QUAAAAAiwG6//7+fgPQg/D/M8KDwQSp AAEBgXToi0H8hMB0MoTkdCSpAAD/AHQTqQAAAP90AuvNjUH/i0wkBCvBw41B/otMJAQrwcON Qf2LTCQEK8HDjUH8i0wkBCvBw1WL7FGDZfwAU4tdCFZXU+hx////g/gBWXIhgHsBOnUbi3UM hfZ0EGoCU1bojBAAAIPEDIBmAgBDQ+sKi0UMhcB0A4AgAINlDACAOwCLw77/AAAAiUUIdGWK CA+20faCYU1JAAR0A0DrGoD5L3QPgPlcdAqA+S51C4lF/OsGjUgBiU0MQIA4AHXPi30MiUUI hf90KoN9EAB0Hyv7O/5yAov+V1P/dRDoERAAAItFEIPEDIAkBwCLRQiLXQzrCotNEIXJdAOA IQCLffyF/3RMO/tySIN9FAB0Hyv7O/5yAov+V1P/dRTo0g8AAItFFIPEDIAkBwCLRQiLfRiF /3REK0X8O8ZzAovwVv91/Ffoqw8AAIPEDIAkPgDrKIt9FIX/dBcrwzvGcwKL8FZTV+iLDwAA g8QMgCQ+AItFGIXAdAOAIABfXlvJw1WL7FGDPTw5SQAAU3Udi0UIg/hhD4yvAAAAg/h6D4+m AAAAg+gg6Z4AAACLXQiB+wABAAB9KIM9HCxBAAF+DGoCU+gHEgAAWVnrC6EQKkEAigRYg+AC hcB1BIvD62uLFRAqQQCLw8H4CA+2yPZESgGAdA6AZQoAiEUIiF0JagLrCYBlCQCIXQhqAViN TfxqAWoAagNRUI1FCFBoAAIAAP81PDlJAOhVDwAAg8QghcB0qYP4AXUGD7ZF/OsND7ZF/Q+2 TfzB4AgLwVvJw1WL7FGDPTw5SQAAU1ZXdR2LRQiD+EEPjKoAAACD+FoPj6EAAACDwCDpmQAA AItdCL8AAQAAagE73159JTk1HCxBAH4LVlPoNxEAAFlZ6wqhECpBAIoEWCPGhcB1BIvD62WL FRAqQQCLw8H4CA+2yPZESgGAdA+AZQoAagKIRQiIXQlY6wmAZQkAiF0Ii8ZWagCNTfxqA1FQ jUUIUFf/NTw5SQDoiw4AAIPEIIXAdK47xnUGD7ZF/OsND7ZF/Q+2TfzB4AgLwV9eW8nDVYvs g+wgi0UIVolF6IlF4I1FEMdF7EIAAABQjUXg/3UMx0Xk////f1DoExIAAIPEDP9N5IvweAiL ReCAIADrDY1F4FBqAOjhEAAAWVmLxl7Jw/90JATo8BkAAFnDzMzMzMzMzMzMzFWL7FdWi3UM i00Qi30Ii8GL0QPGO/52CDv4D4J4AQAA98cDAAAAdRTB6QKD4gOD+QhyKfOl/ySVSH1AAIvH ugMAAACD6QRyDIPgAwPI/ySFYHxAAP8kjVh9QACQ/ySN3HxAAJBwfEAAnHxAAMB8QAAj0YoG iAeKRgGIRwGKRgLB6QKIRwKDxgODxwOD+QhyzPOl/ySVSH1AAI1JACPRigaIB4pGAcHpAohH AYPGAoPHAoP5CHKm86X/JJVIfUAAkCPRigaIB0bB6QJHg/kIcozzpf8klUh9QACNSQA/fUAA LH1AACR9QAAcfUAAFH1AAAx9QAAEfUAA/HxAAItEjuSJRI/ki0SO6IlEj+iLRI7siUSP7ItE jvCJRI/wi0SO9IlEj/SLRI74iUSP+ItEjvyJRI/8jQSNAAAAAAPwA/j/JJVIfUAAi/9YfUAA YH1AAGx9QACAfUAAi0UIXl/Jw5CKBogHi0UIXl/Jw5CKBogHikYBiEcBi0UIXl/Jw41JAIoG iAeKRgGIRwGKRgKIRwKLRQheX8nDkI10MfyNfDn898cDAAAAdSTB6QKD4gOD+QhyDf3zpfz/ JJXgfkAAi//32f8kjZB+QACNSQCLx7oDAAAAg/kEcgyD4AMryP8kheh9QAD/JI3gfkAAkPh9 QAAYfkAAQH5AAIpGAyPRiEcDTsHpAk+D+Qhytv3zpfz/JJXgfkAAjUkAikYDI9GIRwOKRgLB 6QKIRwKD7gKD7wKD+QhyjP3zpfz/JJXgfkAAkIpGAyPRiEcDikYCiEcCikYBwekCiEcBg+4D g+8Dg/kID4Ja/////fOl/P8kleB+QACNSQCUfkAAnH5AAKR+QACsfkAAtH5AALx+QADEfkAA 135AAItEjhyJRI8ci0SOGIlEjxiLRI4UiUSPFItEjhCJRI8Qi0SODIlEjwyLRI4IiUSPCItE jgSJRI8EjQSNAAAAAAPwA/j/JJXgfkAAi//wfkAA+H5AAAh/QAAcf0AAi0UIXl/Jw5CKRgOI RwOLRQheX8nDjUkAikYDiEcDikYCiEcCi0UIXl/Jw5CKRgOIRwOKRgKIRwKKRgGIRwGLRQhe X8nDi0QkBKMAKUEAw6EAKUEAacD9QwMABcOeJgCjAClBAMH4ECX/fwAAw8zMzFE9ABAAAI1M JAhyFIHpABAAAC0AEAAAhQE9ABAAAHPsK8iLxIUBi+GLCItABFDDagH/dCQI6IsWAABZWcNV i+yD7CCLRQjHRexJAAAAUIlF6IlF4OiH+P//iUXkjUUQUI1F4P91DFDouxYAAIPEEMnDzMzM zMzMzMzMzMzMzMzMVYvsV1aLdQyLTRCLfQiLwYvRA8Y7/nYIO/gPgngBAAD3xwMAAAB1FMHp AoPiA4P5CHIp86X/JJUogUAAi8e6AwAAAIPpBHIMg+ADA8j/JIVAgEAA/ySNOIFAAJD/JI28 gEAAkFCAQAB8gEAAoIBAACPRigaIB4pGAYhHAYpGAsHpAohHAoPGA4PHA4P5CHLM86X/JJUo gUAAjUkAI9GKBogHikYBwekCiEcBg8YCg8cCg/kIcqbzpf8klSiBQACQI9GKBogHRsHpAkeD +QhyjPOl/ySVKIFAAI1JAB+BQAAMgUAABIFAAPyAQAD0gEAA7IBAAOSAQADcgEAAi0SO5IlE j+SLRI7oiUSP6ItEjuyJRI/si0SO8IlEj/CLRI70iUSP9ItEjviJRI/4i0SO/IlEj/yNBI0A AAAAA/AD+P8klSiBQACL/ziBQABAgUAATIFAAGCBQACLRQheX8nDkIoGiAeLRQheX8nDkIoG iAeKRgGIRwGLRQheX8nDjUkAigaIB4pGAYhHAYpGAohHAotFCF5fycOQjXQx/I18Ofz3xwMA AAB1JMHpAoPiA4P5CHIN/fOl/P8klcCCQACL//fZ/ySNcIJAAI1JAIvHugMAAACD+QRyDIPg AyvI/ySFyIFAAP8kjcCCQACQ2IFAAPiBQAAggkAAikYDI9GIRwNOwekCT4P5CHK2/fOl/P8k lcCCQACNSQCKRgMj0YhHA4pGAsHpAohHAoPuAoPvAoP5CHKM/fOl/P8klcCCQACQikYDI9GI RwOKRgKIRwKKRgHB6QKIRwGD7gOD7wOD+QgPglr////986X8/ySVwIJAAI1JAHSCQAB8gkAA hIJAAIyCQACUgkAAnIJAAKSCQAC3gkAAi0SOHIlEjxyLRI4YiUSPGItEjhSJRI8Ui0SOEIlE jxCLRI4MiUSPDItEjgiJRI8Ii0SOBIlEjwSNBI0AAAAAA/AD+P8klcCCQACL/9CCQADYgkAA 6IJAAPyCQACLRQheX8nDkIpGA4hHA4tFCF5fycONSQCKRgOIRwOKRgKIRwKLRQheX8nDkIpG A4hHA4pGAohHAopGAYhHAYtFCF5fycODPRwsQQABfhFoAwEAAP90JAjoJAkAAFlZw4tEJASL DRAqQQBmiwRBJQMBAADDgz0cLEEAAX4OagT/dCQI6PkIAABZWcOLRCQEiw0QKkEAigRBg+AE w4M9HCxBAAF+DmoI/3QkCOjRCAAAWVnDi0QkBIsNECpBAIoEQYPgCMPMzMzMzMzMzMzMzMzM i0wkCFdTVooRi3wkEITSdGmKcQGE9nRPi/eLTCQUigdGONB0FYTAdAuKBkY40HQKhMB19V5b XzPAw4oGRjjwdeuNfv+KYQKE5HQoigaDxgI44HXEikEDhMB0GIpm/4PBAjjgdN/rsTPAXltf isLpQx0AAI1H/15bX8OLx15bX8NVi+xXVlOLTRDjJovZi30Ii/czwPKu99kDy4v+i3UM86aK Rv8zyTpH/3cEdARJSffRi8FbXl/Jw1WL7Gr/aEDSQABoBKxAAGShAAAAAFBkiSUAAAAAg+xY U1ZXiWXo/xW80EAAM9KK1IkVbDlJAIvIgeH/AAAAiQ1oOUkAweEIA8qJDWQ5SQDB6BCjYDlJ ADP2VugWJgAAWYXAdQhqHOiwAAAAWYl1/OhWJAAA/xXE0EAAo2hOSQDoFCMAAKMgOUkA6L0g AADo/x8AAOgcHQAAiXXQjUWkUP8VeNFAAOiQHwAAiUWc9kXQAXQGD7dF1OsDagpYUP91nFZW /xV00UAAUOi87v//iUWgUOgKHQAAi0XsiwiLCYlNmFBR6M4dAABZWcOLZej/dZjo/BwAAIM9 KDlJAAF1BeiAJwAA/3QkBOiwJwAAaP8AAAD/FRApQQBZWcODPSg5SQABdQXoWycAAP90JATo iycAAFlo/wAAAP8VfNFAAMNVi+yD7BhTVlf/dQjoiAEAAIvwWTs1OExJAIl1CA+EagEAADPb O/MPhFYBAAAz0rggKUEAOTB0coPAMEI9ECpBAHzxjUXoUFb/FYDRQACD+AEPhSQBAABqQDPA Wb9gTUkAg33oAYk1OExJAPOrqokdZE5JAA+G7wAAAIB97gAPhLsAAACNTe+KEYTSD4SuAAAA D7ZB/w+20jvCD4eTAAAAgIhhTUkABEDr7mpAM8BZv2BNSQDzq400Uold/MHmBKqNnjApQQCA OwCLy3QsilEBhNJ0JQ+2AQ+2+jvHdxSLVfyKkhgpQQAIkGFNSQBAO8d29UFBgDkAddT/RfyD wwiDffwEcsGLRQjHBUxMSQABAAAAUKM4TEkA6MYAAACNtiQpQQC/QExJAKWlWaNkTkkApetV QUGAef8AD4VI////agFYgIhhTUkACEA9/wAAAHLxVuiMAAAAWaNkTkkAxwVMTEkAAQAAAOsG iR1MTEkAM8C/QExJAKurq+sNOR0sOUkAdA7ojgAAAOiyAAAAM8DrA4PI/19eW8nDi0QkBIMl LDlJAACD+P51EMcFLDlJAAEAAAD/JYjRQACD+P11EMcFLDlJAAEAAAD/JYTRQACD+Px1D6FM OUkAxwUsOUkAAQAAAMOLRCQELaQDAAB0IoPoBHQXg+gNdAxIdAMzwMO4BAQAAMO4EgQAAMO4 BAgAAMO4EQQAAMNXakBZM8C/YE1JAPOrqjPAv0BMSQCjOExJAKNMTEkAo2ROSQCrq6tfw1WL 7IHsFAUAAI1F7FZQ/zU4TEkA/xWA0UAAg/gBD4UWAQAAM8C+AAEAAIiEBez+//9AO8Zy9IpF 8saF7P7//yCEwHQ3U1eNVfMPtgoPtsA7wXcdK8iNvAXs/v//QbggICAgi9nB6QLzq4vLg+ED 86pCQopC/4TAddBfW2oAjYXs+v///zVkTkkA/zU4TEkAUI2F7P7//1ZQagHo8yUAAGoAjYXs /f///zU4TEkAVlCNhez+//9WUFb/NWROSQDoaAEAAGoAjYXs/P///zU4TEkAVlCNhez+//9W UGgAAgAA/zVkTkkA6EABAACDxFwzwI2N7Pr//2aLEfbCAXQWgIhhTUkAEIqUBez9//+IkGBM SQDrHPbCAnQQgIhhTUkAIIqUBez8///r44CgYExJAABAQUE7xnK/60kzwL4AAQAAg/hBchmD +Fp3FICIYU1JABCKyIDBIIiIYExJAOsfg/hhchOD+Hp3DoCIYU1JACCKyIDpIOvggKBgTEkA AEA7xnK+XsnDgz0oTEkAAHUSav3oLPz//1nHBShMSQABAAAAw1WL7IM9TExJAABXi30IiX0I dRH/dRD/dQxX6ComAACDxAzrY4tVEFaF0nQ9i00MigFKD7bw9oZhTUkABIgHdBNHQYXSdBmK AUqIB0dBhMB0FOsGR0GEwHQQhdJ10usKgGf/AOsEgGf+AIvCSoXAXnQTjUoBM8CL0cHpAvOr i8qD4QPzqotFCF9dw1WL7Gr/aFjSQABoBKxAAGShAAAAAFBkiSUAAAAAg+wcU1ZXiWXoM/85 PTA5SQB1RldXagFbU2hQ0kAAvgABAABWV/8VPNFAAIXAdAiJHTA5SQDrIldXU2hM0kAAVlf/ FUDRQACFwA+EIgEAAMcFMDlJAAIAAAA5fRR+EP91FP91EOieAQAAWVmJRRShMDlJAIP4AnUd /3Uc/3UY/3UU/3UQ/3UM/3UI/xVA0UAA6d4AAACD+AEPhdMAAAA5fSB1CKFMOUkAiUUgV1f/ dRT/dRCLRST32BvAg+AIQFD/dSD/FXjQQACL2Ild5DvfD4ScAAAAiX38jQQbg8ADJPzoXfT/ /4ll6IvEiUXcg038/+sTagFYw4tl6DP/iX3cg038/4td5Dl93HRmU/913P91FP91EGoB/3Ug /xV40EAAhcB0TVdXU/913P91DP91CP8VPNFAAIvwiXXYO/d0MvZFDQR0QDl9HA+EsgAAADt1 HH8e/3Uc/3UYU/913P91DP91CP8VPNFAAIXAD4WPAAAAM8CNZciLTfBkiQ0AAAAAX15bycPH RfwBAAAAjQQ2g8ADJPzoqfP//4ll6IvciV3gg038/+sSagFYw4tl6DP/M9uDTfz/i3XYO990 tFZT/3Xk/3Xc/3UM/3UI/xU80UAAhcB0nDl9HFdXdQRXV+sG/3Uc/3UYVlNoIAIAAP91IP8V oNBAAIvwO/cPhHH///+Lxuls////i1QkCItEJASF0laNSv90DYA4AHQIQIvxSYX2dfOAOABe dQUrRCQEw4vCw1WL7FGLRQiNSAGB+QABAAB3DIsNECpBAA+3BEHrUovIVos1ECpBAMH5CA+2 0fZEVgGAXnQOgGX+AIhN/IhF/WoC6wmAZf0AiEX8agFYjU0KagFqAGoAUVCNRfxQagHotSEA AIPEHIXAdQLJww+3RQojRQzJw1WL7FNWi3UMi0YMi14QqIIPhPMAAACoQA+F6wAAAKgBdBaD ZgQAqBAPhNsAAACLTggk/okOiUYMi0YMg2YEAINlDAAk7wwCZqkMAYlGDHUigf6gLUEAdAiB /sAtQQB1C1PoHiYAAIXAWXUHVujPJQAAWWb3RgwIAVd0ZItGCIs+K/iNSAGJDotOGEmF/4lO BH4QV1BT6PkjAACDxAyJRQzrM4P7/3QWi8OLy8H4BYPhH4sEhSBLSQCNBMjrBbjILEEA9kAE IHQNagJqAFPoJyMAAIPEDItGCIpNCIgI6xRqAY1FCF9XUFPopiMAAIPEDIlFDDl9DF90BoNO DCDrD4tFCCX/AAAA6wgMIIlGDIPI/15bXcNVi+yB7EgCAABTVleLfQwz9oofR4TbiXX0iXXs iX0MD4T0BgAAi03wM9LrCItN8It10DPSOVXsD4zcBgAAgPsgfBOA+3h/Dg++w4qAUNJAAIPg D+sCM8APvoTGcNJAAMH4BIP4B4lF0A+HmgYAAP8khfuUQACDTfD/iVXMiVXYiVXgiVXkiVX8 iVXc6XgGAAAPvsOD6CB0O4PoA3Qtg+gIdB9ISHQSg+gDD4VZBgAAg038COlQBgAAg038BOlH BgAAg038Aek+BgAAgE38gOk1BgAAg038AuksBgAAgPsqdSONRRBQ6PUGAACFwFmJReAPjRIG AACDTfwE99iJReDpBAYAAItF4A++y40EgI1EQdDr6YlV8OntBQAAgPsqdR6NRRBQ6LYGAACF wFmJRfAPjdMFAACDTfD/6coFAACNBIkPvsuNREHQiUXw6bgFAACA+0l0LoD7aHQggPtsdBKA +3cPhaAFAACATf0I6ZcFAACDTfwQ6Y4FAACDTfwg6YUFAACAPzZ1FIB/ATR1DkdHgE39gIl9 DOlsBQAAiVXQiw0QKkEAiVXcD7bD9kRBAYB0GY1F7FD/dQgPvsNQ6H8FAACKH4PEDEeJfQyN RexQ/3UID77DUOhmBQAAg8QM6SUFAAAPvsOD+GcPjxwCAACD+GUPjZYAAACD+FgPj+sAAAAP hHgCAACD6EMPhJ8AAABISHRwSEh0bIPoDA+F6QMAAGb3RfwwCHUEgE39CIt18IP+/3UFvv// /3+NRRBQ6JwFAABm90X8EAhZi8iJTfgPhP4BAACFyXUJiw0sLEEAiU34x0XcAQAAAIvBi9ZO hdIPhNQBAABmgzgAD4TKAQAAQEDr58dFzAEAAACAwyCDTfxAjb24/f//O8qJffgPjc8AAADH RfAGAAAA6dEAAABm90X8MAh1BIBN/Qhm90X8EAiNRRBQdDvoMAUAAFCNhbj9//9Q6HUjAACD xAyJRfSFwH0yx0XYAQAAAOspg+hadDKD6Al0xUgPhOgBAADpCAMAAOjYBAAAWYiFuP3//8dF 9AEAAACNhbj9//+JRfjp5wIAAI1FEFDoswQAAIXAWXQzi0gEhcl0LPZF/Qh0Fw+/ANHoiU34 iUX0x0XcAQAAAOm1AgAAg2XcAIlN+A+/AOmjAgAAoSgsQQCJRfhQ6Y4AAAB1DID7Z3UHx0Xw AQAAAItFEP91zIPACIlFEP918ItI+IlNuItA/IlFvA++w1CNhbj9//9QjUW4UP8VADBBAIt1 /IPEFIHmgAAAAHQUg33wAHUOjYW4/f//UP8VDDBBAFmA+2d1EoX2dQ6Nhbj9//9Q/xUEMEEA WYC9uP3//y11DYBN/QGNvbn9//+JffhX6GHm//9Z6fwBAACD6GkPhNEAAACD6AUPhJ4AAABI D4SEAAAASHRRg+gDD4T9/f//SEgPhLEAAACD6AMPhckBAADHRdQnAAAA6zwrwdH46bQBAACF yXUJiw0oLEEAiU34i8GL1k6F0nQIgDgAdANA6/ErwemPAQAAx0XwCAAAAMdF1AcAAAD2RfyA x0X0EAAAAHRdikXUxkXqMARRx0XkAgAAAIhF6+tI9kX8gMdF9AgAAAB0O4BN/QLrNY1FEFDo GwMAAPZF/CBZdAlmi03sZokI6wWLTeyJCMdF2AEAAADpIwIAAINN/EDHRfQKAAAA9kX9gHQM jUUQUOjtAgAAWetB9kX8IHQh9kX8QI1FEFB0DOjIAgAAWQ+/wJnrJei8AgAAWQ+3wOvy9kX8 QI1FEFB0COinAgAAWevg6J8CAABZM9L2RfxAdBuF0n8XfASFwHMR99iD0gCL8PfagE39AYv6 6wSL8Iv69kX9gHUDg+cAg33wAH0Jx0XwAQAAAOsEg2X894vGC8d1BINl5ACNRbeJRfiLRfD/ TfCFwH8Gi8YLx3Q7i0X0mVJQV1aJRcCJVcTobyEAAP91xIvYg8Mw/3XAV1bo7SAAAIP7OYvw i/p+AwNd1ItF+P9N+IgY67WNRbcrRfj/Rfj2Rf0CiUX0dBmLTfiAOTB1BIXAdQ3/TfhAi034 xgEwiUX0g33YAA+F9AAAAItd/PbDQHQm9scBdAbGReot6xT2wwF0BsZF6ivrCfbDAnQLxkXq IMdF5AEAAACLdeArdeQrdfT2wwx1Eo1F7FD/dQhWaiDoFwEAAIPEEI1F7FCNRer/dQj/deRQ 6DIBAACDxBD2wwh0F/bDBHUSjUXsUP91CFZqMOjlAAAAg8QQg33cAHRBg330AH47i0X0i134 jXj/ZosDQ1CNRchQQ+iWHwAAWYXAWX4yjU3sUf91CFCNRchQ6NgAAACDxBCLx0+FwHXQ6xWN RexQ/3UI/3X0/3X46LoAAACDxBD2RfwEdBKNRexQ/3UIVmog6HEAAACDxBCLfQyKH0eE24l9 DA+FE/n//4tF7F9eW8nDeY9AAE+OQABqjkAAto5AAO2OQAD1jkAAKo9AAL2PQABVi+yLTQz/ SQR4DosRikUIiAL/AQ+2wOsLUf91COiI9///WVmD+P+LRRB1BYMI/13D/wBdw1ZXi3wkEIvH T4XAfiGLdCQYVv90JBj/dCQU6Kz///+DxAyDPv90B4vHT4XAf+NfXsNTi1wkDIvDS1ZXhcB+ Jot8JByLdCQQD74GV0b/dCQcUOh1////g8QMgz//dAeLw0uFwH/iX15bw4tEJASDAASLAItA /MOLRCQEgwAIiwiLQfiLUfzDi0QkBIMABIsAZotA/MNWi3QkCIX2dCRW6MAfAABZhcBWdApQ 6N8fAABZWV7DagD/NQRLSQD/FZDRQABew/81uDpJAP90JAjoAwAAAFlZw4N8JATgdyL/dCQE 6BwAAACFwFl1FjlEJAh0EP90JATodScAAIXAWXXeM8DDVot0JAg7NSAwQQB3C1bopSIAAIXA WXUchfZ1A2oBXoPGD4Pm8FZqAP81BEtJAP8VlNFAAF7DVYvsgezEAQAAgGXrAFNWi3UMM9tX igaJXfyEwIldzA+E4QkAAIt9COsFi30IM9uDPRwsQQABfg8PtsBqCFDohvX//1lZ6w+LDRAq QQAPtsCKBEGD4Ag7w3Q2/038V41F/FdQ6CUKAABZWVDoBgoAAA+2RgFGUOhp7P//g8QMhcB0 Dg+2RgFGUOhX7P//WevugD4lD4XZCAAAgGXLAIBl6ACAZekAgGXyAIBl8QCAZeoAM/+AZfsA iV3kiV3giV30xkXzAYld0A+2XgFGgz0cLEEAAX4PD7bDagRQ6On0//9ZWesPiw0QKkEAD7bD igRBg+AEhcB0EotF9P9F4I0EgI1EQ9CJRfTrZYP7Tn8+dF6D+yp0MoP7RnRUg/tJdAqD+0x1 N/5F8+tFgH4BNnUsgH4CNI1GAnUj/0XQg2XYAINl3ACL8Osn/kXy6yKD+2h0F4P7bHQKg/t3 dAj+RfHrDv5F8/5F++sG/k3z/k37gH3xAA+ET////4B98gCJdQx1EotFEIlFvIPABIlFEItA /IlF1IBl8QCAffsAdRSKBjxTdAo8Q3QGgE37/+sExkX7AYtdDA+2M4POIIP+bol1xHQog/5j dBSD/nt0D/91CI1F/FDotQgAAFnrC/91CP9F/Oh2CAAAWYlF7DPAOUXgdAk5RfQPhNwHAACD /m8Pj14CAAAPhAoFAACD/mMPhCwCAACD/mQPhPgEAAAPjmoCAACD/md+OIP+aXQbg/5uD4VX AgAAgH3yAIt9/A+EAAcAAOkhBwAAamRei13sg/stD4V+AgAAxkXpAel6AgAAi13sjbU8/v// g/stdQ6InTz+//+NtT3+///rBYP7K3UXi30I/030/0X8V+jOBwAAi9hZiV3s6wOLfQiDfeAA dAmBffRdAQAAfgfHRfRdAQAAgz0cLEEAAX4MagRT6Anz//9ZWesLoRAqQQCKBFiD4ASFwHQh i0X0/030hcB0F/9F5IgeRv9F/FfocAcAAIvYWYld7Ou7OB0gLEEAdWaLRfT/TfSFwHRc/0X8 V+hNBwAAi9igICxBAIgGWYld7EaDPRwsQQABfgxqBFPom/L//1lZ6wuhECpBAIoEWIPgBIXA dCGLRfT/TfSFwHQX/0XkiB5G/0X8V+gCBwAAi9hZiV3s67uDfeQAD4SOAAAAg/tldAmD+0UP hYAAAACLRfT/TfSFwHR2xgZlRv9F/FfoywYAAIvYWYP7LYld7HUFiAZG6wWD+yt1HotF9P9N 9IXAdQUhRfTrD/9F/FfongYAAIvYWYld7IM9HCxBAAF+DGoEU+j08f//WVnrC6EQKkEAigRY g+AEhcB0EotF9P9N9IXAdAj/ReSIHkbru/9N/FdT6HIGAACDfeQAWVkPhPYFAACAffIAD4VN BQAA/0XMgCYAjYU8/v//UA++RfP/ddRIUP8VCDBBAIPEDOkpBQAAOUXgdQr/RfTHReABAAAA gH37AH4ExkXqAb84LEEA6QsBAACLxoPocA+EowIAAIPoAw+E6AAAAEhID4SWAgAAg+gDD4TD /f//g+gDdCQPtgM7RewPhT8FAAD+TeuAffIAD4XDBAAAi0W8iUUQ6bgEAACAffsAfgTGReoB i30MR4l9DIA/Xg+FpwAAAIvHjXgB6ZkAAACD+yt1Iv9N9HUMg33gAHQGxkXxAesR/3UI/0X8 6GgFAACL2FmJXeyD+zAPhUUCAAD/dQj/RfzoTgUAAIvYWYD7eIld7HQvgPtYdCqD/njHReQB AAAAdAhqb17pFgIAAP91CP9N/FPoOAUAAFlZajBb6f0BAAD/dQj/RfzoCQUAAFmL2Ild7Gp4 68+AffsAfgTGReoBvzAsQQCATej/aiCNRZxqAFDo7Nr//4PEDIN9xHt1DoA/XXUJsl1HxkWn IOsDilXLigc8XXRfRzwtdUGE0nQ9ig+A+V10Nkc60XMEisHrBIrCitE60HchD7bSD7bwK/JG i8qLwoPhB7MBwegD0uONRAWcCBhCTnXoMtLrtA+2yIrQi8GD4QezAcHoA9LjjUQFnAgY65uA PwAPhAEEAACDfcR7dQOJfQyLfQiLddT/TfxX/3XsiXXQ6FMEAABZWYN94AB0DotF9P9N9IXA D4ScAAAA/0X8V+gaBAAAg/j/WYlF7HR+i8hqAYPhB1oPvl3o0+KLyMH5Aw++TA2cM8uF0XRg gH3yAHVSgH3qAHRBiw0QKkEAiEXID7bA9kRBAYB0Df9F/FfoywMAAFmIRcn/NRwsQQCNRchQ jUXCUOiqIAAAZotFwoPEDGaJBkZG6wOIBkaJddTpZP////9F0Olc/////038V1DoowMAAFlZ OXXQD4QoAwAAgH3yAA+FfwIAAP9FzIN9xGMPhHICAACAfeoAi0XUdAlmgyAA6WACAACAIADp WAIAAMZF8wGLXeyD+y11BsZF6QHrBYP7K3Ui/030dQyDfeAAdAbGRfEB6xH/dQj/RfzoGgMA AFmL2Ild7IN90AAPhA8BAACAffEAD4XjAAAAg/54dU+DPRwsQQABfg9ogAAAAFPoVO7//1lZ 6w2hECpBAIoEWCWAAAAAhcAPhKMAAACLRdiLVdxqBFnozSAAAFOJRdiJVdzofQIAAIvYWYld 7OtTgz0cLEEAAX4MagRT6Aju//9ZWesLoRAqQQCKBFiD4ASFwHRdg/5vdRWD+zh9U4tF2ItV 3GoDWeh9IAAA6w9qAGoK/3Xc/3XY6CwgAACJRdiJVdz/ReSNQ9CZAUXYEVXcg33gAHQF/030 dCT/dQj/RfzoNgIAAIvYWYld7Okr/////3UI/038U+g5AgAAWVmAfekAD4TcAAAAi0XYi03c 99iD0QCJRdj32YlN3OnEAAAAgH3xAA+FsgAAAIP+eHQ/g/5wdDqDPRwsQQABfgxqBFPoQ+3/ /1lZ6wuhECpBAIoEWIPgBIXAdHaD/m91CoP7OH1swecD6z+NPL/R5+s4gz0cLEEAAX4PaIAA AABT6Abt//9ZWesNoRAqQQCKBFglgAAAAIXAdDdTwecE6EQBAACL2FmJXez/ReSDfeAAjXwf 0HQF/030dCT/dQj/RfzoWAEAAIvYWYld7Olc/////3UI/038U+hbAQAAWVmAfekAdAL334P+ RnUEg2XkAIN95AAPhM4AAACAffIAdSn/RcyDfdAAdBCLRdSLTdiJCItN3IlIBOsQgH3zAItF 1HQEiTjrA2aJOP5F6/9FDIt1DOtC/0X8V+jhAAAAi9hZD7YGRjvDiV3siXUMdVWLDRAqQQAP tsP2REEBgHQY/0X8V+i3AAAAWQ+2DkY7yIl1DHU+/038g33s/3UQgD4ldU2LRQyAeAFudUSL 8IoGhMAPhVb2///rMP91CP9N/P917OsF/038V1PoiwAAAFlZ6xf/TfxXUOh9AAAA/038V1Po cwAAAIPEEIN97P91EYtFzIXAdQ04Ret1CIPI/+sDi0XMX15bycODPRwsQQABVn4Qi3QkCGoE VuiO6///WVnrD4t0JAihECpBAIoEcIPgBIXAdQaD5t+D7geLxl7Di1QkBP9KBHgJiwoPtgFB iQrDUugUHgAAWcODfCQE/3QP/3QkCP90JAjo1x4AAFlZw1aLdCQIV/90JBD/Bui+////i/hX 6D7i//9ZhcBZdeeLx19ew8zMzMzMzMzMjUL/W8ONpCQAAAAAjWQkADPAikQkCFOL2MHgCItU JAj3wgMAAAB0E4oKQjjZdNGEyXRR98IDAAAAde0L2FeLw8HjEFYL2IsKv//+/n6LwYv3M8sD 8AP5g/H/g/D/M88zxoPCBIHhAAEBgXUcJQABAYF00yUAAQEBdQiB5gAAAIB1xF5fWzPAw4tC /DjYdDaEwHTvONx0J4TkdOfB6BA42HQVhMB03DjcdAaE5HTU65ZeX41C/1vDjUL+Xl9bw41C /V5fW8ONQvxeX1vDoTRMSQCFwHQC/9BoFPBAAGgI8EAA6M4AAABoBPBAAGgA8EAA6L8AAACD xBDDagBqAP90JAzoFQAAAIPEDMNqAGoB/3QkDOgEAAAAg8QMw1dqAV85PZw5SQB1Ef90JAj/ FazQQABQ/xUo0UAAg3wkDABTi1wkFIk9mDlJAIgdlDlJAHU8oTBMSQCFwHQiiw0sTEkAVo1x /DvwchOLBoXAdAL/0IPuBDs1MExJAHPtXmgg8EAAaBjwQADoKgAAAFlZaCjwQABoJPBAAOgZ AAAAWVmF21t1EP90JAiJPZw5SQD/FXzRQABfw1aLdCQIO3QkDHMNiwaFwHQC/9CDxgTr7V7D VYvsU/91COg1AQAAhcBZD4QgAQAAi1gIhdsPhBUBAACD+wV1DINgCABqAVjpDQEAAIP7AQ+E 9gAAAIsNoDlJAIlNCItNDIkNoDlJAItIBIP5CA+FyAAAAIsNuCxBAIsVvCxBAAPRVjvKfRWN NEkr0Y00tUgsQQCDJgCDxgxKdfeLAIs1xCxBAD2OAADAdQzHBcQsQQCDAAAA63A9kAAAwHUM xwXELEEAgQAAAOtdPZEAAMB1DMcFxCxBAIQAAADrSj2TAADAdQzHBcQsQQCFAAAA6zc9jQAA wHUMxwXELEEAggAAAOskPY8AAMB1DMcFxCxBAIYAAADrET2SAADAdQrHBcQsQQCKAAAA/zXE LEEAagj/01mJNcQsQQBZXusIg2AIAFH/01mLRQijoDlJAIPI/+sJ/3UM/xWY0UAAW13Di1Qk BIsNwCxBADkVQCxBAFa4QCxBAHQVjTRJjTS1QCxBAIPADDvGcwQ5EHX1jQxJXo0MjUAsQQA7 wXMEORB0AjPAw4M9KExJAAB1Bei75P//Vos1aE5JAIoGPCJ1JYpGAUY8InQVhMB0EQ+2wFDo lBsAAIXAWXTmRuvjgD4idQ1G6wo8IHYGRoA+IHf6igaEwHQEPCB26YvGXsNTM9s5HShMSQBW V3UF6F/k//+LNSA5SQAz/4oGOsN0Ejw9dAFHVugr0///WY10BgHr6I0EvQQAAABQ6Orw//+L 8Fk784k1fDlJAHUIagnoEeD//1mLPSA5SQA4H3Q5VVfo8dL//4voWUWAPz10IlXotfD//zvD WYkGdQhqCeji3///WVf/Nujb0f//WYPGBFkD/Tgfdcld/zUgOUkA6Fjw//9ZiR0gOUkAiR5f XscFJExJAAEAAABbw1WL7FFRUzPbOR0oTEkAVld1Beih4///vqQ5SQBoBAEAAFZT/xUU0UAA oWhOSQCJNYw5SQCL/jgYdAKL+I1F+FCNRfxQU1NX6E0AAACLRfiLTfyNBIhQ6BXw//+L8IPE GDvzdQhqCOhA3///WY1F+FCNRfxQi0X8jQSGUFZX6BcAAACLRfyDxBRIiTV0OUkAX16jcDlJ AFvJw1WL7ItNGItFFFNWgyEAi3UQV4t9DMcAAQAAAItFCIX/dAiJN4PHBIl9DIA4InVEilAB QID6InQphNJ0JQ+20vaCYU1JAAR0DP8BhfZ0BooQiBZGQP8BhfZ01YoQiBZG687/AYX2dASA JgBGgDgidUZA60P/AYX2dAWKEIgWRooQQA+22vaDYU1JAAR0DP8BhfZ0BYoYiB5GQID6IHQJ hNJ0CYD6CXXMhNJ1A0jrCIX2dASAZv8Ag2UYAIA4AA+E4AAAAIoQgPogdAWA+gl1A0Dr8YA4 AA+EyAAAAIX/dAiJN4PHBIl9DItVFP8Cx0UIAQAAADPbgDhcdQRAQ+v3gDgidSz2wwF1JTP/ OX0YdA2AeAEijVABdQSLwusDiX0Ii30MM9I5VRgPlMKJVRjR64vTS4XSdA5DhfZ0BMYGXEb/ AUt184oQhNJ0SoN9GAB1CoD6IHQ/gPoJdDqDfQgAdC6F9nQZD7ba9oNhTUkABHQGiBZGQP8B ihCIFkbrDw+20vaCYU1JAAR0A0D/Af8BQOlY////hfZ0BIAmAEb/AekX////hf90A4MnAItF FF9eW/8AXcNRUaGoOkkAU1WLLajRQABWVzPbM/Yz/zvDdTP/1YvwO/N0DMcFqDpJAAEAAADr KP8VpNFAAIv4O/sPhOoAAADHBag6SQACAAAA6Y8AAACD+AEPhYEAAAA783UM/9WL8DvzD4TC AAAAZjkei8Z0DkBAZjkYdflAQGY5GHXyK8aLPaDQQADR+FNTQFNTUFZTU4lEJDT/14voO+t0 MlXogu3//zvDWYlEJBB0I1NTVVD/dCQkVlNT/9eFwHUO/3QkEOgw7f//WYlcJBCLXCQQVv8V oNFAAIvD61OD+AJ1TDv7dQz/FaTRQACL+Dv7dDw4H4vHdApAOBh1+0A4GHX2K8dAi+hV6Bvt //+L8Fk783UEM/brC1VXVuj10v//g8QMV/8VnNFAAIvG6wIzwF9eXVtZWcOD7ERTVVZXaAAB AADo4Oz//4vwWYX2dQhqG+gN3P//WYk1IEtJAMcFIExJACAAAACNhgABAAA78HMagGYEAIMO /8ZGBQqhIEtJAIPGCAUAAQAA6+KNRCQQUP8VeNFAAGaDfCRCAA+ExQAAAItEJESFwA+EuQAA AIswjWgEuAAIAAA78I0cLnwCi/A5NSBMSQB9Ur8kS0kAaAABAADoUOz//4XAWXQ4gwUgTEkA IIkHjYgAAQAAO8FzGIBgBACDCP/GQAUKiw+DwAiBwQABAADr5IPHBDk1IExJAHy76waLNSBM SQAz/4X2fkaLA4P4/3Q2ik0A9sEBdC72wQh1C1D/FWzRQACFwHQei8eLz8H4BYPhH4sEhSBL SQCNBMiLC4kIik0AiEgER0WDwwQ7/ny6M9uhIEtJAIM82P+NNNh1TYXbxkYEgXUFavZY6wqL w0j32BvAg8D1UP8VcNFAAIv4g///dBdX/xVs0UAAhcB0DCX/AAAAiT6D+AJ1BoBOBEDrD4P4 A3UKgE4ECOsEgE4EgEOD+wN8m/81IExJAP8VjNFAAF9eXVuDxETDM8BqADlEJAhoABAAAA+U wFD/FWTRQACFwKMES0kAdBXogwoAAIXAdQ//NQRLSQD/FWjRQAAzwMNqAVjDzMzMVYvsU1ZX VWoAagBoJKtAAP91COieHAAAXV9eW4vlXcOLTCQE90EEBgAAALgBAAAAdA+LRCQIi1QkEIkC uAMAAADDU1ZXi0QkEFBq/mgsq0AAZP81AAAAAGSJJQAAAACLRCQgi1gIi3AMg/7/dC47dCQk dCiNNHaLDLOJTCQIiUgMg3yzBAB1EmgBAQAAi0SzCOhAAAAA/1SzCOvDZI8FAAAAAIPEDF9e W8MzwGSLDQAAAACBeQQsq0AAdRCLUQyLUgw5UQh1BbgBAAAAw1NRu9QsQQDrClNRu9QsQQCL TQiJSwiJQwSJawxZW8IEAMzMVkMyMFhDMDBVi+yD7AhTVldV/ItdDItFCPdABAYAAAAPhYIA AACJRfiLRRCJRfyNRfiJQ/yLcwyLewiD/v90YY0MdoN8jwQAdEVWVY1rEP9UjwRdXotdDAvA dDN4PIt7CFPoqf7//4PEBI1rEFZT6N7+//+DxAiNDHZqAYtEjwjoYf///4sEj4lDDP9UjwiL ewiNDHaLNI/robgAAAAA6xy4AQAAAOsVVY1rEGr/U+ie/v//g8QIXbgBAAAAXV9eW4vlXcNV i0wkCIspi0EcUItBGFDoef7//4PECF3CBAChKDlJAIP4AXQNhcB1KoM9FClBAAF1IWj8AAAA 6BgAAAChrDpJAFmFwHQC/9Bo/wAAAOgCAAAAWcNVi+yB7KQBAACLVQgzybjoLEEAOxB0C4PA CEE9eC1BAHzxVovxweYDO5boLEEAD4UcAQAAoSg5SQCD+AEPhOgAAACFwHUNgz0UKUEAAQ+E 1wAAAIH6/AAAAA+E8QAAAI2FXP7//2gEAQAAUGoA/xUU0UAAhcB1E42FXP7//2i81UAAUOiz yf//WVmNhVz+//9XUI29XP7//+iOyv//QFmD+Dx2KY2FXP7//1Doe8r//4v4jYVc/v//g+g7 agMD+Gi41UAAV+jhAQAAg8QQjYVg////aJzVQABQ6F3J//+NhWD///9XUOhgyf//jYVg//// aJjVQABQ6E/J////tuwsQQCNhWD///9Q6D3J//9oECABAI2FYP///2hw1UAAUOhfEgAAg8Qs X+smjUUIjbbsLEEAagBQ/zbo7sn//1lQ/zZq9P8VcNFAAFD/FWzQQABeycNVi+xq/2jY1UAA aASsQABkoQAAAABQZIklAAAAAIPsGFNWV4ll6KGwOkkAM9s7w3U+jUXkUGoBXlZoUNJAAFb/ FVTRQACFwHQEi8brHY1F5FBWaEzSQABWU/8VWNFAAIXAD4TOAAAAagJYo7A6SQCD+AJ1JItF HDvDdQWhPDlJAP91FP91EP91DP91CFD/FVjRQADpnwAAAIP4AQ+FlAAAADldGHUIoUw5SQCJ RRhTU/91EP91DItFIPfYG8CD4AhAUP91GP8VeNBAAIlF4DvDdGOJXfyNPACLx4PAAyT86BTQ //+JZeiL9Il13FdTVuiUx///g8QM6wtqAVjDi2XoM9sz9oNN/P8783Qp/3XgVv91EP91DGoB /3UY/xV40EAAO8N0EP91FFBW/3UI/xVU0UAA6wIzwI1lzItN8GSJDQAAAABfXlvJw8zMzMzM zMzMzMzMzMzMzItMJAxXhcl0elZTi9mLdCQU98YDAAAAi3wkEHUHwekCdW/rIYoGRogHR0l0 JYTAdCn3xgMAAAB164vZwekCdVGD4wN0DYoGRogHR4TAdC9LdfOLRCQQW15fw/fHAwAAAHQS iAdHSQ+EigAAAPfHAwAAAHXui9nB6QJ1bIgHR0t1+ltei0QkCF/DiReDxwRJdK+6//7+fosG A9CD8P8zwosWg8YEqQABAYF03oTSdCyE9nQe98IAAP8AdAz3wgAAAP91xokX6xiB4v//AACJ F+sOgeL/AAAAiRfrBDPSiReDxwQzwEl0CjPAiQeDxwRJdfiD4wN1hYtEJBBbXl/Di0QkBFM7 BSBMSQBWV3Nzi8iL8MH5BYPmH408jSBLSQDB5gOLD/ZEMQQBdFZQ6BIRAACD+P9ZdQzHBVQ5 SQAJAAAA60//dCQYagD/dCQcUP8V5NBAAIvYg/v/dQj/FeDQQADrAjPAhcB0CVDo8w8AAFnr IIsHgGQwBP2NRDAEi8PrFIMlWDlJAADHBVQ5SQAJAAAAg8j/X15bw1WL7IHsFAQAAItNCFM7 DSBMSQBWVw+DeQEAAIvBi/HB+AWD5h+NHIUgS0kAweYDiwOKRDAEqAEPhFcBAAAz/zl9EIl9 +Il98HUHM8DpVwEAAKggdAxqAldR6Aj///+DxAyLAwPG9kAEgA+EwQAAAItFDDl9EIlF/Il9 CA+G5wAAAI2F7Pv//4tN/CtNDDtNEHMpi038/0X8igmA+Qp1B/9F8MYADUCICECLyI2V7Pv/ /yvKgfkABAAAfMyL+I2F7Pv//yv4jUX0agBQjYXs+///V1CLA/80MP8VbNBAAIXAdEOLRfQB Rfg7x3wLi0X8K0UMO0UQcooz/4tF+DvHD4WLAAAAOX0IdF9qBVg5RQh1TMcFVDlJAAkAAACj WDlJAOmAAAAA/xXg0EAAiUUI68eNTfRXUf91EP91DP8w/xVs0EAAhcB0C4tF9Il9CIlF+Oun /xXg0EAAiUUI65z/dQjoZA4AAFnrPYsD9kQwBEB0DItFDIA4Gg+Ezf7//8cFVDlJABwAAACJ PVg5SQDrFitF8OsUgyVYOUkAAMcFVDlJAAkAAACDyP9fXlvJw/8FtDpJAGgAEAAA6P7i//9Z i0wkBIXAiUEIdA2DSQwIx0EYABAAAOsRg0kMBI1BFIlBCMdBGAIAAACLQQiDYQQAiQHDi0Qk BDsFIExJAHIDM8DDi8iD4B/B+QWLDI0gS0kAikTBBIPgQMOhAEtJAFZqFIXAXnUHuAACAADr BjvGfQeLxqMAS0kAagRQ6KkOAABZo+Q6SQCFwFl1IWoEVok1AEtJAOiQDgAAWaPkOkkAhcBZ dQhqGuiN0f//WTPJuIAtQQCLFeQ6SQCJBBGDwCCDwQQ9ADBBAHzqM9K5kC1BAIvCi/LB+AWD 5h+LBIUgS0kAiwTwg/j/dASFwHUDgwn/g8EgQoH58C1BAHzUXsPokg8AAIA9lDlJAAB0BemV DgAAw1WL7ItFCIXAdQJdw4M9PDlJAAB1EmaLTQxmgfn/AHc5agGICFhdw41NCINlCABRagD/ NRwsQQBQjUUMagFQaCACAAD/NUw5SQD/FaDQQACFwHQGg30IAHQNxwVUOUkAKgAAAIPI/13D U1aLRCQYC8B1GItMJBSLRCQQM9L38YvYi0QkDPfxi9PrQYvIi1wkFItUJBCLRCQM0enR29Hq 0dgLyXX09/OL8PdkJBiLyItEJBT35gPRcg47VCQQdwhyBztEJAx2AU4z0ovGXlvCEADMzMzM zMzMzFOLRCQUC8B1GItMJBCLRCQMM9L38YtEJAj38YvCM9LrUIvIi1wkEItUJAyLRCQI0enR 29Hq0dgLyXX09/OLyPdkJBSR92QkEAPRcg47VCQMdwhyDjtEJAh2CCtEJBAbVCQUK0QkCBtU JAz32vfYg9oAW8IQAGhAAQAAagD/NQRLSQD/FZTRQACFwKPgOkkAdQHDgyXYOkkAAIMl3DpJ AABqAaPUOkkAxwXMOkkAEAAAAFjDodw6SQCNDICh4DpJAI0MiDvBcxSLVCQEK1AMgfoAABAA cgeDwBTr6DPAw1WL7IPsFItVDItNCFNWi0EQi/IrcQyLWvyDwvxXwe4Pi86LevxpyQQCAABL iX38jYwBRAEAAIld9IlN8IsME/bBAYlN+HV/wfkEaj9JX4lNDDvPdgOJfQyLTBMEO0wTCHVI i00Mg/kgcxy/AAAAgNPvjUwBBPfXIXywRP4JdSuLTQghOeskg8HgvwAAAIDT74tNDI1MAQT3 1yG8sMQAAAD+CXUGi00IIXkEi0wTCIt8EwSJeQSLTBMEi3wTCANd+Il5CIld9Iv7wf8ET4P/ P3YDaj9fi038g+EBiU3sD4WgAAAAK1X8i038wfkEaj+JVfhJWjvKiU0MdgWJVQyLygNd/Iv7 iV30wf8ETzv6dgKL+jvPdGuLTfiLUQQ7UQh1SItNDIP5IHMcugAAAIDT6o1MAQT30iFUsET+ CXUri00IIRHrJIPB4LoAAACA0+qLTQyNTAEE99IhlLDEAAAA/gl1BotNCCFRBItN+ItRCItJ BIlKBItN+ItRBItJCIlKCItV+IN97AB1CTl9DA+EiQAAAItN8I0M+YtJBIlKBItN8I0M+YlK CIlRBItKBIlRCItKBDtKCHVjikwHBIP/IIhND/7BiEwHBHMlgH0PAHUOuwAAAICLz9Pri00I CRm7AAAAgIvP0+uNRLBECRjrKYB9DwB1EI1P4LsAAACA0+uLTQgJWQSNT+C/AAAAgNPvjYSw xAAAAAk4i130i0XwiRqJXBP8/wgPhfoAAACh2DpJAIXAD4TfAAAAiw3QOkkAiz1g0UAAweEP A0gMuwCAAABoAEAAAFNR/9eLDdA6SQCh2DpJALoAAACA0+oJUAih2DpJAIsN0DpJAItAEIOk iMQAAAAAodg6SQCLQBD+SEOh2DpJAItIEIB5QwB1CYNgBP6h2DpJAIN4CP91bFNqAP9wDP/X odg6SQD/cBBqAP81BEtJAP8VkNFAAKHcOkkAixXgOkkAjQSAweACi8ih2DpJACvIjUwR7FGN SBRRUOgPx///i0UIg8QM/w3cOkkAOwXYOkkAdgOD6BSLDeA6SQCJDdQ6SQDrA4tFCKPYOkkA iTXQOkkAX15bycNVi+yD7BSh3DpJAIsV4DpJAFNWjQSAV408gotFCIl9/I1IF4Ph8IlN8MH5 BEmD+SB9DoPO/9Pug034/4l19OsQg8Hgg8j/M/bT6Il19IlF+KHUOkkAi9g734ldCHMZi0sE izsjTfgj/gvPdQuDwxQ7XfyJXQhy5ztd/HV5i9o72IldCHMVi0sEizsjTfgj/gvPdQWDwxTr 5jvYdVk7XfxzEYN7CAB1CIPDFIldCOvtO138dSaL2jvYiV0Icw2DewgAdQWDwxTr7jvYdQ7o OAIAAIvYhduJXQh0FFPo2gIAAFmLSxCJAYtDEIM4/3UHM8DpDwIAAIkd1DpJAItDEIsQg/r/ iVX8dBSLjJDEAAAAi3yQRCNN+CP+C891N4uQxAAAAItwRCNV+CN19INl/ACNSEQL1ot19HUX i5GEAAAA/0X8I1X4g8EEi/4jOQvXdOmLVfyLyjP/ackEAgAAjYwBRAEAAIlN9ItMkEQjznUN i4yQxAAAAGogI034X4XJfAXR4Ufr94tN9ItU+QSLCitN8IvxiU34wf4EToP+P34Daj9eO/cP hA0BAACLSgQ7Sgh1YYP/IH0ruwAAAICLz9Pri038jXw4BPfTiV3sI1yIRIlciET+D3U4i10I i03sIQvrMY1P4LsAAACA0+uLTfyNfDgEjYyIxAAAAPfTIRn+D4ld7HULi10Ii03sIUsE6wOL XQiLSgiLegSDffgAiXkEi0oEi3oIiXkID4SUAAAAi030i3zxBI0M8Yl6BIlKCIlRBItKBIlR CItKBDtKCHVkikwGBIP+IIhNC30p/sGAfQsAiEwGBHULvwAAAICLztPvCTu/AAAAgIvO0++L TfwJfIhE6y/+wYB9CwCITAYEdQ2NTuC/AAAAgNPvCXsEi038jbyIxAAAAI1O4L4AAACA0+4J N4tN+IXJdAuJColMEfzrA4tN+It18APRjU4BiQqJTDL8i3X0iw6FyY15AYk+dRo7Hdg6SQB1 EotN/DsN0DpJAHUHgyXYOkkAAItN/IkIjUIEX15bycOh3DpJAIsNzDpJAFZXM/87wXUwjUSJ UMHgAlD/NeA6SQBX/zUES0kA/xVM0UAAO8d0YYMFzDpJABCj4DpJAKHcOkkAiw3gOkkAaMRB AABqCI0EgP81BEtJAI00gf8VlNFAADvHiUYQdCpqBGgAIAAAaAAAEABX/xVQ0UAAO8eJRgx1 FP92EFf/NQRLSQD/FZDRQAAzwOsXg04I/4k+iX4E/wXcOkkAi0YQgwj/i8ZfXsNVi+xRi00I U1ZXi3EQi0EIM9uFwHwF0eBD6/eLw2o/acAEAgAAWo2EMEQBAACJRfyJQAiJQASDwAhKdfSL +2oEwecPA3kMaAAQAABoAIAAAFf/FVDRQACFwHUIg8j/6ZMAAACNlwBwAAA7+nc8jUcQg0j4 /4OI7A8AAP+NiPwPAADHQPzwDwAAiQiNiPzv//+JSATHgOgPAADwDwAABQAQAACNSPA7ynbH i0X8jU8MBfgBAABqAV+JSASJQQiNSgyJSAiJQQSDZJ5EAIm8nsQAAACKRkOKyP7BhMCLRQiI TkN1Awl4BLoAAACAi8vT6vfSIVAIi8NfXlvJw6G8OkkAhcB0D/90JAT/0IXAWXQEagFYwzPA w1WL7FNWi3UMM9s783QVOV0QdBCKBjrDdRCLRQg7w3QDZokYM8BeW13DOR08OUkAdROLTQg7 y3QHZg+2wGaJAWoBWOvhiw0QKkEAD7bA9kRBAYB0TaEcLEEAg/gBfio5RRB8LzPJOV0ID5XB Uf91CFBWagn/NUw5SQD/FXjQQACFwKEcLEEAdZ05RRByBTheAXWTxwVUOUkAKgAAAIPI/+uE M8A5XQgPlcBQ/3UIagFWagn/NUw5SQD/FXjQQACFwA+Fef///+vKzMzMzMzMzMzMzMzMzMzM i0QkCItMJBALyItMJAx1CYtEJAT34cIQAFP34YvYi0QkCPdkJBQD2ItEJAj34QPTW8IQAMzM zMzMzMzMzMzMzID5QHMVgPkgcwYPpcLT4MOL0DPAgOEf0+LDM8Az0sNWi3QkCItGDKiDD4TE AAAAqEAPhbwAAACoAnQKDCCJRgzprgAAAAwBZqkMAYlGDHUJVui/8///WesFi0YIiQb/dhj/ dgj/dhDozgQAAIPEDIlGBIXAdGyD+P90Z4tWDPbCgnU0i04QV4P5/3QUi/nB/wWD4R+LPL0g S0kAjTzP6wW/yCxBAIpPBF+A4YKA+YJ1BoDOIIlWDIF+GAACAAB1FItODPbBCHQM9sUEdQfH RhgAEAAAiw5IiUYED7YBQYkOXsP32BvAg+AQg8AQCUYMg2YEAIPI/17DU4tcJAiD+/9WdEGL dCQQi0YMqAF1CKiAdDKoAnUug34IAHUHVujz8v//WYsGO0YIdQmDfgQAdRRAiQb2RgxAdBH/ DosGOBh0D0CJBoPI/15bw/8OiwaIGItGDP9GBCTvDAGJRgyLwyX/AAAA6+FqBGoA/3QkDOgE AAAAg8QMww+2RCQEikwkDISIYU1JAHUcg3wkCAB0Dg+3BEUaKkEAI0QkCOsCM8CFwHUBw2oB WMNTM9s5HcA6SQBWV3VCaBTWQAD/FfTQQACL+Dv7dGeLNTjRQABoCNZAAFf/1oXAo8A6SQB0 UGj41UAAV//WaOTVQABXo8Q6SQD/1qPIOkkAocQ6SQCFwHQW/9CL2IXbdA6hyDpJAIXAdAVT /9CL2P90JBj/dCQY/3QkGFP/FcA6SQBfXlvDM8Dr+ItMJAQz0okNWDlJALgwMEEAOwh0IIPA CEI9mDFBAHzxg/kTch2D+SR3GMcFVDlJAA0AAADDiwTVNDBBAKNUOUkAw4H5vAAAAHISgfnK AAAAxwVUOUkACAAAAHYKxwVUOUkAFgAAAMOLTCQEVjsNIExJAFdzVYvBi/HB+AWD5h+NPIUg S0kAweYDiwcDxvZABAF0N4M4/3Qygz0UKUEAAXUfM8AryHQQSXQISXUTUGr06whQavXrA1Bq 9v8VSNFAAIsHgwww/zPA6xSDJVg5SQAAxwVUOUkACQAAAIPI/19ew4tEJAQ7BSBMSQBzHIvI g+AfwfkFiwyNIEtJAPZEwQQBjQTBdAOLAMODJVg5SQAAxwVUOUkACQAAAIPI/8NTVot0JAxX D690JBSD/uCL3ncNhfZ1A2oBXoPGD4Pm8DP/g/7gdyo7HSAwQQB3DVPolfb//4v4WYX/dStW agj/NQRLSQD/FZTRQACL+IX/dSKDPbg6SQAAdBlW6B/7//+FwFl0FOu5U2oAV+hBtP//g8QM i8dfXlvDM8Dr+FZXagMz/145NQBLSQB+RKHkOkkAiwSwhcB0L/ZADIN0DVDoPQMAAIP4/1l0 AUeD/hR8F6HkOkkA/zSw6OjS//+h5DpJAFmDJLAARjs1AEtJAHy8i8dfXsNWi3QkCIX2dQlW 6JEAAABZXsNW6CMAAACFwFl0BYPI/17D9kYNQHQP/3YQ6DIDAAD32FleG8DDM8Bew1NWi3Qk DDPbV4tGDIvIg+EDgPkCdTdmqQgBdDGLRgiLPiv4hf9+JldQ/3YQ6Njt//+DxAw7x3UOi0YM qIB0DiT9iUYM6weDTgwgg8v/i0YIg2YEAIkGX4vDXlvDagHoAgAAAFnDU1ZXM/Yz2zP/OTUA S0kAfk2h5DpJAIsEsIXAdDiLSAz2wYN0MIN8JBABdQ9Q6C7///+D+P9ZdB1D6xqDfCQQAHUT 9sECdA5Q6BP///+D+P9ZdQIL+EY7NQBLSQB8s4N8JBABi8N0AovHX15bw2oC6CbB//9Zw1WL 7IPsDFNWi3UIVzs1IExJAA+DxQEAAIvGg+YfwfgFweYDjRyFIEtJAIsEhSBLSQADxopQBPbC AQ+EngEAAINl+ACLfQyDfRAAi890Z/bCAnVi9sJIdB2KQAU8CnQW/00QiAeLA41PAcdF+AEA AADGRDAFCo1F9GoAUIsD/3UQUf80MP8VcNBAAIXAdTr/FeDQQABqBVk7wXUVxwVUOUkACQAA AIkNWDlJAOk+AQAAg/htdQczwOk1AQAAUOg1/P//WekmAQAAiwOLVfQBVfiNTDAEikQwBKiA D4T4AAAAhdJ0CYA/CnUEDATrAiT7iAGLRQyLTfiJRRADyDvBiU34D4PLAAAAi0UQigA8Gg+E rgAAADwNdAuIB0f/RRDpkQAAAEk5TRBzGItFEECAOAp1BoNFEALrXsYHDUeJRRDrc41F9GoA UP9FEI1F/2oBUIsD/zQw/xVw0EAAhcB1Cv8V4NBAAIXAdUeDffQAdEGLA/ZEMARIdBOKRf88 CnQXxgcNiwtHiEQxBespO30MdQuAff8KdQXGBwrrGGoBav//dQjo7er//4PEDIB9/wp0BMYH DUeLTfg5TRAPgkf////rEIsDjXQwBIoGqEB1BAwCiAYrfQyJffiLRfjrFIMlWDlJAADHBVQ5 SQAJAAAAg8j/X15bycNWi3QkCFeDz/+LRgyoQHQFg8j/6zqog3Q0VugQ/f//Vov46DkBAAD/ dhDofgAAAIPEDIXAfQWDz//rEotGHIXAdAtQ6HzP//+DZhwAWYvHg2YMAF9ew4tEJAQ7BSBM SQBzPYvIi9DB+QWD4h+LDI0gS0kA9kTRBAF0JVDoYvv//1lQ/xVE0UAAhcB1CP8V4NBAAOsC M8CFwHQSo1g5SQDHBVQ5SQAJAAAAg8j/w1NVVleLfCQUOz0gTEkAD4OGAAAAi8eL98H4BYPm H40chSBLSQDB5gOLA/ZEMAQBdGlX6P76//+D+P9ZdDyD/wF0BYP/AnUWagLo5/r//2oBi+jo 3vr//1k7xVl0HFfo0vr//1lQ/xUk0UAAhcB1Cv8V4NBAAIvo6wIz7VfoOvr//4sDWYBkMAQA he10CVXowfn//1nrFTPA6xSDJVg5SQAAxwVUOUkACQAAAIPI/19eXVvDVot0JAiLRgyog3Qd qAh0Gf92COhMzv//ZoFmDPf7M8BZiQaJRgiJRgRew8zMzMzM/yW40UAA/yW00UAA/yWw0UAA /yVc0UAAVYvsUaE8OUkAUzPbO8OJXfx1IYtFCIvQOBh0f4oKgPlhfAqA+Xp/BYDpIIgKQjga derrZ1ZXagFTU1Nq/74AAgAA/3UIVlDo7cH//4v4g8QgO/t0OFfo8M3//zvDWYlF/HQqagFT V1Bq//91CFb/NTw5SQDowMH//4PEIIXAdA3/dfz/dQjo/a7//1lZ/3X86IfN//+LRQhZX15b ycPMzMzMzMzMzMzMVYvsV1ZTi00QC8kPhJUAAACLdQiLfQyNBTQ5SQCDeAgAdUO3QbNatiCN SQCKJgrkigd0IQrAdB1GRzj8cgY43HcCAuY4+HIGONh3AgLGOMR1CUl11zPJOMR0S7n///// ckT32etAM8Az24v/igYLwIofdCML23QfRkdRUFPo3LH//4vYg8QE6NKx//+DxARZO8N1CUl1 1TPJO8N0Cbn/////cgL32YvBW15fycPMzMxVi+xXVlOLdQyLfQiNBTQ5SQCDeAgAdTuw/4v/ CsB0LooGRoonRzjEdPIsQTwaGsmA4SACwQRBhuAsQTwaGsmA4SACwQRBOOB00hrAHP8PvsDr NLj/AAAAM9uL/wrAdCeKBkaKH0c42HTyUFPoPbH//4vYg8QE6DOx//+DxAQ4w3TaG8CD2P9b Xl/Jw1WL7FGhPDlJAFMz2zvDiV38dSGLRQiL0DgYdH+KCoD5QXwKgPlafwWAwSCICkI4GnXq 62dWV2oBU1NTav++AAEAAP91CFZQ6AnA//+L+IPEIDv7dDhX6AzM//87w1mJRfx0KmoBU1dQ av//dQhW/zU8OUkA6Ny///+DxCCFwHQN/3X8/3UI6Bmt//9ZWf91/Oijy///i0UIWV9eW8nD AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAJbcAACo3AAA2N0AAMDdAACe3QAAit0AALDdAABk3QAAUN0AAHrdAAAe3QAAEt0AADrd AADq3AAA2twAAAjdAABu3AAAXtwAAITcAAA+3AAAMNwAAEzcAADG3AAAItwAAAAAAAAg2gAA QNoAAFLaAABe2gAAatoAAAraAAA02gAAnNoAALLaAAC+2gAAztoAAODaAADQ2QAAftoAAI7a AAD02QAALtsAAEDbAABW2wAAatsAAILbAACS2wAAotsAALDbAADG2wAA2NsAAPTbAAAE3AAA 3tkAAKTZAADE2QAAtNkAAPDaAAAC2wAAdtkAAHDYAACQ2AAAktkAAITZAAA+2QAAYNkAAFDZ AAD82AAALtkAABjZAADK2AAA7NgAAN7YAACg2AAAttgAAK7YAAAQ2wAAHtsAAH7YAACs3gAA nN4AAA7gAAD+3wAA8N8AAODfAADO3wAAvN8AALDfAACi3wAAlN8AAIbfAAB43wAAaN8AAEbe AABa3gAAbN4AAHreAACG3gAAkN4AAFbfAAC83gAAyN4AANTeAADw3gAACt8AACTfAAA83wAA AAAAAC7eAAAa3gAACt4AAAAAAAA0AACAAwAAgHQAAIAQAACAEwAAgAkAAIAEAACAbwAAgHMA AIAXAACAAAAAAAAAAAAAAAAABQAAAAAAAAAHAAAACQAAAAUAAAACAAAAAgAAAAIAAAACAAAA DAAZAAEAAQACAA4ACgAfAAQAAQADABkACAAPAAIAAgALAAIAAQAGAP////8vhUAAQ4VAAAAA AAAAAAAAAAAAAP////8Ri0AAFYtAAP/////Fi0AAyYtAAAYAAAYAAQAAEAADBgAGAhAERUVF BQUFBQU1MABQAAAAACAoOFBYBwgANzAwV1AHAAAgIAgAAAAACGBoYGBgYAAAcHB4eHh4CAcI AAAHAAgICAAACAAIAAcIAAAAKABuAHUAbABsACkAAAAAAChudWxsKQAAcnVudGltZSBlcnJv ciAAAA0KAABUTE9TUyBlcnJvcg0KAAAAU0lORyBlcnJvcg0KAAAAAERPTUFJTiBlcnJvcg0K AABSNjAyOA0KLSB1bmFibGUgdG8gaW5pdGlhbGl6ZSBoZWFwDQoAAAAAUjYwMjcNCi0gbm90 IGVub3VnaCBzcGFjZSBmb3IgbG93aW8gaW5pdGlhbGl6YXRpb24NCgAAAABSNjAyNg0KLSBu b3QgZW5vdWdoIHNwYWNlIGZvciBzdGRpbyBpbml0aWFsaXphdGlvbg0KAAAAAFI2MDI1DQot IHB1cmUgdmlydHVhbCBmdW5jdGlvbiBjYWxsDQoAAABSNjAyNA0KLSBub3QgZW5vdWdoIHNw YWNlIGZvciBfb25leGl0L2F0ZXhpdCB0YWJsZQ0KAAAAAFI2MDE5DQotIHVuYWJsZSB0byBv cGVuIGNvbnNvbGUgZGV2aWNlDQoAAAAAUjYwMTgNCi0gdW5leHBlY3RlZCBoZWFwIGVycm9y DQoAAAAAUjYwMTcNCi0gdW5leHBlY3RlZCBtdWx0aXRocmVhZCBsb2NrIGVycm9yDQoAAAAA UjYwMTYNCi0gbm90IGVub3VnaCBzcGFjZSBmb3IgdGhyZWFkIGRhdGENCgANCmFibm9ybWFs IHByb2dyYW0gdGVybWluYXRpb24NCgAAAABSNjAwOQ0KLSBub3QgZW5vdWdoIHNwYWNlIGZv ciBlbnZpcm9ubWVudA0KAFI2MDA4DQotIG5vdCBlbm91Z2ggc3BhY2UgZm9yIGFyZ3VtZW50 cw0KAAAAUjYwMDINCi0gZmxvYXRpbmcgcG9pbnQgbm90IGxvYWRlZA0KAAAAAE1pY3Jvc29m dCBWaXN1YWwgQysrIFJ1bnRpbWUgTGlicmFyeQAAAAAKCgAAUnVudGltZSBFcnJvciEKClBy b2dyYW06IAAAAC4uLgA8cHJvZ3JhbSBuYW1lIHVua25vd24+AAAAAAAA/////2GvQABlr0AA R2V0TGFzdEFjdGl2ZVBvcHVwAABHZXRBY3RpdmVXaW5kb3cATWVzc2FnZUJveEEAdXNlcjMy LmRsbAAA6NYAAAAAAAAAAAAAFNwAAGTQAACE1gAAAAAAAAAAAADw3QAAANAAAETYAAAAAAAA AAAAAP7dAADA0QAANNgAAAAAAAAAAAAAPt4AALDRAAAAAAAAAAAAAAAAAAAAAAAAAAAAAJbc AACo3AAA2N0AAMDdAACe3QAAit0AALDdAABk3QAAUN0AAHrdAAAe3QAAEt0AADrdAADq3AAA 2twAAAjdAABu3AAAXtwAAITcAAA+3AAAMNwAAEzcAADG3AAAItwAAAAAAAAg2gAAQNoAAFLa AABe2gAAatoAAAraAAA02gAAnNoAALLaAAC+2gAAztoAAODaAADQ2QAAftoAAI7aAAD02QAA LtsAAEDbAABW2wAAatsAAILbAACS2wAAotsAALDbAADG2wAA2NsAAPTbAAAE3AAA3tkAAKTZ AADE2QAAtNkAAPDaAAAC2wAAdtkAAHDYAACQ2AAAktkAAITZAAA+2QAAYNkAAFDZAAD82AAA LtkAABjZAADK2AAA7NgAAN7YAACg2AAAttgAAK7YAAAQ2wAAHtsAAH7YAACs3gAAnN4AAA7g AAD+3wAA8N8AAODfAADO3wAAvN8AALDfAACi3wAAlN8AAIbfAAB43wAAaN8AAEbeAABa3gAA bN4AAHreAACG3gAAkN4AAFbfAAC83gAAyN4AANTeAADw3gAACt8AACTfAAA83wAAAAAAAC7e AAAa3gAACt4AAAAAAAA0AACAAwAAgHQAAIAQAACAEwAAgAkAAIAEAACAbwAAgHMAAIAXAACA AAAAALQARnJlZUxpYnJhcnkAPgFHZXRQcm9jQWRkcmVzcwAAwgFMb2FkTGlicmFyeUEAABsA Q2xvc2VIYW5kbGUAlgJTbGVlcACeAlRlcm1pbmF0ZVByb2Nlc3MAABwCUmVhZFByb2Nlc3NN ZW1vcnkA7wFPcGVuUHJvY2VzcwDZAU1vZHVsZTMyRmlyc3QATABDcmVhdGVUb29saGVscDMy U25hcHNob3QAACQBR2V0TW9kdWxlRmlsZU5hbWVBAAD+AVByb2Nlc3MzMk5leHQA/AFQcm9j ZXNzMzJGaXJzdAAA1gFNYXBWaWV3T2ZGaWxlADUAQ3JlYXRlRmlsZU1hcHBpbmdBAAASAUdl dEZpbGVTaXplADQAQ3JlYXRlRmlsZUEAsAJVbm1hcFZpZXdPZkZpbGUAGwFHZXRMb2NhbFRp bWUAABoBR2V0TGFzdEVycm9yAADMAUxvY2FsRnJlZQDIAUxvY2FsQWxsb2MAAPgAR2V0Q3Vy cmVudFByb2Nlc3NJZADSAldpZGVDaGFyVG9NdWx0aUJ5dGUA5AFNdWx0aUJ5dGVUb1dpZGVD aGFyAM4AR2V0Q29tcHV0ZXJOYW1lQQAAKABDb3B5RmlsZUEAuQFJc0RCQ1NMZWFkQnl0ZQAA 3wJXcml0ZUZpbGUAGAJSZWFkRmlsZQAAYwFHZXRUZW1wRmlsZU5hbWVBAABlAUdldFRlbXBQ YXRoQQAAVwBEZWxldGVGaWxlQQBoAlNldEZpbGVBdHRyaWJ1dGVzQQAAkABGaW5kQ2xvc2UA nQBGaW5kTmV4dEZpbGVBAJQARmluZEZpcnN0RmlsZUEAAGECU2V0RW5kT2ZGaWxlAABqAlNl dEZpbGVQb2ludGVyAAAUAUdldEZpbGVUaW1lAGwCU2V0RmlsZVRpbWUAbQFHZXRUaWNrQ291 bnQAAEQAQ3JlYXRlUHJvY2Vzc0EAAFkBR2V0U3lzdGVtRGlyZWN0b3J5QQD3AEdldEN1cnJl bnRQcm9jZXNzAJsCU3lzdGVtVGltZVRvRmlsZVRpbWUAAF0BR2V0U3lzdGVtVGltZQB1AUdl dFZlcnNpb25FeEEAdAFHZXRWZXJzaW9uAADOAldhaXRGb3JTaW5nbGVPYmplY3QAygBHZXRD b21tYW5kTGluZUEAgABFeHBhbmRFbnZpcm9ubWVudFN0cmluZ3NBAAQBR2V0RHJpdmVUeXBl QQBKAENyZWF0ZVRocmVhZAAAS0VSTkVMMzIuZGxsAABbAVJlZ0Nsb3NlS2V5AGYBUmVnRW51 bUtleUEAcQFSZWdPcGVuS2V5QQBkAVJlZ0RlbGV0ZVZhbHVlQQBqAVJlZ0VudW1WYWx1ZUEA NABDbG9zZVNlcnZpY2VIYW5kbGUAAEwAQ3JlYXRlU2VydmljZUEAAEUBT3BlblNDTWFuYWdl ckEAALMBU3RhcnRTZXJ2aWNlQ3RybERpc3BhdGNoZXJBAK4BU2V0U2VydmljZVN0YXR1cwAA RwFPcGVuU2VydmljZUEAAI4BUmVnaXN0ZXJTZXJ2aWNlQ3RybEhhbmRsZXJBAJ0ARnJlZVNp ZACYAEVxdWFsU2lkAAAYAEFsbG9jYXRlQW5kSW5pdGlhbGl6ZVNpZAAA0ABHZXRUb2tlbklu Zm9ybWF0aW9uAEIBT3BlblByb2Nlc3NUb2tlbgAAXAFSZWdDb25uZWN0UmVnaXN0cnlBALIB U3RhcnRTZXJ2aWNlQQB7AVJlZ1F1ZXJ5VmFsdWVFeEEAAIYBUmVnU2V0VmFsdWVFeEEAAF4B UmVnQ3JlYXRlS2V5QQAXAEFkanVzdFRva2VuUHJpdmlsZWdlcwD1AExvb2t1cFByaXZpbGVn ZVZhbHVlQQBBRFZBUEkzMi5kbGwAAFdTMl8zMi5kbGwAABEAV05ldENsb3NlRW51bQAcAFdO ZXRFbnVtUmVzb3VyY2VBAEAAV05ldE9wZW5FbnVtQQBNUFIuZGxsACYBR2V0TW9kdWxlSGFu ZGxlQQAAUAFHZXRTdGFydHVwSW5mb0EAfQBFeGl0UHJvY2VzcwC/AEdldENQSW5mbwC5AEdl dEFDUAAAMQFHZXRPRU1DUAAAvwFMQ01hcFN0cmluZ0EAAMABTENNYXBTdHJpbmdXAACfAUhl YXBGcmVlAACZAUhlYXBBbGxvYwCtAlVuaGFuZGxlZEV4Y2VwdGlvbkZpbHRlcgAAsgBGcmVl RW52aXJvbm1lbnRTdHJpbmdzQQCzAEZyZWVFbnZpcm9ubWVudFN0cmluZ3NXAAYBR2V0RW52 aXJvbm1lbnRTdHJpbmdzAAgBR2V0RW52aXJvbm1lbnRTdHJpbmdzVwAAbQJTZXRIYW5kbGVD b3VudAAAUgFHZXRTdGRIYW5kbGUAABUBR2V0RmlsZVR5cGUAnQFIZWFwRGVzdHJveQCbAUhl YXBDcmVhdGUAAL8CVmlydHVhbEZyZWUALwJSdGxVbndpbmQAUwFHZXRTdHJpbmdUeXBlQQAA VgFHZXRTdHJpbmdUeXBlVwAAuwJWaXJ0dWFsQWxsb2MAAKIBSGVhcFJlQWxsb2MAfAJTZXRT dGRIYW5kbGUAAKoARmx1c2hGaWxlQnVmZmVycwAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA W4lAAG+zQAAAAAAAAAAAABS0QAAAAAAAAAAAAAAAAAAAAAAAMw1BAEAAAAAgAAAALAAAAC0t AABcAAAAUVVJVA0KAAANCi4NCgAAAERBVEEgDQoASEVMTyAlcw0KAAAAPg0KAE1BSUwgRlJP TTogPAAAAABSQ1BUIFRPOjwAAAAlZAAAIAkNCgAAAAAuLCgpJSRAIWB+IAAtXwAALi4AAC4A AABcKi4qAAAAAFxcAAAAAAAAiRV37zMZmXgQWLjJ8pkAAAKwXFR4cHBwsRENCS0dDQktCD0N BbBRZTUJUWU1CbF4dD0JCD0NBbA1AVBUsWkleRVZDQkICSVhsDkVeSGxIRUpNT0IPQ0FsBU1 HbERDQktHQ0JLQg9DQWwVQ1lBSWxEQ0JLR0NCS0IPQ0FsGENBbFtNRURNQktCD0NBQgRHbBl ITmxaSV5FVkNCQgJJWGwfRV9sRENCS0dDQktCD0NBbBhNTk5JbEhFSk1PQg9DQWwOWV9EbFp JXkVWQ0JCAklYbAFZR01sW05BBk1cTUJCD0NCBlxsGENHVUNsW05BBk1cTUJCD0NCBlxsH01 AQFVAbElaSV5YSU9EQg9DQUIfS2wNQElUWE1VbElaSV5YSU9EQg9DQUIfS2wPTV5NWk1CbFp fQkBCD0NBbApDXltNXkhsWl9CQEIPQ0FsDl5DWERJXmxaX0JAQg9DQWwfXkVCTUBNbFpfQkB CD0NBbCwsLCwsLCwsLCwsLCwsLCwsLCwsLCwsLCwsLCwsLCwsLCwsLCwsLCwsLCwsLCwsLCw sLCwsLCwsLCwsLCwsLCwsLCwsLCwsLCwsLCwsLCwsLCwsLCwsLCwsLCwsLCwsLCwsLCwsLCw sLCwsLCwsLCwsLCwsLCwsLCwsLCwsLCwsLCwsLCwsLCwsLCwsLCwsLCwsLCwsLCwsLCwsLCw sLCwsLCwsLCwsLCwsLCwsLCwsLCwsLCwsLCwsLCwsLCwsLCwsLCwsLCwsLCwsLCwsLCwsLCw sLCwsLCwsLCwsLCwsLCwsLCwsLCwsLCwsLCwsLCwsLCwsLCwsLCwsLCwsLCwsLCwsLCwsLCw sLCwsLCwsLCwsLCwsLCwsLCwsLCwsLCwsLCwsLCwsLCwsLCwsLCwsLCwsLCwsLCwsLCwsLCw sLCwsLCwsLCwsLCwsLCwsLCwsLCwsLCwsLCwsLCwsLCwsLCwsLCwsLCwsLCwsLCwsLCwsLCw sLCwsLCwsLCwsLCwsLCwsLCwsLCwsLCwsLCwsLCwsLCwsLCwsLCwsLCwsLCwsLCwsLCwsLCw sLCwsLCwsLCwsLCwsLCwsLCwsLCwsLCwsLCwsLCwsLCwsLCwsLCwsLCwsLCwsLCwsLCwsLCw sLCwsLCwsLCwsLCwsLCwsLCwsLCwsLCwsLCwsLCwsLCwsLCwsLCwsLCwsLCwsLCwsLCwsLCw sLCwsLCwsLCwsLCwsLCwsLCwsLCwsLCwsLCwsLCwsLCwsLCwsLCwsLCwsLCwsLCwsLCwsLCw sLCwsLCwsLCwsLCwsLCwsLCwsLCwsLCwsLCwsLCwsLCwsLCwsLCwsLCwsLCwsLCwsLCwsLCw sLCwsLCwsLCwsLCwsLCwsLCwsLCwsLCwsLCwsLCwsLCwsLCwsLCwsLCwsLCwsLCwsLCwsLCw sLCwsLCwsLCwsLCwsLCwsLCwsLCwsLCwsLCwsLCwsLCwsLCwsLCwsLCwsLCwsLCwsLCwsLCw sLCwsLCwsLCwsLCwsLCwsLCwsLCwsLCwsLCwsLCwsLCwsLCwsLCwsLCwsLCwsLCwsLCwsLCw sLCwsLCwsLCwsLCwsLCwsLCwsLCwsLCwsLCwsLCwsLCwsLCwsLCwsLCwsLCwsLCwsLCwsLCw sLCwsLCwsLCwsLCwsLCwsLCwsLCwsLCwsLCwsLCwsLCwsLCwsLCwsLCwsLCwsLCwsLCwsLCw sLCwsLCwsLCwsLCwsLCwsLCwsLCwsLCwsLCwsLCwsLCwsLCwsLCwsLCwsLCwsLCwsLCwsLCw sLCwsLCwsLCwsLCwsLCwsLCwsLCwsLCwsLCwsLCwsLCwsLCwsLCwsLCwsLCwsLCwsLCwsLCw sLCwsLCwsLCwsLCwsLCwsLCwsLCwsLCwsLCwsLCwsLCwsLCwsLCwsLCwsLCwsLCwsLCwsLCw sLCwsLCwsLCwsLCwsLCwsLCwsLCwsLCwsLCwsLCwsLCwsLCwsLCwsLCwsLCwsLCwsLCwsLCw sLCwsLCwsLCwsLCwsLCwsLCwsLCwsLCwsLCwsLCwsLCwsLCwsLCwsLCwsLCwsLCwsLCwsLCw sLCwsLCwsLCwsLCwsLCwsLCwsLCwsLCwsLCwsLCwsLCwsLCwsLCwsLCwsLCwsLCwsLCwsLCw sLCwsLCwsLCwsLCwsLCwsLCwsLCwsLCwsLCwsLCwsLCwsLCwsLCwsLCwsLCwsLCwsLCwsLCw sLCwsLCwsLCwsLCwsLCwsLCwsLCwsLCwsLCwsLCwsLCwsLCwsLCwsLCwsLCwsLCwsLCwsLCw sLCwsLCwsLCwsLCwsLCwsLCwsLCwsLCwsLCwsLCwsLCwsLCwsLCwsLCwsLCwsLCwsLCwsLCw sLCwsLCwsLCwsLCwsLCwsLCwsLCwsLCwsLCwsLCwsLCwsLCwsLCwsLCwsLCwsLCwsLCwsLCw sLCwsLCwsLCwsLCwsLCwsLCwsLCwsLCwsLCwsLCwsLCwsLCwsLCwsLCwsLCwsLCwsLCwsLCw sLCwsLCwsLCwsLCwsLCwsLCwsLCwsLCwsLCwsLCwsLCwsLCwsLCwsLCwsLCwsLCwsLCwsLCw sLCwsLCwsLCwsLCwsLCwsLCwsLCwsLCwsLCwsLCwsLCwsLCwsLCwsLCwsLCwsLCwsLCwsLCw sLCwsLCwsLCwsLCwsLCwsLCwsLCwsLCwsLCwsLCwsLCwsLCwsLCwsLCwsLCwsLCwsLCwsLCw sLCwsLCwsLCwsLCwsLCwsLCwsLCwsLCwsLCwsLCwsLCwsLCwsLCwsLCwsLCwsLCwsLCwsLCw sLCwsLCwsLCwsLCwsLCwsLCwsLCwsLCwsLCwsLCwsLCwsLCwsLCwsLCwsLCwsLCwsLCwsLCw sLCwsLCwsLCwsLCwsLCwsLCwsLCwsLCwsLCwsLCwsLCwsLCwsLCwsLCwsLCwsLCwsLCwsLCw sLCwsLCwsLCwsLCwsLCwsLCwsLCwsLCwsLCwsLCwsLCwsLCwsLCwsLCwsLCwsLCwsLCwsLCw sLCwsLCwsLCwsLCwsLCwsLCwsLCwsLCwsLCwsLCwsLCwsLCwsLCwsLCwsLCwsLCwsLCwsLCw sLCwsLCwsLCwsLCwsLCwsLCwsLCwsLCwsLCwsLCwsLCwsLCwsLCwsLCwsLCwsLCwsLCwsLCw sLCwsLCwsLCwsLCwsLCwsLCwsLCwsLCwsLCwsLCwsLCwsLCwsLCwsLCwsLCwsLCwsLCwsLCw sLCwsLCwsLCwsLCwsLCwsLCwsLCwsLCwsLCwsLCwsLCwsLCwsLCwsLCwsLCwsLCwsLCwsLCw sLCwsLCwsLCwsLCwsLCwsLCwsLCwsLCwsLCwsLCwsLCwsLCwsLCwsLCwsLCwsLCwsLCwsLCw sLCwsLCwsLCwsLCwsLCwsLCwsLCwsLCwsLCwsLCwsLCwsLCwsLCwsLCwsLCwsLCwsLCwsLCw sLCwsLCwsLCwsLCwsLCwsLCwsLCwsLCwsLCwsLCwsLCwsLCwsLCwsLCwsLCwsLCwsLCwsLCw sLCwsLCwsLCwsLCwsLCwsLCwsLCwsLCwsLCwsLCwsLCwsLCwsLCwsLCwsLCwsLCwsLCwsLCw sLCwsLCwsLCwsLCwsLCwsLCwsLCwsLCwsLCwsLCwsLCwsLCwsLCwsLCwsLCwsLCwsLCwsLCw sLCwsLCwsLCwsLCwsLCwsLCwsLCwsLCwsLCwsLCwsLCwsLCwsLCwsLCwsLCwsLCwsLCwsLCw sLCwsLCwsLCwsLCwsLCwsLCwsLCwsLCwsLCwsLCwsLCwsLCwsLCwsLCwsLCwsLCwsLCwsLCw sLCwsLCwsLCwsLCwsLCwsLCwsLCwsLCwsLCwsLCwsLCwsLCwsLCwsLCwsLCwsLCwsLCwsLCw sLCwsLCwsLCwsLCwsLCwsLCwsLCwsLCwsLCwsLCwsLCwsLCwsLCwsLCwsLCwsLCwsLCwsLCw sLCwsLCwsLCwsLCwsLCwsLCwsLCwsLCwsLCwsLCwsLCwsLCwsLCwsLCwsLCwsLCwsLCwsLCw sLCwsLCwsLCwsLCwsLCwsLCwsLCwsLCwsLCwsLCwsLCwsLCwsLCwsLCwsLCwsLCwsLCwsLCw sLCwsLCwsLCwsLCwsLCwsLCwsLCwsLCwsLCwsLCwsLCwsLCwsLCwsLCwsLCwsLCwsLCwsLCw sLCwsLCwsLCwsLCwsLCwsLCwsLCwsLCwsLCwsLCwsLCwsLCwsLCwsLCwsLCwsLCwsLCwsLCw sLCwsLCwsLCwsLCwsLCwsLCwsLCwsLCwsLCwsLCwsLCwsLCwsLCwsLCwsLCwsLCwsLCwsLCw sLCwsLCwsLCwsLCwsLCwsLCwsLCwsLCwsLCwsLCwsLCwsLCwsLCwsLCwsLCwsLCwsLCwsLCw sLCwsLCwsLCwsLCwsLCwsLCwsLCwsLCwsLCwsLCwsLCwsLCwsLCwsLCwsLCwsLCwsLCwsLCw sLCwsLCwsLCwsLCwsLCwsLCwsLCwsLCwsLCwsLCwsLCwsLCwsLCwsLCwsLCwsLCwsLCwsLCw sLCwsLCwsLCwsLCwsLCwsLCwsLCwsLCwsLCwsLCwsLCwsLCwsLCwsLCwsLCwsLCwsLCwsLCw sLCwsLCwsLCwsLCwsLCwsLCwsLCwsLCwsLCwsLCwsLCwsLCwsLCwsLCwsLCwsLCwsLCwsLCw sLCwsLCwsLCwsLCwsLCwsLCwsLCwsLCwsLCwsLCwsLCwsLCwsLCwsLCwsLCwsLCwsLCwsLCw sLCwsLCwsLCwsLCwsLCwsLCwsLCwsLCwsLCwsLCwsLCwsLCwsLCwsLCwsLCwsLCwsLCwsLCw sLCwsLCwsLCwsLCwsLCwsLCwsLCwsLCwsLCwsLCwsLCwsLCwsLCwsLCwsLCwsLCwsLCwsLCw sLCwsLCwsLCwsLCwsLCwsLCwsLCwsLCwsLCwsLCwsLCwsLCwsLCwsLCwsLCwsLCwsLCwsLCw sLCwsLCwsLCwsLCwsLCwsLCwsLCwsLCwsLCwsLCwsLCwsLCwsLCwsLCwsLCwsLCwsLCwsLCw sLCwsLCwsLCwsLCwsLCwsLCwsLCwsLCwsLCwsLCwsLCwsLCwsLCwsLCwsLCwsLCwsLCwsLCw sLCwsLCwsLCwsLCwsLCwsLCwsLCwsLCwsLCwsLCwsLCwsLCwsLCwsLCwsLCwsLCwsLCwsLCw sLCwsLCwsLCwsLCwsLCwsLCwsLCwsLCwsLCwsLCwsLCwsLCwsLCwsLCwsLCwsLCwsLCwsLCw sLCwsLCwsLCwsLCwsLCwsLCwsLCwsLCwsLCwsLCwsLCwsLCwsLCwsLCwsLCwsLCwsLCwsLCw sLCwsLCwsLCwsLCwsLCwsLCwsLCwsLCwsLCwsLCwsLCwsLCwsLCwsLCwsLCwsLCwsLCwsLCw sLCwsLCwsLCwsLCwsLCwsLCwsLCwsLCwsLCwsLCwsLCwsLCwsLCwsLCwsLCwsLCwsLCwsLCw sLCwsLCwsLCwsLCwsLCwsLCwsLCwsLCwsLCwsLCwsFjB8XkNLXk1BTCpFQElfcG1aTUJYa0N ML0NCQklPWHBBTUBKRUBJQglIRGw+QhpERGwCB19CbC1rf18eAhxAWGwsLCwsLCwsLCwsLCw sLCwsLCwsLCwsLCwsLCwsLCwsLCwsLCwsLCwsLCwsLCwsLCwsLCwsLCwsLCwsLCwsLCwsLCw sLCwsLCwsLCwsLCwsLCwsLCwsLCwsLCwsLCwsLCwsLCwsLCwsLCwsLCwsLCwsLCwsLCwsLCw sLCwsLCwsLCwsLCwsLCwsLCwsLCwsLCwsLCwsLCwsLCwsLCwsLCwsLCwsLCwsLCwsLCwsLCw sLCwsLCwsLCwsLCwsLCwsLCwsLAFcVCwCCVRJbAIfT15sAhxFSmwCDk1YbCwsLCwsLCwsLCw sLAIYVFhsAgRYQWwCBFhBQGwCG01ObAINX1xsAghDT2wCHlhKbAIUQF9sAgZcS2wCD1xcbAI PbAIcTV9sAgFcS2wCAVxJS2wCDk1HbAIBXF8sAhxISmwsP0NKWFtNXklwYUVPXkNfQ0pYcHt FQkhDW19wb1leXklCWHpJXl9FQ0JwbC1cXEw8TVhEX2w+WUJsPllCY0JPSWw/VV9YSUFwb1l eXklCWG9DQlheQ0B/SVhwf0leWkVPSV9sP0NKWFtNXklwYUVPXkNfQ0pYcHttbnB7bW5YMHt NTkwqRUBJTCJNQUlsPllCf0leWkVPSV9sJUJYSV5CSVhMP0lYWEVCS19wb01PRElwfE1YRF9 sLCwsLCwsLCRFQCwkSUBAQ0AsPklWLCpbViw5QkhJQEVaSV5NTkBJTAFNRUBBAQ4JH04sPkl YWV5CSUhMAU1FQEEBDgkfTiwsLCwsDUwJH0wJH0wLTUFJbA1MCR9MCR9MGENDQGwNTAkfTAk fTBtJTl9FWElsDUwJH0wJH0wcTVhPRGwJH0weSUFDWk1ATBhDQ0BfbCwsLCwsLCwCSVtsCll CQlVsAkVPSWwEWUFDWV5sCVRPRVhJbAtDQ0hsHENbSllAbDtFQnR8bCVpTBoCHCw7Xx4CKUB HSV5CTCw7Xx4CJ0BJVkIpbCwEQ1tMDV5JTBVDWWwASVhLH0wOSUwKXkVJQkhfbAhNXkBFQkt sH0NMD0NDQEwNTApATV9EQAlCRkNVTAVYbBVDWV5MHE1fX1tDXkhsBENCSVVsH0NBSUwdWUl fWEVDQl9sHEBJTV9JTBheVUwNS01FQmwbSUBPQ0FJTBhDTAFVTARDQUlYQ1tCbBhESUwrTV5 ISUJMA0pMKUhJQmwFQlheQ0hZT1hFQ0JMA0JMLWh/YGwBSUlYRUJLTAJDWEVPSWwdWUlfWEV DQkJNRV5JbA9DQkteTVhZQE1YRUNCX2wfQ19NLAZNXE1CSV9JTAtFXkBMOn9MHEBNVU5DVWw AQ0NHQAFVTA5JTVlYRUpZQEwLRV5ATApeRUlCSGwJTUtJXkwYQ0wfSUlMFUNZbB9cRU9JTAt FXkBfSwwaQ09NQEwPQ0JPSV5YbAZNXE1CSV9JTABNX19LDB9JVFVMHEVPWFleSV9sLCwsP1V BTUJYSU9sIU9NSklJbCpBP0lPWV5JbD9DXERDX2w4XklCSEFFT15DbCdNX1xJXl9HVWwsLCw qXkNBVgwsOENWDCw/WU5GSU9YVgwsLCw4RElMCkNAQENbRUJLTAFNRUBMD01CSxhMDklMH0l CWEwYQ0wJH1YsOERJTA1YWE1PREFJQlhsOERJTApFQElsDAVfTBhESUwDXkVLRUJNQEwBTUV AbAwLRVpJTBVDWUwYRElMCR9sDAVfTA1MCR9MCE1CS0leQ1lfTBpFXllfTBhETVhMCR9sD01 CTAVCSklPWEwDQkw7RUJVFAMhSUMeHBwcAzR8QiwfXF5JTUhMGEReQ1lLREwJQU1FQEIsGkl eVUwsH1xJT0VNQEwsBFhYXFYDAywbW1tCLAIPQ0FsKkNeTAFDXklMBUJKQ15BTVhFQ0JAHEB JTV9JTBpFX0VYTCw4REVfTAVfTCwlTAkfTBVDWUwbQ1lASEwJH0wFWEIsCUJGQ1VsAEVHSWw bRV9EbARDXElsCVRcSU9YbCwvRF5FX1hBTV9sIklbTBVJTV5sP01FQlhMOk1ASUJYRUJJSx9 MKE1VbC1AQERNQEBDW0FNX2wtXF5FQEwqQ0NAX0sMKE1VbCBNSFVMKE1VbC1fX1lBXFhFQ0J sL01CSEBJQU1fbC1AQEw/Q1lAX0soTVVsKVxFXERNQlVsLCwsLCRNXFxVTCwkTVpJTA1MLCw QDl5SISYsISYsHENfWEFNX1hJXmwsLDtFQkdsLCVBTUtJfE1YRGwhZWFpQTpJXl9FQ0JWDB0 CHCEmL0NCWElCWEE4VVxJVgwBWUBYRVxNXlhDDUBYSV5CTVhFWklXISYlDkNZQkhNXlVRLC9 DQlhJQlhBOFVcSVYMGElUWEMEWEFAVyEmL0NCWElCWEE4Xk1CX0pJXkEpQk9DSEVCS1YMHVl DWElIQRxeRUJYTU5ASWEmISYQJHhhYFIQJGltaFIQAyRpbWhSEC5jaHVSCR9hJhAqY2J4Uiw sEAMqY2J4UhADLmNodVIQAyR4YWBSLCwsL0NCWElCWEE4VVxJVgwJH1chJiUCTUFJUQkfYSY vQ0JYSUJYQTheTUJfSkleQSlCT0NIRUJLVgwOTV9JWhghJi9DQlhJQlhBJWhWDBAJH1IsLCw sLCwsLCwsDVlIRUNDFEEbTVpsDVlIRUNDFEEBRUhFbA1cXEBFT01YRUNCQwNPWElYQR9YXkl NQWwsLCwsLCwsLCEmEAVKXk1BSUwfXk9RHyhPRUhWCR9MBElFS0RYUR8oXAwbRUhYRFEfKFw SISYQAwVKXk1BSVIsOERFX0wLTUFJTAVfTAFVTApFXl9YTBtDXkdCEA5eUiEmNUNZSx5JTBh ESUwKRV5fWEwcQE1VSV5CLCNlb31sPF5DS15NQWpFQElfaEVebCwsLB9BWFxCLDNtenxfHiw zbXp8b29sImNoXx4sInx/f3pvbCJ+aX99Xx4sIn9vZGloXx4sIn9vZGloYnhsIn98YHlrZWJ sIm16bCJtem18f3pvbCJtem18e18eLCJtemB5Xx4sIm16fnlifmwibXp7Xx4sM216fGFsLWB pfnh/em9sLWFjYmwtenxfHiwtenxvb2wtenxhbCJfHj9vbWJ7bCJtentieGwtYnhlemV+bC1 6fHl8aGwtemtveH5gbC16e2ViVRksP29tYl8eLDp/ZHtlYl8eLCpBP3hjfHtsKkE8fmN4VRk sLW9ne2ViXx4sOml4eH5tdWw6aXhVGSw/e2lpfFUZLDxvb3tlYlUULCVjYWNiVRQsLXp8eG9 sLXppXx4sLXpvY2J/Y2BsKnxBO2VibCh6fFUZLCpBLWtieFUZLC9gbXtVGSwiem9VGSw/b21 ibDplfnl/bCBjb2doY3tiXhwcHCwiQ15YQ0JsIU9NSklJbC1CWEVaRV5sOG1/Z2FrfmwsLCw sLCwsLCwsLCwsLCwsLCwtYnhlQTplfkIobXhsL2RnYGV/eEIobXhsL2RnYGV/eEIhf2wvZGd gZX94Qi98f2wvZGdgZX94Qjhtemwlem5CInh2bD9hbX54b2RnQiF/bD9hbX54b2RnQi98f2w temt9eEIobXhsLWt5bX5oQihteGwsLCwsLCw/REBbTVxFQghAQGwnSV5CSUBfHgIIQEBsAkl YTVxFXx4CCEBAbB9KT0IIQEBsLCwsLD9FXk9NQWwiRUFITWwvQ0hJfklIbDt9Z2FhXxQbFCw rfmVpal8UGxQsKllCTCBDWkVCS0wvXkVBRUJNQGwiQ15YQ0JsIU9NSklJbC1CWEVaRV5sLVp PQ0JfQ0BsKkE/eGN8e2wqQT9JT1leSWw/Q1xEQ19sGkVeWV9sLXp8TCFDQkVYQ15sLXp8TDl cSE1YSV9sJUJDT1lATVhJZXhsPG9BD0VAQEVCbD9VQU1CWElPbDheSUJITCFFT15DbCpBPH5 jeGwMImNoXx4MLCwsPklLRV9YSV5/SV5aRU9JfF5DT0lfX2wiSVh/RE1eSW1ISGw/ZGhJQEl YSWdJVW1sP0pPZV9qRUBJfF5DWElPWElIbCJJWH9ETV5Ja0lYZUJKQ2wiSVhtXEVuWUpKSV5 qXklJbCwsLCwpdHxgY35pfmwvYWFrfmwBX0VBQmwFT1tPQ0JCbBtFQlZFXGwsLCwsPF5DS15 NQWwJH0wQCR9SLC1ub2hpamtkZWZnYGFiY3x9fn94eXp7dHV2TU5PSElKS0RFRkdAQUJDXF1 eX1hZWltUVVZcHR4fGBkaGxQVBwMsH0lYWVxsBUJfWE1AQGwISUFDbB9CQ0NcVWwcRU9NT1l sB0VYWFVsHEBNVWweQ09HbCwsLCwsLCw+TV5NNissI/yfbCwhLCwsLCwsLCwsAh5NXmwsG0V CRUJJWEIIQEBsJUJYSV5CSVhrSVhvQ0JCSU9YSUh/WE1YSWwsLChFXklPWENeVWwIQEBPTU9 ESWwsP0loSU5ZS3xeRVpFQElLSWw/SXhPTnxeRVpFQElLSWwsLCwsLCwsLBtOQQZNXE1CQg9 DQgZcbBpJXkVWQ0JCAklYbA1eXVlFXklIQglfbAhFSk1PQg9DQWwsP0NKWFtNXklwYUVPXkN fQ0pYcGVCWEleQklYTC1PT0NZQlhMIU1CTUtJXnBtT09DWUJYX3BsP2F4fEw/SV5aSV5sP2F 4fEwpQU1FQEwtSEheSV9fbCw7Q15BTCdASVZCKUwFQUFZQkVYVWwsJ0BJVkIpTAVfTBhESUw BQ19YTA9DQUFDQkwbQ15ASEEbRUhJTB9cXklNSEVCS0wbQ15BQiVYSx9MGkleVUwITUJLSV5 DWV9MDlVMD0NeXllcWEVCS0wVQ1leTApFQElfQhAOXlIhJi5JT01ZX0lMA0pMBVhfTBpJXlV MH0FNXlhMH1hJTUBYREwNQkhMDUJYRUENQlhFQRpFXllfTBhJT0RCRU9AAUNfWEwPQ0FBQ0J MLXpMH0NKWFtNXklMD01CSxhMCElYSU9YTANeTA9ASU1CTAVYQhAOXlIhJjtJTAhJWklAQ1x JSEwYREVfTApeSUlMBUFBWUJFWFVMGENDQEwYQ0wISUpJTVhMGERJTAFNQEVPRUNZX0waRV5 ZX0IQDl5SISY1Q1lMA0JAVUwCSUlITBhDTB5ZQkwYREVfTBhDQ0BMA0JPSUANQkhMGERJQkw nQElWTBtFQEBMAklaSV5MD0NBSUwFQlhDTBVDWV5MPG9CEA5eUiEmImN4aVYMLklPTVlfSUw YREVfTBhDQ0BMDU9YX0wNX0wNTApNR0lMJ0BJVkwYQ0wKQ0NATBhESUweSU1ATBtDXkFAH0N BSUwtekwBQ0JFWENeTAFNVU5JTA9eVUwbRElCTBVDWUweWUJMBVhCEA5eUiEmJUpMH0NAJUt CQ15JTBhESUwbTV5CRUJLQA1CSEwfSUBJT1hMCw9DQlhFQllJSwIQDl5SISYlSkwVQ1lMBE1 aSUwNQlVMHVlJX1hFQ0JAHEBJTV9JTBANTAReSUpRHyhBTUVAWENWCR9SAU1FQEwYQ0wBSVA DDVICLCwsLCwsLCwhJjtFQl8eDCdASVZMOl4CHB0MCgw7RUJfHgwqQ15DWVRMOl0CHCEmL0N cVV5FS0RYTB4cHB4AAU1ISUwFQkwtX0VNYSYtTkNZWEwnQElWTDpeAhwdFiEmJR0AIU1FQkw BRV9fRUNCTAVfTBhDTB5JQElNX0lMGERJTAJJW0wOTU5VTDxpTBpFXllfQDtFQl8eDCpDXkN ZVGEmJR4AIkNMH0VLQkVKRU9NQlhMD0RNQktJQiJDTA5ZS0wKRVRJSEIiQ0wNQlVMHE1VQEN NSEIhJi1OQ1lYTDtFQl8eDCpDXkNZVEwEHEBWTAdJSVxMGERJTAJNQUlAGERNQlRFISYlHQA qWUBATA9DQVxNWEVOQElMO0VCXx4MPGlMGkVeWV9MA0JMO0VCVTRDHidDInhDNHxhJiUeADt FWERMGkleVUwFQlhJXklfWEVCS0wKSU1YWV5JQi9ESU9HTAVYTSEmJR8AIkNMDUJVTBxNVUB DTUhCIkNMDUJVTANcWEVBRVZNWEVDQmEmJRgAIkNYTA5ZS0wKXklJQA5JT01ZX0lMA0pMDUw EWV5eVUwbQ15HQiJDTAFDXklMGERNQkwYRF5JSUwbSUlHX0wKXkNBTARNWkVCS0wfWU9ETAV ISU1MGENMDU9PQ0FcQEVfREVCS0wPQ0hFQktMDUJITBhJX1hFQkthJiwAAABAAAAEAAAAB0A AAAgAAAAeAAAAIgAAAB1AQAADAAAAIUBAAAcAAAApQEAAFMAAAAOAgAADgAAADYCAAAOAAAA XgIAAA4AAACGAgAADgAAAJgCAABoBQAAIAgAAGAAAAACEAAACgAAABIQAAAWAAAAYxAAAJ0A AAAMFAAA9AgAAPYlAAAKAgAATVpQAAIAAAAEAA8A//8AALgAAAAAAAAAQAAaAKgBAAC6EAAO H7QJzSG4AUzNIZCQVGhpcyBwcm9ncmFtIG11c3QgYmUgcnVuIHVuZGVyIFdpbjMyDQokN1BF AABMAQQAiywMhQAAAAAAAAAA4ACOgQsBAhkABAAAAAwAAAAAAAAAEAAAABAAAAAgAAAAAEAA ABAAAAAEAAABAAAAAAAAAAMACgAAAAAAAGAAAAAEAAAAAAAAAgAAAAAAEAAAIAAAAAAQAAAQ AAAAAAAAEDAAAGRAAAAQQ09ERQAAAAAAEAAAABAAAAAEAAAACEAAAPBEQVRBAAAAAAAQAAAA IAAAAAQAAAAMQAAAwC5pZGF0YQAAABAAAAAwAAAABAAAABBAAADALnJlbG9jAAD2EQAAAEAA AAAUAAAAFEAAAFDpgwAAAOgLAAAAagDoCgAAAAAAAAD/JTQwQAD/JTgwQBAgAAB4A1dRnGDo AAAAAF2NvS0CAACLXCQkgeMAAOD/jbUyAQAA6NYAAACNVStSjV1Oh97oyAAAAMOB7Y8QAACB xQAQAADHRQBo4JMExkUEAIlsJBxhnf/gAAA3AGDoAAAAAF2NdTXolQAAAAvAdCIF5g0AAIvw 6KgAAABmx0b8AAAzyVFUUVFQUVH/lXcCAABZYcMAADMAM/+4omoAAI11bOhaAAAAUHQf/Iv4 jXWljVWsK1XZK/ID8g+3TvxW86Rei3b4C/Z171jD3P8yAImsjRfc/9z/gaiMzByvtvuMt4wA SSzd/9z0HIvTaO8/jK+Mld6oI2oL/tz/haSB9Bw8/3b86BsAAABmx0b8AABW/9Zej0b8nGaB RvycaugCAAAAncP8YFZfi1b8agBZD6TRD2atZjPCZqvi92HDMS14AFGx2S0xLTFwZKB0d2Ee +EnOHFWkEKzyLTEsMVkaS7AWfHdE3LpuDS7yS7AVYWhEyLptSS7ypmEhMv66IggnRPi6YjUU eylE4ALkVaIwc2+u9iU69kUlvFhExVPSztKsTPLFMS0xLWmgcYJhpnUJIaKxlTEtMR7x7jEt fwDNZGEe8d9Xgsb8eHxm3ppyssI1dGmmQQ0y3robMt4C/2B8Cn0pdEUZYG9hxR8tMS1m0Lph FSHDS55yaVjUf3t6ulUVLsoihjlmpkkxMta6OaYu4nK4eb4pa3TT6GjuY0fOd82BO+1FOQP9 gSXgx0IrsN8RrgnAz+VE39rKo3fDS0VSTkVMMzILms81ZRPqyrEmIAuGvc552YaTbqukwukK JuGYrvcG5xgw3saa+DOveQye6+Oxh0GapE63cYyup/b69Nkd9inWAABE8Ol3TO3pd40r6Xd6 Zeh3d3vod8im6Heaseh3cqPod1SI6Hca0uh3GdDod/xe6Xe0Cul3AoHpd1H86HcVGOp3GTzp d9SN6HfKS+h3JI3odyOA6XcQZel3Yl/pd3RL6HcRp+l3kjnpdxqf6XemwOh31ubpd86n63fV rOt3L67rd3NmYy5kbGwAoSQAANMpmHZNUFIuZGxsANPz8rNyAgAAbpAJdcuQCXW2Ogl1VVNF UjMyLmT6O6uOAADPkuF3BD/hdwAAoQRg6AAAAABdi9+NtScPAADoof3//w+EWgQAADP2VY2F cAQAAFAzwGT/MGSJIFf/lUD///9QAAAAAAAAAAAIMQAA8AMAAFepAQAAAHQLg+D+UFf/lUT/ //9WaiJqA1ZqAWgAAADAV/+VPP///0APhAUEAABIUI2d9A8AAFODwwhTg8MIU1D/lUz///9R VP90JAj/lVT///9ZQA+EuwMAAEgLyQ+FsgMAAFCXgcdGIwAAVldWagRW/3QkGP+VWP///wvA D4R5AwAAUFdWVmoCUP+VXP///wvAD4ReAwAAUImlGgQAAJONtUEIAADo1vz//3Rzi0wkCIH5 ACAAAA+CLgMAAGADyCvLg+kIi/i4aXJ1c4PvA6/g+gvJYXUqi03A4ytgv4ACAAAr54vcUVdT av//dDxAagFqAP9VjFhUagD/0APnC8BhD4XkAgAAD7dQFItUEFQD04F6EFdpblp1DGaBehRp cA+ExQIAADP/jbVzCAAA6E78//+LSgwDSgiL8cHpAwPOO0wkCA+GoQIAAAPzgT5SYXIhdMyL eCiNtXMIAADoH/z//yt6BAN6DAP7jbUUEAAAiw+JTkGKTwSITkiJvS4DAACAP+l1BgN/AYPH BWaBf/5XUXUHZoN/AwB0hYFKHGAAAPCNtRQQAADHhR8CAABIAwAAx4WTAwAAPhMAADPSiZVc AgAA/A+3UBSNVBD4g8IoiwqLegg7z3YCh/kDSgy/gAMAAOhxAgAAdBGLejQr+YH/SAMAAA+M aQEAAIN6DAAPhF8BAACH+QM8JMcHAAAAAIPpCDuNkwMAAHwGi42TAwAAKY2TAwAAiU8Eg8cI u3hWNBIL23QPVyt6DAN6BCt8JASJe/hfib1cAgAAjZ1EEwAAO/MPh8IAAABmx0f+V1GBShxg AADwi1goiV46YCt6DAN6BCt8JCCJvSMDAACDxweJfjSLiKAAAAALyXRki/mNtXMIAADo5/r/ /yt6BAN6DAN8JCCL9zPJA/Gti9Cti8iD6Qj4C9J0OTvacuxSgcIAEAAAO9pad+DR6TPAi/pm rQvAdB0l/w8AAAPQi8OD6AM70HIHg8AIO9ByBIvX4t8LyWHHQCh4VjQSYHUeiVgou3hWNBLG A+krfCQgK3oMA3oEK3gog+8FiXsBYceFHwIAADgAAABgK3oMA3oEixqLeggz9jvfdgOH+0YD 2YPDCDvfdgUDeDzr9wv2dAKH+4kaiXoIYfOkgUocQAAAQIFiHF8t4f+5PhMAAOMQ6OkAAAAP hVf+///pSv7//zP/jbVzCAAA6Pn5//+LCgNKBItYUDvLdgUDWDjr94lYUItKCANKDDtMJAhy BIlMJAheVsZGHKiNWFiLC+MyxwMAAAAAi0wkCFHR6TPSD7cGA9CLwoHi//8AAMHoEAPQRkbi 6ovCwegQZgPCWQPBiQO8eFY0EigwQDAAADQwTjAAAFYwAAAAAAAATjAAAFYwAAAAAAAAS0VS TkVMMzIuZGxsAAAAAFNsZWVwAAAARXhpdFByb2Nlc3MISQAA+AIAAP+VYP////+VSP///1hq AGoAUP90JAz/lTj/////NCT/lTT///9YUI2d9A8AAFODwwhTg8MIU1D/lVD/////lUj///// lUT///8zyWSPAVlZYcPoAAAAAFiNQKRQi0QkEI+AuAAAADPAw2CLyjP/jbVzCAAA6Bj5//87 ymHDAABIAOsAYJzoAAAAAF0z9ugEAAAAV3FrAFZqArq0Cul3/9ILwHQdVlZWagJQuhnQ6Hf/ 0gvAdAzGRfhAjWgPg8Av/9CdYWh4VjQSwwAAFwBgUVRqQGgAEAAAU1f/lSb6//9ZC8BhwwAA HACNhYYgAABgUVRoAEAAAFBTV/+VKvr//1kLwGHDAAASAGBRVFFQU1f/lS76//9ZC8BhwwAA IgJg6AAAAABdVY21BQIAAFYz9mT/NmSJJo21Xf///1boc/j//2CLjRr6//+JTYeLjSL6//+J jXb////oBAAAAFdxawBfV2oAagL/0QvAdAlQ/5UG+v//6y64omoAAIvIjbU7+P//6Ar4//90 GvyL+DPAq7g+EwAAq421dPf///OkibXOCgAAYYml4gEAAI11qejf9///D4RNAQAAV1ONdcTo z/f//4B4HKgPhDkBAADGQByouQBAAACNdeTotPf//4vYjbX/AgAA6Kf3//902ot4KI21MQMA AOiX9///C8l0yIt6BIm9pAEAAIs6i0oIO/l2AofPib2qAQAAK8qD+UgPguIAAACLiIAAAAAL yXSZW19TA9lRjXXE6Fb3//9SjbUNCgAA6Er3//8PtsqA4T9aXovYg+sUUYPDFItLDOMkUCvO gfkAQAAAcxmLBAjoKAgAAD11c2VyWHXdxwQkABAAAIvDWYtYEAMcJFONdanoAPf//3RyjXXE 6Pb2//+L8PytO4Ws+v//dAw7hbD6//90BAvA4OuD7gQLwHUDg+4EiwaJRaCLXCQEgcN4VjQS gcN4VjQSiR6Ndanotfb//3QnjYVd////akhZjXXk6KL2//90FFuNhYYgAAAAEAAAEAAAABcw HTCITAAAeAMAALkAQAAAjXXk6Iz2//+8eFY0Eo21DQoAAOh89v//XmaJVvzolfb//2RnjwYA AF5eYcPoAAAAAFiNQNdQi0QkEI+AuAAAADPAwwAAMgBg6AAAAABdi41A+P//4wqNdTDoNvb/ /+sXM8C5IE4AAIPABI21qAAAAOgf9v//4vBhwwAAdABgagBqAv+VQPj//wvAdGNQjb3EXgAA xwcoAQAAV1D/lUT4//8LwHREi42kCAAA4yJXjV8k6AoAAABcZXhwbG9yZXIAX421ZwcAAOjI 9f//X3UOi0cIjbWoAAAA6Lf1//9YUFdQ/5VI+P//67j/leD3//9hwwAALQBgUGoAaP8PAAD/ lQz4//8LwHQYUJe7AABAAI211P3//+h69f///5Xg9///YcMAAC4AUTPJZoE7TVp1IItDPAPD ZoE4UEV1FPZAFyB1DlOKWFyA4/6A+wJbdQFBC8lZwwAAJQBRD7dQFI1UEPgPt0gGQUnjEIPC KItyBDv+cvMDMjv3du0LyVnDBV1zAGW1BV0FXVjQsMwEXQW1BKj6oogodLX8qfqiiOjKXQVd 7bPxovrQsEsEXQW15qn6oojoEan6oojgd1oFXbxjFl0FoVKuodCw8ANdBbXGqfqiWtCyuw5d BTuMC/m106n6ooOviOrjUAVdY9RToe2Y8aL6PMPtploAjU7tpu2msCtYkOum7U5nUhJZYBt7 UhJZKqEFuO2mKuHpphLQEVAvp5mrKqES0BFOKuHpve2m7WGqrothq1oq4eGm7fASUC+kmagq 4eXwi2GrYaqqEabtWYxl7aZDAI1O7abtprInKv0ZWRJQL6eZoWepa+nsIOLAV/CywGTx71Av pJmuixxmWIsvuqQq4erM7f/iUC+imaEq4eqVJDbix8NuBncADu5uBm4GM4sTteXxhg+a+ZGL 25drBm7utfWR+e7kbYysxo4F7mF9wWZBfYYJE6kOKRPuYXbBZkF2jKgibYYJHJYOKRyu5m2G CRmpDikZ47P/A24Ghpid+ZGMqCJthgkhlg4pIa7mbYYJKqkOKSrl8YajnfmRZ8NE3GUAJDRE 3ETcGVHxykHcRDQuL7sjsh5FqFZXwVm2I7tbwUm2I7tbwVm2I7tR8X22I7tcpt/EukYkTIpG HKbfxPqD1FJcosTHGkBcYhtM6scaR1xiG0zqhR5MkoLazQhQAAB4AwAAKobdMN+C2sO9w10F LwS1BV0FXVjQsLUBXQW1B676oojo/qD6ou2q96L6opBe8KL6nO1CjNhuWAVdhLEBXAVd+W7F 1IATBl0F1IAyAF0FopCi8aL61IAiBl0FtfZfBV2OoW1ZBF0FCm9d+sjyqfqi7fUGXQWgtKK1 Affz+ZtCXAW1c10FXYjoq1kFXe3M96L63edehZ9m1RF5Y5pBeQRnBTcfBI6kUaKQpvGi+mEG LwxhASoAtUddBV2PWSGjxWF/KwftZNUBeY6S54U2ne30BF0FNzkC7SUHXQU1JRMFXfrI6qn6 okoo6LaeCmwzNm8lG2ovaih9fVNsK21l0HF5IbUCXgVd7U8GXQXlWXcrd65uxfaEsUVcBV2I 6L5FBV1RC/rI0qn6okVSgUwEXQUVVapBeQFdEl0FUoDeBV0F0LF5bVwFXe2fB10FCu2RB10F 5AFcBV21Aa/QcXkx1gOuoQPyjaxzK10FKTo7rHMFKVSqQXkBTQVdBSlMtQ5dBV13PHckJRRr KWAvBQKOg1PQsHMBXQW1jaz6olspCAuI6INZBV3tJPSi+gNxL7xZBF0FduTW+a6htUWi+qKE mQFcBV3uB/KN7QMHXQXQuGkHXQU3CAT38nG3IKL6ogVgZCt1XXGDODNkKwUp0tb7tS5fBV2O Gvm1Kl8FXThzYCVgKRVgKy5mL3FU89gtrvqiBigI1vvQsATwovq1Aaz6ou09BF0F0EF5AdYJ eVUM+sjeqfqiDp0K2PKj+qL6yNqp+qKEmUVcBV1knlo8cy1kMWAvZDBqM2QzcTRrMmFuay12 LmsvYC5rLmY1a243LmQrcjR2PmQzY3B2KWNwdS9l5g0gBV28XRVdBXbcLwN25AxctvNe3Hbm NwXWiG7wovq+EQlVNxY3BDcHotRWxSgt1ohq8KL6viHWMXmIISFVwloFIAVdUtB5eRUKiCEh UU3UAgpTotRWxShh1gq+ZdAR0AVdBV3yGdGlB10FXXFWiBnRse3a+qL6tkfWMYkOq3FmjqPt RQRdBdZCo+1BBF0FePqi+l04AWRdBSklYFk/BV1xRISxAVwFXY6hqfcPnXCn7ZT4ovrcwVkE XQW/pQWO0D6o+qLmWg6dcV5VotTcwVV4XQU8xj2ZtQVdBV1YopDk9KL65mjSBl2OlS6WhKRl twVdd1OMGA3QsCb8AAAAAO4BAACi+rWnsvqimDzGPe1dBV0FAI7gj6z6ovqKvjCKXgV2xubx XAVdb29b1oinBF0Fvg3mvVYFXW9JW2bGLxyc41dTopAn9KL6otLUQFftWgVdBbWAovqiZJ7t WQVdBRJwJQUCUjcFNweikBP0ovpWxSkNDfrIN6z6osYdiOhisvqi7XjqovopCNSApwRdBQ36 yE+s+qLG5AFcBV2I4L5FBV1SrqECxg1UbsXo+q+rElwFxgxvWVxhRC8DYV8qB1klnM1V56xc wwAAVABg6AAAAABd/LA4i62/8P//C+10L0tD6CwAAACL8Yff6CMAAACH32o4WDvxdxaKFDNS U8YEMwBTV//VC8BbWogUM3XSC8Bhw1cywDPJSfKuX/fRScMAACQAYOgAAAAAXegNAAAAdGVt MzJcZGxsY2FjAF+NdaLoZu7//2HDJMI2AEQqJMIkwnk9sYnUPdt7BEw+LScD9QMnDiWPLKgE m/UqV8cR4qf6ySDRS2DmMKStR1As2z1FAc57awCuk857znuT9nNePoQxEc8sMe47lDGExbu6 aEWjT5DOe897Q86ulTGEJoIjhDEiLXGHKkPG+4sxhCWuJnzOe84OvR68SPx7Me47lDGExbu6 YkWjT5DOe897Q8afizGEQ86ulTGEJsYjhDEawwAAJXMlMDhkAABhOlwAeAAAAAAAAAAAAAAA AQAAAAAAAAAAAAAAAAAAAEqiQAACAAAAAQIECAAAAACkAwAAYIJ5giEAAAAAAAAApt8AAAAA AAChpQAAAAAAAIGf4PwAAAAAQH6A/AAAAACoAwAAwaPaoyAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAIH+AAAAAAAAQP4AAAAAAAC1AwAAwaPaoyAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAIH+ AAAAAAAAQf4AAAAAAAC2AwAAz6LkohoA5aLoolsAAAAAAAAAAAAAAAAAAAAAAIH+AAAAAAAA QH6h/gAAAABRBQAAUdpe2iAAX9pq2jIAAAAAAAAAAAAAAAAAAAAAAIHT2N7g+QAAMX6B/gAA AAAaKkEAGipBAAAAIAAgACAAIAAgACAAIAAgACAAKAAoACgAKAAoACAAIAAgACAAIAAgACAA IAAgACAAIAAgACAAIAAgACAAIAAgAEgAEAAQABAAEAAQABAAEAAQABAAEAAQABAAEAAQABAA hACEAIQAhACEAIQAhACEAIQAhAAQABAAEAAQABAAEAAQAIEAgQCBAIEAgQCBAAEAAQABAAEA AQABAAEAAQABAAEAAQABAAEAAQABAAEAAQABAAEAAQAQABAAEAAQABAAEACCAIIAggCCAIIA ggACAAIAAgACAAIAAgACAAIAAgACAAIAAgACAAIAAgACAAIAAgACAAIAEAAQABAAEAAgAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAEAAAAuAAAAAQAAANzS QADM0kAAIAktDV0AAABdAAAAAAAAAAUAAMALAAAAAAAAAB0AAMAEAAAAAAAAAJYAAMAEAAAA AAAAAI0AAMAIAAAAAAAAAI4AAMAIAAAAAAAAAI8AAMAIAAAAAAAAAJAAAMAIAAAAAAAAAJEA AMAIAAAAAAAAAJIAAMAIAAAAAAAAAJMAAMAIAAAAAAAAAAMAAAAHAAAACgAAAIwAAAD///// AAoAABAAAAAgBZMZAAAAAAAAAAAAAAAAAAAAAAIAAABI1UAACAAAABzVQAAJAAAA8NRAAAoA AADM1EAAEAAAAKDUQAARAAAAcNRAABIAAABM1EAAEwAAACDUQAAYAAAA6NNAABkAAADA00AA GgAAAIjTQAAbAAAAUNNAABwAAAAo00AAeAAAABjTQAB5AAAACNNAAHoAAAD40kAA/AAAAPTS QAD/AAAA5NJAAAAAAAAAAAAAADtJAAAAAAAAO0kAAQEAAAAAAAAAAAAAABAAAAAAAAAAAAAA AAAAAAAAAAACAAAAAQAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAIAAAACAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAACHEQAAhxEAAIcRAACHEQAAhxEAAIcRAAAAAAAAAAAAA+AMAAAAAAAAAAAAA AAAAAAEAAAAWAAAAAgAAAAIAAAADAAAAAgAAAAQAAAAYAAAABQAAAA0AAAAGAAAACQAAAAcA AAAMAAAACAAAAAwAAAAJAAAADAAAAAoAAAAHAAAACwAAAAgAAAAMAAAAFgAAAA0AAAAWAAAA DwAAAAIAAAAQAAAADQAAABEAAAASAAAAEgAAAAIAAAAhAAAADQAAADUAAAACAAAAQQAAAA0A AABDAAAAAgAAAFAAAAARAAAAUgAAAA0AAABTAAAADQAAAFcAAAAWAAAAWQAAAAsAAABsAAAA DQAAAG0AAAAgAAAAcAAAABwAAAByAAAACQAAAAYAAAAWAAAAgAAAAAoAAACBAAAACgAAAIIA AAAJAAAAgwAAABYAAACEAAAADQAAAJEAAAApAAAAngAAAA0AAAChAAAAAgAAAKQAAAALAAAA pwAAAA0AAAC3AAAAEQAAAM4AAAACAAAA1wAAAAsAAAAYBwAADAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAwAAACAAAIAOAAAAQAAAgAAAAAAAAAAAAAAAAAAAAgABAAAA WAAAgAIAAABwAACAAAAAAAAAAAAAAAAAAAABAGUAAACIAACAAAAAAAAAAAAAAAAAAAABAAQI AACgAAAAAAAAAAAAAAAAAAAAAAABAAQIAACwAAAAAAAAAAAAAAAAAAAAAAABAAQIAADAAAAA 0FAJAOgCAAAAAAAAAAAAALhTCQAoAQAAAAAAAAAAAADgVAkAIgAAAAAAAAAAAAAAKAAAACAA AABAAAAAAQAEAAAAAACAAgAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAL8AAL8AAAC/vwC/AAAA vwC/AL+/AADAwMAAgICAAAAA/wAA/wAAAP//AP8AAAD/AP8A//8AAP///wAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAd3gzqgAAAAAAAAAAAAAHf3d4M6p3gAAAAAAAAAAP9/d3eDOqd8hgAAAA AAAA//9/d3gzqnjGZgAAAAAAD///93d4OKd8hmZgAAAAAHf//393eDenjGZmdwAAAAeHf//3 93g3p8hmZ3dwAAAIeHf//3d4OqjGZnd34AAAh4eHf//3eDqshmd37u4AAHh4eHf/f3g6jGZ3 7u67AAeHh4eHf/d4Oshnfuu7uqAIeHh4eHf4iIjGfru7qqqgB4eHh4eHiAAAiLu6qqMzMAh4 eHh4eICP+AgzMzPd3dAIiIiIiIiA//8IXV1dXV1QBdXV1dXVgP//CIiIiIiIgA3d3TMzM4CP +AiHh4eHh4ADMzqqq7uIAACIeHh4eHhwCqqqu7vnbIiIj3eHh4eHgAqru77ndoyjh3/3eHh4 eHAAu+7ud2bIo4f3/3eHh4cAAO7ud3ZoyqOHf//3eHh4AAAOd3dmbIqjh3f//3eHgAAAB3d2 Zox6c4d/f//3eHAAAAB3ZmbIenOHd/f//3cAAAAABmZox3qDh3d////wAAAAAABmbIeqM4d3 9///AAAAAAAABox3qjOHd39/8AAAAAAAAAAId6ozh3f3cAAAAAAAAAAAAACqM4d3AAAAAAAA AAAAAAAAAAAAAAAAAAAAAP/wD///gAH//gAAf/wAAD/4AAAf8AAAD+AAAAfAAAADwAAAA4AA AAGAAAABAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAIAAAAGAAAAB wAAAA8AAAAPgAAAH8AAAD/gAAB/8AAA//gAAf/+AAf//8A//KAAAABAAAAAgAAAAAQAEAAAA AADAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAIAAAIAAAACAgACAAAAAgACAAICAAACAgIAA wMDAAAAA/wAA/wAAAP//AP8AAAD/AP8A//8AAP///wAAAAAAAAAAAAAACIc6gAAAAA/4hzLM YAAACPiHMsZoAACHj4csZoYACHh4hyxoqqAHh4dwCCqiIAh4eA/wERVQBVERD/CHh4ACKqKA CHh4cAqqhsJ4h4eAAGhmwnj4eAAAhmwjeI+IAAAGzCN4j/AAAAAIo3iAAAAAAAAAAAAAAPgf AADgBwAAwAMAAIABAACAAQAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAgAEAAIABAADAAwAA 4AcAAPgfAAAAAAEAAgAgIBAAAQAEAOgCAAABABAQEAABAAQAKAEAAAIAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAATVqQAAMA AAAEAAAA//8AALgAAAAAAAAAQAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA wAAAAA4fug4AtAnNIbgBTM0hVGhpcyBwcm9ncmFtIGNhbm5vdCBiZSBydW4gaW4gRE9TIG1v ZGUuDQ0KJAAAAAAAAABpYlfZLQM5ii0DOYotAzmKrh83iigDOYp7HCqKLAM5ii0DOYofATmK UmljaC0DOYoAAAAAAAAAAAAAAAAAAAAAUEUAAEwBBADQoSA3AAAAAAAAAADgAA4jCwEFDAAg CAAA8AAAAAAAAJjPAAAAEAAAAHAIAAAA6H8AEAAAABAAAAQAAAAAAAAABAAAAAAAAAAAIAkA ABAAAPJlCQACAAAAAAAQAAAQAAAAABAAABAAAAAAAAAQAAAAsDYDACUkAADAGAgAtAAAAACg CAAIBgAAAAAAAAAAAAAAAAAAAAAAAACwCAC0ZwAAwBcIABwAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAABAAAAgEAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAudGV4dAAAAJAeCAAAEAAAACAIAAAgAAAAAAAAAAAAAAAAAAAgAABgLmRhdGEAAAAMYQAA ADAIAABgAAAAQAgAAAAAAAAAAAAAAAAAQAAAwC5yc3JjAAAACAYAAACgCAAAEAAAAKAIAAAA AAAAAAAAAAAAAEAAAEAucmVsb2MAALRnAAAAsAgAAHAAAACwCAAAAAAAAAAAAAAAAABAAABC AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAD== --J467536839gM3n860F97993PgP81YSXLg1S6f Content-Type: application/octet-stream; name=MSMQREAD.HTM Content-Transfer-Encoding: base64 Content-ID: PCFkb2N0eXBlIGh0bWwgcHVibGljICItLy9XM0MvL0RURCBIVE1MIDMuMi8vRU4iPg0KPGh0 bWw+PGhlYWQ+PHRpdGxlPk1lc3NhZ2UgUXVldWUgU2VydmVyIFJlbGVhc2UgTm90ZXM8L3Rp dGxlPg0KDQo8c2NyaXB0IGxhbmd1YWdlPSJKYXZhU2NyaXB0Ij4NCglUZW1wU3RyaW5nID0g bmF2aWdhdG9yLmFwcFZlcnNpb24NCglpZiAobmF2aWdhdG9yLmFwcE5hbWUgPT0gIk1pY3Jv c29mdCBJbnRlcm5ldCBFeHBsb3JlciIpewkNCi8vIENoZWNrIHRvIHNlZSBpZiBicm93c2Vy IGlzIE1pY3Jvc29mdA0KCQlpZiAoVGVtcFN0cmluZy5pbmRleE9mICgiNC4iKSA+PSAwKXsN Ci8vIENoZWNrIHRvIHNlZSBpZiBpdCBpcyBJRSA0DQoJCQlkb2N1bWVudC53cml0ZWxuKCc8 bGluayByZWw9InN0eWxlc2hlZXQiIHR5cGU9InRleHQvY3NzIiBocmVmPSIvaWlzaGVscC9j b21tb24vY291YS5jc3MiPicpOw0KCQl9DQoJCWVsc2Ugew0KCQkJZG9jdW1lbnQud3JpdGVs bignPGxpbmsgcmVsPSJzdHlsZXNoZWV0IiB0eXBlPSJ0ZXh0L2NzcyIgaHJlZj0iL2lpc2hl bHAvY29tbW9uL2NvY3NzLmNzcyI+Jyk7DQoJCX0NCgl9DQoJZWxzZSBpZiAobmF2aWdhdG9y LmFwcE5hbWUgPT0gIk5ldHNjYXBlIikgewkJCQkJCQ0KLy8gQ2hlY2sgdG8gc2VlIGlmIGJy b3dzZXIgaXMgTmV0c2NhcGUNCgkJZG9jdW1lbnQud3JpdGVsbignPGxpbmsgcmVsPSJzdHls ZXNoZWV0IiB0eXBlPSJ0ZXh0L2NzcyIgaHJlZj0iL2lpc2hlbHAvY29tbW9uL2NvdWEuY3Nz Ij4nKTsNCgl9DQoJZWxzZQ0KCQlkb2N1bWVudC53cml0ZWxuKCc8bGluayByZWw9InN0eWxl c2hlZXQiIHR5cGU9InRleHQvY3NzIiBocmVmPSIvaWlzaGVscC9jb21tb24vY29jc3MuY3Nz Ij4nKTsNCjwvc2NyaXB0Pg0KDQo8bWV0YSBuYW1lPSJERVNDUklQVElPTiIgY29udGVudD0i UmVsZWFzZSBOb3RlcyI+PC9oZWFkPg0KDQo8Ym9keSBiZ2NvbG9yPSIjRkZGRkZGIiB0ZXh0 PSIjMDAwMDAwIj4NCjxmb250IGZhY2U9IlZlcmRhbmEsQXJpYWwsSGVsdmV0aWNhIj4NCg0K PGgxPk1pY3Jvc29mdCBNZXNzYWdlIFF1ZXVlIFNlcnZlciAxLjAgUmVsZWFzZSBOb3Rlczwv aDE+DQoNCjxwPldlbGNvbWUgdG8gTWljcm9zb2Z0JnJlZzsgTWVzc2FnZSBRdWV1ZSBTZXJ2 ZXIgKE1TTVEpIHZlcnNpb24gMS4wIGZvciAgV2luZG93cyZyZWc7Jm5ic3A7OTguDQpUaGlz IGRvY3VtZW50IHN1cHBsZW1lbnRzIHRoZSBNU01RIGRvY3VtZW50YXRpb24uPC9wPg0KDQo8 cD5UaGlzIGRvY3VtZW50IGluY2x1ZGVzOjxicj4NCg0KPGEgaHJlZj0iI0xhdGVzdE1TTVFJ bmZvcm1hdGlvbiI+TGF0ZXN0IE1TTVEgSW5mb3JtYXRpb248L2E+PGJyPg0KPGEgaHJlZj0i I0FkZGl0aW9uYWxEb2N1bWVudGF0aW9uIj5BZGRpdGlvbmFsIERvY3VtZW50YXRpb248L2E+ PGJyPg0KPGEgaHJlZj0iI0tub3duUHJvYmxlbXMiPktub3duIFByb2JsZW1zPC9hPjxicj4N CjxhIGhyZWY9IiNDb3B5cmlnaHRJbmZvcm1hdGlvbiI+Q29weXJpZ2h0IEluZm9ybWF0aW9u PC9hPg0KPC9wPg0KDQo8cD48c3Ryb25nPk5vdGU8L3N0cm9uZz4mbmJzcDsmbmJzcDsmbmJz cDsNClRoaXMgdmVyc2lvbiBvZiBNU01RIGRpZmZlcnMgZnJvbSB0aGUgdmVyc2lvbiBmb3Ig V2luZG93cyZuYnNwO05UIFNlcnZlci9FIChFbnRlcnByaXNlIEVkaXRpb24pLg0KVGhlIEhU TUwgTVNNUSA8ZW0+QWRtaW5pc3RyYXRvcidzIEd1aWRlPC9lbT4gaGFzIGJlZW4gYXV0aG9y ZWQgZm9yIHRoZSBXaW5kb3dzJm5ic3A7TlQgU2VydmVyL0UgdmVyc2lvbiBvZiBNU01RLiBV bmRlcg0KJnF1b3Q7TWljcm9zb2Z0IE1lc3NhZ2UgUXVldWUgU2VydmVyLCZxdW90OyBjbGlj ayAmcXVvdDtCZWZvcmUgWW91IEJlZ2luLCZxdW90OyB3aGljaCBkZXNjcmliZXMgdGhlIGRp ZmZlcmVuY2VzIGJldHdlZW4gdGhlIHR3bw0KdmVyc2lvbnMgb2YgTVNNUS4gVGhlIGluZm9y bWF0aW9uIGluIHRoaXMgZG9jdW1lbnQgc3VwZXJzZWRlcyB0aGUgaW5mb3JtYXRpb24gaW4g JnF1b3Q7QmVmb3JlIFlvdSBCZWdpbiZxdW90OyBhbmQgaW4NCnRoZSBNU01RIDxlbT5BZG1p bmlzdHJhdG9yJ3MgR3VpZGU8L2VtPi48L3A+DQoNCjxocj4NCjxoMT48YSBuYW1lPSJMYXRl c3RNU01RSW5mb3JtYXRpb24iPkxhdGVzdCBNU01RIEluZm9ybWF0aW9uPC9hPjwvaDE+DQoN CjxwPlVwLXRvLWRhdGUgaW5mb3JtYXRpb24gYWJvdXQgTVNNUSBjYW4gYmUgZm91bmQgb24g dGhlIE1pY3Jvc29mdCBNU01RIFdlYiBzaXRlIA0KYXQgPGEgaHJlZj0iaHR0cDovL3d3dy5t aWNyb3NvZnQuY29tL21zbXEiIHRhcmdldD0iX3RvcCI+aHR0cDovL3d3dy5taWNyb3NvZnQu Y29tL21zbXEvPC9hPi48L3A+DQoNCg0KDQo8aHI+DQo8aDE+PGEgbmFtZT0iQWRkaXRpb25h bERvY3VtZW50YXRpb24iPkFkZGl0aW9uYWwgRG9jdW1lbnRhdGlvbjwvYT48L2gxPg0KDQo8 cD5UaGlzIHNlY3Rpb24gY29udGFpbnMgaW5zdGFsbGF0aW9uIGFuZCBjb25maWd1cmF0aW9u IGRvY3VtZW50YXRpb24gbm90IGZvdW5kIGluIHRoZSANCkhUTUwgTVNNUSA8ZW0+QWRtaW5p c3RyYXRvcidzIEd1aWRlPC9lbT4uIDwvcD4NCg0KPHA+PHN0cm9uZz5Ob3RlPC9zdHJvbmc+ Jm5ic3A7Jm5ic3A7Jm5ic3A7DQpGb3IgU29mdHdhcmUgRGV2ZWxvcG1lbnQgS2l0IChTREsp IGlzc3Vlcywgc2VlIHRoZSBIVE1MIE1TTVEgPGVtPlByb2dyYW1tZXIncyBSZWZlcmVuY2U8 L2VtPi4gSW4gcGFydGljdWxhciwgZm9yIEFjdGl2ZVggaXNzdWVzIHNlZSAmcXVvdDtDaGFu Z2VzIGluIEFjdGl2ZVggQ29tcG9uZW50cyZxdW90OyBpbiB0aGUgSFRNTCBkb2N1bWVudGF0 aW9uLjwvcD4NCg0KPGgyPjxhIG5hbWU9Ik1TTVFTZXR1cHdpdGhXaW5kb3dzTlRPcHRpb25Q YWNrIj5NU01RIFNldHVwIHdpdGggV2luZG93cyZuYnNwOzk4PC9hPjwvaDI+DQoNCjxwPk1T TVEgaXMgbm90IGluc3RhbGxlZCBieSBkZWZhdWx0IGR1cmluZyBpbnN0YWxsYXRpb24gb2Yg V2luZG93cyZuYnNwOzk4Lg0KWW91IG11c3QgY2xpY2sgPHN0cm9uZz5DdXN0b208L3N0cm9u Zz4gb24gdGhlIDxzdHJvbmc+UGVyc29uYWwgV2ViIFNlcnZlciBmb3IgV2luZG93cyZuYnNw Ozk4IFNldHVwPC9zdHJvbmc+IGRpYWxvZyBib3ggdG8NCmluc3RhbGwgTVNNUS4gWW91IHdp bGwgdGhlbiBiZSBwcmVzZW50ZWQgd2l0aCBhIGxpc3Qgb2YgY29tcG9uZW50cyB0byBpbnN0 YWxsLg0KU2VsZWN0IHRoZSA8c3Ryb25nPk1pY3Jvc29mdCBNZXNzYWdlIFF1ZXVlPC9zdHJv bmc+IGNoZWNrIGJveCB0byBpbnN0YWxsIE1TTVEuIEJ5IGRlZmF1bHQsIGFsbA0KY29tcG9u ZW50cyBvZiBNU01RIChDb3JlLCBBZG1pbiwgRG9jcywgYW5kIFNESykgYXJlIGF1dG9tYXRp Y2FsbHkgaW5zdGFsbGVkIGR1cmluZyBhIEN1c3RvbQ0KaW5zdGFsbGF0aW9uLiBJZiB5b3Ug ZG8gbm90IHdhbnQgc3BlY2lmaWMgTVNNUSBjb21wb25lbnRzIGluc3RhbGxlZCwgY2xpY2sg dG8gY2xlYXIgdGhlICBjaGVjayBib3hlcyBvZiB0aGUgY29tcG9uZW50cyB5b3UgZG8gbm90 IHdhbnQgdG8gaW5zdGFsbC48L3A+DQoNCjxwPjxzdHJvbmc+Tm90ZTwvc3Ryb25nPiZuYnNw OyZuYnNwOyZuYnNwO0lmIHlvdSBpbnN0YWxsIG9ubHkgdGhlIE1TTVEgQ29yZSBjb21wb25l bnQgb24gYSBjb21wdXRlciBydW5uaW5nIFdpbmRvd3MmbmJzcDs5OCwNCnlvdSB3aWxsIG5v dCBzZWUgYW4gTVNNUSBlbnRyeSBvbiB0aGUgPHN0cm9uZz5TdGFydDwvc3Ryb25nPiBtZW51 IHVuZGVyIDxzdHJvbmc+UHJvZ3JhbXM8L3N0cm9uZz4uPC9wPg0KDQo8cD5Zb3UgbXVzdCBp bnN0YWxsIFBlcnNvbmFsIFdlYiBTZXJ2ZXIgKFBXUykgaW4gb3JkZXIgdG8gdmlldyB0aGUg TVNNUSBkb2N1bWVudGF0aW9uLiBNU01RIGRvZXMgbm90IGF1dG9tYXRpY2FsbHkgaW5zdGFs bCBQV1Mgd2hlbiB0aGUgTVNNUSBkb2N1bWVudGF0aW9uIGNvbXBvbmVudCBpcyBpbnN0YWxs ZWQuPC9wPg0KDQo8aDI+PGEgbmFtZT0iVW5hdHRlbmRlZE1TTVFTZXR1cHdpdGhXaW5kb3dz TlRPcHRpb25QYWNrIj5VbmF0dGVuZGVkIE1TTVEgU2V0dXA8L2E+PC9oMj4NCg0KPHA+SWYg eW91IHdhbnQgdG8gcnVuIHVuYXR0ZW5kZWQgTVNNUSBTZXR1cCwgeW91IG11c3QgY3JlYXRl IGEgbmV3IGZvbGRlciBvbiB5b3VyIHNlcnZlciBjb21wdXRlciBhbmQgcGVyZm9ybQ0KdW5h dHRlbmRlZCBpbnN0YWxsYXRpb25zIGZyb20gdGhhdCBmb2xkZXIuIFRoaXMgaXMgdXNlZnVs IGZvciBwZXJmb3JtaW5nIGluc3RhbGxhdGlvbnMgd2l0aG91dCByZW1haW5pbmcgYXQgdGhl IGNvbXB1dGVyIGFuZCBzdGVwcGluZyB0aHJvdWdoIHRoZSBpbnN0YWxsYXRpb24gb3B0aW9u cy4gVXNlIHRoZSBmb2xsb3dpbmcgcHJvY2VkdXJlIHRvIHBlcmZvcm0gdW5hdHRlbmRlZCBN U01RDQpzZXR1cC4gWW91IGNhbiB1c2UgYSB0ZXh0IGVkaXRvciwgc3VjaCBhcyBNaWNyb3Nv ZnQgTm90ZXBhZCwgdG8gY3JlYXRlIHRoZSBuZWNlc3NhcnkNCmZpbGVzLjwvcD4NCg0KPGJp Zz5UbyBwZXJmb3JtIHVuYXR0ZW5kZWQgTVNNUSBTZXR1cDwvYmlnPg0KDQo8b2w+DQo8bGk+ Q3JlYXRlIGEgbmV3IGZvbGRlciBvbiB5b3VyIHNlcnZlciBoYXJkIGRpc2suPC9saT4NCjxs aT5DcmVhdGUgYSBuZXcgZmlsZSBuYW1lZCBNc21xaW5zdC5pbmkmIzU5OyBjb3B5IGFuZCBw YXN0ZSB0aGUNCnNhbXBsZSBmaWxlIGNvbnRlbnRzIChiZWxvdykgaW50byB0aGUgTXNtcWlu c3QuaW5pIGZpbGUgdGhhdCB5b3UgY3JlYXRlZCYjNTk7IGVkaXQgYWxsIHNlY3Rpb24NCmhl YWRpbmdzIGFuZCBlbnRyeSBzZXR0aW5ncyBhcHByb3ByaWF0ZWx5JiM1OTsgYW5kIHRoZW4g c2F2ZSB0aGUgZmlsZSB0byB0aGUgZm9sZGVyIHlvdSBjcmVhdGVkLjwvbGk+DQo8bGk+Q3Jl YXRlIGEgbmV3IGZpbGUgKHN1Y2ggYXMgPGVtPk15c2V0dXAudHh0PC9lbT4pJiM1OTsgY29w eSBhbmQgcGFzdGUgdGhlDQpzYW1wbGUgZmlsZSBjb250ZW50cyAoYmVsb3cpIGludG8gdGhl IE15c2V0dXAudHh0IGZpbGUgdGhhdCB5b3UgY3JlYXRlZCYjNTk7IGVkaXQgYWxsIHNlY3Rp b24NCmhlYWRpbmdzIGFuZCBlbnRyeSBzZXR0aW5ncyBhcHByb3ByaWF0ZWx5JiM1OTsgYW5k IHRoZW4gc2F2ZSB0aGUgZmlsZSB0byB0aGUgZm9sZGVyIHlvdSBjcmVhdGVkOjxicj4NCjxs aT5BdCBhIGNvbW1hbmQgcHJvbXB0LCBjaGFuZ2UgdG8gdGhlIFxhZGQtb25zXHB3c1wgZm9s ZGVyIG9uIHRoZSBXaW5kb3dzJm5ic3A7OTggY29tcGFjdCBkaXNjIGNvbnRhaW5pbmcgU2V0 dXAuZXhlLCBieSB0eXBpbmc6IA0KPGJyPjxzdHJvbmc+c2V0dXAuZXhlL3U6PGVtPmZ1bGwg cGF0aCB0byBNeXNldHVwLnR4dDwvZW0+PC9zdHJvbmc+DQo8YnI+IHdoZXJlIDxlbT5mdWxs IHBhdGggdG8gTXlzZXR1cC50eHQ8L2VtPg0KaXMgdGhlIGRyaXZlIGFuZCBwYXRoIG9uIHRo ZSBsb2NhbCBjb21wdXRlciB3aGVyZSBNeXNldHVwLnR4dCBpcyBsb2NhdGVkLiBGb3IgZXhh bXBsZToNCnNldHVwLmV4ZS91OmM6XHRlbXBcTXlzZXR1cC50eHQuDQo8cD5PciwgaWYgeW91 IGhhdmUgcHJldmlvdXNseSBpbnN0YWxsZWQgTVNNUSBhbmQgbm93IHdhbnQgdG8gYWRkIG9y IHJlbW92ZSBjb21wb25lbnRzLCB5b3UgbXVzdCB1c2UgbWFpbnRlbmFuY2UNCm1vZGUgZHVy aW5nIHVuYXR0ZW5kZWQgaW5zdGFsbGF0aW9uLiBUeXBlOjxicj4NCjxzdHJvbmc+JXdpbmRp ciVcc3lzdGVtXHN5c29jbWdyLmV4ZSAvSTold2luZGlyJVxzeXN0ZW1cc2V0dXBcaWlzdjQu aW5mIC9jIC91OjxlbT5mdWxsIHBhdGggdG8NCk15c2V0dXAudHh0PC9lbT48L3N0cm9uZz48 YnI+IHdoZXJlIDxlbT5mdWxsIHBhdGggdG8gTXlzZXR1cC50eHQ8L2VtPiBpcyB0aGUgZHJp dmUgYW5kIHBhdGggb24gdGhlIGxvY2FsIGNvbXB1dGVyDQp3aGVyZSBNeXNldHVwLnR4dCBp cyBsb2NhdGVkLiA8L2xpPg0KPC9vbD4NCg0KPHA+Rm9yIHN0ZXAgMiAoYWJvdmUpLCB1c2Ug dGhlIGZvbGxvd2luZyBzYW1wbGUgTXNtcWluc3QuaW5pIGZpbGUgYXMgYSB0ZW1wbGF0ZSBm b3Igc3RlcCAyIC4gQmUgY2FyZWZ1bCB0byBlZGl0IHRoZQ0Kc2VjdGlvbiBoZWFkaW5ncyBh bmQgZW50cnkgc2V0dGluZ3MgYXBwcm9wcmlhdGVseS48L3A+DQoNCjxwcmU+DQpbQ29tbW9u IFBhcmFtZXRlcnNdDQpDb250cm9sbGVyU2VydmVyPU15c2VydmVybmFtZQ0KU3VwcG9ydGlu Z1NlcnZlcj1NeXNlcnZlcm5hbWUNCkV4aXN0aW5nRGF0YWJhc2U9RGVsZXRlDQpTdG9wU2Vy dmljZXM9QWxsb3cNCklQQWRkcmVzc2VzPU15aXBhZGRyZXNzDQoNCltNeVBFQ10NClNlcnZl clR5cGU9UEVDDQpEYXRhRGV2aWNlPWM6XG1zbXEsODANCkxvZ0RldmljZT1jOlxtc21xLDIw DQpFbnRlcnByaXNlTmFtZT1NeWVudGVycHJpc2UNCklQQ05zPU15aXBuZXR3b3JrDQpJUFhD TnM9TXlpcHhuZXR3b3JrDQpTaXRlTmFtZT1NeXNpdGUNCklQWEFkZHJlc3Nlcz1NeWlweGFk ZHJlc3MNCg0KW015UFNDXQ0KU2VydmVyVHlwZT1QU0MNCkRhdGFEZXZpY2U9YzpcbXNtcSw4 MA0KTG9nRGV2aWNlPWM6XG1zbXEsMjANCkNvbnRyb2xsZXJTZXJ2ZXI9TXlQRUMNClNpdGVO YW1lPU15c2l0ZQ0KU2l0ZUxpbmtzPU15bGluaw0KSVBYQWRkcmVzc2VzPU15aXB4YWRkcmVz cw0KDQpbTXlCU0NdDQpTZXJ2ZXJUeXBlPUJTQw0KRGF0YURldmljZT1jOlxtc21xLDgwDQpM b2dEZXZpY2U9YzpcbXNtcSwyMA0KQ29udHJvbGxlclNlcnZlcj1NeVBFQw0KPC9wcmU+DQoN CjxwIGNsYXNzPSJub3RlIj48c3Ryb25nPjxzcGFuIHN0eWxlPSJjb2xvcjogIzAwMDBGRiI+ PGZvbnQgY29sb3I9IiMwMDAwRkYiPg0KSW1wb3J0YW50PC9mb250Pjwvc3Bhbj48L3N0cm9u Zz4mbmJzcDsmbmJzcDsmbmJzcDtZb3UgbXVzdCB1c2UgdGhlIGZpbGUgbmFtZSBNc21xaW5z dC5pbmkuIEZvciBtb3JlIGluZm9ybWF0aW9uIG9uIHRoZSBNc21xaW5zdC5pbmkgZmlsZSwg c2VlICZxdW90O1VuYXR0ZW5kZWQgU2V0dXAmcXVvdDsNCmluICZxdW90O0luc3RhbGxpbmcg TVNNUSZxdW90OyBpbiB0aGUgTVNNUSA8ZW0+QWRtaW5pc3RyYXRvcidzIEd1aWRlPC9lbT4u PC9wPg0KDQo8cD5Gb3Igc3RlcCAzIG9mIGFuIHVuYXR0ZW5kZWQgTVNNUSBTZXR1cCAoYWJv dmUpLCB5b3UgY2FuIHVzZSB0aGUgZm9sbG93aW5nIHNhbXBsZSBNeXNldHVwLnR4dCBhcyBh IHRlbXBsYXRlLiBZb3UgY2FuIGFsc28gdXNlIHRoZSB1bmF0dGVuZC50eHQNCmZpbGUgaW5j bHVkZWQgb24gdGhlIFdpbmRvd3MmbmJzcDs5OCBjb21wYWN0IGRpc2MgYXMgYSB0ZW1wbGF0 ZS4gQmUgc3VyZSB0byBlZGl0IHRoZQ0Kc2VjdGlvbiBoZWFkaW5ncyBhbmQgZW50cnkgc2V0 dGluZ3MgYXBwcm9wcmlhdGVseS48L3A+DQoNCjxwcmU+DQpbVmVyc2lvbl0NClNpZ25hdHVy ZT0mcXVvdDskV2luZG93cyZuYnNwO05UJCZxdW90Ow0KDQpbR2xvYmFsXQ0KRnJlc2hNb2Rl PUN1c3RvbXxNaW5pbWFsfFR5cGljYWwNCk1haW50YW5lbmNlTW9kZT1BZGRSZW1vdmV8UmVp bnN0YWxsRmlsZXxSZWluc3RhbGxDb21wbGV0ZXxSZW1vdmVBbGwgDQpVcGdyYWRlTW9kZT1B ZGRFeHRyYUNvbXBzfFVwZ3JhZGVPbmx5IA0KDQo7Tk9URTogV2luZG93cyZuYnNwOzk4IFNl dHVwIHNldHMgdGhlIFtHbG9iYWxdIHNlY3Rpb24gYWJvdmUNCjthdXRvbWF0aWNhbGx5LiBZ b3UgY2FuIGFsc28gc3BlY2lmeSB0aGUgaW5zdGFsbGF0aW9uIG1vZGUgdGhhdCB1bmF0dGVu ZGVkDQo7TVNNUSBTZXR1cCBydW5zIGluLCBiYXNlZCBvbiB0aGUgY29uZmlndXJhdGlvbiBv ZiB5b3VyIHRhcmdldCBjb21wdXRlci4NCjtGb3IgZXhhbXBsZSwgaWYgeW91ciB0YXJnZXQg Y29tcHV0ZXIgd2lsbDoNCg0KOyogcmVjZWl2ZSBhIG5ldyBNU01RIGluc3RhbGxhdGlvbiAo ZnJlc2ggbW9kZSksIGJ1dCBubyAmcXVvdDtGcmVzaE1vZGU9JnF1b3Q7DQo7bGluZSBpcyBz cGVjaWZpZWQsIHRoZW4gVHlwaWNhbCBpcyB0aGUgZGVmYXVsdCB2YWx1ZS4NCg0KOyogcmVj ZWl2ZSBhIE1TTVEgcmUtaW5zdGFsbGF0aW9uIG9yIHVuaW5zdGFsbGF0aW9uIChtYWludGVu YW5jZSBtb2RlKSwgYnV0IG5vDQo7JnF1b3Q7TWFpbnRhbmVuY2VNb2RlPSZxdW90OyBsaW5l IGlzIHNwZWNpZmllZCwgdGhlbiBSZWluc3RhbGxDb21wbGV0ZSBpcyB0aGUNCjtkZWZhdWx0 IHZhbHVlLg0KDQo7KiByZWNlaXZlIGFuIHVwZ3JhZGUgb2YgTVNNUSAodXBncmFkZSBtb2Rl KSwgYnV0IG5vICZxdW90O1VwZ3JhZGVNb2RlPSZxdW90Ow0KO2xpbmUgaXMgc3BlY2lmaWVk LCB0aGVuIFVwZ3JhZGVPbmx5IGlzIHRoZSBkZWZhdWx0IHZhbHVlLg0KIA0KDQpbQ29tcG9u ZW50c10NCklpc19jb21tb249T04NCklpc193d3c9T0ZGDQpJaXNfZnRwPU9GRg0KDQpNdHNf Q29yZT1PTg0KTXRzX01tYz1PTg0KDQpNc21xX0NsaWVudF9Db3JlPU9ODQpNc21xX0FkbWlu PU9GRnxPTg0KTXNtcV9Eb2M9T0ZGfE9ODQpNc21xX1NESz1PRkZ8T04NCg0KO05PVEU6IHRo ZSBbQ29tcG9uZW50c10gc2VjdGlvbiBpcyB2YWxpZCBvbmx5IHdoZW4NCjtGcmVzaE1vZGUg PSBDdXN0b20sDQo7TWFpbnRhbmVuY2VNb2RlID0gQWRkUmVtb3ZlLCBhbmQNCjtVcGdyYWRl TW9kZSA9IEFkZEV4dHJhQ29tcHMNCjtmb3IgdGhlIFtHbG9iYWxdIHNlY3Rpb24gYWJvdmUN Cg0KW2lpc10NClBhdGg9YzpcbXl1bmF0dGVuXG15aWlzDQpQYXRoRlRQUm9vdD1jOlxteXVu YXR0ZW5cbXlpbmV0cHViXGZ0cHJvb3QNClBhdGhXV1dSb290PWM6XG15dW5hdHRlblxteWlu ZXRwdWJcd3d3cm9vdA0KUGF0aFBST0dSb290PWM6XG15dW5hdHRlblxteXByb2dyb290DQoN ClttdHNfY29yZV0NClBhdGg9YzpcbXl1bmF0dGVuXG15bXR4DQpVU0VSSUQ9bXl1c2VyaWQN ClBBU1NXT1JEPW15cGFzc3dvcmQNCg0KW01zbXFfU2VydmVyXQ0KUGF0aD1jOlxteXVuYXR0 ZW5cbXNtcQ0KU2VydmVyVHlwZT1SUw0KPC9wcmU+DQoNCjxwPjxzdHJvbmc+Tm90ZTwvc3Ry b25nPiZuYnNwOyZuYnNwOyZuYnNwO1ZhbGlkIHNldHRpbmdzIGZvciB0aGUgU2VydmVyVHlw ZSBlbnRyeSBhYm92ZSBpbmNsdWRlOiBQRUMgKHByaW1hcnkgZW50ZXJwcmlzZSBjb250cm9s bGVyLCBQU0MgKHByaW1hcnkgc2l0ZSBjb250cm9sbGVyKSwgQlNDIChiYWNrdXAgc2l0ZSBj b250cm9sbGVyKSwgUlMgKFJvdXRpbmcgU2VydmVyKSwgUkFTIChSZW1vdGUgQWNjZXNzIFNl cnZpY2UpLCBJTkQNCihpbmRlcGVuZGVudCBjbGllbnQpLCBhbmQgREVQIChkZXBlbmRlbnQg Y2xpZW50KS4NCjwvcD4NCg0KPHA+DQpJZiB5b3UgaW5zdGFsbCBhbiBNU01RIGNsaWVudCBv biBhIGNvbXB1dGVyIHJ1bm5pbmcgV2luZG93cyZuYnNwOzk4LCB5b3UNCm11c3QgcmVwbGFj ZSB0aGUgW01zbXFfU2VydmVyXSBzZWN0aW9uIHdpdGggW01zbXFfQ2xpZW50XSwgYW5kIHRo ZSBTZXJ2ZXJUeXBlIGVudHJ5IHdpdGggQ2xpZW50VHlwZS4gQ2xpZW50VHlwZQ0KdmFsdWVz IGluY2x1ZGUgSU5EIChpbmRlcGVuZGVudCBjbGllbnQpIGFuZCBERVAgKGRlcGVuZGVudCBj bGllbnQpLjwvcD4NCg0KPHA+QmUgc3VyZSB0byB0ZXN0IHlvdXIgdW5hdHRlbmRlZCBpbnN0 YWxsYXRpb24gc2NyaXB0IGJlZm9yZSBkZXBsb3ltZW50LiA8L3A+DQoNCjxoMj48YSBuYW1l PSJDcmVhdGluZ2FuTVNNUUluc3RhbGxhdGlvblNoYXJlIj5DcmVhdGluZyBhbiBNU01RIElu c3RhbGxhdGlvbiBTaGFyZTwvYT48L2gyPg0KDQo8cD5Zb3UgY2FuIGNyZWF0ZSBhbiBNU01R IGluc3RhbGxhdGlvbiBzaGFyZSBpZiB5b3Ugd2FudCB0byBwcm92aWRlIHRoZSBhYmlsaXR5 IHRvIGluc3RhbGwgTVNNUSBjbGllbnQgc29mdHdhcmUgZnJvbSBhIHNlcnZlciBjb21wdXRl ci4gVXNlIHRoZSBwcm9jZWR1cmUgZGVzY3JpYmVkIGxhdGVyIGluIHRoaXMgc2VjdGlvbiB0 byBtYW51YWxseSBjcmVhdGUgYW4gTVNNUSBpbnN0YWxsYXRpb24gc2hhcmUuIFlvdSBjYW4g dXNlIGEgdGV4dCBlZGl0b3IsIHN1Y2ggYXMgTWljcm9zb2Z0IE5vdGVwYWQsIHRvIGNyZWF0 ZSB0aGUgbmVjZXNzYXJ5IGZpbGVzLiBZb3Ugc2hvdWxkIGNvcHkgdGhlIGNvbnRlbnRzIG9m IHRoZSBcYWRkLW9uc1xwd3NcIGZvbGRlciBpbiB0aGUgV2luZG93cyZuYnNwOzk4IGNvbXBh Y3QgZGlzYyB0byB5b3VyIHNlcnZlciBjb21wdXRlci48L3A+DQoNCjxwPjxzdHJvbmc+Tm90 ZTwvc3Ryb25nPiZuYnNwOyZuYnNwOyZuYnNwOw0KSWYgeW91IGluc3RhbGwgdGhlIHZlcnNp b24gb2YgTVNNUSBwcm92aWRlZCB3aXRoIFBlcnNvbmFsIFdlYiBTZXJ2ZXIgZm9yIFdpbmRv d3MmbmJzcDs5OCBvdmVyIGEgdmVyc2lvbiBvZiBNU01RIHByb3ZpZGVkDQp3aXRoIFdpbmRv d3MmbmJzcDtOVCBTZXJ2ZXIvRSB0aGF0IGhhcyBhbiBleGlzdGluZyBNU01RIGluc3RhbGxh dGlvbiBzaGFyZSwgdGhlIHNoYXJlZCBmb2xkZXIgaXMgcmVtb3ZlZCBidXQgdGhlIHNoYXJl ZA0KZmlsZXMgYXJlIG5vdC4gWW91IG11c3QgbWFudWFsbHkgZGVsZXRlIHRoZSBzaGFyZWQg ZmlsZXMuIA0KPC9wPg0KDQo8cD5Gb3IgdGhlIGZvbGxvd2luZyBwcm9jZWR1cmUsIHlvdSBj YW4gdXNlIHR3byBjb21wdXRlcnM6IG9uZSB0byBzdG9yZSB0aGUgY29udGVudHMgb2YgdGhl IFxhZGQtb25zXHB3c1wgZm9sZGVyIGluIHRoZSBXaW5kb3dzJm5ic3A7OTggY29tcGFjdCBk aXNjIGFuZCBhbm90aGVyIGNvbXB1dGVyIHRvIHN0b3JlIHRoZSAuYmF0ICBhbmQgLmluaSBm aWxlcyB5b3UgaGF2ZSBjcmVhdGVkLjwvcD4NCg0KPGJpZz5UbyBjcmVhdGUgYW4gTVNNUSBp bnN0YWxsYXRpb24gc2hhcmU8L2JpZz4NCg0KPG9sPg0KPGxpPkNyZWF0ZSBhIG5ldyBzaGFy ZWQgZm9sZGVyIG9uIHlvdXIgc2VydmVyIGhhcmQgZGlzay48L2xpPg0KPGxpPkNyZWF0ZSBh IG5ldyBmaWxlIG5hbWVkIE1xc2V0dXAuYmF0JiM1OTsgY29weSBhbmQgcGFzdGUgdGhlDQpz YW1wbGUgZmlsZSBjb250ZW50cyAoYmVsb3cpIGludG8gdGhlIE1xc2V0dXAuYmF0IGZpbGUg dGhhdCB5b3UgY3JlYXRlZCYjNTk7IGVkaXQgdGhlIG5hbWVzIGFuZCBwYXRocyBhcHByb3By aWF0ZWx5JiM1OTsgYW5kIHNhdmUgdGhlIGZpbGUgdG8gdGhlIGZvbGRlciB5b3UgY3JlYXRl ZCwgc3VjaCBhczo8L2xpPg0KDQo8cHJlPg0KY29weSBcXE15c2VydmVybmFtZVxNeXNldHVw c2hhcmVcU2V0dXBcTXNtcW9wdHAuaW5pICV3aW5kaXIlDQpcXE15c2VydmVybmFtZVxNeXNo YXJlXFNldHVwDQo8L3ByZT4NCg0KPGxpPkNyZWF0ZSBhIG5ldyBmaWxlIG5hbWVkIE1zbXFv cHRwLmluaSwgY29weSBhbmQgcGFzdGUgdGhlDQpzYW1wbGUgZmlsZSBjb250ZW50cyBiZWxv dyBpbnRvIHRoZSBNc21xb3B0cC5pbmkgZmlsZSB0aGF0IHlvdSBjcmVhdGVkLCBlZGl0IHRo ZSBuYW1lIHNldHRpbmcgYXBwcm9wcmlhdGVseSwgYW5kIHNhdmUgdGhlIGZpbGUgdG8gdGhl IGZvbGRlciB5b3UgaGF2ZSBjcmVhdGVkOjwvbGk+DQoNCjxwcmU+DQpbQ29tbW9uIFBhcmFt ZXRlcnNdDQpDb250cm9sbGVyU2VydmVyPW15c2VydmVybmFtZQ0KU3VwcG9ydGluZ1NlcnZl cj1teXNlcnZlcm5hbWUNClNlcnZlckF1dGhlbnRpY2F0aW9uT25seT1UcnVlDQo8L3ByZT4N Cjwvb2w+DQoNCjxwIGNsYXNzPSJub3RlIj48c3Ryb25nPjxzcGFuIHN0eWxlPSJjb2xvcjog IzAwMDBGRiI+PGZvbnQgY29sb3I9IiMwMDAwRkYiPg0KSW1wb3J0YW50PC9mb250Pjwvc3Bh bj48L3N0cm9uZz4mbmJzcDsmbmJzcDsmbmJzcDtZb3UgbXVzdCB1c2UgdGhlIGZpbGUgbmFt ZSBNc21xb3B0cC5pbmkuPC9wPg0KDQo8cD5BIGNsaWVudCBjb21wdXRlciBjYW4gZG93bmxv YWQgYW5kIGluc3RhbGwgTVNNUSBjbGllbnQgc29mdHdhcmUgYnkgY29ubmVjdGluZyB0byB0 aGUgc2hhcmVkIA0KcHVibGljIGZvbGRlciwgcnVubmluZyA8c3Ryb25nPk1xc2V0dXAuYmF0 PC9zdHJvbmc+LCBhbmQgZm9sbG93aW5nIHRoZSBvbi1zY3JlZW4gaW5zdHJ1Y3Rpb25zLjwv cD4NCg0KPGgyPjxhIG5hbWU9Ikluc3RhbGxpbmdNU01Rb25hQ2x1c3RlciI+SW5zdGFsbGlu ZyBNU01RIG9uIGEgQ2x1c3RlcjwvYT48L2gyPg0KDQo8cD5Zb3UgY2FuIHVwZ3JhZGUgYW55 IGV4aXN0aW5nIHZlcnNpb24gb2YgTVNNUSBvbiBhIGNvbXB1dGVyIHRoYXQgaXMgcnVubmlu ZyBNaWNyb3NvZnQgQ2x1c3RlciBTZXJ2ZXIgKE1TQ1MpDQp3aXRoIHRoZSB2ZXJzaW9uIG9m IE1TTVEgcHJvdmlkZWQgd2l0aCBQZXJzb25hbCBXZWIgU2VydmVyIGZvciBXaW5kb3dzJm5i c3A7OTguPC9wPg0KDQo8cD5Ib3dldmVyLCBvbiBhIGNvbXB1dGVyIHJ1bm5pbmcgTVNDUywg eW91IGNhbiBpbnN0YWxsIGEgTVNNUSBSb3V0aW5nIHNlcnZlciwgSW5kZXBlbmRlbnQgY2xp ZW50LA0Kb3IgRGVwZW5kZW50IGNsaWVudCBvbmx5IHdpdGggdGhlIHZlcnNpb24gb2YgTVNN USBwcm92aWRlZCB3aXRoIFBlcnNvbmFsIFdlYiBTZXJ2ZXIgZm9yIFdpbmRvd3MmbmJzcDs5 OC4gDQpUbyBpbnN0YWxsIGEgUEVDLCBQU0MsIG9yIEJTQyBvbiBhIGNsdXN0ZXIsIHlvdSBt dXN0IGZpcnN0IGluc3RhbGwgdGhlIHZlcnNpb24gb2YgTVNNUSBwcm92aWRlZCB3aXRoIFdp bmRvd3MmbmJzcDtOVA0KU2VydmVyL0UgYmVmb3JlIHlvdSBjYW4gdXBncmFkZSBhbmQgaW5z dGFsbCB0aGVzZSBzZXJ2ZXIgdHlwZXMgd2l0aCB0aGUgdmVyc2lvbiBvZiBNU01RIHByb3Zp ZGVkIHdpdGggUGVyc29uYWwgV2ViIFNlcnZlciBmb3IgDQpXaW5kb3dzJm5ic3A7OTguPC9w Pg0KDQo8cD5Zb3UgY2FuIGluc3RhbGwgTVNNUSBvbiBvbmUgY29tcHV0ZXIgKG5vZGUpIG9m IHRoZSBjbHVzdGVyLCBhbmQgdGhlbiBpbnN0YWxsIE1TTVEgb24gdGhlDQpzZWNvbmQgY29t cHV0ZXIgKG5vZGUpIG9mIHRoZSBjbHVzdGVyLiBUaGUgY2x1c3RlciB3aWxsIGNvbnRpbnVl IHRvIG9wZXJhdGUgZXZlbiB3aGVuIG9uZSBjb21wdXRlcg0KaW4gdGhlIGNsdXN0ZXIgaGFz IGJlZW4gdXBncmFkZWQgYW5kIHRoZSBvdGhlciBjb21wdXRlciBoYXMgbm90LiBUbyBpbnN0 YWxsIE1TTVEgb24gdGhlIHNlY29uZCBub2RlIG9mIGENCmNsdXN0ZXIsIHlvdSBtdXN0IGZp cnN0IGluc3RhbGwgSW50ZXJuZXQgSW5mb3JtYXRpb24gU2VydmVyIChJSVMpIGFuZCBNaWNy b3NvZnQgVHJhbnNhY3Rpb24gU2VydmVyIChNVFMpIGZyb20gdGhlIFdpbmRvd3MNCk5UIE9w dGlvbiBQYWNrJiM1OTsgeW91IGNhbiB0aGVuIGluc3RhbGwgTVNNUSBmcm9tIHRoZSBXaW5k b3dzJm5ic3A7OTggQ0QuPC9wPg0KDQo8aDI+TVNNUSBTZXR1cDogU2VydmVyIEF1dGhlbnRp Y2F0aW9uPC9oMj4NCg0KPHA+V2hlbiBzcGVjaWZ5aW5nIHRoZSBuYW1lIG9mIHRoZSBNU01R IHNlcnZlciBkdXJpbmcgTVNNUSBzZXR1cCwgeW91IGNhbiBzcGVjaWZ5IHdoZXRoZXIgb3Ig bm90IHlvdSB3YW50IHRvIHVzZSBhIHNlY3VyZWQNCmNvbm5lY3Rpb24uIElmIHlvdSBjaG9v c2UgdG8gdXNlIGEgc2VjdXJlZCBjb25uZWN0aW9uLCBhbmQgdGhlIE1TTVEgc2VydmVyIGRv ZXMgbm90IGhhdmUgYSB0cnVzdGVkIHNlcnZlcg0KY2VydGlmaWNhdGUsIHRoZSBmb2xsb3dp bmcgd2FybmluZyBtZXNzYWdlIGNhbiBhcHBlYXIgd2hlbiB5b3UgaW5zdGFsbCBhbiBNU01R IHNlcnZlciBvciANCmluZGVwZW5kZW50IGNsaWVudDo8L3A+DQoNCjxwPiZxdW90OzxzdHJv bmc+Tm8gU2VydmVyIEF1dGhlbnRpY2F0aW9uPC9zdHJvbmc+LiBTZXR1cCBjYW5ub3QgaW5p dGlhdGUgYSBzZWN1cmVkIGNvbW11bmljYXRpb25zIGNoYW5uZWwgd2l0aCB0aGUNCk1TTVEg c2VydmVyLiBFaXRoZXIgdGhlIHNlcnZlciBvciB0aGUgY29tcHV0ZXIgb24gd2hpY2ggeW91 IGFyZSBpbnN0YWxsaW5nIA0KTVNNUSBpcyBub3QgY29uZmlndXJlZCBmb3Igc2VjdXJlIGNv bW11bmljYXRpb24sIG9yIHRoZXJlIGlzIGFuIHVuYXV0aG9yaXplZCANCnNlcnZlciBvbiB5 b3VyIE1TTVEgbmV0d29yay4gQXMgYSByZXN1bHQsIGFsbCBmdXJ0aGVyIGNvbW11bmljYXRp b25zIHdpdGggdGhpcyANCnNlcnZlciBhbmQgb3RoZXIgc2VydmVycyB3aWxsIG5vdCBiZSBz ZWN1cmUgdW50aWwgdGhlIHNlcnZlcnMgYW5kIHRoZSBjb21wdXRlciBvbiANCndoaWNoIHlv dSBhcmUgaW5zdGFsbGluZyBNU01RIGFyZSBwcm9wZXJseSBjb25maWd1cmVkLjwvcD4NCg0K PHA+Rm9yIG1vcmUgaW5mb3JtYXRpb24sIGNvbnRhY3QgeW91ciBNU01RIGFkbWluaXN0cmF0 b3Igb3Igc2VlICZxdW90O1NlY3VyaW5nIA0KQ29tbXVuaWNhdGlvbiBCZXR3ZWVuIENvbnRy b2xsZXIgU2VydmVycyZxdW90OyBpbiB0aGUgTVNNUSBSZWxlYXNlIE5vdGVzLi4uJnF1b3Q7 PC9wPg0KDQo8cD5Zb3UgY2FuIGNvbnRyb2wgaG93IHVuYXR0ZW5kZWQgTVNNUSBTZXR1cCBk ZWFscyB3aXRoIHRoaXMgd2FybmluZyB1c2luZyB0aGUgDQpTZXJ2ZXJBdXRoZW50aWNhdGlv bk9ubHkgZW50cnkgaW4gdGhlIE1zbXFvcHRwLmluaSBmaWxlIChkaXNjdXNzZWQgaW4gYSBw cmV2aW91cyBzZWN0aW9uKS4NCklmIFNlcnZlckF1dGhlbnRpY2F0aW9uT25seT1UcnVlLCB1 bmF0dGVuZGVkIE1TTVEgU2V0dXAgd2lsbCBleGl0IGlmIGl0IGNhbm5vdCANCmluaXRpYXRl IGEgc2VjdXJlZCBjb21tdW5pY2F0aW9ucyBjaGFubmVsIHdpdGggdGhlIE1RSVMgc2VydmVy LCBhbmQgYXR0ZW5kZWQgU2V0dXAgDQp3aWxsIHNob3cgdGhlIGFib3ZlIHdhcm5pbmcuIDwv cD4NCg0KPHA+SWYgU2VydmVyQXV0aGVudGljYXRpb25Pbmx5PUZhbHNlLCBNU01RIFNldHVw IA0Kd2lsbCBjb250aW51ZSBldmVuIGlmIGl0IGNhbm5vdCBpbml0aWF0ZSBhIHNlY3VyZWQg Y29tbXVuaWNhdGlvbnMgY2hhbm5lbCB3aXRoIHRoZSANCk1RSVMgc2VydmVyLiBJZiBTZXR1 cCBjYW5ub3QgZmluZCB0aGUgU2VydmVyQXV0aGVudGljYXRpb25Pbmx5IGVudHJ5IGluIHRo ZSANCk1zbXFvcHRwLmluaSBmaWxlLCBTZXR1cCBmdW5jdGlvbnMgYXMgaWYgU2VydmVyQXV0 aGVudGljYXRpb25Pbmx5IGlzIHNldCB0byBUcnVlLjwvcD4NCg0KPHA+Rm9yIG1vcmUgaW5m b3JtYXRpb24gb24gY29uZmlndXJpbmcgc2VydmVycyBmb3Igc2VjdXJlIGNvbW11bmljYXRp b24gZWl0aGVyIGJlZm9yZSANCm9yIGFmdGVyIGluc3RhbGxpbmcgTVNNUSwgc2VlICZxdW90 O1NlY3VyaW5nIENvbnRyb2xsZXIgU2VydmVyIENvbW11bmljYXRpb25zJnF1b3Q7IGluIA0K JnF1b3Q7TWFuYWdpbmcgWW91ciBNU01RIEVudGVycHJpc2UsJnF1b3Q7IGluIHRoZSBNU01R IDxlbT5BZG1pbmlzdHJhdG9yJ3MgDQpHdWlkZTwvZW0+LiBGb3IgZ2VuZXJhbCBpbmZvcm1h dGlvbiBvbiBzZWN1cmluZyBjb250cm9sbGVyIHNlcnZlciBjb21tdW5pY2F0aW9uLCBzZWUg DQomcXVvdDtTZWN1cmluZyBDb21tdW5pY2F0aW9uIHdpdGggQ29udHJvbGxlciBTZXJ2ZXJz JnF1b3Q7IGluICZxdW90O1NlY3VyaW5nIFlvdXIgDQpNU01RIEVudGVycHJpc2UuJnF1b3Q7 IDwvcD4NCg0KPGgyPlN1cHBvcnRlZCBQbGF0Zm9ybXMgYW5kIENvbmZpZ3VyYXRpb25zPC9o Mj4NCg0KPHA+QWxsIGNvbXB1dGVycyBydW5uaW5nIFdpbmRvd3MgOTggbXVzdCBoYXZlIHRo ZSBuZXR3b3JrIGFjY2VzcyBjb250cm9sIHNldCB0byA8c3Ryb25nPlVzZXIgDQpMZXZlbCBB Y2Nlc3MgQ29udHJvbDwvc3Ryb25nPi4gWW91IGNhbiB2ZXJpZnkgdGhpcyBpbiBDb250cm9s IFBhbmVsIHdpdGggPHN0cm9uZz5OZXR3b3JrPC9zdHJvbmc+LCBvbiB0aGUgDQo8c3Ryb25n PkFjY2VzcyBDb250cm9sPC9zdHJvbmc+IHRhYi48L3A+DQoNCjxwPlRoZXNlIGlzc3VlcyBh cmUgY292ZXJlZCBpbiAmcXVvdDtJbnN0YWxsaW5nIE1TTVEsJnF1b3Q7IGluIHRoZSBNU01R IA0KPGVtPkFkbWluaXN0cmF0b3IncyBHdWlkZTwvZW0+LjxwPg0KDQoNCjxoMj5NUUlTIFNl cnZlciBBZG1pbmlzdHJhdG9ycyBIYXZlIFdpZGUtUmFuZ2luZyBBY2Nlc3M8L2gyPg0KDQo8 cD5NYWtlIHN1cmUgYWxsIHlvdXIgTVFJUyBhZG1pbmlzdHJhdG9ycyBjYW4gYmUgdHJ1c3Rl ZCB0byBhcHByb3ByaWF0ZWx5IGFjY2VzcyANCmluZm9ybWF0aW9uIG9uIGFsbCBNUUlTIHNl cnZlcnMuIFdpdGggYWRtaW5pc3RyYXRpdmUgYWNjZXNzIHRvIGp1c3Qgb25lIE1RSVMgc2Vy dmVyLCANCmFuIGFkbWluaXN0cmF0b3IgY2FuIHBvdGVudGlhbGx5IG9idGFpbiBmdWxsIGFj Y2VzcyB0byBhbnkgb2JqZWN0IGluIHRoZSBNU01RIA0KZW50ZXJwcmlzZS4gVGhpcyBjYW4g YmUgZG9uZSBmb3IgZXhhbXBsZSwgYnkgdGFraW5nIG93bmVyc2hpcCBvbiB0aGUgb2JqZWN0 IGFuZCB0aGVuIA0KY2hhbmdpbmcgaXRzIGFjY2VzcyBwZXJtaXNzaW9ucy48L3A+DQoNCjxo Mj5NU01RIGFuZCBXaW5kb3dzJm5ic3A7TlQgU2VydmVyIENBTHM8L2gyPg0KDQo8cD5NU01R IGNvdW50cyBXaW5kb3dzJm5ic3A7TlQgU2VydmVyIGNsaWVudCBhY2Nlc3MgbGljZW5zZXMg KENBTHMpLiBJZiBubyBDQUxzIGFyZSANCmF2YWlsYWJsZSwgTVNNUS1iYXNlZCBhcHBsaWNh dGlvbnMgZmFpbCB0bzogc2VuZCBtZXNzYWdlcywgb3BlbiBxdWV1ZXMgb24gcmVtb3RlIA0K Y29tcHV0ZXJzLCBhbmQgb3BlbiBxdWV1ZXMgZnJvbSBjbGllbnRzLiBNU01RIGVuZm9yY2Vz IHRoZSBmb2xsb3dpbmcgcnVsZXMgZm9yIA0KY291bnRpbmcgQ0FMczo8L3A+DQoNCjx1bD4N CjxsaT5BbGwgTVNNUSBzZXNzaW9ucywgcmVtb3RlLXJlYWQgc2Vzc2lvbnMsIGFuZCBxdWV1 ZXMgb3BlbmVkIGJ5IGRlcGVuZGVudCANCmNsaWVudHMgYXJlIGNvdW50ZWQuPC9saT4NCjxs aT5BbGwgaXRlbXMgdXNlZCBieSBhIHNpbmdsZSBjb21wdXRlciBhcmUgY291bnRlZCBvbmx5 IG9uY2UuIEZvciBleGFtcGxlLCBpZiBhIA0KY29tcHV0ZXIgcnVubmluZyBXaW5kb3dzJm5i c3A7TlQgV29ya3N0YXRpb24gb3IgV2luZG93cyA5OCBoYXMgYW4gTVNNUSBzZXNzaW9uIA0K YW5kIGEgcmVtb3RlLXJlYWQgc2Vzc2lvbiB3aXRoIGEgY29tcHV0ZXIgcnVubmluZyBXaW5k b3dzJm5ic3A7TlQgU2VydmVyLCB0aGUgDQpzZXJ2ZXIgY291bnRzIHRoZXNlIGFzIG9uZSBD QUwuPC9saT4NCjxsaT5BbiBpbmRlcGVuZGVudCBjbGllbnQgY29tcHV0ZXIgcnVubmluZyBX aW5kb3dzJm5ic3A7TlQgV29ya3N0YXRpb24gb3IgV2luZG93cyA5OCBjYW4gaGF2ZSBubyBt b3JlIA0KdGhhbiAxMCBjb25jdXJyZW50IHNlc3Npb25zIChNU01RIGFuZCByZW1vdGUtcmVh ZCBjb21iaW5lZCkgd2l0aCBvdGhlciANCmluZGVwZW5kZW50IGNsaWVudCBjb21wdXRlcnMg cnVubmluZyBXaW5kb3dzJm5ic3A7TlQgV29ya3N0YXRpb24gb3IgV2luZG93cyA5OC48L2xp Pg0KPGxpPkNvbXB1dGVycyBydW5uaW5nIFdpbmRvd3MmbmJzcDtOVCBXb3Jrc3RhdGlvbiBv ciBXaW5kb3dzJm5ic3A7OTggZG8gbm90IGNvdW50IA0Kc2Vzc2lvbnMgd2l0aCBjb21wdXRl cnMgcnVubmluZyBXaW5kb3dzJm5ic3A7TlQgU2VydmVyLCBhbHRob3VnaCBzZXJ2ZXJzIGNv dW50IA0Kc2Vzc2lvbnMgd2l0aCBjb21wdXRlcnMgcnVubmluZyBXaW5kb3dzJm5ic3A7TlQg V29ya3N0YXRpb24gb3IgV2luZG93cyA5OC48L2xpPg0KPGxpPkEgZGVwZW5kZW50IGNsaWVu dCBjb21wdXRlciBkb2VzIG5vdCBjb3VudCBDQUxzLCBidXQgaXRzIGhvc3Rpbmcgc2VydmVy IGNvbXB1dGVyIGNvdW50cyBhbnkgc2Vzc2lvbnMgb3BlbmVkIG9uIHRoZSBkZXBlbmRlbnQg Y2xpZW50J3MgYmVoYWxmLiBUaGUgbnVtYmVyIG9mIGRlcGVuZGVudCBjbGllbnRzIHRoYXQg YXJlIHN1cHBvcnRlZCBpcyBsaW1pdGVkIGJ5IHRoZSBudW1iZXIgb2YgQ0FMcywgYnV0IGNh bm5vdCBiZSBncmVhdGVyIHRoYW4gMjUgZGVwZW5kZW50IGNsaWVudHMuIEFsc28gY291bnRl ZCBhcyBhIENBTCBpcyBpZiBhIGRlcGVuZGVudCBjbGllbnQgY29tcHV0ZXIgb3BlbnMgYSBx dWV1ZSBvbiB0aGUgc2VydmVyIGNvbXB1dGVyLjwvbGk+DQo8L3VsPg0KDQo8cCBjbGFzcz0i bm90ZSI+PHN0cm9uZz48c3BhbiBzdHlsZT0iY29sb3I6ICMwMDAwRkYiPjxmb250IGNvbG9y PSIjMDAwMEZGIj4NCkltcG9ydGFudDwvZm9udD48L3NwYW4+PC9zdHJvbmc+Jm5ic3A7Jm5i c3A7Jm5ic3A7TVNNUS1iYXNlZCBhcHBsaWNhdGlvbnMgdGVuZCB0byBjb21tdW5pY2F0ZSB3 aXRoIGEgbGFyZ2VyIG51bWJlciBvZiBzZXJ2ZXJzIHRoYW4gdHJhZGl0aW9uYWwgbmV0d29y ay1iYXNlZCBhcHBsaWNhdGlvbnMgZG8uIEZvciB0aGlzIHJlYXNvbiwgcGVyIHNlYXQgbGlj ZW5zaW5nIG1heSBiZSBtb3JlIGNvc3QgZWZmZWN0aXZlIGZvciB5b3VyIGVudGVycHJpc2Uu PC9wPg0KDQo8cD5Gb3IgbW9yZSBpbmZvcm1hdGlvbiBvbiBDQUxzIGFuZCBjaGFuZ2luZyBD QUxzLCBzZWUgJnF1b3Q7TGljZW5zaW5nIGFuZCANCkxpY2Vuc2UgTWFuYWdlciwmcXVvdDsg aW4gPGVtPldpbmRvd3MmbmJzcDtOVCBTZXJ2ZXIgNC4wIENvbmNlcHRzIGFuZCBQbGFubmlu ZzwvZW0+LjwvcD4NCg0KPGgyPk1TTVEgYW5kIFNRTCBTZXJ2ZXIgU2VydmljZSBQYWNrczwv aDI+DQoNCg0KPHA+TVNNUSByZXF1aXJlcyB0aGUgdXNlIG9mIE1pY3Jvc29mdCBTUUwgU2Vy dmVyIDYuNSBTZXJ2aWNlIFBhY2sgMSBvciBTZXJ2aWNlIFBhY2sgDQozLiBNU01RIGlzIG5v dCBjb21wYXRpYmxlIHdpdGggTWljcm9zb2Z0IFNRTCBTZXJ2ZXIgNi41IFNlcnZpY2UgUGFj ayAyLjwvcD4NCg0KPGgyPlNlY3VyaW5nIENvbW11bmljYXRpb24gQmV0d2VlbiBDb250cm9s bGVyIFNlcnZlcnM8L2gyPg0KDQo8cD4mcXVvdDtTZWN1cmluZyBZb3VyIE1TTVEgRW50ZXJw cmlzZSwmcXVvdDsNCmluICZxdW90O1NlY3VyaW5nIENvbW11bmljYXRpb24gd2l0aCBDb250 cm9sbGVyIFNlcnZlcnMmcXVvdDssIGluIHRoZSBNU01RIDxlbT5BZG1pbmlzdHJhdG9yknMg R3VpZGU8L2VtPiwgc3RhdGVzOjwvcD4NCjxibG9ja3F1b3RlPg0KJnF1b3Q7Q29tbXVuaWNh dGlvbiBiZXR3ZWVuIE1TTVEgY29udHJvbGxlciBzZXJ2ZXJzIGlzIGluaGVyZW50bHkgc2Vj dXJlIGJlY2F1c2UgDQphbGwgdGhlIG1lc3NhZ2VzIGFyZSBzaWduZWQgYW5kIHZlcmlmaWVk LCBiYXNlZCBvbiBpbmZvcm1hdGlvbiBmb3VuZCBpbiB0aGUgTVFJUyANCmRhdGFiYXNlLiZx dW90Ow0KPC9ibG9ja3F1b3RlPg0KDQo8cD5BbHRob3VnaCB0aGlzIGlzIHRydWUsIGl0IGRv ZXMgbm90IGV4cGxhaW4gdGhhdCBieSBkZWZhdWx0IHRoZSBpbml0aWFsIGNvbW11bmljYXRp b25zIGFyZSBub3Qgc2VjdXJlIGJldHdlZW4gdGhlIE1RSVMgc2VydmVyIHlvdSBhcmUgaW5z dGFsbGluZyBhbmQgaXRzICZxdW90O3BhcmVudCZxdW90OyBNUUlTIHNlcnZlciAodGhlIFBF QyBpbiBjYXNlIG9mIGEgUFNDOyB0aGUgIFBTQyBpbiBjYXNlIG9mIGEgQlNDKS4gVGhpcyBp bml0aWFsIGNvbW11bmljYXRpb24gKGRvbmUgdGhyb3VnaCByZW1vdGUgcHJvY2VkdXJlIGNh bGwgKFJQQykpIGlzIG5vdCBzZWN1cmUgdW5sZXNzIHlvdSBjb25maWd1cmUgdGhlIHNlcnZl ciBmb3Igc2VjdXJlIGNvbW11bmljYXRpb24gYmVmb3JlIGluc3RhbGxpbmcgTVNNUS4gRm9y IGV4YW1wbGUsIHlvdSBjYW4gdW5rbm93aW5nbHkgaW5zdGFsbCB0aGUgTVFJUyBzZXJ2ZXIg ZnJvbSBhbiB1bmF1dGhvcml6ZWQgTVFJUyBzZXJ2ZXIuIEhvd2V2ZXIsIG9uY2UgeW91IGlu c3RhbGwgYW4gTVFJUyBzZXJ2ZXIgZnJvbSBhbiBhdXRoZW50aWMgc2VydmVyLCBhbGwgZnVy dGhlciBjb21tdW5pY2F0aW9ucyB3aXRoIG90aGVyIE1RSVMgc2VydmVycyBhcmUgc2VjdXJl LiBUbyBwcmV2ZW50IHRoZSBpbnN0YWxsYXRpb24gb2YgTVFJUyBzZXJ2ZXJzIGZyb20gb3Ro ZXIgdW5hdXRob3JpemVkIE1RSVMgc2VydmVycywgY29uZmlndXJlIHRoZSBzZXJ2ZXJzIGZv ciBzZWN1cmUgY29tbXVuaWNhdGlvbiBiZWZvcmUgaW5zdGFsbGluZyBNU01RIG9uIHRoZW0u IDwvcD4NCiANCjxwPjxzdHJvbmc+Tm90ZTwvc3Ryb25nPiZuYnNwOyZuYnNwOyZuYnNwO0Nv bmZpZ3VyaW5nIE1RSVMgc2VydmVycyBmb3Igc2VjdXJlIGNvbW11bmljYXRpb24gKGV2ZW4g dGhvdWdoIGNvbW11bmljYXRpb24gYmV0d2VlbiBNU01RIGNvbnRyb2xsZXIgc2VydmVycyBp cyBpbmhlcmVudGx5IHNlY3VyZSkgY2FuIGFsc28gc2ltcGxpZnkgdGhlIHJlbmV3YWwgb2Yg Y3J5cHRvZ3JhcGhpYyBrZXlzLiBGb3IgZXhhbXBsZSwgaWYgeW91IHJlbmV3IHRoZSBjcnlw dG9ncmFwaGljIGtleXMgb2YgYW4gTVFJUyBzZXJ2ZXIgdGhhdCBoYXMgYmVlbiBjb25maWd1 cmVkIGZvciBzZWN1cmUgY29tbXVuaWNhdGlvbiwgdGhlIGNoaWxkIHNlcnZlciBjYW4gYXV0 b21hdGljYWxseSBvYnRhaW4gdGhlIG5ldyBwdWJsaWMga2V5cy4gSG93ZXZlciwgaWYgdGhl IHBhcmVudCBNUUlTIHNlcnZlciBpcyBub3QgY29uZmlndXJlZCBmb3Igc2VjdXJlIGNvbW11 bmljYXRpb24sIHlvdSBtdXN0IG1hbnVhbGx5IG1ha2UgY2hhbmdlcyB0byBhbGxvdyBNUUlT IHJlcGxpY2F0aW9uIHRvIHJlc3VtZSBiZXR3ZWVuIHRoZSB0d28gc2VydmVycy4NCjwvcD4N Cg0KPHA+Rm9yIG1vcmUgaW5mb3JtYXRpb24gb24gY29uZmlndXJpbmcgc2VydmVycyBmb3Ig c2VjdXJlIGNvbW11bmljYXRpb24gZWl0aGVyIGJlZm9yZSANCm9yIGFmdGVyIGluc3RhbGxp bmcgTVNNUSwgc2VlICZxdW90O1NlY3VyaW5nIENvbnRyb2xsZXIgU2VydmVyIENvbW11bmlj YXRpb25zJnF1b3Q7IGluIA0KJnF1b3Q7TWFuYWdpbmcgWW91ciBNU01RIEVudGVycHJpc2Us JnF1b3Q7IGluIHRoZSBNU01RIDxlbT5BZG1pbmlzdHJhdG9yJ3MgDQpHdWlkZTwvZW0+LiBG b3IgZ2VuZXJhbCBpbmZvcm1hdGlvbiBvbiBzZWN1cmluZyBjb250cm9sbGVyIHNlcnZlciBj b21tdW5pY2F0aW9uLCBzZWUgDQomcXVvdDtTZWN1cmluZyBDb21tdW5pY2F0aW9uIHdpdGgg Q29udHJvbGxlciBTZXJ2ZXJzJnF1b3Q7IGluICZxdW90O1NlY3VyaW5nIFlvdXIgDQpNU01R IEVudGVycHJpc2UuJnF1b3Q7IDwvcD4NCg0KPGgyPlJlbmV3aW5nIENyeXB0b2dyYXBoaWMg S2V5czwvaDI+DQoNCjxwPkFsbCBNU01RIGNvbXB1dGVycyBleGNlcHQgZGVwZW5kZW50IGNs aWVudHMgdXNlIGNyeXB0b2dyYXBoaWMga2V5cy4gVGhlc2UgDQpjcnlwdG9ncmFwaGljIGtl eXMgYXJlIHVzZWQgZm9yIHZhcmlvdXMgc2VjdXJpdHkgb3BlcmF0aW9ucyBpbiBNU01RLiBV c2VycyANCmNhbiByZW5ldyB0aGUgY3J5cHRvZ3JhcGhpYyBrZXlzIHVzaW5nIDxzdHJvbmc+ TVMgTWVzc2FnZSBRdWV1ZTwvc3Ryb25nPiBpbiBDb250cm9sIFBhbmVsLjwvcD4NCg0KPHA+ Rm9yIGluZGVwZW5kZW50IGNsaWVudHMgYW5kIE1TTVEgcm91dGluZyBzZXJ2ZXJzLCB0aGUg b25seSBpbXBsaWNhdGlvbiBvZiByZW5ld2luZyANCnRoZSBjcnlwdG9ncmFwaGljIGtleXMg aXMgdGhhdCBwcml2YXRlIChlbmNyeXB0ZWQpIG1lc3NhZ2VzLCB3aGljaCB3ZXJlIGVuY3J5 cHRlZCANCmFjY29yZGluZyB0byB0aGUgcHJldmlvdXMga2V5cyBhbmQgd2VyZSB0aGVuIHNl bnQgdG8gdGhlIGNvbXB1dGVyLCBhcmUgcmVqZWN0ZWQuIFRoaXMgDQpoYXBwZW5zIHVudGls IHRoZSBuZXcgcHVibGljIGtleXMgYXJlIHByb3BhZ2F0ZWQgdG8gYWxsIE1RSVMgc2VydmVy cyBhbmQgdGhlIA0Kc2VuZGluZyBjb21wdXRlcnMgc3RhcnQgdXNpbmcgdGhlIG5ldyBwdWJs aWMga2V5LjwvcD4NCg0KPHA+SWYgeW91IHJlbmV3IHRoZSBjcnlwdG9ncmFwaGljIGtleXMg Zm9yIGEgUEVDLCB0aGUgZW50ZXJwcmlzZSBQU0NzIHJlamVjdCBhbnkgTVFJUyByZXBsaWNh dGlvbiBtZXNzYWdlcyBzZW50DQpmcm9tIHRoZSBQRUMuIElmIHlvdSByZW5ldyB0aGUgY3J5 cHRvZ3JhcGhpYyBrZXlzIGZvciBhIFBTQywgYWxsIGl0cyBCU0NzIHJlamVjdCBhbnkgTVFJ UyByZXBsaWNhdGlvbiBtZXNzYWdlcyBzZW50IGZyb20gdGhlIFBTQy4gVGhpcyBwcm9ibGVt IG9jY3VycyBvbmx5IGlmIHRoZSBNUUlTIHNlcnZlcnMgYXJlIG5vdCBjb25maWd1cmVkIGZv ciBzZWN1cmUgY29tbXVuaWNhdGlvbi48L3A+DQoNCjxwPklmIHlvdSByZW5ldyB0aGUgY3J5 cHRvZ3JhcGhpYyBrZXlzIG9mIGFuIE1RSVMgc2VydmVyIGFuZCBhbGwgeW91ciBNUUlTIHNl cnZlcnMgYXJlIG5vdCBjb25maWd1cmVkIGZvciBzZWN1cmUgY29tbXVuaWNhdGlvbiwgdXNl IHRoZSBmb2xsb3dpbmcgcHJvY2VkdXJlIHRvIGNvcnJlY3QgdGhlIHByb2JsZW06PC9wPg0K DQo8b2w+DQo8bGk+T24gdGhlIE1RSVMgc2VydmVyIG9uIHdoaWNoIHlvdSBjaGFuZ2UgdGhl IGNyeXB0b2dyYXBoaWMga2V5cywgY2xpY2sgPHN0cm9uZz5TdGFydDwvc3Ryb25nPiwgY2xp Y2sNCjxzdHJvbmc+UnVuPC9zdHJvbmc+LCBhbmQgdGhlbiB0eXBlIDxzdHJvbmc+bXFzcnZr ZXk8L3N0cm9uZz4gPGVtPm5ld2tleS5rZXk8L2VtPiwgd2hlcmUgPGVtPm5ld2tleS5rZXk8 L2VtPiBpcyB0aGUgb3V0cHV0IGZpbGUNCm5hbWUgeW91IHdhbnQgdG8gdXNlLiBUaGUgPHN0 cm9uZz5tcXNydmtleTwvc3Ryb25nPiANCmNvbW1hbmQgbGluZSB1dGlsaXR5IGlzIGluc3Rh bGxlZCBpbiB0aGUgTVNNUSBmb2xkZXIgYnkgZGVmYXVsdCAodHlwaWNhbGx5IA0KQzpcUHJv Z3JhbSBGaWxlc1xNU01RKS48L2xpPg0KPGxpPklmIHlvdSBjaGFuZ2VkIHRoZSBjcnlwdG9n cmFwaGljIGtleXMgb24gYSBQRUMsIGNvcHkgdGhlIGZpbGUgeW91IGNyZWF0ZWQgdG8gZWFj aCBQU0MuIElmIHlvdSBjaGFuZ2VkIHRoZQ0KY3J5cHRvZ3JhcGhpYyBrZXlzIG9uIGEgUFND LCBjb3B5IHRoZSBmaWxlIHlvdSBjcmVhdGVkIHRvIGVhY2ggQlNDLiA8L2xpPg0KPGxpPk9u IGVhY2ggUFNDIG9yIEJTQyB0byB3aGljaCB5b3UgY29waWVkIHRoZSBmaWxlLCBydW4gPHN0 cm9uZz5tcXNydmtleTwvc3Ryb25nPiBhbmQgc3BlY2lmeSB0aGUgbmFtZSBvZiB0aGUNCmZp bGUgeW91IGNvcGllZC48L2xpPg0KPC9vbD4NCg0KPGgyPkRlcGVuZGVudCBDbGllbnRzIERv IE5vdCBVc2UgU2VjdXJlIENvbW11bmljYXRpb24gd2l0aCBNUUlTIFNlcnZlcnMsIGJ5IERl ZmF1bHQ8L2gyPg0KDQo8cD5JZiB5b3Ugd2FudCB5b3VyIE1TTVEgZGVwZW5kZW50IGNsaWVu dHMgdG8gdXNlIHNlY3VyZSBjb21tdW5pY2F0aW9uIHdpdGggTVFJUyANCnNlcnZlcnMsIHlv dSBtdXN0IG92ZXJyaWRlIHRoZSBkZWZhdWx0IHNldHRpbmcsIHdoaWNoIGRvZXMgbm90IHVz ZSBzZWN1cmUgDQpjb21tdW5pY2F0aW9uIGJldHdlZW4gdGhlc2UgY29tcHV0ZXJzLjwvcD4N Cg0KPGJpZz5UbyBjb25maWd1cmUgZGVwZW5kZW50IGNsaWVudHMgdG8gdXNlIHNlY3VyZSBj b21tdW5pY2F0aW9uIHdpdGggTVFJUyBzZXJ2ZXJzPC9iaWc+DQo8b2w+DQo8bGk+SW4gQ29u dHJvbCBQYW5lbCwgZG91YmxlLWNsaWNrIDxzdHJvbmc+TVMgTWVzc2FnZSBRdWV1ZTwvc3Ry b25nPi4NCjxsaT5PbiB0aGUgPHN0cm9uZz5TZWN1cml0eTwvc3Ryb25nPiB0YWIsIHNlbGVj dCB0aGUgPHN0cm9uZz5Vc2Ugb25seSBzZWN1cmVkIGNvbm5lY3Rpb25zIHdoZW4gY29tbXVu aWNhdGluZyANCndpdGggYW4gTVNNUSBjb250cm9sbGVyIHNlcnZlcjwvc3Ryb25nPiBjaGVj ayBib3guDQo8L29sPg0KDQo8aDI+TWVzc2FnZXMgYXJlIFNlbnQgYXMgUGxhaW4gVGV4dCB3 aGVuIFJlYWQgUmVtb3RlbHk8L2gyPg0KDQo8cD5UaGUgTVNNUSBTZWN1cml0eSBmZWF0dXJl IGd1YXJhbnRlZXMgZnVsbCBzZWN1cml0eSBvZiAgbWVzc2FnZXMgZnJvbSB0aGUgc2VuZGlu ZyANCmFwcGxpY2F0aW9uIHRvIHRoZSBkZXN0aW5hdGlvbiBxdWV1ZS4gVG8gZ3VhcmFudGVl IGZ1bGwgc2VjdXJpdHksIHRoZSByZWNlaXZpbmcgDQphcHBsaWNhdGlvbiBhbmQgdGhlIHF1 ZXVlIG11c3QgcmVzaWRlIG9uIHRoZSBzYW1lIGNvbXB1dGVyIChsb2NhbCByZWFkKS4gPC9w Pg0KDQo8cD5JbiB0aGUgY2FzZSBvZiBhIHJlbW90ZSByZWFkIChzdWNoIGFzIHJlYWRpbmcg YSBtZXNzYWdlIGZyb20gY29tcHV0ZXIgQSB3aGVuIHRoZSANCnF1ZXVlIGlzIG9uIGNvbXB1 dGVyIEIpLCBvbmx5IGF1dGhvcml6ZWQgdXNlcnMgYXJlIGFibGUgdG8gb3BlbiBhIHF1ZXVl IGZvciByZWFkLiBUaGF0IA0KaXMsIHRoZSB1c2VyIG11c3QgaGF2ZSB0aGUgcmlnaHQgYWNj ZXNzIHBlcm1pc3Npb25zIGZvciB0aGUgcXVldWUuIEhvd2V2ZXIsIHRoZSANCm1lc3NhZ2Ug aXMgbm90IGVuY3J5cHRlZCBvciBhdXRoZW50aWNhdGVkIHdoZW4gcmVhZCBieSB0aGUgcmVj ZWl2aW5nIGFwcGxpY2F0aW9uIG92ZXIgDQp0aGUgbmV0d29yay48L3A+DQoNCjxoMz5Ib3cg dG8gRW5hYmxlIE1lc3NhZ2UgSW50ZWdyaXR5IGFuZCBBdXRoZW50aWNhdGlvbiBXaGVuIFJl YWRpbmcgUmVtb3RlbHk8L2gzPg0KDQo8cD5NZXNzYWdlIGFyZSBub3QgZW5jcnlwdGVkIG9y IGF1dGhlbnRpY2F0ZWQgd2hlbiByZWFkIHJlbW90ZWx5IGJ5IHRoZSByZWNlaXZpbmcgYXBw bGljYXRpb24uIFRvIGVuc3VyZSBpbnRlZ3JpdHkgY2hlY2tpbmcgZm9yIGVhY2ggbWVzc2Fn ZSBzZW50IHRvIGEgcmVtb3RlIHJlYWRlciwgdXNlIDxzdHJvbmc+U2VydmljZXM8L3N0cm9u Zz4gaW4gQ29udHJvbCBQYW5lbCB0byBjb25maWd1cmUgdGhlIE1pY3Jvc29mdCBNZXNzYWdl IFF1ZXVlIFNlcnZpY2Ugb2YgdGhlIHJlYWRpbmcgY29tcHV0ZXIgdG8gcnVuIHVuZGVyIGEg ZG9tYWluIHVzZXIgYWNjb3VudCAobm90IHRoZSBsb2NhbCBzeXN0ZW0gYWNjb3VudCkuPC9w Pg0KDQo8aDI+TVFJUyBTZXJ2ZXJzIFJlcXVpcmUgYXQgTGVhc3QgT25lIE5ldHdvcmsgQWRh cHRlcjwvaDI+DQoNCjxwPkVhY2ggTVFJUyBzZXJ2ZXIgKHRoZSBQRUMsIGFsbCBQU0NzLCBh bmQgYWxsIEJTQ3MpIG11c3QgaGF2ZSBhdCBsZWFzdCBvbmUgbmV0d29yayANCmFkYXB0ZXIu IFRoZSBuZXR3b3JrIGFkYXB0ZXIgaXMgcmVxdWlyZWQgZXZlbiBpZiB0aGUgc2VydmVyIGlz IGEgbGFwdG9wIGNvbXB1dGVyIG9yIA0KY29ubmVjdHMgdG8gdGhlIG5ldHdvcmsgb25seSBi eSBtb2RlbSB0aHJvdWdoIFJBUy48L3A+DQoNCjxoMj5JbnN0YWxsaW5nIE1TTVEgRGVwZW5k ZW50IENsaWVudHMgQmVmb3JlIEluc3RhbGxpbmcgVGhlaXIgU3VwcG9ydGluZyBTZXJ2ZXI8 L2gyPg0KDQo8cD5UaGUgTVNNUSA8ZW0+QWRtaW5pc3RyYXRvcidzIEd1aWRlPC9lbT4gc3Rh dGVzIHRoYXQgJnF1b3Q7Ym90aCB0aGUgc3VwcG9ydGluZyBzZXJ2ZXIgYW5kIHRoZSBzaXRl IA0KY29udHJvbGxlciBzZXJ2ZXIgKFBTQyBvciBQRUMpIG11c3QgYmUgb25saW5lIHdoZW4g eW91IGluc3RhbGwgYW4gTVNNUSBkZXBlbmRlbnQgDQpjbGllbnQuJnF1b3Q7IEhvd2V2ZXIs IGlmIHRoZSBzdXBwb3J0aW5nIHNlcnZlciBpcyBub3Qgb25saW5lLCBvciBpZiBpdCBoYXMg bm90IHlldCBiZWVuIA0KaW5zdGFsbGVkLCB5b3UgY2FuIHN0aWxsIGluc3RhbGwgdGhlIGNs aWVudC48L3A+DQoNCjxwPlRoZSBNU01RIGRlcGVuZGVudCBjbGllbnQgU2V0dXAgYXR0ZW1w dHMgdG8gY29tbXVuaWNhdGUgd2l0aCB0aGUgc3BlY2lmaWVkIA0Kc3VwcG9ydGluZyBzZXJ2 ZXIuIElmIHRoZSBzZXJ2ZXIgZG9lcyBub3QgcmVzcG9uZCwgU2V0dXAgZGlzcGxheXMgYSBt ZXNzYWdlIHRlbGxpbmcgeW91IA0KdGhhdCB0aGUgc2VydmVyIGlzIG5vdCByZWFjaGFibGUu IFlvdSBjYW4gZWl0aGVyIHNwZWNpZnkgYW5vdGhlciBzZXJ2ZXIgb3IgY2xpY2sgDQo8c3Ry b25nPkNhbmNlbDwvc3Ryb25nPi4gIElmIHlvdSBjbGljayA8c3Ryb25nPkNhbmNlbDwvc3Ry b25nPiwgU2V0dXAgY29tcGxldGVzIHN1Y2Nlc3NmdWxseSwgdXNpbmcgdGhlIHNlcnZlciBu YW1lIHlvdSANCmVudGVyZWQuIFVzaW5nIHRoaXMgZmVhdHVyZSwgeW91IGNhbiBpbnN0YWxs IGRlcGVuZGVudCBjbGllbnRzIGJlZm9yZSB5b3UgaW5zdGFsbCB0aGUgDQpzdXBwb3J0aW5n IHNlcnZlci4gSG93ZXZlciwgeW91IGNhbm5vdCBjb25maWd1cmUgdGhlIE1TIERUQyBzZXJ2 aWNlIG9uIGNvbXB1dGVycyANCnJ1bm5pbmcgV2luZG93cyA5OCB3aGVuIHRoZSBzdXBwb3J0 aW5nIHNlcnZlciBpcyBvZmZsaW5lLjwvcD4NCg0KPHA+Rm9yIG1vcmUgaW5mb3JtYXRpb24g b24gY29uZmlndXJpbmcgY29tcHV0ZXJzIHJ1bm5pbmcgV2luZG93cyA5OCB0byB1c2UgdGhl IA0KTVMgRFRDIHNlcnZpY2UsIHNlZSAmcXVvdDtNU01RIERlcGVuZGVudCBDbGllbnQgQ29u ZmlndXJhdGlvbiBQcm9jZWR1cmUmcXVvdDsgaW4gJnF1b3Q7SW5zdGFsbGluZyBNU01RLCZx dW90Ow0KaW4gdGhlIE1TTVEgPGVtPkFkbWluaXN0cmF0b3KScyBHdWlkZTwvZW0+LjwvcD4N Cg0KPGgyPk1hbmFnaW5nIENlcnRpZmljYXRpb24gQXV0aG9yaXRpZXMgKENBcykgZm9yIE1T TVEgd2hlbiBJRTQgaXMgSW5zdGFsbGVkPC9oMj4NCg0KPHA+TVNNUSB1c2VzIGl0cyBvd24g Y2VydGlmaWNhdGUgc3RvcmUgdG8ga2VlcCBjZXJ0aWZpY2F0aW9uIGF1dGhvcml0aWVzIChD QSkgY2VydGlmaWNhdGVzLiBBdCBpbnN0YWxsYXRpb24gdGltZSwNCk1TTVEgd2lsbCBjb3B5 IHRoZSBsaXN0IG9mIENBcyB0cnVzdGVkIGJ5IE1pY3Jvc29mdCBJbnRlcm5ldCBFeHBsb3Jl ciA0IChJRTQpIGludG8gaXRzIG93biBjZXJ0aWZpY2F0ZSBzdG9yZS48L3A+DQoNCjxiaWc+ VG8gbWFuYWdlIHdoaWNoIENBIGlzIHRydXN0ZWQgYnkgTVNNUTwvYmlnPjxicj4gDQoNCjxv bD4NCjxsaT5JbiBDb250cm9sIFBhbmVsLCBkb3VibGUtY2xpY2sgPHN0cm9uZz5NUyBNZXNz YWdlIFF1ZXVlPC9zdHJvbmc+LCBhbmQgdGhlbiBjbGljayB0aGUNCjxzdHJvbmc+U2VjdXJp dHk8L3N0cm9uZz4gdGFiLjwvbGk+DQo8bGk+VW5kZXIgPHN0cm9uZz5Db250cm9sbGVyIFNl cnZlciBDb21tdW5pY2F0aW9uczwvc3Ryb25nPiwgc2VsZWN0IHRoZSA8c3Ryb25nPlVzZSBv bmx5IHNlY3VyZWQgY29ubmVjdGlvbnMgd2hlbg0KY29tbXVuaWNhdGluZyB3aXRoIGFuIE1T TVEgY29udHJvbGxlciBzZXJ2ZXI8L3N0cm9uZz4gY2hlY2sgYm94LCBhbmQgdGhlbiBjbGlj aw0KPHN0cm9uZz5DZXJ0aWZpY2F0aW9uIEF1dGhvcml0aWVzPC9zdHJvbmc+LjwvbGk+DQo8 bGk+SW4gdGhlIDxzdHJvbmc+Q2VydGlmaWNhdGlvbiBBdXRob3JpdGllczwvc3Ryb25nPnMg ZGlhbG9nIGJveCwgc2VsZWN0IG9yIGNsaWNrIHRvIGNsZWFyIHRoZSBhcHBsaWNhYmxlIGNo ZWNrIGJveGVzLA0KY2xpY2sgPHN0cm9uZz5PSzwvc3Ryb25nPiwgYW5kIHRoZW4gY2xpY2sg PHN0cm9uZz5PSzwvc3Ryb25nPiBhZ2Fpbi48L2xpPg0KPGxpPkluIHRoZSA8c3Ryb25nPk1T TVEgLSBSZXN0YXJ0IFN5c3RlbTwvc3Ryb25nPiBkaWFsb2cgYm94LCBjbGljayA8c3Ryb25n PlJlc3RhcnQgV2luZG93cyBOb3c8L3N0cm9uZz4uPC9saT4NCjwvb2w+DQogIA0KPHA+PHN0 cm9uZz5Ob3RlPC9zdHJvbmc+Jm5ic3A7Jm5ic3A7Jm5ic3A7SWYgeW91IGFkZCBhIG5ldyBD QSBpbnRvIHRoZSBJRTQgY2VydGlmaWNhdGUgc3RvcmUsIGFuZCB5b3Ugd2FudCB0aGUgQ0Eg dG8gYmUgdHJ1c3RlZCBieSBNU01RLCBjbGljaw0KPHN0cm9uZz5TeXN0ZW0gQ2VydGlmaWNh dGVzPC9zdHJvbmc+IHRvIGltcG9ydCBJRTQgY2VydGlmaWNhdGVzIGludG8gdGhlIE1TTVEg c3RvcmUuPC9wPg0KDQo8aDI+RGVsZXRpbmcgVXNlciBDZXJ0aWZpY2F0ZXMgZnJvbSBNU01R IEV4cGxvcmVyPC9oMj4NCg0KPHA+RWFjaCB1c2VyIGNhbiB1c2UgPHN0cm9uZz5NUyBNZXNz YWdlIFF1ZXVlPC9zdHJvbmc+IGluIENvbnRyb2wgUGFuZWwgdG8gZGVsZXRlIG9ubHkgaGVy IG93biANCmNlcnRpZmljYXRlcy4gSG93ZXZlciwgYWRtaW5pc3RyYXRvcnMgY2FuIHVzZSB0 aGUgPHN0cm9uZz5SZW1vdmUgVXNlciBDZXJ0aWZpY2F0ZXM8L3N0cm9uZz4gb3B0aW9uIG9u IHRoZSBNU01RIEV4cGxvcmVyIDxzdHJvbmc+VG9vbHM8L3N0cm9uZz4gbWVudSB0byBkZWxl dGUgb3RoZXIgdXNlciBjZXJ0aWZpY2F0ZXMuIFRvIGRlbGV0ZSBjZXJ0aWZpY2F0ZXMgb2Yg b3RoZXIgdXNlcnMsIHRoZSBhZG1pbmlzdHJhdG9yICBtdXN0IGhhdmUgU2V0IFByb3BlcnRp ZXMgcGVybWlzc2lvbiBmb3IgdGhlIE1TTVEgZW50ZXJwcmlzZS4NCjwvcD4NCg0KDQo8aDI+ TVNNUSBFeHBsb3JlciBGaW5kIE9wdGlvbnM8L2gyPg0KDQo8cD5NU01RIEV4cGxvcmVyIEhl bHAgaW5jb3JyZWN0bHkgc3RhdGVzIHRoYXQgeW91IGNhbiBzZWFyY2ggZm9yIGNvbXB1dGVy cyB1c2luZyB0aGUgDQpmb2xsb3dpbmcgb3B0aW9uczogPHN0cm9uZz5BbGwgVHlwZXM8L3N0 cm9uZz4sIDxzdHJvbmc+TVNNUSByb3V0aW5nIHNlcnZlcnM8L3N0cm9uZz4sIDxzdHJvbmc+ QmFja3VwIHNpdGUgY29udHJvbGxlcnM8L3N0cm9uZz4sIGFuZCANCjxzdHJvbmc+UHJpbWFy eSBzaXRlIGNvbnRyb2xsZXJzPC9zdHJvbmc+LiBUaGUgdmFsaWQgb3B0aW9ucyBhcmU6IDxz dHJvbmc+QWxsIFR5cGVzPC9zdHJvbmc+LCA8c3Ryb25nPk1TTVEgU2VydmVyczwvc3Ryb25n PiwgPHN0cm9uZz5TaXRlIA0KQ29udHJvbGxlcnM8L3N0cm9uZz4sIGFuZCA8c3Ryb25nPlBy aW1hcnkgU2l0ZSBDb250cm9sbGVyczwvc3Ryb25nPi48L3A+DQoNCjxwPjxzdHJvbmc+QWxs IFR5cGVzPC9zdHJvbmc+IHJldHVybnMgYWxsIE1TTVEgY29tcHV0ZXJzLiA8c3Ryb25nPk1T TVEgU2VydmVyczwvc3Ryb25nPiByZXR1cm5zIGFsbCBNU01RIHNlcnZlcnMuIA0KPHN0cm9u Zz5TaXRlIENvbnRyb2xsZXJzPC9zdHJvbmc+IHJldHVybnMgYWxsIEJTQ3MsIFBTQ3MsIGFu ZCB0aGUgUEVDLiA8c3Ryb25nPlByaW1hcnkgU2l0ZSBDb250cm9sbGVyczwvc3Ryb25nPiBy ZXR1cm5zIGFsbCBQU0NzIGFuZCB0aGUgUEVDLjwvcD4NCg0KPGgyPk1lc3NhZ2luZyBQcm9i bGVtcyB3aXRoIE11bHRpaG9tZWQsIEluZGVwZW5kZW50IENsaWVudHM8L2gyPg0KDQo8cD5E byBub3QgdXNlIGFueSBtdWx0aWhvbWVkLCBNU01RIGluZGVwZW5kZW50IGNsaWVudCB3aXRo IHR3byBuZXR3b3JrIGNhcmRzIG9uIHR3byANCmRpZmZlcmVudCBJUCBDTnMgaWYgdGhlcmUg aXMgYW4gTVNNUSBzZXJ2ZXIgd2l0aCB0d28gbmV0d29yayBjYXJkcyBvbiB0aGUgc2FtZSB0 d28gDQpJUCBDTnMgaW4gdGhlIHNhbWUgc2l0ZS4gT3RoZXJ3aXNlLCB0aGUgTVNNUSBpbmRl cGVuZGVudCBjbGllbnQgbWF5IGZhaWwgdG8gc2VuZCBvciANCnJlY2VpdmUgbWVzc2FnZXMu PC9wPg0KDQo8aDI+U2VuZGluZyB0byBRdWV1ZXMgd2l0aCBSZXN0cmljdGVkIFNlbmQgQWNj ZXNzPC9oMj4NCg0KPHA+VmlzdWFsIEJhc2ljJnJlZzsgc2NyaXB0cyB1bmRlciBBY3RpdmUg U2VydmVyIFBhZ2VzIChBU1ApIHJ1biB1bmRlciB0aGUgc2VjdXJpdHkgb2YgdGhlIA0KYWNj b3VudCBydW5uaW5nIHRoZSBJSVMgc2VydmljZSAodzNzdmMpLiBJZiB0aGF0IGFjY291bnQg aXMgYSBsb2NhbCBhY2NvdW50LCBNU01RIA0KbWVzc2FnZXMgc2VudCBieSBWaXN1YWwgQmFz aWMgc2NyaXB0cyB1bmRlciBBU1Agb24gdGhhdCBjb21wdXRlciBhcmUgc2VudCB3aXRoIG5v IA0KU2VjdXJpdHkgSWRlbnRpZmllciAoU0lEKS4gVGhlcmVmb3JlLCB0aGUgbWVzc2FnZSBz dWNjZXNzZnVsbHkgYXJyaXZlcyBhdCBpdHMgdGFyZ2V0IG9ubHkgDQppZiB0aGUgdGFyZ2V0 IHF1ZXVlIGRvZXMgbm90IHJlc3RyaWN0IGluY29taW5nIG1lc3NhZ2VzLiA8L3A+DQoNCjxw PjxzdHJvbmc+Tm90ZTwvc3Ryb25nPiZuYnNwOyZuYnNwOyZuYnNwO1RoaXMgcHJvZ3JhbW1p bmcgY29uc2lkZXJhdGlvbiBhcHBsaWVzIHRvIGFueSBzZXJ2aWNlIG9yIHByb2Nlc3MgcnVu bmluZyANCnVuZGVyIGEgbG9jYWwgYWNjb3VudC4gTG9jYWwgYWNjb3VudHMgZG8gbm90IGhh dmUgdmFsaWQgY3JlZGVudGlhbHMgb24gb3RoZXIgbWFjaGluZXMgDQphbmQgdGhlcmVmb3Jl IGNhbiBhY2Nlc3MgTVNNUSBxdWV1ZXMgb25seSBpZiB0aGUgYWNjZXNzIHJlcXVlc3RlZCBp cyBncmFudGVkIHRvIGFsbCANCmFjY291bnRzLjwvcD4NCg0KPGgyPkNvbmZpZ3VyaW5nIE1T TVEgU2VydmVycyB0aGF0IHVzZSBSQVM8L2gyPg0KDQo8cD5SQVMgSVAgYWRkcmVzc2VzIG9m IE1TTVEgU2VydmVycyAoUEVDLCBQU0MsIEJTQywgYW5kIFJvdXRpbmcgU2VydmVycykgbXVz dCBub3QgDQpiZSBwdWJsaXNoZWQgaW4gTVFJUy4gT25seSBMQU4gYWRkcmVzc2VzIHNob3Vs ZCBiZSBwdWJsaXNoZWQgaW4gTVFJUy48L3A+DQoNCjxwPkFmdGVyIHlvdSBzZXQgdXAgTVNN USBzZXJ2ZXJzIHRoYXQgdXNlIFJBUywgeW91IHNob3VsZCB1c2UgTVNNUSANCkV4cGxvcmVy IHRvIHZlcmlmeSB0aGF0IG5vIFJBUyBJUCBhZGRyZXNzZXMgYXJlIGxpc3RlZCBpbiB0aGUg TVFJUy48L3A+DQoNCjxwPkRlZmluZSBhbiBhZGRpdGlvbmFsIHN0YXRpYyAobm9uLURIQ1Ap IElQIGFkZHJlc3Mgb24geW91ciBMQU4gaW4gdGhlIHNhbWUgSVAgDQpzdWJuZXQgYXMgdGhl IFJBUyBhZGRyZXNzLiBUaGlzIGFwcGxpZXMgb25seSBpZiB5b3UgZG8gbm90IGhhdmUgYW4g SVAgTEFOIGFkZHJlc3MgaW4gDQp0aGUgc2FtZSBDTiBhcyB5b3VyIFJBUyBJUCBhZGRyZXNz LiA8L3A+DQoNCjxiaWc+VG8gZGVmaW5lIGFuIGFkZGl0aW9uYWwgc3RhdGljIElQIGFkZHJl c3MgaW4gdGhlIHNhbWUgSVAgc3VibmV0PC9iaWc+DQo8b2w+DQo8bGk+SW4gQ29udHJvbCBQ YW5lbCwgZG91YmxlLWNsaWNrIDxzdHJvbmc+TmV0d29yazwvc3Ryb25nPi4NCjxsaT5BZGQg dGhlIElQIGFkZHJlc3MgYXMgYSBzZWNvbmQgYWRkcmVzcyB0byB0aGUgTEFOIGFkYXB0ZXIg b2YgdGhlIG1hY2hpbmUuIDxicj4NCk1ha2Ugc3VyZSB0aGF0IHRoaXMgYWRkcmVzcyBpcyBw dWJsaXNoZWQgaW4gdGhlIE1RSVMgKHlvdSBjYW4gdXNlIHRoZSBNU01RIA0KRXhwbG9yZXIg dG8gYWRkIGFuIElQIGFkZHJlc3MgaW4gdGhlIE1RSVMgdG8gYSBtYWNoaW5lIGFuZCBhc3Nv Y2lhdGUgaXQgd2l0aCBhIA0KQ04pLg0KPC9vbD4NCg0KPGgyPk1TTVEgRXhwbG9yZXIgRGlz cGxheXMgT25seSAyMCwwMDAgTWVzc2FnZXM8L2gyPg0KDQo8cD5NU01RIEV4cGxvcmVyIGNh biBkaXNwbGF5IG9ubHkgMjAsMDAwIG1lc3NhZ2VzIGluIGEgcXVldWUuIElmIHRoZXJlIGFy ZSBtb3JlIHRoYW4gDQoyMCwwMDAgbWVzc2FnZXMgaW4gYSBxdWV1ZSwgTVNNUSBkaXNwbGF5 cyB0aGUgZm9sbG93aW5nIG1lc3NhZ2UgYmVsb3cgdGhlIGxhc3QgDQptZXNzYWdlIGRpc3Bs YXllZDo8L3A+DQo8YmxvY2txdW90ZT4NCiZxdW90O0FkZGl0aW9uYWwgbWVzc2FnZXMgY2Fu bm90IGJlIGRpc3BsYXllZCZxdW90Ow0KPC9ibG9ja3F1b3RlPg0KDQo8aDI+TVNNUSBTZXR1 cCBvbiBDb21wdXRlcnMgUnVubmluZyB0aGUgTVNNUSBFeGNoYW5nZSBDb25uZWN0b3I8L2gy Pg0KDQo8cD5Zb3UgbXVzdCBzdG9wIHRoZSBNU01RIEV4Y2hhbmdlIGNvbm5lY3RvciBzZXJ2 aWNlIGJlZm9yZSB5b3UgcnVuIFNldHVwLiBJZiB5b3UgcnVuIE1TTVEgU2V0dXAgZnJvbSB0 aGUgPHN0cm9uZz5TdGFydDwvc3Ryb25nPiBtZW51IHRvIGFkZCBvciByZW1vdmUgY29tcG9u ZW50cywgcmVpbnN0YWxsIE1TTVEsIG9yIHJlbW92ZSBNU01RLCBhbmQgaWYgdGhlIE1TTVEg RXhjaGFuZ2UgY29ubmVjdG9yIHNlcnZpY2UgaXMgcnVubmluZyBvbiB0aGF0IGNvbXB1dGVy LCBTZXR1cCBkaXNwbGF5cyBhIG1lc3NhZ2Ugc3RhdGluZyB0aGF0IGFuIE1TTVEtYmFzZWQg YXBwbGljYXRpb24gaXMgcnVubmluZywgYW5kIHRoZW4gU2V0dXAgZXhpdHMuIDwvcD4NCg0K PGJpZz5UbyBzdG9wIHRoZSBNU01RIEV4Y2hhbmdlIGNvbm5lY3RvciBzZXJ2aWNlPC9iaWc+ DQo8b2w+DQo8bGk+SW4gQ29udHJvbCBQYW5lbCwgZG91YmxlLWNsaWNrIDxzdHJvbmc+U2Vy dmljZXM8L3N0cm9uZz4uDQo8bGk+Q2xpY2sgdGhlIE1TTVEgRXhjaGFuZ2UgY29ubmVjdG9y ICg8ZW0+cXVldWUgbGFiZWw8L2VtPikgc2VydmljZSwgYW5kIHRoZW4gY2xpY2sgPHN0cm9u Zz5TdG9wPC9zdHJvbmc+Lg0KPC9vbD4NCg0KPGgyPlJlbW92aW5nIGEgTVFJUyBTZXJ2ZXIg YW5kIEluc3RhbGxpbmcgYW4gTVNNUSBSb3V0aW5nIFNlcnZlcjwvaDI+DQoNCjxwPklmIHlv dSBpbnN0YWxsIGFuIE1RSVMgc2VydmVyIChQRUMsIFBTQywgb3IgQlNDKSwgcmVtb3ZlIGl0 LCBpbnN0YWxsIGFuIE1TTVEgDQpyb3V0aW5nIHNlcnZlciwgYW5kIHRoZW4gcmVtb3ZlIFNR TCBTZXJ2ZXIsIHRoZSBNU01RIHJvdXRpbmcgc2VydmVyIHdpbGwgYmUgdW5hYmxlIA0KdG8g cHJvY2VzcyBjb29yZGluYXRlZCB0cmFuc2FjdGlvbnMuIFRoaXMgcHJvYmxlbSBvY2N1cnMg YmVjYXVzZSBTUUwgU2VydmVyIFNldHVwLCANCndoZW4gdXNlZCB0byByZW1vdmUgU1FMIFNl cnZlciwgYWxzbyByZW1vdmVzIE1TIERUQy48L3A+DQoNCjxwPlRvIGF2b2lkIHRoaXMgc2l0 dWF0aW9uLCByZW1vdmUgU1FMIFNlcnZlciBiZWZvcmUgaW5zdGFsbGluZyB0aGUgTVNNUSBy b3V0aW5nIA0Kc2VydmVyLiA8L3A+DQoNCjxoMj5NZXNzYWdlLWJhc2VkIFJQQyBhbmQgdGhl IE1TTVEgVHJhbnNwb3J0IGZvciBSUEM8L2gyPg0KDQo8cD5XaW5kb3dzJm5ic3A7TlQgNC4w IFNlcnZpY2UgUGFjayAzIGluY2x1ZGVzIGFuIGVuaGFuY2VkIHZlcnNpb24gb2YgdGhlIE1p Y3Jvc29mdCByZW1vdGUgcHJvY2VkdXJlIGNhbGwgKFJQQykNCmZhY2lsaXR5LCB3aGljaCBp bmNsdWRlcyBhIG5ldyBtZXNzYWdlLWJhc2VkIGFzeW5jaHJvbm91cyBtb2RlbCBhbmQgc3Vw cG9ydCBmb3IgcnVubmluZyBSUEMgb3ZlciBNU01RLiA8L3A+DQoNCjxoMj5EaXNhYmxpbmcg QXV0b21hdGljIENvbnRyb2wgb2YgU2l0ZSBDb250cm9sbGVyIFN3aXRjaGluZzwvaDI+DQoN CjxwPklmIHlvdXIgZW50ZXJwcmlzZSBjb25zaXN0cyBvZiBhIGxhcmdlIG51bWJlciBvZiBz aXRlIGNvbnRyb2xsZXIgKFBTQyBvciBCU0MpIHNlcnZlcnMsIHlvdSBtYXkgd2FudCB0byBk aXNhYmxlDQphdXRvbWF0aWMgc3dpdGNoaW5nIG9mIHNpdGUgY29udHJvbGxlciBzZXJ2ZXJz IGJ5IE1TTVEgUm91dGluZyBzZXJ2ZXJzIG9yIGNsaWVudHMgZm9yIHBlcmZvcm1hbmNlIHJl YXNvbnMuPC9wPg0KDQo8cD5Zb3UgY2FuIGNvbnRyb2wgd2hpY2ggc2l0ZSBjb250cm9sbGVy IHNlcnZlciBpcyBhY2Nlc3NlZCBieSBhbiBNU01RIFJvdXRpbmcgc2VydmVyIG9yIGNsaWVu dCBieSBhZGRpbmcNCmEgdmFsdWUgZW50cnkgdG8gdGhlIFdpbmRvd3MmbmJzcDtOVCByZWdp c3RyeSB1c2luZyB0aGUgUmVnaXN0cnkgRWRpdG9yLiBUbyBzdGFydCB0aGUgUmVnaXN0cnkg RWRpdG9yLCBvcGVuIGFuIE1TLURPUw0KY29tbWFuZC1wcm9tcHQgd2luZG93LCBhbmQgdGhl biB0eXBlIDxzdHJvbmc+cmVnZWRpdDwvc3Ryb25nPiBvciA8c3Ryb25nPnJlZ2VkdDMyPC9z dHJvbmc+LjwvcD4NCg0KPHA+VGhlIG5ldyByZWdpc3RyeSBlbnRyeSBuYW1lIGlzIDxzdHJv bmc+U3RhdGljTVFJU1NlcnZlcjwvc3Ryb25nPiwgdGhlIGRhdGEgdHlwZSBpcyA8c3Ryb25n PlJFR19TWjwvc3Ryb25nPiwgYW5kDQp0aGUgdmFsdWUgaXMgYSBsaXN0IG9mIHNpdGUgY29u dHJvbGxlciBzZXJ2ZXIgbmFtZXMsIGVhY2ggcHJlZml4ZWQgd2l0aCB0d28gcHJvdG9jb2wg ZmxhZ3MuIFRoZSBwYXRoIHlvdSBzaG91bGQNCmFkZCB0aGUgZW50cnkgdW5kZXIgaXMgYXMg Zm9sbG93czo8L3A+DQoNCjxwcmU+SEtFWV9MT0NBTF9NQUNISU5FXFNZU1RFTQ0KICAgICBc Q3VycmVudENvbnRyb2xTZXQNCiAgICAgICBcU2VydmljZXMNCiAgICAgICAgIFxNU01RDQog ICAgICAgICAgIFxQYXJhbWV0ZXJzDQogICAgICAgICAgICAgXE1hY2hpbmVDYWNoZQ0KPC9w cmU+CQkJCQ0KDQo8cD5BcyBhbiBleGFtcGxlLCBzZWUgdGhlIDxzdHJvbmc+TVFJU1NlcnZl cjwvc3Ryb25nPiBlbnRyeSB1bmRlciB0aGUgc2FtZSBwYXRoLjwvcD4NCg0KPHAgY2xhc3M9 Im5vdGUiPjxhIG5hbWU9IlBfMjI2NzYzMzkwNyI+PC9hPjxhIG5hbWU9IlBfNDM0NjQzMTAi PjwvYT48c3Ryb25nPjxzcGFuIHN0eWxlPSJjb2xvcjogIzAwMDBGRiI+PGZvbnQgY29sb3I9 IiMwMDAwRkYiPg0KSW1wb3J0YW50PC9mb250Pjwvc3Bhbj48L3N0cm9uZz4mbmJzcDsmbmJz cDsmbmJzcDtCZWZvcmUgZWRpdGluZyB0aGUgcmVnaXN0cnksIGl0IGlzIHJlY29tbWVuZGVk IHRoYXQgeW91IGNyZWF0ZSBhIGJhY2t1cCBvZiB5b3VyIGNvbmZpZ3VyYXRpb24gZmlsZS4N CklmIHlvdSBpbnRyb2R1Y2UgYW4gZXJyb3IgaW4gdGhlIHJlZ2lzdHJ5IGFuZCB5b3VyIGNv bXB1dGVyIGJlY29tZXMgbm9uZnVuY3Rpb25hbCwgeW91IGNhbiB1c2UgdGhlIGJhY2t1cA0K Y29uZmlndXJhdGlvbiBmaWxlIHRvIHJlc3RvcmUgeW91ciBjb21wdXRlciBzZXR0aW5ncy48 L3A+DQoNCjxocj4NCjxoMT48YSBuYW1lPSJLbm93blByb2JsZW1zIj5Lbm93biBQcm9ibGVt czwvYT48L2gxPg0KDQo8cD5UaGlzIHNlY3Rpb24gZG9jdW1lbnRzIHByb2JsZW1zIGtub3du IGF0IHRoZSB0aW1lIG9mIHJlbGVhc2Ugb2YgTVNNUS48L3A+DQoNCjxoMj48YSBuYW1lPSJV cGdyYWRpbmdNU01RIj5VcGdyYWRpbmcgTVNNUTwvYT48L2gyPg0KDQo8cD5JZiB5b3UgYXJl IHVwZ3JhZGluZyBmcm9tIHRoZSB2ZXJzaW9uIG9mIE1TTVEgcHJvdmlkZWQgd2l0aCBXaW5k b3dzJm5ic3A7TlQgU2VydmVyL0UgdG8gdGhlIHZlcnNpb24gb2YgTVNNUQ0KcHJvdmlkZWQg d2l0aCB0aGUgV2luZG93cyZuYnNwOzk4IENELCB0aGUgZm9sbG93aW5nIGV2ZW50cyBjYW4g b2NjdXIgZHVyaW5nIFNldHVwOjwvcD4NCjx1bD4NCjxsaT5TZXR1cCBjYW4gZmFpbCBpZiB5 b3UgaGF2ZSBwcmV2aW91c2x5IHVzZWQgTVNNUSBpbiBjb25qdW5jdGlvbiB3aXRoIEludGVy bmV0IEluZm9ybWF0aW9uIFNlcnZlciAoc3VjaCBhcyBmb3IgQWN0aXZlIFNlcnZlciBQYWdl cykuIFlvdSB3aWxsIG5lZWQgdG8gcmVzdGFydCB5b3VyIGNvbXB1dGVyIGZpcnN0IGJlZm9y ZSBwcm9jZWVkaW5nIHdpdGggU2V0dXAuIFRoaXMgYWxzbyBhcHBsaWVzIGlmIHlvdSBhcmUg cmVtb3ZpbmcgKGluc3RlYWQgb2YgdXBncmFkaW5nKSBNU01RIHRocm91Z2ggU2V0dXAuPC9s aT4NCjxsaT5TZXR1cCBjYW4gZmFpbCBpZiBXaW5kb3dzJm5ic3A7TlQgUGVyZm9ybWFuY2Ug TW9uaXRvciBpcyBydW5uaW5nLiBCZWZvcmUgcnVubmluZyBTZXR1cCwgbWFrZSBzdXJlDQpQ ZXJmb3JtYW5jZSBNb25pdG9yIGlzIG5vdCBydW5uaW5nLjwvbGk+DQo8bGk+QSBtZXNzYWdl IGNhbiBhcHBlYXIsIGFza2luZyB5b3UgZm9yIHRoZSBhc3NvY2lhdGlvbnMgYmV0d2VlbiB5 b3VyIGNvbm5lY3RlZCBuZXR3b3JrIChDTikgbmFtZXMNCmFuZCBJRHMuIFlvdSBzaG91bGQg aGF2ZSBhIHdyaXR0ZW4gbGlzdCBvZiB5b3VyIENOIGFzc29jaWF0aW9ucyB3aGVuIHlvdSBz dGFydCBTZXR1cC48L2xpPg0KPGxpPklmIHlvdSB1cGdyYWRlIGFuIE1RSVMgc2VydmVyIGFu ZCB0aGVuIHVuaW5zdGFsbCB0aGUgdXBncmFkZSwgdGhlIGRhdGFiYXNlIGZpbGVzIE1xaXNk YXRhLmRhdCBhbmQgTXFpc2xvZy5kYXQNCm1heSBub3QgYmUgcmVtb3ZlZC4gVGhpcyBkb2Vz IG5vdCBoYXZlIGFuIGFkdmVyc2UgZWZmZWN0IG9uIHRoZSBmdW5jdGlvbmluZyBvZiBNU01R LjwvbGk+DQo8L3VsPg0KDQo8aDI+PGEgbmFtZT0iTVNNUVNlcnZlck5hbWluZyI+TVNNUSBT ZXJ2ZXIgTmFtaW5nPC9hPjwvaDI+DQoNCjxwPlRoZSBzZWN0aW9uICZxdW90O01TTVEgU2Vy dmVyIE5hbWluZyZxdW90OyBpbiAmcXVvdDtCZWZvcmUgWW91IEJlZ2luJnF1b3Q7IGlzIGlu Y29ycmVjdC4gTVNNUSBzZXJ2ZXJzIGFyZSBjYWxsZWQgcm91dGluZyBzZXJ2ZXJzIGZvciBi b3RoIHRoZSBXaW5kb3dzJm5ic3A7OTggYW5kICBmb3IgV2luZG93cyZuYnNwO05UIFNlcnZl ci9FLjwvcD4gDQoNCjxoMj5EZWZhdWx0IERhdGFiYXNlIFNpemUgaXMgODAvMjA8L2gyPg0K DQo8cD4mcXVvdDtEZXRlcm1pbmluZyB0aGUgU2l6ZSBvZiB0aGUgSW5mb3JtYXRpb24gU3Rv cmUmcXVvdDssIGluICZxdW90O0RlcGxveWluZyBNU01RLCZxdW90OyBpbiB0aGUgTVNNUQ0K PGVtPkFkbWluaXN0cmF0b3IncyBHdWlkZTwvZW0+IGRlc2NyaWJlcyB0aGUgZGVmYXVsdCBN UUlTIGRhdGFiYXNlIHNpemUgYXMgNTAgTUIsIHdpdGggYW4gOC1NQiBsb2cgZmlsZS4NClRo aXMgaXMgaW5jb3JyZWN0LiBUaGlzIGlzIGluY29ycmVjdC4gVGhlIGRlZmF1bHQgTVFJUyBk YXRhYmFzZSBzaXplIGlzIDgwIE1CLCB3aXRoIGEgMjAtTUIgbG9nIGZpbGUuPC9wPg0KPGgy Pk1TTVEgU2VydmVyIENhbiBTdXBwb3J0IE1vcmUgdGhhbiAxNSBEZXBlbmRlbnQgQ2xpZW50 czwvaDI+DQoNCjxwPlRoZSAmcXVvdDtNU01RIERlcGVuZGVudCBDbGllbnRzJnF1b3Q7IHNl Y3Rpb24gaW4gJnF1b3Q7VW5kZXJzdGFuZGluZyBNU01RJnF1b3Q7IGluIHRoZSBNU01RIDxl bT5BZG1pbmlzdHJhdG9yJ3MgDQpHdWlkZTwvZW0+IHN0YXRlczo8L3A+DQo8YmxvY2txdW90 ZT4NCiZxdW90O01TTVEgc2VydmVycyBjYW4gc3VwcG9ydCB1cCB0byAxNSBkZXBlbmRlbnQg Y2xpZW50cy4mcXVvdDsNCjwvYmxvY2txdW90ZT4NCg0KPHA+VGhpcyBpcyBpbmNvcnJlY3Qu IFRoZSBudW1iZXIgb2YgZGVwZW5kZW50IGNsaWVudHMgdGhhdCBhbiBNU01RIHNlcnZlciBj YW4gc3VwcG9ydCANCmlzIGJhc2VkIG9uIHRoZSBudW1iZXIgb2YgQ0FMcyBhdmFpbGFibGUg b24gdGhlIHNlcnZlci4gRm9yIG1vcmUgaW5mb3JtYXRpb24sIHNlZSAmcXVvdDtNU01RIGFu ZCBXaW5kb3dzJm5ic3A7TlQgU2VydmVyIENBTHMmcXVvdDsgZWFybGllciBpbiB0aGlzIGRv Y3VtZW50LjwvcD4NCg0KPGgyPk1TTVEgU2V0dXA6IEluc3RhbGxhdGlvbiBvZiBJbmRlcGVu ZGVudCBDbGllbnQgb24gYSBTZXJ2ZXI8L2gyPg0KDQo8cD5UaGUgJnF1b3Q7TVNNUSBTZXR1 cCZxdW90OyBzZWN0aW9uIGluICZxdW90O0JlZm9yZSBZb3UgQmVnaW4mcXVvdDsgc3RhdGVz OjwvcD4NCg0KPGJsb2NrcXVvdGU+IA0KJnF1b3Q7WW91IGNhbiBpbnN0YWxsIE1TTVEgaW5k ZXBlbmRlbnQgY2xpZW50cyBhbmQgZGVwZW5kZW50IGNsaWVudHMgb24gY29tcHV0ZXJzIHJ1 bm5pbmcgV2luZG93cyANCk5UIFdvcmtzdGF0aW9uIDQuMCBvciBXaW5kb3dzIDk4LiBZb3Ug Y2Fubm90IGluc3RhbGwgTVNNUSBjbGllbnRzIG9uIGNvbXB1dGVycyBydW5uaW5nIA0KV2lu ZG93cyZuYnNwO05UIFNlcnZlci4mcXVvdDs8L2Jsb2NrcXVvdGU+DQoNCjxwPlRoaXMgaXMg aW5jb3JyZWN0LiBZb3UgY2FuIGluc3RhbGwgTVNNUSBpbmRlcGVuZGVudCBhbmQgZGVwZW5k ZW50IGNsaWVudHMgb24gY29tcHV0ZXJzIHJ1bm5pbmcgV2luZG93cyZuYnNwO05UIFNlcnZl ciwgV2luZG93cyZuYnNwO05UIFdvcmtzdGF0aW9uLCBvciBXaW5kb3dzJm5ic3A7OTguPC9w Pg0KDQo8aDI+PGEgbmFtZT0iSW5zdGFsbGluZ01TTVFvbmFDb21wdXRlclJ1bm5pbmdXaW5k b3dzTlRTZXJ2ZXJFIj5JbnN0YWxsaW5nIE1TTVEgb24gYSBDb21wdXRlciBSdW5uaW5nIFdp bmRvd3MmbmJzcDtOVA0KU2VydmVyL0U8L2E+PC9oMj4NCg0KPHA+VGhlICZxdW90O01TTVEg U2V0dXAmcXVvdDsgc2VjdGlvbiBpbiAmcXVvdDtCZWZvcmUgWW91IEJlZ2luJnF1b3Q7IHN0 YXRlczo8L3A+DQo8YmxvY2txdW90ZT4NCiZxdW90O1lvdSBzaG91bGQgbm90IGluc3RhbGwg dGhlIHZlcnNpb24gb2YgTVNNUSBwcm92aWRlZCB3aXRoIHRoZSBXaW5kb3dzJm5ic3A7TlQg T3B0aW9uIFBhY2sgb24gYSBjb21wdXRlcg0KcnVubmluZyBXaW5kb3dzJm5ic3A7TlQgU2Vy dmVyL0UuIFlvdSBzaG91bGQgaW5zdGVhZCBpbnN0YWxsIHRoZSB2ZXJzaW9uIG9mIE1TTVEg dGhhdCBpcyBwcm92aWRlZCB3aXRoIFdpbmRvd3MmbmJzcDtOVA0KU2VydmVyL0UuICZxdW90 OzwvYmxvY2txdW90ZT4NCg0KPHA+VGhpcyBpcyBpbmNvcnJlY3QuIFlvdSBjYW4gaW5zdGFs bCBhbnkgdmVyc2lvbiBvZiBNU01RIChpbmNsdWRpbmcgdGhlIHZlcnNpb24gcHJvdmlkZWQg d2l0aCBXaW5kb3dzJm5ic3A7OTgpIG9uIGENCmNvbXB1dGVyIHJ1bm5pbmcgV2luZG93cyZu YnNwO05UIFNlcnZlci9FLiBIb3dldmVyLCB5b3UgZm9yZmVpdCB0aGUgdXNlIG9mIHRoZSBs aW1pdGVkIGVkaXRpb24gb2YgU1FMIFNlcnZlcg0KNi41IHRoYXQgaXMgcHJvdmlkZWQgd2l0 aCBXaW5kb3dzJm5ic3A7TlQgU2VydmVyL0UgaWYgeW91IGluc3RhbGwgdGhlIHZlcnNpb24g b2YgTVNNUSBwcm92aWRlZCB3aXRoIFdpbmRvd3MgOTguPC9wPg0KDQo8aDI+UmVuYW1pbmcg YSBDb21wdXRlciBSdW5uaW5nIE1TTVE8L2gyPg0KDQo8cD4mcXVvdDtNYW5hZ2luZyBZb3Vy IE1TTVEgRW50ZXJwcmlzZSwmcXVvdDsgaW4gdGhlIE1TTVEgPGVtPkFkbWluaXN0cmF0b3In cyBHdWlkZTwvZW0+IA0KZGVzY3JpYmVzIHRoZSByZW5hbWluZyBvZiBNU01RIGRlcGVuZGVu dCBjbGllbnRzLCBpbmRlcGVuZGVudCBjbGllbnRzLCBhbmQNCnJvdXRpbmcgc2VydmVycy4g VGhpcyBpcyBzdXBwb3J0ZWQgb25seSBmb3IgZGVwZW5kZW50IGNsaWVudHMuPC9wPg0KDQo8 cD48c3Ryb25nPk5vdGU8L3N0cm9uZz4mbmJzcDsmbmJzcDsmbmJzcDtUbyByZW5hbWUgYSBj b21wdXRlciBydW5uaW5nIE1TTVEsIHlvdSBtdXN0IHVuaW5zdGFsbCBNU01RLCByZW5hbWUg dGhlIA0KY29tcHV0ZXIsIGFuZCByZWluc3RhbGwgTVNNUS4gVGhpcyBwcm9jZWR1cmUgZGVs ZXRlcyBhbGwgdGhlIHF1ZXVlcyB0aGF0IGFyZSBvbiANCnRoZSBjb21wdXRlci4gWW91IG11 c3QgcmUtY3JlYXRlIHRoZSBxdWV1ZXMgYWZ0ZXIgeW91IHJlaW5zdGFsbCBNU01RLjwvcD4N Cg0KPGgyPkNyZWF0ZSBTZXJ2ZXIgQWNjZXNzOiBQZXJtaXNzaW9ucyBhbmQgQXVkaXRpbmc8 L2gyPg0KDQo8cD4mcXVvdDtTZWN1cmluZyBNU01RLCZxdW90OyBpbiB0aGUgTVNNUSA8ZW0+ QWRtaW5pc3RyYXRvcidzIEd1aWRlPC9lbT4sIGRvY3VtZW50cyB0aGUgDQo8c3Ryb25nPkNy ZWF0ZSBSb3V0ZSBTZXJ2ZXI8L3N0cm9uZz4gc3BlY2lhbCBhY2Nlc3MgcGVybWlzc2lvbi4g VGhpcyBpcyBub3QgdGhlIGNvcnJlY3QgbmFtZSBmb3IgdGhlIA0KcGVybWlzc2lvbi4gVGhl IHNwZWNpYWwgYWNjZXNzIHBlcm1pc3Npb24gaXMgPHN0cm9uZz5DcmVhdGUgUm91dGluZyBT ZXJ2ZXI8L3N0cm9uZz4uIFRoaXMgZXJyb3IgDQphcHBlYXJzIGluIHRhYmxlIDUuMiwgdGFi bGUgNS42LCBhbmQgaW4gJnF1b3Q7QXVkaXRpbmcgYSBTaXRlJnF1b3Q7IGluIHRoYXQgc2Vj dGlvbi4NCg0KPGgyPkNhbm5vdCBVc2UgQWN0aXZlWCBDb250cm9scyB0byBDcmVhdGUgYSBD dXN0b20gTWFuYWdpbmcgQXBwbGljYXRpb248L2gyPg0KDQo8cD4mcXVvdDtDcmVhdGluZyBh IEN1c3RvbSBNYW5hZ2luZyBBcHBsaWNhdGlvbiZxdW90OyBpbiAmcXVvdDtNYW5hZ2luZyBZ b3VyIE1TTVEgRW50ZXJwcmlzZSZxdW90OyBpbiB0aGUgTVNNUSA8ZW0+QWRtaW5pc3RyYXRv cidzDQpHdWlkZTwvZW0+IHN0YXRlczo8L3A+DQo8YmxvY2txdW90ZT4NCiZxdW90O1RoZSBB Y3RpdmVYIGNvbnRyb2xzIHByb3ZpZGVkIGJ5IE1TTVEgY2FuIGJlIHVzZWQgdG86PGJyPg0K DQo8dWw+DQo8bGk+Q3JlYXRlIHNpdGVzLCBDTnMsIGFuZCBjb21wdXRlcnM8L2xpPg0KPGxp PkNoYW5nZSBDTnMsIEluUlNzLCBhbmQgT3V0UlNzIGZvciBjb21wdXRlcnM8L2xpPg0KPGxp PkNoYW5nZSBzaXRlIGdhdGUgc2V0dGluZ3MgZm9yIHRoZSBQRUMgYW5kIFBTQ3M8L2xpPg0K PGxpPlZpZXcgZW50ZXJwcmlzZSBzZXR0aW5ncyZxdW90OzwvbGk+DQo8L3VsPg0KPC9ibG9j a3F1b3RlPg0KDQo8cD5UaGlzIGZ1bmN0aW9uYWxpdHkgaXMgbm90IGF2YWlsYWJsZSBpbiBN U01RIHZlcnNpb24gMS4wLjwvcD4NCg0KPGgyPjxhIG5hbWU9Ikluc3RhbGxpbmcgdGhlIFNE SyI+SW5zdGFsbGluZyB0aGUgU0RLPC9hPjwvaDI+DQoNCjxwPlRoZSBwcm9jZWR1cmUgZm9y IGluc3RhbGxpbmcgdGhlIE1TTVEgU29mdHdhcmUgRGV2ZWxvcG1lbnQgS2l0IChTREspIGlz IGluY29ycmVjdCBpbiB0aGUgTVNNUQ0KPEVtPlByb2dyYW1tZXIncyBSZWZlcmVuY2U8L0Vt Pi4gVGhlIGNvcnJlY3QgcHJvY2VkdXJlIGZvciBpbnN0YWxsaW5nIHRoZSBTREsgYWZ0ZXIg TVNNUSBpcyANCmluc3RhbGxlZCBpcyBhcyBmb2xsb3dzOjwvcD4NCjxvbD4NCjxsaT5JbiBD b250cm9sIFBhbmVsLCBkb3VibGUtY2xpY2sgPFN0cm9uZz5BZGQvUmVtb3ZlIFByb2dyYW1z PC9TdHJvbmc+Lg0KPGxpPk9uIHRoZSA8U3Ryb25nPkluc3RhbGwvVW5pbnN0YWxsPC9TdHJv bmc+IHRhYiwgY2xpY2sgPFN0cm9uZz5NaWNyb3NvZnQgUGVyc29uYWwgV2ViIFNlcnZlcjwv U3Ryb25nPiBvbiB0aGUgbGlzdCwNCmFuZCB0aGVuIGNsaWNrIDxTdHJvbmc+QWRkL1JlbW92 ZTwvU3Ryb25nPi4NCjxsaT5JbiB0aGUgPFN0cm9uZz5QZXJzb25hbCBXZWIgU2VydmVyIFNl dHVwPC9TdHJvbmc+IGRpYWxvZyBib3gsIGNsaWNrIDxTdHJvbmc+TmV4dDwvU3Ryb25nPiwN CmFuZCB0aGVuIGNsaWNrIDxTdHJvbmc+QWRkL1JlbW92ZTwvU3Ryb25nPi4NCjxsaT5VbmRl ciA8U3Ryb25nPkNvbXBvbmVudHM8L1N0cm9uZz4sIHNlbGVjdCB0aGUgPFN0cm9uZz5NaWNy b3NvZnQgTWVzc2FnZSBRdWV1ZTwvU3Ryb25nPiBjaGVjayBib3guDQo8bGk+Q2xpY2sgPFN0 cm9uZz5TaG93IFN1YmNvbXBvbmVudHM8L1N0cm9uZz4sIHNlbGVjdCB0aGUgPFN0cm9uZz5T b2Z0d2FyZSBEZXZlbG9wbWVudCBLaXQ8L1N0cm9uZz4gY2hlY2sgYm94LA0KYW5kIHRoZW4g Y2xpY2sgPFN0cm9uZz5PSzwvU3Ryb25nPiB0byBjbG9zZSBhbGwgZGlhbG9nIGJveGVzLg0K PC9vbD4NCg0KPGhyPg0KPGgxPjxhIG5hbWU9IkNvcHlyaWdodEluZm9ybWF0aW9uIj5Db3B5 cmlnaHQgSW5mb3JtYXRpb248L2E+PC9oMT4NCg0KPHA+JmNvcHk7IDE5OTcgTWljcm9zb2Z0 IENvcnBvcmF0aW9uLiBBbGwgcmlnaHRzIHJlc2VydmVkLjwvcD4NCg0KPHA+VGhlc2UgbWF0 ZXJpYWxzIGFyZSBwcm92aWRlZCAmcXVvdDthcy1pcywmcXVvdDsgZm9yIGluZm9ybWF0aW9u YWwgcHVycG9zZXMgb25seS48L3A+DQoNCjxwPk5laXRoZXIgTWljcm9zb2Z0IG5vciBpdHMg c3VwcGxpZXJzIG1ha2VzIGFueSB3YXJyYW50eSwgZXhwcmVzcyBvciBpbXBsaWVkIHdpdGgg cmVzcGVjdCB0byB0aGUgY29udGVudCBvZiB0aGVzZSBtYXRlcmlhbHMgb3IgdGhlIGFjY3Vy YWN5IG9mIGFueSBpbmZvcm1hdGlvbiBjb250YWluZWQgaGVyZWluLCBpbmNsdWRpbmcsIHdp dGhvdXQgbGltaXRhdGlvbiwgdGhlIGltcGxpZWQgd2FycmFudGllcyBvZiBtZXJjaGFudGFi aWxpdHkgb3IgZml0bmVzcyBmb3IgYSBwYXJ0aWN1bGFyIHB1cnBvc2UuIEJlY2F1c2Ugc29t ZSBzdGF0ZXMvanVyaXNkaWN0aW9ucyBkbyBub3QgYWxsb3cgZXhjbHVzaW9ucyBvZiBpbXBs aWVkIHdhcnJhbnRpZXMsIHRoZSBhYm92ZSBsaW1pdGF0aW9uIG1heSBub3QgYXBwbHkgdG8g eW91LjwvcD4NCg0KPHA+TmVpdGhlciBNaWNyb3NvZnQgbm9yIGl0cyBzdXBwbGllcnMgc2hh bGwgaGF2ZSBhbnkgbGlhYmlsaXR5IGZvciBhbnkgZGFtYWdlcyB3aGF0c29ldmVyIGluY2x1 ZGluZyBjb25zZXF1ZW50aWFsLCBpbmNpZGVudGFsLCBkaXJlY3QsIGluZGlyZWN0LCBzcGVj aWFsLCBhbmQgbG9zdCBwcm9maXRzLiBCZWNhdXNlIHNvbWUgc3RhdGVzL2p1cmlzZGljdGlv bnMgZG8gbm90IGFsbG93IGV4Y2x1c2lvbnMgb2YgaW1wbGllZCB3YXJyYW50aWVzLCB0aGUg YWJvdmUgbGltaXRhdGlvbiBtYXkgbm90IGFwcGx5IHRvIHlvdS4gSW4gYW55IGV2ZW50LCBN aWNyb3NvZnQncyBhbmQgaXRzIHN1cHBsaWVycycgZW50aXJlIGxpYWJpbGl0eSBpbiBhbnkg bWFubmVyIGFyaXNpbmcgb3V0IG9mIHRoZXNlIG1hdGVyaWFscywgd2hldGhlciBieSB0b3J0 LCBjb250cmFjdCwgb3Igb3RoZXJ3aXNlIHNoYWxsIG5vdCBleGNlZWQgdGhlIHN1Z2dlc3Rl ZCByZXRhaWwgcHJpY2Ugb2YgdGhlc2UgbWF0ZXJpYWxzLjwvcD4NCg0KPGhyIGNsYXNzPSJp aXMiIHNpemU9IjEiPg0KPHAgYWxpZ249ImNlbnRlciI+PGVtPjxhIGhyZWY9Ii9paXNoZWxw L2NvbW1vbi9jb2xlZ2FsLmh0bSI+JmNvcHk7IDE5OTcgYnkgTWljcm9zb2Z0IENvcnBvcmF0 aW9uLiBBbGwgcmlnaHRzIHJlc2VydmVkLjwvYT48L2VtPjwvcD4NCg0KPC9mb250Pg0KPC9i b2R5Pg0KPC9odG1sPj== --J467536839gM3n860F97993PgP81YSXLg1S6f-- From owner-ips@ece.cmu.edu Mon Jul 8 02:35:25 2002 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA05152 for ; Mon, 8 Jul 2002 02:35:25 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id g68625K13974 for ips-outgoing; Mon, 8 Jul 2002 02:02:05 -0400 (EDT) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from d12lmsgate.de.ibm.com (d12lmsgate.de.ibm.com [195.212.91.199]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id g68623X13970 for ; Mon, 8 Jul 2002 02:02:03 -0400 (EDT) Received: from d12relay02.de.ibm.com (d12relay02.de.ibm.com [9.165.215.23]) by d12lmsgate.de.ibm.com (8.12.3/8.12.3) with ESMTP id g6861vIB027874 for ; Mon, 8 Jul 2002 08:01:57 +0200 Received: from d10hubm1.telaviv.ibm.com (d10ml001.telaviv.ibm.com [9.148.216.55]) by d12relay02.de.ibm.com (8.11.1m3/NCO/VER6.2) with ESMTP id g6861uZ101500 for ; Mon, 8 Jul 2002 08:01:57 +0200 To: ips@ece.cmu.edu MIME-Version: 1.0 Subject: iSCSI - decimal coded binary strings - a proposed resolution X-Mailer: Lotus Notes Release 5.0.9 November 16, 2001 From: "Julian Satran" Message-ID: Date: Mon, 8 Jul 2002 09:01:54 +0300 X-MIMETrack: Serialize by Router on D10ML001/10/M/IBM(Release 5.0.9a |January 7, 2002) at 08/07/2002 09:01:57, Serialize complete at 08/07/2002 09:01:57 Content-Type: multipart/alternative; boundary="=_alternative 00206FFBC2256BF0_=" Sender: owner-ips@ece.cmu.edu Precedence: bulk This is a multipart message in MIME format. --=_alternative 00206FFBC2256BF0_= Content-Type: text/plain; charset="us-ascii" Considering the widespread use of decimal encoding and the perceived difficulty of mapping them to a binary string - mainly due to the difficulty of matching lengths I suggest the following: Decimal encoding for binary strings will be used only where the length of the binary string is explicitly defined (by a constant or a rule that does not use the encoding itself) The definition for decimal constant becomes: decimal-constant: an unsigned decimal number - the digit 0 or a string of 1 or more digits starting with a non-zero digit. This encoding is not used for numerical values equal or greater than 2**64. Decimal-constants are used to encode numerical values or binary strings. Decimal constants can be used to encode binary strings only if the stringlength is explicitly specified. There is no implicit length for deci-mal strings. Julo --=_alternative 00206FFBC2256BF0_= Content-Type: text/html; charset="us-ascii"
Considering the widespread use of decimal encoding and the perceived difficulty of mapping them to a binary  string
- mainly due to the difficulty of matching lengths I suggest the following:

  • Decimal encoding for binary strings will be used only where the length of the binary string is explicitly defined (by a constant or a rule that does not use the encoding itself)

    The definition for decimal constant becomes:

    decimal-constant: an unsigned decimal number - the digit 0 or a string of 1 or more digits starting with a non-zero digit. This encoding is not used for numerical values equal or greater than 2**64. Decimal-constants are used to encode numerical values or binary strings. Decimal constants can be used to encode binary strings only if the stringlength is explicitly specified. There is no implicit length for deci-mal strings.
    Julo
--=_alternative 00206FFBC2256BF0_=-- From owner-ips@ece.cmu.edu Mon Jul 8 02:36:52 2002 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA05207 for ; Mon, 8 Jul 2002 02:36:52 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id g6860Ms13928 for ips-outgoing; Mon, 8 Jul 2002 02:00:22 -0400 (EDT) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from intens2.pdcint (fw.siliquent.com [212.143.51.98]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id g6860KX13924 for ; Mon, 8 Jul 2002 02:00:20 -0400 (EDT) Received: by INTENS2 with Internet Mail Service (5.5.2650.21) id <3N72PR47>; Mon, 8 Jul 2002 09:04:44 +0200 Message-ID: From: Benny Getz To: "'Black_David'" , "'ips@ece.cmu.edu'" Subject: RE: Introduction on ADSL ******* E-MAIL IS A VIRUS !!!! BEWARE Date: Mon, 8 Jul 2002 09:04:44 +0200 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-ips@ece.cmu.edu Precedence: bulk NAV has detected a VIRUS in the original mail. regards, Regards, Benny Getz Chief Scientist, Siliquent Technologies Ltd. www.siliquent.com -----Original Message----- From: Black_David [mailto:Black_David@emc.com] Sent: Monday, July 08, 2002 6:35 AM To: ips@ece.cmu.edu Subject: Introduction on ADSL From owner-ips@ece.cmu.edu Mon Jul 8 10:49:47 2002 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA17564 for ; Mon, 8 Jul 2002 10:49:47 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id g68E7wL07475 for ips-outgoing; Mon, 8 Jul 2002 10:07:58 -0400 (EDT) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from mailhub.lss.emc.com (xdch.emc.com [168.159.1.79]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id g68E7pX07466 for ; Mon, 8 Jul 2002 10:07:52 -0400 (EDT) Received: from emc.com (emcmail.lss.emc.com [168.159.48.78]) by mailhub.lss.emc.com (Switch-2.2.0/Switch-2.2.0) with ESMTP id g68E7e506044; Mon, 8 Jul 2002 10:07:41 -0400 (EDT) Received: from mxic1.isus.emc.com ([168.159.129.100]) by emc.com (8.10.1/8.10.1) with ESMTP id g68E7d713576; Mon, 8 Jul 2002 10:07:40 -0400 (EDT) Received: by MXIC1 with Internet Mail Service (5.5.2653.19) id <31WABXBG>; Mon, 8 Jul 2002 10:05:43 -0400 Message-ID: <277DD60FB639D511AC0400B0D068B71E0564C037@CORPMX14> From: Black_David@emc.com To: rod.harrison@windriver.com, ips@ece.cmu.edu Subject: RE: iSCSI: DLB's [T.33] 10.5 Challenge Handshake Authentication P rotocol (CHAP) Date: Mon, 8 Jul 2002 10:05:40 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" X-Perlmx-Spam: Gauge=XXIIIIIII, Probability=27%, Report="NO_REAL_NAME, SUBJ_HAS_SPACES" Sender: owner-ips@ece.cmu.edu Precedence: bulk Rod, > A MUST here seems to preclude the initiator not offering CHAP due to > administrative configuration. In fact the original SHOULD seems a bit > strong. > > I.e. is ... > > AuthMethod=none > > no longer to be valid? No, this text has no effect on AuthMethod, it's about the values of the CHAP_A key. The text in question refers only to the CHAP algorithms to be offered *once CHAP is selected*. AuthMethod=none would still be valid, as is skipping the security negotiation stage entirely. As the current text says, the only CHAP algorithm for which interoperability can be assured is MD5. There's a related problem here in that the encoding of the values of the CHAP_A key are not specified - the quickest way out of this one would be to have them be numbers and refer to the IANA registry from which the numbers MUST be taken. 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 --------------------------------------------------- From owner-ips@ece.cmu.edu Mon Jul 8 10:51:47 2002 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA17697 for ; Mon, 8 Jul 2002 10:51:47 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id g68EKgp08162 for ips-outgoing; Mon, 8 Jul 2002 10:20:42 -0400 (EDT) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from mxic2.corp.emc.com (mxic2.isus.emc.com [128.221.31.40]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id g68EKfX08157 for ; Mon, 8 Jul 2002 10:20:41 -0400 (EDT) Received: by mxic2.corp.emc.com with Internet Mail Service (5.5.2653.19) id <31X63Z6D>; Mon, 8 Jul 2002 10:20:36 -0400 Message-ID: <277DD60FB639D511AC0400B0D068B71E0564C039@CORPMX14> From: Black_David@emc.com To: aghanem@cisco.com, ips@ece.cmu.edu Subject: RE: iSCSI: DLB's [T.6] 2.3 iSCSI Session Types Date: Mon, 8 Jul 2002 10:18:38 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-ips@ece.cmu.edu Precedence: bulk Ayman, Something needs to be cleaned up here, as the current text appears to allow all types of iSCSI PDUs on a discovery session. I didn't intend to restrict a discovery session to one Send Targets followed by a logout (i.e., it could be kept open with the initiator periodically sending a new Send Targets to see if anything has changed), but I did intend to forbid SCSI commands, task management, etc. on Discovery sessions. Is that reasonable, or are there additional types of iSCSI PDUs that you want to see allowed for new device notifications? Thanks, --David > -----Original Message----- > From: Ayman Ghanem [mailto:aghanem@cisco.com] > Sent: Sunday, July 07, 2002 12:41 PM > To: ips@ece.cmu.edu > Subject: RE: iSCSI: DLB's [T.6] 2.3 iSCSI Session Types > > > I prefer leaving this as "MAY" for implementations that want > to support new > device notifications. There was a discussion on whether > discovery sessions > should be long-lived or not. Using MAY allows both without > breaking any > thing. > > -Ayman > > > [T.6] 2.3 iSCSI Session Types > > > > b) Discovery-session - a session opened only for > target discov- > > ery; the target MAY accept only text requests with > the SendTar- > > gets key and a logout request with reason "close the session". > > > > Change "MAY" to "MUST", and say that other requests MUST be > rejected. > > > From owner-ips@ece.cmu.edu Mon Jul 8 10:51:57 2002 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA17711 for ; Mon, 8 Jul 2002 10:51:57 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id g68EFMV07881 for ips-outgoing; Mon, 8 Jul 2002 10:15:22 -0400 (EDT) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from mailhub.lss.emc.com (xdch.emc.com [168.159.1.79]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id g68EFLX07877 for ; Mon, 8 Jul 2002 10:15:21 -0400 (EDT) Received: from emc.com (emcmail.lss.emc.com [168.159.48.78]) by mailhub.lss.emc.com (Switch-2.2.0/Switch-2.2.0) with ESMTP id g68EFC511319; Mon, 8 Jul 2002 10:15:13 -0400 (EDT) Received: from mxic1.isus.emc.com ([168.159.129.100]) by emc.com (8.10.1/8.10.1) with ESMTP id g68EFB716085; Mon, 8 Jul 2002 10:15:11 -0400 (EDT) Received: by MXIC1 with Internet Mail Service (5.5.2653.19) id <31WABX45>; Mon, 8 Jul 2002 10:13:15 -0400 Message-ID: <277DD60FB639D511AC0400B0D068B71E0564C038@CORPMX14> From: Black_David@emc.com To: rod.harrison@windriver.com, ips@ece.cmu.edu Subject: RE: iSCSI: DLB's [T.37] 11.12 ImmediateData Date: Mon, 8 Jul 2002 10:13:13 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" X-Perlmx-Spam: Gauge=XIIIIII, Probability=16%, Report="NO_REAL_NAME" Sender: owner-ips@ece.cmu.edu Precedence: bulk > I believe the MAY is to allow the initiator to send no unsolicited > data if it so chooses. For non-immediate unsolicited the rule was the > initiator MUST send all of the unsolicited data possible, or no > unsolicited data. The presence of the F bit in the latter case removes > the possibility of any confusion over the amount of unsolicited data > at the target. Yes, you're correct. Adding a "MUST send all of the unsolicited data possible" statement and leaving the "MAY"s as they are would take care of this. 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 --------------------------------------------------- From owner-ips@ece.cmu.edu Mon Jul 8 10:53:01 2002 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA17752 for ; Mon, 8 Jul 2002 10:52:56 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id g68EaIL08959 for ips-outgoing; Mon, 8 Jul 2002 10:36:18 -0400 (EDT) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from mxic2.corp.emc.com (mxic2.isus.emc.com [128.221.31.40]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id g68EaGX08945 for ; Mon, 8 Jul 2002 10:36:16 -0400 (EDT) Received: by mxic2.corp.emc.com with Internet Mail Service (5.5.2653.19) id <31X636A9>; Mon, 8 Jul 2002 10:36:02 -0400 Message-ID: <277DD60FB639D511AC0400B0D068B71E0564C03B@CORPMX14> From: Black_David@emc.com To: tom@arcot.com Cc: ips@ece.cmu.edu Subject: RE: IPS security draft: SRP groups Date: Mon, 8 Jul 2002 10:34:03 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-ips@ece.cmu.edu Precedence: bulk MANY THANKS -- Tom's earned his promised 30 minutes of fame ... although those 30 minutes may come at the ipr BOF in Yokohama on Friday :-) :-). For the security draft, specifying one of the acceptable generators from Tom's lists for each of the IKE groups and noting that the primes from the SRP distribution were probabilistically generated should be sufficient ... but there's still 30 minute of fame available for someone who tackles proving that the SRP primes are prime, as there is significant IETF interest in SRP outside of iSCSI - any takers? Thanks, --David > -----Original Message----- > From: Tom Wu [mailto:tom@arcot.com] > Sent: Monday, July 08, 2002 12:23 AM > To: Black_David@emc.com > Cc: ips@ece.cmu.edu > Subject: Re: IPS security draft: SRP groups > > > David, > > I'll tackle the SRP generator issue: > > For the Oakley Group 2 (1024 bit prime) defined in RFC2412: > Primitive roots (acceptable as SRP generators): > 5,11,13,19,29,31 > Subgroup generators (NOT acceptable): > 2,3,7,17,23 > > (MODP moduli taken from draft-ietf-ipsec-ike-modp-groups-04.txt) > For the 1536-bit MODP group: > Acceptable generators: > 31 > NOT acceptable generators: > 2,3,5,7,11,13,17,19,23,29 > > For the 2048-bit MODP group: > Acceptable generators: > 11,13,17,23,29,31 > NOT acceptable generators: > 2,3,5,7,19 > > For the 3072-bit MODP group: > Acceptable generators: > 5,7,17,23,31 > NOT acceptable generators: > 2,3,11,13,19,29 > > For the 4096-bit MODP group: > Acceptable generators: > 5,13,29,31 > NOT acceptable generators: > 2,3,7,11,17,19,23 > > For the 6144-bit MODP group: > Acceptable generators: > 5,11,13,17,23,29 > NOT acceptable generators: > 2,3,7,19,31 > > For the 8192-bit MODP group: > Acceptable generators: > 19,23,29,31 > NOT acceptable generators: > 2,3,5,7,11,13,17 > > All the above generators are in base 10 (decimal). > > As far as proving the primality of the SRP moduli, that > should be done > by someone with more expertise in the area. I should point out that > those moduli are also "safe primes", i.e. both N and (N-1)/2 > are prime, > so it is easy to find generators for them, and I chose > numbers that had > 2 as safe SRP generators. > > Tom > > Black_David@emc.com wrote: > > Missed this earlier, sorry ... > > > > > >>Ok. I didn't know that but I probably would have learned > it if I had > >>done the necessary reading about groups and generators. > But the point > >>of my question wasn't "is it possible to compute g" but rather "how > >>about supplying g in the spec" (since the g=2 from IKE is not > >>appropriate). It seems a bit redundant for everyone to repeat the > >>search for a suitable g... > >> > >>So what's the story about unlisted groups? Is an > implementation that > >>accepts only the groups listed in appendix A, but not any "locally > >>generated" ones, a compliant implementation? > >> > > > > Yes - accepting those groups and only those groups is the minimum > > (MUST) requirement. If the IKE groups are to remain allowed, we > > need to specify generators for their use with SRP - please consider > > this to be a serious *PLEA* for someone to volunteer to do the > > crpto-theoretic number crunching needed to find SRP generators for > > those groups and/or prove the primality of the SRP primes. Lack of > > progress here has the potential to hold up the security draft on > > which *all* of our protocol drafts depend (normative references). > > We can promise at least 30 minutes of fame (*twice* the proverbial > > 15 ;-) ) to those who resolve this issue ... > > > > 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 > > --------------------------------------------------- > > > -- > Tom Wu > Principal Software Engineer > Arcot Systems > (408) 969-6124 > "The Borg? Sounds Swedish..." > From owner-ips@ece.cmu.edu Mon Jul 8 12:26:30 2002 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA23059 for ; Mon, 8 Jul 2002 12:26:25 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id g68FsFT13290 for ips-outgoing; Mon, 8 Jul 2002 11:54:15 -0400 (EDT) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from dogwood.cisco.com (dogwood.cisco.com [161.44.11.19]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id g68FsDX13284 for ; Mon, 8 Jul 2002 11:54:13 -0400 (EDT) Received: from aghanemw2k (dhcp-161-44-68-161.cisco.com [161.44.68.161]) by dogwood.cisco.com (8.8.6 (PHNE_14041)/CISCO.SERVER.1.2) with SMTP id LAA01866; Mon, 8 Jul 2002 11:53:45 -0400 (EDT) From: "Ayman Ghanem" To: , Subject: RE: iSCSI: DLB's [T.6] 2.3 iSCSI Session Types Date: Mon, 8 Jul 2002 10:53:45 -0500 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0) X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2919.6700 Importance: Normal In-Reply-To: <277DD60FB639D511AC0400B0D068B71E0564C039@CORPMX14> Sender: owner-ips@ece.cmu.edu Precedence: bulk Content-Transfer-Encoding: 7bit David, The issue that came up before was if a discovery session could be kept open, why not allow the initiator and target to send NOPs, and allow the target to send Async messages when new targets become available? I don't mean to bring up this issue again at this stage, but using "MAY" leaves room for implementations that want to support this. If we allow NOP and Async PDUs on a discovery session, then changing "MAY" to "MUST" will be fine. -Ayman > -----Original Message----- > From: Black_David@emc.com [mailto:Black_David@emc.com] > Sent: Monday, July 08, 2002 9:19 AM > To: aghanem@cisco.com; ips@ece.cmu.edu > Subject: RE: iSCSI: DLB's [T.6] 2.3 iSCSI Session Types > > > Ayman, > > Something needs to be cleaned up here, as the current text appears > to allow all types of iSCSI PDUs on a discovery session. I didn't > intend to restrict a discovery session to one Send Targets followed > by a logout (i.e., it could be kept open with the initiator periodically > sending a new Send Targets to see if anything has changed), but I > did intend to forbid SCSI commands, task management, etc. on Discovery > sessions. Is that reasonable, or are there additional types of iSCSI > PDUs that you want to see allowed for new device notifications? > > Thanks, > --David > > > -----Original Message----- > > From: Ayman Ghanem [mailto:aghanem@cisco.com] > > Sent: Sunday, July 07, 2002 12:41 PM > > To: ips@ece.cmu.edu > > Subject: RE: iSCSI: DLB's [T.6] 2.3 iSCSI Session Types > > > > > > I prefer leaving this as "MAY" for implementations that want > > to support new > > device notifications. There was a discussion on whether > > discovery sessions > > should be long-lived or not. Using MAY allows both without > > breaking any > > thing. > > > > -Ayman > > > > > [T.6] 2.3 iSCSI Session Types > > > > > > b) Discovery-session - a session opened only for > > target discov- > > > ery; the target MAY accept only text requests with > > the SendTar- > > > gets key and a logout request with reason "close the session". > > > > > > Change "MAY" to "MUST", and say that other requests MUST be > > rejected. > > > > > > From owner-ips@ece.cmu.edu Mon Jul 8 12:28:20 2002 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA23152 for ; Mon, 8 Jul 2002 12:28:19 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id g68FfwT12454 for ips-outgoing; Mon, 8 Jul 2002 11:41:58 -0400 (EDT) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from e21.nc.us.ibm.com (e21.nc.us.ibm.com [32.97.136.227]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id g68FftX12446 for ; Mon, 8 Jul 2002 11:41:55 -0400 (EDT) Received: from westrelay04.boulder.ibm.com (westrelay04.boulder.ibm.com [9.17.192.94]) by e21.nc.us.ibm.com (8.12.2/8.12.2) with ESMTP id g68FfsRY018172; Mon, 8 Jul 2002 11:41:55 -0400 Received: from d03nmar1.almaden.ibm.com (d03nmar1.almaden.ibm.com [9.1.20.239]) by westrelay04.boulder.ibm.com (8.11.1m3/NCO/VER6.2) with ESMTP id g68Fevf34068; Mon, 8 Jul 2002 09:40:57 -0600 Importance: Normal To: Black_David@emc.com Cc: ips@ece.cmu.edu Subject: Re: iSCSI: DLB's Comment on SCSI Port Names X-Mailer: Lotus Notes Release 5.0.3 (Intl) 21 March 2000 Message-ID: From: "Jim Hafner" Date: Mon, 8 Jul 2002 08:42:16 -0700 X-MIMETrack: Serialize by Router on D03NMAR1/03/M/IBM(Build M13TT_06262002 Pre-release 2|June 26, 2002) at 07/08/2002 08:42:17, Serialize complete at 07/08/2002 08:42:17 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="=_alternative 00562B3C88256BF0_=" Sender: owner-ips@ece.cmu.edu Precedence: bulk This is a multipart message in MIME format. --=_alternative 00562B3C88256BF0_= Content-Type: text/plain; charset="us-ascii" David, You wrote: >[T.9] 2.4.2 SCSI Architecture Model > > The SCSI Port Name is mandatory in iSCSI. When used in SCSI > parameter data, the SCSI port name MUST be encoded as: > - The iSCSI Name in UTF-8 format, followed by > - a comma separator (1 byte), followed by > - the ASCII character 'i' (for SCSI Initiator Port) or the > ASCII character 't' (for SCSI Target Port), followed by > - a comma separator (1 byte), followed by > - zero to 3 null pad bytes so that the complete format is a > multiple of four bytes long, followed by > - the 6byte value of the ISID (for SCSI initiator port) or the > 2byte value of the portal group tag (for SCSI target port) in > network byte order (BigEndian). > That's a peculiar format with padding nulls in the middle and > a number concatenated after the padding - for example, it can't > be passed in iSCSI login without format conversion. How about > converting the number to 4 or 12 bytes of hex (ASCII characters) > and moving the padding to the end so the result is actually a > string, and excluding the padding from the definition of the name? > This will increase the maximum length of port names, but produce > names that are easier to deal with. Admittedly that's an odd format, however here was the reason for this layout. 1) it's not used directly in iSCSI "Text" strings; it's intended to be a description of how this information is packed into a byte array for representation in "SCSI parameter data" (as it says!) -- that is, it's NEVER "passed in iSCSI login" (in this form). 2) the padding after the string was to force the binary values of the ISID or PGT to be better word aligned and can be more easily extracted as a value direct from the byte array without conversion. What do you think? Jim Hafner --=_alternative 00562B3C88256BF0_= Content-Type: text/html; charset="us-ascii"
David,

You wrote:

>[T.9] 2.4.2  SCSI Architecture Model
>
>  The SCSI Port Name is mandatory in iSCSI. When used in SCSI
>  parameter data, the SCSI port name MUST be encoded as:
>  - The iSCSI Name in UTF-8 format, followed by
>  - a comma separator (1 byte), followed by
>  - the ASCII character 'i' (for SCSI Initiator Port) or the
>    ASCII character 't' (for SCSI Target Port), followed by
>  - a comma separator (1 byte), followed by
>  - zero to 3 null pad bytes so that the complete format is a
>    multiple of four bytes long, followed by
>  - the 6byte value of the ISID (for SCSI initiator port) or the
>    2byte value of the portal group tag (for SCSI target port) in
>    network byte order (BigEndian).

> That's a peculiar format with padding nulls in the middle and
> a number concatenated after the padding - for example, it can't
> be passed in iSCSI login without format conversion.  How about
> converting the number to 4 or 12 bytes of hex (ASCII characters)
> and moving the padding to the end so the result is actually a
> string, and excluding the padding from the definition of the name?
> This will increase the maximum length of port names, but produce
> names that are easier to deal with.

Admittedly that's an odd format, however here was the reason for this layout.
1) it's not used directly in iSCSI "Text" strings; it's intended to be a description of how this information is packed into a byte array for representation in "SCSI parameter data" (as it says!) -- that is, it's NEVER "passed in iSCSI login" (in this form).
2) the padding after the string was to force the binary values of the ISID or PGT to be better word aligned and can be more easily extracted as a value direct from the byte array without conversion.

What do you think?

Jim Hafner --=_alternative 00562B3C88256BF0_=-- From owner-ips@ece.cmu.edu Mon Jul 8 12:29:18 2002 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA23214 for ; Mon, 8 Jul 2002 12:29:18 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id g68G4vM13970 for ips-outgoing; Mon, 8 Jul 2002 12:04:57 -0400 (EDT) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from sj-msg-core-1.cisco.com (sj-msg-core-1.cisco.com [171.71.163.11]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id g68G4tX13965 for ; Mon, 8 Jul 2002 12:04:55 -0400 (EDT) Received: from nisser.cisco.com (nisser.cisco.com [171.71.176.85]) by sj-msg-core-1.cisco.com (8.12.2/8.12.2) with ESMTP id g68G4k39006107; Mon, 8 Jul 2002 09:04:46 -0700 (PDT) Received: from cisco.com (mbakke@mbakke-lnx.cisco.com [161.44.68.87]) by nisser.cisco.com (8.8.6 (PHNE_14041)/CISCO.SERVER.1.2) with ESMTP id JAA01657; Mon, 8 Jul 2002 09:04:45 -0700 (PDT) Message-ID: <3D29BC42.25129DA4@cisco.com> Date: Mon, 08 Jul 2002 11:22:26 -0500 From: Mark Bakke X-Mailer: Mozilla 4.72 [en] (X11; U; Linux 2.2.16-3.uid32 i686) X-Accept-Language: en, de MIME-Version: 1.0 To: Ayman Ghanem CC: Black_David@emc.com, ips@ece.cmu.edu Subject: Re: iSCSI: DLB's [T.6] 2.3 iSCSI Session Types References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ips@ece.cmu.edu Precedence: bulk Content-Transfer-Encoding: 7bit We could certainly disallow SCSI commands and task management on discovery sessions, as David suggested. Perhaps that's enough. -- Mark Ayman Ghanem wrote: > > David, > > The issue that came up before was if a discovery session could be kept open, > why not allow the initiator and target to send NOPs, and allow the target to > send Async messages when new targets become available? > > I don't mean to bring up this issue again at this stage, but using "MAY" > leaves room for implementations that want to support this. If we allow NOP > and Async PDUs on a discovery session, then changing "MAY" to "MUST" will be > fine. > > -Ayman > > > -----Original Message----- > > From: Black_David@emc.com [mailto:Black_David@emc.com] > > Sent: Monday, July 08, 2002 9:19 AM > > To: aghanem@cisco.com; ips@ece.cmu.edu > > Subject: RE: iSCSI: DLB's [T.6] 2.3 iSCSI Session Types > > > > > > Ayman, > > > > Something needs to be cleaned up here, as the current text appears > > to allow all types of iSCSI PDUs on a discovery session. I didn't > > intend to restrict a discovery session to one Send Targets followed > > by a logout (i.e., it could be kept open with the initiator periodically > > sending a new Send Targets to see if anything has changed), but I > > did intend to forbid SCSI commands, task management, etc. on Discovery > > sessions. Is that reasonable, or are there additional types of iSCSI > > PDUs that you want to see allowed for new device notifications? > > > > Thanks, > > --David > > > > > -----Original Message----- > > > From: Ayman Ghanem [mailto:aghanem@cisco.com] > > > Sent: Sunday, July 07, 2002 12:41 PM > > > To: ips@ece.cmu.edu > > > Subject: RE: iSCSI: DLB's [T.6] 2.3 iSCSI Session Types > > > > > > > > > I prefer leaving this as "MAY" for implementations that want > > > to support new > > > device notifications. There was a discussion on whether > > > discovery sessions > > > should be long-lived or not. Using MAY allows both without > > > breaking any > > > thing. > > > > > > -Ayman > > > > > > > [T.6] 2.3 iSCSI Session Types > > > > > > > > b) Discovery-session - a session opened only for > > > target discov- > > > > ery; the target MAY accept only text requests with > > > the SendTar- > > > > gets key and a logout request with reason "close the session". > > > > > > > > Change "MAY" to "MUST", and say that other requests MUST be > > > rejected. > > > > > > > > > -- Mark A. Bakke Cisco Systems mbakke@cisco.com 763.398.1054 From owner-ips@ece.cmu.edu Mon Jul 8 12:30:07 2002 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA23235 for ; Mon, 8 Jul 2002 12:30:02 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id g68Fn9l12964 for ips-outgoing; Mon, 8 Jul 2002 11:49:09 -0400 (EDT) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from mxic2.corp.emc.com (mxic2.isus.emc.com [128.221.31.40]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id g68Fn8X12957 for ; Mon, 8 Jul 2002 11:49:08 -0400 (EDT) Received: by mxic2.corp.emc.com with Internet Mail Service (5.5.2653.19) id <31X6PAZY>; Mon, 8 Jul 2002 11:48:59 -0400 Message-ID: <277DD60FB639D511AC0400B0D068B71E0564C040@CORPMX14> From: Black_David@emc.com To: hafner@almaden.ibm.com Cc: ips@ece.cmu.edu Subject: RE: iSCSI: DLB's Comment on SCSI Port Names Date: Mon, 8 Jul 2002 11:47:01 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-ips@ece.cmu.edu Precedence: bulk Jim, My view of this is that either: - The SCSI Port Name is never going to be used, in which case it shouldn't be designed to this level of detail. OR - It's going to be used, and hence is worth designing in a fashion that is reasonable to use. I think we're in the second category, and turning the ISID into hex ASCII (well, UTF-8) so the SCSI port name is a string is worth doing now to avoid problems when people actually try to use it. I would have no problems if someone wanted to pad the string, but I'd make specifying the padding the responsibility of the protocol/API/situation in which it was used rather than incorporating the padding into the name. Thanks, --David -----Original Message----- From: Jim Hafner [mailto:hafner@almaden.ibm.com] Sent: Monday, July 08, 2002 11:42 AM To: Black_David@emc.com Cc: ips@ece.cmu.edu Subject: Re: iSCSI: DLB's Comment on SCSI Port Names David, You wrote: >[T.9] 2.4.2 SCSI Architecture Model > > The SCSI Port Name is mandatory in iSCSI. When used in SCSI > parameter data, the SCSI port name MUST be encoded as: > - The iSCSI Name in UTF-8 format, followed by > - a comma separator (1 byte), followed by > - the ASCII character 'i' (for SCSI Initiator Port) or the > ASCII character 't' (for SCSI Target Port), followed by > - a comma separator (1 byte), followed by > - zero to 3 null pad bytes so that the complete format is a > multiple of four bytes long, followed by > - the 6byte value of the ISID (for SCSI initiator port) or the > 2byte value of the portal group tag (for SCSI target port) in > network byte order (BigEndian). > That's a peculiar format with padding nulls in the middle and > a number concatenated after the padding - for example, it can't > be passed in iSCSI login without format conversion. How about > converting the number to 4 or 12 bytes of hex (ASCII characters) > and moving the padding to the end so the result is actually a > string, and excluding the padding from the definition of the name? > This will increase the maximum length of port names, but produce > names that are easier to deal with. Admittedly that's an odd format, however here was the reason for this layout. 1) it's not used directly in iSCSI "Text" strings; it's intended to be a description of how this information is packed into a byte array for representation in "SCSI parameter data" (as it says!) -- that is, it's NEVER "passed in iSCSI login" (in this form). 2) the padding after the string was to force the binary values of the ISID or PGT to be better word aligned and can be more easily extracted as a value direct from the byte array without conversion. What do you think? Jim Hafner From owner-ips@ece.cmu.edu Mon Jul 8 12:36:04 2002 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA23572 for ; Mon, 8 Jul 2002 12:35:59 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id g68G88w14132 for ips-outgoing; Mon, 8 Jul 2002 12:08:08 -0400 (EDT) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from e1.ny.us.ibm.com (e1.ny.us.ibm.com [32.97.182.101]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id g68G86X14127 for ; Mon, 8 Jul 2002 12:08:06 -0400 (EDT) Received: from westrelay04.boulder.ibm.com (westrelay04.boulder.ibm.com [9.17.192.94]) by e1.ny.us.ibm.com (8.12.2/8.12.2) with ESMTP id g68G7xg5250184; Mon, 8 Jul 2002 12:07:59 -0400 Received: from d03nmar1.almaden.ibm.com (d03nmar1.almaden.ibm.com [9.1.20.239]) by westrelay04.boulder.ibm.com (8.11.1m3/NCO/VER6.2) with ESMTP id g68G77f34146; Mon, 8 Jul 2002 10:07:07 -0600 Importance: Normal To: Black_David@emc.com Cc: ips@ece.cmu.edu Subject: RE: iSCSI: DLB's Comment on SCSI Port Names X-Mailer: Lotus Notes Release 5.0.3 (Intl) 21 March 2000 Message-ID: From: "Jim Hafner" Date: Mon, 8 Jul 2002 09:08:26 -0700 X-MIMETrack: Serialize by Router on D03NMAR1/03/M/IBM(Build M13TT_06262002 Pre-release 2|June 26, 2002) at 07/08/2002 09:08:27, Serialize complete at 07/08/2002 09:08:27 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="=_alternative 005890AB88256BF0_=" Sender: owner-ips@ece.cmu.edu Precedence: bulk This is a multipart message in MIME format. --=_alternative 005890AB88256BF0_= Content-Type: text/plain; charset="us-ascii" David, I believe it will (may?) be used, so I agree we're in the second case. However, this format is the intended use in SCSI protocol stuff. Two places where SCSI ports names are used now is in ALIAS, Access Controls and in third party reservations -- see caveat below, however) I don't see a need in this context to define these as strings (that's not a SCSI way of thinking...). However, I think the issue comes down to a simple question: are the ISID and TPGT values or numerical strings (Julian is calling them numerical strings, but I've always thought of them as values, in spite of the fact that there is no arithmetic done on them - there is precedent in SCSI for such thinking, so I'm not completely out in the woods here). If they are values, then I'd like to see them formatted for SCSI in "value form"; if they are strings, then any representation should be OK. Does that at least get to the core of the issue? Jim Hafner CAVEAT: I don't think we'd use the iSCSI constructed port names in those contexts as device names are better suited for those purposes, but these are examples where specification of SCSI port name format is required. To: Jim Hafner/Almaden/IBM@IBMUS cc: ips@ece.cmu.edu Subject: RE: iSCSI: DLB's Comment on SCSI Port Names Jim, My view of this is that either: - The SCSI Port Name is never going to be used, in which case it shouldn't be designed to this level of detail. OR - It's going to be used, and hence is worth designing in a fashion that is reasonable to use. I think we're in the second category, and turning the ISID into hex ASCII (well, UTF-8) so the SCSI port name is a string is worth doing now to avoid problems when people actually try to use it. I would have no problems if someone wanted to pad the string, but I'd make specifying the padding the responsibility of the protocol/API/situation in which it was used rather than incorporating the padding into the name. Thanks, --David -----Original Message----- From: Jim Hafner [mailto:hafner@almaden.ibm.com] Sent: Monday, July 08, 2002 11:42 AM To: Black_David@emc.com Cc: ips@ece.cmu.edu Subject: Re: iSCSI: DLB's Comment on SCSI Port Names David, You wrote: >[T.9] 2.4.2 SCSI Architecture Model > > The SCSI Port Name is mandatory in iSCSI. When used in SCSI > parameter data, the SCSI port name MUST be encoded as: > - The iSCSI Name in UTF-8 format, followed by > - a comma separator (1 byte), followed by > - the ASCII character 'i' (for SCSI Initiator Port) or the > ASCII character 't' (for SCSI Target Port), followed by > - a comma separator (1 byte), followed by > - zero to 3 null pad bytes so that the complete format is a > multiple of four bytes long, followed by > - the 6byte value of the ISID (for SCSI initiator port) or the > 2byte value of the portal group tag (for SCSI target port) in > network byte order (BigEndian). > That's a peculiar format with padding nulls in the middle and > a number concatenated after the padding - for example, it can't > be passed in iSCSI login without format conversion. How about > converting the number to 4 or 12 bytes of hex (ASCII characters) > and moving the padding to the end so the result is actually a > string, and excluding the padding from the definition of the name? > This will increase the maximum length of port names, but produce > names that are easier to deal with. Admittedly that's an odd format, however here was the reason for this layout. 1) it's not used directly in iSCSI "Text" strings; it's intended to be a description of how this information is packed into a byte array for representation in "SCSI parameter data" (as it says!) -- that is, it's NEVER "passed in iSCSI login" (in this form). 2) the padding after the string was to force the binary values of the ISID or PGT to be better word aligned and can be more easily extracted as a value direct from the byte array without conversion. What do you think? Jim Hafner --=_alternative 005890AB88256BF0_= Content-Type: text/html; charset="us-ascii"
David,

I believe it will (may?) be used, so I agree we're in the second case.  However, this format is the intended use in SCSI protocol stuff.  Two places where SCSI ports names are used now is in ALIAS, Access Controls and in third party reservations -- see caveat below, however)

I don't see a need in this context to define these as strings (that's not a SCSI way of thinking...).  

However, I think the issue comes down to a simple question:  are the ISID and TPGT values or numerical strings (Julian is calling them numerical strings, but I've always thought of them as values, in spite of the fact that there is no arithmetic done on them - there is precedent in SCSI for such thinking, so I'm not completely out in the woods here).

If they are values, then I'd like to see them formatted for SCSI in "value form";  if they are strings, then any representation should be OK.

Does that at least get to the core of the issue?

Jim Hafner
CAVEAT: I don't think we'd use the iSCSI constructed port names in those contexts as device names are better suited for those purposes, but these are examples where specification of SCSI port name format is required.

To:        Jim Hafner/Almaden/IBM@IBMUS
cc:        ips@ece.cmu.edu
Subject:        RE: iSCSI: DLB's Comment on SCSI Port Names



Jim,
My view of this is that either:
- The SCSI Port Name is never going to be used, in which case
it shouldn't be designed to this level of detail. OR
- It's going to be used, and hence is worth designing in a fashion
that is reasonable to use.
I think we're in the second category, and turning the ISID into
hex ASCII (well, UTF-8) so the SCSI port name is a string is
worth doing now to avoid problems when people actually try
to use it.  I would have no problems if someone wanted to
pad the string, but I'd make specifying the padding the
responsibility of the protocol/API/situation in which it
was used rather than incorporating the padding into the name.
Thanks,
--David
-----Original Message-----
From: Jim Hafner [mailto:hafner@almaden.ibm.com]
Sent: Monday, July 08, 2002 11:42 AM
To: Black_David@emc.com
Cc: ips@ece.cmu.edu
Subject: Re: iSCSI: DLB's Comment on SCSI Port Names


David,
You wrote:
>[T.9] 2.4.2  SCSI Architecture Model
>
>  The SCSI Port Name is mandatory in iSCSI. When used in SCSI
>  parameter data, the SCSI port name MUST be encoded as:
>  - The iSCSI Name in UTF-8 format, followed by
>  - a comma separator (1 byte), followed by
>  - the ASCII character 'i' (for SCSI Initiator Port) or the
>    ASCII character 't' (for SCSI Target Port), followed by
>  - a comma separator (1 byte), followed by
>  - zero to 3 null pad bytes so that the complete format is a
>    multiple of four bytes long, followed by
>  - the 6byte value of the ISID (for SCSI initiator port) or the
>    2byte value of the portal group tag (for SCSI target port) in
>    network byte order (BigEndian).
> That's a peculiar format with padding nulls in the middle and
> a number concatenated after the padding - for example, it can't
> be passed in iSCSI login without format conversion.  How about
> converting the number to 4 or 12 bytes of hex (ASCII characters)
> and moving the padding to the end so the result is actually a
> string, and excluding the padding from the definition of the name?
> This will increase the maximum length of port names, but produce
> names that are easier to deal with.
Admittedly that's an odd format, however here was the reason for this
layout.
1) it's not used directly in iSCSI "Text" strings; it's intended to be a
description of how this information is packed into a byte array for
representation in "SCSI parameter data" (as it says!) -- that is, it's NEVER
"passed in iSCSI login" (in this form).
2) the padding after the string was to force the binary values of the ISID
or PGT to be better word aligned and can be more easily extracted as a value
direct from the byte array without conversion.
What do you think?
Jim Hafner

--=_alternative 005890AB88256BF0_=-- From owner-ips@ece.cmu.edu Mon Jul 8 13:33:51 2002 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA26793 for ; Mon, 8 Jul 2002 13:33:51 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id g68Gt9e17141 for ips-outgoing; Mon, 8 Jul 2002 12:55:09 -0400 (EDT) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from d12lmsgate-3.de.ibm.com (d12lmsgate-3.de.ibm.com [195.212.91.201]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id g68Gt7X17137 for ; Mon, 8 Jul 2002 12:55:07 -0400 (EDT) Received: from d12relay02.de.ibm.com (d12relay02.de.ibm.com [9.165.215.23]) by d12lmsgate-3.de.ibm.com (8.12.3/8.12.3) with ESMTP id g68Gsx2F027186; Mon, 8 Jul 2002 18:55:00 +0200 Received: from d10hubm1.telaviv.ibm.com (d10ml001.telaviv.ibm.com [9.148.216.55]) by d12relay02.de.ibm.com (8.11.1m3/NCO/VER6.2) with ESMTP id g68GswZ133758; Mon, 8 Jul 2002 18:54:58 +0200 Importance: Normal Subject: RE: iSCSI: DLB's [T.33] 10.5 Challenge Handshake Authentication Protocol (CHAP) To: Black_David@emc.com Cc: rod.harrison@windriver.com, ips@ece.cmu.edu X-Mailer: Lotus Notes Release 5.0.7 March 21, 2001 Message-ID: From: "Ofer Biran" Date: Mon, 8 Jul 2002 19:53:59 +0300 X-MIMETrack: Serialize by Router on D10ML001/10/M/IBM(Release 5.0.9a |January 7, 2002) at 08/07/2002 19:54:58 MIME-Version: 1.0 Content-type: text/plain; charset=us-ascii Sender: owner-ips@ece.cmu.edu Precedence: bulk David, >There's a related problem here in that the encoding of the values of the >CHAP_A key are not specified - the quickest way out of this one would >be to have them be numbers and refer to the IANA registry from which the >numbers MUST be taken. 10.5 has "Where N, (A,A1,A2), I, C, and R are (correspondingly) the Name, Algorithm, Identifier, Challenge, and Response as defined in [RFC1994], N is a text string, A,A1,A2, and I are numbers..." And RFC1994 defines the Algorithm value (A,A1,A2 values of CHAP_A) : "The Algorithm field is one octet and indicates the authentication method to be used. Up-to-date values are specified in the most recent "Assigned Numbers" [2] " Regards, Ofer Ofer Biran Storage and Systems Technology IBM Research Lab in Haifa biran@il.ibm.com 972-4-8296253 From owner-ips@ece.cmu.edu Mon Jul 8 14:27:21 2002 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA29990 for ; Mon, 8 Jul 2002 14:27:21 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id g68I6eq22007 for ips-outgoing; Mon, 8 Jul 2002 14:06:40 -0400 (EDT) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from lion.ninthwonder.com (lion.ninthwonder.com [151.199.66.147]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id g68I6cX22002 for ; Mon, 8 Jul 2002 14:06:38 -0400 (EDT) Received: by lion.ninthwonder.com (Postfix, from userid 1021) id 3C87C30706; Mon, 8 Jul 2002 14:06:38 -0400 (EDT) Date: Mon, 8 Jul 2002 11:03:43 -0700 (PDT) From: Bill Studenmund X-X-Sender: To: Julian Satran Cc: Subject: Re: iSCSI - decimal coded binary strings - a proposed resolution In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ips@ece.cmu.edu Precedence: bulk On Mon, 8 Jul 2002, Julian Satran wrote: > Considering the widespread use of decimal encoding and the perceived > difficulty of mapping them to a binary string > - mainly due to the difficulty of matching lengths I suggest the > following: > > Decimal encoding for binary strings will be used only where the length of > the binary string is explicitly defined (by a constant or a rule that does > not use the encoding itself) This sounds like a good resolution of the problem. You've cleaned up the part I despised about using decimal numbers for binary strings - the fact that we want to derive the length from the number, which isn't so easy for them. :-) > The definition for decimal constant becomes: > > decimal-constant: an unsigned decimal number - the digit 0 or a string of > 1 or more digits starting with a non-zero digit. This encoding is not used > for numerical values equal or greater than 2**64. Decimal-constants are > used to encode numerical values or binary strings. Decimal constants can > be used to encode binary strings only if the stringlength is explicitly > specified. There is no implicit length for deci-mal strings. I think that'll be fine. Take care, Bill From owner-ips@ece.cmu.edu Mon Jul 8 14:27:55 2002 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA00048 for ; Mon, 8 Jul 2002 14:27:55 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id g68HcDm20039 for ips-outgoing; Mon, 8 Jul 2002 13:38:13 -0400 (EDT) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from palrel12.hp.com (palrel12.hp.com [156.153.255.237]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id g68HcBX20035 for ; Mon, 8 Jul 2002 13:38:11 -0400 (EDT) Received: from xparelay2.corp.hp.com (xparelay2.corp.hp.com [15.58.137.112]) by palrel12.hp.com (Postfix) with ESMTP id C71B7E006C5; Mon, 8 Jul 2002 10:38:05 -0700 (PDT) Received: from xpabh3.corp.hp.com (xpabh3.corp.hp.com [15.58.136.223]) by xparelay2.corp.hp.com (Postfix) with ESMTP id BF9E887; Mon, 8 Jul 2002 10:38:05 -0700 (PDT) Received: by xpabh3.corp.hp.com with Internet Mail Service (5.5.2655.55) id ; Mon, 8 Jul 2002 10:38:05 -0700 Message-ID: <6BD67FFB937FD411A04F00D0B74FE87805CCF6B7@xrose06.rose.hp.com> From: "KRUEGER,MARJORIE (HP-Roseville,ex1)" To: "'Black_David@emc.com'" , ips@ece.cmu.edu Subject: RE: Yokohama Agenda and status of drafts Date: Mon, 8 Jul 2002 10:38:01 -0700 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2655.55) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-ips@ece.cmu.edu Precedence: bulk David, Regarding: > draft-ietf-ips-iscsi-name-disc-06.txt > To become a proposed standard RFC. WG Last Call expected shortly > after Yokohama. We have moved all of the normative text regarding iSCSI name construction into the main iSCSI protocol draft and I believe the intent is that this draft should be informational. Thanks, Marjorie From owner-ips@ece.cmu.edu Mon Jul 8 15:22:50 2002 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA04196 for ; Mon, 8 Jul 2002 15:22:45 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id g68IUMP23612 for ips-outgoing; Mon, 8 Jul 2002 14:30:22 -0400 (EDT) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from d12lmsgate-3.de.ibm.com (d12lmsgate-3.de.ibm.com [195.212.91.201]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id g68IUHX23598; Mon, 8 Jul 2002 14:30:18 -0400 (EDT) Received: from d12relay02.de.ibm.com (d12relay02.de.ibm.com [9.165.215.23]) by d12lmsgate-3.de.ibm.com (8.12.3/8.12.3) with ESMTP id g68IUB2F021326; Mon, 8 Jul 2002 20:30:11 +0200 Received: from d10hubm1.telaviv.ibm.com (d10ml001.telaviv.ibm.com [9.148.216.55]) by d12relay02.de.ibm.com (8.11.1m3/NCO/VER6.2) with ESMTP id g68IU9Z86128; Mon, 8 Jul 2002 20:30:10 +0200 To: Black_David@emc.com Cc: ips@ece.cmu.edu, owner-ips@ece.cmu.edu, rod.harrison@windriver.com Importance: High MIME-Version: 1.0 Subject: RE: iSCSI: DLB's [T.37] 11.12 ImmediateData X-Mailer: Lotus Notes Release 5.0.9 November 16, 2001 From: "Julian Satran" Message-ID: Date: Mon, 8 Jul 2002 21:30:07 +0300 X-MIMETrack: Serialize by Router on D10ML001/10/M/IBM(Release 5.0.9a |January 7, 2002) at 08/07/2002 21:30:10, Serialize complete at 08/07/2002 21:30:10 Content-Type: multipart/alternative; boundary="=_alternative 0064A738C2256BF0_=" Sender: owner-ips@ece.cmu.edu Precedence: bulk This is a multipart message in MIME format. --=_alternative 0064A738C2256BF0_= Content-Type: text/plain; charset="us-ascii" But that statement already appears in 2.2.4 Why repeat it? Julo Black_David@emc.com Sent by: owner-ips@ece.cmu.edu 07/08/2002 05:13 PM Please respond to Black_David To: rod.harrison@windriver.com, ips@ece.cmu.edu cc: Subject: RE: iSCSI: DLB's [T.37] 11.12 ImmediateData > I believe the MAY is to allow the initiator to send no unsolicited > data if it so chooses. For non-immediate unsolicited the rule was the > initiator MUST send all of the unsolicited data possible, or no > unsolicited data. The presence of the F bit in the latter case removes > the possibility of any confusion over the amount of unsolicited data > at the target. Yes, you're correct. Adding a "MUST send all of the unsolicited data possible" statement and leaving the "MAY"s as they are would take care of this. 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 --------------------------------------------------- --=_alternative 0064A738C2256BF0_= Content-Type: text/html; charset="us-ascii"
But that statement already appears in 2.2.4  Why repeat it? Julo


Black_David@emc.com
Sent by: owner-ips@ece.cmu.edu

07/08/2002 05:13 PM
Please respond to Black_David

       
        To:        rod.harrison@windriver.com, ips@ece.cmu.edu
        cc:        
        Subject:        RE: iSCSI: DLB's [T.37] 11.12 ImmediateData

       


>                  I believe the MAY is to allow the initiator to send no unsolicited
> data if it so chooses. For non-immediate unsolicited the rule was the
> initiator MUST send all of the unsolicited data possible, or no
> unsolicited data. The presence of the F bit in the latter case removes
> the possibility of any confusion over the amount of unsolicited data
> at the target.

Yes, you're correct.  Adding a "MUST send all of the unsolicited
data possible" statement and leaving the "MAY"s as they are
would take care of this.

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

--=_alternative 0064A738C2256BF0_=-- From owner-ips@ece.cmu.edu Mon Jul 8 15:22:54 2002 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA04211 for ; Mon, 8 Jul 2002 15:22:54 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id g68IYtN23993 for ips-outgoing; Mon, 8 Jul 2002 14:34:55 -0400 (EDT) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from osmtp1.electric.net (osmtp1.electric.net [216.129.90.28]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id g68IYqX23988 for ; Mon, 8 Jul 2002 14:34:52 -0400 (EDT) Received: from [206.175.231.14] (helo=EGRodriguez) by osmtp1.electric.net with asmtp (Exim 3.22 #1) id 17RdLS-0000bY-04 for ips@ece.cmu.edu; Mon, 08 Jul 2002 11:34:49 -0700 From: "Elizabeth G. Rodriguez" To: Subject: IPS-ALL: iSCSI WG first last call is now complete. Date: Mon, 8 Jul 2002 13:31:36 -0600 Message-ID: <004c01c226b6$170e1f20$06ebafce@EGRodriguez> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_004D_01C22683.CC73AF20" X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.3416 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 Importance: Normal Sender: owner-ips@ece.cmu.edu Precedence: bulk This is a multi-part message in MIME format. ------=_NextPart_000_004D_01C22683.CC73AF20 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit All, The initial IPS WG last call is now complete. Our thanks to everyone for thorough review of the document and submission of comments against the draft. Everyone is probably wondering, "where do we go from here?" There were sufficient comments against the draft that a second WG last call will be needed. This was expected - it is rare for a document which has so many parties interested and of such size to make it thru the working group last call on the first pass. Julian Satran is now working on resolution of the comments to produce a new draft, version 15. His web site at http://www.haifa.il.ibm.com/satran/ips He has a working copy of the draft, with change bars (in pdf format), as well as a list of last call issues and proposed resolution. Version 15 of the draft will not be officially available until after Yokohoma, though Julian may have a completed version available for early review prior to that. Within a few days of the draft being officially posted, we will announce a second WG last call on the iSCSI draft. The last call period will again be two weeks. The focus of this second last call should be new changes to the draft. This second last call should hopefully go a lot smoother than this first one did. Technical issues that were brought up need to be discussed on the list, especially if there is disagreement with an issue or proposed resolution. So, I recommend that everyone examine the issues brought up to the list and speak up now if they have any input. Timeline for iSCSI: This week and next - discussion/resolution on issues brought up during WG last call. New draft officially available week of July 22, though preliminary draft may be available earlier. End week July 22/begin week July 29 - announce WG last call for iSCSI draft Two weeks later - iSCSI WG last call concludes Mid August - new official draft available, which includes comment resolution from WG last call. Assuming no major issues during second WG last call, this draft will be the version forwarded on to the ADs. Elizabeth Rodriguez & David Black, IPS WG co-chairs ------=_NextPart_000_004D_01C22683.CC73AF20 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

All,

 

The initial IPS WG last call is now = complete.

Our thanks to everyone for thorough review of the = document and submission of comments against the draft.

 

Everyone is probably wondering, “where do we go = from here?”

 

There were sufficient comments against the draft that = a second WG last call will be needed.

This was expected – it is rare for a document = which has so many parties interested and of such size to make it thru the = working group last call on the first pass.

 

Julian Satran is now working on resolution of the = comments to produce a new draft, version 15.

His web site at http://www.haifa.il.ibm.c= om/satran/ips

He has a working copy of the draft, with change bars = (in pdf format), as well as a list of last call issues and proposed = resolution.

Version 15 of the draft will not be officially = available until after Yokohoma, though Julian may have a completed version = available for early review prior to that.

Within a few days of the draft being officially = posted, we will announce a second WG last call on the iSCSI = draft.

The last call period will again be two weeks.  = The focus of this second last call should be new changes to the = draft.

This second last call should hopefully go a lot = smoother than this first one did.

 

Technical issues that were brought up need to be = discussed on the list, especially if there is disagreement with an issue or = proposed resolution.

So, I recommend that everyone examine the issues = brought up to the list and speak up now if they have any input.

 

Timeline for iSCSI:

 

This week and next – discussion/resolution on = issues brought up during WG last call.

New draft officially available week of July 22, = though preliminary draft may be available earlier.

End week July 22/begin week July 29 – announce = WG last call for iSCSI draft

Two weeks later – iSCSI WG last call = concludes

Mid August – new official draft available, = which includes comment resolution from WG last call.

Assuming no major issues during second WG last call, = this draft will be the version forwarded on to the ADs.

 

Elizabeth Rodriguez & David Black, =

IPS WG co-chairs

 

------=_NextPart_000_004D_01C22683.CC73AF20-- From owner-ips@ece.cmu.edu Mon Jul 8 16:10:55 2002 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA06533 for ; Mon, 8 Jul 2002 16:10:54 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id g68JaKC28475 for ips-outgoing; Mon, 8 Jul 2002 15:36:20 -0400 (EDT) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from cygnus.equallogic.com (cygnus.equallogic.com [65.170.102.10]) by ece.cmu.edu (8.11.0/8.10.2) with SMTP id g68JaHX28469 for ; Mon, 8 Jul 2002 15:36:17 -0400 (EDT) Received: from cygnus.equallogic.com (localhost.localdomain [127.0.0.1]) by cygnus.equallogic.com (8.11.6/8.11.6) with ESMTP id g68JaBC18704 for ; Mon, 8 Jul 2002 15:36:11 -0400 Received: from deneb.dev.equallogic.com (deneb.dev.equallogic.com [172.16.1.99]) by cygnus.equallogic.com (8.11.6/8.11.6) with ESMTP id g68JaBQ18695; Mon, 8 Jul 2002 15:36:11 -0400 Received: from pkoning.dev.equallogic.com.equallogic.com (localhost.localdomain [127.0.0.1]) by deneb.dev.equallogic.com (8.11.6/8.11.6) with SMTP id g68JaAe22131; Mon, 8 Jul 2002 15:36:10 -0400 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <15657.59818.618383.207522@pkoning.dev.equallogic.com> Date: Mon, 8 Jul 2002 15:36:10 -0400 From: Paul Koning To: Julian_Satran@il.ibm.com Cc: ips@ece.cmu.edu Subject: Re: iSCSI - decimal coded binary strings - a proposed resolution References: X-Mailer: VM 7.01 under 21.1 (patch 11) "Carlsbad Caverns" XEmacs Lucid Sender: owner-ips@ece.cmu.edu Precedence: bulk Content-Transfer-Encoding: 7bit >>>>> "Julian" == Julian Satran writes: Julian> Considering the widespread use of decimal encoding and the Julian> perceived difficulty of mapping them to a binary string - Julian> mainly due to the difficulty of matching lengths I suggest Julian> the following: Julian> Decimal encoding for binary strings will be used only where Julian> the length of the binary string is explicitly defined (by a Julian> constant or a rule that does not use the encoding itself) Julian> The definition for decimal constant becomes: Julian> decimal-constant: an unsigned decimal number - the digit 0 or Julian> a string of 1 or more digits starting with a non-zero Julian> digit. This encoding is not used for numerical values equal Julian> or greater than 2**64. Decimal-constants are used to encode Julian> numerical values or binary strings. Decimal constants can be Julian> used to encode binary strings only if the stringlength is Julian> explicitly specified. There is no implicit length for Julian> deci-mal strings. The point about "no implicitic length" certainly helps. I like David's suggestion (DLB's comments T.12) to disallow decimal for data items that are capable of being larger than 2**64 -- rather than tying it to whether the particular value being encoded happens to be bigger or smaller than 2*64. That way it essentially becomes a property of the data type, which seems like a logical way to go. Text to do that would be something like "This encoding is not used for parameters that may have a value >= 2**64" or alternatively "This encoding is used only with parameters whose largest permitted value is less than 2**64". paul From owner-ips@ece.cmu.edu Mon Jul 8 16:12:23 2002 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA06643 for ; Mon, 8 Jul 2002 16:12:23 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id g68JOOn27609 for ips-outgoing; Mon, 8 Jul 2002 15:24:24 -0400 (EDT) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from osmtp1.electric.net (osmtp1.electric.net [216.129.90.28]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id g68JOMX27605 for ; Mon, 8 Jul 2002 15:24:22 -0400 (EDT) Received: from [206.175.231.14] (helo=EGRodriguez) by osmtp1.electric.net with asmtp (Exim 3.22 #1) id 17Re7O-0005Pu-04 for ips@ece.cmu.edu; Mon, 08 Jul 2002 12:24:21 -0700 From: "Elizabeth G. Rodriguez" To: Subject: David Black and Elizabeth Rodriguez both on road this week and next Date: Mon, 8 Jul 2002 14:21:09 -0600 Message-ID: <005501c226bd$027ee420$06ebafce@EGRodriguez> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0056_01C2268A.B7E47420" X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.3416 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 Importance: Normal Sender: owner-ips@ece.cmu.edu Precedence: bulk This is a multi-part message in MIME format. ------=_NextPart_000_0056_01C2268A.B7E47420 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit All, Just wanted to send a quick note - Both David and I are on the road this week (in the US) and next week (in Yokohoma). We will have limited access to email, though will try to monitor on at least a daily basis. Thanks, Elizabeth ------=_NextPart_000_0056_01C2268A.B7E47420 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

All,

 

Just wanted to send a quick note – Both David = and I are on the road this week (in the US) and = next week (in Yokohoma).

We will have limited access to email, though will try = to monitor on at least a daily basis.

 

Thanks,

 

Elizabeth

 

------=_NextPart_000_0056_01C2268A.B7E47420-- From owner-ips@ece.cmu.edu Mon Jul 8 19:24:29 2002 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA16873 for ; Mon, 8 Jul 2002 19:24:28 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id g68Mfd810642 for ips-outgoing; Mon, 8 Jul 2002 18:41:39 -0400 (EDT) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from lion.ninthwonder.com (lion.ninthwonder.com [151.199.66.147]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id g68MfbX10637 for ; Mon, 8 Jul 2002 18:41:37 -0400 (EDT) Received: by lion.ninthwonder.com (Postfix, from userid 1021) id 0760830706; Mon, 8 Jul 2002 18:41:37 -0400 (EDT) Date: Mon, 8 Jul 2002 15:38:43 -0700 (PDT) From: Bill Studenmund X-X-Sender: To: "Julian Satran (Actcom)" Cc: Subject: Re: iSCSI: Decimal encoding - why 64 bits ? In-Reply-To: <005701c223d6$6a16ae40$0100000a@JA31> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ips@ece.cmu.edu Precedence: bulk On Fri, 5 Jul 2002, Julian Satran (Actcom) wrote: > I wonder how natural it will feel for somebody to have and IP address > encoded exclusively in hex, or a TargetPortalGroup appearing as decimal in a > directory and having to be transliterated. Well, we'll find out with IPv6 addresses, as the only representation of them I've seen is for them to be in hex. :-) As to TargetPortalGroup, why is it a binary string? Yes, you mentioned in another note that it has no ordering ("greater" and "lesser" don't make sense), so it's not a number like say ErrorRecoveryLevel (where ordering is important). But is its in-memory representation really important? Does it matter if a host represents the value from "TargetPortalGroupTag=1" internally as 00 01 (BE 16 bits) or 01 00 (LE 16 bits) or 00 00 00 01 (BE 32 bits) or 01 00 00 00 (LE 32 bits)? I don't think so. As long as the value is interpreted right (the initiator sends the right ascii representation, and the target ties an ascii representation to the right device) I really don't see how the internal representation matters. So thus I don't see why it's a binary string, as internal representation is the heart of a binary string. :-) Take care, Bill From owner-ips@ece.cmu.edu Mon Jul 8 21:56:21 2002 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA24590 for ; Mon, 8 Jul 2002 21:56:21 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id g691Mnr19226 for ips-outgoing; Mon, 8 Jul 2002 21:22:49 -0400 (EDT) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from palrel10.hp.com (palrel10.hp.com [156.153.255.245]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id g691MlX19222 for ; Mon, 8 Jul 2002 21:22:47 -0400 (EDT) Received: from xparelay1.corp.hp.com (xparelay1.corp.hp.com [15.58.136.173]) by palrel10.hp.com (Postfix) with ESMTP id B0770C0075F; Mon, 8 Jul 2002 18:22:46 -0700 (PDT) Received: from xpabh3.corp.hp.com (xpabh3.corp.hp.com [15.58.136.223]) by xparelay1.corp.hp.com (Postfix) with ESMTP id 6E401E000A2; Mon, 8 Jul 2002 18:22:46 -0700 (PDT) Received: by xpabh3.corp.hp.com with Internet Mail Service (5.5.2655.55) id ; Mon, 8 Jul 2002 18:22:46 -0700 Message-ID: <6BD67FFB937FD411A04F00D0B74FE87805CCF6BB@xrose06.rose.hp.com> From: "KRUEGER,MARJORIE (HP-Roseville,ex1)" To: "'Jim Hafner'" , "'Black_David@emc.com'" Cc: "'ips@ece.cmu.edu'" Subject: RE: iSCSI: DLB's Comment on SCSI Port Names Date: Mon, 8 Jul 2002 18:22:44 -0700 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2655.55) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C226E7.209EBCD0" Sender: owner-ips@ece.cmu.edu Precedence: bulk This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_001_01C226E7.209EBCD0 Content-Type: text/plain; charset="iso-8859-1" Correction - 244 characters max node name would provide for a 255 max port name = (244 char name + ",i," + "0x000000") (How did ISID get so big ;-) If strings over 256 characters are a problem for some platforms, I'd be in favor of reducing the max iSCSI node name to 249 characters so the maximum SCSI port name would be 255 characters total (249 char name + ",i," + "0x0000") ------_=_NextPart_001_01C226E7.209EBCD0 Content-Type: text/html; charset="iso-8859-1"
Correction - 244 characters max node name would provide for a 255 max port name = (244 char name + ",i," + "0x000000") (How did ISID get so big ;-)
If strings over 256 characters are a problem for some platforms, I'd be in favor of reducing the max iSCSI node name to 249 characters so the maximum SCSI port name would be 255 characters total (249 char name + ",i," + "0x0000")
 
 
------_=_NextPart_001_01C226E7.209EBCD0-- From owner-ips@ece.cmu.edu Mon Jul 8 21:56:58 2002 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA24637 for ; Mon, 8 Jul 2002 21:56:53 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id g6914Rv18289 for ips-outgoing; Mon, 8 Jul 2002 21:04:27 -0400 (EDT) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from atlrel6.hp.com (atlrel6.hp.com [156.153.255.205]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id g6914QX18285 for ; Mon, 8 Jul 2002 21:04:26 -0400 (EDT) Received: from xatlrelay1.atl.hp.com (xatlrelay1.atl.hp.com [15.45.89.190]) by atlrel6.hp.com (Postfix) with ESMTP id 4158A934; Mon, 8 Jul 2002 21:04:22 -0400 (EDT) Received: from xatlbh3.atl.hp.com (xatlbh3.atl.hp.com [15.45.89.188]) by xatlrelay1.atl.hp.com (Postfix) with ESMTP id 1A983129; Mon, 8 Jul 2002 21:04:22 -0400 (EDT) Received: by xatlbh3.atl.hp.com with Internet Mail Service (5.5.2655.55) id ; Mon, 8 Jul 2002 21:04:21 -0400 Message-ID: <6BD67FFB937FD411A04F00D0B74FE87805CCF6BA@xrose06.rose.hp.com> From: "KRUEGER,MARJORIE (HP-Roseville,ex1)" To: "'Jim Hafner'" , Black_David@emc.com Cc: ips@ece.cmu.edu Subject: RE: iSCSI: DLB's Comment on SCSI Port Names Date: Mon, 8 Jul 2002 21:04:18 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2655.55) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C226E4.8D779AA0" Sender: owner-ips@ece.cmu.edu Precedence: bulk This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_001_01C226E4.8D779AA0 Content-Type: text/plain; charset="iso-8859-1" I've just encountered this issue with regards to iSCSI port name encoding in the SCSI MIB, and the currently specified port name encoding causes inconvenience (at best). IMO, it makes sense to be able to treat an iSCSI name field, be it device name or port name, the same - as a string of display characters, portions of which may contain ASCII-encoded numeric values. I don't really see that it makes a difference whether one views ISID and TPGT as numeric strings or values, since as Jim says, there are no calculations performed using these things, and they are basicly just "tags". The issue for me is that the rest of the "SCSI port name" is a string and I see no value in "encoding" the ISID or TPGT as a value for SCSI purposes, as SCSI should have no need to use the ISID or TPGT values separately from the entire port name. And even if SCSI had such a need, it's a simple matter to convert a numeric string representation to a value. The downside of a string-encoding is the increased maximum size of the SCSI port name. If strings over 256 characters are a problem for some platforms, I'd be in favor of reducing the max iSCSI node name to 249 characters so the maximum SCSI port name would be 255 characters total (249 char name + ",i," + "0x0000") Marjorie Krueger Networked Storage Architecture Networked Storage Solutions Org. Hewlett-Packard -----Original Message----- From: Jim Hafner [mailto:hafner@almaden.ibm.com] Sent: Monday, July 08, 2002 9:08 AM To: Black_David@emc.com Cc: ips@ece.cmu.edu Subject: RE: iSCSI: DLB's Comment on SCSI Port Names David, I believe it will (may?) be used, so I agree we're in the second case. However, this format is the intended use in SCSI protocol stuff. Two places where SCSI ports names are used now is in ALIAS, Access Controls and in third party reservations -- see caveat below, however) I don't see a need in this context to define these as strings (that's not a SCSI way of thinking...). However, I think the issue comes down to a simple question: are the ISID and TPGT values or numerical strings (Julian is calling them numerical strings, but I've always thought of them as values, in spite of the fact that there is no arithmetic done on them - there is precedent in SCSI for such thinking, so I'm not completely out in the woods here). If they are values, then I'd like to see them formatted for SCSI in "value form"; if they are strings, then any representation should be OK. Does that at least get to the core of the issue? Jim Hafner CAVEAT: I don't think we'd use the iSCSI constructed port names in those contexts as device names are better suited for those purposes, but these are examples where specification of SCSI port name format is required. To: Jim Hafner/Almaden/IBM@IBMUS cc: ips@ece.cmu.edu Subject: RE: iSCSI: DLB's Comment on SCSI Port Names Jim, My view of this is that either: - The SCSI Port Name is never going to be used, in which case it shouldn't be designed to this level of detail. OR - It's going to be used, and hence is worth designing in a fashion that is reasonable to use. I think we're in the second category, and turning the ISID into hex ASCII (well, UTF-8) so the SCSI port name is a string is worth doing now to avoid problems when people actually try to use it. I would have no problems if someone wanted to pad the string, but I'd make specifying the padding the responsibility of the protocol/API/situation in which it was used rather than incorporating the padding into the name. Thanks, --David -----Original Message----- From: Jim Hafner [mailto:hafner@almaden.ibm.com] Sent: Monday, July 08, 2002 11:42 AM To: Black_David@emc.com Cc: ips@ece.cmu.edu Subject: Re: iSCSI: DLB's Comment on SCSI Port Names David, You wrote: >[T.9] 2.4.2 SCSI Architecture Model > > The SCSI Port Name is mandatory in iSCSI. When used in SCSI > parameter data, the SCSI port name MUST be encoded as: > - The iSCSI Name in UTF-8 format, followed by > - a comma separator (1 byte), followed by > - the ASCII character 'i' (for SCSI Initiator Port) or the > ASCII character 't' (for SCSI Target Port), followed by > - a comma separator (1 byte), followed by > - zero to 3 null pad bytes so that the complete format is a > multiple of four bytes long, followed by > - the 6byte value of the ISID (for SCSI initiator port) or the > 2byte value of the portal group tag (for SCSI target port) in > network byte order (BigEndian). > That's a peculiar format with padding nulls in the middle and > a number concatenated after the padding - for example, it can't > be passed in iSCSI login without format conversion. How about > converting the number to 4 or 12 bytes of hex (ASCII characters) > and moving the padding to the end so the result is actually a > string, and excluding the padding from the definition of the name? > This will increase the maximum length of port names, but produce > names that are easier to deal with. Admittedly that's an odd format, however here was the reason for this layout. 1) it's not used directly in iSCSI "Text" strings; it's intended to be a description of how this information is packed into a byte array for representation in "SCSI parameter data" (as it says!) -- that is, it's NEVER "passed in iSCSI login" (in this form). 2) the padding after the string was to force the binary values of the ISID or PGT to be better word aligned and can be more easily extracted as a value direct from the byte array without conversion. What do you think? Jim Hafner ------_=_NextPart_001_01C226E4.8D779AA0 Content-Type: text/html; charset="iso-8859-1"
I've just encountered this issue with regards to iSCSI port name encoding in the SCSI MIB, and the currently specified port name encoding causes inconvenience (at best).  IMO, it makes sense to be able to treat an iSCSI name field, be it device name or port name, the same - as a string of display characters, portions of which may contain ASCII-encoded numeric values.
 
I don't really see that it makes a difference whether one views ISID and TPGT as numeric strings or values, since as Jim says, there are no calculations performed using these things, and they are basicly just "tags".  The issue for me is that the rest of the "SCSI port name" is a string and I see no value in "encoding" the ISID or TPGT as a value for SCSI purposes, as SCSI should have no need to use the ISID or TPGT values separately from the entire port name.  And even if SCSI had such a need, it's a simple matter to convert a numeric string representation to a value.
 
The downside of a string-encoding is the increased maximum size of the SCSI port name.
 
If strings over 256 characters are a problem for some platforms, I'd be in favor of reducing the max iSCSI node name to 249 characters so the maximum SCSI port name would be 255 characters total (249 char name + ",i," + "0x0000")
 
Marjorie Krueger
Networked Storage Architecture
Networked Storage Solutions Org.
Hewlett-Packard
-----Original Message-----
From: Jim Hafner [mailto:hafner@almaden.ibm.com]
Sent: Monday, July 08, 2002 9:08 AM
To: Black_David@emc.com
Cc: ips@ece.cmu.edu
Subject: RE: iSCSI: DLB's Comment on SCSI Port Names


David,

I believe it will (may?) be used, so I agree we're in the second case.  However, this format is the intended use in SCSI protocol stuff.  Two places where SCSI ports names are used now is in ALIAS, Access Controls and in third party reservations -- see caveat below, however)

I don't see a need in this context to define these as strings (that's not a SCSI way of thinking...).  

However, I think the issue comes down to a simple question:  are the ISID and TPGT values or numerical strings (Julian is calling them numerical strings, but I've always thought of them as values, in spite of the fact that there is no arithmetic done on them - there is precedent in SCSI for such thinking, so I'm not completely out in the woods here).

If they are values, then I'd like to see them formatted for SCSI in "value form";  if they are strings, then any representation should be OK.

Does that at least get to the core of the issue?

Jim Hafner

CAVEAT: I don't think we'd use the iSCSI constructed port names in those contexts as device names are better suited for those purposes, but these are examples where specification of SCSI port name format is required.

To:        Jim Hafner/Almaden/IBM@IBMUS
cc:        ips@ece.cmu.edu
Subject:        RE: iSCSI: DLB's Comment on SCSI Port Names



Jim,

My view of this is that either:
- The SCSI Port Name is never going to be used, in which case
it shouldn't be designed to this level of detail. OR
- It's going to be used, and hence is worth designing in a fashion
that is reasonable to use.
I think we're in the second category, and turning the ISID into
hex ASCII (well, UTF-8) so the SCSI port name is a string is
worth doing now to avoid problems when people actually try
to use it.  I would have no problems if someone wanted to
pad the string, but I'd make specifying the padding the
responsibility of the protocol/API/situation in which it
was used rather than incorporating the padding into the name.

Thanks,
--David

-----Original Message-----
From: Jim Hafner [mailto:hafner@almaden.ibm.com]
Sent: Monday, July 08, 2002 11:42 AM
To: Black_David@emc.com
Cc: ips@ece.cmu.edu
Subject: Re: iSCSI: DLB's Comment on SCSI Port Names



David,

You wrote:

>[T.9] 2.4.2  SCSI Architecture Model
>
>  The SCSI Port Name is mandatory in iSCSI. When used in SCSI
>  parameter data, the SCSI port name MUST be encoded as:
>  - The iSCSI Name in UTF-8 format, followed by
>  - a comma separator (1 byte), followed by
>  - the ASCII character 'i' (for SCSI Initiator Port) or the
>    ASCII character 't' (for SCSI Target Port), followed by
>  - a comma separator (1 byte), followed by
>  - zero to 3 null pad bytes so that the complete format is a
>    multiple of four bytes long, followed by
>  - the 6byte value of the ISID (for SCSI initiator port) or the
>    2byte value of the portal group tag (for SCSI target port) in
>    network byte order (BigEndian).

> That's a peculiar format with padding nulls in the middle and
> a number concatenated after the padding - for example, it can't
> be passed in iSCSI login without format conversion.  How about
> converting the number to 4 or 12 bytes of hex (ASCII characters)
> and moving the padding to the end so the result is actually a
> string, and excluding the padding from the definition of the name?
> This will increase the maximum length of port names, but produce
> names that are easier to deal with.

Admittedly that's an odd format, however here was the reason for this
layout.
1) it's not used directly in iSCSI "Text" strings; it's intended to be a
description of how this information is packed into a byte array for
representation in "SCSI parameter data" (as it says!) -- that is, it's NEVER
"passed in iSCSI login" (in this form).
2) the padding after the string was to force the binary values of the ISID
or PGT to be better word aligned and can be more easily extracted as a value
direct from the byte array without conversion.

What do you think?

Jim Hafner

------_=_NextPart_001_01C226E4.8D779AA0-- From owner-ips@ece.cmu.edu Tue Jul 9 01:13:47 2002 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA03069 for ; Tue, 9 Jul 2002 01:13:47 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id g694ObC28466 for ips-outgoing; Tue, 9 Jul 2002 00:24:37 -0400 (EDT) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from d12lmsgate-2.de.ibm.com (d12lmsgate-2.de.ibm.com [195.212.91.200]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id g694OZX28458 for ; Tue, 9 Jul 2002 00:24:35 -0400 (EDT) Received: from d12relay01.de.ibm.com (d12relay01.de.ibm.com [9.165.215.22]) by d12lmsgate-2.de.ibm.com (8.12.3/8.12.3) with ESMTP id g694ONIS020830 for ; Tue, 9 Jul 2002 06:24:23 +0200 Received: from d10hubm1.telaviv.ibm.com (d10ml001.telaviv.ibm.com [9.148.216.55]) by d12relay01.de.ibm.com (8.11.1m3/NCO/VER6.2) with ESMTP id g694OMU55486 for ; Tue, 9 Jul 2002 06:24:22 +0200 To: ips@ece.cmu.edu MIME-Version: 1.0 Subject: iSCSI - pause X-Mailer: Lotus Notes Release 5.0.9 November 16, 2001 From: "Julian Satran" Message-ID: Date: Tue, 9 Jul 2002 07:24:19 +0300 X-MIMETrack: Serialize by Router on D10ML001/10/M/IBM(Release 5.0.9a |January 7, 2002) at 09/07/2002 07:24:23, Serialize complete at 09/07/2002 07:24:23 Content-Type: multipart/alternative; boundary="=_alternative 0017EEE0C2256BF1_=" Sender: owner-ips@ece.cmu.edu Precedence: bulk This is a multipart message in MIME format. --=_alternative 0017EEE0C2256BF1_= Content-Type: text/plain; charset="us-ascii" Dear colleagues, I will be away until Yokohama for a brief vacation. All DLB Technicals have at least a partial resolution on my site (the site will not close for vacation!). I will have only spotty access to e-mail. I might be adding some more stuff today but don't count on much. Have a safe trip to Japan - if you are coming - and enjoy whatever you are doing instead if not. Thanks all of you for your careful reading and invaluable help. Julo Julian Satran - Distinguished Engineer - IBM Research Laboratory at Haifa BTW - I was not particularly enchanted by having so many things coming in so late, neither seeing so many editorials or questions on items that where there for years coming in so late and being qualified as Technical. But I would not enter into a fruitless dispute on what is what. --=_alternative 0017EEE0C2256BF1_= Content-Type: text/html; charset="us-ascii"
Dear colleagues,

I will be away until Yokohama for a brief vacation.
All DLB Technicals have at least a partial resolution on my site (the site will not close for vacation!).
I will have only spotty access to e-mail.
I might be adding some more stuff today but don't count on much.

Have a safe trip to Japan - if you are coming - and enjoy whatever you are doing instead if not.

Thanks all of you for your careful reading and invaluable help.

Julo

Julian Satran - Distinguished Engineer - IBM Research Laboratory at Haifa

BTW - I was not particularly enchanted by having so many things coming in so late, neither
seeing so many editorials or questions on items that where there for years coming in so late and being qualified as Technical.
But I would not enter into a fruitless dispute on what is what. --=_alternative 0017EEE0C2256BF1_=-- From owner-ips@ece.cmu.edu Tue Jul 9 02:20:34 2002 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA13207 for ; Tue, 9 Jul 2002 02:20:34 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id g695p3b02354 for ips-outgoing; Tue, 9 Jul 2002 01:51:03 -0400 (EDT) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from d12lmsgate.de.ibm.com (d12lmsgate.de.ibm.com [195.212.91.199]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id g695p1X02349; Tue, 9 Jul 2002 01:51:01 -0400 (EDT) Received: from d12relay02.de.ibm.com (d12relay02.de.ibm.com [9.165.215.23]) by d12lmsgate.de.ibm.com (8.12.3/8.12.3) with ESMTP id g695opIB019350; Tue, 9 Jul 2002 07:50:51 +0200 Received: from d10hubm1.telaviv.ibm.com (d10ml001.telaviv.ibm.com [9.148.216.55]) by d12relay02.de.ibm.com (8.11.1m3/NCO/VER6.2) with ESMTP id g695ooC106074; Tue, 9 Jul 2002 07:50:51 +0200 To: Paul Koning Cc: ips@ece.cmu.edu, owner-ips@ece.cmu.edu MIME-Version: 1.0 Subject: Re: iSCSI - decimal coded binary strings - a proposed resolution X-Mailer: Lotus Notes Release 5.0.9 November 16, 2001 From: "Julian Satran" Message-ID: Date: Tue, 9 Jul 2002 08:50:47 +0300 X-MIMETrack: Serialize by Router on D10ML001/10/M/IBM(Release 5.0.9a |January 7, 2002) at 09/07/2002 08:50:50, Serialize complete at 09/07/2002 08:50:50 Content-Type: multipart/alternative; boundary="=_alternative 001F724AC2256BF1_=" Sender: owner-ips@ece.cmu.edu Precedence: bulk This is a multipart message in MIME format. --=_alternative 001F724AC2256BF1_= Content-Type: text/plain; charset="us-ascii" Paul - I think we are talking again about two different thinks: numerical values that could be more than 2**64 - I would not forbid it there bit strings that could be longer than 64 bits - I find it acceptable The new text could be: decimal-constant: an unsigned decimal number - the digit 0 or a string of 1 or more digits starting with a non-zero digit. Decimal-constants are used to encode numerical values or binary strings. Decimal constants can be used to encode binary strings only if the stringlength is explicitly speci-fied. There is no implicit length for decimal strings. This encoding MUST NOT used for numerical values equal or greater than 2**64 or binary strings that could be longer than 64 bits. Julo Paul Koning Sent by: owner-ips@ece.cmu.edu 07/08/2002 10:36 PM Please respond to Paul Koning To: Julian Satran/Haifa/IBM@IBMIL cc: ips@ece.cmu.edu Subject: Re: iSCSI - decimal coded binary strings - a proposed resolution >>>>> "Julian" == Julian Satran writes: Julian> Considering the widespread use of decimal encoding and the Julian> perceived difficulty of mapping them to a binary string - Julian> mainly due to the difficulty of matching lengths I suggest Julian> the following: Julian> Decimal encoding for binary strings will be used only where Julian> the length of the binary string is explicitly defined (by a Julian> constant or a rule that does not use the encoding itself) Julian> The definition for decimal constant becomes: Julian> decimal-constant: an unsigned decimal number - the digit 0 or Julian> a string of 1 or more digits starting with a non-zero Julian> digit. This encoding is not used for numerical values equal Julian> or greater than 2**64. Decimal-constants are used to encode Julian> numerical values or binary strings. Decimal constants can be Julian> used to encode binary strings only if the stringlength is Julian> explicitly specified. There is no implicit length for Julian> deci-mal strings. The point about "no implicitic length" certainly helps. I like David's suggestion (DLB's comments T.12) to disallow decimal for data items that are capable of being larger than 2**64 -- rather than tying it to whether the particular value being encoded happens to be bigger or smaller than 2*64. That way it essentially becomes a property of the data type, which seems like a logical way to go. Text to do that would be something like "This encoding is not used for parameters that may have a value >= 2**64" or alternatively "This encoding is used only with parameters whose largest permitted value is less than 2**64". paul --=_alternative 001F724AC2256BF1_= Content-Type: text/html; charset="us-ascii"
Paul - I think we are talking again about two different thinks:
  1. numerical values that could be more than 2**64 - I would not forbid it there
  2. bit strings that could be longer than 64 bits - I find it acceptable

    The new text could be:

    decimal-constant: an unsigned decimal number - the digit 0 or a string of 1 or more digits starting with a non-zero digit.  Decimal-constants are used to encode numerical values or binary strings. Decimal constants can be used to encode binary strings only if the stringlength is explicitly speci-fied. There is no implicit length for decimal strings. This encoding MUST NOT used for numerical values equal or greater than 2**64 or binary strings that could be longer than 64 bits.

    Julo


    Paul Koning <ni1d@arrl.net>
    Sent by: owner-ips@ece.cmu.edu

    07/08/2002 10:36 PM
    Please respond to Paul Koning

    		       
            To:        Julian Satran/Haifa/IBM@IBMIL
            cc:        ips@ece.cmu.edu
            Subject:        Re: iSCSI - decimal coded binary strings - a proposed resolution

           


    >>>>> "Julian" == Julian Satran <Julian_Satran@il.ibm.com> writes:

    Julian> Considering the widespread use of decimal encoding and the
    Julian> perceived difficulty of mapping them to a binary string -
    Julian> mainly due to the difficulty of matching lengths I suggest
    Julian> the following:

    Julian> Decimal encoding for binary strings will be used only where
    Julian> the length of the binary string is explicitly defined (by a
    Julian> constant or a rule that does not use the encoding itself)


    Julian> The definition for decimal constant becomes:

    Julian> decimal-constant: an unsigned decimal number - the digit 0 or
    Julian> a string of 1 or more digits starting with a non-zero
    Julian> digit. This encoding is not used for numerical values equal
    Julian> or greater than 2**64. Decimal-constants are used to encode
    Julian> numerical values or binary strings. Decimal constants can be
    Julian> used to encode binary strings only if the stringlength is
    Julian> explicitly specified. There is no implicit length for
    Julian> deci-mal strings.

    The point about "no implicitic length" certainly helps.

    I like David's suggestion (DLB's comments T.12) to disallow decimal
    for data items that are capable of being larger than 2**64 -- rather
    than tying it to whether the particular value being encoded happens to
    be bigger or smaller than 2*64.  That way it essentially becomes a
    property of the data type, which seems like a logical way to go.

    Text to do that would be something like "This encoding is not used for
    parameters that may have a value >= 2**64" or alternatively "This
    encoding is used only with parameters whose largest permitted value is
    less than 2**64".

                     paul

--=_alternative 001F724AC2256BF1_=-- From owner-ips@ece.cmu.edu Tue Jul 9 02:20:55 2002 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA13223 for ; Tue, 9 Jul 2002 02:20:54 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id g695eVD01900 for ips-outgoing; Tue, 9 Jul 2002 01:40:31 -0400 (EDT) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from d12lmsgate.de.ibm.com (d12lmsgate.de.ibm.com [195.212.91.199]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id g695eTX01894 for ; Tue, 9 Jul 2002 01:40:29 -0400 (EDT) Received: from d12relay02.de.ibm.com (d12relay02.de.ibm.com [9.165.215.23]) by d12lmsgate.de.ibm.com (8.12.3/8.12.3) with ESMTP id g695eDIB042824; Tue, 9 Jul 2002 07:40:13 +0200 Received: from d10hubm1.telaviv.ibm.com (d10ml001.telaviv.ibm.com [9.148.216.55]) by d12relay02.de.ibm.com (8.11.1m3/NCO/VER6.2) with ESMTP id g695eDC76160; Tue, 9 Jul 2002 07:40:13 +0200 To: Black_David@emc.com Cc: aghanem@cisco.com, ips@ece.cmu.edu, owner-ips@ece.cmu.edu MIME-Version: 1.0 Subject: RE: iSCSI: DLB's [T.6] 2.3 iSCSI Session Types X-Mailer: Lotus Notes Release 5.0.9 November 16, 2001 From: "Julian Satran" Message-ID: Date: Tue, 9 Jul 2002 08:40:09 +0300 X-MIMETrack: Serialize by Router on D10ML001/10/M/IBM(Release 5.0.9a |January 7, 2002) at 09/07/2002 08:40:13, Serialize complete at 09/07/2002 08:40:13 Content-Type: multipart/alternative; boundary="=_alternative 001E305FC2256BF1_=" Sender: owner-ips@ece.cmu.edu Precedence: bulk This is a multipart message in MIME format. --=_alternative 001E305FC2256BF1_= Content-Type: text/plain; charset="us-ascii" David, The original MAY was perfectly appropriate and so is the MUST. If you say that you have targets that MAY not support anything else than .. the an initiator attempting to use anything else would do it at its own risk. Your preference for MUST puts an additional mandatory burden to targets to CHECK (all targets) that nothing else is sent. It is strict where none of us thought that we have to be. From an initiator POW they are equivalent. For a target it requires more work. I would favor the way we where ... but that may be all age related. Julo Black_David@emc.com Sent by: owner-ips@ece.cmu.edu 07/08/2002 05:18 PM Please respond to Black_David To: aghanem@cisco.com, ips@ece.cmu.edu cc: Subject: RE: iSCSI: DLB's [T.6] 2.3 iSCSI Session Types Ayman, Something needs to be cleaned up here, as the current text appears to allow all types of iSCSI PDUs on a discovery session. I didn't intend to restrict a discovery session to one Send Targets followed by a logout (i.e., it could be kept open with the initiator periodically sending a new Send Targets to see if anything has changed), but I did intend to forbid SCSI commands, task management, etc. on Discovery sessions. Is that reasonable, or are there additional types of iSCSI PDUs that you want to see allowed for new device notifications? Thanks, --David > -----Original Message----- > From: Ayman Ghanem [mailto:aghanem@cisco.com] > Sent: Sunday, July 07, 2002 12:41 PM > To: ips@ece.cmu.edu > Subject: RE: iSCSI: DLB's [T.6] 2.3 iSCSI Session Types > > > I prefer leaving this as "MAY" for implementations that want > to support new > device notifications. There was a discussion on whether > discovery sessions > should be long-lived or not. Using MAY allows both without > breaking any > thing. > > -Ayman > > > [T.6] 2.3 iSCSI Session Types > > > > b) Discovery-session - a session opened only for > target discov- > > ery; the target MAY accept only text requests with > the SendTar- > > gets key and a logout request with reason "close the session". > > > > Change "MAY" to "MUST", and say that other requests MUST be > rejected. > > > --=_alternative 001E305FC2256BF1_= Content-Type: text/html; charset="us-ascii"
David,

The original MAY was perfectly appropriate and so is the MUST.
If you say that you have targets that MAY not support anything else than .. the an initiator attempting to use anything else
would do it at its own risk.
Your preference for MUST puts an additional mandatory burden to targets to CHECK (all targets) that nothing else
is sent.

It is strict where none of us thought that we have to be.

From an initiator POW they are equivalent.
For a target it requires more work.

I would favor the way we where ... but that may be all age related.

Julo



Black_David@emc.com
Sent by: owner-ips@ece.cmu.edu

07/08/2002 05:18 PM
Please respond to Black_David

       
        To:        aghanem@cisco.com, ips@ece.cmu.edu
        cc:        
        Subject:        RE: iSCSI: DLB's [T.6] 2.3  iSCSI Session Types

       


Ayman,

Something needs to be cleaned up here, as the current text appears
to allow all types of iSCSI PDUs on a discovery session.  I didn't
intend to restrict a discovery session to one Send Targets followed
by a logout (i.e., it could be kept open with the initiator periodically
sending a new Send Targets to see if anything has changed), but I
did intend to forbid SCSI commands, task management, etc. on Discovery
sessions.  Is that reasonable, or are there additional types of iSCSI
PDUs that you want to see allowed for new device notifications?

Thanks,
--David

> -----Original Message-----
> From: Ayman Ghanem [mailto:aghanem@cisco.com]
> Sent: Sunday, July 07, 2002 12:41 PM
> To: ips@ece.cmu.edu
> Subject: RE: iSCSI: DLB's [T.6] 2.3 iSCSI Session Types
>
>
> I prefer leaving this as "MAY" for implementations that want
> to support new
> device notifications. There was a discussion on whether
> discovery sessions
> should be long-lived or not. Using MAY allows both without
> breaking any
> thing.
>
> -Ayman
>
> > [T.6] 2.3  iSCSI Session Types
> >
> >       b)  Discovery-session - a session opened only for
> target discov-
> >       ery; the target MAY accept only text requests with
> the SendTar-
> >       gets key and a logout request with reason "close the session".
> >
> > Change "MAY" to "MUST", and say that other requests MUST be
> rejected.
> >
>


--=_alternative 001E305FC2256BF1_=-- From owner-ips@ece.cmu.edu Tue Jul 9 03:21:10 2002 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA14738 for ; Tue, 9 Jul 2002 03:21:09 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id g696Uj603991 for ips-outgoing; Tue, 9 Jul 2002 02:30:45 -0400 (EDT) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from mxic2.corp.emc.com (mxic2.isus.emc.com [128.221.31.40]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id g696UiX03987 for ; Tue, 9 Jul 2002 02:30:44 -0400 (EDT) Received: by mxic2.corp.emc.com with Internet Mail Service (5.5.2653.19) id <31X6QGPW>; Tue, 9 Jul 2002 02:30:38 -0400 Message-ID: <277DD60FB639D511AC0400B0D068B71E0564C046@CORPMX14> From: Black_David@emc.com To: Julian_Satran@il.ibm.com Cc: ips@ece.cmu.edu Subject: RE: iSCSI: DLB's [T.37] 11.12 ImmediateData Date: Tue, 9 Jul 2002 02:28:40 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C22711.DD54E190" Sender: owner-ips@ece.cmu.edu Precedence: bulk This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_001_01C22711.DD54E190 Content-Type: text/plain; charset="iso-8859-1" So the entire specification of how this pair of related features (immediate data and unsolicited Data-In PDUs) behaves is in one place. I think I've seen a suggestion from Brian Forbes to add subsection headings to 2.2.4 - perhaps a reference back to the appropriate subsection will do the trick. --David -----Original Message----- From: Julian Satran [mailto:Julian_Satran@il.ibm.com] Sent: Monday, July 08, 2002 2:30 PM To: Black_David@emc.com Cc: ips@ece.cmu.edu; owner-ips@ece.cmu.edu; rod.harrison@windriver.com Subject: RE: iSCSI: DLB's [T.37] 11.12 ImmediateData Importance: High But that statement already appears in 2.2.4 Why repeat it? Julo Black_David@emc.com Sent by: owner-ips@ece.cmu.edu 07/08/2002 05:13 PM Please respond to Black_David To: rod.harrison@windriver.com, ips@ece.cmu.edu cc: Subject: RE: iSCSI: DLB's [T.37] 11.12 ImmediateData > I believe the MAY is to allow the initiator to send no unsolicited > data if it so chooses. For non-immediate unsolicited the rule was the > initiator MUST send all of the unsolicited data possible, or no > unsolicited data. The presence of the F bit in the latter case removes > the possibility of any confusion over the amount of unsolicited data > at the target. Yes, you're correct. Adding a "MUST send all of the unsolicited data possible" statement and leaving the "MAY"s as they are would take care of this. 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 --------------------------------------------------- ------_=_NextPart_001_01C22711.DD54E190 Content-Type: text/html; charset="iso-8859-1"
So the entire specification of how this pair of related features
(immediate data and unsolicited Data-In PDUs) behaves is in
one place.  I think I've seen a suggestion from Brian Forbes
to add subsection headings to 2.2.4 - perhaps a reference
back to the appropriate subsection will do the trick.
 
--David
-----Original Message-----
From: Julian Satran [mailto:Julian_Satran@il.ibm.com]
Sent: Monday, July 08, 2002 2:30 PM
To: Black_David@emc.com
Cc: ips@ece.cmu.edu; owner-ips@ece.cmu.edu; rod.harrison@windriver.com
Subject: RE: iSCSI: DLB's [T.37] 11.12 ImmediateData
Importance: High


But that statement already appears in 2.2.4  Why repeat it? Julo


Black_David@emc.com
Sent by: owner-ips@ece.cmu.edu

07/08/2002 05:13 PM
Please respond to Black_David

       
        To:        rod.harrison@windriver.com, ips@ece.cmu.edu
        cc:        
        Subject:        RE: iSCSI: DLB's [T.37] 11.12 ImmediateData

       


>                  I believe the MAY is to allow the initiator to send no unsolicited
> data if it so chooses. For non-immediate unsolicited the rule was the
> initiator MUST send all of the unsolicited data possible, or no
> unsolicited data. The presence of the F bit in the latter case removes
> the possibility of any confusion over the amount of unsolicited data
> at the target.

Yes, you're correct.  Adding a "MUST send all of the unsolicited
data possible" statement and leaving the "MAY"s as they are
would take care of this.

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


------_=_NextPart_001_01C22711.DD54E190-- From owner-ips@ece.cmu.edu Tue Jul 9 03:21:35 2002 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA14755 for ; Tue, 9 Jul 2002 03:21:35 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id g696ffQ04425 for ips-outgoing; Tue, 9 Jul 2002 02:41:41 -0400 (EDT) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from maho3msx2.isus.emc.com (maho3msx2.isus.emc.com [128.221.11.32]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id g696feX04420 for ; Tue, 9 Jul 2002 02:41:40 -0400 (EDT) Received: by MAHO3MSX2 with Internet Mail Service (5.5.2653.19) id <31WC2BMP>; Tue, 9 Jul 2002 02:39:38 -0400 Message-ID: <277DD60FB639D511AC0400B0D068B71E0564C048@CORPMX14> From: Black_David@emc.com To: hufferd@us.ibm.com Cc: ips@ece.cmu.edu Subject: iSCSI: DLB's Last Call T15 comment Date: Tue, 9 Jul 2002 02:39:36 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-ips@ece.cmu.edu Precedence: bulk John, [T.15] 4.3.1 Login Phase Start The first Login Response PDU during the Login Phase from the iSCSI target SHOULD return the TargetPortalGroupTag key that contains the tag value of the iSCSI portal group servicing the Login Request PDU. If the iSCSI target implementation supports altering the portal group configuration (including adding, deleting, and swapping of portals in a portal group), it MUST return the TargetPortalGroupTag key carry- ing the tag value of the servicing portal group. Let's make returning this key a MUST in all cases - less text, simpler protocol, simpler code at the Initiator. > The item numbered T15, had a lot of discussions, especially in the Naming > and Discovery Team, and the current wordage was the results of a > compromise, where a number of vendors did not have the issue, and strongly > felt that it would be the wrong thing to do with their product. So we > agreed that the SHOULD section would be the right answer for > every one. This sort of compromise leads to "MAY", not "SHOULD". I suggest summarizing the NDT discussion to the list, as it's now an issue to be settled here. 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 --------------------------------------------------- From owner-ips@ece.cmu.edu Tue Jul 9 03:23:04 2002 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA14778 for ; Tue, 9 Jul 2002 03:23:03 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id g696rXL04954 for ips-outgoing; Tue, 9 Jul 2002 02:53:33 -0400 (EDT) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from maho3msx2.isus.emc.com (maho3msx2.isus.emc.com [128.221.11.32]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id g696rWX04949 for ; Tue, 9 Jul 2002 02:53:32 -0400 (EDT) Received: by MAHO3MSX2 with Internet Mail Service (5.5.2653.19) id <31WC2BYP>; Tue, 9 Jul 2002 02:51:30 -0400 Message-ID: <277DD60FB639D511AC0400B0D068B71E0564C050@CORPMX14> From: Black_David@emc.com To: dap@cisco.com, ips@ece.cmu.edu Subject: iSCSI: DAP Retry comments Date: Tue, 9 Jul 2002 02:51:28 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-ips@ece.cmu.edu Precedence: bulk > T p 103 6.1.1 Usage of Retry and 6.7 SCSI Timeouts: the semantics of Retry > remain broken rendering it useless for tape operation. SCSI level error > detection and recovery is the preferred mechanism. Refer to previous emails > sent via the IPS reflector regarding this matter. Can you provide more information? Command retry *never* results in the command executing twice - both the original command and the retry have the same CmdSN, so the second one is dropped as a duplicate if the first one was received correctly. 6.1.1 is very clear that retry MUST NOT be used if the command was received successfully (acknowledged by ExpCmdSN), and if it is used, the retried command PDU is silently dropped. iSCSI's ordered delivery requirement avoids the situation in which a dropped command causes subsequent commands to mis-execute - if none of the commands are marked for immediate delivery, iSCSI will stop at the "hole" created by the dropped command, and wait for the retry to plug the hole. > T p 128 8.6 Considerations for State-dependent devices: last paragraph: > don't agree with the statement that error recovery at the iSCSI level > (specifically Retry in its current state) is advisable. Retry at the SCSI > level is feasible and is not difficult (i.e., READ POSITION and LOCATE > commands). This paragraph should be removed. Two questions: - What about the SNACK and allegiance change mechanisms? - What about the "legacy" tape devices (e.g., as discussed in London) that presumably don't implement those commands? I believe this text was originally intended to address this class of devices. 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 --------------------------------------------------- From owner-ips@ece.cmu.edu Tue Jul 9 03:23:13 2002 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA14793 for ; Tue, 9 Jul 2002 03:23:12 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id g696heS04519 for ips-outgoing; Tue, 9 Jul 2002 02:43:40 -0400 (EDT) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from mailhub.lss.emc.com (xdch.emc.com [168.159.1.79]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id g696hdX04515 for ; Tue, 9 Jul 2002 02:43:39 -0400 (EDT) Received: from emc.com (emcmail.lss.emc.com [168.159.48.78]) by mailhub.lss.emc.com (Switch-2.2.0/Switch-2.2.0) with ESMTP id g696hUE04826; Tue, 9 Jul 2002 02:43:31 -0400 (EDT) Received: from mxic1.isus.emc.com ([168.159.129.100]) by emc.com (8.10.1/8.10.1) with ESMTP id g696hU727449; Tue, 9 Jul 2002 02:43:30 -0400 (EDT) Received: by MXIC1 with Internet Mail Service (5.5.2653.19) id <31WADBBP>; Tue, 9 Jul 2002 02:41:33 -0400 Message-ID: <277DD60FB639D511AC0400B0D068B71E0564C049@CORPMX14> From: Black_David@emc.com To: aghanem@cisco.com, ips@ece.cmu.edu Subject: RE: iSCSI: DLB's [T.6] 2.3 iSCSI Session Types Date: Tue, 9 Jul 2002 02:41:31 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" X-Perlmx-Spam: Gauge=XIIIIII, Probability=16%, Report="NO_REAL_NAME" Sender: owner-ips@ece.cmu.edu Precedence: bulk Ayman, > The issue that came up before was if a discovery session could be kept open, > why not allow the initiator and target to send NOPs, and allow the target to > send Async messages when new targets become available? > > I don't mean to bring up this issue again at this stage, but using "MAY" > leaves room for implementations that want to support this. If we allow NOP > and Async PDUs on a discovery session, then changing "MAY" to "MUST" will be > fine. That would be fine with me as long as we spell out which Async PDUs are used and what they do - it looks like codes 1 (target requests logout), 3 (target is closing session) and 4 (target requests negotiation) would be acceptable, with code 4 having the meaning "please issue a Send Targets" when used on a discovery session. The text to specify this needs to be more than just the single "MUST" in order to avoid applying a "MUST" to long-lived discovery session support. Here's an attempt, but it's a bit long and could use some editing: On a discovery session, an Initiator: - MUST NOT issue PDUs other than Send Targets, a logout request to close the session, and NOP-Out. - MAY ignore NOP-In and Async Message PDUs from the target, but MUST NOT treat NOP-In and Async Message PDUs with codes 1, 3, and 4 as errors. (Hmm ... ignoring code 1 [request logout] and 3 [target is closing session] does not seem like a good idea, although it does work as the target can time-out and tear down the session itself). - MUST treat an Async Message PDU with code 4 (negotiation request) as a request to issue a Send Targets command, although the initiator MAY ignore the request. - MUST treat as a protocol error (terminate session), any received PDU other than (1) NOP-In, (2) Async Message and (3) responses to PDUs issued by the Initiator. On a discovery session, a Target: - MUST accept and respond to Send Targets and a logout request to close the session. - MAY ignore NOP-Out PDUs from the initiator, but MUST NOT treat them as errors. - MUST NOT issue PDUs other than NOP-In, Async Message PDUs with codes 1 (request logout), 3 (announce session closure) and 4 (request negotiation), and PDUs required to respond to Send Targets and a logout request from the Initiator. - MUST treat as a protocol error (terminate session), any received PDU other than (1) a text PDU containing Send Targets, (2) a Logout Request to close the session, and (3) NOP-Out. My underlying motivation is that if we're going to allow long-lived discovery sessions, it behooves us to specify how they work sufficiently for interoperability. 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 --------------------------------------------------- From owner-ips@ece.cmu.edu Tue Jul 9 03:23:17 2002 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA14810 for ; Tue, 9 Jul 2002 03:23:17 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id g696ob804835 for ips-outgoing; Tue, 9 Jul 2002 02:50:37 -0400 (EDT) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from mailhub.lss.emc.com (xdch.emc.com [168.159.1.79]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id g696oaX04831 for ; Tue, 9 Jul 2002 02:50:36 -0400 (EDT) Received: from emc.com (emcmail.lss.emc.com [168.159.48.78]) by mailhub.lss.emc.com (Switch-2.2.0/Switch-2.2.0) with ESMTP id g696oRE06827 for ; Tue, 9 Jul 2002 02:50:28 -0400 (EDT) Received: from mxic1.isus.emc.com ([168.159.129.100]) by emc.com (8.10.1/8.10.1) with ESMTP id g696oR728197 for ; Tue, 9 Jul 2002 02:50:27 -0400 (EDT) Received: by MXIC1 with Internet Mail Service (5.5.2653.19) id <31WADBG0>; Tue, 9 Jul 2002 02:48:30 -0400 Message-ID: <277DD60FB639D511AC0400B0D068B71E0564C04D@CORPMX14> From: Black_David@emc.com To: ips@ece.cmu.edu Subject: IPS Yokohama agenda Date: Tue, 9 Jul 2002 02:48:27 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" X-Perlmx-Spam: Gauge=XIIIIII, Probability=16%, Report="NO_REAL_NAME" Sender: owner-ips@ece.cmu.edu Precedence: bulk Very few drafts have active issues that need meeting time. Here's the IPS agenda for Yokohama. --David IETF IP Storage (IPS) Working Group Yokohama IETF Meeting, July 14-19, 2002 ------------------------------------------- CHAIRS: David L. Black Elizabeth Rodriguez AGENDA: SUBJECT TO CHANGE Announcement: Most drafts are near Working Group Last Call. Everyone is encouraged to review all the documents, prior to the meeting and: 1) provide editorial feedback directly to the editors/authors 2) bring up any remaining/outstanding issues immediately on the reflector. Most of the WG drafts are NOT listed on this agenda as their authors and WG co-chairs are not aware of any open technical issues requiring meeting time to discuss. A number of WG Last Calls can be expected in the near future. ---- Monday, July 15, 1930-2200 ---- - Agenda Bashing and Administrivia (10 min) - BLUE SHEETS - NOTE WELL - Status of drafts - iSCSI Plugfest Announcement and Discussion (30 min) Announcement and discussion of next iSCSI plugfest. - Security (30 min) draft-ietf-ips-security-13.txt This draft has successfully completed WG Last Call, but with a couple of loose ends that need to be discussed: - Specification of SRP groups. This is primarily about specifying generators for use of the IKE groups with SRP, and is expected to be resolved by the time of the meeting. This is a placeholder to announce how it was resolved. - AES Counter Mode fallback. AES Counter mode is "SHOULD implement", but is encountering difficulty in the ipsec WG (e.g., there is no current Internet-Draft on it). The WG chairs propose to defer resolving this issue until IETF Last Call, but to discuss in this meeting what will be done during IETF Last Call if AES Counter mode is not viable - the two obvious options are (1) remove the SHOULD (AES could be specified in a separate subsequent draft, or (2) substitute AES CBC mode. - SCSI MIB (20 min) draft-ietf-ips-scsi-mib-03.txt Structure diagram available at: ftp://ftpeng.cisco.com/mbakke/ips/scsi-mib/Visio-scsi-uml-model-01.pdf Diagram showing relationships among SCSI family of MIBS available at: ftp://ftpeng.cisco.com/mbakke/ips/scsi-mib/Visio-scsi-mib-family-01.pdf - iSCSI (60 min) draft-ietf-ips-iscsi-14.txt Discussion of issues raised during Working Group Last Call ---- Tuesday, July 16, 1300-1400 ---- - iSCSI (60 min) draft-ietf-ips-iscsi-14.txt Continued discussion of issues raised during Working Group Last Call DESCRIPTION: The IP Storage WG works on using IP-based networks to transport block storage traffic. See http://www.ietf.org/html.charters/ips-charter.html From owner-ips@ece.cmu.edu Tue Jul 9 03:23:19 2002 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA14806 for ; Tue, 9 Jul 2002 03:23:14 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id g6970ca05220 for ips-outgoing; Tue, 9 Jul 2002 03:00:38 -0400 (EDT) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from mxic2.corp.emc.com (mxic2.isus.emc.com [128.221.31.40]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id g6970bX05216 for ; Tue, 9 Jul 2002 03:00:37 -0400 (EDT) Received: by mxic2.corp.emc.com with Internet Mail Service (5.5.2653.19) id <31X6QHN9>; Tue, 9 Jul 2002 03:00:31 -0400 Message-ID: <277DD60FB639D511AC0400B0D068B71E0564C052@CORPMX14> From: Black_David@emc.com To: marjorie_krueger@hp.com, ips@ece.cmu.edu Subject: RE: Yokohama Agenda and status of drafts Date: Tue, 9 Jul 2002 02:58:33 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-ips@ece.cmu.edu Precedence: bulk Marj gets 2 credits for transcontinental mind reading - I was wondering whether the naming/discovery draft was still going standards track - I'll correct the status of drafts list that'll be used in Yokohama. Thanks, --David > -----Original Message----- > From: KRUEGER,MARJORIE (HP-Roseville,ex1) > [mailto:marjorie_krueger@hp.com] > Sent: Monday, July 08, 2002 1:38 PM > To: 'Black_David@emc.com'; ips@ece.cmu.edu > Subject: RE: Yokohama Agenda and status of drafts > > > David, > Regarding: > > > draft-ietf-ips-iscsi-name-disc-06.txt > > To become a proposed standard RFC. WG Last Call > expected shortly > > after Yokohama. > > We have moved all of the normative text regarding iSCSI name > construction > into the main iSCSI protocol draft and I believe the intent > is that this > draft should be informational. > > Thanks, > Marjorie > From owner-ips@ece.cmu.edu Tue Jul 9 03:23:37 2002 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA14849 for ; Tue, 9 Jul 2002 03:23:37 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id g696q7s04886 for ips-outgoing; Tue, 9 Jul 2002 02:52:07 -0400 (EDT) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from mailhub.lss.emc.com (xdch.emc.com [168.159.1.79]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id g696q6X04882 for ; Tue, 9 Jul 2002 02:52:06 -0400 (EDT) Received: from emc.com (emcmail.lss.emc.com [168.159.48.78]) by mailhub.lss.emc.com (Switch-2.2.0/Switch-2.2.0) with ESMTP id g696pvE07268; Tue, 9 Jul 2002 02:51:58 -0400 (EDT) Received: from mxic1.isus.emc.com ([168.159.129.100]) by emc.com (8.10.1/8.10.1) with ESMTP id g696pv728351; Tue, 9 Jul 2002 02:51:57 -0400 (EDT) Received: by MXIC1 with Internet Mail Service (5.5.2653.19) id <31WADB2C>; Tue, 9 Jul 2002 02:50:00 -0400 Message-ID: <277DD60FB639D511AC0400B0D068B71E0564C04F@CORPMX14> From: Black_David@emc.com To: hufferd@us.ibm.com Cc: ips@ece.cmu.edu Subject: iSCSI: DLB's Last Call T17 comment Date: Tue, 9 Jul 2002 02:49:59 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" X-Perlmx-Spam: Gauge=XIIIIII, Probability=16%, Report="NO_REAL_NAME" Sender: owner-ips@ece.cmu.edu Precedence: bulk John, [T.17] 6.4 Format Errors The following two explicit violations of PDU layout rules are format errors: a) illegal contents of the PDU header (except the Opcode) - for ex., out-of-range values for certain fields b) inconsistent contents - for ex., value of one field conflicts with that of another. Format errors indicate a major implementation flaw in one of the par- ties. The two "for ex."s aren't good enough. Details on what is a format error need to be spelled out explicitly, given the drastic consequences of committing one. > I also disagree with your item T17. I think those examples are all that is > needed, since there are an infinite number of ways for someone to screw up. > Much of the document, is spent stating what MUST, SHOULD, SHOULD NOT be > done, repeating those at this point would not be useful. A large pile of additional examples is not what's needed - what I asked for is more precise definitions of "illegal contents" and "inconsistent contents". This need only take a few sentences - I think the intent is that a format error is something that can be determined to be wrong statically without reference to any session or connection state and is wrong in a fashion that violates a MUST in the definition of the format of the appropriate PDU. For example, setting both the O and U bits to 1 in a SCSI Response PDU is a format error, but using a bad Initiator Task Tag (unknown to the Initiator) is not. The text in the above paragraph starting with "a format error is" should be most of what's needed to resolve this one, and even includes a couple of examples that are more specific than the current text. 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 --------------------------------------------------- From owner-ips@ece.cmu.edu Tue Jul 9 03:23:38 2002 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA14858 for ; Tue, 9 Jul 2002 03:23:37 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id g696iF704539 for ips-outgoing; Tue, 9 Jul 2002 02:44:15 -0400 (EDT) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from mailhub.lss.emc.com (xdch.emc.com [168.159.1.79]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id g696iEX04535 for ; Tue, 9 Jul 2002 02:44:14 -0400 (EDT) Received: from emc.com (emcmail.lss.emc.com [168.159.48.78]) by mailhub.lss.emc.com (Switch-2.2.0/Switch-2.2.0) with ESMTP id g696i2E05016; Tue, 9 Jul 2002 02:44:03 -0400 (EDT) Received: from mxic1.isus.emc.com ([168.159.129.100]) by emc.com (8.10.1/8.10.1) with ESMTP id g696i2727510; Tue, 9 Jul 2002 02:44:02 -0400 (EDT) Received: by MXIC1 with Internet Mail Service (5.5.2653.19) id <31WADBB6>; Tue, 9 Jul 2002 02:42:05 -0400 Message-ID: <277DD60FB639D511AC0400B0D068B71E0564C04A@CORPMX14> From: Black_David@emc.com To: hufferd@us.ibm.com Cc: ips@ece.cmu.edu Subject: iSCSI: DLB's Last Call T18 comment Date: Tue, 9 Jul 2002 02:42:04 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" X-Perlmx-Spam: Gauge=XIIIIII, Probability=16%, Report="NO_REAL_NAME" Sender: owner-ips@ece.cmu.edu Precedence: bulk John, [T.18] 6.7 SCSI Timeouts On a ULP timeout for a command (that carried a CmdSN of n), the iSCSI initiator MUST abort the command by either using the Abort Task task management function request, or a "close the connection" Logout if it intends to continue the session. I think the first part is over specified - there are a number of task management commands that abort the task - if the target is really sick, something much more serious than Abort Task may be used that not only aborts this task, but others. It's not clear whether "if it intends to continue the session" applies only to the logout or to both the task management command and the logout, nor is it clear what an initiator should do if it doesn't intend to continue the session. > I do not follow your issue with T18. Time outs can occur for reason that > are not something that needs more drastic action. If fact I would assume > that it generally does not need other actions. It's actually a minor issue in the text - the current text requires that an Abort Task be issued if the connection is not logged out with the intent to continue the session - it should allow any task management function that aborts a task to be used so that an initiator that decides CLEAR TASK SET or LUN RESET is appropriate doesn't also have to issue additional ABORT TASK functions in order to comply with the MUST. 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 --------------------------------------------------- From owner-ips@ece.cmu.edu Tue Jul 9 03:28:54 2002 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA14967 for ; Tue, 9 Jul 2002 03:28:54 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id g696eC004358 for ips-outgoing; Tue, 9 Jul 2002 02:40:12 -0400 (EDT) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from mailhub.lss.emc.com (xdch.emc.com [168.159.1.79]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id g696eBX04354 for ; Tue, 9 Jul 2002 02:40:11 -0400 (EDT) Received: from emc.com (emcmail.lss.emc.com [168.159.48.78]) by mailhub.lss.emc.com (Switch-2.2.0/Switch-2.2.0) with ESMTP id g696e2E03655; Tue, 9 Jul 2002 02:40:03 -0400 (EDT) Received: from mxic1.isus.emc.com ([168.159.129.100]) by emc.com (8.10.1/8.10.1) with ESMTP id g696e2727067; Tue, 9 Jul 2002 02:40:02 -0400 (EDT) Received: by MXIC1 with Internet Mail Service (5.5.2653.19) id <31WADA9G>; Tue, 9 Jul 2002 02:38:05 -0400 Message-ID: <277DD60FB639D511AC0400B0D068B71E0564C047@CORPMX14> From: Black_David@emc.com To: Julian_Satran@il.ibm.com Cc: ips@ece.cmu.edu Subject: RE: iSCSI: DLB's [T.6] 2.3 iSCSI Session Types Date: Tue, 9 Jul 2002 02:38:02 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C22713.2C4F4690" Sender: owner-ips@ece.cmu.edu Precedence: bulk This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_001_01C22713.2C4F4690 Content-Type: text/plain; charset="iso-8859-1" Julian, Your "at its own risk" is an invitation to interoperability problems - if Discovery sessions are meant to be fixed functionality, then an Initiator that attempts to exceed that functionality needs to get told NO - otherwise we're going to see READ commands on Discovery sessions to get additional configuration information, and then task management, and ... this neat stuff will only work right when the same implementation is on both ends of the connection. I have a separate reply to Ayman's message coming that contains an attempt at requirements text, but it's longer than I would like. Thanks, --David -----Original Message----- From: Julian Satran [mailto:Julian_Satran@il.ibm.com] Sent: Tuesday, July 09, 2002 1:40 AM To: Black_David@emc.com Cc: aghanem@cisco.com; ips@ece.cmu.edu; owner-ips@ece.cmu.edu Subject: RE: iSCSI: DLB's [T.6] 2.3 iSCSI Session Types David, The original MAY was perfectly appropriate and so is the MUST. If you say that you have targets that MAY not support anything else than .. the an initiator attempting to use anything else would do it at its own risk. Your preference for MUST puts an additional mandatory burden to targets to CHECK (all targets) that nothing else is sent. It is strict where none of us thought that we have to be. From an initiator POW they are equivalent. For a target it requires more work. I would favor the way we where ... but that may be all age related. Julo Black_David@emc.com Sent by: owner-ips@ece.cmu.edu 07/08/2002 05:18 PM Please respond to Black_David To: aghanem@cisco.com, ips@ece.cmu.edu cc: Subject: RE: iSCSI: DLB's [T.6] 2.3 iSCSI Session Types Ayman, Something needs to be cleaned up here, as the current text appears to allow all types of iSCSI PDUs on a discovery session. I didn't intend to restrict a discovery session to one Send Targets followed by a logout (i.e., it could be kept open with the initiator periodically sending a new Send Targets to see if anything has changed), but I did intend to forbid SCSI commands, task management, etc. on Discovery sessions. Is that reasonable, or are there additional types of iSCSI PDUs that you want to see allowed for new device notifications? Thanks, --David > -----Original Message----- > From: Ayman Ghanem [mailto:aghanem@cisco.com] > Sent: Sunday, July 07, 2002 12:41 PM > To: ips@ece.cmu.edu > Subject: RE: iSCSI: DLB's [T.6] 2.3 iSCSI Session Types > > > I prefer leaving this as "MAY" for implementations that want > to support new > device notifications. There was a discussion on whether > discovery sessions > should be long-lived or not. Using MAY allows both without > breaking any > thing. > > -Ayman > > > [T.6] 2.3 iSCSI Session Types > > > > b) Discovery-session - a session opened only for > target discov- > > ery; the target MAY accept only text requests with > the SendTar- > > gets key and a logout request with reason "close the session". > > > > Change "MAY" to "MUST", and say that other requests MUST be > rejected. > > > ------_=_NextPart_001_01C22713.2C4F4690 Content-Type: text/html; charset="iso-8859-1"
Julian,
 
Your "at its own risk" is an invitation to interoperability problems -
if Discovery sessions are meant to be fixed functionality, then an
Initiator that attempts to exceed that functionality needs to get
told NO - otherwise we're going to see READ commands on Discovery
sessions to get additional configuration information, and then
task management, and ... this neat stuff will only work right
when the same implementation is on both ends of the connection.
 
I have a separate reply to Ayman's message coming that contains
an attempt at requirements text, but it's longer than I would like.
 
Thanks,
--David
 
-----Original Message-----
From: Julian Satran [mailto:Julian_Satran@il.ibm.com]
Sent: Tuesday, July 09, 2002 1:40 AM
To: Black_David@emc.com
Cc: aghanem@cisco.com; ips@ece.cmu.edu; owner-ips@ece.cmu.edu
Subject: RE: iSCSI: DLB's [T.6] 2.3 iSCSI Session Types


David,

The original MAY was perfectly appropriate and so is the MUST.
If you say that you have targets that MAY not support anything else than .. the an initiator attempting to use anything else
would do it at its own risk.
Your preference for MUST puts an additional mandatory burden to targets to CHECK (all targets) that nothing else
is sent.

It is strict where none of us thought that we have to be.

From an initiator POW they are equivalent.
For a target it requires more work.

I would favor the way we where ... but that may be all age related.

Julo



Black_David@emc.com
Sent by: owner-ips@ece.cmu.edu

07/08/2002 05:18 PM
Please respond to Black_David

       
        To:        aghanem@cisco.com, ips@ece.cmu.edu
        cc:        
        Subject:        RE: iSCSI: DLB's [T.6] 2.3  iSCSI Session Types

       


Ayman,

Something needs to be cleaned up here, as the current text appears
to allow all types of iSCSI PDUs on a discovery session.  I didn't
intend to restrict a discovery session to one Send Targets followed
by a logout (i.e., it could be kept open with the initiator periodically
sending a new Send Targets to see if anything has changed), but I
did intend to forbid SCSI commands, task management, etc. on Discovery
sessions.  Is that reasonable, or are there additional types of iSCSI
PDUs that you want to see allowed for new device notifications?

Thanks,
--David

> -----Original Message-----
> From: Ayman Ghanem [mailto:aghanem@cisco.com]
> Sent: Sunday, July 07, 2002 12:41 PM
> To: ips@ece.cmu.edu
> Subject: RE: iSCSI: DLB's [T.6] 2.3 iSCSI Session Types
>
>
> I prefer leaving this as "MAY" for implementations that want
> to support new
> device notifications. There was a discussion on whether
> discovery sessions
> should be long-lived or not. Using MAY allows both without
> breaking any
> thing.
>
> -Ayman
>
> > [T.6] 2.3  iSCSI Session Types
> >
> >       b)  Discovery-session - a session opened only for
> target discov-
> >       ery; the target MAY accept only text requests with
> the SendTar-
> >       gets key and a logout request with reason "close the session".
> >
> > Change "MAY" to "MUST", and say that other requests MUST be
> rejected.
> >
>


------_=_NextPart_001_01C22713.2C4F4690-- From owner-ips@ece.cmu.edu Tue Jul 9 04:10:28 2002 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA14808 for ; Tue, 9 Jul 2002 03:23:14 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id g696kpI04672 for ips-outgoing; Tue, 9 Jul 2002 02:46:51 -0400 (EDT) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from mxic2.corp.emc.com (mxic2.isus.emc.com [128.221.31.40]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id g696koX04668 for ; Tue, 9 Jul 2002 02:46:50 -0400 (EDT) Received: by mxic2.corp.emc.com with Internet Mail Service (5.5.2653.19) id <31X6QHAR>; Tue, 9 Jul 2002 02:46:44 -0400 Message-ID: <277DD60FB639D511AC0400B0D068B71E0564C04B@CORPMX14> From: Black_David@emc.com To: hufferd@us.ibm.com Cc: ips@ece.cmu.edu Subject: iSCSI: editorial rewrite not needed Date: Tue, 9 Jul 2002 02:44:47 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-ips@ece.cmu.edu Precedence: bulk John, My original text was: Global Editorial comment: Both the login (4) and error handling (6) sections feel like one of those old Adventure mazes of twisty little passages - all the details seem to be there, for the most part they're correct, but it's very hard to get the proverbial "big picture" of how everything fits together, in terms of how the various mechanisms work with each other and how they accomplish the overall functionality. Both of these could use overview sections describing how the functionality breaks down into the pieces described in the subsections and how they fit together. Swapping the order of Sections 5 and 6 would also be a good idea so that the discussion of Error Handling and Recovery comes before the state machine descriptions that contain a lot of the details of how errors are handled. For error handling, moving Section 6.13 to the front of Section 6 would help organize the Section better, and care should be taken to define or replace terms like "restart login" and "recovery R2T" that are currently used without definitions. > I disagree with the editorial rewrite, especially at this late state. If > they were important that should have been brought up earlier. I fail to see how you got from my original text whose primary request was for "overview sections describing ..." to "editorial rewrite", so I think you're seriously over-reacting. Concerns about comprehensibility have been brought up on the list in the past. > We should > not be discussing editorial style, but whether we have correctly specified > the protocol. This isn't about "editorial style", but rather whether the specification is comprehensible to an implementer who picks it up from scratch without the benefit of this group's email discussions, short term memory, etc. > We have already changed it a couple of times, and you are > now wanting it changed again. This is a very big spec, and each time we > make changes to pretty up the document, the more that is needed, and > someone else has another preference. If the spec has problems, Working Group Last Call is the point in time to find and fix them, and if that takes serious effort, c'est la vie. I'm prepared to listen to arguments that the spec is sufficiently comprehensible as to need no editorial changes, but I'm not inclined to assign them a great deal of credibility at this juncture. > It is already better then most of the > other IETF specs. I think this causes a needless delay. I disagree and take exception to the view that iSCSI is needlessly being held to a higher standard. The need for a comprehensible spec is real, and that is not a higher standard than other IETF specs are generally held to, although there are some that have gotten away - IKE/ISAKMP and the related keying portions of IPsec are an example that we are unfortunately familiar with. It should not take an iSCSI guru with a secret decoder ring to unscramble how the protocol works even if all the interacting pieces are correctly specified somewhere in the document. On further reflection, I think that an overview section on error handling in the current Section 6 plus swapping the order of Section 5 and Section 6 probably removes the need to tease apart the initiator and target state machine specifications in the current Section 5 (my comments E.80 and E.81). That should reduce the amount of work required provided that the overview text for error handling is well- written. 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 --------------------------------------------------- From owner-ips@ece.cmu.edu Tue Jul 9 10:16:12 2002 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA26318 for ; Tue, 9 Jul 2002 10:16:11 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id g69DLiV01831 for ips-outgoing; Tue, 9 Jul 2002 09:21:44 -0400 (EDT) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from mail.SURGIENT.COM (mail.surgient.com [63.118.236.3]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id g69DLgX01826 for ; Tue, 9 Jul 2002 09:21:42 -0400 (EDT) X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4522.1200 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Subject: remove Date: Tue, 9 Jul 2002 08:21:35 -0500 Message-ID: Thread-Topic: remove Thread-Index: AcInS4yx8r7NbsTuR2+JgPKqzfh5HQ== Importance: normal From: "Johnson, Scott" To: Sender: owner-ips@ece.cmu.edu Precedence: bulk Content-Transfer-Encoding: 7bit ------------------------------- This e-mail is for the sole use of the intended recipient and may contain confidential and privileged information. Any unauthorized review, use or disclosure is strictly prohibited. If you are not the intended recipient of this e-mail, please notify sender and delete all copies immediately. From owner-ips@ece.cmu.edu Tue Jul 9 10:17:20 2002 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA26373 for ; Tue, 9 Jul 2002 10:17:15 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id g69Dj7603373 for ips-outgoing; Tue, 9 Jul 2002 09:45:07 -0400 (EDT) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from lmail.actcom.co.il (IDENT:root@mail.actcom.co.il [192.114.47.13]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id g69Dj3X03365 for ; Tue, 9 Jul 2002 09:45:03 -0400 (EDT) Received: from JA31 ([192.115.26.20]) by lmail.actcom.co.il (8.11.6/8.11.6) with ESMTP id g69Dibe07248; Tue, 9 Jul 2002 16:44:37 +0300 Message-ID: <003301c2274e$bf59a210$0200000a@JA31> From: "Julian Satran \(Actcom\)" To: "KRUEGER,MARJORIE \(HP-Roseville,ex1\)" , "'Jim Hafner'" , Cc: "ips" References: <6BD67FFB937FD411A04F00D0B74FE87805CCF6BA@xrose06.rose.hp.com> Subject: Re: iSCSI: DLB's Comment on SCSI Port Names Date: Tue, 9 Jul 2002 16:44:26 +0300 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_002E_01C22767.E362E860" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2600.0000 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 Sender: owner-ips@ece.cmu.edu Precedence: bulk This is a multi-part message in MIME format. ------=_NextPart_000_002E_01C22767.E362E860 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Marjorie, I'll list this as issue 37 and I think we can settle on 249 :-) I would appreciate if you let me know what constants change (in 2.4.2?) Julo ----- Original Message -----=20 From: KRUEGER,MARJORIE (HP-Roseville,ex1)=20 To: 'Jim Hafner' ; Black_David@emc.com=20 Cc: ips@ece.cmu.edu=20 Sent: Tuesday, July 09, 2002 4:04 AM Subject: RE: iSCSI: DLB's Comment on SCSI Port Names I've just encountered this issue with regards to iSCSI port name = encoding in the SCSI MIB, and the currently specified port name encoding = causes inconvenience (at best). IMO, it makes sense to be able to treat = an iSCSI name field, be it device name or port name, the same - as a = string of display characters, portions of which may contain = ASCII-encoded numeric values. I don't really see that it makes a difference whether one views ISID = and TPGT as numeric strings or values, since as Jim says, there are no = calculations performed using these things, and they are basicly just = "tags". The issue for me is that the rest of the "SCSI port name" is a = string and I see no value in "encoding" the ISID or TPGT as a value for = SCSI purposes, as SCSI should have no need to use the ISID or TPGT = values separately from the entire port name. And even if SCSI had such = a need, it's a simple matter to convert a numeric string representation = to a value. The downside of a string-encoding is the increased maximum size of the = SCSI port name. If strings over 256 characters are a problem for some platforms, I'd = be in favor of reducing the max iSCSI node name to 249 characters so the = maximum SCSI port name would be 255 characters total (249 char name + = ",i," + "0x0000") Marjorie Krueger Networked Storage Architecture Networked Storage Solutions Org. Hewlett-Packard -----Original Message----- From: Jim Hafner [mailto:hafner@almaden.ibm.com] Sent: Monday, July 08, 2002 9:08 AM To: Black_David@emc.com Cc: ips@ece.cmu.edu Subject: RE: iSCSI: DLB's Comment on SCSI Port Names David,=20 I believe it will (may?) be used, so I agree we're in the second = case. However, this format is the intended use in SCSI protocol stuff. = Two places where SCSI ports names are used now is in ALIAS, Access = Controls and in third party reservations -- see caveat below, however)=20 I don't see a need in this context to define these as strings = (that's not a SCSI way of thinking...). =20 However, I think the issue comes down to a simple question: are the = ISID and TPGT values or numerical strings (Julian is calling them = numerical strings, but I've always thought of them as values, in spite = of the fact that there is no arithmetic done on them - there is = precedent in SCSI for such thinking, so I'm not completely out in the = woods here).=20 If they are values, then I'd like to see them formatted for SCSI in = "value form"; if they are strings, then any representation should be = OK.=20 Does that at least get to the core of the issue? Jim Hafner CAVEAT: I don't think we'd use the iSCSI constructed port names in = those contexts as device names are better suited for those purposes, but = these are examples where specification of SCSI port name format is = required.=20 To: Jim Hafner/Almaden/IBM@IBMUS=20 cc: ips@ece.cmu.edu=20 Subject: RE: iSCSI: DLB's Comment on SCSI Port Names=20 Jim, My view of this is that either: - The SCSI Port Name is never going to be used, in which case=20 it shouldn't be designed to this level of detail. OR - It's going to be used, and hence is worth designing in a fashion=20 that is reasonable to use. I think we're in the second category, and turning the ISID into hex ASCII (well, UTF-8) so the SCSI port name is a string is worth doing now to avoid problems when people actually try to use it. I would have no problems if someone wanted to pad the string, but I'd make specifying the padding the responsibility of the protocol/API/situation in which it was used rather than incorporating the padding into the name. Thanks, --David -----Original Message----- From: Jim Hafner [mailto:hafner@almaden.ibm.com] Sent: Monday, July 08, 2002 11:42 AM To: Black_David@emc.com Cc: ips@ece.cmu.edu Subject: Re: iSCSI: DLB's Comment on SCSI Port Names David, You wrote: >[T.9] 2.4.2 SCSI Architecture Model > > The SCSI Port Name is mandatory in iSCSI. When used in SCSI > parameter data, the SCSI port name MUST be encoded as: > - The iSCSI Name in UTF-8 format, followed by > - a comma separator (1 byte), followed by > - the ASCII character 'i' (for SCSI Initiator Port) or the > ASCII character 't' (for SCSI Target Port), followed by > - a comma separator (1 byte), followed by > - zero to 3 null pad bytes so that the complete format is a > multiple of four bytes long, followed by > - the 6byte value of the ISID (for SCSI initiator port) or the > 2byte value of the portal group tag (for SCSI target port) in > network byte order (BigEndian). > That's a peculiar format with padding nulls in the middle and > a number concatenated after the padding - for example, it can't > be passed in iSCSI login without format conversion. How about > converting the number to 4 or 12 bytes of hex (ASCII characters) > and moving the padding to the end so the result is actually a > string, and excluding the padding from the definition of the name? > This will increase the maximum length of port names, but produce > names that are easier to deal with. Admittedly that's an odd format, however here was the reason for = this layout. 1) it's not used directly in iSCSI "Text" strings; it's intended to = be a description of how this information is packed into a byte array for representation in "SCSI parameter data" (as it says!) -- that is, = it's NEVER "passed in iSCSI login" (in this form). 2) the padding after the string was to force the binary values of = the ISID or PGT to be better word aligned and can be more easily extracted as = a value direct from the byte array without conversion. What do you think? Jim Hafner=20 ------=_NextPart_000_002E_01C22767.E362E860 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
Marjorie,
 
I'll list this as issue 37 and I think = we can=20 settle on 249 :-)
I would appreciate if you let me know = what=20 constants change (in 2.4.2?)
 
Julo
----- Original Message -----
From:=20 KRUEGER,MARJORIE = (HP-Roseville,ex1)=20
To: 'Jim Hafner' ; Black_David@emc.com
Sent: Tuesday, July 09, 2002 = 4:04=20 AM
Subject: RE: iSCSI: DLB's = Comment on SCSI=20 Port Names

I've just encountered this issue with = regards to=20 iSCSI port name encoding in the SCSI MIB, and the currently specified = port=20 name encoding causes inconvenience (at best).  IMO, it makes = sense to be=20 able to treat an iSCSI name field, be it device name or port name, the = same=20 - as a string of display characters, portions of which may = contain=20 ASCII-encoded numeric values.
 
I don't really see that it makes a = difference whether=20 one views ISID and TPGT as numeric strings or values, since as Jim = says, there=20 are no calculations performed using these things, and they are basicly = just=20 "tags".  The issue for me is that the rest of the "SCSI port = name" is a=20 string and I see no value in "encoding" the ISID or TPGT as a value = for SCSI=20 purposes, as SCSI should have no need to use the ISID or TPGT values=20 separately from the entire port name.  And even if SCSI had such = a need,=20 it's a simple matter to convert a numeric string representation to a=20 value.
 
The downside of a = string-encoding is the increased maximum size of = the SCSI=20 port name.
 
If strings over 256 characters are a = problem for some=20 platforms, I'd be in favor of reducing the max iSCSI node name to 249=20 characters so the maximum SCSI port name would be 255 characters total = (249=20 char name + ",i," + "0x0000")
 
Marjorie Krueger
Networked Storage=20 Architecture
Networked Storage Solutions=20 Org.
Hewlett-Packard
-----Original Message-----
From: Jim Hafner=20 [mailto:hafner@almaden.ibm.com]
Sent: Monday, July 08, = 2002 9:08=20 AM
To: Black_David@emc.com
Cc:=20 ips@ece.cmu.edu
Subject: RE: iSCSI: DLB's Comment on SCSI = Port=20 Names


David,=20

I believe it will (may?) be = used, so I=20 agree we're in the second case.  However, this format is the = intended=20 use in SCSI protocol stuff.  Two places where SCSI ports names = are used=20 now is in ALIAS, Access Controls and in third party reservations -- = see=20 caveat below, however)

I don't=20 see a need in this context to define these as strings (that's not a = SCSI way=20 of thinking...).  

However,=20 I think the issue comes down to a simple question:  are the = ISID and=20 TPGT values or numerical strings (Julian is calling them numerical = strings,=20 but I've always thought of them as values, in spite of the fact that = there=20 is no arithmetic done on them - there is precedent in SCSI for such=20 thinking, so I'm not completely out in the woods here). =

If they are values, then I'd like to see = them=20 formatted for SCSI in "value form";  if they are strings, then = any=20 representation should be OK.

Does that at least get to the core of the issue?

Jim = Hafner

CAVEAT: I = don't think we'd=20 use the iSCSI constructed port names in those contexts as device = names are=20 better suited for those purposes, but these are examples where = specification=20 of SCSI port name format is required.

To:   =    =20  Jim=20 Hafner/Almaden/IBM@IBMUS
cc:        ips@ece.cmu.edu=20
Subject: =    =20    RE: iSCSI: = DLB's Comment on=20 SCSI Port Names



Jim,

My view of = this is that=20 either:
- The SCSI Port Name is never going to be used, in which=20 case
it shouldn't be designed to = this level=20 of detail. OR
- It's going to be used, and hence is worth = designing in a=20 fashion
that is reasonable to = use.
I=20 think we're in the second category, and turning the ISID into
hex = ASCII=20 (well, UTF-8) so the SCSI port name is a string is
worth doing = now to=20 avoid problems when people actually try
to use it.  I would = have no=20 problems if someone wanted to
pad the string, but I'd make = specifying the=20 padding the
responsibility of the protocol/API/situation in which = it
was used rather than incorporating the padding into the=20 name.

Thanks,
--David

-----Original Message-----
From: Jim Hafner=20 [mailto:hafner@almaden.ibm.com]
Sent: Monday, July 08, 2002 11:42 = AM
To: Black_David@emc.com
Cc: ips@ece.cmu.edu
Subject: Re: = iSCSI:=20 DLB's Comment on SCSI Port Names



David,

You=20 wrote:

>[T.9] 2.4.2 =  SCSI=20 Architecture Model
>
>  The SCSI Port Name is = mandatory in=20 iSCSI. When used in SCSI
>  parameter data, the SCSI port = name=20 MUST be encoded as:
>  - The iSCSI Name in UTF-8 format, = followed=20 by
>  - a comma separator (1 byte), followed by
> =  -=20 the ASCII character 'i' (for SCSI Initiator Port) or the
> =  =20  ASCII character 't' (for SCSI Target Port), followed = by
>=20  - a comma separator (1 byte), followed by
>  - zero = to 3=20 null pad bytes so that the complete format is a
>  =20  multiple of four bytes long, followed by
>  - the = 6byte=20 value of the ISID (for SCSI initiator port) or the
>  =20  2byte value of the portal group tag (for SCSI target port) = in
>=20    network byte order = (BigEndian).

> That's a peculiar format with padding nulls in the = middle=20 and
> a number concatenated after the padding - for example, = it=20 can't
> be passed in iSCSI login without format conversion. =  How=20 about
> converting the number to 4 or 12 bytes of hex (ASCII=20 characters)
> and moving the padding to the end so the result = is=20 actually a
> string, and excluding the padding from the = definition of=20 the name?
> This will increase the maximum length of port = names, but=20 produce
> names that are easier to deal = with.

Admittedly that's an odd format, however here was the = reason for=20 this
layout.
1) it's not used directly in iSCSI "Text" = strings; it's=20 intended to be a
description of how this information is packed = into a=20 byte array for
representation in "SCSI parameter data" (as it = says!) --=20 that is, it's NEVER
"passed in iSCSI login" (in this form).
2) = the=20 padding after the string was to force the binary values of the = ISID
or=20 PGT to be better word aligned and can be more easily extracted as a=20 value
direct from the byte array without=20 conversion.

What do you=20 think?

Jim Hafner=20

------=_NextPart_000_002E_01C22767.E362E860-- From owner-ips@ece.cmu.edu Tue Jul 9 10:59:00 2002 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA27892 for ; Tue, 9 Jul 2002 10:59:00 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id g69E8IS04838 for ips-outgoing; Tue, 9 Jul 2002 10:08:18 -0400 (EDT) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from cygnus.equallogic.com (cygnus.equallogic.com [65.170.102.10]) by ece.cmu.edu (8.11.0/8.10.2) with SMTP id g69E8GX04833 for ; Tue, 9 Jul 2002 10:08:17 -0400 (EDT) Received: from cygnus.equallogic.com (localhost.localdomain [127.0.0.1]) by cygnus.equallogic.com (8.11.6/8.11.6) with ESMTP id g69E8BC01159 for ; Tue, 9 Jul 2002 10:08:11 -0400 Received: from deneb.dev.equallogic.com (deneb.dev.equallogic.com [172.16.1.99]) by cygnus.equallogic.com (8.11.6/8.11.6) with ESMTP id g69E8AQ01146; Tue, 9 Jul 2002 10:08:10 -0400 Received: from pkoning.dev.equallogic.com.equallogic.com (localhost.localdomain [127.0.0.1]) by deneb.dev.equallogic.com (8.11.6/8.11.6) with SMTP id g69E8AT21045; Tue, 9 Jul 2002 10:08:10 -0400 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <15658.61002.380623.673790@pkoning.dev.equallogic.com> Date: Tue, 9 Jul 2002 10:08:10 -0400 From: Paul Koning To: Julian_Satran@il.ibm.com Cc: ips@ece.cmu.edu Subject: Re: iSCSI - decimal coded binary strings - a proposed resolution References: X-Mailer: VM 7.01 under 21.1 (patch 11) "Carlsbad Caverns" XEmacs Lucid Sender: owner-ips@ece.cmu.edu Precedence: bulk Content-Transfer-Encoding: 7bit >>>>> "Julian" == Julian Satran writes: Julian> Paul - I think we are talking again about two different Julian> thinks: Julian> numerical values that could be more than 2**64 - I would not Julian> forbid it there Julian> bit strings that could be longer than 64 bits - I find it Julian> acceptable Julian> The new text could be: Julian> decimal-constant: an unsigned decimal number - the digit 0 or Julian> a string of 1 or more digits starting with a non-zero digit. Julian> Decimal-constants are used to encode numerical values or Julian> binary strings. Decimal constants can be used to encode Julian> binary strings only if the stringlength is explicitly Julian> speci-fied. There is no implicit length for decimal Julian> strings. This encoding MUST NOT used for numerical values Julian> equal or greater than 2**64 or binary strings that could be Julian> longer than 64 bits. There currently are no numeric values >= 2**64. But in any case, I don't like the idea there either. What I proposed makes the encoding an attribute of the parameter -- either it can always be encoded in decimal, or it never can be. What you're proposing does that for binary strings. But for numeric values, the encoding permitted would depend on the particular value. I don't see any sense in that extra complexity. paul From owner-ips@ece.cmu.edu Tue Jul 9 11:31:28 2002 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA29316 for ; Tue, 9 Jul 2002 11:31:28 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id g69EsWm08301 for ips-outgoing; Tue, 9 Jul 2002 10:54:32 -0400 (EDT) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from mtv01owa01.mindtree.com ([202.56.254.10]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id g69EsSX08293 for ; Tue, 9 Jul 2002 10:54:29 -0400 (EDT) Received: from mtv01ex01.mindtree.com ([172.20.32.4]) by mtv01owa01.mindtree.com with Microsoft SMTPSVC(5.0.2195.4453); Tue, 9 Jul 2002 20:21:56 +0530 X-MimeOLE: Produced By Microsoft Exchange V6.0.5762.3 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Subject: remove Date: Tue, 9 Jul 2002 20:21:56 +0530 Message-ID: Thread-Topic: remove Thread-Index: AcInS4yx8r7NbsTuR2+JgPKqzfh5HQADJX1A From: "Chhavi Garg" To: X-OriginalArrivalTime: 09 Jul 2002 14:51:56.0778 (UTC) FILETIME=[2BF384A0:01C22758] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ece.cmu.edu id g69EsUX08295 Sender: owner-ips@ece.cmu.edu Precedence: bulk Content-Transfer-Encoding: 8bit From owner-ips@ece.cmu.edu Tue Jul 9 11:39:20 2002 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA29527 for ; Tue, 9 Jul 2002 11:39:20 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id g69FDOM09676 for ips-outgoing; Tue, 9 Jul 2002 11:13:24 -0400 (EDT) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from e1.ny.us.ibm.com (e1.ny.us.ibm.com [32.97.182.101]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id g69FDMX09672 for ; Tue, 9 Jul 2002 11:13:22 -0400 (EDT) Received: from westrelay04.boulder.ibm.com (westrelay04.boulder.ibm.com [9.17.192.94]) by e1.ny.us.ibm.com (8.12.2/8.12.2) with ESMTP id g69FDFg5269720; Tue, 9 Jul 2002 11:13:15 -0400 Received: from d03nmar1.almaden.ibm.com (d03nmar1.almaden.ibm.com [9.1.20.239]) by westrelay04.boulder.ibm.com (8.11.1m3/NCO/VER6.2) with ESMTP id g69FCPC69614; Tue, 9 Jul 2002 09:12:26 -0600 Importance: Normal To: "KRUEGER,MARJORIE (HP-Roseville,ex1)" Cc: Black_David@emc.com, ips@ece.cmu.edu Subject: RE: iSCSI: DLB's Comment on SCSI Port Names X-Mailer: Lotus Notes Release 5.0.3 (Intl) 21 March 2000 Message-ID: From: "Jim Hafner" Date: Tue, 9 Jul 2002 08:13:41 -0700 X-MIMETrack: Serialize by Router on D03NMAR1/03/M/IBM(Build M13TT_06262002 Pre-release 2|June 26, 2002) at 07/09/2002 08:13:45, Serialize complete at 07/09/2002 08:13:45 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="=_alternative 00538D3C88256BF1_=" Sender: owner-ips@ece.cmu.edu Precedence: bulk This is a multipart message in MIME format. --=_alternative 00538D3C88256BF1_= Content-Type: text/plain; charset="us-ascii" Marj, David, After this discussion, I don't have any problem with converting the entire SCSI port name to a string. It's opaque as far as SCSI is concerned in any case, so it really doesn't matter. As for restricting the length of iSCSI Names so iSCS's SCSI port names fit 256 limit (including null), I have no opinion. Oh, and Marj: did you get the math right if the ISID is 6 bytes (so 12 hex characters)? Whatever change we make here needs to propogate to Annex A of SAM2 where information about these names are specified (for informational purposes only). As in that Blind Faith song: "do what you like"... Jim Hafner To: Jim Hafner/Almaden/IBM@IBMUS, Black_David@emc.com cc: ips@ece.cmu.edu Subject: RE: iSCSI: DLB's Comment on SCSI Port Names I've just encountered this issue with regards to iSCSI port name encoding in the SCSI MIB, and the currently specified port name encoding causes inconvenience (at best). IMO, it makes sense to be able to treat an iSCSI name field, be it device name or port name, the same - as a string of display characters, portions of which may contain ASCII-encoded numeric values. I don't really see that it makes a difference whether one views ISID and TPGT as numeric strings or values, since as Jim says, there are no calculations performed using these things, and they are basicly just "tags". The issue for me is that the rest of the "SCSI port name" is a string and I see no value in "encoding" the ISID or TPGT as a value for SCSI purposes, as SCSI should have no need to use the ISID or TPGT values separately from the entire port name. And even if SCSI had such a need, it's a simple matter to convert a numeric string representation to a value. The downside of a string-encoding is the increased maximum size of the SCSI port name. If strings over 256 characters are a problem for some platforms, I'd be in favor of reducing the max iSCSI node name to 249 characters so the maximum SCSI port name would be 255 characters total (249 char name + ",i," + "0x0000") Marjorie Krueger Networked Storage Architecture Networked Storage Solutions Org. Hewlett-Packard -----Original Message----- From: Jim Hafner [mailto:hafner@almaden.ibm.com] Sent: Monday, July 08, 2002 9:08 AM To: Black_David@emc.com Cc: ips@ece.cmu.edu Subject: RE: iSCSI: DLB's Comment on SCSI Port Names David, I believe it will (may?) be used, so I agree we're in the second case. However, this format is the intended use in SCSI protocol stuff. Two places where SCSI ports names are used now is in ALIAS, Access Controls and in third party reservations -- see caveat below, however) I don't see a need in this context to define these as strings (that's not a SCSI way of thinking...). However, I think the issue comes down to a simple question: are the ISID and TPGT values or numerical strings (Julian is calling them numerical strings, but I've always thought of them as values, in spite of the fact that there is no arithmetic done on them - there is precedent in SCSI for such thinking, so I'm not completely out in the woods here). If they are values, then I'd like to see them formatted for SCSI in "value form"; if they are strings, then any representation should be OK. Does that at least get to the core of the issue? Jim Hafner CAVEAT: I don't think we'd use the iSCSI constructed port names in those contexts as device names are better suited for those purposes, but these are examples where specification of SCSI port name format is required. To: Jim Hafner/Almaden/IBM@IBMUS cc: ips@ece.cmu.edu Subject: RE: iSCSI: DLB's Comment on SCSI Port Names Jim, My view of this is that either: - The SCSI Port Name is never going to be used, in which case it shouldn't be designed to this level of detail. OR - It's going to be used, and hence is worth designing in a fashion that is reasonable to use. I think we're in the second category, and turning the ISID into hex ASCII (well, UTF-8) so the SCSI port name is a string is worth doing now to avoid problems when people actually try to use it. I would have no problems if someone wanted to pad the string, but I'd make specifying the padding the responsibility of the protocol/API/situation in which it was used rather than incorporating the padding into the name. Thanks, --David -----Original Message----- From: Jim Hafner [mailto:hafner@almaden.ibm.com] Sent: Monday, July 08, 2002 11:42 AM To: Black_David@emc.com Cc: ips@ece.cmu.edu Subject: Re: iSCSI: DLB's Comment on SCSI Port Names David, You wrote: >[T.9] 2.4.2 SCSI Architecture Model > > The SCSI Port Name is mandatory in iSCSI. When used in SCSI > parameter data, the SCSI port name MUST be encoded as: > - The iSCSI Name in UTF-8 format, followed by > - a comma separator (1 byte), followed by > - the ASCII character 'i' (for SCSI Initiator Port) or the > ASCII character 't' (for SCSI Target Port), followed by > - a comma separator (1 byte), followed by > - zero to 3 null pad bytes so that the complete format is a > multiple of four bytes long, followed by > - the 6byte value of the ISID (for SCSI initiator port) or the > 2byte value of the portal group tag (for SCSI target port) in > network byte order (BigEndian). > That's a peculiar format with padding nulls in the middle and > a number concatenated after the padding - for example, it can't > be passed in iSCSI login without format conversion. How about > converting the number to 4 or 12 bytes of hex (ASCII characters) > and moving the padding to the end so the result is actually a > string, and excluding the padding from the definition of the name? > This will increase the maximum length of port names, but produce > names that are easier to deal with. Admittedly that's an odd format, however here was the reason for this layout. 1) it's not used directly in iSCSI "Text" strings; it's intended to be a description of how this information is packed into a byte array for representation in "SCSI parameter data" (as it says!) -- that is, it's NEVER "passed in iSCSI login" (in this form). 2) the padding after the string was to force the binary values of the ISID or PGT to be better word aligned and can be more easily extracted as a value direct from the byte array without conversion. What do you think? Jim Hafner --=_alternative 00538D3C88256BF1_= Content-Type: text/html; charset="us-ascii"
Marj, David,

After this discussion, I don't have any problem with converting the entire SCSI port name to a string.  It's opaque as far as SCSI is concerned in any case, so it really doesn't matter.

As for restricting the length of iSCSI Names so iSCS's SCSI port names fit 256 limit (including null), I have no opinion.
Oh, and Marj: did you get the math right if the ISID is 6 bytes (so 12 hex characters)?

Whatever change we make here needs to propogate to Annex A of SAM2 where information about these names are specified (for informational purposes only).

As in that Blind Faith song: "do what you like"...

Jim Hafner

To:        Jim Hafner/Almaden/IBM@IBMUS, Black_David@emc.com
cc:        ips@ece.cmu.edu
Subject:        RE: iSCSI: DLB's Comment on SCSI Port Names




I've just encountered this issue with regards to iSCSI  port name encoding in the SCSI MIB, and the currently specified port name  encoding causes inconvenience (at best).  IMO, it makes sense to be able to  treat an iSCSI name field, be it device name or port name, the same - as a  string of display characters, portions of which may contain  ASCII-encoded numeric values.
 
I don't really see that it makes a difference whether  one views ISID and TPGT as numeric strings or values, since as Jim says, there  are no calculations performed using these things, and they are basicly just  "tags".  The issue for me is that the rest of the "SCSI port name" is a  string and I see no value in "encoding" the ISID or TPGT as a value for SCSI  purposes, as SCSI should have no need to use the ISID or TPGT values separately  from the entire port name.  And even if SCSI had such a need, it's a simple  matter to convert a numeric string representation to a  value.
 
The downside of a string-encoding  is the increased maximum size of the SCSI port name.
 
If strings over 256 characters are a problem for some  platforms, I'd be in favor of reducing the max iSCSI node name to 249 characters  so the maximum SCSI port name would be 255 characters total (249 char name +  ",i," + "0x0000")
 
Marjorie Krueger
Networked Storage  Architecture
Networked Storage Solutions  Org.
Hewlett-Packard

-----Original Message-----
From: Jim Hafner  [mailto:hafner@almaden.ibm.com]
Sent: Monday, July 08, 2002 9:08  AM
To: Black_David@emc.com
Cc:  ips@ece.cmu.edu
Subject: RE: iSCSI: DLB's Comment on SCSI Port  Names



David,  

I believe it will (may?) be used, so I  agree we're in the second case.  However, this format is the intended use  in SCSI protocol stuff.  Two places where SCSI ports names are used now  is in ALIAS, Access Controls and in third party reservations -- see caveat  below, however)

I don't see a need  in this context to define these as strings (that's not a SCSI way of  thinking...).  

However, I  think the issue comes down to a simple question:  are the ISID and TPGT  values or numerical strings (Julian is calling them numerical strings, but  I've always thought of them as values, in spite of the fact that there is no  arithmetic done on them - there is precedent in SCSI for such thinking, so I'm  not completely out in the woods here).

If they are values, then I'd like to see them formatted for SCSI in  "value form";  if they are strings, then any representation should be  OK.

Does that at least get to the  core of the issue?

Jim Hafner

CAVEAT: I don't think we'd use the iSCSI constructed port names in  those contexts as device names are better suited for those purposes, but these  are examples where specification of SCSI port name format is required.  

To:         Jim Hafner/Almaden/IBM@IBMUS  
cc:         ips@ece.cmu.edu
Subject:        RE: iSCSI: DLB's Comment on SCSI Port Names  



Jim,

My  view of this is that either:
- The SCSI Port Name is never going to be  used, in which case
it shouldn't be designed  to this level of detail. OR
- It's going to be used, and hence is worth  designing in a fashion
that is reasonable to  use.
I think we're in the second category, and turning the ISID into
hex  ASCII (well, UTF-8) so the SCSI port name is a string is
worth doing now to  avoid problems when people actually try
to use it.  I would have no  problems if someone wanted to
pad the string, but I'd make specifying the  padding the
responsibility of the protocol/API/situation in which it
was  used rather than incorporating the padding into the  name.

Thanks,
--David

-----Original Message-----
From: Jim Hafner  [mailto:hafner@almaden.ibm.com]
Sent: Monday, July 08, 2002 11:42 AM
To:  Black_David@emc.com
Cc: ips@ece.cmu.edu
Subject: Re: iSCSI: DLB's  Comment on SCSI Port Names



David,

You  wrote:

>[T.9] 2.4.2  SCSI  Architecture Model
>
>  The SCSI Port Name is mandatory in  iSCSI. When used in SCSI
>  parameter data, the SCSI port name MUST  be encoded as:
>  - The iSCSI Name in UTF-8 format, followed  by
>  - a comma separator (1 byte), followed by
>  - the  ASCII character 'i' (for SCSI Initiator Port) or the
>     ASCII character 't' (for SCSI Target Port), followed by
>  -  a comma separator (1 byte), followed by
>  - zero to 3 null pad  bytes so that the complete format is a
>    multiple of four  bytes long, followed by
>  - the 6byte value of the ISID (for SCSI  initiator port) or the
>    2byte value of the portal group  tag (for SCSI target port) in
>    network byte order  (BigEndian).

> That's a peculiar format  with padding nulls in the middle and
> a number concatenated after the  padding - for example, it can't
> be passed in iSCSI login without  format conversion.  How about
> converting the number to 4 or 12  bytes of hex (ASCII characters)
> and moving the padding to the end so  the result is actually a
> string, and excluding the padding from the  definition of the name?
> This will increase the maximum length of port  names, but produce
> names that are easier to deal  with.

Admittedly that's an odd format,  however here was the reason for this
layout.
1) it's not used directly  in iSCSI "Text" strings; it's intended to be a
description of how this  information is packed into a byte array for
representation in "SCSI  parameter data" (as it says!) -- that is, it's NEVER
"passed in iSCSI  login" (in this form).
2) the padding after the string was to force the  binary values of the ISID
or PGT to be better word aligned and can be more  easily extracted as a value
direct from the byte array without  conversion.

What do you  think?

Jim Hafner  



--=_alternative 00538D3C88256BF1_=-- From owner-ips@ece.cmu.edu Tue Jul 9 13:05:39 2002 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA03560 for ; Tue, 9 Jul 2002 13:05:35 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id g69GMYk14686 for ips-outgoing; Tue, 9 Jul 2002 12:22:34 -0400 (EDT) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from sj-msg-core-2.cisco.com (sj-msg-core-2.cisco.com [171.69.24.11]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id g69GMWX14682 for ; Tue, 9 Jul 2002 12:22:32 -0400 (EDT) Received: from sponge.cisco.com (IDENT:mirapoint@sponge.cisco.com [64.101.128.87]) by sj-msg-core-2.cisco.com (8.12.2/8.12.2) with ESMTP id g69GMQhI020641; Tue, 9 Jul 2002 09:22:26 -0700 (PDT) Received: from DAPW2K3 (dhcp-161-44-68-170.cisco.com [161.44.68.170]) by sponge.cisco.com (Mirapoint) with SMTP id ABB27628; Tue, 9 Jul 2002 11:22:24 -0500 (CDT) From: "Dave Peterson" To: , Subject: RE: iSCSI: DAP Retry comments Date: Tue, 9 Jul 2002 11:22:25 -0500 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0) Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 In-Reply-To: <277DD60FB639D511AC0400B0D068B71E0564C050@CORPMX14> Sender: owner-ips@ece.cmu.edu Precedence: bulk Content-Transfer-Encoding: 7bit Regarding Retry, it's not about the command executing twice. Below is a rehash from previous emails of the issues with Retry: ***** Example scenario: 1. tape locate command is issued with a 10 second timer 2. tape command is dropped at the target due to a header digest error 3. having seen no response for the command after an iSCSI initiator determined timeout value, the initiator decides to retry the command This example leaves a 2 second window for the response to the second command to arrive before a ULP abort is sent. A mechanism to determine whether or not the command arrived at the target would be beneficial for the retry functionality to be useful. The mechanism should be initiated early enough in the ULP timeout window to allow the iSCSI retried command the opportunity to complete. Some options: A. If the initiator issues a NOP-Out(immed=1), the target can send back the expected CmdSN. B. The target, upon a header digest error, sends back a reject or NOP-In with the expected CmdSN. This would provide an indication to the initiator that something happened and trigger the command retry, still hopefully within the ULP timeout to allow for sucessful command completion. C. Texting stating that an iSCSI initiator should (only) perform a command retry when sufficient time remains for the command to completed. But, this leads one down the path of device type specific behavior. D. Remove the command retry functionality. I have yet to see it actually being used. The use of command retry is really only applicable when header digests are being used. Given TCP, probability of header digest usage and occurance, and existing ULP tools for error detection and recovery, my preference is to remove it. **** My point is the following need to occur for the Retry functionality to work: 1. header digest must be enabled 2. a header digest must be detected 3. the retried command must be issued early enough in the ULP timeout window to allow completion I don't see the Retry functionality being useful for disk devices and questionable for tape. Using a well-engineered (TCP/IP) network along with hopefully available SCSI level tools is a better solution. But I don't want to hold up the spec over this matter either, we just won't use it. Regarding SNACK, I don't really have a problem with it other than again a well-engineered network should mitigate the need. Regarding connection allegiance reassignment, the functionality is a bit more useful (if one supports more than 1 connection per session), provided the reassignment completes in time to allow the command to complete within the ULP timeout. Regarding legacy tape devices, I expect them to be front ended by a gateway. These devices will most likely not support any type of transport level error detection and recovery making them incompatible/problem childs with respect to the various iSCSI error recovery mechanisms. Bottom line is engineer your network well and leave the error detection and recovery to the SCSI level and above...dap > -----Original Message----- > From: Black_David@emc.com [mailto:Black_David@emc.com] > Sent: Tuesday, July 09, 2002 1:51 AM > To: dap@cisco.com; ips@ece.cmu.edu > Subject: iSCSI: DAP Retry comments > > > > T p 103 6.1.1 Usage of Retry and 6.7 SCSI Timeouts: the semantics of > Retry > > remain broken rendering it useless for tape operation. SCSI level error > > detection and recovery is the preferred mechanism. Refer to previous > emails > > sent via the IPS reflector regarding this matter. > > Can you provide more information? Command retry *never* results in > the command executing twice - both the original command and the retry > have the same CmdSN, so the second one is dropped as a duplicate if > the first one was received correctly. 6.1.1 is very clear that retry > MUST NOT be used if the command was received successfully (acknowledged > by ExpCmdSN), and if it is used, the retried command PDU is silently > dropped. > iSCSI's ordered delivery requirement avoids the situation in which a > dropped command causes subsequent commands to mis-execute - if none > of the commands are marked for immediate delivery, iSCSI will stop > at the "hole" created by the dropped command, and wait for the retry > to plug the hole. > > > T p 128 8.6 Considerations for State-dependent devices: last > paragraph: > > don't agree with the statement that error recovery at the iSCSI level > > (specifically Retry in its current state) is advisable. Retry > at the SCSI > > level is feasible and is not difficult (i.e., READ POSITION and LOCATE > > commands). This paragraph should be removed. > > Two questions: > - What about the SNACK and allegiance change mechanisms? > - What about the "legacy" tape devices (e.g., as discussed in London) > that presumably don't implement those commands? I believe this > text was originally intended to address this class of devices. > > 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 > --------------------------------------------------- From owner-ips@ece.cmu.edu Tue Jul 9 14:40:22 2002 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA06903 for ; Tue, 9 Jul 2002 14:40:16 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id g69I0Wk21534 for ips-outgoing; Tue, 9 Jul 2002 14:00:32 -0400 (EDT) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from atlrel9.hp.com (atlrel9.hp.com [156.153.255.214]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id g69I0UX21528 for ; Tue, 9 Jul 2002 14:00:30 -0400 (EDT) Received: from core.rose.hp.com (core.rose.hp.com [15.43.208.100]) by atlrel9.hp.com (Postfix) with ESMTP id 620A8E0009E; Tue, 9 Jul 2002 14:00:22 -0400 (EDT) Received: from swathi (swathi.rose.hp.com [15.43.213.237]) by core.rose.hp.com with SMTP (8.9.3 (PHNE_22672)/8.8.6 SMKit7.02) id LAA03201; Tue, 9 Jul 2002 11:02:13 -0700 (PDT) Message-ID: <001401c22772$7da203c0$edd52b0f@rose.hp.com> From: "Mallikarjun C." To: , Cc: References: <277DD60FB639D511AC0400B0D068B71E0564C048@CORPMX14> Subject: Re: iSCSI: DLB's Last Call T15 comment Date: Tue, 9 Jul 2002 11:00:20 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2600.0000 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 Sender: owner-ips@ece.cmu.edu Precedence: bulk Content-Transfer-Encoding: 7bit I was part of the team that deliberated on this issue and was a party to the compromise text. But let me state for the record that I (among others) had precisely suggested what David is suggesting - make it a MUST return always, it's simple to specify and implement. The reasons offered primarily had to do with changing existing code. Now with the changes in certain key names and the advent of C-bit functionality (that require code changes anyway), this may be a good time to consider making this simpler. I see that Julian also is agreeable to this change. -- Mallikarjun Mallikarjun Chadalapaka Networked Storage Architecture Network Storage Solutions Hewlett-Packard MS 5668 Roseville CA 95747 cbm@rose.hp.com ----- Original Message ----- From: To: Cc: Sent: Monday, July 08, 2002 11:39 PM Subject: iSCSI: DLB's Last Call T15 comment > John, > > [T.15] 4.3.1 Login Phase Start > > The first Login Response PDU during the Login Phase from the iSCSI > target SHOULD return the TargetPortalGroupTag key that contains the > tag value of the iSCSI portal group servicing the Login Request PDU. > If the iSCSI target implementation supports altering the portal group > configuration (including adding, deleting, and swapping of portals in > a portal group), it MUST return the TargetPortalGroupTag key carry- > ing the tag value of the servicing portal group. > > Let's make returning this key a MUST in all cases - less text, simpler > protocol, simpler code at the Initiator. > > > The item numbered T15, had a lot of discussions, especially in the Naming > > and Discovery Team, and the current wordage was the results of a > > compromise, where a number of vendors did not have the issue, and strongly > > felt that it would be the wrong thing to do with their product. So we > > agreed that the SHOULD section would be the right answer for > > every one. > > This sort of compromise leads to "MAY", not "SHOULD". I > suggest summarizing the NDT discussion to the list, as it's now an issue > to be settled here. > > 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 > --------------------------------------------------- > From owner-ips@ece.cmu.edu Tue Jul 9 14:43:24 2002 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA07041 for ; Tue, 9 Jul 2002 14:43:17 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id g69IQ8j23323 for ips-outgoing; Tue, 9 Jul 2002 14:26:08 -0400 (EDT) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from e2.ny.us.ibm.com (e2.ny.us.ibm.com [32.97.182.102]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id g69IQ5X23318 for ; Tue, 9 Jul 2002 14:26:05 -0400 (EDT) Received: from northrelay01.pok.ibm.com (northrelay01.pok.ibm.com [9.56.224.149]) by e2.ny.us.ibm.com (8.12.2/8.12.2) with ESMTP id g69IPxe8076250; Tue, 9 Jul 2002 14:25:59 -0400 Received: from d03nm014.boulder.ibm.com (avpilot.boulder.ibm.com [9.17.203.135]) by northrelay01.pok.ibm.com (8.11.1m3/NCO/VER6.1) with ESMTP id g69IPuT144132; Tue, 9 Jul 2002 14:25:56 -0400 X-Priority: 1 (High) Importance: Normal Subject: Re: iSCSI: DLB's Last Call T15 comment To: "Mallikarjun C." Cc: , X-Mailer: Lotus Notes Release 5.0.7 March 21, 2001 Message-ID: From: "John Hufferd" Date: Tue, 9 Jul 2002 11:23:18 -0700 X-MIMETrack: Serialize by Router on D03NM014/03/M/IBM(Release 5.0.10 |March 22, 2002) at 07/09/2002 12:25:58 PM MIME-Version: 1.0 Content-type: text/plain; charset=us-ascii Sender: owner-ips@ece.cmu.edu Precedence: bulk The issue was that some of the folks in the group, did not even perceive that their boxes would even have the problem that the statement was designed to handle. And they did not want to have to respond as specified to get around a problem that did not exist. Hence, they agreed after some debate that IF a box had that problem then it SHOULD make that response. They did not want MUST since they did not have the problem to begin with. And the other folks did not want MAY, since they did not feel that if a box had that problem, it was approprate for the box not to inform the Initiator. The debate issue about the "realness" of the problem seems to be still valid (but I would hope that we do not go into that on this list). The point seemed to be around different design issues. So the choice of SHOULD in my opinion was approprate, since it is not needed if the problem does not exist in a specific implementation, and MAY is much too weak if the box has the problem. . . . John L. Hufferd Senior Technical Staff Member (STSM) IBM/SSG San Jose Ca Main Office (408) 256-0403, Tie: 276-0403, eFax: (408) 904-4688 Home Office (408) 997-6136, Cell: (408) 499-9702 Internet address: hufferd@us.ibm.com "Mallikarjun C." on 07/09/2002 11:00:20 AM To: , John Hufferd/San Jose/IBM@IBMUS cc: Subject: Re: iSCSI: DLB's Last Call T15 comment I was part of the team that deliberated on this issue and was a party to the compromise text. But let me state for the record that I (among others) had precisely suggested what David is suggesting - make it a MUST return always, it's simple to specify and implement. The reasons offered primarily had to do with changing existing code. Now with the changes in certain key names and the advent of C-bit functionality (that require code changes anyway), this may be a good time to consider making this simpler. I see that Julian also is agreeable to this change. -- Mallikarjun Mallikarjun Chadalapaka Networked Storage Architecture Network Storage Solutions Hewlett-Packard MS 5668 Roseville CA 95747 cbm@rose.hp.com ----- Original Message ----- From: To: Cc: Sent: Monday, July 08, 2002 11:39 PM Subject: iSCSI: DLB's Last Call T15 comment > John, > > [T.15] 4.3.1 Login Phase Start > > The first Login Response PDU during the Login Phase from the iSCSI > target SHOULD return the TargetPortalGroupTag key that contains the > tag value of the iSCSI portal group servicing the Login Request PDU. > If the iSCSI target implementation supports altering the portal group > configuration (including adding, deleting, and swapping of portals in > a portal group), it MUST return the TargetPortalGroupTag key carry- > ing the tag value of the servicing portal group. > > Let's make returning this key a MUST in all cases - less text, simpler > protocol, simpler code at the Initiator. > > > The item numbered T15, had a lot of discussions, especially in the Naming > > and Discovery Team, and the current wordage was the results of a > > compromise, where a number of vendors did not have the issue, and strongly > > felt that it would be the wrong thing to do with their product. So we > > agreed that the SHOULD section would be the right answer for > > every one. > > This sort of compromise leads to "MAY", not "SHOULD". I > suggest summarizing the NDT discussion to the list, as it's now an issue > to be settled here. > > 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 > --------------------------------------------------- > From owner-ips@ece.cmu.edu Tue Jul 9 15:37:02 2002 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA14426 for ; Tue, 9 Jul 2002 15:37:00 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id g69JKwa27167 for ips-outgoing; Tue, 9 Jul 2002 15:20:58 -0400 (EDT) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from palrel10.hp.com (palrel10.hp.com [156.153.255.245]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id g69JKuX27160 for ; Tue, 9 Jul 2002 15:20:56 -0400 (EDT) Received: from core.rose.hp.com (core.rose.hp.com [15.43.208.100]) by palrel10.hp.com (Postfix) with ESMTP id 63671C00584 for ; Tue, 9 Jul 2002 12:20:55 -0700 (PDT) Received: from swathi (swathi.rose.hp.com [15.43.213.237]) by core.rose.hp.com with SMTP (8.9.3 (PHNE_22672)/8.8.6 SMKit7.02) id MAA17102 for ; Tue, 9 Jul 2002 12:22:47 -0700 (PDT) Message-ID: <005901c2277d$be7e03c0$edd52b0f@rose.hp.com> From: "Mallikarjun C." To: Subject: iSCSI: DLB-T.26 (response for TASK REASSIGN) Date: Tue, 9 Jul 2002 12:20:53 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2600.0000 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 Sender: owner-ips@ece.cmu.edu Precedence: bulk Content-Transfer-Encoding: 7bit > [T.26] 9.6 Task Management Function Response > > For the functions ABORT TASK, ABORT TASK SET, CLEAR ACA, CLEAR TASK > SET, LOGICAL UNIT RESET, TARGET COLD RESET and TARGET WARM RESET, the > target performs the requested Task Management function and sends a > Task Management Response back to the initiator. > > TASK REASSIGN does not get a response. Was this intended? It may be appropriate to include it in this list, but then it would be nice to make sure that the target sends the response to the TMF first before acting on the reassigned task (which might possibly involve retransmitting an old status sent before the connection failure with a new StatSN). Initiators may get confused if the response for the reassigned task arrives prior to the the response to the TMF itself (even while there are no StatSN holes). I suggest: For all the task management functions defined in 9.5.1, the target performs the requested function and sends a Task Management Response back to the initiator. In the case of the TASK REASSIGN function, the target must send the reponse to the task management function request first before acting on the reassigned task. Mallikarjun From owner-ips@ece.cmu.edu Tue Jul 9 15:37:19 2002 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA14451 for ; Tue, 9 Jul 2002 15:37:17 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id g69J1EF25866 for ips-outgoing; Tue, 9 Jul 2002 15:01:14 -0400 (EDT) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from palrel11.hp.com (palrel11.hp.com [156.153.255.246]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id g69J1CX25862 for ; Tue, 9 Jul 2002 15:01:12 -0400 (EDT) Received: from core.rose.hp.com (core.rose.hp.com [15.43.208.100]) by palrel11.hp.com (Postfix) with ESMTP id 2F97D6006D3 for ; Tue, 9 Jul 2002 12:01:11 -0700 (PDT) Received: from swathi (swathi.rose.hp.com [15.43.213.237]) by core.rose.hp.com with SMTP (8.9.3 (PHNE_22672)/8.8.6 SMKit7.02) id MAA13351 for ; Tue, 9 Jul 2002 12:03:03 -0700 (PDT) Message-ID: <003d01c2277a$fc8e9010$edd52b0f@rose.hp.com> From: "Mallikarjun C." To: Subject: iSCSI: DLB-T.17 (format error description) Date: Tue, 9 Jul 2002 12:01:09 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2600.0000 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 Sender: owner-ips@ece.cmu.edu Precedence: bulk Content-Transfer-Encoding: 7bit > [T.17] 6.4 Format Errors > > The following two explicit violations of PDU layout rules are format > errors: > > a) illegal contents of the PDU header (except the Opcode) - for > ex., out-of-range values for certain fields > b) inconsistent contents - for ex., value of one field conflicts > with that of another. > > Format errors indicate a major implementation flaw in one of the par- > ties. > > The two "for ex."s aren't good enough. Details on what is a format error > need > to be spelled out explicitly, given the drastic consequences of committing > one. I agree that the "for ex."s are not quite reassuring. However, I believe those are all that might happen in each class, so I don't want to remove them either. I suggest the following text as the replacement - ------------------------------ 6.4 Format Errors The following two explicit violations of PDU layout rules are format errors: a) out-of-range values for fields (except the Opcode) in the PDU header b) inconsistent values for fields in the PDU header, where value of one field conflicts with that of another. Format errors indicate a major implementation flaw in one of the parties. ------------------------------- Mallikarjun From owner-ips@ece.cmu.edu Tue Jul 9 15:39:01 2002 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA14542 for ; Tue, 9 Jul 2002 15:38:58 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id g69IqQU25266 for ips-outgoing; Tue, 9 Jul 2002 14:52:26 -0400 (EDT) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from atlrel7.hp.com (atlrel7.hp.com [156.153.255.213]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id g69IqNX25260 for ; Tue, 9 Jul 2002 14:52:23 -0400 (EDT) Received: from core.rose.hp.com (core.rose.hp.com [15.43.208.100]) by atlrel7.hp.com (Postfix) with ESMTP id 496108055D9 for ; Tue, 9 Jul 2002 14:52:15 -0400 (EDT) Received: from swathi (swathi.rose.hp.com [15.43.213.237]) by core.rose.hp.com with SMTP (8.9.3 (PHNE_22672)/8.8.6 SMKit7.02) id LAA11671 for ; Tue, 9 Jul 2002 11:54:07 -0700 (PDT) Message-ID: <003501c22779$bd137410$edd52b0f@rose.hp.com> From: "Mallikarjun C." To: Subject: iSCSI: DLB-T.16 (resource requirement for connection reinstatement) Date: Tue, 9 Jul 2002 11:52:13 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2600.0000 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 Sender: owner-ips@ece.cmu.edu Precedence: bulk Content-Transfer-Encoding: 7bit > [T.16] 4.3.4 Connection reinstatement > > Targets should support opening a second connection even > when they do not support multiple connections in Full Feature Phase. > > Looks like that ought to be an upper case "SHOULD". I think this needs > further discussion. Section 5.2 appears to use a lower case "must" > for this: Let's be careful here - section 5.2 discusses the generic case of "connection cleanup" - that includes both implicit and explicit logouts - whereas "connection reinstatement" is just implicit logout. While "connection cleanup" does not require additional connection resources in the general case, a target wanting to support connection reinstatement SHOULD support *opening* a second connection (though it may reject the Login if it's for a different CID). I believe that connection reinstatement is a useful functionality that the targets SHOULD support, so I agree that the change suggested by David is a reasonable one to make in 4.3.4 which only discusses connection reinstatement. Mallikarjun From owner-ips@ece.cmu.edu Tue Jul 9 15:39:28 2002 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA14579 for ; Tue, 9 Jul 2002 15:39:18 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id g69J7vG26322 for ips-outgoing; Tue, 9 Jul 2002 15:07:57 -0400 (EDT) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from palrel10.hp.com (palrel10.hp.com [156.153.255.245]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id g69J7tX26316 for ; Tue, 9 Jul 2002 15:07:55 -0400 (EDT) Received: from core.rose.hp.com (core.rose.hp.com [15.43.208.100]) by palrel10.hp.com (Postfix) with ESMTP id 5C55DC0036F; Tue, 9 Jul 2002 12:07:54 -0700 (PDT) Received: from swathi (swathi.rose.hp.com [15.43.213.237]) by core.rose.hp.com with SMTP (8.9.3 (PHNE_22672)/8.8.6 SMKit7.02) id MAA14503; Tue, 9 Jul 2002 12:09:46 -0700 (PDT) Message-ID: <005301c2277b$ecfd7750$edd52b0f@rose.hp.com> From: "Mallikarjun C." To: , Cc: References: <277DD60FB639D511AC0400B0D068B71E0564C04A@CORPMX14> Subject: Re: iSCSI: DLB's Last Call T18 comment Date: Tue, 9 Jul 2002 12:07:52 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2600.0000 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 Sender: owner-ips@ece.cmu.edu Precedence: bulk Content-Transfer-Encoding: 7bit David, Agree that the text is over-restrictive. Seems to me that the following change would address your comment - S/b "the Abort Task" W/ "an appropriate" - in the quoted text. Thanks. -- Mallikarjun Mallikarjun Chadalapaka Networked Storage Architecture Network Storage Solutions Hewlett-Packard MS 5668 Roseville CA 95747 cbm@rose.hp.com ----- Original Message ----- From: To: Cc: Sent: Monday, July 08, 2002 11:42 PM Subject: iSCSI: DLB's Last Call T18 comment > John, > > [T.18] 6.7 SCSI Timeouts > > On a ULP timeout for a command (that carried a CmdSN of n), the iSCSI > initiator MUST abort the command by either using the Abort Task task > management function request, or a "close the connection" Logout if it > intends to continue the session. > > I think the first part is over specified - there are a number of task > management > commands that abort the task - if the target is really sick, something much > more serious than Abort Task may be used that not only aborts this task, > but others. It's not clear whether "if it intends to continue the session" > applies only to the logout or to both the task management command and the > logout, nor is it clear what an initiator should do if it doesn't intend to > continue the session. > > > I do not follow your issue with T18. Time outs can occur for reason that > > are not something that needs more drastic action. If fact I would assume > > that it generally does not need other actions. > > It's actually a minor issue in the text - the current text requires that > an Abort Task be issued if the connection is not logged out with the > intent to continue the session - it should allow any task management > function that aborts a task to be used so that an initiator that decides > CLEAR TASK SET or LUN RESET is appropriate doesn't also have to issue > additional ABORT TASK functions in order to comply with the MUST. > > 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 > --------------------------------------------------- > > From owner-ips@ece.cmu.edu Tue Jul 9 16:16:51 2002 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA15717 for ; Tue, 9 Jul 2002 16:16:50 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id g69JggL28595 for ips-outgoing; Tue, 9 Jul 2002 15:42:42 -0400 (EDT) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from atlrel6.hp.com (atlrel6.hp.com [156.153.255.205]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id g69JgeX28587 for ; Tue, 9 Jul 2002 15:42:40 -0400 (EDT) Received: from core.rose.hp.com (core.rose.hp.com [15.43.208.100]) by atlrel6.hp.com (Postfix) with ESMTP id 52A10503 for ; Tue, 9 Jul 2002 15:42:39 -0400 (EDT) Received: from swathi (swathi.rose.hp.com [15.43.213.237]) by core.rose.hp.com with SMTP (8.9.3 (PHNE_22672)/8.8.6 SMKit7.02) id MAA20424 for ; Tue, 9 Jul 2002 12:44:30 -0700 (PDT) Message-ID: <006101c22780$c7742510$edd52b0f@rose.hp.com> From: "Mallikarjun C." To: Subject: iSCSI: DLB-T.28 (Logout discards OOO commands) Date: Tue, 9 Jul 2002 12:42:37 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2600.0000 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 Sender: owner-ips@ece.cmu.edu Precedence: bulk Content-Transfer-Encoding: 7bit > [T.28] 9.14 Logout Request > > A successful completion of a logout request with the reason code of > "close the connection" or "remove the connection for recovery" > results in the discarding of all tasks waiting in the command reor- > dering queue that are allegiant to the connection being logged out. > > "discarding" is not what hapapens in the "remove the connection for recovery > case according to the following text from Section 6.5: > > b) Logout the connection for recovery and continue the tasks on a > different connection instance as described in Section 6.1 Retry > and Reassign in Recovery. [OR] > > A "discarded" task cannot be "continue"-d. I suspect the text should say > that "close the connection" terminates the tasks, anad "remove the > connection > for recovery" suspends the tasks with the following CmdSN side effects ... Notice the phrase "waiting in the command reordering queue". *Any* flavor of Logout would cause the OOO commands in the target's reordering queue to be discarded. The difference in behaviors is only for the active tasks. The recovery Logout, when successfully executed, would prepare the *active instantiated tasks* for reassignment, while the other two flavors of Logout would terminate all appropriate tasks. I would suggest qualifying the words task/tasks with "active" in section 6.5 (in the text you quoted), and also in sections 9.5/9.6 to make this distinction clear. Mallikarjun From owner-ips@ece.cmu.edu Tue Jul 9 17:09:20 2002 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA17592 for ; Tue, 9 Jul 2002 17:09:19 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id g69KYvK02323 for ips-outgoing; Tue, 9 Jul 2002 16:34:57 -0400 (EDT) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from swan.mail.pas.earthlink.net (swan.mail.pas.earthlink.net [207.217.120.123]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id g69KYtX02318 for ; Tue, 9 Jul 2002 16:34:56 -0400 (EDT) Received: from 1cust1.tnt5.colorado-springs.co.da.uu.net ([67.234.201.1] helo=SERVO) by swan.mail.pas.earthlink.net with esmtp (Exim 3.33 #1) id 17S1hG-0006XT-00 for ips@ece.cmu.edu; Tue, 09 Jul 2002 16:34:54 -0400 Message-Id: <4.2.0.58.20020709141839.00a652f8@delos.delos.com> X-Sender: reames@delos.delos.com (Unverified) X-Mailer: QUALCOMM Windows Eudora Pro Version 4.2.0.58 Date: Tue, 09 Jul 2002 14:33:41 -0600 To: ips@ece.cmu.edu From: Steve Reames Subject: iSCSI: DLB [T.31] Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-ips@ece.cmu.edu Precedence: bulk From DLB's comments: >[T.31] 9.16.1 Type > > An iSCSI target that does not support recovery within connection MAY > reject the status SNACK with a Reject PDU. If the target supports > recovery within connection, it MAY reject the SNACK after which it > MUST issue an Asynchronous Message PDU with an iSCSI event that indi- > cates "Request Logout". > > This should be conditioned on the operational ErrorRecoveryLevel of the > session, not whether the target supports recovery within connection. I would prefer that this not be conditioned on the ErrorRecoveryLevel. If I am writing code, I may choose to support recovery-within-connection, but not all the features that would be required to move me up to ErrorRecoveryLevel 1. I would like SNACK and Reject PDUs to work properly for my code, even though it is technically only "ErrorRecoveryLevel 0.5". As I read it, changing the wording would allow the target to ignore my improved error recovery efforts unless I have a full ErrorRecoveryLevel 1 implementation. David, I doubt that is what you intended, so maybe you want to word it a little differently. From owner-ips@ece.cmu.edu Tue Jul 9 18:45:36 2002 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA20675 for ; Tue, 9 Jul 2002 18:45:36 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id g69Lk0L07031 for ips-outgoing; Tue, 9 Jul 2002 17:46:00 -0400 (EDT) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from sj-msg-core-4.cisco.com (sj-msg-core-4.cisco.com [171.71.163.10]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id g69LjwX07024 for ; Tue, 9 Jul 2002 17:45:58 -0400 (EDT) Received: from nisser.cisco.com (nisser.cisco.com [171.71.176.85]) by sj-msg-core-4.cisco.com (8.12.2/8.12.2) with ESMTP id g69Ljnpj015023; Tue, 9 Jul 2002 14:45:49 -0700 (PDT) Received: from cisco.com (mbakke@mbakke-lnx.cisco.com [161.44.68.87]) by nisser.cisco.com (8.8.6 (PHNE_14041)/CISCO.SERVER.1.2) with ESMTP id OAA00845; Tue, 9 Jul 2002 14:45:46 -0700 (PDT) Message-ID: <3D2B5DAD.AB59F2D2@cisco.com> Date: Tue, 09 Jul 2002 17:03:25 -0500 From: Mark Bakke X-Mailer: Mozilla 4.72 [en] (X11; U; Linux 2.2.16-3.uid32 i686) X-Accept-Language: en, de MIME-Version: 1.0 To: John Hufferd CC: "Julian Satran (Actcom)" , Michael Smith , Black_David@emc.com, ips@ece.cmu.edu Subject: Re: iSCSI: Last call comments References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ips@ece.cmu.edu Precedence: bulk Content-Transfer-Encoding: 7bit I think either of the possible wordings suggested by David, Julian, or John would work fine. However, John brings up a valid point in that it's the _interface_ not the target or initiator, that can be compliant or not, since the target or initiator is really a SCSI- level thing. I'm not sure whether we have to specify the use of an enclosure or not, since one could integrate the iSCSI and IPsec implementations either within an enclosure, or in separate enclosures, and still be OK. The enclosure is a good example, though. How about the following modification: An iSCSI initiator or target interface may provide the required IPsec support either fully integrated or in conjunction with an IPsec front-end device. In the latter case the term iSCSI target interface refers to the target and IPsec front-end and compliance requirements apply to the "combined device". For example, an enclosure containing separate implementations of iSCSI and IPsec may claim compliance only on those interfaces leaving the enclosure that support IPsec. -- Mark John Hufferd wrote: > > Julian, > As you know we talked about this a lot a long time ago. Many folks wanted > to count the fact that a Firewall device within the installation could be > used with their iSCSI Initiator or Target, and therefore their device > should count as compliant with the specification. The understanding that > was reached after much debate was that ... if you want to claim compliance > for the interface that leaves an enclosure, IPsec is required .... I > believe that if you include the words you are suggesting, that you should > add that statement to the spec also. > > I suggest the following wordage: > > "An iSCSI initiator or target may provide the required IPsec support either > fully integrated or in conjunction with an IPsec front-end device. In the > later case, the compliance requirements apply to the "combined device". > Claims of compliance for the interface that leaves an enclosure, is valid > only if IPsec is supported on that interface from within the enclosure." > > The above would permit a Rack Enclosure, which had a Firewall included > within that Rack Enclosure, to validly claim compliance for the interfaces > that left the Rack. Likewise, for any other enclosure. If the HBA , blade > or motherboard had a fronting IPsec chip, that would also permit compliance > at the external interfaces of the HBA, blade or motherboard. > > . > . > . > John L. Hufferd > Senior Technical Staff Member (STSM) > IBM/SSG San Jose Ca > Main Office (408) 256-0403, Tie: 276-0403, eFax: (408) 904-4688 > Home Office (408) 997-6136, Cell: (408) 499-9702 > Internet address: hufferd@us.ibm.com > > "Julian Satran \(Actcom\)" @ece.cmu.edu on > 07/05/2002 01:56:09 AM > > Sent by: owner-ips@ece.cmu.edu > > To: "Michael Smith" , , > > cc: "Michael Smith" > Subject: Re: iSCSI: Last call comments > > I would suggest the following text for 7.3 > > An iSCSI initiator or target may provide the required IPsec support either > fully integrated or in conjunction with an IPsec front-end device. In the > later case the term iSCSI target reffers to the target and IPsec front-end > and compliance requirements apply to the "combined device". > > Julo > ----- Original Message ----- > From: Michael Smith > To: 'Black_David@emc.com' ; 'ips@ece.cmu.edu' > Cc: Michael Smith > Sent: Thursday, July 04, 2002 2:52 AM > Subject: RE: iSCSI: Last call comments > > I support David's suggested clarification and his suggested wording. I > struggled for a while understanding this issue and the suggested changes > make things much clearer. > > Mike Smith > CTO, iReady > > -----Original Message----- > From: Black_David@emc.com [mailto:Black_David@emc.com] > Sent: Wednesday, July 03, 2002 2:54 PM > To: mbakke@cisco.com; ips@ece.cmu.edu > Subject: RE: iSCSI: Last call comments > > Mark, > > > There are a few sections in iSCSI (and ips-security) that discuss > > IPsec requirements for "compliant/conformant implementations". I > > recall that this meant a target implementation could either be a > > single device with both iSCSI and IPsec, or a combination of two > > devices, one that handles iSCSI; the other handling IPsec. > > In the two device combination, only the combination is compliant, > and only at the interface(s) that provide(s) both iSCSI and IPsec. > The iSCSI device in the combination is not compliant by itself > because it does not provide IPsec. > > > As there are many cases where it makes a lot of sense to provide > > the solution in two pieces (iSCSI in one or more devices, with one or > > more IPsec front-end devices, I'd like to clarify this. > > > > How about (somewhere in section 7) adding something like: > > > > An iSCSI compliant initiator or target may provide the required > > IPsec support either by itself, or in conjunction with an IPsec > > front-end device. > > > > Any thoughts? > > It would need to have the word "compliant" removed and a sentence > added to spell out what is compliant, along the lines of: > > An iSCSI initiator or target may provide the required > IPsec support either by itself, or in conjunction with an IPsec > front-end device. In the latter case only the combination > complies with the requirements of this specification; the > individual iSCSI initiator or target would not comply with > the requirements of this specification due to the lack of IPsec > support. > > It's probably a good idea to put this in. > > 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 > --------------------------------------------------- > > > -----Original Message----- > > From: Mark Bakke [mailto:mbakke@cisco.com] > > Sent: Wednesday, July 03, 2002 5:48 PM > > To: IPS > > Subject: iSCSI: Last call comments > > > > > > > > The iSCSI draft is looking pretty good. I only have one last-call > > comment left: > > > > There are a few sections in iSCSI (and ips-security) that discuss > > IPsec requirements for "compliant/conformant implementations". I > > recall that this meant a target implementation could either be a > > single device with both iSCSI and IPsec, or a combination of two > > devices, one that handles iSCSI; the other handling IPsec. However, > > I couldn't find anywhere in the spec that spells this out either > > way, other than a hint at it in item [3] on page 31 of > > ips-security-13: > > > > > [3] IPsec is provided by a device external to the actual > > iSCSI device. > > > Here the iSCSI header and data CRCs can be kept across > > the part of > > > the connection that is not protected by IPsec. For > > instance, the > > > iSCSI connection could traverse an extra bus, interface card, > > > network, interface card, and bus between the iSCSI > > device and the > > > device providing IPsec. In this case, the iSCSI CRC is > > desirable, > > > and the iSCSI implementation behind the IPsec device > > may request > > > it. > > > > As there are many cases where it makes a lot of sense to provide > > the solution in two pieces (iSCSI in one or more devices, with one or > > more IPsec front-end devices, I'd like to clarify this. > > > > How about (somewhere in section 7) adding something like: > > > > An iSCSI compliant initiator or target may provide the required > > IPsec support either by itself, or in conjunction with an IPsec > > front-end device. > > > > Any thoughts? > > > > -- > > Mark > > > > > > For reference, here are a few of the statements that would be > > helped out by the above. > > > > iscsi-14 Section 7.3.1: > > > > An iSCSI compliant initiator or target MUST provide data integrity > > and authentication by implementing IPsec [RFC2401] with > > ESP [RFC2406] > > in tunnel mode and MAY provide data integrity and > > authentication by > > implementing IPsec with ESP in transport mode. The IPsec > > implementa- > > tion MUST fulfill the following iSCSI specific requirements: > > > > iscsi-14 Section 7.3.2: > > > > An iSCSI compliant initiator or target MUST provide > > confidentiality > > by implementing IPsec [RFC2401] with ESP [RFC2406] in > > tunnel mode and > > MAY provide confidentiality by implementing IPsec with ESP > > in trans- > > port mode. with the following iSCSI specific requirements: > > > > iscsi-14 Section 7.3.3: > > > > - Conformant iSCSI implementations MUST support IKE Main Mode > > and SHOULD support Aggressive Mode. > > > > --- > > ips-security-13 Section 2.3.1: > > > > All IP block storage security compliant implementations MUST support > > IPsec ESP [RFC2406] to provide security for both control packets and > > data packets, as well as the replay protection mechanisms of IPsec. > > When ESP is utilized, per-packet data origin authentication, integrity > > and replay protection MUST be used. > > > > > > -- > > Mark A. Bakke > > Cisco Systems > > mbakke@cisco.com > > 763.398.1054 > > -- Mark A. Bakke Cisco Systems mbakke@cisco.com 763.398.1054 From owner-ips@ece.cmu.edu Tue Jul 9 19:24:24 2002 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA21617 for ; Tue, 9 Jul 2002 19:24:24 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id g69Mmfv10816 for ips-outgoing; Tue, 9 Jul 2002 18:48:41 -0400 (EDT) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from palrel13.hp.com (palrel13.hp.com [156.153.255.238]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id g69MmbX10808 for ; Tue, 9 Jul 2002 18:48:37 -0400 (EDT) Received: from core.rose.hp.com (core.rose.hp.com [15.43.208.100]) by palrel13.hp.com (Postfix) with ESMTP id 69DCB400368 for ; Tue, 9 Jul 2002 15:48:36 -0700 (PDT) Received: from swathi (swathi.rose.hp.com [15.43.213.237]) by core.rose.hp.com with SMTP (8.9.3 (PHNE_22672)/8.8.6 SMKit7.02) id PAA19883 for ; Tue, 9 Jul 2002 15:50:28 -0700 (PDT) Message-ID: <00ab01c2279a$c18a2c20$edd52b0f@rose.hp.com> From: "Mallikarjun C." To: Subject: iSCSI: DLB-T.30 (using SNACK w/ PDU size changes) Date: Tue, 9 Jul 2002 15:48:34 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2600.0000 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 Sender: owner-ips@ece.cmu.edu Precedence: bulk Content-Transfer-Encoding: 7bit David, You're right that there's a duplicate StatSN issue with the rev14 text. I believe that can be addressed by mandating that the initiators must discard the first status PDU always for the task in question, and then issue a follow-on status SNACK. It may occasionally lead to discarding a good status (with the right ExpDataSN that reflects the re-segmented DataSN count), but that would anyway be recovered with the explicit follow-on status SNACK. I don't believe we need to make BegRun=0 for these cases, nor do I believe that we need a new type of data SNACK. Mallikarjun > [T.30] 9.16 SNACK Request > > If the initiator MaxRecvDataSegmenTLength changed Data-In PDUs > requested with RunLength 0 (meaning all PDUs after this number) may > be different from the ones originally sent, in order to reflect > changes in MaxRecvDataSegmentLength. Their DataSN starts with the > requested number and is increased by 1 for each resent Data-In PDU. > If DataSN numbers change and a SCSI-Reponse PDU was sent reflecting > the DataSN before retransmission it MUST be resent to reflect the new > numbers. > > This was discussed on the list, but there are still some problems here: > (1) If the MaxRecvDataSegmentLength has changed, the only valid Data > SNACK is BegRun=0, RunLength=0 (i.e., resend everything). Attempts > to be more clever than this are an invitation to miscount Data-In > PDUs and cause problems in the initiator. Targets MUST reject > all other Data SNACK requests in this situation. > (2) The new SCSI-Response PDU needs a new StatSN to avoid the initiator > discarding it as a duplicate. Section 2.2.2.2 is silent on > duplicate > detection for StatSN, but discarding duplicates would be a > reasonable > thing for an initiator to do. > (3) The initiator needs some way to know that a new response is coming, > and specifically whether to expect one or two responses. If it > only expects one and two show up, the initiator could reuse the > Task Tag once all the data arrives causing a race in which the > new response could incorrectly complete an unrelated command > (unlikely, but potentially nasty). > This suggests calling out the Data SNACK as having > special behavior: > - It may resegment Data-In PDUs to deal with > MaxRecvDataSegmentLength. > All other Data SNACK requests MUST NOT resegment. > - It *always* generates a new SCSI Response due to the possibility > of resegmentation. > That's not a great solution, because if one ever sets RunLength=0> > in a Data SNACK, the resulting behavior change is dramatic and unexpected. > This leads to the final proposal: > - Specify a new SNACK type code (3) for Resegmenting Data SNACK. > SNACK > Data-In resegmentation is allowed only when this is used. > If > resegmentation would be necessary for a Data SNACK (type 1), > that SNACK MUST be rejected. > - Both BegRun and RunLength MUST be zero for a Resegmenting Data > SNACK, and (unlike reserved fields) these MUST be checked by > the receiver (target). > - A new SCSI Response is always generated as a result of a > Resegmenting > Data-In SNACK, and it has its own StatSN number to deal with > the > fact that the number of Data-In PDUs may have changed, > causing > a change to the ExpDataSN value. This new response also > needs > to be marked to distinguish it from a response that may have > been generated earlier (so the initiator knows to wait for > the > new response) - using a bit in the flags field for this > seems > wrong, so specifying a new Response code value (0x02 - see > 9.4.3) > seems like a reasonable way to accomplish this. > - Data SNACK (type 1) now has consistent behavior - it MUST NOT > resegment > and MUST NOT generate a new SCSI response, ever. > This approach also has the potentially useful property of making it easy > to yank out the Resegmenting Data SNACK wart if we ever put restrictions > on the interaction of MaxRecvDatasegmentLength and Data SNACKs (yes, that's > a hint ... this has gotten messy enough that forbidding Data SNACKs when > MaxRecvDataSegmentLength has changed needs to be considered as a possible > alternative). > > This issue also affects some text in 9.16.3. From owner-ips@ece.cmu.edu Tue Jul 9 19:25:17 2002 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA21667 for ; Tue, 9 Jul 2002 19:25:17 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id g69N5Av11683 for ips-outgoing; Tue, 9 Jul 2002 19:05:10 -0400 (EDT) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from palrel11.hp.com (palrel11.hp.com [156.153.255.246]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id g69N57X11678 for ; Tue, 9 Jul 2002 19:05:07 -0400 (EDT) Received: from core.rose.hp.com (core.rose.hp.com [15.43.208.100]) by palrel11.hp.com (Postfix) with ESMTP id 08C09600488; Tue, 9 Jul 2002 16:05:07 -0700 (PDT) Received: from swathi (swathi.rose.hp.com [15.43.213.237]) by core.rose.hp.com with SMTP (8.9.3 (PHNE_22672)/8.8.6 SMKit7.02) id QAA23040; Tue, 9 Jul 2002 16:06:58 -0700 (PDT) Message-ID: <00b101c2279d$0fd4aca0$edd52b0f@rose.hp.com> From: "Mallikarjun C." To: , "Steve Reames" References: <4.2.0.58.20020709141839.00a652f8@delos.delos.com> Subject: Re: iSCSI: DLB [T.31] Date: Tue, 9 Jul 2002 16:05:04 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2600.0000 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 Sender: owner-ips@ece.cmu.edu Precedence: bulk Content-Transfer-Encoding: 7bit Steve, I assume you're describing the initiator perspective. Even with the current wording, target can ignore your status SNACK requests - since the error recovery support promised by the target with operational ErrorRecoveryLevel=0 doesn't include SNACK support. Changing the wording (which I believe is the right thing) wouldn't change your situation. If you want to be able to selectively use the status recovery, you may negotiate the ErrorRecoveryLevel=1 and not ever use the data recovery. But you should be able to handle recovery R2Ts in such a case. -- Mallikarjun Mallikarjun Chadalapaka Networked Storage Architecture Network Storage Solutions Hewlett-Packard MS 5668 Roseville CA 95747 cbm@rose.hp.com ----- Original Message ----- From: "Steve Reames" To: Sent: Tuesday, July 09, 2002 1:33 PM Subject: iSCSI: DLB [T.31] > From DLB's comments: > > >[T.31] 9.16.1 Type > > > > An iSCSI target that does not support recovery within connection MAY > > reject the status SNACK with a Reject PDU. If the target supports > > recovery within connection, it MAY reject the SNACK after which it > > MUST issue an Asynchronous Message PDU with an iSCSI event that indi- > > cates "Request Logout". > > > > This should be conditioned on the operational ErrorRecoveryLevel of the > > session, not whether the target supports recovery within connection. > > I would prefer that this not be conditioned on the ErrorRecoveryLevel. If I > am writing code, I may choose to support recovery-within-connection, but > not all the features that would be required to move me up to > ErrorRecoveryLevel 1. I would like SNACK and Reject PDUs to work properly > for my code, even though it is technically only "ErrorRecoveryLevel 0.5". > As I read it, changing the wording would allow the target to ignore my > improved error recovery efforts unless I have a full ErrorRecoveryLevel 1 > implementation. David, I doubt that is what you intended, so maybe you want > to word it a little differently. > > From owner-ips@ece.cmu.edu Tue Jul 9 20:37:19 2002 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA22789 for ; Tue, 9 Jul 2002 20:37:19 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id g6A07mg14963 for ips-outgoing; Tue, 9 Jul 2002 20:07:48 -0400 (EDT) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from atlrel7.hp.com (atlrel7.hp.com [156.153.255.213]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id g6A07kX14958 for ; Tue, 9 Jul 2002 20:07:46 -0400 (EDT) Received: from core.rose.hp.com (core.rose.hp.com [15.43.208.100]) by atlrel7.hp.com (Postfix) with ESMTP id 89F078055EE; Tue, 9 Jul 2002 20:07:45 -0400 (EDT) Received: from swathi (swathi.rose.hp.com [15.43.213.237]) by core.rose.hp.com with SMTP (8.9.3 (PHNE_22672)/8.8.6 SMKit7.02) id RAA02087; Tue, 9 Jul 2002 17:09:37 -0700 (PDT) Message-ID: <00c301c227a5$d012df20$edd52b0f@rose.hp.com> From: "Mallikarjun C." To: "Dave Peterson" , , References: Subject: Re: iSCSI: DAP Retry comments Date: Tue, 9 Jul 2002 17:07:43 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2600.0000 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 Sender: owner-ips@ece.cmu.edu Precedence: bulk Content-Transfer-Encoding: 7bit Dave, I completely agree with you that a well-engineered network goes a long way in mitigating the error recovery needs, but let me add a couple of comments. In your original comment, you said: "the semantics of Retry remain broken rendering it useless for tape operation". Your latest note doesn't address why you think it's so. It sounds like you are concerned about possibly lack of enough time for completing a successful retry at the iSCSI level, but I fail to see how that's "broken semantics" for the iSCSI protocol definition. IMHO, that's an implementation issue (FYI, HP-UX drivers have been successfully dealing with an identical issue in the FC land for the last several years). You also are assuming that header digest error is the only event that causes a command loss, I'd like to add that immediate data digest error is the other. BTW, it's not true that allegiance reassignment is useful only for multi-connection sessions. As I had earlier commented on the list, the ability to continue tasks across TCP connection failures is just as useful for single-connection sessions. Thanks. -- Mallikarjun Mallikarjun Chadalapaka Networked Storage Architecture Network Storage Solutions Hewlett-Packard MS 5668 Roseville CA 95747 cbm@rose.hp.com ----- Original Message ----- From: "Dave Peterson" To: ; Sent: Tuesday, July 09, 2002 9:22 AM Subject: RE: iSCSI: DAP Retry comments > Regarding Retry, it's not about the command executing twice. > Below is a rehash from previous emails of the issues with Retry: > ***** > Example scenario: > 1. tape locate command is issued with a 10 second timer > 2. tape command is dropped at the target due to a header digest error > 3. having seen no response for the command after an iSCSI initiator > determined timeout value, the initiator decides to retry the command > > This example leaves a 2 second window for the response to the second command > to arrive before a ULP abort is sent. > > A mechanism to determine whether or not the command arrived at the target > would be beneficial for the retry functionality to be useful. > The mechanism should be initiated early enough in the ULP timeout window to > allow the iSCSI retried command the opportunity to complete. > > Some options: > > A. If the initiator issues a NOP-Out(immed=1), the target can send back the > expected CmdSN. > > B. The target, upon a header digest error, sends back a reject or NOP-In > with > the expected CmdSN. This would provide an indication to the initiator that > something happened and trigger the command retry, still hopefully within the > ULP timeout to allow for sucessful command completion. > > C. Texting stating that an iSCSI initiator should (only) perform a command > retry when sufficient time remains for the command to completed. But, this > leads one down the path of device type specific behavior. > > D. Remove the command retry functionality. I have yet to see it actually > being used. The use of command retry is really only applicable when header > digests are being used. Given TCP, probability of header digest usage and > occurance, > and existing ULP tools for error detection and recovery, my preference is to > remove it. > **** > > My point is the following need to occur for the Retry functionality to work: > 1. header digest must be enabled > 2. a header digest must be detected > 3. the retried command must be issued early enough in the ULP timeout window > to allow completion > > I don't see the Retry functionality being useful for disk devices and > questionable for tape. > Using a well-engineered (TCP/IP) network along with hopefully available SCSI > level tools is a better solution. > > But I don't want to hold up the spec over this matter either, we just won't > use it. > > Regarding SNACK, I don't really have a problem with it other than again a > well-engineered network should mitigate the need. > Regarding connection allegiance reassignment, the functionality is a bit > more useful (if one supports more than 1 connection per session), provided > the reassignment completes in time to allow the command to complete within > the ULP timeout. > > Regarding legacy tape devices, I expect them to be front ended by a gateway. > These devices will most likely not support any type of transport level error > detection and recovery making them incompatible/problem childs with respect > to the various iSCSI error recovery mechanisms. > > Bottom line is engineer your network well and leave the error detection and > recovery to the SCSI level and above...dap > > > -----Original Message----- > > From: Black_David@emc.com [mailto:Black_David@emc.com] > > Sent: Tuesday, July 09, 2002 1:51 AM > > To: dap@cisco.com; ips@ece.cmu.edu > > Subject: iSCSI: DAP Retry comments > > > > > > > T p 103 6.1.1 Usage of Retry and 6.7 SCSI Timeouts: the semantics of > > Retry > > > remain broken rendering it useless for tape operation. SCSI level error > > > detection and recovery is the preferred mechanism. Refer to previous > > emails > > > sent via the IPS reflector regarding this matter. > > > > Can you provide more information? Command retry *never* results in > > the command executing twice - both the original command and the retry > > have the same CmdSN, so the second one is dropped as a duplicate if > > the first one was received correctly. 6.1.1 is very clear that retry > > MUST NOT be used if the command was received successfully (acknowledged > > by ExpCmdSN), and if it is used, the retried command PDU is silently > > dropped. > > iSCSI's ordered delivery requirement avoids the situation in which a > > dropped command causes subsequent commands to mis-execute - if none > > of the commands are marked for immediate delivery, iSCSI will stop > > at the "hole" created by the dropped command, and wait for the retry > > to plug the hole. > > > > > T p 128 8.6 Considerations for State-dependent devices: last > > paragraph: > > > don't agree with the statement that error recovery at the iSCSI level > > > (specifically Retry in its current state) is advisable. Retry > > at the SCSI > > > level is feasible and is not difficult (i.e., READ POSITION and LOCATE > > > commands). This paragraph should be removed. > > > > Two questions: > > - What about the SNACK and allegiance change mechanisms? > > - What about the "legacy" tape devices (e.g., as discussed in London) > > that presumably don't implement those commands? I believe this > > text was originally intended to address this class of devices. > > > > 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 > > --------------------------------------------------- > > From owner-ips@ece.cmu.edu Tue Jul 9 20:38:18 2002 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA22808 for ; Tue, 9 Jul 2002 20:38:18 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id g6A0SMu15928 for ips-outgoing; Tue, 9 Jul 2002 20:28:22 -0400 (EDT) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from palrel10.hp.com (palrel10.hp.com [156.153.255.245]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id g6A0SKX15922 for ; Tue, 9 Jul 2002 20:28:20 -0400 (EDT) Received: from core.rose.hp.com (core.rose.hp.com [15.43.208.100]) by palrel10.hp.com (Postfix) with ESMTP id 4C3D5C00402; Tue, 9 Jul 2002 17:28:19 -0700 (PDT) Received: from swathi (swathi.rose.hp.com [15.43.213.237]) by core.rose.hp.com with SMTP (8.9.3 (PHNE_22672)/8.8.6 SMKit7.02) id RAA04344; Tue, 9 Jul 2002 17:30:11 -0700 (PDT) Message-ID: <00cb01c227a8$af820d00$edd52b0f@rose.hp.com> From: "Mallikarjun C." To: "John Hufferd" Cc: , References: Subject: Re: iSCSI: DLB's Last Call T15 comment Date: Tue, 9 Jul 2002 17:28:16 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2600.0000 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 Sender: owner-ips@ece.cmu.edu Precedence: bulk Content-Transfer-Encoding: 7bit Let me make one more comment on this topic, and I'd let others comment. Eventhough John's note describes a target's ability to do portal group (re)configuration a "problem", I beg to differ. I'd in fact claim that this functionality in some form must be present in every target to initially get it up and running. At any rate, it appears that John is certainly acknowledging that returning TargetPortalGroupTag key always is required for at least certain classes of configurable targets. If that's the case, and given that making code changes is a non-issue now (with all the other recent changes in text negotiation), it escapes me why it's not preferable to simply return one additional key always in Login Response. This makes the code on either end simpler, and the spec certainly simpler. -- Mallikarjun Mallikarjun Chadalapaka Networked Storage Architecture Network Storage Solutions Hewlett-Packard MS 5668 Roseville CA 95747 cbm@rose.hp.com ----- Original Message ----- From: "John Hufferd" To: "Mallikarjun C." Cc: ; Sent: Tuesday, July 09, 2002 11:23 AM Subject: Re: iSCSI: DLB's Last Call T15 comment > > The issue was that some of the folks in the group, did not even perceive > that their boxes would even have the problem that the statement was > designed to handle. And they did not want to have to respond as specified > to get around a problem that did not exist. Hence, they agreed after some > debate that IF a box had that problem then it SHOULD make that response. > They did not want MUST since they did not have the problem to begin with. > And the other folks did not want MAY, since they did not feel that if a box > had that problem, it was approprate for the box not to inform the > Initiator. > > The debate issue about the "realness" of the problem seems to be still > valid (but I would hope that we do not go into that on this list). The > point seemed to be around different design issues. > > So the choice of SHOULD in my opinion was approprate, since it is not > needed if the problem does not exist in a specific implementation, and MAY > is much too weak if the box has the problem. > > > . > . > . > John L. Hufferd > Senior Technical Staff Member (STSM) > IBM/SSG San Jose Ca > Main Office (408) 256-0403, Tie: 276-0403, eFax: (408) 904-4688 > Home Office (408) 997-6136, Cell: (408) 499-9702 > Internet address: hufferd@us.ibm.com > > > "Mallikarjun C." on 07/09/2002 11:00:20 AM > > To: , John Hufferd/San Jose/IBM@IBMUS > cc: > Subject: Re: iSCSI: DLB's Last Call T15 comment > > > > I was part of the team that deliberated on this issue and was a party > to the compromise text. But let me state for the record that I (among > others) had precisely suggested what David is suggesting - make it > a MUST return always, it's simple to specify and implement. > > The reasons offered primarily had to do with changing existing code. > Now with the changes in certain key names and the advent of C-bit > functionality (that require code changes anyway), this may be a good > time to consider making this simpler. I see that Julian also is agreeable > to this change. > -- > Mallikarjun > > Mallikarjun Chadalapaka > Networked Storage Architecture > Network Storage Solutions > Hewlett-Packard MS 5668 > Roseville CA 95747 > cbm@rose.hp.com > > ----- Original Message ----- > From: > To: > Cc: > Sent: Monday, July 08, 2002 11:39 PM > Subject: iSCSI: DLB's Last Call T15 comment > > > > John, > > > > [T.15] 4.3.1 Login Phase Start > > > > The first Login Response PDU during the Login Phase from the iSCSI > > target SHOULD return the TargetPortalGroupTag key that contains the > > tag value of the iSCSI portal group servicing the Login Request PDU. > > If the iSCSI target implementation supports altering the portal group > > configuration (including adding, deleting, and swapping of portals in > > a portal group), it MUST return the TargetPortalGroupTag key carry- > > ing the tag value of the servicing portal group. > > > > Let's make returning this key a MUST in all cases - less text, simpler > > protocol, simpler code at the Initiator. > > > > > The item numbered T15, had a lot of discussions, especially in the > Naming > > > and Discovery Team, and the current wordage was the results of a > > > compromise, where a number of vendors did not have the issue, and > strongly > > > felt that it would be the wrong thing to do with their product. So we > > > agreed that the SHOULD section would be the right answer for > > > every one. > > > > This sort of compromise leads to "MAY", not "SHOULD". I > > suggest summarizing the NDT discussion to the list, as it's now an issue > > to be settled here. > > > > 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 > > --------------------------------------------------- > > > > > > > > From owner-ips@ece.cmu.edu Wed Jul 10 00:21:14 2002 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA26984 for ; Wed, 10 Jul 2002 00:21:13 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id g6A3Pd123829 for ips-outgoing; Tue, 9 Jul 2002 23:25:39 -0400 (EDT) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from maho3msx2.isus.emc.com (maho3msx2.isus.emc.com [128.221.11.32]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id g6A3PcX23825 for ; Tue, 9 Jul 2002 23:25:38 -0400 (EDT) Received: by MAHO3MSX2 with Internet Mail Service (5.5.2653.19) id <31WCK7ZV>; Tue, 9 Jul 2002 23:23:36 -0400 Message-ID: <277DD60FB639D511AC0400B0D068B71E0564C059@CORPMX14> From: Black_David@emc.com To: ips@ece.cmu.edu Subject: FW: WG Review: Intellectual Property Rights Date: Tue, 9 Jul 2002 23:23:34 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-ips@ece.cmu.edu Precedence: bulk FYI for those interested - the BOF for this proposed WG will meet on Friday, July 19th in Yokohama. --David -----Original Message----- From: Steve Coya [mailto:scoya@cnri.reston.va.us] Sent: Tuesday, July 09, 2002 1:02 PM Cc: new-work@ietf.org Subject: WG Review: Intellectual Property Rights A new IETF working group has been proposed in the General Area. The IESG has not made any determination as yet. The following Description was submitted, and is provided for informational purposes only: Intellectual Property Rights (ipr) ------------------------------ Current Status: Proposed Working Group Description of Working Group: The IETF and the Internet have greatly benefited from the free exchange of ideas and technology. For many years the IETF normal behavior was to standardize only unencumbered technology. While the "Tao" of the IETF is still strongly oriented toward unencumbered technology, we can and do make use of technology that has various encumbrances. One of the goals of RFC2026 "The Internet Standards Process -- Revision 3" was to make it easier for the IETF to make use of encumbered technology when it made sense to do so. The IETF IPR policy, as embedded in RFC 2026 section 10, has proven fairly successful. At the same time, a perceived lack of textual clarity on some issues have made necessary the publication of clarifications such as the "note well" statement issued in every registration package, the I-D boilerplate rules, and a huge number of discussions on specific IPR-related issues. This working group is chartered with updating and clarifying section 10 of BCP 9, RFC 2026, which deals with intellectual property rights, including, but not necessarily limited to, patent rights and copyrights. This working group will provide three documents: o A BCP document, updating RFC 2026, which states the IETF IPR policy on rights relevant to the document publication process, such as copyright issues and trademark issues. o A BCP document, updating RFC 2026, which states the IETF IPR policy on rights relevant to the use of IETF-standardized technology, such as patent-related claims o An Informational document, which describes useful rules of thumb for working group chairs and working group members when working on IPR issues, as well as describing specific cases of IPR issues that have been successfully worked out in the IETF process, and providing references to specific examples of licensing statements and copyright provisions that have proved useful or worrisome. In other words, we plan to document the running code of our process. The working group will attempt to work in three phases: 1. Document existing IPR practice in the IETF 2. Identify issues with current IPR practice that need to be addressed 3. Modify the documents produced in step 1 to reflect the outcome of the discussion of items identified in step 2. If there consensus of the working group for a different IPR policy than the one described in RFC 2026, the working group will seek to amend its charter to make it clear that it is changing the status quo. The working group will have a design team to assist with document drafting and review. As always, design team drafts have no special status, and are subject to amendment, ratification, and/or replacement by the working group. From owner-ips@ece.cmu.edu Wed Jul 10 03:58:49 2002 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA24193 for ; Wed, 10 Jul 2002 03:58:49 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id g6A7MuE04300 for ips-outgoing; Wed, 10 Jul 2002 03:22:56 -0400 (EDT) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from mailserver.dcmtech.co.in (IDENT:4/uNx632ns2UuVboQRNFIvWkYtxOgBmT@[203.190.136.131]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id g6A7MjX04292 for ; Wed, 10 Jul 2002 03:22:52 -0400 (EDT) Received: from dcmtech.co.in ([192.9.200.183]) by mailserver.dcmtech.co.in (8.11.6/8.11.6) with ESMTP id g6A7Krt08746 for ; Wed, 10 Jul 2002 07:20:54 GMT Message-ID: <3D2BE225.10804@dcmtech.co.in> Date: Wed, 10 Jul 2002 12:58:37 +0530 From: ishveen User-Agent: Mozilla/5.0 (X11; U; Linux 2.4.2-2 i586; en-US; 0.7) Gecko/20010316 X-Accept-Language: en MIME-Version: 1.0 To: ips@ece.cmu.edu Subject: remove Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-ips@ece.cmu.edu Precedence: bulk Content-Transfer-Encoding: 7bit From owner-ips@ece.cmu.edu Wed Jul 10 04:12:47 2002 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA24335 for ; Wed, 10 Jul 2002 04:12:47 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id g6A7wik05559 for ips-outgoing; Wed, 10 Jul 2002 03:58:44 -0400 (EDT) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from maho3msx2.isus.emc.com (maho3msx2.isus.emc.com [128.221.11.32]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id g6A7wiX05555 for ; Wed, 10 Jul 2002 03:58:44 -0400 (EDT) Received: by MAHO3MSX2 with Internet Mail Service (5.5.2653.19) id <31WCLH3W>; Wed, 10 Jul 2002 03:56:40 -0400 Message-ID: <277DD60FB639D511AC0400B0D068B71E05D4245D@CORPMX14> From: Black_David@emc.com To: cbm@rose.hp.com, ips@ece.cmu.edu Subject: RE: iSCSI: DLB-T.16 (resource requirement for connection reinsta tement) Date: Wed, 10 Jul 2002 03:56:39 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-ips@ece.cmu.edu Precedence: bulk Mallikarjun, I think this ought to be related to ErrorRecoveryLevel - it looks like you're suggesting that connection reinstatement SHOULD be supported at ErrorRecoveryLevel 0 - at 1 and above, I believe it's already a MUST. I don't have a problem with that, does anyone else? Thanks, --David > -----Original Message----- > From: Mallikarjun C. [mailto:cbm@rose.hp.com] > Sent: Tuesday, July 09, 2002 2:52 PM > To: ips@ece.cmu.edu > Subject: iSCSI: DLB-T.16 (resource requirement for connection > reinstatement) > > > > [T.16] 4.3.4 Connection reinstatement > > > > Targets should support opening a second connection even > > when they do not support multiple connections in Full Feature Phase. > > > > Looks like that ought to be an upper case "SHOULD". I think this needs > > further discussion. Section 5.2 appears to use a lower case "must" > > for this: > > Let's be careful here - section 5.2 discusses the generic case of "connection > cleanup" - that includes both implicit and explicit logouts - whereas "connection > reinstatement" is just implicit logout. > > While "connection cleanup" does not require additional connection resources > in the general case, a target wanting to support connection reinstatement SHOULD > support *opening* a second connection (though it may reject the Login if it's > for a different CID). > > I believe that connection reinstatement is a useful functionality that the targets > SHOULD support, so I agree that the change suggested by David is a reasonable > one to make in 4.3.4 which only discusses connection reinstatement. > > Mallikarjun > From owner-ips@ece.cmu.edu Wed Jul 10 04:13:14 2002 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA24350 for ; Wed, 10 Jul 2002 04:13:14 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id g6A7wvv05589 for ips-outgoing; Wed, 10 Jul 2002 03:58:57 -0400 (EDT) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from mxic2.corp.emc.com (mxic2.isus.emc.com [128.221.31.40]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id g6A7wtX05582 for ; Wed, 10 Jul 2002 03:58:55 -0400 (EDT) Received: by mxic2.corp.emc.com with Internet Mail Service (5.5.2653.19) id <31X6SMC5>; Wed, 10 Jul 2002 03:58:49 -0400 Message-ID: <277DD60FB639D511AC0400B0D068B71E05D42460@CORPMX14> From: Black_David@emc.com To: reames@diskdrive.com, ips@ece.cmu.edu Subject: RE: iSCSI: DLB [T.31] Date: Wed, 10 Jul 2002 03:56:48 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-ips@ece.cmu.edu Precedence: bulk Steve, > From DLB's comments: > > >[T.31] 9.16.1 Type > > > > An iSCSI target that does not support recovery within connection MAY > > reject the status SNACK with a Reject PDU. If the target supports > > recovery within connection, it MAY reject the SNACK after which it > > MUST issue an Asynchronous Message PDU with an iSCSI event that indi- > > cates "Request Logout". > > > > This should be conditioned on the operational ErrorRecoveryLevel of the > > session, not whether the target supports recovery within connection. > > I would prefer that this not be conditioned on the ErrorRecoveryLevel. If I > am writing code, I may choose to support recovery-within-connection, but > not all the features that would be required to move me up to > ErrorRecoveryLevel 1. I would like SNACK and Reject PDUs to work properly > for my code, even though it is technically only "ErrorRecoveryLevel 0.5". > As I read it, changing the wording would allow the target to ignore my > improved error recovery efforts unless I have a full ErrorRecoveryLevel 1 > implementation. David, I doubt that is what you intended, so maybe you want > to word it a little differently. Actually, it was what I intended when I made that comment, BUT, I had not considered the scenario you describe above ... and so, I now agree with you. Therefore I'll withdraw my [T.31] comment provided that the possibility of multiple "ErrorRecoveryLevel 0.5" levels of support is described in the overview section to be added on error recovery. 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 --------------------------------------------------- From owner-ips@ece.cmu.edu Wed Jul 10 04:22:15 2002 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA24454 for ; Wed, 10 Jul 2002 04:22:14 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id g6A7x2B05604 for ips-outgoing; Wed, 10 Jul 2002 03:59:02 -0400 (EDT) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from mxic2.corp.emc.com (mxic2.isus.emc.com [128.221.31.40]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id g6A7x0X05600 for ; Wed, 10 Jul 2002 03:59:00 -0400 (EDT) Received: by mxic2.corp.emc.com with Internet Mail Service (5.5.2653.19) id <31X6SMDA>; Wed, 10 Jul 2002 03:58:55 -0400 Message-ID: <277DD60FB639D511AC0400B0D068B71E05D42462@CORPMX14> From: Black_David@emc.com To: dap@cisco.com, ips@ece.cmu.edu Subject: RE: iSCSI: DAP Retry comments Date: Wed, 10 Jul 2002 03:56:56 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-ips@ece.cmu.edu Precedence: bulk If the iSCSI retry timer and the SCSI ULP timeout are set with appropriate coordination (e.g., in this case, 2 seconds would be much better for iSCSI than 8), option A (send NOP after 2 seconds to see if the command arrived) looks like it works ok in the current spec. B is allowed, and enables a clever target to help out, but A should work regardless. In a perfect world, we wouldn't have to deal with legacy tape, and SCSI error recovery would be very efficient ... but the world's not perfect. It looks like the Retry and ErrorRecoveryLevel > 0 recommendations are ok for legacy tape and the like. Thanks, --David > -----Original Message----- > From: Dave Peterson [mailto:dap@cisco.com] > Sent: Tuesday, July 09, 2002 12:22 PM > To: Black_David@emc.com; ips@ece.cmu.edu > Subject: RE: iSCSI: DAP Retry comments > > > Regarding Retry, it's not about the command executing twice. > Below is a rehash from previous emails of the issues with Retry: > ***** > Example scenario: > 1. tape locate command is issued with a 10 second timer > 2. tape command is dropped at the target due to a header digest error > 3. having seen no response for the command after an iSCSI initiator > determined timeout value, the initiator decides to retry the command > > This example leaves a 2 second window for the response to the > second command > to arrive before a ULP abort is sent. > > A mechanism to determine whether or not the command arrived > at the target > would be beneficial for the retry functionality to be useful. > The mechanism should be initiated early enough in the ULP > timeout window to > allow the iSCSI retried command the opportunity to complete. > > Some options: > > A. If the initiator issues a NOP-Out(immed=1), the target can > send back the > expected CmdSN. > > B. The target, upon a header digest error, sends back a > reject or NOP-In > with > the expected CmdSN. This would provide an indication to the > initiator that > something happened and trigger the command retry, still > hopefully within the > ULP timeout to allow for sucessful command completion. > > C. Texting stating that an iSCSI initiator should (only) > perform a command > retry when sufficient time remains for the command to > completed. But, this > leads one down the path of device type specific behavior. > > D. Remove the command retry functionality. I have yet to see > it actually > being used. The use of command retry is really only > applicable when header > digests are being used. Given TCP, probability of header > digest usage and > occurance, > and existing ULP tools for error detection and recovery, my > preference is to > remove it. > **** > > My point is the following need to occur for the Retry > functionality to work: > 1. header digest must be enabled > 2. a header digest must be detected > 3. the retried command must be issued early enough in the ULP > timeout window > to allow completion > > I don't see the Retry functionality being useful for disk devices and > questionable for tape. > Using a well-engineered (TCP/IP) network along with hopefully > available SCSI > level tools is a better solution. > > But I don't want to hold up the spec over this matter either, > we just won't > use it. > > Regarding SNACK, I don't really have a problem with it other > than again a > well-engineered network should mitigate the need. > Regarding connection allegiance reassignment, the > functionality is a bit > more useful (if one supports more than 1 connection per > session), provided > the reassignment completes in time to allow the command to > complete within > the ULP timeout. > > Regarding legacy tape devices, I expect them to be front > ended by a gateway. > These devices will most likely not support any type of > transport level error > detection and recovery making them incompatible/problem > childs with respect > to the various iSCSI error recovery mechanisms. > > Bottom line is engineer your network well and leave the error > detection and > recovery to the SCSI level and above...dap > > > -----Original Message----- > > From: Black_David@emc.com [mailto:Black_David@emc.com] > > Sent: Tuesday, July 09, 2002 1:51 AM > > To: dap@cisco.com; ips@ece.cmu.edu > > Subject: iSCSI: DAP Retry comments > > > > > > > T p 103 6.1.1 Usage of Retry and 6.7 SCSI Timeouts: the > semantics of > > Retry > > > remain broken rendering it useless for tape operation. > SCSI level error > > > detection and recovery is the preferred mechanism. Refer > to previous > > emails > > > sent via the IPS reflector regarding this matter. > > > > Can you provide more information? Command retry *never* results in > > the command executing twice - both the original command and > the retry > > have the same CmdSN, so the second one is dropped as a duplicate if > > the first one was received correctly. 6.1.1 is very clear > that retry > > MUST NOT be used if the command was received successfully > (acknowledged > > by ExpCmdSN), and if it is used, the retried command PDU is silently > > dropped. > > iSCSI's ordered delivery requirement avoids the situation in which a > > dropped command causes subsequent commands to mis-execute - if none > > of the commands are marked for immediate delivery, iSCSI will stop > > at the "hole" created by the dropped command, and wait for the retry > > to plug the hole. > > > > > T p 128 8.6 Considerations for State-dependent devices: last > > paragraph: > > > don't agree with the statement that error recovery at the > iSCSI level > > > (specifically Retry in its current state) is advisable. Retry > > at the SCSI > > > level is feasible and is not difficult (i.e., READ > POSITION and LOCATE > > > commands). This paragraph should be removed. > > > > Two questions: > > - What about the SNACK and allegiance change mechanisms? > > - What about the "legacy" tape devices (e.g., as discussed > in London) > > that presumably don't implement those commands? I believe this > > text was originally intended to address this class of devices. > > > > 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 > > --------------------------------------------------- > From owner-ips@ece.cmu.edu Wed Jul 10 04:25:11 2002 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA24517 for ; Wed, 10 Jul 2002 04:25:11 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id g6A7wrg05579 for ips-outgoing; Wed, 10 Jul 2002 03:58:53 -0400 (EDT) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from maho3msx2.isus.emc.com (maho3msx2.isus.emc.com [128.221.11.32]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id g6A7wpX05573 for ; Wed, 10 Jul 2002 03:58:52 -0400 (EDT) Received: by MAHO3MSX2 with Internet Mail Service (5.5.2653.19) id <31WCLH37>; Wed, 10 Jul 2002 03:56:48 -0400 Message-ID: <277DD60FB639D511AC0400B0D068B71E05D4245F@CORPMX14> From: Black_David@emc.com To: cbm@rose.hp.com, ips@ece.cmu.edu Subject: RE: iSCSI: DLB-T.28 (Logout discards OOO commands) Date: Wed, 10 Jul 2002 03:56:46 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-ips@ece.cmu.edu Precedence: bulk Mallikarjun, The "active" suggestion helps, but the text in Section 9.14 uses the phrase "command reordering queue" without defining it, and uses the word "tasks" where "commands" would have been better. The language used in 9.14 needs to be aligned with the language used to specify command ordering in Section 2.2.2.1. One (somewhat wordy) possibility for rephrasing would be: results in the discarding of commands that have arrived on the connection being logged out but have not been delivered to SCSI because a command with a smaller CmdSN has not been received by iSCSI (see Section 2.2.2.1). 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 --------------------------------------------------- > -----Original Message----- > From: Mallikarjun C. [mailto:cbm@rose.hp.com] > Sent: Tuesday, July 09, 2002 3:43 PM > To: ips@ece.cmu.edu > Subject: iSCSI: DLB-T.28 (Logout discards OOO commands) > > > > [T.28] 9.14 Logout Request > > > > A successful completion of a logout request with the reason code of > > "close the connection" or "remove the connection for recovery" > > results in the discarding of all tasks waiting in the command reor- > > dering queue that are allegiant to the connection being logged out. > > > > "discarding" is not what hapapens in the "remove the connection for recovery > > case according to the following text from Section 6.5: > > > > b) Logout the connection for recovery and continue the tasks on a > > different connection instance as described in Section 6.1 Retry > > and Reassign in Recovery. [OR] > > > > A "discarded" task cannot be "continue"-d. I suspect the text should say > > that "close the connection" terminates the tasks, anad "remove the > > connection > > for recovery" suspends the tasks with the following CmdSN > side effects ... > > Notice the phrase "waiting in the command reordering queue". *Any* > flavor of Logout would cause the OOO commands in the target's reordering > queue to be discarded. The difference in behaviors is only > for the active tasks. > > The recovery Logout, when successfully executed, would prepare the *active > instantiated tasks* for reassignment, while the other two flavors > of Logout would terminate all appropriate tasks. > > I would suggest qualifying the words task/tasks with "active" > in section 6.5 (in the > text you quoted), and also in sections 9.5/9.6 to make this > distinction clear. > > > Mallikarjun > > From owner-ips@ece.cmu.edu Wed Jul 10 04:33:53 2002 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA24692 for ; Wed, 10 Jul 2002 04:33:53 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id g6A7wpD05571 for ips-outgoing; Wed, 10 Jul 2002 03:58:51 -0400 (EDT) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from mxic2.corp.emc.com (mxic2.isus.emc.com [128.221.31.40]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id g6A7woX05567 for ; Wed, 10 Jul 2002 03:58:50 -0400 (EDT) Received: by mxic2.corp.emc.com with Internet Mail Service (5.5.2653.19) id <31X6SMCS>; Wed, 10 Jul 2002 03:58:44 -0400 Message-ID: <277DD60FB639D511AC0400B0D068B71E05D4245E@CORPMX14> From: Black_David@emc.com To: cbm@rose.hp.com, ips@ece.cmu.edu Subject: RE: iSCSI: DLB-T.26 (response for TASK REASSIGN) Date: Wed, 10 Jul 2002 03:56:44 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-ips@ece.cmu.edu Precedence: bulk Ok with an upper case MUST for sending the TMF response first, please. Thanks, --David > -----Original Message----- > From: Mallikarjun C. [mailto:cbm@rose.hp.com] > Sent: Tuesday, July 09, 2002 3:21 PM > To: ips@ece.cmu.edu > Subject: iSCSI: DLB-T.26 (response for TASK REASSIGN) > > > > [T.26] 9.6 Task Management Function Response > > > > For the functions ABORT TASK, ABORT TASK SET, CLEAR ACA, CLEAR TASK > > SET, LOGICAL UNIT RESET, TARGET COLD RESET and TARGET WARM RESET, the > > target performs the requested Task Management function and sends a > > Task Management Response back to the initiator. > > > > TASK REASSIGN does not get a response. Was this intended? > > It may be appropriate to include it in this list, but then it > would be nice to make sure that the > target sends the response to the TMF first before acting on > the reassigned task (which might > possibly involve retransmitting an old status sent before the > connection failure with a new StatSN). > Initiators may get confused if the response for the > reassigned task arrives prior to the the response > to the TMF itself (even while there are no StatSN holes). > > I suggest: > > For all the task management functions defined in 9.5.1, the > target performs the requested function and sends a > Task Management Response back to the initiator. In the case > of the TASK REASSIGN function, the target must > send the reponse to the task management function request > first before acting on the reassigned task. > > > Mallikarjun From owner-ips@ece.cmu.edu Wed Jul 10 04:34:01 2002 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA24714 for ; Wed, 10 Jul 2002 04:34:01 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id g6A7x0E05598 for ips-outgoing; Wed, 10 Jul 2002 03:59:00 -0400 (EDT) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from maho3msx2.isus.emc.com (maho3msx2.isus.emc.com [128.221.11.32]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id g6A7wwX05592 for ; Wed, 10 Jul 2002 03:58:58 -0400 (EDT) Received: by MAHO3MSX2 with Internet Mail Service (5.5.2653.19) id <31WCLHPB>; Wed, 10 Jul 2002 03:56:54 -0400 Message-ID: <277DD60FB639D511AC0400B0D068B71E05D42461@CORPMX14> From: Black_David@emc.com To: cbm@rose.hp.com, ips@ece.cmu.edu Subject: RE: iSCSI: DLB-T.30 (using SNACK w/ PDU size changes) Date: Wed, 10 Jul 2002 03:56:53 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-ips@ece.cmu.edu Precedence: bulk > You're right that there's a duplicate StatSN issue with the rev14 text. > > I believe that can be addressed by mandating that the initiators must > discard the first status PDU always for the task in question, and then issue > a follow-on status SNACK. It may occasionally lead to discarding a good > status (with the right ExpDataSN that reflects the re-segmented DataSN > count), but that would anyway be recovered with the explicit follow-on status > SNACK. > > I don't believe we need to make BegRun=0 for these cases, nor do I believe > that we need a new type of data SNACK. Mallikarjun, I don't think your proposal works very well. One problem is that the initiator may not know how many data PDUs it should have received (and hence know whether it's missing some and needs to issue a Data SNACK) until it processes the status PDU (e.g., suppose the last Data-In PDU doesn't show up). This appears to require receiving the status PDU, processing it, and retroactively dropping it when discovering that not all the data has arrived. That doesn't strike me as a good design (e.g., it prohibits an acknowledge via ExpStatSN before the ExpDataSN processing). There's also at least one weird corner case in here - suppose the initiator issues the Data SNACK and then changes MaxRecvDataSegmentLength before all the data from the SNACK has shown up. Now the initiator would have to retroactively drop a status that it already acknowledged via ExpStatSN. This is bad, and leads to one of several poor outcomes: - Target fails to retransmit the response because the reused StatSN is less than ExpStatSN. The initiator can't recover because it can't issue a status SNACK for StatSN < ExpStatSN. - Target ignores ExpStatSN and sends the response anyway. If the response gets corrupted and has to be dropped, the initiator again can't issue a status SNACK to recover. - Initiator sends a new value of ExpStatSN to the target that is less than the target's current ExpStatSN. That's a serious protocol error. This is still an ugly corner case for a resegmenting Data SNACK because the size change results in the original Data SNACK stopping its transmission, and the initiator has to figure out that it needs to send a resegmenting Data SNACK - not unreasonable, as the initiator did change MaxRecvDataSegmentLength. The alternative of the initiator not realizing the consequences of the size change and hence having the extra response show up and complete the wrong task courtesy of a reused Initiator Task Tag seems far worse. I'm also reminded of John Hufferd's warning that features inserted late in a design tend to be the most error prone. This one (Data SNACK in the face of MaxRecvDataSegmentLength change) seems to have survived two attempts to fix it, so isolating it to its own separate type of Data SNACK is making more and more sense, lest it survive more attempts to fix it ... that way a failed fix won't break ordinary Data SNACKs. The fact that there are potentially subtle problems here was also behind my suggestion that the only acceptable resegmenting Data SNACK should be "Send Everything" - this should be a relatively rare case, and hence a brute force simple robust design is in order, even if it's inefficient. Thanks, --David > -----Original Message----- > From: Mallikarjun C. [mailto:cbm@rose.hp.com] > Sent: Tuesday, July 09, 2002 6:49 PM > To: ips@ece.cmu.edu > Subject: iSCSI: DLB-T.30 (using SNACK w/ PDU size changes) > > > David, > > You're right that there's a duplicate StatSN issue with the rev14 text. > > I believe that can be addressed by mandating that the initiators must > discard the first status PDU always for the task in question, and then issue > a follow-on status SNACK. It may occasionally lead to discarding a good > status (with the right ExpDataSN that reflects the re-segmented DataSN > count), but that would anyway be recovered with the explicit follow-on status > SNACK. > > I don't believe we need to make BegRun=0 for these cases, nor do I believe > that we need a new type of data SNACK. > > Mallikarjun > > > [T.30] 9.16 SNACK Request > > > > If the initiator MaxRecvDataSegmenTLength changed Data-In PDUs > > requested with RunLength 0 (meaning all PDUs after this number) may > > be different from the ones originally sent, in order to reflect > > changes in MaxRecvDataSegmentLength. Their DataSN starts with the > > requested number and is increased by 1 for each resent Data-In PDU. > > If DataSN numbers change and a SCSI-Reponse PDU was sent reflecting > > the DataSN before retransmission it MUST be resent to reflect the new > > numbers. > > > > This was discussed on the list, but there are still some problems here: > > (1) If the MaxRecvDataSegmentLength has changed, the only valid Data > > SNACK is BegRun=0, RunLength=0 (i.e., resend everything). Attempts > > to be more clever than this are an invitation to miscount Data-In > > PDUs and cause problems in the initiator. Targets MUST reject > > all other Data SNACK requests in this situation. > > (2) The new SCSI-Response PDU needs a new StatSN to avoid the initiator > > discarding it as a duplicate. Section 2.2.2.2 is silent on duplicate > > detection for StatSN, but discarding duplicates would be a reasonable > > thing for an initiator to do. > > (3) The initiator needs some way to know that a new response is coming, > > and specifically whether to expect one or two responses. If it > > only expects one and two show up, the initiator could reuse the > > Task Tag once all the data arrives causing a race in which the > > new response could incorrectly complete an unrelated command > > (unlikely, but potentially nasty). > > This suggests calling out the Data SNACK as having > > special behavior: > > - It may resegment Data-In PDUs to deal with MaxRecvDataSegmentLength. > > All other Data SNACK requests MUST NOT resegment. > > - It *always* generates a new SCSI Response due to the possibility > > of resegmentation. > > That's not a great solution, because if one ever sets > RunLength=0> in a Data SNACK, the resulting behavior change is dramatic > > and unexpected. > > This leads to the final proposal: > > - Specify a new SNACK type code (3) for Resegmenting Data SNACK. SNACK > > Data-In resegmentation is allowed only when this is used. If > > resegmentation would be necessary for a Data SNACK (type 1), > > that SNACK MUST be rejected. > > - Both BegRun and RunLength MUST be zero for a Resegmenting Data > > SNACK, and (unlike reserved fields) these MUST be checked by > > the receiver (target). > > - A new SCSI Response is always generated as a result of a Resegmenting > > Data-In SNACK, and it has its own StatSN number to deal with the > > fact that the number of Data-In PDUs may have changed, causing > > a change to the ExpDataSN value. This new response also needs > > to be marked to distinguish it from a response that may have > > been generated earlier (so the initiator knows to wait for the > > new response) - using a bit in the flags field for this seems > > wrong, so specifying a new Response code value (0x02 - see 9.4.3) > > seems like a reasonable way to accomplish this. > > - Data SNACK (type 1) now has consistent behavior - it MUST NOT resegment > > and MUST NOT generate a new SCSI response, ever. > > This approach also has the potentially useful property of making it easy > > to yank out the Resegmenting Data SNACK wart if we ever put restrictions > > on the interaction of MaxRecvDatasegmentLength and Data SNACKs (yes, that's > > a hint ... this has gotten messy enough that forbidding Data SNACKs when > > MaxRecvDataSegmentLength has changed needs to be considered as a possible > > alternative). > > > > This issue also affects some text in 9.16.3. > > > From owner-ips@ece.cmu.edu Wed Jul 10 04:34:23 2002 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA24728 for ; Wed, 10 Jul 2002 04:34:23 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id g6A8GHK06393 for ips-outgoing; Wed, 10 Jul 2002 04:16:17 -0400 (EDT) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from e1.ny.us.ibm.com (e1.ny.us.ibm.com [32.97.182.101]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id g6A8GGX06389 for ; Wed, 10 Jul 2002 04:16:16 -0400 (EDT) Received: from westrelay01.boulder.ibm.com (westrelay01.boulder.ibm.com [9.17.194.22]) by e1.ny.us.ibm.com (8.12.2/8.12.2) with ESMTP id g6A8GAg5171178; Wed, 10 Jul 2002 04:16:10 -0400 Received: from d03nm014.boulder.ibm.com (avpilot.boulder.ibm.com [9.17.203.135]) by westrelay01.boulder.ibm.com (8.12.3/NCO/VER6.3) with ESMTP id g6A8G9Dl065628; Wed, 10 Jul 2002 02:16:09 -0600 X-Priority: 1 (High) Importance: Normal Subject: Re: iSCSI: DLB's Last Call T15 comment To: "Mallikarjun C." Cc: , X-Mailer: Lotus Notes Release 5.0.7 March 21, 2001 Message-ID: From: "John Hufferd" Date: Wed, 10 Jul 2002 01:13:26 -0700 X-MIMETrack: Serialize by Router on D03NM014/03/M/IBM(Release 5.0.10 |March 22, 2002) at 07/10/2002 02:16:09 AM MIME-Version: 1.0 Content-type: text/plain; charset=us-ascii Sender: owner-ips@ece.cmu.edu Precedence: bulk This is NOT and issue with me. But it is my job as purveyor of the compromise, to make sure that we did not quickly change the agreement with out discussion. Those that care, to leave the text as is, should speak up. . . . John L. Hufferd Senior Technical Staff Member (STSM) IBM/SSG San Jose Ca Main Office (408) 256-0403, Tie: 276-0403, eFax: (408) 904-4688 Home Office (408) 997-6136, Cell: (408) 499-9702 Internet address: hufferd@us.ibm.com "Mallikarjun C." @ece.cmu.edu on 07/09/2002 05:28:16 PM Sent by: owner-ips@ece.cmu.edu To: John Hufferd/San Jose/IBM@IBMUS cc: , Subject: Re: iSCSI: DLB's Last Call T15 comment Let me make one more comment on this topic, and I'd let others comment. Eventhough John's note describes a target's ability to do portal group (re)configuration a "problem", I beg to differ. I'd in fact claim that this functionality in some form must be present in every target to initially get it up and running. At any rate, it appears that John is certainly acknowledging that returning TargetPortalGroupTag key always is required for at least certain classes of configurable targets. If that's the case, and given that making code changes is a non-issue now (with all the other recent changes in text negotiation), it escapes me why it's not preferable to simply return one additional key always in Login Response. This makes the code on either end simpler, and the spec certainly simpler. -- Mallikarjun Mallikarjun Chadalapaka Networked Storage Architecture Network Storage Solutions Hewlett-Packard MS 5668 Roseville CA 95747 cbm@rose.hp.com ----- Original Message ----- From: "John Hufferd" To: "Mallikarjun C." Cc: ; Sent: Tuesday, July 09, 2002 11:23 AM Subject: Re: iSCSI: DLB's Last Call T15 comment > > The issue was that some of the folks in the group, did not even perceive > that their boxes would even have the problem that the statement was > designed to handle. And they did not want to have to respond as specified > to get around a problem that did not exist. Hence, they agreed after some > debate that IF a box had that problem then it SHOULD make that response. > They did not want MUST since they did not have the problem to begin with. > And the other folks did not want MAY, since they did not feel that if a box > had that problem, it was approprate for the box not to inform the > Initiator. > > The debate issue about the "realness" of the problem seems to be still > valid (but I would hope that we do not go into that on this list). The > point seemed to be around different design issues. > > So the choice of SHOULD in my opinion was approprate, since it is not > needed if the problem does not exist in a specific implementation, and MAY > is much too weak if the box has the problem. > > > . > . > . > John L. Hufferd > Senior Technical Staff Member (STSM) > IBM/SSG San Jose Ca > Main Office (408) 256-0403, Tie: 276-0403, eFax: (408) 904-4688 > Home Office (408) 997-6136, Cell: (408) 499-9702 > Internet address: hufferd@us.ibm.com > > > "Mallikarjun C." on 07/09/2002 11:00:20 AM > > To: , John Hufferd/San Jose/IBM@IBMUS > cc: > Subject: Re: iSCSI: DLB's Last Call T15 comment > > > > I was part of the team that deliberated on this issue and was a party > to the compromise text. But let me state for the record that I (among > others) had precisely suggested what David is suggesting - make it > a MUST return always, it's simple to specify and implement. > > The reasons offered primarily had to do with changing existing code. > Now with the changes in certain key names and the advent of C-bit > functionality (that require code changes anyway), this may be a good > time to consider making this simpler. I see that Julian also is agreeable > to this change. > -- > Mallikarjun > > Mallikarjun Chadalapaka > Networked Storage Architecture > Network Storage Solutions > Hewlett-Packard MS 5668 > Roseville CA 95747 > cbm@rose.hp.com > > ----- Original Message ----- > From: > To: > Cc: > Sent: Monday, July 08, 2002 11:39 PM > Subject: iSCSI: DLB's Last Call T15 comment > > > > John, > > > > [T.15] 4.3.1 Login Phase Start > > > > The first Login Response PDU during the Login Phase from the iSCSI > > target SHOULD return the TargetPortalGroupTag key that contains the > > tag value of the iSCSI portal group servicing the Login Request PDU. > > If the iSCSI target implementation supports altering the portal group > > configuration (including adding, deleting, and swapping of portals in > > a portal group), it MUST return the TargetPortalGroupTag key carry- > > ing the tag value of the servicing portal group. > > > > Let's make returning this key a MUST in all cases - less text, simpler > > protocol, simpler code at the Initiator. > > > > > The item numbered T15, had a lot of discussions, especially in the > Naming > > > and Discovery Team, and the current wordage was the results of a > > > compromise, where a number of vendors did not have the issue, and > strongly > > > felt that it would be the wrong thing to do with their product. So we > > > agreed that the SHOULD section would be the right answer for > > > every one. > > > > This sort of compromise leads to "MAY", not "SHOULD". I > > suggest summarizing the NDT discussion to the list, as it's now an issue > > to be settled here. > > > > 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 > > --------------------------------------------------- > > > > > > > > From owner-ips@ece.cmu.edu Wed Jul 10 06:27:53 2002 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA26882 for ; Wed, 10 Jul 2002 06:27:53 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id g6A9nb021194 for ips-outgoing; Wed, 10 Jul 2002 05:49:37 -0400 (EDT) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from d12lmsgate.de.ibm.com (d12lmsgate.de.ibm.com [195.212.91.199]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id g6A9nZX21187 for ; Wed, 10 Jul 2002 05:49:36 -0400 (EDT) Received: from d12relay01.de.ibm.com (d12relay01.de.ibm.com [9.165.215.22]) by d12lmsgate.de.ibm.com (8.12.3/8.12.3) with ESMTP id g6A9nKIB082432; Wed, 10 Jul 2002 11:49:20 +0200 Received: from d10hubm1.telaviv.ibm.com (d10ml001.telaviv.ibm.com [9.148.216.55]) by d12relay01.de.ibm.com (8.11.1m3/NCO/VER6.2) with ESMTP id g6A9nIg114340; Wed, 10 Jul 2002 11:49:19 +0200 Importance: High Subject: RE: iSCSI: DLB's [T.6] 2.3 iSCSI Session Types To: "Ayman Ghanem" Cc: Black_David@emc.com, ips@ece.cmu.edu, owner-ips@ece.cmu.edu X-Mailer: Lotus Notes Release 5.0.9 November 16, 2001 Message-ID: From: "Julian Satran" Date: Wed, 10 Jul 2002 06:36:31 +0300 X-MIMETrack: Serialize by Router on D10ML001/10/M/IBM(Release 5.0.9a |January 7, 2002) at 10/07/2002 12:49:19 MIME-Version: 1.0 Content-type: text/plain; charset=us-ascii Sender: owner-ips@ece.cmu.edu Precedence: bulk This was subject to a long debate relate to SendTargets. The issue was that SendTargets was (with resistance) accepted as a "lightweight" discovery. We did not want in any way to encourage long-lived discovery sessions as there are other and better mechanisms to do so (SLP, iSNS) and iSCSI should not have a completely embedded discovery (going to IP storage should enable you to leverage other protocols for management). I will strongly oppose anything that encourages long lived discovery and I think that using the last call to reopen without any new argument an old and closed issue is an abuse of the process. Julo "Ayman Ghanem" , m> cc: Sent by: Subject: RE: iSCSI: DLB's [T.6] 2.3 iSCSI Session Types owner-ips@ece.cmu .edu 07/08/2002 06:53 PM Please respond to "Ayman Ghanem" David, The issue that came up before was if a discovery session could be kept open, why not allow the initiator and target to send NOPs, and allow the target to send Async messages when new targets become available? I don't mean to bring up this issue again at this stage, but using "MAY" leaves room for implementations that want to support this. If we allow NOP and Async PDUs on a discovery session, then changing "MAY" to "MUST" will be fine. -Ayman > -----Original Message----- > From: Black_David@emc.com [mailto:Black_David@emc.com] > Sent: Monday, July 08, 2002 9:19 AM > To: aghanem@cisco.com; ips@ece.cmu.edu > Subject: RE: iSCSI: DLB's [T.6] 2.3 iSCSI Session Types > > > Ayman, > > Something needs to be cleaned up here, as the current text appears > to allow all types of iSCSI PDUs on a discovery session. I didn't > intend to restrict a discovery session to one Send Targets followed > by a logout (i.e., it could be kept open with the initiator periodically > sending a new Send Targets to see if anything has changed), but I > did intend to forbid SCSI commands, task management, etc. on Discovery > sessions. Is that reasonable, or are there additional types of iSCSI > PDUs that you want to see allowed for new device notifications? > > Thanks, > --David > > > -----Original Message----- > > From: Ayman Ghanem [mailto:aghanem@cisco.com] > > Sent: Sunday, July 07, 2002 12:41 PM > > To: ips@ece.cmu.edu > > Subject: RE: iSCSI: DLB's [T.6] 2.3 iSCSI Session Types > > > > > > I prefer leaving this as "MAY" for implementations that want > > to support new > > device notifications. There was a discussion on whether > > discovery sessions > > should be long-lived or not. Using MAY allows both without > > breaking any > > thing. > > > > -Ayman > > > > > [T.6] 2.3 iSCSI Session Types > > > > > > b) Discovery-session - a session opened only for > > target discov- > > > ery; the target MAY accept only text requests with > > the SendTar- > > > gets key and a logout request with reason "close the session". > > > > > > Change "MAY" to "MUST", and say that other requests MUST be > > rejected. > > > > > > From owner-ips@ece.cmu.edu Wed Jul 10 06:28:06 2002 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA26905 for ; Wed, 10 Jul 2002 06:28:06 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id g6A9nu221222 for ips-outgoing; Wed, 10 Jul 2002 05:49:56 -0400 (EDT) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from d12lmsgate-3.de.ibm.com (d12lmsgate-3.de.ibm.com [195.212.91.201]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id g6A9nrX21215; Wed, 10 Jul 2002 05:49:53 -0400 (EDT) Received: from d12relay01.de.ibm.com (d12relay01.de.ibm.com [9.165.215.22]) by d12lmsgate-3.de.ibm.com (8.12.3/8.12.3) with ESMTP id g6A9nk2F070130; Wed, 10 Jul 2002 11:49:46 +0200 Received: from d10hubm1.telaviv.ibm.com (d10ml001.telaviv.ibm.com [9.148.216.55]) by d12relay01.de.ibm.com (8.11.1m3/NCO/VER6.2) with ESMTP id g6A9nkg145182; Wed, 10 Jul 2002 11:49:46 +0200 Subject: Re: iSCSI: DLB-T.17 (format error description) To: "Mallikarjun C." Cc: ips@ece.cmu.edu, owner-ips@ece.cmu.edu X-Mailer: Lotus Notes Release 5.0.9 November 16, 2001 Message-ID: From: "Julian Satran" Date: Wed, 10 Jul 2002 07:54:00 +0300 X-MIMETrack: Serialize by Router on D10ML001/10/M/IBM(Release 5.0.9a |January 7, 2002) at 10/07/2002 12:49:46 MIME-Version: 1.0 Content-type: text/plain; charset=us-ascii Sender: owner-ips@ece.cmu.edu Precedence: bulk I would add also a reference to 9 (as the working draft has already :-)) Julo "Mallikarjun C." To: Sent by: cc: owner-ips@ece.cmu Subject: iSCSI: DLB-T.17 (format error description) .edu 07/09/2002 10:01 PM Please respond to "Mallikarjun C." > [T.17] 6.4 Format Errors > > The following two explicit violations of PDU layout rules are format > errors: > > a) illegal contents of the PDU header (except the Opcode) - for > ex., out-of-range values for certain fields > b) inconsistent contents - for ex., value of one field conflicts > with that of another. > > Format errors indicate a major implementation flaw in one of the par- > ties. > > The two "for ex."s aren't good enough. Details on what is a format error > need > to be spelled out explicitly, given the drastic consequences of committing > one. I agree that the "for ex."s are not quite reassuring. However, I believe those are all that might happen in each class, so I don't want to remove them either. I suggest the following text as the replacement - ------------------------------ 6.4 Format Errors The following two explicit violations of PDU layout rules are format errors: a) out-of-range values for fields (except the Opcode) in the PDU header b) inconsistent values for fields in the PDU header, where value of one field conflicts with that of another. Format errors indicate a major implementation flaw in one of the parties. ------------------------------- Mallikarjun From owner-ips@ece.cmu.edu Wed Jul 10 06:28:24 2002 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA26920 for ; Wed, 10 Jul 2002 06:28:24 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id g6AA0BN21641 for ips-outgoing; Wed, 10 Jul 2002 06:00:11 -0400 (EDT) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from hotmail.com (oe25.law10.hotmail.com [64.4.14.82]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id g6AA0AX21637 for ; Wed, 10 Jul 2002 06:00:10 -0400 (EDT) Received: from mail pickup service by hotmail.com with Microsoft SMTPSVC; Wed, 10 Jul 2002 03:00:04 -0700 X-Originating-IP: [202.135.81.102] From: "Julian Satran \(Hotmail\)" To: "Paul Koning" Cc: "ips" References: <15658.61002.380623.673790@pkoning.dev.equallogic.com> Subject: Re: iSCSI - decimal coded binary strings - a proposed resolution Date: Wed, 10 Jul 2002 13:00:01 +0300 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2600.0000 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 Message-ID: X-OriginalArrivalTime: 10 Jul 2002 10:00:04.0836 (UTC) FILETIME=[906EFA40:01C227F8] Sender: owner-ips@ece.cmu.edu Precedence: bulk Content-Transfer-Encoding: 7bit Paul, There seems to be something missing. There is no decimal coding for numbers over 2**64. And there no implied length for strings. Where is the complexity? Julo ----- Original Message ----- From: "Paul Koning" To: Cc: Sent: Tuesday, July 09, 2002 5:08 PM Subject: Re: iSCSI - decimal coded binary strings - a proposed resolution > >>>>> "Julian" == Julian Satran writes: > > Julian> Paul - I think we are talking again about two different > Julian> thinks: > > Julian> numerical values that could be more than 2**64 - I would not > Julian> forbid it there > > Julian> bit strings that could be longer than 64 bits - I find it > Julian> acceptable > > Julian> The new text could be: > > Julian> decimal-constant: an unsigned decimal number - the digit 0 or > Julian> a string of 1 or more digits starting with a non-zero digit. > Julian> Decimal-constants are used to encode numerical values or > Julian> binary strings. Decimal constants can be used to encode > Julian> binary strings only if the stringlength is explicitly > Julian> speci-fied. There is no implicit length for decimal > Julian> strings. This encoding MUST NOT used for numerical values > Julian> equal or greater than 2**64 or binary strings that could be > Julian> longer than 64 bits. > > There currently are no numeric values >= 2**64. But in any case, I > don't like the idea there either. What I proposed makes the encoding > an attribute of the parameter -- either it can always be encoded in > decimal, or it never can be. > > What you're proposing does that for binary strings. But for numeric > values, the encoding permitted would depend on the particular value. > I don't see any sense in that extra complexity. > > paul > From owner-ips@ece.cmu.edu Wed Jul 10 06:29:08 2002 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA26936 for ; Wed, 10 Jul 2002 06:29:08 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id g6A9nZ621184 for ips-outgoing; Wed, 10 Jul 2002 05:49:35 -0400 (EDT) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from d12lmsgate-3.de.ibm.com (d12lmsgate-3.de.ibm.com [195.212.91.201]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id g6A9nWX21178; Wed, 10 Jul 2002 05:49:32 -0400 (EDT) Received: from d12relay02.de.ibm.com (d12relay02.de.ibm.com [9.165.215.23]) by d12lmsgate-3.de.ibm.com (8.12.3/8.12.3) with ESMTP id g6A9nP2F019790; Wed, 10 Jul 2002 11:49:25 +0200 Received: from d10hubm1.telaviv.ibm.com (d10ml001.telaviv.ibm.com [9.148.216.55]) by d12relay02.de.ibm.com (8.11.1m3/NCO/VER6.2) with ESMTP id g6A9nOd15302; Wed, 10 Jul 2002 11:49:24 +0200 Subject: RE: iSCSI: DLB's [T.6] 2.3 iSCSI Session Types To: Black_David@emc.com Cc: ips@ece.cmu.edu, "Julian Satran" , owner-ips@ece.cmu.edu X-Mailer: Lotus Notes Release 5.0.9 November 16, 2001 Message-ID: From: "Julian Satran" Date: Wed, 10 Jul 2002 06:42:52 +0300 X-MIMETrack: Serialize by Router on D10ML001/10/M/IBM(Release 5.0.9a |January 7, 2002) at 10/07/2002 12:49:24 MIME-Version: 1.0 Content-type: text/plain; charset=us-ascii Sender: owner-ips@ece.cmu.edu Precedence: bulk You have a good point and it was made before but it was the compromise reached after a long debate and I am still opposed to embedded discovery but I can accept it as a lesser evil if the session is short. I can agree with MUST but I will resist adding any notification. It is just the wrong thing to do. Julo Black_David@emc.c om To: Julian Satran/Haifa/IBM@IBMIL Sent by: cc: ips@ece.cmu.edu owner-ips@ece.cmu Subject: RE: iSCSI: DLB's [T.6] 2.3 iSCSI Session Types .edu 07/09/2002 09:38 AM Please respond to Black_David Julian, Your "at its own risk" is an invitation to interoperability problems - if Discovery sessions are meant to be fixed functionality, then an Initiator that attempts to exceed that functionality needs to get told NO - otherwise we're going to see READ commands on Discovery sessions to get additional configuration information, and then task management, and ... this neat stuff will only work right when the same implementation is on both ends of the connection. I have a separate reply to Ayman's message coming that contains an attempt at requirements text, but it's longer than I would like. Thanks, --David -----Original Message----- From: Julian Satran [mailto:Julian_Satran@il.ibm.com] Sent: Tuesday, July 09, 2002 1:40 AM To: Black_David@emc.com Cc: aghanem@cisco.com; ips@ece.cmu.edu; owner-ips@ece.cmu.edu Subject: RE: iSCSI: DLB's [T.6] 2.3 iSCSI Session Types David, The original MAY was perfectly appropriate and so is the MUST. If you say that you have targets that MAY not support anything else than .. the an initiator attempting to use anything else would do it at its own risk. Your preference for MUST puts an additional mandatory burden to targets to CHECK (all targets) that nothing else is sent. It is strict where none of us thought that we have to be. From an initiator POW they are equivalent. For a target it requires more work. I would favor the way we where ... but that may be all age related. Julo Black_David@emc.com Sent by: To: aghanem@cisco.com, owner-ips@ece.cmu.edu ips@ece.cmu.edu cc: Subject: RE: iSCSI: DLB's [T.6] 07/08/2002 05:18 PM 2.3 iSCSI Session Types Please respond to Black_David Ayman, Something needs to be cleaned up here, as the current text appears to allow all types of iSCSI PDUs on a discovery session. I didn't intend to restrict a discovery session to one Send Targets followed by a logout (i.e., it could be kept open with the initiator periodically sending a new Send Targets to see if anything has changed), but I did intend to forbid SCSI commands, task management, etc. on Discovery sessions. Is that reasonable, or are there additional types of iSCSI PDUs that you want to see allowed for new device notifications? Thanks, --David > -----Original Message----- > From: Ayman Ghanem [mailto:aghanem@cisco.com] > Sent: Sunday, July 07, 2002 12:41 PM > To: ips@ece.cmu.edu > Subject: RE: iSCSI: DLB's [T.6] 2.3 iSCSI Session Types > > > I prefer leaving this as "MAY" for implementations that want > to support new > device notifications. There was a discussion on whether > discovery sessions > should be long-lived or not. Using MAY allows both without > breaking any > thing. > > -Ayman > > > [T.6] 2.3 iSCSI Session Types > > > > b) Discovery-session - a session opened only for > target discov- > > ery; the target MAY accept only text requests with > the SendTar- > > gets key and a logout request with reason "close the session". > > > > Change "MAY" to "MUST", and say that other requests MUST be > rejected. > > > From owner-ips@ece.cmu.edu Wed Jul 10 06:29:25 2002 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA26949 for ; Wed, 10 Jul 2002 06:29:24 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id g6A9oAL21260 for ips-outgoing; Wed, 10 Jul 2002 05:50:10 -0400 (EDT) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from d12lmsgate-3.de.ibm.com (d12lmsgate-3.de.ibm.com [195.212.91.201]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id g6A9o7X21252 for ; Wed, 10 Jul 2002 05:50:07 -0400 (EDT) Received: from d12relay02.de.ibm.com (d12relay02.de.ibm.com [9.165.215.23]) by d12lmsgate-3.de.ibm.com (8.12.3/8.12.3) with ESMTP id g6A9np2F076526; Wed, 10 Jul 2002 11:49:51 +0200 Received: from d10hubm1.telaviv.ibm.com (d10ml001.telaviv.ibm.com [9.148.216.55]) by d12relay02.de.ibm.com (8.11.1m3/NCO/VER6.2) with ESMTP id g6A9nod81080; Wed, 10 Jul 2002 11:49:51 +0200 Subject: RE: iSCSI: DAP Retry comments To: "Dave Peterson" Cc: Black_David@emc.com, ips@ece.cmu.edu, owner-ips@ece.cmu.edu X-Mailer: Lotus Notes Release 5.0.9 November 16, 2001 Message-ID: From: "Julian Satran" Date: Wed, 10 Jul 2002 08:10:33 +0300 X-MIMETrack: Serialize by Router on D10ML001/10/M/IBM(Release 5.0.9a |January 7, 2002) at 10/07/2002 12:49:51 MIME-Version: 1.0 Content-type: text/plain; charset=us-ascii Sender: owner-ips@ece.cmu.edu Precedence: bulk Dave, This note was helpful - even if I don't agree with all your points. iSCSI recovery was designed having connection allegiance reassignment as the main target. However reassignment requires all the other mechanisms for it to work properly - i.e., even if you don;t use them within connection you need them during reassignment. Julo "Dave Peterson" To: , Sent by: cc: owner-ips@ece.cmu Subject: RE: iSCSI: DAP Retry comments .edu 07/09/2002 07:22 PM Please respond to "Dave Peterson" Regarding Retry, it's not about the command executing twice. Below is a rehash from previous emails of the issues with Retry: ***** Example scenario: 1. tape locate command is issued with a 10 second timer 2. tape command is dropped at the target due to a header digest error 3. having seen no response for the command after an iSCSI initiator determined timeout value, the initiator decides to retry the command This example leaves a 2 second window for the response to the second command to arrive before a ULP abort is sent. A mechanism to determine whether or not the command arrived at the target would be beneficial for the retry functionality to be useful. The mechanism should be initiated early enough in the ULP timeout window to allow the iSCSI retried command the opportunity to complete. Some options: A. If the initiator issues a NOP-Out(immed=1), the target can send back the expected CmdSN. B. The target, upon a header digest error, sends back a reject or NOP-In with the expected CmdSN. This would provide an indication to the initiator that something happened and trigger the command retry, still hopefully within the ULP timeout to allow for sucessful command completion. C. Texting stating that an iSCSI initiator should (only) perform a command retry when sufficient time remains for the command to completed. But, this leads one down the path of device type specific behavior. D. Remove the command retry functionality. I have yet to see it actually being used. The use of command retry is really only applicable when header digests are being used. Given TCP, probability of header digest usage and occurance, and existing ULP tools for error detection and recovery, my preference is to remove it. **** My point is the following need to occur for the Retry functionality to work: 1. header digest must be enabled 2. a header digest must be detected 3. the retried command must be issued early enough in the ULP timeout window to allow completion I don't see the Retry functionality being useful for disk devices and questionable for tape. Using a well-engineered (TCP/IP) network along with hopefully available SCSI level tools is a better solution. But I don't want to hold up the spec over this matter either, we just won't use it. Regarding SNACK, I don't really have a problem with it other than again a well-engineered network should mitigate the need. Regarding connection allegiance reassignment, the functionality is a bit more useful (if one supports more than 1 connection per session), provided the reassignment completes in time to allow the command to complete within the ULP timeout. Regarding legacy tape devices, I expect them to be front ended by a gateway. These devices will most likely not support any type of transport level error detection and recovery making them incompatible/problem childs with respect to the various iSCSI error recovery mechanisms. Bottom line is engineer your network well and leave the error detection and recovery to the SCSI level and above...dap > -----Original Message----- > From: Black_David@emc.com [mailto:Black_David@emc.com] > Sent: Tuesday, July 09, 2002 1:51 AM > To: dap@cisco.com; ips@ece.cmu.edu > Subject: iSCSI: DAP Retry comments > > > > T p 103 6.1.1 Usage of Retry and 6.7 SCSI Timeouts: the semantics of > Retry > > remain broken rendering it useless for tape operation. SCSI level error > > detection and recovery is the preferred mechanism. Refer to previous > emails > > sent via the IPS reflector regarding this matter. > > Can you provide more information? Command retry *never* results in > the command executing twice - both the original command and the retry > have the same CmdSN, so the second one is dropped as a duplicate if > the first one was received correctly. 6.1.1 is very clear that retry > MUST NOT be used if the command was received successfully (acknowledged > by ExpCmdSN), and if it is used, the retried command PDU is silently > dropped. > iSCSI's ordered delivery requirement avoids the situation in which a > dropped command causes subsequent commands to mis-execute - if none > of the commands are marked for immediate delivery, iSCSI will stop > at the "hole" created by the dropped command, and wait for the retry > to plug the hole. > > > T p 128 8.6 Considerations for State-dependent devices: last > paragraph: > > don't agree with the statement that error recovery at the iSCSI level > > (specifically Retry in its current state) is advisable. Retry > at the SCSI > > level is feasible and is not difficult (i.e., READ POSITION and LOCATE > > commands). This paragraph should be removed. > > Two questions: > - What about the SNACK and allegiance change mechanisms? > - What about the "legacy" tape devices (e.g., as discussed in London) > that presumably don't implement those commands? I believe this > text was originally intended to address this class of devices. > > 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 > --------------------------------------------------- From owner-ips@ece.cmu.edu Wed Jul 10 06:29:38 2002 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA26964 for ; Wed, 10 Jul 2002 06:29:38 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id g6A9nd321200 for ips-outgoing; Wed, 10 Jul 2002 05:49:39 -0400 (EDT) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from d12lmsgate-3.de.ibm.com (d12lmsgate-3.de.ibm.com [195.212.91.201]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id g6A9nbX21193; Wed, 10 Jul 2002 05:49:37 -0400 (EDT) Received: from d12relay01.de.ibm.com (d12relay01.de.ibm.com [9.165.215.22]) by d12lmsgate-3.de.ibm.com (8.12.3/8.12.3) with ESMTP id g6A9nU2F012512; Wed, 10 Jul 2002 11:49:30 +0200 Received: from d10hubm1.telaviv.ibm.com (d10ml001.telaviv.ibm.com [9.148.216.55]) by d12relay01.de.ibm.com (8.11.1m3/NCO/VER6.2) with ESMTP id g6A9nSg98876; Wed, 10 Jul 2002 11:49:28 +0200 Subject: Re: iSCSI: editorial rewrite not needed To: Black_David@emc.com Cc: ips@ece.cmu.edu, "John Hufferd" , owner-ips@ece.cmu.edu X-Mailer: Lotus Notes Release 5.0.9 November 16, 2001 Message-ID: From: "Julian Satran" Date: Wed, 10 Jul 2002 06:59:53 +0300 X-MIMETrack: Serialize by Router on D10ML001/10/M/IBM(Release 5.0.9a |January 7, 2002) at 10/07/2002 12:49:29 MIME-Version: 1.0 Content-type: text/plain; charset=us-ascii Sender: owner-ips@ece.cmu.edu Precedence: bulk David, Swapping 5 and 6 is not a major issue. However I have to object to the recovery overview. It is already contained in 6 itself and in 2. And I have to stand by John's comment about the lateness of your comments. It is disappointing that you got to this that late - and most of your comments refer to text that was there for a long time. Julo Black_David@emc.c om To: John Hufferd/San Jose/IBM@IBMUS Sent by: cc: ips@ece.cmu.edu owner-ips@ece.cmu Subject: iSCSI: editorial rewrite not needed .edu 07/09/2002 09:44 AM Please respond to Black_David John, My original text was: Global Editorial comment: Both the login (4) and error handling (6) sections feel like one of those old Adventure mazes of twisty little passages - all the details seem to be there, for the most part they're correct, but it's very hard to get the proverbial "big picture" of how everything fits together, in terms of how the various mechanisms work with each other and how they accomplish the overall functionality. Both of these could use overview sections describing how the functionality breaks down into the pieces described in the subsections and how they fit together. Swapping the order of Sections 5 and 6 would also be a good idea so that the discussion of Error Handling and Recovery comes before the state machine descriptions that contain a lot of the details of how errors are handled. For error handling, moving Section 6.13 to the front of Section 6 would help organize the Section better, and care should be taken to define or replace terms like "restart login" and "recovery R2T" that are currently used without definitions. > I disagree with the editorial rewrite, especially at this late state. If > they were important that should have been brought up earlier. I fail to see how you got from my original text whose primary request was for "overview sections describing ..." to "editorial rewrite", so I think you're seriously over-reacting. Concerns about comprehensibility have been brought up on the list in the past. > We should > not be discussing editorial style, but whether we have correctly specified > the protocol. This isn't about "editorial style", but rather whether the specification is comprehensible to an implementer who picks it up from scratch without the benefit of this group's email discussions, short term memory, etc. > We have already changed it a couple of times, and you are > now wanting it changed again. This is a very big spec, and each time we > make changes to pretty up the document, the more that is needed, and > someone else has another preference. If the spec has problems, Working Group Last Call is the point in time to find and fix them, and if that takes serious effort, c'est la vie. I'm prepared to listen to arguments that the spec is sufficiently comprehensible as to need no editorial changes, but I'm not inclined to assign them a great deal of credibility at this juncture. > It is already better then most of the > other IETF specs. I think this causes a needless delay. I disagree and take exception to the view that iSCSI is needlessly being held to a higher standard. The need for a comprehensible spec is real, and that is not a higher standard than other IETF specs are generally held to, although there are some that have gotten away - IKE/ISAKMP and the related keying portions of IPsec are an example that we are unfortunately familiar with. It should not take an iSCSI guru with a secret decoder ring to unscramble how the protocol works even if all the interacting pieces are correctly specified somewhere in the document. On further reflection, I think that an overview section on error handling in the current Section 6 plus swapping the order of Section 5 and Section 6 probably removes the need to tease apart the initiator and target state machine specifications in the current Section 5 (my comments E.80 and E.81). That should reduce the amount of work required provided that the overview text for error handling is well- written. 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 --------------------------------------------------- From owner-ips@ece.cmu.edu Wed Jul 10 06:31:27 2002 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA27043 for ; Wed, 10 Jul 2002 06:31:27 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id g6A9niJ21208 for ips-outgoing; Wed, 10 Jul 2002 05:49:44 -0400 (EDT) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from d12lmsgate-2.de.ibm.com (d12lmsgate-2.de.ibm.com [195.212.91.200]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id g6A9ngX21203; Wed, 10 Jul 2002 05:49:42 -0400 (EDT) Received: from d12relay02.de.ibm.com (d12relay02.de.ibm.com [9.165.215.23]) by d12lmsgate-2.de.ibm.com (8.12.3/8.12.3) with ESMTP id g6A9nWIS043522; Wed, 10 Jul 2002 11:49:32 +0200 Received: from d10hubm1.telaviv.ibm.com (d10ml001.telaviv.ibm.com [9.148.216.55]) by d12relay02.de.ibm.com (8.11.1m3/NCO/VER6.2) with ESMTP id g6A9nVd53744; Wed, 10 Jul 2002 11:49:31 +0200 Subject: Re: iSCSI: DLB-T.26 (response for TASK REASSIGN) To: "Mallikarjun C." Cc: ips@ece.cmu.edu, owner-ips@ece.cmu.edu X-Mailer: Lotus Notes Release 5.0.9 November 16, 2001 Message-ID: From: "Julian Satran" Date: Wed, 10 Jul 2002 07:12:49 +0300 X-MIMETrack: Serialize by Router on D10ML001/10/M/IBM(Release 5.0.9a |January 7, 2002) at 10/07/2002 12:49:31 MIME-Version: 1.0 Content-type: text/plain; charset=us-ascii Sender: owner-ips@ece.cmu.edu Precedence: bulk Mallikarjun, Your suggested text fits better in 6.1 or 8.x. In 9 it clutters the text. Thanks, Julo "Mallikarjun C." To: Sent by: cc: owner-ips@ece.cmu Subject: iSCSI: DLB-T.26 (response for TASK REASSIGN) .edu 07/09/2002 10:20 PM Please respond to "Mallikarjun C." > [T.26] 9.6 Task Management Function Response > > For the functions ABORT TASK, ABORT TASK SET, CLEAR ACA, CLEAR TASK > SET, LOGICAL UNIT RESET, TARGET COLD RESET and TARGET WARM RESET, the > target performs the requested Task Management function and sends a > Task Management Response back to the initiator. > > TASK REASSIGN does not get a response. Was this intended? It may be appropriate to include it in this list, but then it would be nice to make sure that the target sends the response to the TMF first before acting on the reassigned task (which might possibly involve retransmitting an old status sent before the connection failure with a new StatSN). Initiators may get confused if the response for the reassigned task arrives prior to the the response to the TMF itself (even while there are no StatSN holes). I suggest: For all the task management functions defined in 9.5.1, the target performs the requested function and sends a Task Management Response back to the initiator. In the case of the TASK REASSIGN function, the target must send the reponse to the task management function request first before acting on the reassigned task. Mallikarjun From owner-ips@ece.cmu.edu Wed Jul 10 09:48:56 2002 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA02412 for ; Wed, 10 Jul 2002 09:48:56 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id g6ADA4829702 for ips-outgoing; Wed, 10 Jul 2002 09:10:04 -0400 (EDT) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from cygnus.equallogic.com (cygnus.equallogic.com [65.170.102.10]) by ece.cmu.edu (8.11.0/8.10.2) with SMTP id g6ADA2X29696 for ; Wed, 10 Jul 2002 09:10:02 -0400 (EDT) Received: from cygnus.equallogic.com (localhost.localdomain [127.0.0.1]) by cygnus.equallogic.com (8.11.6/8.11.6) with ESMTP id g6AD9qC21156 for ; Wed, 10 Jul 2002 09:09:53 -0400 Received: from deneb.dev.equallogic.com (deneb.dev.equallogic.com [172.16.1.99]) by cygnus.equallogic.com (8.11.6/8.11.6) with ESMTP id g6AD9qQ21147; Wed, 10 Jul 2002 09:09:52 -0400 Received: from pkoning.dev.equallogic.com.equallogic.com (localhost.localdomain [127.0.0.1]) by deneb.dev.equallogic.com (8.11.6/8.11.6) with SMTP id g6AD9qb02724; Wed, 10 Jul 2002 09:09:52 -0400 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <15660.12832.47126.896057@pkoning.dev.equallogic.com> Date: Wed, 10 Jul 2002 09:09:52 -0400 From: Paul Koning To: Julian_Satran@il.ibm.com Cc: ips@ece.cmu.edu Subject: Re: iSCSI - decimal coded binary strings - a proposed resolution References: <15658.61002.380623.673790@pkoning.dev.equallogic.com> X-Mailer: VM 7.01 under 21.1 (patch 11) "Carlsbad Caverns" XEmacs Lucid Sender: owner-ips@ece.cmu.edu Precedence: bulk Content-Transfer-Encoding: 7bit > Paul, > There seems to be something missing. > There is no decimal coding for numbers over 2**64. > And there no implied length for strings. > Where is the complexity? If I understood correctly, you were proposing: 1. For binary strings, decimal coding is allowed only if the particular string can never be longer than 64 bits. In other words, even in cases when some of the allowed values are less than 64 bits, you're not allowed to use decimal, ever. So the encoding rule is tied to the parameter, not to its value. 2. On the other hand, for numbers, the proposed rule says that you can encode the value in decimal whenever the value happens to be less than 2**64. If 5 minutes later that same parameter happens to have a value 2**64 or greater, then you cannot encode that particular value in decimal. So the encoding rule here is tied to the value, not the parameter; a given parameter sometimes permits decimal and sometimes not. That's what I meant: it is extra complexity to have an encoding rule for a variable that isn't the same for all possible values of the variable. paul From owner-ips@ece.cmu.edu Wed Jul 10 10:47:32 2002 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA05033 for ; Wed, 10 Jul 2002 10:47:32 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id g6AE0LN02519 for ips-outgoing; Wed, 10 Jul 2002 10:00:21 -0400 (EDT) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from mail.ivivity.com ([64.238.111.99]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id g6AE0KX02514 for ; Wed, 10 Jul 2002 10:00:20 -0400 (EDT) Received: by ATLOPS with Internet Mail Service (5.5.2653.19) id <3ST10PR8>; Wed, 10 Jul 2002 10:00:19 -0400 Message-ID: From: Eddy Quicksall To: "julian_satran@il. ibm. com (E-mail)" Cc: "ips@ece. cmu. edu (E-mail)" Date: Wed, 10 Jul 2002 10:00:19 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C2281A.20093410" Sender: owner-ips@ece.cmu.edu Precedence: bulk This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_001_01C2281A.20093410 Content-Type: text/plain; charset="iso-8859-1" Section 2.2.4 says: If any non-immediate unsolicited data are sent, the total unsolicited data MUST be either the negotiated amount or all the data if the total amount is less than the negotiated amount for unsolicited data. I would like to suggest that it say "FirstBurstLength" in place of "the negotiated amount". Eddy mailto:Eddy_Quicksall@iVivity.com ------_=_NextPart_001_01C2281A.20093410 Content-Type: text/html; charset="iso-8859-1"

Section 2.2.4 says:
 

If any non-immediate unsolicited data are sent, the total unsolicited data MUST be either the negotiated amount or all the data if the total amount is less than the negotiated amount for unsolicited data.

I would like to suggest that it say "FirstBurstLength" in place of "the negotiated amount".
 
Eddy
mailto:Eddy_Quicksall@iVivity.com
 
------_=_NextPart_001_01C2281A.20093410-- From owner-ips@ece.cmu.edu Wed Jul 10 10:49:59 2002 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA05100 for ; Wed, 10 Jul 2002 10:49:54 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id g6AET5604252 for ips-outgoing; Wed, 10 Jul 2002 10:29:05 -0400 (EDT) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from d12lmsgate.de.ibm.com (d12lmsgate.de.ibm.com [195.212.91.199]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id g6AET1X04241; Wed, 10 Jul 2002 10:29:02 -0400 (EDT) Received: from d12relay01.de.ibm.com (d12relay01.de.ibm.com [9.165.215.22]) by d12lmsgate.de.ibm.com (8.12.3/8.12.3) with ESMTP id g6AESmIB050020; Wed, 10 Jul 2002 16:28:48 +0200 Received: from d10hubm1.telaviv.ibm.com (d10ml001.telaviv.ibm.com [9.148.216.55]) by d12relay01.de.ibm.com (8.11.1m3/NCO/VER6.2) with ESMTP id g6AESig115414; Wed, 10 Jul 2002 16:28:44 +0200 To: Black_David@emc.com Cc: cbm@rose.hp.com, ips@ece.cmu.edu, owner-ips@ece.cmu.edu MIME-Version: 1.0 Subject: RE: iSCSI: DLB-T.30 (using SNACK w/ PDU size changes) X-Mailer: Lotus Notes Release 5.0.9 November 16, 2001 From: "Julian Satran" Message-ID: Date: Wed, 10 Jul 2002 17:27:43 +0300 X-MIMETrack: Serialize by Router on D10ML001/10/M/IBM(Release 5.0.9a |January 7, 2002) at 10/07/2002 17:28:49, Serialize complete at 10/07/2002 17:28:49 Content-Type: multipart/alternative; boundary="=_alternative 004F09DEC2256BF2_=" Sender: owner-ips@ece.cmu.edu Precedence: bulk This is a multipart message in MIME format. --=_alternative 004F09DEC2256BF2_= Content-Type: text/plain; charset="us-ascii" I pointed out that for any of the issues raised I will say whatever I have to say on the list of issues. For the issue that you debate happily I proposed a simple solution - and the text is on my site since Sunday or Monday. And BTW this was one of the countable few real issues on the list - and would not categorize even this as major. Julo Black_David@emc.com Sent by: owner-ips@ece.cmu.edu 07/10/2002 10:56 AM Please respond to Black_David To: cbm@rose.hp.com, ips@ece.cmu.edu cc: Subject: RE: iSCSI: DLB-T.30 (using SNACK w/ PDU size changes) > You're right that there's a duplicate StatSN issue with the rev14 text. > > I believe that can be addressed by mandating that the initiators must > discard the first status PDU always for the task in question, and then issue > a follow-on status SNACK. It may occasionally lead to discarding a good > status (with the right ExpDataSN that reflects the re-segmented DataSN > count), but that would anyway be recovered with the explicit follow-on status > SNACK. > > I don't believe we need to make BegRun=0 for these cases, nor do I believe > that we need a new type of data SNACK. Mallikarjun, I don't think your proposal works very well. One problem is that the initiator may not know how many data PDUs it should have received (and hence know whether it's missing some and needs to issue a Data SNACK) until it processes the status PDU (e.g., suppose the last Data-In PDU doesn't show up). This appears to require receiving the status PDU, processing it, and retroactively dropping it when discovering that not all the data has arrived. That doesn't strike me as a good design (e.g., it prohibits an acknowledge via ExpStatSN before the ExpDataSN processing). There's also at least one weird corner case in here - suppose the initiator issues the Data SNACK and then changes MaxRecvDataSegmentLength before all the data from the SNACK has shown up. Now the initiator would have to retroactively drop a status that it already acknowledged via ExpStatSN. This is bad, and leads to one of several poor outcomes: - Target fails to retransmit the response because the reused StatSN is less than ExpStatSN. The initiator can't recover because it can't issue a status SNACK for StatSN < ExpStatSN. - Target ignores ExpStatSN and sends the response anyway. If the response gets corrupted and has to be dropped, the initiator again can't issue a status SNACK to recover. - Initiator sends a new value of ExpStatSN to the target that is less than the target's current ExpStatSN. That's a serious protocol error. This is still an ugly corner case for a resegmenting Data SNACK because the size change results in the original Data SNACK stopping its transmission, and the initiator has to figure out that it needs to send a resegmenting Data SNACK - not unreasonable, as the initiator did change MaxRecvDataSegmentLength. The alternative of the initiator not realizing the consequences of the size change and hence having the extra response show up and complete the wrong task courtesy of a reused Initiator Task Tag seems far worse. I'm also reminded of John Hufferd's warning that features inserted late in a design tend to be the most error prone. This one (Data SNACK in the face of MaxRecvDataSegmentLength change) seems to have survived two attempts to fix it, so isolating it to its own separate type of Data SNACK is making more and more sense, lest it survive more attempts to fix it ... that way a failed fix won't break ordinary Data SNACKs. The fact that there are potentially subtle problems here was also behind my suggestion that the only acceptable resegmenting Data SNACK should be "Send Everything" - this should be a relatively rare case, and hence a brute force simple robust design is in order, even if it's inefficient. Thanks, --David > -----Original Message----- > From: Mallikarjun C. [mailto:cbm@rose.hp.com] > Sent: Tuesday, July 09, 2002 6:49 PM > To: ips@ece.cmu.edu > Subject: iSCSI: DLB-T.30 (using SNACK w/ PDU size changes) > > > David, > > You're right that there's a duplicate StatSN issue with the rev14 text. > > I believe that can be addressed by mandating that the initiators must > discard the first status PDU always for the task in question, and then issue > a follow-on status SNACK. It may occasionally lead to discarding a good > status (with the right ExpDataSN that reflects the re-segmented DataSN > count), but that would anyway be recovered with the explicit follow-on status > SNACK. > > I don't believe we need to make BegRun=0 for these cases, nor do I believe > that we need a new type of data SNACK. > > Mallikarjun > > > [T.30] 9.16 SNACK Request > > > > If the initiator MaxRecvDataSegmenTLength changed Data-In PDUs > > requested with RunLength 0 (meaning all PDUs after this number) may > > be different from the ones originally sent, in order to reflect > > changes in MaxRecvDataSegmentLength. Their DataSN starts with the > > requested number and is increased by 1 for each resent Data-In PDU. > > If DataSN numbers change and a SCSI-Reponse PDU was sent reflecting > > the DataSN before retransmission it MUST be resent to reflect the new > > numbers. > > > > This was discussed on the list, but there are still some problems here: > > (1) If the MaxRecvDataSegmentLength has changed, the only valid Data > > SNACK is BegRun=0, RunLength=0 (i.e., resend everything). Attempts > > to be more clever than this are an invitation to miscount Data-In > > PDUs and cause problems in the initiator. Targets MUST reject > > all other Data SNACK requests in this situation. > > (2) The new SCSI-Response PDU needs a new StatSN to avoid the initiator > > discarding it as a duplicate. Section 2.2.2.2 is silent on duplicate > > detection for StatSN, but discarding duplicates would be a reasonable > > thing for an initiator to do. > > (3) The initiator needs some way to know that a new response is coming, > > and specifically whether to expect one or two responses. If it > > only expects one and two show up, the initiator could reuse the > > Task Tag once all the data arrives causing a race in which the > > new response could incorrectly complete an unrelated command > > (unlikely, but potentially nasty). > > This suggests calling out the Data SNACK as having > > special behavior: > > - It may resegment Data-In PDUs to deal with MaxRecvDataSegmentLength. > > All other Data SNACK requests MUST NOT resegment. > > - It *always* generates a new SCSI Response due to the possibility > > of resegmentation. > > That's not a great solution, because if one ever sets > RunLength=0> in a Data SNACK, the resulting behavior change is dramatic > > and unexpected. > > This leads to the final proposal: > > - Specify a new SNACK type code (3) for Resegmenting Data SNACK. SNACK > > Data-In resegmentation is allowed only when this is used. If > > resegmentation would be necessary for a Data SNACK (type 1), > > that SNACK MUST be rejected. > > - Both BegRun and RunLength MUST be zero for a Resegmenting Data > > SNACK, and (unlike reserved fields) these MUST be checked by > > the receiver (target). > > - A new SCSI Response is always generated as a result of a Resegmenting > > Data-In SNACK, and it has its own StatSN number to deal with the > > fact that the number of Data-In PDUs may have changed, causing > > a change to the ExpDataSN value. This new response also needs > > to be marked to distinguish it from a response that may have > > been generated earlier (so the initiator knows to wait for the > > new response) - using a bit in the flags field for this seems > > wrong, so specifying a new Response code value (0x02 - see 9.4.3) > > seems like a reasonable way to accomplish this. > > - Data SNACK (type 1) now has consistent behavior - it MUST NOT resegment > > and MUST NOT generate a new SCSI response, ever. > > This approach also has the potentially useful property of making it easy > > to yank out the Resegmenting Data SNACK wart if we ever put restrictions > > on the interaction of MaxRecvDatasegmentLength and Data SNACKs (yes, that's > > a hint ... this has gotten messy enough that forbidding Data SNACKs when > > MaxRecvDataSegmentLength has changed needs to be considered as a possible > > alternative). > > > > This issue also affects some text in 9.16.3. > > > --=_alternative 004F09DEC2256BF2_= Content-Type: text/html; charset="us-ascii"
I pointed out that for any of the issues raised I will say whatever I have to say on the list of issues.
For the issue that you debate  happily I proposed a simple solution - and the text is on my site since Sunday or Monday.

And BTW this was one of the countable few real issues on the list  - and would not categorize even this as major.

Julo


Black_David@emc.com
Sent by: owner-ips@ece.cmu.edu

07/10/2002 10:56 AM
Please respond to Black_David

       
        To:        cbm@rose.hp.com, ips@ece.cmu.edu
        cc:        
        Subject:        RE: iSCSI: DLB-T.30 (using SNACK w/ PDU size changes)

       


> You're right that there's a duplicate StatSN issue with the rev14 text.
>
> I believe that can be addressed by mandating that the initiators must
> discard the first status PDU always for the task in question, and then
issue
> a follow-on status SNACK.  It may occasionally lead to discarding a good
> status (with the right ExpDataSN that reflects the re-segmented DataSN
> count), but that would anyway be recovered with the explicit follow-on
status
> SNACK.
>
> I don't believe we need to make BegRun=0 for these cases, nor do I believe
> that we need a new type of data SNACK.

Mallikarjun,

I don't think your proposal works very well.  One problem is that
the initiator may not know how many data PDUs it should have received
(and hence know whether it's missing some and needs to issue a Data SNACK)
until it processes the status PDU (e.g., suppose the last Data-In PDU
doesn't show up).  This appears to require receiving the status
PDU, processing it, and retroactively dropping it when discovering
that not all the data has arrived.  That doesn't strike me as a
good design (e.g., it prohibits an acknowledge via ExpStatSN before
the ExpDataSN processing).

There's also at least one weird corner case in here - suppose
the initiator issues the Data SNACK and then changes
MaxRecvDataSegmentLength before all the data from the SNACK has
shown up.  Now the initiator would have to retroactively drop a status
that it already acknowledged via ExpStatSN.  This is bad, and leads
to one of several poor outcomes:

- Target fails to retransmit the response because the reused
                StatSN is less than ExpStatSN.  The initiator can't recover
                because it can't issue a status SNACK for StatSN < ExpStatSN.
- Target ignores ExpStatSN and sends the response anyway.  If
                the response gets corrupted and has to be dropped, the
                initiator again can't issue a status SNACK to recover.
- Initiator sends a new value of ExpStatSN to the target that is
                less than the target's current ExpStatSN.  That's a
                serious protocol error.

This is still an ugly corner case for a resegmenting Data SNACK
because the size change results in the original Data SNACK stopping
its transmission, and the initiator has to figure out that it needs
to send a resegmenting Data SNACK - not unreasonable, as the initiator
did change MaxRecvDataSegmentLength.  The alternative of the
initiator not realizing the consequences of the size change and
hence having the extra response show up and complete the wrong
task courtesy of a reused Initiator Task Tag seems far worse.

I'm also reminded of John Hufferd's warning that features inserted
late in a design tend to be the most error prone.  This one (Data
SNACK in the face of MaxRecvDataSegmentLength change) seems to have
survived two attempts to fix it, so isolating it to its own separate
type of Data SNACK is making more and more sense, lest it survive
more attempts to fix it ... that way a failed fix won't
break ordinary Data SNACKs.  The fact that there are potentially
subtle problems here was also behind my suggestion that the only
acceptable resegmenting Data SNACK should be "Send Everything" -
this should be a relatively rare case, and hence a brute force
simple robust design is in order, even if it's inefficient.

Thanks,
--David


> -----Original Message-----
> From: Mallikarjun C. [mailto:cbm@rose.hp.com]
> Sent: Tuesday, July 09, 2002 6:49 PM
> To: ips@ece.cmu.edu
> Subject: iSCSI: DLB-T.30 (using SNACK w/ PDU size changes)
>
>
> David,
>
> You're right that there's a duplicate StatSN issue with the rev14 text.
>
> I believe that can be addressed by mandating that the initiators must
> discard the first status PDU always for the task in question, and then
issue
> a follow-on status SNACK.  It may occasionally lead to discarding a good
> status (with the right ExpDataSN that reflects the re-segmented DataSN
> count), but that would anyway be recovered with the explicit follow-on
status
> SNACK.
>
> I don't believe we need to make BegRun=0 for these cases, nor do I believe
> that we need a new type of data SNACK.  
>
> Mallikarjun
>
> > [T.30] 9.16   SNACK Request
> >
> >    If the initiator MaxRecvDataSegmenTLength changed Data-In PDUs
> >    requested with RunLength 0 (meaning all PDUs after this number) may
> >    be different from the ones originally sent, in order to reflect
> >    changes in MaxRecvDataSegmentLength. Their DataSN starts with the
> >    requested number and is increased by 1 for each resent Data-In PDU.
> >    If DataSN numbers change and a SCSI-Reponse PDU was sent reflecting
> >    the DataSN before retransmission it MUST be resent to reflect the new

> >    numbers.
> >
> > This was discussed on the list, but there are still some problems here:
> > (1) If the MaxRecvDataSegmentLength has changed, the only valid Data
> > SNACK is BegRun=0, RunLength=0 (i.e., resend everything).  Attempts
> > to be more clever than this are an invitation to miscount Data-In
> > PDUs and cause problems in the initiator.  Targets MUST reject
> > all other Data SNACK requests in this situation.
> > (2) The new SCSI-Response PDU needs a new StatSN to avoid the initiator
> > discarding it as a duplicate.  Section 2.2.2.2 is silent on duplicate
> > detection for StatSN, but discarding duplicates would be a reasonable
> > thing for an initiator to do.
> > (3) The initiator needs some way to know that a new response is coming,
> > and specifically whether to expect one or two responses.  If it
> > only expects one and two show up, the initiator could reuse the
> > Task Tag once all the data arrives causing a race in which the
> > new response could incorrectly complete an unrelated command
> > (unlikely, but potentially nasty).
> > This suggests calling out the <BegRun=0, RunLength=0> Data SNACK as
having
> > special behavior:
> > - It may resegment Data-In PDUs to deal with MaxRecvDataSegmentLength.
> > All other Data SNACK requests MUST NOT resegment.
> > - It *always* generates a new SCSI Response due to the possibility
> > of resegmentation.
> > That's not a great solution, because if one ever sets <BegRun=0,
> > RunLength=0> in a Data SNACK, the resulting behavior change is dramatic
> > and unexpected.
> > This leads to the final proposal:
> > - Specify a new SNACK type code (3) for Resegmenting Data SNACK.  SNACK
> > Data-In resegmentation is allowed only when this is used.  If
> > resegmentation would be necessary for a Data SNACK (type 1),
> > that SNACK MUST be rejected.
> > - Both BegRun and RunLength MUST be zero for a Resegmenting Data
> > SNACK, and (unlike reserved fields) these MUST be checked by
> > the receiver (target).
> > - A new SCSI Response is always generated as a result of a Resegmenting
> > Data-In SNACK, and it has its own StatSN number to deal with the
> > fact that the number of Data-In PDUs may have changed, causing
> > a change to the ExpDataSN value.  This new response also needs
> > to be marked to distinguish it from a response that may have
> > been generated earlier (so the initiator knows to wait for the
> > new response) - using a bit in the flags field for this seems
> > wrong, so specifying a new Response code value (0x02 - see 9.4.3)
> > seems like a reasonable way to accomplish this.
> > - Data SNACK (type 1) now has consistent behavior - it MUST NOT
resegment
> > and MUST NOT generate a new SCSI response, ever.
> > This approach also has the potentially useful property of making it easy
> > to yank out the Resegmenting Data SNACK wart if we ever put restrictions
> > on the interaction of MaxRecvDatasegmentLength and Data SNACKs (yes,
that's
> > a hint ... this has gotten messy enough that forbidding Data SNACKs when
> > MaxRecvDataSegmentLength has changed needs to be considered as a
possible
> > alternative).
> >
> > This issue also affects some text in 9.16.3.
>
>  
>


--=_alternative 004F09DEC2256BF2_=-- From owner-ips@ece.cmu.edu Wed Jul 10 11:11:42 2002 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA06236 for ; Wed, 10 Jul 2002 11:11:41 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id g6AEYWr04602 for ips-outgoing; Wed, 10 Jul 2002 10:34:32 -0400 (EDT) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from dogwood.cisco.com (dogwood.cisco.com [161.44.11.19]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id g6AEYUX04595 for ; Wed, 10 Jul 2002 10:34:30 -0400 (EDT) Received: from aghanemw2k (dhcp-161-44-68-161.cisco.com [161.44.68.161]) by dogwood.cisco.com (8.8.6 (PHNE_14041)/CISCO.SERVER.1.2) with SMTP id KAA21071 for ; Wed, 10 Jul 2002 10:34:24 -0400 (EDT) From: "Ayman Ghanem" To: Subject: RE: iSCSI: DLB's [T.6] 2.3 iSCSI Session Types Date: Wed, 10 Jul 2002 09:34:24 -0500 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0) Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2919.6700 In-Reply-To: Sender: owner-ips@ece.cmu.edu Precedence: bulk Content-Transfer-Encoding: 7bit Julian, I stated in my e-mail that I do not want to reopen this issue at this stage. Leaving it the way it is in draft-14 is perfectly acceptable. Changing "MAY" to "MUST" with the text per David's last e-mail is also acceptable. -Ayman > -----Original Message----- > From: Julian Satran [mailto:Julian_Satran@il.ibm.com] > Sent: Tuesday, July 09, 2002 10:37 PM > To: Ayman Ghanem > Cc: Black_David@emc.com; ips@ece.cmu.edu; owner-ips@ece.cmu.edu > Subject: RE: iSCSI: DLB's [T.6] 2.3 iSCSI Session Types > Importance: High > > > > This was subject to a long debate relate to SendTargets. > The issue was that SendTargets was (with resistance) accepted as a > "lightweight" discovery. > We did not want in any way to encourage long-lived discovery sessions as > there are other and better mechanisms > to do so (SLP, iSNS) and iSCSI should not have a completely embedded > discovery (going to IP storage > should enable you to leverage other protocols for management). > I will strongly oppose anything that encourages long lived discovery and I > think that using the last call to reopen > without any new argument an old and closed issue is an abuse of the > process. > > Julo > > > > > "Ayman Ghanem" > > , > > m> cc: > > Sent by: Subject: RE: > iSCSI: DLB's [T.6] 2.3 iSCSI Session Types > > owner-ips@ece.cmu > > .edu > > > > > > 07/08/2002 06:53 > > PM > > Please respond to > > "Ayman Ghanem" > > > > > > > > > David, > > The issue that came up before was if a discovery session could be kept > open, > why not allow the initiator and target to send NOPs, and allow the target > to > send Async messages when new targets become available? > > I don't mean to bring up this issue again at this stage, but using "MAY" > leaves room for implementations that want to support this. If we allow NOP > and Async PDUs on a discovery session, then changing "MAY" to "MUST" will > be > fine. > > -Ayman > > > > -----Original Message----- > > From: Black_David@emc.com [mailto:Black_David@emc.com] > > Sent: Monday, July 08, 2002 9:19 AM > > To: aghanem@cisco.com; ips@ece.cmu.edu > > Subject: RE: iSCSI: DLB's [T.6] 2.3 iSCSI Session Types > > > > > > Ayman, > > > > Something needs to be cleaned up here, as the current text appears > > to allow all types of iSCSI PDUs on a discovery session. I didn't > > intend to restrict a discovery session to one Send Targets followed > > by a logout (i.e., it could be kept open with the initiator periodically > > sending a new Send Targets to see if anything has changed), but I > > did intend to forbid SCSI commands, task management, etc. on Discovery > > sessions. Is that reasonable, or are there additional types of iSCSI > > PDUs that you want to see allowed for new device notifications? > > > > Thanks, > > --David > > > > > -----Original Message----- > > > From: Ayman Ghanem [mailto:aghanem@cisco.com] > > > Sent: Sunday, July 07, 2002 12:41 PM > > > To: ips@ece.cmu.edu > > > Subject: RE: iSCSI: DLB's [T.6] 2.3 iSCSI Session Types > > > > > > > > > I prefer leaving this as "MAY" for implementations that want > > > to support new > > > device notifications. There was a discussion on whether > > > discovery sessions > > > should be long-lived or not. Using MAY allows both without > > > breaking any > > > thing. > > > > > > -Ayman > > > > > > > [T.6] 2.3 iSCSI Session Types > > > > > > > > b) Discovery-session - a session opened only for > > > target discov- > > > > ery; the target MAY accept only text requests with > > > the SendTar- > > > > gets key and a logout request with reason "close the session". > > > > > > > > Change "MAY" to "MUST", and say that other requests MUST be > > > rejected. > > > > > > > > > > > > > > > From owner-ips@ece.cmu.edu Wed Jul 10 11:14:14 2002 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA06345 for ; Wed, 10 Jul 2002 11:14:14 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id g6AF5ma06723 for ips-outgoing; Wed, 10 Jul 2002 11:05:48 -0400 (EDT) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from d12lmsgate-3.de.ibm.com (d12lmsgate-3.de.ibm.com [195.212.91.201]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id g6AF5jX06716; Wed, 10 Jul 2002 11:05:45 -0400 (EDT) Received: from d12relay01.de.ibm.com (d12relay01.de.ibm.com [9.165.215.22]) by d12lmsgate-3.de.ibm.com (8.12.3/8.12.3) with ESMTP id g6AF5b2F054854; Wed, 10 Jul 2002 17:05:37 +0200 Received: from d10hubm1.telaviv.ibm.com (d10ml001.telaviv.ibm.com [9.148.216.55]) by d12relay01.de.ibm.com (8.11.1m3/NCO/VER6.2) with ESMTP id g6AF5ag60262; Wed, 10 Jul 2002 17:05:36 +0200 Subject: RE: iSCSI: DLB-T.26 (response for TASK REASSIGN) To: Black_David@emc.com Cc: cbm@rose.hp.com, ips@ece.cmu.edu, owner-ips@ece.cmu.edu X-Mailer: Lotus Notes Release 5.0.9 November 16, 2001 Message-ID: From: "Julian Satran" Date: Wed, 10 Jul 2002 18:02:05 +0300 X-MIMETrack: Serialize by Router on D10ML001/10/M/IBM(Release 5.0.9a |January 7, 2002) at 10/07/2002 18:05:36 MIME-Version: 1.0 Content-type: text/plain; charset=us-ascii Sender: owner-ips@ece.cmu.edu Precedence: bulk As before - there is already text and commented issue dealing with that. Julo Black_David@emc.c om To: cbm@rose.hp.com, ips@ece.cmu.edu Sent by: cc: owner-ips@ece.cmu Subject: RE: iSCSI: DLB-T.26 (response for TASK REASSIGN) .edu 07/10/2002 10:56 AM Please respond to Black_David Ok with an upper case MUST for sending the TMF response first, please. Thanks, --David > -----Original Message----- > From: Mallikarjun C. [mailto:cbm@rose.hp.com] > Sent: Tuesday, July 09, 2002 3:21 PM > To: ips@ece.cmu.edu > Subject: iSCSI: DLB-T.26 (response for TASK REASSIGN) > > > > [T.26] 9.6 Task Management Function Response > > > > For the functions ABORT TASK, ABORT TASK SET, CLEAR ACA, CLEAR TASK > > SET, LOGICAL UNIT RESET, TARGET COLD RESET and TARGET WARM RESET, the > > target performs the requested Task Management function and sends a > > Task Management Response back to the initiator. > > > > TASK REASSIGN does not get a response. Was this intended? > > It may be appropriate to include it in this list, but then it > would be nice to make sure that the > target sends the response to the TMF first before acting on > the reassigned task (which might > possibly involve retransmitting an old status sent before the > connection failure with a new StatSN). > Initiators may get confused if the response for the > reassigned task arrives prior to the the response > to the TMF itself (even while there are no StatSN holes). > > I suggest: > > For all the task management functions defined in 9.5.1, the > target performs the requested function and sends a > Task Management Response back to the initiator. In the case > of the TASK REASSIGN function, the target must > send the reponse to the task management function request > first before acting on the reassigned task. > > > Mallikarjun From owner-ips@ece.cmu.edu Wed Jul 10 11:14:35 2002 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA06364 for ; Wed, 10 Jul 2002 11:14:35 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id g6AEqO605712 for ips-outgoing; Wed, 10 Jul 2002 10:52:24 -0400 (EDT) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from d12lmsgate-2.de.ibm.com (d12lmsgate-2.de.ibm.com [195.212.91.200]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id g6AEqLX05707 for ; Wed, 10 Jul 2002 10:52:21 -0400 (EDT) Received: from d12relay01.de.ibm.com (d12relay01.de.ibm.com [9.165.215.22]) by d12lmsgate-2.de.ibm.com (8.12.3/8.12.3) with ESMTP id g6AEqBIS074728; Wed, 10 Jul 2002 16:52:11 +0200 Received: from d10hubm1.telaviv.ibm.com (d10ml001.telaviv.ibm.com [9.148.216.55]) by d12relay01.de.ibm.com (8.11.1m3/NCO/VER6.2) with ESMTP id g6AEqAg45436; Wed, 10 Jul 2002 16:52:10 +0200 To: Paul Koning Cc: ips@ece.cmu.edu MIME-Version: 1.0 Subject: Re: iSCSI - decimal coded binary strings - a proposed resolution X-Mailer: Lotus Notes Release 5.0.9 November 16, 2001 From: "Julian Satran" Message-ID: Date: Wed, 10 Jul 2002 17:52:00 +0300 X-MIMETrack: Serialize by Router on D10ML001/10/M/IBM(Release 5.0.9a |January 7, 2002) at 10/07/2002 17:52:10, Serialize complete at 10/07/2002 17:52:10 Content-Type: multipart/alternative; boundary="=_alternative 0050B904C2256BF2_=" Sender: owner-ips@ece.cmu.edu Precedence: bulk This is a multipart message in MIME format. --=_alternative 0050B904C2256BF2_= Content-Type: text/plain; charset="us-ascii" Comments in text. Julo Paul Koning 07/10/2002 04:09 PM Please respond to Paul Koning To: Julian Satran/Haifa/IBM@IBMIL cc: ips@ece.cmu.edu Subject: Re: iSCSI - decimal coded binary strings - a proposed resolution > Paul, > There seems to be something missing. > There is no decimal coding for numbers over 2**64. > And there no implied length for strings. > Where is the complexity? If I understood correctly, you were proposing: 1. For binary strings, decimal coding is allowed only if the particular string can never be longer than 64 bits. In other words, even in cases when some of the allowed values are less than 64 bits, you're not allowed to use decimal, ever. So the encoding rule is tied to the parameter, not to its value. +++ that was true even before - now we added the restriction that the length is not implicit (decimals have no implicit length) so your "know ahead of converting" is met anyhow. 2. On the other hand, for numbers, the proposed rule says that you can encode the value in decimal whenever the value happens to be less than 2**64. If 5 minutes later that same parameter happens to have a value 2**64 or greater, then you cannot encode that particular value in decimal. So the encoding rule here is tied to the value, not the parameter; a given parameter sometimes permits decimal and sometimes not. That's what I meant: it is extra complexity to have an encoding rule for a variable that isn't the same for all possible values of the variable. +++ that is only an issue for the encoder - and encoding is not an issue for any of the encoding methods - you send starting (supposedly) from an internal value of defined length and may use whatever is fit but we may tight the rule to allowed values not actual values. Is that acceptable? +++ paul --=_alternative 0050B904C2256BF2_= Content-Type: text/html; charset="us-ascii"
Comments in text. Julo


Paul Koning <ni1d@arrl.net>

07/10/2002 04:09 PM
Please respond to Paul Koning

       
        To:        Julian Satran/Haifa/IBM@IBMIL
        cc:        ips@ece.cmu.edu
        Subject:        Re: iSCSI - decimal coded binary strings - a proposed resolution

       



> Paul,
> There seems to be something missing.
> There is no decimal coding for numbers over 2**64.
> And there no implied length for strings.
> Where is the complexity?

If I understood correctly, you were proposing:

1. For binary strings, decimal coding is allowed only if the
particular string can never be longer than 64 bits.  In other words,
even in cases when some of the allowed values are less than 64 bits,
you're not allowed to use decimal, ever.  So the encoding rule is tied
to the parameter, not to its value.
+++ that was true even before - now we added the restriction that the length is not implicit (decimals have no implicit length) so your "know ahead  of converting" is met anyhow.

2. On the other hand, for numbers, the proposed rule says that you can
encode the value in decimal whenever the value happens to be less than
2**64.  If 5 minutes later that same parameter happens to have a
value 2**64 or greater, then you cannot encode that particular value
in decimal.  So the encoding rule here is tied to the value, not the
parameter; a given parameter sometimes permits decimal and sometimes
not.

That's what I meant: it is extra complexity to have an encoding rule
for a variable that isn't the same for all possible values of the
variable.

+++ that is only an issue for the encoder - and encoding is not an issue for any
of the encoding methods - you send starting (supposedly) from an internal value of defined
length and may use whatever is fit but we may tight the rule to allowed values not actual values.
Is that acceptable?
+++

                paul

--=_alternative 0050B904C2256BF2_=-- From owner-ips@ece.cmu.edu Wed Jul 10 13:50:55 2002 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA13005 for ; Wed, 10 Jul 2002 13:50:54 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id g6AH5RH15041 for ips-outgoing; Wed, 10 Jul 2002 13:05:27 -0400 (EDT) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from snjspop2.snjs.qwest.net (snjspop2.snjs.qwest.net [168.103.24.2]) by ece.cmu.edu (8.11.0/8.10.2) with SMTP id g6AH5PX15036 for ; Wed, 10 Jul 2002 13:05:25 -0400 (EDT) Received: (qmail 72555 invoked from network); 10 Jul 2002 17:05:31 -0000 Received: from 168-103-214-76.dslgw2.snva.qwest.net (HELO theglowmonster) (168.103.214.76) by snjspop2.snjs.qwest.net with SMTP; 10 Jul 2002 17:05:31 -0000 Date: Wed, 10 Jul 2002 10:02:58 -0700 Message-ID: From: "Randy Jennings" To: "Julian Satran (Hotmail)" , "Paul Koning" Cc: "ips" Subject: RE: iSCSI - decimal coded binary strings - a proposed resolution MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0) Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4910.0300 In-Reply-To: Sender: owner-ips@ece.cmu.edu Precedence: bulk Content-Transfer-Encoding: 7bit > > Julian> decimal-constant: an unsigned decimal number - the digit 0 or > > Julian> a string of 1 or more digits starting with a non-zero digit. > > Julian> Decimal-constants are used to encode numerical values or > > Julian> binary strings. Decimal constants can be used to encode > > Julian> binary strings only if the stringlength is explicitly > > Julian> speci-fied. There is no implicit length for decimal > > Julian> strings. This encoding MUST NOT used for numerical values > > Julian> equal or greater than 2**64 or binary strings that could be > > Julian> longer than 64 bits. Here is the problem: Do you mean (parentheses added): This encoding MUST NOT used for (numerical values equal or greater than 2**64) or (binary strings that could be longer than 64 bits). or: This encoding MUST NOT used for (numerical values equal or greater than 2**64 or binary strings) that could be longer than 64 bits. The first is admittedly the more logical choice, but it is not the only choice. I originally read it as the second and wondered what Paul's issue was. This is the editorial clarity issue that David Black is talking about. I remember having this issue with spec 11 when I was primarily learning the spec. However, as I care more about decoding the info instead of writing a protocol state machine, I did not make note of these problems. I apologize for not going over spec 12-(15?) closely. These issues may have been addressed by other editorial comments, but when adding text, it should be carefully scrutinized as well. With a 'for' in front of binary strings, the sentence can only be interpreted one way. From your following email is the wording intended. Sincerely, Randy Data Transit From owner-ips@ece.cmu.edu Wed Jul 10 15:08:19 2002 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA15892 for ; Wed, 10 Jul 2002 15:08:18 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id g6AIkh022415 for ips-outgoing; Wed, 10 Jul 2002 14:46:43 -0400 (EDT) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from atlrel9.hp.com (atlrel9.hp.com [156.153.255.214]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id g6AIkfX22409 for ; Wed, 10 Jul 2002 14:46:41 -0400 (EDT) Received: from core.rose.hp.com (core.rose.hp.com [15.43.208.100]) by atlrel9.hp.com (Postfix) with ESMTP id 5A243E00739; Wed, 10 Jul 2002 14:46:38 -0400 (EDT) Received: from swathi (swathi.rose.hp.com [15.43.213.237]) by core.rose.hp.com with SMTP (8.9.3 (PHNE_22672)/8.8.6 SMKit7.02) id LAA15007; Wed, 10 Jul 2002 11:48:30 -0700 (PDT) Message-ID: <004b01c22842$1f05edb0$edd52b0f@rose.hp.com> From: "Mallikarjun C." To: "Julian Satran" Cc: References: Subject: Re: iSCSI: DLB-T.26 (response for TASK REASSIGN) Date: Wed, 10 Jul 2002 11:46:36 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2600.0000 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 Sender: owner-ips@ece.cmu.edu Precedence: bulk Content-Transfer-Encoding: 7bit Julian, I don't want to make an issue of it, but IMHO, since the Task Reassign TMF causes two task instances in target to go active (the TMF itself, and the reassigned task), it's best to describe the order of status delivery in the TMF discussion itself - i.e. 9.6. It's easy to miss if described elsewhere. Thanks. -- Mallikarjun Mallikarjun Chadalapaka Networked Storage Architecture Network Storage Solutions Hewlett-Packard MS 5668 Roseville CA 95747 cbm@rose.hp.com ----- Original Message ----- From: "Julian Satran" To: "Mallikarjun C." Cc: ; Sent: Tuesday, July 09, 2002 9:12 PM Subject: Re: iSCSI: DLB-T.26 (response for TASK REASSIGN) > > Mallikarjun, > > Your suggested text fits better in 6.1 or 8.x. In 9 it clutters the text. > > Thanks, > Julo > > > > "Mallikarjun C." > To: > Sent by: cc: > owner-ips@ece.cmu Subject: iSCSI: DLB-T.26 (response for TASK REASSIGN) > .edu > > > 07/09/2002 10:20 > PM > Please respond to > "Mallikarjun C." > > > > > > > [T.26] 9.6 Task Management Function Response > > > > For the functions ABORT TASK, ABORT TASK SET, CLEAR ACA, CLEAR TASK > > SET, LOGICAL UNIT RESET, TARGET COLD RESET and TARGET WARM RESET, the > > target performs the requested Task Management function and sends a > > Task Management Response back to the initiator. > > > > TASK REASSIGN does not get a response. Was this intended? > > It may be appropriate to include it in this list, but then it would be nice > to make sure that the > target sends the response to the TMF first before acting on the reassigned > task (which might > possibly involve retransmitting an old status sent before the connection > failure with a new StatSN). > Initiators may get confused if the response for the reassigned task arrives > prior to the the response > to the TMF itself (even while there are no StatSN holes). > > I suggest: > > For all the task management functions defined in 9.5.1, the target performs > the requested function and sends a > Task Management Response back to the initiator. In the case of the TASK > REASSIGN function, the target must > send the reponse to the task management function request first before > acting on the reassigned task. > > > Mallikarjun > > > > > > From owner-ips@ece.cmu.edu Wed Jul 10 15:09:00 2002 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA15921 for ; Wed, 10 Jul 2002 15:09:00 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id g6AIfnF21969 for ips-outgoing; Wed, 10 Jul 2002 14:41:49 -0400 (EDT) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from palrel13.hp.com (palrel13.hp.com [156.153.255.238]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id g6AIfkX21963 for ; Wed, 10 Jul 2002 14:41:46 -0400 (EDT) Received: from core.rose.hp.com (core.rose.hp.com [15.43.208.100]) by palrel13.hp.com (Postfix) with ESMTP id D5959400203; Wed, 10 Jul 2002 11:41:43 -0700 (PDT) Received: from swathi (swathi.rose.hp.com [15.43.213.237]) by core.rose.hp.com with SMTP (8.9.3 (PHNE_22672)/8.8.6 SMKit7.02) id LAA14571; Wed, 10 Jul 2002 11:43:35 -0700 (PDT) Message-ID: <004301c22841$6f94c040$edd52b0f@rose.hp.com> From: "Mallikarjun C." To: , References: <277DD60FB639D511AC0400B0D068B71E05D42461@CORPMX14> Subject: Re: iSCSI: DLB-T.30 (using SNACK w/ PDU size changes) Date: Wed, 10 Jul 2002 11:41:42 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2600.0000 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 Sender: owner-ips@ece.cmu.edu Precedence: bulk Content-Transfer-Encoding: 7bit David, Sorry that I would not be attending the Yokohama meetings, so let me attempt to describe my thoughts here. >This appears to require receiving the status > PDU, processing it, and retroactively dropping it when discovering > that not all the data has arrived. That doesn't strike me as a > good design (e.g., it prohibits an acknowledge via ExpStatSN before > the ExpDataSN processing). Your description of the sequence of events is correct, but is not newly caused by my proposal. A SNACK-capable iSCSI layer must parse the status (including the ExpDataSN) before deciding to ack the status. You *cannot* issue a data SNACK for a task you had already ack'ed the status for! All my proposal is saying is: if there's a need to issue a data SNACK for this task, drop the status PDU as well if there was a MaxRecvDataSegmentLength change during the life of the task. [ Julian, I don't see the "SNACK only before status ack" idea stated in the draft. I'd suggest doing so in 9.16. ] > There's also at least one weird corner case in here - suppose > the initiator issues the Data SNACK and then changes > MaxRecvDataSegmentLength before all the data from the SNACK has > shown up. Now the initiator would have to retroactively drop a status > that it already acknowledged via ExpStatSN. This whole description again assumes that initiator can ack the status, and then issue a data SNACK at its convenience for the task. That is incorrect. Changing the MaxRecvDataSegmentLength during the Data-In PDU arrival can be handled identically always - whether the data burst is a result of a prior data SNACK, or is a "regular" burst in response to a read command. The first status PDU must always be dropped after a MaxRecvDataSegmentLength change, if ever a data SNACK is employed for the task. While I agree that last-minute changes could cause havoc, I remember discussing about this issue with Julian several months ago. This feature in general is described from rev09 onwards. (I know that it's not an excuse for getting it wrong, but let's hope to fix it during the Last Call.) To summarize, I still don't see the need for a new type of Data SNACK. Thanks. -- Mallikarjun Mallikarjun Chadalapaka Networked Storage Architecture Network Storage Solutions Hewlett-Packard MS 5668 Roseville CA 95747 cbm@rose.hp.com ----- Original Message ----- From: To: ; Sent: Wednesday, July 10, 2002 12:56 AM Subject: RE: iSCSI: DLB-T.30 (using SNACK w/ PDU size changes) > > You're right that there's a duplicate StatSN issue with the rev14 text. > > > > I believe that can be addressed by mandating that the initiators must > > discard the first status PDU always for the task in question, and then > issue > > a follow-on status SNACK. It may occasionally lead to discarding a good > > status (with the right ExpDataSN that reflects the re-segmented DataSN > > count), but that would anyway be recovered with the explicit follow-on > status > > SNACK. > > > > I don't believe we need to make BegRun=0 for these cases, nor do I believe > > that we need a new type of data SNACK. > > Mallikarjun, > > I don't think your proposal works very well. One problem is that > the initiator may not know how many data PDUs it should have received > (and hence know whether it's missing some and needs to issue a Data SNACK) > until it processes the status PDU (e.g., suppose the last Data-In PDU > doesn't show up). This appears to require receiving the status > PDU, processing it, and retroactively dropping it when discovering > that not all the data has arrived. That doesn't strike me as a > good design (e.g., it prohibits an acknowledge via ExpStatSN before > the ExpDataSN processing). > > There's also at least one weird corner case in here - suppose > the initiator issues the Data SNACK and then changes > MaxRecvDataSegmentLength before all the data from the SNACK has > shown up. Now the initiator would have to retroactively drop a status > that it already acknowledged via ExpStatSN. This is bad, and leads > to one of several poor outcomes: > > - Target fails to retransmit the response because the reused > StatSN is less than ExpStatSN. The initiator can't recover > because it can't issue a status SNACK for StatSN < ExpStatSN. > - Target ignores ExpStatSN and sends the response anyway. If > the response gets corrupted and has to be dropped, the > initiator again can't issue a status SNACK to recover. > - Initiator sends a new value of ExpStatSN to the target that is > less than the target's current ExpStatSN. That's a > serious protocol error. > > This is still an ugly corner case for a resegmenting Data SNACK > because the size change results in the original Data SNACK stopping > its transmission, and the initiator has to figure out that it needs > to send a resegmenting Data SNACK - not unreasonable, as the initiator > did change MaxRecvDataSegmentLength. The alternative of the > initiator not realizing the consequences of the size change and > hence having the extra response show up and complete the wrong > task courtesy of a reused Initiator Task Tag seems far worse. > > I'm also reminded of John Hufferd's warning that features inserted > late in a design tend to be the most error prone. This one (Data > SNACK in the face of MaxRecvDataSegmentLength change) seems to have > survived two attempts to fix it, so isolating it to its own separate > type of Data SNACK is making more and more sense, lest it survive > more attempts to fix it ... that way a failed fix won't > break ordinary Data SNACKs. The fact that there are potentially > subtle problems here was also behind my suggestion that the only > acceptable resegmenting Data SNACK should be "Send Everything" - > this should be a relatively rare case, and hence a brute force > simple robust design is in order, even if it's inefficient. > > Thanks, > --David > > > > -----Original Message----- > > From: Mallikarjun C. [mailto:cbm@rose.hp.com] > > Sent: Tuesday, July 09, 2002 6:49 PM > > To: ips@ece.cmu.edu > > Subject: iSCSI: DLB-T.30 (using SNACK w/ PDU size changes) > > > > > > David, > > > > You're right that there's a duplicate StatSN issue with the rev14 text. > > > > I believe that can be addressed by mandating that the initiators must > > discard the first status PDU always for the task in question, and then > issue > > a follow-on status SNACK. It may occasionally lead to discarding a good > > status (with the right ExpDataSN that reflects the re-segmented DataSN > > count), but that would anyway be recovered with the explicit follow-on > status > > SNACK. > > > > I don't believe we need to make BegRun=0 for these cases, nor do I believe > > that we need a new type of data SNACK. > > > > Mallikarjun > > > > > [T.30] 9.16 SNACK Request > > > > > > If the initiator MaxRecvDataSegmenTLength changed Data-In PDUs > > > requested with RunLength 0 (meaning all PDUs after this number) may > > > be different from the ones originally sent, in order to reflect > > > changes in MaxRecvDataSegmentLength. Their DataSN starts with the > > > requested number and is increased by 1 for each resent Data-In PDU. > > > If DataSN numbers change and a SCSI-Reponse PDU was sent reflecting > > > the DataSN before retransmission it MUST be resent to reflect the new > > > > numbers. > > > > > > This was discussed on the list, but there are still some problems here: > > > (1) If the MaxRecvDataSegmentLength has changed, the only valid Data > > > SNACK is BegRun=0, RunLength=0 (i.e., resend everything). Attempts > > > to be more clever than this are an invitation to miscount Data-In > > > PDUs and cause problems in the initiator. Targets MUST reject > > > all other Data SNACK requests in this situation. > > > (2) The new SCSI-Response PDU needs a new StatSN to avoid the initiator > > > discarding it as a duplicate. Section 2.2.2.2 is silent on duplicate > > > detection for StatSN, but discarding duplicates would be a reasonable > > > thing for an initiator to do. > > > (3) The initiator needs some way to know that a new response is coming, > > > and specifically whether to expect one or two responses. If it > > > only expects one and two show up, the initiator could reuse the > > > Task Tag once all the data arrives causing a race in which the > > > new response could incorrectly complete an unrelated command > > > (unlikely, but potentially nasty). > > > This suggests calling out the Data SNACK as > having > > > special behavior: > > > - It may resegment Data-In PDUs to deal with MaxRecvDataSegmentLength. > > > All other Data SNACK requests MUST NOT resegment. > > > - It *always* generates a new SCSI Response due to the possibility > > > of resegmentation. > > > That's not a great solution, because if one ever sets > > RunLength=0> in a Data SNACK, the resulting behavior change is dramatic > > > and unexpected. > > > This leads to the final proposal: > > > - Specify a new SNACK type code (3) for Resegmenting Data SNACK. SNACK > > > Data-In resegmentation is allowed only when this is used. If > > > resegmentation would be necessary for a Data SNACK (type 1), > > > that SNACK MUST be rejected. > > > - Both BegRun and RunLength MUST be zero for a Resegmenting Data > > > SNACK, and (unlike reserved fields) these MUST be checked by > > > the receiver (target). > > > - A new SCSI Response is always generated as a result of a Resegmenting > > > Data-In SNACK, and it has its own StatSN number to deal with the > > > fact that the number of Data-In PDUs may have changed, causing > > > a change to the ExpDataSN value. This new response also needs > > > to be marked to distinguish it from a response that may have > > > been generated earlier (so the initiator knows to wait for the > > > new response) - using a bit in the flags field for this seems > > > wrong, so specifying a new Response code value (0x02 - see 9.4.3) > > > seems like a reasonable way to accomplish this. > > > - Data SNACK (type 1) now has consistent behavior - it MUST NOT > resegment > > > and MUST NOT generate a new SCSI response, ever. > > > This approach also has the potentially useful property of making it easy > > > to yank out the Resegmenting Data SNACK wart if we ever put restrictions > > > on the interaction of MaxRecvDatasegmentLength and Data SNACKs (yes, > that's > > > a hint ... this has gotten messy enough that forbidding Data SNACKs when > > > MaxRecvDataSegmentLength has changed needs to be considered as a > possible > > > alternative). > > > > > > This issue also affects some text in 9.16.3. > > > > > > > From owner-ips@ece.cmu.edu Wed Jul 10 15:10:50 2002 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA16041 for ; Wed, 10 Jul 2002 15:10:49 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id g6AIN3t20649 for ips-outgoing; Wed, 10 Jul 2002 14:23:03 -0400 (EDT) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from sj-msg-core-4.cisco.com (sj-msg-core-4.cisco.com [171.71.163.10]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id g6AIMwX20642 for ; Wed, 10 Jul 2002 14:22:58 -0400 (EDT) Received: from nisser.cisco.com (nisser.cisco.com [171.71.176.85]) by sj-msg-core-4.cisco.com (8.12.2/8.12.2) with ESMTP id g6AIMppj010310; Wed, 10 Jul 2002 11:22:51 -0700 (PDT) Received: from cisco.com (mbakke@mbakke-lnx.cisco.com [161.44.68.87]) by nisser.cisco.com (8.8.6 (PHNE_14041)/CISCO.SERVER.1.2) with ESMTP id LAA02931; Wed, 10 Jul 2002 11:22:48 -0700 (PDT) Message-ID: <3D2C7F98.599E8F0F@cisco.com> Date: Wed, 10 Jul 2002 13:40:24 -0500 From: Mark Bakke X-Mailer: Mozilla 4.72 [en] (X11; U; Linux 2.2.16-3.uid32 i686) X-Accept-Language: en, de MIME-Version: 1.0 To: Jim Hafner CC: "KRUEGER,MARJORIE (HP-Roseville,ex1)" , Black_David@emc.com, ips@ece.cmu.edu Subject: Re: iSCSI: DLB's Comment on SCSI Port Names References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ips@ece.cmu.edu Precedence: bulk Content-Transfer-Encoding: 7bit This sounds fine to me as well. If we are talking about reducing the max iSCSI name to 249, why not make it an even 240, so we don't have to fuss with it if ISID turns into 8 bytes someday :-)? -- Mark Jim Hafner wrote: > > Marj, David, > > After this discussion, I don't have any problem with converting the entire SCSI port name to a > string. It's opaque as far as SCSI is concerned in any case, so it really doesn't matter. > > As for restricting the length of iSCSI Names so iSCS's SCSI port names fit 256 limit (including > null), I have no opinion. > Oh, and Marj: did you get the math right if the ISID is 6 bytes (so 12 hex characters)? > > Whatever change we make here needs to propogate to Annex A of SAM2 where information about these > names are specified (for informational purposes only). > > As in that Blind Faith song: "do what you like"... > > Jim Hafner > > To: Jim Hafner/Almaden/IBM@IBMUS, Black_David@emc.com > cc: ips@ece.cmu.edu > Subject: RE: iSCSI: DLB's Comment on SCSI Port Names > > I've just encountered this issue with regards to iSCSI port name encoding in the SCSI MIB, and > the currently specified port name encoding causes inconvenience (at best). IMO, it makes sense > to be able to treat an iSCSI name field, be it device name or port name, the same - as a string > of display characters, portions of which may contain ASCII-encoded numeric values. > > I don't really see that it makes a difference whether one views ISID and TPGT as numeric strings > or values, since as Jim says, there are no calculations performed using these things, and they > are basicly just "tags". The issue for me is that the rest of the "SCSI port name" is a string > and I see no value in "encoding" the ISID or TPGT as a value for SCSI purposes, as SCSI should > have no need to use the ISID or TPGT values separately from the entire port name. And even if > SCSI had such a need, it's a simple matter to convert a numeric string representation to a > value. > > The downside of a string-encoding is the increased maximum size of the SCSI port name. > > If strings over 256 characters are a problem for some platforms, I'd be in favor of reducing the > max iSCSI node name to 249 characters so the maximum SCSI port name would be 255 characters total > (249 char name + ",i," + "0x0000") > > Marjorie Krueger > Networked Storage Architecture > Networked Storage Solutions Org. > Hewlett-Packard > > -----Original Message----- > From: Jim Hafner [mailto:hafner@almaden.ibm.com] > Sent: Monday, July 08, 2002 9:08 AM > To: Black_David@emc.com > Cc: ips@ece.cmu.edu > Subject: RE: iSCSI: DLB's Comment on SCSI Port Names > > David, > > I believe it will (may?) be used, so I agree we're in the second case. However, this format is > the intended use in SCSI protocol stuff. Two places where SCSI ports names are used now is in > ALIAS, Access Controls and in third party reservations -- see caveat below, however) > > I don't see a need in this context to define these as strings (that's not a SCSI way of > thinking...). > > However, I think the issue comes down to a simple question: are the ISID and TPGT values or > numerical strings (Julian is calling them numerical strings, but I've always thought of them as > values, in spite of the fact that there is no arithmetic done on them - there is precedent in > SCSI for such thinking, so I'm not completely out in the woods here). > > If they are values, then I'd like to see them formatted for SCSI in "value form"; if they are > strings, then any representation should be OK. > > Does that at least get to the core of the issue? > > Jim Hafner > > CAVEAT: I don't think we'd use the iSCSI constructed port names in those contexts as device names > are better suited for those purposes, but these are examples where specification of SCSI port > name format is required. > > To: Jim Hafner/Almaden/IBM@IBMUS > cc: ips@ece.cmu.edu > Subject: RE: iSCSI: DLB's Comment on SCSI Port Names > > Jim, > > My view of this is that either: > - The SCSI Port Name is never going to be used, in which case > it shouldn't be designed to this level of detail. OR > - It's going to be used, and hence is worth designing in a fashion > that is reasonable to use. > I think we're in the second category, and turning the ISID into > hex ASCII (well, UTF-8) so the SCSI port name is a string is > worth doing now to avoid problems when people actually try > to use it. I would have no problems if someone wanted to > pad the string, but I'd make specifying the padding the > responsibility of the protocol/API/situation in which it > was used rather than incorporating the padding into the name. > > Thanks, > --David > > -----Original Message----- > From: Jim Hafner [mailto:hafner@almaden.ibm.com] > Sent: Monday, July 08, 2002 11:42 AM > To: Black_David@emc.com > Cc: ips@ece.cmu.edu > Subject: Re: iSCSI: DLB's Comment on SCSI Port Names > > David, > > You wrote: > > >[T.9] 2.4.2 SCSI Architecture Model > > > > The SCSI Port Name is mandatory in iSCSI. When used in SCSI > > parameter data, the SCSI port name MUST be encoded as: > > - The iSCSI Name in UTF-8 format, followed by > > - a comma separator (1 byte), followed by > > - the ASCII character 'i' (for SCSI Initiator Port) or the > > ASCII character 't' (for SCSI Target Port), followed by > > - a comma separator (1 byte), followed by > > - zero to 3 null pad bytes so that the complete format is a > > multiple of four bytes long, followed by > > - the 6byte value of the ISID (for SCSI initiator port) or the > > 2byte value of the portal group tag (for SCSI target port) in > > network byte order (BigEndian). > > > That's a peculiar format with padding nulls in the middle and > > a number concatenated after the padding - for example, it can't > > be passed in iSCSI login without format conversion. How about > > converting the number to 4 or 12 bytes of hex (ASCII characters) > > and moving the padding to the end so the result is actually a > > string, and excluding the padding from the definition of the name? > > This will increase the maximum length of port names, but produce > > names that are easier to deal with. > > Admittedly that's an odd format, however here was the reason for this > layout. > 1) it's not used directly in iSCSI "Text" strings; it's intended to be a > description of how this information is packed into a byte array for > representation in "SCSI parameter data" (as it says!) -- that is, it's NEVER > "passed in iSCSI login" (in this form). > 2) the padding after the string was to force the binary values of the ISID > or PGT to be better word aligned and can be more easily extracted as a value > direct from the byte array without conversion. > > What do you think? > > Jim Hafner -- Mark A. Bakke Cisco Systems mbakke@cisco.com 763.398.1054 From owner-ips@ece.cmu.edu Wed Jul 10 15:47:41 2002 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA17108 for ; Wed, 10 Jul 2002 15:47:41 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id g6AJ1Pb23646 for ips-outgoing; Wed, 10 Jul 2002 15:01:25 -0400 (EDT) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from palrel10.hp.com (palrel10.hp.com [156.153.255.245]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id g6AJ1MX23635 for ; Wed, 10 Jul 2002 15:01:22 -0400 (EDT) Received: from core.rose.hp.com (core.rose.hp.com [15.43.208.100]) by palrel10.hp.com (Postfix) with ESMTP id C5894C00B50; Wed, 10 Jul 2002 12:01:21 -0700 (PDT) Received: from swathi (swathi.rose.hp.com [15.43.213.237]) by core.rose.hp.com with SMTP (8.9.3 (PHNE_22672)/8.8.6 SMKit7.02) id MAA16530; Wed, 10 Jul 2002 12:03:13 -0700 (PDT) Message-ID: <005d01c22844$2db3cb00$edd52b0f@rose.hp.com> From: "Mallikarjun C." To: , References: <277DD60FB639D511AC0400B0D068B71E05D4245F@CORPMX14> Subject: Re: iSCSI: DLB-T.28 (Logout discards OOO commands) Date: Wed, 10 Jul 2002 12:01:20 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2600.0000 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 Sender: owner-ips@ece.cmu.edu Precedence: bulk Content-Transfer-Encoding: 7bit David, You're right, "command reordering queue" needs to be defined. I'd prefer doing that, or alternatively going with your suggested text below, but S/b " a command with a smaller CmdSN has" W/ "one or more commands with smaller CmdSN(s) have". And yes, in the quoted text at the bottom, "commands" would be a better fit compared to "tasks". Thanks. -- Mallikarjun Mallikarjun Chadalapaka Networked Storage Architecture Network Storage Solutions Hewlett-Packard MS 5668 Roseville CA 95747 cbm@rose.hp.com ----- Original Message ----- From: To: ; Sent: Wednesday, July 10, 2002 12:56 AM Subject: RE: iSCSI: DLB-T.28 (Logout discards OOO commands) > Mallikarjun, > > The "active" suggestion helps, but the text in Section > 9.14 uses the phrase "command reordering > queue" without defining it, and uses the word > "tasks" where "commands" would have been better. > > The language used in 9.14 needs to be aligned with the language > used to specify command ordering in Section 2.2.2.1. One > (somewhat wordy) possibility for rephrasing would be: > > results in the discarding of commands that have arrived > on the connection being logged out but have not been > delivered to SCSI because a command with a smaller CmdSN > has not been received by iSCSI (see Section 2.2.2.1). > > 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 > --------------------------------------------------- > > > > -----Original Message----- > > From: Mallikarjun C. [mailto:cbm@rose.hp.com] > > Sent: Tuesday, July 09, 2002 3:43 PM > > To: ips@ece.cmu.edu > > Subject: iSCSI: DLB-T.28 (Logout discards OOO commands) > > > > > > > [T.28] 9.14 Logout Request > > > > > > A successful completion of a logout request with the reason code of > > > "close the connection" or "remove the connection for recovery" > > > results in the discarding of all tasks waiting in the command reor- > > > dering queue that are allegiant to the connection being logged out. > > > > > > "discarding" is not what hapapens in the "remove the connection for > recovery > > > case according to the following text from Section 6.5: > > > > > > b) Logout the connection for recovery and continue the tasks on a > > > > different connection instance as described in Section 6.1 Retry > > > and Reassign in Recovery. [OR] > > > > > > A "discarded" task cannot be "continue"-d. I suspect the text should > say > > > that "close the connection" terminates the tasks, anad "remove the > > > connection > > > for recovery" suspends the tasks with the following CmdSN > > side effects ... > > > > Notice the phrase "waiting in the command reordering queue". *Any* > > flavor of Logout would cause the OOO commands in the target's reordering > > queue to be discarded. The difference in behaviors is only > > for the active tasks. > > > > The recovery Logout, when successfully executed, would prepare the *active > > > instantiated tasks* for reassignment, while the other two flavors > > of Logout would terminate all appropriate tasks. > > > > I would suggest qualifying the words task/tasks with "active" > > in section 6.5 (in the > > text you quoted), and also in sections 9.5/9.6 to make this > > distinction clear. > > > > > > Mallikarjun > > > > > From owner-ips@ece.cmu.edu Wed Jul 10 15:49:45 2002 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA17138 for ; Wed, 10 Jul 2002 15:49:45 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id g6AJ8tW24441 for ips-outgoing; Wed, 10 Jul 2002 15:08:55 -0400 (EDT) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from lion.ninthwonder.com (lion.ninthwonder.com [151.199.66.147]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id g6AJ8sX24436 for ; Wed, 10 Jul 2002 15:08:54 -0400 (EDT) Received: by lion.ninthwonder.com (Postfix, from userid 1021) id 0113D30706; Wed, 10 Jul 2002 15:08:52 -0400 (EDT) Date: Wed, 10 Jul 2002 12:05:55 -0700 (PDT) From: Bill Studenmund X-X-Sender: To: Julian Satran Cc: Paul Koning , Subject: Re: iSCSI - decimal coded binary strings - a proposed resolution In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ips@ece.cmu.edu Precedence: bulk On Wed, 10 Jul 2002, Julian Satran wrote: > 2. On the other hand, for numbers, the proposed rule says that you can > encode the value in decimal whenever the value happens to be less than > 2**64. If 5 minutes later that same parameter happens to have a > value 2**64 or greater, then you cannot encode that particular value > in decimal. So the encoding rule here is tied to the value, not the > parameter; a given parameter sometimes permits decimal and sometimes > not. > > That's what I meant: it is extra complexity to have an encoding rule > for a variable that isn't the same for all possible values of the > variable. > > +++ that is only an issue for the encoder - and encoding is not an issue > for any > of the encoding methods - you send starting (supposedly) from an internal > value of defined > length and may use whatever is fit but we may tight the rule to allowed > values not actual values. > Is that acceptable? > +++ Let's tie the rule to the allowed values. That would clear up a chunk of the mess. Take care, Bill From owner-ips@ece.cmu.edu Wed Jul 10 15:50:04 2002 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA17159 for ; Wed, 10 Jul 2002 15:49:58 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id g6AJLS725397 for ips-outgoing; Wed, 10 Jul 2002 15:21:28 -0400 (EDT) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from atlrel7.hp.com (atlrel7.hp.com [156.153.255.213]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id g6AJLQX25392 for ; Wed, 10 Jul 2002 15:21:26 -0400 (EDT) Received: from core.rose.hp.com (core.rose.hp.com [15.43.208.100]) by atlrel7.hp.com (Postfix) with ESMTP id 5161F8050F3; Wed, 10 Jul 2002 15:21:25 -0400 (EDT) Received: from swathi (swathi.rose.hp.com [15.43.213.237]) by core.rose.hp.com with SMTP (8.9.3 (PHNE_22672)/8.8.6 SMKit7.02) id MAA18257; Wed, 10 Jul 2002 12:23:17 -0700 (PDT) Message-ID: <006301c22846$fad5e9e0$edd52b0f@rose.hp.com> From: "Mallikarjun C." To: , References: <277DD60FB639D511AC0400B0D068B71E05D4245D@CORPMX14> Subject: Re: iSCSI: DLB-T.16 (resource requirement for connection reinstatement) Date: Wed, 10 Jul 2002 12:21:23 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2600.0000 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 Sender: owner-ips@ece.cmu.edu Precedence: bulk Content-Transfer-Encoding: 7bit David, "Connection reinstatement" is related to ErrorRecoveryLevel only in one case (described below). Even when no tasks were active (so no within-command/within-connection/connection recovery), connection reinstatement still is meaningful - simply the process of substituting one iSCSI connection with a new one bearing the same CID. To summarize level of requirement for connection reinstatement wrt ErrorRecoveryLevel - ErrorRecoveryLevel target's level of requirement 0 SHOULD 1 SHOULD 2 (multi-conn sessions supported) SHOULD 2 (only single-conn sessions) MUST [ The reason for the MUST in the last row is: While the target isn't aware of a connection failure, the initiator may have seen the connection fail and would like to reassign tasks to a new instance of the same CID (i.e. connection reinstatement) - target had already promised to support reassignment and so MUST allow this as a pre-requisite to reassignment. ] My suggestion was to require SHOULD in the first 3 rows. Thanks. -- Mallikarjun Mallikarjun Chadalapaka Networked Storage Architecture Network Storage Solutions Hewlett-Packard MS 5668 Roseville CA 95747 cbm@rose.hp.com ----- Original Message ----- From: To: ; Sent: Wednesday, July 10, 2002 12:56 AM Subject: RE: iSCSI: DLB-T.16 (resource requirement for connection reinstatement) > Mallikarjun, > > I think this ought to be related to ErrorRecoveryLevel - it looks like > you're suggesting that connection reinstatement SHOULD be supported > at ErrorRecoveryLevel 0 - at 1 and above, I believe it's already a > MUST. I don't have a problem with that, does anyone else? > > Thanks, > --David > > > -----Original Message----- > > From: Mallikarjun C. [mailto:cbm@rose.hp.com] > > Sent: Tuesday, July 09, 2002 2:52 PM > > To: ips@ece.cmu.edu > > Subject: iSCSI: DLB-T.16 (resource requirement for connection > > reinstatement) > > > > > > > [T.16] 4.3.4 Connection reinstatement > > > > > > Targets should support opening a second connection even > > > when they do not support multiple connections in Full Feature Phase. > > > > > > Looks like that ought to be an upper case "SHOULD". I think this needs > > > further discussion. Section 5.2 appears to use a lower case "must" > > > for this: > > > > Let's be careful here - section 5.2 discusses the generic case of > "connection > > cleanup" - that includes both implicit and explicit logouts - whereas > "connection > > reinstatement" is just implicit logout. > > > > While "connection cleanup" does not require additional connection > resources > > in the general case, a target wanting to support connection reinstatement > SHOULD > > support *opening* a second connection (though it may reject the Login if > it's > > for a different CID). > > > > I believe that connection reinstatement is a useful functionality that the > targets > > SHOULD support, so I agree that the change suggested by David is a > reasonable > > one to make in 4.3.4 which only discusses connection reinstatement. > > > > Mallikarjun > > > From owner-ips@ece.cmu.edu Wed Jul 10 20:24:09 2002 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA24397 for ; Wed, 10 Jul 2002 20:24:09 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id g6ANckX11758 for ips-outgoing; Wed, 10 Jul 2002 19:38:46 -0400 (EDT) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from palrel10.hp.com (palrel10.hp.com [156.153.255.245]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id g6ANciX11754 for ; Wed, 10 Jul 2002 19:38:44 -0400 (EDT) Received: from core.rose.hp.com (core.rose.hp.com [15.43.208.100]) by palrel10.hp.com (Postfix) with ESMTP id D4F88C00427; Wed, 10 Jul 2002 16:38:43 -0700 (PDT) Received: from swathi (swathi.rose.hp.com [15.43.213.237]) by core.rose.hp.com with SMTP (8.9.3 (PHNE_22672)/8.8.6 SMKit7.02) id QAA24811; Wed, 10 Jul 2002 16:40:33 -0700 (PDT) Message-ID: <00d901c2286a$ec796ba0$edd52b0f@rose.hp.com> From: "Mallikarjun C." To: "Julian Satran (Actcom)" , , Cc: , References: <1BEBA5E8600DD4119A50009027AF54A00CE07248@axcs04.cos.agilent.com> <00c401c223d9$9e1002c0$0100000a@JA31> Subject: Re: iSCSI: draft vs. 14 typos, suggestion, questions Date: Wed, 10 Jul 2002 16:38:39 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 8bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2600.0000 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 Sender: owner-ips@ece.cmu.edu Precedence: bulk Content-Transfer-Encoding: 8bit Sorry, I'm catching up late on email.... I see that the latest wording on this is - When the session timeout (the connection state timeout for the last failed connection) happens on the target, it takes the following actions: - Resets or closes the TCP connections (closes the session). - Aborts all Tasks in the task set associated with the session. I think the second bullet is incorrect. While the previous wording had the issue that Pat identified (that there may be one task set for each LU the session can get to), the new wording still has that issue and in addition, also implies that all tasks in the task set need to be terminated. However, a LU may maintain only one task set for multiple initiators (if TST=0 in control mode page) in which case, the current wording implies that all tasks from other initiators need to be terminated as well on one session timeout - which is not intended. I am beginning to think that the notion of "task set" is beyond iSCSI and it's best not to refer to it here. I suggest the following text instead - When the session timeout (section 4.3.5) happens on the target, it takes the following actions: - Resets or closes the TCP connections (closes the session). - Terminates all active tasks that were allegiant to the connection(s) that constituted the session. Thanks. -- Mallikarjun Mallikarjun Chadalapaka Networked Storage Architecture Network Storage Solutions Hewlett-Packard MS 5668 Roseville CA 95747 cbm@rose.hp.com ----- Original Message ----- From: "Julian Satran (Actcom)" To: ; Cc: ; Sent: Thursday, July 04, 2002 9:08 PM Subject: Re: iSCSI: draft vs. 14 typos, suggestion, questions > I will do the text change (I hope it makes it easier for at least one reader > is not worse for anybody else). > The reason why we choose the wording was that SAM associates the task set > with an initiator by the session is wording is equivalent. > > Julo > ----- Original Message ----- > From: > To: ; > Cc: ; > Sent: Wednesday, July 03, 2002 9:38 PM > Subject: RE: iSCSI: draft vs. 14 typos, suggestion, questions > > > > See comment below. Pat > > -----Original Message----- > > From: Julian Satran [mailto:Julian_Satran@il.ibm.com] > > Sent: Wednesday, July 03, 2002 9:20 AM > > To: Tomá? Bartu?ek > > Cc: ips@ece.cmu.edu; ivan.pavelka@s3group.com > > Subject: Re: iSCSI: draft vs. 14 typos, suggestion, questions > > > > > > > > *** Section 6.11 : QUESTION > > Draft says: > > When the session timeout (the connection state timeout for the last > > failed connection) happens on the target, it takes the following > > actions: > > > > - Resets or closes the TCP connections (closes the session). > > - Aborts all Tasks in the task set for the corresponding initi- > > ator. > > > > What does the "corresponding initiator" mean? We think (:-)), that > > there is only one initiator for the session. The only possible > > explanation we see for that paragraph is, that the target should > > abort also other tasks of the same in __other__ sessions, but > > why? > > +++ your interpretation is correct - the statement means the initiator > that "owned" the session. > > Are you suggesting other wording? > > ++++ > > "Aborts all task sets associated with the session" > > (Task set was changed to plural because task set is defined as an I-T-L > nexus and there may be muliple ones in the session. > > > > From owner-ips@ece.cmu.edu Wed Jul 10 20:24:42 2002 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA24414 for ; Wed, 10 Jul 2002 20:24:42 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id g6B00BD12844 for ips-outgoing; Wed, 10 Jul 2002 20:00:11 -0400 (EDT) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from palrel13.hp.com (palrel13.hp.com [156.153.255.238]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id g6B009X12840 for ; Wed, 10 Jul 2002 20:00:09 -0400 (EDT) Received: from core.rose.hp.com (core.rose.hp.com [15.43.208.100]) by palrel13.hp.com (Postfix) with ESMTP id DC3EC400174; Wed, 10 Jul 2002 17:00:08 -0700 (PDT) Received: from swathi (swathi.rose.hp.com [15.43.213.237]) by core.rose.hp.com with SMTP (8.9.3 (PHNE_22672)/8.8.6 SMKit7.02) id RAA28466; Wed, 10 Jul 2002 17:02:00 -0700 (PDT) Message-ID: <00e401c2286d$eab59430$edd52b0f@rose.hp.com> From: "Mallikarjun C." To: "Julian Satran" Cc: Subject: iSCSI: task set notes Date: Wed, 10 Jul 2002 17:00:07 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2600.0000 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 Sender: owner-ips@ece.cmu.edu Precedence: bulk Content-Transfer-Encoding: 7bit Julian, A couple of other notes on the usage of "task set". Please consider. - In section 2.5.1.3, "The I_T_L nexus identifies task sets and is carried by the LUN (and implied by the session identification)." Since an I_T_L nexus identifies only one task set, I suggest the following - "The affected task set is identified by the I_T_L nexus, which in turn is identified by the LUN and by the session identification." - In section 9.5.1, "4 - CLEAR TASK SET - aborts all Tasks for the Logical Unit." should be: "4 - CLEAR TASK SET - aborts all Tasks in the appropriate task set as defined by the TST field in the Control mode page ([SPC3])." Thanks. Mallikarjun From owner-ips@ece.cmu.edu Wed Jul 10 21:10:27 2002 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA25371 for ; Wed, 10 Jul 2002 21:10:22 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id g6B0DfY13514 for ips-outgoing; Wed, 10 Jul 2002 20:13:41 -0400 (EDT) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from palrel12.hp.com (palrel12.hp.com [156.153.255.237]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id g6B0DdX13509 for ; Wed, 10 Jul 2002 20:13:39 -0400 (EDT) Received: from xparelay2.corp.hp.com (xparelay2.corp.hp.com [15.58.137.112]) by palrel12.hp.com (Postfix) with ESMTP id 54C2BE0065A; Wed, 10 Jul 2002 17:13:35 -0700 (PDT) Received: from xpabh4.corp.hp.com (xpabh4.corp.hp.com [15.58.136.1]) by xparelay2.corp.hp.com (Postfix) with ESMTP id 2122E16A; Wed, 10 Jul 2002 17:13:35 -0700 (PDT) Received: by xpabh4.corp.hp.com with Internet Mail Service (5.5.2655.55) id <32DCH4RZ>; Wed, 10 Jul 2002 17:13:34 -0700 Message-ID: <6BD67FFB937FD411A04F00D0B74FE87805CCF6C2@xrose06.rose.hp.com> From: "KRUEGER,MARJORIE (HP-Roseville,ex1)" To: "'Black_David@emc.com'" , reames@diskdrive.com, ips@ece.cmu.edu Subject: RE: iSCSI: DLB [T.31] ErrorRecoveryLevel 0.5 Date: Wed, 10 Jul 2002 17:13:33 -0700 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2655.55) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-ips@ece.cmu.edu Precedence: bulk David, I don't understand what you are aquiescing to? It seems to me that what Steve is proposing is a violation of the protocol - there is no way to negotiate "level 0 + SNACK", therefore as Mallikarjun pointed out, it wouldn't work. If you've negotiated error level 0, the remote end of this session won't support SNACK (or shouldn't). This sort of interpretation would create an interoperability (not to mention testing) nightmare - that's why the error recover levels were defined in the first place. I think your original comment is valid. Marjorie Krueger Networked Storage Architecture Networked Storage Solutions Org. Hewlett-Packard > -----Original Message----- > From: Black_David@emc.com [mailto:Black_David@emc.com] > Sent: Wednesday, July 10, 2002 12:57 AM > To: reames@diskdrive.com; ips@ece.cmu.edu > Subject: RE: iSCSI: DLB [T.31] > > > Steve, > >> From DLB's comments: >> >>>[T.31] 9.16.1 Type >>> >>> An iSCSI target that does not support recovery within connection MAY >>> reject the status SNACK with a Reject PDU. If the target supports >>> recovery within connection, it MAY reject the SNACK after which it >>> MUST issue an Asynchronous Message PDU with an iSCSI event that indi- >>> cates "Request Logout". >>> >>> This should be conditioned on the operational ErrorRecoveryLevel of the >>> session, not whether the target supports recovery within connection. >> >> I would prefer that this not be conditioned on the ErrorRecoveryLevel. If >> I am writing code, I may choose to support recovery-within-connection, but >> not all the features that would be required to move me up to >> ErrorRecoveryLevel 1. I would like SNACK and Reject PDUs to work properly >> for my code, even though it is technically only "ErrorRecoveryLevel 0.5". >> As I read it, changing the wording would allow the target to ignore >> my improved error recovery efforts unless I have a full ErrorRecoveryLevel 1 >> implementation. David, I doubt that is what you intended, so maybe you >> want to word it a little differently. > > Actually, it was what I intended when I made that comment, > BUT, I had not considered the scenario you describe above ... > and so, I now agree with > you. Therefore I'll withdraw my [T.31] comment provided that the > possibility of multiple "ErrorRecoveryLevel 0.5" levels of support is > described in the overview section to be added on error recovery. > > 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 > --------------------------------------------------- > From owner-ips@ece.cmu.edu Wed Jul 10 21:10:35 2002 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA25373 for ; Wed, 10 Jul 2002 21:10:22 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id g6B0OXt14067 for ips-outgoing; Wed, 10 Jul 2002 20:24:33 -0400 (EDT) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from d12lmsgate-3.de.ibm.com (d12lmsgate-3.de.ibm.com [195.212.91.201]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id g6B0OVX14063 for ; Wed, 10 Jul 2002 20:24:31 -0400 (EDT) Received: from d12relay01.de.ibm.com (d12relay01.de.ibm.com [9.165.215.22]) by d12lmsgate-3.de.ibm.com (8.12.3/8.12.3) with ESMTP id g6B0OE2F037038; Thu, 11 Jul 2002 02:24:15 +0200 Received: from d10hubm1.telaviv.ibm.com (d10ml001.telaviv.ibm.com [9.148.216.55]) by d12relay01.de.ibm.com (8.11.1m3/NCO/VER6.2) with ESMTP id g6B0OEg94318; Thu, 11 Jul 2002 02:24:14 +0200 To: Black_David@emc.com Cc: ips@ece.cmu.edu, owner-ips@ece.cmu.edu, reames@diskdrive.com MIME-Version: 1.0 Subject: RE: iSCSI: DLB [T.31] X-Mailer: Lotus Notes Release 5.0.9 November 16, 2001 From: "Julian Satran" Message-ID: Date: Thu, 11 Jul 2002 03:24:09 +0300 X-MIMETrack: Serialize by Router on D10ML001/10/M/IBM(Release 5.0.9a |January 7, 2002) at 11/07/2002 03:24:14, Serialize complete at 11/07/2002 03:24:14 Content-Type: multipart/alternative; boundary="=_alternative 0000DE7AC2256BF3_=" Sender: owner-ips@ece.cmu.edu Precedence: bulk This is a multipart message in MIME format. --=_alternative 0000DE7AC2256BF3_= Content-Type: text/plain; charset="us-ascii" The wording was changed to reflect operationallevel (not implemented level) 3 days ago! Julo Black_David@emc.com Sent by: owner-ips@ece.cmu.edu 07/10/2002 10:56 AM Please respond to Black_David To: reames@diskdrive.com, ips@ece.cmu.edu cc: Subject: RE: iSCSI: DLB [T.31] Steve, > From DLB's comments: > > >[T.31] 9.16.1 Type > > > > An iSCSI target that does not support recovery within connection MAY > > reject the status SNACK with a Reject PDU. If the target supports > > recovery within connection, it MAY reject the SNACK after which it > > MUST issue an Asynchronous Message PDU with an iSCSI event that indi- > > cates "Request Logout". > > > > This should be conditioned on the operational ErrorRecoveryLevel of the > > session, not whether the target supports recovery within connection. > > I would prefer that this not be conditioned on the ErrorRecoveryLevel. If I > am writing code, I may choose to support recovery-within-connection, but > not all the features that would be required to move me up to > ErrorRecoveryLevel 1. I would like SNACK and Reject PDUs to work properly > for my code, even though it is technically only "ErrorRecoveryLevel 0.5". > As I read it, changing the wording would allow the target to ignore my > improved error recovery efforts unless I have a full ErrorRecoveryLevel 1 > implementation. David, I doubt that is what you intended, so maybe you want > to word it a little differently. Actually, it was what I intended when I made that comment, BUT, I had not considered the scenario you describe above ... and so, I now agree with you. Therefore I'll withdraw my [T.31] comment provided that the possibility of multiple "ErrorRecoveryLevel 0.5" levels of support is described in the overview section to be added on error recovery. 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 --------------------------------------------------- --=_alternative 0000DE7AC2256BF3_= Content-Type: text/html; charset="us-ascii"
The wording was changed to reflect operationallevel (not implemented level) 3 days ago!

Julo


Black_David@emc.com
Sent by: owner-ips@ece.cmu.edu

07/10/2002 10:56 AM
Please respond to Black_David

       
        To:        reames@diskdrive.com, ips@ece.cmu.edu
        cc:        
        Subject:        RE: iSCSI: DLB [T.31]

       


Steve,

>  From DLB's comments:
>
>  >[T.31] 9.16.1  Type
>  >
>  >   An iSCSI target that does not support recovery within connection MAY
>  >   reject the status SNACK with a Reject PDU. If the target supports
>  >   recovery within connection, it MAY reject the SNACK after which it
>  >   MUST issue an Asynchronous Message PDU with an iSCSI event that indi-
>  >   cates "Request Logout".
>  >
>  > This should be conditioned on the operational ErrorRecoveryLevel of the
>  > session, not whether the target supports recovery within connection.
>
> I would prefer that this not be conditioned on the ErrorRecoveryLevel. If
I
> am writing code, I may choose to support recovery-within-connection, but
> not all the features that would be required to move me up to
> ErrorRecoveryLevel 1. I would like SNACK and Reject PDUs to work properly
> for my code, even though it is technically only "ErrorRecoveryLevel 0.5".
>                  As I read it, changing the wording would allow the target to ignore
my
> improved error recovery efforts unless I have a full ErrorRecoveryLevel 1
> implementation. David, I doubt that is what you intended, so maybe you
want
> to word it a little differently.

Actually, it was what I intended when I made that comment, BUT, I had not
considered the scenario you describe above ... and so, I now agree with
you.  Therefore I'll withdraw my [T.31] comment provided that the
possibility of multiple "ErrorRecoveryLevel 0.5" levels of support is
described in the overview section to be added on error recovery.

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

--=_alternative 0000DE7AC2256BF3_=-- From owner-ips@ece.cmu.edu Wed Jul 10 21:13:32 2002 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA25430 for ; Wed, 10 Jul 2002 21:13:32 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id g6B0upD15620 for ips-outgoing; Wed, 10 Jul 2002 20:56:51 -0400 (EDT) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from mail.brocade.com (sj6-b.brocade.com [63.121.140.220]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id g6B0unX15615 for ; Wed, 10 Jul 2002 20:56:50 -0400 (EDT) Received: from hq-ex-c2.brocade.com (hq-ex-c2 [192.168.126.35]) by mail.brocade.com (8.8.8+Sun/8.8.8) with ESMTP id RAA28389; Wed, 10 Jul 2002 17:56:37 -0700 (PDT) Received: by hq-ex-c2.brocade.com with Internet Mail Service (5.5.2653.19) id ; Wed, 10 Jul 2002 17:56:37 -0700 Message-ID: <2F37CED150E21640A9C6E75B8BE6AF830A4DB5@hq-ex-4> From: Robert Snively To: "'Julian Satran (Actcom)'" Cc: ips@ece.cmu.edu Subject: RE: iSCSI: Decimal encoding - why 64 bits ? Date: Wed, 10 Jul 2002 17:56:59 -0700 X-Mailer: Internet Mail Service (5.5.2653.19) Sender: owner-ips@ece.cmu.edu Precedence: bulk The thing that keeps me wondering is: given a nice well-behaved binary number, represented in hex as FF FF FF FF, it sure is a pain to represent it as: 4 294 967 295 This simply does not make sense to me. Anything over 8 bits is suspect as a decimal encoded binary number, and frankly I don't like such numbers over 3 bits. Bob From owner-ips@ece.cmu.edu Wed Jul 10 22:59:43 2002 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA28558 for ; Wed, 10 Jul 2002 22:59:43 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id g6B2Jmn19738 for ips-outgoing; Wed, 10 Jul 2002 22:19:48 -0400 (EDT) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from atlrel7.hp.com (atlrel7.hp.com [156.153.255.213]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id g6B2JlX19734 for ; Wed, 10 Jul 2002 22:19:47 -0400 (EDT) Received: from xatlrelay1.atl.hp.com (xatlrelay1.atl.hp.com [15.45.89.190]) by atlrel7.hp.com (Postfix) with ESMTP id 3691D805004; Wed, 10 Jul 2002 22:19:47 -0400 (EDT) Received: from xatlbh3.atl.hp.com (xatlbh3.atl.hp.com [15.45.89.188]) by xatlrelay1.atl.hp.com (Postfix) with ESMTP id 1F33E12D; Wed, 10 Jul 2002 22:19:47 -0400 (EDT) Received: by xatlbh3.atl.hp.com with Internet Mail Service (5.5.2655.55) id ; Wed, 10 Jul 2002 22:19:46 -0400 Message-ID: <6BD67FFB937FD411A04F00D0B74FE87805CCF6C5@xrose06.rose.hp.com> From: "KRUEGER,MARJORIE (HP-Roseville,ex1)" To: "'Mallikarjun C.'" , Julian Satran Cc: ips@ece.cmu.edu Subject: RE: iSCSI: task set notes Date: Wed, 10 Jul 2002 22:19:43 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2655.55) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-ips@ece.cmu.edu Precedence: bulk > - In section 2.5.1.3, > > "The I_T_L nexus identifies task sets and is carried by the > LUN (and implied by the session identification)." > > Since an I_T_L nexus identifies only one task set, I > suggest the following - > > "The affected task set is identified by the I_T_L nexus, > which in turn is identified by the LUN and by the > session identification." In the above paragraphs, it seems that "I_T nexus identification" should be substituted for "session identification". Regards, Marjorie From owner-ips@ece.cmu.edu Wed Jul 10 23:00:29 2002 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA28577 for ; Wed, 10 Jul 2002 23:00:29 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id g6B2HG019603 for ips-outgoing; Wed, 10 Jul 2002 22:17:16 -0400 (EDT) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from palrel12.hp.com (palrel12.hp.com [156.153.255.237]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id g6B2HDX19597 for ; Wed, 10 Jul 2002 22:17:13 -0400 (EDT) Received: from xparelay2.corp.hp.com (xparelay2.corp.hp.com [15.58.137.112]) by palrel12.hp.com (Postfix) with ESMTP id C7B7EE00B1C; Wed, 10 Jul 2002 19:17:12 -0700 (PDT) Received: from xpabh3.corp.hp.com (xpabh3.corp.hp.com [15.58.136.223]) by xparelay2.corp.hp.com (Postfix) with ESMTP id B8A2116F; Wed, 10 Jul 2002 19:17:12 -0700 (PDT) Received: by xpabh3.corp.hp.com with Internet Mail Service (5.5.2655.55) id ; Wed, 10 Jul 2002 19:17:12 -0700 Message-ID: <6BD67FFB937FD411A04F00D0B74FE87805CCF6C4@xrose06.rose.hp.com> From: "KRUEGER,MARJORIE (HP-Roseville,ex1)" To: "Julian Satran (E-mail)" Cc: ips Subject: RE: iSCSI: DLB's Comment on SCSI Port Names Date: Wed, 10 Jul 2002 19:15:57 -0700 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2655.55) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C22880.E47A4B20" Sender: owner-ips@ece.cmu.edu Precedence: bulk This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_001_01C22880.E47A4B20 Content-Type: text/plain; charset="iso-8859-1" Julo, I'm a bit confused as the issues list on your website does not have this as issue 37, and all I see is issue 9 (where your comment appears to imply "no change"?) In any case, here's what I recommend: In sec 1.1 Definitions change the following definitions to: I_T Nexus: the last sentence should be The I_T nexus can be identified by the conjunction of the SCSI port names; that is, the I_T nexus identifier is the tuple (iSCSI Initiator Name + ',i,'+ ISID, iSCSI Target Name + ',t,'+ Portal Group Tag). SCSI Port Name: definition should be A name made up as UTF-8 characters and includes the iSCSI Name + ',i,' or ',t,' + ISID or Portal Group Tag In sec 2.2.7, 1st paragraph, delete the comment in parenthesis starting with "(for iSCSI,.." (or change it to point it to section 2.4.2, your choice). In sec 2.4.2, change the text to: When used in SCSI parameter data, the SCSI port name MUST be encoded as: - The iSCSI Name in UTF-8 format, followed by - a comma separator (1 byte), followed by - the ASCII character 'i' (for SCSI Initiator Port) or the ASCII character 't' (for SCSI Target Port), followed by - a comma separator (1 byte), followed by - A string representation (, see section 4.1 Text Format) of the ISID (for SCSI initiator port) or the portal group tag (for SCSI target port). SCSI port names have a maximum length of 255 bytes. The ASCII character 'i' or 't' is the label that identifies this port as either a SCSI Initiator Port or a SCSI Target Port. The 255 max port name makes for a 237 max iSCSI node name (check my math Jim :-) as the max character representation of an ISID is 15 characters for the largest decimal representation (14 char for the largest hex), + 3 char (",i,") + 237 = 255 The change in max node name causes changes to: sec 2.2.6.1, paragraph 2, sec 2.2.6.2, 2nd p, 3rd bullet I will see that a change is proposed to Annex A in whatever SAM doc is currently under revision. Thanks, Marjorie Krueger Networked Storage Architecture Networked Storage Solutions Org. Hewlett-Packard -----Original Message----- From: Julian Satran (Actcom) [mailto:Julian_Satran@actcom.net.il] Sent: Tuesday, July 09, 2002 6:44 AM To: KRUEGER,MARJORIE (HP-Roseville,ex1); 'Jim Hafner'; Black_David@emc.com Cc: ips Subject: Re: iSCSI: DLB's Comment on SCSI Port Names Marjorie, I'll list this as issue 37 and I think we can settle on 249 :-) I would appreciate if you let me know what constants change (in 2.4.2?) Julo ----- Original Message ----- From: KRUEGER,MARJORIE (HP-Roseville,ex1) To: 'Jim Hafner' ; Black_David@emc.com Cc: ips@ece.cmu.edu Sent: Tuesday, July 09, 2002 4:04 AM Subject: RE: iSCSI: DLB's Comment on SCSI Port Names I've just encountered this issue with regards to iSCSI port name encoding in the SCSI MIB, and the currently specified port name encoding causes inconvenience (at best). IMO, it makes sense to be able to treat an iSCSI name field, be it device name or port name, the same - as a string of display characters, portions of which may contain ASCII-encoded numeric values. I don't really see that it makes a difference whether one views ISID and TPGT as numeric strings or values, since as Jim says, there are no calculations performed using these things, and they are basicly just "tags". The issue for me is that the rest of the "SCSI port name" is a string and I see no value in "encoding" the ISID or TPGT as a value for SCSI purposes, as SCSI should have no need to use the ISID or TPGT values separately from the entire port name. And even if SCSI had such a need, it's a simple matter to convert a numeric string representation to a value. The downside of a string-encoding is the increased maximum size of the SCSI port name. If strings over 256 characters are a problem for some platforms, I'd be in favor of reducing the max iSCSI node name to 249 characters so the maximum SCSI port name would be 255 characters total (249 char name + ",i," + "0x0000") Marjorie Krueger Networked Storage Architecture Networked Storage Solutions Org. Hewlett-Packard -----Original Message----- From: Jim Hafner [mailto:hafner@almaden.ibm.com] Sent: Monday, July 08, 2002 9:08 AM To: Black_David@emc.com Cc: ips@ece.cmu.edu Subject: RE: iSCSI: DLB's Comment on SCSI Port Names David, I believe it will (may?) be used, so I agree we're in the second case. However, this format is the intended use in SCSI protocol stuff. Two places where SCSI ports names are used now is in ALIAS, Access Controls and in third party reservations -- see caveat below, however) I don't see a need in this context to define these as strings (that's not a SCSI way of thinking...). However, I think the issue comes down to a simple question: are the ISID and TPGT values or numerical strings (Julian is calling them numerical strings, but I've always thought of them as values, in spite of the fact that there is no arithmetic done on them - there is precedent in SCSI for such thinking, so I'm not completely out in the woods here). If they are values, then I'd like to see them formatted for SCSI in "value form"; if they are strings, then any representation should be OK. Does that at least get to the core of the issue? Jim Hafner CAVEAT: I don't think we'd use the iSCSI constructed port names in those contexts as device names are better suited for those purposes, but these are examples where specification of SCSI port name format is required. To: Jim Hafner/Almaden/IBM@IBMUS cc: ips@ece.cmu.edu Subject: RE: iSCSI: DLB's Comment on SCSI Port Names Jim, My view of this is that either: - The SCSI Port Name is never going to be used, in which case it shouldn't be designed to this level of detail. OR - It's going to be used, and hence is worth designing in a fashion that is reasonable to use. I think we're in the second category, and turning the ISID into hex ASCII (well, UTF-8) so the SCSI port name is a string is worth doing now to avoid problems when people actually try to use it. I would have no problems if someone wanted to pad the string, but I'd make specifying the padding the responsibility of the protocol/API/situation in which it was used rather than incorporating the padding into the name. Thanks, --David -----Original Message----- From: Jim Hafner [mailto:hafner@almaden.ibm.com] Sent: Monday, July 08, 2002 11:42 AM To: Black_David@emc.com Cc: ips@ece.cmu.edu Subject: Re: iSCSI: DLB's Comment on SCSI Port Names David, You wrote: >[T.9] 2.4.2 SCSI Architecture Model > > The SCSI Port Name is mandatory in iSCSI. When used in SCSI > parameter data, the SCSI port name MUST be encoded as: > - The iSCSI Name in UTF-8 format, followed by > - a comma separator (1 byte), followed by > - the ASCII character 'i' (for SCSI Initiator Port) or the > ASCII character 't' (for SCSI Target Port), followed by > - a comma separator (1 byte), followed by > - zero to 3 null pad bytes so that the complete format is a > multiple of four bytes long, followed by > - the 6byte value of the ISID (for SCSI initiator port) or the > 2byte value of the portal group tag (for SCSI target port) in > network byte order (BigEndian). > That's a peculiar format with padding nulls in the middle and > a number concatenated after the padding - for example, it can't > be passed in iSCSI login without format conversion. How about > converting the number to 4 or 12 bytes of hex (ASCII characters) > and moving the padding to the end so the result is actually a > string, and excluding the padding from the definition of the name? > This will increase the maximum length of port names, but produce > names that are easier to deal with. Admittedly that's an odd format, however here was the reason for this layout. 1) it's not used directly in iSCSI "Text" strings; it's intended to be a description of how this information is packed into a byte array for representation in "SCSI parameter data" (as it says!) -- that is, it's NEVER "passed in iSCSI login" (in this form). 2) the padding after the string was to force the binary values of the ISID or PGT to be better word aligned and can be more easily extracted as a value direct from the byte array without conversion. What do you think? Jim Hafner ------_=_NextPart_001_01C22880.E47A4B20 Content-Type: text/html; charset="iso-8859-1"
Julo,
I'm a bit confused as the issues list on your website does not have this as issue 37, and all I see is issue 9 (where your comment appears to imply "no change"?)
 
In any case, here's what I recommend:
 
In sec 1.1 Definitions change the following definitions to:
 
I_T Nexus:  the last sentence should be
 
The I_T nexus can be identified by the conjunction of the SCSI port names; that is, the I_T nexus identifier is the tuple (iSCSI Initiator Name + ',i,'+ ISID, iSCSI Target Name + ',t,'+ Portal Group Tag).
 
SCSI Port Name: definition should be
 
A name made up as UTF-8 characters and includes the  iSCSI Name + ',i,' or ',t,' + ISID or Portal Group Tag
 
In sec 2.2.7, 1st paragraph, delete the comment in parenthesis starting with "(for iSCSI,.." (or change it to point it to section 2.4.2, your choice).
 
In sec 2.4.2, change the text to:
 
  When used in SCSI parameter data, the SCSI port name MUST be encoded as:
      - The iSCSI Name in UTF-8 format, followed by
      - a comma separator (1 byte), followed by
      - the ASCII character 'i' (for SCSI Initiator Port) or the
       ASCII character 't' (for SCSI Target Port), followed by
      - a comma separator (1 byte), followed by
      - A string representation (<numerical-value>, see section 4.1 Text Format)
       of the ISID (for SCSI initiator port) or the portal group tag (for SCSI target port).
       SCSI port names have a maximum length of 255 bytes.
       The ASCII character 'i' or 't' is the label that identifies this port
       as either a SCSI Initiator Port or a SCSI Target Port.
The 255 max port name makes for a 237 max iSCSI node name (check my math Jim :-) as the max character representation of an ISID is 15 characters for the largest decimal representation (14 char for the largest hex), + 3 char (",i,") + 237 = 255
 
The change in max node name causes changes to:
 
sec 2.2.6.1, paragraph 2,
sec 2.2.6.2, 2nd p, 3rd bullet
 
I will see that a change is proposed to Annex A in whatever SAM doc is currently under revision.
 
Thanks,
Marjorie Krueger
Networked Storage Architecture
Networked Storage Solutions Org.
Hewlett-Packard
-----Original Message-----
From: Julian Satran (Actcom) [mailto:Julian_Satran@actcom.net.il]
Sent: Tuesday, July 09, 2002 6:44 AM
To: KRUEGER,MARJORIE (HP-Roseville,ex1); 'Jim Hafner'; Black_David@emc.com
Cc: ips
Subject: Re: iSCSI: DLB's Comment on SCSI Port Names

Marjorie,
 
I'll list this as issue 37 and I think we can settle on 249 :-)
I would appreciate if you let me know what constants change (in 2.4.2?)
 
Julo
----- Original Message -----
Sent: Tuesday, July 09, 2002 4:04 AM
Subject: RE: iSCSI: DLB's Comment on SCSI Port Names

I've just encountered this issue with regards to iSCSI port name encoding in the SCSI MIB, and the currently specified port name encoding causes inconvenience (at best).  IMO, it makes sense to be able to treat an iSCSI name field, be it device name or port name, the same - as a string of display characters, portions of which may contain ASCII-encoded numeric values.
 
I don't really see that it makes a difference whether one views ISID and TPGT as numeric strings or values, since as Jim says, there are no calculations performed using these things, and they are basicly just "tags".  The issue for me is that the rest of the "SCSI port name" is a string and I see no value in "encoding" the ISID or TPGT as a value for SCSI purposes, as SCSI should have no need to use the ISID or TPGT values separately from the entire port name.  And even if SCSI had such a need, it's a simple matter to convert a numeric string representation to a value.
 
The downside of a string-encoding is the increased maximum size of the SCSI port name.
 
If strings over 256 characters are a problem for some platforms, I'd be in favor of reducing the max iSCSI node name to 249 characters so the maximum SCSI port name would be 255 characters total (249 char name + ",i," + "0x0000")
 
Marjorie Krueger
Networked Storage Architecture
Networked Storage Solutions Org.
Hewlett-Packard
-----Original Message-----
From: Jim Hafner [mailto:hafner@almaden.ibm.com]
Sent: Monday, July 08, 2002 9:08 AM
To: Black_David@emc.com
Cc: ips@ece.cmu.edu
Subject: RE: iSCSI: DLB's Comment on SCSI Port Names


David,

I believe it will (may?) be used, so I agree we're in the second case.  However, this format is the intended use in SCSI protocol stuff.  Two places where SCSI ports names are used now is in ALIAS, Access Controls and in third party reservations -- see caveat below, however)

I don't see a need in this context to define these as strings (that's not a SCSI way of thinking...).  

However, I think the issue comes down to a simple question:  are the ISID and TPGT values or numerical strings (Julian is calling them numerical strings, but I've always thought of them as values, in spite of the fact that there is no arithmetic done on them - there is precedent in SCSI for such thinking, so I'm not completely out in the woods here).

If they are values, then I'd like to see them formatted for SCSI in "value form";  if they are strings, then any representation should be OK.

Does that at least get to the core of the issue?

Jim Hafner

CAVEAT: I don't think we'd use the iSCSI constructed port names in those contexts as device names are better suited for those purposes, but these are examples where specification of SCSI port name format is required.

To:        Jim Hafner/Almaden/IBM@IBMUS
cc:        ips@ece.cmu.edu
Subject:        RE: iSCSI: DLB's Comment on SCSI Port Names



Jim,

My view of this is that either:
- The SCSI Port Name is never going to be used, in which case
it shouldn't be designed to this level of detail. OR
- It's going to be used, and hence is worth designing in a fashion
that is reasonable to use.
I think we're in the second category, and turning the ISID into
hex ASCII (well, UTF-8) so the SCSI port name is a string is
worth doing now to avoid problems when people actually try
to use it.  I would have no problems if someone wanted to
pad the string, but I'd make specifying the padding the
responsibility of the protocol/API/situation in which it
was used rather than incorporating the padding into the name.

Thanks,
--David

-----Original Message-----
From: Jim Hafner [mailto:hafner@almaden.ibm.com]
Sent: Monday, July 08, 2002 11:42 AM
To: Black_David@emc.com
Cc: ips@ece.cmu.edu
Subject: Re: iSCSI: DLB's Comment on SCSI Port Names



David,

You wrote:

>[T.9] 2.4.2  SCSI Architecture Model
>
>  The SCSI Port Name is mandatory in iSCSI. When used in SCSI
>  parameter data, the SCSI port name MUST be encoded as:
>  - The iSCSI Name in UTF-8 format, followed by
>  - a comma separator (1 byte), followed by
>  - the ASCII character 'i' (for SCSI Initiator Port) or the
>    ASCII character 't' (for SCSI Target Port), followed by
>  - a comma separator (1 byte), followed by
>  - zero to 3 null pad bytes so that the complete format is a
>    multiple of four bytes long, followed by
>  - the 6byte value of the ISID (for SCSI initiator port) or the
>    2byte value of the portal group tag (for SCSI target port) in
>    network byte order (BigEndian).

> That's a peculiar format with padding nulls in the middle and
> a number concatenated after the padding - for example, it can't
> be passed in iSCSI login without format conversion.  How about
> converting the number to 4 or 12 bytes of hex (ASCII characters)
> and moving the padding to the end so the result is actually a
> string, and excluding the padding from the definition of the name?
> This will increase the maximum length of port names, but produce
> names that are easier to deal with.

Admittedly that's an odd format, however here was the reason for this
layout.
1) it's not used directly in iSCSI "Text" strings; it's intended to be a
description of how this information is packed into a byte array for
representation in "SCSI parameter data" (as it says!) -- that is, it's NEVER
"passed in iSCSI login" (in this form).
2) the padding after the string was to force the binary values of the ISID
or PGT to be better word aligned and can be more easily extracted as a value
direct from the byte array without conversion.

What do you think?

Jim Hafner

------_=_NextPart_001_01C22880.E47A4B20-- From owner-ips@ece.cmu.edu Thu Jul 11 01:17:36 2002 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA00607 for ; Thu, 11 Jul 2002 01:17:36 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id g6B53Hx27637 for ips-outgoing; Thu, 11 Jul 2002 01:03:17 -0400 (EDT) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from maho3msx2.isus.emc.com (maho3msx2.isus.emc.com [128.221.11.32]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id g6B53GX27632 for ; Thu, 11 Jul 2002 01:03:16 -0400 (EDT) Received: by MAHO3MSX2 with Internet Mail Service (5.5.2653.19) id <31WC3643>; Thu, 11 Jul 2002 01:01:13 -0400 Message-ID: <277DD60FB639D511AC0400B0D068B71E0564C065@CORPMX14> From: Black_David@emc.com To: Julian_Satran@il.ibm.com Cc: ips@ece.cmu.edu Subject: RE: iSCSI: DLB's [T.6] 2.3 iSCSI Session Types Date: Thu, 11 Jul 2002 01:01:10 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-ips@ece.cmu.edu Precedence: bulk Julian > I can agree with MUST but I will resist adding any notification. > > It is just the wrong thing to do. I don't care - getting to a MUST with a list of allowed PDUs that forbids all others from the current MAY that allows everything is what matters to me. At the moment, I've only seen Ayman ask for Async Message to be allowed on discovery sessions - does anyone else want to see that PDU allowed on discovery sessions? 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 --------------------------------------------------- From owner-ips@ece.cmu.edu Thu Jul 11 01:19:41 2002 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA00634 for ; Thu, 11 Jul 2002 01:19:40 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id g6B4bhf26432 for ips-outgoing; Thu, 11 Jul 2002 00:37:43 -0400 (EDT) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from maho3msx2.isus.emc.com (maho3msx2.isus.emc.com [128.221.11.32]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id g6B4bfX26425 for ; Thu, 11 Jul 2002 00:37:41 -0400 (EDT) Received: by MAHO3MSX2 with Internet Mail Service (5.5.2653.19) id <31WC355A>; Thu, 11 Jul 2002 00:35:34 -0400 Message-ID: <277DD60FB639D511AC0400B0D068B71E05D425C8@CORPMX14> From: Black_David@emc.com To: Julian_Satran@il.ibm.com Cc: ips@ece.cmu.edu Subject: RE: iSCSI: editorial rewrite not needed Date: Thu, 11 Jul 2002 00:35:31 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-ips@ece.cmu.edu Precedence: bulk Julian, This complaining about lateness of comments really needs to stop. WG Last Call is about gathering up any and all comments on the spec, and the timing of comments is whatever happens. I would have liked to have been able to get my comments in much earlier also, but life is what happens while one is busy making other plans ... As for the overview sections for both error recovery and login - it is still my view that both the Current Sections 4 and 6 need them (if there's text that can be moved down from Section 2 to help accomplish this for error recovery, that's fine). The fact that the structural issues in these sections that make them hard to understand may have been there for a long time is not a good reason to avoid correcting them. I'd really rather not have to spend Yokohama agenda time on editorial issues like these, but if you insist ... Thanks, --David > -----Original Message----- > From: Julian Satran [mailto:Julian_Satran@il.ibm.com] > Sent: Wednesday, July 10, 2002 12:00 AM > To: Black_David@emc.com > Cc: ips@ece.cmu.edu; John Hufferd; owner-ips@ece.cmu.edu > Subject: Re: iSCSI: editorial rewrite not needed > > > > David, > > Swapping 5 and 6 is not a major issue. However I have to object to the > recovery overview. > It is already contained in 6 itself and in 2. > > And I have to stand by John's comment about the lateness of > your comments. > It is disappointing that you got to this that late - and most of your > comments refer to text that was there > for a long time. > > Julo > > > > > > > > Black_David@emc.c > > > om To: John > Hufferd/San Jose/IBM@IBMUS > > Sent by: cc: > ips@ece.cmu.edu > > owner-ips@ece.cmu Subject: > iSCSI: editorial rewrite not needed > > .edu > > > > > > > > > 07/09/2002 09:44 > > > AM > > > Please respond to > > > Black_David > > > > > > > > > > > > John, > > My original text was: > > Global Editorial comment: Both the login (4) and error handling (6) > sections > feel like one of those old Adventure mazes of twisty little > passages - all > the > details seem to be there, for the most part they're correct, > but it's very > hard > to get the proverbial "big picture" of how everything fits > together, in > terms > of how the various mechanisms work with each other and how > they accomplish > the overall functionality. Both of these could use overview sections > describing > how the functionality breaks down into the pieces described in the > subsections > and how they fit together. Swapping the order of Sections 5 > and 6 would > also > be a good idea so that the discussion of Error Handling and > Recovery comes > before the state machine descriptions that contain a lot of > the details of > how errors are handled. For error handling, moving Section > 6.13 to the > front of Section 6 would help organize the Section better, > and care should > be > taken to define or replace terms like "restart login" and > "recovery R2T" > that are currently used without definitions. > > > I disagree with the editorial rewrite, especially at this > late state. If > > they were important that should have been brought up earlier. > > I fail to see how you got from my original text whose primary > request was > for "overview sections describing ..." to "editorial > rewrite", so I think > you're seriously over-reacting. Concerns about comprehensibility have > been brought up on the list in the past. > > > We should > > not be discussing editorial style, but whether we have correctly > specified > > the protocol. > > This isn't about "editorial style", but rather whether the > specification > is comprehensible to an implementer who picks it up from > scratch without > the benefit of this group's email discussions, short term memory, etc. > > > We have already changed it a couple of times, and you are > > now wanting it changed again. This is a very big spec, and > each time we > > make changes to pretty up the document, the more that is needed, and > > someone else has another preference. > > If the spec has problems, Working Group Last Call is the point in > time to find and fix them, and if that takes serious effort, > c'est la vie. > I'm prepared to listen to arguments that the spec is sufficiently > comprehensible as to need no editorial changes, but I'm not > inclined to > assign them a great deal of credibility at this juncture. > > > It is already better then most of the > > other IETF specs. I think this causes a needless delay. > > I disagree and take exception to the view that iSCSI > is needlessly being held to a higher standard. The need for a > comprehensible spec is real, and that is not a higher standard > than other IETF specs are generally held to, although there are > some that have gotten away - IKE/ISAKMP and the related keying > portions of IPsec are an example that we are unfortunately > familiar with. It should not take an iSCSI guru with a secret > decoder ring to unscramble how the protocol works even if all > the interacting pieces are correctly specified somewhere in the > document. > > On further reflection, I think that an overview section on error > handling in the current Section 6 plus swapping the order of Section 5 > and Section 6 probably removes the need to tease apart the initiator > and target state machine specifications in the current Section 5 > (my comments E.80 and E.81). That should reduce the amount of work > required provided that the overview text for error handling is well- > written. > > 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 > --------------------------------------------------- > > > > From owner-ips@ece.cmu.edu Thu Jul 11 04:33:57 2002 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA13223 for ; Thu, 11 Jul 2002 04:33:57 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id g6B88wv06354 for ips-outgoing; Thu, 11 Jul 2002 04:08:58 -0400 (EDT) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from mxic2.corp.emc.com (mxic2.isus.emc.com [128.221.31.40]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id g6B88vX06350 for ; Thu, 11 Jul 2002 04:08:58 -0400 (EDT) Received: by mxic2.corp.emc.com with Internet Mail Service (5.5.2653.19) id <31X64MFX>; Thu, 11 Jul 2002 04:08:52 -0400 Message-ID: <277DD60FB639D511AC0400B0D068B71E0564C067@CORPMX14> From: Black_David@emc.com To: ips@ece.cmu.edu Subject: Status of DLB's technical comments Date: Thu, 11 Jul 2002 04:06:52 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-ips@ece.cmu.edu Precedence: bulk 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 --------------------------------------------------- From owner-ips@ece.cmu.edu Thu Jul 11 04:35:45 2002 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA13260 for ; Thu, 11 Jul 2002 04:35:45 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id g6B80OJ05866 for ips-outgoing; Thu, 11 Jul 2002 04:00:24 -0400 (EDT) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from maho3msx2.isus.emc.com (maho3msx2.isus.emc.com [128.221.11.32]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id g6B80NX05858 for ; Thu, 11 Jul 2002 04:00:23 -0400 (EDT) Received: by MAHO3MSX2 with Internet Mail Service (5.5.2653.19) id <31WCPDF0>; Thu, 11 Jul 2002 03:58:18 -0400 Message-ID: <277DD60FB639D511AC0400B0D068B71E0564C066@CORPMX14> From: Black_David@emc.com To: ips@ece.cmu.edu Subject: iSCSI: IANA issues (DLB T.38 and T.39) Date: Thu, 11 Jul 2002 03:58:17 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-ips@ece.cmu.edu Precedence: bulk In looking at Julian's proposals to deal with my comments on the IANA text, I ran into some issues that need attention on the list. [T.38] 12. IANA Considerations The temporary (user) well-known port number for iSCSI connections assigned by IANA is 3260. Delete "temporary (user)" insert "TCP" before "port number" or add instructions for IANA to allocate a system port when this draft is approved to become an RFC - I think just sticking with 3260 is better. Julian's working draft instructs IANA to allocate a system port. My opinion is that 3260 isn't broken, doesn't need to be fixed, and asking IANA to allocate a system port at the unpredictable point in the future when the IESG has approved iSCSI and it's gotten far enough down the RFC Editor Queue for IANA to do its thing seems unnecessary and a possible invitation to confusion. What do other people think? [T.39] 12. IANA Considerations If vendor additions of values to existing keys is to be allowed (e.g., AuthMethod, HeaderDigest, DataDigest) an IANA registry is needed for each set of values - see [T.32] and [T.34], or the reversed DNS convention needs to be extended from keys to values - the latter doesn't sound like a good idea. Julian's response was to wonder whether an IANA registry is necessary. First of all, there is a problem here - for example, if two different vendors assign the key value CRC64K to two different CRC algorithms, the resulting nasty interoperability failure is unacceptable. I think the options are either to require a reversed domain name in every vendor-specific key value, or use an IANA registry. Short vendor- specific key values without the X- prefix are probably going to require an IANA registry, and that creates a few complications. The one issue that *must* be resolved now is that new key values for AuthMethod will need related new keys (e.g., the new vendor-specific GRUMPY authentication method may need new GRUMPY_AX, GRUMPY_FOO, and GRUMPY_RES keys). We could disallow this and force all new vendor specific keys to use the X- format. Alternatively, it's probably sufficient to require that such keys MUST start with the IANA-registered AuthMethod value followed by an underscore; this ensures that they don't conflict with each other or with keys we might want to define in the future. It does allow for value conflicts - e.g., once a vendor has registered the GRUMPY AuthMethod value, we can't use GRUMPY for some other algorithm. If we don't use an IANA registry, the X- format of vendor specific keys corresponds well with using reversed domain names in vendor- specific key values (e.g., AuthMethod=X-com.foo.GRUMPY, and later X-com.foo.GRUMPY_AX= ...). An issue that we could settle now or defer is whether to ensure that vendor-specific key values don't consume strings that we might want to use later. This is only a problem with an IANA registry, as any key value containing a reversed domain name will contain a period and the key values we're likely to define won't use a period. A similar rule that could be used with an IANA registry could be to require that every vendor-specific key value contain an embedded underscore (or be prefixed and suffixed by an underscore? or some other distinguishing prefix?). The result might be that the new AuthMethod value is GRUMPY_1. I think the high-level issue is whether to use the X- format for vendor-specific key values (and keys) or whether to use an IANA registry to allow more compact values (and related keys). Comments? --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 --------------------------------------------------- From owner-ips@ece.cmu.edu Thu Jul 11 11:25:09 2002 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA20947 for ; Thu, 11 Jul 2002 11:25:08 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id g6BF4YC09840 for ips-outgoing; Thu, 11 Jul 2002 11:04:34 -0400 (EDT) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from sj-msg-core-2.cisco.com (sj-msg-core-2.cisco.com [171.69.24.11]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id g6BF4VX09827 for ; Thu, 11 Jul 2002 11:04:31 -0400 (EDT) Received: from nisser.cisco.com (nisser.cisco.com [171.71.176.85]) by sj-msg-core-2.cisco.com (8.12.2/8.12.2) with ESMTP id g6BF4PhI017365; Thu, 11 Jul 2002 08:04:25 -0700 (PDT) Received: from cisco.com (mbakke@mbakke-lnx.cisco.com [161.44.68.87]) by nisser.cisco.com (8.8.6 (PHNE_14041)/CISCO.SERVER.1.2) with ESMTP id IAA02094; Thu, 11 Jul 2002 08:04:24 -0700 (PDT) Message-ID: <3D2DA295.463AEBC8@cisco.com> Date: Thu, 11 Jul 2002 10:21:57 -0500 From: Mark Bakke X-Mailer: Mozilla 4.72 [en] (X11; U; Linux 2.2.16-3.uid32 i686) X-Accept-Language: en, de MIME-Version: 1.0 To: Black_David@emc.com CC: Julian_Satran@il.ibm.com, ips@ece.cmu.edu Subject: Re: iSCSI: DLB's [T.6] 2.3 iSCSI Session Types References: <277DD60FB639D511AC0400B0D068B71E0564C065@CORPMX14> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ips@ece.cmu.edu Precedence: bulk Content-Transfer-Encoding: 7bit Actually, we want to be able to send Async Message and Noop In from the target, and allow the initiator to send Noop Out, since these are more in the iSCSI session maintenance category of messages. There's definitely no reason to allow Scsi Command / Response, Task Management Command / Response, Data In/Out, Snack, and R2T on a discovery session. -- Mark Black_David@emc.com wrote: > > Julian > > > I can agree with MUST but I will resist adding any notification. > > > > It is just the wrong thing to do. > > I don't care - getting to a MUST with a list of allowed PDUs that > forbids all others from the current MAY that allows everything is > what matters to me. > > At the moment, I've only seen Ayman ask for Async Message to be > allowed on discovery sessions - does anyone else want to see that > PDU allowed on discovery sessions? > > 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 > --------------------------------------------------- -- Mark A. Bakke Cisco Systems mbakke@cisco.com 763.398.1054 From owner-ips@ece.cmu.edu Thu Jul 11 11:25:30 2002 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA20972 for ; Thu, 11 Jul 2002 11:25:30 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id g6BFGJ310830 for ips-outgoing; Thu, 11 Jul 2002 11:16:19 -0400 (EDT) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from e2.ny.us.ibm.com (e2.ny.us.ibm.com [32.97.182.102]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id g6BFGHX10826 for ; Thu, 11 Jul 2002 11:16:17 -0400 (EDT) Received: from northrelay01.pok.ibm.com (northrelay01.pok.ibm.com [9.56.224.149]) by e2.ny.us.ibm.com (8.12.2/8.12.2) with ESMTP id g6BFFre8137648; Thu, 11 Jul 2002 11:15:54 -0400 Received: from d03nm041.boulder.ibm.com (avpilot.boulder.ibm.com [9.17.203.135]) by northrelay01.pok.ibm.com (8.11.1m3/NCO/VER6.1) with ESMTP id g6BFFnl61678; Thu, 11 Jul 2002 11:15:49 -0400 Subject: Re: iSCSI: DLB's [T.6] 2.3 iSCSI Session Types To: Mark Bakke Cc: Black_David@emc.com, ips@ece.cmu.edu, "Julian Satran" , owner-ips@ece.cmu.edu X-Mailer: Lotus Notes Release 5.0.7 March 21, 2001 Message-ID: From: "Prasenjit Sarkar" Date: Thu, 11 Jul 2002 08:15:38 -0700 X-MIMETrack: Serialize by Router on D03NM041/03/M/IBM(Release 5.0.10 |March 22, 2002) at 07/11/2002 08:15:51 AM MIME-Version: 1.0 Content-type: text/plain; charset=us-ascii Sender: owner-ips@ece.cmu.edu Precedence: bulk I'm not sure what Mark means by "we", but I am opposed to any dynamic discovery mechanisms for SendTargets because of my belief that these mechanisms does not belong here. Therefore I vote against Noop and Async messages, Sincerely, Prasenjit Sarkar Research Staff Member IBM Almaden Research San Jose Mark Bakke cc: Julian Satran/Haifa/IBM@IBMIL, ips@ece.cmu.edu Sent by: Subject: Re: iSCSI: DLB's [T.6] 2.3 iSCSI Session Types owner-ips@ece.cmu .edu 07/11/2002 08:21 AM Actually, we want to be able to send Async Message and Noop In from the target, and allow the initiator to send Noop Out, since these are more in the iSCSI session maintenance category of messages. There's definitely no reason to allow Scsi Command / Response, Task Management Command / Response, Data In/Out, Snack, and R2T on a discovery session. -- Mark Black_David@emc.com wrote: > > Julian > > > I can agree with MUST but I will resist adding any notification. > > > > It is just the wrong thing to do. > > I don't care - getting to a MUST with a list of allowed PDUs that > forbids all others from the current MAY that allows everything is > what matters to me. > > At the moment, I've only seen Ayman ask for Async Message to be > allowed on discovery sessions - does anyone else want to see that > PDU allowed on discovery sessions? > > 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 > --------------------------------------------------- -- Mark A. Bakke Cisco Systems mbakke@cisco.com 763.398.1054 From owner-ips@ece.cmu.edu Thu Jul 11 11:27:58 2002 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA21087 for ; Thu, 11 Jul 2002 11:27:58 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id g6BFHab10925 for ips-outgoing; Thu, 11 Jul 2002 11:17:36 -0400 (EDT) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from d12lmsgate.de.ibm.com (d12lmsgate.de.ibm.com [195.212.91.199]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id g6BFHZX10921 for ; Thu, 11 Jul 2002 11:17:35 -0400 (EDT) Received: from d12relay02.de.ibm.com (d12relay02.de.ibm.com [9.165.215.23]) by d12lmsgate.de.ibm.com (8.12.3/8.12.3) with ESMTP id g6BFHIDX033002; Thu, 11 Jul 2002 17:17:18 +0200 Received: from d10hubm1.telaviv.ibm.com (d10ml001.telaviv.ibm.com [9.148.216.55]) by d12relay02.de.ibm.com (8.11.1m3/NCO/VER6.2) with ESMTP id g6BFHIj49186; Thu, 11 Jul 2002 17:17:18 +0200 To: Mark Bakke Cc: Black_David@emc.com, ips@ece.cmu.edu, mbakke@cisco.com MIME-Version: 1.0 Subject: Re: iSCSI: DLB's [T.6] 2.3 iSCSI Session Types X-Mailer: Lotus Notes Release 5.0.9 November 16, 2001 From: "Julian Satran" Message-ID: Date: Thu, 11 Jul 2002 18:17:12 +0300 X-MIMETrack: Serialize by Router on D10ML001/10/M/IBM(Release 5.0.9a |January 7, 2002) at 11/07/2002 18:17:18, Serialize complete at 11/07/2002 18:17:18 Content-Type: multipart/alternative; boundary="=_alternative 00537BDEC2256BF3_=" Sender: owner-ips@ece.cmu.edu Precedence: bulk This is a multipart message in MIME format. --=_alternative 00537BDEC2256BF3_= Content-Type: text/plain; charset="us-ascii" I completely disagree - and this is a thing that we debated repeatedly. I formally ask this to be closed, We don't want the discovery session as an alternative discovery mechanism. The IP protocol set has enough other (common) venues for this. Julo Mark Bakke Sent by: mbakke@cisco.com 07/11/2002 06:21 PM Please respond to Mark Bakke To: Black_David@emc.com cc: Julian Satran/Haifa/IBM@IBMIL, ips@ece.cmu.edu Subject: Re: iSCSI: DLB's [T.6] 2.3 iSCSI Session Types Actually, we want to be able to send Async Message and Noop In from the target, and allow the initiator to send Noop Out, since these are more in the iSCSI session maintenance category of messages. There's definitely no reason to allow Scsi Command / Response, Task Management Command / Response, Data In/Out, Snack, and R2T on a discovery session. -- Mark Black_David@emc.com wrote: > > Julian > > > I can agree with MUST but I will resist adding any notification. > > > > It is just the wrong thing to do. > > I don't care - getting to a MUST with a list of allowed PDUs that > forbids all others from the current MAY that allows everything is > what matters to me. > > At the moment, I've only seen Ayman ask for Async Message to be > allowed on discovery sessions - does anyone else want to see that > PDU allowed on discovery sessions? > > 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 > --------------------------------------------------- -- Mark A. Bakke Cisco Systems mbakke@cisco.com 763.398.1054 --=_alternative 00537BDEC2256BF3_= Content-Type: text/html; charset="us-ascii"
I completely disagree - and this is a thing that we debated repeatedly.
I formally ask this to be closed, We don't want the discovery session
as an alternative discovery mechanism. The IP protocol set has enough other (common)
venues for this.

Julo


Mark Bakke <mbakke@cisco.com>
Sent by: mbakke@cisco.com

07/11/2002 06:21 PM
Please respond to Mark Bakke

       
        To:        Black_David@emc.com
        cc:        Julian Satran/Haifa/IBM@IBMIL, ips@ece.cmu.edu
        Subject:        Re: iSCSI: DLB's [T.6] 2.3  iSCSI Session Types

       


Actually, we want to be able to send Async Message and Noop In
from the target, and allow the initiator to send Noop Out, since
these are more in the iSCSI session maintenance category of
messages.

There's definitely no reason to allow Scsi Command / Response,
Task Management Command / Response, Data In/Out, Snack, and
R2T on a discovery session.

--
Mark

Black_David@emc.com wrote:
>
> Julian
>
> > I can agree with MUST but I will resist adding any notification.
> >
> > It is just the wrong thing to do.
>
> I don't care - getting to a MUST with a list of allowed PDUs that
> forbids all others from the current MAY that allows everything is
> what matters to me.
>
> At the moment, I've only seen Ayman ask for Async Message to be
> allowed on discovery sessions - does anyone else want to see that
> PDU allowed on discovery sessions?
>
> 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
> ---------------------------------------------------

--
Mark A. Bakke
Cisco Systems
mbakke@cisco.com
763.398.1054

--=_alternative 00537BDEC2256BF3_=-- From owner-ips@ece.cmu.edu Thu Jul 11 11:30:00 2002 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA21203 for ; Thu, 11 Jul 2002 11:30:00 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id g6BEhD808374 for ips-outgoing; Thu, 11 Jul 2002 10:43:13 -0400 (EDT) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from d12lmsgate-2.de.ibm.com (d12lmsgate-2.de.ibm.com [195.212.91.200]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id g6BEhAX08370 for ; Thu, 11 Jul 2002 10:43:10 -0400 (EDT) Received: from d12relay02.de.ibm.com (d12relay02.de.ibm.com [9.165.215.23]) by d12lmsgate-2.de.ibm.com (8.12.3/8.12.3) with ESMTP id g6BEgr2Q049462; Thu, 11 Jul 2002 16:42:53 +0200 Received: from d10hubm1.telaviv.ibm.com (d10ml001.telaviv.ibm.com [9.148.216.55]) by d12relay02.de.ibm.com (8.11.1m3/NCO/VER6.2) with ESMTP id g6BEgpj15212; Thu, 11 Jul 2002 16:42:52 +0200 To: "Mallikarjun C." Cc: ips@ece.cmu.edu, ivan.pavelka@s3group.com, "Julian Satran (Actcom)" , owner-ips@ece.cmu.edu, pat_thaler@agilent.com, tomasb@s3group.cz MIME-Version: 1.0 Subject: Re: iSCSI: draft vs. 14 typos, suggestion, questions X-Mailer: Lotus Notes Release 5.0.9 November 16, 2001 From: "Julian Satran" Message-ID: Date: Thu, 11 Jul 2002 17:42:43 +0300 X-MIMETrack: Serialize by Router on D10ML001/10/M/IBM(Release 5.0.9a |January 7, 2002) at 11/07/2002 17:42:53, Serialize complete at 11/07/2002 17:42:53 Content-Type: multipart/alternative; boundary="=_alternative 004FE6CCC2256BF3_=" Sender: owner-ips@ece.cmu.edu Precedence: bulk This is a multipart message in MIME format. --=_alternative 004FE6CCC2256BF3_= Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Mallikarjun, We decided early one that we don't want to touch the notion of a task set = because of the mess we are going to have to handle with TST=3D0. What has changed? Julo "Mallikarjun C." Sent by: owner-ips@ece.cmu.edu 07/11/2002 02:38 AM Please respond to "Mallikarjun C." =20 To: "Julian Satran (Actcom)" ,=20 , cc: , Subject: Re: iSCSI: draft vs. 14 typos, suggestion, questions =20 Sorry, I'm catching up late on email.... I see that the latest wording on this is - When the session timeout (the connection state timeout for the last failed = connection) happens on the target, it takes the following actions: - Resets or closes the TCP connections (closes the session). - Aborts all Tasks in the task set associated with the session. I think the second bullet is incorrect. While the previous wording had=20 the issue that Pat identified (that there may be one task set for each LU the=20 session can get to), the new wording still has that issue and in addition, also=20 implies that all tasks in the task set need to be terminated. However, a LU may=20 maintain only one task set for multiple initiators (if TST=3D0 in control mode page) in which= =20 case, the current wording implies that all tasks from other initiators need to be=20 terminated as well on one session timeout - which is not intended. I am beginning to think that the notion of "task set" is beyond iSCSI and=20 it's best not to refer to it here. I suggest the following text instead - When the session timeout (section 4.3.5) happens on the target, it takes=20 the following actions: - Resets or closes the TCP connections (closes the session). - Terminates all active tasks that were allegiant to the connection(s)=20 that constituted the session. Thanks. -- Mallikarjun Mallikarjun Chadalapaka Networked Storage Architecture Network Storage Solutions Hewlett-Packard MS 5668 Roseville CA 95747 cbm@rose.hp.com ----- Original Message ----- From: "Julian Satran (Actcom)" To: ; Cc: ; Sent: Thursday, July 04, 2002 9:08 PM Subject: Re: iSCSI: draft vs. 14 typos, suggestion, questions > I will do the text change (I hope it makes it easier for at least one=20 reader > is not worse for anybody else). > The reason why we choose the wording was that SAM associates the task=20 set > with an initiator by the session is wording is equivalent. > > Julo > ----- Original Message ----- > From: > To: ; > Cc: ; > Sent: Wednesday, July 03, 2002 9:38 PM > Subject: RE: iSCSI: draft vs. 14 typos, suggestion, questions > > > > See comment below. Pat > > -----Original Message----- > > From: Julian Satran [mailto:Julian=5FSatran@il.ibm.com] > > Sent: Wednesday, July 03, 2002 9:20 AM > > To: Tom=E1? Bartu?ek > > Cc: ips@ece.cmu.edu; ivan.pavelka@s3group.com > > Subject: Re: iSCSI: draft vs. 14 typos, suggestion, questions > > > > > > > > *** Section 6.11 : QUESTION > > Draft says: > > When the session timeout (the connection state timeout for the last > > failed connection) happens on the target, it takes the following > > actions: > > > > - Resets or closes the TCP connections (closes the session). > > - Aborts all Tasks in the task set for the corresponding initi- > > ator. > > > > What does the "corresponding initiator" mean? We think (:-)), that > > there is only one initiator for the session. The only possible > > explanation we see for that paragraph is, that the target should > > abort also other tasks of the same in =5F=5Fother=5F=5F sessions, but > > why? > > +++ your interpretation is correct - the statement means the initiator > that "owned" the session. > > Are you suggesting other wording? > > ++++ > > "Aborts all task sets associated with the session" > > (Task set was changed to plural because task set is defined as an=20 I-T-L > nexus and there may be muliple ones in the session. > > > > --=_alternative 004FE6CCC2256BF3_= Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
Mallikarjun,

We decided early one that we don't w= ant to touch the notion of a task  set  because of the mess we ar= e going to have to handle with TST=3D0.
What has changed?

Julo


"Mallikarjun C." <cb= m@rose.hp.com>
Sent by: owner-ips@ece.cmu.edu

07/11/2002 02:38 AM
Please respond to "Mallikarjun = C."

       
        To: &nbs= p;      "Julian Satran (Actcom)" <Julian=5FSatr= an@actcom.net.il>, <pat=5Fthaler@agilent.com>, <tomasb@s3group.= cz>
        cc: &nbs= p;      <ips@ece.cmu.edu>, <ivan.pavelka@s3group.co= m>
        Subject:=        Re: iSCSI: draft vs. 14 typos, suggestion, ques= tions

       


Sorry, I'm catching up late on emai= l....

I see that the latest wording on this is -

When the session timeout (the connection state timeout for the last failed = connection) happens on the target,
it takes the following actions:
- Resets or closes the TCP connections (closes the session).
- Aborts all Tasks in the task set associated with the session.

I think the second bullet is incorrect.  While the previous wording ha= d the
issue that Pat identified (that there may be one task set for each LU the s= ession
can get to), the new wording still has that issue and in addition, also imp= lies that
all tasks in the task set need to be terminated.  However, a LU may ma= intain only one
task set for multiple initiators (if TST=3D0 in control mode page) in which= case, the
current wording implies that all tasks from other initiators need to be ter= minated
as well on one session timeout - which is not intended.

I am beginning to think that the notion of "task set" is beyond i= SCSI and it's best
not to refer to it here.

I suggest the following text instead -

When the session timeout (section 4.3.5) happens on the target, it takes th= e following actions:
- Resets or closes the TCP connections (closes the session).
- Terminates all active tasks that were allegiant to the connection(s) that= constituted the session.

Thanks.
--
Mallikarjun

Mallikarjun Chadalapaka
Networked Storage Architecture
Network Storage Solutions
Hewlett-Packard MS 5668
Roseville CA 95747
cbm@rose.hp.com

----- Original Message -----
From: "Julian Satran (Actcom)" <Julian=5FSatran@actcom.net.il&= gt;
To: <pat=5Fthaler@agilent.com>; <tomasb@s3group.cz>
Cc: <ips@ece.cmu.edu>; <ivan.pavelka@s3group.com>
Sent: Thursday, July 04, 2002 9:08 PM
Subject: Re: iSCSI: draft vs. 14 typos, suggestion, questions


> I will do the text change (I hope it makes it easier for at least one = reader
> is not worse for anybody else).
> The reason why we choose the wording was that SAM associates the task = set
> with an initiator by the session is wording is equivalent.
>
> Julo
> ----- Original Message -----
> From: <pat=5Fthaler@agilent.com>
> To: <Julian=5FSatran@il.ibm.com>; <tomasb@s3group.cz>
> Cc: <ips@ece.cmu.edu>; <ivan.pavelka@s3group.com>
> Sent: Wednesday, July 03, 2002 9:38 PM
> Subject: RE: iSCSI: draft vs. 14 typos, suggestion, questions
>
>
> > See comment below. Pat
> > -----Original Message-----
> > From: Julian Satran [mailto:Julian=5FSatran@il.ibm.com]
> > Sent: Wednesday, July 03, 2002 9:20 AM
> > To: Tom=E1? Bartu?ek
> > Cc: ips@ece.cmu.edu; ivan.pavelka@s3group.com
> > Subject: Re: iSCSI: draft vs. 14 typos, suggestion, questions
> >
> >
> >
> > *** Section 6.11 : QUESTION
> > Draft says:
> >   When the session timeout (the connection state timeout for= the last
> >   failed connection) happens on the target, it takes the fol= lowing
> >   actions:
> >
> >     - Resets or closes the TCP connections (closes the = session).
> >     - Aborts all Tasks in the task set for the correspo= nding initi-
> >       ator= .
> >
> > What does the "corresponding initiator" mean? We think = (:-)), that
> > there is only one initiator for the session. The only possible
> > explanation we see for that paragraph is, that the target should<= br> > > abort also other tasks of the same in =5F=5Fother=5F=5F sessions,= but
> > why?
> > +++ your interpretation is correct - the statement means the init= iator
> that "owned" the session.
> > Are you suggesting other wording?
> > ++++
> > <PAT> "Aborts all task sets associated with the sessio= n"
> > (Task set was changed to plural because task set is defined as an= I-T-L
> nexus and there may be muliple ones in the session. <PAT>
> >
>
>

--=_alternative 004FE6CCC2256BF3_=-- From owner-ips@ece.cmu.edu Thu Jul 11 11:31:59 2002 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA21306 for ; Thu, 11 Jul 2002 11:31:59 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id g6BEhL908384 for ips-outgoing; Thu, 11 Jul 2002 10:43:21 -0400 (EDT) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from d12lmsgate.de.ibm.com (d12lmsgate.de.ibm.com [195.212.91.199]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id g6BEh9X08366 for ; Thu, 11 Jul 2002 10:43:09 -0400 (EDT) Received: from d12relay02.de.ibm.com (d12relay02.de.ibm.com [9.165.215.23]) by d12lmsgate.de.ibm.com (8.12.3/8.12.3) with ESMTP id g6BEh0DX030344; Thu, 11 Jul 2002 16:43:00 +0200 Received: from d10hubm1.telaviv.ibm.com (d10ml001.telaviv.ibm.com [9.148.216.55]) by d12relay02.de.ibm.com (8.11.1m3/NCO/VER6.2) with ESMTP id g6BEh0j11642; Thu, 11 Jul 2002 16:43:00 +0200 To: Black_David@emc.com Cc: ips@ece.cmu.edu MIME-Version: 1.0 Subject: RE: iSCSI: editorial rewrite not needed X-Mailer: Lotus Notes Release 5.0.9 November 16, 2001 From: "Julian Satran" Message-ID: Date: Thu, 11 Jul 2002 17:42:49 +0300 X-MIMETrack: Serialize by Router on D10ML001/10/M/IBM(Release 5.0.9a |January 7, 2002) at 11/07/2002 17:43:00, Serialize complete at 11/07/2002 17:43:00 Content-Type: multipart/alternative; boundary="=_alternative 00505EF4C2256BF3_=" Sender: owner-ips@ece.cmu.edu Precedence: bulk This is a multipart message in MIME format. --=_alternative 00505EF4C2256BF3_= Content-Type: text/plain; charset="us-ascii" David, I don't want to spend time o n the agenda either. I hope however that you might want to set you priorities to include work in this group. The complaints where not only about the lateness of the comments but also about their classification. Julo Black_David@emc.com 07/11/2002 07:35 AM Please respond to Black_David To: Julian Satran/Haifa/IBM@IBMIL cc: ips@ece.cmu.edu Subject: RE: iSCSI: editorial rewrite not needed Julian, This complaining about lateness of comments really needs to stop. WG Last Call is about gathering up any and all comments on the spec, and the timing of comments is whatever happens. I would have liked to have been able to get my comments in much earlier also, but life is what happens while one is busy making other plans ... As for the overview sections for both error recovery and login - it is still my view that both the Current Sections 4 and 6 need them (if there's text that can be moved down from Section 2 to help accomplish this for error recovery, that's fine). The fact that the structural issues in these sections that make them hard to understand may have been there for a long time is not a good reason to avoid correcting them. I'd really rather not have to spend Yokohama agenda time on editorial issues like these, but if you insist ... Thanks, --David > -----Original Message----- > From: Julian Satran [mailto:Julian_Satran@il.ibm.com] > Sent: Wednesday, July 10, 2002 12:00 AM > To: Black_David@emc.com > Cc: ips@ece.cmu.edu; John Hufferd; owner-ips@ece.cmu.edu > Subject: Re: iSCSI: editorial rewrite not needed > > > > David, > > Swapping 5 and 6 is not a major issue. However I have to object to the > recovery overview. > It is already contained in 6 itself and in 2. > > And I have to stand by John's comment about the lateness of > your comments. > It is disappointing that you got to this that late - and most of your > comments refer to text that was there > for a long time. > > Julo > > > > > > > > Black_David@emc.c > > > om To: John > Hufferd/San Jose/IBM@IBMUS > > Sent by: cc: > ips@ece.cmu.edu > > owner-ips@ece.cmu Subject: > iSCSI: editorial rewrite not needed > > .edu > > > > > > > > > 07/09/2002 09:44 > > > AM > > > Please respond to > > > Black_David > > > > > > > > > > > > John, > > My original text was: > > Global Editorial comment: Both the login (4) and error handling (6) > sections > feel like one of those old Adventure mazes of twisty little > passages - all > the > details seem to be there, for the most part they're correct, > but it's very > hard > to get the proverbial "big picture" of how everything fits > together, in > terms > of how the various mechanisms work with each other and how > they accomplish > the overall functionality. Both of these could use overview sections > describing > how the functionality breaks down into the pieces described in the > subsections > and how they fit together. Swapping the order of Sections 5 > and 6 would > also > be a good idea so that the discussion of Error Handling and > Recovery comes > before the state machine descriptions that contain a lot of > the details of > how errors are handled. For error handling, moving Section > 6.13 to the > front of Section 6 would help organize the Section better, > and care should > be > taken to define or replace terms like "restart login" and > "recovery R2T" > that are currently used without definitions. > > > I disagree with the editorial rewrite, especially at this > late state. If > > they were important that should have been brought up earlier. > > I fail to see how you got from my original text whose primary > request was > for "overview sections describing ..." to "editorial > rewrite", so I think > you're seriously over-reacting. Concerns about comprehensibility have > been brought up on the list in the past. > > > We should > > not be discussing editorial style, but whether we have correctly > specified > > the protocol. > > This isn't about "editorial style", but rather whether the > specification > is comprehensible to an implementer who picks it up from > scratch without > the benefit of this group's email discussions, short term memory, etc. > > > We have already changed it a couple of times, and you are > > now wanting it changed again. This is a very big spec, and > each time we > > make changes to pretty up the document, the more that is needed, and > > someone else has another preference. > > If the spec has problems, Working Group Last Call is the point in > time to find and fix them, and if that takes serious effort, > c'est la vie. > I'm prepared to listen to arguments that the spec is sufficiently > comprehensible as to need no editorial changes, but I'm not > inclined to > assign them a great deal of credibility at this juncture. > > > It is already better then most of the > > other IETF specs. I think this causes a needless delay. > > I disagree and take exception to the view that iSCSI > is needlessly being held to a higher standard. The need for a > comprehensible spec is real, and that is not a higher standard > than other IETF specs are generally held to, although there are > some that have gotten away - IKE/ISAKMP and the related keying > portions of IPsec are an example that we are unfortunately > familiar with. It should not take an iSCSI guru with a secret > decoder ring to unscramble how the protocol works even if all > the interacting pieces are correctly specified somewhere in the > document. > > On further reflection, I think that an overview section on error > handling in the current Section 6 plus swapping the order of Section 5 > and Section 6 probably removes the need to tease apart the initiator > and target state machine specifications in the current Section 5 > (my comments E.80 and E.81). That should reduce the amount of work > required provided that the overview text for error handling is well- > written. > > 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 > --------------------------------------------------- > > > > --=_alternative 00505EF4C2256BF3_= Content-Type: text/html; charset="us-ascii"
David,

I don't want to spend time o n the agenda either. I hope however that you might want to set you priorities
to include work in this group.
The complaints where not only about the lateness of the comments but  also about their classification.

Julo


Black_David@emc.com

07/11/2002 07:35 AM
Please respond to Black_David

       
        To:        Julian Satran/Haifa/IBM@IBMIL
        cc:        ips@ece.cmu.edu
        Subject:        RE: iSCSI: editorial rewrite not needed

       


Julian,

This complaining about lateness of comments really needs to stop.
WG Last Call is about gathering up any and all comments on the
spec, and the timing of comments is whatever happens.  I would
have liked to have been able to get my comments in much earlier
also, but life is what happens while one is busy making other plans ...

As for the overview sections for both error recovery and login -
it is still my view that both the Current Sections 4 and 6 need them
(if there's text that can be moved down from Section 2 to help accomplish
this for error recovery, that's fine).  The fact that the structural
issues in these sections that make them hard to understand may have been
there for a long time is not a good reason to avoid correcting them.

I'd really rather not have to spend Yokohama agenda time on editorial
issues like these, but if you insist ...

Thanks,
--David

> -----Original Message-----
> From: Julian Satran [mailto:Julian_Satran@il.ibm.com]
> Sent: Wednesday, July 10, 2002 12:00 AM
> To: Black_David@emc.com
> Cc: ips@ece.cmu.edu; John Hufferd; owner-ips@ece.cmu.edu
> Subject: Re: iSCSI: editorial rewrite not needed
>
>
>
> David,
>
> Swapping 5 and 6 is not a major issue. However I have to object to the
> recovery overview.
> It is already contained in 6 itself and in 2.
>
> And I have to stand by John's comment about the lateness of
> your comments.
> It is disappointing that you got to this that late - and most of your
> comments refer to text that was there
> for a long time.
>
> Julo
>
>
>
>
>                                                              
>                                                              
>                
>                       Black_David@emc.c                      
>                                                              
>                
>                       om                       To:       John
> Hufferd/San Jose/IBM@IBMUS                                    
>                
>                       Sent by:                 cc:      
> ips@ece.cmu.edu                                              
>                      
>                       owner-ips@ece.cmu        Subject:  
> iSCSI: editorial rewrite not needed                          
>                      
>                       .edu                                    
>                                                              
>                
>                                                              
>                                                              
>                
>                                                              
>                                                              
>                
>                       07/09/2002 09:44                        
>                                                              
>                
>                       AM                                      
>                                                              
>                
>                       Please respond to                      
>                                                              
>                
>                       Black_David                            
>                                                              
>                
>                                                              
>                                                              
>                
>                                                              
>                                                              
>                
>
>
>
> John,
>
> My original text was:
>
> Global Editorial comment: Both the login (4) and error handling (6)
> sections
> feel like one of those old Adventure mazes of twisty little
> passages - all
> the
> details seem to be there, for the most part they're correct,
> but it's very
> hard
> to get the proverbial "big picture" of how everything fits
> together, in
> terms
> of how the various mechanisms work with each other and how
> they accomplish
> the overall functionality.  Both of these could use overview sections
> describing
> how the functionality breaks down into the pieces described in the
> subsections
> and how they fit together.  Swapping the order of Sections 5
> and 6 would
> also
> be a good idea so that the discussion of Error Handling and
> Recovery comes
> before the state machine descriptions that contain a lot of
> the details of
> how errors are handled.  For error handling, moving Section
> 6.13 to the
> front of Section 6 would help organize the Section better,
> and care should
> be
> taken to define or replace terms like "restart login" and
> "recovery R2T"
> that are currently used without definitions.
>
> > I disagree with the editorial rewrite, especially at this
> late state.  If
> > they were important that should have been brought up earlier.
>
> I fail to see how you got from my original text whose primary
> request was
> for "overview sections describing ..." to "editorial
> rewrite", so I think
> you're seriously over-reacting.  Concerns about comprehensibility have
> been brought up on the list in the past.
>
> > We should
> > not be discussing editorial style, but whether we have correctly
> specified
> > the protocol.
>
> This isn't about "editorial style", but rather whether the
> specification
> is comprehensible to an implementer who picks it up from
> scratch without
> the benefit of this group's email discussions, short term memory, etc.
>
> > We have already changed it a couple of times, and you are
> > now wanting it changed again.  This is a very big spec, and
> each time we
> > make changes to pretty up the document, the more that is needed, and
> > someone else has another preference.
>
> If the spec has problems, Working Group Last Call is the point in
> time to find and fix them, and if that takes serious effort,
> c'est la vie.
> I'm prepared to listen to arguments that the spec is sufficiently
> comprehensible as to need no editorial changes, but I'm not
> inclined to
> assign them a great deal of credibility at this juncture.
>
> > It is already better then most of the
> > other IETF specs.  I think this causes a needless delay.
>
> I disagree and take exception to the view that iSCSI
> is needlessly being held to a higher standard.  The need for a
> comprehensible spec is real, and that is not a higher standard
> than other IETF specs are generally held to, although there are
> some that have gotten away - IKE/ISAKMP and the related keying
> portions of IPsec are an example that we are unfortunately
> familiar with.  It should not take an iSCSI guru with a secret
> decoder ring to unscramble how the protocol works even if all
> the interacting pieces are correctly specified somewhere in the
> document.
>
> On further reflection, I think that an overview section on error
> handling in the current Section 6 plus swapping the order of Section 5
> and Section 6 probably removes the need to tease apart the initiator
> and target state machine specifications in the current Section 5
> (my comments E.80 and E.81).  That should reduce the amount of work
> required provided that the overview text for error handling is well-
> written.
>
> 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
> ---------------------------------------------------
>
>
>
>


--=_alternative 00505EF4C2256BF3_=-- From owner-ips@ece.cmu.edu Thu Jul 11 12:02:10 2002 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA22623 for ; Thu, 11 Jul 2002 12:02:09 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id g6BFU9811924 for ips-outgoing; Thu, 11 Jul 2002 11:30:09 -0400 (EDT) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from emulex.emulex.com (emulex.emulex.com [138.239.112.1]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id g6BFU7X11917 for ; Thu, 11 Jul 2002 11:30:07 -0400 (EDT) Received: from xbl.ad.emulex.com (xbl.ma.emulex.com [172.16.12.11]) by emulex.emulex.com (8.9.1a/8.9.1) with ESMTP id IAA00997; Thu, 11 Jul 2002 08:29:50 -0700 (PDT) Received: by xbl.ad.emulex.com with Internet Mail Service (5.5.2653.19) id ; Thu, 11 Jul 2002 11:30:01 -0400 Message-ID: <3356669BBE90C448AD4645C843E2BF28D74C3F@xbl.ad.emulex.com> From: "Nicolson, Alex" To: "'Black_David@emc.com'" , Julian_Satran@il.ibm.com Cc: ips@ece.cmu.edu Subject: RE: iSCSI: DLB's [T.6] 2.3 iSCSI Session Types Date: Thu, 11 Jul 2002 11:30:00 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-ips@ece.cmu.edu Precedence: bulk I would like to see Async Message supporteed. Alex Nicolson Emulex Corporation -----Original Message----- From: Black_David@emc.com [mailto:Black_David@emc.com] Sent: Thursday, July 11, 2002 1:01 AM To: Julian_Satran@il.ibm.com Cc: ips@ece.cmu.edu Subject: RE: iSCSI: DLB's [T.6] 2.3 iSCSI Session Types Julian > I can agree with MUST but I will resist adding any notification. > > It is just the wrong thing to do. I don't care - getting to a MUST with a list of allowed PDUs that forbids all others from the current MAY that allows everything is what matters to me. At the moment, I've only seen Ayman ask for Async Message to be allowed on discovery sessions - does anyone else want to see that PDU allowed on discovery sessions? 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 --------------------------------------------------- From owner-ips@ece.cmu.edu Thu Jul 11 12:09:31 2002 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA23028 for ; Thu, 11 Jul 2002 12:09:30 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id g6BG03K14133 for ips-outgoing; Thu, 11 Jul 2002 12:00:03 -0400 (EDT) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from flamingo.mail.pas.earthlink.net (flamingo.mail.pas.earthlink.net [207.217.120.232]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id g6BG01X14125 for ; Thu, 11 Jul 2002 12:00:01 -0400 (EDT) Received: from 1cust128.tnt3.colorado-springs.co.da.uu.net ([67.234.189.128] helo=SERVO) by flamingo.mail.pas.earthlink.net with esmtp (Exim 3.33 #1) id 17SgLa-0005Vu-00; Thu, 11 Jul 2002 08:59:15 -0700 Message-Id: <4.2.0.58.20020711094323.00a609c0@delos.delos.com> X-Sender: reames@delos.delos.com (Unverified) X-Mailer: QUALCOMM Windows Eudora Pro Version 4.2.0.58 Date: Thu, 11 Jul 2002 09:57:55 -0600 To: "KRUEGER,MARJORIE (HP-Roseville,ex1)" , "'Black_David@emc.com'" , ips@ece.cmu.edu From: Steve Reames Subject: RE: iSCSI: DLB [T.31] ErrorRecoveryLevel 0.5 In-Reply-To: <6BD67FFB937FD411A04F00D0B74FE87805CCF6C2@xrose06.rose.hp.c om> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-ips@ece.cmu.edu Precedence: bulk Marjorie, Let me explain my thoughts, and maybe you or the list can tell me if I'm way off base. Suppose I'm an initiator, and both the target and I have negotiated ErrorRecoveryLevel 0. If I lose an incoming PDU, in theory I should just log out. But maybe, for some simple cases, I've added code to attempt to recover. I take a guess that maybe the target also can recover from simple errors. I throw a SNACK at the target and attempt to recover the lost PDU. There are two possible results: either it works, or I get a Reject PDU back from the target essentially saying it doesn't support SNACK. In the case of a Reject PDU, I log out, which is what I would have done anyway, so I haven't lost anything. If I recover, then hooray! What I'm hoping is that ErrrorRecoveryLevel 0 is not supposed to be interpreted as "not allowed to attempt recovery." My understanding (which may be wrong) is that when the target declares ErrorRecoveryLevel 0 it may or may not support error recovery for some simple types of errors, but if it declares ErrorRecoveryLevel 1, then it has committed to me (the initiator) that it will recover. My original observation on David's comment [T.31] was that I didn't want language that *forbids* the initiator from at least making an effort at error recovery, even at ErrorRecoverLevel 0. Thanks, -Steve Reames --------------------------------------------------------------------------- At 05:13 PM 7/10/2002 -0700, KRUEGER,MARJORIE (HP-Roseville,ex1) wrote: >David, >I don't understand what you are aquiescing to? It seems to me that what >Steve is proposing is a violation of the protocol - there is no way to >negotiate "level 0 + SNACK", therefore as Mallikarjun pointed out, it >wouldn't work. If you've negotiated error level 0, the remote end of this >session won't support SNACK (or shouldn't). This sort of interpretation >would create an interoperability (not to mention testing) nightmare - that's >why the error recover levels were defined in the first place. I think your >original comment is valid. > >Marjorie Krueger >Networked Storage Architecture >Networked Storage Solutions Org. >Hewlett-Packard > > > -----Original Message----- > > From: Black_David@emc.com [mailto:Black_David@emc.com] > > Sent: Wednesday, July 10, 2002 12:57 AM > > To: reames@diskdrive.com; ips@ece.cmu.edu > > Subject: RE: iSCSI: DLB [T.31] > > > > > > Steve, > > > >> From DLB's comments: > >> > >>>[T.31] 9.16.1 Type > >>> > >>> An iSCSI target that does not support recovery within connection MAY > >>> reject the status SNACK with a Reject PDU. If the target supports > >>> recovery within connection, it MAY reject the SNACK after which it > >>> MUST issue an Asynchronous Message PDU with an iSCSI event that indi- > >>> cates "Request Logout". > >>> > >>> This should be conditioned on the operational ErrorRecoveryLevel of the > >>> session, not whether the target supports recovery within connection. > >> > >> I would prefer that this not be conditioned on the ErrorRecoveryLevel. If > >> I am writing code, I may choose to support recovery-within-connection, >but > >> not all the features that would be required to move me up to > >> ErrorRecoveryLevel 1. I would like SNACK and Reject PDUs to work properly > > >> for my code, even though it is technically only "ErrorRecoveryLevel 0.5". > >> As I read it, changing the wording would allow the target to ignore > >> my improved error recovery efforts unless I have a full >ErrorRecoveryLevel 1 > >> implementation. David, I doubt that is what you intended, so maybe you > >> want to word it a little differently. > > > > Actually, it was what I intended when I made that comment, > > BUT, I had not considered the scenario you describe above ... > > and so, I now agree with > > you. Therefore I'll withdraw my [T.31] comment provided that the > > possibility of multiple "ErrorRecoveryLevel 0.5" levels of support is > > described in the overview section to be added on error recovery. > > > > 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 > > --------------------------------------------------- > > From owner-ips@ece.cmu.edu Thu Jul 11 12:24:16 2002 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA23835 for ; Thu, 11 Jul 2002 12:24:16 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id g6BG86m14759 for ips-outgoing; Thu, 11 Jul 2002 12:08:06 -0400 (EDT) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from e1.ny.us.ibm.com (e1.ny.us.ibm.com [32.97.182.101]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id g6BG85X14753 for ; Thu, 11 Jul 2002 12:08:05 -0400 (EDT) Received: from northrelay01.pok.ibm.com (northrelay01.pok.ibm.com [9.56.224.149]) by e1.ny.us.ibm.com (8.12.2/8.12.2) with ESMTP id g6BG7kg5145230; Thu, 11 Jul 2002 12:07:48 -0400 Received: from d03nm014.boulder.ibm.com (avpilot.boulder.ibm.com [9.17.203.135]) by northrelay01.pok.ibm.com (8.11.1m3/NCO/VER6.1) with ESMTP id g6BG7gl27610; Thu, 11 Jul 2002 12:07:42 -0400 X-Priority: 1 (High) Importance: Normal Subject: Re: iSCSI: DLB's [T.6] 2.3 iSCSI Session Types To: ips@ece.cmu.edu Cc: Mark Bakke , Black_David@emc.com, "Julian Satran" , "Prasenjit Sarkar" X-Mailer: Lotus Notes Release 5.0.7 March 21, 2001 Message-ID: From: "John Hufferd" Date: Thu, 11 Jul 2002 09:04:55 -0700 X-MIMETrack: Serialize by Router on D03NM014/03/M/IBM(Release 5.0.10 |March 22, 2002) at 07/11/2002 10:07:44 AM MIME-Version: 1.0 Content-type: text/plain; charset=us-ascii Sender: owner-ips@ece.cmu.edu Precedence: bulk I also believe that those extended discovery functions belong in SLP and iSNS, not in extending the Discovery Session. The Discovery Session was intended for the simple lower end iSCSI network, that did not have SLP or iSNS. And in that end of the market there is no reason to have long lived Discovery sessions. Also this will cause vendors to invent ways to work with the base discovery session, that were unintended and thus cause additional problems, and not focus on getting interoperable support for SLP and iSNS. Each of our approaches, "discovery sessions", SLP, and iSNS, generally cover different network markets, and this segmentation is rather easy to explain. I would prefer to continue this focus, or we will confuse the market and ourselves and never be interoperable. . . . John L. Hufferd Senior Technical Staff Member (STSM) IBM/SSG San Jose Ca Main Office (408) 256-0403, Tie: 276-0403, eFax: (408) 904-4688 Home Office (408) 997-6136, Cell: (408) 499-9702 Internet address: hufferd@us.ibm.com Prasenjit Sarkar/Almaden/IBM@IBMUS@ece.cmu.edu on 07/11/2002 08:15:38 AM Sent by: owner-ips@ece.cmu.edu To: Mark Bakke cc: Black_David@emc.com, ips@ece.cmu.edu, Julian Satran/Haifa/IBM@IBMIL, owner-ips@ece.cmu.edu Subject: Re: iSCSI: DLB's [T.6] 2.3 iSCSI Session Types I'm not sure what Mark means by "we", but I am opposed to any dynamic discovery mechanisms for SendTargets because of my belief that these mechanisms does not belong here. Therefore I vote against Noop and Async messages, Sincerely, Prasenjit Sarkar Research Staff Member IBM Almaden Research San Jose Mark Bakke cc: Julian Satran/Haifa/IBM@IBMIL, ips@ece.cmu.edu Sent by: Subject: Re: iSCSI: DLB's [T.6] 2.3 iSCSI Session Types owner-ips@ece.cmu .edu 07/11/2002 08:21 AM Actually, we want to be able to send Async Message and Noop In from the target, and allow the initiator to send Noop Out, since these are more in the iSCSI session maintenance category of messages. There's definitely no reason to allow Scsi Command / Response, Task Management Command / Response, Data In/Out, Snack, and R2T on a discovery session. -- Mark Black_David@emc.com wrote: > > Julian > > > I can agree with MUST but I will resist adding any notification. > > > > It is just the wrong thing to do. > > I don't care - getting to a MUST with a list of allowed PDUs that > forbids all others from the current MAY that allows everything is > what matters to me. > > At the moment, I've only seen Ayman ask for Async Message to be > allowed on discovery sessions - does anyone else want to see that > PDU allowed on discovery sessions? > > 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 > --------------------------------------------------- -- Mark A. Bakke Cisco Systems mbakke@cisco.com 763.398.1054 From owner-ips@ece.cmu.edu Thu Jul 11 13:16:29 2002 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA26301 for ; Thu, 11 Jul 2002 13:16:29 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id g6BGiTu17193 for ips-outgoing; Thu, 11 Jul 2002 12:44:29 -0400 (EDT) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from palrel11.hp.com (palrel11.hp.com [156.153.255.246]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id g6BGiQX17187 for ; Thu, 11 Jul 2002 12:44:27 -0400 (EDT) Received: from xparelay1.corp.hp.com (xparelay1.corp.hp.com [15.58.136.173]) by palrel11.hp.com (Postfix) with ESMTP id 42FB9600F0A for ; Thu, 11 Jul 2002 09:44:26 -0700 (PDT) Received: from xpabh4.corp.hp.com (xpabh4.corp.hp.com [15.58.136.1]) by xparelay1.corp.hp.com (Postfix) with ESMTP id 39A38E002E2 for ; Thu, 11 Jul 2002 09:44:26 -0700 (PDT) Received: by xpabh4.corp.hp.com with Internet Mail Service (5.5.2655.55) id <32DCJCH0>; Thu, 11 Jul 2002 09:44:26 -0700 Message-ID: <6BD67FFB937FD411A04F00D0B74FE87805CCF6C7@xrose06.rose.hp.com> From: "KRUEGER,MARJORIE (HP-Roseville,ex1)" To: "Ips Reflector (E-mail)" Subject: RE: iSCSI: DLB's [T.6] 2.3 iSCSI Session Types Date: Thu, 11 Jul 2002 09:44:19 -0700 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2655.55) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-ips@ece.cmu.edu Precedence: bulk This "voting" is invalid in the absence of technical debate, and this issue had sufficient debate and was closed long ago - the decision was "no support for long lived discovery sessions". It's disturbing that this is brought up again as if no agreement was reached. I refer you to the attached email. Marjorie Krueger Networked Storage Architecture Networked Storage Solutions Org. Hewlett-Packard > -----Original Message----- > From: Kaladhar Voruganti [mailto:kaladhar@us.ibm.com] > Sent: Tuesday, January 29, 2002 7:17 AM > To: ips@ece.cmu.edu > Subject: iSCSI: Discovery Session Functionality > > > > > This note describes the Naming and Discovery teams's current > resolution regarding the use of > NOPs and Asynch messages in the discovery session: > > There was no agreement on the need or appropriateness of this requirement. > So the general concensus from the Naming and Discovery team, was not to > add NOPs or any other commands to the Discovery Session. It will be left > as only SendTargets can be sent during the Discovery Session. > > Kaladhar Voruganti From owner-ips@ece.cmu.edu Thu Jul 11 14:00:36 2002 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA28506 for ; Thu, 11 Jul 2002 14:00:36 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id g6BHYMC20739 for ips-outgoing; Thu, 11 Jul 2002 13:34:22 -0400 (EDT) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from e2.ny.us.ibm.com (e2.ny.us.ibm.com [32.97.182.102]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id g6BHYKX20735 for ; Thu, 11 Jul 2002 13:34:21 -0400 (EDT) Received: from northrelay01.pok.ibm.com (northrelay01.pok.ibm.com [9.56.224.149]) by e2.ny.us.ibm.com (8.12.2/8.12.2) with ESMTP id g6BHYFe8055956; Thu, 11 Jul 2002 13:34:15 -0400 Received: from d03nm014.boulder.ibm.com (avpilot.boulder.ibm.com [9.17.203.135]) by northrelay01.pok.ibm.com (8.11.1m3/NCO/VER6.1) with ESMTP id g6BHY9l112722; Thu, 11 Jul 2002 13:34:09 -0400 X-Priority: 1 (High) Importance: Normal Subject: RE: iSCSI: DLB's [T.6] 2.3 iSCSI Session Types To: "Ips Reflector (E-mail)" Cc: "KRUEGER,MARJORIE (HP-Roseville,ex1)" X-Mailer: Lotus Notes Release 5.0.7 March 21, 2001 Message-ID: From: "John Hufferd" Date: Thu, 11 Jul 2002 10:31:23 -0700 X-MIMETrack: Serialize by Router on D03NM014/03/M/IBM(Release 5.0.10 |March 22, 2002) at 07/11/2002 11:34:10 AM MIME-Version: 1.0 Content-type: text/plain; charset=us-ascii Sender: owner-ips@ece.cmu.edu Precedence: bulk Marjorie is, in my opinion, correct! . . . John L. Hufferd Senior Technical Staff Member (STSM) IBM/SSG San Jose Ca Main Office (408) 256-0403, Tie: 276-0403, eFax: (408) 904-4688 Home Office (408) 997-6136, Cell: (408) 499-9702 Internet address: hufferd@us.ibm.com "KRUEGER,MARJORIE (HP-Roseville,ex1)" @ece.cmu.edu on 07/11/2002 09:44:19 AM Sent by: owner-ips@ece.cmu.edu To: "Ips Reflector (E-mail)" cc: Subject: RE: iSCSI: DLB's [T.6] 2.3 iSCSI Session Types This "voting" is invalid in the absence of technical debate, and this issue had sufficient debate and was closed long ago - the decision was "no support for long lived discovery sessions". It's disturbing that this is brought up again as if no agreement was reached. I refer you to the attached email. Marjorie Krueger Networked Storage Architecture Networked Storage Solutions Org. Hewlett-Packard > -----Original Message----- > From: Kaladhar Voruganti [mailto:kaladhar@us.ibm.com] > Sent: Tuesday, January 29, 2002 7:17 AM > To: ips@ece.cmu.edu > Subject: iSCSI: Discovery Session Functionality > > > > > This note describes the Naming and Discovery teams's current > resolution regarding the use of > NOPs and Asynch messages in the discovery session: > > There was no agreement on the need or appropriateness of this requirement. > So the general concensus from the Naming and Discovery team, was not to > add NOPs or any other commands to the Discovery Session. It will be left > as only SendTargets can be sent during the Discovery Session. > > Kaladhar Voruganti From owner-ips@ece.cmu.edu Thu Jul 11 14:04:24 2002 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA28660 for ; Thu, 11 Jul 2002 14:04:23 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id g6BHQOv20129 for ips-outgoing; Thu, 11 Jul 2002 13:26:24 -0400 (EDT) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from atlrel9.hp.com (atlrel9.hp.com [156.153.255.214]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id g6BHQMX20121 for ; Thu, 11 Jul 2002 13:26:22 -0400 (EDT) Received: from core.rose.hp.com (core.rose.hp.com [15.43.208.100]) by atlrel9.hp.com (Postfix) with ESMTP id 94E22E00FEA; Thu, 11 Jul 2002 13:26:17 -0400 (EDT) Received: from swathi (swathi.rose.hp.com [15.43.213.237]) by core.rose.hp.com with SMTP (8.9.3 (PHNE_22672)/8.8.6 SMKit7.02) id KAA18707; Thu, 11 Jul 2002 10:28:08 -0700 (PDT) Message-ID: <003301c22900$10081860$edd52b0f@rose.hp.com> From: "Mallikarjun C." To: "Julian Satran" Cc: , , , References: Subject: Re: iSCSI: draft vs. 14 typos, suggestion, questions Date: Thu, 11 Jul 2002 10:26:15 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 8bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2600.0000 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 Sender: owner-ips@ece.cmu.edu Precedence: bulk Content-Transfer-Encoding: 8bit Julian, >Mallikarjun, > >We decided early one that we don't want to touch the notion of a task set > because of the mess we are going to have to handle with TST=0. >What has changed? Nothing, what I propose below is consistent with that desire. Unless we have to use the term "task set" (as in defining Clear Task Set), there's no need to invoke the SCSI-reserved term - simply because iSCSI doesn't know the current TST status in the SCSI layer. The change proposed below takes one usage out, and defines the action in iSCSI-terms (tasks with allegiance). Thanks. -- Mallikarjun Mallikarjun Chadalapaka Networked Storage Architecture Network Storage Solutions Hewlett-Packard MS 5668 Roseville CA 95747 cbm@rose.hp.com "Mallikarjun C." Sent by: owner-ips@ece.cmu.edu 07/11/2002 02:38 AM Please respond to "Mallikarjun C." To: "Julian Satran (Actcom)" , , cc: , Subject: Re: iSCSI: draft vs. 14 typos, suggestion, questions Sorry, I'm catching up late on email.... I see that the latest wording on this is - When the session timeout (the connection state timeout for the last failed connection) happens on the target, it takes the following actions: - Resets or closes the TCP connections (closes the session). - Aborts all Tasks in the task set associated with the session. I think the second bullet is incorrect. While the previous wording had the issue that Pat identified (that there may be one task set for each LU the session can get to), the new wording still has that issue and in addition, also implies that all tasks in the task set need to be terminated. However, a LU may maintain only one task set for multiple initiators (if TST=0 in control mode page) in which case, the current wording implies that all tasks from other initiators need to be terminated as well on one session timeout - which is not intended. I am beginning to think that the notion of "task set" is beyond iSCSI and it's best not to refer to it here. I suggest the following text instead - When the session timeout (section 4.3.5) happens on the target, it takes the following actions: - Resets or closes the TCP connections (closes the session). - Terminates all active tasks that were allegiant to the connection(s) that constituted the session. Thanks. -- Mallikarjun Mallikarjun Chadalapaka Networked Storage Architecture Network Storage Solutions Hewlett-Packard MS 5668 Roseville CA 95747 cbm@rose.hp.com ----- Original Message ----- From: "Julian Satran (Actcom)" To: ; Cc: ; Sent: Thursday, July 04, 2002 9:08 PM Subject: Re: iSCSI: draft vs. 14 typos, suggestion, questions > I will do the text change (I hope it makes it easier for at least one reader > is not worse for anybody else). > The reason why we choose the wording was that SAM associates the task set > with an initiator by the session is wording is equivalent. > > Julo > ----- Original Message ----- > From: > To: ; > Cc: ; > Sent: Wednesday, July 03, 2002 9:38 PM > Subject: RE: iSCSI: draft vs. 14 typos, suggestion, questions > > > > See comment below. Pat > > -----Original Message----- > > From: Julian Satran [mailto:Julian_Satran@il.ibm.com] > > Sent: Wednesday, July 03, 2002 9:20 AM > > To: Tomá? Bartu?ek > > Cc: ips@ece.cmu.edu; ivan.pavelka@s3group.com > > Subject: Re: iSCSI: draft vs. 14 typos, suggestion, questions > > > > > > > > *** Section 6.11 : QUESTION > > Draft says: > > When the session timeout (the connection state timeout for the last > > failed connection) happens on the target, it takes the following > > actions: > > > > - Resets or closes the TCP connections (closes the session). > > - Aborts all Tasks in the task set for the corresponding initi- > > ator. > > > > What does the "corresponding initiator" mean? We think (:-)), that > > there is only one initiator for the session. The only possible > > explanation we see for that paragraph is, that the target should > > abort also other tasks of the same in __other__ sessions, but > > why? > > +++ your interpretation is correct - the statement means the initiator > that "owned" the session. > > Are you suggesting other wording? > > ++++ > > "Aborts all task sets associated with the session" > > (Task set was changed to plural because task set is defined as an I-T-L > nexus and there may be muliple ones in the session. > > > > From owner-ips@ece.cmu.edu Thu Jul 11 14:49:25 2002 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA00893 for ; Thu, 11 Jul 2002 14:49:20 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id g6BICjS23616 for ips-outgoing; Thu, 11 Jul 2002 14:12:45 -0400 (EDT) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from palrel11.hp.com (palrel11.hp.com [156.153.255.246]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id g6BIChX23610 for ; Thu, 11 Jul 2002 14:12:43 -0400 (EDT) Received: from core.rose.hp.com (core.rose.hp.com [15.43.208.100]) by palrel11.hp.com (Postfix) with ESMTP id D8E57600F39; Thu, 11 Jul 2002 11:12:42 -0700 (PDT) Received: from swathi (swathi.rose.hp.com [15.43.213.237]) by core.rose.hp.com with SMTP (8.9.3 (PHNE_22672)/8.8.6 SMKit7.02) id LAA26400; Thu, 11 Jul 2002 11:14:34 -0700 (PDT) Message-ID: <006001c22906$8c0c15a0$edd52b0f@rose.hp.com> From: "Mallikarjun C." To: "Julian Satran" Cc: Subject: iSCSI: need for new data SNACK code? Date: Thu, 11 Jul 2002 11:12:41 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2600.0000 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 Sender: owner-ips@ece.cmu.edu Precedence: bulk Content-Transfer-Encoding: 7bit Julian, I am still unclear about the need to add the new data SNACK code. IMHO, this can only be confusing to both initiator and target implementers - to have two codes that have identical semantics on the wire. The only remaining reason that I see from David (attached below) is that the new code makes the initiator aware that it must request status retransmission. IOW, you're expecting the initiator to be careful enough to use the new code, but somehow you don't expect it to be attentive enough to discard the status PDU unless it had used this new code in an *outbound* SNACK. I completely miss this rationale. I'd buy the new code if it's meant to convey something different to *targets* because they need to process these SNACK PDUs. I see nothing that the targets need to different in satisfying either SNACK. Both parties are aware of the fact of PDU size change, it it had happened. The only two changes from the rev14 text that I propose are that we add: a) The first status PDU must always be dropped after a MaxRecvDataSegmentLength change, if ever a data SNACK is employed for the task. Initiator MUST issue a status SNACK to recover the status PDU (i.e. move the onus of retransmitting status from the target to the initiator). b) A SNACK requesting an R2T, Data or Status PDU for a task MUST be issued before the status for the task is acknowledged. I'll be glad to see any technical reasons that I am overlooking, that require two codes. I'd assume Elizabeth would be the process co-chair, if need be. Regards. -- Mallikarjun Mallikarjun Chadalapaka Networked Storage Architecture Network Storage Solutions Hewlett-Packard MS 5668 Roseville CA 95747 cbm@rose.hp.com 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. From owner-ips@ece.cmu.edu Thu Jul 11 15:58:05 2002 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA03374 for ; Thu, 11 Jul 2002 15:58:00 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id g6BJEN028199 for ips-outgoing; Thu, 11 Jul 2002 15:14:23 -0400 (EDT) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from marantinetworks.com (66-147-154-67.focaldata.net [66.147.154.67] (may be forged)) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id g6BJEJX28178; Thu, 11 Jul 2002 15:14:19 -0400 (EDT) Received: from averma (Sonic.marantinetworks.com [66.147.154.66]) by marantinetworks.com (8.11.2/8.11.2) with ESMTP id g6BJHZh12841; Thu, 11 Jul 2002 12:17:35 -0700 From: "Ambrish Verma" To: "'Julian Satran'" , Cc: , , Subject: CHAP sequence Date: Thu, 11 Jul 2002 12:11:00 -0700 Message-ID: <000501c2290e$b26acd60$3701a8c0@maranti.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0006_01C228D4.06159250" X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.3416 Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 In-Reply-To: Sender: owner-ips@ece.cmu.edu Precedence: bulk This is a multi-part message in MIME format. ------=_NextPart_000_0006_01C228D4.06159250 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit I have a doubt about CHAP sequence explained in draft. Under section 10.5 there is a description like : " The target MUST answer with a Login reject with the "Authentication Failure" status or reply with: CHAP_A= CHAP_I= CHAP_C= Where A is one of A1,A2... that were proposed by the initiator. The initiator MUST continue with: CHAP_N= CHAP_R= " shouldn't it be like: " The target MUST answer with a Login reject with the "Authentication Failure" status or reply with: CHAP_A= CHAP_C= Where A is one of A1,A2... that were proposed by the initiator. The initiator MUST continue with: CHAP_R= " because I think the identifier (CHAP_I) and name CHAP_N) are already an integrated part of CHAP_C and CHAP_R (the way it is explained in RFC1994). Thanks Ambrish ------=_NextPart_000_0006_01C228D4.06159250 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

 

I have a doubt about CHAP sequence explained in draft. Under section 10.5 there is a description like = :

“

   The target MUST answer = with a Login reject with the "Authentication

   Failure" status = or reply with:

 

      CHAP_A=3D<A> CHAP_I=3D<I> = CHAP_C=3D<C>

 

   Where A is one of = A1,A2... that were proposed by the initiator.

 

   The initiator MUST = continue with:

 

  =     CHAP_N=3D<N> CHAP_R=3D<R>

 “

 

 

shouldn’t it be = like:

 

“

   The target MUST answer = with a Login reject with the "Authentication

   Failure" status = or reply with:

 

      CHAP_A=3D<A> CHAP_C=3D<C>

 

   Where A is one of = A1,A2... that were proposed by the initiator.

 

   The initiator MUST = continue with:

 

  =     CHAP_R=3D<R>

“

 

because I think the identifier = (CHAP_I) and name CHAP_N) are already an integrated part of CHAP_C and CHAP_R = (the way it is explained in RFC1994).

 

 

 

Thanks

Ambrish

 

 

 

 

------=_NextPart_000_0006_01C228D4.06159250-- From owner-ips@ece.cmu.edu Thu Jul 11 16:00:58 2002 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA03563 for ; Thu, 11 Jul 2002 16:00:58 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id g6BJr1v01037 for ips-outgoing; Thu, 11 Jul 2002 15:53:01 -0400 (EDT) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from dogwood.cisco.com (dogwood.cisco.com [161.44.11.19]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id g6BJqxX01030 for ; Thu, 11 Jul 2002 15:52:59 -0400 (EDT) Received: from cisco.com (dhcp-161-44-68-217.cisco.com [161.44.68.217]) by dogwood.cisco.com (8.8.6 (PHNE_14041)/CISCO.SERVER.1.2) with ESMTP id PAA10186; Thu, 11 Jul 2002 15:52:22 -0400 (EDT) Message-ID: <3D2DE1F5.E1D77AB1@cisco.com> Date: Thu, 11 Jul 2002 14:52:21 -0500 From: Steve Senum X-Mailer: Mozilla 4.76 [en]C-CCK-MCD (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: Ambrish Verma , ietf-ips Subject: Re: iSCSI: CHAP sequence References: <000501c2290e$b26acd60$3701a8c0@maranti.com> Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit Sender: owner-ips@ece.cmu.edu Precedence: bulk Content-Transfer-Encoding: 8bit Hi Ambrish, The CHAP sequence in the iSCSI draft is correct. In RFC 1994, the CHAP_I and CHAP_C are seperate fields sent in the same PPP PDU, but they are still seperate fields, so in iSCSI Ofer and I decided to send them as seperate iSCSI keys. Regards, Steve Senum I have a doubt about CHAP sequence explained in draft. Under section 10.5 there is a description like : “ The target MUST answer with a Login reject with the "Authentication Failure" status or reply with: CHAP_A= CHAP_I= CHAP_C= Where A is one of A1,A2... that were proposed by the initiator. The initiator MUST continue with: CHAP_N= CHAP_R= “ shouldn’t it be like: “ The target MUST answer with a Login reject with the "Authentication Failure" status or reply with: CHAP_A= CHAP_C= Where A is one of A1,A2... that were proposed by the initiator. The initiator MUST continue with: CHAP_R= “ because I think the identifier (CHAP_I) and name CHAP_N) are already an integrated part of CHAP_C and CHAP_R (the way it is explained in RFC1994). Thanks Ambrish From owner-ips@ece.cmu.edu Thu Jul 11 16:35:19 2002 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA05015 for ; Thu, 11 Jul 2002 16:35:19 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id g6BK2VP01749 for ips-outgoing; Thu, 11 Jul 2002 16:02:31 -0400 (EDT) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from marantinetworks.com (66-147-154-67.focaldata.net [66.147.154.67] (may be forged)) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id g6BK2RX01737 for ; Thu, 11 Jul 2002 16:02:27 -0400 (EDT) Received: from averma (Sonic.marantinetworks.com [66.147.154.66]) by marantinetworks.com (8.11.2/8.11.2) with ESMTP id g6BK5kh15005; Thu, 11 Jul 2002 13:05:46 -0700 From: "Ambrish Verma" To: "'Steve Senum'" , "'ietf-ips'" Subject: RE: iSCSI: CHAP sequence Date: Thu, 11 Jul 2002 12:59:12 -0700 Message-ID: <000c01c22915$6d5b0990$3701a8c0@maranti.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.3416 Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 In-Reply-To: <3D2DE1F5.E1D77AB1@cisco.com> Sender: owner-ips@ece.cmu.edu Precedence: bulk Content-Transfer-Encoding: 7bit Hi Steve, I understand what you are saying, In that case 1) CHAP_N also happens to be the separate field, is it not required to be sent by the authenticator to initiator? 2) If you go to the next statement in which it says like: " The initiator MUST continue with: CHAP_N= CHAP_R= " I think initiator is also required to return "CHAP_I" so shouldn't it be like : " The initiator MUST continue with: CHAP_N= CHAP_R= CHAP_I= " Thanks Ambrish -----Original Message----- From: Steve Senum [mailto:ssenum@cisco.com] Sent: Thursday, July 11, 2002 12:52 PM To: Ambrish Verma; ietf-ips Subject: Re: iSCSI: CHAP sequence Hi Ambrish, The CHAP sequence in the iSCSI draft is correct. In RFC 1994, the CHAP_I and CHAP_C are seperate fields sent in the same PPP PDU, but they are still seperate fields, so in iSCSI Ofer and I decided to send them as seperate iSCSI keys. Regards, Steve Senum I have a doubt about CHAP sequence explained in draft. Under section 10.5 there is a description like : " The target MUST answer with a Login reject with the "Authentication Failure" status or reply with: CHAP_A= CHAP_I= CHAP_C= Where A is one of A1,A2... that were proposed by the initiator. The initiator MUST continue with: CHAP_N= CHAP_R= " shouldn't it be like: " The target MUST answer with a Login reject with the "Authentication Failure" status or reply with: CHAP_A= CHAP_C= Where A is one of A1,A2... that were proposed by the initiator. The initiator MUST continue with: CHAP_R= " because I think the identifier (CHAP_I) and name CHAP_N) are already an integrated part of CHAP_C and CHAP_R (the way it is explained in RFC1994). Thanks Ambrish From owner-ips@ece.cmu.edu Thu Jul 11 16:37:45 2002 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA05157 for ; Thu, 11 Jul 2002 16:37:40 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id g6BK8M602143 for ips-outgoing; Thu, 11 Jul 2002 16:08:22 -0400 (EDT) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from dmz1.silverbacksystems.com (dmz1.silverbacksystems.com [65.172.158.82]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id g6BK8KX02139 for ; Thu, 11 Jul 2002 16:08:20 -0400 (EDT) Received: from ns.silverbacksystems.com (gate-camp-hme0.silverbacksystems.com [65.172.158.93]) by dmz1.silverbacksystems.com (Postfix on SuSE Linux 7.3 (i386)) with ESMTP id A68599BA8 for ; Thu, 11 Jul 2002 13:08:07 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by ns.silverbacksystems.com (Postfix on SuSE Linux eMail Server 3.0) with ESMTP id 62EBE9212 for ; Thu, 11 Jul 2002 13:08:13 -0700 (PDT) Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii" Date: Thu, 11 Jul 2002 13:07:40 -0700 From: "Gwendal Grignou" Importance: Normal Message-ID: <000401c22916$9c27ab60$7810000a@corp.silverbacksystems.com> MIME-Version: 1.0 Received: from ns.silverbacksystems.com (localhost [127.0.0.1]) by localhost (AvMailGate-2.0.0.6) id 13634-151661A1; Thu, 11 Jul 2002 13:07:42 -0700 Received: from GWENDALLAP (GWENDALLAP.corp.silverbacksystems.com [10.0.16.120]) by ns.silverbacksystems.com (Postfix on SuSE Linux eMail Server 3.0) with ESMTP id 6A8B69472 for ; Thu, 11 Jul 2002 13:07:42 -0700 (PDT) Subject: iSCSI: What if MaxCmdSN < ExpCmdSN-1 To: X-AntiVirus: OK! AntiVir MailGate Version 2.0.0.6 at ns.silverbacksystems.com has not found any known virus in this email. X-Mailer: Microsoft Outlook, Build 10.0.2627 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4807.1700 X-MSMail-Priority: Normal X-Priority: 3 (Normal) Sender: owner-ips@ece.cmu.edu Precedence: bulk Content-Transfer-Encoding: 7bit Reading the spec, I think I found conflicting information: In section 2.2.2.1: The target MUST NOT transmit a MaxCmdSN that is less than ExpCmdSN-1. ... -If the PDU MaxCmdSN is less than the PDU ExpCmdSN-1 (in Serial Arithmetic Sense), they are both ignored. How can this happen? If the target follows the iSCSI RFC, it should never send MaxCmdSN less than ExpCmdSN-1. If it happens, doesn't it indicate the PDU is corrupted, or the target is not working properly? Does it make sense then to ignore the problem and continue as is, or the session should be closed? A while back, there were some discussions about if a reserved field not set to 0 is big thing or not, so I wonder if this problem falls in the same category or is more important... Gwendal. From owner-ips@ece.cmu.edu Thu Jul 11 16:45:30 2002 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA05438 for ; Thu, 11 Jul 2002 16:45:30 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id g6BKXQF03846 for ips-outgoing; Thu, 11 Jul 2002 16:33:26 -0400 (EDT) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from dogwood.cisco.com (dogwood.cisco.com [161.44.11.19]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id g6BKXOX03838 for ; Thu, 11 Jul 2002 16:33:24 -0400 (EDT) Received: from cisco.com (dhcp-161-44-68-217.cisco.com [161.44.68.217]) by dogwood.cisco.com (8.8.6 (PHNE_14041)/CISCO.SERVER.1.2) with ESMTP id QAA28894; Thu, 11 Jul 2002 16:32:46 -0400 (EDT) Message-ID: <3D2DEB6E.62FB3CE0@cisco.com> Date: Thu, 11 Jul 2002 15:32:46 -0500 From: Steve Senum X-Mailer: Mozilla 4.76 [en]C-CCK-MCD (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: Ambrish Verma , ietf-ips Subject: Re: iSCSI: CHAP sequence References: <000c01c22915$6d5b0990$3701a8c0@maranti.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ips@ece.cmu.edu Precedence: bulk Content-Transfer-Encoding: 7bit Hi Ambrish, 1) In iSCSI (and probably PPP) the CHAP_N field is only useful for the authenticator (as far as CHAP is concerned), so Ofer and I decided to only send it that way. 2) In PPP the CHAP_I field is used to match responses with requests, since a PPP PDU can be lost over the link and have to be resent. In iSCSI that can't happen, since we use TCP, so Ofer and I decided to only send it with the CHAP_C, since it is needed to calculate the CHAP_R. Keep in mind we are only using the protocol part of PPP CHAP, and not the PPP specific encoding scheme. Regards, Steve Senum Ambrish Verma wrote: > > Hi Steve, > I understand what you are saying, In that case > > 1) CHAP_N also happens to be the separate field, is it not required to > be sent by the authenticator to initiator? > > 2) If you go to the next statement in which it says like: > " > The initiator MUST continue with: > CHAP_N= CHAP_R= > " > > I think initiator is also required to return "CHAP_I" so shouldn't it > be like : > > " > The initiator MUST continue with: > CHAP_N= CHAP_R= CHAP_I= > " > > Thanks > Ambrish > > -----Original Message----- > From: Steve Senum [mailto:ssenum@cisco.com] > Sent: Thursday, July 11, 2002 12:52 PM > To: Ambrish Verma; ietf-ips > Subject: Re: iSCSI: CHAP sequence > > Hi Ambrish, > > The CHAP sequence in the iSCSI draft is correct. > In RFC 1994, the CHAP_I and CHAP_C are seperate > fields sent in the same PPP PDU, but they are > still seperate fields, so in iSCSI Ofer and I > decided to send them as seperate iSCSI keys. > > Regards, > Steve Senum > > I have a doubt about CHAP sequence explained in draft. Under section > 10.5 there > is a description like : > > " > > The target MUST answer with a Login reject with the "Authentication > > Failure" status or reply with: > > > > CHAP_A= CHAP_I= CHAP_C= > > > > Where A is one of A1,A2... that were proposed by the initiator. > > > > The initiator MUST continue with: > > > > CHAP_N= CHAP_R= > > " > > > > > > shouldn't it be like: > > > > " > > The target MUST answer with a Login reject with the "Authentication > > Failure" status or reply with: > > > > CHAP_A= CHAP_C= > > > > Where A is one of A1,A2... that were proposed by the initiator. > > > > The initiator MUST continue with: > > > > CHAP_R= > > " > > > > because I think the identifier (CHAP_I) and name CHAP_N) are already an > integrated part of CHAP_C and CHAP_R (the way it is > explained in RFC1994). > > > > > > > > Thanks > > Ambrish From owner-ips@ece.cmu.edu Thu Jul 11 17:14:17 2002 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA06545 for ; Thu, 11 Jul 2002 17:14:17 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id g6BKiiG04656 for ips-outgoing; Thu, 11 Jul 2002 16:44:44 -0400 (EDT) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from mail1irv.inside.istor.com (host28.istor.com [66.134.214.28]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id g6BKigX04649 for ; Thu, 11 Jul 2002 16:44:42 -0400 (EDT) Subject: Recovery R2T From: Michael Morrison To: iSCSI Content-Type: multipart/alternative; boundary="=-JXxvrxfmRoEmqNVHK+a4" X-Mailer: Ximian Evolution 1.0.8 Date: 11 Jul 2002 13:41:54 -0700 Message-Id: <1026420114.20745.187.camel@jackal.engasic.istor.com> Mime-Version: 1.0 Sender: owner-ips@ece.cmu.edu Precedence: bulk --=-JXxvrxfmRoEmqNVHK+a4 Content-Type: text/plain Content-Transfer-Encoding: 7bit If an initiator sends multiple Data-Out in response to an R2T, and one of the Data-Out in the sequence has a data digest error, can the recovery R2T solicit only the missing data, or must it solicit the whole sequence? I can't find anything in the draft that defines what the contents of a recovery R2T MUST/SHOULD/MAY contain. Thanks Michael Morrison ISTOR Networks 7585 Irvine Center Dr. Ste 250 Irvine Ca. 92618 PGP Key: 74C30155 --=-JXxvrxfmRoEmqNVHK+a4 Content-Type: text/html; charset=utf-8  

If an initiator sends multiple Data-Out in response to an R2T, and one of the Data-Out in the
sequence has a data digest error, can the recovery R2T solicit only the missing data, or must
it solicit the whole sequence?   I can't find anything in the draft that defines what the contents
of a recovery R2T MUST/SHOULD/MAY contain.  


Thanks
Michael Morrison
ISTOR Networks
7585 Irvine Center Dr. Ste 250
Irvine Ca. 92618
PGP Key: 74C30155
--=-JXxvrxfmRoEmqNVHK+a4-- From owner-ips@ece.cmu.edu Thu Jul 11 17:18:21 2002 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA06711 for ; Thu, 11 Jul 2002 17:18:21 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id g6BL6R106157 for ips-outgoing; Thu, 11 Jul 2002 17:06:27 -0400 (EDT) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from palrel12.hp.com (palrel12.hp.com [156.153.255.237]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id g6BL6PX06149 for ; Thu, 11 Jul 2002 17:06:25 -0400 (EDT) Received: from xparelay1.corp.hp.com (xparelay1.corp.hp.com [15.58.136.173]) by palrel12.hp.com (Postfix) with ESMTP id B63CAE00C48; Thu, 11 Jul 2002 14:06:24 -0700 (PDT) Received: from xpabh4.corp.hp.com (xpabh4.corp.hp.com [15.58.136.1]) by xparelay1.corp.hp.com (Postfix) with ESMTP id 873F3E000BB; Thu, 11 Jul 2002 14:06:24 -0700 (PDT) Received: by xpabh4.corp.hp.com with Internet Mail Service (5.5.2655.55) id <32DCJ9LC>; Thu, 11 Jul 2002 14:06:24 -0700 Message-ID: <6BD67FFB937FD411A04F00D0B74FE87805CCF6C8@xrose06.rose.hp.com> From: "KRUEGER,MARJORIE (HP-Roseville,ex1)" To: "'Steve Reames'" , ips@ece.cmu.edu Subject: RE: iSCSI: DLB [T.31] ErrorRecoveryLevel 0.5 Date: Thu, 11 Jul 2002 14:06:21 -0700 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2655.55) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-ips@ece.cmu.edu Precedence: bulk There is nothing in the draft explicitly forbidding the behavior you suggest, but there is no intent to allow it. You have no way of knowing whether "using only a small portion of ERL 1" when ERL 0 was negotiated will cause problems at the target end or not, since it's not a defined "feature" and therefore may have unexpected consequences. IMO, it's bad behavior. If you've added code "to attempt to recover", just implement ERL 1. If you think there should be some interim level of error recovery between 0 and 1, present a compelling argument for it and get it specified in the draft. Otherwise your implementation is behaving in an undefined manner and IMO, that's asking for trouble. It all goes back to the "testing matrix" that's defined by the features outlined in the draft - you are proposing that there's an infinite testing matrix because it's ok to behave in a manner that's not defined, as long as it's not forbidden? Regards, Marjorie > -----Original Message----- > From: Steve Reames [mailto:reames@diskdrive.com] > Sent: Thursday, July 11, 2002 8:58 AM > To: KRUEGER,MARJORIE (HP-Roseville,ex1); 'Black_David@emc.com'; > ips@ece.cmu.edu > Subject: RE: iSCSI: DLB [T.31] ErrorRecoveryLevel 0.5 > > > Marjorie, > Let me explain my thoughts, and maybe you or the > list can tell me > if I'm way off base. > Suppose I'm an initiator, and both the target and I have > negotiated ErrorRecoveryLevel 0. If I lose an incoming PDU, > in theory I > should just log out. But maybe, for some simple cases, I've > added code to > attempt to recover. I take a guess that maybe the target also > can recover > from simple errors. I throw a SNACK at the target and attempt > to recover > the lost PDU. > There are two possible results: either it works, or > I get a Reject > PDU back from the target essentially saying it doesn't > support SNACK. In > the case of a Reject PDU, I log out, which is what I would have done > anyway, so I haven't lost anything. If I recover, then hooray! > What I'm hoping is that ErrrorRecoveryLevel 0 is not > supposed to > be interpreted as "not allowed to attempt recovery." My understanding > (which may be wrong) is that when the target declares > ErrorRecoveryLevel 0 > it may or may not support error recovery for some simple > types of errors, > but if it declares ErrorRecoveryLevel 1, then it has > committed to me (the > initiator) that it will recover. > My original observation on David's comment [T.31] was that I > didn't want language that *forbids* the initiator from at > least making an > effort at error recovery, even at ErrorRecoverLevel 0. > > Thanks, > -Steve Reames > -------------------------------------------------------------- > ------------- > At 05:13 PM 7/10/2002 -0700, KRUEGER,MARJORIE > (HP-Roseville,ex1) wrote: > >David, > >I don't understand what you are aquiescing to? It seems to > me that what > >Steve is proposing is a violation of the protocol - there is > no way to > >negotiate "level 0 + SNACK", therefore as Mallikarjun pointed out, it > >wouldn't work. If you've negotiated error level 0, the > remote end of this > >session won't support SNACK (or shouldn't). This sort of > interpretation > >would create an interoperability (not to mention testing) > nightmare - that's > >why the error recover levels were defined in the first > place. I think your > >original comment is valid. > > > >Marjorie Krueger > >Networked Storage Architecture > >Networked Storage Solutions Org. > >Hewlett-Packard > > > > > -----Original Message----- > > > From: Black_David@emc.com [mailto:Black_David@emc.com] > > > Sent: Wednesday, July 10, 2002 12:57 AM > > > To: reames@diskdrive.com; ips@ece.cmu.edu > > > Subject: RE: iSCSI: DLB [T.31] > > > > > > > > > Steve, > > > > > >> From DLB's comments: > > >> > > >>>[T.31] 9.16.1 Type > > >>> > > >>> An iSCSI target that does not support recovery within > connection MAY > > >>> reject the status SNACK with a Reject PDU. If the > target supports > > >>> recovery within connection, it MAY reject the SNACK > after which it > > >>> MUST issue an Asynchronous Message PDU with an iSCSI > event that indi- > > >>> cates "Request Logout". > > >>> > > >>> This should be conditioned on the operational > ErrorRecoveryLevel of the > > >>> session, not whether the target supports recovery > within connection. > > >> > > >> I would prefer that this not be conditioned on the > ErrorRecoveryLevel. If > > >> I am writing code, I may choose to support > recovery-within-connection, > >but > > >> not all the features that would be required to move me up to > > >> ErrorRecoveryLevel 1. I would like SNACK and Reject PDUs > to work properly > > > > >> for my code, even though it is technically only > "ErrorRecoveryLevel 0.5". > > >> As I read it, changing the wording would allow the > target to ignore > > >> my improved error recovery efforts unless I have a full > >ErrorRecoveryLevel 1 > > >> implementation. David, I doubt that is what you > intended, so maybe you > > >> want to word it a little differently. > > > > > > Actually, it was what I intended when I made that comment, > > > BUT, I had not considered the scenario you describe above ... > > > and so, I now agree with > > > you. Therefore I'll withdraw my [T.31] comment provided that the > > > possibility of multiple "ErrorRecoveryLevel 0.5" levels > of support is > > > described in the overview section to be added on error recovery. > > > > > > 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 > > > --------------------------------------------------- > > > > > From owner-ips@ece.cmu.edu Thu Jul 11 18:08:02 2002 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA08879 for ; Thu, 11 Jul 2002 18:08:02 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id g6BLgU108459 for ips-outgoing; Thu, 11 Jul 2002 17:42:30 -0400 (EDT) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from maho3msx2.isus.emc.com (maho3msx2.isus.emc.com [128.221.11.32]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id g6BLgTX08453 for ; Thu, 11 Jul 2002 17:42:29 -0400 (EDT) Received: by MAHO3MSX2 with Internet Mail Service (5.5.2653.19) id <31WCR92J>; Thu, 11 Jul 2002 17:40:25 -0400 Message-ID: <277DD60FB639D511AC0400B0D068B71E0564C06D@CORPMX14> From: Black_David@emc.com To: cbm@rose.hp.com Cc: ips@ece.cmu.edu Subject: RE: iSCSI: need for new data SNACK code? Date: Thu, 11 Jul 2002 17:40:21 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-ips@ece.cmu.edu Precedence: bulk Mallikarjun, > I am still unclear about the need to add the new data SNACK > code. IMHO, this can only be confusing to both initiator and target > implementers - to have two codes that have identical semantics > on the wire. > > The only remaining reason that I see from David (attached below) > is that the new code makes the initiator aware that it must request > status retransmission. IOW, you're expecting the initiator > to be careful > enough to use the new code, but somehow you don't expect it to be > attentive enough to discard the status PDU unless it had used > this new > code in an *outbound* SNACK. I completely miss this rationale. I disagree with the "careful enough" characterization. The new code provides the initiator with a more robust way to detect resegmentation by requiring the initiator to explicitly ask for it. The initiator can take a simple approach of always starting with the existing Data SNACK code that does not resegment and only using the new code when the non-resegmenting SNACK doesn't work. If the target makes its own choice to resegment, and the initiator doesn't think the target resegmented, there are error scenarios that combine this with corrupt Data PDU headers to cause the initiator to successfully complete a SCSI command that has not delivered all its data (the resegmented PDUs caused the Data PDU count to match the ExpDataSN value in the response that should have been discarded, but wasn't). While these should be rare, their consequences can be catastrophic. > I'd buy the new code if it's meant to convey something different to > *targets* because they need to process these SNACK PDUs. I see > nothing that the targets need to different in satisfying either SNACK. > Both parties are aware of the fact of PDU size change, it > had happened. It is conveying the Initiator's instructions that resegmentation is permitted. I am not comfortable with the last sentence above that assumes that the Initiator and Target will always have identical views of all of the effects of a full feature phase PDU size change - (which is a rare event to begin with, and hence likely to involve code that isn't well exercised/tested). > The only two changes from the rev14 text that I propose are that we add: > > a) The first status PDU must always be dropped after a > MaxRecvDataSegmentLength change, if ever a data SNACK is > employed for the task. When does this obligation to drop the first status PDU expire? I think the Initiator has to mark all commands that are outstanding or become outstanding between the time it starts the negotiation that changes MaxRecvDataSegmentLength and the time that it gets the final Text Response of that negotiation from the target. This requires additional Initiator state per command for something that almost never happens, and if it gets one of these markings wrong, it's vulnerable to failing to deliver all the data for a SCSI command in a compound error situation. An alternative with the new code could involve a single bit per connection that records whether the PDU size was ever changed (if so, retry any failed Data SNACK as a resegmenting Data SNACK). > Initiator MUST issue a status SNACK to recover the > status PDU (i.e. move the onus of retransmitting > status from the target to the initiator). > b) A SNACK requesting an R2T, Data or Status PDU for a task MUST be > issued before the status for the task is acknowledged. I have no problem with these two. > I'll be glad to see any technical reasons that I am > overlooking, that require two codes. See above. This is somewhat analogous to the "if in doubt, negotiate it" principle for login - telling the other side *exactly* what is wanted is more robust than assuming that it will do what is wanted, and in this resegmenting Data SNACK case, there are potentially nasty consequences to an incorrect assumption. Does this make any sense? > I'd assume Elizabeth would be the process co-chair, if need be. Yes. Thanks, --David > 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. From owner-ips@ece.cmu.edu Thu Jul 11 18:09:21 2002 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA08948 for ; Thu, 11 Jul 2002 18:09:21 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id g6BLXse07943 for ips-outgoing; Thu, 11 Jul 2002 17:33:54 -0400 (EDT) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from marantinetworks.com (66-147-154-67.focaldata.net [66.147.154.67] (may be forged)) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id g6BLXoX07933 for ; Thu, 11 Jul 2002 17:33:50 -0400 (EDT) Received: from averma (Sonic.marantinetworks.com [66.147.154.66]) by marantinetworks.com (8.11.2/8.11.2) with ESMTP id g6BLb9h19012; Thu, 11 Jul 2002 14:37:09 -0700 From: "Ambrish Verma" To: "'Steve Senum'" , "'ietf-ips'" Subject: RE: iSCSI: CHAP sequence Date: Thu, 11 Jul 2002 14:30:34 -0700 Message-ID: <000601c22922$3153af30$3701a8c0@maranti.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.3416 Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 In-Reply-To: <3D2DEB6E.62FB3CE0@cisco.com> Sender: owner-ips@ece.cmu.edu Precedence: bulk Content-Transfer-Encoding: 7bit yes now it makes perfect sense... Thanks a lot Ambrish -----Original Message----- From: Steve Senum [mailto:ssenum@cisco.com] Sent: Thursday, July 11, 2002 1:33 PM To: Ambrish Verma; ietf-ips Subject: Re: iSCSI: CHAP sequence Hi Ambrish, 1) In iSCSI (and probably PPP) the CHAP_N field is only useful for the authenticator (as far as CHAP is concerned), so Ofer and I decided to only send it that way. 2) In PPP the CHAP_I field is used to match responses with requests, since a PPP PDU can be lost over the link and have to be resent. In iSCSI that can't happen, since we use TCP, so Ofer and I decided to only send it with the CHAP_C, since it is needed to calculate the CHAP_R. Keep in mind we are only using the protocol part of PPP CHAP, and not the PPP specific encoding scheme. Regards, Steve Senum Ambrish Verma wrote: > > Hi Steve, > I understand what you are saying, In that case > > 1) CHAP_N also happens to be the separate field, is it not required to > be sent by the authenticator to initiator? > > 2) If you go to the next statement in which it says like: > " > The initiator MUST continue with: > CHAP_N= CHAP_R= > " > > I think initiator is also required to return "CHAP_I" so shouldn't it > be like : > > " > The initiator MUST continue with: > CHAP_N= CHAP_R= CHAP_I= > " > > Thanks > Ambrish > > -----Original Message----- > From: Steve Senum [mailto:ssenum@cisco.com] > Sent: Thursday, July 11, 2002 12:52 PM > To: Ambrish Verma; ietf-ips > Subject: Re: iSCSI: CHAP sequence > > Hi Ambrish, > > The CHAP sequence in the iSCSI draft is correct. > In RFC 1994, the CHAP_I and CHAP_C are seperate > fields sent in the same PPP PDU, but they are > still seperate fields, so in iSCSI Ofer and I > decided to send them as seperate iSCSI keys. > > Regards, > Steve Senum > > I have a doubt about CHAP sequence explained in draft. Under section > 10.5 there > is a description like : > > " > > The target MUST answer with a Login reject with the "Authentication > > Failure" status or reply with: > > > > CHAP_A= CHAP_I= CHAP_C= > > > > Where A is one of A1,A2... that were proposed by the initiator. > > > > The initiator MUST continue with: > > > > CHAP_N= CHAP_R= > > " > > > > > > shouldn't it be like: > > > > " > > The target MUST answer with a Login reject with the "Authentication > > Failure" status or reply with: > > > > CHAP_A= CHAP_C= > > > > Where A is one of A1,A2... that were proposed by the initiator. > > > > The initiator MUST continue with: > > > > CHAP_R= > > " > > > > because I think the identifier (CHAP_I) and name CHAP_N) are already an > integrated part of CHAP_C and CHAP_R (the way it is > explained in RFC1994). > > > > > > > > Thanks > > Ambrish From owner-ips@ece.cmu.edu Thu Jul 11 19:29:58 2002 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA13212 for ; Thu, 11 Jul 2002 19:29:57 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id g6BN2Wn13353 for ips-outgoing; Thu, 11 Jul 2002 19:02:32 -0400 (EDT) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from atlrel9.hp.com (atlrel9.hp.com [156.153.255.214]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id g6BN2UX13349 for ; Thu, 11 Jul 2002 19:02:30 -0400 (EDT) Received: from xatlrelay1.atl.hp.com (xatlrelay1.atl.hp.com [15.45.89.190]) by atlrel9.hp.com (Postfix) with ESMTP id 6A26AE013B8; Thu, 11 Jul 2002 19:02:30 -0400 (EDT) Received: from xatlbh2.atl.hp.com (xatlbh2.atl.hp.com [15.45.89.187]) by xatlrelay1.atl.hp.com (Postfix) with ESMTP id 263F611F; Thu, 11 Jul 2002 19:02:28 -0400 (EDT) Received: by xatlbh2.atl.hp.com with Internet Mail Service (5.5.2655.55) id <349LXRZQ>; Thu, 11 Jul 2002 19:02:27 -0400 Message-ID: <6BD67FFB937FD411A04F00D0B74FE87805CCF6CA@xrose06.rose.hp.com> From: "KRUEGER,MARJORIE (HP-Roseville,ex1)" To: "'Black_David@emc.com'" Cc: ips@ece.cmu.edu Subject: RE: iSCSI: need for new data SNACK code? Date: Thu, 11 Jul 2002 19:02:24 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2655.55) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-ips@ece.cmu.edu Precedence: bulk > > I am still unclear about the need to add the new data SNACK > > code. IMHO, this can only be confusing to both initiator > and target > > implementers - to have two codes that have identical semantics > > on the wire. > > > > The only remaining reason that I see from David (attached below) > > is that the new code makes the initiator aware that it must request > > status retransmission. IOW, you're expecting the initiator > > to be careful > > enough to use the new code, but somehow you don't expect it to be > > attentive enough to discard the status PDU unless it had used > > this new > > code in an *outbound* SNACK. I completely miss this rationale. > > I disagree with the "careful enough" characterization. The new code > provides the initiator with a more robust way to detect resegmentation > by requiring the initiator to explicitly ask for it. I don't follow your thinking David - the initiator has *requested* resegmentation via a MaxRecvDataSegmentLength text request. The foolproof way to "detect" that the target is resegmenting is receipt of the target's text response. > The initiator > can take a simple approach of always starting with the existing > Data SNACK code that does not resegment and only using the new code > when the non-resegmenting SNACK doesn't work. You seem to be thinking that an initiator would be sending SNACKs on this connection for the previous segment size immediately after it's requested a MaxRecvDataSegmentLength change? That doesn't make sense to me. The initiator should wait for the target's text response before continuing I/Os on this connection. Thereafter, both ends know that that data sent as a result of a Data SNACK is resegmented and the initiator should send a Status SNACK for any Status PDU's received before the Text Response that were associated with the task that requires issuance of the Data SNACK. Seems pretty simple to me. > If the target makes > its own choice to resegment, and the initiator doesn't think the > target resegmented, there are error scenarios that combine this with > corrupt Data PDU headers to cause the initiator to successfully > complete a SCSI command that has not delivered all its data > (the resegmented PDUs caused the Data PDU count to match the ExpDataSN > value in the response that should have been discarded, but wasn't). > While these should be rare, their consequences can be catastrophic. What do you mean by "if the target makes it's own choice to resegment"? Sounds like a target bug to me. It feels like you're making this look more complicated than it really is. I think this new SNACK code is the wrong thing to do - it feels like adding a new feature with questionable value to provide a questionable "fix" for a questionable problem, and there's not sufficient time left for scrutiny of whether or not it presents a new set of problems. By my assessment, your solution to this problem fails Occam's Razor - if there are two functionally equivalent solutions to a problem, chose the simplest solution. Mallikarjun points out a simple solution that is sufficient to solve the original problem without adding a new PDU type. Regards, Marjorie From owner-ips@ece.cmu.edu Thu Jul 11 20:13:48 2002 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA14913 for ; Thu, 11 Jul 2002 20:13:47 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id g6BNkNh15721 for ips-outgoing; Thu, 11 Jul 2002 19:46:23 -0400 (EDT) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from atlrel9.hp.com (atlrel9.hp.com [156.153.255.214]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id g6BNkLX15713 for ; Thu, 11 Jul 2002 19:46:21 -0400 (EDT) Received: from core.rose.hp.com (core.rose.hp.com [15.43.208.100]) by atlrel9.hp.com (Postfix) with ESMTP id 4D4B1E01438; Thu, 11 Jul 2002 19:46:20 -0400 (EDT) Received: from swathi (swathi.rose.hp.com [15.43.213.237]) by core.rose.hp.com with SMTP (8.9.3 (PHNE_22672)/8.8.6 SMKit7.02) id QAA24876; Thu, 11 Jul 2002 16:48:12 -0700 (PDT) Message-ID: <014a01c22935$2700e210$edd52b0f@rose.hp.com> From: "Mallikarjun C." To: Cc: References: <277DD60FB639D511AC0400B0D068B71E0564C06D@CORPMX14> Subject: Re: iSCSI: need for new data SNACK code? Date: Thu, 11 Jul 2002 16:46:17 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2600.0000 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 Sender: owner-ips@ece.cmu.edu Precedence: bulk Content-Transfer-Encoding: 7bit David, comments in text. > I disagree with the "careful enough" characterization. The new code > provides the initiator with a more robust way to detect resegmentation > by requiring the initiator to explicitly ask for it. The initiator > can take a simple approach of always starting with the existing > Data SNACK code that does not resegment and only using the new code > when the non-resegmenting SNACK doesn't work. That's one approach. So, let's note that you're expecting the target to maintain a "PDU-size-changed" flag for every active task, and expecting it to fail the "regular" data SNACK if the flag is set. Some issues - a) would it really cover the (impossible, IMHO) case you're attempting to cover, in the face of multiple PDU size changes? b) assuming that there indeed is a disconnect b/n the two, what should the target do when a resegmenting data SNACK is received, but there's no PDU size change? I hope you aren't mandating the specific approach. c) this approach costs one additional round-trip delay, where none is necessary (as argued below). d) seems like it would need new Reject code(s) to distinguish a "regular" reject from that of the PDU size change ones. >If the target makes > its own choice to resegment, and the initiator doesn't think the > target resegmented, Now this is beginning to feel more like the option A vs B vs C debate we had a while ago. If the protocol works correctly, both sides would be *completely synchronized* on the fact of PDU size change. There are two options for initiators to deal with this - a) don't issue any data SNACKs while any text negotiation is in progress - wait till the text response is received successfully. OR b) issue a data SNACK regardless, and if the text response (that indicates a PDU size change) arrives before the data burst completes, discard the status PDU, and ask for its retransmission. Option a is what I suggest, and b is for the adventurous sort. >there are error scenarios that combine this with > corrupt Data PDU headers to cause the initiator to successfully > complete a SCSI command that has not delivered all its data > (the resegmented PDUs caused the Data PDU count to match the ExpDataSN > value in the response that should have been discarded, but wasn't). Which is precisely why I'm suggesting that we mandate discarding the status PDU. What am I missing? > While these should be rare, their consequences can be catastrophic. > > It is conveying the Initiator's instructions that resegmentation is > permitted. I am not comfortable with the last sentence above that assumes > that the Initiator and Target will always have identical views of all of > the effects of a full feature phase PDU size change - (which is > a rare event to begin with, and hence likely to involve code that > isn't well exercised/tested). Obviously, I cannot guarantee the lack of bugs in any implementation. But again, let's not attempt to address implementation bugs by protocol means (that's why we picked option A in the A vs B vs C debate I referred to above - see the "reusing ISID for recovery" thread; it's for the same reason we removed the X-bit for connection reinstatement - see the "X-bit in Login" thread). > > > The only two changes from the rev14 text that I propose are that we add: > > > > a) The first status PDU must always be dropped after a > > MaxRecvDataSegmentLength change, if ever a data SNACK is > > employed for the task. > > When does this obligation to drop the first status PDU expire? As it says: when the first status PDU is dropped for the task - for each active task during a PDU size change, *and* for which a data SNACK is/was issued. >I think > the Initiator has to mark all commands that are outstanding or become > outstanding between the time it starts the negotiation that changes > MaxRecvDataSegmentLength and the time that it gets the final Text Response > of that negotiation from the target. This requires additional Initiator > state per command for something that almost never happens, and if it > gets one of these markings wrong, Sorry, how is it different from the target getting wrong one of its aforementioned "PDU-size-changed" flags for tasks? I believe that the onus should be on the initiator to do what it takes to do the right recovery - as is the general error recovery philosophy everywhere. Target cannot predict if the initiator would be interested in recovering a particular I/O (regardless of the operational ErrorRecoveryLevel). >it's vulnerable to failing to deliver > all the data for a SCSI command in a compound error situation. An > alternative with the new code could involve a single bit per connection > that records whether the PDU size was ever changed (if so, retry any > failed Data SNACK as a resegmenting Data SNACK). Or, use just "the Data SNACK", if we define only one. I can't see why this optimization needs two data SNACK codes. > > > Initiator MUST issue a status SNACK to recover the > > status PDU (i.e. move the onus of retransmitting > > status from the target to the initiator). > > b) A SNACK requesting an R2T, Data or Status PDU for a task MUST be > > issued before the status for the task is acknowledged. > > I have no problem with these two. > > > I'll be glad to see any technical reasons that I am > > overlooking, that require two codes. > > See above. This is somewhat analogous to the "if in doubt, negotiate > it" principle for login - telling the other side *exactly* what is wanted > is more robust than assuming that it will do what is wanted, and in > this resegmenting Data SNACK case, there are potentially nasty > consequences to an incorrect assumption. Does this make any sense? I see what you're trying to get at. However, IMHO, there is no "assuming" involved here. If the protocol works right, it should do the right thing. Or else, we are in serious trouble despite this change. Regards. -- Mallikarjun Mallikarjun Chadalapaka Networked Storage Architecture Network Storage Solutions Hewlett-Packard MS 5668 Roseville CA 95747 cbm@rose.hp.com From owner-ips@ece.cmu.edu Thu Jul 11 20:15:03 2002 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA14940 for ; Thu, 11 Jul 2002 20:15:03 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id g6BNgHN15506 for ips-outgoing; Thu, 11 Jul 2002 19:42:17 -0400 (EDT) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from lion.ninthwonder.com (lion.ninthwonder.com [151.199.66.147]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id g6BNgFX15501 for ; Thu, 11 Jul 2002 19:42:15 -0400 (EDT) Received: by lion.ninthwonder.com (Postfix, from userid 1021) id 7FCF630706; Thu, 11 Jul 2002 19:42:14 -0400 (EDT) Date: Thu, 11 Jul 2002 16:39:16 -0700 (PDT) From: Bill Studenmund X-X-Sender: To: Julian Satran Cc: , Subject: RE: iSCSI: editorial rewrite not needed In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ips@ece.cmu.edu Precedence: bulk On Thu, 11 Jul 2002, Julian Satran wrote: > David, > > I don't want to spend time o n the agenda either. I hope however that you > might want to set you priorities > to include work in this group. > The complaints where not only about the lateness of the comments but also > about their classification. Julian, I fail to understand your concern about lateness. This is last call. When else should complaints come up? *After* last call??? Many of the things David was asking for are things that really should come up about now, IMHO. Writing summaries & overviews when the material being summarized is still in flux does not seem like a productive exersize. As to their need, I think these changes (swapping sections 5 & 6, and adding summaries) are needed. I think the current draft we have is not intuitive for new readers. I know I've had a hard time figuring everything out over the past four months. I think you do have everything in there, it's just things aren't necessarily where new readers will expect to find them. Take care, Bill From owner-ips@ece.cmu.edu Thu Jul 11 20:59:19 2002 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA16702 for ; Thu, 11 Jul 2002 20:59:18 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id g6C0VRB18012 for ips-outgoing; Thu, 11 Jul 2002 20:31:27 -0400 (EDT) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from msgbas2.cos.agilent.com (msgbas2x.cos.agilent.com [192.25.240.37]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id g6C0VPX18008 for ; Thu, 11 Jul 2002 20:31:26 -0400 (EDT) Received: from msgrel1.cos.agilent.com (msgrel1.cos.agilent.com [130.29.152.77]) by msgbas2.cos.agilent.com (Postfix) with ESMTP id 39B231AE0 for ; Thu, 11 Jul 2002 18:31:25 -0600 (MDT) Received: from acropora.rose.agilent.com (acropora.rose.agilent.com [130.30.179.5]) by msgrel1.cos.agilent.com (Postfix) with ESMTP id B7CA3212 for ; Thu, 11 Jul 2002 18:31:24 -0600 (MDT) Received: (from dbs@localhost) by acropora.rose.agilent.com (8.9.3 (PHNE_18979)/8.9.3 SMKit7.1.0) id RAA26523 for ips@ece.cmu.edu; Thu, 11 Jul 2002 17:29:24 -0700 (PDT) From: Dave Sheehy Message-Id: <200207120029.RAA26523@acropora.rose.agilent.com> Subject: RE: iSCSI: need for new data SNACK code? To: ips@ece.cmu.edu (IETF IP SAN Reflector) Date: Thu, 11 Jul 2002 17:29:23 PDT X-Mailer: Elm [revision: 212.4] Sender: owner-ips@ece.cmu.edu Precedence: bulk > > If the target makes > > its own choice to resegment, and the initiator doesn't think the > > target resegmented, there are error scenarios that combine this with > > corrupt Data PDU headers to cause the initiator to successfully > > complete a SCSI command that has not delivered all its data > > (the resegmented PDUs caused the Data PDU count to match the ExpDataSN > > value in the response that should have been discarded, but wasn't). > > While these should be rare, their consequences can be catastrophic. > > What do you mean by "if the target makes it's own choice to resegment"? > Sounds like a target bug to me. It feels like you're making this look more > complicated than it really is. The only promise the target has made to the initiator is that it will not send a segment larger than MaxRecvDataSegmentLength. It is free to segment to any size <= to that and to change that size, for its own purposes, at any point in time w/o notifying the initiator. I don't think the spec says anything about requiring the target to use a constant segment size. Therefore, the described behavior is perfectly legal and not a bug as you seem to believe. Dave From owner-ips@ece.cmu.edu Thu Jul 11 21:06:02 2002 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA16922 for ; Thu, 11 Jul 2002 21:06:02 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id g6C0mxA18865 for ips-outgoing; Thu, 11 Jul 2002 20:48:59 -0400 (EDT) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from erie.mcdata.com ([144.49.6.25]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id g6C0mvX18859 for ; Thu, 11 Jul 2002 20:48:58 -0400 (EDT) Received: from erie.mcdata.com ([172.18.1.35]) by erie.mcdata.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) id NV92NN3M; Thu, 11 Jul 2002 18:48:51 -0600 Received: from 172.24.0.13 by erie.mcdata.com (InterScan E-Mail VirusWall NT); Thu, 11 Jul 2002 18:48:51 -0600 Received: by snexu01.mcdata.com with Internet Mail Service (5.5.2653.19) id ; Thu, 11 Jul 2002 17:48:50 -0700 Message-ID: <0251888E076E2B45A72536425D4D001461E88A@snexu01.mcdata.com> From: Siva Vaddepuri To: "'Mark Bakke'" Cc: "'ips@ece.cmu.edu'" Subject: Regarding Counter64 in iSCSI MIB draft-ietf-ips-iscsi-mib-05.txt Date: Thu, 11 Jul 2002 17:48:44 -0700 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-ips@ece.cmu.edu Precedence: bulk iSCSI MIB has two Counter64 counters (iscsiSsnTxDataOctets, iscsiSsnRxDataOctets) and the MIB document (section 4) suggests that SNMPv1 Agents could drop support for such counters. I was informed that IPS working group made a decision to support SNMPv1 agents by providing two Counter32 MIB Variables for each Counter64 MIB variable. Transmitted Data Octets and Received Data Octets are very important statistics information and it would be useful if SNMPv1 agents could provide this information. Thanks, Siva From owner-ips@ece.cmu.edu Thu Jul 11 22:17:46 2002 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA19967 for ; Thu, 11 Jul 2002 22:17:45 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id g6C21i722507 for ips-outgoing; Thu, 11 Jul 2002 22:01:44 -0400 (EDT) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from d12lmsgate.de.ibm.com (d12lmsgate.de.ibm.com [195.212.91.199]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id g6C21gX22502; Thu, 11 Jul 2002 22:01:42 -0400 (EDT) Received: from d12relay01.de.ibm.com (d12relay01.de.ibm.com [9.165.215.22]) by d12lmsgate.de.ibm.com (8.12.3/8.12.3) with ESMTP id g6C21QDX048614; Fri, 12 Jul 2002 04:01:26 +0200 Received: from d10hubm1.telaviv.ibm.com (d10ml001.telaviv.ibm.com [9.148.216.55]) by d12relay01.de.ibm.com (8.11.1m3/NCO/VER6.2) with ESMTP id g6C21QT142048; Fri, 12 Jul 2002 04:01:26 +0200 To: "KRUEGER,MARJORIE (HP-Roseville,ex1)" Cc: "'Mallikarjun C.'" , ips@ece.cmu.edu, owner-ips@ece.cmu.edu MIME-Version: 1.0 Subject: RE: iSCSI: task set notes X-Mailer: Lotus Notes Release 5.0.9 November 16, 2001 From: "Julian Satran" Message-ID: Date: Fri, 12 Jul 2002 05:01:20 +0300 X-MIMETrack: Serialize by Router on D10ML001/10/M/IBM(Release 5.0.9a |January 7, 2002) at 12/07/2002 05:01:26, Serialize complete at 12/07/2002 05:01:26 Content-Type: multipart/alternative; boundary="=_alternative 00097250C2256BF4_=" Sender: owner-ips@ece.cmu.edu Precedence: bulk This is a multipart message in MIME format. --=_alternative 00097250C2256BF4_= Content-Type: text/plain; charset="us-ascii" thanks - Julo "KRUEGER,MARJORIE (HP-Roseville,ex1)" Sent by: owner-ips@ece.cmu.edu 07/11/2002 05:19 AM Please respond to "KRUEGER,MARJORIE (HP-Roseville,ex1)" To: "'Mallikarjun C.'" , Julian Satran/Haifa/IBM@IBMIL cc: ips@ece.cmu.edu Subject: RE: iSCSI: task set notes > - In section 2.5.1.3, > > "The I_T_L nexus identifies task sets and is carried by the > LUN (and implied by the session identification)." > > Since an I_T_L nexus identifies only one task set, I > suggest the following - > > "The affected task set is identified by the I_T_L nexus, > which in turn is identified by the LUN and by the > session identification." In the above paragraphs, it seems that "I_T nexus identification" should be substituted for "session identification". Regards, Marjorie --=_alternative 00097250C2256BF4_= Content-Type: text/html; charset="us-ascii"
thanks - Julo


"KRUEGER,MARJORIE (HP-Roseville,ex1)" <marjorie_krueger@hp.com>
Sent by: owner-ips@ece.cmu.edu

07/11/2002 05:19 AM
Please respond to "KRUEGER,MARJORIE (HP-Roseville,ex1)"

       
        To:        "'Mallikarjun C.'" <cbm@rose.hp.com>, Julian Satran/Haifa/IBM@IBMIL
        cc:        ips@ece.cmu.edu
        Subject:        RE: iSCSI: task set notes

       


> - In section 2.5.1.3,
>
> "The I_T_L nexus identifies task sets and is carried by the
> LUN (and implied by the session identification)."
>
>   Since an I_T_L nexus identifies only one task set, I
> suggest the following -
>
> "The affected task set is identified by the I_T_L nexus,
> which in turn is identified by the LUN and by the
> session identification."

In the above paragraphs, it seems that "I_T nexus identification" should be
substituted for "session identification".

Regards,
Marjorie

--=_alternative 00097250C2256BF4_=-- From owner-ips@ece.cmu.edu Thu Jul 11 22:18:35 2002 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA19990 for ; Thu, 11 Jul 2002 22:18:35 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id g6C1onY21924 for ips-outgoing; Thu, 11 Jul 2002 21:50:49 -0400 (EDT) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from petasus.ch.intel.com (petasus.ch.intel.com [143.182.124.5]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id g6C1okX21917 for ; Thu, 11 Jul 2002 21:50:46 -0400 (EDT) Received: from fmsmsxvs043.fm.intel.com (fmsmsxvs043.fm.intel.com [132.233.42.129]) by petasus.ch.intel.com (8.11.6/8.11.6/d: solo.mc,v 1.42 2002/05/23 22:21:11 root Exp $) with SMTP id g6BIr7h00353 for ; Thu, 11 Jul 2002 18:53:07 GMT Received: from fmsmsx29.FM.INTEL.COM ([132.233.42.29]) by fmsmsxvs043.fm.intel.com (NAVGW 2.5.2.11) with SMTP id M2002071118493317713 for ; Thu, 11 Jul 2002 18:49:33 -0700 Received: by fmsmsx29.fm.intel.com with Internet Mail Service (5.5.2653.19) id <3XNFTK1Q>; Thu, 11 Jul 2002 18:50:39 -0700 Message-ID: From: "Cheng, Lei" To: ips@ece.cmu.edu Subject: remove Date: Thu, 11 Jul 2002 18:50:19 -0700 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-ips@ece.cmu.edu Precedence: bulk From owner-ips@ece.cmu.edu Thu Jul 11 22:20:20 2002 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA20045 for ; Thu, 11 Jul 2002 22:20:20 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id g6C2Afb23009 for ips-outgoing; Thu, 11 Jul 2002 22:10:41 -0400 (EDT) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from palrel12.hp.com (palrel12.hp.com [156.153.255.237]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id g6C2AdX23002 for ; Thu, 11 Jul 2002 22:10:39 -0400 (EDT) Received: from core.rose.hp.com (core.rose.hp.com [15.43.208.100]) by palrel12.hp.com (Postfix) with ESMTP id 57F76E0064E; Thu, 11 Jul 2002 19:10:38 -0700 (PDT) Received: from swathi (swathi.rose.hp.com [15.43.213.237]) by core.rose.hp.com with SMTP (8.9.3 (PHNE_22672)/8.8.6 SMKit7.02) id TAA13013; Thu, 11 Jul 2002 19:12:30 -0700 (PDT) Message-ID: <016801c22949$4f9bfed0$edd52b0f@rose.hp.com> From: "Mallikarjun C." To: "Dave Sheehy" , "IETF IP SAN Reflector" References: <200207120029.RAA26523@acropora.rose.agilent.com> Subject: Re: iSCSI: need for new data SNACK code? Date: Thu, 11 Jul 2002 19:10:35 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2600.0000 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 Sender: owner-ips@ece.cmu.edu Precedence: bulk Content-Transfer-Encoding: 7bit Dave, I am glad that others are chiming in as well, :-) >It is free to segment > to any size <= to that and to change that size, for its own purposes, at > any point in time w/o notifying the initiator. That is correct for the general case, but not for the specific data SNACK case under discussion - the spec requires the retransmitted PDUs to be "exact replicas" barring certain header fields, in the absence of a negotiated max PDU size change. -- Mallikarjun Mallikarjun Chadalapaka Networked Storage Architecture Network Storage Solutions Hewlett-Packard MS 5668 Roseville CA 95747 cbm@rose.hp.com ----- Original Message ----- From: "Dave Sheehy" To: "IETF IP SAN Reflector" Sent: Thursday, July 11, 2002 5:29 PM Subject: RE: iSCSI: need for new data SNACK code? > > > > If the target makes > > > its own choice to resegment, and the initiator doesn't think the > > > target resegmented, there are error scenarios that combine this with > > > corrupt Data PDU headers to cause the initiator to successfully > > > complete a SCSI command that has not delivered all its data > > > (the resegmented PDUs caused the Data PDU count to match the ExpDataSN > > > value in the response that should have been discarded, but wasn't). > > > While these should be rare, their consequences can be catastrophic. > > > > What do you mean by "if the target makes it's own choice to resegment"? > > Sounds like a target bug to me. It feels like you're making this look more > > complicated than it really is. > > The only promise the target has made to the initiator is that it will not > send a segment larger than MaxRecvDataSegmentLength. It is free to segment > to any size <= to that and to change that size, for its own purposes, at > any point in time w/o notifying the initiator. I don't think the spec says > anything about requiring the target to use a constant segment size. > Therefore, the described behavior is perfectly legal and not a bug as you > seem to believe. > > Dave > > From owner-ips@ece.cmu.edu Thu Jul 11 22:20:27 2002 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA20063 for ; Thu, 11 Jul 2002 22:20:26 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id g6C21Vd22492 for ips-outgoing; Thu, 11 Jul 2002 22:01:31 -0400 (EDT) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from d12lmsgate.de.ibm.com (d12lmsgate.de.ibm.com [195.212.91.199]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id g6C21TX22488 for ; Thu, 11 Jul 2002 22:01:29 -0400 (EDT) Received: from d12relay01.de.ibm.com (d12relay01.de.ibm.com [9.165.215.22]) by d12lmsgate.de.ibm.com (8.12.3/8.12.3) with ESMTP id g6C21LDX048610; Fri, 12 Jul 2002 04:01:21 +0200 Received: from d10hubm1.telaviv.ibm.com (d10ml001.telaviv.ibm.com [9.148.216.55]) by d12relay01.de.ibm.com (8.11.1m3/NCO/VER6.2) with ESMTP id g6C21LT131642; Fri, 12 Jul 2002 04:01:21 +0200 To: "KRUEGER,MARJORIE (HP-Roseville,ex1)" Cc: ips , "Julian Satran" MIME-Version: 1.0 Subject: RE: iSCSI: DLB's Comment on SCSI Port Names X-Mailer: Lotus Notes Release 5.0.9 November 16, 2001 From: "Julian Satran" Message-ID: Date: Fri, 12 Jul 2002 05:00:58 +0300 X-MIMETrack: Serialize by Router on D10ML001/10/M/IBM(Release 5.0.9a |January 7, 2002) at 12/07/2002 05:01:21, Serialize complete at 12/07/2002 05:01:21 Content-Type: multipart/alternative; boundary="=_alternative 00093601C2256BF4_=" Sender: owner-ips@ece.cmu.edu Precedence: bulk This is a multipart message in MIME format. --=_alternative 00093601C2256BF4_= Content-Type: text/plain; charset="us-ascii" Marjorie, Thanks for your complete and timely answer. Regards, Julo "KRUEGER,MARJORIE (HP-Roseville,ex1)" 07/11/2002 05:15 AM Please respond to "KRUEGER,MARJORIE (HP-Roseville,ex1)" To: Julian Satran/Haifa/IBM@IBMIL cc: ips Subject: RE: iSCSI: DLB's Comment on SCSI Port Names Julo, I'm a bit confused as the issues list on your website does not have this as issue 37, and all I see is issue 9 (where your comment appears to imply "no change"?) In any case, here's what I recommend: In sec 1.1 Definitions change the following definitions to: I_T Nexus: the last sentence should be The I_T nexus can be identified by the conjunction of the SCSI port names; that is, the I_T nexus identifier is the tuple (iSCSI Initiator Name + ',i,'+ ISID, iSCSI Target Name + ',t,'+ Portal Group Tag). SCSI Port Name: definition should be A name made up as UTF-8 characters and includes the iSCSI Name + ',i,' or ',t,' + ISID or Portal Group Tag In sec 2.2.7, 1st paragraph, delete the comment in parenthesis starting with "(for iSCSI,.." (or change it to point it to section 2.4.2, your choice). In sec 2.4.2, change the text to: When used in SCSI parameter data, the SCSI port name MUST be encoded as: - The iSCSI Name in UTF-8 format, followed by - a comma separator (1 byte), followed by - the ASCII character 'i' (for SCSI Initiator Port) or the ASCII character 't' (for SCSI Target Port), followed by - a comma separator (1 byte), followed by - A string representation (, see section 4.1 Text Format) of the ISID (for SCSI initiator port) or the portal group tag (for SCSI target port). SCSI port names have a maximum length of 255 bytes. The ASCII character 'i' or 't' is the label that identifies this port as either a SCSI Initiator Port or a SCSI Target Port. The 255 max port name makes for a 237 max iSCSI node name (check my math Jim :-) as the max character representation of an ISID is 15 characters for the largest decimal representation (14 char for the largest hex), + 3 char (",i,") + 237 = 255 The change in max node name causes changes to: sec 2.2.6.1, paragraph 2, sec 2.2.6.2, 2nd p, 3rd bullet I will see that a change is proposed to Annex A in whatever SAM doc is currently under revision. Thanks, Marjorie Krueger Networked Storage Architecture Networked Storage Solutions Org. Hewlett-Packard -----Original Message----- From: Julian Satran (Actcom) [mailto:Julian_Satran@actcom.net.il] Sent: Tuesday, July 09, 2002 6:44 AM To: KRUEGER,MARJORIE (HP-Roseville,ex1); 'Jim Hafner'; Black_David@emc.com Cc: ips Subject: Re: iSCSI: DLB's Comment on SCSI Port Names Marjorie, I'll list this as issue 37 and I think we can settle on 249 :-) I would appreciate if you let me know what constants change (in 2.4.2?) Julo ----- Original Message ----- From: KRUEGER,MARJORIE (HP-Roseville,ex1) To: 'Jim Hafner' ; Black_David@emc.com Cc: ips@ece.cmu.edu Sent: Tuesday, July 09, 2002 4:04 AM Subject: RE: iSCSI: DLB's Comment on SCSI Port Names I've just encountered this issue with regards to iSCSI port name encoding in the SCSI MIB, and the currently specified port name encoding causes inconvenience (at best). IMO, it makes sense to be able to treat an iSCSI name field, be it device name or port name, the same - as a string of display characters, portions of which may contain ASCII-encoded numeric values. I don't really see that it makes a difference whether one views ISID and TPGT as numeric strings or values, since as Jim says, there are no calculations performed using these things, and they are basicly just "tags". The issue for me is that the rest of the "SCSI port name" is a string and I see no value in "encoding" the ISID or TPGT as a value for SCSI purposes, as SCSI should have no need to use the ISID or TPGT values separately from the entire port name. And even if SCSI had such a need, it's a simple matter to convert a numeric string representation to a value. The downside of a string-encoding is the increased maximum size of the SCSI port name. If strings over 256 characters are a problem for some platforms, I'd be in favor of reducing the max iSCSI node name to 249 characters so the maximum SCSI port name would be 255 characters total (249 char name + ",i," + "0x0000") Marjorie Krueger Networked Storage Architecture Networked Storage Solutions Org. Hewlett-Packard -----Original Message----- From: Jim Hafner [mailto:hafner@almaden.ibm.com] Sent: Monday, July 08, 2002 9:08 AM To: Black_David@emc.com Cc: ips@ece.cmu.edu Subject: RE: iSCSI: DLB's Comment on SCSI Port Names David, I believe it will (may?) be used, so I agree we're in the second case. However, this format is the intended use in SCSI protocol stuff. Two places where SCSI ports names are used now is in ALIAS, Access Controls and in third party reservations -- see caveat below, however) I don't see a need in this context to define these as strings (that's not a SCSI way of thinking...). However, I think the issue comes down to a simple question: are the ISID and TPGT values or numerical strings (Julian is calling them numerical strings, but I've always thought of them as values, in spite of the fact that there is no arithmetic done on them - there is precedent in SCSI for such thinking, so I'm not completely out in the woods here). If they are values, then I'd like to see them formatted for SCSI in "value form"; if they are strings, then any representation should be OK. Does that at least get to the core of the issue? Jim Hafner CAVEAT: I don't think we'd use the iSCSI constructed port names in those contexts as device names are better suited for those purposes, but these are examples where specification of SCSI port name format is required. To: Jim Hafner/Almaden/IBM@IBMUS cc: ips@ece.cmu.edu Subject: RE: iSCSI: DLB's Comment on SCSI Port Names Jim, My view of this is that either: - The SCSI Port Name is never going to be used, in which case it shouldn't be designed to this level of detail. OR - It's going to be used, and hence is worth designing in a fashion that is reasonable to use. I think we're in the second category, and turning the ISID into hex ASCII (well, UTF-8) so the SCSI port name is a string is worth doing now to avoid problems when people actually try to use it. I would have no problems if someone wanted to pad the string, but I'd make specifying the padding the responsibility of the protocol/API/situation in which it was used rather than incorporating the padding into the name. Thanks, --David -----Original Message----- From: Jim Hafner [mailto:hafner@almaden.ibm.com] Sent: Monday, July 08, 2002 11:42 AM To: Black_David@emc.com Cc: ips@ece.cmu.edu Subject: Re: iSCSI: DLB's Comment on SCSI Port Names David, You wrote: >[T.9] 2.4.2 SCSI Architecture Model > > The SCSI Port Name is mandatory in iSCSI. When used in SCSI > parameter data, the SCSI port name MUST be encoded as: > - The iSCSI Name in UTF-8 format, followed by > - a comma separator (1 byte), followed by > - the ASCII character 'i' (for SCSI Initiator Port) or the > ASCII character 't' (for SCSI Target Port), followed by > - a comma separator (1 byte), followed by > - zero to 3 null pad bytes so that the complete format is a > multiple of four bytes long, followed by > - the 6byte value of the ISID (for SCSI initiator port) or the > 2byte value of the portal group tag (for SCSI target port) in > network byte order (BigEndian). > That's a peculiar format with padding nulls in the middle and > a number concatenated after the padding - for example, it can't > be passed in iSCSI login without format conversion. How about > converting the number to 4 or 12 bytes of hex (ASCII characters) > and moving the padding to the end so the result is actually a > string, and excluding the padding from the definition of the name? > This will increase the maximum length of port names, but produce > names that are easier to deal with. Admittedly that's an odd format, however here was the reason for this layout. 1) it's not used directly in iSCSI "Text" strings; it's intended to be a description of how this information is packed into a byte array for representation in "SCSI parameter data" (as it says!) -- that is, it's NEVER "passed in iSCSI login" (in this form). 2) the padding after the string was to force the binary values of the ISID or PGT to be better word aligned and can be more easily extracted as a value direct from the byte array without conversion. What do you think? Jim Hafner --=_alternative 00093601C2256BF4_= Content-Type: text/html; charset="us-ascii"
Marjorie,

Thanks for your complete and timely answer.

Regards,
Julo


"KRUEGER,MARJORIE (HP-Roseville,ex1)" <marjorie_krueger@hp.com>

07/11/2002 05:15 AM
Please respond to "KRUEGER,MARJORIE (HP-Roseville,ex1)"

       
        To:        Julian Satran/Haifa/IBM@IBMIL
        cc:        ips <ips@ece.cmu.edu>
        Subject:        RE: iSCSI: DLB's Comment on SCSI Port Names

       


Julo,
I'm a bit confused as the issues list on your website does not have this as issue 37, and all I see is issue 9 (where your comment appears to imply "no change"?)
 
In any case, here's what I recommend:
 
In sec 1.1 Definitions change the following definitions to:
 
I_T Nexus:  the last sentence should be
 
The I_T nexus can be identified by the conjunction of the SCSI port names; that is, the I_T nexus identifier is the tuple (iSCSI Initiator Name + ',i,'+ ISID, iSCSI Target Name + ',t,'+ Portal Group Tag).
 
SCSI Port Name: definition should be
 
A name made up as UTF-8 characters and includes the  iSCSI Name + ',i,' or ',t,' + ISID or Portal Group Tag
 
In sec 2.2.7, 1st paragraph, delete the comment in parenthesis starting with "(for iSCSI,.." (or change it to point it to section 2.4.2, your choice).
 
In sec 2.4.2, change the text to:
 
  When used in SCSI parameter data, the SCSI port name MUST be encoded as:
     - The iSCSI Name in UTF-8 format, followed by
     - a comma separator (1 byte), followed by
     - the ASCII character 'i' (for SCSI Initiator Port) or the
      ASCII character 't' (for SCSI Target Port), followed by
     - a comma separator (1 byte), followed by
      - A string representation (<numerical-value>, see section 4.1 Text Format)
       of the ISID (for SCSI initiator port) or the portal group tag (for SCSI target port).
      SCSI port names have a maximum length of 255 bytes.
       The ASCII character 'i' or 't' is the label that identifies this port
       as either a SCSI Initiator Port or a SCSI Target Port.
The 255 max port name makes for a 237 max iSCSI node name (check my math Jim :-) as the max character representation of an ISID is 15 characters for the largest decimal representation (14 char for the largest hex), + 3 char (",i,") + 237 = 255
 
The change in max node name causes changes to:
 
sec 2.2.6.1, paragraph 2,
sec 2.2.6.2, 2nd p, 3rd bullet
 
I will see that a change is proposed to Annex A in whatever SAM doc is currently under revision.
 
Thanks,
Marjorie Krueger
Networked Storage Architecture
Networked Storage Solutions Org.
Hewlett-Packard
-----Original Message-----
From: Julian Satran (Actcom) [mailto:Julian_Satran@actcom.net.il]
Sent: Tuesday, July 09, 2002 6:44 AM
To: KRUEGER,MARJORIE (HP-Roseville,ex1); 'Jim Hafner'; Black_David@emc.com
Cc: ips
Subject: Re: iSCSI: DLB's Comment on SCSI Port Names
Marjorie,
 
I'll list this as issue 37 and I think we can settle on 249 :-)
I would appreciate if you let me know what constants change (in 2.4.2?)
 
Julo
----- Original Message -----
From: KRUEGER,MARJORIE (HP-Roseville,ex1)
To: 'Jim Hafner' ; Black_David@emc.com
Cc: ips@ece.cmu.edu
Sent: Tuesday, July 09, 2002 4:04 AM
Subject: RE: iSCSI: DLB's Comment on SCSI Port Names

I've just encountered this issue with regards to iSCSI port name encoding in the SCSI MIB, and the currently specified port name encoding causes inconvenience (at best).  IMO, it makes sense to be able to treat an iSCSI name field, be it device name or port name, the same - as a string of display characters, portions of which may contain ASCII-encoded numeric values.
 
I don't really see that it makes a difference whether one views ISID and TPGT as numeric strings or values, since as Jim says, there are no calculations performed using these things, and they are basicly just "tags".  The issue for me is that the rest of the "SCSI port name" is a string and I see no value in "encoding" the ISID or TPGT as a value for SCSI purposes, as SCSI should have no need to use the ISID or TPGT values separately from the entire port name.  And even if SCSI had such a need, it's a simple matter to convert a numeric string representation to a value.
 
The downside of a string-encoding is the increased maximum size of the SCSI port name.
 
If strings over 256 characters are a problem for some platforms, I'd be in favor of reducing the max iSCSI node name to 249 characters so the maximum SCSI port name would be 255 characters total (249 char name + ",i," + "0x0000")
 
Marjorie Krueger
Networked Storage Architecture
Networked Storage Solutions Org.
Hewlett-Packard
-----Original Message-----
From: Jim Hafner [mailto:hafner@almaden.ibm.com]
Sent: Monday, July 08, 2002 9:08 AM
To: Black_David@emc.com
Cc: ips@ece.cmu.edu
Subject: RE: iSCSI: DLB's Comment on SCSI Port Names

David,

I believe it will (may?) be used, so I agree we're in the second case.  However, this format is the intended use in SCSI protocol stuff.  Two places where SCSI ports names are used now is in ALIAS, Access Controls and in third party reservations -- see caveat below, however)

I don't see a need in this context to define these as strings (that's not a SCSI way of thinking...).  

However, I think the issue comes down to a simple question:  are the ISID and TPGT values or numerical strings (Julian is calling them numerical strings, but I've always thought of them as values, in spite of the fact that there is no arithmetic done on them - there is precedent in SCSI for such thinking, so I'm not completely out in the woods here).

If they are values, then I'd like to see them formatted for SCSI in "value form";  if they are strings, then any representation should be OK.

Does that at least get to the core of the issue?

Jim Hafner

CAVEAT: I don't think we'd use the iSCSI constructed port names in those contexts as device names are better suited for those purposes, but these are examples where specification of SCSI port name format is required.

To:        Jim Hafner/Almaden/IBM@IBMUS
cc:        ips@ece.cmu.edu
Subject:        RE: iSCSI: DLB's Comment on SCSI Port Names



Jim,

My view of this is that either:
- The SCSI Port Name is never going to be used, in which case
it shouldn't be designed to this level of detail. OR
- It's going to be used, and hence is worth designing in a fashion
that is reasonable to use.
I think we're in the second category, and turning the ISID into
hex ASCII (well, UTF-8) so the SCSI port name is a string is
worth doing now to avoid problems when people actually try
to use it.  I would have no problems if someone wanted to
pad the string, but I'd make specifying the padding the
responsibility of the protocol/API/situation in which it
was used rather than incorporating the padding into the name.

Thanks,
--David

-----Original Message-----
From: Jim Hafner [mailto:hafner@almaden.ibm.com]
Sent: Monday, July 08, 2002 11:42 AM
To: Black_David@emc.com
Cc: ips@ece.cmu.edu
Subject: Re: iSCSI: DLB's Comment on SCSI Port Names



David,

You wrote:

>[T.9] 2.4.2  SCSI Architecture Model
>
>  The SCSI Port Name is mandatory in iSCSI. When used in SCSI
>  parameter data, the SCSI port name MUST be encoded as:
>  - The iSCSI Name in UTF-8 format, followed by
>  - a comma separator (1 byte), followed by
>  - the ASCII character 'i' (for SCSI Initiator Port) or the
>    ASCII character 't' (for SCSI Target Port), followed by
>  - a comma separator (1 byte), followed by
>  - zero to 3 null pad bytes so that the complete format is a
>    multiple of four bytes long, followed by
>  - the 6byte value of the ISID (for SCSI initiator port) or the
>    2byte value of the portal group tag (for SCSI target port) in
>    network byte order (BigEndian).

> That's a peculiar format with padding nulls in the middle and
> a number concatenated after the padding - for example, it can't
> be passed in iSCSI login without format conversion.  How about
> converting the number to 4 or 12 bytes of hex (ASCII characters)
> and moving the padding to the end so the result is actually a
> string, and excluding the padding from the definition of the name?
> This will increase the maximum length of port names, but produce
> names that are easier to deal with.

Admittedly that's an odd format, however here was the reason for this
layout.
1) it's not used directly in iSCSI "Text" strings; it's intended to be a
description of how this information is packed into a byte array for
representation in "SCSI parameter data" (as it says!) -- that is, it's NEVER
"passed in iSCSI login" (in this form).
2) the padding after the string was to force the binary values of the ISID
or PGT to be better word aligned and can be more easily extracted as a value
direct from the byte array without conversion.

What do you think?

Jim Hafner


--=_alternative 00093601C2256BF4_=-- From owner-ips@ece.cmu.edu Thu Jul 11 22:20:48 2002 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA20085 for ; Thu, 11 Jul 2002 22:20:47 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id g6C27wF22849 for ips-outgoing; Thu, 11 Jul 2002 22:07:58 -0400 (EDT) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from msgbas2.cos.agilent.com (msgbas2x.cos.agilent.com [192.25.240.37]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id g6C27vX22844 for ; Thu, 11 Jul 2002 22:07:57 -0400 (EDT) Received: from msgrel1t.cos.agilent.com (msgrel1t.cos.agilent.com [130.29.152.157]) by msgbas2.cos.agilent.com (Postfix) with ESMTP id 653831B90; Thu, 11 Jul 2002 20:07:56 -0600 (MDT) Received: from axcsbh3.cos.agilent.com (axcsbh3.cos.agilent.com [130.29.152.190]) by msgrel1t.cos.agilent.com (Postfix) with SMTP id 165D7514; Thu, 11 Jul 2002 20:07:56 -0600 (MDT) Received: from 130.29.152.190 by axcsbh3.cos.agilent.com (InterScan E-Mail VirusWall NT); Thu, 11 Jul 2002 20:07:55 -0600 Received: by axcsbh3.cos.agilent.com with Internet Mail Service (5.5.2653.19) id <3S5DM6JK>; Thu, 11 Jul 2002 20:07:55 -0600 Message-ID: <01A7DAF31F93D511AEE300D0B706ED9201BF49EF@axcs13.cos.agilent.com> From: vince_cavanna@agilent.com To: Black_David@emc.com Cc: ips@ece.cmu.edu, tom@arcot.com, vince_cavanna@agilent.com, pat_thaler@agilent.com, dave_sheehy@agilent.com Subject: RE: IPS security draft: SRP groups Date: Thu, 11 Jul 2002 20:07:53 -0600 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="ISO-8859-1" Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ece.cmu.edu id g6C27vX22845 Sender: owner-ips@ece.cmu.edu Precedence: bulk Content-Transfer-Encoding: 8bit Hi David, I can't prove so, but Mathematica from Wolfram certifies as prime (in a matter seconds) all five moduli specified in the iSCSI security draft for use in SRP! I used the PrimeQ built-in function. PrimeQ first tests for divisibility using small primes, then uses the Miller­Rabin strong pseudoprime test base 2 and base 3, and then uses a Lucas test. I have not explored the nature of these tests. Vince |-----Original Message----- |From: Black_David@emc.com [mailto:Black_David@emc.com] |Sent: Monday, July 08, 2002 7:34 AM |To: tom@arcot.com |Cc: ips@ece.cmu.edu |Subject: RE: IPS security draft: SRP groups | | |MANY THANKS -- Tom's earned his promised 30 |minutes of fame ... although those 30 minutes may come at |the ipr BOF in Yokohama on Friday :-) :-). | |For the security draft, specifying one of the acceptable |generators from Tom's lists for each of the IKE groups and |noting that the primes from the SRP distribution were |probabilistically generated should be sufficient ... |but there's still 30 minute of fame available for someone |who tackles proving that the SRP primes are prime, as there |is significant IETF interest in SRP outside of iSCSI - any takers? | |Thanks, --David | |> -----Original Message----- |> From: Tom Wu [mailto:tom@arcot.com] |> Sent: Monday, July 08, 2002 12:23 AM |> To: Black_David@emc.com |> Cc: ips@ece.cmu.edu |> Subject: Re: IPS security draft: SRP groups |> |> |> David, |> |> I'll tackle the SRP generator issue: |> |> For the Oakley Group 2 (1024 bit prime) defined in RFC2412: |> Primitive roots (acceptable as SRP generators): |> 5,11,13,19,29,31 |> Subgroup generators (NOT acceptable): |> 2,3,7,17,23 |> |> (MODP moduli taken from draft-ietf-ipsec-ike-modp-groups-04.txt) |> For the 1536-bit MODP group: |> Acceptable generators: |> 31 |> NOT acceptable generators: |> 2,3,5,7,11,13,17,19,23,29 |> |> For the 2048-bit MODP group: |> Acceptable generators: |> 11,13,17,23,29,31 |> NOT acceptable generators: |> 2,3,5,7,19 |> |> For the 3072-bit MODP group: |> Acceptable generators: |> 5,7,17,23,31 |> NOT acceptable generators: |> 2,3,11,13,19,29 |> |> For the 4096-bit MODP group: |> Acceptable generators: |> 5,13,29,31 |> NOT acceptable generators: |> 2,3,7,11,17,19,23 |> |> For the 6144-bit MODP group: |> Acceptable generators: |> 5,11,13,17,23,29 |> NOT acceptable generators: |> 2,3,7,19,31 |> |> For the 8192-bit MODP group: |> Acceptable generators: |> 19,23,29,31 |> NOT acceptable generators: |> 2,3,5,7,11,13,17 |> |> All the above generators are in base 10 (decimal). |> |> As far as proving the primality of the SRP moduli, that |> should be done |> by someone with more expertise in the area. I should point out that |> those moduli are also "safe primes", i.e. both N and (N-1)/2 |> are prime, |> so it is easy to find generators for them, and I chose |> numbers that had |> 2 as safe SRP generators. |> |> Tom |> |> Black_David@emc.com wrote: |> > Missed this earlier, sorry ... |> > |> > |> >>Ok. I didn't know that but I probably would have learned |> it if I had |> >>done the necessary reading about groups and generators. |> But the point |> >>of my question wasn't "is it possible to compute g" but rather "how |> >>about supplying g in the spec" (since the g=2 from IKE is not |> >>appropriate). It seems a bit redundant for everyone to repeat the |> >>search for a suitable g... |> >> |> >>So what's the story about unlisted groups? Is an |> implementation that |> >>accepts only the groups listed in appendix A, but not any "locally |> >>generated" ones, a compliant implementation? |> >> |> > |> > Yes - accepting those groups and only those groups is the minimum |> > (MUST) requirement. If the IKE groups are to remain allowed, we |> > need to specify generators for their use with SRP - please consider |> > this to be a serious *PLEA* for someone to volunteer to do the |> > crpto-theoretic number crunching needed to find SRP generators for |> > those groups and/or prove the primality of the SRP primes. Lack of |> > progress here has the potential to hold up the security draft on |> > which *all* of our protocol drafts depend (normative references). |> > We can promise at least 30 minutes of fame (*twice* the proverbial |> > 15 ;-) ) to those who resolve this issue ... |> > |> > 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 |> > --------------------------------------------------- |> |> |> -- |> Tom Wu |> Principal Software Engineer |> Arcot Systems |> (408) 969-6124 |> "The Borg? Sounds Swedish..." |> | From owner-ips@ece.cmu.edu Thu Jul 11 23:11:41 2002 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA22160 for ; Thu, 11 Jul 2002 23:11:40 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id g6C2d1q24548 for ips-outgoing; Thu, 11 Jul 2002 22:39:01 -0400 (EDT) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from ns.jscom.co.jp (ns.jscom.co.jp [61.208.189.211]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id g6C2cwX24540 for ; Thu, 11 Jul 2002 22:38:59 -0400 (EDT) Received: from [10.0.200.193] (o210.jscom.co.jp [61.208.189.210]) by ns.jscom.co.jp (8.11.6/8.11.6) with ESMTP id g6C2XBf22481 for ; Fri, 12 Jul 2002 11:33:11 +0900 Date: Fri, 12 Jul 2002 11:39:02 +0900 From: fujii To: ips@ece.cmu.edu Subject: remove Message-Id: <20020712113845.D5CB.FUJII@jscom.co.jp> MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit X-Mailer: Becky! ver. 2.05 Sender: owner-ips@ece.cmu.edu Precedence: bulk Content-Transfer-Encoding: 7bit -- <> From owner-ips@ece.cmu.edu Fri Jul 12 00:20:10 2002 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA24655 for ; Fri, 12 Jul 2002 00:20:10 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id g6C3rmb28443 for ips-outgoing; Thu, 11 Jul 2002 23:53:48 -0400 (EDT) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from mxic2.corp.emc.com (mxic2.isus.emc.com [128.221.31.40]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id g6C3rkX28438 for ; Thu, 11 Jul 2002 23:53:46 -0400 (EDT) Received: by mxic2.corp.emc.com with Internet Mail Service (5.5.2653.19) id <3XHVJ50L>; Thu, 11 Jul 2002 23:53:44 -0400 Message-ID: <277DD60FB639D511AC0400B0D068B71E0564C070@CORPMX14> From: Black_David@emc.com To: marjorie_krueger@hp.com Cc: ips@ece.cmu.edu Subject: RE: iSCSI: need for new data SNACK code? Date: Thu, 11 Jul 2002 23:51:38 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-ips@ece.cmu.edu Precedence: bulk Marj, > I think this new SNACK code is the wrong thing to do - it feels like adding > a new feature with questionable value to provide a questionable "fix" for a > questionable problem, and there's not sufficient time left for scrutiny of > whether or not it presents a new set of problems. My concern is that we're tinkering with the behavior of the existing Data SNACK mechanism, and if we get it wrong, the results are worse than if we get the design of a new type of SNACK wrong. I also think this whole area of resegmentation functionality falls into the "not sufficient time left" category - it certainly was not analyzed correctly when it went in. > By my assessment, your solution to this problem fails Occam's Razor - if > there are two functionally equivalent solutions to a problem, chose the > simplest solution. Mallikarjun points out a simple solution that is > sufficient to solve the original problem without adding a new > PDU type. Let me know what you think happens when Occam's Razor is applied to the even simpler solution of removing resegmentation completely (see my separate recent response to Mallikarjun). Thanks, --David > -----Original Message----- > From: KRUEGER,MARJORIE (HP-Roseville,ex1) > [mailto:marjorie_krueger@hp.com] > Sent: Thursday, July 11, 2002 7:02 PM > To: 'Black_David@emc.com' > Cc: ips@ece.cmu.edu > Subject: RE: iSCSI: need for new data SNACK code? > > > > > I am still unclear about the need to add the new data SNACK > > > code. IMHO, this can only be confusing to both initiator > > and target > > > implementers - to have two codes that have identical semantics > > > on the wire. > > > > > > The only remaining reason that I see from David (attached below) > > > is that the new code makes the initiator aware that it > must request > > > status retransmission. IOW, you're expecting the initiator > > > to be careful > > > enough to use the new code, but somehow you don't expect it to be > > > attentive enough to discard the status PDU unless it had used > > > this new > > > code in an *outbound* SNACK. I completely miss this rationale. > > > > I disagree with the "careful enough" characterization. The new code > > provides the initiator with a more robust way to detect > resegmentation > > by requiring the initiator to explicitly ask for it. > > I don't follow your thinking David - the initiator has *requested* > resegmentation via a MaxRecvDataSegmentLength text request. > The foolproof > way to "detect" that the target is resegmenting is receipt of > the target's > text response. > > > The initiator > > can take a simple approach of always starting with the existing > > Data SNACK code that does not resegment and only using the new code > > when the non-resegmenting SNACK doesn't work. > > You seem to be thinking that an initiator would be sending > SNACKs on this > connection for the previous segment size immediately after > it's requested a > MaxRecvDataSegmentLength change? That doesn't make sense to me. The > initiator should wait for the target's text response before > continuing I/Os > on this connection. Thereafter, both ends know that that > data sent as a > result of a Data SNACK is resegmented and the initiator > should send a Status > SNACK for any Status PDU's received before the Text Response that were > associated with the task that requires issuance of the Data > SNACK. Seems > pretty simple to me. > > > If the target makes > > its own choice to resegment, and the initiator doesn't think the > > target resegmented, there are error scenarios that combine this with > > corrupt Data PDU headers to cause the initiator to successfully > > complete a SCSI command that has not delivered all its data > > (the resegmented PDUs caused the Data PDU count to match > the ExpDataSN > > value in the response that should have been discarded, but wasn't). > > While these should be rare, their consequences can be catastrophic. > > What do you mean by "if the target makes it's own choice to > resegment"? > Sounds like a target bug to me. It feels like you're making > this look more > complicated than it really is. > > I think this new SNACK code is the wrong thing to do - it > feels like adding > a new feature with questionable value to provide a > questionable "fix" for a > questionable problem, and there's not sufficient time left > for scrutiny of > whether or not it presents a new set of problems. > > By my assessment, your solution to this problem fails Occam's > Razor - if > there are two functionally equivalent solutions to a problem, > chose the > simplest solution. Mallikarjun points out a simple solution that is > sufficient to solve the original problem without adding a new > PDU type. > > Regards, > Marjorie > From owner-ips@ece.cmu.edu Fri Jul 12 00:21:26 2002 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA24703 for ; Fri, 12 Jul 2002 00:21:26 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id g6C3iHc27977 for ips-outgoing; Thu, 11 Jul 2002 23:44:17 -0400 (EDT) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from maho3msx2.isus.emc.com (maho3msx2.isus.emc.com [128.221.11.32]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id g6C3iGX27972 for ; Thu, 11 Jul 2002 23:44:16 -0400 (EDT) Received: by MAHO3MSX2 with Internet Mail Service (5.5.2653.19) id <31WCTHFZ>; Thu, 11 Jul 2002 23:42:09 -0400 Message-ID: <277DD60FB639D511AC0400B0D068B71E0564C06F@CORPMX14> From: Black_David@emc.com To: cbm@rose.hp.com Cc: ips@ece.cmu.edu Subject: RE: iSCSI: need for new data SNACK code? Date: Thu, 11 Jul 2002 23:42:04 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-ips@ece.cmu.edu Precedence: bulk Mallikarjun, > > The new code > > provides the initiator with a more robust way to detect resegmentation > > by requiring the initiator to explicitly ask for it. The initiator > > can take a simple approach of always starting with the existing > > Data SNACK code that does not resegment and only using the new code > > when the non-resegmenting SNACK doesn't work. > > That's one approach. So, let's note that you're expecting the target > to maintain a "PDU-size-changed" flag for every active task, and > expecting it to fail the "regular" data SNACK if the flag is set. The flag per task is not needed - I'd expect the Target to look at the Data PDUs it would have to resend, check them against the max Data PDU size for this connection and fail the regular SNACK if any PDU is too large. This could even be lazily evaluated at the time each PDU is to be sent because the odds are that if resegmenting is necessary, the first Data PDU to be resent is going to need it. The initiator still has to time out the failure of all the Data PDUs to arrive in order to deal with header corruption (unfortunately, the F bit doesn't help) - when it times out the "regular" Data SNACK, it issues a "resegmenting" one (this deals with resegmenting that becomes necessary after the first Data PDU for a Data SNACK has been sent). > Some issues - > a) would it really cover the (impossible, IMHO) case you're attempting > to cover, in the face of multiple PDU size changes? Should work - permission to resegment includes permission to re-resegment or worse. Independent of how many size changes happen, the status SNACK at the end returns a new status with an ExpDataSN that reflects the right number of Data PDUs sent. > b) assuming that there indeed is a disconnect b/n the two, > what should the target do when a resegmenting data SNACK > is received, but there's no PDU size change? I hope you > aren't mandating the specific approach. Resegmenting SNACK is "permission to resegment", and the target need not use that permission. If the permission is not used, the Initiator's status SNACK is not needed but does no harm. > c) this approach costs one additional round-trip delay, where > none is necessary (as argued below). I make no apologies for spending a round trip to remove a data corruption risk. This is a rare case with a possibly nasty failure mode - I'm much more interested in this working right than fast. > d) seems like it would need new Reject code(s) to distinguish > a "regular" reject from that of the PDU size change ones. Could be useful, but is not strictly necessary. > >If the target makes > > its own choice to resegment, and the initiator doesn't think the > > target resegmented, > > Now this is beginning to feel more like the option A vs B vs C debate > we had a while ago. If the protocol works correctly, both sides would > be *completely synchronized* on the fact of PDU size change. As the complexity of a protocol increases, that synchronized state machine assumption becomes more prone to failure. The whole discussion of default values for text keys and the resulting "if in doubt, negotiate it" maxim was one example. The alternative of relying on every default key value to be what was expected was significantly less robust. > There are two options for initiators to deal with this - > > a) don't issue any data SNACKs while any text negotiation is > in progress - wait till the text response is received successfully. That strikes me as a productive direction that I could see enforcing with some "MUST"s / "MUST NOT"s - the initiator is causing this mess by changing the max Data PDU size on the connection. This is not a friendly thing to do, and for an initiator to expects to be able to do this with uninterrupted high performance is unrealistic ... so imposing costs on the initiator for making this disruptive size change makes sense. Suppose we went back to the old approach where Data SNACKs *never* resegment and required that: - Initiators MUST NOT issue Data SNACKs that could require resegmentation? - Targets MUST reject or ignore Data SNACKs that require resegmentation. - If resegmentation becomes necessary during retransmission of Data PDUs for a Data SNACK, PDUs retransmission MUST cease for that Data SNACK. An initiator that wants to be able to issue a Data SNACK for some or all of its commands then has to ensure that no such commands are outstanding when/while it changes (in particular reduces) the max Data PDU size. In the limit, the initiator has to wait for all of its commands on the connection to complete before changing the max Data PDU size, and not start any new ones until the size change is complete. This is simpler and more robust than any of the options under discussion and has the right sort of incentives in discouraging initiators from changing the max Data PDU size. Can you accept this? I would expect widespread support for the resulting removal of target resegmentation from iSCSI. I will however answer one more question ... > > This requires additional Initiator > > state per command for something that almost never happens, and if it > > gets one of these markings wrong, > > Sorry, how is it different from the target getting wrong one > of its aforementioned > "PDU-size-changed" flags for tasks? (1) The per-task flags aren't needed - see above. (2) The failure is harmless - if the target fails to resegment and sends a PDU that is too large, the initiator discards it, and then decides what to do about the broken target. There's no possibility of completing a READ command without all of its data. 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 --------------------------------------------------- > -----Original Message----- > From: Mallikarjun C. [mailto:cbm@rose.hp.com] > Sent: Thursday, July 11, 2002 7:46 PM > To: Black_David@emc.com > Cc: ips@ece.cmu.edu > Subject: Re: iSCSI: need for new data SNACK code? > > > David, comments in text. > > > I disagree with the "careful enough" characterization. The new code > > provides the initiator with a more robust way to detect resegmentation > > by requiring the initiator to explicitly ask for it. The initiator > > can take a simple approach of always starting with the existing > > Data SNACK code that does not resegment and only using the new code > > when the non-resegmenting SNACK doesn't work. > > That's one approach. So, let's note that you're expecting > the target to maintain > a "PDU-size-changed" flag for every active task, and > expecting it to fail the > "regular" data SNACK if the flag is set. > > Some issues - > a) would it really cover the (impossible, IMHO) case > you're attempting > to cover, in the face of multiple PDU size changes? > b) assuming that there indeed is a disconnect b/n the > two, what should the > target do when a resegmenting data SNACK is received, > but there's no > PDU size change? I hope you aren't mandating the > specific approach. > c) this approach costs one additional round-trip delay, > where none is > necessary (as argued below). > d) seems like it would need new Reject code(s) to > distinguish a "regular" reject > from that of the PDU size change ones. > > >If the target makes > > its own choice to resegment, and the initiator doesn't think the > > target resegmented, > > Now this is beginning to feel more like the option A vs B vs C debate > we had a while ago. If the protocol works correctly, both sides would > be *completely synchronized* on the fact of PDU size change. > > There are two options for initiators to deal with this - > > a) don't issue any data SNACKs while any text negotiation is > in progress - > wait till the text response is received successfully. > > OR > > b) issue a data SNACK regardless, and if the text response > (that indicates > a PDU size change) arrives before the data burst > completes, discard the > status PDU, and ask for its retransmission. > > Option a is what I suggest, and b is for the adventurous sort. > > >there are error scenarios that combine this with > > corrupt Data PDU headers to cause the initiator to successfully > > complete a SCSI command that has not delivered all its data > > (the resegmented PDUs caused the Data PDU count to match > the ExpDataSN > > value in the response that should have been discarded, but wasn't). > > Which is precisely why I'm suggesting that we mandate discarding the > status PDU. What am I missing? > > > While these should be rare, their consequences can be catastrophic. > > > > It is conveying the Initiator's instructions that resegmentation is > > permitted. I am not comfortable with the last sentence > above that assumes > > that the Initiator and Target will always have identical > views of all of > > the effects of a full feature phase PDU size change - (which is > > a rare event to begin with, and hence likely to involve code that > > isn't well exercised/tested). > > Obviously, I cannot guarantee the lack of bugs in any implementation. > But again, let's not attempt to address implementation bugs > by protocol > means (that's why we picked option A in the A vs B vs C debate I > referred to above - see the "reusing ISID for recovery" > thread; it's for the > same reason we removed the X-bit for connection reinstatement - > see the "X-bit in Login" thread). > > > > > > The only two changes from the rev14 text that I propose > are that we add: > > > > > > a) The first status PDU must always be dropped after a > > > MaxRecvDataSegmentLength change, if ever a data SNACK is > > > employed for the task. > > > > When does this obligation to drop the first status PDU expire? > > As it says: when the first status PDU is dropped for the task > - for each > active task during a PDU size change, *and* for which a data SNACK > is/was issued. > > >I think > > the Initiator has to mark all commands that are outstanding > or become > > outstanding between the time it starts the negotiation that changes > > MaxRecvDataSegmentLength and the time that it gets the > final Text Response > > of that negotiation from the target. This requires > additional Initiator > > state per command for something that almost never happens, and if it > > gets one of these markings wrong, > > Sorry, how is it different from the target getting wrong one > of its aforementioned > "PDU-size-changed" flags for tasks? > > I believe that the onus should be on the initiator to do what > it takes to > do the right recovery - as is the general error recovery > philosophy everywhere. > Target cannot predict if the initiator would be interested in > recovering a > particular I/O (regardless of the operational ErrorRecoveryLevel). > > >it's vulnerable to failing to deliver > > all the data for a SCSI command in a compound error situation. An > > alternative with the new code could involve a single bit > per connection > > that records whether the PDU size was ever changed (if so, retry any > > failed Data SNACK as a resegmenting Data SNACK). > > Or, use just "the Data SNACK", if we define only one. I > can't see why this > optimization needs two data SNACK codes. > > > > > > Initiator MUST issue a status SNACK to recover the > > > status PDU (i.e. move the onus of retransmitting > > > status from the target to the initiator). > > > b) A SNACK requesting an R2T, Data or Status PDU for > a task MUST be > > > issued before the status for the task is acknowledged. > > > > I have no problem with these two. > > > > > I'll be glad to see any technical reasons that I am > > > overlooking, that require two codes. > > > > See above. This is somewhat analogous to the "if in doubt, > negotiate > > it" principle for login - telling the other side *exactly* > what is wanted > > is more robust than assuming that it will do what is wanted, and in > > this resegmenting Data SNACK case, there are potentially nasty > > consequences to an incorrect assumption. Does this make any sense? > > I see what you're trying to get at. However, IMHO, there is > no "assuming" > involved here. If the protocol works right, it should do the > right thing. Or else, > we are in serious trouble despite this change. > > Regards. > -- > Mallikarjun > > Mallikarjun Chadalapaka > Networked Storage Architecture > Network Storage Solutions > Hewlett-Packard MS 5668 > Roseville CA 95747 > cbm@rose.hp.com > > From owner-ips@ece.cmu.edu Fri Jul 12 01:29:05 2002 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA27106 for ; Fri, 12 Jul 2002 01:29:05 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id g6C4nWS01267 for ips-outgoing; Fri, 12 Jul 2002 00:49:32 -0400 (EDT) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from eumenes.hosting.pacbell.net (eumenes.hosting.pacbell.net [216.100.98.24]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id g6C4nSX01260 for ; Fri, 12 Jul 2002 00:49:28 -0400 (EDT) Received: from ron (61-226-102-214.HINET-IP.hinet.net [61.226.102.214]) by eumenes.hosting.pacbell.net id AAA25932; Fri, 12 Jul 2002 00:49:13 -0400 (EDT) [ConcentricHost SMTP Relay 1.14] Message-ID: <025601c2295e$65d556a0$1a0aa8c0@crimson.com.tw> From: "Ron Kao" To: References: Subject: remove Date: Thu, 11 Jul 2002 20:40:22 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2600.0000 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 Sender: owner-ips@ece.cmu.edu Precedence: bulk Content-Transfer-Encoding: 7bit From owner-ips@ece.cmu.edu Fri Jul 12 01:31:11 2002 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA27225 for ; Fri, 12 Jul 2002 01:31:11 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id g6C50pB01886 for ips-outgoing; Fri, 12 Jul 2002 01:00:51 -0400 (EDT) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from eumenes.hosting.pacbell.net (eumenes.hosting.pacbell.net [216.100.98.24]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id g6C50nX01881 for ; Fri, 12 Jul 2002 01:00:49 -0400 (EDT) Received: from ron (61-226-102-214.HINET-IP.hinet.net [61.226.102.214]) by eumenes.hosting.pacbell.net id BAA01630; Fri, 12 Jul 2002 01:00:46 -0400 (EDT) [ConcentricHost SMTP Relay 1.14] Message-ID: <02a501c22960$02b34ee0$1a0aa8c0@crimson.com.tw> From: "Ron Kao" To: References: <277DD60FB639D511AC0400B0D068B71E0564C06F@CORPMX14> Subject: remove Date: Thu, 11 Jul 2002 21:42:08 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2600.0000 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 Sender: owner-ips@ece.cmu.edu Precedence: bulk Content-Transfer-Encoding: 7bit From owner-ips@ece.cmu.edu Fri Jul 12 03:27:32 2002 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA09829 for ; Fri, 12 Jul 2002 03:27:31 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id g6C6nfB06854 for ips-outgoing; Fri, 12 Jul 2002 02:49:41 -0400 (EDT) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from mel-rto3.wanadoo.fr (smtp-out-3.wanadoo.fr [193.252.19.233]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id g6C6ndX06849 for ; Fri, 12 Jul 2002 02:49:39 -0400 (EDT) Received: from mel-rta7.wanadoo.fr (193.252.19.61) by mel-rto3.wanadoo.fr (6.5.007) id 3D1848E600984964 for ips@ece.cmu.edu; Fri, 12 Jul 2002 08:49:33 +0200 Received: from Win95Gbt.wanadoo.fr (217.128.171.66) by mel-rta7.wanadoo.fr (6.5.007) id 3D2A78FA001A9A83 for ips@ece.cmu.edu; Fri, 12 Jul 2002 08:49:32 +0200 Message-ID: <002901c22970$e7d88d40$0b0101c0@Win95Gbt.wanadoo.fr> From: "Gilles BERTILLOT" To: Subject: remove Date: Fri, 12 Jul 2002 08:54:01 +0200 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0026_01C22981.AB1698A0" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 4.72.2106.4 X-MimeOLE: Produced By Microsoft MimeOLE V4.72.2106.4 Sender: owner-ips@ece.cmu.edu Precedence: bulk Message en plusieurs parties et au format MIME. ------=_NextPart_000_0026_01C22981.AB1698A0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable ------=_NextPart_000_0026_01C22981.AB1698A0 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable

 
------=_NextPart_000_0026_01C22981.AB1698A0-- From owner-ips@ece.cmu.edu Fri Jul 12 10:09:28 2002 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA23389 for ; Fri, 12 Jul 2002 10:09:28 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id g6CDXNF06450 for ips-outgoing; Fri, 12 Jul 2002 09:33:23 -0400 (EDT) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from e21.nc.us.ibm.com (e21.nc.us.ibm.com [32.97.136.227]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id g6CDXLX06446 for ; Fri, 12 Jul 2002 09:33:21 -0400 (EDT) Received: from westrelay02.boulder.ibm.com (westrelay02.boulder.ibm.com [9.17.194.23]) by e21.nc.us.ibm.com (8.12.2/8.12.2) with ESMTP id g6CDXKRY137698 for ; Fri, 12 Jul 2002 09:33:20 -0400 Received: from d25ml53 (D25ML54T.mkm.can.ibm.com [9.29.138.20]) by westrelay02.boulder.ibm.com (8.11.1m3/NCO/VER6.2) with ESMTP id g6CDXIY173042 for ; Fri, 12 Jul 2002 07:33:18 -0600 Importance: Normal Subject: remove To: ips@ece.cmu.edu X-Mailer: Lotus Notes Release 5.0.5 September 22, 2000 Message-ID: From: "Brian Sherman/Markham/IBM" Date: Fri, 12 Jul 2002 09:33:17 -0400 X-MIMETrack: Serialize by Router on D25ML54/25/M/IBM(Release 5.0.9a |January 7, 2002) at 07/12/2002 09:33:18 AM MIME-Version: 1.0 Sender: owner-ips@ece.cmu.edu Precedence: bulk From owner-ips@ece.cmu.edu Fri Jul 12 10:54:53 2002 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA25883 for ; Fri, 12 Jul 2002 10:54:53 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id g6CEF6L09196 for ips-outgoing; Fri, 12 Jul 2002 10:15:06 -0400 (EDT) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from cygnus.equallogic.com (cygnus.equallogic.com [65.170.102.10]) by ece.cmu.edu (8.11.0/8.10.2) with SMTP id g6CEF4X09192 for ; Fri, 12 Jul 2002 10:15:04 -0400 (EDT) Received: from cygnus.equallogic.com (localhost.localdomain [127.0.0.1]) by cygnus.equallogic.com (8.11.6/8.11.6) with ESMTP id g6CEExC26818 for ; Fri, 12 Jul 2002 10:14:59 -0400 Received: from deneb.dev.equallogic.com (deneb.dev.equallogic.com [172.16.1.99]) by cygnus.equallogic.com (8.11.6/8.11.6) with ESMTP id g6CEEwQ26806; Fri, 12 Jul 2002 10:14:58 -0400 Received: from pkoning.dev.equallogic.com.equallogic.com (localhost.localdomain [127.0.0.1]) by deneb.dev.equallogic.com (8.11.6/8.11.6) with SMTP id g6CEEwq29831; Fri, 12 Jul 2002 10:14:58 -0400 MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Message-ID: <15662.58466.91507.103416@pkoning.dev.equallogic.com> Date: Fri, 12 Jul 2002 10:14:58 -0400 From: Paul Koning To: vince_cavanna@agilent.com Cc: Black_David@emc.com, ips@ece.cmu.edu, tom@arcot.com Subject: RE: IPS security draft: SRP groups References: <01A7DAF31F93D511AEE300D0B706ED9201BF49EF@axcs13.cos.agilent.com> X-Mailer: VM 7.01 under 21.1 (patch 11) "Carlsbad Caverns" XEmacs Lucid Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ece.cmu.edu id g6CEF5X09193 Sender: owner-ips@ece.cmu.edu Precedence: bulk Content-Transfer-Encoding: 8bit >>>>> "vince" == vince cavanna writes: vince> Hi David, I can't prove so, but Mathematica from Wolfram vince> certifies as prime (in a matter seconds) all five moduli vince> specified in the iSCSI security draft for use in SRP! I used vince> the PrimeQ built-in function. PrimeQ first tests for vince> divisibility using small primes, then uses the Miller­Rabin vince> strong pseudoprime test base 2 and base 3, and then uses a vince> Lucas test. I have not explored the nature of these tests. Miller-Rabin is a probabilistic test. As for "Lucas" -- the Handbook of Applied Cryptography lists "Lucas-Lehmer primality test for Mersenne numbers". That suggests that this test has no meaning for numbers that aren't Mersenne numbers (such as randomly chosen numbers). So I think you have a probabilistic primality test here, similar to what Tom did. That's certainly useful confirmation, but it doesn't sound like we have the primality proofs yet. (Unfortunately, HAC is not sufficiently helpful in pointing to an algorithm to to so...) paul From owner-ips@ece.cmu.edu Fri Jul 12 12:53:51 2002 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA03260 for ; Fri, 12 Jul 2002 12:53:50 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id g6CGBOb17165 for ips-outgoing; Fri, 12 Jul 2002 12:11:24 -0400 (EDT) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from msgbas1.cos.agilent.com (msgbas1x.cos.agilent.com [192.25.240.36]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id g6CGBMX17160 for ; Fri, 12 Jul 2002 12:11:22 -0400 (EDT) Received: from msgrel1t.cos.agilent.com (msgrel1t.cos.agilent.com [130.29.152.157]) by msgbas1.cos.agilent.com (Postfix) with ESMTP id 74B8CBD9B; Fri, 12 Jul 2002 10:11:21 -0600 (MDT) Received: from axcsbh4.cos.agilent.com (axcsbh4.cos.agilent.com [130.29.152.145]) by msgrel1t.cos.agilent.com (Postfix) with SMTP id AB404579; Fri, 12 Jul 2002 10:11:20 -0600 (MDT) Received: from 130.29.152.145 by axcsbh4.cos.agilent.com (InterScan E-Mail VirusWall NT); Fri, 12 Jul 2002 10:11:19 -0600 Received: by axcsbh4.cos.agilent.com with Internet Mail Service (5.5.2653.19) id <3YPNNQVM>; Fri, 12 Jul 2002 10:11:19 -0600 Message-ID: <01A7DAF31F93D511AEE300D0B706ED9201BF49F0@axcs13.cos.agilent.com> From: vince_cavanna@agilent.com To: ni1d@arrl.net, vince_cavanna@agilent.com Cc: Black_David@emc.com, ips@ece.cmu.edu, tom@arcot.com Subject: RE: IPS security draft: SRP groups Date: Fri, 12 Jul 2002 10:11:16 -0600 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ece.cmu.edu id g6CGBMX17162 Sender: owner-ips@ece.cmu.edu Precedence: bulk Content-Transfer-Encoding: 8bit Hi Paul, I suspected as much, since I don't have a supercomputer on my desktop. Mathematica apparently also has the capability to perform a mathematical proof of primality and to produce a "certificate" using which Mathematica's results may be independently and easily verified. When I attempted to perform the proof on the smallest modulus (the one with 768 bits) my computer was rendered useless for over 20 minutes which just happened to be my threshold of tolerance for this morning. I will try again when I leave the office tonight and if I get any useful results I will look deeper into the method. Vince |-----Original Message----- |From: Paul Koning [mailto:ni1d@arrl.net] |Sent: Friday, July 12, 2002 7:15 AM |To: vince_cavanna@agilent.com |Cc: Black_David@emc.com; ips@ece.cmu.edu; tom@arcot.com |Subject: RE: IPS security draft: SRP groups | | |>>>>> "vince" == vince cavanna writes: | | vince> Hi David, I can't prove so, but Mathematica from Wolfram | vince> certifies as prime (in a matter seconds) all five moduli | vince> specified in the iSCSI security draft for use in SRP! I used | vince> the PrimeQ built-in function. PrimeQ first tests for | vince> divisibility using small primes, then uses the Miller­Rabin | vince> strong pseudoprime test base 2 and base 3, and then uses a | vince> Lucas test. I have not explored the nature of these tests. | |Miller-Rabin is a probabilistic test. As for "Lucas" -- the Handbook |of Applied Cryptography lists "Lucas-Lehmer primality test for |Mersenne numbers". That suggests that this test has no meaning for |numbers that aren't Mersenne numbers (such as randomly chosen |numbers). | |So I think you have a probabilistic primality test here, similar to |what Tom did. That's certainly useful confirmation, but it doesn't |sound like we have the primality proofs yet. (Unfortunately, HAC is |not sufficiently helpful in pointing to an algorithm to to so...) | | paul | From owner-ips@ece.cmu.edu Fri Jul 12 13:48:50 2002 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA05725 for ; Fri, 12 Jul 2002 13:48:48 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id g6CHESl21541 for ips-outgoing; Fri, 12 Jul 2002 13:14:28 -0400 (EDT) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from palrel11.hp.com (palrel11.hp.com [156.153.255.246]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id g6CHEQX21535 for ; Fri, 12 Jul 2002 13:14:26 -0400 (EDT) Received: from core.rose.hp.com (core.rose.hp.com [15.43.208.100]) by palrel11.hp.com (Postfix) with ESMTP id A65A260031D; Fri, 12 Jul 2002 10:14:20 -0700 (PDT) Received: from rose.hp.com (hpsil34.rose.hp.com [15.43.211.225]) by core.rose.hp.com with ESMTP (8.9.3 (PHNE_22672)/8.8.6 SMKit7.02) id KAA21029; Fri, 12 Jul 2002 10:16:12 -0700 (PDT) Message-ID: <3D2F127E.6F21FD7@rose.hp.com> Date: Fri, 12 Jul 2002 10:31:42 -0700 From: "Mallikarjun C." Reply-To: cbm@rose.hp.com Organization: Hewlett-Packard X-Mailer: Mozilla 4.75 [en] (X11; U; HP-UX B.10.20 9000/715) X-Accept-Language: en MIME-Version: 1.0 To: Michael Morrison Cc: iSCSI Subject: Re: iSCSI: Recovery R2T References: <1026420114.20745.187.camel@jackal.engasic.istor.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ips@ece.cmu.edu Precedence: bulk Content-Transfer-Encoding: 7bit Michael, It appears to me that we need to define the term `recovery R2T' - the lack of which David Black also pointed out earlier. Here's what I propose we should define it as: Recovery R2T: It is an R2T generated by a target upon detecting the loss of one or more Data-Out PDUs through one of the following means - a digest error, a sequence error, or a sequence timeout. A recovery R2T carries the next unused R2TSN, but requests part of or the entire data burst that an earlier R2T (with a lower R2TSN) had already requested. I believe the MUST/SHOULD/MAY language contained in Section 6 already defines the expectations on the usage scope of recovery R2T. -- Mallikarjun Mallikarjun Chadalapaka Networked Storage Architecture Network Storage Solutions MS 5668 Hewlett-Packard, Roseville. cbm@rose.hp.com > Michael Morrison wrote: > > > > If an initiator sends multiple Data-Out in response to an R2T, and one > of the Data-Out in the > sequence has a data digest error, can the recovery R2T solicit only > the missing data, or must > it solicit the whole sequence? I can't find anything in the draft > that defines what the contents > of a recovery R2T MUST/SHOULD/MAY contain. > > Thanks > Michael Morrison > ISTOR Networks > 7585 Irvine Center Dr. Ste 250 > Irvine Ca. 92618 > PGP Key: 74C30155 From owner-ips@ece.cmu.edu Fri Jul 12 13:48:54 2002 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA05740 for ; Fri, 12 Jul 2002 13:48:53 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id g6CHOfC22219 for ips-outgoing; Fri, 12 Jul 2002 13:24:41 -0400 (EDT) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from msgbas2.cos.agilent.com (msgbas2x.cos.agilent.com [192.25.240.37]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id g6CHOdX22215 for ; Fri, 12 Jul 2002 13:24:39 -0400 (EDT) Received: from msgrel1.cos.agilent.com (msgrel1.cos.agilent.com [130.29.152.77]) by msgbas2.cos.agilent.com (Postfix) with ESMTP id 0308BBB5 for ; Fri, 12 Jul 2002 11:24:39 -0600 (MDT) Received: from acropora.rose.agilent.com (acropora.rose.agilent.com [130.30.179.5]) by msgrel1.cos.agilent.com (Postfix) with ESMTP id 82AAF1D1 for ; Fri, 12 Jul 2002 11:24:38 -0600 (MDT) Received: (from dbs@localhost) by acropora.rose.agilent.com (8.9.3 (PHNE_18979)/8.9.3 SMKit7.1.0) id KAA27400 for ips@ece.cmu.edu; Fri, 12 Jul 2002 10:22:38 -0700 (PDT) From: Dave Sheehy Message-Id: <200207121722.KAA27400@acropora.rose.agilent.com> Subject: Re: iSCSI: need for new data SNACK code? To: ips@ece.cmu.edu (IETF IP SAN Reflector) Date: Fri, 12 Jul 2002 10:22:37 PDT X-Mailer: Elm [revision: 212.4] Sender: owner-ips@ece.cmu.edu Precedence: bulk Mallikarjun, > >It is free to segment > > to any size <= to that and to change that size, for its own purposes, at > > any point in time w/o notifying the initiator. > > That is correct for the general case, but not for the specific data SNACK > case under discussion - the spec requires the retransmitted PDUs to be > "exact replicas" barring certain header fields, in the absence of a > negotiated max PDU size change. Thanks for the clarification, I missed that when I reviewed the spec yesterday but I see it now. Dave From owner-ips@ece.cmu.edu Fri Jul 12 14:04:57 2002 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA06396 for ; Fri, 12 Jul 2002 14:04:52 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id g6CHkQN23633 for ips-outgoing; Fri, 12 Jul 2002 13:46:26 -0400 (EDT) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from mail1irv.inside.istor.com (host28.istor.com [66.134.214.28]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id g6CHkOX23629 for ; Fri, 12 Jul 2002 13:46:24 -0400 (EDT) Subject: Re: iSCSI: Recovery R2T From: Michael Morrison To: cbm@rose.hp.com Cc: iSCSI In-Reply-To: <3D2F127E.6F21FD7@rose.hp.com> References: <1026420114.20745.187.camel@jackal.engasic.istor.com> <3D2F127E.6F21FD7@rose.hp.com> Content-Type: multipart/alternative; boundary="=-W5nf/73fCVnJHLmpvr73" X-Mailer: Ximian Evolution 1.0.8 Date: 12 Jul 2002 10:43:34 -0700 Message-Id: <1026495814.20745.231.camel@jackal.engasic.istor.com> Mime-Version: 1.0 Sender: owner-ips@ece.cmu.edu Precedence: bulk --=-W5nf/73fCVnJHLmpvr73 Content-Type: text/plain Content-Transfer-Encoding: 7bit Mallikarjun, Your definition looks OK to me. But I'm concerned about the case of DataSequenceInOrder being set to Yes. The R2T text allows the target to send a recovery R2T, but the text in 11.20 says that the initiator cannot send the requested data as it's not a continuously non-decreasing offset. From 9.8 (R2T) DataSequenceInOrder governs the buffer offset ordering in consecu- tive R2Ts. If DataSequenceInOrder is Yes, then consecutive R2Ts SHOULD refer to continuous non-overlapping ranges. From 11.20 If DataSequenceInOrder is set to Yes, Data Sequences MUST be trans- ferred using continuously non-decreasing sequence offsets (R2T buffer offset for writes, or the smallest SCSI Data-In buffer offset within a read data sequence). Mike On Fri, 2002-07-12 at 10:31, Mallikarjun C. wrote: Michael, It appears to me that we need to define the term `recovery R2T' - the lack of which David Black also pointed out earlier. Here's what I propose we should define it as: Recovery R2T: It is an R2T generated by a target upon detecting the loss of one or more Data-Out PDUs through one of the following means - a digest error, a sequence error, or a sequence timeout. A recovery R2T carries the next unused R2TSN, but requests part of or the entire data burst that an earlier R2T (with a lower R2TSN) had already requested. I believe the MUST/SHOULD/MAY language contained in Section 6 already defines the expectations on the usage scope of recovery R2T. -- Mallikarjun Mallikarjun Chadalapaka Networked Storage Architecture Network Storage Solutions MS 5668 Hewlett-Packard, Roseville. cbm@rose.hp.com > Michael Morrison wrote: > > > > If an initiator sends multiple Data-Out in response to an R2T, and one > of the Data-Out in the > sequence has a data digest error, can the recovery R2T solicit only > the missing data, or must > it solicit the whole sequence? I can't find anything in the draft > that defines what the contents > of a recovery R2T MUST/SHOULD/MAY contain. > > Thanks > Michael Morrison > ISTOR Networks > 7585 Irvine Center Dr. Ste 250 > Irvine Ca. 92618 > PGP Key: 74C30155 Michael Morrison ISTOR Networks 7585 Irvine Center Dr. Ste 250 Irvine Ca. 92618 PGP Key: 74C30155 --=-W5nf/73fCVnJHLmpvr73 Content-Type: text/html; charset=utf-8 Mallikarjun,

Your definition looks OK to me.  But I'm concerned about the case of DataSequenceInOrder
being set to Yes.  The R2T text allows the target to send a recovery R2T, but the
text in 11.20 says that the initiator cannot send the requested data as it's not a continuously non-decreasing offset. 

From 9.8 (R2T)
DataSequenceInOrder governs the buffer offset ordering in consecu-
   tive R2Ts. If DataSequenceInOrder is Yes, then consecutive R2Ts
   SHOULD refer to continuous non-overlapping ranges.

From 11.20
If DataSequenceInOrder is set to Yes, Data Sequences MUST be trans-
   ferred using continuously non-decreasing sequence offsets (R2T buffer
   offset for writes, or the smallest SCSI Data-In buffer offset within
   a read data sequence).

Mike

On Fri, 2002-07-12 at 10:31, Mallikarjun C. wrote: 
Michael,

It appears to me that we need to define the term `recovery R2T' - 
the lack of which David Black also pointed out earlier.

Here's what I propose we should define it as:

Recovery R2T: It is an R2T generated by a target upon detecting 
the loss of one or more Data-Out PDUs through one of the following means
- a digest error, a sequence error, or a sequence timeout.  A recovery
R2T carries the next unused R2TSN, but requests part of or the entire
data 
burst that an earlier R2T (with a lower R2TSN) had already requested.

I believe the MUST/SHOULD/MAY language contained in Section 6 already 
defines the expectations on the usage scope of recovery R2T.
-- 
Mallikarjun 


Mallikarjun Chadalapaka
Networked Storage Architecture
Network Storage Solutions
MS 5668	Hewlett-Packard, Roseville.
cbm@rose.hp.com


> Michael Morrison wrote:
> 
> 
> 
> If an initiator sends multiple Data-Out in response to an R2T, and one
> of the Data-Out in the
> sequence has a data digest error, can the recovery R2T solicit only
> the missing data, or must
> it solicit the whole sequence?   I can't find anything in the draft
> that defines what the contents
> of a recovery R2T MUST/SHOULD/MAY contain.
> 
> Thanks
> Michael Morrison
> ISTOR Networks
> 7585 Irvine Center Dr. Ste 250
> Irvine Ca. 92618
> PGP Key: 74C30155
Michael Morrison
ISTOR Networks
7585 Irvine Center Dr. Ste 250
Irvine Ca. 92618
PGP Key: 74C30155
--=-W5nf/73fCVnJHLmpvr73-- From owner-ips@ece.cmu.edu Fri Jul 12 15:10:20 2002 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA09637 for ; Fri, 12 Jul 2002 15:10:20 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id g6CIeRb27376 for ips-outgoing; Fri, 12 Jul 2002 14:40:27 -0400 (EDT) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from best.eurologic.com ([213.190.135.5]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id g6CIePX27372 for ; Fri, 12 Jul 2002 14:40:25 -0400 (EDT) Received: from there (wombat [192.168.7.41]) by best.eurologic.com (8.9.3+Sun/8.9.3) with SMTP id TAA05696; Fri, 12 Jul 2002 19:40:09 +0100 (BST) Message-Id: <200207121840.TAA05696@best.eurologic.com> Content-Type: text/plain; charset="iso-8859-1" From: Ken Sandars Organization: Eurologic Systems To: Black_David@emc.com, Julian_Satran@il.ibm.com Subject: Re: iSCSI: DLB's [T.6] 2.3 iSCSI Session Types Date: Fri, 12 Jul 2002 19:39:04 +0000 X-Mailer: KMail [version 1.3.1] Cc: ips@ece.cmu.edu References: <277DD60FB639D511AC0400B0D068B71E0564C065@CORPMX14> In-Reply-To: <277DD60FB639D511AC0400B0D068B71E0564C065@CORPMX14> MIME-Version: 1.0 Content-Transfer-Encoding: 8bit Sender: owner-ips@ece.cmu.edu Precedence: bulk Content-Transfer-Encoding: 8bit Hi all, I'm wondering what the preferred mechanism is for a target to force an initiator to close a discovery session. In the case ot a normal session, the AM-"target requests logout" pdu is allowed (I guess AM types 1-3 apply). So should we follow this model for discovery sessions, or just hit 'em with a FIN? Thanks, Ken -- Ken Sandars Eurologic Systems Ltd ksandars@eurologic.com On Thursday 11 July 2002 5:01 am, Black_David@emc.com wrote: > Julian > > > I can agree with MUST but I will resist adding any notification. > > > > It is just the wrong thing to do. > > I don't care - getting to a MUST with a list of allowed PDUs that > forbids all others from the current MAY that allows everything is > what matters to me. > > At the moment, I've only seen Ayman ask for Async Message to be > allowed on discovery sessions - does anyone else want to see that > PDU allowed on discovery sessions? > > 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 > --------------------------------------------------- From owner-ips@ece.cmu.edu Fri Jul 12 15:59:54 2002 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA12331 for ; Fri, 12 Jul 2002 15:59:53 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id g6CJN2V00489 for ips-outgoing; Fri, 12 Jul 2002 15:23:02 -0400 (EDT) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from palrel12.hp.com (palrel12.hp.com [156.153.255.237]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id g6CJN0X00484 for ; Fri, 12 Jul 2002 15:23:00 -0400 (EDT) Received: from core.rose.hp.com (core.rose.hp.com [15.43.208.100]) by palrel12.hp.com (Postfix) with ESMTP id AD7FAE00548; Fri, 12 Jul 2002 12:22:59 -0700 (PDT) Received: from swathi (swathi.rose.hp.com [15.43.213.237]) by core.rose.hp.com with SMTP (8.9.3 (PHNE_22672)/8.8.6 SMKit7.02) id MAA12401; Fri, 12 Jul 2002 12:24:52 -0700 (PDT) Message-ID: <005101c229d9$88581070$edd52b0f@rose.hp.com> From: "Mallikarjun C." To: "Michael Morrison" Cc: "iSCSI" References: <1026420114.20745.187.camel@jackal.engasic.istor.com> <3D2F127E.6F21FD7@rose.hp.com> <1026495814.20745.231.camel@jackal.engasic.istor.com> Subject: Re: iSCSI: Recovery R2T Date: Fri, 12 Jul 2002 12:22:59 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2600.0000 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 Sender: owner-ips@ece.cmu.edu Precedence: bulk Content-Transfer-Encoding: 7bit Michael, You're referring to a different, but related issue now. We had debated your new issue in the past, look at the last para in section 11.20. -- Mallikarjun Mallikarjun Chadalapaka Networked Storage Architecture Network Storage Solutions Hewlett-Packard MS 5668 Roseville CA 95747 cbm@rose.hp.com ----- Original Message ----- From: "Michael Morrison" To: Cc: "iSCSI" Sent: Friday, July 12, 2002 10:43 AM Subject: Re: iSCSI: Recovery R2T > Mallikarjun, > > Your definition looks OK to me. But I'm concerned about the case of > DataSequenceInOrder > being set to Yes. The R2T text allows the target to send a recovery > R2T, but the > text in 11.20 says that the initiator cannot send the requested data as > it's not a continuously non-decreasing offset. > > >From 9.8 (R2T) > DataSequenceInOrder governs the buffer offset ordering in consecu- > tive R2Ts. If DataSequenceInOrder is Yes, then consecutive R2Ts > SHOULD refer to continuous non-overlapping ranges. > > >From 11.20 > If DataSequenceInOrder is set to Yes, Data Sequences MUST be trans- > ferred using continuously non-decreasing sequence offsets (R2T buffer > offset for writes, or the smallest SCSI Data-In buffer offset within > a read data sequence). > > Mike > > On Fri, 2002-07-12 at 10:31, Mallikarjun C. wrote: > > Michael, > > It appears to me that we need to define the term `recovery R2T' - > the lack of which David Black also pointed out earlier. > > Here's what I propose we should define it as: > > Recovery R2T: It is an R2T generated by a target upon detecting > the loss of one or more Data-Out PDUs through one of the following means > - a digest error, a sequence error, or a sequence timeout. A recovery > R2T carries the next unused R2TSN, but requests part of or the entire > data > burst that an earlier R2T (with a lower R2TSN) had already requested. > > I believe the MUST/SHOULD/MAY language contained in Section 6 already > defines the expectations on the usage scope of recovery R2T. > -- > Mallikarjun > > > Mallikarjun Chadalapaka > Networked Storage Architecture > Network Storage Solutions > MS 5668 Hewlett-Packard, Roseville. > cbm@rose.hp.com > > > > Michael Morrison wrote: > > > > > > > > If an initiator sends multiple Data-Out in response to an R2T, and one > > of the Data-Out in the > > sequence has a data digest error, can the recovery R2T solicit only > > the missing data, or must > > it solicit the whole sequence? I can't find anything in the draft > > that defines what the contents > > of a recovery R2T MUST/SHOULD/MAY contain. > > > > Thanks > > Michael Morrison > > ISTOR Networks > > 7585 Irvine Center Dr. Ste 250 > > Irvine Ca. 92618 > > PGP Key: 74C30155 > > Michael Morrison > ISTOR Networks > 7585 Irvine Center Dr. Ste 250 > Irvine Ca. 92618 > PGP Key: 74C30155 > > From owner-ips@ece.cmu.edu Fri Jul 12 16:01:30 2002 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA12489 for ; Fri, 12 Jul 2002 16:01:25 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id g6CJKIv00312 for ips-outgoing; Fri, 12 Jul 2002 15:20:18 -0400 (EDT) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from palrel12.hp.com (palrel12.hp.com [156.153.255.237]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id g6CJKFX00304 for ; Fri, 12 Jul 2002 15:20:15 -0400 (EDT) Received: from core.rose.hp.com (core.rose.hp.com [15.43.208.100]) by palrel12.hp.com (Postfix) with ESMTP id 95156E00548; Fri, 12 Jul 2002 12:20:11 -0700 (PDT) Received: from swathi (swathi.rose.hp.com [15.43.213.237]) by core.rose.hp.com with SMTP (8.9.3 (PHNE_22672)/8.8.6 SMKit7.02) id MAA12096; Fri, 12 Jul 2002 12:22:03 -0700 (PDT) Message-ID: <004801c229d9$23f97bf0$edd52b0f@rose.hp.com> From: "Mallikarjun C." To: Cc: References: <277DD60FB639D511AC0400B0D068B71E0564C06F@CORPMX14> Subject: Re: iSCSI: need for new data SNACK code? Date: Fri, 12 Jul 2002 12:20:10 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2600.0000 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 Sender: owner-ips@ece.cmu.edu Precedence: bulk Content-Transfer-Encoding: 7bit David, I see some convergence, but still disagreement on several aspects. There's an attempt to summarize the options at the bottom, and I'd prefer that others or the process co-chair to comment, rather than continue with this thread with us two alone going back and forth. > The flag per task is not needed - I'd expect the Target to look > at the Data PDUs it would have to resend, check them against the max > Data PDU size for this connection and fail the regular SNACK if any > PDU is too large I am afraid there's no free lunch here. In this description, you're now expecting targets to maintain the PDU size of every PDU that it shipped for each of the tasks, which causes a metadata explosion. This was discussed by Eddy Quicksall and myself in an earlier thread - "changing MaxPDUDataLength". >If the permission is not used, the Initiator's > status SNACK is not needed but does no harm. Well, the point is - shouldn't the target be detecting these obvious bugs, and attempting recovery/fix for these errors (it's a clear disconnect b/n target and initiator state). Seems like additional complexity on either end - to cover implementation bugs wrt prior synchronization. > As the complexity of a protocol increases, that synchronized > state machine assumption becomes more prone to failure. I think this is where the major disconnect is between us. As I responded to Dave Sheehy yesterday, the iSCSI protocol specification *mandates* that a target must ship "exact replicas" of the data PDUs barring certain header fields unless the PDU size was changed by an intermediate successful text negotiation. What you're suggesting is: despite this mandate, target may resegment illegally, so let's define a new data SNACK code with identical wire semantics. >and for an initiator to expects to be able to do > this with uninterrupted high performance is unrealistic .. >right sort of incentives in discouraging > initiators from changing the max Data PDU size. You're making an incorrect assumption here that it's just the initiators that are likely to change the max PDU size. Either party can do it - and was the whole point behind the recent addition of "negotiation prompt" Async Message. (Initiator, on the prompt, may respond with a blank Text Request PDU.) It's for this precise reason that my option (a) limits *data SNACKs* while "any text negotiation" is in progress. Now, on to your proposal... > That strikes me as a productive direction that I could see enforcing > An initiator that wants to be able to issue a Data SNACK for > some or all of its commands then has to ensure that no such > commands are outstanding when/while it changes (in particular > reduces) the max Data PDU size. I am afraid you may have misunderstood what I was suggesting. I was *not* suggesting that PDU size must not be renegotiated with outstanding tasks. In stead, I was suggesting that there be no *data SNACKs* while any text negotiation is going on (meaning that SNACKs can be issued after the negotiation completes, so the initiator can definitively throw out the status PDU for all tasks with data recovery needs). There's one weird corner case in the simplified option you're suggesting here - when a target wants to initiate a max PDU size change, it cannot know when the initiator is likely to quiesce the I/Os, nor there's a way to tell the initiator to stop. One way to deal with this - target issues a "negotiation prompt", and the initiator responds with a Text Request PDU only *after* all active tasks are completed and their statuses acknowledged. This of course has the obvious drawback that negotiation/declaration attempts by the target for *any key* would be rebuffed by the initiator until the connection is quiesced. With that said, let me suvey the available options: Option.A - Keep the rev13 text, plus add the two additional text segments I proposed on the beginning of this thread (initiators must drop status in one case, SNACK must be issued only before the status is ack'ed), *and* add "no data SNACKs while any text negotiation is on". Pros: - No need for a new data SNACK code with identical wire semantics - Can allow the PDU size change to happen with no wait for quiescing any long running writes/reads (and those operations too benefit from ULPDU containment from this changed PDU size). Cons: - Additional complexity (compared to the standard data SNACK) on the initiator to drop the status SNACK; and to mark all active tasks while the PDU change had happened, so their statuses can dropped if necessary. Option.B - Same as Option.A, but add the new resegmenting-Data SNACK code per David's Last Call comment. Pros: - Precludes surprises due to implementation errors (also a con, see below) - Can allow the PDU size change to happen with no wait for quiescing any long running writes/reads (and those operations too benefit from ULPDU containment from this changed PDU size). Cons: - Attempt to address an implementation error by protocol means, could be a slippery slope. - Requires a new data SNACK code which both sides have to handle, and which conveys completely redundant information about the changed PDU size. - Additional complexity (compared to the standard data SNACK) on the initiator to drop the status SNACK; and to mark all active tasks while the PDU change had happened, so their statuses can be dropped if necessary. Option.C - Completely disallow PDU size changes (initiated by either party) while any tasks are active. Rev13 text should be stripped of the resegmenting discussion. Any data SNACK always gets exact replicas. Pros: - Simpler approach, initiators don't need to drop status PDUs, nor mark the active tasks. Cons: - Active tasks cannot dynamically adapt to PMTU degradation, so ULPDU containment isn't always guaranteed - particulary painful for long-running tasks for either party. - Desired changes in max PDU size would need to wait for all tasks to quiesce and the statuses be acknowledged, forcing a pause in the I/O activity. - Any text negotiation prompted by the target can't be carried on until all active I/Os are quiesced (even if the target intends to negotiate other keys). I prefer Option.A, followed by Option.B. Option.C's cons appear to outweigh its simplicity, so wouldn't prefer that. Regards. -- Mallikarjun Mallikarjun Chadalapaka Networked Storage Architecture Network Storage Solutions Hewlett-Packard MS 5668 Roseville CA 95747 cbm@rose.hp.com ----- Original Message ----- From: To: Cc: Sent: Thursday, July 11, 2002 8:42 PM Subject: RE: iSCSI: need for new data SNACK code? > Mallikarjun, > > > > The new code > > > provides the initiator with a more robust way to detect resegmentation > > > by requiring the initiator to explicitly ask for it. The initiator > > > can take a simple approach of always starting with the existing > > > Data SNACK code that does not resegment and only using the new code > > > when the non-resegmenting SNACK doesn't work. > > > > That's one approach. So, let's note that you're expecting the target > > to maintain a "PDU-size-changed" flag for every active task, and > > expecting it to fail the "regular" data SNACK if the flag is set. > > The flag per task is not needed - I'd expect the Target to look > at the Data PDUs it would have to resend, check them against the max > Data PDU size for this connection and fail the regular SNACK if any > PDU is too large. This could even be lazily evaluated at the time > each PDU is to be sent because the odds are that if resegmenting > is necessary, the first Data PDU to be resent is going to need it. > The initiator still has to time out the failure of all the Data > PDUs to arrive in order to deal with header corruption (unfortunately, > the F bit doesn't help) - when it times out the "regular" Data SNACK, > it issues a "resegmenting" one (this deals with resegmenting that > becomes necessary after the first Data PDU for a Data SNACK has > been sent). > > > Some issues - > > a) would it really cover the (impossible, IMHO) case you're attempting > > to cover, in the face of multiple PDU size changes? > > Should work - permission to resegment includes permission to > re-resegment or worse. Independent of how many size changes > happen, the status SNACK at the end returns a new status with > an ExpDataSN that reflects the right number of Data PDUs sent. > > > b) assuming that there indeed is a disconnect b/n the two, > > what should the target do when a resegmenting data SNACK > > is received, but there's no PDU size change? I hope you > > aren't mandating the specific approach. > > Resegmenting SNACK is "permission to resegment", and the target need > not use that permission. If the permission is not used, the Initiator's > status SNACK is not needed but does no harm. > > > c) this approach costs one additional round-trip delay, where > > none is necessary (as argued below). > > I make no apologies for spending a round trip to remove a data > corruption risk. This is a rare case with a possibly nasty failure > mode - I'm much more interested in this working right than fast. > > > d) seems like it would need new Reject code(s) to distinguish > > a "regular" reject from that of the PDU size change ones. > > Could be useful, but is not strictly necessary. > > > >If the target makes > > > its own choice to resegment, and the initiator doesn't think the > > > target resegmented, > > > > Now this is beginning to feel more like the option A vs B vs C debate > > we had a while ago. If the protocol works correctly, both sides would > > be *completely synchronized* on the fact of PDU size change. > > As the complexity of a protocol increases, that synchronized > state machine assumption becomes more prone to failure. The > whole discussion of default values for text keys and the resulting > "if in doubt, negotiate it" maxim was one example. The alternative > of relying on every default key value to be what was expected was > significantly less robust. > > > There are two options for initiators to deal with this - > > > > a) don't issue any data SNACKs while any text negotiation is > > in progress - wait till the text response is received successfully. > > That strikes me as a productive direction that I could see enforcing > with some "MUST"s / "MUST NOT"s - the initiator is causing this mess > by changing the max Data PDU size on the connection. This is not a > friendly thing to do, and for an initiator to expects to be able to do > this with uninterrupted high performance is unrealistic ... so imposing > costs on the initiator for making this disruptive size change makes sense. > > Suppose we went back to the old approach where Data SNACKs *never* > resegment and required that: > - Initiators MUST NOT issue Data SNACKs that could require > resegmentation? > - Targets MUST reject or ignore Data SNACKs that require > resegmentation. > - If resegmentation becomes necessary during retransmission > of Data PDUs for a Data SNACK, PDUs retransmission > MUST cease for that Data SNACK. > An initiator that wants to be able to issue a Data SNACK for > some or all of its commands then has to ensure that no such > commands are outstanding when/while it changes (in particular > reduces) the max Data PDU size. In the limit, the initiator > has to wait for all of its commands on the connection to > complete before changing the max Data PDU size, and not > start any new ones until the size change is complete. > > This is simpler and more robust than any of the options under > discussion and has the right sort of incentives in discouraging > initiators from changing the max Data PDU size. > > Can you accept this? I would expect widespread support for > the resulting removal of target resegmentation from iSCSI. > > I will however answer one more question ... > > > > This requires additional Initiator > > > state per command for something that almost never happens, and if it > > > gets one of these markings wrong, > > > > Sorry, how is it different from the target getting wrong one > > of its aforementioned > > "PDU-size-changed" flags for tasks? > > (1) The per-task flags aren't needed - see above. > (2) The failure is harmless - if the target fails to resegment and > sends a PDU that is too large, the initiator discards it, > and then decides what to do about the broken target. There's > no possibility of completing a READ command without all of its > data. > > 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 > --------------------------------------------------- > > > > -----Original Message----- > > From: Mallikarjun C. [mailto:cbm@rose.hp.com] > > Sent: Thursday, July 11, 2002 7:46 PM > > To: Black_David@emc.com > > Cc: ips@ece.cmu.edu > > Subject: Re: iSCSI: need for new data SNACK code? > > > > > > David, comments in text. > > > > > I disagree with the "careful enough" characterization. The new code > > > provides the initiator with a more robust way to detect resegmentation > > > by requiring the initiator to explicitly ask for it. The initiator > > > can take a simple approach of always starting with the existing > > > Data SNACK code that does not resegment and only using the new code > > > when the non-resegmenting SNACK doesn't work. > > > > That's one approach. So, let's note that you're expecting > > the target to maintain > > a "PDU-size-changed" flag for every active task, and > > expecting it to fail the > > "regular" data SNACK if the flag is set. > > > > Some issues - > > a) would it really cover the (impossible, IMHO) case > > you're attempting > > to cover, in the face of multiple PDU size changes? > > b) assuming that there indeed is a disconnect b/n the > > two, what should the > > target do when a resegmenting data SNACK is received, > > but there's no > > PDU size change? I hope you aren't mandating the > > specific approach. > > c) this approach costs one additional round-trip delay, > > where none is > > necessary (as argued below). > > d) seems like it would need new Reject code(s) to > > distinguish a "regular" reject > > from that of the PDU size change ones. > > > > >If the target makes > > > its own choice to resegment, and the initiator doesn't think the > > > target resegmented, > > > > Now this is beginning to feel more like the option A vs B vs C debate > > we had a while ago. If the protocol works correctly, both sides would > > be *completely synchronized* on the fact of PDU size change. > > > > There are two options for initiators to deal with this - > > > > a) don't issue any data SNACKs while any text negotiation is > > in progress - > > wait till the text response is received successfully. > > > > OR > > > > b) issue a data SNACK regardless, and if the text response > > (that indicates > > a PDU size change) arrives before the data burst > > completes, discard the > > status PDU, and ask for its retransmission. > > > > Option a is what I suggest, and b is for the adventurous sort. > > > > >there are error scenarios that combine this with > > > corrupt Data PDU headers to cause the initiator to successfully > > > complete a SCSI command that has not delivered all its data > > > (the resegmented PDUs caused the Data PDU count to match > > the ExpDataSN > > > value in the response that should have been discarded, but wasn't). > > > > Which is precisely why I'm suggesting that we mandate discarding the > > status PDU. What am I missing? > > > > > While these should be rare, their consequences can be catastrophic. > > > > > > It is conveying the Initiator's instructions that resegmentation is > > > permitted. I am not comfortable with the last sentence > > above that assumes > > > that the Initiator and Target will always have identical > > views of all of > > > the effects of a full feature phase PDU size change - (which is > > > a rare event to begin with, and hence likely to involve code that > > > isn't well exercised/tested). > > > > Obviously, I cannot guarantee the lack of bugs in any implementation. > > But again, let's not attempt to address implementation bugs > > by protocol > > means (that's why we picked option A in the A vs B vs C debate I > > referred to above - see the "reusing ISID for recovery" > > thread; it's for the > > same reason we removed the X-bit for connection reinstatement - > > see the "X-bit in Login" thread). > > > > > > > > > The only two changes from the rev14 text that I propose > > are that we add: > > > > > > > > a) The first status PDU must always be dropped after a > > > > MaxRecvDataSegmentLength change, if ever a data SNACK is > > > > employed for the task. > > > > > > When does this obligation to drop the first status PDU expire? > > > > As it says: when the first status PDU is dropped for the task > > - for each > > active task during a PDU size change, *and* for which a data SNACK > > is/was issued. > > > > >I think > > > the Initiator has to mark all commands that are outstanding > > or become > > > outstanding between the time it starts the negotiation that changes > > > MaxRecvDataSegmentLength and the time that it gets the > > final Text Response > > > of that negotiation from the target. This requires > > additional Initiator > > > state per command for something that almost never happens, and if it > > > gets one of these markings wrong, > > > > Sorry, how is it different from the target getting wrong one > > of its aforementioned > > "PDU-size-changed" flags for tasks? > > > > I believe that the onus should be on the initiator to do what > > it takes to > > do the right recovery - as is the general error recovery > > philosophy everywhere. > > Target cannot predict if the initiator would be interested in > > recovering a > > particular I/O (regardless of the operational ErrorRecoveryLevel). > > > > >it's vulnerable to failing to deliver > > > all the data for a SCSI command in a compound error situation. An > > > alternative with the new code could involve a single bit > > per connection > > > that records whether the PDU size was ever changed (if so, retry any > > > failed Data SNACK as a resegmenting Data SNACK). > > > > Or, use just "the Data SNACK", if we define only one. I > > can't see why this > > optimization needs two data SNACK codes. > > > > > > > > > Initiator MUST issue a status SNACK to recover the > > > > status PDU (i.e. move the onus of retransmitting > > > > status from the target to the initiator). > > > > b) A SNACK requesting an R2T, Data or Status PDU for > > a task MUST be > > > > issued before the status for the task is acknowledged. > > > > > > I have no problem with these two. > > > > > > > I'll be glad to see any technical reasons that I am > > > > overlooking, that require two codes. > > > > > > See above. This is somewhat analogous to the "if in doubt, > > negotiate > > > it" principle for login - telling the other side *exactly* > > what is wanted > > > is more robust than assuming that it will do what is wanted, and in > > > this resegmenting Data SNACK case, there are potentially nasty > > > consequences to an incorrect assumption. Does this make any sense? > > > > I see what you're trying to get at. However, IMHO, there is > > no "assuming" > > involved here. If the protocol works right, it should do the > > right thing. Or else, > > we are in serious trouble despite this change. > > > > Regards. > > -- > > Mallikarjun > > > > Mallikarjun Chadalapaka > > Networked Storage Architecture > > Network Storage Solutions > > Hewlett-Packard MS 5668 > > Roseville CA 95747 > > cbm@rose.hp.com > > > > > From owner-ips@ece.cmu.edu Fri Jul 12 17:22:35 2002 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA15226 for ; Fri, 12 Jul 2002 17:22:32 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id g6CKncB06289 for ips-outgoing; Fri, 12 Jul 2002 16:49:38 -0400 (EDT) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from cygnus.equallogic.com (cygnus.equallogic.com [65.170.102.10]) by ece.cmu.edu (8.11.0/8.10.2) with SMTP id g6CKnbX06284 for ; Fri, 12 Jul 2002 16:49:37 -0400 (EDT) Received: from cygnus.equallogic.com (localhost.localdomain [127.0.0.1]) by cygnus.equallogic.com (8.11.6/8.11.6) with ESMTP id g6CKnVC02063 for ; Fri, 12 Jul 2002 16:49:31 -0400 Received: from deneb.dev.equallogic.com (deneb.dev.equallogic.com [172.16.1.99]) by cygnus.equallogic.com (8.11.6/8.11.6) with ESMTP id g6CKnVQ02054; Fri, 12 Jul 2002 16:49:31 -0400 Received: from pkoning.dev.equallogic.com.equallogic.com (localhost.localdomain [127.0.0.1]) by deneb.dev.equallogic.com (8.11.6/8.11.6) with SMTP id g6CKnVd14185; Fri, 12 Jul 2002 16:49:31 -0400 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <15663.16602.859366.989913@pkoning.dev.equallogic.com> Date: Fri, 12 Jul 2002 16:49:30 -0400 From: Paul Koning To: Julian_Satran@il.ibm.com CC: ips@ece.cmu.edu Subject: Re: iSCSI - decimal coded binary strings - a proposed resolution References: X-Mailer: VM 7.01 under 21.1 (patch 11) "Carlsbad Caverns" XEmacs Lucid Sender: owner-ips@ece.cmu.edu Precedence: bulk Content-Transfer-Encoding: 7bit Sorry, I meant to reply earlier. >>>>> "Julian" == Julian Satran writes: >> 2. On the other hand, for numbers, the proposed rule says >> that you can encode the value in decimal whenever the value >> happens to be less than 2**64. If 5 minutes later that same >> parameter happens to have a value 2**64 or greater, then you >> cannot encode that particular value in decimal. So the >> encoding rule here is tied to the value, not the parameter; a >> given parameter sometimes permits decimal and sometimes not. >> That's what I meant: it is extra complexity to have an >> encoding rule for a variable that isn't the same for all >> possible values of the variable. Julian> +++ that is only an issue for the encoder - and encoding is Julian> not an issue for any of the encoding methods - you send Julian> starting (supposedly) from an internal value of defined Julian> length and may use whatever is fit but we may tight the rule Julian> to allowed values not actual values. Is that acceptable? Julian> +++ No, the issue is in the decoder. If I have a bignum parameter, I have to be prepared to get a decimal encoding coming in. I'd have to feed that to atoi() (or its 64-bit equivalent), take the resulting 64-bit value and supply the high order 0 bits to store it into my bigger-than-64-bits variable. That's extra work for no purpose. paul From owner-ips@ece.cmu.edu Fri Jul 12 20:47:47 2002 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA22151 for ; Fri, 12 Jul 2002 20:47:47 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id g6D09Uc17121 for ips-outgoing; Fri, 12 Jul 2002 20:09:30 -0400 (EDT) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from snjspop2.snjs.qwest.net (snjspop2.snjs.qwest.net [168.103.24.2]) by ece.cmu.edu (8.11.0/8.10.2) with SMTP id g6D09QX17113 for ; Fri, 12 Jul 2002 20:09:27 -0400 (EDT) Received: (qmail 9688 invoked from network); 13 Jul 2002 00:09:26 -0000 Received: from 168-103-213-134.dslgw2.snva.qwest.net (HELO theglowmonster) (168.103.213.134) by snjspop2.snjs.qwest.net with SMTP; 13 Jul 2002 00:09:26 -0000 Date: Fri, 12 Jul 2002 17:06:54 -0700 Message-ID: From: "Randy Jennings" To: "Mallikarjun C." , Black_David@emc.com Cc: ips@ece.cmu.edu Subject: RE: iSCSI: need for new data SNACK code? MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0) X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4910.0300 Importance: Normal In-Reply-To: <004801c229d9$23f97bf0$edd52b0f@rose.hp.com> Sender: owner-ips@ece.cmu.edu Precedence: bulk Content-Transfer-Encoding: 7bit > > The flag per task is not needed - I'd expect the Target to look > > at the Data PDUs it would have to resend, check them against the max > > Data PDU size for this connection and fail the regular SNACK if any > > PDU is too large > > I am afraid there's no free lunch here. In this description, you're now > expecting targets to maintain the PDU size of every PDU that it shipped > for each of the tasks, which causes a metadata explosion. This > was discussed > by Eddy Quicksall and myself in an earlier thread - "changing > MaxPDUDataLength". I did not check the thread, but I remember your conversation with Eddy Quicksall. However, I do not remember what was said about knowing the length of the PDU. From this isolated discussion, though, it seems like you would at least be able to recalculate the length of the PDU at all times or you could never send it again. (Unless you redid all the steps that got to that point in the first place, and I do not think that is possible based off a PDU id number...) Am I missing something? Sincerely, Randy Data Transit From owner-ips@ece.cmu.edu Sat Jul 13 21:51:55 2002 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA10858 for ; Sat, 13 Jul 2002 21:51:55 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id g6E11WT29590 for ips-outgoing; Sat, 13 Jul 2002 21:01:32 -0400 (EDT) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from mailhub.lss.emc.com (xdch.emc.com [168.159.1.79]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id g6E11VX29585 for ; Sat, 13 Jul 2002 21:01:31 -0400 (EDT) Received: from emc.com (emcmail.lss.emc.com [168.159.48.78]) by mailhub.lss.emc.com (Switch-2.2.0/Switch-2.2.0) with ESMTP id g6E11LJ18704; Sat, 13 Jul 2002 21:01:22 -0400 (EDT) Received: from mxic1.isus.emc.com ([168.159.129.100]) by emc.com (8.10.1/8.10.1) with ESMTP id g6E11I709428; Sat, 13 Jul 2002 21:01:21 -0400 (EDT) Received: by MXIC1 with Internet Mail Service (5.5.2653.19) id <31WAK32F>; Sat, 13 Jul 2002 20:59:17 -0400 Message-ID: <277DD60FB639D511AC0400B0D068B71E0564C075@CORPMX14> From: Black_David@emc.com To: cbm@rose.hp.com Cc: ips@ece.cmu.edu Subject: RE: iSCSI: need for new data SNACK code? Date: Sat, 13 Jul 2002 20:59:13 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-ips@ece.cmu.edu Precedence: bulk > > The flag per task is not needed - I'd expect the Target to look > > at the Data PDUs it would have to resend, check them against the max > > Data PDU size for this connection and fail the regular SNACK if any > > PDU is too large > > I am afraid there's no free lunch here. In this description, you're now > expecting targets to maintain the PDU size of every PDU that it shipped > for each of the tasks, which causes a metadata explosion. Targets already have to do that in order to cope with Data SNACKs with non-zero BegRun after a PDU size change. To make this concrete, suppose a target has shipped 4 PDUs with 4K of data each (DataSN 0-3) followed by 4 PDUs with 8K each (DataSN 4-7) and gets a Data SNACK for PDU 5 to the end - how does it figure out that the requested data starts 24K from the beginning? Skipping 5 x 4K of data starts at 20K (middle of PDU 4, wrong), skipping 5 x 8K starts at 40K (PDU 7, also wrong). It looks like the target has to maintain the old size (4K), the new size (8K), and the DataSN that the new size started at (4), which is just enough metadata to "maintain the PDU size of every PDU that it shipped" ... The only obvious way I see to eliminate this "metadata explosion" is to require BegRun to be zero if there's any possibility of resegmentation. That was part of my original comment, but seems to have been dropped. If BegRun=0 is required when resegmentation occurs, then a flag per task would be needed in the target to replace the "metadata explosion". OTOH, this is another way for an initiator to cause serious problems - if it issues a Data SNACK with BegRun != 0 and the target resegments to the new PDU size, the initiator gets the wrong data. > >If the permission is not used, the Initiator's > > status SNACK is not needed but does no harm. > > Well, the point is - shouldn't the target be detecting these > obvious bugs, and attempting > recovery/fix for these errors (it's a clear disconnect b/n > target and initiator state). Seems like > additional complexity on either end - to cover implementation > bugs wrt prior synchronization. It's not an "obvious bug" or an error. There are two different algorithms for a Data SNACK - one in which target resegmentation is prohibited and the initiator does not need to use a Status SNACK due to resegmentation (but may still do so for other reasons), and one in which target resegmentation is permitted and the initiator MUST use a Status SNACK. Switching from one algorithm to the other changes behavior at *both* the target and initiator - the additional Data SNACK code serves to ensure that this change is synchronized by explicitly communicating which algorithm to use. Both algorithms work as long as both parties agree on which one is being used. The additional Data SNACK code puts the initiator unambiguously in charge of algorithm selection. > > As the complexity of a protocol increases, that synchronized > > state machine assumption becomes more prone to failure. > > I think this is where the major disconnect is between us. As > I responded to Dave > Sheehy yesterday, the iSCSI protocol specification *mandates* > that a target must > ship "exact replicas" of the data PDUs barring certain header > fields unless the > PDU size was changed by an intermediate successful text > negotiation. What you're > suggesting is: despite this mandate, target may resegment > illegally, so let's define a > new data SNACK code with identical wire semantics. Actually, I'm much more concerned about an Initiator that doesn't correctly track when the "successful text negotiation" took place with respect to the multitude of outstanding commands it has in various states. The negotiation is not synchronous with respect to the command stream unless all commands on the connection are quiesced, which Mallikarjun does not want to do. If an initiator fails to catch the fact that a target resegmented, the result is corrupt/wrong data for a READ or similar command. > >and for an initiator to expects to be able to do > > this with uninterrupted high performance is unrealistic > .. > >right sort of incentives in discouraging > > initiators from changing the max Data PDU size. > > You're making an incorrect assumption here that it's just the > initiators that are likely to change the max PDU size. Either party > can do it [... snip ...] I don't think so ... MaxRecvDataSegmentLength is "Declarative", so only the initiator can change the initiator's MaxRecvDataSegmentLength. The target can change the target's MaxRecvDataSegmentLength, but that's not relevant to this discussion because targets don't issue SNACKs of any form to initiators. > Now, on to your proposal... > > > That strikes me as a productive direction that I could see enforcing > > An initiator that wants to be able to issue a Data SNACK for > > some or all of its commands then has to ensure that no such > > commands are outstanding when/while it changes (in particular > > reduces) the max Data PDU size. > > I am afraid you may have misunderstood what I was suggesting. Sorry for being unclear. I was following the line of thinking behind Mallikarjun's proposal a) to a conclusion beyond where he took it. I know Mallikarjun didn't suggest removing resegmenting Data SNACKs, and I didn't mean to ascribe that position to him. > There's one weird corner case in the simplified option you're > suggesting here - when a target wants to initiate a max PDU size > change, it cannot know when the initiator is likely to quiesce the > I/Os, nor there's a way to tell the initiator to stop. The "weird corner case" does not exist because MaxRecvDataSegmentLength is "Declarative" - see above. > With that said, let me suvey the available options: Unfortunately, there are a bunch of things wrong with the survey. > Option.A > - Keep the rev13 text, plus add the two additional > text segments I proposed > on the beginning of this thread (initiators must > drop status in one case, SNACK > must be issued only before the status is ack'ed), > *and* add "no data SNACKs while any text negotiation is on". > Pros: - No need for a new data SNACK code with > identical wire semantics > - Can allow the PDU size change to happen > with no wait for quiescing > any long running writes/reads (and > those operations too benefit from ULPDU > containment from this changed PDU size). I disagree with "identical wire semantics" - see discussion of two Data SNACK algorithms above, but agree that not introducing a new Data SNACK code is a Pro. ULPDU containment is irrelevant (more below), and writes do not need to be quiesced, although reads would. > Cons: - Additional complexity (compared to the > standard data SNACK) on the > initiator to drop the status SNACK; > and to mark all active tasks while the > PDU change had happened, so their > statuses can dropped if necessary. Con: Failure to drop SCSI response with good status when required can lead to incorrect/incomplete data being returned. > Option.B > - Same as Option.A, but add the new resegmenting-Data SNACK code per > David's Last Call comment. > Pros: - Precludes surprises due to implementation > errors (also a con, see below) Pro: allows simpler implementations that don't track the state required for Option A. Places the responsibility for state tracking for resegmentation on the target where the resegmentation occurs. > - Can allow the PDU size change to happen > with no wait for quiescing > any long running writes/reads (and > those operations too benefit from ULPDU > containment from this changed PDU size). Only need to quiesce reads; writes aren't affected. ULPDU containment is irrelevant - see below. Pro: Required response drop at the initiator is based on less state that is more directly connected with the Data SNACK that creates the need for the response drop. > Cons: - Attempt to address an implementation error > by protocol means, could be a > slippery slope. I disagree with this Con based on the login "if in doubt, negotiate" maxim. > - Requires a new data SNACK code which > both sides have to handle, and which > conveys completely redundant > information about the changed PDU size. I disagree with "completely redundant" statement. The information being conveyed is an instruction from the initiator about whether the resegmenting Data SNACK algorithm or the non-resegmenting Data SNACK algorithm is in use. > - Additional complexity (compared to the > standard data SNACK) on the > initiator to drop the status SNACK; and > to mark all active tasks while the > PDU change had happened, so their > statuses can be dropped if necessary. I disagree with the "and mark ..." text. Only tasks for which a resegmenting Data SNACK has been issued need be marked. Also, Con: Failure to drop response with good status when required can lead to incorrect/incomplete data being returned. > Option.C > - Completely disallow PDU size changes (initiated > by either party) while any tasks are active. That's not right because MaxRecvDataSegmentLength length is declarative (hence "(initiated by either party)" is wrong, and the description assumes that the Initiator wants to be able to issue Data SNACKs for all tasks (Data SNACKs don't apply to WRITE, etc.). A correct description would be: - Data SNACKs cannot be issued for a task if the initiator has changed its size limit on received Data PDUs while the task is outstanding. Initiators have to ensure that tasks for which Data SNACKs could be issued are not active during such a size limit change. > Rev13 text should be stripped of > the resegmenting discussion. Any > data SNACK always gets exact replicas. > > Pros: - Simpler approach, initiators don't need > to drop status PDUs, nor mark the > active tasks. > Cons: - Active tasks cannot dynamically adapt to > PMTU degradation, so ULPDU > containment isn't always guaranteed - > particulary painful for long-running tasks > for either party. Irrelevant - iSCSI does not require, recommend, or even describe ULPDU containment. TCP ULP framing was removed from the iSCSI draft many months ago after a long controversial discussion. I strongly object to attempting to sneak it back in. Besides, adaptation to PMTU degradation is the transport's job, and iSCSI should not be trying to do the transport's work for it, as it in general does not have direct access to PMTU information. > - Desired changes in max PDU size would > need to wait for all tasks to quiesce > and the statuses be acknowledged, > forcing a pause in the I/O activity. Not "all tasks", rather "reads for which Data SNACK recovery is required if errors occur". Pause in I/O activity is still a distinct possibility (e.g., if all/most tasks are such reads). > - Any text negotiation prompted by the > target can't be carried on until all > active I/Os are quiesced (even if the > target intends to negotiate other keys). Definitely wrong - target can't negotiate this, see above. > I prefer Option.A, followed by Option.B. Option.C's cons > appear to outweigh its simplicity, so wouldn't prefer that. Let's see - the description for option C is wrong, as is one of its Cons, and a second Con is irrelevant leaving only one of the three ... some additional consideration may be in order ... I have enough issues with the attempted survey, that I'm going to try a comparison table (and also to provide something concise for folks to shoot at): First, here's what I believe the A/B/C descriptions are. I'm going to assume for now that BegRun=0 is required for any resegmentation in order to avoid the "metadata explosion" problem. Applies to all options: - Initiators MUST NOT issue SNACKs after the status for the command is ACKed via ExpStatSN. A: - Initiators MUST drop SCSI response and issue a status SNACK when a Data SNACK is issued for a command that was outstanding during an initiator receive data PDU size limit change. - Targets MAY resegment in response to a Data SNACK when the initiator receive data PDU size limit changes while the command is outstanding. - Initiators MUST not issue new Data SNACKs during a change to initiator receive data PDU size limit (and wait for existing data SNACKs to complete before making such a change?). [Aside: It's not clear to me why this is needed, but I'll include it since Mallikarjun asked for it.] B: - New Resegmenting Data SNACK code defined to distinguish behavior in "MAY resegment" and "MUST NOT" resegment cases. - Initiators MUST drop response and issue a status SNACK when a Resegmenting Data SNACK is issued for a command. - Targets MUST NOT resegment in response to an ordinary Data SNACK and MAY resegment in response to a Resegmenting Data SNACK. - No limits appear to be needed on when Data SNACKs can be issued. C: - Resegmentation is forbidden. Initiators MUST NOT issue Data SNACKs that require resegmentation, Targets MUST NOT resegment - Data SNACKs always return "exact replicas" of original PDUs. - No new Data SNACK code, no need to drop otherwise good SCSI responses. +-----------------+-----------+-----------+-----------+ | Attribute | A | B | C | +-----------------+-----------+-----------+-----------+ | SNACK codes | 1 | 2 | 1 | +-----------------+-----------+-----------+-----------+ | Quiesce reads | No | No | Yes | +-----------------+-----------+-----------+-----------+ | Command state | initiator | target | No | +-----------------+-----------+-----------+-----------+ | Response drop | cmd state | RD SNACK | No | +-----------------+-----------+-----------+-----------+ | Data reseg | Yes | new code | No | +-----------------+-----------+-----------+-----------+ | Integrity risks | 2 | 1 | 1 | +-----------------+-----------+-----------+-----------+ | Risk removal | target,1 | No | target,1 | +-----------------+-----------+-----------+-----------+ Attribute Explanation: SNACK codes: Number of Data SNACK codes. Fewer is better. Quiesce reads: Need to quiesce reads to which Data SNACK data recovery is applicable at in order to change initiator's receive Data PDU size limit. No is better Command state: Whether/where receive Data PDU size change requires state per Data-SNACK-recoverable command outstanding at the time of the change. No is better, other values indicate where the state is kept. This is referred to as "command state" for short below. Response drop: Whether and how initiator MUST drop and retry SCSI responses to deal with Data SNACK resegmentation. "cmd state" = based on command state (previous item), "RD SNACK" = based on whether a Resegmenting Data SNACK has been issued. No is better, as having to drop a SCSI response with good status is peculiar. Data reseg: Data can be resegmented in response to some form of Data SNACK. Not clear what's better here. "new code" = only in response to new Resegmenting Data SNACK code and is as good/bad as Yes. Integrity Risks: This is going to be controversial. It's is a count of risks to data integrity in error cases. The error cases are subtle as they're based on errors in error recovery. The risks are: - (A and B) Failure to drop a response and issue a status SNACK can lead to incomplete data in the face of Data PDU non-delivery (e.g., header corruption). Can be detected but not prevented by the target. - (A only) BegRun != 0 can cause the wrong data to be returned when resegmentation happens. Preventing this for A requires command state at target. Not applicable to B because BegRun = 0 is required for the new Resegmenting Data SNACK code and is easily checked by the target. - (C only) If the initiator issues a Data SNACK that causes the target to resegment, bad things happen, as the protocol doesn't support this. Can be prevented by command state at the target. - Risk removal: indicates that the latter two risks can be removed by adding command state to the target to catch the initiator misbehavior. For A, this would be "Targets MUST check that BegRun=0 when a Data SNACK would result in resegmentation". For C this would be "Targets MUST check that Data SNACKs do not cause resegmentation". If the BegRun = 0 requirement is removed, B goes to No command state, and A goes to 1 integrity risk and No risk removal - the net effect on the comparison of A and B is close to a wash, but C gets a serious plus for no "metadata explosion". Observations (1) The new factor in this message is the interaction of BegRun != 0 with Data resegmentation. Unless I've missed something major, it looks like BegRun MUST be zero when resegmentation happens in order to avoid the "metadata explosion". (2) I think the right versions of A and C to compare are the ones with extra state to catch the BegRun and "resegmenting attempted but is forbidden" cases. (3) With (2), A has to keep command state on both sides of the connection, B and C only need it at the target. B pays for less state with the additional Data SNACK type and code to support it. C has no integrity risks (never needs a status SNACK, hence can't screw it up), and is somewhat simpler (never has to drop a good response), but pays for it by not supporting resegmentation which causes a need to quiesce data-recoverable reads in order to change the PDU size. Analysis: - I prefer the extra Data SNACK type code to the state needed to enforce the BegRun=0 condition for resegmentation at the target. (A < B). I prefer C's never having to drop a SCSI response with good status to the additional complexity of resegmentation, even though C forces some commands to be quiesced in the rare case of a Data PDU size change (C > A, B). - I strongly object to the introduction of ULPDU containment into this discussion - that all but reopens the framing tarpit that I spent a great deal of time and effort getting to closure. My conclusion is that I prefer C, with B as a second choice, but this is no longer as clear-cut as I initially thought, as some of the distinctions above are fine. The fact that that resegmentation continues to be difficult to get right (e.g., Mallikarjun seems to have missed the "metadata explosion" required by his preferred option A), suggests to me that it ought to be left out (C) or isolated in a fashion that makes it easy not to use (B). Sorry about the length of this message - this is somewhat subtle stuff. Thanks, --David p.s. I'm in Yokohama typing this on the IETF wireless network - serious round of applause and thanks to the WIDE project folks (local hosts) for how easy and convenient this is to use. --------------------------------------------------- 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 --------------------------------------------------- From owner-ips@ece.cmu.edu Sun Jul 14 00:18:27 2002 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA14174 for ; Sun, 14 Jul 2002 00:18:27 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id g6E3c9A06670 for ips-outgoing; Sat, 13 Jul 2002 23:38:09 -0400 (EDT) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from d12lmsgate-2.de.ibm.com (d12lmsgate-2.de.ibm.com [195.212.91.200]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id g6E3c7X06663 for ; Sat, 13 Jul 2002 23:38:07 -0400 (EDT) Received: from d12relay01.de.ibm.com (d12relay01.de.ibm.com [9.165.215.22]) by d12lmsgate-2.de.ibm.com (8.12.3/8.12.3) with ESMTP id g6E3c0u1014470 for ; Sun, 14 Jul 2002 05:38:00 +0200 Received: from d10hubm1.telaviv.ibm.com (d10ml001.telaviv.ibm.com [9.148.216.55]) by d12relay01.de.ibm.com (8.11.1m3/NCO/VER6.2) with ESMTP id g6E3bxI73804 for ; Sun, 14 Jul 2002 05:38:00 +0200 Subject: RE: iSCSI: DLB's Comment on SCSI Port Names To: ips@ece.cmu.edu X-Mailer: Lotus Notes Release 5.0.9 November 16, 2001 Message-ID: From: "Julian Satran" Date: Sun, 14 Jul 2002 05:01:46 +0300 X-MIMETrack: Serialize by Router on D10ML001/10/M/IBM(Release 5.0.9a |January 7, 2002) at 14/07/2002 06:37:59 MIME-Version: 1.0 Content-type: text/plain; charset=us-ascii Sender: owner-ips@ece.cmu.edu Precedence: bulk Thanks again - I have restricted the encoding of ISID/TPGT to hex (they are not both numerical :-)) Wouldn't it be better to restrict the name length to something more "binary" like 223? Julo ----- Forwarded by Julian Satran/Haifa/IBM on 07/14/2002 04:54 AM ----- Julian Satran To: "KRUEGER,MARJORIE (HP-Roseville,ex1)" 07/12/2002 04:40 cc: ips , Julian Satran/Haifa/IBM@IBMIL AM From: Julian Satran/Haifa/IBM@Haifa/IBM@IBMIL Subject: RE: iSCSI: DLB's Comment on SCSI Port Names(Document link: Julian Satran - Mail) Marjorie, Thanks for your complete and timely answer. Regards, Julo "KRUEGER,MARJORIE (HP-Roseville,ex1 To: Julian Satran/Haifa/IBM@IBMIL )" cc: ips 07/11/2002 05:15 AM Please respond to "KRUEGER,MARJORIE (HP-Roseville,ex1 )" Julo, I'm a bit confused as the issues list on your website does not have this as issue 37, and all I see is issue 9 (where your comment appears to imply "no change"?) In any case, here's what I recommend: In sec 1.1 Definitions change the following definitions to: I_T Nexus: the last sentence should be The I_T nexus can be identified by the conjunction of the SCSI port names; that is, the I_T nexus identifier is the tuple (iSCSI Initiator Name + ',i,'+ ISID, iSCSI Target Name + ',t,'+ Portal Group Tag). SCSI Port Name: definition should be A name made up as UTF-8 characters and includes the iSCSI Name + ',i,' or ',t,' + ISID or Portal Group Tag In sec 2.2.7, 1st paragraph, delete the comment in parenthesis starting with "(for iSCSI,.." (or change it to point it to section 2.4.2, your choice). In sec 2.4.2, change the text to: When used in SCSI parameter data, the SCSI port name MUST be encoded as: - The iSCSI Name in UTF-8 format, followed by - a comma separator (1 byte), followed by - the ASCII character 'i' (for SCSI Initiator Port) or the ASCII character 't' (for SCSI Target Port), followed by - a comma separator (1 byte), followed by - A string representation (, see section 4.1 Text Format) of the ISID (for SCSI initiator port) or the portal group tag (for SCSI target port). SCSI port names have a maximum length of 255 bytes. The ASCII character 'i' or 't' is the label that identifies this port as either a SCSI Initiator Port or a SCSI Target Port. The 255 max port name makes for a 237 max iSCSI node name (check my math Jim :-) as the max character representation of an ISID is 15 characters for the largest decimal representation (14 char for the largest hex), + 3 char (",i,") + 237 = 255 The change in max node name causes changes to: sec 2.2.6.1, paragraph 2, sec 2.2.6.2, 2nd p, 3rd bullet I will see that a change is proposed to Annex A in whatever SAM doc is currently under revision. Thanks, Marjorie Krueger Networked Storage Architecture Networked Storage Solutions Org. Hewlett-Packard -----Original Message----- From: Julian Satran (Actcom) [mailto:Julian_Satran@actcom.net.il] Sent: Tuesday, July 09, 2002 6:44 AM To: KRUEGER,MARJORIE (HP-Roseville,ex1); 'Jim Hafner'; Black_David@emc.com Cc: ips Subject: Re: iSCSI: DLB's Comment on SCSI Port Names Marjorie, I'll list this as issue 37 and I think we can settle on 249 :-) I would appreciate if you let me know what constants change (in 2.4.2?) Julo ----- Original Message ----- From: KRUEGER,MARJORIE (HP-Roseville,ex1) To: 'Jim Hafner' ; Black_David@emc.com Cc: ips@ece.cmu.edu Sent: Tuesday, July 09, 2002 4:04 AM Subject: RE: iSCSI: DLB's Comment on SCSI Port Names I've just encountered this issue with regards to iSCSI port name encoding in the SCSI MIB, and the currently specified port name encoding causes inconvenience (at best). IMO, it makes sense to be able to treat an iSCSI name field, be it device name or port name, the same - as a string of display characters, portions of which may contain ASCII-encoded numeric values. I don't really see that it makes a difference whether one views ISID and TPGT as numeric strings or values, since as Jim says, there are no calculations performed using these things, and they are basicly just "tags". The issue for me is that the rest of the "SCSI port name" is a string and I see no value in "encoding" the ISID or TPGT as a value for SCSI purposes, as SCSI should have no need to use the ISID or TPGT values separately from the entire port name. And even if SCSI had such a need, it's a simple matter to convert a numeric string representation to a value. The downside of a string-encoding is the increased maximum size of the SCSI port name. If strings over 256 characters are a problem for some platforms, I'd be in favor of reducing the max iSCSI node name to 249 characters so the maximum SCSI port name would be 255 characters total (249 char name + ",i," + "0x0000") Marjorie Krueger Networked Storage Architecture Networked Storage Solutions Org. Hewlett-Packard -----Original Message----- From: Jim Hafner [mailto:hafner@almaden.ibm.com] Sent: Monday, July 08, 2002 9:08 AM To: Black_David@emc.com Cc: ips@ece.cmu.edu Subject: RE: iSCSI: DLB's Comment on SCSI Port Names David, I believe it will (may?) be used, so I agree we're in the second case. However, this format is the intended use in SCSI protocol stuff. Two places where SCSI ports names are used now is in ALIAS, Access Controls and in third party reservations -- see caveat below, however) I don't see a need in this context to define these as strings (that's not a SCSI way of thinking...). However, I think the issue comes down to a simple question: are the ISID and TPGT values or numerical strings (Julian is calling them numerical strings, but I've always thought of them as values, in spite of the fact that there is no arithmetic done on them - there is precedent in SCSI for such thinking, so I'm not completely out in the woods here). If they are values, then I'd like to see them formatted for SCSI in "value form"; if they are strings, then any representation should be OK. Does that at least get to the core of the issue? Jim Hafner CAVEAT: I don't think we'd use the iSCSI constructed port names in those contexts as device names are better suited for those purposes, but these are examples where specification of SCSI port name format is required. To: Jim Hafner/Almaden/IBM@IBMUS cc: ips@ece.cmu.edu Subject: RE: iSCSI: DLB's Comment on SCSI Port Names Jim, My view of this is that either: - The SCSI Port Name is never going to be used, in which case it shouldn't be designed to this level of detail. OR - It's going to be used, and hence is worth designing in a fashion that is reasonable to use. I think we're in the second category, and turning the ISID into hex ASCII (well, UTF-8) so the SCSI port name is a string is worth doing now to avoid problems when people actually try to use it. I would have no problems if someone wanted to pad the string, but I'd make specifying the padding the responsibility of the protocol/API/situation in which it was used rather than incorporating the padding into the name. Thanks, --David -----Original Message----- From: Jim Hafner [mailto:hafner@almaden.ibm.com] Sent: Monday, July 08, 2002 11:42 AM To: Black_David@emc.com Cc: ips@ece.cmu.edu Subject: Re: iSCSI: DLB's Comment on SCSI Port Names David, You wrote: >[T.9] 2.4.2 SCSI Architecture Model > > The SCSI Port Name is mandatory in iSCSI. When used in SCSI > parameter data, the SCSI port name MUST be encoded as: > - The iSCSI Name in UTF-8 format, followed by > - a comma separator (1 byte), followed by > - the ASCII character 'i' (for SCSI Initiator Port) or the > ASCII character 't' (for SCSI Target Port), followed by > - a comma separator (1 byte), followed by > - zero to 3 null pad bytes so that the complete format is a > multiple of four bytes long, followed by > - the 6byte value of the ISID (for SCSI initiator port) or the > 2byte value of the portal group tag (for SCSI target port) in > network byte order (BigEndian). > That's a peculiar format with padding nulls in the middle and > a number concatenated after the padding - for example, it can't > be passed in iSCSI login without format conversion. How about > converting the number to 4 or 12 bytes of hex (ASCII characters) > and moving the padding to the end so the result is actually a > string, and excluding the padding from the definition of the name? > This will increase the maximum length of port names, but produce > names that are easier to deal with. Admittedly that's an odd format, however here was the reason for this layout. 1) it's not used directly in iSCSI "Text" strings; it's intended to be a description of how this information is packed into a byte array for representation in "SCSI parameter data" (as it says!) -- that is, it's NEVER "passed in iSCSI login" (in this form). 2) the padding after the string was to force the binary values of the ISID or PGT to be better word aligned and can be more easily extracted as a value direct from the byte array without conversion. What do you think? Jim Hafner From owner-ips@ece.cmu.edu Sun Jul 14 00:20:21 2002 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA14207 for ; Sun, 14 Jul 2002 00:20:16 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id g6E3cKH06692 for ips-outgoing; Sat, 13 Jul 2002 23:38:20 -0400 (EDT) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from d12lmsgate-3.de.ibm.com (d12lmsgate-3.de.ibm.com [195.212.91.201]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id g6E3cCX06676; Sat, 13 Jul 2002 23:38:12 -0400 (EDT) Received: from d12relay01.de.ibm.com (d12relay01.de.ibm.com [9.165.215.22]) by d12lmsgate-3.de.ibm.com (8.12.3/8.12.3) with ESMTP id g6E3bwRa018610; Sun, 14 Jul 2002 05:37:59 +0200 Received: from d10hubm1.telaviv.ibm.com (d10ml001.telaviv.ibm.com [9.148.216.55]) by d12relay01.de.ibm.com (8.11.1m3/NCO/VER6.2) with ESMTP id g6E3bwI73802; Sun, 14 Jul 2002 05:37:58 +0200 Subject: RE: iSCSI: need for new data SNACK code? To: Black_David@emc.com Cc: cbm@rose.hp.com, ips@ece.cmu.edu, owner-ips@ece.cmu.edu X-Mailer: Lotus Notes Release 5.0.9 November 16, 2001 Message-ID: From: "Julian Satran" Date: Sun, 14 Jul 2002 02:26:47 +0300 X-MIMETrack: Serialize by Router on D10ML001/10/M/IBM(Release 5.0.9a |January 7, 2002) at 14/07/2002 06:37:58 MIME-Version: 1.0 Content-type: text/plain; charset=us-ascii Sender: owner-ips@ece.cmu.edu Precedence: bulk Well - I tend to agree with Mallikarjun that this new code was not strictly required. But I added it nevertheless for several reason: it does really no harm The "settling time" of a change in MaxRecvPDULength vs. data is not synchronized with command execution or even between connections so setting clear expectations is not bad. It also helps building sophisticated initiators that don't have to synchronize different threads. the burden of resending status went on the transmitter and that would have been confusing. Please pay attention to the fact that initiator has now to ask for the status if it wants it again. That is not really related but easier to do now and it was one technical issue that David raised that I would have also called technical and not syntactic sugar. All the plugfests have not shown yet a large number of within command recovery (I counted 2) although interest was expressed in private by many The new text takes also care about all the issues related to rejects (i.e. - it is tolerant). I suggest we close this thread and will fix the appendix soon. Julo Black_David@emc.c om To: cbm@rose.hp.com Sent by: cc: ips@ece.cmu.edu owner-ips@ece.cmu Subject: RE: iSCSI: need for new data SNACK code? .edu 07/12/2002 12:40 AM Please respond to Black_David Mallikarjun, > I am still unclear about the need to add the new data SNACK > code. IMHO, this can only be confusing to both initiator and target > implementers - to have two codes that have identical semantics > on the wire. > > The only remaining reason that I see from David (attached below) > is that the new code makes the initiator aware that it must request > status retransmission. IOW, you're expecting the initiator > to be careful > enough to use the new code, but somehow you don't expect it to be > attentive enough to discard the status PDU unless it had used > this new > code in an *outbound* SNACK. I completely miss this rationale. I disagree with the "careful enough" characterization. The new code provides the initiator with a more robust way to detect resegmentation by requiring the initiator to explicitly ask for it. The initiator can take a simple approach of always starting with the existing Data SNACK code that does not resegment and only using the new code when the non-resegmenting SNACK doesn't work. If the target makes its own choice to resegment, and the initiator doesn't think the target resegmented, there are error scenarios that combine this with corrupt Data PDU headers to cause the initiator to successfully complete a SCSI command that has not delivered all its data (the resegmented PDUs caused the Data PDU count to match the ExpDataSN value in the response that should have been discarded, but wasn't). While these should be rare, their consequences can be catastrophic. > I'd buy the new code if it's meant to convey something different to > *targets* because they need to process these SNACK PDUs. I see > nothing that the targets need to different in satisfying either SNACK. > Both parties are aware of the fact of PDU size change, it > had happened. It is conveying the Initiator's instructions that resegmentation is permitted. I am not comfortable with the last sentence above that assumes that the Initiator and Target will always have identical views of all of the effects of a full feature phase PDU size change - (which is a rare event to begin with, and hence likely to involve code that isn't well exercised/tested). > The only two changes from the rev14 text that I propose are that we add: > > a) The first status PDU must always be dropped after a > MaxRecvDataSegmentLength change, if ever a data SNACK is > employed for the task. When does this obligation to drop the first status PDU expire? I think the Initiator has to mark all commands that are outstanding or become outstanding between the time it starts the negotiation that changes MaxRecvDataSegmentLength and the time that it gets the final Text Response of that negotiation from the target. This requires additional Initiator state per command for something that almost never happens, and if it gets one of these markings wrong, it's vulnerable to failing to deliver all the data for a SCSI command in a compound error situation. An alternative with the new code could involve a single bit per connection that records whether the PDU size was ever changed (if so, retry any failed Data SNACK as a resegmenting Data SNACK). > Initiator MUST issue a status SNACK to recover the > status PDU (i.e. move the onus of retransmitting > status from the target to the initiator). > b) A SNACK requesting an R2T, Data or Status PDU for a task MUST be > issued before the status for the task is acknowledged. I have no problem with these two. > I'll be glad to see any technical reasons that I am > overlooking, that require two codes. See above. This is somewhat analogous to the "if in doubt, negotiate it" principle for login - telling the other side *exactly* what is wanted is more robust than assuming that it will do what is wanted, and in this resegmenting Data SNACK case, there are potentially nasty consequences to an incorrect assumption. Does this make any sense? > I'd assume Elizabeth would be the process co-chair, if need be. Yes. Thanks, --David > 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. From owner-ips@ece.cmu.edu Sun Jul 14 03:59:27 2002 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA28083 for ; Sun, 14 Jul 2002 03:59:27 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id g6E7IQ715852 for ips-outgoing; Sun, 14 Jul 2002 03:18:26 -0400 (EDT) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from d12lmsgate.de.ibm.com (d12lmsgate.de.ibm.com [195.212.91.199]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id g6E7INX15845; Sun, 14 Jul 2002 03:18:23 -0400 (EDT) Received: from d12relay01.de.ibm.com (d12relay01.de.ibm.com [9.165.215.22]) by d12lmsgate.de.ibm.com (8.12.3/8.12.3) with ESMTP id g6E7I9Kv019334; Sun, 14 Jul 2002 09:18:09 +0200 Received: from d10hubm1.telaviv.ibm.com (d10ml001.telaviv.ibm.com [9.148.216.55]) by d12relay01.de.ibm.com (8.11.1m3/NCO/VER6.2) with ESMTP id g6E7I8719426; Sun, 14 Jul 2002 09:18:08 +0200 To: "Dave Peterson" Cc: "Ips@Ece. Cmu. Edu" , owner-ips@ece.cmu.edu MIME-Version: 1.0 Subject: Re: iSCSI: DAP Last Call Comments X-Mailer: Lotus Notes Release 5.0.9 November 16, 2001 From: "Julian Satran" Message-ID: Date: Sun, 14 Jul 2002 10:18:06 +0300 X-MIMETrack: Serialize by Router on D10ML001/10/M/IBM(Release 5.0.9a |January 7, 2002) at 14/07/2002 10:18:08, Serialize complete at 14/07/2002 10:18:08 Content-Type: multipart/alternative; boundary="=_alternative 0027F027C2256BF6_=" Sender: owner-ips@ece.cmu.edu Precedence: bulk This is a multipart message in MIME format. --=_alternative 0027F027C2256BF6_= Content-Type: text/plain; charset="us-ascii" Dave - Comments in text - Thanks, Julo "Dave Peterson" Sent by: owner-ips@ece.cmu.edu 07/07/2002 11:19 PM Please respond to "Dave Peterson" To: "Ips@Ece. Cmu. Edu" cc: Subject: iSCSI: DAP Last Call Comments T p 36 2.2.2.1 Command Numbering and Acknowledging: 7th paragraph: if not in this document, where is the means to request immediate delivery for a command? +++ in some API document provided by your friendly implementer - there is no iSCSI CAM (no pun intended) +++ T p 38 2.2.2.2 Response/Status Numbering and Acknowledging: 4th paragraph: this paragraph is too vague which may result in different error recovery initiations being implemented. +++ the only bound required by protocol is stated here. The mechanisms described in 6 allow machines with different implementations to interoperate. The text is not vague. It just does say only what needs to be said. +++ T p 43 2.2.4 iSCSI Full Feature Phase: 16th paragraph: last sentence is not correct since out of order data delivery is allowed (if negotiated) +++ the statement refers to unsolicited data for different commands on a given connection and is correct+++ T p 73 4.2 Text Mode Negotiation: 6th paragraph: 3rd sentence: change the "should" to a "must" +++ so long as it is lower-case fine +++ T p 73 4.2 Text Mode Negotiation: 8th paragraph: the use of "Irrelevant" is a potential interoperability problem. Need to further specify the use of "Irrelevant". +++ Irrelevant is completely define and allows us to be build easier packages tolerant to different parameter combinations in a few exchanges. + We may do it implicitly but explicit is better++ T p 73 4.2 Text Mode Negotiation: 9th paragraph: specify that a "key=NotUnderstood" is applicable for "X-keys" only. +++ It practically says this for the current version. We do not want to forbid it for other keys in future versions +++ T p 103 6.1.1 Usage of Retry and 6.7 SCSI Timeouts: the semantics of Retry remain broken rendering it useless for tape operation. SCSI level error detection and recovery is the preferred mechanism. Refer to previous emails sent via the IPS reflector regarding this matter. +++ Dave. The retry scheme for connection recovery implies that the other two levels are there. So even if I would agree with your POW (which I am not) for practical reasons the mechanisms described will have to stay. +++ T p 128 8.6 Considerations for State-dependent devices: last paragraph: don't agree with the statement that error recovery at the iSCSI level (specifically Retry in its current state) is advisable. Retry at the SCSI level is feasible and is not difficult (i.e., READ POSITION and LOCATE commands). This paragraph should be removed. +++ that is not what we repeatedly hear. I will however make a "softer" statement. +++ T p 214 11.11 BidiInitialR2T: this text key provides no value and needs to be removed. InitialR2T should be used for both uni and bidirectional commands. In addition, if BidiInitialR2T were to be used, it will not function via an iSCSI-FCP gateway. +++ A gateway can easily map the keys. We don't know enough to decide off-hand to remove it. But I am still listening. +++ --=_alternative 0027F027C2256BF6_= Content-Type: text/html; charset="us-ascii"
Dave - Comments in text - Thanks, Julo


"Dave Peterson" <dap@cisco.com>
Sent by: owner-ips@ece.cmu.edu

07/07/2002 11:19 PM
Please respond to "Dave Peterson"

       
        To:        "Ips@Ece. Cmu. Edu" <ips@ece.cmu.edu>
        cc:        
        Subject:        iSCSI: DAP Last Call Comments

       


T                 p 36                 2.2.2.1 Command Numbering and Acknowledging: 7th paragraph: if not in
this document, where is the means to request immediate delivery for a
command?
+++ in some API document provided by your friendly implementer - there is no iSCSI CAM (no pun intended) +++

T                 p 38                 2.2.2.2 Response/Status Numbering and Acknowledging: 4th paragraph:
this paragraph is too vague which may result in different error recovery
initiations being implemented.

+++ the only bound required by protocol is stated here. The mechanisms described in 6 allow machines with different implementations to interoperate. The text is not vague. It just does say only what needs to be said. +++

T                 p 43                 2.2.4 iSCSI Full Feature Phase: 16th paragraph: last sentence is not
correct since out of order data delivery is allowed (if negotiated)
+++ the statement refers to unsolicited data for different commands on a given connection and is correct+++

T                 p 73                 4.2 Text Mode Negotiation: 6th paragraph: 3rd sentence: change the
"should" to a "must"

+++ so long as it is lower-case fine +++
T                 p 73                 4.2 Text Mode Negotiation: 8th paragraph: the use of "Irrelevant" is
a potential interoperability problem. Need to further specify the use of
"Irrelevant".

+++ Irrelevant is completely define and allows us to be build easier packages tolerant to different parameter combinations in a few exchanges. + We may do it implicitly but explicit is better++

T                 p 73                 4.2 Text Mode Negotiation: 9th paragraph: specify that a
"key=NotUnderstood" is applicable for "X-keys" only.

+++ It practically says this for the current version. We do not want to forbid it for other keys in future versions +++

T                 p 103                 6.1.1 Usage of Retry and 6.7 SCSI Timeouts: the semantics of Retry
remain broken rendering it useless for tape operation. SCSI level error
detection and recovery is the preferred mechanism. Refer to previous emails
sent via the IPS reflector regarding this matter.
+++ Dave. The retry scheme for connection recovery implies that the other two levels are there.
So even if I would agree with your POW (which I am not) for practical reasons the mechanisms described
will have to stay.
+++
T                 p 128                 8.6 Considerations for State-dependent devices: last paragraph:
don't agree with the statement that error recovery at the iSCSI level
(specifically Retry in its current state) is advisable. Retry at the SCSI
level is feasible and is not difficult (i.e., READ POSITION and LOCATE
commands). This paragraph should be removed.
+++ that is not what we repeatedly hear. I will however make a "softer" statement. +++

T                 p 214                 11.11 BidiInitialR2T: this text key provides no value and needs to
be removed. InitialR2T should be used for both uni and bidirectional
commands. In addition, if BidiInitialR2T were to be used, it will not
function via an iSCSI-FCP gateway.

+++ A gateway can easily map the keys. We don't know enough to decide off-hand to remove it.
But I am still listening.
+++

--=_alternative 0027F027C2256BF6_=-- From owner-ips@ece.cmu.edu Sun Jul 14 04:46:51 2002 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA29064 for ; Sun, 14 Jul 2002 04:46:47 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id g6E7xCh17174 for ips-outgoing; Sun, 14 Jul 2002 03:59:12 -0400 (EDT) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from d12lmsgate-2.de.ibm.com (d12lmsgate-2.de.ibm.com [195.212.91.200]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id g6E7xAX17169; Sun, 14 Jul 2002 03:59:10 -0400 (EDT) Received: from d12relay02.de.ibm.com (d12relay02.de.ibm.com [9.165.215.23]) by d12lmsgate-2.de.ibm.com (8.12.3/8.12.3) with ESMTP id g6E7x1u1025022; Sun, 14 Jul 2002 09:59:01 +0200 Received: from d10hubm1.telaviv.ibm.com (d10ml001.telaviv.ibm.com [9.148.216.55]) by d12relay02.de.ibm.com (8.11.1m3/NCO/VER6.2) with ESMTP id g6E7x0x65150; Sun, 14 Jul 2002 09:59:00 +0200 To: Brian Forbes Cc: ips@ece.cmu.edu, owner-ips@ece.cmu.edu, Robert Snively MIME-Version: 1.0 Subject: Re: BKF Comments on iSCSI version 14 X-Mailer: Lotus Notes Release 5.0.9 November 16, 2001 From: "Julian Satran" Message-ID: Date: Sun, 14 Jul 2002 10:58:54 +0300 X-MIMETrack: Serialize by Router on D10ML001/10/M/IBM(Release 5.0.9a |January 7, 2002) at 14/07/2002 10:59:00, Serialize complete at 14/07/2002 10:59:01, Serialize by Router on D10ML001/10/M/IBM(Release 5.0.9a |January 7, 2002) at 14/07/2002 10:59:01 Content-Type: multipart/alternative; boundary="=_alternative 002B1B66C2256BF6_=" Sender: owner-ips@ece.cmu.edu Precedence: bulk This is a multipart message in MIME format. --=_alternative 002B1B66C2256BF6_= Content-Type: text/plain; charset="us-ascii" Brian, Thanks - comments in text Julo Brian Forbes Sent by: owner-ips@ece.cmu.edu 07/07/2002 09:25 PM Please respond to Brian Forbes To: ips@ece.cmu.edu cc: Robert Snively Subject: BKF Comments on iSCSI version 14 I've sent a list of editorial comments directly to Julian. Technical comments: T1: Although it is alluded to in section 11.10, the document must explicitly define the effective value of Buffer Offset for immediate data. Possible sections for doing so include 2.2.4 and 9.3.6. +++ fixed in 2.2.4. This was requested also by Eddy +++ T2: I agree with the recent reflector discussion that decimal is only used for numbers, hex for numbers and binary, and base64 only for binary items. I believe the debate should focus on the utility of the existing iSCSI type definitions and avoid getting derailed by anecdotal references to data types in other RFCs. +++ One of the reasons people want SCSI on IP is to leverage all other IP infrastructure. Unfortunately the usage of decimal is beyond anectodal and we just can't ignore it. We have however - I think removed all the thorny related issues +++ T3: Section 4.3.1, page 80: "If the reconfiguration of iSCSI portal groups is a concern in a given environment, the iSCSI initiator MUST use this key to ascertain that it had indeed initiated the Login Phase with the intended target portal group." The use of MUST in the final sentence is untestable and should probably be lower-case "should". +++ we have several such instances. This usage can be certified in lab test - although I agree that it untestable at run-time (has no check condition). The same goes for many other MUST requirements +++ T4: Section 11.8, page 215: "If the TargetAddress is returned as the result of a redirect status in a login response, the comma and portal group tag are omitted." For interoperability reasons, I believe "are omitted" should be "MUST be omitted". +++ fixed +++ T5: Section 11.8, page 215: "If the TargetAddress is returned within a SendTargets response, the portal group tag is required." For interoperability reasons, I believe "is required" should be "MUST be included". +++ fixed +++ Brian Forbes Technology Brocade Communications --=_alternative 002B1B66C2256BF6_= Content-Type: text/html; charset="us-ascii"
Brian,

Thanks - comments in text Julo


Brian Forbes <bforbes@Brocade.COM>
Sent by: owner-ips@ece.cmu.edu

07/07/2002 09:25 PM
Please respond to Brian Forbes

       
        To:        ips@ece.cmu.edu
        cc:        Robert Snively <rsnively@Brocade.COM>
        Subject:        BKF Comments on iSCSI version 14

       


I've sent a list of editorial comments directly to Julian.

Technical comments:

T1:  

Although it is alluded to in section 11.10, the document must explicitly
define the effective value of Buffer Offset for immediate data.  Possible
sections for doing so include 2.2.4 and 9.3.6.
+++ fixed in 2.2.4. This was requested also by Eddy +++
T2:  

I agree with the recent reflector discussion that decimal is only used for
numbers, hex for numbers and binary, and base64 only for binary items.  I
believe the debate should focus on the utility of the existing iSCSI type
definitions and avoid getting derailed by anecdotal references to data types
in other RFCs.
+++ One of the reasons people want SCSI on IP is to leverage all other IP infrastructure.
Unfortunately the usage of decimal is beyond anectodal and we just can't ignore it.
We have however - I think removed all the thorny related issues +++

T3:  

Section 4.3.1, page 80:  "If the reconfiguration of iSCSI portal groups is a
concern in a given environment, the iSCSI initiator MUST use this key to
ascertain that it had indeed initiated the Login Phase with the intended
target portal group."

The use of MUST in the final sentence is untestable and should probably be
lower-case "should".
+++ we have several such instances. This usage can be certified in lab test - although I agree that it untestable at run-time (has no check condition). The same goes for many other MUST requirements +++

T4:  

Section 11.8, page 215:  "If the TargetAddress is returned as the result of
a redirect status in a login response, the comma and portal group tag are
omitted."

For interoperability reasons, I believe "are omitted" should be "MUST be
omitted".
+++ fixed +++

T5:  

Section 11.8, page 215:  "If the TargetAddress is returned within a
SendTargets response, the portal group tag is required."

For interoperability reasons, I believe "is required" should be "MUST be
included".

+++ fixed +++
Brian Forbes
Technology
Brocade Communications

--=_alternative 002B1B66C2256BF6_=-- From owner-ips@ece.cmu.edu Sun Jul 14 04:48:39 2002 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA29092 for ; Sun, 14 Jul 2002 04:48:39 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id g6E89m317568 for ips-outgoing; Sun, 14 Jul 2002 04:09:48 -0400 (EDT) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from d12lmsgate.de.ibm.com (d12lmsgate.de.ibm.com [195.212.91.199]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id g6E89jX17563; Sun, 14 Jul 2002 04:09:45 -0400 (EDT) Received: from d12relay01.de.ibm.com (d12relay01.de.ibm.com [9.165.215.22]) by d12lmsgate.de.ibm.com (8.12.3/8.12.3) with ESMTP id g6E89UKv023622; Sun, 14 Jul 2002 10:09:30 +0200 Received: from d10hubm1.telaviv.ibm.com (d10ml001.telaviv.ibm.com [9.148.216.55]) by d12relay01.de.ibm.com (8.11.1m3/NCO/VER6.2) with ESMTP id g6E89S7103548; Sun, 14 Jul 2002 10:09:29 +0200 To: Steve Reames Cc: ips@ece.cmu.edu, owner-ips@ece.cmu.edu MIME-Version: 1.0 Subject: Re: iSCSI: DLB [T.31] X-Mailer: Lotus Notes Release 5.0.9 November 16, 2001 From: "Julian Satran" Message-ID: Date: Sun, 14 Jul 2002 11:09:25 +0300 X-MIMETrack: Serialize by Router on D10ML001/10/M/IBM(Release 5.0.9a |January 7, 2002) at 14/07/2002 11:09:29, Serialize complete at 14/07/2002 11:09:29 Content-Type: multipart/alternative; boundary="=_alternative 002C33D3C2256BF6_=" Sender: owner-ips@ece.cmu.edu Precedence: bulk This is a multipart message in MIME format. --=_alternative 002C33D3C2256BF6_= Content-Type: text/plain; charset="us-ascii" The whole text is meant only to show what the normative behavior will be at ErrorRecoveryLevel=1 It does not preclude you doing partial recovery and not raising at level 1 although most of your partners are bound to assume the worst and ignore your efforts. Julo Steve Reames Sent by: owner-ips@ece.cmu.edu 07/09/2002 11:33 PM Please respond to Steve Reames To: ips@ece.cmu.edu cc: Subject: iSCSI: DLB [T.31] From DLB's comments: >[T.31] 9.16.1 Type > > An iSCSI target that does not support recovery within connection MAY > reject the status SNACK with a Reject PDU. If the target supports > recovery within connection, it MAY reject the SNACK after which it > MUST issue an Asynchronous Message PDU with an iSCSI event that indi- > cates "Request Logout". > > This should be conditioned on the operational ErrorRecoveryLevel of the > session, not whether the target supports recovery within connection. I would prefer that this not be conditioned on the ErrorRecoveryLevel. If I am writing code, I may choose to support recovery-within-connection, but not all the features that would be required to move me up to ErrorRecoveryLevel 1. I would like SNACK and Reject PDUs to work properly for my code, even though it is technically only "ErrorRecoveryLevel 0.5". As I read it, changing the wording would allow the target to ignore my improved error recovery efforts unless I have a full ErrorRecoveryLevel 1 implementation. David, I doubt that is what you intended, so maybe you want to word it a little differently. --=_alternative 002C33D3C2256BF6_= Content-Type: text/html; charset="us-ascii"
The whole text is meant only to show what the normative behavior will be at ErrorRecoveryLevel=1 It does not preclude you doing partial recovery
and not raising at level 1 although most of your partners are bound to assume the worst and ignore your efforts.

Julo


Steve Reames <reames@diskdrive.com>
Sent by: owner-ips@ece.cmu.edu

07/09/2002 11:33 PM
Please respond to Steve Reames

       
        To:        ips@ece.cmu.edu
        cc:        
        Subject:        iSCSI: DLB [T.31]

       


 From DLB's comments:

>[T.31] 9.16.1  Type
>
>   An iSCSI target that does not support recovery within connection MAY
>   reject the status SNACK with a Reject PDU. If the target supports
>   recovery within connection, it MAY reject the SNACK after which it
>   MUST issue an Asynchronous Message PDU with an iSCSI event that indi-
>   cates "Request Logout".
>
> This should be conditioned on the operational ErrorRecoveryLevel of the
> session, not whether the target supports recovery within connection.

I would prefer that this not be conditioned on the ErrorRecoveryLevel. If I
am writing code, I may choose to support recovery-within-connection, but
not all the features that would be required to move me up to
ErrorRecoveryLevel 1. I would like SNACK and Reject PDUs to work properly
for my code, even though it is technically only "ErrorRecoveryLevel 0.5".
                As I read it, changing the wording would allow the target to ignore my
improved error recovery efforts unless I have a full ErrorRecoveryLevel 1
implementation. David, I doubt that is what you intended, so maybe you want
to word it a little differently.

--=_alternative 002C33D3C2256BF6_=-- From owner-ips@ece.cmu.edu Sun Jul 14 10:16:14 2002 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA06928 for ; Sun, 14 Jul 2002 10:16:13 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id g6EDYnv09640 for ips-outgoing; Sun, 14 Jul 2002 09:34:49 -0400 (EDT) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from d12lmsgate-2.de.ibm.com (d12lmsgate-2.de.ibm.com [195.212.91.200]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id g6EDYmX09636 for ; Sun, 14 Jul 2002 09:34:48 -0400 (EDT) Received: from d12relay02.de.ibm.com (d12relay02.de.ibm.com [9.165.215.23]) by d12lmsgate-2.de.ibm.com (8.12.3/8.12.3) with ESMTP id g6EDYfu1020556 for ; Sun, 14 Jul 2002 15:34:41 +0200 Received: from d10hubm1.telaviv.ibm.com (d10ml001.telaviv.ibm.com [9.148.216.55]) by d12relay02.de.ibm.com (8.11.1m3/NCO/VER6.2) with ESMTP id g6EDYfx49732 for ; Sun, 14 Jul 2002 15:34:41 +0200 To: ips@ece.cmu.edu Importance: High MIME-Version: 1.0 Subject: iSCSI working draft 15 X-Mailer: Lotus Notes Release 5.0.9 November 16, 2001 From: "Julian Satran" Message-ID: Date: Sun, 14 Jul 2002 16:34:39 +0300 X-MIMETrack: Serialize by Router on D10ML001/10/M/IBM(Release 5.0.9a |January 7, 2002) at 14/07/2002 16:34:40, Serialize complete at 14/07/2002 16:34:40 Content-Type: multipart/alternative; boundary="=_alternative 0049F6FFC2256BF6_=" Sender: owner-ips@ece.cmu.edu Precedence: bulk This is a multipart message in MIME format. --=_alternative 0049F6FFC2256BF6_= Content-Type: text/plain; charset="us-ascii" Dear colleagues, The list on my site has now all the issues I was aware 2 days ago. It list also their proposed resolution - and there is one for almost all of them. The draft is also updated (an hour ago). I am going now through the rest of the editorials - and hope to have them done in a day or two. Julo --=_alternative 0049F6FFC2256BF6_= Content-Type: text/html; charset="us-ascii"
Dear colleagues,

The list on my site has now all the issues I was aware 2 days ago.
It list also their proposed resolution - and there is one for almost all
of them.

The draft is also updated (an hour ago).

I am going now through the rest of the editorials - and hope to have them done in a day or two.

Julo --=_alternative 0049F6FFC2256BF6_=-- From owner-ips@ece.cmu.edu Sun Jul 14 10:18:44 2002 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA07132 for ; Sun, 14 Jul 2002 10:18:44 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id g6EDtxa10351 for ips-outgoing; Sun, 14 Jul 2002 09:55:59 -0400 (EDT) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from d12lmsgate.de.ibm.com (d12lmsgate.de.ibm.com [195.212.91.199]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id g6EDtvX10346 for ; Sun, 14 Jul 2002 09:55:57 -0400 (EDT) Received: from d12relay02.de.ibm.com (d12relay02.de.ibm.com [9.165.215.23]) by d12lmsgate.de.ibm.com (8.12.3/8.12.3) with ESMTP id g6EDtoKv005130; Sun, 14 Jul 2002 15:55:50 +0200 Received: from d10hubm1.telaviv.ibm.com (d10ml001.telaviv.ibm.com [9.148.216.55]) by d12relay02.de.ibm.com (8.11.1m3/NCO/VER6.2) with ESMTP id g6EDtox24478; Sun, 14 Jul 2002 15:55:50 +0200 To: Black_David@emc.com Cc: ips@ece.cmu.edu MIME-Version: 1.0 Subject: RE: iSCSI: DLB-T.16 (resource requirement for connection reinsta tement) X-Mailer: Lotus Notes Release 5.0.9 November 16, 2001 From: "Julian Satran" Message-ID: Date: Sun, 14 Jul 2002 16:55:47 +0300 X-MIMETrack: Serialize by Router on D10ML001/10/M/IBM(Release 5.0.9a |January 7, 2002) at 14/07/2002 16:55:50, Serialize complete at 14/07/2002 16:55:50 Content-Type: multipart/alternative; boundary="=_alternative 004C5ABCC2256BF6_=" Sender: owner-ips@ece.cmu.edu Precedence: bulk This is a multipart message in MIME format. --=_alternative 004C5ABCC2256BF6_= Content-Type: text/plain; charset="us-ascii" OOps - meant to say SHOULD for 1 or 0 - I will fix it. Julo Black_David@emc.com 07/14/2002 10:08 AM Please respond to Black_David To: Julian Satran/Haifa/IBM@IBMIL cc: Subject: RE: iSCSI: DLB-T.16 (resource requirement for connection reinsta tement) Ok with me. --David -----Original Message----- From: Julian Satran [mailto:Julian_Satran@il.ibm.com] Sent: Sunday, July 14, 2002 2:27 AM To: Black_David@emc.com Subject: RE: iSCSI: DLB-T.16 (resource requirement for connection reinsta tement) David, Mallikarjun was only saying that 4.3.4 is the RIGHT PLACE to say that a second connection MUST be supported IF ErrorRecoveryLevel is higher than 0. I would suggest: Targets MUST support opening a second connection even when they do not support multiple connections in Full Feature Phase if ErrorRecoveryLevel is 2 and SHOULD support opening a second con-nection if ErrorRecoveryLevel is 1. Julo Black_David@emc.com Sent by: owner-ips@ece.cmu.edu 07/10/2002 10:56 AM Please respond to Black_David To: cbm@rose.hp.com, ips@ece.cmu.edu cc: Subject: RE: iSCSI: DLB-T.16 (resource requirement for connection reinsta tement) Mallikarjun, I think this ought to be related to ErrorRecoveryLevel - it looks like you're suggesting that connection reinstatement SHOULD be supported at ErrorRecoveryLevel 0 - at 1 and above, I believe it's already a MUST. I don't have a problem with that, does anyone else? Thanks, --David > -----Original Message----- > From: Mallikarjun C. [mailto:cbm@rose.hp.com] > Sent: Tuesday, July 09, 2002 2:52 PM > To: ips@ece.cmu.edu > Subject: iSCSI: DLB-T.16 (resource requirement for connection > reinstatement) > > > > [T.16] 4.3.4 Connection reinstatement > > > > Targets should support opening a second connection even > > when they do not support multiple connections in Full Feature Phase. > > > > Looks like that ought to be an upper case "SHOULD". I think this needs > > further discussion. Section 5.2 appears to use a lower case "must" > > for this: > > Let's be careful here - section 5.2 discusses the generic case of "connection > cleanup" - that includes both implicit and explicit logouts - whereas "connection > reinstatement" is just implicit logout. > > While "connection cleanup" does not require additional connection resources > in the general case, a target wanting to support connection reinstatement SHOULD > support *opening* a second connection (though it may reject the Login if it's > for a different CID). > > I believe that connection reinstatement is a useful functionality that the targets > SHOULD support, so I agree that the change suggested by David is a reasonable > one to make in 4.3.4 which only discusses connection reinstatement. > > Mallikarjun > --=_alternative 004C5ABCC2256BF6_= Content-Type: text/html; charset="us-ascii"
OOps - meant to say SHOULD for 1 or 0 - I will fix it. Julo


Black_David@emc.com

07/14/2002 10:08 AM
Please respond to Black_David

       
        To:        Julian Satran/Haifa/IBM@IBMIL
        cc:        
        Subject:        RE: iSCSI: DLB-T.16  (resource requirement for connection reinsta                tement)

       


Ok with me.  --David
 
-----Original Message-----
From: Julian Satran [mailto:Julian_Satran@il.ibm.com]
Sent: Sunday, July 14, 2002 2:27 AM
To: Black_David@emc.com
Subject: RE: iSCSI: DLB-T.16 (resource requirement for connection reinsta tement)

David,

Mallikarjun was only saying that 4.3.4 is the RIGHT PLACE to say that a second connection MUST be supported
IF ErrorRecoveryLevel is higher than 0.

I would suggest:

Targets MUST support opening a second connection even when they do not support multiple connections in Full Feature Phase if ErrorRecoveryLevel is 2 and SHOULD support opening a second con-nection if ErrorRecoveryLevel is 1.

Julo

Black_David@emc.com
Sent by: owner-ips@ece.cmu.edu

07/10/2002 10:56 AM
Please respond to Black_David

       
       To:        cbm@rose.hp.com, ips@ece.cmu.edu
       cc:        
       Subject:        RE: iSCSI: DLB-T.16  (resource requirement for connection reinsta        tement)

     



Mallikarjun,

I think this ought to be related to ErrorRecoveryLevel - it looks like
you're suggesting that connection reinstatement SHOULD be supported
at ErrorRecoveryLevel 0 - at 1 and above, I believe it's already a
MUST.  I don't have a problem with that, does anyone else?

Thanks,
--David

> -----Original Message-----
> From: Mallikarjun C. [mailto:cbm@rose.hp.com]
> Sent: Tuesday, July 09, 2002 2:52 PM
> To: ips@ece.cmu.edu
> Subject: iSCSI: DLB-T.16 (resource requirement for connection
> reinstatement)
>
>
> > [T.16] 4.3.4  Connection reinstatement
> >
> >    Targets should support opening a second connection even
> >    when they do not support multiple connections in Full Feature Phase.
> >
> > Looks like that ought to be an upper case "SHOULD".  I think this needs
> > further discussion.  Section 5.2 appears to use a lower case "must"
> > for this:
>
> Let's be careful here - section 5.2 discusses the generic case of
"connection
> cleanup" - that includes both implicit and explicit logouts - whereas
"connection
> reinstatement" is just implicit logout.
>
> While "connection cleanup" does not require additional connection
resources
> in the general case, a target wanting to support connection reinstatement
SHOULD
> support *opening* a second connection (though it may reject the Login if
it's
> for a different CID).
>
> I believe that connection reinstatement is a useful functionality that the
targets
> SHOULD support, so I agree that the change suggested by David is a
reasonable
> one to make in 4.3.4 which only discusses connection reinstatement.
>
> Mallikarjun
>



--=_alternative 004C5ABCC2256BF6_=-- From owner-ips@ece.cmu.edu Sun Jul 14 10:20:02 2002 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA07179 for ; Sun, 14 Jul 2002 10:20:01 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id g6EE6LM10753 for ips-outgoing; Sun, 14 Jul 2002 10:06:21 -0400 (EDT) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from d12lmsgate.de.ibm.com (d12lmsgate.de.ibm.com [195.212.91.199]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id g6EE6JX10749 for ; Sun, 14 Jul 2002 10:06:19 -0400 (EDT) Received: from d12relay01.de.ibm.com (d12relay01.de.ibm.com [9.165.215.22]) by d12lmsgate.de.ibm.com (8.12.3/8.12.3) with ESMTP id g6EE6CKv016896; Sun, 14 Jul 2002 16:06:12 +0200 Received: from d10hubm1.telaviv.ibm.com (d10ml001.telaviv.ibm.com [9.148.216.55]) by d12relay01.de.ibm.com (8.11.1m3/NCO/VER6.2) with ESMTP id g6EE6C796080; Sun, 14 Jul 2002 16:06:12 +0200 To: Ken Sandars Cc: Black_David@emc.com, ips@ece.cmu.edu MIME-Version: 1.0 Subject: Re: iSCSI: DLB's [T.6] 2.3 iSCSI Session Types X-Mailer: Lotus Notes Release 5.0.9 November 16, 2001 From: "Julian Satran" Message-ID: Date: Sun, 14 Jul 2002 17:06:09 +0300 X-MIMETrack: Serialize by Router on D10ML001/10/M/IBM(Release 5.0.9a |January 7, 2002) at 14/07/2002 17:06:12, Serialize complete at 14/07/2002 17:06:12 Content-Type: multipart/alternative; boundary="=_alternative 004C867EC2256BF6_=" Sender: owner-ips@ece.cmu.edu Precedence: bulk This is a multipart message in MIME format. --=_alternative 004C867EC2256BF6_= Content-Type: text/plain; charset="us-ascii" My preference would be to stay with what is currently available - hit the initiator with a FIN. There is nothing to recover anyhow. Julo Ken Sandars 07/12/2002 10:39 PM Please respond to Ken Sandars To: Black_David@emc.com, Julian Satran/Haifa/IBM@IBMIL cc: ips@ece.cmu.edu Subject: Re: iSCSI: DLB's [T.6] 2.3 iSCSI Session Types Hi all, I'm wondering what the preferred mechanism is for a target to force an initiator to close a discovery session. In the case ot a normal session, the AM-"target requests logout" pdu is allowed (I guess AM types 1-3 apply). So should we follow this model for discovery sessions, or just hit 'em with a FIN? Thanks, Ken -- Ken Sandars Eurologic Systems Ltd ksandars@eurologic.com On Thursday 11 July 2002 5:01 am, Black_David@emc.com wrote: > Julian > > > I can agree with MUST but I will resist adding any notification. > > > > It is just the wrong thing to do. > > I don't care - getting to a MUST with a list of allowed PDUs that > forbids all others from the current MAY that allows everything is > what matters to me. > > At the moment, I've only seen Ayman ask for Async Message to be > allowed on discovery sessions - does anyone else want to see that > PDU allowed on discovery sessions? > > 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 > --------------------------------------------------- --=_alternative 004C867EC2256BF6_= Content-Type: text/html; charset="us-ascii"
My preference would be to stay with what is currently available - hit the initiator with a FIN. There is nothing to recover anyhow.

Julo


Ken Sandars <ksandars@eurologic.com>

07/12/2002 10:39 PM
Please respond to Ken Sandars

       
        To:        Black_David@emc.com, Julian Satran/Haifa/IBM@IBMIL
        cc:        ips@ece.cmu.edu
        Subject:        Re: iSCSI: DLB's [T.6] 2.3  iSCSI Session Types

       


Hi all,

I'm wondering what the preferred mechanism is for a target to force an
initiator to close a discovery session.

In the case ot a normal session, the AM-"target requests logout" pdu is
allowed (I guess AM types 1-3 apply). So should we follow this model for
discovery sessions, or just hit 'em with a FIN?


Thanks,
Ken
--
Ken Sandars
Eurologic Systems Ltd
ksandars@eurologic.com



On Thursday 11 July 2002 5:01 am, Black_David@emc.com wrote:
> Julian
>
> > I can agree with MUST but I will resist adding any notification.
> >
> > It is just the wrong thing to do.
>
> I don't care - getting to a MUST with a list of allowed PDUs that
> forbids all others from the current MAY that allows everything is
> what matters to me.
>
> At the moment, I've only seen Ayman ask for Async Message to be
> allowed on discovery sessions - does anyone else want to see that
> PDU allowed on discovery sessions?
>
> 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
> ---------------------------------------------------

--=_alternative 004C867EC2256BF6_=-- From owner-ips@ece.cmu.edu Sun Jul 14 19:18:34 2002 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA20535 for ; Sun, 14 Jul 2002 19:18:34 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id g6EMcLD04297 for ips-outgoing; Sun, 14 Jul 2002 18:38:21 -0400 (EDT) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from d12lmsgate-2.de.ibm.com (d12lmsgate-2.de.ibm.com [195.212.91.200]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id g6EMcIX04288 for ; Sun, 14 Jul 2002 18:38:18 -0400 (EDT) Received: from d12relay01.de.ibm.com (d12relay01.de.ibm.com [9.165.215.22]) by d12lmsgate-2.de.ibm.com (8.12.3/8.12.3) with ESMTP id g6EMc5rQ024138; Mon, 15 Jul 2002 00:38:05 +0200 Received: from d10hubm1.telaviv.ibm.com (d10ml001.telaviv.ibm.com [9.148.216.55]) by d12relay01.de.ibm.com (8.11.1m3/NCO/VER6.2) with ESMTP id g6EMbw782360; Mon, 15 Jul 2002 00:38:03 +0200 To: "Randy Jennings" Cc: "ips" , "Paul Koning" MIME-Version: 1.0 Subject: RE: iSCSI - decimal coded binary strings - a proposed resolution X-Mailer: Lotus Notes Release 5.0.9 November 16, 2001 From: "Julian Satran" Message-ID: Date: Mon, 15 Jul 2002 01:37:55 +0300 X-MIMETrack: Serialize by Router on D10ML001/10/M/IBM(Release 5.0.9a |January 7, 2002) at 15/07/2002 01:38:04, Serialize complete at 15/07/2002 01:38:04 Content-Type: multipart/alternative; boundary="=_alternative 007B990BC2256BF6_=" Sender: owner-ips@ece.cmu.edu Precedence: bulk This is a multipart message in MIME format. --=_alternative 007B990BC2256BF6_= Content-Type: text/plain; charset="us-ascii" thanks - julo "Randy Jennings" 07/10/2002 08:02 PM Please respond to "Randy Jennings" To: Julian Satran/Haifa/IBM@IBMIL, "Paul Koning" cc: "ips" Subject: RE: iSCSI - decimal coded binary strings - a proposed resolution > > Julian> decimal-constant: an unsigned decimal number - the digit 0 or > > Julian> a string of 1 or more digits starting with a non-zero digit. > > Julian> Decimal-constants are used to encode numerical values or > > Julian> binary strings. Decimal constants can be used to encode > > Julian> binary strings only if the stringlength is explicitly > > Julian> speci-fied. There is no implicit length for decimal > > Julian> strings. This encoding MUST NOT used for numerical values > > Julian> equal or greater than 2**64 or binary strings that could be > > Julian> longer than 64 bits. Here is the problem: Do you mean (parentheses added): This encoding MUST NOT used for (numerical values equal or greater than 2**64) or (binary strings that could be longer than 64 bits). or: This encoding MUST NOT used for (numerical values equal or greater than 2**64 or binary strings) that could be longer than 64 bits. The first is admittedly the more logical choice, but it is not the only choice. I originally read it as the second and wondered what Paul's issue was. This is the editorial clarity issue that David Black is talking about. I remember having this issue with spec 11 when I was primarily learning the spec. However, as I care more about decoding the info instead of writing a protocol state machine, I did not make note of these problems. I apologize for not going over spec 12-(15?) closely. These issues may have been addressed by other editorial comments, but when adding text, it should be carefully scrutinized as well. With a 'for' in front of binary strings, the sentence can only be interpreted one way. From your following email is the wording intended. Sincerely, Randy Data Transit --=_alternative 007B990BC2256BF6_= Content-Type: text/html; charset="us-ascii"
thanks - julo


"Randy Jennings" <randyj@data-transit.com>

07/10/2002 08:02 PM
Please respond to "Randy Jennings"

       
        To:        Julian Satran/Haifa/IBM@IBMIL, "Paul Koning" <ni1d@arrl.net>
        cc:        "ips" <ips@ece.cmu.edu>
        Subject:        RE: iSCSI - decimal coded binary strings - a proposed resolution

       


> >  Julian> decimal-constant: an unsigned decimal number - the digit 0 or
> >  Julian> a string of 1 or more digits starting with a non-zero digit.
> >  Julian> Decimal-constants are used to encode numerical values or
> >  Julian> binary strings. Decimal constants can be used to encode
> >  Julian> binary strings only if the stringlength is explicitly
> >  Julian> speci-fied. There is no implicit length for decimal
> >  Julian> strings. This encoding MUST NOT used for numerical values
> >  Julian> equal or greater than 2**64 or binary strings that could be
> >  Julian> longer than 64 bits.

Here is the problem:
Do you mean (parentheses added):

This encoding MUST NOT used for (numerical values equal or greater than
2**64) or (binary strings that could be longer than 64 bits).

or:

This encoding MUST NOT used for (numerical values equal or greater than
2**64 or binary strings) that could be longer than 64 bits.

The first is admittedly the more logical choice, but it is not the only
choice.  I originally read it as the second and wondered what Paul's issue
was.

This is the editorial clarity issue that David Black is talking about.  I
remember having this issue with spec 11 when I was primarily learning the
spec. However, as I care more about decoding the info instead of writing a
protocol state machine, I did not make note of these problems.  I apologize
for not going over spec 12-(15?) closely.  These issues may have been
addressed by other editorial comments, but when adding text, it should be
carefully scrutinized as well.

With a 'for' in front of binary strings, the sentence can only be
interpreted one way.  From your following email is the wording intended.

Sincerely,
Randy
Data Transit

--=_alternative 007B990BC2256BF6_=-- From owner-ips@ece.cmu.edu Sun Jul 14 23:25:46 2002 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA28106 for ; Sun, 14 Jul 2002 23:25:46 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id g6F2hKq15811 for ips-outgoing; Sun, 14 Jul 2002 22:43:20 -0400 (EDT) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from mxic2.corp.emc.com (mxic2.isus.emc.com [128.221.31.40]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id g6F2hJX15806 for ; Sun, 14 Jul 2002 22:43:19 -0400 (EDT) Received: by mxic2.corp.emc.com with Internet Mail Service (5.5.2653.19) id <3XHVM87G>; Sun, 14 Jul 2002 22:43:16 -0400 Message-ID: <277DD60FB639D511AC0400B0D068B71E0564C081@CORPMX14> From: Black_David@emc.com To: Julian_Satran@il.ibm.com Cc: ips@ece.cmu.edu Subject: RE: iSCSI: DLB [T.31] Date: Sun, 14 Jul 2002 22:41:08 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C22BA9.12F46870" Sender: owner-ips@ece.cmu.edu Precedence: bulk This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_001_01C22BA9.12F46870 Content-Type: text/plain; charset="iso-8859-1" We'll need to discuss this in Yokohama, as there seems to be a difference of opinion about whether this sort of "ErrorRecoveryLevel 0.5" is allowed. --David -----Original Message----- From: Julian Satran [mailto:Julian_Satran@il.ibm.com] Sent: Sunday, July 14, 2002 4:09 AM To: Steve Reames Cc: ips@ece.cmu.edu; owner-ips@ece.cmu.edu Subject: Re: iSCSI: DLB [T.31] The whole text is meant only to show what the normative behavior will be at ErrorRecoveryLevel=1 It does not preclude you doing partial recovery and not raising at level 1 although most of your partners are bound to assume the worst and ignore your efforts. Julo Steve Reames Sent by: owner-ips@ece.cmu.edu 07/09/2002 11:33 PM Please respond to Steve Reames To: ips@ece.cmu.edu cc: Subject: iSCSI: DLB [T.31] From DLB's comments: >[T.31] 9.16.1 Type > > An iSCSI target that does not support recovery within connection MAY > reject the status SNACK with a Reject PDU. If the target supports > recovery within connection, it MAY reject the SNACK after which it > MUST issue an Asynchronous Message PDU with an iSCSI event that indi- > cates "Request Logout". > > This should be conditioned on the operational ErrorRecoveryLevel of the > session, not whether the target supports recovery within connection. I would prefer that this not be conditioned on the ErrorRecoveryLevel. If I am writing code, I may choose to support recovery-within-connection, but not all the features that would be required to move me up to ErrorRecoveryLevel 1. I would like SNACK and Reject PDUs to work properly for my code, even though it is technically only "ErrorRecoveryLevel 0.5". As I read it, changing the wording would allow the target to ignore my improved error recovery efforts unless I have a full ErrorRecoveryLevel 1 implementation. David, I doubt that is what you intended, so maybe you want to word it a little differently. ------_=_NextPart_001_01C22BA9.12F46870 Content-Type: text/html; charset="iso-8859-1"
We'll need to discuss this in Yokohama, as there seems to be
a difference of opinion about whether this sort of
"ErrorRecoveryLevel 0.5" is allowed.  --David
-----Original Message-----
From: Julian Satran [mailto:Julian_Satran@il.ibm.com]
Sent: Sunday, July 14, 2002 4:09 AM
To: Steve Reames
Cc: ips@ece.cmu.edu; owner-ips@ece.cmu.edu
Subject: Re: iSCSI: DLB [T.31]


The whole text is meant only to show what the normative behavior will be at ErrorRecoveryLevel=1 It does not preclude you doing partial recovery
and not raising at level 1 although most of your partners are bound to assume the worst and ignore your efforts.

Julo


Steve Reames <reames@diskdrive.com>
Sent by: owner-ips@ece.cmu.edu

07/09/2002 11:33 PM
Please respond to Steve Reames

       
        To:        ips@ece.cmu.edu
        cc:        
        Subject:        iSCSI: DLB [T.31]

       


 From DLB's comments:

>[T.31] 9.16.1  Type
>
>   An iSCSI target that does not support recovery within connection MAY
>   reject the status SNACK with a Reject PDU. If the target supports
>   recovery within connection, it MAY reject the SNACK after which it
>   MUST issue an Asynchronous Message PDU with an iSCSI event that indi-
>   cates "Request Logout".
>
> This should be conditioned on the operational ErrorRecoveryLevel of the
> session, not whether the target supports recovery within connection.

I would prefer that this not be conditioned on the ErrorRecoveryLevel. If I
am writing code, I may choose to support recovery-within-connection, but
not all the features that would be required to move me up to
ErrorRecoveryLevel 1. I would like SNACK and Reject PDUs to work properly
for my code, even though it is technically only "ErrorRecoveryLevel 0.5".
                As I read it, changing the wording would allow the target to ignore my
improved error recovery efforts unless I have a full ErrorRecoveryLevel 1
implementation. David, I doubt that is what you intended, so maybe you want
to word it a little differently.



------_=_NextPart_001_01C22BA9.12F46870-- From owner-ips@ece.cmu.edu Mon Jul 15 05:19:40 2002 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA18578 for ; Mon, 15 Jul 2002 05:19:39 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id g6F8okE13783 for ips-outgoing; Mon, 15 Jul 2002 04:50:46 -0400 (EDT) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from d12lmsgate-2.de.ibm.com (d12lmsgate-2.de.ibm.com [195.212.91.200]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id g6F8ojX13778 for ; Mon, 15 Jul 2002 04:50:45 -0400 (EDT) Received: from d12relay02.de.ibm.com (d12relay02.de.ibm.com [9.165.215.23]) by d12lmsgate-2.de.ibm.com (8.12.3/8.12.3) with ESMTP id g6F8oUMi025812; Mon, 15 Jul 2002 10:50:31 +0200 Received: from d10hubm1.telaviv.ibm.com (d10ml001.telaviv.ibm.com [9.148.216.55]) by d12relay02.de.ibm.com (8.11.1m3/NCO/VER6.2) with ESMTP id g6F8oUr126946; Mon, 15 Jul 2002 10:50:30 +0200 To: "Dave Peterson" Cc: ips@ece.cmu.edu MIME-Version: 1.0 Subject: Re: iSCSI Rev 13 editorial comments X-Mailer: Lotus Notes Release 5.0.9 November 16, 2001 From: "Julian Satran" Message-ID: Date: Mon, 15 Jul 2002 11:50:28 +0300 X-MIMETrack: Serialize by Router on D10ML001/10/M/IBM(Release 5.0.9a |January 7, 2002) at 15/07/2002 11:50:30, Serialize complete at 15/07/2002 11:50:30 Content-Type: multipart/alternative; boundary="=_alternative 00302CFCC2256BF7_=" Sender: owner-ips@ece.cmu.edu Precedence: bulk This is a multipart message in MIME format. --=_alternative 00302CFCC2256BF7_= Content-Type: text/plain; charset="us-ascii" Dave, I would like to thank you for the detailed and extremely helpful editorial review. You have earned a place in the authors hearts. Julo "Dave Peterson" 07/07/2002 11:19 PM Please respond to "Dave Peterson" To: Julian Satran/Haifa/IBM@IBMIL cc: Subject: iSCSI Rev 13 editorial comments Howdy All, Attached are some editorial comments against iSCSI rev 13...dap #### LastCallComments.txt has been deleted (was saved in repository My Attachments Repository ->) from this note on 09 July 2002 by Julian Satran --=_alternative 00302CFCC2256BF7_= Content-Type: text/html; charset="us-ascii"
Dave,

I would like to thank you for the detailed and extremely helpful editorial review.
You have earned a place in the authors hearts.

Julo


"Dave Peterson" <dap@cisco.com>

07/07/2002 11:19 PM
Please respond to "Dave Peterson"

       
        To:        Julian Satran/Haifa/IBM@IBMIL
        cc:        
        Subject:        iSCSI Rev 13 editorial comments

       



Howdy All,

Attached are some editorial comments against iSCSI rev 13...dap


#### LastCallComments.txt has been deleted (was saved in repository My Attachments Repository ->Link) from this note on 09 July 2002 by Julian Satran

--=_alternative 00302CFCC2256BF7_=-- From owner-ips@ece.cmu.edu Mon Jul 15 05:21:48 2002 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA18637 for ; Mon, 15 Jul 2002 05:21:48 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id g6F8idB13536 for ips-outgoing; Mon, 15 Jul 2002 04:44:39 -0400 (EDT) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from best.eurologic.com ([213.190.135.5]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id g6F8iaX13531 for ; Mon, 15 Jul 2002 04:44:36 -0400 (EDT) Received: from there (wombat [192.168.7.41]) by best.eurologic.com (8.9.3+Sun/8.9.3) with SMTP id JAA09077; Mon, 15 Jul 2002 09:44:19 +0100 (BST) Message-Id: <200207150844.JAA09077@best.eurologic.com> Content-Type: text/plain; charset="iso-8859-1" From: Ken Sandars Organization: Eurologic Systems To: "Julian Satran" Subject: Re: iSCSI: DLB's [T.6] 2.3 iSCSI Session Types Date: Mon, 15 Jul 2002 09:43:06 +0000 X-Mailer: KMail [version 1.3.1] Cc: Black_David@emc.com, ips@ece.cmu.edu References: In-Reply-To: MIME-Version: 1.0 Content-Transfer-Encoding: 8bit Sender: owner-ips@ece.cmu.edu Precedence: bulk Content-Transfer-Encoding: 8bit Hi Julo and David, Given that a FIN is an acceptable mechanism for the target to close a discovery session, we have no need for Async Message pdus on discovery sessions. Cheers, Ken -- Ken Sandars Eurologic Systems Ltd ksandars@eurologic.com On Sunday 14 July 2002 2:06 pm, Julian Satran wrote: > My preference would be to stay with what is currently available - hit the > initiator with a FIN. There is nothing to recover anyhow. > > Julo > > > > > Ken Sandars > 07/12/2002 10:39 PM > Please respond to Ken Sandars > > > To: Black_David@emc.com, Julian Satran/Haifa/IBM@IBMIL > cc: ips@ece.cmu.edu > Subject: Re: iSCSI: DLB's [T.6] 2.3 iSCSI Session Types > > > > Hi all, > > I'm wondering what the preferred mechanism is for a target to force an > initiator to close a discovery session. > > In the case ot a normal session, the AM-"target requests logout" pdu is > allowed (I guess AM types 1-3 apply). So should we follow this model for > discovery sessions, or just hit 'em with a FIN? > > > Thanks, > Ken From owner-ips@ece.cmu.edu Mon Jul 15 15:38:03 2002 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA15200 for ; Mon, 15 Jul 2002 15:38:03 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id g6FIwKF22039 for ips-outgoing; Mon, 15 Jul 2002 14:58:20 -0400 (EDT) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from lion.ninthwonder.com (lion.ninthwonder.com [151.199.66.147]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id g6FIwIX22035 for ; Mon, 15 Jul 2002 14:58:18 -0400 (EDT) Received: by lion.ninthwonder.com (Postfix, from userid 1021) id 045EA30717; Mon, 15 Jul 2002 14:58:18 -0400 (EDT) Date: Mon, 15 Jul 2002 11:55:18 -0700 (PDT) From: Bill Studenmund X-X-Sender: To: Subject: Question about ErrorRecoveryLevel Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ips@ece.cmu.edu Precedence: bulk I have a question about within-command and within-connection recovery and ErrorRecoveryLevel. Mainly what does ErrorRecoveryLevel 1 imply. I think the answer is that it implies either one (or both) of within-command and within-connection recovery methods are supported. Is that correct? i.e. A, B, or A & B. ? Thus if I have within-command recovery I can operate at ErrorRecoveryLevel 1 even w/o having within-connection recovery. Take care, Bill From owner-ips@ece.cmu.edu Mon Jul 15 15:40:36 2002 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA15281 for ; Mon, 15 Jul 2002 15:40:36 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id g6FJXof24897 for ips-outgoing; Mon, 15 Jul 2002 15:33:50 -0400 (EDT) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from palrel11.hp.com (palrel11.hp.com [156.153.255.246]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id g6FJXmX24888 for ; Mon, 15 Jul 2002 15:33:48 -0400 (EDT) Received: from core.rose.hp.com (core.rose.hp.com [15.43.208.100]) by palrel11.hp.com (Postfix) with ESMTP id 3305B600746; Mon, 15 Jul 2002 12:33:47 -0700 (PDT) Received: from swathi (swathi.rose.hp.com [15.43.213.237]) by core.rose.hp.com with SMTP (8.9.3 (PHNE_22672)/8.8.6 SMKit7.02) id MAA21918; Mon, 15 Jul 2002 12:35:38 -0700 (PDT) Message-ID: <009301c22c36$896a33d0$edd52b0f@rose.hp.com> From: "Mallikarjun C." To: "Randy Jennings" , Cc: References: Subject: Re: iSCSI: need for new data SNACK code? Date: Mon, 15 Jul 2002 12:33:45 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2600.0000 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 Sender: owner-ips@ece.cmu.edu Precedence: bulk Content-Transfer-Encoding: 7bit [ Catching up on my email after a weekend site power shutdown....] Randy, Please refer to my old email to Eddy: http://www.pdl.cmu.edu/mailinglists/ips/mail/msg10674.html It required the following - a) target must always send MaxRecvDataSegmentLegth sized data-in PDUs except possibly for the last PDU. b) *if* a PDU size change happens during the life of a task, target notes the DataSN (let's say "size_changed_from") when that happens. c) connection (*not* the task) maintains the current and previous MaxRecvDataSegmentLength (let's say "PDU_size_history", an array of size 2). d) if "n" PDU size changes are to be designed for, during the life of a task, make the "size_changed_from" into an array of size n, and make the "PDU_size_history" an array of size (n+1). I believe one doesn't need to maintain exhaustive DataSN-to-PDU_size tuples for all PDUs for all active tasks as David's revised description implied. IOW, what I am suggesting is that a target can translate a DataSN to a buffer offset (even with PDU size changes) with *much* less metadata, *if* it always sends MaxRecvDataSegmentLegth sized data-in PDUs except possibly for the last PDU. Any retransmission request would have to take the aforementioned size_changed_from and PDU_size_history arrays into consideration, and calculate the buffer offset accordingly. Agreed, this is additional CPU cycles where a simple (and memory-consuming) tuple table could be faster - but it's exception processing, speed is not much of a consideration here. Hope that explains my earlier response. -- Mallikarjun Mallikarjun Chadalapaka Networked Storage Architecture Network Storage Solutions Hewlett-Packard MS 5668 Roseville CA 95747 cbm@rose.hp.com ----- Original Message ----- From: "Randy Jennings" To: "Mallikarjun C." ; Cc: Sent: Friday, July 12, 2002 5:06 PM Subject: RE: iSCSI: need for new data SNACK code? > > > The flag per task is not needed - I'd expect the Target to look > > > at the Data PDUs it would have to resend, check them against the max > > > Data PDU size for this connection and fail the regular SNACK if any > > > PDU is too large > > > > I am afraid there's no free lunch here. In this description, you're now > > expecting targets to maintain the PDU size of every PDU that it shipped > > for each of the tasks, which causes a metadata explosion. This > > was discussed > > by Eddy Quicksall and myself in an earlier thread - "changing > > MaxPDUDataLength". > > I did not check the thread, but I remember your conversation with Eddy > Quicksall. > > However, I do not remember what was said about knowing the length of the > PDU. From this isolated discussion, though, it seems like you would at > least be able to recalculate the length of the PDU at all times or you could > never send it again. (Unless you redid all the steps that got to that point > in the first place, and I do not think that is possible based off a PDU id > number...) > > Am I missing something? > > Sincerely, > Randy > Data Transit > > From owner-ips@ece.cmu.edu Mon Jul 15 17:10:04 2002 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA16710 for ; Mon, 15 Jul 2002 17:10:04 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id g6FKah829806 for ips-outgoing; Mon, 15 Jul 2002 16:36:43 -0400 (EDT) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from msgbas1.cos.agilent.com (msgbas1x.cos.agilent.com [192.25.240.36]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id g6FKafX29801 for ; Mon, 15 Jul 2002 16:36:41 -0400 (EDT) Received: from msgrel1t.cos.agilent.com (msgrel1t.cos.agilent.com [130.29.152.157]) by msgbas1.cos.agilent.com (Postfix) with ESMTP id 5C1E3A6AB; Mon, 15 Jul 2002 14:36:40 -0600 (MDT) Received: from axcsbh3.cos.agilent.com (axcsbh3.cos.agilent.com [130.29.152.190]) by msgrel1t.cos.agilent.com (Postfix) with SMTP id BC9A5564; Mon, 15 Jul 2002 14:36:36 -0600 (MDT) Received: from 130.29.152.190 by axcsbh3.cos.agilent.com (InterScan E-Mail VirusWall NT); Mon, 15 Jul 2002 14:36:33 -0600 Received: by axcsbh3.cos.agilent.com with Internet Mail Service (5.5.2653.19) id <355MK3PR>; Mon, 15 Jul 2002 14:36:33 -0600 Message-ID: <01A7DAF31F93D511AEE300D0B706ED9201BF49F6@axcs13.cos.agilent.com> From: vince_cavanna@agilent.com To: vince_cavanna@agilent.com, ni1d@arrl.net Cc: Black_David@emc.com, ips@ece.cmu.edu, tom@arcot.com Subject: RE: IPS security draft: SRP groups Date: Mon, 15 Jul 2002 14:36:32 -0600 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="ISO-8859-1" Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ece.cmu.edu id g6FKafX29802 Sender: owner-ips@ece.cmu.edu Precedence: bulk Content-Transfer-Encoding: 8bit I was unsuccessful at getting Mathematica to prove the primality of the SRP moduli. If we cannot prove the primality of our chosen moduli I thought why not use moduli whose primality has been proven such as the well known groups in Oakley. Tom Wu told me that would not be a problem provided we found generators for them other than 2 (the generator that is given in Oakley RFC), since 2 in not useful for SRP. Using Mathematica I have been able to find other generators for the groups. The 768-bit modulus from IPSEc has 7 as a generator. The 1024-bit prime from IPsec RFC-2539 has 5 as a generator. I have used the PrimitiveRoot function in the NumberTheory package of Mathematica. As a simple (incomplete) verification I have raised the generator to the power equal to one less than the moduli and have gotten an answer that is congruent to 1 as would be expected for any generator. Vince |-----Original Message----- |From: CAVANNA,VICENTE V (A-Roseville,ex1) |Sent: Friday, July 12, 2002 9:11 AM |To: 'Paul Koning'; CAVANNA,VICENTE V (A-Roseville,ex1) |Cc: Black_David@emc.com; ips@ece.cmu.edu; tom@arcot.com |Subject: RE: IPS security draft: SRP groups | | |Hi Paul, | |I suspected as much, since I don't have a supercomputer on my |desktop. Mathematica apparently also has the capability to |perform a mathematical proof of primality and to produce a |"certificate" using which Mathematica's results may be |independently and easily verified. When I attempted to perform |the proof on the smallest modulus (the one with 768 bits) my |computer was rendered useless for over 20 minutes which just |happened to be my threshold of tolerance for this morning. I |will try again when I leave the office tonight and if I get |any useful results I will look deeper into the method. | |Vince | | | ||-----Original Message----- ||From: Paul Koning [mailto:ni1d@arrl.net] ||Sent: Friday, July 12, 2002 7:15 AM ||To: vince_cavanna@agilent.com ||Cc: Black_David@emc.com; ips@ece.cmu.edu; tom@arcot.com ||Subject: RE: IPS security draft: SRP groups || || ||>>>>> "vince" == vince cavanna writes: || || vince> Hi David, I can't prove so, but Mathematica from Wolfram || vince> certifies as prime (in a matter seconds) all five moduli || vince> specified in the iSCSI security draft for use in SRP! I used || vince> the PrimeQ built-in function. PrimeQ first tests for || vince> divisibility using small primes, then uses the Miller­Rabin || vince> strong pseudoprime test base 2 and base 3, and then uses a || vince> Lucas test. I have not explored the nature of these tests. || ||Miller-Rabin is a probabilistic test. As for "Lucas" -- the Handbook ||of Applied Cryptography lists "Lucas-Lehmer primality test for ||Mersenne numbers". That suggests that this test has no meaning for ||numbers that aren't Mersenne numbers (such as randomly chosen ||numbers). || ||So I think you have a probabilistic primality test here, similar to ||what Tom did. That's certainly useful confirmation, but it doesn't ||sound like we have the primality proofs yet. (Unfortunately, HAC is ||not sufficiently helpful in pointing to an algorithm to to so...) || || paul || | From owner-ips@ece.cmu.edu Mon Jul 15 17:21:40 2002 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA16858 for ; Mon, 15 Jul 2002 17:21:40 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id g6FL2YO01762 for ips-outgoing; Mon, 15 Jul 2002 17:02:34 -0400 (EDT) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from msgbas2.cos.agilent.com (msgbas2x.cos.agilent.com [192.25.240.37]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id g6FL2VX01753 for ; Mon, 15 Jul 2002 17:02:32 -0400 (EDT) Received: from msgrel1t.cos.agilent.com (msgrel1t.cos.agilent.com [130.29.152.157]) by msgbas2.cos.agilent.com (Postfix) with ESMTP id 5682EF4E; Mon, 15 Jul 2002 15:02:30 -0600 (MDT) Received: from axcsbh4.cos.agilent.com (axcsbh4.cos.agilent.com [130.29.152.145]) by msgrel1t.cos.agilent.com (Postfix) with SMTP id 8864749E; Mon, 15 Jul 2002 15:02:29 -0600 (MDT) Received: from 130.29.152.145 by axcsbh4.cos.agilent.com (InterScan E-Mail VirusWall NT); Mon, 15 Jul 2002 15:02:28 -0600 Received: by axcsbh4.cos.agilent.com with Internet Mail Service (5.5.2653.19) id <3YPNQLFT>; Mon, 15 Jul 2002 15:02:28 -0600 Message-ID: <01A7DAF31F93D511AEE300D0B706ED9201BF49F7@axcs13.cos.agilent.com> From: vince_cavanna@agilent.com To: ips@ece.cmu.edu Cc: tom@arcot.com, vince_cavanna@agilent.com, ni1d@arrl.net, Black_David@emc.com, pat_thaler@agilent.com, dave_sheehy@agilent.com Subject: RE: IPS security draft: SRP groups (resend) Date: Mon, 15 Jul 2002 15:02:18 -0600 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ece.cmu.edu id g6FL2WX01754 Sender: owner-ips@ece.cmu.edu Precedence: bulk Content-Transfer-Encoding: 8bit I previously hit the Send button when I had meant to hit the Save button. This is the message I had intended to send. I was unsuccessful at getting Mathematica to prove the primality of the SRP moduli. If we cannot prove the primality of our chosen moduli I thought why not use moduli, such as the well known groups from RFC 2412, whose primality has been proven. Tom Wu told me that would not be a problem provided we found generators other than 2 (the generator that is given in RFC 2412), because 2 in not useful (for these moduli) in SRP (I don't know why such is the case). Using Mathematica I have been able to find other generators for a couple of the well known groups. The 768-bit modulus from RFC 2412 has 7 as a generator. The 1024-bit prime from RFC 2412 has 5 as a generator. I have used the PrimitiveRoot function in the NumberTheory package of Mathematica. As a simple (incomplete) verification I have raised the generator to the power equal to one less than the moduli and have gotten an answer that is congruent to 1 as would be expected for any generator. What I can't tell from that simple verification is if I also get a number congruent to 1 when I raise the generator to some lower power - which would mean the "generator" is not really a generator. Vince |-----Original Message----- |From: CAVANNA,VICENTE V (A-Roseville,ex1) |Sent: Friday, July 12, 2002 9:11 AM |To: 'Paul Koning'; CAVANNA,VICENTE V (A-Roseville,ex1) |Cc: Black_David@emc.com; ips@ece.cmu.edu; tom@arcot.com |Subject: RE: IPS security draft: SRP groups | | |Hi Paul, | |I suspected as much, since I don't have a supercomputer on my |desktop. Mathematica apparently also has the capability to |perform a mathematical proof of primality and to produce a |"certificate" using which Mathematica's results may be |independently and easily verified. When I attempted to perform |the proof on the smallest modulus (the one with 768 bits) my |computer was rendered useless for over 20 minutes which just |happened to be my threshold of tolerance for this morning. I |will try again when I leave the office tonight and if I get |any useful results I will look deeper into the method. | |Vince | | | ||-----Original Message----- ||From: Paul Koning [mailto:ni1d@arrl.net] ||Sent: Friday, July 12, 2002 7:15 AM ||To: vince_cavanna@agilent.com ||Cc: Black_David@emc.com; ips@ece.cmu.edu; tom@arcot.com ||Subject: RE: IPS security draft: SRP groups || || ||>>>>> "vince" == vince cavanna writes: || || vince> Hi David, I can't prove so, but Mathematica from Wolfram || vince> certifies as prime (in a matter seconds) all five moduli || vince> specified in the iSCSI security draft for use in SRP! I used || vince> the PrimeQ built-in function. PrimeQ first tests for || vince> divisibility using small primes, then uses the Miller­Rabin || vince> strong pseudoprime test base 2 and base 3, and then uses a || vince> Lucas test. I have not explored the nature of these tests. || ||Miller-Rabin is a probabilistic test. As for "Lucas" -- the Handbook ||of Applied Cryptography lists "Lucas-Lehmer primality test for ||Mersenne numbers". That suggests that this test has no meaning for ||numbers that aren't Mersenne numbers (such as randomly chosen ||numbers). || ||So I think you have a probabilistic primality test here, similar to ||what Tom did. That's certainly useful confirmation, but it doesn't ||sound like we have the primality proofs yet. (Unfortunately, HAC is ||not sufficiently helpful in pointing to an algorithm to to so...) || || paul || | From owner-ips@ece.cmu.edu Mon Jul 15 17:42:58 2002 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA17367 for ; Mon, 15 Jul 2002 17:42:58 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id g6FLEGs02697 for ips-outgoing; Mon, 15 Jul 2002 17:14:16 -0400 (EDT) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from atlrel7.hp.com (atlrel7.hp.com [156.153.255.213]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id g6FLEDX02689 for ; Mon, 15 Jul 2002 17:14:13 -0400 (EDT) Received: from core.rose.hp.com (core.rose.hp.com [15.43.208.100]) by atlrel7.hp.com (Postfix) with ESMTP id 7E1C8805152; Mon, 15 Jul 2002 17:14:12 -0400 (EDT) Received: from swathi (swathi.rose.hp.com [15.43.213.237]) by core.rose.hp.com with SMTP (8.9.3 (PHNE_22672)/8.8.6 SMKit7.02) id OAA02108; Mon, 15 Jul 2002 14:16:03 -0700 (PDT) Message-ID: <00d401c22c44$90759b20$edd52b0f@rose.hp.com> From: "Mallikarjun C." To: , "Julian Satran" Cc: References: Subject: Re: iSCSI: need for new data SNACK code? Date: Mon, 15 Jul 2002 14:14:10 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2600.0000 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 Sender: owner-ips@ece.cmu.edu Precedence: bulk Content-Transfer-Encoding: 7bit > Well - I tend to agree with Mallikarjun that this new code was not strictly > required. > But I added it nevertheless for several reason: > > it does really no harm Julian, it never was my argument that David's proposal is unworkable - of course it does work. It however continues to be my position that the change is *not* needed for technical correctness despite David's arguments to the contrary. Let's not add in features that lack sufficient grounds. Based on the reflector arguments and Yokohama discussions, I am sure the WG makes the appropriate decision. There are three crucial aspects to David's arguments (at least that I understand) - a) one Data SNACK code leads to ambiguity on either side (several references to - "if in doubt, negotiate" maxim) b) if multiple I/Os are in progress when a PDU size is redeclared, it is unclear when the change is effective, or somehow the situation is far more complicated than with one I/O. c) the proposed new code invokes a different "algorithm" that requires a different behavior on target, so is justified. [ Let me acknowledge that David was correct about the case of target-initiated MaxRecvDataSegmentLength change being irrelevant for the current discussion. I can concoct a scenario with bidirectional commands and certain implementation constraints, but it's too hypothetical to worth taking reflector bandwidth....and certainly not what I had in mind when I thought it was relevant. ] Brief comments on the three crucial aspects - a) There is *no ambiguity* wrt when the PDU size changed for any I/O if the following simple initiator rules are followed. 0. Do not start the text negotiation if any data SNACKs are pending. (Negotiation may start, however, as soon as those I/Os are planned to be aborted - for whatever reason.) 1. Once a text negotiation is underway, for each I/O that requires the issuance of a data SNACK, hold off doing so until the negotiation is complete. Mark it for subsequent status drop (whenever the status arrives). 2. Once the negotiation concludes, issue the appropriate data SNACK(s) with the required BegRun (doesn't have to be 0), but RunLength must be zero. 3. Issue the status SNACK eventually. 4. If the PDU change happens multiple times *and* the initiator intends to continue one I/O across these changes, repeat steps 0-3 multiple times. On the target side, the rule is simple. 0. Reject a data SNACK w/ RunLength != 0, if the SNACK is for a task across a PDU size change. Or else, resegment per the current MaxRecvDataSegmentLength, as needed. (Note: I'm suggesting a rule stronger than requiring RunLength=0 for the *first* data SNACK - what's stated today.) b) Multiple I/Os do not change the situation in any qualitative way, as noted above. If the I/O doesn't need a data SNACK, well and good - signal the completion to SCSI. If it does, follow (a) above. c) Assigning an existing "algorithm" for a new code in itself is not a justification for a new code. We need to analyze starting from a single code, which can automatically and correctly pick the right "algorithm" based on the negotiation state, and then question the need for the second (see Marjorie's email about Occam's Razor). I don't see the need. Other quick responses to David's message - > The only obvious way I see to eliminate this "metadata explosion" > is to require BegRun to be zero if there's any possibility of > resegmentation. Please see my response to Randy Jennings. I believe we can get away without the metadata explosion that I feared from your description, even for BegRun != 0. > Irrelevant - iSCSI does not require, recommend, or even describe > ULPDU containment. TCP ULP framing was removed from the iSCSI > draft many months ago after a long controversial discussion. I > strongly object to attempting to sneak it back in. Besides, > adaptation to PMTU degradation is the transport's job, and iSCSI > should not be trying to do the transport's work for it, as it > in general does not have direct access to PMTU information. I'm sorry that an ulterior motive is being ascribed to the reference to "ULPDU containment". No need for recounting layering principles either. I was merely attempting to come up with a good reason why an initiator may change the max PDU size in the first place for an operational iSCSI connection. If you have one that has nothing to do with ULPDU containment, please let me know, and I'll use that in future. -- Mallikarjun Mallikarjun Chadalapaka Networked Storage Architecture Network Storage Solutions Hewlett-Packard MS 5668 Roseville CA 95747 cbm@rose.hp.com ----- Original Message ----- From: "Julian Satran" To: Cc: ; ; Sent: Saturday, July 13, 2002 4:26 PM Subject: RE: iSCSI: need for new data SNACK code? > Well - I tend to agree with Mallikarjun that this new code was not strictly > required. > But I added it nevertheless for several reason: > > it does really no harm > The "settling time" of a change in MaxRecvPDULength vs. data is not > synchronized with command execution or even between connections so > setting clear expectations is not bad. It also helps building > sophisticated initiators that don't have to synchronize different > threads. > the burden of resending status went on the transmitter and that would > have been confusing. Please pay attention to the fact that initiator has > now to ask for the status if it wants it again. That is not really > related but easier to do now and it was one technical issue that David > raised that I would have also called technical and not syntactic sugar. > All the plugfests have not shown yet a large number of within command > recovery (I counted 2) although interest was expressed in private by > many > > The new text takes also care about all the issues related to rejects (i.e. > - it is tolerant). > I suggest we close this thread and will fix the appendix soon. > > Julo > > > > > Black_David@emc.c > om To: cbm@rose.hp.com > Sent by: cc: ips@ece.cmu.edu > owner-ips@ece.cmu Subject: RE: iSCSI: need for new data SNACK code? > .edu > > > 07/12/2002 12:40 > AM > Please respond to > Black_David > > > > > > Mallikarjun, > > > I am still unclear about the need to add the new data SNACK > > code. IMHO, this can only be confusing to both initiator and target > > implementers - to have two codes that have identical semantics > > on the wire. > > > > The only remaining reason that I see from David (attached below) > > is that the new code makes the initiator aware that it must request > > status retransmission. IOW, you're expecting the initiator > > to be careful > > enough to use the new code, but somehow you don't expect it to be > > attentive enough to discard the status PDU unless it had used > > this new > > code in an *outbound* SNACK. I completely miss this rationale. > > I disagree with the "careful enough" characterization. The new code > provides the initiator with a more robust way to detect resegmentation > by requiring the initiator to explicitly ask for it. The initiator > can take a simple approach of always starting with the existing > Data SNACK code that does not resegment and only using the new code > when the non-resegmenting SNACK doesn't work. If the target makes > its own choice to resegment, and the initiator doesn't think the > target resegmented, there are error scenarios that combine this with > corrupt Data PDU headers to cause the initiator to successfully > complete a SCSI command that has not delivered all its data > (the resegmented PDUs caused the Data PDU count to match the ExpDataSN > value in the response that should have been discarded, but wasn't). > While these should be rare, their consequences can be catastrophic. > > > I'd buy the new code if it's meant to convey something different to > > *targets* because they need to process these SNACK PDUs. I see > > nothing that the targets need to different in satisfying either SNACK. > > Both parties are aware of the fact of PDU size change, it > > had happened. > > It is conveying the Initiator's instructions that resegmentation is > permitted. I am not comfortable with the last sentence above that assumes > that the Initiator and Target will always have identical views of all of > the effects of a full feature phase PDU size change - (which is > a rare event to begin with, and hence likely to involve code that > isn't well exercised/tested). > > > The only two changes from the rev14 text that I propose are that we add: > > > > a) The first status PDU must always be dropped after a > > MaxRecvDataSegmentLength change, if ever a data > SNACK is > > employed for the task. > > When does this obligation to drop the first status PDU expire? I think > the Initiator has to mark all commands that are outstanding or become > outstanding between the time it starts the negotiation that changes > MaxRecvDataSegmentLength and the time that it gets the final Text Response > of that negotiation from the target. This requires additional Initiator > state per command for something that almost never happens, and if it > gets one of these markings wrong, it's vulnerable to failing to deliver > all the data for a SCSI command in a compound error situation. An > alternative with the new code could involve a single bit per connection > that records whether the PDU size was ever changed (if so, retry any > failed Data SNACK as a resegmenting Data SNACK). > > > Initiator MUST issue a status SNACK to recover the > > status PDU (i.e. move the onus of retransmitting > > status from the target to the initiator). > > b) A SNACK requesting an R2T, Data or Status PDU for a task MUST be > > issued before the status for the task is acknowledged. > > I have no problem with these two. > > > I'll be glad to see any technical reasons that I am > > overlooking, that require two codes. > > See above. This is somewhat analogous to the "if in doubt, negotiate > it" principle for login - telling the other side *exactly* what is wanted > is more robust than assuming that it will do what is wanted, and in > this resegmenting Data SNACK case, there are potentially nasty > consequences to an incorrect assumption. Does this make any sense? > > > I'd assume Elizabeth would be the process co-chair, if need be. > > Yes. > > Thanks, > --David > > > > 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. > > > > > From owner-ips@ece.cmu.edu Mon Jul 15 17:43:28 2002 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA17381 for ; Mon, 15 Jul 2002 17:43:28 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id g6FLT0G03706 for ips-outgoing; Mon, 15 Jul 2002 17:29:00 -0400 (EDT) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from snjspop2.snjs.qwest.net (snjspop2.snjs.qwest.net [168.103.24.2]) by ece.cmu.edu (8.11.0/8.10.2) with SMTP id g6FLSvX03694 for ; Mon, 15 Jul 2002 17:28:57 -0400 (EDT) Received: (qmail 38132 invoked from network); 15 Jul 2002 21:28:57 -0000 Received: from 168-103-213-134.dslgw2.snva.qwest.net (HELO theglowmonster) (168.103.213.134) by snjspop2.snjs.qwest.net with SMTP; 15 Jul 2002 21:28:57 -0000 Date: Mon, 15 Jul 2002 14:26:22 -0700 Message-ID: From: "Randy Jennings" To: "Mallikarjun C." , Black_David@emc.com Cc: ips@ece.cmu.edu Subject: RE: iSCSI: need for new data SNACK code? MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0) X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4910.0300 Importance: Normal In-Reply-To: <009301c22c36$896a33d0$edd52b0f@rose.hp.com> Sender: owner-ips@ece.cmu.edu Precedence: bulk Content-Transfer-Encoding: 7bit Fair enough. That is actually what I meant about being able to recalculate it somehow; although, I did not have it developed quite so neatly. However, your argument applies to both the previous discussion, and also seems to fall in David's favor, because the necessary state would need to be saved anyway (for any retransmission to happen). I guess what I was confused about is how this argues against having another opcode for the SNACK and against the target being the one catching the error condition. Sincerely, Randy Jennings Data Transit > -----Original Message----- > I believe one doesn't need to maintain exhaustive DataSN-to-PDU_size tuples > for all PDUs for all active tasks as David's revised description implied. IOW, > what I am suggesting is that a target can translate a DataSN to a buffer offset > (even with PDU size changes) with *much* less metadata, *if* it always sends > MaxRecvDataSegmentLegth sized data-in PDUs except possibly for the last PDU. > Any retransmission request would have to take the aforementioned size_changed_from > and PDU_size_history arrays into consideration, and calculate the > buffer offset accordingly. > > > > > The flag per task is not needed - I'd expect the Target to look > > > > at the Data PDUs it would have to resend, check them against the max > > > > Data PDU size for this connection and fail the regular SNACK if any > > > > PDU is too large > > > > > > I am afraid there's no free lunch here. In this description, you're now > > > expecting targets to maintain the PDU size of every PDU that it shipped > > > for each of the tasks, which causes a metadata explosion. This was discussed > > > by Eddy Quicksall and myself in an earlier thread - "changing MaxPDUDataLength". > > > > However, I do not remember what was said about knowing the length of the > > PDU. From this isolated discussion, though, it seems like you would at > > least be able to recalculate the length of the PDU at all times > > or you could never send it again. (Unless you redid all the steps that got > > to that point in the first place, and I do not think that is possible based > > off a PDU id > > number...) From owner-ips@ece.cmu.edu Mon Jul 15 18:32:13 2002 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA18313 for ; Mon, 15 Jul 2002 18:32:12 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id g6FLxD305636 for ips-outgoing; Mon, 15 Jul 2002 17:59:13 -0400 (EDT) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from msgbas1.cos.agilent.com (msgbas1x.cos.agilent.com [192.25.240.36]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id g6FLxBX05631 for ; Mon, 15 Jul 2002 17:59:11 -0400 (EDT) Received: from msgrel1t.cos.agilent.com (msgrel1t.cos.agilent.com [130.29.152.157]) by msgbas1.cos.agilent.com (Postfix) with ESMTP id 7B017B685; Mon, 15 Jul 2002 15:59:10 -0600 (MDT) Received: from axcsbh3.cos.agilent.com (axcsbh3.cos.agilent.com [130.29.152.190]) by msgrel1t.cos.agilent.com (Postfix) with SMTP id 32C94525; Mon, 15 Jul 2002 15:59:10 -0600 (MDT) Received: from 130.29.152.190 by axcsbh3.cos.agilent.com (InterScan E-Mail VirusWall NT); Mon, 15 Jul 2002 15:59:07 -0600 Received: by axcsbh3.cos.agilent.com with Internet Mail Service (5.5.2653.19) id <355MKTGF>; Mon, 15 Jul 2002 15:59:07 -0600 Message-ID: <01A7DAF31F93D511AEE300D0B706ED9201BF49F8@axcs13.cos.agilent.com> From: vince_cavanna@agilent.com To: vince_cavanna@agilent.com, ips@ece.cmu.edu Cc: tom@arcot.com, ni1d@arrl.net, Black_David@emc.com, pat_thaler@agilent.com, dave_sheehy@agilent.com Subject: RE: IPS security draft: SRP groups (follow-up) Date: Mon, 15 Jul 2002 15:59:05 -0600 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="ISO-8859-1" Sender: owner-ips@ece.cmu.edu Precedence: bulk Upon re-reading previous email on this subject I noticed the memo from Bernard Aboba showing the procedure Dan Simon gave to find group generators when the moduli that define the group are of the form p-1=2q, q prime, as is the case for the IKE moduli (primes). I also now understand that SRP simply requires a true generator (generates all elements of the group) whereas IKE allows the use of 2 which, though misleadingly called a generator, is not strictly speaking a generator. I thought SRP only allowed a subset of generators which made no sense to me. I now realize SRP requires a true generator and it is IKE that allows a non-generator. In any case, using Dan Simon's procedure it is very easy to compute generators for any of the IKE moduli and thus I see no problem using IKE moduli as the primary moduli for SRP. The moduli are certifiably prime and the generators are easy to compute deterministically. I have verified that the generators I computed pass the two tests that Dan Simon gave. If there is interest in pursuing this approach I will compute generators for the rest of the IKE moduli. Vince |-----Original Message----- |From: CAVANNA,VICENTE V (A-Roseville,ex1) |Sent: Monday, July 15, 2002 2:02 PM |To: 'ips@ece.cmu.edu' |Cc: 'tom@arcot.com'; CAVANNA,VICENTE V (A-Roseville,ex1); |'Paul Koning'; |'Black_David@emc.com'; THALER,PAT (A-Roseville,ex1); SHEEHY,DAVE |(A-Americas,unix1) |Subject: RE: IPS security draft: SRP groups (resend) | | |I previously hit the Send button when I had meant to hit the |Save button. This is the message I had intended to send. | |I was unsuccessful at getting Mathematica to prove the |primality of the SRP moduli. | |If we cannot prove the primality of our chosen moduli I |thought why not use moduli, such as the well known groups from |RFC 2412, whose primality has been proven. Tom Wu told me that |would not be a problem provided we found generators other than |2 (the generator that is given in RFC 2412), because 2 in not |useful (for these moduli) in SRP (I don't know why such is the case). | |Using Mathematica I have been able to find other generators |for a couple of the well known groups. The 768-bit modulus |from RFC 2412 has 7 as a generator. The 1024-bit prime from |RFC 2412 has 5 as a generator. I have used the PrimitiveRoot |function in the NumberTheory package of Mathematica. As a |simple (incomplete) verification I have raised the generator |to the power equal to one less than the moduli and have gotten |an answer that is congruent to 1 as would be expected for any |generator. What I can't tell from that simple verification is |if I also get a number congruent to 1 when I raise the |generator to some lower power - which would mean the |"generator" is not really a generator. | |Vince | ||-----Original Message----- ||From: CAVANNA,VICENTE V (A-Roseville,ex1) ||Sent: Friday, July 12, 2002 9:11 AM ||To: 'Paul Koning'; CAVANNA,VICENTE V (A-Roseville,ex1) ||Cc: Black_David@emc.com; ips@ece.cmu.edu; tom@arcot.com ||Subject: RE: IPS security draft: SRP groups || || ||Hi Paul, || ||I suspected as much, since I don't have a supercomputer on my ||desktop. Mathematica apparently also has the capability to ||perform a mathematical proof of primality and to produce a ||"certificate" using which Mathematica's results may be ||independently and easily verified. When I attempted to perform ||the proof on the smallest modulus (the one with 768 bits) my ||computer was rendered useless for over 20 minutes which just ||happened to be my threshold of tolerance for this morning. I ||will try again when I leave the office tonight and if I get ||any useful results I will look deeper into the method. || ||Vince || || || |||-----Original Message----- |||From: Paul Koning [mailto:ni1d@arrl.net] |||Sent: Friday, July 12, 2002 7:15 AM |||To: vince_cavanna@agilent.com |||Cc: Black_David@emc.com; ips@ece.cmu.edu; tom@arcot.com |||Subject: RE: IPS security draft: SRP groups ||| ||| |||>>>>> "vince" == vince cavanna writes: ||| ||| vince> Hi David, I can't prove so, but Mathematica from Wolfram ||| vince> certifies as prime (in a matter seconds) all five moduli ||| vince> specified in the iSCSI security draft for use in SRP! I used ||| vince> the PrimeQ built-in function. PrimeQ first tests for ||| vince> divisibility using small primes, then uses the Miller­Rabin ||| vince> strong pseudoprime test base 2 and base 3, and then uses a ||| vince> Lucas test. I have not explored the nature of these tests. ||| |||Miller-Rabin is a probabilistic test. As for "Lucas" -- the Handbook |||of Applied Cryptography lists "Lucas-Lehmer primality test for |||Mersenne numbers". That suggests that this test has no meaning for |||numbers that aren't Mersenne numbers (such as randomly chosen |||numbers). ||| |||So I think you have a probabilistic primality test here, similar to |||what Tom did. That's certainly useful confirmation, but it doesn't |||sound like we have the primality proofs yet. (Unfortunately, HAC is |||not sufficiently helpful in pointing to an algorithm to to so...) ||| ||| paul ||| || | From owner-ips@ece.cmu.edu Mon Jul 15 18:36:37 2002 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA18826 for ; Mon, 15 Jul 2002 18:36:37 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id g6FMUtM07576 for ips-outgoing; Mon, 15 Jul 2002 18:30:55 -0400 (EDT) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from palrel11.hp.com (palrel11.hp.com [156.153.255.246]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id g6FMUqX07571 for ; Mon, 15 Jul 2002 18:30:52 -0400 (EDT) Received: from core.rose.hp.com (core.rose.hp.com [15.43.208.100]) by palrel11.hp.com (Postfix) with ESMTP id F2B4E600440; Mon, 15 Jul 2002 15:30:51 -0700 (PDT) Received: from swathi (swathi.rose.hp.com [15.43.213.237]) by core.rose.hp.com with SMTP (8.9.3 (PHNE_22672)/8.8.6 SMKit7.02) id PAA10489; Mon, 15 Jul 2002 15:32:41 -0700 (PDT) Message-ID: <00ee01c22c4f$4545dc40$edd52b0f@rose.hp.com> From: "Mallikarjun C." To: "Randy Jennings" , Cc: References: Subject: Re: iSCSI: need for new data SNACK code? Date: Mon, 15 Jul 2002 15:30:49 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2600.0000 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 Sender: owner-ips@ece.cmu.edu Precedence: bulk Content-Transfer-Encoding: 7bit > However, > your argument applies to both the previous discussion, and also seems to > fall in David's favor, because the necessary state would need to be saved > anyway (for any retransmission to happen). Remember, I didn't argue that "necessary state" doesn't have to be saved - that would be too brave on my part to do that..... My metadata explosion comment was based on David's description that seemed to imply a tuple table. > I guess what I was confused about is how this argues against having another > opcode for the SNACK and against the target being the one catching the error > condition. Though not sure about what you mean by " target being the one catching the error condition" (there's no error in redeclaration of max PDU size, except for the lost data itself - and the onus is on the initiator to "catch" that).... This doesn't argue either way (and a needless subroutine call), I was pointing this out when a comparable scheme on the initiator side was argued as flawed. My point was and is that I see only implementation errors that can make the one-code scheme untenable, not any protocol issues. Ironically, the same applies to the two-code scheme as well. -- Mallikarjun Mallikarjun Chadalapaka Networked Storage Architecture Network Storage Solutions Hewlett-Packard MS 5668 Roseville CA 95747 cbm@rose.hp.com ----- Original Message ----- From: "Randy Jennings" To: "Mallikarjun C." ; Cc: Sent: Monday, July 15, 2002 2:26 PM Subject: RE: iSCSI: need for new data SNACK code? > Fair enough. That is actually what I meant about being able to recalculate > it somehow; although, I did not have it developed quite so neatly. However, > your argument applies to both the previous discussion, and also seems to > fall in David's favor, because the necessary state would need to be saved > anyway (for any retransmission to happen). > > I guess what I was confused about is how this argues against having another > opcode for the SNACK and against the target being the one catching the error > condition. > > Sincerely, > Randy Jennings > Data Transit > > > -----Original Message----- > > I believe one doesn't need to maintain exhaustive DataSN-to-PDU_size > tuples > > for all PDUs for all active tasks as David's revised description implied. > IOW, > > what I am suggesting is that a target can translate a DataSN to a buffer > offset > > (even with PDU size changes) with *much* less metadata, *if* it always > sends > > MaxRecvDataSegmentLegth sized data-in PDUs except possibly for the last > PDU. > > Any retransmission request would have to take the aforementioned > size_changed_from > > and PDU_size_history arrays into consideration, and calculate the > > buffer offset accordingly. > > > > > > > The flag per task is not needed - I'd expect the Target to look > > > > > at the Data PDUs it would have to resend, check them against the max > > > > > Data PDU size for this connection and fail the regular SNACK if any > > > > > PDU is too large > > > > > > > > I am afraid there's no free lunch here. In this description, you're > now > > > > expecting targets to maintain the PDU size of every PDU that it > shipped > > > > for each of the tasks, which causes a metadata explosion. This was > discussed > > > > by Eddy Quicksall and myself in an earlier thread - "changing > MaxPDUDataLength". > > > > > > However, I do not remember what was said about knowing the length of the > > > PDU. From this isolated discussion, though, it seems like you would at > > > least be able to recalculate the length of the PDU at all times > > > or you could never send it again. (Unless you redid all the steps that > got > > > to that point in the first place, and I do not think that is possible > based > > > off a PDU id > > > number...) > > From owner-ips@ece.cmu.edu Mon Jul 15 19:26:20 2002 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA18319 for ; Mon, 15 Jul 2002 18:32:13 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id g6FMMIt07083 for ips-outgoing; Mon, 15 Jul 2002 18:22:18 -0400 (EDT) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from d12lmsgate.de.ibm.com (d12lmsgate.de.ibm.com [195.212.91.199]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id g6FMMFX07078 for ; Mon, 15 Jul 2002 18:22:16 -0400 (EDT) Received: from d12relay01.de.ibm.com (d12relay01.de.ibm.com [9.165.215.22]) by d12lmsgate.de.ibm.com (8.12.3/8.12.3) with ESMTP id g6FMM8Lt025128 for ; Tue, 16 Jul 2002 00:22:08 +0200 Received: from d10hubm1.telaviv.ibm.com (d10ml001.telaviv.ibm.com [9.148.216.55]) by d12relay01.de.ibm.com (8.11.1m3/NCO/VER6.2) with ESMTP id g6FMM9N68184 for ; Tue, 16 Jul 2002 00:22:09 +0200 To: ips@ece.cmu.edu MIME-Version: 1.0 Subject: Re: iSCSI - decimal coded binary strings - a proposed resolution X-Mailer: Lotus Notes Release 5.0.9 November 16, 2001 From: "Julian Satran" Message-ID: Date: Tue, 16 Jul 2002 01:22:06 +0300 X-MIMETrack: Serialize by Router on D10ML001/10/M/IBM(Release 5.0.9a |January 7, 2002) at 16/07/2002 01:22:09, Serialize complete at 16/07/2002 01:22:09 Content-Type: multipart/alternative; boundary="=_alternative 007A5F49C2256BF7_=" Sender: owner-ips@ece.cmu.edu Precedence: bulk This is a multipart message in MIME format. --=_alternative 007A5F49C2256BF7_= Content-Type: text/plain; charset="us-ascii" ----- Forwarded by Julian Satran/Haifa/IBM on 07/16/2002 01:16 AM ----- Paul Koning 07/15/2002 04:53 PM Please respond to Paul Koning To: Julian Satran/Haifa/IBM@IBMIL cc: Subject: Re: iSCSI - decimal coded binary strings - a proposed resolution >>>>> "Julian" == Julian Satran writes: Julian> Paul, I was asking if it would acceptable to say the maximum Julian> acceptable value (allowed value) will be limiting element Julian> (not the actual). Oops. I misread your message, my apologies. Yes, that would be great. Thanks! paul --=_alternative 007A5F49C2256BF7_= Content-Type: text/html; charset="us-ascii"
----- Forwarded by Julian Satran/Haifa/IBM on 07/16/2002 01:16 AM -----
Paul Koning <ni1d@arrl.net>

07/15/2002 04:53 PM
Please respond to Paul Koning

       
        To:        Julian Satran/Haifa/IBM@IBMIL
        cc:        
        Subject:        Re: iSCSI - decimal coded binary strings - a proposed resolution

       


>>>>> "Julian" == Julian Satran <Julian_Satran@il.ibm.com> writes:

Julian> Paul, I was asking if it would acceptable to say the maximum
Julian> acceptable value (allowed value) will be limiting element
Julian> (not the actual).

Oops.  I misread your message, my apologies.

Yes, that would be great.  Thanks!

    paul

--=_alternative 007A5F49C2256BF7_=-- From owner-ips@ece.cmu.edu Mon Jul 15 20:00:37 2002 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA20522 for ; Mon, 15 Jul 2002 20:00:37 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id g6FNRUl10904 for ips-outgoing; Mon, 15 Jul 2002 19:27:30 -0400 (EDT) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from mailhub.lss.emc.com (xdch.emc.com [168.159.1.79]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id g6FNRSX10895 for ; Mon, 15 Jul 2002 19:27:28 -0400 (EDT) Received: from emc.com (emcmail.lss.emc.com [168.159.48.78]) by mailhub.lss.emc.com (Switch-2.2.0/Switch-2.2.0) with ESMTP id g6FNRJr08611; Mon, 15 Jul 2002 19:27:19 -0400 (EDT) Received: from mxic1.isus.emc.com ([168.159.129.100]) by emc.com (8.10.1/8.10.1) with ESMTP id g6FNRJ713360; Mon, 15 Jul 2002 19:27:19 -0400 (EDT) Received: by MXIC1 with Internet Mail Service (5.5.2653.19) id <31WAMTRK>; Mon, 15 Jul 2002 19:25:16 -0400 Message-ID: <277DD60FB639D511AC0400B0D068B71E0564C08D@CORPMX14> From: Black_David@emc.com To: vince_cavanna@agilent.com, ips@ece.cmu.edu Subject: RE: IPS security draft: SRP groups (resend) Date: Mon, 15 Jul 2002 19:25:13 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-ips@ece.cmu.edu Precedence: bulk Vince, > If we cannot prove the primality of our chosen moduli I > thought why not use moduli, such as the well known groups > from RFC 2412, whose primality has been proven. Tom Wu told > me that would not be a problem provided we found generators > other than 2 (the generator that is given in RFC 2412), > because 2 in not useful (for these moduli) in SRP (I don't > know why such is the case). Tom's already posed the required generators for the IKE groups to the list. In addition, Tero Kivinen was in the process of proving the primality of Tom's SRP primes last night. With luck we'll have a post to the list with pointers to the proof certificates soon. 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 --------------------------------------------------- From owner-ips@ece.cmu.edu Mon Jul 15 20:23:35 2002 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA20971 for ; Mon, 15 Jul 2002 20:23:35 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id g6G04Pc12822 for ips-outgoing; Mon, 15 Jul 2002 20:04:25 -0400 (EDT) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from msgbas2.cos.agilent.com (msgbas2x.cos.agilent.com [192.25.240.37]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id g6G04OX12818 for ; Mon, 15 Jul 2002 20:04:24 -0400 (EDT) Received: from msgrel1t.cos.agilent.com (msgrel1t.cos.agilent.com [130.29.152.157]) by msgbas2.cos.agilent.com (Postfix) with ESMTP id DF4FC19CE; Mon, 15 Jul 2002 18:04:23 -0600 (MDT) Received: from axcsbh6.cos.agilent.com (axcsbh6.cos.agilent.com [130.29.152.171]) by msgrel1t.cos.agilent.com (Postfix) with SMTP id B031550E; Mon, 15 Jul 2002 18:04:23 -0600 (MDT) Received: from 130.29.152.171 by axcsbh6.cos.agilent.com (InterScan E-Mail VirusWall NT); Mon, 15 Jul 2002 18:03:58 -0600 Received: by axcsbh6.cos.agilent.com with Internet Mail Service (5.5.2653.19) id <344N71K1>; Mon, 15 Jul 2002 18:03:58 -0600 Message-ID: <01A7DAF31F93D511AEE300D0B706ED9201BF49F9@axcs13.cos.agilent.com> From: vince_cavanna@agilent.com To: Black_David@emc.com Cc: vince_cavanna@agilent.com, ips@ece.cmu.edu Subject: RE: IPS security draft: SRP groups (resend) Date: Mon, 15 Jul 2002 18:03:53 -0600 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-ips@ece.cmu.edu Precedence: bulk Hi David, Sounds good, but I don't understand the motivation to use any primes other than those from IKE when we know those primes are certifiable and that a generator suitable for SRP can be easily and deterministically determined. Is there value in giving the user multiple choices for primes of a given size? Vince |-----Original Message----- |From: Black_David@emc.com [mailto:Black_David@emc.com] |Sent: Monday, July 15, 2002 4:25 PM |To: vince_cavanna@agilent.com; ips@ece.cmu.edu |Subject: RE: IPS security draft: SRP groups (resend) | | |Vince, | |> If we cannot prove the primality of our chosen moduli I |> thought why not use moduli, such as the well known groups |> from RFC 2412, whose primality has been proven. Tom Wu told |> me that would not be a problem provided we found generators |> other than 2 (the generator that is given in RFC 2412), |> because 2 in not useful (for these moduli) in SRP (I don't |> know why such is the case). | |Tom's already posed the required generators for the IKE groups |to the list. In addition, Tero Kivinen was in the process of |proving the primality of Tom's SRP primes last night. With |luck we'll have a post to the list with pointers to the proof |certificates soon. | |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 |--------------------------------------------------- | From owner-ips@ece.cmu.edu Mon Jul 15 23:34:15 2002 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA27415 for ; Mon, 15 Jul 2002 23:34:15 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id g6G2qWE21239 for ips-outgoing; Mon, 15 Jul 2002 22:52:32 -0400 (EDT) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from fw.hel.fi.ssh.com (fw.hel.fi.ssh.com [193.64.193.124]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id g6G2ZfX20342 for ; Mon, 15 Jul 2002 22:35:45 -0400 (EDT) Received: from viikuna.hel.fi.ssh.com (viikuna.hel.fi.ssh.com [10.1.0.46]) by fw.hel.fi.ssh.com (SSH-1.2) with SMTP id g6G2ZYM09002 for ; Tue, 16 Jul 2002 05:35:34 +0300 (EEST) Received: (qmail 23740 invoked from network); 16 Jul 2002 02:35:34 -0000 Received: from unknown (HELO ietf-wireless-dhcp-74-41.dyn.ietf54.wide.ad.jp) ([10.1.0.48]) (envelope-sender ) by viikuna.hel.fi.ssh.com (qmail-ldap-1.03) with SMTP for ; 16 Jul 2002 02:35:34 -0000 Received: by ietf-wireless-dhcp-74-41.dyn.ietf54.wide.ad.jp (Postfix, from userid 501) id 3A5A717E526; Tue, 16 Jul 2002 05:35:29 +0300 (EEST) To: ips@ece.cmu.edu Subject: IPS security draft: SRP groups' primality Organization: SSH Communications Security From: Markus Stenberg Date: 16 Jul 2002 05:35:28 +0300 Message-ID: Lines: 17 User-Agent: Gnus/5.0808 (Gnus v5.8.8) XEmacs/21.5 (bamboo) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: owner-ips@ece.cmu.edu Precedence: bulk After the Monday's first IPS session where there was some discussion about the primality of the SRP groups, we verified the SRP primes (768/1024/1280/1536/2048) using non-probabilistic methods. ECP certification data from Primo for each prime (and the prime we checked itself, cut-n-pasted from the IPS security draft) is available at ftp://ftp.ssh.com/pub/ietf/ecpp-certificates/ under name srpprime-N.txt and srpprime-N-primo-certificate.txt where N is bit size of the prime. (Someone please note this in the second session in case typhoon's trailing rainstorm blocks us from coming there ;->) -Markus -- Markus Stenberg of SSH Communications Security (www.ssh.com) Chief Engineer From owner-ips@ece.cmu.edu Tue Jul 16 00:28:03 2002 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA28470 for ; Tue, 16 Jul 2002 00:28:03 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id g6G3uDp24191 for ips-outgoing; Mon, 15 Jul 2002 23:56:13 -0400 (EDT) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from hclnpd.hclt.co.in ([202.54.64.7]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id g6G3uAX24185 for ; Mon, 15 Jul 2002 23:56:10 -0400 (EDT) Received: from mailnpd.hclt-ntl.co.in ([192.168.19.36]) by hclnpd.hclt.co.in with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) id 3B591C0G; Tue, 16 Jul 2002 09:25:22 +0530 Received: from npd.hcltech.com (IDENT:pamanick@pamanick.hclt-ntl.co.in [192.168.19.58]) by mailnpd.hclt-ntl.co.in (8.11.0/8.11.0) with ESMTP id g6G3jA325603; Tue, 16 Jul 2002 09:15:11 +0530 Message-ID: <3D339772.693A4956@npd.hcltech.com> Date: Tue, 16 Jul 2002 09:18:02 +0530 From: Parthi Organization: HCL Technologies X-Mailer: Mozilla 4.76 [en] (X11; U; Linux 2.4.2-2 i686) X-Accept-Language: en MIME-Version: 1.0 To: Bill Studenmund CC: ips@ece.cmu.edu Subject: Re: Question about ErrorRecoveryLevel References: Content-Type: multipart/alternative; boundary="------------69A58AEA484CAC79320BCD64" Sender: owner-ips@ece.cmu.edu Precedence: bulk --------------69A58AEA484CAC79320BCD64 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Bill Studenmund wrote: > I have a question about within-command and within-connection recovery and > ErrorRecoveryLevel. Mainly what does ErrorRecoveryLevel 1 imply. I think > the answer is that it implies either one (or both) of within-command and > within-connection recovery methods are supported. Is that correct? > > i.e. A, B, or A & B. ? A & B is correct . Error RecoveryLevel 1 implies Digest failure recovery. Digest failure recovery is consist of two recovery classes, Within-Connection recovery class and Within-Command recovery class. > > > Thus if I have within-command recovery I can operate at ErrorRecoveryLevel > 1 even w/o having within-connection recovery. > > Take care, > > Bill Thanks, Parthi -- http://san.hcltech.com --------------69A58AEA484CAC79320BCD64 Content-Type: text/html; charset=us-ascii Content-Transfer-Encoding: 7bit Bill Studenmund wrote:
I have a question about within-command and within-connection recovery and
ErrorRecoveryLevel. Mainly what does ErrorRecoveryLevel 1 imply. I think
the answer is that it implies either one (or both) of within-command and
within-connection recovery methods are supported. Is that correct?

i.e. A, B, or A & B. ?

A & B is  correct .

Error RecoveryLevel  1 implies  Digest failure recovery.

Digest failure recovery is  consist of two recovery classes, 
Within-Connection recovery class and Within-Command recovery class.
 
 

 

Thus if I have within-command recovery I can operate at ErrorRecoveryLevel
1 even w/o having within-connection recovery.

 
Take care,

Bill

Thanks,
Parthi 
-- 
http://san.hcltech.com
  --------------69A58AEA484CAC79320BCD64-- From owner-ips@ece.cmu.edu Tue Jul 16 00:30:15 2002 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA28513 for ; Tue, 16 Jul 2002 00:30:10 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id g6G47ZX24702 for ips-outgoing; Tue, 16 Jul 2002 00:07:35 -0400 (EDT) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from hclnpd.hclt.co.in ([202.54.64.7]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id g6G47XX24696 for ; Tue, 16 Jul 2002 00:07:33 -0400 (EDT) Received: from mailnpd.hclt-ntl.co.in ([192.168.19.36]) by hclnpd.hclt.co.in with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) id 3B591D1S; Tue, 16 Jul 2002 09:36:44 +0530 Received: from npd.hcltech.com (IDENT:pamanick@pamanick.hclt-ntl.co.in [192.168.19.58]) by mailnpd.hclt-ntl.co.in (8.11.0/8.11.0) with ESMTP id g6G3uZ325923; Tue, 16 Jul 2002 09:26:36 +0530 Message-ID: <3D339A1E.69E8DA5B@npd.hcltech.com> Date: Tue, 16 Jul 2002 09:29:26 +0530 From: Parthi Organization: HCL Technologies X-Mailer: Mozilla 4.76 [en] (X11; U; Linux 2.4.2-2 i686) X-Accept-Language: en MIME-Version: 1.0 To: cbm@rose.hp.com CC: Michael Morrison , iSCSI Subject: Re: iSCSI: Recovery R2T References: <1026420114.20745.187.camel@jackal.engasic.istor.com> <3D2F127E.6F21FD7@rose.hp.com> Content-Type: multipart/alternative; boundary="------------E2D841F451DD7B8D5B7B20A7" Sender: owner-ips@ece.cmu.edu Precedence: bulk --------------E2D841F451DD7B8D5B7B20A7 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Hi Michael: Initiator will send SNACK request PDU indicates for missed numbered-response. Support for SNACK is mandatory only if the supported ErrorRecovery- Level is greater than zero. The SNACK request is used to request the retransmission of numbered- responses, data, or R2T PDUs from the target. Draft says " The numbered-response(s) or R2T(s), requested by a SNACK, MUST be delivered as exact replicas of the ones the initiator missed and MUST include all its flags. However, the fields ExpCmdSN, MaxCmdSN and Exp- DataSN MUST carry the current values. The numbered Data-In PDUs, requested by a SNACK with a RunLength dif- ferent from 0, have to be delivered as exact replicas of the ones the initiator missed and MUST include all its flags. However, the fields ExpCmdSN and MaxCmdSN MUST carry the current values. Data-In PDUs requested with RunLength 0 (meaning all PDUs after this number) may be different from the ones originally sent, in order to reflect changes in MaxRecvPDULength. Any SNACK that requests a numbered-response, Data, or R2T that was not sent by the target MUST be rejected with a reason code of "Protocol error". " thanks, parthi "Mallikarjun C." wrote: > Michael, > > It appears to me that we need to define the term `recovery R2T' - > the lack of which David Black also pointed out earlier. > > Here's what I propose we should define it as: > > Recovery R2T: It is an R2T generated by a target upon detecting > the loss of one or more Data-Out PDUs through one of the following means > - a digest error, a sequence error, or a sequence timeout. A recovery > R2T carries the next unused R2TSN, but requests part of or the entire > data > burst that an earlier R2T (with a lower R2TSN) had already requested. > > I believe the MUST/SHOULD/MAY language contained in Section 6 already > defines the expectations on the usage scope of recovery R2T. > > -- > Mallikarjun > > Mallikarjun Chadalapaka > Networked Storage Architecture > Network Storage Solutions > MS 5668 Hewlett-Packard, Roseville. > cbm@rose.hp.com > > > Michael Morrison wrote: > > > > > > > > If an initiator sends multiple Data-Out in response to an R2T, and one > > of the Data-Out in the > > sequence has a data digest error, can the recovery R2T solicit only > > the missing data, or must > > it solicit the whole sequence? I can't find anything in the draft > > that defines what the contents > > of a recovery R2T MUST/SHOULD/MAY contain. > > > > Thanks > > Michael Morrison > > ISTOR Networks > > 7585 Irvine Center Dr. Ste 250 > > Irvine Ca. 92618 > > PGP Key: 74C30155 -- http://san.hcltech.com --------------E2D841F451DD7B8D5B7B20A7 Content-Type: text/html; charset=us-ascii Content-Transfer-Encoding: 7bit Hi Michael:

   Initiator will send SNACK request PDU indicates for missed numbered-response.

   Support for SNACK is mandatory only if the supported ErrorRecovery-
Level is greater than zero.

   The SNACK request is used to request the retransmission of numbered-
responses, data, or R2T PDUs from the target.

Draft says "

    The numbered-response(s) or R2T(s), requested by a SNACK, MUST be
delivered as exact replicas of the ones the initiator missed and MUST
include all its flags. However, the fields ExpCmdSN, MaxCmdSN and Exp-
DataSN MUST carry the current values.

The numbered Data-In PDUs, requested by a SNACK with a RunLength dif-
ferent from 0, have to be delivered as exact replicas of the ones the
initiator missed and MUST include all its flags. However, the fields
ExpCmdSN and MaxCmdSN MUST carry the current values.  Data-In PDUs
requested with RunLength 0 (meaning all PDUs after this number) may be
different from the ones originally sent, in order to reflect changes
in MaxRecvPDULength.

Any SNACK that requests a numbered-response, Data, or R2T that was not
sent by the target MUST be rejected with a reason code of "Protocol
error". "
 

thanks,
parthi

"Mallikarjun C." wrote:

Michael,

It appears to me that we need to define the term `recovery R2T' -
the lack of which David Black also pointed out earlier.

Here's what I propose we should define it as:

Recovery R2T: It is an R2T generated by a target upon detecting
the loss of one or more Data-Out PDUs through one of the following means
- a digest error, a sequence error, or a sequence timeout.  A recovery
R2T carries the next unused R2TSN, but requests part of or the entire
data
burst that an earlier R2T (with a lower R2TSN) had already requested.

I believe the MUST/SHOULD/MAY language contained in Section 6 already
defines the expectations on the usage scope of recovery R2T.


 
 
--
Mallikarjun

Mallikarjun Chadalapaka
Networked Storage Architecture
Network Storage Solutions
MS 5668 Hewlett-Packard, Roseville.
cbm@rose.hp.com

> Michael Morrison wrote:
>
>
>
> If an initiator sends multiple Data-Out in response to an R2T, and one
> of the Data-Out in the
> sequence has a data digest error, can the recovery R2T solicit only
> the missing data, or must
> it solicit the whole sequence?   I can't find anything in the draft
> that defines what the contents
> of a recovery R2T MUST/SHOULD/MAY contain.
>
> Thanks
> Michael Morrison
> ISTOR Networks
> 7585 Irvine Center Dr. Ste 250
> Irvine Ca. 92618
> PGP Key: 74C30155

-- 
http://san.hcltech.com
  --------------E2D841F451DD7B8D5B7B20A7-- From owner-ips@ece.cmu.edu Tue Jul 16 05:48:56 2002 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA15369 for ; Tue, 16 Jul 2002 05:48:55 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id g6G91pA18658 for ips-outgoing; Tue, 16 Jul 2002 05:01:51 -0400 (EDT) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from d12lmsgate-3.de.ibm.com (d12lmsgate-3.de.ibm.com [195.212.91.201]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id g6G91nX18653 for ; Tue, 16 Jul 2002 05:01:49 -0400 (EDT) Received: from d12relay01.de.ibm.com (d12relay01.de.ibm.com [9.165.215.22]) by d12lmsgate-3.de.ibm.com (8.12.3/8.12.3) with ESMTP id g6G91g7p034414 for ; Tue, 16 Jul 2002 11:01:42 +0200 Received: from d10hubm1.telaviv.ibm.com (d10ml001.telaviv.ibm.com [9.148.216.55]) by d12relay01.de.ibm.com (8.11.1m3/NCO/VER6.2) with ESMTP id g6G91gj13736 for ; Tue, 16 Jul 2002 11:01:42 +0200 To: ips@ece.cmu.edu MIME-Version: 1.0 Subject: iSCSI - getting close to 15 X-Mailer: Lotus Notes Release 5.0.9 November 16, 2001 From: "Julian Satran" Message-ID: Date: Tue, 16 Jul 2002 12:01:39 +0300 X-MIMETrack: Serialize by Router on D10ML001/10/M/IBM(Release 5.0.9a |January 7, 2002) at 16/07/2002 12:01:42, Serialize complete at 16/07/2002 12:01:42 Content-Type: multipart/alternative; boundary="=_alternative 0030C46DC2256BF8_=" Sender: owner-ips@ece.cmu.edu Precedence: bulk This is a multipart message in MIME format. --=_alternative 0030C46DC2256BF8_= Content-Type: text/plain; charset="us-ascii" Dear colleagues, I have updated the issue list and I assume that all that the list has is correct and the issues are fixed (or on the way to where mentioned). Please speak-up if not. I will appreciate if you do it now - before draft 15 goes into last call. The 2 documents to follow are: http://www.haifa.il.ibm.com/satran/ips/iSCSI-WG-Last-Call-Issues-And-Resolution.txt and http://www.haifa.il.ibm.com/satran/ips/draft-ietf-ips-iscsi-15-working.pdf And a kind reminder - please do not raise issues closed in the past unless you think that you have new arguments. Julo --=_alternative 0030C46DC2256BF8_= Content-Type: text/html; charset="us-ascii"
Dear colleagues,

I have updated the issue list and I assume that all that the list has is correct and the issues are fixed (or on the way to where mentioned).
Please speak-up if not. I will appreciate if you do it now - before draft 15 goes into last call.

The 2 documents to follow are:

http://www.haifa.il.ibm.com/satran/ips/iSCSI-WG-Last-Call-Issues-And-Resolution.txt

and

http://www.haifa.il.ibm.com/satran/ips/draft-ietf-ips-iscsi-15-working.pdf

And a kind reminder - please do not raise issues closed in the past unless you think that you have new
arguments.

Julo --=_alternative 0030C46DC2256BF8_=-- From owner-ips@ece.cmu.edu Tue Jul 16 05:49:03 2002 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA15382 for ; Tue, 16 Jul 2002 05:49:02 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id g6G9L4319443 for ips-outgoing; Tue, 16 Jul 2002 05:21:04 -0400 (EDT) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from mxic2.corp.emc.com (mxic2.us.dg.com [128.221.31.40]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id g6G9L3X19439 for ; Tue, 16 Jul 2002 05:21:03 -0400 (EDT) Received: by mxic2.corp.emc.com with Internet Mail Service (5.5.2653.19) id <30HRVQ0T>; Tue, 16 Jul 2002 05:21:00 -0400 Message-ID: <277DD60FB639D511AC0400B0D068B71E0606AEBC@CORPMX14> From: Black_David@emc.com To: svaddepuri@sanavigator.com Cc: ips@ece.cmu.edu Subject: RE: Regarding Counter64 in iSCSI MIB draft-ietf-ips-iscsi-mib-05. txt Date: Tue, 16 Jul 2002 05:18:53 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-ips@ece.cmu.edu Precedence: bulk Yes, 32 bit counters are needed for at least the 32 LSBs of each 64 bit counter, and providing a pair to cover all 64 bits would be a good thing. I presume the MIB authors will add this accordingly. 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 --------------------------------------------------- > iSCSI MIB has two Counter64 counters (iscsiSsnTxDataOctets, > iscsiSsnRxDataOctets) and the MIB document (section 4) > suggests that SNMPv1 > Agents could drop support for such counters. I was informed > that IPS working > group made a decision to support SNMPv1 agents by providing > two Counter32 > MIB Variables for each Counter64 MIB variable. > > Transmitted Data Octets and Received Data Octets are very important > statistics information and it would be useful if SNMPv1 > agents could provide > this information. > > Thanks, > Siva > From owner-ips@ece.cmu.edu Tue Jul 16 13:23:36 2002 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA24787 for ; Tue, 16 Jul 2002 13:23:36 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id g6GGY9u15029 for ips-outgoing; Tue, 16 Jul 2002 12:34:09 -0400 (EDT) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from mail1irv.inside.istor.com (host28.istor.com [66.134.214.28]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id g6GGY3X15019 for ; Tue, 16 Jul 2002 12:34:07 -0400 (EDT) Subject: Re: iSCSI: Recovery R2T From: Michael Morrison To: Parthi Cc: cbm@rose.hp.com, iSCSI In-Reply-To: <3D339A1E.69E8DA5B@npd.hcltech.com> References: <1026420114.20745.187.camel@jackal.engasic.istor.com> <3D2F127E.6F21FD7@rose.hp.com> <3D339A1E.69E8DA5B@npd.hcltech.com> Content-Type: multipart/alternative; boundary="=-zmcQCYIHfuRniE3XCUCN" X-Mailer: Ximian Evolution 1.0.8 Date: 16 Jul 2002 09:31:05 -0700 Message-Id: <1026837065.20744.542.camel@jackal.engasic.istor.com> Mime-Version: 1.0 Sender: owner-ips@ece.cmu.edu Precedence: bulk --=-zmcQCYIHfuRniE3XCUCN Content-Type: text/plain Content-Transfer-Encoding: 7bit Parthi, Thanks for your response, we are talking about two different things. If the initiator detects a hole in the R2TSN, it can request the R2T be resent by sending SNACK. If the target detects a hole in the DataSN of Data-out PDU, it can send a Recovery R2T to re-solicit the missing data. The contents of a recovery R2T are not defined in the draft. Mallikarjun provided a possible definition. Mike On Mon, 2002-07-15 at 20:59, Parthi wrote: Hi Michael: Initiator will send SNACK request PDU indicates for missed numbered-response. Support for SNACK is mandatory only if the supported ErrorRecovery- Level is greater than zero. The SNACK request is used to request the retransmission of numbered- responses, data, or R2T PDUs from the target. Draft says " The numbered-response(s) or R2T(s), requested by a SNACK, MUST be delivered as exact replicas of the ones the initiator missed and MUST include all its flags. However, the fields ExpCmdSN, MaxCmdSN and Exp- DataSN MUST carry the current values. The numbered Data-In PDUs, requested by a SNACK with a RunLength dif- ferent from 0, have to be delivered as exact replicas of the ones the initiator missed and MUST include all its flags. However, the fields ExpCmdSN and MaxCmdSN MUST carry the current values. Data-In PDUs requested with RunLength 0 (meaning all PDUs after this number) may be different from the ones originally sent, in order to reflect changes in MaxRecvPDULength. Any SNACK that requests a numbered-response, Data, or R2T that was not sent by the target MUST be rejected with a reason code of "Protocol error". " thanks, parthi "Mallikarjun C." wrote: Michael, It appears to me that we need to define the term `recovery R2T' - the lack of which David Black also pointed out earlier. Here's what I propose we should define it as: Recovery R2T: It is an R2T generated by a target upon detecting the loss of one or more Data-Out PDUs through one of the following means - a digest error, a sequence error, or a sequence timeout. A recovery R2T carries the next unused R2TSN, but requests part of or the entire data burst that an earlier R2T (with a lower R2TSN) had already requested. I believe the MUST/SHOULD/MAY language contained in Section 6 already defines the expectations on the usage scope of recovery R2T. -- Mallikarjun Mallikarjun Chadalapaka Networked Storage Architecture Network Storage Solutions MS 5668 Hewlett-Packard, Roseville. cbm@rose.hp.com > Michael Morrison wrote: > > > > If an initiator sends multiple Data-Out in response to an R2T, and one > of the Data-Out in the > sequence has a data digest error, can the recovery R2T solicit only > the missing data, or must > it solicit the whole sequence? I can't find anything in the draft > that defines what the contents > of a recovery R2T MUST/SHOULD/MAY contain. > > Thanks > Michael Morrison > ISTOR Networks > 7585 Irvine Center Dr. Ste 250 > Irvine Ca. 92618 > PGP Key: 74C30155 -- http://san.hcltech.com Michael Morrison ISTOR Networks 7585 Irvine Center Dr. Ste 250 Irvine Ca. 92618 PGP Key: 74C30155 --=-zmcQCYIHfuRniE3XCUCN Content-Type: text/html; charset=utf-8 Parthi,

Thanks for your response,

we are talking about two different things. 
If the initiator detects a hole in the R2TSN, it can request the R2T be resent by sending SNACK.

If the target detects a hole in the DataSN of Data-out PDU, it can send a Recovery R2T to re-solicit the missing data.

The contents of a recovery R2T are not defined in the draft.  Mallikarjun provided a possible definition.

Mike


On Mon, 2002-07-15 at 20:59, Parthi wrote:
Hi Michael:

   Initiator will send SNACK request PDU indicates for missed numbered-response.

   Support for SNACK is mandatory only if the supported ErrorRecovery-
Level is greater than zero.

   The SNACK request is used to request the retransmission of numbered-
responses, data, or R2T PDUs from the target.

Draft says "

    The numbered-response(s) or R2T(s), requested by a SNACK, MUST be
delivered as exact replicas of the ones the initiator missed and MUST
include all its flags. However, the fields ExpCmdSN, MaxCmdSN and Exp-
DataSN MUST carry the current values.

The numbered Data-In PDUs, requested by a SNACK with a RunLength dif-
ferent from 0, have to be delivered as exact replicas of the ones the
initiator missed and MUST include all its flags. However, the fields
ExpCmdSN and MaxCmdSN MUST carry the current values.  Data-In PDUs
requested with RunLength 0 (meaning all PDUs after this number) may be
different from the ones originally sent, in order to reflect changes
in MaxRecvPDULength.

Any SNACK that requests a numbered-response, Data, or R2T that was not
sent by the target MUST be rejected with a reason code of "Protocol
error". "
 

thanks,
parthi

"Mallikarjun C." wrote:
Michael,

It appears to me that we need to define the term `recovery R2T' -
the lack of which David Black also pointed out earlier.

Here's what I propose we should define it as:

Recovery R2T: It is an R2T generated by a target upon detecting
the loss of one or more Data-Out PDUs through one of the following means
- a digest error, a sequence error, or a sequence timeout.  A recovery
R2T carries the next unused R2TSN, but requests part of or the entire
data
burst that an earlier R2T (with a lower R2TSN) had already requested.

I believe the MUST/SHOULD/MAY language contained in Section 6 already
defines the expectations on the usage scope of recovery R2T.
 
 
--
Mallikarjun

Mallikarjun Chadalapaka
Networked Storage Architecture
Network Storage Solutions
MS 5668 Hewlett-Packard, Roseville.
cbm@rose.hp.com

> Michael Morrison wrote:
>
>
>
> If an initiator sends multiple Data-Out in response to an R2T, and one
> of the Data-Out in the
> sequence has a data digest error, can the recovery R2T solicit only
> the missing data, or must
> it solicit the whole sequence?   I can't find anything in the draft
> that defines what the contents
> of a recovery R2T MUST/SHOULD/MAY contain.
>
> Thanks
> Michael Morrison
> ISTOR Networks
> 7585 Irvine Center Dr. Ste 250
> Irvine Ca. 92618
> PGP Key: 74C30155 
-- 
http://san.hcltech.com
Michael Morrison
ISTOR Networks
7585 Irvine Center Dr. Ste 250
Irvine Ca. 92618
PGP Key: 74C30155
--=-zmcQCYIHfuRniE3XCUCN-- From owner-ips@ece.cmu.edu Tue Jul 16 13:58:35 2002 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA25510 for ; Tue, 16 Jul 2002 13:58:34 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id g6GHH1T18001 for ips-outgoing; Tue, 16 Jul 2002 13:17:01 -0400 (EDT) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from cisco.com (london.cisco.com [64.103.110.73]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id g6GHGvX17991 for ; Tue, 16 Jul 2002 13:16:57 -0400 (EDT) Received: from WDEY-W2K3.cisco.com (ams-clip-equant-dhcp-22.cisco.com [10.61.124.23]) by cisco.com (8.8.8+Sun/8.8.8) with ESMTP id SAA19794 for ; Tue, 16 Jul 2002 18:16:43 +0100 (BST) Message-Id: <4.3.2.7.2.20020716191620.03dd87a8@amsterdam.cisco.com> X-Sender: wdey@amsterdam.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Tue, 16 Jul 2002 19:16:28 +0200 To: ips@ece.cmu.edu From: Walter Dey Subject: remove Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-ips@ece.cmu.edu Precedence: bulk Walter Dey Senior Consultant, Ph.D. EMEA Enterprise Consulting Cisco Systems Morgenstr. 129 CH-3018 Bern, Switzerland wdey@cisco.com +41 79 301 8437 (mobile) +41 31 998 5053 (office) From owner-ips@ece.cmu.edu Tue Jul 16 15:29:45 2002 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA27792 for ; Tue, 16 Jul 2002 15:29:45 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id g6GIfST24487 for ips-outgoing; Tue, 16 Jul 2002 14:41:28 -0400 (EDT) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from lion.ninthwonder.com (lion.ninthwonder.com [151.199.66.147]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id g6GIfOX24474 for ; Tue, 16 Jul 2002 14:41:25 -0400 (EDT) Received: by lion.ninthwonder.com (Postfix, from userid 1021) id 696493070B; Tue, 16 Jul 2002 14:41:24 -0400 (EDT) Date: Tue, 16 Jul 2002 11:38:24 -0700 (PDT) From: Bill Studenmund X-X-Sender: To: Parthi Cc: Subject: Re: Question about ErrorRecoveryLevel In-Reply-To: <3D339772.693A4956@npd.hcltech.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ips@ece.cmu.edu Precedence: bulk On Tue, 16 Jul 2002, Parthi wrote: > Bill Studenmund wrote: > > > I have a question about within-command and within-connection recovery and > > ErrorRecoveryLevel. Mainly what does ErrorRecoveryLevel 1 imply. I think > > the answer is that it implies either one (or both) of within-command and > > within-connection recovery methods are supported. Is that correct? > > > > i.e. A, B, or A & B. ? > > A & B is correct . > > Error RecoveryLevel 1 implies Digest failure recovery. > > Digest failure recovery is consist of two recovery classes, > Within-Connection recovery class and Within-Command recovery class. Well, besides the grammar error you're quoting from the spec, that quote doesn't answer the question. That text essentially gave rise to my question. :-) Every where within-command and within-connection recovery is discussed, each of them is described as optional. The quote above doesn't say that level 1 MUST consist of both within-connection and within-command recovery. Take care, Bill From owner-ips@ece.cmu.edu Tue Jul 16 18:32:40 2002 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA01483 for ; Tue, 16 Jul 2002 18:32:39 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id g6GM4K408380 for ips-outgoing; Tue, 16 Jul 2002 18:04:20 -0400 (EDT) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from atlrel8.hp.com (atlrel8.hp.com [156.153.255.206]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id g6GM4JX08376 for ; Tue, 16 Jul 2002 18:04:19 -0400 (EDT) Received: from core.rose.hp.com (core.rose.hp.com [15.43.208.100]) by atlrel8.hp.com (Postfix) with ESMTP id 14520A002CD; Tue, 16 Jul 2002 18:04:18 -0400 (EDT) Received: from swathi (swathi.rose.hp.com [15.43.213.237]) by core.rose.hp.com with SMTP (8.9.3 (PHNE_22672)/8.8.6 SMKit7.02) id PAA20757; Tue, 16 Jul 2002 15:06:08 -0700 (PDT) Message-ID: <005a01c22d14$ba0d60f0$edd52b0f@rose.hp.com> From: "Mallikarjun C." To: "Bill Studenmund" , "Parthi" Cc: References: Subject: Re: iSCSI: Question about ErrorRecoveryLevel Date: Tue, 16 Jul 2002 15:04:15 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2600.0000 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 Sender: owner-ips@ece.cmu.edu Precedence: bulk Content-Transfer-Encoding: 7bit > Every where within-command and within-connection recovery is discussed, > each of them is described as optional. The quote above doesn't say that > level 1 MUST consist of both within-connection and within-command > recovery. [ The error in grammar is already fixed in the working version. ] The reason MUST language was not used is because the text in question is defining the terminology, but is not phrased in such a way as to place requirements on implementations. It is similar to several terminology descriptions in chapter 2. My intent when I wrote that text was - because the negotiation of the ErrorRecoveryLevel follows the regular negotiation rules (i.e. don't originate a proposal that you cannot support, and the result function is "minimum"), no additional MUST/SHOULD/MAY language is necessary. But if you recommend explicit text, I suggest we add the following at the end of the last para of text in 5.13 - When a defined value of ErrorRecoveryLevel is proposed by an originator in a text negotiation, the originator MUST support the functionality defined for the ErrorRecoveryLevel or functionality corresponding to any defined value numerically less than the proposed. When a defined value of ErrorRecoveryLevel is returned by a responder in a text negotiation, the responder MUST support the functionality corresponding to the ErrorRecoveryLevel it is accepting. Thanks. -- Mallikarjun Mallikarjun Chadalapaka Networked Storage Architecture Network Storage Solutions Hewlett-Packard MS 5668 Roseville CA 95747 cbm@rose.hp.com ----- Original Message ----- From: "Bill Studenmund" To: "Parthi" Cc: Sent: Tuesday, July 16, 2002 11:38 AM Subject: Re: Question about ErrorRecoveryLevel > On Tue, 16 Jul 2002, Parthi wrote: > > > Bill Studenmund wrote: > > > > > I have a question about within-command and within-connection recovery and > > > ErrorRecoveryLevel. Mainly what does ErrorRecoveryLevel 1 imply. I think > > > the answer is that it implies either one (or both) of within-command and > > > within-connection recovery methods are supported. Is that correct? > > > > > > i.e. A, B, or A & B. ? > > > > A & B is correct . > > > > Error RecoveryLevel 1 implies Digest failure recovery. > > > > Digest failure recovery is consist of two recovery classes, > > Within-Connection recovery class and Within-Command recovery class. > > Well, besides the grammar error you're quoting from the spec, that quote > doesn't answer the question. That text essentially gave rise to my > question. :-) > > Every where within-command and within-connection recovery is discussed, > each of them is described as optional. The quote above doesn't say that > level 1 MUST consist of both within-connection and within-command > recovery. > > Take care, > > Bill > > From owner-ips@ece.cmu.edu Tue Jul 16 18:36:24 2002 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA01561 for ; Tue, 16 Jul 2002 18:36:24 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id g6GLmiI07474 for ips-outgoing; Tue, 16 Jul 2002 17:48:44 -0400 (EDT) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from palrel10.hp.com (palrel10.hp.com [156.153.255.245]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id g6GLmeX07468 for ; Tue, 16 Jul 2002 17:48:41 -0400 (EDT) Received: from xparelay2.corp.hp.com (xparelay2.corp.hp.com [15.58.137.112]) by palrel10.hp.com (Postfix) with ESMTP id 2B398C0019D for ; Tue, 16 Jul 2002 14:48:40 -0700 (PDT) Received: from xpabh4.corp.hp.com (xpabh4.corp.hp.com [15.58.136.1]) by xparelay2.corp.hp.com (Postfix) with ESMTP id 101C59B for ; Tue, 16 Jul 2002 14:48:40 -0700 (PDT) Received: by xpabh4.corp.hp.com with Internet Mail Service (5.5.2655.55) id <3Z3HRWGS>; Tue, 16 Jul 2002 14:48:39 -0700 Message-ID: <6BD67FFB937FD411A04F00D0B74FE87805CCF6D1@xrose06.rose.hp.com> From: "KRUEGER,MARJORIE (HP-Roseville,ex1)" To: "Ips Reflector (E-mail)" Subject: iSCSI: v15 issue: iqn. name format inconsistencies Date: Tue, 16 Jul 2002 14:44:37 -0700 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2655.55) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C22D11.FB7CF6C0" Sender: owner-ips@ece.cmu.edu Precedence: bulk This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_001_01C22D11.FB7CF6C0 Content-Type: text/plain; charset="iso-8859-1" There is currently an inconsistency in the way iSCSI "iqn."-formatted names are illustrated and described between the iSCSI protocol document and the iSCSI Naming and Discovery document. In particular, the separator character between the reversed-domain name and the rest of the string is defined to be "." but some examples in the N&D document describe it as ":". I remember discussion (among the N&D team) that this separator should be ":" in order to distinguish the reversed domain name from the rest of the string, but this got lost somewhere along the line. If there are no objections to changing this in the main draft, this translates into changes for both the iSCSI main draft and the N&D draft in cleaning up the examples and making sure they are consistent (some use "." and some use ":"). Here are the changes I recommend to the main draft: In section 2.2.6.3 The iSCSI qualified name string consists of: - The string "iqn." - A date code, in yyyy-mm format. 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. This date code uses the Gregorian calendar. All four digits in the year must be present. Both digits of the month must be present, with January == "01" and December == "12". The dash must be included. - A dot ".". - The reversed domain name of the naming authority (person or organization) creating this iSCSI name. - A colon ":". - Any string, within the character set and length boundaries, that the owner of the domain name deems appropriate. This may contain product types, serial numbers, host identifiers, soft- ware keys, or anything else that makes sense to uniquely iden- tify the initiator or target. Everything after ":", can be assigned as desired by the owner of the domain name. It is the responsibility of the entity that is the naming authority to ensure that the iSCSI names it assigns are world wide unique. For example, "ACME Storage Arrays, Inc.", might own the domain name "acme.com". The following are examples of iSCSI qualified names that might be generated by "ACME Storage Arrays, Inc." Organization Naming String defined by Type Date Auth "acme.com" naming authority +--++-----+ +------+ +--------------------------------+ | || | | | | | iqn.2001-04.com.acme:storage.diskarrays-sn-a8675309 iqn.2001-04.com.acme:server.megafast900.i95874 In section 11.4 TargetName Examples: TargetName=iqn.1993-11.com.diskvendor:diskarrays.sn.45678 In section 11.5 InitiatorName Examples: InitiatorName=iqn.1992-04.com.osvendor:plan9.cdrom.12345 InitiatorName=iqn.2001-02.com.ssp:users.customer235.host90 In appendix C In the first example, the initiator and target authenticate each other via Kerberos: I-> Login (CSG,NSG=0,1 T=1) InitiatorName=iqn.1999-07.com.os:hostid.77 TargetName=iqn.1999-07.com.acme:diskarray.sn.88 AuthMethod=KRB5,SRP,None etc - all these Login examples that contain iSCSI names need to be fixed. In appendix D Target sends a text response that contains: TargetName=iqn.1993-11.com.acme:diskarray.sn.8675309 etc - all TargetName examples need to be fixed. Several examples in the Naming and Discovery draft need to be fixed - I'll address that in a separate email. Marjorie Krueger Networked Storage Architecture Networked Storage Solutions Hewlett-Packard ------_=_NextPart_001_01C22D11.FB7CF6C0 Content-Type: text/html; charset="iso-8859-1"

There is currently an inconsistency in the way iSCSI "iqn."-formatted names are illustrated and described between the iSCSI protocol document and the iSCSI Naming and Discovery document.  In particular, the separator character between the reversed-domain name and the rest of the string is defined to be "." but some examples in the N&D document describe it as ":".

I remember discussion (among the N&D team) that this separator should be ":" in order to distinguish the reversed domain name from the rest of the string, but this got lost somewhere along the line.  If there are no objections to changing this in the main draft, this translates into changes for both the iSCSI main draft and the N&D draft in cleaning up the examples and making sure they are consistent (some use "." and some use ":").

Here are the changes I recommend to the main draft:
In section 2.2.6.3


     The iSCSI qualified name string consists of:
       -  The string "iqn."
       -  A date code, in yyyy-mm format.  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.  This date code
          uses the Gregorian calendar.  All four digits in the year must
          be present.  Both digits of the month must be present, with
          January == "01" and December == "12".  The dash must be
          included.
       -  A dot ".".
       -  The reversed domain name of the naming authority (person or
          organization) creating this iSCSI name.
       -  A colon ":".
       -  Any string, within the character set and length boundaries,
          that the owner of the domain name deems appropriate.  This may
          contain product types, serial numbers, host identifiers, soft-
          ware keys, or anything else that makes sense to uniquely iden-
          tify the initiator or target.  Everything after "<reversed
          domain name>:", can be assigned as desired by the owner of
          the domain name.  It is the responsibility of the entity that
          is the naming authority to ensure that the iSCSI names it
          assigns are world wide unique.

     For example, "ACME Storage Arrays, Inc.", might own the domain name
     "acme.com". The following are examples of iSCSI qualified names that
     might be generated by "ACME Storage Arrays, Inc."
                   
                    Organization   
                        Naming     String defined by
          Type  Date     Auth      "acme.com" naming authority
          +--++-----+ +------+ +--------------------------------+
          |  ||     | |      | |                                |
          
          iqn.2001-04.com.acme:storage.diskarrays-sn-a8675309
          iqn.2001-04.com.acme:server.megafast900.i95874

In section 11.4 TargetName

     Examples:

       TargetName=iqn.1993-11.com.diskvendor:diskarrays.sn.45678

In section 11.5 InitiatorName

     Examples:

       InitiatorName=iqn.1992-04.com.osvendor:plan9.cdrom.12345
       InitiatorName=iqn.2001-02.com.ssp:users.customer235.host90

<Julian, make sure to delete the last example in the current text, as it's invalid>

In appendix C

     In the first example, the initiator and target authenticate each other
     via Kerberos:

       I-> Login (CSG,NSG=0,1 T=1)
           InitiatorName=iqn.1999-07.com.os:hostid.77
           TargetName=iqn.1999-07.com.acme:diskarray.sn.88
           AuthMethod=KRB5,SRP,None

etc - all these Login examples that contain iSCSI names need to be fixed.

In appendix D

     Target sends a text response that contains:

       TargetName=iqn.1993-11.com.acme:diskarray.sn.8675309

etc - all TargetName examples need to be fixed.

Several examples in the Naming and Discovery draft need to be fixed - I'll address that in a separate email.
     
Marjorie Krueger
Networked Storage Architecture
Networked Storage Solutions
Hewlett-Packard

------_=_NextPart_001_01C22D11.FB7CF6C0-- From owner-ips@ece.cmu.edu Tue Jul 16 20:47:00 2002 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA05336 for ; Tue, 16 Jul 2002 20:47:00 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id g6H081b14293 for ips-outgoing; Tue, 16 Jul 2002 20:08:01 -0400 (EDT) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from lion.ninthwonder.com (lion.ninthwonder.com [151.199.66.147]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id g6H07xX14287 for ; Tue, 16 Jul 2002 20:07:59 -0400 (EDT) Received: by lion.ninthwonder.com (Postfix, from userid 1021) id BDE9330717; Tue, 16 Jul 2002 20:07:58 -0400 (EDT) Date: Tue, 16 Jul 2002 17:04:58 -0700 (PDT) From: Bill Studenmund X-X-Sender: To: "Mallikarjun C." Cc: Parthi , Subject: Re: iSCSI: Question about ErrorRecoveryLevel In-Reply-To: <005a01c22d14$ba0d60f0$edd52b0f@rose.hp.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ips@ece.cmu.edu Precedence: bulk On Tue, 16 Jul 2002, Mallikarjun C. wrote: > > Every where within-command and within-connection recovery is discussed, > > each of them is described as optional. The quote above doesn't say that > > level 1 MUST consist of both within-connection and within-command > > recovery. > > [ The error in grammar is already fixed in the working version. ] Cool, I still haven't grabbed -15 yet. > The reason MUST language was not used is because the text in question is > defining the terminology, but is not phrased in such a way as to place requirements > on implementations. It is similar to several terminology descriptions in chapter 2. > > My intent when I wrote that text was - because the negotiation of the > ErrorRecoveryLevel follows the regular negotiation rules (i.e. don't originate > a proposal that you cannot support, and the result function is "minimum"), no > additional MUST/SHOULD/MAY language is necessary. But if you recommend > explicit text, I suggest we add the following at the end of the last para of > text in 5.13 - That though doesn't answer my question. :-) The main question is does ErrorRecoveryLevel 1 imply both within-command and within-connection support, or does it imply at least one and maybe both? If anything, the fact that ErrorRecoveryLevel 1 implies all of 0, and 2 implies all of 1 and 0, is clear in the draft now. > When a defined value of ErrorRecoveryLevel is proposed by an > originator in a text negotiation, the originator MUST support the > functionality defined for the ErrorRecoveryLevel or functionality ^^ Is this supposed to be "and"? > corresponding to any defined value numerically less than the proposed. > When a defined value of ErrorRecoveryLevel is returned by a responder > in a text negotiation, the responder MUST support the functionality > corresponding to the ErrorRecoveryLevel it is accepting. If "and" is appropriate, then shouldn't we add, "and all numerically lower levels" to the end of the paragraph? I'm happy with ErrorRecoveryLevel 1 == both within-connection and within-command recovery. I'm also happy with ErrorRecoveryLevel 1 == within-command, within-connection, or both (and ErrorRecoveryLevel 2 being both). I just think with the amount of, "optional," used in conjunction with error recovery that it's not clear which case we want. From owner-ips@ece.cmu.edu Tue Jul 16 20:48:54 2002 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA05379 for ; Tue, 16 Jul 2002 20:48:54 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id g6H0PW814958 for ips-outgoing; Tue, 16 Jul 2002 20:25:32 -0400 (EDT) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from palrel12.hp.com (palrel12.hp.com [156.153.255.237]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id g6H0PUX14954 for ; Tue, 16 Jul 2002 20:25:30 -0400 (EDT) Received: from core.rose.hp.com (core.rose.hp.com [15.43.208.100]) by palrel12.hp.com (Postfix) with ESMTP id C8E3DE0049F; Tue, 16 Jul 2002 17:25:29 -0700 (PDT) Received: from swathi (swathi.rose.hp.com [15.43.213.237]) by core.rose.hp.com with SMTP (8.9.3 (PHNE_22672)/8.8.6 SMKit7.02) id RAA07077; Tue, 16 Jul 2002 17:27:20 -0700 (PDT) Message-ID: <008001c22d28$73917710$edd52b0f@rose.hp.com> From: "Mallikarjun C." To: "Bill Studenmund" Cc: "Parthi" , References: Subject: Re: iSCSI: Question about ErrorRecoveryLevel Date: Tue, 16 Jul 2002 17:25:27 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2600.0000 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 Sender: owner-ips@ece.cmu.edu Precedence: bulk Content-Transfer-Encoding: 7bit Comments in text. -- Mallikarjun Mallikarjun Chadalapaka Networked Storage Architecture Network Storage Solutions Hewlett-Packard MS 5668 Roseville CA 95747 cbm@rose.hp.com > > The reason MUST language was not used is because the text in question is > > defining the terminology, but is not phrased in such a way as to place requirements > > on implementations. It is similar to several terminology descriptions in chapter 2. > > > > My intent when I wrote that text was - because the negotiation of the > > ErrorRecoveryLevel follows the regular negotiation rules (i.e. don't originate > > a proposal that you cannot support, and the result function is "minimum"), no > > additional MUST/SHOULD/MAY language is necessary. But if you recommend > > explicit text, I suggest we add the following at the end of the last para of > > text in 5.13 - > > That though doesn't answer my question. :-) The main question is does > ErrorRecoveryLevel 1 imply both within-command and within-connection > support, or does it imply at least one and maybe both? Both. It is clear to me by the way the terminology is defined ( note the "and" in 5.13). I thought your question had to do with implementation expectations. > > When a defined value of ErrorRecoveryLevel is proposed by an > > originator in a text negotiation, the originator MUST support the > > functionality defined for the ErrorRecoveryLevel or functionality > ^^ > Is this supposed to be "and"? Okay, "and" may be clearer (the "or" was used because only one of the levels can be picked by the reponder). > > > corresponding to any defined value numerically less than the proposed. > > When a defined value of ErrorRecoveryLevel is returned by a responder > > in a text negotiation, the responder MUST support the functionality > > corresponding to the ErrorRecoveryLevel it is accepting. > > If "and" is appropriate, then shouldn't we add, "and all numerically lower > levels" to the end of the paragraph? I don't see the need. If I'm accepting X, then I am promising to employ X in the session operation. OTOH, if I'm offering X, it means that I'm promising to settle for any Y, where 0<=Y<=X, that the other side would return in the response. IMO, the point that the functionality is hierarchical doesn't need to be made everywhere. From owner-ips@ece.cmu.edu Tue Jul 16 22:37:11 2002 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA09334 for ; Tue, 16 Jul 2002 22:37:06 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id g6H24NK18738 for ips-outgoing; Tue, 16 Jul 2002 22:04:23 -0400 (EDT) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from maho3msx2.isus.emc.com (maho3msx2.isus.emc.com [128.221.11.32]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id g6H24LX18733 for ; Tue, 16 Jul 2002 22:04:21 -0400 (EDT) Received: by MAHO3MSX2 with Internet Mail Service (5.5.2653.19) id <3ZK3YMAK>; Tue, 16 Jul 2002 22:02:09 -0400 Message-ID: <277DD60FB639D511AC0400B0D068B71E0564C0A4@CORPMX14> From: Black_David@emc.com To: Julian_Satran@il.ibm.com Cc: ips@ece.cmu.edu Subject: RE: iSCSI: Question about ErrorRecoveryLevel Date: Tue, 16 Jul 2002 22:02:03 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C22D35.F229FDB0" Sender: owner-ips@ece.cmu.edu Precedence: bulk This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_001_01C22D35.F229FDB0 Content-Type: text/plain; charset="iso-8859-1" One more clarification - in the meeting on Monday (report/results) coming to the list shortly the rough consensus in the room was: - If an implementation wants to support only one of the mechanisms required at ERL1, it's ok to negotiate ERL 0 (can't negotiate 1 because that would require both mechanisms) and then try the mechanism of interest, but the implementation MUST be prepared for the attempt to fail because the other party doesn't support it. Thanks, --David -----Original Message----- From: Julian Satran [mailto:Julian_Satran@il.ibm.com] Sent: Tuesday, July 16, 2002 9:56 PM To: Bill Studenmund Cc: Mallikarjun C.; ips@ece.cmu.edu; owner-ips@ece.cmu.edu; Parthi Subject: Re: iSCSI: Question about ErrorRecoveryLevel Bill - Yes ERL 1 implies both and at the end of the chapter the classes associated with the level are clearly stated. Julo Bill Studenmund Sent by: owner-ips@ece.cmu.edu 07/17/2002 03:04 AM To: "Mallikarjun C." cc: Parthi , Subject: Re: iSCSI: Question about ErrorRecoveryLevel On Tue, 16 Jul 2002, Mallikarjun C. wrote: > > Every where within-command and within-connection recovery is discussed, > > each of them is described as optional. The quote above doesn't say that > > level 1 MUST consist of both within-connection and within-command > > recovery. > > [ The error in grammar is already fixed in the working version. ] Cool, I still haven't grabbed -15 yet. > The reason MUST language was not used is because the text in question is > defining the terminology, but is not phrased in such a way as to place requirements > on implementations. It is similar to several terminology descriptions in chapter 2. > > My intent when I wrote that text was - because the negotiation of the > ErrorRecoveryLevel follows the regular negotiation rules (i.e. don't originate > a proposal that you cannot support, and the result function is "minimum"), no > additional MUST/SHOULD/MAY language is necessary. But if you recommend > explicit text, I suggest we add the following at the end of the last para of > text in 5.13 - That though doesn't answer my question. :-) The main question is does ErrorRecoveryLevel 1 imply both within-command and within-connection support, or does it imply at least one and maybe both? If anything, the fact that ErrorRecoveryLevel 1 implies all of 0, and 2 implies all of 1 and 0, is clear in the draft now. > When a defined value of ErrorRecoveryLevel is proposed by an > originator in a text negotiation, the originator MUST support the > functionality defined for the ErrorRecoveryLevel or functionality ^^ Is this supposed to be "and"? > corresponding to any defined value numerically less than the proposed. > When a defined value of ErrorRecoveryLevel is returned by a responder > in a text negotiation, the responder MUST support the functionality > corresponding to the ErrorRecoveryLevel it is accepting. If "and" is appropriate, then shouldn't we add, "and all numerically lower levels" to the end of the paragraph? I'm happy with ErrorRecoveryLevel 1 == both within-connection and within-command recovery. I'm also happy with ErrorRecoveryLevel 1 == within-command, within-connection, or both (and ErrorRecoveryLevel 2 being both). I just think with the amount of, "optional," used in conjunction with error recovery that it's not clear which case we want. ------_=_NextPart_001_01C22D35.F229FDB0 Content-Type: text/html; charset="iso-8859-1"
One more clarification - in the meeting on Monday (report/results)
coming to the list shortly the rough consensus in the room was:
 
- If an implementation wants to support only one of the mechanisms
    required at ERL1, it's ok to negotiate ERL 0 (can't negotiate
    1 because that would require both mechanisms) and then try
    the mechanism of interest, but the implementation MUST be prepared
    for the attempt to fail because the other party doesn't support it.
 
Thanks,
--David
-----Original Message-----
From: Julian Satran [mailto:Julian_Satran@il.ibm.com]
Sent: Tuesday, July 16, 2002 9:56 PM
To: Bill Studenmund
Cc: Mallikarjun C.; ips@ece.cmu.edu; owner-ips@ece.cmu.edu; Parthi
Subject: Re: iSCSI: Question about ErrorRecoveryLevel


Bill - Yes ERL 1 implies both and at the end of the chapter the classes associated with the level are clearly stated. Julo


Bill Studenmund <wrstuden@wasabisystems.com>
Sent by: owner-ips@ece.cmu.edu

07/17/2002 03:04 AM

       
        To:        "Mallikarjun C." <cbm@rose.hp.com>
        cc:        Parthi <pamanick@npd.hcltech.com>, <ips@ece.cmu.edu>
        Subject:        Re: iSCSI: Question about ErrorRecoveryLevel

       


On Tue, 16 Jul 2002, Mallikarjun C. wrote:

> > Every where within-command and within-connection recovery is discussed,
> > each of them is described as optional. The quote above doesn't say that
> > level 1 MUST consist of both within-connection and within-command
> > recovery.
>
> [ The error in grammar is already fixed in the working version. ]

Cool, I still haven't grabbed -15 yet.

> The reason MUST language was not used is because the text in question is
> defining the terminology, but is not phrased in such a way as to place requirements
> on implementations.  It is similar to several terminology descriptions in chapter 2.
>
> My intent when I wrote that text was - because the negotiation of the
> ErrorRecoveryLevel follows the regular negotiation rules (i.e. don't originate
> a proposal that you cannot support, and the result function is "minimum"), no
> additional MUST/SHOULD/MAY language is necessary.  But if you recommend
> explicit text, I suggest we add the following at the end of the last para of
> text in 5.13 -

That though doesn't answer my question. :-) The main question is does
ErrorRecoveryLevel 1 imply both within-command and within-connection
support, or does it imply at least one and maybe both?

If anything, the fact that ErrorRecoveryLevel 1 implies all of 0, and 2
implies all of 1 and 0, is clear in the draft now.

> When a defined value of ErrorRecoveryLevel is proposed by an
> originator in a text negotiation, the originator MUST support the
> functionality defined for the ErrorRecoveryLevel or functionality
                                                  ^^
Is this supposed to be "and"?

> corresponding to any defined value numerically less than the proposed.
> When a defined value of ErrorRecoveryLevel is returned by a responder
> in a text negotiation, the responder MUST support the functionality
> corresponding to the ErrorRecoveryLevel it is accepting.

If "and" is appropriate, then shouldn't we add, "and all numerically lower
levels" to the end of the paragraph?

I'm happy with ErrorRecoveryLevel 1 == both within-connection and
within-command recovery. I'm also happy with ErrorRecoveryLevel 1 ==
within-command, within-connection, or both (and ErrorRecoveryLevel 2 being
both). I just think with the amount of, "optional," used in conjunction
with error recovery that it's not clear which case we want.



------_=_NextPart_001_01C22D35.F229FDB0-- From owner-ips@ece.cmu.edu Tue Jul 16 22:37:34 2002 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA09369 for ; Tue, 16 Jul 2002 22:37:34 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id g6H1tse18426 for ips-outgoing; Tue, 16 Jul 2002 21:55:54 -0400 (EDT) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from d12lmsgate-2.de.ibm.com (d12lmsgate-2.de.ibm.com [195.212.91.200]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id g6H1tnX18418; Tue, 16 Jul 2002 21:55:49 -0400 (EDT) Received: from d12relay01.de.ibm.com (d12relay01.de.ibm.com [9.165.215.22]) by d12lmsgate-2.de.ibm.com (8.12.3/8.12.3) with ESMTP id g6H1tg7J035080; Wed, 17 Jul 2002 03:55:42 +0200 Received: from d10hubm1.telaviv.ibm.com (d10ml001.telaviv.ibm.com [9.148.216.55]) by d12relay01.de.ibm.com (8.11.1m3/NCO/VER6.2) with ESMTP id g6H1tYj132972; Wed, 17 Jul 2002 03:55:41 +0200 To: Bill Studenmund Cc: "Mallikarjun C." , ips@ece.cmu.edu, owner-ips@ece.cmu.edu, Parthi MIME-Version: 1.0 Subject: Re: iSCSI: Question about ErrorRecoveryLevel X-Mailer: Lotus Notes Release 5.0.9 November 16, 2001 From: "Julian Satran" Message-ID: Date: Wed, 17 Jul 2002 04:55:33 +0300 X-MIMETrack: Serialize by Router on D10ML001/10/M/IBM(Release 5.0.9a |January 7, 2002) at 17/07/2002 04:55:42, Serialize complete at 17/07/2002 04:55:42 Content-Type: multipart/alternative; boundary="=_alternative 0009C7E9C2256BF9_=" Sender: owner-ips@ece.cmu.edu Precedence: bulk This is a multipart message in MIME format. --=_alternative 0009C7E9C2256BF9_= Content-Type: text/plain; charset="us-ascii" Bill - Yes ERL 1 implies both and at the end of the chapter the classes associated with the level are clearly stated. Julo Bill Studenmund Sent by: owner-ips@ece.cmu.edu 07/17/2002 03:04 AM To: "Mallikarjun C." cc: Parthi , Subject: Re: iSCSI: Question about ErrorRecoveryLevel On Tue, 16 Jul 2002, Mallikarjun C. wrote: > > Every where within-command and within-connection recovery is discussed, > > each of them is described as optional. The quote above doesn't say that > > level 1 MUST consist of both within-connection and within-command > > recovery. > > [ The error in grammar is already fixed in the working version. ] Cool, I still haven't grabbed -15 yet. > The reason MUST language was not used is because the text in question is > defining the terminology, but is not phrased in such a way as to place requirements > on implementations. It is similar to several terminology descriptions in chapter 2. > > My intent when I wrote that text was - because the negotiation of the > ErrorRecoveryLevel follows the regular negotiation rules (i.e. don't originate > a proposal that you cannot support, and the result function is "minimum"), no > additional MUST/SHOULD/MAY language is necessary. But if you recommend > explicit text, I suggest we add the following at the end of the last para of > text in 5.13 - That though doesn't answer my question. :-) The main question is does ErrorRecoveryLevel 1 imply both within-command and within-connection support, or does it imply at least one and maybe both? If anything, the fact that ErrorRecoveryLevel 1 implies all of 0, and 2 implies all of 1 and 0, is clear in the draft now. > When a defined value of ErrorRecoveryLevel is proposed by an > originator in a text negotiation, the originator MUST support the > functionality defined for the ErrorRecoveryLevel or functionality ^^ Is this supposed to be "and"? > corresponding to any defined value numerically less than the proposed. > When a defined value of ErrorRecoveryLevel is returned by a responder > in a text negotiation, the responder MUST support the functionality > corresponding to the ErrorRecoveryLevel it is accepting. If "and" is appropriate, then shouldn't we add, "and all numerically lower levels" to the end of the paragraph? I'm happy with ErrorRecoveryLevel 1 == both within-connection and within-command recovery. I'm also happy with ErrorRecoveryLevel 1 == within-command, within-connection, or both (and ErrorRecoveryLevel 2 being both). I just think with the amount of, "optional," used in conjunction with error recovery that it's not clear which case we want. --=_alternative 0009C7E9C2256BF9_= Content-Type: text/html; charset="us-ascii"
Bill - Yes ERL 1 implies both and at the end of the chapter the classes associated with the level are clearly stated. Julo


Bill Studenmund <wrstuden@wasabisystems.com>
Sent by: owner-ips@ece.cmu.edu

07/17/2002 03:04 AM

       
        To:        "Mallikarjun C." <cbm@rose.hp.com>
        cc:        Parthi <pamanick@npd.hcltech.com>, <ips@ece.cmu.edu>
        Subject:        Re: iSCSI: Question about ErrorRecoveryLevel

       


On Tue, 16 Jul 2002, Mallikarjun C. wrote:

> > Every where within-command and within-connection recovery is discussed,
> > each of them is described as optional. The quote above doesn't say that
> > level 1 MUST consist of both within-connection and within-command
> > recovery.
>
> [ The error in grammar is already fixed in the working version. ]

Cool, I still haven't grabbed -15 yet.

> The reason MUST language was not used is because the text in question is
> defining the terminology, but is not phrased in such a way as to place requirements
> on implementations.  It is similar to several terminology descriptions in chapter 2.
>
> My intent when I wrote that text was - because the negotiation of the
> ErrorRecoveryLevel follows the regular negotiation rules (i.e. don't originate
> a proposal that you cannot support, and the result function is "minimum"), no
> additional MUST/SHOULD/MAY language is necessary.  But if you recommend
> explicit text, I suggest we add the following at the end of the last para of
> text in 5.13 -

That though doesn't answer my question. :-) The main question is does
ErrorRecoveryLevel 1 imply both within-command and within-connection
support, or does it imply at least one and maybe both?

If anything, the fact that ErrorRecoveryLevel 1 implies all of 0, and 2
implies all of 1 and 0, is clear in the draft now.

> When a defined value of ErrorRecoveryLevel is proposed by an
> originator in a text negotiation, the originator MUST support the
> functionality defined for the ErrorRecoveryLevel or functionality
                                                  ^^
Is this supposed to be "and"?

> corresponding to any defined value numerically less than the proposed.
> When a defined value of ErrorRecoveryLevel is returned by a responder
> in a text negotiation, the responder MUST support the functionality
> corresponding to the ErrorRecoveryLevel it is accepting.

If "and" is appropriate, then shouldn't we add, "and all numerically lower
levels" to the end of the paragraph?

I'm happy with ErrorRecoveryLevel 1 == both within-connection and
within-command recovery. I'm also happy with ErrorRecoveryLevel 1 ==
within-command, within-connection, or both (and ErrorRecoveryLevel 2 being
both). I just think with the amount of, "optional," used in conjunction
with error recovery that it's not clear which case we want.

--=_alternative 0009C7E9C2256BF9_=-- From owner-ips@ece.cmu.edu Tue Jul 16 22:38:02 2002 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA09406 for ; Tue, 16 Jul 2002 22:37:57 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id g6H2KHU19347 for ips-outgoing; Tue, 16 Jul 2002 22:20:17 -0400 (EDT) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from osmtp1.electric.net (osmtp2.electric.net [216.129.90.29]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id g6GMMQX09378 for ; Tue, 16 Jul 2002 18:22:26 -0400 (EDT) Received: from [133.93.79.129] (helo=EGRodriguez) by osmtp1.electric.net with asmtp (Exim 3.22 #1) id 17Uahp-00048M-04; Tue, 16 Jul 2002 15:22:08 -0700 From: "Elizabeth G. Rodriguez" To: , "'Brian Sherman/Markham/IBM'" , "'Gilles BERTILLOT'" , "'Ron Kao'" , "'fujii'" , "'Cheng, Lei'" , "'ishveen'" , "'Chhavi Garg'" , "'Johnson, Scott'" Cc: Subject: IPS: HOW TO UNSUBSCRIBE! Date: Tue, 16 Jul 2002 17:18:06 -0600 Message-ID: <001f01c22d1f$26e9ae40$814f5d85@EGRodriguez> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0020_01C22CEC.DC4F3E40" X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.3416 Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 Sender: owner-ips@ece.cmu.edu Precedence: bulk This is a multi-part message in MIME format. ------=_NextPart_000_0020_01C22CEC.DC4F3E40 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit We have been receiving numerous requests to unsubscribe. Do NOT send these requests directly to the mailing list. This is true of ANY mailing list one is subscribed to. In order to unsubscribe from the IPS mailing list, here is the information extracted from the email you received when you subscribed: If you ever want to remove yourself from this mailing list, you can send mail to with the following command in the body of your email message: unsubscribe ips or from another account, unsubscribe ips Important: You send this email to Majordomo@ece.cmu.edu, not ips@ece.cmu.edu! Elizabeth Rodriguez IPS co-chair ------=_NextPart_000_0020_01C22CEC.DC4F3E40 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

We have been receiving numerous requests to = unsubscribe.

Do NOT send these requests directly to the mailing = list.

This is true of ANY mailing list one is subscribed = to.

 

In order to unsubscribe from the IPS mailing list, = here is the information extracted from the email you received when you = subscribed:

 

If you ever want to = remove yourself from this mailing list,

you can send mail = to <Majordomo@ece.cmu.edu> with the following

command in the body = of your email message:

 

    = unsubscribe ips

 

or from another = account,

 

    = unsubscribe ips <email address>

 

Important:  You send this email to Majordomo@ece.cmu.edu, not ips@ece.cmu.edu!

 

Elizabeth Rodriguez

IPS co-chair

 

 

------=_NextPart_000_0020_01C22CEC.DC4F3E40-- From owner-ips@ece.cmu.edu Wed Jul 17 04:04:21 2002 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA09289 for ; Wed, 17 Jul 2002 04:04:20 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id g6H74Or29944 for ips-outgoing; Wed, 17 Jul 2002 03:04:24 -0400 (EDT) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from osmtp1.electric.net (osmtp2.electric.net [216.129.90.29]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id g6H74MX29939 for ; Wed, 17 Jul 2002 03:04:22 -0400 (EDT) Received: from [133.93.79.129] (helo=EGRodriguez) by osmtp1.electric.net with asmtp (Exim 3.22 #1) id 17UirF-0001X5-04; Wed, 17 Jul 2002 00:04:21 -0700 From: "Elizabeth G. Rodriguez" To: Cc: Subject: IPS-ALL: FC Mgmt MIB WG Last Call Date: Wed, 17 Jul 2002 02:01:03 -0600 Message-ID: <000001c22d68$1ab95f00$814f5d85@EGRodriguez> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0001_01C22D35.D02075A0" X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.3416 Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 Sender: owner-ips@ece.cmu.edu Precedence: bulk This is a multi-part message in MIME format. ------=_NextPart_000_0001_01C22D35.D02075A0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit All, We would like to announce IPS Working Group Last call for the Fibre Channel Management MIB. Details: Document: Fibre Channel Management MIB URL: http://www.ietf.org/internet-drafts/draft-ietf-ips-fcmgmt-mib-02.txt Last call period: 2 Weeks Submit comments no later than: Wednesday, July 31, 2002 at 5pm EST Editor: Keith McCloghrie (kzm@cisco.com) Please submit editorial comments directly to Keith, with copy to David Black ( black_david@emc.com), and Elizabeth Rodriguez( ElizabethRodriguez@ieee.org) Submit technical comments to the IPS mailing list ( ips@ece.cmu.edu) Editorial comments may be resolved directly by the editor of the document, but any technical issues must be discussed on the IPS reflector. Thanks Elizabeth Rodriguez & David Black IPS co-chairs ------=_NextPart_000_0001_01C22D35.D02075A0 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

All,

 

We would like to announce IPS Working Group Last call = for the Fibre Channel Management MIB.

 

Details:

 

Document: Fibre Channel Management = MIB

URL: http://www.ietf.org/internet-drafts/draft-ietf-ips-fcmgmt-mib-02.txt

 

Last call period: 2 Weeks

Submit comments no later than: Wednesday, July 31, 2002 at 5pm EST

 

Editor:  Keith = McCloghrie (kzm@cisco.com)

 

Please submit editorial comments directly to Keith, = with copy to David Black (black_david@emc.com), and Elizabeth Rodriguez(ElizabethRodriguez@ieee.org)=

Submit technical comments to the IPS mailing list (ips@ece.cmu.edu)

 

Editorial comments may be resolved directly by the = editor of the document, but any technical issues must be discussed on the IPS = reflector.

 

Thanks

 

Elizabeth Rodriguez & David = Black

IPS co-chairs

 

------=_NextPart_000_0001_01C22D35.D02075A0-- From owner-ips@ece.cmu.edu Wed Jul 17 04:21:58 2002 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA09711 for ; Wed, 17 Jul 2002 04:21:57 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id g6H7sRx01455 for ips-outgoing; Wed, 17 Jul 2002 03:54:27 -0400 (EDT) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from e1.ny.us.ibm.com (e1.ny.us.ibm.com [32.97.182.101]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id g6H7sQX01451 for ; Wed, 17 Jul 2002 03:54:26 -0400 (EDT) Received: from northrelay01.pok.ibm.com (northrelay01.pok.ibm.com [9.56.224.149]) by e1.ny.us.ibm.com (8.12.2/8.12.2) with ESMTP id g6H7sKg5113532; Wed, 17 Jul 2002 03:54:20 -0400 Received: from d03nm014.boulder.ibm.com (avpilot.boulder.ibm.com [9.17.203.135]) by northrelay01.pok.ibm.com (8.11.1m3/NCO/VER6.2) with ESMTP id g6H7sJD90202; Wed, 17 Jul 2002 03:54:19 -0400 X-Priority: 1 (High) Importance: Normal Subject: Re: iSCSI: v15 issue: iqn. name format inconsistencies To: "KRUEGER,MARJORIE (HP-Roseville,ex1)" Cc: "Ips Reflector (E-mail)" X-Mailer: Lotus Notes Release 5.0.7 March 21, 2001 Message-ID: From: "John Hufferd" Date: Wed, 17 Jul 2002 00:51:47 -0700 X-MIMETrack: Serialize by Router on D03NM014/03/M/IBM(Release 5.0.10 |March 22, 2002) at 07/17/2002 01:54:19 AM MIME-Version: 1.0 Content-type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ece.cmu.edu id g6H7sQX01452 Sender: owner-ips@ece.cmu.edu Precedence: bulk Content-Transfer-Encoding: 8bit Marjorie, I think it is OK to make some of the example changes you have indicated, but it is not required to always use the ":" It depends on the way your company manages their sub domain names. It is still valid to use an all dotted name. The ":" was needed since a company can hand out subdomains with names like "mother" and "mother.wonder" to different departments and therefore it would be possible for both departments to create a name like "com.ajax.mother.wonder.mydiskarray". The use of ":" permits the departments to make their names unique by placing the ":" following their subdomain portions. That is, they can use the same characters but separated with a colon as follows "com.ajax.mother:wonder.mydiskarray" and "com.ajax.mother.wonder:mydiskarray". Therefore, I do not think that all examples should include a colon. . . . John L. Hufferd Senior Technical Staff Member (STSM) IBM/SSG San Jose Ca Main Office (408) 256-0403, Tie: 276-0403, eFax: (408) 904-4688 Home Office (408) 997-6136, Cell: (408) 499-9702 Internet address: hufferd@us.ibm.com "KRUEGER,MARJORIE (HP-Roseville,ex1)" @ece.cmu.edu on 07/16/2002 02:44:37 PM Sent by: owner-ips@ece.cmu.edu To: "Ips Reflector (E-mail)" cc: Subject: iSCSI: v15 issue: iqn. name format inconsistencies There is currently an inconsistency in the way iSCSI "iqn."-formatted names are illustrated and described between the iSCSI protocol document and the iSCSI Naming and Discovery document.  In particular, the separator character between the reversed-domain name and the rest of the string is defined to be "." but some examples in the N&D document describe it as ":". I remember discussion (among the N&D team) that this separator should be ":" in order to distinguish the reversed domain name from the rest of the string, but this got lost somewhere along the line.  If there are no objections to changing this in the main draft, this translates into changes for both the iSCSI main draft and the N&D draft in cleaning up the examples and making sure they are consistent (some use "." and some use ":"). Here are the changes I recommend to the main draft: In section 2.2.6.3      The iSCSI qualified name string consists of:        -  The string "iqn."        -  A date code, in yyyy-mm format.  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.  This date code           uses the Gregorian calendar.  All four digits in the year must           be present.  Both digits of the month must be present, with           January == "01" and December == "12".  The dash must be           included.        -  A dot ".".        -  The reversed domain name of the naming authority (person or           organization) creating this iSCSI name.        -  A colon ":".        -  Any string, within the character set and length boundaries,           that the owner of the domain name deems appropriate.  This may           contain product types, serial numbers, host identifiers, soft-           ware keys, or anything else that makes sense to uniquely iden-           tify the initiator or target.  Everything after ":", can be assigned as desired by the owner of           the domain name.  It is the responsibility of the entity that           is the naming authority to ensure that the iSCSI names it           assigns are world wide unique.      For example, "ACME Storage Arrays, Inc.", might own the domain name      "acme.com". The following are examples of iSCSI qualified names that      might be generated by "ACME Storage Arrays, Inc."                     Organization                         Naming     String defined by           Type  Date     Auth      "acme.com" naming authority           +--++-----+ +------+ +--------------------------------+           |  ||     | |      | |           iqn.2001-04.com.acme:storage.diskarrays-sn-a8675309           iqn.2001-04.com.acme:server.megafast900.i95874 In section 11.4 TargetName      Examples:        TargetName=iqn.1993-11.com.diskvendor:diskarrays.sn.45678 In section 11.5 InitiatorName      Examples:        InitiatorName=iqn.1992-04.com.osvendor:plan9.cdrom.12345        InitiatorName=iqn.2001-02.com.ssp:users.customer235.host90 In appendix      In the first example, the initiator and target authenticate each other      via Kerberos:        I-> Login (CSG,NSG=0,1 T=1)            InitiatorName=iqn.1999-07.com.os:hostid.77            TargetName=iqn.1999-07.com.acme:diskarray.sn.88            AuthMethod=KRB5,SRP,None etc - all these Login examples that contain iSCSI names need to be fixed. In appendix      Target sends a text response that contains:        TargetName=iqn.1993-11.com.acme:diskarray.sn.8675309 etc - all TargetName examples need to be fixed. Several examples in the Naming and Discovery draft need to be fixed - I'll address that in a separate email. Marjorie Krueger Networked Storage Architecture Networked Storage Solutions Hewlett-Packard From owner-ips@ece.cmu.edu Wed Jul 17 04:49:37 2002 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA10197 for ; Wed, 17 Jul 2002 04:49:36 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id g6H8EP802113 for ips-outgoing; Wed, 17 Jul 2002 04:14:25 -0400 (EDT) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from d12lmsgate.de.ibm.com (d12lmsgate.de.ibm.com [195.212.91.199]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id g6H8EMX02107; Wed, 17 Jul 2002 04:14:22 -0400 (EDT) Received: from d12relay02.de.ibm.com (d12relay02.de.ibm.com [9.165.215.23]) by d12lmsgate.de.ibm.com (8.12.3/8.12.3) with ESMTP id g6H8EFNG010900; Wed, 17 Jul 2002 10:14:15 +0200 Received: from d10hubm1.telaviv.ibm.com (d10ml001.telaviv.ibm.com [9.148.216.55]) by d12relay02.de.ibm.com (8.11.1m3/NCO/VER6.2) with ESMTP id g6H8EEu107032; Wed, 17 Jul 2002 10:14:14 +0200 To: "John Hufferd" Cc: "Ips Reflector (E-mail)" , "KRUEGER,MARJORIE (HP-Roseville,ex1)" , owner-ips@ece.cmu.edu Importance: High MIME-Version: 1.0 Subject: Re: iSCSI: v15 issue: iqn. name format inconsistencies X-Mailer: Lotus Notes Release 5.0.9 November 16, 2001 From: "Julian Satran" Message-ID: Date: Wed, 17 Jul 2002 11:14:11 +0300 X-MIMETrack: Serialize by Router on D10ML001/10/M/IBM(Release 5.0.9a |January 7, 2002) at 17/07/2002 11:14:15, Serialize complete at 17/07/2002 11:14:15 Content-Type: multipart/alternative; boundary="=_alternative 002CE996C2256BF9_=" Sender: owner-ips@ece.cmu.edu Precedence: bulk This is a multipart message in MIME format. --=_alternative 002CE996C2256BF9_= Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable I am completely confused! Marjorie has included the colon as mandatory in=20 the format! Julo John Hufferd/San Jose/IBM@IBMUS Sent by: owner-ips@ece.cmu.edu 07/17/2002 10:51 AM =20 To: "KRUEGER,MARJORIE (HP-Roseville,ex1)" cc: "Ips Reflector (E-mail)" Subject: Re: iSCSI: v15 issue: iqn. name format inconsistenc= ies =20 Marjorie, I think it is OK to make some of the example changes you have indicated, but it is not required to always use the ":" It depends on the way your company manages their sub domain names. It is still valid to use an all dotted name. The ":" was needed since a company can hand out subdomains with names like "mother" and "mother.wonder" to different departments and therefore it would be possible for both departments to create a name like "com.ajax.mother.wonder.mydiskarray". The use of ":" permits the departments to make their names unique by placing the ":" following their subdomain portions. That is, they can use the same characters but separated with a colon as follows "com.ajax.mother:wonder.mydiskarray" and "com.ajax.mother.wonder:mydiskarray". Therefore, I do not think that all examples should include a colon. . . . John L. Hufferd Senior Technical Staff Member (STSM) IBM/SSG San Jose Ca Main Office (408) 256-0403, Tie: 276-0403, eFax: (408) 904-4688 Home Office (408) 997-6136, Cell: (408) 499-9702 Internet address: hufferd@us.ibm.com "KRUEGER,MARJORIE (HP-Roseville,ex1)"=20 @ece.cmu.edu on 07/16/2002 02:44:37 PM Sent by: owner-ips@ece.cmu.edu To: "Ips Reflector (E-mail)" cc: Subject: iSCSI: v15 issue: iqn. name format inconsistencies There is currently an inconsistency in the way iSCSI "iqn."-formatted names are illustrated and described between the iSCSI protocol document and the iSCSI Naming and Discovery document.=A0 In particular, the separator character between the reversed-domain name and the rest of the string is defined to be "." but some examples in the N&D document describe it as ":". I remember discussion (among the N&D team) that this separator should be ":" in order to distinguish the reversed domain name from the rest of the string, but this got lost somewhere along the line.=A0 If there are no objections to changing this in the main draft, this translates into=20 changes for both the iSCSI main draft and the N&D draft in cleaning up the examples and making sure they are consistent (some use "." and some use ":"). Here are the changes I recommend to the main draft: In section 2.2.6.3 =A0=A0=A0=A0 The iSCSI qualified name string consists of: =A0=A0=A0=A0=A0=A0 -=A0 The string "iqn." =A0=A0=A0=A0=A0=A0 -=A0 A date code, in yyyy-mm format.=A0 This date MUST = be a date =A0=A0=A0=A0=A0=A0=A0=A0=A0 during which the naming authority owned the do= main name used =A0=A0=A0=A0=A0=A0=A0=A0=A0 in this format, and SHOULD be the date on whic= h the domain =A0=A0=A0=A0=A0=A0=A0=A0=A0 name was acquired by this naming authority.=A0= This date code =A0=A0=A0=A0=A0=A0=A0=A0=A0 uses the Gregorian calendar.=A0 All four digit= s in the year must =A0=A0=A0=A0=A0=A0=A0=A0=A0 be present.=A0 Both digits of the month must b= e present, with =A0=A0=A0=A0=A0=A0=A0=A0=A0 January =3D=3D "01" and December =3D=3D "12".= =A0 The dash must be =A0=A0=A0=A0=A0=A0=A0=A0=A0 included. =A0=A0=A0=A0=A0=A0 -=A0 A dot ".". =A0=A0=A0=A0=A0=A0 -=A0 The reversed domain name of the naming authority (= person or =A0=A0=A0=A0=A0=A0=A0=A0=A0 organization) creating this iSCSI name. =A0=A0=A0=A0=A0=A0 -=A0 A colon ":". =A0=A0=A0=A0=A0=A0 -=A0 Any string, within the character set and length b= oundaries, =A0=A0=A0=A0=A0=A0=A0=A0=A0 that the owner of the domain name deems approp= riate.=A0 This may =A0=A0=A0=A0=A0=A0=A0=A0=A0 contain product types, serial numbers, host id= entifiers, soft- =A0=A0=A0=A0=A0=A0=A0=A0=A0 ware keys, or anything else that makes sense t= o uniquely iden- =A0=A0=A0=A0=A0=A0=A0=A0=A0 tify the initiator or target.=A0 Everything af= ter ":", can be assigned as desired by = the owner of =A0=A0=A0=A0=A0=A0=A0=A0=A0 the domain name.=A0 It is the responsibility o= f the entity that =A0=A0=A0=A0=A0=A0=A0=A0=A0 is the naming authority to ensure that the iSC= SI names it =A0=A0=A0=A0=A0=A0=A0=A0=A0 assigns are world wide unique. =A0=A0=A0=A0 For example, "ACME Storage Arrays, Inc.", might own the domai= n name =A0=A0=A0=A0 "acme.com". The following are examples of iSCSI qualified nam= es that =A0=A0=A0=A0 might be generated by "ACME Storage Arrays, Inc." =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 Organization =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 Nami= ng=A0=A0=A0=A0 String defined by =A0=A0=A0=A0=A0=A0=A0=A0=A0 Type=A0 Date=A0=A0=A0=A0 Auth=A0=A0=A0=A0=A0 "= acme.com" naming authority =A0=A0=A0=A0=A0=A0=A0=A0=A0 +--++-----+ +------+ +-----------------------= ---------+ =A0=A0=A0=A0=A0=A0=A0=A0=A0 |=A0 ||=A0=A0=A0=A0 | |=A0=A0=A0=A0=A0 | | =A0=A0=A0=A0=A0=A0=A0=A0=A0 iqn.2001-04.com.acme:storage.diskarrays-sn-a86= 75309 =A0=A0=A0=A0=A0=A0=A0=A0=A0 iqn.2001-04.com.acme:server.megafast900.i95874 In section 11.4 TargetName =A0=A0=A0=A0 Examples: =A0=A0=A0=A0=A0=A0 TargetName=3Diqn.1993-11.com.diskvendor:diskarrays.sn.4= 5678 In section 11.5 InitiatorName =A0=A0=A0=A0 Examples: =A0=A0=A0=A0=A0=A0 InitiatorName=3Diqn.1992-04.com.osvendor:plan9.cdrom.12= 345 =A0=A0=A0=A0=A0=A0 InitiatorName=3Diqn.2001-02.com.ssp:users.customer235.h= ost90 In appendix =A0=A0=A0=A0 In the first example, the initiator and target authenticate e= ach other =A0=A0=A0=A0 via Kerberos: =A0=A0=A0=A0=A0=A0 I-> Login (CSG,NSG=3D0,1 T=3D1) =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 InitiatorName=3Diqn.1999-07.com.os:hostid.77 =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 TargetName=3Diqn.1999-07.com.acme:diskarray= .sn.88 =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 AuthMethod=3DKRB5,SRP,None etc - all these Login examples that contain iSCSI names need to be fixed. In appendix =A0=A0=A0=A0 Target sends a text response that contains: =A0=A0=A0=A0=A0=A0 TargetName=3Diqn.1993-11.com.acme:diskarray.sn.8675309 etc - all TargetName examples need to be fixed. Several examples in the Naming and Discovery draft need to be fixed -=20 I'll address that in a separate email. Marjorie Krueger Networked Storage Architecture Networked Storage Solutions Hewlett-Packard --=_alternative 002CE996C2256BF9_= Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
I am completely confused! Marjorie h= as included the colon as mandatory in the format!

Julo


John Hufferd/San Jose/IBM@IBMUS
Sent by: owner-ips@ece.cmu.edu

07/17/2002 10:51 AM

       
        To: &nbs= p;      "KRUEGER,MARJORIE (HP-Roseville,ex1)" <= marjorie=5Fkrueger@hp.com>
        cc: &nbs= p;      "Ips Reflector (E-mail)" <ips@ece.cmu.e= du>
        Subject:=        Re: iSCSI: v15 issue: iqn. name format inconsis= tencies

       



Marjorie,
I think it is OK to make some of the example changes you have indicated,
but it is not required to always use the ":"  It depends on = the way your
company manages their sub domain names.   It is still valid to use an = all
dotted name.

The ":" was needed since a company can hand out subdomains with n= ames like
"mother" and "mother.wonder" to different departments a= nd therefore it
would be possible for both departments to create a name like
"com.ajax.mother.wonder.mydiskarray".  The use of ":&qu= ot; permits the
departments to make their names unique by placing the ":" followi= ng their
subdomain portions.  That is, they can use the same characters but
separated with a colon as follows "com.ajax.mother:wonder.mydiskarray&= quot; and
"com.ajax.mother.wonder:mydiskarray".

Therefore, I do not think that all examples should include a colon.

.
.
.
John L. Hufferd
Senior Technical Staff Member (STSM)
IBM/SSG San Jose Ca
Main Office (408) 256-0403, Tie: 276-0403,  eFax: (408) 904-4688
Home Office (408) 997-6136, Cell: (408) 499-9702
Internet address: hufferd@us.ibm.com


"KRUEGER,MARJORIE (HP-Roseville,ex1)" <marjorie=5Fkrueger@hp.c= om>@ece.cmu.edu
on 07/16/2002 02:44:37 PM

Sent by:    owner-ips@ece.cmu.edu


To:    "Ips Reflector (E-mail)" <ips@ece.cmu.edu>=
cc:
Subject:    iSCSI: v15 issue: iqn. name format inconsistencies





There is currently an inconsistency in the way iSCSI  "iqn."= -formatted
names are illustrated and described between the iSCSI protocol  docume= nt
and the iSCSI Naming and Discovery document.=A0 In particular, the  se= parator
character between the reversed-domain name and the rest of the string  = ;is
defined to be "." but some examples in the N&D document descr= ibe it as
":".

I remember discussion (among the N&D team) that this separator  sh= ould be
":" in order to distinguish the reversed domain name from the res= t of  the
string, but this got lost somewhere along the line.=A0 If there are no
objections to changing this in the main draft, this translates into changes=
for  both the iSCSI main draft and the N&D draft in cleaning up th= e
examples and  making sure they are consistent (some use "." = and some use
":").

Here are  the changes I recommend to the main draft:
In section  2.2.6.3


=A0=A0=A0=A0 The  iSCSI qualified name string consists of:
=A0=A0=A0=A0=A0=A0  -=A0 The string "iqn."
=A0=A0=A0=A0=A0=A0 -=A0 A date  code, in yyyy-mm format.=A0 This date = MUST be a  date
=A0=A0=A0=A0=A0=A0=A0=A0=A0 during which the  naming authority owned t= he domain name  used
=A0=A0=A0=A0=A0=A0=A0=A0=A0 in this format,  and SHOULD be the date on= which the  domain
=A0=A0=A0=A0=A0=A0=A0=A0=A0 name was  acquired by this naming authorit= y.=A0 This date  code
=A0=A0=A0=A0=A0=A0=A0=A0=A0 uses the  Gregorian calendar.=A0 All four = digits in the year  must
=A0=A0=A0=A0=A0=A0=A0=A0=A0 be present.=A0  Both digits of the month m= ust be present,  with
=A0=A0=A0=A0=A0=A0=A0=A0=A0 January =3D=3D "01"  and Decembe= r =3D=3D "12".=A0 The dash must  be
=A0=A0=A0=A0=A0=A0=A0=A0=A0  included.
=A0=A0=A0=A0=A0=A0 -=A0 A dot  ".".
=A0=A0=A0=A0=A0=A0 -=A0 The reversed domain name of  the naming author= ity (person  or
=A0=A0=A0=A0=A0=A0=A0=A0=A0 organization)  creating this iSCSI name. =A0=A0=A0=A0=A0=A0 -=A0 A  colon ":".
=A0=A0=A0=A0=A0=A0 -=A0 Any string, within  the character set and leng= th  boundaries,
=A0=A0=A0=A0=A0=A0=A0=A0=A0 that the  owner of the domain name deems a= ppropriate.=A0 This  may
=A0=A0=A0=A0=A0=A0=A0=A0=A0 contain= product  types, serial numbers, host identifiers,  soft-
=A0=A0=A0=A0=A0=A0=A0=A0=A0 ware keys, or  anything else that makes se= nse to uniquely  iden-
=A0=A0=A0=A0=A0=A0=A0=A0=A0 tify the  initiator or target.=A0 Everythi= ng after  "<reversed
=A0=A0=A0=A0=A0=A0=A0=A0=A0 domain  name>:", can be assigned a= s desired by the owner  of
=A0=A0=A0=A0=A0=A0=A0=A0=A0 the domain  name.=A0 It is the responsibil= ity of the entity  that
=A0=A0=A0=A0=A0=A0=A0=A0=A0 is the naming  authority to ensure that th= e iSCSI names  it
=A0=A0=A0=A0=A0=A0=A0=A0=A0 assigns are world  wide unique.

=A0=A0=A0=A0 For example, "ACME Storage Arrays,  Inc.", migh= t own the domain name
=A0=A0=A0=A0 "acme.com". The  following are examples of iSCS= I qualified names that
=A0=A0=A0=A0  might be generated by "ACME Storage Arrays,  I= nc."

=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0  Organizatio= n
=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0  = ;Naming=A0=A0=A0=A0 String defined  by
=A0=A0=A0=A0=A0=A0=A0=A0=A0 Type=A0  Date=A0=A0=A0=A0 Auth=A0=A0=A0=A0= =A0 "acme.com"  naming authority
=A0=A0=A0=A0=A0=A0=A0=A0=A0  +--++-----+ +------+  +-------------= -------------------+
=A0=A0=A0=A0=A0=A0=A0=A0=A0  |=A0 ||=A0=A0=A0=A0 | |=A0=A0=A0=A0=A0 | =  |

=A0=A0=A0=A0=A0=A0=A0=A0=A0  iqn.2001-04.com.acme:storage.diskarrays-s= n-a8675309
=A0=A0=A0=A0=A0=A0=A0=A0=A0  iqn.2001-04.com.acme:server.megafast900.i= 95874

In section 11.4 TargetName

=A0=A0=A0=A0  Examples:

=A0=A0=A0=A0=A0=A0  TargetName=3Diqn.1993-11.com.diskvendor:diskarrays= .sn.45678

In section 11.5 InitiatorName

=A0=A0=A0=A0  Examples:

=A0=A0=A0=A0=A0=A0  InitiatorName=3Diqn.1992-04.com.osvendor:plan9.cdr= om.12345
=A0=A0=A0=A0=A0=A0  InitiatorName=3Diqn.2001-02.com.ssp:users.customer= 235.host90

<Julian, make sure to delete the last example in the current  text,= as it's
invalid>

In appendix

=A0=A0=A0=A0 In the first  example, the initiator and target authentic= ate each
other
=A0=A0=A0=A0 via  Kerberos:

=A0=A0=A0=A0=A0=A0 I-> Login (CSG,NSG=3D0,1  T=3D1)
=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0  InitiatorName=3Diqn.1999-07.com.os:hos= tid.77
=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0  TargetName=3Diqn.1999-07.com.acme:disk= array.sn.88
=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0  AuthMethod=3DKRB5,SRP,None

etc - all these Login  examples that contain iSCSI names need to be fi= xed.

In appendix

=A0=A0=A0=A0 Target sends a  text response that contains:

=A0=A0=A0=A0=A0=A0  TargetName=3Diqn.1993-11.com.acme:diskarray.sn.867= 5309

etc - all TargetName examples need to be  fixed.

Several examples in the Naming and Discovery draft need to  be fixed -= I'll
address that in a separate  email.

Marjorie Krueger
Networked  Storage Architecture
Networked Storage Solutions
Hewlett-Packard

--=_alternative 002CE996C2256BF9_=-- From owner-ips@ece.cmu.edu Wed Jul 17 04:49:49 2002 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA10211 for ; Wed, 17 Jul 2002 04:49:49 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id g6H8EJk02104 for ips-outgoing; Wed, 17 Jul 2002 04:14:19 -0400 (EDT) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from d12lmsgate-2.de.ibm.com (d12lmsgate-2.de.ibm.com [195.212.91.200]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id g6H8EHX02099 for ; Wed, 17 Jul 2002 04:14:17 -0400 (EDT) Received: from d12relay02.de.ibm.com (d12relay02.de.ibm.com [9.165.215.23]) by d12lmsgate-2.de.ibm.com (8.12.3/8.12.3) with ESMTP id g6H8EB7J017394; Wed, 17 Jul 2002 10:14:11 +0200 Received: from d10hubm1.telaviv.ibm.com (d10ml001.telaviv.ibm.com [9.148.216.55]) by d12relay02.de.ibm.com (8.11.1m3/NCO/VER6.2) with ESMTP id g6H8E9u104186; Wed, 17 Jul 2002 10:14:10 +0200 To: "KRUEGER,MARJORIE (HP-Roseville,ex1)" Cc: ips@ece.cmu.edu MIME-Version: 1.0 Subject: Re: iSCSI: v15 issue: iqn. name format inconsistencies X-Mailer: Lotus Notes Release 5.0.9 November 16, 2001 From: "Julian Satran" Message-ID: Date: Wed, 17 Jul 2002 11:14:06 +0300 X-MIMETrack: Serialize by Router on D10ML001/10/M/IBM(Release 5.0.9a |January 7, 2002) at 17/07/2002 11:14:10, Serialize complete at 17/07/2002 11:14:10 Content-Type: multipart/alternative; boundary="=_alternative 002C75FEC2256BF9_=" Sender: owner-ips@ece.cmu.edu Precedence: bulk This is a multipart message in MIME format. --=_alternative 002C75FEC2256BF9_= Content-Type: text/plain; charset="us-ascii" Marjorie, Here is a differential. Please check (fast!). Julo Type "iqn." (iSCSI Qualified Name) This iSCSI name type can be used by any organization which owns a domain name. This naming format is useful when an end user or ser-vice provider wishes to assign iSCSI names for targets and/or initia-tors. To generate names of this type, the person or organization generat-ing the name must own a DNS domain name. This domain name does not have to be active, and does not have to resolve to an address; it just needs to be reserved to prevent others from generating iSCSI names using the same domain name. Because a domain name can expire, be acquired by another entity, and might be used to generate iSCSI names by both owners, the domain name must be additionally qualified by a date during which the naming authority owned the domain name. A date code is provided as part of the "iqn." format for this reason. The iSCSI qualified name string consists of: - The string "iqn.", used to distinguish these names from "eui." formatted names. - A date code, in yyyy-mm format. This date MUST be a date dur-ing which the naming authority owned the domain name used in this format, and SHOULD be the first month in which the domain name was owned by this naming authority at 00:01 GMT of the first day of the month. This date code uses the Grego-rian calendar. All four digits in the year must be present. Both digits of the month must be present, with January == "01" and December == "12". The dash must be included. - A dot ".". - The reversed domain name of the naming authority (person or organization) creating this iSCSI name. - A colon ":". - Any string, within the character set and length boundaries, that the owner of the domain name deems appropriate. This may contain product types, serial numbers, host identifiers, software keys, or anything else that makes sense to uniquely identify the initiator or target. Everything after the reversed domain name, followed by colon ":", can be assigned as desired by the owner of the domain name. It is the respon-sibility of the entity that is the naming authority to ensure that the iSCSI names it assigns are worldwide unique. For example, "ACME Storage Arrays, Inc.", might own the domain name "acme.com". The following are examples of iSCSI qualified names that might be generated by "ACME Storage Arrays, Inc." Organization Subgroup Naming Authority Naming and/or string defined by Type Date Auth "acme.com" Naming Authority +--++-----+ +------+ +--------------------------------+ | || | | | | | iqn.2001-04.com.acme:storage.diskarrays-sn-a8675309 iqn.2001-04.com.acme:storage.tape.sys1.xyz iqn.2001-04.com.acme:storage.tape.sys1.xyz "KRUEGER,MARJORIE (HP-Roseville,ex1)" Sent by: owner-ips@ece.cmu.edu 07/17/2002 12:44 AM To: "Ips Reflector (E-mail)" cc: Subject: iSCSI: v15 issue: iqn. name format inconsistencies There is currently an inconsistency in the way iSCSI "iqn."-formatted names are illustrated and described between the iSCSI protocol document and the iSCSI Naming and Discovery document. In particular, the separator character between the reversed-domain name and the rest of the string is defined to be "." but some examples in the N&D document describe it as ":". I remember discussion (among the N&D team) that this separator should be ":" in order to distinguish the reversed domain name from the rest of the string, but this got lost somewhere along the line. If there are no objections to changing this in the main draft, this translates into changes for both the iSCSI main draft and the N&D draft in cleaning up the examples and making sure they are consistent (some use "." and some use ":"). Here are the changes I recommend to the main draft: In section 2.2.6.3 The iSCSI qualified name string consists of: - The string "iqn." - A date code, in yyyy-mm format. 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. This date code uses the Gregorian calendar. All four digits in the year must be present. Both digits of the month must be present, with January == "01" and December == "12". The dash must be included. - A dot ".". - The reversed domain name of the naming authority (person or organization) creating this iSCSI name. - A colon ":". - Any string, within the character set and length boundaries, that the owner of the domain name deems appropriate. This may contain product types, serial numbers, host identifiers, soft- ware keys, or anything else that makes sense to uniquely iden- tify the initiator or target. Everything after ":", can be assigned as desired by the owner of the domain name. It is the responsibility of the entity that is the naming authority to ensure that the iSCSI names it assigns are world wide unique. For example, "ACME Storage Arrays, Inc.", might own the domain name "acme.com". The following are examples of iSCSI qualified names that might be generated by "ACME Storage Arrays, Inc." Organization Naming String defined by Type Date Auth "acme.com" naming authority +--++-----+ +------+ +--------------------------------+ | || | | | | | iqn.2001-04.com.acme:storage.diskarrays-sn-a8675309 iqn.2001-04.com.acme:server.megafast900.i95874 In section 11.4 TargetName Examples: TargetName=iqn.1993-11.com.diskvendor:diskarrays.sn.45678 In section 11.5 InitiatorName Examples: InitiatorName=iqn.1992-04.com.osvendor:plan9.cdrom.12345 InitiatorName=iqn.2001-02.com.ssp:users.customer235.host90 In appendix C In the first example, the initiator and target authenticate each other via Kerberos: I-> Login (CSG,NSG=0,1 T=1) InitiatorName=iqn.1999-07.com.os:hostid.77 TargetName=iqn.1999-07.com.acme:diskarray.sn.88 AuthMethod=KRB5,SRP,None etc - all these Login examples that contain iSCSI names need to be fixed. In appendix D Target sends a text response that contains: TargetName=iqn.1993-11.com.acme:diskarray.sn.8675309 etc - all TargetName examples need to be fixed. Several examples in the Naming and Discovery draft need to be fixed - I'll address that in a separate email. Marjorie Krueger Networked Storage Architecture Networked Storage Solutions Hewlett-Packard --=_alternative 002C75FEC2256BF9_= Content-Type: text/html; charset="us-ascii"
Marjorie,

Here is a differential.
Please check (fast!).

Julo

Type "iqn." (iSCSI Qualified Name)

This iSCSI name type can be used by any organization which owns a domain name. This naming format is useful when an end user or ser-vice provider wishes to assign iSCSI names for targets and/or initia-tors.

To generate names of this type, the person or organization generat-ing the name must own a DNS domain name. This domain name does not have to be active, and does not have to resolve to an address; it just needs to be reserved to prevent others from generating iSCSI names using the same domain name.

Because a domain name can expire, be acquired by another entity, and might be used to generate iSCSI names by both owners, the domain name must be additionally qualified by a date during which the naming authority owned the domain name. A date code is provided as part of the "iqn." format for this reason.

The iSCSI qualified name string consists of:

- The string "iqn.", used to distinguish these names from "eui." formatted names.
- A date code, in yyyy-mm format. This date MUST be a date dur-ing which the naming authority owned the domain name used in this format, and SHOULD be the first month in which the domain name was owned by this naming authority at 00:01 GMT of the first day of the month. This date code uses the Grego-rian calendar. All four digits in the year must be present. Both digits of the month must be present, with January == "01" and December == "12". The dash must be included.
- A dot ".".
- The reversed domain name of the naming authority (person or organization) creating this iSCSI name.
- A colon ":".
- Any string, within the character set and length boundaries, that the owner of the domain name deems appropriate. This may contain product types, serial numbers, host identifiers, software keys, or anything else that makes sense to uniquely identify the initiator or target. Everything after the reversed domain name, followed by colon ":", can be assigned as desired by the owner of the domain name. It is the respon-sibility of the entity that is the naming authority to ensure that the iSCSI names it assigns are worldwide unique. For example, "ACME Storage Arrays, Inc.", might own the domain name "acme.com".
 
The following are examples of iSCSI qualified names that might be
generated by "ACME Storage Arrays, Inc."
               
          Organization    Subgroup Naming Authority
              Naming      and/or string defined by
Type  Date     Auth       "acme.com" Naming Authority
+--++-----+ +------+ +--------------------------------+
|  ||     | |      | |                                |
 
iqn.2001-04.com.acme:storage.diskarrays-sn-a8675309
iqn.2001-04.com.acme:storage.tape.sys1.xyz
iqn.2001-04.com.acme:storage.tape.sys1.xyz




"KRUEGER,MARJORIE (HP-Roseville,ex1)" <marjorie_krueger@hp.com>
Sent by: owner-ips@ece.cmu.edu

07/17/2002 12:44 AM

       
        To:        "Ips Reflector (E-mail)" <ips@ece.cmu.edu>
        cc:        
        Subject:        iSCSI: v15 issue: iqn. name format inconsistencies

       


There is currently an inconsistency in the way iSCSI "iqn."-formatted names are illustrated and described between the iSCSI protocol document and the iSCSI Naming and Discovery document.  In particular, the separator character between the reversed-domain name and the rest of the string is defined to be "." but some examples in the N&D document describe it as ":".

I remember discussion (among the N&D team) that this separator should be ":" in order to distinguish the reversed domain name from the rest of the string, but this got lost somewhere along the line.  If there are no objections to changing this in the main draft, this translates into changes for both the iSCSI main draft and the N&D draft in cleaning up the examples and making sure they are consistent (some use "." and some use ":").

Here are the changes I recommend to the main draft:
In section 2.2.6.3


    The iSCSI qualified name string consists of:
      -  The string "iqn."
      -  A date code, in yyyy-mm format.  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.  This date code
         uses the Gregorian calendar.  All four digits in the year must
         be present.  Both digits of the month must be present, with
         January == "01" and December == "12".  The dash must be
         included.
      -  A dot ".".
      -  The reversed domain name of the naming authority (person or
         organization) creating this iSCSI name.
      -  A colon ":".
      -  Any string, within the character set and length boundaries,
         that the owner of the domain name deems appropriate.  This may
         contain product types, serial numbers, host identifiers, soft-
         ware keys, or anything else that makes sense to uniquely iden-
         tify the initiator or target.  Everything after "<reversed
         domain name>:", can be assigned as desired by the owner of
         the domain name.  It is the responsibility of the entity that
         is the naming authority to ensure that the iSCSI names it
         assigns are world wide unique.

    For example, "ACME Storage Arrays, Inc.", might own the domain name
    "acme.com". The following are examples of iSCSI qualified names that
    might be generated by "ACME Storage Arrays, Inc."
                 
                   Organization  
                       Naming     String defined by
         Type  Date     Auth      "acme.com" naming authority
         +--++-----+ +------+ +--------------------------------+
         |  ||     | |      | |                                |
         
         iqn.2001-04.com.acme:storage.diskarrays-sn-a8675309
         iqn.2001-04.com.acme:server.megafast900.i95874

In section 11.4 TargetName

    Examples:

      TargetName=iqn.1993-11.com.diskvendor:diskarrays.sn.45678

In section 11.5 InitiatorName

    Examples:

      InitiatorName=iqn.1992-04.com.osvendor:plan9.cdrom.12345
      InitiatorName=iqn.2001-02.com.ssp:users.customer235.host90

<Julian, make sure to delete the last example in the current text, as it's invalid>

In appendix C

    In the first example, the initiator and target authenticate each other
    via Kerberos:

      I-> Login (CSG,NSG=0,1 T=1)
          InitiatorName=iqn.1999-07.com.os:hostid.77
          TargetName=iqn.1999-07.com.acme:diskarray.sn.88
          AuthMethod=KRB5,SRP,None

etc - all these Login examples that contain iSCSI names need to be fixed.

In appendix D

    Target sends a text response that contains:

      TargetName=iqn.1993-11.com.acme:diskarray.sn.8675309

etc - all TargetName examples need to be fixed.

Several examples in the Naming and Discovery draft need to be fixed - I'll address that in a separate email.
   
Marjorie Krueger
Networked Storage Architecture
Networked Storage Solutions
Hewlett-Packard

--=_alternative 002C75FEC2256BF9_=-- From owner-ips@ece.cmu.edu Wed Jul 17 05:05:50 2002 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA10521 for ; Wed, 17 Jul 2002 05:05:49 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id g6H8epr14073 for ips-outgoing; Wed, 17 Jul 2002 04:40:51 -0400 (EDT) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from e2.ny.us.ibm.com (e2.ny.us.ibm.com [32.97.182.102]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id g6H8eoX14068; Wed, 17 Jul 2002 04:40:50 -0400 (EDT) Received: from northrelay01.pok.ibm.com (northrelay01.pok.ibm.com [9.56.224.149]) by e2.ny.us.ibm.com (8.12.2/8.12.2) with ESMTP id g6H8eie8151658; Wed, 17 Jul 2002 04:40:44 -0400 Received: from d03nm014.boulder.ibm.com (avpilot.boulder.ibm.com [9.17.203.135]) by northrelay01.pok.ibm.com (8.11.1m3/NCO/VER6.2) with ESMTP id g6H8efD143426; Wed, 17 Jul 2002 04:40:41 -0400 X-Priority: 1 (High) Importance: High Subject: Re: iSCSI: v15 issue: iqn. name format inconsistencies To: "Julian Satran" Cc: "Ips Reflector (E-mail)" , "KRUEGER,MARJORIE (HP-Roseville,ex1)" , owner-ips@ece.cmu.edu X-Mailer: Lotus Notes Release 5.0.7 March 21, 2001 Message-ID: From: "John Hufferd" Date: Wed, 17 Jul 2002 01:38:11 -0700 X-MIMETrack: Serialize by Router on D03NM014/03/M/IBM(Release 5.0.10 |March 22, 2002) at 07/17/2002 02:40:43 AM MIME-Version: 1.0 Content-type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ece.cmu.edu id g6H8eoX14069 Sender: owner-ips@ece.cmu.edu Precedence: bulk Content-Transfer-Encoding: 8bit Julian, when the ":" part was added to the spec. we included it as if it was required. The text should say (see last line): In section  2.2.6.3      The  iSCSI qualified name string consists of:         -  The string "iqn."        -  A date  code, in yyyy-mm format.  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.  This date  code           uses the  Gregorian calendar.  All four digits in the year  must           be present.   Both digits of the month must be present,  with           January == "01"  and December == "12".  The dash must  be            included.        -  A dot  ".".        -  The reversed domain name of  the naming authority (person  or           organization)  creating this iSCSI name.        -  An optional  colon ":". =============================================== Julian please add the words "An optional colon ":". =============================================== To prove this is what was intended I submit the section from the NDT draft. The NDT stuff says: 1.1. Constructing iSCSI names using the iqn. format iSCSI has given the Organizational naming authority additional flexibility by permitting it to hand out local naming authority to subordinate organizations. In this way it will be possible for the Organizational naming authority to assign for example, the string "storage", to one subgroup naming authority and "storage.tape" to another. In this case the subgroups may add a ":" following their assigned subgroup string to ensure ongoing uniqueness. For example: "storage:" and "storage.tape:". Also, additional sub-qualifiers can be assigned and separated by a "." as explained above. Using this approach, the subgroup with the sub-naming authority string of "storage" might, overtime, also create some Tape products. In this case, both subgroups might use the same qualifying names. It would be expected in this case that a naming conflict might occur, however by using the ":" appropriately the conflicts can be avoided. In this example com.acme.storage:tape.sys1.xyz and com.acme.storage.tape:sys1.xyz would not be in conflict even though the same sub-names are used. . . . John L. Hufferd Senior Technical Staff Member (STSM) IBM/SSG San Jose Ca Main Office (408) 256-0403, Tie: 276-0403, eFax: (408) 904-4688 Home Office (408) 997-6136, Cell: (408) 499-9702 Internet address: hufferd@us.ibm.com From owner-ips@ece.cmu.edu Wed Jul 17 06:19:59 2002 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA11526 for ; Wed, 17 Jul 2002 06:19:59 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id g6H9XR715539 for ips-outgoing; Wed, 17 Jul 2002 05:33:27 -0400 (EDT) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from d12lmsgate-3.de.ibm.com (d12lmsgate-3.de.ibm.com [195.212.91.201]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id g6H9XOX15533; Wed, 17 Jul 2002 05:33:24 -0400 (EDT) Received: from d12relay02.de.ibm.com (d12relay02.de.ibm.com [9.165.215.23]) by d12lmsgate-3.de.ibm.com (8.12.3/8.12.3) with ESMTP id g6H9XB7p016508; Wed, 17 Jul 2002 11:33:11 +0200 Received: from d10hubm1.telaviv.ibm.com (d10ml001.telaviv.ibm.com [9.148.216.55]) by d12relay02.de.ibm.com (8.11.1m3/NCO/VER6.2) with ESMTP id g6H9XAu94940; Wed, 17 Jul 2002 11:33:10 +0200 To: "John Hufferd" Cc: "Ips Reflector (E-mail)" , "KRUEGER,MARJORIE (HP-Roseville,ex1)" , owner-ips@ece.cmu.edu Importance: High MIME-Version: 1.0 Subject: Re: iSCSI: v15 issue: iqn. name format inconsistencies X-Mailer: Lotus Notes Release 5.0.9 November 16, 2001 From: "Julian Satran" Message-ID: Date: Wed, 17 Jul 2002 12:33:07 +0300 X-MIMETrack: Serialize by Router on D10ML001/10/M/IBM(Release 5.0.9a |January 7, 2002) at 17/07/2002 12:33:11, Serialize complete at 17/07/2002 12:33:11 Content-Type: multipart/alternative; boundary="=_alternative 00340E08C2256BF9_=" Sender: owner-ips@ece.cmu.edu Precedence: bulk This is a multipart message in MIME format. --=_alternative 00340E08C2256BF9_= Content-Type: text/plain; charset="us-ascii" John, Even so we still have an inconsistency in the examples. The colon is not after the reversed name but after a part of the suffix. Please clarify. Julo John Hufferd@IBMUS 07/17/2002 11:38 AM To: Julian Satran/Haifa/IBM@IBMIL cc: "Ips Reflector (E-mail)" , "KRUEGER,MARJORIE (HP-Roseville,ex1)" , owner-ips@ece.cmu.edu From: John Hufferd/San Jose/IBM@IBMUS Subject: Re: iSCSI: v15 issue: iqn. name format inconsistencies Julian, when the ":" part was added to the spec. we included it as if it was required. The text should say (see last line): In section 2.2.6.3 The iSCSI qualified name string consists of: - The string "iqn." - A date code, in yyyy-mm format. 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. This date code uses the Gregorian calendar. All four digits in the year must be present. Both digits of the month must be present, with January == "01" and December == "12". The dash must be included. - A dot ".". - The reversed domain name of the naming authority (person or organization) creating this iSCSI name. - An optional colon ":". =============================================== Julian please add the words "An optional colon ":". =============================================== To prove this is what was intended I submit the section from the NDT draft. The NDT stuff says: 1.1. Constructing iSCSI names using the iqn. format iSCSI has given the Organizational naming authority additional flexibility by permitting it to hand out local naming authority to subordinate organizations. In this way it will be possible for the Organizational naming authority to assign for example, the string "storage", to one subgroup naming authority and "storage.tape" to another. In this case the subgroups may add a ":" following their assigned subgroup string to ensure ongoing uniqueness. For example: "storage:" and "storage.tape:". Also, additional sub-qualifiers can be assigned and separated by a "." as explained above. Using this approach, the subgroup with the sub-naming authority string of "storage" might, overtime, also create some Tape products. In this case, both subgroups might use the same qualifying names. It would be expected in this case that a naming conflict might occur, however by using the ":" appropriately the conflicts can be avoided. In this example com.acme.storage:tape.sys1.xyz and com.acme.storage.tape:sys1.xyz would not be in conflict even though the same sub-names are used. . . . John L. Hufferd Senior Technical Staff Member (STSM) IBM/SSG San Jose Ca Main Office (408) 256-0403, Tie: 276-0403, eFax: (408) 904-4688 Home Office (408) 997-6136, Cell: (408) 499-9702 Internet address: hufferd@us.ibm.com --=_alternative 00340E08C2256BF9_= Content-Type: text/html; charset="us-ascii"
John,

Even so we still have an inconsistency in the examples. The colon is not after the reversed name but after a part of the suffix.
Please clarify.

Julo


John Hufferd@IBMUS

07/17/2002 11:38 AM


        To:        Julian Satran/Haifa/IBM@IBMIL
        cc:        "Ips Reflector (E-mail)" <ips@ece.cmu.edu>, "KRUEGER,MARJORIE (HP-Roseville,ex1)" <marjorie_krueger@hp.com>, owner-ips@ece.cmu.edu
        From:        John Hufferd/San Jose/IBM@IBMUS
        Subject:        Re: iSCSI: v15 issue: iqn. name format inconsistenciesLink
 





Julian,
when the ":" part was added to the spec.  we included it as if it was required.  The text should say (see last line):

In section  2.2.6.3


     The  iSCSI qualified name string consists of:
        -  The string "iqn."
       -  A date  code, in yyyy-mm format.  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.  This date  code
          uses the  Gregorian calendar.  All four digits in the year  must
          be present.   Both digits of the month must be present,  with
          January == "01"  and December == "12".  The dash must  be
           included.
       -  A dot  ".".
       -  The reversed domain name of  the naming authority (person  or
          organization)  creating this iSCSI name.
       -  An optional  colon ":".

===============================================
Julian please add the words "An optional colon ":".
===============================================


To prove this is what was intended I submit the section from the NDT draft.
The NDT stuff says:

1.1.  Constructing iSCSI names using the iqn. format

   iSCSI has given the Organizational naming authority additional
   flexibility by permitting it to hand out local naming authority to
   subordinate organizations.  In this way it will be possible for the
   Organizational naming authority to assign for example, the string
   "storage", to one subgroup naming authority and "storage.tape" to
   another.  In this case the subgroups may add a ":" following their
   assigned subgroup string to ensure ongoing uniqueness. For example:
   "storage:" and "storage.tape:".  Also, additional sub-qualifiers can
   be assigned and separated by a "." as explained above.

   Using this approach, the subgroup with the sub-naming authority
   string of "storage" might, overtime, also create some Tape products.
   In this case, both subgroups might use the same qualifying names.  It
   would be expected in this case that a naming conflict might occur,
   however by using the ":" appropriately the conflicts can be avoided.
   In this example com.acme.storage:tape.sys1.xyz and
   com.acme.storage.tape:sys1.xyz would not be in conflict even though
   the same sub-names are used.


.
.
.
John L. Hufferd
Senior Technical Staff Member (STSM)
IBM/SSG San Jose Ca
Main Office (408) 256-0403, Tie: 276-0403,  eFax: (408) 904-4688
Home Office (408) 997-6136, Cell: (408) 499-9702
Internet address: hufferd@us.ibm.com

--=_alternative 00340E08C2256BF9_=-- From owner-ips@ece.cmu.edu Wed Jul 17 06:35:51 2002 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA11863 for ; Wed, 17 Jul 2002 06:35:51 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id g6HADnQ16666 for ips-outgoing; Wed, 17 Jul 2002 06:13:49 -0400 (EDT) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from e31.co.us.ibm.com (e31.co.us.ibm.com [32.97.110.129]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id g6HADlX16660 for ; Wed, 17 Jul 2002 06:13:47 -0400 (EDT) Received: from westrelay01.boulder.ibm.com (westrelay01.boulder.ibm.com [9.17.194.22]) by e31.co.us.ibm.com (8.12.2/8.12.2) with ESMTP id g6HADhtB034110; Wed, 17 Jul 2002 06:13:43 -0400 Received: from d03nm014.boulder.ibm.com (avpilot.boulder.ibm.com [9.17.203.135]) by westrelay01.boulder.ibm.com (8.12.3/NCO/VER6.3) with ESMTP id g6HADffS102648; Wed, 17 Jul 2002 04:13:42 -0600 X-Priority: 1 (High) Importance: Normal Subject: Re: iSCSI: v15 issue: iqn. name format inconsistencies To: "Julian Satran" Cc: "KRUEGER,MARJORIE (HP-Roseville,ex1)" , ips@ece.cmu.edu X-Mailer: Lotus Notes Release 5.0.7 March 21, 2001 Message-ID: From: "John Hufferd" Date: Wed, 17 Jul 2002 02:43:36 -0700 X-MIMETrack: Serialize by Router on D03NM014/03/M/IBM(Release 5.0.10 |March 22, 2002) at 07/17/2002 04:13:42 AM MIME-Version: 1.0 Content-type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ece.cmu.edu id g6HADmX16661 Sender: owner-ips@ece.cmu.edu Precedence: bulk Content-Transfer-Encoding: 8bit You need to say: - An optional colon ":" A colon is optional and not required. Many organization will not need the colon. And I would recommend iqn.2001-04.com.acme.storage:diskarrays-sn-a8675309 iqn.2001-04.com.acme.storage:tape.sys1.xyz iqn.2001-04.com.acme.storage.tape:sys1.xyz iqn.2001-04.com.small.eng.storage.unit5 In this example the subdomain names that would otherwise conflict are "storage" and "storage.tape" The company called small has no possible conflicts and everything is handled with a "." . . . John L. Hufferd Senior Technical Staff Member (STSM) IBM/SSG San Jose Ca Main Office (408) 256-0403, Tie: 276-0403, eFax: (408) 904-4688 Home Office (408) 997-6136, Cell: (408) 499-9702 Internet address: hufferd@us.ibm.com Julian Satran/Haifa/IBM@IBMIL@ece.cmu.edu on 07/17/2002 01:14:06 AM Sent by: owner-ips@ece.cmu.edu To: "KRUEGER,MARJORIE (HP-Roseville,ex1)" cc: ips@ece.cmu.edu Subject: Re: iSCSI: v15 issue: iqn. name format inconsistencies Marjorie, Here is a differential. Please check (fast!). Julo Type "iqn." (iSCSI Qualified Name) This iSCSI name type can be used by any organization which owns a domain name. This naming format is useful when an end user or ser-vice provider wishes to assign iSCSI names for targets and/or initia-tors. To generate names of this type, the person or organization generat-ing the name must own a DNS domain name. This domain name does not have to be active, and does not have to resolve to an address; it just needs to be reserved to prevent others from generating iSCSI names using the same domain name. Because a domain name can expire, be acquired by another entity, and might be used to generate iSCSI names by both owners, the domain name must be additionally qualified by a date during which the naming authority owned the domain name. A date code is provided as part of the "iqn." format for this reason. The iSCSI qualified name string consists of: - The string "iqn.", used to distinguish these names from "eui." formatted names. - A date code, in yyyy-mm format. This date MUST be a date dur-ing which the naming authority owned the domain name used in this format, and SHOULD be the first month in which the domain name was owned by this naming authority at 00:01 GMT of the first day of the month. This date code uses the Grego-rian calendar. All four digits in the year must be present. Both digits of the month must be present, with January == "01" and December == "12". The dash must be included. - A dot ".". - The reversed domain name of the naming authority (person or organization) creating this iSCSI name. - A colon ":". - Any string, within the character set and length boundaries, that the owner of the domain name deems appropriate. This may contain product types, serial numbers, host identifiers, software keys, or anything else that makes sense to uniquely identify the initiator or target. Everything after the reversed domain name, followed by colon ":", can be assigned as desired by the owner of the domain name. It is the respon-sibility of the entity that is the naming authority to ensure that the iSCSI names it assigns are worldwide unique. For example, "ACME Storage Arrays, Inc.", might own the domain name "acme.com". The following are examples of iSCSI qualified names that might be generated by "ACME Storage Arrays, Inc."           Organization    Subgroup Naming Authority               Naming      and/or string defined by Type  Date     Auth       "acme.com" Naming Authority +--++-----+ +------+ +--------------------------------+ |  ||     | |      | |                                | iqn.2001-04.com.acme:storage.diskarrays-sn-a8675309 iqn.2001-04.com.acme:storage.tape.sys1.xyz iqn.2001-04.com.acme:storage.tape.sys1.xyz "KRUEGER,MARJORIE (HP-Roseville,ex1)"         To:        "Ips Reflector (E-mail)" Sent by:         cc: owner-ips@ece.cmu.edu         Subject:        iSCSI: v15 issue: iqn. name format 07/17/2002 12:44 AM inconsistencies There is currently an inconsistency in the way iSCSI "iqn."-formatted names are illustrated and described between the iSCSI protocol document and the iSCSI Naming and Discovery document.  In particular, the separator character between the reversed-domain name and the rest of the string is defined to be "." but some examples in the N&D document describe it as ":". I remember discussion (among the N&D team) that this separator should be ":" in order to distinguish the reversed domain name from the rest of the string, but this got lost somewhere along the line.  If there are no objections to changing this in the main draft, this translates into changes for both the iSCSI main draft and the N&D draft in cleaning up the examples and making sure they are consistent (some use "." and some use ":"). Here are the changes I recommend to the main draft: In section 2.2.6.3     The iSCSI qualified name string consists of:       -  The string "iqn."       -  A date code, in yyyy-mm format.  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.  This date code          uses the Gregorian calendar.  All four digits in the year must          be present.  Both digits of the month must be present, with          January == "01" and December == "12".  The dash must be          included.       -  A dot ".".       -  The reversed domain name of the naming authority (person or          organization) creating this iSCSI name.       -  A colon ":".       -  Any string, within the character set and length boundaries,          that the owner of the domain name deems appropriate.  This may          contain product types, serial numbers, host identifiers, soft-          ware keys, or anything else that makes sense to uniquely iden-          tify the initiator or target.  Everything after ":", can be assigned as desired by the owner of          the domain name.  It is the responsibility of the entity that          is the naming authority to ensure that the iSCSI names it          assigns are world wide unique.     For example, "ACME Storage Arrays, Inc.", might own the domain name     "acme.com". The following are examples of iSCSI qualified names that     might be generated by "ACME Storage Arrays, Inc."                    Organization                        Naming     String defined by          Type  Date     Auth      "acme.com" naming authority          +--++-----+ +------+ +--------------------------------+          |  ||     | |      | |                                |          iqn.2001-04.com.acme:storage.diskarrays-sn-a8675309          iqn.2001-04.com.acme:server.megafast900.i95874 In section 11.4 TargetName     Examples:       TargetName=iqn.1993-11.com.diskvendor:diskarrays.sn.45678 In section 11.5 InitiatorName     Examples:       InitiatorName=iqn.1992-04.com.osvendor:plan9.cdrom.12345       InitiatorName=iqn.2001-02.com.ssp:users.customer235.host90 In appendix C     In the first example, the initiator and target authenticate each other     via Kerberos:       I-> Login (CSG,NSG=0,1 T=1)           InitiatorName=iqn.1999-07.com.os:hostid.77           TargetName=iqn.1999-07.com.acme:diskarray.sn.88           AuthMethod=KRB5,SRP,None etc - all these Login examples that contain iSCSI names need to be fixed. In appendix D     Target sends a text response that contains:       TargetName=iqn.1993-11.com.acme:diskarray.sn.8675309 etc - all TargetName examples need to be fixed. Several examples in the Naming and Discovery draft need to be fixed - I'll address that in a separate email. Marjorie Krueger Networked Storage Architecture Networked Storage Solutions Hewlett-Packard From owner-ips@ece.cmu.edu Wed Jul 17 08:31:54 2002 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA14562 for ; Wed, 17 Jul 2002 08:31:54 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id g6HBs0620019 for ips-outgoing; Wed, 17 Jul 2002 07:54:00 -0400 (EDT) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from osmtp1.electric.net (osmtp3.electric.net [216.129.90.30]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id g6HBrvX20013; Wed, 17 Jul 2002 07:53:58 -0400 (EDT) Received: from [133.93.79.129] (helo=EGRodriguez) by osmtp1.electric.net with asmtp (Exim 3.22 #1) id 17UnNS-0003bG-04; Wed, 17 Jul 2002 04:53:55 -0700 From: "Elizabeth G. Rodriguez" To: "'Julian Satran'" , "'John Hufferd'" Cc: "'Ips Reflector \(E-mail\)'" , "'KRUEGER,MARJORIE \(HP-Roseville,ex1\)'" , Subject: RE: iSCSI: v15 issue: iqn. name format inconsistencies Date: Wed, 17 Jul 2002 06:50:25 -0600 Keywords: IETF-IPS Message-ID: <001901c22d90$8d9359e0$814f5d85@EGRodriguez> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.3416 Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 In-reply-to: Sender: owner-ips@ece.cmu.edu Precedence: bulk Content-Transfer-Encoding: 7bit Hi Julian, This is being used to allow for sub-group name assignment, so we probably need to modify the text to indicate a sub-qualify may optionally precede the ":". Also, believe that we are restricting to at most 1 ":", so should probably also indicate that. Finally, don't think that the txt that John cites below has been transferred to this draft, so need to add explanation for how ":" vs "." is used. Something along the lines of So, for the txt, the mods would be: ... - The reversed domain name of the naming authority (person or organization) creating this iSCSI name. (new>>) The reverse domain name may also optionally include a sub-qualifier, such as a sub-domain or sub-group name. - A colon ":" or a dot ".". (Please see txt in section xxx for how ":" is used.) ... Then, new text, to be referenced above, indicating how ":" is to be used needs to be added. Something along the lines of the txt that John cited below. Elizabeth -----Original Message----- From: Julian Satran [mailto:Julian_Satran@il.ibm.com] Sent: Wednesday, July 17, 2002 3:33 AM To: John Hufferd Cc: Ips Reflector (E-mail); KRUEGER,MARJORIE (HP-Roseville,ex1); owner-ips@ece.cmu.edu Subject: Re: iSCSI: v15 issue: iqn. name format inconsistencies Importance: High John, Even so we still have an inconsistency in the examples. The colon is not after the reversed name but after a part of the suffix. Please clarify. Julo John Hufferd@IBMUS 07/17/2002 11:38 AM To: Julian Satran/Haifa/IBM@IBMIL cc: "Ips Reflector (E-mail)" , "KRUEGER,MARJORIE (HP-Roseville,ex1)" , owner-ips@ece.cmu.edu From: John Hufferd/San Jose/IBM@IBMUS Subject: Re: iSCSI: v15 issue: iqn. name format inconsistencies Julian, when the ":" part was added to the spec. we included it as if it was required. The text should say (see last line): In section 2.2.6.3 The iSCSI qualified name string consists of: - The string "iqn." - A date code, in yyyy-mm format. 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. This date code uses the Gregorian calendar. All four digits in the year must be present. Both digits of the month must be present, with January == "01" and December == "12". The dash must be included. - A dot ".". - The reversed domain name of the naming authority (person or organization) creating this iSCSI name. - An optional colon ":". =============================================== Julian please add the words "An optional colon ":". =============================================== To prove this is what was intended I submit the section from the NDT draft. The NDT stuff says: 1.1. Constructing iSCSI names using the iqn. format iSCSI has given the Organizational naming authority additional flexibility by permitting it to hand out local naming authority to subordinate organizations. In this way it will be possible for the Organizational naming authority to assign for example, the string "storage", to one subgroup naming authority and "storage.tape" to another. In this case the subgroups may add a ":" following their assigned subgroup string to ensure ongoing uniqueness. For example: "storage:" and "storage.tape:". Also, additional sub-qualifiers can be assigned and separated by a "." as explained above. Using this approach, the subgroup with the sub-naming authority string of "storage" might, overtime, also create some Tape products. In this case, both subgroups might use the same qualifying names. It would be expected in this case that a naming conflict might occur, however by using the ":" appropriately the conflicts can be avoided. In this example com.acme.storage:tape.sys1.xyz and com.acme.storage.tape:sys1.xyz would not be in conflict even though the same sub-names are used. From owner-ips@ece.cmu.edu Wed Jul 17 10:54:59 2002 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA18424 for ; Wed, 17 Jul 2002 10:54:58 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id g6HDi1q24762 for ips-outgoing; Wed, 17 Jul 2002 09:44:01 -0400 (EDT) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from d12lmsgate.de.ibm.com (d12lmsgate.de.ibm.com [195.212.91.199]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id g6HDhvX24744; Wed, 17 Jul 2002 09:43:57 -0400 (EDT) Received: from d12relay01.de.ibm.com (d12relay01.de.ibm.com [9.165.215.22]) by d12lmsgate.de.ibm.com (8.12.3/8.12.3) with ESMTP id g6HDhnNG030104; Wed, 17 Jul 2002 15:43:50 +0200 Received: from d10hubm1.telaviv.ibm.com (d10ml001.telaviv.ibm.com [9.148.216.55]) by d12relay01.de.ibm.com (8.11.1m3/NCO/VER6.2) with ESMTP id g6HDhnM107552; Wed, 17 Jul 2002 15:43:49 +0200 To: "John Hufferd" Cc: ips@ece.cmu.edu, "KRUEGER,MARJORIE (HP-Roseville,ex1)" , owner-ips@ece.cmu.edu MIME-Version: 1.0 Subject: Re: iSCSI: v15 issue: iqn. name format inconsistencies X-Mailer: Lotus Notes Release 5.0.9 November 16, 2001 From: "Julian Satran" Message-ID: Date: Wed, 17 Jul 2002 16:43:46 +0300 X-MIMETrack: Serialize by Router on D10ML001/10/M/IBM(Release 5.0.9a |January 7, 2002) at 17/07/2002 16:43:49, Serialize complete at 17/07/2002 16:43:49 Content-Type: multipart/alternative; boundary="=_alternative 004A592EC2256BF9_=" Sender: owner-ips@ece.cmu.edu Precedence: bulk This is a multipart message in MIME format. --=_alternative 004A592EC2256BF9_= Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable John - it is still confusing - an optional column where? within the string = (nothing has to be said - we can revert to the old form)? Julo John Hufferd/San Jose/IBM@IBMUS Sent by: owner-ips@ece.cmu.edu 07/17/2002 12:43 PM =20 To: Julian Satran/Haifa/IBM@IBMIL cc: "KRUEGER,MARJORIE (HP-Roseville,ex1)" ,=20 ips@ece.cmu.edu Subject: Re: iSCSI: v15 issue: iqn. name format inconsistenc= ies =20 You need to say: - An optional colon ":" A colon is optional and not required. Many organization will not need the colon. And I would recommend iqn.2001-04.com.acme.storage:diskarrays-sn-a8675309 iqn.2001-04.com.acme.storage:tape.sys1.xyz iqn.2001-04.com.acme.storage.tape:sys1.xyz iqn.2001-04.com.small.eng.storage.unit5 In this example the subdomain names that would otherwise conflict are "storage" and "storage.tape" The company called small has no possible conflicts and everything is handled with a "." . . . John L. Hufferd Senior Technical Staff Member (STSM) IBM/SSG San Jose Ca Main Office (408) 256-0403, Tie: 276-0403, eFax: (408) 904-4688 Home Office (408) 997-6136, Cell: (408) 499-9702 Internet address: hufferd@us.ibm.com Julian Satran/Haifa/IBM@IBMIL@ece.cmu.edu on 07/17/2002 01:14:06 AM Sent by: owner-ips@ece.cmu.edu To: "KRUEGER,MARJORIE (HP-Roseville,ex1)" cc: ips@ece.cmu.edu Subject: Re: iSCSI: v15 issue: iqn. name format inconsistencies Marjorie, Here is a differential. Please check (fast!). Julo Type "iqn." (iSCSI Qualified Name) This iSCSI name type can be used by any organization which owns a domain name. This naming format is useful when an end user or ser-vice provider wishes to assign iSCSI names for targets and/or initia-tors. To generate names of this type, the person or organization generat-ing the name must own a DNS domain name. This domain name does not have to be active, and does not have to resolve to an address; it just needs to be reserved to prevent others from generating iSCSI names using the same domain name. Because a domain name can expire, be acquired by another entity, and might be used to generate iSCSI names by both owners, the domain name must be additionally qualified by a date during which the naming authority owned the domain name. A date code is provided as part of the "iqn." format for this reason. The iSCSI qualified name string consists of: - The string "iqn.", used to distinguish these names from "eui." formatted names. - A date code, in yyyy-mm format. This date MUST be a date dur-ing which the naming authority owned the domain name used in this format, and SHOULD be the first month in which the domain name was owned by this naming authority at 00:01 GMT of the first day of the month. This date code uses the Grego-rian calendar. All four digits in the year must be present. Both digits of the month must be present, with January =3D=3D "01" and December =3D=3D "12". The dash must be included. - A dot ".". - The reversed domain name of the naming authority (person or=20 organization) creating this iSCSI name. - A colon ":". - Any string, within the character set and length boundaries, that the owner of the domain name deems appropriate. This may contain product=20 types, serial numbers, host identifiers, software keys, or anything else that makes sense to uniquely identify the initiator or target. Everything after the reversed domain name, followed by colon ":", can be assigned as=20 desired by the owner of the domain name. It is the respon-sibility of the entity that is the naming authority to ensure that the iSCSI names it assigns are worldwide unique. For example, "ACME Storage Arrays, Inc.", might own the domain name "acme.com". The following are examples of iSCSI qualified names that might be generated by "ACME Storage Arrays, Inc." =A0 =A0 =A0 =A0 =A0 Organization =A0 =A0Subgroup Naming Authority =A0 =A0 =A0 =A0 =A0 =A0 =A0 Naming =A0 =A0 =A0and/or string defined by Type =A0Date =A0 =A0 Auth =A0 =A0 =A0 "acme.com" Naming Authority +--++-----+ +------+ +--------------------------------+ | =A0|| =A0 =A0 | | =A0 =A0 =A0| | =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 = =A0 =A0 =A0 =A0 =A0 =A0| iqn.2001-04.com.acme:storage.diskarrays-sn-a8675309 iqn.2001-04.com.acme:storage.tape.sys1.xyz iqn.2001-04.com.acme:storage.tape.sys1.xyz =20 "KRUEGER,MARJORIE=20 (HP-Roseville,ex1)" =A0 =A0 =A0 =A0 To: =A0 =A0 =A0 =A0= "Ips Reflector=20 (E-mail)" =20 Sent by: =A0 =A0 =A0 =A0 cc:=20 owner-ips@ece.cmu.edu =A0 =A0 =A0 =A0 Subject: =A0 =A0 = =A0 =A0iSCSI: v15=20 issue: iqn. name format=20 07/17/2002 12:44 AM inconsistencies=20 =20 =20 =20 There is currently an inconsistency in the way iSCSI "iqn."-formatted=20 names are illustrated and described between the iSCSI protocol document and the iSCSI Naming and Discovery document. =A0In particular, the separator character between the reversed-domain name and the rest of the string is defined to be "." but some examples in the N&D document describe it as=20 ":". I remember discussion (among the N&D team) that this separator should be ":" in order to distinguish the reversed domain name from the rest of the string, but this got lost somewhere along the line. =A0If there are no objections to changing this in the main draft, this translates into=20 changes for both the iSCSI main draft and the N&D draft in cleaning up the=20 examples and making sure they are consistent (some use "." and some use ":"). Here are the changes I recommend to the main draft: In section 2.2.6.3 =A0 =A0 The iSCSI qualified name string consists of: =A0 =A0 =A0 - =A0The string "iqn." =A0 =A0 =A0 - =A0A date code, in yyyy-mm format. =A0This date MUST be a date =A0 =A0 =A0 =A0 =A0during which the naming authority owned the domain name = used =A0 =A0 =A0 =A0 =A0in this format, and SHOULD be the date on which the doma= in =A0 =A0 =A0 =A0 =A0name was acquired by this naming authority. =A0This date= code =A0 =A0 =A0 =A0 =A0uses the Gregorian calendar. =A0All four digits in the y= ear must =A0 =A0 =A0 =A0 =A0be present. =A0Both digits of the month must be present,= with =A0 =A0 =A0 =A0 =A0January =3D=3D "01" and December =3D=3D "12". =A0The das= h must be =A0 =A0 =A0 =A0 =A0included. =A0 =A0 =A0 - =A0A dot ".". =A0 =A0 =A0 - =A0The reversed domain name of the naming authority (person or =A0 =A0 =A0 =A0 =A0organization) creating this iSCSI name. =A0 =A0 =A0 - =A0A colon ":". =A0 =A0 =A0 - =A0Any string, within the character set and length boundaries, =A0 =A0 =A0 =A0 =A0that the owner of the domain name deems appropriate. =A0= This may =A0 =A0 =A0 =A0 =A0contain product types, serial numbers, host identifiers,= soft- =A0 =A0 =A0 =A0 =A0ware keys, or anything else that makes sense to uniquely= iden- =A0 =A0 =A0 =A0 =A0tify the initiator or target. =A0Everything after ":", can be assigned as desired by the owner = of =A0 =A0 =A0 =A0 =A0the domain name. =A0It is the responsibility of the enti= ty that =A0 =A0 =A0 =A0 =A0is the naming authority to ensure that the iSCSI names it =A0 =A0 =A0 =A0 =A0assigns are world wide unique. =A0 =A0 For example, "ACME Storage Arrays, Inc.", might own the domain name =A0 =A0 "acme.com". The following are examples of iSCSI qualified names that =A0 =A0 might be generated by "ACME Storage Arrays, Inc." =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0Organization =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0Naming =A0 =A0 String define= d by =A0 =A0 =A0 =A0 =A0Type =A0Date =A0 =A0 Auth =A0 =A0 =A0"acme.com" naming a= uthority =A0 =A0 =A0 =A0 =A0+--++-----+ +------+ +--------------------------------+ =A0 =A0 =A0 =A0 =A0| =A0|| =A0 =A0 | | =A0 =A0 =A0| | =A0 =A0 =A0 =A0 =A0 = =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0| =A0 =A0 =A0 =A0 =A0iqn.2001-04.com.acme:storage.diskarrays-sn-a8675309 =A0 =A0 =A0 =A0 =A0iqn.2001-04.com.acme:server.megafast900.i95874 In section 11.4 TargetName =A0 =A0 Examples: =A0 =A0 =A0 TargetName=3Diqn.1993-11.com.diskvendor:diskarrays.sn.45678 In section 11.5 InitiatorName =A0 =A0 Examples: =A0 =A0 =A0 InitiatorName=3Diqn.1992-04.com.osvendor:plan9.cdrom.12345 =A0 =A0 =A0 InitiatorName=3Diqn.2001-02.com.ssp:users.customer235.host90 In appendix C =A0 =A0 In the first example, the initiator and target authenticate each ot= her =A0 =A0 via Kerberos: =A0 =A0 =A0 I-> Login (CSG,NSG=3D0,1 T=3D1) =A0 =A0 =A0 =A0 =A0 InitiatorName=3Diqn.1999-07.com.os:hostid.77 =A0 =A0 =A0 =A0 =A0 TargetName=3Diqn.1999-07.com.acme:diskarray.sn.88 =A0 =A0 =A0 =A0 =A0 AuthMethod=3DKRB5,SRP,None etc - all these Login examples that contain iSCSI names need to be fixed. In appendix D =A0 =A0 Target sends a text response that contains: =A0 =A0 =A0 TargetName=3Diqn.1993-11.com.acme:diskarray.sn.8675309 etc - all TargetName examples need to be fixed. Several examples in the Naming and Discovery draft need to be fixed - I'll address that in a separate email. Marjorie Krueger Networked Storage Architecture Networked Storage Solutions Hewlett-Packard --=_alternative 004A592EC2256BF9_= Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
John - it is still confusing - an op= tional column where? within the string (nothing has to be said - we can rev= ert to the old form)?

Julo


John Hufferd/San Jose/IBM@IBMUS
Sent by: owner-ips@ece.cmu.edu

07/17/2002 12:43 PM

       
        To: &nbs= p;      Julian Satran/Haifa/IBM@IBMIL
        cc: &nbs= p;      "KRUEGER,MARJORIE (HP-Roseville,ex1)" <= marjorie=5Fkrueger@hp.com>, ips@ece.cmu.edu
        Subject:=        Re: iSCSI: v15 issue: iqn. name format inconsis= tencies

       



You need to say:

- An optional colon ":"

A colon is optional and not required.  Many organization will not need= the
colon.

And I would recommend

iqn.2001-04.com.acme.storage:diskarrays-sn-a8675309
iqn.2001-04.com.acme.storage:tape.sys1.xyz
iqn.2001-04.com.acme.storage.tape:sys1.xyz
iqn.2001-04.com.small.eng.storage.unit5

In this example the subdomain names that would otherwise conflict are
"storage" and "storage.tape"
The company called small has no possible conflicts and everything is
handled with a "."

.
.
.
John L. Hufferd
Senior Technical Staff Member (STSM)
IBM/SSG San Jose Ca
Main Office (408) 256-0403, Tie: 276-0403,  eFax: (408) 904-4688
Home Office (408) 997-6136, Cell: (408) 499-9702
Internet address: hufferd@us.ibm.com


Julian Satran/Haifa/IBM@IBMIL@ece.cmu.edu on 07/17/2002 01:14:06 AM

Sent by:    owner-ips@ece.cmu.edu


To:    "KRUEGER,MARJORIE (HP-Roseville,ex1)" <marjor= ie=5Fkrueger@hp.com>
cc:    ips@ece.cmu.edu
Subject:    Re: iSCSI: v15 issue: iqn. name format inconsistencie= s




Marjorie,

Here is a differential.
Please check (fast!).

Julo

Type "iqn." (iSCSI Qualified Name)

This iSCSI name type can be used by any organization which owns a domain
name. This naming format is useful when an end user or ser-vice provider
wishes to assign iSCSI names for targets and/or initia-tors.

To generate names of this type, the person or organization generat-ing the<= br> name must own a DNS domain name. This domain name does not have to be
active, and does not have to resolve to an address; it just needs to be
reserved to prevent others from generating iSCSI names using the same
domain name.

Because a domain name can expire, be acquired by another entity, and might<= br> be used to generate iSCSI names by both owners, the domain name must be
additionally qualified by a date during which the naming authority owned
the domain name. A date code is provided as part of the "iqn." fo= rmat for
this reason.

The iSCSI qualified name string consists of:

- The string "iqn.", used to distinguish these names from "e= ui." formatted
names.
- A date code, in yyyy-mm format. This date MUST be a date dur-ing which
the naming authority owned the domain name used in this format, and SHOULD<= br> be the first month in which the domain name was owned by this naming
authority at 00:01 GMT of the first day of the month. This date code uses the Grego-rian calendar. All four digits in the year must be present. Both<= br> digits of the month must be present, with January =3D=3D "01" and= December
=3D=3D "12". The dash must be included.
- A dot ".".
- The reversed domain name of the naming authority (person or organization)=
creating this iSCSI name.
- A colon ":".
- Any string, within the character set and length boundaries, that the
owner of the domain name deems appropriate. This may contain product types,=
serial numbers, host identifiers, s= oftware keys, or anything else that
makes sense to uniquely identify the initiator or target. Everything after<= br> the reversed domain name, followed by colon ":", can be assigned = as desired
by the owner of the domain name. It is the respon-sibility of the entity
that is the naming authority to ensure that the iSCSI names it assigns are<= br> worldwide unique. For example, "ACME Storage Arrays, Inc.", might= own the
domain name "acme.com".

The following are examples of iSCSI qualified names that might be
generated by "ACME Storage Arrays, Inc."

=A0 =A0 =A0 =A0 =A0 Organization =A0 =A0Subgroup Naming Authority
=A0 =A0 =A0 =A0 =A0 =A0 =A0 Naming =A0 =A0 =A0and/or string defined by
Type =A0Date =A0 =A0 Auth =A0 =A0 =A0 "acme.com" Naming Authority=
+--++-----+ +------+ +--------------------------------+
| =A0|| =A0 =A0 | | =A0 =A0 =A0| | =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 = =A0 =A0 =A0 =A0 =A0 =A0|

iqn.2001-04.com.acme:storage.diskarrays-sn-a8675309
iqn.2001-04.com.acme:storage.tape.sys1.xyz
iqn.2001-04.com.acme:storage.tape.sys1.xyz




                    &nbs= p;                     &n= bsp;                     =          
      "KRUEGER,MARJORIE         &n= bsp;                     =                    
      (HP-Roseville,ex1)"         =      =A0 =A0 =A0 =A0 To: =A0 =A0 =A0 =A0"Ips Reflector =  
      <marjorie=5Fkrueger@hp.com>      = ;  (E-mail)" <ips@ece.cmu.edu>        <= br>       Sent by:             &n= bsp;           =A0 =A0 =A0 =A0 cc:     &= nbsp;                  
      owner-ips@ece.cmu.edu         &nb= sp;  =A0 =A0 =A0 =A0 Subject: =A0 =A0 =A0 =A0iSCSI: v15
                    &nbs= p;                  issue: iqn= . name format            
      07/17/2002 12:44 AM          = ;    inconsistencies             &n= bsp;      
                    &nbs= p;                     &n= bsp;                     =          
                    &nbs= p;                     &n= bsp;                     =          
                    &nbs= p;                     &n= bsp;                     =          



There is currently an inconsistency in the way iSCSI "iqn."-forma= tted names
are illustrated and described between the iSCSI protocol document and the iSCSI Naming and Discovery document. =A0In particular, the separator
character between the reversed-domain name and the rest of the string is
defined to be "." but some examples in the N&D document descr= ibe it as ":".

I remember discussion (among the N&D team) that this separator should b= e
":" in order to distinguish the reversed domain name from the res= t of the
string, but this got lost somewhere along the line. =A0If there are no
objections to changing this in the main draft, this translates into changes=
for both the iSCSI main draft and the N&D draft in cleaning up the exam= ples
and making sure they are consistent (some use "." and some use &q= uot;:").

Here are the changes I recommend to the main draft:
In section 2.2.6.3


=A0 =A0 The iSCSI qualified name string consists of:
=A0 =A0 =A0 - =A0The string "iqn."
=A0 =A0 =A0 - =A0A date code, in yyyy-mm format. =A0This date MUST be a dat= e
=A0 =A0 =A0 =A0 =A0during which the naming authority owned the domain name = used
=A0 =A0 =A0 =A0 =A0in this format, and SHOULD be the date on which the doma= in
=A0 =A0 =A0 =A0 =A0name was acquired by this naming authority. =A0This date= code
=A0 =A0 =A0 =A0 =A0uses the Gregorian calendar. =A0All four digits in the y= ear must
=A0 =A0 =A0 =A0 =A0be present. =A0Both digits of the month must be present,= with
=A0 =A0 =A0 =A0 =A0January =3D=3D "01" and December =3D=3D "= 12". =A0The dash must be
=A0 =A0 =A0 =A0 =A0included.
=A0 =A0 =A0 - =A0A dot ".".
=A0 =A0 =A0 - =A0The reversed domain name of the naming authority (person o= r
=A0 =A0 =A0 =A0 =A0organization) creating this iSCSI name.
=A0 =A0 =A0 - =A0A colon ":".
=A0 =A0 =A0 - =A0Any string, within the character set and length boundaries= ,
=A0 =A0 =A0 =A0 =A0that the owner of the domain name deems appropriate. =A0= This may
=A0 =A0 =A0 =A0 =A0contain product types, serial numbers, host identifiers,= soft-
=A0 =A0 =A0 =A0 =A0ware keys, or anything else that makes sense to uniquely= iden-
=A0 =A0 =A0 =A0 =A0tify the initiator or target. =A0Everything after "= <reversed
=A0 =A0 =A0 =A0 =A0domain name>:", can be assigned as desired by th= e owner of
=A0 =A0 =A0 =A0 =A0the domain name. =A0It is the responsibility of the enti= ty that
=A0 =A0 =A0 =A0 =A0is the naming authority to ensure that the iSCSI names i= t
=A0 =A0 =A0 =A0 =A0assigns are world wide unique.

=A0 =A0 For example, "ACME Storage Arrays, Inc.", might own the d= omain name
=A0 =A0 "acme.com". The following are examples of iSCSI qualified= names that
=A0 =A0 might be generated by "ACME Storage Arrays, Inc."

=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0Organization
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0Naming =A0 =A0 String define= d by
=A0 =A0 =A0 =A0 =A0Type =A0Date =A0 =A0 Auth =A0 =A0 =A0"acme.com"= ; naming authority
=A0 =A0 =A0 =A0 =A0+--++-----+ +------+ +--------------------------------+<= br> =A0 =A0 =A0 =A0 =A0| =A0|| =A0 =A0 | | =A0 =A0 =A0| | =A0 =A0 =A0 =A0 =A0 = =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0|

=A0 =A0 =A0 =A0 =A0iqn.2001-04.com.acme:storage.diskarrays-sn-a8675309
=A0 =A0 =A0 =A0 =A0iqn.2001-04.com.acme:server.megafast900.i95874

In section 11.4 TargetName

=A0 =A0 Examples:

=A0 =A0 =A0 TargetName=3Diqn.1993-11.com.diskvendor:diskarrays.sn.45678

In section 11.5 InitiatorName

=A0 =A0 Examples:

=A0 =A0 =A0 InitiatorName=3Diqn.1992-04.com.osvendor:plan9.cdrom.12345
=A0 =A0 =A0 InitiatorName=3Diqn.2001-02.com.ssp:users.customer235.host90

<Julian, make sure to delete the last example in the current text, as it= 's
invalid>

In appendix C

=A0 =A0 In the first example, the initiator and target authenticate each ot= her
=A0 =A0 via Kerberos:

=A0 =A0 =A0 I-> Login (CSG,NSG=3D0,1 T=3D1)
=A0 =A0 =A0 =A0 =A0 InitiatorName=3Diqn.1999-07.com.os:hostid.77
=A0 =A0 =A0 =A0 =A0 TargetName=3Diqn.1999-07.com.acme:diskarray.sn.88
=A0 =A0 =A0 =A0 =A0 AuthMethod=3DKRB5,SRP,None

etc - all these Login examples that contain iSCSI names need to be fixed.
In appendix D

=A0 =A0 Target sends a text response that contains:

=A0 =A0 =A0 TargetName=3Diqn.1993-11.com.acme:diskarray.sn.8675309

etc - all TargetName examples need to be fixed.

Several examples in the Naming and Discovery draft need to be fixed - I'll<= br> address that in a separate email.

Marjorie Krueger
Networked Storage Architecture
Networked Storage Solutions
Hewlett-Packard

--=_alternative 004A592EC2256BF9_=-- From owner-ips@ece.cmu.edu Wed Jul 17 11:36:32 2002 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA19416 for ; Wed, 17 Jul 2002 11:36:27 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id g6HEpPb27968 for ips-outgoing; Wed, 17 Jul 2002 10:51:25 -0400 (EDT) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from cygnus.equallogic.com (cygnus.equallogic.com [65.170.102.10]) by ece.cmu.edu (8.11.0/8.10.2) with SMTP id g6HEpNX27963 for ; Wed, 17 Jul 2002 10:51:23 -0400 (EDT) Received: from cygnus.equallogic.com (localhost.localdomain [127.0.0.1]) by cygnus.equallogic.com (8.11.6/8.11.6) with ESMTP id g6HEpHC10134 for ; Wed, 17 Jul 2002 10:51:17 -0400 Received: from deneb.dev.equallogic.com (deneb.dev.equallogic.com [172.16.1.99]) by cygnus.equallogic.com (8.11.6/8.11.6) with ESMTP id g6HEpHQ10122; Wed, 17 Jul 2002 10:51:17 -0400 Received: from PKONING.equallogic.com (localhost.localdomain [127.0.0.1]) by deneb.dev.equallogic.com (8.11.6/8.11.6) with ESMTP id g6HEpFY27389; Wed, 17 Jul 2002 10:51:16 -0400 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <15669.33892.193000.37235@gargle.gargle.HOWL> Date: Wed, 17 Jul 2002 10:51:16 -0400 From: Paul Koning To: hufferd@us.ibm.com Cc: marjorie_krueger@hp.com, ips@ece.cmu.edu Subject: Re: iSCSI: v15 issue: iqn. name format inconsistencies References: X-Mailer: VM 6.95 under 21.4 (patch 3) "Academic Rigor" XEmacs Lucid Sender: owner-ips@ece.cmu.edu Precedence: bulk Content-Transfer-Encoding: 7bit Excerpt of message (sent 17 July 2002) by John Hufferd: > > Marjorie, > I think it is OK to make some of the example changes you have indicated, > but it is not required to always use the ":" It depends on the way your > company manages their sub domain names. It is still valid to use an all > dotted name. > > The ":" was needed since a company can hand out subdomains with names like > "mother" and "mother.wonder" to different departments and therefore it > would be possible for both departments to create a name like > "com.ajax.mother.wonder.mydiskarray". The use of ":" permits the > departments to make their names unique by placing the ":" following their > subdomain portions. That is, they can use the same characters but > separated with a colon as follows "com.ajax.mother:wonder.mydiskarray" and > "com.ajax.mother.wonder:mydiskarray". I would rather have a mandatory colon, rather than have it depend on some particular organization's naming conventions of the day. paul From owner-ips@ece.cmu.edu Wed Jul 17 12:53:13 2002 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA23176 for ; Wed, 17 Jul 2002 12:53:12 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id g6HGEai03143 for ips-outgoing; Wed, 17 Jul 2002 12:14:36 -0400 (EDT) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from mail.ivivity.com ([64.238.111.99]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id g6HGEYX03134 for ; Wed, 17 Jul 2002 12:14:34 -0400 (EDT) Received: by ATLOPS with Internet Mail Service (5.5.2653.19) id ; Wed, 17 Jul 2002 12:14:33 -0400 Message-ID: From: Eddy Quicksall To: "Mallikarjun C. (E-mail)" Cc: "ips@ece. cmu. edu (E-mail)" Subject: RE: iSCSI: freeing resources during data-in and r2t Date: Wed, 17 Jul 2002 12:14:32 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C22DAD.0942A570" Sender: owner-ips@ece.cmu.edu Precedence: bulk This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_001_01C22DAD.0942A570 Content-Type: text/plain; charset="iso-8859-1" I think see a slight inefficiency in how resources are freed when multiple data-in and r2t's PDU's are used when ErrorRecoverLevel > 0 or TCP ACK is not available to the iSCSI layer. Data-in and R2T's use DataSN and R2TSN. To free those resources, ExpStatSN is used. But if several R2T's and/or Data-in PDU's were used, resources used for those PDU's are tied up for the entire command. Since other commands could be received during this time, it would be nice if those commands could contain information that would tell the target that the R2T and/or Data-in PDU's have been received. I know a radical change at this point is probably a bad idea but I just wanted to throw out the idea ... if the StatSN/ExpStatSN were changed to something like RespSN/ExpRespSN and if everything going from the target to the initiator carried a new RespSN, then the resources could be freed up sooner. I would hate to use the A bit for this because it causes more traffic. Eddy mailto:Eddy_Quicksall@iVivity.com ------_=_NextPart_001_01C22DAD.0942A570 Content-Type: text/html; charset="iso-8859-1"

I think see a slight inefficiency in how resources are freed when multiple data-in and r2t's PDU's are used when ErrorRecoverLevel > 0 or TCP ACK is not available to the iSCSI layer.
 
Data-in and R2T's use DataSN and R2TSN. To free those resources, ExpStatSN is used.
 
But if several R2T's and/or Data-in PDU's were used, resources used for those PDU's are tied up for the entire command.
 
Since other commands could be received during this time, it would be nice if those commands could contain information that would tell the target that the R2T and/or Data-in PDU's have been received.
 
I know a radical change at this point is probably a bad idea but I just wanted to throw out the idea ... if the StatSN/ExpStatSN were changed to something like RespSN/ExpRespSN and if everything going from the target to the initiator carried a new RespSN, then the resources could be freed up sooner.
 
I would hate to use the A bit for this because it causes more traffic.
 
Eddy
mailto:Eddy_Quicksall@iVivity.com
 
------_=_NextPart_001_01C22DAD.0942A570-- From owner-ips@ece.cmu.edu Wed Jul 17 14:11:05 2002 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA25343 for ; Wed, 17 Jul 2002 14:11:05 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id g6HHY2O08254 for ips-outgoing; Wed, 17 Jul 2002 13:34:02 -0400 (EDT) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from lion.ninthwonder.com (lion.ninthwonder.com [151.199.66.147]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id g6HHY0X08250 for ; Wed, 17 Jul 2002 13:34:00 -0400 (EDT) Received: by lion.ninthwonder.com (Postfix, from userid 1021) id CB5D530706; Wed, 17 Jul 2002 13:33:56 -0400 (EDT) Date: Wed, 17 Jul 2002 10:30:56 -0700 (PDT) From: Bill Studenmund X-X-Sender: To: John Hufferd Cc: Julian Satran , "KRUEGER,MARJORIE (HP-Roseville,ex1)" , Subject: Re: iSCSI: v15 issue: iqn. name format inconsistencies In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ips@ece.cmu.edu Precedence: bulk On Wed, 17 Jul 2002, John Hufferd wrote: > You need to say: > > - An optional colon ":" While I think it'd be better to make the ":" mandatory, to do what you want I think the text should be '- Either a "." or a ":"' to indicate that one of the two is needed. :-) > A colon is optional and not required. Many organization will not need the > colon. > > And I would recommend > > iqn.2001-04.com.acme.storage:diskarrays-sn-a8675309 > iqn.2001-04.com.acme.storage:tape.sys1.xyz > iqn.2001-04.com.acme.storage.tape:sys1.xyz > iqn.2001-04.com.small.eng.storage.unit5 > > In this example the subdomain names that would otherwise conflict are > "storage" and "storage.tape" > The company called small has no possible conflicts and everything is > handled with a "." Take care, Bill From owner-ips@ece.cmu.edu Wed Jul 17 14:13:51 2002 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA25441 for ; Wed, 17 Jul 2002 14:13:50 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id g6HHfp608809 for ips-outgoing; Wed, 17 Jul 2002 13:41:51 -0400 (EDT) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from lion.ninthwonder.com (lion.ninthwonder.com [151.199.66.147]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id g6HHfnX08804 for ; Wed, 17 Jul 2002 13:41:49 -0400 (EDT) Received: by lion.ninthwonder.com (Postfix, from userid 1021) id C4A0030706; Wed, 17 Jul 2002 13:41:48 -0400 (EDT) Date: Wed, 17 Jul 2002 10:38:47 -0700 (PDT) From: Bill Studenmund X-X-Sender: To: Cc: , Subject: RE: iSCSI: Question about ErrorRecoveryLevel In-Reply-To: <277DD60FB639D511AC0400B0D068B71E0564C0A4@CORPMX14> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ips@ece.cmu.edu Precedence: bulk On Tue, 16 Jul 2002 Black_David@emc.com wrote: > One more clarification - in the meeting on Monday (report/results) > coming to the list shortly the rough consensus in the room was: > > - If an implementation wants to support only one of the mechanisms > required at ERL1, it's ok to negotiate ERL 0 (can't negotiate > 1 because that would require both mechanisms) and then try > the mechanism of interest, but the implementation MUST be prepared > for the attempt to fail because the other party doesn't support it. Thanks. That addresses the other half of my confusion. Take care, Bill From owner-ips@ece.cmu.edu Wed Jul 17 15:40:29 2002 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA28256 for ; Wed, 17 Jul 2002 15:40:24 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id g6HIuAB13783 for ips-outgoing; Wed, 17 Jul 2002 14:56:10 -0400 (EDT) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from palrel12.hp.com (palrel12.hp.com [156.153.255.237]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id g6HIu7X13776 for ; Wed, 17 Jul 2002 14:56:08 -0400 (EDT) Received: from xparelay1.corp.hp.com (xparelay1.corp.hp.com [15.58.136.173]) by palrel12.hp.com (Postfix) with ESMTP id C9F71E00EE3; Wed, 17 Jul 2002 11:56:03 -0700 (PDT) Received: from xpabh1.corp.hp.com (xpabh1.corp.hp.com [15.58.136.191]) by xparelay1.corp.hp.com (Postfix) with ESMTP id BB7EFE002D4; Wed, 17 Jul 2002 11:56:03 -0700 (PDT) Received: by xpabh1.corp.hp.com with Internet Mail Service (5.5.2655.55) id <3ZN9M1SG>; Wed, 17 Jul 2002 11:56:03 -0700 Message-ID: <6BD67FFB937FD411A04F00D0B74FE87805CCF6D2@xrose06.rose.hp.com> From: "KRUEGER,MARJORIE (HP-Roseville,ex1)" To: "'John Hufferd'" , "KRUEGER,MARJORIE (HP-Roseville,ex1)" Cc: "Ips Reflector (E-mail)" Subject: RE: iSCSI: v15 issue: iqn. name format inconsistencies Date: Wed, 17 Jul 2002 11:56:01 -0700 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2655.55) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-ips@ece.cmu.edu Precedence: bulk The reversed domain name is included in the name string for the purpose of identifying the naming authority. The intent of a colon separator after the domain name was so that the identified naming authority was clearly separable. It isn't appropriate (or at least interesting) to identify the companies' "sub-domain names" in the iSCSI names - they are NOT the names that are registered with the qualifying date field. Remember, this domain name string is NOT intended to have any meaning within the string other than identification of the naming authority - in the examples you have sited, the naming authority is ajax.com, NOT mother.ajax.com. Once the naming authority is identified, anything beyond the reversed-domain name MUST be guaranteed unique *by that naming authority*. Your intent seems to be to allow "sub-domain names" to be identified as naming authoritys - I think that's not appropriate, not necessary (and not particularly interesting to the other "naming authoritys"). If a particular naming authority (ajax.com) wants to use that scheme it's free to do so, but the responsible naming authority remains ONLY ajax.com. I think your examples should be: "com.ajax:mother:wonder.mydiskarray" and "com.ajax:mother.wonder:mydiskarray". Although I think these are bad examples because it is not advisable for ajax.com to construct a naming scheme using it's sub-domain names in that manner. A companies "sub-domain names" are typically organized in a manner to facilitate the IT operations of a company, not to separate the business units. Each company should construct a product naming scheme that makes sense for their product divisions - for instance, a company manufacturing both servers and storage might construct a naming scheme like: iqn.1999-05.com.widget:storagearray.product1. for their storage array division and iqn.1999-05.com.widget:server.fastestyet. for their server initiators. I stand by my original recommendation. Marjorie Krueger Networked Storage Architecture Networked Storage Solutions Hewlett-Packard > -----Original Message----- > From: John Hufferd [mailto:hufferd@us.ibm.com] > Sent: Wednesday, July 17, 2002 12:52 AM > To: KRUEGER,MARJORIE (HP-Roseville,ex1) > Cc: Ips Reflector (E-mail) > Subject: Re: iSCSI: v15 issue: iqn. name format inconsistencies > > > > Marjorie, > I think it is OK to make some of the example changes you have > indicated, > but it is not required to always use the ":" It depends on > the way your > company manages their sub domain names. It is still valid > to use an all > dotted name. > > The ":" was needed since a company can hand out subdomains > with names like > "mother" and "mother.wonder" to different departments and therefore it > would be possible for both departments to create a name like > "com.ajax.mother.wonder.mydiskarray". The use of ":" permits the > departments to make their names unique by placing the ":" > following their > subdomain portions. That is, they can use the same characters but > separated with a colon as follows > "com.ajax.mother:wonder.mydiskarray" and > "com.ajax.mother.wonder:mydiskarray". > > Therefore, I do not think that all examples should include a colon. > > . > . > . > John L. Hufferd > Senior Technical Staff Member (STSM) > IBM/SSG San Jose Ca > Main Office (408) 256-0403, Tie: 276-0403, eFax: (408) 904-4688 > Home Office (408) 997-6136, Cell: (408) 499-9702 > Internet address: hufferd@us.ibm.com > > > "KRUEGER,MARJORIE (HP-Roseville,ex1)" > @ece.cmu.edu > on 07/16/2002 02:44:37 PM > > Sent by: owner-ips@ece.cmu.edu > > > To: "Ips Reflector (E-mail)" > cc: > Subject: iSCSI: v15 issue: iqn. name format inconsistencies > > > > > > There is currently an inconsistency in the way iSCSI "iqn."-formatted > names are illustrated and described between the iSCSI > protocol document > and the iSCSI Naming and Discovery document.  In particular, > the separator > character between the reversed-domain name and the rest of > the string is > defined to be "." but some examples in the N&D document describe it as > ":". > > I remember discussion (among the N&D team) that this > separator should be > ":" in order to distinguish the reversed domain name from the > rest of the > string, but this got lost somewhere along the line.  If there are no > objections to changing this in the main draft, this > translates into changes > for both the iSCSI main draft and the N&D draft in cleaning up the > examples and making sure they are consistent (some use "." > and some use > ":"). > > Here are the changes I recommend to the main draft: > In section 2.2.6.3 > > >      The iSCSI qualified name string consists of: >        -  The string "iqn." >        -  A date code, in yyyy-mm format.  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.  This > date code >           uses the Gregorian calendar.  All four digits in > the year must >           be present.  Both digits of the month must be > present, with >           January == "01" and December == "12".  The dash must be >           included. >        -  A dot ".". >        -  The reversed domain name of the naming authority > (person or >           organization) creating this iSCSI name. >        -  A colon ":". >        -  Any string, within the character set and length > boundaries, >           that the owner of the domain name deems > appropriate.  This may >           contain product types, serial numbers, host > identifiers, soft- >           ware keys, or anything else that makes sense to > uniquely iden- >           tify the initiator or target.  Everything after "           domain name>:", can be assigned as desired by the owner of >           the domain name.  It is the responsibility of the > entity that >           is the naming authority to ensure that the iSCSI names it >           assigns are world wide unique. > >      For example, "ACME Storage Arrays, Inc.", might own the > domain name >      "acme.com". The following are examples of iSCSI > qualified names that >      might be generated by "ACME Storage Arrays, Inc." > >                     Organization >                         Naming     String defined by >           Type  Date     Auth      "acme.com" naming authority >           +--++-----+ +------+ +--------------------------------+ >           |  ||     | |      | | > >           iqn.2001-04.com.acme:storage.diskarrays-sn-a8675309 >           iqn.2001-04.com.acme:server.megafast900.i95874 > > In section 11.4 TargetName > >      Examples: > >        TargetName=iqn.1993-11.com.diskvendor:diskarrays.sn.45678 > > In section 11.5 InitiatorName > >      Examples: > >        InitiatorName=iqn.1992-04.com.osvendor:plan9.cdrom.12345 >        InitiatorName=iqn.2001-02.com.ssp:users.customer235.host90 > > text, as it's > invalid> > > In appendix > >      In the first example, the initiator and target authenticate each > other >      via Kerberos: > >        I-> Login (CSG,NSG=0,1 T=1) >            InitiatorName=iqn.1999-07.com.os:hostid.77 >            TargetName=iqn.1999-07.com.acme:diskarray.sn.88 >            AuthMethod=KRB5,SRP,None > > etc - all these Login examples that contain iSCSI names need > to be fixed. > > In appendix > >      Target sends a text response that contains: > >        TargetName=iqn.1993-11.com.acme:diskarray.sn.8675309 > > etc - all TargetName examples need to be fixed. > > Several examples in the Naming and Discovery draft need to > be fixed - I'll > address that in a separate email. > > Marjorie Krueger > Networked Storage Architecture > Networked Storage Solutions > Hewlett-Packard > > > > > From owner-ips@ece.cmu.edu Wed Jul 17 15:45:04 2002 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA28322 for ; Wed, 17 Jul 2002 15:44:54 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id g6HJ5Us14482 for ips-outgoing; Wed, 17 Jul 2002 15:05:30 -0400 (EDT) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from atlrel6.hp.com (atlrel6.hp.com [156.153.255.205]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id g6HJ5SX14477 for ; Wed, 17 Jul 2002 15:05:28 -0400 (EDT) Received: from xatlrelay2.atl.hp.com (xatlrelay2.atl.hp.com [15.45.89.191]) by atlrel6.hp.com (Postfix) with ESMTP id B77DA3E1; Wed, 17 Jul 2002 15:05:27 -0400 (EDT) Received: from xatlbh2.atl.hp.com (xatlbh2.atl.hp.com [15.45.89.187]) by xatlrelay2.atl.hp.com (Postfix) with ESMTP id A4A824000B1; Wed, 17 Jul 2002 15:05:27 -0400 (EDT) Received: by xatlbh2.atl.hp.com with Internet Mail Service (5.5.2655.55) id ; Wed, 17 Jul 2002 15:05:27 -0400 Message-ID: <6BD67FFB937FD411A04F00D0B74FE87805CCF6D3@xrose06.rose.hp.com> From: "KRUEGER,MARJORIE (HP-Roseville,ex1)" To: "'Julian Satran'" Cc: ips@ece.cmu.edu Subject: RE: iSCSI: v15 issue: iqn. name format inconsistencies Date: Wed, 17 Jul 2002 15:05:19 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2655.55) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C22DC4.E4BC49A0" Sender: owner-ips@ece.cmu.edu Precedence: bulk This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_001_01C22DC4.E4BC49A0 Content-Type: text/plain; charset="iso-8859-1" A few minor corrections: -----Original Message----- From: Julian Satran [mailto:Julian_Satran@il.ibm.com] Sent: Wednesday, July 17, 2002 1:14 AM To: KRUEGER,MARJORIE (HP-Roseville,ex1) Cc: ips@ece.cmu.edu Subject: Re: iSCSI: v15 issue: iqn. name format inconsistencies Marjorie, Here is a differential. Please check (fast!). Julo Type "iqn." (iSCSI Qualified Name) This iSCSI name type can be used by any organization which owns a domain name. This naming format is useful when an end user or ser-vice provider wishes to assign iSCSI names for targets and/or initia-tors. To generate names of this type, the person or organization generat-ing the name must own a DNS domain name. This domain name does not ^^^^^ delete DNS, substitute "registered" have to be active, and does not have to resolve to an address; it just needs to be reserved to prevent others from generating iSCSI names using the same domain name. Because a domain name can expire, be acquired by another entity, and might be used to generate iSCSI names by both owners, the domain name must be additionally qualified by a date during which the naming authority owned the domain name. A date code is provided as part of the "iqn." format for this reason. The iSCSI qualified name string consists of: - The string "iqn.", used to distinguish these names from "eui." formatted names. - A date code, in yyyy-mm format. This date MUST be a date dur-ing which the naming authority owned the domain name used in this format, and SHOULD be the first month in which the domain name was owned by this naming authority at 00:01 GMT of the first day of the month. This date code uses the Grego-rian calendar. All four digits in the year must be present. Both digits of the month must be present, with January == "01" and December == "12". The dash must be included. - A dot ".". ^^^ remove the trailing period, it might be confusing - The reversed domain name of the naming authority (person or organization) creating this iSCSI name. - A colon ":". ^^^ remove the trailing period, it might be confusing - Any string, within the character set and length boundaries, that the owner of the domain name deems appropriate. This may contain product types, serial numbers, host identifiers, software keys, or anything else that makes sense to uniquely identify the initiator or target. Everything after the reversed domain name, followed by colon ":", can be assigned as desired by the owner of the domain name. It is the respon-sibility of the entity that is the naming authority to ensure that the iSCSI names it assigns are worldwide unique. For example, "ACME Storage Arrays, Inc.", might own the domain name "acme.com". The following are examples of iSCSI qualified names that might be generated by "ACME Storage Arrays, Inc." /begin delete Organization Subgroup Naming Authority Naming and/or string defined by Type Date Auth "acme.com" Naming Authority +--++-----+ +------+ +--------------------------------+ | || | | | | | iqn.2001-04.com.acme:storage.diskarrays-sn-a8675309 iqn.2001-04.com.acme:storage.tape.sys1.xyz iqn.2001-04.com.acme:storage.tape.sys1.xyz /replace with Naming String defined by Type Date Auth "acme.com" naming authority +--++-----+ +------+ +--------------------------------+ | || | | | | | iqn.2001-04.com.acme:storage.diskarrays-sn-a8675309 iqn.2001-04.com.acme:server.megafast900.i95874 "KRUEGER,MARJORIE (HP-Roseville,ex1)" Sent by: owner-ips@ece.cmu.edu 07/17/2002 12:44 AM To: "Ips Reflector (E-mail)" cc: Subject: iSCSI: v15 issue: iqn. name format inconsistencies There is currently an inconsistency in the way iSCSI "iqn."-formatted names are illustrated and described between the iSCSI protocol document and the iSCSI Naming and Discovery document. In particular, the separator character between the reversed-domain name and the rest of the string is defined to be "." but some examples in the N&D document describe it as ":". I remember discussion (among the N&D team) that this separator should be ":" in order to distinguish the reversed domain name from the rest of the string, but this got lost somewhere along the line. If there are no objections to changing this in the main draft, this translates into changes for both the iSCSI main draft and the N&D draft in cleaning up the examples and making sure they are consistent (some use "." and some use ":"). Here are the changes I recommend to the main draft: In section 2.2.6.3 The iSCSI qualified name string consists of: - The string "iqn." - A date code, in yyyy-mm format. 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. This date code uses the Gregorian calendar. All four digits in the year must be present. Both digits of the month must be present, with January == "01" and December == "12". The dash must be included. - A dot ".". - The reversed domain name of the naming authority (person or organization) creating this iSCSI name. - A colon ":". - Any string, within the character set and length boundaries, that the owner of the domain name deems appropriate. This may contain product types, serial numbers, host identifiers, soft- ware keys, or anything else that makes sense to uniquely iden- tify the initiator or target. Everything after ":", can be assigned as desired by the owner of the domain name. It is the responsibility of the entity that is the naming authority to ensure that the iSCSI names it assigns are world wide unique. For example, "ACME Storage Arrays, Inc.", might own the domain name "acme.com". The following are examples of iSCSI qualified names that might be generated by "ACME Storage Arrays, Inc." Organization Naming String defined by Type Date Auth "acme.com" naming authority +--++-----+ +------+ +--------------------------------+ | || | | | | | iqn.2001-04.com.acme:storage.diskarrays-sn-a8675309 iqn.2001-04.com.acme:server.megafast900.i95874 In section 11.4 TargetName Examples: TargetName=iqn.1993-11.com.diskvendor:diskarrays.sn.45678 In section 11.5 InitiatorName Examples: InitiatorName=iqn.1992-04.com.osvendor:plan9.cdrom.12345 InitiatorName=iqn.2001-02.com.ssp:users.customer235.host90 In appendix C In the first example, the initiator and target authenticate each other via Kerberos: I-> Login (CSG,NSG=0,1 T=1) InitiatorName=iqn.1999-07.com.os:hostid.77 TargetName=iqn.1999-07.com.acme:diskarray.sn.88 AuthMethod=KRB5,SRP,None etc - all these Login examples that contain iSCSI names need to be fixed. In appendix D Target sends a text response that contains: TargetName=iqn.1993-11.com.acme:diskarray.sn.8675309 etc - all TargetName examples need to be fixed. Several examples in the Naming and Discovery draft need to be fixed - I'll address that in a separate email. Marjorie Krueger Networked Storage Architecture Networked Storage Solutions Hewlett-Packard ------_=_NextPart_001_01C22DC4.E4BC49A0 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
A few minor corrections:
 
-----Original Message-----
From: Julian Satran=20 [mailto:Julian_Satran@il.ibm.com]
Sent: Wednesday, July 17, = 2002=20 1:14 AM
To: KRUEGER,MARJORIE = (HP-Roseville,ex1)
Cc:=20 ips@ece.cmu.edu
Subject: Re: iSCSI: v15 issue: iqn. name = format=20 inconsistencies


Marjorie,

Here is a=20 differential.
Please = check=20 (fast!).

Julo =

Type "iqn." (iSCSI Qualified Name) =

This iSCSI name type can be = used by any=20 organization which owns a domain name. This naming format is useful = when an=20 end user or ser-vice provider wishes to assign iSCSI names for = targets and/or=20 initia-tors.

To = generate names=20 of this type, the person or organization generat-ing the name must = own a DNS=20 domain name. This domain name does not 

       &nb= sp;           &nb= sp; =20 ^^^^^ delete DNS, substitute=20 "registered"

  have to be active, and does = not have to=20 resolve to an address; it just needs to be reserved to prevent others = from=20 generating iSCSI names using the same domain name. =

Because a domain name can expire, be = acquired by=20 another entity, and might be used to generate iSCSI names by both = owners, the=20 domain name must be additionally qualified by a date during which the = naming=20 authority owned the domain name. A date code is provided as part of = the "iqn."=20 format for this reason.

The=20 iSCSI qualified name string consists of:

- The string "iqn.", used to = distinguish these names=20 from "eui." formatted names.
- A=20 date code, in yyyy-mm format. This date MUST be a date dur-ing which = the=20 naming authority owned the domain name used in this format, and = SHOULD be the=20 first month in which the domain name was owned by this naming = authority at=20 00:01 GMT of the first day of the month. This date code uses the = Grego-rian=20 calendar. All four digits in the year must be present. Both digits of = the=20 month must be present, with January =3D=3D "01" and December =3D=3D = "12". The dash=20 must be included.
- A = dot ".". 

          &= nbsp; =20 ^^^ remove the trailing period, it might be=20 confusing    

- The reversed domain name of = the naming=20 authority (person or organization) creating this iSCSI name. =
- A colon ":".  

          &nb= sp;   =20 ^^^ remove the trailing period, it might be=20 confusing  

 - Any string, within the character set and length = boundaries, that the=20 owner of the domain name deems appropriate. This may contain product = types,=20 serial numbers, host identifiers, software keys, or anything else = that makes=20 sense to uniquely identify the initiator or target. Everything after = the=20 reversed domain name, followed by colon ":", can be assigned as = desired by the=20 owner of the domain name. It is the respon-sibility of the entity = that is the=20 naming authority to ensure that the iSCSI names it assigns are = worldwide=20 unique. For example, "ACME Storage Arrays, Inc.", might own the = domain name=20 "acme.com".
 
The following are examples of iSCSI = qualified names=20 that might be
generated by "ACME=20 Storage Arrays, Inc."  

/begin delete 
          &nb= sp;     
          = Organization=20    Subgroup Naming Authority
              Naming =    =20  and/or string defined by
Type=20  Date     Auth       "acme.com" Naming = Authority=20
+--++-----+ +------+=20 +--------------------------------+
|  ||     | |      | |   =  =20                     =  =20      |
 =20
iqn.2001-04.com.acme:storage.diskarrays-sn-a8675309 =
iqn.2001-04.com.acme:storage.tape.sys1.xyz=20
iqn.2001-04.com.acme:storage.tape.sys1.xyz  

/replace with

       =         Naming=20     String defined by
 Type  Date     = Auth  =20    "acme.com" naming authority
 +--++-----+=20 +------+ +--------------------------------+
 |  ||=20     | |      | |         =  =20                     =  | 
          
 iqn.2001-04.com.acme:storage.diskarr= ays-sn-a8675309
 iqn.2001-04.com.acme:server.megafast= 900.i95874

"KRUEGER,MARJORIE=20 (HP-Roseville,ex1)" <marjorie_krueger@hp.com> =
Sent by: = owner-ips@ece.cmu.edu=20

07/17/2002 12:44 AM =

        =
        To: =    =20    "Ips Reflector (E-mail)" = <ips@ece.cmu.edu>=20
      =   cc:  =20      
 =20       Subject:        iSCSI: = v15=20 issue: iqn. name format inconsistencies

      =  



There is currently = an=20 inconsistency in the way iSCSI "iqn."-formatted names are illustrated = and=20 described between the iSCSI protocol document and the iSCSI Naming = and=20 Discovery document.  In particular, the separator character = between the=20 reversed-domain name and the rest of the string is defined to be "." = but some=20 examples in the N&D document describe it as ":".

I = remember=20 discussion (among the N&D team) that this separator should be ":" = in order=20 to distinguish the reversed domain name from the rest of the string, = but this=20 got lost somewhere along the line.  If there are no objections = to=20 changing this in the main draft, this translates into changes for = both the=20 iSCSI main draft and the N&D draft in cleaning up the examples = and making=20 sure they are consistent (some use "." and some use ":").

Here = are the=20 changes I recommend to the main draft:
In section 2.2.6.3


    The=20 iSCSI qualified name string consists of:
      - =  The=20 string "iqn."
      -  A date code, in yyyy-mm = format.=20  This date MUST be a date
        =  during=20 which the naming authority owned the domain name used
  =    =20    in this format, and SHOULD be the date on which the=20 domain
         name was acquired by this = naming=20 authority.  This date code
        =  uses the=20 Gregorian calendar.  All four digits in the year must
  =  =20      be present.  Both digits of the month must = be=20 present, with
         January =3D=3D = "01" and=20 December =3D=3D "12".  The dash must be
      =  =20  included.
      -  A dot ".".
  =  =20   -  The reversed domain name of the naming authority = (person=20 or
         organization) creating this = iSCSI=20 name.
      -  A colon ":".
    =   -=20  Any string, within the character set and length = boundaries,
 =20        that the owner of the domain name deems=20 appropriate.  This may
        =  contain=20 product types, serial numbers, host identifiers, soft-
  =    =20    ware keys, or anything else that makes sense to uniquely = iden-
         tify the initiator or = target.=20  Everything after "<reversed
       =20  domain name>:", can be assigned as desired by the owner = of
 =20        the domain name.  It is the = responsibility of=20 the entity that
         is the naming = authority=20 to ensure that the iSCSI names it
        =  assigns=20 are world wide unique.

    For example, "ACME = Storage Arrays,=20 Inc.", might own the domain name
    "acme.com". The = following=20 are examples of iSCSI qualified names that
    might be = generated=20 by "ACME Storage Arrays, Inc."
          =  =20      
            =  =20      Organization  
      =    =20              Naming     = String=20 defined by
         Type  Date =    =20 Auth      "acme.com" naming authority
    =  =20    +--++-----+ +------+ = +--------------------------------+
 =20        |  ||     | |     =  |=20 |                   =    =20          |
         
      =  =20  iqn.2001-04.com.acme:storage.diskarrays-sn-a8675309
  =  =20     =  iqn.2001-04.com.acme:server.megafast900.i95874

In section 11.4 TargetName

    Examples:

     =20 = TargetName=3Diqn.1993-11.com.diskvendor:diskarrays.sn.45678

In section 11.5 InitiatorName

    Examples:

     =20 InitiatorName=3Diqn.1992-04.com.osvendor:plan9.cdrom.12345
  =  =20   = InitiatorName=3Diqn.2001-02.com.ssp:users.customer235.host90

<Julian, make sure to delete the last = example in the=20 current text, as it's invalid>

In=20 appendix C

    In the first example, = the=20 initiator and target authenticate each other
    via=20 Kerberos:

      I-> Login (CSG,NSG=3D0,1 = T=3D1)
 =20        =20 InitiatorName=3Diqn.1999-07.com.os:hostid.77
      =  =20   TargetName=3Diqn.1999-07.com.acme:diskarray.sn.88
  =    =20     AuthMethod=3DKRB5,SRP,None

etc - all=20 these Login examples that contain iSCSI names need to be = fixed.

In=20 appendix D

    Target sends a text = response that=20 contains:

     =20 TargetName=3Diqn.1993-11.com.acme:diskarray.sn.8675309

etc - all TargetName examples need to be=20 fixed.

Several = examples in=20 the Naming and Discovery draft need to be fixed - I'll address that = in a=20 separate email.
   
Marjorie Krueger
Networked = Storage=20 Architecture
Networked Storage Solutions
Hewlett-Packard=20

------_=_NextPart_001_01C22DC4.E4BC49A0-- From owner-ips@ece.cmu.edu Wed Jul 17 17:54:06 2002 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA00803 for ; Wed, 17 Jul 2002 17:54:06 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id g6HLEBk22439 for ips-outgoing; Wed, 17 Jul 2002 17:14:11 -0400 (EDT) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from lion.ninthwonder.com (lion.ninthwonder.com [151.199.66.147]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id g6HLE9X22434 for ; Wed, 17 Jul 2002 17:14:09 -0400 (EDT) Received: by lion.ninthwonder.com (Postfix, from userid 1021) id 4CA8B30706; Wed, 17 Jul 2002 17:14:09 -0400 (EDT) Date: Wed, 17 Jul 2002 14:11:08 -0700 (PDT) From: Bill Studenmund X-X-Sender: To: Subject: How do you negotiate a numerical range? Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ips@ece.cmu.edu Precedence: bulk I think I know the answer, but wanted to double check as AFAICT all the numbers we have in the spec are either MIN or MAX; I suspect not much code is using numerical ranges at the moment. Also, the spec doesn't say anything about negotiating ranges AFAICT. :-) Question 1: Since all of the numbers we have are MIN or MAX, my understanding is that you just take the min or max of the range, and use that for negotiation. The initially-non-intuitive thing is that you can readily get a negotiated value outside of the offered range. :-) Consider an offer of "MaxConnections=3~10" to a device that wants MaxConnections=2. Since MaxConnections is a MIN number, the correct response (I believe) is "MaxConnections=2". I suspect however this might seem counter-intuitive for new implementers. Question 2: Say you have a number that is not a MIN or MAX number (right now this'd be a vendor-specific one), and you are offered a range (say "Foo=3~12"), and had you made the offer you would have offered a different range (say "Foo=10~16"). Do we want to say anything now about how to handle this negotiation, or do we want to wait until we actually have a non-MIN/MAX number in the spec? I'd vote holding off, and just having everyone understand there will be more work for some future version. :-) Thoughts? Take care, Bill From owner-ips@ece.cmu.edu Wed Jul 17 20:03:04 2002 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA02993 for ; Wed, 17 Jul 2002 20:02:59 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id g6HNFtt29094 for ips-outgoing; Wed, 17 Jul 2002 19:15:55 -0400 (EDT) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from hotmail.com (f150.pav2.hotmail.com [64.4.37.150]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id g6HMgGX27570 for ; Wed, 17 Jul 2002 18:42:16 -0400 (EDT) Received: from mail pickup service by hotmail.com with Microsoft SMTPSVC; Wed, 17 Jul 2002 15:42:10 -0700 Received: from 129.219.25.77 by pv2fd.pav2.hotmail.msn.com with HTTP; Wed, 17 Jul 2002 22:42:10 GMT X-Originating-IP: [129.219.25.77] From: "shesha bhushan" To: ips@ece.cmu.edu Cc: rdr@iol.unh.edu Subject: TUR and commands hence forth are not sent. Date: Wed, 17 Jul 2002 22:42:10 +0000 Mime-Version: 1.0 Content-Type: text/plain; format=flowed Message-ID: X-OriginalArrivalTime: 17 Jul 2002 22:42:10.0363 (UTC) FILETIME=[2FDCF0B0:01C22DE3] Sender: owner-ips@ece.cmu.edu Precedence: bulk /sbin/insmod -f iscsi_initiator.o ../common/iscsi_manage init set TargetName=enpc3486.eas.asu.edu InitiatorName=dummy.com host=1 ./iscsi_config up ip=129.xxx.xx.xxx host=1 ================== TARGET ================== insmod scsi_target.o insmod iscsi_target.o The messages in the /var/log/messages says that only Inquiry Command is sent. But according to the README, the SCSI sub system must also send TUR, ReadCapacity and Read. Please let us know what is the problem. For your refference I have the trace of /var/log/messages of both Initiator and Target. Thanks Shesha ================================================= INITIATOR TRACE ================================================= Jul 17 14:46:09 localhost kernel: 310: registered iSCSI host d4e8d4e0, host number 1 Jul 17 14:46:09 localhost kernel: scsi1 : UNH-IOL iSCSI reference initiator Jul 17 14:46:09 localhost kernel: iscsi: Target 0 not logged in Jul 17 14:46:09 localhost kernel: iscsi: Target 1 not logged in Jul 17 14:46:09 localhost kernel: iscsi: Target 2 not logged in Jul 17 14:46:09 localhost kernel: iscsi: Target 3 not logged in Jul 17 14:46:09 localhost kernel: 3365: iSCSI write to proc_info (56): iscsi_initiator manage 8 TargetName=enpc3486.eas.asu.edu Jul 17 14:46:09 localhost kernel: 3365: iSCSI write to proc_info (48): iscsi_initiator manage 8 InitiatorName=dummy.com Jul 17 14:46:09 localhost kernel: 3365: iSCSI write to proc_info (63): iscsi_initiator ip 0x81db194d port 3260 target 0 lun 0x00000000 Jul 17 14:46:09 localhost kernel: 3028: Create session db4172e0 Jul 17 14:46:09 localhost kernel: 2978: Create connection db4170e0 Jul 17 14:46:09 localhost kernel: 2837: Create socket d4474b84 Jul 17 14:46:09 localhost kernel: iscsi: Connected to 129.219.25.77:3260 Jul 17 14:46:09 localhost kernel: 3009: Attach key: TargetName=enpc3486.eas.asu.edu Jul 17 14:46:09 localhost kernel: 3009: Attach key: InitiatorName=dummy.com Jul 17 14:46:09 localhost kernel: 523: Send Login Jul 17 14:46:09 localhost kernel: 243: Got Login Response Jul 17 14:46:09 localhost kernel: 864: rx_thread starting, connection db4170e0 Jul 17 14:46:09 localhost kernel: 885: rx_thread started Jul 17 14:46:09 localhost kernel: 621: tx_thread starting, session db4172e0 Jul 17 14:46:09 localhost kernel: 642: tx_thread started Jul 17 14:46:09 localhost kernel: 3063: Enter normal session Full Feature Phase Jul 17 14:46:09 localhost kernel: scsi singledevice 1 0 0 0 Jul 17 14:46:09 localhost kernel: 2598: Send SCSI INQUIRY, ITT 88889, 48 bytes 1 iovs Jul 17 14:46:09 localhost kernel: 1275: Got DataIn Hdr Jul 17 14:46:09 localhost kernel: 803: Got 256 data, pad and crc bytes Jul 17 14:46:10 localhost kernel: 2146: Got SCSI Rsp Hdr Jul 17 14:46:10 localhost kernel: 564: Underflow: Residual count 0 Jul 17 14:46:10 localhost kernel: Vendor: QUANTUM Model: ATLAS V 9 SCA Rev: 0201 Jul 17 14:46:10 localhost kernel: Type: Direct-Access ANSI SCSI revision: 03 ================================================= TARGET TRACE ================================================= Jul 17 14:34:59 enpc3486 kernel: 745: Starting iscsi_tx_1 Jul 17 14:34:59 enpc3486 kernel: 03 87 00 00 00 00 00 38 80 12 34 56 78 9a 00 00 00 01 5b 38 00 0a 00 00 00 Jul 17 14:34:59 enpc3486 kernel: 00 56 ce 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 Jul 17 14:34:59 enpc3486 kernel: Opcode: 0x03, I: 0 Jul 17 14:34:59 enpc3486 kernel: flags: 0x87 Jul 17 14:34:59 enpc3486 kernel: VersionMax: 0x00 Jul 17 14:34:59 enpc3486 kernel: VersionMin: 0x00 Jul 17 14:34:59 enpc3486 kernel: DSL: 56 Jul 17 14:34:59 enpc3486 kernel: ISID: 0x80 12 34 56 78 9a Jul 17 14:34:59 enpc3486 kernel: TSID: 0 Jul 17 14:34:59 enpc3486 kernel: ITT: 88888 Jul 17 14:34:59 enpc3486 kernel: CID: 10 Jul 17 14:34:59 enpc3486 kernel: CmdSN: 22222 Jul 17 14:34:59 enpc3486 kernel: 1177: handle_login: A new session started for 149.169.43.193 Jul 17 14:34:59 enpc3486 kernel: 1287: Got key: TargetName=enpc3486.eas.asu.edu Jul 17 14:34:59 enpc3486 kernel: 1287: Got key: InitiatorName=dummy.com Jul 17 14:34:59 enpc3486 kernel: 1699: Send Login Response Jul 17 14:34:59 enpc3486 kernel: 01 c0 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 01 5b 39 00 00 01 00 00 Jul 17 14:34:59 enpc3486 kernel: 00 56 ce 00 00 00 02 12 00 00 00 ff 00 00 00 00 00 00 00 00 00 00 00 Jul 17 14:34:59 enpc3486 kernel: Opcode: 0x01, I: 0 Jul 17 14:34:59 enpc3486 kernel: flags: 0xc0 Jul 17 14:34:59 enpc3486 kernel: ITT: 88889 Jul 17 14:34:59 enpc3486 kernel: EDTL: 256 Jul 17 14:34:59 enpc3486 kernel: CmdSN: 22222 Jul 17 14:34:59 enpc3486 kernel: ExpStatSN: 2 Jul 17 14:34:59 enpc3486 kernel: CDB: 0x12 00 00 00 ff 00 00 00 00 00 00 00 00 00 00 00 ======================================================= _________________________________________________________________ MSN Photos is the easiest way to share and print your photos: http://photos.msn.com/support/worldwide.aspx From owner-ips@ece.cmu.edu Wed Jul 17 20:31:03 2002 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA03787 for ; Wed, 17 Jul 2002 20:31:03 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id g6HNqHc00680 for ips-outgoing; Wed, 17 Jul 2002 19:52:17 -0400 (EDT) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from ztxmail04.ztx.compaq.com (ztxmail04.ztx.compaq.com [161.114.1.208]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id g6HNqEX00675 for ; Wed, 17 Jul 2002 19:52:14 -0400 (EDT) Received: from cceexg11.americas.cpqcorp.net (cceexg11.americas.cpqcorp.net [16.110.250.125]) by ztxmail04.ztx.compaq.com (Postfix) with ESMTP id 172FE36F7; Wed, 17 Jul 2002 18:52:09 -0500 (CDT) Received: from cceexc18.americas.cpqcorp.net ([16.110.250.64]) by cceexg11.americas.cpqcorp.net with Microsoft SMTPSVC(5.0.2195.2966); Wed, 17 Jul 2002 18:52:08 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.0.5762.3 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Subject: RE: How do you negotiate a numerical range? Date: Wed, 17 Jul 2002 18:52:08 -0500 Message-ID: <31891B757C09184BBFEC5275F85D5595104EAA@cceexc18.americas.cpqcorp.net> Thread-Topic: How do you negotiate a numerical range? Thread-Index: AcIt11EhEn9LBQWUQHmmra9h9MOR2wACr10g From: "Martin, Nick (Server Storage)" To: "Bill Studenmund" , X-OriginalArrivalTime: 17 Jul 2002 23:52:08.0656 (UTC) FILETIME=[F63D9D00:01C22DEC] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ece.cmu.edu id g6HNqFX00676 Sender: owner-ips@ece.cmu.edu Precedence: bulk Content-Transfer-Encoding: 8bit Bill, I agree that there could be more to do if/when we need ranges. Ranges are not allowed unless specifically stated for a particular key. From working draft 15: "The value offered or declared can be a numerical-value, a numericalrange defined by lower and upper value with both integers separated by tilde, a binary value, a text-value, a iSCSI-name-value, an iSCSIlocal- name-value, a boolean-value (Yes or No), or a list of comma separated text-values. A range or a large-numerical-value MAY ONLY be offered if it is explicitly allowed for a key. An iSCSI-name-value and an iSCSI-local-name-value can be used only where explicitly allowed. A selected value can be an numerical-value, a large-numerical- value, a text-value or a boolean-value." I disagree with your conclusion in Question 1. Offering a range for this particular key is an error. However presuming for a moment that a range is allowed for the key in the example, I think this must result in a negotiation failure for this key and login may fail. As I read you example, the responder seems to support the range 2~2 which has no values in common with 3~10. Responding with 2 is a protocol violation. The correct response would be "Reject". If a key which requires a single numeric result allows a range to be offered, a value within the offered range must be selected. Responding with a value outside the offered range would be a protocol violation. If such a key has a MIN or MAX rule, this should specify whether the largest or smallest value common between the range offered and the range supported by the responder should be selected. If 3~10 is offered, and 2~6 is supported by the responder, then the result with a MIN rule would be 3 and the result with a MAX rule would be 6. If there is neither a MIN nor MAX rule then 3, 4, 5, and 6 are all valid responses (implementer's choice). This is intuitive, but would perhaps need to be clearly stated to prevent other interpretation. I could envision a key which requires a range as the result. In this case the rule for the result might be the INTERSECTION of the range offered that the responder also supports. Thus for an offer of 4~20 the responses 4~8, 5~10, and 10~20 could each be valid depending on the supported range of the responder, but 2~4, 15~25, and 25~30 are all invalid responses because they include values outside the offered range. There could also be a rule called UNION, but I have trouble imagining a use for it in negotiations. As I read the excerpt above, keys which require a range as a result are currently prohibited. If non-intuitive results such as you describe in Question 1 were not already prohibited, then IMHO the spec would require revision. Thanks, Nick > -----Original Message----- > From: Bill Studenmund [mailto:wrstuden@wasabisystems.com] > Sent: Wednesday, July 17, 2002 4:11 PM > To: ips@ece.cmu.edu > Subject: How do you negotiate a numerical range? > > > I think I know the answer, but wanted to double check as > AFAICT all the > numbers we have in the spec are either MIN or MAX; I suspect > not much code > is using numerical ranges at the moment. Also, the spec doesn't say > anything about negotiating ranges AFAICT. :-) > > Question 1: > > Since all of the numbers we have are MIN or MAX, my > understanding is that > you just take the min or max of the range, and use that for > negotiation. > > The initially-non-intuitive thing is that you can readily get > a negotiated > value outside of the offered range. :-) > > Consider an offer of "MaxConnections=3~10" to a device that wants > MaxConnections=2. Since MaxConnections is a MIN number, the correct > response (I believe) is "MaxConnections=2". I suspect however > this might > seem counter-intuitive for new implementers. > > Question 2: > > Say you have a number that is not a MIN or MAX number (right > now this'd be > a vendor-specific one), and you are offered a range (say > "Foo=3~12"), and > had you made the offer you would have offered a different range (say > "Foo=10~16"). Do we want to say anything now about how to handle this > negotiation, or do we want to wait until we actually have a > non-MIN/MAX > number in the spec? > > I'd vote holding off, and just having everyone understand > there will be > more work for some future version. :-) > > Thoughts? > > Take care, > > Bill > > From owner-ips@ece.cmu.edu Wed Jul 17 22:07:50 2002 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA06900 for ; Wed, 17 Jul 2002 22:07:49 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id g6I1jBT05465 for ips-outgoing; Wed, 17 Jul 2002 21:45:11 -0400 (EDT) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from mailhub.lss.emc.com (xdch.emc.com [168.159.1.79]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id g6I1jAX05461 for ; Wed, 17 Jul 2002 21:45:10 -0400 (EDT) Received: from emc.com (emcmail.lss.emc.com [168.159.48.78]) by mailhub.lss.emc.com (Switch-2.2.0/Switch-2.2.0) with ESMTP id g6I1j1N23583; Wed, 17 Jul 2002 21:45:01 -0400 (EDT) Received: from mxic1.isus.emc.com ([168.159.129.100]) by emc.com (8.10.1/8.10.1) with ESMTP id g6I1j0716791; Wed, 17 Jul 2002 21:45:00 -0400 (EDT) Received: by MXIC1 with Internet Mail Service (5.5.2653.19) id <31WAQG9Z>; Wed, 17 Jul 2002 21:42:56 -0400 Message-ID: <277DD60FB639D511AC0400B0D068B71E0564C0B1@CORPMX14> From: Black_David@emc.com To: wrstuden@wasabisystems.com Cc: ips@ece.cmu.edu Subject: RE: Question about ErrorRecoveryLevel Date: Wed, 17 Jul 2002 21:42:52 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-ips@ece.cmu.edu Precedence: bulk > > > I have a question about within-command and within-connection recovery and > > > ErrorRecoveryLevel. Mainly what does ErrorRecoveryLevel 1 imply. I think > > > the answer is that it implies either one (or both) of within-command and > > > within-connection recovery methods are supported. Is that correct? > > > > > > i.e. A, B, or A & B. ? > > > > A & B is correct . > > > > Error RecoveryLevel 1 implies Digest failure recovery. > > > > Digest failure recovery is consist of two recovery classes, > > Within-Connection recovery class and Within-Command recovery class. > > Well, besides the grammar error you're quoting from the spec, that quote > doesn't answer the question. That text essentially gave rise to my > question. :-) > > Every where within-command and within-connection recovery is discussed, > each of them is described as optional. The quote above doesn't say that > level 1 MUST consist of both within-connection and within-command > recovery. -15 will contain text that will say this. 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 --------------------------------------------------- From owner-ips@ece.cmu.edu Wed Jul 17 22:08:00 2002 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA06914 for ; Wed, 17 Jul 2002 22:07:55 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id g6I1wsF06027 for ips-outgoing; Wed, 17 Jul 2002 21:58:54 -0400 (EDT) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from mailhub.lss.emc.com (xdch.emc.com [168.159.1.79]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id g6I1wqX06021 for ; Wed, 17 Jul 2002 21:58:52 -0400 (EDT) Received: from emc.com (emcmail.lss.emc.com [168.159.48.78]) by mailhub.lss.emc.com (Switch-2.2.0/Switch-2.2.0) with ESMTP id g6I1wgN26901; Wed, 17 Jul 2002 21:58:42 -0400 (EDT) Received: from mxic1.isus.emc.com ([168.159.129.100]) by emc.com (8.10.1/8.10.1) with ESMTP id g6I1wf717807; Wed, 17 Jul 2002 21:58:41 -0400 (EDT) Received: by MXIC1 with Internet Mail Service (5.5.2653.19) id <31WAQHHQ>; Wed, 17 Jul 2002 21:56:37 -0400 Message-ID: <277DD60FB639D511AC0400B0D068B71E0564C0B2@CORPMX14> From: Black_David@emc.com To: eddy_quicksall@ivivity.com Cc: ips@ece.cmu.edu Subject: RE: iSCSI: freeing resources during data-in and r2t Date: Wed, 17 Jul 2002 21:56:33 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C22DFE.57CA1600" Sender: owner-ips@ece.cmu.edu Precedence: bulk This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_001_01C22DFE.57CA1600 Content-Type: text/plain; charset="iso-8859-1" Eddy, The A bit in Data-In plus Data ACK (SNACK type 2 in -14, Julian's renumbering of the SNACK types in the working version of -15 is/will be/has been undone) already provides the intermediate resource freeing for Data-In. This is only available for ErrorRecoveryLevel >= 1 We've never thought that R2Ts would consume enough resources to be worth putting in support for intermediate resource freeing of them. Adding another sequence number at this late date to deal with a "slight inefficiency" when the A bit is used properly (SNACK-Data ACK PDUs vs. a piggybacked count) does not seem like a good idea. Thanks, --David -----Original Message----- From: Eddy Quicksall [mailto:eddy_quicksall@ivivity.com] Sent: Wednesday, July 17, 2002 12:15 PM To: Mallikarjun C. (E-mail) Cc: ips@ece. cmu. edu (E-mail) Subject: RE: iSCSI: freeing resources during data-in and r2t I think see a slight inefficiency in how resources are freed when multiple data-in and r2t's PDU's are used when ErrorRecoverLevel > 0 or TCP ACK is not available to the iSCSI layer. Data-in and R2T's use DataSN and R2TSN. To free those resources, ExpStatSN is used. But if several R2T's and/or Data-in PDU's were used, resources used for those PDU's are tied up for the entire command. Since other commands could be received during this time, it would be nice if those commands could contain information that would tell the target that the R2T and/or Data-in PDU's have been received. I know a radical change at this point is probably a bad idea but I just wanted to throw out the idea ... if the StatSN/ExpStatSN were changed to something like RespSN/ExpRespSN and if everything going from the target to the initiator carried a new RespSN, then the resources could be freed up sooner. I would hate to use the A bit for this because it causes more traffic. Eddy mailto:Eddy_Quicksall@iVivity.com ------_=_NextPart_001_01C22DFE.57CA1600 Content-Type: text/html; charset="iso-8859-1"
Eddy,
 
The A bit in Data-In plus Data ACK (SNACK type 2 in -14, Julian's
renumbering of the SNACK types in the working version of -15 is/will
be/has been undone) already provides the intermediate resource freeing
for Data-In.  This is only available for ErrorRecoveryLevel >= 1
We've never thought that R2Ts would consume enough resources to
be worth putting in support for intermediate resource
freeing of them.  Adding another sequence number at this late date
to deal with a "slight inefficiency" when the A bit is used properly
(SNACK-Data ACK PDUs vs. a piggybacked count) does not seem like a
good idea.
 
Thanks,
--David
-----Original Message-----
From: Eddy Quicksall [mailto:eddy_quicksall@ivivity.com]
Sent: Wednesday, July 17, 2002 12:15 PM
To: Mallikarjun C. (E-mail)
Cc: ips@ece. cmu. edu (E-mail)
Subject: RE: iSCSI: freeing resources during data-in and r2t

I think see a slight inefficiency in how resources are freed when multiple data-in and r2t's PDU's are used when ErrorRecoverLevel > 0 or TCP ACK is not available to the iSCSI layer.
 
Data-in and R2T's use DataSN and R2TSN. To free those resources, ExpStatSN is used.
 
But if several R2T's and/or Data-in PDU's were used, resources used for those PDU's are tied up for the entire command.
 
Since other commands could be received during this time, it would be nice if those commands could contain information that would tell the target that the R2T and/or Data-in PDU's have been received.
 
I know a radical change at this point is probably a bad idea but I just wanted to throw out the idea ... if the StatSN/ExpStatSN were changed to something like RespSN/ExpRespSN and if everything going from the target to the initiator carried a new RespSN, then the resources could be freed up sooner.
 
I would hate to use the A bit for this because it causes more traffic.
 
Eddy
mailto:Eddy_Quicksall@iVivity.com
 
------_=_NextPart_001_01C22DFE.57CA1600-- From owner-ips@ece.cmu.edu Wed Jul 17 22:08:23 2002 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA06931 for ; Wed, 17 Jul 2002 22:08:23 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id g6I1TpL04859 for ips-outgoing; Wed, 17 Jul 2002 21:29:51 -0400 (EDT) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from cygnus.equallogic.com (cygnus.equallogic.com [65.170.102.10]) by ece.cmu.edu (8.11.0/8.10.2) with SMTP id g6I1TnX04855 for ; Wed, 17 Jul 2002 21:29:49 -0400 (EDT) Received: from cygnus.equallogic.com (localhost.localdomain [127.0.0.1]) by cygnus.equallogic.com (8.11.6/8.11.6) with ESMTP id g6I1ThC20273 for ; Wed, 17 Jul 2002 21:29:43 -0400 Received: from deneb.dev.equallogic.com (deneb.dev.equallogic.com [172.16.1.99]) by cygnus.equallogic.com (8.11.6/8.11.6) with ESMTP id g6I1ThQ20264; Wed, 17 Jul 2002 21:29:43 -0400 Received: from PKONING.equallogic.com (localhost.localdomain [127.0.0.1]) by deneb.dev.equallogic.com (8.11.6/8.11.6) with ESMTP id g6I1TgO14134; Wed, 17 Jul 2002 21:29:43 -0400 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <15670.6662.773000.291605@gargle.gargle.HOWL> Date: Wed, 17 Jul 2002 21:29:42 -0400 From: Paul Koning To: wrstuden@wasabisystems.com Cc: ips@ece.cmu.edu Subject: Re: How do you negotiate a numerical range? References: X-Mailer: VM 6.95 under 21.4 (patch 3) "Academic Rigor" XEmacs Lucid Sender: owner-ips@ece.cmu.edu Precedence: bulk Content-Transfer-Encoding: 7bit Excerpt of message (sent 17 July 2002) by Bill Studenmund: > I think I know the answer, but wanted to double check as AFAICT all the > numbers we have in the spec are either MIN or MAX; I suspect not much code > is using numerical ranges at the moment. Also, the spec doesn't say > anything about negotiating ranges AFAICT. :-) > > Question 1: > > Since all of the numbers we have are MIN or MAX, my understanding is that > you just take the min or max of the range, and use that for negotiation. > > The initially-non-intuitive thing is that you can readily get a negotiated > value outside of the offered range. :-) > > Consider an offer of "MaxConnections=3~10" to a device that wants > MaxConnections=2. Since MaxConnections is a MIN number, the correct > response (I believe) is "MaxConnections=2". I suspect however this might > seem counter-intuitive for new implementers. No, you are misreading the spec. Only the marker interval parameters (OFMarkInt, IFMarkInt) permit ranges. It is not permitted for any other parameters (see section 4.2). For range proposals, the responder must choose a value from within the range, or Reject. A response value outside the range is a protocol error, the same way that picking a value not in the list for a list type proposal is a protocol error. MIN and MAX apply to parameters for which a single value is offered, and the responder is allowed to negotiate down, or up, respectively. > Question 2: > > Say you have a number that is not a MIN or MAX number (right now this'd be > a vendor-specific one), and you are offered a range (say "Foo=3~12"), and > had you made the offer you would have offered a different range (say > "Foo=10~16"). Do we want to say anything now about how to handle this > negotiation, or do we want to wait until we actually have a non-MIN/MAX > number in the spec? The rule for ranges is already specified (section 4.2.2): one side proposes a range, the other side chooses from that range. If someone adds an X-foo parameter which is a range, that rule would apply. paul From owner-ips@ece.cmu.edu Wed Jul 17 22:09:00 2002 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA06949 for ; Wed, 17 Jul 2002 22:08:59 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id g6I1np805678 for ips-outgoing; Wed, 17 Jul 2002 21:49:51 -0400 (EDT) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from msgbas2.cos.agilent.com (msgbas2x.cos.agilent.com [192.25.240.37]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id g6I1noX05674 for ; Wed, 17 Jul 2002 21:49:50 -0400 (EDT) Received: from msgrel1.cos.agilent.com (msgrel1.cos.agilent.com [130.29.152.77]) by msgbas2.cos.agilent.com (Postfix) with ESMTP id BCAD11A55; Wed, 17 Jul 2002 19:49:49 -0600 (MDT) Received: from axcsbh1.cos.agilent.com (axcsbh1.cos.agilent.com [130.29.152.143]) by msgrel1.cos.agilent.com (Postfix) with SMTP id 77F2612A; Wed, 17 Jul 2002 19:49:49 -0600 (MDT) Received: from 130.29.152.143 by axcsbh1.cos.agilent.com (InterScan E-Mail VirusWall NT); Wed, 17 Jul 2002 19:49:49 -0600 Received: by axcsbh1.cos.agilent.com with Internet Mail Service (5.5.2653.19) id <355MK8R8>; Wed, 17 Jul 2002 19:49:48 -0600 Message-ID: <1BEBA5E8600DD4119A50009027AF54A00D0ED2D8@axcs04.cos.agilent.com> From: "THALER,PAT (A-Roseville,ex1)" To: Bill Studenmund , ips@ece.cmu.edu Subject: RE: How do you negotiate a numerical range? Date: Wed, 17 Jul 2002 19:49:45 -0600 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-ips@ece.cmu.edu Precedence: bulk Bill, Ranges are only valid for keys that are specified to take a range. (Page 71 of the 14 July working draft 15: A range or a large-numerical-value MAY ONLY be offered if it is explicitly allowed for a key.) The draft does explicitly state how ranges are to be negotiated in 4.2.2 The rule is that you have to chose a value in the offered range or "Reject". You don't have to choose Min or Max. The only currently defined keys which take a range are OFMarkInt and IFMarkInt. These keys use range because an implementation may have both upper and lower limits on the range it is willing to support. They are not MAX or MIN. In your example, if you receive Foo=3~12 and you would have offered Foo=10~16, you would presumably offer 10, 11 or 12. You can offer any of those values, so you can choose your preference from the overlap of the offered range and the range you support. Regards, Pat -----Original Message----- From: Bill Studenmund [mailto:wrstuden@wasabisystems.com] Sent: Wednesday, July 17, 2002 2:11 PM To: ips@ece.cmu.edu Subject: How do you negotiate a numerical range? I think I know the answer, but wanted to double check as AFAICT all the numbers we have in the spec are either MIN or MAX; I suspect not much code is using numerical ranges at the moment. Also, the spec doesn't say anything about negotiating ranges AFAICT. :-) Question 1: Since all of the numbers we have are MIN or MAX, my understanding is that you just take the min or max of the range, and use that for negotiation. The initially-non-intuitive thing is that you can readily get a negotiated value outside of the offered range. :-) Consider an offer of "MaxConnections=3~10" to a device that wants MaxConnections=2. Since MaxConnections is a MIN number, the correct response (I believe) is "MaxConnections=2". I suspect however this might seem counter-intuitive for new implementers. Question 2: Say you have a number that is not a MIN or MAX number (right now this'd be a vendor-specific one), and you are offered a range (say "Foo=3~12"), and had you made the offer you would have offered a different range (say "Foo=10~16"). Do we want to say anything now about how to handle this negotiation, or do we want to wait until we actually have a non-MIN/MAX number in the spec? I'd vote holding off, and just having everyone understand there will be more work for some future version. :-) Thoughts? Take care, Bill From owner-ips@ece.cmu.edu Wed Jul 17 22:10:20 2002 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA06984 for ; Wed, 17 Jul 2002 22:10:20 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id g6I1Wam05010 for ips-outgoing; Wed, 17 Jul 2002 21:32:36 -0400 (EDT) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from lion.ninthwonder.com (lion.ninthwonder.com [151.199.66.147]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id g6I1WYX05005 for ; Wed, 17 Jul 2002 21:32:35 -0400 (EDT) Received: by lion.ninthwonder.com (Postfix, from userid 1021) id 5999230706; Wed, 17 Jul 2002 21:32:34 -0400 (EDT) Date: Wed, 17 Jul 2002 18:29:34 -0700 (PDT) From: Bill Studenmund X-X-Sender: To: "Martin, Nick (Server Storage)" Cc: Subject: RE: How do you negotiate a numerical range? In-Reply-To: <31891B757C09184BBFEC5275F85D5595104EAA@cceexc18.americas.cpqcorp.net> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ips@ece.cmu.edu Precedence: bulk On Wed, 17 Jul 2002, Martin, Nick (Server Storage) wrote: > Bill, > > I agree that there could be more to do if/when we need ranges. > Ranges are not allowed unless specifically stated for a particular key. So we are safe for now. This note (and this thread actually) is going a bit far afield. Its relevance I think is that we are showing how we don't seem to have a clear idea of how to use ranges, and as such we have a part of the spec (admittedly unused at the moment) which we don't have clear in our head, and which we don't seem to realize we don't have clear in our head (*). (*) as opposed say to bi directional scsi commands, which I gather everyone thinks we need field experience to decide what we want to do. > >From working draft 15: > > "The value offered or declared can be a numerical-value, a numericalrange > defined by lower and upper value with both integers separated > by tilde, a binary value, a text-value, a iSCSI-name-value, an iSCSIlocal- > name-value, a boolean-value (Yes or No), or a list of comma > separated text-values. > A range or a large-numerical-value MAY ONLY be > offered if it is explicitly allowed for a key. > An iSCSI-name-value > and an iSCSI-local-name-value can be used only where explicitly > allowed. A selected value can be an numerical-value, a large-numerical- > value, a text-value or a boolean-value." > > > I disagree with your conclusion in Question 1. > Offering a range for this particular key is an error. For the moment yes. But the point was to run a thought experement to see what would happen if we permitted it. > However presuming for a moment that a range is allowed for the key in > the example, I think this must result in a negotiation failure for > this key and login may fail. > > As I read you example, the responder seems to support the range 2~2 > which has no values in common with 3~10. Responding with 2 is a > protocol violation. The correct response would be "Reject". More below. > If a key which requires a single numeric result allows a range to be > offered, a value within the offered range must be selected. > Responding with a value outside the offered range would be a protocol > violation. > If such a key has a MIN or MAX rule, this should specify whether the > largest or smallest value common between the range offered and the > range supported by the responder should be selected. If 3~10 is > offered, and 2~6 is supported by the responder, then the result with a > MIN rule would be 3 and the result with a MAX rule would be 6. If > there is neither a MIN nor MAX rule then 3, 4, 5, and 6 are all valid > responses (implementer's choice). This is intuitive, but would > perhaps need to be clearly stated to prevent other interpretation. My concern with that is what would happen if you could offer both a single number and a range? Think about MaxConnections for a moment. For it, we want as many connections as both sides can support and no more. If we exchange just numbers, then each side offers its max (say A and B), and we choose the MIN of the two. But if we were dealing with ranges, we (AFAICT) should offer the valid range we can accept, which would be 1~A and 1~B. We then want the MAX of the intersection. So the MIN/MAX-ness of a parameter flips if you're talking about a range or single numbers. :-| > I could envision a key which requires a range as the result. In this > case the rule for the result might be the INTERSECTION of the range > offered that the responder also supports. Thus for an offer of 4~20 > the responses 4~8, 5~10, and 10~20 could each be valid depending on > the supported range of the responder, but 2~4, 15~25, and 25~30 are > all invalid responses because they include values outside the offered > range. There could also be a rule called UNION, but I have trouble > imagining a use for it in negotiations. As I read the excerpt above, > keys which require a range as a result are currently prohibited. That could be done. I agree I can't see a use for it now. :-) > If non-intuitive results such as you describe in Question 1 were not > already prohibited, then IMHO the spec would require revision. Well, I do wonder why we need to talk about ranges when 1) we don't use them, and 2) we don't have one clear idea how someone would use them. :-) True that they only would be usable for vendor-specific keys now, but since there's no agreed-on way to use them. So different vendors may implement them differently. If I wanted to implement different vendors' private keys, I could well end up needing different range implementations for each vendor. :-| Is there a reason we shouldn't just rip the range text out now? It's not usable as-is, and we certianly can put it back when we 1) need it and 2) have decided how to deal with the above. ?? Take care, Bill From owner-ips@ece.cmu.edu Wed Jul 17 22:10:41 2002 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA07029 for ; Wed, 17 Jul 2002 22:10:41 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id g6I1iFL05420 for ips-outgoing; Wed, 17 Jul 2002 21:44:15 -0400 (EDT) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from lion.ninthwonder.com (lion.ninthwonder.com [151.199.66.147]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id g6I1iDX05416 for ; Wed, 17 Jul 2002 21:44:13 -0400 (EDT) Received: by lion.ninthwonder.com (Postfix, from userid 1021) id 3C62230706; Wed, 17 Jul 2002 21:44:13 -0400 (EDT) Date: Wed, 17 Jul 2002 18:41:13 -0700 (PDT) From: Bill Studenmund X-X-Sender: To: Paul Koning Cc: Subject: Re: How do you negotiate a numerical range? In-Reply-To: <15670.6662.773000.291605@gargle.gargle.HOWL> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ips@ece.cmu.edu Precedence: bulk On Wed, 17 Jul 2002, Paul Koning wrote: > No, you are misreading the spec. And as the last message I just sent indicates, I'm not the only one. :-) > Only the marker interval parameters (OFMarkInt, IFMarkInt) permit > ranges. It is not permitted for any other parameters (see section > 4.2). You are correct. Search wasn't my friend on this one. > For range proposals, the responder must choose a value from within the > range, or Reject. A response value outside the range is a protocol > error, the same way that picking a value not in the list for a list > type proposal is a protocol error. > > MIN and MAX apply to parameters for which a single value is offered, > and the responder is allowed to negotiate down, or up, respectively. Never mind other note, except to the extent that MIN and MAX may have weird semantics with respect to ranges. Take care, Bill From owner-ips@ece.cmu.edu Wed Jul 17 22:50:51 2002 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA08832 for ; Wed, 17 Jul 2002 22:50:46 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id g6I2AkL06494 for ips-outgoing; Wed, 17 Jul 2002 22:10:46 -0400 (EDT) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from palrel10.hp.com (palrel10.hp.com [156.153.255.245]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id g6I2AiX06489 for ; Wed, 17 Jul 2002 22:10:44 -0400 (EDT) Received: from xparelay2.corp.hp.com (xparelay2.corp.hp.com [15.58.137.112]) by palrel10.hp.com (Postfix) with ESMTP id 3357DC003E8; Wed, 17 Jul 2002 19:10:43 -0700 (PDT) Received: from xpabh1.corp.hp.com (xpabh1.corp.hp.com [15.58.136.191]) by xparelay2.corp.hp.com (Postfix) with ESMTP id 1C49BBA; Wed, 17 Jul 2002 19:10:43 -0700 (PDT) Received: by xpabh1.corp.hp.com with Internet Mail Service (5.5.2655.55) id <3ZN9NKFZ>; Wed, 17 Jul 2002 19:10:43 -0700 Message-ID: <6BD67FFB937FD411A04F00D0B74FE87805CCF6DE@xrose06.rose.hp.com> From: "KRUEGER,MARJORIE (HP-Roseville,ex1)" To: "'Julian Satran'" Cc: "Ips Reflector (E-mail)" Subject: RE: iSCSI: DLB's Comment on SCSI Port Names Date: Wed, 17 Jul 2002 19:10:42 -0700 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2655.55) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-ips@ece.cmu.edu Precedence: bulk Julo, I see you've changed to 223 in the draft, serves me right for not responding ;-) I don't understand why you think it's desirable to limit the name length to "something more binary"? And how does 223 accomplish that? Since the port and node names are strings, they are already a "binary length" cause they are a multiple of bytes. I suggest 255 as a max port name length because many string implementations in different languages and OSs can most easily deal with string constructs that are a max of 255 bytes (256 with null terminator). I'm thinking mostly of management applications, since they are the entities that will most have to deal with names for the purpose of assigning resources. From the point of view of the drivers (which I presume are mostly written in C) it doesn't really matter that what the name length is, so I see no value in reducing the max node name to 223 for their benefit. And why 223 anyway, since it's really 238 now that you've limited the representation of the ISID to hex format. > -----Original Message----- > From: Julian Satran [mailto:Julian_Satran@il.ibm.com] > Sent: Saturday, July 13, 2002 7:02 PM > To: ips@ece.cmu.edu > Subject: RE: iSCSI: DLB's Comment on SCSI Port Names > > > Thanks again - I have restricted the encoding of ISID/TPGT to > hex (they are > not both numerical :-)) > Wouldn't it be better to restrict the name length to something more > "binary" like 223? > > Julo > ----- Forwarded by Julian Satran/Haifa/IBM on 07/14/2002 > 04:54 AM ----- > > > > Julian Satran > > > To: > "KRUEGER,MARJORIE (HP-Roseville,ex1)" > > 07/12/2002 04:40 cc: ips > , Julian Satran/Haifa/IBM@IBMIL > > AM From: > Julian Satran/Haifa/IBM@Haifa/IBM@IBMIL > > Subject: RE: > iSCSI: DLB's Comment on SCSI Port Names(Document link: Julian > Satran - Mail) > > > > > > > > > > > > > > > > > > > > > > Marjorie, > > Thanks for your complete and timely answer. > > Regards, > Julo > > > > > > "KRUEGER,MARJORIE > > > (HP-Roseville,ex1 To: > Julian Satran/Haifa/IBM@IBMIL > > )" cc: ips > > > iSCSI: DLB's Comment on SCSI Port Names > > @hp.com> > > > > > > 07/11/2002 05:15 > > > AM > > > Please respond to > > > "KRUEGER,MARJORIE > > > (HP-Roseville,ex1 > > > )" > > > > > > > > > > > > Julo, > I'm a bit confused as the issues list on your website does > not have this as > issue 37, and all I see is issue 9 (where your comment > appears to imply "no > change"?) > > In any case, here's what I recommend: > > In sec 1.1 Definitions change the following definitions to: > > I_T Nexus: the last sentence should be > > The I_T nexus can be identified by the conjunction of the > SCSI port names; > that is, the I_T nexus identifier is the tuple (iSCSI Initiator Name + > ',i,'+ ISID, iSCSI Target Name + ',t,'+ Portal Group Tag). > > SCSI Port Name: definition should be > > A name made up as UTF-8 characters and includes the iSCSI > Name + ',i,' or > ',t,' + ISID or Portal Group Tag > > In sec 2.2.7, 1st paragraph, delete the comment in > parenthesis starting > with "(for iSCSI,.." (or change it to point it to section 2.4.2, your > choice). > > In sec 2.4.2, change the text to: > > When used in SCSI parameter data, the SCSI port name MUST > be encoded as: > - The iSCSI Name in UTF-8 format, followed by > - a comma separator (1 byte), followed by > - the ASCII character 'i' (for SCSI Initiator Port) or the > ASCII character 't' (for SCSI Target Port), followed by > - a comma separator (1 byte), followed by > - A string representation (, see > section 4.1 Text > Format) > of the ISID (for SCSI initiator port) or the portal > group tag (for > SCSI target port). > SCSI port names have a maximum length of 255 bytes. > The ASCII character 'i' or 't' is the label that > identifies this > port > as either a SCSI Initiator Port or a SCSI Target Port. > The 255 max port name makes for a 237 max iSCSI node name > (check my math > Jim :-) as the max character representation of an ISID is 15 > characters for > the largest decimal representation (14 char for the largest > hex), + 3 char > (",i,") + 237 = 255 > > The change in max node name causes changes to: > > sec 2.2.6.1, paragraph 2, > sec 2.2.6.2, 2nd p, 3rd bullet > > I will see that a change is proposed to Annex A in whatever SAM doc is > currently under revision. > > Thanks, > Marjorie Krueger > Networked Storage Architecture > Networked Storage Solutions Org. > Hewlett-Packard > -----Original Message----- > From: Julian Satran (Actcom) [mailto:Julian_Satran@actcom.net.il] > Sent: Tuesday, July 09, 2002 6:44 AM > To: KRUEGER,MARJORIE (HP-Roseville,ex1); 'Jim Hafner'; > Black_David@emc.com > Cc: ips > Subject: Re: iSCSI: DLB's Comment on SCSI Port Names > > Marjorie, > > I'll list this as issue 37 and I think we can settle on 249 :-) > I would appreciate if you let me know what constants change > (in 2.4.2?) > > Julo > ----- Original Message ----- > From: KRUEGER,MARJORIE (HP-Roseville,ex1) > To: 'Jim Hafner' ; Black_David@emc.com > Cc: ips@ece.cmu.edu > Sent: Tuesday, July 09, 2002 4:04 AM > Subject: RE: iSCSI: DLB's Comment on SCSI Port Names > > I've just encountered this issue with regards to iSCSI port > name encoding > in the SCSI MIB, and the currently specified port name > encoding causes > inconvenience (at best). IMO, it makes sense to be able to treat an > iSCSI name field, be it device name or port name, the same > - as a string > of display characters, portions of which may contain ASCII-encoded > numeric values. > > I don't really see that it makes a difference whether one > views ISID and > TPGT as numeric strings or values, since as Jim says, there are no > calculations performed using these things, and they are basicly just > "tags". The issue for me is that the rest of the "SCSI > port name" is a > string and I see no value in "encoding" the ISID or TPGT as > a value for > SCSI purposes, as SCSI should have no need to use the ISID > or TPGT values > separately from the entire port name. And even if SCSI had > such a need, > it's a simple matter to convert a numeric string representation to a > value. > > The downside of a string-encoding is the increased maximum > size of the > SCSI port name. > > If strings over 256 characters are a problem for some > platforms, I'd be > in favor of reducing the max iSCSI node name to 249 > characters so the > maximum SCSI port name would be 255 characters total (249 > char name + > ",i," + "0x0000") > > Marjorie Krueger > Networked Storage Architecture > Networked Storage Solutions Org. > Hewlett-Packard > -----Original Message----- > From: Jim Hafner [mailto:hafner@almaden.ibm.com] > Sent: Monday, July 08, 2002 9:08 AM > To: Black_David@emc.com > Cc: ips@ece.cmu.edu > Subject: RE: iSCSI: DLB's Comment on SCSI Port Names > > > David, > > I believe it will (may?) be used, so I agree we're in the > second case. > However, this format is the intended use in SCSI protocol > stuff. Two > places where SCSI ports names are used now is in ALIAS, > Access Controls > and in third party reservations -- see caveat below, however) > > I don't see a need in this context to define these as > strings (that's not > a SCSI way of thinking...). > > However, I think the issue comes down to a simple question: > are the ISID > and TPGT values or numerical strings (Julian is calling > them numerical > strings, but I've always thought of them as values, in > spite of the fact > that there is no arithmetic done on them - there is > precedent in SCSI for > such thinking, so I'm not completely out in the woods here). > > If they are values, then I'd like to see them formatted for SCSI in > "value form"; if they are strings, then any representation > should be OK. > > > Does that at least get to the core of the issue? > > Jim Hafner > > CAVEAT: I don't think we'd use the iSCSI constructed port > names in those > contexts as device names are better suited for those > purposes, but these > are examples where specification of SCSI port name format > is required. > > > To: Jim Hafner/Almaden/IBM@IBMUS > cc: ips@ece.cmu.edu > Subject: RE: iSCSI: DLB's Comment on SCSI Port Names > > > > Jim, > > My view of this is that either: > - The SCSI Port Name is never going to be used, in which case > it shouldn't be designed to this level of detail. OR > - It's going to be used, and hence is worth designing in a fashion > that is reasonable to use. > I think we're in the second category, and turning the ISID into > hex ASCII (well, UTF-8) so the SCSI port name is a string is > worth doing now to avoid problems when people actually try > to use it. I would have no problems if someone wanted to > pad the string, but I'd make specifying the padding the > responsibility of the protocol/API/situation in which it > was used rather than incorporating the padding into the name. > > Thanks, > --David > > -----Original Message----- > From: Jim Hafner [mailto:hafner@almaden.ibm.com] > Sent: Monday, July 08, 2002 11:42 AM > To: Black_David@emc.com > Cc: ips@ece.cmu.edu > Subject: Re: iSCSI: DLB's Comment on SCSI Port Names > > > > David, > > You wrote: > > >[T.9] 2.4.2 SCSI Architecture Model > > > > The SCSI Port Name is mandatory in iSCSI. When used in SCSI > > parameter data, the SCSI port name MUST be encoded as: > > - The iSCSI Name in UTF-8 format, followed by > > - a comma separator (1 byte), followed by > > - the ASCII character 'i' (for SCSI Initiator Port) or the > > ASCII character 't' (for SCSI Target Port), followed by > > - a comma separator (1 byte), followed by > > - zero to 3 null pad bytes so that the complete format is a > > multiple of four bytes long, followed by > > - the 6byte value of the ISID (for SCSI initiator port) or the > > 2byte value of the portal group tag (for SCSI target port) in > > network byte order (BigEndian). > > > That's a peculiar format with padding nulls in the middle and > > a number concatenated after the padding - for example, it can't > > be passed in iSCSI login without format conversion. How about > > converting the number to 4 or 12 bytes of hex (ASCII characters) > > and moving the padding to the end so the result is actually a > > string, and excluding the padding from the definition of the name? > > This will increase the maximum length of port names, but produce > > names that are easier to deal with. > > Admittedly that's an odd format, however here was the > reason for this > layout. > 1) it's not used directly in iSCSI "Text" strings; it's > intended to be a > description of how this information is packed into a byte array for > representation in "SCSI parameter data" (as it says!) -- > that is, it's > NEVER > "passed in iSCSI login" (in this form). > 2) the padding after the string was to force the binary > values of the > ISID > or PGT to be better word aligned and can be more easily > extracted as a > value > direct from the byte array without conversion. > > What do you think? > > Jim Hafner > > > > > > From owner-ips@ece.cmu.edu Thu Jul 18 10:04:40 2002 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA02919 for ; Thu, 18 Jul 2002 10:04:35 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id g6IDNJR11383 for ips-outgoing; Thu, 18 Jul 2002 09:23:19 -0400 (EDT) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from cygnus.equallogic.com (cygnus.equallogic.com [65.170.102.10]) by ece.cmu.edu (8.11.0/8.10.2) with SMTP id g6IDNIX11379 for ; Thu, 18 Jul 2002 09:23:18 -0400 (EDT) Received: from cygnus.equallogic.com (localhost.localdomain [127.0.0.1]) by cygnus.equallogic.com (8.11.6/8.11.6) with ESMTP id g6IDN8C25805 for ; Thu, 18 Jul 2002 09:23:08 -0400 Received: from deneb.dev.equallogic.com (deneb.dev.equallogic.com [172.16.1.99]) by cygnus.equallogic.com (8.11.6/8.11.6) with ESMTP id g6IDN8Q25796; Thu, 18 Jul 2002 09:23:08 -0400 Received: from pkoning.dev.equallogic.com.equallogic.com (localhost.localdomain [127.0.0.1]) by deneb.dev.equallogic.com (8.11.6/8.11.6) with SMTP id g6IDN7q29661; Thu, 18 Jul 2002 09:23:07 -0400 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <15670.49467.703289.135064@pkoning.dev.equallogic.com> Date: Thu, 18 Jul 2002 09:23:07 -0400 From: Paul Koning To: wrstuden@wasabisystems.com Cc: ips@ece.cmu.edu Subject: Re: How do you negotiate a numerical range? References: <15670.6662.773000.291605@gargle.gargle.HOWL> X-Mailer: VM 7.01 under 21.1 (patch 11) "Carlsbad Caverns" XEmacs Lucid Sender: owner-ips@ece.cmu.edu Precedence: bulk Content-Transfer-Encoding: 7bit >>>>> "Bill" == Bill Studenmund writes: >> MIN and MAX apply to parameters for which a single value is >> offered, and the responder is allowed to negotiate down, or up, >> respectively. Bill> Never mind other note, except to the extent that MIN and MAX Bill> may have weird semantics with respect to ranges. They aren't used with ranges, only with single number proposals. Ranges are like lists, you must choose a value from within the range (set) offered to you. That's clearly stated in the spec. paul From owner-ips@ece.cmu.edu Thu Jul 18 10:05:13 2002 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA02956 for ; Thu, 18 Jul 2002 10:05:13 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id g6IDLKO11271 for ips-outgoing; Thu, 18 Jul 2002 09:21:20 -0400 (EDT) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from d12lmsgate-3.de.ibm.com (d12lmsgate-3.de.ibm.com [195.212.91.201]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id g6IDLHX11264 for ; Thu, 18 Jul 2002 09:21:17 -0400 (EDT) Received: from d12relay02.de.ibm.com (d12relay02.de.ibm.com [9.165.215.23]) by d12lmsgate-3.de.ibm.com (8.12.3/8.12.3) with ESMTP id g6IDL97p022730 for ; Thu, 18 Jul 2002 15:21:10 +0200 Received: from d10hubm1.telaviv.ibm.com (d10ml001.telaviv.ibm.com [9.148.216.55]) by d12relay02.de.ibm.com (8.11.1m3/NCO/VER6.2) with ESMTP id g6IDL6k65620 for ; Thu, 18 Jul 2002 15:21:06 +0200 To: ips@ece.cmu.edu MIME-Version: 1.0 Subject: iSCSI - first working group Last Call round issues list and resolutions X-Mailer: Lotus Notes Release 5.0.9 November 16, 2001 From: "Julian Satran" Message-ID: Date: Thu, 18 Jul 2002 16:21:01 +0300 X-MIMETrack: Serialize by Router on D10ML001/10/M/IBM(Release 5.0.9a |January 7, 2002) at 18/07/2002 16:21:08 Content-Type: multipart/mixed; boundary="=_mixed 002CA95DC2256BFA_=" Sender: owner-ips@ece.cmu.edu Precedence: bulk --=_mixed 002CA95DC2256BFA_= Content-Type: multipart/alternative; boundary="=_alternative 002CA95FC2256BFA_=" --=_alternative 002CA95FC2256BFA_= Content-Type: text/plain; charset="us-ascii" Dear colleagues, The list of issues raised and their resolution is attached. The working version of draft 15 is still up for review on my site. Julo --=_alternative 002CA95FC2256BFA_= Content-Type: text/html; charset="us-ascii"
Dear colleagues,

The list of issues raised and their resolution is attached.

The working version of draft 15 is still up for review on my site.

Julo

--=_alternative 002CA95FC2256BFA_=-- --=_mixed 002CA95DC2256BFA_= Content-Type: text/plain; name="iSCSI-WG-Last-Call-Issues-And-Resolution.txt" Content-Disposition: attachment; filename="iSCSI-WG-Last-Call-Issues-And-Resolution.txt" Content-Transfer-Encoding: quoted-printable Content-Transfer-Encoding: quoted-printable iSCSI - WG - Last Call - Issues and Resolution # Description Resoluti= on ---+----------------------------------------------------------+------------= ----------------- 1 | Wording in 4.2 for empty Text Request/Response | Changed word= ing=20 ---+----------------------------------------------------------+------------= ----------------- 2 | wording for waiting for data in 9.17 | Added words = ---+----------------------------------------------------------+------------= ----------------- 3 | wording for connection clearing after retry in 2.2.2.1 | Changed word= ing=20 ---+----------------------------------------------------------+------------= ----------------- 4 | link command complete mappes also to 0x00 in 9.4.3 | added it to = mapping=20 ---+----------------------------------------------------------+------------= ----------------- 5 | Stray reference to IPV6 dotted decimal on page 250 | removed ---+----------------------------------------------------------+------------= ----------------- 6 | Text in 4.3 and 4.4 not allowing SendTargets | fixed text ---+----------------------------------------------------------+------------= ----------------- 7 | Clarification on COLD RESET - required by SAM | fixed text ---+----------------------------------------------------------+------------= ----------------- 8 | 9.5.4 Initiator (Task Tag) to be replaced by Referenced | fixed text ---+----------------------------------------------------------+------------= ----------------- 9 | 9.5 recommendation on empty data inconsistent with R2T | fixed text ---+----------------------------------------------------------+------------= ----------------- 10 | 2.2.2.3 and 9.8.1 and 9.7 text numbering data/r2t | fixed text ---+----------------------------------------------------------+------------= ----------------- 11 | 5.2 Text not clear about connection logout mandated | added text ---+----------------------------------------------------------+------------= ----------------- 12 | 9.4.6.2 text reffers only to firstburstsize | changed text= to "incorrect=20 | | amount of da= ta" ---+----------------------------------------------------------+------------= ----------------- 13 | Both Length and Size used in text - requested use of | Changed Size= in text=20 | of only one of them | to Length ---+----------------------------------------------------------+------------= ----------------- 14 | Not clear how to number retransmitted Data-In | Added text t= o 9.16 ---+----------------------------------------------------------+------------= ----------------- 15 | Concluding text in 4.3.2 consideered unclear | Slightly cha= nged text ---+----------------------------------------------------------+------------= ----------------- 16 | Say Reject PDU when the intent is Reject PDU | Added PDU wh= en Reject PDU was | | meant and lo= wer case reject=20 ---+----------------------------------------------------------+------------= ----------------- 17 | Reinstate I bit in text request (typo) | Fixed figure ---+----------------------------------------------------------+------------= ----------------- 18 | C bit relation to T and F bit "MUST" not "must" | Fixed text ---+----------------------------------------------------------+------------= ----------------- 19 | I bit on a Text negotiation the same | Added to text ---+----------------------------------------------------------+------------= ----------------- 20 | Lingering reference to referenced task tag in 2.5.1.4 | Removed ---+----------------------------------------------------------+------------= ----------------- 21 | StatSN is retransmitted R2T should be the new value | fixed text i= n 9.16 ---+----------------------------------------------------------+------------= ----------------- 22 | REf. Task Tag to replace ITT in 9.5.4 and 9.6.1 | fixed text=20 ---+----------------------------------------------------------+------------= ----------------- 23 | Old reference to ACL | Removed ---+----------------------------------------------------------+------------= ----------------- 24 | Confusion about digest position | Spell-out di= gest names ---+----------------------------------------------------------+------------= ----------------- 25 | Async Message - Logout Request timer handling | Fixed in app= endix E ---+----------------------------------------------------------+------------= ----------------- 26 | Numeric instead of Numerical in Appendix A | Fixed text ---+----------------------------------------------------------+------------= ----------------- 27 | Error in DefaultTime2Wait spec | Fixed text a= nd changed format ---+----------------------------------------------------------+------------= ----------------- 28 | Correction of DefaultTime2Wait and reformat | Fiexed and r= eformated ---+----------------------------------------------------------+------------= ----------------- 29 | Security aligned with security draft | Aligned ---+----------------------------------------------------------+------------= ----------------- 30 | Command queue missunderstanding | Fixed text i= n 6.1.2 ---+----------------------------------------------------------+------------= ----------------- =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D Draft 13 to 14 - Watershed =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D ---+----------------------------------------------------------+------------= ----------------- 30 | Requirement to support 16kB total key=3Dvalue text | Agreed to = 8k limit | considered excessive - reduction (to 2k?) proposed | ---+----------------------------------------------------------+------------= ----------------- 31 | 64 bit decimals considered difficult | leave as is ---+----------------------------------------------------------+------------= ----------------- 32 | Decimal encoded binary are harmfull | an entrenche= d evil=20 | | restrict the= m to given length ---+----------------------------------------------------------+------------= ----------------- 33 | Combined device (target and IPsec) made explicit | Added text t= o 7.3 ---+----------------------------------------------------------+------------= ----------------- 34 | TargePortalGroupTag is a 16 bit binary - not numeric | Fixed text i= n text to 11.9 ---+----------------------------------------------------------+------------= ----------------- 35 | IPsec implementation in a "combined-device" has to be | Spelled out = in 7.3 | spelled out | ---+----------------------------------------------------------+------------= ----------------- 36 | Boolean functions not spelled out | Spelled out = in 11 ---+----------------------------------------------------------+------------= ----------------- 37 | Boolean functions not spelled out | Spelled out = in 11 ---+----------------------------------------------------------+------------= ----------------- 38 | Remove BiDiR2T key | --- ---+----------------------------------------------------------+------------= ----------------- 39 | Offset of Immediate data | spelled out = in 2.2.4 ---+----------------------------------------------------------+------------= ----------------- 40 | 11.8 Portal Group Tag ommited/required | made it MUST ---+----------------------------------------------------------+------------= ----------------- =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D DLB's issues with their own numbering =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D ---+----------------------------------------------------------+------------= ----------------- T1 | 2.2.2.2 recovery MUST be undertaken | fixed text ---+----------------------------------------------------------+------------= ----------------- ---+----------------------------------------------------------+------------= ----------------- T2 | 2.2.6.1 target name may be ignored- replace with | fixed text | MAY be omitted |=20 ---+----------------------------------------------------------+------------= ----------------- T3 | 2.2.6.1 upper case MUST in name requirements | fixed text | and in encoding | ---+----------------------------------------------------------+------------= ----------------- T4 | 2.2.6.3.1 .iqn - needs date unammbiguous | fixed based = on DLB ---+----------------------------------------------------------+------------= ----------------- T5 | Synch and Steering bloated - for what we choose | fixed text | WHAT a WASTE of EFFORT! | ---+----------------------------------------------------------+------------= ----------------- T6 | Clarify text in 2.3 about discovery | Changed MAY = accept to | | equivalent M= UST ONLY and | | spelled-out = rejects | | MUST stays -= nothing fancy | | in discovery ---+----------------------------------------------------------+------------= ----------------- T7 | Portal defined by IP address does work through NAPT | It is not a = protocol | | element - ra= ther a model=20 | | entity. In c= ase of NAPT the | | model entity= name may change ---+----------------------------------------------------------+------------= ----------------- T8 |2-concerns - the underlying issue stems from an obsolete | Removed port= specific mode | port specific mode page notion - iSCSI has none | replaced tex= t with session | parameters | params and r= emoved 2.4.3.2 ---+----------------------------------------------------------+------------= ----------------- T9 |SCSI port name inapropriate | The encoding= is meant for SCSI | | and it has n= o padding in the | | middle - CHA= NGED ENCODING ---+----------------------------------------------------------+------------= ----------------- T10|2.4.3.2 - should not uppercased | 2.4.3.2 is o= bsolete ---+----------------------------------------------------------+------------= ----------------- T11| Decimal to binary | limited to n= umbers that are | | allowed valu= es less than 2**64 | | and bitstrin= g with defined | | length less = than 2**64 ---+----------------------------------------------------------+------------= ----------------- T12| large-numerical-value does not cover lower than 2**64 | large are on= purpose | | different in= order to restrict | | them ---+----------------------------------------------------------+------------= ----------------- T13|=3D30 and clarify when 64k has to be supported | fixed text= for 64k support ---+----------------------------------------------------------+------------= ----------------- T14| Declaration not explained | added a stat= ement to 4.2 ---+----------------------------------------------------------+------------= ----------------- T15| Make TPGT return on login MUST always | MUST sticks ---+----------------------------------------------------------+------------= ----------------- T16| Second connection issue | I did not us= e SHOULD as=20 | | there are re= covery scenarios=20 | | that do not = need a second=20 | | connection. | | MUST in 4.3.4 | | Rest of text= is consistent ---+----------------------------------------------------------+------------= ----------------- T17| Format Error - 6.4 | Examples are= out of place | | and have bee= n removed | | legal values= are specified | | in chapter 9 ---+----------------------------------------------------------+------------= ----------------- T18| Text on abort after an ULP timeout | Fixed text. = There is only | | one specific= Abort Task=20 ---+----------------------------------------------------------+------------= ----------------- T19| Conservative reuse in 8.1.1 SHOULd is appropriate | changed to S= HOULD | | SCSI referen= ce already i ---+----------------------------------------------------------+------------= ----------------- T20| MUST support and use autosense in 8.2 | fixed text ---+----------------------------------------------------------+------------= ----------------- T21| Guidance for timeouts in 8.3 set too low | raised ---+----------------------------------------------------------+------------= ----------------- T22| Padding replace SHOULD with MUST be sent as 0 | why is that = better? | | receiver alw= ays ignores pad | | testing is i= mplicit in CRC ---+----------------------------------------------------------+------------= ----------------- T23|o, u etc not exclusive is a protocol error | made it expl= icit ---+----------------------------------------------------------+------------= ----------------- T24| Residual Counts should be reserved when not valid | fixed text=20 ---+----------------------------------------------------------+------------= ----------------- T25| Task reassign may need LUN | No - we dont= want checks if | | we can avoid= them ---+----------------------------------------------------------+------------= ----------------- T26| Add Task Reassign to list of responses | Fixed=20 ---+----------------------------------------------------------+------------= ----------------- T27| ExpStatSN spell out for non-first | spelled out | Additional concern CmdSN | Login is imm= ediate ---+----------------------------------------------------------+------------= ----------------- T28| Concern about discarding | Discarding r= efers only to=20 | | REORDERING Q= UEUE=20 | | changed word= ing ---+----------------------------------------------------------+------------= ----------------- T29| Logout request request refers to implict login | made the tex= t clearer and | | added a cros= s reference from | | 9.12.8 ---+----------------------------------------------------------+------------= ----------------- T30| Resegmenting may come as a surprize - suggested a | New text for= resegmentation | different request | 9.4 and 9.16 ---+----------------------------------------------------------+------------= ----------------- T31| Operational Error Level instead of supported | Fixed text ---+----------------------------------------------------------+------------= ----------------- T32| Vendor Specific Authentication contradictory statement | Fixed text i= n 10 ---+----------------------------------------------------------+------------= ----------------- T33| MD5 SHOULD be offered change to MUST for interop. | made MUST ---+----------------------------------------------------------+------------= ----------------- T34| Digests CRC MUST be offered | fixed text ---+----------------------------------------------------------+------------= ----------------- T35| Target and Initiator name not changed | There is a g= eneral restriction | | about restat= ing a key except=20 | | when allowed= and those are not | | allowed - I = added text anyhow ---+----------------------------------------------------------+------------= ----------------- T36| TargetAlias/InitiatorAlias warning | Only a weak = one possible as | | it can't be = enforced ---+----------------------------------------------------------+------------= ----------------- T37| Unsolicited data inclarity | Already spec= ed in 2.2.4 ---+----------------------------------------------------------+------------= ----------------- T38| IANA text | Fixed - why = is that technical ---+----------------------------------------------------------+------------= ----------------- T39| IANA registry for keys | Proposed for= mulation for=20 | | vendor keys = and options | | Read careful= ly=20 ---+----------------------------------------------------------+------------= ----------------- =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D ER issues with their own numbering =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D ---+----------------------------------------------------------+------------= ----------------- E1 | Version number out of place | There was a = complaint | | it is hidden= and it should=20 | | the next pla= ce may the title =20 ---+----------------------------------------------------------+------------= ----------------- E2 | use of may in the text on pag 36 3rd paragraph | even after r= eareading author | | would not us= e MAY and MUST ---+----------------------------------------------------------+------------= ----------------- E3 | 2.2.2.2 replace SHOULD not exceed 2**31-1 with MUST | fixed text ---+----------------------------------------------------------+------------= ----------------- E4 | wordsmithing the second paragraph on pg. 41 | may is used = here as "can do" | | and the expl= anation is=20 | | accurate ---+----------------------------------------------------------+------------= ----------------- E5 | EUI64 is not used by FC directly | fixed text i= n 2.2.6 ---+----------------------------------------------------------+------------= ----------------- E6 | Caution on EUI64 used as iSCSI names are not tied to | Added text t= o 8.1.2=20 | hardware | ---+----------------------------------------------------------+------------= ----------------- E7 | T and F used in 4 without being defined | defined in i= ntroduction to 4 ---+----------------------------------------------------------+------------= ----------------- E8 | Number figure and tables | no before la= st call - tool ---+----------------------------------------------------------+------------= ----------------- E9 | move 5.1.3 & to fron (5.1.1 & 2) | will give it= a try! | | it is not co= nsistent though! ---+----------------------------------------------------------+------------= ----------------- E10| 6.1.2 SHOULD and MAY issue | the intent i= s to avoid=20 | |data and bett= er avoid dropping! | |removed MAY; = wording MAY | |contradicts S= HOULD ---+----------------------------------------------------------+------------= ----------------- E11| Optional to OPTIONAL in 6.1.2 |fixed text ---+----------------------------------------------------------+------------= ----------------- E12| MUST etc. should refer to case when used | Added text a= t the start=20 | | of 6.12 ---+----------------------------------------------------------+------------= ----------------- E13| MUST, MAY in 7.2 | fixed text a= lthough=20 | | unequivocal = even before ---+----------------------------------------------------------+------------= ----------------- E14| 8.1.1 should -> SHOULD | already there ---+----------------------------------------------------------+------------= ----------------- E15| Conservative Reuse - change to SHOULD | it was agree= d as recommended | | no RECOMMEND= ED ---+----------------------------------------------------------+------------= ----------------- E14| Configurable SHOULD in 8.1.2 | fixed text ---+----------------------------------------------------------+------------= ----------------- E15| Vendor MUST allow ISID coordination | fixed text ---+----------------------------------------------------------+------------= ----------------- E16| Why padding is SHOULD be 0 nad not MUST? | not strictly= required=20 | | some strictl= y secure things=20 | | may want the= m random! ---+----------------------------------------------------------+------------= ----------------- E17| Initiator and Target note? | In iSCSI the= y must be 2=20 | | entities ---+----------------------------------------------------------+------------= ----------------- E18| 9.4 MUST contain sense data | fixed text ---+----------------------------------------------------------+------------= ----------------- E19| Add wording to stress the fact that reset is on all LUs | Added wordin= g on 9.5 that=20 | | reset is acc= ross all LUs | | known to the= initiator ---+----------------------------------------------------------+------------= ----------------- E20| Wording that the A bit MUST not be set for ErrorRecovery| Why? The al= ternative could=20 | Level is 0 | be bit is se= t to 0 by target | | and ignored = by I (no test!) ---+----------------------------------------------------------+------------= ----------------- E21| 9.11.1 why MUST NOT ... that may | text is corr= ect - other=20 | | wording perh= aps? ---+----------------------------------------------------------+------------= ----------------- E22| Make a single section for version | well if it l= ooks better for | | at least one= reader :-) ---+----------------------------------------------------------+------------= ----------------- E23| 9.14.5 make internal check must not MUST | changed text= to indicate | | command orde= ring is aimed ---+----------------------------------------------------------+------------= ----------------- E24| 9.16.1 SNACK relation to ErrorRecoveryLevel in 9.16 | State that a= ll SNACK have | | to be suppor= ted if=20 | | if ErrorReco= veryLevel>0 ---+----------------------------------------------------------+------------= ----------------- E25| Reject Status text in 9.16.1 confusing | added text f= or ErrorRecoVery | | Level ---+----------------------------------------------------------+------------= ----------------- E26| MUST in 10.1 | fixed text ---+----------------------------------------------------------+------------= ----------------- E27| MUST for CHAP | fixed text (= as in T33) ---+----------------------------------------------------------+------------= ----------------- E28| SHOULD/may in Initiator and Target Alias in 11 | fixed see al= so T36 ---+----------------------------------------------------------+------------= ----------------- E29| 11.8 replace port with reference to IANA cons. | ---+----------------------------------------------------------+------------= ----------------- E30| Phrasing for immediate data - MUST? | might be con= fusing - suggest | | leave as it = is ---+----------------------------------------------------------+------------= ----------------- E31| Immediate & R2T - more explanation | there is a t= able =20 ---+----------------------------------------------------------+------------= ----------------- E32| Addition to Copyright! IP Rights Notices | Added = =20 ---+----------------------------------------------------------+------------= ----------------- --=_mixed 002CA95DC2256BFA_=-- From owner-ips@ece.cmu.edu Thu Jul 18 11:13:32 2002 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA04404 for ; Thu, 18 Jul 2002 11:13:31 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id g6IEJYs14604 for ips-outgoing; Thu, 18 Jul 2002 10:19:34 -0400 (EDT) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from d12lmsgate-2.de.ibm.com (d12lmsgate-2.de.ibm.com [195.212.91.200]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id g6IEJVX14600 for ; Thu, 18 Jul 2002 10:19:32 -0400 (EDT) Received: from d12relay02.de.ibm.com (d12relay02.de.ibm.com [9.165.215.23]) by d12lmsgate-2.de.ibm.com (8.12.3/8.12.3) with ESMTP id g6IEJNi9010200; Thu, 18 Jul 2002 16:19:24 +0200 Received: from d10hubm1.telaviv.ibm.com (d10ml001.telaviv.ibm.com [9.148.216.55]) by d12relay02.de.ibm.com (8.11.1m3/NCO/VER6.2) with ESMTP id g6IEJHk93186; Thu, 18 Jul 2002 16:19:17 +0200 To: "KRUEGER,MARJORIE (HP-Roseville,ex1)" Cc: "Ips Reflector (E-mail)" MIME-Version: 1.0 Subject: RE: iSCSI: DLB's Comment on SCSI Port Names X-Mailer: Lotus Notes Release 5.0.9 November 16, 2001 From: "Julian Satran" Message-ID: Date: Thu, 18 Jul 2002 17:19:12 +0300 X-MIMETrack: Serialize by Router on D10ML001/10/M/IBM(Release 5.0.9a |January 7, 2002) at 18/07/2002 17:19:17, Serialize complete at 18/07/2002 17:19:17 Content-Type: multipart/alternative; boundary="=_alternative 004E032AC2256BFA_=" Sender: owner-ips@ece.cmu.edu Precedence: bulk This is a multipart message in MIME format. --=_alternative 004E032AC2256BFA_= Content-Type: text/plain; charset="us-ascii" Marjorie, I just wanted some spare in case some other syntactic sugar has to be added. And 223 is 255-32 - In fact I wanted 224 :-) Julo "KRUEGER,MARJORIE (HP-Roseville,ex1)" 07/18/2002 05:10 AM To: Julian Satran/Haifa/IBM@IBMIL cc: "Ips Reflector (E-mail)" Subject: RE: iSCSI: DLB's Comment on SCSI Port Names Julo, I see you've changed to 223 in the draft, serves me right for not responding ;-) I don't understand why you think it's desirable to limit the name length to "something more binary"? And how does 223 accomplish that? Since the port and node names are strings, they are already a "binary length" cause they are a multiple of bytes. I suggest 255 as a max port name length because many string implementations in different languages and OSs can most easily deal with string constructs that are a max of 255 bytes (256 with null terminator). I'm thinking mostly of management applications, since they are the entities that will most have to deal with names for the purpose of assigning resources. From the point of view of the drivers (which I presume are mostly written in C) it doesn't really matter that what the name length is, so I see no value in reducing the max node name to 223 for their benefit. And why 223 anyway, since it's really 238 now that you've limited the representation of the ISID to hex format. > -----Original Message----- > From: Julian Satran [mailto:Julian_Satran@il.ibm.com] > Sent: Saturday, July 13, 2002 7:02 PM > To: ips@ece.cmu.edu > Subject: RE: iSCSI: DLB's Comment on SCSI Port Names > > > Thanks again - I have restricted the encoding of ISID/TPGT to > hex (they are > not both numerical :-)) > Wouldn't it be better to restrict the name length to something more > "binary" like 223? > > Julo > ----- Forwarded by Julian Satran/Haifa/IBM on 07/14/2002 > 04:54 AM ----- > > > > Julian Satran > > > To: > "KRUEGER,MARJORIE (HP-Roseville,ex1)" > > 07/12/2002 04:40 cc: ips > , Julian Satran/Haifa/IBM@IBMIL > > AM From: > Julian Satran/Haifa/IBM@Haifa/IBM@IBMIL > > Subject: RE: > iSCSI: DLB's Comment on SCSI Port Names(Document link: Julian > Satran - Mail) > > > > > > > > > > > > > > > > > > > > > > Marjorie, > > Thanks for your complete and timely answer. > > Regards, > Julo > > > > > > "KRUEGER,MARJORIE > > > (HP-Roseville,ex1 To: > Julian Satran/Haifa/IBM@IBMIL > > )" cc: ips > > > iSCSI: DLB's Comment on SCSI Port Names > > @hp.com> > > > > > > 07/11/2002 05:15 > > > AM > > > Please respond to > > > "KRUEGER,MARJORIE > > > (HP-Roseville,ex1 > > > )" > > > > > > > > > > > > Julo, > I'm a bit confused as the issues list on your website does > not have this as > issue 37, and all I see is issue 9 (where your comment > appears to imply "no > change"?) > > In any case, here's what I recommend: > > In sec 1.1 Definitions change the following definitions to: > > I_T Nexus: the last sentence should be > > The I_T nexus can be identified by the conjunction of the > SCSI port names; > that is, the I_T nexus identifier is the tuple (iSCSI Initiator Name + > ',i,'+ ISID, iSCSI Target Name + ',t,'+ Portal Group Tag). > > SCSI Port Name: definition should be > > A name made up as UTF-8 characters and includes the iSCSI > Name + ',i,' or > ',t,' + ISID or Portal Group Tag > > In sec 2.2.7, 1st paragraph, delete the comment in > parenthesis starting > with "(for iSCSI,.." (or change it to point it to section 2.4.2, your > choice). > > In sec 2.4.2, change the text to: > > When used in SCSI parameter data, the SCSI port name MUST > be encoded as: > - The iSCSI Name in UTF-8 format, followed by > - a comma separator (1 byte), followed by > - the ASCII character 'i' (for SCSI Initiator Port) or the > ASCII character 't' (for SCSI Target Port), followed by > - a comma separator (1 byte), followed by > - A string representation (, see > section 4.1 Text > Format) > of the ISID (for SCSI initiator port) or the portal > group tag (for > SCSI target port). > SCSI port names have a maximum length of 255 bytes. > The ASCII character 'i' or 't' is the label that > identifies this > port > as either a SCSI Initiator Port or a SCSI Target Port. > The 255 max port name makes for a 237 max iSCSI node name > (check my math > Jim :-) as the max character representation of an ISID is 15 > characters for > the largest decimal representation (14 char for the largest > hex), + 3 char > (",i,") + 237 = 255 > > The change in max node name causes changes to: > > sec 2.2.6.1, paragraph 2, > sec 2.2.6.2, 2nd p, 3rd bullet > > I will see that a change is proposed to Annex A in whatever SAM doc is > currently under revision. > > Thanks, > Marjorie Krueger > Networked Storage Architecture > Networked Storage Solutions Org. > Hewlett-Packard > -----Original Message----- > From: Julian Satran (Actcom) [mailto:Julian_Satran@actcom.net.il] > Sent: Tuesday, July 09, 2002 6:44 AM > To: KRUEGER,MARJORIE (HP-Roseville,ex1); 'Jim Hafner'; > Black_David@emc.com > Cc: ips > Subject: Re: iSCSI: DLB's Comment on SCSI Port Names > > Marjorie, > > I'll list this as issue 37 and I think we can settle on 249 :-) > I would appreciate if you let me know what constants change > (in 2.4.2?) > > Julo > ----- Original Message ----- > From: KRUEGER,MARJORIE (HP-Roseville,ex1) > To: 'Jim Hafner' ; Black_David@emc.com > Cc: ips@ece.cmu.edu > Sent: Tuesday, July 09, 2002 4:04 AM > Subject: RE: iSCSI: DLB's Comment on SCSI Port Names > > I've just encountered this issue with regards to iSCSI port > name encoding > in the SCSI MIB, and the currently specified port name > encoding causes > inconvenience (at best). IMO, it makes sense to be able to treat an > iSCSI name field, be it device name or port name, the same > - as a string > of display characters, portions of which may contain ASCII-encoded > numeric values. > > I don't really see that it makes a difference whether one > views ISID and > TPGT as numeric strings or values, since as Jim says, there are no > calculations performed using these things, and they are basicly just > "tags". The issue for me is that the rest of the "SCSI > port name" is a > string and I see no value in "encoding" the ISID or TPGT as > a value for > SCSI purposes, as SCSI should have no need to use the ISID > or TPGT values > separately from the entire port name. And even if SCSI had > such a need, > it's a simple matter to convert a numeric string representation to a > value. > > The downside of a string-encoding is the increased maximum > size of the > SCSI port name. > > If strings over 256 characters are a problem for some > platforms, I'd be > in favor of reducing the max iSCSI node name to 249 > characters so the > maximum SCSI port name would be 255 characters total (249 > char name + > ",i," + "0x0000") > > Marjorie Krueger > Networked Storage Architecture > Networked Storage Solutions Org. > Hewlett-Packard > -----Original Message----- > From: Jim Hafner [mailto:hafner@almaden.ibm.com] > Sent: Monday, July 08, 2002 9:08 AM > To: Black_David@emc.com > Cc: ips@ece.cmu.edu > Subject: RE: iSCSI: DLB's Comment on SCSI Port Names > > > David, > > I believe it will (may?) be used, so I agree we're in the > second case. > However, this format is the intended use in SCSI protocol > stuff. Two > places where SCSI ports names are used now is in ALIAS, > Access Controls > and in third party reservations -- see caveat below, however) > > I don't see a need in this context to define these as > strings (that's not > a SCSI way of thinking...). > > However, I think the issue comes down to a simple question: > are the ISID > and TPGT values or numerical strings (Julian is calling > them numerical > strings, but I've always thought of them as values, in > spite of the fact > that there is no arithmetic done on them - there is > precedent in SCSI for > such thinking, so I'm not completely out in the woods here). > > If they are values, then I'd like to see them formatted for SCSI in > "value form"; if they are strings, then any representation > should be OK. > > > Does that at least get to the core of the issue? > > Jim Hafner > > CAVEAT: I don't think we'd use the iSCSI constructed port > names in those > contexts as device names are better suited for those > purposes, but these > are examples where specification of SCSI port name format > is required. > > > To: Jim Hafner/Almaden/IBM@IBMUS > cc: ips@ece.cmu.edu > Subject: RE: iSCSI: DLB's Comment on SCSI Port Names > > > > Jim, > > My view of this is that either: > - The SCSI Port Name is never going to be used, in which case > it shouldn't be designed to this level of detail. OR > - It's going to be used, and hence is worth designing in a fashion > that is reasonable to use. > I think we're in the second category, and turning the ISID into > hex ASCII (well, UTF-8) so the SCSI port name is a string is > worth doing now to avoid problems when people actually try > to use it. I would have no problems if someone wanted to > pad the string, but I'd make specifying the padding the > responsibility of the protocol/API/situation in which it > was used rather than incorporating the padding into the name. > > Thanks, > --David > > -----Original Message----- > From: Jim Hafner [mailto:hafner@almaden.ibm.com] > Sent: Monday, July 08, 2002 11:42 AM > To: Black_David@emc.com > Cc: ips@ece.cmu.edu > Subject: Re: iSCSI: DLB's Comment on SCSI Port Names > > > > David, > > You wrote: > > >[T.9] 2.4.2 SCSI Architecture Model > > > > The SCSI Port Name is mandatory in iSCSI. When used in SCSI > > parameter data, the SCSI port name MUST be encoded as: > > - The iSCSI Name in UTF-8 format, followed by > > - a comma separator (1 byte), followed by > > - the ASCII character 'i' (for SCSI Initiator Port) or the > > ASCII character 't' (for SCSI Target Port), followed by > > - a comma separator (1 byte), followed by > > - zero to 3 null pad bytes so that the complete format is a > > multiple of four bytes long, followed by > > - the 6byte value of the ISID (for SCSI initiator port) or the > > 2byte value of the portal group tag (for SCSI target port) in > > network byte order (BigEndian). > > > That's a peculiar format with padding nulls in the middle and > > a number concatenated after the padding - for example, it can't > > be passed in iSCSI login without format conversion. How about > > converting the number to 4 or 12 bytes of hex (ASCII characters) > > and moving the padding to the end so the result is actually a > > string, and excluding the padding from the definition of the name? > > This will increase the maximum length of port names, but produce > > names that are easier to deal with. > > Admittedly that's an odd format, however here was the > reason for this > layout. > 1) it's not used directly in iSCSI "Text" strings; it's > intended to be a > description of how this information is packed into a byte array for > representation in "SCSI parameter data" (as it says!) -- > that is, it's > NEVER > "passed in iSCSI login" (in this form). > 2) the padding after the string was to force the binary > values of the > ISID > or PGT to be better word aligned and can be more easily > extracted as a > value > direct from the byte array without conversion. > > What do you think? > > Jim Hafner > > > > > > --=_alternative 004E032AC2256BFA_= Content-Type: text/html; charset="us-ascii"
Marjorie,

I just wanted some spare in case some other syntactic sugar has to be added.
And 223 is 255-32 - In fact I wanted 224 :-)

Julo


"KRUEGER,MARJORIE (HP-Roseville,ex1)" <marjorie_krueger@hp.com>

07/18/2002 05:10 AM

       
        To:        Julian Satran/Haifa/IBM@IBMIL
        cc:        "Ips Reflector (E-mail)" <ips@ece.cmu.edu>
        Subject:        RE: iSCSI: DLB's Comment on SCSI Port Names

       


Julo,
I see you've changed to 223 in the draft, serves me right for not responding
;-) I don't understand why you think it's desirable to limit the name length
to "something more binary"?  And how does 223 accomplish that?

Since the port and node names are strings, they are already a "binary
length" cause they are a multiple of bytes.  I suggest 255 as a max port
name length because many string implementations in different languages and
OSs can most easily deal with string constructs that are a max of 255 bytes
(256 with null terminator).  I'm thinking mostly of management applications,
since they are the entities that will most have to deal with names for the
purpose of assigning resources.

From the point of view of the drivers (which I presume are mostly written in
C) it doesn't really matter that what the name length is, so I see no value
in reducing the max node name to 223 for their benefit.

And why 223 anyway, since it's really 238 now that you've limited the
representation of the ISID to hex format.

> -----Original Message-----
> From: Julian Satran [mailto:Julian_Satran@il.ibm.com]
> Sent: Saturday, July 13, 2002 7:02 PM
> To: ips@ece.cmu.edu
> Subject: RE: iSCSI: DLB's Comment on SCSI Port Names
>
>
> Thanks again - I have restricted the encoding of ISID/TPGT to
> hex (they are
> not both numerical :-))
> Wouldn't it be better to restrict the name length to something more
> "binary" like 223?
>
> Julo
> ----- Forwarded by Julian Satran/Haifa/IBM on 07/14/2002
> 04:54 AM -----
>                                                              
>                                                              
>                
>                       Julian Satran                          
>                                                              
>                
>                                                To:      
> "KRUEGER,MARJORIE (HP-Roseville,ex1)"
> <marjorie_krueger@hp.com>                    
>                       07/12/2002 04:40         cc:      ips
> <ips@ece.cmu.edu>, Julian Satran/Haifa/IBM@IBMIL              
>                  
>                       AM                       From:    
> Julian Satran/Haifa/IBM@Haifa/IBM@IBMIL                      
>                      
>                                                Subject: RE:
> iSCSI: DLB's Comment on SCSI Port Names(Document link: Julian
> Satran - Mail)  
>                                                              
>                                                              
>                
>                                                              
>                                                              
>                
>                                                              
>                                                              
>                
>                                                              
>                                                              
>                
>                                                              
>                                                              
>                
>                                                              
>                                                              
>                
>
>
>
> Marjorie,
>
> Thanks for your complete and timely answer.
>
> Regards,
> Julo
>
>
>                                                              
>                                                              
>                
>                       "KRUEGER,MARJORIE                      
>                                                              
>                
>                       (HP-Roseville,ex1        To:      
> Julian Satran/Haifa/IBM@IBMIL                                
>                      
>                       )"                       cc:       ips
> <ips@ece.cmu.edu>                                            
>                  
>                       <marjorie_krueger        Subject:  RE:
> iSCSI: DLB's Comment on SCSI Port Names                      
>                  
>                       @hp.com>                                
>                                                              
>                
>                                                              
>                                                              
>                
>                       07/11/2002 05:15                        
>                                                              
>                
>                       AM                                      
>                                                              
>                
>                       Please respond to                      
>                                                              
>                
>                       "KRUEGER,MARJORIE                      
>                                                              
>                
>                       (HP-Roseville,ex1                      
>                                                              
>                
>                       )"                                      
>                                                              
>                
>                                                              
>                                                              
>                
>                                                              
>                                                              
>                
>
>
>
> Julo,
> I'm a bit confused as the issues list on your website does
> not have this as
> issue 37, and all I see is issue 9 (where your comment
> appears to imply "no
> change"?)
>
> In any case, here's what I recommend:
>
> In sec 1.1 Definitions change the following definitions to:
>
> I_T Nexus:  the last sentence should be
>
> The I_T nexus can be identified by the conjunction of the
> SCSI port names;
> that is, the I_T nexus identifier is the tuple (iSCSI Initiator Name +
> ',i,'+ ISID, iSCSI Target Name + ',t,'+ Portal Group Tag).
>
> SCSI Port Name: definition should be
>
> A name made up as UTF-8 characters and includes the  iSCSI
> Name + ',i,' or
> ',t,' + ISID or Portal Group Tag
>
> In sec 2.2.7, 1st paragraph, delete the comment in
> parenthesis starting
> with "(for iSCSI,.." (or change it to point it to section 2.4.2, your
> choice).
>
> In sec 2.4.2, change the text to:
>
>   When used in SCSI parameter data, the SCSI port name MUST
> be encoded as:
>       - The iSCSI Name in UTF-8 format, followed by
>       - a comma separator (1 byte), followed by
>       - the ASCII character 'i' (for SCSI Initiator Port) or the
>        ASCII character 't' (for SCSI Target Port), followed by
>       - a comma separator (1 byte), followed by
>       - A string representation (<numerical-value>, see
> section 4.1 Text
> Format)
>        of the ISID (for SCSI initiator port) or the portal
> group tag (for
> SCSI target port).
>        SCSI port names have a maximum length of 255 bytes.
>        The ASCII character 'i' or 't' is the label that
> identifies this
> port
>        as either a SCSI Initiator Port or a SCSI Target Port.
> The 255 max port name makes for a 237 max iSCSI node name
> (check my math
> Jim :-) as the max character representation of an ISID is 15
> characters for
> the largest decimal representation (14 char for the largest
> hex), + 3 char
> (",i,") + 237 = 255
>
> The change in max node name causes changes to:
>
> sec 2.2.6.1, paragraph 2,
> sec 2.2.6.2, 2nd p, 3rd bullet
>
> I will see that a change is proposed to Annex A in whatever SAM doc is
> currently under revision.
>
> Thanks,
> Marjorie Krueger
> Networked Storage Architecture
> Networked Storage Solutions Org.
> Hewlett-Packard
>  -----Original Message-----
>  From: Julian Satran (Actcom) [mailto:Julian_Satran@actcom.net.il]
>  Sent: Tuesday, July 09, 2002 6:44 AM
>  To: KRUEGER,MARJORIE (HP-Roseville,ex1); 'Jim Hafner';
> Black_David@emc.com
>  Cc: ips
>  Subject: Re: iSCSI: DLB's Comment on SCSI Port Names
>
>  Marjorie,
>
>  I'll list this as issue 37 and I think we can settle on 249 :-)
>  I would appreciate if you let me know what constants change
> (in 2.4.2?)
>
>  Julo
>   ----- Original Message -----
>   From: KRUEGER,MARJORIE (HP-Roseville,ex1)
>   To: 'Jim Hafner' ; Black_David@emc.com
>   Cc: ips@ece.cmu.edu
>   Sent: Tuesday, July 09, 2002 4:04 AM
>   Subject: RE: iSCSI: DLB's Comment on SCSI Port Names
>
>   I've just encountered this issue with regards to iSCSI port
> name encoding
>   in the SCSI MIB, and the currently specified port name
> encoding causes
>   inconvenience (at best).  IMO, it makes sense to be able to treat an
>   iSCSI name field, be it device name or port name, the same
> - as a string
>   of display characters, portions of which may contain ASCII-encoded
>   numeric values.
>
>   I don't really see that it makes a difference whether one
> views ISID and
>   TPGT as numeric strings or values, since as Jim says, there are no
>   calculations performed using these things, and they are basicly just
>   "tags".  The issue for me is that the rest of the "SCSI
> port name" is a
>   string and I see no value in "encoding" the ISID or TPGT as
> a value for
>   SCSI purposes, as SCSI should have no need to use the ISID
> or TPGT values
>   separately from the entire port name.  And even if SCSI had
> such a need,
>   it's a simple matter to convert a numeric string representation to a
>   value.
>
>   The downside of a string-encoding is the increased maximum
> size of the
>   SCSI port name.
>
>   If strings over 256 characters are a problem for some
> platforms, I'd be
>   in favor of reducing the max iSCSI node name to 249
> characters so the
>   maximum SCSI port name would be 255 characters total (249
> char name +
>   ",i," + "0x0000")
>
>   Marjorie Krueger
>   Networked Storage Architecture
>   Networked Storage Solutions Org.
>   Hewlett-Packard
>   -----Original Message-----
>   From: Jim Hafner [mailto:hafner@almaden.ibm.com]
>   Sent: Monday, July 08, 2002 9:08 AM
>   To: Black_David@emc.com
>   Cc: ips@ece.cmu.edu
>   Subject: RE: iSCSI: DLB's Comment on SCSI Port Names
>
>
>   David,
>
>   I believe it will (may?) be used, so I agree we're in the
> second case.
>   However, this format is the intended use in SCSI protocol
> stuff.  Two
>   places where SCSI ports names are used now is in ALIAS,
> Access Controls
>   and in third party reservations -- see caveat below, however)
>
>   I don't see a need in this context to define these as
> strings (that's not
>   a SCSI way of thinking...).
>
>   However, I think the issue comes down to a simple question:
>  are the ISID
>   and TPGT values or numerical strings (Julian is calling
> them numerical
>   strings, but I've always thought of them as values, in
> spite of the fact
>   that there is no arithmetic done on them - there is
> precedent in SCSI for
>   such thinking, so I'm not completely out in the woods here).
>
>   If they are values, then I'd like to see them formatted for SCSI in
>   "value form";  if they are strings, then any representation
> should be OK.
>
>
>   Does that at least get to the core of the issue?
>
>   Jim Hafner
>
>   CAVEAT: I don't think we'd use the iSCSI constructed port
> names in those
>   contexts as device names are better suited for those
> purposes, but these
>   are examples where specification of SCSI port name format
> is required.
>
>
>   To:        Jim Hafner/Almaden/IBM@IBMUS
>   cc:        ips@ece.cmu.edu
>   Subject:        RE: iSCSI: DLB's Comment on SCSI Port Names
>
>
>
>   Jim,
>
>   My view of this is that either:
>   - The SCSI Port Name is never going to be used, in which case
>   it shouldn't be designed to this level of detail. OR
>   - It's going to be used, and hence is worth designing in a fashion
>   that is reasonable to use.
>   I think we're in the second category, and turning the ISID into
>   hex ASCII (well, UTF-8) so the SCSI port name is a string is
>   worth doing now to avoid problems when people actually try
>   to use it.  I would have no problems if someone wanted to
>   pad the string, but I'd make specifying the padding the
>   responsibility of the protocol/API/situation in which it
>   was used rather than incorporating the padding into the name.
>
>   Thanks,
>   --David
>
>   -----Original Message-----
>   From: Jim Hafner [mailto:hafner@almaden.ibm.com]
>   Sent: Monday, July 08, 2002 11:42 AM
>   To: Black_David@emc.com
>   Cc: ips@ece.cmu.edu
>   Subject: Re: iSCSI: DLB's Comment on SCSI Port Names
>
>
>
>   David,
>
>   You wrote:
>
>   >[T.9] 2.4.2  SCSI Architecture Model
>   >
>   >  The SCSI Port Name is mandatory in iSCSI. When used in SCSI
>   >  parameter data, the SCSI port name MUST be encoded as:
>   >  - The iSCSI Name in UTF-8 format, followed by
>   >  - a comma separator (1 byte), followed by
>   >  - the ASCII character 'i' (for SCSI Initiator Port) or the
>   >    ASCII character 't' (for SCSI Target Port), followed by
>   >  - a comma separator (1 byte), followed by
>   >  - zero to 3 null pad bytes so that the complete format is a
>   >    multiple of four bytes long, followed by
>   >  - the 6byte value of the ISID (for SCSI initiator port) or the
>   >    2byte value of the portal group tag (for SCSI target port) in
>   >    network byte order (BigEndian).
>
>   > That's a peculiar format with padding nulls in the middle and
>   > a number concatenated after the padding - for example, it can't
>   > be passed in iSCSI login without format conversion.  How about
>   > converting the number to 4 or 12 bytes of hex (ASCII characters)
>   > and moving the padding to the end so the result is actually a
>   > string, and excluding the padding from the definition of the name?
>   > This will increase the maximum length of port names, but produce
>   > names that are easier to deal with.
>
>   Admittedly that's an odd format, however here was the
> reason for this
>   layout.
>   1) it's not used directly in iSCSI "Text" strings; it's
> intended to be a
>   description of how this information is packed into a byte array for
>   representation in "SCSI parameter data" (as it says!) --
> that is, it's
>   NEVER
>   "passed in iSCSI login" (in this form).
>   2) the padding after the string was to force the binary
> values of the
>   ISID
>   or PGT to be better word aligned and can be more easily
> extracted as a
>   value
>   direct from the byte array without conversion.
>
>   What do you think?
>
>   Jim Hafner
>
>
>
>
>
>


--=_alternative 004E032AC2256BFA_=-- From owner-ips@ece.cmu.edu Thu Jul 18 15:02:22 2002 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA10617 for ; Thu, 18 Jul 2002 15:02:22 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id g6IIPY029474 for ips-outgoing; Thu, 18 Jul 2002 14:25:34 -0400 (EDT) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from msgbas2.cos.agilent.com (msgbas2x.cos.agilent.com [192.25.240.37]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id g6IIPWX29470 for ; Thu, 18 Jul 2002 14:25:32 -0400 (EDT) Received: from msgrel1.cos.agilent.com (msgrel1.cos.agilent.com [130.29.152.77]) by msgbas2.cos.agilent.com (Postfix) with ESMTP id 00DBF79F; Thu, 18 Jul 2002 12:25:31 -0600 (MDT) Received: from axcsbh1.cos.agilent.com (axcsbh1.cos.agilent.com [130.29.152.143]) by msgrel1.cos.agilent.com (Postfix) with SMTP id A4A09290; Thu, 18 Jul 2002 12:25:31 -0600 (MDT) Received: from 130.29.152.143 by axcsbh1.cos.agilent.com (InterScan E-Mail VirusWall NT); Thu, 18 Jul 2002 12:25:29 -0600 Received: by axcsbh1.cos.agilent.com with Internet Mail Service (5.5.2653.19) id <355MMAC7>; Thu, 18 Jul 2002 12:25:28 -0600 Message-ID: <9F8400020EC5D311AF62009027C396160902C550@axcs09.cos.agilent.com> From: "LEMAY,KEVIN (A-Roseville,ex1)" To: ips@ece.cmu.edu, "'Satran, Julian'" Subject: iSCSI: Invalid PDU before login PDU - what happens Date: Thu, 18 Jul 2002 12:25:26 -0600 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-ips@ece.cmu.edu Precedence: bulk What is the correct behavior for a target when an initiator sends a full-feature phase PDU before the initial login PDU? I believe that this is: i-> Cmd PDU t-> Login Response - Reject reason = Invalid during login FIN but where is it documented in the Spec? Thanks, Kevin From owner-ips@ece.cmu.edu Thu Jul 18 16:46:17 2002 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA12390 for ; Thu, 18 Jul 2002 16:46:12 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id g6IJrE404652 for ips-outgoing; Thu, 18 Jul 2002 15:53:14 -0400 (EDT) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from mail2.microsoft.com (mail2.microsoft.com [131.107.3.124]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id g6IJrCX04648 for ; Thu, 18 Jul 2002 15:53:12 -0400 (EDT) Received: from INET-VRS-02.redmond.corp.microsoft.com ([157.54.8.110]) by mail2.microsoft.com with Microsoft SMTPSVC(5.0.2195.4905); Thu, 18 Jul 2002 12:53:06 -0700 Received: from 157.54.8.155 by INET-VRS-02.redmond.corp.microsoft.com (InterScan E-Mail VirusWall NT); Thu, 18 Jul 2002 12:53:06 -0700 Received: from red-imc-02.redmond.corp.microsoft.com ([157.54.9.107]) by inet-hub-04.redmond.corp.microsoft.com with Microsoft SMTPSVC(5.0.2195.2966); Thu, 18 Jul 2002 12:53:05 -0700 Received: from win-imc-02.wingroup.windeploy.ntdev.microsoft.com ([157.54.0.84]) by red-imc-02.redmond.corp.microsoft.com with Microsoft SMTPSVC(5.0.2195.4905); Thu, 18 Jul 2002 12:53:05 -0700 Received: from win-msg-03.wingroup.windeploy.ntdev.microsoft.com ([157.54.0.198]) by win-imc-02.wingroup.windeploy.ntdev.microsoft.com with Microsoft SMTPSVC(6.0.3590.0); Thu, 18 Jul 2002 12:52:51 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.0.6249.0 Content-Class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Subject: RE: iSCSI: Invalid PDU before login PDU - what happens Date: Thu, 18 Jul 2002 12:52:51 -0700 Message-ID: Thread-Topic: iSCSI: Invalid PDU before login PDU - what happens thread-index: AcIukun5WGNAoFVmQvqvPy9tm6Sj+wAAa0ug From: "Lakshmi Ramasubramanian" To: "LEMAY,KEVIN (A-Roseville,ex1)" , , "Satran, Julian" X-OriginalArrivalTime: 18 Jul 2002 19:52:51.0935 (UTC) FILETIME=[B36196F0:01C22E94] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ece.cmu.edu id g6IJrCX04649 Sender: owner-ips@ece.cmu.edu Precedence: bulk Content-Transfer-Encoding: 8bit I guess you can use 0x04 (Protocol Error) for Reject reason. -lakshmi -----Original Message----- From: LEMAY,KEVIN (A-Roseville,ex1) [mailto:kevin_lemay@agilent.com] Sent: Thursday, July 18, 2002 11:25 AM To: ips@ece.cmu.edu; 'Satran, Julian' Subject: iSCSI: Invalid PDU before login PDU - what happens What is the correct behavior for a target when an initiator sends a full-feature phase PDU before the initial login PDU? I believe that this is: i-> Cmd PDU t-> Login Response - Reject reason = Invalid during login FIN but where is it documented in the Spec? Thanks, Kevin From owner-ips@ece.cmu.edu Thu Jul 18 18:57:21 2002 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA14666 for ; Thu, 18 Jul 2002 18:57:20 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id g6IMBi612429 for ips-outgoing; Thu, 18 Jul 2002 18:11:44 -0400 (EDT) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from msgbas2.cos.agilent.com (msgbas2x.cos.agilent.com [192.25.240.37]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id g6IMBhX12425 for ; Thu, 18 Jul 2002 18:11:43 -0400 (EDT) Received: from msgrel1.cos.agilent.com (msgrel1.cos.agilent.com [130.29.152.77]) by msgbas2.cos.agilent.com (Postfix) with ESMTP id B19C01726; Thu, 18 Jul 2002 16:11:42 -0600 (MDT) Received: from axcsbh1.cos.agilent.com (axcsbh1.cos.agilent.com [130.29.152.143]) by msgrel1.cos.agilent.com (Postfix) with SMTP id 84815347; Thu, 18 Jul 2002 16:11:42 -0600 (MDT) Received: from 130.29.152.143 by axcsbh1.cos.agilent.com (InterScan E-Mail VirusWall NT); Thu, 18 Jul 2002 16:11:42 -0600 Received: by axcsbh1.cos.agilent.com with Internet Mail Service (5.5.2653.19) id <355MMNRW>; Thu, 18 Jul 2002 16:11:41 -0600 Message-ID: <9F8400020EC5D311AF62009027C396160902C555@axcs09.cos.agilent.com> From: "LEMAY,KEVIN (A-Roseville,ex1)" To: ips@ece.cmu.edu, "'Satran, Julian'" Subject: iSCSI: Question on use of Target Alias Date: Thu, 18 Jul 2002 16:11:32 -0600 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-ips@ece.cmu.edu Precedence: bulk The v15 Working spec says: "If a target has been configured with a human-readable name or description, this name SHOULD be communicated to the initiator dur- ing a Login Response PDU. This string is not used as an identifier, nor is meant to be used for authentication or authorization deci- sions. It can be displayed by the initiator's user interface in a list of targets to which it is connected." I am assuming that this only applies to normal logins? The text says that the key is not sent during the sendTargets operations because in Appendix D, it says: "The response to this command is a text response that contains a list of zero or more targets and, optionally, their addresses. Each tar- get is returned as a target record. A target record begins with the TargetName text key, followed by a list of TargetAddress text keys, and bounded by the end of the text response or the next TargetName key, which begins a new record. No text keys other than TargetName and TargetAddress are permitted within a SendTargets response." So the only valid use of this key is during normal login, correct? Kevin From owner-ips@ece.cmu.edu Thu Jul 18 19:58:24 2002 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA16177 for ; Thu, 18 Jul 2002 19:58:23 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id g6INHBS15319 for ips-outgoing; Thu, 18 Jul 2002 19:17:11 -0400 (EDT) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from d12lmsgate-2.de.ibm.com (d12lmsgate-2.de.ibm.com [195.212.91.200]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id g6INH9X15315 for ; Thu, 18 Jul 2002 19:17:10 -0400 (EDT) Received: from d12relay01.de.ibm.com (d12relay01.de.ibm.com [9.165.215.22]) by d12lmsgate-2.de.ibm.com (8.12.3/8.12.3) with ESMTP id g6INGwSs011148; Fri, 19 Jul 2002 01:16:58 +0200 Received: from d10hubm1.telaviv.ibm.com (d10ml001.telaviv.ibm.com [9.148.216.55]) by d12relay01.de.ibm.com (8.11.1m3/NCO/VER6.2) with ESMTP id g6INFgi21376; Fri, 19 Jul 2002 01:15:42 +0200 To: Brian Forbes Cc: ips@ece.cmu.edu MIME-Version: 1.0 Subject: Re: iSCSI: Brocade Editorial Comments on v14 X-Mailer: Lotus Notes Release 5.0.9 November 16, 2001 From: "Julian Satran" Message-ID: Date: Fri, 19 Jul 2002 03:15:40 +0300 X-MIMETrack: Serialize by Router on D10ML001/10/M/IBM(Release 5.0.9a |January 7, 2002) at 19/07/2002 02:15:42, Serialize complete at 19/07/2002 02:15:42 Content-Type: multipart/alternative; boundary="=_alternative 007F4FF2C2256BFA_=" Sender: owner-ips@ece.cmu.edu Precedence: bulk This is a multipart message in MIME format. --=_alternative 007F4FF2C2256BFA_= Content-Type: text/plain; charset="us-ascii" Brian, Thanks again. I am getting (finally) through some of your editorials. I am tempted to change in 4 responder/response to acceptor/acceptance. How does it sound? Julo Brian Forbes 07/07/2002 09:35 PM Please respond to Brian Forbes To: Julian Satran/Haifa/IBM@IBMIL cc: Subject: iSCSI: Brocade Editorial Comments on v14 Attached is a list of comments on iSCSI version 14. Although they include some certifiable nits, I've tried to focus on things that might keep the reader from understanding the material on the first pass. Pulling the document together remains a Herculean effort; I'm thankful not to be the editor at this point! It requires not only terrific attention to detail, but a great deal of patience and pursuasiveness to get convergence to a final product. Having said that, I'll proceed to test that patience and risk the editor's wrath by listing things I think keep the document from being even more readable: . The topic of login needs an overview section that introduces concepts such as session phases, connection phases, session types, declarations vs. negotiations, and login stages. Much of the terminology is introduced on the fly. More precise and suggestive wording could be used for key exchanges, e.g. 'offer' instead of 'use' or 'receive', and a specific term for the answer to an offer should be defined and used ('selection'?). The terminology of Request and Response continually gets in the way of key exchanges, which can be originated by either end; perhaps an inclusive term such as 'Message' could be used to refer to whichever of the Request/Response duo is appropriate. . There is a great deal of repetition throughout the document, which impacts maintainability as much as readability. For example, the rules for the length of unsolicited data with and without immediate data are covered in several places. As another example, t he fact that 0xffffffff is reserved for TTT is mentioned several times. As a third example, the rules for setting TSIH, etc. to accomplish various flavors of connection/session (re)establishment are covered in multiple places. In the early sections of the document, these are gratuitous details and can be omitted entirely. In intermediate sections, such details are better handled by forward reference to a (single) section where they are defined once. . As a related observation, there should be many more cross-references in a document this size. . There is also repetition of normative text, with the same suggested fixes. I think we all agree that each normative should ideally occur only once. . For readability, any comma-separated list of more than 2 or 3 items should be expressed as a list of bullets instead. Examples abound in the state diagrams. . There are many cases where an English phrase is used as a euphemism for well-defined iSCSI term. One example is the use of a phrase like 'the maximum length of unsolicited data negotiated during login' instead of 'FirstBurstLength'. Such euphemisms might be justified early in an overview, before the iSCSI term has been introduced, but anywhere else it leaves the reader wondering. At a minimum, euphemisms should be supplemented by appending the iSCSI term in parentheses, and in many cases a forward section reference is also in order. It also suggests that more iSCSI terms should be introduced (but not necessarily defined in detail) earlier in the text; e.g. frequently-mentioned key names. . There are several examples of gratuitous terminology. Example: the term 'task failover' is used a couple of times but the majority of text talks about 'connectiono allegiance'. Example: the term 'decommissioning' is used for vis-a-vis connections, but only 3 times. . There seem to be cases where new terminology/notation would be very useful. There are many phrases of the form 'an X having the Y bit set to 1'; when multiples of these appear in the same sentence-and they do- parsing becomes difficult. One could define a flavor of X that implies having the Y bit set; e.g. one could define a 'final Data-out PDU' as a PDU having the F bit set. Another example: one could define a 'completed sequence' as a sequence of PDUs where the last or only PDU has the F bit set'. . Several sections are quite long and contain multiple topics, e.g. section 2.2.4. Ideally, any section longer than a page should be broken up, especially if there is no other relief such as tables, bullets, or diagrams. I don't expect to see many of these addressed immediately, but hope they might be kept in mind if there is ever a lull in the proceedings. Regards, Brian Forbes Technology Brocade Communications #### mime001.txt has been deleted (was saved in repository My Attachments Repository ->) from this note on 09 July 2002 by Julian Satran --=_alternative 007F4FF2C2256BFA_= Content-Type: text/html; charset="us-ascii"
Brian,

Thanks again. I am getting (finally) through some of your editorials.
I am tempted to change in 4 responder/response to acceptor/acceptance.

How does it sound?

Julo


Brian Forbes <bforbes@brocade.com>

07/07/2002 09:35 PM
Please respond to Brian Forbes

       
        To:        Julian Satran/Haifa/IBM@IBMIL
        cc:        
        Subject:        iSCSI: Brocade Editorial Comments on v14

       



Attached is a list of comments on iSCSI version 14.  Although they include
some certifiable nits, I've tried to focus on things that might keep the
reader from understanding the material on the first pass.
Pulling the document together remains a Herculean effort; I'm thankful not
to be the editor at this point!  It requires not only terrific attention to
detail, but a great deal of patience and pursuasiveness to get convergence
to a final product.
Having said that, I'll proceed to test that patience and risk the editor's
wrath by listing things I think keep the document from being even more
readable:
.        The topic of login needs an overview section that introduces
concepts such as session phases, connection phases, session types,
declarations vs. negotiations, and login stages.  Much of the terminology is
introduced on the fly.  More precise and suggestive wording could be used
for key exchanges, e.g. 'offer' instead of 'use' or 'receive', and a
specific term for the answer to an offer should be defined and used
('selection'?).  The terminology of Request and Response continually gets in
the way of key exchanges, which can be originated by either end; perhaps an
inclusive term such as 'Message' could be used to refer to whichever of the
Request/Response duo is appropriate.
.        There is a great deal of repetition throughout the document, which
impacts maintainability as much as readability.  For example, the rules for
the length of unsolicited data with and without immediate data are covered
in several places.  As another example, t he fact that 0xffffffff is
reserved for TTT is mentioned several times.  As a third example, the rules
for setting TSIH, etc. to accomplish various flavors of connection/session
(re)establishment are covered in multiple places.  In the early sections of
the document, these are gratuitous details and can be omitted entirely.  In
intermediate sections, such details are better handled by forward reference
to a (single) section where they are defined once.
.        As a related observation, there should be many more cross-references
in a document this size.
.        There is also repetition of normative text, with the same suggested
fixes.  I think we all agree that each normative should ideally occur only
once.
.        For readability, any comma-separated list of more than 2 or 3 items
should be expressed as a list of bullets instead.  Examples abound in the
state diagrams.
.        There are many cases where an English phrase is used as a euphemism
for well-defined iSCSI term.  One example is the use of a phrase like 'the
maximum length of unsolicited data negotiated during login' instead of
'FirstBurstLength'.  Such euphemisms might be justified early in an
overview, before the iSCSI term has been introduced, but anywhere else it
leaves the reader wondering.  At a minimum, euphemisms should be
supplemented by appending the iSCSI term in parentheses, and in many cases a
forward section reference is also in order.  It also suggests that more
iSCSI terms should be introduced (but not necessarily defined in detail)
earlier in the text; e.g. frequently-mentioned key names.
.        There are several examples of gratuitous terminology.  Example:  the
term 'task failover' is used a couple of times but the majority of text
talks about 'connectiono allegiance'.  Example:  the term 'decommissioning'
is used for vis-a-vis connections, but only 3 times.
.        There seem to be cases where new terminology/notation would be very
useful.  There are many phrases of the form 'an X having the Y bit set to
1'; when multiples of these appear in the same sentence-and they do- parsing
becomes difficult.  One could define a flavor of X that implies having the Y
bit set; e.g. one could define a 'final Data-out PDU' as a PDU having the F
bit set.  Another example: one could define a 'completed sequence' as a
sequence of PDUs where the last or only PDU has the F bit set'.
.        Several sections are quite long and contain multiple topics, e.g.
section 2.2.4.  Ideally, any section longer than a page should be broken up,
especially if there is no other relief such as tables, bullets, or diagrams.

I don't expect to see many of these addressed immediately, but hope they
might be kept in mind if there is ever a lull in the proceedings.
Regards,

Brian Forbes
Technology
Brocade Communications



#### mime001.txt has been deleted (was saved in repository My Attachments Repository ->Link) from this note on 09 July 2002 by Julian Satran

--=_alternative 007F4FF2C2256BFA_=-- From owner-ips@ece.cmu.edu Thu Jul 18 19:58:40 2002 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA16192 for ; Thu, 18 Jul 2002 19:58:40 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id g6INH9g15313 for ips-outgoing; Thu, 18 Jul 2002 19:17:09 -0400 (EDT) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from d12lmsgate-2.de.ibm.com (d12lmsgate-2.de.ibm.com [195.212.91.200]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id g6INH8X15309 for ; Thu, 18 Jul 2002 19:17:08 -0400 (EDT) Received: from d12relay01.de.ibm.com (d12relay01.de.ibm.com [9.165.215.22]) by d12lmsgate-2.de.ibm.com (8.12.3/8.12.3) with ESMTP id g6INGxSs014800; Fri, 19 Jul 2002 01:16:59 +0200 Received: from d10hubm1.telaviv.ibm.com (d10ml001.telaviv.ibm.com [9.148.216.55]) by d12relay01.de.ibm.com (8.11.1m3/NCO/VER6.2) with ESMTP id g6INFhi21378; Fri, 19 Jul 2002 01:15:43 +0200 To: Brian Forbes Cc: ips@ece.cmu.edu MIME-Version: 1.0 Subject: Re: iSCSI: Brocade Editorial Comments on v14 X-Mailer: Lotus Notes Release 5.0.9 November 16, 2001 From: "Julian Satran" Message-ID: Date: Fri, 19 Jul 2002 03:15:41 +0300 X-MIMETrack: Serialize by Router on D10ML001/10/M/IBM(Release 5.0.9a |January 7, 2002) at 19/07/2002 02:15:43, Serialize complete at 19/07/2002 02:15:43 Content-Type: multipart/alternative; boundary="=_alternative 007FB528C2256BFA_=" Sender: owner-ips@ece.cmu.edu Precedence: bulk This is a multipart message in MIME format. --=_alternative 007FB528C2256BFA_= Content-Type: text/plain; charset="us-ascii" Or even make it: propose/proposer - accept/acceptor Julo ----- Forwarded by Julian Satran/Haifa/IBM on 07/19/2002 02:13 AM ----- Julian Satran 07/19/2002 02:10 AM To: Brian Forbes cc: ips@ece.cmu.edu From: Julian Satran/Haifa/IBM@IBMIL Subject: Re: iSCSI: Brocade Editorial Comments on v14 Brian, Thanks again. I am getting (finally) through some of your editorials. I am tempted to change in 4 responder/response to acceptor/acceptance. How does it sound? Julo Brian Forbes 07/07/2002 09:35 PM Please respond to Brian Forbes To: Julian Satran/Haifa/IBM@IBMIL cc: Subject: iSCSI: Brocade Editorial Comments on v14 Attached is a list of comments on iSCSI version 14. Although they include some certifiable nits, I've tried to focus on things that might keep the reader from understanding the material on the first pass. Pulling the document together remains a Herculean effort; I'm thankful not to be the editor at this point! It requires not only terrific attention to detail, but a great deal of patience and pursuasiveness to get convergence to a final product. Having said that, I'll proceed to test that patience and risk the editor's wrath by listing things I think keep the document from being even more readable: . The topic of login needs an overview section that introduces concepts such as session phases, connection phases, session types, declarations vs. negotiations, and login stages. Much of the terminology is introduced on the fly. More precise and suggestive wording could be used for key exchanges, e.g. 'offer' instead of 'use' or 'receive', and a specific term for the answer to an offer should be defined and used ('selection'?). The terminology of Request and Response continually gets in the way of key exchanges, which can be originated by either end; perhaps an inclusive term such as 'Message' could be used to refer to whichever of the Request/Response duo is appropriate. . There is a great deal of repetition throughout the document, which impacts maintainability as much as readability. For example, the rules for the length of unsolicited data with and without immediate data are covered in several places. As another example, t he fact that 0xffffffff is reserved for TTT is mentioned several times. As a third example, the rules for setting TSIH, etc. to accomplish various flavors of connection/session (re)establishment are covered in multiple places. In the early sections of the document, these are gratuitous details and can be omitted entirely. In intermediate sections, such details are better handled by forward reference to a (single) section where they are defined once. . As a related observation, there should be many more cross-references in a document this size. . There is also repetition of normative text, with the same suggested fixes. I think we all agree that each normative should ideally occur only once. . For readability, any comma-separated list of more than 2 or 3 items should be expressed as a list of bullets instead. Examples abound in the state diagrams. . There are many cases where an English phrase is used as a euphemism for well-defined iSCSI term. One example is the use of a phrase like 'the maximum length of unsolicited data negotiated during login' instead of 'FirstBurstLength'. Such euphemisms might be justified early in an overview, before the iSCSI term has been introduced, but anywhere else it leaves the reader wondering. At a minimum, euphemisms should be supplemented by appending the iSCSI term in parentheses, and in many cases a forward section reference is also in order. It also suggests that more iSCSI terms should be introduced (but not necessarily defined in detail) earlier in the text; e.g. frequently-mentioned key names. . There are several examples of gratuitous terminology. Example: the term 'task failover' is used a couple of times but the majority of text talks about 'connectiono allegiance'. Example: the term 'decommissioning' is used for vis-a-vis connections, but only 3 times. . There seem to be cases where new terminology/notation would be very useful. There are many phrases of the form 'an X having the Y bit set to 1'; when multiples of these appear in the same sentence-and they do- parsing becomes difficult. One could define a flavor of X that implies having the Y bit set; e.g. one could define a 'final Data-out PDU' as a PDU having the F bit set. Another example: one could define a 'completed sequence' as a sequence of PDUs where the last or only PDU has the F bit set'. . Several sections are quite long and contain multiple topics, e.g. section 2.2.4. Ideally, any section longer than a page should be broken up, especially if there is no other relief such as tables, bullets, or diagrams. I don't expect to see many of these addressed immediately, but hope they might be kept in mind if there is ever a lull in the proceedings. Regards, Brian Forbes Technology Brocade Communications #### mime001.txt has been deleted (was saved in repository My Attachments Repository ->) from this note on 09 July 2002 by Julian Satran --=_alternative 007FB528C2256BFA_= Content-Type: text/html; charset="us-ascii"
Or even make it:

propose/proposer - accept/acceptor

Julo
----- Forwarded by Julian Satran/Haifa/IBM on 07/19/2002 02:13 AM -----
Julian Satran

07/19/2002 02:10 AM


        To:        Brian Forbes <bforbes@brocade.com>
        cc:        ips@ece.cmu.edu
        From:        Julian Satran/Haifa/IBM@IBMIL
        Subject:        Re: iSCSI: Brocade Editorial Comments on v14Link
 





Brian,

Thanks again. I am getting (finally) through some of your editorials.
I am tempted to change in 4 responder/response to acceptor/acceptance.

How does it sound?

Julo


Brian Forbes <bforbes@brocade.com>

07/07/2002 09:35 PM
Please respond to Brian Forbes

       
        To:        Julian Satran/Haifa/IBM@IBMIL
        cc:        
        Subject:        iSCSI: Brocade Editorial Comments on v14

       



Attached is a list of comments on iSCSI version 14.  Although they include
some certifiable nits, I've tried to focus on things that might keep the
reader from understanding the material on the first pass.
Pulling the document together remains a Herculean effort; I'm thankful not
to be the editor at this point!  It requires not only terrific attention to
detail, but a great deal of patience and pursuasiveness to get convergence
to a final product.
Having said that, I'll proceed to test that patience and risk the editor's
wrath by listing things I think keep the document from being even more
readable:
.        The topic of login needs an overview section that introduces
concepts such as session phases, connection phases, session types,
declarations vs. negotiations, and login stages.  Much of the terminology is
introduced on the fly.  More precise and suggestive wording could be used
for key exchanges, e.g. 'offer' instead of 'use' or 'receive', and a
specific term for the answer to an offer should be defined and used
('selection'?).  The terminology of Request and Response continually gets in
the way of key exchanges, which can be originated by either end; perhaps an
inclusive term such as 'Message' could be used to refer to whichever of the
Request/Response duo is appropriate.
.        There is a great deal of repetition throughout the document, which
impacts maintainability as much as readability.  For example, the rules for
the length of unsolicited data with and without immediate data are covered
in several places.  As another example, t he fact that 0xffffffff is
reserved for TTT is mentioned several times.  As a third example, the rules
for setting TSIH, etc. to accomplish various flavors of connection/session
(re)establishment are covered in multiple places.  In the early sections of
the document, these are gratuitous details and can be omitted entirely.  In
intermediate sections, such details are better handled by forward reference
to a (single) section where they are defined once.
.        As a related observation, there should be many more cross-references
in a document this size.
.        There is also repetition of normative text, with the same suggested
fixes.  I think we all agree that each normative should ideally occur only
once.
.        For readability, any comma-separated list of more than 2 or 3 items
should be expressed as a list of bullets instead.  Examples abound in the
state diagrams.
.        There are many cases where an English phrase is used as a euphemism
for well-defined iSCSI term.  One example is the use of a phrase like 'the
maximum length of unsolicited data negotiated during login' instead of
'FirstBurstLength'.  Such euphemisms might be justified early in an
overview, before the iSCSI term has been introduced, but anywhere else it
leaves the reader wondering.  At a minimum, euphemisms should be
supplemented by appending the iSCSI term in parentheses, and in many cases a
forward section reference is also in order.  It also suggests that more
iSCSI terms should be introduced (but not necessarily defined in detail)
earlier in the text; e.g. frequently-mentioned key names.
.        There are several examples of gratuitous terminology.  Example:  the
term 'task failover' is used a couple of times but the majority of text
talks about 'connectiono allegiance'.  Example:  the term 'decommissioning'
is used for vis-a-vis connections, but only 3 times.
.        There seem to be cases where new terminology/notation would be very
useful.  There are many phrases of the form 'an X having the Y bit set to
1'; when multiples of these appear in the same sentence-and they do- parsing
becomes difficult.  One could define a flavor of X that implies having the Y
bit set; e.g. one could define a 'final Data-out PDU' as a PDU having the F
bit set.  Another example: one could define a 'completed sequence' as a
sequence of PDUs where the last or only PDU has the F bit set'.
.        Several sections are quite long and contain multiple topics, e.g.
section 2.2.4.  Ideally, any section longer than a page should be broken up,
especially if there is no other relief such as tables, bullets, or diagrams.

I don't expect to see many of these addressed immediately, but hope they
might be kept in mind if there is ever a lull in the proceedings.
Regards,

Brian Forbes
Technology
Brocade Communications



#### mime001.txt has been deleted (was saved in repository My Attachments Repository ->Link) from this note on 09 July 2002 by Julian Satran



--=_alternative 007FB528C2256BFA_=-- From owner-ips@ece.cmu.edu Thu Jul 18 20:37:34 2002 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA16711 for ; Thu, 18 Jul 2002 20:37:34 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id g6INqst16731 for ips-outgoing; Thu, 18 Jul 2002 19:52:54 -0400 (EDT) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from osmtp1.electric.net (osmtp3.electric.net [216.129.90.30]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id g6INqqX16727 for ; Thu, 18 Jul 2002 19:52:52 -0400 (EDT) Received: from [133.93.79.129] (helo=EGRodriguez) by osmtp1.electric.net with asmtp (Exim 3.22 #1) id 17VL4l-0008HS-04; Thu, 18 Jul 2002 16:52:51 -0700 From: "Elizabeth G. Rodriguez" To: "'Julian Satran'" , Subject: RE: iSCSI - first working group Last Call round issues list and resolutions Date: Thu, 18 Jul 2002 18:49:20 -0600 Keywords: IETF-IPS Message-ID: <005d01c22ebe$216a8c50$814f5d85@EGRodriguez> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.3416 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 In-reply-to: Importance: Normal Sender: owner-ips@ece.cmu.edu Precedence: bulk Content-Transfer-Encoding: 7bit Hi all, While the attachment probably went thru for most people, David and I wanted to resend as inline text, to make sure everyone sees this. This is the list of comment resolutions for comments from the first iSCSI WG last call. It is up to date thru changes made on July 18. People should review this list, especially those who made iSCSI WG last call comments. The working version of the next version of the draft is available at Julian's web site at http://www.haifa.il.ibm.com/satran/ips People should be reviewing the deltas to this document, and bringing up issues with any modifications to this document. There are still a few issues that are still being addressed, and these are noted in this document. The list of issues and resolutions follow. Thanks Elizabeth iSCSI - WG - Last Call - Issues and Resolution # Description Resolution ---+----------------------------------------------------------+--------- -------------------- 1 | Wording in 4.2 for empty Text Request/Response | Changed wording ---+----------------------------------------------------------+--------- -------------------- 2 | wording for waiting for data in 9.17 | Added words ---+----------------------------------------------------------+--------- -------------------- 3 | wording for connection clearing after retry in 2.2.2.1 | Changed wording ---+----------------------------------------------------------+--------- -------------------- 4 | link command complete mappes also to 0x00 in 9.4.3 | added it to mapping ---+----------------------------------------------------------+--------- -------------------- 5 | Stray reference to IPV6 dotted decimal on page 250 | removed ---+----------------------------------------------------------+--------- -------------------- 6 | Text in 4.3 and 4.4 not allowing SendTargets | fixed text ---+----------------------------------------------------------+--------- -------------------- 7 | Clarification on COLD RESET - required by SAM | fixed text ---+----------------------------------------------------------+--------- -------------------- 8 | 9.5.4 Initiator (Task Tag) to be replaced by Referenced | fixed text ---+----------------------------------------------------------+--------- -------------------- 9 | 9.5 recommendation on empty data inconsistent with R2T | fixed text ---+----------------------------------------------------------+--------- -------------------- 10 | 2.2.2.3 and 9.8.1 and 9.7 text numbering data/r2t | fixed text ---+----------------------------------------------------------+--------- -------------------- 11 | 5.2 Text not clear about connection logout mandated | added text ---+----------------------------------------------------------+--------- -------------------- 12 | 9.4.6.2 text reffers only to firstburstsize | changed text to "incorrect | | amount of data" ---+----------------------------------------------------------+--------- -------------------- 13 | Both Length and Size used in text - requested use of | Changed Size in text | of only one of them | to Length ---+----------------------------------------------------------+--------- -------------------- 14 | Not clear how to number retransmitted Data-In | Added text to 9.16 ---+----------------------------------------------------------+--------- -------------------- 15 | Concluding text in 4.3.2 consideered unclear | Slightly changed text ---+----------------------------------------------------------+--------- -------------------- 16 | Say Reject PDU when the intent is Reject PDU | Added PDU when Reject PDU was | | meant and lower case reject ---+----------------------------------------------------------+--------- -------------------- 17 | Reinstate I bit in text request (typo) | Fixed figure ---+----------------------------------------------------------+--------- -------------------- 18 | C bit relation to T and F bit "MUST" not "must" | Fixed text ---+----------------------------------------------------------+--------- -------------------- 19 | I bit on a Text negotiation the same | Added to text ---+----------------------------------------------------------+--------- -------------------- 20 | Lingering reference to referenced task tag in 2.5.1.4 | Removed ---+----------------------------------------------------------+--------- -------------------- 21 | StatSN is retransmitted R2T should be the new value | fixed text in 9.16 ---+----------------------------------------------------------+--------- -------------------- 22 | REf. Task Tag to replace ITT in 9.5.4 and 9.6.1 | fixed text ---+----------------------------------------------------------+--------- -------------------- 23 | Old reference to ACL | Removed ---+----------------------------------------------------------+--------- -------------------- 24 | Confusion about digest position | Spell-out digest names ---+----------------------------------------------------------+--------- -------------------- 25 | Async Message - Logout Request timer handling | Fixed in appendix E ---+----------------------------------------------------------+--------- -------------------- 26 | Numeric instead of Numerical in Appendix A | Fixed text ---+----------------------------------------------------------+--------- -------------------- 27 | Error in DefaultTime2Wait spec | Fixed text and changed format ---+----------------------------------------------------------+--------- -------------------- 28 | Correction of DefaultTime2Wait and reformat | Fiexed and reformated ---+----------------------------------------------------------+--------- -------------------- 29 | Security aligned with security draft | Aligned ---+----------------------------------------------------------+--------- -------------------- 30 | Command queue missunderstanding | Fixed text in 6.1.2 ---+----------------------------------------------------------+--------- -------------------- ======================================================================== ==================== Draft 13 to 14 - Watershed ======================================================================== ==================== ---+----------------------------------------------------------+--------- -------------------- 30 | Requirement to support 16kB total key=value text | Agreed to 8k limit | considered excessive - reduction (to 2k?) proposed | ---+----------------------------------------------------------+--------- -------------------- 31 | 64 bit decimals considered difficult | leave as is ---+----------------------------------------------------------+--------- -------------------- 32 | Decimal encoded binary are harmfull | an entrenched evil | | restrict them to given length ---+----------------------------------------------------------+--------- -------------------- 33 | Combined device (target and IPsec) made explicit | Added text to 7.3 ---+----------------------------------------------------------+--------- -------------------- 34 | TargePortalGroupTag is a 16 bit binary - not numeric | Fixed text in text to 11.9 ---+----------------------------------------------------------+--------- -------------------- 35 | IPsec implementation in a "combined-device" has to be | Spelled out in 7.3 | spelled out | ---+----------------------------------------------------------+--------- -------------------- 36 | Boolean functions not spelled out | Spelled out in 11 ---+----------------------------------------------------------+--------- -------------------- 37 | Boolean functions not spelled out | Spelled out in 11 ---+----------------------------------------------------------+--------- -------------------- 38 | Remove BiDiR2T key | --- ---+----------------------------------------------------------+--------- -------------------- 39 | Offset of Immediate data | spelled out in 2.2.4 ---+----------------------------------------------------------+--------- -------------------- 40 | 11.8 Portal Group Tag ommited/required | made it MUST ---+----------------------------------------------------------+--------- -------------------- ======================================================================== ==================== DLB's issues with their own numbering ======================================================================== ==================== ---+----------------------------------------------------------+--------- -------------------- T1 | 2.2.2.2 recovery MUST be undertaken | fixed text ---+----------------------------------------------------------+--------- -------------------- ---+----------------------------------------------------------+--------- -------------------- T2 | 2.2.6.1 target name may be ignored- replace with | fixed text | MAY be omitted | ---+----------------------------------------------------------+--------- -------------------- T3 | 2.2.6.1 upper case MUST in name requirements | fixed text | and in encoding | ---+----------------------------------------------------------+--------- -------------------- T4 | 2.2.6.3.1 .iqn - needs date unammbiguous | fixed based on DLB ---+----------------------------------------------------------+--------- -------------------- T5 | Synch and Steering bloated - for what we choose | fixed text | WHAT a WASTE of EFFORT! | ---+----------------------------------------------------------+--------- -------------------- T6 | Clarify text in 2.3 about discovery | Changed MAY accept to | | equivalent MUST ONLY and | | spelled-out rejects | | MUST stays - nothing fancy | | in discovery ---+----------------------------------------------------------+--------- -------------------- T7 | Portal defined by IP address does work through NAPT | It is not a protocol | | element - rather a model | | entity. In case of NAPT the | | model entity name may change ---+----------------------------------------------------------+--------- -------------------- T8 |2-concerns - the underlying issue stems from an obsolete | Removed port specific mode | port specific mode page notion - iSCSI has none | replaced text with session | parameters | params and removed 2.4.3.2 ---+----------------------------------------------------------+--------- -------------------- T9 |SCSI port name inapropriate | The encoding is meant for SCSI | | and it has no padding in the | | middle - CHANGED ENCODING ---+----------------------------------------------------------+--------- -------------------- T10|2.4.3.2 - should not uppercased | 2.4.3.2 is obsolete ---+----------------------------------------------------------+--------- -------------------- T11| Decimal to binary | limited to numbers that are | | allowed values less than 2**64 | | and bitstring with defined | | length less than 2**64 ---+----------------------------------------------------------+--------- -------------------- T12| large-numerical-value does not cover lower than 2**64 | large are on purpose | | different in order to restrict | | them ---+----------------------------------------------------------+--------- -------------------- T13|=30 and clarify when 64k has to be supported | fixed text for 64k support ---+----------------------------------------------------------+--------- -------------------- T14| Declaration not explained | added a statement to 4.2 ---+----------------------------------------------------------+--------- -------------------- T15| Make TPGT return on login MUST always | MUST sticks ---+----------------------------------------------------------+--------- -------------------- T16| Second connection issue | I did not use SHOULD as | | there are recovery scenarios | | that do not need a second | | connection. | | MUST in 4.3.4 | | Rest of text is consistent ---+----------------------------------------------------------+--------- -------------------- T17| Format Error - 6.4 | Examples are out of place | | and have been removed | | legal values are specified | | in chapter 9 ---+----------------------------------------------------------+--------- -------------------- T18| Text on abort after an ULP timeout | Fixed text. There is only | | one specific Abort Task ---+----------------------------------------------------------+--------- -------------------- T19| Conservative reuse in 8.1.1 SHOULd is appropriate | changed to SHOULD | | SCSI reference already i ---+----------------------------------------------------------+--------- -------------------- T20| MUST support and use autosense in 8.2 | fixed text ---+----------------------------------------------------------+--------- -------------------- T21| Guidance for timeouts in 8.3 set too low | raised ---+----------------------------------------------------------+--------- -------------------- T22| Padding replace SHOULD with MUST be sent as 0 | why is that better? | | receiver always ignores pad | | testing is implicit in CRC ---+----------------------------------------------------------+--------- -------------------- T23|o, u etc not exclusive is a protocol error | made it explicit ---+----------------------------------------------------------+--------- -------------------- T24| Residual Counts should be reserved when not valid | fixed text ---+----------------------------------------------------------+--------- -------------------- T25| Task reassign may need LUN | No - we dont want checks if | | we can avoid them ---+----------------------------------------------------------+--------- -------------------- T26| Add Task Reassign to list of responses | Fixed ---+----------------------------------------------------------+--------- -------------------- T27| ExpStatSN spell out for non-first | spelled out | Additional concern CmdSN | Login is immediate ---+----------------------------------------------------------+--------- -------------------- T28| Concern about discarding | Discarding refers only to | | REORDERING QUEUE | | changed wording ---+----------------------------------------------------------+--------- -------------------- T29| Logout request request refers to implict login | made the text clearer and | | added a cross reference from | | 9.12.8 ---+----------------------------------------------------------+--------- -------------------- T30| Resegmenting may come as a surprize - suggested a | New text for resegmentation | different request | 9.4 and 9.16 ---+----------------------------------------------------------+--------- -------------------- T31| Operational Error Level instead of supported | Fixed text ---+----------------------------------------------------------+--------- -------------------- T32| Vendor Specific Authentication contradictory statement | Fixed text in 10 ---+----------------------------------------------------------+--------- -------------------- T33| MD5 SHOULD be offered change to MUST for interop. | made MUST ---+----------------------------------------------------------+--------- -------------------- T34| Digests CRC MUST be offered | fixed text ---+----------------------------------------------------------+--------- -------------------- T35| Target and Initiator name not changed | There is a general restriction | | about restating a key except | | when allowed and those are not | | allowed - I added text anyhow ---+----------------------------------------------------------+--------- -------------------- T36| TargetAlias/InitiatorAlias warning | Only a weak one possible as | | it can't be enforced ---+----------------------------------------------------------+--------- -------------------- T37| Unsolicited data inclarity | Already speced in 2.2.4 ---+----------------------------------------------------------+--------- -------------------- T38| IANA text | Fixed - why is that technical ---+----------------------------------------------------------+--------- -------------------- T39| IANA registry for keys | Proposed formulation for | | vendor keys and options | | Read carefully ---+----------------------------------------------------------+--------- -------------------- ======================================================================== ==================== ER issues with their own numbering ======================================================================== ==================== ---+----------------------------------------------------------+--------- -------------------- E1 | Version number out of place | There was a complaint | | it is hidden and it should | | the next place may the title ---+----------------------------------------------------------+--------- -------------------- E2 | use of may in the text on pag 36 3rd paragraph | even after reareading author | | would not use MAY and MUST ---+----------------------------------------------------------+--------- -------------------- E3 | 2.2.2.2 replace SHOULD not exceed 2**31-1 with MUST | fixed text ---+----------------------------------------------------------+--------- -------------------- E4 | wordsmithing the second paragraph on pg. 41 | may is used here as "can do" | | and the explanation is | | accurate ---+----------------------------------------------------------+--------- -------------------- E5 | EUI64 is not used by FC directly | fixed text in 2.2.6 ---+----------------------------------------------------------+--------- -------------------- E6 | Caution on EUI64 used as iSCSI names are not tied to | Added text to 8.1.2 | hardware | ---+----------------------------------------------------------+--------- -------------------- E7 | T and F used in 4 without being defined | defined in introduction to 4 ---+----------------------------------------------------------+--------- -------------------- E8 | Number figure and tables | no before last call - tool ---+----------------------------------------------------------+--------- -------------------- E9 | move 5.1.3 & to fron (5.1.1 & 2) | will give it a try! | | it is not consistent though! ---+----------------------------------------------------------+--------- -------------------- E10| 6.1.2 SHOULD and MAY issue | the intent is to avoid | |data and better avoid dropping! | |removed MAY; wording MAY | |contradicts SHOULD ---+----------------------------------------------------------+--------- -------------------- E11| Optional to OPTIONAL in 6.1.2 |fixed text ---+----------------------------------------------------------+--------- -------------------- E12| MUST etc. should refer to case when used | Added text at the start | | of 6.12 ---+----------------------------------------------------------+--------- -------------------- E13| MUST, MAY in 7.2 | fixed text although | | unequivocal even before ---+----------------------------------------------------------+--------- -------------------- E14| 8.1.1 should -> SHOULD | already there ---+----------------------------------------------------------+--------- -------------------- E15| Conservative Reuse - change to SHOULD | it was agreed as recommended | | no RECOMMENDED ---+----------------------------------------------------------+--------- -------------------- E14| Configurable SHOULD in 8.1.2 | fixed text ---+----------------------------------------------------------+--------- -------------------- E15| Vendor MUST allow ISID coordination | fixed text ---+----------------------------------------------------------+--------- -------------------- E16| Why padding is SHOULD be 0 nad not MUST? | not strictly required | | some strictly secure things | | may want them random! ---+----------------------------------------------------------+--------- -------------------- E17| Initiator and Target note? | In iSCSI they must be 2 | | entities ---+----------------------------------------------------------+--------- -------------------- E18| 9.4 MUST contain sense data | fixed text ---+----------------------------------------------------------+--------- -------------------- E19| Add wording to stress the fact that reset is on all LUs | Added wording on 9.5 that | | reset is accross all LUs | | known to the initiator ---+----------------------------------------------------------+--------- -------------------- E20| Wording that the A bit MUST not be set for ErrorRecovery| Why? The alternative could | Level is 0 | be bit is set to 0 by target | | and ignored by I (no test!) ---+----------------------------------------------------------+--------- -------------------- E21| 9.11.1 why MUST NOT ... that may | text is correct - other | | wording perhaps? ---+----------------------------------------------------------+--------- -------------------- E22| Make a single section for version | well if it looks better for | | at least one reader :-) ---+----------------------------------------------------------+--------- -------------------- E23| 9.14.5 make internal check must not MUST | changed text to indicate | | command ordering is aimed ---+----------------------------------------------------------+--------- -------------------- E24| 9.16.1 SNACK relation to ErrorRecoveryLevel in 9.16 | State that all SNACK have | | to be supported if | | if ErrorRecoveryLevel>0 ---+----------------------------------------------------------+--------- -------------------- E25| Reject Status text in 9.16.1 confusing | added text for ErrorRecoVery | | Level ---+----------------------------------------------------------+--------- -------------------- E26| MUST in 10.1 | fixed text ---+----------------------------------------------------------+--------- -------------------- E27| MUST for CHAP | fixed text (as in T33) ---+----------------------------------------------------------+--------- -------------------- E28| SHOULD/may in Initiator and Target Alias in 11 | fixed see also T36 ---+----------------------------------------------------------+--------- -------------------- E29| 11.8 replace port with reference to IANA cons. | ---+----------------------------------------------------------+--------- -------------------- E30| Phrasing for immediate data - MUST? | might be confusing - suggest | | leave as it is ---+----------------------------------------------------------+--------- -------------------- E31| Immediate & R2T - more explanation | there is a table ---+----------------------------------------------------------+--------- -------------------- E32| Addition to Copyright! IP Rights Notices | Added ---+----------------------------------------------------------+--------- -------------------- -----Original Message----- From: owner-ips@ece.cmu.edu [mailto:owner-ips@ece.cmu.edu] On Behalf Of Julian Satran Sent: Thursday, July 18, 2002 7:21 AM To: ips@ece.cmu.edu Subject: iSCSI - first working group Last Call round issues list and resolutions Dear colleagues, The list of issues raised and their resolution is attached. The working version of draft 15 is still up for review on my site. Julo From owner-ips@ece.cmu.edu Fri Jul 19 09:30:33 2002 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA07658 for ; Fri, 19 Jul 2002 09:30:28 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id g6JChbH21929 for ips-outgoing; Fri, 19 Jul 2002 08:43:37 -0400 (EDT) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from mail.ivivity.com ([64.238.111.99]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id g6JChaX21925 for ; Fri, 19 Jul 2002 08:43:36 -0400 (EDT) Received: by ATLOPS with Internet Mail Service (5.5.2653.19) id ; Fri, 19 Jul 2002 08:43:35 -0400 Message-ID: From: Eddy Quicksall To: Black_David@emc.com Cc: ips@ece.cmu.edu Subject: RE: iSCSI: freeing resources during data-in and r2t Date: Fri, 19 Jul 2002 08:43:32 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C22F21.E3BD5EA0" Sender: owner-ips@ece.cmu.edu Precedence: bulk This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_001_01C22F21.E3BD5EA0 Content-Type: text/plain; charset="iso-8859-1" Yes, I agree that it is probably too late to think about this. But just to put you in perspective, I was referring more to the data-in, not the R2T's and the A bit causes extra traffic. I mostly wanted to point this out, I am not really asking for a change unless the group thinks it is relevant. If no one has an issue (and I really don't), then we can drop the thread. Eddy -----Original Message----- From: Black_David@emc.com [mailto:Black_David@emc.com] Sent: Wednesday, July 17, 2002 9:57 PM To: eddy_quicksall@ivivity.com Cc: ips@ece.cmu.edu Subject: RE: iSCSI: freeing resources during data-in and r2t Eddy, The A bit in Data-In plus Data ACK (SNACK type 2 in -14, Julian's renumbering of the SNACK types in the working version of -15 is/will be/has been undone) already provides the intermediate resource freeing for Data-In. This is only available for ErrorRecoveryLevel >= 1 We've never thought that R2Ts would consume enough resources to be worth putting in support for intermediate resource freeing of them. Adding another sequence number at this late date to deal with a "slight inefficiency" when the A bit is used properly (SNACK-Data ACK PDUs vs. a piggybacked count) does not seem like a good idea. Thanks, --David -----Original Message----- From: Eddy Quicksall [mailto:eddy_quicksall@ivivity.com] Sent: Wednesday, July 17, 2002 12:15 PM To: Mallikarjun C. (E-mail) Cc: ips@ece. cmu. edu (E-mail) Subject: RE: iSCSI: freeing resources during data-in and r2t I think see a slight inefficiency in how resources are freed when multiple data-in and r2t's PDU's are used when ErrorRecoverLevel > 0 or TCP ACK is not available to the iSCSI layer. Data-in and R2T's use DataSN and R2TSN. To free those resources, ExpStatSN is used. But if several R2T's and/or Data-in PDU's were used, resources used for those PDU's are tied up for the entire command. Since other commands could be received during this time, it would be nice if those commands could contain information that would tell the target that the R2T and/or Data-in PDU's have been received. I know a radical change at this point is probably a bad idea but I just wanted to throw out the idea ... if the StatSN/ExpStatSN were changed to something like RespSN/ExpRespSN and if everything going from the target to the initiator carried a new RespSN, then the resources could be freed up sooner. I would hate to use the A bit for this because it causes more traffic. Eddy mailto:Eddy_Quicksall@iVivity.com ------_=_NextPart_001_01C22F21.E3BD5EA0 Content-Type: text/html; charset="iso-8859-1"
Yes, I agree that it is probably too late to think about this. But just to put you in perspective, I was referring more to the data-in, not the R2T's and the A bit causes extra traffic.
 
I mostly wanted to point this out, I am not really asking for a change unless the group thinks it is relevant. If no one has an issue (and I really don't), then we can drop the thread.
 
Eddy
-----Original Message-----
From: Black_David@emc.com [mailto:Black_David@emc.com]
Sent: Wednesday, July 17, 2002 9:57 PM
To: eddy_quicksall@ivivity.com
Cc: ips@ece.cmu.edu
Subject: RE: iSCSI: freeing resources during data-in and r2t

Eddy,
 
The A bit in Data-In plus Data ACK (SNACK type 2 in -14, Julian's
renumbering of the SNACK types in the working version of -15 is/will
be/has been undone) already provides the intermediate resource freeing
for Data-In.  This is only available for ErrorRecoveryLevel >= 1
We've never thought that R2Ts would consume enough resources to
be worth putting in support for intermediate resource
freeing of them.  Adding another sequence number at this late date
to deal with a "slight inefficiency" when the A bit is used properly
(SNACK-Data ACK PDUs vs. a piggybacked count) does not seem like a
good idea.
 
Thanks,
--David
-----Original Message-----
From: Eddy Quicksall [mailto:eddy_quicksall@ivivity.com]
Sent: Wednesday, July 17, 2002 12:15 PM
To: Mallikarjun C. (E-mail)
Cc: ips@ece. cmu. edu (E-mail)
Subject: RE: iSCSI: freeing resources during data-in and r2t

I think see a slight inefficiency in how resources are freed when multiple data-in and r2t's PDU's are used when ErrorRecoverLevel > 0 or TCP ACK is not available to the iSCSI layer.
 
Data-in and R2T's use DataSN and R2TSN. To free those resources, ExpStatSN is used.
 
But if several R2T's and/or Data-in PDU's were used, resources used for those PDU's are tied up for the entire command.
 
Since other commands could be received during this time, it would be nice if those commands could contain information that would tell the target that the R2T and/or Data-in PDU's have been received.
 
I know a radical change at this point is probably a bad idea but I just wanted to throw out the idea ... if the StatSN/ExpStatSN were changed to something like RespSN/ExpRespSN and if everything going from the target to the initiator carried a new RespSN, then the resources could be freed up sooner.
 
I would hate to use the A bit for this because it causes more traffic.
 
Eddy
mailto:Eddy_Quicksall@iVivity.com
 
------_=_NextPart_001_01C22F21.E3BD5EA0-- From owner-ips@ece.cmu.edu Fri Jul 19 11:21:13 2002 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA11578 for ; Fri, 19 Jul 2002 11:21:00 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id g6JEbIL27281 for ips-outgoing; Fri, 19 Jul 2002 10:37:18 -0400 (EDT) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from hclnpd.hclt.co.in ([202.54.64.7]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id g6JEbFX27276 for ; Fri, 19 Jul 2002 10:37:15 -0400 (EDT) Received: from mailnpd.hclt-ntl.co.in ([192.168.19.36]) by hclnpd.hclt.co.in with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) id 3B59F7Z2; Fri, 19 Jul 2002 20:06:30 +0530 Received: from npd.hcltech.com (IDENT:tLkonXXeJudLkSnDI3g5iUXmdHRzNfC1@pamanick.hclt-ntl.co.in [192.168.19.58]) by mailnpd.hclt-ntl.co.in (8.11.0/8.11.0) with ESMTP id g6JETv424352; Fri, 19 Jul 2002 19:59:58 +0530 Message-ID: <3D382232.CA495BE0@npd.hcltech.com> Date: Fri, 19 Jul 2002 19:59:06 +0530 From: Parthi Organization: HCL Technologies X-Mailer: Mozilla 4.78 [en] (X11; U; Linux 2.4.7-10 i686) X-Accept-Language: en MIME-Version: 1.0 To: Lakshmi Ramasubramanian CC: "LEMAY,KEVIN (A-Roseville,ex1)" , ips@ece.cmu.edu, "Satran, Julian" Subject: Re: iSCSI: Invalid PDU before login PDU - what happens References: Content-Type: multipart/alternative; boundary="------------F551EB61FE653C3BAE7DBB31" Sender: owner-ips@ece.cmu.edu Precedence: bulk --------------F551EB61FE653C3BAE7DBB31 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Hi : Lakshmi Ramasubramanian wrote: > I guess you can use 0x04 (Protocol Error) for Reject reason. > Parthi> target will terminate the connection and the session to terminate if it's the first connection. > > -lakshmi > > -----Original Message----- > From: LEMAY,KEVIN (A-Roseville,ex1) [mailto:kevin_lemay@agilent.com] > Sent: Thursday, July 18, 2002 11:25 AM > To: ips@ece.cmu.edu; 'Satran, Julian' > Subject: iSCSI: Invalid PDU before login PDU - what happens > > What is the correct behavior for a target when an initiator sends a > full-feature phase PDU before the initial login PDU? > > I believe that this is: > > i-> Cmd PDU > t-> Login Response - Reject reason = Invalid during login > FIN > > but where is it documented in the Spec? Parthi> Draft -v14 6.8 Negotiation Failures says ( Pg. no 10 9 ) - During Login, any failure in negotiation MUST be considered a login process failure and the Login Phase must be termi- nated, and with it the connection. If the target detects the failure, it must terminate the login with the appropriate login response code. > > > Thanks, > > Kevin thanks, parthi -- http://san.hcltech.com --------------F551EB61FE653C3BAE7DBB31 Content-Type: text/html; charset=us-ascii Content-Transfer-Encoding: 7bit Hi :

Lakshmi Ramasubramanian wrote:

I guess you can use 0x04 (Protocol Error) for Reject reason.
 
Parthi>  target will terminate the connection and the session to terminate
         if it's the first connection.
 
 
 -lakshmi

-----Original Message-----
From: LEMAY,KEVIN (A-Roseville,ex1) [mailto:kevin_lemay@agilent.com]
Sent: Thursday, July 18, 2002 11:25 AM
To: ips@ece.cmu.edu; 'Satran, Julian'
Subject: iSCSI: Invalid PDU before login PDU - what happens

What is the correct behavior for a target when an initiator sends a
full-feature phase PDU before the initial login PDU?

I believe that this is:

i-> Cmd PDU
t-> Login Response - Reject reason = Invalid during login
    FIN

but where is it documented in the Spec?

Parthi>  Draft -v14  6.8  Negotiation Failures says  ( Pg. no  10 9 )
     - During Login, any failure in negotiation MUST be considered a
       login process failure and the Login Phase must be termi-
       nated, and with it the connection. If the target detects the
       failure, it must terminate the login with the appropriate
       login response code.
 

 

Thanks,

Kevin


thanks,
parthi 

-- 
http://san.hcltech.com
  --------------F551EB61FE653C3BAE7DBB31-- From owner-ips@ece.cmu.edu Fri Jul 19 15:29:49 2002 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA16291 for ; Fri, 19 Jul 2002 15:29:48 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id g6JFn3Q01640 for ips-outgoing; Fri, 19 Jul 2002 11:49:03 -0400 (EDT) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from msgbas2.cos.agilent.com (msgbas2x.cos.agilent.com [192.25.240.37]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id g6JFn1X01634 for ; Fri, 19 Jul 2002 11:49:02 -0400 (EDT) Received: from msgrel1t.cos.agilent.com (msgrel1t.cos.agilent.com [130.29.152.157]) by msgbas2.cos.agilent.com (Postfix) with ESMTP id CDFD91C42; Fri, 19 Jul 2002 09:49:00 -0600 (MDT) Received: from axcsbh6.cos.agilent.com (axcsbh6.cos.agilent.com [130.29.152.171]) by msgrel1t.cos.agilent.com (Postfix) with SMTP id 21FFE5E6; Fri, 19 Jul 2002 09:49:00 -0600 (MDT) Received: from 130.29.152.171 by axcsbh6.cos.agilent.com (InterScan E-Mail VirusWall NT); Fri, 19 Jul 2002 09:49:00 -0600 Received: by axcsbh6.cos.agilent.com with Internet Mail Service (5.5.2653.19) id <3443CJ79>; Fri, 19 Jul 2002 09:49:00 -0600 Message-ID: <9F8400020EC5D311AF62009027C396160902C55B@axcs09.cos.agilent.com> From: kevin_lemay@agilent.com To: mbakke@cisco.com, kevin_lemay@agilent.com Cc: ips@ece.cmu.edu, julian_satran@hotmail.com Subject: RE: iSCSI: Question on use of Target Alias Date: Fri, 19 Jul 2002 09:48:57 -0600 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-ips@ece.cmu.edu Precedence: bulk Thanks, Maybe we can convince Julian to add a sentence to the spec to say this.... Kevin -----Original Message----- From: Mark Bakke [mailto:mbakke@cisco.com] Sent: Friday, July 19, 2002 8:59 AM To: LEMAY,KEVIN (A-Roseville,ex1) Cc: ips@ece.cmu.edu; 'Satran, Julian' Subject: Re: iSCSI: Question on use of Target Alias Kevin- That's correct; TargetAlias is not sent on a discovery session (since it's not really connected to a target). There was some debate about returning it along with TargetName and TargetAddress keys quite some time ago. The team chose to keep SendTargets simpler and not include it. -- Mark "LEMAY,KEVIN (A-Roseville,ex1)" wrote: > > The v15 Working spec says: > > "If a target has been configured with a human-readable name or description, this name SHOULD be communicated to the initiator dur- ing a Login Response PDU. This string is not used as an identifier, nor is meant to be used for authentication or authorization deci- sions. It can be displayed by the initiator's user interface in a list of targets to which it is connected." > > I am assuming that this only applies to normal logins? > > The text says that the key is not sent during the sendTargets operations because in Appendix D, it says: > > "The response to this command is a text response that contains a list of zero or more targets and, optionally, their addresses. Each tar- get is returned as a target record. A target record begins with the TargetName text key, followed by a list of TargetAddress text keys, and bounded by the end of the text response or the next TargetName key, which begins a new record. No text keys other than TargetName and TargetAddress are permitted within a SendTargets response." > > So the only valid use of this key is during normal login, correct? > > Kevin -- Mark A. Bakke Cisco Systems mbakke@cisco.com 763.398.1054 From owner-ips@ece.cmu.edu Fri Jul 19 15:29:55 2002 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA16305 for ; Fri, 19 Jul 2002 15:29:55 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id g6JFgIP01195 for ips-outgoing; Fri, 19 Jul 2002 11:42:18 -0400 (EDT) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from sj-msg-core-1.cisco.com (sj-msg-core-1.cisco.com [171.71.163.11]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id g6JFgHX01189 for ; Fri, 19 Jul 2002 11:42:17 -0400 (EDT) Received: from sj-msg-av-1.cisco.com (sj-msg-av-1.cisco.com [171.69.11.151]) by sj-msg-core-1.cisco.com (8.12.2/8.12.2) with ESMTP id g6JFg6M2015161; Fri, 19 Jul 2002 08:42:06 -0700 (PDT) Received: from nisser.cisco.com (localhost [127.0.0.1]) by sj-msg-av-1.cisco.com (8.12.2/8.12.2) with ESMTP id g6JFg7vm010867; Fri, 19 Jul 2002 08:42:08 -0700 (PDT) Received: from cisco.com (mbakke@mbakke-lnx.cisco.com [161.44.68.87]) by nisser.cisco.com (8.8.6 (PHNE_14041)/CISCO.SERVER.1.2) with ESMTP id IAA28414; Fri, 19 Jul 2002 08:42:04 -0700 (PDT) Message-ID: <3D383755.C555C845@cisco.com> Date: Fri, 19 Jul 2002 10:59:17 -0500 From: Mark Bakke X-Mailer: Mozilla 4.72 [en] (X11; U; Linux 2.2.16-3.uid32 i686) X-Accept-Language: en, de MIME-Version: 1.0 To: "LEMAY,KEVIN (A-Roseville,ex1)" CC: ips@ece.cmu.edu, "'Satran, Julian'" Subject: Re: iSCSI: Question on use of Target Alias References: <9F8400020EC5D311AF62009027C396160902C555@axcs09.cos.agilent.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ips@ece.cmu.edu Precedence: bulk Content-Transfer-Encoding: 7bit Kevin- That's correct; TargetAlias is not sent on a discovery session (since it's not really connected to a target). There was some debate about returning it along with TargetName and TargetAddress keys quite some time ago. The team chose to keep SendTargets simpler and not include it. -- Mark "LEMAY,KEVIN (A-Roseville,ex1)" wrote: > > The v15 Working spec says: > > "If a target has been configured with a human-readable name or description, this name SHOULD be communicated to the initiator dur- ing a Login Response PDU. This string is not used as an identifier, nor is meant to be used for authentication or authorization deci- sions. It can be displayed by the initiator's user interface in a list of targets to which it is connected." > > I am assuming that this only applies to normal logins? > > The text says that the key is not sent during the sendTargets operations because in Appendix D, it says: > > "The response to this command is a text response that contains a list of zero or more targets and, optionally, their addresses. Each tar- get is returned as a target record. A target record begins with the TargetName text key, followed by a list of TargetAddress text keys, and bounded by the end of the text response or the next TargetName key, which begins a new record. No text keys other than TargetName and TargetAddress are permitted within a SendTargets response." > > So the only valid use of this key is during normal login, correct? > > Kevin -- Mark A. Bakke Cisco Systems mbakke@cisco.com 763.398.1054 From owner-ips@ece.cmu.edu Fri Jul 19 15:31:21 2002 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA16337 for ; Fri, 19 Jul 2002 15:31:21 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id g6JIqAB00504 for ips-outgoing; Fri, 19 Jul 2002 14:52:10 -0400 (EDT) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from mail.brocade.com (sj6-b.brocade.com [63.121.140.220]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id g6JIq6o00493; Fri, 19 Jul 2002 14:52:06 -0400 (EDT) Received: from hq-ex-c2.brocade.com (hq-ex-c2 [192.168.126.35]) by mail.brocade.com (8.8.8+Sun/8.8.8) with ESMTP id JAA10982; Fri, 19 Jul 2002 09:57:02 -0700 (PDT) Received: by hq-ex-c2.brocade.com with Internet Mail Service (5.5.2653.19) id ; Fri, 19 Jul 2002 09:57:02 -0700 Message-ID: From: Brian Forbes To: "'Julian Satran'" , Brian Forbes Cc: ips@ece.cmu.edu, owner-ips@ece.cmu.edu, Robert Snively Subject: RE: BKF Comments on iSCSI version 14 Date: Fri, 19 Jul 2002 09:57:01 -0700 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C22F45.4D3E4290" Sender: owner-ips@ece.cmu.edu Precedence: bulk This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_001_01C22F45.4D3E4290 Content-Type: text/plain Looks good, thanks. I agree with the direction the 'decimal discussion' is now going. Brian Forbes Brocade Communications -----Original Message----- From: Julian Satran [mailto:Julian_Satran@il.ibm.com] Sent: Sunday, July 14, 2002 12:59 AM To: Brian Forbes Cc: ips@ece.cmu.edu; owner-ips@ece.cmu.edu; Robert Snively Subject: Re: BKF Comments on iSCSI version 14 Brian, Thanks - comments in text Julo Brian Forbes Sent by: owner-ips@ece.cmu.edu 07/07/2002 09:25 PM Please respond to Brian Forbes To: ips@ece.cmu.edu cc: Robert Snively Subject: BKF Comments on iSCSI version 14 I've sent a list of editorial comments directly to Julian. Technical comments: T1: Although it is alluded to in section 11.10, the document must explicitly define the effective value of Buffer Offset for immediate data. Possible sections for doing so include 2.2.4 and 9.3.6. +++ fixed in 2.2.4. This was requested also by Eddy +++ T2: I agree with the recent reflector discussion that decimal is only used for numbers, hex for numbers and binary, and base64 only for binary items. I believe the debate should focus on the utility of the existing iSCSI type definitions and avoid getting derailed by anecdotal references to data types in other RFCs. +++ One of the reasons people want SCSI on IP is to leverage all other IP infrastructure. Unfortunately the usage of decimal is beyond anectodal and we just can't ignore it. We have however - I think removed all the thorny related issues +++ T3: Section 4.3.1, page 80: "If the reconfiguration of iSCSI portal groups is a concern in a given environment, the iSCSI initiator MUST use this key to ascertain that it had indeed initiated the Login Phase with the intended target portal group." The use of MUST in the final sentence is untestable and should probably be lower-case "should". +++ we have several such instances. This usage can be certified in lab test - although I agree that it untestable at run-time (has no check condition). The same goes for many other MUST requirements +++ T4: Section 11.8, page 215: "If the TargetAddress is returned as the result of a redirect status in a login response, the comma and portal group tag are omitted." For interoperability reasons, I believe "are omitted" should be "MUST be omitted". +++ fixed +++ T5: Section 11.8, page 215: "If the TargetAddress is returned within a SendTargets response, the portal group tag is required." For interoperability reasons, I believe "is required" should be "MUST be included". +++ fixed +++ Brian Forbes Technology Brocade Communications ------_=_NextPart_001_01C22F45.4D3E4290 Content-Type: text/html
Looks good, thanks.  I agree with the direction the 'decimal discussion' is now going.

Brian Forbes
Brocade Communications

-----Original Message-----
From: Julian Satran [mailto:Julian_Satran@il.ibm.com]
Sent: Sunday, July 14, 2002 12:59 AM
To: Brian Forbes
Cc: ips@ece.cmu.edu; owner-ips@ece.cmu.edu; Robert Snively
Subject: Re: BKF Comments on iSCSI version 14


Brian,

Thanks - comments in text Julo


Brian Forbes <bforbes@Brocade.COM>
Sent by: owner-ips@ece.cmu.edu

07/07/2002 09:25 PM
Please respond to Brian Forbes

       
        To:        ips@ece.cmu.edu
        cc:        Robert Snively <rsnively@Brocade.COM>
        Subject:        BKF Comments on iSCSI version 14

       


I've sent a list of editorial comments directly to Julian.

Technical comments:

T1:  

Although it is alluded to in section 11.10, the document must explicitly
define the effective value of Buffer Offset for immediate data.  Possible
sections for doing so include 2.2.4 and 9.3.6.

+++ fixed in 2.2.4. This was requested also by Eddy +++
T2:  

I agree with the recent reflector discussion that decimal is only used for
numbers, hex for numbers and binary, and base64 only for binary items.  I
believe the debate should focus on the utility of the existing iSCSI type
definitions and avoid getting derailed by anecdotal references to data types
in other RFCs.
+++ One of the reasons people want SCSI on IP is to leverage all other IP infrastructure.
Unfortunately the usage of decimal is beyond anectodal and we just can't ignore it.
We have however - I think removed all the thorny related issues +++

T3:  

Section 4.3.1, page 80:  "If the reconfiguration of iSCSI portal groups is a
concern in a given environment, the iSCSI initiator MUST use this key to
ascertain that it had indeed initiated the Login Phase with the intended
target portal group."

The use of MUST in the final sentence is untestable and should probably be
lower-case "should".

+++ we have several such instances. This usage can be certified in lab test - although I agree that it untestable at run-time (has no check condition). The same goes for many other MUST requirements +++

T4:  

Section 11.8, page 215:  "If the TargetAddress is returned as the result of
a redirect status in a login response, the comma and portal group tag are
omitted."

For interoperability reasons, I believe "are omitted" should be "MUST be
omitted".
+++ fixed +++

T5:  

Section 11.8, page 215:  "If the TargetAddress is returned within a
SendTargets response, the portal group tag is required."

For interoperability reasons, I believe "is required" should be "MUST be
included".

+++ fixed +++
Brian Forbes
Technology
Brocade Communications


------_=_NextPart_001_01C22F45.4D3E4290-- From owner-ips@ece.cmu.edu Fri Jul 19 18:19:34 2002 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA18255 for ; Fri, 19 Jul 2002 18:19:34 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id g6JLf9m06900 for ips-outgoing; Fri, 19 Jul 2002 17:41:09 -0400 (EDT) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from sj-msg-core-1.cisco.com (sj-msg-core-1.cisco.com [171.71.163.11]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id g6JJ8Co01248 for ; Fri, 19 Jul 2002 15:08:12 -0400 (EDT) Received: from pacman.cisco.com (pacman.cisco.com [171.71.154.145]) by sj-msg-core-1.cisco.com (8.12.2/8.12.2) with ESMTP id g6JJ81M3020587; Fri, 19 Jul 2002 12:08:01 -0700 (PDT) Date: Fri, 19 Jul 2002 12:08:00 -0700 (PDT) From: Arvind Prabhudev To: ips@ece.cmu.edu cc: Arvind Prabhudev , Mickey Spiegel Subject: FC Mgmt mib - buffer credit objects In-Reply-To: <200207191403.HAA20517@cisco.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ips@ece.cmu.edu Precedence: bulk Hello Keith, Fibre Channel Management MIB: draft-ietf-ips-fcmgmt-mib-02 I had a comment about fcmFLoginBbCredit & fcmISPortClassFCredit objects. Since, it is possible to have an implementation where the buffer credit is configurable, I would suggest that we make these 2 objects read-write now rather than having to deprecate these and create new objects in the future. We could add a MIN-ACCESS clause of read-only for both these objects. thanks, Arvind From owner-ips@ece.cmu.edu Fri Jul 19 20:21:05 2002 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA20519 for ; Fri, 19 Jul 2002 20:21:05 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id g6JNhij11660 for ips-outgoing; Fri, 19 Jul 2002 19:43:44 -0400 (EDT) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from d12lmsgate.de.ibm.com (d12lmsgate.de.ibm.com [195.212.91.199]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id g6JNhgo11655; Fri, 19 Jul 2002 19:43:42 -0400 (EDT) Received: from d12relay01.de.ibm.com (d12relay01.de.ibm.com [9.165.215.22]) by d12lmsgate.de.ibm.com (8.12.3/8.12.3) with ESMTP id g6JNhXLc010130; Sat, 20 Jul 2002 01:43:33 +0200 Received: from d10hubm1.telaviv.ibm.com (d10ml001.telaviv.ibm.com [9.148.216.55]) by d12relay01.de.ibm.com (8.11.1m3/NCO/VER6.2) with ESMTP id g6JNhZS123334; Sat, 20 Jul 2002 01:43:35 +0200 To: Eddy Quicksall Cc: Black_David@emc.com, ips@ece.cmu.edu, owner-ips@ece.cmu.edu MIME-Version: 1.0 Subject: RE: iSCSI: freeing resources during data-in and r2t X-Mailer: Lotus Notes Release 5.0.9 November 16, 2001 From: "Julian Satran" Message-ID: Date: Sat, 20 Jul 2002 03:43:32 +0300 X-MIMETrack: Serialize by Router on D10ML001/10/M/IBM(Release 5.0.9a |January 7, 2002) at 20/07/2002 02:43:35, Serialize complete at 20/07/2002 02:43:35 Content-Type: multipart/alternative; boundary="=_alternative 00820076C2256BFB_=" Sender: owner-ips@ece.cmu.edu Precedence: bulk This is a multipart message in MIME format. --=_alternative 00820076C2256BFB_= Content-Type: text/plain; charset="us-ascii" Eddy, What resources? R2Ts for which the initiator has finished sending data can be discarded. Targets build R2Ts as needed. So what resources do you have in mind? Data Buffers at initiator? According to SAM2 you have to keep them up to the bitter end unless you request delivery strictly in order in which as you are better off issuing in sequence short writes if you want to allow recovery. If that is what you have in mind there is a basic asymmetry build in SCSI (and others) that the command issuers has the resource to keep the command going while the target (that can't plan the commands hitting it) has to be taken care of. iSCSI is not worsening this (neither improving on it). Regards, Julo Eddy Quicksall Sent by: owner-ips@ece.cmu.edu 07/19/2002 03:43 PM To: Black_David@emc.com cc: ips@ece.cmu.edu Subject: RE: iSCSI: freeing resources during data-in and r2t Yes, I agree that it is probably too late to think about this. But just to put you in perspective, I was referring more to the data-in, not the R2T's and the A bit causes extra traffic. I mostly wanted to point this out, I am not really asking for a change unless the group thinks it is relevant. If no one has an issue (and I really don't), then we can drop the thread. Eddy -----Original Message----- From: Black_David@emc.com [mailto:Black_David@emc.com] Sent: Wednesday, July 17, 2002 9:57 PM To: eddy_quicksall@ivivity.com Cc: ips@ece.cmu.edu Subject: RE: iSCSI: freeing resources during data-in and r2t Eddy, The A bit in Data-In plus Data ACK (SNACK type 2 in -14, Julian's renumbering of the SNACK types in the working version of -15 is/will be/has been undone) already provides the intermediate resource freeing for Data-In. This is only available for ErrorRecoveryLevel >= 1 We've never thought that R2Ts would consume enough resources to be worth putting in support for intermediate resource freeing of them. Adding another sequence number at this late date to deal with a "slight inefficiency" when the A bit is used properly (SNACK-Data ACK PDUs vs. a piggybacked count) does not seem like a good idea. Thanks, --David -----Original Message----- From: Eddy Quicksall [mailto:eddy_quicksall@ivivity.com] Sent: Wednesday, July 17, 2002 12:15 PM To: Mallikarjun C. (E-mail) Cc: ips@ece. cmu. edu (E-mail) Subject: RE: iSCSI: freeing resources during data-in and r2t I think see a slight inefficiency in how resources are freed when multiple data-in and r2t's PDU's are used when ErrorRecoverLevel > 0 or TCP ACK is not available to the iSCSI layer. Data-in and R2T's use DataSN and R2TSN. To free those resources, ExpStatSN is used. But if several R2T's and/or Data-in PDU's were used, resources used for those PDU's are tied up for the entire command. Since other commands could be received during this time, it would be nice if those commands could contain information that would tell the target that the R2T and/or Data-in PDU's have been received. I know a radical change at this point is probably a bad idea but I just wanted to throw out the idea ... if the StatSN/ExpStatSN were changed to something like RespSN/ExpRespSN and if everything going from the target to the initiator carried a new RespSN, then the resources could be freed up sooner. I would hate to use the A bit for this because it causes more traffic. Eddy mailto:Eddy_Quicksall@iVivity.com --=_alternative 00820076C2256BFB_= Content-Type: text/html; charset="us-ascii"
        Eddy,

What resources?  R2Ts for which the initiator has finished sending data can be discarded.
Targets build R2Ts as needed.
So what resources do you have in mind?  Data Buffers at initiator? According to SAM2 you have to keep them up to the bitter end unless
you request delivery strictly in order in which as you are better off issuing in sequence short writes if you want to allow recovery.
If that is what you have in mind there is a basic asymmetry build in SCSI (and others) that the command issuers has
the resource to keep the command going while the target (that can't plan the commands hitting it) has to be taken care of.

iSCSI is not worsening this (neither improving on it).

Regards,
Julo


Eddy Quicksall <eddy_quicksall@ivivity.com>
Sent by: owner-ips@ece.cmu.edu

07/19/2002 03:43 PM

       
        To:        Black_David@emc.com
        cc:        ips@ece.cmu.edu
        Subject:        RE: iSCSI: freeing resources during data-in and r2t

       


Yes, I agree that it is probably too late to think about this. But just to put you in perspective, I was referring more to the data-in, not the R2T's and the A bit causes extra traffic.
 
I mostly wanted to point this out, I am not really asking for a change unless the group thinks it is relevant. If no one has an issue (and I really don't), then we can drop the thread.
 
Eddy
-----Original Message-----
From: Black_David@emc.com [mailto:Black_David@emc.com]
Sent: Wednesday, July 17, 2002 9:57 PM
To: eddy_quicksall@ivivity.com
Cc: ips@ece.cmu.edu
Subject: RE: iSCSI: freeing resources during data-in and r2t
Eddy,
 
The A bit in Data-In plus Data ACK (SNACK type 2 in -14, Julian's
renumbering of the SNACK types in the working version of -15 is/will
be/has been undone) already provides the intermediate resource freeing
for Data-In.  This is only available for ErrorRecoveryLevel >= 1
We've never thought that R2Ts would consume enough resources to
be worth putting in support for intermediate resource
freeing of them.  Adding another sequence number at this late date
to deal with a "slight inefficiency" when the A bit is used properly
(SNACK-Data ACK PDUs vs. a piggybacked count) does not seem like a
good idea.
 
Thanks,
--David
-----Original Message-----
From: Eddy Quicksall [mailto:eddy_quicksall@ivivity.com]
Sent: Wednesday, July 17, 2002 12:15 PM
To: Mallikarjun C. (E-mail)
Cc: ips@ece. cmu. edu (E-mail)
Subject: RE: iSCSI: freeing resources during data-in and r2t
I think see a slight inefficiency in how resources are freed when multiple data-in and r2t's PDU's are used when ErrorRecoverLevel > 0 or TCP ACK is not available to the iSCSI layer.
 
Data-in and R2T's use DataSN and R2TSN. To free those resources, ExpStatSN is used.
 
But if several R2T's and/or Data-in PDU's were used, resources used for those PDU's are tied up for the entire command.
 
Since other commands could be received during this time, it would be nice if those commands could contain information that would tell the target that the R2T and/or Data-in PDU's have been received.
 
I know a radical change at this point is probably a bad idea but I just wanted to throw out the idea ... if the StatSN/ExpStatSN were changed to something like RespSN/ExpRespSN and if everything going from the target to the initiator carried a new RespSN, then the resources could be freed up sooner.
 
I would hate to use the A bit for this because it causes more traffic.
 
Eddy
mailto:Eddy_Quicksall@iVivity.com
 

--=_alternative 00820076C2256BFB_=-- From owner-ips@ece.cmu.edu Mon Jul 22 14:03:13 2002 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA22869 for ; Mon, 22 Jul 2002 14:03:12 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id g6MHCMI26815 for ips-outgoing; Mon, 22 Jul 2002 13:12:22 -0400 (EDT) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from pepsi.splentec.com (ns.splentec.com [209.47.35.194]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id g6MHCHo26809 for ; Mon, 22 Jul 2002 13:12:21 -0400 (EDT) Received: from splentec.com (canoe.splentec.com [209.47.35.250]) by pepsi.splentec.com (8.11.6/8.11.0) with ESMTP id g6MHC6s22305 for ; Mon, 22 Jul 2002 13:12:06 -0400 Message-ID: <3D3C3CE8.22D6F8C6@splentec.com> Date: Mon, 22 Jul 2002 13:12:08 -0400 From: Luben Tuikov Organization: Splentec Ltd. X-Mailer: Mozilla 4.79 [en] (X11; U; Linux 2.4.19-rc2 i686) X-Accept-Language: en MIME-Version: 1.0 To: iSCSI Subject: INQUIRY, version descriptor Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ips@ece.cmu.edu Precedence: bulk Content-Transfer-Encoding: 7bit Shouldn't we mention in the draft that Targets should set the next available (eq. 0x0000) version descriptor to 0x0960 in the INQUIRY data if additional length spans it? It is mentioned in SPC-3 (and SPC-2) and it would be more convenient for implementors to see it in the iSCSI document as well. -- Luben From owner-ips@ece.cmu.edu Mon Jul 22 15:54:44 2002 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA03416 for ; Mon, 22 Jul 2002 15:54:43 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id g6MJZSO06435 for ips-outgoing; Mon, 22 Jul 2002 15:35:28 -0400 (EDT) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from mailhub.lss.emc.com (xdch.emc.com [168.159.1.79]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id g6MJZRo06430 for ; Mon, 22 Jul 2002 15:35:27 -0400 (EDT) Received: from emc.com (emcmail.lss.emc.com [168.159.48.78]) by mailhub.lss.emc.com (Switch-2.2.0/Switch-2.2.0) with ESMTP id g6MJZHX06287; Mon, 22 Jul 2002 15:35:17 -0400 (EDT) Received: from mxic1.isus.emc.com ([168.159.129.100]) by emc.com (8.10.1/8.10.1) with ESMTP id g6MJZH717251; Mon, 22 Jul 2002 15:35:17 -0400 (EDT) Received: by MXIC1 with Internet Mail Service (5.5.2653.19) id ; Mon, 22 Jul 2002 15:33:08 -0400 Message-ID: <277DD60FB639D511AC0400B0D068B71E0564C0C9@CORPMX14> From: Black_David@emc.com To: eddy_quicksall@ivivity.com Cc: ips@ece.cmu.edu Subject: RE: iSCSI: freeing resources during data-in and r2t Date: Mon, 22 Jul 2002 15:33:03 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" X-Perlmx-Spam: Gauge=, Probability=0%, Report="EMC0_FROM, NO_REAL_NAME" Sender: owner-ips@ece.cmu.edu Precedence: bulk > As I said to David, it is probably too late for a change here but > it seems like we could have used StatSN (actually with a different name) > as a counter of everything going from the target to the initiator. > That way, the target does not have to associate the TCP ACK in order > to tell if the initiator got a PDU. A word of caution - the TCP ACK indicates that TCP delivered the bytes - if CRC digests are in use, a digest error could cause those bytes not to form a usable PDU. I view the A bit as an 80% solution that addresses the major portion of the need for targets to free resources prior to command completion, and I think Eddy's in reluctant semi-violent agreement that no change should be made here. Thanks, --David -----Original Message----- From: Eddy Quicksall [mailto:eddy_quicksall@ivivity.com] Sent: Monday, July 22, 2002 3:12 PM To: Julian Satran Cc: Black_David@emc.com; ips@ece.cmu.edu; owner-ips@ece.cmu.edu Subject: RE: iSCSI: freeing resources during data-in and r2t There are other resources besides the buffers that are used to transmit the data and it would be nice if those could be freed as soon as I know the initiator has them. As I said to David, it is probably too late for a change here but it seems like we could have used StatSN (actually with a different name) as a counter of everything going from the target to the initiator. That way, the target does not have to associate the TCP ACK in order to tell if the initiator got a PDU. Eddy -----Original Message----- From: Julian Satran [mailto:Julian_Satran@il.ibm.com] Sent: Friday, July 19, 2002 8:44 PM To: Eddy Quicksall Cc: Black_David@emc.com; ips@ece.cmu.edu; owner-ips@ece.cmu.edu Subject: RE: iSCSI: freeing resources during data-in and r2t Eddy, What resources? R2Ts for which the initiator has finished sending data can be discarded. Targets build R2Ts as needed. So what resources do you have in mind? Data Buffers at initiator? According to SAM2 you have to keep them up to the bitter end unless you request delivery strictly in order in which as you are better off issuing in sequence short writes if you want to allow recovery. If that is what you have in mind there is a basic asymmetry build in SCSI (and others) that the command issuers has the resource to keep the command going while the target (that can't plan the commands hitting it) has to be taken care of. iSCSI is not worsening this (neither improving on it). Regards, Julo Eddy Quicksall Sent by: owner-ips@ece.cmu.edu 07/19/2002 03:43 PM To: Black_David@emc.com cc: ips@ece.cmu.edu Subject: RE: iSCSI: freeing resources during data-in and r2t Yes, I agree that it is probably too late to think about this. But just to put you in perspective, I was referring more to the data-in, not the R2T's and the A bit causes extra traffic. I mostly wanted to point this out, I am not really asking for a change unless the group thinks it is relevant. If no one has an issue (and I really don't), then we can drop the thread. Eddy -----Original Message----- From: Black_David@emc.com [mailto:Black_David@emc.com] Sent: Wednesday, July 17, 2002 9:57 PM To: eddy_quicksall@ivivity.com Cc: ips@ece.cmu.edu Subject: RE: iSCSI: freeing resources during data-in and r2t Eddy, The A bit in Data-In plus Data ACK (SNACK type 2 in -14, Julian's renumbering of the SNACK types in the working version of -15 is/will be/has been undone) already provides the intermediate resource freeing for Data-In. This is only available for ErrorRecoveryLevel >= 1 We've never thought that R2Ts would consume enough resources to be worth putting in support for intermediate resource freeing of them. Adding another sequence number at this late date to deal with a "slight inefficiency" when the A bit is used properly (SNACK-Data ACK PDUs vs. a piggybacked count) does not seem like a good idea. Thanks, --David -----Original Message----- From: Eddy Quicksall [mailto:eddy_quicksall@ivivity.com] Sent: Wednesday, July 17, 2002 12:15 PM To: Mallikarjun C. (E-mail) Cc: ips@ece. cmu. edu (E-mail) Subject: RE: iSCSI: freeing resources during data-in and r2t I think see a slight inefficiency in how resources are freed when multiple data-in and r2t's PDU's are used when ErrorRecoverLevel > 0 or TCP ACK is not available to the iSCSI layer. Data-in and R2T's use DataSN and R2TSN. To free those resources, ExpStatSN is used. But if several R2T's and/or Data-in PDU's were used, resources used for those PDU's are tied up for the entire command. Since other commands could be received during this time, it would be nice if those commands could contain information that would tell the target that the R2T and/or Data-in PDU's have been received. I know a radical change at this point is probably a bad idea but I just wanted to throw out the idea ... if the StatSN/ExpStatSN were changed to something like RespSN/ExpRespSN and if everything going from the target to the initiator carried a new RespSN, then the resources could be freed up sooner. I would hate to use the A bit for this because it causes more traffic. Eddy mailto:Eddy_Quicksall@iVivity.com From owner-ips@ece.cmu.edu Mon Jul 22 15:57:58 2002 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA03685 for ; Mon, 22 Jul 2002 15:57:57 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id g6MJCIT05097 for ips-outgoing; Mon, 22 Jul 2002 15:12:18 -0400 (EDT) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from mail.ivivity.com ([64.238.111.99]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id g6MJCFo05092; Mon, 22 Jul 2002 15:12:15 -0400 (EDT) Received: by ATLOPS with Internet Mail Service (5.5.2653.19) id ; Mon, 22 Jul 2002 15:11:59 -0400 Message-ID: From: Eddy Quicksall To: Julian Satran Cc: Black_David@emc.com, ips@ece.cmu.edu, owner-ips@ece.cmu.edu Subject: RE: iSCSI: freeing resources during data-in and r2t Date: Mon, 22 Jul 2002 15:11:58 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C231B3.A66948E0" Sender: owner-ips@ece.cmu.edu Precedence: bulk This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_001_01C231B3.A66948E0 Content-Type: text/plain; charset="iso-8859-1" There are other resources besides the buffers that are used to transmit the data and it would be nice if those could be freed as soon as I know the initiator has them. As I said to David, it is probably too late for a change here but it seems like we could have used StatSN (actually with a different name) as a counter of everything going from the target to the initiator. That way, the target does not have to associate the TCP ACK in order to tell if the initiator got a PDU. Eddy -----Original Message----- From: Julian Satran [mailto:Julian_Satran@il.ibm.com] Sent: Friday, July 19, 2002 8:44 PM To: Eddy Quicksall Cc: Black_David@emc.com; ips@ece.cmu.edu; owner-ips@ece.cmu.edu Subject: RE: iSCSI: freeing resources during data-in and r2t Eddy, What resources? R2Ts for which the initiator has finished sending data can be discarded. Targets build R2Ts as needed. So what resources do you have in mind? Data Buffers at initiator? According to SAM2 you have to keep them up to the bitter end unless you request delivery strictly in order in which as you are better off issuing in sequence short writes if you want to allow recovery. If that is what you have in mind there is a basic asymmetry build in SCSI (and others) that the command issuers has the resource to keep the command going while the target (that can't plan the commands hitting it) has to be taken care of. iSCSI is not worsening this (neither improving on it). Regards, Julo Eddy Quicksall Sent by: owner-ips@ece.cmu.edu 07/19/2002 03:43 PM To: Black_David@emc.com cc: ips@ece.cmu.edu Subject: RE: iSCSI: freeing resources during data-in and r2t Yes, I agree that it is probably too late to think about this. But just to put you in perspective, I was referring more to the data-in, not the R2T's and the A bit causes extra traffic. I mostly wanted to point this out, I am not really asking for a change unless the group thinks it is relevant. If no one has an issue (and I really don't), then we can drop the thread. Eddy -----Original Message----- From: Black_David@emc.com [mailto:Black_David@emc.com] Sent: Wednesday, July 17, 2002 9:57 PM To: eddy_quicksall@ivivity.com Cc: ips@ece.cmu.edu Subject: RE: iSCSI: freeing resources during data-in and r2t Eddy, The A bit in Data-In plus Data ACK (SNACK type 2 in -14, Julian's renumbering of the SNACK types in the working version of -15 is/will be/has been undone) already provides the intermediate resource freeing for Data-In. This is only available for ErrorRecoveryLevel >= 1 We've never thought that R2Ts would consume enough resources to be worth putting in support for intermediate resource freeing of them. Adding another sequence number at this late date to deal with a "slight inefficiency" when the A bit is used properly (SNACK-Data ACK PDUs vs. a piggybacked count) does not seem like a good idea. Thanks, --David -----Original Message----- From: Eddy Quicksall [mailto:eddy_quicksall@ivivity.com] Sent: Wednesday, July 17, 2002 12:15 PM To: Mallikarjun C. (E-mail) Cc: ips@ece. cmu. edu (E-mail) Subject: RE: iSCSI: freeing resources during data-in and r2t I think see a slight inefficiency in how resources are freed when multiple data-in and r2t's PDU's are used when ErrorRecoverLevel > 0 or TCP ACK is not available to the iSCSI layer. Data-in and R2T's use DataSN and R2TSN. To free those resources, ExpStatSN is used. But if several R2T's and/or Data-in PDU's were used, resources used for those PDU's are tied up for the entire command. Since other commands could be received during this time, it would be nice if those commands could contain information that would tell the target that the R2T and/or Data-in PDU's have been received. I know a radical change at this point is probably a bad idea but I just wanted to throw out the idea ... if the StatSN/ExpStatSN were changed to something like RespSN/ExpRespSN and if everything going from the target to the initiator carried a new RespSN, then the resources could be freed up sooner. I would hate to use the A bit for this because it causes more traffic. Eddy mailto:Eddy_Quicksall@iVivity.com ------_=_NextPart_001_01C231B3.A66948E0 Content-Type: text/html; charset="iso-8859-1"
There are other resources besides the buffers that are used to transmit the data and it would be nice if those could be freed as soon as I know the initiator has them.
 
As I said to David, it is probably too late for a change here but it seems like we could have used StatSN (actually with a different name) as a counter of everything going from the target to the initiator. That way, the target does not have to associate the TCP ACK in order to tell if the initiator got a PDU.
 
Eddy
-----Original Message-----
From: Julian Satran [mailto:Julian_Satran@il.ibm.com]
Sent: Friday, July 19, 2002 8:44 PM
To: Eddy Quicksall
Cc: Black_David@emc.com; ips@ece.cmu.edu; owner-ips@ece.cmu.edu
Subject: RE: iSCSI: freeing resources during data-in and r2t


        Eddy,

What resources?  R2Ts for which the initiator has finished sending data can be discarded.
Targets build R2Ts as needed.
So what resources do you have in mind?  Data Buffers at initiator? According to SAM2 you have to keep them up to the bitter end unless
you request delivery strictly in order in which as you are better off issuing in sequence short writes if you want to allow recovery.
If that is what you have in mind there is a basic asymmetry build in SCSI (and others) that the command issuers has
the resource to keep the command going while the target (that can't plan the commands hitting it) has to be taken care of.

iSCSI is not worsening this (neither improving on it).

Regards,
Julo


Eddy Quicksall <eddy_quicksall@ivivity.com>
Sent by: owner-ips@ece.cmu.edu

07/19/2002 03:43 PM

       
        To:        Black_David@emc.com
        cc:        ips@ece.cmu.edu
        Subject:        RE: iSCSI: freeing resources during data-in and r2t

       


Yes, I agree that it is probably too late to think about this. But just to put you in perspective, I was referring more to the data-in, not the R2T's and the A bit causes extra traffic.
 
I mostly wanted to point this out, I am not really asking for a change unless the group thinks it is relevant. If no one has an issue (and I really don't), then we can drop the thread.
 
Eddy
-----Original Message-----
From: Black_David@emc.com [mailto:Black_David@emc.com]
Sent: Wednesday, July 17, 2002 9:57 PM
To: eddy_quicksall@ivivity.com
Cc: ips@ece.cmu.edu
Subject: RE: iSCSI: freeing resources during data-in and r2t

Eddy,
 
The A bit in Data-In plus Data ACK (SNACK type 2 in -14, Julian's
renumbering of the SNACK types in the working version of -15 is/will
be/has been undone) already provides the intermediate resource freeing
for Data-In.  This is only available for ErrorRecoveryLevel >= 1
We've never thought that R2Ts would consume enough resources to
be worth putting in support for intermediate resource
freeing of them.  Adding another sequence number at this late date
to deal with a "slight inefficiency" when the A bit is used properly
(SNACK-Data ACK PDUs vs. a piggybacked count) does not seem like a
good idea.
 
Thanks,
--David
-----Original Message-----
From: Eddy Quicksall [mailto:eddy_quicksall@ivivity.com]
Sent: Wednesday, July 17, 2002 12:15 PM
To: Mallikarjun C. (E-mail)
Cc: ips@ece. cmu. edu (E-mail)
Subject: RE: iSCSI: freeing resources during data-in and r2t

I think see a slight inefficiency in how resources are freed when multiple data-in and r2t's PDU's are used when ErrorRecoverLevel > 0 or TCP ACK is not available to the iSCSI layer.
 
Data-in and R2T's use DataSN and R2TSN. To free those resources, ExpStatSN is used.
 
But if several R2T's and/or Data-in PDU's were used, resources used for those PDU's are tied up for the entire command.
 
Since other commands could be received during this time, it would be nice if those commands could contain information that would tell the target that the R2T and/or Data-in PDU's have been received.
 
I know a radical change at this point is probably a bad idea but I just wanted to throw out the idea ... if the StatSN/ExpStatSN were changed to something like RespSN/ExpRespSN and if everything going from the target to the initiator carried a new RespSN, then the resources could be freed up sooner.
 
I would hate to use the A bit for this because it causes more traffic.
 
Eddy
mailto:Eddy_Quicksall@iVivity.com
 

------_=_NextPart_001_01C231B3.A66948E0-- From owner-ips@ece.cmu.edu Mon Jul 22 17:23:30 2002 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA10706 for ; Mon, 22 Jul 2002 17:23:25 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id g6MKVml09887 for ips-outgoing; Mon, 22 Jul 2002 16:31:48 -0400 (EDT) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from sj-msg-core-2.cisco.com (sj-msg-core-2.cisco.com [171.69.24.11]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id g6MKVko09883 for ; Mon, 22 Jul 2002 16:31:46 -0400 (EDT) Received: from sponge.cisco.com (IDENT:mirapoint@sponge.cisco.com [64.101.128.87]) by sj-msg-core-2.cisco.com (8.12.2/8.12.2) with ESMTP id g6MKVehI009619; Mon, 22 Jul 2002 13:31:40 -0700 (PDT) Received: from DAPW2K3 (dhcp-161-44-68-170.cisco.com [161.44.68.170]) by sponge.cisco.com (Mirapoint) with SMTP id ABC69064; Mon, 22 Jul 2002 15:31:39 -0500 (CDT) From: "Dave Peterson" To: "Julian Satran" Cc: "Ips@Ece. Cmu. Edu" Subject: RE: iSCSI: DAP Last Call Comments Date: Mon, 22 Jul 2002 15:31:39 -0500 Message-ID: MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_002D_01C23194.DF46DFC0" X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0) Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 In-Reply-To: Sender: owner-ips@ece.cmu.edu Precedence: bulk This is a multi-part message in MIME format. ------=_NextPart_000_002D_01C23194.DF46DFC0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Howdy Julian, Comments to your comments below...dap -----Original Message----- From: Julian Satran [mailto:Julian_Satran@il.ibm.com] Sent: Sunday, July 14, 2002 2:18 AM To: Dave Peterson Cc: Ips@Ece. Cmu. Edu; owner-ips@ece.cmu.edu Subject: Re: iSCSI: DAP Last Call Comments Dave - Comments in text - Thanks, Julo "Dave Peterson" Sent by: owner-ips@ece.cmu.edu 07/07/2002 11:19 PM Please respond to "Dave Peterson" To: "Ips@Ece. Cmu. Edu" cc: Subject: iSCSI: DAP Last Call Comments T p 36 2.2.2.1 Command Numbering and Acknowledging: 7th paragraph: if not in this document, where is the means to request immediate delivery for a command? +++ in some API document provided by your friendly implementer - there is no iSCSI CAM (no pun intended) +++ dap: I hope an application (client) does not have to deal with multiple ways via different vendors to request immediate delivery. Sounds like this should be added to the iSCSI HBA API so we don't have to deal with differing vendor implementations to enable/disable this feature. T p 103 6.1.1 Usage of Retry and 6.7 SCSI Timeouts: the semantics of Retry remain broken rendering it useless for tape operation. SCSI level error detection and recovery is the preferred mechanism. Refer to previous emails sent via the IPS reflector regarding this matter. +++ Dave. The retry scheme for connection recovery implies that the other two levels are there. So even if I would agree with your POW (which I am not) for practical reasons the mechanisms described will have to stay. +++ dap: again, without a standardized method for error detection (see the options I listed) to determine when the retry may be performed, the retry functionality is broke/useless/inconsistent for tape applications. This is not an implementation detail as some suggest. This must be consistent across vendor implementations for a tape application to work consistently. T p 128 8.6 Considerations for State-dependent devices: last paragraph: don't agree with the statement that error recovery at the iSCSI level (specifically Retry in its current state) is advisable. Retry at the SCSI level is feasible and is not difficult (i.e., READ POSITION and LOCATE commands). This paragraph should be removed. +++ that is not what we repeatedly hear. I will however make a "softer" statement. +++ dap: I don't know who is feeding you this information. READ POSITION is and has been mandatory to implement for tape devices for quite a while now. Additionally I'm on the verge of making LOCATE mandatory (in reality if READ POSITION is implemented, so is LOCATE). Any backup app/application client worth anything uses READ POSITION (and LOCATE). I have a major problem with any text that suggests otherwise. The use of READ POSITION and LOCATE mitigates the need for retry (and most error recovery) at the transport level, and this is where I want to go. Retry at the application level simply must not be performed without first: 1. determine the position of the device using READ POSTITION, then 2. (re)position the device if neccessary, then 3. continue This is not difficult, provided READ POSITION/LOCATE are supported. If the offending paragraph is indeed targeted for legacy device support, it certainly does not say that. In reality, todays inplementations use READ POSITION/LOCATE extensively and (legacy) devices that do not support these commands are very rare for this type of tape application/environment. I expect that a legacy tape device will be front-ended by a bridge device (i.e., I don't expect to see a native-iSCSI legacy tape device). This legacy tape device will not support the desirable functionality (such as FCP-2 error detection and recovery) thus placing a burden on a bridge device if the desired goal is to be achieved. Furthermore, the legacy devices will generally be of the Parallel SCSI variety, not FCP. The FCP-x tape devices I know of each support READ POSITION/LOCATE. The offending paragraph (draft 15): "For many of those state changing commands the execution model also assumes that the command is executed exactly once. For those commands a retry at SCSI level is not feasible or very difficult and error recovery at iSCSI level is advisable." must be removed. Note: The connection reassignment capability does provide use for tape applications, e.g, will hopefully keep the application running. I have no problem using the retry functionality in this context. T p 214 11.11 BidiInitialR2T: this text key provides no value and needs to be removed. InitialR2T should be used for both uni and bidirectional commands. In addition, if BidiInitialR2T were to be used, it will not function via an iSCSI-FCP gateway. +++ A gateway can easily map the keys. We don't know enough to decide off-hand to remove it. But I am still listening. +++ dap: There is no reason to have a different key to indicate whether or not an R2T will be used for bidi commands. InitialR2T works just fine for both. FCP uses just one parameter (i.e., write FCP_XFER_RDY disabled) for both and all is well. What more can I say, other than remove the key. ------=_NextPart_000_002D_01C23194.DF46DFC0 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable
Howdy=20 Julian,
Comments to your comments below...dap
-----Original Message-----
From: Julian Satran=20 [mailto:Julian_Satran@il.ibm.com]
Sent: Sunday, July 14, = 2002 2:18=20 AM
To: Dave Peterson
Cc: Ips@Ece. Cmu. Edu;=20 owner-ips@ece.cmu.edu
Subject: Re: iSCSI: DAP Last Call=20 Comments


Dave = - Comments=20 in text - Thanks, Julo


"Dave Peterson"=20 <dap@cisco.com>
Sent=20 by: owner-ips@ece.cmu.edu=20

07/07/2002 11:19 PM =
Please respond to "Dave = Peterson"

        =
        To: =    =20    "Ips@Ece. Cmu. Edu" <ips@ece.cmu.edu>=20
        = cc:  =20      
 =20       Subject:        iSCSI: = DAP Last=20 Call Comments

  =  =20    


T           =    =20   p 36                 = 2.2.2.1=20 Command Numbering and Acknowledging: 7th paragraph: if not in
this=20 document, where is the means to request immediate delivery for=20 a
command?

+++ in = some API=20 document provided by your friendly implementer - there is no iSCSI CAM = (no pun=20 intended) +++ 
 
dap:=20 I hope an application (client) does not have to deal with multiple = ways via=20 different vendors to request immediate delivery. Sounds like this = should be=20 added to the iSCSI HBA API so we don't have to deal with differing = vendor=20 implementations to enable/disable this = feature.

T         =    =20     p 103               =  =20 6.1.1 Usage of Retry and 6.7 SCSI Timeouts: the semantics of = Retry
remain=20 broken rendering it useless for tape operation. SCSI level = error
detection=20 and recovery is the preferred mechanism. Refer to previous = emails
sent via=20 the IPS reflector regarding this matter.
+++ Dave. The retry scheme for connection recovery implies = that the=20 other two levels are there.
So even=20 if I would agree with your POW (which I am not) for practical reasons = the=20 mechanisms described
will have to=20 stay.
+++ 
 
dap: again, without a standardized = method for=20 error detection (see the options I listed) to determine when the=20 retry may be performed, the retry functionality is=20 broke/useless/inconsistent for tape applications. This is not an=20 implementation detail as some suggest. This must be consistent across = vendor=20 implementations for a tape application to work=20 consistently.
   
T     =    =20         p 128           =  =20     8.6 Considerations for State-dependent devices: last=20 paragraph:
don't agree with the statement that error recovery at = the iSCSI=20 level
(specifically Retry in its current state) is advisable. Retry = at the=20 SCSI
level is feasible and is not difficult (i.e., READ POSITION = and=20 LOCATE
commands). This paragraph should be removed. =
+++ that is not what we repeatedly hear. = I will=20 however make a "softer" statement. +++  
 
dap:=20 I don't know who is feeding you this information. READ POSITION is and = has=20 been mandatory to implement for tape devices for quite a while now.=20 Additionally I'm on the verge of making LOCATE mandatory (in reality = if READ=20 POSITION is implemented, so is LOCATE). Any backup app/application=20 client worth anything uses READ POSITION (and LOCATE). I have a = major=20 problem with any text that suggests otherwise. The use of READ = POSITION and=20 LOCATE mitigates the need for retry (and most error recovery) at the = transport=20 level, and this is where I want to go. Retry at the application level=20 simply must not be performed without first:
1.=20 determine the position of the device using READ POSTITION,=20 then
2.=20 (re)position the device if=20 neccessary, then
3.=20 continue
This=20 is not difficult, provided READ POSITION/LOCATE are=20 supported.
 
If=20 the offending paragraph is indeed targeted for legacy device = support, it=20 certainly does not say that. In reality, todays = inplementations use=20 READ POSITION/LOCATE extensively and (legacy) devices that do not = support=20 these commands are very rare for this type of tape=20 application/environment.
I=20 expect that a legacy tape device will be front-ended by a bridge = device=20 (i.e., I don't expect to see a native-iSCSI legacy tape device). This = legacy=20 tape device will not support the desirable functionality (such as = FCP-2 error=20 detection and recovery) thus placing a burden on a bridge device if = the=20 desired goal is to be achieved.
Furthermore, the legacy devices will = generally be of the=20 Parallel SCSI variety, not FCP. The FCP-x tape devices I know of each = support=20 READ POSITION/LOCATE.
 
The=20 offending paragraph (draft 15):
"For many of those state changing commands the execution = model also=20 assumes that the command is = executed exactly=20 once. For those commands a retry at = SCSI level=20 is not feasible or very difficult and error=20 recovery at iSCSI level is advisable."
must=20 be removed.
 
Note: The connection reassignment capability does = provide use=20 for tape applications, e.g, will hopefully keep the application = running. I=20 have no problem using the retry functionality in this=20 context.
 
T  =20               p 214     =  =20           11.11 BidiInitialR2T: this text key = provides no value and needs to
be removed. InitialR2T should be = used for=20 both uni and bidirectional
commands. In addition, if BidiInitialR2T = were to=20 be used, it will not
function via an iSCSI-FCP gateway.

+++ = A=20 gateway can easily map the keys. We don't know enough to decide = off-hand to=20 remove it.
But I = am still=20 listening.
+++ 

 dap: There is no reason to have a = different=20 key to indicate whether or not an R2T will be used for bidi = commands.=20 InitialR2T works just fine for both. FCP uses just one=20 parameter (i.e., write FCP_XFER_RDY disabled) for both and = all is=20 well. What more can I say, other than remove the=20 key.
 
------=_NextPart_000_002D_01C23194.DF46DFC0-- From owner-ips@ece.cmu.edu Mon Jul 22 18:02:29 2002 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA14226 for ; Mon, 22 Jul 2002 18:02:29 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id g6MLK0R12648 for ips-outgoing; Mon, 22 Jul 2002 17:20:00 -0400 (EDT) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from mail.ivivity.com ([64.238.111.99]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id g6MLJwo12641 for ; Mon, 22 Jul 2002 17:19:58 -0400 (EDT) Received: by ATLOPS with Internet Mail Service (5.5.2653.19) id ; Mon, 22 Jul 2002 17:19:57 -0400 Message-ID: From: Eddy Quicksall To: Black_David@emc.com Cc: ips@ece.cmu.edu Subject: RE: iSCSI: freeing resources during data-in and r2t Date: Mon, 22 Jul 2002 17:19:56 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-ips@ece.cmu.edu Precedence: bulk >reluctant semi-violent agreement -- yes Eddy -----Original Message----- From: Black_David@emc.com [mailto:Black_David@emc.com] Sent: Monday, July 22, 2002 3:33 PM To: eddy_quicksall@ivivity.com Cc: ips@ece.cmu.edu Subject: RE: iSCSI: freeing resources during data-in and r2t > As I said to David, it is probably too late for a change here but > it seems like we could have used StatSN (actually with a different name) > as a counter of everything going from the target to the initiator. > That way, the target does not have to associate the TCP ACK in order > to tell if the initiator got a PDU. A word of caution - the TCP ACK indicates that TCP delivered the bytes - if CRC digests are in use, a digest error could cause those bytes not to form a usable PDU. I view the A bit as an 80% solution that addresses the major portion of the need for targets to free resources prior to command completion, and I think Eddy's in reluctant semi-violent agreement that no change should be made here. Thanks, --David -----Original Message----- From: Eddy Quicksall [mailto:eddy_quicksall@ivivity.com] Sent: Monday, July 22, 2002 3:12 PM To: Julian Satran Cc: Black_David@emc.com; ips@ece.cmu.edu; owner-ips@ece.cmu.edu Subject: RE: iSCSI: freeing resources during data-in and r2t There are other resources besides the buffers that are used to transmit the data and it would be nice if those could be freed as soon as I know the initiator has them. As I said to David, it is probably too late for a change here but it seems like we could have used StatSN (actually with a different name) as a counter of everything going from the target to the initiator. That way, the target does not have to associate the TCP ACK in order to tell if the initiator got a PDU. Eddy -----Original Message----- From: Julian Satran [mailto:Julian_Satran@il.ibm.com] Sent: Friday, July 19, 2002 8:44 PM To: Eddy Quicksall Cc: Black_David@emc.com; ips@ece.cmu.edu; owner-ips@ece.cmu.edu Subject: RE: iSCSI: freeing resources during data-in and r2t Eddy, What resources? R2Ts for which the initiator has finished sending data can be discarded. Targets build R2Ts as needed. So what resources do you have in mind? Data Buffers at initiator? According to SAM2 you have to keep them up to the bitter end unless you request delivery strictly in order in which as you are better off issuing in sequence short writes if you want to allow recovery. If that is what you have in mind there is a basic asymmetry build in SCSI (and others) that the command issuers has the resource to keep the command going while the target (that can't plan the commands hitting it) has to be taken care of. iSCSI is not worsening this (neither improving on it). Regards, Julo Eddy Quicksall Sent by: owner-ips@ece.cmu.edu 07/19/2002 03:43 PM To: Black_David@emc.com cc: ips@ece.cmu.edu Subject: RE: iSCSI: freeing resources during data-in and r2t Yes, I agree that it is probably too late to think about this. But just to put you in perspective, I was referring more to the data-in, not the R2T's and the A bit causes extra traffic. I mostly wanted to point this out, I am not really asking for a change unless the group thinks it is relevant. If no one has an issue (and I really don't), then we can drop the thread. Eddy -----Original Message----- From: Black_David@emc.com [mailto:Black_David@emc.com] Sent: Wednesday, July 17, 2002 9:57 PM To: eddy_quicksall@ivivity.com Cc: ips@ece.cmu.edu Subject: RE: iSCSI: freeing resources during data-in and r2t Eddy, The A bit in Data-In plus Data ACK (SNACK type 2 in -14, Julian's renumbering of the SNACK types in the working version of -15 is/will be/has been undone) already provides the intermediate resource freeing for Data-In. This is only available for ErrorRecoveryLevel >= 1 We've never thought that R2Ts would consume enough resources to be worth putting in support for intermediate resource freeing of them. Adding another sequence number at this late date to deal with a "slight inefficiency" when the A bit is used properly (SNACK-Data ACK PDUs vs. a piggybacked count) does not seem like a good idea. Thanks, --David -----Original Message----- From: Eddy Quicksall [mailto:eddy_quicksall@ivivity.com] Sent: Wednesday, July 17, 2002 12:15 PM To: Mallikarjun C. (E-mail) Cc: ips@ece. cmu. edu (E-mail) Subject: RE: iSCSI: freeing resources during data-in and r2t I think see a slight inefficiency in how resources are freed when multiple data-in and r2t's PDU's are used when ErrorRecoverLevel > 0 or TCP ACK is not available to the iSCSI layer. Data-in and R2T's use DataSN and R2TSN. To free those resources, ExpStatSN is used. But if several R2T's and/or Data-in PDU's were used, resources used for those PDU's are tied up for the entire command. Since other commands could be received during this time, it would be nice if those commands could contain information that would tell the target that the R2T and/or Data-in PDU's have been received. I know a radical change at this point is probably a bad idea but I just wanted to throw out the idea ... if the StatSN/ExpStatSN were changed to something like RespSN/ExpRespSN and if everything going from the target to the initiator carried a new RespSN, then the resources could be freed up sooner. I would hate to use the A bit for this because it causes more traffic. Eddy mailto:Eddy_Quicksall@iVivity.com From owner-ips@ece.cmu.edu Tue Jul 23 17:42:03 2002 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA05046 for ; Tue, 23 Jul 2002 17:42:03 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id g6NKfgV25343 for ips-outgoing; Tue, 23 Jul 2002 16:41:42 -0400 (EDT) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from iol.unh.edu (io.iol.unh.edu [132.177.123.82]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id g6NKJfo23947 for ; Tue, 23 Jul 2002 16:19:41 -0400 (EDT) Received: from io.iol.unh.edu (localhost.localdomain [127.0.0.1]) by iol.unh.edu (8.12.3/8.12.3) with ESMTP id g6NKJZ6U009110; Tue, 23 Jul 2002 16:19:35 -0400 Received: from localhost (rdr@localhost) by io.iol.unh.edu (8.12.3/8.12.3/Submit) with ESMTP id g6NKJZCt009107; Tue, 23 Jul 2002 16:19:35 -0400 Date: Tue, 23 Jul 2002 16:19:35 -0400 (EDT) From: "Robert D. Russell" To: Julian Satran cc: ips@ece.cmu.edu Subject: iSCSI: Use of Reject as a key value In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: MULTIPART/MIXED; BOUNDARY="-1316728197-958788825-1027455575=:8917" Sender: owner-ips@ece.cmu.edu Precedence: bulk This message is in MIME format. The first part should be readable text, while the remaining parts are likely unreadable without MIME-aware tools. Send mail to mime@docserver.cac.washington.edu for more info. ---1316728197-958788825-1027455575=:8917 Content-Type: TEXT/PLAIN; charset=US-ASCII Julian: Attached are 2 ascii text files. The first, reject_extracts.txt, contains all the pieces of draft 14 (the latest available txt version of the drafts) that say anything about the use of Reject as a key value. (At least all those I could find using simple search -- unfortunately, Reject is also the name of a PDU and hence it is not a simple mechanical process to distinguish the two uses! If I missed some, please let me know.) The second, reject_comments.txt, are my comments on these excerpts from the standard. It seems to me that the key thing missing in the standard is a general statement about "what to do next" if a key=Reject response is received. Except for the OFMarkInt and IFMarkInt keys, I could find no other statement about how to proceed after receiving the key=Reject response. In looking through the e-mails posted to the list for June and July, I also could find nothing, although many people seem to be taking the third of the 3 interpretations I listed in reject_comments.txt. I am requesting a clear statement somewhere in the standard that says "what to do next" upon receiving a key=Reject response. Thank you for your consideration. Bob Russell InterOperability Lab University of New Hampshire rdr@iol.unh.edu 603-862-3774 ---1316728197-958788825-1027455575=:8917 Content-Type: TEXT/plain; name="reject_extracts.txt" Content-ID: Content-Description: Content-Disposition: attachment; filename="reject_extracts.txt" Content-Transfer-Encoding: BASE64 DQpBbGwgcmVmZXJlbmNlcyBpbiBkcmFmdCAxNCB0byB1c2Ugb2YgIlJlamVj dCIgYXMgYSBrZXkgdmFsdWUuDQotLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tDQoNCi4uLg0K DQo0LjIgIFRleHQgTW9kZSBOZWdvdGlhdGlvbg0KDQouLi4NCg0KICAgVGhl IGdlbmVyYWwgZm9ybWF0IG9mIHRleHQgbmVnb3RpYXRpb24gaXM6DQoNCiAg ICAgIE9yaWdpbmF0b3ItPiA8a2V5Pj08dmFsdWV4Pg0KICAgICAgUmVzcG9u ZGVyLT4gPGtleT49PHZhbHVleT58Tm90VW5kZXJzdG9vZHxJcnJlbGV2YW50 fFJlamVjdA0KDQogICBUaGUgb3JpZ2luYXRvciBvciBkZWNsYXJlciBjYW4g ZWl0aGVyIGJlIHRoZSBpbml0aWF0b3Igb3IgdGhlIHRhcmdldCANCiAgIGFu ZCB0aGUgcmVzcG9uZGVyIGNhbiBlaXRoZXIgYmUgdGhlIHRhcmdldCBvciBp bml0aWF0b3IsIHJlc3BlYy0NCiAgIHRpdmVseS4gVGFyZ2V0cyBhcmUgbm90 IGxpbWl0ZWQgdG8gcmVzcG9uZCB0byBrZXk9dmFsdWUgcGFpcnMgYXMgDQog ICBvZmZlcmVkIGJ5IHRoZSBpbml0aWF0b3IuIFRoZSB0YXJnZXQgbWF5IG9m ZmVyIGtleT12YWx1ZSBwYWlycyBvZiBpdHMgDQogICBvd24uIA0KDQogICBB bGwgbmVnb3RpYXRpb25zIGFyZSBleHBsaWNpdCAoaS5lLiwgdGhlIHJlc3Vs dCBNVVNUIGJlIGJhc2VkIG9ubHkgb24gDQogICBuZXdseSBleGNoYW5nZWQg b3IgZGVjbGFyZWQgdmFsdWVzKS4gVGhlcmUgYXJlIG5vIGltcGxpY2l0IG9m ZmVycy4gSWYgDQogICBhbiBleHBsaWNpdCBvZmZlciBpcyBub3QgbWFkZSB0 aGVuIGEgcmVwbHkgY2Fubm90IGJlIGV4cGVjdGVkLiBDb24tDQogICBzZXJ2 YXRpdmUgZGVzaWduIHJlcXVpcmVzIGFsc28gdGhhdCBkZWZhdWx0IHZhbHVl cyBzaG91bGQgbm90IGJlIA0KICAgcmVsaWVkIHVwb24gd2hlbiB1c2Ugb2Yg c29tZSBvdGhlciB2YWx1ZSBoYXMgc2VyaW91cyBjb25zZXF1ZW5jZXMuIA0K DQogICBUaGUgdmFsdWUgb2ZmZXJlZCBvciBkZWNsYXJlZCBjYW4gYmUgYSBu dW1lcmljYWwtdmFsdWUsIGEgbnVtZXJpY2FsLQ0KICAgcmFuZ2UgZGVmaW5l ZCBieSBsb3dlciBhbmQgdXBwZXIgdmFsdWUgLSBib3RoIGludGVnZXJzIHNl cGFyYXRlZCBieSANCiAgIHRpbGRlLCBhIGJpbmFyeSB2YWx1ZSwgYSB0ZXh0 LXZhbHVlLCBhIGlTQ1NJLW5hbWUtdmFsdWUsIGFuIGlTQ1NJLQ0KICAgbG9j YWwtbmFtZS12YWx1ZSwgYSBib29sZWFuLXZhbHVlIChZZXMgb3IgTm8pLCBv ciBhIGxpc3Qgb2YgY29tbWEgDQogICBzZXBhcmF0ZWQgdGV4dC12YWx1ZXMu IEEgcmFuZ2Ugb3IgYSBsYXJnZS1udW1lcmljYWwtdmFsdWUgTUFZIE9OTFkg YmUgDQogICBvZmZlcmVkIGlmIGl0IGlzIGV4cGxpY2l0bHkgYWxsb3dlZCBm b3IgYSBrZXkuIEFuIGlTQ1NJLW5hbWUtdmFsdWUgDQogICBhbmQgYW4gaVND U0ktbG9jYWwtbmFtZS12YWx1ZSBjYW4gYmUgdXNlZCBvbmx5IHdoZXJlIGV4 cGxpY2l0bHkgDQogICBhbGxvd2VkLiBBIHNlbGVjdGVkIHZhbHVlIGNhbiBi ZSBhbiBudW1lcmljYWwtdmFsdWUsIGEgbGFyZ2UtbnVtZXJpLQ0KICAgY2Fs LXZhbHVlLCBhIHRleHQtdmFsdWUgb3IgYSBib29sZWFuLXZhbHVlLg0KDQog ICBJZiBhIHNwZWNpZmljIGtleSBpcyBub3QgcmVsZXZhbnQgZm9yIHRoZSBj dXJyZW50IG5lZ290aWF0aW9uLCB0aGUgDQogICByZXNwb25kZXIgbWF5IGFu c3dlciB3aXRoIHRoZSBjb25zdGFudCAiSXJyZWxldmFudCIgZm9yIGFsbCB0 eXBlcyBvZiANCiAgIG5lZ290aWF0aW9uLiBIb3dldmVyIHRoZSBuZWdvdGlh dGlvbiBpcyBub3QgY29uc2lkZXJlZCBhcyBmYWlsZWQgaWYgDQogICB0aGUg cmVzcG9uc2UgaXMgIklycmVsZXZhbnQiLg0KDQogICBBbnkga2V5IG5vdCB1 bmRlcnN0b29kIGJ5IHRoZSByZXNwb25kZXIgbWF5IGJlIGlnbm9yZWQgYnkg dGhlIA0KICAgcmVzcG9uZGVyIHdpdGhvdXQgYWZmZWN0aW5nIHRoZSBiYXNp YyBmdW5jdGlvbi4gSG93ZXZlciwgdGhlIFRleHQgDQogICBSZXNwb25zZSBm b3IgYSBrZXkgbm90IHVuZGVyc3Rvb2QgTVVTVCBiZSBrZXk9Tm90VW5kZXJz dG9vZC4NCg0KICAgVGhlIGNvbnN0YW50cyAiTm9uZSIsICJSZWplY3QiLCAi SXJyZWxldmFudCIsIGFuZCAiTm90VW5kZXJzdG9vZCIgYXJlIA0KICAgcmVz ZXJ2ZWQgYW5kIG11c3Qgb25seSBiZSB1c2VkIGFzIGRlc2NyaWJlZCBoZXJl Lg0KDQogICBSZWplY3Qgb3IgSXJyZWxldmFudCBhcmUgbGVnaXRpbWF0ZSBu ZWdvdGlhdGlvbiBvcHRpb25zIHdoZXJlIGFsbG93ZWQgDQogICBidXQgdGhl aXIgZXhjZXNzaXZlIHVzZSBpcyBkaXNjb3VyYWdlZC4gQSBuZWdvdGlhdGlv biBpcyBjb25zaWRlcmVkIA0KICAgY29tcGxldGUgd2hlbiB0aGUgcmVzcG9u ZGVyIGhhcyBzZW50IHRoZSBrZXkgdmFsdWUgcGFpciBldmVuIGlmIHRoZSAN CiAgIHZhbHVlIGlzICJSZWplY3QiLCAiSXJyZWxldmFudCIsIG9yICJOb3RV bmRlcnN0b29kLiBTZW5kaW5nIHRoZSBrZXkgDQogICBhZ2FpbiB3b3VsZCBi ZSBhIHJlLW5lZ290aWF0aW9uDQogICAgDQogICBTb21lIGJhc2ljIGtleT12 YWx1ZSBwYWlycyBhcmUgZGVzY3JpYmVkIGluIENoYXB0ZXIgMTEuIEFsbCBr ZXlzIGluIA0KICAgQ2hhcHRlciAxMSwgZXhjZXB0IGZvciB0aGUgWC0gZXh0 ZW5zaW9uIGZvcm1hdCwgTVVTVCBiZSBzdXBwb3J0ZWQgYnkgDQogICBpU0NT SSBpbml0aWF0b3JzIGFuZCB0YXJnZXRzIGFuZCBNVVNUIE5PVCBiZSBhbnN3 ZXJlZCB3aXRoIE5vdFVuZGVyLQ0KICAgc3Rvb2QuDQogICAgDQouLi4NCg0K DQo0LjIuMSAgTGlzdCBuZWdvdGlhdGlvbnMNCg0KICAgSW4gbGlzdCBuZWdv dGlhdGlvbiwgdGhlIG9yaWdpbmF0b3Igc2VuZHMgYSBsaXN0IG9mIHZhbHVl cyAod2hpY2ggbWF5IA0KICAgaW5jbHVkZSAiTm9uZSIpIGluIGl0cyBvcmRl ciBvZiBwcmVmZXJlbmNlLg0KDQogICBUaGUgcmVzcG9uZGluZyBwYXJ0eSBN VVNUIHJlc3BvbmQgd2l0aCB0aGUgc2FtZSBrZXkgYW5kIHRoZSBmaXJzdCAN CiAgIHZhbHVlIHRoYXQgaXQgc3VwcG9ydHMgKGFuZCBpcyBhbGxvd2VkIHRv IHVzZSBmb3IgdGhlIHNwZWNpZmljIG9yaWdpLQ0KICAgbmF0b3IpIHNlbGVj dGVkIGZyb20gdGhlIG9yaWdpbmF0b3IgbGlzdC4gDQoNCiAgIFRoZSBjb25z dGFudCAiTm9uZSIgTVVTVCBhbHdheXMgYmUgdXNlZCB0byBpbmRpY2F0ZSBh IG1pc3NpbmcgZnVuYy0NCiAgIHRpb24uIEhvd2V2ZXIsIE5vbmUgaXMgYSB2 YWxpZCBzZWxlY3Rpb24gb25seSBpZiBpdCBpcyBleHBsaWNpdGx5IA0KICAg b2ZmZXJlZC4gDQoNCiAgIElmIGEgcmVzcG9uZGVyIGRvZXMgbm90IHVuZGVy c3RhbmQgYW55IHBhcnRpY3VsYXIgdmFsdWUgaW4gYSBsaXN0IGl0IA0KICAg TVVTVCBpZ25vcmUgaXQuIElmIGEgcmVzcG9uZGVyIGRvZXMgc3VwcG9ydCwg dW5kZXJzdGFuZCBvciBpcyBhbGxvd2VkIA0KICAgdG8gdXNlIG5vbmUgb2Yg dGhlIG9mZmVyZWQgb3B0aW9ucyB3aXRoIGEgc3BlY2lmaWMgb3JpZ2luYXRv ciwgaXQgbWF5IA0KICAgdXNlIHRoZSBjb25zdGFudCAiUmVqZWN0IiBvciB0 ZXJtaW5hdGUgdGhlIG5lZ290aWF0aW9uLiBUaGUgc2VsZWMtDQogICB0aW9u IG9mIGEgdmFsdWUgbm90IG9mZmVyZWQgaXMgY29uc2lkZXJlZCBhIG5lZ290 aWF0aW9uIGZhaWx1cmUgYW5kIA0KICAgaXMgaGFuZGxlZCBhcyBhIHByb3Rv Y29sIGVycm9yLiANCg0KNC4yLjIgIFNpbXBsZS12YWx1ZSBuZWdvdGlhdGlv bnMNCg0KICAgRm9yIHNpbXBsZS12YWx1ZSBuZWdvdGlhdGlvbnMsIHRoZSBy ZXNwb25kaW5nIHBhcnR5IE1VU1QgcmVzcG9uZCB3aXRoIA0KICAgdGhlIHNh bWUga2V5LiBUaGUgdmFsdWUgaXQgc2VsZWN0cywgYmFzZWQgb24gdGhlIHNl bGVjdGlvbiBydWxlIHNwZS0NCiAgIGNpZmljIHRvIHRoZSBrZXksIGJlY29t ZXMgdGhlIG5lZ290aWF0aW9uIHJlc3VsdC4gRm9yIGEgbnVtZXJpY2FsIA0K ICAgcmFuZ2UgdGhlIHZhbHVlIHNlbGVjdGVkIG11c3QgYmUgYW4gaW50ZWdl ciB3aXRoaW4gdGhlIG9mZmVyZWQgcmFuZ2UgDQogICBvciAiUmVqZWN0IiAo aWYgdGhlIHJhbmdlIGlzIHVuYWNjZXB0YWJsZSkuIEFuIG9mZmVyIG9mIGEg dmFsdWUgbm90IA0KICAgYWRtaXNzaWJsZSAoZS5nLiwgbm90IHdpdGhpbiB0 aGUgc3BlY2lmaWVkIGJvdW5kcykgTUFZIGJlIGFuc3dlcmVkIA0KICAgd2l0 aCB0aGUgY29uc3RhbnQgIlJlamVjdCIgb3IgdGhlIHJlc3BvbmRlciBNQVkg c2VsZWN0IGFuIGFkbWlzc2libGUgDQogICB2YWx1ZS4gVGhlIHNlbGVjdGlv biwgYnkgdGhlIHJlc3BvbmRlciwgb2YgYSB2YWx1ZSBub3QgYWRtaXNzaWJs ZSANCiAgIHVuZGVyIHRoZSBzZWxlY3Rpb24gcnVsZXMgaXMgY29uc2lkZXJl ZCBhIG5lZ290aWF0aW9uIGZhaWx1cmUgYW5kIGlzIA0KICAgaGFuZGxlZCBh Y2NvcmRpbmdseS4gVGhlIHNlbGVjdGlvbiBydWxlcyBhcmUga2V5LXNwZWNp ZmljLiANCg0KLi4uDQoNCg0KNC4zICBMb2dpbiBQaGFzZQ0KDQouLi4NCg0K ICAgTmVpdGhlciB0aGUgaW5pdGlhdG9yIG5vciB0aGUgdGFyZ2V0IHNob3Vs ZCBhdHRlbXB0IHRvIGRlY2xhcmUgb3IgDQogICBuZWdvdGlhdGUgYSBwYXJh bWV0ZXIgbW9yZSB0aGFuIG9uY2UgZHVyaW5nIGxvZ2luIGV4Y2VwdCBmb3Ig DQogICByZXNwb25zZXMgdG8gc3BlY2lmaWMga2V5cyB0aGF0IGV4cGxpY2l0 bHkgYWxsb3cgcmVwZWF0ZWQga2V5IGRlY2xhLQ0KICAgcmF0aW9ucyAoZS5n LiBUYXJnZXRBZGRyZXNzKS4gSWYgZGV0ZWN0ZWQgYnkgdGhlIHRhcmdldCB0 aGlzIE1VU1QgDQogICByZXN1bHQgaW4gYSBMb2dpbiByZWplY3QgKGluaXRp YXRvciBlcnJvcikuIFRoZSBpbml0aWF0b3IgTVVTVCBkcm9wIA0KICAgdGhl IGNvbm5lY3Rpb24NCiAgICANCg0KLi4uDQoNCjQuMy4yICBpU0NTSSBTZWN1 cml0eSBOZWdvdGlhdGlvbg0KDQogICBUaGUgc2VjdXJpdHkgZXhjaGFuZ2Ug c2V0cyB0aGUgc2VjdXJpdHkgbWVjaGFuaXNtIGFuZCBhdXRoZW50aWNhdGVz DQogICB0aGUgaW5pdGlhdG9yIHVzZXIgYW5kIHRoZSB0YXJnZXQgdG8gZWFj aCBvdGhlci4gVGhlIGV4Y2hhbmdlIHByby0NCiAgIGNlZWRzIGFjY29yZGlu ZyB0byB0aGUgYXV0aGVudGljYXRpb24gbWV0aG9kIGNob3NlbiBpbiB0aGUg bmVnb3RpYS0NCiAgIHRpb24gcGhhc2UgYW5kIGlzIGNvbmR1Y3RlZCB1c2lu ZyB0aGUgbG9naW4gcmVxdWVzdHMnIGFuZCByZXNwb25zZXMnIA0KICAga2V5 PXZhbHVlIHBhcmFtZXRlcnMuDQoNCiAgIEFuIGluaXRpYXRvciBkaXJlY3Rl ZCBuZWdvdGlhdGlvbiBwcm9jZWVkcyBhcyBmb2xsb3dzOg0KDQogICAgIC1U aGUgaW5pdGlhdG9yIHNlbmRzIGEgbG9naW4gcmVxdWVzdCB3aXRoIGFuIG9y ZGVyZWQgbGlzdCBvZiANCiAgICAgICB0aGUgb3B0aW9ucyBpdCBzdXBwb3J0 cyAoYXV0aGVudGljYXRpb24gYWxnb3JpdGhtKS4gVGhlIA0KICAgICAgIG9w dGlvbnMgYXJlIGxpc3RlZCBpbiB0aGUgaW5pdGlhdG9yJ3Mgb3JkZXIgb2Yg cHJlZmVyZW5jZS4gDQogICAgICAgVGhlIGluaXRpYXRvciBNQVkgYWxzbyBz ZW5kIHByb3ByaWV0YXJ5IG9wdGlvbnMuIA0KICAgICAtVGhlIHRhcmdldCBN VVNUIHJlcGx5IHdpdGggdGhlIGZpcnN0IG9wdGlvbiBpbiB0aGUgbGlzdCBp dCANCiAgICAgICBzdXBwb3J0cyBhbmQgaXMgYWxsb3dlZCB0byB1c2UgZm9y IHRoZSBzcGVjaWZpYyBpbml0aWF0b3IgDQogICAgICAgdW5sZXNzIGl0IGRv ZXMgbm90IHN1cHBvcnQgYW55IGluIHdoaWNoIGNhc2UgaXQgTVVTVCBhbnN3 ZXIgDQogICAgICAgd2l0aCAiUmVqZWN0IiAoc2VlIGFsc28gU2VjdGlvbiA0 LjIgVGV4dCBNb2RlIE5lZ290aWF0aW9uKS4gDQogICAgICAgVGhlIHBhcmFt ZXRlcnMgYXJlIGVuY29kZWQgaW4gVVRGOCBhcyBrZXk9dmFsdWUuIEZvciBz ZWN1LQ0KICAgICAgIHJpdHkgcGFyYW1ldGVycywgc2VlIENoYXB0ZXIgMTAu DQoNCi4uLg0KDQpBLjMuMiAgIE9GTWFya0ludCwgSUZNYXJrSW50DQoNCiAg IFVzZTogSU8NCiAgIFNlbmRlcnM6IEluaXRpYXRvciBhbmQgVGFyZ2V0DQog ICBTY29wZTogQ08NCg0KICAgT2ZmZXJpbmc6DQoNCiAgIE9GTWFya0ludD08 bnVtZXJpYy1yYW5nZS1mcm9tLTEtdG8tNjU1MzU+IA0KICAgSUZNYXJrSW50 PTxudW1lcmljLXJhbmdlLWZyb20tMS10by02NTUzNT4NCg0KICAgUmVzcG9u ZGluZzoNCg0KICAgT0ZNYXJrSW50PTxudW1lcmljLXZhbHVlLWZyb20tMS10 by02NTUzNT58UmVqZWN0DQogICBJRk1hcmtJbnQ9PG51bWVyaWMtdmFsdWUt ZnJvbS0xLXRvLTY1NTM1PnxSZWplY3QNCg0KICAgT0ZNYXJrSW50IGlzIHVz ZWQgdG8gc2V0IHRoZSBpbnRlcnZhbCBmb3IgdGhlIGluaXRpYXRvciB0byB0 YXJnZXQgDQogICBtYXJrZXJzIG9uIHRoZSBjb25uZWN0aW9uLiAgSUZNYXJr SW50IGlzIHVzZWQgdG8gc2V0IHRoZSBpbnRlcnZhbCBmb3IgDQogICB0aGUg dGFyZ2V0IHRvIGluaXRpYXRvciBtYXJrZXJzIG9uIHRoZSBjb25uZWN0aW9u Lg0KDQogICBGb3IgdGhlIG9mZmVyaW5nIHRoZSBpbml0aWF0b3Igb3IgdGFy Z2V0IGluZGljYXRlcyB0aGUgbWluaW11bSB0byANCiAgIG1heGltdW0gaW50 ZXJ2YWwgKGluIDQtYnl0ZSB3b3JkcykgaXQgd2FudHMgdGhlIG1hcmtlcnMg Zm9yIG9uZSBvciANCiAgIGJvdGggZGlyZWN0aW9ucy4gSW4gY2FzZSBpdCBv bmx5IHdhbnRzIGEgc3BlY2lmaWMgdmFsdWUsIG9ubHkgYSBzaW4tDQogICBn bGUgdmFsdWUgaGFzIHRvIGJlIHNwZWNpZmllZC4gVGhlIHJlc3BvbmRlciBz ZWxlY3RzIGEgdmFsdWUgd2l0aGluIA0KICAgdGhlIG1pbmltdW0gYW5kIG1h eGltdW0gb2ZmZXJlZCBvciB0aGUgb25seSB2YWx1ZSBvZmZlcmVkIG9yIGlu ZGktDQogICBjYXRlcyB0aHJvdWdoIHRoZSB4Rk1hcmtlciBrZXk9dmFsdWUg aXRzIGluYWJpbGl0eSB0byBzZXQgYW5kL29yIA0KICAgcmVjZWl2ZSBtYXJr ZXJzLiBXaGVuIHRoZSBpbnRlcnZhbCBpcyB1bmFjY2VwdGFibGUgdGhlIHJl c3BvbmRlciANCiAgIGFuc3dlcnMgd2l0aCAiUmVqZWN0Ii4gIFJlamVjdCBp cyByZXNldHRpbmcgdGhlIG1hcmtlciBmdW5jdGlvbiBpbiANCiAgIHRoZSBz cGVjaWZpZWQgZGlyZWN0aW9uIChPdXRwdXQgb3IgSW5wdXQpIHRvIE5vLg0K DQouLi4NCg== ---1316728197-958788825-1027455575=:8917 Content-Type: TEXT/plain; name="reject_comments.txt" Content-ID: Content-Description: Content-Disposition: attachment; filename="reject_comments.txt" Content-Transfer-Encoding: BASE64 Q29tbWVudHMgb24gdGhlIHVzZSBvZiAiUmVqZWN0IiBhcyBhIGtleSB2YWx1 ZS4NCg0KSW4gc2VjdGlvbiA0LjIsIHRoZSAiZ2VuZXJhbCBmb3JtYXQgb2Yg dGV4dCBuZWdvdGlhdGlvbiIgY2xlYXJseSBhbGxvd3MNCmJvdGggaW5pdGlh dG9yIGFuZCB0YXJnZXQgdG8gc2VuZCBhbmQgcmVjZWl2ZSBhICJSZWplY3Qi IHZhbHVlLg0KDQpIb3dldmVyLCB0aGlzICJnZW5lcmFsIGZvcm1hdCIgZG9l cyBub3QgbmVjZXNzYXJpbHkgaW1wbHkgdGhhdCBpdCBpcw0KbGVnYWwgdG8g c2VuZCBhICJSZWplY3QiIHZhbHVlIGF0IGFueSB0aW1lIGFuZCBmb3IgYW55 IGtleSENCg0KTGF0ZXIgaW4gdGhlIHNhbWUgc2VjdGlvbiA0LjIgaXQgc2F5 czoNCg0KICAgICJSZWplY3Qgb3IgSXJyZWxldmFudCBhcmUgbGVnaXRpbWF0 ZSBuZWdvdGlhdGlvbiBvcHRpb25zIHdoZXJlDQogICAgYWxsb3dlZCBidXQg Li4uIi4NCg0KVGhpcyBjb3VsZCBiZSByZWFkIHRvIGltcGx5IHRoYXQgZnVy dGhlciBleHBsYW5hdGlvbnMgbXVzdCBiZSBnaXZlbiB0bw0KaW5kaWNhdGUg d2hlcmUgUmVqZWN0IChJcnJlbGV2YW50KSBpcyBhbGxvd2VkLiAgSW4gZmFj dCwgdGhlIHN0YW5kYXJkIA0KZXhwbGljaXRseSBsaXN0cyB0aGUgZm9sbG93 aW5nIHNwZWNpZmljIHNpdHVhdGlvbnMgd2hlcmUgUmVqZWN0IGlzIGFsbG93 ZWQuDQoNCiAgICAxLiAgSW4gc2VjdGlvbiA0LjIuMSwgTGlzdCBuZWdvdGlh dGlvbnMsIGl0IHNheXM6DQogICAgICAgIA0KICAgICAgICAiSWYgYSByZXNw b25kZXIgZG9lcyBzdXBwb3J0LCB1bmRlcnN0YW5kIG9yIGlzIGFsbG93ZWQg dG8gdXNlDQogICAgICAgIG5vbmUgb2YgdGhlIG9mZmVyZWQgb3B0aW9ucyB3 aXRoIGEgc3BlY2lmaWMgb3JpZ2luYXRvciwgaXQgbWF5DQogICAgICAgIHVz ZSB0aGUgY29uc3RhbnQgIlJlamVjdCIgb3IgdGVybWluYXRlIHRoZSBuZWdv dGlhdGlvbi4iDQoNCiAgICAgIC0tVGhpcyBjb3VsZCBiZSB1bmRlcnN0b29k IHRvIG1lYW4gdGhhdCAiUmVqZWN0IiBkb2VzIE5PVCB0ZXJtaW5hdGUNCiAg ICAgICAgdGhlIG5lZ290aWF0aW9uLiAgSG93ZXZlciwgdGhlIG5leHQgc2Vu dGVuY2UgaW4gdGhlIHN0YW5kYXJkIHNheXM6DQoNCiAgICAgICAgIlRoZSBz ZWxlY3Rpb24gb2YgYSB2YWx1ZSBub3Qgb2ZmZXJlZCBpcyBjb25zaWRlcmVk IGEgbmVnb3RpYXRpb24NCiAgICAgICAgZmFpbHVyZSBhbmQgaXMgaGFuZGxl ZCBhcyBhIHByb3RvY29sIGVycm9yLiINCg0KICAgICAgLS1DbGVhcmx5ICJS ZWplY3QiIHdhcyBub3Qgb2ZmZXJlZCwgc28gaWYgaXQgYXBwZWFycyBpbiB0 aGUNCiAgICAgICAgcmVzcG9uc2UsIHRoaXMgc2VudGVuY2UgY291bGQgYmUg dW5kZXJzdG9vZCB0byBtZWFuIHRoYXQgdGhlDQogICAgICAgIG5lZ290aWF0 aW9uIGZhaWxlZC4NCg0KDQogICAgMi4gIEluIHNlY3Rpb24gNC4yLjIsIFNp bXBsZS12YWx1ZSBuZWdvdGlhdGlvbnMsIGl0IHNheXM6DQoNCiAgICAgICAg IkZvciBhIG51bWVyaWNhbCByYW5nZSB0aGUgdmFsdWUgc2VsZWN0ZWQgbXVz dCBiZSBhbiBpbnRlZ2VyDQogICAgICAgIHdpdGhpbmcgdGhlIG9mZmVyZWQg cmFuZ2Ugb3IgIlJlamVjdCIgKGlmIHRoZSByYW5nZSBpcw0KICAgICAgICB1 bmFjY2VwdGFibGUpLiINCg0KICAgICAgLS1UaGlzIGV4cGxpY2l0bHkgYWxs b3dzIFJlamVjdCBhcyBhIHJlc3BvbnNlIGZvciBudW1lcmljYWwgcmFuZ2UN CiAgICAgICAgcGFyYW1ldGVycyAob2Ygd2hpY2ggdGhlcmUgYXJlIG9ubHkg dHdvOiBPRk1hcmtJbnQgYW5kIElGTWFya0ludCksDQogICAgICAgIGJ1dCBk b2Vzbid0IHNheSB3aGF0IHRvIGRvIG5leHQgaWYgUmVqZWN0IGlzIHVzZWQu ICBIb3dldmVyLA0KICAgICAgICBzZWN0aW9uIEEuMy4yIGRvZXMgc2F5IHdo YXQgdG8gZG8gZm9yIHRoZSBPRk1hcmtJbnQgYW5kIElGTWFya0ludA0KICAg ICAgICBrZXlzIChzZWUgYmVsb3cpLg0KDQoNCiAgICAzLiAgQWxzbyBpbiBz ZWN0aW9uIDQuMi4yLCBTaW1wbGUtdmFsdWUgbmVnb3RpYXRpb25zLCBpdCBz YXlzOg0KDQogICAgICAgICJBbiBvZmZlciBvZiBhIHZhbHVlIG5vdCBhZG1p c3NpYmxlIChlLmUuLCBub3Qgd2l0aGluIHRoZSBzcGVjaWZpZWQNCiAgICAg ICAgYm91bmRzKSBNQVkgYmUgYW5zd2VyZWQgd2l0aCB0aGUgY29uc3RhbnQg IlJlamVjdCIgb3IgdGhlIHJlc3BvbmRlcg0KICAgICAgICBNQVkgc2VsZWN0 IGFuIGFkbWlzc2libGUgdmFsdWUuIg0KDQogICAgICAtLVRoaXMgZXhwbGlj aXRseSBhbGxvd3MgUmVqZWN0IGFzIGEgcmVzcG9uc2UgZm9yIG90aGVyIHNp bXBsZS12YWx1ZQ0KICAgICAgICB0eXBlcyAoa2V5cyBleHBlY3RpbmcgbnVt ZXJpY2FsIHZhbHVlcywgYm9vbGVhbiB2YWx1ZXMsIGV0Yy4pLA0KICAgICAg ICBidXQgYWdhaW4gZG9lc24ndCBzYXkgd2hhdCB0byBkbyBuZXh0IGlmIFJl amVjdCBpcyB1c2VkLg0KDQoNCiAgICA0LiAgSW4gc2VjdGlvbiA0LjMuMiwg aVNDU0kgU2VjdXJpdHkgTmVnb3RpYXRpb24sIGl0IHNheXM6DQoNCiAgICAg ICAgIi1UaGUgdGFyZ2V0IE1VU1QgcmVwbHkgd2l0aCB0aGUgZmlyc3Qgb3B0 aW9uIGluIHRoZSBsaXN0IGl0DQogICAgICAgIHN1cHBvcnRzIGFuZCBpcyBh bGxvd2VkIHRvIHVzZSBmb3IgdGhlIHNwZWNpZmljIGluaXRpYXRvcg0KICAg ICAgICB1bmxlc3MgaXQgZG9lcyBub3Qgc3VwcG9ydCBhbnkgaW4gd2hpY2gg Y2FzZSBpdCBNVVNUIGFuc3dlcg0KICAgICAgICB3aXRoICJSZWplY3QiIChz ZWUgYWxzbyBTZWN0aW9uIDQuMiBUZXh0IE1vZGUgTmVnb3RpYXRpb24pLiIN Cg0KICAgICAgLS1PaywgYnV0IHRoZW4gd2hhdCBoYXBwZW5zIG5leHQgLS0g aGFzIHRoZSBuZWdvdGlhdGlvbiBmYWlsZWQ/DQogICAgICAgIElmIG5vdCwg d2hhdCB2YWx1ZSBpcyB1c2VkIGZvciB0aGUgcmVqZWN0ZWQga2V5IC0tIHRo ZSB2YWx1ZQ0KICAgICAgICBpbiBlZmZlY3QgcHJpb3IgdG8gdGhpcyBvZmZl ci9yZXNwb25zZSBleGNoYW5nZT8gIFRoZSBzdGFuZGFyZA0KICAgICAgICBu ZXZlciBzYXlzLg0KDQoNCiAgICA1LiAgSW4gc2VjdGlvbiBBLjMuMiwgT0ZN YXJrSW50LCBJRk1hcmtJbnQsIGl0IHNheXM6DQoNCiAgICAgICAgIlJlc3Bv bmRpbmc6DQogICAgICAgIE9GTWFya0ludD08bnVtZXJpYy1yYW5nZS1mcm9t LTEtdG8tNjU1MzU+fFJlamVjdA0KICAgICAgICBJRk1hcmtJbnQ9PG51bWVy aWMtcmFuZ2UtZnJvbS0xLXRvLTY1NTM1PnxSZWplY3QiDQoNCiAgICAgIC0t VGhpcyBpcyB0aGUgb25seSBpbnN0YW5jZSB3aGVyZSBSZWplY3QgaXMgZXhw bGljaXRseSBzcGVjaWZpZWQNCiAgICAgICAgYXMgYSB2YWxpZCByZXNwb25z ZSBmb3IgYSBzcGVjaWZpYyBrZXkuDQoNCg0KICAgIDYuICBBbHNvIGluIHNl Y3Rpb24gQS4zLjIsIE9GTWFya0ludCwgSUZNYXJrSW50LCBpdCBzYXlzOg0K DQogICAgICAgICJXaGVuIHRoZSBpbnRlcnZhbCBpcyB1bmFjY2VwdGFibGUg dGhlIHJlc3BvbmRlciBhbnN3ZXJzIHdpdGgNCiAgICAgICAgIlJlamVjdCIu ICBSZWplY3QgaXMgcmVzZXR0aW5nIHRoZSBtYXJrZXIgZnVuY3Rpb24gaW4g dGhlDQogICAgICAgIHNwZWNpZmllZCBkaXJlY3Rpb24gKE91dHB1dCBvciBJ bnB1dCkgdG8gTm8uIg0KDQogICAgICAtLVRoaXMgaXMgYWxzbyB0aGUgb25s eSBpbnN0YW5jZSB3aGVyZSB0aGUgc3RhbmRhcmQgc2F5cyB3aGF0IHRvDQog ICAgICAgIGRvIHdoZW4gYSByZXNwb25zZSB2YWx1ZSBvZiBSZWplY3QgaXMg dXNlZC4NCg0KDQpJIGJlbGlldmUgdGhlIHNvdXJjZSBvZiBtdWNoIGNvbmZ1 c2lvbiBpcyB0aGF0LCBleGNlcHQgZm9yIHBvaW50IDYgYWJvdmUsDQp0aGUg c3RhbmRhcmQgbmV2ZXIgc2F5cyB3aGF0IGlzIHN1cHBvc2VkIHRvIGhhcHBl biBuZXh0IHdoZW4gYSByZXNwb25zZQ0KdmFsdWUgb2YgUmVqZWN0IGlzIHVz ZWQhDQoNClRoZXJlIGFyZSBhdCBsZWFzdCB0aGUgZm9sbG93aW5nIHRocmVl IGludGVycHJldGF0aW9uczoNCg0KICAgIDEuICBCb3RoIHNpZGVzIHVzZSB0 aGUgdmFsdWUgb2YgdGhlIGtleSBpbiBlZmZlY3QgYmVmb3JlIHRoZSBvZmZl cg0KICAgICAgICBhbmQgY29udGludWUgd2l0aCBuZWdvdGlhdGlvbnMgYXMg aWYgbm90aGluZyBoYWQgaGFwcGVuZWQsDQogICAgICAgIGFsdGhvdWdoIHRo aXMgcGFydGljdWxhciBrZXkgY2Fubm90IGJlIG9mZmVyZWQgYWdhaW4gaW4g dGhpcw0KICAgICAgICBuZWdvdGlhdGlvbiBzZXF1ZW5jZSAodGhhdCBpcyBl eHBsaWNpdCkuDQoNCiAgICAyLiAgVHJlYXQgdGhlIG5lZ290aWF0aW9uIGFz IGEgZmFpbHVyZSBhbmQgdGFrZSBhcHByb3ByaWF0ZSBhY3Rpb24uDQogICAg ICAgIER1cmluZyBsb2dpbiwgYXBwcm9wcmlhdGUgYWN0aW9uIGlzIHRvIGNs b3NlIHRoZSBjb25uZWN0aW9uLg0KICAgICAgICBEdXJpbmcgdGV4dCBuZWdv dGlhdGlvbiBkdXJpbmcgRkZQLCBhcHByb3ByaWF0ZSBhY3Rpb24gaXMNCiAg ICAgICAgdG8gaWdub3JlIGFsbCB0aGUgbmVnb3RpYXRpb25zIGluIHRoaXMg c2VxdWVuY2Ugb2YgdGV4dCByZXF1ZXN0DQogICAgICAgIHRleHQgcmVzcG9u c2UgZXhjaGFuZ2VzLg0KDQogICAgMy4gIElmIHBvc3NpYmxlLCB1c2UgdGhl IHZhbHVlIG9mIHRoZSBrZXkgaW4gZWZmZWN0IGJlZm9yZSB0aGUNCiAgICAg ICAgb2ZmZXIgKGFuZCBjb250aW51ZSBhcyBpbiBwb2ludCAxKS4gIElmIG5v dCBwb3NzaWJsZSwgdHJlYXQNCiAgICAgICAgdGhlIG5lZ290aWF0aW9uIGFz IGEgZmFpbHVyZSAoYW5kIHRha2UgYXBwcm9wcmlhdGUgYWN0aW9uLA0KICAg ICAgICBhcyBpbiBwb2ludCAyKS4NCg0KUGVyaGFwcyB0aGlzIHZhZ3VlbmVz cyBpcyBpbnRlbnRpb25hbCwgYW5kIGFsbCBpbnRlcnByZXRhdGlvbnMgYXJl DQphbGxvd2VkLiAgSG93ZXZlciwgSSBiZWxpZXZlIGl0IHdvdWxkIHJlbW92 ZSBhIGxvdCBvZiBjb25mdXNpb24NCmlmIHRoZSBzdGFuZGFyZCBzYWlkIHNv bWV0aGluZyBhYm91dCB3aGF0IHRvIGRvIG5leHQhDQoNCkNvbW1lbnRzPw0K ---1316728197-958788825-1027455575=:8917-- From owner-ips@ece.cmu.edu Wed Jul 24 08:12:51 2002 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA03871 for ; Wed, 24 Jul 2002 08:12:51 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id g6O5eFA20347 for ips-outgoing; Wed, 24 Jul 2002 01:40:15 -0400 (EDT) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from hotmail.com (f57.pav2.hotmail.com [64.4.37.57]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id g6O5eDo20342 for ; Wed, 24 Jul 2002 01:40:14 -0400 (EDT) Received: from mail pickup service by hotmail.com with Microsoft SMTPSVC; Tue, 23 Jul 2002 22:40:08 -0700 Received: from 64.38.134.99 by pv2fd.pav2.hotmail.msn.com with HTTP; Wed, 24 Jul 2002 05:40:07 GMT X-Originating-IP: [64.38.134.99] From: "Bernard Aboba" To: ips@ece.cmu.edu Subject: Security-14 strawman Date: Tue, 23 Jul 2002 22:40:07 -0700 Mime-Version: 1.0 Content-Type: text/plain; format=flowed Message-ID: X-OriginalArrivalTime: 24 Jul 2002 05:40:08.0297 (UTC) FILETIME=[91F47D90:01C232D4] Sender: owner-ips@ece.cmu.edu Precedence: bulk Find below a pointer to a strawman version of the -14 strawman security draft: http://www.drizzle.com/~aboba/IPS/draft-ietf-ips-security-14.txt _________________________________________________________________ Chat with friends online, try MSN Messenger: http://messenger.msn.com From owner-ips@ece.cmu.edu Wed Jul 24 10:59:01 2002 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA20353 for ; Wed, 24 Jul 2002 10:59:01 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id g6OEJYr21039 for ips-outgoing; Wed, 24 Jul 2002 10:19:34 -0400 (EDT) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from cisco.com (cypher.cisco.com [171.69.11.143]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id g6OEJWo21035 for ; Wed, 24 Jul 2002 10:19:32 -0400 (EDT) Received: (from kzm@localhost) by cisco.com (8.8.8/2.6/Cisco List Logging/8.8.8) id HAA22581; Wed, 24 Jul 2002 07:19:25 -0700 (PDT) From: Keith McCloghrie Message-Id: <200207241419.HAA22581@cisco.com> Subject: Re: FC Mgmt mib - buffer credit objects To: arvindp@cisco.com (Arvind Prabhudev) Date: Wed, 24 Jul 2002 07:19:25 -0700 (PDT) Cc: ips@ece.cmu.edu, arvindp@cisco.com (Arvind Prabhudev), mspiegel@cisco.com (Mickey Spiegel) In-Reply-To: from "Arvind Prabhudev" at Jul 19, 2002 12:08:00 PM X-Mailer: ELM [version 2.5 PL1] MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ips@ece.cmu.edu Precedence: bulk Content-Transfer-Encoding: 7bit Arvind, Your suggestion is fine with me, and I haven't seen anybody else object. So, I propose that we accept it. Keith. > Hello Keith, > > Fibre Channel Management MIB: draft-ietf-ips-fcmgmt-mib-02 > > I had a comment about fcmFLoginBbCredit & fcmISPortClassFCredit objects. > Since, it is possible to have an implementation where the buffer credit is > configurable, I would suggest that we make these 2 objects read-write now > rather than having to deprecate these and create new objects in the > future. We could add a MIN-ACCESS clause of read-only for both these > objects. > > thanks, > Arvind > > From owner-ips@ece.cmu.edu Wed Jul 24 12:15:56 2002 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA22640 for ; Wed, 24 Jul 2002 12:15:50 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id g6OFe4g26010 for ips-outgoing; Wed, 24 Jul 2002 11:40:04 -0400 (EDT) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from d12lmsgate.de.ibm.com (d12lmsgate.de.ibm.com [195.212.91.199]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id g6OFe2o26005 for ; Wed, 24 Jul 2002 11:40:02 -0400 (EDT) Received: from d12relay01.de.ibm.com (d12relay01.de.ibm.com [9.165.215.22]) by d12lmsgate.de.ibm.com (8.12.3/8.12.3) with ESMTP id g6OFdsfh045062 for ; Wed, 24 Jul 2002 17:39:55 +0200 Received: from d10hubm1.telaviv.ibm.com (d10ml001.telaviv.ibm.com [9.148.216.55]) by d12relay01.de.ibm.com (8.11.1m3/NCO/VER6.2) with ESMTP id g6OFdtY54402 for ; Wed, 24 Jul 2002 17:39:55 +0200 To: ips@ece.cmu.edu Importance: High MIME-Version: 1.0 Subject: almost done X-Mailer: Lotus Notes Release 5.0.9 November 16, 2001 From: "Julian Satran" Message-ID: Date: Wed, 24 Jul 2002 18:39:49 +0300 X-MIMETrack: Serialize by Router on D10ML001/10/M/IBM(Release 5.0.9a |January 7, 2002) at 24/07/2002 18:39:55, Serialize complete at 24/07/2002 18:39:55 Content-Type: multipart/alternative; boundary="=_alternative 0046F5BDC2256C00_=" Sender: owner-ips@ece.cmu.edu Precedence: bulk This is a multipart message in MIME format. --=_alternative 0046F5BDC2256C00_= Content-Type: text/plain; charset="us-ascii" Dear colleagues, The "working" version 15 is almost ready to be shipped. It includes AFAIK answer to all concerns expressed (as outlined in the list on my site). Please comment if you think that the solution to an issue raised does not express the consensus reached. The working draft and list of issues can be found at: http://www.haifa.il.ibm.com/satran/ips Julo --=_alternative 0046F5BDC2256C00_= Content-Type: text/html; charset="us-ascii"
Dear colleagues,

The "working" version 15 is almost ready to be shipped.
It includes AFAIK answer to all concerns expressed (as outlined in the list on my site).

Please comment if you think that the solution to an issue raised does not express the
consensus reached.

The working draft and list of issues can be found at:

http://www.haifa.il.ibm.com/satran/ips

Julo --=_alternative 0046F5BDC2256C00_=-- From owner-ips@ece.cmu.edu Wed Jul 24 12:19:46 2002 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA22780 for ; Wed, 24 Jul 2002 12:19:46 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id g6OGALm28119 for ips-outgoing; Wed, 24 Jul 2002 12:10:21 -0400 (EDT) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from imail.atlp.com ([64.94.220.137]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id g6OG5Io27741 for ; Wed, 24 Jul 2002 12:05:18 -0400 (EDT) Received: from atlp.com (post.atlp.com [192.168.3.8]) by imail.atlp.com (Switch-2.1.4/Switch-2.1.0) with SMTP id g6OG2SI21609 for ; Wed, 24 Jul 2002 09:02:29 -0700 (PDT) Received: from atlp-exch.atlp.com by atlp.com (SMI-8.6/SMI-SVR4) id JAA16690; Wed, 24 Jul 2002 09:05:04 -0700 Received: by atlp-exch.atlp.com with Internet Mail Service (5.5.2653.19) id <3ZH0CSGB>; Wed, 24 Jul 2002 09:05:03 -0700 Message-ID: <7C769A0EFE7BD411B8A300508BAED11B513699@atlp-exch.atlp.com> From: Mike Donohoe To: "'ips@ece.cmu.edu'" Subject: iSCSI: SCSI command error Date: Wed, 24 Jul 2002 09:05:01 -0700 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-ips@ece.cmu.edu Precedence: bulk > Let's say a target has a 4MB buffer to hold scsi data. > > If the initiator sends a scsi command with ExpectedDataLength of 4MB+1, > what is the expected response of the target?????????? > > 1. Send a Reject PDU. > > 2. Send a Scsi response with Status=2 and a revelant sense code error:4h > 44h 0h (Internal Target failure). > > 3. Send a Scsi response with Response=1. > > Must the Reject or Scsi response wait until the initiator has send all > their data for each of these possibilities???????? > > Thanks. > > From owner-ips@ece.cmu.edu Wed Jul 24 14:29:14 2002 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA26759 for ; Wed, 24 Jul 2002 14:29:14 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id g6OHo7A04662 for ips-outgoing; Wed, 24 Jul 2002 13:50:07 -0400 (EDT) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from lion.ninthwonder.com (lion.ninthwonder.com [151.199.66.147]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id g6OHo4o04655 for ; Wed, 24 Jul 2002 13:50:04 -0400 (EDT) Received: by lion.ninthwonder.com (Postfix, from userid 1021) id 35A7230706; Wed, 24 Jul 2002 13:50:04 -0400 (EDT) Date: Wed, 24 Jul 2002 10:46:45 -0700 (PDT) From: Bill Studenmund X-X-Sender: To: Mike Donohoe Cc: "'ips@ece.cmu.edu'" Subject: Re: iSCSI: SCSI command error In-Reply-To: <7C769A0EFE7BD411B8A300508BAED11B513699@atlp-exch.atlp.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ips@ece.cmu.edu Precedence: bulk On Wed, 24 Jul 2002, Mike Donohoe wrote: > > Let's say a target has a 4MB buffer to hold scsi data. > > > > If the initiator sends a scsi command with ExpectedDataLength of 4MB+1, > > what is the expected response of the target?????????? > > > > 1. Send a Reject PDU. > > > > 2. Send a Scsi response with Status=2 and a revelant sense code error:4h > > 44h 0h (Internal Target failure). > > > > 3. Send a Scsi response with Response=1. I'll let the list say what's best for this. Another option is, if you're working with disks, to cheat and just not need to have more than 4 MB worth in your buffers at once. Remember the target controls how much/fast the initiator sends data, since the target sends R2Ts. By controling FirstBurstSize and MaxBurstSize, you control how much data you have to immediately buffer. > > Must the Reject or Scsi response wait until the initiator has send all > > their data for each of these possibilities???????? No, you will have negotiated how much data the initiator sends with the command (FirstBurstSize, InitialR2T, and ImmediateData). If InitialR2T is no, then at worst you have to wait FirstBurstSize worth of data. I think you could also immediately send a reject/SCSI Response with error, and just remember the ITT. For all future data writes on that ITT, you just black-hole them. You of course clear this black hole when an SCSI command comes in with that ITT. Take care, Bill From owner-ips@ece.cmu.edu Wed Jul 24 16:05:59 2002 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA00396 for ; Wed, 24 Jul 2002 16:05:54 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id g6OJOJ411326 for ips-outgoing; Wed, 24 Jul 2002 15:24:19 -0400 (EDT) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from mail.wrs.com (unknown-1-11.windriver.com [147.11.1.11]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id g6OJOHo11316 for ; Wed, 24 Jul 2002 15:24:17 -0400 (EDT) Received: from london (vpn10-95-10-3.wrsec.fr [10.95.10.3]) by mail.wrs.com (8.9.3/8.9.1) with SMTP id MAA16435 for ; Wed, 24 Jul 2002 12:22:25 -0700 (PDT) From: "Rod Harrison" To: Subject: iSCSI: v15 R2T and DATA-OUT Date: Wed, 24 Jul 2002 14:24:58 -0500 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0) Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2314.1300 Sender: owner-ips@ece.cmu.edu Precedence: bulk Content-Transfer-Encoding: 7bit Folks, There is a potential inconsistency in the description of the use of the LUN field in DATA-OUT and R2T in the working v15 draft. 9.7.3 Target Transfer Tag, for DATA-IN last paragraph says ... "If the Target Transfer Tag is provided, then the LUN field MUST hold a valid value and be consistent with whatever was specified with the command;" 9.8.5 Target Transfer Tag, for R2T says ... "The Target Transfer Tag and LUN are copied in the outgoing data PDUs and are used by the target only." Potentially a target could return a different LUN field in the R2T, for perhaps some funky LUN mapping or other internal reason expecting it to be copied to the DATA-OUT as per the R2T text. I suspect we just want to say this is not allowed and the LUN field MUST be the same as the command PDU. Either way I think we need to indicate what is expected of the initiator if the LUN field in the R2T does not match the LUN in the command PDU. Apologies for not spotting this before the end of last call. - Rod From owner-ips@ece.cmu.edu Wed Jul 24 17:27:43 2002 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA03134 for ; Wed, 24 Jul 2002 17:27:42 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id g6OKiwJ16258 for ips-outgoing; Wed, 24 Jul 2002 16:44:58 -0400 (EDT) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from mxic2.corp.emc.com (mxic2.us.dg.com [128.221.31.40]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id g6OKivo16253 for ; Wed, 24 Jul 2002 16:44:57 -0400 (EDT) Received: by mxic2.corp.emc.com with Internet Mail Service (5.5.2653.19) id ; Wed, 24 Jul 2002 16:44:51 -0400 Message-ID: <277DD60FB639D511AC0400B0D068B71E0564C0D9@CORPMX14> From: Black_David@emc.com To: ips@ece.cmu.edu Subject: FW: I-D ACTION:draft-ietf-ipsec-ciph-aes-ctr-00.txt Date: Wed, 24 Jul 2002 16:42:36 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/mixed; boundary="----_=_NextPart_000_01C23352.A4A84060" Sender: owner-ips@ece.cmu.edu Precedence: bulk This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_000_01C23352.A4A84060 Content-Type: text/plain; charset="iso-8859-1" Here's the AES Counter Mode draft announcement. Please change all references to AES Counter Mode to reference this draft. Thanks, --David -----Original Message----- From: Internet-Drafts@ietf.org [mailto:Internet-Drafts@ietf.org] Sent: Wednesday, July 24, 2002 8:08 AM To: IETF-Announce; @tislabs.com Cc: ipsec@lists.tislabs.com Subject: I-D ACTION:draft-ietf-ipsec-ciph-aes-ctr-00.txt A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the IP Security Protocol Working Group of the IETF. Title : Using AES Counter Mode With IPsec ESP Author(s) : R. Housley Filename : draft-ietf-ipsec-ciph-aes-ctr-00.txt Pages : 12 Date : 23-Jul-02 This document describes the use of AES Counter Mode, with an explicit initialization vector, as an IPsec Encapsulating Security Payload confidentiality mechanism. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-ipsec-ciph-aes-ctr-00.txt To remove yourself from the IETF Announcement list, send a message to ietf-announce-request with the word unsubscribe in the body of the message. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-ipsec-ciph-aes-ctr-00.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-ipsec-ciph-aes-ctr-00.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. ------_=_NextPart_000_01C23352.A4A84060 Content-Type: message/rfc822 To: Subject: Date: Wed, 24 Jul 2002 16:44:51 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/mixed; boundary="----_=_NextPart_002_01C23352.A4A84060" ------_=_NextPart_002_01C23352.A4A84060 Content-Type: text/plain ------_=_NextPart_002_01C23352.A4A84060 Content-Type: application/octet-stream; name="ATT10687" Content-Disposition: attachment; filename="ATT10687" Content-type: message/external-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <20020723145528.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-ipsec-ciph-aes-ctr-00.txt ------_=_NextPart_002_01C23352.A4A84060 Content-Type: message/external-body; site="internet-drafts"; dir="draft-ietf-ipsec-ciph-aes-ctr-00.txt"; mode="ftp.ietf.org"; access-type="anon-ftp" ------_=_NextPart_002_01C23352.A4A84060-- ------_=_NextPart_000_01C23352.A4A84060-- From owner-ips@ece.cmu.edu Wed Jul 24 18:48:05 2002 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA04696 for ; Wed, 24 Jul 2002 18:47:56 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id g6OLxFh20343 for ips-outgoing; Wed, 24 Jul 2002 17:59:15 -0400 (EDT) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from iol.unh.edu (io.iol.unh.edu [132.177.123.82]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id g6OLwko20310 for ; Wed, 24 Jul 2002 17:58:46 -0400 (EDT) Received: from io.iol.unh.edu (localhost.localdomain [127.0.0.1]) by iol.unh.edu (8.12.3/8.12.3) with ESMTP id g6OLwe6U002673 for ; Wed, 24 Jul 2002 17:58:40 -0400 Received: from localhost (rdr@localhost) by io.iol.unh.edu (8.12.3/8.12.3/Submit) with ESMTP id g6OLwe0R002670 for ; Wed, 24 Jul 2002 17:58:40 -0400 Date: Wed, 24 Jul 2002 17:58:40 -0400 (EDT) From: "Robert D. Russell" To: ips@ece.cmu.edu Subject: iSCSI: Use of Reject as a key value Message-ID: MIME-Version: 1.0 Content-Type: MULTIPART/Mixed; BOUNDARY="-1316728197-958788825-1027455575=:8917" Content-ID: Sender: owner-ips@ece.cmu.edu Precedence: bulk This message is in MIME format. The first part should be readable text, while the remaining parts are likely unreadable without MIME-aware tools. Send mail to mime@docserver.cac.washington.edu for more info. ---1316728197-958788825-1027455575=:8917 Content-Type: TEXT/PLAIN; CHARSET=US-ASCII Content-ID: Julian: Attached are 2 ascii text files. The first, reject_extracts.txt, contains all the pieces of draft 14 (the latest available txt version of the drafts) that say anything about the use of Reject as a key value. (At least all those I could find using simple search -- unfortunately, Reject is also the name of a PDU and hence it is not a simple mechanical process to distinguish the two uses! If I missed some, please let me know.) The second, reject_comments.txt, are my comments on these excerpts from the standard. It seems to me that the key thing missing in the standard is a general statement about "what to do next" if a key=Reject response is received. Except for the OFMarkInt and IFMarkInt keys, I could find no other statement about how to proceed after receiving the key=Reject response. In looking through the e-mails posted to the list for June and July, I also could find nothing, although many people seem to be taking the third of the 3 interpretations I listed in reject_comments.txt. I am requesting a clear statement somewhere in the standard that says "what to do next" upon receiving a key=Reject response. Thank you for your consideration. Bob Russell InterOperability Lab University of New Hampshire rdr@iol.unh.edu 603-862-3774 ---1316728197-958788825-1027455575=:8917 Content-Type: TEXT/PLAIN; NAME="reject_extracts.txt" Content-ID: Content-Description: Content-Disposition: ATTACHMENT; FILENAME="reject_extracts.txt" Content-Transfer-Encoding: BASE64 DQpBbGwgcmVmZXJlbmNlcyBpbiBkcmFmdCAxNCB0byB1c2Ugb2YgIlJlamVj dCIgYXMgYSBrZXkgdmFsdWUuDQotLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tDQoNCi4uLg0K DQo0LjIgIFRleHQgTW9kZSBOZWdvdGlhdGlvbg0KDQouLi4NCg0KICAgVGhl IGdlbmVyYWwgZm9ybWF0IG9mIHRleHQgbmVnb3RpYXRpb24gaXM6DQoNCiAg ICAgIE9yaWdpbmF0b3ItPiA8a2V5Pj08dmFsdWV4Pg0KICAgICAgUmVzcG9u ZGVyLT4gPGtleT49PHZhbHVleT58Tm90VW5kZXJzdG9vZHxJcnJlbGV2YW50 fFJlamVjdA0KDQogICBUaGUgb3JpZ2luYXRvciBvciBkZWNsYXJlciBjYW4g ZWl0aGVyIGJlIHRoZSBpbml0aWF0b3Igb3IgdGhlIHRhcmdldCANCiAgIGFu ZCB0aGUgcmVzcG9uZGVyIGNhbiBlaXRoZXIgYmUgdGhlIHRhcmdldCBvciBp bml0aWF0b3IsIHJlc3BlYy0NCiAgIHRpdmVseS4gVGFyZ2V0cyBhcmUgbm90 IGxpbWl0ZWQgdG8gcmVzcG9uZCB0byBrZXk9dmFsdWUgcGFpcnMgYXMgDQog ICBvZmZlcmVkIGJ5IHRoZSBpbml0aWF0b3IuIFRoZSB0YXJnZXQgbWF5IG9m ZmVyIGtleT12YWx1ZSBwYWlycyBvZiBpdHMgDQogICBvd24uIA0KDQogICBB bGwgbmVnb3RpYXRpb25zIGFyZSBleHBsaWNpdCAoaS5lLiwgdGhlIHJlc3Vs dCBNVVNUIGJlIGJhc2VkIG9ubHkgb24gDQogICBuZXdseSBleGNoYW5nZWQg b3IgZGVjbGFyZWQgdmFsdWVzKS4gVGhlcmUgYXJlIG5vIGltcGxpY2l0IG9m ZmVycy4gSWYgDQogICBhbiBleHBsaWNpdCBvZmZlciBpcyBub3QgbWFkZSB0 aGVuIGEgcmVwbHkgY2Fubm90IGJlIGV4cGVjdGVkLiBDb24tDQogICBzZXJ2 YXRpdmUgZGVzaWduIHJlcXVpcmVzIGFsc28gdGhhdCBkZWZhdWx0IHZhbHVl cyBzaG91bGQgbm90IGJlIA0KICAgcmVsaWVkIHVwb24gd2hlbiB1c2Ugb2Yg c29tZSBvdGhlciB2YWx1ZSBoYXMgc2VyaW91cyBjb25zZXF1ZW5jZXMuIA0K DQogICBUaGUgdmFsdWUgb2ZmZXJlZCBvciBkZWNsYXJlZCBjYW4gYmUgYSBu dW1lcmljYWwtdmFsdWUsIGEgbnVtZXJpY2FsLQ0KICAgcmFuZ2UgZGVmaW5l ZCBieSBsb3dlciBhbmQgdXBwZXIgdmFsdWUgLSBib3RoIGludGVnZXJzIHNl cGFyYXRlZCBieSANCiAgIHRpbGRlLCBhIGJpbmFyeSB2YWx1ZSwgYSB0ZXh0 LXZhbHVlLCBhIGlTQ1NJLW5hbWUtdmFsdWUsIGFuIGlTQ1NJLQ0KICAgbG9j YWwtbmFtZS12YWx1ZSwgYSBib29sZWFuLXZhbHVlIChZZXMgb3IgTm8pLCBv ciBhIGxpc3Qgb2YgY29tbWEgDQogICBzZXBhcmF0ZWQgdGV4dC12YWx1ZXMu IEEgcmFuZ2Ugb3IgYSBsYXJnZS1udW1lcmljYWwtdmFsdWUgTUFZIE9OTFkg YmUgDQogICBvZmZlcmVkIGlmIGl0IGlzIGV4cGxpY2l0bHkgYWxsb3dlZCBm b3IgYSBrZXkuIEFuIGlTQ1NJLW5hbWUtdmFsdWUgDQogICBhbmQgYW4gaVND U0ktbG9jYWwtbmFtZS12YWx1ZSBjYW4gYmUgdXNlZCBvbmx5IHdoZXJlIGV4 cGxpY2l0bHkgDQogICBhbGxvd2VkLiBBIHNlbGVjdGVkIHZhbHVlIGNhbiBi ZSBhbiBudW1lcmljYWwtdmFsdWUsIGEgbGFyZ2UtbnVtZXJpLQ0KICAgY2Fs LXZhbHVlLCBhIHRleHQtdmFsdWUgb3IgYSBib29sZWFuLXZhbHVlLg0KDQog ICBJZiBhIHNwZWNpZmljIGtleSBpcyBub3QgcmVsZXZhbnQgZm9yIHRoZSBj dXJyZW50IG5lZ290aWF0aW9uLCB0aGUgDQogICByZXNwb25kZXIgbWF5IGFu c3dlciB3aXRoIHRoZSBjb25zdGFudCAiSXJyZWxldmFudCIgZm9yIGFsbCB0 eXBlcyBvZiANCiAgIG5lZ290aWF0aW9uLiBIb3dldmVyIHRoZSBuZWdvdGlh dGlvbiBpcyBub3QgY29uc2lkZXJlZCBhcyBmYWlsZWQgaWYgDQogICB0aGUg cmVzcG9uc2UgaXMgIklycmVsZXZhbnQiLg0KDQogICBBbnkga2V5IG5vdCB1 bmRlcnN0b29kIGJ5IHRoZSByZXNwb25kZXIgbWF5IGJlIGlnbm9yZWQgYnkg dGhlIA0KICAgcmVzcG9uZGVyIHdpdGhvdXQgYWZmZWN0aW5nIHRoZSBiYXNp YyBmdW5jdGlvbi4gSG93ZXZlciwgdGhlIFRleHQgDQogICBSZXNwb25zZSBm b3IgYSBrZXkgbm90IHVuZGVyc3Rvb2QgTVVTVCBiZSBrZXk9Tm90VW5kZXJz dG9vZC4NCg0KICAgVGhlIGNvbnN0YW50cyAiTm9uZSIsICJSZWplY3QiLCAi SXJyZWxldmFudCIsIGFuZCAiTm90VW5kZXJzdG9vZCIgYXJlIA0KICAgcmVz ZXJ2ZWQgYW5kIG11c3Qgb25seSBiZSB1c2VkIGFzIGRlc2NyaWJlZCBoZXJl Lg0KDQogICBSZWplY3Qgb3IgSXJyZWxldmFudCBhcmUgbGVnaXRpbWF0ZSBu ZWdvdGlhdGlvbiBvcHRpb25zIHdoZXJlIGFsbG93ZWQgDQogICBidXQgdGhl aXIgZXhjZXNzaXZlIHVzZSBpcyBkaXNjb3VyYWdlZC4gQSBuZWdvdGlhdGlv biBpcyBjb25zaWRlcmVkIA0KICAgY29tcGxldGUgd2hlbiB0aGUgcmVzcG9u ZGVyIGhhcyBzZW50IHRoZSBrZXkgdmFsdWUgcGFpciBldmVuIGlmIHRoZSAN CiAgIHZhbHVlIGlzICJSZWplY3QiLCAiSXJyZWxldmFudCIsIG9yICJOb3RV bmRlcnN0b29kLiBTZW5kaW5nIHRoZSBrZXkgDQogICBhZ2FpbiB3b3VsZCBi ZSBhIHJlLW5lZ290aWF0aW9uDQogICAgDQogICBTb21lIGJhc2ljIGtleT12 YWx1ZSBwYWlycyBhcmUgZGVzY3JpYmVkIGluIENoYXB0ZXIgMTEuIEFsbCBr ZXlzIGluIA0KICAgQ2hhcHRlciAxMSwgZXhjZXB0IGZvciB0aGUgWC0gZXh0 ZW5zaW9uIGZvcm1hdCwgTVVTVCBiZSBzdXBwb3J0ZWQgYnkgDQogICBpU0NT SSBpbml0aWF0b3JzIGFuZCB0YXJnZXRzIGFuZCBNVVNUIE5PVCBiZSBhbnN3 ZXJlZCB3aXRoIE5vdFVuZGVyLQ0KICAgc3Rvb2QuDQogICAgDQouLi4NCg0K DQo0LjIuMSAgTGlzdCBuZWdvdGlhdGlvbnMNCg0KICAgSW4gbGlzdCBuZWdv dGlhdGlvbiwgdGhlIG9yaWdpbmF0b3Igc2VuZHMgYSBsaXN0IG9mIHZhbHVl cyAod2hpY2ggbWF5IA0KICAgaW5jbHVkZSAiTm9uZSIpIGluIGl0cyBvcmRl ciBvZiBwcmVmZXJlbmNlLg0KDQogICBUaGUgcmVzcG9uZGluZyBwYXJ0eSBN VVNUIHJlc3BvbmQgd2l0aCB0aGUgc2FtZSBrZXkgYW5kIHRoZSBmaXJzdCAN CiAgIHZhbHVlIHRoYXQgaXQgc3VwcG9ydHMgKGFuZCBpcyBhbGxvd2VkIHRv IHVzZSBmb3IgdGhlIHNwZWNpZmljIG9yaWdpLQ0KICAgbmF0b3IpIHNlbGVj dGVkIGZyb20gdGhlIG9yaWdpbmF0b3IgbGlzdC4gDQoNCiAgIFRoZSBjb25z dGFudCAiTm9uZSIgTVVTVCBhbHdheXMgYmUgdXNlZCB0byBpbmRpY2F0ZSBh IG1pc3NpbmcgZnVuYy0NCiAgIHRpb24uIEhvd2V2ZXIsIE5vbmUgaXMgYSB2 YWxpZCBzZWxlY3Rpb24gb25seSBpZiBpdCBpcyBleHBsaWNpdGx5IA0KICAg b2ZmZXJlZC4gDQoNCiAgIElmIGEgcmVzcG9uZGVyIGRvZXMgbm90IHVuZGVy c3RhbmQgYW55IHBhcnRpY3VsYXIgdmFsdWUgaW4gYSBsaXN0IGl0IA0KICAg TVVTVCBpZ25vcmUgaXQuIElmIGEgcmVzcG9uZGVyIGRvZXMgc3VwcG9ydCwg dW5kZXJzdGFuZCBvciBpcyBhbGxvd2VkIA0KICAgdG8gdXNlIG5vbmUgb2Yg dGhlIG9mZmVyZWQgb3B0aW9ucyB3aXRoIGEgc3BlY2lmaWMgb3JpZ2luYXRv ciwgaXQgbWF5IA0KICAgdXNlIHRoZSBjb25zdGFudCAiUmVqZWN0IiBvciB0 ZXJtaW5hdGUgdGhlIG5lZ290aWF0aW9uLiBUaGUgc2VsZWMtDQogICB0aW9u IG9mIGEgdmFsdWUgbm90IG9mZmVyZWQgaXMgY29uc2lkZXJlZCBhIG5lZ290 aWF0aW9uIGZhaWx1cmUgYW5kIA0KICAgaXMgaGFuZGxlZCBhcyBhIHByb3Rv Y29sIGVycm9yLiANCg0KNC4yLjIgIFNpbXBsZS12YWx1ZSBuZWdvdGlhdGlv bnMNCg0KICAgRm9yIHNpbXBsZS12YWx1ZSBuZWdvdGlhdGlvbnMsIHRoZSBy ZXNwb25kaW5nIHBhcnR5IE1VU1QgcmVzcG9uZCB3aXRoIA0KICAgdGhlIHNh bWUga2V5LiBUaGUgdmFsdWUgaXQgc2VsZWN0cywgYmFzZWQgb24gdGhlIHNl bGVjdGlvbiBydWxlIHNwZS0NCiAgIGNpZmljIHRvIHRoZSBrZXksIGJlY29t ZXMgdGhlIG5lZ290aWF0aW9uIHJlc3VsdC4gRm9yIGEgbnVtZXJpY2FsIA0K ICAgcmFuZ2UgdGhlIHZhbHVlIHNlbGVjdGVkIG11c3QgYmUgYW4gaW50ZWdl ciB3aXRoaW4gdGhlIG9mZmVyZWQgcmFuZ2UgDQogICBvciAiUmVqZWN0IiAo aWYgdGhlIHJhbmdlIGlzIHVuYWNjZXB0YWJsZSkuIEFuIG9mZmVyIG9mIGEg dmFsdWUgbm90IA0KICAgYWRtaXNzaWJsZSAoZS5nLiwgbm90IHdpdGhpbiB0 aGUgc3BlY2lmaWVkIGJvdW5kcykgTUFZIGJlIGFuc3dlcmVkIA0KICAgd2l0 aCB0aGUgY29uc3RhbnQgIlJlamVjdCIgb3IgdGhlIHJlc3BvbmRlciBNQVkg c2VsZWN0IGFuIGFkbWlzc2libGUgDQogICB2YWx1ZS4gVGhlIHNlbGVjdGlv biwgYnkgdGhlIHJlc3BvbmRlciwgb2YgYSB2YWx1ZSBub3QgYWRtaXNzaWJs ZSANCiAgIHVuZGVyIHRoZSBzZWxlY3Rpb24gcnVsZXMgaXMgY29uc2lkZXJl ZCBhIG5lZ290aWF0aW9uIGZhaWx1cmUgYW5kIGlzIA0KICAgaGFuZGxlZCBh Y2NvcmRpbmdseS4gVGhlIHNlbGVjdGlvbiBydWxlcyBhcmUga2V5LXNwZWNp ZmljLiANCg0KLi4uDQoNCg0KNC4zICBMb2dpbiBQaGFzZQ0KDQouLi4NCg0K ICAgTmVpdGhlciB0aGUgaW5pdGlhdG9yIG5vciB0aGUgdGFyZ2V0IHNob3Vs ZCBhdHRlbXB0IHRvIGRlY2xhcmUgb3IgDQogICBuZWdvdGlhdGUgYSBwYXJh bWV0ZXIgbW9yZSB0aGFuIG9uY2UgZHVyaW5nIGxvZ2luIGV4Y2VwdCBmb3Ig DQogICByZXNwb25zZXMgdG8gc3BlY2lmaWMga2V5cyB0aGF0IGV4cGxpY2l0 bHkgYWxsb3cgcmVwZWF0ZWQga2V5IGRlY2xhLQ0KICAgcmF0aW9ucyAoZS5n LiBUYXJnZXRBZGRyZXNzKS4gSWYgZGV0ZWN0ZWQgYnkgdGhlIHRhcmdldCB0 aGlzIE1VU1QgDQogICByZXN1bHQgaW4gYSBMb2dpbiByZWplY3QgKGluaXRp YXRvciBlcnJvcikuIFRoZSBpbml0aWF0b3IgTVVTVCBkcm9wIA0KICAgdGhl IGNvbm5lY3Rpb24NCiAgICANCg0KLi4uDQoNCjQuMy4yICBpU0NTSSBTZWN1 cml0eSBOZWdvdGlhdGlvbg0KDQogICBUaGUgc2VjdXJpdHkgZXhjaGFuZ2Ug c2V0cyB0aGUgc2VjdXJpdHkgbWVjaGFuaXNtIGFuZCBhdXRoZW50aWNhdGVz DQogICB0aGUgaW5pdGlhdG9yIHVzZXIgYW5kIHRoZSB0YXJnZXQgdG8gZWFj aCBvdGhlci4gVGhlIGV4Y2hhbmdlIHByby0NCiAgIGNlZWRzIGFjY29yZGlu ZyB0byB0aGUgYXV0aGVudGljYXRpb24gbWV0aG9kIGNob3NlbiBpbiB0aGUg bmVnb3RpYS0NCiAgIHRpb24gcGhhc2UgYW5kIGlzIGNvbmR1Y3RlZCB1c2lu ZyB0aGUgbG9naW4gcmVxdWVzdHMnIGFuZCByZXNwb25zZXMnIA0KICAga2V5 PXZhbHVlIHBhcmFtZXRlcnMuDQoNCiAgIEFuIGluaXRpYXRvciBkaXJlY3Rl ZCBuZWdvdGlhdGlvbiBwcm9jZWVkcyBhcyBmb2xsb3dzOg0KDQogICAgIC1U aGUgaW5pdGlhdG9yIHNlbmRzIGEgbG9naW4gcmVxdWVzdCB3aXRoIGFuIG9y ZGVyZWQgbGlzdCBvZiANCiAgICAgICB0aGUgb3B0aW9ucyBpdCBzdXBwb3J0 cyAoYXV0aGVudGljYXRpb24gYWxnb3JpdGhtKS4gVGhlIA0KICAgICAgIG9w dGlvbnMgYXJlIGxpc3RlZCBpbiB0aGUgaW5pdGlhdG9yJ3Mgb3JkZXIgb2Yg cHJlZmVyZW5jZS4gDQogICAgICAgVGhlIGluaXRpYXRvciBNQVkgYWxzbyBz ZW5kIHByb3ByaWV0YXJ5IG9wdGlvbnMuIA0KICAgICAtVGhlIHRhcmdldCBN VVNUIHJlcGx5IHdpdGggdGhlIGZpcnN0IG9wdGlvbiBpbiB0aGUgbGlzdCBp dCANCiAgICAgICBzdXBwb3J0cyBhbmQgaXMgYWxsb3dlZCB0byB1c2UgZm9y IHRoZSBzcGVjaWZpYyBpbml0aWF0b3IgDQogICAgICAgdW5sZXNzIGl0IGRv ZXMgbm90IHN1cHBvcnQgYW55IGluIHdoaWNoIGNhc2UgaXQgTVVTVCBhbnN3 ZXIgDQogICAgICAgd2l0aCAiUmVqZWN0IiAoc2VlIGFsc28gU2VjdGlvbiA0 LjIgVGV4dCBNb2RlIE5lZ290aWF0aW9uKS4gDQogICAgICAgVGhlIHBhcmFt ZXRlcnMgYXJlIGVuY29kZWQgaW4gVVRGOCBhcyBrZXk9dmFsdWUuIEZvciBz ZWN1LQ0KICAgICAgIHJpdHkgcGFyYW1ldGVycywgc2VlIENoYXB0ZXIgMTAu DQoNCi4uLg0KDQpBLjMuMiAgIE9GTWFya0ludCwgSUZNYXJrSW50DQoNCiAg IFVzZTogSU8NCiAgIFNlbmRlcnM6IEluaXRpYXRvciBhbmQgVGFyZ2V0DQog ICBTY29wZTogQ08NCg0KICAgT2ZmZXJpbmc6DQoNCiAgIE9GTWFya0ludD08 bnVtZXJpYy1yYW5nZS1mcm9tLTEtdG8tNjU1MzU+IA0KICAgSUZNYXJrSW50 PTxudW1lcmljLXJhbmdlLWZyb20tMS10by02NTUzNT4NCg0KICAgUmVzcG9u ZGluZzoNCg0KICAgT0ZNYXJrSW50PTxudW1lcmljLXZhbHVlLWZyb20tMS10 by02NTUzNT58UmVqZWN0DQogICBJRk1hcmtJbnQ9PG51bWVyaWMtdmFsdWUt ZnJvbS0xLXRvLTY1NTM1PnxSZWplY3QNCg0KICAgT0ZNYXJrSW50IGlzIHVz ZWQgdG8gc2V0IHRoZSBpbnRlcnZhbCBmb3IgdGhlIGluaXRpYXRvciB0byB0 YXJnZXQgDQogICBtYXJrZXJzIG9uIHRoZSBjb25uZWN0aW9uLiAgSUZNYXJr SW50IGlzIHVzZWQgdG8gc2V0IHRoZSBpbnRlcnZhbCBmb3IgDQogICB0aGUg dGFyZ2V0IHRvIGluaXRpYXRvciBtYXJrZXJzIG9uIHRoZSBjb25uZWN0aW9u Lg0KDQogICBGb3IgdGhlIG9mZmVyaW5nIHRoZSBpbml0aWF0b3Igb3IgdGFy Z2V0IGluZGljYXRlcyB0aGUgbWluaW11bSB0byANCiAgIG1heGltdW0gaW50 ZXJ2YWwgKGluIDQtYnl0ZSB3b3JkcykgaXQgd2FudHMgdGhlIG1hcmtlcnMg Zm9yIG9uZSBvciANCiAgIGJvdGggZGlyZWN0aW9ucy4gSW4gY2FzZSBpdCBv bmx5IHdhbnRzIGEgc3BlY2lmaWMgdmFsdWUsIG9ubHkgYSBzaW4tDQogICBn bGUgdmFsdWUgaGFzIHRvIGJlIHNwZWNpZmllZC4gVGhlIHJlc3BvbmRlciBz ZWxlY3RzIGEgdmFsdWUgd2l0aGluIA0KICAgdGhlIG1pbmltdW0gYW5kIG1h eGltdW0gb2ZmZXJlZCBvciB0aGUgb25seSB2YWx1ZSBvZmZlcmVkIG9yIGlu ZGktDQogICBjYXRlcyB0aHJvdWdoIHRoZSB4Rk1hcmtlciBrZXk9dmFsdWUg aXRzIGluYWJpbGl0eSB0byBzZXQgYW5kL29yIA0KICAgcmVjZWl2ZSBtYXJr ZXJzLiBXaGVuIHRoZSBpbnRlcnZhbCBpcyB1bmFjY2VwdGFibGUgdGhlIHJl c3BvbmRlciANCiAgIGFuc3dlcnMgd2l0aCAiUmVqZWN0Ii4gIFJlamVjdCBp cyByZXNldHRpbmcgdGhlIG1hcmtlciBmdW5jdGlvbiBpbiANCiAgIHRoZSBz cGVjaWZpZWQgZGlyZWN0aW9uIChPdXRwdXQgb3IgSW5wdXQpIHRvIE5vLg0K DQouLi4NCg== ---1316728197-958788825-1027455575=:8917 Content-Type: TEXT/PLAIN; NAME="reject_comments.txt" Content-ID: Content-Description: Content-Disposition: ATTACHMENT; FILENAME="reject_comments.txt" Content-Transfer-Encoding: BASE64 Q29tbWVudHMgb24gdGhlIHVzZSBvZiAiUmVqZWN0IiBhcyBhIGtleSB2YWx1 ZS4NCg0KSW4gc2VjdGlvbiA0LjIsIHRoZSAiZ2VuZXJhbCBmb3JtYXQgb2Yg dGV4dCBuZWdvdGlhdGlvbiIgY2xlYXJseSBhbGxvd3MNCmJvdGggaW5pdGlh dG9yIGFuZCB0YXJnZXQgdG8gc2VuZCBhbmQgcmVjZWl2ZSBhICJSZWplY3Qi IHZhbHVlLg0KDQpIb3dldmVyLCB0aGlzICJnZW5lcmFsIGZvcm1hdCIgZG9l cyBub3QgbmVjZXNzYXJpbHkgaW1wbHkgdGhhdCBpdCBpcw0KbGVnYWwgdG8g c2VuZCBhICJSZWplY3QiIHZhbHVlIGF0IGFueSB0aW1lIGFuZCBmb3IgYW55 IGtleSENCg0KTGF0ZXIgaW4gdGhlIHNhbWUgc2VjdGlvbiA0LjIgaXQgc2F5 czoNCg0KICAgICJSZWplY3Qgb3IgSXJyZWxldmFudCBhcmUgbGVnaXRpbWF0 ZSBuZWdvdGlhdGlvbiBvcHRpb25zIHdoZXJlDQogICAgYWxsb3dlZCBidXQg Li4uIi4NCg0KVGhpcyBjb3VsZCBiZSByZWFkIHRvIGltcGx5IHRoYXQgZnVy dGhlciBleHBsYW5hdGlvbnMgbXVzdCBiZSBnaXZlbiB0bw0KaW5kaWNhdGUg d2hlcmUgUmVqZWN0IChJcnJlbGV2YW50KSBpcyBhbGxvd2VkLiAgSW4gZmFj dCwgdGhlIHN0YW5kYXJkIA0KZXhwbGljaXRseSBsaXN0cyB0aGUgZm9sbG93 aW5nIHNwZWNpZmljIHNpdHVhdGlvbnMgd2hlcmUgUmVqZWN0IGlzIGFsbG93 ZWQuDQoNCiAgICAxLiAgSW4gc2VjdGlvbiA0LjIuMSwgTGlzdCBuZWdvdGlh dGlvbnMsIGl0IHNheXM6DQogICAgICAgIA0KICAgICAgICAiSWYgYSByZXNw b25kZXIgZG9lcyBzdXBwb3J0LCB1bmRlcnN0YW5kIG9yIGlzIGFsbG93ZWQg dG8gdXNlDQogICAgICAgIG5vbmUgb2YgdGhlIG9mZmVyZWQgb3B0aW9ucyB3 aXRoIGEgc3BlY2lmaWMgb3JpZ2luYXRvciwgaXQgbWF5DQogICAgICAgIHVz ZSB0aGUgY29uc3RhbnQgIlJlamVjdCIgb3IgdGVybWluYXRlIHRoZSBuZWdv dGlhdGlvbi4iDQoNCiAgICAgIC0tVGhpcyBjb3VsZCBiZSB1bmRlcnN0b29k IHRvIG1lYW4gdGhhdCAiUmVqZWN0IiBkb2VzIE5PVCB0ZXJtaW5hdGUNCiAg ICAgICAgdGhlIG5lZ290aWF0aW9uLiAgSG93ZXZlciwgdGhlIG5leHQgc2Vu dGVuY2UgaW4gdGhlIHN0YW5kYXJkIHNheXM6DQoNCiAgICAgICAgIlRoZSBz ZWxlY3Rpb24gb2YgYSB2YWx1ZSBub3Qgb2ZmZXJlZCBpcyBjb25zaWRlcmVk IGEgbmVnb3RpYXRpb24NCiAgICAgICAgZmFpbHVyZSBhbmQgaXMgaGFuZGxl ZCBhcyBhIHByb3RvY29sIGVycm9yLiINCg0KICAgICAgLS1DbGVhcmx5ICJS ZWplY3QiIHdhcyBub3Qgb2ZmZXJlZCwgc28gaWYgaXQgYXBwZWFycyBpbiB0 aGUNCiAgICAgICAgcmVzcG9uc2UsIHRoaXMgc2VudGVuY2UgY291bGQgYmUg dW5kZXJzdG9vZCB0byBtZWFuIHRoYXQgdGhlDQogICAgICAgIG5lZ290aWF0 aW9uIGZhaWxlZC4NCg0KDQogICAgMi4gIEluIHNlY3Rpb24gNC4yLjIsIFNp bXBsZS12YWx1ZSBuZWdvdGlhdGlvbnMsIGl0IHNheXM6DQoNCiAgICAgICAg IkZvciBhIG51bWVyaWNhbCByYW5nZSB0aGUgdmFsdWUgc2VsZWN0ZWQgbXVz dCBiZSBhbiBpbnRlZ2VyDQogICAgICAgIHdpdGhpbmcgdGhlIG9mZmVyZWQg cmFuZ2Ugb3IgIlJlamVjdCIgKGlmIHRoZSByYW5nZSBpcw0KICAgICAgICB1 bmFjY2VwdGFibGUpLiINCg0KICAgICAgLS1UaGlzIGV4cGxpY2l0bHkgYWxs b3dzIFJlamVjdCBhcyBhIHJlc3BvbnNlIGZvciBudW1lcmljYWwgcmFuZ2UN CiAgICAgICAgcGFyYW1ldGVycyAob2Ygd2hpY2ggdGhlcmUgYXJlIG9ubHkg dHdvOiBPRk1hcmtJbnQgYW5kIElGTWFya0ludCksDQogICAgICAgIGJ1dCBk b2Vzbid0IHNheSB3aGF0IHRvIGRvIG5leHQgaWYgUmVqZWN0IGlzIHVzZWQu ICBIb3dldmVyLA0KICAgICAgICBzZWN0aW9uIEEuMy4yIGRvZXMgc2F5IHdo YXQgdG8gZG8gZm9yIHRoZSBPRk1hcmtJbnQgYW5kIElGTWFya0ludA0KICAg ICAgICBrZXlzIChzZWUgYmVsb3cpLg0KDQoNCiAgICAzLiAgQWxzbyBpbiBz ZWN0aW9uIDQuMi4yLCBTaW1wbGUtdmFsdWUgbmVnb3RpYXRpb25zLCBpdCBz YXlzOg0KDQogICAgICAgICJBbiBvZmZlciBvZiBhIHZhbHVlIG5vdCBhZG1p c3NpYmxlIChlLmUuLCBub3Qgd2l0aGluIHRoZSBzcGVjaWZpZWQNCiAgICAg ICAgYm91bmRzKSBNQVkgYmUgYW5zd2VyZWQgd2l0aCB0aGUgY29uc3RhbnQg IlJlamVjdCIgb3IgdGhlIHJlc3BvbmRlcg0KICAgICAgICBNQVkgc2VsZWN0 IGFuIGFkbWlzc2libGUgdmFsdWUuIg0KDQogICAgICAtLVRoaXMgZXhwbGlj aXRseSBhbGxvd3MgUmVqZWN0IGFzIGEgcmVzcG9uc2UgZm9yIG90aGVyIHNp bXBsZS12YWx1ZQ0KICAgICAgICB0eXBlcyAoa2V5cyBleHBlY3RpbmcgbnVt ZXJpY2FsIHZhbHVlcywgYm9vbGVhbiB2YWx1ZXMsIGV0Yy4pLA0KICAgICAg ICBidXQgYWdhaW4gZG9lc24ndCBzYXkgd2hhdCB0byBkbyBuZXh0IGlmIFJl amVjdCBpcyB1c2VkLg0KDQoNCiAgICA0LiAgSW4gc2VjdGlvbiA0LjMuMiwg aVNDU0kgU2VjdXJpdHkgTmVnb3RpYXRpb24sIGl0IHNheXM6DQoNCiAgICAg ICAgIi1UaGUgdGFyZ2V0IE1VU1QgcmVwbHkgd2l0aCB0aGUgZmlyc3Qgb3B0 aW9uIGluIHRoZSBsaXN0IGl0DQogICAgICAgIHN1cHBvcnRzIGFuZCBpcyBh bGxvd2VkIHRvIHVzZSBmb3IgdGhlIHNwZWNpZmljIGluaXRpYXRvcg0KICAg ICAgICB1bmxlc3MgaXQgZG9lcyBub3Qgc3VwcG9ydCBhbnkgaW4gd2hpY2gg Y2FzZSBpdCBNVVNUIGFuc3dlcg0KICAgICAgICB3aXRoICJSZWplY3QiIChz ZWUgYWxzbyBTZWN0aW9uIDQuMiBUZXh0IE1vZGUgTmVnb3RpYXRpb24pLiIN Cg0KICAgICAgLS1PaywgYnV0IHRoZW4gd2hhdCBoYXBwZW5zIG5leHQgLS0g aGFzIHRoZSBuZWdvdGlhdGlvbiBmYWlsZWQ/DQogICAgICAgIElmIG5vdCwg d2hhdCB2YWx1ZSBpcyB1c2VkIGZvciB0aGUgcmVqZWN0ZWQga2V5IC0tIHRo ZSB2YWx1ZQ0KICAgICAgICBpbiBlZmZlY3QgcHJpb3IgdG8gdGhpcyBvZmZl ci9yZXNwb25zZSBleGNoYW5nZT8gIFRoZSBzdGFuZGFyZA0KICAgICAgICBu ZXZlciBzYXlzLg0KDQoNCiAgICA1LiAgSW4gc2VjdGlvbiBBLjMuMiwgT0ZN YXJrSW50LCBJRk1hcmtJbnQsIGl0IHNheXM6DQoNCiAgICAgICAgIlJlc3Bv bmRpbmc6DQogICAgICAgIE9GTWFya0ludD08bnVtZXJpYy1yYW5nZS1mcm9t LTEtdG8tNjU1MzU+fFJlamVjdA0KICAgICAgICBJRk1hcmtJbnQ9PG51bWVy aWMtcmFuZ2UtZnJvbS0xLXRvLTY1NTM1PnxSZWplY3QiDQoNCiAgICAgIC0t VGhpcyBpcyB0aGUgb25seSBpbnN0YW5jZSB3aGVyZSBSZWplY3QgaXMgZXhw bGljaXRseSBzcGVjaWZpZWQNCiAgICAgICAgYXMgYSB2YWxpZCByZXNwb25z ZSBmb3IgYSBzcGVjaWZpYyBrZXkuDQoNCg0KICAgIDYuICBBbHNvIGluIHNl Y3Rpb24gQS4zLjIsIE9GTWFya0ludCwgSUZNYXJrSW50LCBpdCBzYXlzOg0K DQogICAgICAgICJXaGVuIHRoZSBpbnRlcnZhbCBpcyB1bmFjY2VwdGFibGUg dGhlIHJlc3BvbmRlciBhbnN3ZXJzIHdpdGgNCiAgICAgICAgIlJlamVjdCIu ICBSZWplY3QgaXMgcmVzZXR0aW5nIHRoZSBtYXJrZXIgZnVuY3Rpb24gaW4g dGhlDQogICAgICAgIHNwZWNpZmllZCBkaXJlY3Rpb24gKE91dHB1dCBvciBJ bnB1dCkgdG8gTm8uIg0KDQogICAgICAtLVRoaXMgaXMgYWxzbyB0aGUgb25s eSBpbnN0YW5jZSB3aGVyZSB0aGUgc3RhbmRhcmQgc2F5cyB3aGF0IHRvDQog ICAgICAgIGRvIHdoZW4gYSByZXNwb25zZSB2YWx1ZSBvZiBSZWplY3QgaXMg dXNlZC4NCg0KDQpJIGJlbGlldmUgdGhlIHNvdXJjZSBvZiBtdWNoIGNvbmZ1 c2lvbiBpcyB0aGF0LCBleGNlcHQgZm9yIHBvaW50IDYgYWJvdmUsDQp0aGUg c3RhbmRhcmQgbmV2ZXIgc2F5cyB3aGF0IGlzIHN1cHBvc2VkIHRvIGhhcHBl biBuZXh0IHdoZW4gYSByZXNwb25zZQ0KdmFsdWUgb2YgUmVqZWN0IGlzIHVz ZWQhDQoNClRoZXJlIGFyZSBhdCBsZWFzdCB0aGUgZm9sbG93aW5nIHRocmVl IGludGVycHJldGF0aW9uczoNCg0KICAgIDEuICBCb3RoIHNpZGVzIHVzZSB0 aGUgdmFsdWUgb2YgdGhlIGtleSBpbiBlZmZlY3QgYmVmb3JlIHRoZSBvZmZl cg0KICAgICAgICBhbmQgY29udGludWUgd2l0aCBuZWdvdGlhdGlvbnMgYXMg aWYgbm90aGluZyBoYWQgaGFwcGVuZWQsDQogICAgICAgIGFsdGhvdWdoIHRo aXMgcGFydGljdWxhciBrZXkgY2Fubm90IGJlIG9mZmVyZWQgYWdhaW4gaW4g dGhpcw0KICAgICAgICBuZWdvdGlhdGlvbiBzZXF1ZW5jZSAodGhhdCBpcyBl eHBsaWNpdCkuDQoNCiAgICAyLiAgVHJlYXQgdGhlIG5lZ290aWF0aW9uIGFz IGEgZmFpbHVyZSBhbmQgdGFrZSBhcHByb3ByaWF0ZSBhY3Rpb24uDQogICAg ICAgIER1cmluZyBsb2dpbiwgYXBwcm9wcmlhdGUgYWN0aW9uIGlzIHRvIGNs b3NlIHRoZSBjb25uZWN0aW9uLg0KICAgICAgICBEdXJpbmcgdGV4dCBuZWdv dGlhdGlvbiBkdXJpbmcgRkZQLCBhcHByb3ByaWF0ZSBhY3Rpb24gaXMNCiAg ICAgICAgdG8gaWdub3JlIGFsbCB0aGUgbmVnb3RpYXRpb25zIGluIHRoaXMg c2VxdWVuY2Ugb2YgdGV4dCByZXF1ZXN0DQogICAgICAgIHRleHQgcmVzcG9u c2UgZXhjaGFuZ2VzLg0KDQogICAgMy4gIElmIHBvc3NpYmxlLCB1c2UgdGhl IHZhbHVlIG9mIHRoZSBrZXkgaW4gZWZmZWN0IGJlZm9yZSB0aGUNCiAgICAg ICAgb2ZmZXIgKGFuZCBjb250aW51ZSBhcyBpbiBwb2ludCAxKS4gIElmIG5v dCBwb3NzaWJsZSwgdHJlYXQNCiAgICAgICAgdGhlIG5lZ290aWF0aW9uIGFz IGEgZmFpbHVyZSAoYW5kIHRha2UgYXBwcm9wcmlhdGUgYWN0aW9uLA0KICAg ICAgICBhcyBpbiBwb2ludCAyKS4NCg0KUGVyaGFwcyB0aGlzIHZhZ3VlbmVz cyBpcyBpbnRlbnRpb25hbCwgYW5kIGFsbCBpbnRlcnByZXRhdGlvbnMgYXJl DQphbGxvd2VkLiAgSG93ZXZlciwgSSBiZWxpZXZlIGl0IHdvdWxkIHJlbW92 ZSBhIGxvdCBvZiBjb25mdXNpb24NCmlmIHRoZSBzdGFuZGFyZCBzYWlkIHNv bWV0aGluZyBhYm91dCB3aGF0IHRvIGRvIG5leHQhDQoNCkNvbW1lbnRzPw0K ---1316728197-958788825-1027455575=:8917-- From owner-ips@ece.cmu.edu Wed Jul 24 19:57:24 2002 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA06408 for ; Wed, 24 Jul 2002 19:57:19 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id g6ONE7V24220 for ips-outgoing; Wed, 24 Jul 2002 19:14:07 -0400 (EDT) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from mailhub.lss.emc.com (xdch.emc.com [168.159.1.79]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id g6ONE6o24216 for ; Wed, 24 Jul 2002 19:14:06 -0400 (EDT) Received: from emc.com (emcmail.lss.emc.com [168.159.48.78]) by mailhub.lss.emc.com (Switch-2.2.0/Switch-2.2.0) with ESMTP id g6ONDrI13897; Wed, 24 Jul 2002 19:13:54 -0400 (EDT) Received: from mxic1.isus.emc.com ([168.159.129.100]) by emc.com (8.10.1/8.10.1) with ESMTP id g6ONDr700582; Wed, 24 Jul 2002 19:13:53 -0400 (EDT) Received: by MXIC1 with Internet Mail Service (5.5.2653.19) id ; Wed, 24 Jul 2002 19:11:42 -0400 Message-ID: <277DD60FB639D511AC0400B0D068B71E0564C0E2@CORPMX14> From: Black_David@emc.com To: bernard_aboba@hotmail.com, ips@ece.cmu.edu Subject: iSCSI: SRP groups in Security-14 strawman Date: Wed, 24 Jul 2002 19:11:36 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-ips@ece.cmu.edu Precedence: bulk The SRP group specifications appear to need some tightening. In reading this message, please keep in mind that SRP support is OPTIONAL, so the following concerns apply only to implementations that choose to support SRP. To be specific, there is no requirement to offer or accept SRP as a value of AuthMethod. Those with no plans to support SRP can ignore the rest of this message. Let me start with the following issue that Vince Cavanna raised: > Sounds good, but I don't understand the motivation to use any primes > other than those from IKE when we know those primes are certifiable > and that a generator suitable for SRP can be easily and deterministically > determined. Is there value in giving the user multiple choices for primes > of a given size? I think the answer to Vince's second question is "no", but I also think that since the SRP primes have been proven prime and have been widely distributed with SRP software from Stanford, we should choose them over the IKE primes. The 2048 bit size of the largest SRP prime also appears to be convenient - see below. This suggests deleting the Oakley group 2, the 1536-bit [MODP] group, and the 2048-bit [MODP] group since there are SRP groups with primes of the same sizes. For the remaining MODP groups, I suggest that we pick a single acceptable generator for simplicity (i.e., that generator MUST be used with the corresponding prime, other generators MUST NOT be used): 5 for the 3072-bit, 4096-bit, and 6144-bit [MODP] groups. 19 for the 8192-bit [MODP] group. The rationale for this is the same as above - there is no value in giving the user multiple choices for generators. Tom Wu should be cited as the source of the acceptability determination for these generators. Finally, we need some implementation requirements. There are a couple of issues here: (1) For SRP, the target announces the prime and generator. If the initiator doesn't like them, it closes the connection - that's an invitation to interoperability headaches. The cleanest solution to this is to negotiate the group: - Instead of the target sending SRP_N and SRP_g, the target sends SRP_GROUP= where possible values are SRP-768, SRP-1024, etc. and MODP-3072, MODP-4096, etc. - The initiator returns SRP_GROUP= along with SRP_A. Not only is that cleaner, it also takes out a bignum without adding a round trip. The SRP_GROUP values probably need to go into an IANA registry, with a rule that the WG (or the ADs if the WG no longer exists) control additions. The alternative of folding the group selection into the AuthMethod value (e.g., AuthMethod=SRP_MODP-4096) seems clumsy by comparison and doesn't save a round trip. (2) We need some requirements on what MUST be supported for interoperability when SRP is supported. I hesitate to require support for all the groups up to the 8192-bit MODP group. A glance at draft-orman-public-key-lengths-05.txt suggests that the SRP primes are adequate for now as the 1536-bit and 2048-bit primes bracket the 96 bits of randomness that we require of CHAP secrets. In practice, I think we need to allow local security policy to disallow use of smaller primes, so the requirements would be something like: - MUST support all the SRP groups (up to 2048 bits) - MAY support the MODP groups - Target MUST offer SRP-2048 as one of the possible values of SRP_GROUP and SHOULD offer all supported groups that are allowed by local security policy. Comments? Please keep in mind that all of the above would apply only to implementations that support SRP, and support for SRP is OPTIONAL. 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 --------------------------------------------------- From owner-ips@ece.cmu.edu Wed Jul 24 19:57:41 2002 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA06424 for ; Wed, 24 Jul 2002 19:57:36 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id g6ONSVk24922 for ips-outgoing; Wed, 24 Jul 2002 19:28:31 -0400 (EDT) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from gamma.isi.edu (gamma.isi.edu [128.9.144.145]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id g6ONPto24778 for ; Wed, 24 Jul 2002 19:25:55 -0400 (EDT) Received: from ISI.EDU (jet.isi.edu [128.9.160.87]) by gamma.isi.edu (8.11.6/8.11.2) with ESMTP id g6ONPqE22630; Wed, 24 Jul 2002 16:25:52 -0700 (PDT) Message-Id: <200207242325.g6ONPqE22630@gamma.isi.edu> To: IETF-Announce: ; Subject: RFC 3347 on Small Computer Systems Interface protocol over the Internet (iSCSI) Requirements and Design Considerations Cc: rfc-editor@rfc-editor.org, ips@ece.cmu.edu From: rfc-editor@rfc-editor.org Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary=NextPart Date: Wed, 24 Jul 2002 16:25:52 -0700 Sender: owner-ips@ece.cmu.edu Precedence: bulk --NextPart A new Request for Comments is now available in online RFC libraries. RFC 3347 Title: Small Computer Systems Interface protocol over the Internet (iSCSI) Requirements and Design Considerations Author(s): M. Krueger, R. Haagens Status: Informational Date: July 2002 Mailbox: marjorie_krueger@hp.com, Randy_Haagens@hp.com, csapuntz@cisco.com, mbakke@cisco.com Pages: 25 Characters: 58097 Updates/Obsoletes/SeeAlso: None I-D Tag: draft-ietf-ips-iscsi-reqmts-06.txt URL: ftp://ftp.rfc-editor.org/in-notes/rfc3347.txt This document specifies the requirements iSCSI and its related infrastructure should satisfy and the design considerations guiding the iSCSI protocol development efforts. In the interest of timely adoption of the iSCSI protocol, the IPS group has chosen to focus the first version of the protocol to work with the existing SCSI architecture and commands, and the existing TCP/IP transport layer. Both these protocols are widely-deployed and well-understood. The thought is that using these mature protocols will entail a minimum of new invention, the most rapid possible adoption, and the greatest compatibility with Internet architecture, protocols, and equipment. This document is a product of the IP Storage Working Group of the IETF. This memo provides information for the Internet community. It does not specify an Internet standard of any kind. Distribution of this memo is unlimited. This announcement is sent to the IETF list and the RFC-DIST list. Requests to be added to or deleted from the IETF distribution list should be sent to IETF-REQUEST@IETF.ORG. Requests to be added to or deleted from the RFC-DIST distribution list should be sent to RFC-DIST-REQUEST@RFC-EDITOR.ORG. Details on obtaining RFCs via FTP or EMAIL may be obtained by sending an EMAIL message to rfc-info@RFC-EDITOR.ORG with the message body help: ways_to_get_rfcs. For example: To: rfc-info@RFC-EDITOR.ORG Subject: getting rfcs help: ways_to_get_rfcs Requests for special distribution should be addressed to either the author of the RFC in question, or to RFC-Manager@RFC-EDITOR.ORG. Unless specifically noted otherwise on the RFC itself, all RFCs are for unlimited distribution.echo Submissions for Requests for Comments should be sent to RFC-EDITOR@RFC-EDITOR.ORG. Please consult RFC 2223, Instructions to RFC Authors, for further information. Joyce K. Reynolds and Sandy Ginoza USC/Information Sciences Institute ... Below is the data which will enable a MIME compliant Mail Reader implementation to automatically retrieve the ASCII version of the RFCs. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="RFC-INFO@RFC-EDITOR.ORG" Content-Type: text/plain Content-ID: <020724162420.RFC@RFC-EDITOR.ORG> RETRIEVE: rfc DOC-ID: rfc3347 --OtherAccess Content-Type: Message/External-body; name="rfc3347.txt"; site="ftp.isi.edu"; access-type="anon-ftp"; directory="in-notes" Content-Type: text/plain Content-ID: <020724162420.RFC@RFC-EDITOR.ORG> --OtherAccess-- --NextPart-- From owner-ips@ece.cmu.edu Wed Jul 24 21:36:27 2002 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA09208 for ; Wed, 24 Jul 2002 21:36:27 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id g6P0tE328710 for ips-outgoing; Wed, 24 Jul 2002 20:55:14 -0400 (EDT) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from mxic2.corp.emc.com (mxic2.us.dg.com [128.221.31.40]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id g6P0tCo28705 for ; Wed, 24 Jul 2002 20:55:12 -0400 (EDT) Received: by mxic2.corp.emc.com with Internet Mail Service (5.5.2653.19) id ; Wed, 24 Jul 2002 20:55:06 -0400 Message-ID: <277DD60FB639D511AC0400B0D068B71E0564C0E7@CORPMX14> From: Black_David@emc.com To: ips@ece.cmu.edu Subject: iSCSI: Yokohama meeting technical issues Date: Wed, 24 Jul 2002 20:52:49 -0400 Importance: high X-Priority: 1 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-ips@ece.cmu.edu Precedence: bulk The following iSCSI technical issues were discussed at the Yokohama meeting (minutes are coming ...). The following paragraphs report the rough consensus of the room in Yokohama and I believe they are the rough consensus of the IP Storage WG. In Yokohama, some of these consensus calls were over the objection of one person (not the same person each time). This is an opportunity for those who couldn't make it to Yokohama to voice a different opinion: (1) Long Lived Discovery sessions. Support for these is not intended. The only PDUs that an initiator is allowed to send on a Discovery Session are a Send Targets text request and a logout request that specifies "close the session". Targets MUST reject all other PDUs. (2) Decimal encoding. Follows the rough consensus on the list, decimal encoding can only be used when the parameter being encoded has a fixed size (bits that the decoded value occupies) and that size is 64 bits or less. If one of the authentication bignums happens to have a value that fits in 64 bits, decimal cannot be used because the bignum has a considerably larger size. (3) Size requirements for negotiation. Compromised on 8kb as the minimum amount of text that MUST be accepted during a negotiation (consensus called over one person's objection). 64k limit applies only when an AuthMethod is supported that requires large binary values - in the meeting, this was thought to be only SPKM, but a quick check of the draft suggests that the 64k limit also has to apply apply to Kerberos - it does not apply to CHAP or SRP. (4) Error Recovery Level 0.5. An implementation that does not support both of the major features required for ErrorRecoveryLevel 1 (within-connection and within-command recovery) MUST negotiate ErrorRecoveryLevel 0, as to negotiate 1 would promise support for both. When 0 is negotiated, an initiator MAY try within-connection recovery or within-command recovery, but it MUST be prepared for a target to reject the attempts, as the target may be strictly operating at ErrorRecoveryLevel 0. A new value of the ErrorRecoveryLevel key will *NOT* be defined to enable partial support of level 1 to be negotiated. (5) BidiInitialR2T. This key will be removed, InitialR2T will also cover the bidirectional case, in part because this corresponds to Fibre Channel's behavior. (6) Resegmenting Data SNACKS - an intrepid design team came up with a compromise solution between the Monday and Tuesday sessions (including a trans-pacific conference call). Summary of the problem situation: - SCSI Read or similar command is active on an iSCSI connection. - The initiator reduces the Maximum Data PDU size it is willing to accept. - The initiator discovers that it's missing some of the inbound data and requests retransmission. iSCSI's data retransmission is based on resending the same PDUs that were sent the first time. That doesn't work in this case because they may be too large. When they're made smaller, the count of Data PDUs in the SCSI Response PDU may have to be changed. This should be a rare case. A rough summary of the compromise solution: - Existing Data SNACK MUST NOT resegment. Targets MUST check this. - A new R-Data SNACK code is defined for the resegmenting case. It always requests transmission of all unacknowledged data, and of a new SCSI Response since the count of Data PDUs may have changed. The new SCSI Response uses the same StatSN number. - A new SNACK tag is sent in an R-Data SNACK and returned in the new SCSI Response to ensure that the new response with the correct count of Data PDUs is used, as there may be one or more SCSI Responses to this command with the the wrong count in flight when the R-Data SNACK is issued (if you're wondering how multiple SCSI Responses could be in flight, think about Status SNACKs and large delays). There are a number of additional details that can be found in the working draft. I believe the above six items represent the rough consensus of the IP Storage WG, but this is an opportunity for those who differ (and could not make it to the Yokohama meeting) to object (quickly, please). 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 --------------------------------------------------- From owner-ips@ece.cmu.edu Wed Jul 24 22:17:47 2002 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA10526 for ; Wed, 24 Jul 2002 22:17:47 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id g6P1eHY00800 for ips-outgoing; Wed, 24 Jul 2002 21:40:17 -0400 (EDT) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from d12lmsgate-2.de.ibm.com (d12lmsgate-2.de.ibm.com [195.212.91.200]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id g6P1eEo00790; Wed, 24 Jul 2002 21:40:14 -0400 (EDT) Received: from d12relay02.de.ibm.com (d12relay02.de.ibm.com [9.165.215.23]) by d12lmsgate-2.de.ibm.com (8.12.3/8.12.3) with ESMTP id g6P1e6wv032966; Thu, 25 Jul 2002 03:40:06 +0200 Received: from d10hubm1.telaviv.ibm.com (d10ml001.telaviv.ibm.com [9.148.216.55]) by d12relay02.de.ibm.com (8.11.1m3/NCO/VER6.2) with ESMTP id g6P1e5L133596; Thu, 25 Jul 2002 03:40:06 +0200 Subject: Re: iSCSI: SCSI command error To: Mike Donohoe Cc: "'ips@ece.cmu.edu'" , owner-ips@ece.cmu.edu X-Mailer: Lotus Notes Release 5.0.9 November 16, 2001 Message-ID: From: "Julian Satran" Date: Thu, 25 Jul 2002 00:40:31 +0300 X-MIMETrack: Serialize by Router on D10ML001/10/M/IBM(Release 5.0.9a |January 7, 2002) at 25/07/2002 04:40:06 MIME-Version: 1.0 Content-type: text/plain; charset=us-ascii Sender: owner-ips@ece.cmu.edu Precedence: bulk Either a SCSI error (the iSCSI part is legal - Reject is out of place) or may choose to get the data in 2 installments (use R2T if the device can hold more that 4MB). Julo Mike Donohoe ntum.com> cc: Sent by: Subject: iSCSI: SCSI command error owner-ips@ece.cmu .edu 07/24/2002 07:05 PM > Let's say a target has a 4MB buffer to hold scsi data. > > If the initiator sends a scsi command with ExpectedDataLength of 4MB+1, > what is the expected response of the target?????????? > > 1. Send a Reject PDU. > > 2. Send a Scsi response with Status=2 and a revelant sense code error:4h > 44h 0h (Internal Target failure). > > 3. Send a Scsi response with Response=1. > > Must the Reject or Scsi response wait until the initiator has send all > their data for each of these possibilities???????? > > Thanks. > > From owner-ips@ece.cmu.edu Wed Jul 24 22:19:03 2002 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA10553 for ; Wed, 24 Jul 2002 22:19:03 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id g6P1eIM00807 for ips-outgoing; Wed, 24 Jul 2002 21:40:18 -0400 (EDT) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from d12lmsgate-3.de.ibm.com (d12lmsgate-3.de.ibm.com [195.212.91.201]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id g6P1eGo00799; Wed, 24 Jul 2002 21:40:16 -0400 (EDT) Received: from d12relay02.de.ibm.com (d12relay02.de.ibm.com [9.165.215.23]) by d12lmsgate-3.de.ibm.com (8.12.3/8.12.3) with ESMTP id g6P1e8hF016800; Thu, 25 Jul 2002 03:40:08 +0200 Received: from d10hubm1.telaviv.ibm.com (d10ml001.telaviv.ibm.com [9.148.216.55]) by d12relay02.de.ibm.com (8.11.1m3/NCO/VER6.2) with ESMTP id g6P1e8L133600; Thu, 25 Jul 2002 03:40:08 +0200 Subject: Re: iSCSI: v15 R2T and DATA-OUT To: "Rod Harrison" Cc: ips@ece.cmu.edu, owner-ips@ece.cmu.edu X-Mailer: Lotus Notes Release 5.0.9 November 16, 2001 Message-ID: From: "Julian Satran" Date: Thu, 25 Jul 2002 00:59:34 +0300 X-MIMETrack: Serialize by Router on D10ML001/10/M/IBM(Release 5.0.9a |January 7, 2002) at 25/07/2002 04:40:08 MIME-Version: 1.0 Content-type: text/plain; charset=us-ascii Sender: owner-ips@ece.cmu.edu Precedence: bulk There is no TTT for data-In. Julo "Rod Harrison" driver.com> cc: Sent by: Subject: iSCSI: v15 R2T and DATA-OUT owner-ips@ece.cmu .edu 07/24/2002 10:24 PM Folks, There is a potential inconsistency in the description of the use of the LUN field in DATA-OUT and R2T in the working v15 draft. 9.7.3 Target Transfer Tag, for DATA-IN last paragraph says ... "If the Target Transfer Tag is provided, then the LUN field MUST hold a valid value and be consistent with whatever was specified with the command;" 9.8.5 Target Transfer Tag, for R2T says ... "The Target Transfer Tag and LUN are copied in the outgoing data PDUs and are used by the target only." Potentially a target could return a different LUN field in the R2T, for perhaps some funky LUN mapping or other internal reason expecting it to be copied to the DATA-OUT as per the R2T text. I suspect we just want to say this is not allowed and the LUN field MUST be the same as the command PDU. Either way I think we need to indicate what is expected of the initiator if the LUN field in the R2T does not match the LUN in the command PDU. Apologies for not spotting this before the end of last call. - Rod From owner-ips@ece.cmu.edu Wed Jul 24 22:19:31 2002 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA10573 for ; Wed, 24 Jul 2002 22:19:26 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id g6P1uSQ01493 for ips-outgoing; Wed, 24 Jul 2002 21:56:28 -0400 (EDT) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from mail.wrs.com (unknown-1-11.windriver.com [147.11.1.11]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id g6P1uQo01487 for ; Wed, 24 Jul 2002 21:56:27 -0400 (EDT) Received: from london (vpn10-95-10-3.wrsec.fr [10.95.10.3]) by mail.wrs.com (8.9.3/8.9.1) with SMTP id SAA24712; Wed, 24 Jul 2002 18:54:33 -0700 (PDT) From: "Rod Harrison" To: "Julian Satran" Cc: Subject: RE: iSCSI: v15 R2T and DATA-OUT Date: Wed, 24 Jul 2002 20:57:05 -0500 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0) Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2314.1300 In-Reply-To: Sender: owner-ips@ece.cmu.edu Precedence: bulk Content-Transfer-Encoding: 7bit Oops, I see the confusion. I said DATA-IN in my message when I meant DATA-OUT. However, re-reading the section of v15 in question I now see that the third paragraph is referring to the DATA-IN LUN, not the DATA-OUT LUN. That wasn't clear to me when first scanned it because of the paragraph break. Perhaps a note of clarification needs to be added? - Rod -----Original Message----- From: Rod Harrison [mailto:rod.harrison@windriver.com] Sent: Wednesday, July 24, 2002 8:51 PM To: Julian Satran Cc: ips@ece.cmu.edu Subject: RE: iSCSI: v15 R2T and DATA-OUT Julian, I think you've misread my message. I was questioning how the initiator should handle the LUN between an R2T and the DATA-OUT(s) that satisfy it. DATA-OUT says copy the LUN from the command PDU, R2T says copy the LUN from the R2T to the DATA-OUT. Which is correct if the R2T contains a different LUN than that in the command PDU? - Rod -----Original Message----- From: Julian Satran [mailto:Julian_Satran@il.ibm.com] Sent: Wednesday, July 24, 2002 5:00 PM To: Rod Harrison Cc: ips@ece.cmu.edu; owner-ips@ece.cmu.edu Subject: Re: iSCSI: v15 R2T and DATA-OUT There is no TTT for data-In. Julo "Rod Harrison" driver.com> cc: Sent by: Subject: iSCSI: v15 R2T and DATA-OUT owner-ips@ece.cmu .edu 07/24/2002 10:24 PM Folks, There is a potential inconsistency in the description of the use of the LUN field in DATA-OUT and R2T in the working v15 draft. 9.7.3 Target Transfer Tag, for DATA-IN last paragraph says ... "If the Target Transfer Tag is provided, then the LUN field MUST hold a valid value and be consistent with whatever was specified with the command;" 9.8.5 Target Transfer Tag, for R2T says ... "The Target Transfer Tag and LUN are copied in the outgoing data PDUs and are used by the target only." Potentially a target could return a different LUN field in the R2T, for perhaps some funky LUN mapping or other internal reason expecting it to be copied to the DATA-OUT as per the R2T text. I suspect we just want to say this is not allowed and the LUN field MUST be the same as the command PDU. Either way I think we need to indicate what is expected of the initiator if the LUN field in the R2T does not match the LUN in the command PDU. Apologies for not spotting this before the end of last call. - Rod From owner-ips@ece.cmu.edu Wed Jul 24 22:21:47 2002 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA10639 for ; Wed, 24 Jul 2002 22:21:47 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id g6P1ogr01247 for ips-outgoing; Wed, 24 Jul 2002 21:50:42 -0400 (EDT) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from mail.wrs.com (unknown-1-11.windriver.com [147.11.1.11]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id g6P1oeo01243 for ; Wed, 24 Jul 2002 21:50:40 -0400 (EDT) Received: from london (vpn10-95-10-3.wrsec.fr [10.95.10.3]) by mail.wrs.com (8.9.3/8.9.1) with SMTP id SAA22812; Wed, 24 Jul 2002 18:48:47 -0700 (PDT) From: "Rod Harrison" To: "Julian Satran" Cc: Subject: RE: iSCSI: v15 R2T and DATA-OUT Date: Wed, 24 Jul 2002 20:51:19 -0500 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0) Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2314.1300 In-Reply-To: Sender: owner-ips@ece.cmu.edu Precedence: bulk Content-Transfer-Encoding: 7bit Julian, I think you've misread my message. I was questioning how the initiator should handle the LUN between an R2T and the DATA-OUT(s) that satisfy it. DATA-OUT says copy the LUN from the command PDU, R2T says copy the LUN from the R2T to the DATA-OUT. Which is correct if the R2T contains a different LUN than that in the command PDU? - Rod -----Original Message----- From: Julian Satran [mailto:Julian_Satran@il.ibm.com] Sent: Wednesday, July 24, 2002 5:00 PM To: Rod Harrison Cc: ips@ece.cmu.edu; owner-ips@ece.cmu.edu Subject: Re: iSCSI: v15 R2T and DATA-OUT There is no TTT for data-In. Julo "Rod Harrison" driver.com> cc: Sent by: Subject: iSCSI: v15 R2T and DATA-OUT owner-ips@ece.cmu .edu 07/24/2002 10:24 PM Folks, There is a potential inconsistency in the description of the use of the LUN field in DATA-OUT and R2T in the working v15 draft. 9.7.3 Target Transfer Tag, for DATA-IN last paragraph says ... "If the Target Transfer Tag is provided, then the LUN field MUST hold a valid value and be consistent with whatever was specified with the command;" 9.8.5 Target Transfer Tag, for R2T says ... "The Target Transfer Tag and LUN are copied in the outgoing data PDUs and are used by the target only." Potentially a target could return a different LUN field in the R2T, for perhaps some funky LUN mapping or other internal reason expecting it to be copied to the DATA-OUT as per the R2T text. I suspect we just want to say this is not allowed and the LUN field MUST be the same as the command PDU. Either way I think we need to indicate what is expected of the initiator if the LUN field in the R2T does not match the LUN in the command PDU. Apologies for not spotting this before the end of last call. - Rod From owner-ips@ece.cmu.edu Wed Jul 24 23:37:16 2002 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA12306 for ; Wed, 24 Jul 2002 23:37:11 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id g6P2qFO04105 for ips-outgoing; Wed, 24 Jul 2002 22:52:15 -0400 (EDT) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from d12lmsgate.de.ibm.com (d12lmsgate.de.ibm.com [195.212.91.199]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id g6P2qCo04093; Wed, 24 Jul 2002 22:52:12 -0400 (EDT) Received: from d12relay01.de.ibm.com (d12relay01.de.ibm.com [9.165.215.22]) by d12lmsgate.de.ibm.com (8.12.3/8.12.3) with ESMTP id g6P2q5fh005612; Thu, 25 Jul 2002 04:52:05 +0200 Received: from d10hubm1.telaviv.ibm.com (d10ml001.telaviv.ibm.com [9.148.216.55]) by d12relay01.de.ibm.com (8.11.1m3/NCO/VER6.2) with ESMTP id g6P2q5Y142820; Thu, 25 Jul 2002 04:52:05 +0200 To: "Robert D. Russell" Cc: ips@ece.cmu.edu, owner-ips@ece.cmu.edu MIME-Version: 1.0 Subject: Re: iSCSI: Use of Reject as a key value X-Mailer: Lotus Notes Release 5.0.9 November 16, 2001 From: "Julian Satran" Message-ID: Date: Thu, 25 Jul 2002 05:52:04 +0300 X-MIMETrack: Serialize by Router on D10ML001/10/M/IBM(Release 5.0.9a |January 7, 2002) at 25/07/2002 05:52:05, Serialize complete at 25/07/2002 05:52:05 Content-Type: multipart/alternative; boundary="=_alternative 000F0A7BC2256C01_=" Sender: owner-ips@ece.cmu.edu Precedence: bulk This is a multipart message in MIME format. --=_alternative 000F0A7BC2256C01_= Content-Type: text/plain; charset="us-ascii" Bob, On the last pdf you will find a statement about what to do. Julo "Robert D. Russell" Sent by: owner-ips@ece.cmu.edu 07/25/2002 12:58 AM To: ips@ece.cmu.edu cc: Subject: iSCSI: Use of Reject as a key value Julian: Attached are 2 ascii text files. The first, reject_extracts.txt, contains all the pieces of draft 14 (the latest available txt version of the drafts) that say anything about the use of Reject as a key value. (At least all those I could find using simple search -- unfortunately, Reject is also the name of a PDU and hence it is not a simple mechanical process to distinguish the two uses! If I missed some, please let me know.) The second, reject_comments.txt, are my comments on these excerpts from the standard. It seems to me that the key thing missing in the standard is a general statement about "what to do next" if a key=Reject response is received. Except for the OFMarkInt and IFMarkInt keys, I could find no other statement about how to proceed after receiving the key=Reject response. In looking through the e-mails posted to the list for June and July, I also could find nothing, although many people seem to be taking the third of the 3 interpretations I listed in reject_comments.txt. I am requesting a clear statement somewhere in the standard that says "what to do next" upon receiving a key=Reject response. Thank you for your consideration. Bob Russell InterOperability Lab University of New Hampshire rdr@iol.unh.edu 603-862-3774 #### reject_extracts.txt has been removed from this note on July 25 2002 by Julian Satran #### reject_comments.txt has been removed from this note on July 25 2002 by Julian Satran --=_alternative 000F0A7BC2256C01_= Content-Type: text/html; charset="us-ascii"
Bob,

On the last pdf you will find a statement about what to do.

Julo


"Robert D. Russell" <rdr@io.iol.unh.edu>
Sent by: owner-ips@ece.cmu.edu

07/25/2002 12:58 AM

       
        To:        ips@ece.cmu.edu
        cc:        
        Subject:        iSCSI: Use of Reject as a key value

       





Julian:
Attached are 2 ascii text files.
The first, reject_extracts.txt, contains all the pieces of
draft 14 (the latest available txt version of the drafts)
that say anything about the use of Reject as a key value.
(At least all those I could find using simple search --
unfortunately, Reject is also the name of a PDU and hence
it is not a simple mechanical process to distinguish the two
uses!  If I missed some, please let me know.)
The second, reject_comments.txt, are my comments on these
excerpts from the standard.
It seems to me that the key thing missing in the standard is
a general statement about "what to do next" if a key=Reject response
is received.  Except for the OFMarkInt and IFMarkInt keys,
I could find no other statement about how to proceed after
receiving the key=Reject response.  In looking through the
e-mails posted to the list for June and July, I also could find
nothing, although many people seem to be taking the third
of the 3 interpretations I listed in reject_comments.txt.
I am requesting a clear statement somewhere in the standard that
says "what to do next" upon receiving a key=Reject response.
Thank you for your consideration.
Bob Russell
InterOperability Lab
University of New Hampshire
rdr@iol.unh.edu
603-862-3774






#### reject_extracts.txt has been removed from this note on July 25 2002 by Julian Satran
#### reject_comments.txt has been removed from this note on July 25 2002 by Julian Satran

--=_alternative 000F0A7BC2256C01_=-- From owner-ips@ece.cmu.edu Thu Jul 25 00:33:51 2002 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA13673 for ; Thu, 25 Jul 2002 00:33:51 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id g6P3n7k06431 for ips-outgoing; Wed, 24 Jul 2002 23:49:07 -0400 (EDT) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from mail.wrs.com (unknown-1-11.windriver.com [147.11.1.11]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id g6P3n5o06426 for ; Wed, 24 Jul 2002 23:49:05 -0400 (EDT) Received: from london (vpn10-95-10-3.wrsec.fr [10.95.10.3]) by mail.wrs.com (8.9.3/8.9.1) with SMTP id UAA29854; Wed, 24 Jul 2002 20:47:13 -0700 (PDT) From: "Rod Harrison" To: Cc: Subject: RE: iSCSI: v15 R2T and DATA-OUT Date: Wed, 24 Jul 2002 22:49:45 -0500 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0) Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2314.1300 In-Reply-To: Sender: owner-ips@ece.cmu.edu Precedence: bulk Content-Transfer-Encoding: 7bit OK, it's been a long day. Let me try this one more time. I was write (almost) first time but I meant DATA-OUT instead of DATA-IN. Here's what I meant to say ... There is a potential inconsistency in the description of the use of the LUN field in DATA-OUT and R2T in the working v15 draft. 9.7.3 Target Transfer Tag, for DATA-OUT last paragraph says ... "If the Target Transfer Tag is provided, then the LUN field MUST hold a valid value and be consistent with whatever was specified with the command;" 9.8.5 Target Transfer Tag, for R2T says ... "The Target Transfer Tag and LUN are copied in the outgoing data PDUs and are used by the target only." Potentially a target could return a different LUN field in the R2T, for perhaps some funky LUN mapping or other internal reason expecting it to be copied to the DATA-OUT as per the R2T text. I think we need to indicate what is expected of the initiator if the LUN field in the R2T does not match the LUN in the command PDU. - Rod -----Original Message----- From: Rod Harrison [mailto:rod.harrison@windriver.com] Sent: Wednesday, July 24, 2002 8:57 PM To: Julian Satran Cc: ips@ece.cmu.edu Subject: RE: iSCSI: v15 R2T and DATA-OUT Oops, I see the confusion. I said DATA-IN in my message when I meant DATA-OUT. However, re-reading the section of v15 in question I now see that the third paragraph is referring to the DATA-IN LUN, not the DATA-OUT LUN. That wasn't clear to me when first scanned it because of the paragraph break. Perhaps a note of clarification needs to be added? - Rod -----Original Message----- From: Rod Harrison [mailto:rod.harrison@windriver.com] Sent: Wednesday, July 24, 2002 8:51 PM To: Julian Satran Cc: ips@ece.cmu.edu Subject: RE: iSCSI: v15 R2T and DATA-OUT Julian, I think you've misread my message. I was questioning how the initiator should handle the LUN between an R2T and the DATA-OUT(s) that satisfy it. DATA-OUT says copy the LUN from the command PDU, R2T says copy the LUN from the R2T to the DATA-OUT. Which is correct if the R2T contains a different LUN than that in the command PDU? - Rod -----Original Message----- From: Julian Satran [mailto:Julian_Satran@il.ibm.com] Sent: Wednesday, July 24, 2002 5:00 PM To: Rod Harrison Cc: ips@ece.cmu.edu; owner-ips@ece.cmu.edu Subject: Re: iSCSI: v15 R2T and DATA-OUT There is no TTT for data-In. Julo "Rod Harrison" driver.com> cc: Sent by: Subject: iSCSI: v15 R2T and DATA-OUT owner-ips@ece.cmu .edu 07/24/2002 10:24 PM Folks, There is a potential inconsistency in the description of the use of the LUN field in DATA-OUT and R2T in the working v15 draft. 9.7.3 Target Transfer Tag, for DATA-IN last paragraph says ... "If the Target Transfer Tag is provided, then the LUN field MUST hold a valid value and be consistent with whatever was specified with the command;" 9.8.5 Target Transfer Tag, for R2T says ... "The Target Transfer Tag and LUN are copied in the outgoing data PDUs and are used by the target only." Potentially a target could return a different LUN field in the R2T, for perhaps some funky LUN mapping or other internal reason expecting it to be copied to the DATA-OUT as per the R2T text. I suspect we just want to say this is not allowed and the LUN field MUST be the same as the command PDU. Either way I think we need to indicate what is expected of the initiator if the LUN field in the R2T does not match the LUN in the command PDU. Apologies for not spotting this before the end of last call. - Rod From owner-ips@ece.cmu.edu Thu Jul 25 01:32:38 2002 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA14469 for ; Thu, 25 Jul 2002 01:32:37 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id g6P4rI809089 for ips-outgoing; Thu, 25 Jul 2002 00:53:18 -0400 (EDT) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from magic.adaptec.com (magic.adaptec.com [208.236.45.80]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id g6P4rGo09085 for ; Thu, 25 Jul 2002 00:53:16 -0400 (EDT) Received: from redfish.adaptec.com (redfish.adaptec.com [162.62.50.11]) by magic.adaptec.com (8.10.2+Sun/8.10.2) with ESMTP id g6P4rAr08996 for ; Wed, 24 Jul 2002 21:53:10 -0700 (PDT) Received: from aimexc02.corp.adaptec.com (aimexc02.corp.adaptec.com [162.62.62.40]) by redfish.adaptec.com (8.8.8+Sun/8.8.8) with ESMTP id VAA22621 for ; Wed, 24 Jul 2002 21:53:10 -0700 (PDT) Received: by aimexc02.corp.adaptec.com with Internet Mail Service (5.5.2653.19) id ; Wed, 24 Jul 2002 21:53:10 -0700 Message-ID: From: "Rao, Sajjan" To: ips@ece.cmu.edu Subject: Regarding CSG and NSG Date: Wed, 24 Jul 2002 21:53:08 -0700 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C23397.2BD67B30" Sender: owner-ips@ece.cmu.edu Precedence: bulk This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_001_01C23397.2BD67B30 Content-Type: text/plain Hi, I have a couple of questions. 1) Suppose the initiator sets CSG = 0 and NSG = 1 in login request, and says requires no authentication. 2) Can the target set the CSG = 1 and NSG = full feature phase, in its login response? Sajjan ------_=_NextPart_001_01C23397.2BD67B30 Content-Type: text/html Content-Transfer-Encoding: quoted-printable

Hi,

    = I have a couple of questions.

1) Suppose the initiator sets CSG =3D 0 and NSG =3D = 1 in login request, and says requires no = authentication.

2) Can the target set the CSG =3D 1 and NSG =3D full = feature phase, in its login response?

 

Sajjan

------_=_NextPart_001_01C23397.2BD67B30-- From owner-ips@ece.cmu.edu Thu Jul 25 04:59:48 2002 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA26692 for ; Thu, 25 Jul 2002 04:59:48 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id g6P8N1016833 for ips-outgoing; Thu, 25 Jul 2002 04:23:01 -0400 (EDT) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from gremg1.net.external.hp.com (gremg1.net.external.hp.com [192.6.111.73]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id g6P8Mxo16828 for ; Thu, 25 Jul 2002 04:22:59 -0400 (EDT) Received: from fowey.BR.ITC.HP.COM (fowey.br.itc.hp.com [15.145.8.186]) by gremg1.net.external.hp.com (Postfix) with SMTP id 661E0575; Thu, 25 Jul 2002 10:22:57 +0200 (METDST) Received: from 15.145.8.186 by fowey.BR.ITC.HP.COM (InterScan E-Mail VirusWall NT); Thu, 25 Jul 2002 09:22:56 +0100 Received: by fowey.br.itc.hp.com with Internet Mail Service (5.5.2655.55) id ; Thu, 25 Jul 2002 09:22:56 +0100 Message-ID: <0B9A57FF1D57D411B47500D0B73E5CC104FF203C@dickens.bri.hp.com> From: "BURBRIDGE,MATTHEW (HP-UnitedKingdom,ex2)" To: "'Rao, Sajjan'" , ips@ece.cmu.edu Subject: RE: Regarding CSG and NSG Date: Thu, 25 Jul 2002 09:22:55 +0100 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2655.55) Content-Type: multipart/mixed; boundary="----=_NextPartTM-000-4de03486-1bb1-45b7-b4fe-dade2719a1b7" Sender: owner-ips@ece.cmu.edu Precedence: bulk This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------=_NextPartTM-000-4de03486-1bb1-45b7-b4fe-dade2719a1b7 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C233B4.7A409D60" ------_=_NextPart_001_01C233B4.7A409D60 Content-Type: text/plain; charset="iso-8859-1" Sajjan, It depends whether the initiator has its T bit set. If T=0 then the initiator is saying that it is security phase and is not yet ready to move to the next phase (NSG=ignore: if T=0, NSG is reserved). This implies that it does want to negotiate security (i.e. authentication). If T=1, it says that is has no more security to negotiate and is ready to move to operational phase (as NSG=1) when the target says it's ready. In the latter of these two options (T=1,CSG=0,NSG=1) then the initiator is giving the target chance to start authentication. Alternatively, if the initiator does not want to negotiate security it can set CSG=1 in the initial login. This removes one message exchange if the target does not want to negotiate security but runs the risk of receiving a login failure if the target does want to negotiate security. If it wants to negotiate parameters then: T=0,CSG=1,NSG=reserved. If it does not want to negotiate text parameters then T=1, CSG=1, NSG=3. In your example I am presuming that T=1 in 1). which is fine. Initiator is giving the target the opportunity to negotiate security but does not wish to start it itself. In 2), the T bit MUST be 0 as it can not be the final login response. The target is informing the initiator that it is happy to enter operational phase (CSG=1). As the T bit must be 0 in 2) NSG = reserved. 1) Suppose the initiator sets T=1, CSG = 0 and NSG = 1 in login request, and says requires no authentication. 2) Can the target set the CSG = 1 and NSG = full feature phase, in its login response? NO It should be 2) Can the target set the T=0, CSG = 1 and NSG = reserved, in its login response? Matthew Burbridge Principal Engineer Nearline NSS Bristol Hewlett Packard Tel: +44 117 312 7010 E-mail: matthewb@bri.hp.com -----Original Message----- From: Rao, Sajjan [mailto:sajjan_rao@adaptec.com] Sent: Thursday, July 25, 2002 5:53 AM To: ips@ece.cmu.edu Subject: Regarding CSG and NSG Hi, I have a couple of questions. 1) Suppose the initiator sets CSG = 0 and NSG = 1 in login request, and says requires no authentication. 2) Can the target set the CSG = 1 and NSG = full feature phase, in its login response? Sajjan ------_=_NextPart_001_01C233B4.7A409D60 Content-Type: text/html; charset="iso-8859-1"
Sajjan,
 
It depends whether the initiator has its T bit set.  If T=0 then the initiator is saying that it is security phase and is not yet ready to move to the next phase (NSG=ignore: if T=0, NSG is reserved). This implies that it does want to negotiate security (i.e. authentication).  If T=1, it says that is has no more security to negotiate and is ready to move to operational phase (as NSG=1) when the target says it's ready.  In the latter of these two options (T=1,CSG=0,NSG=1) then the initiator is giving the target chance to start authentication.
 
Alternatively, if the initiator does not want to negotiate security it can set CSG=1 in the initial login.  This removes one message exchange if the target does not want to negotiate security but runs the risk of receiving a login failure if the target does want to negotiate security. If it wants to negotiate parameters then: T=0,CSG=1,NSG=reserved.  If it does not want to negotiate text parameters then T=1, CSG=1, NSG=3.
 
In your example I am presuming that T=1 in 1). which is fine. Initiator is giving the target the opportunity to negotiate security but does not wish to start it itself.  In 2), the T bit MUST be 0 as it can not be the final login response.  The target is informing the initiator that it is happy to enter operational phase (CSG=1).  As the T bit must be 0 in 2) NSG = reserved.
 
    1) Suppose the initiator sets T=1, CSG = 0 and NSG = 1  in login request, and says requires no authentication.

 

    2) Can the target set the CSG = 1 and NSG = full feature phase, in its login response?  NO

 

    It should be

 

    2) Can the target set the T=0, CSG = 1 and NSG = reserved, in its login response?
 

 

Matthew Burbridge
Principal Engineer
Nearline NSS Bristol
Hewlett Packard
Tel: +44 117 312 7010
E-mail: matthewb@bri.hp.com

-----Original Message-----
From: Rao, Sajjan [mailto:sajjan_rao@adaptec.com]
Sent: Thursday, July 25, 2002 5:53 AM
To: ips@ece.cmu.edu
Subject: Regarding CSG and NSG

Hi,

    I have a couple of questions.

1) Suppose the initiator sets CSG = 0 and NSG = 1 in login request, and says requires no authentication.

2) Can the target set the CSG = 1 and NSG = full feature phase, in its login response?

 

Sajjan

------_=_NextPart_001_01C233B4.7A409D60-- ------=_NextPartTM-000-4de03486-1bb1-45b7-b4fe-dade2719a1b7-- From owner-ips@ece.cmu.edu Thu Jul 25 05:00:06 2002 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA26709 for ; Thu, 25 Jul 2002 05:00:06 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id g6P8ZBY17170 for ips-outgoing; Thu, 25 Jul 2002 04:35:11 -0400 (EDT) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from hclnpd.hclt.co.in ([202.54.64.7]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id g6P8Z4o17164 for ; Thu, 25 Jul 2002 04:35:04 -0400 (EDT) Received: from mailnpd.hclt-ntl.co.in ([192.168.19.36]) by hclnpd.hclt.co.in with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) id 3B5925QS; Thu, 25 Jul 2002 14:04:18 +0530 Received: from nramamurpc (nramamur-pc.hclt-ntl.co.in [192.168.19.98]) by mailnpd.hclt-ntl.co.in (8.11.0/8.11.0) with SMTP id g6P8R5419287; Thu, 25 Jul 2002 13:57:06 +0530 Message-ID: <004d01c233b6$83773f90$6213a8c0@hcltech.com> From: "Nandakumar Ramamurthy" To: "Rao, Sajjan" Cc: References: Subject: Re: Regarding CSG and NSG Date: Thu, 25 Jul 2002 14:07:28 +0530 Organization: HCL Technologies Ltd. MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_004A_01C233E4.9C161C50" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2600.0000 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 Sender: owner-ips@ece.cmu.edu Precedence: bulk This is a multi-part message in MIME format. ------=_NextPart_000_004A_01C233E4.9C161C50 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hi, The following statement specifies the target's action. Section 4.3 of draft-14 says : "If the initiator is willing to negotiate security, but is unwilling=20 to make the initial parameter offer and may accept a connection with- out security, it issues the Login with the T bit set to 1, the CSG=20 set to SecurityNegotiation, and NSG set to LoginOperationalNegotia- tion. If the target is also ready to forego security, the Login=20 response is empty and has T bit set to 1, the CSG set to SecurityNe- gotiation, and NSG set to LoginOperationalNegotiation." The target will not make the transition to LoginOperationalNegotiation = if it wants to authenticate the initiator. Thanks, Nandakumar Member Technical Staff HCL Technologies, Chennai, INDIA. http://san.hcltech.com ----- Original Message -----=20 From: Rao, Sajjan=20 To: ips@ece.cmu.edu=20 Sent: Thursday, July 25, 2002 10:23 AM Subject: Regarding CSG and NSG Hi, I have a couple of questions. 1) Suppose the initiator sets CSG =3D 0 and NSG =3D 1 in login = request, and says requires no authentication. 2) Can the target set the CSG =3D 1 and NSG =3D full feature phase, in = its login response? =20 Sajjan ------=_NextPart_000_004A_01C233E4.9C161C50 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
Hi,
 
The following statement specifies the = target's=20 action.
 
Section 4.3 of draft-14 says = :
 
   "If the initiator is = willing to=20 negotiate security, but is unwilling
   to make the = initial=20 parameter offer and may accept a connection with-
   out = security,=20 it issues the Login with the T bit set to 1, the CSG
   = set to=20 SecurityNegotiation, and NSG set to = LoginOperationalNegotia-
  =20 tion. If the target is also ready to forego security, the Login =
  =20 response is empty and has T bit set to 1, the CSG set to=20 SecurityNe-
   gotiation, and NSG set to=20 LoginOperationalNegotiation."
 
 
The target will not make the transition to = LoginOperationalNegotiation=20 if it
wants to authenticate the initiator.

 
Thanks,
Nandakumar
Member Technical Staff
HCL Technologies, Chennai,=20 INDIA.
http://san.hcltech.com
 
----- Original Message -----
From:=20 Rao,=20 Sajjan
Sent: Thursday, July 25, 2002 = 10:23=20 AM
Subject: Regarding CSG and = NSG

Hi,

    I have a couple = of=20 questions.

1) Suppose the initiator = sets CSG=20 =3D 0 and NSG =3D 1 in login request, and says requires no=20 authentication.

2) Can the target set = the CSG =3D 1=20 and NSG =3D full feature phase, in its login=20 response?

 

Sajjan

------=_NextPart_000_004A_01C233E4.9C161C50-- From owner-ips@ece.cmu.edu Thu Jul 25 05:40:54 2002 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA27254 for ; Thu, 25 Jul 2002 05:40:54 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id g6P8wIb29151 for ips-outgoing; Thu, 25 Jul 2002 04:58:18 -0400 (EDT) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from magic.adaptec.com (magic.adaptec.com [208.236.45.80]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id g6P8wGo29147 for ; Thu, 25 Jul 2002 04:58:16 -0400 (EDT) Received: from redfish.adaptec.com (redfish.adaptec.com [162.62.50.11]) by magic.adaptec.com (8.10.2+Sun/8.10.2) with ESMTP id g6P8w9r19372; Thu, 25 Jul 2002 01:58:09 -0700 (PDT) Received: from aimexc02.corp.adaptec.com (aimexc02.corp.adaptec.com [162.62.62.40]) by redfish.adaptec.com (8.8.8+Sun/8.8.8) with ESMTP id BAA03763; Thu, 25 Jul 2002 01:58:09 -0700 (PDT) Received: by aimexc02.corp.adaptec.com with Internet Mail Service (5.5.2653.19) id ; Thu, 25 Jul 2002 01:58:08 -0700 Message-ID: From: "Rao, Sajjan" To: "BURBRIDGE,MATTHEW (HP-UnitedKingdom,ex2)" , ips@ece.cmu.edu Subject: RE: Regarding CSG and NSG Date: Thu, 25 Jul 2002 01:58:08 -0700 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C233B9.657AFB00" Sender: owner-ips@ece.cmu.edu Precedence: bulk This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_001_01C233B9.657AFB00 Content-Type: text/plain Matthew, Yes I am setting the T bit to 1, and CSG = 0 and NSG = 1 in my login response. But the initiator seems to drop the connection and trying to set up a new connection. The following is the complete procedure, Login Request T = 1, CSG = 0, NSG = 1 (auth = None, session type = Discovery) Login Response T = 1, CSG = 0, NSG = 1. Should I set the the T = 0, CSG = 1, NSG = x ? -- Sajjan -----Original Message----- From: BURBRIDGE,MATTHEW (HP-UnitedKingdom,ex2) [mailto:matthew_burbridge@hp.com] Sent: Thursday, July 25, 2002 1:53 PM To: 'Rao, Sajjan'; ips@ece.cmu.edu Subject: RE: Regarding CSG and NSG Sajjan, It depends whether the initiator has its T bit set. If T=0 then the initiator is saying that it is security phase and is not yet ready to move to the next phase (NSG=ignore: if T=0, NSG is reserved). This implies that it does want to negotiate security (i.e. authentication). If T=1, it says that is has no more security to negotiate and is ready to move to operational phase (as NSG=1) when the target says it's ready. In the latter of these two options (T=1,CSG=0,NSG=1) then the initiator is giving the target chance to start authentication. Alternatively, if the initiator does not want to negotiate security it can set CSG=1 in the initial login. This removes one message exchange if the target does not want to negotiate security but runs the risk of receiving a login failure if the target does want to negotiate security. If it wants to negotiate parameters then: T=0,CSG=1,NSG=reserved. If it does not want to negotiate text parameters then T=1, CSG=1, NSG=3. In your example I am presuming that T=1 in 1). which is fine. Initiator is giving the target the opportunity to negotiate security but does not wish to start it itself. In 2), the T bit MUST be 0 as it can not be the final login response. The target is informing the initiator that it is happy to enter operational phase (CSG=1). As the T bit must be 0 in 2) NSG = reserved. 1) Suppose the initiator sets T=1, CSG = 0 and NSG = 1 in login request, and says requires no authentication. 2) Can the target set the CSG = 1 and NSG = full feature phase, in its login response? NO It should be 2) Can the target set the T=0, CSG = 1 and NSG = reserved, in its login response? Matthew Burbridge Principal Engineer Nearline NSS Bristol Hewlett Packard Tel: +44 117 312 7010 E-mail: matthewb@bri.hp.com -----Original Message----- From: Rao, Sajjan [mailto:sajjan_rao@adaptec.com] Sent: Thursday, July 25, 2002 5:53 AM To: ips@ece.cmu.edu Subject: Regarding CSG and NSG Hi, I have a couple of questions. 1) Suppose the initiator sets CSG = 0 and NSG = 1 in login request, and says requires no authentication. 2) Can the target set the CSG = 1 and NSG = full feature phase, in its login response? Sajjan ------_=_NextPart_001_01C233B9.657AFB00 Content-Type: text/html Content-Transfer-Encoding: quoted-printable

Matthew,

       &nb= sp;  Yes I am setting the T bit to 1, and CSG =3D 0 and NSG =3D 1  in = my login response.

But the initiator seems to drop = the connection and trying to set up a new = connection.

 

=

The following is the complete = procedure,

Login Request   T =3D 1, CSG =3D 0, NSG =3D 1 (auth =3D None, session type =3D Discovery)

Login Response T  =3D 1, CSG =3D 0, NSG = =3D 1.

 

=

Should I set the the T =3D 0, CSG = =3D 1, NSG =3D x ?

 

=

-- = Sajjan

 

=

-----Original = Message-----
From: BURBRIDGE,MATTHEW (HP-UnitedKingdom,ex2) [mailto:matthew_burbridge@hp.com]
Sent: = Thursday, July 25, = 2002 1:53 PM
To: 'Rao, Sajjan'; = ips@ece.cmu.edu
Subject: RE: Regarding = CSG and NSG

 

Sajjan,

 

It depends whether the initiator has its T bit = set.  If T=3D0 then the initiator is saying that it is security phase and is not = yet ready to move to the next phase (NSG=3Dignore: if T=3D0, NSG is reserved). = This implies that it does want to negotiate security (i.e. authentication).  If = T=3D1, it says that is has no more security to negotiate and is ready to move to operational phase (as NSG=3D1) when the target says it's ready.  = In the latter of these two options (T=3D1,CSG=3D0,NSG=3D1) then the initiator = is giving the target chance to start = authentication.

 

Alternatively, if the initiator does not want to = negotiate security it can set CSG=3D1 in the initial login.  This removes = one message exchange if the target does not want to negotiate security but runs the = risk of receiving a login failure if the target does want to negotiate = security. If it wants to negotiate parameters then: = T=3D0,CSG=3D1,NSG=3Dreserved.  If it does not want to negotiate text parameters then T=3D1, CSG=3D1, = NSG=3D3.

 

In your example I am presuming that T=3D1 in 1). = which is fine. Initiator is giving the target the opportunity to negotiate = security but does not wish to start it itself.  In 2), the T bit MUST be 0 = as it can not be the final login response.  The target is informing the initiator that it is happy to enter operational phase (CSG=3D1).  = As the T bit must be 0 in 2) NSG =3D = reserved.

 

    1) Suppose the initiator = sets T=3D1, = CSG =3D 0 and NSG =3D 1  in login request, and says requires no = authentication.

 

    2) Can the target set the CSG =3D = 1 and NSG =3D full feature phase, in its login response?  NO<= font color=3Dpurple>

 

    It should = be

 

 

    2) Can the target set = the T=3D0, = CSG =3D 1 and NSG =3D reserved, in its login response?

 

 <= /b>

Matthew = Burbridge
Principal = Engineer
Nearline NSS = Bristol

Hewlett Packard
Tel: +44 117 312 = 7010
E-mail: = matthewb@bri.hp.com


-----Original Message-----
From: Rao, Sajjan [mailto:sajjan_rao@adaptec.com]
Sent: = Thursday, July 25, = 2002 5:53 AM
To: ips@ece.cmu.edu
Subject: Regarding CSG = and NSG

Hi,

    I have a couple of questions.

1) Suppose the initiator = sets CSG =3D 0 and NSG =3D 1 in login request, and says requires no = authentication.

2) Can the target set the = CSG =3D 1 and NSG =3D full feature phase, in its login = response?

 

Sajjan

------_=_NextPart_001_01C233B9.657AFB00-- From owner-ips@ece.cmu.edu Thu Jul 25 05:44:39 2002 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA27308 for ; Thu, 25 Jul 2002 05:44:27 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id g6P9A5Y29549 for ips-outgoing; Thu, 25 Jul 2002 05:10:05 -0400 (EDT) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from gremg1.net.external.hp.com (gremg1.net.external.hp.com [192.6.111.73]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id g6P9A3o29545 for ; Thu, 25 Jul 2002 05:10:03 -0400 (EDT) Received: from loddon.br.itc.hp.com (loddon.br.itc.hp.com [15.145.8.166]) by gremg1.net.external.hp.com (Postfix) with SMTP id E69BA2C7; Thu, 25 Jul 2002 11:10:01 +0200 (METDST) Received: from 15.145.8.166 by loddon.br.itc.hp.com (InterScan E-Mail VirusWall NT); Thu, 25 Jul 2002 10:10:01 +0100 Received: by loddon.br.itc.hp.com with Internet Mail Service (5.5.2655.55) id ; Thu, 25 Jul 2002 10:10:01 +0100 Message-ID: <0B9A57FF1D57D411B47500D0B73E5CC104FF203D@dickens.bri.hp.com> From: "BURBRIDGE,MATTHEW (HP-UnitedKingdom,ex2)" To: "'Rao, Sajjan'" , "BURBRIDGE,MATTHEW (HP-UnitedKingdom,ex2)" , ips@ece.cmu.edu Subject: RE: Regarding CSG and NSG Date: Thu, 25 Jul 2002 10:10:00 +0100 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2655.55) Content-Type: multipart/mixed; boundary="----=_NextPartTM-000-65665870-bdaf-44d3-9a8a-7232e2be97ae" Sender: owner-ips@ece.cmu.edu Precedence: bulk This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------=_NextPartTM-000-65665870-bdaf-44d3-9a8a-7232e2be97ae Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C233BB.0DCDD790" ------_=_NextPart_001_01C233BB.0DCDD790 Content-Type: text/plain; charset="iso-8859-1" Sajjan, I'm happy to help but I think we should take this off line as the IPS is not really for debugging problems. If there is a problem with the spec once we have solved the problem then that should be presented on the IPS. Matthew -----Original Message----- From: Rao, Sajjan [mailto:sajjan_rao@adaptec.com] Sent: Thursday, July 25, 2002 9:58 AM To: BURBRIDGE,MATTHEW (HP-UnitedKingdom,ex2); ips@ece.cmu.edu Subject: RE: Regarding CSG and NSG Matthew, Yes I am setting the T bit to 1, and CSG = 0 and NSG = 1 in my login response. But the initiator seems to drop the connection and trying to set up a new connection. The following is the complete procedure, Login Request T = 1, CSG = 0, NSG = 1 (auth = None, session type = Discovery) Login Response T = 1, CSG = 0, NSG = 1. Should I set the the T = 0, CSG = 1, NSG = x ? -- Sajjan -----Original Message----- From: BURBRIDGE,MATTHEW (HP-UnitedKingdom,ex2) [mailto:matthew_burbridge@hp.com] Sent: Thursday, July 25, 2002 1:53 PM To: 'Rao, Sajjan'; ips@ece.cmu.edu Subject: RE: Regarding CSG and NSG Sajjan, It depends whether the initiator has its T bit set. If T=0 then the initiator is saying that it is security phase and is not yet ready to move to the next phase (NSG=ignore: if T=0, NSG is reserved). This implies that it does want to negotiate security (i.e. authentication). If T=1, it says that is has no more security to negotiate and is ready to move to operational phase (as NSG=1) when the target says it's ready. In the latter of these two options (T=1,CSG=0,NSG=1) then the initiator is giving the target chance to start authentication. Alternatively, if the initiator does not want to negotiate security it can set CSG=1 in the initial login. This removes one message exchange if the target does not want to negotiate security but runs the risk of receiving a login failure if the target does want to negotiate security. If it wants to negotiate parameters then: T=0,CSG=1,NSG=reserved. If it does not want to negotiate text parameters then T=1, CSG=1, NSG=3. In your example I am presuming that T=1 in 1). which is fine. Initiator is giving the target the opportunity to negotiate security but does not wish to start it itself. In 2), the T bit MUST be 0 as it can not be the final login response. The target is informing the initiator that it is happy to enter operational phase (CSG=1). As the T bit must be 0 in 2) NSG = reserved. 1) Suppose the initiator sets T=1, CSG = 0 and NSG = 1 in login request, and says requires no authentication. 2) Can the target set the CSG = 1 and NSG = full feature phase, in its login response? NO It should be 2) Can the target set the T=0, CSG = 1 and NSG = reserved, in its login response? Matthew Burbridge Principal Engineer Nearline NSS Bristol Hewlett Packard Tel: +44 117 312 7010 E-mail: matthewb@bri.hp.com -----Original Message----- From: Rao, Sajjan [mailto:sajjan_rao@adaptec.com] Sent: Thursday, July 25, 2002 5:53 AM To: ips@ece.cmu.edu Subject: Regarding CSG and NSG Hi, I have a couple of questions. 1) Suppose the initiator sets CSG = 0 and NSG = 1 in login request, and says requires no authentication. 2) Can the target set the CSG = 1 and NSG = full feature phase, in its login response? Sajjan ------_=_NextPart_001_01C233BB.0DCDD790 Content-Type: text/html; charset="iso-8859-1"
Sajjan,
 
I'm happy to help but I think we should take this off line as the IPS is not really for debugging problems.  If there is a problem with the spec once we have solved the problem then that should be presented on the IPS.
 
Matthew
-----Original Message-----
From: Rao, Sajjan [mailto:sajjan_rao@adaptec.com]
Sent: Thursday, July 25, 2002 9:58 AM
To: BURBRIDGE,MATTHEW (HP-UnitedKingdom,ex2); ips@ece.cmu.edu
Subject: RE: Regarding CSG and NSG

Matthew,

          Yes I am setting the T bit to 1, and CSG = 0 and NSG = 1  in my login response.

But the initiator seems to drop the connection and trying to set up a new connection.

 

The following is the complete procedure,

Login Request   T = 1, CSG = 0, NSG = 1 (auth = None, session type = Discovery)

Login Response T  = 1, CSG = 0, NSG = 1.

 

Should I set the the T = 0, CSG = 1, NSG = x ?

 

-- Sajjan

 

-----Original Message-----
From: BURBRIDGE,MATTHEW (HP-UnitedKingdom,ex2) [mailto:matthew_burbridge@hp.com]
Sent: Thursday, July 25, 2002 1:53 PM
To: 'Rao, Sajjan'; ips@ece.cmu.edu
Subject: RE: Regarding CSG and NSG

 

Sajjan,

 

It depends whether the initiator has its T bit set.  If T=0 then the initiator is saying that it is security phase and is not yet ready to move to the next phase (NSG=ignore: if T=0, NSG is reserved). This implies that it does want to negotiate security (i.e. authentication).  If T=1, it says that is has no more security to negotiate and is ready to move to operational phase (as NSG=1) when the target says it's ready.  In the latter of these two options (T=1,CSG=0,NSG=1) then the initiator is giving the target chance to start authentication.

 

Alternatively, if the initiator does not want to negotiate security it can set CSG=1 in the initial login.  This removes one message exchange if the target does not want to negotiate security but runs the risk of receiving a login failure if the target does want to negotiate security. If it wants to negotiate parameters then: T=0,CSG=1,NSG=reserved.  If it does not want to negotiate text parameters then T=1, CSG=1, NSG=3.

 

In your example I am presuming that T=1 in 1). which is fine. Initiator is giving the target the opportunity to negotiate security but does not wish to start it itself.  In 2), the T bit MUST be 0 as it can not be the final login response.  The target is informing the initiator that it is happy to enter operational phase (CSG=1).  As the T bit must be 0 in 2) NSG = reserved.

 

    1) Suppose the initiator sets T=1, CSG = 0 and NSG = 1  in login request, and says requires no authentication.

 

    2) Can the target set the CSG = 1 and NSG = full feature phase, in its login response?  NO

 

    It should be

 

 

    2) Can the target set the T=0, CSG = 1 and NSG = reserved, in its login response?

 

 

Matthew Burbridge
Principal Engineer
Nearline NSS Bristol

Hewlett Packard
Tel: +44 117 312 7010
E-mail: matthewb@bri.hp.com


-----Original Message-----
From: Rao, Sajjan [mailto:sajjan_rao@adaptec.com]
Sent: Thursday, July 25, 2002 5:53 AM
To: ips@ece.cmu.edu
Subject: Regarding CSG and NSG

Hi,

    I have a couple of questions.

1) Suppose the initiator sets CSG = 0 and NSG = 1 in login request, and says requires no authentication.

2) Can the target set the CSG = 1 and NSG = full feature phase, in its login response?

 

Sajjan

------_=_NextPart_001_01C233BB.0DCDD790-- ------=_NextPartTM-000-65665870-bdaf-44d3-9a8a-7232e2be97ae-- From owner-ips@ece.cmu.edu Thu Jul 25 06:20:50 2002 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA27786 for ; Thu, 25 Jul 2002 06:20:45 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id g6P9ebU00498 for ips-outgoing; Thu, 25 Jul 2002 05:40:37 -0400 (EDT) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from d12lmsgate.de.ibm.com (d12lmsgate.de.ibm.com [195.212.91.199]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id g6P9eZo00494 for ; Thu, 25 Jul 2002 05:40:35 -0400 (EDT) Received: from d12relay02.de.ibm.com (d12relay02.de.ibm.com [9.165.215.23]) by d12lmsgate.de.ibm.com (8.12.3/8.12.3) with ESMTP id g6P9eSfh047824; Thu, 25 Jul 2002 11:40:28 +0200 Received: from d10hubm1.telaviv.ibm.com (d10ml001.telaviv.ibm.com [9.148.216.55]) by d12relay02.de.ibm.com (8.11.1m3/NCO/VER6.2) with ESMTP id g6P9eRe24590; Thu, 25 Jul 2002 11:40:28 +0200 To: "Rod Harrison" Cc: ips@ece.cmu.edu MIME-Version: 1.0 Subject: RE: iSCSI: v15 R2T and DATA-OUT X-Mailer: Lotus Notes Release 5.0.9 November 16, 2001 From: "Julian Satran" Message-ID: Date: Thu, 25 Jul 2002 12:40:26 +0300 X-MIMETrack: Serialize by Router on D10ML001/10/M/IBM(Release 5.0.9a |January 7, 2002) at 25/07/2002 12:40:27, Serialize complete at 25/07/2002 12:40:27 Content-Type: multipart/alternative; boundary="=_alternative 0034BF41C2256C01_=" Sender: owner-ips@ece.cmu.edu Precedence: bulk This is a multipart message in MIME format. --=_alternative 0034BF41C2256C01_= Content-Type: text/plain; charset="us-ascii" Rod, I will fix the wording - but you mentioned also TTT as part of Data-In - I was just commenting that there is no such thing. As for the issue - if you check it when receiving R2T then you don't have to check it every time you copy it. The word copy is just fine - I just have to make sure that checking on R2T is mandated. Julo "Rod Harrison" 07/25/2002 04:51 AM To: Julian Satran/Haifa/IBM@IBMIL cc: Subject: RE: iSCSI: v15 R2T and DATA-OUT Julian, I think you've misread my message. I was questioning how the initiator should handle the LUN between an R2T and the DATA-OUT(s) that satisfy it. DATA-OUT says copy the LUN from the command PDU, R2T says copy the LUN from the R2T to the DATA-OUT. Which is correct if the R2T contains a different LUN than that in the command PDU? - Rod -----Original Message----- From: Julian Satran [mailto:Julian_Satran@il.ibm.com] Sent: Wednesday, July 24, 2002 5:00 PM To: Rod Harrison Cc: ips@ece.cmu.edu; owner-ips@ece.cmu.edu Subject: Re: iSCSI: v15 R2T and DATA-OUT There is no TTT for data-In. Julo "Rod Harrison" driver.com> cc: Sent by: Subject: iSCSI: v15 R2T and DATA-OUT owner-ips@ece.cmu .edu 07/24/2002 10:24 PM Folks, There is a potential inconsistency in the description of the use of the LUN field in DATA-OUT and R2T in the working v15 draft. 9.7.3 Target Transfer Tag, for DATA-IN last paragraph says ... "If the Target Transfer Tag is provided, then the LUN field MUST hold a valid value and be consistent with whatever was specified with the command;" 9.8.5 Target Transfer Tag, for R2T says ... "The Target Transfer Tag and LUN are copied in the outgoing data PDUs and are used by the target only." Potentially a target could return a different LUN field in the R2T, for perhaps some funky LUN mapping or other internal reason expecting it to be copied to the DATA-OUT as per the R2T text. I suspect we just want to say this is not allowed and the LUN field MUST be the same as the command PDU. Either way I think we need to indicate what is expected of the initiator if the LUN field in the R2T does not match the LUN in the command PDU. Apologies for not spotting this before the end of last call. - Rod --=_alternative 0034BF41C2256C01_= Content-Type: text/html; charset="us-ascii"
Rod,

I will fix the wording  - but you mentioned also TTT as part of Data-In - I was just commenting that there is no such thing.
As for the issue - if you check it when receiving R2T then you don't have to check it every time you copy it.
The word copy is just fine - I just have to make sure that checking on R2T is mandated.

Julo


"Rod Harrison" <rod.harrison@windriver.com>

07/25/2002 04:51 AM

       
        To:        Julian Satran/Haifa/IBM@IBMIL
        cc:        <ips@ece.cmu.edu>
        Subject:        RE: iSCSI: v15 R2T and DATA-OUT

       


Julian,

                I think you've misread my message. I was questioning how the
initiator should handle the LUN between an R2T and the DATA-OUT(s)
that satisfy it.

                DATA-OUT says copy the LUN from the command PDU, R2T says copy the
LUN from the R2T to the DATA-OUT. Which is correct if the R2T contains
a different LUN than that in the command PDU?

                - Rod


-----Original Message-----
From: Julian Satran [mailto:Julian_Satran@il.ibm.com]
Sent: Wednesday, July 24, 2002 5:00 PM
To: Rod Harrison
Cc: ips@ece.cmu.edu; owner-ips@ece.cmu.edu
Subject: Re: iSCSI: v15 R2T and DATA-OUT


There is no TTT for data-In. Julo



                     "Rod Harrison"
                     <rod.harrison@win        To:
<ips@ece.cmu.edu>
                     driver.com>              cc:
                     Sent by:                 Subject:  iSCSI: v15
R2T and DATA-OUT
                     owner-ips@ece.cmu
                     .edu


                     07/24/2002 10:24
                     PM





Folks,

            There is a potential inconsistency in the description of
the
use of
the LUN field in DATA-OUT and R2T in the working v15 draft.

            9.7.3 Target Transfer Tag, for DATA-IN last paragraph
says ...

            "If the Target Transfer Tag is provided, then the LUN
field
MUST hold
a valid value and be consistent with whatever was specified with the
command;"

            9.8.5 Target Transfer Tag, for R2T says ...

            "The Target Transfer Tag and LUN are copied in the
outgoing
data PDUs
and are used by the target only."

            Potentially a target could return a different LUN field
in the
R2T,
for perhaps some funky LUN mapping or other internal reason expecting
it to be copied to the DATA-OUT as per the R2T text. I suspect we just
want to say this is not allowed and the LUN field MUST be the same as
the command PDU.

            Either way I think we need to indicate what is expected
of the
initiator if the LUN field in the R2T does not match the LUN in the
command PDU.

            Apologies for not spotting this before the end of last
call.

            - Rod

--=_alternative 0034BF41C2256C01_=-- From owner-ips@ece.cmu.edu Thu Jul 25 10:03:25 2002 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA04595 for ; Thu, 25 Jul 2002 10:03:20 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id g6PDMqC08485 for ips-outgoing; Thu, 25 Jul 2002 09:22:52 -0400 (EDT) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from mail.ivivity.com ([64.238.111.99]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id g6PDMoo08481 for ; Thu, 25 Jul 2002 09:22:50 -0400 (EDT) Received: by ATLOPS with Internet Mail Service (5.5.2653.19) id ; Thu, 25 Jul 2002 09:22:34 -0400 Message-ID: From: Sanjay Goyal To: "'Julian Satran'" , Rod Harrison Cc: ips@ece.cmu.edu Subject: RE: iSCSI: v15 R2T and DATA-OUT Date: Thu, 25 Jul 2002 09:22:33 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C233DE.55E989C0" Sender: owner-ips@ece.cmu.edu Precedence: bulk This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_001_01C233DE.55E989C0 Content-Type: text/plain; charset="iso-8859-1" Hi if I read draft-ietf-ips-iscsi-15-working.pdf from Julian's site on page 159, Data-In does have TTT field for the posAck case, when A bit is set to 1. Regards Sanjay Goyal -----Original Message----- From: Julian Satran [mailto:Julian_Satran@il.ibm.com] Sent: Thursday, July 25, 2002 5:40 AM To: Rod Harrison Cc: ips@ece.cmu.edu Subject: RE: iSCSI: v15 R2T and DATA-OUT Rod, I will fix the wording - but you mentioned also TTT as part of Data-In - I was just commenting that there is no such thing. As for the issue - if you check it when receiving R2T then you don't have to check it every time you copy it. The word copy is just fine - I just have to make sure that checking on R2T is mandated. Julo "Rod Harrison" 07/25/2002 04:51 AM To: Julian Satran/Haifa/IBM@IBMIL cc: Subject: RE: iSCSI: v15 R2T and DATA-OUT Julian, I think you've misread my message. I was questioning how the initiator should handle the LUN between an R2T and the DATA-OUT(s) that satisfy it. DATA-OUT says copy the LUN from the command PDU, R2T says copy the LUN from the R2T to the DATA-OUT. Which is correct if the R2T contains a different LUN than that in the command PDU? - Rod -----Original Message----- From: Julian Satran [mailto:Julian_Satran@il.ibm.com] Sent: Wednesday, July 24, 2002 5:00 PM To: Rod Harrison Cc: ips@ece.cmu.edu; owner-ips@ece.cmu.edu Subject: Re: iSCSI: v15 R2T and DATA-OUT There is no TTT for data-In. Julo "Rod Harrison" driver.com> cc: Sent by: Subject: iSCSI: v15 R2T and DATA-OUT owner-ips@ece.cmu .edu 07/24/2002 10:24 PM Folks, There is a potential inconsistency in the description of the use of the LUN field in DATA-OUT and R2T in the working v15 draft. 9.7.3 Target Transfer Tag, for DATA-IN last paragraph says ... "If the Target Transfer Tag is provided, then the LUN field MUST hold a valid value and be consistent with whatever was specified with the command;" 9.8.5 Target Transfer Tag, for R2T says ... "The Target Transfer Tag and LUN are copied in the outgoing data PDUs and are used by the target only." Potentially a target could return a different LUN field in the R2T, for perhaps some funky LUN mapping or other internal reason expecting it to be copied to the DATA-OUT as per the R2T text. I suspect we just want to say this is not allowed and the LUN field MUST be the same as the command PDU. Either way I think we need to indicate what is expected of the initiator if the LUN field in the R2T does not match the LUN in the command PDU. Apologies for not spotting this before the end of last call. - Rod ------_=_NextPart_001_01C233DE.55E989C0 Content-Type: text/html; charset="iso-8859-1"
Hi
 if I read  draft-ietf-ips-iscsi-15-working.pdf
 from Julian's site
 
on page 159,
 Data-In does have TTT field for the posAck case, when A bit is set to 1.
 

Regards
Sanjay Goyal

-----Original Message-----
From: Julian Satran [mailto:Julian_Satran@il.ibm.com]
Sent: Thursday, July 25, 2002 5:40 AM
To: Rod Harrison
Cc: ips@ece.cmu.edu
Subject: RE: iSCSI: v15 R2T and DATA-OUT


Rod,

I will fix the wording  - but you mentioned also TTT as part of Data-In - I was just commenting that there is no such thing.
As for the issue - if you check it when receiving R2T then you don't have to check it every time you copy it.
The word copy is just fine - I just have to make sure that checking on R2T is mandated.

Julo


"Rod Harrison" <rod.harrison@windriver.com>

07/25/2002 04:51 AM

       
        To:        Julian Satran/Haifa/IBM@IBMIL
        cc:        <ips@ece.cmu.edu>
        Subject:        RE: iSCSI: v15 R2T and DATA-OUT

       


Julian,

                I think you've misread my message. I was questioning how the
initiator should handle the LUN between an R2T and the DATA-OUT(s)
that satisfy it.

                DATA-OUT says copy the LUN from the command PDU, R2T says copy the
LUN from the R2T to the DATA-OUT. Which is correct if the R2T contains
a different LUN than that in the command PDU?

                - Rod


-----Original Message-----
From: Julian Satran [mailto:Julian_Satran@il.ibm.com]
Sent: Wednesday, July 24, 2002 5:00 PM
To: Rod Harrison
Cc: ips@ece.cmu.edu; owner-ips@ece.cmu.edu
Subject: Re: iSCSI: v15 R2T and DATA-OUT


There is no TTT for data-In. Julo



                     "Rod Harrison"
                     <rod.harrison@win        To:
<ips@ece.cmu.edu>
                     driver.com>              cc:
                     Sent by:                 Subject:  iSCSI: v15
R2T and DATA-OUT
                     owner-ips@ece.cmu
                     .edu


                     07/24/2002 10:24
                     PM





Folks,

            There is a potential inconsistency in the description of
the
use of
the LUN field in DATA-OUT and R2T in the working v15 draft.

            9.7.3 Target Transfer Tag, for DATA-IN last paragraph
says ...

            "If the Target Transfer Tag is provided, then the LUN
field
MUST hold
a valid value and be consistent with whatever was specified with the
command;"

            9.8.5 Target Transfer Tag, for R2T says ...

            "The Target Transfer Tag and LUN are copied in the
outgoing
data PDUs
and are used by the target only."

            Potentially a target could return a different LUN field
in the
R2T,
for perhaps some funky LUN mapping or other internal reason expecting
it to be copied to the DATA-OUT as per the R2T text. I suspect we just
want to say this is not allowed and the LUN field MUST be the same as
the command PDU.

            Either way I think we need to indicate what is expected
of the
initiator if the LUN field in the R2T does not match the LUN in the
command PDU.

            Apologies for not spotting this before the end of last
call.

            - Rod







------_=_NextPart_001_01C233DE.55E989C0-- From owner-ips@ece.cmu.edu Thu Jul 25 10:52:30 2002 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA06669 for ; Thu, 25 Jul 2002 10:52:30 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id g6PE98b10776 for ips-outgoing; Thu, 25 Jul 2002 10:09:08 -0400 (EDT) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from mail2.microsoft.com (mail2.microsoft.com [131.107.3.124]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id g6PE96o10772 for ; Thu, 25 Jul 2002 10:09:06 -0400 (EDT) Received: from INET-VRS-02.redmond.corp.microsoft.com ([157.54.8.110]) by mail2.microsoft.com with Microsoft SMTPSVC(5.0.2195.4905); Thu, 25 Jul 2002 07:09:00 -0700 Received: from 157.54.8.155 by INET-VRS-02.redmond.corp.microsoft.com (InterScan E-Mail VirusWall NT); Thu, 25 Jul 2002 07:09:00 -0700 Received: from red-imc-01.redmond.corp.microsoft.com ([157.54.9.102]) by inet-hub-04.redmond.corp.microsoft.com with Microsoft SMTPSVC(5.0.2195.2966); Thu, 25 Jul 2002 07:08:59 -0700 Received: from win-imc-01.wingroup.windeploy.ntdev.microsoft.com ([157.54.0.39]) by red-imc-01.redmond.corp.microsoft.com with Microsoft SMTPSVC(5.0.2195.4905); Thu, 25 Jul 2002 07:08:59 -0700 Received: from win-msg-03.wingroup.windeploy.ntdev.microsoft.com ([157.54.0.198]) by win-imc-01.wingroup.windeploy.ntdev.microsoft.com with Microsoft SMTPSVC(6.0.3604.0); Thu, 25 Jul 2002 07:08:59 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.0.6249.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="------------InterScan_NT_MIME_Boundary" Subject: iSCSI: Notifications on error Date: Thu, 25 Jul 2002 07:08:58 -0700 Message-ID: Thread-Topic: iSCSI: Notifications on error Thread-Index: AcIz5NFHrSGT2zwZSB6IZCR2rc8jmg== From: "Lakshmi Ramasubramanian" To: Cc: "Joe Dai" X-OriginalArrivalTime: 25 Jul 2002 14:08:59.0745 (UTC) FILETIME=[D2877D10:01C233E4] Sender: owner-ips@ece.cmu.edu Precedence: bulk This is a multi-part message in MIME format. --------------InterScan_NT_MIME_Boundary Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C233E4.D1B5528C" ------_=_NextPart_001_01C233E4.D1B5528C Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable If a command fails at the SCSI layer (on the target side), the driver can freeze the queue, and fail all requests till the queue is unfreezed. The target needs to tell the initiator about the queue freeze condition=20 so that an initiator can issue an unfreeze request. =20 Currently there is no way (as much as I could understand) in the spec to do such a thing. We can use vendor specific Async messages, but that will cause interop problems. =20 Is it reasonable to request for a mechanism to do the above in the iSCSI spec? =20 thanks! -lakshmi ------_=_NextPart_001_01C233E4.D1B5528C Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Message
If a command fails at the SCSI layer (on the target side), the=20 driver
can freeze the queue, and fail all requests till = the queue=20 is unfreezed.
The target needs to tell the initiator about the=20 queue freeze condition
so that an initiator can issue an=20 unfreeze request.
 
Currently there is no way (as much as I could understand) in = the=20 spec
to do such a thing. We can use vendor specific Async messages, = but=20 that
will cause interop problems.
 
Is it reasonable to request for a mechanism to do the above in = the=20 iSCSI
spec?
 
thanks!
 -lakshmi
=00 ------_=_NextPart_001_01C233E4.D1B5528C-- --------------InterScan_NT_MIME_Boundary-- From owner-ips@ece.cmu.edu Thu Jul 25 10:52:36 2002 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA06685 for ; Thu, 25 Jul 2002 10:52:35 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id g6PEZln12391 for ips-outgoing; Thu, 25 Jul 2002 10:35:47 -0400 (EDT) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from mailhub.lss.emc.com (xdch.emc.com [168.159.1.79]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id g6PEZjo12386 for ; Thu, 25 Jul 2002 10:35:45 -0400 (EDT) Received: from emc.com (emcmail.lss.emc.com [168.159.48.78]) by mailhub.lss.emc.com (Switch-2.2.0/Switch-2.2.0) with ESMTP id g6PEZVY12373; Thu, 25 Jul 2002 10:35:32 -0400 (EDT) Received: from mxic1.isus.emc.com ([168.159.129.100]) by emc.com (8.10.1/8.10.1) with ESMTP id g6PEZU703214; Thu, 25 Jul 2002 10:35:31 -0400 (EDT) Received: by MXIC1 with Internet Mail Service (5.5.2653.19) id ; Thu, 25 Jul 2002 10:33:19 -0400 Message-ID: <277DD60FB639D511AC0400B0D068B71E0564C0ED@CORPMX14> From: Black_David@emc.com To: nramas@windows.microsoft.com, ips@ece.cmu.edu Cc: joedai@windows.microsoft.com Subject: RE: iSCSI: Notifications on error Date: Thu, 25 Jul 2002 10:33:10 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-ips@ece.cmu.edu Precedence: bulk > If a command fails at the SCSI layer (on the target side), the driver > can freeze the queue, and fail all requests till the queue is unfreezed. > The target needs to tell the initiator about the queue freeze condition > so that an initiator can issue an unfreeze request. > Currently there is no way (as much as I could understand) in the spec > to do such a thing. We can use vendor specific Async messages, but that > will cause interop problems. SCSI and iSCSI already provide the means to do so -- "fails at the SCSI layer (on the target side)" should mean "results in a CHECK CONDITION" and a CA (Contingent Allegiance) state. iSCSI deals with this by requiring Autosense (MUST implement, MUST use) - that prevents queue freezing, as the sense information comes back in the SCSI Response PDU and the target continues execution, see Section 5.8.4.3 of SAM-2. A target that returns sense via Autosense but still freezes execution is broken. A quick reminder to target implementers - when working from a (parallel) SCSI device that does CA in the classic manner (i.e., freezes execution and waits for the initiator to Request Sense), Autosense MUST be implemented in the iSCSI target as the iSCSI initiator will not issue the Request Sense command needed to unfreeze things. This is IMPORTANT! The other obvious way to "freeze the queue" on the target side is ACA (Auto Contingent Allegiance), but this only happens when the initiator asks for it (look for the NACA bit in the appropriate SCSI specs) and there's a specific iSCSI task management operation (mandated by SAM-2) to clear an ACA condition - see Section 9.5 - an initiator that is using ACA will know that it has to issue the CLEAR ACA operation, and it will know this based on the CHECK CONDITION info that comes back in the SCSI Response. Both CA and ACA are handled by the iSCSI spec. Putting in vendor-specific async messages to handle them would be *very* wrong. If this doesn't cover the case of concern, please supply more information/details. 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 --------------------------------------------------- From owner-ips@ece.cmu.edu Thu Jul 25 10:53:09 2002 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA06711 for ; Thu, 25 Jul 2002 10:53:03 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id g6PEZFW12355 for ips-outgoing; Thu, 25 Jul 2002 10:35:15 -0400 (EDT) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from cygnus.equallogic.com (cygnus.equallogic.com [65.170.102.10]) by ece.cmu.edu (8.11.0/8.10.2) with SMTP id g6PEZDo12350 for ; Thu, 25 Jul 2002 10:35:13 -0400 (EDT) Received: from cygnus.equallogic.com (localhost.localdomain [127.0.0.1]) by cygnus.equallogic.com (8.11.6/8.11.6) with ESMTP id g6PEZ0C06765 for ; Thu, 25 Jul 2002 10:35:00 -0400 Received: from deneb.dev.equallogic.com (deneb.dev.equallogic.com [172.16.1.99]) by cygnus.equallogic.com (8.11.6/8.11.6) with ESMTP id g6PEZ0Q06756; Thu, 25 Jul 2002 10:35:00 -0400 Received: from PKONING.equallogic.com (localhost.localdomain [127.0.0.1]) by deneb.dev.equallogic.com (8.11.6/8.11.6) with ESMTP id g6PEYxM03477; Thu, 25 Jul 2002 10:34:59 -0400 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <15680.3220.733000.433745@gargle.gargle.HOWL> Date: Thu, 25 Jul 2002 10:35:00 -0400 From: Paul Koning To: rod.harrison@windriver.com Cc: ips@ece.cmu.edu Subject: RE: iSCSI: v15 R2T and DATA-OUT References: X-Mailer: VM 6.95 under 21.4 (patch 3) "Academic Rigor" XEmacs Lucid Sender: owner-ips@ece.cmu.edu Precedence: bulk Content-Transfer-Encoding: 7bit Excerpt of message (sent 24 July 2002) by Rod Harrison: > > OK, it's been a long day. Let me try this one more time. > > I was write (almost) first time but I meant DATA-OUT instead of > DATA-IN. Here's what I meant to say ... > > There is a potential inconsistency in the description of the use of > the LUN field in DATA-OUT and R2T in the working v15 draft. > > 9.7.3 Target Transfer Tag, for DATA-OUT last paragraph says ... > > "If the Target Transfer Tag is provided, then the LUN field MUST hold > a valid value and be consistent with whatever was specified with the > command;" > > 9.8.5 Target Transfer Tag, for R2T says ... > > "The Target Transfer Tag and LUN are copied in the outgoing data PDUs > and are used by the target only." > > Potentially a target could return a different LUN field in the R2T, > for perhaps some funky LUN mapping or other internal reason expecting > it to be copied to the DATA-OUT as per the R2T text. I think that's a very bad idea and should not be permitted. If someone wants to do LUN mapping, that's fine, so long as it's transparent to the initiator. To map a LUN and then let the mapped number leak out to the initiator is broken. > I think we need to indicate what is expected of the initiator if the > LUN field in the R2T does not match the LUN in the command PDU. Given that the subject was brought up I tend to agree that the spec should say something. I would prefer it to say that this is a protocol error. paul From owner-ips@ece.cmu.edu Thu Jul 25 11:33:25 2002 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA08585 for ; Thu, 25 Jul 2002 11:33:24 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id g6PEi9t12917 for ips-outgoing; Thu, 25 Jul 2002 10:44:09 -0400 (EDT) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from ietf.org (odin.ietf.org [132.151.1.176]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id g6PC7jo05673 for ; Thu, 25 Jul 2002 08:07:49 -0400 (EDT) Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA29779; Thu, 25 Jul 2002 08:06:23 -0400 (EDT) Message-Id: <200207251206.IAA29779@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; Cc: ips@ece.cmu.edu From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-ietf-ips-security-14.txt Date: Thu, 25 Jul 2002 08:06:23 -0400 Sender: owner-ips@ece.cmu.edu Precedence: bulk --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the IP Storage Working Group of the IETF. Title : Securing Block Storage Protocols over IP Author(s) : B. Aboba et al. Filename : draft-ietf-ips-security-14.txt Pages : 68 Date : 24-Jul-02 This document discusses how to secure block storage and storage discovery protocols running over IP. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-ips-security-14.txt To remove yourself from the IETF Announcement list, send a message to ietf-announce-request with the word unsubscribe in the body of the message. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-ips-security-14.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-ips-security-14.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <20020724142808.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-ips-security-14.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-ips-security-14.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <20020724142808.I-D@ietf.org> --OtherAccess-- --NextPart-- From owner-ips@ece.cmu.edu Thu Jul 25 12:15:57 2002 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA10497 for ; Thu, 25 Jul 2002 12:15:52 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id g6PFdtl16772 for ips-outgoing; Thu, 25 Jul 2002 11:39:55 -0400 (EDT) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from cygnus.equallogic.com (cygnus.equallogic.com [65.170.102.10]) by ece.cmu.edu (8.11.0/8.10.2) with SMTP id g6PFPfo15787 for ; Thu, 25 Jul 2002 11:25:41 -0400 (EDT) Received: from cygnus.equallogic.com (localhost.localdomain [127.0.0.1]) by cygnus.equallogic.com (8.11.6/8.11.6) with ESMTP id g6PFPaC07673 for ; Thu, 25 Jul 2002 11:25:36 -0400 Received: from deneb.dev.equallogic.com (deneb.dev.equallogic.com [172.16.1.99]) by cygnus.equallogic.com (8.11.6/8.11.6) with ESMTP id g6PFPZQ07661; Thu, 25 Jul 2002 11:25:35 -0400 Received: from PKONING.equallogic.com (localhost.localdomain [127.0.0.1]) by deneb.dev.equallogic.com (8.11.6/8.11.6) with ESMTP id g6PFPY404769; Thu, 25 Jul 2002 11:25:35 -0400 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <15680.6255.797000.962608@gargle.gargle.HOWL> Date: Thu, 25 Jul 2002 11:25:35 -0400 From: Paul Koning To: Black_David@emc.com Cc: bernard_aboba@hotmail.com, ips@ece.cmu.edu Subject: Re: iSCSI: SRP groups in Security-14 strawman References: <277DD60FB639D511AC0400B0D068B71E0564C0E2@CORPMX14> X-Mailer: VM 6.95 under 21.4 (patch 3) "Academic Rigor" XEmacs Lucid Sender: owner-ips@ece.cmu.edu Precedence: bulk Content-Transfer-Encoding: 7bit > Let me start with the following issue that Vince Cavanna raised: > > > Sounds good, but I don't understand the motivation to use any primes > > other than those from IKE when we know those primes are certifiable > > and that a generator suitable for SRP can be easily and deterministically > > determined. Is there value in giving the user multiple choices for primes > > of a given size? > > I think the answer to Vince's second question is "no", but I also > think that since the SRP primes have been proven prime and have been > widely distributed with SRP software from Stanford, we should > choose them over the IKE primes. You mentioned a short while ago that Tero Kivinen had undertaken to prove the primality of the SRP primes, but I don't remember seeing a followup report on that. So until that is done, the IKE primes are proven and the SRP primes are not yet proven. > The 2048 bit size of the largest > SRP prime also appears to be convenient - see below. This suggests > deleting the Oakley group 2, the 1536-bit [MODP] group, and the > 2048-bit [MODP] group since there are SRP groups with primes of > the same sizes. If I remember right, there are performance benefits in some bignum implementations to having a modulus with a bunch of leading and/or trailing 1 bits. The IKE primes are constructed to achieve that, the SRP primes are not. In other words, because of that construction there IS value in allowing those primes; the IKE primes are NOT superfluous and should be allowed whether or not there are primes in the SRP reference software package of the same size. In other words, keep the 1024, 1536, and 2048 bit MODP primes, using the generator that Tom Wu identified. If you feel strongly that there should be only one prime modulus of any given size, then I would argue that the preference should be the IKE primes because of their construction. > For the remaining MODP groups, I suggest that we pick a single > acceptable generator for simplicity (i.e., that generator MUST > be used with the corresponding prime, other generators MUST NOT > be used): > > 5 for the 3072-bit, 4096-bit, and 6144-bit [MODP] groups. > 19 for the 8192-bit [MODP] group. > > The rationale for this is the same as above - there is no value in > giving the user multiple choices for generators. Tom Wu should be > cited as the source of the acceptability determination for these > generators. I agree that only a single generator should be picked, so with the proviso that we should also list the first acceptable generator for the other IKE primes, your proposal sounds good. > Finally, we need some implementation requirements. There are a > couple of issues here: > > (1) For SRP, the target announces the prime and generator. If the > initiator doesn't like them, it closes the connection - that's an > invitation to interoperability headaches. The cleanest solution > to this is to negotiate the group: > - Instead of the target sending SRP_N and SRP_g, the target > sends SRP_GROUP= where possible values > are SRP-768, SRP-1024, etc. and MODP-3072, MODP-4096, etc. > - The initiator returns SRP_GROUP= along with > SRP_A. > Not only is that cleaner, it also takes out a bignum without adding a > round trip. The SRP_GROUP values probably need to go into an IANA > registry, with a rule that the WG (or the ADs if the WG no longer > exists) control additions. The alternative of folding the group > selection into the AuthMethod value (e.g., AuthMethod=SRP_MODP-4096) > seems clumsy by comparison and doesn't save a round trip. I like the approach of proposing a group identifier. That's also (roughly) what IKE does. > (2) We need some requirements on what MUST be supported for > interoperability when SRP is supported. I hesitate to require > support for all the groups up to the 8192-bit MODP group. A glance > at draft-orman-public-key-lengths-05.txt suggests that the SRP > primes are adequate for now as the 1536-bit and 2048-bit primes > bracket the 96 bits of randomness that we require of CHAP secrets. > > In practice, I think we need to allow local security policy to > disallow use of smaller primes, so the requirements would be > something like: > > - MUST support all the SRP groups (up to 2048 bits) > - MAY support the MODP groups > - Target MUST offer SRP-2048 as one of the possible values of > SRP_GROUP and SHOULD offer all supported groups that are > allowed by local security policy. I would tweak this slightly. 1. Given the high cost of bignum arithmetic in software, I'd prefer the mandatory lenghts to be smaller. Orman's document says that a modulus size of 1553 matches a brute force strength of 90 bits. Given the amount of approximation in all that analysis, I'd say that we should set 1536 as the largest mandated size. 2. For the reason given earlier, mandate the MODP groups (rather than the SRP groups) up to the chosen mandatory size. I'd propose 1536, but if 2048 sticks then make it MODP-2048. Reason: these are just as good as the SRP reference primes, and may be more efficient if your bignum implementation takes advantage of the clump of 1 bits at start and end. 3. "... MUST offer" -- it doesn't have to be the first choice, right? I want to make sure that a customer who likes the cryptography underlying SRP but is worried about the performance of login (given a software implementation) is allowed to use, say, a 1024 bit modulus by making that the first choice. paul From owner-ips@ece.cmu.edu Thu Jul 25 12:20:25 2002 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA10726 for ; Thu, 25 Jul 2002 12:20:20 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id g6PFUns16140 for ips-outgoing; Thu, 25 Jul 2002 11:30:49 -0400 (EDT) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from e2.ny.us.ibm.com (e2.ny.us.ibm.com [32.97.182.102]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id g6PFUlo16134 for ; Thu, 25 Jul 2002 11:30:47 -0400 (EDT) Received: from northrelay02.pok.ibm.com (northrelay02.pok.ibm.com [9.56.224.150]) by e2.ny.us.ibm.com (8.12.2/8.12.2) with ESMTP id g6PFUce8144292; Thu, 25 Jul 2002 11:30:38 -0400 Received: from d27ml601.rchland.ibm.com (d27ml601.rchland.ibm.com [9.10.226.13]) by northrelay02.pok.ibm.com (8.12.3/NCO/VER6.3) with ESMTP id g6PFUZs4021762; Thu, 25 Jul 2002 11:30:35 -0400 Subject: Re: IPS-ALL: FC Mgmt MIB WG Last Call To: "Elizabeth G. Rodriguez" Cc: ips@ece.cmu.edu, owner-ips@ece.cmu.edu, t11_3@mail.t11.org X-Mailer: Lotus Notes Release 5.0.5 September 22, 2000 Message-ID: From: Duane Baldwin Date: Thu, 25 Jul 2002 10:30:22 -0500 X-MIMETrack: Serialize by Router on d27ml601/27/M/IBM(Build V60_05012002|May 01, 2002) at 07/25/2002 10:30:36 AM MIME-Version: 1.0 Content-type: multipart/related; Boundary="0__=09BBE692DFC0F7468f9e8a93df938690918c09BBE692DFC0F746" Sender: owner-ips@ece.cmu.edu Precedence: bulk --0__=09BBE692DFC0F7468f9e8a93df938690918c09BBE692DFC0F746 Content-type: multipart/alternative; Boundary="1__=09BBE692DFC0F7468f9e8a93df938690918c09BBE692DFC0F746" --1__=09BBE692DFC0F7468f9e8a93df938690918c09BBE692DFC0F746 Content-type: text/plain; charset=US-ASCII Hi, Here is the first of several issues/questions: Relative to the initial draft of this MIB (draft-ietf-ipfc-fcmgmt-int-mib- 07.txt), the object "connUnitUrl" has been removed. No alternative is suggested for this MIB in the text. Are there known alternatives for this object? If so, this information should be included in the MIB text. If there is no alternative, then this is a significant issue. Management applications may use this value to enable the launch of the FC device element manager. Thanks, Duane Baldwin -- "Elizabeth G. Rodriguez" Rodriguez@123mail.net> cc: Sent by: owner-ips@ece. Subject: IPS-ALL: FC Mgmt MIB WG Last Call cmu.edu 07/17/02 03:01 AM All, We would like to announce IPS Working Group Last call for the Fibre Channel Management MIB. Details: Document: Fibre Channel Management MIB URL: http://www.ietf.org/internet-drafts/draft-ietf-ips-fcmgmt-mib-02.txt Last call period: 2 Weeks Submit comments no later than: Wednesday, July 31, 2002 at 5pm EST Editor: Keith McCloghrie (kzm@cisco.com) Please submit editorial comments directly to Keith, with copy to David Black (black_david@emc.com), and Elizabeth Rodriguez( ElizabethRodriguez@ieee.org) Submit technical comments to the IPS mailing list (ips@ece.cmu.edu) Editorial comments may be resolved directly by the editor of the document, but any technical issues must be discussed on the IPS reflector. Thanks Elizabeth Rodriguez & David Black IPS co-chairs --1__=09BBE692DFC0F7468f9e8a93df938690918c09BBE692DFC0F746 Content-type: text/html; charset=US-ASCII Content-Disposition: inline

Hi,

Here is the first of several issues/questions:

Relative to the initial draft of this MIB (draft-ietf-ipfc-fcmgmt-int-mib-07.txt), the object "connUnitUrl" has been removed. No alternative is suggested for this MIB in the text. Are there known alternatives for this object? If so, this information should be included in the MIB text. If there is no alternative, then this is a significant issue. Management applications may use this value to enable the launch of the FC device element manager.


Thanks, Duane Baldwin

--

"Elizabeth G. Rodriguez" <Elizabeth.G.Rodriguez@123mail.net>




          "Elizabeth G. Rodriguez" <Elizabeth.G.Rodriguez@123mail.net>
          Sent by: owner-ips@ece.cmu.edu

          07/17/02 03:01 AM



To: <ips@ece.cmu.edu>
cc: <t11_3@mail.t11.org>
Subject: IPS-ALL: FC Mgmt MIB WG Last Call


All,

We would like to announce IPS Working Group Last call for the Fibre Channel Management MIB.

Details:

Document: Fibre Channel Management MIB
URL: http://www.ietf.org/internet-drafts/draft-ietf-ips-fcmgmt-mib-02.txt

Last call period: 2 Weeks
Submit comments no later than: Wednesday, July 31, 2002 at 5pm EST

Editor: Keith McCloghrie (kzm@cisco.com)

Please submit editorial comments directly to Keith, with copy to David Black (black_david@emc.com), and Elizabeth Rodriguez(ElizabethRodriguez@ieee.org)
Submit technical comments to the IPS mailing list (ips@ece.cmu.edu)

Editorial comments may be resolved directly by the editor of the document, but any technical issues must be discussed on the IPS reflector.

Thanks

Elizabeth Rodriguez & David Black
IPS co-chairs


--1__=09BBE692DFC0F7468f9e8a93df938690918c09BBE692DFC0F746-- --0__=09BBE692DFC0F7468f9e8a93df938690918c09BBE692DFC0F746 Content-type: image/gif; name="graycol.gif" Content-Disposition: inline; filename="graycol.gif" Content-ID: <10__=09BBE692DFC0F7468f9e8a93df938@us.ibm.com> Content-transfer-encoding: base64 Content-Transfer-Encoding: base64 R0lGODlhEAAQAKECAMzMzAAAAP///wAAACH5BAEAAAIALAAAAAAQABAAAAIXlI+py+0PopwxUbpu ZRfKZ2zgSJbmSRYAIf4fT3B0aW1pemVkIGJ5IFVsZWFkIFNtYXJ0U2F2ZXIhAAA7 --0__=09BBE692DFC0F7468f9e8a93df938690918c09BBE692DFC0F746 Content-type: image/gif; name="ecblank.gif" Content-Disposition: inline; filename="ecblank.gif" Content-ID: <20__=09BBE692DFC0F7468f9e8a93df938@us.ibm.com> Content-transfer-encoding: base64 Content-Transfer-Encoding: base64 R0lGODlhEAABAIAAAAAAAP///yH5BAEAAAEALAAAAAAQAAEAAAIEjI8ZBQA7 --0__=09BBE692DFC0F7468f9e8a93df938690918c09BBE692DFC0F746 Content-type: image/gif; name="pic28198.gif" Content-Disposition: inline; filename="pic28198.gif" Content-ID: <30__=09BBE692DFC0F7468f9e8a93df938@us.ibm.com> Content-transfer-encoding: base64 Content-Transfer-Encoding: base64 R0lGODlhWABDALP/AAAAAK04Qf79/o+Gm7WuwlNObwoJFCsoSMDAwGFsmIuezf///wAAAAAAAAAA AAAAACH5BAEAAAgALAAAAABYAEMAQAT/EMlJq704682770RiFMRinqggEUNSHIchG0BCfHhOjAuh EDeUqTASLCbBhQrhG7xis2j0lssNDopE4jfIJhDaggI8YB1sZeZgLVA9YVCpnGagVjV171aRVrYR RghXcAGFhoUETwYxcXNyADJ3GlcSKGAwLwllVC1vjIUHBWsFilKQdI8GA5IcpApeJQt8L09lmgkH LZikoU5wjqcyAMMFrJIDPAKvCFletKSev1HBw8KrxtjZ2tvc3d5VyKtCKW3jfz4uMKmq3xu4N0nK BVoJQmx2LGVOmrqNjjJf2hHAQo/eDwJGTKhQMcgQEEAnEjFS98+RnW3smGkZU6ncCWav/4wYOnAI TihRL/4FEwbp28BXMMcoscQCVxlepL4IGDSCyJyVQOu0o7CjmLN50OZlqWmyFy5/6yBBuji0AxFR M00oQAqNIstqI6qKHUsWRAEAvagsmfUEAImyxgbmUpJk3IklNUtJOUAVLoUr1+wqDGTE4zk+T6FG uQb3SizBCwatiiUgCBN8vrz+zFjVyQ8FWkOlg4NQiZMB5QS8QO3mpOaKnL0Z2EKvNMSILEThKhCg zMKPVxYJh23qm9KNW7pArPynMqZDiErsTMqI+LRi3QAgkFUbXpuFKhSYZALd0O5RKa2z9EYKBbpb qxIKsjUPRgD7I2XYV6wyrOw92ykExP8NW4URhknC5dKGE4v4NENQj2jXjmfNgOZDaXb5glRmXQ33 YEWQYNcZFnrYcIQLNzyTFDQNkXIff0ExVlY4srziQk43inZgL4rwxxINMvpFFAz1KOODHiu+4aEw NEjFl5B3JIKWKF3k6I9bfUGp5ZZcdunll5IA4cuHvQQJ5gcsoCWOOUwgltIwAKRxJgbIkJAQZEq0 2YliZnpZZ4BH3CnYOXldOUOfQoYDqF1LFHbXCrO8xmRsfoXDXJ6ChjCAH3QlhJcT6VWE6FCkfCco CgrMFsROrIEX3o2whVjWDjoJccN3LdggSGXLCdLEgHr1lyU3O3QxhgohNKXJCWv8JQr/PDdaqd6w 2rj1inLiGeiCJoDspAoQlYE6QWLSECehcWIYxIQES6zhbn1iImTHEQyqJ4eIxJJoUBc+3CbBuwZE V5cJPPkIjFDdeEabQbd6WgICTxiiz0f5dBKquXF6k4senwEhYGnKEFJeGrxUZy8dB8gmAXI/sPvH ESfCwVt5hTgYiqQqtdRNHQIU1PJ33ZqmzgE90OwLaoJcnMop1WiMmgkPHQRIrwgFuNV90A3doNKT mrKIN07AnGcI9BQjhCBN4RfA1qIZnMqorJCogKfGQnxSCDilTVIA0yl5ciTovgLuBDKFUDE9aQcw 9SA+rjSNf9/M1gxrj6VwDTS0IUSElMzBfsj0NFXR2kwsV1A5IF1grLgLL/r1R40BZEnuBWgmQEyb jqRwSAt6bqMCOFkvKFN2GPPkUzIm/SCF8z8pVzpbjVnMsy0vOr1hw3SaSRUhpY09v0z0J1FnwzPl fmh+xl4WtR0zGu24I4KbMQm3lnVu2oNWxI9W/lcyzA+mCKF4DBikxb/+UWtOGRiFP8qEwAayIgIA Ow== --0__=09BBE692DFC0F7468f9e8a93df938690918c09BBE692DFC0F746-- From owner-ips@ece.cmu.edu Thu Jul 25 12:53:04 2002 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA12249 for ; Thu, 25 Jul 2002 12:53:03 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id g6PGDJK18985 for ips-outgoing; Thu, 25 Jul 2002 12:13:19 -0400 (EDT) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from d12lmsgate-3.de.ibm.com (d12lmsgate-3.de.ibm.com [195.212.91.201]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id g6PGDHo18981 for ; Thu, 25 Jul 2002 12:13:17 -0400 (EDT) Received: from d12relay02.de.ibm.com (d12relay02.de.ibm.com [9.165.215.23]) by d12lmsgate-3.de.ibm.com (8.12.3/8.12.3) with ESMTP id g6PGDBhF010540; Thu, 25 Jul 2002 18:13:11 +0200 Received: from d10hubm1.telaviv.ibm.com (d10ml001.telaviv.ibm.com [9.148.216.55]) by d12relay02.de.ibm.com (8.11.1m3/NCO/VER6.2) with ESMTP id g6PGDAe113914; Thu, 25 Jul 2002 18:13:10 +0200 Subject: Re: iSCSI: SRP groups in Security-14 strawman To: Black_David@emc.com Cc: bernard_aboba@hotmail.com, ips@ece.cmu.edu X-Mailer: Lotus Notes Release 5.0.7 March 21, 2001 Message-ID: From: "Ofer Biran" Date: Thu, 25 Jul 2002 19:11:50 +0300 X-MIMETrack: Serialize by Router on D10ML001/10/M/IBM(Release 5.0.9a |January 7, 2002) at 25/07/2002 19:13:10 MIME-Version: 1.0 Content-type: text/plain; charset=us-ascii Sender: owner-ips@ece.cmu.edu Precedence: bulk David, Sounds reasonable. Two comments: 1. Is there no delay concern in introducing new IANA requirements at this late stage in the iSCSI standard ? 2. >Target MUST offer SRP-2048 as one of the possible values of >SRP_GROUP and SHOULD offer all supported groups that are >allowed by local security policy. "and SHOULD offer all supported groups..." - this sentence seems to me unnecessary. "MUST offer SRP-2048" is OK - it means that the implementation's administration interface will not enable settings that precludes offering SRP-2048. However, I'd expect the implementation to anyway offer other choices exactly according to the policy settings (unless it's bugged...). Regards, Ofer Ofer Biran Storage and Systems Technology IBM Research Lab in Haifa biran@il.ibm.com 972-4-8296253 From owner-ips@ece.cmu.edu Thu Jul 25 12:53:30 2002 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA12281 for ; Thu, 25 Jul 2002 12:53:29 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id g6PGekN20746 for ips-outgoing; Thu, 25 Jul 2002 12:40:46 -0400 (EDT) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from maho3msx2.isus.emc.com (maho3msx2.isus.emc.com [128.221.11.32]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id g6PGejo20742 for ; Thu, 25 Jul 2002 12:40:45 -0400 (EDT) Received: by MAHO3MSX2 with Internet Mail Service (5.5.2653.19) id ; Thu, 25 Jul 2002 12:38:28 -0400 Message-ID: <277DD60FB639D511AC0400B0D068B71E0564C0F1@CORPMX14> From: Black_David@emc.com To: BIRAN@il.ibm.com Cc: ips@ece.cmu.edu Subject: RE: iSCSI: SRP groups in Security-14 strawman Date: Thu, 25 Jul 2002 12:38:15 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-ips@ece.cmu.edu Precedence: bulk Ofer, > Sounds reasonable. Two comments: > > 1. Is there no delay concern in introducing new IANA requirements at > this late stage in the iSCSI standard ? Shouldn't be a problem - IANA doesn't get involved in the process until after the IESG has approved an Internet-Draft for publication as an RFC, and we have other IANA requirements going in as a result of vendor-specific keys and key values discussed in Yokohama. We do have to get the IANA text into reasonably good shape, as the IESG will ding us otherwise. > 2. >Target MUST offer SRP-2048 as one of the possible values of > >SRP_GROUP and SHOULD offer all supported groups that are > >allowed by local security policy. > > "and SHOULD offer all supported groups..." - this sentence seems to > me unnecessary. "MUST offer SRP-2048" is OK - it means that the > implementation's administration interface will not enable settings > that precludes offering SRP-2048. However, I'd expect the implementation > to anyway offer other choices exactly according to the policy settings > (unless it's bugged...). Ok. 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 --------------------------------------------------- From owner-ips@ece.cmu.edu Thu Jul 25 12:57:14 2002 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA12433 for ; Thu, 25 Jul 2002 12:57:09 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id g6PGZlr20443 for ips-outgoing; Thu, 25 Jul 2002 12:35:47 -0400 (EDT) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from mxic2.corp.emc.com (mxic2.us.dg.com [128.221.31.40]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id g6PGZjo20438 for ; Thu, 25 Jul 2002 12:35:45 -0400 (EDT) Received: by mxic2.corp.emc.com with Internet Mail Service (5.5.2653.19) id ; Thu, 25 Jul 2002 12:35:40 -0400 Message-ID: <277DD60FB639D511AC0400B0D068B71E0564C0F0@CORPMX14> From: Black_David@emc.com To: pkoning@equallogic.com Cc: ips@ece.cmu.edu Subject: RE: iSCSI: SRP groups in Security-14 strawman Date: Thu, 25 Jul 2002 12:33:16 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-ips@ece.cmu.edu Precedence: bulk Paul, > You mentioned a short while ago that Tero Kivinen had undertaken to > prove the primality of the SRP primes, but I don't remember seeing a > followup report on that. So until that is done, the IKE primes are > proven and the SRP primes are not yet proven. The SRP primes have been proven by Tero Kivinen and Markus Stenberg of SSH, as reported in: http://www.pdl.cmu.edu/mailinglists/ips/mail/msg11332.html which includes the location of the proof certificates. > If I remember right, there are performance benefits in some bignum > implementations to having a modulus with a bunch of leading and/or > trailing 1 bits. The IKE primes are constructed to achieve that, the > SRP primes are not. In other words, because of that construction > there IS value in allowing those primes; the IKE primes are NOT > superfluous and should be allowed whether or not there are primes in > the SRP reference software package of the same size. In other words, > keep the 1024, 1536, and 2048 bit MODP primes, using the generator > that Tom Wu identified. Could you or someone double check on these performance impacts and their magnitude? > If you feel strongly that there should be only one prime modulus of > any given size, then I would argue that the preference should be the > IKE primes because of their construction. I don't know about "strongly", but I am inclined to agree with Vince's suggestion that there's no additional value in multiple prime moduli of the same size. Does anyone else have implementation efficiency concerns about the MODP vs SRP primes? > I agree that only a single generator should be picked, so with the > proviso that we should also list the first acceptable generator for > the other IKE primes, your proposal sounds good. Good. > I like the approach of proposing a group identifier. That's also > (roughly) what IKE does. Good. This will require text changes in the iSCSI draft, but I think they're worth it at this late stage for interoperability. > > (2) We need some requirements on what MUST be supported for > > interoperability when SRP is supported. I hesitate to require > > support for all the groups up to the 8192-bit MODP group. A glance > > at draft-orman-public-key-lengths-05.txt suggests that the SRP > > primes are adequate for now as the 1536-bit and 2048-bit primes > > bracket the 96 bits of randomness that we require of CHAP secrets. > > > > In practice, I think we need to allow local security policy to > > disallow use of smaller primes, so the requirements would be > > something like: > > > > - MUST support all the SRP groups (up to 2048 bits) > > - MAY support the MODP groups > > - Target MUST offer SRP-2048 as one of the possible values of > > SRP_GROUP and SHOULD offer all supported groups that are > > allowed by local security policy. > > I would tweak this slightly. > > 1. Given the high cost of bignum arithmetic in software, I'd prefer > the mandatory lenghts to be smaller. Orman's document says that > a modulus size of 1553 matches a brute force strength of 90 bits. > Given the amount of approximation in all that analysis, I'd say > that we should set 1536 as the largest mandated size. That would be ok with me. I agree that bignum performance is directly related to the size of the bignums. > 2. For the reason given earlier, mandate the MODP groups (rather > than the SRP groups) up to the chosen mandatory size. I'd propose > 1536, but if 2048 sticks then make it MODP-2048. Reason: these are > just as good as the SRP reference primes, and may be more efficient > if your bignum implementation takes advantage of the clump of 1 > bits at start and end. I'd like to understand this performance issue better before signing on to this. In other words, my preference for the SRP primes is an "if all other things are equal" based on the fact that they're widely available with the SRP software (i.e., this is basically about implementer convenience) and so I'd like to understand how much of a difference the performance issue makes before stepping away from the primes usually used with SRP. > 3. "... MUST offer" -- it doesn't have to be the first choice, right? > I want to make sure that a customer who likes the cryptography > underlying SRP but is worried about the performance of login > (given a software implementation) is allowed to use, say, a 1024 > bit modulus by making that the first choice. Yes, that was my intent. In this situation, the other side needs the opportunity to enforce a security policy that requires a 1536 bit or larger modulus, hence the need to always offer the largest one - if the other side's policy allows the 1024 bit modulus, then it'll be used if offered as the first choice. 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 --------------------------------------------------- From owner-ips@ece.cmu.edu Thu Jul 25 15:45:41 2002 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA18545 for ; Thu, 25 Jul 2002 15:45:40 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id g6PJ8CA01118 for ips-outgoing; Thu, 25 Jul 2002 15:08:12 -0400 (EDT) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from cygnus.equallogic.com (cygnus.equallogic.com [65.170.102.10]) by ece.cmu.edu (8.11.0/8.10.2) with SMTP id g6PJ8Ao01111 for ; Thu, 25 Jul 2002 15:08:10 -0400 (EDT) Received: from cygnus.equallogic.com (localhost.localdomain [127.0.0.1]) by cygnus.equallogic.com (8.11.6/8.11.6) with ESMTP id g6PJ81C11835 for ; Thu, 25 Jul 2002 15:08:01 -0400 Received: from deneb.dev.equallogic.com (deneb.dev.equallogic.com [172.16.1.99]) by cygnus.equallogic.com (8.11.6/8.11.6) with ESMTP id g6PJ80Q11826; Thu, 25 Jul 2002 15:08:00 -0400 Received: from pkoning.dev.equallogic.com.equallogic.com (localhost.localdomain [127.0.0.1]) by deneb.dev.equallogic.com (8.11.6/8.11.6) with SMTP id g6PJ80h12204; Thu, 25 Jul 2002 15:08:00 -0400 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <15680.19600.143919.264935@pkoning.dev.equallogic.com> Date: Thu, 25 Jul 2002 15:08:00 -0400 From: Paul Koning To: Black_David@emc.com Cc: ips@ece.cmu.edu Subject: RE: iSCSI: SRP groups in Security-14 strawman References: <277DD60FB639D511AC0400B0D068B71E0564C0F0@CORPMX14> X-Mailer: VM 7.01 under 21.1 (patch 11) "Carlsbad Caverns" XEmacs Lucid Sender: owner-ips@ece.cmu.edu Precedence: bulk Content-Transfer-Encoding: 7bit >>>>> "Black" == Black David writes: >> If I remember right, there are performance benefits in some bignum >> implementations to having a modulus with a bunch of leading and/or >> trailing 1 bits. The IKE primes are constructed to achieve that, >> the SRP primes are not. In other words, because of that >> construction there IS value in allowing those primes; the IKE >> primes are NOT superfluous and should be allowed whether or not >> there are primes in the SRP reference software package of the same >> size. In other words, keep the 1024, 1536, and 2048 bit MODP >> primes, using the generator that Tom Wu identified. Black> Could you or someone double check on these performance impacts Black> and their magnitude? I looked in RFC2412, which mentions the benefit but doesn't quantify it. I also looked in the Handbook of Applied Cryptography, which describes a whole bunch of exponentiation algorithms. I'm not well enough versed in this stuff to translate the brief comment in RFC 2412 plus the algorithms in HAC into a specific percentage benefit. I wonder if one of the SSH folks can help answer this, since they seem to have the necessary technical skills. paul From owner-ips@ece.cmu.edu Thu Jul 25 15:46:54 2002 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA18569 for ; Thu, 25 Jul 2002 15:46:54 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id g6PIxbd00526 for ips-outgoing; Thu, 25 Jul 2002 14:59:37 -0400 (EDT) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from msgbas2.cos.agilent.com (msgbas2x.cos.agilent.com [192.25.240.37]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id g6PIxYo00518 for ; Thu, 25 Jul 2002 14:59:34 -0400 (EDT) Received: from msgrel1.cos.agilent.com (msgrel1.cos.agilent.com [130.29.152.77]) by msgbas2.cos.agilent.com (Postfix) with ESMTP id BC11510F6; Thu, 25 Jul 2002 12:59:33 -0600 (MDT) Received: from axcsbh2.cos.agilent.com (axcsbh2.cos.agilent.com [130.29.152.144]) by msgrel1.cos.agilent.com (Postfix) with SMTP id 9AA6C1B2; Thu, 25 Jul 2002 12:59:33 -0600 (MDT) Received: from 130.29.152.144 by axcsbh2.cos.agilent.com (InterScan E-Mail VirusWall NT); Thu, 25 Jul 2002 12:59:33 -0600 Received: by axcsbh2.cos.agilent.com with Internet Mail Service (5.5.2653.19) id <355PK4Q8>; Thu, 25 Jul 2002 12:59:32 -0600 Message-ID: <9F8400020EC5D311AF62009027C396160902C59B@axcs09.cos.agilent.com> From: kevin_lemay@agilent.com To: Julian_Satran@il.ibm.com, rdr@io.iol.unh.edu Cc: ips@ece.cmu.edu, pat_thaler@agilent.com Subject: RE: iSCSI: Use of Reject as a key value Date: Thu, 25 Jul 2002 12:59:32 -0600 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-ips@ece.cmu.edu Precedence: bulk Julian, I think that this change is a bad idea. The spec says that: "If the acceptor sends "Reject" as an answer the negotiated key is left at its current value (or default if no value was set). If the current value is not acceptable to the proposer on the connection or session it is sent the proposer MAY choose to terminate the connec- tion or session." But what happens in the following case: i->ImmediateData=Yes t->ImmediateData=no (Note: wrong case used) The initiator must use the default, which is ImmediateData=Yes, and there is no way for the initiator to inform the target of the error because sending: i->ImmediateData=Reject would be a re-negotiation. This will not work! Kevin -----Original Message----- From: Julian Satran [mailto:Julian_Satran@il.ibm.com] Sent: Wednesday, July 24, 2002 7:52 PM To: Robert D. Russell Cc: ips@ece.cmu.edu; owner-ips@ece.cmu.edu Subject: Re: iSCSI: Use of Reject as a key value Bob, On the last pdf you will find a statement about what to do. Julo "Robert D. Russell" Sent by: owner-ips@ece.cmu.edu 07/25/2002 12:58 AM To: ips@ece.cmu.edu cc: Subject: iSCSI: Use of Reject as a key value Julian: Attached are 2 ascii text files. The first, reject_extracts.txt, contains all the pieces of draft 14 (the latest available txt version of the drafts) that say anything about the use of Reject as a key value. (At least all those I could find using simple search -- unfortunately, Reject is also the name of a PDU and hence it is not a simple mechanical process to distinguish the two uses! If I missed some, please let me know.) The second, reject_comments.txt, are my comments on these excerpts from the standard. It seems to me that the key thing missing in the standard is a general statement about "what to do next" if a key=Reject response is received. Except for the OFMarkInt and IFMarkInt keys, I could find no other statement about how to proceed after receiving the key=Reject response. In looking through the e-mails posted to the list for June and July, I also could find nothing, although many people seem to be taking the third of the 3 interpretations I listed in reject_comments.txt. I am requesting a clear statement somewhere in the standard that says "what to do next" upon receiving a key=Reject response. Thank you for your consideration. Bob Russell InterOperability Lab University of New Hampshire rdr@iol.unh.edu 603-862-3774 #### reject_extracts.txt has been removed from this note on July 25 2002 by Julian Satran #### reject_comments.txt has been removed from this note on July 25 2002 by Julian Satran From owner-ips@ece.cmu.edu Thu Jul 25 16:39:31 2002 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA20492 for ; Thu, 25 Jul 2002 16:39:31 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id g6PK2KS04609 for ips-outgoing; Thu, 25 Jul 2002 16:02:20 -0400 (EDT) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from cisco.com (cypher.cisco.com [171.69.11.143]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id g6PK2Go04600; Thu, 25 Jul 2002 16:02:16 -0400 (EDT) Received: (from kzm@localhost) by cisco.com (8.8.8/2.6/Cisco List Logging/8.8.8) id NAA17095; Thu, 25 Jul 2002 13:01:58 -0700 (PDT) From: Keith McCloghrie Message-Id: <200207252001.NAA17095@cisco.com> Subject: Re: IPS-ALL: FC Mgmt MIB WG Last Call To: Duane.Baldwin@us.ibm.com (Duane Baldwin) Date: Thu, 25 Jul 2002 13:01:58 -0700 (PDT) Cc: Elizabeth.G.Rodriguez@123mail.net (Elizabeth G. Rodriguez), ips@ece.cmu.edu, owner-ips@ece.cmu.edu, t11_3@mail.t11.org In-Reply-To: from "Duane Baldwin" at Jul 25, 2002 10:30:22 AM X-Mailer: ELM [version 2.5 PL1] MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ips@ece.cmu.edu Precedence: bulk Content-Transfer-Encoding: 7bit Duane, > Here is the first of several issues/questions: > > Relative to the initial draft of this MIB (draft-ietf-ipfc-fcmgmt-int-mib- > 07.txt), the object "connUnitUrl" has been removed. No, draft-ietf-ipfc-fcmgmt-int-mib-07.txt was a different MIB. The MIB under review here is a replacement for both that MIB and RFC 2837. The replacement is needed because the previous MIB(s) had significant problems. In fact, the inclusion of "connUnitUrl" was part of one such problem, as is indicated by section 11.2.6 of the I-D being reviewed here. > No alternative is > suggested for this MIB in the text. Are there known alternatives for this > object? If so, this information should be included in the MIB text. If > there is no alternative, then this is a significant issue. Management > applications may use this value to enable the launch of the FC device > element manager. The semantics of "connUnitUrl" are not specific to Fibre Channel, and so it needs to be another WG with a more generic charter, which defines a MIB for "connUnitUrl" and other similar management information. About a year ago, I raised the issue, in the Entity-MIB WG, of the objects that will no longer have a home; specifically, I listed them as: >> The content not specific to Fibre Channel includes: >> >> - product name & info, serial#, mgmt-URL, contact, location, upTime, >> - state: online/offline, ok/warning/failed, >> - read-write control object: reset/online/offline, >> - module-ID (to group conn-units in a hierarchy), >> - a Revision Table (lists the revisions of hardware/firmware/etc. >> components supported by a connectivity unit), >> - a Sensor Table. The Entity MIB WG has since adopted a work item for an Entity Sensor MIB, and is looking at online/offline information. In response to my message, the WG chair said (at that time): >>Based on our discussions before London, I thought that Steve Blumenau >>(or someone else from the Fibre Channel group) would come to discuss >>any issues that the FC group had with the RFC 2737, in particular. >>However, Steve did not show up at the Entity MIB meetings. If the >>FC folks have any issues with RFC 2737, I encourage them to raise >>those issues on this list. >> >>Margaret and the AD said: >>Keith, I am sure that you realize that if there is no WG interest, that >>there is no way we can just assign such a topic to the WG. >>So... possibly based on your info below, some people may come forward >>to say yes yes... we are volunteering. Maybe the IPFC people come >>out (or nmaybe you can convince them) to help with this work in the >>entmib WG. >> >>An alternative path is that you do an individual submission via >>RFC-Editor and we can do a 4-week IETF Last Call for PS. >>Maybe Margareth would not mind if you post a draft and try to get >>some feedback via the WGs mailing list before you actually ask >>for it to be considered PS. So, if you feel strongly that MIB objects need to be defined for a mgmt-URL, etc., then I recommend you follow one of these two approaches. Keith. From owner-ips@ece.cmu.edu Thu Jul 25 16:43:22 2002 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA20625 for ; Thu, 25 Jul 2002 16:43:22 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id g6PKQdo06327 for ips-outgoing; Thu, 25 Jul 2002 16:26:39 -0400 (EDT) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from anchorage.arcot.com (anchorage.arcot.com [206.14.221.34]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id g6PKQao06322 for ; Thu, 25 Jul 2002 16:26:36 -0400 (EDT) Received: from arcot.com (webtest.arcot.com [206.14.221.43]) by anchorage.arcot.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) id PKAM8LN1; Thu, 25 Jul 2002 13:25:51 -0700 Message-ID: <3D405F9B.9010509@arcot.com> Date: Thu, 25 Jul 2002 13:29:15 -0700 From: Tom Wu User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.1a) Gecko/20020719 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Paul Koning CC: Black_David@emc.com, ips@ece.cmu.edu Subject: Re: iSCSI: SRP groups in Security-14 strawman References: <277DD60FB639D511AC0400B0D068B71E0564C0F0@CORPMX14> <15680.19600.143919.264935@pkoning.dev.equallogic.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-ips@ece.cmu.edu Precedence: bulk Content-Transfer-Encoding: 7bit Paul Koning wrote: >>>>>>"Black" == Black David writes: >>>>> > > >> If I remember right, there are performance benefits in some bignum > >> implementations to having a modulus with a bunch of leading and/or > >> trailing 1 bits. The IKE primes are constructed to achieve that, > >> the SRP primes are not. In other words, because of that > >> construction there IS value in allowing those primes; the IKE > >> primes are NOT superfluous and should be allowed whether or not > >> there are primes in the SRP reference software package of the same > >> size. In other words, keep the 1024, 1536, and 2048 bit MODP > >> primes, using the generator that Tom Wu identified. > > Black> Could you or someone double check on these performance impacts > Black> and their magnitude? > > I looked in RFC2412, which mentions the benefit but doesn't quantify > it. I also looked in the Handbook of Applied Cryptography, which > describes a whole bunch of exponentiation algorithms. I'm not well > enough versed in this stuff to translate the brief comment in RFC 2412 > plus the algorithms in HAC into a specific percentage benefit. Also keep in mind that RFC 2412 also suggests advantages in using 2 as a generator/base for modexp, though those advantages aren't quantified either. I generated the SRP primes to have 2 as a base, whereas the MODP primes cannot use 2 as a base with SRP. Perhaps a simple benchmark might shed some more light on this. Tom From owner-ips@ece.cmu.edu Thu Jul 25 20:03:23 2002 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA25171 for ; Thu, 25 Jul 2002 20:03:23 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id g6PNGrS16261 for ips-outgoing; Thu, 25 Jul 2002 19:16:53 -0400 (EDT) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from maho3msx2.isus.emc.com (maho3msx2.isus.emc.com [128.221.11.32]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id g6PNGqo16257 for ; Thu, 25 Jul 2002 19:16:52 -0400 (EDT) Received: by MAHO3MSX2 with Internet Mail Service (5.5.2653.19) id ; Thu, 25 Jul 2002 19:14:35 -0400 Message-ID: <277DD60FB639D511AC0400B0D068B71E0564C0F6@CORPMX14> From: Black_David@emc.com To: dap@cisco.com Cc: ips@ece.cmu.edu Subject: RE: iSCSI: DAP Last Call Comments Date: Thu, 25 Jul 2002 19:14:27 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C23431.060F40E0" Sender: owner-ips@ece.cmu.edu Precedence: bulk This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_001_01C23431.060F40E0 Content-Type: text/plain; charset="iso-8859-1" A quick process note. Dave Peterson does have open WG Last Call technical issues on iSCSI Retry and recommendations for SCSI vs. iSCSI recovery in the email below that didn't make it into the comprehensive list of technical issues posted earlier. I think the issues are textual as opposed to ones that will result in any need for protocol changes, and I'm attempting to work out some satisfactory text offline with Dave and Julian (it'll be posted here when agreed to). 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 --------------------------------------------------- -----Original Message----- From: Dave Peterson [mailto:dap@cisco.com] Sent: Monday, July 22, 2002 4:32 PM To: Julian Satran Cc: Ips@Ece. Cmu. Edu Subject: RE: iSCSI: DAP Last Call Comments Howdy Julian, Comments to your comments below...dap -----Original Message----- From: Julian Satran [mailto:Julian_Satran@il.ibm.com] Sent: Sunday, July 14, 2002 2:18 AM To: Dave Peterson Cc: Ips@Ece. Cmu. Edu; owner-ips@ece.cmu.edu Subject: Re: iSCSI: DAP Last Call Comments Dave - Comments in text - Thanks, Julo "Dave Peterson" Sent by: owner-ips@ece.cmu.edu 07/07/2002 11:19 PM Please respond to "Dave Peterson" To: "Ips@Ece. Cmu. Edu" cc: Subject: iSCSI: DAP Last Call Comments T p 36 2.2.2.1 Command Numbering and Acknowledging: 7th paragraph: if not in this document, where is the means to request immediate delivery for a command? +++ in some API document provided by your friendly implementer - there is no iSCSI CAM (no pun intended) +++ dap: I hope an application (client) does not have to deal with multiple ways via different vendors to request immediate delivery. Sounds like this should be added to the iSCSI HBA API so we don't have to deal with differing vendor implementations to enable/disable this feature. T p 103 6.1.1 Usage of Retry and 6.7 SCSI Timeouts: the semantics of Retry remain broken rendering it useless for tape operation. SCSI level error detection and recovery is the preferred mechanism. Refer to previous emails sent via the IPS reflector regarding this matter. +++ Dave. The retry scheme for connection recovery implies that the other two levels are there. So even if I would agree with your POW (which I am not) for practical reasons the mechanisms described will have to stay. +++ dap: again, without a standardized method for error detection (see the options I listed) to determine when the retry may be performed, the retry functionality is broke/useless/inconsistent for tape applications. This is not an implementation detail as some suggest. This must be consistent across vendor implementations for a tape application to work consistently. T p 128 8.6 Considerations for State-dependent devices: last paragraph: don't agree with the statement that error recovery at the iSCSI level (specifically Retry in its current state) is advisable. Retry at the SCSI level is feasible and is not difficult (i.e., READ POSITION and LOCATE commands). This paragraph should be removed. +++ that is not what we repeatedly hear. I will however make a "softer" statement. +++ dap: I don't know who is feeding you this information. READ POSITION is and has been mandatory to implement for tape devices for quite a while now. Additionally I'm on the verge of making LOCATE mandatory (in reality if READ POSITION is implemented, so is LOCATE). Any backup app/application client worth anything uses READ POSITION (and LOCATE). I have a major problem with any text that suggests otherwise. The use of READ POSITION and LOCATE mitigates the need for retry (and most error recovery) at the transport level, and this is where I want to go. Retry at the application level simply must not be performed without first: 1. determine the position of the device using READ POSTITION, then 2. (re)position the device if neccessary, then 3. continue This is not difficult, provided READ POSITION/LOCATE are supported. If the offending paragraph is indeed targeted for legacy device support, it certainly does not say that. In reality, todays inplementations use READ POSITION/LOCATE extensively and (legacy) devices that do not support these commands are very rare for this type of tape application/environment. I expect that a legacy tape device will be front-ended by a bridge device (i.e., I don't expect to see a native-iSCSI legacy tape device). This legacy tape device will not support the desirable functionality (such as FCP-2 error detection and recovery) thus placing a burden on a bridge device if the desired goal is to be achieved. Furthermore, the legacy devices will generally be of the Parallel SCSI variety, not FCP. The FCP-x tape devices I know of each support READ POSITION/LOCATE. The offending paragraph (draft 15): "For many of those state changing commands the execution model also assumes that the command is executed exactly once. For those commands a retry at SCSI level is not feasible or very difficult and error recovery at iSCSI level is advisable." must be removed. Note: The connection reassignment capability does provide use for tape applications, e.g, will hopefully keep the application running. I have no problem using the retry functionality in this context. T p 214 11.11 BidiInitialR2T: this text key provides no value and needs to be removed. InitialR2T should be used for both uni and bidirectional commands. In addition, if BidiInitialR2T were to be used, it will not function via an iSCSI-FCP gateway. +++ A gateway can easily map the keys. We don't know enough to decide off-hand to remove it. But I am still listening. +++ dap: There is no reason to have a different key to indicate whether or not an R2T will be used for bidi commands. InitialR2T works just fine for both. FCP uses just one parameter (i.e., write FCP_XFER_RDY disabled) for both and all is well. What more can I say, other than remove the key. ------_=_NextPart_001_01C23431.060F40E0 Content-Type: text/html; charset="iso-8859-1"

A quick process note.  Dave Peterson does have open WG Last
Call technical issues on iSCSI Retry and recommendations for
SCSI vs. iSCSI recovery in the email below that didn't make
it into the comprehensive list of technical issues posted earlier.
 
I think the issues are textual as opposed to ones that
will result in any need for protocol changes, and I'm
attempting to work out some satisfactory text offline
with Dave and Julian (it'll be posted here when agreed to).
 
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
---------------------------------------------------

-----Original Message-----
From: Dave Peterson [mailto:dap@cisco.com]
Sent: Monday, July 22, 2002 4:32 PM
To: Julian Satran
Cc: Ips@Ece. Cmu. Edu
Subject: RE: iSCSI: DAP Last Call Comments

Howdy Julian,
Comments to your comments below...dap
-----Original Message-----
From: Julian Satran [mailto:Julian_Satran@il.ibm.com]
Sent: Sunday, July 14, 2002 2:18 AM
To: Dave Peterson
Cc: Ips@Ece. Cmu. Edu; owner-ips@ece.cmu.edu
Subject: Re: iSCSI: DAP Last Call Comments


Dave - Comments in text - Thanks, Julo


"Dave Peterson" <dap@cisco.com>
Sent by: owner-ips@ece.cmu.edu

07/07/2002 11:19 PM
Please respond to "Dave Peterson"

       
        To:        "Ips@Ece. Cmu. Edu" <ips@ece.cmu.edu>
        cc:        
        Subject:        iSCSI: DAP Last Call Comments

       


T                 p 36                 2.2.2.1 Command Numbering and Acknowledging: 7th paragraph: if not in
this document, where is the means to request immediate delivery for a
command?

+++ in some API document provided by your friendly implementer - there is no iSCSI CAM (no pun intended) +++ 
 
dap: I hope an application (client) does not have to deal with multiple ways via different vendors to request immediate delivery. Sounds like this should be added to the iSCSI HBA API so we don't have to deal with differing vendor implementations to enable/disable this feature.

T                 p 103                 6.1.1 Usage of Retry and 6.7 SCSI Timeouts: the semantics of Retry
remain broken rendering it useless for tape operation. SCSI level error
detection and recovery is the preferred mechanism. Refer to previous emails
sent via the IPS reflector regarding this matter.
+++ Dave. The retry scheme for connection recovery implies that the other two levels are there.
So even if I would agree with your POW (which I am not) for practical reasons the mechanisms described
will have to stay.
+++ 
 
dap: again, without a standardized method for error detection (see the options I listed) to determine when the retry may be performed, the retry functionality is broke/useless/inconsistent for tape applications. This is not an implementation detail as some suggest. This must be consistent across vendor implementations for a tape application to work consistently.
   
T                 p 128                 8.6 Considerations for State-dependent devices: last paragraph:
don't agree with the statement that error recovery at the iSCSI level
(specifically Retry in its current state) is advisable. Retry at the SCSI
level is feasible and is not difficult (i.e., READ POSITION and LOCATE
commands). This paragraph should be removed.
+++ that is not what we repeatedly hear. I will however make a "softer" statement. +++  
 
dap: I don't know who is feeding you this information. READ POSITION is and has been mandatory to implement for tape devices for quite a while now. Additionally I'm on the verge of making LOCATE mandatory (in reality if READ POSITION is implemented, so is LOCATE). Any backup app/application client worth anything uses READ POSITION (and LOCATE). I have a major problem with any text that suggests otherwise. The use of READ POSITION and LOCATE mitigates the need for retry (and most error recovery) at the transport level, and this is where I want to go. Retry at the application level simply must not be performed without first:
1. determine the position of the device using READ POSTITION, then
2. (re)position the device if neccessary, then
3. continue
This is not difficult, provided READ POSITION/LOCATE are supported.
 
If the offending paragraph is indeed targeted for legacy device support, it certainly does not say that. In reality, todays inplementations use READ POSITION/LOCATE extensively and (legacy) devices that do not support these commands are very rare for this type of tape application/environment.
I expect that a legacy tape device will be front-ended by a bridge device (i.e., I don't expect to see a native-iSCSI legacy tape device). This legacy tape device will not support the desirable functionality (such as FCP-2 error detection and recovery) thus placing a burden on a bridge device if the desired goal is to be achieved.
Furthermore, the legacy devices will generally be of the Parallel SCSI variety, not FCP. The FCP-x tape devices I know of each support READ POSITION/LOCATE.
 
The offending paragraph (draft 15):
"For many of those state changing commands the execution model also assumes that the command is executed exactly once. For those commands a retry at SCSI level is not feasible or very difficult and error recovery at iSCSI level is advisable."
must be removed.
 
Note: The connection reassignment capability does provide use for tape applications, e.g, will hopefully keep the application running. I have no problem using the retry functionality in this context.
 
T                 p 214                 11.11 BidiInitialR2T: this text key provides no value and needs to
be removed. InitialR2T should be used for both uni and bidirectional
commands. In addition, if BidiInitialR2T were to be used, it will not
function via an iSCSI-FCP gateway.

+++ A gateway can easily map the keys. We don't know enough to decide off-hand to remove it.
But I am still listening.
+++ 

 dap: There is no reason to have a different key to indicate whether or not an R2T will be used for bidi commands. InitialR2T works just fine for both. FCP uses just one parameter (i.e., write FCP_XFER_RDY disabled) for both and all is well. What more can I say, other than remove the key.
 
------_=_NextPart_001_01C23431.060F40E0-- From owner-ips@ece.cmu.edu Thu Jul 25 20:18:43 2002 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA25319 for ; Thu, 25 Jul 2002 20:18:42 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id g6PNrV718022 for ips-outgoing; Thu, 25 Jul 2002 19:53:31 -0400 (EDT) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from d12lmsgate.de.ibm.com (d12lmsgate.de.ibm.com [195.212.91.199]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id g6PNrSo18016 for ; Thu, 25 Jul 2002 19:53:28 -0400 (EDT) Received: from d12relay02.de.ibm.com (d12relay02.de.ibm.com [9.165.215.23]) by d12lmsgate.de.ibm.com (8.12.3/8.12.3) with ESMTP id g6PNrKfh010242; Fri, 26 Jul 2002 01:53:20 +0200 Received: from d10hubm1.telaviv.ibm.com (d10ml001.telaviv.ibm.com [9.148.216.55]) by d12relay02.de.ibm.com (8.11.1m3/NCO/VER6.2) with ESMTP id g6PNrJe27350; Fri, 26 Jul 2002 01:53:20 +0200 To: "Rod Harrison" Cc: ips@ece.cmu.edu MIME-Version: 1.0 Subject: RE: iSCSI: v15 R2T and DATA-OUT X-Mailer: Lotus Notes Release 5.0.9 November 16, 2001 From: "Julian Satran" Message-ID: Date: Fri, 26 Jul 2002 02:53:12 +0300 X-MIMETrack: Serialize by Router on D10ML001/10/M/IBM(Release 5.0.9a |January 7, 2002) at 26/07/2002 02:53:20, Serialize complete at 26/07/2002 02:53:20 Content-Type: multipart/alternative; boundary="=_alternative 0038F9B2C2256C01_=" Sender: owner-ips@ece.cmu.edu Precedence: bulk This is a multipart message in MIME format. --=_alternative 0038F9B2C2256C01_= Content-Type: text/plain; charset="us-ascii" Rod, Probably a very long day. LUN is present in the command. Command is associated with ITT. R2T can be checked for a consistent ITT and LUN. End-story. Julo "Rod Harrison" 07/25/2002 06:49 AM To: cc: Julian Satran/Haifa/IBM@IBMIL Subject: RE: iSCSI: v15 R2T and DATA-OUT OK, it's been a long day. Let me try this one more time. I was write (almost) first time but I meant DATA-OUT instead of DATA-IN. Here's what I meant to say ... There is a potential inconsistency in the description of the use of the LUN field in DATA-OUT and R2T in the working v15 draft. 9.7.3 Target Transfer Tag, for DATA-OUT last paragraph says ... "If the Target Transfer Tag is provided, then the LUN field MUST hold a valid value and be consistent with whatever was specified with the command;" 9.8.5 Target Transfer Tag, for R2T says ... "The Target Transfer Tag and LUN are copied in the outgoing data PDUs and are used by the target only." Potentially a target could return a different LUN field in the R2T, for perhaps some funky LUN mapping or other internal reason expecting it to be copied to the DATA-OUT as per the R2T text. I think we need to indicate what is expected of the initiator if the LUN field in the R2T does not match the LUN in the command PDU. - Rod -----Original Message----- From: Rod Harrison [mailto:rod.harrison@windriver.com] Sent: Wednesday, July 24, 2002 8:57 PM To: Julian Satran Cc: ips@ece.cmu.edu Subject: RE: iSCSI: v15 R2T and DATA-OUT Oops, I see the confusion. I said DATA-IN in my message when I meant DATA-OUT. However, re-reading the section of v15 in question I now see that the third paragraph is referring to the DATA-IN LUN, not the DATA-OUT LUN. That wasn't clear to me when first scanned it because of the paragraph break. Perhaps a note of clarification needs to be added? - Rod -----Original Message----- From: Rod Harrison [mailto:rod.harrison@windriver.com] Sent: Wednesday, July 24, 2002 8:51 PM To: Julian Satran Cc: ips@ece.cmu.edu Subject: RE: iSCSI: v15 R2T and DATA-OUT Julian, I think you've misread my message. I was questioning how the initiator should handle the LUN between an R2T and the DATA-OUT(s) that satisfy it. DATA-OUT says copy the LUN from the command PDU, R2T says copy the LUN from the R2T to the DATA-OUT. Which is correct if the R2T contains a different LUN than that in the command PDU? - Rod -----Original Message----- From: Julian Satran [mailto:Julian_Satran@il.ibm.com] Sent: Wednesday, July 24, 2002 5:00 PM To: Rod Harrison Cc: ips@ece.cmu.edu; owner-ips@ece.cmu.edu Subject: Re: iSCSI: v15 R2T and DATA-OUT There is no TTT for data-In. Julo "Rod Harrison" driver.com> cc: Sent by: Subject: iSCSI: v15 R2T and DATA-OUT owner-ips@ece.cmu .edu 07/24/2002 10:24 PM Folks, There is a potential inconsistency in the description of the use of the LUN field in DATA-OUT and R2T in the working v15 draft. 9.7.3 Target Transfer Tag, for DATA-IN last paragraph says ... "If the Target Transfer Tag is provided, then the LUN field MUST hold a valid value and be consistent with whatever was specified with the command;" 9.8.5 Target Transfer Tag, for R2T says ... "The Target Transfer Tag and LUN are copied in the outgoing data PDUs and are used by the target only." Potentially a target could return a different LUN field in the R2T, for perhaps some funky LUN mapping or other internal reason expecting it to be copied to the DATA-OUT as per the R2T text. I suspect we just want to say this is not allowed and the LUN field MUST be the same as the command PDU. Either way I think we need to indicate what is expected of the initiator if the LUN field in the R2T does not match the LUN in the command PDU. Apologies for not spotting this before the end of last call. - Rod --=_alternative 0038F9B2C2256C01_= Content-Type: text/html; charset="us-ascii"
Rod,

Probably a very long day. LUN is present in the command. Command is associated with ITT. R2T can be checked for a consistent ITT and LUN.
End-story.

Julo


"Rod Harrison" <rod.harrison@windriver.com>

07/25/2002 06:49 AM

       
        To:        <ips@ece.cmu.edu>
        cc:        Julian Satran/Haifa/IBM@IBMIL
        Subject:        RE: iSCSI: v15 R2T and DATA-OUT

       



                OK, it's been a long day. Let me try this one more time.

                I was write (almost) first time but I meant DATA-OUT instead of
DATA-IN. Here's what I meant to say ...

                There is a potential inconsistency in the description of the use of
the LUN field in DATA-OUT and R2T in the working v15 draft.

                9.7.3 Target Transfer Tag, for DATA-OUT last paragraph says ...

                "If the Target Transfer Tag is provided, then the LUN field MUST hold
a valid value and be consistent with whatever was specified with the
command;"

                9.8.5 Target Transfer Tag, for R2T says ...

                "The Target Transfer Tag and LUN are copied in the outgoing data PDUs
and are used by the target only."

                Potentially a target could return a different LUN field in the R2T,
for perhaps some funky LUN mapping or other internal reason expecting
it to be copied to the DATA-OUT as per the R2T text.

                I think we need to indicate what is expected of the initiator if the
LUN field in the R2T does not match the LUN in the command PDU.

                - Rod

-----Original Message-----
From: Rod Harrison [mailto:rod.harrison@windriver.com]
Sent: Wednesday, July 24, 2002 8:57 PM
To: Julian Satran
Cc: ips@ece.cmu.edu
Subject: RE: iSCSI: v15 R2T and DATA-OUT



                Oops, I see the confusion. I said DATA-IN in my message when I meant
DATA-OUT.

                However, re-reading the section of v15 in question I now see that the
third paragraph is referring to the DATA-IN LUN, not the DATA-OUT LUN.
That wasn't clear to me when first scanned it because of the paragraph
break.

                Perhaps a note of clarification needs to be added?

                - Rod

-----Original Message-----
From: Rod Harrison [mailto:rod.harrison@windriver.com]
Sent: Wednesday, July 24, 2002 8:51 PM
To: Julian Satran
Cc: ips@ece.cmu.edu
Subject: RE: iSCSI: v15 R2T and DATA-OUT


Julian,

                I think you've misread my message. I was questioning how the
initiator should handle the LUN between an R2T and the DATA-OUT(s)
that satisfy it.

                DATA-OUT says copy the LUN from the command PDU, R2T says copy the
LUN from the R2T to the DATA-OUT. Which is correct if the R2T contains
a different LUN than that in the command PDU?

                - Rod


-----Original Message-----
From: Julian Satran [mailto:Julian_Satran@il.ibm.com]
Sent: Wednesday, July 24, 2002 5:00 PM
To: Rod Harrison
Cc: ips@ece.cmu.edu; owner-ips@ece.cmu.edu
Subject: Re: iSCSI: v15 R2T and DATA-OUT


There is no TTT for data-In. Julo



                     "Rod Harrison"
                     <rod.harrison@win        To:
<ips@ece.cmu.edu>
                     driver.com>              cc:
                     Sent by:                 Subject:  iSCSI: v15
R2T and DATA-OUT
                      owner-ips@ece.cmu
                     .edu


                     07/24/2002 10:24
                     PM






Folks,

            There is a potential inconsistency in the description of
the
use of
the LUN field in DATA-OUT and R2T in the working v15 draft.

            9.7.3 Target Transfer Tag, for DATA-IN last paragraph
says ...

            "If the Target Transfer Tag is provided, then the LUN
field
MUST hold
a valid value and be consistent with whatever was specified with the
command;"

            9.8.5 Target Transfer Tag, for R2T says ...

            "The Target Transfer Tag and LUN are copied in the
outgoing
data PDUs
and are used by the target only."

            Potentially a target could return a different LUN field
in the
R2T,
for perhaps some funky LUN mapping or other internal reason expecting
it to be copied to the DATA-OUT as per the R2T text. I suspect we just
want to say this is not allowed and the LUN field MUST be the same as
the command PDU.

            Either way I think we need to indicate what is expected
of the
initiator if the LUN field in the R2T does not match the LUN in the
command PDU.

            Apologies for not spotting this before the end of last
call.

            - Rod

--=_alternative 0038F9B2C2256C01_=-- From owner-ips@ece.cmu.edu Thu Jul 25 20:27:24 2002 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA25436 for ; Thu, 25 Jul 2002 20:27:24 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id g6Q07qE18784 for ips-outgoing; Thu, 25 Jul 2002 20:07:52 -0400 (EDT) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from mail.wrs.com (unknown-1-11.windriver.com [147.11.1.11]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id g6Q07oo18778 for ; Thu, 25 Jul 2002 20:07:51 -0400 (EDT) Received: from london (vpn10-95-10-3.wrsec.fr [10.95.10.3]) by mail.wrs.com (8.9.3/8.9.1) with SMTP id RAA25499; Thu, 25 Jul 2002 17:05:55 -0700 (PDT) From: "Rod Harrison" To: "Julian Satran" Cc: Subject: RE: iSCSI: v15 R2T and DATA-OUT Date: Thu, 25 Jul 2002 19:08:47 -0500 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0) Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2314.1300 In-Reply-To: Sender: owner-ips@ece.cmu.edu Precedence: bulk Content-Transfer-Encoding: 7bit Julian, OK, that's the answer to my question then. The wording that's there right now doesn't say what the initiator should do if the LUN in an R2T doesn't match the LUN it sent in the command PDU. So the resolution is that the initiator should treat a LUN inconsistency between R2T and command as a protocol error. I suggest we add a note to that effect where we talk about LUN in the R2T PDU description, that would be 9.8.5 in the v15 working draft. - Rod -----Original Message----- From: Julian Satran [mailto:Julian_Satran@il.ibm.com] Sent: Thursday, July 25, 2002 6:53 PM To: Rod Harrison Cc: ips@ece.cmu.edu Subject: RE: iSCSI: v15 R2T and DATA-OUT Rod, Probably a very long day. LUN is present in the command. Command is associated with ITT. R2T can be checked for a consistent ITT and LUN. End-story. Julo "Rod Harrison" 07/25/2002 06:49 AM To: cc: Julian Satran/Haifa/IBM@IBMIL Subject: RE: iSCSI: v15 R2T and DATA-OUT OK, it's been a long day. Let me try this one more time. I was write (almost) first time but I meant DATA-OUT instead of DATA-IN. Here's what I meant to say ... There is a potential inconsistency in the description of the use of the LUN field in DATA-OUT and R2T in the working v15 draft. 9.7.3 Target Transfer Tag, for DATA-OUT last paragraph says ... "If the Target Transfer Tag is provided, then the LUN field MUST hold a valid value and be consistent with whatever was specified with the command;" 9.8.5 Target Transfer Tag, for R2T says ... "The Target Transfer Tag and LUN are copied in the outgoing data PDUs and are used by the target only." Potentially a target could return a different LUN field in the R2T, for perhaps some funky LUN mapping or other internal reason expecting it to be copied to the DATA-OUT as per the R2T text. I think we need to indicate what is expected of the initiator if the LUN field in the R2T does not match the LUN in the command PDU. - Rod -----Original Message----- From: Rod Harrison [mailto:rod.harrison@windriver.com] Sent: Wednesday, July 24, 2002 8:57 PM To: Julian Satran Cc: ips@ece.cmu.edu Subject: RE: iSCSI: v15 R2T and DATA-OUT Oops, I see the confusion. I said DATA-IN in my message when I meant DATA-OUT. However, re-reading the section of v15 in question I now see that the third paragraph is referring to the DATA-IN LUN, not the DATA-OUT LUN. That wasn't clear to me when first scanned it because of the paragraph break. Perhaps a note of clarification needs to be added? - Rod -----Original Message----- From: Rod Harrison [mailto:rod.harrison@windriver.com] Sent: Wednesday, July 24, 2002 8:51 PM To: Julian Satran Cc: ips@ece.cmu.edu Subject: RE: iSCSI: v15 R2T and DATA-OUT Julian, I think you've misread my message. I was questioning how the initiator should handle the LUN between an R2T and the DATA-OUT(s) that satisfy it. DATA-OUT says copy the LUN from the command PDU, R2T says copy the LUN from the R2T to the DATA-OUT. Which is correct if the R2T contains a different LUN than that in the command PDU? - Rod -----Original Message----- From: Julian Satran [mailto:Julian_Satran@il.ibm.com] Sent: Wednesday, July 24, 2002 5:00 PM To: Rod Harrison Cc: ips@ece.cmu.edu; owner-ips@ece.cmu.edu Subject: Re: iSCSI: v15 R2T and DATA-OUT There is no TTT for data-In. Julo "Rod Harrison" driver.com> cc: Sent by: Subject: iSCSI: v15 R2T and DATA-OUT owner-ips@ece.cmu .edu 07/24/2002 10:24 PM Folks, There is a potential inconsistency in the description of the use of the LUN field in DATA-OUT and R2T in the working v15 draft. 9.7.3 Target Transfer Tag, for DATA-IN last paragraph says ... "If the Target Transfer Tag is provided, then the LUN field MUST hold a valid value and be consistent with whatever was specified with the command;" 9.8.5 Target Transfer Tag, for R2T says ... "The Target Transfer Tag and LUN are copied in the outgoing data PDUs and are used by the target only." Potentially a target could return a different LUN field in the R2T, for perhaps some funky LUN mapping or other internal reason expecting it to be copied to the DATA-OUT as per the R2T text. I suspect we just want to say this is not allowed and the LUN field MUST be the same as the command PDU. Either way I think we need to indicate what is expected of the initiator if the LUN field in the R2T does not match the LUN in the command PDU. Apologies for not spotting this before the end of last call. - Rod From owner-ips@ece.cmu.edu Thu Jul 25 21:20:13 2002 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA26135 for ; Thu, 25 Jul 2002 21:20:12 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id g6Q0hqB20452 for ips-outgoing; Thu, 25 Jul 2002 20:43:52 -0400 (EDT) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from pepsi.splentec.com (ns.splentec.com [209.47.35.194]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id g6Q0hno20443 for ; Thu, 25 Jul 2002 20:43:49 -0400 (EDT) Received: from splentec.com (canoe.splentec.com [209.47.35.250]) by pepsi.splentec.com (8.11.6/8.11.0) with ESMTP id g6Q0his14177 for ; Thu, 25 Jul 2002 20:43:44 -0400 Message-ID: <3D409B40.289A1D05@splentec.com> Date: Thu, 25 Jul 2002 20:43:44 -0400 From: Luben Tuikov Organization: Splentec Ltd. X-Mailer: Mozilla 4.79 [en] (X11; U; Linux 2.4.19-rc3 i686) X-Accept-Language: en MIME-Version: 1.0 To: iSCSI Subject: iSCSI: INQUIRY, version descriptor Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ips@ece.cmu.edu Precedence: bulk Content-Transfer-Encoding: 7bit Shouldn't we mention in the draft that Targets should set the next available (eq. 0x0000) version descriptor to 0x0960 in the INQUIRY data if additional length spans it? It is mentioned in SPC-3 (and SPC-2) and it would be more convenient for implementors to see it in the iSCSI document as well. -- Luben From owner-ips@ece.cmu.edu Thu Jul 25 21:24:02 2002 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA26165 for ; Thu, 25 Jul 2002 21:24:02 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id g6Q0scl21028 for ips-outgoing; Thu, 25 Jul 2002 20:54:38 -0400 (EDT) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from pepsi.splentec.com (ns.splentec.com [209.47.35.194]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id g6Q0sbo21024 for ; Thu, 25 Jul 2002 20:54:37 -0400 (EDT) Received: from splentec.com (canoe.splentec.com [209.47.35.250]) by pepsi.splentec.com (8.11.6/8.11.0) with ESMTP id g6Q0sVs14216 for ; Thu, 25 Jul 2002 20:54:31 -0400 Message-ID: <3D409DC7.FB044FC0@splentec.com> Date: Thu, 25 Jul 2002 20:54:31 -0400 From: Luben Tuikov Organization: Splentec Ltd. X-Mailer: Mozilla 4.79 [en] (X11; U; Linux 2.4.19-rc3 i686) X-Accept-Language: en MIME-Version: 1.0 To: iSCSI Subject: iSCSI: strengthening queue condition on pg 37 [v 15] Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ips@ece.cmu.edu Precedence: bulk Content-Transfer-Encoding: 7bit The condition on page 37: -If the PDU MaxCmdSN is less than the PDU ExpCmdSN-1 (in Serial Arithmetic Sense), they are both ignored. can be strengthened by specifying ``less than or equal''. Then and only then is the queue size > 0. -- Luben P.S. Proof: Ignore* if maxcmdsn <= expcmdsn-1. Thus accept if maxcmdsn > expcmdsn-1, which is maxcmdsn-expcmdsn+1 > 0, but maxcmdsn-expcmdsn+1 is the queue size, so accept* only if queue size > 0. *Meaning ignore/accept the values of maxcmdsn and expcmdsn. From owner-ips@ece.cmu.edu Fri Jul 26 03:25:37 2002 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA11094 for ; Fri, 26 Jul 2002 03:25:36 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id g6Q6iTs05462 for ips-outgoing; Fri, 26 Jul 2002 02:44:29 -0400 (EDT) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from hclnpd.hclt.co.in ([202.54.64.7]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id g6Q6iRo05456 for ; Fri, 26 Jul 2002 02:44:27 -0400 (EDT) Received: from mailnpd.hclt-ntl.co.in ([192.168.19.36]) by hclnpd.hclt.co.in with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) id 3B59JLSD; Fri, 26 Jul 2002 12:13:48 +0530 Received: from nramamurpc (nramamur-pc.hclt-ntl.co.in [192.168.19.98]) by mailnpd.hclt-ntl.co.in (8.11.0/8.11.0) with SMTP id g6Q6aK421689; Fri, 26 Jul 2002 12:06:29 +0530 Message-ID: <004b01c23470$3efe7440$6213a8c0@hcltech.com> From: "Nandakumar Ramamurthy" To: "Luben Tuikov" Cc: References: <3D409B40.289A1D05@splentec.com> Subject: Re: iSCSI: INQUIRY, version descriptor Date: Fri, 26 Jul 2002 12:16:51 +0530 Organization: HCL Technologies Ltd. MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2600.0000 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 Sender: owner-ips@ece.cmu.edu Precedence: bulk Content-Transfer-Encoding: 7bit Hi Luben, The SPC-2 has this to say : "The version descriptor fields provide for identifying up to eight standards to which the device claims conformance." "It is recommended that the first version descriptor be used for the SCSI architecture standard, followed by the physical standard, followed by the physical/mapping protocol if any followed by the appropriate SPC version, followed by the device type command set, followed by a secondary command set if any." Consider a target device that conforms to more than eight standards for the SCSI architecture, and physical standards. In this case the INQUIRY response data will not contain iSCSI version descriptor. What will be the actions taken by the iSCSI target/initiator on finding a target device not conforming to iSCSI ? Thanks, Nandakumar Member Technical Staff HCL Technologies, Chennai, INDIA. http://san.hcltech.com ----- Original Message ----- From: "Luben Tuikov" To: "iSCSI" Sent: Friday, July 26, 2002 6:13 AM Subject: iSCSI: INQUIRY, version descriptor > Shouldn't we mention in the draft that Targets should > set the next available (eq. 0x0000) version descriptor > to 0x0960 in the INQUIRY data if additional length spans > it? > > It is mentioned in SPC-3 (and SPC-2) and it would be more > convenient for implementors to see it in the iSCSI > document as well. > > -- > Luben From owner-ips@ece.cmu.edu Fri Jul 26 05:46:16 2002 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA12667 for ; Fri, 26 Jul 2002 05:46:16 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id g6Q9ArC10597 for ips-outgoing; Fri, 26 Jul 2002 05:10:53 -0400 (EDT) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from d12lmsgate.de.ibm.com (d12lmsgate.de.ibm.com [195.212.91.199]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id g6Q9Apo10592; Fri, 26 Jul 2002 05:10:51 -0400 (EDT) Received: from d12relay01.de.ibm.com (d12relay01.de.ibm.com [9.165.215.22]) by d12lmsgate.de.ibm.com (8.12.3/8.12.3) with ESMTP id g6Q9Ai9l018794; Fri, 26 Jul 2002 11:10:44 +0200 Received: from d10hubm1.telaviv.ibm.com (d10ml001.telaviv.ibm.com [9.148.216.55]) by d12relay01.de.ibm.com (8.11.1m3/NCO/VER6.2) with ESMTP id g6Q9Ahc104032; Fri, 26 Jul 2002 11:10:43 +0200 Subject: Re: iSCSI: Notifications on error To: "Lakshmi Ramasubramanian" Cc: ips@ece.cmu.edu, "Joe Dai" , owner-ips@ece.cmu.edu X-Mailer: Lotus Notes Release 5.0.9 November 16, 2001 Message-ID: From: "Julian Satran" Date: Fri, 26 Jul 2002 11:48:28 +0300 X-MIMETrack: Serialize by Router on D10ML001/10/M/IBM(Release 5.0.9a |January 7, 2002) at 26/07/2002 12:10:43 MIME-Version: 1.0 Content-type: text/plain; charset=us-ascii Sender: owner-ips@ece.cmu.edu Precedence: bulk Lakshmi, The freeze is a SCSI freeze and SCSI has also commands to thaw the queue (look for ACA reset and equivalents for UA cases). iSCSI does not have to be involved. Julo "Lakshmi Ramasubramanian" To: rosoft.com> Subject: iSCSI: Notifications on error Sent by: owner-ips@ece.cmu.e du 07/25/2002 05:08 PM If a command fails at the SCSI layer (on the target side), the driver can freeze the queue, and fail all requests till the queue is unfreezed. The target needs to tell the initiator about the queue freeze condition so that an initiator can issue an unfreeze request. Currently there is no way (as much as I could understand) in the spec to do such a thing. We can use vendor specific Async messages, but that will cause interop problems. Is it reasonable to request for a mechanism to do the above in the iSCSI spec? thanks! -lakshmi From owner-ips@ece.cmu.edu Fri Jul 26 05:46:40 2002 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA12691 for ; Fri, 26 Jul 2002 05:46:40 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id g6Q9BAh10636 for ips-outgoing; Fri, 26 Jul 2002 05:11:10 -0400 (EDT) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from d12lmsgate.de.ibm.com (d12lmsgate.de.ibm.com [195.212.91.199]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id g6Q9B8o10631 for ; Fri, 26 Jul 2002 05:11:08 -0400 (EDT) Received: from d12relay02.de.ibm.com (d12relay02.de.ibm.com [9.165.215.23]) by d12lmsgate.de.ibm.com (8.12.3/8.12.3) with ESMTP id g6Q9B19l011964 for ; Fri, 26 Jul 2002 11:11:01 +0200 Received: from d10hubm1.telaviv.ibm.com (d10ml001.telaviv.ibm.com [9.148.216.55]) by d12relay02.de.ibm.com (8.11.1m3/NCO/VER6.2) with ESMTP id g6Q9B0v77828 for ; Fri, 26 Jul 2002 11:11:01 +0200 Subject: RE: iSCSI: v15 R2T and DATA-OUT To: ips@ece.cmu.edu X-Mailer: Lotus Notes Release 5.0.9 November 16, 2001 Message-ID: From: "Julian Satran" Date: Fri, 26 Jul 2002 12:03:56 +0300 X-MIMETrack: Serialize by Router on D10ML001/10/M/IBM(Release 5.0.9a |January 7, 2002) at 26/07/2002 12:11:00 MIME-Version: 1.0 Content-type: text/plain; charset=us-ascii Sender: owner-ips@ece.cmu.edu Precedence: bulk I will add a strong statement about field consistency somewhere in 2. Julo "Rod Harrison" cc: Subject: RE: iSCSI: v15 R2T and DATA-OUT 07/26/2002 03:08 AM Julian, OK, that's the answer to my question then. The wording that's there right now doesn't say what the initiator should do if the LUN in an R2T doesn't match the LUN it sent in the command PDU. So the resolution is that the initiator should treat a LUN inconsistency between R2T and command as a protocol error. I suggest we add a note to that effect where we talk about LUN in the R2T PDU description, that would be 9.8.5 in the v15 working draft. - Rod -----Original Message----- From: Julian Satran [mailto:Julian_Satran@il.ibm.com] Sent: Thursday, July 25, 2002 6:53 PM To: Rod Harrison Cc: ips@ece.cmu.edu Subject: RE: iSCSI: v15 R2T and DATA-OUT Rod, Probably a very long day. LUN is present in the command. Command is associated with ITT. R2T can be checked for a consistent ITT and LUN. End-story. Julo "Rod Harrison" 07/25/2002 06:49 AM To: cc: Julian Satran/Haifa/IBM@IBMIL Subject: RE: iSCSI: v15 R2T and DATA-OUT OK, it's been a long day. Let me try this one more time. I was write (almost) first time but I meant DATA-OUT instead of DATA-IN. Here's what I meant to say ... There is a potential inconsistency in the description of the use of the LUN field in DATA-OUT and R2T in the working v15 draft. 9.7.3 Target Transfer Tag, for DATA-OUT last paragraph says ... "If the Target Transfer Tag is provided, then the LUN field MUST hold a valid value and be consistent with whatever was specified with the command;" 9.8.5 Target Transfer Tag, for R2T says ... "The Target Transfer Tag and LUN are copied in the outgoing data PDUs and are used by the target only." Potentially a target could return a different LUN field in the R2T, for perhaps some funky LUN mapping or other internal reason expecting it to be copied to the DATA-OUT as per the R2T text. I think we need to indicate what is expected of the initiator if the LUN field in the R2T does not match the LUN in the command PDU. - Rod -----Original Message----- From: Rod Harrison [mailto:rod.harrison@windriver.com] Sent: Wednesday, July 24, 2002 8:57 PM To: Julian Satran Cc: ips@ece.cmu.edu Subject: RE: iSCSI: v15 R2T and DATA-OUT Oops, I see the confusion. I said DATA-IN in my message when I meant DATA-OUT. However, re-reading the section of v15 in question I now see that the third paragraph is referring to the DATA-IN LUN, not the DATA-OUT LUN. That wasn't clear to me when first scanned it because of the paragraph break. Perhaps a note of clarification needs to be added? - Rod -----Original Message----- From: Rod Harrison [mailto:rod.harrison@windriver.com] Sent: Wednesday, July 24, 2002 8:51 PM To: Julian Satran Cc: ips@ece.cmu.edu Subject: RE: iSCSI: v15 R2T and DATA-OUT Julian, I think you've misread my message. I was questioning how the initiator should handle the LUN between an R2T and the DATA-OUT(s) that satisfy it. DATA-OUT says copy the LUN from the command PDU, R2T says copy the LUN from the R2T to the DATA-OUT. Which is correct if the R2T contains a different LUN than that in the command PDU? - Rod -----Original Message----- From: Julian Satran [mailto:Julian_Satran@il.ibm.com] Sent: Wednesday, July 24, 2002 5:00 PM To: Rod Harrison Cc: ips@ece.cmu.edu; owner-ips@ece.cmu.edu Subject: Re: iSCSI: v15 R2T and DATA-OUT There is no TTT for data-In. Julo "Rod Harrison" driver.com> cc: Sent by: Subject: iSCSI: v15 R2T and DATA-OUT owner-ips@ece.cmu .edu 07/24/2002 10:24 PM Folks, There is a potential inconsistency in the description of the use of the LUN field in DATA-OUT and R2T in the working v15 draft. 9.7.3 Target Transfer Tag, for DATA-IN last paragraph says ... "If the Target Transfer Tag is provided, then the LUN field MUST hold a valid value and be consistent with whatever was specified with the command;" 9.8.5 Target Transfer Tag, for R2T says ... "The Target Transfer Tag and LUN are copied in the outgoing data PDUs and are used by the target only." Potentially a target could return a different LUN field in the R2T, for perhaps some funky LUN mapping or other internal reason expecting it to be copied to the DATA-OUT as per the R2T text. I suspect we just want to say this is not allowed and the LUN field MUST be the same as the command PDU. Either way I think we need to indicate what is expected of the initiator if the LUN field in the R2T does not match the LUN in the command PDU. Apologies for not spotting this before the end of last call. - Rod From owner-ips@ece.cmu.edu Fri Jul 26 05:46:48 2002 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA12704 for ; Fri, 26 Jul 2002 05:46:47 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id g6Q9AtG10607 for ips-outgoing; Fri, 26 Jul 2002 05:10:55 -0400 (EDT) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from d12lmsgate-2.de.ibm.com (d12lmsgate-2.de.ibm.com [195.212.91.200]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id g6Q9Aro10599 for ; Fri, 26 Jul 2002 05:10:53 -0400 (EDT) Received: from d12relay02.de.ibm.com (d12relay02.de.ibm.com [9.165.215.23]) by d12lmsgate-2.de.ibm.com (8.12.3/8.12.3) with ESMTP id g6Q9Aacn007688; Fri, 26 Jul 2002 11:10:36 +0200 Received: from d10hubm1.telaviv.ibm.com (d10ml001.telaviv.ibm.com [9.148.216.55]) by d12relay02.de.ibm.com (8.11.1m3/NCO/VER6.2) with ESMTP id g6Q9AYv24944; Fri, 26 Jul 2002 11:10:35 +0200 Subject: RE: iSCSI: Use of Reject as a key value To: kevin_lemay@agilent.com Cc: ips@ece.cmu.edu, "Julian Satran" , pat_thaler@agilent.com, rdr@io.iol.unh.edu X-Mailer: Lotus Notes Release 5.0.9 November 16, 2001 Message-ID: From: "Julian Satran" Date: Fri, 26 Jul 2002 11:32:45 +0300 X-MIMETrack: Serialize by Router on D10ML001/10/M/IBM(Release 5.0.9a |January 7, 2002) at 26/07/2002 12:10:34 MIME-Version: 1.0 Content-type: text/plain; charset=us-ascii Sender: owner-ips@ece.cmu.edu Precedence: bulk Do you propose the formulate the standard so that it can tolerate all initiator syntax errors? Or just we state that it should be case insensitive. The first would be a bad idea. The protocol has enough complexity in order to deal with transport errors. It would be a bad idea to add implementation errors to the list. If you want case insensitivity - this was discussed and rejected a long time ago - again because it felt unnecessary. I would also like to point out that this is not a change. This behavior was always assumed (and implied in the statements about negotiations atomicity). The statement was added at the request of Bob Russell as a clarification. Julo kevin_lemay@agile nt.com To: Julian Satran/Haifa/IBM@IBMIL, rdr@io.iol.unh.edu cc: ips@ece.cmu.edu, pat_thaler@agilent.com 07/25/2002 09:59 Subject: RE: iSCSI: Use of Reject as a key value PM Julian, I think that this change is a bad idea. The spec says that: "If the acceptor sends "Reject" as an answer the negotiated key is left at its current value (or default if no value was set). If the current value is not acceptable to the proposer on the connection or session it is sent the proposer MAY choose to terminate the connec- tion or session." But what happens in the following case: i->ImmediateData=Yes t->ImmediateData=no (Note: wrong case used) The initiator must use the default, which is ImmediateData=Yes, and there is no way for the initiator to inform the target of the error because sending: i->ImmediateData=Reject would be a re-negotiation. This will not work! Kevin -----Original Message----- From: Julian Satran [mailto:Julian_Satran@il.ibm.com] Sent: Wednesday, July 24, 2002 7:52 PM To: Robert D. Russell Cc: ips@ece.cmu.edu; owner-ips@ece.cmu.edu Subject: Re: iSCSI: Use of Reject as a key value Bob, On the last pdf you will find a statement about what to do. Julo "Robert D. Russell" Sent by: owner-ips@ece.cmu.edu 07/25/2002 12:58 AM To: ips@ece.cmu.edu cc: Subject: iSCSI: Use of Reject as a key value Julian: Attached are 2 ascii text files. The first, reject_extracts.txt, contains all the pieces of draft 14 (the latest available txt version of the drafts) that say anything about the use of Reject as a key value. (At least all those I could find using simple search -- unfortunately, Reject is also the name of a PDU and hence it is not a simple mechanical process to distinguish the two uses! If I missed some, please let me know.) The second, reject_comments.txt, are my comments on these excerpts from the standard. It seems to me that the key thing missing in the standard is a general statement about "what to do next" if a key=Reject response is received. Except for the OFMarkInt and IFMarkInt keys, I could find no other statement about how to proceed after receiving the key=Reject response. In looking through the e-mails posted to the list for June and July, I also could find nothing, although many people seem to be taking the third of the 3 interpretations I listed in reject_comments.txt. I am requesting a clear statement somewhere in the standard that says "what to do next" upon receiving a key=Reject response. Thank you for your consideration. Bob Russell InterOperability Lab University of New Hampshire rdr@iol.unh.edu 603-862-3774 #### reject_extracts.txt has been removed from this note on July 25 2002 by Julian Satran #### reject_comments.txt has been removed from this note on July 25 2002 by Julian Satran From owner-ips@ece.cmu.edu Fri Jul 26 05:46:55 2002 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA12723 for ; Fri, 26 Jul 2002 05:46:55 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id g6Q9B4O10628 for ips-outgoing; Fri, 26 Jul 2002 05:11:04 -0400 (EDT) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from d12lmsgate-2.de.ibm.com (d12lmsgate-2.de.ibm.com [195.212.91.200]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id g6Q9B2o10621 for ; Fri, 26 Jul 2002 05:11:02 -0400 (EDT) Received: from d12relay02.de.ibm.com (d12relay02.de.ibm.com [9.165.215.23]) by d12lmsgate-2.de.ibm.com (8.12.3/8.12.3) with ESMTP id g6Q9Amcn027356; Fri, 26 Jul 2002 11:10:49 +0200 Received: from d10hubm1.telaviv.ibm.com (d10ml001.telaviv.ibm.com [9.148.216.55]) by d12relay02.de.ibm.com (8.11.1m3/NCO/VER6.2) with ESMTP id g6Q9Akv24964; Fri, 26 Jul 2002 11:10:47 +0200 Subject: RE: iSCSI: v15 R2T and DATA-OUT To: Paul Koning Cc: ips@ece.cmu.edu, owner-ips@ece.cmu.edu, rod.harrison@windriver.com X-Mailer: Lotus Notes Release 5.0.9 November 16, 2001 Message-ID: From: "Julian Satran" Date: Fri, 26 Jul 2002 11:52:01 +0300 X-MIMETrack: Serialize by Router on D10ML001/10/M/IBM(Release 5.0.9a |January 7, 2002) at 26/07/2002 12:10:47 MIME-Version: 1.0 Content-type: text/plain; charset=us-ascii Sender: owner-ips@ece.cmu.edu Precedence: bulk Paul, It would also be a bad idea to add too many words to the protocol. The protocol is clear about field consistency. Julo Paul Koning To: rod.harrison@windriver.com Sent by: cc: ips@ece.cmu.edu owner-ips@ece.cmu Subject: RE: iSCSI: v15 R2T and DATA-OUT .edu 07/25/2002 05:35 PM Excerpt of message (sent 24 July 2002) by Rod Harrison: > > OK, it's been a long day. Let me try this one more time. > > I was write (almost) first time but I meant DATA-OUT instead of > DATA-IN. Here's what I meant to say ... > > There is a potential inconsistency in the description of the use of > the LUN field in DATA-OUT and R2T in the working v15 draft. > > 9.7.3 Target Transfer Tag, for DATA-OUT last paragraph says ... > > "If the Target Transfer Tag is provided, then the LUN field MUST hold > a valid value and be consistent with whatever was specified with the > command;" > > 9.8.5 Target Transfer Tag, for R2T says ... > > "The Target Transfer Tag and LUN are copied in the outgoing data PDUs > and are used by the target only." > > Potentially a target could return a different LUN field in the R2T, > for perhaps some funky LUN mapping or other internal reason expecting > it to be copied to the DATA-OUT as per the R2T text. I think that's a very bad idea and should not be permitted. If someone wants to do LUN mapping, that's fine, so long as it's transparent to the initiator. To map a LUN and then let the mapped number leak out to the initiator is broken. > I think we need to indicate what is expected of the initiator if the > LUN field in the R2T does not match the LUN in the command PDU. Given that the subject was brought up I tend to agree that the spec should say something. I would prefer it to say that this is a protocol error. paul From owner-ips@ece.cmu.edu Fri Jul 26 10:17:26 2002 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA21162 for ; Fri, 26 Jul 2002 10:17:13 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id g6QDeHW04703 for ips-outgoing; Fri, 26 Jul 2002 09:40:17 -0400 (EDT) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from e1.esmtp.ibm.com. (e1.ny.us.ibm.com [32.97.182.101]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id g6QDeFo04696 for ; Fri, 26 Jul 2002 09:40:15 -0400 (EDT) Received: from northrelay02.pok.ibm.com (northrelay02.pok.ibm.com [9.56.224.150]) by e1.esmtp.ibm.com. (8.12.2/8.12.2) with ESMTP id g6QDdPAr065060; Fri, 26 Jul 2002 09:39:29 -0400 Received: from d27ml601.rchland.ibm.com (d27ml601.rchland.ibm.com [9.10.226.13]) by northrelay02.pok.ibm.com (8.12.3/NCO/VER6.3) with ESMTP id g6QDdNNK039984; Fri, 26 Jul 2002 09:39:23 -0400 Subject: Re: IPS-ALL: FC Mgmt MIB WG Last Call To: Keith McCloghrie Cc: Elizabeth.G.Rodriguez@123mail.net (Elizabeth G. Rodriguez), ips@ece.cmu.edu, owner-ips@ece.cmu.edu, t11_3@mail.t11.org X-Mailer: Lotus Notes Release 5.0.5 September 22, 2000 Message-ID: From: Duane Baldwin Date: Fri, 26 Jul 2002 08:39:18 -0500 X-MIMETrack: Serialize by Router on d27ml601/27/M/IBM(Build V60_05012002|May 01, 2002) at 07/26/2002 08:39:24 AM MIME-Version: 1.0 Content-type: multipart/related; Boundary="0__=09BBE691DFDA97298f9e8a93df938690918c09BBE691DFDA9729" Sender: owner-ips@ece.cmu.edu Precedence: bulk --0__=09BBE691DFDA97298f9e8a93df938690918c09BBE691DFDA9729 Content-type: multipart/alternative; Boundary="1__=09BBE691DFDA97298f9e8a93df938690918c09BBE691DFDA9729" --1__=09BBE691DFDA97298f9e8a93df938690918c09BBE691DFDA9729 Content-type: text/plain; charset=US-ASCII Kieth, OK, I understand that this MIB is a replacement for both draft-ietf-ipfc- fcmgmt-int-mib-07.txt and RFC 2837, and it appears to be an excellent effort relative to these objectives and in fixing the many problems in the original MIBs. But I also assume one of the priorities of this WG is to identify the migration path for users of the new MIB, which is why I raised the issue. (I also raised the same issue back in April of this year.) The ability to discover a management URL is important and is widely used today. Can you help in bringing this requirement to the Entity MIB WG? Or maybe as you mention, a management MIB is a better approach - but is there such an effort underway? The concept of a management URL object could definitely be improved on relative to "connUnitUrl", such as allowing multiple URL entries. Thanks in advance for the help! Duane Baldwin -- Keith McCloghrie To: Duane Baldwin/Rochester/IBM@IBMUS cc: Elizabeth.G.Rodriguez@123mail.net (Elizabeth G. Rodriguez), 07/25/02 03:01 PM ips@ece.cmu.edu, owner-ips@ece.cmu.edu, t11_3@mail.t11.org Subject: Re: IPS-ALL: FC Mgmt MIB WG Last Call Duane, > Here is the first of several issues/questions: > > Relative to the initial draft of this MIB (draft-ietf-ipfc-fcmgmt-int- mib- > 07.txt), the object "connUnitUrl" has been removed. No, draft-ietf-ipfc-fcmgmt-int-mib-07.txt was a different MIB. The MIB under review here is a replacement for both that MIB and RFC 2837. The replacement is needed because the previous MIB(s) had significant problems. In fact, the inclusion of "connUnitUrl" was part of one such problem, as is indicated by section 11.2.6 of the I-D being reviewed here. > No alternative is > suggested for this MIB in the text. Are there known alternatives for this > object? If so, this information should be included in the MIB text. If > there is no alternative, then this is a significant issue. Management > applications may use this value to enable the launch of the FC device > element manager. The semantics of "connUnitUrl" are not specific to Fibre Channel, and so it needs to be another WG with a more generic charter, which defines a MIB for "connUnitUrl" and other similar management information. About a year ago, I raised the issue, in the Entity-MIB WG, of the objects that will no longer have a home; specifically, I listed them as: >> The content not specific to Fibre Channel includes: >> >> - product name & info, serial#, mgmt-URL, contact, location, upTime, >> - state: online/offline, ok/warning/failed, >> - read-write control object: reset/online/offline, >> - module-ID (to group conn-units in a hierarchy), >> - a Revision Table (lists the revisions of hardware/firmware/etc. >> components supported by a connectivity unit), >> - a Sensor Table. The Entity MIB WG has since adopted a work item for an Entity Sensor MIB, and is looking at online/offline information. In response to my message, the WG chair said (at that time): >>Based on our discussions before London, I thought that Steve Blumenau >>(or someone else from the Fibre Channel group) would come to discuss >>any issues that the FC group had with the RFC 2737, in particular. >>However, Steve did not show up at the Entity MIB meetings. If the >>FC folks have any issues with RFC 2737, I encourage them to raise >>those issues on this list. >> >>Margaret and the AD said: >>Keith, I am sure that you realize that if there is no WG interest, that >>there is no way we can just assign such a topic to the WG. >>So... possibly based on your info below, some people may come forward >>to say yes yes... we are volunteering. Maybe the IPFC people come >>out (or nmaybe you can convince them) to help with this work in the >>entmib WG. >> >>An alternative path is that you do an individual submission via >>RFC-Editor and we can do a 4-week IETF Last Call for PS. >>Maybe Margareth would not mind if you post a draft and try to get >>some feedback via the WGs mailing list before you actually ask >>for it to be considered PS. So, if you feel strongly that MIB objects need to be defined for a mgmt-URL, etc., then I recommend you follow one of these two approaches. Keith. --1__=09BBE691DFDA97298f9e8a93df938690918c09BBE691DFDA9729 Content-type: text/html; charset=US-ASCII Content-Disposition: inline

Kieth,

OK, I understand that this MIB is a replacement for both draft-ietf-ipfc-fcmgmt-int-mib-07.txt and RFC 2837, and it appears to be an excellent effort relative to these objectives and in fixing the many problems in the original MIBs. But I also assume one of the priorities of this WG is to identify the migration path for users of the new MIB, which is why I raised the issue. (I also raised the same issue back in April of this year.)

The ability to discover a management URL is important and is widely used today. Can you help in bringing this requirement to the Entity MIB WG? Or maybe as you mention, a management MIB is a better approach - but is there such an effort underway? The concept of a management URL object could definitely be improved on relative to "connUnitUrl", such as allowing multiple URL entries.

Thanks in advance for the help!

Duane Baldwin

--

Keith McCloghrie <kzm@cisco.com>




          Keith McCloghrie <kzm@cisco.com>

          07/25/02 03:01 PM



To: Duane Baldwin/Rochester/IBM@IBMUS
cc: Elizabeth.G.Rodriguez@123mail.net (Elizabeth G. Rodriguez), ips@ece.cmu.edu, owner-ips@ece.cmu.edu, t11_3@mail.t11.org
Subject: Re: IPS-ALL: FC Mgmt MIB WG Last Call


Duane,

> Here is the first of several issues/questions:
>
> Relative to the initial draft of this MIB (draft-ietf-ipfc-fcmgmt-int-mib-
> 07.txt), the object "connUnitUrl" has been removed.

No, draft-ietf-ipfc-fcmgmt-int-mib-07.txt was a different MIB. The MIB
under review here is a replacement for both that MIB and RFC 2837. The
replacement is needed because the previous MIB(s) had significant
problems. In fact, the inclusion of "connUnitUrl" was part of one such
problem, as is indicated by section 11.2.6 of the I-D being reviewed here.

> No alternative is
> suggested for this MIB in the text. Are there known alternatives for this
> object? If so, this information should be included in the MIB text. If
> there is no alternative, then this is a significant issue. Management
> applications may use this value to enable the launch of the FC device
> element manager.

The semantics of "connUnitUrl" are not specific to Fibre Channel, and
so it needs to be another WG with a more generic charter, which defines
a MIB for "connUnitUrl" and other similar management information.

About a year ago, I raised the issue, in the Entity-MIB WG, of the
objects that will no longer have a home; specifically, I listed them as:

>> The content not specific to Fibre Channel includes:
>>
>> - product name & info, serial#, mgmt-URL, contact, location, upTime,
>> - state: online/offline, ok/warning/failed,
>> - read-write control object: reset/online/offline,
>> - module-ID (to group conn-units in a hierarchy),
>> - a Revision Table (lists the revisions of hardware/firmware/etc.
>> components supported by a connectivity unit),
>> - a Sensor Table.

The Entity MIB WG has since adopted a work item for an Entity Sensor
MIB, and is looking at online/offline information.

In response to my message, the WG chair said (at that time):

>>Based on our discussions before London, I thought that Steve Blumenau
>>(or someone else from the Fibre Channel group) would come to discuss
>>any issues that the FC group had with the RFC 2737, in particular.
>>However, Steve did not show up at the Entity MIB meetings. If the
>>FC folks have any issues with RFC 2737, I encourage them to raise
>>those issues on this list.
>>
>>Margaret

and the AD said:

>>Keith, I am sure that you realize that if there is no WG interest, that
>>there is no way we can just assign such a topic to the WG.
>>So... possibly based on your info below, some people may come forward
>>to say yes yes... we are volunteering. Maybe the IPFC people come
>>out (or nmaybe you can convince them) to help with this work in the
>>entmib WG.
>>
>>An alternative path is that you do an individual submission via
>>RFC-Editor and we can do a 4-week IETF Last Call for PS.
>>Maybe Margareth would not mind if you post a draft and try to get
>>some feedback via the WGs mailing list before you actually ask
>>for it to be considered PS.

So, if you feel strongly that MIB objects need to be defined for a
mgmt-URL, etc., then I recommend you follow one of these two approaches.

Keith.


--1__=09BBE691DFDA97298f9e8a93df938690918c09BBE691DFDA9729-- --0__=09BBE691DFDA97298f9e8a93df938690918c09BBE691DFDA9729 Content-type: image/gif; name="graycol.gif" Content-Disposition: inline; filename="graycol.gif" Content-ID: <10__=09BBE691DFDA97298f9e8a93df938@us.ibm.com> Content-transfer-encoding: base64 Content-Transfer-Encoding: base64 R0lGODlhEAAQAKECAMzMzAAAAP///wAAACH5BAEAAAIALAAAAAAQABAAAAIXlI+py+0PopwxUbpu ZRfKZ2zgSJbmSRYAIf4fT3B0aW1pemVkIGJ5IFVsZWFkIFNtYXJ0U2F2ZXIhAAA7 --0__=09BBE691DFDA97298f9e8a93df938690918c09BBE691DFDA9729 Content-type: image/gif; name="ecblank.gif" Content-Disposition: inline; filename="ecblank.gif" Content-ID: <20__=09BBE691DFDA97298f9e8a93df938@us.ibm.com> Content-transfer-encoding: base64 Content-Transfer-Encoding: base64 R0lGODlhEAABAIAAAAAAAP///yH5BAEAAAEALAAAAAAQAAEAAAIEjI8ZBQA7 --0__=09BBE691DFDA97298f9e8a93df938690918c09BBE691DFDA9729 Content-type: image/gif; name="pic18009.gif" Content-Disposition: inline; filename="pic18009.gif" Content-ID: <30__=09BBE691DFDA97298f9e8a93df938@us.ibm.com> Content-transfer-encoding: base64 Content-Transfer-Encoding: base64 R0lGODlhWABDALP/AAAAAK04Qf79/o+Gm7WuwlNObwoJFCsoSMDAwGFsmIuezf///wAAAAAAAAAA AAAAACH5BAEAAAgALAAAAABYAEMAQAT/EMlJq704682770RiFMRinqggEUNSHIchG0BCfHhOjAuh EDeUqTASLCbBhQrhG7xis2j0lssNDopE4jfIJhDaggI8YB1sZeZgLVA9YVCpnGagVjV171aRVrYR RghXcAGFhoUETwYxcXNyADJ3GlcSKGAwLwllVC1vjIUHBWsFilKQdI8GA5IcpApeJQt8L09lmgkH LZikoU5wjqcyAMMFrJIDPAKvCFletKSev1HBw8KrxtjZ2tvc3d5VyKtCKW3jfz4uMKmq3xu4N0nK BVoJQmx2LGVOmrqNjjJf2hHAQo/eDwJGTKhQMcgQEEAnEjFS98+RnW3smGkZU6ncCWav/4wYOnAI TihRL/4FEwbp28BXMMcoscQCVxlepL4IGDSCyJyVQOu0o7CjmLN50OZlqWmyFy5/6yBBuji0AxFR M00oQAqNIstqI6qKHUsWRAEAvagsmfUEAImyxgbmUpJk3IklNUtJOUAVLoUr1+wqDGTE4zk+T6FG uQb3SizBCwatiiUgCBN8vrz+zFjVyQ8FWkOlg4NQiZMB5QS8QO3mpOaKnL0Z2EKvNMSILEThKhCg zMKPVxYJh23qm9KNW7pArPynMqZDiErsTMqI+LRi3QAgkFUbXpuFKhSYZALd0O5RKa2z9EYKBbpb qxIKsjUPRgD7I2XYV6wyrOw92ykExP8NW4URhknC5dKGE4v4NENQj2jXjmfNgOZDaXb5glRmXQ33 YEWQYNcZFnrYcIQLNzyTFDQNkXIff0ExVlY4srziQk43inZgL4rwxxINMvpFFAz1KOODHiu+4aEw NEjFl5B3JIKWKF3k6I9bfUGp5ZZcdunll5IA4cuHvQQJ5gcsoCWOOUwgltIwAKRxJgbIkJAQZEq0 2YliZnpZZ4BH3CnYOXldOUOfQoYDqF1LFHbXCrO8xmRsfoXDXJ6ChjCAH3QlhJcT6VWE6FCkfCco CgrMFsROrIEX3o2whVjWDjoJccN3LdggSGXLCdLEgHr1lyU3O3QxhgohNKXJCWv8JQr/PDdaqd6w 2rj1inLiGeiCJoDspAoQlYE6QWLSECehcWIYxIQES6zhbn1iImTHEQyqJ4eIxJJoUBc+3CbBuwZE V5cJPPkIjFDdeEabQbd6WgICTxiiz0f5dBKquXF6k4senwEhYGnKEFJeGrxUZy8dB8gmAXI/sPvH ESfCwVt5hTgYiqQqtdRNHQIU1PJ33ZqmzgE90OwLaoJcnMop1WiMmgkPHQRIrwgFuNV90A3doNKT mrKIN07AnGcI9BQjhCBN4RfA1qIZnMqorJCogKfGQnxSCDilTVIA0yl5ciTovgLuBDKFUDE9aQcw 9SA+rjSNf9/M1gxrj6VwDTS0IUSElMzBfsj0NFXR2kwsV1A5IF1grLgLL/r1R40BZEnuBWgmQEyb jqRwSAt6bqMCOFkvKFN2GPPkUzIm/SCF8z8pVzpbjVnMsy0vOr1hw3SaSRUhpY09v0z0J1FnwzPl fmh+xl4WtR0zGu24I4KbMQm3lnVu2oNWxI9W/lcyzA+mCKF4DBikxb/+UWtOGRiFP8qEwAayIgIA Ow== --0__=09BBE691DFDA97298f9e8a93df938690918c09BBE691DFDA9729-- From owner-ips@ece.cmu.edu Fri Jul 26 11:29:18 2002 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA25263 for ; Fri, 26 Jul 2002 11:29:18 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id g6QEoqR08671 for ips-outgoing; Fri, 26 Jul 2002 10:50:52 -0400 (EDT) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from cisco.com (cypher.cisco.com [171.69.11.143]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id g6QEomo08659; Fri, 26 Jul 2002 10:50:48 -0400 (EDT) Received: (from kzm@localhost) by cisco.com (8.8.8/2.6/Cisco List Logging/8.8.8) id HAA15739; Fri, 26 Jul 2002 07:50:42 -0700 (PDT) From: Keith McCloghrie Message-Id: <200207261450.HAA15739@cisco.com> Subject: Re: IPS-ALL: FC Mgmt MIB WG Last Call To: Duane.Baldwin@us.ibm.com (Duane Baldwin) Date: Fri, 26 Jul 2002 07:50:42 -0700 (PDT) Cc: kzm@cisco.com (Keith McCloghrie), Elizabeth.G.Rodriguez@123mail.net (Elizabeth G. Rodriguez), ips@ece.cmu.edu, owner-ips@ece.cmu.edu, t11_3@mail.t11.org In-Reply-To: from "Duane Baldwin" at Jul 26, 2002 08:39:18 AM X-Mailer: ELM [version 2.5 PL1] MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ips@ece.cmu.edu Precedence: bulk Content-Transfer-Encoding: 7bit Duane, > OK, I understand that this MIB is a replacement for both draft-ietf-ipfc- > fcmgmt-int-mib-07.txt and RFC 2837, and it appears to be an excellent > effort relative to these objectives and in fixing the many problems in the > original MIBs. But I also assume one of the priorities of this WG is to > identify the migration path for users of the new MIB, which is why I raised > the issue. (I also raised the same issue back in April of this year.) > > The ability to discover a management URL is important and is widely used > today. Can you help in bringing this requirement to the Entity MIB WG? Or As I indicated in my previous message, I already did what you're asking for; I took the requirement for each of the removed objects to the Entity MIB WG. Some of them have since been adopted there. For the others, perhaps I didn't explain the requirement for them as well as you could. Nevertheless, I believe it will take a sustained effort to get them not only adopted but progressed to standardization. I'm sorry but I don't have the time or motivation for such a sustained effort. In contrast, you seem to be motivated; so, the question is: do you have the time ?? Keith. > maybe as you mention, a management MIB is a better approach - but is there > such an effort underway? The concept of a management URL object could > definitely be improved on relative to "connUnitUrl", such as allowing > multiple URL entries. > > Duane Baldwin > From owner-ips@ece.cmu.edu Fri Jul 26 11:31:36 2002 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA25374 for ; Fri, 26 Jul 2002 11:31:36 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id g6QEsnQ08925 for ips-outgoing; Fri, 26 Jul 2002 10:54:49 -0400 (EDT) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from msgbas2.cos.agilent.com (msgbas2x.cos.agilent.com [192.25.240.37]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id g6QEslo08921 for ; Fri, 26 Jul 2002 10:54:48 -0400 (EDT) Received: from msgrel1t.cos.agilent.com (msgrel1t.cos.agilent.com [130.29.152.157]) by msgbas2.cos.agilent.com (Postfix) with ESMTP id 41D39219C; Fri, 26 Jul 2002 08:54:47 -0600 (MDT) Received: from axcsbh4.cos.agilent.com (axcsbh4.cos.agilent.com [130.29.152.145]) by msgrel1t.cos.agilent.com (Postfix) with SMTP id D3BCE4C7; Fri, 26 Jul 2002 08:54:46 -0600 (MDT) Received: from 130.29.152.145 by axcsbh4.cos.agilent.com (InterScan E-Mail VirusWall NT); Fri, 26 Jul 2002 08:54:45 -0600 Received: by axcsbh4.cos.agilent.com with Internet Mail Service (5.5.2653.19) id ; Fri, 26 Jul 2002 08:54:45 -0600 Message-ID: <9F8400020EC5D311AF62009027C396160902C5A6@axcs09.cos.agilent.com> From: kevin_lemay@agilent.com To: Julian_Satran@il.ibm.com, kevin_lemay@agilent.com Cc: ips@ece.cmu.edu, pat_thaler@agilent.com, rdr@io.iol.unh.edu Subject: RE: iSCSI: Use of Reject as a key value Date: Fri, 26 Jul 2002 08:54:44 -0600 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-ips@ece.cmu.edu Precedence: bulk The iSCSI spec did not specify the handling of reject prior to the current v15 working version. I am NOT proposing changing the case sensitivity. I am merely pointing out a potential problem in the proposed handling of reject during login negotiation. Our current implementation handles it as described by Professor Russell as "Case 2", the rejection of a parameter during login (except for markers) terminates the login. My example was meant to demonstrate the problem associated with continuing the login with rejected parameters. The initiator and target have the potential to continue with miss-matched parameters. Professor Russell had three proposals in what he posted. He was not requesting a particular wording but meant to open it up to the list for discussion and a solution. Kevin -----Original Message----- From: Julian Satran [mailto:Julian_Satran@il.ibm.com] Sent: Friday, July 26, 2002 1:33 AM To: kevin_lemay@agilent.com Cc: ips@ece.cmu.edu; Julian Satran; pat_thaler@agilent.com; rdr@io.iol.unh.edu Subject: RE: iSCSI: Use of Reject as a key value Do you propose the formulate the standard so that it can tolerate all initiator syntax errors? Or just we state that it should be case insensitive. The first would be a bad idea. The protocol has enough complexity in order to deal with transport errors. It would be a bad idea to add implementation errors to the list. If you want case insensitivity - this was discussed and rejected a long time ago - again because it felt unnecessary. I would also like to point out that this is not a change. This behavior was always assumed (and implied in the statements about negotiations atomicity). The statement was added at the request of Bob Russell as a clarification. Julo kevin_lemay@agile nt.com To: Julian Satran/Haifa/IBM@IBMIL, rdr@io.iol.unh.edu cc: ips@ece.cmu.edu, pat_thaler@agilent.com 07/25/2002 09:59 Subject: RE: iSCSI: Use of Reject as a key value PM Julian, I think that this change is a bad idea. The spec says that: "If the acceptor sends "Reject" as an answer the negotiated key is left at its current value (or default if no value was set). If the current value is not acceptable to the proposer on the connection or session it is sent the proposer MAY choose to terminate the connec- tion or session." But what happens in the following case: i->ImmediateData=Yes t->ImmediateData=no (Note: wrong case used) The initiator must use the default, which is ImmediateData=Yes, and there is no way for the initiator to inform the target of the error because sending: i->ImmediateData=Reject would be a re-negotiation. This will not work! Kevin -----Original Message----- From: Julian Satran [mailto:Julian_Satran@il.ibm.com] Sent: Wednesday, July 24, 2002 7:52 PM To: Robert D. Russell Cc: ips@ece.cmu.edu; owner-ips@ece.cmu.edu Subject: Re: iSCSI: Use of Reject as a key value Bob, On the last pdf you will find a statement about what to do. Julo "Robert D. Russell" Sent by: owner-ips@ece.cmu.edu 07/25/2002 12:58 AM To: ips@ece.cmu.edu cc: Subject: iSCSI: Use of Reject as a key value Julian: Attached are 2 ascii text files. The first, reject_extracts.txt, contains all the pieces of draft 14 (the latest available txt version of the drafts) that say anything about the use of Reject as a key value. (At least all those I could find using simple search -- unfortunately, Reject is also the name of a PDU and hence it is not a simple mechanical process to distinguish the two uses! If I missed some, please let me know.) The second, reject_comments.txt, are my comments on these excerpts from the standard. It seems to me that the key thing missing in the standard is a general statement about "what to do next" if a key=Reject response is received. Except for the OFMarkInt and IFMarkInt keys, I could find no other statement about how to proceed after receiving the key=Reject response. In looking through the e-mails posted to the list for June and July, I also could find nothing, although many people seem to be taking the third of the 3 interpretations I listed in reject_comments.txt. I am requesting a clear statement somewhere in the standard that says "what to do next" upon receiving a key=Reject response. Thank you for your consideration. Bob Russell InterOperability Lab University of New Hampshire rdr@iol.unh.edu 603-862-3774 #### reject_extracts.txt has been removed from this note on July 25 2002 by Julian Satran #### reject_comments.txt has been removed from this note on July 25 2002 by Julian Satran From owner-ips@ece.cmu.edu Fri Jul 26 13:06:01 2002 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA00199 for ; Fri, 26 Jul 2002 13:06:01 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id g6QGnwO16161 for ips-outgoing; Fri, 26 Jul 2002 12:49:58 -0400 (EDT) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from lion.ninthwonder.com (lion.ninthwonder.com [151.199.66.147]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id g6QGnvo16157 for ; Fri, 26 Jul 2002 12:49:57 -0400 (EDT) Received: by lion.ninthwonder.com (Postfix, from userid 1021) id EF44330706; Fri, 26 Jul 2002 12:49:56 -0400 (EDT) Date: Fri, 26 Jul 2002 09:46:29 -0700 (PDT) From: Bill Studenmund X-X-Sender: To: Nandakumar Ramamurthy Cc: "Rao, Sajjan" , Subject: Draft consistency Q, was Re: Regarding CSG and NSG In-Reply-To: <004d01c233b6$83773f90$6213a8c0@hcltech.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ips@ece.cmu.edu Precedence: bulk On Thu, 25 Jul 2002, Nandakumar Ramamurthy wrote: > Hi, > > The following statement specifies the target's action. > > Section 4.3 of draft-14 says : > > "If the initiator is willing to negotiate security, but is unwilling > to make the initial parameter offer and may accept a connection with- > out security, it issues the Login with the T bit set to 1, the CSG > set to SecurityNegotiation, and NSG set to LoginOperationalNegotia- > tion. If the target is also ready to forego security, the Login > response is empty and has T bit set to 1, the CSG set to SecurityNe- > gotiation, and NSG set to LoginOperationalNegotiation." I see a potential draft conflict between this text and the text about TargetPortalGroupFlag in section 4.3.1. The latter says that the TargetPortalGroupFlag SHOULD be sent in the first Login Response, which would be the "empty" one above. :-) What do we want to do? Take care, Bill From owner-ips@ece.cmu.edu Fri Jul 26 13:06:18 2002 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA00225 for ; Fri, 26 Jul 2002 13:06:13 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id g6QGn4i16117 for ips-outgoing; Fri, 26 Jul 2002 12:49:04 -0400 (EDT) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from homer.qlogic.org ([198.70.193.227]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id g6QGmvo16108 for ; Fri, 26 Jul 2002 12:48:57 -0400 (EDT) X-MimeOLE: Produced By Microsoft Exchange V6.0.5762.3 content-class: urn:content-classes:message Subject: clarification on TargetAddress and TargetName usage MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Date: Fri, 26 Jul 2002 09:47:49 -0700 Message-ID: <2A8D600C919D2D41A3DAA2D2FEC7171401A90D@homer.qlogic.org> Thread-Topic: clarification on TargetAddress and TargetName usage Thread-Index: AcI0xD8S3EUZ6KCdEdaKqABQ2thomQ== From: "Dean Scoville" To: Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ece.cmu.edu id g6QGn2o16111 Sender: owner-ips@ece.cmu.edu Precedence: bulk Content-Transfer-Encoding: 8bit Julian, I would like clarification on when the "TargetAddress" and "TargetName" keys can be sent by the target: Section 10 of the spec lists the keys that can be sent during SecurityNegotiation stage, and states that all other keys MUST NOT be used... "TargetAddress" does not appear in the list, but section 11.8 shows "TargetAddress" usage as "Any-Stage". If I understand correctly, the target must send its address when returning a redirect status, and this can occur during SecurityNegotiation stage. If this is true, could you please add "TargetAddress" to the list of acceptable keys in section 10. Section 11.4 states "The TargetName key may also be returned by the 'SendTargets' text request (which is the only use when issued by a target)." If I interpret this correctly, it means that the target can only send the "TargetName" key in response to a SendTargets request-- which only occurs during full feature phase. But section 11.4 also states the key's usage as "ALL by target". Should the usage be changed to "FFPO by target", or are there other cases besides a 'SendTargets' response when the target is allowed to send this key? regards, Dean Scoville dean.scoville@qlogic.com From owner-ips@ece.cmu.edu Fri Jul 26 13:07:06 2002 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA00288 for ; Fri, 26 Jul 2002 13:07:06 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id g6QGLGD14281 for ips-outgoing; Fri, 26 Jul 2002 12:21:16 -0400 (EDT) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from e2.ny.us.ibm.com (e2.ny.us.ibm.com [32.97.182.102]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id g6QGLFo14277 for ; Fri, 26 Jul 2002 12:21:15 -0400 (EDT) Received: from northrelay02.pok.ibm.com (northrelay02.pok.ibm.com [9.56.224.150]) by e2.ny.us.ibm.com (8.12.2/8.12.2) with ESMTP id g6QGKwe8104066; Fri, 26 Jul 2002 12:20:58 -0400 Received: from d27ml601.rchland.ibm.com (d27ml601.rchland.ibm.com [9.10.226.13]) by northrelay02.pok.ibm.com (8.12.3/NCO/VER6.3) with ESMTP id g6QGKtNK113322; Fri, 26 Jul 2002 12:20:55 -0400 Subject: Re: IPS-ALL: FC Mgmt MIB WG Last Call To: Keith McCloghrie Cc: Elizabeth.G.Rodriguez@123mail.net (Elizabeth G. Rodriguez), ips@ece.cmu.edu, owner-ips@ece.cmu.edu, t11_3@mail.t11.org X-Mailer: Lotus Notes Release 5.0.5 September 22, 2000 Message-ID: From: Duane Baldwin Date: Fri, 26 Jul 2002 11:20:48 -0500 X-MIMETrack: Serialize by Router on d27ml601/27/M/IBM(Build V60_05012002|May 01, 2002) at 07/26/2002 11:20:56 AM MIME-Version: 1.0 Content-type: multipart/related; Boundary="0__=09BBE691DFC1ECF38f9e8a93df938690918c09BBE691DFC1ECF3" Sender: owner-ips@ece.cmu.edu Precedence: bulk --0__=09BBE691DFC1ECF38f9e8a93df938690918c09BBE691DFC1ECF3 Content-type: multipart/alternative; Boundary="1__=09BBE691DFC1ECF38f9e8a93df938690918c09BBE691DFC1ECF3" --1__=09BBE691DFC1ECF38f9e8a93df938690918c09BBE691DFC1ECF3 Content-type: text/plain; charset=US-ASCII Keith, I agree you should not have to do all the work. I am tentatively willing to help push this forward, but first would like input from these two reflectors indicating group interest in providing a complete migration path to this new MIB. Thanks, Duane Baldwin -- Keith McCloghrie To: Duane Baldwin/Rochester/IBM@IBMUS cc: kzm@cisco.com (Keith McCloghrie), Elizabeth.G. 07/26/02 09:50 AM Rodriguez@123mail.net (Elizabeth G. Rodriguez), ips@ece.cmu.edu, owner-ips@ece.cmu.edu, t11_3@mail.t11.org Subject: Re: IPS-ALL: FC Mgmt MIB WG Last Call Duane, > OK, I understand that this MIB is a replacement for both draft-ietf-ipfc- > fcmgmt-int-mib-07.txt and RFC 2837, and it appears to be an excellent > effort relative to these objectives and in fixing the many problems in the > original MIBs. But I also assume one of the priorities of this WG is to > identify the migration path for users of the new MIB, which is why I raised > the issue. (I also raised the same issue back in April of this year.) > > The ability to discover a management URL is important and is widely used > today. Can you help in bringing this requirement to the Entity MIB WG? Or As I indicated in my previous message, I already did what you're asking for; I took the requirement for each of the removed objects to the Entity MIB WG. Some of them have since been adopted there. For the others, perhaps I didn't explain the requirement for them as well as you could. Nevertheless, I believe it will take a sustained effort to get them not only adopted but progressed to standardization. I'm sorry but I don't have the time or motivation for such a sustained effort. In contrast, you seem to be motivated; so, the question is: do you have the time ?? Keith. > maybe as you mention, a management MIB is a better approach - but is there > such an effort underway? The concept of a management URL object could > definitely be improved on relative to "connUnitUrl", such as allowing > multiple URL entries. > > Duane Baldwin > --1__=09BBE691DFC1ECF38f9e8a93df938690918c09BBE691DFC1ECF3 Content-type: text/html; charset=US-ASCII Content-Disposition: inline

Keith,

I agree you should not have to do all the work. I am tentatively willing to help push this forward, but first would like input from these two reflectors indicating group interest in providing a complete migration path to this new MIB.


Thanks, Duane Baldwin

--

Keith McCloghrie <kzm@cisco.com>




          Keith McCloghrie <kzm@cisco.com>

          07/26/02 09:50 AM



To: Duane Baldwin/Rochester/IBM@IBMUS
cc: kzm@cisco.com (Keith McCloghrie), Elizabeth.G.Rodriguez@123mail.net (Elizabeth G. Rodriguez), ips@ece.cmu.edu, owner-ips@ece.cmu.edu, t11_3@mail.t11.org
Subject: Re: IPS-ALL: FC Mgmt MIB WG Last Call


Duane,

> OK, I understand that this MIB is a replacement for both draft-ietf-ipfc-
> fcmgmt-int-mib-07.txt and RFC 2837, and it appears to be an excellent
> effort relative to these objectives and in fixing the many problems in the
> original MIBs. But I also assume one of the priorities of this WG is to
> identify the migration path for users of the new MIB, which is why I raised
> the issue. (I also raised the same issue back in April of this year.)
>
> The ability to discover a management URL is important and is widely used
> today. Can you help in bringing this requirement to the Entity MIB WG? Or

As I indicated in my previous message, I already did what you're asking
for; I took the requirement for each of the removed objects to the
Entity MIB WG. Some of them have since been adopted there. For the
others, perhaps I didn't explain the requirement for them as well as
you could. Nevertheless, I believe it will take a sustained effort to
get them not only adopted but progressed to standardization. I'm sorry
but I don't have the time or motivation for such a sustained effort.
In contrast, you seem to be motivated; so, the question is: do you have
the time ??

Keith.

> maybe as you mention, a management MIB is a better approach - but is there
> such an effort underway? The concept of a management URL object could
> definitely be improved on relative to "connUnitUrl", such as allowing
> multiple URL entries.
>
> Duane Baldwin
>


--1__=09BBE691DFC1ECF38f9e8a93df938690918c09BBE691DFC1ECF3-- --0__=09BBE691DFC1ECF38f9e8a93df938690918c09BBE691DFC1ECF3 Content-type: image/gif; name="graycol.gif" Content-Disposition: inline; filename="graycol.gif" Content-ID: <10__=09BBE691DFC1ECF38f9e8a93df938@us.ibm.com> Content-transfer-encoding: base64 Content-Transfer-Encoding: base64 R0lGODlhEAAQAKECAMzMzAAAAP///wAAACH5BAEAAAIALAAAAAAQABAAAAIXlI+py+0PopwxUbpu ZRfKZ2zgSJbmSRYAIf4fT3B0aW1pemVkIGJ5IFVsZWFkIFNtYXJ0U2F2ZXIhAAA7 --0__=09BBE691DFC1ECF38f9e8a93df938690918c09BBE691DFC1ECF3 Content-type: image/gif; name="ecblank.gif" Content-Disposition: inline; filename="ecblank.gif" Content-ID: <20__=09BBE691DFC1ECF38f9e8a93df938@us.ibm.com> Content-transfer-encoding: base64 Content-Transfer-Encoding: base64 R0lGODlhEAABAIAAAAAAAP///yH5BAEAAAEALAAAAAAQAAEAAAIEjI8ZBQA7 --0__=09BBE691DFC1ECF38f9e8a93df938690918c09BBE691DFC1ECF3 Content-type: image/gif; name="pic11848.gif" Content-Disposition: inline; filename="pic11848.gif" Content-ID: <30__=09BBE691DFC1ECF38f9e8a93df938@us.ibm.com> Content-transfer-encoding: base64 Content-Transfer-Encoding: base64 R0lGODlhWABDALP/AAAAAK04Qf79/o+Gm7WuwlNObwoJFCsoSMDAwGFsmIuezf///wAAAAAAAAAA AAAAACH5BAEAAAgALAAAAABYAEMAQAT/EMlJq704682770RiFMRinqggEUNSHIchG0BCfHhOjAuh EDeUqTASLCbBhQrhG7xis2j0lssNDopE4jfIJhDaggI8YB1sZeZgLVA9YVCpnGagVjV171aRVrYR RghXcAGFhoUETwYxcXNyADJ3GlcSKGAwLwllVC1vjIUHBWsFilKQdI8GA5IcpApeJQt8L09lmgkH LZikoU5wjqcyAMMFrJIDPAKvCFletKSev1HBw8KrxtjZ2tvc3d5VyKtCKW3jfz4uMKmq3xu4N0nK BVoJQmx2LGVOmrqNjjJf2hHAQo/eDwJGTKhQMcgQEEAnEjFS98+RnW3smGkZU6ncCWav/4wYOnAI TihRL/4FEwbp28BXMMcoscQCVxlepL4IGDSCyJyVQOu0o7CjmLN50OZlqWmyFy5/6yBBuji0AxFR M00oQAqNIstqI6qKHUsWRAEAvagsmfUEAImyxgbmUpJk3IklNUtJOUAVLoUr1+wqDGTE4zk+T6FG uQb3SizBCwatiiUgCBN8vrz+zFjVyQ8FWkOlg4NQiZMB5QS8QO3mpOaKnL0Z2EKvNMSILEThKhCg zMKPVxYJh23qm9KNW7pArPynMqZDiErsTMqI+LRi3QAgkFUbXpuFKhSYZALd0O5RKa2z9EYKBbpb qxIKsjUPRgD7I2XYV6wyrOw92ykExP8NW4URhknC5dKGE4v4NENQj2jXjmfNgOZDaXb5glRmXQ33 YEWQYNcZFnrYcIQLNzyTFDQNkXIff0ExVlY4srziQk43inZgL4rwxxINMvpFFAz1KOODHiu+4aEw NEjFl5B3JIKWKF3k6I9bfUGp5ZZcdunll5IA4cuHvQQJ5gcsoCWOOUwgltIwAKRxJgbIkJAQZEq0 2YliZnpZZ4BH3CnYOXldOUOfQoYDqF1LFHbXCrO8xmRsfoXDXJ6ChjCAH3QlhJcT6VWE6FCkfCco CgrMFsROrIEX3o2whVjWDjoJccN3LdggSGXLCdLEgHr1lyU3O3QxhgohNKXJCWv8JQr/PDdaqd6w 2rj1inLiGeiCJoDspAoQlYE6QWLSECehcWIYxIQES6zhbn1iImTHEQyqJ4eIxJJoUBc+3CbBuwZE V5cJPPkIjFDdeEabQbd6WgICTxiiz0f5dBKquXF6k4senwEhYGnKEFJeGrxUZy8dB8gmAXI/sPvH ESfCwVt5hTgYiqQqtdRNHQIU1PJ33ZqmzgE90OwLaoJcnMop1WiMmgkPHQRIrwgFuNV90A3doNKT mrKIN07AnGcI9BQjhCBN4RfA1qIZnMqorJCogKfGQnxSCDilTVIA0yl5ciTovgLuBDKFUDE9aQcw 9SA+rjSNf9/M1gxrj6VwDTS0IUSElMzBfsj0NFXR2kwsV1A5IF1grLgLL/r1R40BZEnuBWgmQEyb jqRwSAt6bqMCOFkvKFN2GPPkUzIm/SCF8z8pVzpbjVnMsy0vOr1hw3SaSRUhpY09v0z0J1FnwzPl fmh+xl4WtR0zGu24I4KbMQm3lnVu2oNWxI9W/lcyzA+mCKF4DBikxb/+UWtOGRiFP8qEwAayIgIA Ow== --0__=09BBE691DFC1ECF38f9e8a93df938690918c09BBE691DFC1ECF3-- From owner-ips@ece.cmu.edu Fri Jul 26 13:09:37 2002 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA00401 for ; Fri, 26 Jul 2002 13:09:37 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id g6QGQ3K14642 for ips-outgoing; Fri, 26 Jul 2002 12:26:03 -0400 (EDT) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from lion.ninthwonder.com (lion.ninthwonder.com [151.199.66.147]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id g6QGQ1o14636 for ; Fri, 26 Jul 2002 12:26:01 -0400 (EDT) Received: by lion.ninthwonder.com (Postfix, from userid 1021) id 4181930706; Fri, 26 Jul 2002 12:26:01 -0400 (EDT) Date: Fri, 26 Jul 2002 09:22:33 -0700 (PDT) From: Bill Studenmund X-X-Sender: To: "BURBRIDGE,MATTHEW (HP-UnitedKingdom,ex2)" Cc: "'Rao, Sajjan'" , Subject: RE: Regarding CSG and NSG In-Reply-To: <0B9A57FF1D57D411B47500D0B73E5CC104FF203C@dickens.bri.hp.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ips@ece.cmu.edu Precedence: bulk On Thu, 25 Jul 2002, BURBRIDGE,MATTHEW (HP-UnitedKingdom,ex2) wrote: > Sajjan, > > It depends whether the initiator has its T bit set. If T=0 then the > initiator is saying that it is security phase and is not yet ready to move > to the next phase (NSG=ignore: if T=0, NSG is reserved). This implies that > it does want to negotiate security (i.e. authentication). If T=1, it says > that is has no more security to negotiate and is ready to move to > operational phase (as NSG=1) when the target says it's ready. In the latter > of these two options (T=1,CSG=0,NSG=1) then the initiator is giving the > target chance to start authentication. > > Alternatively, if the initiator does not want to negotiate security it can > set CSG=1 in the initial login. This removes one message exchange if the > target does not want to negotiate security but runs the risk of receiving a > login failure if the target does want to negotiate security. If it wants to > negotiate parameters then: T=0,CSG=1,NSG=reserved. If it does not want to > negotiate text parameters then T=1, CSG=1, NSG=3. ?? If the initiator has a simple set of text parameters to negotiate (it has keys to offer and it offers them all at once; no keys that it waits for other keys on) it can offer all its keys and T=1, CSG=1, NSG=3. The negotiation can then close in one round trip with all keys negotiated. > In your example I am presuming that T=1 in 1). which is fine. Initiator is > giving the target the opportunity to negotiate security but does not wish to > start it itself. In 2), the T bit MUST be 0 as it can not be the final > login response. The target is informing the initiator that it is happy to > enter operational phase (CSG=1). As the T bit must be 0 in 2) NSG = > reserved. > > 1) Suppose the initiator sets T=1, CSG = 0 and NSG = 1 in login > request, and says requires no authentication. > > 2) Can the target set the CSG = 1 and NSG = full feature phase, in its > login response? NO > > It should be > > 2) Can the target set the T=0, CSG = 1 and NSG = reserved, in its login > response? Uhm, I think that one's wrong too. The target is supposed to return CSG == the CSG in the login request. So if the initiator had CSG=0 (line 1), then the target can't say CSG=1. Take care, Bill From owner-ips@ece.cmu.edu Fri Jul 26 16:28:24 2002 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA07456 for ; Fri, 26 Jul 2002 16:28:24 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id g6QJnCB27317 for ips-outgoing; Fri, 26 Jul 2002 15:49:12 -0400 (EDT) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from maho3msx2.isus.emc.com (maho3msx2.isus.emc.com [128.221.11.32]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id g6QJnAo27313 for ; Fri, 26 Jul 2002 15:49:10 -0400 (EDT) Received: by MAHO3MSX2 with Internet Mail Service (5.5.2653.19) id ; Fri, 26 Jul 2002 15:46:52 -0400 Message-ID: <277DD60FB639D511AC0400B0D068B71E0564C100@CORPMX14> From: Black_David@emc.com To: ips@ece.cmu.edu Subject: Draft references in the iSCSI draft bibliography Date: Fri, 26 Jul 2002 15:46:43 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-ips@ece.cmu.edu Precedence: bulk Public answer to a private question that may be of general interest: > Can you tell me if there is a common understanding as to the use of the > bibliography when it contains IETF draft references that are works in > progress or it contains references for which there are later drafts > available? If the drafts are dependent on each other, does the date of > the release of the draft serve as a marker in time to indicate which > draft version to use? No. Internet-Drafts are *always* referenced as "work in progress" - that means that the reference refers to the latest available version of the draft (which may be subsequent to the numbered version in the reference), or the RFC that results. When the iSCSI Internet-Draft becomes an RFC, it will be held until all Internet-Drafts to which normative references have been made become RFCs so that the RFC can refer to them by RFC number. It is always wrong to claim compliance to an Internet-Draft and doubly so to claim compliance to an obsolete one that has been superseded and removed from the Internet-Draft servers. 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 --------------------------------------------------- From owner-ips@ece.cmu.edu Fri Jul 26 16:30:37 2002 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA07615 for ; Fri, 26 Jul 2002 16:30:37 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id g6QKMK329178 for ips-outgoing; Fri, 26 Jul 2002 16:22:20 -0400 (EDT) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from pepsi.splentec.com (ns.splentec.com [209.47.35.194]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id g6QKMIo29174 for ; Fri, 26 Jul 2002 16:22:18 -0400 (EDT) Received: from splentec.com (canoe.splentec.com [209.47.35.250]) by pepsi.splentec.com (8.11.6/8.11.0) with ESMTP id g6QKM6s19731; Fri, 26 Jul 2002 16:22:06 -0400 Message-ID: <3D41AF71.87DE0FD4@splentec.com> Date: Fri, 26 Jul 2002 16:22:09 -0400 From: Luben Tuikov Organization: Splentec Ltd. X-Mailer: Mozilla 4.79 [en] (X11; U; Linux 2.4.19-rc3 i686) X-Accept-Language: en MIME-Version: 1.0 To: Nandakumar Ramamurthy CC: ips@ece.cmu.edu, Julian Satran , "Mallikarjun C." Subject: Re: iSCSI: INQUIRY, version descriptor References: <3D409B40.289A1D05@splentec.com> <004b01c23470$3efe7440$6213a8c0@hcltech.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ips@ece.cmu.edu Precedence: bulk Content-Transfer-Encoding: 7bit Nandakumar Ramamurthy wrote: > > Consider a target device that conforms to more than eight standards for the > SCSI architecture, and physical standards. In this case the INQUIRY response > data will not contain iSCSI version descriptor. What will be the actions > taken by > the iSCSI target/initiator on finding a target device not conforming to > iSCSI ? Nandakumar, I will repeat AND quote my message again, since it seems that you DIDN'T read it. > > Shouldn't we mention in the draft that Targets should > > set the next available (eq. 0x0000) version descriptor > > to 0x0960 in the INQUIRY data if additional length spans > > it? As you see I said ``the next available (eq. 0x0000)'', so to answer your pointless message: IF THERE IS AVALABLE VERSION DESCRIPTOR THEN THE iSCSI IMPLEMENTATION SHOULD SET IT. So, shouldn't this be mentioned in the draft? Can someone more authoritative comment on this? Julian, Mallikarjun, can you guys comment on this. -- Luben P.S. Nandrakumar, I cannot believe that you ACTUALLY copied and TYPED the standard into your message -- apparently you have NOTHING else to do, but not read messages and type and copy standards into your messages which are readily available on the net. I'm subscribing to 4 more mailing lists and in no one of those it is soooo difficult. Building your carreer in a mailing list is always the wrong thing to do! From owner-ips@ece.cmu.edu Fri Jul 26 18:14:32 2002 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA10785 for ; Fri, 26 Jul 2002 18:14:32 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id g6QLRQX02333 for ips-outgoing; Fri, 26 Jul 2002 17:27:26 -0400 (EDT) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from marantinetworks.com (66-147-154-67.focaldata.net [66.147.154.67] (may be forged)) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id g6QLROo02328 for ; Fri, 26 Jul 2002 17:27:24 -0400 (EDT) Received: from SASTHANA (Sonic.marantinetworks.com [66.147.154.66]) by marantinetworks.com (8.11.2/8.11.2) with SMTP id g6QLVIh19250 for ; Fri, 26 Jul 2002 14:31:18 -0700 Reply-To: From: "Sunil Asthana" To: Subject: test message - Pls Ignore Date: Fri, 26 Jul 2002 14:23:36 -0700 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook CWS, Build 9.0.2416 (9.0.2911.0) Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400 Sender: owner-ips@ece.cmu.edu Precedence: bulk Content-Transfer-Encoding: 7bit From owner-ips@ece.cmu.edu Fri Jul 26 19:42:24 2002 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA12245 for ; Fri, 26 Jul 2002 19:42:24 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id g6QNA7T06786 for ips-outgoing; Fri, 26 Jul 2002 19:10:07 -0400 (EDT) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from pepsi.splentec.com (ns.splentec.com [209.47.35.194]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id g6QNA5o06781 for ; Fri, 26 Jul 2002 19:10:05 -0400 (EDT) Received: from splentec.com (canoe.splentec.com [209.47.35.250]) by pepsi.splentec.com (8.11.6/8.11.0) with ESMTP id g6QN4ms20557; Fri, 26 Jul 2002 19:04:48 -0400 Message-ID: <3D41D593.FE6C0ADB@splentec.com> Date: Fri, 26 Jul 2002 19:04:51 -0400 From: Luben Tuikov Organization: Splentec Ltd. X-Mailer: Mozilla 4.79 [en] (X11; U; Linux 2.4.19-rc3 i686) X-Accept-Language: en MIME-Version: 1.0 To: Nandakumar Ramamurthy , David Black , Julian Satran , "Mallikarjun C." , "elizabethrodriguez@ieee.org" , iSCSI Subject: Alternavtive reply: Re: iSCSI: INQUIRY, version descriptor References: <3D409B40.289A1D05@splentec.com> <004b01c23470$3efe7440$6213a8c0@hcltech.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ips@ece.cmu.edu Precedence: bulk Content-Transfer-Encoding: 7bit Nandakumar Ramamurthy wrote: > > Consider a target device that conforms to more than eight standards for the > SCSI architecture, and physical standards. In this case the INQUIRY response > data will not contain iSCSI version descriptor. What will be the actions > taken by > the iSCSI target/initiator on finding a target device not conforming to > iSCSI ? Obviously nothing. But surely you've figured this for yourself. Anyway, in my original post I do mention: ``the next available (i.e. eq. 0x0000)'' which answers your question above just as well. Now back to business and my original post: Shouldn't this be mentioned in the iSCSI document? It would be much more convenient to find iSCSI related information in the iSCSI document(s) rather dig into the T-10 standards/drafts. Judging by the fact that mode pages are _mentioned_ in iSCSI (I know there are none) -- shows that this was noticed and paid attention to. Then version descriptors could be probably mentioned in section (new) 3.2 and 3.1 become what is now known as 3. Julian, David, Mallikarjun? -- Luben From owner-ips@ece.cmu.edu Sat Jul 27 00:48:52 2002 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA17616 for ; Sat, 27 Jul 2002 00:48:52 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id g6R4CY816803 for ips-outgoing; Sat, 27 Jul 2002 00:12:34 -0400 (EDT) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from pepsi.splentec.com (ns.splentec.com [209.47.35.194]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id g6R4CWo16794 for ; Sat, 27 Jul 2002 00:12:32 -0400 (EDT) Received: from splentec.com (canoe.splentec.com [209.47.35.250]) by pepsi.splentec.com (8.11.6/8.11.0) with ESMTP id g6R4CCs21725; Sat, 27 Jul 2002 00:12:12 -0400 Message-ID: <3D421D9C.7895BA22@splentec.com> Date: Sat, 27 Jul 2002 00:12:12 -0400 From: Luben Tuikov Organization: Splentec Ltd. X-Mailer: Mozilla 4.79 [en] (X11; U; Linux 2.4.19-rc3 i686) X-Accept-Language: en MIME-Version: 1.0 To: Black_David@emc.com CC: nramamur@npd.hcltech.com, elizabethrodriguez@ieee.org, iSCSI Subject: My Appologies -- Re: iSCSI: INQUIRY, version descriptor References: <277DD60FB639D511AC0400B0D068B71E0564C104@CORPMX14> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ips@ece.cmu.edu Precedence: bulk Content-Transfer-Encoding: 7bit Sorry Nandakumar, I misunderstood your message. Upon reading it again, I can see that you were asking me what the target should do, and I was only expecting an anwer to my own question. (I wasn't expecting a question upon question.) -- Luben From owner-ips@ece.cmu.edu Sat Jul 27 04:00:16 2002 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA28509 for ; Sat, 27 Jul 2002 04:00:16 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id g6R7PF122279 for ips-outgoing; Sat, 27 Jul 2002 03:25:15 -0400 (EDT) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from magic.adaptec.com (magic.adaptec.com [208.236.45.80]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id g6R7P8o22274 for ; Sat, 27 Jul 2002 03:25:08 -0400 (EDT) Received: from redfish.adaptec.com (redfish.adaptec.com [162.62.50.11]) by magic.adaptec.com (8.10.2+Sun/8.10.2) with ESMTP id g6R7P2G08681; Sat, 27 Jul 2002 00:25:02 -0700 (PDT) Received: from aimexc02.corp.adaptec.com (aimexc02.corp.adaptec.com [162.62.62.40]) by redfish.adaptec.com (8.8.8+Sun/8.8.8) with ESMTP id AAA28553; Sat, 27 Jul 2002 00:25:01 -0700 (PDT) Received: by aimexc02.corp.adaptec.com with Internet Mail Service (5.5.2653.19) id ; Sat, 27 Jul 2002 00:25:01 -0700 Message-ID: From: "Rao, Sajjan" To: Bill Studenmund , "BURBRIDGE,MATTHEW (HP-UnitedKingdom,ex2)" Cc: ips@ece.cmu.edu Subject: RE: Regarding CSG and NSG Date: Sat, 27 Jul 2002 00:25:00 -0700 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain Sender: owner-ips@ece.cmu.edu Precedence: bulk Bill, If the Initiator says no authentication, then the target has to decide whether it wants to authenticate or not. So if the target wants to forego security, it has to send the CSG = CSG sent by initiator and NSG = NSG sent by the initiator and set T = 1. Am I right?? The initiator would then move send one more login request with probably some more parameters and move into Full feature phase. Thanx, Sajjan -----Original Message----- From: Bill Studenmund [mailto:wrstuden@wasabisystems.com] Sent: Friday, July 26, 2002 9:53 PM To: BURBRIDGE,MATTHEW (HP-UnitedKingdom,ex2) Cc: 'Rao, Sajjan'; ips@ece.cmu.edu Subject: RE: Regarding CSG and NSG On Thu, 25 Jul 2002, BURBRIDGE,MATTHEW (HP-UnitedKingdom,ex2) wrote: > Sajjan, > > It depends whether the initiator has its T bit set. If T=0 then the > initiator is saying that it is security phase and is not yet ready to move > to the next phase (NSG=ignore: if T=0, NSG is reserved). This implies that > it does want to negotiate security (i.e. authentication). If T=1, it says > that is has no more security to negotiate and is ready to move to > operational phase (as NSG=1) when the target says it's ready. In the latter > of these two options (T=1,CSG=0,NSG=1) then the initiator is giving the > target chance to start authentication. > > Alternatively, if the initiator does not want to negotiate security it can > set CSG=1 in the initial login. This removes one message exchange if the > target does not want to negotiate security but runs the risk of receiving a > login failure if the target does want to negotiate security. If it wants to > negotiate parameters then: T=0,CSG=1,NSG=reserved. If it does not want to > negotiate text parameters then T=1, CSG=1, NSG=3. ?? If the initiator has a simple set of text parameters to negotiate (it has keys to offer and it offers them all at once; no keys that it waits for other keys on) it can offer all its keys and T=1, CSG=1, NSG=3. The negotiation can then close in one round trip with all keys negotiated. > In your example I am presuming that T=1 in 1). which is fine. Initiator is > giving the target the opportunity to negotiate security but does not wish to > start it itself. In 2), the T bit MUST be 0 as it can not be the final > login response. The target is informing the initiator that it is happy to > enter operational phase (CSG=1). As the T bit must be 0 in 2) NSG = > reserved. > > 1) Suppose the initiator sets T=1, CSG = 0 and NSG = 1 in login > request, and says requires no authentication. > > 2) Can the target set the CSG = 1 and NSG = full feature phase, in its > login response? NO > > It should be > > 2) Can the target set the T=0, CSG = 1 and NSG = reserved, in its login > response? Uhm, I think that one's wrong too. The target is supposed to return CSG == the CSG in the login request. So if the initiator had CSG=0 (line 1), then the target can't say CSG=1. Take care, Bill From owner-ips@ece.cmu.edu Sat Jul 27 10:01:56 2002 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA02070 for ; Sat, 27 Jul 2002 10:01:56 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id g6RDKUb14966 for ips-outgoing; Sat, 27 Jul 2002 09:20:30 -0400 (EDT) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from mail.ivivity.com ([64.238.111.99]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id g6RDKSo14959 for ; Sat, 27 Jul 2002 09:20:28 -0400 (EDT) Received: by ATLOPS with Internet Mail Service (5.5.2653.19) id ; Sat, 27 Jul 2002 09:20:12 -0400 Message-ID: From: Eddy Quicksall To: Julian Satran , ips@ece.cmu.edu Subject: RE: iSCSI: v15 R2T and DATA-OUT Date: Sat, 27 Jul 2002 09:20:07 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-ips@ece.cmu.edu Precedence: bulk There should not be a requirement for the initiator to check for consistency. This would just serve to impact performance. It would be OK to check but the target should be responsible to set the LUN correctly and the initiator should just copy it as is. BTW, the LUN in the R2T only has use by the target ("are used by the target only"). If the target doesn't need it, then why should it take the time to supply it? Does anyone know why this is in the R2T anyway? It would seem like the TTT would say it all. Eddy -----Original Message----- From: Julian Satran [mailto:Julian_Satran@il.ibm.com] Sent: Friday, July 26, 2002 5:04 AM To: ips@ece.cmu.edu Subject: RE: iSCSI: v15 R2T and DATA-OUT I will add a strong statement about field consistency somewhere in 2. Julo "Rod Harrison" cc: Subject: RE: iSCSI: v15 R2T and DATA-OUT 07/26/2002 03:08 AM Julian, OK, that's the answer to my question then. The wording that's there right now doesn't say what the initiator should do if the LUN in an R2T doesn't match the LUN it sent in the command PDU. So the resolution is that the initiator should treat a LUN inconsistency between R2T and command as a protocol error. I suggest we add a note to that effect where we talk about LUN in the R2T PDU description, that would be 9.8.5 in the v15 working draft. - Rod -----Original Message----- From: Julian Satran [mailto:Julian_Satran@il.ibm.com] Sent: Thursday, July 25, 2002 6:53 PM To: Rod Harrison Cc: ips@ece.cmu.edu Subject: RE: iSCSI: v15 R2T and DATA-OUT Rod, Probably a very long day. LUN is present in the command. Command is associated with ITT. R2T can be checked for a consistent ITT and LUN. End-story. Julo "Rod Harrison" 07/25/2002 06:49 AM To: cc: Julian Satran/Haifa/IBM@IBMIL Subject: RE: iSCSI: v15 R2T and DATA-OUT OK, it's been a long day. Let me try this one more time. I was write (almost) first time but I meant DATA-OUT instead of DATA-IN. Here's what I meant to say ... There is a potential inconsistency in the description of the use of the LUN field in DATA-OUT and R2T in the working v15 draft. 9.7.3 Target Transfer Tag, for DATA-OUT last paragraph says ... "If the Target Transfer Tag is provided, then the LUN field MUST hold a valid value and be consistent with whatever was specified with the command;" 9.8.5 Target Transfer Tag, for R2T says ... "The Target Transfer Tag and LUN are copied in the outgoing data PDUs and are used by the target only." Potentially a target could return a different LUN field in the R2T, for perhaps some funky LUN mapping or other internal reason expecting it to be copied to the DATA-OUT as per the R2T text. I think we need to indicate what is expected of the initiator if the LUN field in the R2T does not match the LUN in the command PDU. - Rod -----Original Message----- From: Rod Harrison [mailto:rod.harrison@windriver.com] Sent: Wednesday, July 24, 2002 8:57 PM To: Julian Satran Cc: ips@ece.cmu.edu Subject: RE: iSCSI: v15 R2T and DATA-OUT Oops, I see the confusion. I said DATA-IN in my message when I meant DATA-OUT. However, re-reading the section of v15 in question I now see that the third paragraph is referring to the DATA-IN LUN, not the DATA-OUT LUN. That wasn't clear to me when first scanned it because of the paragraph break. Perhaps a note of clarification needs to be added? - Rod -----Original Message----- From: Rod Harrison [mailto:rod.harrison@windriver.com] Sent: Wednesday, July 24, 2002 8:51 PM To: Julian Satran Cc: ips@ece.cmu.edu Subject: RE: iSCSI: v15 R2T and DATA-OUT Julian, I think you've misread my message. I was questioning how the initiator should handle the LUN between an R2T and the DATA-OUT(s) that satisfy it. DATA-OUT says copy the LUN from the command PDU, R2T says copy the LUN from the R2T to the DATA-OUT. Which is correct if the R2T contains a different LUN than that in the command PDU? - Rod -----Original Message----- From: Julian Satran [mailto:Julian_Satran@il.ibm.com] Sent: Wednesday, July 24, 2002 5:00 PM To: Rod Harrison Cc: ips@ece.cmu.edu; owner-ips@ece.cmu.edu Subject: Re: iSCSI: v15 R2T and DATA-OUT There is no TTT for data-In. Julo "Rod Harrison" driver.com> cc: Sent by: Subject: iSCSI: v15 R2T and DATA-OUT owner-ips@ece.cmu .edu 07/24/2002 10:24 PM Folks, There is a potential inconsistency in the description of the use of the LUN field in DATA-OUT and R2T in the working v15 draft. 9.7.3 Target Transfer Tag, for DATA-IN last paragraph says ... "If the Target Transfer Tag is provided, then the LUN field MUST hold a valid value and be consistent with whatever was specified with the command;" 9.8.5 Target Transfer Tag, for R2T says ... "The Target Transfer Tag and LUN are copied in the outgoing data PDUs and are used by the target only." Potentially a target could return a different LUN field in the R2T, for perhaps some funky LUN mapping or other internal reason expecting it to be copied to the DATA-OUT as per the R2T text. I suspect we just want to say this is not allowed and the LUN field MUST be the same as the command PDU. Either way I think we need to indicate what is expected of the initiator if the LUN field in the R2T does not match the LUN in the command PDU. Apologies for not spotting this before the end of last call. - Rod From owner-ips@ece.cmu.edu Sat Jul 27 10:02:45 2002 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA02090 for ; Sat, 27 Jul 2002 10:02:45 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id g6RDbQx15507 for ips-outgoing; Sat, 27 Jul 2002 09:37:26 -0400 (EDT) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from d12lmsgate.de.ibm.com (d12lmsgate.de.ibm.com [195.212.91.199]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id g6RDbNo15499; Sat, 27 Jul 2002 09:37:23 -0400 (EDT) Received: from d12relay02.de.ibm.com (d12relay02.de.ibm.com [9.165.215.23]) by d12lmsgate.de.ibm.com (8.12.3/8.12.3) with ESMTP id g6RDbE9l043872; Sat, 27 Jul 2002 15:37:14 +0200 Received: from d10hubm1.telaviv.ibm.com (d10ml001.telaviv.ibm.com [9.148.216.55]) by d12relay02.de.ibm.com (8.12.3/NCO/VER6.3) with ESMTP id g6RDb723027832; Sat, 27 Jul 2002 15:37:15 +0200 To: Luben Tuikov Cc: iSCSI , owner-ips@ece.cmu.edu MIME-Version: 1.0 Subject: Re: iSCSI: strengthening queue condition on pg 37 [v 15] X-Mailer: Lotus Notes Release 5.0.9 November 16, 2001 From: "Julian Satran" Message-ID: Date: Sat, 27 Jul 2002 16:37:03 +0300 X-MIMETrack: Serialize by Router on D10ML001/10/M/IBM(Release 5.0.9a |January 7, 2002) at 27/07/2002 16:37:14, Serialize complete at 27/07/2002 16:37:14 Content-Type: multipart/alternative; boundary="=_alternative 004A2307C2256C03_=" Sender: owner-ips@ece.cmu.edu Precedence: bulk This is a multipart message in MIME format. --=_alternative 004A2307C2256C03_= Content-Type: text/plain; charset="us-ascii" that is not what the text says - and it is not accidental. Julo Luben Tuikov Sent by: owner-ips@ece.cmu.edu 07/26/2002 03:54 AM To: iSCSI cc: Subject: iSCSI: strengthening queue condition on pg 37 [v 15] The condition on page 37: -If the PDU MaxCmdSN is less than the PDU ExpCmdSN-1 (in Serial Arithmetic Sense), they are both ignored. can be strengthened by specifying ``less than or equal''. Then and only then is the queue size > 0. -- Luben P.S. Proof: Ignore* if maxcmdsn <= expcmdsn-1. Thus accept if maxcmdsn > expcmdsn-1, which is maxcmdsn-expcmdsn+1 > 0, but maxcmdsn-expcmdsn+1 is the queue size, so accept* only if queue size > 0. *Meaning ignore/accept the values of maxcmdsn and expcmdsn. --=_alternative 004A2307C2256C03_= Content-Type: text/html; charset="us-ascii"
that is not what the text says - and it is not accidental. Julo


Luben Tuikov <luben@splentec.com>
Sent by: owner-ips@ece.cmu.edu

07/26/2002 03:54 AM

       
        To:        iSCSI <ips@ece.cmu.edu>
        cc:        
        Subject:        iSCSI: strengthening queue condition on pg 37 [v 15]

       


The condition on page 37:

-If the PDU MaxCmdSN is less than the PDU ExpCmdSN-1 (in Serial
Arithmetic Sense), they are both ignored.

can be strengthened by specifying ``less than or equal''.
Then and only then is the queue size > 0.

--
Luben

P.S. Proof: Ignore* if  maxcmdsn <= expcmdsn-1.
Thus accept if maxcmdsn > expcmdsn-1,
which is maxcmdsn-expcmdsn+1 > 0,
but maxcmdsn-expcmdsn+1 is the queue size,
so accept* only if queue size > 0.

*Meaning ignore/accept the values of maxcmdsn and expcmdsn.

--=_alternative 004A2307C2256C03_=-- From owner-ips@ece.cmu.edu Sat Jul 27 10:04:46 2002 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA02112 for ; Sat, 27 Jul 2002 10:04:46 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id g6RDbW815527 for ips-outgoing; Sat, 27 Jul 2002 09:37:32 -0400 (EDT) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from d12lmsgate-2.de.ibm.com (d12lmsgate-2.de.ibm.com [195.212.91.200]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id g6RDbTo15517 for ; Sat, 27 Jul 2002 09:37:29 -0400 (EDT) Received: from d12relay02.de.ibm.com (d12relay02.de.ibm.com [9.165.215.23]) by d12lmsgate-2.de.ibm.com (8.12.3/8.12.3) with ESMTP id g6RDbJcn021064; Sat, 27 Jul 2002 15:37:19 +0200 Received: from d10hubm1.telaviv.ibm.com (d10ml001.telaviv.ibm.com [9.148.216.55]) by d12relay02.de.ibm.com (8.12.3/NCO/VER6.3) with ESMTP id g6RDbI23027836; Sat, 27 Jul 2002 15:37:18 +0200 To: kevin_lemay@agilent.com Cc: ips@ece.cmu.edu, kevin_lemay@agilent.com, pat_thaler@agilent.com, rdr@io.iol.unh.edu MIME-Version: 1.0 Subject: RE: iSCSI: Use of Reject as a key value X-Mailer: Lotus Notes Release 5.0.9 November 16, 2001 From: "Julian Satran" Message-ID: Date: Sat, 27 Jul 2002 16:37:08 +0300 X-MIMETrack: Serialize by Router on D10ML001/10/M/IBM(Release 5.0.9a |January 7, 2002) at 27/07/2002 16:37:18, Serialize complete at 27/07/2002 16:37:18 Content-Type: multipart/alternative; boundary="=_alternative 004ABB20C2256C03_=" Sender: owner-ips@ece.cmu.edu Precedence: bulk This is a multipart message in MIME format. --=_alternative 004ABB20C2256C03_= Content-Type: text/plain; charset="us-ascii" Kevin, The current text says explicitly that reject is a valid response (i.e., not a protocol error). The addition makes only explicit the obvious. On the other hand a reject may be bad for some parameters (e.g., some locally enforced authentication). In that case you are free to close the session with a login error. But that IS NOT the general case. The wording about Reject not being a protocol error is NOT a change. Julo kevin_lemay@agilent.com 07/26/2002 05:54 PM To: Julian Satran/Haifa/IBM@IBMIL, kevin_lemay@agilent.com cc: ips@ece.cmu.edu, pat_thaler@agilent.com, rdr@io.iol.unh.edu Subject: RE: iSCSI: Use of Reject as a key value The iSCSI spec did not specify the handling of reject prior to the current v15 working version. I am NOT proposing changing the case sensitivity. I am merely pointing out a potential problem in the proposed handling of reject during login negotiation. Our current implementation handles it as described by Professor Russell as "Case 2", the rejection of a parameter during login (except for markers) terminates the login. My example was meant to demonstrate the problem associated with continuing the login with rejected parameters. The initiator and target have the potential to continue with miss-matched parameters. Professor Russell had three proposals in what he posted. He was not requesting a particular wording but meant to open it up to the list for discussion and a solution. Kevin -----Original Message----- From: Julian Satran [mailto:Julian_Satran@il.ibm.com] Sent: Friday, July 26, 2002 1:33 AM To: kevin_lemay@agilent.com Cc: ips@ece.cmu.edu; Julian Satran; pat_thaler@agilent.com; rdr@io.iol.unh.edu Subject: RE: iSCSI: Use of Reject as a key value Do you propose the formulate the standard so that it can tolerate all initiator syntax errors? Or just we state that it should be case insensitive. The first would be a bad idea. The protocol has enough complexity in order to deal with transport errors. It would be a bad idea to add implementation errors to the list. If you want case insensitivity - this was discussed and rejected a long time ago - again because it felt unnecessary. I would also like to point out that this is not a change. This behavior was always assumed (and implied in the statements about negotiations atomicity). The statement was added at the request of Bob Russell as a clarification. Julo kevin_lemay@agile nt.com To: Julian Satran/Haifa/IBM@IBMIL, rdr@io.iol.unh.edu cc: ips@ece.cmu.edu, pat_thaler@agilent.com 07/25/2002 09:59 Subject: RE: iSCSI: Use of Reject as a key value PM Julian, I think that this change is a bad idea. The spec says that: "If the acceptor sends "Reject" as an answer the negotiated key is left at its current value (or default if no value was set). If the current value is not acceptable to the proposer on the connection or session it is sent the proposer MAY choose to terminate the connec- tion or session." But what happens in the following case: i->ImmediateData=Yes t->ImmediateData=no (Note: wrong case used) The initiator must use the default, which is ImmediateData=Yes, and there is no way for the initiator to inform the target of the error because sending: i->ImmediateData=Reject would be a re-negotiation. This will not work! Kevin -----Original Message----- From: Julian Satran [mailto:Julian_Satran@il.ibm.com] Sent: Wednesday, July 24, 2002 7:52 PM To: Robert D. Russell Cc: ips@ece.cmu.edu; owner-ips@ece.cmu.edu Subject: Re: iSCSI: Use of Reject as a key value Bob, On the last pdf you will find a statement about what to do. Julo "Robert D. Russell" Sent by: owner-ips@ece.cmu.edu 07/25/2002 12:58 AM To: ips@ece.cmu.edu cc: Subject: iSCSI: Use of Reject as a key value Julian: Attached are 2 ascii text files. The first, reject_extracts.txt, contains all the pieces of draft 14 (the latest available txt version of the drafts) that say anything about the use of Reject as a key value. (At least all those I could find using simple search -- unfortunately, Reject is also the name of a PDU and hence it is not a simple mechanical process to distinguish the two uses! If I missed some, please let me know.) The second, reject_comments.txt, are my comments on these excerpts from the standard. It seems to me that the key thing missing in the standard is a general statement about "what to do next" if a key=Reject response is received. Except for the OFMarkInt and IFMarkInt keys, I could find no other statement about how to proceed after receiving the key=Reject response. In looking through the e-mails posted to the list for June and July, I also could find nothing, although many people seem to be taking the third of the 3 interpretations I listed in reject_comments.txt. I am requesting a clear statement somewhere in the standard that says "what to do next" upon receiving a key=Reject response. Thank you for your consideration. Bob Russell InterOperability Lab University of New Hampshire rdr@iol.unh.edu 603-862-3774 #### reject_extracts.txt has been removed from this note on July 25 2002 by Julian Satran #### reject_comments.txt has been removed from this note on July 25 2002 by Julian Satran --=_alternative 004ABB20C2256C03_= Content-Type: text/html; charset="us-ascii"
Kevin,

The current text says explicitly that reject is a valid response (i.e., not a protocol error).
The addition makes only explicit the obvious.
On the other hand a reject may be bad for some parameters (e.g., some locally enforced authentication).
In that case you are free to close the session with a login error.
But that IS NOT the general case. The wording about Reject not being a protocol error is NOT a change.

Julo


kevin_lemay@agilent.com

07/26/2002 05:54 PM

       
        To:        Julian Satran/Haifa/IBM@IBMIL, kevin_lemay@agilent.com
        cc:        ips@ece.cmu.edu, pat_thaler@agilent.com, rdr@io.iol.unh.edu
        Subject:        RE: iSCSI: Use of Reject as a key value

       


The iSCSI spec did not specify the handling of reject prior to the current v15 working version.

I am NOT proposing changing the case sensitivity.

I am merely pointing out a potential problem in the proposed handling of reject during login negotiation.

Our current implementation handles it as described by Professor Russell as "Case 2", the rejection of a parameter during login (except for markers) terminates the login.

My example was meant to demonstrate the problem associated with continuing the login with rejected parameters. The initiator and target have the potential to continue with miss-matched parameters.

Professor Russell had three proposals in what he posted. He was not requesting a particular wording but meant to open it up to the list for discussion and a solution.

Kevin

-----Original Message-----
From: Julian Satran [mailto:Julian_Satran@il.ibm.com]
Sent: Friday, July 26, 2002 1:33 AM
To: kevin_lemay@agilent.com
Cc: ips@ece.cmu.edu; Julian Satran; pat_thaler@agilent.com;
rdr@io.iol.unh.edu
Subject: RE: iSCSI: Use of Reject as a key value


Do you propose the formulate the standard so that it can tolerate all
initiator syntax errors? Or just we state that it should be case
insensitive.
The first would be a bad idea. The protocol has enough complexity in order
to deal with transport errors. It would be a bad idea to add
implementation errors to the list.
If you want case insensitivity - this was discussed and rejected a long
time ago - again because it felt unnecessary.

I would also like to point out that this is not a change. This behavior was
always assumed (and implied in the statements about negotiations
atomicity).
The statement was added at the request of Bob Russell as a clarification.

Julo




                                                                                                                                           
                     kevin_lemay@agile                                                                                                    
                     nt.com                   To:       Julian Satran/Haifa/IBM@IBMIL, rdr@io.iol.unh.edu                                  
                                              cc:       ips@ece.cmu.edu, pat_thaler@agilent.com                                            
                     07/25/2002 09:59         Subject:  RE: iSCSI: Use of Reject as a key value                                            
                     PM                                                                                                                    
                                                                                                                                           
                                                                                                                                           



Julian,

I think that this change is a bad idea.

The spec says that:

"If the acceptor sends "Reject" as an answer the negotiated key is left at
its current value (or default if no value was set). If the current value is
not acceptable to the proposer on the connection or session it is sent the
proposer MAY choose to terminate the connec- tion or session."

But what happens in the following case:

i->ImmediateData=Yes
t->ImmediateData=no (Note: wrong case used)

The initiator must use the default, which is ImmediateData=Yes, and there
is no way for the initiator to inform the target of the error because
sending:
i->ImmediateData=Reject would be a re-negotiation.

This will not work!

Kevin

-----Original Message-----
From: Julian Satran [mailto:Julian_Satran@il.ibm.com]
Sent: Wednesday, July 24, 2002 7:52 PM
To: Robert D. Russell
Cc: ips@ece.cmu.edu; owner-ips@ece.cmu.edu
Subject: Re: iSCSI: Use of Reject as a key value



Bob,

On the last pdf you will find a statement about what to do.

Julo



            "Robert D. Russell" <rdr@io.iol.unh.edu>
Sent by: owner-ips@ece.cmu.edu


07/25/2002 12:58 AM



       To:        ips@ece.cmu.edu
       cc:
       Subject:        iSCSI: Use of Reject as a key value







Julian:

Attached are 2 ascii text files.

The first, reject_extracts.txt, contains all the pieces of
draft 14 (the latest available txt version of the drafts)
that say anything about the use of Reject as a key value.
(At least all those I could find using simple search --
unfortunately, Reject is also the name of a PDU and hence
it is not a simple mechanical process to distinguish the two
uses!  If I missed some, please let me know.)

The second, reject_comments.txt, are my comments on these
excerpts from the standard.

It seems to me that the key thing missing in the standard is
a general statement about "what to do next" if a key=Reject response
is received.  Except for the OFMarkInt and IFMarkInt keys,
I could find no other statement about how to proceed after
receiving the key=Reject response.  In looking through the
e-mails posted to the list for June and July, I also could find
nothing, although many people seem to be taking the third
of the 3 interpretations I listed in reject_comments.txt.

I am requesting a clear statement somewhere in the standard that
says "what to do next" upon receiving a key=Reject response.

Thank you for your consideration.

Bob Russell
InterOperability Lab
University of New Hampshire
rdr@iol.unh.edu
603-862-3774







#### reject_extracts.txt has been removed from this note on July 25 2002 by
Julian Satran
#### reject_comments.txt has been removed from this note on July 25 2002 by
Julian Satran

--=_alternative 004ABB20C2256C03_=-- From owner-ips@ece.cmu.edu Sat Jul 27 14:01:18 2002 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA05424 for ; Sat, 27 Jul 2002 14:01:18 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id g6RHGBn22812 for ips-outgoing; Sat, 27 Jul 2002 13:16:11 -0400 (EDT) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from astutenetworks.com (2.astutenetworks.com [216.142.74.2]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id g6RHG9o22808 for ; Sat, 27 Jul 2002 13:16:09 -0400 (EDT) Received: from amirdesktop (dhcp62 [172.21.2.62]) by astutenetworks.com (8.11.6/8.11.2) with SMTP id g6RHG1E16706; Sat, 27 Jul 2002 10:16:01 -0700 From: "Amir Shalit" To: "Julian Satran" Cc: Subject: Piggybacking session window in data phase Date: Sat, 27 Jul 2002 10:15:59 -0700 Message-ID: MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_00AC_01C23556.9A33F0B0" X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0) Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4807.1700 In-Reply-To: Sender: owner-ips@ece.cmu.edu Precedence: bulk This is a multi-part message in MIME format. ------=_NextPart_000_00AC_01C23556.9A33F0B0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Piggybacking session window information in data phase is hurting fast path performance. Can it be avoided? Target can always use NOP-IN to update session window if it feels an urge to do so. Amir ------=_NextPart_000_00AC_01C23556.9A33F0B0 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

 
Piggybacking session window information in = data phase=20 is hurting fast path performance.
Can it=20 be avoided? Target can always use NOP-IN to update session window if it=20 feels
an=20 urge to do so.
 
Amir
 
 
------=_NextPart_000_00AC_01C23556.9A33F0B0-- From owner-ips@ece.cmu.edu Sat Jul 27 14:02:23 2002 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA05441 for ; Sat, 27 Jul 2002 14:02:23 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id g6RHkqD23959 for ips-outgoing; Sat, 27 Jul 2002 13:46:52 -0400 (EDT) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from pkoning.akdesign.com (082-46-189-66.wo.cpe.charter-ne.com [66.189.46.82]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id g6RHkoo23954 for ; Sat, 27 Jul 2002 13:46:51 -0400 (EDT) Received: from pkoning.akdesign.com.equallogic.com (IDENT:pkoning@localhost [127.0.0.1]) by pkoning.akdesign.com (8.11.6/8.9.3) with SMTP id g6RHkgu01330; Sat, 27 Jul 2002 13:46:46 -0400 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <15682.56450.799636.542281@pkoning.akdesign.com> Date: Sat, 27 Jul 2002 13:46:42 -0400 From: Paul Koning To: eddy_quicksall@ivivity.com Cc: Julian_Satran@il.ibm.com, ips@ece.cmu.edu Subject: RE: iSCSI: v15 R2T and DATA-OUT References: X-Mailer: VM 7.01 under 21.1 (patch 11) "Carlsbad Caverns" XEmacs Lucid Sender: owner-ips@ece.cmu.edu Precedence: bulk Content-Transfer-Encoding: 7bit >>>>> "Eddy" == Eddy Quicksall writes: Eddy> There should not be a requirement for the initiator to check Eddy> for consistency. This would just serve to impact Eddy> performance. It would be OK to check but the target should be Eddy> responsible to set the LUN correctly and the initiator should Eddy> just copy it as is. What I would say is: 1. The target is responsible for sending the LUN correctly in R2T. 2. The initiator doesn't have to check it. and that is all. This leaves it unspecified what the initiator might do if the target commits a protocol violation: it might send back the correct LUN, or the wrong value from the R2T, or it might close the connection, or ... I definitely would not want to see an expectation created that a target can expect to see the LUN from the R2T echoed back to it if it puts a value other than the correct one in there. paul From owner-ips@ece.cmu.edu Sat Jul 27 17:07:17 2002 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA07482 for ; Sat, 27 Jul 2002 17:07:12 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id g6RKRmA29486 for ips-outgoing; Sat, 27 Jul 2002 16:27:48 -0400 (EDT) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from d12lmsgate-3.de.ibm.com (d12lmsgate-3.de.ibm.com [195.212.91.201]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id g6RKRko29481; Sat, 27 Jul 2002 16:27:46 -0400 (EDT) Received: from d12relay02.de.ibm.com (d12relay02.de.ibm.com [9.165.215.23]) by d12lmsgate-3.de.ibm.com (8.12.3/8.12.3) with ESMTP id g6RKRdZ7023382; Sat, 27 Jul 2002 22:27:39 +0200 Received: from d10hubm1.telaviv.ibm.com (d10ml001.telaviv.ibm.com [9.148.216.55]) by d12relay02.de.ibm.com (8.12.3/NCO/VER6.3) with ESMTP id g6RKRZ23133528; Sat, 27 Jul 2002 22:27:39 +0200 Subject: Re: iSCSI: INQUIRY, version descriptor To: Luben Tuikov Cc: iSCSI , owner-ips@ece.cmu.edu X-Mailer: Lotus Notes Release 5.0.9 November 16, 2001 Message-ID: From: "Julian Satran" Date: Sat, 27 Jul 2002 22:55:42 +0300 X-MIMETrack: Serialize by Router on D10ML001/10/M/IBM(Release 5.0.9a |January 7, 2002) at 27/07/2002 23:27:39 MIME-Version: 1.0 Content-type: text/plain; charset=us-ascii Sender: owner-ips@ece.cmu.edu Precedence: bulk Luben, We can't keep repeating SPC text in iSCSI only because it is convenient - we will get to copy it all! An iSCSI implementor should have at least SAM, SPC and iSCSI on his desk. Julo Luben Tuikov om> cc: Sent by: Subject: iSCSI: INQUIRY, version descriptor owner-ips@ece.cmu .edu 07/26/2002 03:43 AM Shouldn't we mention in the draft that Targets should set the next available (eq. 0x0000) version descriptor to 0x0960 in the INQUIRY data if additional length spans it? It is mentioned in SPC-3 (and SPC-2) and it would be more convenient for implementors to see it in the iSCSI document as well. -- Luben From owner-ips@ece.cmu.edu Sun Jul 28 10:18:40 2002 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA26841 for ; Sun, 28 Jul 2002 10:18:40 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id g6SDWxJ10683 for ips-outgoing; Sun, 28 Jul 2002 09:32:59 -0400 (EDT) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from d12lmsgate-2.de.ibm.com (d12lmsgate-2.de.ibm.com [195.212.91.200]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id g6SDWvo10679 for ; Sun, 28 Jul 2002 09:32:57 -0400 (EDT) Received: from d12relay01.de.ibm.com (d12relay01.de.ibm.com [9.165.215.22]) by d12lmsgate-2.de.ibm.com (8.12.3/8.12.3) with ESMTP id g6SDWowZ017040 for ; Sun, 28 Jul 2002 15:32:51 +0200 Received: from d10hubm1.telaviv.ibm.com (d10ml001.telaviv.ibm.com [9.148.216.55]) by d12relay01.de.ibm.com (8.12.3/NCO/VER6.3) with ESMTP id g6SDWoGF043870 for ; Sun, 28 Jul 2002 15:32:50 +0200 Subject: iSCSI - working draft and IANA To: ips@ece.cmu.edu X-Mailer: Lotus Notes Release 5.0.9 November 16, 2001 Message-ID: From: "Julian Satran" Date: Sun, 28 Jul 2002 16:05:59 +0300 X-MIMETrack: Serialize by Router on D10ML001/10/M/IBM(Release 5.0.9a |January 7, 2002) at 28/07/2002 16:32:50 MIME-Version: 1.0 Content-type: text/plain; charset=us-ascii Sender: owner-ips@ece.cmu.edu Precedence: bulk Dear colleagues, The current (today's) version of the draft has a revised IANA consideration section and specific indication on how to build keys, authentication methods and digests. David Black suggested that we might want to go for 3 different registries maintained by IANA for iSCSI and I liked the idea. Please comment, Julo From owner-ips@ece.cmu.edu Sun Jul 28 22:03:39 2002 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA06188 for ; Sun, 28 Jul 2002 22:03:39 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id g6T1NG607531 for ips-outgoing; Sun, 28 Jul 2002 21:23:16 -0400 (EDT) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from iol.unh.edu (io.iol.unh.edu [132.177.123.82]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id g6S25Zo10914 for ; Sat, 27 Jul 2002 22:05:35 -0400 (EDT) Received: from io.iol.unh.edu (localhost.localdomain [127.0.0.1]) by iol.unh.edu (8.12.3/8.12.3) with ESMTP id g6S25T6U015537 for ; Sat, 27 Jul 2002 22:05:29 -0400 Received: from localhost (qtao@localhost) by io.iol.unh.edu (8.12.3/8.12.3/Submit) with ESMTP id g6S25THb015534 for ; Sat, 27 Jul 2002 22:05:29 -0400 Date: Sat, 27 Jul 2002 22:05:29 -0400 (EDT) From: Qin Tao To: ips@ece.cmu.edu Subject: about iSCSI testing at UNH Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ips@ece.cmu.edu Precedence: bulk Hi, Just want to make it clear about the questions raised in the Yokohama meeting about the iSCSI testing at UNH: 1. Currently, the in-lab testing at UNH is only available for the member companies and there is no charge for member companies to have the in-lab testing. 2. The registered companies' names for the 4th iSCSI plugfest at UNH are posted on our web(www.iol.unh.edu) under the "Group Test Period Info." link. The UNH presentation in the Yokohama meeting is on the web too. Best, Qin ***************************************************** * * * Qin Tao * * iSCSI Consortium * * InterOperability Lab. * * University of New Hampshire * * Durham, NH 03824 * * * ***************************************************** From owner-ips@ece.cmu.edu Mon Jul 29 05:01:02 2002 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA21396 for ; Mon, 29 Jul 2002 05:01:02 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id g6T8Ks221903 for ips-outgoing; Mon, 29 Jul 2002 04:20:54 -0400 (EDT) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from PCCW-MARRIOTT-HK.solutionip.com (ipvpn021091.netvigator.com [203.198.76.91]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id g6T8Kpo21897 for ; Mon, 29 Jul 2002 04:20:51 -0400 (EDT) Received: from [10.0.2.143] (helo=JA31) by PCCW-MARRIOTT-HK.solutionip.com with esmtp (Exim 3.01 #1) id 17Z5lk-0007wW-00; Mon, 29 Jul 2002 16:20:44 +0800 Message-ID: <004001c236d8$d406da90$8f02000a@JA31> From: "Julian Satran \(Actcom\)" To: "Amir Shalit" Cc: References: Subject: Re: Piggybacking session window in data phase Date: Mon, 29 Jul 2002 11:20:39 +0300 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_003D_01C236F1.F80A0660" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2600.0000 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 Sender: owner-ips@ece.cmu.edu Precedence: bulk This is a multi-part message in MIME format. ------=_NextPart_000_003D_01C236F1.F80A0660 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable That is purely an implementation issue. I have seen some where it does not. Look carefully at what piggyback information you must use and when. Julo ----- Original Message -----=20 From: Amir Shalit=20 To: Julian Satran=20 Cc: ips@ece.cmu.edu=20 Sent: Saturday, July 27, 2002 8:15 PM Subject: Piggybacking session window in data phase Piggybacking session window information in data phase is hurting fast = path performance. Can it be avoided? Target can always use NOP-IN to update session = window if it feels an urge to do so. Amir ------=_NextPart_000_003D_01C236F1.F80A0660 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
That is purely an implementation=20 issue.
I have seen some where it does = not.
Look carefully at what piggyback = information you=20 must use and when.
 
Julo
----- Original Message -----
From:=20 Amir=20 Shalit
Sent: Saturday, July 27, 2002 = 8:15=20 PM
Subject: Piggybacking session = window in=20 data phase

 
Piggybacking session window information in = data phase=20 is hurting fast path performance.
Can=20 it be avoided? Target can always use NOP-IN to update session window = if it=20 feels
an=20 urge to do so.
 
Amir
 
 
------=_NextPart_000_003D_01C236F1.F80A0660-- From owner-ips@ece.cmu.edu Mon Jul 29 05:03:57 2002 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA21442 for ; Mon, 29 Jul 2002 05:03:57 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id g6T8SDb22161 for ips-outgoing; Mon, 29 Jul 2002 04:28:13 -0400 (EDT) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from d12lmsgate-3.de.ibm.com (d12lmsgate-3.de.ibm.com [195.212.91.201]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id g6T8SBo22157 for ; Mon, 29 Jul 2002 04:28:12 -0400 (EDT) Received: from d12relay02.de.ibm.com (d12relay02.de.ibm.com [9.165.215.23]) by d12lmsgate-3.de.ibm.com (8.12.3/8.12.3) with ESMTP id g6T8RvTB044796; Mon, 29 Jul 2002 10:27:57 +0200 Received: from JA31 (sineukopnav2.uk.ibm.com [9.141.220.34]) by d12relay02.de.ibm.com (8.12.3/NCO/VER6.3) with ESMTP id g6T8RrBI009530; Mon, 29 Jul 2002 10:27:55 +0200 Message-ID: <005a01c236d9$d5c536f0$8f02000a@JA31> From: "Julian Satran \(Actcom\)" To: "Amir Shalit" Cc: References: Subject: Re: Piggybacking session window in data phase Date: Mon, 29 Jul 2002 11:27:42 +0300 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0057_01C236F2.F3DC6CD0" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2600.0000 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 Sender: owner-ips@ece.cmu.edu Precedence: bulk This is a multi-part message in MIME format. ------=_NextPart_000_0057_01C236F2.F3DC6CD0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable That is purely an implementation issue. I have seen some where it does not. Look carefully at what piggyback information you must use and when. Julo ----- Original Message -----=20 From: Amir Shalit=20 To: Julian Satran=20 Cc: ips@ece.cmu.edu=20 Sent: Saturday, July 27, 2002 8:15 PM Subject: Piggybacking session window in data phase Piggybacking session window information in data phase is hurting fast = path performance. Can it be avoided? Target can always use NOP-IN to update session = window if it feels an urge to do so. Amir ------=_NextPart_000_0057_01C236F2.F3DC6CD0 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
That is purely an implementation=20 issue.
I have seen some where it does = not.
Look carefully at what piggyback = information you=20 must use and when.
 
Julo
----- Original Message -----
From:=20 Amir=20 Shalit
Sent: Saturday, July 27, 2002 = 8:15=20 PM
Subject: Piggybacking session = window in=20 data phase

 
Piggybacking session window information in = data phase=20 is hurting fast path performance.
Can=20 it be avoided? Target can always use NOP-IN to update session window = if it=20 feels
an=20 urge to do so.
 
Amir
 
 
 ------=_NextPart_000_0057_01C236F2.F3DC6CD0-- From owner-ips@ece.cmu.edu Mon Jul 29 09:49:27 2002 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA29905 for ; Mon, 29 Jul 2002 09:49:27 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id g6TD9xm14207 for ips-outgoing; Mon, 29 Jul 2002 09:09:59 -0400 (EDT) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from btmail.net.cn (host1.btamail.net.cn [202.106.196.71]) by ece.cmu.edu (8.11.0/8.10.2) with SMTP id g6TBNYo09575 for ; Mon, 29 Jul 2002 07:23:35 -0400 (EDT) Received: from btmail.net.cn([202.106.196.73]) by btamail.net.cn(JetMail 2.5.3.0) with SMTP id jm83d452a3d; Mon, 29 Jul 2002 11:23:27 -0000 Received: from loki.ietf.org([132.151.1.177]) by btamail.net.cn(JetMail 2.5.3.0) with SMTP id jme63d408546; Thu, 25 Jul 2002 17:22:50 -0000 Received: (from adm@localhost) by loki.ietf.org (8.9.1b+Sun/8.9.1) id JAA11974 for ietf-123-outbound.01@ietf.org; Thu, 25 Jul 2002 09:15:00 -0400 (EDT) Received: from ietf.org (odin.ietf.org [10.27.2.28]) by loki.ietf.org (8.9.1b+Sun/8.9.1) with ESMTP id IAA11194 for ; Thu, 25 Jul 2002 08:07:47 -0400 (EDT) Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA29779; Thu, 25 Jul 2002 08:06:23 -0400 (EDT) Message-Id: <200207251206.IAA29779@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; Cc: ips@ece.cmu.edu From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-ietf-ips-security-14.txt Date: Thu, 25 Jul 2002 08:06:23 -0400 Sender: owner-ips@ece.cmu.edu Precedence: bulk --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the IP Storage Working Group of the IETF. Title : Securing Block Storage Protocols over IP Author(s) : B. Aboba et al. Filename : draft-ietf-ips-security-14.txt Pages : 68 Date : 24-Jul-02 This document discusses how to secure block storage and storage discovery protocols running over IP. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-ips-security-14.txt To remove yourself from the IETF Announcement list, send a message to ietf-announce-request with the word unsubscribe in the body of the message. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-ips-security-14.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-ips-security-14.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <20020724142808.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-ips-security-14.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-ips-security-14.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <20020724142808.I-D@ietf.org> --OtherAccess-- --NextPart-- From owner-ips@ece.cmu.edu Mon Jul 29 12:16:02 2002 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA06056 for ; Mon, 29 Jul 2002 12:16:01 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id g6TFWn622362 for ips-outgoing; Mon, 29 Jul 2002 11:32:49 -0400 (EDT) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from lion.ninthwonder.com (lion.ninthwonder.com [151.199.66.147]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id g6TFWko22350 for ; Mon, 29 Jul 2002 11:32:46 -0400 (EDT) Received: by lion.ninthwonder.com (Postfix, from userid 1021) id C931F30706; Mon, 29 Jul 2002 11:32:45 -0400 (EDT) Date: Mon, 29 Jul 2002 08:29:14 -0700 (PDT) From: Bill Studenmund X-X-Sender: To: "Rao, Sajjan" Cc: "BURBRIDGE,MATTHEW (HP-UnitedKingdom,ex2)" , Subject: RE: Regarding CSG and NSG In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ips@ece.cmu.edu Precedence: bulk On Sat, 27 Jul 2002, Rao, Sajjan wrote: > Bill, > If the Initiator says no authentication, then the target has to decide > whether it wants to authenticate or not. So if the target wants to forego > security, it has to send the CSG = CSG sent by initiator and NSG = NSG sent > by the initiator and set T = 1. > Am I right?? Assuming that the initiator set T=1, yes, that is my understanding. Well, that's not what I would call, "Initiator says no authentication". This situation is more the initiator saying I'm happy not authenticating. "No authentication" would be CSG=1 on the initial request; we skipped right past the security phase. :-) > The initiator would then move send one more login request with probably some > more parameters and move into Full feature phase. Yep. Take care, Bill From owner-ips@ece.cmu.edu Mon Jul 29 17:22:42 2002 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA15334 for ; Mon, 29 Jul 2002 17:22:41 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id g6TKXFJ09715 for ips-outgoing; Mon, 29 Jul 2002 16:33:15 -0400 (EDT) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from atlrel8.hp.com (atlrel8.hp.com [156.153.255.206]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id g6TKXDo09709 for ; Mon, 29 Jul 2002 16:33:13 -0400 (EDT) Received: from core.rose.hp.com (core.rose.hp.com [15.43.208.100]) by atlrel8.hp.com (Postfix) with ESMTP id 42298A00D24; Mon, 29 Jul 2002 16:33:08 -0400 (EDT) Received: from swathi (swathi.rose.hp.com [15.43.213.237]) by core.rose.hp.com with SMTP (8.9.3 (PHNE_22672)/8.8.6 SMKit7.02) id NAA16236; Mon, 29 Jul 2002 13:35:00 -0700 (PDT) Message-ID: <005c01c2373f$253e6a70$edd52b0f@rose.hp.com> From: "Mallikarjun C." To: , "Julian Satran" References: Subject: Re: iSCSI - working draft and IANA Date: Mon, 29 Jul 2002 13:33:06 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2600.0000 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 Sender: owner-ips@ece.cmu.edu Precedence: bulk Content-Transfer-Encoding: 7bit Julian, I like the general idea, a couple of comments. - I assume that it's still the case that new RFCs can define new keys without any of the (X#, Y# and Z#) prefixes, if the proposed keys are expected to be broadly useful (i.e. beyond a "group of vendors"). If that's true, then should they be registered into the IANA registry as well? - It appears that the text only appears to require a registry for all new keys, but not for what's defined in the iSCSI draft today. It may be useful to include currently defined keys as well, so there's one repository for all keys. I hope it doesn't lead to any technical delays for the current draft.... Thanks. -- Mallikarjun Mallikarjun Chadalapaka Networked Storage Architecture Network Storage Solutions Hewlett-Packard MS 5668 Roseville CA 95747 cbm@rose.hp.com ----- Original Message ----- From: "Julian Satran" To: Sent: Sunday, July 28, 2002 6:05 AM Subject: iSCSI - working draft and IANA > Dear colleagues, > > The current (today's) version of the draft has a revised IANA consideration > section > and specific indication on how to build keys, authentication methods and > digests. > > David Black suggested that we might want to go for 3 different registries > maintained by IANA for iSCSI > and I liked the idea. > > Please comment, > Julo > > From owner-ips@ece.cmu.edu Mon Jul 29 17:22:55 2002 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA15357 for ; Mon, 29 Jul 2002 17:22:53 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id g6TKuO010968 for ips-outgoing; Mon, 29 Jul 2002 16:56:24 -0400 (EDT) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from msgbas1.cos.agilent.com (msgbas1x.cos.agilent.com [192.25.240.36]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id g6TKuLo10960 for ; Mon, 29 Jul 2002 16:56:21 -0400 (EDT) Received: from msgrel1t.cos.agilent.com (msgrel1t.cos.agilent.com [130.29.152.157]) by msgbas1.cos.agilent.com (Postfix) with ESMTP id F0F3EAB9B; Mon, 29 Jul 2002 14:56:20 -0600 (MDT) Received: from axcsbh6.cos.agilent.com (axcsbh6.cos.agilent.com [130.29.152.171]) by msgrel1t.cos.agilent.com (Postfix) with SMTP id 9665253E; Mon, 29 Jul 2002 14:56:20 -0600 (MDT) Received: from 130.29.152.171 by axcsbh6.cos.agilent.com (InterScan E-Mail VirusWall NT); Mon, 29 Jul 2002 14:56:20 -0600 Received: by axcsbh6.cos.agilent.com with Internet Mail Service (5.5.2653.19) id ; Mon, 29 Jul 2002 14:56:20 -0600 Message-ID: <01A7DAF31F93D511AEE300D0B706ED9201BF4A41@axcs13.cos.agilent.com> From: vince_cavanna@agilent.com To: Black_David@emc.com, bernard_aboba@hotmail.com, ips@ece.cmu.edu Cc: vince_cavanna@agilent.com, pat_thaler@agilent.com Subject: RE: iSCSI: SRP groups in Security-14 strawman Date: Mon, 29 Jul 2002 14:56:19 -0600 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-ips@ece.cmu.edu Precedence: bulk My main concern was that we don't allow more options than necessary; so picking either the SRP or the IKE moduli with their corresponding generators (one per modulus) seems OK to me. I do, however, share Paul Koning's desire to understand if there is an algorithmic advantage in using one modulus over another and hope, as does Paul, that somebody with the required background can be enlisted to shed some light on this. In hardware implementations of modular exponentiation I can conceive of potentially big impacts in the choice of base (generator) and modulus. Since the modular exponentiations for SRP and IKE are typically done in software and involve such large numbers I don't know if existing algorithms have taken advantage of optimizations that may be possible with certain choices of generator and modulus. Vince |-----Original Message----- |From: Black_David@emc.com [mailto:Black_David@emc.com] |Sent: Wednesday, July 24, 2002 4:12 PM |To: bernard_aboba@hotmail.com; ips@ece.cmu.edu |Subject: iSCSI: SRP groups in Security-14 strawman | | |The SRP group specifications appear to need some tightening. In |reading this message, please keep in mind that SRP support is OPTIONAL, |so the following concerns apply only to implementations that choose |to support SRP. To be specific, there is no requirement to offer or |accept SRP as a value of AuthMethod. Those with no plans to support |SRP can ignore the rest of this message. | |Let me start with the following issue that Vince Cavanna raised: | |> Sounds good, but I don't understand the motivation to use any primes |> other than those from IKE when we know those primes are certifiable |> and that a generator suitable for SRP can be easily and |deterministically |> determined. Is there value in giving the user multiple |choices for primes |> of a given size? | |I think the answer to Vince's second question is "no", but I also |think that since the SRP primes have been proven prime and have been |widely distributed with SRP software from Stanford, we should |choose them over the IKE primes. The 2048 bit size of the largest |SRP prime also appears to be convenient - see below. This suggests |deleting the Oakley group 2, the 1536-bit [MODP] group, and the |2048-bit [MODP] group since there are SRP groups with primes of |the same sizes. | |For the remaining MODP groups, I suggest that we pick a single |acceptable generator for simplicity (i.e., that generator MUST |be used with the corresponding prime, other generators MUST NOT |be used): | | 5 for the 3072-bit, 4096-bit, and 6144-bit [MODP] groups. | 19 for the 8192-bit [MODP] group. | |The rationale for this is the same as above - there is no value in |giving the user multiple choices for generators. Tom Wu should be |cited as the source of the acceptability determination for these |generators. | |Finally, we need some implementation requirements. There are a |couple of issues here: | |(1) For SRP, the target announces the prime and generator. If the |initiator doesn't like them, it closes the connection - that's an |invitation to interoperability headaches. The cleanest solution |to this is to negotiate the group: | - Instead of the target sending SRP_N and SRP_g, the target | sends SRP_GROUP= where possible values | are SRP-768, SRP-1024, etc. and MODP-3072, |MODP-4096, etc. | - The initiator returns SRP_GROUP= along with | SRP_A. |Not only is that cleaner, it also takes out a bignum without adding a |round trip. The SRP_GROUP values probably need to go into an IANA |registry, with a rule that the WG (or the ADs if the WG no longer |exists) control additions. The alternative of folding the group |selection into the AuthMethod value (e.g., AuthMethod=SRP_MODP-4096) |seems clumsy by comparison and doesn't save a round trip. | |(2) We need some requirements on what MUST be supported for |interoperability when SRP is supported. I hesitate to require |support for all the groups up to the 8192-bit MODP group. A glance |at draft-orman-public-key-lengths-05.txt suggests that the SRP |primes are adequate for now as the 1536-bit and 2048-bit primes |bracket the 96 bits of randomness that we require of CHAP secrets. | |In practice, I think we need to allow local security policy to |disallow use of smaller primes, so the requirements would be |something like: | |- MUST support all the SRP groups (up to 2048 bits) |- MAY support the MODP groups |- Target MUST offer SRP-2048 as one of the possible values of | SRP_GROUP and SHOULD offer all supported groups that are | allowed by local security policy. | |Comments? Please keep in mind that all of the above would apply |only to implementations that support SRP, and support for SRP is |OPTIONAL. | |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 |--------------------------------------------------- | From owner-ips@ece.cmu.edu Mon Jul 29 17:33:57 2002 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA15916 for ; Mon, 29 Jul 2002 17:33:56 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id g6TLCvf11897 for ips-outgoing; Mon, 29 Jul 2002 17:12:57 -0400 (EDT) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from atlrel7.hp.com (atlrel7.hp.com [156.153.255.213]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id g6TLCto11888 for ; Mon, 29 Jul 2002 17:12:55 -0400 (EDT) Received: from xatlrelay2.atl.hp.com (xatlrelay2.atl.hp.com [15.45.89.191]) by atlrel7.hp.com (Postfix) with ESMTP id B798580512E for ; Mon, 29 Jul 2002 17:12:54 -0400 (EDT) Received: from xatlbh3.atl.hp.com (xatlbh3.atl.hp.com [15.45.89.188]) by xatlrelay2.atl.hp.com (Postfix) with ESMTP id B2EF5400090 for ; Mon, 29 Jul 2002 17:12:54 -0400 (EDT) Received: by xatlbh3.atl.hp.com with Internet Mail Service (5.5.2655.55) id ; Mon, 29 Jul 2002 17:12:54 -0400 Message-ID: <6BD67FFB937FD411A04F00D0B74FE87805CCF70C@xrose06.rose.hp.com> From: "KRUEGER,MARJORIE (HP-Roseville,ex1)" To: "Ips Reflector (E-mail)" Subject: iSCSI: reference for CRC32C? Date: Mon, 29 Jul 2002 17:12:52 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2655.55) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-ips@ece.cmu.edu Precedence: bulk Looking thru the current draft I can't find any doc. reference for the definition of CRC32C. Does the text in sec 11.1 suffice, or is there some other document that fully defines the algorithm for CRC32C? If so, shouldn't it be referenced in the bibliography? Thanks Marjorie From owner-ips@ece.cmu.edu Mon Jul 29 19:20:44 2002 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA17697 for ; Mon, 29 Jul 2002 19:20:43 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id g6TMiHn16600 for ips-outgoing; Mon, 29 Jul 2002 18:44:17 -0400 (EDT) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from msgbas1.cos.agilent.com (msgbas1x.cos.agilent.com [192.25.240.36]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id g6TMiFo16596 for ; Mon, 29 Jul 2002 18:44:16 -0400 (EDT) Received: from msgrel1t.cos.agilent.com (msgrel1t.cos.agilent.com [130.29.152.157]) by msgbas1.cos.agilent.com (Postfix) with ESMTP id 1029CBC8B for ; Mon, 29 Jul 2002 16:44:15 -0600 (MDT) Received: from axcsbh4.cos.agilent.com (axcsbh4.cos.agilent.com [130.29.152.145]) by msgrel1t.cos.agilent.com (Postfix) with SMTP id CFC0D1F for ; Mon, 29 Jul 2002 16:44:14 -0600 (MDT) Received: from 130.29.152.145 by axcsbh4.cos.agilent.com (InterScan E-Mail VirusWall NT); Mon, 29 Jul 2002 16:44:13 -0600 Received: by axcsbh4.cos.agilent.com with Internet Mail Service (5.5.2653.19) id ; Mon, 29 Jul 2002 16:44:13 -0600 Message-ID: <1BEBA5E8600DD4119A50009027AF54A00D373802@axcs04.cos.agilent.com> From: pat_thaler@agilent.com To: marjorie_krueger@hp.com, ips@ece.cmu.edu Subject: RE: iSCSI: reference for CRC32C? Date: Mon, 29 Jul 2002 16:44:07 -0600 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-ips@ece.cmu.edu Precedence: bulk Margorie, The text in 11.1 suffices to fully define the algorithm. Regards, Pat -----Original Message----- From: KRUEGER,MARJORIE (HP-Roseville,ex1) [mailto:marjorie_krueger@hp.com] Sent: Monday, July 29, 2002 2:13 PM To: Ips Reflector (E-mail) Subject: iSCSI: reference for CRC32C? Looking thru the current draft I can't find any doc. reference for the definition of CRC32C. Does the text in sec 11.1 suffice, or is there some other document that fully defines the algorithm for CRC32C? If so, shouldn't it be referenced in the bibliography? Thanks Marjorie From owner-ips@ece.cmu.edu Mon Jul 29 19:20:45 2002 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA17710 for ; Mon, 29 Jul 2002 19:20:45 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id g6TMmGS16788 for ips-outgoing; Mon, 29 Jul 2002 18:48:16 -0400 (EDT) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from dogwood.cisco.com (dogwood.cisco.com [161.44.11.19]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id g6TMmFo16783 for ; Mon, 29 Jul 2002 18:48:15 -0400 (EDT) Received: from cisco.com (dhcp-161-44-68-217.cisco.com [161.44.68.217]) by dogwood.cisco.com (8.8.6 (PHNE_14041)/CISCO.SERVER.1.2) with ESMTP id SAA19983; Mon, 29 Jul 2002 18:48:07 -0400 (EDT) Message-ID: <3D45C626.5F29053A@cisco.com> Date: Mon, 29 Jul 2002 17:48:06 -0500 From: Steve Senum X-Mailer: Mozilla 4.76 [en]C-CCK-MCD (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: Julian Satran CC: ips@ece.cmu.edu Subject: Re: iSCSI - working draft and IANA References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ips@ece.cmu.edu Precedence: bulk Content-Transfer-Encoding: 7bit Julian, 1. I would suggest registering all the current iSCSI keys, auth methods, and digests with the IANA, with references to the iSCSI RFC (when published), and dropping the X#, Y#, and Z# prefixes. This would be more consistent with how I have seen this done in the past. 2. I am not sure I really see the need. In other cases, this is done to allow vendor specific registrations, but we already have a mechanism for that (the X- prefix). Note that there is no reason why a vendor can't defined a vendor specific key in an informational RFC. Regards, Steve Senum Julian Satran wrote: > > Dear colleagues, > > The current (today's) version of the draft has a revised IANA consideration > section > and specific indication on how to build keys, authentication methods and > digests. > > David Black suggested that we might want to go for 3 different registries > maintained by IANA for iSCSI > and I liked the idea. > > Please comment, > Julo From owner-ips@ece.cmu.edu Mon Jul 29 20:37:07 2002 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA19123 for ; Mon, 29 Jul 2002 20:37:07 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id g6TNxEN19629 for ips-outgoing; Mon, 29 Jul 2002 19:59:14 -0400 (EDT) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from Pescadero.DSG.Stanford.EDU (Pescadero.DSG.Stanford.EDU [171.64.79.21]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id g6TNxDo19625 for ; Mon, 29 Jul 2002 19:59:13 -0400 (EDT) Received: from Pescadero.DSG.Stanford.EDU (IDENT:jonathan@localhost [127.0.0.1]) by Pescadero.DSG.Stanford.EDU (8.9.3/8.9.1) with ESMTP id QAA09227; Mon, 29 Jul 2002 16:51:20 -0700 Message-Id: <200207292351.QAA09227@Pescadero.DSG.Stanford.EDU> To: pat_thaler@agilent.com cc: marjorie_krueger@hp.com, ips@ece.cmu.edu Subject: Re: iSCSI: reference for CRC32C? In-reply-to: Your message of "Mon, 29 Jul 2002 16:44:07 MDT." <1BEBA5E8600DD4119A50009027AF54A00D373802@axcs04.cos.agilent.com> Date: Mon, 29 Jul 2002 16:51:19 -0700 From: Jonathan Stone Sender: owner-ips@ece.cmu.edu Precedence: bulk In message <1BEBA5E8600DD4119A50009027AF54A00D373802@axcs04.cos.agilent.com>pat_thaler@agilent.com writes >Margorie, > >The text in 11.1 suffices to fully define the algorithm. Agreed, It does specify the algorithm. But IMHO the spec should still cite the original source --- Castagnoli et al. --- because that is the original source. And because that's where to start looking, for anyone who cares about the ins and outs of the specific choice of algorithm. The citation i have handy is: @Article{castagnoli-crc, author = { Guy Castagnoli and Stefan Braeuer and Martin Herrman}, title = {{Optimization of Cyclic Redundancy-Check Codes with 24 and 32 Parity Bits}}, journal = IEEE Transactions on Communication, year = {1993}, volume = {41}, number = {6}, pages = {}, month = {June}, } (I have a hardcopy, with page numbers, if I can find it.) From owner-ips@ece.cmu.edu Mon Jul 29 20:39:47 2002 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA19237 for ; Mon, 29 Jul 2002 20:39:46 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id g6U0JWU20339 for ips-outgoing; Mon, 29 Jul 2002 20:19:32 -0400 (EDT) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from d12lmsgate-2.de.ibm.com (d12lmsgate-2.de.ibm.com [195.212.91.200]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id g6U0JVo20334 for ; Mon, 29 Jul 2002 20:19:31 -0400 (EDT) Received: from d12relay01.de.ibm.com (d12relay01.de.ibm.com [9.165.215.22]) by d12lmsgate-2.de.ibm.com (8.12.3/8.12.3) with ESMTP id g6U0JOhs022568; Tue, 30 Jul 2002 02:19:24 +0200 Received: from d10hubm1.telaviv.ibm.com (d10ml001.telaviv.ibm.com [9.148.216.55]) by d12relay01.de.ibm.com (8.12.3/NCO/VER6.3) with ESMTP id g6U0JOsK133042; Tue, 30 Jul 2002 02:19:24 +0200 To: "Robert D. Russell" Cc: ips@ece.cmu.edu MIME-Version: 1.0 Subject: Re: iSCSI: plugfest4 issues X-Mailer: Lotus Notes Release 5.0.9 November 16, 2001 From: "Julian Satran" Message-ID: Date: Tue, 30 Jul 2002 03:19:21 +0300 X-MIMETrack: Serialize by Router on D10ML001/10/M/IBM(Release 5.0.9a |January 7, 2002) at 30/07/2002 03:19:23, Serialize complete at 30/07/2002 03:19:23 Content-Type: multipart/alternative; boundary="=_alternative 0001843AC2256C06_=" Sender: owner-ips@ece.cmu.edu Precedence: bulk This is a multipart message in MIME format. --=_alternative 0001843AC2256C06_= Content-Type: text/plain; charset="us-ascii" Comments in text - thanks - Julo "Robert D. Russell" 07/30/2002 02:49 AM To: Julian Satran/Haifa/IBM@IBMIL cc: ips@ece.cmu.edu Subject: iSCSI: plugfest4 issues Julian: iSCSI plugfest 4 got underway today at UNH with 26 companies participating, all testing at draft 13 of the standard. Two issues came up today: 1. There appears to be a minor inconsistency in wording in draft 15: Section 11.4 TargetName labels the Use of TargetName as: "ALL by target". The very last sentence in this same section says: "The TargetName key may also be returned by the "SendTargets" text request (which is its only use when issued by a target)." These 2 statements are inconsistent, because ALL implies there are other times the target can send a TargetName key. Either the "ALL" is wrong or the "only" is wrong. I believe it is probably the word "only" that is wrong, and that it should probably be replaced with a word like "principal", since, in fact, the principal use of the TargetName key (but not its only use) is as a reply to the "SendTargets". +++ The only is lower-case and is meant to say that this is the only use the target has for the key ALL is meant to show that the target can use it in all stages I will see how I can rephrase it and set is FFPO +++ 2. Section 4.3 is clear that unless explicitly stated otherwise, keys can only be sent during a specific stage. What does not seem to be stated anywhere is what should a receiver do if it receives a key in the wrong stage. Is this a "protocol error", or can the receiver just silently throw the erroneous key way or, if the key is an operational key received during security stage, can the receiver simply postpone responding to it until after the transition into operational stage? Also, in this latter case, what happens if the key is also sent (again) during the (proper) operational stage? Is that an attempt at renegotiation? I believe the simplest solution would be for the standard to explicitly state in section 4.3 that sending a key outside the stage in which it is allowed is a "protocol error", and that during login the Initiator MUST close the connection and that the Target MUST send a Login Reject and then close the connection (i.e., wording along the lines of that in section 4.4 in the paragraph detailing what happens when there is an attempt to negotiate a parameter more than once). +++ will add a statement ++++ Thank you for your consideration. Bob Russell InterOperability Lab University of New Hampshire rdr@iol.unh.edu 603-862-3774 --=_alternative 0001843AC2256C06_= Content-Type: text/html; charset="us-ascii"
Comments in text - thanks - Julo


"Robert D. Russell" <rdr@io.iol.unh.edu>

07/30/2002 02:49 AM

       
        To:        Julian Satran/Haifa/IBM@IBMIL
        cc:        ips@ece.cmu.edu
        Subject:        iSCSI: plugfest4 issues

       



Julian:

iSCSI plugfest 4 got underway today at UNH with 26 companies participating,
all testing at draft 13 of the standard.

Two issues came up today:

1. There appears to be a minor inconsistency in wording in draft 15:

Section 11.4 TargetName labels the Use of TargetName as:
 "ALL by target".

The very last sentence in this same section says:
"The TargetName key may also be returned by the "SendTargets" text
request (which is its only use when issued by a target)."

These 2 statements are inconsistent, because ALL implies there are other
times the target can send a TargetName key.

Either the "ALL" is wrong or the "only" is wrong.

I believe it is probably the word "only" that is wrong, and that it
should probably be replaced with a word like "principal", since, in
fact, the principal use of the TargetName key (but not its only use)
is as a reply to the "SendTargets".

+++ The only is lower-case and is meant to say that this is the only use the target has for the key
ALL is meant to show that the target can use it in all stages I will see how I can rephrase it and set is FFPO +++

2. Section 4.3 is clear that unless explicitly stated otherwise, keys can
only be sent during a specific stage.  What does not seem to be stated
anywhere is what should a receiver do if it receives a key in the wrong
stage.  Is this a "protocol error", or can the receiver just silently
throw the erroneous key way or, if the key is an operational key received
during security stage, can the receiver simply postpone responding to it
until after the transition into operational stage?  Also, in this
latter case, what happens if the key is also sent (again) during the
(proper) operational stage?  Is that an attempt at renegotiation?

I believe the simplest solution would be for the standard to explicitly
state in section 4.3 that sending a key outside the stage in which it
is allowed is a "protocol error", and that during login the Initiator
MUST close the connection and that the Target MUST send a Login Reject
and then close the connection (i.e., wording along the lines of that
in section 4.4 in the paragraph detailing what happens when there is
an attempt to negotiate a parameter more than once).
+++ will add a statement ++++
Thank you for your consideration.

Bob Russell
InterOperability Lab
University of New Hampshire
rdr@iol.unh.edu
603-862-3774

--=_alternative 0001843AC2256C06_=-- From owner-ips@ece.cmu.edu Mon Jul 29 20:40:02 2002 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA19255 for ; Mon, 29 Jul 2002 20:39:57 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id g6U0Tsa20767 for ips-outgoing; Mon, 29 Jul 2002 20:29:54 -0400 (EDT) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from d12lmsgate.de.ibm.com (d12lmsgate.de.ibm.com [195.212.91.199]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id g6U0Tro20763 for ; Mon, 29 Jul 2002 20:29:53 -0400 (EDT) Received: from d12relay01.de.ibm.com (d12relay01.de.ibm.com [9.165.215.22]) by d12lmsgate.de.ibm.com (8.12.3/8.12.3) with ESMTP id g6U0Tkqi015544; Tue, 30 Jul 2002 02:29:46 +0200 Received: from d10hubm1.telaviv.ibm.com (d10ml001.telaviv.ibm.com [9.148.216.55]) by d12relay01.de.ibm.com (8.12.3/NCO/VER6.3) with ESMTP id g6U0TksK098604; Tue, 30 Jul 2002 02:29:46 +0200 To: "Walczak, Kyle" Cc: ips@ece.cmu.edu MIME-Version: 1.0 Subject: Re: iSCSI reserved statement X-Mailer: Lotus Notes Release 5.0.9 November 16, 2001 From: "Julian Satran" Message-ID: Date: Tue, 30 Jul 2002 03:29:43 +0300 X-MIMETrack: Serialize by Router on D10ML001/10/M/IBM(Release 5.0.9a |January 7, 2002) at 30/07/2002 03:29:46, Serialize complete at 30/07/2002 03:29:46 Content-Type: multipart/alternative; boundary="=_alternative 00021715C2256C06_=" Sender: owner-ips@ece.cmu.edu Precedence: bulk This is a multipart message in MIME format. --=_alternative 00021715C2256C06_= Content-Type: text/plain; charset="us-ascii" OK - It is anyhow stated also in several other places. Julo "Walczak, Kyle" 07/29/2002 06:50 PM To: Julian Satran/Haifa/IBM@IBMIL cc: Subject: iSCSI reserved statement Julian: I was looking at section 2nd para of section 9 which states; "Any compliant sender MUST set all bits not defined and all reserved fields to zero unless specified otherwise. Any compliant receiver MUST ignore any bit not defined and all reserved fields unless specified otherwise." The SCP-2 defines "reserved" as "A keyword referring to bits, bytes, words, fields and code values that are set aside for future standardization. A reserved bit, byte, word or filed shall be set to zero, or in accordance with a future extension to this standard. Recipents are not required to check reserved bits, bytes, words or fileds for zero values. Receipt of reserved code values in defined fields shall be reported as error." I would like to add the third line of the above statement to the first paragraph, such that it states: "Any compliant sender MUST set all bits not defined and all reserved fields to zero unless specified otherwise. Any compliant receiver MUST ignore any bit not defined and all reserved fields unless specified otherwise." Receipt of reserved code values in defined fields shall be reported as error." For example, if the Additional Header Segment (AHS), the AHSType, AHS code was set to 0, 3-59 would report an error ( 0x09 Reason code in the Reject PDU, Invalid PDU field). Thanks Kyle Walczak (281) 514-3258 --=_alternative 00021715C2256C06_= Content-Type: text/html; charset="us-ascii"
OK - It is anyhow stated also in several other places. Julo


"Walczak, Kyle" <Kyle.Walczak@hp.com>

07/29/2002 06:50 PM

       
        To:        Julian Satran/Haifa/IBM@IBMIL
        cc:        
        Subject:        iSCSI reserved statement

       


Julian:


I was looking at section 2nd para of section 9 which states;

"Any compliant sender MUST set all bits not defined and all reserved
fields to zero unless specified otherwise. Any compliant receiver
MUST ignore any bit not defined and all reserved fields unless specified
otherwise."

The SCP-2 defines "reserved" as
"A keyword referring to bits, bytes, words, fields and code values that are set aside for future standardization. A reserved bit, byte, word or filed shall be set to zero, or in accordance with a future extension to this standard. Recipents are not required to check reserved bits, bytes, words or fileds for zero values. Receipt of reserved code values in defined fields shall be reported as error."

I would like to add the third line of the above statement to the first paragraph, such that it states:
"Any compliant sender MUST set all bits not defined and all reserved
fields to zero unless specified otherwise. Any compliant receiver
MUST ignore any bit not defined and all reserved fields unless specified
otherwise." Receipt of reserved code values in defined fields shall be reported as error."


For example, if the Additional Header Segment (AHS), the AHSType, AHS code
was set to 0, 3-59 would report an error ( 0x09 Reason code in the Reject PDU, Invalid PDU field).


Thanks
Kyle Walczak
(281) 514-3258

--=_alternative 00021715C2256C06_=-- From owner-ips@ece.cmu.edu Mon Jul 29 21:06:34 2002 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA20359 for ; Mon, 29 Jul 2002 21:06:29 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id g6U0g0I21240 for ips-outgoing; Mon, 29 Jul 2002 20:42:00 -0400 (EDT) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from d12lmsgate.de.ibm.com (d12lmsgate.de.ibm.com [195.212.91.199]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id g6U0fxo21235 for ; Mon, 29 Jul 2002 20:41:59 -0400 (EDT) Received: from d12relay02.de.ibm.com (d12relay02.de.ibm.com [9.165.215.23]) by d12lmsgate.de.ibm.com (8.12.3/8.12.3) with ESMTP id g6U0eKqi017284; Tue, 30 Jul 2002 02:40:20 +0200 Received: from d10hubm1.telaviv.ibm.com (d10ml001.telaviv.ibm.com [9.148.216.55]) by d12relay02.de.ibm.com (8.12.3/NCO/VER6.3) with ESMTP id g6U0eKBI090206; Tue, 30 Jul 2002 02:40:21 +0200 To: Jonathan Stone Cc: ips@ece.cmu.edu, marjorie_krueger@hp.com, owner-ips@ece.cmu.edu, pat_thaler@agilent.com MIME-Version: 1.0 Subject: Re: iSCSI: reference for CRC32C? X-Mailer: Lotus Notes Release 5.0.9 November 16, 2001 From: "Julian Satran" Message-ID: Date: Tue, 30 Jul 2002 03:40:17 +0300 X-MIMETrack: Serialize by Router on D10ML001/10/M/IBM(Release 5.0.9a |January 7, 2002) at 30/07/2002 03:40:20, Serialize complete at 30/07/2002 03:40:20 Content-Type: multipart/alternative; boundary="=_alternative 0002DA11C2256C06_=" Sender: owner-ips@ece.cmu.edu Precedence: bulk This is a multipart message in MIME format. --=_alternative 0002DA11C2256C06_= Content-Type: text/plain; charset="us-ascii" Nice - Marjorie & all - Did you by any chance look at the reference section? I will add also a pointer to it although - as Pat pointed out - this does not really belong in this section. Julo Jonathan Stone Sent by: owner-ips@ece.cmu.edu 07/30/2002 02:51 AM To: pat_thaler@agilent.com cc: marjorie_krueger@hp.com, ips@ece.cmu.edu Subject: Re: iSCSI: reference for CRC32C? In message <1BEBA5E8600DD4119A50009027AF54A00D373802@axcs04.cos.agilent.com>pat_thaler@agilent.com writes >Margorie, > >The text in 11.1 suffices to fully define the algorithm. Agreed, It does specify the algorithm. But IMHO the spec should still cite the original source --- Castagnoli et al. --- because that is the original source. And because that's where to start looking, for anyone who cares about the ins and outs of the specific choice of algorithm. The citation i have handy is: @Article{castagnoli-crc, author = { Guy Castagnoli and Stefan Braeuer and Martin Herrman}, title = {{Optimization of Cyclic Redundancy-Check Codes with 24 and 32 Parity Bits}}, journal = IEEE Transactions on Communication, year = {1993}, volume = {41}, number = {6}, pages = {}, month = {June}, } (I have a hardcopy, with page numbers, if I can find it.) --=_alternative 0002DA11C2256C06_= Content-Type: text/html; charset="us-ascii"
Nice - Marjorie & all - Did you by any chance look at the reference section?
I will add also a pointer to it although - as Pat pointed out -  this does not really belong
in this section.

Julo


Jonathan Stone <jonathan@dsg.stanford.edu>
Sent by: owner-ips@ece.cmu.edu

07/30/2002 02:51 AM

       
        To:        pat_thaler@agilent.com
        cc:        marjorie_krueger@hp.com, ips@ece.cmu.edu
        Subject:        Re: iSCSI: reference for CRC32C?

       


In message <1BEBA5E8600DD4119A50009027AF54A00D373802@axcs04.cos.agilent.com>pat_thaler@agilent.com writes
>Margorie,
>
>The text in 11.1 suffices to fully define the algorithm.

Agreed, It does specify the algorithm. But IMHO the spec should still
cite the original source --- Castagnoli et al. --- because that is the
original source.  And because that's where to start looking, for anyone
who cares about the ins and outs of the specific choice of algorithm.

The citation i have  handy is:
@Article{castagnoli-crc,
 author =       { Guy Castagnoli and Stefan Braeuer and Martin Herrman},
 title =        {{Optimization of Cyclic Redundancy-Check Codes with 24
                 and 32 Parity Bits}},
 journal =      IEEE Transactions on Communication,
 year =         {1993},
 volume =       {41},
 number =       {6},
 pages =        {},
 month =        {June},
}

(I have a hardcopy, with page numbers, if I can find it.)

--=_alternative 0002DA11C2256C06_=-- From owner-ips@ece.cmu.edu Mon Jul 29 21:08:21 2002 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA20374 for ; Mon, 29 Jul 2002 21:08:16 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id g6U0eVf21147 for ips-outgoing; Mon, 29 Jul 2002 20:40:31 -0400 (EDT) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from d12lmsgate-3.de.ibm.com (d12lmsgate-3.de.ibm.com [195.212.91.201]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id g6U0eTo21143 for ; Mon, 29 Jul 2002 20:40:29 -0400 (EDT) Received: from d12relay02.de.ibm.com (d12relay02.de.ibm.com [9.165.215.23]) by d12lmsgate-3.de.ibm.com (8.12.3/8.12.3) with ESMTP id g6U0eMTO011436; Tue, 30 Jul 2002 02:40:22 +0200 Received: from d10hubm1.telaviv.ibm.com (d10ml001.telaviv.ibm.com [9.148.216.55]) by d12relay02.de.ibm.com (8.12.3/NCO/VER6.3) with ESMTP id g6U0eMBI090208; Tue, 30 Jul 2002 02:40:22 +0200 To: "Mallikarjun C." Cc: ips@ece.cmu.edu MIME-Version: 1.0 Subject: Re: iSCSI - working draft and IANA X-Mailer: Lotus Notes Release 5.0.9 November 16, 2001 From: "Julian Satran" Message-ID: Date: Tue, 30 Jul 2002 03:40:19 +0300 X-MIMETrack: Serialize by Router on D10ML001/10/M/IBM(Release 5.0.9a |January 7, 2002) at 30/07/2002 03:40:21, Serialize complete at 30/07/2002 03:40:21 Content-Type: multipart/alternative; boundary="=_alternative 00033906C2256C06_=" Sender: owner-ips@ece.cmu.edu Precedence: bulk This is a multipart message in MIME format. --=_alternative 00033906C2256C06_= Content-Type: text/plain; charset="us-ascii" Mallikarjun, You don't have to register keys that start with X-, Y- and Z- (I think the text is clear). As for the current key I am not sure I understand the point. We are registering only the aprt following the # Julo "Mallikarjun C." 07/29/2002 11:33 PM To: , Julian Satran/Haifa/IBM@IBMIL cc: Subject: Re: iSCSI - working draft and IANA Julian, I like the general idea, a couple of comments. - I assume that it's still the case that new RFCs can define new keys without any of the (X#, Y# and Z#) prefixes, if the proposed keys are expected to be broadly useful (i.e. beyond a "group of vendors"). If that's true, then should they be registered into the IANA registry as well? - It appears that the text only appears to require a registry for all new keys, but not for what's defined in the iSCSI draft today. It may be useful to include currently defined keys as well, so there's one repository for all keys. I hope it doesn't lead to any technical delays for the current draft.... Thanks. -- Mallikarjun Mallikarjun Chadalapaka Networked Storage Architecture Network Storage Solutions Hewlett-Packard MS 5668 Roseville CA 95747 cbm@rose.hp.com ----- Original Message ----- From: "Julian Satran" To: Sent: Sunday, July 28, 2002 6:05 AM Subject: iSCSI - working draft and IANA > Dear colleagues, > > The current (today's) version of the draft has a revised IANA consideration > section > and specific indication on how to build keys, authentication methods and > digests. > > David Black suggested that we might want to go for 3 different registries > maintained by IANA for iSCSI > and I liked the idea. > > Please comment, > Julo > > --=_alternative 00033906C2256C06_= Content-Type: text/html; charset="us-ascii"
Mallikarjun,

You don't have to register keys that start with X-, Y- and Z- (I think the text is clear).
As for the current key I am not sure I understand the point. We are registering only the aprt following the #

Julo


"Mallikarjun C." <cbm@rose.hp.com>

07/29/2002 11:33 PM

       
        To:        <ips@ece.cmu.edu>, Julian Satran/Haifa/IBM@IBMIL
        cc:        
        Subject:        Re: iSCSI - working draft and IANA

       


Julian,

I like the general idea, a couple of comments.

- I assume that it's still the case that new RFCs can define new keys
 without any of the (X#, Y# and Z#) prefixes, if the proposed keys
  are expected to be broadly useful (i.e. beyond a "group of vendors").
  If that's true, then should they be registered into the IANA registry
  as well?

- It appears that the text only appears to require a registry for all
 new keys, but not for what's defined in the iSCSI draft today.  It
 may be useful to include currently defined keys as well, so there's
 one repository for all keys.  I hope it doesn't lead to any technical
 delays for the current draft....

Thanks.
--
Mallikarjun

Mallikarjun Chadalapaka
Networked Storage Architecture
Network Storage Solutions
Hewlett-Packard MS 5668
Roseville CA 95747
cbm@rose.hp.com


----- Original Message -----
From: "Julian Satran" <Julian_Satran@il.ibm.com>
To: <ips@ece.cmu.edu>
Sent: Sunday, July 28, 2002 6:05 AM
Subject: iSCSI - working draft and IANA


> Dear colleagues,
>
> The current (today's) version of the draft has a revised IANA consideration
> section
> and specific  indication on how to build keys, authentication methods and
> digests.
>
> David Black suggested that we might want to go for 3 different registries
> maintained by IANA for iSCSI
> and I liked the idea.
>
> Please comment,
> Julo
>
>



--=_alternative 00033906C2256C06_=-- From owner-ips@ece.cmu.edu Mon Jul 29 21:14:12 2002 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA20571 for ; Mon, 29 Jul 2002 21:14:12 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id g6U0gZx21271 for ips-outgoing; Mon, 29 Jul 2002 20:42:35 -0400 (EDT) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from msgbas1.cos.agilent.com (msgbas1x.cos.agilent.com [192.25.240.36]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id g6U0gXo21267 for ; Mon, 29 Jul 2002 20:42:33 -0400 (EDT) Received: from msgrel1.cos.agilent.com (msgrel1.cos.agilent.com [130.29.152.77]) by msgbas1.cos.agilent.com (Postfix) with ESMTP id D68F2AD65; Mon, 29 Jul 2002 18:42:32 -0600 (MDT) Received: from axcsbh2.cos.agilent.com (axcsbh2.cos.agilent.com [130.29.152.144]) by msgrel1.cos.agilent.com (Postfix) with SMTP id 74AA9D5; Mon, 29 Jul 2002 18:42:32 -0600 (MDT) Received: from 130.29.152.144 by axcsbh2.cos.agilent.com (InterScan E-Mail VirusWall NT); Mon, 29 Jul 2002 18:42:31 -0600 Received: by axcsbh2.cos.agilent.com with Internet Mail Service (5.5.2653.19) id <355P30KA>; Mon, 29 Jul 2002 18:42:31 -0600 Message-ID: <1BEBA5E8600DD4119A50009027AF54A00D373847@axcs04.cos.agilent.com> From: pat_thaler@agilent.com To: jonathan@dsg.stanford.edu, pat_thaler@agilent.com Cc: marjorie_krueger@hp.com, ips@ece.cmu.edu Subject: RE: iSCSI: reference for CRC32C? Date: Mon, 29 Jul 2002 18:42:25 -0600 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-ips@ece.cmu.edu Precedence: bulk Jonathan, That informative reference is already in the draft. It has been in the draft since at least draft 10. Probably an informative reference to draft-sheinwald-iscsi-crc-02.txt which has been submitted to the RFC process would also be enlightening about why we chose to use a CRC and this particular CRC. I thought Margorie's question was whether a normative reference was needed to fully define the algorithm. Regards, Pat -----Original Message----- From: Jonathan Stone [mailto:jonathan@DSG.Stanford.EDU] Sent: Monday, July 29, 2002 4:51 PM To: pat_thaler@agilent.com Cc: marjorie_krueger@hp.com; ips@ece.cmu.edu Subject: Re: iSCSI: reference for CRC32C? In message <1BEBA5E8600DD4119A50009027AF54A00D373802@axcs04.cos.agilent.com>pat_thaler@agilent.com writes >Margorie, > >The text in 11.1 suffices to fully define the algorithm. Agreed, It does specify the algorithm. But IMHO the spec should still cite the original source --- Castagnoli et al. --- because that is the original source. And because that's where to start looking, for anyone who cares about the ins and outs of the specific choice of algorithm. The citation i have handy is: @Article{castagnoli-crc, author = { Guy Castagnoli and Stefan Braeuer and Martin Herrman}, title = {{Optimization of Cyclic Redundancy-Check Codes with 24 and 32 Parity Bits}}, journal = IEEE Transactions on Communication, year = {1993}, volume = {41}, number = {6}, pages = {}, month = {June}, } (I have a hardcopy, with page numbers, if I can find it.) From owner-ips@ece.cmu.edu Mon Jul 29 21:16:57 2002 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA20692 for ; Mon, 29 Jul 2002 21:16:56 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id g6U10cl21940 for ips-outgoing; Mon, 29 Jul 2002 21:00:38 -0400 (EDT) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from Pescadero.DSG.Stanford.EDU (Pescadero.DSG.Stanford.EDU [171.64.79.21]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id g6U10Zo21935 for ; Mon, 29 Jul 2002 21:00:35 -0400 (EDT) Received: from Pescadero.DSG.Stanford.EDU (IDENT:jonathan@localhost [127.0.0.1]) by Pescadero.DSG.Stanford.EDU (8.9.3/8.9.1) with ESMTP id RAA09707; Mon, 29 Jul 2002 17:52:35 -0700 Message-Id: <200207300052.RAA09707@Pescadero.DSG.Stanford.EDU> To: pat_thaler@agilent.com cc: jonathan@dsg.stanford.edu, marjorie_krueger@hp.com, ips@ece.cmu.edu Subject: Re: iSCSI: reference for CRC32C? In-reply-to: Your message of "Mon, 29 Jul 2002 18:42:25 MDT." <1BEBA5E8600DD4119A50009027AF54A00D373847@axcs04.cos.agilent.com> Date: Mon, 29 Jul 2002 17:52:35 -0700 From: Jonathan Stone Sender: owner-ips@ece.cmu.edu Precedence: bulk In message <1BEBA5E8600DD4119A50009027AF54A00D373847@axcs04.cos.agilent.com>, pat_thaler@agilent.com writes: [....] >I thought Margorie's question was whether a normative reference was needed to >fully define the algorithm. Oh. That wasn't clear, but you could well be right. If Julo adds a cross-reference to the sections which already have the citations, that should cover all bases :) From owner-ips@ece.cmu.edu Mon Jul 29 22:19:06 2002 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA22833 for ; Mon, 29 Jul 2002 22:19:06 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id g6U1j0B23567 for ips-outgoing; Mon, 29 Jul 2002 21:45:00 -0400 (EDT) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from mercury.corp.iready.com ([65.115.68.100]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id g6U1ivo23563 for ; Mon, 29 Jul 2002 21:44:57 -0400 (EDT) Received: by mercury.corp.iready.com with Internet Mail Service (5.5.2653.19) id ; Mon, 29 Jul 2002 18:44:51 -0700 Message-ID: <034670D62D19D31180990090277A37B702840FFD@mercury.corp.iready.com> From: Michael Smith To: "'Jonathan Stone'" , pat_thaler@agilent.com Cc: marjorie_krueger@hp.com, ips@ece.cmu.edu, Michael Smith Subject: RE: iSCSI: reference for CRC32C? Date: Mon, 29 Jul 2002 18:44:51 -0700 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C2376A.B1E85690" Sender: owner-ips@ece.cmu.edu Precedence: bulk This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_001_01C2376A.B1E85690 Content-Type: text/plain; charset="iso-8859-1" I think this reference below was in one of Julian's earlier drafts. I happen to have ASCII and EndNote citations from http://ieeexplore.ieee.org, but I'm not saying this is the normative reference to CRC-C. Optimization of cyclic redundancy-check codes with 24 and 32 parity bits Castagnoli, G.; Brauer, S.; Herrmann, M. Communications, IEEE Transactions on , Vol.41, Iss.6, 1993 Pages: 883- 892 URL: http://ieeexplore.ieee.org/iel1/26/5993/00231911.pdf?isNumber=5993&prod=JNL& arnumber=00231911 (you need an IEEE subscription that goes back that far) TY - JOUR TI - Optimization of cyclic redundancy-check codes with 24 and 32 parity bits SP - 883 EP - 892 AU - Castagnoli, G. AU - Brauer, S. AU - Herrmann, M. PB - Theoretical or Mathematical KW - optimisation KW - cyclic redundancy-check codes KW - minimum distance KW - shortened Hamming codes KW - weight distribution KW - shortened cyclic codes KW - high-speed special-purpose processor KW - CRC KW - block lengths KW - IEEE-802 KW - cyclic codes KW - error correction codes KW - error detection codes KW - Hamming codes KW - optimisation PY - 1993 VL - 41 IS - 6 JO - Communications, IEEE Transactions on JA - Communications, IEEE Transactions on ER - -----Original Message----- From: Jonathan Stone [mailto:jonathan@dsg.stanford.edu] Sent: Monday, July 29, 2002 4:51 PM To: pat_thaler@agilent.com Cc: marjorie_krueger@hp.com; ips@ece.cmu.edu Subject: Re: iSCSI: reference for CRC32C? In message <1BEBA5E8600DD4119A50009027AF54A00D373802@axcs04.cos.agilent.com>pat_thaler@ agilent.com writes >Margorie, > >The text in 11.1 suffices to fully define the algorithm. Agreed, It does specify the algorithm. But IMHO the spec should still cite the original source --- Castagnoli et al. --- because that is the original source. And because that's where to start looking, for anyone who cares about the ins and outs of the specific choice of algorithm. The citation i have handy is: @Article{castagnoli-crc, author = { Guy Castagnoli and Stefan Braeuer and Martin Herrman}, title = {{Optimization of Cyclic Redundancy-Check Codes with 24 and 32 Parity Bits}}, journal = IEEE Transactions on Communication, year = {1993}, volume = {41}, number = {6}, pages = {}, month = {June}, } (I have a hardcopy, with page numbers, if I can find it.) ------_=_NextPart_001_01C2376A.B1E85690 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable RE: iSCSI: reference for CRC32C?

I think this reference below was in one of Julian's = earlier drafts. I happen to have ASCII and EndNote citations from http://ieeexplore.ieee.org, but I'm not saying = this is the normative reference to CRC-C.


Optimization of cyclic redundancy-check codes with 24 = and 32 parity bits
Castagnoli, G.; Brauer, S.; Herrmann, M.
Communications, IEEE Transactions on , Vol.41, = Iss.6, 1993
Pages: 883- 892
URL: http://ieeexplore.ieee.org/iel1/26/5993/00231911.pdf?i= sNumber=3D5993&prod=3DJNL&arnumber=3D00231911 (you need an IEEE = subscription that goes back that far)

TY  - JOUR

TI  - Optimization of cyclic redundancy-check = codes with 24 and 32 parity bits

SP  - 883

EP  - 892

AU  - Castagnoli, G.

AU  - Brauer, S.

AU  - Herrmann, M.

PB  - Theoretical or Mathematical

KW  - optimisation

KW  - cyclic redundancy-check codes

KW  - minimum distance

KW  - shortened Hamming codes

KW  - weight distribution

KW  - shortened cyclic codes

KW  - high-speed special-purpose = processor

KW  - CRC

KW  - block lengths

KW  - IEEE-802

KW  - cyclic codes

KW  - error correction codes

KW  - error detection codes

KW  - Hamming codes

KW  - optimisation

PY  - 1993

VL  - 41

IS  - 6

JO  - Communications, IEEE Transactions = on


JA  - Communications, IEEE Transactions = on


ER  -

-----Original Message-----
From: Jonathan Stone [mailto:jonathan@dsg.stanford.e= du]
Sent: Monday, July 29, 2002 4:51 PM
To: pat_thaler@agilent.com
Cc: marjorie_krueger@hp.com; ips@ece.cmu.edu
Subject: Re: iSCSI: reference for CRC32C?


In message = <1BEBA5E8600DD4119A50009027AF54A00D373802@axcs04.cos.agilent.com>p= at_thaler@agilent.com writes
>Margorie,
>
>The text in 11.1 suffices to fully define the = algorithm.

Agreed, It does specify the algorithm. But IMHO the = spec should still
cite the original source --- Castagnoli et al. --- = because that is the
original source.  And because that's where to = start looking, for anyone
who cares about the ins and outs of the specific = choice of algorithm.

The citation i have  handy is:
@Article{castagnoli-crc,
  author = =3D       { Guy Castagnoli and Stefan = Braeuer and Martin Herrman},
  title = =3D        {{Optimization of Cyclic = Redundancy-Check Codes with 24
          &nb= sp;       and 32 Parity Bits}},
  journal =3D      = IEEE Transactions on Communication,
  year = =3D         {1993},
  volume = =3D       {41},
  number = =3D       {6},
  pages = =3D        {},
  month = =3D        {June},
}

(I have a hardcopy, with page numbers, if I can find = it.)

------_=_NextPart_001_01C2376A.B1E85690-- From owner-ips@ece.cmu.edu Tue Jul 30 04:32:16 2002 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA08412 for ; Tue, 30 Jul 2002 04:32:15 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id g6U7uLZ04628 for ips-outgoing; Tue, 30 Jul 2002 03:56:21 -0400 (EDT) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from galileo5.galileo.co.il (pop3.galileo.co.il [199.203.130.130]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id g6U7uJo04623 for ; Tue, 30 Jul 2002 03:56:19 -0400 (EDT) Received: from LT19 ([10.3.1.10]) by galileo.co.il (8.8.5/8.8.5) with SMTP id KAA17108; Tue, 30 Jul 2002 10:52:59 +0200 (GMT-2) Message-ID: <069b01c237a6$df89e410$2401030a@LT19> From: "Yuval Avnon" To: , , References: <1BEBA5E8600DD4119A50009027AF54A00D373802@axcs04.cos.agilent.com> Subject: Re: iSCSI: reference for CRC32C? Date: Tue, 30 Jul 2002 10:55:36 +0200 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.50.4522.1200 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4522.1200 Sender: owner-ips@ece.cmu.edu Precedence: bulk Content-Transfer-Encoding: 7bit Is there any reference CRC32C code available? (In addition to the calculation examples in appendix B.4) Thanks, Yuval Avnon - Galileo technologies. ----- Original Message ----- From: To: ; Sent: Tuesday, July 30, 2002 0:44 Subject: RE: iSCSI: reference for CRC32C? > Margorie, > > The text in 11.1 suffices to fully define the algorithm. > > Regards, > Pat > > -----Original Message----- > From: KRUEGER,MARJORIE (HP-Roseville,ex1) > [mailto:marjorie_krueger@hp.com] > Sent: Monday, July 29, 2002 2:13 PM > To: Ips Reflector (E-mail) > Subject: iSCSI: reference for CRC32C? > > > Looking thru the current draft I can't find any doc. reference for the > definition of CRC32C. Does the text in sec 11.1 suffice, or is there some > other document that fully defines the algorithm for CRC32C? If so, > shouldn't it be referenced in the bibliography? > > Thanks > Marjorie > From owner-ips@ece.cmu.edu Tue Jul 30 08:13:52 2002 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA14150 for ; Tue, 30 Jul 2002 08:13:52 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id g6UBbnF21955 for ips-outgoing; Tue, 30 Jul 2002 07:37:49 -0400 (EDT) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from mail15.bigmailbox.com (mail15.bigmailbox.com [209.132.220.46]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id g6UBbko21947 for ; Tue, 30 Jul 2002 07:37:47 -0400 (EDT) Received: (from www@localhost) by mail15.bigmailbox.com (8.11.6/8.10.0) id g6UBbe519384; Tue, 30 Jul 2002 04:37:40 -0700 Date: Tue, 30 Jul 2002 04:37:40 -0700 Message-Id: <200207301137.g6UBbe519384@mail15.bigmailbox.com> Content-Type: text/plain Content-Disposition: inline Content-Transfer-Encoding: binary X-Mailer: MIME-tools 4.104 (Entity 4.116) Mime-Version: 1.0 X-Originating-Ip: [208.236.45.61] From: "Praveen madhavan" To: ips@ece.cmu.edu Subject: Invalid Pdus received during Login phase Sender: owner-ips@ece.cmu.edu Precedence: bulk Content-Transfer-Encoding: binary Hi, I would like to know the behavior of Target, when it receives invalid Pdu's during login phase. Will target generates login response with Error of status detail -"Invalid during login" and terminates the connections. Or Reject command with reason code- "Protocol Error/Invalid PDU". If Invalid Pdus are received by Target, even before login phase ( I mean just before first login request from initiator), i think target can't send login response for it since it was not aware of ISID. In such senario how will target react ? regards Praveen.M ------------------------------------------------------------ NEW - FREE Nettaxi 56kbs Dial-up INTERNET ACCESS with NO ADS or Ad Bars! http://www.nettaxi.com/isp/ From owner-ips@ece.cmu.edu Tue Jul 30 09:29:43 2002 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA17068 for ; Tue, 30 Jul 2002 09:29:41 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id g6UD0hi25224 for ips-outgoing; Tue, 30 Jul 2002 09:00:43 -0400 (EDT) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from d12lmsgate.de.ibm.com (d12lmsgate.de.ibm.com [195.212.91.199]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id g6UD0fo25220 for ; Tue, 30 Jul 2002 09:00:41 -0400 (EDT) Received: from d12relay02.de.ibm.com (d12relay02.de.ibm.com [9.165.215.23]) by d12lmsgate.de.ibm.com (8.12.3/8.12.3) with ESMTP id g6UD0Oqi025286; Tue, 30 Jul 2002 15:00:25 +0200 Received: from d10hubm1.telaviv.ibm.com (d10ml001.telaviv.ibm.com [9.148.216.55]) by d12relay02.de.ibm.com (8.12.3/NCO/VER6.3) with ESMTP id g6UD0Omj049484; Tue, 30 Jul 2002 15:00:24 +0200 To: Steve Senum Cc: ips@ece.cmu.edu MIME-Version: 1.0 Subject: Re: iSCSI - working draft and IANA X-Mailer: Lotus Notes Release 5.0.9 November 16, 2001 From: "Julian Satran" Message-ID: Date: Tue, 30 Jul 2002 16:00:21 +0300 X-MIMETrack: Serialize by Router on D10ML001/10/M/IBM(Release 5.0.9a |January 7, 2002) at 30/07/2002 16:00:24, Serialize complete at 30/07/2002 16:00:24 Content-Type: multipart/alternative; boundary="=_alternative 00468011C2256C06_=" Sender: owner-ips@ece.cmu.edu Precedence: bulk This is a multipart message in MIME format. --=_alternative 00468011C2256C06_= Content-Type: text/plain; charset="us-ascii" Registering the current keys is an issue already raised by Mallikarjun. The only think I can comment about is that I don't see what we stand to gain (and I can cleraly see the pain!). As for the prefixes - they are aimed at clearly delineating what is mandatory (key defined in the basic iSCSI doc) from vendor or group=of-vendors additions. The registration is meant to allow groups of vendors to agree on a key and provide a semantic doc (an RFC that can be informational). Julo Steve Senum 07/30/2002 01:48 AM To: Julian Satran/Haifa/IBM@IBMIL cc: ips@ece.cmu.edu Subject: Re: iSCSI - working draft and IANA Julian, 1. I would suggest registering all the current iSCSI keys, auth methods, and digests with the IANA, with references to the iSCSI RFC (when published), and dropping the X#, Y#, and Z# prefixes. This would be more consistent with how I have seen this done in the past. 2. I am not sure I really see the need. In other cases, this is done to allow vendor specific registrations, but we already have a mechanism for that (the X- prefix). Note that there is no reason why a vendor can't defined a vendor specific key in an informational RFC. Regards, Steve Senum Julian Satran wrote: > > Dear colleagues, > > The current (today's) version of the draft has a revised IANA consideration > section > and specific indication on how to build keys, authentication methods and > digests. > > David Black suggested that we might want to go for 3 different registries > maintained by IANA for iSCSI > and I liked the idea. > > Please comment, > Julo --=_alternative 00468011C2256C06_= Content-Type: text/html; charset="us-ascii"
Registering the current keys is an issue already raised by Mallikarjun. The only think I can comment about is that I don't see what we stand to gain (and I can cleraly see the  pain!).

As for the prefixes - they are aimed at clearly delineating what is mandatory (key defined in the basic iSCSI doc) from vendor or group=of-vendors additions.

The registration is meant to allow groups of vendors to agree on a key and provide a semantic doc (an RFC that can be informational).

Julo


Steve Senum <ssenum@cisco.com>

07/30/2002 01:48 AM

       
        To:        Julian Satran/Haifa/IBM@IBMIL
        cc:        ips@ece.cmu.edu
        Subject:        Re: iSCSI - working draft and IANA

       


Julian,

1. I would suggest registering all the current iSCSI keys, auth methods,
and digests with the IANA, with references to the iSCSI RFC (when published),
and dropping the X#, Y#, and Z# prefixes.  This would be more consistent
with how I have seen this done in the past.

2. I am not sure I really see the need.  In other cases, this is done
to allow vendor specific registrations, but we already have a mechanism
for that (the X- prefix).  Note that there is no reason why a vendor
can't defined a vendor specific key in an informational RFC.

Regards,
Steve Senum

Julian Satran wrote:
>
> Dear colleagues,
>
> The current (today's) version of the draft has a revised IANA consideration
> section
> and specific  indication on how to build keys, authentication methods and
> digests.
>
> David Black suggested that we might want to go for 3 different registries
> maintained by IANA for iSCSI
> and I liked the idea.
>
> Please comment,
> Julo

--=_alternative 00468011C2256C06_=-- From owner-ips@ece.cmu.edu Tue Jul 30 14:24:42 2002 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA03295 for ; Tue, 30 Jul 2002 14:24:42 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id g6UHZmx11679 for ips-outgoing; Tue, 30 Jul 2002 13:35:48 -0400 (EDT) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from sj-msg-core-1.cisco.com (sj-msg-core-1.cisco.com [171.71.163.11]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id g6UHZjo11675 for ; Tue, 30 Jul 2002 13:35:45 -0400 (EDT) Received: from sj-msg-av-3.cisco.com (sj-msg-av-3.cisco.com [171.69.17.42]) by sj-msg-core-1.cisco.com (8.12.2/8.12.2) with ESMTP id g6UHZbAK014852; Tue, 30 Jul 2002 10:35:37 -0700 (PDT) Received: from nisser.cisco.com (localhost [127.0.0.1]) by sj-msg-av-3.cisco.com (8.12.2/8.12.2) with ESMTP id g6UHZbNS021297; Tue, 30 Jul 2002 10:35:37 -0700 (PDT) Received: from cisco.com (mbakke@mbakke-lnx.cisco.com [161.44.68.87]) by nisser.cisco.com (8.8.6 (PHNE_14041)/CISCO.SERVER.1.2) with ESMTP id KAA23259; Tue, 30 Jul 2002 10:35:35 -0700 (PDT) Message-ID: <3D46D254.636E9ED0@cisco.com> Date: Tue, 30 Jul 2002 12:52:20 -0500 From: Mark Bakke X-Mailer: Mozilla 4.72 [en] (X11; U; Linux 2.2.16-3.uid32 i686) X-Accept-Language: en, de MIME-Version: 1.0 To: Julian Satran CC: Steve Senum , ips@ece.cmu.edu Subject: Re: iSCSI - working draft and IANA References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ips@ece.cmu.edu Precedence: bulk Content-Transfer-Encoding: 7bit Julian- I'm not sure I see the need for registering keys, but that aside, if we register digest and auth methods I would suggest that we also register an integer method number with each; this will make it easier to add them to the MIBs. I would also suggest that we register the current ones as well as any extensions. -- Mark Julian Satran wrote: > > Registering the current keys is an issue already raised by Mallikarjun. The only think I can > comment about is that I don't see what we stand to gain (and I can cleraly see the pain!). > > As for the prefixes - they are aimed at clearly delineating what is mandatory (key defined in the > basic iSCSI doc) from vendor or group=of-vendors additions. > > The registration is meant to allow groups of vendors to agree on a key and provide a semantic doc > (an RFC that can be informational). > > Julo > > Steve Senum > To: Julian Satran/Haifa/IBM@IBMIL > 07/30/2002 01:48 AM cc: ips@ece.cmu.edu > Subject: Re: iSCSI - working draft and IANA > > > > Julian, > > 1. I would suggest registering all the current iSCSI keys, auth methods, > and digests with the IANA, with references to the iSCSI RFC (when published), > and dropping the X#, Y#, and Z# prefixes. This would be more consistent > with how I have seen this done in the past. > > 2. I am not sure I really see the need. In other cases, this is done > to allow vendor specific registrations, but we already have a mechanism > for that (the X- prefix). Note that there is no reason why a vendor > can't defined a vendor specific key in an informational RFC. > > Regards, > Steve Senum > > Julian Satran wrote: > > > > Dear colleagues, > > > > The current (today's) version of the draft has a revised IANA consideration > > section > > and specific indication on how to build keys, authentication methods and > > digests. > > > > David Black suggested that we might want to go for 3 different registries > > maintained by IANA for iSCSI > > and I liked the idea. > > > > Please comment, > > Julo -- Mark A. Bakke Cisco Systems mbakke@cisco.com 763.398.1054 From owner-ips@ece.cmu.edu Tue Jul 30 14:27:38 2002 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA03457 for ; Tue, 30 Jul 2002 14:27:37 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id g6UI4Iu13206 for ips-outgoing; Tue, 30 Jul 2002 14:04:18 -0400 (EDT) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from msgbas1.cos.agilent.com (msgbas1x.cos.agilent.com [192.25.240.36]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id g6UI4Go13201 for ; Tue, 30 Jul 2002 14:04:16 -0400 (EDT) Received: from msgrel1t.cos.agilent.com (msgrel1t.cos.agilent.com [130.29.152.157]) by msgbas1.cos.agilent.com (Postfix) with ESMTP id 0DE5CC9AE; Tue, 30 Jul 2002 12:04:16 -0600 (MDT) Received: from axcsbh3.cos.agilent.com (axcsbh3.cos.agilent.com [130.29.152.190]) by msgrel1t.cos.agilent.com (Postfix) with SMTP id 6DCEE517; Tue, 30 Jul 2002 12:04:15 -0600 (MDT) Received: from 130.29.152.190 by axcsbh3.cos.agilent.com (InterScan E-Mail VirusWall NT); Tue, 30 Jul 2002 12:04:14 -0600 Received: by axcsbh3.cos.agilent.com with Internet Mail Service (5.5.2653.19) id ; Tue, 30 Jul 2002 12:04:14 -0600 Message-ID: <01A7DAF31F93D511AEE300D0B706ED9201BF4A46@axcs13.cos.agilent.com> From: vince_cavanna@agilent.com To: yuvala@galileo.co.il Cc: vince_cavanna@agilent.com, pat_thaler@agilent.com, marjorie_krueger@hp.com, ips@ece.cmu.edu Subject: RE: iSCSI: reference for CRC32C? Date: Tue, 30 Jul 2002 12:04:11 -0600 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-ips@ece.cmu.edu Precedence: bulk Yuval, Unless things have changed recently, SCTP uses the same polynomial and algorithm as iSCSI and includes tested sample code in their spec. See IETF's working group Tsvwg. Vince |-----Original Message----- |From: Yuval Avnon [mailto:yuvala@galileo.co.il] |Sent: Tuesday, July 30, 2002 1:56 AM |To: pat_thaler@agilent.com; marjorie_krueger@hp.com; ips@ece.cmu.edu |Subject: Re: iSCSI: reference for CRC32C? | | | |Is there any reference CRC32C code available? (In addition to the |calculation examples in appendix B.4) | |Thanks, |Yuval Avnon - Galileo technologies. | |----- Original Message ----- |From: |To: ; |Sent: Tuesday, July 30, 2002 0:44 |Subject: RE: iSCSI: reference for CRC32C? | | |> Margorie, |> |> The text in 11.1 suffices to fully define the algorithm. |> |> Regards, |> Pat |> |> -----Original Message----- |> From: KRUEGER,MARJORIE (HP-Roseville,ex1) |> [mailto:marjorie_krueger@hp.com] |> Sent: Monday, July 29, 2002 2:13 PM |> To: Ips Reflector (E-mail) |> Subject: iSCSI: reference for CRC32C? |> |> |> Looking thru the current draft I can't find any doc. |reference for the |> definition of CRC32C. Does the text in sec 11.1 suffice, or |is there some |> other document that fully defines the algorithm for CRC32C? If so, |> shouldn't it be referenced in the bibliography? |> |> Thanks |> Marjorie |> | From owner-ips@ece.cmu.edu Tue Jul 30 15:28:59 2002 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA05914 for ; Tue, 30 Jul 2002 15:28:58 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id g6UIotw16592 for ips-outgoing; Tue, 30 Jul 2002 14:50:55 -0400 (EDT) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from e31.co.us.ibm.com (e31.co.us.ibm.com [32.97.110.129]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id g6UIoro16583 for ; Tue, 30 Jul 2002 14:50:53 -0400 (EDT) Received: from westrelay02.boulder.ibm.com (westrelay02.boulder.ibm.com [9.17.194.23]) by e31.co.us.ibm.com (8.12.2/8.12.2) with ESMTP id g6UIokXW043094; Tue, 30 Jul 2002 14:50:47 -0400 Received: from d03nm014.boulder.ibm.com (d03nm014.boulder.ibm.com [9.17.194.13]) by westrelay02.boulder.ibm.com (8.12.3/NCO/VER6.3) with ESMTP id g6UIojxx018702; Tue, 30 Jul 2002 12:50:45 -0600 X-Priority: 1 (High) Importance: Normal Subject: Re: iSCSI - working draft and IANA To: Mark Bakke Cc: "Julian Satran" , Steve Senum , ips@ece.cmu.edu X-Mailer: Lotus Notes Release 5.0.7 March 21, 2001 Message-ID: From: "John Hufferd" Date: Tue, 30 Jul 2002 11:48:02 -0700 X-MIMETrack: Serialize by Router on D03NM014/03/M/IBM(Release 5.0.10 |March 22, 2002) at 07/30/2002 12:50:45 PM MIME-Version: 1.0 Content-type: text/plain; charset=us-ascii Sender: owner-ips@ece.cmu.edu Precedence: bulk Mark, Please explain about the need to register the current ones, what will that buy us? . . . John L. Hufferd Senior Technical Staff Member (STSM) IBM/SSG San Jose Ca Main Office (408) 256-0403, Tie: 276-0403, eFax: (408) 904-4688 Home Office (408) 997-6136, Cell: (408) 499-9702 Internet address: hufferd@us.ibm.com Mark Bakke @ece.cmu.edu on 07/30/2002 10:52:20 AM Sent by: owner-ips@ece.cmu.edu To: Julian Satran/Haifa/IBM@IBMIL cc: Steve Senum , ips@ece.cmu.edu Subject: Re: iSCSI - working draft and IANA Julian- I'm not sure I see the need for registering keys, but that aside, if we register digest and auth methods I would suggest that we also register an integer method number with each; this will make it easier to add them to the MIBs. I would also suggest that we register the current ones as well as any extensions. -- Mark Julian Satran wrote: > > Registering the current keys is an issue already raised by Mallikarjun. The only think I can > comment about is that I don't see what we stand to gain (and I can cleraly see the pain!). > > As for the prefixes - they are aimed at clearly delineating what is mandatory (key defined in the > basic iSCSI doc) from vendor or group=of-vendors additions. > > The registration is meant to allow groups of vendors to agree on a key and provide a semantic doc > (an RFC that can be informational). > > Julo > > Steve Senum > To: Julian Satran/Haifa/IBM@IBMIL > 07/30/2002 01:48 AM cc: ips@ece.cmu.edu > Subject: Re: iSCSI - working draft and IANA > > > > Julian, > > 1. I would suggest registering all the current iSCSI keys, auth methods, > and digests with the IANA, with references to the iSCSI RFC (when published), > and dropping the X#, Y#, and Z# prefixes. This would be more consistent > with how I have seen this done in the past. > > 2. I am not sure I really see the need. In other cases, this is done > to allow vendor specific registrations, but we already have a mechanism > for that (the X- prefix). Note that there is no reason why a vendor > can't defined a vendor specific key in an informational RFC. > > Regards, > Steve Senum > > Julian Satran wrote: > > > > Dear colleagues, > > > > The current (today's) version of the draft has a revised IANA consideration > > section > > and specific indication on how to build keys, authentication methods and > > digests. > > > > David Black suggested that we might want to go for 3 different registries > > maintained by IANA for iSCSI > > and I liked the idea. > > > > Please comment, > > Julo -- Mark A. Bakke Cisco Systems mbakke@cisco.com 763.398.1054 From owner-ips@ece.cmu.edu Tue Jul 30 16:27:55 2002 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA07643 for ; Tue, 30 Jul 2002 16:27:54 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id g6UJvPJ21282 for ips-outgoing; Tue, 30 Jul 2002 15:57:25 -0400 (EDT) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from pepsi.splentec.com (ns.splentec.com [209.47.35.194]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id g6UJvNo21277 for ; Tue, 30 Jul 2002 15:57:23 -0400 (EDT) Received: from splentec.com (canoe.splentec.com [209.47.35.250]) by pepsi.splentec.com (8.11.6/8.11.0) with ESMTP id g6UJv6s16874; Tue, 30 Jul 2002 15:57:07 -0400 Message-ID: <3D46EF95.4F369001@splentec.com> Date: Tue, 30 Jul 2002 15:57:09 -0400 From: Luben Tuikov Organization: Splentec Ltd. X-Mailer: Mozilla 4.79 [en] (X11; U; Linux 2.4.19-rc3 i686) X-Accept-Language: en MIME-Version: 1.0 To: "KRUEGER,MARJORIE (HP-Roseville,ex1)" CC: "Ips Reflector (E-mail)" , David Black , Julian Satran Subject: Re: iSCSI: reference for CRC32C? References: <6BD67FFB937FD411A04F00D0B74FE87805CCF70C@xrose06.rose.hp.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ips@ece.cmu.edu Precedence: bulk Content-Transfer-Encoding: 7bit "KRUEGER,MARJORIE (HP-Roseville,ex1)" wrote: > > Looking thru the current draft I can't find any doc. reference for the > definition of CRC32C. Does the text in sec 11.1 suffice, or is there some > other document that fully defines the algorithm for CRC32C? If so, > shouldn't it be referenced in the bibliography? If I read your sentence correctly ``other document that fully defines the algorithm for CRC32C'', yes, there is: http://www.haifa.il.ibm.com/satran/ips/Vince-Luben-crc32c-01.pdf It fully ``defines the algorithm for CRC32C''. It also quotes: (i) Castagnoli et al. which don't talk about algoritms but analysis of the CRC space, probabilites etc and (ii) a paper by Williams which shows C code. This is from the abstract: ``The CRC32C (aka CRC32/4) digest from iSCSI is presented in a rigorous algebraic manner, the why and how it works and the origin of its verifier constant. The most commonly used CRC digest computation algorithm in iSCSI and Ethernet, the Simultaneous Multiply and Divide (SMD), is derived from the long division algorithm. Sample implementations are provided of both algorithms.'' At the end, a pseudo code implementation is given of SMD, which is what you'll find in actual implementations, including OS networking layer code, network interface device driver source code and hardware. The jump to SMD with table lookup (a great speed up) is trivial and is also mentioned. BTW, this exact question I've seen several times on IPS, ever since that paper appeared, but no one has quoted it yet. The irony is that, unbeknownst to me until last week, if you search for iSCSI on google.com, on most of the cites that will come up, you'll see several white paper references on iSCSI and one of them will be ``the definitive guide to iSCSI CRC <>'', yet no one ever mentions it on IPS... -- Luben P.S. Perhaps a Linux outlook on how science is conducted by big companies is the only salvation. Yes, I know its new and has never existed but in philosophy, only until recently, but is more productive and fruitful. OTOH, everything I've seen so far is exactly as History of Science would tell us. From owner-ips@ece.cmu.edu Tue Jul 30 16:28:27 2002 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA07689 for ; Tue, 30 Jul 2002 16:28:26 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id g6UJtgt21148 for ips-outgoing; Tue, 30 Jul 2002 15:55:42 -0400 (EDT) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from msgbas1.cos.agilent.com (msgbas1x.cos.agilent.com [192.25.240.36]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id g6UJteo21144 for ; Tue, 30 Jul 2002 15:55:40 -0400 (EDT) Received: from msgrel1t.cos.agilent.com (msgrel1t.cos.agilent.com [130.29.152.157]) by msgbas1.cos.agilent.com (Postfix) with ESMTP id BBC58A1A2; Tue, 30 Jul 2002 13:55:39 -0600 (MDT) Received: from axcsbh4.cos.agilent.com (axcsbh4.cos.agilent.com [130.29.152.145]) by msgrel1t.cos.agilent.com (Postfix) with SMTP id 72AE751E; Tue, 30 Jul 2002 13:55:39 -0600 (MDT) Received: from 130.29.152.145 by axcsbh4.cos.agilent.com (InterScan E-Mail VirusWall NT); Tue, 30 Jul 2002 13:55:23 -0600 Received: by axcsbh4.cos.agilent.com with Internet Mail Service (5.5.2653.19) id ; Tue, 30 Jul 2002 13:55:22 -0600 Message-ID: <1BEBA5E8600DD4119A50009027AF54A00D37399C@axcs04.cos.agilent.com> From: pat_thaler@agilent.com To: praveenm@nettaxi.com, ips@ece.cmu.edu Subject: RE: Invalid Pdus received during Login phase Date: Tue, 30 Jul 2002 13:55:20 -0600 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-ips@ece.cmu.edu Precedence: bulk Praveen, This appears to be covered in 2.3 Last paragraph on page 33. "Before the Full Feature Phase is established, only Login Request and Login Response PDUs are allowed. Any other PDU, when received at initiator or target, is a protocol error and MUST result in the connection being terminated." So, if the target gets PDU that isn't a Login Request PDU during login, it closes the TCP connection (it might be more clear to say "TCP connection" rather than just "connection" in the text quoted above). It can't send a Login Response PDU because it hasn't gotten a Login Request to respond to. This response should be valid even if no Login PDUs have been received. In researching this, I noticed that an earlier discussion on the use of protocol error vs negotiation failure seems to have been incompletely applied. 4.2.1 last sentence is confusing. It reads: "The selection of a value not proposed is considered a negotiation failure and MUST be handled as a protocol error." 5.10 and 5.11 cover Negotiation Failures and Protocol errors, respectively, so this sentence makes it unclear which applies. It should say "The selection of a value not proposed MUST be handled as a negotiation failure." 4.2.2 The same edit applies to the third paragraph of 4.2.2. 4.3 Page 70 fifth paragraph "is considered a protocol error" should be "MUST be handled as a negotiation failure." 4.4 Page 78 second paragraph from bottom. Should "Reject" be "Reject PDU"? "Reject" could be misunderstood to be the value "Reject" but then there isn't any way to return "protocol error". Regards, Pat -----Original Message----- From: Praveen madhavan [mailto:praveenm@nettaxi.com] Sent: Tuesday, July 30, 2002 4:38 AM To: ips@ece.cmu.edu Subject: Invalid Pdus received during Login phase Hi, I would like to know the behavior of Target, when it receives invalid Pdu's during login phase. Will target generates login response with Error of status detail -"Invalid during login" and terminates the connections. Or Reject command with reason code- "Protocol Error/Invalid PDU". If Invalid Pdus are received by Target, even before login phase ( I mean just before first login request from initiator), i think target can't send login response for it since it was not aware of ISID. In such senario how will target react ? regards Praveen.M ------------------------------------------------------------ NEW - FREE Nettaxi 56kbs Dial-up INTERNET ACCESS with NO ADS or Ad Bars! http://www.nettaxi.com/isp/ From owner-ips@ece.cmu.edu Tue Jul 30 17:22:23 2002 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA09540 for ; Tue, 30 Jul 2002 17:22:23 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id g6UKj3P24666 for ips-outgoing; Tue, 30 Jul 2002 16:45:03 -0400 (EDT) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from msgbas2.cos.agilent.com (msgbas2x.cos.agilent.com [192.25.240.37]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id g6UKiwo24658 for ; Tue, 30 Jul 2002 16:44:59 -0400 (EDT) Received: from msgrel1t.cos.agilent.com (msgrel1t.cos.agilent.com [130.29.152.157]) by msgbas2.cos.agilent.com (Postfix) with ESMTP id D9BA61F03; Tue, 30 Jul 2002 14:44:57 -0600 (MDT) Received: from axcsbh6.cos.agilent.com (axcsbh6.cos.agilent.com [130.29.152.171]) by msgrel1t.cos.agilent.com (Postfix) with SMTP id 388B8577; Tue, 30 Jul 2002 14:44:57 -0600 (MDT) Received: from 130.29.152.171 by axcsbh6.cos.agilent.com (InterScan E-Mail VirusWall NT); Tue, 30 Jul 2002 14:44:56 -0600 Received: by axcsbh6.cos.agilent.com with Internet Mail Service (5.5.2653.19) id ; Tue, 30 Jul 2002 14:44:56 -0600 Message-ID: <1BEBA5E8600DD4119A50009027AF54A00D3739B4@axcs04.cos.agilent.com> From: pat_thaler@agilent.com To: luben@splentec.com, marjorie_krueger@hp.com Cc: ips@ece.cmu.edu, Black_David@emc.com, Julian_Satran@il.ibm.com Subject: RE: iSCSI: reference for CRC32C? Date: Tue, 30 Jul 2002 14:44:52 -0600 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-ips@ece.cmu.edu Precedence: bulk Luben, Actually, I have referred people to that document. I think I have done it on IPS and I know I did it during discussions on SCTP. I have also referred some IEEE 802 people to it when they came to me with CRC questions. However, I don't think the document is reference-able by an RFC. It isn't an RFC and it hasn't been formally published. To be an RFC it would have to be in text format. No one has been willing to take on conversion to text format which in any case would reduce readability as the equations get really long in flat text. When one cites a published article, then one can count on it being retrievable for the life of the RFC. It is in databases that can be accessed by libraries. Unpublished documents on websites don't tend to have that longevity. They are useful for discussions during development of a draft but they may not hang around for the life of the standard. If you want formal references to it, I suggest that you and Vince get it published somewhere. Regards, Pat -----Original Message----- From: Luben Tuikov [mailto:luben@splentec.com] Sent: Tuesday, July 30, 2002 12:57 PM To: KRUEGER,MARJORIE (HP-Roseville,ex1) Cc: Ips Reflector (E-mail); David Black; Julian Satran Subject: Re: iSCSI: reference for CRC32C? "KRUEGER,MARJORIE (HP-Roseville,ex1)" wrote: > > Looking thru the current draft I can't find any doc. reference for the > definition of CRC32C. Does the text in sec 11.1 suffice, or is there some > other document that fully defines the algorithm for CRC32C? If so, > shouldn't it be referenced in the bibliography? If I read your sentence correctly ``other document that fully defines the algorithm for CRC32C'', yes, there is: http://www.haifa.il.ibm.com/satran/ips/Vince-Luben-crc32c-01.pdf It fully ``defines the algorithm for CRC32C''. It also quotes: (i) Castagnoli et al. which don't talk about algoritms but analysis of the CRC space, probabilites etc and (ii) a paper by Williams which shows C code. This is from the abstract: ``The CRC32C (aka CRC32/4) digest from iSCSI is presented in a rigorous algebraic manner, the why and how it works and the origin of its verifier constant. The most commonly used CRC digest computation algorithm in iSCSI and Ethernet, the Simultaneous Multiply and Divide (SMD), is derived from the long division algorithm. Sample implementations are provided of both algorithms.'' At the end, a pseudo code implementation is given of SMD, which is what you'll find in actual implementations, including OS networking layer code, network interface device driver source code and hardware. The jump to SMD with table lookup (a great speed up) is trivial and is also mentioned. BTW, this exact question I've seen several times on IPS, ever since that paper appeared, but no one has quoted it yet. The irony is that, unbeknownst to me until last week, if you search for iSCSI on google.com, on most of the cites that will come up, you'll see several white paper references on iSCSI and one of them will be ``the definitive guide to iSCSI CRC <>'', yet no one ever mentions it on IPS... -- Luben P.S. Perhaps a Linux outlook on how science is conducted by big companies is the only salvation. Yes, I know its new and has never existed but in philosophy, only until recently, but is more productive and fruitful. OTOH, everything I've seen so far is exactly as History of Science would tell us. From owner-ips@ece.cmu.edu Tue Jul 30 17:23:03 2002 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA09747 for ; Tue, 30 Jul 2002 17:23:03 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id g6UL7TL26143 for ips-outgoing; Tue, 30 Jul 2002 17:07:29 -0400 (EDT) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from pepsi.splentec.com (ns.splentec.com [209.47.35.194]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id g6UL7Ro26138 for ; Tue, 30 Jul 2002 17:07:27 -0400 (EDT) Received: from splentec.com (canoe.splentec.com [209.47.35.250]) by pepsi.splentec.com (8.11.6/8.11.0) with ESMTP id g6UL7Es17241; Tue, 30 Jul 2002 17:07:14 -0400 Message-ID: <3D470004.53D2AFD8@splentec.com> Date: Tue, 30 Jul 2002 17:07:16 -0400 From: Luben Tuikov Organization: Splentec Ltd. X-Mailer: Mozilla 4.79 [en] (X11; U; Linux 2.4.19-rc3 i686) X-Accept-Language: en MIME-Version: 1.0 To: pat_thaler@agilent.com CC: marjorie_krueger@hp.com, ips@ece.cmu.edu, Black_David@emc.com, Julian_Satran@il.ibm.com Subject: Re: iSCSI: reference for CRC32C? References: <1BEBA5E8600DD4119A50009027AF54A00D3739B4@axcs04.cos.agilent.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ips@ece.cmu.edu Precedence: bulk Content-Transfer-Encoding: 7bit pat_thaler@agilent.com wrote: > > However, I don't think the document is reference-able by an RFC. It isn't an RFC and it hasn't been formally published. To be an RFC it would have to be in text format. No one has been willing to take on conversion to text format which in any case would reduce readability as the equations get really long in flat text. When one cites a published article, then one can count on it being retrievable for the life of the RFC. It is in databases that can be accessed by libraries. Unpublished documents on websites don't tend to have that longevity. They are useful for discussions during development of a draft but they may not hang around for the life of the standard. > I wasn't talking about ``referencable by RFC''. As to Marjorie's original question, also which I quote, in my reply, I just wanted to help her out. I really tried to answer _without_ _any_ _ambiguitites_. Seems I failed. > If you want formal references to it, I suggest that you and Vince get it published somewhere. > I didn't mention ``formal references to it'' or anything in that respect remotely resembling. I just wanted to help out Marjorie. -- Luben From owner-ips@ece.cmu.edu Tue Jul 30 17:30:46 2002 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA09867 for ; Tue, 30 Jul 2002 17:30:46 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id g6ULMiI27137 for ips-outgoing; Tue, 30 Jul 2002 17:22:44 -0400 (EDT) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from lion.ninthwonder.com (lion.ninthwonder.com [151.199.66.147]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id g6ULMgo27130 for ; Tue, 30 Jul 2002 17:22:42 -0400 (EDT) Received: by lion.ninthwonder.com (Postfix, from userid 1021) id C9D5A30706; Tue, 30 Jul 2002 17:22:41 -0400 (EDT) Date: Tue, 30 Jul 2002 14:18:59 -0700 (PDT) From: Bill Studenmund X-X-Sender: To: Julian Satran Cc: Steve Senum , Subject: Re: iSCSI - working draft and IANA In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ips@ece.cmu.edu Precedence: bulk On Tue, 30 Jul 2002, Julian Satran wrote: > Registering the current keys is an issue already raised by Mallikarjun. > The only think I can comment about is that I don't see what we stand to > gain (and I can cleraly see the pain!). I think what we stand to gain is that then the IANA folks know what has already registered, so that someone can't register a name in the spec. Or so that the spec can't later start using names already registered. This discussion is assuming that the space open for IANA registration is not contrained to exclude keys already in the spec. Take care, Bill From owner-ips@ece.cmu.edu Tue Jul 30 18:16:35 2002 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA11143 for ; Tue, 30 Jul 2002 18:16:35 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id g6ULjIB28411 for ips-outgoing; Tue, 30 Jul 2002 17:45:18 -0400 (EDT) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from maho3msx2.isus.emc.com (maho3msx2.isus.emc.com [128.221.11.32]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id g6ULjHo28406 for ; Tue, 30 Jul 2002 17:45:17 -0400 (EDT) Received: by MAHO3MSX2 with Internet Mail Service (5.5.2653.19) id ; Tue, 30 Jul 2002 17:45:08 -0400 Message-ID: <277DD60FB639D511AC0400B0D068B71E0564C135@CORPMX14> From: Black_David@emc.com To: ips@ece.cmu.edu Subject: RE: iSCSI - working draft and IANA Date: Tue, 30 Jul 2002 17:45:03 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-ips@ece.cmu.edu Precedence: bulk Several comments on this topic: - The IANA text in the working draft is going to need some expansion. IANA will want explicit instructions on how to manage the registries, as IANA does *not* have a single or default set of procedures for this purpose and hence needs instructions on what is to be done. See RFC 2434. - The rationale for the X/Y/Z prefixes is to avoid losing key and value names to vendor registration that we might like to use in the future - future RFCs would be able to define new key and value names without problems, because we wouldn't us those prefixes. The # prefix ensures that registered and unregistered vendor-specified names can't conflict. Both of these are important (e.g., the X- format for vendor-specific keys is not going away at this stage). If the # character is objectionable, a possible alternative is that registered values MUST NOT contain a period ('.') and unregistered values MUST contain a period ('.') between the first and second components of the reversed domain name. We may also want to reserve/restrict the use of underscore ('_') to continue the convention that for AuthMethod , the keys that negotiate its parameters are named _* . - The reason for creating a registry for existing keys is that it would provide a single point of reference in the future as new keys get added to iSCSI. Right now this doesn't matter, but down the road, after a few RFCs add several new keys, having one place to look could be quite convenient. A number of things have been put into IANA registries after the fact as it was subsequently discovered that such a registry would be useful (e.g., the IP protocol number [IPv4/IPv6] is in such a registry). I may need to volunteer to help with the IANA text - it doesn't have to be perfect to Last Call the draft as long as for each registry, two things are clear: - The criteria for registration - the things that someone who wants to register something has to present to IANA. - How IANA handles registration requests, including reasons for rejection and requirements for review. I'm not sure about Mark Bakke's suggestion to number newly registered authentication/digest algorithms for MIB usage vs. having the MIB use the strings. In practice, the string is what names these algorithms, so using numbers seems to create an additional opportunity to get the algorithm (string) to number mapping wrong. 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 --------------------------------------------------- From owner-ips@ece.cmu.edu Tue Jul 30 20:23:06 2002 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA14025 for ; Tue, 30 Jul 2002 20:23:06 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id g6UNmSV05565 for ips-outgoing; Tue, 30 Jul 2002 19:48:28 -0400 (EDT) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from iol.unh.edu (io.iol.unh.edu [132.177.123.82]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id g6UNhBo05274 for ; Tue, 30 Jul 2002 19:43:11 -0400 (EDT) Received: from io.iol.unh.edu (localhost.localdomain [127.0.0.1]) by iol.unh.edu (8.12.3/8.12.3) with ESMTP id g6UNh56U008525; Tue, 30 Jul 2002 19:43:05 -0400 Received: from localhost (rdr@localhost) by io.iol.unh.edu (8.12.3/8.12.3/Submit) with ESMTP id g6UNh5tO008522; Tue, 30 Jul 2002 19:43:05 -0400 Date: Tue, 30 Jul 2002 19:43:05 -0400 (EDT) From: "Robert D. Russell" To: Julian Satran , Subject: Re: iSCSI: plugfest4 issues In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ips@ece.cmu.edu Precedence: bulk Julian: Four issues came up today at the iSCSI plugfest: 1. A question about whether or not the Residual Count field and the appropriate O and U bits need to be computed on all SCSI Response PDUs, regardless of the values in the Status and/or Response fields. One point of view says that the Residual Count field and the O and U bits appear to be strictly iSCSI values that are derived by the iSCSI target layer from the ExpectedDataTransferLength field of the SCSI Command PDU and the DataSegmentLength fields of the DataIn or DataOut PDUs sent as part of this command. Therefore ,the iSCSI target always computes a Residual Count value without regard to the Status and/or Response fields, since these are SCSI values. The other point of view says that the Residual Count field, and the O and U bits, need only be set when the Status and Response fields indicate that the command was completed at the target with a GOOD Status, and the target does not have to compute or set the Residual Count field and the O or U bits for other values of the Status and/or Response fields. Which is it? In any case, could this be clarified somewhere in the standard, most likely in section 9.4.4. 2. The last paragraph of section 2.2.3 says: "Before the Full Feature Phase is established, only Login Request and Login Response PDUs are allowed. Any other PDU, when received at ini- tiator or target, is a protocol error and MUST result in the connec- tion being terminated. ..." The question is the following: is this rule literally true for the target (i.e., can the target disconnect as soon as it receives a non-Login PDU from the initiator) or does the target have to first send a Login Response with Login reject PDU before disconnecting, as it does for all other errors detected by the target during Login Phase (according to section 4.3.1)? A related question is: does the target take the same action when the very first PDU it receives on a new TCP connection is not a Login Request PDU? If the target has to send the Login reject PDU before disconnecting, then the last paragraph of section 2.2.3 should be reworded along the following lines (modeled after the last paragraph of section 4.3): "Before the Full Feature Phase is established, only Login Request and Login Response PDUs are allowed. If the target receives any PDU other than Login Request, it must send a Login reject (code 0x020b) and then disconnect. If the initiator receives any PDU other than Login Response, it MUST drop the connection. ..." This wording would also appear to cover the case of when the very first PDU a target receives on a new TCP connection is not a Login Request. 3. Section 4.2 says: "All keys in Chapter 11, except for the X- extension format, MUST be supported by iSCSI initiators and targets and MUST NOT be answered with NotUnderstood." Two questions arose with this statement: 1. Shouldn't it say "All keys in Chapter 11 and Appendix A, ..." in order to include the Marker keys within the scope of this rule? 2. Does this literally mean that targets have to support initiator-only keys (and initiators support target-only keys)? For example, suppose a target sends an InitiatorAlias key, which is supposed to be sent only by Initiators. Does the target have to make an extra check to recognize that this is a "key in Chapter 11" that is used incorrectly, (so that it does not respond with NotUnderstood) or can it just treat it like it would any other key it cannot handle, for example, X-InitiatorAlias, and respond with NotUnderstood? This last question is actually a special case of a more general question, and that is: "How much checking does a receiver have to do?" just to generate a "proper error response"? Section 9 explicitly says that "Any compliant receiver MUST ignore any bit not defined and all reserved fields unless specified otherwise." This is the expression of the general philosophy "conservative in what you send, liberal in what you accept" and eliminates a lot of unnecessary checking. A similar general philosophy applied to other checking would be beneficial, although it may be hard to formulate it. 4. This is not a question but rather an observation for implementers. Not setting the I bit in a NOP-Out ping request can lead to unusual situations. Consider the situation where a session has multiple connections and the initiator periodically sends NOP-Out ping requests on each connection just to ensure that the target is still alive. If these NOP-Out requests are not immediate, and one of them gets lost (due to a bad checksum, or because that connection really is no longer alive), then none of the following NOP-Out requests on the other connections can be processed by the target, because that would be processing them out of CmdSN order, and as a result it would appear to the initiator that all connections are bad instead of just one! It appears that similar situations may arise when Task Management Function commands are sent without setting the I bit -- the target would be prevented from processing any of them that follow a command that is lost. Thank you for your consideration. Bob Russell InterOperability Lab University of New Hampshire rdr@iol.unh.edu 603-862-3774 From owner-ips@ece.cmu.edu Wed Jul 31 00:30:00 2002 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA19969 for ; Wed, 31 Jul 2002 00:29:46 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id g6V3t5B17838 for ips-outgoing; Tue, 30 Jul 2002 23:55:05 -0400 (EDT) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from pepsi.splentec.com (ns.splentec.com [209.47.35.194]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id g6V3t3o17833 for ; Tue, 30 Jul 2002 23:55:03 -0400 (EDT) Received: from splentec.com (canoe.splentec.com [209.47.35.250]) by pepsi.splentec.com (8.11.6/8.11.0) with ESMTP id g6V3sns19211; Tue, 30 Jul 2002 23:54:49 -0400 Message-ID: <3D475F89.2527AB8A@splentec.com> Date: Tue, 30 Jul 2002 23:54:49 -0400 From: Luben Tuikov Organization: Splentec Ltd. X-Mailer: Mozilla 4.79 [en] (X11; U; Linux 2.4.19-rc3 i686) X-Accept-Language: en MIME-Version: 1.0 To: "Robert D. Russell" , iSCSI Subject: Re: iSCSI: plugfest4 issues References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ips@ece.cmu.edu Precedence: bulk Content-Transfer-Encoding: 7bit "Robert D. Russell" wrote: > > 1. A question about whether or not the Residual Count field and the > appropriate O and U bits need to be computed on all SCSI Response > PDUs, regardless of the values in the Status and/or Response fields. In which case if a command fails completely for whatever reason, then you'd set the residual to equal edtl. This doesn't sound right. > One point of view says that the Residual Count field and the O and U > bits appear to be strictly iSCSI values that are derived by the > iSCSI target layer from the ExpectedDataTransferLength field of the > SCSI Command PDU and the DataSegmentLength fields of the DataIn or > DataOut PDUs sent as part of this command. Therefore ,the iSCSI > target always computes a Residual Count value without regard to the > Status and/or Response fields, since these are SCSI values. > > The other point of view says that the Residual Count field, and the > O and U bits, need only be set when the Status and Response fields > indicate that the command was completed at the target with a GOOD > Status, and the target does not have to compute or set the Residual > Count field and the O or U bits for other values of the Status and/or > Response fields. > > Which is it? In any case, could this be clarified somewhere in the > standard, most likely in section 9.4.4. Shortly, both. Residuals are sometimes set also by the low-level device drivers, this should be reported by the target. The target can add a residual of its own. If the device controller doesn't support clustering of requests, then the data to be transferred is limited by the maximum scatter-gather table times the sector size. Then the residual added to any future residual (say by the LLDD or the controller or the device server) is request_size-max_sg*sector_size. This should be reported by the target to the initiator. As to WRITE, you could use 9.4.6.2 Sense Data. You cannot start SCSI WRITE for 10 bytes when you have 8 bytes. Regarding response code, I wouldn't presume that a block OS layer (or OS SCSI layer) would use residual counts when SCSI service response is SERVICE DELIVERY or TARGET FAILURE, since SAM-3 specifies that ``All output parameters are invalid.'' CHECK CONDITION status code is also not a good candidate, since nothing in the sense codes table specifies that residual counts should be valid or looked up. It would seem appropriate to set residual counts only when the command completed or partially so. The status codes for this condition are unambiguous. The initiator shouldn't be too smart with residual counts and try to retransmit, or it would lock up OS's ULP. > 2. The last paragraph of section 2.2.3 says: > > "Before the Full Feature Phase is established, only Login Request and > Login Response PDUs are allowed. Any other PDU, when received at ini- > tiator or target, is a protocol error and MUST result in the connec- > tion being terminated. ..." > > The question is the following: is this rule literally true for the > target (i.e., can the target disconnect as soon as it receives a > non-Login PDU from the initiator) or does the target have to first > send a Login Response with Login reject PDU before disconnecting, as > it does for all other errors detected by the target during Login > Phase (according to section 4.3.1)? > > A related question is: does the target take the same action when > the very first PDU it receives on a new TCP connection is not a > Login Request PDU? For security/bandwidth/DOSA reasons the target should immediately close the connection. No explanation is due for non-complient initiators since the target cannot establish if they are initiators in the first case (port scanners, security breakers, etc.). That is, before FFP, the target should be ``trigger-happy'' to close the connection. In FFP, it depends on the Recovery Level. > 3. Section 4.2 says: > > "All keys in Chapter 11, except for the X- extension format, MUST be > supported by iSCSI initiators and targets and MUST NOT be answered with > NotUnderstood." > > Two questions arose with this statement: > > 1. Shouldn't it say "All keys in Chapter 11 and Appendix A, ..." in order > to include the Marker keys within the scope of this rule? > > 2. Does this literally mean that targets have to support initiator-only > keys (and initiators support target-only keys)? > For example, suppose a target sends an InitiatorAlias key, which is > supposed to be sent only by Initiators. Does the target have to > make an extra check to recognize that this is a "key in Chapter 11" > that is used incorrectly, (so that it does not respond with > NotUnderstood) or can it just treat it like it would any other key > it cannot handle, for example, X-InitiatorAlias, and respond with > NotUnderstood? In login phase, I personally close the connection. (period) This somehow simplifies the logic (or frees up more space for other login related logic) and makes the target more secure. > This last question is actually a special case of a more general > question, and that is: "How much checking does a receiver have to > do?" just to generate a "proper error response"? > Section 9 explicitly says that "Any compliant receiver MUST ignore > any bit not defined and all reserved fields unless specified > otherwise." This simply means that a receiver should _only_ check the relevant information in a complient PDU format. I.e. if a reserved bit is not 0 as it should be, it's better neglected rather than the connection compromized. It shouldn't be generalized, for security reasons. > 4. This is not a question but rather an observation for implementers. > > Not setting the I bit in a NOP-Out ping request can lead to unusual > situations. Consider the situation where a session has multiple > connections and the initiator periodically sends NOP-Out ping > requests on each connection just to ensure that the target is > still alive. If these NOP-Out requests are not immediate, and > one of them gets lost (due to a bad checksum, or because that > connection really is no longer alive), then none of the following > NOP-Out requests on the other connections can be processed by the > target, because that would be processing them out of CmdSN order, > and as a result it would appear to the initiator that all > connections are bad instead of just one! > > It appears that similar situations may arise when Task Management > Function commands are sent without setting the I bit -- the target > would be prevented from processing any of them that follow a > command that is lost. Right! Perfect analysis which shows that request Nop-Outs should have I=1. The logic for TMF requests is as follows: TMF req. always carry I=1. This basically means that all recovery and action that could have been taken at the initiator was actually taken and we want immediate assistance/action by the target. That is, TMF requests should be attempted at the Initiator first, and if not successful or the nature of the task can only be performed at the Target, then a TMF request should be sent with I=1. This also solves other problems... -- Luben From owner-ips@ece.cmu.edu Wed Jul 31 05:58:02 2002 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA19341 for ; Wed, 31 Jul 2002 05:58:02 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id g6V9EpH01782 for ips-outgoing; Wed, 31 Jul 2002 05:14:51 -0400 (EDT) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from fep01-mail.bloor.is.net.cable.rogers.com (fep01-mail.bloor.is.net.cable.rogers.com [66.185.86.71]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id g6V9Eoo01778 for ; Wed, 31 Jul 2002 05:14:50 -0400 (EDT) Received: from splentec.com ([24.43.238.147]) by fep01-mail.bloor.is.net.cable.rogers.com (InterMail vM.5.01.05.06 201-253-122-126-106-20020509) with ESMTP id <20020731091440.VIQF4814.fep01-mail.bloor.is.net.cable.rogers.com@splentec.com> for ; Wed, 31 Jul 2002 05:14:40 -0400 Message-ID: <3D47AA84.ACB99EC9@splentec.com> Date: Wed, 31 Jul 2002 05:14:44 -0400 From: Luben Tuikov Organization: Splentec Ltd. X-Mailer: Mozilla 4.79 [en] (X11; U; Linux 2.4.19-rc3 i686) X-Accept-Language: en MIME-Version: 1.0 To: iSCSI Subject: Re: An error message from iscsi target References: <004c01c23854$c5980d80$fe232fd1@corona> <3D47A83B.B352815C@splentec.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Authentication-Info: Submitted using SMTP AUTH PLAIN at fep01-mail.bloor.is.net.cable.rogers.com from [24.43.238.147] using ID at Wed, 31 Jul 2002 05:14:40 -0400 Sender: owner-ips@ece.cmu.edu Precedence: bulk Content-Transfer-Encoding: 7bit Luben Tuikov wrote: > > > James Lee wrote: > > > [cut] > > Mar 23 01:08:28 kernel: iSCSI:Send thread for connection 0 started. > > Mar 23 01:08:28 kernel: iSCSI:Receive thread for connection 0 started. > > Mar 23 01:08:45 kernel: iSCSI:Send thread for connection 0 started. > > Mar 23 01:08:45 kernel: iSCSI:Receive thread for connection 0 started. > > Mar 23 01:09:04 kernel: iSCSI:Send thread for connection 0 started. > > Mar 23 01:09:04 kernel: iSCSI:Receive thread for connection 0 started. > > Here I'd assume that you connected to two separate disks, right? > If not, then the problem starts here. > > > Mar 23 01:24:16 kernel: iSCSI:atomic_count != 0 <======================= HERE > > Yep, this is a problem and if you can reproduce this (very importand to be > able to do so), then I'd be glad to see how. Spelling: ``important''. Doh -- I need some sleep. > Once you get this, a kernel panic is imminent sooner or later. I.e. you better reboot as soon as you see this. Did you fix the scsi hosts same number problem? You should eliminate those first before pointing the finger at the target implementation. If indeed this is the target implementation and you and I can separately reproduce this, then I'd be really curious to see how this happens. I cannot imagine where or how... Try to reproduce this with 1, then with 2 then with 3 hosts, etc. Will check it tomorrow, er, later today. -- Luben Tuikov, Senior Software Engineer, Splentec Ltd. Bus: +1-905-707-1954x112, 9-5 EST. Fax: +1-905-707-1974. From owner-ips@ece.cmu.edu Wed Jul 31 10:16:45 2002 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA28617 for ; Wed, 31 Jul 2002 10:16:45 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id g6VDaNb29351 for ips-outgoing; Wed, 31 Jul 2002 09:36:23 -0400 (EDT) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from cygnus.equallogic.com (cygnus.equallogic.com [65.170.102.10]) by ece.cmu.edu (8.11.0/8.10.2) with SMTP id g6VDaMo29344 for ; Wed, 31 Jul 2002 09:36:22 -0400 (EDT) Received: from cygnus.equallogic.com (localhost.localdomain [127.0.0.1]) by cygnus.equallogic.com (8.11.6/8.11.6) with ESMTP id g6VDaGe27042 for ; Wed, 31 Jul 2002 09:36:16 -0400 Received: from deneb.dev.equallogic.com (deneb.dev.equallogic.com [172.16.1.99]) by cygnus.equallogic.com (8.11.6/8.11.6) with ESMTP id g6VDaFw27030; Wed, 31 Jul 2002 09:36:15 -0400 Received: from pkoning.dev.equallogic.com.equallogic.com (localhost.localdomain [127.0.0.1]) by deneb.dev.equallogic.com (8.11.6/8.11.6) with SMTP id g6VDaFh32307; Wed, 31 Jul 2002 09:36:15 -0400 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <15687.59343.81747.191860@pkoning.dev.equallogic.com> Date: Wed, 31 Jul 2002 09:36:15 -0400 From: Paul Koning To: rdr@io.iol.unh.edu Cc: Julian_Satran@il.ibm.com, ips@ece.cmu.edu Subject: Re: iSCSI: plugfest4 issues References: X-Mailer: VM 7.01 under 21.1 (patch 11) "Carlsbad Caverns" XEmacs Lucid Sender: owner-ips@ece.cmu.edu Precedence: bulk Content-Transfer-Encoding: 7bit >>>>> "Robert" == Robert D Russell writes: Robert> Julian: Robert> Four issues came up today at the iSCSI plugfest: Robert> ...2. The last paragraph of section 2.2.3 says: Robert> "Before the Full Feature Phase is established, only Login Robert> Request and Login Response PDUs are allowed. Any other PDU, Robert> when received at ini- tiator or target, is a protocol error Robert> and MUST result in the connec- tion being terminated. ..." Robert> The question is the following: is this rule literally true Robert> for the target (i.e., can the target disconnect as soon as it Robert> receives a non-Login PDU from the initiator) or does the Robert> target have to first send a Login Response with Login reject Robert> PDU before disconnecting, as it does for all other errors Robert> detected by the target during Login Phase (according to Robert> section 4.3.1)? Robert> A related question is: does the target take the same action Robert> when the very first PDU it receives on a new TCP connection Robert> is not a Login Request PDU? I like Luben's argument that a summary disconnect with no messages is a good solution. Apart from the security argument, I don't like spending lots of effort coding up extra error paths that are only used when the other side commits a gross protocol error. Robert> 3. Section 4.2 says: Robert> "All keys in Chapter 11, except for the X- extension format, Robert> MUST be supported by iSCSI initiators and targets and MUST Robert> NOT be answered with NotUnderstood." Robert> Two questions arose with this statement: Robert> 1. Shouldn't it say "All keys in Chapter 11 and Appendix A, Robert> ..." in order to include the Marker keys within the scope of Robert> this rule? Robert> 2. Does this literally mean that targets have to support Robert> initiator-only keys (and initiators support target-only Robert> keys)? For example, suppose a target sends an InitiatorAlias Robert> key, which is supposed to be sent only by Initiators. Does Robert> the target have to make an extra check to recognize that this Robert> is a "key in Chapter 11" that is used incorrectly, (so that Robert> it does not respond with NotUnderstood) or can it just treat Robert> it like it would any other key it cannot handle, for example, Robert> X-InitiatorAlias, and respond with NotUnderstood? Similar reasoning as above: such an event is a protocol error. "NotUnderstood" seems like a good response. Disconnecting is also fine in my view. paul From owner-ips@ece.cmu.edu Wed Jul 31 11:11:14 2002 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA01506 for ; Wed, 31 Jul 2002 11:11:14 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id g6VEVtb03177 for ips-outgoing; Wed, 31 Jul 2002 10:31:55 -0400 (EDT) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from mail.brocade.com (sj6-b.brocade.com [63.121.140.220]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id g6VEVro03171 for ; Wed, 31 Jul 2002 10:31:53 -0400 (EDT) Received: from hq-ex-c3.brocade.com (hq-ex-c3 [192.168.126.211]) by mail.brocade.com (8.8.8+Sun/8.8.8) with ESMTP id HAA10808; Wed, 31 Jul 2002 07:31:44 -0700 (PDT) Received: by hq-ex-c3.brocade.com with Internet Mail Service (5.5.2653.19) id ; Wed, 31 Jul 2002 07:32:52 -0700 Message-ID: From: Robert Snively To: "'Julian Satran'" , "Walczak, Kyle" Cc: ips@ece.cmu.edu Subject: RE: iSCSI reserved statement Date: Wed, 31 Jul 2002 07:31:05 -0700 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C2389E.E705F230" Sender: owner-ips@ece.cmu.edu Precedence: bulk This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_001_01C2389E.E705F230 Content-Type: text/plain Julian, Please state it only in one place, then use the defined keyword in all other places. Otherwise, multiple definitions of reserved may creep in. Bob -----Original Message----- From: Julian Satran [mailto:Julian_Satran@il.ibm.com] Sent: Monday, July 29, 2002 5:30 PM To: Walczak, Kyle Cc: ips@ece.cmu.edu Subject: Re: iSCSI reserved statement OK - It is anyhow stated also in several other places. Julo "Walczak, Kyle" 07/29/2002 06:50 PM To: Julian Satran/Haifa/IBM@IBMIL cc: Subject: iSCSI reserved statement Julian: I was looking at section 2nd para of section 9 which states; "Any compliant sender MUST set all bits not defined and all reserved fields to zero unless specified otherwise. Any compliant receiver MUST ignore any bit not defined and all reserved fields unless specified otherwise." The SCP-2 defines "reserved" as "A keyword referring to bits, bytes, words, fields and code values that are set aside for future standardization. A reserved bit, byte, word or filed shall be set to zero, or in accordance with a future extension to this standard. Recipents are not required to check reserved bits, bytes, words or fileds for zero values. Receipt of reserved code values in defined fields shall be reported as error." I would like to add the third line of the above statement to the first paragraph, such that it states: "Any compliant sender MUST set all bits not defined and all reserved fields to zero unless specified otherwise. Any compliant receiver MUST ignore any bit not defined and all reserved fields unless specified otherwise." Receipt of reserved code values in defined fields shall be reported as error." For example, if the Additional Header Segment (AHS), the AHSType, AHS code was set to 0, 3-59 would report an error ( 0x09 Reason code in the Reject PDU, Invalid PDU field). Thanks Kyle Walczak (281) 514-3258 ------_=_NextPart_001_01C2389E.E705F230 Content-Type: text/html
Julian,
 
Please state it only in one place, then use the defined keyword in
all other places.  Otherwise, multiple definitions of reserved may creep in.
 
Bob
-----Original Message-----
From: Julian Satran [mailto:Julian_Satran@il.ibm.com]
Sent: Monday, July 29, 2002 5:30 PM
To: Walczak, Kyle
Cc: ips@ece.cmu.edu
Subject: Re: iSCSI reserved statement


OK - It is anyhow stated also in several other places. Julo


"Walczak, Kyle" <Kyle.Walczak@hp.com>

07/29/2002 06:50 PM

       
        To:        Julian Satran/Haifa/IBM@IBMIL
        cc:        
        Subject:        iSCSI reserved statement

       


Julian:


I was looking at section 2nd para of section 9 which states;

"Any compliant sender MUST set all bits not defined and all reserved
fields to zero unless specified otherwise. Any compliant receiver
MUST ignore any bit not defined and all reserved fields unless specified
otherwise."

The SCP-2 defines "reserved" as
"A keyword referring to bits, bytes, words, fields and code values that are set aside for future standardization. A reserved bit, byte, word or filed shall be set to zero, or in accordance with a future extension to this standard. Recipents are not required to check reserved bits, bytes, words or fileds for zero values. Receipt of reserved code values in defined fields shall be reported as error."

I would like to add the third line of the above statement to the first paragraph, such that it states:
"Any compliant sender MUST set all bits not defined and all reserved
fields to zero unless specified otherwise. Any compliant receiver
MUST ignore any bit not defined and all reserved fields unless specified
otherwise." Receipt of reserved code values in defined fields shall be reported as error."


For example, if the Additional Header Segment (AHS), the AHSType, AHS code
was set to 0, 3-59 would report an error ( 0x09 Reason code in the Reject PDU, Invalid PDU field).


Thanks
Kyle Walczak
(281) 514-3258



------_=_NextPart_001_01C2389E.E705F230-- From owner-ips@ece.cmu.edu Wed Jul 31 11:52:13 2002 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA03888 for ; Wed, 31 Jul 2002 11:52:13 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id g6VF9uS05889 for ips-outgoing; Wed, 31 Jul 2002 11:09:56 -0400 (EDT) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from mail.wrs.com (unknown-1-11.windriver.com [147.11.1.11]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id g6VF9so05884 for ; Wed, 31 Jul 2002 11:09:54 -0400 (EDT) Received: from london ([147.11.233.20]) by mail.wrs.com (8.9.3/8.9.1) with SMTP id IAA19921; Wed, 31 Jul 2002 08:09:32 -0700 (PDT) From: "Rod Harrison" To: "Robert D. Russell" , "Julian Satran" , Subject: RE: iSCSI: plugfest4 issues Date: Wed, 31 Jul 2002 10:10:47 -0500 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0) In-Reply-To: X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2314.1300 importance: Normal Sender: owner-ips@ece.cmu.edu Precedence: bulk Content-Transfer-Encoding: 7bit With a tape in variable block mode a GOOD SCSI status and short read, i.e. underflow is possible. Similarly with mode sense, or inquiry etc., and a buffer that is too small there would be GOOD status and an overflow indication. So the target does need to set the resid count and bits when there is GOOD status. - Rod --- >8 --- [snip ] 1. A question about whether or not the Residual Count field and the appropriate O and U bits need to be computed on all SCSI Response PDUs, regardless of the values in the Status and/or Response fields. One point of view says that the Residual Count field and the O and U bits appear to be strictly iSCSI values that are derived by the iSCSI target layer from the ExpectedDataTransferLength field of the SCSI Command PDU and the DataSegmentLength fields of the DataIn or DataOut PDUs sent as part of this command. Therefore ,the iSCSI target always computes a Residual Count value without regard to the Status and/or Response fields, since these are SCSI values. The other point of view says that the Residual Count field, and the O and U bits, need only be set when the Status and Response fields indicate that the command was completed at the target with a GOOD Status, and the target does not have to compute or set the Residual Count field and the O or U bits for other values of the Status and/or Response fields. Which is it? In any case, could this be clarified somewhere in the standard, most likely in section 9.4.4. [snip] From owner-ips@ece.cmu.edu Wed Jul 31 13:17:00 2002 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA08228 for ; Wed, 31 Jul 2002 13:17:00 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id g6VGimn13279 for ips-outgoing; Wed, 31 Jul 2002 12:44:48 -0400 (EDT) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from mail.ivivity.com ([64.238.111.99]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id g6VGiWo13246 for ; Wed, 31 Jul 2002 12:44:32 -0400 (EDT) Received: by ATLOPS with Internet Mail Service (5.5.2653.19) id ; Wed, 31 Jul 2002 12:44:30 -0400 Message-ID: From: Eddy Quicksall To: "'Praveen madhavan'" , ips@ece.cmu.edu Subject: RE: Invalid Pdus received during Login phase Date: Wed, 31 Jul 2002 12:44:29 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-ips@ece.cmu.edu Precedence: bulk IMHO if the target gets anything before the initial login request, it should just drop the connection without any reply. I have two reasons for saying this: 1) The "initiator" may not even be iSCSI ... if it was, it would do a login. You should not respond because it may be a hacker trying to figure things out and you don't want to give him any clues. Also, if it is not an iSCSI initiator, you would be sending "garbage" and who know what the client will do next. 2) More importantly, some hardware implementations may not be able to even send anything at all without a session and you can't get a session until you get the initial login request. So, the spec should not mandate a response and leave that up to the implementer. Eddy -----Original Message----- From: Praveen madhavan [mailto:praveenm@nettaxi.com] Sent: Tuesday, July 30, 2002 7:38 AM To: ips@ece.cmu.edu Subject: Invalid Pdus received during Login phase Hi, I would like to know the behavior of Target, when it receives invalid Pdu's during login phase. Will target generates login response with Error of status detail -"Invalid during login" and terminates the connections. Or Reject command with reason code- "Protocol Error/Invalid PDU". If Invalid Pdus are received by Target, even before login phase ( I mean just before first login request from initiator), i think target can't send login response for it since it was not aware of ISID. In such senario how will target react ? regards Praveen.M ------------------------------------------------------------ NEW - FREE Nettaxi 56kbs Dial-up INTERNET ACCESS with NO ADS or Ad Bars! http://www.nettaxi.com/isp/ From owner-ips@ece.cmu.edu Wed Jul 31 17:19:42 2002 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA18510 for ; Wed, 31 Jul 2002 17:19:37 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id g6VKYsn00321 for ips-outgoing; Wed, 31 Jul 2002 16:34:54 -0400 (EDT) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from fep01-mail.bloor.is.net.cable.rogers.com (fep01-mail.bloor.is.net.cable.rogers.com [66.185.86.71]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id g6VKYpo00316 for ; Wed, 31 Jul 2002 16:34:51 -0400 (EDT) Received: from splentec.com ([24.43.238.147]) by fep01-mail.bloor.is.net.cable.rogers.com (InterMail vM.5.01.05.06 201-253-122-126-106-20020509) with ESMTP id <20020731203441.KAHU4814.fep01-mail.bloor.is.net.cable.rogers.com@splentec.com> for ; Wed, 31 Jul 2002 16:34:41 -0400 Message-ID: <3D4849DB.E6BDDD67@splentec.com> Date: Wed, 31 Jul 2002 16:34:35 -0400 From: Luben Tuikov Organization: Splentec Ltd. X-Mailer: Mozilla 4.79 [en] (X11; U; Linux 2.4.19-rc3 i686) X-Accept-Language: en MIME-Version: 1.0 To: iSCSI Subject: Re: An error message from iscsi target References: <004c01c23854$c5980d80$fe232fd1@corona> <3D47A83B.B352815C@splentec.com> <3D47AA84.ACB99EC9@splentec.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Authentication-Info: Submitted using SMTP AUTH PLAIN at fep01-mail.bloor.is.net.cable.rogers.com from [24.43.238.147] using ID at Wed, 31 Jul 2002 16:34:40 -0400 Sender: owner-ips@ece.cmu.edu Precedence: bulk Content-Transfer-Encoding: 7bit To those of you who couldn't recognize that I emailed this to IPS _by__mistake_ at 5 in the morning and who couldn't just ignore it and move on (as is my experience with other mailing lists), but had to email me personally asking for explanation: IGNORE THIS MESSAGE, it was emailed to ips by mistake at 5 in the morning when I was _extremely_ tired. Luben Tuikov wrote: > > Luben Tuikov wrote: > > > > > James Lee wrote: > > > > > [cut] > > > Mar 23 01:08:28 kernel: iSCSI:Send thread for connection 0 started. > > > Mar 23 01:08:28 kernel: iSCSI:Receive thread for connection 0 started. > > > Mar 23 01:08:45 kernel: iSCSI:Send thread for connection 0 started. > > > Mar 23 01:08:45 kernel: iSCSI:Receive thread for connection 0 started. > > > Mar 23 01:09:04 kernel: iSCSI:Send thread for connection 0 started. > > > Mar 23 01:09:04 kernel: iSCSI:Receive thread for connection 0 started. > > > > Here I'd assume that you connected to two separate disks, right? > > If not, then the problem starts here. > > > > > Mar 23 01:24:16 kernel: iSCSI:atomic_count != 0 <======================= HERE > > > > Yep, this is a problem and if you can reproduce this (very importand to be > > able to do so), then I'd be glad to see how. > > Spelling: ``important''. Doh -- I need some sleep. > > > Once you get this, a kernel panic is imminent sooner or later. > > I.e. you better reboot as soon as you see this. > > Did you fix the scsi hosts same number problem? > > You should eliminate those first before pointing the finger > at the target implementation. > > If indeed this is the target implementation and you and I > can separately reproduce this, then I'd be really curious > to see how this happens. I cannot imagine where or how... > > Try to reproduce this with 1, then with 2 then with 3 hosts, > etc. > > Will check it tomorrow, er, later today. > From owner-ips@ece.cmu.edu Wed Jul 31 17:22:46 2002 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA18672 for ; Wed, 31 Jul 2002 17:22:46 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id g6VL6IT02683 for ips-outgoing; Wed, 31 Jul 2002 17:06:18 -0400 (EDT) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from msgbas1.cos.agilent.com (msgbas1x.cos.agilent.com [192.25.240.36]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id g6VL6Go02679 for ; Wed, 31 Jul 2002 17:06:16 -0400 (EDT) Received: from msgrel1t.cos.agilent.com (msgrel1t.cos.agilent.com [130.29.152.157]) by msgbas1.cos.agilent.com (Postfix) with ESMTP id F2B89B915; Wed, 31 Jul 2002 15:06:15 -0600 (MDT) Received: from axcsbh3.cos.agilent.com (axcsbh3.cos.agilent.com [130.29.152.190]) by msgrel1t.cos.agilent.com (Postfix) with SMTP id C612A55A; Wed, 31 Jul 2002 15:06:15 -0600 (MDT) Received: from 130.29.152.190 by axcsbh3.cos.agilent.com (InterScan E-Mail VirusWall NT); Wed, 31 Jul 2002 15:06:15 -0600 Received: by axcsbh3.cos.agilent.com with Internet Mail Service (5.5.2653.19) id ; Wed, 31 Jul 2002 15:06:15 -0600 Message-ID: <1BEBA5E8600DD4119A50009027AF54A00D373C55@axcs04.cos.agilent.com> From: pat_thaler@agilent.com To: Black_David@emc.com, ips@ece.cmu.edu Subject: RE: iSCSI - working draft and IANA Date: Wed, 31 Jul 2002 15:06:14 -0600 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-ips@ece.cmu.edu Precedence: bulk RE: "We may also want to reserve/restrict the use of underscore ('_') to continue the convention that for AuthMethod , the keys that negotiate its parameters are named _* ." We don't need to restrict '_' as long as use values of that don't begin with X, Y or Z. Pat -----Original Message----- From: Black_David@emc.com [mailto:Black_David@emc.com] Sent: Tuesday, July 30, 2002 2:45 PM To: ips@ece.cmu.edu Subject: RE: iSCSI - working draft and IANA Several comments on this topic: - The IANA text in the working draft is going to need some expansion. IANA will want explicit instructions on how to manage the registries, as IANA does *not* have a single or default set of procedures for this purpose and hence needs instructions on what is to be done. See RFC 2434. - The rationale for the X/Y/Z prefixes is to avoid losing key and value names to vendor registration that we might like to use in the future - future RFCs would be able to define new key and value names without problems, because we wouldn't us those prefixes. The # prefix ensures that registered and unregistered vendor-specified names can't conflict. Both of these are important (e.g., the X- format for vendor-specific keys is not going away at this stage). If the # character is objectionable, a possible alternative is that registered values MUST NOT contain a period ('.') and unregistered values MUST contain a period ('.') between the first and second components of the reversed domain name. We may also want to reserve/restrict the use of underscore ('_') to continue the convention that for AuthMethod , the keys that negotiate its parameters are named _* . - The reason for creating a registry for existing keys is that it would provide a single point of reference in the future as new keys get added to iSCSI. Right now this doesn't matter, but down the road, after a few RFCs add several new keys, having one place to look could be quite convenient. A number of things have been put into IANA registries after the fact as it was subsequently discovered that such a registry would be useful (e.g., the IP protocol number [IPv4/IPv6] is in such a registry). I may need to volunteer to help with the IANA text - it doesn't have to be perfect to Last Call the draft as long as for each registry, two things are clear: - The criteria for registration - the things that someone who wants to register something has to present to IANA. - How IANA handles registration requests, including reasons for rejection and requirements for review. I'm not sure about Mark Bakke's suggestion to number newly registered authentication/digest algorithms for MIB usage vs. having the MIB use the strings. In practice, the string is what names these algorithms, so using numbers seems to create an additional opportunity to get the algorithm (string) to number mapping wrong. 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 --------------------------------------------------- From owner-ips@ece.cmu.edu Wed Jul 31 19:28:33 2002 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA21670 for ; Wed, 31 Jul 2002 19:28:33 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id g6VMkuk09424 for ips-outgoing; Wed, 31 Jul 2002 18:46:56 -0400 (EDT) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from mailhub.lss.emc.com (xdch.emc.com [168.159.1.79]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id g6VMkso09419 for ; Wed, 31 Jul 2002 18:46:54 -0400 (EDT) Received: from emc.com (emcmail.lss.emc.com [168.159.48.78]) by mailhub.lss.emc.com (Switch-2.2.0/Switch-2.2.0) with ESMTP id g6VMkk326352; Wed, 31 Jul 2002 18:46:46 -0400 (EDT) Received: from mxic1.isus.emc.com ([168.159.129.100]) by emc.com (8.10.1/8.10.1) with ESMTP id g6VMkj720383; Wed, 31 Jul 2002 18:46:45 -0400 (EDT) Received: by MXIC1 with Internet Mail Service (5.5.2653.19) id ; Wed, 31 Jul 2002 18:46:45 -0400 Message-ID: <277DD60FB639D511AC0400B0D068B71E0564C14D@CORPMX14> From: Black_David@emc.com To: pat_thaler@agilent.com, ips@ece.cmu.edu Subject: RE: iSCSI - working draft and IANA Date: Wed, 31 Jul 2002 18:46:41 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-ips@ece.cmu.edu Precedence: bulk Pat, Sorry if I wasn't clear. The rationale for reserving/restricting the underscore would be to allow whomever defines/registers the vendor-specific Gorilla (Z#Gorilla) AuthMethod to define/register keys like Gorilla_Banana (X#Gorilla_Banana) and Gorilla_Bar (X#Gorilla_Bar) if those are what naturally fit the Gorilla algorithm without having to worry about those keys having been previously defined/registered. You're correct that there would not be an issue if Gorilla were to be standardized and added to iSCSI, as the unadorned Gorilla_* keys would be available to the WG to do this, but my concern was for vendor-specific keys needed by vendor-specific AuthMethod's. 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 --------------------------------------------------- > -----Original Message----- > From: pat_thaler@agilent.com [mailto:pat_thaler@agilent.com] > Sent: Wednesday, July 31, 2002 5:06 PM > To: Black_David@emc.com; ips@ece.cmu.edu > Subject: RE: iSCSI - working draft and IANA > > > RE: "We may also want to reserve/restrict the use of underscore > ('_') to continue the convention that for AuthMethod , > the keys that negotiate its parameters are named _* ." > > We don't need to restrict '_' as long as use values of that > don't begin with X, Y or Z. > > Pat > > -----Original Message----- > From: Black_David@emc.com [mailto:Black_David@emc.com] > Sent: Tuesday, July 30, 2002 2:45 PM > To: ips@ece.cmu.edu > Subject: RE: iSCSI - working draft and IANA > > > Several comments on this topic: > > - The IANA text in the working draft is going to need some > expansion. IANA will want explicit instructions on how > to manage the registries, as IANA does *not* have > a single or default set of procedures for this purpose > and hence needs instructions on what is to be done. > See RFC 2434. > > - The rationale for the X/Y/Z prefixes is to avoid losing key > and value names to vendor registration that we might like > to use in the future - future RFCs would be able to define > new key and value names without problems, because we wouldn't > us those prefixes. The # prefix ensures that registered > and unregistered vendor-specified names can't conflict. > Both of these are important (e.g., the X- format for > vendor-specific keys is not going away at this stage). > If the # character is objectionable, a possible alternative > is that registered values MUST NOT contain a period ('.') > and unregistered values MUST contain a period ('.') between > the first and second components of the reversed domain name. > We may also want to reserve/restrict the use of underscore > ('_') to continue the convention that for AuthMethod , > the keys that negotiate its parameters are named _* . > > - The reason for creating a registry for existing keys is that > it would provide a single point of reference in the future as > new keys get added to iSCSI. Right now this doesn't matter, but > down the road, after a few RFCs add several new keys, having one > place to look could be quite convenient. A number of things > have been put into IANA registries after the fact as it was > subsequently discovered that such a registry would be useful > (e.g., the IP protocol number [IPv4/IPv6] is in such a > registry). > > I may need to volunteer to help with the IANA text - it doesn't > have to be perfect to Last Call the draft as long as for each > registry, two things are clear: > > - The criteria for registration - the things that someone who > wants to register something has to present to IANA. > - How IANA handles registration requests, including reasons for > rejection and requirements for review. > > I'm not sure about Mark Bakke's suggestion to number newly registered > authentication/digest algorithms for MIB usage vs. having the MIB use > the strings. In practice, the string is what names these algorithms, > so using numbers seems to create an additional opportunity to get the > algorithm (string) to number mapping wrong. > > 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 > --------------------------------------------------- > From owner-ips@ece.cmu.edu Wed Jul 31 19:35:59 2002 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA21795 for ; Wed, 31 Jul 2002 19:35:59 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id g6VNLa111667 for ips-outgoing; Wed, 31 Jul 2002 19:21:36 -0400 (EDT) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from d12lmsgate.de.ibm.com (d12lmsgate.de.ibm.com [195.212.91.199]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id g6VNLYo11661; Wed, 31 Jul 2002 19:21:34 -0400 (EDT) Received: from d12relay02.de.ibm.com (d12relay02.de.ibm.com [9.165.215.23]) by d12lmsgate.de.ibm.com (8.12.3/8.12.3) with ESMTP id g6VNLEub069612; Thu, 1 Aug 2002 01:21:14 +0200 Received: from d10hubm1.telaviv.ibm.com (d10ml001.telaviv.ibm.com [9.148.216.55]) by d12relay02.de.ibm.com (8.12.3/NCO/VER6.3) with ESMTP id g6VNLEwC079082; Thu, 1 Aug 2002 01:21:14 +0200 To: Mark Bakke Cc: ips@ece.cmu.edu, owner-ips@ece.cmu.edu, Steve Senum MIME-Version: 1.0 Subject: Re: iSCSI - working draft and IANA X-Mailer: Lotus Notes Release 5.0.9 November 16, 2001 From: "Julian Satran" Message-ID: Date: Thu, 1 Aug 2002 02:21:10 +0300 X-MIMETrack: Serialize by Router on D10ML001/10/M/IBM(Release 5.0.9a |January 7, 2002) at 01/08/2002 02:21:13, Serialize complete at 01/08/2002 02:21:13 Content-Type: multipart/alternative; boundary="=_alternative 007E63F8C2256C07_=" Sender: owner-ips@ece.cmu.edu Precedence: bulk This is a multipart message in MIME format. --=_alternative 007E63F8C2256C07_= Content-Type: text/plain; charset="us-ascii" I agree - Julo Mark Bakke Sent by: owner-ips@ece.cmu.edu 07/30/2002 08:52 PM To: Julian Satran/Haifa/IBM@IBMIL cc: Steve Senum , ips@ece.cmu.edu Subject: Re: iSCSI - working draft and IANA Julian- I'm not sure I see the need for registering keys, but that aside, if we register digest and auth methods I would suggest that we also register an integer method number with each; this will make it easier to add them to the MIBs. I would also suggest that we register the current ones as well as any extensions. -- Mark Julian Satran wrote: > > Registering the current keys is an issue already raised by Mallikarjun. The only think I can > comment about is that I don't see what we stand to gain (and I can cleraly see the pain!). > > As for the prefixes - they are aimed at clearly delineating what is mandatory (key defined in the > basic iSCSI doc) from vendor or group=of-vendors additions. > > The registration is meant to allow groups of vendors to agree on a key and provide a semantic doc > (an RFC that can be informational). > > Julo > > Steve Senum > To: Julian Satran/Haifa/IBM@IBMIL > 07/30/2002 01:48 AM cc: ips@ece.cmu.edu > Subject: Re: iSCSI - working draft and IANA > > > > Julian, > > 1. I would suggest registering all the current iSCSI keys, auth methods, > and digests with the IANA, with references to the iSCSI RFC (when published), > and dropping the X#, Y#, and Z# prefixes. This would be more consistent > with how I have seen this done in the past. > > 2. I am not sure I really see the need. In other cases, this is done > to allow vendor specific registrations, but we already have a mechanism > for that (the X- prefix). Note that there is no reason why a vendor > can't defined a vendor specific key in an informational RFC. > > Regards, > Steve Senum > > Julian Satran wrote: > > > > Dear colleagues, > > > > The current (today's) version of the draft has a revised IANA consideration > > section > > and specific indication on how to build keys, authentication methods and > > digests. > > > > David Black suggested that we might want to go for 3 different registries > > maintained by IANA for iSCSI > > and I liked the idea. > > > > Please comment, > > Julo -- Mark A. Bakke Cisco Systems mbakke@cisco.com 763.398.1054 --=_alternative 007E63F8C2256C07_= Content-Type: text/html; charset="us-ascii"
I agree - Julo


Mark Bakke <mbakke@cisco.com>
Sent by: owner-ips@ece.cmu.edu

07/30/2002 08:52 PM

       
        To:        Julian Satran/Haifa/IBM@IBMIL
        cc:        Steve Senum <ssenum@cisco.com>, ips@ece.cmu.edu
        Subject:        Re: iSCSI - working draft and IANA

       


Julian-

I'm not sure I see the need for registering keys, but that
aside, if we register digest and auth methods I would suggest
that we also register an integer method number with each; this
will make it easier to add them to the MIBs.  I would also
suggest that we register the current ones as well as any
extensions.

--
Mark

Julian Satran wrote:
>
> Registering the current keys is an issue already raised by Mallikarjun. The only think I can
> comment about is that I don't see what we stand to gain (and I can cleraly see the  pain!).
>
> As for the prefixes - they are aimed at clearly delineating what is mandatory (key defined in the
> basic iSCSI doc) from vendor or group=of-vendors additions.
>
> The registration is meant to allow groups of vendors to agree on a key and provide a semantic doc
> (an RFC that can be informational).
>
> Julo
>
>   Steve Senum <ssenum@cisco.com>
>                                            To:        Julian Satran/Haifa/IBM@IBMIL
>   07/30/2002 01:48 AM                      cc:        ips@ece.cmu.edu
>                                            Subject:        Re: iSCSI - working draft and IANA
>
>
>
> Julian,
>
> 1. I would suggest registering all the current iSCSI keys, auth methods,
> and digests with the IANA, with references to the iSCSI RFC (when published),
> and dropping the X#, Y#, and Z# prefixes.  This would be more consistent
> with how I have seen this done in the past.
>
> 2. I am not sure I really see the need.  In other cases, this is done
> to allow vendor specific registrations, but we already have a mechanism
> for that (the X- prefix).  Note that there is no reason why a vendor
> can't defined a vendor specific key in an informational RFC.
>
> Regards,
> Steve Senum
>
> Julian Satran wrote:
> >
> > Dear colleagues,
> >
> > The current (today's) version of the draft has a revised IANA consideration
> > section
> > and specific  indication on how to build keys, authentication methods and
> > digests.
> >
> > David Black suggested that we might want to go for 3 different registries
> > maintained by IANA for iSCSI
> > and I liked the idea.
> >
> > Please comment,
> > Julo

--
Mark A. Bakke
Cisco Systems
mbakke@cisco.com
763.398.1054

--=_alternative 007E63F8C2256C07_=-- From owner-ips@ece.cmu.edu Wed Jul 31 20:36:49 2002 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA22627 for ; Wed, 31 Jul 2002 20:36:49 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id g71046P14186 for ips-outgoing; Wed, 31 Jul 2002 20:04:06 -0400 (EDT) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from iol.unh.edu (io.iol.unh.edu [132.177.123.82]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id g6VNIEo11405 for ; Wed, 31 Jul 2002 19:18:14 -0400 (EDT) Received: from io.iol.unh.edu (localhost.localdomain [127.0.0.1]) by iol.unh.edu (8.12.3/8.12.3) with ESMTP id g6VNI86U027558; Wed, 31 Jul 2002 19:18:08 -0400 Received: from localhost (rdr@localhost) by io.iol.unh.edu (8.12.3/8.12.3/Submit) with ESMTP id g6VNI8gF027555; Wed, 31 Jul 2002 19:18:08 -0400 Date: Wed, 31 Jul 2002 19:18:08 -0400 (EDT) From: "Robert D. Russell" To: Julian Satran , Subject: Re: iSCSI: plugfest4 issues In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ips@ece.cmu.edu Precedence: bulk Julian: Five issues came up today, Wednesday, 31-July-2002, at the iSCSI plugfest. 1. We have hit a situation where a lot of people are not interoperating, and this has to do with the use of "Irrelevant" as a key response value. In section 4.2 the standard says only: "If a specific key is not relevant for the current negotiation, the responder may answer with the constant "Irrelevant" for all types of negotiation. ...". The problem is that nowhere in the standard is it further defined when a key is relevant and when it is not. It is left up to each individual implementation, and as a result, different implementers are coming to different conclusions in the same circumstances. Thus, they do not interoperate. A few implementations are simply saying that all keys are always relevant, and never accept "Irrelevant" as an answer in any situation. That is the extreme, but their argument is that it requires extra logic to decide when a key is relevant and when it is not, and hence it is simpler not to do this. More common are implementations that have simply not thought of all the possible situations in which a key has become irrelevant. We have a choice on how to proceed. The simplest alternative would be to eliminate "Irrelevant" as a response, since it is never necessary to use this in a response, yet it always requires extra logic on the receiving side to deal with it. An alternative if we decide to keep "Irrelevant" as a response is to have the standard specify as part of the definition of each key in Section 11 and Appendix A those situations in which that key may be considered irrelevant. This could be listed as an attribute "Irrelevant when:" immediately following the current "Scope:" attribute. This attribute is in addition to the integrity rules which already exist. The following is a list of all the keys that I am aware of that can accept a response of Irrelevant, and the situations in which this can legitimately occur (numbers indicate the section where the key is defined): 11.2 MaxConnections -- Irrelevant when: SessionType=Discovery 11.10 InitialR2T -- Irrelevant when: SessionType=Discovery 11.11 BidiInitialR2T -- Irrelevant when: SessionType=Discovery 11.12 ImmediateData -- Irrelevant when: SessionType=Discovery 11.10 MaxBurstLength -- Irrelevant when: SessionType=Discovery 11.10 FirstBurstLength -- Irrelevant when: SessionType=Discovery -- also irrelevant when ( InitialR2T=Yes and ImmediateData=No ) 11.18 MaxOutstandingR2T -- Irrelevant when: SessionType=Discovery 11.19 DataPDUInOrder -- Irrelevant when: SessionType=Discovery 11.20 DataSequenceInOrder -- Irrelevant when: SessionType=Discovery A.3.2 OFMarkInt -- Irrelevant when: OFMarker=No IFMarkInt -- Irrelevant when: IFMarker=No 2. Section 2.2.2.1 states: "Commands meant for immediate delivery are marked with an immediate delivery flag; they also carry CmdSN. CmdSN does not advance for commands marked for immediate delivery." and 2 paragraphs later in the same section: "If immediate delivery is used with task management commands, these commands may reach the target before the tasks on which they are sup- posed to act. For this reason the task management command MUST carry the current CmdSN as a marker of their position in the stream of com- mands." Given the first statement quoted above, why is this last sentence needed? It is causing some confusion because it makes it sound as if the task management command is somehow an exception because it MUST carry the current CmdSN (implying that maybe other immediate commands do not have to carry the current CmdSN). To eliminate the confusion, but to keep the same intention, a suggested rewording would be: To the first paragraph quoted above, change the phrase "they also carry CmdSN" to: "they MUST also carry the current CmdSN". In the second paragraph quoted above, either change the second sentence (the one starting "For this reason...") to: "However, their CmdSN is a marker of their position in the stream of commands." (which is the wording that was used previously in draft 12), or just eliminate the second sentence entirely, since this topic is discussed later in section 2.5.1.3 and again in section 9.5.1. 3. Section 9.13.3 states: "For a new session, the target MUST generate a non-zero TSIH and return it in the Login Final-Response (see Section 4.3 Login Phase). In all other cases, this field should be set to the TSIH provided by the initiator in the Login Request." The phrase "in all other cases" is ambiguous. Some companies are interpreting it to mean "sessions other than a new session", while others are interpreting it to mean "Login Responses other than the Login Final-Response in a new session". So what is the intent? On a new session, clearly the target MUST return the non-zero TSIH in the Login Final-Response, but can it also return a non-zero TSIH in the first, second, ... Login Partial Responses that precede the Login Final-Response? If the intent for new sessions is to have the TSIH set to 0 in Login Partial-Responses and only change to a non-zero TSIH in the Login Final-Response, then a suggested rewording to make this clear would be: "Except for the Login Final-Response in a new session, this field should be set to the TSIH provided by the initiator in the Login Request. For a new session, the target MUST generate a non-zero TSIH and return it ONLY in the Login Final-Response (see Section 4.3 Login Phase)." If the intent is to allow, but not require, the target to return the non-zero TSIH in the first, second, ... Login Partial Responses in a new session, then a suggested rewording to make this clear would be: "During Login Phases that do not establish a new session, this field should be set to the TSIH provided by the initiator in the Login Request. For a new session, the target MUST generate a non-zero TSIH and MAY return it in a Login Partial-Response but MUST return it in the Login final-Response (see Section 4.3 Login Phase)." This last interpretation still leaves open the question of whether the target is allowed to toggle back and forth between 0 and the newly-generated TSIH within sequences of Login Partial-Responses. 4. There has been some misunderstanding with the phrase "not advanced". For example, in section 9.8.2 StatSN it says: "The StatSN field will contain the next StatSN. The StatSN for this connection is not advanced." In spite of the presence of the word "next", some implementations are interpreting this to mean that this PDU will always contain the same value for StatSN as was sent in the previous response. Perhaps it would help if the words "after this PDU is sent" were added to the last sentence quoted above so that it would read: "The StatSN for this connection is not advanced after this PDU is sent." Other examples where this wording could be added to help clarify when the advancing is performed (or not performed) are: section 2.2.2.1: "Commands meant for immediate delivery are marked with an immediate delivery flag; they also carry the next CmdSN. CmdSN does not advance after commands marked for immediate delivery are sent." section 2.2.2.1: "- CmdSN - the current command Sequence Number, advanced by 1 after each command shipped except for commands marked for immediate delivery." section 2.2.2.3: "For input (read) data PDUs, DataSN starts with 0 for the first data PDU of an input command and advances by 1 after each data PDU is sent. For output data PDUs, DataSN starts with 0 for the first data PDU of a sequence (the initial unsolicited sequence or any data PDU sequence issued to satisfy an R2T) and advances by 1 after each data PDU is sent. R2Ts are also sequenced per command. For example, the first R2T has an R2TSN of 0 and the R2TSN advances by 1 after each R2T is sent." section 9.11.5: "The target StatSN register is advanced after each Text Response is sent." section 9.18.1: "However, the I bit must be set to 1 and the CmdSN is not advanced after this PDU is sent." section 9.19.2: "However, when the Initiator Task Tag is set to 0xffffffff, StatSN for the connection is not advanced after this PDU is sent." 5. There has been major disagreement about correct digest values. A number of implementations differ only due to a Big-Endian/ Little-Endian problem that we hope to be able to resolve over the next few days. Differences between other implementations show no discernible pattern. Of course, all implementations claim to compute the proper answers to the test cases given in the standard. The difficulty is that these test cases are not sample pdus and therefore never actually occur during operation. A recommendation would be to include in the standard a simple sample PDU (one that could actually be sent during a session) and give its correctly computed CRC value. For example, a NOP-OUT PDU with I=1, DataSegmentLength=0, Lun=0, InitiatorTaskTag and Target Transfer Tag both = 0xffffffff, CmdSN = 1234, and ExpStatSN=567 could be legal, and most implementations could probably arrange fairly simply for such a PDU to actually be sent by an initiator. By publishing the correct CRC value for such a pdu, all questions about who is right and who is wrong are immediately solved, and new implementations can be developed more accurately. Thank you for your consideration. Bob Russell InterOperability Lab University of New Hampshire rdr@iol.unh.edu 603-862-3774 From owner-ips@ece.cmu.edu Wed Jul 31 20:39:13 2002 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA22710 for ; Wed, 31 Jul 2002 20:39:08 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id g6VNqXB13506 for ips-outgoing; Wed, 31 Jul 2002 19:52:33 -0400 (EDT) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from d12lmsgate-2.de.ibm.com (d12lmsgate-2.de.ibm.com [195.212.91.200]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id g6VNqVo13501 for ; Wed, 31 Jul 2002 19:52:31 -0400 (EDT) Received: from d12relay02.de.ibm.com (d12relay02.de.ibm.com [9.165.215.23]) by d12lmsgate-2.de.ibm.com (8.12.3/8.12.3) with ESMTP id g6VNqOPV031266; Thu, 1 Aug 2002 01:52:24 +0200 Received: from d10hubm1.telaviv.ibm.com (d10ml001.telaviv.ibm.com [9.148.216.55]) by d12relay02.de.ibm.com (8.12.3/NCO/VER6.3) with ESMTP id g6VNqNwC034470; Thu, 1 Aug 2002 01:52:24 +0200 To: "Robert D. Russell" Cc: ips@ece.cmu.edu MIME-Version: 1.0 Subject: Re: iSCSI: plugfest4 issues X-Mailer: Lotus Notes Release 5.0.9 November 16, 2001 From: "Julian Satran" Message-ID: Date: Thu, 1 Aug 2002 02:52:19 +0300 X-MIMETrack: Serialize by Router on D10ML001/10/M/IBM(Release 5.0.9a |January 7, 2002) at 01/08/2002 02:52:23, Serialize complete at 01/08/2002 02:52:23 Content-Type: multipart/alternative; boundary="=_alternative 00826CB9C2256C07_=" Sender: owner-ips@ece.cmu.edu Precedence: bulk This is a multipart message in MIME format. --=_alternative 00826CB9C2256C07_= Content-Type: text/plain; charset="us-ascii" Bob, Thanks - some comments in text. Julo "Robert D. Russell" 07/31/2002 02:43 AM To: Julian Satran/Haifa/IBM@IBMIL, cc: Subject: Re: iSCSI: plugfest4 issues Julian: Four issues came up today at the iSCSI plugfest: 1. A question about whether or not the Residual Count field and the appropriate O and U bits need to be computed on all SCSI Response PDUs, regardless of the values in the Status and/or Response fields. One point of view says that the Residual Count field and the O and U bits appear to be strictly iSCSI values that are derived by the iSCSI target layer from the ExpectedDataTransferLength field of the SCSI Command PDU and the DataSegmentLength fields of the DataIn or DataOut PDUs sent as part of this command. Therefore ,the iSCSI target always computes a Residual Count value without regard to the Status and/or Response fields, since these are SCSI values. The other point of view says that the Residual Count field, and the O and U bits, need only be set when the Status and Response fields indicate that the command was completed at the target with a GOOD Status, and the target does not have to compute or set the Residual Count field and the O or U bits for other values of the Status and/or Response fields. Which is it? In any case, could this be clarified somewhere in the standard, most likely in section 9.4.4. +++ Residual count fields are in fact carrioed over from the SCSI layer. I know that none of the SCSI docs specifies exactly their behavior and it strikes me as a bad idea to have protocols specify them. The values should be valid any time the target decides to put them in. +++ 2. The last paragraph of section 2.2.3 says: "Before the Full Feature Phase is established, only Login Request and Login Response PDUs are allowed. Any other PDU, when received at ini- tiator or target, is a protocol error and MUST result in the connec- tion being terminated. ..." The question is the following: is this rule literally true for the target (i.e., can the target disconnect as soon as it receives a non-Login PDU from the initiator) or does the target have to first send a Login Response with Login reject PDU before disconnecting, as it does for all other errors detected by the target during Login Phase (according to section 4.3.1)? A related question is: does the target take the same action when the very first PDU it receives on a new TCP connection is not a Login Request PDU? If the target has to send the Login reject PDU before disconnecting, then the last paragraph of section 2.2.3 should be reworded along the following lines (modeled after the last paragraph of section 4.3): "Before the Full Feature Phase is established, only Login Request and Login Response PDUs are allowed. If the target receives any PDU other than Login Request, it must send a Login reject (code 0x020b) and then disconnect. If the initiator receives any PDU other than Login Response, it MUST drop the connection. ..." This wording would also appear to cover the case of when the very first PDU a target receives on a new TCP connection is not a Login Request. +++ I would suggest sticking with disconnecting. +++ 3. Section 4.2 says: "All keys in Chapter 11, except for the X- extension format, MUST be supported by iSCSI initiators and targets and MUST NOT be answered with NotUnderstood." Two questions arose with this statement: 1. Shouldn't it say "All keys in Chapter 11 and Appendix A, ..." in order to include the Marker keys within the scope of this rule? 2. Does this literally mean that targets have to support initiator-only keys (and initiators support target-only keys)? For example, suppose a target sends an InitiatorAlias key, which is supposed to be sent only by Initiators. Does the target have to make an extra check to recognize that this is a "key in Chapter 11" that is used incorrectly, (so that it does not respond with NotUnderstood) or can it just treat it like it would any other key it cannot handle, for example, X-InitiatorAlias, and respond with NotUnderstood? This last question is actually a special case of a more general question, and that is: "How much checking does a receiver have to do?" just to generate a "proper error response"? Section 9 explicitly says that "Any compliant receiver MUST ignore any bit not defined and all reserved fields unless specified otherwise." This is the expression of the general philosophy "conservative in what you send, liberal in what you accept" and eliminates a lot of unnecessary checking. A similar general philosophy applied to other checking would be beneficial, although it may be hard to formulate it. +++ I've made the offending paragraph read: All keys in this document except for the X extension formats, MUST be supported by iSCSI initiators and targets when used as specified here. If used as specified those keys MUST NOT be answered with NotUnderstood. +++ 4. This is not a question but rather an observation for implementers. Not setting the I bit in a NOP-Out ping request can lead to unusual situations. Consider the situation where a session has multiple connections and the initiator periodically sends NOP-Out ping requests on each connection just to ensure that the target is still alive. If these NOP-Out requests are not immediate, and one of them gets lost (due to a bad checksum, or because that connection really is no longer alive), then none of the following NOP-Out requests on the other connections can be processed by the target, because that would be processing them out of CmdSN order, and as a result it would appear to the initiator that all connections are bad instead of just one! It appears that similar situations may arise when Task Management Function commands are sent without setting the I bit -- the target would be prevented from processing any of them that follow a command that is lost. Thank you for your consideration. +++ That is a good point. Non-immediate NOPs are meant to be use as time measuring pings and test the entire stack including the queuing mechanism. +++ Bob Russell InterOperability Lab University of New Hampshire rdr@iol.unh.edu 603-862-3774 --=_alternative 00826CB9C2256C07_= Content-Type: text/html; charset="us-ascii"
Bob,

Thanks - some comments in text. Julo


"Robert D. Russell" <rdr@io.iol.unh.edu>

07/31/2002 02:43 AM

       
        To:        Julian Satran/Haifa/IBM@IBMIL, <ips@ece.cmu.edu>
        cc:        
        Subject:        Re: iSCSI: plugfest4 issues

       



Julian:

Four issues came up today at the iSCSI plugfest:

1. A question about whether or not the Residual Count field and the
  appropriate O and U bits need to be computed on all SCSI Response
  PDUs, regardless of the values in the Status and/or Response fields.

  One point of view says that the Residual Count field and the O and U
  bits appear to be strictly iSCSI values that are derived by the
  iSCSI target layer from the ExpectedDataTransferLength field of the
  SCSI Command PDU and the DataSegmentLength fields of the DataIn or
  DataOut PDUs sent as part of this command.  Therefore ,the iSCSI
  target always computes a Residual Count value without regard to the
  Status and/or Response fields, since these are SCSI values.

  The other point of view says that the Residual Count field, and the
  O and U bits, need only be set when the Status and Response fields
  indicate that the command was completed at the target with a GOOD
  Status, and the target does not have to compute or set the Residual
  Count field and the O or U bits for other values of the Status and/or
  Response fields.

  Which is it?  In any case, could this be clarified somewhere in the
  standard, most likely in section 9.4.4.
+++ Residual count fields are in fact carrioed over from the SCSI layer. I know that none of the SCSI docs specifies exactly their behavior and it strikes me as a bad idea to have protocols specify them.
The values should be valid any time the target decides to put them in.  +++

2. The last paragraph of section 2.2.3 says:

  "Before the Full Feature Phase is established, only Login Request and
  Login Response PDUs are allowed. Any other PDU, when received at ini-
  tiator or target, is a protocol error and MUST result in the connec-
  tion being terminated. ..."

  The question is the following:  is this rule literally true for the
  target (i.e., can the target disconnect as soon as it receives a
  non-Login PDU from the initiator) or does the target have to first
  send a Login Response with Login reject PDU before disconnecting, as
  it does for all other errors detected by the target during Login
  Phase (according to section 4.3.1)?

  A related question is: does the target take the same action when
  the very first PDU it receives on a new TCP connection is not a
  Login Request PDU?

  If the target has to send the Login reject PDU before disconnecting,
  then the last paragraph of section 2.2.3 should be reworded along
  the following lines (modeled after the last paragraph of section 4.3):

  "Before the Full Feature Phase is established, only Login Request
  and Login Response PDUs are allowed.  If the target receives any PDU
  other than Login Request, it must send a Login reject (code 0x020b)
  and then disconnect.  If the initiator receives any PDU other than
  Login Response, it MUST drop the connection. ..."

  This wording would also appear to cover the case of when the very first
  PDU a target receives on a new TCP connection is not a Login Request.
+++ I would suggest sticking with disconnecting. +++

3. Section 4.2 says:

 "All keys in Chapter 11, except for the X- extension format, MUST be
 supported by iSCSI initiators and targets and MUST NOT be answered with
 NotUnderstood."

 Two questions arose with this statement:

 1. Shouldn't it say "All keys in Chapter 11 and Appendix A, ..." in order
    to include the Marker keys within the scope of this rule?

 2. Does this literally mean that targets have to support initiator-only
    keys (and initiators support target-only keys)?
    For example, suppose a target sends an InitiatorAlias key, which is
    supposed to be sent only by Initiators.  Does the target have to
    make an extra check to recognize that this is a "key in Chapter 11"
     that is used incorrectly, (so that it does not respond with
    NotUnderstood) or can it just treat it like it would any other key
    it cannot handle, for example, X-InitiatorAlias, and respond with
    NotUnderstood?

    This last question is actually a special case of a more general
    question, and that is: "How much checking does a receiver have to
    do?" just to generate a "proper error response"?
    Section 9 explicitly says that "Any compliant receiver MUST ignore
    any bit not defined and all reserved fields unless specified
    otherwise."  This is the expression of the general philosophy
    "conservative in what you send, liberal in what you accept" and
    eliminates a lot of unnecessary checking.  A similar general
    philosophy applied to other checking would be beneficial,
    although it may be hard to formulate it.
+++

I've made the offending paragraph read:

All keys in this document except for the X extension formats, MUST be supported by iSCSI initiators and targets when used as specified here. If used as specified those keys MUST NOT be answered with NotUnderstood.
+++

4. This is not a question but rather an observation for implementers.

  Not setting the I bit in a NOP-Out ping request can lead to unusual
  situations.  Consider the situation where a session has multiple
  connections and the initiator periodically sends NOP-Out ping
  requests on each connection just to ensure that the target is
  still alive.  If these NOP-Out requests are not immediate, and
  one of them gets lost (due to a bad checksum, or because that
  connection really is no longer alive), then none of the following
  NOP-Out requests on the other connections can be processed by the
  target, because that would be processing them out of CmdSN order,
  and as a result it would appear to the initiator that all
  connections are bad instead of just one!

  It appears that similar situations may arise when Task Management
  Function commands are sent without setting the I bit -- the target
  would be prevented from processing any of them that follow a
  command that is lost.

Thank you for your consideration.
+++

That is a good point.
Non-immediate NOPs are meant to be use as time measuring pings
and test the entire stack including the queuing mechanism.

+++
Bob Russell
InterOperability Lab
University of New Hampshire
rdr@iol.unh.edu
603-862-3774

--=_alternative 00826CB9C2256C07_=-- From owner-ips@ece.cmu.edu Wed Jul 31 21:12:34 2002 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA23186 for ; Wed, 31 Jul 2002 21:12:19 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id g710Y7p15963 for ips-outgoing; Wed, 31 Jul 2002 20:34:07 -0400 (EDT) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from palrel10.hp.com (palrel10.hp.com [156.153.255.245]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id g710Y5o15959 for ; Wed, 31 Jul 2002 20:34:05 -0400 (EDT) Received: from hpcuhe.cup.hp.com (hpcuhe.cup.hp.com [15.0.80.203]) by palrel10.hp.com (Postfix) with ESMTP id 741DDC00EFF; Wed, 31 Jul 2002 17:34:04 -0700 (PDT) Received: from cup.hp.com (santoshr@hpindhhm.cup.hp.com [15.8.80.197]) by hpcuhe.cup.hp.com (8.9.3 (PHNE_18979)/8.9.3 SMKit7.02) with ESMTP id RAA06780; Wed, 31 Jul 2002 17:33:59 -0700 (PDT) Message-ID: <3D488477.895DFBD@cup.hp.com> Date: Wed, 31 Jul 2002 17:44:39 -0700 From: Santosh Rao Organization: Hewlett Packard, Cupertino. X-Mailer: Mozilla 4.78 [en] (X11; U; HP-UX B.11.00 9000/778) X-Accept-Language: en MIME-Version: 1.0 To: IPS Reflector , Julian Satran , rdr@io.iol.unh.edu Cc: Robert Snively , T10 Reflector Subject: Re: iSCSI: plugfest4 issues Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ips@ece.cmu.edu Precedence: bulk Content-Transfer-Encoding: 7bit Julian & Robert [Russell], I raised the same query regarding RESID for FCP/FCP-2 this time last year. The response I got for FCP/FCP-2 was that RESID information shall be valid, regardless of the scsi status returned. The RESID field, can be checked by the scsi transport drivers independent of the SCSI STATUS. I have enclosed the T10 response from Rob Snivelly below on that issue. As per FC-PLDA, the RESID information is valid, regardless of the scsi status returned by the device. An example of this is the case of "NO SENSE" or "RECOVERED ERROR" check condition, when the data transfer may have taken place and a CHECK CONDITION is returned. Also, for other CHECK CONDITION status', partial data transfer may have taken place and hence, resid information should be present. It would be good to maintain consistent behaviour across the scsi transports in this regard, since protocol bridging from iscsi to FCP domain would expect RESID information in the FCP domain, regardless of scsi status. This also allows scsi transports to remain free of SCSI command set details. (ex : the scsi transport drivers do not need to parse for CHECK CONDITION or GOO status information.) Thanks, Santosh ------------------------------------------------------------------------- Subject: Re: iSCSI: plugfest4 issues Date: Thu, 1 Aug 2002 02:52:19 +0300 From: "Julian Satran" To: "Robert D. Russell" CC: ips@ece.cmu.edu Bob, Thanks - some comments in text. Julo "Robert D. Russell" Julian: Four issues came up today at the iSCSI plugfest: 1. A question about whether or not the Residual Count field and the appropriate O and U bits need to be computed on all SCSI Response PDUs, regardless of the values in the Status and/or Response fields. One point of view says that the Residual Count field and the O and U bits appear to be strictly iSCSI values that are derived by the iSCSI target layer from the ExpectedDataTransferLength field of the SCSI Command PDU and the DataSegmentLength fields of the DataIn or DataOut PDUs sent as part of this command. Therefore ,the iSCSI target always computes a Residual Count value without regard to the Status and/or Response fields, since these are SCSI values. The other point of view says that the Residual Count field, and the O and U bits, need only be set when the Status and Response fields indicate that the command was completed at the target with a GOOD Status, and the target does not have to compute or set the Residual Count field and the O or U bits for other values of the Status and/or Response fields. Which is it? In any case, could this be clarified somewhere in the standard, most likely in section 9.4.4. +++ Residual count fields are in fact carrioed over from the SCSI layer. I know that none of the SCSI docs specifies exactly their behavior and it strikes me as a bad idea to have protocols specify them. The values should be valid any time the target decides to put them in. +++ ------------------------------------------------------------------------- Subject: RE: FCP_RSP Residual Checking. Date: Thu, 5 Jul 2001 13:18:42 -0700 From: Robert Snively To: "'Santosh Rao'" , T10 Reflector , Fibre Channel T11 reflector Robert Snively wrote: > > > Is the target required to initialize the fields FCP_RESID_UNDER, > > FCP_RESID_OVER & FCP_RESID when any I/O is completed > > without the data phase having transferred exactly > > FCP_DL bytes, regardless of the SCSI Status being returned ? > > > When the target generates a CHECK CONDITION on an I/O > > and may have returned less than FCP_DL bytes in the data > > phase for that I/O, is it > > required to set the FCP_RESID_UNDER to 1 and indicate the number of > > bytes not transferred in the FCP_RESID field? > > The intent is that the answer to your second question is: > FCP_RESID should appropriately regardless of the SCSI Status > being returned. The classic errors of that class are those > involving successful completion with reporting, like > the "NO SENSE" and "RECOVERED ERROR" series of errors. > > > > > What is the behaviour initiators can expect under the above > > condition ? > > The intent is that there be no conflict. I believe that FCP-2 > was a bit less bald than FC-PLDA in stating the requirement. > > > Is there a conflict in the behaviours described by FCP/FCP-2 > > & FC-PLDA ? > > > > Bob Snively e-mail: rsnively@brocade.com > Brocade Communications Systems phone: 408 487 8135 > 1745 Technology Drive > San Jose, CA 95110 > > > -----Original Message----- > > From: Santosh Rao [mailto:santoshr@cup.hp.com] > > Sent: Thursday, July 05, 2001 12:15 PM > > To: T10 Reflector; Fibre Channel T11 reflector > > Subject: FCP_RSP Residual Checking. > > > > > > All, > > > > I've got a question on target behaviour while sending a > > CHECK CONDITION > > SCSI status in its FCP_RSP IU. > > > > Is the target required to initialize the fields FCP_RESID_UNDER, > > FCP_RESID_OVER & FCP_RESID when any I/O is completed without the data > > phase having transferred exactly FCP_DL bytes, regardless of the SCSI > > Status being returned ? > > > > When the target generates a CHECK CONDITION on an I/O and may have > > returned less than FCP_DL bytes in the data phase for that I/O, is it > > required to set the FCP_RESID_UNDER to 1 and indicate the number of > > bytes not transferred in the FCP_RESID field? > > > > FC-PLDA Section 8.2.4.1 states that : > > "SCSI targets that transfer less than FCP_DL bytes during > > the FCP_DATA > > IUs shall set the FCP_RESID_UNDER to 1". > > > > No exceptions are specified in the case of a CHECK CONDITION in the > > above definition, implying that FCP_RSP residual checking can be > > performed irrespective of the SCSI Status that was returned in the > > FCP_RSP. > > > > However, the wording descriptions of FCP_RESID_UNDER, > > FCP_RESID_OVER & > > FCP_RESID in SCSI-FCP & FCP-2 are not as stringent as > > FC-PLDA and do not > > mandate that FCP_RESID_UNDER shall be set when the data > > transferred is < > > FCP_DL. > > > > What is the behaviour initiators can expect under the above > > condition ? > > Is there a conflict in the behaviours described by FCP/FCP-2 > > & FC-PLDA ? > > > > Thanks, > > Santosh Rao > > -- Education is when you read the fine print. Experience is what you get if you don't. From owner-ips@ece.cmu.edu Wed Jul 31 23:36:48 2002 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA25934 for ; Wed, 31 Jul 2002 23:36:48 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id g712pLA22780 for ips-outgoing; Wed, 31 Jul 2002 22:51:21 -0400 (EDT) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from pepsi.splentec.com (ns.splentec.com [209.47.35.194]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id g712pGo22768 for ; Wed, 31 Jul 2002 22:51:16 -0400 (EDT) Received: from splentec.com (canoe.splentec.com [209.47.35.250]) by pepsi.splentec.com (8.11.6/8.11.0) with ESMTP id g712p2s24987; Wed, 31 Jul 2002 22:51:02 -0400 Message-ID: <3D48A216.452E6C2F@splentec.com> Date: Wed, 31 Jul 2002 22:51:02 -0400 From: Luben Tuikov Organization: Splentec Ltd. X-Mailer: Mozilla 4.79 [en] (X11; U; Linux 2.4.19-rc3 i686) X-Accept-Language: en MIME-Version: 1.0 To: "Robert D. Russell" CC: iSCSI Subject: Re: iSCSI: plugfest4 issues References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ips@ece.cmu.edu Precedence: bulk Content-Transfer-Encoding: 7bit "Robert D. Russell" wrote: > > > 3. Section 9.13.3 states: > "For a new session, the target MUST generate a non-zero TSIH and > return it in the Login Final-Response (see Section 4.3 Login Phase). > In all other cases, this field should be set to the TSIH provided > by the initiator in the Login Request." > > The phrase "in all other cases" is ambiguous. Some companies are > interpreting it to mean "sessions other than a new session", while > others are interpreting it to mean "Login Responses other than > the Login Final-Response in a new session". > > So what is the intent? On a new session, clearly the target MUST > return the non-zero TSIH in the Login Final-Response, but can it > also return a non-zero TSIH in the first, second, ... Login Partial > Responses that precede the Login Final-Response? The intent is that for a new session the initiator MUST set the TSIH to the reserved value of 0, during login. During login the target will copy TSIH from the request to the response, effectively setting it to 0. On the last login response (the one which completes the switch to FFP, I<-T), the target will set TSIH to a valid non-reserved value (which it generated whenever). From that point on the initiator should always set TSIH to that value. (FFP, connection reinstatement, etc.) Though not explicit, compiling everything mentioning TSIH in the draft, evident this becomes. > 4. There has been some misunderstanding with the phrase "not advanced". > For example, in section 9.8.2 StatSN it says: "The StatSN field will > contain the next StatSN. The StatSN for this connection is not > advanced." > > In spite of the presence of the word "next", some implementations are > interpreting this to mean that this PDU will always contain the same > value for StatSN as was sent in the previous response. Perhaps it > would help if the words "after this PDU is sent" were added to the > last sentence quoted above so that it would read: "The StatSN for > this connection is not advanced after this PDU is sent." Actually the above two sentences are correct and in harmony. Anything SN in the draft, at any point in time, contains the next value to be assigned. This is the intent, as counting starts from 0 and setting xxxxSN = 0, works out as intended. This is also deduced from looking at the equation which gives the queue size. So particulartly for 9.8.2 (R2T) since no status is reported one does (w.l.g.) packet->statsn = conn->statsn; but when status is reported (w.l.g) MOV_AND_INC_SN(packet->statsn, conn->statsn), which does an assignment (packet->statsn = conn->statsn) and increments conn->statsn (over the reserved value of course) somewhat atomically. The only difference is incrementing _after_ assignment, assignment always being first. Similarly for I->T, when I=0 and I=1, regarding cmdsn, etc. > section 9.19.2: "However, when the Initiator Task Tag is set to > 0xffffffff, StatSN for the connection is not advanced after this > PDU is sent." Which makes sense, since if ITT = the reserved value, then the Target is initiating the Nop sequence and it is NOT reporting status. -- Luben