From sip-admin@ietf.org Fri Nov 1 13:01:30 2002 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA26102 for ; Fri, 1 Nov 2002 13:01:29 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id gA1I3Sv17864 for ; Fri, 1 Nov 2002 13:03:28 -0500 Date: Fri, 01 Nov 2002 13:03:28 -0500 Message-ID: <20021101180328.25483.32761.Mailman@www1.ietf.org> Subject: ietf.org mailing list memberships reminder From: mailman-owner@www1.ietf.org To: ips-archive@ietf.org X-No-Archive: yes X-Ack: no Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-BeenThere: sip@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk This is a reminder, sent out once a month, about your ietf.org mailing list memberships. It includes your subscription info and how to use it to change it or unsubscribe from a list. You can visit the URLs to change your membership status or configuration, including unsubscribing, setting digest-style delivery or disabling delivery altogether (e.g., for a vacation), and so on. In addition to the URL interfaces, you can also use email to make such changes. For more info, send a message to the '-request' address of the list (for example, ips-request@ietf.org) containing just the word 'help' in the message body, and an email message will be sent to you with instructions. *************************************************************************** Note Well All statements related to the activities of the IETF and addressed to the IETF are subject to all provisions of Section 10 of RFC 2026, which grants to the IETF and its participants certain licenses and rights in such statements. Such statements include verbal statements in IETF meetings, as well as written and electronic communications made at any time or place, which are addressed to * the IETF plenary session, * any IETF working group or portion thereof, * the IESG, or any member thereof on behalf of the IESG, * the IAB or any member thereof on behalf of the IAB, * any IETF mailing list, including the IETF list itself, any working group or design team list, or any other list functioning under IETF auspices, * the RFC Editor or the Internet-Drafts function Statements made outside of an IETF meeting, mailing list or other function, that are clearly not intended to be input to an IETF activity, group or function, are not subject to these provisions. *************************************************************************** If you have questions, problems, comments, etc, send them to mailman-owner@www1.ietf.org. Thanks! Passwords for ips-archive@lists.ietf.org: List Password // URL ---- -------- ips@ietf.org INMn https://www1.ietf.org/mailman/options/ips/ips-archive%40lists.ietf.org From owner-ips@ece.cmu.edu Fri Nov 1 19:44:53 2002 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA10500 for ; Fri, 1 Nov 2002 19:44:53 -0500 (EST) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id gA20Zpq21183 for ips-outgoing; Fri, 1 Nov 2002 19:35:51 -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 gA20ZmH21179 for ; Fri, 1 Nov 2002 19:35:48 -0500 (EST) Received: from sj-msg-av-2.cisco.com (sj-msg-av-2.cisco.com [171.70.145.31]) by sj-msg-core-1.cisco.com (8.12.2/8.12.2) with ESMTP id gA20ZhPP002469 for ; Fri, 1 Nov 2002 16:35:43 -0800 (PST) Received: from nisser.cisco.com (localhost [127.0.0.1]) by sj-msg-av-2.cisco.com (8.12.2/8.12.2) with ESMTP id gA20ZZ87019792 for ; Fri, 1 Nov 2002 16:35:35 -0800 (PST) Received: from cisco.com (mbakke-lnx2.cisco.com [64.101.211.59]) by nisser.cisco.com (8.8.6 (PHNE_14041)/CISCO.SERVER.1.2) with ESMTP id QAA19259 for ; Fri, 1 Nov 2002 16:35:35 -0800 (PST) Message-ID: <3DC31DD8.325B849E@cisco.com> Date: Fri, 01 Nov 2002 18:35:36 -0600 From: Mark Bakke X-Mailer: Mozilla 4.77 [en] (X11; U; Linux 2.4.9-34.cisco.2 i686) X-Accept-Language: en, de MIME-Version: 1.0 To: IPS Subject: iSCSI: New 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 I just submitted a new version of the iSCSI MIB, which should address all last call comments. Until it pops out of the I-D queue, it's available at: ftp://ftpeng.cisco.com/mbakke/ips/iscsi-mib/draft-ietf-ips-iscsi-mib-07.txt Changes: - Included text in the iscsiNodeName, iscsiSessionTargetName, and iscsiSessionInitiatorName to handle discovery-only sessions that do not have a "real" iSCSI target or initiator as an end-point. - Removed BidiInitialR2T attributes. - Fixed some text on Counter64. -- Mark A. Bakke Cisco Systems mbakke@cisco.com 763.398.1054 From owner-ips@ece.cmu.edu Fri Nov 1 19:45:06 2002 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA10514 for ; Fri, 1 Nov 2002 19:45:01 -0500 (EST) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id gA1Nte319278 for ips-outgoing; Fri, 1 Nov 2002 18:55:40 -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.54]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id gA1NtcH19273 for ; Fri, 1 Nov 2002 18:55:38 -0500 (EST) Received: from sj-msg-av-2.cisco.com (sj-msg-av-2.cisco.com [171.70.145.31]) by sj-msg-core-4.cisco.com (8.12.2/8.12.2) with ESMTP id gA1NtVot006176 for ; Fri, 1 Nov 2002 15:55:31 -0800 (PST) Received: from nisser.cisco.com (localhost [127.0.0.1]) by sj-msg-av-2.cisco.com (8.12.2/8.12.2) with ESMTP id gA1NtOR1026788 for ; Fri, 1 Nov 2002 15:55:24 -0800 (PST) Received: from cisco.com (mbakke-lnx2.cisco.com [64.101.211.59]) by nisser.cisco.com (8.8.6 (PHNE_14041)/CISCO.SERVER.1.2) with ESMTP id PAA20518 for ; Fri, 1 Nov 2002 15:55:29 -0800 (PST) Message-ID: <3DC31472.4709AC2C@cisco.com> Date: Fri, 01 Nov 2002 17:55:30 -0600 From: Mark Bakke X-Mailer: Mozilla 4.77 [en] (X11; U; Linux 2.4.9-34.cisco.2 i686) X-Accept-Language: en, de MIME-Version: 1.0 To: IPS Subject: iSCSI: New SLP draft Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ips@ece.cmu.edu Precedence: bulk Content-Transfer-Encoding: 7bit I just published a new version of the iSCSI SLP template. Until it pops out of the I-D queue, it's available at: ftp://ftpeng.cisco.com/mbakke/ips/iscsi/draft-ietf-ips-iscsi-slp-04.txt Major changes from the last draft: - Replaced access-list attribute with the three auth-xxxx attributes to match the iSCSI authentication model and the IPS Authentication MIB. - Added an optional initiator identity to the end of the service URL to allow separate sets of auth-xxxx attributes to be registered for a target, also to be consistent with the IPS Authentication MIB. - Updated the Security Considerations text. -- Mark A. Bakke Cisco Systems mbakke@cisco.com 763.398.1054 From owner-ips@ece.cmu.edu Sun Nov 3 16:10:36 2002 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA14832 for ; Sun, 3 Nov 2002 16:10:36 -0500 (EST) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id gA3KAFU18146 for ips-outgoing; Sun, 3 Nov 2002 15:10:15 -0500 (EST) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from d12lmsgate-5.de.ibm.com (d12lmsgate-5.de.ibm.com [194.196.100.238]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id gA3KACH18141 for ; Sun, 3 Nov 2002 15:10:12 -0500 (EST) Received: from d12relay02.de.ibm.com (d12relay02.de.ibm.com [9.165.215.23]) by d12lmsgate-5.de.ibm.com (8.12.3/8.12.3) with ESMTP id gA3KA4jk065690; Sun, 3 Nov 2002 21:10:05 +0100 Received: from d10hubm1.telaviv.ibm.com (d10ml001.telaviv.ibm.com [9.148.216.55]) by d12relay02.de.ibm.com (8.12.3/NCO/VER6.4) with ESMTP id gA3KA4h6013822; Sun, 3 Nov 2002 21:10:04 +0100 To: internet-drafts@ietf.org Cc: ips@ece.cmu.edu MIME-Version: 1.0 Subject: Fw: iSCSI version 19 draft X-Mailer: Lotus Notes Release 6.0 September 26, 2002 From: "Julian Satran" Message-ID: Date: Sun, 3 Nov 2002 22:10:01 +0200 X-MIMETrack: Serialize by Router on D10ML001/10/M/IBM(Release 5.0.9a |January 7, 2002) at 03/11/2002 22:10:04, Serialize complete at 03/11/2002 22:10:04 Content-Type: multipart/alternative; boundary="=_alternative 0065A106C2256C66_=" Sender: owner-ips@ece.cmu.edu Precedence: bulk This is a multipart message in MIME format. --=_alternative 0065A106C2256C66_= Content-Type: text/plain; charset="US-ASCII" On behalf of the team of authors and as part of the IETF-IPS working group I submit a draft for immediate publication. The text and pdf versions can be found at: http://www.haifa.il.ibm.com/satran/ips/draft-ietf-ips-iscsi-19.txt http://www.haifa.il.ibm.com/satran/ips/draft-ietf-ips-iscsi-19.pdf This version completely replaces: draft-ietf-ips-iscsi-18.txt and pdf The change marks are relative to version 18 and are ONLY typos and minor edits. All AD concerns and the "nits" where (hopefully) addressed. Julian Satran - IBM Research Laboratory at Haifa --=_alternative 0065A106C2256C66_= Content-Type: text/html; charset="US-ASCII"




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

The text and pdf versions can be found at:

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

This version completely replaces:

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


The change marks are relative to version 18 and are ONLY typos and minor edits.
All AD concerns and the "nits" where (hopefully) addressed.

Julian Satran - IBM Research Laboratory at Haifa



































--=_alternative 0065A106C2256C66_=-- From owner-ips@ece.cmu.edu Mon Nov 4 11:20:17 2002 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA20266 for ; Mon, 4 Nov 2002 11:20:17 -0500 (EST) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id gA4FHFW14930 for ips-outgoing; Mon, 4 Nov 2002 10:17:15 -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 gA4FHEH14925 for ; Mon, 4 Nov 2002 10:17:14 -0500 (EST) Received: from sj-msg-av-2.cisco.com (sj-msg-av-2.cisco.com [171.70.145.31]) by sj-msg-core-1.cisco.com (8.12.2/8.12.2) with ESMTP id gA4FH7PP003195 for ; Mon, 4 Nov 2002 07:17:07 -0800 (PST) Received: from nisser.cisco.com (localhost [127.0.0.1]) by sj-msg-av-2.cisco.com (8.12.2/8.12.2) with ESMTP id gA4FGxUv008099 for ; Mon, 4 Nov 2002 07:16:59 -0800 (PST) Received: from cisco.com (mbakke-lnx2.cisco.com [64.101.211.59]) by nisser.cisco.com (8.8.6 (PHNE_14041)/CISCO.SERVER.1.2) with ESMTP id HAA11437 for ; Mon, 4 Nov 2002 07:17:06 -0800 (PST) Message-ID: <3DC68F72.C0C67987@cisco.com> Date: Mon, 04 Nov 2002 09:17:06 -0600 From: Mark Bakke X-Mailer: Mozilla 4.77 [en] (X11; U; Linux 2.4.9-34.cisco.2 i686) X-Accept-Language: en, de MIME-Version: 1.0 To: IPS Subject: iSCSI boot and SNMP notifications Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ips@ece.cmu.edu Precedence: bulk Content-Transfer-Encoding: 7bit While implementing network boot using iSCSI, we realized that there is no current DHCP option for configuring SNMP notification (AKA trap) hosts. Without this option, there is no good way to notify a management station if a host fails to boot, for instance if it can't locate the iSCSI target given by the root-path option, or if the iSCSI target IP address doesn't respond, or if the boot disk is not really a boot disk. Since configuring this via DHCP seems like something more generally needed, I've submitted an I-D describing a new option for this, and posted it to the DHC and SNMP WGs. One question that these groups have is whether there are multiple people interested in doing this. I'd like to get an idea of how many iSCSI implementors would like to see this happen. The draft is available at: ftp://ftpeng.cisco.com/mbakke/ips/dhcp/draft-bakke-dhc-snmp-trap-01.txt Thanks, -- Mark A. Bakke Cisco Systems mbakke@cisco.com 763.398.1054 From owner-ips@ece.cmu.edu Mon Nov 4 16:47:54 2002 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA08782 for ; Mon, 4 Nov 2002 16:47:53 -0500 (EST) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id gA4KsA111366 for ips-outgoing; Mon, 4 Nov 2002 15:54:10 -0500 (EST) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from emailO.iomega.com (email.iomega.com [147.178.1.2] (may be forged)) by ece.cmu.edu (8.11.0/8.10.2) with SMTP id gA4Ks7H11357 for ; Mon, 4 Nov 2002 15:54:07 -0500 (EST) Received: from royntex01.iomegacorp.com by emailO.iomega.com via smtpd (for ECE.CMU.EDU [128.2.136.200]) with SMTP; 4 Nov 2002 20:54:07 UT Received: from sdontfps01.iomegacorp.com ([147.178.169.11]) by royntex01.iomegacorp.com with Microsoft SMTPSVC(5.0.2195.4453); Mon, 4 Nov 2002 13:53:59 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.0.5762.3 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C28444.4BBBE7E8" Subject: RE: iSCSI version 19 draft Date: Mon, 4 Nov 2002 12:53:58 -0800 Message-ID: Thread-Topic: iSCSI version 19 draft Thread-Index: AcKDdiJrRCfAwhRVSSKvOaXo4AVkygAzX6Kw From: "Sukanta Ganguly" To: X-OriginalArrivalTime: 04 Nov 2002 20:53:59.0975 (UTC) FILETIME=[4CBAD370:01C28444] Sender: owner-ips@ece.cmu.edu Precedence: bulk This is a multi-part message in MIME format. ------_=_NextPart_001_01C28444.4BBBE7E8 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable The Atlanta IEFT is on the same week as COMDEX. This is going to inhibit = the attendance of many (like me) who would like to spend time at Comdex = as well as the IETF. =20 Can the ips meeting be scheduled more than once (sometime around = thursday or so ) so that poeple like me can make arrangements to attend = both? =20 =20 Thanx SG -----Original Message----- From: Julian Satran [mailto:Julian_Satran@il.ibm.com]=20 Sent: Sunday, November 03, 2002 1:10 PM To: internet-drafts@ietf.org Cc: ips@ece.cmu.edu Subject: Fw: iSCSI version 19 draft =09 =09 On behalf of the team of authors and as part of the IETF-IPS working = group=20 I submit a draft for immediate publication.=20 =09 The text and pdf versions can be found at:=20 =09 http://www.haifa.il.ibm.com/satran/ips/draft-ietf-ips-iscsi-19.txt=20 http://www.haifa.il.ibm.com/satran/ips/draft-ietf-ips-iscsi-19.pdf=20 =09 This version completely replaces:=20 =09 draft-ietf-ips-iscsi-18.txt and pdf=20 =09 =09 The change marks are relative to version 18 and are ONLY typos and = minor edits.=20 All AD concerns and the "nits" where (hopefully) addressed.=20 =09 Julian Satran - IBM Research Laboratory at Haifa=20 =09 =09 =09 =09 =09 =09 =09 =09 =09 =09 =09 =09 =09 =09 =09 =09 =09 =09 =09 =09 =09 =09 =09 =09 =09 =09 =09 =09 =09 =09 =09 =09 =09 =09 =09 =09 ------_=_NextPart_001_01C28444.4BBBE7E8 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Message
The=20 Atlanta IEFT is on the same week as COMDEX. This is going to inhibit the = attendance of many (like me) who would like to spend time at Comdex as = well as=20 the IETF.
 
Can=20 the ips meeting be scheduled more than once (sometime around thursday or = so ) so=20 that poeple like me can make arrangements to attend = both?
 
 
Thanx
SG
-----Original Message-----
From: = Julian Satran=20 [mailto:Julian_Satran@il.ibm.com]
Sent: Sunday, November = 03, 2002=20 1:10 PM
To: internet-drafts@ietf.org
Cc:=20 ips@ece.cmu.edu
Subject: Fw: iSCSI version 19=20 draft






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

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

http://www.haifa.il.ibm.com/satran/ips/draft-ietf-ips-iscsi-19.t= xt=20
http://www.haifa.il.ibm.com/satran/ips/draft-ietf-ips-iscsi-19.p= df=20

This version completely = replaces:=20

draft-ietf-ips-iscsi-18.txt = and=20 pdf


The change = marks are=20 relative to version 18 and are ONLY typos and minor edits. =
All AD concerns and the "nits" where = (hopefully)=20 addressed.

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

















<= BR>
















=00 ------_=_NextPart_001_01C28444.4BBBE7E8-- From owner-ips@ece.cmu.edu Mon Nov 4 18:49: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 SAA15096 for ; Mon, 4 Nov 2002 18:49:38 -0500 (EST) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id gA4Mw3Y20358 for ips-outgoing; Mon, 4 Nov 2002 17:58:03 -0500 (EST) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from maho3msx2.isus.emc.com (maho3msx2.isus.emc.com [128.221.11.32]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id gA4Mw1H20350 for ; Mon, 4 Nov 2002 17:58:01 -0500 (EST) Received: by maho3msx2.isus.emc.com with Internet Mail Service (5.5.2653.19) id ; Mon, 4 Nov 2002 17:57:54 -0500 Message-ID: <277DD60FB639D511AC0400B0D068B71E0564C4E4@CORPMX14> From: Black_David@emc.com To: ganguly@iomega.com, ips@ece.cmu.edu Subject: RE: iSCSI version 19 draft Date: Mon, 4 Nov 2002 17:57:48 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C28455.985D1980" Sender: owner-ips@ece.cmu.edu Precedence: bulk This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_001_01C28455.985D1980 Content-Type: text/plain; charset="iso-8859-1" Rescheduling of the ips WG meeting in Atlanta is not possible now - the IETF schedule of meetings for the week is final at this point. Once I get the IPS agenda prepared (soon, in my "copious spare time"), everyone will see that there will be very little on it - I don't think we'll need the two hours allocated to us ... but I've been surprised before. Thanks, --David ---------------------------------------------------- David L. Black, Senior Technologist EMC Corporation, 176 South St., Hopkinton, MA 01748 +1 (508) 293-7953 **NEW** FAX: +1 (508) 293-7786 black_david@emc.com Mobile: +1 (978) 394-7754 ---------------------------------------------------- -----Original Message----- From: Sukanta Ganguly [mailto:ganguly@iomega.com] Sent: Monday, November 04, 2002 3:54 PM To: ips@ece.cmu.edu Subject: RE: iSCSI version 19 draft The Atlanta IEFT is on the same week as COMDEX. This is going to inhibit the attendance of many (like me) who would like to spend time at Comdex as well as the IETF. Can the ips meeting be scheduled more than once (sometime around thursday or so ) so that poeple like me can make arrangements to attend both? Thanx SG -----Original Message----- From: Julian Satran [mailto:Julian_Satran@il.ibm.com] Sent: Sunday, November 03, 2002 1:10 PM To: internet-drafts@ietf.org Cc: ips@ece.cmu.edu Subject: Fw: iSCSI version 19 draft On behalf of the team of authors and as part of the IETF-IPS working group I submit a draft for immediate publication. The text and pdf versions can be found at: http://www.haifa.il.ibm.com/satran/ips/draft-ietf-ips-iscsi-19.txt http://www.haifa.il.ibm.com/satran/ips/draft-ietf-ips-iscsi-19.pdf This version completely replaces: draft-ietf-ips-iscsi-18.txt and pdf The change marks are relative to version 18 and are ONLY typos and minor edits. All AD concerns and the "nits" where (hopefully) addressed. Julian Satran - IBM Research Laboratory at Haifa ------_=_NextPart_001_01C28455.985D1980 Content-Type: text/html; charset="iso-8859-1" Message
Rescheduling of the ips WG meeting in Atlanta is not possible now -
the IETF schedule of meetings for the week is final at this
point.  Once I get the IPS agenda prepared (soon, in my "copious spare
time"), everyone will see that there will be very little on it -
I don't think we'll need the two hours allocated to us ... but I've
been surprised before.
 
Thanks,
--David

----------------------------------------------------
David L. Black, Senior Technologist
EMC Corporation, 176 South St., Hopkinton, MA  01748
+1 (508) 293-7953 **NEW**     FAX: +1 (508) 293-7786
black_david@emc.com        Mobile: +1 (978) 394-7754
----------------------------------------------------

-----Original Message-----
From: Sukanta Ganguly [mailto:ganguly@iomega.com]
Sent: Monday, November 04, 2002 3:54 PM
To: ips@ece.cmu.edu
Subject: RE: iSCSI version 19 draft

The Atlanta IEFT is on the same week as COMDEX. This is going to inhibit the attendance of many (like me) who would like to spend time at Comdex as well as the IETF.
 
Can the ips meeting be scheduled more than once (sometime around thursday or so ) so that poeple like me can make arrangements to attend both?
 
 
Thanx
SG
-----Original Message-----
From: Julian Satran [mailto:Julian_Satran@il.ibm.com]
Sent: Sunday, November 03, 2002 1:10 PM
To: internet-drafts@ietf.org
Cc: ips@ece.cmu.edu
Subject: Fw: iSCSI version 19 draft






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

The text and pdf versions can be found at:

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

This version completely replaces:

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


The change marks are relative to version 18 and are ONLY typos and minor edits.
All AD concerns and the "nits" where (hopefully) addressed.

Julian Satran - IBM Research Laboratory at Haifa



































------_=_NextPart_001_01C28455.985D1980-- From owner-ips@ece.cmu.edu Mon Nov 4 18:51: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 SAA15151 for ; Mon, 4 Nov 2002 18:51:30 -0500 (EST) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id gA4NOqI22035 for ips-outgoing; Mon, 4 Nov 2002 18:24:52 -0500 (EST) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from hammer.brocade.com (sj6-b.brocade.com [63.121.140.220]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id gA4NOnH22029 for ; Mon, 4 Nov 2002 18:24:49 -0500 (EST) Received: from hq-ex-c2.brocade.com (hq-ex-c2.brocade.com [192.168.126.35]) by hammer.brocade.com (8.11.3/8.11.3) with ESMTP id gA4NOhL14990 for ; Mon, 4 Nov 2002 15:24:43 -0800 (PST) Received: by hq-ex-c2.brocade.com with Internet Mail Service (5.5.2653.19) id <4LHFG3QM>; Mon, 4 Nov 2002 15:24:43 -0800 Message-ID: From: Elizabeth Rodriguez To: ips@ece.cmu.edu Subject: IPS-All: Introducing the ID tracker Date: Mon, 4 Nov 2002 15:24:37 -0800 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C28459.57A0FFC0" Sender: owner-ips@ece.cmu.edu Precedence: bulk This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_001_01C28459.57A0FFC0 Content-Type: text/plain Hi all, Below is a new tool that can be used to check the status of a draft. https://datatracker.ietf.org/public/pidtracker.cgi Elizabeth -----Original Message----- From: Harald Tveit Alvestrand [mailto:harald@alvestrand.no] Sent: Monday, November 04, 2002 1:44 PM Subject: Introducing the ID tracker Hello, The IESG is always trying to work better. We have gotten a number of comments from the community that it is sometimes very hard to find out what the IESG is doing to documents, why documents take a long time to process, who makes comments, what the comments are and so on, and that this is a significant source of frustration for the community. For the last year or so, the secretariat has been working on a tool to help us keep track of what documents are on our plate, what state they are in and who is responsible for them; we call it the "ID tracker". It's been in use for about 6 months now, and has definitely improved our ability to keep track. For several months, the "status of items" pages on the IESG web pages have been generated from this tool, showing the high-order bit of who we think is responsible. In order to help you know more about what we are doing, we've decided to open up a public view of the ID tracker itself. This will allow you to search for the documents you want to look at, and for each document see: - What its current state is - What the history of IESG processing is - AD and IESG comments on the document - For documents in IESG consideration for standards track, what the individual ADs have indicated as their opinion on the document, and if they think there are problems with it, what the comments are. The last point is a revision of previous IESG policy, based on the feedback from the Yokohama plenary; we are now telling you the names that go with each comment from the IESG members. The system is far from perfect - you can tell from the history of documents that we've been changing this as we go along - but we hope that it will be a useful tool for people to figure out what the IESG is doing with their documents, and for them to have an easier time talking to the relevant ADs in order to get what we all want out of the process - relevant, high quality standards for the Internet. The tool and its documentation is found at https://datatracker.ietf.org/public/pidtracker.cgi The link to it is also visible on the IESG Web page. Welcome! The IESG ------_=_NextPart_001_01C28459.57A0FFC0 Content-Type: text/html Content-Transfer-Encoding: quoted-printable IPS-All: Introducing the ID tracker

Hi all,

Below is a new tool that can be used to check the = status of a draft.

https://datatracker.ietf.org/public/pidtracker.cgi=

Elizabeth
-----Original Message-----
From: Harald Tveit Alvestrand [mailto:harald@alvestrand.no]
Sent: Monday, November 04, 2002 1:44 PM
Subject: Introducing the ID tracker



Hello,

The IESG is always trying to work better.
We have gotten a number of comments from the = community that it is sometimes
very hard to find out what the IESG is doing to = documents, why documents
take a long time to process, who makes comments, = what the comments are and
so on, and that this is a significant source of = frustration for the
community.

For the last year or so, the secretariat has been = working on a tool to help
us keep track of what documents are on our plate, = what state they are in
and who is responsible for them; we call it the = "ID tracker". It's been in
use for about 6 months now, and has definitely = improved our ability to keep
track.

For several months, the "status of items" = pages on the IESG web pages have
been generated from this tool, showing the = high-order bit of who we think
is responsible.

In order to help you know more about what we are = doing, we've decided to
open up a public view of the ID tracker = itself.

This will allow you to search for the documents you = want to look at, and
for each document see:

- What its current state is
- What the history of IESG processing is
- AD and IESG comments on the document
- For documents in IESG consideration for standards = track, what the
individual ADs have indicated as their opinion on = the document, and if they
think there are problems with it, what the comments = are.

The last point is a revision of previous IESG policy, = based on the feedback
from the Yokohama plenary; we are now telling you = the names that go with
each comment from the IESG members.

The system is far from perfect - you can tell from = the history of documents
that we've been changing this as we go along - but = we hope that it will be
a useful tool for people to figure out what the IESG = is doing with their
documents, and for them to have an easier time = talking to the relevant ADs
in order to get what we all want out of the process = - relevant, high
quality standards for the Internet.

The tool and its documentation is found at

https://datatracker.ietf.org/public/pidtracker.cgi=

The link to it is also visible on the IESG Web = page.

Welcome!

          &nb= sp;   The IESG

------_=_NextPart_001_01C28459.57A0FFC0-- From owner-ips@ece.cmu.edu Wed Nov 6 11:57: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 LAA01542 for ; Wed, 6 Nov 2002 11:57:26 -0500 (EST) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id gA6G6F424315 for ips-outgoing; Wed, 6 Nov 2002 11:06:15 -0500 (EST) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from ietf.org (odin.ietf.org [132.151.1.176]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id gA6BWiH08720 for ; Wed, 6 Nov 2002 06:32:44 -0500 (EST) Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA12357; Wed, 6 Nov 2002 06:30:14 -0500 (EST) Message-Id: <200211061130.GAA12357@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; Cc: ips@ece.cmu.edu From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-ietf-ips-iscsi-slp-04.txt Date: Wed, 06 Nov 2002 06:30:14 -0500 Sender: owner-ips@ece.cmu.edu Precedence: bulk --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the IP Storage Working Group of the IETF. Title : Finding iSCSI Targets and Name Servers Using SLP Author(s) : M. Bakke et al. Filename : draft-ietf-ips-iscsi-slp-04.txt Pages : 22 Date : 2002-11-5 The iSCSI protocol provides a way for hosts to access SCSI devices over an IP network. This document defines the use of the Service Location Protocol (SLP) by iSCSI hosts, devices, and management services, along with the SLP service type templates that describe the services they provide. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-ips-iscsi-slp-04.txt To remove yourself from the IETF Announcement list, send a message to ietf-announce-request with the word unsubscribe in the body of the message. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-ips-iscsi-slp-04.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-ips-iscsi-slp-04.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <2002-11-5193300.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-ips-iscsi-slp-04.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-ips-iscsi-slp-04.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2002-11-5193300.I-D@ietf.org> --OtherAccess-- --NextPart-- From owner-ips@ece.cmu.edu Wed Nov 6 12:12:35 2002 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA02387 for ; Wed, 6 Nov 2002 12:12:34 -0500 (EST) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id gA6G6DD24306 for ips-outgoing; Wed, 6 Nov 2002 11:06:13 -0500 (EST) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from ietf.org (odin.ietf.org [132.151.1.176]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id gA6BWeH08709 for ; Wed, 6 Nov 2002 06:32:40 -0500 (EST) Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA12318; Wed, 6 Nov 2002 06:30:09 -0500 (EST) Message-Id: <200211061130.GAA12318@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; Cc: ips@ece.cmu.edu From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-ietf-ips-iscsi-mib-07.txt Date: Wed, 06 Nov 2002 06:30:09 -0500 Sender: owner-ips@ece.cmu.edu Precedence: bulk --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the IP Storage Working Group of the IETF. Title : Definitions of Managed Objects for iSCSI Author(s) : M. Bakke, J. Muchow, M. Krueger, T. McSweeney Filename : draft-ietf-ips-iscsi-mib-07.txt Pages : 70 Date : 2002-11-5 This memo defines a portion of the Management Information Base (MIB) for use with network management protocols in TCP/IP based internets. In particular it defines objects for managing a client using the iSCSI (SCSI over TCP) protocol. It is meant to match the latest version of iSCSI defined in [ISCSI]. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-ips-iscsi-mib-07.txt To remove yourself from the IETF Announcement list, send a message to ietf-announce-request with the word unsubscribe in the body of the message. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-ips-iscsi-mib-07.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-ips-iscsi-mib-07.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <2002-11-5193251.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-ips-iscsi-mib-07.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-ips-iscsi-mib-07.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2002-11-5193251.I-D@ietf.org> --OtherAccess-- --NextPart-- From owner-ips@ece.cmu.edu Thu Nov 7 02:00:51 2002 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA26910 for ; Thu, 7 Nov 2002 02:00:50 -0500 (EST) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id gA76NZm14808 for ips-outgoing; Thu, 7 Nov 2002 01:23:35 -0500 (EST) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from maho3msx2.isus.emc.com (maho3msx2.isus.emc.com [128.221.11.32]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id gA76NYH14802 for ; Thu, 7 Nov 2002 01:23:34 -0500 (EST) Received: by maho3msx2.isus.emc.com with Internet Mail Service (5.5.2653.19) id ; Thu, 7 Nov 2002 01:23:28 -0500 Message-ID: <277DD60FB639D511AC0400B0D068B71E0564C506@CORPMX14> From: Black_David@emc.com To: ips@ece.cmu.edu Subject: IPS: Atlanta agenda Date: Thu, 7 Nov 2002 01:23:24 -0500 Importance: high X-Priority: 1 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-ips@ece.cmu.edu Precedence: bulk Here's the agenda for Atlanta. Elizabeth and I need to see any additional requests for time ASAP, as this will be finalized in the next few days. We do not anticipate using the entire 2 hour time slot, so there should be time at the end of the meeting for questions/concerns/etc. about drafts that are not on the agenda (e.g., have completed WG Last Call). Thanks, --David IETF IP Storage (IPS) Working Group Atlanta IETF Meeting, November 18-21, 2002 ------------------------------------------- CHAIRS: David L. Black Elizabeth Rodriguez **NEW EMAIL** AGENDA: SUBJECT TO CHANGE Announcement: The IPS WG's work program is close to complete. All remaining WG drafts will go to WG Last Call shortly after Atlanta at the latest. Most of the IPS WG drafts are NOT listed on this agenda as their authors and WG co-chairs are not aware of any open technical issues requiring meeting time to discuss, and most have completed WG Last Call. ---- Monday, November 18, 1300-1500 ---- - Agenda Bashing and Administrivia (15 min) - BLUE SHEETS - NOTE WELL - Status of drafts - Future of IPS WG (chairs and ADs) - SCSI MIB (15 min) draft-ietf-ips-scsi-mib-04.txt Structure diagram available at: ftp://ftpeng.cisco.com/mbakke/ips/scsi-mib/Visio-scsi-uml-model-01.pdf Diagram showing relationships among SCSI family of MIBS available at: ftp://ftpeng.cisco.com/mbakke/ips/scsi-mib/Visio-scsi-mib-family-01.pdf - DHC support for iSCSI boot failure notification (15 min) draft-bakke-dhc-snmp-trap-00.txt If this draft is to go forward, it will do so in the DHC WG, but it's on the IPS agenda to discuss the problem and proposed approach to solving it. - NAA naming format for iSCSI (30 min) draft-krueger-iscsi-name-ext-00.txt This draft proposes to add a new .naa naming format to iSCSI in addition to the current .iqn and .eui formats. A significant motivation for this is an desire by T10 (ANSI organization that handles SCSI standards) to obtain consistent SCSI device naming across SCSI transports. The authors request that the IPS WG adopt this draft as an official work item. It would become a separate RFC rather than being folded into the main iSCSI draft. DESCRIPTION: The IP Storage WG works on using IP-based networks to transport block storage traffic. See http://www.ietf.org/html.charters/ips-charter.html From owner-ips@ece.cmu.edu Thu Nov 7 02:00:58 2002 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA27071 for ; Thu, 7 Nov 2002 02:00:58 -0500 (EST) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id gA76IhG14575 for ips-outgoing; Thu, 7 Nov 2002 01:18:43 -0500 (EST) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from mxic2.corp.emc.com (mxic2.us.dg.com [128.221.31.40]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id gA76IfH14571 for ; Thu, 7 Nov 2002 01:18:41 -0500 (EST) Received: by mxic2.corp.emc.com with Internet Mail Service (5.5.2653.19) id ; Thu, 7 Nov 2002 01:18:36 -0500 Message-ID: <277DD60FB639D511AC0400B0D068B71E0564C505@CORPMX14> From: Black_David@emc.com To: ips@ece.cmu.edu Subject: IPS: Status of Drafts - November 2002 Date: Thu, 7 Nov 2002 01:18:31 -0500 Importance: high X-Priority: 1 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-ips@ece.cmu.edu Precedence: bulk This is the (in)famous pre-meeting status of drafts email that summarizes (what the WG co-chairs believe to be) the current status of all IPS WG drafts. Please send corrections if we've missed anything. Thanks, --David IETF IP Storage (ips) Working Group WG Internet-Draft Status: November 2002 ------------------------------------ Summary: 23 drafts total: - 2 have been published as RFCs - 4 are in IETF Last Call - 4 have been forwarded to ADs/IESG after completing WG Last Call - 5 have completed WG Last Call with all technical issues resolved. Editorial updates, nit checks, and/or MIB advisor approval may be needed prior to forwarding to the ADs/IESG. - 1 has completed WG Last Call, and all technical issues are believed to be resolved, but another WG Last Call will be done to check the changes made as a result of the first WG Last Call. - 1 is in WG Last Call - 3 will not be published as RFCs (WG Last Call comment resolution) That leaves 3 drafts still to go through WG Last Call. IESG draft tracker - https://datatracker.ietf.org/public/pidtracker.cgi This tracks status of drafts that have been submitted to the ADs/IESG and indicates only the existence of those that have not. Status with respect to WG Last Call is not tracked by this tool. NOTE: PDF versions for some drafts are for ease of review only. The definitive format for RFCs is text, and it is the text versions that will be forwarded to the IESG for publication as RFCs. -- Security for all IPS protocols draft-ietf-ips-security-16.txt To be a proposed standard RFC. In IETF Last Call which will conclude on November 7. -- iSCSI draft-ietf-ips-iscsi-19.txt draft-ietf-ips-iscsi-19.pdf To become a proposed standard RFC. Has completed WG Last Call and been submitted to the ADs/IESG. -19 version responds to AD review comments and nit checking. draft-ietf-ips-iscsi-boot-07.txt To become a proposed standard RFC. Has completed WG Last Call and been submitted to the ADs/IESG. New version coming to correct nits. draft-ietf-ips-iscsi-reqmts-06.txt has been published as Informational RFC 3347. draft-ietf-ips-iscsi-name-disc-08.txt To become an informational RFC. Has completed WG Last Call and been submitted to the ADs/IESG. draft-ietf-ips-iscsi-slp-04.txt To become a proposed standard RFC. WG Last Call expected soon on the new -04 version. draft-ietf-ips-iscsi-string-prep-03.txt To become a proposed standard RFC. Has completed WG Last Call. Needs to be nit-checked before being forwarded to ADs/IESG. draft-ietf-ips-iscsi-mib-07.txt To be a proposed standard RFC. Has completed WG Last Call, -07 version contains resulting changes. Needs nit check and MIB advisor approval before forwarding to ADs/IESG. Structure diagram available at: ftp://ftpeng.cisco.com/mbakke/ips/iscsi-mib/Visio-ietf-iscsi-uml-model-05.pd f draft-ietf-ips-auth-mib-02.txt To be a proposed standard RFC. User identity information MIB split out from basic iSCSI MIB for more general use, but currently only being used for iSCSI. Has completed WG Last Call, needs nit check and MIB advisor approval before forwarding to ADs/IESG. Structure diagram available at: ftp://ftpeng.cisco.com/mbakke/ips/auth-mib/Visio-ietf-ips-auth-mib-01.pdf draft-sheinwald-iscsi-crc-01.txt has been published as Informational RFC 3385. -- FC Common Encapsulation draft-ietf-ips-fcencapsulation-08.txt draft-ietf-ips-fcencapsulation-08.pdf To be a proposed standard RFC. In IETF Last Call which will conclude on November 7. -- FCIP draft-ietf-ips-fcovertcpip-12.txt draft-ietf-ips-fcovertcpip-12.pdf To be a proposed standard RFC. In IETF Last Call which will conclude on November 7. draft-ietf-ips-fcip-slp-04.txt To be a proposed standard RFC. Has completed WG Last Call, and been submitted to ADs/IESG. draft-ietf-ips-fcip-mib-02.txt To be a proposed standard RFC. Has been restructured to align with new structure of FC Management MIB and been reviewed by the WG's MIB Technical Expert. In WG Last Call, which will end on November 10. -- iFCP draft-ietf-ips-ifcp-13.txt draft-ietf-ips-ifcp-13.pdf To be a proposed standard RFC. In IETF Last Call which will conclude on November 7. draft-ietf-ips-ifcp-mib-03.txt To be a proposed standard RFC. Has completed WG Last Call, and resulting editorial updates have been applied. Will be forwarded to ADs/IESG after review by the WG's MIB expert. -- iSNS draft-ietf-ips-isns-14.txt To be a proposed standard RFC. Completed first WG Last Call, but will need another one due to the volume of resulting changes. No technical issues are believed to be open. The -14 version is believed to contain all the required changes and will go to WG Last Call shortly. The related draft-ietf-dhc-isnsoption-03.txt requests allocation of a DHC option code for iSNS, and is being handled in the DHC WG. draft-ietf-ips-isns-mib-02.txt To be a proposed standard RFC. WG Last Call should be within next month. -- SCSI MIB draft-ietf-ips-scsi-mib-04.txt To be a proposed standard RFC. -04 version will go to WG Last Call soon. Structure diagram available at: ftp://ftpeng.cisco.com/mbakke/ips/scsi-mib/Visio-scsi-uml-model-01.pdf Diagram showing relationships among SCSI family of MIBS available at: ftp://ftpeng.cisco.com/mbakke/ips/scsi-mib/Visio-scsi-mib-family-01.pdf -- Fibre Channel Management MIB draft-ietf-ips-fcmgmt-mib-03.txt To be a proposed standard RFC. This work has been transferred to the IPS WG from the IPFC WG, and the scope has been expanded to include replacement of the FC Fabric Element MIB (RFC 2837). Has completed WG Last Call. -03 version contains minor changes resulting from WG Last Call and will be forwarded to ADs/IESG shortly. -- Last Call Drafts draft-ietf-ips-fcencap-wglc-01.txt draft-ietf-ips-fcip-wglc-02.txt draft-ietf-ips-ifcp-wglcc-00.txt These drafts will not be published as RFCs. They exist solely to record the resolution of WG Last Call comments on the FC Encapsulation, FCIP and iFCP drafts. ----- Document Completion Guesstimates ------ The drafts that have not completed WG Last Call fall into three categories: (1) Completed WG Last Call, but needs another one to check changes resulting from the first WG Last Call. - iSNS (2) In WG Last Call - FCIP MIB (ends November 10) (3) WG Last Call still needed for: - iSNS MIB - iSCSI SLP - SCSI MIB The WG co-chairs expect to announce WG Last Calls for some of the four remaining drafts that need them next week - the Last Calls will close at least a week after the Atlanta meetings. -- Potential Additional Work Additional drafts may be forthcoming on: - Issues involved in gateways and bridges between iSCSI and other SCSI protocols. There has been work in this area, but the draft was not submitted in time for Atlanta meeting. - Additional MIB(s) that extend the FC Management MIB to cover additional aspects of Fibre Channel. - iSNS extensions to support FCIP in addition to iFCP and iSNS. - Addition of a new iSCSI name type (NAA) in order to coordinate SCSI device naming across transports with T10 - this is motivated by VPD usage for multi-protocol devices rather than an iSCSI need for a third class of names. draft-krueger-iscsi-name-ext-00.txt - DHCP support for boot failure notification. draft-bakke-dhc-snmp-trap-00.txt Will also need review in dhc wg and from MIB/SNMP experts. From owner-ips@ece.cmu.edu Thu Nov 7 12:51:01 2002 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA04127 for ; Thu, 7 Nov 2002 12:51:01 -0500 (EST) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id gA7GoW429192 for ips-outgoing; Thu, 7 Nov 2002 11:50:32 -0500 (EST) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from front2.mail.megapathdsl.net (front2.mail.megapathdsl.net [66.80.60.30]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id gA7GoSH29186 for ; Thu, 7 Nov 2002 11:50:29 -0500 (EST) Received: from [168.103.215.118] (HELO DelliciousGlow) by front2.mail.megapathdsl.net (CommuniGate Pro SMTP 3.5.8) with ESMTP id 55282286 for ips@ece.cmu.edu; Thu, 07 Nov 2002 08:49:07 -0800 From: "Randy Jennings" To: Subject: ISCSI: NAA naming format Date: Thu, 7 Nov 2002 08:50:21 -0800 Organization: Data Transit Message-ID: <000001c2867d$c31dcfa0$f200000a@DelliciousGlow> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.4024 Importance: Normal In-Reply-To: <277DD60FB639D511AC0400B0D068B71E0564C506@CORPMX14> X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 Sender: owner-ips@ece.cmu.edu Precedence: bulk Content-Transfer-Encoding: 7bit I will not be in the Atlanta meeting, so I will have to open this can of worms here. > - NAA naming format for iSCSI (30 min) draft-krueger-iscsi-name-ext-00.txt > This draft proposes to add a new .naa naming format to iSCSI in > addition to the current .iqn and .eui formats. A significant > motivation for this is an desire by T10 (ANSI organization that > handles SCSI standards) to obtain consistent SCSI device > naming across SCSI transports. > > The authors request that the IPS WG adopt this draft as an official > work item. It would become a separate RFC rather than being folded > into the main iSCSI draft. I first want to say that whether the NAA naming format is adopted or not does not matter to me, but it matters to me if the following text is left in the Proposed Standard version of the iSCSI draft: (pg39, line from start of document 2340) As these two naming authority designators will suffice in nearly every case for both software and hardware-based entities, the creation of additional type designators is prohibited. Now, it does not use the MUST language required by IETF drafts (as I understand it), but prohibited is a strong word for me. (On a side note, it would be interesting to open up a thesaurus and search for other such words in the draft (i.e. 'mandatory').) I do not want to see a sorry chap reading this draft, see the word 'prohibited' and not ever worry about another name format ever being made. It gives this nice sense of (false?) security that made me like math and standards in the first place. Sincerely, Randy Jennings Data Transit From owner-ips@ece.cmu.edu Thu Nov 7 18:28: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 SAA18005 for ; Thu, 7 Nov 2002 18:28:22 -0500 (EST) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id gA7Ml4g26940 for ips-outgoing; Thu, 7 Nov 2002 17:47:04 -0500 (EST) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from ietf.org (odin.ietf.org [132.151.1.176]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id gA7BRvH09413 for ; Thu, 7 Nov 2002 06:27:57 -0500 (EST) Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA10909; Thu, 7 Nov 2002 06:25:26 -0500 (EST) Message-Id: <200211071125.GAA10909@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; Cc: ips@ece.cmu.edu From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-ietf-ips-iscsi-19.txt,.pdf Date: Thu, 07 Nov 2002 06:25:26 -0500 Sender: owner-ips@ece.cmu.edu Precedence: bulk --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the IP Storage Working Group of the IETF. Title : iSCSI Author(s) : J. Satran et al. Filename : draft-ietf-ips-iscsi-19.txt,.pdf Pages : 291 Date : 2002-11-6 The Small Computer Systems Interface (SCSI) is a popular family of protocols that enable systems to communicate with I/O devices, especially storage devices. SCSI protocols are request/response application protocols with a common standardized architecture model and basic command set as well as standardized command sets for different device classes (disks, tapes, media-changers etc.). As system interconnects move from the classical bus structure to a network structure SCSI has to be mapped to network transport protocols. IP networks now meet the performance requirements of fast system interconnects and as such are good candidates to 'carry' SCSI. This document describes a transport protocol for SCSI that works on top of TCP. The iSCSI protocol aims to be fully compliant with the standardized SCSI architectural model. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-ips-iscsi-19.txt To remove yourself from the IETF Announcement list, send a message to ietf-announce-request with the word unsubscribe in the body of the message. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-ips-iscsi-19.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-ips-iscsi-19.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <2002-11-6174905.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-ips-iscsi-19.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-ips-iscsi-19.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2002-11-6174905.I-D@ietf.org> --OtherAccess-- --NextPart-- From owner-ips@ece.cmu.edu Fri Nov 8 01:30:00 2002 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA28087 for ; Fri, 8 Nov 2002 01:30:00 -0500 (EST) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id gA85i4M18636 for ips-outgoing; Fri, 8 Nov 2002 00:44:04 -0500 (EST) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from atlrel7.hp.com (atlrel7.hp.com [156.153.255.213]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id gA85i1H18630 for ; Fri, 8 Nov 2002 00:44:01 -0500 (EST) Received: from rosemail.rose.hp.com (rosemail.rose.hp.com [15.96.64.26]) by atlrel7.hp.com (Postfix) with ESMTP id A4F67804E23; Fri, 8 Nov 2002 00:44:00 -0500 (EST) Received: from swathi (atl2nai160097.ssr.hp.com [15.228.160.97]) by rosemail.rose.hp.com with SMTP (8.7.1/8.7.3 SMKit7.02) id VAA26705; Thu, 7 Nov 2002 21:43:57 -0800 (PST) Message-ID: <002801c286e9$d4a68520$61a0e40f@rose.hp.com> From: "Mallikarjun C." To: "Randy Jennings" , References: <000001c2867d$c31dcfa0$f200000a@DelliciousGlow> Subject: Re: ISCSI: NAA naming format Date: Thu, 7 Nov 2002 21:42:27 -0800 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2600.0000 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 Sender: owner-ips@ece.cmu.edu Precedence: bulk Content-Transfer-Encoding: 7bit Good catch. The statement would need to be modified to state that: this version of the iSCSI draft allows only two name type designators, and using user-defined name type designators is prohibited. Implementations complying with the iSCSI RFC would then support only those two formats, while new name formats may in addition be supported based on compliance to additional RFCs, as may be approved by the WG from time to time. Thanks. -- Mallikarjun Mallikarjun Chadalapaka Networked Storage Architecture Network Storage Solutions Hewlett-Packard MS 5668 Roseville CA 95747 cbm@rose.hp.com ----- Original Message ----- From: "Randy Jennings" To: Sent: Thursday, November 07, 2002 8:50 AM Subject: ISCSI: NAA naming format > I will not be in the Atlanta meeting, so I will have to open this can of > worms here. > > > - NAA naming format for iSCSI (30 min) > draft-krueger-iscsi-name-ext-00.txt > > This draft proposes to add a new .naa naming format to iSCSI in > > addition to the current .iqn and .eui formats. A significant > > motivation for this is an desire by T10 (ANSI organization that > > handles SCSI standards) to obtain consistent SCSI device > > naming across SCSI transports. > > > > The authors request that the IPS WG adopt this draft as an > official > > work item. It would become a separate RFC rather than being > folded > > into the main iSCSI draft. > I first want to say that whether the NAA naming format is adopted or not > does not matter to me, but it matters to me if the following text is > left in the Proposed Standard version of the iSCSI draft: > > (pg39, line from start of document 2340) > As these two naming authority designators will suffice in nearly > every case for both software and hardware-based entities, the > creation of additional type designators is prohibited. > > Now, it does not use the MUST language required by IETF drafts (as I > understand it), but prohibited is a strong word for me. (On a side > note, it would be interesting to open up a thesaurus and search for > other such words in the draft (i.e. 'mandatory').) > > I do not want to see a sorry chap reading this draft, see the word > 'prohibited' and not ever worry about another name format ever being > made. It gives this nice sense of (false?) security that made me like > math and standards in the first place. > > Sincerely, > Randy Jennings > Data Transit > > From owner-ips@ece.cmu.edu Fri Nov 8 15:52:06 2002 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA13532 for ; Fri, 8 Nov 2002 15:52:05 -0500 (EST) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id gA8K45i16746 for ips-outgoing; Fri, 8 Nov 2002 15:04:05 -0500 (EST) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from hammer.brocade.com (sj6-b.brocade.com [63.121.140.220]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id gA8K41H16736 for ; Fri, 8 Nov 2002 15:04:01 -0500 (EST) Received: from hq-ex-c2.brocade.com (hq-ex-c2.brocade.com [192.168.126.35]) by hammer.brocade.com (8.11.3/8.11.3) with ESMTP id gA8JxoL22816; Fri, 8 Nov 2002 11:59:50 -0800 (PST) Received: by hq-ex-c2.brocade.com with Internet Mail Service (5.5.2653.19) id <4LHF2N01>; Fri, 8 Nov 2002 11:59:50 -0800 Message-ID: From: Elizabeth Rodriguez To: "Mallikarjun C." , Randy Jennings , ips@ece.cmu.edu Subject: RE: ISCSI: NAA naming format Date: Fri, 8 Nov 2002 11:59:49 -0800 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C28761.64BA3EA0" Sender: owner-ips@ece.cmu.edu Precedence: bulk This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_001_01C28761.64BA3EA0 Content-Type: text/plain; charset="iso-8859-1" WG Chair hat on The iSCSI draft has completed working group last call, and no more changes may be made to that draft, unless explicitly requested by the IESG or the ADs. So, it is unlikely that the iSCSI draft would be modified in the manner suggested below. That said, RFCs may be updated by other RFCs, and such updates are noted on the RFC web page. Should the proposal be accepted, this is likely what would happen in this case. Elizabeth Rodriguez IPS WG chair -----Original Message----- From: Mallikarjun C. [mailto:cbm@rose.hp.com] Sent: Thursday, November 07, 2002 9:42 PM To: Randy Jennings; ips@ece.cmu.edu Subject: Re: ISCSI: NAA naming format Good catch. The statement would need to be modified to state that: this version of the iSCSI draft allows only two name type designators, and using user-defined name type designators is prohibited. Implementations complying with the iSCSI RFC would then support only those two formats, while new name formats may in addition be supported based on compliance to additional RFCs, as may be approved by the WG from time to time. Thanks. -- Mallikarjun Mallikarjun Chadalapaka Networked Storage Architecture Network Storage Solutions Hewlett-Packard MS 5668 Roseville CA 95747 cbm@rose.hp.com ----- Original Message ----- From: "Randy Jennings" To: Sent: Thursday, November 07, 2002 8:50 AM Subject: ISCSI: NAA naming format > I will not be in the Atlanta meeting, so I will have to open this can of > worms here. > > > - NAA naming format for iSCSI (30 min) > draft-krueger-iscsi-name-ext-00.txt > > This draft proposes to add a new .naa naming format to iSCSI in > > addition to the current .iqn and .eui formats. A significant > > motivation for this is an desire by T10 (ANSI organization that > > handles SCSI standards) to obtain consistent SCSI device > > naming across SCSI transports. > > > > The authors request that the IPS WG adopt this draft as an > official > > work item. It would become a separate RFC rather than being > folded > > into the main iSCSI draft. > I first want to say that whether the NAA naming format is adopted or not > does not matter to me, but it matters to me if the following text is > left in the Proposed Standard version of the iSCSI draft: > > (pg39, line from start of document 2340) > As these two naming authority designators will suffice in nearly > every case for both software and hardware-based entities, the > creation of additional type designators is prohibited. > > Now, it does not use the MUST language required by IETF drafts (as I > understand it), but prohibited is a strong word for me. (On a side > note, it would be interesting to open up a thesaurus and search for > other such words in the draft (i.e. 'mandatory').) > > I do not want to see a sorry chap reading this draft, see the word > 'prohibited' and not ever worry about another name format ever being > made. It gives this nice sense of (false?) security that made me like > math and standards in the first place. > > Sincerely, > Randy Jennings > Data Transit > > ------_=_NextPart_001_01C28761.64BA3EA0 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable RE: ISCSI: NAA naming format

WG Chair hat on

The iSCSI draft has completed working group last = call, and no more changes may be made to that draft, unless explicitly = requested by the IESG or the ADs.

So, it is unlikely that the iSCSI draft would be = modified in the manner suggested below.

That said, RFCs may be updated by other RFCs, and = such updates are noted on the RFC web page.
Should the proposal be accepted, this is likely what = would happen in this case.

Elizabeth Rodriguez
IPS WG chair


-----Original Message-----
From: Mallikarjun C. [mailto:cbm@rose.hp.com]
Sent: Thursday, November 07, 2002 9:42 PM
To: Randy Jennings; ips@ece.cmu.edu
Subject: Re: ISCSI: NAA naming format


Good catch.

The statement would need to be modified to state = that: this version
of the iSCSI draft allows only two name type = designators, and using
user-defined name type designators is = prohibited.

Implementations complying with the iSCSI RFC would = then support
only those two formats, while new name formats may = in addition be
supported based on compliance to additional RFCs, as = may be approved
by the WG from time to time.

Thanks.
--
Mallikarjun

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

----- Original Message -----
From: "Randy Jennings" = <randyj@data-transit.com>
To: <ips@ece.cmu.edu>
Sent: Thursday, November 07, 2002 8:50 AM
Subject: ISCSI: NAA naming format


> I will not be in the Atlanta meeting, so I will = have to open this can of
> worms here.
>
> > - NAA naming format for iSCSI (30 = min)
> draft-krueger-iscsi-name-ext-00.txt
> > This draft proposes to add a new .naa = naming format to iSCSI in
> > addition to the current .iqn and .eui = formats.  A significant
> > motivation for this is an desire by T10 = (ANSI organization that
> > handles SCSI standards) to obtain = consistent SCSI device
> > naming across SCSI transports.
> >
> > The authors request that the IPS WG adopt = this draft as an
> official
> > work item.  It would become a = separate RFC rather than being
> folded
> > into the main iSCSI draft.
> I first want to say that whether the NAA naming = format is adopted or not
> does not matter to me, but it matters to me if = the following text is
> left in the Proposed Standard version of the = iSCSI draft:
>
> (pg39, line from start of document 2340)
>    As these two naming authority = designators will suffice in nearly
>    every case for both software = and hardware-based entities, the
>    creation of additional type = designators is prohibited.
>
> Now, it does not use the MUST language required = by IETF drafts (as I
> understand it), but prohibited is a strong word = for me.  (On a side
> note, it would be interesting to open up a = thesaurus and search for
> other such words in the draft (i.e. = 'mandatory').)
>
> I do not want to see a sorry chap reading this = draft, see the word
> 'prohibited' and not ever worry about another = name format ever being
> made.  It gives this nice sense of = (false?) security that made me like
> math and standards in the first place.
>
> Sincerely,
> Randy Jennings
> Data Transit
>
>

------_=_NextPart_001_01C28761.64BA3EA0-- From owner-ips@ece.cmu.edu Sun Nov 10 20:04:31 2002 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA27755 for ; Sun, 10 Nov 2002 20:04:31 -0500 (EST) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id gAB0B3G15431 for ips-outgoing; Sun, 10 Nov 2002 19:11:03 -0500 (EST) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from mxic2.corp.emc.com (mxic2.us.dg.com [128.221.31.40]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id gAB0B2H15427 for ; Sun, 10 Nov 2002 19:11:02 -0500 (EST) Received: by mxic2.corp.emc.com with Internet Mail Service (5.5.2653.19) id ; Sun, 10 Nov 2002 19:10:42 -0500 Message-ID: <277DD60FB639D511AC0400B0D068B71E0814B359@CORPMX14> From: Black_David@emc.com To: ips@ece.cmu.edu Subject: iSCSI: requirements terminology Date: Sun, 10 Nov 2002 19:10:32 -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 I've seen some confusion over use of words to express requirements in the iSCSI draft. There are a couple of important points to keep in mind: (1) Unless there is some clear reason in the text of the iSCSI draft to interpret them in some other fashion, "prohibited" is equivalent to "MUST NOT" and "mandatory" is equivalent to "MUST" (in their RFC 2119 meaning in both cases). While RFC 2119 terms provide clarity in requirement statements, the IETF does not require that all requirements be expressed using RFC 2119 terms, and it would certainly be wrong to interpret "prohibited" and "mandatory" as not stating requirements solely because those two terms are not defined in RFC 2119. (2) OTOH, use of an RFC 2119-defined term in lower case (e.g., "must", "should") assigns the common usage (i.e., dictionary) meaning to that term rather than its RFC 2119 meaning. Such a term may still express a requirement, but that depends on the specific usage and context. It is also the case that the common usage meaning of "should" is weaker than the RFC 2119 meaning of "SHOULD" (and similarly for "should not" vs. "SHOULD NOT"). It is generally reasonable to initially assume that use of a lower case version of an RFC 2119 term was a deliberate decision made by the draft author(s) and/or the WG to limit usage of RFC 2119 terms in accordance with the guidance in Section 6 of RFC 2119, but this needs to be checked based on the actual usage and context in each case. Thanks, --David ---------------------------------------------------- David L. Black, Senior Technologist EMC Corporation, 176 South St., Hopkinton, MA 01748 +1 (508) 293-7953 **NEW** FAX: +1 (508) 293-7786 black_david@emc.com Mobile: +1 (978) 394-7754 ---------------------------------------------------- From owner-ips@ece.cmu.edu Mon Nov 11 11:23:33 2002 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA23658 for ; Mon, 11 Nov 2002 11:23:33 -0500 (EST) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id gABFcaA05612 for ips-outgoing; Mon, 11 Nov 2002 10:38:36 -0500 (EST) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from mxic2.corp.emc.com (mxic2.us.dg.com [128.221.31.40]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id gABFcWH05608 for ; Mon, 11 Nov 2002 10:38:32 -0500 (EST) Received: by mxic2.corp.emc.com with Internet Mail Service (5.5.2653.19) id ; Mon, 11 Nov 2002 10:38:26 -0500 Message-ID: <277DD60FB639D511AC0400B0D068B71E0564C518@CORPMX14> From: Black_David@emc.com To: ips@ece.cmu.edu, agenda@ietf.org Cc: mankin@ISI.EDU, sob@harvard.edu Subject: IP Storage (ips) Atlanta agenda Date: Mon, 11 Nov 2002 10:38:17 -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 Sending again, just in case something ate the first attempt. I've also appended the status of drafts as of about a week ago. Apologies if this is a duplicate, --David IETF IP Storage (IPS) Working Group Atlanta IETF Meeting, November 18-21, 2002 ------------------------------------------- CHAIRS: David L. Black Elizabeth Rodriguez **NEW EMAIL** AGENDA: SUBJECT TO CHANGE Announcement: The IPS WG's work program is close to complete. All remaining WG drafts will go to WG Last Call shortly after Atlanta at the latest. Most of the IPS WG drafts are NOT listed on this agenda as their authors and WG co-chairs are not aware of any open technical issues requiring meeting time to discuss, and most have completed WG Last Call. ---- Monday, November 18, 1300-1500 ---- - Agenda Bashing and Administrivia (15 min) - BLUE SHEETS - NOTE WELL - Status of drafts - Future of IPS WG (chairs and ADs) - SCSI MIB (15 min) draft-ietf-ips-scsi-mib-04.txt Structure diagram available at: ftp://ftpeng.cisco.com/mbakke/ips/scsi-mib/Visio-scsi-uml-model-01.pdf Diagram showing relationships among SCSI family of MIBS available at: ftp://ftpeng.cisco.com/mbakke/ips/scsi-mib/Visio-scsi-mib-family-01.pdf - DHC support for iSCSI boot failure notification (15 min) draft-bakke-dhc-snmp-trap-01.txt If this draft is to go forward, it will do so in the DHC WG, but it's on the agenda here to discuss the problem and proposed approach to solving it. - NAA naming format for iSCSI (30 min) draft-krueger-iscsi-name-ext-00.txt This draft proposes to add a new .naa naming format to iSCSI in addition to the current .iqn and .eui formats. A significant motivation for this is an desire by T10 (ANSI organization that handles SCSI standards) to obtain consistent SCSI device naming across SCSI transports. The authors request that the IPS WG adopt this draft as an official work item. It would become a separate RFC rather than being folded into the main iSCSI draft. - Any other business/questions (time remaining) DESCRIPTION: The IP Storage WG works on using IP-based networks to transport block storage traffic. See http://www.ietf.org/html.charters/ips-charter.html IETF IP Storage (ips) Working Group WG Internet-Draft Status: November 2002 ------------------------------------ Summary: 23 drafts total: - 2 have been published as RFCs - 4 are in IETF Last Call - 4 have been forwarded to ADs/IESG after completing WG Last Call - 5 have completed WG Last Call with all technical issues resolved. Editorial updates, nit checks, and/or MIB advisor approval may be needed prior to forwarding to the ADs/IESG. - 1 has completed WG Last Call, and all technical issues are believed to be resolved, but another WG Last Call will be done to check the changes made as a result of the first WG Last Call. - 1 is in WG Last Call - 3 will not be published as RFCs (WG Last Call comment resolution) That leaves 3 drafts still to go through WG Last Call. IESG draft tracker - https://datatracker.ietf.org/public/pidtracker.cgi This tracks status of drafts that have been submitted to the ADs/IESG and indicates only the existence of those that have not. Status with respect to WG Last Call is not tracked by this tool. NOTE: PDF versions for some drafts are for ease of review only. The definitive format for RFCs is text, and it is the text versions that will be forwarded to the IESG for publication as RFCs. -- Security for all IPS protocols draft-ietf-ips-security-16.txt To be a proposed standard RFC. In IETF Last Call which will conclude on November 7. -- iSCSI draft-ietf-ips-iscsi-19.txt draft-ietf-ips-iscsi-19.pdf To become a proposed standard RFC. Has completed WG Last Call and been submitted to the ADs/IESG. -19 version responds to AD review comments and nit checking. draft-ietf-ips-iscsi-boot-07.txt To become a proposed standard RFC. Has completed WG Last Call annd been submitted to the ADs/IESG. New version coming to correct nits. draft-ietf-ips-iscsi-reqmts-06.txt has been published as Informational RFC 3347. draft-ietf-ips-iscsi-name-disc-08.txt To become an informational RFC. Has completed WG Last Call and been submitted to the ADs/IESG. draft-ietf-ips-iscsi-slp-04.txt To become a proposed standard RFC. WG Last Call expected soon on the new -04 version. draft-ietf-ips-iscsi-string-prep-03.txt To become a proposed standard RFC. Has completed WG Last Call. Needs to be nit-checked before being forwarded to ADs/IESG. draft-ietf-ips-iscsi-mib-07.txt To be a proposed standard RFC. Has completed WG Last Call, -07 version contains resulting changes. Needs nit check and MIB advisor approval before forwarding to ADs/IESG. Structure diagram available at: ftp://ftpeng.cisco.com/mbakke/ips/iscsi-mib/Visio-ietf-iscsi-uml-model-05.pd f draft-ietf-ips-auth-mib-02.txt To be a proposed standard RFC. User identity information MIB split out from basic iSCSI MIB for more general use, but currently only being used for iSCSI. Has completed WG Last Call, needs nit check and MIB advisor approval before forwarding to ADs/IESG. Structure diagram available at: ftp://ftpeng.cisco.com/mbakke/ips/auth-mib/Visio-ietf-ips-auth-mib-01.pdf draft-sheinwald-iscsi-crc-01.txt has been published as Informational RFC 3385. -- FC Common Encapsulation draft-ietf-ips-fcencapsulation-08.txt draft-ietf-ips-fcencapsulation-08.pdf To be a proposed standard RFC. In IETF Last Call which will conclude on November 7. -- FCIP draft-ietf-ips-fcovertcpip-12.txt draft-ietf-ips-fcovertcpip-12.pdf To be a proposed standard RFC. In IETF Last Call which will conclude on November 7. draft-ietf-ips-fcip-slp-04.txt To be a proposed standard RFC. Has completed WG Last Call, and been submitted to ADs/IESG. draft-ietf-ips-fcip-mib-02.txt To be a proposed standard RFC. Has been restructured to align with new structure of FC Management MIB and been reviewed by the WG's MIB Technical Expert. In WG Last Call, which will end on November 10. -- iFCP draft-ietf-ips-ifcp-13.txt draft-ietf-ips-ifcp-13.pdf To be a proposed standard RFC. In IETF Last Call which will conclude on November 7. draft-ietf-ips-ifcp-mib-03.txt To be a proposed standard RFC. Has completed WG Last Call, and resulting editorial updates have been applied. Will be forwarded to ADs/IESG after review by the WG's MIB expert. -- iSNS draft-ietf-ips-isns-14.txt To be a proposed standard RFC. Completed first WG Last Call, but will need another one due to the volume of resulting changes. No technical issues are believed to be open. The -14 version is believed to contain all the required changes and will go to WG Last Call shortly. The related draft-ietf-dhc-isnsoption-03.txt requests allocation of a DHC option code for iSNS, and is being handled in the DHC WG. draft-ietf-ips-isns-mib-02.txt To be a proposed standard RFC. WG Last Call should be within next month. -- SCSI MIB draft-ietf-ips-scsi-mib-04.txt To be a proposed standard RFC. -04 version will go to WG Last Call soon. Structure diagram available at: ftp://ftpeng.cisco.com/mbakke/ips/scsi-mib/Visio-scsi-uml-model-01.pdf Diagram showing relationships among SCSI family of MIBS available at: ftp://ftpeng.cisco.com/mbakke/ips/scsi-mib/Visio-scsi-mib-family-01.pdf -- Fibre Channel Management MIB draft-ietf-ips-fcmgmt-mib-03.txt To be a proposed standard RFC. This work has been transferred to the IPS WG from the IPFC WG, and the scope has been expanded to include replacement of the FC Fabric Element MIB (RFC 2837). Has completed WG Last Call. -03 version contains minor changes resulting from WG Last Call and will be forwarded to ADs/IESG shortly. -- Last Call Drafts draft-ietf-ips-fcencap-wglc-01.txt draft-ietf-ips-fcip-wglc-02.txt draft-ietf-ips-ifcp-wglcc-00.txt These drafts will not be published as RFCs. They exist solely to record the resolution of WG Last Call comments on the FC Encapsulation, FCIP and iFCP drafts. ----- Document Completion Guesstimates ------ The drafts that have not completed WG Last Call fall into three categories: (1) Completed WG Last Call, but needs another one to check changes resulting from the first WG Last Call. - iSNS (2) In WG Last Call - FCIP MIB (ends November 10) (3) WG Last Call still needed for: - iSNS MIB - iSCSI SLP - SCSI MIB The WG co-chairs expect to announce WG Last Calls for some of the four remaining drafts that need them next week - the Last Calls will close at least a week after the Atlanta meetings. -- Potential Additional Work Additional drafts may be forthcoming on: - Issues involved in gateways and bridges between iSCSI and other SCSI protocols. There has been work in this area, but the draft was not submitted in time for Atlanta meeting. - Additional MIB(s) that extend the FC Management MIB to cover additional aspects of Fibre Channel. - iSNS extensions to support FCIP in addition to iFCP and iSNS. - Addition of a new iSCSI name type (NAA) in order to coordinate SCSI device naming across transports with T10 - this is motivated by VPD usage for multi-protocol devices rather than an iSCSI need for a third class of names. draft-krueger-iscsi-name-ext-00.txt - DHCP support for boot failure notification. draft-bakke-dhc-snmp-trap-00.txt Will also need review in dhc wg and from MIB/SNMP experts. From mailnull@www1.ietf.org Mon Nov 11 15:53:20 2002 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA01133 for ; Mon, 11 Nov 2002 15:53:20 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id gABKtSx02761 for ips-archive@odin.ietf.org; Mon, 11 Nov 2002 15:55:28 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id gABKtSv02758 for ; Mon, 11 Nov 2002 15:55:28 -0500 Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA01125 for ; Mon, 11 Nov 2002 15:52:49 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id gABKqxv02644; Mon, 11 Nov 2002 15:52:59 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id gABKmAv02499 for ; Mon, 11 Nov 2002 15:48:10 -0500 Received: from mail7.atl.registeredsite.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA00900 for ; Mon, 11 Nov 2002 15:45:31 -0500 (EST) Received: from imta01a2.registeredsite.com (imta01a2.registeredsite.com [64.225.255.10]) by mail7.atl.registeredsite.com (8.12.2/8.12.5) with ESMTP id gABKm3jx009310 for ; Mon, 11 Nov 2002 15:48:03 -0500 Received: from LTSRAMPONI ([66.80.35.240]) by imta01a2.registeredsite.com with SMTP id <20021111204802.DIND4614.imta01a2.registeredsite.com@LTSRAMPONI> for ; Mon, 11 Nov 2002 15:48:02 -0500 From: "Steve" To: Date: Mon, 11 Nov 2002 15:54:23 -0500 Message-ID: <001501c289c4$846349d0$7501a8c0@optimaleng.com> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook CWS, Build 9.0.2416 (9.0.2911.0) Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4807.1700 Content-Transfer-Encoding: 7bit Subject: [Ips] jiob X-BeenThere: ips@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IP Storage List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Can this role be posted on the PDL site? Our client in the bostos 495 belt area is seeking senior to principal level developers with extensive storage experience, specifically with SCSI and Fibre Channel. Contract or possibly perm. Must be local, no relo. The tasks will involve embedded systems work moving the host based drivers, firmware and programming functionality to on chip. Candidates must have over 5 yrs of SCSI and/or FC, and embedded systems experience. Stephen Ramponi OPTIMAL ENGINEERING PARTNERS "Resources and Expertise for Embedded Systems Development" www.OptimalEng.com (978) 256-1113 ext 101 sramponi@optimaleng.com _______________________________________________ Ips mailing list Ips@ietf.org https://www1.ietf.org/mailman/listinfo/ips From ips-admin@ietf.org Mon Nov 11 15:53:30 2002 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA01167 for ; Mon, 11 Nov 2002 15:53:29 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id gABKqxv02644; Mon, 11 Nov 2002 15:52:59 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id gABKmAv02499 for ; Mon, 11 Nov 2002 15:48:10 -0500 Received: from mail7.atl.registeredsite.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA00900 for ; Mon, 11 Nov 2002 15:45:31 -0500 (EST) Received: from imta01a2.registeredsite.com (imta01a2.registeredsite.com [64.225.255.10]) by mail7.atl.registeredsite.com (8.12.2/8.12.5) with ESMTP id gABKm3jx009310 for ; Mon, 11 Nov 2002 15:48:03 -0500 Received: from LTSRAMPONI ([66.80.35.240]) by imta01a2.registeredsite.com with SMTP id <20021111204802.DIND4614.imta01a2.registeredsite.com@LTSRAMPONI> for ; Mon, 11 Nov 2002 15:48:02 -0500 From: "Steve" To: Date: Mon, 11 Nov 2002 15:54:23 -0500 Message-ID: <001501c289c4$846349d0$7501a8c0@optimaleng.com> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook CWS, Build 9.0.2416 (9.0.2911.0) Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4807.1700 Content-Transfer-Encoding: 7bit Subject: [Ips] jiob X-BeenThere: ips@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IP Storage List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Can this role be posted on the PDL site? Our client in the bostos 495 belt area is seeking senior to principal level developers with extensive storage experience, specifically with SCSI and Fibre Channel. Contract or possibly perm. Must be local, no relo. The tasks will involve embedded systems work moving the host based drivers, firmware and programming functionality to on chip. Candidates must have over 5 yrs of SCSI and/or FC, and embedded systems experience. Stephen Ramponi OPTIMAL ENGINEERING PARTNERS "Resources and Expertise for Embedded Systems Development" www.OptimalEng.com (978) 256-1113 ext 101 sramponi@optimaleng.com _______________________________________________ Ips mailing list Ips@ietf.org https://www1.ietf.org/mailman/listinfo/ips From owner-ips@ece.cmu.edu Tue Nov 12 09:20:02 2002 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA01101 for ; Tue, 12 Nov 2002 09:20:01 -0500 (EST) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id gACDPuX27438 for ips-outgoing; Tue, 12 Nov 2002 08:25:56 -0500 (EST) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from mailhub.lss.emc.com (xdch.emc.com [168.159.1.79]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id gACDPrH27433 for ; Tue, 12 Nov 2002 08:25:53 -0500 (EST) Received: from emc.com (emcmail.lss.emc.com [168.159.48.78]) by mailhub.lss.emc.com (Switch-2.2.0/Switch-2.2.0) with ESMTP id gACA9wr23836; Tue, 12 Nov 2002 05:09:58 -0500 (EST) Received: from mxic1.isus.emc.com ([168.159.129.100]) by emc.com (8.10.1/8.10.1) with ESMTP id gACA9s718698; Tue, 12 Nov 2002 05:09:54 -0500 (EST) Received: by MXIC1 with Internet Mail Service (5.5.2653.19) id ; Tue, 12 Nov 2002 05:09:52 -0500 Message-ID: <277DD60FB639D511AC0400B0D068B71E0564C517@CORPMX14> From: Black_David@emc.com To: agenda@ietf.org, ips@ece.cmu.edu Cc: sob@harvard.edu, mankin@ISI.EDU Subject: IP Storage Atlanta Agenda Date: Sun, 10 Nov 2002 19:52:13 -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 IETF IP Storage (IPS) Working Group Atlanta IETF Meeting, November 18-21, 2002 ------------------------------------------- CHAIRS: David L. Black Elizabeth Rodriguez **NEW EMAIL** AGENDA: SUBJECT TO CHANGE Announcement: The IPS WG's work program is close to complete. All remaining WG drafts will go to WG Last Call shortly after Atlanta at the latest. Most of the IPS WG drafts are NOT listed on this agenda as their authors and WG co-chairs are not aware of any open technical issues requiring meeting time to discuss, and most have completed WG Last Call. ---- Monday, November 18, 1300-1500 ---- - Agenda Bashing and Administrivia (15 min) - BLUE SHEETS - NOTE WELL - Status of drafts - Future of IPS WG (chairs and ADs) - SCSI MIB (15 min) draft-ietf-ips-scsi-mib-04.txt Structure diagram available at: ftp://ftpeng.cisco.com/mbakke/ips/scsi-mib/Visio-scsi-uml-model-01.pdf Diagram showing relationships among SCSI family of MIBS available at: ftp://ftpeng.cisco.com/mbakke/ips/scsi-mib/Visio-scsi-mib-family-01.pdf - DHC support for iSCSI boot failure notification (15 min) draft-bakke-dhc-snmp-trap-01.txt If this draft is to go forward, it will do so in the DHC WG, but it's on the agenda here to discuss the problem and proposed approach to solving it. - NAA naming format for iSCSI (30 min) draft-krueger-iscsi-name-ext-00.txt This draft proposes to add a new .naa naming format to iSCSI in addition to the current .iqn and .eui formats. A significant motivation for this is an desire by T10 (ANSI organization that handles SCSI standards) to obtain consistent SCSI device naming across SCSI transports. The authors request that the IPS WG adopt this draft as an official work item. It would become a separate RFC rather than being folded into the main iSCSI draft. - Any other business/questions (time remaining) DESCRIPTION: The IP Storage WG works on using IP-based networks to transport block storage traffic. See http://www.ietf.org/html.charters/ips-charter.html From owner-ips@ece.cmu.edu Fri Nov 15 20:50:00 2002 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA26474 for ; Fri, 15 Nov 2002 20:49:59 -0500 (EST) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id gAG0u9t18521 for ips-outgoing; Fri, 15 Nov 2002 19:56:09 -0500 (EST) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from lion.ninthwonder.com (lion.ninthwonder.com [151.199.66.147]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id gAG0u7H18517 for ; Fri, 15 Nov 2002 19:56:07 -0500 (EST) Received: by lion.ninthwonder.com (Postfix, from userid 1021) id 4734F30706; Fri, 15 Nov 2002 19:56:06 -0500 (EST) Date: Fri, 15 Nov 2002 16:55:44 -0800 (PST) From: Bill Studenmund X-X-Sender: To: Subject: Questions about adding additional connections to a session Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ips@ece.cmu.edu Precedence: bulk I was wondering when exactly an additional connection becomes part of a session? When it is IN_LOGIN, or LOGGED_IN? This question is coming from the angle of seeing if an attacker could disrupt a session by trying to log in additional connections. I'm also assuming it's an attacker that does NOT have the security secrets; an attacker with the secrets will look legitemate. If the connection is added at LOGGED_IN, then there is nothing malicious an attacker can do. However, that doesn't seem to be how the spec is writen, and it means special-casing additional-connection logins. 'cause we have state Q2, which corresponds to the first connection of the session being in IN_LOGIN. It also breaks the clenliness of connections always being in their session, and of using itt to always find a task, including login, in a session. The flip side is that if the extra connection is added at IN_LOGIN, then an attacker can impact an operational session. Note: I understand well that since I'm talking about an attacker without valid security credentials, this impact is bounded; at some point the target will reject the login. At the bare minimum, assuming we enforce a limit on the number of connections, the rogue connection will count. Thus there will be a window in which the real initiator can't add new connections. Since it's real easy to keep fake connections going, this could be a long-term attack. The other thing I could see is that if the connection is part of the session, then, unless care is taken, its itt is visable to the session. Thus the real initiator can't start a task with that itt. While it's feasable to shield the itt, you have to take care to do it. Thoughts? Take care, Bill From owner-ips@ece.cmu.edu Fri Nov 15 22:47: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 WAA29387 for ; Fri, 15 Nov 2002 22:47:42 -0500 (EST) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id gAG39fS24195 for ips-outgoing; Fri, 15 Nov 2002 22:09:41 -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 gAG39cH24189 for ; Fri, 15 Nov 2002 22:09:38 -0500 (EST) Received: from rosemail.rose.hp.com (rosemail.rose.hp.com [15.96.64.26]) by palrel11.hp.com (Postfix) with ESMTP id E7E5260085F; Fri, 15 Nov 2002 19:09:35 -0800 (PST) Received: from swathi (swathi.rose.hp.com [15.43.213.237]) by rosemail.rose.hp.com with SMTP (8.7.1/8.7.3 SMKit7.02) id TAA09361; Fri, 15 Nov 2002 19:09:35 -0800 (PST) Message-ID: <00d601c28d1d$96ea9840$edd52b0f@rose.hp.com> From: "Mallikarjun C." To: "Bill Studenmund" , References: Subject: Re: iSCSI: Questions about adding additional connections to a session Date: Fri, 15 Nov 2002 19:09:33 -0800 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2600.0000 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 Sender: owner-ips@ece.cmu.edu Precedence: bulk Content-Transfer-Encoding: 7bit An iSCSI connection is considered to be part of a FFP iSCSI session (one in Q3) when the connection enters the LOGGED_IN state. The target session state Q2 represents the fact that the first iSCSI connection is going through the login dynamics. The connection itself is not formally considered to be "part of the" session, because the session itself is not quite operational state. Note that the session is essentially in a special situation here, and that's what state Q2 represents. I tend to think that one doesn't have a need to use general purpose algorithms here - no active connections yet, no active tasks yet. Hope that answers your question. -- Mallikarjun Mallikarjun Chadalapaka Networked Storage Architecture Network Storage Solutions Hewlett-Packard MS 5668 Roseville CA 95747 cbm@rose.hp.com ----- Original Message ----- From: "Bill Studenmund" To: Sent: Friday, November 15, 2002 4:55 PM Subject: Questions about adding additional connections to a session > I was wondering when exactly an additional connection becomes part of a > session? When it is IN_LOGIN, or LOGGED_IN? > > This question is coming from the angle of seeing if an attacker could > disrupt a session by trying to log in additional connections. I'm also > assuming it's an attacker that does NOT have the security secrets; an > attacker with the secrets will look legitemate. > > If the connection is added at LOGGED_IN, then there is nothing malicious > an attacker can do. However, that doesn't seem to be how the spec is > writen, and it means special-casing additional-connection logins. 'cause > we have state Q2, which corresponds to the first connection of the session > being in IN_LOGIN. It also breaks the clenliness of connections always > being in their session, and of using itt to always find a task, including > login, in a session. > > The flip side is that if the extra connection is added at IN_LOGIN, then > an attacker can impact an operational session. Note: I understand well > that since I'm talking about an attacker without valid security > credentials, this impact is bounded; at some point the target will reject > the login. > > At the bare minimum, assuming we enforce a limit on the number of > connections, the rogue connection will count. Thus there will be a window > in which the real initiator can't add new connections. Since it's real > easy to keep fake connections going, this could be a long-term attack. > > The other thing I could see is that if the connection is part of the > session, then, unless care is taken, its itt is visable to the session. > Thus the real initiator can't start a task with that itt. While it's > feasable to shield the itt, you have to take care to do it. > > Thoughts? > > Take care, > > Bill > > > From owner-ips@ece.cmu.edu Sat Nov 16 00:32:16 2002 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA01078 for ; Sat, 16 Nov 2002 00:32:16 -0500 (EST) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id gAG4lvD28143 for ips-outgoing; Fri, 15 Nov 2002 23:47:57 -0500 (EST) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from d12lmsgate-4.de.ibm.com (d12lmsgate-4.de.ibm.com [194.196.100.237]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id gAG4lsH28138; Fri, 15 Nov 2002 23:47:54 -0500 (EST) Received: from d12relay02.de.ibm.com (d12relay02.de.ibm.com [9.165.215.23]) by d12lmsgate-4.de.ibm.com (8.12.3/8.12.3) with ESMTP id gAG4lf6Q046846; Sat, 16 Nov 2002 05:47:46 +0100 Received: from d10hubm1.telaviv.ibm.com (d10ml001.telaviv.ibm.com [9.148.216.55]) by d12relay02.de.ibm.com (8.12.3/NCO/VER6.4) with ESMTP id gAG4lf2Y130994; Sat, 16 Nov 2002 05:47:41 +0100 In-Reply-To: To: Bill Studenmund Cc: ips@ece.cmu.edu, owner-ips@ece.cmu.edu MIME-Version: 1.0 Subject: Re: Questions about adding additional connections to a session X-Mailer: Lotus Notes Release 6.0 September 26, 2002 From: "Julian Satran" Message-ID: Date: Sat, 16 Nov 2002 06:47:37 +0200 X-MIMETrack: Serialize by Router on D10ML001/10/M/IBM(Release 5.0.9a |January 7, 2002) at 16/11/2002 06:47:41, Serialize complete at 16/11/2002 06:47:41 Content-Type: multipart/alternative; boundary="=_alternative 0019C853C2256C73_=" Sender: owner-ips@ece.cmu.edu Precedence: bulk This is a multipart message in MIME format. --=_alternative 0019C853C2256C73_= Content-Type: text/plain; charset="US-ASCII" Bill, You want to work both without a security envelope and to resist an active attack... If you keep letting in in your hypothetical attacker time after time then you certainly have a pretty weak security. This type of attacks are not uncommon on servers with a limited number of threads and the can be stopped by blocking the intruder through some other means (IP address filtering etc.). And regardless of when you declare a connection in session and count it in the limit - this type of attack will consume some resources if it reaches your system. Julo Bill Studenmund Sent by: owner-ips@ece.cmu.edu 16/11/02 02:55 To: cc: Subject: Questions about adding additional connections to a session I was wondering when exactly an additional connection becomes part of a session? When it is IN_LOGIN, or LOGGED_IN? This question is coming from the angle of seeing if an attacker could disrupt a session by trying to log in additional connections. I'm also assuming it's an attacker that does NOT have the security secrets; an attacker with the secrets will look legitemate. If the connection is added at LOGGED_IN, then there is nothing malicious an attacker can do. However, that doesn't seem to be how the spec is writen, and it means special-casing additional-connection logins. 'cause we have state Q2, which corresponds to the first connection of the session being in IN_LOGIN. It also breaks the clenliness of connections always being in their session, and of using itt to always find a task, including login, in a session. The flip side is that if the extra connection is added at IN_LOGIN, then an attacker can impact an operational session. Note: I understand well that since I'm talking about an attacker without valid security credentials, this impact is bounded; at some point the target will reject the login. At the bare minimum, assuming we enforce a limit on the number of connections, the rogue connection will count. Thus there will be a window in which the real initiator can't add new connections. Since it's real easy to keep fake connections going, this could be a long-term attack. The other thing I could see is that if the connection is part of the session, then, unless care is taken, its itt is visable to the session. Thus the real initiator can't start a task with that itt. While it's feasable to shield the itt, you have to take care to do it. Thoughts? Take care, Bill --=_alternative 0019C853C2256C73_= Content-Type: text/html; charset="US-ASCII"
Bill,

You want to work both without a security envelope and to resist an active attack...
If you keep letting in in your hypothetical attacker time after time then you certainly  have a pretty weak security.
This type of attacks are not uncommon on servers with a limited number of threads and the can be stopped by blocking the intruder through some other means (IP address filtering etc.).  
And regardless of when you declare a connection in session and count it in the limit - this type of attack will consume some resources if it reaches your system.

Julo


Bill Studenmund <wrstuden@wasabisystems.com>
Sent by: owner-ips@ece.cmu.edu

16/11/02 02:55

       
        To:        <ips@ece.cmu.edu>
        cc:        
        Subject:        Questions about adding additional connections to a session

       


I was wondering when exactly an additional connection becomes part of a
session? When it is IN_LOGIN, or LOGGED_IN?

This question is coming from the angle of seeing if an attacker could
disrupt a session by trying to log in additional connections. I'm also
assuming it's an attacker that does NOT have the security secrets; an
attacker with the secrets will look legitemate.

If the connection is added at LOGGED_IN, then there is nothing malicious
an attacker can do. However, that doesn't seem to be how the spec is
writen, and it means special-casing additional-connection logins. 'cause
we have state Q2, which corresponds to the first connection of the session
being in IN_LOGIN. It also breaks the clenliness of connections always
being in their session, and of using itt to always find a task, including
login, in a session.

The flip side is that if the extra connection is added at IN_LOGIN, then
an attacker can impact an operational session. Note: I understand well
that since I'm talking about an attacker without valid security
credentials, this impact is bounded; at some point the target will reject
the login.

At the bare minimum, assuming we enforce a limit on the number of
connections, the rogue connection will count. Thus there will be a window
in which the real initiator can't add new connections. Since it's real
easy to keep fake connections going, this could be a long-term attack.

The other thing I could see is that if the connection is part of the
session, then, unless care is taken, its itt is visable to the session.
Thus the real initiator can't start a task with that itt. While it's
feasable to shield the itt, you have to take care to do it.

Thoughts?

Take care,

Bill
--=_alternative 0019C853C2256C73_=-- From owner-ips@ece.cmu.edu Sun Nov 17 00:20:02 2002 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA02229 for ; Sun, 17 Nov 2002 00:20:02 -0500 (EST) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id gAH4FCj00957 for ips-outgoing; Sat, 16 Nov 2002 23:15:12 -0500 (EST) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from lion.ninthwonder.com (lion.ninthwonder.com [151.199.66.147]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id gAH4F9H00952; Sat, 16 Nov 2002 23:15:09 -0500 (EST) Received: by lion.ninthwonder.com (Postfix, from userid 1021) id 44F3B30706; Sat, 16 Nov 2002 23:15:03 -0500 (EST) Date: Sat, 16 Nov 2002 20:14:56 -0800 (PST) From: Bill Studenmund X-X-Sender: To: Julian Satran Cc: , Subject: Re: Questions about adding additional connections to a session In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ips@ece.cmu.edu Precedence: bulk On Sat, 16 Nov 2002, Julian Satran wrote: > Bill, > > You want to work both without a security envelope and to resist an active > attack... Agreed. > If you keep letting in in your hypothetical attacker time after time then > you certainly have a pretty weak security. > This type of attacks are not uncommon on servers with a limited number of > threads and the can be stopped by blocking the intruder through some other > means (IP address filtering etc.). Just to run with the idea, say the attacker is a hostile process on the initiator? :-) > And regardless of when you declare a connection in session and count it in > the limit - this type of attack will consume some resources if it reaches > your system. Agreed. Take care, Bill From owner-ips@ece.cmu.edu Sun Nov 17 02:31:17 2002 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA14071 for ; Sun, 17 Nov 2002 02:31:16 -0500 (EST) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id gAH6oLj06385 for ips-outgoing; Sun, 17 Nov 2002 01:50:21 -0500 (EST) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from lion.ninthwonder.com (lion.ninthwonder.com [151.199.66.147]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id gAH6oIH06379 for ; Sun, 17 Nov 2002 01:50:18 -0500 (EST) Received: by lion.ninthwonder.com (Postfix, from userid 1021) id EC22530706; Sun, 17 Nov 2002 01:50:17 -0500 (EST) Date: Sat, 16 Nov 2002 22:50:10 -0800 (PST) From: Bill Studenmund X-X-Sender: To: "Mallikarjun C." Cc: Subject: Re: iSCSI: Questions about adding additional connections to a session In-Reply-To: <00d601c28d1d$96ea9840$edd52b0f@rose.hp.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ips@ece.cmu.edu Precedence: bulk On Fri, 15 Nov 2002, Mallikarjun C. wrote: > An iSCSI connection is considered to be part of a FFP iSCSI > session (one in Q3) when the connection enters the LOGGED_IN > state. > > The target session state Q2 represents the fact that the first iSCSI > connection is going through the login dynamics. The connection itself > is not formally considered to be "part of the" session, because the > session itself is not quite operational state. Note that the session is > essentially in a special situation here, and that's what state Q2 > represents. I tend to think that one doesn't have a need to use general > purpose algorithms here - no active connections yet, no active tasks yet. > > Hope that answers your question. Yep, it does. Thanks! Take care, Bill From owner-ips@ece.cmu.edu Sun Nov 17 21:56:13 2002 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA00433 for ; Sun, 17 Nov 2002 21:56:13 -0500 (EST) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id gAI23qV27186 for ips-outgoing; Sun, 17 Nov 2002 21:03:52 -0500 (EST) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from maho3msx2.corp.emc.com (maho3msx2.corp.emc.com [128.221.11.32]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id gAI23oH27181 for ; Sun, 17 Nov 2002 21:03:50 -0500 (EST) Received: by maho3msx2.corp.emc.com with Internet Mail Service (5.5.2653.19) id ; Sun, 17 Nov 2002 21:03:41 -0500 Message-ID: <277DD60FB639D511AC0400B0D068B71E0564C562@CORPMX14> From: Black_David@emc.com To: ips@ece.cmu.edu Subject: IPS-ALL: Four WG Last Calls Date: Sun, 17 Nov 2002 21:03:28 -0500 Importance: high X-Priority: 1 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-ips@ece.cmu.edu Precedence: bulk All, We would like to announce IPS Working Group Last Calls for the four remaining IPS WG drafts that need a WG Last Call. Due to the IETF meeting week and Thanksgiving holidays, these WG Last Calls will run for more than the usual two weeks. Details: (1) Document: Internet Storage Name Service (iSNS) URL: http://www.ietf.org/internet-drafts/draft-ietf-ips-isns-14.txt Note: This document has been through one WG Last Call. All technical issues are believed to be resolved, but the resulting extensive text changes warrant another WG Last Call. The primary purpose of this second WG Last Call is to check that issues raised in the first WG Last Call have been resolved satisfactorily. Last call period: 3 Weeks Submit comments no later than: Monday, December 9, 2002 at 5pm EST Editor: Josh Tseng (2) Document: Finding iSCSI Targets and Name Servers Using SLP URL: http://www.ietf.org/internet-drafts/draft-ietf-ips-iscsi-slp-04.txt Last call period: 3 Weeks Submit comments no later than: Monday, December 9, 2002 at 5pm EST Editor: Mark Bakke Note: This document has too many authors. A -05 version will be needed to reduce the author count. (3) Document: Definitions of Managed Objects for iSNS (Internet Storage Name Service) URL: http://www.ietf.org/internet-drafts/draft-ietf-ips-isns-mib-02.txt Last call period: 3 Weeks Submit comments no later than: Monday, December 9, 2002 at 5pm EST Editor: Kevin Gibbons (4) Document: Definition of Managed Objects for SCSI Entities URL: http://www.ietf.org/internet-drafts/draft-ietf-ips-scsi-mib-04.txt Last call period: 3 Weeks Submit comments no later than: Monday, December 9, 2002 at 5pm EST Editor: Michele Hallak-Stamler Please submit editorial comments directly to the appropriate document editor, with a copy to David Black (black_david@emc.com), and Elizabeth Rodriguez (erodrigu@brocade.com). Submit technical comments to the IPS mailing list (ips@ece.cmu.edu) Editorial comments may be resolved directly by the editor of the document, but any technical issues must be discussed on the IPS reflector. Thanks, David Black & Elizabeth Rodriguez IPS co-chairs ---------------------------------------------------- David L. Black, Senior Technologist EMC Corporation, 176 South St., Hopkinton, MA 01748 +1 (508) 293-7953 **NEW** FAX: +1 (508) 293-7786 black_david@emc.com Mobile: +1 (978) 394-7754 ---------------------------------------------------- \ From owner-ips@ece.cmu.edu Tue Nov 19 00:01: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 AAA15414 for ; Tue, 19 Nov 2002 00:01:20 -0500 (EST) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id gAJ3qco03919 for ips-outgoing; Mon, 18 Nov 2002 22:52:38 -0500 (EST) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from atlrel8.hp.com (atlrel8.hp.com [156.153.255.206]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id gAJ3qXH03910 for ; Mon, 18 Nov 2002 22:52:33 -0500 (EST) Received: from rosemail.rose.hp.com (rosemail.rose.hp.com [15.96.64.26]) by atlrel8.hp.com (Postfix) with ESMTP id 5BFD9A00961 for ; Mon, 18 Nov 2002 22:52:30 -0500 (EST) Received: from swathi (atl1nai176023.ssr.hp.com [15.228.176.23]) by rosemail.rose.hp.com with SMTP (8.7.1/8.7.3 SMKit7.02) id TAA28922 for ; Mon, 18 Nov 2002 19:52:24 -0800 (PST) Message-ID: <000c01c28f7f$131384a0$17b0e40f@rose.hp.com> From: "Mallikarjun C." To: Subject: iSCSI: IETF-55 slides for name-ext proposal Date: Mon, 18 Nov 2002 19:51:32 -0800 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2600.0000 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 Sender: owner-ips@ece.cmu.edu Precedence: bulk Content-Transfer-Encoding: 7bit All: The slides that I presented at the IETF Atlanta meeting today are posted at: http://storage-arch.hp.com/naa_for_iSCSI.pdf Thanks. -- Mallikarjun Mallikarjun Chadalapaka Networked Storage Architecture Network Storage Solutions Hewlett-Packard MS 5668 Roseville CA 95747 cbm@rose.hp.com From owner-ips@ece.cmu.edu Tue Nov 19 11:24:37 2002 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA08837 for ; Tue, 19 Nov 2002 11:24:36 -0500 (EST) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id gAJFTr419328 for ips-outgoing; Tue, 19 Nov 2002 10:29:53 -0500 (EST) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from mxic2.corp.emc.com (mxic2.us.dg.com [128.221.31.40]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id gAJFToH19319 for ; Tue, 19 Nov 2002 10:29:50 -0500 (EST) Received: by mxic2.corp.emc.com with Internet Mail Service (5.5.2653.19) id ; Tue, 19 Nov 2002 10:25:46 -0500 Message-ID: <277DD60FB639D511AC0400B0D068B71E0564C572@CORPMX14> From: Black_David@emc.com To: ips@ece.cmu.edu Subject: Atlanta DRAFT minutes Date: Tue, 19 Nov 2002 10:25:27 -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 Comments and/or corrections to me and/or the list please. Thanks, --David IP Storage (ips) Working Group Atlanta Minutes - November 18, 2002 ----------------------------------- -- Agenda Bashing and Status of Drafts - David L. Black, EMC (WG co-chair) Most drafts are not on the agenda because they are in or beyond WG Last Call. Last four WG drafts are in WG Last Call which will end on December 9. See "status of drafts 1102 IETF55" file for detailed status of all drafts. WG members should review draft-ietf-dhc-isnsoption-03.txt ASAP as it will be jointly Last Called in the IPS and DHC WGs in the near future - send comments to the IPS list. The WG has accomplished a great deal of work (4 major protocols, plus ancillary documents, including 7 MIBs) in about 2 years, and the Technical Coordinators received a round of applause for their efforts to ensure that everything else (especially MIBs) was completed at about the same time as the main protocols. -- SCSI MIB - Roger Cummings, Veritas draft-ietf-ips-scsi-mib-04.txt SCSI MIB is in WG Last Call. Some additional T10 document references need to be added. The request made on the list to add some counter64 elements will not be done because it is not in keeping with IETF guidelines for appropriate use of counter64 (based on how fast a counter32 element rolls over). -- DHC config of SNMP trap config for iSCSI boot failure - Mark Bakke, Cisco draft-bakke-dhc-snmp-trap-01.txt This is a string format DHCP option to report boot failure. Will most likely go forward in DHC WG. Rationale, requirements, scenarios are ok to discuss on IPS list, but details will be on DHC and appropriate SNMP lists. Discussion in DHC earlier the same day was that there is definitely a problem here that needs to be addressed, but there were some open issues about how much of the problem to take on initially and details of how to go about it. General sense of the room is that this is something worth working on. -- NAA naming format for iSCSI - Mallikarjun Chadalapaka, HP draft-krueger-iscsi-name-ext-00.txt Proposal for a new "naa." naming format in addition to "iqn." and "eui.". Motivated in part by a T10 proposal, but described as having value on its own for multi-protocol devices (i.e. implementing SCSI over more than one transport). David Black put up a T11 document (01-630v0) describing NAA (WWN) to EUI mapping for some NAA formats. About 1/4 of the room understands the issues here, and among that 1/4 there is clear rough consensus for carrying this proposal forward in appropriate coordination with T10. Co-chairs and ADs will consult off line about how to do this, and will also ensure that current text in iSCSI -19 that prohibits adding a naming format is appropriately changed/weakened to allow this, but the resulting text will set a high criterion for future additions to meet. -- Future of WG Discussion - WG co-chairs, and Allison Mankin, Transport AD WG has completed a lot of work and is close to done. The Transport ADs like WGs that set out to do something, do it and shut down, so IPS WG will probably shut down in near future. Mailing list will remain alive, and the above NAA draft may be progressed solely via mailing list. Progression of any of IPS's protocols to Draft Standard requires interoperability reports on which work could start now, but the WG co-chairs are adamant that the main protocol documents will not be re-opened for general revisions prior to 2004 at the earliest, although bug fixes and the like can be done in the interim if/as necessary. From owner-ips@ece.cmu.edu Thu Nov 21 17:57:18 2002 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA24910 for ; Thu, 21 Nov 2002 17:57:17 -0500 (EST) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id gALM49S07031 for ips-outgoing; Thu, 21 Nov 2002 17:04:09 -0500 (EST) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from cybernetics.com (cyborg.cybernetics.com [206.246.200.18]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id gALM47H07025 for ; Thu, 21 Nov 2002 17:04:07 -0500 (EST) Received: by cyborg.cybernetics.com id <119048>; Thu, 21 Nov 2002 17:03:56 -0500 Reply-To: From: "Tony Battersby" To: Subject: iSCSI: rejecting AuthMethod Date: Thu, 21 Nov 2002 17:03:55 -0500 Message-Id: <02Nov21.170356est.119048@cyborg.cybernetics.com> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook CWS, Build 9.0.2416 (9.0.2910.0) X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4522.1200 Importance: Normal Sender: owner-ips@ece.cmu.edu Precedence: bulk Content-Transfer-Encoding: 7bit Draft 19 Section 5.3.2 iSCSI Security Negotiation: The target MUST reply with the first option in the list it supports and is allowed to use for the specific initiator unless it does not support any in which case it MUST answer with "Reject" (see Section 5.2 Text Mode Negotiation). Draft 19 Section 5.2.1 List Negotiations: If an acceptor does not support, does not understand, or is not allowed to use any of the proposed options with a specific originator, it may use the constant "Reject" or terminate the negotiation. I am considering the case where the target is configured not to accept a connection without authentication, and the target does not support any of the authentication methods offered by the initiator. Since the initiator is not allowed to send the AuthMethod key a second time, the login attempt must fail. I assume that the target should return a Login Response with Authentication Failure status in this case. The first quote above implies that the target's Login Response should in addition contain the "AuthMethod=Reject" key. Is this really the intended meaning? In the general case it is not necessary to return any keys with a Login Response that has a nonzero Status-Class, so I do not see why this case should be any different. For consistency, I recommend changing the text to something like "...in which case it MUST answer with "Reject" (see Section 5.2 Text Mode Negotiation) or terminate the negotiation." Incidently, the names of the Login Response status codes in section 10.13.5 have inconsistent capitalization (e.g. "Target Moved Temporarily" vs. "Can't include in session"). Anthony J. Battersby Cybernetics From owner-ips@ece.cmu.edu Fri Nov 22 08:17:04 2002 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA24340 for ; Fri, 22 Nov 2002 08:17:04 -0500 (EST) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id gAMCJcK02433 for ips-outgoing; Fri, 22 Nov 2002 07:19:38 -0500 (EST) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from d12lmsgate-3.de.ibm.com (d12lmsgate-3.de.ibm.com [194.196.100.236]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id gAMCJYH02425; Fri, 22 Nov 2002 07:19:34 -0500 (EST) Received: from d12relay02.de.ibm.com (d12relay02.de.ibm.com [9.165.215.23]) by d12lmsgate-3.de.ibm.com (8.12.3/8.12.3) with ESMTP id gAMCJJC3034114; Fri, 22 Nov 2002 13:19:20 +0100 Received: from d10hubm1.telaviv.ibm.com (d10ml001.telaviv.ibm.com [9.148.216.55]) by d12relay02.de.ibm.com (8.12.3/NCO/VER6.4) with ESMTP id gAMCJItj067234; Fri, 22 Nov 2002 13:19:19 +0100 In-Reply-To: <02Nov21.170356est.119048@cyborg.cybernetics.com> To: Cc: ips@ece.cmu.edu, owner-ips@ece.cmu.edu MIME-Version: 1.0 Subject: Re: iSCSI: rejecting AuthMethod X-Mailer: Lotus Notes Release 6.0 September 26, 2002 From: "Julian Satran" Message-ID: Date: Fri, 22 Nov 2002 14:19:14 +0200 X-MIMETrack: Serialize by Router on D10ML001/10/M/IBM(Release 5.0.9a |January 7, 2002) at 22/11/2002 14:19:19, Serialize complete at 22/11/2002 14:19:19 Content-Type: multipart/alternative; boundary="=_alternative 0042CF67C2256C79_=" Sender: owner-ips@ece.cmu.edu Precedence: bulk This is a multipart message in MIME format. --=_alternative 0042CF67C2256C79_= Content-Type: text/plain; charset="US-ASCII" Tony, The intent (based on vivid requests on the list) was to provide as much information as possible about any failure instead of "terse" termination. Reject is thus required. Whether you do it in one stage or two depends on implementation and exchange. As for the capitalization - I will do it is a bit late for changes now but I'll keep it on the list. Julo "Tony Battersby" Sent by: owner-ips@ece.cmu.edu 22/11/02 00:03 Please respond to tonyb To: cc: Subject: iSCSI: rejecting AuthMethod Draft 19 Section 5.3.2 iSCSI Security Negotiation: The target MUST reply with the first option in the list it supports and is allowed to use for the specific initiator unless it does not support any in which case it MUST answer with "Reject" (see Section 5.2 Text Mode Negotiation). Draft 19 Section 5.2.1 List Negotiations: If an acceptor does not support, does not understand, or is not allowed to use any of the proposed options with a specific originator, it may use the constant "Reject" or terminate the negotiation. I am considering the case where the target is configured not to accept a connection without authentication, and the target does not support any of the authentication methods offered by the initiator. Since the initiator is not allowed to send the AuthMethod key a second time, the login attempt must fail. I assume that the target should return a Login Response with Authentication Failure status in this case. The first quote above implies that the target's Login Response should in addition contain the "AuthMethod=Reject" key. Is this really the intended meaning? In the general case it is not necessary to return any keys with a Login Response that has a nonzero Status-Class, so I do not see why this case should be any different. For consistency, I recommend changing the text to something like "...in which case it MUST answer with "Reject" (see Section 5.2 Text Mode Negotiation) or terminate the negotiation." Incidently, the names of the Login Response status codes in section 10.13.5 have inconsistent capitalization (e.g. "Target Moved Temporarily" vs. "Can't include in session"). Anthony J. Battersby Cybernetics --=_alternative 0042CF67C2256C79_= Content-Type: text/html; charset="US-ASCII"
Tony,

The intent (based on vivid requests on the list) was to provide as much information as possible about any failure instead of "terse" termination.
Reject is thus required. Whether you do it in one stage or two depends on implementation and exchange.

As for the capitalization - I will do it is a bit late for changes now but I'll keep it on the list.

Julo


"Tony Battersby" <tonyb@cybernetics.com>
Sent by: owner-ips@ece.cmu.edu

22/11/02 00:03
Please respond to tonyb

       
        To:        <ips@ece.cmu.edu>
        cc:        
        Subject:        iSCSI: rejecting AuthMethod

       


Draft 19 Section 5.3.2 iSCSI Security Negotiation: The target MUST reply
with the first option in the list it supports and is allowed to use for the
specific initiator unless it does not support any in which case it MUST
answer with "Reject" (see Section 5.2 Text Mode Negotiation).

Draft 19 Section 5.2.1 List Negotiations: If an acceptor does not support,
does not understand, or is not allowed to use any of the proposed options
with a specific originator, it may use the constant "Reject" or terminate
the negotiation.

I am considering the case where the target is configured not to accept a
connection without authentication, and the target does not support any of
the authentication methods offered by the initiator.  Since the initiator is
not allowed to send the AuthMethod key a second time, the login attempt must
fail.  I assume that the target should return a Login Response with
Authentication Failure status in this case.  The first quote above implies
that the target's Login Response should in addition contain the
"AuthMethod=Reject" key.  Is this really the intended meaning?  In the
general case it is not necessary to return any keys with a Login Response
that has a nonzero Status-Class, so I do not see why this case should be any
different.  For consistency, I recommend changing the text to something like
"...in which case it MUST answer with "Reject" (see Section 5.2 Text Mode
Negotiation) or terminate the negotiation."

Incidently, the names of the Login Response status codes in section 10.13.5
have inconsistent capitalization (e.g. "Target Moved Temporarily" vs. "Can't
include in session").

Anthony J. Battersby
Cybernetics
--=_alternative 0042CF67C2256C79_=-- From owner-ips@ece.cmu.edu Mon Nov 25 17:26:53 2002 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA28897 for ; Mon, 25 Nov 2002 17:26:53 -0500 (EST) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id gAPLQSQ02626 for ips-outgoing; Mon, 25 Nov 2002 16:26:28 -0500 (EST) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from maho3msx2.corp.emc.com (maho3msx2.corp.emc.com [128.221.11.32]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id gAPLQQH02620 for ; Mon, 25 Nov 2002 16:26:26 -0500 (EST) Received: by maho3msx2.corp.emc.com with Internet Mail Service (5.5.2653.19) id ; Mon, 25 Nov 2002 16:26:20 -0500 Message-ID: <277DD60FB639D511AC0400B0D068B71E0564C59E@corpmx14.us.dg.com> From: Black_David@emc.com To: ips@ece.cmu.edu Subject: iSCSI status Date: Mon, 25 Nov 2002 16:26:02 -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 Since people have been bugging me about this ... iSCSI should be entering IETF Last Call within the next week. The changes in the -19 version were sufficient to deal with the concerns from Area Director review. FYI, --David ---------------------------------------------------- David L. Black, Senior Technologist EMC Corporation, 176 South St., Hopkinton, MA 01748 +1 (508) 293-7953 **NEW** FAX: +1 (508) 293-7786 black_david@emc.com Mobile: +1 (978) 394-7754 ---------------------------------------------------- From owner-ips@ece.cmu.edu Wed Nov 27 13:23:49 2002 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA23045 for ; Wed, 27 Nov 2002 13:23:49 -0500 (EST) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id gARHVZF16391 for ips-outgoing; Wed, 27 Nov 2002 12:31:35 -0500 (EST) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from ietf.org (odin.ietf.org [132.151.1.176]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id gARD8nH01417 for ; Wed, 27 Nov 2002 08:08:49 -0500 (EST) Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA08201; Wed, 27 Nov 2002 08:06:04 -0500 (EST) Message-Id: <200211271306.IAA08201@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; Cc: ips@ece.cmu.edu From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-ietf-ips-iscsi-boot-08.txt Date: Wed, 27 Nov 2002 08:06:04 -0500 Sender: owner-ips@ece.cmu.edu Precedence: bulk --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the IP Storage Working Group of the IETF. Title : Bootstrapping Clients using the iSCSI Protocol Author(s) : P. Sarkar, D. Missimer, C. Sapuntzakis Filename : draft-ietf-ips-iscsi-boot-08.txt Pages : 11 Date : 2002-11-26 iSCSI is a proposed transport protocol for SCSI that operates on top of TCP. This memo describes a standard mechanism to enable clients to bootstrap themselves using the iSCSI protocol. The goal of this standard is to enable iSCSI boot clients to obtain the information to open an iSCSI session with the iSCSI boot server. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-ips-iscsi-boot-08.txt To remove yourself from the IETF Announcement list, send a message to ietf-announce-request with the word unsubscribe in the body of the message. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-ips-iscsi-boot-08.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-ips-iscsi-boot-08.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <2002-11-26133316.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-ips-iscsi-boot-08.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-ips-iscsi-boot-08.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2002-11-26133316.I-D@ietf.org> --OtherAccess-- --NextPart-- From owner-ips@ece.cmu.edu Wed Nov 27 18:34: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 SAA02576 for ; Wed, 27 Nov 2002 18:34:49 -0500 (EST) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id gARMFdl02470 for ips-outgoing; Wed, 27 Nov 2002 17:15:39 -0500 (EST) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from maho3msx2.corp.emc.com (maho3msx2.corp.emc.com [128.221.11.32]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id gARMFcH02466 for ; Wed, 27 Nov 2002 17:15:38 -0500 (EST) Received: by maho3msx2.corp.emc.com with Internet Mail Service (5.5.2653.19) id ; Wed, 27 Nov 2002 17:15:33 -0500 Message-ID: <277DD60FB639D511AC0400B0D068B71E0564C5C4@corpmx14.us.dg.com> From: Black_David@emc.com To: ips@ece.cmu.edu Subject: iSNS DHC option comments Date: Wed, 27 Nov 2002 17:15:16 -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 In the hopes of encouraging others to do likewise, here are my comments from a review of draft-ietf-dhc-isnsoption-03.txt (1) If FCIP were to be added, we could run out of space in the DD Access field. I suggest moving the high order octet of Administrative Flags to DD Access and making all of those new DD Access bits RESERVED for future extensibility. (2) The Security Considerations need to include the exposure to a "bid down" attack on security policy distribution (malicious intermediary weakens the security used) and say that reliance on local policy to avoid unacceptably weak security is the countermeasure. Plus a few nits: (3) Section 2.3 - Typo in name of bit 28, Discovrery --> Discovery (4) The description of the heartbeat should probably talk about the Multicast address to which the heartbeat is sent, as opposed to the current language about where it originates. (5) Please double check that the PFS bit for security is needed. It looks like it is, as I didn't find anything obvious in a quick scan of RFC 2409 and the DOI (and IANA registry) only has KEY_IKE, and the authentication methods, with nothing to indicate PFS usage. Thanks, --David p.s. I hope to push this draft to a joint ips/dhc WG Last Call shortly after Thanksgiving. ---------------------------------------------------- David L. Black, Senior Technologist EMC Corporation, 176 South St., Hopkinton, MA 01748 +1 (508) 293-7953 **NEW** FAX: +1 (508) 293-7786 black_david@emc.com Mobile: +1 (978) 394-7754 ----------------------------------------------------