From exim@www1.ietf.org Fri Mar 12 02:29:43 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA06010 for ; Fri, 12 Mar 2004 02:29:43 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B1h6Y-0007aL-En for ips-archive@odin.ietf.org; Fri, 12 Mar 2004 02:29:15 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i2C7TEhG029139 for ips-archive@odin.ietf.org; Fri, 12 Mar 2004 02:29:14 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B1h6X-0007Zn-Qg for ips-web-archive@optimus.ietf.org; Fri, 12 Mar 2004 02:29:13 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA05965 for ; Fri, 12 Mar 2004 02:29:11 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B1h6U-0002pG-00 for ips-web-archive@ietf.org; Fri, 12 Mar 2004 02:29:10 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B1h5V-0002gf-00 for ips-web-archive@ietf.org; Fri, 12 Mar 2004 02:28:11 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1B1h4V-0002T1-00 for ips-web-archive@ietf.org; Fri, 12 Mar 2004 02:27:07 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B1h4R-0006x2-CY; Fri, 12 Mar 2004 02:27:03 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B1h3l-0006o9-NA for ips@optimus.ietf.org; Fri, 12 Mar 2004 02:26:21 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA05684 for ; Fri, 12 Mar 2004 02:26:18 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B1h3i-0002Rb-00 for ips@ietf.org; Fri, 12 Mar 2004 02:26:18 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B1h2t-0002K5-00 for ips@ietf.org; Fri, 12 Mar 2004 02:25:28 -0500 Received: from e35.co.us.ibm.com ([32.97.110.133]) by ietf-mx with esmtp (Exim 4.12) id 1B1h29-00024i-00 for ips@ietf.org; Fri, 12 Mar 2004 02:24:41 -0500 Received: from westrelay04.boulder.ibm.com (westrelay04.boulder.ibm.com [9.17.193.32]) by e35.co.us.ibm.com (8.12.10/8.12.2) with ESMTP id i2C7O7F4393782; Fri, 12 Mar 2004 02:24:07 -0500 Received: from d03nm115.boulder.ibm.com (d03av02.boulder.ibm.com [9.17.193.82]) by westrelay04.boulder.ibm.com (8.12.10/NCO/VER6.6) with ESMTP id i2C7O5Df108940; Fri, 12 Mar 2004 00:24:06 -0700 In-Reply-To: <2FE6D10B746E524998DEA70F2D418F0201D3DB7D@EXC2K01A.cselt.it> To: Maffione Eugenio Cc: ips@ietf.org, ips-admin@ietf.org, wangxz@ict.ac.cn MIME-Version: 1.0 Subject: Re: RIF: [Ips] is a share disk possible on SCSI/iSCSI level? X-Mailer: Lotus Notes Release 6.0.2CF1 June 9, 2003 From: John Hufferd Message-ID: Date: Thu, 11 Mar 2004 23:24:01 -0800 X-MIMETrack: Serialize by Router on D03NM115/03/M/IBM(Release 6.0.2CF2HF168 | December 5, 2003) at 03/12/2004 00:24:06, Serialize complete at 03/12/2004 00:24:06 Content-Type: multipart/alternative; boundary="=_alternative 0028A68608256E55_=" Sender: ips-admin@ietf.org Errors-To: ips-admin@ietf.org 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: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.3 required=5.0 tests=AWL,HTML_20_30,HTML_MESSAGE autolearn=no version=2.60 This is a multipart message in MIME format. --=_alternative 0028A68608256E55_= Content-Type: text/plain; charset="US-ASCII" Perhaps this is a basic misunderstanding about what disk sharing means. I think you are asking if there is something that is possible about sharing the same LU from different computers. This is completely independent of the Network interconnect. FC or iSCSI permit the Host systems to issue Reserves or Releases. Even Persistent Reserves. The question is does the File system on the Host systems know how to support a shared LU. There are special File System available which know how to do this, and they are independent of the network and will operate on either FC or iSCSI. For normal pooled storage, the general support is the creation of a pool of Logical LUs on an external (perhaps RAID) Controller. Many/most of these permit a Virtualized set of LUs that span across the various physical Disk Drives (It can even be done on a single partitioned disk drive). In this type of a configuration each host system puts their own File System on the LUs that they think are theirs. As a rule, Reserve/Release is not an issue since each system will only "See" the LUs that belong to it. There was some problems with this in the early days of FC, but today with various forms of zoning and LUN masking, this is not a big problem. With iSCSI, I think that most/all vendors are defining to the External Controllers the LUs that are addressable by authorized hosts, and those are the only LUs the Host can get at. And, yes, in most of the implementations these are logical LUs that map in some way to the physical disks. And there is not usually any problems with Reserves. This is pooled storage, not shared files and not shared (logical) disks. . . John L. Hufferd Senior Technical Staff Member (STSM) IBM/System Group, San Jose CA Main Office: (408) 256-0403, Tie: 276-0403, eFax: (408) 904-4688 Alt Office: (408) 997-6136, Cell: (408) 499-9702 Internet Address: hufferd@us.ibm.com Maffione Eugenio Sent by: ips-admin@ietf.org 03/11/2004 11:30 AM To ips@ietf.org cc wangxz@ict.ac.cn Subject RIF: [Ips] is a share disk possible on SCSI/iSCSI level? Hi, the compatibility of commercial iscsi gateway with reserve-release mechanism is not widely available, even if everyone agrees that clustering systems with iscsi targets (instead of expensive FC SAN) could cut down the costs of the solutions. Any news about target implementation (also not commercial ...) with release-reserve support? Eugenio eugenio.maffione@telecomitalia.it -----Messaggio originale----- Da: ips-admin@ietf.org per conto di sunzen.w Inviato: lun 01/03/2004 3.19 A: ips@ietf.org Cc: Oggetto: [Ips] is a share disk possible on SCSI/iSCSI level? Hi, Storaging networking enables storage consolodation and deployment.Typically disk array serves as a storage server, its storage is parted and exported via storage networking protocols such as iSCSI,etc. Share problem arises. Current solutions are mainly on upper file level, either additionally deploying a NAS or using a SAN file system. Is it possible on SCSI/iSCSI level? In iSCSI spec, multi session on a target are allowed. is it for sharing? On SCSI, OSD commands are designed.Is it the way for sharing on disk level? sunzen wangxz@ict.ac.cn 2004-03-01 _______________________________________________ Ips mailing list Ips@ietf.org https://www1.ietf.org/mailman/listinfo/ips ==================================================================== CONFIDENTIALITY NOTICE This message and its attachments are addressed solely to the persons above and may contain confidential information. If you have received the message in error, be informed that any use of the content hereof is prohibited. Please return it immediately to the sender and delete the message. Should you have any questions, please contact us by replying to MailAdmin@tilab.com. Thank you ==================================================================== _______________________________________________ Ips mailing list Ips@ietf.org https://www1.ietf.org/mailman/listinfo/ips --=_alternative 0028A68608256E55_= Content-Type: text/html; charset="US-ASCII"
Perhaps this is a basic misunderstanding about what disk sharing means.

I think you are asking if there is something that is possible about sharing the same LU from different computers.  This is completely independent of the Network interconnect.  FC or iSCSI permit the Host systems to issue Reserves or Releases.  Even Persistent Reserves.  The question is does the File system on the Host systems know how to support a shared LU.  There are special File System available which know how to do this, and they are independent of the network and will operate on either FC or iSCSI.  

For normal pooled storage, the general support is the creation of a pool of Logical LUs on an external (perhaps RAID) Controller.  Many/most of these permit a Virtualized set of LUs that span across the various physical Disk Drives  (It can even be done on a single partitioned disk drive).  In this type of a configuration each host system puts their own File System on the LUs that they think are theirs.  As a rule, Reserve/Release is not an issue since each system will only "See" the LUs that belong to it.

There was some problems with this in the early days of FC, but today with various forms of zoning and LUN masking, this is not a big problem.

With iSCSI, I think that most/all vendors are defining to the External Controllers the LUs that are addressable by authorized hosts, and those are the only LUs the Host can get at.  And, yes, in  most of the implementations these are logical LUs that map in some way to the physical disks.  And there is not usually any problems with Reserves.

This is pooled storage, not shared files and not shared (logical) disks.
.
.
John L. Hufferd
Senior Technical Staff Member (STSM)
IBM/System Group, San Jose CA
Main Office: (408) 256-0403, Tie: 276-0403, eFax: (408) 904-4688
Alt Office: (408) 997-6136, Cell: (408) 499-9702
Internet Address: hufferd@us.ibm.com


Maffione Eugenio <Eugenio.Maffione@TILAB.COM>
Sent by: ips-admin@ietf.org

03/11/2004 11:30 AM

To
ips@ietf.org
cc
wangxz@ict.ac.cn
Subject
RIF: [Ips] is a share disk possible on SCSI/iSCSI level?





Hi,
the compatibility of commercial iscsi gateway with reserve-release mechanism is not widely available, even if everyone agrees that clustering systems with iscsi targets (instead of expensive FC SAN) could cut down the costs of the solutions.

Any news about target implementation (also not commercial ...) with release-reserve support?

Eugenio

eugenio.maffione@telecomitalia.it

                -----Messaggio originale-----
                Da: ips-admin@ietf.org per conto di sunzen.w
                Inviato: lun 01/03/2004 3.19
                A: ips@ietf.org
                Cc:
                Oggetto: [Ips] is a share disk possible on SCSI/iSCSI level?
               
               

                Hi,
                  Storaging networking enables storage consolodation and deployment.Typically disk array
                serves as a storage server, its storage is parted and exported via storage networking protocols
                such as iSCSI,etc. Share problem arises. Current solutions are mainly on upper file level, either
                additionally deploying a NAS or using a SAN file system. Is it possible on SCSI/iSCSI level?
                  In iSCSI spec, multi session on a target are allowed. is it for sharing?  On SCSI, OSD commands
                are designed.Is it the way for sharing on disk level?
                                               
               
                sunzen
                wangxz@ict.ac.cn
                2004-03-01
               
               
               
                _______________________________________________
                Ips mailing list
                Ips@ietf.org
                https://www1.ietf.org/mailman/listinfo/ips
               



====================================================================
CONFIDENTIALITY NOTICE
This message and its attachments are addressed solely to the persons
above and may contain confidential information. If you have received
the message in error, be informed that any use of the content hereof
is prohibited. Please return it immediately to the sender and delete
the message. Should you have any questions, please contact us by
replying to MailAdmin@tilab.com. Thank you
====================================================================

_______________________________________________
Ips mailing list
Ips@ietf.org
https://www1.ietf.org/mailman/listinfo/ips
--=_alternative 0028A68608256E55_=-- _______________________________________________ Ips mailing list Ips@ietf.org https://www1.ietf.org/mailman/listinfo/ips From exim@www1.ietf.org Fri Mar 12 09:02:00 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA21495 for ; Fri, 12 Mar 2004 09:02:00 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B1nEB-0008P3-DS for ips-archive@odin.ietf.org; Fri, 12 Mar 2004 09:01:32 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i2CE1VCL032301 for ips-archive@odin.ietf.org; Fri, 12 Mar 2004 09:01:31 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B1nEB-0008Ou-87 for ips-web-archive@optimus.ietf.org; Fri, 12 Mar 2004 09:01:31 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA21487 for ; Fri, 12 Mar 2004 09:01:28 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B1nE9-0007Wg-00 for ips-web-archive@ietf.org; Fri, 12 Mar 2004 09:01:29 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B1nDN-0007Q5-00 for ips-web-archive@ietf.org; Fri, 12 Mar 2004 09:00:42 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1B1nCq-0007IT-00 for ips-web-archive@ietf.org; Fri, 12 Mar 2004 09:00:08 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B1nCn-0008Ad-6R; Fri, 12 Mar 2004 09:00:05 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B1nCJ-00086P-CU for ips@optimus.ietf.org; Fri, 12 Mar 2004 08:59:35 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA21338 for ; Fri, 12 Mar 2004 08:59:32 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B1nCH-0007Fv-00 for ips@ietf.org; Fri, 12 Mar 2004 08:59:33 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B1nBL-000783-00 for ips@ietf.org; Fri, 12 Mar 2004 08:58:36 -0500 Received: from brmea-mail-3.sun.com ([192.18.98.34]) by ietf-mx with esmtp (Exim 4.12) id 1B1nAM-00070q-00 for ips@ietf.org; Fri, 12 Mar 2004 08:57:34 -0500 Received: from phys-giza-1 ([129.147.4.102]) by brmea-mail-3.sun.com (8.12.10/8.12.9) with ESMTP id i2CDvXf3028529 for ; Fri, 12 Mar 2004 06:57:34 -0700 (MST) Received: from sun.com (vpn-129-147-154-16.Central.Sun.COM [129.147.154.16]) by giza-mail1.Central.Sun.COM (iPlanet Messaging Server 5.2 HotFix 1.16 (built May 14 2003)) with ESMTP id <0HUG00J4CURWZ0@giza-mail1.Central.Sun.COM> for ips@ietf.org; Fri, 12 Mar 2004 06:57:33 -0700 (MST) Date: Fri, 12 Mar 2004 06:56:55 -0700 From: Paul von Behren Subject: Re: RIF: [Ips] is a share disk possible on SCSI/iSCSI level? In-reply-to: To: John Hufferd Cc: Maffione Eugenio , ips@ietf.org, ips-admin@ietf.org, wangxz@ict.ac.cn Message-id: <4051C1A7.4080206@sun.com> MIME-version: 1.0 Content-type: text/plain; format=flowed; charset=us-ascii Content-transfer-encoding: 7bit X-Accept-Language: en-us, en User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.4) Gecko/20030624 References: Content-Transfer-Encoding: 7bit Sender: ips-admin@ietf.org Errors-To: ips-admin@ietf.org 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: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit > This is pooled storage, not shared files and not shared (logical) disks. > . But shared logical units are commonly used with cluster software along with SCSI 3 persistrent reservations or SCSI 2 reserve/release (though the SCSI 2 commands should be avoided). My interpretation of the question was - are iSCSI disk/array vendors implementing SCSI PR or reserve/release? Paul John Hufferd wrote: > > Perhaps this is a basic misunderstanding about what disk sharing means. > > I think you are asking if there is something that is possible about > sharing the same LU from different computers. This is completely > independent of the Network interconnect. FC or iSCSI permit the Host > systems to issue Reserves or Releases. Even Persistent Reserves. The > question is does the File system on the Host systems know how to support > a shared LU. There are special File System available which know how to > do this, and they are independent of the network and will operate on > either FC or iSCSI. > > For normal pooled storage, the general support is the creation of a pool > of Logical LUs on an external (perhaps RAID) Controller. Many/most of > these permit a Virtualized set of LUs that span across the various > physical Disk Drives (It can even be done on a single partitioned disk > drive). In this type of a configuration each host system puts their own > File System on the LUs that they think are theirs. As a rule, > Reserve/Release is not an issue since each system will only "See" the > LUs that belong to it. > > There was some problems with this in the early days of FC, but today > with various forms of zoning and LUN masking, this is not a big problem. > > With iSCSI, I think that most/all vendors are defining to the External > Controllers the LUs that are addressable by authorized hosts, and those > are the only LUs the Host can get at. And, yes, in most of the > implementations these are logical LUs that map in some way to the > physical disks. And there is not usually any problems with Reserves. > > This is pooled storage, not shared files and not shared (logical) disks. > . > . > John L. Hufferd > Senior Technical Staff Member (STSM) > IBM/System Group, San Jose CA > Main Office: (408) 256-0403, Tie: 276-0403, eFax: (408) 904-4688 > Alt Office: (408) 997-6136, Cell: (408) 499-9702 > Internet Address: hufferd@us.ibm.com > > > *Maffione Eugenio * > Sent by: ips-admin@ietf.org > > 03/11/2004 11:30 AM > > > To > ips@ietf.org > cc > wangxz@ict.ac.cn > Subject > RIF: [Ips] is a share disk possible on SCSI/iSCSI level? > > > > > > > > > Hi, > the compatibility of commercial iscsi gateway with reserve-release > mechanism is not widely available, even if everyone agrees that > clustering systems with iscsi targets (instead of expensive FC SAN) > could cut down the costs of the solutions. > > Any news about target implementation (also not commercial ...) with > release-reserve support? > > Eugenio > > eugenio.maffione@telecomitalia.it > > -----Messaggio originale----- > Da: ips-admin@ietf.org per conto di sunzen.w > Inviato: lun 01/03/2004 3.19 > A: ips@ietf.org > Cc: > Oggetto: [Ips] is a share disk possible on SCSI/iSCSI level? > > > > Hi, > Storaging networking enables storage consolodation and > deployment.Typically disk array > serves as a storage server, its storage is parted and > exported via storage networking protocols > such as iSCSI,etc. Share problem arises. Current > solutions are mainly on upper file level, either > additionally deploying a NAS or using a SAN file system. > Is it possible on SCSI/iSCSI level? > In iSCSI spec, multi session on a target are allowed. > is it for sharing? On SCSI, OSD commands > are designed.Is it the way for sharing on disk level? > > > sunzen > wangxz@ict.ac.cn > 2004-03-01 > > > > _______________________________________________ > Ips mailing list > Ips@ietf.org > https://www1.ietf.org/mailman/listinfo/ips > > > > > ==================================================================== > CONFIDENTIALITY NOTICE > This message and its attachments are addressed solely to the persons > above and may contain confidential information. If you have received > the message in error, be informed that any use of the content hereof > is prohibited. Please return it immediately to the sender and delete > the message. Should you have any questions, please contact us by > replying to MailAdmin@tilab.com. Thank you > ==================================================================== > > _______________________________________________ > Ips mailing list > Ips@ietf.org > https://www1.ietf.org/mailman/listinfo/ips > _______________________________________________ Ips mailing list Ips@ietf.org https://www1.ietf.org/mailman/listinfo/ips From exim@www1.ietf.org Fri Mar 12 09:36:13 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA23744 for ; Fri, 12 Mar 2004 09:36:13 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B1nlJ-0002uC-RP for ips-archive@odin.ietf.org; Fri, 12 Mar 2004 09:35:45 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i2CEZjol011168 for ips-archive@odin.ietf.org; Fri, 12 Mar 2004 09:35:45 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B1nlJ-0002u3-Ia for ips-web-archive@optimus.ietf.org; Fri, 12 Mar 2004 09:35:45 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA23619 for ; Fri, 12 Mar 2004 09:35:42 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B1nlH-0005CD-00 for ips-web-archive@ietf.org; Fri, 12 Mar 2004 09:35:43 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B1njs-0004nG-00 for ips-web-archive@ietf.org; Fri, 12 Mar 2004 09:34:17 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1B1nif-0004V8-03 for ips-web-archive@ietf.org; Fri, 12 Mar 2004 09:33:01 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B1naw-0002DU-Ep; Fri, 12 Mar 2004 09:25:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B1naR-0002Bm-Dq for ips@optimus.ietf.org; Fri, 12 Mar 2004 09:24:31 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA23154 for ; Fri, 12 Mar 2004 09:24:28 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B1naP-0003ZX-00 for ips@ietf.org; Fri, 12 Mar 2004 09:24:29 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B1nZZ-0003TY-00 for ips@ietf.org; Fri, 12 Mar 2004 09:23:37 -0500 Received: from sadr.equallogic.com ([66.155.203.134]) by ietf-mx with smtp (Exim 4.12) id 1B1nYo-0003EV-00 for ips@ietf.org; Fri, 12 Mar 2004 09:22:50 -0500 Received: from sadr.equallogic.com (localhost.localdomain [127.0.0.1]) by sadr.equallogic.com (8.12.8/8.12.8) with ESMTP id i2CEMJPv019478 for ; Fri, 12 Mar 2004 09:22:19 -0500 Received: from deneb.dev.equallogic.com (deneb [172.16.1.99]) by sadr.equallogic.com (8.12.8/8.12.8) with ESMTP id i2CEMJM5019473; Fri, 12 Mar 2004 09:22:19 -0500 Received: from PKONING.equallogic.com (localhost.localdomain [127.0.0.1]) by deneb.dev.equallogic.com (8.11.6/8.11.6) with ESMTP id i2CEMFo04700; Fri, 12 Mar 2004 09:22:16 -0500 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <16465.51095.759000.701246@gargle.gargle.HOWL> Date: Fri, 12 Mar 2004 09:22:15 -0500 From: Paul Koning To: Paul.Vonbehren@Sun.COM Cc: ips@ietf.org Subject: Re: RIF: [Ips] is a share disk possible on SCSI/iSCSI level? References: <4051C1A7.4080206@sun.com> X-Mailer: VM 7.07 under 21.4 (patch 10) "Military Intelligence (Windows)" XEmacs Lucid Content-Transfer-Encoding: 7bit Sender: ips-admin@ietf.org Errors-To: ips-admin@ietf.org 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: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit >>>>> "Paul" == Paul von Behren writes: >> This is pooled storage, not shared files and not shared (logical) >> disks. . Paul> But shared logical units are commonly used with cluster Paul> software along with SCSI 3 persistrent reservations or SCSI 2 Paul> reserve/release (though the SCSI 2 commands should be avoided). Paul> My interpretation of the question was - are iSCSI disk/array Paul> vendors implementing SCSI PR or reserve/release? Yes. paul _______________________________________________ Ips mailing list Ips@ietf.org https://www1.ietf.org/mailman/listinfo/ips From exim@www1.ietf.org Fri Mar 12 12:13:11 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA03737 for ; Fri, 12 Mar 2004 12:13:11 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B1qDC-0007Ry-Tj for ips-archive@odin.ietf.org; Fri, 12 Mar 2004 12:12:44 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i2CHCg7O028634 for ips-archive@odin.ietf.org; Fri, 12 Mar 2004 12:12:42 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B1qDC-0007Rl-M8 for ips-web-archive@optimus.ietf.org; Fri, 12 Mar 2004 12:12:42 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA03719 for ; Fri, 12 Mar 2004 12:12:39 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B1qDB-0003fe-00 for ips-web-archive@ietf.org; Fri, 12 Mar 2004 12:12:41 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B1qCJ-0003XS-00 for ips-web-archive@ietf.org; Fri, 12 Mar 2004 12:11:47 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1B1qBd-0003Pv-00 for ips-web-archive@ietf.org; Fri, 12 Mar 2004 12:11:05 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B1qBa-0007FN-M5; Fri, 12 Mar 2004 12:11:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B1qBA-0007CX-QR for ips@optimus.ietf.org; Fri, 12 Mar 2004 12:10:37 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA03514 for ; Fri, 12 Mar 2004 12:10:33 -0500 (EST) From: wrstuden@wasabisystems.com Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B1qB9-0003Mf-00 for ips@ietf.org; Fri, 12 Mar 2004 12:10:35 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B1qAF-0003Dt-00 for ips@ietf.org; Fri, 12 Mar 2004 12:09:40 -0500 Received: from mononoke.wasabisystems.com ([151.199.66.145]) by ietf-mx with esmtp (Exim 4.12) id 1B1q9K-00035I-00 for ips@ietf.org; Fri, 12 Mar 2004 12:08:42 -0500 Received: by mononoke.wasabisystems.com (Postfix, from userid 1021) id 1088440134; Fri, 12 Mar 2004 12:08:41 -0500 (EST) Date: Fri, 12 Mar 2004 09:08:31 -0800 (PST) X-X-Sender: wrstuden@neverwinter.home-net.icnt.net To: Paul von Behren Cc: John Hufferd , Maffione Eugenio , ips@ietf.org, wangxz@ict.ac.cn Subject: Re: RIF: [Ips] is a share disk possible on SCSI/iSCSI level? In-Reply-To: <4051C1A7.4080206@sun.com> Message-ID: References: <4051C1A7.4080206@sun.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: ips-admin@ietf.org Errors-To: ips-admin@ietf.org 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: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.3 required=5.0 tests=AWL,NO_REAL_NAME autolearn=no version=2.60 On Fri, 12 Mar 2004, Paul von Behren wrote: > > This is pooled storage, not shared files and not shared (logical) disks. > > . > > But shared logical units are commonly used with cluster software > along with SCSI 3 persistrent reservations or SCSI 2 reserve/release > (though the SCSI 2 commands should be avoided). My interpretation > of the question was - are iSCSI disk/array vendors implementing > SCSI PR or reserve/release? Yes, both. Take care, Bill _______________________________________________ Ips mailing list Ips@ietf.org https://www1.ietf.org/mailman/listinfo/ips From exim@www1.ietf.org Fri Mar 12 12:38:17 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA05843 for ; Fri, 12 Mar 2004 12:38:17 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B1qbW-0000da-72 for ips-archive@odin.ietf.org; Fri, 12 Mar 2004 12:37:50 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i2CHboYq002438 for ips-archive@odin.ietf.org; Fri, 12 Mar 2004 12:37:50 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B1qbV-0000d5-Lb for ips-web-archive@optimus.ietf.org; Fri, 12 Mar 2004 12:37:49 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA05761 for ; Fri, 12 Mar 2004 12:37:45 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B1qbT-0000Lx-00 for ips-web-archive@ietf.org; Fri, 12 Mar 2004 12:37:47 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B1qa7-0007mK-00 for ips-web-archive@ietf.org; Fri, 12 Mar 2004 12:36:24 -0500 Received: from [65.246.255.50] (helo=mx2.foretec.com) by ietf-mx with esmtp (Exim 4.12) id 1B1qZ7-0007ZE-00 for ips-web-archive@ietf.org; Fri, 12 Mar 2004 12:35:21 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by mx2.foretec.com with esmtp (Exim 4.24) id 1B1qZ6-0004Pe-1z for ips-web-archive@ietf.org; Fri, 12 Mar 2004 12:35:21 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B1qYt-00008f-Bn; Fri, 12 Mar 2004 12:35:07 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B1qYR-0008SX-8t for ips@optimus.ietf.org; Fri, 12 Mar 2004 12:34:39 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA05460 for ; Fri, 12 Mar 2004 12:34:35 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B1qYP-0007UV-00 for ips@ietf.org; Fri, 12 Mar 2004 12:34:37 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B1qXZ-0007JL-00 for ips@ietf.org; Fri, 12 Mar 2004 12:33:46 -0500 Received: from mail2.microsoft.com ([131.107.3.124]) by ietf-mx with esmtp (Exim 4.12) id 1B1qWi-0006yH-00 for ips@ietf.org; Fri, 12 Mar 2004 12:32:53 -0500 Received: from INET-VRS-02.redmond.corp.microsoft.com ([157.54.8.110]) by mail2.microsoft.com with Microsoft SMTPSVC(6.0.3790.1041); Fri, 12 Mar 2004 09:32:18 -0800 Received: from 157.54.8.23 by INET-VRS-02.redmond.corp.microsoft.com (InterScan E-Mail VirusWall NT); Fri, 12 Mar 2004 09:32:21 -0800 Received: from RED-IMC-04.redmond.corp.microsoft.com ([157.54.2.168]) by inet-hub-01.redmond.corp.microsoft.com with Microsoft SMTPSVC(6.0.3790.0); Fri, 12 Mar 2004 09:32:14 -0800 Received: from win-imc-01.wingroup.windeploy.ntdev.microsoft.com ([157.54.0.39]) by RED-IMC-04.redmond.corp.microsoft.com with Microsoft SMTPSVC(6.0.3790.0); Fri, 12 Mar 2004 09:30:44 -0800 Received: from WIN-MSG-10.wingroup.windeploy.ntdev.microsoft.com ([157.54.12.81]) by win-imc-01.wingroup.windeploy.ntdev.microsoft.com with Microsoft SMTPSVC(6.0.3790.1069); Fri, 12 Mar 2004 09:32:16 -0800 X-MimeOLE: Produced By Microsoft Exchange V6.5.7195.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [Ips] is a share disk possible on SCSI/iSCSI level? Date: Fri, 12 Mar 2004 09:32:19 -0800 Message-ID: Thread-Topic: [Ips] is a share disk possible on SCSI/iSCSI level? thread-index: AcP/MzyMed6fDebRTam+yhs7L9UEpQIbANd3AC3A0uA= From: "Alan Warwick" To: "Maffione Eugenio" , Cc: X-OriginalArrivalTime: 12 Mar 2004 17:32:16.0878 (UTC) FILETIME=[F6C948E0:01C40857] Content-Transfer-Encoding: quoted-printable Sender: ips-admin@ietf.org Errors-To: ips-admin@ietf.org 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: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60 Content-Transfer-Encoding: quoted-printable Content-Transfer-Encoding: quoted-printable The Microsoft Windows iSCSI logo program requires and checks for SCSI RESERVE/RELEASE (per SPC & SPC-2). Any target that passes is ready for Windows cluster. There are a list of target devices that have passed logo testing at this link http://download.microsoft.com/download/c/b/0/cb05a3e3-2f85-4714-ab36-649 1b366bfd9/DFW-qualified-iSCSI-hardware1.xls. Alan -----Original Message----- From: ips-admin@ietf.org [mailto:ips-admin@ietf.org] On Behalf Of Maffione Eugenio Sent: Thursday, March 11, 2004 11:31 AM To: ips@ietf.org Cc: wangxz@ict.ac.cn Subject: RIF: [Ips] is a share disk possible on SCSI/iSCSI level? Hi, the compatibility of commercial iscsi gateway with reserve-release mechanism is not widely available, even if everyone agrees that clustering systems with iscsi targets (instead of expensive FC SAN) could cut down the costs of the solutions. =20 Any news about target implementation (also not commercial ...) with release-reserve support? =20 Eugenio =20 eugenio.maffione@telecomitalia.it -----Messaggio originale-----=20 Da: ips-admin@ietf.org per conto di sunzen.w=20 Inviato: lun 01/03/2004 3.19=20 A: ips@ietf.org=20 Cc:=20 Oggetto: [Ips] is a share disk possible on SCSI/iSCSI level? =09 =09 Hi, Storaging networking enables storage consolodation and deployment.Typically disk array serves as a storage server, its storage is parted and exported via storage networking protocols such as iSCSI,etc. Share problem arises. Current solutions are mainly on upper file level, either additionally deploying a NAS or using a SAN file system. Is it possible on SCSI/iSCSI level? In iSCSI spec, multi session on a target are allowed. is it for sharing? On SCSI, OSD commands are designed.Is it the way for sharing on disk level? =20 =09 sunzen wangxz@ict.ac.cn 2004-03-01 =09 =09 =09 _______________________________________________ Ips mailing list Ips@ietf.org https://www1.ietf.org/mailman/listinfo/ips =09 =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D CONFIDENTIALITY NOTICE This message and its attachments are addressed solely to the persons above and may contain confidential information. If you have received the message in error, be informed that any use of the content hereof is prohibited. Please return it immediately to the sender and delete the message. Should you have any questions, please contact us by replying to MailAdmin@tilab.com. Thank you =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D _______________________________________________ Ips mailing list Ips@ietf.org https://www1.ietf.org/mailman/listinfo/ips _______________________________________________ Ips mailing list Ips@ietf.org https://www1.ietf.org/mailman/listinfo/ips From exim@www1.ietf.org Fri Mar 12 13:08:09 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA08530 for ; Fri, 12 Mar 2004 13:08:09 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B1r4R-00033G-2M for ips-archive@odin.ietf.org; Fri, 12 Mar 2004 13:07:43 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i2CI7hqu011722 for ips-archive@odin.ietf.org; Fri, 12 Mar 2004 13:07:43 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B1r4Q-00032z-N1 for ips-web-archive@optimus.ietf.org; Fri, 12 Mar 2004 13:07:42 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA08519 for ; Fri, 12 Mar 2004 13:07:38 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B1r4O-0005G8-00 for ips-web-archive@ietf.org; Fri, 12 Mar 2004 13:07:40 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B1r3R-00058i-00 for ips-web-archive@ietf.org; Fri, 12 Mar 2004 13:06:42 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1B1r2o-00052G-00 for ips-web-archive@ietf.org; Fri, 12 Mar 2004 13:06:02 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B1r2o-0002fZ-Fi; Fri, 12 Mar 2004 13:06:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B1r2P-0002cf-IP for ips@optimus.ietf.org; Fri, 12 Mar 2004 13:05:37 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA08397 for ; Fri, 12 Mar 2004 13:05:33 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B1r2N-0004zo-00 for ips@ietf.org; Fri, 12 Mar 2004 13:05:35 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B1r1Q-0004rU-00 for ips@ietf.org; Fri, 12 Mar 2004 13:04:38 -0500 Received: from mail3.microsoft.com ([131.107.3.123]) by ietf-mx with esmtp (Exim 4.12) id 1B1r0W-0004dB-00 for ips@ietf.org; Fri, 12 Mar 2004 13:03:40 -0500 Received: from mail6.microsoft.com ([157.54.6.196]) by mail3.microsoft.com with Microsoft SMTPSVC(6.0.3790.0); Fri, 12 Mar 2004 10:03:10 -0800 Received: from inet-vrs-06.redmond.corp.microsoft.com ([157.54.6.181]) by mail6.microsoft.com with Microsoft SMTPSVC(6.0.3790.1069); Fri, 12 Mar 2004 10:02:45 -0800 Received: from 157.54.6.150 by inet-vrs-06.redmond.corp.microsoft.com (InterScan E-Mail VirusWall NT); Fri, 12 Mar 2004 10:03:09 -0800 Received: from RED-IMC-04.redmond.corp.microsoft.com ([157.54.2.168]) by inet-hub-05.redmond.corp.microsoft.com with Microsoft SMTPSVC(6.0.3790.0); Fri, 12 Mar 2004 10:03:06 -0800 Received: from win-imc-01.wingroup.windeploy.ntdev.microsoft.com ([157.54.0.39]) by RED-IMC-04.redmond.corp.microsoft.com with Microsoft SMTPSVC(6.0.3790.0); Fri, 12 Mar 2004 10:01:29 -0800 Received: from WIN-MSG-10.wingroup.windeploy.ntdev.microsoft.com ([157.54.12.81]) by win-imc-01.wingroup.windeploy.ntdev.microsoft.com with Microsoft SMTPSVC(6.0.3790.1069); Fri, 12 Mar 2004 10:03:04 -0800 X-MimeOLE: Produced By Microsoft Exchange V6.5.7195.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="------------InterScan_NT_MIME_Boundary" Date: Fri, 12 Mar 2004 10:03:08 -0800 Message-ID: Thread-Topic: Reservations, multiple sessions and ISID usage thread-index: AcQIXEaAsFRC6v39Q4uKYuAUBAN4GQ== From: "Alan Warwick" To: X-OriginalArrivalTime: 12 Mar 2004 18:03:04.0134 (UTC) FILETIME=[43D62E60:01C4085C] Subject: [Ips] Reservations, multiple sessions and ISID usage Sender: ips-admin@ietf.org Errors-To: ips-admin@ietf.org 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: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.2 required=5.0 tests=AWL,HTML_50_60, HTML_FONTCOLOR_UNKNOWN,HTML_MESSAGE autolearn=no version=2.60 This is a multi-part message in MIME format. --------------InterScan_NT_MIME_Boundary Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C4085C.5364CCB0" ------_=_NextPart_001_01C4085C.5364CCB0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable >From my understanding of the specifications there are these rules for managing multiple sessions to a target =20 1. Each session from the same initiator to the same target must have a different ISID if the two sessions login to portals that belong to the same portal group. 2. If the sessions are logged into portals that belong to different portal groups then the sessions may have the same ISID. 3. When establishing a session to a target the initiator should reuse the ISID that was previously used for a session to that target. =20 Given this I have a few questions =20 How do these rules affect the implementation of SCSI reserve and release in a load balancing environment where there are multiple sessions to a target ? What criteria does the target use to determine that all of the sessions are from the same initiator for the purposes of reserve so as to allow load balancing to occur over the multiple sessions ? Is it the Initiator name plus ISID, just the initiator name, something else or it depends ? I would think that just using the initiator name would make the most sense - what would be the usage scenario for using the initiator name plus ISID ? =20 Lets say I have 2 sessions to different portals in different portal groups and am using the same ISID when the target decides to merge the 2 portal groups into a single portal group. At this point my initiator is breaking rule #1 above. How are the targets and initiators supposed to handle this ? =20 Thanks, Alan =20 =20 ------_=_NextPart_001_01C4085C.5364CCB0 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

From my understanding of the specifications there are these rules for managing = multiple sessions to a target

 

  1. Each session from the same initiator = to the same target must = have a different ISID if the two sessions login to portals that belong to = the same portal group.
  2. If the sessions are logged into = portals that belong to different portal groups then the sessions may have the same = ISID.
  3. When establishing a session to a = target the initiator should = reuse the ISID that was previously used for a session to that = target.

 

Given this I have a few questions

 

How = do these rules affect the implementation of SCSI reserve and release in a load = balancing environment where there are multiple sessions to a target ? What = criteria does the target use to determine that all of the sessions are from the same = initiator for the purposes of reserve so as to  allow load balancing to occur = over the multiple sessions ?  Is it the Initiator name plus ISID, just = the initiator name, something else or it depends ?  I would think that = just using the initiator name would make the most sense – what would be = the usage scenario for using the initiator name plus ISID = ?

 

Lets say I have 2 sessions to different portals in different portal groups and am = using the same ISID when the target decides to merge the 2 portal groups into = a single portal group. At this point my initiator is breaking rule #1 = above. How are the targets and initiators supposed to handle this = ?

 

Thanks,

Alan

 

 

------_=_NextPart_001_01C4085C.5364CCB0-- --------------InterScan_NT_MIME_Boundary-- _______________________________________________ Ips mailing list Ips@ietf.org https://www1.ietf.org/mailman/listinfo/ips From exim@www1.ietf.org Fri Mar 12 17:44:21 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA23735 for ; Fri, 12 Mar 2004 17:44:21 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B1vNi-0000Yw-Fx for ips-archive@odin.ietf.org; Fri, 12 Mar 2004 17:43:54 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i2CMhspP002158 for ips-archive@odin.ietf.org; Fri, 12 Mar 2004 17:43:54 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B1vNi-0000Yj-A9 for ips-web-archive@optimus.ietf.org; Fri, 12 Mar 2004 17:43:54 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA23724 for ; Fri, 12 Mar 2004 17:43:50 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B1vNf-0004Ym-00 for ips-web-archive@ietf.org; Fri, 12 Mar 2004 17:43:51 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B1vMp-0004VV-00 for ips-web-archive@ietf.org; Fri, 12 Mar 2004 17:43:00 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1B1vLx-0004Sj-00 for ips-web-archive@ietf.org; Fri, 12 Mar 2004 17:42:05 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B1vLt-0000PV-Su; Fri, 12 Mar 2004 17:42:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B1vLf-0000Os-Gh for ips@optimus.ietf.org; Fri, 12 Mar 2004 17:41:47 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA23659 for ; Fri, 12 Mar 2004 17:41:43 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B1vLc-0004RD-00 for ips@ietf.org; Fri, 12 Mar 2004 17:41:44 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B1vKh-0004QC-00 for ips@ietf.org; Fri, 12 Mar 2004 17:40:48 -0500 Received: from e34.co.us.ibm.com ([32.97.110.132]) by ietf-mx with esmtp (Exim 4.12) id 1B1vKF-0004OE-00; Fri, 12 Mar 2004 17:40:19 -0500 Received: from westrelay04.boulder.ibm.com (westrelay04.boulder.ibm.com [9.17.193.32]) by e34.co.us.ibm.com (8.12.10/8.12.2) with ESMTP id i2CMdmrj434838; Fri, 12 Mar 2004 17:39:48 -0500 Received: from d03nm115.boulder.ibm.com (d03av02.boulder.ibm.com [9.17.193.82]) by westrelay04.boulder.ibm.com (8.12.10/NCO/VER6.6) with ESMTP id i2CMdljR097626; Fri, 12 Mar 2004 15:39:47 -0700 In-Reply-To: To: "Alan Warwick" Cc: ips@ietf.org, ips-admin@ietf.org MIME-Version: 1.0 Subject: Re: [Ips] Reservations, multiple sessions and ISID usage X-Mailer: Lotus Notes Release 6.0.2CF1 June 9, 2003 From: John Hufferd Message-ID: Date: Fri, 12 Mar 2004 14:39:41 -0800 X-MIMETrack: Serialize by Router on D03NM115/03/M/IBM(Release 6.0.2CF2HF168 | December 5, 2003) at 03/12/2004 15:39:47, Serialize complete at 03/12/2004 15:39:47 Content-Type: multipart/alternative; boundary="=_alternative 007C791F08256E55_=" Sender: ips-admin@ietf.org Errors-To: ips-admin@ietf.org 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: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.1 required=5.0 tests=AWL autolearn=no version=2.60 This is a multipart message in MIME format. --=_alternative 007C791F08256E55_= Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: base64 Q29tbWVudHMgaW4gbGluZSBtYXJrZWQgd2l0aCAvSHVmZi8gYW5kIFxIdWZmXA0KLg0KLg0KSm9o biBMLiBIdWZmZXJkDQpTZW5pb3IgVGVjaG5pY2FsIFN0YWZmIE1lbWJlciAoU1RTTSkNCklCTS9T eXN0ZW0gR3JvdXAsIFNhbiBKb3NlIENBDQpNYWluIE9mZmljZTogKDQwOCkgMjU2LTA0MDMsIFRp ZTogMjc2LTA0MDMsIGVGYXg6ICg0MDgpIDkwNC00Njg4DQpBbHQgT2ZmaWNlOiAoNDA4KSA5OTct NjEzNiwgQ2VsbDogKDQwOCkgNDk5LTk3MDINCkludGVybmV0IEFkZHJlc3M6IGh1ZmZlcmRAdXMu aWJtLmNvbQ0KDQoNCg0KIkFsYW4gV2Fyd2ljayIgPGFsYW53YXJAd2luZG93cy5taWNyb3NvZnQu Y29tPiANClNlbnQgYnk6IGlwcy1hZG1pbkBpZXRmLm9yZw0KMDMvMTIvMjAwNCAxMDowMyBBTQ0K DQpUbw0KPGlwc0BpZXRmLm9yZz4NCmNjDQoNClN1YmplY3QNCltJcHNdIFJlc2VydmF0aW9ucywg bXVsdGlwbGUgc2Vzc2lvbnMgYW5kIElTSUQgdXNhZ2UNCg0KDQoNCg0KDQoNCkZyb20gbXkgdW5k ZXJzdGFuZGluZyBvZiB0aGUgc3BlY2lmaWNhdGlvbnMgdGhlcmUgYXJlIHRoZXNlIHJ1bGVzIGZv ciANCm1hbmFnaW5nIG11bHRpcGxlIHNlc3Npb25zIHRvIGEgdGFyZ2V0DQogDQoxLiAgICAgIEVh Y2ggc2Vzc2lvbiBmcm9tIHRoZSBzYW1lIGluaXRpYXRvciB0byB0aGUgc2FtZSB0YXJnZXQgbXVz dCBoYXZlIA0KYSBkaWZmZXJlbnQgSVNJRCBpZiB0aGUgdHdvIHNlc3Npb25zIGxvZ2luIHRvIHBv cnRhbHMgdGhhdCBiZWxvbmcgdG8gdGhlIA0Kc2FtZSBwb3J0YWwgZ3JvdXAuDQoyLiAgICAgIElm IHRoZSBzZXNzaW9ucyBhcmUgbG9nZ2VkIGludG8gcG9ydGFscyB0aGF0IGJlbG9uZyB0byBkaWZm ZXJlbnQgDQpwb3J0YWwgZ3JvdXBzIHRoZW4gdGhlIHNlc3Npb25zIG1heSBoYXZlIHRoZSBzYW1l IElTSUQuDQozLiAgICAgIFdoZW4gZXN0YWJsaXNoaW5nIGEgc2Vzc2lvbiB0byBhIHRhcmdldCB0 aGUgaW5pdGlhdG9yIHNob3VsZCByZXVzZSANCnRoZSBJU0lEIHRoYXQgd2FzIHByZXZpb3VzbHkg dXNlZCBmb3IgYSBzZXNzaW9uIHRvIHRoYXQgdGFyZ2V0Lg0KDQovSHVmZi8gDQpUaGF0IGlzIGNv cnJlY3QuDQogXEh1ZmZcDQogDQpHaXZlbiB0aGlzIEkgaGF2ZSBhIGZldyBxdWVzdGlvbnMNCiAN CkhvdyBkbyB0aGVzZSBydWxlcyBhZmZlY3QgdGhlIGltcGxlbWVudGF0aW9uIG9mIFNDU0kgcmVz ZXJ2ZSBhbmQgcmVsZWFzZSANCmluIGEgbG9hZCBiYWxhbmNpbmcgZW52aXJvbm1lbnQgd2hlcmUg dGhlcmUgYXJlIG11bHRpcGxlIHNlc3Npb25zIHRvIGEgDQp0YXJnZXQgPyBXaGF0IGNyaXRlcmlh IGRvZXMgdGhlIHRhcmdldCB1c2UgdG8gZGV0ZXJtaW5lIHRoYXQgYWxsIG9mIHRoZSANCnNlc3Np b25zIGFyZSBmcm9tIHRoZSBzYW1lIGluaXRpYXRvciBmb3IgdGhlIHB1cnBvc2VzIG9mIHJlc2Vy dmUgc28gYXMgdG8gDQphbGxvdyBsb2FkIGJhbGFuY2luZyB0byBvY2N1ciBvdmVyIHRoZSBtdWx0 aXBsZSBzZXNzaW9ucyA/ICBJcyBpdCB0aGUgDQpJbml0aWF0b3IgbmFtZSBwbHVzIElTSUQsIGp1 c3QgdGhlIGluaXRpYXRvciBuYW1lLCBzb21ldGhpbmcgZWxzZSBvciBpdCANCmRlcGVuZHMgPyAg SSB3b3VsZCB0aGluayB0aGF0IGp1c3QgdXNpbmcgdGhlIGluaXRpYXRvciBuYW1lIHdvdWxkIG1h a2UgdGhlIA0KbW9zdCBzZW5zZSDigJMgd2hhdCB3b3VsZCBiZSB0aGUgdXNhZ2Ugc2NlbmFyaW8g Zm9yIHVzaW5nIHRoZSBpbml0aWF0b3IgbmFtZSANCnBsdXMgSVNJRCA/DQoNCi9IdWZmLw0KDQpU aGUgaVNDU0kgc3BlY2lmaWNhdGlvbiBpbiBzZWN0aW9uIDMuNC4yIGRlZmluZXMgdGhlIElfVCBu ZXh1cyBpZGVudGlmaWVyIA0KdG8gYmUgdGhlIHR1cGxlIChpU0NTSSBJbml0aWF0b3IgTmFtZSAr ICdpJyArIElTSUQsaVNDU0kgVGFyZ2V0IE5hbWUgKyAndCcgDQorIFBvcnRhbCBHcm91cCBUYWcp DQoNCiBJIGd1ZXNzIHRoZSBwcm9ibGVtIHRoYXQgSSBoYXZlIHdpdGggdGhpcyBxdWVzdGlvbiwg aXMgdGhhdCB5b3UgZXhwZWN0IA0KdGhlIFRhcmdldCB0byBkbyBzb21ldGhpbmcgc3BlY2lhbC4g IEl0IGNhbiBub3QgdGVsbCB0aGUgZGlmZmVyZW5jZSANCmJldHdlZW4gdGhlIFNlc3Npb25zIGFz IGJlaW5nIGZyb20gZGlmZmVyZW50IGluaXRpYXRvcnMgb24gdGhlIHNhbWUgaG9zdCANCm9yIGZy b20gZGlmZmVyZW50IGhvc3QuICBSZW1lbWJlciBhbGwgdGhlIHJlc2VydmF0aW9ucyBhcmUgZG9u ZSBhdCB0aGUgDQpTQ1NJIGxldmVsLCBub3QgdGhlIGlTQ1NJIGxldmVsLiAgVGhlc2UgZGlmZmVy ZW50IHNlc3Npb24gaGF2ZSBkaWZmZXJlbnQgDQpJLVQtTCBuZXh1cy4gIFRoZXNlIGFyZSB0aGUg YXJlYXMgdGhhdCBhcmUgdG8gYmUgaGFuZGxlZCBieSB0aGUgSG9zdCANCnNvZnR3YXJlLCB1c3Vh bGx5IGluIHdoYXQgd2UgY2FsbCB0aGUgIldlZGdlIERyaXZlcnMiICAoYWthIE1QSU8sIERQTywg DQpldGMuKS4gIFdlIGF0dGVtcHRlZCB0byB0cnkgdG8gYXZvaWQgdGhlIGlzc3VlcyB3aXRoIFdl ZGdlIERyaXZlcnMgYnkgDQpzdXBwb3J0aW5nIHRoZSBjb25jZXB0IG9mIE11bHRpcGxlIENvbm5l Y3Rpb25zIHBlciBTZXNzaW9uIChNUC9TKS4gIFRoaXMgDQp3YXMgdmVyeSBpbXBvcnRhbnQgaW4g ZW52aXJvbm1lbnRzIHRoYXQgaGFkIHNldmVyYWwgZGlmZmVyZW50IHZlbmRvcidzIA0KU3RvcmFn ZSBDb250cm9sbGVycy4gIFRoZSBuZWVkIHdhcyB0byBhdm9pZCB0aGUgcG90ZW50aWFsIGNvbmZs aWN0cyBpbiANCmRpZmZlcmVudCB2ZW5kb3IncyBXZWRnZSBEcml2ZXJzLiAgQnV0IGluIGFueSBl dmVudCwgV2VkZ2UgRHJpdmVycyBzdGlsbCANCndvcmsgaW4gYW4gaVNDU0kgZW52aXJvbm1lbnQg YXMgdGhleSBkbyBpbiBGQy4gDQoNCkluIG1hbnkgb2YgdGhlc2UgV2VkZ2UgRHJpdmVycywgdGhl eSBtYWtlIHN1cmUgdGhhdCBhbGwgdGhlIEkvTyBmb3IgYSANCnNwZWNpZmljIGxvZ2ljYWwgVW5p dCBvY2N1ciBvbiBhIHNpbmdsZSBMb2dpY2FsIFNDU0kgQnVzIChGQyBXV04gb3IgaVNDU0kgDQpT ZXNzaW9uKSwgc28gdGhlIGlzc3VlIG9mIGhhdmluZyB0aGUgUmVzZXJ2YXRpb25zIGZvciBhbiBM VSBhY3Jvc3MgDQpkaWZmZXJlbnQgbG9naWNhbCBTQ1NJIGJ1c2VzIGp1c3QgZG9lc24ndCBvY2N1 ci4gIEJ1dCB0byB0aGUgZXh0ZW50IHRoYXQgYSANCndlZGdlIGRyaXZlciBhdHRlbXB0cyB0byAi QmFsYW5jZSIgdGhlIExVIEkvTyBhY3Jvc3MgdGhlc2UgbG9naWNhbCBTQ1NJIA0KYnVzZXMgKGUu Zy4gaVNDU0kgU2Vzc2lvbnMpLCB0aGVuIGl0ICh0aGUgaG9zdCBXZWRnZSBEcml2ZXIgU1cpIG11 c3QgDQpoYW5kbGUgdGhlIGlzc3VlcyBvZiBSZXNlcnZlcyAoTm90IHRoZSBUYXJnZXQpLg0KDQpJ dCBpcyBiZXN0IHRvIHVzZSBNQy9TIGFuZCBhdm9pZCBhbGwgdGhvc2UgcHJvYmxlbXMuDQpcSHVm ZlwgDQogDQpMZXRzIHNheSBJIGhhdmUgMiBzZXNzaW9ucyB0byBkaWZmZXJlbnQgcG9ydGFscyBp biBkaWZmZXJlbnQgcG9ydGFsIGdyb3VwcyANCmFuZCBhbSB1c2luZyB0aGUgc2FtZSBJU0lEIHdo ZW4gdGhlIHRhcmdldCBkZWNpZGVzIHRvIG1lcmdlIHRoZSAyIHBvcnRhbCANCmdyb3VwcyBpbnRv IGEgc2luZ2xlIHBvcnRhbCBncm91cC4gQXQgdGhpcyBwb2ludCBteSBpbml0aWF0b3IgaXMgYnJl YWtpbmcgDQpydWxlICMxIGFib3ZlLiBIb3cgYXJlIHRoZSB0YXJnZXRzIGFuZCBpbml0aWF0b3Jz IHN1cHBvc2VkIHRvIGhhbmRsZSB0aGlzIA0KPw0KDQovSHVmZi8NCkkgd291bGQgc3Ryb25nbHkg cmVjb21tZW5kIHRoYXQgeW91IHN0b3AgeW91ciBjb25uZWN0aW9ucyBpbiBzb21lIHdheSANCmJl Zm9yZSB5b3UgZG8gdGhpcyBqb2luaW5nIG9mIHRhcmdldCBwb3J0YWwgZ3JvdXBzLCB0aGVuIHVw ZGF0ZSB5b3VyIA0KZGlzY292ZXJ5IGluZm9ybWF0aW9uLCBhbmQgdGhlbiBwZXJtaXQgdGhlIGhv c3QgdG8gcmVkaXNjb3ZlciB0aGUgcGF0aHMsIA0KY29ubmVjdGlvbnMgYW5kIHBvcnRhbCBncm91 cHMuIA0KXEh1ZmZcDQoNCiANClRoYW5rcywNCkFsYW4NCiANCiANCg0K --=_alternative 007C791F08256E55_= Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: base64 DQo8YnI+PGZvbnQgc2l6ZT0yIGZhY2U9InNhbnMtc2VyaWYiPkNvbW1lbnRzIGluIGxpbmUgbWFy a2VkIHdpdGggL0h1ZmYvDQphbmQgXEh1ZmZcPC9mb250Pg0KPGJyPjxmb250IHNpemU9MiBmYWNl PSJzYW5zLXNlcmlmIj4uPGJyPg0KLjxicj4NCkpvaG4gTC4gSHVmZmVyZDxicj4NClNlbmlvciBU ZWNobmljYWwgU3RhZmYgTWVtYmVyIChTVFNNKTxicj4NCklCTS9TeXN0ZW0gR3JvdXAsIFNhbiBK b3NlIENBPGJyPg0KTWFpbiBPZmZpY2U6ICg0MDgpIDI1Ni0wNDAzLCBUaWU6IDI3Ni0wNDAzLCBl RmF4OiAoNDA4KSA5MDQtNDY4ODxicj4NCkFsdCBPZmZpY2U6ICg0MDgpIDk5Ny02MTM2LCBDZWxs OiAoNDA4KSA0OTktOTcwMjxicj4NCkludGVybmV0IEFkZHJlc3M6IGh1ZmZlcmRAdXMuaWJtLmNv bTwvZm9udD4NCjxicj4NCjxicj4NCjxicj4NCjx0YWJsZSB3aWR0aD0xMDAlPg0KPHRyIHZhbGln bj10b3A+DQo8dGQgd2lkdGg9NDAlPjxmb250IHNpemU9MSBmYWNlPSJzYW5zLXNlcmlmIj48Yj4m cXVvdDtBbGFuIFdhcndpY2smcXVvdDsNCiZsdDthbGFud2FyQHdpbmRvd3MubWljcm9zb2Z0LmNv bSZndDs8L2I+IDwvZm9udD4NCjxicj48Zm9udCBzaXplPTEgZmFjZT0ic2Fucy1zZXJpZiI+U2Vu dCBieTogaXBzLWFkbWluQGlldGYub3JnPC9mb250Pg0KPHA+PGZvbnQgc2l6ZT0xIGZhY2U9InNh bnMtc2VyaWYiPjAzLzEyLzIwMDQgMTA6MDMgQU08L2ZvbnQ+DQo8dGQgd2lkdGg9NTklPg0KPHRh YmxlIHdpZHRoPTEwMCU+DQo8dHI+DQo8dGQ+DQo8ZGl2IGFsaWduPXJpZ2h0Pjxmb250IHNpemU9 MSBmYWNlPSJzYW5zLXNlcmlmIj5UbzwvZm9udD48L2Rpdj4NCjx0ZCB2YWxpZ249dG9wPjxmb250 IHNpemU9MSBmYWNlPSJzYW5zLXNlcmlmIj4mbHQ7aXBzQGlldGYub3JnJmd0OzwvZm9udD4NCjx0 cj4NCjx0ZD4NCjxkaXYgYWxpZ249cmlnaHQ+PGZvbnQgc2l6ZT0xIGZhY2U9InNhbnMtc2VyaWYi PmNjPC9mb250PjwvZGl2Pg0KPHRkIHZhbGlnbj10b3A+DQo8dHI+DQo8dGQ+DQo8ZGl2IGFsaWdu PXJpZ2h0Pjxmb250IHNpemU9MSBmYWNlPSJzYW5zLXNlcmlmIj5TdWJqZWN0PC9mb250PjwvZGl2 Pg0KPHRkIHZhbGlnbj10b3A+PGZvbnQgc2l6ZT0xIGZhY2U9InNhbnMtc2VyaWYiPltJcHNdIFJl c2VydmF0aW9ucywgbXVsdGlwbGUNCnNlc3Npb25zIGFuZCBJU0lEIHVzYWdlPC9mb250PjwvdGFi bGU+DQo8YnI+DQo8dGFibGU+DQo8dHIgdmFsaWduPXRvcD4NCjx0ZD4NCjx0ZD48L3RhYmxlPg0K PGJyPjwvdGFibGU+DQo8YnI+DQo8YnI+DQo8YnI+PGZvbnQgc2l6ZT0yIGNvbG9yPSNmZjAwZmYg ZmFjZT0iQ29taWMgU2FucyBNUyI+RnJvbSBteSB1bmRlcnN0YW5kaW5nDQpvZiB0aGUgc3BlY2lm aWNhdGlvbnMgdGhlcmUgYXJlIHRoZXNlIHJ1bGVzIGZvciBtYW5hZ2luZyBtdWx0aXBsZSBzZXNz aW9ucw0KdG8gYSB0YXJnZXQ8L2ZvbnQ+DQo8YnI+PGZvbnQgc2l6ZT0yIGNvbG9yPSNmZjAwZmYg ZmFjZT0iQ29taWMgU2FucyBNUyI+Jm5ic3A7PC9mb250Pg0KPGJyPjxmb250IHNpemU9MiBmYWNl PSJzYW5zLXNlcmlmIj4xLiAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDs8L2ZvbnQ+PGZvbnQg c2l6ZT0yIGNvbG9yPSNmZjAwZmYgZmFjZT0iQ29taWMgU2FucyBNUyI+RWFjaA0Kc2Vzc2lvbiBm cm9tIHRoZSBzYW1lIGluaXRpYXRvciB0byB0aGUgc2FtZSB0YXJnZXQgPGI+bXVzdDwvYj4gaGF2 ZSBhIGRpZmZlcmVudA0KSVNJRCBpZiB0aGUgdHdvIHNlc3Npb25zIGxvZ2luIHRvIHBvcnRhbHMg dGhhdCBiZWxvbmcgdG8gdGhlIHNhbWUgcG9ydGFsDQpncm91cC48L2ZvbnQ+DQo8YnI+PGZvbnQg c2l6ZT0yIGZhY2U9InNhbnMtc2VyaWYiPjIuICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOzwv Zm9udD48Zm9udCBzaXplPTIgY29sb3I9I2ZmMDBmZiBmYWNlPSJDb21pYyBTYW5zIE1TIj5JZg0K dGhlIHNlc3Npb25zIGFyZSBsb2dnZWQgaW50byBwb3J0YWxzIHRoYXQgYmVsb25nIHRvIGRpZmZl cmVudCBwb3J0YWwgZ3JvdXBzDQp0aGVuIHRoZSBzZXNzaW9ucyA8Yj5tYXk8L2I+IGhhdmUgdGhl IHNhbWUgSVNJRC48L2ZvbnQ+DQo8YnI+PGZvbnQgc2l6ZT0yIGZhY2U9InNhbnMtc2VyaWYiPjMu ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOzwvZm9udD48Zm9udCBzaXplPTIgY29sb3I9I2Zm MDBmZiBmYWNlPSJDb21pYyBTYW5zIE1TIj5XaGVuDQplc3RhYmxpc2hpbmcgYSBzZXNzaW9uIHRv IGEgdGFyZ2V0IHRoZSBpbml0aWF0b3IgPGI+c2hvdWxkPC9iPiByZXVzZSB0aGUNCklTSUQgdGhh dCB3YXMgcHJldmlvdXNseSB1c2VkIGZvciBhIHNlc3Npb24gdG8gdGhhdCB0YXJnZXQuPC9mb250 Pg0KPGJyPg0KPGJyPjxmb250IHNpemU9MiBmYWNlPSJDb21pYyBTYW5zIE1TIj4vSHVmZi8gPC9m b250Pg0KPGJyPjxmb250IHNpemU9MiBmYWNlPSJDb21pYyBTYW5zIE1TIj5UaGF0IGlzIGNvcnJl Y3QuPC9mb250Pg0KPGJyPjxmb250IHNpemU9MiBmYWNlPSJDb21pYyBTYW5zIE1TIj4mbmJzcDtc SHVmZlw8L2ZvbnQ+DQo8YnI+PGZvbnQgc2l6ZT0yIGNvbG9yPSNmZjAwZmYgZmFjZT0iQ29taWMg U2FucyBNUyI+Jm5ic3A7PC9mb250Pg0KPGJyPjxmb250IHNpemU9MiBjb2xvcj0jZmYwMGZmIGZh Y2U9IkNvbWljIFNhbnMgTVMiPkdpdmVuIHRoaXMgSSBoYXZlIGENCmZldyBxdWVzdGlvbnM8L2Zv bnQ+DQo8YnI+PGZvbnQgc2l6ZT0yIGNvbG9yPSNmZjAwZmYgZmFjZT0iQ29taWMgU2FucyBNUyI+ Jm5ic3A7PC9mb250Pg0KPGJyPjxmb250IHNpemU9MiBjb2xvcj0jZmYwMGZmIGZhY2U9IkNvbWlj IFNhbnMgTVMiPkhvdyBkbyB0aGVzZSBydWxlcw0KYWZmZWN0IHRoZSBpbXBsZW1lbnRhdGlvbiBv ZiBTQ1NJIHJlc2VydmUgYW5kIHJlbGVhc2UgaW4gYSBsb2FkIGJhbGFuY2luZw0KZW52aXJvbm1l bnQgd2hlcmUgdGhlcmUgYXJlIG11bHRpcGxlIHNlc3Npb25zIHRvIGEgdGFyZ2V0ID8gV2hhdCBj cml0ZXJpYQ0KZG9lcyB0aGUgdGFyZ2V0IHVzZSB0byBkZXRlcm1pbmUgdGhhdCBhbGwgb2YgdGhl IHNlc3Npb25zIGFyZSBmcm9tIHRoZQ0Kc2FtZSBpbml0aWF0b3IgZm9yIHRoZSBwdXJwb3NlcyBv ZiByZXNlcnZlIHNvIGFzIHRvICZuYnNwO2FsbG93IGxvYWQgYmFsYW5jaW5nDQp0byBvY2N1ciBv dmVyIHRoZSBtdWx0aXBsZSBzZXNzaW9ucyA/ICZuYnNwO0lzIGl0IHRoZSBJbml0aWF0b3IgbmFt ZSBwbHVzDQpJU0lELCBqdXN0IHRoZSBpbml0aWF0b3IgbmFtZSwgc29tZXRoaW5nIGVsc2Ugb3Ig aXQgZGVwZW5kcyA/ICZuYnNwO0kgd291bGQNCnRoaW5rIHRoYXQganVzdCB1c2luZyB0aGUgaW5p dGlhdG9yIG5hbWUgd291bGQgbWFrZSB0aGUgbW9zdCBzZW5zZSDigJMgd2hhdA0Kd291bGQgYmUg dGhlIHVzYWdlIHNjZW5hcmlvIGZvciB1c2luZyB0aGUgaW5pdGlhdG9yIG5hbWUgcGx1cyBJU0lE ID88L2ZvbnQ+DQo8YnI+DQo8YnI+PGZvbnQgc2l6ZT0yIGZhY2U9IkNvbWljIFNhbnMgTVMiPi9I dWZmLzwvZm9udD4NCjxicj4NCjxicj48Zm9udCBzaXplPTI+PHR0PlRoZSBpU0NTSSBzcGVjaWZp Y2F0aW9uIGluIHNlY3Rpb24gMy40LjIgZGVmaW5lcyB0aGUNCklfVCBuZXh1cyBpZGVudGlmaWVy IHRvIGJlIHRoZSB0dXBsZSAoaVNDU0kgSW5pdGlhdG9yIE5hbWUgKyAnaScgKyBJU0lELGlTQ1NJ DQpUYXJnZXQgTmFtZSArICd0JyArIFBvcnRhbCBHcm91cCBUYWcpPC90dD48L2ZvbnQ+DQo8YnI+ DQo8YnI+PGZvbnQgc2l6ZT0yIGZhY2U9IkNvbWljIFNhbnMgTVMiPiZuYnNwO0kgZ3Vlc3MgdGhl IHByb2JsZW0gdGhhdCBJDQpoYXZlIHdpdGggdGhpcyBxdWVzdGlvbiwgaXMgdGhhdCB5b3UgZXhw ZWN0IHRoZSBUYXJnZXQgdG8gZG8gc29tZXRoaW5nDQpzcGVjaWFsLiAmbmJzcDtJdCBjYW4gbm90 IHRlbGwgdGhlIGRpZmZlcmVuY2UgYmV0d2VlbiB0aGUgU2Vzc2lvbnMgYXMgYmVpbmcNCmZyb20g ZGlmZmVyZW50IGluaXRpYXRvcnMgb24gdGhlIHNhbWUgaG9zdCBvciBmcm9tIGRpZmZlcmVudCBo b3N0LiAmbmJzcDtSZW1lbWJlcg0KYWxsIHRoZSByZXNlcnZhdGlvbnMgYXJlIGRvbmUgYXQgdGhl IFNDU0kgbGV2ZWwsIG5vdCB0aGUgaVNDU0kgbGV2ZWwuICZuYnNwO1RoZXNlDQpkaWZmZXJlbnQg c2Vzc2lvbiBoYXZlIGRpZmZlcmVudCBJLVQtTCBuZXh1cy4gJm5ic3A7VGhlc2UgYXJlIHRoZSBh cmVhcw0KdGhhdCBhcmUgdG8gYmUgaGFuZGxlZCBieSB0aGUgSG9zdCBzb2Z0d2FyZSwgdXN1YWxs eSBpbiB3aGF0IHdlIGNhbGwgdGhlDQomcXVvdDtXZWRnZSBEcml2ZXJzJnF1b3Q7ICZuYnNwOyhh a2EgTVBJTywgRFBPLCBldGMuKS4gJm5ic3A7V2UgYXR0ZW1wdGVkDQp0byB0cnkgdG8gYXZvaWQg dGhlIGlzc3VlcyB3aXRoIFdlZGdlIERyaXZlcnMgYnkgc3VwcG9ydGluZyB0aGUgY29uY2VwdA0K b2YgTXVsdGlwbGUgQ29ubmVjdGlvbnMgcGVyIFNlc3Npb24gKE1QL1MpLiAmbmJzcDtUaGlzIHdh cyB2ZXJ5IGltcG9ydGFudA0KaW4gZW52aXJvbm1lbnRzIHRoYXQgaGFkIHNldmVyYWwgZGlmZmVy ZW50IHZlbmRvcidzIFN0b3JhZ2UgQ29udHJvbGxlcnMuDQombmJzcDtUaGUgbmVlZCB3YXMgdG8g YXZvaWQgdGhlIHBvdGVudGlhbCBjb25mbGljdHMgaW4gZGlmZmVyZW50IHZlbmRvcidzDQpXZWRn ZSBEcml2ZXJzLiAmbmJzcDtCdXQgaW4gYW55IGV2ZW50LCBXZWRnZSBEcml2ZXJzIHN0aWxsIHdv cmsgaW4gYW4gaVNDU0kNCmVudmlyb25tZW50IGFzIHRoZXkgZG8gaW4gRkMuICZuYnNwOzwvZm9u dD4NCjxicj4NCjxicj48Zm9udCBzaXplPTIgZmFjZT0iQ29taWMgU2FucyBNUyI+SW4gbWFueSBv ZiB0aGVzZSBXZWRnZSBEcml2ZXJzLCB0aGV5DQptYWtlIHN1cmUgdGhhdCBhbGwgdGhlIEkvTyBm b3IgYSBzcGVjaWZpYyBsb2dpY2FsIFVuaXQgb2NjdXIgb24gYSBzaW5nbGUNCkxvZ2ljYWwgU0NT SSBCdXMgKEZDIFdXTiBvciBpU0NTSSBTZXNzaW9uKSwgc28gdGhlIGlzc3VlIG9mIGhhdmluZyB0 aGUNClJlc2VydmF0aW9ucyBmb3IgYW4gTFUgYWNyb3NzIGRpZmZlcmVudCBsb2dpY2FsIFNDU0kg YnVzZXMganVzdCBkb2Vzbid0DQpvY2N1ci4gJm5ic3A7QnV0IHRvIHRoZSBleHRlbnQgdGhhdCBh IHdlZGdlIGRyaXZlciBhdHRlbXB0cyB0byAmcXVvdDtCYWxhbmNlJnF1b3Q7DQp0aGUgTFUgSS9P IGFjcm9zcyB0aGVzZSBsb2dpY2FsIFNDU0kgYnVzZXMgKGUuZy4gaVNDU0kgU2Vzc2lvbnMpLCB0 aGVuDQppdCAodGhlIGhvc3QgV2VkZ2UgRHJpdmVyIFNXKSBtdXN0IGhhbmRsZSB0aGUgaXNzdWVz IG9mIFJlc2VydmVzIChOb3QgdGhlDQpUYXJnZXQpLjwvZm9udD4NCjxicj4NCjxicj48Zm9udCBz aXplPTIgZmFjZT0iQ29taWMgU2FucyBNUyI+SXQgaXMgYmVzdCB0byB1c2UgTUMvUyBhbmQgYXZv aWQNCmFsbCB0aG9zZSBwcm9ibGVtcy48L2ZvbnQ+DQo8YnI+PGZvbnQgc2l6ZT0yIGZhY2U9IkNv bWljIFNhbnMgTVMiPlxIdWZmXCA8L2ZvbnQ+DQo8YnI+PGZvbnQgc2l6ZT0yIGNvbG9yPSNmZjAw ZmYgZmFjZT0iQ29taWMgU2FucyBNUyI+Jm5ic3A7PC9mb250Pg0KPGJyPjxmb250IHNpemU9MiBj b2xvcj0jZmYwMGZmIGZhY2U9IkNvbWljIFNhbnMgTVMiPkxldHMgc2F5IEkgaGF2ZSAyIHNlc3Np b25zDQp0byBkaWZmZXJlbnQgcG9ydGFscyBpbiBkaWZmZXJlbnQgcG9ydGFsIGdyb3VwcyBhbmQg YW0gdXNpbmcgdGhlIHNhbWUgSVNJRA0Kd2hlbiB0aGUgdGFyZ2V0IGRlY2lkZXMgdG8gbWVyZ2Ug dGhlIDIgcG9ydGFsIGdyb3VwcyBpbnRvIGEgc2luZ2xlIHBvcnRhbA0KZ3JvdXAuIEF0IHRoaXMg cG9pbnQgbXkgaW5pdGlhdG9yIGlzIGJyZWFraW5nIHJ1bGUgIzEgYWJvdmUuIEhvdyBhcmUgdGhl DQp0YXJnZXRzIGFuZCBpbml0aWF0b3JzIHN1cHBvc2VkIHRvIGhhbmRsZSB0aGlzID88L2ZvbnQ+ DQo8YnI+DQo8YnI+PGZvbnQgc2l6ZT0yIGZhY2U9IkNvbWljIFNhbnMgTVMiPi9IdWZmLzwvZm9u dD4NCjxicj48Zm9udCBzaXplPTIgZmFjZT0iQ29taWMgU2FucyBNUyI+SSB3b3VsZCBzdHJvbmds eSByZWNvbW1lbmQgdGhhdCB5b3UNCnN0b3AgeW91ciBjb25uZWN0aW9ucyBpbiBzb21lIHdheSBi ZWZvcmUgeW91IGRvIHRoaXMgam9pbmluZyBvZiB0YXJnZXQNCnBvcnRhbCBncm91cHMsIHRoZW4g dXBkYXRlIHlvdXIgZGlzY292ZXJ5IGluZm9ybWF0aW9uLCBhbmQgdGhlbiBwZXJtaXQNCnRoZSBo b3N0IHRvIHJlZGlzY292ZXIgdGhlIHBhdGhzLCBjb25uZWN0aW9ucyBhbmQgcG9ydGFsIGdyb3Vw cy4gJm5ic3A7PC9mb250Pg0KPGJyPjxmb250IHNpemU9MiBmYWNlPSJDb21pYyBTYW5zIE1TIj5c SHVmZlw8L2ZvbnQ+DQo8YnI+DQo8YnI+PGZvbnQgc2l6ZT0yIGNvbG9yPSNmZjAwZmYgZmFjZT0i Q29taWMgU2FucyBNUyI+Jm5ic3A7PC9mb250Pg0KPGJyPjxmb250IHNpemU9MiBjb2xvcj0jZmYw MGZmIGZhY2U9IkNvbWljIFNhbnMgTVMiPlRoYW5rcyw8L2ZvbnQ+DQo8YnI+PGZvbnQgc2l6ZT0y IGNvbG9yPSNmZjAwZmYgZmFjZT0iQ29taWMgU2FucyBNUyI+QWxhbjwvZm9udD4NCjxicj48Zm9u dCBzaXplPTIgY29sb3I9I2ZmMDBmZiBmYWNlPSJDb21pYyBTYW5zIE1TIj4mbmJzcDs8L2ZvbnQ+ DQo8YnI+PGZvbnQgc2l6ZT0yIGNvbG9yPSNmZjAwZmYgZmFjZT0iQ29taWMgU2FucyBNUyI+Jm5i c3A7PC9mb250Pg0KPGJyPg0K --=_alternative 007C791F08256E55_=-- _______________________________________________ Ips mailing list Ips@ietf.org https://www1.ietf.org/mailman/listinfo/ips From exim@www1.ietf.org Sat Mar 13 10:39:50 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA19160 for ; Sat, 13 Mar 2004 10:39:50 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B2BER-0003qw-SM for ips-archive@odin.ietf.org; Sat, 13 Mar 2004 10:39:24 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i2DFdNn0014804 for ips-archive@odin.ietf.org; Sat, 13 Mar 2004 10:39:23 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B2BER-0003qh-N8 for ips-web-archive@optimus.ietf.org; Sat, 13 Mar 2004 10:39:23 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA19154 for ; Sat, 13 Mar 2004 10:39:19 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B2BEP-0003r3-00 for ips-web-archive@ietf.org; Sat, 13 Mar 2004 10:39:21 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B2BDX-0003nR-00 for ips-web-archive@ietf.org; Sat, 13 Mar 2004 10:38:27 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1B2BDC-0003js-00 for ips-web-archive@ietf.org; Sat, 13 Mar 2004 10:38:06 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B2BD9-0003hB-4b; Sat, 13 Mar 2004 10:38:03 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B2BCc-0003Y7-TL for ips@optimus.ietf.org; Sat, 13 Mar 2004 10:37:31 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA19088 for ; Sat, 13 Mar 2004 10:37:26 -0500 (EST) From: AClarke@attotech.com Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B2BCa-0003jH-00 for ips@ietf.org; Sat, 13 Mar 2004 10:37:28 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B2BBd-0003fG-00 for ips@ietf.org; Sat, 13 Mar 2004 10:36:29 -0500 Received: from sw.attotech.com ([12.32.232.56] helo=noteserv1.attotech.com) by ietf-mx with esmtp (Exim 4.12) id 1B2BBM-0003b4-00; Sat, 13 Mar 2004 10:36:13 -0500 Subject: Re: [Ips] Reservations, multiple sessions and ISID usage To: "Alan Warwick" Cc: ips@ietf.org, ips-admin@ietf.org Message-ID: Date: Sat, 13 Mar 2004 10:35:50 -0500 MIME-Version: 1.0 Content-type: text/plain; charset=us-ascii Sender: ips-admin@ietf.org Errors-To: ips-admin@ietf.org 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: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.3 required=5.0 tests=AWL,NO_REAL_NAME autolearn=no version=2.60 >How do these rules affect the implementation of SCSI reserve and release in a load balancing environment where there are >multiple sessions to a target ? What criteria does the target use to determine that all of the sessions are from the same initiator >for the purposes of reserve so as to allow load balancing to occur over the multiple sessions ? I think that a the target should not have to detect multiple session load balancing OS's. I think that this view is in line with the iSCSI specification (references cited below). I do have some related questions and comments 1. Do other SCSI transport protocol targets detect load balancing OS's using multiple initiators? 2. If a target does not detect load balancing then the reserve/release would be a bottleneck (that resource path would be locked), but multiple connection sessions solves this problem and is well defined. Other that lack of target support, why can't multiple connection sessions be used instead? >From Sec. 9.1.2 The designers of the iSCSI protocol envisioned there being one iSCSI Initiator Node Name per operating system image on a machine. This enables SAN resource configuration and authentication schemes based on a system's identity. It supports the notion that it should be possible to assign access to storage resources based on "initiator device" identity. Sec. 2.1 - Session: The group of TCP connections that link an initiator with a target form a session (loosely equivalent to a SCSI I-T nexus). TCP connections can be added and removed from a session. Across all connections within a session, an initiator sees one and the same target. >From Sec. 9. (my favorite) The guiding assumption made throughout the design of this protocol is that targets are resource constrained relative to initiators. I would appreciate any comments or corrections. Aaron _______________________________________________ Ips mailing list Ips@ietf.org https://www1.ietf.org/mailman/listinfo/ips From exim@www1.ietf.org Sat Mar 13 22:12:17 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA14359 for ; Sat, 13 Mar 2004 22:12:17 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B2M2W-0000C0-AV for ips-archive@odin.ietf.org; Sat, 13 Mar 2004 22:11:50 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i2E3BmI4000734 for ips-archive@odin.ietf.org; Sat, 13 Mar 2004 22:11:48 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B2M2W-0000Bl-2q for ips-web-archive@optimus.ietf.org; Sat, 13 Mar 2004 22:11:48 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA14342 for ; Sat, 13 Mar 2004 22:11:44 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B2M2T-000260-00 for ips-web-archive@ietf.org; Sat, 13 Mar 2004 22:11:45 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B2M1Y-00021K-00 for ips-web-archive@ietf.org; Sat, 13 Mar 2004 22:10:49 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1B2M0s-0001wZ-00 for ips-web-archive@ietf.org; Sat, 13 Mar 2004 22:10:06 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B2M0p-0008WL-4W; Sat, 13 Mar 2004 22:10:03 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B2M0T-0008VX-OJ for ips@optimus.ietf.org; Sat, 13 Mar 2004 22:09:41 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA14265 for ; Sat, 13 Mar 2004 22:09:37 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B2M0Q-0001vC-00 for ips@ietf.org; Sat, 13 Mar 2004 22:09:38 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B2LzU-0001rW-00 for ips@ietf.org; Sat, 13 Mar 2004 22:08:41 -0500 Received: from astound-64-85-224-245.ca.astound.net ([64.85.224.245] helo=master.linux-ide.org) by ietf-mx with esmtp (Exim 4.12) id 1B2LzE-0001o0-00; Sat, 13 Mar 2004 22:08:24 -0500 Received: from localhost (andre@localhost) by master.linux-ide.org (8.11.0/8.11.0/SuSE Linux 8.11.0-0.4) with ESMTP id i2E36iL04072; Sat, 13 Mar 2004 19:06:44 -0800 Date: Sat, 13 Mar 2004 19:06:44 -0800 (PST) From: Andre Hedrick X-Sender: andre@master.linux-ide.org To: AClarke@attotech.com cc: Alan Warwick , ips@ietf.org, ips-admin@ietf.org Subject: Re: [Ips] Reservations, multiple sessions and ISID usage In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: ips-admin@ietf.org Errors-To: ips-admin@ietf.org 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: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60 Aaron, The way to load balance effectively is to execute dispatch without the use of 802.3ad. If the balance is dependent on a network stack and 802.3ad dependency, one generates the single point of failure on the subnet. Each session should have describe a base queue depth after FFP. Doing dynamic load balance was found to be rude to sleeping initiators logged in currently. If a new session(different initiator) completes discovery/login to FFP and there is a resource limitation because of existing allocations, one can not collapse the two windows on a sleeping initiator. Thus to free resources, one has to rudely kick an initiator off and force it to perform session re-instatement. One could grab another chunk of host-memory, but then face the race condition of allocation failures. Just a comment. Cheers, Andre On Sat, 13 Mar 2004 AClarke@attotech.com wrote: > > >How do these rules affect the implementation of SCSI reserve and release > in a load balancing environment where there are >multiple sessions to a > target ? What criteria does the target use to determine that all of the > sessions are from the same initiator >for the purposes of reserve so as to > allow load balancing to occur over the multiple sessions ? > > I think that a the target should not have to detect multiple session > load balancing OS's. I think that this view is in line with the iSCSI > specification (references cited below). > > I do have some related questions and comments > 1. Do other SCSI transport protocol targets detect load balancing OS's > using multiple initiators? > 2. If a target does not detect load balancing then the reserve/release > would be a bottleneck (that resource path would be locked), but multiple > connection sessions solves this problem and is well defined. Other > that lack of target support, why can't multiple connection sessions > be used instead? > > >From Sec. 9.1.2 > The designers of the iSCSI protocol envisioned there being one iSCSI > Initiator Node Name per operating system image on a machine. This > enables SAN resource configuration and authentication schemes based > on a system's identity. It supports the notion that it should be > possible to assign access to storage resources based on "initiator > device" identity. > Sec. 2.1 > - Session: The group of TCP connections that link an initiator with > a target form a session (loosely equivalent to a SCSI I-T nexus). > TCP connections can be added and removed from a session. Across all > connections within a session, an initiator sees one and the same > target. > >From Sec. 9. (my favorite) > The guiding assumption made throughout the design of this protocol > is that targets are resource constrained relative to initiators. > > I would appreciate any comments or corrections. > > Aaron > > > > > _______________________________________________ > Ips mailing list > Ips@ietf.org > https://www1.ietf.org/mailman/listinfo/ips > _______________________________________________ Ips mailing list Ips@ietf.org https://www1.ietf.org/mailman/listinfo/ips From exim@www1.ietf.org Mon Mar 15 14:25:33 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA17996 for ; Mon, 15 Mar 2004 14:25:33 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B2xhx-0003bw-7S for ips-archive@odin.ietf.org; Mon, 15 Mar 2004 14:25:05 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i2FJP5P9013872 for ips-archive@odin.ietf.org; Mon, 15 Mar 2004 14:25:05 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B2xhw-0003be-Qf for ips-web-archive@optimus.ietf.org; Mon, 15 Mar 2004 14:25:04 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA17953 for ; Mon, 15 Mar 2004 14:25:01 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B2xhu-00065A-00 for ips-web-archive@ietf.org; Mon, 15 Mar 2004 14:25:02 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B2xgy-00061s-00 for ips-web-archive@ietf.org; Mon, 15 Mar 2004 14:24:05 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1B2xg3-0005zJ-00 for ips-web-archive@ietf.org; Mon, 15 Mar 2004 14:23:07 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B2xfx-0003OY-Do; Mon, 15 Mar 2004 14:23:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B2xf6-0003Ld-Ow for ips@optimus.ietf.org; Mon, 15 Mar 2004 14:22:08 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA17829 for ; Mon, 15 Mar 2004 14:22:05 -0500 (EST) From: wrstuden@wasabisystems.com Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B2xf4-0005wD-00 for ips@ietf.org; Mon, 15 Mar 2004 14:22:06 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B2xe9-0005tv-00 for ips@ietf.org; Mon, 15 Mar 2004 14:21:10 -0500 Received: from mononoke.wasabisystems.com ([151.199.66.145]) by ietf-mx with esmtp (Exim 4.12) id 1B2xdT-0005rL-00 for ips@ietf.org; Mon, 15 Mar 2004 14:20:27 -0500 Received: by mononoke.wasabisystems.com (Postfix, from userid 1021) id 984CC4015D; Mon, 15 Mar 2004 14:20:20 -0500 (EST) Date: Mon, 15 Mar 2004 11:20:07 -0800 (PST) X-X-Sender: wrstuden@neverwinter.home-net.icnt.net To: Alan Warwick Cc: ips@ietf.org Subject: Re: [Ips] Reservations, multiple sessions and ISID usage In-Reply-To: Message-ID: References: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: ips-admin@ietf.org Errors-To: ips-admin@ietf.org 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: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.3 required=5.0 tests=AWL,NO_REAL_NAME autolearn=no version=2.60 On Fri, 12 Mar 2004, Alan Warwick wrote: > Given this I have a few questions > > > > How do these rules affect the implementation of SCSI reserve and release > in a load balancing environment where there are multiple sessions to a > target ? What criteria does the target use to determine that all of the > sessions are from the same initiator for the purposes of reserve so as > to allow load balancing to occur over the multiple sessions ? Is it > the Initiator name plus ISID, just the initiator name, something else or > it depends ? I would think that just using the initiator name would > make the most sense - what would be the usage scenario for using the > initiator name plus ISID ? As John said, the I_T nexus ID contains both the initiator name and the ISID. The multiple connections per session route he suggested will help here. An alternative is to use Persistent Reservations. My understanding is the Registrants Only reservation types will permit you to also do what you want. You have the different sessions each register with the same registration key, and then have one of them grab a Registrants Only reservation (either write exclusive or exclusive access as needed). > Lets say I have 2 sessions to different portals in different portal > groups and am using the same ISID when the target decides to merge the 2 > portal groups into a single portal group. At this point my initiator is > breaking rule #1 above. How are the targets and initiators supposed to > handle this ? That's not covered in the spec. The target should only be changing the portal group tag of a port at the request of an administrator, so issues such as the one you describe should be avoidable in normal usage. My guess would be that a target should log out the session (or the connections) on the portal that is changing portal group. But that's a guess about behavior that I expect should be vendor-defined. Take care, Bill _______________________________________________ Ips mailing list Ips@ietf.org https://www1.ietf.org/mailman/listinfo/ips From exim@www1.ietf.org Fri Mar 19 14:03:16 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA15788 for ; Fri, 19 Mar 2004 14:03:16 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B4PGY-0006SA-Tn for ips-archive@odin.ietf.org; Fri, 19 Mar 2004 14:02:48 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i2JJ2kRg024805 for ips-archive@odin.ietf.org; Fri, 19 Mar 2004 14:02:46 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B4PGY-0006S0-LC for ips-web-archive@optimus.ietf.org; Fri, 19 Mar 2004 14:02:46 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA15741 for ; Fri, 19 Mar 2004 14:02:44 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B4PGW-0005Nx-00 for ips-web-archive@ietf.org; Fri, 19 Mar 2004 14:02:44 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B4PFT-0005DM-00 for ips-web-archive@ietf.org; Fri, 19 Mar 2004 14:01:41 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1B4PEN-00056A-00 for ips-web-archive@ietf.org; Fri, 19 Mar 2004 14:00:31 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B4PDw-0006Ft-Pb; Fri, 19 Mar 2004 14:00:04 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B4PDJ-0006Eg-AL for ips@optimus.ietf.org; Fri, 19 Mar 2004 13:59:25 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA15578 for ; Fri, 19 Mar 2004 13:59:23 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B4PDH-0004zF-00 for ips@ietf.org; Fri, 19 Mar 2004 13:59:23 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B4PCR-0004uq-00 for ips@ietf.org; Fri, 19 Mar 2004 13:58:33 -0500 Received: from auemail2.lucent.com ([192.11.223.163] helo=auemail2.firewall.lucent.com) by ietf-mx with esmtp (Exim 4.12) id 1B4PC3-0004nH-00 for ips@ietf.org; Fri, 19 Mar 2004 13:58:07 -0500 Received: from nl0006exch001h.wins.lucent.com (h135-85-76-62.lucent.com [135.85.76.62]) by auemail2.firewall.lucent.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id i2JIvWc10546 for ; Fri, 19 Mar 2004 12:57:33 -0600 (CST) Received: by nl0006exch001h.nl.lucent.com with Internet Mail Service (5.5.2657.72) id <1699XPS0>; Fri, 19 Mar 2004 19:57:30 +0100 Message-ID: <7D5D48D2CAA3D84C813F5B154F43B15503DB0C97@nl0006exch001u.nl.lucent.com> From: "Wijnen, Bert (Bert)" To: Keith McCloghrie , bwijnen@lucent.com Cc: ips@ietf.org, mrm@kazeon.com, mankin@psg.com Subject: RE: [Ips] FW: Initial review of http://www.ietf.org/internet-draf ts/draft-i Date: Fri, 19 Mar 2004 19:57:30 +0100 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2657.72) Content-Type: text/plain Sender: ips-admin@ietf.org Errors-To: ips-admin@ietf.org 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: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=AWL autolearn=no version=2.60 Sorry for later response/reaction Comments inline, where I feel I need to add something Thanks, Bert > -----Original Message----- > From: Keith McCloghrie [mailto:kzm@cisco.com] > Sent: vrijdag 6 februari 2004 23:55 > To: bwijnen@lucent.com > Cc: ips@ietf.org; mrm@kazeon.com; mankin@psg.com > Subject: Re: [Ips] FW: Initial review of > http://www.ietf.org/internet-drafts/draft-i > > > Bert/Mike, > > Thanks for the review. > > Below, please find : > > a) my respones to the comments, and > b) the changes that I plan to make as a result of the review. > > Thanks, > Keith. > > > Thanks Mike for the first MIB Doctor review. > > > > authors/wg members, > > Pls copy Mike on any responses, cause I suspect he is not > > subscribed to IPS mailinglist (Mike tell us if you are, > > in which case people do not specifically have to copy you). > > > > Thanks, > > Bert > > > > -----Original Message----- > > From: Michael MacFaden [mailto:mrm@kazeon.com] > > Sent: woensdag 4 februari 2004 7:02 > > To: Wijnen, Bert (Bert) > > Cc: Anurag Maunder > > Subject: Initial review of > > http://www.ietf.org/internet-drafts/draft-ietf-ips-fcmgmt-mib-04.txt > > > > > > Hi Bert, > > > > My review of the fiber channel management MIB module: > > > > http://www.macfaden.com/ietf/fc-mgmt-mib-4-reviewed.txt > > > > Regards, > > Mike > > > > -------------------------------------------------------------- > ---------------- > > > > Feb 3, 2004 MIB DOCTOR Review: > http://www.ietf.org/internet-drafts/draft-ietf-ips-fcmgmt-mib-04.txt > > > > Performed by Michael R. MacFaden, Kazeon Systems, Inc > > according to draft-ietf-ops-mib-review-guidelines-02.txt > > > > A. Documentation Guidelines > > 3.1 o MIB boilerplate section -> present > > current version? -> YES > > o Narrative sections -> present > > Scope described? -> YES > > Spelling? -> No obvious mistakes > > Module structure described? -> YES > > Dependent on other modules? -> YES > > If so, which ones? -> IF-MIB > > Relates to other modules? -> YES > > If so, which ones? -> > HOST-RESOURCES-MIB, ENTITY-MIB, > > References ([XXX])? -> Yes, they are > correct and resolve properly > > > > Reviewer Comments: > > 1. "high performance capability" isn't further > defined so first > > sentence is so much fluff. > > This sentence which appears in the first sentence of the > "Short Intro to > Fibre Channel" section, was copied from the Introduction section of > Fibre Channel standards documents. The intent is to give a high-level > indication of what Fibre Channel is aimed at, and to phrase > it so as to > remain valid in the future as and when the specific bandwidth > supported > by Fibre Channel is higher than it is today. It is too early in the > into to be definitive. Thus, it isn't "fluff". > > > 2. Text describing the MIB module's structure > (Sect 4.1-11) is better than the GROUP DESCRIPTION > > clauses in the compliance section. > > 3. IF-MIB description was superbly done. > > o Definitions section present -> present > > Written to SMIv2 standards? -> YES > > Issues with compilation? -> YES > > o Intellectual Property section -> present > > Matches current boilerplate? -> YES > > Any proprietary rights claimed? -> NO > > o References section -> present > > Matches current boilerplate (2578-80,3410)? -> YES > > Normative/informative sections separate? -> YES > > MIB modules listed in IMPORTS included? -> > > o Security section -> present > > Matches current boilerplate? -> YES > > Specific Read/write objects listed? -> YES > > Security risk spelled out? -> YES > > Specific Read only objects listed? > > > > Reviewer Comments: > > There was only one specific security risk > described. More could be "spelled out." > > For instance, setting fcmSwitchDomainId to an > invalid value could lead to > > denial of service in some configurations. > > No matter how much one writes in this section, it is always true that > "more could be spelled out". > Keith, pls don't read it so litrrally. I guess Mike did see room for improvement. And he in fact gives an example as to what can be improved. > > o IANA Considerations section -> not present > > Was a namespace defined? -> NO > > > > o Copyright Notices section -> present > > Correct year specified? -> NO > > Copyright found in MODULE-IDENTITY? -> NO > > Noted. > and will be fixed I assume? > > o Definitions section detail > > > > Here are the diagnostics from certain mib syntax checkers: > > > > Diagnostics from Version 0.4.2 smilint -l9 > > C:\local\smi\mibs\ietf>smilint -m -s -l 9 ./FC-MGMT-MIB > > ./FC-MGMT-MIB:2213: [5] {group-unref} warning: current > group `fcmLinkBasicGroup' is not referenced in this module > > OK, I will add a GROUP clause to "make it clear that the > optional status is intended". > Thanks > > ./FC-MGMT-MIB:62: [5] {type-without-format} warning: type > `DomainIdOrZero' has no format specification > > ./FC-MGMT-MIB:94: [5] {type-without-format} warning: type > `FcBbCredit' has no format specification > > ./FC-MGMT-MIB:106: [5] {type-without-format} warning: type > `FcDataFieldSize' has no format specification > > ./FC-MGMT-MIB:171: [5] {type-without-format} warning: type > `PhysicalIndexOrZero' has no format specification > > ./FC-MGMT-MIB:181: [5] {type-without-format} warning: type > `HrSWInstalledIndexOrZero' has no format specification > > ./FC-MGMT-MIB:192: [5] {type-without-format} warning: type > `MilliSeconds' has no format specification > > ./FC-MGMT-MIB:198: [5] {type-without-format} warning: type > `MicroSeconds' has no format specification > > It seems to me like the compiler has a bug here, since all of these are, or > have a TC as their syntax and for all but two of them, the TC is defined > with a range, e.g., DomainIdOrZero is defined as: > > DomainIdOrZero ::= TEXTUAL-CONVENTION > STATUS current > DESCRIPTION > "The Domain Id (of a FC switch), or zero if the no Domain Id > has been assigned." > SYNTAX Integer32 (0..239) > > The two exceptions are MilliSeconds and MicroSeconds which are both > Unsigned32 and the inherent (0..4294967295) is correct for both. > I think the warning is cause by the fact that there is no DISPLAY-HINT. Can you add those? > > Diagnostics from MIB Smithy 2.4.2 > > > > > [FC-MGMT-MIB:fcmgmtCompliance:FC-MGMT-MIB:fcmInstanceSoftwareI > ndex] : warning : SYNTAX in variation and OBJECT-TYPE differ > in type names 'Integer32' and 'HrSWInstalledIndexOrZero'. > > > [FC-MGMT-MIB:fcmgmtCompliance:FC-MGMT-MIB:fcmInstancePhysicalI > ndex] : warning : SYNTAX in variation and OBJECT-TYPE differ > in type names 'Integer32' and 'PhysicalIndexOrZero'. > > Yes, but both HrSWInstalledIndexOrZero and PhysicalIndexOrZero are TCs > which have Integer32 as their underlying syntax. > And no change is needed. I think the Smithy should be fixed. > > [FC-MGMT-MIB:fcmLinkEnd2UnitType] : warning : BITS > named-number list values should start at zero. > > [FC-MGMT-MIB:fcmFLoginClassesAgreed] : warning : BITS > named-number list values should start at zero. > > Another bug in the compiler. Both objects have a TC as their syntax where > the TC has a named-number list which does start at zero. > Agreed > > [FC-MGMT-MIB:fcmISPortEntry] : warning : All INDEX objects > in this table are auxiliary (i.e., from other tables). > > [FC-MGMT-MIB:fcmFxPortEntry] : warning : All INDEX objects > in this table are auxiliary (i.e., from other tables). > > Eh? The compiler has another bug, since: > > a) auxiliary does NOT mean "i.e., from other tables", rather RFC 2758 > section 7.7 defines "auxiliary" as follows: > > Objects which are both specified in the INDEX clause of a conceptual > row and also columnar objects of the same conceptual row are termed > auxiliary objects. > > Thus, the error message as stated is actually wrong. > I believe so too > b) It is common practice for media-specific MIBs which extend the > IF-MIB to define a table which is INDEX-ed only by ifIndex. > Agreed and no issue I think > > > [FC-MGMT-MIB:fcmPortFcOperClass] : warning : BITS > named-number list values should start at zero. > > [FC-MGMT-MIB:fcmPortFcCapClass] : warning : BITS > named-number list values should start at zero. > > [FC-MGMT-MIB:fcmPortEntry] : warning : All INDEX objects in > this table are auxiliary (i.e., from other tables). > > [FC-MGMT-MIB:fcmInstanceFunctions] : warning : BITS > named-number list values should start at zero. > > Validation complete - 0 error(s), 10 warning(s) > > See above. > > > Reviewer Comments: > > 1. The TC's could possibly go into a separate TC > document for fiber channel: FcNameIdOrZero, DomainIdOrZero, > FcAddressId > > as it is mentioned there might be multiple Fiber > channel mib modules in the future. > > While your "could" and "possibly" are correct, but we have already > written several of these follow-on FC MIB modules, and they are > IMPORT-ing TCs from this MIB without any problems. So, this > would be a disruptive change for no benefit. > Keith, but the current spec locks all other MIB modules to this one. I.e. the otehrs cannot advance unless this one also advances. If you put TCs in a separate module then you do not have that issue. Now it can still be changed (rather easily), later it becomes more difficult. But it is not a MUST change > > 2. FcAddressId doesn't have an *OrZero version, which > might be needed at a later date. > > It's syntax is "OCTET STRING (SIZE(0 | 3))" and the zero-length value > is already used (see fcmLinkEnd2FcAddressId). > You migth want to add text to the DESCRITPION clause that explains the special meaning of zero. I think what Mike noticed is an inconsistency, because some of your other TCs do have an xxxOrZero. Consistency is (I think ) a good thing. But a again not a MUST change. > > 3. FcPortType enumeration "dynamic(3), -- determined > dynamically" seems redundant, prefer comment point to underlying spec > > No, it's not redundant because "dynamic" could also mean that > the value > is constantly changing, and saying "determined dynamically" > removes that possibility. > You might want to enhance the description somewhat then. And as Mike says, a ptr to the spec might be helpful too > > 4. PhysicalIndexOrZero, HrSWInstalledIndexOrZero are > > very useful and generally applicable to many mib modules. > > They look strangly wrong being defined here and > > should be defined in another TC, like Entity-MIB, or some > > common TC-MIB. > > But they aren't, and thus, the best that this MIB module can do is to > define the TC's itself. > Could you rename them to RcPhysicalIndexOrZero and FcHrSWInstalledIndexOrZero so that they will not conflict if Entity MIB does define them later. But... SURPRISE (maybe), pls take a look at draft-ietf-entmib-v3-04.txt and is on my AD plate for review!! So at least that one can be imported from ENTITY-MIB. > > 5. MicroSeconds, MilliSeconds should also be in some > generic tc-mib... > > But they aren't, and thus, the best that this MIB module can do is to > define the TC's itself. > Well, the SSPM-MIB (draft-ietf-rmonmib-sspm-mib-11.txt) which is in IETF Last Call DOES have a SspmMicroSeconds TC. I made them prefix with Sspm.. because I do foresee a future generic TC MIB for these things. So if you want to keep them in this MIB module I strongly recommend to name it FcMicroSeconds and FcMilliSeconds. > > 6. fcmInstanceIndex DESCRIPTION is problematic for me. > Either it stays static or it doesn't. > > Having something "desireable" is worthless to those > writing mangement applications, they have to assume worst case always. > > Not worthless, because if agent implementors heed the advice, > then mgmt > apps can coded to check whether the index values have been retained > over the last restart, and only if not, do they need to re-synchronize > their database. That is, it is an optimization for the common case of > index values being retained, but the fallback still works in the case > (hopefully less common) when all knowledge of index values is lost. > So would it make sense to phrase it with a SHOULD ?? > > There are problems with the description. Sentences > start without capitalization. > > "Sentences" ?? I see only one such sentence-break, for which the fix > is to delete the the period before "but" (because it's bad grammar to > start a sentence with "But".) > > > fcmInstanceTable has very critical data. Would like > to have a LastChange entry per row to know when values were changed or > > a "configuration change" notification if lastChange > object is too much overhead. > > But the data is not, in general, both critial and dynamic. > Specifically, > the only things in this table that change are: > - the FabricId if it's based on the WWN of the Principal switch; > -- a notification of a Principal switch change is being > proposed as > an extension to this MIB. > - the read-write objects (but only when an app changes them); > -- changes in these values are not critical to the > operation of the > network, and the synchronization of mgmt apps should > not have to > rely on notifications from agents for such non-critical data. > - the Status object, > -- to monitor this object for changes, set an RMON > threshold on it. > Note that the typical situation is to have just one instance; > even if there are multiple instances, there will not be many. > Having an RMON threshold will be more effective than having a > LastChange object. > > > 7. fcmInstanceWwn, but does it matter which WWN is > selected? Will managment stations expect one vendor > implemetnation over another? > > The ability to have multiple instances is defined as a flexibility to > allow for many/any different choices by vendors. Vendors are free to > choose to have one, or more, instances using whatever > methodology they wish. > Thus, we cannot prescribe how the WWN is selected. > > This flexibility is necessary because otherwise there is a > genuine risk > that a vendor will implement a set of Fibre Channel > interfaces in a manner > which cannot be represented by this MIB. > > > Wouldn't it be the same as fcmSwitchDomainId if > fcmSwitchPrincipal is True? > > It could be but it needn't be, and the circumstance you ask about is a > corner case which for example never applies to HBAs. > > > 8. fcmInstanceStatus could use an associated object to > get timestamp of the last state change > > While implementation feedback might tell us that, I think it's too > soon to be sure. So, let's save this comment until we update > the MIB from > Proposed to Draft Standard. > > > 9. fcmInstanceStatus doesn't seem to be implementable in > a consistent way across vendors. Needs better definition > > ideally this state is defined in the underlying > technology specifications. > > On the contrary, a) there is no one underlying technology, and b) the > underlying technology specifications are the subject of future MIBs, > not this one. This object serves as a generic summary of the > underlying > specifics (e.g., somewhat like ifOperStatus does for an interface.) > > > 10. fcmInstanceTextName/fcmInstanceDescr, are there any > DEFAULT values for these? Suspect vendor implementations will > > provide something. Better to define the intended > purpose of these objects better. > > "A textual name for this management instance > and the Fibre > > Channel entity/entities that it is managing." > > might be > > "A textual name for this management instance > and the Fibre > > Channel entity/entities that it is managing set > by the operator or to a default string "XXXX" by the device." > > "XXXX" can not be specified in this MIB without restricting > the necessary > flexibility, anything that could be specified in this MIB would not be > specific enough. The whole idea of this object is to be the > name specified > by the operator/NM-app, to have a default value changes the semantics. > > > 11. fcmPortAdminType - Assuming a valid value change > can't be done for some device resource specific case, how can > > the error be reported? A generic > snmp error to the set is necessary but not sufficient I think. > > Why would it not be sufficient ?? > cause genErr is also used for other (unspecified) errors. Maybe this could be spelled out that the best would be to sent an inconsistentValue error? > > 12. Not sure why these object's syntax wasn't a TC? They > will probably be added to in time as well. > > fcmPortCapProtocols > > fcmPortTransmitterType > > fcmPortConnectorType -- this should probably > follow the MAU-MIB convention or we need to standardize 'JackType' > > in a new TC mib as > there is now overlap... > > Actually, not for the latter two because they are not generic > definitions. > Rather they are the specific enumerations listed for the function in > T11's GS-3 speciofication. Sicne a future revision of the GS-3 spec > could revise them individually, they cannot be defined as common TCs. > The first one could, but I don't see any rule that it violates which > would justify a change at this time. > A change is justified as much as no change. My personal opinion. Is it a MSUT change? no it is not. > > 13. fcmPortStatsTable doesn't have an explicitly > specified discontinuity object -- is ifXTable entry the one > that applies? > > Yes. > Then you want to state that in DESCRIPTION clause(s) > > Also, the counters described here should > have REFERNCE clauses to counters defined in the underlying > technology > > specs. While the descriptions are generally > good, they do not cover all possible cases when > > one should be incremented or not -- that > leads to incompatible implementations. > > Many of them are not specifically defined in any Fibre Channel > specification. If any are ambiguous, please suggest alternative > wording. Otherwise, I suggest we wait for implementation feedback. > > > 14. fcmPortLcStatsTable doesn't have split counters? Is > a SNMPv1 agent then really useful when running high speed interfaces? > > No, but at the time (several years ago now) when this was discussed > in the WG, many Storage vendors only had SNMPv1 agents, and as a > result, this table was defined at the explicit direction of the WG. > I.e. to force them to SNMPv3? FIne by me! > > DESCRIPTION > > "A list of Counter32-based statistics which are > a shadow of > > the Counter64 statistics in the fcmPortStatsTable, for > > systems which do not support Counter64." > > I suggest the text mention it should "shadow" the > lower 32 bits? > > If that isn't what "shadow" means, then I don't know what it > does mean, and we shouldn't use the term at all. > I prefer if you spell out they contain the low order 32 bits. > > 15. If errors are not so common an occurance across > instances, the fcmPortErrorsTable might benefit from a > *LastChange object > > so not all objects have to be polled to determine > any error state change. Alternately provide a summary counter that > > is a simple sum of the number of errors. That should > allow for better scaling of this table for mgmt polling using > SNMP/UDP. > > The summary counter for many of these is already available: > ifInErrors. > > > 16. Error table should have REFERENCE clauses to point > out where in the underlying spec these counters are defined. > > This appears to be done, but is inconsistent. > fcmPortLinkFailures has a REFERENCE but fcmPortLinkResets wasn't? > > As I recall, it is consistent; specifically, all those for which > there is an appropriate section to reference have a REFERENCE clause. > > > 17. fcmFxPortTable needs a discontinutity object. if > fcmPortOperType is changed from Fx to some other then back within > > a given polling interval, the data collected from > this table will be incorrect. > > No, because there are no Counter-based objects in this table. > > > 18. Objects in fcmFxPortTable, fcmFLoginTable could use > REFERENCE clauses. > > Sigh !! I will look again to see what I can find. > > > 19. fcmFLoginNxPortIndex doesn't specify what behaviors > should be across SNMP agent reset or system reboots like > > fcmInstanceIndex is required to do. So I'm a bit > concerned what the indexing looks like for all the tables on > > system reset or agent reset. > > I will add a sentence saying that after a value of > fcmFLoginNxPortIndex > is assigned to a particular Nx_Port, it can be re-used when and only > when it is assigned to the same Nx_Port, or, after a reset of > the value > of the relevant instance of ifCounterDiscontinuityTime. > > > 20. fcmLinkEnd2AgentAddress OBJECT-TYPE is SYNTAX > SnmpAdminString, not InetAddressType? Why? > > Because the value is received from the otrher end of the > link, and if the > other end supplies a bogus value,m then that bpgus value > needs to be stored > in the MIB. > So in that case it can be stored with InetAddressType "unknown" and the value that you received in the InetAddress, no? So I do not see a reason to NOT use InetAddress(Type) combo. > > 21. > > > > End of Report > > An additional remark from me: I strongly recommend to rename DomainIdOrZero to FcDomainIdOrZero. The current definition of the TC is certainly not a generic DomainId definition is it? Bert > > -------------------------------------------------------------- > ---------------- > > > - fix the Copyright dates, and insert a Copyright statement in > the MODULE-IDENTITY. > > - add > GROUP fcmLinkBasicGroup > DESCRIPTION > "This group is optional." > > - delete the period in "... across restarts. (but note, it is ..." > > - add an explicit statement that discontinuities in the counters in > the fcmPortStatsTable can only occur when the value of the relevant > isntance of ifCounterDiscontinuityTime is zero. > > - look again to see what references I can find to put in > REFERENCE clauses > of objects in fcmFxPortTable, fcmFLoginTable. > > - add a sentence saying that after a value of fcmFLoginNxPortIndex > is assigned to a particular Nx_Port, it can be re-used when and only > when it is assigned to the same Nx_Port, or, after a reset > of the value > of the relevant instance of ifCounterDiscontinuityTime. > _______________________________________________ Ips mailing list Ips@ietf.org https://www1.ietf.org/mailman/listinfo/ips From exim@www1.ietf.org Mon Mar 22 14:27:06 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA14042 for ; Mon, 22 Mar 2004 14:27:06 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B5V4I-00062f-BP for ips-archive@odin.ietf.org; Mon, 22 Mar 2004 14:26:38 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i2MJQc8x023219 for ips-archive@odin.ietf.org; Mon, 22 Mar 2004 14:26:38 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B5V4I-00062Q-6p for ips-web-archive@optimus.ietf.org; Mon, 22 Mar 2004 14:26:38 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA14032 for ; Mon, 22 Mar 2004 14:26:35 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B5V4F-0006uy-00 for ips-web-archive@ietf.org; Mon, 22 Mar 2004 14:26:35 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B5V3H-0006oE-00 for ips-web-archive@ietf.org; Mon, 22 Mar 2004 14:25:36 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1B5V2N-0006hW-00 for ips-web-archive@ietf.org; Mon, 22 Mar 2004 14:24:39 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B5V18-0005qF-7D; Mon, 22 Mar 2004 14:23:22 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B5V0P-0005pC-59 for ips@optimus.ietf.org; Mon, 22 Mar 2004 14:22:37 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA13936 for ; Mon, 22 Mar 2004 14:22:34 -0500 (EST) From: Black_David@emc.com Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B5V0M-0006VV-00 for ips@ietf.org; Mon, 22 Mar 2004 14:22:34 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B5UzQ-0006P7-00 for ips@ietf.org; Mon, 22 Mar 2004 14:21:36 -0500 Received: from mxic2.corp.emc.com ([128.221.12.9]) by ietf-mx with esmtp (Exim 4.12) id 1B5UyU-0006Cm-00 for ips@ietf.org; Mon, 22 Mar 2004 14:20:38 -0500 Received: by mxic2.corp.emc.com with Internet Mail Service (5.5.2653.19) id ; Mon, 22 Mar 2004 14:19:54 -0500 Message-ID: To: ips@ietf.org Date: Mon, 22 Mar 2004 14:19:53 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain Subject: [Ips] March 2004 Status of Drafts Sender: ips-admin@ietf.org Errors-To: ips-admin@ietf.org 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: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.3 required=5.0 tests=AWL,NO_REAL_NAME autolearn=no version=2.60 This is what the WG chairs believe to be the current status of drafts in the IP Storage (ips) Working Group. Let us know if there are any questions or errors. Thanks, --David (for David and Elizabeth, IPS WG co-chairs) IETF IP Storage (ips) Working Group WG Internet-Draft Status: March 2004 ------------------------------------ Summary: 22 drafts total: - 3 have been published as RFCs. - 6 have been approved for RFC publication by the IESG and are in the RFC Editor Queue awaiting approval of drafts they depend on and/or editing. The RFC Editor is close to publishing some of these drafts. - 4 are awaiting further AD/IESG action, mostly after revisions to respond to IESG issues. - 5 MIBs have completed WG Last Call with all technical issues resolved and are in Expert Review at the IESG. - 1 MIB completed Expert Review and needs to be revised to respond to the Expert Review Comments. - 1 (plus a related DHC WG draft) needs IPS WG chair attention to resolve technical issues that have arisen during AD/IESG review. Expect email to the list on the IPS draft (iscsi-slp) shortly. The DHC WG draft will take longer to get to. - 2 have completed WG Last Call, but require revisions before being submitted to the ADs/IESG. 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-19.txt To be a proposed standard RFC. Approved by the IESG for RFC publication, in RFC Editor Queue. -- iSCSI draft-ietf-ips-iscsi-20.txt draft-ietf-ips-iscsi-20.pdf To become a proposed standard RFC. Approved by the IESG for RFC publication, in RFC Editor Queue. draft-ietf-ips-iscsi-boot-12.txt To become a proposed standard RFC. Completed WG Last Call and submitted to the ADs/IESG. Has been revised to respond to IESG comments and is about to be sent back to the ADs for further IESG action. draft-ietf-ips-iscsi-reqmts-06.txt has been published as Informational RFC 3347. draft-ietf-ips-iscsi-name-disc-10.txt To become an informational RFC. Approved by the IESG for RFC publication, in RFC Editor Queue. draft-ietf-ips-iscsi-slp-06.txt To become a proposed standard RFC. Updated version has corrected nits and addressed relevant expert review comments from FCIP SLP draft. Still has an iSNS-related issue that needs to be sorted out. WG chairs will get to this shortly. draft-ietf-ips-iscsi-string-prep-06.txt To become a proposed standard RFC. Approved by the IESG for RFC publication, in RFC Editor Queue. draft-ietf-ips-iscsi-mib-09.txt To be a proposed standard RFC. Has completed WG Last Call, and been submitted to ADs/IESG. Currently in Expert Review. draft-ietf-ips-auth-mib-05.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 and been submitted to ADs/IESG. Currently in Expert Review. draft-sheinwald-iscsi-crc-01.txt has been published as Informational RFC 3385. This was not a working group draft, but records information that the WG found very useful in designing CRC functionality for iSCSI. draft-ietf-ips-iscsi-name-ext-02.txt To become a Proposed Standard RFC. Has passed WG Last Call, but needs a revision to cross-protocol consistency rationale before being submitted to ADs/IESG. draft-ietf-ips-command-ordering-02.txt To become an Informational RFC. Has passed WG Last Call and been submitted to ADs/IESG. -- FC Common Encapsulation draft-ietf-ips-fcencapsulation-09.txt draft-ietf-ips-fcencapsulation-09.pdf Published as Proposed Standard RFC 3643 -- FCIP draft-ietf-ips-fcovertcpip-12.txt draft-ietf-ips-fcovertcpip-12.pdf To be a proposed standard RFC. Approved by IESG for RFC publication, in RFC Editor Queue. draft-ietf-ips-fcip-slp-09.txt To be a proposed standard RFC. Revised version has dealt with expert review comments and nits, and is awaiting further AD action. It should go to IETF Last Call. draft-ietf-ips-fcip-mib-05.txt To be a proposed standard RFC. Has been submitted to the ADs/IESG. Currently in Expert Review. -- iFCP draft-ietf-ips-ifcp-14.txt draft-ietf-ips-ifcp-14.pdf To be a proposed standard RFC. Approved by IESG for RFC publication, in RFC Editor Queue. draft-ietf-ips-ifcp-mib-05.txt To be a proposed standard RFC. Has completed WG Last Call, and resulting editorial updates have been applied. Has been submitted to the ADs/IESG. Currently in Expert Review. -- iSNS draft-ietf-ips-isns-22.txt To be a proposed standard RFC. Has completed WG Last Call, and been forwarded to ADs/IESG. With luck, -22 contains the last set of changes required to respond to IESG coments. Awaiting further AD action. The related draft-ietf-dhc-isnsoption-11.txt requests allocation of a DHC option code for iSNS, and has completed a joint IPS WG/ DHC WG last call. Draft is currently blocked on an IESG security issue that the draft authors are not able to resolve. One of the IPS WG chairs will try to write new security text for this draft in the near future. draft-ietf-ips-isns-mib-05.txt To be a proposed standard RFC. Has completed WG Last Call. Still needs revision to respond to WG's MIB Expert comments. Draft has not been revised recently, and has been removed from Internet-Draft servers for this reason; the new version will be -06. -- SCSI MIB draft-ietf-ips-scsi-mib-06.txt To be a proposed standard RFC. Has completed WG Last Call been revised to address issues found by the WG's MIB expert. Has been forwarded to ADs/IESG. Currently in Expert Review. -- Fibre Channel Management MIB draft-ietf-ips-fcmgmt-mib-04.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 and has been forwarded to ADs/IESG. Expert review comments have been received - a revised version will be prepared to respond to them. _______________________________________________ Ips mailing list Ips@ietf.org https://www1.ietf.org/mailman/listinfo/ips From exim@www1.ietf.org Mon Mar 22 14:49:25 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA15265 for ; Mon, 22 Mar 2004 14:49:25 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B5VPt-0000Ib-JN for ips-archive@odin.ietf.org; Mon, 22 Mar 2004 14:48:58 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i2MJmpiH001143 for ips-archive@odin.ietf.org; Mon, 22 Mar 2004 14:48:51 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B5VPe-00009P-F8 for ips-web-archive@optimus.ietf.org; Mon, 22 Mar 2004 14:48:42 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA15235 for ; Mon, 22 Mar 2004 14:48:38 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B5VPa-0001TM-00 for ips-web-archive@ietf.org; Mon, 22 Mar 2004 14:48:38 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B5VOk-0001OQ-00 for ips-web-archive@ietf.org; Mon, 22 Mar 2004 14:47:46 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1B5VO6-0001In-00 for ips-web-archive@ietf.org; Mon, 22 Mar 2004 14:47:06 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B5VO1-0008FM-FI; Mon, 22 Mar 2004 14:47:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B5VNk-0008E7-8s for ips@optimus.ietf.org; Mon, 22 Mar 2004 14:46:44 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA15145 for ; Mon, 22 Mar 2004 14:46:41 -0500 (EST) From: Black_David@emc.com Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B5VNh-0001HJ-00 for ips@ietf.org; Mon, 22 Mar 2004 14:46:41 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B5VMl-0001BV-00 for ips@ietf.org; Mon, 22 Mar 2004 14:45:44 -0500 Received: from mxic2.corp.emc.com ([128.221.12.9]) by ietf-mx with esmtp (Exim 4.12) id 1B5VM4-0000y8-00 for ips@ietf.org; Mon, 22 Mar 2004 14:45:00 -0500 Received: by mxic2.corp.emc.com with Internet Mail Service (5.5.2653.19) id ; Mon, 22 Mar 2004 14:44:29 -0500 Message-ID: To: ips@ietf.org Cc: Black_David@emc.com Date: Mon, 22 Mar 2004 14:44:28 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain Subject: [Ips] iSCSI SLP draft status Sender: ips-admin@ietf.org Errors-To: ips-admin@ietf.org 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: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.3 required=5.0 tests=AWL,NO_REAL_NAME autolearn=no version=2.60 In the status of drafts email that I just sent, the status of this draft was indicated as: draft-ietf-ips-iscsi-slp-06.txt To become a proposed standard RFC. Updated version has corrected nits and addressed relevant expert review comments from FCIP SLP draft. Still has an iSNS-related issue that needs to be sorted out. WG chairs will get to this shortly. So, here's one of your WG chairs picking up that cue ... between Josh (>>) and Bill (>), we have the following: > > I would agree, and would request that the iSCSI-SLP draft author (Mark > > Bakke, you still there?) to incorporate a precedence attribute into the > > sms template. > > That's now two outstanding requests against the iSCSI-SLP draft. The other > (repeated for clarity) is that we add a transport attribute for iSNS > servers so that a client knows if it should use tcp or udp to > reach the server. > > I second Josh's request that we make these changes. :-) > > Elizabeth & David, where do we stand on this draft? The draft needs to be modified so that it works properly with iSNS, as we've described iSNS as being discoverable via SLP for a long time. The draft is currently being held (Revised Draft Needed state in the draft tracker) so that it can be suitably modified. In order to move forward here, I need someone to propose specific text additions and/or changes to resolve the above two issues - send the proposed additions and/or changes to the list. Thanks, --David ---------------------------------------------------- David L. Black, Senior Technologist EMC Corporation, 176 South St., Hopkinton, MA 01748 +1 (508) 293-7953 FAX: +1 (508) 293-7786 black_david@emc.com Mobile: +1 (978) 394-7754 ---------------------------------------------------- _______________________________________________ Ips mailing list Ips@ietf.org https://www1.ietf.org/mailman/listinfo/ips From exim@www1.ietf.org Mon Mar 22 17:57:41 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA00927 for ; Mon, 22 Mar 2004 17:57:41 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B5YM6-0002zN-It for ips-archive@odin.ietf.org; Mon, 22 Mar 2004 17:57:14 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i2MMvEfq011483 for ips-archive@odin.ietf.org; Mon, 22 Mar 2004 17:57:14 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B5YM6-0002z1-BA for ips-web-archive@optimus.ietf.org; Mon, 22 Mar 2004 17:57:14 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA00835 for ; Mon, 22 Mar 2004 17:57:10 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B5YM3-0003uo-00 for ips-web-archive@ietf.org; Mon, 22 Mar 2004 17:57:11 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B5YL6-0003ih-00 for ips-web-archive@ietf.org; Mon, 22 Mar 2004 17:56:13 -0500 Received: from [65.246.255.50] (helo=mx2.foretec.com) by ietf-mx with esmtp (Exim 4.12) id 1B5YJw-0003Xk-01 for ips-web-archive@ietf.org; Mon, 22 Mar 2004 17:55:00 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by mx2.foretec.com with esmtp (Exim 4.24) id 1B5YDB-0002Ao-KH for ips-web-archive@ietf.org; Mon, 22 Mar 2004 17:48:01 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B5YDB-0002GB-FV; Mon, 22 Mar 2004 17:48:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B5YCw-0002Ff-2i for ips@optimus.ietf.org; Mon, 22 Mar 2004 17:47:46 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA00281 for ; Mon, 22 Mar 2004 17:47:42 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B5YCt-0002kx-00 for ips@ietf.org; Mon, 22 Mar 2004 17:47:43 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B5YBs-0002ey-00 for ips@ietf.org; Mon, 22 Mar 2004 17:46:41 -0500 Received: from rtp-iport-1.cisco.com ([64.102.122.148]) by ietf-mx with esmtp (Exim 4.12) id 1B5YB1-0002Ul-00 for ips@ietf.org; Mon, 22 Mar 2004 17:45:47 -0500 Received: from rtp-core-1.cisco.com (64.102.124.12) by rtp-iport-1.cisco.com with ESMTP; 22 Mar 2004 14:52:39 -0800 X-BrightmailFiltered: true Received: from cisco.com (mbakke-lnx2.cisco.com [64.101.211.59]) by rtp-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id i2MMjEU7000850; Mon, 22 Mar 2004 17:45:14 -0500 (EST) Message-ID: <405F6C7A.9080502@cisco.com> Date: Mon, 22 Mar 2004 16:45:14 -0600 From: Mark Bakke User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.4) Gecko/20030624 Netscape/7.1 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Black_David@emc.com CC: ips@ietf.org Subject: Re: [Ips] iSCSI SLP draft status References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: ips-admin@ietf.org Errors-To: ips-admin@ietf.org 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: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit I'm still here, and I owe the team some security section changes to match those done for the FCIP-SLP draft. I'll generate some text. -- Mark Black_David@emc.com wrote: >In the status of drafts email that I just sent, the status of this >draft was indicated as: > >draft-ietf-ips-iscsi-slp-06.txt > To become a proposed standard RFC. Updated version has corrected >nits > and addressed relevant expert review comments from FCIP SLP draft. > Still has an iSNS-related issue that needs to be sorted out. WG > chairs will get to this shortly. > >So, here's one of your WG chairs picking up that cue ... between >Josh (>>) and Bill (>), we have the following: > > > >>>I would agree, and would request that the iSCSI-SLP draft author (Mark >>>Bakke, you still there?) to incorporate a precedence attribute into the >>>sms template. >>> >>> >>That's now two outstanding requests against the iSCSI-SLP draft. The other >>(repeated for clarity) is that we add a transport attribute for iSNS >>servers so that a client knows if it should use tcp or udp to >>reach the server. >> >>I second Josh's request that we make these changes. :-) >> >>Elizabeth & David, where do we stand on this draft? >> >> > >The draft needs to be modified so that it works properly with iSNS, as >we've described iSNS as being discoverable via SLP for a long time. >The draft is currently being held (Revised Draft Needed state in the >draft tracker) so that it can be suitably modified. In order to move >forward here, I need someone to propose specific text additions >and/or changes to resolve the above two issues - send the proposed >additions and/or changes to the list. > >Thanks, >--David >---------------------------------------------------- >David L. Black, Senior Technologist >EMC Corporation, 176 South St., Hopkinton, MA 01748 >+1 (508) 293-7953 FAX: +1 (508) 293-7786 >black_david@emc.com Mobile: +1 (978) 394-7754 >---------------------------------------------------- > >_______________________________________________ >Ips mailing list >Ips@ietf.org >https://www1.ietf.org/mailman/listinfo/ips > > > > _______________________________________________ Ips mailing list Ips@ietf.org https://www1.ietf.org/mailman/listinfo/ips From exim@www1.ietf.org Mon Mar 22 17:57:55 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA00971 for ; Mon, 22 Mar 2004 17:57:55 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B5YMK-000356-S3 for ips-archive@odin.ietf.org; Mon, 22 Mar 2004 17:57:28 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i2MMvSjp011833 for ips-archive@odin.ietf.org; Mon, 22 Mar 2004 17:57:28 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B5YMK-00034l-Na for ips-web-archive@optimus.ietf.org; Mon, 22 Mar 2004 17:57:28 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA00864 for ; Mon, 22 Mar 2004 17:57:24 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B5YMI-0003wi-00 for ips-web-archive@ietf.org; Mon, 22 Mar 2004 17:57:26 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B5YLQ-0003la-00 for ips-web-archive@ietf.org; Mon, 22 Mar 2004 17:56:33 -0500 Received: from [65.246.255.50] (helo=mx2.foretec.com) by ietf-mx with esmtp (Exim 4.12) id 1B5YK0-0003Xk-03 for ips-web-archive@ietf.org; Mon, 22 Mar 2004 17:55:04 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by mx2.foretec.com with esmtp (Exim 4.24) id 1B5Y75-0001zz-Fe for ips-web-archive@ietf.org; Mon, 22 Mar 2004 17:41:43 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B5Y71-0001GK-CQ; Mon, 22 Mar 2004 17:41:39 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B5Y5K-0001B7-3Q for ips@optimus.ietf.org; Mon, 22 Mar 2004 17:39:54 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA00055 for ; Mon, 22 Mar 2004 17:39:50 -0500 (EST) From: Black_David@emc.com Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B5Y5H-00022o-00 for ips@ietf.org; Mon, 22 Mar 2004 17:39:51 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B5Y4b-0001wl-00 for ips@ietf.org; Mon, 22 Mar 2004 17:39:09 -0500 Received: from mxic2.corp.emc.com ([128.221.12.9]) by ietf-mx with esmtp (Exim 4.12) id 1B5Y43-0001pg-00 for ips@ietf.org; Mon, 22 Mar 2004 17:38:35 -0500 Received: by mxic2.corp.emc.com with Internet Mail Service (5.5.2653.19) id ; Mon, 22 Mar 2004 17:38:03 -0500 Message-ID: To: ips@ietf.org Subject: RE: [Ips] March 2004 Status of Drafts Date: Mon, 22 Mar 2004 17:36:47 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain Sender: ips-admin@ietf.org Errors-To: ips-admin@ietf.org 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: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.3 required=5.0 tests=AWL,NO_REAL_NAME autolearn=no version=2.60 I thought this answer to a private inquiry would be of general interest. > Is there any way you could add to this some estimates of time to > publication, for those things in the RFC Editor queue? For example, > iSCSI has been there for a long time now, and I'm sure lots of people > would like to know how much longer. The biggest delay with iSCSI has been clearing dependencies - they're all cleared now and the WG chairs are starting to see authors' 48 hour notices on some of the drafts that have to be published with iSCSI, so iSCSI shouldn't be too much longer now. Beyond that, I don't know how to estimate time for a draft to remain in the RFC Editor queue. > Alternatively or additionally, for things in the queue, are they > waiting for dependencies? I think iSCSI was for a while (the crypto > stuff) -- is it still? Has there been *any* progress? Yes, all dependencies have been cleared for iSCSI. The principle remaining dependencies are that FCIP depends on FCIP-SLP, and iFCP depends on iSNS - both FCIP-SLP and iSNS are on the AD's plate headed back to the IESG. Thanks, --David ---------------------------------------------------- David L. Black, Senior Technologist EMC Corporation, 176 South St., Hopkinton, MA 01748 +1 (508) 293-7953 FAX: +1 (508) 293-7786 black_david@emc.com Mobile: +1 (978) 394-7754 ---------------------------------------------------- _______________________________________________ Ips mailing list Ips@ietf.org https://www1.ietf.org/mailman/listinfo/ips From exim@www1.ietf.org Mon Mar 22 19:00:19 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA05039 for ; Mon, 22 Mar 2004 19:00:19 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B5ZKj-00064h-Et for ips-archive@odin.ietf.org; Mon, 22 Mar 2004 18:59:53 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i2MNxrZZ023351 for ips-archive@odin.ietf.org; Mon, 22 Mar 2004 18:59:53 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B5ZKj-00064W-3E for ips-web-archive@optimus.ietf.org; Mon, 22 Mar 2004 18:59:53 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA05015 for ; Mon, 22 Mar 2004 18:59:48 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B5ZKg-00033g-00 for ips-web-archive@ietf.org; Mon, 22 Mar 2004 18:59:50 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B5ZJo-0002yH-00 for ips-web-archive@ietf.org; Mon, 22 Mar 2004 18:58:56 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1B5ZJ3-0002sK-00 for ips-web-archive@ietf.org; Mon, 22 Mar 2004 18:58:09 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B5ZIv-0005uS-3A; Mon, 22 Mar 2004 18:58:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B5ZIr-0005u4-0S for ips@optimus.ietf.org; Mon, 22 Mar 2004 18:57:57 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA04961 for ; Mon, 22 Mar 2004 18:57:52 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B5ZIn-0002rD-00 for ips@ietf.org; Mon, 22 Mar 2004 18:57:53 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B5ZHu-0002lW-00 for ips@ietf.org; Mon, 22 Mar 2004 18:56:59 -0500 Received: from f112.brocade.com ([66.243.153.112] helo=blasphemy.brocade.com) by ietf-mx with esmtp (Exim 4.12) id 1B5ZHN-0002dN-00 for ips@ietf.org; Mon, 22 Mar 2004 18:56:25 -0500 Received: from hq-ex-4.corp.brocade.com (hq-ex-4 [192.168.38.93]) by blasphemy.brocade.com (Postfix) with ESMTP id 703611415B; Mon, 22 Mar 2004 15:55:42 -0800 (PST) X-MimeOLE: Produced By Microsoft Exchange V6.0.6487.1 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Date: Mon, 22 Mar 2004 15:55:41 -0800 Message-ID: Thread-Topic: usage and validation of iSCSI Name Source Attribute in iSNS registrations? Thread-Index: AcQQaS7ClFpzGmjfT1azymlDF2v8KQ== From: "Danny Mitzel" To: Cc: Content-Transfer-Encoding: quoted-printable Subject: [Ips] usage and validation of iSCSI Name Source Attribute in iSNS registrations? Sender: ips-admin@ietf.org Errors-To: ips-admin@ietf.org 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: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60 Content-Transfer-Encoding: quoted-printable Content-Transfer-Encoding: quoted-printable I'm trying to understand the usage and validation of the iSCSI Name Source Attribute in iSNS registrations (DevAttrReg). I've been studying the iSNS-I-D-22.txt and playing a bit with Microsoft freebie iSNS server and generating some iSNS PDU. the latest MS iSNS server claims to 'Added Source Attribute based checks and restrictions', which has = increased my frustration as I get rejected registrations 'Source Unauthorized = (code=3D8)'. I'm hoping you all can help clarify a few simple registration scenario = to help me master iSNS operation. scenario #1: initial Network Entity / Storage Node registration this is a chicken-and-egg case. on the initial Network Entity and Storage Node registration there's no existing iSCSI Name to validate. from the Appendix A examples and my experimentation appears I just plug in the iSCSI Name of the Storage Node being registered? scenario #2: adding a Storage Node to an existing Network Entity lets say I already did a registration as in scenario #1 above (Network Entity=3D"jbod1.example.com", iSCSI Name=3D"NAMEabcd"). now I bring another iSCSI target online (iSCSI Name=3D"NAMEefgh"). to = register=20 this can I specify iSCSI Name Source Attribute=3D"NAMEefgh" similar to how I specified the Storage Node being registered in scenario #1? or do I need to give the already existing NAMEabcd as key? or ??? scenario #3: replacing an existing Network Entity again assume scenario #1 was already performed. now I want to = replace that record (Network Entity=3D"jbod1.example.com"/iSCSI = Name=3D"NAMEabcd") with Network Entity=3D"jbod1.example.com"/iSCSI Name=3D"NAMEefgh". I = build up a PDU with the replace flag set and do I specify Source Attribute as the existing or new iSCSI Name? or ??? scenario #4: registering a Network Entity without a Storage Node say I have a target device that knows its Network Entity name, has a portal configured, etc. but hasn't yet been configured with = exported Storage Nodes. is it possible for this device to register the known information into the iSNS database without a Source Attribute iSCSI = Name? granted there's no iSCSI targets to discover yet but maybe having this = other=20 information and attributes in the iSNS database is of some use to see the device out there. thanks for your time and any comments. cheers,danny _______________________________________________ Ips mailing list Ips@ietf.org https://www1.ietf.org/mailman/listinfo/ips From exim@www1.ietf.org Mon Mar 22 23:35:36 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA18262 for ; Mon, 22 Mar 2004 23:35:36 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B5dd5-0008QB-RG for ips-archive@odin.ietf.org; Mon, 22 Mar 2004 23:35:08 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i2N4Z7uH032371 for ips-archive@odin.ietf.org; Mon, 22 Mar 2004 23:35:07 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B5dd5-0008Q2-Iq for ips-web-archive@optimus.ietf.org; Mon, 22 Mar 2004 23:35:07 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA18222 for ; Mon, 22 Mar 2004 23:35:04 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B5dd3-00063L-00 for ips-web-archive@ietf.org; Mon, 22 Mar 2004 23:35:05 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B5dc3-0005tv-00 for ips-web-archive@ietf.org; Mon, 22 Mar 2004 23:34:03 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1B5db6-0005ma-00 for ips-web-archive@ietf.org; Mon, 22 Mar 2004 23:33:04 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B5db3-0008BY-5R; Mon, 22 Mar 2004 23:33:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B5dZ2-00081h-AZ for ips@optimus.ietf.org; Mon, 22 Mar 2004 23:30:56 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA18013 for ; Mon, 22 Mar 2004 23:30:53 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B5dZ0-0005YW-00 for ips@ietf.org; Mon, 22 Mar 2004 23:30:54 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B5dY4-0005SS-00 for ips@ietf.org; Mon, 22 Mar 2004 23:29:57 -0500 Received: from mail1.microsoft.com ([131.107.3.125]) by ietf-mx with esmtp (Exim 4.12) id 1B5dXA-0005GC-00 for ips@ietf.org; Mon, 22 Mar 2004 23:29:00 -0500 Received: from inet-vrs-01.redmond.corp.microsoft.com ([157.54.8.27]) by mail1.microsoft.com with Microsoft SMTPSVC(6.0.3790.0); Mon, 22 Mar 2004 20:28:27 -0800 Received: from 157.54.8.109 by inet-vrs-01.redmond.corp.microsoft.com (InterScan E-Mail VirusWall NT); Mon, 22 Mar 2004 20:28:30 -0800 Received: from red-imc-02.redmond.corp.microsoft.com ([157.54.9.107]) by inet-hub-02.redmond.corp.microsoft.com with Microsoft SMTPSVC(6.0.3790.0); Mon, 22 Mar 2004 20:28:29 -0800 Received: from win-imc-02.wingroup.windeploy.ntdev.microsoft.com ([157.54.0.84]) by red-imc-02.redmond.corp.microsoft.com with Microsoft SMTPSVC(6.0.3790.0); Mon, 22 Mar 2004 20:28:29 -0800 Received: from WIN-MSG-10.wingroup.windeploy.ntdev.microsoft.com ([157.54.12.81]) by win-imc-02.wingroup.windeploy.ntdev.microsoft.com with Microsoft SMTPSVC(6.0.3790.1069); Mon, 22 Mar 2004 20:28:26 -0800 X-MimeOLE: Produced By Microsoft Exchange V6.5.7195.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [Ips] usage and validation of iSCSI Name Source Attribute in iSNS registrations? Date: Mon, 22 Mar 2004 20:28:45 -0800 Message-ID: Thread-Topic: [Ips] usage and validation of iSCSI Name Source Attribute in iSNS registrations? thread-index: AcQQaS7ClFpzGmjfT1azymlDF2v8KQAJO/xQ From: "Joe Souza" To: "Danny Mitzel" , Cc: , "Alan Warwick" , "Chris Robinson" , "Suzanne Morgan" X-OriginalArrivalTime: 23 Mar 2004 04:28:26.0435 (UTC) FILETIME=[49007130:01C4108F] Content-Transfer-Encoding: quoted-printable Sender: ips-admin@ietf.org Errors-To: ips-admin@ietf.org 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: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60 Content-Transfer-Encoding: quoted-printable Content-Transfer-Encoding: quoted-printable Hi Danny, In general, the Source Attribute should always be a Node which is already registered in your Entity or is currently being registered in your Entity. I have answered your questions more specifically below: -----Original Message----- From: ips-admin@ietf.org [mailto:ips-admin@ietf.org] On Behalf Of Danny Mitzel Sent: Monday, March 22, 2004 3:56 PM To: ips@ietf.org Cc: mitzel@acm.org Subject: [Ips] usage and validation of iSCSI Name Source Attribute in iSNS registrations? I'm trying to understand the usage and validation of the iSCSI Name Source Attribute in iSNS registrations (DevAttrReg). I've been studying the iSNS-I-D-22.txt and playing a bit with Microsoft freebie iSNS server and generating some iSNS PDU. the latest MS iSNS server claims to 'Added Source Attribute based checks and restrictions', which has increased my frustration as I get rejected registrations 'Source Unauthorized (code=3D8)'. I'm hoping you all can help clarify a few simple registration scenario to help me master iSNS operation. scenario #1: initial Network Entity / Storage Node registration this is a chicken-and-egg case. on the initial Network Entity and Storage Node registration there's no existing iSCSI Name to validate. from the Appendix A examples and my experimentation appears I just plug in the iSCSI Name of the Storage Node being registered? [Joe Souza] Yes. scenario #2: adding a Storage Node to an existing Network Entity lets say I already did a registration as in scenario #1 above (Network Entity=3D"jbod1.example.com", iSCSI Name=3D"NAMEabcd"). now I bring another iSCSI target online (iSCSI Name=3D"NAMEefgh"). to register=20 this can I specify iSCSI Name Source Attribute=3D"NAMEefgh" similar to how I specified the Storage Node being registered in scenario #1? or do I need to give the already existing NAMEabcd as key? or ??? [Joe Souza] Either should be fine. scenario #3: replacing an existing Network Entity again assume scenario #1 was already performed. now I want to replace that record (Network Entity=3D"jbod1.example.com"/iSCSI = Name=3D"NAMEabcd") with Network Entity=3D"jbod1.example.com"/iSCSI Name=3D"NAMEefgh". I = build up a PDU with the replace flag set and do I specify Source Attribute as the existing or new iSCSI Name? or ??? [Joe Souza] In this case, the Source Attribute should contain the name being newly registered. scenario #4: registering a Network Entity without a Storage Node say I have a target device that knows its Network Entity name, has a portal configured, etc. but hasn't yet been configured with exported Storage Nodes. is it possible for this device to register the known information into the iSNS database without a Source Attribute iSCSI Name? granted there's no iSCSI targets to discover yet but maybe having this other=20 information and attributes in the iSNS database is of some use to see the device out there. [Joe Souza] Since the spec does allow registering Portals into an Entity without registering Nodes, there is less checking performed on the Source Attribute in this case. You still need to specify a Source Attribute, however. thanks for your time and any comments. cheers,danny _______________________________________________ Ips mailing list Ips@ietf.org https://www1.ietf.org/mailman/listinfo/ips _______________________________________________ Ips mailing list Ips@ietf.org https://www1.ietf.org/mailman/listinfo/ips From exim@www1.ietf.org Tue Mar 23 04:05:42 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA12644 for ; Tue, 23 Mar 2004 04:05:42 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B5hqT-0006LN-PA for ips-archive@odin.ietf.org; Tue, 23 Mar 2004 04:05:13 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i2N95Di9024385 for ips-archive@odin.ietf.org; Tue, 23 Mar 2004 04:05:13 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B5hqT-0006LE-Cc for ips-web-archive@optimus.ietf.org; Tue, 23 Mar 2004 04:05:13 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA12626 for ; Tue, 23 Mar 2004 04:05:11 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B5hqQ-0006no-00 for ips-web-archive@ietf.org; Tue, 23 Mar 2004 04:05:10 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B5hpS-0006fq-00 for ips-web-archive@ietf.org; Tue, 23 Mar 2004 04:04:11 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1B5hoa-0006YA-00 for ips-web-archive@ietf.org; Tue, 23 Mar 2004 04:03:16 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B5hoT-0005uZ-3Z; Tue, 23 Mar 2004 04:03:09 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B5hkh-0005fn-PU for ips@optimus.ietf.org; Tue, 23 Mar 2004 03:59:15 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA12300 for ; Tue, 23 Mar 2004 03:59:13 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B5hkf-00063x-00 for ips@ietf.org; Tue, 23 Mar 2004 03:59:13 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B5hjf-0005wq-00 for ips@ietf.org; Tue, 23 Mar 2004 03:58:12 -0500 Received: from mtagate6.de.ibm.com ([195.212.29.155]) by ietf-mx with esmtp (Exim 4.12) id 1B5his-0005jv-00; Tue, 23 Mar 2004 03:57:22 -0500 Received: from d12relay01.megacenter.de.ibm.com (d12relay01.megacenter.de.ibm.com [9.149.165.180]) by mtagate6.de.ibm.com (8.12.10/8.12.10) with ESMTP id i2N8tlhW021244; Tue, 23 Mar 2004 08:55:50 GMT Received: from d12ml102.megacenter.de.ibm.com (d12av02.megacenter.de.ibm.com [9.149.165.228]) by d12relay01.megacenter.de.ibm.com (8.12.10/NCO/VER6.6) with ESMTP id i2N8tZMZ170434; Tue, 23 Mar 2004 09:55:36 +0100 In-Reply-To: To: Black_David@emc.com Cc: ips@ietf.org, ips-admin@ietf.org MIME-Version: 1.0 Subject: RE: [Ips] March 2004 Status of Drafts X-Mailer: Lotus Notes Release 6.5.1 January 21, 2004 From: Julian Satran Message-ID: Date: Tue, 23 Mar 2004 10:57:43 +0200 X-MIMETrack: Serialize by Router on D12ML102/12/M/IBM(Release 6.0.2CF2|July 23, 2003) at 23/03/2004 10:55:29, Serialize complete at 23/03/2004 10:55:29 Content-Type: multipart/alternative; boundary="=_alternative 002E41B9C2256E60_=" Sender: ips-admin@ietf.org Errors-To: ips-admin@ietf.org 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: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.1 required=5.0 tests=AWL,HTML_MESSAGE autolearn=no version=2.60 This is a multipart message in MIME format. --=_alternative 002E41B9C2256E60_= Content-Type: text/plain; charset="US-ASCII" iSCSI has also entered 48h - the RFC number is 3720 - julo Black_David@emc.com Sent by: ips-admin@ietf.org 23/03/04 00:36 To ips@ietf.org cc Subject RE: [Ips] March 2004 Status of Drafts I thought this answer to a private inquiry would be of general interest. > Is there any way you could add to this some estimates of time to > publication, for those things in the RFC Editor queue? For example, > iSCSI has been there for a long time now, and I'm sure lots of people > would like to know how much longer. The biggest delay with iSCSI has been clearing dependencies - they're all cleared now and the WG chairs are starting to see authors' 48 hour notices on some of the drafts that have to be published with iSCSI, so iSCSI shouldn't be too much longer now. Beyond that, I don't know how to estimate time for a draft to remain in the RFC Editor queue. > Alternatively or additionally, for things in the queue, are they > waiting for dependencies? I think iSCSI was for a while (the crypto > stuff) -- is it still? Has there been *any* progress? Yes, all dependencies have been cleared for iSCSI. The principle remaining dependencies are that FCIP depends on FCIP-SLP, and iFCP depends on iSNS - both FCIP-SLP and iSNS are on the AD's plate headed back to the IESG. Thanks, --David ---------------------------------------------------- David L. Black, Senior Technologist EMC Corporation, 176 South St., Hopkinton, MA 01748 +1 (508) 293-7953 FAX: +1 (508) 293-7786 black_david@emc.com Mobile: +1 (978) 394-7754 ---------------------------------------------------- _______________________________________________ Ips mailing list Ips@ietf.org https://www1.ietf.org/mailman/listinfo/ips --=_alternative 002E41B9C2256E60_= Content-Type: text/html; charset="US-ASCII"
iSCSI has also entered 48h - the RFC number is 3720 - julo


Black_David@emc.com
Sent by: ips-admin@ietf.org

23/03/04 00:36

To
ips@ietf.org
cc
Subject
RE: [Ips] March 2004 Status of Drafts





I thought this answer to a private inquiry would be of general interest.

> Is there any way you could add to this some estimates of time to
> publication, for those things in the RFC Editor queue?  For example,
> iSCSI has been there for a long time now, and I'm sure lots of people
> would like to know how much longer.

The biggest delay with iSCSI has been clearing dependencies - they're
all cleared now and the WG chairs are starting to see authors' 48 hour
notices on some of the drafts that have to be published with iSCSI,
so iSCSI shouldn't be too much longer now.  Beyond that, I don't know
how to estimate time for a draft to remain in the RFC Editor queue.

> Alternatively or additionally, for things in the queue, are they
> waiting for dependencies?  I think iSCSI was for a while (the crypto
> stuff) -- is it still?  Has there been *any* progress?

Yes, all dependencies have been cleared for iSCSI.  The principle
remaining dependencies are that FCIP depends on FCIP-SLP, and iFCP
depends on iSNS - both FCIP-SLP and iSNS are on the AD's plate
headed back to the IESG.

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

_______________________________________________
Ips mailing list
Ips@ietf.org
https://www1.ietf.org/mailman/listinfo/ips
--=_alternative 002E41B9C2256E60_=-- _______________________________________________ Ips mailing list Ips@ietf.org https://www1.ietf.org/mailman/listinfo/ips From exim@www1.ietf.org Tue Mar 23 09:49:45 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA00071 for ; Tue, 23 Mar 2004 09:49:45 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B5nDR-0004AW-Vi for ips-archive@odin.ietf.org; Tue, 23 Mar 2004 09:49:18 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i2NEnHK7016021 for ips-archive@odin.ietf.org; Tue, 23 Mar 2004 09:49:17 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B5nDR-0004AK-OT for ips-web-archive@optimus.ietf.org; Tue, 23 Mar 2004 09:49:17 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA00018 for ; Tue, 23 Mar 2004 09:49:14 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B5nDP-0004TI-00 for ips-web-archive@ietf.org; Tue, 23 Mar 2004 09:49:15 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B5nCP-0004JR-00 for ips-web-archive@ietf.org; Tue, 23 Mar 2004 09:48:14 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1B5nBS-0004As-00 for ips-web-archive@ietf.org; Tue, 23 Mar 2004 09:47:14 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B5nBH-0003u1-6R; Tue, 23 Mar 2004 09:47:03 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B5nAg-0003nf-5B for ips@optimus.ietf.org; Tue, 23 Mar 2004 09:46:26 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA29914 for ; Tue, 23 Mar 2004 09:46:22 -0500 (EST) From: Black_David@emc.com Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B5nAd-00044m-00 for ips@ietf.org; Tue, 23 Mar 2004 09:46:23 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B5n9p-0003ye-00 for ips@ietf.org; Tue, 23 Mar 2004 09:45:33 -0500 Received: from maho3msx2.isus.emc.com ([128.221.11.32] helo=MAHO3MSX2.corp.emc.com) by ietf-mx with esmtp (Exim 4.12) id 1B5n9M-0003pv-00 for ips@ietf.org; Tue, 23 Mar 2004 09:45:04 -0500 Received: by maho3msx2.corp.emc.com with Internet Mail Service (5.5.2653.19) id ; Tue, 23 Mar 2004 09:44:31 -0500 Message-ID: To: ips@ietf.org Subject: RE: [Ips] March 2004 Status of Drafts Date: Tue, 23 Mar 2004 09:43:09 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain Sender: ips-admin@ietf.org Errors-To: ips-admin@ietf.org 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: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.3 required=5.0 tests=AWL,NO_REAL_NAME autolearn=no version=2.60 > iSCSI has also entered 48h - the RFC number is 3720 - julo Before people get too excited, I need to say that between the amount of final editing needed (both errata we've found and things the RFC Editor has turned up) and the fact that a number of RFCs have to be published simultaneously, the "48 hours" stage for iSCSI is going to take considerably longer than 48 hours. Please don't start asking "where's the RFC?" for at least a couple of weeks. Thanks, --David ---------------------------------------------------- David L. Black, Senior Technologist EMC Corporation, 176 South St., Hopkinton, MA 01748 +1 (508) 293-7953 FAX: +1 (508) 293-7786 black_david@emc.com Mobile: +1 (978) 394-7754 ---------------------------------------------------- _______________________________________________ Ips mailing list Ips@ietf.org https://www1.ietf.org/mailman/listinfo/ips From exim@www1.ietf.org Tue Mar 23 14:58:36 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA22082 for ; Tue, 23 Mar 2004 14:58:35 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B5s2K-0004ny-JX for ips-archive@odin.ietf.org; Tue, 23 Mar 2004 14:58:08 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i2NJw8dc018466 for ips-archive@odin.ietf.org; Tue, 23 Mar 2004 14:58:08 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B5s2K-0004nl-Co for ips-web-archive@optimus.ietf.org; Tue, 23 Mar 2004 14:58:08 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA21962 for ; Tue, 23 Mar 2004 14:58:04 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B5s2H-0007XJ-00 for ips-web-archive@ietf.org; Tue, 23 Mar 2004 14:58:05 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B5s0L-0007CL-00 for ips-web-archive@ietf.org; Tue, 23 Mar 2004 14:56:12 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1B5ryS-0006uY-00 for ips-web-archive@ietf.org; Tue, 23 Mar 2004 14:54:08 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B5ryM-0004L1-5W; Tue, 23 Mar 2004 14:54:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B5rxv-0004Jk-DO for ips@optimus.ietf.org; Tue, 23 Mar 2004 14:53:35 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA21477 for ; Tue, 23 Mar 2004 14:53:31 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B5rxs-0006oI-00 for ips@ietf.org; Tue, 23 Mar 2004 14:53:32 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B5rvt-0006WJ-00 for ips@ietf.org; Tue, 23 Mar 2004 14:51:35 -0500 Received: from sj-iport-2-in.cisco.com ([171.71.176.71] helo=sj-iport-2.cisco.com) by ietf-mx with esmtp (Exim 4.12) id 1B5rts-0006Bo-00 for ips@ietf.org; Tue, 23 Mar 2004 14:49:24 -0500 Received: from sj-core-2.cisco.com (171.71.177.254) by sj-iport-2.cisco.com with ESMTP; 23 Mar 2004 11:53:48 +0000 Received: from cisco.com (cypher.cisco.com [171.69.11.143]) by sj-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id i2NJmqKj006126; Tue, 23 Mar 2004 11:48:52 -0800 (PST) Received: (from kzm@localhost) by cisco.com (8.8.8/2.6/Cisco List Logging/8.8.8) id LAA01217; Tue, 23 Mar 2004 11:48:51 -0800 (PST) From: Keith McCloghrie Message-Id: <200403231948.LAA01217@cisco.com> Subject: Re: [Ips] FW: Initial review of http://www.ietf.org/internet-draf To: bwijnen@lucent.com ("Wijnen, Bert (Bert)") Date: Tue, 23 Mar 2004 11:48:51 -0800 (PST) Cc: kzm@cisco.com (Keith McCloghrie), bwijnen@lucent.com, ips@ietf.org, mrm@kazeon.com, mankin@psg.com In-Reply-To: <7D5D48D2CAA3D84C813F5B154F43B15503DB0C97@nl0006exch001u.nl.lucent.com> from "Wijnen, Bert (Bert)" at Mar 19, 2004 07:57:30 PM X-Mailer: ELM [version 2.5 PL1] MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: ips-admin@ietf.org Errors-To: ips-admin@ietf.org 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: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Bert, > Comments inline, where I feel I need to add something and my responses. You can find the updated MIB at: ftp://ftpeng.cisco.com/ftp/kzm/pub/draft-ietf-ips-fcmgmt-mib-05.txt I'll submit it as an updated I-D if I don't receive any comments in the next few days. Thanks, Keith. > Thanks, > Bert > > > -----Original Message----- > > From: Keith McCloghrie [mailto:kzm@cisco.com] > > Sent: vrijdag 6 februari 2004 23:55 > > To: bwijnen@lucent.com > > Cc: ips@ietf.org; mrm@kazeon.com; mankin@psg.com > > Subject: Re: [Ips] FW: Initial review of > > http://www.ietf.org/internet-drafts/draft-i > > > > > > Bert/Mike, > > > > Thanks for the review. > > > > Below, please find : > > > > a) my respones to the comments, and > > b) the changes that I plan to make as a result of the review. > > > > Thanks, > > Keith. > > > > > Thanks Mike for the first MIB Doctor review. > > > > > > authors/wg members, > > > Pls copy Mike on any responses, cause I suspect he is not > > > subscribed to IPS mailinglist (Mike tell us if you are, > > > in which case people do not specifically have to copy you). > > > > > > Thanks, > > > Bert > > > > > > -----Original Message----- > > > From: Michael MacFaden [mailto:mrm@kazeon.com] > > > Sent: woensdag 4 februari 2004 7:02 > > > To: Wijnen, Bert (Bert) > > > Cc: Anurag Maunder > > > Subject: Initial review of > > > http://www.ietf.org/internet-drafts/draft-ietf-ips-fcmgmt-mib-04.txt > > > > > > > > > Hi Bert, > > > > > > My review of the fiber channel management MIB module: > > > > > > http://www.macfaden.com/ietf/fc-mgmt-mib-4-reviewed.txt > > > > > > Regards, > > > Mike > > > > > > > -------------------------------------------------------------- > > ---------------- > > > > > > > Feb 3, 2004 MIB DOCTOR Review: > > http://www.ietf.org/internet-drafts/draft-ietf-ips-fcmgmt-mib-04.txt > > > > > > Performed by Michael R. MacFaden, Kazeon Systems, Inc > > > according to draft-ietf-ops-mib-review-guidelines-02.txt > > > > > > A. Documentation Guidelines > > > 3.1 o MIB boilerplate section -> present > > > current version? -> YES > > > o Narrative sections -> present > > > Scope described? -> YES > > > Spelling? -> No obvious mistakes > > > Module structure described? -> YES > > > Dependent on other modules? -> YES > > > If so, which ones? -> IF-MIB > > > Relates to other modules? -> YES > > > If so, which ones? -> > > HOST-RESOURCES-MIB, ENTITY-MIB, > > > References ([XXX])? -> Yes, they are > > correct and resolve properly > > > > > > Reviewer Comments: > > > 1. "high performance capability" isn't further > > defined so first > > > sentence is so much fluff. > > > > This sentence which appears in the first sentence of the > > "Short Intro to > > Fibre Channel" section, was copied from the Introduction section of > > Fibre Channel standards documents. The intent is to give a high-level > > indication of what Fibre Channel is aimed at, and to phrase > > it so as to > > remain valid in the future as and when the specific bandwidth > > supported > > by Fibre Channel is higher than it is today. It is too early in the > > into to be definitive. Thus, it isn't "fluff". > > > > > 2. Text describing the MIB module's structure > > (Sect 4.1-11) is better than the GROUP DESCRIPTION > > > clauses in the compliance section. > > > 3. IF-MIB description was superbly done. > > > o Definitions section present -> present > > > Written to SMIv2 standards? -> YES > > > Issues with compilation? -> YES > > > o Intellectual Property section -> present > > > Matches current boilerplate? -> YES > > > Any proprietary rights claimed? -> NO > > > o References section -> present > > > Matches current boilerplate (2578-80,3410)? -> YES > > > Normative/informative sections separate? -> YES > > > MIB modules listed in IMPORTS included? -> > > > o Security section -> present > > > Matches current boilerplate? -> YES > > > Specific Read/write objects listed? -> YES > > > Security risk spelled out? -> YES > > > Specific Read only objects listed? > > > > > > Reviewer Comments: > > > There was only one specific security risk > > described. More could be "spelled out." > > > For instance, setting fcmSwitchDomainId to an > > invalid value could lead to > > > denial of service in some configurations. > > > > No matter how much one writes in this section, it is always true that > > "more could be spelled out". > > > Keith, pls don't read it so litrrally. I guess Mike did see room > for improvement. And he in fact gives an example as to what can be improved. > > > > o IANA Considerations section -> not present > > > Was a namespace defined? -> NO > > > > > > o Copyright Notices section -> present > > > Correct year specified? -> NO > > > Copyright found in MODULE-IDENTITY? -> NO > > > > Noted. > > and will be fixed I assume? Right; it was on the list of fixes that I previously enclosed. > > > o Definitions section detail > > > > > > Here are the diagnostics from certain mib syntax checkers: > > > > > > Diagnostics from Version 0.4.2 smilint -l9 > > > C:\local\smi\mibs\ietf>smilint -m -s -l 9 ./FC-MGMT-MIB > > > ./FC-MGMT-MIB:2213: [5] {group-unref} warning: current > > group `fcmLinkBasicGroup' is not referenced in this module > > > > OK, I will add a GROUP clause to "make it clear that the > > optional status is intended". > > > Thanks > > > > ./FC-MGMT-MIB:62: [5] {type-without-format} warning: type > > `DomainIdOrZero' has no format specification > > > ./FC-MGMT-MIB:94: [5] {type-without-format} warning: type > > `FcBbCredit' has no format specification > > > ./FC-MGMT-MIB:106: [5] {type-without-format} warning: type > > `FcDataFieldSize' has no format specification > > > ./FC-MGMT-MIB:171: [5] {type-without-format} warning: type > > `PhysicalIndexOrZero' has no format specification > > > ./FC-MGMT-MIB:181: [5] {type-without-format} warning: type > > `HrSWInstalledIndexOrZero' has no format specification > > > ./FC-MGMT-MIB:192: [5] {type-without-format} warning: type > > `MilliSeconds' has no format specification > > > ./FC-MGMT-MIB:198: [5] {type-without-format} warning: type > > `MicroSeconds' has no format specification > > > > It seems to me like the compiler has a bug here, since all of these are, or > > have a TC as their syntax and for all but two of them, the TC is defined > > with a range, e.g., DomainIdOrZero is defined as: > > > > DomainIdOrZero ::= TEXTUAL-CONVENTION > > STATUS current > > DESCRIPTION > > "The Domain Id (of a FC switch), or zero if the no Domain Id > > has been assigned." > > SYNTAX Integer32 (0..239) > > > > The two exceptions are MilliSeconds and MicroSeconds which are both > > Unsigned32 and the inherent (0..4294967295) is correct for both. > > I think the warning is cause by the fact that there is no DISPLAY-HINT. > Can you add those? I can't because, as far as I know, there is no standard format for displaying these. Anyway, RFC 2579 says that DISPLAY-HINT is optional. So, this is another bug in that compiler. Why is the IETF's MIB review process relying upon a buggy compiler ?? > > > Diagnostics from MIB Smithy 2.4.2 > > > > > > > > [FC-MGMT-MIB:fcmgmtCompliance:FC-MGMT-MIB:fcmInstanceSoftwareI > > ndex] : warning : SYNTAX in variation and OBJECT-TYPE differ > > in type names 'Integer32' and 'HrSWInstalledIndexOrZero'. > > > > > [FC-MGMT-MIB:fcmgmtCompliance:FC-MGMT-MIB:fcmInstancePhysicalI > > ndex] : warning : SYNTAX in variation and OBJECT-TYPE differ > > in type names 'Integer32' and 'PhysicalIndexOrZero'. > > > > Yes, but both HrSWInstalledIndexOrZero and PhysicalIndexOrZero are TCs > > which have Integer32 as their underlying syntax. > > > And no change is needed. I think the Smithy should be fixed. > > > > [FC-MGMT-MIB:fcmLinkEnd2UnitType] : warning : BITS > > named-number list values should start at zero. > > > [FC-MGMT-MIB:fcmFLoginClassesAgreed] : warning : BITS > > named-number list values should start at zero. > > > > Another bug in the compiler. Both objects have a TC as their syntax where > > the TC has a named-number list which does start at zero. > > > Agreed > > > > [FC-MGMT-MIB:fcmISPortEntry] : warning : All INDEX objects > > in this table are auxiliary (i.e., from other tables). > > > [FC-MGMT-MIB:fcmFxPortEntry] : warning : All INDEX objects > > in this table are auxiliary (i.e., from other tables). > > > > Eh? The compiler has another bug, since: > > > > a) auxiliary does NOT mean "i.e., from other tables", rather RFC 2758 > > section 7.7 defines "auxiliary" as follows: > > > > Objects which are both specified in the INDEX clause of a conceptual > > row and also columnar objects of the same conceptual row are termed > > auxiliary objects. > > > > Thus, the error message as stated is actually wrong. > > > I believe so too > > > b) It is common practice for media-specific MIBs which extend the > > IF-MIB to define a table which is INDEX-ed only by ifIndex. > > > Agreed and no issue I think > > > > > > [FC-MGMT-MIB:fcmPortFcOperClass] : warning : BITS > > named-number list values should start at zero. > > > [FC-MGMT-MIB:fcmPortFcCapClass] : warning : BITS > > named-number list values should start at zero. > > > [FC-MGMT-MIB:fcmPortEntry] : warning : All INDEX objects in > > this table are auxiliary (i.e., from other tables). > > > [FC-MGMT-MIB:fcmInstanceFunctions] : warning : BITS > > named-number list values should start at zero. > > > Validation complete - 0 error(s), 10 warning(s) > > > > See above. > > > > > Reviewer Comments: > > > 1. The TC's could possibly go into a separate TC > > document for fiber channel: FcNameIdOrZero, DomainIdOrZero, > > FcAddressId > > > as it is mentioned there might be multiple Fiber > > channel mib modules in the future. > > > > While your "could" and "possibly" are correct, but we have already > > written several of these follow-on FC MIB modules, and they are > > IMPORT-ing TCs from this MIB without any problems. So, this > > would be a disruptive change for no benefit. > > Keith, but the current spec locks all other MIB modules to this > one. I.e. the otehrs cannot advance unless this one also advances. > If you put TCs in a separate module then you do not have that issue. > Now it can still be changed (rather easily), later it becomes more > difficult. But it is not a MUST change Since they are "follow-on FC MIB modules", it is entirely appropriate that they not advance until this one does, and anyway most of them would still be dependent on this MIB, even if the TC's were in a separate document. > > > 2. FcAddressId doesn't have an *OrZero version, which > > might be needed at a later date. > > > > It's syntax is "OCTET STRING (SIZE(0 | 3))" and the zero-length value > > is already used (see fcmLinkEnd2FcAddressId). > > You migth want to add text to the DESCRITPION clause that explains the > special meaning of zero. > > I think what Mike noticed is an inconsistency, because some of your other > TCs do have an xxxOrZero. Consistency is (I think ) a good thing. > But a again not a MUST change. Because the TC is not currently imported by any other MIB, I've made the change that you ask for (but not the addition of another TC that Mike asked for). > > > 3. FcPortType enumeration "dynamic(3), -- determined > > dynamically" seems redundant, prefer comment point to underlying spec > > > > No, it's not redundant because "dynamic" could also mean that > > the value > > is constantly changing, and saying "determined dynamically" > > removes that possibility. > > You might want to enhance the description somewhat then. > And as Mike says, a ptr to the spec might be helpful too I've added a couple of words and moved it inside the DESCRIPTION instead of being an ASN.1 comment. > > > 4. PhysicalIndexOrZero, HrSWInstalledIndexOrZero are > > > very useful and generally applicable to many mib modules. > > > They look strangly wrong being defined here and > > > should be defined in another TC, like Entity-MIB, or some > > > common TC-MIB. > > > > But they aren't, and thus, the best that this MIB module can do is to > > define the TC's itself. > > Could you rename them to RcPhysicalIndexOrZero and FcHrSWInstalledIndexOrZero > so that they will not conflict if Entity MIB does define them later. There will be no conflict. First, the possibility of a descriptor clash is ever-present in practically every deployment because of Enterprise MIBs. Second, MIB compilers have to cope with it, and they do for the most part, although HP OpenView's compiler has had the same bug for the last ~10 years, and most often shows up because of OwnerString being defined as an OCTET STRING in IF-MIB and as a DisplayString in RMON-MIB; if you delete one of the two definitions or change them to both have the same syntax, OpenView stops complaining. > But... SURPRISE (maybe), pls take a look at > > draft-ietf-entmib-v3-04.txt > > and is on my AD plate for review!! So at least that one can be > imported from ENTITY-MIB. First, we don't want to risk any further delays. (In the update that I've just done, I changed the date from February 2003 to March 2004. In other words, we have waited 13 months for the benefit of the minor changes that I'm making now :-(.) So, let's not import from draft-ietf-entmib-v3-04.txt. Second, as you may have noticed all(*) the FC-specific TC's in this MIB are already prefixed with "Fc", and none of the generic TC's are prefixed with "Fc". I want to keep it that way, and since neither of PhysicalIndexOrZero or HrSWInstalledIndexOrZero are FC-specific, I've just deleted them. (* -- actually, all but one because I made a mistake with DomainIdOrZero.) > > > 5. MicroSeconds, MilliSeconds should also be in some > > generic tc-mib... > > > > But they aren't, and thus, the best that this MIB module can do is to > > define the TC's itself. > > Well, the SSPM-MIB (draft-ietf-rmonmib-sspm-mib-11.txt) which is in > IETF Last Call DOES have a SspmMicroSeconds TC. > I made them prefix with Sspm.. because I do foresee a future generic > TC MIB for these things. So if you want to keep them in this MIB > module I strongly recommend to name it FcMicroSeconds and FcMilliSeconds. Again, naming them FcMilliseconds and FcMicroseconds would give the reader the wromng impression. These are NOT Fibre Channel units; they are generic units. Fibre Channel's milliseconds/microseconds are NO different from any other technology's milliseconds/microseconds. Nevertheless, because of the comment, I've deleted the two TC's. > > > 6. fcmInstanceIndex DESCRIPTION is problematic for me. > > Either it stays static or it doesn't. > > > Having something "desireable" is worthless to those > > writing mangement applications, they have to assume worst case always. > > > > Not worthless, because if agent implementors heed the advice, > > then mgmt > > apps can coded to check whether the index values have been retained > > over the last restart, and only if not, do they need to re-synchronize > > their database. That is, it is an optimization for the common case of > > index values being retained, but the fallback still works in the case > > (hopefully less common) when all knowledge of index values is lost. > > So would it make sense to phrase it with a SHOULD ?? It wouldn't make sense to say a system SHOULD retain the values if all of its non-volatile memory is replaced, i.e., to say that it should when we know there are circumstances when it can't !! > > > There are problems with the description. Sentences > > start without capitalization. > > > > "Sentences" ?? I see only one such sentence-break, for which the fix > > is to delete the the period before "but" (because it's bad grammar to > > start a sentence with "But".) > > > > > fcmInstanceTable has very critical data. Would like > > to have a LastChange entry per row to know when values were changed or > > > a "configuration change" notification if lastChange > > object is too much overhead. > > > > But the data is not, in general, both critial and dynamic. > > Specifically, > > the only things in this table that change are: > > - the FabricId if it's based on the WWN of the Principal switch; > > -- a notification of a Principal switch change is being > > proposed as > > an extension to this MIB. > > - the read-write objects (but only when an app changes them); > > -- changes in these values are not critical to the > > operation of the > > network, and the synchronization of mgmt apps should > > not have to > > rely on notifications from agents for such non-critical data. > > - the Status object, > > -- to monitor this object for changes, set an RMON > > threshold on it. > > Note that the typical situation is to have just one instance; > > even if there are multiple instances, there will not be many. > > Having an RMON threshold will be more effective than having a > > LastChange object. > > > > > 7. fcmInstanceWwn, but does it matter which WWN is > > selected? Will managment stations expect one vendor > > implemetnation over another? > > > > The ability to have multiple instances is defined as a flexibility to > > allow for many/any different choices by vendors. Vendors are free to > > choose to have one, or more, instances using whatever > > methodology they wish. > > Thus, we cannot prescribe how the WWN is selected. > > > > This flexibility is necessary because otherwise there is a > > genuine risk > > that a vendor will implement a set of Fibre Channel > > interfaces in a manner > > which cannot be represented by this MIB. > > > > > Wouldn't it be the same as fcmSwitchDomainId if > > fcmSwitchPrincipal is True? > > > > It could be but it needn't be, and the circumstance you ask about is a > > corner case which for example never applies to HBAs. > > > > > 8. fcmInstanceStatus could use an associated object to > > get timestamp of the last state change > > > > While implementation feedback might tell us that, I think it's too > > soon to be sure. So, let's save this comment until we update > > the MIB from > > Proposed to Draft Standard. > > > > > 9. fcmInstanceStatus doesn't seem to be implementable in > > a consistent way across vendors. Needs better definition > > > ideally this state is defined in the underlying > > technology specifications. > > > > On the contrary, a) there is no one underlying technology, and b) the > > underlying technology specifications are the subject of future MIBs, > > not this one. This object serves as a generic summary of the > > underlying > > specifics (e.g., somewhat like ifOperStatus does for an interface.) > > > > > 10. fcmInstanceTextName/fcmInstanceDescr, are there any > > DEFAULT values for these? Suspect vendor implementations will > > > provide something. Better to define the intended > > purpose of these objects better. > > > "A textual name for this management instance > > and the Fibre > > > Channel entity/entities that it is managing." > > > might be > > > "A textual name for this management instance > > and the Fibre > > > Channel entity/entities that it is managing set > > by the operator or to a default string "XXXX" by the device." > > > > "XXXX" can not be specified in this MIB without restricting > > the necessary > > flexibility, anything that could be specified in this MIB would not be > > specific enough. The whole idea of this object is to be the > > name specified > > by the operator/NM-app, to have a default value changes the semantics. > > > > > 11. fcmPortAdminType - Assuming a valid value change > > can't be done for some device resource specific case, how can > > > the error be reported? A generic > > snmp error to the set is necessary but not sufficient I think. > > > > Why would it not be sufficient ?? > > cause genErr is also used for other (unspecified) errors. > Maybe this could be spelled out that the best would be to sent an > inconsistentValue error? This comment applies to every read-write/read-create in this and every other MIB. To explain when to return which error status for a SetRequest requires most of pages 20-22 of RFC 3416 to be included in the DESCRIPTION of each such MIB object, and that doesn't make sense. It seems to me that the thing which prompted this comment was the second sentence in the DESCRIPTION: "The administratively desired type of this port. Each port will typically only be able to support a subset of these types." Is it really necessary for me to remove the second sentence ?? > > > 12. Not sure why these object's syntax wasn't a TC? They > > will probably be added to in time as well. > > > fcmPortCapProtocols > > > fcmPortTransmitterType > > > fcmPortConnectorType -- this should probably > > follow the MAU-MIB convention or we need to standardize 'JackType' > > > in a new TC mib as > > there is now overlap... > > > > Actually, not for the latter two because they are not generic > > definitions. > > Rather they are the specific enumerations listed for the function in > > T11's GS-3 speciofication. Sicne a future revision of the GS-3 spec > > could revise them individually, they cannot be defined as common TCs. > > The first one could, but I don't see any rule that it violates which > > would justify a change at this time. > > > A change is justified as much as no change. My personal opinion. > Is it a MSUT change? no it is not. > > > > 13. fcmPortStatsTable doesn't have an explicitly > > specified discontinuity object -- is ifXTable entry the one > > that applies? > > > > Yes. > > Then you want to state that in DESCRIPTION clause(s) I've added this to all tables which have CounterNn objects. > > > Also, the counters described here should > > have REFERNCE clauses to counters defined in the underlying > > technology > > > specs. While the descriptions are generally > > good, they do not cover all possible cases when > > > one should be incremented or not -- that > > leads to incompatible implementations. > > > > Many of them are not specifically defined in any Fibre Channel > > specification. If any are ambiguous, please suggest alternative > > wording. Otherwise, I suggest we wait for implementation feedback. > > > > > 14. fcmPortLcStatsTable doesn't have split counters? Is > > a SNMPv1 agent then really useful when running high speed interfaces? > > > > No, but at the time (several years ago now) when this was discussed > > in the WG, many Storage vendors only had SNMPv1 agents, and as a > > result, this table was defined at the explicit direction of the WG. > > > I.e. to force them to SNMPv3? FIne by me! > > > > DESCRIPTION > > > "A list of Counter32-based statistics which are > > a shadow of > > > the Counter64 statistics in the fcmPortStatsTable, for > > > systems which do not support Counter64." > > > I suggest the text mention it should "shadow" the > > lower 32 bits? > > > > If that isn't what "shadow" means, then I don't know what it > > does mean, and we shouldn't use the term at all. > > > I prefer if you spell out they contain the low order 32 bits. I removed the phrase containing "shadow". > > > 15. If errors are not so common an occurance across > > instances, the fcmPortErrorsTable might benefit from a > > *LastChange object > > > so not all objects have to be polled to determine > > any error state change. Alternately provide a summary counter that > > > is a simple sum of the number of errors. That should > > allow for better scaling of this table for mgmt polling using > > SNMP/UDP. > > > > The summary counter for many of these is already available: > > ifInErrors. > > > > > 16. Error table should have REFERENCE clauses to point > > out where in the underlying spec these counters are defined. > > > This appears to be done, but is inconsistent. > > fcmPortLinkFailures has a REFERENCE but fcmPortLinkResets wasn't? > > > > As I recall, it is consistent; specifically, all those for which > > there is an appropriate section to reference have a REFERENCE clause. > > > > > 17. fcmFxPortTable needs a discontinutity object. if > > fcmPortOperType is changed from Fx to some other then back within > > > a given polling interval, the data collected from > > this table will be incorrect. > > > > No, because there are no Counter-based objects in this table. > > > > > 18. Objects in fcmFxPortTable, fcmFLoginTable could use > > REFERENCE clauses. > > > > Sigh !! I will look again to see what I can find. > > > > > 19. fcmFLoginNxPortIndex doesn't specify what behaviors > > should be across SNMP agent reset or system reboots like > > > fcmInstanceIndex is required to do. So I'm a bit > > concerned what the indexing looks like for all the tables on > > > system reset or agent reset. > > > > I will add a sentence saying that after a value of > > fcmFLoginNxPortIndex > > is assigned to a particular Nx_Port, it can be re-used when and only > > when it is assigned to the same Nx_Port, or, after a reset of > > the value > > of the relevant instance of ifCounterDiscontinuityTime. > > > > > 20. fcmLinkEnd2AgentAddress OBJECT-TYPE is SYNTAX > > SnmpAdminString, not InetAddressType? Why? > > > > Because the value is received from the otrher end of the > > link, and if the > > other end supplies a bogus value,m then that bpgus value > > needs to be stored > > in the MIB. > > So in that case it can be stored with InetAddressType "unknown" and > the value that you received in the InetAddress, no? No. The GS-3 spec gives, as an example, the use of a URL in this string, with the URL being for an SNMP, or HTTP or XML agent. I've added some words to the DESCRIPTION stating this. > So I do not see a reason to NOT use InetAddress(Type) combo. > > > 21. > > > > > > End of Report > > > > > An additional remark from me: > > I strongly recommend to rename DomainIdOrZero to FcDomainIdOrZero. > The current definition of the TC is certainly not a generic DomainId > definition is it? Agreed. DomainIdOrZero is FC-specific, and so it was my mistake to call it DomainIdOrZero. Keith. _______________________________________________ Ips mailing list Ips@ietf.org https://www1.ietf.org/mailman/listinfo/ips From exim@www1.ietf.org Tue Mar 23 16:56:43 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA05144 for ; Tue, 23 Mar 2004 16:56:43 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B5tsd-0003Ak-Qv for ips-archive@odin.ietf.org; Tue, 23 Mar 2004 16:56:15 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i2NLuFC7012193 for ips-archive@odin.ietf.org; Tue, 23 Mar 2004 16:56:15 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B5tsd-0003Aa-Je for ips-web-archive@optimus.ietf.org; Tue, 23 Mar 2004 16:56:15 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA05036 for ; Tue, 23 Mar 2004 16:56:12 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B5tsb-00008C-00 for ips-web-archive@ietf.org; Tue, 23 Mar 2004 16:56:13 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B5trY-0007k4-00 for ips-web-archive@ietf.org; Tue, 23 Mar 2004 16:55:11 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1B5tqW-0007ZU-00 for ips-web-archive@ietf.org; Tue, 23 Mar 2004 16:54:04 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B5tqT-0002p7-D5; Tue, 23 Mar 2004 16:54:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B5tqP-0002mv-V6 for ips@optimus.ietf.org; Tue, 23 Mar 2004 16:53:58 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA04880 for ; Tue, 23 Mar 2004 16:53:54 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B5tqN-0007Y2-00 for ips@ietf.org; Tue, 23 Mar 2004 16:53:55 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B5tpE-0007LY-00 for ips@ietf.org; Tue, 23 Mar 2004 16:52:46 -0500 Received: from hoemail1.lucent.com ([192.11.226.161] helo=hoemail1.firewall.lucent.com) by ietf-mx with esmtp (Exim 4.12) id 1B5toB-0007Br-00 for ips@ietf.org; Tue, 23 Mar 2004 16:51:39 -0500 Received: from nl0006exch001h.wins.lucent.com (h135-85-76-62.lucent.com [135.85.76.62]) by hoemail1.firewall.lucent.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id i2NLor229282 for ; Tue, 23 Mar 2004 15:50:56 -0600 (CST) Received: by nl0006exch001h.nl.lucent.com with Internet Mail Service (5.5.2657.72) id <16995B3G>; Tue, 23 Mar 2004 22:50:51 +0100 Message-ID: <7D5D48D2CAA3D84C813F5B154F43B15503DB11C5@nl0006exch001u.nl.lucent.com> From: "Wijnen, Bert (Bert)" To: Keith McCloghrie , ips@ietf.org Cc: bwijnen@lucent.com, mrm@kazeon.com, mankin@psg.com Subject: RE: [Ips] FW: Initial review of http://www.ietf.org/internet-draf Date: Tue, 23 Mar 2004 22:50:49 +0100 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2657.72) Content-Type: text/plain Sender: ips-admin@ietf.org Errors-To: ips-admin@ietf.org 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: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=AWL autolearn=no version=2.60 First, I still see: ::= { mib-2 999999 } -- to be assigned by IANA Keith, you know VERY WELL I think that we do NOT want that. The strongly recommended notation is: ::= { mib-2 xxx } -- to be assigned by IANA Responses to things on which we're still not in sync > > > > ./FC-MGMT-MIB:62: [5] {type-without-format} warning: type > > > `DomainIdOrZero' has no format specification > > > > ./FC-MGMT-MIB:94: [5] {type-without-format} warning: type > > > `FcBbCredit' has no format specification > > > > ./FC-MGMT-MIB:106: [5] {type-without-format} warning: type > > > `FcDataFieldSize' has no format specification > > > > ./FC-MGMT-MIB:171: [5] {type-without-format} warning: type > > > `PhysicalIndexOrZero' has no format specification > > > > ./FC-MGMT-MIB:181: [5] {type-without-format} warning: type > > > `HrSWInstalledIndexOrZero' has no format specification > > > > ./FC-MGMT-MIB:192: [5] {type-without-format} warning: type > > > `MilliSeconds' has no format specification > > > > ./FC-MGMT-MIB:198: [5] {type-without-format} warning: type > > > `MicroSeconds' has no format specification > > > > > > It seems to me like the compiler has a bug here, since > > > all of these are, or > > > have a TC as their syntax and for all but two of them, > > > the TC is defined > > > with a range, e.g., DomainIdOrZero is defined as: > > > > > > DomainIdOrZero ::= TEXTUAL-CONVENTION > > > STATUS current > > > DESCRIPTION > > > "The Domain Id (of a FC switch), or zero if > > > the no Domain Id has been assigned." > > > SYNTAX Integer32 (0..239) > > > > > > The two exceptions are MilliSeconds and MicroSeconds > > > which are both > > > Unsigned32 and the inherent (0..4294967295) is correct for both. > > > > I think the warning is cause by the fact that there is no > > DISPLAY-HINT. Can you add those? > > I can't because, as far as I know, there is no standard format for > displaying these. Anyway, RFC 2579 says that DISPLAY-HINT is > optional. > So, this is another bug in that compiler. Why is the IETF's > MIB review process relying upon a buggy compiler ?? > OK, I asked "can you add those?" I did not say "you MUST add those". AS you note, they are optional. However the set of current MIB doctors have composed a set of guidelines for review, and document draft-ietf-ops-mib-review-guidelines-02.txt represents the current guidelines and sect 4.6.3 recommends to add a DISPLAY HINT: 4.6.3. DISPLAY-HINT Clause The DISPLAY-HINT clause is used in a TC to provide a non-binding hint to a management application as to how the value of an instance of an object defined with the syntax in the TC might be displayed. Its presence is optional. Although management applications typically default to decimal format ("d") for integer TCs which are not enumerations and to a hexadecimal format ("1x:" or "1x " or "1x_") for octet string TCs when the DISPLAY-HINT clause is absent, it should be noted that SMIv2 does not actually specify any defaults. MIB authors should be aware that a clear hint is provided to applications only when the DISPLAY-HINT clause is present. So... Can you add one please. If nothing else, then use "d" If you disagree with the mib-review guideline. pls speak up on ietfmibs@ops.ietf.org list, so we can re-evaluate. This guidelines doc is on its way to become a BCP. The compiler by the wayt only generates a warning, not an error! ... snip ... > > > > Reviewer Comments: > > > > 1. The TC's could possibly go into a separate TC > > > document for fiber channel: FcNameIdOrZero, DomainIdOrZero, > > > FcAddressId > > > > as it is mentioned there might be multiple Fiber > > > channel mib modules in the future. > > > > > > While your "could" and "possibly" are correct, but we have already > > > written several of these follow-on FC MIB modules, and they are > > > IMPORT-ing TCs from this MIB without any problems. So, this > > > would be a disruptive change for no benefit. > > > > Keith, but the current spec locks all other MIB modules to this > > one. I.e. the otehrs cannot advance unless this one also advances. > > If you put TCs in a separate module then you do not have that issue. > > Now it can still be changed (rather easily), later it becomes more > > difficult. But it is not a MUST change > > Since they are "follow-on FC MIB modules", it is entirely appropriate > that they not advance until this one does, and anyway most of them > would still be dependent on this MIB, even if the TC's were in a > separate document. > OK fine. as long as the WG makes a conscious and educated decision on this, then I am happy. > > > > 2. FcAddressId doesn't have an *OrZero version, which > > > might be needed at a later date. > > > > > > It's syntax is "OCTET STRING (SIZE(0 | 3))" and the > > > zero-length value is already used (see fcmLinkEnd2FcAddressId). > > > > You migth want to add text to the DESCRITPION clause that > > explains the special meaning of zero. > > > > I think what Mike noticed is an inconsistency, because some > > of your other > > TCs do have an xxxOrZero. Consistency is (I think ) a good thing. > > But a again not a MUST change. > > Because the TC is not currently imported by any other MIB, > I've made the > change that you ask for (but not the addition of another TC that Mike > asked for). > > > > > 3. FcPortType enumeration "dynamic(3), -- determined > > > dynamically" seems redundant, prefer comment point to > > > underlying spec > > > > > > No, it's not redundant because "dynamic" could also mean that > > > the value > > > is constantly changing, and saying "determined dynamically" > > > removes that possibility. > > > > You might want to enhance the description somewhat then. > > And as Mike says, a ptr to the spec might be helpful too > > I've added a couple of words and moved it inside the DESCRIPTION > instead of being an ASN.1 comment. > Thanks > > > > 4. PhysicalIndexOrZero, HrSWInstalledIndexOrZero are > > > > very useful and generally applicable to many mib modules. > > > > They look strangly wrong being defined here and > > > > should be defined in another TC, like Entity-MIB, or some > > > > common TC-MIB. > > > > > > But they aren't, and thus, the best that this MIB module > > > can do is to define the TC's itself. > > > > Could you rename them to RcPhysicalIndexOrZero and > > FcHrSWInstalledIndexOrZero > > so that they will not conflict if Entity MIB does define them later. > > There will be no conflict. First, the possibility of a descriptor > clash is ever-present in practically every deployment because of > Enterprise MIBs. Second, MIB compilers have to cope with it, and they > do for the most part, although HP OpenView's compiler has had the same > bug for the last ~10 years, and most often shows up because of > OwnerString being defined as an OCTET STRING in IF-MIB and as a > DisplayString in RMON-MIB; if you delete one of the two definitions or > change them to both have the same syntax, OpenView stops complaining. > In principle we try to NOT get name clashes in STDs track MIB modules. Of course we have goofed up a few times, and we want to try to avoid so in the future, that is why I am asking (pretty serious) to consider the name change and add the prefix. PLEASE! > > But... SURPRISE (maybe), pls take a look at > > > > draft-ietf-entmib-v3-04.txt > > > > and is on my AD plate for review!! So at least that one can be > > imported from ENTITY-MIB. > > First, we don't want to risk any further delays. (In the update that I've > just done, I changed the date from February 2003 to March 2004. In other > words, we have waited 13 months for the benefit of the minor changes that > I'm making now :-(.) So, let's not import from > draft-ietf-entmib-v3-04.txt. > If you do not want to IMPORT from entmibv3, I can accept that. I may want to re-open that if that entmib docs ends up as RFC earlier than yours. But it DOES again show that you better add the requested prefix to the TC names. > Second, as you may have noticed all(*) the FC-specific TC's in this MIB > are already prefixed with "Fc", and none of the generic TC's are > prefixed with "Fc". I want to keep it that way, and since neither of > PhysicalIndexOrZero or HrSWInstalledIndexOrZero are FC-specific, I've > just deleted them. (* -- actually, all but one because I made a > mistake with DomainIdOrZero.) > So you have removed them I see. And you have instead used Integer32. Although this is perfectly legal SMIv2, I think you understand VERY WELL that this is against the spirit of what we are trying to do with TCs. If that is the way you want to go... fine, I guess we should make the docs informational or experimental and then you can do whatever you want as long as the SMIv2 use is legal to the letter instead of to teh spirit. > > > > 5. MicroSeconds, MilliSeconds should also be in some > > > generic tc-mib... > > > > > > But they aren't, and thus, the best that this MIB module > > > can do is to define the TC's itself. > > > > Well, the SSPM-MIB (draft-ietf-rmonmib-sspm-mib-11.txt) which is in > > IETF Last Call DOES have a SspmMicroSeconds TC. > > I made them prefix with Sspm.. because I do foresee a future generic > > TC MIB for these things. So if you want to keep them in this MIB > > module I strongly recommend to name it FcMicroSeconds and FcMilliSeconds. > > Again, naming them FcMilliseconds and FcMicroseconds would give the > reader the wromng impression. These are NOT Fibre Channel units; they are > generic units. Fibre Channel's milliseconds/microseconds are NO different > from any other technology's milliseconds/microseconds. Nevertheless, > because of the comment, I've deleted the two TC's. > And again use a plain Integer32 instead. OK... you win > > > > 6. fcmInstanceIndex DESCRIPTION is problematic for me. > > > Either it stays static or it doesn't. > > > > Having something "desireable" is worthless to those > > > writing mangement applications, they have to assume worst > > > case always. > > > > > > Not worthless, because if agent implementors heed the advice, > > > then mgmt > > > apps can coded to check whether the index values have > > > been retained > > > over the last restart, and only if not, do they need to > > > re-synchronize > > > their database. That is, it is an optimization for the > > > common case of > > > index values being retained, but the fallback still works > > > in the case > > > (hopefully less common) when all knowledge of index > > > values is lost. > > > > So would it make sense to phrase it with a SHOULD ?? > > It wouldn't make sense to say a system SHOULD retain the > values if all of > its non-volatile memory is replaced, i.e., to say that it > should when we > know there are circumstances when it can't !! > Would it be better then to just say instead of "desirable" to add a sentence that says somethink aka "This should no tbe taken as an easy excuse to ignore the desire for keeping the value constant across restarts" We did a similar thing for commitFailed and undoFailed. > > > > There are problems with the description. Sentences > > > start without capitalization. > > > > > > "Sentences" ?? I see only one such sentence-break, for > > > which the fix > > > is to delete the the period before "but" (because it's > > > bad grammar to start a sentence with "But".) > > > > > > > fcmInstanceTable has very critical data. Would like > > > to have a LastChange entry per row to know when values > > > were changed or > > > > a "configuration change" notification if lastChange > > > object is too much overhead. > > > > > > But the data is not, in general, both critial and dynamic. > > > Specifically, > > > the only things in this table that change are: > > > - the FabricId if it's based on the WWN of the Principal switch; > > > -- a notification of a Principal switch change is being > > > proposed as > > > an extension to this MIB. > > > - the read-write objects (but only when an app changes them); > > > -- changes in these values are not critical to the > > > operation of the > > > network, and the synchronization of mgmt apps should > > > not have to > > > rely on notifications from agents for such non-critical data. > > > - the Status object, > > > -- to monitor this object for changes, set an RMON > > > threshold on it. > > > Note that the typical situation is to have just one instance; > > > even if there are multiple instances, there will not be many. > > > Having an RMON threshold will be more effective than having a > > > LastChange object. > > > > > > > 7. fcmInstanceWwn, but does it matter which WWN is > > > selected? Will managment stations expect one vendor > > > implemetnation over another? > > > > > > The ability to have multiple instances is defined as a > flexibility to > > > allow for many/any different choices by vendors. Vendors > are free to > > > choose to have one, or more, instances using whatever > > > methodology they wish. > > > Thus, we cannot prescribe how the WWN is selected. > > > > > > This flexibility is necessary because otherwise there is a > > > genuine risk > > > that a vendor will implement a set of Fibre Channel > > > interfaces in a manner > > > which cannot be represented by this MIB. > > > > > > > Wouldn't it be the same as fcmSwitchDomainId if > > > fcmSwitchPrincipal is True? > > > > > > It could be but it needn't be, and the circumstance you > ask about is a > > > corner case which for example never applies to HBAs. > > > > > > > 8. fcmInstanceStatus could use an associated object to > > > get timestamp of the last state change > > > > > > While implementation feedback might tell us that, I think it's too > > > soon to be sure. So, let's save this comment until we update > > > the MIB from > > > Proposed to Draft Standard. > > > > > > > 9. fcmInstanceStatus doesn't seem to be implementable in > > > a consistent way across vendors. Needs better definition > > > > ideally this state is defined in the underlying > > > technology specifications. > > > > > > On the contrary, a) there is no one underlying > technology, and b) the > > > underlying technology specifications are the subject of > future MIBs, > > > not this one. This object serves as a generic summary of the > > > underlying > > > specifics (e.g., somewhat like ifOperStatus does for an > interface.) > > > > > > > 10. fcmInstanceTextName/fcmInstanceDescr, are there any > > > DEFAULT values for these? Suspect vendor implementations will > > > > provide something. Better to define the intended > > > purpose of these objects better. > > > > "A textual name for this management instance > > > and the Fibre > > > > Channel entity/entities that it is managing." > > > > might be > > > > "A textual name for this management instance > > > and the Fibre > > > > Channel entity/entities that it is managing set > > > by the operator or to a default string "XXXX" by the device." > > > > > > "XXXX" can not be specified in this MIB without restricting > > > the necessary > > > flexibility, anything that could be specified in this MIB > would not be > > > specific enough. The whole idea of this object is to be the > > > name specified > > > by the operator/NM-app, to have a default value changes > the semantics. > > > > > > > 11. fcmPortAdminType - Assuming a valid value change > > > can't be done for some device resource specific case, how can > > > > the error be reported? A generic > > > snmp error to the set is necessary but not sufficient I think. > > > > > > Why would it not be sufficient ?? > > > > cause genErr is also used for other (unspecified) errors. > > Maybe this could be spelled out that the best would be to sent an > > inconsistentValue error? > > This comment applies to every read-write/read-create in this and every > other MIB. To explain when to return which error status for > a SetRequest > requires most of pages 20-22 of RFC 3416 to be included in > the DESCRIPTION > of each such MIB object, and that doesn't make sense. > > It seems to me that the thing which prompted this comment was the > second sentence in the DESCRIPTION: > > "The administratively desired type of this port. > Each port > will typically only be able to support a subset > of these types." > > Is it really necessary for me to remove the second sentence ?? > Mike... you raised it? > > > > 12. Not sure why these object's syntax wasn't a TC? They > > > will probably be added to in time as well. > > > > fcmPortCapProtocols > > > > fcmPortTransmitterType > > > > fcmPortConnectorType -- this should probably > > > follow the MAU-MIB convention or we need to standardize 'JackType' > > > > in a new TC mib as > > > there is now overlap... > > > > > > Actually, not for the latter two because they are not generic > > > definitions. > > > Rather they are the specific enumerations listed for the > function in > > > T11's GS-3 speciofication. Sicne a future revision of > the GS-3 spec > > > could revise them individually, they cannot be defined as > common TCs. > > > The first one could, but I don't see any rule that it > violates which > > > would justify a change at this time. > > > > > A change is justified as much as no change. My personal opinion. > > Is it a MSUT change? no it is not. > > > > > > 13. fcmPortStatsTable doesn't have an explicitly > > > specified discontinuity object -- is ifXTable entry the one > > > that applies? > > > > > > Yes. > > > > Then you want to state that in DESCRIPTION clause(s) > > I've added this to all tables which have CounterNn objects. > > > > > Also, the counters described here should > > > have REFERNCE clauses to counters defined in the underlying > > > technology > > > > specs. While the descriptions are generally > > > good, they do not cover all possible cases when > > > > one should be incremented or not -- that > > > leads to incompatible implementations. > > > > > > Many of them are not specifically defined in any Fibre Channel > > > specification. If any are ambiguous, please suggest alternative > > > wording. Otherwise, I suggest we wait for implementation > feedback. > > > > > > > 14. fcmPortLcStatsTable doesn't have split counters? Is > > > a SNMPv1 agent then really useful when running high speed > interfaces? > > > > > > No, but at the time (several years ago now) when this was > discussed > > > in the WG, many Storage vendors only had SNMPv1 agents, and as a > > > result, this table was defined at the explicit direction > of the WG. > > > > > I.e. to force them to SNMPv3? FIne by me! > > > > > > DESCRIPTION > > > > "A list of Counter32-based statistics which are > > > a shadow of > > > > the Counter64 statistics in the > fcmPortStatsTable, for > > > > systems which do not support Counter64." > > > > I suggest the text mention it should "shadow" the > > > lower 32 bits? > > > > > > If that isn't what "shadow" means, then I don't know what it > > > does mean, and we shouldn't use the term at all. > > > > > I prefer if you spell out they contain the low order 32 bits. > > I removed the phrase containing "shadow". > I do not think that addresses our concerns. For an SNMPv1 manager which obtains those. I bet they are the lower32 bits of the Counter64. What is so darn difficult to spell it out? > > > > 15. If errors are not so common an occurance across > > > instances, the fcmPortErrorsTable might benefit from a > > > *LastChange object > > > > so not all objects have to be polled to determine > > > any error state change. Alternately provide a summary counter that > > > > is a simple sum of the number of errors. That should > > > allow for better scaling of this table for mgmt polling using > > > SNMP/UDP. > > > > > > The summary counter for many of these is already available: > > > ifInErrors. > > > > > > > 16. Error table should have REFERENCE clauses to point > > > out where in the underlying spec these counters are defined. > > > > This appears to be done, but is inconsistent. > > > fcmPortLinkFailures has a REFERENCE but fcmPortLinkResets wasn't? > > > > > > As I recall, it is consistent; specifically, all those for which > > > there is an appropriate section to reference have a > REFERENCE clause. > > > > > > > 17. fcmFxPortTable needs a discontinutity object. if > > > fcmPortOperType is changed from Fx to some other then back within > > > > a given polling interval, the data collected from > > > this table will be incorrect. > > > > > > No, because there are no Counter-based objects in this table. > > > > > > > 18. Objects in fcmFxPortTable, fcmFLoginTable could use > > > REFERENCE clauses. > > > > > > Sigh !! I will look again to see what I can find. > > > > > > > 19. fcmFLoginNxPortIndex doesn't specify what behaviors > > > should be across SNMP agent reset or system reboots like > > > > fcmInstanceIndex is required to do. So I'm a bit > > > concerned what the indexing looks like for all the tables on > > > > system reset or agent reset. > > > > > > I will add a sentence saying that after a value of > > > fcmFLoginNxPortIndex > > > is assigned to a particular Nx_Port, it can be re-used > when and only > > > when it is assigned to the same Nx_Port, or, after a reset of > > > the value > > > of the relevant instance of ifCounterDiscontinuityTime. > > > > > > > 20. fcmLinkEnd2AgentAddress OBJECT-TYPE is SYNTAX > > > SnmpAdminString, not InetAddressType? Why? > > > > > > Because the value is received from the otrher end of the > > > link, and if the > > > other end supplies a bogus value,m then that bpgus value > > > needs to be stored > > > in the MIB. > > > > So in that case it can be stored with InetAddressType "unknown" and > > the value that you received in the InetAddress, no? > > No. The GS-3 spec gives, as an example, the use of a URL in this > string, with the URL being for an SNMP, or HTTP or XML agent. > I've added some words to the DESCRIPTION stating this. > Look much better already. How can I get access to the GS-3 spec? > > So I do not see a reason to NOT use InetAddress(Type) combo. > > > > 21. > > > > > > > > End of Report > > > > > > > > An additional remark from me: > > > > I strongly recommend to rename DomainIdOrZero to FcDomainIdOrZero. > > The current definition of the TC is certainly not a generic DomainId > > definition is it? > > Agreed. DomainIdOrZero is FC-specific, and so it was my mistake to > call it DomainIdOrZero. > Peace. When I do SMICng, I get: W: f(fcmgmt.mi2), (2211,1) OBJECT-GROUP "fcmLinkBasicGroup" is not used in a MODULE-COMPLIANCE in current module That probably means that this is an optional GROUP. We recommend in mib review guidelines to include it in a MODULE_COMPLIANCE and spell out that it is optional. This to make it clear that it is intentional instead of accidental. Bert > Keith. > _______________________________________________ Ips mailing list Ips@ietf.org https://www1.ietf.org/mailman/listinfo/ips From exim@www1.ietf.org Tue Mar 23 19:23:08 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA14085 for ; Tue, 23 Mar 2004 19:23:08 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B5wAJ-0007je-HH for ips-archive@odin.ietf.org; Tue, 23 Mar 2004 19:22:39 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i2O0Mdwg029735 for ips-archive@odin.ietf.org; Tue, 23 Mar 2004 19:22:39 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B5wAJ-0007jW-7p for ips-web-archive@optimus.ietf.org; Tue, 23 Mar 2004 19:22:39 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA14057 for ; Tue, 23 Mar 2004 19:22:37 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B5wAH-0005fU-00 for ips-web-archive@ietf.org; Tue, 23 Mar 2004 19:22:37 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B5w9V-0005b6-00 for ips-web-archive@ietf.org; Tue, 23 Mar 2004 19:21:50 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1B5w8l-0005W6-00 for ips-web-archive@ietf.org; Tue, 23 Mar 2004 19:21:03 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B5w8j-0007MP-8h; Tue, 23 Mar 2004 19:21:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B5w8b-0007Ld-Kz for ips@optimus.ietf.org; Tue, 23 Mar 2004 19:20:53 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA13969 for ; Tue, 23 Mar 2004 19:20:52 -0500 (EST) From: Black_David@emc.com Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B5w8a-0005U1-00 for ips@ietf.org; Tue, 23 Mar 2004 19:20:52 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B5w7a-0005O7-00 for ips@ietf.org; Tue, 23 Mar 2004 19:19:50 -0500 Received: from mxic2.corp.emc.com ([128.221.12.9]) by ietf-mx with esmtp (Exim 4.12) id 1B5w7A-0005IZ-00 for ips@ietf.org; Tue, 23 Mar 2004 19:19:24 -0500 Received: by mxic2.corp.emc.com with Internet Mail Service (5.5.2653.19) id ; Tue, 23 Mar 2004 19:18:46 -0500 Message-ID: To: ips@ietf.org Date: Tue, 23 Mar 2004 19:17:29 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain Subject: [Ips] SCSI MIB status update Sender: ips-admin@ietf.org Errors-To: ips-admin@ietf.org 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: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.3 required=5.0 tests=AWL,NO_REAL_NAME autolearn=no version=2.60 The recent status of drafts email said: > -- SCSI MIB > > draft-ietf-ips-scsi-mib-06.txt > To be a proposed standard RFC. Has completed WG Last Call been > revised to address issues found by the WG's MIB expert. Has been > forwarded to ADs/IESG. Currently in Expert Review. It has been pointed out that this is incorrect, as Expert Review comments have been received for this MIB. See: https://www1.ietf.org/mail-archive/working-groups/ips/current/msg00318.html So, the summary of MIB status should be: - 4 MIBs have completed WG Last Call with all technical issues resolved and are in Expert Review at the IESG. - 2 MIBs have completed Expert Review and need to be revised to respond to the Expert Review Comments. instead of 5 and 1. The SCSI MIB authors have been asked to produce a new draft to respond to these comments. I apologize for the oversight. Thanks, --David ---------------------------------------------------- David L. Black, Senior Technologist EMC Corporation, 176 South St., Hopkinton, MA 01748 +1 (508) 293-7953 FAX: +1 (508) 293-7786 black_david@emc.com Mobile: +1 (978) 394-7754 ---------------------------------------------------- _______________________________________________ Ips mailing list Ips@ietf.org https://www1.ietf.org/mailman/listinfo/ips From exim@www1.ietf.org Tue Mar 23 22:50:25 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA23196 for ; Tue, 23 Mar 2004 22:50:24 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B5zOw-00015A-0T for ips-archive@odin.ietf.org; Tue, 23 Mar 2004 22:49:58 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i2O3nv0X004160 for ips-archive@odin.ietf.org; Tue, 23 Mar 2004 22:49:57 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B5zOv-000151-OV for ips-web-archive@optimus.ietf.org; Tue, 23 Mar 2004 22:49:57 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA23143 for ; Tue, 23 Mar 2004 22:49:53 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B5zOs-0001h3-00 for ips-web-archive@ietf.org; Tue, 23 Mar 2004 22:49:54 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B5zO0-0001WP-00 for ips-web-archive@ietf.org; Tue, 23 Mar 2004 22:49:01 -0500 Received: from [65.246.255.50] (helo=mx2.foretec.com) by ietf-mx with esmtp (Exim 4.12) id 1B5zNH-0001QD-01 for ips-web-archive@ietf.org; Tue, 23 Mar 2004 22:48:15 -0500 Received: from optimus22.ietf.org ([132.151.6.22] helo=optimus.ietf.org) by mx2.foretec.com with esmtp (Exim 4.24) id 1B5zJF-0000EB-2i for ips-web-archive@ietf.org; Tue, 23 Mar 2004 22:44:05 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B5zJB-0000oy-6v; Tue, 23 Mar 2004 22:44:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B5zIs-0000ok-Uv for ips@optimus.ietf.org; Tue, 23 Mar 2004 22:43:43 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA22962 for ; Tue, 23 Mar 2004 22:43:38 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B5zIp-000191-00 for ips@ietf.org; Tue, 23 Mar 2004 22:43:39 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B5zHs-000158-00 for ips@ietf.org; Tue, 23 Mar 2004 22:42:42 -0500 Received: from sj-iport-4.cisco.com ([171.68.10.86]) by ietf-mx with esmtp (Exim 4.12) id 1B5zHS-000121-00 for ips@ietf.org; Tue, 23 Mar 2004 22:42:15 -0500 Received: from cisco.com (cypher.cisco.com [171.69.11.143]) by sj-core-3.cisco.com (8.12.10/8.12.6) with ESMTP id i2O3fgBB006827; Tue, 23 Mar 2004 19:41:42 -0800 (PST) Received: (from kzm@localhost) by cisco.com (8.8.8/2.6/Cisco List Logging/8.8.8) id TAA25165; Tue, 23 Mar 2004 19:41:41 -0800 (PST) From: Keith McCloghrie Message-Id: <200403240341.TAA25165@cisco.com> Subject: Re: [Ips] FW: Initial review of http://www.ietf.org/internet-draf To: bwijnen@lucent.com ("Wijnen, Bert (Bert)") Date: Tue, 23 Mar 2004 19:41:41 -0800 (PST) Cc: kzm@cisco.com (Keith McCloghrie), ips@ietf.org, bwijnen@lucent.com, mrm@kazeon.com, mankin@psg.com In-Reply-To: <7D5D48D2CAA3D84C813F5B154F43B15503DB11C5@nl0006exch001u.nl.lucent.com> from "Wijnen, Bert (Bert)" at Mar 23, 2004 10:50:49 PM X-Mailer: ELM [version 2.5 PL1] MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: ips-admin@ietf.org Errors-To: ips-admin@ietf.org 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: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit > First, I still see: > > ::= { mib-2 999999 } -- to be assigned by IANA > > Keith, you know VERY WELL I think that we do NOT want that. > The strongly recommended notation is: > > ::= { mib-2 xxx } -- to be assigned by IANA Sorry. I hadn't noticed it; presumably, it's been 999999 for at least the last 2+ years. I've changed it, and I'm hopeful it will change again in the near future. > > > I think the warning is cause by the fact that there is no > > > DISPLAY-HINT. Can you add those? > > > > I can't because, as far as I know, there is no standard format for > > displaying these. Anyway, RFC 2579 says that DISPLAY-HINT is > > optional. > > So, this is another bug in that compiler. Why is the IETF's > > MIB review process relying upon a buggy compiler ?? > > OK, I asked "can you add those?" I did not say "you MUST add those". > AS you note, they are optional. However the set of current MIB doctors > have composed a set of guidelines for review, and document > draft-ietf-ops-mib-review-guidelines-02.txt > represents the current guidelines and sect 4.6.3 recommends to add > a DISPLAY HINT: > > 4.6.3. DISPLAY-HINT Clause > > The DISPLAY-HINT clause is used in a TC to provide a non-binding hint > to a management application as to how the value of an instance of an > object defined with the syntax in the TC might be displayed. Its > presence is optional. > > Although management applications typically default to decimal format > ("d") for integer TCs which are not enumerations and to a hexadecimal > format ("1x:" or "1x " or "1x_") for octet string TCs when the > DISPLAY-HINT clause is absent, it should be noted that SMIv2 does not > actually specify any defaults. MIB authors should be aware that a > clear hint is provided to applications only when the DISPLAY-HINT > clause is present. > > So... Can you add one please. I already answered: no because I don't know what the correct hint is. > If nothing else, then use "d" Why, if it might be wrong ?? Note that DISPLAY-HINT has always been a compromise between being simple versus being powerful. That is, DISPLAY-HINT was intentionally kept simple even though its simplicity prevents it from being able to represent complicated display formats. Specifically, it's not possible to express all display formats with DISPLAY-HINT, and thus, it makes no sense for it to be required. That's also why it's a "hint". > If you disagree with the mib-review guideline. pls speak up on > ietfmibs@ops.ietf.org list, so we can re-evaluate. This guidelines doc > is on its way to become a BCP. But I don't disagree, because as your quote says, with no ambiguity possible: Its presence is optional. > The compiler by the way only generates a warning, not an error! I'm confused. Why do you even get a warning for omitting something which is optional ? > > > > > 4. PhysicalIndexOrZero, HrSWInstalledIndexOrZero are > > > > > very useful and generally applicable to many mib modules. > > > > > They look strangly wrong being defined here and > > > > > should be defined in another TC, like Entity-MIB, or some > > > > > common TC-MIB. > > > > > > > > But they aren't, and thus, the best that this MIB module > > > > can do is to define the TC's itself. > > > > > > Could you rename them to RcPhysicalIndexOrZero and > > > FcHrSWInstalledIndexOrZero > > > so that they will not conflict if Entity MIB does define them later. > > > > There will be no conflict. First, the possibility of a descriptor > > clash is ever-present in practically every deployment because of > > Enterprise MIBs. Second, MIB compilers have to cope with it, and they > > do for the most part, although HP OpenView's compiler has had the same > > bug for the last ~10 years, and most often shows up because of > > OwnerString being defined as an OCTET STRING in IF-MIB and as a > > DisplayString in RMON-MIB; if you delete one of the two definitions or > > change them to both have the same syntax, OpenView stops complaining. > > > In principle we try to NOT get name clashes in STDs track MIB modules. > Of course we have goofed up a few times, and we want to try to avoid so > in the future, that is why I am asking (pretty serious) to consider the > name change and add the prefix. PLEASE! > > > > But... SURPRISE (maybe), pls take a look at > > > > > > draft-ietf-entmib-v3-04.txt > > > > > > and is on my AD plate for review!! So at least that one can be > > > imported from ENTITY-MIB. > > > > First, we don't want to risk any further delays. (In the update that I've > > just done, I changed the date from February 2003 to March 2004. In other > > words, we have waited 13 months for the benefit of the minor changes that > > I'm making now :-(.) So, let's not import from > > draft-ietf-entmib-v3-04.txt. > > > If you do not want to IMPORT from entmibv3, I can accept that. I may want > to re-open that if that entmib docs ends up as RFC earlier than yours. > > But it DOES again show that you better add the requested prefix to the > TC names. > > > Second, as you may have noticed all(*) the FC-specific TC's in this MIB > > are already prefixed with "Fc", and none of the generic TC's are > > prefixed with "Fc". I want to keep it that way, and since neither of > > PhysicalIndexOrZero or HrSWInstalledIndexOrZero are FC-specific, I've > > just deleted them. (* -- actually, all but one because I made a > > mistake with DomainIdOrZero.) > > > So you have removed them I see. Right, and therefore they won't conflict, which was your concern. > And you have instead used Integer32. > Although this is perfectly legal SMIv2, I think you understand VERY WELL > that this is against the spirit of what we are trying to do with TCs. I used Integer32 because that is the correct syntax in this case. Specifically, it would be an error to define them with Unsigned32 because both values are constrained by the syntax of the index objects which they reference, as defined in RFCs 2737 and 2790 respectively. > If that is the way you want to go... fine, I guess we should make the docs > informational or experimental and then you can do whatever you want > as long as the SMIv2 use is legal to the letter instead of to teh spirit. > > > > > > 5. MicroSeconds, MilliSeconds should also be in some > > > > generic tc-mib... > > > > > > > > But they aren't, and thus, the best that this MIB module > > > > can do is to define the TC's itself. > > > > > > Well, the SSPM-MIB (draft-ietf-rmonmib-sspm-mib-11.txt) which is in > > > IETF Last Call DOES have a SspmMicroSeconds TC. > > > I made them prefix with Sspm.. because I do foresee a future generic > > > TC MIB for these things. So if you want to keep them in this MIB > > > module I strongly recommend to name it FcMicroSeconds and FcMilliSeconds. > > > > Again, naming them FcMilliseconds and FcMicroseconds would give the > > reader the wromng impression. These are NOT Fibre Channel units; they are > > generic units. Fibre Channel's milliseconds/microseconds are NO different > > from any other technology's milliseconds/microseconds. Nevertheless, > > because of the comment, I've deleted the two TC's. > > And again use a plain Integer32 instead. OK... you win You're right that Integer32 would be a mistake for these. So, I went to change them, but I found that I had previously changed all six of them to Unsigned32. However, in searching for other Integer32's, I found FcDataFieldSize, FcBbCredit and FcDomainIdOrZero are defined as Integer32's. I think I inherited these when I started on this MIB nearly 3 years ago. Nevertheless, while they seem to be in the "it's acceptable" category in draft-ietf-ops-mib-review-guidelines, I'd be happy to change these three TC's to Unsigned32's if you want ?? > > > > > 6. fcmInstanceIndex DESCRIPTION is problematic for me. > > > > Either it stays static or it doesn't. > > > > > Having something "desireable" is worthless to those > > > > writing mangement applications, they have to assume worst > > > > case always. > > > > > > > > Not worthless, because if agent implementors heed the advice, > > > > then mgmt > > > > apps can coded to check whether the index values have > > > > been retained > > > > over the last restart, and only if not, do they need to > > > > re-synchronize > > > > their database. That is, it is an optimization for the > > > > common case of > > > > index values being retained, but the fallback still works > > > > in the case > > > > (hopefully less common) when all knowledge of index > > > > values is lost. > > > > > > So would it make sense to phrase it with a SHOULD ?? > > > > It wouldn't make sense to say a system SHOULD retain the > > values if all of > > its non-volatile memory is replaced, i.e., to say that it > > should when we > > know there are circumstances when it can't !! > > > Would it be better then to just say instead of "desirable" to add > a sentence that says somethink aka > "This should no tbe taken as an easy excuse to ignore the desire > for keeping the value constant across restarts" > We did a similar thing for commitFailed and undoFailed. I've reworded it to: It is mandatory to keep this value constant between restarts of the agent, and to make every possible effort to keep it constant across restarts (but note, it is unrealistic to expect it to remain constant across all re-configurations of the local system, e.g., across the replacement of all non-volatile storage). > > "The administratively desired type of this port. > > Each port > > will typically only be able to support a subset > > of these types." > > > > Is it really necessary for me to remove the second sentence ?? > > > Mike... you raised it? I've removed it anyway. > > > > > DESCRIPTION > > > > > "A list of Counter32-based statistics which are > > > > a shadow of > > > > > the Counter64 statistics in the > > fcmPortStatsTable, for > > > > > systems which do not support Counter64." > > > > > I suggest the text mention it should "shadow" the > > > > lower 32 bits? > > > > > > > > If that isn't what "shadow" means, then I don't know what it > > > > does mean, and we shouldn't use the term at all. > > > > > > > I prefer if you spell out they contain the low order 32 bits. > > > > I removed the phrase containing "shadow". > > I do not think that addresses our concerns. > For an SNMPv1 manager which obtains those. I bet they are the lower32 bits > of the Counter64. What is so darn difficult to spell it out? It would be easy to "spell it out" (easier than arguing about it :-), but that doesn't make it right. While it's a likely and reasonable implementation strategy, there's no advantage in requiring it. Specifically, who cares whether they are the lower 32 bits?? An SNMPv1 manager reading them isn't going to care (because it can't read the Counter64's), and neither will an SNMPv2c/SNMPv3 manager because the Counter32's are redundant as far as it's concerned. [Aside: this reminds me of the old story about conformance testing with X.25. Even though most of the original X.25 implementations passed the conformance test, none of them interoperated with each other. In other words, any tests of these Counters should check that their values accurately reflect their semantics, and we should not provide fuel for a worthless conformance test which would compare the low32 bits of the Counter64 with the Counter32's value.] > > > So in that case it can be stored with InetAddressType "unknown" and > > > the value that you received in the InetAddress, no? > > > > No. The GS-3 spec gives, as an example, the use of a URL in this > > string, with the URL being for an SNMP, or HTTP or XML agent. > > I've added some words to the DESCRIPTION stating this. > > > Look much better already. > How can I get access to the GS-3 spec? I'll send you a URL in another message. > > > So I do not see a reason to NOT use InetAddress(Type) combo. > > > > > 21. > > > > > > > > > > End of Report > > > > > > > > > > > An additional remark from me: > > > > > > I strongly recommend to rename DomainIdOrZero to FcDomainIdOrZero. > > > The current definition of the TC is certainly not a generic DomainId > > > definition is it? > > > > Agreed. DomainIdOrZero is FC-specific, and so it was my mistake to > > call it DomainIdOrZero. > > > Peace. > > When I do SMICng, I get: > > W: f(fcmgmt.mi2), (2211,1) OBJECT-GROUP "fcmLinkBasicGroup" is not > used in a MODULE-COMPLIANCE in current module > > That probably means that this is an optional GROUP. We recommend in mib > review guidelines to include it in a MODULE_COMPLIANCE and spell out that > it is optional. This to make it clear that it is intentional instead > of accidental. I had added it at the end, after the OBJECT statements, but I've now moved it to be next to the other GROUP statements. Does that stop SMICng from complaining ?? The updated version is in the same place: ftp://ftpeng.cisco.com/ftp/kzm/pub/draft-ietf-ips-fcmgmt-mib-05.txt Keith. _______________________________________________ Ips mailing list Ips@ietf.org https://www1.ietf.org/mailman/listinfo/ips From exim@www1.ietf.org Thu Mar 25 13:55:53 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA13735 for ; Thu, 25 Mar 2004 13:55:53 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B6a0k-0001g0-6P for ips-archive@odin.ietf.org; Thu, 25 Mar 2004 13:55:26 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i2PItQ8q006440 for ips-archive@odin.ietf.org; Thu, 25 Mar 2004 13:55:26 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B6a0k-0001fn-0w for ips-web-archive@optimus.ietf.org; Thu, 25 Mar 2004 13:55:26 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA13728 for ; Thu, 25 Mar 2004 13:55:23 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B6a0h-000013-00 for ips-web-archive@ietf.org; Thu, 25 Mar 2004 13:55:23 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B6Zzq-0007nT-00 for ips-web-archive@ietf.org; Thu, 25 Mar 2004 13:54:30 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1B6Zz0-0007lW-00 for ips-web-archive@ietf.org; Thu, 25 Mar 2004 13:53:38 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B6Zyw-0001U4-CZ; Thu, 25 Mar 2004 13:53:34 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B6Zxs-0001OH-4V for ips@optimus.ietf.org; Thu, 25 Mar 2004 13:52:28 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA13654 for ; Thu, 25 Mar 2004 13:52:25 -0500 (EST) From: kevin_lemay@agilent.com Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B6Zxp-0007hG-00 for ips@ietf.org; Thu, 25 Mar 2004 13:52:25 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B6Zww-0007fQ-00 for ips@ietf.org; Thu, 25 Mar 2004 13:51:31 -0500 Received: from msgbas1tx.cos.agilent.com ([192.25.240.37] helo=msgbas2x.cos.agilent.com) by ietf-mx with esmtp (Exim 4.12) id 1B6Zw6-0007dE-00 for ips@ietf.org; Thu, 25 Mar 2004 13:50:39 -0500 Received: from relcos2.cos.agilent.com (relcos2.cos.agilent.com [130.29.152.237]) by msgbas2x.cos.agilent.com (Postfix) with ESMTP id 0CE227E3D for ; Thu, 25 Mar 2004 11:50:39 -0700 (MST) Received: from wcosbh22.cos.agilent.com (wcosbh22.cos.agilent.com [130.29.152.178]) by relcos2.cos.agilent.com (Postfix) with ESMTP id E73632D4 for ; Thu, 25 Mar 2004 11:50:38 -0700 (MST) Received: from wcosmb02.cos.agilent.com ([130.29.152.96]) by wcosbh22.cos.agilent.com with Microsoft SMTPSVC(5.0.2195.6713); Thu, 25 Mar 2004 11:50:38 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.0.6487.1 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: [Ips] What iSNS servers are available for interop testing? Date: Thu, 25 Mar 2004 11:50:34 -0700 Message-ID: <9AB7C093B52FEE4EB66BAE9BE58A32730E55CC@wcosmb02.cos.agilent.com> Thread-Topic: [Ips] March 2004 Status of Drafts Thread-Index: AcQQ5cEGlXWVmqtxQ6Wo9Auj4CM1cgBs8rQQ To: X-OriginalArrivalTime: 25 Mar 2004 18:50:38.0624 (UTC) FILETIME=[109D8A00:01C4129A] Content-Transfer-Encoding: quoted-printable Sender: ips-admin@ietf.org Errors-To: ips-admin@ietf.org 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: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.3 required=5.0 tests=NO_REAL_NAME autolearn=no version=2.60 Content-Transfer-Encoding: quoted-printable Content-Transfer-Encoding: quoted-printable I am looking for iSNS servers for interop testing with our client. Please let me know if you have a current iSNS server that you would be = willing to share. Thank you, Kevin Lemay _______________________________________________ Ips mailing list Ips@ietf.org https://www1.ietf.org/mailman/listinfo/ips From exim@www1.ietf.org Thu Mar 25 14:18:04 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA14577 for ; Thu, 25 Mar 2004 14:18:04 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B6aMD-00044l-3j for ips-archive@odin.ietf.org; Thu, 25 Mar 2004 14:17:37 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i2PJHb7O015667 for ips-archive@odin.ietf.org; Thu, 25 Mar 2004 14:17:37 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B6aMC-00044c-OD for ips-web-archive@optimus.ietf.org; Thu, 25 Mar 2004 14:17:36 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA14548 for ; Thu, 25 Mar 2004 14:17:33 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B6aMA-0001LP-00 for ips-web-archive@ietf.org; Thu, 25 Mar 2004 14:17:34 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B6aLK-0001IV-00 for ips-web-archive@ietf.org; Thu, 25 Mar 2004 14:16:43 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1B6aKW-0001EO-00 for ips-web-archive@ietf.org; Thu, 25 Mar 2004 14:15:52 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B6aKX-0003u0-Gm; Thu, 25 Mar 2004 14:15:53 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B6aJJ-0003f3-Ri for ips@optimus.ietf.org; Thu, 25 Mar 2004 14:14:38 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA14467 for ; Thu, 25 Mar 2004 14:14:34 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B6aJH-00017e-00 for ips@ietf.org; Thu, 25 Mar 2004 14:14:35 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B6aIX-00014n-00 for ips@ietf.org; Thu, 25 Mar 2004 14:13:49 -0500 Received: from sj-iport-4.cisco.com ([171.68.10.86]) by ietf-mx with esmtp (Exim 4.12) id 1B6aHu-0000yN-00 for ips@ietf.org; Thu, 25 Mar 2004 14:13:10 -0500 Received: from cisco.com (cypher.cisco.com [171.69.11.143]) by sj-core-5.cisco.com (8.12.10/8.12.6) with ESMTP id i2PJCaGX010972; Thu, 25 Mar 2004 11:12:36 -0800 (PST) Received: (from kzm@localhost) by cisco.com (8.8.8/2.6/Cisco List Logging/8.8.8) id LAA23895; Thu, 25 Mar 2004 11:12:35 -0800 (PST) From: Keith McCloghrie Message-Id: <200403251912.LAA23895@cisco.com> To: ips@ietf.org Date: Thu, 25 Mar 2004 11:12:35 -0800 (PST) Cc: bwijnen@lucent.com, mrm@kazeon.com, mankin@psg.com, Elizabeth.Rodriguez@dothill.com, Black_David@emc.com, kzm@cisco.com (Keith McCloghrie) X-Mailer: ELM [version 2.5 PL1] MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Subject: [Ips] Request from T11.5 for editorial cleanup Sender: ips-admin@ietf.org Errors-To: ips-admin@ietf.org 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: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Hi, As you will have seen from recent messages to this list, a few changes are required to draft-ietf-ips-fcmgmt-mib-04.txt as a result of the IESG Expert Review process. Meanwhile, I received the message below from Roger on behalf of T11.5. Your WG chairs and I agree with Roger that these are purely editorial clarifications, and that consistency with FC-SWAPI is a good thing. So, I've taken the liberty of updating the draft as requested. The latest draft can be found at: ftp://ftpeng.cisco.com/ftp/kzm/pub/draft-ietf-ips-fcmgmt-mib-05.txt In due course, I will be submitting the latest draft as a new I-D. If you have any concerns, please speak up. Thanks, Keith. -------------- Forwarded message: > From: Roger Cummings > Message-ID: <8BE017CC8923D511A00A0008C78605EE0906084C@LMOXCH04> > To: Keith McCloghrie > Cc: Elizabeth Rodriguez , black_david@emc.com > Subject: Issues with FC Management MIB > Date: Fri, 12 Mar 2004 15:14:41 -0500 > > Keith, > > At a recent conference call reviewing Letter Ballot comments on one of the > T11.5 API projects, called FC-SWAPI, it was noted that clarifications of the > definitions of several of the objects defined in the API should probably be > reflected in the FC Management MIB. > > The specific SWAPI objects, and their clarified definitions are : > > 1) SWAPI_STATS_LBL_RLRS > > Count of Link resets. This is the number of Link Reset (LR) Primitive > Sequences received. > > 2) SWAPI_STATS_LBL_TLRS > > Count of Link resets. This is the number of Link Reset (LR) Primitive > Sequences transmitted. > > 4) SWAPI_STATS_LBL_ROLS > > Count of Offline (OLS) Primitive Sequences received at this port. > > 5) SWAPI_STATS_LBL_TOLS > > Count of Offline (OLS) Primitive Sequences transmitted by this port. > > > The corresponding definitions in draft-ietf-ips-fcmgmt-mib-04.txt are: > > fcmPortRxLinkResets OBJECT-TYPE > > DESCRIPTION > "The number of Link resets (LR primitives) received." > > fcmPortTxLinkResets OBJECT-TYPE > DESCRIPTION > "The number of Link resets (LRs primitive) transmitted." > > fcmPortRxOfflineSequences OBJECT-TYPE > > DESCRIPTION > "The number of Offline Primitive OLS received at this port." > fcmPortTxOfflineSequences OBJECT-TYPE > > DESCRIPTION > "The number of Offline Primitive OLS transmitted by this > port." > > The problem here is that all of these objects are defined as the number of > primitives, but LR and OLS are Primitive Sequences and not primitives. This > was not at all clear in earlier versions of SWAPI, and I suspect that may > have been what you based the definitions on. Primitive Sequences are already > referenced in the MIB in the fcmPortPrimSeqProtocolErrors object type. > > To make SWAPI & the FC Management MIB consistent, our suggestions would be: > > fcmPortRxLinkResets OBJECT-TYPE > > DESCRIPTION > > "The number of Link Reset (LR) Primitive Sequences received." > > > fcmPortTxLinkResets OBJECT-TYPE > DESCRIPTION > > "The number of Link Reset (LR) Primitive Sequences transmitted." > > > fcmPortRxOfflineSequences OBJECT-TYPE > > DESCRIPTION > > "The number of Offline (OLS) Primitive Sequences received at this port." > > > fcmPortTxOfflineSequences OBJECT-TYPE > > DESCRIPTION > > "The number of Offline (OLS) Primitive Sequences transmitted by this port." > > > I think that this can be regarded purely as editorial clarification, because > LR & OLS are clearly defined as Primitive Sequences in FC-FS. Is it too late > to make these changes to the MIB? Do you need me to submit these changes > "officially" as T11.5 Chair during IESG last call? > > Regards, > > > > > Roger Cummings > Chair, TG T11.5 > > roger.cummings@veritas.com > _______________________________________________ Ips mailing list Ips@ietf.org https://www1.ietf.org/mailman/listinfo/ips From exim@www1.ietf.org Fri Mar 26 18:04:00 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA23283 for ; Fri, 26 Mar 2004 18:04:00 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B70MP-0005AJ-Bi for ips-archive@odin.ietf.org; Fri, 26 Mar 2004 18:03:33 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i2QN3Xlm019852 for ips-archive@odin.ietf.org; Fri, 26 Mar 2004 18:03:33 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B70MP-00059w-3J for ips-web-archive@optimus.ietf.org; Fri, 26 Mar 2004 18:03:33 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA23219 for ; Fri, 26 Mar 2004 18:03:29 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B70MM-00035v-00 for ips-web-archive@ietf.org; Fri, 26 Mar 2004 18:03:30 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B70Lh-00031o-00 for ips-web-archive@ietf.org; Fri, 26 Mar 2004 18:02:50 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1B70L0-0002uw-00 for ips-web-archive@ietf.org; Fri, 26 Mar 2004 18:02:06 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B70Kv-0003hg-80; Fri, 26 Mar 2004 18:02:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B70KE-0003CM-UC for ips@optimus.ietf.org; Fri, 26 Mar 2004 18:01:21 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA23010 for ; Fri, 26 Mar 2004 18:01:14 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B70KC-0002p7-00 for ips@ietf.org; Fri, 26 Mar 2004 18:01:16 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B70JK-0002hu-00 for ips@ietf.org; Fri, 26 Mar 2004 18:00:24 -0500 Received: from f112.brocade.com ([66.243.153.112] helo=blasphemy.brocade.com) by ietf-mx with esmtp (Exim 4.12) id 1B70IJ-0002RG-00 for ips@ietf.org; Fri, 26 Mar 2004 17:59:19 -0500 Received: from hq-ex-11.corp.brocade.com (hq-ex-11 [192.168.38.58]) by blasphemy.brocade.com (Postfix) with ESMTP id E73B1142E9; Fri, 26 Mar 2004 14:58:48 -0800 (PST) X-MimeOLE: Produced By Microsoft Exchange V6.0.6487.1 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [Ips] Request from T11.5 for editorial cleanup Date: Fri, 26 Mar 2004 14:58:48 -0800 Message-ID: <191DA4FAE235D24C9BCC8D50F6B17AB9093352@hq-ex-11.corp.brocade.com> Thread-Topic: [Ips] Request from T11.5 for editorial cleanup Thread-Index: AcQSnbZ/okh+SZORT0CcRzPy1kYV2gA3mRjQ From: "Robert Snively" To: "Keith McCloghrie" , , "T11_5 (E-mail)" Cc: , , , , Content-Transfer-Encoding: quoted-printable Sender: ips-admin@ietf.org Errors-To: ips-admin@ietf.org 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: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=AWL autolearn=no version=2.60 Content-Transfer-Encoding: quoted-printable Content-Transfer-Encoding: quoted-printable Keith, Internal review by Brocade specialists has identified the following=20 questions and suggestions about revision 5 of the document. 1) Fabric Name: In FC-SW-3, Clause 7.3, Principal Switch Selection states: =20 "The Switch_Name of the Principal Switch shall be=20 used as the Fabric_Name." In the MIB (fcmInstanceFabricId), it states:=20 "The globally unique Fabric Identifier which identifies the fabric to which the Fibre Channel entity/entities managed by this management instance are connected, or, of which they are a part. This is typically the Node WWN of the principal switch of a Fibre Channel fabric." The text should be changed to align with FC-SW-3 and indicate that the Fabric Identifier SHALL be the Node WWN of the principal switch.=20 2) Definition of port types under FcPortType: In FC-SW-3 two additional Port Types are defined, G_Port and GL_Port. =20 In FC-GS-4 a third Port Type of F/NL_Port is defined. Other collective ports are also defined by FC standards documents, but those are for documentation purposes=20 only, rather than defining functionality. Such ports include: Nx_Port (any port with N_Port or NL_Port capability) and FC_Port (any port capable of transceiving Fibre Channel frames). While those are actually specified as port types in FC-GS-4, that is probably an error that should be corrected in the next revision of that document. =09 The MIB has added the port type "dynamic", not defined by any of the T11 documents. It is suggested the "dynamic" port type be removed and that "gPort" and "glPort" be used in its place,=20 since that is the likely intent of the word "dynamic",=20 referring to a port which has not quite yet decided what it is=20 going to be, but has a defined protocol to make that determination. Use a port type of "unknown" when you cannot identify the port according to a standard. An additional port type of F/NL_Port ("fnlPort") should be=20 defined for applications that have that requirement. For reference, FC-SW-3 defines the G and GL_Ports as follows: 3.1.45 G_Port: A generic Fabric Port that may=20 function either as an E_Port, or as an F_Port. 3.1.46 GL_Port: A generic Fabric Port that may=20 function either as an E_Port, or as an Fx_Port. For reference, FC-GS-4 defines the F/NL_Port as follows: 3.2.19 F/NL_Port: An NL_Port that detects OPN(00,x)=20 and provides Fibre Channel services in the absence of an FL_Port (see FC-AL-2). Thank you very much for your attention, Sincerely, Robert Snively Brocade Communications Systems, Inc. 1745 Technology Drive San Jose, CA 95110 +1 408 333 8135 rsnively@brocade.com=20 > -----Original Message----- > From: ips-admin@ietf.org [mailto:ips-admin@ietf.org]On Behalf Of Keith > McCloghrie > Sent: Thursday, March 25, 2004 11:13 AM > To: ips@ietf.org > Cc: bwijnen@lucent.com; mrm@kazeon.com; mankin@psg.com; > Elizabeth.Rodriguez@dothill.com; Black_David@emc.com; kzm@cisco.com > Subject: [Ips] Request from T11.5 for editorial cleanup >=20 >=20 > Hi, >=20 > As you will have seen from recent messages to this list, a few changes > are required to draft-ietf-ips-fcmgmt-mib-04.txt as a result of the > IESG Expert Review process. >=20 > Meanwhile, I received the message below from Roger on behalf of T11.5. > Your WG chairs and I agree with Roger that these are purely editorial > clarifications, and that consistency with FC-SWAPI is a good thing. > So, I've taken the liberty of updating the draft as requested. >=20 > The latest draft can be found at: >=20 > ftp://ftpeng.cisco.com/ftp/kzm/pub/draft-ietf-ips-fcmgmt-mib-05.txt >=20 > In due course, I will be submitting the latest draft as a new I-D. > If you have any concerns, please speak up. >=20 > Thanks, > Keith. > -------------- > Forwarded message: > > From: Roger Cummings > > Message-ID: <8BE017CC8923D511A00A0008C78605EE0906084C@LMOXCH04> > > To: Keith McCloghrie > > Cc: Elizabeth Rodriguez ,=20 > black_david@emc.com > > Subject: Issues with FC Management MIB > > Date: Fri, 12 Mar 2004 15:14:41 -0500 > >=20 > > Keith, > >=20 > > At a recent conference call reviewing Letter Ballot=20 > comments on one of the > > T11.5 API projects, called FC-SWAPI, it was noted that=20 > clarifications of the > > definitions of several of the objects defined in the API=20 > should probably be > > reflected in the FC Management MIB.=20 > >=20 > > The specific SWAPI objects, and their clarified definitions are : > >=20 > > 1) SWAPI_STATS_LBL_RLRS > >=20 > > Count of Link resets. This is the number of Link Reset (LR)=20 > Primitive > > Sequences received. > >=20 > > 2) SWAPI_STATS_LBL_TLRS=20 > >=20 > > Count of Link resets. This is the number of Link Reset (LR)=20 > Primitive > > Sequences transmitted. > >=20 > > 4) SWAPI_STATS_LBL_ROLS > >=20 > > Count of Offline (OLS) Primitive Sequences received at this port. > >=20 > > 5) SWAPI_STATS_LBL_TOLS > >=20 > > Count of Offline (OLS) Primitive Sequences transmitted by this port. > >=20 > >=20 > > The corresponding definitions in=20 > draft-ietf-ips-fcmgmt-mib-04.txt are: > >=20 > > fcmPortRxLinkResets OBJECT-TYPE > > =20 > > DESCRIPTION > > "The number of Link resets (LR primitives) received." > >=20 > > fcmPortTxLinkResets OBJECT-TYPE > > DESCRIPTION > > "The number of Link resets (LRs primitive) transmitted." > >=20 > > fcmPortRxOfflineSequences OBJECT-TYPE > > =20 > > DESCRIPTION > > "The number of Offline Primitive OLS received=20 > at this port." > > fcmPortTxOfflineSequences OBJECT-TYPE > > =20 > > DESCRIPTION > > "The number of Offline Primitive OLS transmitted by this > > port." > >=20 > > The problem here is that all of these objects are defined=20 > as the number of > > primitives, but LR and OLS are Primitive Sequences and not=20 > primitives. This > > was not at all clear in earlier versions of SWAPI, and I=20 > suspect that may > > have been what you based the definitions on. Primitive=20 > Sequences are already > > referenced in the MIB in the fcmPortPrimSeqProtocolErrors=20 > object type. > >=20 > > To make SWAPI & the FC Management MIB consistent, our=20 > suggestions would be: > >=20 > > fcmPortRxLinkResets OBJECT-TYPE > > =20 > > DESCRIPTION > >=20 > > "The number of Link Reset (LR) Primitive Sequences received." > >=20 > >=20 > > fcmPortTxLinkResets OBJECT-TYPE > > DESCRIPTION > >=20 > > "The number of Link Reset (LR) Primitive Sequences transmitted." > > =20 > >=20 > > fcmPortRxOfflineSequences OBJECT-TYPE > > =20 > > DESCRIPTION > >=20 > > "The number of Offline (OLS) Primitive Sequences received=20 > at this port." > >=20 > >=20 > > fcmPortTxOfflineSequences OBJECT-TYPE > > =20 > > DESCRIPTION > >=20 > > "The number of Offline (OLS) Primitive Sequences=20 > transmitted by this port." > >=20 > >=20 > > I think that this can be regarded purely as editorial=20 > clarification, because > > LR & OLS are clearly defined as Primitive Sequences in=20 > FC-FS. Is it too late > > to make these changes to the MIB? Do you need me to submit=20 > these changes > > "officially" as T11.5 Chair during IESG last call? > >=20 > > Regards, > >=20 > >=20 > >=20 > >=20 > > Roger Cummings > > Chair, TG T11.5 > >=20 > > roger.cummings@veritas.com > >=20 >=20 >=20 > _______________________________________________ > Ips mailing list > Ips@ietf.org > https://www1.ietf.org/mailman/listinfo/ips >=20 >=20 _______________________________________________ Ips mailing list Ips@ietf.org https://www1.ietf.org/mailman/listinfo/ips From exim@www1.ietf.org Sun Mar 28 01:37:56 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA19673 for ; Sun, 28 Mar 2004 01:37:56 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B7TvE-0001gs-6E for ips-archive@odin.ietf.org; Sun, 28 Mar 2004 01:37:28 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i2S6bS8g006494 for ips-archive@odin.ietf.org; Sun, 28 Mar 2004 01:37:28 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B7TvE-0001gX-0N for ips-web-archive@optimus.ietf.org; Sun, 28 Mar 2004 01:37:28 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA19668 for ; Sun, 28 Mar 2004 01:37:25 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B7TvA-0005i8-00 for ips-web-archive@ietf.org; Sun, 28 Mar 2004 01:37:24 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B7TuJ-0005bi-00 for ips-web-archive@ietf.org; Sun, 28 Mar 2004 01:36:31 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1B7Tts-0005Uw-00 for ips-web-archive@ietf.org; Sun, 28 Mar 2004 01:36:04 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B7Ttq-0001QU-2V; Sun, 28 Mar 2004 01:36:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B7TtA-0001Og-0G for ips@optimus.ietf.org; Sun, 28 Mar 2004 01:35:20 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA19581 for ; Sun, 28 Mar 2004 01:35:17 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B7Tt6-0005Rp-00 for ips@ietf.org; Sun, 28 Mar 2004 01:35:17 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B7Ts8-0005Jv-00 for ips@ietf.org; Sun, 28 Mar 2004 01:34:17 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1B7TrA-0005B9-00 for ips@ietf.org; Sun, 28 Mar 2004 01:33:16 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B7TrD-0001Ie-4r for ips@ietf.org; Sun, 28 Mar 2004 01:33:19 -0500 Received: (from nobody@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i2S6XJvF004998 for ips@ietf.org; Sun, 28 Mar 2004 01:33:19 -0500 Date: Sun, 28 Mar 2004 01:33:19 -0500 Message-Id: <200403280633.i2S6XJvF004998@www1.ietf.org> X-Authentication-Warning: www1.ietf.org: nobody set sender to iesg-secretary@ietf.org using -f From: Support Online To: ips@ietf.org Reply-To: iesg-secretary@ietf.org X-Loop: WREQ 2 Subject: [Ips] [iesg-secretary #24702] why should I? (Autoreply) Sender: ips-admin@ietf.org Errors-To: ips-admin@ietf.org 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: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.2 required=5.0 tests=AWL autolearn=no version=2.60 Your request of the subject why should I? has been received. If you have further email on this subject, please retain the subject: line (including the tracking number [ietf-action #xxx]) so that when you respond to ietf-action@ietf.org, the email goes in the same tracking ticket. Thank you. _______________________________________________ Ips mailing list Ips@ietf.org https://www1.ietf.org/mailman/listinfo/ips From exim@www1.ietf.org Sun Mar 28 20:12:41 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA15491 for ; Sun, 28 Mar 2004 20:12:41 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B7lK0-00044Q-Fb for ips-archive@odin.ietf.org; Sun, 28 Mar 2004 20:12:13 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i2T1CC9W015640 for ips-archive@odin.ietf.org; Sun, 28 Mar 2004 20:12:12 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B7lK0-00044B-8q for ips-web-archive@optimus.ietf.org; Sun, 28 Mar 2004 20:12:12 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA15467 for ; Sun, 28 Mar 2004 20:12:09 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B7lJy-0006wZ-00 for ips-web-archive@ietf.org; Sun, 28 Mar 2004 20:12:10 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B7lIz-0006oS-00 for ips-web-archive@ietf.org; Sun, 28 Mar 2004 20:11:10 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1B7lI7-0006gN-00 for ips-web-archive@ietf.org; Sun, 28 Mar 2004 20:10:15 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B7lHu-0003ZU-56; Sun, 28 Mar 2004 20:10:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B7lHq-0003YZ-N5 for ips@optimus.ietf.org; Sun, 28 Mar 2004 20:09:58 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA15419 for ; Sun, 28 Mar 2004 20:09:56 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B7lHo-0006fO-00 for ips@ietf.org; Sun, 28 Mar 2004 20:09:56 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B7lGt-0006ZZ-00 for ips@ietf.org; Sun, 28 Mar 2004 20:09:00 -0500 Received: from mail.kazeon.com ([209.172.74.40] helo=kazeon.com) by ietf-mx with esmtp (Exim 4.12) id 1B7lG5-0006T8-00 for ips@ietf.org; Sun, 28 Mar 2004 20:08:09 -0500 Content-class: urn:content-classes:message Date: Sun, 28 Mar 2004 17:08:00 -0800 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Message-ID: <4E022DDAB8F45741914ACD6EDFE2309B07EC42@BIGFOOT.kazeon.local> X-MimeOLE: Produced By Microsoft Exchange V6.5.6944.0 Thread-Topic: Request from T11.5 for editorial cleanup Thread-Index: AcQSnNv7z/BYVHh2RzmHL8d3OM4RCwCikxmw From: "Michael MacFaden" To: "Keith McCloghrie" , Cc: , , , Content-Transfer-Encoding: quoted-printable Subject: [Ips] RE: Request from T11.5 for editorial cleanup Sender: ips-admin@ietf.org Errors-To: ips-admin@ietf.org 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: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60 Content-Transfer-Encoding: quoted-printable Content-Transfer-Encoding: quoted-printable Keith, My comments on draft 5 can be found here: http://www.macfaden.com/ietf/fc-mgmt-mib-5-reviewed.txt I have no outstanding issues with this draft other than what is mentioned above. Mike MacFaden Kazeon Systems, Inc -----Original Message----- From: Keith McCloghrie [mailto:kzm@cisco.com]=20 Sent: Thursday, March 25, 2004 11:13 AM To: ips@ietf.org Cc: bwijnen@lucent.com; Michael MacFaden; mankin@psg.com; Elizabeth.Rodriguez@dothill.com; Black_David@emc.com; Keith McCloghrie Subject: Request from T11.5 for editorial cleanup Hi, As you will have seen from recent messages to this list, a few changes are required to draft-ietf-ips-fcmgmt-mib-04.txt as a result of the IESG Expert Review process. Meanwhile, I received the message below from Roger on behalf of T11.5. Your WG chairs and I agree with Roger that these are purely editorial clarifications, and that consistency with FC-SWAPI is a good thing. So, I've taken the liberty of updating the draft as requested. The latest draft can be found at: ftp://ftpeng.cisco.com/ftp/kzm/pub/draft-ietf-ips-fcmgmt-mib-05.txt In due course, I will be submitting the latest draft as a new I-D. If you have any concerns, please speak up. Thanks, Keith. -------------- Forwarded message: > From: Roger Cummings > Message-ID: <8BE017CC8923D511A00A0008C78605EE0906084C@LMOXCH04> > To: Keith McCloghrie > Cc: Elizabeth Rodriguez ,=20 > black_david@emc.com > Subject: Issues with FC Management MIB > Date: Fri, 12 Mar 2004 15:14:41 -0500 >=20 > Keith, >=20 > At a recent conference call reviewing Letter Ballot comments on one of > the > T11.5 API projects, called FC-SWAPI, it was noted that clarifications=20 > of the definitions of several of the objects defined in the API should > probably be reflected in the FC Management MIB. >=20 > The specific SWAPI objects, and their clarified definitions are : >=20 > 1) SWAPI_STATS_LBL_RLRS >=20 > Count of Link resets. This is the number of Link Reset (LR) Primitive=20 > Sequences received. >=20 > 2) SWAPI_STATS_LBL_TLRS >=20 > Count of Link resets. This is the number of Link Reset (LR) Primitive=20 > Sequences transmitted. >=20 > 4) SWAPI_STATS_LBL_ROLS >=20 > Count of Offline (OLS) Primitive Sequences received at this port. >=20 > 5) SWAPI_STATS_LBL_TOLS >=20 > Count of Offline (OLS) Primitive Sequences transmitted by this port. >=20 >=20 > The corresponding definitions in draft-ietf-ips-fcmgmt-mib-04.txt are: >=20 > fcmPortRxLinkResets OBJECT-TYPE > =20 > DESCRIPTION > "The number of Link resets (LR primitives) received." >=20 > fcmPortTxLinkResets OBJECT-TYPE > DESCRIPTION > "The number of Link resets (LRs primitive) transmitted." >=20 > fcmPortRxOfflineSequences OBJECT-TYPE > =20 > DESCRIPTION > "The number of Offline Primitive OLS received at this port." > fcmPortTxOfflineSequences OBJECT-TYPE > =20 > DESCRIPTION > "The number of Offline Primitive OLS transmitted by this > port." >=20 > The problem here is that all of these objects are defined as the=20 > number of primitives, but LR and OLS are Primitive Sequences and not=20 > primitives. This was not at all clear in earlier versions of SWAPI,=20 > and I suspect that may have been what you based the definitions on.=20 > Primitive Sequences are already referenced in the MIB in the fcmPortPrimSeqProtocolErrors object type. >=20 > To make SWAPI & the FC Management MIB consistent, our suggestions would be: >=20 > fcmPortRxLinkResets OBJECT-TYPE > =20 > DESCRIPTION >=20 > "The number of Link Reset (LR) Primitive Sequences received." >=20 >=20 > fcmPortTxLinkResets OBJECT-TYPE > DESCRIPTION >=20 > "The number of Link Reset (LR) Primitive Sequences transmitted." > =20 >=20 > fcmPortRxOfflineSequences OBJECT-TYPE > =20 > DESCRIPTION >=20 > "The number of Offline (OLS) Primitive Sequences received at this port." >=20 >=20 > fcmPortTxOfflineSequences OBJECT-TYPE > =20 > DESCRIPTION >=20 > "The number of Offline (OLS) Primitive Sequences transmitted by this port." >=20 >=20 > I think that this can be regarded purely as editorial clarification,=20 > because LR & OLS are clearly defined as Primitive Sequences in FC-FS.=20 > Is it too late to make these changes to the MIB? Do you need me to=20 > submit these changes "officially" as T11.5 Chair during IESG last call? >=20 > Regards, >=20 >=20 >=20 >=20 > Roger Cummings > Chair, TG T11.5 >=20 > roger.cummings@veritas.com >=20 _______________________________________________ Ips mailing list Ips@ietf.org https://www1.ietf.org/mailman/listinfo/ips From exim@www1.ietf.org Mon Mar 29 13:52:11 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA17469 for ; Mon, 29 Mar 2004 13:52:11 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B81rL-0007bV-3U for ips-archive@odin.ietf.org; Mon, 29 Mar 2004 13:51:43 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i2TIphFq029229 for ips-archive@odin.ietf.org; Mon, 29 Mar 2004 13:51:43 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B81rK-0007bM-S2 for ips-web-archive@optimus.ietf.org; Mon, 29 Mar 2004 13:51:42 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA17442 for ; Mon, 29 Mar 2004 13:51:40 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B81rI-000211-00 for ips-web-archive@ietf.org; Mon, 29 Mar 2004 13:51:40 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B81qN-0001uE-00 for ips-web-archive@ietf.org; Mon, 29 Mar 2004 13:50:44 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1B81pk-0001nd-00 for ips-web-archive@ietf.org; Mon, 29 Mar 2004 13:50:04 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B81ph-0007Rv-Fl; Mon, 29 Mar 2004 13:50:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B81pI-0007QQ-14 for ips@optimus.ietf.org; Mon, 29 Mar 2004 13:49:41 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA17292 for ; Mon, 29 Mar 2004 13:49:33 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B81pF-0001mq-00 for ips@ietf.org; Mon, 29 Mar 2004 13:49:33 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B81oN-0001gN-00 for ips@ietf.org; Mon, 29 Mar 2004 13:48:39 -0500 Received: from sj-iport-2-in.cisco.com ([171.71.176.71] helo=sj-iport-2.cisco.com) by ietf-mx with esmtp (Exim 4.12) id 1B81nc-0001SR-00 for ips@ietf.org; Mon, 29 Mar 2004 13:47:53 -0500 Received: from sj-core-1.cisco.com (171.71.177.237) by sj-iport-2.cisco.com with ESMTP; 29 Mar 2004 10:53:26 +0000 X-BrightmailFiltered: true Received: from cisco.com (cypher.cisco.com [171.69.11.143]) by sj-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id i2TIlJUe017057; Mon, 29 Mar 2004 10:47:19 -0800 (PST) Received: (from kzm@localhost) by cisco.com (8.8.8/2.6/Cisco List Logging/8.8.8) id KAA10807; Mon, 29 Mar 2004 10:47:18 -0800 (PST) From: Keith McCloghrie Message-Id: <200403291847.KAA10807@cisco.com> Subject: Re: [Ips] Request from T11.5 for editorial cleanup To: rsnively@Brocade.COM (Robert Snively) Date: Mon, 29 Mar 2004 10:47:18 -0800 (PST) Cc: kzm@cisco.com (Keith McCloghrie), ips@ietf.org, t11_5@mail.t11.org ("T11_5 (E-mail)"), bwijnen@lucent.com, mrm@kazeon.com, mankin@psg.com, Elizabeth.Rodriguez@dothill.com, Black_David@emc.com In-Reply-To: <191DA4FAE235D24C9BCC8D50F6B17AB9093352@hq-ex-11.corp.brocade.com> from "Robert Snively" at Mar 26, 2004 02:58:48 PM X-Mailer: ELM [version 2.5 PL1] MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: ips-admin@ietf.org Errors-To: ips-admin@ietf.org 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: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit > 1) Fabric Name: > > In FC-SW-3, Clause 7.3, Principal Switch Selection states: > > "The Switch_Name of the Principal Switch shall be > used as the Fabric_Name." > > In the MIB (fcmInstanceFabricId), it states: > > "The globally unique Fabric Identifier which identifies the > fabric to which the Fibre Channel entity/entities managed by > this management instance are connected, or, of which they > are a part. This is typically the Node WWN of the principal > switch of a Fibre Channel fabric." > > The text should be changed to align with FC-SW-3 and indicate > that the Fabric Identifier SHALL be the Node WWN of the > principal switch. How about, I change the last sentence to be: FC-SW-3 requires this to be the Node WWN of the principal switch of the Fibre Channel fabric. > 2) Definition of port types under FcPortType: > > In FC-SW-3 two additional Port Types are defined, G_Port and GL_Port. > In FC-GS-4 a third Port Type of F/NL_Port is defined. > > Other collective ports are also defined by FC standards > documents, but those are for documentation purposes > only, rather than defining functionality. > Such ports include: Nx_Port (any port with N_Port or NL_Port > capability) and FC_Port (any port capable of transceiving > Fibre Channel frames). While those are actually specified > as port types in FC-GS-4, that is probably an error that > should be corrected in the next revision of that document. > > The MIB has added the port type "dynamic", not defined by any > of the T11 documents. It is suggested the "dynamic" port type > be removed and that "gPort" and "glPort" be used in its place, > since that is the likely intent of the word "dynamic", > referring to a port which has not quite yet decided what it is > going to be, but has a defined protocol to make that determination. > > Use a port type of "unknown" when you cannot identify the port > according to a standard. > > An additional port type of F/NL_Port ("fnlPort") should be > defined for applications that have that requirement. > > For reference, FC-SW-3 defines the G and GL_Ports as follows: > > 3.1.45 G_Port: A generic Fabric Port that may > function either as an E_Port, or as an > F_Port. > 3.1.46 GL_Port: A generic Fabric Port that may > function either as an E_Port, or as an > Fx_Port. > > For reference, FC-GS-4 defines the F/NL_Port as follows: > > 3.2.19 F/NL_Port: An NL_Port that detects OPN(00,x) > and provides Fibre Channel services in > the > absence of an FL_Port (see FC-AL-2). Thanks for the information. I agree that "gPort" and "glPort" together represent one example of a "determined dynamically" scenario defined by the 'dynamic' enumeration. However, I suggest that we want this MIB to support multiple versions of the FC-SW specification, such that as and when switches compliant to FC-SW-4 start shipping in the future, that this same MIB will simultaneously support both FC-SW-3 switches and FC-SW-4 switches. If I understand correctly, "gPort" and "glPort" were added in SW-3 (i.e., they were not present in SW-2), and thus I would speculate that there's a non-zero possibility that other types of dynamic determination could be added in SW-4 or SW-5. In other words, I believe this MIB must not say: "you will comply with FC-SW-3", but instead, it needs to say: "a switch compliant to FC-SW-3 will do xxx" (for example, see the proposal I made above wrt. Fabric_Name). That is, this MIB needs to be a superset of FC-SW-3. Given this, then we should definitely add enumerations for a "F/NL_Port" port, and for "gPort" and "glPort" as defined in SW-3, but I suggest that we retain "dynamic" as well in order to give this MIB the best chance of accommodating the future. (Note that it has taken many years for the IETF to get this far with this MIB. With T11 already having started work on SW-4, let's not make any assumptions about how long after SW-4 is approved there will be an update to this MIB.) Keith. _______________________________________________ Ips mailing list Ips@ietf.org https://www1.ietf.org/mailman/listinfo/ips From exim@www1.ietf.org Mon Mar 29 14:56:15 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA20771 for ; Mon, 29 Mar 2004 14:56:15 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B82rM-0004XZ-91 for ips-archive@odin.ietf.org; Mon, 29 Mar 2004 14:55:48 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i2TJtmvQ017453 for ips-archive@odin.ietf.org; Mon, 29 Mar 2004 14:55:48 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B82rM-0004XL-14 for ips-web-archive@optimus.ietf.org; Mon, 29 Mar 2004 14:55:48 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA20768 for ; Mon, 29 Mar 2004 14:55:44 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B82rJ-0002z0-00 for ips-web-archive@ietf.org; Mon, 29 Mar 2004 14:55:45 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B82qO-0002rG-00 for ips-web-archive@ietf.org; Mon, 29 Mar 2004 14:54:49 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1B82q1-0002jL-00 for ips-web-archive@ietf.org; Mon, 29 Mar 2004 14:54:25 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B82pr-0004IE-Cq; Mon, 29 Mar 2004 14:54:15 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B82pG-0004Fu-1J for ips@optimus.ietf.org; Mon, 29 Mar 2004 14:53:38 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA20673 for ; Mon, 29 Mar 2004 14:53:34 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B82pD-0002h5-00 for ips@ietf.org; Mon, 29 Mar 2004 14:53:35 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B82oE-0002Zd-00 for ips@ietf.org; Mon, 29 Mar 2004 14:52:35 -0500 Received: from brmea-mail-4.sun.com ([192.18.98.36]) by ietf-mx with esmtp (Exim 4.12) id 1B82nG-0002SM-00 for ips@ietf.org; Mon, 29 Mar 2004 14:51:34 -0500 Received: from phys-giza-1 ([129.147.4.102]) by brmea-mail-4.sun.com (8.12.10/8.12.9) with ESMTP id i2TJohMn001777 for ; Mon, 29 Mar 2004 12:50:43 -0700 (MST) Received: from [172.20.24.175] by giza-mail1.Central.Sun.COM (iPlanet Messaging Server 5.2 HotFix 1.16 (built May 14 2003)) with ESMTP id <0HVC00HICSHTX9@giza-mail1.Central.Sun.COM> for ips@ietf.org; Mon, 29 Mar 2004 12:51:29 -0700 (MST) Date: Mon, 29 Mar 2004 12:51:30 -0700 From: David Weibel To: ips@ietf.org Message-id: <797154FE-81BA-11D8-97AC-000A95B1A482@sun.com> MIME-version: 1.0 (Apple Message framework v613) X-Mailer: Apple Mail (2.613) Content-type: text/plain; format=flowed; charset=US-ASCII Content-transfer-encoding: 7bit Content-Transfer-Encoding: 7bit Subject: [Ips] iSCSI: clarification? data-in PDU->command status bit Sender: ips-admin@ietf.org Errors-To: ips-admin@ietf.org 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: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit [This topic appeared about 6 months ago in email archive without a clear resolution] Based on the iSCSI draft 20 is seems that it is legal for an iSCSI target to set the command status bit in a data-in PDU and either return a SCSI response PDU or drop the response PDU on a successful CMD completion. 10.7.3 Flags (byte 1) The last SCSI Data packet sent from a target to an initiator for a SCSI command that completed successfully (with a status of GOOD, CONDITION MET, INTERMEDIATE or INTERMEDIATE CONDITION MET) may also optionally contain the Status for the data transfer. In this case, Sense Data cannot be sent together with the Command Status. If the command is completed with an error, then the response and sense data MUST be sent in a SCSI Response PDU (i.e., MUST NOT be sent in a SCSI Data packet). For Bidirectional commands, the status MUST be sent in a SCSI Response PDU. I would like to purpose two possible clarifications to close the interpretation of this bit. 1) Update section 10.7.3 to add a statement similar to the below. ... If the command status bit is set the target MUST not send a SCSI response PDU. (or) 2) Add a new login parameter that allows the target device to notify the initiator of it's planned implementation of the bit. 12.XX CommandStatusResponse Use: LO Senders: Target Scope: SW CommandStatusResponse= Examples: CommandStatusResponse=No CommandStatusResponse=Yes Default is Yes The CommandStatusResonse is used to define the target implementation of the data-in PDU's command status bit. If CommandStatusResponse is Yes then the target MUST followup a data-in PDU containing the command status bit set with a scsi reponse PDU. If CommandStatusResponse is No then that target device MUST not send the scsi response PDU. --- [past email archive postings] suggestion to drop the S bit - http://www.pdl.cmu.edu/mailinglists/ips/mail/msg05757.html requested clarification on the S bit - http://www.pdl.cmu.edu/mailinglists/ips/mail/msg12341.html _______________________________________________ Ips mailing list Ips@ietf.org https://www1.ietf.org/mailman/listinfo/ips From exim@www1.ietf.org Mon Mar 29 15:25:15 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA23722 for ; Mon, 29 Mar 2004 15:25:15 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B83JP-0000un-7O for ips-archive@odin.ietf.org; Mon, 29 Mar 2004 15:24:47 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i2TKOlZ7003516 for ips-archive@odin.ietf.org; Mon, 29 Mar 2004 15:24:47 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B83JP-0000ud-11 for ips-web-archive@optimus.ietf.org; Mon, 29 Mar 2004 15:24:47 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA23699 for ; Mon, 29 Mar 2004 15:24:44 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B83JN-0007NR-00 for ips-web-archive@ietf.org; Mon, 29 Mar 2004 15:24:45 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B83IT-0007FD-00 for ips-web-archive@ietf.org; Mon, 29 Mar 2004 15:23:49 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1B83Hm-00076y-00 for ips-web-archive@ietf.org; Mon, 29 Mar 2004 15:23:06 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B83Hj-0000kk-G1; Mon, 29 Mar 2004 15:23:03 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B83Hc-0000iU-VA for ips@optimus.ietf.org; Mon, 29 Mar 2004 15:22:57 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA23626 for ; Mon, 29 Mar 2004 15:22:54 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B83Hb-000767-00 for ips@ietf.org; Mon, 29 Mar 2004 15:22:55 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B83Gi-0006xo-00 for ips@ietf.org; Mon, 29 Mar 2004 15:22:01 -0500 Received: from web12823.mail.yahoo.com ([216.136.174.204]) by ietf-mx with smtp (Exim 4.12) id 1B83G3-0006oC-00 for ips@ietf.org; Mon, 29 Mar 2004 15:21:19 -0500 Message-ID: <20040329201046.50079.qmail@web12823.mail.yahoo.com> Received: from [141.158.91.170] by web12823.mail.yahoo.com via HTTP; Mon, 29 Mar 2004 12:10:46 PST Date: Mon, 29 Mar 2004 12:10:46 -0800 (PST) From: Luben Tuikov Subject: Re: [Ips] iSCSI: clarification? data-in PDU->command status bit To: David Weibel , ips@ietf.org In-Reply-To: <797154FE-81BA-11D8-97AC-000A95B1A482@sun.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: ips-admin@ietf.org Errors-To: ips-admin@ietf.org 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: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60 I don't see the problem. Task SUCESS: If the task successfully completed, then the target MAY set the S bit and return the sucessful status along with the last Data-In PDU. This of course precludes sending SENSE DATA. No need for separate Response PDU as the task's lifetime has ended with sending response in the last Data-In PDU with S set. Or the target may choose to send status in a separate PDU (SCSI Response), thus S is not set for any Data-In PDU, and SCSI Response PDU follows. Task FAILURE: Response PDU. Sense data if available. Both cases send a response. -- Luben --- David Weibel wrote: > [This topic appeared about 6 months ago in email archive without a > clear resolution] > > Based on the iSCSI draft 20 is seems that it is legal for an iSCSI > target > to set the command status bit in a data-in PDU and either return a SCSI > response PDU or drop the response PDU on a successful CMD completion. > > 10.7.3 Flags (byte 1) The last SCSI Data packet sent from a target > to an initiator for a SCSI command that completed successfully > (with a status of GOOD, CONDITION MET, INTERMEDIATE or INTERMEDIATE > CONDITION MET) may also optionally contain the Status for the data > transfer. In this case, Sense Data cannot be sent together with > the Command Status. If the command is completed with an error, > then the response and sense data MUST be sent in a SCSI Response > PDU (i.e., MUST NOT be sent in a SCSI Data packet). For Bidirectional > commands, the status MUST be sent in a SCSI Response PDU. > > I would like to purpose two possible clarifications to close the > interpretation of this bit. > > 1) Update section 10.7.3 to add a statement similar to the below. > > ... If the command status bit is set the target MUST not send a SCSI > response PDU. > > (or) 2) Add a new login parameter that allows the target device to > notify the > initiator of it's planned implementation of the bit. > > 12.XX CommandStatusResponse > Use: LO > Senders: Target > Scope: SW > > CommandStatusResponse= > > Examples: > > CommandStatusResponse=No > CommandStatusResponse=Yes > > Default is Yes > > The CommandStatusResonse is used to define the target implementation > of the data-in PDU's command status bit. If CommandStatusResponse is > Yes then the target MUST followup a data-in PDU containing the command > status bit set with a scsi reponse PDU. If CommandStatusResponse is > No then that target device MUST not send the scsi response PDU. > > --- > > [past email archive postings] > suggestion to drop the S bit - > http://www.pdl.cmu.edu/mailinglists/ips/mail/msg05757.html > requested clarification on the S bit - > http://www.pdl.cmu.edu/mailinglists/ips/mail/msg12341.html > > > _______________________________________________ > Ips mailing list > Ips@ietf.org > https://www1.ietf.org/mailman/listinfo/ips _______________________________________________ Ips mailing list Ips@ietf.org https://www1.ietf.org/mailman/listinfo/ips From exim@www1.ietf.org Mon Mar 29 15:36:22 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA24481 for ; Mon, 29 Mar 2004 15:36:21 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B83U9-00025B-BB for ips-archive@odin.ietf.org; Mon, 29 Mar 2004 15:35:53 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i2TKZrSt008004 for ips-archive@odin.ietf.org; Mon, 29 Mar 2004 15:35:53 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B83U9-000251-5L for ips-web-archive@optimus.ietf.org; Mon, 29 Mar 2004 15:35:53 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA24454 for ; Mon, 29 Mar 2004 15:35:50 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B83U7-0001HF-00 for ips-web-archive@ietf.org; Mon, 29 Mar 2004 15:35:51 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B83TF-000170-00 for ips-web-archive@ietf.org; Mon, 29 Mar 2004 15:34:58 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1B83SL-0000ww-00 for ips-web-archive@ietf.org; Mon, 29 Mar 2004 15:34:01 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B83SL-0001ru-DA; Mon, 29 Mar 2004 15:34:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B83SB-0001qg-0t for ips@optimus.ietf.org; Mon, 29 Mar 2004 15:33:51 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA24226 for ; Mon, 29 Mar 2004 15:33:48 -0500 (EST) From: Black_David@emc.com Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B83S9-0000uh-00 for ips@ietf.org; Mon, 29 Mar 2004 15:33:49 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B83RM-0000la-00 for ips@ietf.org; Mon, 29 Mar 2004 15:33:01 -0500 Received: from mxic2.corp.emc.com ([128.221.12.9]) by ietf-mx with esmtp (Exim 4.12) id 1B83Ql-0000an-00 for ips@ietf.org; Mon, 29 Mar 2004 15:32:23 -0500 Received: by mxic2.corp.emc.com with Internet Mail Service (5.5.2653.19) id ; Mon, 29 Mar 2004 15:31:50 -0500 Message-ID: To: David.Weibel@Sun.COM, ips@ietf.org Subject: RE: [Ips] iSCSI: clarification? data-in PDU->command status bit Date: Mon, 29 Mar 2004 15:31:48 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain Sender: ips-admin@ietf.org Errors-To: ips-admin@ietf.org 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: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.3 required=5.0 tests=AWL,NO_REAL_NAME autolearn=no version=2.60 1) is the intended sense - Status is sent *exactly* once for any completed command, either via the status bit XOR a Response PDU. The clarifying sentence indicating that it is wrong to set the status bit AND send a Response PDU for the same command is a reasonable addition. Adding a new login parameter at this late stage is not possible. Thanks, --David ---------------------------------------------------- David L. Black, Senior Technologist EMC Corporation, 176 South St., Hopkinton, MA 01748 +1 (508) 293-7953 FAX: +1 (508) 293-7786 black_david@emc.com Mobile: +1 (978) 394-7754 ---------------------------------------------------- > -----Original Message----- > From: ips-admin@ietf.org [mailto:ips-admin@ietf.org] On > Behalf Of David Weibel > Sent: Monday, March 29, 2004 2:52 PM > To: ips@ietf.org > Subject: [Ips] iSCSI: clarification? data-in PDU->command status bit > > > [This topic appeared about 6 months ago in email archive without a > clear resolution] > > Based on the iSCSI draft 20 is seems that it is legal for an iSCSI target > to set the command status bit in a data-in PDU and either return a SCSI > response PDU or drop the response PDU on a successful CMD completion. > > 10.7.3 Flags (byte 1) The last SCSI Data packet sent from a target > to an initiator for a SCSI command that completed successfully > (with a status of GOOD, CONDITION MET, INTERMEDIATE or INTERMEDIATE > CONDITION MET) may also optionally contain the Status for the data > transfer. In this case, Sense Data cannot be sent together with > the Command Status. If the command is completed with an error, > then the response and sense data MUST be sent in a SCSI Response > PDU (i.e., MUST NOT be sent in a SCSI Data packet). For Bidirectional > commands, the status MUST be sent in a SCSI Response PDU. > > I would like to purpose two possible clarifications to close the > interpretation of this bit. > > 1) Update section 10.7.3 to add a statement similar to the below. > > ... If the command status bit is set the target MUST > not send a SCSI > response PDU. > > (or) 2) Add a new login parameter that allows the target device to > notify the > initiator of it's planned implementation of the bit. > > 12.XX CommandStatusResponse > Use: LO > Senders: Target > Scope: SW > > CommandStatusResponse= > > Examples: > > CommandStatusResponse=No > CommandStatusResponse=Yes > > Default is Yes > > The CommandStatusResonse is used to define the target implementation > of the data-in PDU's command status bit. If CommandStatusResponse is > Yes then the target MUST followup a data-in PDU containing the command > status bit set with a scsi reponse PDU. If CommandStatusResponse is > No then that target device MUST not send the scsi response PDU. > > --- > > [past email archive postings] > suggestion to drop the S bit - > http://www.pdl.cmu.edu/mailinglists/ips/mail/msg05757.html > requested clarification on the S bit - > http://www.pdl.cmu.edu/mailinglists/ips/mail/msg12341.html > > > _______________________________________________ > Ips mailing list > Ips@ietf.org > https://www1.ietf.org/mailman/listinfo/ips > _______________________________________________ Ips mailing list Ips@ietf.org https://www1.ietf.org/mailman/listinfo/ips From exim@www1.ietf.org Mon Mar 29 19:40:23 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA06034 for ; Mon, 29 Mar 2004 19:40:22 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B87IH-0001vc-SY for ips-archive@odin.ietf.org; Mon, 29 Mar 2004 19:39:54 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i2U0dr9N007408 for ips-archive@odin.ietf.org; Mon, 29 Mar 2004 19:39:53 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B87IH-0001vP-LT for ips-web-archive@optimus.ietf.org; Mon, 29 Mar 2004 19:39:53 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA06027 for ; Mon, 29 Mar 2004 19:39:51 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B87IG-0004yq-00 for ips-web-archive@ietf.org; Mon, 29 Mar 2004 19:39:52 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B87HS-0004qx-00 for ips-web-archive@ietf.org; Mon, 29 Mar 2004 19:39:03 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1B87Gc-0004hn-00 for ips-web-archive@ietf.org; Mon, 29 Mar 2004 19:38:10 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B87GT-0001lV-Hg; Mon, 29 Mar 2004 19:38:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B87GE-0001gX-Dp for ips@optimus.ietf.org; Mon, 29 Mar 2004 19:37:46 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA05905 for ; Mon, 29 Mar 2004 19:37:44 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B87GC-0004dd-00 for ips@ietf.org; Mon, 29 Mar 2004 19:37:44 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B87FD-0004UX-00 for ips@ietf.org; Mon, 29 Mar 2004 19:36:45 -0500 Received: from mtagate2.de.ibm.com ([195.212.29.151]) by ietf-mx with esmtp (Exim 4.12) id 1B87EC-0004F8-00 for ips@ietf.org; Mon, 29 Mar 2004 19:35:40 -0500 Received: from d12relay01.megacenter.de.ibm.com (d12relay01.megacenter.de.ibm.com [9.149.165.180]) by mtagate2.de.ibm.com (8.12.10/8.12.10) with ESMTP id i2U0YuKG135264; Tue, 30 Mar 2004 00:34:56 GMT Received: from d12ml102.megacenter.de.ibm.com (d12av02.megacenter.de.ibm.com [9.149.165.228]) by d12relay01.megacenter.de.ibm.com (8.12.10/NCO/VER6.6) with ESMTP id i2U0Yws9241260; Tue, 30 Mar 2004 02:34:59 +0200 In-Reply-To: <001c01c3d6d5$10afca40$0303a8c0@ivvt2dxrc11> To: "Eddy Quicksall" Cc: cbm@rose.hp.com, ips@ietf.org, ips-admin@ietf.org, "Paul Koning" , wrstuden@wasabisystems.com MIME-Version: 1.0 Subject: Re: [Ips] iSCSI: When does a connection become part of a session? X-Mailer: Lotus Notes Release 6.5.1 January 21, 2004 From: Julian Satran Message-ID: Date: Tue, 30 Mar 2004 02:34:52 +0200 X-MIMETrack: Serialize by Router on D12ML102/12/M/IBM(Release 6.0.2CF2|July 23, 2003) at 30/03/2004 02:37:00, Serialize complete at 30/03/2004 02:37:00 Content-Type: multipart/alternative; boundary="=_alternative 003EC815C2256E66_=" Sender: ips-admin@ietf.org Errors-To: ips-admin@ietf.org 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: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.3 required=5.0 tests=AWL,HTML_20_30,HTML_MESSAGE autolearn=no version=2.60 This is a multipart message in MIME format. --=_alternative 003EC815C2256E66_= Content-Type: text/plain; charset="US-ASCII" Eddy, It does not look to me that an errata is needed. As Login is made of immediate commands you may keep ExpCmdSN/MaxCmdSN at CmdSN value on the connection and the protocol will work (if you are security conscious). You may even keep them all 0. Julo "Eddy Quicksall" Sent by: ips-admin@ietf.org 09/01/04 19:21 To "Paul Koning" , cc , Subject Re: [Ips] iSCSI: When does a connection become part of a session? It seems that everyone agrees that ExpCmdSN and MaxCmdSN should not be reported during security stage. But the spec does not say that and does not even imply that. I think there needs to be an errata to the spec to specifically say this. Eddy ----- Original Message ----- From: "Paul Koning" To: Cc: ; Sent: Friday, January 09, 2004 10:05 AM Subject: Re: [Ips] iSCSI: When does a connection become part of a session? > >>>>> "Mallikarjun" == Mallikarjun C writes: > > >> Also, our target expects StatSN (and ExpStatSN) to be handled > >> correctly even in login. As StatSN is connection-specific, I see > >> no session nor security problems with this. :-) > > Mallikarjun> Agreed. > > >> Does anyone see a security implication of the target leaking > >> MaxCmdSN and ExpCmdSN? > > Mallikarjun> I think inadvertent revealing of current ExpCmdSN even > Mallikarjun> before the security negotiation stage allows an attacker > Mallikarjun> to gain insights into traffic volumes - he can > Mallikarjun> periodically use this to get snapshots of the ExpCmdSN > Mallikarjun> value. > > Traffic analysis is probably more easily done by watching existing > connections than by active attack. But I'd agree that this is > possible. > > The other issue, I think, is that ExpCmdSN is one of the pieces of > state you need to succeed in connection hijacking. For that reason, > it would be better not to reveal it until authentication is done. > > As a design principle, it would make sense to say that the security > handshake portion of the login procedures contains NOTHING other than > the data required for the security machinery. > > paul > > > _______________________________________________ > Ips mailing list > Ips@ietf.org > https://www1.ietf.org/mailman/listinfo/ips _______________________________________________ Ips mailing list Ips@ietf.org https://www1.ietf.org/mailman/listinfo/ips --=_alternative 003EC815C2256E66_= Content-Type: text/html; charset="US-ASCII"
Eddy,

It does not look to me that an errata is needed. As Login is made of immediate commands you may keep ExpCmdSN/MaxCmdSN at CmdSN value on the connection and the protocol will work (if you are security conscious). You may even keep them all 0.

Julo


"Eddy Quicksall" <eddy_quicksall_iVivity_iSCSI@comcast.net>
Sent by: ips-admin@ietf.org

09/01/04 19:21

To
"Paul Koning" <pkoning@equallogic.com>, <cbm@rose.hp.com>
cc
<wrstuden@wasabisystems.com>, <ips@ietf.org>
Subject
Re: [Ips] iSCSI: When does a connection become part of a session?





It seems that everyone agrees that ExpCmdSN and MaxCmdSN should not be
reported during security stage. But the spec does not say that and does not
even imply that.

I think there needs to be an errata to the spec to specifically say this.

Eddy

----- Original Message -----
From: "Paul Koning" <pkoning@equallogic.com>
To: <cbm@rose.hp.com>
Cc: <wrstuden@wasabisystems.com>; <ips@ietf.org>
Sent: Friday, January 09, 2004 10:05 AM
Subject: Re: [Ips] iSCSI: When does a connection become part of a session?


> >>>>> "Mallikarjun" == Mallikarjun C <cbm@rose.hp.com> writes:
>
>  >> Also, our target expects StatSN (and ExpStatSN) to be handled
>  >> correctly even in login. As StatSN is connection-specific, I see
>  >> no session nor security problems with this. :-)
>
>  Mallikarjun> Agreed.
>
>  >> Does anyone see a security implication of the target leaking
>  >> MaxCmdSN and ExpCmdSN?
>
>  Mallikarjun> I think inadvertent revealing of current ExpCmdSN even
>  Mallikarjun> before the security negotiation stage allows an attacker
>  Mallikarjun> to gain insights into traffic volumes - he can
>  Mallikarjun> periodically use this to get snapshots of the ExpCmdSN
>  Mallikarjun> value.
>
> Traffic analysis is probably more easily done by watching existing
> connections than by active attack.  But I'd agree that this is
> possible.
>
> The other issue, I think, is that ExpCmdSN is one of the pieces of
> state you need to succeed in connection hijacking.  For that reason,
> it would be better not to reveal it until authentication is done.
>
> As a design principle, it would make sense to say that the security
> handshake portion of the login procedures contains NOTHING other than
> the data required for the security machinery.
>
>     paul
>
>
> _______________________________________________
> Ips mailing list
> Ips@ietf.org
> https://www1.ietf.org/mailman/listinfo/ips


_______________________________________________
Ips mailing list
Ips@ietf.org
https://www1.ietf.org/mailman/listinfo/ips
--=_alternative 003EC815C2256E66_=-- _______________________________________________ Ips mailing list Ips@ietf.org https://www1.ietf.org/mailman/listinfo/ips From exim@www1.ietf.org Mon Mar 29 21:34:22 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA10260 for ; Mon, 29 Mar 2004 21:34:21 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B894d-00011f-0u for ips-archive@odin.ietf.org; Mon, 29 Mar 2004 21:33:55 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i2U2XsK8003942 for ips-archive@odin.ietf.org; Mon, 29 Mar 2004 21:33:54 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B894c-00011V-OP for ips-web-archive@optimus.ietf.org; Mon, 29 Mar 2004 21:33:54 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA10248 for ; Mon, 29 Mar 2004 21:33:51 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B894Z-0005Do-00 for ips-web-archive@ietf.org; Mon, 29 Mar 2004 21:33:52 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B893c-00056Q-00 for ips-web-archive@ietf.org; Mon, 29 Mar 2004 21:32:52 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1B892r-0004zP-00 for ips-web-archive@ietf.org; Mon, 29 Mar 2004 21:32:05 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B892n-0000r0-4k; Mon, 29 Mar 2004 21:32:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B891o-0000ng-J0 for ips@optimus.ietf.org; Mon, 29 Mar 2004 21:31:00 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA10192 for ; Mon, 29 Mar 2004 21:30:57 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B891l-0004rI-00 for ips@ietf.org; Mon, 29 Mar 2004 21:30:57 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B890u-0004jO-00 for ips@ietf.org; Mon, 29 Mar 2004 21:30:05 -0500 Received: from mtagate2.de.ibm.com ([195.212.29.151]) by ietf-mx with esmtp (Exim 4.12) id 1B890Y-0004at-00 for ips@ietf.org; Mon, 29 Mar 2004 21:29:43 -0500 Received: from d12relay01.megacenter.de.ibm.com (d12relay01.megacenter.de.ibm.com [9.149.165.180]) by mtagate2.de.ibm.com (8.12.10/8.12.10) with ESMTP id i2U2TBKG142862 for ; Tue, 30 Mar 2004 02:29:11 GMT Received: from d12ml102.megacenter.de.ibm.com (d12av02.megacenter.de.ibm.com [9.149.165.228]) by d12relay01.megacenter.de.ibm.com (8.12.10/NCO/VER6.6) with ESMTP id i2U2TGsB228070 for ; Tue, 30 Mar 2004 04:29:18 +0200 To: ips@ietf.org MIME-Version: 1.0 X-Mailer: Lotus Notes Release 6.5.1 January 21, 2004 From: Julian Satran Message-ID: Date: Tue, 30 Mar 2004 04:29:11 +0200 X-MIMETrack: Serialize by Router on D12ML102/12/M/IBM(Release 6.0.2CF2|July 23, 2003) at 30/03/2004 04:31:29, Serialize complete at 30/03/2004 04:31:29 Content-Type: multipart/alternative; boundary="=_alternative 000B94E8C2256E67_=" Subject: [Ips] iSCSI-a recent version of the draft Sender: ips-admin@ietf.org Errors-To: ips-admin@ietf.org 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: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.1 required=5.0 tests=AWL,HTML_MESSAGE autolearn=no version=2.60 This is a multipart message in MIME format. --=_alternative 000B94E8C2256E67_= Content-Type: text/plain; charset="US-ASCII" The most recent version of the draft - with errata will be out on my site during the next day (the date on it reads March 29) It contains all the editorial changes that where discussed and agreed - except the codes for the UA that we agreed to add - and I will. Please have a look and comment. We will have to merge them with the RFC editor's fixes very soon. Julo --=_alternative 000B94E8C2256E67_= Content-Type: text/html; charset="US-ASCII"
The most recent version of the draft - with errata will be out on my site during the next day (the date on it reads March 29)
It contains all the editorial changes that where discussed and agreed - except the codes for the UA that we agreed to add - and I will.

Please have a look and comment.

We will have to merge them with the RFC editor's fixes very soon.

Julo
--=_alternative 000B94E8C2256E67_=-- _______________________________________________ Ips mailing list Ips@ietf.org https://www1.ietf.org/mailman/listinfo/ips From exim@www1.ietf.org Tue Mar 30 10:11:36 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA23688 for ; Tue, 30 Mar 2004 10:11:36 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B8KtS-0007PK-19 for ips-archive@odin.ietf.org; Tue, 30 Mar 2004 10:11:10 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i2UFBA7j028470 for ips-archive@odin.ietf.org; Tue, 30 Mar 2004 10:11:10 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B8KtR-0007Ow-Q1 for ips-web-archive@optimus.ietf.org; Tue, 30 Mar 2004 10:11:09 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA23579 for ; Tue, 30 Mar 2004 10:11:05 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B8KtP-0000Qy-00 for ips-web-archive@ietf.org; Tue, 30 Mar 2004 10:11:07 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B8KrW-00002C-00 for ips-web-archive@ietf.org; Tue, 30 Mar 2004 10:09:11 -0500 Received: from [65.246.255.50] (helo=mx2.foretec.com) by ietf-mx with esmtp (Exim 4.12) id 1B8KqJ-0007aR-03 for ips-web-archive@ietf.org; Tue, 30 Mar 2004 10:07:55 -0500 Received: from optimus22.ietf.org ([132.151.6.22] helo=optimus.ietf.org) by mx2.foretec.com with esmtp (Exim 4.24) id 1B8KfI-000828-56 for ips-web-archive@ietf.org; Tue, 30 Mar 2004 09:56:32 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B8Keo-0001yS-0R; Tue, 30 Mar 2004 09:56:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B8KeK-0001rH-W2 for ips@optimus.ietf.org; Tue, 30 Mar 2004 09:55:33 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA22518 for ; Tue, 30 Mar 2004 09:55:29 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B8KeJ-000611-00 for ips@ietf.org; Tue, 30 Mar 2004 09:55:31 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B8KdG-0005nt-00 for ips@ietf.org; Tue, 30 Mar 2004 09:54:28 -0500 Received: from mtagate1.de.ibm.com ([195.212.29.150]) by ietf-mx with esmtp (Exim 4.12) id 1B8KcG-0005Pa-00 for ips@ietf.org; Tue, 30 Mar 2004 09:53:25 -0500 Received: from d12relay02.megacenter.de.ibm.com (d12relay02.megacenter.de.ibm.com [9.149.165.196]) by mtagate1.de.ibm.com (8.12.10/8.12.10) with ESMTP id i2UEqcVC119624; Tue, 30 Mar 2004 14:52:42 GMT Received: from d12ml102.megacenter.de.ibm.com (d12av02.megacenter.de.ibm.com [9.149.165.228]) by d12relay02.megacenter.de.ibm.com (8.12.10/NCO/VER6.6) with ESMTP id i2UEq5xU285410; Tue, 30 Mar 2004 16:52:06 +0200 In-Reply-To: To: Black_David@emc.com Cc: David.Weibel@Sun.COM, ips@ietf.org, ips-admin@ietf.org MIME-Version: 1.0 Subject: RE: [Ips] iSCSI: clarification? data-in PDU->command status bit X-Mailer: Lotus Notes Release 6.5.1 January 21, 2004 From: Julian Satran Message-ID: Date: Tue, 30 Mar 2004 16:52:04 +0200 X-MIMETrack: Serialize by Router on D12ML102/12/M/IBM(Release 6.0.2CF2|July 23, 2003) at 30/03/2004 16:54:17, Serialize complete at 30/03/2004 16:54:17 Content-Type: multipart/alternative; boundary="=_alternative 004FA67EC2256E67_=" Sender: ips-admin@ietf.org Errors-To: ips-admin@ietf.org 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: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.3 required=5.0 tests=AWL,HTML_20_30,HTML_MESSAGE autolearn=no version=2.60 This is a multipart message in MIME format. --=_alternative 004FA67EC2256E67_= Content-Type: text/plain; charset="US-ASCII" I am against saying again what SCSI says already. Julo Black_David@emc.com Sent by: ips-admin@ietf.org 29/03/04 22:31 To David.Weibel@Sun.COM, ips@ietf.org cc Subject RE: [Ips] iSCSI: clarification? data-in PDU->command status bit 1) is the intended sense - Status is sent *exactly* once for any completed command, either via the status bit XOR a Response PDU. The clarifying sentence indicating that it is wrong to set the status bit AND send a Response PDU for the same command is a reasonable addition. Adding a new login parameter at this late stage is not possible. Thanks, --David ---------------------------------------------------- David L. Black, Senior Technologist EMC Corporation, 176 South St., Hopkinton, MA 01748 +1 (508) 293-7953 FAX: +1 (508) 293-7786 black_david@emc.com Mobile: +1 (978) 394-7754 ---------------------------------------------------- > -----Original Message----- > From: ips-admin@ietf.org [mailto:ips-admin@ietf.org] On > Behalf Of David Weibel > Sent: Monday, March 29, 2004 2:52 PM > To: ips@ietf.org > Subject: [Ips] iSCSI: clarification? data-in PDU->command status bit > > > [This topic appeared about 6 months ago in email archive without a > clear resolution] > > Based on the iSCSI draft 20 is seems that it is legal for an iSCSI target > to set the command status bit in a data-in PDU and either return a SCSI > response PDU or drop the response PDU on a successful CMD completion. > > 10.7.3 Flags (byte 1) The last SCSI Data packet sent from a target > to an initiator for a SCSI command that completed successfully > (with a status of GOOD, CONDITION MET, INTERMEDIATE or INTERMEDIATE > CONDITION MET) may also optionally contain the Status for the data > transfer. In this case, Sense Data cannot be sent together with > the Command Status. If the command is completed with an error, > then the response and sense data MUST be sent in a SCSI Response > PDU (i.e., MUST NOT be sent in a SCSI Data packet). For Bidirectional > commands, the status MUST be sent in a SCSI Response PDU. > > I would like to purpose two possible clarifications to close the > interpretation of this bit. > > 1) Update section 10.7.3 to add a statement similar to the below. > > ... If the command status bit is set the target MUST > not send a SCSI > response PDU. > > (or) 2) Add a new login parameter that allows the target device to > notify the > initiator of it's planned implementation of the bit. > > 12.XX CommandStatusResponse > Use: LO > Senders: Target > Scope: SW > > CommandStatusResponse= > > Examples: > > CommandStatusResponse=No > CommandStatusResponse=Yes > > Default is Yes > > The CommandStatusResonse is used to define the target implementation > of the data-in PDU's command status bit. If CommandStatusResponse is > Yes then the target MUST followup a data-in PDU containing the command > status bit set with a scsi reponse PDU. If CommandStatusResponse is > No then that target device MUST not send the scsi response PDU. > > --- > > [past email archive postings] > suggestion to drop the S bit - > http://www.pdl.cmu.edu/mailinglists/ips/mail/msg05757.html > requested clarification on the S bit - > http://www.pdl.cmu.edu/mailinglists/ips/mail/msg12341.html > > > _______________________________________________ > Ips mailing list > Ips@ietf.org > https://www1.ietf.org/mailman/listinfo/ips > _______________________________________________ Ips mailing list Ips@ietf.org https://www1.ietf.org/mailman/listinfo/ips --=_alternative 004FA67EC2256E67_= Content-Type: text/html; charset="US-ASCII"
I am against saying again what SCSI says already. Julo


Black_David@emc.com
Sent by: ips-admin@ietf.org

29/03/04 22:31

To
David.Weibel@Sun.COM, ips@ietf.org
cc
Subject
RE: [Ips] iSCSI: clarification? data-in PDU->command status bit





1) is the intended sense - Status is sent *exactly* once for any
completed command, either via the status bit XOR a Response PDU.

The clarifying sentence indicating that it is wrong to set the
status bit AND send a Response PDU for the same command is a
reasonable addition.

Adding a new login parameter at this late stage is not possible.

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

> -----Original Message-----
> From: ips-admin@ietf.org [mailto:ips-admin@ietf.org] On
> Behalf Of David Weibel
> Sent: Monday, March 29, 2004 2:52 PM
> To: ips@ietf.org
> Subject: [Ips] iSCSI: clarification? data-in PDU->command status bit
>
>
> [This topic appeared about 6 months ago in email archive without a
> clear resolution]
>
>    Based on the iSCSI draft 20 is seems that it is legal for an iSCSI
target
> to set the command status bit in a data-in PDU and either return a SCSI
> response PDU or drop the response PDU on a successful CMD completion.
>
>                  10.7.3  Flags (byte 1) The last SCSI Data packet sent from a target
>                  to an initiator for a  SCSI command that completed successfully
>                  (with a status of GOOD,  CONDITION MET, INTERMEDIATE or INTERMEDIATE
>                  CONDITION MET) may also  optionally contain the Status for the data
>                  transfer.  In this case,  Sense Data cannot be sent together with
>                  the Command Status.  If the  command is completed with an error,
>                  then the response and sense data  MUST be sent in a SCSI Response
>                  PDU (i.e., MUST NOT be sent in a  SCSI Data packet). For
Bidirectional
>                  commands, the status MUST be  sent in a SCSI Response PDU.
>
>    I would like to purpose two possible clarifications to close the
> interpretation of this bit.
>
> 1) Update section 10.7.3 to add a statement similar to the below.
>
>                  ... If the command status bit is set the target MUST
> not send a SCSI
>                  response PDU.
>
> (or) 2) Add a new login parameter that allows the target device to
> notify the
> initiator of it's planned implementation of the bit.
>
>                  12.XX  CommandStatusResponse
>                  Use: LO
>                  Senders: Target
>                  Scope: SW
>
>                  CommandStatusResponse=<boolean-value>
>
>                  Examples:
>
>                                   CommandStatusResponse=No
>                                   CommandStatusResponse=Yes
>
>                  Default is Yes
>
>                  The CommandStatusResonse is used to define the target implementation
>                  of the data-in PDU's command status bit.  If CommandStatusResponse
is
>                  Yes then the target MUST followup a data-in PDU containing the
command
>                  status bit set with a scsi reponse PDU.  If CommandStatusResponse is
>                  No then that target device MUST not send the scsi response PDU.
>
> ---
>
> [past email archive postings]
> suggestion to drop the S bit -
>    http://www.pdl.cmu.edu/mailinglists/ips/mail/msg05757.html
> requested clarification on the S bit -
>    http://www.pdl.cmu.edu/mailinglists/ips/mail/msg12341.html
>
>
> _______________________________________________
> Ips mailing list
> Ips@ietf.org
> https://www1.ietf.org/mailman/listinfo/ips
>

_______________________________________________
Ips mailing list
Ips@ietf.org
https://www1.ietf.org/mailman/listinfo/ips
--=_alternative 004FA67EC2256E67_=-- _______________________________________________ Ips mailing list Ips@ietf.org https://www1.ietf.org/mailman/listinfo/ips From exim@www1.ietf.org Tue Mar 30 10:12:25 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA23881 for ; Tue, 30 Mar 2004 10:12:25 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B8KuE-0007YS-HE for ips-archive@odin.ietf.org; Tue, 30 Mar 2004 10:11:58 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i2UFBwCO029034 for ips-archive@odin.ietf.org; Tue, 30 Mar 2004 10:11:58 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B8KuE-0007YD-BL for ips-web-archive@optimus.ietf.org; Tue, 30 Mar 2004 10:11:58 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA23773 for ; Tue, 30 Mar 2004 10:11:54 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B8KuC-0000dY-00 for ips-web-archive@ietf.org; Tue, 30 Mar 2004 10:11:56 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B8Ks2-0000An-00 for ips-web-archive@ietf.org; Tue, 30 Mar 2004 10:09:43 -0500 Received: from [65.246.255.50] (helo=mx2.foretec.com) by ietf-mx with esmtp (Exim 4.12) id 1B8KqR-0007aR-03 for ips-web-archive@ietf.org; Tue, 30 Mar 2004 10:08:04 -0500 Received: from optimus22.ietf.org ([132.151.6.22] helo=optimus.ietf.org) by mx2.foretec.com with esmtp (Exim 4.24) id 1B8Kdy-00080X-Rt for ips-web-archive@ietf.org; Tue, 30 Mar 2004 09:55:11 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B8Kdq-0001fq-Il; Tue, 30 Mar 2004 09:55:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B8Kdm-0001dt-AJ for ips@optimus.ietf.org; Tue, 30 Mar 2004 09:54:58 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA22450 for ; Tue, 30 Mar 2004 09:54:54 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B8Kdk-0005s8-00 for ips@ietf.org; Tue, 30 Mar 2004 09:54:56 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B8Kcs-0005et-00 for ips@ietf.org; Tue, 30 Mar 2004 09:54:03 -0500 Received: from mtagate4.de.ibm.com ([195.212.29.153]) by ietf-mx with esmtp (Exim 4.12) id 1B8Kc1-0005N4-00; Tue, 30 Mar 2004 09:53:09 -0500 Received: from d12relay02.megacenter.de.ibm.com (d12relay02.megacenter.de.ibm.com [9.149.165.196]) by mtagate4.de.ibm.com (8.12.10/8.12.10) with ESMTP id i2UEqQMU113732; Tue, 30 Mar 2004 14:52:26 GMT Received: from d12ml102.megacenter.de.ibm.com (d12av02.megacenter.de.ibm.com [9.149.165.228]) by d12relay02.megacenter.de.ibm.com (8.12.10/NCO/VER6.6) with ESMTP id i2UEq5xV250492; Tue, 30 Mar 2004 16:52:07 +0200 In-Reply-To: <797154FE-81BA-11D8-97AC-000A95B1A482@sun.com> To: David Weibel Cc: ips@ietf.org, ips-admin@ietf.org MIME-Version: 1.0 Subject: Re: [Ips] iSCSI: clarification? data-in PDU->command status bit X-Mailer: Lotus Notes Release 6.5.1 January 21, 2004 From: Julian Satran Message-ID: Date: Tue, 30 Mar 2004 16:52:04 +0200 X-MIMETrack: Serialize by Router on D12ML102/12/M/IBM(Release 6.0.2CF2|July 23, 2003) at 30/03/2004 16:54:17, Serialize complete at 30/03/2004 16:54:17 Content-Type: multipart/alternative; boundary="=_alternative 004F074AC2256E67_=" Sender: ips-admin@ietf.org Errors-To: ips-admin@ietf.org 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: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.3 required=5.0 tests=AWL,HTML_20_30,HTML_MESSAGE autolearn=no version=2.60 This is a multipart message in MIME format. --=_alternative 004F074AC2256E67_= Content-Type: text/plain; charset="US-ASCII" Sorry David. iSCSI operates as SCSI transport. SCSI mandates that the status is sent once (SAM2) only. As for your login parameter besides being far too late for such a change I do not see why we should mandate this regularity when the code has to be there to handle both anyhow. What you suggest will only change the location of the bit tested. Julo David Weibel Sent by: ips-admin@ietf.org 29/03/04 21:51 To ips@ietf.org cc Subject [Ips] iSCSI: clarification? data-in PDU->command status bit [This topic appeared about 6 months ago in email archive without a clear resolution] Based on the iSCSI draft 20 is seems that it is legal for an iSCSI target to set the command status bit in a data-in PDU and either return a SCSI response PDU or drop the response PDU on a successful CMD completion. 10.7.3 Flags (byte 1) The last SCSI Data packet sent from a target to an initiator for a SCSI command that completed successfully (with a status of GOOD, CONDITION MET, INTERMEDIATE or INTERMEDIATE CONDITION MET) may also optionally contain the Status for the data transfer. In this case, Sense Data cannot be sent together with the Command Status. If the command is completed with an error, then the response and sense data MUST be sent in a SCSI Response PDU (i.e., MUST NOT be sent in a SCSI Data packet). For Bidirectional commands, the status MUST be sent in a SCSI Response PDU. I would like to purpose two possible clarifications to close the interpretation of this bit. 1) Update section 10.7.3 to add a statement similar to the below. ... If the command status bit is set the target MUST not send a SCSI response PDU. (or) 2) Add a new login parameter that allows the target device to notify the initiator of it's planned implementation of the bit. 12.XX CommandStatusResponse Use: LO Senders: Target Scope: SW CommandStatusResponse= Examples: CommandStatusResponse=No CommandStatusResponse=Yes Default is Yes The CommandStatusResonse is used to define the target implementation of the data-in PDU's command status bit. If CommandStatusResponse is Yes then the target MUST followup a data-in PDU containing the command status bit set with a scsi reponse PDU. If CommandStatusResponse is No then that target device MUST not send the scsi response PDU. --- [past email archive postings] suggestion to drop the S bit - http://www.pdl.cmu.edu/mailinglists/ips/mail/msg05757.html requested clarification on the S bit - http://www.pdl.cmu.edu/mailinglists/ips/mail/msg12341.html _______________________________________________ Ips mailing list Ips@ietf.org https://www1.ietf.org/mailman/listinfo/ips --=_alternative 004F074AC2256E67_= Content-Type: text/html; charset="US-ASCII"
Sorry David. iSCSI operates as SCSI transport. SCSI mandates that the status is sent once (SAM2) only.
As for your login parameter besides being far too late for such a change I do not see why we should mandate this regularity when the code has to be there to handle both anyhow.
What you suggest will only change the location of the bit tested.

Julo


David Weibel <David.Weibel@Sun.COM>
Sent by: ips-admin@ietf.org

29/03/04 21:51

To
ips@ietf.org
cc
Subject
[Ips] iSCSI: clarification? data-in PDU->command status bit





[This topic appeared about 6 months ago in email archive without a
clear resolution]

  Based on the iSCSI draft 20 is seems that it is legal for an iSCSI
target
to set the command status bit in a data-in PDU and either return a SCSI
response PDU or drop the response PDU on a successful CMD completion.

                10.7.3  Flags (byte 1) The last SCSI Data packet sent from a target
                to an initiator for a  SCSI command that completed successfully
                (with a status of GOOD,  CONDITION MET, INTERMEDIATE or INTERMEDIATE
                CONDITION MET) may also  optionally contain the Status for the data
                transfer.  In this case,  Sense Data cannot be sent together with
                the Command Status.  If the  command is completed with an error,
                then the response and sense data  MUST be sent in a SCSI Response
                PDU (i.e., MUST NOT be sent in a  SCSI Data packet). For Bidirectional
                commands, the status MUST be  sent in a SCSI Response PDU.

  I would like to purpose two possible clarifications to close the
interpretation of this bit.

1) Update section 10.7.3 to add a statement similar to the below.

                ... If the command status bit is set the target MUST not send a SCSI
                response PDU.

(or) 2) Add a new login parameter that allows the target device to
notify the
initiator of it's planned implementation of the bit.

                12.XX  CommandStatusResponse
                Use: LO
                Senders: Target
                Scope: SW

                CommandStatusResponse=<boolean-value>

                Examples:

                                 CommandStatusResponse=No
                                 CommandStatusResponse=Yes

                Default is Yes

                The CommandStatusResonse is used to define the target implementation
                of the data-in PDU's command status bit.  If CommandStatusResponse is
                Yes then the target MUST followup a data-in PDU containing the command
                status bit set with a scsi reponse PDU.  If CommandStatusResponse is
                No then that target device MUST not send the scsi response PDU.

---

[past email archive postings]
suggestion to drop the S bit -
  http://www.pdl.cmu.edu/mailinglists/ips/mail/msg05757.html
requested clarification on the S bit -
  http://www.pdl.cmu.edu/mailinglists/ips/mail/msg12341.html


_______________________________________________
Ips mailing list
Ips@ietf.org
https://www1.ietf.org/mailman/listinfo/ips
--=_alternative 004F074AC2256E67_=-- _______________________________________________ Ips mailing list Ips@ietf.org https://www1.ietf.org/mailman/listinfo/ips From exim@www1.ietf.org Tue Mar 30 10:30:13 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA25239 for ; Tue, 30 Mar 2004 10:30:13 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B8LBT-0002Tw-49 for ips-archive@odin.ietf.org; Tue, 30 Mar 2004 10:29:47 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i2UFTldC009539 for ips-archive@odin.ietf.org; Tue, 30 Mar 2004 10:29:47 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B8LBS-0002Tm-T4 for ips-web-archive@optimus.ietf.org; Tue, 30 Mar 2004 10:29:46 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA25197 for ; Tue, 30 Mar 2004 10:29:42 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B8LBQ-0003iW-00 for ips-web-archive@ietf.org; Tue, 30 Mar 2004 10:29:44 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B8LAY-0003X2-00 for ips-web-archive@ietf.org; Tue, 30 Mar 2004 10:28:51 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1B8L9k-0003KK-00 for ips-web-archive@ietf.org; Tue, 30 Mar 2004 10:28:00 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B8L9l-0002Dc-3s; Tue, 30 Mar 2004 10:28:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B8L9B-0002CE-C3 for ips@optimus.ietf.org; Tue, 30 Mar 2004 10:27:25 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA25061 for ; Tue, 30 Mar 2004 10:27:21 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B8L99-0003Hm-00 for ips@ietf.org; Tue, 30 Mar 2004 10:27:23 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B8L89-00037Z-00 for ips@ietf.org; Tue, 30 Mar 2004 10:26:22 -0500 Received: from nwkea-mail-2.sun.com ([192.18.42.14]) by ietf-mx with esmtp (Exim 4.12) id 1B8L7D-0002r2-00 for ips@ietf.org; Tue, 30 Mar 2004 10:25:23 -0500 Received: from phys-giza-1 ([129.147.4.102]) by nwkea-mail-2.sun.com (8.12.10/8.12.9) with ESMTP id i2UFOqni022009 for ; Tue, 30 Mar 2004 07:24:52 -0800 (PST) Received: from [172.20.24.175] by giza-mail1.Central.Sun.COM (iPlanet Messaging Server 5.2 HotFix 1.16 (built May 14 2003)) with ESMTP id <0HVE00529ATGFZ@giza-mail1.Central.Sun.COM> for ips@ietf.org; Tue, 30 Mar 2004 08:24:52 -0700 (MST) Date: Tue, 30 Mar 2004 08:24:51 -0700 From: David Weibel Subject: Re: [Ips] iSCSI: clarification? data-in PDU->command status bit In-reply-to: To: Julian Satran Cc: ips-admin@ietf.org, ips@ietf.org Message-id: <63A77D18-825E-11D8-9F04-000A95B1A482@sun.com> MIME-version: 1.0 (Apple Message framework v613) X-Mailer: Apple Mail (2.613) Content-type: text/plain; format=flowed; charset=ISO-8859-1 Content-transfer-encoding: quoted-printable References: Content-Transfer-Encoding: quoted-printable Sender: ips-admin@ietf.org Errors-To: ips-admin@ietf.org 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: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60 Content-Transfer-Encoding: quoted-printable Content-Transfer-Encoding: quoted-printable Julian, I found the section in SAM2 which is mandating the status only=20= being sent once. I believe this resolves our question. We have been=20 seeing a third party target returning both the S bit and SCSI response=20= PDU to our initiator stack and wanted to have a solid position to=20 address the issue. Thanks -David On Mar 30, 2004, at 7:52 AM, Julian Satran wrote: > > Sorry David. iSCSI operates as SCSI transport. SCSI mandates that the=20= > status is sent once (SAM2) only. > As for your login parameter besides being far too late for such a=20 > change I do not see why we should mandate this regularity when the=20 > code has to be there to handle both anyhow. > What you suggest will only change the location of the bit tested. > > Julo > > > > > David Weibel > Sent by: ips-admin@ietf.org > > 29/03/04 21:51 > > To > ips@ietf.org > > cc > > Subject > [Ips] iSCSI: clarification? data-in PDU->command status bit > > > > > > > > [This topic appeared about 6 months ago in email archive without a > clear resolution] > > =A0 Based on the iSCSI draft 20 is seems that it is legal for an = iSCSI > target > to set the command status bit in a data-in PDU and either return a=20 > SCSI > response PDU or drop the response PDU on a successful CMD completion. > > =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 10.7.3 =A0Flags (byte 1) The last = SCSI Data packet sent=20 > from a target > =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 to an initiator for a =A0SCSI command = that completed=20 > successfully > =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 (with a status of GOOD, =A0CONDITION = MET, INTERMEDIATE=20 > or INTERMEDIATE > =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 CONDITION MET) may also =A0optionally = contain the=20 > Status for the data > =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 transfer. =A0In this case, =A0Sense = Data cannot be sent=20 > together with > =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 the Command Status. =A0If the = =A0command is completed=20 > with an error, > =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 then the response and sense data = =A0MUST be sent in a=20 > SCSI Response > =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 PDU (i.e., MUST NOT be sent in a = =A0SCSI Data packet).=20 > For Bidirectional > =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 commands, the status MUST be =A0sent = in a SCSI Response=20 > PDU. > > =A0 I would like to purpose two possible clarifications to close the > interpretation of this bit. > > 1) Update section 10.7.3 to add a statement similar to the below. > > =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 ... If the command status bit is set = the target MUST=20 > not send a SCSI > =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 response PDU. > > (or) 2) Add a new login parameter that allows the target device to > notify the > initiator of it's planned implementation of the bit. > > =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 12.XX =A0CommandStatusResponse > =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 Use: LO > =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 Senders: Target > =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 Scope: SW > > =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 CommandStatusResponse=3D= > > =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 Examples: > > =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 = =A0CommandStatusResponse=3DNo > =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 = =A0CommandStatusResponse=3DYes > > =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 Default is Yes > > =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 The CommandStatusResonse is used to = define the target=20 > implementation > =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 of the data-in PDU's command status = bit. =A0If=20 > CommandStatusResponse is > =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 Yes then the target MUST followup a = data-in PDU=20 > containing the command > =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 status bit set with a scsi reponse = PDU. =A0If=20 > CommandStatusResponse is > =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 No then that target device MUST not = send the scsi=20 > response PDU. > > --- > > [past email archive postings] > suggestion to drop the S bit - > =A0 http://www.pdl.cmu.edu/mailinglists/ips/mail/msg05757.html > requested clarification on the S bit - > =A0 http://www.pdl.cmu.edu/mailinglists/ips/mail/msg12341.html > > > _______________________________________________ > Ips mailing list > Ips@ietf.org > https://www1.ietf.org/mailman/listinfo/ips > _______________________________________________ Ips mailing list Ips@ietf.org https://www1.ietf.org/mailman/listinfo/ips From exim@www1.ietf.org Tue Mar 30 17:22:15 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA17301 for ; Tue, 30 Mar 2004 17:22:15 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B8RcC-0006Gb-RU for ips-archive@odin.ietf.org; Tue, 30 Mar 2004 17:21:49 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i2UMLmhk024089 for ips-archive@odin.ietf.org; Tue, 30 Mar 2004 17:21:48 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B8RcC-0006GS-M4 for ips-web-archive@optimus.ietf.org; Tue, 30 Mar 2004 17:21:48 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA17286 for ; Tue, 30 Mar 2004 17:21:44 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B8RcA-0005FV-00 for ips-web-archive@ietf.org; Tue, 30 Mar 2004 17:21:46 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B8RbC-0005Bq-00 for ips-web-archive@ietf.org; Tue, 30 Mar 2004 17:20:47 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1B8RaY-00058V-00 for ips-web-archive@ietf.org; Tue, 30 Mar 2004 17:20:06 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B8RaU-00065p-Me; Tue, 30 Mar 2004 17:20:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B8RaC-000640-Pc for ips@optimus.ietf.org; Tue, 30 Mar 2004 17:19:44 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA17183 for ; Tue, 30 Mar 2004 17:19:40 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B8RaA-00056a-00 for ips@ietf.org; Tue, 30 Mar 2004 17:19:42 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B8RZH-00053A-00 for ips@ietf.org; Tue, 30 Mar 2004 17:18:48 -0500 Received: from sccrmhc12.comcast.net ([204.127.202.56]) by ietf-mx with esmtp (Exim 4.12) id 1B8RYw-0004zj-00 for ips@ietf.org; Tue, 30 Mar 2004 17:18:26 -0500 Received: from ivvt2dxrc11 (c-66-177-57-55.se.client2.attbi.com[66.177.57.55]) by comcast.net (sccrmhc12) with SMTP id <2004033022175601200nfio7e> (Authid: esquicksall); Tue, 30 Mar 2004 22:17:56 +0000 Message-ID: <002801c416a4$da0b5580$0303a8c0@ivvt2dxrc11> From: "Eddy Quicksall" To: Date: Tue, 30 Mar 2004 17:17:55 -0500 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0025_01C4167A.F0C43C30" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1158 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 Subject: [Ips] iSCSI: reinstatement Sender: ips-admin@ietf.org Errors-To: ips-admin@ietf.org 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: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.2 required=5.0 tests=AWL,HTML_50_60,HTML_MESSAGE autolearn=no version=2.60 This is a multi-part message in MIME format. ------=_NextPart_000_0025_01C4167A.F0C43C30 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable I just noticed this ("if an explicit logout was not performed earlier" = ). The first part of the paragraph already said "possibly active" which = could only happen if a logout had not been performed earlier. Is this = just an overstatement or am I missing something? =20 Connection reinstatement is the process of an initiator logging in with a ISID-TSIH-CID combination that is possibly active from the target's perspective, which causes the implicit logging out of the connection corresponding to the CID and reinstating a new Full Feature Phase iSCSI connection in its place (with the same CID). Thus, the TSIH in the Login PDU MUST be non-zero and CID does not change during a connection reinstatement. The Login request performs the logout function of the old connection if an explicit logout was not performed earlier. =20 ------=_NextPart_000_0025_01C4167A.F0C43C30 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable

I just noticed this (=93if = an explicit=20 logout was not performed earlier=94 ). The first part of the paragraph = already=20 said =93possibly active=94 which could only happen if a logout had not = been=20 performed earlier. Is this just an overstatement or am I missing=20 something?

 

Connection=20 reinstatement is the process of an initiator logging = in

with=20 a ISID-TSIH-CID combination that is possibly active from=20 the

target=92s=20 perspective, which causes the implicit logging out of = the

connection=20 corresponding to the CID and reinstating a new = Full

Feature=20 Phase iSCSI connection in its place (with the same = CID).

Thus,=20 the TSIH in the Login PDU MUST be non-zero and CID does=20 not

change=20 during a connection reinstatement. The Login request=20 performs

the=20 logout function of the old connection if = an=20 explicit logout was

not=20 performed earlier.

 

------=_NextPart_000_0025_01C4167A.F0C43C30-- _______________________________________________ Ips mailing list Ips@ietf.org https://www1.ietf.org/mailman/listinfo/ips From exim@www1.ietf.org Tue Mar 30 17:57:20 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA22104 for ; Tue, 30 Mar 2004 17:57:20 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B8Rjc-0006a4-17 for ips-archive@odin.ietf.org; Tue, 30 Mar 2004 17:29:28 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i2BJZoOa006793 for ips-archive@odin.ietf.org; Thu, 11 Mar 2004 14:35:50 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B1Vy8-0001l3-8o for ips-web-archive@optimus.ietf.org; Thu, 11 Mar 2004 14:35:48 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA18191 for ; Thu, 11 Mar 2004 14:35:45 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B1Vy5-0005DC-00 for ips-web-archive@ietf.org; Thu, 11 Mar 2004 14:35:45 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B1VxB-00054X-00 for ips-web-archive@ietf.org; Thu, 11 Mar 2004 14:34:50 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1B1VwP-0004un-00 for ips-web-archive@ietf.org; Thu, 11 Mar 2004 14:34:01 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B1VwO-0001PG-L0; Thu, 11 Mar 2004 14:34:00 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B1VvY-0001HU-4H for ips@optimus.ietf.org; Thu, 11 Mar 2004 14:33:08 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA17907 for ; Thu, 11 Mar 2004 14:33:05 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B1VvV-0004ka-00 for ips@ietf.org; Thu, 11 Mar 2004 14:33:05 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B1VuX-0004am-00 for ips@ietf.org; Thu, 11 Mar 2004 14:32:06 -0500 Received: from dns2.tilab.com ([163.162.42.5]) by ietf-mx with esmtp (Exim 4.12) id 1B1Vu1-0004RC-00 for ips@ietf.org; Thu, 11 Mar 2004 14:31:33 -0500 Received: from iowa2k01b.cselt.it ([163.162.242.204]) by dns2.cselt.it (PMDF V6.1 #38895) with ESMTP id <0HUF0094MFBW2M@dns2.cselt.it> for ips@ietf.org; Thu, 11 Mar 2004 20:26:21 +0100 (MET) Received: from iowa2k01b.cselt.it ([163.162.242.204]) by iowa2k01b.cselt.it with Microsoft SMTPSVC(5.0.2195.5329); Thu, 11 Mar 2004 20:30:01 +0100 Received: from EXC2K01A.cselt.it ([163.162.4.34]) by iowa2k01b.cselt.it with Microsoft SMTPSVC(5.0.2195.5329); Thu, 11 Mar 2004 20:30:01 +0100 Date: Thu, 11 Mar 2004 20:30:59 +0100 From: Maffione Eugenio Subject: RIF: [Ips] is a share disk possible on SCSI/iSCSI level? To: ips@ietf.org Cc: wangxz@ict.ac.cn Message-id: <2FE6D10B746E524998DEA70F2D418F0201D3DB7D@EXC2K01A.cselt.it> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 Content-type: text/plain; charset=utf-8 Content-transfer-encoding: quoted-printable Importance: normal Priority: normal Thread-Topic: [Ips] is a share disk possible on SCSI/iSCSI level? Thread-Index: AcP/MzyMed6fDebRTam+yhs7L9UEpQIbANd3 content-class: urn:content-classes:message X-OriginalArrivalTime: 11 Mar 2004 19:30:01.0250 (UTC) FILETIME=[3F112820:01C4079F] Content-Transfer-Encoding: quoted-printable Sender: ips-admin@ietf.org Errors-To: ips-admin@ietf.org 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: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60 Content-Transfer-Encoding: quoted-printable Content-Transfer-Encoding: quoted-printable Hi, the compatibility of commercial iscsi gateway with reserve-release = mechanism is not widely available, even if everyone agrees that = clustering systems with iscsi targets (instead of expensive FC SAN) = could cut down the costs of the solutions. =20 Any news about target implementation (also not commercial ...) with = release-reserve support? =20 Eugenio =20 eugenio.maffione@telecomitalia.it -----Messaggio originale-----=20 Da: ips-admin@ietf.org per conto di sunzen.w=20 Inviato: lun 01/03/2004 3.19=20 A: ips@ietf.org=20 Cc:=20 Oggetto: [Ips] is a share disk possible on SCSI/iSCSI level? =09 =09 Hi, Storaging networking enables storage consolodation and = deployment.Typically disk array serves as a storage server, its storage is parted and exported via = storage networking protocols such as iSCSI,etc. Share problem arises. Current solutions are mainly = on upper file level, either additionally deploying a NAS or using a SAN file system. Is it possible = on SCSI/iSCSI level? In iSCSI spec, multi session on a target are allowed. is it for = sharing? On SCSI, OSD commands are designed.Is it the way for sharing on disk level? =20 =09 sunzen wangxz@ict.ac.cn 2004-03-01 =09 =09 =09 _______________________________________________ Ips mailing list Ips@ietf.org https://www1.ietf.org/mailman/listinfo/ips =09 =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D CONFIDENTIALITY NOTICE This message and its attachments are addressed solely to the persons above and may contain confidential information. If you have received the message in error, be informed that any use of the content hereof is prohibited. Please return it immediately to the sender and delete the message. Should you have any questions, please contact us by replying to MailAdmin@tilab.com. Thank you =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D _______________________________________________ Ips mailing list Ips@ietf.org https://www1.ietf.org/mailman/listinfo/ips From exim@www1.ietf.org Tue Mar 30 18:21:46 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA29154 for ; Tue, 30 Mar 2004 18:21:46 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B8RjQ-0006Zv-CU for ips-archive@odin.ietf.org; Tue, 30 Mar 2004 17:29:16 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i1ALg7XZ018405 for ips-archive@odin.ietf.org; Tue, 10 Feb 2004 16:42:07 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Aqfdv-0004mm-8H for ips-web-archive@optimus.ietf.org; Tue, 10 Feb 2004 16:42:07 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA20475 for ; Tue, 10 Feb 2004 16:42:04 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1Aqfds-0000Tu-00 for ips-web-archive@ietf.org; Tue, 10 Feb 2004 16:42:04 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Aqfct-0000Jf-00 for ips-web-archive@ietf.org; Tue, 10 Feb 2004 16:41:04 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1Aqfbw-00009F-00 for ips-web-archive@ietf.org; Tue, 10 Feb 2004 16:40:04 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Aqfbv-0004KK-Od; Tue, 10 Feb 2004 16:40:03 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Aqfb2-0001jo-68 for ips@optimus.ietf.org; Tue, 10 Feb 2004 16:39:08 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA20170 for ; Tue, 10 Feb 2004 16:39:05 -0500 (EST) From: wrstuden@wasabisystems.com Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1Aqfaz-0007mY-00 for ips@ietf.org; Tue, 10 Feb 2004 16:39:05 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AqfZz-0007bd-00 for ips@ietf.org; Tue, 10 Feb 2004 16:38:03 -0500 Received: from mononoke.wasabisystems.com ([151.199.66.145]) by ietf-mx with esmtp (Exim 4.12) id 1AqfYx-0007Jw-00 for ips@ietf.org; Tue, 10 Feb 2004 16:37:02 -0500 Received: by mononoke.wasabisystems.com (Postfix, from userid 1021) id DC2AA4013A; Tue, 10 Feb 2004 16:36:58 -0500 (EST) Date: Tue, 10 Feb 2004 13:36:37 -0800 (PST) X-X-Sender: wrstuden@neverwinter.home-net.icnt.net To: Eddy Quicksall Cc: ips@ietf.org Subject: Re: [Ips] iSCSI: reinstatement In-Reply-To: <003201c3f01d$0abca980$0303a8c0@ivvt2dxrc11> Message-ID: References: <003201c3f01d$0abca980$0303a8c0@ivvt2dxrc11> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: ips-admin@ietf.org Errors-To: ips-admin@ietf.org 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: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.3 required=5.0 tests=NO_REAL_NAME autolearn=no version=2.60 On Tue, 10 Feb 2004, Eddy Quicksall wrote: > Maybe I'm reading too much into this... are you really just saying that a > session can't be reinstated? If they can, what about them is reinstated? My understanding is that the session does not "persist" across the session reinstatement action. Yes, there is still a session with the same ID (initiator name + ISID, target name + TSIH), but the I_T nexus was broken by the reinstatement event. So the old tasks die. Take care, Bill _______________________________________________ Ips mailing list Ips@ietf.org https://www1.ietf.org/mailman/listinfo/ips From exim@www1.ietf.org Tue Mar 30 18:33:19 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA01951 for ; Tue, 30 Mar 2004 18:33:19 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B8RjH-0006YH-88 for ips-archive@odin.ietf.org; Tue, 30 Mar 2004 17:29:07 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hAKKW7Mk001224 for ips-archive@odin.ietf.org; Thu, 20 Nov 2003 15:32:07 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AMvTD-0000Ja-Lh for ips-web-archive@optimus.ietf.org; Thu, 20 Nov 2003 15:32:07 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA24360 for ; Thu, 20 Nov 2003 15:31:54 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AMvTC-0001t8-00 for ips-web-archive@ietf.org; Thu, 20 Nov 2003 15:32:06 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AMvTB-0001t0-00 for ips-web-archive@ietf.org; Thu, 20 Nov 2003 15:32:05 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AMvT8-0000IS-Va; Thu, 20 Nov 2003 15:32:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AMvSm-00006D-8g for ips@optimus.ietf.org; Thu, 20 Nov 2003 15:31:40 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA24313 for ; Thu, 20 Nov 2003 15:31:27 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AMvSk-0001sB-00 for ips@ietf.org; Thu, 20 Nov 2003 15:31:38 -0500 Received: from palrel13.hp.com ([156.153.255.238]) by ietf-mx with esmtp (Exim 4.12) id 1AMvSk-0001s7-00 for ips@ietf.org; Thu, 20 Nov 2003 15:31:38 -0500 Received: from rosemail.rose.hp.com (rosemail.rose.hp.com [15.96.64.26]) by palrel13.hp.com (Postfix) with ESMTP id 0F1861C02377 for ; Thu, 20 Nov 2003 12:31:38 -0800 (PST) Received: from rose.hp.com (dhcp-roseor-bec059.rose.hp.com [15.23.142.59]) by rosemail.rose.hp.com with ESMTP (8.7.1/8.7.3 SMKit7.02) id MAA05867 for ; Thu, 20 Nov 2003 12:31:37 -0800 (PST) Message-ID: <3FBD24A5.5080204@rose.hp.com> Date: Thu, 20 Nov 2003 12:31:33 -0800 From: "Mallikarjun C." User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.4) Gecko/20030624 Netscape/7.1 (ax) X-Accept-Language: en-us, en MIME-Version: 1.0 To: ips@ietf.org Subject: Re: [Ips] iSCSI cmd ordering and tagged task References: <20031120172026.99685.qmail@web20713.mail.yahoo.com> <1069354631.25197.33.camel@subjekt.volcom.net> In-Reply-To: <1069354631.25197.33.camel@subjekt.volcom.net> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: ips-admin@ietf.org Errors-To: ips-admin@ietf.org 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 Nick, > Frankly, I will continue to advicate the point that only > ErrorRecoveryLevel=1 and above implementations will be allowed use > multiple connection sessions. Any iSCSI target supporting multiple > connection sessions in a ErrorRecoveryLevel=0 implemenation is broken Why? The iSCSI semantics wrt multi-connection sessions are always true (really relevant based on the operational value of the MaxConnections key), not tied to the operational ErrorRecoveryLevel key. M Nicholas A. Bellinger wrote: > Dan, > > Session wide ordering is a requirement for even single connection > ErrorRecoveryLevel=0 implementations. Please see section 3.2.2.1 for > the MUST requirement. Not supporting CmdSN/ExpCmdSN/MaxCmdSN ordering > requirements is a definate violation of the iSCSI specification in a > simple ErrorRecoveryLevel=0 implementation, let alone a multiple > connection ErrorRecoveryLevel=1 and above implementation. > > One of the key goals of RFC 3347 and the iSCSI draft is to allow iSCSI > vendors to create interoptable high speed implemenations. Leaving out > basic parts of the specification to avoid doing the necessary work to > make the implementation is question interoptable with industry standard > implemenations is a bad position to put ones self into. > > Frankly, I will continue to advicate the point that only > ErrorRecoveryLevel=1 and above implementations will be allowed use > multiple connection sessions. Any iSCSI target supporting multiple > connection sessions in a ErrorRecoveryLevel=0 implemenation is broken > IMHO and does so to support broken iSCSI ErrorRecoveryLevel=0 initiator > implemenations and vendors who believe they can get away with only doing > parts of ErrorRecoveryLevel=1 without doing a complete > ErrorRecoveryLevel=1 implementation. > > Negoitating the ErrorRecoveryLevel=1 key during the leading connection > of a full feature phase iSCSI login means the supporting the nine (9) > requirements of within-command and within-connection recovery from > sections 6.1.4.1 and 6.1.4.2, negoitating the ErrorRecoveryLevel=1 key > without implementing these features is a clear violation of the > specification. > > In order to support the nine (9) requirements of ErrorRecoveryLevel=1 > means supporting Fixed Interval Markers or some other framing mechnisim > to recover from header digest failures where the offset to the next > iSCSI Opcode cannot be reliably determined. (See section 6.1.4.1, > Initiator and Target case C, and section 3.2.8) Also in the > within-command recovery cases from section 6.1.4.1, DataPDUInOrder=No > and DataSequenceInOrder=No cases must also be considered. > > Thanks! > _______________________________________________ Ips mailing list Ips@ietf.org https://www1.ietf.org/mailman/listinfo/ips From exim@www1.ietf.org Tue Mar 30 18:36:20 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA02671 for ; Tue, 30 Mar 2004 18:36:20 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B8RjE-0006Yx-8R for ips-archive@odin.ietf.org; Tue, 30 Mar 2004 17:29:04 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hAIBaEhE024468 for ips-archive@odin.ietf.org; Tue, 18 Nov 2003 06:36:14 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AM49W-0006MZ-Np for ips-web-archive@optimus.ietf.org; Tue, 18 Nov 2003 06:36:14 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA16784 for ; Tue, 18 Nov 2003 06:36:00 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AM49S-0003GC-00 for ips-web-archive@ietf.org; Tue, 18 Nov 2003 06:36:10 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AM49S-0003G9-00 for ips-web-archive@ietf.org; Tue, 18 Nov 2003 06:36:10 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AM49N-0006IX-UC; Tue, 18 Nov 2003 06:36:05 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AM49G-0006ED-Co for ips@optimus.ietf.org; Tue, 18 Nov 2003 06:35:58 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA16737; Tue, 18 Nov 2003 06:35:44 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AM49B-0003FG-00; Tue, 18 Nov 2003 06:35:54 -0500 Received: from mtagate3.uk.ibm.com ([195.212.29.136]) by ietf-mx with esmtp (Exim 4.12) id 1AM49A-0003EJ-00; Tue, 18 Nov 2003 06:35:53 -0500 Received: from d06relay01.portsmouth.uk.ibm.com (d06relay01.uk.ibm.com [9.166.84.147]) by mtagate3.uk.ibm.com (8.12.10/8.12.10) with ESMTP id hAIBW4k3029388; Tue, 18 Nov 2003 11:32:42 GMT Received: from d10ml001.telaviv.ibm.com (d06av02.portsmouth.uk.ibm.com [9.149.37.228]) by d06relay01.portsmouth.uk.ibm.com (8.12.9/NCO/VER6.6) with ESMTP id hAIBUKk9175734; Tue, 18 Nov 2003 11:30:23 GMT In-Reply-To: <20031118085427.97112.qmail@web42001.mail.yahoo.com> To: Alberto Alesina Cc: ips@ietf.org, ips-admin@ietf.org Subject: Re: [Ips] target device MIME-Version: 1.0 X-Mailer: Lotus Notes Release 6.0.2CF2 July 23, 2003 From: Julian Satran Message-ID: Date: Tue, 18 Nov 2003 13:27:21 +0200 X-MIMETrack: Serialize by Router on D10ML001/10/M/IBM(Release 6.0.2CF2|July 23, 2003) at 18/11/2003 13:30:22, Serialize complete at 18/11/2003 13:30:22 Content-Type: multipart/alternative; boundary="=_alternative 003EEDD3C2256DE2_=" Sender: ips-admin@ietf.org Errors-To: ips-admin@ietf.org 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: , This is a multipart message in MIME format. --=_alternative 003EEDD3C2256DE2_= Content-Type: text/plain; charset="US-ASCII" Alberto - determining disk capacity is part of SCSI (see the command set for block devices). iSCSI is only a transport - Julo Alberto Alesina Sent by: ips-admin@ietf.org 18/11/2003 10:54 To ips@ietf.org cc Subject [Ips] target device hello, i am new to iSCSI and have a basic question about iSCSI - how would the initiator know about the disk capacity of the target devices (to calculate the maximum logical block address) ? is this part of the iSCSI protocol? thanks a lot.... alberto alesina Do you Yahoo!? Protect your identity with Yahoo! Mail AddressGuard --=_alternative 003EEDD3C2256DE2_= Content-Type: text/html; charset="US-ASCII"
Alberto - determining disk capacity is part of SCSI (see the command set for block devices). iSCSI is only a transport - Julo


Alberto Alesina <aalesina@yahoo.com>
Sent by: ips-admin@ietf.org

18/11/2003 10:54

To
ips@ietf.org
cc
Subject
[Ips] target device





hello,
i am new to iSCSI and have a basic question about iSCSI - how would the initiator know about the disk capacity of the target devices (to calculate the maximum logical block address) ?  is this part of the iSCSI protocol?
 
thanks a lot....
alberto alesina

Do you Yahoo!?
Protect your identity with Yahoo! Mail AddressGuard

--=_alternative 003EEDD3C2256DE2_=-- _______________________________________________ Ips mailing list Ips@ietf.org https://www1.ietf.org/mailman/listinfo/ips From exim@www1.ietf.org Tue Mar 30 18:38:57 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA03408 for ; Tue, 30 Mar 2004 18:38:57 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B8RjB-0006Yx-83 for ips-archive@odin.ietf.org; Tue, 30 Mar 2004 17:29:01 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i152ejbU011426 for ips-archive@odin.ietf.org; Wed, 4 Feb 2004 21:40:45 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AoZRd-0002yD-1x for ips-web-archive@optimus.ietf.org; Wed, 04 Feb 2004 21:40:45 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA14715 for ; Wed, 4 Feb 2004 21:40:42 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AoZRa-0002hg-00 for ips-web-archive@ietf.org; Wed, 04 Feb 2004 21:40:42 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AoZR1-0002am-00 for ips-web-archive@ietf.org; Wed, 04 Feb 2004 21:40:08 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1AoZQ1-0002S9-00 for ips-web-archive@ietf.org; Wed, 04 Feb 2004 21:39:05 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AoZPy-0002an-3R; Wed, 04 Feb 2004 21:39:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AoZPg-0002Ya-1d for ips@optimus.ietf.org; Wed, 04 Feb 2004 21:38:44 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA14508 for ; Wed, 4 Feb 2004 21:38:40 -0500 (EST) From: wrstuden@wasabisystems.com Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AoZPd-0002O4-00 for ips@ietf.org; Wed, 04 Feb 2004 21:38:41 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AoZOm-0002FD-00 for ips@ietf.org; Wed, 04 Feb 2004 21:37:48 -0500 Received: from mononoke.wasabisystems.com ([151.199.66.145]) by ietf-mx with esmtp (Exim 4.12) id 1AoZO0-00023z-00 for ips@ietf.org; Wed, 04 Feb 2004 21:37:00 -0500 Received: by mononoke.wasabisystems.com (Postfix, from userid 1021) id 3EC8E4014A; Wed, 4 Feb 2004 21:37:01 -0500 (EST) Date: Wed, 4 Feb 2004 18:36:44 -0800 (PST) X-X-Sender: wrstuden@neverwinter.home-net.icnt.net To: ips@ietf.org Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Subject: [Ips] iSNS failover and multi-server configurations Sender: ips-admin@ietf.org Errors-To: ips-admin@ietf.org 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: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.3 required=5.0 tests=NO_REAL_NAME autolearn=no version=2.60 The iSNS draft (draft-ietf-ips-isns-21.txt) mentions the concept of backup servers (especially in the heartbeat PDU) and says it will describe client interatctions with multiple servers (Section 2.8). However I can't find any discussion of client interactions in that section. So can we either have some more text, or some sort of suplimental document that gives guidelines on how to deal with these concepts? I have a few questions, and while I can answer them, I want to make sure my answers agree with everyone else's. :-) Questions: 1) Say a device is using iSNS heartbeats to find the server. Say it starts up and can't connect to the primary server (or specifically it is only hearing messages from a backup server). Say it registers with the backup server. Now say the primary server comes back on line. What does the device need to do? 1a) does it re-register its configuration with the new primary server, or does it assume that the new server synchronized itself before resuming being hte primary server? 1b) does it need to register SCN requests with the new server? Does it need to de-register its old SCN registrations? 2) I see that DHCP can indicate multiple servers. But what about SLP in face of multiple servers? Andy Currid suggested that SLP should only have the most-senior operational server registered. But what happens when either a formerly-off-line server comes back on line or an on-line server goes off-line? SLP does not seem well-suited for "server moved" notifications. Also, with SLP, if a server fails, what are the security considerations for the backup server to be able to de-register the server? Would it be easier for SLP to add a "precedence" attribute and have each server register with SLP, then have the client perform the same failover as DHCP and heartbeat do? Thanks! Take care, Bill _______________________________________________ Ips mailing list Ips@ietf.org https://www1.ietf.org/mailman/listinfo/ips From exim@www1.ietf.org Tue Mar 30 18:49:12 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA06032 for ; Tue, 30 Mar 2004 18:49:12 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B8SyN-0001OA-2R for ips-archive@odin.ietf.org; Tue, 30 Mar 2004 18:48:47 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i2UNmllm005338 for ips-archive@odin.ietf.org; Tue, 30 Mar 2004 18:48:47 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B8SyM-0001O1-To for ips-web-archive@optimus.ietf.org; Tue, 30 Mar 2004 18:48:46 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA05872 for ; Tue, 30 Mar 2004 18:48:41 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B8SyJ-0004OZ-00 for ips-web-archive@ietf.org; Tue, 30 Mar 2004 18:48:43 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B8SxM-0004L3-00 for ips-web-archive@ietf.org; Tue, 30 Mar 2004 18:47:45 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1B8Swj-0004I4-00 for ips-web-archive@ietf.org; Tue, 30 Mar 2004 18:47:05 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B8Swf-0001Ec-Uq; Tue, 30 Mar 2004 18:47:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B8SwN-0001DB-Mf for ips@optimus.ietf.org; Tue, 30 Mar 2004 18:46:43 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA05372 for ; Tue, 30 Mar 2004 18:46:38 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B8SwK-0004Gi-00 for ips@ietf.org; Tue, 30 Mar 2004 18:46:40 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B8SvO-0004EN-00 for ips@ietf.org; Tue, 30 Mar 2004 18:45:43 -0500 Received: from palrel11.hp.com ([156.153.255.246]) by ietf-mx with esmtp (Exim 4.12) id 1B8Suz-0004CI-00 for ips@ietf.org; Tue, 30 Mar 2004 18:45:17 -0500 Received: from rosemail.rose.hp.com (rosemail.rose.hp.com [15.43.209.160]) by palrel11.hp.com (Postfix) with ESMTP id 3275D1C01569 for ; Tue, 30 Mar 2004 15:45:05 -0800 (PST) Received: from rose.hp.com (dhcp-roseor-bdi249.rose.hp.com [15.23.138.249]) by rosemail.rose.hp.com (Postfix) with ESMTP id 6C77384FC for ; Tue, 30 Mar 2004 15:35:59 -0800 (PST) Message-ID: <406A0676.1040509@rose.hp.com> Date: Tue, 30 Mar 2004 15:44:54 -0800 From: "Mallikarjun C." User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.4) Gecko/20030624 Netscape/7.1 (ax) X-Accept-Language: en-us, en MIME-Version: 1.0 To: ips@ietf.org Subject: Re: [Ips] iSCSI: reinstatement References: <002801c416a4$da0b5580$0303a8c0@ivvt2dxrc11> In-Reply-To: <002801c416a4$da0b5580$0303a8c0@ivvt2dxrc11> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: quoted-printable Content-Transfer-Encoding: quoted-printable Sender: ips-admin@ietf.org Errors-To: ips-admin@ietf.org 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: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60 Content-Transfer-Encoding: quoted-printable Content-Transfer-Encoding: quoted-printable Eddy, Here's one scenario to consider. - Logout Response (success) was on its way from the target to the initiator. - TCP connection fails, initiator doesn't see the Logout Response. - In the initiator's view, the connection is "possibly active from the target=92s perspective". - Initiator attempts a connection reinstatement. - When the target receives the new reinstatement Login Request, an explicit logout was already performed in its view. The current Login doesn't trigger the logout function. Mallikarjun Eddy Quicksall wrote: > I just noticed this (=93if an explicit logout was not performed earlier= =94=20 > ). The first part of the paragraph already said =93possibly active=94 w= hich=20 > could only happen if a logout had not been performed earlier. Is this=20 > just an overstatement or am I missing something? >=20 > =20 >=20 > Connection reinstatement is the process of an initiator logging in >=20 > with a ISID-TSIH-CID combination that is possibly active from the >=20 > target=92s perspective, which causes the implicit logging out of the >=20 > connection corresponding to the CID and reinstating a new Full >=20 > Feature Phase iSCSI connection in its place (with the same CID). >=20 > Thus, the TSIH in the Login PDU MUST be non-zero and CID does not >=20 > change during a connection reinstatement. The Login request performs >=20 > the logout function of the old connection if an explicit logout was >=20 > not performed earlier. >=20 > =20 >=20 _______________________________________________ Ips mailing list Ips@ietf.org https://www1.ietf.org/mailman/listinfo/ips From exim@www1.ietf.org Tue Mar 30 22:26:03 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA21722 for ; Tue, 30 Mar 2004 22:26:03 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B8WMC-0001ci-ME for ips-archive@odin.ietf.org; Tue, 30 Mar 2004 22:25:37 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i2V3PaDA006241 for ips-archive@odin.ietf.org; Tue, 30 Mar 2004 22:25:36 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B8WMC-0001ca-HC for ips-web-archive@optimus.ietf.org; Tue, 30 Mar 2004 22:25:36 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA21559 for ; Tue, 30 Mar 2004 22:25:32 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B8WM9-0000Gi-00 for ips-web-archive@ietf.org; Tue, 30 Mar 2004 22:25:33 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B8WJG-0007VG-00 for ips-web-archive@ietf.org; Tue, 30 Mar 2004 22:22:34 -0500 Received: from [65.246.255.50] (helo=mx2.foretec.com) by ietf-mx with esmtp (Exim 4.12) id 1B8WHv-0007LF-00 for ips-web-archive@ietf.org; Tue, 30 Mar 2004 22:21:11 -0500 Received: from optimus22.ietf.org ([132.151.6.22] helo=optimus.ietf.org) by mx2.foretec.com with esmtp (Exim 4.24) id 1B8WA4-0000K4-Vm for ips-web-archive@ietf.org; Tue, 30 Mar 2004 22:13:05 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B8WA1-0000ZS-K1; Tue, 30 Mar 2004 22:13:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B8W9k-0000Yp-F6 for ips@optimus.ietf.org; Tue, 30 Mar 2004 22:12:44 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA21143 for ; Tue, 30 Mar 2004 22:12:40 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B8W9h-0006ti-00 for ips@ietf.org; Tue, 30 Mar 2004 22:12:41 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B8W8m-0006rz-00 for ips@ietf.org; Tue, 30 Mar 2004 22:11:45 -0500 Received: from mononoke.wasabisystems.com ([151.199.66.145]) by ietf-mx with esmtp (Exim 4.12) id 1B8W86-0006q4-00 for ips@ietf.org; Tue, 30 Mar 2004 22:11:02 -0500 Received: from [10.0.0.10] (h-66-166-188-62.sndacagl.covad.net [66.166.188.62]) by mononoke.wasabisystems.com (Postfix) with ESMTP id 41D2D40145; Tue, 30 Mar 2004 22:11:01 -0500 (EST) In-Reply-To: References: Mime-Version: 1.0 (Apple Message framework v613) Content-Type: multipart/signed; protocol="application/pgp-signature"; micalg=pgp-sha1; boundary="Apple-Mail-5--685238774" Message-Id: <94B5C1AA-82BD-11D8-8C42-000A95D14BEC@wasabisystems.com> Content-Transfer-Encoding: 7bit Cc: Black_David@emc.com, ips@ietf.org, David.Weibel@Sun.COM From: William Studenmund Subject: Re: [Ips] iSCSI: clarification? data-in PDU->command status bit Date: Tue, 30 Mar 2004 18:46:16 -0800 To: Julian Satran X-Pgp-Agent: GPGMail 1.0 (v30, 10.3) X-Mailer: Apple Mail (2.613) Sender: ips-admin@ietf.org Errors-To: ips-admin@ietf.org 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: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60 --Apple-Mail-5--685238774 Content-Type: text/plain; charset=US-ASCII; format=flowed Content-Transfer-Encoding: 7bit On Mar 30, 2004, at 6:52 AM, Julian Satran wrote: > I am against saying again what SCSI says already. Julo The problem we're seeing is that while SCSI says it already, people are getting confused by it. So do we clear up confusion or not? :-) Take care, BIll --Apple-Mail-5--685238774 content-type: application/pgp-signature; x-mac-type=70674453; name=PGP.sig content-description: This is a digitally signed message part content-disposition: inline; filename=PGP.sig Content-Transfer-Encoding: 7bit -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.3 (Darwin) iD8DBQFAajEEDJT2Egh26K0RAr6aAJ91g/1AjKexx7TaTqJU5fgyOhFvwQCcC4m1 TC12F0P9PIaMgyZannwNtS0= =32gS -----END PGP SIGNATURE----- --Apple-Mail-5--685238774-- _______________________________________________ Ips mailing list Ips@ietf.org https://www1.ietf.org/mailman/listinfo/ips From exim@www1.ietf.org Wed Mar 31 12:39:55 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA03504 for ; Wed, 31 Mar 2004 12:39:55 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B8jgH-0005fs-KY for ips-archive@odin.ietf.org; Wed, 31 Mar 2004 12:39:29 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i2VHdDDg021812 for ips-archive@odin.ietf.org; Wed, 31 Mar 2004 12:39:13 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B8jgH-0005fi-Dz for ips-web-archive@optimus.ietf.org; Wed, 31 Mar 2004 12:39:13 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA03447 for ; Wed, 31 Mar 2004 12:39:09 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B8jgF-000680-00 for ips-web-archive@ietf.org; Wed, 31 Mar 2004 12:39:11 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B8jfJ-00064k-00 for ips-web-archive@ietf.org; Wed, 31 Mar 2004 12:38:14 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1B8jeP-00061K-00 for ips-web-archive@ietf.org; Wed, 31 Mar 2004 12:37:17 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B8je9-00056R-TW; Wed, 31 Mar 2004 12:37:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B8jdX-000554-S9 for ips@optimus.ietf.org; Wed, 31 Mar 2004 12:36:24 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA03297 for ; Wed, 31 Mar 2004 12:36:19 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B8jdW-0005xP-00 for ips@ietf.org; Wed, 31 Mar 2004 12:36:22 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B8jcV-0005pJ-00 for ips@ietf.org; Wed, 31 Mar 2004 12:35:20 -0500 Received: from mtagate3.de.ibm.com ([195.212.29.152]) by ietf-mx with esmtp (Exim 4.12) id 1B8jbK-0005c5-00 for ips@ietf.org; Wed, 31 Mar 2004 12:34:06 -0500 Received: from d12relay01.megacenter.de.ibm.com (d12relay01.megacenter.de.ibm.com [9.149.165.180]) by mtagate3.de.ibm.com (8.12.10/8.12.10) with ESMTP id i2VHXUxJ133190; Wed, 31 Mar 2004 17:33:30 GMT Received: from d12ml102.megacenter.de.ibm.com (d12av02.megacenter.de.ibm.com [9.149.165.228]) by d12relay01.megacenter.de.ibm.com (8.12.10/NCO/VER6.6) with ESMTP id i2VHXakV005424; Wed, 31 Mar 2004 19:33:36 +0200 In-Reply-To: <94B5C1AA-82BD-11D8-8C42-000A95D14BEC@wasabisystems.com> To: William Studenmund Cc: Black_David@emc.com, David.Weibel@Sun.COM, ips@ietf.org MIME-Version: 1.0 Subject: Re: [Ips] iSCSI: clarification? data-in PDU->command status bit X-Mailer: Lotus Notes Release 6.5.1 January 21, 2004 From: Julian Satran Message-ID: Date: Wed, 31 Mar 2004 19:33:25 +0200 X-MIMETrack: Serialize by Router on D12ML102/12/M/IBM(Release 6.0.2CF2|July 23, 2003) at 31/03/2004 19:33:29 Content-Type: multipart/mixed; boundary="=_mixed 002B578B08256E68_=" Sender: ips-admin@ietf.org Errors-To: ips-admin@ietf.org 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: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.5 required=5.0 tests=AWL,HTML_30_40,HTML_MESSAGE autolearn=no version=2.60 --=_mixed 002B578B08256E68_= Content-Type: multipart/alternative; boundary="=_alternative 002B578B08256E68_=" --=_alternative 002B578B08256E68_= Content-Type: text/plain; charset="US-ASCII" read the errata - julo William Studenmund 30/03/04 18:46 To Julian Satran/Haifa/IBM@IBMIL cc Black_David@emc.com, ips@ietf.org, David.Weibel@Sun.COM Subject Re: [Ips] iSCSI: clarification? data-in PDU->command status bit On Mar 30, 2004, at 6:52 AM, Julian Satran wrote: > I am against saying again what SCSI says already. Julo The problem we're seeing is that while SCSI says it already, people are getting confused by it. So do we clear up confusion or not? :-) Take care, BIll --=_alternative 002B578B08256E68_= Content-Type: text/html; charset="US-ASCII"
read the errata - julo


William Studenmund <wrstuden@wasabisystems.com>

30/03/04 18:46

To
Julian Satran/Haifa/IBM@IBMIL
cc
Black_David@emc.com, ips@ietf.org, David.Weibel@Sun.COM
Subject
Re: [Ips] iSCSI: clarification? data-in PDU->command status bit






On Mar 30, 2004, at 6:52 AM, Julian Satran wrote:


> I am against saying again what SCSI says already. Julo

The problem we're seeing is that while SCSI says it already,
people are getting confused by it.

So do we clear up confusion or not? :-)

Take care,

BIll
--=_alternative 002B578B08256E68_=-- --=_mixed 002B578B08256E68_= Content-Type: application/octet-stream; name="PGP.sig" Content-Disposition: attachment; filename="PGP.sig" Content-Transfer-Encoding: base64 Content-Transfer-Encoding: base64 Content-Transfer-Encoding: base64 Content-Transfer-Encoding: base64 LS0tLS1CRUdJTiBQR1AgU0lHTkFUVVJFLS0tLS0NClZlcnNpb246IEdudVBHIHYxLjIuMyAoRGFy d2luKQ0KDQppRDhEQlFGQWFqRUVESlQyRWdoMjZLMFJBcjZhQUo5MWcvMUFqS2V4eDdUYVRxSlU1 Zmd5T2hGdndRQ2NDNG0xDQpUQzEyRjBQOVBJYU1neVphbm53TnRTMD0NCj0zMmdTDQotLS0tLUVO RCBQR1AgU0lHTkFUVVJFLS0tLS0NCg== --=_mixed 002B578B08256E68_=-- _______________________________________________ Ips mailing list Ips@ietf.org https://www1.ietf.org/mailman/listinfo/ips From exim@www1.ietf.org Wed Mar 31 17:19:13 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA16291 for ; Wed, 31 Mar 2004 17:19:13 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B8o2n-0003JA-UU for ips-archive@odin.ietf.org; Wed, 31 Mar 2004 17:18:46 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i2VMIjE0012716 for ips-archive@odin.ietf.org; Wed, 31 Mar 2004 17:18:45 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B8o2n-0003J1-KJ for ips-web-archive@optimus.ietf.org; Wed, 31 Mar 2004 17:18:45 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA16258 for ; Wed, 31 Mar 2004 17:18:41 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B8o2l-0005wQ-00 for ips-web-archive@ietf.org; Wed, 31 Mar 2004 17:18:43 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B8o1l-0005nM-00 for ips-web-archive@ietf.org; Wed, 31 Mar 2004 17:17:42 -0500 Received: from [65.246.255.50] (helo=mx2.foretec.com) by ietf-mx with esmtp (Exim 4.12) id 1B8o00-0005ZD-00 for ips-web-archive@ietf.org; Wed, 31 Mar 2004 17:15:52 -0500 Received: from optimus22.ietf.org ([132.151.6.22] helo=optimus.ietf.org) by mx2.foretec.com with esmtp (Exim 4.24) id 1B8o00-0003Eb-Qx for ips-web-archive@ietf.org; Wed, 31 Mar 2004 17:15:52 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B8nni-0001VF-6S; Wed, 31 Mar 2004 17:03:10 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B8nnW-0001RF-2n for ips@optimus.ietf.org; Wed, 31 Mar 2004 17:02:58 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA15330 for ; Wed, 31 Mar 2004 17:02:54 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B8nnT-0004uB-00 for ips@ietf.org; Wed, 31 Mar 2004 17:02:55 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B8nmh-0004o2-00 for ips@ietf.org; Wed, 31 Mar 2004 17:02:08 -0500 Received: from mononoke.wasabisystems.com ([151.199.66.145]) by ietf-mx with esmtp (Exim 4.12) id 1B8nlF-0004gG-00 for ips@ietf.org; Wed, 31 Mar 2004 17:00:37 -0500 Received: from [10.0.0.10] (h-66-166-188-62.sndacagl.covad.net [66.166.188.62]) by mononoke.wasabisystems.com (Postfix) with ESMTP id 1751640151; Wed, 31 Mar 2004 17:00:35 -0500 (EST) In-Reply-To: References: Mime-Version: 1.0 (Apple Message framework v613) Content-Type: multipart/signed; protocol="application/pgp-signature"; micalg=pgp-sha1; boundary="Apple-Mail-3--615986241" Message-Id: Content-Transfer-Encoding: 7bit Cc: Black_David@emc.com, ips@ietf.org, David.Weibel@Sun.COM From: William Studenmund Subject: Re: [Ips] iSCSI: clarification? data-in PDU->command status bit Date: Wed, 31 Mar 2004 14:00:28 -0800 To: Julian Satran X-Pgp-Agent: GPGMail 1.0 (v30, 10.3) X-Mailer: Apple Mail (2.613) Sender: ips-admin@ietf.org Errors-To: ips-admin@ietf.org 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: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60 --Apple-Mail-3--615986241 Content-Type: text/plain; charset=US-ASCII; format=flowed Content-Transfer-Encoding: 7bit On Mar 31, 2004, at 9:33 AM, Julian Satran wrote: > read the errata - julo Uhm, Julian, this whole thread has been in response to the errata. I fail to see how "read the errata" will change my mind. "If Status is sent with the data it MUST not be sent again with a SCSI Response PDU as this would violate SCSI rules (a single ...." David's concern is confusion over "with a SCSI Response PDU". You (and I and DLB and most of the folks on the list) know that means you don't send a PDU; you just removed the need. A few people new to the spec, though, seem to think you still need to send the SCSI Response PDU, just that it isn't carrying SCSI status. Or something like that. Adding a "MUST" will make things clear. I'd suggest (if we can still make the change) something like: "If Status is sent with the data it MUST not be sent again (SCSI Response PDU MUST not be sent) as this would violate SCSI rules (a single ...." Take care, Bill --Apple-Mail-3--615986241 content-type: application/pgp-signature; x-mac-type=70674453; name=PGP.sig content-description: This is a digitally signed message part content-disposition: inline; filename=PGP.sig Content-Transfer-Encoding: 7bit -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.3 (Darwin) iD8DBQFAaz+CDJT2Egh26K0RAu9qAJ41mKrrUGD5umBdEaE/JrZK+mpB1QCcCuMx Mo6g6aZ+M2688TCzHjQONMM= =2wAQ -----END PGP SIGNATURE----- --Apple-Mail-3--615986241-- _______________________________________________ Ips mailing list Ips@ietf.org https://www1.ietf.org/mailman/listinfo/ips From exim@www1.ietf.org Wed Mar 31 17:33:04 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA17128 for ; Wed, 31 Mar 2004 17:33:04 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B8oGE-00056W-89 for ips-archive@odin.ietf.org; Wed, 31 Mar 2004 17:32:38 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i2VMWckp019621 for ips-archive@odin.ietf.org; Wed, 31 Mar 2004 17:32:38 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B8oGE-00056O-1E for ips-web-archive@optimus.ietf.org; Wed, 31 Mar 2004 17:32:38 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA17122 for ; Wed, 31 Mar 2004 17:32:34 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B8oGB-0006vw-00 for ips-web-archive@ietf.org; Wed, 31 Mar 2004 17:32:35 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B8oFH-0006tz-00 for ips-web-archive@ietf.org; Wed, 31 Mar 2004 17:31:40 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1B8oEg-0006s9-00 for ips-web-archive@ietf.org; Wed, 31 Mar 2004 17:31:02 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B8oEf-0004yy-Pj; Wed, 31 Mar 2004 17:31:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B8oEL-0004yF-Fc for ips@optimus.ietf.org; Wed, 31 Mar 2004 17:30:41 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA17074 for ; Wed, 31 Mar 2004 17:30:37 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B8oEJ-0006rD-00 for ips@ietf.org; Wed, 31 Mar 2004 17:30:39 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B8oDO-0006na-00 for ips@ietf.org; Wed, 31 Mar 2004 17:29:43 -0500 Received: from mercury.lss.emc.com ([168.159.100.12] helo=mercury.eng.emc.com) by ietf-mx with esmtp (Exim 4.12) id 1B8oCb-0006iJ-00 for ips@ietf.org; Wed, 31 Mar 2004 17:28:53 -0500 Received: by mercury.lss.emc.com with Internet Mail Service (5.5.2656.59) id <2ARDWYH5>; Wed, 31 Mar 2004 17:28:24 -0500 Message-ID: From: "brown, david1 (eng)" To: "'William Studenmund'" Cc: "Black, David" , ips@ietf.org, David.Weibel@Sun.COM, Julian Satran Subject: RE: [Ips] iSCSI: clarification? data-in PDU->command status bit Date: Wed, 31 Mar 2004 17:28:23 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2656.59) Content-Type: text/plain Sender: ips-admin@ietf.org Errors-To: ips-admin@ietf.org 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: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=2.2 required=5.0 tests=FROM_HAS_ULINE_NUMS autolearn=no version=2.60 The language in the iSCSI spec is clear. The last paragraph of section 3.2 says that there is no difference between a status and a response. The last paragraph of 3.5.1.5 says that you don't send a response when the data-in PDU contains a status. Besides, if the developer thought for even a moment about why something called StatSN was counting something called a Response PDU, he or she would realize that sending a separate response would mangle the StatSN count. If the developer thought about the logic behind phase collapse, he or she might realize that the status/response is bundled in with the data PDU in order to avoid the need to send it separately. Even if we assume the developer made the mistake despite reading the specs carefully, that doesn't mean the specs are at fault. It looks like the developer ran through at least two red lights and two yellow lights; that doesn't mean a fifth light would help. Besides, such an amendment to the spec at this stage would set a bad precedent. Should we alter the spec each time some device in beta-test violates the spec, as long as the developer says it's just a misunderstanding? If you could find one other person on this mailing list who honestly misunderstood the implications of sending status with a data PDU, it would strengthen the argument considerably. DJ Brown -----Original Message----- From: ips-admin@ietf.org [mailto:ips-admin@ietf.org] On Behalf Of William Studenmund Sent: Wednesday, March 31, 2004 5:00 PM To: Julian Satran Cc: Black_David@emc.com; ips@ietf.org; David.Weibel@Sun.COM Subject: Re: [Ips] iSCSI: clarification? data-in PDU->command status bit On Mar 31, 2004, at 9:33 AM, Julian Satran wrote: > read the errata - julo Uhm, Julian, this whole thread has been in response to the errata. I fail to see how "read the errata" will change my mind. "If Status is sent with the data it MUST not be sent again with a SCSI Response PDU as this would violate SCSI rules (a single ...." David's concern is confusion over "with a SCSI Response PDU". You (and I and DLB and most of the folks on the list) know that means you don't send a PDU; you just removed the need. A few people new to the spec, though, seem to think you still need to send the SCSI Response PDU, just that it isn't carrying SCSI status. Or something like that. Adding a "MUST" will make things clear. I'd suggest (if we can still make the change) something like: "If Status is sent with the data it MUST not be sent again (SCSI Response PDU MUST not be sent) as this would violate SCSI rules (a single ...." Take care, Bill _______________________________________________ Ips mailing list Ips@ietf.org https://www1.ietf.org/mailman/listinfo/ips From exim@www1.ietf.org Wed Mar 31 21:14:15 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA27022 for ; Wed, 31 Mar 2004 21:14:15 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B8riG-0000VR-6e for ips-archive@odin.ietf.org; Wed, 31 Mar 2004 21:13:48 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i312DmFi001945 for ips-archive@odin.ietf.org; Wed, 31 Mar 2004 21:13:48 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B8riF-0000VI-Vn for ips-web-archive@optimus.ietf.org; Wed, 31 Mar 2004 21:13:48 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA27013 for ; Wed, 31 Mar 2004 21:13:44 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B8riD-0004rg-00 for ips-web-archive@ietf.org; Wed, 31 Mar 2004 21:13:45 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B8rhG-0004pV-00 for ips-web-archive@ietf.org; Wed, 31 Mar 2004 21:12:47 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1B8rgf-0004nL-00 for ips-web-archive@ietf.org; Wed, 31 Mar 2004 21:12:09 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B8rgX-0000Kq-IW; Wed, 31 Mar 2004 21:12:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B8rgN-0000KQ-D7 for ips@optimus.ietf.org; Wed, 31 Mar 2004 21:11:51 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA26964 for ; Wed, 31 Mar 2004 21:11:41 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B8rgE-0004mJ-00 for ips@ietf.org; Wed, 31 Mar 2004 21:11:42 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B8rfK-0004jV-00 for ips@ietf.org; Wed, 31 Mar 2004 21:10:46 -0500 Received: from mononoke.wasabisystems.com ([151.199.66.145]) by ietf-mx with esmtp (Exim 4.12) id 1B8reQ-0004dW-00 for ips@ietf.org; Wed, 31 Mar 2004 21:09:50 -0500 Received: from [10.0.0.10] (h-66-166-188-62.sndacagl.covad.net [66.166.188.62]) by mononoke.wasabisystems.com (Postfix) with ESMTP id 94C8540158; Wed, 31 Mar 2004 21:09:49 -0500 (EST) In-Reply-To: References: Mime-Version: 1.0 (Apple Message framework v613) Content-Type: multipart/signed; protocol="application/pgp-signature"; micalg=pgp-sha1; boundary="Apple-Mail-4--601033304" Message-Id: Content-Transfer-Encoding: 7bit Cc: "Black, David" , ips@ietf.org, David.Weibel@Sun.COM, Julian Satran , William Studenmund From: William Studenmund Subject: Re: [Ips] iSCSI: clarification? data-in PDU->command status bit Date: Wed, 31 Mar 2004 18:09:41 -0800 To: "brown, david1 (eng)" X-Pgp-Agent: GPGMail 1.0 (v30, 10.3) X-Mailer: Apple Mail (2.613) Sender: ips-admin@ietf.org Errors-To: ips-admin@ietf.org 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: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60 --Apple-Mail-4--601033304 Content-Type: text/plain; charset=US-ASCII; format=flowed Content-Transfer-Encoding: 7bit On Mar 31, 2004, at 2:28 PM, brown, david1 (eng) wrote: > The language in the iSCSI spec is clear. The last paragraph of > section 3.2 > says that there is no difference between a status and a response. The > last > paragraph of 3.5.1.5 says that you don't send a response when the > data-in > PDU contains a status. We must have a different idea of what clear means. Note also that we were talking about section 10.7.3, not section 3.2 or 3.5. > Besides, if the developer thought for even a moment about why something > called StatSN was counting something called a Response PDU, he or she > would > realize that sending a separate response would mangle the StatSN > count. If > the developer thought about the logic behind phase collapse, he or she > might > realize that the status/response is bundled in with the data PDU in > order to > avoid the need to send it separately. > > Even if we assume the developer made the mistake despite reading the > specs > carefully, that doesn't mean the specs are at fault. It looks like the > developer ran through at least two red lights and two yellow lights; > that > doesn't mean a fifth light would help. "Fault" is far stronger a term than I had in mind. I do not think the spec is at "fault," I think there is a point where it can be made more clear. A number of other persons have agreed. > Besides, such an amendment to the spec at this stage would set a bad > precedent. Should we alter the spec each time some device in beta-test > violates the spec, as long as the developer says it's just a > misunderstanding? Note: this moment is our last chance to change the spec. After the author's "48 hours" is done, the iSCSI RFC is done. Any changes require a new RFC. I see no problem with making a minor, clarifying change at this point in time. After all, I thought that was the point. I think that any change should be considered on a case-by-case basis. The fact that one change was or wasn't made should not impact other changes. And if the change makes the spec clearer, in general, why wouldn't we do it? [I do concede that we may want to not make the change now just to reduce the number of changes, but that is a different criteria :-) ] > If you could find one other person on this mailing list who honestly > misunderstood the implications of sending status with a data PDU, it > would > strengthen the argument considerably. I don't think that criteria is a good one. My concern with it is that it requires persons on this list to share the confusion. I'm more concerned with people who aren't on the list. The persons who will be using iSCSI in one, two, three, or ten years. _I_ am not confused on this point (no SCSI Command Response needed with phase-collapsed read), however I can see a place (mentioned before) where someone could, unluckily, come away with an incorrect understanding. Given that, I can see how either proposed change would improve clarity. Take care, Bill --Apple-Mail-4--601033304 content-type: application/pgp-signature; x-mac-type=70674453; name=PGP.sig content-description: This is a digitally signed message part content-disposition: inline; filename=PGP.sig Content-Transfer-Encoding: 7bit -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.3 (Darwin) iD8DBQFAa3nsDJT2Egh26K0RAhIOAJwI2O8tMsxDNLfdEVKJerHeP1dBJgCcChbo tdLXLQeSbuAAAE7OHQ6NhcI= =LaSy -----END PGP SIGNATURE----- --Apple-Mail-4--601033304-- _______________________________________________ Ips mailing list Ips@ietf.org https://www1.ietf.org/mailman/listinfo/ips