a5=20 Ted 010= 203040506 0000 0001 idisk=20 * #2 it-4

a6=20 Fred 01020304= 0506 0000 0001 idisk=20 * ??

a7=20 Ted 010= 203040506 =20 0004 0001 idisk ??

a8=20 Ted 010= 203040506 =20 0001 0001=20 idisk ??

<= /SPAN>

*=20 Leading login TSID=3D0000 was sent by initiator, TSID value assigned by = target.

---------------------------------------------------------------= ----------

Within any single = session there will=20 be one or more I_T nexus formed (see a1, a2, a3,=20 a4).

           = ISID RULE:=20 Between a given iSCSI Initiator and iSCSI Target Portal=20
           Group = (SCSI=20 target port), there can be only one session with a given=20
           value = for ISID=20 that identifies the SCSI initiator port. See Section=20
           9.12.5 = ISID.

My=20 interpretation: any initiator's attempt to = reuse=20 the same ISID for creating an additional session (TSID =3D = 0000) with the=20 same target-portal-group breaks the ISID rule;=20 initiators must=20 provide different ISID = values to=20 create new sessions with the same target-portal-group (see a6, breaks = ISID=20 rule). However, since the "initiator port identifier" includes=20 InitiatorName, alternate initiators may simultaneously use the same = ISID value=20 (see a5, does not break ISID rule).

           = TSID RULE:=20 The iSCSI Target SHOULD NOT select a TSID for a given login=20
           = request if the=20 resulting SSID is already in use by an existing session=20
           = between the=20 target and the requesting iSCSI Initiator. See Section=20
           8.1.1=20 Conservative Reuse of ISIDs.

My interpretation: a target should expect (and accept) = initiator=20 attempts to login with the same ISID and can select the same TSID as = long=20 it's from a different initiator (see a5). However, if an = existing=20 initiator is identified, then the target should select a TSID = that=20 forms a unique SSID (see b4). This is confusing because it = assumes=20 that the initiator will break the ISID rule? Also, does this = break session=20 reinstatement?

---------------------------------------------------------------= ----------

= InitiatorName =20 ISID CID = TSID =20 TargetName Session

b1 Fred &nb= sp; 010203040506 =20 0000 0001 =20 idisk * #1

b2 Bob &nbs= p; =20 010203040506 0000 0001 = idisk=20 * #2

b3=20 Joe &nb= sp;=20 010203040506 0000 = 0001 idisk=20 * #3

b4 Fred &nb= sp; 010203040506 =20 0000 0002 =20 idisk * = #4

* Leading login = TSID=3D0000 was sent by=20 initiator, TSID value assigned by=20 target.

---------------------------------------------------------------= ----------

&nb= sp;

How does = this work with=20 4.3.5 Session = Reinstatement:

          = ; Session=20 reinstatement is the process of initiator logging in with an=20
           ISID = that is=20 possibly active from the target's perspective - thus=20
           = implicitly=20 logging out the session state machine corresponding to the=20
           ISID = and=20 reinstating a new iSCSI session in its place (with the same=20
           = ISID). =20 Thus, the TSID in the Login PDU MUST be zero to signal session=20
          =20 reinstatement. All the tasks that were active on the old session = are=20
           = internally=20 terminated on a session reinstatement.

= ; The=20 initiator session state MUST be FAILED (Section 5.3 Session State=20
= Diagrams) for=20 attempting a session=20 reinstatement.

My interpretation (#1 of 2): Session = reinstatement=20 only occurs when the target has identified and authenticated that = an=20 existing initiator (identified by InitiatorName & ISID) has = performed a=20 second leading login. Then and only then can session = reinstatement be=20 performed. Unfortunately, this assumes that sessions will = always have=20 the same initiator performing the leading login (so in a1->a4, = only Fred=20 can perform session reinstatement for that session.) That's bad = news if=20 that particular initiator is no longer = active.

(#2 of = 2): ANY leading login received by the iSCSI = target with an=20 existing and target-perspective active ISID is assumed = to be=20 session reinstatement. This means that the logins described by [ = a5 &=20 b1..b4 ] are invalid. Further, this conflicts with your note = saying that=20 the initiator must be completely identified on every=20 login.

Now look at connection reinstatement=20 (4.3.4)

          = ;=20 Connection reinstatement is the process of initiator logging in with a=20
           = ISID-TSID-CID=20 combination that is possibly active from the target's=20
           = perspective -=20 thus implicitly logging out the connection state=20
           = machine=20 corresponding to the CID and reinstating a new full-feature=20
           phase = iSCSI=20 connection in its place (with the same CID). Thus, the=20
           TSID = in the=20 Login PDU MUST be non-zero and CID does not change during=20
           a = connection=20 reinstatement. The Login command performs the logout=20
           = function of the=20 old connection if an explicit logout was not performed=20
           = earlier. In=20 sessions with a single connection, this may imply the=20
           = opening of a=20 second connection with the sole purpose of cleaning up=20
           the = first.=20 Targets should support opening a second connection even=20
           when = they do=20 not support multiple connections in full feature phase.

           If = the=20 operational ErrorRecoveryLevel is 2, connection reinstatement=20
           = enables future=20 task reassignment. If the operational=20 ErrorRecovery-
         = =20 Level is less than 2, connection reinstatement is the replacement of=20
           the = old CID=20 without enabling task reassignment. In this case, all the=20
           tasks = that were=20 active on the old CID are internally terminated.

The = initiator=20 connection state MUST be CLEANUP_WAIT (section 5.1) for=20
= attempting a=20 connection reinstatement.

If an iSCSI connection is attempted in which = multiple=20 initiator-sessions are available with the same ISID + TSID, to which = session=20 should the iSCSI target attach it? In [a7] above, there are two = active=20 sessions with the same SSID, to which should a7 = be attached? =20 Another special case [a8] will result in either a new connection on = session #2=20 or connection reinstatement (or possible conflict) with session=20 #1.

Thanks for your time on=20 this!

-----Original = Message-----
From:=20 Julian Satran [mailto:Julian_Satran@il.ibm.com]
Sent: = Wednesday, March=20 20, 2002 9:08 AM
To: Michael Schoberg
Cc: IPS = Reflector=20 (E-mail); owner-ips@ece.cmu.edu
Subject: Re: iSCSI: Rev 11 = minor=20 issues

To add a connection to an existing session = you need to=20 comletely identify the session you are attaching to.
A host can use several initiator names and = a target can=20 held several target names.
The=20 ISID+TPGT are unique only between a pair of names. =

JUlo

Michael Schoberg=20 <michael_schoberg@cnt.com>
Sent by: owner-ips@ece.cmu.edu=20
19-03-02 20:27 =
Please respond to Michael = Schoberg=20
=
To: = =20 "IPS Reflector (E-mail)" = <ips@ece.cmu.edu>=20
= cc: =20
=20 Subject: iSCSI: = Rev 11=20 minor issues

= =20

Just want to verify something. Is it possible to have = multiple=20 Initiator identities (i.e.: InitiatorName=3D) on the same session = through=20 different connections? If not, why is InitiatorName negotiation = required=20 on ancillary connections. If iSCSI doesn't allow for multiple = initiators=20 per session, then all it's doing is requiring another check for the = target;=20 that the same InitiatorName is given for all connections on the=20 session.=20
Example .. on the leading = session=20 connection, the initiator says:=20
InitiatorName=3DFred=20
Then on an ancillary = connection the=20 initiator says:=20
InitiatorName=3DBob =
Now the target would have = to trap this=20 and zap the connection. Why not just assume the same = InitiatorName as=20 the session and let authentication verify it? This eliminates = the extra=20 negotiation check on the target.=20

4.3=20
The initial login = request of any=20 connection MUST include the InitiatorName key=3Dvalue pair. =

8.1.2 & 11=20
"SW" and "CO" ? Can = the=20 abbreviation be dropped and replaced with the full description?=20 "Session-Wide" and "Connection-Wide" should fit on the = line.=20

------_=_NextPart_001_01C1D046.ACEFF660-- From owner-ips@ece.cmu.edu Wed Mar 20 16:59: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 QAA16461 for ; Wed, 20 Mar 2002 16:59:41 -0500 (EST) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id g2KL0hI02335 for ips-outgoing; Wed, 20 Mar 2002 16:00:43 -0500 (EST) 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 g2KL0fw02331 for ; Wed, 20 Mar 2002 16:00:42 -0500 (EST) Received: from d12relay02.de.ibm.com (d12relay02.de.ibm.com [9.165.215.23]) by d12lmsgate-2.de.ibm.com (1.0.0) with ESMTP id WAA58118 for ; Wed, 20 Mar 2002 22:00:35 +0100 Received: from d10hubm1.telaviv.ibm.com (d10ml001.telaviv.ibm.com [9.148.216.55]) by d12relay02.de.ibm.com (8.11.1m3/NCO/VER6.00) with ESMTP id g2KL0YW98544 for ; Wed, 20 Mar 2002 22:00:34 +0100 To: ips@ece.cmu.edu X-Mailer: Lotus Notes Release 5.0.9 November 16, 2001 Message-ID: From: "Julian Satran" Date: Wed, 20 Mar 2002 19:05:00 +0200 X-MIMETrack: Serialize by Router on D10ML001/10/M/IBM(Release 5.0.9a |January 7, 2002) at 20/03/2002 23:00:34 MIME-Version: 1.0 Content-type: text/plain; charset=us-ascii Sender: owner-ips@ece.cmu.edu Precedence: bulk Dear colleagues, I suggested using : (colon) to separate values in a range. Unfortunately : is overused (in addresses and in names). I suggest we use the (old) two dots (..) to mark a range. Comments? Julo From owner-ips@ece.cmu.edu Wed Mar 20 17:48: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 RAA18074 for ; Wed, 20 Mar 2002 17:48:29 -0500 (EST) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id g2KM5jM06696 for ips-outgoing; Wed, 20 Mar 2002 17:05:45 -0500 (EST) 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 g2KM5hw06691 for ; Wed, 20 Mar 2002 17:05:43 -0500 (EST) Received: from nisser.cisco.com (nisser.cisco.com [171.71.176.85]) by sj-msg-core-1.cisco.com (8.11.3/8.9.1) with ESMTP id g2KM5bd11557 for ; Wed, 20 Mar 2002 14:05:37 -0800 (PST) Received: from cisco.com (58509@mbakke-lnx.cisco.com [161.44.68.87]) by nisser.cisco.com (8.8.6 (PHNE_14041)/CISCO.SERVER.1.2) with ESMTP id OAA26575 for ; Wed, 20 Mar 2002 14:05:35 -0800 (PST) Message-ID: <3C9903FD.9085407D@cisco.com> Date: Wed, 20 Mar 2002 15:49:49 -0600 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: IPS: SLP MIB draft Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ips@ece.cmu.edu Precedence: bulk Content-Transfer-Encoding: 7bit Here's the SLP MIB draft announcement from the SLP list. The object model (extremely simple) is at: ftp://ftp.pwg.org/pub/pwg/ipp/new_SLP/draft-mcdonald-svrloc-mib-uml-03.pdf -- Mark "McDonald, Ira" wrote: > > Copies: "SLP Project" > "IETF IPP WG" > > Hi folks, Friday (1 March 2002) > > I've just sent a revised draft of 'Definitions of Managed Objects for > Service Location Protocol (SLP MIB)' to the Internet-Drafts editor and > posted a copy on the Printer Working Group (PWG) Anonymous FTP server in > the directory 'ftp://ftp.pwg.org/pub/pwg/ipp/new_SLP/' in the files: > > (1 March 2002) - full I-D > (1 March 2002) - SMIv2 MIB > > This draft is a minor rewrite to remove all the remaining 'read-write' > objects, per concensus of the SLP Project mailing list. The draft-01 > defined 142 objects. This new draft defines 10 mandatory and 6 optional > objects. > > My co-editor Mark Bakke (Cisco) will raise the question of a separate > experimental (or standards track) SLPv2 Configuration MIB during the > IETF IPS (IP Storage) WG session on Monday (18 March 2002) at IETF 53 > in Minneapolis (iSCSI uses SLPv2 for discovery and requires remote > configuration capabilities for SLPv2 DAs/SAs). > > Comments? > > Cheers, > - Ira McDonald (co-editor of SLP MIB) > High North Inc > imcdonald@sharplabs.com > > ------------------------------------------------------------------------ > > 14. Appendix X - Change Log > > [to be deleted before publication as an RFC] > > 1 March 2002 > - added Normative References section, per request of RFC Editor > - added Informative References section, per request of RFC Editor > - revised Abstract, Introduction, and Security Considerations to > state that the SLP MIB supports passive monitoring (but not > configuration), per concensus of SLP Project mailing list > - deleted Property group (last remaining 'read-write' objects), per > concensus of SLP Project mailing list > > ------------------------------------------------------------------------ > > Copies: "Internet Drafts Editor" > "Mark Bakke" > "Ira McDonald" > > I-D Editor, Friday (1 March 2002) > > Please place this updated document in the Internet-Drafts repository > named: > > (1 March 2002) > > It replaces the previous draft: > > (11 February 2002) > > Abstract > > This memo defines a portion of the Management Information Base (MIB) > for use with network management protocols in the Internet community. > In particular, it defines as set of managed objects that support > monitoring (but not configuration) of Service Location Protocol > Version 2 (SLPv2) [RFC2608] [RFC3111] directory agents (DAs), service > agents (SAs), and user agents (UAs). > > Thanks very much, > - Ira McDonald (co-editor of SLP MIB) > High North Inc > imcdonald@sharplabs.com > > ------------------------------------------------------------------------ > > _______________________________________________ > Srvloc-discuss mailing list > Srvloc-discuss@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/srvloc-discuss -- Mark A. Bakke Cisco Systems mbakke@cisco.com 763.398.1054 From owner-ips@ece.cmu.edu Wed Mar 20 17:49: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 RAA18117 for ; Wed, 20 Mar 2002 17:49:16 -0500 (EST) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id g2KM3f706544 for ips-outgoing; Wed, 20 Mar 2002 17:03:41 -0500 (EST) 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 g2KM3cw06539 for ; Wed, 20 Mar 2002 17:03:38 -0500 (EST) 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 g2KM3Uja019945 for ; Wed, 20 Mar 2002 14:03:30 -0800 (PST) Received: from cisco.com (58509@mbakke-lnx.cisco.com [161.44.68.87]) by nisser.cisco.com (8.8.6 (PHNE_14041)/CISCO.SERVER.1.2) with ESMTP id OAA24289 for ; Wed, 20 Mar 2002 14:03:14 -0800 (PST) Message-ID: <3C99036E.C8BB1C08@cisco.com> Date: Wed, 20 Mar 2002 15:47:26 -0600 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 Auth MIB: Address Family Type Request (22-23) Content-Type: multipart/mixed; boundary="------------756B6A3496F89B5CE79539B5" Sender: owner-ips@ece.cmu.edu Precedence: bulk This is a multi-part message in MIME format. --------------756B6A3496F89B5CE79539B5 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit We had requested that IANA add two new address family types for FC WWPNs and FC WWNNs for use within the authentication MIB, and perhaps within other FC-related MIBs. They (Michelle) responded very quickly (within a few days!) The assignments doc and MIBs have been updated. IANA wrote: > > Dear Mark, > > We have assigned the following IANA Address > Family Numbers with you as the point of contact: > > 22 Fibre Channel World-Wide Port Name [Bakke] > 23 Fibre Channel World-Wide Node Name [Bakke] > > [Bakke] Mark Bakke, , March 2002. > > > > and > > > > Please notify the IANA if there is a change in contact > information. > > Thank you, > > Michelle S. Cotton > IANA Administrator > > *************************************************************** > Internet Assigned Numbers Authority (IANA) > 4676 Admiralty Way, Suite 330 > Marina del Rey, California 90292 > > Voice: (310) 823-9358 > FAX: (310) 823-8649 > email: iana@iana.org > *************************************************************** -- Mark A. Bakke Cisco Systems mbakke@cisco.com 763.398.1054 --------------756B6A3496F89B5CE79539B5 Content-Type: message/rfc822 Content-Disposition: inline Return-Path: iana@icann.org Received: from sj-msg-core-4.cisco.com (sj-msg-core-4.cisco.com [171.71.163.10]) by dogwood.cisco.com (8.8.6 (PHNE_14041)/CISCO.SERVER.1.2) with ESMTP id NAA17976 for ; Thu, 14 Mar 2002 13:20:37 -0500 (EST) Received: from sj-msg-av-3.cisco.com (sj-msg-av-3.cisco.com [171.69.17.42]) by sj-msg-core-4.cisco.com (8.11.3/8.9.1) with ESMTP id g2EIKZT26068; Thu, 14 Mar 2002 10:20:36 -0800 (PST) Received: from proxy2.cisco.com (localhost [127.0.0.1]) by sj-msg-av-3.cisco.com (8.10.1/8.10.1) with ESMTP id g2EIKZw02535; Thu, 14 Mar 2002 10:20:35 -0800 (PST) Received: from mailhub.icann.org (mailhub.icann.org [192.0.34.33]) by proxy2.cisco.com (8.11.2/8.11.2) with ESMTP id g2EIKIw05040; Thu, 14 Mar 2002 10:20:18 -0800 (PST) Received: from tarim ([192.0.35.80]) by mailhub.icann.org (8.9.3/8.9.3) with SMTP id KAA32094; Thu, 14 Mar 2002 10:15:43 -0800 From: "IANA" To: Cc: "David Black" , "Elizabeth Rodriguez" , "Keith McCloghrie" Subject: RE: Address Family Type Request (22-23) Date: Thu, 14 Mar 2002 10:20:22 -0800 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0) X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2615.200 Importance: Normal In-Reply-To: <3C8F7558.8F24A53C@cisco.com> X-Mozilla-Status2: 00000000 Content-Transfer-Encoding: 7bit Dear Mark, We have assigned the following IANA Address Family Numbers with you as the point of contact: 22 Fibre Channel World-Wide Port Name [Bakke] 23 Fibre Channel World-Wide Node Name [Bakke] [Bakke] Mark Bakke, , March 2002. and Please notify the IANA if there is a change in contact information. Thank you, Michelle S. Cotton IANA Administrator *************************************************************** Internet Assigned Numbers Authority (IANA) 4676 Admiralty Way, Suite 330 Marina del Rey, California 90292 Voice: (310) 823-9358 FAX: (310) 823-8649 email: iana@iana.org *************************************************************** --------------756B6A3496F89B5CE79539B5-- From owner-ips@ece.cmu.edu Wed Mar 20 18:30: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 SAA18935 for ; Wed, 20 Mar 2002 18:30:02 -0500 (EST) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id g2KMlO809392 for ips-outgoing; Wed, 20 Mar 2002 17:47:24 -0500 (EST) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from erie.mcdata.com (mcjekyll.mcdata.com [144.49.6.25]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id g2KMlLw09388 for ; Wed, 20 Mar 2002 17:47:22 -0500 (EST) Received: by erie.mcdata.com with Internet Mail Service (5.5.2653.19) id ; Wed, 20 Mar 2002 15:47:16 -0700 Message-ID: <84540A7A9263854CBA6E6F99BA2CE4CE15CC41@380exu01.mcdata.com> From: Michel Maddux To: "'Julian Satran'" , "'ips@ece.cmu.edu'" Subject: RE: Date: Wed, 20 Mar 2002 15:47:15 -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 two dots (..) seems clear - you've got my vote. /m. -----Original Message----- From: Julian Satran [mailto:Julian_Satran@il.ibm.com] Sent: Wednesday, March 20, 2002 10:05 AM To: ips@ece.cmu.edu Subject: Dear colleagues, I suggested using : (colon) to separate values in a range. Unfortunately : is overused (in addresses and in names). I suggest we use the (old) two dots (..) to mark a range. Comments? Julo From owner-ips@ece.cmu.edu Wed Mar 20 18:33: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 SAA19023 for ; Wed, 20 Mar 2002 18:33:19 -0500 (EST) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id g2KNB4T10853 for ips-outgoing; Wed, 20 Mar 2002 18:11:04 -0500 (EST) 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 g2KNB1w10847; Wed, 20 Mar 2002 18:11:01 -0500 (EST) Received: from d12relay01.de.ibm.com (d12relay01.de.ibm.com [9.165.215.22]) by d12lmsgate-2.de.ibm.com (1.0.0) with ESMTP id AAA30088; Thu, 21 Mar 2002 00:10:54 +0100 Received: from d10hubm1.telaviv.ibm.com (d10ml001.telaviv.ibm.com [9.148.216.55]) by d12relay01.de.ibm.com (8.11.1m3/NCO/VER6.00) with ESMTP id g2KNArG87682; Thu, 21 Mar 2002 00:10:54 +0100 To: Martins Krikis Cc: ips@ece.cmu.edu, owner-ips@ece.cmu.edu Importance: High MIME-Version: 1.0 Subject: Re: ExpDataSN overload X-Mailer: Lotus Notes Release 5.0.9 November 16, 2001 From: "Julian Satran" Message-ID: Date: Thu, 21 Mar 2002 01:10:53 +0200 X-MIMETrack: Serialize by Router on D10ML001/10/M/IBM(Release 5.0.9a |January 7, 2002) at 21/03/2002 01:10:52, Serialize complete at 21/03/2002 01:10:52 Content-Type: multipart/alternative; boundary="=_alternative 007EBE63C2256B82_=" Sender: owner-ips@ece.cmu.edu Precedence: bulk This is a multipart message in MIME format. --=_alternative 007EBE63C2256B82_= Content-Type: text/plain; charset="us-ascii" It has popped now to the top of my stack - comments in text _ Julo Martins Krikis Sent by: owner-ips@ece.cmu.edu 13-03-02 01:37 Please respond to Martins Krikis To: ips@ece.cmu.edu cc: Subject: ExpDataSN overload Dear list members, I've just noticed that ExpDataSN is used to denote a lot of different things (all references w.r.t. to draft 11): 1) the total number of Data-In PDUs that a target has sent to complete a SCSI (read-like) command (2.5.1.2, 9.4.7, 6.6, E.9.2); 2) next concecutive input DataSN number expected by the initiator for the referenced command in previous execution, used in TASK REASSIGN (6.1.2, 9.5.4); 3) internal target variable used to track the next DataSN Expected from the initator or something like that (6.2). Regarding use 1: this is the most widespread, and there is nothing to object, except perhaps that the name ExpDataSN doesn't convey the exact meaning--- "TotalDataPDUs" or "NumDataPDUs" or something like that. Anyway, I can live with this. +++ It coveys the name of register it copies into the PDU - +++ Regarding use 2: the name conveys the meaning, but I don't like the wording of this spot in 6.1.2: "... for example taking advantage of ExpDataSN in the iSCSI command PDU for read commands...". The problem is that "read commands" don't have ExpDataSN in the PDU, it's the "Task Management Function Request" PDUs that do. Task Management Function Request PDUs are, of course, "iSCSI command PDUs", but the whole thing makes it too easy to make the mistake of remembering (the ill-named) ExpDataSN field in SCSI Response PDU, at which point nothing makes sense anymore, because that's the other meaning of ExpDataSN. I would appreciate if somebody could rephrase the sentence. I'll even volunteer: "In reassigning connection allegiance for a command, the targets SHOULD continue the command from its current state. For example, when reassigning read commands, the targets SHOULD take advantage of the ExpDataSN field provided by the Task Management Function Request PDU (which must be set to zero if there was no data transfer) and bring the command to completion by sending (or resending) the status." +++ I'll fix the wording +++ Regarding use 3: I don't understand this. The last two sentences of 6.2 seem to be talking about Data-Out PDUs, therefore uses 1 and 2 of ExpDataSN (that are both Data-In PDU related) don't apply here. I'm concluding that these sentences are making some (unwelcome) assumptions about target implementation details (e.g., ExpDataSN in the role of a variable used to track the DataSN of the next Data-Out PDU that a target expects to receive for this command). If so, I would like such assumptions dropped and no MUSTs (and MAYs) imposed on a target implementation. If I'm wrong, somebody please explain to me what was meant here. +++ will fix text +++ "Bonus" :-) problem: While we're at 6.1.2, the start of the 3rd paragraph also got me thinking and browsing the draft for quite a while. I don't like the "This is true even when the CmdSN can be reliably ascertained..." phrase. The problem is, I don't see how it could not be reliably determined for rejected PDUs. My thinking is that the only way to not be able to reliably determine CmdSN is in the case of header digest errors. +++ Yes +++ But in this case, the PDU must be silently dropped, and not be answered with a Reject PDU. Am I wrong somewhere? If not, can we change the sentence I mentioned to something that explains that for rejected PDUs, the target will necessarily have a good CmdSN, but still must not use it"? +++ because there was a feeling that retrying the whole PDU (even if only the immediate data failed was a simpler option +++ Help on these issues will be much appreciated. Martins Krikis, Intel Corp. Disclaimer: These opinions are mine only and may not reflect those of my employer. __________________________________________________ Do You Yahoo!? Try FREE Yahoo! Mail - the world's greatest free email! http://mail.yahoo.com/ --=_alternative 007EBE63C2256B82_= Content-Type: text/html; charset="us-ascii"
It has popped now to the top of my stack - comments in text _ Julo

Martins Krikis <mkrikis@yahoo.com>
Sent by: owner-ips@ece.cmu.edu

13-03-02 01:37
Please respond to Martins Krikis

To: ips@ece.cmu.edu
cc:
Subject: ExpDataSN overload

Dear list members,

I've just noticed that ExpDataSN is used to denote
a lot of different things (all references w.r.t.
to draft 11):

1) the total number of Data-In PDUs that a target
has sent to complete a SCSI (read-like) command
(2.5.1.2, 9.4.7, 6.6, E.9.2);

2) next concecutive input DataSN number expected by
the initiator for the referenced command in
previous
execution, used in TASK REASSIGN
(6.1.2, 9.5.4);

3) internal target variable used to track the next
DataSN Expected from the initator or something
like that
(6.2).

Regarding use 1: this is the most widespread, and
there is nothing to object, except perhaps that the
name ExpDataSN doesn't convey the exact meaning---
"TotalDataPDUs" or "NumDataPDUs" or something like
that. Anyway, I can live with this.

+++ It coveys the name of register it copies into the PDU - +++

Regarding use 2: the name conveys the meaning, but
I don't like the wording of this spot in 6.1.2:
"... for example taking advantage of ExpDataSN in
the iSCSI command PDU for read commands...". The
problem is that "read commands" don't have ExpDataSN
in the PDU, it's the "Task Management Function
Request"
PDUs that do. Task Management Function Request PDUs
are, of course, "iSCSI command PDUs", but the whole
thing makes it too easy to make the mistake of
remembering (the ill-named) ExpDataSN field in
SCSI Response PDU, at which point nothing makes sense
anymore, because that's the other meaning of
ExpDataSN.
I would appreciate if somebody could rephrase the
sentence. I'll even volunteer:

"In reassigning connection allegiance for a command,
the targets SHOULD continue the command from its
current state. For example, when reassigning read
commands, the targets SHOULD take advantage of the
ExpDataSN field provided by the Task Management
Function Request PDU (which must be set to zero
if there was no data transfer) and bring the command
to completion by sending (or resending) the status."
+++ I'll fix the wording +++
Regarding use 3: I don't understand this. The last
two sentences of 6.2 seem to be talking about
Data-Out PDUs, therefore uses 1 and 2 of ExpDataSN
(that are both Data-In PDU related) don't apply
here. I'm concluding that these sentences are
making some (unwelcome) assumptions about target
implementation details (e.g., ExpDataSN in the role
of a variable used to track the DataSN of the next
Data-Out PDU that a target expects to receive for
this command). If so, I would like such assumptions
dropped and no MUSTs (and MAYs) imposed on a target
implementation. If I'm wrong, somebody please explain
to me what was meant here.
+++ will fix text +++
"Bonus" :-) problem:

While we're at 6.1.2, the start of the 3rd paragraph
also got me thinking and browsing the draft for
quite a while. I don't like the "This is true even
when the CmdSN can be reliably ascertained..."
phrase. The problem is, I don't see how it could not
be reliably determined for rejected PDUs. My thinking
is that the only way to not be able to reliably
determine CmdSN is in the case of header digest
errors. +++ Yes +++
But in this case, the PDU must be silently dropped,
and not be answered with a Reject PDU. Am I wrong
somewhere? If not, can we change the sentence I
mentioned to something that explains that for rejected
PDUs, the target will necessarily have a good CmdSN,
but still must not use it"?
+++ because there was a feeling that retrying the whole PDU (even if only the immediate data failed was a simpler option +++

Help on these issues will be much appreciated.

Martins Krikis, Intel Corp.

Disclaimer: These opinions are mine only and
may not reflect those of my employer.

__________________________________________________
Do You Yahoo!?
Try FREE Yahoo! Mail - the world's greatest free email!
http://mail.yahoo.com/

--=_alternative 007EBE63C2256B82_=-- From owner-ips@ece.cmu.edu Wed Mar 20 19:48: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 TAA20367 for ; Wed, 20 Mar 2002 19:48:34 -0500 (EST) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id g2L059K14190 for ips-outgoing; Wed, 20 Mar 2002 19:05:09 -0500 (EST) 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 g2L056w14184 for ; Wed, 20 Mar 2002 19:05:06 -0500 (EST) 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 QAA28134; Wed, 20 Mar 2002 16:04:25 -0800 (PST) From: "Rod Harrison" To: "Julian Satran" , Subject: RE: Date: Thu, 21 Mar 2002 00:04:51 -0000 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: Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2314.1300 Sender: owner-ips@ece.cmu.edu Precedence: bulk Content-Transfer-Encoding: 7bit I would prefer one character. I don't care what it is, any character will do, but having only one there is slightly easier to parse that having two. - Rod -----Original Message----- From: owner-ips@ece.cmu.edu [mailto:owner-ips@ece.cmu.edu]On Behalf Of Julian Satran Sent: Wednesday, March 20, 2002 5:05 PM To: ips@ece.cmu.edu Subject: Dear colleagues, I suggested using : (colon) to separate values in a range. Unfortunately : is overused (in addresses and in names). I suggest we use the (old) two dots (..) to mark a range. Comments? Julo From owner-ips@ece.cmu.edu Wed Mar 20 19:49: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 TAA20386 for ; Wed, 20 Mar 2002 19:49:26 -0500 (EST) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id g2L0MEJ15210 for ips-outgoing; Wed, 20 Mar 2002 19:22:14 -0500 (EST) 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 g2L0MBw15201 for ; Wed, 20 Mar 2002 19:22:11 -0500 (EST) Received: from hpcuhe.cup.hp.com (hpcuhe.cup.hp.com [15.0.80.203]) by palrel11.hp.com (Postfix) with ESMTP id D0C03600953; Wed, 20 Mar 2002 16:22:05 -0800 (PST) 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 QAA05600; Wed, 20 Mar 2002 16:21:59 -0800 (PST) Message-ID: <3C9928AC.9708B6B9@cup.hp.com> Date: Wed, 20 Mar 2002 16:26:20 -0800 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: Michael Schoberg Cc: "IPS Reflector (E-mail)" Subject: Re: iSCSI: Rev 11 minor issues References: <3C7122FAF06DD5118ED60050047336482631E1@esply01.cnt.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, I don't believe the individual connections that comprise a session can use different iscsi initiator names. The initiator name is intended to be the node name of that initiator. A session cannot span multiple nodes. Also, there is a one to one correspondence b/n an I-T nexus and an iscsi session. Hence, the following does'nt seem quite right to me : > Each login requires the InitiatorName because although > it may be an additional connection to an existing session, > it may not be for the same I_T nexus. and, since a session can't involve multiple initiator names, this does'nt seem right either : > ------------------------------------------------------------------------- > InitiatorName ISID CID TSID TgtName Session I_T Nexus > a1 Fred 010203040506 0000 0001 idisk * #1 it-1 > a2 Bob 010203040506 0001 0001 idisk #1 it-2 > a3 Joe 010203040506 0002 0001 idisk #1 it-3 > a4 Fred 010203040506 0003 0001 idisk #1 it-1 In the above example, if Fred, Bob & Joe belong to a single node, then, they need to use a single iscsi initiator name, and only then, can they share a session. Thanks, Santosh Julian, Thanks for the follow-up. Forgive me for being slow with this, but I'm still confused by your statement. Let me walk you through some of my thoughts. An initiator is defined to be an "initiator node". It's identification is through the initiator port name, which includes the InitiatorName, ISID, etc. Each login requires the InitiatorName because although it may be an additional connection to an existing session, it may not be for the same I_T nexus. Initiators are added to a session like this: ------------------------------------------------------------------------- InitiatorName ISID CID TSID TgtName Session I_T Nexus a1 Fred 010203040506 0000 0001 idisk * #1 it-1 a2 Bob 010203040506 0001 0001 idisk #1 it-2 a3 Joe 010203040506 0002 0001 idisk #1 it-3 a4 Fred 010203040506 0003 0001 idisk #1 it-1 a5 Ted 010203040506 0000 0001 idisk * #2 it-4 a6 Fred 010203040506 0000 0001 idisk * ?? a7 Ted 010203040506 0004 0001 idisk ?? a8 Ted 010203040506 0001 0001 idisk ?? * Leading login TSID=0000 was sent by initiator, TSID value assigned by target. ------------------------------------------------------------------------- Within any single session there will be one or more I_T nexus formed (see a1, a2, a3, a4). ISID RULE: Between a given iSCSI Initiator and iSCSI Target Portal Group (SCSI target port), there can be only one session with a given value for ISID that identifies the SCSI initiator port. See Section 9.12.5 ISID. My interpretation: any initiator's attempt to reuse the same ISID for creating an additional session (TSID = 0000) with the same target-portal-group breaks the ISID rule; initiators must provide different ISID values to create new sessions with the same target-portal-group (see a6, breaks ISID rule). However, since the "initiator port identifier" includes InitiatorName, alternate initiators may simultaneously use the same ISID value (see a5, does not break ISID rule). TSID RULE: The iSCSI Target SHOULD NOT select a TSID for a given login request if the resulting SSID is already in use by an existing session between the target and the requesting iSCSI Initiator. See Section 8.1.1 Conservative Reuse of ISIDs. My interpretation: a target should expect (and accept) initiator attempts to login with the same ISID and can select the same TSID as long it's from a different initiator (see a5). However, if an existing initiator is identified, then the target should select a TSID that forms a unique SSID (see b4). This is confusing because it assumes that the initiator will break the ISID rule? Also, does this break session reinstatement? ------------------------------------------------------------------------- InitiatorName ISID CID TSID TargetName Session b1 Fred 010203040506 0000 0001 idisk * #1 b2 Bob 010203040506 0000 0001 idisk * #2 b3 Joe 010203040506 0000 0001 idisk * #3 b4 Fred 010203040506 0000 0002 idisk * #4 * Leading login TSID=0000 was sent by initiator, TSID value assigned by target. ------------------------------------------------------------------------- How does this work with 4.3.5 Session Reinstatement: Session reinstatement is the process of initiator logging in with an ISID that is possibly active from the target's perspective - thus implicitly logging out the session state machine corresponding to the ISID and reinstating a new iSCSI session in its place (with the same ISID). Thus, the TSID in the Login PDU MUST be zero to signal session reinstatement. All the tasks that were active on the old session are internally terminated on a session reinstatement. The initiator session state MUST be FAILED (Section 5.3 Session State Diagrams) for attempting a session reinstatement. My interpretation (#1 of 2): Session reinstatement only occurs when the target has identified and authenticated that an existing initiator (identified by InitiatorName & ISID) has performed a second leading login. Then and only then can session reinstatement be performed. Unfortunately, this assumes that sessions will always have the same initiator performing the leading login (so in a1->a4, only Fred can perform session reinstatement for that session.) That's bad news if that particular initiator is no longer active. (#2 of 2): ANY leading login received by the iSCSI target with an existing and target-perspective active ISID is assumed to be session reinstatement. This means that the logins described by [ a5 & b1..b4 ] are invalid. Further, this conflicts with your note saying that the initiator must be completely identified on every login. Now look at connection reinstatement (4.3.4) Connection reinstatement is the process of initiator logging in with a ISID-TSID-CID combination that is possibly active from the target's perspective - thus implicitly logging out the connection state machine corresponding to the CID and reinstating a new full-feature phase iSCSI connection in its place (with the same CID). Thus, the TSID in the Login PDU MUST be non-zero and CID does not change during a connection reinstatement. The Login command performs the logout function of the old connection if an explicit logout was not performed earlier. In sessions with a single connection, this may imply the opening of a second connection with the sole purpose of cleaning up the first. Targets should support opening a second connection even when they do not support multiple connections in full feature phase. If the operational ErrorRecoveryLevel is 2, connection reinstatement enables future task reassignment. If the operational ErrorRecovery- Level is less than 2, connection reinstatement is the replacement of the old CID without enabling task reassignment. In this case, all the tasks that were active on the old CID are internally terminated. The initiator connection state MUST be CLEANUP_WAIT (section 5.1) for attempting a connection reinstatement. If an iSCSI connection is attempted in which multiple initiator-sessions are available with the same ISID + TSID, to which session should the iSCSI target attach it? In [a7] above, there are two active sessions with the same SSID, to which should a7 be attached? Another special case [a8] will result in either a new connection on session #2 or connection reinstatement (or possible conflict) with session #1. Thanks for your time on this! -- ################################## Santosh Rao Software Design Engineer, HP-UX iSCSI Driver Team, Hewlett Packard, Cupertino. email : santoshr@cup.hp.com Phone : 408-447-3751 ################################## From owner-ips@ece.cmu.edu Wed Mar 20 20:05: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 UAA20581 for ; Wed, 20 Mar 2002 20:05:19 -0500 (EST) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id g2L0Fx214851 for ips-outgoing; Wed, 20 Mar 2002 19:15:59 -0500 (EST) 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 g2L0Fkw14837 for ; Wed, 20 Mar 2002 19:15:47 -0500 (EST) Received: from hpcuhe.cup.hp.com (hpcuhe.cup.hp.com [15.0.80.203]) by palrel10.hp.com (Postfix) with ESMTP id 6566CC00172; Wed, 20 Mar 2002 16:15:39 -0800 (PST) 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 QAA04790; Wed, 20 Mar 2002 16:15:33 -0800 (PST) Message-ID: <3C99272B.B78D3BE7@cup.hp.com> Date: Wed, 20 Mar 2002 16:19:55 -0800 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: Dave Peterson Cc: "Ips@Ece. Cmu. Edu" Subject: Re: iSCSI: items discussed at WG meeting References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ips@ece.cmu.edu Precedence: bulk Content-Transfer-Encoding: 7bit Dave, Some queries inline. Regards, Santosh Dave Peterson wrote: > 4. Clause 6.7 SCSI Timeouts: explicitly state that a command retry shouldn't > be performed after a SCSI level timeout. > > "An iSCSI initiator MAY attempt to plug a command sequence gap on the target > end (in the absence of an acknowledgement of the command by way of ExpCmdSN) > before the ULP timeout by retrying the unacknowledged command, as described > in Section 6.1 Retry and Reassign in Recovery." Why would a scsi transport protocol be required to specify this ? Since a ULP timeout is O.S. specific and is not an externally observable value, either on the wire, or communicated to the target, why should iscsi specify this ? Different O.S. drivers may apply different timeout policies, with some drivers allowing for some grace time to attempt to complete the I/O after a timeout. IMO, the iscsi spec can be silent on what an O.S. specific driver does when its O.S. specific ULP timeout expires. This is O.S. dependent. > 6. Text stating that a TMF=Abort Task must be issued for each outstanding > command. (Clause 6.7) What does this mean (?). Could you elaborate further on this. 6.7 defines what action should be taken by an initiator on a SCSI timeout, which occurs on a per-command basis and is dealt with individually for each command. Where do the remaining outstanding commands come into the picture, unless, you're proposing that something like the FC second level error recovery be performed, on failure of the abort (?). > > 7. Targets MUST support the command retry functionality. Don't think this > functionality provides much benefit in its current state. > Consider this case: > a. tape locate command is issued with a 10 second ULP timer > b. command is dropped at the target due to a digest error > c. having seen no status for 8 seconds (for example) the iSCSI initiator > decides to retry the command. > > What happens with the timer on the first command? If it is not canceled, and > if status is not received within 2 seconds, an abort for the command will be > issued by the ULP. Agreed. This is an issue in some cases, since not enough I/O time would be available for the retry. However, the selection of the initial command retry timeout value (when the initiator determines that the cmdsn has not been acknowledged for a long enough period and decides to retry the command) and the decision on whether to retry should be taken by the initiator driver, based on how much ULP time remains for that I/O. (Again, this logic is mostly O.S. driver specific.) > > dap: a mechanism to initiate error detection/recovery would be beneficial. Could you expand on this some more ? > > 8. CRN Processing and behavior: spec currently references SAM-2 for CRN. > > Per SAM-2: > Command Reference Number (CRN): > When this argument is used, all sequential commands of an I_T_L nexus shall > include a CRN argument that is incremented by one. The initial, wrap, and > reset CRN values shall be one. The CRN value zero shall be reserved for use > as defined by the SCSI protocol. It is not an error for the application > client to provide this argument when CRN is not supported by the SCSI > protocol or logical unit. > > More text specifying the behavior of CRN in the iSCSI realm is needed. In > addition, a method to determine if CRN is being used (or not) is missing. We went through this discussion several months ago in another ips thread. CRN really belongs to the SCSI ULP and any mechanism to check if the device server supports CRN should be in a SCSI ULP mode page (like the Control Mode Page). As far as iscsi is concerned, both the iscsi initiator and target implementations MUST support CRN, since it is defined in iscsi command pdu. Why is such a method required at the SCSI LLP layer ? -- ################################## Santosh Rao Software Design Engineer, HP-UX iSCSI Driver Team, Hewlett Packard, Cupertino. email : santoshr@cup.hp.com Phone : 408-447-3751 ################################## From owner-ips@ece.cmu.edu Thu Mar 21 00:14: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 AAA26550 for ; Thu, 21 Mar 2002 00:14:06 -0500 (EST) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id g2L4T2A27756 for ips-outgoing; Wed, 20 Mar 2002 23:29:02 -0500 (EST) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from siaar2ab.compuserve.com (siaar2ab.compuserve.com [149.174.40.138]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id g2L4Sxw27749 for ; Wed, 20 Mar 2002 23:28:59 -0500 (EST) Received: (from mailgate@localhost) by siaar2ab.compuserve.com (8.9.3/8.9.3/SUN-REL-1.3) id XAA10959 for ips@ece.cmu.edu; Wed, 20 Mar 2002 23:28:53 -0500 (EST) Received: from compuserve.com (dal-tgn-tkk-vty41.as.wcom.net [206.175.239.41]) by siaar2ab.compuserve.com (8.9.3/8.9.3/SUN-REL-1.3) with ESMTP id XAA10940 for ; Wed, 20 Mar 2002 23:28:45 -0500 (EST) Message-ID: <3C9962F1.27A3FC95@compuserve.com> Date: Wed, 20 Mar 2002 22:34:57 -0600 From: Ralph Weber Reply-To: roweber@acm.org X-Mailer: Mozilla 4.7 [en]C-CCK-MCD NSCPCD47 (Win95; I) X-Accept-Language: en,pdf MIME-Version: 1.0 To: IPS Reflector Subject: Bit numbering I-D nit Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ips@ece.cmu.edu Precedence: bulk Content-Transfer-Encoding: 7bit I am getting serious flack from the Fibre Channel community over the bit numbering requirement in http://www.ietf.org/ID-nits.html. The problem is that Fibre Channel uses the other bit numbering scheme and interoperability woes seem certain unless something gets documented in the IETF RFCs. Everybody agrees that the body of the FC Frame Encapsulation and FCIP drafts can have the IETF bit numbering in the figures. What they all want is an appendix, or some such thing in the drafts/RFCs that translates it all back to the Fibre Channel view of reality. Such a thing seems destined to make waves in the IETF review process, and possibly even be a target for the RFC Editor's ax. Should I just jump of the top of the Hilton now, or is there a way out of this mess? Thanks. Ralph... From owner-ips@ece.cmu.edu Thu Mar 21 02:42: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 CAA06325 for ; Thu, 21 Mar 2002 02:42:32 -0500 (EST) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id g2L6r6a04828 for ips-outgoing; Thu, 21 Mar 2002 01:53:06 -0500 (EST) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from fep03-mail.bloor.is.net.cable.rogers.com (fep03-mail.bloor.is.net.cable.rogers.com [66.185.86.73]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id g2L6r4w04823 for ; Thu, 21 Mar 2002 01:53:05 -0500 (EST) Received: from splentec.com ([24.43.3.134]) by fep03-mail.bloor.is.net.cable.rogers.com (InterMail vM.5.01.04.06 201-253-122-122-106-20020109) with ESMTP id <20020321065300.BJXG4474.fep03-mail.bloor.is.net.cable.rogers.com@splentec.com>; Thu, 21 Mar 2002 01:53:00 -0500 Message-ID: <3C998343.6080305@splentec.com> Date: Thu, 21 Mar 2002 01:52:51 -0500 From: Luben Tuikov Reply-To: iSCSI , luben@splentec.com Organization: Splentec Ltd. User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:0.9.4) Gecko/20011126 Netscape6/6.2.1 X-Accept-Language: en-us MIME-Version: 1.0 To: Rod Harrison CC: Julian Satran , ips@ece.cmu.edu Subject: Re: References: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Authentication-Info: Submitted using SMTP AUTH PLAIN at fep03-mail.bloor.is.net.cable.rogers.com from [24.43.3.134] using ID at Thu, 21 Mar 2002 01:53:00 -0500 Sender: owner-ips@ece.cmu.edu Precedence: bulk Content-Transfer-Encoding: 7bit Rod Harrison wrote: > I would prefer one character. I don't care what it is, any character > will do, but having only one there is slightly easier to parse that > having two. I strongly agree. A single character, anyone indeed. Maybe a dash/minus ``-'' (0x2d). I don't think we'd ever need to pass arithmetic expressions, so a minus would do... -- Luben From owner-ips@ece.cmu.edu Thu Mar 21 08:24: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 IAA10121 for ; Thu, 21 Mar 2002 08:24:11 -0500 (EST) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id g2LCddg29588 for ips-outgoing; Thu, 21 Mar 2002 07:39:39 -0500 (EST) 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 g2LCdbw29584 for ; Thu, 21 Mar 2002 07:39:38 -0500 (EST) Received: by ATLOPS with Internet Mail Service (5.5.2653.19) id ; Thu, 21 Mar 2002 07:39:22 -0500 Message-ID: <25369470B6F0D41194820002B328BDD22F589A@ATLOPS> From: Eddy Quicksall To: iSCSI , luben@splentec.com, Rod Harrison Cc: Julian Satran Subject: RE: Date: Thu, 21 Mar 2002 07:39:20 -0500 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 A dash is also used for negative numbers (we don't have any yet but could in the future). It doesn't look cool but how about the semi-colon? Eddy -----Original Message----- From: Luben Tuikov [mailto:luben@splentec.com] Sent: Thursday, March 21, 2002 1:53 AM To: Rod Harrison Cc: Julian Satran; ips@ece.cmu.edu Subject: Re: Rod Harrison wrote: > I would prefer one character. I don't care what it is, any character > will do, but having only one there is slightly easier to parse that > having two. I strongly agree. A single character, anyone indeed. Maybe a dash/minus ``-'' (0x2d). I don't think we'd ever need to pass arithmetic expressions, so a minus would do... -- Luben From owner-ips@ece.cmu.edu Thu Mar 21 11: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 LAA14618 for ; Thu, 21 Mar 2002 11:00:24 -0500 (EST) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id g2LFa9a09988 for ips-outgoing; Thu, 21 Mar 2002 10:36:09 -0500 (EST) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from erie.mcdata.com (mcjekyll.mcdata.com [144.49.6.25]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id g2LFa7w09984 for ; Thu, 21 Mar 2002 10:36:07 -0500 (EST) Received: by erie.mcdata.com with Internet Mail Service (5.5.2653.19) id ; Thu, 21 Mar 2002 08:35:58 -0700 Message-ID: <84540A7A9263854CBA6E6F99BA2CE4CE15CC44@380exu01.mcdata.com> From: Michel Maddux To: "'iSCSI'" , "'luben@splentec.com'" , Rod Harrison Cc: Julian Satran Subject: RE: Date: Thu, 21 Mar 2002 08:35:50 -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 I disagree; a range of values has long been denoted by (..) ASCII being limited, using a minus (-) sign will get into character overloading and ambiguity. thanks ./m. -----Original Message----- From: Luben Tuikov [mailto:luben@splentec.com] Sent: Wednesday, March 20, 2002 11:53 PM To: Rod Harrison Cc: Julian Satran; ips@ece.cmu.edu Subject: Re: Rod Harrison wrote: > I would prefer one character. I don't care what it is, any character > will do, but having only one there is slightly easier to parse that > having two. I strongly agree. A single character, anyone indeed. Maybe a dash/minus ``-'' (0x2d). I don't think we'd ever need to pass arithmetic expressions, so a minus would do... -- Luben From owner-ips@ece.cmu.edu Thu Mar 21 11:00: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 LAA14639 for ; Thu, 21 Mar 2002 11:00:42 -0500 (EST) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id g2LF8Bb08183 for ips-outgoing; Thu, 21 Mar 2002 10:08:11 -0500 (EST) 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 g2LF86w08177 for ; Thu, 21 Mar 2002 10:08:07 -0500 (EST) Received: from cygnus.equallogic.com (localhost.localdomain [127.0.0.1]) by cygnus.equallogic.com (8.11.6/8.11.6) with ESMTP id g2LF7u004754 for ; Thu, 21 Mar 2002 10:07:56 -0500 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 g2LF7sK04745; Thu, 21 Mar 2002 10:07:54 -0500 Received: from pkoning.dev.equallogic.com.equallogic.com (localhost.localdomain [127.0.0.1]) by deneb.dev.equallogic.com (8.11.6/8.11.2) with SMTP id g2LF7s315523; Thu, 21 Mar 2002 10:07:54 -0500 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <15513.63306.446436.598026@pkoning.dev.equallogic.com> Date: Thu, 21 Mar 2002 10:07:54 -0500 From: Paul Koning To: rod.harrison@windriver.com Cc: ips@ece.cmu.edu Subject: RE: 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 >>>>> "Rod" == Rod Harrison writes: Rod> I would prefer one character. I don't care what it is, any Rod> character will do, but having only one there is slightly easier Rod> to parse that having two. I agree. Colon will serve fine, unless we expect to have IPv6 address ranges in login negotiations at some point. Dash should work fine too. But no double-character tokens, please. paul From owner-ips@ece.cmu.edu Thu Mar 21 11:01: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 LAA14675 for ; Thu, 21 Mar 2002 11:01:08 -0500 (EST) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id g2LFeuJ10262 for ips-outgoing; Thu, 21 Mar 2002 10:40:56 -0500 (EST) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from mononoke.wasabisystems.com (lion.ninthwonder.com [151.199.66.147]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id g2LFeqw10254 for ; Thu, 21 Mar 2002 10:40:52 -0500 (EST) Received: by mononoke.wasabisystems.com (Postfix, from userid 1021) id 7A8C530715; Thu, 21 Mar 2002 10:40:48 -0500 (EST) Date: Thu, 21 Mar 2002 07:36:31 -0800 (PST) From: Bill Studenmund X-X-Sender: To: Eddy Quicksall Cc: iSCSI , , Rod Harrison , Julian Satran Subject: RE: In-Reply-To: <25369470B6F0D41194820002B328BDD22F589A@ATLOPS> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ips@ece.cmu.edu Precedence: bulk On Thu, 21 Mar 2002, Eddy Quicksall wrote: > A dash is also used for negative numbers (we don't have any yet but could in > the future). True, but is that a concern here? For a range, you have to have two numbers with the dash/minus between them. "-number" would not be a valid range. So even if we ever get negative numbers, ranges should be readily different. The only point of confusion would be if we ever permitted algebraic expressions, when the '-' would look like subtraction. But I think that would neither be sensible nor likely. Take care, Bill From owner-ips@ece.cmu.edu Thu Mar 21 11:23: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 LAA15668 for ; Thu, 21 Mar 2002 11:23:23 -0500 (EST) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id g2LFium10534 for ips-outgoing; Thu, 21 Mar 2002 10:44:56 -0500 (EST) 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 g2LFisw10526 for ; Thu, 21 Mar 2002 10:44:54 -0500 (EST) Received: by ATLOPS with Internet Mail Service (5.5.2653.19) id ; Thu, 21 Mar 2002 10:44:53 -0500 Message-ID: <25369470B6F0D41194820002B328BDD22F58A9@ATLOPS> From: Eddy Quicksall To: Bill Studenmund , Eddy Quicksall Cc: iSCSI , luben@splentec.com, Rod Harrison , Julian Satran Subject: RE: Date: Thu, 21 Mar 2002 10:44:45 -0500 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 That would be ok for something like an expression parser but our parser should be very simple minded and it is better if it is not context sensitive. It is the same idea as "don't use two characters". Also, the "looks" of it is not very important. Eddy -----Original Message----- From: Bill Studenmund [mailto:wrstuden@wasabisystems.com] Sent: Thursday, March 21, 2002 10:37 AM To: Eddy Quicksall Cc: iSCSI; luben@splentec.com; Rod Harrison; Julian Satran Subject: RE: On Thu, 21 Mar 2002, Eddy Quicksall wrote: > A dash is also used for negative numbers (we don't have any yet but could in > the future). True, but is that a concern here? For a range, you have to have two numbers with the dash/minus between them. "-number" would not be a valid range. So even if we ever get negative numbers, ranges should be readily different. The only point of confusion would be if we ever permitted algebraic expressions, when the '-' would look like subtraction. But I think that would neither be sensible nor likely. Take care, Bill From owner-ips@ece.cmu.edu Thu Mar 21 11:36: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 LAA16082 for ; Thu, 21 Mar 2002 11:36:25 -0500 (EST) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id g2LG4Jf12075 for ips-outgoing; Thu, 21 Mar 2002 11:04:19 -0500 (EST) 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 g2LG4Ew12068 for ; Thu, 21 Mar 2002 11:04:15 -0500 (EST) Received: from cygnus.equallogic.com (localhost.localdomain [127.0.0.1]) by cygnus.equallogic.com (8.11.6/8.11.6) with ESMTP id g2LG45005312 for ; Thu, 21 Mar 2002 11:04:05 -0500 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 g2LG45K05303; Thu, 21 Mar 2002 11:04:05 -0500 Received: from pkoning.dev.equallogic.com.equallogic.com (localhost.localdomain [127.0.0.1]) by deneb.dev.equallogic.com (8.11.6/8.11.2) with SMTP id g2LG44F18182; Thu, 21 Mar 2002 11:04:04 -0500 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <15514.1140.622421.720310@pkoning.dev.equallogic.com> Date: Thu, 21 Mar 2002 11:04:04 -0500 From: Paul Koning To: roweber@acm.org Cc: ips@ece.cmu.edu Subject: Re: Bit numbering I-D nit References: <3C9962F1.27A3FC95@compuserve.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 >>>>> "Ralph" == Ralph Weber writes: Ralph> I am getting serious flack from the Fibre Channel community Ralph> over the bit numbering requirement in Ralph> http://www.ietf.org/ID-nits.html. I can see why... I didn't realize that the requirement is for the confusing old IMB-360 style bit ordering rather than the "powers of two" bit ordering that's generally used. Yuck. Ralph> The problem is that Fibre Channel uses the other bit numbering Ralph> scheme and interoperability woes seem certain unless something Ralph> gets documented in the IETF RFCs. Ralph> Everybody agrees that the body of the FC Frame Encapsulation Ralph> and FCIP drafts can have the IETF bit numbering in the Ralph> figures. Ralph> What they all want is an appendix, or some such thing in the Ralph> drafts/RFCs that translates it all back to the Fibre Channel Ralph> view of reality. Ralph> Such a thing seems destined to make waves in the IETF review Ralph> process, and possibly even be a target for the RFC Editor's Ralph> ax. I would say an appendix that documents the mapping to other standards is the right thing. If that gives the RFC editor and/or IESG heartburn, it's worth a battle. Bit order is far too important an interop issue to be left undiscussed, and if bureaucratic rules stand in the way, those rules MUST change. If those sound like strong words, so be it. I've been burned far too many times by bit order confusion to take this sort of thing lightly. If there exist two conventions in the community, it's mandatory to document that explicitly and clearly state the mapping between the two notations, or things will never work. paul From owner-ips@ece.cmu.edu Thu Mar 21 11: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 LAA16202 for ; Thu, 21 Mar 2002 11:39:28 -0500 (EST) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id g2LG4vg12128 for ips-outgoing; Thu, 21 Mar 2002 11:04:57 -0500 (EST) 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 g2LG4tw12122 for ; Thu, 21 Mar 2002 11:04:55 -0500 (EST) Received: from westrelay02.boulder.ibm.com (westrelay02.boulder.ibm.com [9.17.194.23]) by e31.co.us.ibm.com (8.9.3/8.9.3) with ESMTP id LAA62660; Thu, 21 Mar 2002 11:01:33 -0500 Received: from d03nm014.boulder.ibm.com (avpilot.boulder.ibm.com [9.17.188.135]) by westrelay02.boulder.ibm.com (8.11.1m3/NCO/VER6.00) with ESMTP id g2LG4rR127566; Thu, 21 Mar 2002 09:04:53 -0700 X-Priority: 1 (High) Importance: Normal Subject: Re: Bit numbering I-D nit To: roweber@acm.org Cc: IPS Reflector X-Mailer: Lotus Notes Release 5.0.7 March 21, 2001 Message-ID: From: "John Hufferd" Date: Thu, 21 Mar 2002 08:04:16 -0800 X-MIMETrack: Serialize by Router on D03NM014/03/M/IBM(Release 5.0.9a |January 7, 2002) at 03/21/2002 09:04:52 AM MIME-Version: 1.0 Content-type: text/plain; charset=us-ascii Sender: owner-ips@ece.cmu.edu Precedence: bulk Ralph, I may have looked at this wrong, but though we have to change the way we present (print) the bit numbering, the bits on the link are the same way it was, or at least that is the way I read the RFC requirement. What do you think is the issue? . . . 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 Ralph Weber @ece.cmu.edu on 03/20/2002 08:34:57 PM Please respond to roweber@acm.org Sent by: owner-ips@ece.cmu.edu To: IPS Reflector cc: Subject: Bit numbering I-D nit I am getting serious flack from the Fibre Channel community over the bit numbering requirement in http://www.ietf.org/ID-nits.html. The problem is that Fibre Channel uses the other bit numbering scheme and interoperability woes seem certain unless something gets documented in the IETF RFCs. Everybody agrees that the body of the FC Frame Encapsulation and FCIP drafts can have the IETF bit numbering in the figures. What they all want is an appendix, or some such thing in the drafts/RFCs that translates it all back to the Fibre Channel view of reality. Such a thing seems destined to make waves in the IETF review process, and possibly even be a target for the RFC Editor's ax. Should I just jump of the top of the Hilton now, or is there a way out of this mess? Thanks. Ralph... From owner-ips@ece.cmu.edu Thu Mar 21 11:39: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 LAA16214 for ; Thu, 21 Mar 2002 11:39:38 -0500 (EST) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id g2LFpGl11015 for ips-outgoing; Thu, 21 Mar 2002 10:51:16 -0500 (EST) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from mononoke.wasabisystems.com (lion.ninthwonder.com [151.199.66.147]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id g2LFpFw11011 for ; Thu, 21 Mar 2002 10:51:15 -0500 (EST) Received: by mononoke.wasabisystems.com (Postfix, from userid 1021) id C4E5630715; Thu, 21 Mar 2002 10:51:14 -0500 (EST) Date: Thu, 21 Mar 2002 07:47:00 -0800 (PST) From: Bill Studenmund X-X-Sender: To: Cc: IPS Reflector Subject: Re: Bit numbering I-D nit In-Reply-To: <3C9962F1.27A3FC95@compuserve.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ips@ece.cmu.edu Precedence: bulk On Wed, 20 Mar 2002, Ralph Weber wrote: > I am getting serious flack from the Fibre Channel > community over the bit numbering requirement > in http://www.ietf.org/ID-nits.html. > > The problem is that Fibre Channel uses the > other bit numbering scheme and interoperability > woes seem certain unless something gets > documented in the IETF RFCs. > > Everybody agrees that the body of the FC > Frame Encapsulation and FCIP drafts can > have the IETF bit numbering in the figures. > > What they all want is an appendix, or some > such thing in the drafts/RFCs that translates > it all back to the Fibre Channel view of > reality. > > Such a thing seems destined to make waves > in the IETF review process, and possibly > even be a target for the RFC Editor's ax. > > Should I just jump of the top of the Hilton > now, or is there a way out of this mess? Add it as an appendix, and see what happens. Does the Fibre Channel community have a standard dictating how they lay out bit numbers? If so, label it a translation to that standard. :-) Take care, Bill From owner-ips@ece.cmu.edu Thu Mar 21 11:40: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 LAA16298 for ; Thu, 21 Mar 2002 11:40:30 -0500 (EST) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id g2LGKXN13307 for ips-outgoing; Thu, 21 Mar 2002 11:20:33 -0500 (EST) 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 g2LGKUw13299 for ; Thu, 21 Mar 2002 11:20:30 -0500 (EST) Received: from msgrel1.cos.agilent.com (msgrel1.cos.agilent.com [130.29.152.77]) by msgbas1.cos.agilent.com (Postfix) with ESMTP id 6AAA2B940; Thu, 21 Mar 2002 09:20:29 -0700 (MST) Received: from axcsbh1.cos.agilent.com (axcsbh1.cos.agilent.com [130.29.152.143]) by msgrel1.cos.agilent.com (Postfix) with ESMTP id 4EBBC436; Thu, 21 Mar 2002 09:20:29 -0700 (MST) Received: by axcsbh1.cos.agilent.com with Internet Mail Service (5.5.2653.19) id ; Thu, 21 Mar 2002 09:20:29 -0700 Message-ID: <9F8400020EC5D311AF62009027C3961605F2693F@axcs09.cos.agilent.com> From: "LEMAY,KEVIN (A-Roseville,ex1)" To: "'Julian Satran'" Cc: ips@ece.cmu.edu Subject: RE: Range Seperator Date: Thu, 21 Mar 2002 09:20:27 -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 I do not like the ';' but I would prefer a single character. There have been objections to using the comma or colon, then my third choice is the ".." I really don't see any conflict using either the comma or colon. Using comma is already used to separate list values. Colon being used in addresses is irrelevant because those are different parameters. I certainly keep track of which one we are working on. Kevin Lemay -----Original Message----- From: Julian Satran [mailto:Julian_Satran@il.ibm.com] Sent: Thursday, March 21, 2002 7:47 AM To: Rod Harrison Cc: ips@ece.cmu.edu Subject: RE: I was looking at what would be appropriate (and perhaps familiar to programmers - double dot is used in Pascal for ranges). (- or +) may come handy later for other things. And BTW double characters are already there in addresses. We could use semicolon(;) (I for some reason do not like it). So we have 2 proposals: 1) .. (2 votes) 2); (1 vote?) The tally is on! (untill tomorrow) Julo "Rod Harrison" 21-03-02 02:04 Please respond to "Rod Harrison" To: Julian Satran/Haifa/IBM@IBMIL, cc: Subject: RE: I would prefer one character. I don't care what it is, any character will do, but having only one there is slightly easier to parse that having two. - Rod -----Original Message----- From: owner-ips@ece.cmu.edu [mailto:owner-ips@ece.cmu.edu]On Behalf Of Julian Satran Sent: Wednesday, March 20, 2002 5:05 PM To: ips@ece.cmu.edu Subject: Dear colleagues, I suggested using : (colon) to separate values in a range. Unfortunately : is overused (in addresses and in names). I suggest we use the (old) two dots (..) to mark a range. Comments? Julo From owner-ips@ece.cmu.edu Thu Mar 21 11:40: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 LAA16311 for ; Thu, 21 Mar 2002 11:40:56 -0500 (EST) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id g2LFlLp10721 for ips-outgoing; Thu, 21 Mar 2002 10:47:21 -0500 (EST) 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 g2LFlKw10717 for ; Thu, 21 Mar 2002 10:47:20 -0500 (EST) Received: from d12relay01.de.ibm.com (d12relay01.de.ibm.com [9.165.215.22]) by d12lmsgate.de.ibm.com (1.0.0) with ESMTP id QAA149766; Thu, 21 Mar 2002 16:47:12 +0100 Received: from d10hubm1.telaviv.ibm.com (d10ml001.telaviv.ibm.com [9.148.216.55]) by d12relay01.de.ibm.com (8.11.1m3/NCO/VER6.00) with ESMTP id g2LFlBc21892; Thu, 21 Mar 2002 16:47:12 +0100 To: "Rod Harrison" Cc: ips@ece.cmu.edu MIME-Version: 1.0 Subject: RE: X-Mailer: Lotus Notes Release 5.0.9 November 16, 2001 From: "Julian Satran" Message-ID: Date: Thu, 21 Mar 2002 17:47:11 +0200 X-MIMETrack: Serialize by Router on D10ML001/10/M/IBM(Release 5.0.9a |January 7, 2002) at 21/03/2002 17:47:12, Serialize complete at 21/03/2002 17:47:12 Content-Type: multipart/alternative; boundary="=_alternative 00567952C2256B83_=" Sender: owner-ips@ece.cmu.edu Precedence: bulk This is a multipart message in MIME format. --=_alternative 00567952C2256B83_= Content-Type: text/plain; charset="us-ascii" I was looking at what would be appropriate (and perhaps familiar to programmers - double dot is used in Pascal for ranges). (- or +) may come handy later for other things. And BTW double characters are already there in addresses. We could use semicolon(;) (I for some reason do not like it). So we have 2 proposals: 1) .. (2 votes) 2); (1 vote?) The tally is on! (untill tomorrow) Julo "Rod Harrison" 21-03-02 02:04 Please respond to "Rod Harrison" To: Julian Satran/Haifa/IBM@IBMIL, cc: Subject: RE: I would prefer one character. I don't care what it is, any character will do, but having only one there is slightly easier to parse that having two. - Rod -----Original Message----- From: owner-ips@ece.cmu.edu [mailto:owner-ips@ece.cmu.edu]On Behalf Of Julian Satran Sent: Wednesday, March 20, 2002 5:05 PM To: ips@ece.cmu.edu Subject: Dear colleagues, I suggested using : (colon) to separate values in a range. Unfortunately : is overused (in addresses and in names). I suggest we use the (old) two dots (..) to mark a range. Comments? Julo --=_alternative 00567952C2256B83_= Content-Type: text/html; charset="us-ascii"
I was looking at what would be appropriate (and perhaps familiar to programmers - double dot is used in Pascal for ranges). (- or +) may come handy later for other things. And BTW double characters are already there in addresses.
We could use semicolon(;) (I for some reason do not like it).

So we have 2 proposals:

1) .. (2 votes)
2); (1 vote?)

The tally is on! (untill tomorrow)

Julo

"Rod Harrison" <rod.harrison@windriver.com>

21-03-02 02:04
Please respond to "Rod Harrison"

To: Julian Satran/Haifa/IBM@IBMIL, <ips@ece.cmu.edu>
cc:
Subject: RE:

I would prefer one character. I don't care what it is, any character
will do, but having only one there is slightly easier to parse that
having two.

- Rod

-----Original Message-----
From: owner-ips@ece.cmu.edu [mailto:owner-ips@ece.cmu.edu]On Behalf Of
Julian Satran
Sent: Wednesday, March 20, 2002 5:05 PM
To: ips@ece.cmu.edu
Subject:

Dear colleagues,

I suggested using : (colon) to separate values in a range.
Unfortunately :
is overused (in addresses and in names).
I suggest we use the (old) two dots (..) to mark a range.

Comments?
Julo

--=_alternative 00567952C2256B83_=-- From owner-ips@ece.cmu.edu Thu Mar 21 11:41: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 LAA16370 for ; Thu, 21 Mar 2002 11:41:12 -0500 (EST) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id g2LG9kp12503 for ips-outgoing; Thu, 21 Mar 2002 11:09:46 -0500 (EST) 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 g2LG9iw12499 for ; Thu, 21 Mar 2002 11:09:44 -0500 (EST) Received: by ATLOPS with Internet Mail Service (5.5.2653.19) id ; Thu, 21 Mar 2002 11:09:43 -0500 Message-ID: <25369470B6F0D41194820002B328BDD22F58AB@ATLOPS> From: Eddy Quicksall To: Michel Maddux , "'iSCSI'" , "'luben@splentec.com'" , Rod Harrison Cc: Julian Satran Subject: RE: Date: Thu, 21 Mar 2002 11:09:39 -0500 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 Whatever is done, the parsing should be kept simple. Double characters and context sensitive parsing has not been necessary to date. Let's just move ahead with some unique (non overloaded) single character. Eddy -----Original Message----- From: Michel Maddux [mailto:Michel.Maddux@mcdata.com] Sent: Thursday, March 21, 2002 10:36 AM To: 'iSCSI'; 'luben@splentec.com'; Rod Harrison Cc: Julian Satran Subject: RE: I disagree; a range of values has long been denoted by (..) ASCII being limited, using a minus (-) sign will get into character overloading and ambiguity. thanks ./m. -----Original Message----- From: Luben Tuikov [mailto:luben@splentec.com] Sent: Wednesday, March 20, 2002 11:53 PM To: Rod Harrison Cc: Julian Satran; ips@ece.cmu.edu Subject: Re: Rod Harrison wrote: > I would prefer one character. I don't care what it is, any character > will do, but having only one there is slightly easier to parse that > having two. I strongly agree. A single character, anyone indeed. Maybe a dash/minus ``-'' (0x2d). I don't think we'd ever need to pass arithmetic expressions, so a minus would do... -- Luben From owner-ips@ece.cmu.edu Thu Mar 21 11:42: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 LAA16473 for ; Thu, 21 Mar 2002 11:42:43 -0500 (EST) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id g2LFxu211713 for ips-outgoing; Thu, 21 Mar 2002 10:59:56 -0500 (EST) 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 g2LFxow11699; Thu, 21 Mar 2002 10:59:51 -0500 (EST) Received: from d12relay01.de.ibm.com (d12relay01.de.ibm.com [9.165.215.22]) by d12lmsgate.de.ibm.com (1.0.0) with ESMTP id QAA126942; Thu, 21 Mar 2002 16:59:29 +0100 Received: from d10hubm1.telaviv.ibm.com (d10ml001.telaviv.ibm.com [9.148.216.55]) by d12relay01.de.ibm.com (8.11.1m3/NCO/VER6.00) with ESMTP id g2LFxKc160792; Thu, 21 Mar 2002 16:59:29 +0100 To: Santosh Rao Cc: Dave Peterson , "Ips@Ece. Cmu. Edu" , owner-ips@ece.cmu.edu MIME-Version: 1.0 Subject: Re: iSCSI: items discussed at WG meeting X-Mailer: Lotus Notes Release 5.0.9 November 16, 2001 From: "Julian Satran" Message-ID: Date: Thu, 21 Mar 2002 17:59:19 +0200 X-MIMETrack: Serialize by Router on D10ML001/10/M/IBM(Release 5.0.9a |January 7, 2002) at 21/03/2002 17:59:29, Serialize complete at 21/03/2002 17:59:29 Content-Type: multipart/alternative; boundary="=_alternative 00573432C2256B83_=" Sender: owner-ips@ece.cmu.edu Precedence: bulk This is a multipart message in MIME format. --=_alternative 00573432C2256B83_= Content-Type: text/plain; charset="us-ascii" Santosh, my comments in text - Julo Santosh Rao Sent by: owner-ips@ece.cmu.edu 21-03-02 02:19 Please respond to Santosh Rao To: Dave Peterson cc: "Ips@Ece. Cmu. Edu" Subject: Re: iSCSI: items discussed at WG meeting Dave, Some queries inline. Regards, Santosh Dave Peterson wrote: > 4. Clause 6.7 SCSI Timeouts: explicitly state that a command retry shouldn't > be performed after a SCSI level timeout. > > "An iSCSI initiator MAY attempt to plug a command sequence gap on the target > end (in the absence of an acknowledgement of the command by way of ExpCmdSN) > before the ULP timeout by retrying the unacknowledged command, as described > in Section 6.1 Retry and Reassign in Recovery." Why would a scsi transport protocol be required to specify this ? Since a ULP timeout is O.S. specific and is not an externally observable value, either on the wire, or communicated to the target, why should iscsi specify this ? Different O.S. drivers may apply different timeout policies, with some drivers allowing for some grace time to attempt to complete the I/O after a timeout. IMO, the iscsi spec can be silent on what an O.S. specific driver does when its O.S. specific ULP timeout expires. This is O.S. dependent. > 6. Text stating that a TMF=Abort Task must be issued for each outstanding > command. (Clause 6.7) What does this mean (?). Could you elaborate further on this. 6.7 defines what action should be taken by an initiator on a SCSI timeout, which occurs on a per-command basis and is dealt with individually for each command. Where do the remaining outstanding commands come into the picture, unless, you're proposing that something like the FC second level error recovery be performed, on failure of the abort (?). +++ Santosh - Dave asked for some advisory statements and we can make some about the ISCSI part. We can add some statements to the implementor notes I will make the available to the list soon. +++ > > 7. Targets MUST support the command retry functionality. Don't think this > functionality provides much benefit in its current state. > Consider this case: > a. tape locate command is issued with a 10 second ULP timer > b. command is dropped at the target due to a digest error > c. having seen no status for 8 seconds (for example) the iSCSI initiator > decides to retry the command. > > What happens with the timer on the first command? If it is not canceled, and > if status is not received within 2 seconds, an abort for the command will be > issued by the ULP. Agreed. This is an issue in some cases, since not enough I/O time would be available for the retry. However, the selection of the initial command retry timeout value (when the initiator determines that the cmdsn has not been acknowledged for a long enough period and decides to retry the command) and the decision on whether to retry should be taken by the initiator driver, based on how much ULP time remains for that I/O. (Again, this logic is mostly O.S. driver specific.) > > dap: a mechanism to initiate error detection/recovery would be beneficial. Could you expand on this some more ? > > 8. CRN Processing and behavior: spec currently references SAM-2 for CRN. > > Per SAM-2: > Command Reference Number (CRN): > When this argument is used, all sequential commands of an I_T_L nexus shall > include a CRN argument that is incremented by one. The initial, wrap, and > reset CRN values shall be one. The CRN value zero shall be reserved for use > as defined by the SCSI protocol. It is not an error for the application > client to provide this argument when CRN is not supported by the SCSI > protocol or logical unit. > > More text specifying the behavior of CRN in the iSCSI realm is needed. In > addition, a method to determine if CRN is being used (or not) is missing. +++ we made clear that CRN is a SCSI issue. The only think that we might do is the clearing but even there I am not sure that we should not call a "generic SCSI function" and let T10 define what the function will do for different devices - certainly after defining it+++ We went through this discussion several months ago in another ips thread. CRN really belongs to the SCSI ULP and any mechanism to check if the device server supports CRN should be in a SCSI ULP mode page (like the Control Mode Page). As far as iscsi is concerned, both the iscsi initiator and target implementations MUST support CRN, since it is defined in iscsi command pdu. Why is such a method required at the SCSI LLP layer ? -- ################################## Santosh Rao Software Design Engineer, HP-UX iSCSI Driver Team, Hewlett Packard, Cupertino. email : santoshr@cup.hp.com Phone : 408-447-3751 ################################## --=_alternative 00573432C2256B83_= Content-Type: text/html; charset="us-ascii"
Santosh,

my comments in text - Julo

Santosh Rao <santoshr@cup.hp.com>
Sent by: owner-ips@ece.cmu.edu

21-03-02 02:19
Please respond to Santosh Rao

To: Dave Peterson <dap@cisco.com>
cc: "Ips@Ece. Cmu. Edu" <ips@ece.cmu.edu>
Subject: Re: iSCSI: items discussed at WG meeting

Dave,

Some queries inline.

Regards,
Santosh

Dave Peterson wrote:

> 4. Clause 6.7 SCSI Timeouts: explicitly state that a command retry shouldn't
> be performed after a SCSI level timeout.
>
> "An iSCSI initiator MAY attempt to plug a command sequence gap on the target
> end (in the absence of an acknowledgement of the command by way of ExpCmdSN)
> before the ULP timeout by retrying the unacknowledged command, as described
> in Section 6.1 Retry and Reassign in Recovery."

Why would a scsi transport protocol be required to specify this ? Since
a ULP timeout is O.S. specific and is not an externally observable
value, either on the wire, or communicated to the target, why should
iscsi specify this ?

Different O.S. drivers may apply different timeout policies, with some
drivers allowing for some grace time to attempt to complete the I/O
after a timeout.

IMO, the iscsi spec can be silent on what an O.S. specific driver does
when its O.S. specific ULP timeout expires. This is O.S. dependent.

> 6. Text stating that a TMF=Abort Task must be issued for each outstanding
> command. (Clause 6.7)

What does this mean (?). Could you elaborate further on this. 6.7
defines what action should be taken by an initiator on a SCSI timeout,
which occurs on a per-command basis and is dealt with individually for
each command.

Where do the remaining outstanding commands come into the picture,
unless, you're proposing that something like the FC second level error
recovery be performed, on failure of the abort (?).

+++ Santosh - Dave asked for some advisory statements and we can make some about the ISCSI part. We can add some statements to the implementor notes I will make the available to the list soon. +++
>
> 7. Targets MUST support the command retry functionality. Don't think this
> functionality provides much benefit in its current state.
> Consider this case:
> a. tape locate command is issued with a 10 second ULP timer
> b. command is dropped at the target due to a digest error
> c. having seen no status for 8 seconds (for example) the iSCSI initiator
> decides to retry the command.
>
> What happens with the timer on the first command? If it is not canceled, and
> if status is not received within 2 seconds, an abort for the command will be
> issued by the ULP.

Agreed. This is an issue in some cases, since not enough I/O time would
be available for the retry. However, the selection of the initial
command retry timeout value (when the initiator determines that the
cmdsn has not been acknowledged for a long enough period and decides to
retry the command) and the decision on whether to retry should be taken
by the initiator driver, based on how much ULP time remains for that
I/O.

(Again, this logic is mostly O.S. driver specific.)

>
> dap: a mechanism to initiate error detection/recovery would be beneficial.

Could you expand on this some more ?

>
> 8. CRN Processing and behavior: spec currently references SAM-2 for CRN.
>
> Per SAM-2:
> Command Reference Number (CRN):
> When this argument is used, all sequential commands of an I_T_L nexus shall
> include a CRN argument that is incremented by one. The initial, wrap, and
> reset CRN values shall be one. The CRN value zero shall be reserved for use
> as defined by the SCSI protocol. It is not an error for the application
> client to provide this argument when CRN is not supported by the SCSI
> protocol or logical unit.
>
> More text specifying the behavior of CRN in the iSCSI realm is needed. In
> addition, a method to determine if CRN is being used (or not) is missing.
+++ we made clear that CRN is a SCSI issue. The only think that we might do is the clearing but even there I am not sure that we should not call a "generic SCSI function" and let T10 define what the function will do for different devices - certainly after defining it+++
We went through this discussion several months ago in another ips
thread. CRN really belongs to the SCSI ULP and any mechanism to check if
the device server supports CRN should be in a SCSI ULP mode page (like
the Control Mode Page).

As far as iscsi is concerned, both the iscsi initiator and target
implementations MUST support CRN, since it is defined in iscsi command
pdu.

Why is such a method required at the SCSI LLP layer ?

--
##################################
Santosh Rao
Software Design Engineer,
HP-UX iSCSI Driver Team,
Hewlett Packard, Cupertino.
email : santoshr@cup.hp.com
Phone : 408-447-3751
##################################

--=_alternative 00573432C2256B83_=-- From owner-ips@ece.cmu.edu Thu Mar 21 12:12: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 MAA17995 for ; Thu, 21 Mar 2002 12:12:07 -0500 (EST) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id g2LGWlB14133 for ips-outgoing; Thu, 21 Mar 2002 11:32:47 -0500 (EST) 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 g2LGWiw14125 for ; Thu, 21 Mar 2002 11:32:44 -0500 (EST) Received: by ATLOPS with Internet Mail Service (5.5.2653.19) id ; Thu, 21 Mar 2002 11:32:43 -0500 Message-ID: <25369470B6F0D41194820002B328BDD22F58AF@ATLOPS> From: Eddy Quicksall To: Paul Koning , rod.harrison@windriver.com Cc: ips@ece.cmu.edu Subject: RE: Date: Thu, 21 Mar 2002 11:32:37 -0500 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 Tilde (~) is another choice. Eddy -----Original Message----- From: Paul Koning [mailto:ni1d@arrl.net] Sent: Thursday, March 21, 2002 10:08 AM To: rod.harrison@windriver.com Cc: ips@ece.cmu.edu Subject: RE: >>>>> "Rod" == Rod Harrison writes: Rod> I would prefer one character. I don't care what it is, any Rod> character will do, but having only one there is slightly easier Rod> to parse that having two. I agree. Colon will serve fine, unless we expect to have IPv6 address ranges in login negotiations at some point. Dash should work fine too. But no double-character tokens, please. paul From owner-ips@ece.cmu.edu Thu Mar 21 12:15: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 MAA18140 for ; Thu, 21 Mar 2002 12:15:25 -0500 (EST) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id g2LGtj415806 for ips-outgoing; Thu, 21 Mar 2002 11:55:45 -0500 (EST) 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 g2LGthw15802 for ; Thu, 21 Mar 2002 11:55:43 -0500 (EST) Received: from westrelay03.boulder.ibm.com (westrelay03.boulder.ibm.com [9.17.194.24]) by e31.co.us.ibm.com (8.9.3/8.9.3) with ESMTP id LAA81208 for ; Thu, 21 Mar 2002 11:52:20 -0500 Received: from d03nm014.boulder.ibm.com (avpilot.boulder.ibm.com [9.17.188.135]) by westrelay03.boulder.ibm.com (8.11.1m3/NCO/VER6.00) with ESMTP id g2LGtdP28806; Thu, 21 Mar 2002 09:55:39 -0700 X-Priority: 1 (High) Importance: Normal Subject: RE: To: "Julian Satran" Cc: ips@ece.cmu.edu X-Mailer: Lotus Notes Release 5.0.7 March 21, 2001 Message-ID: From: "John Hufferd" Date: Thu, 21 Mar 2002 08:50:50 -0800 X-MIMETrack: Serialize by Router on D03NM014/03/M/IBM(Release 5.0.9a |January 7, 2002) at 03/21/2002 09:55:38 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 g2LGthw15803 Sender: owner-ips@ece.cmu.edu Precedence: bulk Content-Transfer-Encoding: 8bit What about using the ~ (tittle) symbol. . . . 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" @ece.cmu.edu on 03/21/2002 07:47:11 AM Sent by: owner-ips@ece.cmu.edu To: "Rod Harrison" cc: ips@ece.cmu.edu Subject: RE: I was looking at what would be appropriate (and perhaps familiar to programmers - double dot is used in Pascal for ranges). �(- or +) may come handy later for other things. And BTW double characters are already there in addresses. We could use semicolon(;) (I for some reason do not like it). So we have 2 proposals: 1) .. (2 votes) 2); (1 vote?) The tally is on! (untill tomorrow) Julo "Rod Harrison" Satran/Haifa/IBM@IBMIL, 21-03-02 02:04 � � � � cc: Please respond to "Rod � � � � Subject: � � � �RE: Harrison" � � � � � � � � I would prefer one character. I don't care what it is, any character will do, but having only one there is slightly easier to parse that having two. � � � � � � � � - Rod -----Original Message----- From: owner-ips@ece.cmu.edu [mailto:owner-ips@ece.cmu.edu]On Behalf Of Julian Satran Sent: Wednesday, March 20, 2002 5:05 PM To: ips@ece.cmu.edu Subject: Dear colleagues, I suggested using : (colon) to separate values in a range. Unfortunately : is overused (in addresses and in names). I suggest we use the (old) two dots (..) to mark a range. Comments? Julo From owner-ips@ece.cmu.edu Thu Mar 21 12: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 MAA18378 for ; Thu, 21 Mar 2002 12:21:05 -0500 (EST) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id g2LGfCF14725 for ips-outgoing; Thu, 21 Mar 2002 11:41:12 -0500 (EST) 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 g2LGf9w14715 for ; Thu, 21 Mar 2002 11:41:09 -0500 (EST) Received: from frejya.corp.netapp.com (frejya [10.10.20.91]) by mx01-a.netapp.com (8.11.1/8.11.1/NTAP-1.2) with ESMTP id g2LGf3302481; Thu, 21 Mar 2002 08:41:03 -0800 (PST) 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 g2LGf2x4010501; Thu, 21 Mar 2002 08:41:03 -0800 (PST) Received: by tahoe.corp.netapp.com with Internet Mail Service (5.5.2650.21) id ; Thu, 21 Mar 2002 08:38:26 -0800 Message-ID: <02740A3D0809D5118C7C00034707E9F30155485C@ussvlexc10.corp.netapp.com> From: "Pittman, Joseph" To: "'Julian Satran'" Cc: ips@ece.cmu.edu Subject: RE: Date: Thu, 21 Mar 2002 08:41:01 -0800 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 How about the tilde character, '~'? -- Joe Pittman jpittman@netapp.com -----Original Message----- From: Julian Satran [mailto:Julian_Satran@il.ibm.com] Sent: Thursday, March 21, 2002 10:47 AM To: Rod Harrison Cc: ips@ece.cmu.edu Subject: RE: I was looking at what would be appropriate (and perhaps familiar to programmers - double dot is used in Pascal for ranges). (- or +) may come handy later for other things. And BTW double characters are already there in addresses. We could use semicolon(;) (I for some reason do not like it). So we have 2 proposals: 1) .. (2 votes) 2); (1 vote?) The tally is on! (untill tomorrow) Julo "Rod Harrison" 21-03-02 02:04 Please respond to "Rod Harrison" To: Julian Satran/Haifa/IBM@IBMIL, cc: Subject: RE: I would prefer one character. I don't care what it is, any character will do, but having only one there is slightly easier to parse that having two. - Rod -----Original Message----- From: owner-ips@ece.cmu.edu [mailto:owner-ips@ece.cmu.edu]On Behalf Of Julian Satran Sent: Wednesday, March 20, 2002 5:05 PM To: ips@ece.cmu.edu Subject: Dear colleagues, I suggested using : (colon) to separate values in a range. Unfortunately : is overused (in addresses and in names). I suggest we use the (old) two dots (..) to mark a range. Comments? Julo From owner-ips@ece.cmu.edu Thu Mar 21 12: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 MAA18480 for ; Thu, 21 Mar 2002 12:23:58 -0500 (EST) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id g2LH0FU16116 for ips-outgoing; Thu, 21 Mar 2002 12:00:15 -0500 (EST) 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 g2LH09w16103; Thu, 21 Mar 2002 12:00:09 -0500 (EST) Received: from msgrel1.cos.agilent.com (msgrel1.cos.agilent.com [130.29.152.77]) by msgbas2.cos.agilent.com (Postfix) with ESMTP id 72255D1F; Thu, 21 Mar 2002 10:00:08 -0700 (MST) Received: from axcsbh2.cos.agilent.com (axcsbh2.cos.agilent.com [130.29.152.144]) by msgrel1.cos.agilent.com (Postfix) with SMTP id D49BC436; Thu, 21 Mar 2002 10:00:07 -0700 (MST) Received: from 130.29.152.144 by axcsbh2.cos.agilent.com (InterScan E-Mail VirusWall NT); Thu, 21 Mar 2002 10:00:07 -0700 Received: by axcsbh2.cos.agilent.com with Internet Mail Service (5.5.2653.19) id ; Thu, 21 Mar 2002 10:00:07 -0700 Message-ID: <1BEBA5E8600DD4119A50009027AF54A00ADA261E@axcs04.cos.agilent.com> From: "THALER,PAT (A-Roseville,ex1)" To: "Ranganathan, Deva" , "'Robert D. Russell'" , Julian Satran Cc: ips@ece.cmu.edu, owner-ips@ece.cmu.edu Subject: RE: iSCSI: ITT field in draft 11 Date: Thu, 21 Mar 2002 10:00:03 -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 Deva, An implementation can only rely on the field to always hold an ITT if it is specified to do so. Currently, the BHS shows the field holding ITT "or Opcode specific fields". Therefore, an implementation must check the Opcode before it can use the field as an ITT. The change Robert suggests isn't quite sufficient to accomplish allowing an implementation to use the ITT before it checks the Opcode. To do that, we would need to also need to change the BHS definition adding ITT to the list of fields that always appear in the BHS and change the figure to reflect that. Otherwise, vendor specific Opcodes and Opcodes defined in the future might use that space in the BHS for something else. Regards, Pat -----Original Message----- From: Ranganathan, Deva [mailto:Deva_Ranganathan@adaptec.com] Sent: Wednesday, March 20, 2002 8:59 AM To: 'Robert D. Russell'; Julian Satran Cc: ips@ece.cmu.edu; owner-ips@ece.cmu.edu Subject: RE: iSCSI: ITT field in draft 11 Robert, Is this not implementation related? -Deva -----Original Message----- From: Robert D. Russell [mailto:rdr@io.iol.unh.edu] Sent: Wednesday, March 20, 2002 5:26 AM To: Julian Satran Cc: ips@ece.cmu.edu; owner-ips@ece.cmu.edu Subject: iSCSI: ITT field in draft 11 Julian: One of the changes that came in with draft 11 is that in the Asynchronous Message PDU and in the Reject PDU the 4-byte field at offset 16 became: 16| Reserved -0xffffffff whereas previously it had just been Reserved. I believe the reason for explicitly specifying the value 0xffffffff is because this field in all other PDUs is the Initiator Task Tag, and for all those other PDUs this value means there is no valid Initiator Transfer Tag. This change now makes it possible for an initiator to find the task associated with each incoming PDU before looking at the opcode of the PDU. So far so good. The problem is that this field cannot be called Reserved due to section 9 which says that receivers MUST ignore reserved fields, thus defeating the whole purpose of defining a value the initiator can use. To correct this, the specs for both Asynchronous Message and Reject should be changed to explicitly include the Initiator Task Tag field and specify in the descriptions of each of those PDUs that this field MUST be set to 0xffffffff. If this is done, then every PDU will contain the Initiator Task Tag field, and the description of the BHS in section 9.2.1 can be changed from: 16| Initiator Task Tag or Opcode-specific fields to 16| Initiator Task Tag which would clearly show the consistent meaning of this field over all PDUs. Also, there are two related minor clarifications that should be made: 1) The 4th paragraph of section 9.16.1 currently says: "For Status SNACK, the Initiator Task Tag is reserved." It would be better if this said explicitly: "For Status SNACK, the Initiator Task Tag MUST be set to the reserved value 0xffffffff." 2) The last sentence in section 9.5.3 says: "For all the other functions this field is reserved." It would be better if this said explicitly: "For all the other functions this field MUST be set to the reserved value 0xffffffff." (Note that the corresponding sentence in section 9.6.2 already says this.) Thanks, Bob Russell InterOperability Lab University of New Hampshire rdr@iol.unh.edu 603-862-3774 From owner-ips@ece.cmu.edu Thu Mar 21 12:26: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 MAA18569 for ; Thu, 21 Mar 2002 12:26:57 -0500 (EST) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id g2LH6cF16592 for ips-outgoing; Thu, 21 Mar 2002 12:06:38 -0500 (EST) 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 g2LH6Xw16584 for ; Thu, 21 Mar 2002 12:06:34 -0500 (EST) 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 JAA21500; Thu, 21 Mar 2002 09:05:50 -0800 (PST) From: "Rod Harrison" To: "LEMAY,KEVIN (A-Roseville,ex1)" , "'Julian Satran'" Cc: Subject: RE: iSCSI: Range Seperator Date: Thu, 21 Mar 2002 17:06:15 -0000 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) In-Reply-To: <9F8400020EC5D311AF62009027C3961605F2693F@axcs09.cos.agilent.com> Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2314.1300 Sender: owner-ips@ece.cmu.edu Precedence: bulk Content-Transfer-Encoding: 7bit I don't care what the character is since the focus is to make this easy to parse, and not human readable. So to that end consider my vote to be for whichever of the single characters is nearest to winning. ;-) However, if we do have to pay some mind to aesthetics then how about the < character? So we would have MyKey=3<65,93<123 - Rod -----Original Message----- From: owner-ips@ece.cmu.edu [mailto:owner-ips@ece.cmu.edu]On Behalf Of LEMAY,KEVIN (A-Roseville,ex1) Sent: Thursday, March 21, 2002 4:20 PM To: 'Julian Satran' Cc: ips@ece.cmu.edu Subject: RE: Range Seperator I do not like the ';' but I would prefer a single character. There have been objections to using the comma or colon, then my third choice is the ".." I really don't see any conflict using either the comma or colon. Using comma is already used to separate list values. Colon being used in addresses is irrelevant because those are different parameters. I certainly keep track of which one we are working on. Kevin Lemay -----Original Message----- From: Julian Satran [mailto:Julian_Satran@il.ibm.com] Sent: Thursday, March 21, 2002 7:47 AM To: Rod Harrison Cc: ips@ece.cmu.edu Subject: RE: I was looking at what would be appropriate (and perhaps familiar to programmers - double dot is used in Pascal for ranges). (- or +) may come handy later for other things. And BTW double characters are already there in addresses. We could use semicolon(;) (I for some reason do not like it). So we have 2 proposals: 1) .. (2 votes) 2); (1 vote?) The tally is on! (untill tomorrow) Julo "Rod Harrison" 21-03-02 02:04 Please respond to "Rod Harrison" To: Julian Satran/Haifa/IBM@IBMIL, cc: Subject: RE: I would prefer one character. I don't care what it is, any character will do, but having only one there is slightly easier to parse that having two. - Rod -----Original Message----- From: owner-ips@ece.cmu.edu [mailto:owner-ips@ece.cmu.edu]On Behalf Of Julian Satran Sent: Wednesday, March 20, 2002 5:05 PM To: ips@ece.cmu.edu Subject: Dear colleagues, I suggested using : (colon) to separate values in a range. Unfortunately : is overused (in addresses and in names). I suggest we use the (old) two dots (..) to mark a range. Comments? Julo From owner-ips@ece.cmu.edu Thu Mar 21 12:28: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 MAA18652 for ; Thu, 21 Mar 2002 12:28:43 -0500 (EST) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id g2LH6gu16602 for ips-outgoing; Thu, 21 Mar 2002 12:06:42 -0500 (EST) 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 g2LH6dw16595 for ; Thu, 21 Mar 2002 12:06:39 -0500 (EST) 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 g2LH6Xj03269; Thu, 21 Mar 2002 09:06:33 -0800 (PST) Received: from aimexc07.corp.adaptec.com (aimexc07.corp.adaptec.com [162.62.62.47]) by redfish.adaptec.com (8.8.8+Sun/8.8.8) with ESMTP id JAA02442; Thu, 21 Mar 2002 09:06:33 -0800 (PST) Received: by aimexc07.corp.adaptec.com with Internet Mail Service (5.5.2653.19) id ; Thu, 21 Mar 2002 09:04:38 -0800 Message-ID: From: "Ranganathan, Deva" To: "'Robert D. Russell'" Cc: "'ips@ece.cmu.edu'" Subject: RE: iSCSI: ITT field in draft 11 Date: Thu, 21 Mar 2002 09:04:38 -0800 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 Robert, I agree with you that we need to have a consistent format defined for efficient implementation. As Pat suggests, ITT needs to,probably, be defined in BHS. Thanks Deva -----Original Message----- From: Robert D. Russell [mailto:rdr@io.iol.unh.edu] Sent: Thursday, March 21, 2002 3:19 AM To: Ranganathan, Deva Cc: ips@ece.cmu.edu; owner-ips@ece.cmu.edu Subject: RE: iSCSI: ITT field in draft 11 Deva: I don't think so. The target action must not be implementation dependent because then initiators would not be able to reliably use the value in the ITT field, which is the whole point. Bob Russell On Wed, 20 Mar 2002, Ranganathan, Deva wrote: > Robert, > > Is this not implementation related? > > -Deva > > > -----Original Message----- > From: Robert D. Russell [mailto:rdr@io.iol.unh.edu] > Sent: Wednesday, March 20, 2002 5:26 AM > To: Julian Satran > Cc: ips@ece.cmu.edu; owner-ips@ece.cmu.edu > Subject: iSCSI: ITT field in draft 11 > > > Julian: > > One of the changes that came in with draft 11 is that in the > Asynchronous Message PDU and in the Reject PDU the 4-byte field > at offset 16 became: > 16| Reserved -0xffffffff > whereas previously it had just been Reserved. > > I believe the reason for explicitly specifying the value 0xffffffff > is because this field in all other PDUs is the Initiator Task Tag, > and for all those other PDUs this value means there is no valid > Initiator Transfer Tag. This change now makes it possible for an > initiator to find the task associated with each incoming PDU before > looking at the opcode of the PDU. So far so good. > > The problem is that this field cannot be called Reserved due to section > 9 which says that receivers MUST ignore reserved fields, thus defeating > the whole purpose of defining a value the initiator can use. > > To correct this, the specs for both Asynchronous Message and Reject > should be changed to explicitly include the Initiator Task Tag field > and specify in the descriptions of each of those PDUs that this field > MUST be set to 0xffffffff. > > If this is done, then every PDU will contain the Initiator Task Tag field, > and the description of the BHS in section 9.2.1 can be changed from: > 16| Initiator Task Tag or Opcode-specific fields > to > 16| Initiator Task Tag > which would clearly show the consistent meaning of this field over all PDUs. > > > Also, there are two related minor clarifications that should be made: > > 1) The 4th paragraph of section 9.16.1 currently says: > "For Status SNACK, the Initiator Task Tag is reserved." > It would be better if this said explicitly: > "For Status SNACK, the Initiator Task Tag MUST be set to the > reserved value 0xffffffff." > > 2) The last sentence in section 9.5.3 says: > "For all the other functions this field is reserved." > It would be better if this said explicitly: > "For all the other functions this field MUST be set to the > reserved value 0xffffffff." > (Note that the corresponding sentence in section 9.6.2 already > says this.) > > > Thanks, > > Bob Russell > InterOperability Lab > University of New Hampshire > rdr@iol.unh.edu > 603-862-3774 > From owner-ips@ece.cmu.edu Thu Mar 21 12: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 MAA18953 for ; Thu, 21 Mar 2002 12:35:45 -0500 (EST) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id g2LH83d16683 for ips-outgoing; Thu, 21 Mar 2002 12:08:03 -0500 (EST) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from mononoke.wasabisystems.com (lion.ninthwonder.com [151.199.66.147]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id g2LH81w16677 for ; Thu, 21 Mar 2002 12:08:01 -0500 (EST) Received: by mononoke.wasabisystems.com (Postfix, from userid 1021) id E59B03070C; Thu, 21 Mar 2002 12:08:00 -0500 (EST) Date: Thu, 21 Mar 2002 09:03:43 -0800 (PST) From: Bill Studenmund X-X-Sender: To: Eddy Quicksall Cc: iSCSI , , Rod Harrison , Julian Satran Subject: RE: In-Reply-To: <25369470B6F0D41194820002B328BDD22F58A9@ATLOPS> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ips@ece.cmu.edu Precedence: bulk On Thu, 21 Mar 2002, Eddy Quicksall wrote: > That would be ok for something like an expression parser but our parser > should be very simple minded and it is better if it is not context > sensitive. It is the same idea as "don't use two characters". While I agree simple is good, there has to be some sort of context senstivity. I mean you have to figure out if you have one value or a range, don't you? How do you do that? Don't you parse one number and then look at the next character to decide if you have a range or not? If the next character is the range-indicating character, you remove it from the stream and then call the number parser again, don't you? Given that, how is using a '-' a problem? It's the exact same code (hardware or software) as using ';', just a different constant. Since I really doubt algebraic expressions will ever be valid, the sequence " ... number '-' number ... " can never mean anything other than a range. So how is that hard for even a simple parser to deal with? Also, I think you've assumed that: 1) we should use '-' either for negative numbers or for ranges not both, and 2) that we would rather use '-' for negative numbers than for ranges. While I don't care much about the first assumption, if we have to choose between ranges using '-' and negative numbers, ranges seem to make more sense to me here. Most programs accept them, and it's a rather intuitive way to express them. Also, are we really ever going to need negative numbers? SCSI doesn't have them. IP doesn't. TCP does not. Since those protocols use unsigned numbers, why would we need signed? > Also, the "looks" of it is not very important. I think you took my use of "look" at too simplistic a level. I did not say aesthetics. :-) My use of "look" reflects parsability of text. If something "looks" like something else, I'm saying it's more difficult to distinguish the two interpretations in a parser (you need extra context which we both agree is usually bad). If things "look" like each other, it's harder to tell them apart. We don't want that, in order to keep the parser simple as you mentioned above. Thus "looks" are important. Take care, Bill From owner-ips@ece.cmu.edu Thu Mar 21 13: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 NAA20977 for ; Thu, 21 Mar 2002 13:36:24 -0500 (EST) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id g2LI1gF20308 for ips-outgoing; Thu, 21 Mar 2002 13:01:42 -0500 (EST) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from Kairos.dsa.uqam.ca (kairos.dsa.uqam.ca [132.208.43.57]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id g2LI1dw20300 for ; Thu, 21 Mar 2002 13:01:39 -0500 (EST) Received: from localhost (bill@localhost) by Kairos.dsa.uqam.ca (8.11.4/8.11.4) with ESMTP id g2LHwOu27416; Thu, 21 Mar 2002 12:58:24 -0500 Date: Thu, 21 Mar 2002 12:58:24 -0500 (EST) From: Bill Strahm X-X-Sender: To: John Hufferd cc: Julian Satran , Subject: RE: In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=X-UNKNOWN Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from QUOTED-PRINTABLE to 8bit by ece.cmu.edu id g2LI1ew20301 Sender: owner-ips@ece.cmu.edu Precedence: bulk Content-Transfer-Encoding: 8bit I wonder if this is how Ray Tomlinson felt when he had to select a seperator... Hmmmm this one doesn't seem to be used for much, lets use it Bill On Thu, 21 Mar 2002, John Hufferd wrote: > > What about using the ~ (tittle) symbol. > > . > . > . > 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" @ece.cmu.edu on 03/21/2002 > 07:47:11 AM > > Sent by: owner-ips@ece.cmu.edu > > > To: "Rod Harrison" > cc: ips@ece.cmu.edu > Subject: RE: > > > > > I was looking at what would be appropriate (and perhaps familiar to > programmers - double dot is used in Pascal for ranges). �(- or +) may come > handy later for other things. And BTW double characters are already there > in addresses. > We could use semicolon(;) (I for some reason do not like it). > > So we have 2 proposals: > > 1) .. (2 votes) > 2); (1 vote?) > > The tally is on! (untill tomorrow) > > Julo > > > > > > "Rod Harrison" > com> Satran/Haifa/IBM@IBMIL, > > 21-03-02 02:04 � � � � cc: > Please respond to "Rod � � � � Subject: � � � �RE: > Harrison" > > > > > > > � � � � � � � � I would prefer one character. I don't care what it is, any > character > will do, but having only one there is slightly easier to parse that > having two. > > � � � � � � � � - Rod > > -----Original Message----- > From: owner-ips@ece.cmu.edu [mailto:owner-ips@ece.cmu.edu]On Behalf Of > Julian Satran > Sent: Wednesday, March 20, 2002 5:05 PM > To: ips@ece.cmu.edu > Subject: > > > Dear colleagues, > > I suggested using : (colon) to separate values in a range. > Unfortunately : > is overused (in addresses and in names). > I suggest we use the (old) two dots (..) to mark a range. > > Comments? > Julo > > > > > > > From owner-ips@ece.cmu.edu Thu Mar 21 13:37: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 NAA20991 for ; Thu, 21 Mar 2002 13:37:26 -0500 (EST) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id g2LHmsV19425 for ips-outgoing; Thu, 21 Mar 2002 12:48:54 -0500 (EST) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from mononoke.wasabisystems.com (lion.ninthwonder.com [151.199.66.147]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id g2LHmpw19417 for ; Thu, 21 Mar 2002 12:48:51 -0500 (EST) Received: by mononoke.wasabisystems.com (Postfix, from userid 1021) id EBCEB3070C; Thu, 21 Mar 2002 12:48:50 -0500 (EST) Date: Thu, 21 Mar 2002 09:44:35 -0800 (PST) From: Bill Studenmund X-X-Sender: To: Julian Satran Cc: Rod Harrison , Subject: RE: 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, 21 Mar 2002, Julian Satran wrote: > I was looking at what would be appropriate (and perhaps familiar to > programmers - double dot is used in Pascal for ranges). (- or +) may come > handy later for other things. And BTW double characters are already there > in addresses. > > We could use semicolon(;) (I for some reason do not like it). > > So we have 2 proposals: I think actually we have three proposals, don't we? > 1) .. (2 votes) > 2); (1 vote?) 3) '-', and it seems to have at least two supporters. :-) > The tally is on! (untill tomorrow) Take care, Bill From owner-ips@ece.cmu.edu Thu Mar 21 13:39: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 NAA21079 for ; Thu, 21 Mar 2002 13:39:44 -0500 (EST) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id g2LHt9R19839 for ips-outgoing; Thu, 21 Mar 2002 12:55:09 -0500 (EST) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from lakemtao03.cox.net (lakemtao03.cox.net [68.1.17.242]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id g2LHt6w19833 for ; Thu, 21 Mar 2002 12:55:06 -0500 (EST) Received: from CX418298C ([68.5.217.92]) by lakemtao03.cox.net (InterMail vM.5.01.04.05 201-253-122-122-105-20011231) with SMTP id <20020321175501.KCEU18064.lakemtao03.cox.net@CX418298C>; Thu, 21 Mar 2002 12:55:01 -0500 From: "Murali Rajagopal" To: "Paul Koning" , Cc: Subject: RE: Bit numbering I-D nit Date: Thu, 21 Mar 2002 09:55:34 -0800 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 In-Reply-To: <15514.1140.622421.720310@pkoning.dev.equallogic.com> X-MIMEOLE: Produced By Microsoft MimeOLE V5.50.4807.1700 Sender: owner-ips@ece.cmu.edu Precedence: bulk Content-Transfer-Encoding: 7bit Paul/Ralph: Clearly it appears that putting something an appendix is reaching a high degree of consensus. One might also, via an example in the appendix alert the reader to this mapping. I would find it hard that any RFC editor would argue with this informative example. -Murali -----Original Message----- From: owner-ips@ece.cmu.edu [mailto:owner-ips@ece.cmu.edu]On Behalf Of Paul Koning Sent: Thursday, March 21, 2002 8:04 AM To: roweber@acm.org Cc: ips@ece.cmu.edu Subject: Re: Bit numbering I-D nit >>>>> "Ralph" == Ralph Weber writes: Ralph> I am getting serious flack from the Fibre Channel community Ralph> over the bit numbering requirement in Ralph> http://www.ietf.org/ID-nits.html. I can see why... I didn't realize that the requirement is for the confusing old IMB-360 style bit ordering rather than the "powers of two" bit ordering that's generally used. Yuck. Ralph> The problem is that Fibre Channel uses the other bit numbering Ralph> scheme and interoperability woes seem certain unless something Ralph> gets documented in the IETF RFCs. Ralph> Everybody agrees that the body of the FC Frame Encapsulation Ralph> and FCIP drafts can have the IETF bit numbering in the Ralph> figures. Ralph> What they all want is an appendix, or some such thing in the Ralph> drafts/RFCs that translates it all back to the Fibre Channel Ralph> view of reality. Ralph> Such a thing seems destined to make waves in the IETF review Ralph> process, and possibly even be a target for the RFC Editor's Ralph> ax. I would say an appendix that documents the mapping to other standards is the right thing. If that gives the RFC editor and/or IESG heartburn, it's worth a battle. Bit order is far too important an interop issue to be left undiscussed, and if bureaucratic rules stand in the way, those rules MUST change. If those sound like strong words, so be it. I've been burned far too many times by bit order confusion to take this sort of thing lightly. If there exist two conventions in the community, it's mandatory to document that explicitly and clearly state the mapping between the two notations, or things will never work. paul From owner-ips@ece.cmu.edu Thu Mar 21 14:26: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 OAA22491 for ; Thu, 21 Mar 2002 14:26:40 -0500 (EST) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id g2LJ3Kq25295 for ips-outgoing; Thu, 21 Mar 2002 14:03:20 -0500 (EST) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from ariel.nishansystems.com (goretex.nishansystems.com [216.217.36.167] (may be forged)) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id g2LJ3Iw25291 for ; Thu, 21 Mar 2002 14:03:18 -0500 (EST) Received: by ariel.nishansystems.com with Internet Mail Service (5.5.2653.19) id ; Thu, 21 Mar 2002 11:03:03 -0800 Message-ID: From: Charles Monia To: "'Murali Rajagopal'" , Paul Koning , roweber@acm.org Cc: ips@ece.cmu.edu Subject: RE: Bit numbering I-D nit Date: Thu, 21 Mar 2002 11:02:52 -0800 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 Folks: In my opinion, the overriding consideration must be to achieve clarity. In that regard, I think the following guidelines should apply to the fibre channel related drafts: 1. The specification should have one and only one convention for representing bits in a structure. 2. When a fibre channel construct is referenced in the spec, including a reference to specific bit positions, the conventions for representing the structure and the corresponding textual reference to specific fields or bits within it should correspond to the normative fibre channel spec in which the structure is defined. I would suggest an informative appendix showing the mapping between the fibre channel convention and that shown in the 'nits' document cited by Ralph. thanks, Charles > -----Original Message----- > From: Murali Rajagopal [mailto:muralir@cox.net] > Sent: Thursday, March 21, 2002 9:56 AM > To: Paul Koning; roweber@acm.org > Cc: ips@ece.cmu.edu > Subject: RE: Bit numbering I-D nit > > > Paul/Ralph: > > Clearly it appears that putting something an appendix is > reaching a high > degree of consensus. > One might also, via an example in the appendix alert the > reader to this > mapping. I would find > it hard that any RFC editor would argue with this informative example. > > -Murali > > -----Original Message----- > From: owner-ips@ece.cmu.edu [mailto:owner-ips@ece.cmu.edu]On Behalf Of > Paul Koning > Sent: Thursday, March 21, 2002 8:04 AM > To: roweber@acm.org > Cc: ips@ece.cmu.edu > Subject: Re: Bit numbering I-D nit > > > >>>>> "Ralph" == Ralph Weber writes: > > Ralph> I am getting serious flack from the Fibre Channel community > Ralph> over the bit numbering requirement in > Ralph> http://www.ietf.org/ID-nits.html. > > I can see why... I didn't realize that the requirement is for the > confusing old IMB-360 style bit ordering rather than the "powers of > two" bit ordering that's generally used. Yuck. > > Ralph> The problem is that Fibre Channel uses the other bit numbering > Ralph> scheme and interoperability woes seem certain unless something > Ralph> gets documented in the IETF RFCs. > > Ralph> Everybody agrees that the body of the FC Frame Encapsulation > Ralph> and FCIP drafts can have the IETF bit numbering in the > Ralph> figures. > > Ralph> What they all want is an appendix, or some such thing in the > Ralph> drafts/RFCs that translates it all back to the Fibre Channel > Ralph> view of reality. > > Ralph> Such a thing seems destined to make waves in the IETF review > Ralph> process, and possibly even be a target for the RFC Editor's > Ralph> ax. > > I would say an appendix that documents the mapping to other standards > is the right thing. If that gives the RFC editor and/or IESG > heartburn, it's worth a battle. Bit order is far too important an > interop issue to be left undiscussed, and if bureaucratic rules stand > in the way, those rules MUST change. > > If those sound like strong words, so be it. I've been burned far too > many times by bit order confusion to take this sort of thing lightly. > If there exist two conventions in the community, it's mandatory to > document that explicitly and clearly state the mapping between the two > notations, or things will never work. > > paul > > From owner-ips@ece.cmu.edu Thu Mar 21 14:27: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 OAA22545 for ; Thu, 21 Mar 2002 14:27:49 -0500 (EST) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id g2LJIM926460 for ips-outgoing; Thu, 21 Mar 2002 14:18:22 -0500 (EST) 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 g2LJIJw26453 for ; Thu, 21 Mar 2002 14:18:19 -0500 (EST) Received: from splentec.com (canoe.splentec.com [209.47.35.250]) by pepsi.splentec.com (8.11.6/8.11.0) with ESMTP id g2LJHO220492; Thu, 21 Mar 2002 14:17:24 -0500 Message-ID: <3C9A31E9.3DF85391@splentec.com> Date: Thu, 21 Mar 2002 14:18:01 -0500 From: Luben Tuikov Reply-To: iSCSI , luben@splentec.com Organization: Splentec Ltd. X-Mailer: Mozilla 4.79 [en] (X11; U; Linux 2.4.18 i686) X-Accept-Language: en MIME-Version: 1.0 To: Julian Satran CC: Rod Harrison , ips@ece.cmu.edu Subject: Re: References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ips@ece.cmu.edu Precedence: bulk Content-Transfer-Encoding: 7bit > 1) .. (2 votes) > 2); (1 vote?) Note that the complexity is between 1 and N (N > 1) character as you'll have to ``put back'' those characters in the buffer/IO stream if they don't match, and going about it with a single char is so much easy... Hmm, why do we need a _different_ character for ranges? Don't we have the variable context already? As Bill pointed out, even if we use dash/minus, allowing negative numbers in ranges is NO problem. You can see this for yourselves by either writing down the context free grammar rules for it, or equivalently an automata for parsing it. If we decide on ``..'', then this _is_equivalent_ to ``range'', i.e. OFMarkInt=1..10 parses as OFMarkInt=1range10 since you'll have to get to _another_ state upon parsing the second ``.'', the only difference is that you need more states for ``range''. -- Luben From owner-ips@ece.cmu.edu Thu Mar 21 14:28: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 OAA22572 for ; Thu, 21 Mar 2002 14:28:15 -0500 (EST) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id g2LIn4c24092 for ips-outgoing; Thu, 21 Mar 2002 13:49:04 -0500 (EST) 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 g2LIn0w24088 for ; Thu, 21 Mar 2002 13:49:01 -0500 (EST) Received: from splentec.com (canoe.splentec.com [209.47.35.250]) by pepsi.splentec.com (8.11.6/8.11.0) with ESMTP id g2LImC220346; Thu, 21 Mar 2002 13:48:12 -0500 Message-ID: <3C9A2B12.2930B6FE@splentec.com> Date: Thu, 21 Mar 2002 13:48:50 -0500 From: Luben Tuikov Reply-To: iSCSI , luben@splentec.com Organization: Splentec Ltd. X-Mailer: Mozilla 4.79 [en] (X11; U; Linux 2.4.18 i686) X-Accept-Language: en MIME-Version: 1.0 To: Eddy Quicksall CC: Bill Studenmund , iSCSI , Rod Harrison , Julian Satran Subject: iSCSI: Re: range separator References: <25369470B6F0D41194820002B328BDD22F58A9@ATLOPS> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ips@ece.cmu.edu Precedence: bulk Content-Transfer-Encoding: 7bit Eddy Quicksall wrote: > > That would be ok for something like an expression parser but our parser > should be very simple minded and it is better if it is not context > sensitive. It is the same idea as "don't use two characters". Context: are you parsing ``MaxConnections=3'' or ``3''. You see, your parser is already context sensitive. As iSCSI grows, undoubtedly each parameter/variable will be handled by it's own string value parser, and _THEN_ you'd abstractize into integer value, or string value, or range. Note, that a range is a string (we know this already) of to use context free grammar (stripped down version :-). Philosophically, the debate is whether to use 1 character or many. I vote for just a single char. Anywhich one. Using a different character to tell us that this string denotes a range is not quite a solution here. E.g.: MaxConnections=310 So the Target will know that it is a range, but it doesn't matter... it will have to check the context anyway... That is, the context really matters! (AI anyone?) P.S. It would also be nice to see keys' values in context free grammar (EBNF will do the trick, or even BNF)... Then everything will be easier. :-) -- Luben From owner-ips@ece.cmu.edu Thu Mar 21 14: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 OAA22756 for ; Thu, 21 Mar 2002 14:31:27 -0500 (EST) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id g2LJ2Fc25232 for ips-outgoing; Thu, 21 Mar 2002 14:02:15 -0500 (EST) 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 g2LJ2Cw25222 for ; Thu, 21 Mar 2002 14:02:12 -0500 (EST) Received: from splentec.com (canoe.splentec.com [209.47.35.250]) by pepsi.splentec.com (8.11.6/8.11.0) with ESMTP id g2LJ1S220413; Thu, 21 Mar 2002 14:01:28 -0500 Message-ID: <3C9A2E2D.1B4C01B3@splentec.com> Date: Thu, 21 Mar 2002 14:02:05 -0500 From: Luben Tuikov Reply-To: iSCSI , luben@splentec.com Organization: Splentec Ltd. X-Mailer: Mozilla 4.79 [en] (X11; U; Linux 2.4.18 i686) X-Accept-Language: en MIME-Version: 1.0 To: Michel Maddux CC: "'iSCSI'" , Rod Harrison , Julian Satran Subject: Re: References: <84540A7A9263854CBA6E6F99BA2CE4CE15CC44@380exu01.mcdata.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ips@ece.cmu.edu Precedence: bulk Content-Transfer-Encoding: 7bit Michel Maddux wrote: > > I disagree; a range of values has long been denoted by (..) Really? In which context? Pascal programming language? Math uses comma. We can use that too. Regular expressions use dash/minus. We can use that too. Why don't we use dash/minus which most of us know from regular expressions and from school... Regarding ``simplicity'': If we are trying to keep it simple, then why are we using variables like MaxRecvPDULength and OFMarkInt case sensitive on top of that???? Isn't this a low level protocol that will not be looked at by humans. How about "4=2"? ;-) -- Luben From owner-ips@ece.cmu.edu Thu Mar 21 15:21: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 PAA24119 for ; Thu, 21 Mar 2002 15:21:22 -0500 (EST) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id g2LJXeC27733 for ips-outgoing; Thu, 21 Mar 2002 14:33:40 -0500 (EST) 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 g2LJXbw27726 for ; Thu, 21 Mar 2002 14:33:37 -0500 (EST) Received: from splentec.com (canoe.splentec.com [209.47.35.250]) by pepsi.splentec.com (8.11.6/8.11.0) with ESMTP id g2LJWm220573; Thu, 21 Mar 2002 14:32:48 -0500 Message-ID: <3C9A3586.316C3BAE@splentec.com> Date: Thu, 21 Mar 2002 14:33:26 -0500 From: Luben Tuikov Reply-To: iSCSI , luben@splentec.com Organization: Splentec Ltd. X-Mailer: Mozilla 4.79 [en] (X11; U; Linux 2.4.18 i686) X-Accept-Language: en MIME-Version: 1.0 To: pat_thaler@agilent.com CC: wrstuden@wasabisystems.com, Eddy_Quicksall@ivivity.com, ips@ece.cmu.edu, rod.harrison@windriver.com, Julian_Satran@il.ibm.com Subject: Question? Re: iSCSI range separator References: <1BEBA5E8600DD4119A50009027AF54A00ADA26A8@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: > > Bill, > > We are trying to avoid overloading characters. Pat, why are we trying to avoid overloading of characters? Given that a context for each variable already exists and we cannot avoid it. We already know what a variable takes, so then we can just parse for THAT particular thing. How about this (BNF) (Just an example, just an example): IFMarkInt= OFMarkInt= ::= ::= ::= , ::= : | - | ~ -- Luben From owner-ips@ece.cmu.edu Thu Mar 21 15:27: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 OAA22583 for ; Thu, 21 Mar 2002 14:28:15 -0500 (EST) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id g2LIjp223806 for ips-outgoing; Thu, 21 Mar 2002 13:45:51 -0500 (EST) 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 g2LIjkw23794 for ; Thu, 21 Mar 2002 13:45:46 -0500 (EST) Received: from msgrel1.cos.agilent.com (msgrel1.cos.agilent.com [130.29.152.77]) by msgbas1.cos.agilent.com (Postfix) with ESMTP id 1D972BADC; Thu, 21 Mar 2002 11:45:46 -0700 (MST) Received: from axcsbh4.cos.agilent.com (axcsbh4.cos.agilent.com [130.29.152.145]) by msgrel1.cos.agilent.com (Postfix) with SMTP id 7D2B819F6; Thu, 21 Mar 2002 11:45:45 -0700 (MST) Received: from 130.29.152.145 by axcsbh4.cos.agilent.com (InterScan E-Mail VirusWall NT); Thu, 21 Mar 2002 11:45:45 -0700 Received: by axcsbh4.cos.agilent.com with Internet Mail Service (5.5.2653.19) id ; Thu, 21 Mar 2002 11:45:45 -0700 Message-ID: <1BEBA5E8600DD4119A50009027AF54A00ADA26A8@axcs04.cos.agilent.com> From: pat_thaler@agilent.com To: wrstuden@wasabisystems.com, Eddy_Quicksall@ivivity.com Cc: ips@ece.cmu.edu, luben@splentec.com, rod.harrison@windriver.com, Julian_Satran@il.ibm.com Subject: RE: iSCSI range separater Date: Thu, 21 Mar 2002 11:45:42 -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 Bill, We are trying to avoid overloading characters. If we were willing to overload, we could use : (colon) which is used by some applications as a range separater. I don't think we should overload the minus sign. If we are not overloading, I vote for tilde. If we are willing to overload, I vote for colon. Pat -----Original Message----- From: Bill Studenmund [mailto:wrstuden@wasabisystems.com] Sent: Thursday, March 21, 2002 7:37 AM To: Eddy Quicksall Cc: iSCSI; luben@splentec.com; Rod Harrison; Julian Satran Subject: RE: On Thu, 21 Mar 2002, Eddy Quicksall wrote: > A dash is also used for negative numbers (we don't have any yet but could in > the future). True, but is that a concern here? For a range, you have to have two numbers with the dash/minus between them. "-number" would not be a valid range. So even if we ever get negative numbers, ranges should be readily different. The only point of confusion would be if we ever permitted algebraic expressions, when the '-' would look like subtraction. But I think that would neither be sensible nor likely. Take care, Bill From owner-ips@ece.cmu.edu Thu Mar 21 15:33: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 PAA24490 for ; Thu, 21 Mar 2002 15:33:48 -0500 (EST) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id g2LK8b601235 for ips-outgoing; Thu, 21 Mar 2002 15:08:37 -0500 (EST) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from cheetah.istor-networks.com (h-66-134-214-26.LSANCA54.covad.net [66.134.214.26]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id g2LK8Yw01230 for ; Thu, 21 Mar 2002 15:08:34 -0500 (EST) X-MimeOLE: Produced By Microsoft Exchange V6.0.4417.0 content-class: urn:content-classes:message Subject: Model for iSCSI over DDP or RDMA (iWarp)? Date: Thu, 21 Mar 2002 12:09:20 -0800 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Thread-Topic: Model for iSCSI over DDP or RDMA (iWarp)? Thread-Index: AcHRFEj14OTATiPvTk68iyMuZWwFzg== From: "Andy Kraslavsky" To: "IPS Reflector" Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ece.cmu.edu id g2LK8Zw01231 Sender: owner-ips@ece.cmu.edu Precedence: bulk Content-Transfer-Encoding: 8bit Good day, Sorry if I missed this in an earlier posting but, is there a document I can get at which describes how iSCSI transactions would be best conducted via DDP (DDPP) or RDMA (iWarp)? Thank you, -- Andrew Kraslavsky iStor Networks From owner-ips@ece.cmu.edu Thu Mar 21 15:35: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 PAA24526 for ; Thu, 21 Mar 2002 15:35:30 -0500 (EST) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id g2LKESH01904 for ips-outgoing; Thu, 21 Mar 2002 15:14:28 -0500 (EST) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from mononoke.wasabisystems.com (lion.ninthwonder.com [151.199.66.147]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id g2LKEPw01899 for ; Thu, 21 Mar 2002 15:14:25 -0500 (EST) Received: by mononoke.wasabisystems.com (Postfix, from userid 1021) id E42F23070C; Thu, 21 Mar 2002 15:14:24 -0500 (EST) Date: Thu, 21 Mar 2002 12:10:09 -0800 (PST) From: Bill Studenmund X-X-Sender: To: iSCSI , Cc: Eddy Quicksall , Rod Harrison , Julian Satran Subject: Re: iSCSI: Re: range separator In-Reply-To: <3C9A2B12.2930B6FE@splentec.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ips@ece.cmu.edu Precedence: bulk On Thu, 21 Mar 2002, Luben Tuikov wrote: > Eddy Quicksall wrote: > > > > That would be ok for something like an expression parser but our parser > > should be very simple minded and it is better if it is not context > > sensitive. It is the same idea as "don't use two characters". > > Context: are you parsing ``MaxConnections=3'' > or ``3''. You see, your parser is already > context sensitive. > > As iSCSI grows, undoubtedly each parameter/variable > will be handled by it's own string value parser, Well, there probably won't be that many parsers. One set-of-numbers parser can be used for all the number-expecting cases. > and _THEN_ you'd abstractize into > integer value, or > string value, or > range. > > Note, that a range is > a string (we know this already) of > to use context > free grammar (stripped down version :-). > > Philosophically, the debate is whether to use > 1 character or many. > > I vote for just a single char. Anywhich one. Agreed. > Using a different character to tell us that > this string denotes a range is not quite a > solution here. E.g.: > > MaxConnections=310 > > So the Target will know that it is a range, > but it doesn't matter... it will have to check > the context anyway... Won't the parser already have to have figured out the context anyway? We have to know if the key is: 1) valid, and 2) appropriate for this phase already, don't we? After figuring that out, is it hard to know if we expect a string or one or more numbers? Take care, Bill From owner-ips@ece.cmu.edu Thu Mar 21 15:35: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 PAA24538 for ; Thu, 21 Mar 2002 15:35:32 -0500 (EST) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id g2LKKAV02568 for ips-outgoing; Thu, 21 Mar 2002 15:20:10 -0500 (EST) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from mononoke.wasabisystems.com (lion.ninthwonder.com [151.199.66.147]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id g2LKK7w02558 for ; Thu, 21 Mar 2002 15:20:07 -0500 (EST) Received: by mononoke.wasabisystems.com (Postfix, from userid 1021) id 86F9A3070C; Thu, 21 Mar 2002 15:20:07 -0500 (EST) Date: Thu, 21 Mar 2002 12:15:51 -0800 (PST) From: Bill Studenmund X-X-Sender: To: Julian Satran Cc: Rod Harrison , Subject: RE: 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, 21 Mar 2002, Julian Satran wrote: > I was looking at what would be appropriate (and perhaps familiar to > programmers - double dot is used in Pascal for ranges). (- or +) may come > handy later for other things. And BTW double characters are already there > in addresses. One thing I would like to suggest also in choosing a value is to pick one that will make sense to more than just programmers. One of the advantages of using a text-based negotiation is that in case of negotiation problems, an administrator could read the negotiation transcript and hopefully figure out what was wrong. My suggestion is that we pick something that will make sense to administrators also. Take care, Bill From owner-ips@ece.cmu.edu Thu Mar 21 16:14: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 QAA25757 for ; Thu, 21 Mar 2002 16:14:48 -0500 (EST) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id g2LKgIO04768 for ips-outgoing; Thu, 21 Mar 2002 15:42:18 -0500 (EST) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from mononoke.wasabisystems.com (lion.ninthwonder.com [151.199.66.147]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id g2LKgFw04763 for ; Thu, 21 Mar 2002 15:42:15 -0500 (EST) Received: by mononoke.wasabisystems.com (Postfix, from userid 1021) id 2912E3070C; Thu, 21 Mar 2002 15:42:15 -0500 (EST) Date: Thu, 21 Mar 2002 12:37:44 -0800 (PST) From: Bill Studenmund X-X-Sender: To: iSCSI , Cc: Michel Maddux , Rod Harrison , Julian Satran Subject: Re: In-Reply-To: <3C9A2E2D.1B4C01B3@splentec.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ips@ece.cmu.edu Precedence: bulk On Thu, 21 Mar 2002, Luben Tuikov wrote: > Michel Maddux wrote: > > > > I disagree; a range of values has long been denoted by (..) > > Really? In which context? Pascal programming language? > > Math uses comma. We can use that too. > Regular expressions use dash/minus. We can use that too. > > Why don't we use dash/minus which most of us know > from regular expressions and from school... :-) > Regarding ``simplicity'': > > If we are trying to keep it > simple, then why are we using variables like > MaxRecvPDULength and OFMarkInt case sensitive > on top of that???? > > Isn't this a low level protocol that will not be looked > at by humans. I think readability should be thought about. While rare, I think it will help to let admins be able to watch a login transcript if they think something is wrong. Take care, Bill From owner-ips@ece.cmu.edu Thu Mar 21 16:26: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 QAA26012 for ; Thu, 21 Mar 2002 16:26:57 -0500 (EST) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id g2LKrA105771 for ips-outgoing; Thu, 21 Mar 2002 15:53:10 -0500 (EST) 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 g2LKr8w05764 for ; Thu, 21 Mar 2002 15:53:08 -0500 (EST) 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 MAA09915; Thu, 21 Mar 2002 12:53:01 -0800 (PST) Received: by xbl.ad.emulex.com with Internet Mail Service (5.5.2653.19) id ; Thu, 21 Mar 2002 15:53:02 -0500 Received: from rome.emulex.com (rome.ma.emulex.com [172.16.14.140]) by xbl.ad.emulex.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) id GFHTPBHC; Thu, 21 Mar 2002 15:52:50 -0500 From: "Kleinman, Barry" To: Julian Satran , Rod Harrison Cc: ips@ece.cmu.edu Message-Id: <4.3.2.7.2.20020321155102.01b7ebb0@xbl> X-Sender: barry@xbl X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Thu, 21 Mar 2002 15:52:50 -0500 Subject: RE: In-Reply-To: Mime-Version: 1.0 Content-Type: multipart/alternative; boundary="=====================_1821877250==_.ALT" Sender: owner-ips@ece.cmu.edu Precedence: bulk --=====================_1821877250==_.ALT Content-Type: text/plain; charset="us-ascii" At 05:47 PM 3/21/2002 +0200, Julian Satran wrote: I was looking at what would be appropriate (and perhaps familiar to programmers - double dot is used in Pascal for ranges). (- or +) may come handy later for other things. And BTW double characters are already there in addresses. We could use semicolon(;) (I for some reason do not like it). So we have 2 proposals: 1) .. (2 votes) 2); (1 vote?) How about underscore? Looks sort of like a dash, never used in arithmetic or floating point numbers. -- Barry --=====================_1821877250==_.ALT Content-Type: text/html; charset="us-ascii" At 05:47 PM 3/21/2002 +0200, Julian Satran wrote:

I was looking at what would be appropriate (and perhaps familiar to programmers - double dot is used in Pascal for ranges). (- or +) may come handy later for other things. And BTW double characters are already there in addresses.
We could use semicolon(;) (I for some reason do not like it).

So we have 2 proposals:

1) .. (2 votes)
2); (1 vote?)

How about underscore? Looks sort of like a dash, never used in arithmetic or floating point numbers.

-- Barry

--=====================_1821877250==_.ALT-- From owner-ips@ece.cmu.edu Thu Mar 21 17:17: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 RAA27246 for ; Thu, 21 Mar 2002 17:17:07 -0500 (EST) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id g2LLjT110652 for ips-outgoing; Thu, 21 Mar 2002 16:45:29 -0500 (EST) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from mononoke.wasabisystems.com (lion.ninthwonder.com [151.199.66.147]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id g2LLjNw10632 for ; Thu, 21 Mar 2002 16:45:23 -0500 (EST) Received: by mononoke.wasabisystems.com (Postfix, from userid 1021) id 9B5D93070C; Thu, 21 Mar 2002 16:45:22 -0500 (EST) Date: Thu, 21 Mar 2002 13:40:43 -0800 (PST) From: Bill Studenmund X-X-Sender: To: iSCSI , Cc: Eddy Quicksall , Rod Harrison , Julian Satran Subject: Re: iSCSI: Re: range separator In-Reply-To: <3C9A51E7.93C9F70F@splentec.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ips@ece.cmu.edu Precedence: bulk On Thu, 21 Mar 2002, Luben Tuikov wrote: > Bill Studenmund wrote: > > > Won't the parser already have to have figured out the context anyway? We > > have to know if the key is: 1) valid, and 2) appropriate for this phase > > already, don't we? After figuring that out, is it hard to know if we > > expect a string or one or more numbers? > > Yes, of course. I was merely trying to show that > we cannot escape from the variable's context. Ahhh.... Ok. > Once we all recognize this fact we'd see that > we could overload certain symbols to denote > ranges. I mean certain, since overloading the comma > will not be that wise as in the _future_ we may > want to have a list of ranges (e.g. for choosing > a bit as in ``OurBitRange=1-4,13-16''). Agreed, ',' would be bad. Take care, Bill From owner-ips@ece.cmu.edu Thu Mar 21 17:19: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 RAA27294 for ; Thu, 21 Mar 2002 17:19:10 -0500 (EST) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id g2LLYdw09643 for ips-outgoing; Thu, 21 Mar 2002 16:34:39 -0500 (EST) 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 g2LLYWw09626 for ; Thu, 21 Mar 2002 16:34:32 -0500 (EST) Received: from splentec.com (canoe.splentec.com [209.47.35.250]) by pepsi.splentec.com (8.11.6/8.11.0) with ESMTP id g2LLXr221553; Thu, 21 Mar 2002 16:33:53 -0500 Message-ID: <3C9A51E7.93C9F70F@splentec.com> Date: Thu, 21 Mar 2002 16:34:31 -0500 From: Luben Tuikov Reply-To: iSCSI , luben@splentec.com Organization: Splentec Ltd. X-Mailer: Mozilla 4.79 [en] (X11; U; Linux 2.4.18 i686) X-Accept-Language: en MIME-Version: 1.0 To: Bill Studenmund CC: iSCSI , Eddy Quicksall , Rod Harrison , Julian Satran Subject: Re: iSCSI: Re: range separator References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ips@ece.cmu.edu Precedence: bulk Content-Transfer-Encoding: 7bit Bill Studenmund wrote: > > Well, there probably won't be that many parsers. One set-of-numbers parser > can be used for all the number-expecting cases. Yes, that's why I was mentioning contex-free grammars to describe the values which the variables can take, since then it is really easy to see what the terminals are (aka tokens, primitives), and one would need to have an integer, and string parser, the rest is left to the key's handler/negotiator. As in: > > > and _THEN_ you'd abstractize into > > integer value, or > > string value, or > > range. > > > > Note, that a range is > > a string (we know this already) of > > to use context > > free grammar (stripped down version :-). [cut] > > So the Target will know that it is a range, > > but it doesn't matter... it will have to check > > the context anyway... > > Won't the parser already have to have figured out the context anyway? We > have to know if the key is: 1) valid, and 2) appropriate for this phase > already, don't we? After figuring that out, is it hard to know if we > expect a string or one or more numbers? Yes, of course. I was merely trying to show that we cannot escape from the variable's context. Once we all recognize this fact we'd see that we could overload certain symbols to denote ranges. I mean certain, since overloading the comma will not be that wise as in the _future_ we may want to have a list of ranges (e.g. for choosing a bit as in ``OurBitRange=1-4,13-16''). -- Luben From owner-ips@ece.cmu.edu Thu Mar 21 18:54: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 SAA00506 for ; Thu, 21 Mar 2002 18:54:22 -0500 (EST) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id g2LN6fV17916 for ips-outgoing; Thu, 21 Mar 2002 18:06:41 -0500 (EST) 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 g2LN6dw17905 for ; Thu, 21 Mar 2002 18:06:39 -0500 (EST) Received: by ATLOPS with Internet Mail Service (5.5.2653.19) id ; Thu, 21 Mar 2002 18:06:38 -0500 Message-ID: <25369470B6F0D41194820002B328BDD22F58D9@ATLOPS> From: Eddy Quicksall To: Bill Studenmund Cc: "ips@ece. cmu. edu (E-mail)" Subject: RE: Date: Thu, 21 Mar 2002 18:06:29 -0500 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 missed the tilde (~) there are 3 votes for that. Eddy -----Original Message----- From: Bill Studenmund [mailto:wrstuden@wasabisystems.com] Sent: Thursday, March 21, 2002 12:45 PM To: Julian Satran Cc: Rod Harrison; ips@ece.cmu.edu Subject: RE: On Thu, 21 Mar 2002, Julian Satran wrote: > I was looking at what would be appropriate (and perhaps familiar to > programmers - double dot is used in Pascal for ranges). (- or +) may come > handy later for other things. And BTW double characters are already there > in addresses. > > We could use semicolon(;) (I for some reason do not like it). > > So we have 2 proposals: I think actually we have three proposals, don't we? > 1) .. (2 votes) > 2); (1 vote?) 3) '-', and it seems to have at least two supporters. :-) > The tally is on! (untill tomorrow) Take care, Bill From owner-ips@ece.cmu.edu Thu Mar 21 18:54: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 SAA00544 for ; Thu, 21 Mar 2002 18:54:40 -0500 (EST) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id g2LNFLS18634 for ips-outgoing; Thu, 21 Mar 2002 18:15:21 -0500 (EST) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from mononoke.wasabisystems.com (lion.ninthwonder.com [151.199.66.147]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id g2LNFIw18623 for ; Thu, 21 Mar 2002 18:15:18 -0500 (EST) Received: by mononoke.wasabisystems.com (Postfix, from userid 1021) id 01AFD3070C; Thu, 21 Mar 2002 18:15:17 -0500 (EST) Date: Thu, 21 Mar 2002 15:10:38 -0800 (PST) From: Bill Studenmund X-X-Sender: To: Eddy Quicksall Cc: "ips@ece. cmu. edu (E-mail)" Subject: speed, was RE: In-Reply-To: <25369470B6F0D41194820002B328BDD22F58D9@ATLOPS> Message-ID: