From exim@www1.ietf.org Fri Apr 2 04:20:34 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 EAA00739 for ; Fri, 2 Apr 2004 04:20:34 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B9Gpo-0003FI-US for ips-archive@odin.ietf.org; Fri, 02 Apr 2004 00:03:17 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i3253GR2012477 for ips-archive@odin.ietf.org; Fri, 2 Apr 2004 00:03:16 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B9E0u-00029K-5t for ips-web-archive@optimus.ietf.org; Thu, 01 Apr 2004 21:02:32 -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 VAA22320 for ; Thu, 1 Apr 2004 21:02:26 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B9E0r-0000To-00 for ips-web-archive@ietf.org; Thu, 01 Apr 2004 21:02:29 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B9Dzs-0000Ip-00 for ips-web-archive@ietf.org; Thu, 01 Apr 2004 21:01:29 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1B9Dyu-00007x-00 for ips-web-archive@ietf.org; Thu, 01 Apr 2004 21:00:28 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B9ADU-0007tu-QH; Thu, 01 Apr 2004 16:59:16 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B97zN-0001wH-A3 for ips@optimus.ietf.org; Thu, 01 Apr 2004 14:36: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 OAA27063 for ; Thu, 1 Apr 2004 14:36:17 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B97zA-0001PT-00 for ips@ietf.org; Thu, 01 Apr 2004 14:36:20 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B97yJ-0001IH-00 for ips@ietf.org; Thu, 01 Apr 2004 14:35:28 -0500 Received: from p1.almaden.ibm.com ([198.4.83.52] helo=almaden.ibm.com) by ietf-mx with esmtp (Exim 4.12) id 1B97xL-00017m-00 for ips@ietf.org; Thu, 01 Apr 2004 14:34:27 -0500 Received: from porter.almaden.ibm.com (porter.almaden.ibm.com [9.1.25.138]) by almaden.ibm.com (AIX4.3/8.9.3p2/8.9.3) with ESMTP id LAA47780; Thu, 1 Apr 2004 11:33:54 -0800 Received: from porter.almaden.ibm.com (localhost.localdomain [127.0.0.1]) by porter.almaden.ibm.com (8.12.8/8.12.8) with ESMTP id i31JXsDX004867; Thu, 1 Apr 2004 11:33:54 -0800 Received: (from dfsmith@localhost) by porter.almaden.ibm.com (8.12.8/8.12.8/Submit) id i31JXsdg004865; Thu, 1 Apr 2004 11:33:54 -0800 Date: Thu, 1 Apr 2004 11:33:54 -0800 From: "Daniel F. Smith" To: William Studenmund Cc: ips@ietf.org Subject: Re: [Ips] iSCSI: clarification? data-in PDU->command status bit Message-ID: <20040401193354.GA4853@porter.almaden.ibm.com> Reply-To: dfsmith@almaden.ibm.com Mail-Followup-To: William Studenmund , ips@ietf.org References: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.4.1i 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 What you, and very likely other implementors, might like to author is an Internet Draft with the title "Implementation considerations for iSCSI (RFC xxxx)" where items that are not explicitly clear are laid down. IDs are easy to make and, as far as I know, there are no requirements as to authorship. That way the ID can be kept up to date as a kind of implementors' FAQ while the standard is unchanging. Daniel Smith -- IBM Almaden Research Center, K01F/E2, 650 Harry Road, San Jose CA 95120-6099 USA Phone: +1(408)927-2072 William Studenmund scribed the following, on or around Wed, Mar 31, 2004 at 06:09:41PM -0800: > > 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 _______________________________________________ Ips mailing list Ips@ietf.org https://www1.ietf.org/mailman/listinfo/ips From exim@www1.ietf.org Fri Apr 2 15:43:40 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 PAA27831 for ; Fri, 2 Apr 2004 15:43:39 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B9SJS-0007dr-JP for ips-archive@odin.ietf.org; Fri, 02 Apr 2004 12:18:39 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i32HIc0u029376 for ips-archive@odin.ietf.org; Fri, 2 Apr 2004 12:18:38 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B9QTc-0004PL-8a for ips-web-archive@optimus.ietf.org; Fri, 02 Apr 2004 10:21:01 -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 KAA13400 for ; Fri, 2 Apr 2004 10:20:57 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B9QTa-0005tT-00 for ips-web-archive@ietf.org; Fri, 02 Apr 2004 10:20:58 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B9QSc-0005ma-00 for ips-web-archive@ietf.org; Fri, 02 Apr 2004 10:19:59 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1B9QSA-0005g1-00 for ips-web-archive@ietf.org; Fri, 02 Apr 2004 10:19:30 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B9N7h-0002XK-Mw; Fri, 02 Apr 2004 06:46:09 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B9JN0-0000U0-HE for ips@optimus.ietf.org; Fri, 02 Apr 2004 02:45: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 CAA27332 for ; Fri, 2 Apr 2004 02:45:39 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B9JMw-0004kH-00 for ips@ietf.org; Fri, 02 Apr 2004 02:45:38 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B9JM1-0004d1-00 for ips@ietf.org; Fri, 02 Apr 2004 02:44:42 -0500 Received: from web12824.mail.yahoo.com ([216.136.174.205]) by ietf-mx with smtp (Exim 4.12) id 1B9JLD-0004XU-00 for ips@ietf.org; Fri, 02 Apr 2004 02:43:51 -0500 Message-ID: <20040402074351.20430.qmail@web12824.mail.yahoo.com> Received: from [141.158.91.170] by web12824.mail.yahoo.com via HTTP; Thu, 01 Apr 2004 23:43:51 PST Date: Thu, 1 Apr 2004 23:43:51 -0800 (PST) From: Luben Tuikov Subject: RE: [Ips] iSCSI: clarification? data-in PDU->command status bit To: "brown, david1 \(eng\)" , "'William Studenmund'" Cc: "Black, David" , ips@ietf.org, David.Weibel@Sun.COM, Julian Satran In-Reply-To: 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 couldn't agree more. Plus SAM-2 is prerequisite to any attempt at implementing or even reading and understanding iSCSI. I understand that there _could_ be some confusion to someone totally unfamiliar with SCSI and iSCSI, but we cannot accomodate for all those "confusions" -- we might as well copy SAM-2 right in (and then there'd still be confusions :-) ). The spec is consistent, and for completeness SAM-2 is a prerequisite -- iSCSI need not be changed for this. -- Luben P.S. From SAM-2's perspective, why would someone send status for a task twice when the task's lifetime ended when the 1st status was received? >From iSCSI's perspective, StatSN window has moved, as DJ pointed out. --- "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. > > 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 _______________________________________________ Ips mailing list Ips@ietf.org https://www1.ietf.org/mailman/listinfo/ips From exim@www1.ietf.org Fri Apr 2 16:59: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 QAA05077 for ; Fri, 2 Apr 2004 16:59: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 1B9Wga-0001f4-DT for ips-archive@odin.ietf.org; Fri, 02 Apr 2004 16:58:50 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i32Lwm4k006387 for ips-archive@odin.ietf.org; Fri, 2 Apr 2004 16:58:48 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B9Wga-0001eX-47 for ips-web-archive@optimus.ietf.org; Fri, 02 Apr 2004 16:58: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 QAA04854 for ; Fri, 2 Apr 2004 16:58:45 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B9WgY-0002rZ-00 for ips-web-archive@ietf.org; Fri, 02 Apr 2004 16:58:46 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B9Wcq-00021G-00 for ips-web-archive@ietf.org; Fri, 02 Apr 2004 16:54:57 -0500 Received: from [65.246.255.50] (helo=mx2.foretec.com) by ietf-mx with esmtp (Exim 4.12) id 1B9WaN-0001S5-03 for ips-web-archive@ietf.org; Fri, 02 Apr 2004 16:52:23 -0500 Received: from optimus22.ietf.org ([132.151.6.22] helo=optimus.ietf.org) by mx2.foretec.com with esmtp (Exim 4.24) id 1B9WTi-0007oK-D7 for ips-web-archive@ietf.org; Fri, 02 Apr 2004 16:45:30 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B9WTO-0002gp-Pv; Fri, 02 Apr 2004 16:45:10 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B9Uub-0006tP-3R for ips@optimus.ietf.org; Fri, 02 Apr 2004 15:05: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 PAA25513 for ; Fri, 2 Apr 2004 15:05:05 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B9UuY-0006gx-00 for ips@ietf.org; Fri, 02 Apr 2004 15:05:06 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B9UtY-0006Ze-00 for ips@ietf.org; Fri, 02 Apr 2004 15:04:04 -0500 Received: from web12826.mail.yahoo.com ([216.136.174.207]) by ietf-mx with smtp (Exim 4.12) id 1B9Usb-0006TC-00 for ips@ietf.org; Fri, 02 Apr 2004 15:03:05 -0500 Message-ID: <20040402200304.22020.qmail@web12826.mail.yahoo.com> Received: from [141.158.91.170] by web12826.mail.yahoo.com via HTTP; Fri, 02 Apr 2004 12:03:04 PST Date: Fri, 2 Apr 2004 12:03:04 -0800 (PST) From: Luben Tuikov Subject: Re: [Ips] iSCSI: clarification? data-in PDU->command status bit To: William Studenmund Cc: "Black, David" , ips@ietf.org, David.Weibel@Sun.COM, "brown, david1 \(eng\)" , Julian Satran In-Reply-To: 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 --- William Studenmund wrote: > > I believe you (and a few others) missed the point of misunderstanding. > The misunderstanding I was referring to was not that you can't send > status twice, it was that you can't send a SCSI Command Response > PDU that doesn't carry status; > sending status is the sole purpose of the PDU. ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ I believe that this statement (underlined above) is pretty clear to everyone, or at least it _should_ be pretty clear to an engineer. I don't think an _engineer_ can miss it. I think this thread didn't start with this misunderstanding. I believe it started with the fact that a broken target sent SCSI status twice, 1st as part of READ and 2nd as part of SCSI Response. > Thus once you've sent status, the PDU is neither needed > nor appropriate. As the SCSI Command Response PDU is an iSCSI > concept, no amount of reference to SAM-2 will help the situation. Returning status and response _is_ a SAM thing. iSCSI as an interconnect has to accomodate it and stipulate how it implements it. The reference in SAM-2 is 5.1 Service Response, and 5.3.1 Status, those are exactly iSCSI 10.4.2 and 10.4.3. The iSCSI reference is 3.2, first paragraph, 3.1 second last paragraph and 3.5.1.2 SCSI Response for exact mapping and of course 10.4 SCSI Response. Also it is important to understand _why_ "once you've sent status, the PDU is neither needed nor appropriate". > To be honest, I am puzzled as to why this argument has gone on so long. I agree, it should've ended immediately as "broken implementation of a target -- tell them to fix it". I think that most of those misunderstandings are due to ppl not paying enough attention or not reading the whole spec. Some of them just read the PDU description and off they go implementing iSCSI. > This misunderstanding made it into code that was put up for interop > testing. The other side of the interop testing didn't feel sufficiently > bolstered as to just quote a section number to resolve the issue. When > raised on this list, a number of us said, "Yes, that can be made > better." > We are (or were earlier this week) in a period when such small, > clarifying > changes are appropriate. So why not make it better? I really don't see why whenever someone implements a buggy iSCSI Target/Initiator, it is immediately the fault of the iSCSI spec. In fact I contend that 99.9% if the time it's the other way around. -- Luben _______________________________________________ Ips mailing list Ips@ietf.org https://www1.ietf.org/mailman/listinfo/ips From exim@www1.ietf.org Fri Apr 2 17:03:48 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 RAA05838 for ; Fri, 2 Apr 2004 17:03:48 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B9Wkz-00032U-8O for ips-archive@odin.ietf.org; Fri, 02 Apr 2004 17:03:21 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i32M3Ln4011682 for ips-archive@odin.ietf.org; Fri, 2 Apr 2004 17:03:21 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B9Wky-00032G-6Y for ips-web-archive@optimus.ietf.org; Fri, 02 Apr 2004 17:03: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 RAA05823 for ; Fri, 2 Apr 2004 17:03:17 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B9Wkw-0003qM-00 for ips-web-archive@ietf.org; Fri, 02 Apr 2004 17:03:18 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B9Who-00037i-00 for ips-web-archive@ietf.org; Fri, 02 Apr 2004 17:00:06 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1B9We2-0002ET-00 for ips-web-archive@ietf.org; Fri, 02 Apr 2004 16:56:10 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B9Wdt-0000pV-DK; Fri, 02 Apr 2004 16:56:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B9WdT-0000hK-IN for ips@optimus.ietf.org; Fri, 02 Apr 2004 16:55: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 QAA04402 for ; Fri, 2 Apr 2004 16:55:32 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B9WdR-00027z-00 for ips@ietf.org; Fri, 02 Apr 2004 16:55:33 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B9WaT-0001Tn-00 for ips@ietf.org; Fri, 02 Apr 2004 16:52:29 -0500 Received: from mononoke.wasabisystems.com ([151.199.66.145]) by ietf-mx with esmtp (Exim 4.12) id 1B9WZI-0001GT-00 for ips@ietf.org; Fri, 02 Apr 2004 16:51:16 -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 ADB9540148; Fri, 2 Apr 2004 16:51:15 -0500 (EST) In-Reply-To: <20040402200105.95261.qmail@web12825.mail.yahoo.com> References: <20040402200105.95261.qmail@web12825.mail.yahoo.com> Mime-Version: 1.0 (Apple Message framework v613) Content-Type: multipart/signed; protocol="application/pgp-signature"; micalg=pgp-sha1; boundary="Apple-Mail-2--443748501" Message-Id: Content-Transfer-Encoding: 7bit Cc: ips@ietf.org From: William Studenmund Subject: Re: [Ips] iSCSI: clarification? data-in PDU->command status bit Date: Fri, 2 Apr 2004 13:51:06 -0800 To: Luben Tuikov 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-2--443748501 Content-Type: text/plain; charset=US-ASCII; format=flowed Content-Transfer-Encoding: 7bit On Apr 2, 2004, at 12:01 PM, Luben Tuikov wrote: > --- William Studenmund wrote: >> >> I believe you (and a few others) missed the point of misunderstanding. >> The misunderstanding I was referring to was not that you can't send >> status twice, it was that you can't send a SCSI Command Response >> PDU that doesn't carry status; >> sending status is the sole purpose of the PDU. > ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ > > I believe that this statement (underlined above) is pretty clear to > everyone, or at least it _should_ be pretty clear to an engineer. > I don't think an _engineer_ can miss it. I actually just reviewed the spec, and it can be missed. It's never spelled out. It's strongly inferred, but it's never stated (that there is no reason for the PDU without status). > I think this thread didn't start with this misunderstanding. I believe > it > started with the fact that a broken target sent SCSI status twice, 1st > as > part of READ and 2nd as part of SCSI Response. I agree that we are talking about a target that sent status as part of a READ and then sent a SCSI Response. However the initial part of this thread indicated to me that the confusion was about what the SCSI Response PDU was (not) needed for. If the confusion had been that status was being sent twice, then all of the references to SAM would have cleared things up immediately. >> Thus once you've sent status, the PDU is neither needed >> nor appropriate. As the SCSI Command Response PDU is an iSCSI >> concept, no amount of reference to SAM-2 will help the situation. > > Returning status and response _is_ a SAM thing. iSCSI as an > interconnect > has to accomodate it and stipulate how it implements it. > > The reference in SAM-2 is 5.1 Service Response, and 5.3.1 Status, those > are exactly iSCSI 10.4.2 and 10.4.3. > > The iSCSI reference is 3.2, first paragraph, 3.1 second last paragraph > and > 3.5.1.2 SCSI Response for exact mapping and of course 10.4 SCSI > Response. > > Also it is important to understand _why_ "once you've sent status, > the PDU is neither needed nor appropriate". I agree. I see two reasons. One is the SCSI requirement that you send status once, which I think the spec states clearly now. The other is that the PDU has no use other than SCSI status. That is what I'm wanting more emphasis on. >> To be honest, I am puzzled as to why this argument has gone on so >> long. > > I agree, it should've ended immediately as "broken implementation of > a target -- tell them to fix it". See below. > I think that most of those misunderstandings are due to ppl not paying > enough attention or not reading the whole spec. Some of them just read > the PDU description and off they go implementing iSCSI. >> This misunderstanding made it into code that was put up for interop >> testing. The other side of the interop testing didn't feel >> sufficiently >> bolstered as to just quote a section number to resolve the issue. When >> raised on this list, a number of us said, "Yes, that can be made >> better." >> We are (or were earlier this week) in a period when such small, >> clarifying >> changes are appropriate. So why not make it better? > > I really don't see why whenever someone implements a buggy iSCSI > Target/Initiator, it is immediately the fault of the iSCSI spec. In > fact > I contend that 99.9% if the time it's the other way around. You're the second person to use the word, "fault," in reference to this thread. Why? I don't think it's the iSCSI spec's "fault" that this happened, I just am able to see where someone might get a different impression of what the spec is saying than what it really meant. So why can't we just decide, "this change will make the text clearer," and do it? Assuming we're still in a window when Julian is able to make editorial changes. Take care, Bill --Apple-Mail-2--443748501 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) iD8DBQFAbeBQDJT2Egh26K0RAk4pAJ9ATn4Dov1UGYsnrY1aKKuyyhlWOgCfTH0x kyAt7UPkPAY+f6+rdr8i5vk= =e4TY -----END PGP SIGNATURE----- --Apple-Mail-2--443748501-- _______________________________________________ Ips mailing list Ips@ietf.org https://www1.ietf.org/mailman/listinfo/ips From exim@www1.ietf.org Fri Apr 2 17:25: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 RAA09090 for ; Fri, 2 Apr 2004 17:25: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 1B9X5n-00020t-SY for ips-archive@odin.ietf.org; Fri, 02 Apr 2004 17:24:52 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i32MOp4M007740 for ips-archive@odin.ietf.org; Fri, 2 Apr 2004 17:24:51 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B9X5n-00020l-JJ for ips-web-archive@optimus.ietf.org; Fri, 02 Apr 2004 17:24: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 RAA08885 for ; Fri, 2 Apr 2004 17:24:48 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B9X5l-0000by-00 for ips-web-archive@ietf.org; Fri, 02 Apr 2004 17:24:49 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B9X13-0007U5-00 for ips-web-archive@ietf.org; Fri, 02 Apr 2004 17:19:58 -0500 Received: from [65.246.255.50] (helo=mx2.foretec.com) by ietf-mx with esmtp (Exim 4.12) id 1B9Wy2-0006bI-03 for ips-web-archive@ietf.org; Fri, 02 Apr 2004 17:16:50 -0500 Received: from optimus22.ietf.org ([132.151.6.22] helo=optimus.ietf.org) by mx2.foretec.com with esmtp (Exim 4.24) id 1B9Wq8-0000TX-UK for ips-web-archive@ietf.org; Fri, 02 Apr 2004 17:08:41 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B9VxO-0004Fh-Sf; Fri, 02 Apr 2004 16:12:06 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B9SL0-0007p7-Re for ips@optimus.ietf.org; Fri, 02 Apr 2004 12:20: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 MAA19683 for ; Fri, 2 Apr 2004 12:20:11 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B9SKz-0000Py-00 for ips@ietf.org; Fri, 02 Apr 2004 12:20:13 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B9SJu-0000FC-00 for ips@ietf.org; Fri, 02 Apr 2004 12:19:06 -0500 Received: from mononoke.wasabisystems.com ([151.199.66.145]) by ietf-mx with esmtp (Exim 4.12) id 1B9SIy-00002Q-00 for ips@ietf.org; Fri, 02 Apr 2004 12:18:09 -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 66F3D40137; Fri, 2 Apr 2004 12:18:05 -0500 (EST) In-Reply-To: <20040402074351.20430.qmail@web12824.mail.yahoo.com> References: <20040402074351.20430.qmail@web12824.mail.yahoo.com> Mime-Version: 1.0 (Apple Message framework v613) Content-Type: multipart/signed; protocol="application/pgp-signature"; micalg=pgp-sha1; boundary="Apple-Mail-1--460137688" Message-Id: Content-Transfer-Encoding: 7bit Cc: "Black, David" , ips@ietf.org, David.Weibel@Sun.COM, "brown, david1 (eng)" , Julian Satran From: William Studenmund Subject: Re: [Ips] iSCSI: clarification? data-in PDU->command status bit Date: Fri, 2 Apr 2004 09:17:57 -0800 To: Luben Tuikov 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-1--460137688 Content-Type: text/plain; charset=US-ASCII; format=flowed Content-Transfer-Encoding: 7bit On Apr 1, 2004, at 11:43 PM, Luben Tuikov wrote: > I couldn't agree more. > > Plus SAM-2 is prerequisite to any attempt at implementing or even > reading > and understanding iSCSI. > > I understand that there _could_ be some confusion to someone totally > unfamiliar with SCSI and iSCSI, but we cannot accomodate for all those > "confusions" -- we might as well copy SAM-2 right in (and then there'd > still be confusions :-) ). > > The spec is consistent, and for completeness SAM-2 is a prerequisite -- > iSCSI need not be changed for this. I believe you (and a few others) missed the point of misunderstanding. The misunderstanding I was referring to was not that you can't send status twice, it was that you can't send a SCSI Command Response PDU that doesn't carry status; sending status is the sole purpose of the PDU. Thus once you've sent status, the PDU is neither needed nor appropriate. As the SCSI Command Response PDU is an iSCSI concept, no amount of reference to SAM-2 will help the situation. To be honest, I am puzzled as to why this argument has gone on so long. This misunderstanding made it into code that was put up for interop testing. The other side of the interop testing didn't feel sufficiently bolstered as to just quote a section number to resolve the issue. When raised on this list, a number of us said, "Yes, that can be made better." We are (or were earlier this week) in a period when such small, clarifying changes are appropriate. So why not make it better? Take care, Bill --Apple-Mail-1--460137688 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) iD8DBQFAbaBLDJT2Egh26K0RAth6AJ9cJOHiZ2tDRragwGYvJj1a72pWOwCeLoWp DrUYraDA43Xq8KQ6DKNIfuk= =Wjjo -----END PGP SIGNATURE----- --Apple-Mail-1--460137688-- _______________________________________________ Ips mailing list Ips@ietf.org https://www1.ietf.org/mailman/listinfo/ips From exim@www1.ietf.org Fri Apr 2 17:48:51 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 QAA05076 for ; Fri, 2 Apr 2004 16:59: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 1B9Wgc-0001fa-1t for ips-archive@odin.ietf.org; Fri, 02 Apr 2004 16:58:50 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i32Lwo8x006414 for ips-archive@odin.ietf.org; Fri, 2 Apr 2004 16:58:50 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B9Wgb-0001fN-Ue for ips-web-archive@optimus.ietf.org; Fri, 02 Apr 2004 16:58: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 QAA04861 for ; Fri, 2 Apr 2004 16:58:46 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B9WgZ-0002s0-00 for ips-web-archive@ietf.org; Fri, 02 Apr 2004 16:58:47 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B9Wcr-00021a-00 for ips-web-archive@ietf.org; Fri, 02 Apr 2004 16:54:58 -0500 Received: from [65.246.255.50] (helo=mx2.foretec.com) by ietf-mx with esmtp (Exim 4.12) id 1B9WaO-0001Ld-01 for ips-web-archive@ietf.org; Fri, 02 Apr 2004 16:52:24 -0500 Received: from optimus22.ietf.org ([132.151.6.22] helo=optimus.ietf.org) by mx2.foretec.com with esmtp (Exim 4.24) id 1B9WTZ-0007oJ-FQ for ips-web-archive@ietf.org; Fri, 02 Apr 2004 16:45:23 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B9UzK-0001Rt-DU; Fri, 02 Apr 2004 15: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 1B9S0Z-0005mg-G0 for ips@optimus.ietf.org; Fri, 02 Apr 2004 11:59: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 LAA18167 for ; Fri, 2 Apr 2004 11:59:04 -0500 (EST) From: Black_David@emc.com Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B9S0Y-0004hl-00 for ips@ietf.org; Fri, 02 Apr 2004 11:59:06 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B9Rzg-0004WL-00 for ips@ietf.org; Fri, 02 Apr 2004 11:58:12 -0500 Received: from maho3msx2.corp.emc.com ([128.221.11.32]) by ietf-mx with esmtp (Exim 4.12) id 1B9Ryv-0004E3-00 for ips@ietf.org; Fri, 02 Apr 2004 11:57:25 -0500 Received: by maho3msx2.corp.emc.com with Internet Mail Service (5.5.2653.19) id ; Fri, 2 Apr 2004 11:56:51 -0500 Message-ID: To: ips@ietf.org Subject: RE: [Ips] iSCSI: clarification? data-in PDU->command status bit Date: Fri, 2 Apr 2004 11:55:32 -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 > Adding a "MUST" will make things clear. This will be done. Thanks, --David (with WG chair hat on). ---------------------------------------------------- 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: William Studenmund [mailto:wrstuden@wasabisystems.com] > 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 Sat Apr 3 14:31:49 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 OAA01177 for ; Sat, 3 Apr 2004 14:31:49 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B9qrR-0004Xq-Hw for ips-archive@odin.ietf.org; Sat, 03 Apr 2004 14:31:22 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i33JVLNT017466 for ips-archive@odin.ietf.org; Sat, 3 Apr 2004 14:31:21 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B9qrQ-0004Xd-Ul for ips-web-archive@optimus.ietf.org; Sat, 03 Apr 2004 14:31: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 OAA01111 for ; Sat, 3 Apr 2004 14:31:17 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B9qrO-0001kx-00 for ips-web-archive@ietf.org; Sat, 03 Apr 2004 14:31:18 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B9qpS-0001ID-00 for ips-web-archive@ietf.org; Sat, 03 Apr 2004 14:29:20 -0500 Received: from [65.246.255.50] (helo=mx2.foretec.com) by ietf-mx with esmtp (Exim 4.12) id 1B9qn0-0000kH-01 for ips-web-archive@ietf.org; Sat, 03 Apr 2004 14:26:46 -0500 Received: from optimus22.ietf.org ([132.151.6.22] helo=optimus.ietf.org) by mx2.foretec.com with esmtp (Exim 4.24) id 1B9qYn-00012P-Is for ips-web-archive@ietf.org; Sat, 03 Apr 2004 14:12:05 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B9qYj-0006e0-Qu; Sat, 03 Apr 2004 14: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 1B9qYI-0006HM-5v for ips@optimus.ietf.org; Sat, 03 Apr 2004 14:11:34 -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 OAA00050 for ; Sat, 3 Apr 2004 14:11:31 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B9qYF-0006nS-00 for ips@ietf.org; Sat, 03 Apr 2004 14:11:31 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B9qX6-0006Zu-00 for ips@ietf.org; Sat, 03 Apr 2004 14:10:20 -0500 Received: from sccrmhc13.comcast.net ([204.127.202.64]) by ietf-mx with esmtp (Exim 4.12) id 1B9qW8-0006Ht-00 for ips@ietf.org; Sat, 03 Apr 2004 14:09:20 -0500 Received: from ivvt2dxrc11 (c-66-177-57-55.se.client2.attbi.com[66.177.57.55]) by comcast.net (sccrmhc13) with SMTP id <20040403190849016003gnppe> (Authid: esquicksall); Sat, 3 Apr 2004 19:08:50 +0000 Message-ID: <005a01c419af$0954cc60$0303a8c0@ivvt2dxrc11> From: "Eddy Quicksall" To: "William Studenmund" , "Luben Tuikov" Cc: "Black, David" , , , "brown, david1 \(eng\)" , "Julian Satran" References: <20040402074351.20430.qmail@web12824.mail.yahoo.com> Subject: Re: [Ips] iSCSI: clarification? data-in PDU->command status bit Date: Sat, 3 Apr 2004 14:08:22 -0500 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1158 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 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.1 required=5.0 tests=AWL autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit How could you send a SCSI Response without either sending status or target failure? If you want to clear something up, how about clearing this up too? If a SCSI Response PDU does not arrive before the session is terminated, the SCSI service response is SERVICE DELIVERY OR TARGET FAILURE. "If a SCSI Response PDU...". In the case of Data In carrying status, a SCSI Response PDU has not been sent so the sentence leads to ambiguity (actually that is also OK if one were to use some common sense). A non-zero response field indicates a failure to execute the command in which case the Status and Sense fields are undefined. Why is this referring the "Sense field". There is no such field in the PDU. It probably should be changed to "Status and Flags fields are undefined". Eddy ----- Original Message ----- From: "William Studenmund" To: "Luben Tuikov" Cc: "Black, David" ; ; ; "brown, david1 (eng)" ; "Julian Satran" Sent: Friday, April 02, 2004 12:17 PM Subject: Re: [Ips] iSCSI: clarification? data-in PDU->command status bit The misunderstanding I was referring to was not that you can't send status twice, it was that you can't send a SCSI Command Response PDU that doesn't carry status; _______________________________________________ Ips mailing list Ips@ietf.org https://www1.ietf.org/mailman/listinfo/ips From exim@www1.ietf.org Sat Apr 3 19:53:47 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 TAA13714 for ; Sat, 3 Apr 2004 19:53:47 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B9vt0-0008RW-CY for ips-archive@odin.ietf.org; Sat, 03 Apr 2004 19:53:18 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i340rIDR032455 for ips-archive@odin.ietf.org; Sat, 3 Apr 2004 19:53:18 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B9vt0-0008RO-7c for ips-web-archive@optimus.ietf.org; Sat, 03 Apr 2004 19:53:18 -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 TAA13693 for ; Sat, 3 Apr 2004 19:53:16 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B9vsy-0007Dp-00 for ips-web-archive@ietf.org; Sat, 03 Apr 2004 19:53:16 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B9vs2-00076e-00 for ips-web-archive@ietf.org; Sat, 03 Apr 2004 19:52:18 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1B9vr5-0006zz-00 for ips-web-archive@ietf.org; Sat, 03 Apr 2004 19:51:19 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B9vqn-000834-Md; Sat, 03 Apr 2004 19:51:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B9vq3-0007uu-Eq for ips@optimus.ietf.org; Sat, 03 Apr 2004 19:50: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 TAA13602 for ; Sat, 3 Apr 2004 19:50:13 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B9vq1-0006s1-00 for ips@ietf.org; Sat, 03 Apr 2004 19:50:13 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B9vp7-0006lV-00 for ips@ietf.org; Sat, 03 Apr 2004 19:49:18 -0500 Received: from sccrmhc12.comcast.net ([204.127.202.56]) by ietf-mx with esmtp (Exim 4.12) id 1B9voE-0006XZ-00 for ips@ietf.org; Sat, 03 Apr 2004 19:48:22 -0500 Received: from ivvt2dxrc11 (c-66-177-57-55.se.client2.attbi.com[66.177.57.55]) by comcast.net (sccrmhc12) with SMTP id <20040404004752012002j3lie> (Authid: esquicksall); Sun, 4 Apr 2004 00:47:53 +0000 Message-ID: <009001c419de$6573ab90$0303a8c0@ivvt2dxrc11> From: "Eddy Quicksall" To: , References: <9AB7C093B52FEE4EB66BAE9BE58A32730E55CC@wcosmb02.cos.agilent.com> Subject: Re: [Ips] What iSNS servers are available for interop testing? Date: Sat, 3 Apr 2004 19:47:24 -0500 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1158 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 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.1 required=5.0 tests=AWL autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit There is an open source version but the last I tried it, it was not up to date. The location is: http://sourceforge.net/projects/linuxisns/ An alternative site is http://www.nishansystems.com/iSNS/index.html The Microsoft server can be found on their web site and it works. Eddy ----- Original Message ----- From: To: Sent: Thursday, March 25, 2004 1:50 PM Subject: [Ips] What iSNS servers are available for interop testing? 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 _______________________________________________ Ips mailing list Ips@ietf.org https://www1.ietf.org/mailman/listinfo/ips From exim@www1.ietf.org Sun Apr 4 20:24:31 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 UAA17086 for ; Sun, 4 Apr 2004 20:24:31 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BAHuE-0006pM-Lt for ips-archive@odin.ietf.org; Sun, 04 Apr 2004 20:24:03 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i350O2Y3026245 for ips-archive@odin.ietf.org; Sun, 4 Apr 2004 20:24:02 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BAHuE-0006pE-DI for ips-web-archive@optimus.ietf.org; Sun, 04 Apr 2004 20:24:02 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA17076 for ; Sun, 4 Apr 2004 20:24:00 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1BAHuC-0000NG-00 for ips-web-archive@ietf.org; Sun, 04 Apr 2004 20:24:00 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BAHtI-0000Hh-00 for ips-web-archive@ietf.org; Sun, 04 Apr 2004 20:23:04 -0400 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1BAHt0-0000C7-00 for ips-web-archive@ietf.org; Sun, 04 Apr 2004 20:22:46 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BAHsI-0006R3-Ev; Sun, 04 Apr 2004 20:22:02 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BAHrJ-0006JG-5G for ips@optimus.ietf.org; Sun, 04 Apr 2004 20:21:01 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA16988 for ; Sun, 4 Apr 2004 20:20:59 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1BAHrH-00003y-00 for ips@ietf.org; Sun, 04 Apr 2004 20:20:59 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BAHqN-0007mM-00 for ips@ietf.org; Sun, 04 Apr 2004 20:20:03 -0400 Received: from mononoke.wasabisystems.com ([151.199.66.145]) by ietf-mx with esmtp (Exim 4.12) id 1BAHpe-0007gq-00 for ips@ietf.org; Sun, 04 Apr 2004 20:19:18 -0400 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 7C87D40137; Sun, 4 Apr 2004 20:19:12 -0400 (EDT) In-Reply-To: <005a01c419af$0954cc60$0303a8c0@ivvt2dxrc11> References: <20040402074351.20430.qmail@web12824.mail.yahoo.com> <005a01c419af$0954cc60$0303a8c0@ivvt2dxrc11> Mime-Version: 1.0 (Apple Message framework v613) Content-Type: multipart/signed; protocol="application/pgp-signature"; micalg=pgp-sha1; boundary="Apple-Mail-1--262072346" Message-Id: Content-Transfer-Encoding: 7bit Cc: "Black, David" , , , "Luben Tuikov" , "brown, david1 (eng)" , "Julian Satran" From: William Studenmund Subject: Re: [Ips] iSCSI: clarification? data-in PDU->command status bit Date: Sun, 4 Apr 2004 17:19:02 -0700 To: "Eddy Quicksall" 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-1--262072346 Content-Type: text/plain; charset=US-ASCII; format=flowed Content-Transfer-Encoding: 7bit On Apr 3, 2004, at 11:08 AM, Eddy Quicksall wrote: > How could you send a SCSI Response without either sending status or > target > failure? You can't. The point of this hasn't been that you can, but that people can get to thinking you can. > If you want to clear something up, how about clearing this up too? > > > > If a SCSI Response PDU does not arrive before the session is > terminated, the SCSI service response is SERVICE DELIVERY OR TARGET > FAILURE. > > > > "If a SCSI Response PDU...". In the case of Data In carrying status, a > SCSI > Response PDU has not been sent so the sentence leads to ambiguity > (actually > that is also OK if one were to use some common sense). That too needs fixing. And it can even more strongly lead to the erroneous idea you always need a SCSI Response PDU. I am though unsure if we still have time. Julian? David? I'd suggest something like "If SCSI Status (either SCSI Response PDU or DATA IN with status) ...". > A non-zero response field indicates a failure to execute the command > in which case the Status and Sense fields are undefined. > > > Why is this referring the "Sense field". There is no such field in the > PDU. > It probably should be changed to "Status and Flags fields are > undefined". Indeed. Take care, Bill --Apple-Mail-1--262072346 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) iD8DBQFAcKX9DJT2Egh26K0RAp0OAJ42CJ2VpCjyL+omXEEDwoiPz6kYzwCfQwU5 YAlhn7Do6f+XlG6/4QWoZRk= =BWuO -----END PGP SIGNATURE----- --Apple-Mail-1--262072346-- _______________________________________________ Ips mailing list Ips@ietf.org https://www1.ietf.org/mailman/listinfo/ips From exim@www1.ietf.org Tue Apr 6 18:09: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 SAA04956 for ; Tue, 6 Apr 2004 18:09:16 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BAykU-0005oA-Nh for ips-archive@odin.ietf.org; Tue, 06 Apr 2004 18:08:50 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i36M8oTZ022324 for ips-archive@odin.ietf.org; Tue, 6 Apr 2004 18:08:50 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BAykU-0005nz-HS for ips-web-archive@optimus.ietf.org; Tue, 06 Apr 2004 18:08:50 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA04881 for ; Tue, 6 Apr 2004 18:08:45 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1BAykR-0002cQ-00 for ips-web-archive@ietf.org; Tue, 06 Apr 2004 18:08:47 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BAy7W-0003lb-00 for ips-web-archive@ietf.org; Tue, 06 Apr 2004 17:28:36 -0400 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1BAx3H-0004wS-00 for ips-web-archive@ietf.org; Tue, 06 Apr 2004 16:20:07 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BAx3B-0004Cx-OG; Tue, 06 Apr 2004 16:20:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BAx3A-0004CS-6p for ips@optimus.ietf.org; Tue, 06 Apr 2004 16:20:00 -0400 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA25633 for ; Tue, 6 Apr 2004 16:19:57 -0400 (EDT) Received: from nobody by optimus.ietf.org with local (Exim 4.20) id 1BAx2f-00048Y-RY; Tue, 06 Apr 2004 16:19:29 -0400 X-test-idtracker: no From: The IESG To: IETF-Announce:; Cc: Internet Architecture Board , RFC Editor , ips mailing list , ips chair , ips chair Message-Id: Date: Tue, 06 Apr 2004 16:19:29 -0400 Subject: [Ips] Document Action: 'SCSI Command Ordering Considerations with iSCSI' to Informational RFC 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 The IESG has approved the following document: - 'SCSI Command Ordering Considerations with iSCSI ' as an Informational RFC This document is the product of the IP Storage Working Group. The IESG contact persons are Allison Mankin and Jon Peterson. _______________________________________________ Ips mailing list Ips@ietf.org https://www1.ietf.org/mailman/listinfo/ips From exim@www1.ietf.org Thu Apr 8 00:54: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 AAA17292 for ; Thu, 8 Apr 2004 00:54:45 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BBRYN-0005Nu-M3 for ips-archive@odin.ietf.org; Thu, 08 Apr 2004 00:54:18 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i384sFcT020694 for ips-archive@odin.ietf.org; Thu, 8 Apr 2004 00:54:15 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BBRYK-0005Kv-MF for ips-web-archive@optimus.ietf.org; Thu, 08 Apr 2004 00:54:15 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA17122 for ; Thu, 8 Apr 2004 00:54:08 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1BBRYH-00029O-00 for ips-web-archive@ietf.org; Thu, 08 Apr 2004 00:54:09 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BBPBu-0003Vn-00 for ips-web-archive@ietf.org; Wed, 07 Apr 2004 22:22:56 -0400 Received: from [65.246.255.50] (helo=mx2.foretec.com) by ietf-mx with esmtp (Exim 4.12) id 1BBNmI-00062R-00 for ips-web-archive@ietf.org; Wed, 07 Apr 2004 20:52:22 -0400 Received: from optimus22.ietf.org ([132.151.6.22] helo=optimus.ietf.org) by mx2.foretec.com with esmtp (Exim 4.24) id 1BBNmJ-0005SY-4L for ips-web-archive@ietf.org; Wed, 07 Apr 2004 20:52:23 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BBNm5-0002i8-Oo; Wed, 07 Apr 2004 20:52:09 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BBK4w-0004PY-Qe for ips@optimus.ietf.org; Wed, 07 Apr 2004 16:55:32 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA03462 for ; Wed, 7 Apr 2004 16:55:19 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1BBK4u-0001gc-00 for ips@ietf.org; Wed, 07 Apr 2004 16:55:20 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BBI58-00052k-00 for ips@ietf.org; Wed, 07 Apr 2004 14:47:27 -0400 Received: from f112.brocade.com ([66.243.153.112] helo=blasphemy.brocade.com) by ietf-mx with esmtp (Exim 4.12) id 1BBHCZ-0004l4-00 for ips@ietf.org; Wed, 07 Apr 2004 13:51:04 -0400 Received: from hq-ex-11.corp.brocade.com (hq-ex-11 [192.168.38.58]) by blasphemy.brocade.com (Postfix) with ESMTP id 18DD914271; Wed, 7 Apr 2004 10:50:28 -0700 (PDT) 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: [T11.5] Re: [Ips] Request from T11.5 for editorial cleanup Date: Wed, 7 Apr 2004 10:50:27 -0700 Message-ID: <191DA4FAE235D24C9BCC8D50F6B17AB9451D15@hq-ex-11.brocade.com> Thread-Topic: [T11.5] Re: [Ips] Request from T11.5 for editorial cleanup Thread-Index: AcQWAG/7cJCQEbZGRcSMXb1kirVCvQGx7+4g From: "John Crandall" To: "Keith McCloghrie" , "Robert Snively" 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=none autolearn=no version=2.60 Content-Transfer-Encoding: quoted-printable Content-Transfer-Encoding: quoted-printable Keith, I still don't understand why the Fabric Name will not be the Node WWN of the principal switch. Is it possible as defined that someone can populate the Fabric Name with something other than a WWN? Also I don't understand the difference between other and dynamic unless we add a whole lot more to expand dynamic. Maybe you can explain this during the Ad Hoc meeting today. Thanks, John=20 -----Original Message----- From: t11_5-bounce@mailman.listserve.com [mailto:t11_5-bounce@mailman.listserve.com]On Behalf Of Keith McCloghrie Sent: Monday, March 29, 2004 10:47 AM To: Robert Snively Cc: kzm@cisco.com; ips@ietf.org; t11_5@mail.t11.org; bwijnen@lucent.com; mrm@kazeon.com; mankin@psg.com; Elizabeth.Rodriguez@dothill.com; Black_David@emc.com Subject: [T11.5] Re: [Ips] Request from T11.5 for editorial cleanup INCITS T11.5 Mail Reflector ******************************** > 1) Fabric Name: >=20 > 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." >=20 > In the MIB (fcmInstanceFabricId), it states:=20 >=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." >=20 > 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 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: >=20 > 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. >=20 > 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. >=20 > An additional port type of F/NL_Port ("fnlPort") should be=20 > defined for applications that have that requirement. >=20 > For reference, FC-SW-3 defines the G and GL_Ports as follows: >=20 > 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. >=20 > For reference, FC-GS-4 defines the F/NL_Port as follows: >=20 > 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). =20 Thanks for the information.=20 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. To Unsubscribe: mailto:t11_5-request@mail.t11.org?subject=3Dunsubscribe _______________________________________________ Ips mailing list Ips@ietf.org https://www1.ietf.org/mailman/listinfo/ips From exim@www1.ietf.org Mon Apr 12 16:34: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 QAA12961 for ; Mon, 12 Apr 2004 16:34:06 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BD87e-0006tE-Qo for ips-archive@odin.ietf.org; Mon, 12 Apr 2004 16:33:39 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i3CKXcN5026480 for ips-archive@odin.ietf.org; Mon, 12 Apr 2004 16:33:38 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BD87e-0006t1-LE for ips-web-archive@optimus.ietf.org; Mon, 12 Apr 2004 16:33:38 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA12921 for ; Mon, 12 Apr 2004 16:33:35 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1BD87c-0000Ia-00 for ips-web-archive@ietf.org; Mon, 12 Apr 2004 16:33:36 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BD7qE-0006Ky-00 for ips-web-archive@ietf.org; Mon, 12 Apr 2004 16:15:38 -0400 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1BD7a4-0004ow-00 for ips-web-archive@ietf.org; Mon, 12 Apr 2004 15:58:56 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BD7VA-0007cf-CD; Mon, 12 Apr 2004 15:53:52 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BD7MH-0003eV-7k for ips@optimus.ietf.org; Mon, 12 Apr 2004 15:44:41 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA09684 for ; Mon, 12 Apr 2004 15:44:37 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1BD7ME-0002Yu-00 for ips@ietf.org; Mon, 12 Apr 2004 15:44:39 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BD7IP-0001xV-00 for ips@ietf.org; Mon, 12 Apr 2004 15:40:41 -0400 Received: from host28.istor.com ([66.134.214.28] helo=mail1irv.inside.istor.com) by ietf-mx with esmtp (Exim 4.12) id 1BD7FX-0001Eq-00 for ips@ietf.org; Mon, 12 Apr 2004 15:37:44 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.0.5762.3 Content-Class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Mon, 12 Apr 2004 12:36:45 -0700 Message-ID: <7D036BD3216A084DB1BD9D62BCEAF2903C9813@mail1irv.inside.istor.com> Thread-Topic: NOP-IN question Thread-Index: AcQgxX1eo/h4xJ2jTquaiMtKgNe10g== From: "Ken Craig" To: Content-Transfer-Encoding: quoted-printable Subject: [Ips] NOP-IN question 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 Section 10.18 in the iSCSI draft 20 states that an iSCSI Initiator MUST send a NOP-OUT PDU if I, as an iSCSI Target, generate a NOP-IN PDU with a valid TTT. My question is "How long is the Target supposed to wait before deciding that the NOP-OUT PDU isn't coming?". The draft does not appear to give any guidance as to how long the Target is supposed to wait to receive the NOP-OUT. Would I be correct in assuming I can use the time2wait and time2retain values or is there some other mechanism for timing this out? Thanks, Kenneth Craig _______________________________________________ Ips mailing list Ips@ietf.org https://www1.ietf.org/mailman/listinfo/ips From exim@www1.ietf.org Tue Apr 13 16:05: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 QAA03637 for ; Tue, 13 Apr 2004 16:05:53 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BDTnq-0004Vi-4y for ips-archive@odin.ietf.org; Tue, 13 Apr 2004 15:42:41 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i3DJgci1017334 for ips-archive@odin.ietf.org; Tue, 13 Apr 2004 15:42:38 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BDTkU-0003pQ-Tb for ips-web-archive@optimus.ietf.org; Tue, 13 Apr 2004 15:39:10 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA02156 for ; Tue, 13 Apr 2004 15:39:09 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1BDTkS-0001GU-00 for ips-web-archive@ietf.org; Tue, 13 Apr 2004 15:39:08 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BDTia-00016g-00 for ips-web-archive@ietf.org; Tue, 13 Apr 2004 15:37:13 -0400 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1BDThI-0000yw-00 for ips-web-archive@ietf.org; Tue, 13 Apr 2004 15:35:52 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BDTbe-0002UR-FA; Tue, 13 Apr 2004 15:30:02 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BDTWF-0001dx-PQ for ips@optimus.ietf.org; Tue, 13 Apr 2004 15:24:31 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA01057 for ; Tue, 13 Apr 2004 15:24:25 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1BDTWD-0007fQ-00 for ips@ietf.org; Tue, 13 Apr 2004 15:24:25 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BDTTv-0007Uh-00 for ips@ietf.org; Tue, 13 Apr 2004 15:22:04 -0400 Received: from mtagate7.de.ibm.com ([195.212.29.156]) by ietf-mx with esmtp (Exim 4.12) id 1BDTSy-0007KI-00; Tue, 13 Apr 2004 15:21:04 -0400 Received: from d12nrmr1607.megacenter.de.ibm.com (d12nrmr1607.megacenter.de.ibm.com [9.149.167.49]) by mtagate7.de.ibm.com (8.12.10/8.12.10) with ESMTP id i3DJKEWn089398; Tue, 13 Apr 2004 19:20:14 GMT Received: from d12ml102.megacenter.de.ibm.com (d12av02.megacenter.de.ibm.com [9.149.165.228]) by d12nrmr1607.megacenter.de.ibm.com (8.12.10/NCO/VER6.6) with ESMTP id i3DJKDd3042776; Tue, 13 Apr 2004 21:20:14 +0200 In-Reply-To: <7D036BD3216A084DB1BD9D62BCEAF2903C9813@mail1irv.inside.istor.com> To: "Ken Craig" Cc: ips@ietf.org, ips-admin@ietf.org MIME-Version: 1.0 Subject: Re: [Ips] NOP-IN question X-Mailer: Lotus Notes Release 6.5.1 January 21, 2004 From: Julian Satran Message-ID: Date: Tue, 13 Apr 2004 22:22:35 +0300 X-MIMETrack: Serialize by Router on D12ML102/12/M/IBM(Release 6.0.2CF2|July 23, 2003) at 13/04/2004 22:22:40, Serialize complete at 13/04/2004 22:22:40 Content-Type: multipart/alternative; boundary="=_alternative 0060D8A285256E75_=" 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 This is a multipart message in MIME format. --=_alternative 0060D8A285256E75_= Content-Type: text/plain; charset="US-ASCII" Ken, There is no specific mechanism in place for this case. You have to consider transport characteristics (RTT) and end-point characteristics. Those can be set by an administrator or learned or both. Julo "Ken Craig" Sent by: ips-admin@ietf.org 12/04/04 15:36 To cc Subject [Ips] NOP-IN question Section 10.18 in the iSCSI draft 20 states that an iSCSI Initiator MUST send a NOP-OUT PDU if I, as an iSCSI Target, generate a NOP-IN PDU with a valid TTT. My question is "How long is the Target supposed to wait before deciding that the NOP-OUT PDU isn't coming?". The draft does not appear to give any guidance as to how long the Target is supposed to wait to receive the NOP-OUT. Would I be correct in assuming I can use the time2wait and time2retain values or is there some other mechanism for timing this out? Thanks, Kenneth Craig _______________________________________________ Ips mailing list Ips@ietf.org https://www1.ietf.org/mailman/listinfo/ips --=_alternative 0060D8A285256E75_= Content-Type: text/html; charset="US-ASCII"
Ken,

There is no specific mechanism in place for this case.
You have to consider transport characteristics (RTT) and end-point characteristics.
Those can be set by an administrator or learned or both.

Julo


"Ken Craig" <kcraig@istor.com>
Sent by: ips-admin@ietf.org

12/04/04 15:36

To
<ips@ietf.org>
cc
Subject
[Ips] NOP-IN question





Section 10.18 in the iSCSI draft 20 states that an iSCSI
Initiator MUST send a NOP-OUT PDU if I, as an iSCSI Target,
generate a NOP-IN PDU with a valid TTT.  My question is
"How long is the Target supposed to wait before deciding
that the NOP-OUT PDU isn't coming?".  The draft does not
appear to give any guidance as to how long the Target is
supposed to wait to receive the NOP-OUT.  Would I be correct
in assuming I can use the time2wait and time2retain values
or is there some other mechanism for timing this out?

Thanks,
Kenneth Craig

_______________________________________________
Ips mailing list
Ips@ietf.org
https://www1.ietf.org/mailman/listinfo/ips
--=_alternative 0060D8A285256E75_=-- _______________________________________________ Ips mailing list Ips@ietf.org https://www1.ietf.org/mailman/listinfo/ips From exim@www1.ietf.org Wed Apr 14 11:27: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 LAA01441 for ; Wed, 14 Apr 2004 11:27:54 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BDmEg-0002nE-9q for ips-archive@odin.ietf.org; Wed, 14 Apr 2004 11:23:34 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i3EFNY0b010736 for ips-archive@odin.ietf.org; Wed, 14 Apr 2004 11:23:34 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BDmAT-0001pz-Vd for ips-web-archive@optimus.ietf.org; Wed, 14 Apr 2004 11:19:14 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA00909 for ; Wed, 14 Apr 2004 11:19:11 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1BDmAT-0001Uy-00 for ips-web-archive@ietf.org; Wed, 14 Apr 2004 11:19:13 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BDm9K-0001RK-00 for ips-web-archive@ietf.org; Wed, 14 Apr 2004 11:18:03 -0400 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1BDm8O-0001Oc-00 for ips-web-archive@ietf.org; Wed, 14 Apr 2004 11:17:04 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BDm2X-0000FJ-BO; Wed, 14 Apr 2004 11:11:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BDlo8-0005RY-UZ for ips@optimus.ietf.org; Wed, 14 Apr 2004 10:56:09 -0400 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA29182 for ; Wed, 14 Apr 2004 10:56:04 -0400 (EDT) Received: from nobody by optimus.ietf.org with local (Exim 4.20) id 1BDljj-0004gt-3j; Wed, 14 Apr 2004 10:51:35 -0400 X-test-idtracker: no From: The IESG To: IETF-Announce:; Cc: Internet Architecture Board , RFC Editor , ips mailing list , ips chair , ips chair Message-Id: Date: Wed, 14 Apr 2004 10:51:35 -0400 Subject: [Ips] Protocol Action: 'Bootstrapping Clients using the iSCSI Protocol' to Proposed Standard 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 The IESG has approved the following document: - 'Bootstrapping Clients using the iSCSI Protocol ' as a Proposed Standard This document is the product of the IP Storage Working Group. The IESG contact persons are Allison Mankin and Jon Peterson. Technical Summary This specification describes a standard mechanism to enable clients to bootstrap themselves using the iSCSI protocol. The goal of this standard is to enable iSCSI boot clients to obtain the information to open an iSCSI session with the iSCSI boot server. It is possible that all the information is not available at the very outset, so the memo describes steps to obtain the information required to bootstrap clients off an iSCSI boot server. Since iSCSI allows a general Internet to be interposed between the clients and server, a secure design is introduced for these steps. Working Group Summary The original version of the boot protocol was found by Security Area to have serious security flaws and was returned to the working group for an overhaul. A design team developed a completely new approach during an intensive effort, developed working group consensus in several careful sessions, and discussed (also with care) the issues of implementability. There was good agreement by and members of the SCSI standards community that this solution would be adopted and implemented. Protocol Quality The specification was reviewed for the IESG by the Operations Directorate and Allison Mankin. Margaret Wasserman reviewed the IPv6 issues. Bernard Aboba led the effort in response to the the first IESG review. RFC Editor Notes Section 5 - OLD: An iSCSI boot client which does not know its IP address at power-on may acquire its IP address via BOOTP or DHCP (v4 or v6). NEW: An iSCSI boot client which does not know its IP address at power-on may acquire its IP address via BOOTP or DHCP (v4 or v6), or via IPv6 address autoconfiguration. OLD: This is done using the variable length option named Root Path. NEW: This is done using the variable length option named Root Path [Alexander93, Reynolds93]. _______________________________________________ Ips mailing list Ips@ietf.org https://www1.ietf.org/mailman/listinfo/ips From exim@www1.ietf.org Wed Apr 14 13:25:44 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 NAA08707 for ; Wed, 14 Apr 2004 13:25:44 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BDo0l-0001E8-5a for ips-archive@odin.ietf.org; Wed, 14 Apr 2004 13:17:19 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i3EHHJUA004712 for ips-archive@odin.ietf.org; Wed, 14 Apr 2004 13:17:19 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BDnj7-0005fz-KE for ips-web-archive@optimus.ietf.org; Wed, 14 Apr 2004 12:59:05 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA06001 for ; Wed, 14 Apr 2004 12:59:01 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1BDnj5-0007Bg-00 for ips-web-archive@ietf.org; Wed, 14 Apr 2004 12:59:03 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BDngl-0006py-00 for ips-web-archive@ietf.org; Wed, 14 Apr 2004 12:56:41 -0400 Received: from [65.246.255.50] (helo=mx2.foretec.com) by ietf-mx with esmtp (Exim 4.12) id 1BDnew-0006VE-01 for ips-web-archive@ietf.org; Wed, 14 Apr 2004 12:54:46 -0400 Received: from optimus22.ietf.org ([132.151.6.22] helo=optimus.ietf.org) by mx2.foretec.com with esmtp (Exim 4.24) id 1BDnSI-0002Ua-L0 for ips-web-archive@ietf.org; Wed, 14 Apr 2004 12:41:42 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BDnBg-00053E-N2; Wed, 14 Apr 2004 12:24:32 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BDmXg-0006lc-7I for ips@optimus.ietf.org; Wed, 14 Apr 2004 11:43:12 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA02523 for ; Wed, 14 Apr 2004 11:43:09 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1BDmXf-0002tc-00 for ips@ietf.org; Wed, 14 Apr 2004 11:43:11 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BDmX3-0002rH-00 for ips@ietf.org; Wed, 14 Apr 2004 11:42:33 -0400 Received: from atlrel6.hp.com ([156.153.255.205]) by ietf-mx with esmtp (Exim 4.12) id 1BDmWM-0002lu-00 for ips@ietf.org; Wed, 14 Apr 2004 11:41:51 -0400 Received: from rosemail.rose.hp.com (rosemail.rose.hp.com [15.43.209.160]) by atlrel6.hp.com (Postfix) with ESMTP id 747321C0006F for ; Wed, 14 Apr 2004 11:41:50 -0400 (EDT) Received: from rose.hp.com (unknown [15.244.196.156]) by rosemail.rose.hp.com (Postfix) with ESMTP id A09258469 for ; Wed, 14 Apr 2004 08:31:50 -0700 (PDT) Message-ID: <407D5BBC.5030203@rose.hp.com> Date: Wed, 14 Apr 2004 08:41:48 -0700 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] NOP-IN question References: In-Reply-To: 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: , 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 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit In addition to what Julian said, let me add that the iSCSI spec generally considers the timeout values used by the iSCSI implementations to be outside its scope - I do not know of any exception. Section 6 makes this point several times wrt various timeout scenarios. The Time2Wait/Retain are not to be used for timing any operations on one connection. They are applicable only during the transition period from one connection to another. Mallikarjun Julian Satran wrote: > > Ken, > > There is no specific mechanism in place for this case. > You have to consider transport characteristics (RTT) and end-point > characteristics. > Those can be set by an administrator or learned or both. > > Julo > > > "Ken Craig" > Sent by: ips-admin@ietf.org > > 12/04/04 15:36 > > > To > > cc > > Subject > [Ips] NOP-IN question > > > > > > > > > Section 10.18 in the iSCSI draft 20 states that an iSCSI > Initiator MUST send a NOP-OUT PDU if I, as an iSCSI Target, > generate a NOP-IN PDU with a valid TTT. My question is > "How long is the Target supposed to wait before deciding > that the NOP-OUT PDU isn't coming?". The draft does not > appear to give any guidance as to how long the Target is > supposed to wait to receive the NOP-OUT. Would I be correct > in assuming I can use the time2wait and time2retain values > or is there some other mechanism for timing this out? > > Thanks, > Kenneth Craig > > _______________________________________________ > 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 Thu Apr 15 13:49: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 NAA08620 for ; Thu, 15 Apr 2004 13:49:41 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BEAsg-0008Md-V5 for ips-archive@odin.ietf.org; Thu, 15 Apr 2004 13:42:30 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i3FHgUTL032147 for ips-archive@odin.ietf.org; Thu, 15 Apr 2004 13:42:30 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BEAme-0006t6-5w for ips-web-archive@optimus.ietf.org; Thu, 15 Apr 2004 13:36:16 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA07884 for ; Thu, 15 Apr 2004 13:36:13 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1BEAmc-0003Gj-00 for ips-web-archive@ietf.org; Thu, 15 Apr 2004 13:36:14 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BEAlf-0003Bf-00 for ips-web-archive@ietf.org; Thu, 15 Apr 2004 13:35:16 -0400 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1BEAkj-00036D-00 for ips-web-archive@ietf.org; Thu, 15 Apr 2004 13:34:17 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BEAXy-0003JA-0P; Thu, 15 Apr 2004 13:21:06 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BEAUG-0002Hl-84 for ips@optimus.ietf.org; Thu, 15 Apr 2004 13:17:16 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA05749 for ; Thu, 15 Apr 2004 13:17:14 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1BEAUE-0001TB-00 for ips@ietf.org; Thu, 15 Apr 2004 13:17:14 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BEATL-0001Pi-00 for ips@ietf.org; Thu, 15 Apr 2004 13:16:19 -0400 Received: from sj-iport-5.cisco.com ([171.68.10.87]) by ietf-mx with esmtp (Exim 4.12) id 1BEASc-0001Gx-00 for ips@ietf.org; Thu, 15 Apr 2004 13:15:34 -0400 Received: from sj-core-4.cisco.com (171.68.223.138) by sj-iport-5.cisco.com with ESMTP; 15 Apr 2004 10:15:04 -0700 Received: from cisco.com (sjc-vpn2-377.cisco.com [10.21.113.121]) by sj-core-4.cisco.com (8.12.10/8.12.6) with ESMTP id i3FHF1hE026636 for ; Thu, 15 Apr 2004 10:15:01 -0700 (PDT) Message-ID: <407EC315.8060608@cisco.com> Date: Thu, 15 Apr 2004 12:15:01 -0500 From: Mark Bakke 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 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Subject: [Ips] Changes to the iSCSI SLP 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.0 required=5.0 tests=none autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit I'm updating the SLP draft to include all of the proposed changes so far, primarily the security considerations, NAT/NAPT considerations, references, and the SMS template for use in discovering iSNS. The primary technical change is to the SMS template, to allow for management services that use either TCP or UDP. I've added the attribute: transports = string M L tcp # This is a list of transport protocols that the registered # entity supports. tcp, udp I will post a more complete list of changes shortly, along with a iscsi-slp-07. -- Mark _______________________________________________ Ips mailing list Ips@ietf.org https://www1.ietf.org/mailman/listinfo/ips From exim@www1.ietf.org Thu Apr 15 14:39: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 OAA12062 for ; Thu, 15 Apr 2004 14:39:42 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BEBka-0006ZR-Lq for ips-archive@odin.ietf.org; Thu, 15 Apr 2004 14:38:12 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i3FIcCOV025252 for ips-archive@odin.ietf.org; Thu, 15 Apr 2004 14:38:12 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BEBi7-0005Xl-Dp for ips-web-archive@optimus.ietf.org; Thu, 15 Apr 2004 14:35:39 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA11298 for ; Thu, 15 Apr 2004 14:35:36 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1BEBi4-0007iv-00 for ips-web-archive@ietf.org; Thu, 15 Apr 2004 14:35:36 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BEBeT-00078w-00 for ips-web-archive@ietf.org; Thu, 15 Apr 2004 14:31:54 -0400 Received: from [65.246.255.50] (helo=mx2.foretec.com) by ietf-mx with esmtp (Exim 4.12) id 1BEBdQ-00074M-00 for ips-web-archive@ietf.org; Thu, 15 Apr 2004 14:30:48 -0400 Received: from optimus22.ietf.org ([132.151.6.22] helo=optimus.ietf.org) by mx2.foretec.com with esmtp (Exim 4.24) id 1BEBa0-0006gc-71 for ips-web-archive@ietf.org; Thu, 15 Apr 2004 14:27:16 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BEBT3-00029f-QF; Thu, 15 Apr 2004 14:20:05 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BEBL2-0000Qh-TJ for ips@optimus.ietf.org; Thu, 15 Apr 2004 14:11:48 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA10266 for ; Thu, 15 Apr 2004 14:11:45 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1BEBL0-0006GV-00 for ips@ietf.org; Thu, 15 Apr 2004 14:11:46 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BEBK3-0006E9-00 for ips@ietf.org; Thu, 15 Apr 2004 14:10:48 -0400 Received: from rtp-iport-1.cisco.com ([64.102.122.148]) by ietf-mx with esmtp (Exim 4.12) id 1BEBJ5-0006Ai-00 for ips@ietf.org; Thu, 15 Apr 2004 14:09:47 -0400 Received: from rtp-core-2.cisco.com (64.102.124.13) by rtp-iport-1.cisco.com with ESMTP; 15 Apr 2004 11:20:48 -0700 X-BrightmailFiltered: true Received: from cisco.com (mbakke-lnx2.cisco.com [64.101.211.59]) by rtp-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id i3FI9Fbd017708 for ; Thu, 15 Apr 2004 14:09:15 -0400 (EDT) Message-ID: <407ECFCB.8040803@cisco.com> Date: Thu, 15 Apr 2004 13:09:15 -0500 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: IPS Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Subject: [Ips] New iscsi-slp 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.0 required=5.0 tests=none autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit I've just submitted a new iscsi-slp draft, to address comments made on the list during the last few months. The draft is available at: ftp://ftpeng.cisco.com/mbakke/ips/iscsi/draft-ietf-ips-iscsi-slp-07.txt Issues Resolved: 1. Security Comments Make sure that IPsec is required whenever SLP is used to distribute security policy, including any of the auth- fields. 2. Update the Security Considerations and Security Implementation sections as per emails 3. Update document to deal with NATs and template chaining 4. Update template for iSNS discovery Emails used to update from -06: 12/17/03 - David Black - FCIP and ISCSI SLP drafts IESG Issue 1 - Add language requiring IPsec whenever security policy (auth-xxxx and boot-list attributes) are distributed via SLP. IESG Issue 2 - Fix up security mechanism language, as provided in 12/23/03 email. 12/23/03 - David Black - FCIP and ISCSI SLP draft revisions Updated references to the IPS-SEC draft. Updated Security Considerations section. 1/16/04 - David Black - draft-ietf-ips-fcip-slp-08.txt Ted Hardie's NAT and template chaining comments. 1/23/04 - David Black - iSCSI SLP draft Updates to security considerations. 1/28/04 - Bill Studenmond - Finding iSNS using SLP Need to provide TCP/UDP transport information when discovering an iSNS URL. Need to discover server priority for iSNS URLs if possible. 1/29/04 - Josh Tseng - (in response to Bill's email) Proposed solution for TCP/UDP transport Non-SLP solution for server priority 3/22/04 - David Black - iSCSI SLP draft status iSNS text additions. 4/14/04 - David Black - iSCSI SLP draft Gentle reminder :-) Changes (by section): Finding Targets Based on Initiator Credentials Added text: Also note that the auth-xxxx attributes are considered to be security policy information. If these attributes are distributed, IPsec MUST be implemented as specified in the Security Implementation section below. Discovering Storage Management Services using SLP Changed URL paragraph to: A storage management server's URL contains the domain name or IP address and TCP or UDP port number. No other information is required. NAT and NAPT Considerations Added text to first paragraph (same as FCIP draft): Also note that SLP advertisements that occur inside a private address realm may be unreachable outside that realm. Added reference to RFC1900, as in FCIP draft. Updated second bullet to: Configure the NAPT device to provide default mapping(s) for the well-known port(s) and use the default IANA-assigned iSCSI TCP port number in service URLs, when possible. Deleted third bullet (SLPv2 proxy). The iSCSI Target Concrete Service Type Template Added to auth-name, auth-addr, auth-cred, and boot-list attributes: # This attribute contains security policy information. If this # attribute is distributed via an Attribute Reply message, # IPsec MUST be used. iSCSI Storage Management Service Templates Added transports attribute (tcp and udp supported, default is tcp) transports = string M L tcp # This is a list of transport protocols that the registered # entity supports. tcp, udp Security Considerations Updated section Security Implementation Updated section References Removed reference to RFC3082 (not referenced in text) Added reference to RFC1900 (non-normative) Updated iSCSI, N&D, Security, and Stringprep references to use the RFC numbers. Updated Author name format in references to match what the RFC editor will require. Misc Updated copyright dates _______________________________________________ Ips mailing list Ips@ietf.org https://www1.ietf.org/mailman/listinfo/ips From exim@www1.ietf.org Thu Apr 15 18:28:24 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 SAA04639 for ; Thu, 15 Apr 2004 18:28:24 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BEFIQ-0004wm-R0 for ips-archive@odin.ietf.org; Thu, 15 Apr 2004 18:25:22 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i3FMPM3e019017 for ips-archive@odin.ietf.org; Thu, 15 Apr 2004 18:25:22 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BEFHC-0003tk-DY for ips-web-archive@optimus.ietf.org; Thu, 15 Apr 2004 18:24:06 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA03215 for ; Thu, 15 Apr 2004 18:24:01 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BEFH9-0001BQ-9H for ips-web-archive@ietf.org; Thu, 15 Apr 2004 18:24:03 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BEF6b-0007R9-00 for ips-web-archive@ietf.org; Thu, 15 Apr 2004 18:13:11 -0400 Received: from [65.246.255.50] (helo=mx2.foretec.com) by ietf-mx with esmtp (Exim 4.12) id 1BEEdN-0006Cd-00 for ips-web-archive@ietf.org; Thu, 15 Apr 2004 17:42:57 -0400 Received: from optimus22.ietf.org ([132.151.6.22] helo=optimus.ietf.org) by mx2.foretec.com with esmtp (Exim 4.24) id 1BEEPH-0000o3-64 for ips-web-archive@ietf.org; Thu, 15 Apr 2004 17:28:23 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BEDkh-0000sR-M6; Thu, 15 Apr 2004 16:46:27 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BEDg8-0008LP-B8 for ips@optimus.ietf.org; Thu, 15 Apr 2004 16:41:44 -0400 Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA25618; Thu, 15 Apr 2004 16:41:41 -0400 (EDT) Message-Id: <200404152041.QAA25618@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: i-d-announce@ietf.org Cc: ips@ietf.org From: Internet-Drafts@ietf.org Date: Thu, 15 Apr 2004 16:41:40 -0400 Subject: [Ips] I-D ACTION:draft-ietf-ips-iscsi-slp-07.txt 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,MIME_BOUND_NEXTPART, NO_REAL_NAME autolearn=no version=2.60 --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the IP Storage Working Group of the IETF. Title : Finding iSCSI Targets and Name Servers Using SLP Author(s) : M. Bakke, et al. Filename : draft-ietf-ips-iscsi-slp-07.txt Pages : 23 Date : 2004-4-15 The iSCSI protocol provides a way for hosts to access SCSI devices over an IP network. This document defines the use of the Service Location Protocol (SLP) by iSCSI hosts, devices, and management services, along with the SLP service type templates that describe the services they provide. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-ips-iscsi-slp-07.txt To remove yourself from the I-D Announcement list, send a message to i-d-announce-request@ietf.org with the word unsubscribe in the body of the message. You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce to change your subscription settings. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-ips-iscsi-slp-07.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-ips-iscsi-slp-07.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <2004-4-15153853.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-ips-iscsi-slp-07.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-ips-iscsi-slp-07.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2004-4-15153853.I-D@ietf.org> --OtherAccess-- --NextPart-- _______________________________________________ Ips mailing list Ips@ietf.org https://www1.ietf.org/mailman/listinfo/ips From exim@www1.ietf.org Thu Apr 15 18:39:34 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 SAA05999 for ; Thu, 15 Apr 2004 18:39:34 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BEFTM-0008QG-6E for ips-archive@odin.ietf.org; Thu, 15 Apr 2004 18:36:40 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i3FMaeRH032368 for ips-archive@odin.ietf.org; Thu, 15 Apr 2004 18:36:40 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BEFKY-00062J-KR for ips-web-archive@optimus.ietf.org; Thu, 15 Apr 2004 18:27:34 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA04376 for ; Thu, 15 Apr 2004 18:27:29 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BEFKV-0001jf-H1 for ips-web-archive@ietf.org; Thu, 15 Apr 2004 18:27:31 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BEFC9-0000V7-00 for ips-web-archive@ietf.org; Thu, 15 Apr 2004 18:18:55 -0400 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1BEEum-0006R3-00 for ips-web-archive@ietf.org; Thu, 15 Apr 2004 18:00:56 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BEEkG-0005VZ-Er; Thu, 15 Apr 2004 17:50:04 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BEEHY-00041X-F8 for ips@optimus.ietf.org; Thu, 15 Apr 2004 17:20:24 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA27767 for ; Thu, 15 Apr 2004 17:20:20 -0400 (EDT) From: Black_David@emc.com Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BEEHW-0003V2-3A for ips@ietf.org; Thu, 15 Apr 2004 17:20:22 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BEEAf-00032Z-00 for ips@ietf.org; Thu, 15 Apr 2004 17:13:18 -0400 Received: from mxic2.corp.emc.com ([128.221.12.9]) by ietf-mx with esmtp (Exim 4.12) id 1BEEA3-0002uE-00 for ips@ietf.org; Thu, 15 Apr 2004 17:12:39 -0400 Received: by mxic2.corp.emc.com with Internet Mail Service (5.5.2653.19) id <20065BXZ>; Thu, 15 Apr 2004 17:11:57 -0400 Message-ID: To: mbakke@cisco.com, ips@ietf.org Subject: RE: [Ips] New iscsi-slp draft Date: Thu, 15 Apr 2004 17:11:55 -0400 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 > Added to auth-name, auth-addr, auth-cred, and boot-list attributes: > > # This attribute contains security policy information. If this > # attribute is distributed via an Attribute Reply message, > # IPsec MUST be used. Oops, that should say "MUST be implemented", not "MUST be used". The IPsec requirement is "MUST implement, MAY use" when distributing security policy information (for iSCSI SLP, this means distribution of anything containing identity info on initiators that can access a target). 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 Fri Apr 16 03:40: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 DAA20117 for ; Fri, 16 Apr 2004 03:40:13 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BENos-0001pd-DM for ips-archive@odin.ietf.org; Fri, 16 Apr 2004 03:31:26 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i3G7VQtD007041 for ips-archive@odin.ietf.org; Fri, 16 Apr 2004 03:31:26 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BENjk-0000xb-UH for ips-web-archive@optimus.ietf.org; Fri, 16 Apr 2004 03:26:08 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA19136 for ; Fri, 16 Apr 2004 03:26:07 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BENji-0003sq-LE for ips-web-archive@ietf.org; Fri, 16 Apr 2004 03:26:06 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BENiy-0003mR-00 for ips-web-archive@ietf.org; Fri, 16 Apr 2004 03:25:21 -0400 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1BENiR-0003eq-00 for ips-web-archive@ietf.org; Fri, 16 Apr 2004 03:24:47 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BENdv-0007kw-7d; Fri, 16 Apr 2004 03:20:07 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BENYd-0006cw-R5 for ips@optimus.ietf.org; Fri, 16 Apr 2004 03:14:39 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA18115 for ; Fri, 16 Apr 2004 03:14:38 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BENYb-0002NG-Jf for ips@ietf.org; Fri, 16 Apr 2004 03:14:37 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BENXQ-0002Aj-00 for ips@ietf.org; Fri, 16 Apr 2004 03:13:25 -0400 Received: from gw2.cox.com ([24.248.72.254] helo=hatl0ms21.CORP.COX.COM) by ietf-mx with esmtp (Exim 4.12) id 1BENWH-0001qB-00; Fri, 16 Apr 2004 03:12:13 -0400 Received: from mail pickup service by hatl0ms21.CORP.COX.COM with Microsoft SMTPSVC; Fri, 16 Apr 2004 03:11:44 -0400 Received: from cox.com ([10.225.2.122]) by hatl0ms23.corp.cox.com with Microsoft SMTPSVC(5.0.2195.6713); Thu, 15 Apr 2004 19:09:43 -0400 Received: from ([132.151.6.22]) by post4.cox.com with SMTP ; Thu, 15 Apr 2004 18:50:32 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BEDkg-0000sB-9s; Thu, 15 Apr 2004 16:46:26 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BEDg8-0008LP-8Y for i-d-announce@optimus.ietf.org; Thu, 15 Apr 2004 16:41:44 -0400 Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA25618; Thu, 15 Apr 2004 16:41:41 -0400 (EDT) Message-Id: <200404152041.QAA25618@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: i-d-announce@ietf.org Cc: ips@ietf.org From: Internet-Drafts@ietf.org Date: Thu, 15 Apr 2004 16:41:40 -0400 X-BeenThere: i-d-announce@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk Reply-To: internet-drafts@ietf.org X-OriginalArrivalTime: 15 Apr 2004 23:09:43.0009 (UTC) FILETIME=[BC773510:01C4233E] Subject: [Ips] I-D ACTION:draft-ietf-ips-iscsi-slp-07.txt Sender: ips-admin@ietf.org Errors-To: ips-admin@ietf.org X-BeenThere: ips@ietf.org 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,MIME_BOUND_NEXTPART, NO_REAL_NAME autolearn=no version=2.60 --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the IP Storage Working Group of the IETF. Title : Finding iSCSI Targets and Name Servers Using SLP Author(s) : M. Bakke, et al. Filename : draft-ietf-ips-iscsi-slp-07.txt Pages : 23 Date : 2004-4-15 The iSCSI protocol provides a way for hosts to access SCSI devices over an IP network. This document defines the use of the Service Location Protocol (SLP) by iSCSI hosts, devices, and management services, along with the SLP service type templates that describe the services they provide. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-ips-iscsi-slp-07.txt To remove yourself from the I-D Announcement list, send a message to i-d-announce-request@ietf.org with the word unsubscribe in the body of the message. You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce to change your subscription settings. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-ips-iscsi-slp-07.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-ips-iscsi-slp-07.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <2004-4-15153853.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-ips-iscsi-slp-07.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-ips-iscsi-slp-07.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2004-4-15153853.I-D@ietf.org> --OtherAccess-- --NextPart-- _______________________________________________ I-D-Announce mailing list I-D-Announce@ietf.org https://www.ietf.org/mailman/listinfo/i-d-announce _______________________________________________ Ips mailing list Ips@ietf.org https://www1.ietf.org/mailman/listinfo/ips From exim@www1.ietf.org Fri Apr 16 09:55:39 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 JAA09393 for ; Fri, 16 Apr 2004 09:55:39 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BETmy-0001oI-2I for ips-archive@odin.ietf.org; Fri, 16 Apr 2004 09:53:52 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i3GDrqgd006958 for ips-archive@odin.ietf.org; Fri, 16 Apr 2004 09:53:52 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BETlM-0001Li-Di for ips-web-archive@optimus.ietf.org; Fri, 16 Apr 2004 09:52:12 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA09108 for ; Fri, 16 Apr 2004 09:52:09 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BETlK-0006zl-HG for ips-web-archive@ietf.org; Fri, 16 Apr 2004 09:52:10 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BETkL-0006wM-00 for ips-web-archive@ietf.org; Fri, 16 Apr 2004 09:51:10 -0400 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1BETjP-0006tr-00 for ips-web-archive@ietf.org; Fri, 16 Apr 2004 09:50:11 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BETdS-0007oe-W5; Fri, 16 Apr 2004 09:44:02 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BETZf-0006sW-GA for ips@optimus.ietf.org; Fri, 16 Apr 2004 09:40:07 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA08281 for ; Fri, 16 Apr 2004 09:40:04 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BETZd-00069P-Kq for ips@ietf.org; Fri, 16 Apr 2004 09:40:05 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BETYe-000604-00 for ips@ietf.org; Fri, 16 Apr 2004 09:39:05 -0400 Received: from rtp-iport-1.cisco.com ([64.102.122.148]) by ietf-mx with esmtp (Exim 4.12) id 1BETXk-0005sG-00 for ips@ietf.org; Fri, 16 Apr 2004 09:38:08 -0400 Received: from rtp-core-1.cisco.com (64.102.124.12) by rtp-iport-1.cisco.com with ESMTP; 16 Apr 2004 06:49:17 -0700 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 i3GDbYwb016880; Fri, 16 Apr 2004 09:37:35 -0400 (EDT) Message-ID: <407FE19E.2010505@cisco.com> Date: Fri, 16 Apr 2004 08:37:34 -0500 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] New iscsi-slp draft 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 My bad; I must have been typing too fast. Should I issue another draft, or should I do this during auth48? Black_David@emc.com wrote: >> Added to auth-name, auth-addr, auth-cred, and boot-list attributes: >> >> # This attribute contains security policy information. If this >> # attribute is distributed via an Attribute Reply message, >> # IPsec MUST be used. >> >> > >Oops, that should say "MUST be implemented", not "MUST be used". The >IPsec requirement is "MUST implement, MAY use" when distributing security >policy information (for iSCSI SLP, this means distribution of anything >containing identity info on initiators that can access a target). > >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 Fri Apr 16 21:10: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 VAA24901 for ; Fri, 16 Apr 2004 21:10:03 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BEeJu-0004xt-EZ for ips-archive@odin.ietf.org; Fri, 16 Apr 2004 21:08:34 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i3H18Y1e019083 for ips-archive@odin.ietf.org; Fri, 16 Apr 2004 21:08:34 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BEeE6-00039V-Kl for ips-web-archive@optimus.ietf.org; Fri, 16 Apr 2004 21:02:34 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA24513 for ; Fri, 16 Apr 2004 21:02:32 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BEeE4-0000gb-5u for ips-web-archive@ietf.org; Fri, 16 Apr 2004 21:02:32 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BEeDC-0000al-00 for ips-web-archive@ietf.org; Fri, 16 Apr 2004 21:01:39 -0400 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1BEeCQ-0000Xa-00 for ips-web-archive@ietf.org; Fri, 16 Apr 2004 21:00:50 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BEe4s-0000eo-KU; Fri, 16 Apr 2004 20:53:02 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BEe3S-0000Aw-8e for ips@optimus.ietf.org; Fri, 16 Apr 2004 20:51:34 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA23706 for ; Fri, 16 Apr 2004 20:51:31 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BEe3P-0007Yb-Oo for ips@ietf.org; Fri, 16 Apr 2004 20:51:31 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BEe2W-0007VS-00 for ips@ietf.org; Fri, 16 Apr 2004 20:50:36 -0400 Received: from mononoke.wasabisystems.com ([151.199.66.145]) by ietf-mx with esmtp (Exim 4.12) id 1BEe1z-0007SY-00 for ips@ietf.org; Fri, 16 Apr 2004 20:50:03 -0400 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 A834840135; Fri, 16 Apr 2004 20:50:01 -0400 (EDT) In-Reply-To: <407ECFCB.8040803@cisco.com> References: <407ECFCB.8040803@cisco.com> Mime-Version: 1.0 (Apple Message framework v613) Content-Type: multipart/signed; protocol="application/pgp-signature"; micalg=pgp-sha1; boundary="Apple-Mail-3-776578429" Message-Id: <23A92338-9009-11D8-870C-000A95D14BEC@wasabisystems.com> Content-Transfer-Encoding: 7bit Cc: IPS From: William Studenmund Subject: Re: [Ips] New iscsi-slp draft Date: Fri, 16 Apr 2004 17:49:53 -0700 To: josh.tseng@mcdata.com, Mark Bakke 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-776578429 Content-Type: text/plain; charset=US-ASCII; format=flowed Content-Transfer-Encoding: 7bit On Apr 15, 2004, at 11:09 AM, Mark Bakke wrote: > I've just submitted a new iscsi-slp draft, to address comments made on > the list > during the last few months. The draft is available at: [snip] > 1/28/04 - Bill Studenmond - Finding iSNS using SLP > > Need to provide TCP/UDP transport information when discovering > an iSNS URL. > > Need to discover server priority for iSNS URLs if possible. > > 1/29/04 - Josh Tseng - (in response to Bill's email) > > Proposed solution for TCP/UDP transport > > Non-SLP solution for server priority I'm sorry I didn't get to you yesterday about this. I've been thinking about it, and I'm not sure I like this idea. Just for everyone else, the idea is that we only have the active iSNS server advertising itself via SLP. In the case of failover, the backup server advertises itself and we wait for the original SLP advertisement to expire. I think the thing I dislike most about this is that the other location methods, DHCP and heartbeat, report all the servers. Not including a server priority means SLP acts differently. Additionally, it means that iSNS servers have to put lifetimes on their SLP registrations. And the registrations have to have a lifetime that does not severely impact failover (if the idea is that only active hosts are advertised). Since the iSNS clients have to worry about failover anyway, I think it'd be better to include the priority. Then SLP discovery would work the same as heartbeat and DHCP. Take care, Bill --Apple-Mail-3-776578429 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) iD8DBQFAgH83DJT2Egh26K0RAjI5AJ9iAQ2RjCQ10Z2bavi/JOxXfUmiywCgmDQp vPY55oZe/GPRkz7uihQK7ho= =WuF5 -----END PGP SIGNATURE----- --Apple-Mail-3-776578429-- _______________________________________________ Ips mailing list Ips@ietf.org https://www1.ietf.org/mailman/listinfo/ips From exim@www1.ietf.org Sat Apr 17 00:11: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 AAA03090 for ; Sat, 17 Apr 2004 00:11:33 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BEh9w-0005Ot-TN for ips-archive@odin.ietf.org; Sat, 17 Apr 2004 00:10:29 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i3H4ASju020752 for ips-archive@odin.ietf.org; Sat, 17 Apr 2004 00:10:28 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BEh5N-0003q1-EP for ips-web-archive@optimus.ietf.org; Sat, 17 Apr 2004 00:05:45 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA02778 for ; Sat, 17 Apr 2004 00:05:42 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BEh5K-0005KL-Ow for ips-web-archive@ietf.org; Sat, 17 Apr 2004 00:05:42 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BEh4Y-0005Gd-00 for ips-web-archive@ietf.org; Sat, 17 Apr 2004 00:04:55 -0400 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1BEh3j-0005Cx-00 for ips-web-archive@ietf.org; Sat, 17 Apr 2004 00:04:03 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BEgys-0002IN-AB; Fri, 16 Apr 2004 23:59:02 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BEgvi-0001NV-Hd for ips@optimus.ietf.org; Fri, 16 Apr 2004 23:55:46 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA02442 for ; Fri, 16 Apr 2004 23:55:43 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BEgvf-0004gA-Uh for ips@ietf.org; Fri, 16 Apr 2004 23:55:44 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BEguz-0004bx-00 for ips@ietf.org; Fri, 16 Apr 2004 23:55:03 -0400 Received: from web21323.mail.yahoo.com ([216.136.175.209]) by ietf-mx with smtp (Exim 4.12) id 1BEgty-0004WM-00 for ips@ietf.org; Fri, 16 Apr 2004 23:53:58 -0400 Message-ID: <20040417035358.26558.qmail@web21323.mail.yahoo.com> Received: from [63.201.88.190] by web21323.mail.yahoo.com via HTTP; Fri, 16 Apr 2004 20:53:58 PDT Date: Fri, 16 Apr 2004 20:53:58 -0700 (PDT) From: Josh Tseng Subject: Re: [Ips] New iscsi-slp draft To: William Studenmund , joshtseng@yahoo.com, Mark Bakke Cc: IPS In-Reply-To: <23A92338-9009-11D8-870C-000A95D14BEC@wasabisystems.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 agree with Bill. Although I lost the original e-mail thread, I believe the comment was to include a priority field in the SMS template, and not to rely exclusively on the iSNS server heartbeat for failover priority. Josh --- William Studenmund wrote: > > On Apr 15, 2004, at 11:09 AM, Mark Bakke wrote: > > > I've just submitted a new iscsi-slp draft, to > address comments made on > > the list > > during the last few months. The draft is > available at: > > [snip] > > > 1/28/04 - Bill Studenmond - Finding iSNS using SLP > > > > Need to provide TCP/UDP transport information > when discovering > > an iSNS URL. > > > > Need to discover server priority for iSNS URLs if > possible. > > > > 1/29/04 - Josh Tseng - (in response to Bill's > email) > > > > Proposed solution for TCP/UDP transport > > > > Non-SLP solution for server priority > > I'm sorry I didn't get to you yesterday about this. > > I've been thinking about it, and I'm not sure I like > this idea. Just > for everyone > else, the idea is that we only have the active iSNS > server advertising > itself via SLP. In the case of failover, the backup > server advertises > itself > and we wait for the original SLP advertisement to > expire. > > I think the thing I dislike most about this is that > the other location > methods, > DHCP and heartbeat, report all the servers. Not > including a server > priority > means SLP acts differently. > > Additionally, it means that iSNS servers have to put > lifetimes on their > SLP > registrations. And the registrations have to have a > lifetime that does > not > severely impact failover (if the idea is that only > active hosts are > advertised). > > Since the iSNS clients have to worry about failover > anyway, I think > it'd be > better to include the priority. Then SLP discovery > would work the same > as > heartbeat and DHCP. > > Take care, > > Bill > > ATTACHMENT part 2 application/pgp-signature x-mac-type=70674453; name=PGP.sig __________________________________ Do you Yahoo!? Yahoo! Tax Center - File online by April 15th http://taxes.yahoo.com/filing.html _______________________________________________ Ips mailing list Ips@ietf.org https://www1.ietf.org/mailman/listinfo/ips From exim@www1.ietf.org Sat Apr 17 11:14: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 LAA14824 for ; Sat, 17 Apr 2004 11:14:43 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BErSI-0004QB-Kj for ips-archive@odin.ietf.org; Sat, 17 Apr 2004 11:10:06 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i3HFA6pK016995 for ips-archive@odin.ietf.org; Sat, 17 Apr 2004 11:10:06 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BErLd-0002Y8-Qa for ips-web-archive@optimus.ietf.org; Sat, 17 Apr 2004 11:03:13 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA14215 for ; Sat, 17 Apr 2004 11:03:09 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BErLb-0002zZ-AM for ips-web-archive@ietf.org; Sat, 17 Apr 2004 11:03:11 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BErKe-0002qU-00 for ips-web-archive@ietf.org; Sat, 17 Apr 2004 11:02:14 -0400 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1BErK3-0002hd-00 for ips-web-archive@ietf.org; Sat, 17 Apr 2004 11:01:35 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BErFd-0000pf-IS; Sat, 17 Apr 2004 10:57:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BEqig-0000AU-6u for ips@optimus.ietf.org; Sat, 17 Apr 2004 10:22:58 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA12150 for ; Sat, 17 Apr 2004 10:22:54 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BEqid-0004xI-UC for ips@ietf.org; Sat, 17 Apr 2004 10:22:56 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BEqhh-0004pR-00 for ips@ietf.org; Sat, 17 Apr 2004 10:21:58 -0400 Received: from mx01.netapp.com ([198.95.226.53]) by ietf-mx with esmtp (Exim 4.12) id 1BEqgj-0004cK-00 for ips@ietf.org; Sat, 17 Apr 2004 10:20:57 -0400 Received: from frejya.corp.netapp.com (frejya [10.57.157.119]) by mx01.netapp.com (8.12.10/8.12.10/NTAP-1.4) with ESMTP id i3HEKQZh029287 for ; Sat, 17 Apr 2004 07:20:26 -0700 (PDT) Received: from svlexc01.hq.netapp.com (svlexc01.corp.netapp.com [10.57.156.135]) by frejya.corp.netapp.com (8.12.9/8.12.9/NTAP-1.5) with ESMTP id i3HEKQNm028668 for ; Sat, 17 Apr 2004 07:20:26 -0700 (PDT) Received: from rtpexc03.hq.netapp.com ([10.60.4.50]) by svlexc01.hq.netapp.com with Microsoft SMTPSVC(5.0.2195.6713); Sat, 17 Apr 2004 07:20:26 -0700 x-mimeole: Produced By Microsoft Exchange V6.0.6249.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C42487.201CC18B" Date: Sat, 17 Apr 2004 10:20:25 -0400 Message-ID: <3A62517F5A8AFE4098ADDBD25B5D4D5C2FBC50@rtpexc03.hq.netapp.com> Thread-Topic: Multi-connection sessions and ErrorRecoveryLevel=0 Thread-Index: AcQkhx+aAx/5nAERRrSU0rZjtmkh7A== From: "Pittman, Joseph" To: X-OriginalArrivalTime: 17 Apr 2004 14:20:26.0029 (UTC) FILETIME=[20A81DD0:01C42487] Subject: [Ips] Multi-connection sessions and ErrorRecoveryLevel=0 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_001_01C42487.201CC18B Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable I have a question about multi-connection sessions with ErrorRecoveryLevel=3D0. =20 Consider this situation: =20 - Session is in progress consisting of 2 TCP connections {C1, C2) - Initiator and Target have negotiated ErrorRecoveryLevel=3D0 - The target detects an error on TCP connection C1. =20 What is the target supposed to do? And, for any initiator-implementers out there, what actions do you plan to take in the face of such an event? =20 I know that the target (or initiator) may choose to escalate this situation to session recovery, and simply shutdown the entire session, sending the appropriate ASYNC_MSG, etc. =20 But is there provision within the spec for the session to persist beyond the loss of an individual TCP connection, even though ERL=3D0 eliminates the possibility for task reassignment and connection recovery? =20 Sometimes when I read the spec, I think the target is allowed to handle this situation by taking these actions: =20 - Discard any cmd PDUs which have not yet been submitted to the SCSI layer - Abort all in-progress commands associated with the failed connection - Shutdown the failed connection - If the discarded PDUs result in a cmd sequence window hole, then the initiator will have to either resubmit those cmds, or use task management commands to fill the hole. =20 But other times, when I read the spec, I have doubts about whether such behavior is prescribed or expected. =20 Thanks in advance for any guidance! -- Joe Pittman jpittman@netapp.com ------_=_NextPart_001_01C42487.201CC18B Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Message
I have a=20 question about multi-connection sessions with=20 ErrorRecoveryLevel=3D0.
 
Consider=20 this situation:
 
- Session is=20 in progress consisting of 2 TCP connections {C1, = C2)
- Initiator=20 and Target have negotiated ErrorRecoveryLevel=3D0
- The target=20 detects an error on TCP connection C1.
 
What is the=20 target supposed to do?  And, for any=20 initiator-implementers
out there,=20 what actions do you plan to take in the face of such an=20 event?
 
I know that=20 the target (or initiator) may choose to escalate = this
situation to=20 session recovery, and simply shutdown the entire = session,
sending the=20 appropriate ASYNC_MSG, etc.
 
But is there=20 provision within the spec for the session to persist
beyond the=20 loss of an individual TCP connection, even though = ERL=3D0
eliminates=20 the possibility for task reassignment and connection
recovery?
 
Sometimes=20 when I read the spec, I think the target is allowed = to
handle this=20 situation by taking these actions:
 
- Discard=20 any cmd PDUs which have not yet been submitted to
  the=20 SCSI layer
- Abort all=20 in-progress commands associated with the failed
  connection
- Shutdown=20 the failed connection
- If the=20 discarded PDUs result in a cmd sequence window hole,
  then=20 the initiator will have to either resubmit those = cmds,
  or=20 use task management commands to fill the hole.
 
But other=20 times, when I read the spec, I have doubts about
whether such=20 behavior is prescribed or expected.
 
Thanks in=20 advance for any guidance!
--
Joe=20 Pittman
jpittman@netapp.com=
=00 ------_=_NextPart_001_01C42487.201CC18B-- _______________________________________________ Ips mailing list Ips@ietf.org https://www1.ietf.org/mailman/listinfo/ips From exim@www1.ietf.org Sat Apr 17 13:00: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 NAA19087 for ; Sat, 17 Apr 2004 13:00:43 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BEt5V-00085m-Ry for ips-archive@odin.ietf.org; Sat, 17 Apr 2004 12:54:42 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i3HGsfp3031101 for ips-archive@odin.ietf.org; Sat, 17 Apr 2004 12:54:41 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BEsxH-00065L-Ba for ips-web-archive@optimus.ietf.org; Sat, 17 Apr 2004 12:46:11 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA17987 for ; Sat, 17 Apr 2004 12:46:07 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BEsxF-0001oJ-Nx for ips-web-archive@ietf.org; Sat, 17 Apr 2004 12:46:09 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BEswH-0001gp-00 for ips-web-archive@ietf.org; Sat, 17 Apr 2004 12:45:10 -0400 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1BEsvt-0001Yh-00 for ips-web-archive@ietf.org; Sat, 17 Apr 2004 12:44:45 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BEsnS-0002vE-T8; Sat, 17 Apr 2004 12:36:02 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BEshi-0000rs-4w for ips@optimus.ietf.org; Sat, 17 Apr 2004 12:30:06 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA17514 for ; Sat, 17 Apr 2004 12:30:02 -0400 (EDT) From: AClarke@attotech.com Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BEshg-0007PD-HP for ips@ietf.org; Sat, 17 Apr 2004 12:30:04 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BEsgn-0007Hj-00 for ips@ietf.org; Sat, 17 Apr 2004 12:29:10 -0400 Received: from sw.attotech.com ([12.32.232.56] helo=noteserv1.attotech.com) by ietf-mx with esmtp (Exim 4.12) id 1BEsgL-00079c-00; Sat, 17 Apr 2004 12:28:41 -0400 Subject: Re: [Ips] Multi-connection sessions and ErrorRecoveryLevel=0 To: "Pittman, Joseph" Cc: ips@ietf.org, ips-admin@ietf.org Message-ID: Date: Sat, 17 Apr 2004 12:26:57 -0400 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 >- Session is in progress consisting of 2 TCP connections {C1, C2) >- Initiator and Target have negotiated ErrorRecoveryLevel=0 >- The target detects an error on TCP connection C1. >What is the target supposed to do? And, for any initiator-implementers >out there, what actions do you plan to take in the face of such an event? I think the spec. covers what happens to the commands on the lost connection. But the error recovery level 0 case not spelled out in one section. The commands do not persist (3.2.7), and if the initiator attempts reinstatement (maybe the target has not noticed the connection failure yet) it must terminate the commands immediately (5.3.4). You also have to look at clearing effects in appendix F1. (partial pdus are cleared etc.). >But is there provision within the spec for the session to persist >beyond the loss of an individual TCP connection, even though ERL=0 >eliminates the possibility for task reassignment and connection >recovery? By definition the session persists, but the question is for error recovery level 0 is it useful? I think that it could be depending on the situation: 1. If there were no commands in process or transit on that lost connection then the session can definitly continue without a problem. The initiator can even add another connection to replace it. 2. Partial PDUs in transit but none in process. The initiator should see an error on send and must clear the partial pdu. It can then re-send it on another connection (assuming it has not sent a higher cmdsn already, if so then you have a sequence gap). 3. Commands in process by the target. The status cannot return on the same connection. This can be handled by a task management from the initiator. In any case at the target you can only wait for task management or if you detect something really bad then do session recovery. But I don't think session recovery is automatic for a lost connection at level 0. I hope this helps, I am also working on multiple connection issues with erl 0, so I would appreciate any comments. Aaron _______________________________________________ Ips mailing list Ips@ietf.org https://www1.ietf.org/mailman/listinfo/ips From exim@www1.ietf.org Sat Apr 17 23:01: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 XAA12129 for ; Sat, 17 Apr 2004 23:01:33 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BF2Ni-0002wE-Il for ips-archive@odin.ietf.org; Sat, 17 Apr 2004 22:50:06 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i3I2o6F8011286 for ips-archive@odin.ietf.org; Sat, 17 Apr 2004 22:50:06 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BF2JV-0008ON-9w for ips-web-archive@optimus.ietf.org; Sat, 17 Apr 2004 22:45:45 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA10428 for ; Sat, 17 Apr 2004 22:45:40 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BF2JS-0004ab-0R for ips-web-archive@ietf.org; Sat, 17 Apr 2004 22:45:42 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BF2IY-0004OV-00 for ips-web-archive@ietf.org; Sat, 17 Apr 2004 22:44:48 -0400 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1BF2Hs-0004Dj-00 for ips-web-archive@ietf.org; Sat, 17 Apr 2004 22:44:04 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BF1pS-0006A1-Qw; Sat, 17 Apr 2004 22:14:42 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BEyyx-0007vL-29 for ips@optimus.ietf.org; Sat, 17 Apr 2004 19:12:19 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA02141 for ; Sat, 17 Apr 2004 19:12:15 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BEyyv-0002Nx-Bl for ips@ietf.org; Sat, 17 Apr 2004 19:12:17 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BEyxy-0002G1-00 for ips@ietf.org; Sat, 17 Apr 2004 19:11:19 -0400 Received: from mtagate3.de.ibm.com ([195.212.29.152]) by ietf-mx with esmtp (Exim 4.12) id 1BEyxT-0001zD-00; Sat, 17 Apr 2004 19:10:47 -0400 Received: from d12nrmr1607.megacenter.de.ibm.com (d12nrmr1607.megacenter.de.ibm.com [9.149.167.49]) by mtagate3.de.ibm.com (8.12.10/8.12.10) with ESMTP id i3HNA6n5109420; Sat, 17 Apr 2004 23:10:06 GMT Received: from d12ml102.megacenter.de.ibm.com (d12av02.megacenter.de.ibm.com [9.149.165.228]) by d12nrmr1607.megacenter.de.ibm.com (8.12.10/NCO/VER6.6) with ESMTP id i3HNA68J023696; Sun, 18 Apr 2004 01:10:06 +0200 In-Reply-To: <3A62517F5A8AFE4098ADDBD25B5D4D5C2FBC50@rtpexc03.hq.netapp.com> To: "Pittman, Joseph" Cc: ips@ietf.org, ips-admin@ietf.org MIME-Version: 1.0 Subject: Re: [Ips] Multi-connection sessions and ErrorRecoveryLevel=0 X-Mailer: Lotus Notes Release 6.5.1 January 21, 2004 From: Julian Satran Message-ID: Date: Sat, 17 Apr 2004 19:12:31 -0400 X-MIMETrack: Serialize by Router on D12ML102/12/M/IBM(Release 6.0.2CF2|July 23, 2003) at 18/04/2004 02:12:34, Serialize complete at 18/04/2004 02:12:34 Content-Type: multipart/alternative; boundary="=_alternative 007C340F85256E79_=" 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.6 required=5.0 tests=AWL,HTML_30_40, HTML_FONTCOLOR_UNKNOWN,HTML_MESSAGE autolearn=no version=2.60 This is a multipart message in MIME format. --=_alternative 007C340F85256E79_= Content-Type: text/plain; charset="US-ASCII" Joe, The ErrorLevel setting was "created" to simplify the different recovery options and to reduce the number of "alternatives" that have to be supported (keep complexity acceptable). It may be that what you want the target to do will be handled properly while some other initiators may resort to the big harmer and reset the session. Essentially you will end-up having to extend your testing to cover all the cases (and probably many initiators will play along!) but you will not be sure and will not be able to claim that "my target withstands the loss of a connection" as there might be initiators hat will not play along (which I assume was the purpose of your question) unless you successfully negotiate the proper ErrorLevel. Julo "Pittman, Joseph" Sent by: ips-admin@ietf.org 17/04/04 10:20 To cc Subject [Ips] Multi-connection sessions and ErrorRecoveryLevel=0 I have a question about multi-connection sessions with ErrorRecoveryLevel=0. Consider this situation: - Session is in progress consisting of 2 TCP connections {C1, C2) - Initiator and Target have negotiated ErrorRecoveryLevel=0 - The target detects an error on TCP connection C1. What is the target supposed to do? And, for any initiator-implementers out there, what actions do you plan to take in the face of such an event? I know that the target (or initiator) may choose to escalate this situation to session recovery, and simply shutdown the entire session, sending the appropriate ASYNC_MSG, etc. But is there provision within the spec for the session to persist beyond the loss of an individual TCP connection, even though ERL=0 eliminates the possibility for task reassignment and connection recovery? Sometimes when I read the spec, I think the target is allowed to handle this situation by taking these actions: - Discard any cmd PDUs which have not yet been submitted to the SCSI layer - Abort all in-progress commands associated with the failed connection - Shutdown the failed connection - If the discarded PDUs result in a cmd sequence window hole, then the initiator will have to either resubmit those cmds, or use task management commands to fill the hole. But other times, when I read the spec, I have doubts about whether such behavior is prescribed or expected. Thanks in advance for any guidance! -- Joe Pittman jpittman@netapp.com --=_alternative 007C340F85256E79_= Content-Type: text/html; charset="US-ASCII"
Joe,

The ErrorLevel setting was "created" to simplify the different recovery options and to reduce the number of "alternatives" that have to be supported (keep complexity acceptable).
It may be that what you want the target to do will be handled properly while some other initiators may resort to the big harmer and reset the session.
Essentially you will end-up having to extend your testing to cover all the cases (and probably many initiators will play along!) but you will not be sure and will not be able to claim that "my target withstands the loss of a connection" as there might be initiators hat will not play along (which I assume was the purpose of your question) unless you successfully negotiate the proper ErrorLevel.

Julo


"Pittman, Joseph" <Joseph.Pittman@netapp.com>
Sent by: ips-admin@ietf.org

17/04/04 10:20

To
<ips@ietf.org>
cc
Subject
[Ips] Multi-connection sessions and ErrorRecoveryLevel=0





I have a question about multi-connection sessions with ErrorRecoveryLevel=0.
 
Consider this situation:
 
- Session is in progress consisting of 2 TCP connections {C1, C2)
- Initiator and Target have negotiated ErrorRecoveryLevel=0
- The target detects an error on TCP connection C1.
 
What is the target supposed to do?  And, for any initiator-implementers
out there, what actions do you plan to take in the face of such an event?
 
I know that the target (or initiator) may choose to escalate this
situation to session recovery, and simply shutdown the entire session,
sending the appropriate ASYNC_MSG, etc.
 
But is there provision within the spec for the session to persist
beyond the loss of an individual TCP connection, even though ERL=0
eliminates the possibility for task reassignment and connection
recovery?
 
Sometimes when I read the spec, I think the target is allowed to
handle this situation by taking these actions:
 
- Discard any cmd PDUs which have not yet been submitted to
  the SCSI layer
- Abort all in-progress commands associated with the failed
  connection
- Shutdown the failed connection
- If the discarded PDUs result in a cmd sequence window hole,
  then the initiator will have to either resubmit those cmds,
  or use task management commands to fill the hole.
 
But other times, when I read the spec, I have doubts about
whether such behavior is prescribed or expected.
 
Thanks in advance for any guidance!
--
Joe Pittman
jpittman@netapp.com
--=_alternative 007C340F85256E79_=-- _______________________________________________ Ips mailing list Ips@ietf.org https://www1.ietf.org/mailman/listinfo/ips From exim@www1.ietf.org Sun Apr 18 12:17: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 MAA28782 for ; Sun, 18 Apr 2004 12:17:07 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BFExU-0007Tq-Bk for ips-archive@odin.ietf.org; Sun, 18 Apr 2004 12:15:52 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i3IGFqQF028754 for ips-archive@odin.ietf.org; Sun, 18 Apr 2004 12:15:52 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BFEjE-0003ET-52 for ips-web-archive@optimus.ietf.org; Sun, 18 Apr 2004 12:01:08 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA28109 for ; Sun, 18 Apr 2004 12:01:05 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BFEjC-000285-U7 for ips-web-archive@ietf.org; Sun, 18 Apr 2004 12:01:07 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BFEiH-0001w0-00 for ips-web-archive@ietf.org; Sun, 18 Apr 2004 12:00:10 -0400 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1BFEhw-0001jp-00 for ips-web-archive@ietf.org; Sun, 18 Apr 2004 11:59:48 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BFEbO-0000bH-5q; Sun, 18 Apr 2004 11:53:02 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BFEQz-0006dw-2S for ips@optimus.ietf.org; Sun, 18 Apr 2004 11:42:17 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA27206 for ; Sun, 18 Apr 2004 11:42:14 -0400 (EDT) From: Black_David@emc.com Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BFEQx-0005mW-U6 for ips@ietf.org; Sun, 18 Apr 2004 11:42:16 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BFEPx-0005Ys-00 for ips@ietf.org; Sun, 18 Apr 2004 11:41:13 -0400 Received: from maho3msx2.corp.emc.com ([128.221.11.32]) by ietf-mx with esmtp (Exim 4.12) id 1BFEPQ-0005L2-00 for ips@ietf.org; Sun, 18 Apr 2004 11:40:40 -0400 Received: by maho3msx2.corp.emc.com with Internet Mail Service (5.5.2653.19) id ; Sun, 18 Apr 2004 11:40:05 -0400 Message-ID: To: mbakke@cisco.com Cc: ips@ietf.org Subject: RE: [Ips] New iscsi-slp draft Date: Sun, 18 Apr 2004 11:40:04 -0400 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 Please submit a -08 with this correction and the addition of the iSNS server priority field. 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: Mark Bakke [mailto:mbakke@cisco.com] > Sent: Friday, April 16, 2004 9:38 AM > To: Black_David@emc.com > Cc: ips@ietf.org > Subject: Re: [Ips] New iscsi-slp draft > > > My bad; I must have been typing too fast. Should I issue > another draft, or > should I do this during auth48? > > Black_David@emc.com wrote: > > >> Added to auth-name, auth-addr, auth-cred, and boot-list > attributes: > >> > >> # This attribute contains security policy information. If this > >> # attribute is distributed via an Attribute Reply message, > >> # IPsec MUST be used. > >> > >> > > > >Oops, that should say "MUST be implemented", not "MUST be used". The > >IPsec requirement is "MUST implement, MAY use" when > distributing security > >policy information (for iSCSI SLP, this means distribution > of anything > >containing identity info on initiators that can access a target). > > > >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 Apr 19 10:34: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 KAA14217 for ; Mon, 19 Apr 2004 10:34:12 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BFZno-0007hU-DX for ips-archive@odin.ietf.org; Mon, 19 Apr 2004 10:31:16 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i3JEVG2o029600 for ips-archive@odin.ietf.org; Mon, 19 Apr 2004 10:31:16 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BFZe7-0005n9-5c for ips-web-archive@optimus.ietf.org; Mon, 19 Apr 2004 10:21:15 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA13668 for ; Mon, 19 Apr 2004 10:21:11 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BFZe4-0002iR-RT for ips-web-archive@ietf.org; Mon, 19 Apr 2004 10:21:12 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BFZd7-0002TV-00 for ips-web-archive@ietf.org; Mon, 19 Apr 2004 10:20:14 -0400 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1BFZcA-0002G1-00 for ips-web-archive@ietf.org; Mon, 19 Apr 2004 10:19:14 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BFZVE-0001rL-Mn; Mon, 19 Apr 2004 10:12:04 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BFZRM-00008E-PF for ips@optimus.ietf.org; Mon, 19 Apr 2004 10:08:05 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA12450 for ; Mon, 19 Apr 2004 10:08:01 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BFZRK-0007cy-Ep for ips@ietf.org; Mon, 19 Apr 2004 10:08:02 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BFZQN-0007OF-00 for ips@ietf.org; Mon, 19 Apr 2004 10:07:03 -0400 Received: from rtp-iport-1.cisco.com ([64.102.122.148]) by ietf-mx with esmtp (Exim 4.12) id 1BFZPX-0006uV-00 for ips@ietf.org; Mon, 19 Apr 2004 10:06:11 -0400 Received: from rtp-core-2.cisco.com (64.102.124.13) by rtp-iport-1.cisco.com with ESMTP; 19 Apr 2004 07:17:52 -0700 X-BrightmailFiltered: true Received: from cisco.com (mbakke-lnx2.cisco.com [64.101.211.59]) by rtp-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id i3JE5cAH025777; Mon, 19 Apr 2004 10:05:39 -0400 (EDT) Message-ID: <4083DCB2.2010203@cisco.com> Date: Mon, 19 Apr 2004 09:05:38 -0500 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: Josh Tseng CC: William Studenmund , IPS Subject: Re: [Ips] New iscsi-slp draft References: <20040417035358.26558.qmail@web21323.mail.yahoo.com> In-Reply-To: <20040417035358.26558.qmail@web21323.mail.yahoo.com> 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 Makes sense; I had seen the original email, then saw a (I think) later one that said we didn't need it. What should I call the field? How about: server-priority = integer # The priority a client should give this server, when choosing # between multiple servers with the same protocol type. # When multiple servers are discovered for a given protocol type, # the client should (must?) use the server with the highest (lowest?) # server-priority value. Is the above description adequate? Do we want "should" or "must" in the last sentence? Should it be "highest" or "lowest"? Let me know, Mark Josh Tseng wrote: >I agree with Bill. Although I lost the original >e-mail thread, I believe the comment was to include a >priority field in the SMS template, and not to rely >exclusively on the iSNS server heartbeat for failover >priority. > >Josh > > >--- William Studenmund >wrote: > > >>On Apr 15, 2004, at 11:09 AM, Mark Bakke wrote: >> >> >> >>>I've just submitted a new iscsi-slp draft, to >>> >>> >>address comments made on >> >> >>>the list >>>during the last few months. The draft is >>> >>> >>available at: >> >>[snip] >> >> >> >>>1/28/04 - Bill Studenmond - Finding iSNS using SLP >>> >>> Need to provide TCP/UDP transport information >>> >>> >>when discovering >> >> >>> an iSNS URL. >>> >>> Need to discover server priority for iSNS URLs if >>> >>> >>possible. >> >> >>>1/29/04 - Josh Tseng - (in response to Bill's >>> >>> >>email) >> >> >>> Proposed solution for TCP/UDP transport >>> >>> Non-SLP solution for server priority >>> >>> >>I'm sorry I didn't get to you yesterday about this. >> >>I've been thinking about it, and I'm not sure I like >>this idea. Just >>for everyone >>else, the idea is that we only have the active iSNS >>server advertising >>itself via SLP. In the case of failover, the backup >>server advertises >>itself >>and we wait for the original SLP advertisement to >>expire. >> >>I think the thing I dislike most about this is that >>the other location >>methods, >>DHCP and heartbeat, report all the servers. Not >>including a server >>priority >>means SLP acts differently. >> >>Additionally, it means that iSNS servers have to put >>lifetimes on their >>SLP >>registrations. And the registrations have to have a >>lifetime that does >>not >>severely impact failover (if the idea is that only >>active hosts are >>advertised). >> >>Since the iSNS clients have to worry about failover >>anyway, I think >>it'd be >>better to include the priority. Then SLP discovery >>would work the same >>as >>heartbeat and DHCP. >> >>Take care, >> >>Bill >> >> >> > > > >>ATTACHMENT part 2 application/pgp-signature >> >> >x-mac-type=70674453; name=PGP.sig > > > > > > >__________________________________ >Do you Yahoo!? >Yahoo! Tax Center - File online by April 15th >http://taxes.yahoo.com/filing.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 Apr 19 13:05: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 NAA23894 for ; Mon, 19 Apr 2004 13:05:17 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BFcA3-0000E2-Is for ips-archive@odin.ietf.org; Mon, 19 Apr 2004 13:02:24 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i3JH2Npb000860 for ips-archive@odin.ietf.org; Mon, 19 Apr 2004 13:02:23 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BFc1I-0006qh-Mr for ips-web-archive@optimus.ietf.org; Mon, 19 Apr 2004 12:53:20 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA23229 for ; Mon, 19 Apr 2004 12:53:17 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BFc1H-0000FZ-2V for ips-web-archive@ietf.org; Mon, 19 Apr 2004 12:53:19 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BFc0R-00001P-00 for ips-web-archive@ietf.org; Mon, 19 Apr 2004 12:52:28 -0400 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1BFbzw-0007a2-00 for ips-web-archive@ietf.org; Mon, 19 Apr 2004 12:51:56 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BFbsK-0004NM-HQ; Mon, 19 Apr 2004 12:44:04 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BFbik-0001h9-7K for ips@optimus.ietf.org; Mon, 19 Apr 2004 12:34:10 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA22171 for ; Mon, 19 Apr 2004 12:34:06 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BFbii-0003Zu-L1 for ips@ietf.org; Mon, 19 Apr 2004 12:34:08 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BFbhr-0003JT-00 for ips@ietf.org; Mon, 19 Apr 2004 12:33:16 -0400 Received: from mononoke.wasabisystems.com ([151.199.66.145]) by ietf-mx with esmtp (Exim 4.12) id 1BFbgq-0002qR-00 for ips@ietf.org; Mon, 19 Apr 2004 12:32:12 -0400 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 F0F5E40134; Mon, 19 Apr 2004 12:32:04 -0400 (EDT) In-Reply-To: <4083DCB2.2010203@cisco.com> References: <20040417035358.26558.qmail@web21323.mail.yahoo.com> <4083DCB2.2010203@cisco.com> Mime-Version: 1.0 (Apple Message framework v613) Content-Type: multipart/signed; protocol="application/pgp-signature"; micalg=pgp-sha1; boundary="Apple-Mail-1-1005903164" Message-Id: <13DAC1DE-921F-11D8-BB10-000A95D14BEC@wasabisystems.com> Content-Transfer-Encoding: 7bit Cc: IPS , Josh Tseng From: William Studenmund Subject: Re: [Ips] New iscsi-slp draft Date: Mon, 19 Apr 2004 09:31:58 -0700 To: Mark Bakke 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-1-1005903164 Content-Type: text/plain; charset=US-ASCII; format=flowed Content-Transfer-Encoding: 7bit On Apr 19, 2004, at 7:05 AM, Mark Bakke wrote: > Makes sense; I had seen the original email, then saw a (I think) later > one > that said we didn't need it. > > What should I call the field? How about: > > server-priority = integer > # The priority a client should give this server, when choosing > # between multiple servers with the same protocol type. > # When multiple servers are discovered for a given protocol type, > # the client should (must?) use the server with the highest (lowest?) > # server-priority value. > > Is the above description adequate? Do we want "should" or "must" > in the last sentence? Should it be "highest" or "lowest"? How about: # The priority a client should give this server, when choosing # between multiple servers with the same protocol type. # When multiple servers are discovered for a given protocol type, # this parameter indicates their relative precedence. Server # precedence is protocol-specific; for some protocols, the primary # server may have the highest server-priority value, while for # others it may have the lowest. For example, with iSNS, the primary # server has the lowest value (value 0). I'm trying to get at: 1) different protocols may have different server priority values already, and this field should map to that. 2) Exactly what a client does with multiple servers is protocol-specific (we should leave it alone in this spec). 3) We need to say somewhere what iSNS does. As this document serves as the SLP definition for iSNS, I figured this is the best place to mention it. I expect that any sms protocol other than iSNS will have a separate, follow-on document that indicates what its protocol is, its transports, and how to use this field. Take care, Bill --Apple-Mail-1-1005903164 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) iD8DBQFAg/8DDJT2Egh26K0RAtRSAJ4lyS/dBS2lf+tJf/e1VkmFt1CloACdEOwL AeZYGetcRDGnn36XsqrzUqs= =t8oJ -----END PGP SIGNATURE----- --Apple-Mail-1-1005903164-- _______________________________________________ Ips mailing list Ips@ietf.org https://www1.ietf.org/mailman/listinfo/ips From exim@www1.ietf.org Mon Apr 19 13:10: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 NAA24185 for ; Mon, 19 Apr 2004 13:10:53 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BFcD9-00011d-RC for ips-archive@odin.ietf.org; Mon, 19 Apr 2004 13:05:35 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i3JH5Z8k003937 for ips-archive@odin.ietf.org; Mon, 19 Apr 2004 13:05:35 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BFcAq-0000Sg-FW for ips-web-archive@optimus.ietf.org; Mon, 19 Apr 2004 13:03:12 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA23798 for ; Mon, 19 Apr 2004 13:03:08 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BFcAo-0002aS-OG for ips-web-archive@ietf.org; Mon, 19 Apr 2004 13:03:10 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BFcA0-0002Na-00 for ips-web-archive@ietf.org; Mon, 19 Apr 2004 13:02:21 -0400 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1BFc9Q-0002A9-00 for ips-web-archive@ietf.org; Mon, 19 Apr 2004 13:01:44 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BFc11-0006pa-Di; Mon, 19 Apr 2004 12:53:03 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BFbvH-0004wG-MG for ips@optimus.ietf.org; Mon, 19 Apr 2004 12:47:07 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA22880 for ; Mon, 19 Apr 2004 12:47:04 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BFbvF-0006dJ-Rz for ips@ietf.org; Mon, 19 Apr 2004 12:47:05 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BFbuH-0006PE-00 for ips@ietf.org; Mon, 19 Apr 2004 12:46:06 -0400 Received: from rtp-iport-2.cisco.com ([64.102.122.149]) by ietf-mx with esmtp (Exim 4.12) id 1BFbtC-0005zI-00 for ips@ietf.org; Mon, 19 Apr 2004 12:44:58 -0400 Received: from rtp-core-2.cisco.com (64.102.124.13) by rtp-iport-2.cisco.com with ESMTP; 19 Apr 2004 09:43:51 -0700 X-BrightmailFiltered: true Received: from cisco.com (mbakke-lnx2.cisco.com [64.101.211.59]) by rtp-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id i3JGiPAH026727; Mon, 19 Apr 2004 12:44:25 -0400 (EDT) Message-ID: <408401E9.2020707@cisco.com> Date: Mon, 19 Apr 2004 11:44:25 -0500 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: William Studenmund CC: IPS , Josh Tseng Subject: Re: [Ips] New iscsi-slp draft References: <20040417035358.26558.qmail@web21323.mail.yahoo.com> <4083DCB2.2010203@cisco.com> <13DAC1DE-921F-11D8-BB10-000A95D14BEC@wasabisystems.com> In-Reply-To: <13DAC1DE-921F-11D8-BB10-000A95D14BEC@wasabisystems.com> 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 OK; I like that better. I'll send an 08 (with this plus David's implement vs used changes) later today. -- Mark William Studenmund wrote: > On Apr 19, 2004, at 7:05 AM, Mark Bakke wrote: > >> Makes sense; I had seen the original email, then saw a (I think) >> later one >> that said we didn't need it. >> >> What should I call the field? How about: >> >> server-priority = integer >> # The priority a client should give this server, when choosing >> # between multiple servers with the same protocol type. >> # When multiple servers are discovered for a given protocol type, >> # the client should (must?) use the server with the highest (lowest?) >> # server-priority value. >> >> Is the above description adequate? Do we want "should" or "must" >> in the last sentence? Should it be "highest" or "lowest"? > > > How about: > > # The priority a client should give this server, when choosing > # between multiple servers with the same protocol type. > # When multiple servers are discovered for a given protocol type, > # this parameter indicates their relative precedence. Server > # precedence is protocol-specific; for some protocols, the primary > # server may have the highest server-priority value, while for > # others it may have the lowest. For example, with iSNS, the primary > # server has the lowest value (value 0). > > I'm trying to get at: 1) different protocols may have different server > priority values already, and this field should map to that. 2) Exactly > what a client does with multiple servers is protocol-specific (we > should leave it alone in this spec). 3) We need to say somewhere > what iSNS does. As this document serves as the SLP definition for > iSNS, I figured this is the best place to mention it. > > I expect that any sms protocol other than iSNS will have a separate, > follow-on document that indicates what its protocol is, its transports, > and how to use this field. > > Take care, > > Bill _______________________________________________ Ips mailing list Ips@ietf.org https://www1.ietf.org/mailman/listinfo/ips From exim@www1.ietf.org Mon Apr 19 22:39: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 WAA29827 for ; Mon, 19 Apr 2004 22:39:20 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BFl7I-0000jn-Sh for ips-archive@odin.ietf.org; Mon, 19 Apr 2004 22:36:08 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i3K2a80n002831 for ips-archive@odin.ietf.org; Mon, 19 Apr 2004 22:36:08 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BFl6i-0000RG-Mt for ips-web-archive@optimus.ietf.org; Mon, 19 Apr 2004 22:35:32 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA29758 for ; Mon, 19 Apr 2004 22:35:29 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BFl6f-0005Yd-CE for ips-web-archive@ietf.org; Mon, 19 Apr 2004 22:35:29 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BFl5h-0005LI-00 for ips-web-archive@ietf.org; Mon, 19 Apr 2004 22:34:29 -0400 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1BFl5A-00058B-00 for ips-web-archive@ietf.org; Mon, 19 Apr 2004 22:33:56 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BFkzS-0007Ce-CG; Mon, 19 Apr 2004 22:28:02 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BFVXR-00052S-IX for ips@optimus.ietf.org; Mon, 19 Apr 2004 05:58:05 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA00162 for ; Mon, 19 Apr 2004 05:58:02 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BFVXN-0005yz-RC for ips@ietf.org; Mon, 19 Apr 2004 05:58:01 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BFVW9-0005lg-00 for ips@ietf.org; Mon, 19 Apr 2004 05:56:45 -0400 Received: from ind-iport-1-sec.cisco.com ([64.104.129.9] helo=ind-iport-1.cisco.com) by ietf-mx with esmtp (Exim 4.12) id 1BFVV9-0005Np-00 for ips@ietf.org; Mon, 19 Apr 2004 05:55:43 -0400 Received: from india-core-1.cisco.com (64.104.129.221) by ind-iport-1.cisco.com with ESMTP; 19 Apr 2004 21:04:35 +0530 X-BrightmailFiltered: true Received: from naveenb-lnx.cisco.com (naveenb-lnx.cisco.com [10.77.7.56]) by india-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id i3J9slq0001988 for ; Mon, 19 Apr 2004 02:54:47 -0700 (PDT) Received: from localhost (localhost [[UNIX: localhost]]) by naveenb-lnx.cisco.com (8.11.6/8.11.6) id i3J9t3v05481 for ips@ietf.org; Mon, 19 Apr 2004 15:25:03 +0530 From: Naveen Burmi Reply-To: naveenb@cisco.com To: ips@ietf.org Date: Mon, 19 Apr 2004 15:25:02 +0530 User-Agent: KMail/1.5.4 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200404191525.02909.naveenb@cisco.com> Content-Transfer-Encoding: 7bit Subject: [Ips] Behaviour of iSCSI Initiator, if target is not returning "Target Portal Group Tag". 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 Need some clarification regarding Target portal Group Tag. Draft says that "iSCSI target MUST return the TargetPortalGroupTag key with the first login response PDU for all session types". But it does not, explicitly, talks about the action that needs to be taken by initiator if target does not return this value. Draft section 6.11 "Protocol Errors" says that "All violations of iSCSI PDU exchange sequences specified in this draft are also protocol errors." Do we need to consider it as "protocol error"? Thanks, Naveen. _______________________________________________ Ips mailing list Ips@ietf.org https://www1.ietf.org/mailman/listinfo/ips From exim@www1.ietf.org Tue Apr 20 02:28:34 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 CAA25580 for ; Tue, 20 Apr 2004 02:28:34 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BFojN-0004US-Ei for ips-archive@odin.ietf.org; Tue, 20 Apr 2004 02:27:41 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i3K6Rf3e017260 for ips-archive@odin.ietf.org; Tue, 20 Apr 2004 02:27:41 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BFohY-0003xP-Ka for ips-web-archive@optimus.ietf.org; Tue, 20 Apr 2004 02:25:48 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA25449 for ; Tue, 20 Apr 2004 02:25:46 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BFohV-00023z-2Q for ips-web-archive@ietf.org; Tue, 20 Apr 2004 02:25:45 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BFogd-0001oF-00 for ips-web-archive@ietf.org; Tue, 20 Apr 2004 02:24:51 -0400 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1BFofx-0001Yt-00 for ips-web-archive@ietf.org; Tue, 20 Apr 2004 02:24:09 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BFoa1-0000mH-GR; Tue, 20 Apr 2004 02:18:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BFoN9-0001Me-DD for ips@optimus.ietf.org; Tue, 20 Apr 2004 02:04:43 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA16081 for ; Tue, 20 Apr 2004 02:04:41 -0400 (EDT) From: pamanick@npd.hcltech.com Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BFoN5-0004aM-R6 for ips@ietf.org; Tue, 20 Apr 2004 02:04:39 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BFoMC-0004ML-00 for ips@ietf.org; Tue, 20 Apr 2004 02:03:45 -0400 Received: from [202.54.64.17] (helo=hclnpd.hcltech.com) by ietf-mx with esmtp (Exim 4.12) id 1BFoLj-00046u-00 for ips@ietf.org; Tue, 20 Apr 2004 02:03:16 -0400 Received: from pilex.hclt-ntl.co.in ([192.168.19.34]) by hclnpd.hcltech.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) id HT65795B; Tue, 20 Apr 2004 11:32:48 +0530 Received: by PILEX with Internet Mail Service (5.5.2653.19) id <28G616LK>; Tue, 20 Apr 2004 11:35:15 +0530 Message-ID: <50D40047DC73D611BDA60050BAC4EDD9010C95FB@PILEX> To: naveenb@cisco.com, ips@ietf.org Subject: RE: [Ips] Behaviour of iSCSI Initiator, if target is not returnin g "Target Portal Group Tag". Date: Tue, 20 Apr 2004 11:35:12 +0530 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=NO_REAL_NAME autolearn=no version=2.60 Yes, the initiator should close the connection. thanks Parthi -----Original Message----- From: Naveen Burmi [mailto:naveenb@cisco.com] Sent: Monday, April 19, 2004 3:25 PM To: ips@ietf.org Subject: [Ips] Behaviour of iSCSI Initiator, if target is not returning "Target Portal Group Tag". Need some clarification regarding Target portal Group Tag. Draft says that "iSCSI target MUST return the TargetPortalGroupTag key with the first login response PDU for all session types". But it does not, explicitly, talks about the action that needs to be taken by initiator if target does not return this value. Draft section 6.11 "Protocol Errors" says that "All violations of iSCSI PDU exchange sequences specified in this draft are also protocol errors." Do we need to consider it as "protocol error"? Thanks, Naveen. _______________________________________________ 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 Apr 20 08:27:31 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 IAA13156 for ; Tue, 20 Apr 2004 08:27:31 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BFuIG-0002n8-8k for ips-archive@odin.ietf.org; Tue, 20 Apr 2004 08:24:04 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i3KCO4ip010730 for ips-archive@odin.ietf.org; Tue, 20 Apr 2004 08:24:04 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BFuEN-0001b1-2m for ips-web-archive@optimus.ietf.org; Tue, 20 Apr 2004 08:20:03 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA12960 for ; Tue, 20 Apr 2004 08:20:01 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BFuEM-0003Rl-16 for ips-web-archive@ietf.org; Tue, 20 Apr 2004 08:20:02 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BFuDU-0003BA-00 for ips-web-archive@ietf.org; Tue, 20 Apr 2004 08:19:09 -0400 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1BFuCY-0002tZ-00 for ips-web-archive@ietf.org; Tue, 20 Apr 2004 08:18:10 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BFu8Y-0008BY-Q0; Tue, 20 Apr 2004 08:14:02 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BFu6d-0007Ss-MF for ips@optimus.ietf.org; Tue, 20 Apr 2004 08:12:03 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA12399 for ; Tue, 20 Apr 2004 08:12:02 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BFu6c-0000wt-Gs for ips@ietf.org; Tue, 20 Apr 2004 08:12:02 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BFu5h-0000ee-00 for ips@ietf.org; Tue, 20 Apr 2004 08:11:05 -0400 Received: from rwcrmhc11.comcast.net ([204.127.198.35]) by ietf-mx with esmtp (Exim 4.12) id 1BFu4m-00007n-00 for ips@ietf.org; Tue, 20 Apr 2004 08:10:08 -0400 Received: from ivvt2dxrc11 (c-66-177-57-55.se.client2.attbi.com[66.177.57.55]) by comcast.net (rwcrmhc11) with SMTP id <2004042012093701300fckmie> (Authid: esquicksall); Tue, 20 Apr 2004 12:09:37 +0000 Message-ID: <000a01c426d0$59f4e050$0303a8c0@ivvt2dxrc11> From: "Eddy Quicksall" To: , , References: <50D40047DC73D611BDA60050BAC4EDD9010C95FB@PILEX> Subject: Re: [Ips] Behaviour of iSCSI Initiator, if target is not returning "Target Portal Group Tag". Date: Tue, 20 Apr 2004 08:09:36 -0400 MIME-Version: 1.0 Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1409 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1409 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.1 required=5.0 tests=AWL autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Additionally, you may be behind in your draft ... draft 20+errata has a correction to this since the TargetPortalGroupTag does not make sense in some cases: "The TargetPortalGroupTag key must also be returned by the target as a confirmation during connection establishment when TargetName is given." "... iSCSI target MUST return the TargetPortalGroupTag ... for all session types when TargetName is given and the response is not a redirection." Eddy ----- Original Message ----- From: To: ; Sent: Tuesday, April 20, 2004 2:05 AM Subject: RE: [Ips] Behaviour of iSCSI Initiator, if target is not returning "Target Portal Group Tag". > Yes, the initiator should close the connection. > > thanks > Parthi > > -----Original Message----- > From: Naveen Burmi [mailto:naveenb@cisco.com] > Sent: Monday, April 19, 2004 3:25 PM > To: ips@ietf.org > Subject: [Ips] Behaviour of iSCSI Initiator, if target is not returning > "Target Portal Group Tag". > > > > Need some clarification regarding Target portal Group Tag. > > Draft says that "iSCSI target MUST return the > TargetPortalGroupTag key with the first login response PDU > for all session types". But it does not, explicitly, talks > about the action that needs to be taken by initiator if > target does not return this value. > > Draft section 6.11 "Protocol Errors" says that "All violations of iSCSI PDU > exchange sequences specified in this draft are also protocol errors." > > Do we need to consider it as "protocol error"? > > Thanks, > Naveen. > > _______________________________________________ > 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 _______________________________________________ Ips mailing list Ips@ietf.org https://www1.ietf.org/mailman/listinfo/ips From exim@www1.ietf.org Tue Apr 20 14:46: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 OAA11849 for ; Tue, 20 Apr 2004 14:46:09 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BG07m-0007ZJ-KL for ips-archive@odin.ietf.org; Tue, 20 Apr 2004 14:37:38 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i3KIbcPX029084 for ips-archive@odin.ietf.org; Tue, 20 Apr 2004 14:37:38 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BFzyf-0004Qq-9S for ips-web-archive@optimus.ietf.org; Tue, 20 Apr 2004 14:28:13 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA10355 for ; Tue, 20 Apr 2004 14:28:10 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BFzyc-000675-O9 for ips-web-archive@ietf.org; Tue, 20 Apr 2004 14:28:10 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BFzxe-00065J-00 for ips-web-archive@ietf.org; Tue, 20 Apr 2004 14:27:11 -0400 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1BFzxP-00063N-00 for ips-web-archive@ietf.org; Tue, 20 Apr 2004 14:26:55 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BFzri-0001Xs-Bg; Tue, 20 Apr 2004 14:21:02 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BFzeH-0003of-BZ for ips@optimus.ietf.org; Tue, 20 Apr 2004 14:07:09 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA09038 for ; Tue, 20 Apr 2004 14:07:06 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BFzeE-0004fW-So for ips@ietf.org; Tue, 20 Apr 2004 14:07:06 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BFzdL-0004dY-00 for ips@ietf.org; Tue, 20 Apr 2004 14:06:12 -0400 Received: from mail.maranti.com ([12.7.173.35] helo=msg001.maranti.com) by ietf-mx with esmtp (Exim 4.12) id 1BFzcp-0004bm-00 for ips@ietf.org; Tue, 20 Apr 2004 14:05:39 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.0.6249.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Date: Tue, 20 Apr 2004 11:02:19 -0700 Message-ID: Thread-Topic: Encryption and ISCSI PDUs. Thread-Index: AcQnAgeOt45kCwdJQbSUc4Jq0Uck9w== From: "Preetam Verma" To: Content-Transfer-Encoding: quoted-printable Subject: [Ips] Encryption and ISCSI PDUs. 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 Do I need to use on of the reserved bits to compress ISCSI PDUs using = some compression algorithm? I quickly went through the draft but could = not find any specific bit that you can use for something like this.=20 Regards Preetam _______________________________________________ Ips mailing list Ips@ietf.org https://www1.ietf.org/mailman/listinfo/ips From exim@www1.ietf.org Tue Apr 20 15:08:54 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 PAA14193 for ; Tue, 20 Apr 2004 15:08:54 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BG0Te-00080a-HM for ips-archive@odin.ietf.org; Tue, 20 Apr 2004 15:00:14 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i3KJ0E0g030769 for ips-archive@odin.ietf.org; Tue, 20 Apr 2004 15:00:14 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BG0Mw-0005Jn-Ct for ips-web-archive@optimus.ietf.org; Tue, 20 Apr 2004 14:53:18 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA12417 for ; Tue, 20 Apr 2004 14:53:15 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BG0Mt-0000KJ-Gg for ips-web-archive@ietf.org; Tue, 20 Apr 2004 14:53:15 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BG0M6-0000Eg-00 for ips-web-archive@ietf.org; Tue, 20 Apr 2004 14:52:26 -0400 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1BG0L9-00007u-00 for ips-web-archive@ietf.org; Tue, 20 Apr 2004 14:51:27 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BG099-0008Lr-HS; Tue, 20 Apr 2004 14:39:03 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BG01c-0005W0-W3 for ips@optimus.ietf.org; Tue, 20 Apr 2004 14:31:17 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA10497 for ; Tue, 20 Apr 2004 14:31:14 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BG01a-0006JQ-CM for ips@ietf.org; Tue, 20 Apr 2004 14:31:14 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BG00j-0006Fr-00 for ips@ietf.org; Tue, 20 Apr 2004 14:30:21 -0400 Received: from mail.maranti.com ([12.7.173.35] helo=msg001.maranti.com) by ietf-mx with esmtp (Exim 4.12) id 1BFzzv-0006CT-00 for ips@ietf.org; Tue, 20 Apr 2004 14:29:31 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.0.6249.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: RE: [Ips] Encryption and ISCSI PDUs. Date: Tue, 20 Apr 2004 11:26:25 -0700 Message-ID: Thread-Topic: Encryption and ISCSI PDUs. Thread-Index: AcQnAgeOt45kCwdJQbSUc4Jq0Uck9wAA0QDQ From: "Preetam Verma" To: "Preetam Verma" , 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 I meant compression......not encryption. Preetam -----Original Message----- From: Preetam Verma=20 Sent: Tuesday, April 20, 2004 11:02 AM To: ips@ietf.org Subject: [Ips] Encryption and ISCSI PDUs. Do I need to use on of the reserved bits to compress ISCSI PDUs using = some compression algorithm? I quickly went through the draft but could = not find any specific bit that you can use for something like this.=20 Regards Preetam _______________________________________________ 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 Apr 20 15:29: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 PAA16167 for ; Tue, 20 Apr 2004 15:29:08 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BG0hm-0005D4-Tg for ips-archive@odin.ietf.org; Tue, 20 Apr 2004 15:14:51 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i3KJEoa0020022 for ips-archive@odin.ietf.org; Tue, 20 Apr 2004 15:14:50 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BG0Tl-0008Nz-8m for ips-web-archive@optimus.ietf.org; Tue, 20 Apr 2004 15:00:21 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA12931 for ; Tue, 20 Apr 2004 15:00:18 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BG0Ti-0000qc-8G for ips-web-archive@ietf.org; Tue, 20 Apr 2004 15:00:18 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BG0Sq-0000lw-00 for ips-web-archive@ietf.org; Tue, 20 Apr 2004 14:59:24 -0400 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1BG0Rx-0000gE-00 for ips-web-archive@ietf.org; Tue, 20 Apr 2004 14:58:29 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BG09H-0008PJ-0S; Tue, 20 Apr 2004 14:39:11 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BG05k-00062q-FW for ips@optimus.ietf.org; Tue, 20 Apr 2004 14:35:35 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA10902 for ; Tue, 20 Apr 2004 14:35:29 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BG05h-0006aQ-M1 for ips@ietf.org; Tue, 20 Apr 2004 14:35:29 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BG04f-0006WQ-00 for ips@ietf.org; Tue, 20 Apr 2004 14:34:26 -0400 Received: from sadr.equallogic.com ([66.155.203.134]) by ietf-mx with smtp (Exim 4.12) id 1BG042-0006Qp-00 for ips@ietf.org; Tue, 20 Apr 2004 14:33:46 -0400 Received: from sadr.equallogic.com (localhost.localdomain [127.0.0.1]) by sadr.equallogic.com (8.12.8/8.12.8) with ESMTP id i3KIXCVL012810 for ; Tue, 20 Apr 2004 14:33:12 -0400 Received: from M30.equallogic.com (m30 [172.16.1.30]) by sadr.equallogic.com (8.12.8/8.12.8) with SMTP id i3KIXBru012805; Tue, 20 Apr 2004 14:33:11 -0400 Received: from PKONING.equallogic.com ([172.16.1.120]) by M30.equallogic.com with Microsoft SMTPSVC(5.0.2195.6713); Tue, 20 Apr 2004 14:33:14 -0400 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <16517.27881.349000.112823@gargle.gargle.HOWL> Date: Tue, 20 Apr 2004 14:33:13 -0400 From: Paul Koning To: pverma@marantinetworks.com Cc: ips@ietf.org Subject: Re: [Ips] Encryption and ISCSI PDUs. References: X-Mailer: VM 7.07 under 21.4 (patch 10) "Military Intelligence (Windows)" XEmacs Lucid X-OriginalArrivalTime: 20 Apr 2004 18:33:14.0474 (UTC) FILETIME=[F0FE64A0:01C42705] 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 >>>>> "Preetam" == Preetam Verma writes: Preetam> Do I need to use on of the reserved bits to compress ISCSI Preetam> PDUs using some compression algorithm? I quickly went Preetam> through the draft but could not find any specific bit that Preetam> you can use for something like this. Did you mean compression, or encryption? For compression there is IPcomp, which is loosely tied to encryption. Loosely, because you can negotiate it with IKE when you negotiate IPsec. paul _______________________________________________ Ips mailing list Ips@ietf.org https://www1.ietf.org/mailman/listinfo/ips From exim@www1.ietf.org Tue Apr 20 15:36:37 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 PAA16788 for ; Tue, 20 Apr 2004 15:36:37 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BG0v3-0004JH-Mf for ips-archive@odin.ietf.org; Tue, 20 Apr 2004 15:28:33 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i3KJSXTK016561 for ips-archive@odin.ietf.org; Tue, 20 Apr 2004 15:28:33 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BG0gD-0004Yj-3m for ips-web-archive@optimus.ietf.org; Tue, 20 Apr 2004 15:13:13 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA14670 for ; Tue, 20 Apr 2004 15:13:11 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BG0gB-0001sf-OW for ips-web-archive@ietf.org; Tue, 20 Apr 2004 15:13:11 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BG0fH-0001q5-00 for ips-web-archive@ietf.org; Tue, 20 Apr 2004 15:12:16 -0400 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1BG0eT-0001nT-00 for ips-web-archive@ietf.org; Tue, 20 Apr 2004 15:11:25 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BG0Tg-00083G-8i; Tue, 20 Apr 2004 15:00:16 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BG0DC-0001Wo-BO for ips@optimus.ietf.org; Tue, 20 Apr 2004 14:43:14 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA11716 for ; Tue, 20 Apr 2004 14:43:11 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BG0D9-0007Hj-Gb for ips@ietf.org; Tue, 20 Apr 2004 14:43:11 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BG0CE-0007FF-00 for ips@ietf.org; Tue, 20 Apr 2004 14:42:15 -0400 Received: from mail.maranti.com ([12.7.173.35] helo=msg001.maranti.com) by ietf-mx with esmtp (Exim 4.12) id 1BG0Bm-0007Cl-00 for ips@ietf.org; Tue, 20 Apr 2004 14:41:46 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.0.6249.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: RE: [Ips] Encryption and ISCSI PDUs. Date: Tue, 20 Apr 2004 11:38:40 -0700 Message-ID: Thread-Topic: [Ips] Encryption and ISCSI PDUs. Thread-Index: AcQnBZsfzfksJJ9lTiO81byMutDIHwAAQO7Q From: "Preetam Verma" To: "Paul Koning" 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=none autolearn=no version=2.60 Content-Transfer-Encoding: quoted-printable Content-Transfer-Encoding: quoted-printable Paul In a case in which you have a TOE(TCP Offload Engine) that takes iSCSI = PDUs only, and you have no way of doing things at the TCP level, how = would you go for compression? Regards Preetam=20 -----Original Message----- From: Paul Koning [mailto:pkoning@equallogic.com] Sent: Tuesday, April 20, 2004 11:33 AM To: Preetam Verma Cc: ips@ietf.org Subject: Re: [Ips] Encryption and ISCSI PDUs. >>>>> "Preetam" =3D=3D Preetam Verma = writes: Preetam> Do I need to use on of the reserved bits to compress ISCSI Preetam> PDUs using some compression algorithm? I quickly went Preetam> through the draft but could not find any specific bit that Preetam> you can use for something like this.=20 Did you mean compression, or encryption? For compression there is IPcomp, which is loosely tied to encryption. Loosely, because you can negotiate it with IKE when you negotiate IPsec. =20 paul _______________________________________________ Ips mailing list Ips@ietf.org https://www1.ietf.org/mailman/listinfo/ips From exim@www1.ietf.org Tue Apr 20 15:49: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 PAA17709 for ; Tue, 20 Apr 2004 15:49:41 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BG0zy-00070y-BE for ips-archive@odin.ietf.org; Tue, 20 Apr 2004 15:33:38 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i3KJXcpC026960 for ips-archive@odin.ietf.org; Tue, 20 Apr 2004 15:33:38 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BG0ti-0003X6-3K for ips-web-archive@optimus.ietf.org; Tue, 20 Apr 2004 15:27:10 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA16035 for ; Tue, 20 Apr 2004 15:27:08 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BG0tg-00030z-R1 for ips-web-archive@ietf.org; Tue, 20 Apr 2004 15:27:08 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BG0sl-0002xb-00 for ips-web-archive@ietf.org; Tue, 20 Apr 2004 15:26:11 -0400 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1BG0rx-0002vK-00 for ips-web-archive@ietf.org; Tue, 20 Apr 2004 15:25:21 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BG0Tt-0000Ws-Sx; Tue, 20 Apr 2004 15:00:29 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BG0I0-0003GD-9t for ips@optimus.ietf.org; Tue, 20 Apr 2004 14:48:12 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA12023 for ; Tue, 20 Apr 2004 14:48:09 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BG0Hx-0007ax-BN for ips@ietf.org; Tue, 20 Apr 2004 14:48:09 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BG0H1-0007Wl-00 for ips@ietf.org; Tue, 20 Apr 2004 14:47:12 -0400 Received: from sadr.equallogic.com ([66.155.203.134]) by ietf-mx with smtp (Exim 4.12) id 1BG0GB-0007PV-00 for ips@ietf.org; Tue, 20 Apr 2004 14:46:20 -0400 Received: from sadr.equallogic.com (localhost.localdomain [127.0.0.1]) by sadr.equallogic.com (8.12.8/8.12.8) with ESMTP id i3KIjoVL013132 for ; Tue, 20 Apr 2004 14:45:50 -0400 Received: from M30.equallogic.com (m30 [172.16.1.30]) by sadr.equallogic.com (8.12.8/8.12.8) with SMTP id i3KIjoru013127; Tue, 20 Apr 2004 14:45:50 -0400 Received: from PKONING.equallogic.com ([172.16.1.120]) by M30.equallogic.com with Microsoft SMTPSVC(5.0.2195.6713); Tue, 20 Apr 2004 14:45:52 -0400 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <16517.28638.564000.609330@gargle.gargle.HOWL> Date: Tue, 20 Apr 2004 14:45:50 -0400 From: Paul Koning To: pverma@marantinetworks.com Cc: ips@ietf.org Subject: RE: [Ips] Encryption and ISCSI PDUs. References: X-Mailer: VM 7.07 under 21.4 (patch 10) "Military Intelligence (Windows)" XEmacs Lucid X-OriginalArrivalTime: 20 Apr 2004 18:45:52.0796 (UTC) FILETIME=[B4FD25C0:01C42707] 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 >>>>> "Preetam" == Preetam Verma writes: Preetam> Paul In a case in which you have a TOE(TCP Offload Engine) Preetam> that takes iSCSI PDUs only, and you have no way of doing Preetam> things at the TCP level, how would you go for compression? I would put an IPsec gateway that includes IPcomp support in front. That's the logical setup anyway. Compression is useful for slow WAN links, but not on gigabit or better Ethernet. WAN edge IPsec boxes have implemented IPcomp for years. paul _______________________________________________ Ips mailing list Ips@ietf.org https://www1.ietf.org/mailman/listinfo/ips From exim@www1.ietf.org Tue Apr 20 15:54: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 PAA18532 for ; Tue, 20 Apr 2004 15:54:50 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BG1FM-0004gf-O1 for ips-archive@odin.ietf.org; Tue, 20 Apr 2004 15:49:32 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i3KJnWmU018009 for ips-archive@odin.ietf.org; Tue, 20 Apr 2004 15:49:32 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BG17L-0000sx-F7 for ips-web-archive@optimus.ietf.org; Tue, 20 Apr 2004 15:41:15 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA17051 for ; Tue, 20 Apr 2004 15:41:13 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BG17K-000487-3T for ips-web-archive@ietf.org; Tue, 20 Apr 2004 15:41:14 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BG16Q-00045A-00 for ips-web-archive@ietf.org; Tue, 20 Apr 2004 15:40:19 -0400 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1BG15n-00042A-00 for ips-web-archive@ietf.org; Tue, 20 Apr 2004 15:39:39 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BG0vh-0004dO-4V; Tue, 20 Apr 2004 15:29:13 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BG0iE-0005tr-DC for ips@optimus.ietf.org; Tue, 20 Apr 2004 15:15:18 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA14884 for ; Tue, 20 Apr 2004 15:15:16 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BG0iD-00021Q-4g for ips@ietf.org; Tue, 20 Apr 2004 15:15:17 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BG0hH-0001xT-00 for ips@ietf.org; Tue, 20 Apr 2004 15:14:19 -0400 Received: from mail.maranti.com ([12.7.173.35] helo=msg001.maranti.com) by ietf-mx with esmtp (Exim 4.12) id 1BG0gg-0001uJ-00 for ips@ietf.org; Tue, 20 Apr 2004 15:13:42 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.0.6249.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Date: Tue, 20 Apr 2004 12:10:19 -0700 Message-ID: Thread-Topic: Compression and iSCSI PDUs. Thread-Index: AcQnC4dJ+nidHHE6RX2KywQCVnOA8g== From: "Preetam Verma" To: Content-Transfer-Encoding: quoted-printable Subject: [Ips] Compression and iSCSI PDUs. 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 Using an IPSec gateway kind of a thing would be a cumbersome solution = for me(too many chips). If I use one of the reserved bits, I don't have = a stable solution either if that bit were to change in the future. What = would be the best way out in this case? Preetam _______________________________________________ Ips mailing list Ips@ietf.org https://www1.ietf.org/mailman/listinfo/ips From exim@www1.ietf.org Tue Apr 20 17:50: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 RAA28846 for ; Tue, 20 Apr 2004 17:50:46 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BG2or-0000er-KQ for ips-archive@odin.ietf.org; Tue, 20 Apr 2004 17:30:17 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i3KLUHWG002525 for ips-archive@odin.ietf.org; Tue, 20 Apr 2004 17:30:17 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BG1Uy-0002rV-42 for ips-web-archive@optimus.ietf.org; Tue, 20 Apr 2004 16:05:40 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA19202 for ; Tue, 20 Apr 2004 16:05:37 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BG1Uw-0006J5-Bs for ips-web-archive@ietf.org; Tue, 20 Apr 2004 16:05:38 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BG1UE-0006CO-00 for ips-web-archive@ietf.org; Tue, 20 Apr 2004 16:04:55 -0400 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1BG1T7-00065D-00 for ips-web-archive@ietf.org; Tue, 20 Apr 2004 16:03:45 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BG1Hl-0006Bh-RL; Tue, 20 Apr 2004 15:52:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BG1CI-0003S4-Mn for ips@optimus.ietf.org; Tue, 20 Apr 2004 15:46:22 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA17382 for ; Tue, 20 Apr 2004 15:46:20 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BG1CH-0004Xj-75 for ips@ietf.org; Tue, 20 Apr 2004 15:46:21 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BG1BR-0004Sy-00 for ips@ietf.org; Tue, 20 Apr 2004 15:45:29 -0400 Received: from email.crossroads.com ([65.68.235.6]) by ietf-mx with smtp (Exim 4.12) id 1BG1AZ-0004Ip-00 for ips@ietf.org; Tue, 20 Apr 2004 15:44:35 -0400 Received: from mailnode1.COMMSTOR.Crossroads.com ([192.168.1.249]) by email.crossroads.com with Microsoft SMTPSVC(5.0.2195.6713); Tue, 20 Apr 2004 14:44:05 -0500 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: RE: [Ips] Compression and iSCSI PDUs. Date: Tue, 20 Apr 2004 14:44:04 -0500 Message-ID: <43F5E8AE07F17C47BC16F7A159E9E7006B90@mailnode1.commstor.crossroads.com> Thread-Topic: Compression and iSCSI PDUs. Thread-Index: AcQnC4dJ+nidHHE6RX2KywQCVnOA8gAA8CLQ From: "Buck Landry" To: "Preetam Verma" , X-OriginalArrivalTime: 20 Apr 2004 19:44:05.0186 (UTC) FILETIME=[D69D9220:01C4270F] 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 If it must be part of iSCSI, you might try creating a login-phase = negotiated vendor-specific key for this situation. --buck -----Original Message----- From: ips-admin@ietf.org [mailto:ips-admin@ietf.org]On Behalf Of Preetam Verma Sent: Tuesday, April 20, 2004 2:10 PM To: ips@ietf.org Subject: [Ips] Compression and iSCSI PDUs. Using an IPSec gateway kind of a thing would be a cumbersome solution = for me(too many chips). If I use one of the reserved bits, I don't have = a stable solution either if that bit were to change in the future. What = would be the best way out in this case? Preetam _______________________________________________ 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 Apr 20 18:15:32 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 SAA02187 for ; Tue, 20 Apr 2004 18:15:32 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BG3Iv-0008SE-2n for ips-archive@odin.ietf.org; Tue, 20 Apr 2004 18:01:21 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i3KM1LMe032491 for ips-archive@odin.ietf.org; Tue, 20 Apr 2004 18:01:21 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BG2vZ-0003En-Qz for ips-web-archive@optimus.ietf.org; Tue, 20 Apr 2004 17:37:13 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA27711 for ; Tue, 20 Apr 2004 17:37:10 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BG2vX-0001jf-Bl for ips-web-archive@ietf.org; Tue, 20 Apr 2004 17:37:11 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BG2ua-0001gA-00 for ips-web-archive@ietf.org; Tue, 20 Apr 2004 17:36:12 -0400 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1BG2te-0001dS-00 for ips-web-archive@ietf.org; Tue, 20 Apr 2004 17:35:14 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BG1ln-00045O-RK; Tue, 20 Apr 2004 16:23:03 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BG1Ol-0000AZ-Fr for ips@optimus.ietf.org; Tue, 20 Apr 2004 15:59:15 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA18745 for ; Tue, 20 Apr 2004 15:59:13 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BG1Oj-0005lx-UH for ips@ietf.org; Tue, 20 Apr 2004 15:59:14 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BG1Nn-0005jA-00 for ips@ietf.org; Tue, 20 Apr 2004 15:58:16 -0400 Received: from sadr.equallogic.com ([66.155.203.134]) by ietf-mx with smtp (Exim 4.12) id 1BG1NX-0005gL-00 for ips@ietf.org; Tue, 20 Apr 2004 15:57:59 -0400 Received: from sadr.equallogic.com (localhost.localdomain [127.0.0.1]) by sadr.equallogic.com (8.12.8/8.12.8) with ESMTP id i3KJvTVL014799 for ; Tue, 20 Apr 2004 15:57:29 -0400 Received: from M30.equallogic.com (m30 [172.16.1.30]) by sadr.equallogic.com (8.12.8/8.12.8) with SMTP id i3KJvTru014793; Tue, 20 Apr 2004 15:57:29 -0400 Received: from PKONING.equallogic.com ([172.16.1.120]) by M30.equallogic.com with Microsoft SMTPSVC(5.0.2195.6713); Tue, 20 Apr 2004 15:57:32 -0400 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <16517.32940.44000.634031@gargle.gargle.HOWL> Date: Tue, 20 Apr 2004 15:57:32 -0400 From: Paul Koning To: pverma@marantinetworks.com Cc: ips@ietf.org Subject: Re: [Ips] Compression and iSCSI PDUs. References: X-Mailer: VM 7.07 under 21.4 (patch 10) "Military Intelligence (Windows)" XEmacs Lucid X-OriginalArrivalTime: 20 Apr 2004 19:57:32.0273 (UTC) FILETIME=[B7AD4610:01C42711] 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 >>>>> "Preetam" == Preetam Verma writes: Preetam> Using an IPSec gateway kind of a thing would be a cumbersome Preetam> solution for me(too many chips). If I use one of the Preetam> reserved bits, I don't have a stable solution either if that Preetam> bit were to change in the future. What would be the best way Preetam> out in this case? Are you suggesting that compression should be built in to iSCSI? If so, I think that's a very bad idea. It's quite wrong to reinvent everything that's in IPcomp when IPcomp already exists and provides the capabilities you are asking for. I mentioned that I would deploy IPcomp as part of a VPN gateway setup. That's a valid and plausible scenario, but it's not the only possibility. You can also implement IPcomp right into your devices if you wish to do so. You may not find anyone else to talk to other than IPsec/IPcomp gateway boxes -- given that compression has no obvious place on LANs. But protocol wise this would be a valid design. As for the number of chips, that's a non-issue. You can integrate several protocols into one chip if that makes sense in your design. If you have an iSCSI chip, it already implements a complete TCP/IP stack. Adding IPcomp to it would certainly be possible. paul _______________________________________________ Ips mailing list Ips@ietf.org https://www1.ietf.org/mailman/listinfo/ips From exim@www1.ietf.org Tue Apr 20 18:16: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 SAA02464 for ; Tue, 20 Apr 2004 18:16:56 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BG3LZ-0003vz-3L for ips-archive@odin.ietf.org; Tue, 20 Apr 2004 18:04:05 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i3KM45T8015115 for ips-archive@odin.ietf.org; Tue, 20 Apr 2004 18:04:05 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BG33O-0000J3-Dm for ips-web-archive@optimus.ietf.org; Tue, 20 Apr 2004 17:45:18 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA28186 for ; Tue, 20 Apr 2004 17:45:14 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BG33L-0002PC-Ug for ips-web-archive@ietf.org; Tue, 20 Apr 2004 17:45:15 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BG32M-0002Fh-00 for ips-web-archive@ietf.org; Tue, 20 Apr 2004 17:44:15 -0400 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1BG31O-0002B9-00 for ips-web-archive@ietf.org; Tue, 20 Apr 2004 17:43:14 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BG1xN-0001UR-Au; Tue, 20 Apr 2004 16:35:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BG1Po-0000Sj-Du for ips@optimus.ietf.org; Tue, 20 Apr 2004 16:00:20 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA18791 for ; Tue, 20 Apr 2004 16:00:18 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BG1Pm-0005pZ-Np for ips@ietf.org; Tue, 20 Apr 2004 16:00:18 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BG1On-0005mi-00 for ips@ietf.org; Tue, 20 Apr 2004 15:59:18 -0400 Received: from mtagate6.de.ibm.com ([195.212.29.155]) by ietf-mx with esmtp (Exim 4.12) id 1BG1OY-0005jM-00; Tue, 20 Apr 2004 15:59:02 -0400 Received: from d12nrmr1607.megacenter.de.ibm.com (d12nrmr1607.megacenter.de.ibm.com [9.149.167.49]) by mtagate6.de.ibm.com (8.12.10/8.12.10) with ESMTP id i3KJwVMp122524; Tue, 20 Apr 2004 19:58:31 GMT Received: from d12ml102.megacenter.de.ibm.com (d12av02.megacenter.de.ibm.com [9.149.165.228]) by d12nrmr1607.megacenter.de.ibm.com (8.12.10/NCO/VER6.6) with ESMTP id i3KJwV2C092280; Tue, 20 Apr 2004 21:58:31 +0200 In-Reply-To: To: "Preetam Verma" Cc: ips@ietf.org, ips-admin@ietf.org MIME-Version: 1.0 Subject: Re: [Ips] Encryption and ISCSI PDUs. X-Mailer: Lotus Notes Release 6.5.1 January 21, 2004 From: Julian Satran Message-ID: Date: Tue, 20 Apr 2004 15:58:30 -0400 X-MIMETrack: Serialize by Router on D12ML102/12/M/IBM(Release 6.0.2CF2|July 23, 2003) at 20/04/2004 22:58:31, Serialize complete at 20/04/2004 22:58:31 Content-Type: multipart/alternative; boundary="=_alternative 006D8E6C85256E7C_=" 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 This is a multipart message in MIME format. --=_alternative 006D8E6C85256E7C_= Content-Type: text/plain; charset="US-ASCII" If you are taling about standard IP compression that is handled by different headers than the iSCSI one. Otherwise if you want compression at the iSCSI level you may want to negotiate it with vendor keys and you won't need anything else. Julo "Preetam Verma" Sent by: ips-admin@ietf.org 20/04/04 14:02 To cc Subject [Ips] Encryption and ISCSI PDUs. Do I need to use on of the reserved bits to compress ISCSI PDUs using some compression algorithm? I quickly went through the draft but could not find any specific bit that you can use for something like this. Regards Preetam _______________________________________________ Ips mailing list Ips@ietf.org https://www1.ietf.org/mailman/listinfo/ips --=_alternative 006D8E6C85256E7C_= Content-Type: text/html; charset="US-ASCII"
If you are taling about standard IP compression that is handled by different headers than the iSCSI one.
Otherwise if you want compression at the iSCSI level you may want to negotiate it with vendor keys and you won't need anything else.

Julo


"Preetam Verma" <pverma@marantinetworks.com>
Sent by: ips-admin@ietf.org

20/04/04 14:02

To
<ips@ietf.org>
cc
Subject
[Ips] Encryption and ISCSI PDUs.





Do I need to use on of the reserved bits to compress ISCSI PDUs using some compression algorithm? I quickly went through the draft but could not find any specific bit that you can use for something like this.

Regards

Preetam

_______________________________________________
Ips mailing list
Ips@ietf.org
https://www1.ietf.org/mailman/listinfo/ips
--=_alternative 006D8E6C85256E7C_=-- _______________________________________________ Ips mailing list Ips@ietf.org https://www1.ietf.org/mailman/listinfo/ips From exim@www1.ietf.org Wed Apr 21 18:33:02 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 SAA25469 for ; Wed, 21 Apr 2004 18:33:01 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BGQ2U-0004Kb-34 for ips-archive@odin.ietf.org; Wed, 21 Apr 2004 18:17:59 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i3LMHsYc016649 for ips-archive@odin.ietf.org; Wed, 21 Apr 2004 18:17:54 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BGPBj-0005ax-LG for ips-web-archive@optimus.ietf.org; Wed, 21 Apr 2004 17:23:23 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA15638 for ; Wed, 21 Apr 2004 17:23:20 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BGPBh-0001mX-BI for ips-web-archive@ietf.org; Wed, 21 Apr 2004 17:23:21 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BGP8f-0000ye-00 for ips-web-archive@ietf.org; Wed, 21 Apr 2004 17:20:14 -0400 Received: from [65.246.255.50] (helo=mx2.foretec.com) by ietf-mx with esmtp (Exim 4.12) id 1BGP6g-0000JF-02 for ips-web-archive@ietf.org; Wed, 21 Apr 2004 17:18:10 -0400 Received: from optimus22.ietf.org ([132.151.6.22] helo=optimus.ietf.org) by mx2.foretec.com with esmtp (Exim 4.24) id 1BGOwM-0007hw-I1 for ips-web-archive@ietf.org; Wed, 21 Apr 2004 17:07:30 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BGOZv-0003VA-Tz; Wed, 21 Apr 2004 16:44:19 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BGLNJ-0004hl-50 for ips@optimus.ietf.org; Wed, 21 Apr 2004 13:19:05 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA02739 for ; Wed, 21 Apr 2004 13:19:03 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BGLNH-0005IN-5t for ips@ietf.org; Wed, 21 Apr 2004 13:19:03 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BGLMG-00059P-00 for ips@ietf.org; Wed, 21 Apr 2004 13:18:01 -0400 Received: from mononoke.wasabisystems.com ([151.199.66.145]) by ietf-mx with esmtp (Exim 4.12) id 1BGLLR-00050D-00 for ips@ietf.org; Wed, 21 Apr 2004 13:17:09 -0400 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 78EC540137; Wed, 21 Apr 2004 13:17:01 -0400 (EDT) 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-1--966086300" Message-Id: Content-Transfer-Encoding: 7bit Cc: From: William Studenmund Subject: Re: [Ips] Encryption and ISCSI PDUs. Date: Wed, 21 Apr 2004 10:16:52 -0700 To: "Preetam Verma" 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-1--966086300 Content-Type: text/plain; charset=US-ASCII; format=flowed Content-Transfer-Encoding: 7bit On Apr 20, 2004, at 11:02 AM, Preetam Verma wrote: > Do I need to use on of the reserved bits to compress ISCSI PDUs using > some compression algorithm? I quickly went through the draft but could > not find any specific bit that you can use for something like this. One question which hasn't come up is why do you want to compress PDUs? Compression makes the most sense for a situation where the connection is "slow" and processing power is "cheep". Thus it makes sense to spend processing power (CPU cycles) to compress the data for the slow link. The main motivator behind iSCSI, though, is Gigabit Ethernet. With it, the connection is not "slow". In fact, the connection is fast compared to a lot of stuff. Line rate for iSCSI is around 112 MiB/sec. Low-end PCs have 33 MHz 32-bit busses, which can transfer at 133 MB/sec theoretically. You of course aren't going to get that transfer rate, so the PCI bus will be as slow or slower than the max iSCSI rate. So all compression will do in this case is make things worse. You'll have to take processing power to read the raw data, compress it, write it to memory, then read that memory for TCP transmission. You're adding two extra data copies and eating the CPU. Not a good situation. On the WAN side of things, the connection will go back to being slow. However even here I don't think compression is what you want to do. The problem is you probably also have a long link. So to get optimal performance, you want to fill the TCP pipe. That means lots of data outstanding (specifically bandwidth * delay worth). The way to do that is to work with a deep task queue and a storage system that will have lots of tasks outstanding. Only when you are filling the TCP pipe full will it make sense to look at compression. Even then I'd suggest something like IPcomp. Otherwise, your initiator has to be used with your target (since any solution using reserved bits would be proprietary). Do you really want to develop both of them? Will your customers really want to be tied into your products? With IPcomp, you're playing the standardized-products game. Your product will work with other standards-compliant products, and your product will sell better. Take care, Bill --Apple-Mail-1--966086300 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) iD8DBQFAhqyLDJT2Egh26K0RAm+lAJ9V4ZWJnAJYx/Sijv1VJHJADYyYxQCcCpte 3Xtq7ONvZvb5yEjPStZCJNc= =gmQv -----END PGP SIGNATURE----- --Apple-Mail-1--966086300-- _______________________________________________ Ips mailing list Ips@ietf.org https://www1.ietf.org/mailman/listinfo/ips From exim@www1.ietf.org Thu Apr 22 19:06:07 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 TAA10880 for ; Thu, 22 Apr 2004 19:06:07 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BGnDP-0004rq-O3 for ips-archive@odin.ietf.org; Thu, 22 Apr 2004 19:02:43 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i3MN2ho8018702 for ips-archive@odin.ietf.org; Thu, 22 Apr 2004 19:02:43 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BGmrz-0005U1-Oi for ips-web-archive@optimus.ietf.org; Thu, 22 Apr 2004 18:40:35 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA09213 for ; Thu, 22 Apr 2004 18:40:30 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BGmru-0007mj-NX for ips-web-archive@ietf.org; Thu, 22 Apr 2004 18:40:30 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BGmqu-0007V2-00 for ips-web-archive@ietf.org; Thu, 22 Apr 2004 18:39:28 -0400 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1BGmq3-0007D9-00 for ips-web-archive@ietf.org; Thu, 22 Apr 2004 18:38:35 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BGmer-0008AJ-Ox; Thu, 22 Apr 2004 18:27:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BGmG7-0008RQ-Cr for ips@optimus.ietf.org; Thu, 22 Apr 2004 18:01:27 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA05034 for ; Thu, 22 Apr 2004 18:01:22 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BGmG2-0004Am-Jw for ips@ietf.org; Thu, 22 Apr 2004 18:01:22 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BGmF3-0003qj-00 for ips@ietf.org; Thu, 22 Apr 2004 18:00:21 -0400 Received: from mail.cs.utexas.edu ([128.83.139.10] ident=root) by ietf-mx with esmtp (Exim 4.12) id 1BGmE2-0003XS-00 for ips@ietf.org; Thu, 22 Apr 2004 17:59:18 -0400 Received: from mainsa.cs.utexas.edu (nishit@mainsa.cs.utexas.edu [128.83.144.239]) by mail.cs.utexas.edu (8.12.11/8.12.11) with ESMTP id i3MLxKJn021717 for ; Thu, 22 Apr 2004 16:59:20 -0500 (CDT) Received: (from nishit@localhost) by mainsa.cs.utexas.edu (8.12.11/8.12.11/Submit) id i3MLxKkN005893; Thu, 22 Apr 2004 16:59:20 -0500 Date: Thu, 22 Apr 2004 16:59:20 -0500 (CDT) From: "Nishit S. Shah" To: ips@ietf.org Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Subject: [Ips] iSCSI application characteristics 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 Hello, I am studying the application characteristics of storage protocols like iSCSI. I need some help in figuring out some characteristics of iSCSI like: Typically how many sessions are maintained by an initiator/target. How many connections one usually supports per session. What is the state maintained per session and what are the typical data structures used. Could you please forward me a pointer which can be of use? Thank you very much for your help, Nishit | Nishit Sureshchandra Shah | (512) 658-8257 | Off: ACES 6.402 | _______________________________________________ Ips mailing list Ips@ietf.org https://www1.ietf.org/mailman/listinfo/ips From exim@www1.ietf.org Fri Apr 23 17:05: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 RAA11450 for ; Fri, 23 Apr 2004 17:05:41 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BH7SD-0003xU-HE for ips-archive@odin.ietf.org; Fri, 23 Apr 2004 16:39:21 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i3NKdLgn015211 for ips-archive@odin.ietf.org; Fri, 23 Apr 2004 16:39:21 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BH6mv-0007Ei-B6 for ips-web-archive@optimus.ietf.org; Fri, 23 Apr 2004 15:56:41 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA05502 for ; Fri, 23 Apr 2004 15:56:38 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BH6mt-0002z5-Ss for ips-web-archive@ietf.org; Fri, 23 Apr 2004 15:56:39 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BH6la-0002Pw-00 for ips-web-archive@ietf.org; Fri, 23 Apr 2004 15:55:18 -0400 Received: from [65.246.255.50] (helo=mx2.foretec.com) by ietf-mx with esmtp (Exim 4.12) id 1BH6jm-0001wi-01 for ips-web-archive@ietf.org; Fri, 23 Apr 2004 15:53:26 -0400 Received: from optimus22.ietf.org ([132.151.6.22] helo=optimus.ietf.org) by mx2.foretec.com with esmtp (Exim 4.24) id 1BH6Xx-0006xx-KC for ips-web-archive@ietf.org; Fri, 23 Apr 2004 15:41:13 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BH6KD-0005kp-UX; Fri, 23 Apr 2004 15:27:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BH6D5-0001Sp-76 for ips@optimus.ietf.org; Fri, 23 Apr 2004 15:19:39 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA02190 for ; Fri, 23 Apr 2004 15:19:36 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BH6D3-0007cS-OD for ips@ietf.org; Fri, 23 Apr 2004 15:19:37 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BH6C8-0007KG-00 for ips@ietf.org; Fri, 23 Apr 2004 15:18:41 -0400 Received: from atlrel6.hp.com ([156.153.255.205]) by ietf-mx with esmtp (Exim 4.12) id 1BH6B8-00072j-00 for ips@ietf.org; Fri, 23 Apr 2004 15:17:38 -0400 Received: from rosemail.rose.hp.com (rosemail.rose.hp.com [15.43.209.160]) by atlrel6.hp.com (Postfix) with ESMTP id E31171C02ACF for ; Fri, 23 Apr 2004 15:17:37 -0400 (EDT) Received: from rose.hp.com (dhcp-roseor-beb167.rose.hp.com [15.23.141.167]) by rosemail.rose.hp.com (Postfix) with ESMTP id 3EF8C826F for ; Fri, 23 Apr 2004 12:06:59 -0700 (PDT) Message-ID: <40896BD1.7030308@rose.hp.com> Date: Fri, 23 Apr 2004 12:17:37 -0700 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] Multi-connection sessions and ErrorRecoveryLevel=0 References: <3A62517F5A8AFE4098ADDBD25B5D4D5C2FBC50@rtpexc03.hq.netapp.com> In-Reply-To: <3A62517F5A8AFE4098ADDBD25B5D4D5C2FBC50@rtpexc03.hq.netapp.com> 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: , 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 Joseph, > Sometimes when I read the spec, I think the target is allowed to > handle this situation by taking these actions: Your reading is correct. > But other times, when I read the spec, I have doubts about > whether such behavior is prescribed or expected. I think such a target behavior will be very reasonable. It doesn't really look like an expensive behavior to support either. Besides, it would leave the initiator in charge of deciding what to do next. If the initiator doesn't want to plug the holes with aborts, it can always decide to shut down the session. -- Mallikarjun Mallikarjun Chadalapaka Networked Storage Architecture Network Storage Solutions Hewlett-Packard MS 5668 Roseville CA 95747 cbm [at] rose.hp.com Pittman, Joseph wrote: > I have a question about multi-connection sessions with ErrorRecoveryLevel=0. > > Consider this situation: > > - Session is in progress consisting of 2 TCP connections {C1, C2) > - Initiator and Target have negotiated ErrorRecoveryLevel=0 > - The target detects an error on TCP connection C1. > > What is the target supposed to do? And, for any initiator-implementers > out there, what actions do you plan to take in the face of such an event? > > I know that the target (or initiator) may choose to escalate this > situation to session recovery, and simply shutdown the entire session, > sending the appropriate ASYNC_MSG, etc. > > But is there provision within the spec for the session to persist > beyond the loss of an individual TCP connection, even though ERL=0 > eliminates the possibility for task reassignment and connection > recovery? > > Sometimes when I read the spec, I think the target is allowed to > handle this situation by taking these actions: > > - Discard any cmd PDUs which have not yet been submitted to > the SCSI layer > - Abort all in-progress commands associated with the failed > connection > - Shutdown the failed connection > - If the discarded PDUs result in a cmd sequence window hole, > then the initiator will have to either resubmit those cmds, > or use task management commands to fill the hole. > > But other times, when I read the spec, I have doubts about > whether such behavior is prescribed or expected. > > Thanks in advance for any guidance! > -- > Joe Pittman > jpittman@netapp.com _______________________________________________ Ips mailing list Ips@ietf.org https://www1.ietf.org/mailman/listinfo/ips From exim@www1.ietf.org Tue Apr 27 11:12:45 2004 Received: from optimus.ietf.org (www.iesg.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA06361 for ; Tue, 27 Apr 2004 11:12:45 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BIUAp-0007zz-Oi for ips-archive@odin.ietf.org; Tue, 27 Apr 2004 11:07:04 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i3RF73Uj030747 for ips-archive@odin.ietf.org; Tue, 27 Apr 2004 11:07:03 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BIU6v-00078T-26 for ips-web-archive@optimus.ietf.org; Tue, 27 Apr 2004 11:03:01 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA05556 for ; Tue, 27 Apr 2004 11:02:54 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BIU6o-0003zO-Ic for ips-web-archive@ietf.org; Tue, 27 Apr 2004 11:02:54 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BIU5v-0003w8-00 for ips-web-archive@ietf.org; Tue, 27 Apr 2004 11:01:59 -0400 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1BIU51-0003tE-00 for ips-web-archive@ietf.org; Tue, 27 Apr 2004 11:01:03 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BITtS-0004Ew-Bq; Tue, 27 Apr 2004 10:49:06 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BITpV-0003Nd-0C for ips@optimus.ietf.org; Tue, 27 Apr 2004 10:45:01 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA04732 for ; Tue, 27 Apr 2004 10:44:54 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BITpO-0003BX-H1 for ips@ietf.org; Tue, 27 Apr 2004 10:44:54 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BIToV-00039N-00 for ips@ietf.org; Tue, 27 Apr 2004 10:43:59 -0400 Received: from brmea-mail-3.sun.com ([192.18.98.34]) by ietf-mx with esmtp (Exim 4.12) id 1BITnh-00037P-00 for ips@ietf.org; Tue, 27 Apr 2004 10:43:09 -0400 Received: from phys-giza-2 ([129.147.4.101]) by brmea-mail-3.sun.com (8.12.10/8.12.9) with ESMTP id i3REhA4W003388 for ; Tue, 27 Apr 2004 08:43:10 -0600 (MDT) Received: from conversion-daemon.giza-mail1.Central.Sun.COM by giza-mail1.Central.Sun.COM (iPlanet Messaging Server 5.2 HotFix 1.16 (built May 14 2003)) id <0HWU000013H2DX@giza-mail1.Central.Sun.COM> for ips@ietf.org; Tue, 27 Apr 2004 08:43:10 -0600 (MDT) 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 <0HWU001583JCWR@giza-mail1.Central.Sun.COM>; Tue, 27 Apr 2004 08:42:48 -0600 (MDT) Date: Tue, 27 Apr 2004 08:42:54 -0600 From: David Weibel Subject: Re: [Ips] iSCSI application characteristics In-reply-to: To: "Nishit S. Shah" Cc: ips@ietf.org Message-id: <2AE8DADD-9859-11D8-8DA2-000A95B1A482@sun.com> MIME-version: 1.0 (Apple Message framework v613) X-Mailer: Apple Mail (2.613) Content-type: text/plain; charset=US-ASCII; format=flowed Content-transfer-encoding: 7BIT 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 [not to plug it but it's a good book] Pick up the book iSCSI by John L. Hufferd. It provides examples of iSCSI applications and provides additional answers to your questions. In addition the iSCSI specification give lots of examples. Specifically the appendix which includes example structures and algorithms. -dcw On Apr 22, 2004, at 3:59 PM, Nishit S. Shah wrote: > Hello, > > I am studying the application characteristics of storage protocols like > iSCSI. > > I need some help in figuring out some characteristics of iSCSI like: > > Typically how many sessions are maintained by an initiator/target. > How many connections one usually supports per session. > What is the state maintained per session and what are the typical data > structures used. > > Could you please forward me a pointer which can be of use? > > Thank you very much for your help, > Nishit > > | Nishit Sureshchandra Shah | (512) 658-8257 | Off: ACES 6.402 | > > _______________________________________________ > 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 Wed Apr 28 15:34: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 PAA11395 for ; Wed, 28 Apr 2004 15:34:15 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BIuh6-0000dC-BW for ips-archive@odin.ietf.org; Wed, 28 Apr 2004 15:26:08 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i3SJQ8DV002427 for ips-archive@odin.ietf.org; Wed, 28 Apr 2004 15:26:08 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BIuZc-0006YO-1o for ips-web-archive@optimus.ietf.org; Wed, 28 Apr 2004 15:18:24 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA09758 for ; Wed, 28 Apr 2004 15:18:22 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BIuZZ-00015d-Hr for ips-web-archive@ietf.org; Wed, 28 Apr 2004 15:18:21 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BIuYb-00011w-00 for ips-web-archive@ietf.org; Wed, 28 Apr 2004 15:17:22 -0400 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1BIuXf-0000ye-00 for ips-web-archive@ietf.org; Wed, 28 Apr 2004 15:16:23 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BIuNd-0001C6-T2; Wed, 28 Apr 2004 15:06:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BIuFL-00027K-Mo for ips@optimus.ietf.org; Wed, 28 Apr 2004 14:57:29 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA07561 for ; Wed, 28 Apr 2004 14:57:24 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BIuFH-0007Pw-Ig for ips@ietf.org; Wed, 28 Apr 2004 14:57:23 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BIuEN-0007KO-00 for ips@ietf.org; Wed, 28 Apr 2004 14:56:28 -0400 Received: from f112.brocade.com ([66.243.153.112] helo=blasphemy.brocade.com) by ietf-mx with esmtp (Exim 4.12) id 1BIuDQ-0007BQ-00; Wed, 28 Apr 2004 14:55:29 -0400 Received: from hq-ex-11.corp.brocade.com (hq-ex-11 [192.168.38.58]) by blasphemy.brocade.com (Postfix) with ESMTP id D4A2F14152; Wed, 28 Apr 2004 11:54:59 -0700 (PDT) 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: Wed, 28 Apr 2004 11:54:59 -0700 Message-ID: <191DA4FAE235D24C9BCC8D50F6B17AB90933B6@hq-ex-11.brocade.com> Thread-Topic: DRAFT: Proposal to remove "dynamic" port type for FcPortType: DRAFT Thread-Index: AcQskqCVLCR/mzvDQn6Q2Jjb6vN9NgAvb4zA From: "Robert Snively" To: Cc: "T11_5 (E-mail)" , "T11_3 (E-mail)" , , "Robert Snively" Content-Transfer-Encoding: quoted-printable Subject: [Ips] Proposal to remove "dynamic" port type for FcPortType 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 I apologize for the cross posting, but the breadth of expert knowledge and breadth of responsibility for this particular=20 subject extends across all four reflectors. The history is: Snively: Proposed including: gPort glPort fnlPort Proposed removing: dynamic Because: All known "dynamic" ports are either G_Ports or GL_Ports (which dynamically change to F_ or E_Ports) or F/NL_Ports (which provides fabric services when no FL_Port is available). All other ports (if known) are "other",=20 whether dynamic or not. McCloghrie: Agreed to add: gPort glPort fnlPort =09 Proposed retaining: dynamic Because: There might be some future ports defined that had mechanisms that would select the final port type using previously undefined mechanisms. In a sense, this was a future proofing. Crandall: Proposed removing: dynamic Because: Unless some clear definition of the port were created or referenced in a standard, it was equivalent to "unknown". My final proposal would be: Remove: dynamic Because: There is no referent for a "dynamic" port. =20 Further explanation: All Fibre Channel Ports have an associated type. That type is determined absolutely either by the port being set to or=20 designed to be compliant with a particular type or by=20 being designed as a specified type of multi-function port that uses a certain standard algorithm to determine which port type will be agreed upon. Ports with knowable types (as opposed to "unknown" types)=20 that do not behave according to those rules are "other" and might as well be labeled as such. Future revisions of a MIB may add additional types to the list as new port types are defined or may use other mechanisms (manufacturer and model) to define the actual use of an "other" port until such changes can be made in the MIB. Note that PortType does not tell everything there is to know about a port. As an example, FcPortType nPort may be implemented as an FCP SCSI initiator port, an FCP SCSI target port, or an IPv6 over SCSI port, none of which is presently defined in the MIB. Similarly E_Ports may have different capabilities such as trunking that are not presently defined in the MIB. Many of these capabilities are also dynamic, requiring negotiations and login operations to actually enable them. However, these capabilities do NOT define a different port type. =20 I believe there are probably a number of solutions to the "future proofing" suggestion that do not require us to make up a definition for a port type. _______________________________________________ Ips mailing list Ips@ietf.org https://www1.ietf.org/mailman/listinfo/ips From exim@www1.ietf.org Wed Apr 28 18:17:05 2004 Received: from optimus.ietf.org (iesg.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA28689 for ; Wed, 28 Apr 2004 18:17:05 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BIxJS-0002Xt-7a for ips-archive@odin.ietf.org; Wed, 28 Apr 2004 18:13:54 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i3SMDs4N009786 for ips-archive@odin.ietf.org; Wed, 28 Apr 2004 18:13:54 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BIx0w-0007xl-0W for ips-web-archive@optimus.ietf.org; Wed, 28 Apr 2004 17:54:46 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA25992 for ; Wed, 28 Apr 2004 17:54:42 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BIx0s-0003Ql-5t for ips-web-archive@ietf.org; Wed, 28 Apr 2004 17:54:42 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BIwyN-0002vP-00 for ips-web-archive@ietf.org; Wed, 28 Apr 2004 17:52:07 -0400 Received: from [65.246.255.50] (helo=mx2.foretec.com) by ietf-mx with esmtp (Exim 4.12) id 1BIwwt-0002dE-00 for ips-web-archive@ietf.org; Wed, 28 Apr 2004 17:50:36 -0400 Received: from optimus22.ietf.org ([132.151.6.22] helo=optimus.ietf.org) by mx2.foretec.com with esmtp (Exim 4.24) id 1BIwrM-0001zg-L0 for ips-web-archive@ietf.org; Wed, 28 Apr 2004 17:44:52 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BIwZI-000478-6S; Wed, 28 Apr 2004 17:26:12 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BIwCT-0008TZ-02 for ips@optimus.ietf.org; Wed, 28 Apr 2004 17:02:37 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA20258 for ; Wed, 28 Apr 2004 17:02:34 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BIwCP-0004hy-H0 for ips@ietf.org; Wed, 28 Apr 2004 17:02:33 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BIwBV-0004bO-00 for ips@ietf.org; Wed, 28 Apr 2004 17:01:38 -0400 Received: from sccrmhc13.comcast.net ([204.127.202.64]) by ietf-mx with esmtp (Exim 4.12) id 1BIwAg-0004Qo-00 for ips@ietf.org; Wed, 28 Apr 2004 17:00:46 -0400 Received: from ivvt2dxrc11 (c-66-177-57-55.se.client2.attbi.com[66.177.57.55]) by comcast.net (sccrmhc13) with SMTP id <2004042821001701600a38n8e> (Authid: esquicksall); Wed, 28 Apr 2004 21:00:17 +0000 Message-ID: <000801c42d63$cd521f60$0503a8c0@ivvt2dxrc11> From: "Eddy Quicksall" To: Date: Wed, 28 Apr 2004 17:00:07 -0400 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0005_01C42D42.42329840" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1409 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1409 Subject: [Ips] iSCSI: NOP-Out during discovery 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.4 required=5.0 tests=AWL,HTML_40_50,HTML_MESSAGE autolearn=no version=2.60 This is a multi-part message in MIME format. ------=_NextPart_000_0005_01C42D42.42329840 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Is it intended that a NOP-Out is allowed during discovery? Technically = since it is not a request, 3.3 probably does not restrict it. If so, = what about a login? 3.3 iSCSI Session Types .... b) Discovery-session All other requests MUST be rejected. ------=_NextPart_000_0005_01C42D42.42329840 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
Is it intended that a NOP-Out = is allowed=20 during discovery? Technically since it is not a request, 3.3 probably = does not=20 restrict it. If so, what about a login?
 
3.3 iSCSI Session = Types
        = ....
    b)=20 Discovery-session
        =     All=20 other requests MUST be rejected.
------=_NextPart_000_0005_01C42D42.42329840-- _______________________________________________ Ips mailing list Ips@ietf.org https://www1.ietf.org/mailman/listinfo/ips From exim@www1.ietf.org Wed Apr 28 19:28:51 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 TAA02997 for ; Wed, 28 Apr 2004 19:28:50 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BIyGW-0006a2-De for ips-archive@odin.ietf.org; Wed, 28 Apr 2004 19:14:56 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i3SNEu7m025289 for ips-archive@odin.ietf.org; Wed, 28 Apr 2004 19:14:56 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BIy6T-0003rp-Eg for ips-web-archive@optimus.ietf.org; Wed, 28 Apr 2004 19:04:33 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA01662 for ; Wed, 28 Apr 2004 19:04:28 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BIy6O-0001DM-Sx for ips-web-archive@ietf.org; Wed, 28 Apr 2004 19:04:28 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BIy5S-00018U-00 for ips-web-archive@ietf.org; Wed, 28 Apr 2004 19:03:30 -0400 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1BIy4U-000146-00 for ips-web-archive@ietf.org; Wed, 28 Apr 2004 19:02:30 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BIxuN-0007Th-Jf; Wed, 28 Apr 2004 18:52:03 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BIxjH-0005I0-GE for ips@optimus.ietf.org; Wed, 28 Apr 2004 18:40:35 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA00439 for ; Wed, 28 Apr 2004 18:40:31 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BIxjD-000788-5a for ips@ietf.org; Wed, 28 Apr 2004 18:40:31 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BIxiH-00074o-00 for ips@ietf.org; Wed, 28 Apr 2004 18:39:34 -0400 Received: from email.crossroads.com ([65.68.235.6]) by ietf-mx with smtp (Exim 4.12) id 1BIxhW-0006xh-00 for ips@ietf.org; Wed, 28 Apr 2004 18:38:46 -0400 Received: from mailnode1.COMMSTOR.Crossroads.com ([192.168.1.249]) by email.crossroads.com with Microsoft SMTPSVC(5.0.2195.6713); Wed, 28 Apr 2004 17:38:18 -0500 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: RE: [Ips] iSCSI: NOP-Out during discovery Date: Wed, 28 Apr 2004 17:38:18 -0500 Message-ID: <43F5E8AE07F17C47BC16F7A159E9E7006B9E@mailnode1.commstor.crossroads.com> Thread-Topic: [Ips] iSCSI: NOP-Out during discovery Thread-Index: AcQtahR3cqK7OyZSTxyTwZY8xYZTJgAAINig From: "Buck Landry" To: "Eddy Quicksall" , X-OriginalArrivalTime: 28 Apr 2004 22:38:18.0237 (UTC) FILETIME=[806C92D0:01C42D71] 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 >>> Is it intended that a NOP-Out is allowed during discovery? Technically = since it is not a request, 3.3 probably does not restrict it. <<< Reading draft-ietf-ips-iscsi-20+errata.txt, I infer from 3.5 that all = iSCSI PDUs are requests or responses, and 3.5.3.6 explicitly refers to = NOP-Out as "NOP-Out Request". >>> If so, what about a login? <<< Good point. In 3.3, s/"The target MUST ONLY"/"During Full Feature = Phase, the target MUST ONLY"/ --buck -----Original Message----- From: ips-admin@ietf.org [mailto:ips-admin@ietf.org]On Behalf Of Eddy = Quicksall Sent: Wednesday, April 28, 2004 4:00 PM To: ips@ietf.org Subject: [Ips] iSCSI: NOP-Out during discovery Is it intended that a NOP-Out is allowed during discovery? Technically = since it is not a request, 3.3 probably does not restrict it. If so, = what about a login? 3.3 iSCSI Session Types .... b) Discovery-session All other requests MUST be rejected. _______________________________________________ Ips mailing list Ips@ietf.org https://www1.ietf.org/mailman/listinfo/ips From exim@www1.ietf.org Wed Apr 28 20:00:55 2004 Received: from optimus.ietf.org (www.iesg.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA05677 for ; Wed, 28 Apr 2004 20:00:55 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BIyte-00010u-7R for ips-archive@odin.ietf.org; Wed, 28 Apr 2004 19:55:22 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i3SNtMFp003891 for ips-archive@odin.ietf.org; Wed, 28 Apr 2004 19:55:22 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BIydP-0006M2-AR for ips-web-archive@optimus.ietf.org; Wed, 28 Apr 2004 19:38:35 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA03896 for ; Wed, 28 Apr 2004 19:38:34 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BIydM-0004TR-ET for ips-web-archive@ietf.org; Wed, 28 Apr 2004 19:38:32 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BIycR-0004Nv-00 for ips-web-archive@ietf.org; Wed, 28 Apr 2004 19:37:35 -0400 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1BIybV-0004IX-00 for ips-web-archive@ietf.org; Wed, 28 Apr 2004 19:36:37 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BIyV7-00031K-OA; Wed, 28 Apr 2004 19:30:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BIyQt-0008VA-A8 for ips@optimus.ietf.org; Wed, 28 Apr 2004 19:25:39 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA02908 for ; Wed, 28 Apr 2004 19:25:38 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BIyQq-00036C-CN for ips@ietf.org; Wed, 28 Apr 2004 19:25:36 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BIyPt-00032l-00 for ips@ietf.org; Wed, 28 Apr 2004 19:24:38 -0400 Received: from mtagate4.de.ibm.com ([195.212.29.153]) by ietf-mx with esmtp (Exim 4.12) id 1BIyPd-0002zB-00; Wed, 28 Apr 2004 19:24:21 -0400 Received: from d12nrmr1607.megacenter.de.ibm.com (d12nrmr1607.megacenter.de.ibm.com [9.149.167.49]) by mtagate4.de.ibm.com (8.12.10/8.12.10) with ESMTP id i3SNNoPk066884; Wed, 28 Apr 2004 23:23:50 GMT Received: from d12ml102.megacenter.de.ibm.com (d12av02.megacenter.de.ibm.com [9.149.165.228]) by d12nrmr1607.megacenter.de.ibm.com (8.12.10/NCO/VER6.6) with ESMTP id i3SNNnYk160270; Thu, 29 Apr 2004 01:23:50 +0200 In-Reply-To: <000801c42d63$cd521f60$0503a8c0@ivvt2dxrc11> To: "Eddy Quicksall" Cc: ips@ietf.org, ips-admin@ietf.org MIME-Version: 1.0 Subject: Re: [Ips] iSCSI: NOP-Out during discovery X-Mailer: Lotus Notes Release 6.5.1 January 21, 2004 From: Julian Satran Message-ID: Date: Wed, 28 Apr 2004 16:23:47 -0700 X-MIMETrack: Serialize by Router on D12ML102/12/M/IBM(Release 6.0.2CF2|July 23, 2003) at 29/04/2004 02:23:49, Serialize complete at 29/04/2004 02:23:49 Content-Type: multipart/alternative; boundary="=_alternative 00807DFF88256E84_=" 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_40_50,HTML_MESSAGE autolearn=no version=2.60 This is a multipart message in MIME format. --=_alternative 00807DFF88256E84_= Content-Type: text/plain; charset="US-ASCII" no - julo "Eddy Quicksall" Sent by: ips-admin@ietf.org 28/04/04 14:00 To cc Subject [Ips] iSCSI: NOP-Out during discovery Is it intended that a NOP-Out is allowed during discovery? Technically since it is not a request, 3.3 probably does not restrict it. If so, what about a login? 3.3 iSCSI Session Types .... b) Discovery-session All other requests MUST be rejected. --=_alternative 00807DFF88256E84_= Content-Type: text/html; charset="US-ASCII"
no - julo


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

28/04/04 14:00

To
<ips@ietf.org>
cc
Subject
[Ips] iSCSI: NOP-Out during discovery





Is it intended that a NOP-Out is allowed during discovery? Technically since it is not a request, 3.3 probably does not restrict it. If so, what about a login?
 
3.3 iSCSI Session Types
        ....
    b) Discovery-session
            All other requests MUST be rejected.
--=_alternative 00807DFF88256E84_=-- _______________________________________________ Ips mailing list Ips@ietf.org https://www1.ietf.org/mailman/listinfo/ips From exim@www1.ietf.org Wed Apr 28 20:30:51 2004 Received: from optimus.ietf.org (www.iesg.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA07105 for ; Wed, 28 Apr 2004 20:30:51 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BIzL0-00006y-Lx for ips-archive@odin.ietf.org; Wed, 28 Apr 2004 20:23:38 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i3T0Nc50000420 for ips-archive@odin.ietf.org; Wed, 28 Apr 2004 20:23:38 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BIzHL-0007e9-LV for ips-web-archive@optimus.ietf.org; Wed, 28 Apr 2004 20:19:51 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA06598 for ; Wed, 28 Apr 2004 20:19:49 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BIzHI-00014S-ED for ips-web-archive@ietf.org; Wed, 28 Apr 2004 20:19:48 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BIzGK-0000zM-00 for ips-web-archive@ietf.org; Wed, 28 Apr 2004 20:18:49 -0400 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1BIzFv-0000tv-00 for ips-web-archive@ietf.org; Wed, 28 Apr 2004 20:18:23 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BIz5z-0005Xi-2W; Wed, 28 Apr 2004 20:08:07 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BIz1e-0003lb-QR for ips@optimus.ietf.org; Wed, 28 Apr 2004 20:03:38 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA05815 for ; Wed, 28 Apr 2004 20:03:37 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BIz1b-0007Hk-KB for ips@ietf.org; Wed, 28 Apr 2004 20:03:35 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BIz0e-0007Bn-00 for ips@ietf.org; Wed, 28 Apr 2004 20:02:37 -0400 Received: from boreas.isi.edu ([128.9.160.161]) by ietf-mx with esmtp (Exim 4.12) id 1BIyzk-00070c-00; Wed, 28 Apr 2004 20:01:40 -0400 Received: from ISI.EDU (adma.isi.edu [128.9.160.239]) by boreas.isi.edu (8.11.6p2+0917/8.11.2) with ESMTP id i3SNxDU03260; Wed, 28 Apr 2004 16:59:13 -0700 (PDT) Message-Id: <200404282359.i3SNxDU03260@boreas.isi.edu> To: IETF-Announce: ; Cc: rfc-editor@rfc-editor.org, ips@ietf.org From: rfc-editor@rfc-editor.org Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary=NextPart Date: Wed, 28 Apr 2004 16:59:13 -0700 X-ISI-4-28-6-MailScanner: Found to be clean X-MailScanner-From: rfc-ed@isi.edu Subject: [Ips] RFC 3721 on Internet Small Computer Systems Interface (iSCSI) Naming and Discovery 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=-1.6 required=5.0 tests=AWL,MIME_BOUND_NEXTPART, NO_REAL_NAME autolearn=no version=2.60 --NextPart A new Request for Comments is now available in online RFC libraries. RFC 3721 Title: Internet Small Computer Systems Interface (iSCSI) Naming and Discovery Author(s): M. Bakke, J. Hafner, J. Hufferd, K. Voruganti, M. Krueger Status: Informational Date: April 2004 Mailbox: mbakke@cisco.com, hafner@almaden.ibm.com, hufferd@us.ibm.com, kaladhar@us.ibm.com, marjorie_krueger@hp.com Pages: 22 Characters: 47564 Updates/Obsoletes/SeeAlso: None I-D Tag: draft-ietf-ips-iscsi-name-disc-10.txt URL: ftp://ftp.rfc-editor.org/in-notes/rfc3721.txt This document provides examples of the Internet Small Computer Systems Interface (iSCSI; or SCSI over TCP) name construction and discussion of discovery of iSCSI resources (targets) by iSCSI initiators. This document complements the iSCSI protocol document. Flexibility is the key guiding principle behind this document. That is, an effort has been made to satisfy the needs of both small isolated environments, as well as large environments requiring secure/scalable solutions. This document is a product of the IP Storage Working Group of the IETF. This memo provides information for the Internet community. It does not specify an Internet standard of any kind. Distribution of this memo is unlimited. This announcement is sent to the IETF list and the RFC-DIST list. Requests to be added to or deleted from the IETF distribution list should be sent to IETF-REQUEST@IETF.ORG. Requests to be added to or deleted from the RFC-DIST distribution list should be sent to RFC-DIST-REQUEST@RFC-EDITOR.ORG. Details on obtaining RFCs via FTP or EMAIL may be obtained by sending an EMAIL message to rfc-info@RFC-EDITOR.ORG with the message body help: ways_to_get_rfcs. For example: To: rfc-info@RFC-EDITOR.ORG Subject: getting rfcs help: ways_to_get_rfcs Requests for special distribution should be addressed to either the author of the RFC in question, or to RFC-Manager@RFC-EDITOR.ORG. Unless specifically noted otherwise on the RFC itself, all RFCs are for unlimited distribution.echo Submissions for Requests for Comments should be sent to RFC-EDITOR@RFC-EDITOR.ORG. Please consult RFC 2223, Instructions to RFC Authors, for further information. Joyce K. Reynolds and Sandy Ginoza USC/Information Sciences Institute ... Below is the data which will enable a MIME compliant Mail Reader implementation to automatically retrieve the ASCII version of the RFCs. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="RFC-INFO@RFC-EDITOR.ORG" Content-Type: text/plain Content-ID: <040428165734.RFC@RFC-EDITOR.ORG> RETRIEVE: rfc DOC-ID: rfc3721 --OtherAccess Content-Type: Message/External-body; name="rfc3721.txt"; site="ftp.isi.edu"; access-type="anon-ftp"; directory="in-notes" Content-Type: text/plain Content-ID: <040428165734.RFC@RFC-EDITOR.ORG> --OtherAccess-- --NextPart-- _______________________________________________ Ips mailing list Ips@ietf.org https://www1.ietf.org/mailman/listinfo/ips From exim@www1.ietf.org Wed Apr 28 20:33:04 2004 Received: from optimus.ietf.org (www.iesg.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA07274 for ; Wed, 28 Apr 2004 20:33:04 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BIzRM-00011g-Mf for ips-archive@odin.ietf.org; Wed, 28 Apr 2004 20:30:12 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i3T0UC1o003935 for ips-archive@odin.ietf.org; Wed, 28 Apr 2004 20:30:12 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BIzK5-0008NV-L3 for ips-web-archive@optimus.ietf.org; Wed, 28 Apr 2004 20:22:41 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA06729 for ; Wed, 28 Apr 2004 20:22:39 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BIzK2-0001LX-DF for ips-web-archive@ietf.org; Wed, 28 Apr 2004 20:22:38 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BIzJG-0001Gu-00 for ips-web-archive@ietf.org; Wed, 28 Apr 2004 20:21:50 -0400 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1BIzIZ-0001Bz-00 for ips-web-archive@ietf.org; Wed, 28 Apr 2004 20:21:07 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BIz61-0005YS-5T; Wed, 28 Apr 2004 20:08:09 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BIz1m-0003ls-A4 for ips@optimus.ietf.org; Wed, 28 Apr 2004 20:03:46 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA05832 for ; Wed, 28 Apr 2004 20:03:44 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BIz1j-0007If-3g for ips@ietf.org; Wed, 28 Apr 2004 20:03:43 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BIz0x-0007Dz-00 for ips@ietf.org; Wed, 28 Apr 2004 20:02:56 -0400 Received: from boreas.isi.edu ([128.9.160.161]) by ietf-mx with esmtp (Exim 4.12) id 1BIz0O-00076G-00; Wed, 28 Apr 2004 20:02:20 -0400 Received: from ISI.EDU (adma.isi.edu [128.9.160.239]) by boreas.isi.edu (8.11.6p2+0917/8.11.2) with ESMTP id i3T014U03723; Wed, 28 Apr 2004 17:01:04 -0700 (PDT) Message-Id: <200404290001.i3T014U03723@boreas.isi.edu> To: IETF-Announce: ; Cc: rfc-editor@rfc-editor.org, ips@ietf.org From: rfc-editor@rfc-editor.org Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary=NextPart Date: Wed, 28 Apr 2004 17:01:04 -0700 X-ISI-4-28-6-MailScanner: Found to be clean X-MailScanner-From: rfc-ed@isi.edu Subject: [Ips] RFC 3722 on String Profile for Internet Small Computer Systems Interface (iSCSI) Names 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=-1.6 required=5.0 tests=AWL,MIME_BOUND_NEXTPART, NO_REAL_NAME autolearn=no version=2.60 --NextPart A new Request for Comments is now available in online RFC libraries. RFC 3722 Title: String Profile for Internet Small Computer Systems Interface (iSCSI) Names Author(s): M. Bakke Status: Standards Track Date: April 2004 Mailbox: mbakke@cisco.com Pages: 8 Characters: 14702 Updates/Obsoletes/SeeAlso: None I-D Tag: draft-ietf-ips-iscsi-string-prep-06.txt URL: ftp://ftp.rfc-editor.org/in-notes/rfc3722.txt This document describes how to prepare internationalized iSCSI names to increase the likelihood that name input and comparison work in ways that make sense for typical users throughout the world. The Internet Small Computer Systems Interface (iSCSI) protocol provides a way for hosts to access SCSI devices over an IP network. The iSCSI end-points, called initiators and targets, each have a globally-unique name that must be transcribable, as well as easily compared. This document is a product of the IP Storage Working Group of the IETF. This is now a Proposed Standard Protocol. This document specifies an Internet standards track protocol for the Internet community, and requests discussion and suggestions for improvements. Please refer to the current edition of the "Internet Official Protocol Standards" (STD 1) for the standardization state and status of this protocol. Distribution of this memo is unlimited. This announcement is sent to the IETF list and the RFC-DIST list. Requests to be added to or deleted from the IETF distribution list should be sent to IETF-REQUEST@IETF.ORG. Requests to be added to or deleted from the RFC-DIST distribution list should be sent to RFC-DIST-REQUEST@RFC-EDITOR.ORG. Details on obtaining RFCs via FTP or EMAIL may be obtained by sending an EMAIL message to rfc-info@RFC-EDITOR.ORG with the message body help: ways_to_get_rfcs. For example: To: rfc-info@RFC-EDITOR.ORG Subject: getting rfcs help: ways_to_get_rfcs Requests for special distribution should be addressed to either the author of the RFC in question, or to RFC-Manager@RFC-EDITOR.ORG. Unless specifically noted otherwise on the RFC itself, all RFCs are for unlimited distribution.echo Submissions for Requests for Comments should be sent to RFC-EDITOR@RFC-EDITOR.ORG. Please consult RFC 2223, Instructions to RFC Authors, for further information. Joyce K. Reynolds and Sandy Ginoza USC/Information Sciences Institute ... Below is the data which will enable a MIME compliant Mail Reader implementation to automatically retrieve the ASCII version of the RFCs. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="RFC-INFO@RFC-EDITOR.ORG" Content-Type: text/plain Content-ID: <040428165935.RFC@RFC-EDITOR.ORG> RETRIEVE: rfc DOC-ID: rfc3722 --OtherAccess Content-Type: Message/External-body; name="rfc3722.txt"; site="ftp.isi.edu"; access-type="anon-ftp"; directory="in-notes" Content-Type: text/plain Content-ID: <040428165935.RFC@RFC-EDITOR.ORG> --OtherAccess-- --NextPart-- _______________________________________________ Ips mailing list Ips@ietf.org https://www1.ietf.org/mailman/listinfo/ips From exim@www1.ietf.org Wed Apr 28 21:07:25 2004 Received: from optimus.ietf.org (iesg.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA08543 for ; Wed, 28 Apr 2004 21:07:24 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BJ00M-0000Nw-Ps for ips-archive@odin.ietf.org; Wed, 28 Apr 2004 21:06:23 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i3T16Mnh001475 for ips-archive@odin.ietf.org; Wed, 28 Apr 2004 21:06:22 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BIzze-0008WA-Fx for ips-web-archive@optimus.ietf.org; Wed, 28 Apr 2004 21:05:38 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA08453 for ; Wed, 28 Apr 2004 21:05:36 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BIzza-0004wI-LN for ips-web-archive@ietf.org; Wed, 28 Apr 2004 21:05:34 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BIzyd-0004rq-00 for ips-web-archive@ietf.org; Wed, 28 Apr 2004 21:04:36 -0400 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1BIzxx-0004ny-00 for ips-web-archive@ietf.org; Wed, 28 Apr 2004 21:03:53 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BIzpQ-0006Ty-62; Wed, 28 Apr 2004 20:55:04 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BIzcR-0004Sv-CE for ips@optimus.ietf.org; Wed, 28 Apr 2004 20:41:39 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA07683 for ; Wed, 28 Apr 2004 20:41:37 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BIzcN-0002yz-Mx for ips@ietf.org; Wed, 28 Apr 2004 20:41:35 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BIzba-0002uO-00 for ips@ietf.org; Wed, 28 Apr 2004 20:40:47 -0400 Received: from sccrmhc13.comcast.net ([204.127.202.64]) by ietf-mx with esmtp (Exim 4.12) id 1BIzaf-0002jW-00; Wed, 28 Apr 2004 20:39:49 -0400 Received: from ivvt2dxrc11 (c-66-177-57-55.se.client2.attbi.com[66.177.57.55]) by comcast.net (sccrmhc13) with SMTP id <2004042900392001600a23h8e> (Authid: esquicksall); Thu, 29 Apr 2004 00:39:20 +0000 Message-ID: <001c01c42d82$69652050$0503a8c0@ivvt2dxrc11> From: "Eddy Quicksall" To: "Julian Satran" Cc: , References: Subject: Re: [Ips] iSCSI: NOP-Out during discovery Date: Wed, 28 Apr 2004 20:39:18 -0400 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0019_01C42D60.E09CF6B0" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1409 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1409 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.4 required=5.0 tests=AWL,HTML_40_50,HTML_MESSAGE, HTML_TAG_EXISTS_TBODY autolearn=no version=2.60 This is a multi-part message in MIME format. ------=_NextPart_000_0019_01C42D60.E09CF6B0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Thanks, I found one popular company that is doing it to see if I'm still = alive.=20 I can see why they probably used a nop ... the spec discurrages using an = empty text request (4th paragraph in 5.2). What is the expected way an initiator should test for "aliveness" during = a discovery session that is held open? Eddy ----- Original Message -----=20 From: Julian Satran=20 To: Eddy Quicksall=20 Cc: ips@ietf.org ; ips-admin@ietf.org=20 Sent: Wednesday, April 28, 2004 7:23 PM Subject: Re: [Ips] iSCSI: NOP-Out during discovery no - julo=20 "Eddy Quicksall" =20 Sent by: ips-admin@ietf.org=20 28/04/04 14:00=20 To =20 cc =20 Subject [Ips] iSCSI: NOP-Out during discovery=20 =20 =20 Is it intended that a NOP-Out is allowed during discovery? Technically = since it is not a request, 3.3 probably does not restrict it. If so, = what about a login?=20 =20 3.3 iSCSI Session Types=20 ....=20 b) Discovery-session=20 All other requests MUST be rejected.=20 ------=_NextPart_000_0019_01C42D60.E09CF6B0 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
Thanks, I found one popular company that is doing it = to see if=20 I'm still alive.
 
I can see why they probably used a nop ... the spec=20 discurrages using an empty text request (4th paragraph in = 5.2).
 
What is the expected way an initiator should test = for=20 "aliveness" during a discovery session that is held open?
 
Eddy
----- Original Message -----
From:=20 Julian Satran
To: Eddy = Quicksall=20
Sent: Wednesday, April 28, 2004 = 7:23=20 PM
Subject: Re: [Ips] iSCSI: = NOP-Out during=20 discovery


no - julo =


"Eddy = Quicksall" <eddy_quicksall_i= Vivity_iSCSI@comcast.net>=20
Sent by: ips-admin@ietf.org =

28/04/04 14:00

To
<ips@ietf.org>=20
cc
Subject
[Ips] = iSCSI: NOP-Out=20 during discovery

=




Is it intended that a NOP-Out is allowed = during=20 discovery? Technically since it is not a request, 3.3 probably does = not=20 restrict it. If so, what about a login?
 =20
3.3 iSCSI Session Types =
        ....
    b) Discovery-session
 =20           All other requests MUST be = rejected.=20
------=_NextPart_000_0019_01C42D60.E09CF6B0-- _______________________________________________ Ips mailing list Ips@ietf.org https://www1.ietf.org/mailman/listinfo/ips From exim@www1.ietf.org Thu Apr 29 09:47:26 2004 Received: from optimus.ietf.org (iesg.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA01750 for ; Thu, 29 Apr 2004 09:47:26 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BJBeo-0003TV-VG for ips-archive@odin.ietf.org; Thu, 29 Apr 2004 09:32:55 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i3TDWstn013357 for ips-archive@odin.ietf.org; Thu, 29 Apr 2004 09:32:54 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BJBXf-0007Rj-Kn for ips-web-archive@optimus.ietf.org; Thu, 29 Apr 2004 09:25:31 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA00318 for ; Thu, 29 Apr 2004 09:25:23 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BJBXU-0005iS-Qv for ips-web-archive@ietf.org; Thu, 29 Apr 2004 09:25:20 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BJBWT-0005Ra-00 for ips-web-archive@ietf.org; Thu, 29 Apr 2004 09:24:18 -0400 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1BJBVh-0005CU-00 for ips-web-archive@ietf.org; Thu, 29 Apr 2004 09:23:29 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BJBF8-0001Jp-E4; Thu, 29 Apr 2004 09:06:22 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BJAr2-0007EJ-7G for ips@optimus.ietf.org; Thu, 29 Apr 2004 08:41:28 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA25715 for ; Thu, 29 Apr 2004 08:41:20 -0400 (EDT) From: AClarke@attotech.com Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BJAqs-0000ng-6c for ips@ietf.org; Thu, 29 Apr 2004 08:41:18 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BJApo-0000VZ-00 for ips@ietf.org; Thu, 29 Apr 2004 08:40:13 -0400 Received: from sw.attotech.com ([12.32.232.56] helo=noteserv1.attotech.com) by ietf-mx with esmtp (Exim 4.12) id 1BJAoX-0007mg-00 for ips@ietf.org; Thu, 29 Apr 2004 08:38:58 -0400 Subject: Re: [Ips] iSCSI: NOP-Out during discovery To: "Eddy Quicksall" , ips@ietf.org Message-ID: Date: Thu, 29 Apr 2004 08:38:49 -0400 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 Eddy, You can send "SendTargets=All" to the target at any time during discovery sessions. This will definetly tell you if the connection is alive and that is the only reason to keep the session open anyway. >From Appendix D: After obtaining a list of targets from the discovery target session, an iSCSI initiator may initiate new sessions to log in to the discovered targets for full operation. The initiator MAY keep the discovery session open, and MAY send subsequent SendTargets commands to discover new targets. I would prefer if initiators just performed a new login for each discovery session. Here are my reasons: 1. Less connections open = less resources wasted on the target. 2. Having two ways to report target changes adds complexity. 3. I doubt target lists will change that often, checking once when the initiator boots or when an administrator asks seems sufficient. Regards, Aaron "Eddy Quicksall" omcast.net> cc: , Sent by: ips-admin@ietf.org Subject: Re: [Ips] iSCSI: NOP-Out during discovery 04/28/2004 08:39 PM Thanks, I found one popular company that is doing it to see if I'm still alive. I can see why they probably used a nop ... the spec discurrages using an empty text request (4th paragraph in 5.2). What is the expected way an initiator should test for "aliveness" during a discovery session that is held open? Eddy ----- Original Message ----- From: Julian Satran To: Eddy Quicksall Cc: ips@ietf.org ; ips-admin@ietf.org Sent: Wednesday, April 28, 2004 7:23 PM Subject: Re: [Ips] iSCSI: NOP-Out during discovery no - julo "Eddy Quicksall" < eddy_quicksall_iVivity_iSCSI@comcast.net> Sent by: ips-admin@ietf.org To 28/04/04 14:00 cc Subject [Ips] iSCSI: NOP-Out during discovery Is it intended that a NOP-Out is allowed during discovery? Technically since it is not a request, 3.3 probably does not restrict it. If so, what about a login? 3.3 iSCSI Session Types .... b) Discovery-session All other requests MUST be rejected. _______________________________________________ Ips mailing list Ips@ietf.org https://www1.ietf.org/mailman/listinfo/ips From exim@www1.ietf.org Thu Apr 29 19:11:12 2004 Received: from optimus.ietf.org (iesg.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA09787 for ; Thu, 29 Apr 2004 19:11:12 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BJKeB-0005tC-P3 for ips-archive@odin.ietf.org; Thu, 29 Apr 2004 19:08:52 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i3TN8psu022638 for ips-archive@odin.ietf.org; Thu, 29 Apr 2004 19:08:51 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BJKVB-0004N2-Ri for ips-web-archive@optimus.ietf.org; Thu, 29 Apr 2004 18:59:33 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA09046 for ; Thu, 29 Apr 2004 18:59:27 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BJKV3-0005vy-BQ for ips-web-archive@ietf.org; Thu, 29 Apr 2004 18:59:25 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BJKU8-0005qX-00 for ips-web-archive@ietf.org; Thu, 29 Apr 2004 18:58:29 -0400 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1BJKTX-0005na-00 for ips-web-archive@ietf.org; Thu, 29 Apr 2004 18:57:51 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BJKPq-0003EM-Bs; Thu, 29 Apr 2004 18:54:02 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BJKEl-0001Dx-Ri for ips@optimus.ietf.org; Thu, 29 Apr 2004 18:42:41 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA08469 for ; Thu, 29 Apr 2004 18:42:29 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BJKEd-00052R-C2 for ips@ietf.org; Thu, 29 Apr 2004 18:42:27 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BJKDh-0004zE-00 for ips@ietf.org; Thu, 29 Apr 2004 18:41:30 -0400 Received: from sj-iport-4.cisco.com ([171.68.10.86]) by ietf-mx with esmtp (Exim 4.12) id 1BJKD0-0004tE-00; Thu, 29 Apr 2004 18:40:46 -0400 Received: from cypher.cisco.com (cypher.cisco.com [171.69.11.143]) by sj-core-5.cisco.com (8.12.10/8.12.6) with ESMTP id i3TMeFW9017778; Thu, 29 Apr 2004 15:40:16 -0700 (PDT) Received: (from kzm@localhost) by cypher.cisco.com (8.8.8/2.6/Cisco List Logging/8.8.8) id PAA12461; Thu, 29 Apr 2004 15:40:05 -0700 (PDT) From: Keith McCloghrie Message-Id: <200404292240.PAA12461@cypher.cisco.com> Subject: Re: [Ips] Proposal to remove "dynamic" port type for FcPortType To: rsnively@Brocade.COM (Robert Snively) Date: Thu, 29 Apr 2004 15:40:05 -0700 (PDT) Cc: ips@ietf.org, t11_5@mail.t11.org ("T11_5 (E-mail)"), t11_3@mail.t11.org ("T11_3 (E-mail)"), imss@ietf.org, rsnively@Brocade.COM (Robert Snively) In-Reply-To: <191DA4FAE235D24C9BCC8D50F6B17AB90933B6@hq-ex-11.brocade.com> from "Robert Snively" at Apr 28, 2004 11:54:59 AM 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 Bob, Thanks for raising this. I believe that as editor, I do need the WG's approval to make any additions or deletions to: draft-ietf-ips-fcmgmt-mib-04.txt at its current stage of progress. So, if the WG approves the addition of these three recently-defined new types: 'gPort', 'glPort' and 'fnlPort' as new enumerations of the FcPortType TC, then I can go ahead and add them. As regards 'dynamic': - it is obviously needed in the MIB's current state (to represent G_Ports, GL_Ports and F/NL_Ports), and if the WG decided to defer the addition of the three new types, then it would continue to be needed. - to characterize the retention of 'dynamic' as unnecessary "future proofing" is to ignore history. Specifically, 'dynamic' was defined in the original version of the draft-ietf-ips-fcmgmt-mib, more than two years ago, and hindsight shows us that was a smart move, because (as I said above) it is needed in the MIB's current state, it would continue to be needed if we deferred adding the three new types, and there are good chances it will be needed yet again in the future, even after we add the three new types. - the first of those good chances is currently being debated in T11 in regard to (virtual-fabric) "trunking". It seems to me that while T11 has not yet reached the stage of debating of whether "trunking" is a characteristic of a port type, it likely is because a result of the layer-2 negotiation (that you mention) will be the port becoming either a trunking port or one of the already-defined values of FcPortType, i.e., it's a type just like the existing ones are. The other (non-)types you mention are completely different because they will not be the subject of a layer-2 negotiation, and thus I agree that those others are not port types at layer-2 (and this is a layer-2 MIB). - and finally, to remove 'dynamic' because: There is no referent for a "dynamic" port. doesn't make any sense to me because there is no referent for an "unknown port" and no referent for an "other port". Since we're not going to throw out 'unknown' or 'other' for this reason, then neither should we throw out 'dyanmic'. Thanks, Keith. > I apologize for the cross posting, but the breadth of expert > knowledge and breadth of responsibility for this particular > subject extends across all four reflectors. > > The history is: > > Snively: > > Proposed including: > gPort > glPort > fnlPort > > Proposed removing: > dynamic > > Because: > All known "dynamic" ports are either G_Ports or > GL_Ports (which dynamically change to F_ or E_Ports) > or F/NL_Ports (which provides fabric services when > no FL_Port is available). > All other ports (if known) are "other", > whether dynamic or not. > > McCloghrie: > > Agreed to add: > gPort > glPort > fnlPort > > Proposed retaining: > dynamic > > Because: > There might be some future ports defined that had > mechanisms that would select the final port type > using previously undefined mechanisms. > In a sense, this was a future proofing. > > Crandall: > > Proposed removing: > dynamic > > Because: > Unless some clear definition of the port were > created or referenced in a standard, it was > equivalent to "unknown". > > My final proposal would be: > > Remove: > dynamic > > Because: > There is no referent for a "dynamic" port. > > Further explanation: > > All Fibre Channel Ports have an associated type. That type > is determined absolutely either by the port being set to or > designed to be compliant with a particular type or by > being designed as a specified type of multi-function port > that uses a certain standard algorithm to determine which > port type will be agreed upon. > > Ports with knowable types (as opposed to "unknown" types) > that do not behave according to those rules are "other" > and might as well be labeled as such. Future revisions > of a MIB may add additional types to the list as new port types > are defined or may use other mechanisms (manufacturer and model) > to define the actual use of an "other" port until such changes > can be made in the MIB. > > Note that PortType does not tell everything there is to know > about a port. As an example, FcPortType nPort may be implemented > as an FCP SCSI initiator port, an FCP SCSI target port, or > an IPv6 over SCSI port, none of which is presently defined in the > MIB. Similarly E_Ports may have different capabilities such > as trunking that are not presently defined in the MIB. Many of > these capabilities are also dynamic, requiring negotiations and > login operations to actually enable them. However, these capabilities > do NOT define a different port type. > > I believe there are probably a number of solutions to the > "future proofing" suggestion that do not require us to > make up a definition for a port type. > _______________________________________________ Ips mailing list Ips@ietf.org https://www1.ietf.org/mailman/listinfo/ips From exim@www1.ietf.org Fri Apr 30 10:06:38 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 KAA02705 for ; Fri, 30 Apr 2004 10:06:38 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BJYaE-0007F6-EN for ips-archive@odin.ietf.org; Fri, 30 Apr 2004 10:01:42 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i3UE1gFu027836 for ips-archive@odin.ietf.org; Fri, 30 Apr 2004 10:01:42 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BJYXj-0005mg-I9 for ips-web-archive@optimus.ietf.org; Fri, 30 Apr 2004 09:59:07 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA02042 for ; Fri, 30 Apr 2004 09:59:04 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BJYXh-00044w-KU for ips-web-archive@ietf.org; Fri, 30 Apr 2004 09:59:05 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BJYWp-00043J-00 for ips-web-archive@ietf.org; Fri, 30 Apr 2004 09:58:11 -0400 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1BJYWS-00041P-00 for ips-web-archive@ietf.org; Fri, 30 Apr 2004 09:57:48 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BJYSn-00053S-6d; Fri, 30 Apr 2004 09:54:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BJYOy-0004Sp-9C for ips@optimus.ietf.org; Fri, 30 Apr 2004 09:50:04 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA01629 for ; Fri, 30 Apr 2004 09:49:59 -0400 (EDT) From: Black_David@emc.com Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BJYOw-0003fP-6d for ips@ietf.org; Fri, 30 Apr 2004 09:50:02 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BJYO4-0003eV-00 for ips@ietf.org; Fri, 30 Apr 2004 09:49:09 -0400 Received: from mxic2.corp.emc.com ([128.221.12.9]) by ietf-mx with esmtp (Exim 4.12) id 1BJYNg-0003cu-00 for ips@ietf.org; Fri, 30 Apr 2004 09:48:44 -0400 Received: by mxic2.corp.emc.com with Internet Mail Service (5.5.2653.19) id ; Fri, 30 Apr 2004 09:48:14 -0400 Message-ID: To: ips@ietf.org Date: Fri, 30 Apr 2004 09:48:12 -0400 Importance: high X-Priority: 1 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain Subject: [Ips] iSCSI RFCs published! 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.6 required=5.0 tests=AWL,NO_REAL_NAME, X_PRIORITY_HIGH autolearn=no version=2.60 While I haven't seen the announcements yet, the iSCSI RFCs have been published: iSCSI (RFC 3720) iSCSI Naming and Discovery (RFC 3721) String Profile for iSCSI Names (RFC 3722) Securing Block Storage Protocols over IP (RFC 3723) Thanks and congratulations to all involved, --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 Fri Apr 30 11:32: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 LAA08631 for ; Fri, 30 Apr 2004 11:32:22 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BJZsG-0001Iv-Pj for ips-archive@odin.ietf.org; Fri, 30 Apr 2004 11:24:24 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i3UFOOQb005008 for ips-archive@odin.ietf.org; Fri, 30 Apr 2004 11:24:24 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BJZp0-0000PM-Sb for ips-web-archive@optimus.ietf.org; Fri, 30 Apr 2004 11:21:02 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA07868 for ; Fri, 30 Apr 2004 11:21:00 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BJZp0-0000oO-0w for ips-web-archive@ietf.org; Fri, 30 Apr 2004 11:21:02 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BJZo4-0000kk-00 for ips-web-archive@ietf.org; Fri, 30 Apr 2004 11:20:05 -0400 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1BJZnC-0000iD-00 for ips-web-archive@ietf.org; Fri, 30 Apr 2004 11:19:10 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BJZWb-0005VO-U5; Fri, 30 Apr 2004 11:02:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BJZN8-0003TO-DO for ips@optimus.ietf.org; Fri, 30 Apr 2004 10:52:14 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA05731 for ; Fri, 30 Apr 2004 10:52:10 -0400 (EDT) From: AClarke@attotech.com Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BJZN5-0006fk-Tg for ips@ietf.org; Fri, 30 Apr 2004 10:52:12 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BJZMD-0006dW-00 for ips@ietf.org; Fri, 30 Apr 2004 10:51:17 -0400 Received: from sw.attotech.com ([12.32.232.56] helo=noteserv1.attotech.com) by ietf-mx with esmtp (Exim 4.12) id 1BJZLs-0006ap-00 for ips@ietf.org; Fri, 30 Apr 2004 10:50:56 -0400 To: ips@ietf.org Message-ID: Date: Fri, 30 Apr 2004 10:51:02 -0400 MIME-Version: 1.0 Content-type: text/plain; charset=us-ascii Subject: [Ips] Is an update to rfc3347 planned? 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 Congratulations to all for your hard work on the iSCSI rfc. Now that iSCSI is an rfc, does the WG plan on updating rfc3347? There have been a few changes and lots of experience gained implementing iSCSI since July 2002. At least we can add the correct section numbers now. Regards, Aaron _______________________________________________ Ips mailing list Ips@ietf.org https://www1.ietf.org/mailman/listinfo/ips From exim@www1.ietf.org Fri Apr 30 11:54:30 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 LAA10717 for ; Fri, 30 Apr 2004 11:54:30 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BJaD0-0005XQ-VS for ips-archive@odin.ietf.org; Fri, 30 Apr 2004 11:45:51 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i3UFjoRL021289 for ips-archive@odin.ietf.org; Fri, 30 Apr 2004 11:45:50 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BJa6w-0004St-Vi for ips-web-archive@optimus.ietf.org; Fri, 30 Apr 2004 11:39:35 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA09464 for ; Fri, 30 Apr 2004 11:39:32 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BJa6v-0002XW-Up for ips-web-archive@ietf.org; Fri, 30 Apr 2004 11:39:33 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BJa5s-0002O8-00 for ips-web-archive@ietf.org; Fri, 30 Apr 2004 11:38:30 -0400 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1BJa5C-0002JV-00 for ips-web-archive@ietf.org; Fri, 30 Apr 2004 11:37:46 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BJZze-0002nZ-Tz; Fri, 30 Apr 2004 11:32:02 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BJZs7-0001H6-7B for ips@optimus.ietf.org; Fri, 30 Apr 2004 11:24:17 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA08180 for ; Fri, 30 Apr 2004 11:24:12 -0400 (EDT) From: Black_David@emc.com Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BJZs6-00014O-4u for ips@ietf.org; Fri, 30 Apr 2004 11:24:14 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BJZrI-00011k-00 for ips@ietf.org; Fri, 30 Apr 2004 11:23:25 -0400 Received: from maho3msx2.isus.emc.com ([128.221.11.32] helo=MAHO3MSX2.corp.emc.com) by ietf-mx with esmtp (Exim 4.12) id 1BJZqZ-0000uc-00; Fri, 30 Apr 2004 11:22:39 -0400 Received: by maho3msx2.corp.emc.com with Internet Mail Service (5.5.2653.19) id ; Fri, 30 Apr 2004 11:22:09 -0400 Message-ID: To: kzm@cisco.com, rsnively@Brocade.COM Cc: ips@ietf.org, t11_5@mail.t11.org, t11_3@mail.t11.org, imss@ietf.org Subject: RE: [Ips] Proposal to remove "dynamic" port type for FcPortType Date: Fri, 30 Apr 2004 11:22:08 -0400 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 > Thanks for raising this. I believe that as editor, I do need the > WG's approval to make any additions or deletions to: > draft-ietf-ips-fcmgmt-mib-04.txt at its current stage of progress. > > So, if the WG approves the addition of these three recently-defined > new types: 'gPort', 'glPort' and 'fnlPort' as new enumerations of the > FcPortType TC, then I can go ahead and add them. With WG co-chair hat on, unless someone objects to these additions on the list, the editor should assume the that rough consensus of the ips WG is to make these additions. This is a relatively minor change (adds elements to an existing enumeration), and better aligns the MIB with Fibre Channel standards. As to the possible removal of the "dynamic" port type, the issue appears to boil down to whether a "dynamic" type is justified in addition to "other" and "unknown". Let me encourage further comments to focus on this specific issue, and I offer the following advice: - I think Keith is correct that not having a standard to reference is insufficient to remove "dynamic", as this would also entail also removing "other" and "unknown", which does not appear to be a desired outcome. - It would be useful to see an explanation of how "dynamic" improves "future proofing" over and above "other" and "unknown". I think there's rough consensus that some form of "future proofing" is needed, and the disagreement centers on whether "other" and "unknown" are sufficient. The current MIB text is: unknown(1), other(2), -- none of the below dynamic(3), -- determined dynamically where the "below" list contains N, NL, F, FL, E and B ports (and will contain G, GL and FNL ports, assuming no objections to their addition). Note that if we were to remove "dynamic", its value in the enumeration would be reserved in order to avoid renumbering other port types or accidental reuse in the future. Thanks, --David (ips WG co-chair) ---------------------------------------------------- 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 Keith McCloghrie > Sent: Thursday, April 29, 2004 6:40 PM > To: rsnively@Brocade.COM > Cc: ips@ietf.org; t11_5@mail.t11.org; t11_3@mail.t11.org; > imss@ietf.org; rsnively@Brocade.COM > Subject: Re: [Ips] Proposal to remove "dynamic" port type for > FcPortType > > > Bob, > > Thanks for raising this. I believe that as editor, I do need the > WG's approval to make any additions or deletions to: > draft-ietf-ips-fcmgmt-mib-04.txt at its current stage of progress. > > So, if the WG approves the addition of these three recently-defined > new types: 'gPort', 'glPort' and 'fnlPort' as new enumerations of the > FcPortType TC, then I can go ahead and add them. > > As regards 'dynamic': > > - it is obviously needed in the MIB's current state (to represent > G_Ports, GL_Ports and F/NL_Ports), and if the WG decided to defer the > addition of the three new types, then it would continue to be needed. > > - to characterize the retention of 'dynamic' as unnecessary "future > proofing" is to ignore history. Specifically, 'dynamic' was > defined in > the original version of the draft-ietf-ips-fcmgmt-mib, more than two > years ago, and hindsight shows us that was a smart move, because (as > I said above) it is needed in the MIB's current state, it would > continue to be needed if we deferred adding the three new types, and > there are good chances it will be needed yet again in the future, even > after we add the three new types. > > - the first of those good chances is currently being debated in T11 in > regard to (virtual-fabric) "trunking". It seems to me that while T11 > has not yet reached the stage of debating of whether "trunking" is a > characteristic of a port type, it likely is because a result of the > layer-2 negotiation (that you mention) will be the port > becoming either > a trunking port or one of the already-defined values of > FcPortType, i.e., > it's a type just like the existing ones are. The other > (non-)types you > mention are completely different because they will not be the subject > of a layer-2 negotiation, and thus I agree that those others are not > port types at layer-2 (and this is a layer-2 MIB). > > - and finally, to remove 'dynamic' because: > > There is no referent for a "dynamic" port. > > doesn't make any sense to me because there is no referent for an > "unknown port" and no referent for an "other port". Since we're not > going to throw out 'unknown' or 'other' for this reason, then neither > should we throw out 'dyanmic'. > > Thanks, > Keith. > > > > I apologize for the cross posting, but the breadth of expert > > knowledge and breadth of responsibility for this particular > > subject extends across all four reflectors. > > > > The history is: > > > > Snively: > > > > Proposed including: > > gPort > > glPort > > fnlPort > > > > Proposed removing: > > dynamic > > > > Because: > > All known "dynamic" ports are either G_Ports or > > GL_Ports (which dynamically change to F_ or E_Ports) > > or F/NL_Ports (which provides fabric services when > > no FL_Port is available). > > All other ports (if known) are "other", > > whether dynamic or not. > > > > McCloghrie: > > > > Agreed to add: > > gPort > > glPort > > fnlPort > > > > Proposed retaining: > > dynamic > > > > Because: > > There might be some future ports defined that had > > mechanisms that would select the final port type > > using previously undefined mechanisms. > > In a sense, this was a future proofing. > > > > Crandall: > > > > Proposed removing: > > dynamic > > > > Because: > > Unless some clear definition of the port were > > created or referenced in a standard, it was > > equivalent to "unknown". > > > > My final proposal would be: > > > > Remove: > > dynamic > > > > Because: > > There is no referent for a "dynamic" port. > > > > Further explanation: > > > > All Fibre Channel Ports have an associated type. That type > > is determined absolutely either by the port being set to or > > designed to be compliant with a particular type or by > > being designed as a specified type of multi-function port > > that uses a certain standard algorithm to determine which > > port type will be agreed upon. > > > > Ports with knowable types (as opposed to "unknown" types) > > that do not behave according to those rules are "other" > > and might as well be labeled as such. Future revisions > > of a MIB may add additional types to the list as new port types > > are defined or may use other mechanisms (manufacturer and model) > > to define the actual use of an "other" port until such changes > > can be made in the MIB. > > > > Note that PortType does not tell everything there is to know > > about a port. As an example, FcPortType nPort may be > implemented > > as an FCP SCSI initiator port, an FCP SCSI target port, or > > an IPv6 over SCSI port, none of which is presently > defined in the > > MIB. Similarly E_Ports may have different capabilities such > > as trunking that are not presently defined in the MIB. Many of > > these capabilities are also dynamic, requiring negotiations and > > login operations to actually enable them. However, > these capabilities > > do NOT define a different port type. > > > > I believe there are probably a number of solutions to the > > "future proofing" suggestion that do not require us to > > make up a definition for a port type. > > > > _______________________________________________ > 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 Apr 30 12: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 MAA14394 for ; Fri, 30 Apr 2004 12:57:20 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BJb92-0001oJ-WA for ips-archive@odin.ietf.org; Fri, 30 Apr 2004 12:45:49 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i3UGjmUo006954 for ips-archive@odin.ietf.org; Fri, 30 Apr 2004 12:45:48 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BJb1g-0008M2-TX for ips-web-archive@optimus.ietf.org; Fri, 30 Apr 2004 12:38:15 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA13288 for ; Fri, 30 Apr 2004 12:38:09 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BJb1f-0006j4-9j for ips-web-archive@ietf.org; Fri, 30 Apr 2004 12:38:11 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BJb0k-0006fC-00 for ips-web-archive@ietf.org; Fri, 30 Apr 2004 12:37:16 -0400 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1BJazo-0006as-00 for ips-web-archive@ietf.org; Fri, 30 Apr 2004 12:36:16 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BJaov-0005DB-6K; Fri, 30 Apr 2004 12:25:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BJaYX-00013A-6D for ips@optimus.ietf.org; Fri, 30 Apr 2004 12:08:05 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA11653 for ; Fri, 30 Apr 2004 12:08:02 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BJaYV-0004hq-My for ips@ietf.org; Fri, 30 Apr 2004 12:08:03 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BJaXY-0004bq-00 for ips@ietf.org; Fri, 30 Apr 2004 12:07:05 -0400 Received: from mcjekyll.mcdata.com ([144.49.6.25] helo=380GATE01out.mcdata.com) by ietf-mx with esmtp (Exim 4.12) id 1BJaWi-0004XR-00; Fri, 30 Apr 2004 12:06:12 -0400 Received: from 380GATE01.mcdata.com ([172.18.1.72]) by 380GATE01out.mcdata.com with Microsoft SMTPSVC(5.0.2195.6713); Fri, 30 Apr 2004 10:06:26 -0600 Received: from MC4EXCH03.mcdata.com ([172.16.11.122]) by 380GATE01 with InterScan Messaging Security Suite; Fri, 30 Apr 2004 10:06:25 -0600 X-MimeOLE: Produced By Microsoft Exchange V6.0.6375.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: RE: [T11.5] Re: [Ips] Proposal to remove "dynamic" port type for FcPortType Date: Fri, 30 Apr 2004 10:06:24 -0600 Message-ID: <95C56F83F771C041B4EC26C4DAEEC942D4B434@MC4EXCH03.mcdata.com> Thread-Topic: [T11.5] Re: [Ips] Proposal to remove "dynamic" port type for FcPortType Thread-Index: AcQuxxU67JYgezpLQYyNGB1YSjYWSgAASvkw From: "Mike O'Donnell" To: , , Cc: , , , X-OriginalArrivalTime: 30 Apr 2004 16:06:26.0161 (UTC) FILETIME=[16F5FE10:01C42ECD] 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 David, I beg to differ... >"I think Keith is correct that not having a standard to reference is > insufficient to remove "dynamic", as this would also entail > also removing "other" and "unknown", which does not appear to > be a desired outcome. "Other" and "Unknown" are (as is stated) used to indicate that (for the= case of 'other') the agent can determine the port type and it is NOT any= of those types identified in the MIB. "Unknown" indicates the agent is= unable to ascertain its type (be it any of those identified or other). It= is an accepted mechanism in MIB's to provide an agent a mechanism to= report it as such.=20 Based on the above, I don't accept the logic that because 'other' and= 'unknown' are not specified in any standard and that dynamic is ALSO not= specified in any standard then "other" an "unknown" should also be removed= from the MIB.=20 As for the use of dynamic, it is my opinion that if the specified states of= a port can be determined (and documented in the MIB), then dynamic has no= value. And, from an implementor's perspective, if dynamic is added to the= MIB, when does one report "dynamic" versus G-port, GL_port, FNL_port (or= other specified port types)? If it is to 'future-proof' the MIB, what does 'future_port_type' (aka= 'dynamic') tell me that 'other' does not? Help me understand. Maybe= someone can point to where this has been successfully implemented (not= just documented) in other MIBs so we can use this as a model for= future-proofing our FC MIB's. As an application vendor, "dynamic" doesn't= add any additional value as specified today. Mike O'Donnell =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=20 Michael E. O'Donnell=20 Director Software Architecture=20 McDATA Corporation=20 4 McDATA Parkway=20 Broomfield, Colorado 80021=20 720.558.4142 (office)=20 303.570.3631 (cel)=20 mike.o'donnell@mcdata.com=20 =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D =20 -----Original Message----- From: Black_David@emc.com [mailto:Black_David@emc.com] Sent: Friday, April 30, 2004 9:22 AM To: kzm@cisco.com; rsnively@Brocade.COM Cc: ips@ietf.org; t11_5@mail.t11.org; t11_3@mail.t11.org; imss@ietf.org Subject: [T11.5] Re: [Ips] Proposal to remove "dynamic" port type for FcPortType INCITS T11.5 Mail Reflector ******************************** > Thanks for raising this. I believe that as editor, I do need the > WG's approval to make any additions or deletions to: > draft-ietf-ips-fcmgmt-mib-04.txt at its current stage of progress. >=20 > So, if the WG approves the addition of these three recently-defined=20 > new types: 'gPort', 'glPort' and 'fnlPort' as new enumerations of the > FcPortType TC, then I can go ahead and add them. With WG co-chair hat on, unless someone objects to these additions on the list, the editor should assume the that rough consensus of the ips WG is to make these additions. This is a relatively minor change (adds elements to an existing enumeration), and better aligns the MIB with Fibre Channel standards. As to the possible removal of the "dynamic" port type, the issue appears to boil down to whether a "dynamic" type is justified in addition to "other" and "unknown". Let me encourage further comments to focus on this specific issue, and I offer the following advice: - I think Keith is correct that not having a standard to reference is insufficient to remove "dynamic", as this would also entail also removing "other" and "unknown", which does not appear to be a desired outcome. - It would be useful to see an explanation of how "dynamic" improves "future proofing" over and above "other" and "unknown". I think there's rough consensus that some form of "future proofing" is needed, and the disagreement centers on whether "other" and "unknown" are sufficient. The current MIB text is: unknown(1), other(2), -- none of the below dynamic(3), -- determined dynamically where the "below" list contains N, NL, F, FL, E and B ports (and will contain G, GL and FNL ports, assuming no objections to their addition). Note that if we were to remove "dynamic", its value in the enumeration would be reserved in order to avoid renumbering other port types or accidental reuse in the future. Thanks, --David (ips WG co-chair) ---------------------------------------------------- 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=20 > Behalf Of Keith McCloghrie > Sent: Thursday, April 29, 2004 6:40 PM > To: rsnively@Brocade.COM > Cc: ips@ietf.org; t11_5@mail.t11.org; t11_3@mail.t11.org;=20 > imss@ietf.org; rsnively@Brocade.COM > Subject: Re: [Ips] Proposal to remove "dynamic" port type for=20 > FcPortType >=20 >=20 > Bob, >=20 > Thanks for raising this. I believe that as editor, I do need the > WG's approval to make any additions or deletions to: > draft-ietf-ips-fcmgmt-mib-04.txt at its current stage of progress. >=20 > So, if the WG approves the addition of these three recently-defined=20 > new types: 'gPort', 'glPort' and 'fnlPort' as new enumerations of the > FcPortType TC, then I can go ahead and add them. >=20 > As regards 'dynamic': >=20 > - it is obviously needed in the MIB's current state (to represent > G_Ports, GL_Ports and F/NL_Ports), and if the WG decided to defer the > addition of the three new types, then it would continue to be needed. >=20 > - to characterize the retention of 'dynamic' as unnecessary "future > proofing" is to ignore history. Specifically, 'dynamic' was=20 > defined in > the original version of the draft-ietf-ips-fcmgmt-mib, more than two > years ago, and hindsight shows us that was a smart move, because (as > I said above) it is needed in the MIB's current state, it would > continue to be needed if we deferred adding the three new types, and > there are good chances it will be needed yet again in the future, even > after we add the three new types. >=20 > - the first of those good chances is currently being debated in T11 in > regard to (virtual-fabric) "trunking". It seems to me that while T11 > has not yet reached the stage of debating of whether "trunking" is a > characteristic of a port type, it likely is because a result of the > layer-2 negotiation (that you mention) will be the port=20 > becoming either > a trunking port or one of the already-defined values of=20 > FcPortType, i.e., > it's a type just like the existing ones are. The other=20 > (non-)types you > mention are completely different because they will not be the subject > of a layer-2 negotiation, and thus I agree that those others are not > port types at layer-2 (and this is a layer-2 MIB). >=20 > - and finally, to remove 'dynamic' because: >=20 > There is no referent for a "dynamic" port. >=20 > doesn't make any sense to me because there is no referent for an > "unknown port" and no referent for an "other port". Since we're not > going to throw out 'unknown' or 'other' for this reason, then neither > should we throw out 'dyanmic'. >=20 > Thanks, > Keith. >=20 >=20 > > I apologize for the cross posting, but the breadth of expert > > knowledge and breadth of responsibility for this particular=20 > > subject extends across all four reflectors. > >=20 > > The history is: > >=20 > > Snively: > >=20 > > Proposed including: > > gPort > > glPort > > fnlPort > >=20 > > Proposed removing: > > dynamic > >=20 > > Because: > > All known "dynamic" ports are either G_Ports or > > GL_Ports (which dynamically change to F_ or E_Ports) > > or F/NL_Ports (which provides fabric services when > > no FL_Port is available). > > All other ports (if known) are "other",=20 > > whether dynamic or not. > >=20 > > McCloghrie: > >=20 > > Agreed to add: > > gPort > > glPort > > fnlPort > > =09 > > Proposed retaining: > > dynamic > >=20 > > Because: > > There might be some future ports defined that had > > mechanisms that would select the final port type > > using previously undefined mechanisms. > > In a sense, this was a future proofing. > >=20 > > Crandall: > >=20 > > Proposed removing: > > dynamic > >=20 > > Because: > > Unless some clear definition of the port were > > created or referenced in a standard, it was > > equivalent to "unknown". > >=20 > > My final proposal would be: > >=20 > > Remove: > > dynamic > >=20 > > Because: > > There is no referent for a "dynamic" port. =20 > >=20 > > Further explanation: > >=20 > > All Fibre Channel Ports have an associated type. That type > > is determined absolutely either by the port being set to or=20 > > designed to be compliant with a particular type or by=20 > > being designed as a specified type of multi-function port > > that uses a certain standard algorithm to determine which > > port type will be agreed upon. > >=20 > > Ports with knowable types (as opposed to "unknown" types)=20 > > that do not behave according to those rules are "other" > > and might as well be labeled as such. Future revisions > > of a MIB may add additional types to the list as new port types > > are defined or may use other mechanisms (manufacturer and model) > > to define the actual use of an "other" port until such changes > > can be made in the MIB. > > > > Note that PortType does not tell everything there is to know > > about a port. As an example, FcPortType nPort may be=20 > implemented > > as an FCP SCSI initiator port, an FCP SCSI target port, or > > an IPv6 over SCSI port, none of which is presently=20 > defined in the > > MIB. Similarly E_Ports may have different capabilities such > > as trunking that are not presently defined in the MIB. Many of > > these capabilities are also dynamic, requiring negotiations and > > login operations to actually enable them. However,=20 > these capabilities > > do NOT define a different port type. =20 > >=20 > > I believe there are probably a number of solutions to the > > "future proofing" suggestion that do not require us to > > make up a definition for a port type. > >=20 >=20 > _______________________________________________ > Ips mailing list > Ips@ietf.org > https://www1.ietf.org/mailman/listinfo/ips >=20 To Unsubscribe: mailto:t11_5-request@mail.t11.org?subject=3Dunsubscribe SPECIAL NOTICE=20 All information transmitted hereby is intended only for the use of the=20 addressee(s) named above and may contain confidential and privileged=20 information. Any unauthorized review, use, disclosure or distribution of confidential and privileged information is prohibited. If the reader of this message is not the intended recipient(s) or the employee or agent=20 responsible for delivering the message to the intended recipient, you are hereby notified that you must not read this transmission and that disclosure, copying, printing, distribution or use of any of the information contained in or attached to this transmission is STRICTLY=20 PROHIBITED. Anyone who receives confidential and privileged information in error should= =20 notify us immediately by telephone and mail the original message to us at= the above address and destroy all copies. To the extent any portion of this communication contains public information, no such restrictions=20 apply to that information. (gate01) _______________________________________________ Ips mailing list Ips@ietf.org https://www1.ietf.org/mailman/listinfo/ips From exim@www1.ietf.org Fri Apr 30 13:28:20 2004 Received: from optimus.ietf.org (www.iesg.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA16722 for ; Fri, 30 Apr 2004 13:28:20 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BJbjk-0000Nl-7S for ips-archive@odin.ietf.org; Fri, 30 Apr 2004 13:23:44 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i3UHNiJU001469 for ips-archive@odin.ietf.org; Fri, 30 Apr 2004 13:23:44 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BJbgG-0008E6-1L for ips-web-archive@optimus.ietf.org; Fri, 30 Apr 2004 13:20:08 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA15885 for ; Fri, 30 Apr 2004 13:20:04 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BJbgE-00024e-30 for ips-web-archive@ietf.org; Fri, 30 Apr 2004 13:20:06 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BJbfG-00021a-00 for ips-web-archive@ietf.org; Fri, 30 Apr 2004 13:19:07 -0400 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1BJbeP-0001zA-00 for ips-web-archive@ietf.org; Fri, 30 Apr 2004 13:18:13 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BJbXS-0006el-2V; Fri, 30 Apr 2004 13:11:02 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BJbMw-0004KD-Nf for ips@optimus.ietf.org; Fri, 30 Apr 2004 13:00:10 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA14545 for ; Fri, 30 Apr 2004 13:00:06 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BJbMu-0000aX-QN for ips@ietf.org; Fri, 30 Apr 2004 13:00:08 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BJbLz-0000US-00 for ips@ietf.org; Fri, 30 Apr 2004 12:59:12 -0400 Received: from f112.brocade.com ([66.243.153.112] helo=blasphemy.brocade.com) by ietf-mx with esmtp (Exim 4.12) id 1BJbL1-0000Ni-00; Fri, 30 Apr 2004 12:58:11 -0400 Received: from hq-ex-11.corp.brocade.com (hq-ex-11 [192.168.38.58]) by blasphemy.brocade.com (Postfix) with ESMTP id 2CB5F14149; Fri, 30 Apr 2004 09:57:37 -0700 (PDT) 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] Proposal to remove "dynamic" port type for FcPortType Date: Fri, 30 Apr 2004 09:57:36 -0700 Message-ID: <191DA4FAE235D24C9BCC8D50F6B17AB90933BB@hq-ex-11.brocade.com> Thread-Topic: [Ips] Proposal to remove "dynamic" port type for FcPortType Thread-Index: AcQuOx+GC/+RQNvqQdyVzSqSoeq/mwAlphFw From: "Robert Snively" To: "Keith McCloghrie" 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 Using David Black's consensus call, I will focus on=20 the "dynamic" question. I am in agreement with Mike O'Donnell's=20 analysis of "unknown" and "other". I support his conclusions on "dynamic" (i.e. that it should be removed as a port type). Keith McLoughrie indicates that dynamic is useful for future proofing. I believe that the most effective mechanism for future proofing would be to remove "dynamic" as a type, then provide a certain number of pre-specified type values for future assignment by INCITS TC T11 standards. That way, the MIB can remain unchanged and the values be picked up by future T11 standards if they are ever required. The number of such values should be small, since any large number of future variants would probably require modification to the MIB anyway. That allows both for future definition of ports with a=20 negotiation algorithm and ports with a pre-established=20 fixed type, something that "dynamic" does not. Robert Snively Brocade Communications Systems, Inc. 1745 Technology Drive San Jose, CA 95110 +1 408 333 8135 rsnively@brocade.com=20 _______________________________________________ Ips mailing list Ips@ietf.org https://www1.ietf.org/mailman/listinfo/ips From exim@www1.ietf.org Fri Apr 30 15:15:30 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 PAA24021 for ; Fri, 30 Apr 2004 15:15:29 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BJdPO-00067f-Aw for ips-archive@odin.ietf.org; Fri, 30 Apr 2004 15:11:04 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i3UJAoOh023526 for ips-archive@odin.ietf.org; Fri, 30 Apr 2004 15:10:50 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BJd7R-0006bH-B7 for ips-web-archive@optimus.ietf.org; Fri, 30 Apr 2004 14:52:17 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA22066 for ; Fri, 30 Apr 2004 14:52:12 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BJd7O-0001xn-Kr for ips-web-archive@ietf.org; Fri, 30 Apr 2004 14:52:14 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BJd6X-0001t9-00 for ips-web-archive@ietf.org; Fri, 30 Apr 2004 14:51:22 -0400 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1BJd5b-0001ok-00 for ips-web-archive@ietf.org; Fri, 30 Apr 2004 14:50:23 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BJd0P-0005J8-Li; Fri, 30 Apr 2004 14:45:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BJcxf-0004ig-Ts for ips@optimus.ietf.org; Fri, 30 Apr 2004 14:42:12 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA21489 for ; Fri, 30 Apr 2004 14:42:06 -0400 (EDT) From: Black_David@emc.com Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BJcxd-000104-3z for ips@ietf.org; Fri, 30 Apr 2004 14:42:09 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BJcwe-0000vP-00 for ips@ietf.org; Fri, 30 Apr 2004 14:41:09 -0400 Received: from maho3msx2.isus.emc.com ([128.221.11.32] helo=MAHO3MSX2.corp.emc.com) by ietf-mx with esmtp (Exim 4.12) id 1BJcvg-0000nC-00; Fri, 30 Apr 2004 14:40:08 -0400 Received: by maho3msx2.corp.emc.com with Internet Mail Service (5.5.2653.19) id ; Fri, 30 Apr 2004 14:39:25 -0400 Message-ID: To: mike.o'donnell@mcdata.com, Black_David@emc.com, kzm@cisco.com, rsnively@Brocade.COM Cc: ips@ietf.org, t11_5@mail.t11.org, t11_3@mail.t11.org, imss@ietf.org Subject: RE: [T11.5] Re: [Ips] Proposal to remove "dynamic" port type for FcPortType Date: Fri, 30 Apr 2004 14:39:22 -0400 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.4 required=5.0 tests=AWL,NO_REAL_NAME,OFFERS_ETC autolearn=no version=2.60 Mike, I'm trying not to take sides in this discussion. From your message, I understand your view to be that "unknown" and "other" are sufficient to cover all the cases in which the port type is not one of the specific values in the enumeration (N, NL, F, etc.), and hence that "dynamic" should not be part of that enumeration. Consider that view noted. Someone who is in favor of "dynamic" will need to address your question about how it improves future-proofing. 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: Mike O'Donnell [mailto:mike.o'donnell@mcdata.com] > Sent: Friday, April 30, 2004 12:06 PM > To: Black_David@emc.com; kzm@cisco.com; rsnively@Brocade.COM > Cc: ips@ietf.org; t11_5@mail.t11.org; t11_3@mail.t11.org; > imss@ietf.org > Subject: RE: [T11.5] Re: [Ips] Proposal to remove "dynamic" > port type for FcPortType > > > > David, > > I beg to differ... > > >"I think Keith is correct that not having a standard to reference is > > insufficient to remove "dynamic", as this would also entail > > also removing "other" and "unknown", which does not appear to > > be a desired outcome. > > "Other" and "Unknown" are (as is stated) used to indicate > that (for the case of 'other') the agent can determine the > port type and it is NOT any of those types identified in the > MIB. "Unknown" indicates the agent is unable to ascertain > its type (be it any of those identified or other). It is an > accepted mechanism in MIB's to provide an agent a mechanism > to report it as such. > > Based on the above, I don't accept the logic that because > 'other' and 'unknown' are not specified in any standard and > that dynamic is ALSO not specified in any standard then > "other" an "unknown" should also be removed from the MIB. > > As for the use of dynamic, it is my opinion that if the > specified states of a port can be determined (and documented > in the MIB), then dynamic has no value. And, from an > implementor's perspective, if dynamic is added to the MIB, > when does one report "dynamic" versus G-port, GL_port, > FNL_port (or other specified port types)? > > If it is to 'future-proof' the MIB, what does > 'future_port_type' (aka 'dynamic') tell me that 'other' does > not? Help me understand. Maybe someone can point to where > this has been successfully implemented (not just documented) > in other MIBs so we can use this as a model for > future-proofing our FC MIB's. As an application vendor, > "dynamic" doesn't add any additional value as specified today. > > Mike O'Donnell > > ====================== > Michael E. O'Donnell > Director Software Architecture > McDATA Corporation > 4 McDATA Parkway > Broomfield, Colorado 80021 > 720.558.4142 (office) > 303.570.3631 (cel) > mike.o'donnell@mcdata.com > ====================== > > > > > > > -----Original Message----- > From: Black_David@emc.com [mailto:Black_David@emc.com] > Sent: Friday, April 30, 2004 9:22 AM > To: kzm@cisco.com; rsnively@Brocade.COM > Cc: ips@ietf.org; t11_5@mail.t11.org; t11_3@mail.t11.org; > imss@ietf.org > Subject: [T11.5] Re: [Ips] Proposal to remove "dynamic" port type for > FcPortType > > > INCITS T11.5 Mail Reflector > ******************************** > > > Thanks for raising this. I believe that as editor, I do need the > > WG's approval to make any additions or deletions to: > > draft-ietf-ips-fcmgmt-mib-04.txt at its current stage of progress. > > > > So, if the WG approves the addition of these three recently-defined > > new types: 'gPort', 'glPort' and 'fnlPort' as new > enumerations of the > > FcPortType TC, then I can go ahead and add them. > > With WG co-chair hat on, unless someone objects to these additions > on the list, the editor should assume the that rough consensus of the > ips WG is to make these additions. This is a relatively minor change > (adds elements to an existing enumeration), and better aligns the MIB > with Fibre Channel standards. > > As to the possible removal of the "dynamic" port type, the > issue appears > to boil down to whether a "dynamic" type is justified in addition to > "other" and "unknown". Let me encourage further comments to focus on > this specific issue, and I offer the following advice: > > - I think Keith is correct that not having a standard to reference is > insufficient to remove "dynamic", as this would also entail > also removing "other" and "unknown", which does not appear to > be a desired outcome. > - It would be useful to see an explanation of how "dynamic" improves > "future proofing" over and above "other" and "unknown". I think > there's rough consensus that some form of "future proofing" is > needed, and the disagreement centers on whether "other" and > "unknown" are sufficient. > > The current MIB text is: > unknown(1), > other(2), -- none of the below > dynamic(3), -- determined dynamically > where the "below" list contains N, NL, F, FL, E and B ports (and will > contain G, GL and FNL ports, assuming no objections to their > addition). > > Note that if we were to remove "dynamic", its value in the > enumeration would be reserved in order to avoid renumbering > other port types or accidental reuse in the future. > > Thanks, > --David (ips WG co-chair) > ---------------------------------------------------- > 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 Keith McCloghrie > > Sent: Thursday, April 29, 2004 6:40 PM > > To: rsnively@Brocade.COM > > Cc: ips@ietf.org; t11_5@mail.t11.org; t11_3@mail.t11.org; > > imss@ietf.org; rsnively@Brocade.COM > > Subject: Re: [Ips] Proposal to remove "dynamic" port type for > > FcPortType > > > > > > Bob, > > > > Thanks for raising this. I believe that as editor, I do need the > > WG's approval to make any additions or deletions to: > > draft-ietf-ips-fcmgmt-mib-04.txt at its current stage of progress. > > > > So, if the WG approves the addition of these three recently-defined > > new types: 'gPort', 'glPort' and 'fnlPort' as new > enumerations of the > > FcPortType TC, then I can go ahead and add them. > > > > As regards 'dynamic': > > > > - it is obviously needed in the MIB's current state (to represent > > G_Ports, GL_Ports and F/NL_Ports), and if the WG decided to > defer the > > addition of the three new types, then it would continue to > be needed. > > > > - to characterize the retention of 'dynamic' as unnecessary "future > > proofing" is to ignore history. Specifically, 'dynamic' was > > defined in > > the original version of the draft-ietf-ips-fcmgmt-mib, more than two > > years ago, and hindsight shows us that was a smart move, because (as > > I said above) it is needed in the MIB's current state, it would > > continue to be needed if we deferred adding the three new types, and > > there are good chances it will be needed yet again in the > future, even > > after we add the three new types. > > > > - the first of those good chances is currently being > debated in T11 in > > regard to (virtual-fabric) "trunking". It seems to me that > while T11 > > has not yet reached the stage of debating of whether "trunking" is a > > characteristic of a port type, it likely is because a result of the > > layer-2 negotiation (that you mention) will be the port > > becoming either > > a trunking port or one of the already-defined values of > > FcPortType, i.e., > > it's a type just like the existing ones are. The other > > (non-)types you > > mention are completely different because they will not be > the subject > > of a layer-2 negotiation, and thus I agree that those others are not > > port types at layer-2 (and this is a layer-2 MIB). > > > > - and finally, to remove 'dynamic' because: > > > > There is no referent for a "dynamic" port. > > > > doesn't make any sense to me because there is no referent for an > > "unknown port" and no referent for an "other port". Since we're not > > going to throw out 'unknown' or 'other' for this reason, > then neither > > should we throw out 'dyanmic'. > > > > Thanks, > > Keith. > > > > > > > I apologize for the cross posting, but the breadth of expert > > > knowledge and breadth of responsibility for this particular > > > subject extends across all four reflectors. > > > > > > The history is: > > > > > > Snively: > > > > > > Proposed including: > > > gPort > > > glPort > > > fnlPort > > > > > > Proposed removing: > > > dynamic > > > > > > Because: > > > All known "dynamic" ports are either G_Ports or > > > GL_Ports (which dynamically change to F_ or E_Ports) > > > or F/NL_Ports (which provides fabric services when > > > no FL_Port is available). > > > All other ports (if known) are "other", > > > whether dynamic or not. > > > > > > McCloghrie: > > > > > > Agreed to add: > > > gPort > > > glPort > > > fnlPort > > > > > > Proposed retaining: > > > dynamic > > > > > > Because: > > > There might be some future ports defined that had > > > mechanisms that would select the final port type > > > using previously undefined mechanisms. > > > In a sense, this was a future proofing. > > > > > > Crandall: > > > > > > Proposed removing: > > > dynamic > > > > > > Because: > > > Unless some clear definition of the port were > > > created or referenced in a standard, it was > > > equivalent to "unknown". > > > > > > My final proposal would be: > > > > > > Remove: > > > dynamic > > > > > > Because: > > > There is no referent for a "dynamic" port. > > > > > > Further explanation: > > > > > > All Fibre Channel Ports have an associated type. That type > > > is determined absolutely either by the port being set to or > > > designed to be compliant with a particular type or by > > > being designed as a specified type of multi-function port > > > that uses a certain standard algorithm to determine which > > > port type will be agreed upon. > > > > > > Ports with knowable types (as opposed to "unknown" types) > > > that do not behave according to those rules are "other" > > > and might as well be labeled as such. Future revisions > > > of a MIB may add additional types to the list as new port types > > > are defined or may use other mechanisms (manufacturer and model) > > > to define the actual use of an "other" port until such changes > > > can be made in the MIB. > > > > > > Note that PortType does not tell everything there is to know > > > about a port. As an example, FcPortType nPort may be > > implemented > > > as an FCP SCSI initiator port, an FCP SCSI target port, or > > > an IPv6 over SCSI port, none of which is presently > > defined in the > > > MIB. Similarly E_Ports may have different capabilities such > > > as trunking that are not presently defined in the MIB. Many of > > > these capabilities are also dynamic, requiring negotiations and > > > login operations to actually enable them. However, > > these capabilities > > > do NOT define a different port type. > > > > > > I believe there are probably a number of solutions to the > > > "future proofing" suggestion that do not require us to > > > make up a definition for a port type. > > > > > > > _______________________________________________ > > Ips mailing list > > Ips@ietf.org > > https://www1.ietf.org/mailman/listinfo/ips > > > > > To Unsubscribe: > mailto:t11_5-request@mail.t11.org?subject=unsubscribe > > > SPECIAL NOTICE > > All information transmitted hereby is intended only for the > use of the > addressee(s) named above and may contain confidential and privileged > information. Any unauthorized review, use, disclosure or distribution > of confidential and privileged information is prohibited. If > the reader of > this message is not the intended recipient(s) or the employee > or agent > responsible for delivering the message to the intended recipient, you > are hereby notified that you must not read this transmission and that > disclosure, copying, printing, distribution or use of any of the > information contained in or attached to this transmission is STRICTLY > PROHIBITED. > > Anyone who receives confidential and privileged information > in error should > notify us immediately by telephone and mail the original > message to us at the > above address and destroy all copies. To the extent any > portion of this > communication contains public information, no such restrictions > apply to that information. (gate01) > _______________________________________________ Ips mailing list Ips@ietf.org https://www1.ietf.org/mailman/listinfo/ips From exim@www1.ietf.org Fri Apr 30 15:19:40 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 PAA24500 for ; Fri, 30 Apr 2004 15:19:40 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BJdQ3-0006PY-Q2 for ips-archive@odin.ietf.org; Fri, 30 Apr 2004 15:11:36 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i3UJBVH7024639 for ips-archive@odin.ietf.org; Fri, 30 Apr 2004 15:11:31 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BJd9W-0006z6-MM for ips-web-archive@optimus.ietf.org; Fri, 30 Apr 2004 14:54:26 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA22207 for ; Fri, 30 Apr 2004 14:54:21 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BJd9T-00029E-Uc for ips-web-archive@ietf.org; Fri, 30 Apr 2004 14:54:23 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BJd8a-00024p-00 for ips-web-archive@ietf.org; Fri, 30 Apr 2004 14:53:29 -0400 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1BJd8A-0001ze-00 for ips-web-archive@ietf.org; Fri, 30 Apr 2004 14:53:02 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BJd0S-0005Jg-Gt; Fri, 30 Apr 2004 14:45:04 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BJcyl-0004sr-6T for ips@optimus.ietf.org; Fri, 30 Apr 2004 14:43:19 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA21530 for ; Fri, 30 Apr 2004 14:43:14 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BJcyi-00016v-F7 for ips@ietf.org; Fri, 30 Apr 2004 14:43:16 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BJcxk-00011N-00 for ips@ietf.org; Fri, 30 Apr 2004 14:42:17 -0400 Received: from rtp-iport-2.cisco.com ([64.102.122.149]) by ietf-mx with esmtp (Exim 4.12) id 1BJcwp-0000t3-00 for ips@ietf.org; Fri, 30 Apr 2004 14:41:19 -0400 Received: from rtp-core-2.cisco.com (64.102.124.13) by rtp-iport-2.cisco.com with ESMTP; 30 Apr 2004 11:38:36 -0700 X-BrightmailFiltered: true Received: from cisco.com (mbakke-lnx2.cisco.com [64.101.211.59]) by rtp-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id i3UIecpI015536; Fri, 30 Apr 2004 14:40:38 -0400 (EDT) Message-ID: <40929DA5.2070207@cisco.com> Date: Fri, 30 Apr 2004 13:40:37 -0500 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: Mark Bakke CC: William Studenmund , IPS , Josh Tseng Subject: Re: [Ips] New iscsi-slp draft References: <20040417035358.26558.qmail@web21323.mail.yahoo.com> <4083DCB2.2010203@cisco.com> <13DAC1DE-921F-11D8-BB10-000A95D14BEC@wasabisystems.com> <408401E9.2020707@cisco.com> In-Reply-To: <408401E9.2020707@cisco.com> 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've just submitted iscsi-slp-08 with the changes; it is available at: ftp://ftpeng.cisco.com/mbakke/ips/iscsi/draft-ietf-ips-iscsi-slp-08.txt -- Mark Mark Bakke wrote: > OK; I like that better. I'll send an 08 (with this plus David's > implement vs used > changes) later today. > > -- > Mark > > William Studenmund wrote: > >> On Apr 19, 2004, at 7:05 AM, Mark Bakke wrote: >> >>> Makes sense; I had seen the original email, then saw a (I think) >>> later one >>> that said we didn't need it. >>> >>> What should I call the field? How about: >>> >>> server-priority = integer >>> # The priority a client should give this server, when choosing >>> # between multiple servers with the same protocol type. >>> # When multiple servers are discovered for a given protocol type, >>> # the client should (must?) use the server with the highest (lowest?) >>> # server-priority value. >>> >>> Is the above description adequate? Do we want "should" or "must" >>> in the last sentence? Should it be "highest" or "lowest"? >> >> >> >> How about: >> >> # The priority a client should give this server, when choosing >> # between multiple servers with the same protocol type. >> # When multiple servers are discovered for a given protocol type, >> # this parameter indicates their relative precedence. Server >> # precedence is protocol-specific; for some protocols, the primary >> # server may have the highest server-priority value, while for >> # others it may have the lowest. For example, with iSNS, the primary >> # server has the lowest value (value 0). >> >> I'm trying to get at: 1) different protocols may have different server >> priority values already, and this field should map to that. 2) Exactly >> what a client does with multiple servers is protocol-specific (we >> should leave it alone in this spec). 3) We need to say somewhere >> what iSNS does. As this document serves as the SLP definition for >> iSNS, I figured this is the best place to mention it. >> >> I expect that any sms protocol other than iSNS will have a separate, >> follow-on document that indicates what its protocol is, its transports, >> and how to use this field. >> >> Take care, >> >> Bill > > > > > _______________________________________________ > 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 Apr 30 15:44:18 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 PAA26100 for ; Fri, 30 Apr 2004 15:44:18 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BJdnX-0004Tx-S5 for ips-archive@odin.ietf.org; Fri, 30 Apr 2004 15:35:52 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i3UJZlN7017230 for ips-archive@odin.ietf.org; Fri, 30 Apr 2004 15:35:47 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BJdfF-0002r0-35 for ips-web-archive@optimus.ietf.org; Fri, 30 Apr 2004 15:27:13 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA24818 for ; Fri, 30 Apr 2004 15:27:09 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BJdfD-0004fh-Qs for ips-web-archive@ietf.org; Fri, 30 Apr 2004 15:27:11 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BJdeJ-0004cT-00 for ips-web-archive@ietf.org; Fri, 30 Apr 2004 15:26:15 -0400 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1BJddr-0004ZD-00 for ips-web-archive@ietf.org; Fri, 30 Apr 2004 15:25:47 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BJdSU-0007O5-4X; Fri, 30 Apr 2004 15:14:02 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BJdJy-0003tq-M7 for ips@optimus.ietf.org; Fri, 30 Apr 2004 15:05:14 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA22730 for ; Fri, 30 Apr 2004 15:05:09 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BJdJv-0002ot-FJ for ips@ietf.org; Fri, 30 Apr 2004 15:05:11 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BJdIw-0002kf-00 for ips@ietf.org; Fri, 30 Apr 2004 15:04:11 -0400 Received: from mononoke.wasabisystems.com ([151.199.66.145]) by ietf-mx with esmtp (Exim 4.12) id 1BJdI5-0002gx-00 for ips@ietf.org; Fri, 30 Apr 2004 15:03:17 -0400 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 9273040142; Fri, 30 Apr 2004 15:03:16 -0400 (EDT) In-Reply-To: <40929DA5.2070207@cisco.com> References: <20040417035358.26558.qmail@web21323.mail.yahoo.com> <4083DCB2.2010203@cisco.com> <13DAC1DE-921F-11D8-BB10-000A95D14BEC@wasabisystems.com> <408401E9.2020707@cisco.com> <40929DA5.2070207@cisco.com> Mime-Version: 1.0 (Apple Message framework v613) Content-Type: multipart/signed; protocol="application/pgp-signature"; micalg=pgp-sha1; boundary="Apple-Mail-2--182110844" Message-Id: <04506B82-9AD9-11D8-A1CF-000A95D14BEC@wasabisystems.com> Content-Transfer-Encoding: 7bit Cc: IPS , Josh Tseng From: William Studenmund Subject: Re: [Ips] New iscsi-slp draft Date: Fri, 30 Apr 2004 12:03:07 -0700 To: Mark Bakke 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-2--182110844 Content-Type: text/plain; charset=US-ASCII; format=flowed Content-Transfer-Encoding: 7bit On Apr 30, 2004, at 11:40 AM, Mark Bakke wrote: > I've just submitted iscsi-slp-08 with the changes; it is available at: > > ftp://ftpeng.cisco.com/mbakke/ips/iscsi/draft-ietf-ips-iscsi-slp-08.txt I quickly scanned it, looking at the changes regarding sms support. Looks good, though I was a bit confused by one bit: transports = string M L tcp # This is a list of transport protocols that the registered # entity supports. tcp, udp Is the first 'tcp' a typo? Take care, Bill --Apple-Mail-2--182110844 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) iD8DBQFAkqLzDJT2Egh26K0RAuawAKCAe0+mG3h2ZEMHYDpmBgdvIAMLwACfc8q1 LtZleMFzAv+kN2xOmtxarlU= =b9aF -----END PGP SIGNATURE----- --Apple-Mail-2--182110844-- _______________________________________________ Ips mailing list Ips@ietf.org https://www1.ietf.org/mailman/listinfo/ips From exim@www1.ietf.org Fri Apr 30 16:04:44 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 QAA27510 for ; Fri, 30 Apr 2004 16:04:44 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BJe5p-0002yb-Tr for ips-archive@odin.ietf.org; Fri, 30 Apr 2004 15:54:42 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i3UJsfJX011423 for ips-archive@odin.ietf.org; Fri, 30 Apr 2004 15:54:41 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BJdvH-0006rO-00 for ips-web-archive@optimus.ietf.org; Fri, 30 Apr 2004 15:43:47 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA26035 for ; Fri, 30 Apr 2004 15:43:42 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BJdvF-0006Fx-Ev for ips-web-archive@ietf.org; Fri, 30 Apr 2004 15:43:45 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BJduE-00068V-00 for ips-web-archive@ietf.org; Fri, 30 Apr 2004 15:42:43 -0400 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1BJdtU-000622-00 for ips-web-archive@ietf.org; Fri, 30 Apr 2004 15:41:56 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BJdks-0003k3-1W; Fri, 30 Apr 2004 15:33:02 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BJdWi-0000FE-P1 for ips@optimus.ietf.org; Fri, 30 Apr 2004 15:18:24 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA24378 for ; Fri, 30 Apr 2004 15:18:20 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BJdWh-00040E-Cq for ips@ietf.org; Fri, 30 Apr 2004 15:18:23 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BJdVj-0003w4-00 for ips@ietf.org; Fri, 30 Apr 2004 15:17:23 -0400 Received: from rtp-iport-1.cisco.com ([64.102.122.148]) by ietf-mx with esmtp (Exim 4.12) id 1BJdV6-0003pi-00 for ips@ietf.org; Fri, 30 Apr 2004 15:16:44 -0400 Received: from rtp-core-1.cisco.com (64.102.124.12) by rtp-iport-1.cisco.com with ESMTP; 30 Apr 2004 12:17:37 -0700 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 i3UJG8Yu014279; Fri, 30 Apr 2004 15:16:10 -0400 (EDT) Message-ID: <4092A5F8.8070009@cisco.com> Date: Fri, 30 Apr 2004 14:16:08 -0500 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: William Studenmund CC: IPS , Josh Tseng Subject: Re: [Ips] New iscsi-slp draft References: <20040417035358.26558.qmail@web21323.mail.yahoo.com> <4083DCB2.2010203@cisco.com> <13DAC1DE-921F-11D8-BB10-000A95D14BEC@wasabisystems.com> <408401E9.2020707@cisco.com> <40929DA5.2070207@cisco.com> <04506B82-9AD9-11D8-A1CF-000A95D14BEC@wasabisystems.com> In-Reply-To: <04506B82-9AD9-11D8-A1CF-000A95D14BEC@wasabisystems.com> 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 Bill- It's not a typo; the line right after the definition is the default to use if nothing is returned. The line after the description is the set of possible literal values. -- Mark William Studenmund wrote: > On Apr 30, 2004, at 11:40 AM, Mark Bakke wrote: > >> I've just submitted iscsi-slp-08 with the changes; it is available at: >> >> ftp://ftpeng.cisco.com/mbakke/ips/iscsi/draft-ietf-ips-iscsi-slp-08.txt > > > I quickly scanned it, looking at the changes regarding sms support. > > Looks good, though I was a bit confused by one bit: > > > transports = string M L > tcp > # This is a list of transport protocols that the registered > # entity supports. > tcp, udp > > Is the first 'tcp' a typo? > > Take care, > > Bill _______________________________________________ Ips mailing list Ips@ietf.org https://www1.ietf.org/mailman/listinfo/ips From exim@www1.ietf.org Fri Apr 30 17:37:13 2004 Received: from optimus.ietf.org (iesg.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA05687 for ; Fri, 30 Apr 2004 17:37:13 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BJfZ6-00061r-Pf for ips-archive@odin.ietf.org; Fri, 30 Apr 2004 17:29:00 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i3ULT0cc023171 for ips-archive@odin.ietf.org; Fri, 30 Apr 2004 17:29:00 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BJfPq-0003Et-Cv for ips-web-archive@optimus.ietf.org; Fri, 30 Apr 2004 17:19:27 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA04039 for ; Fri, 30 Apr 2004 17:19:23 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BJfPo-0002z8-3y for ips-web-archive@ietf.org; Fri, 30 Apr 2004 17:19:24 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BJfMU-0002X8-00 for ips-web-archive@ietf.org; Fri, 30 Apr 2004 17:15:59 -0400 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1BJfKr-0002AK-00 for ips-web-archive@ietf.org; Fri, 30 Apr 2004 17:14:17 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BJf74-0004Yc-Bg; Fri, 30 Apr 2004 17:00:02 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BJeAF-0003be-CW for ips@optimus.ietf.org; Fri, 30 Apr 2004 15:59:15 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA27287 for ; Fri, 30 Apr 2004 15:59:11 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BJeAD-00003n-QJ for ips@ietf.org; Fri, 30 Apr 2004 15:59:13 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BJe9L-0007nj-00 for ips@ietf.org; Fri, 30 Apr 2004 15:58:20 -0400 Received: from mononoke.wasabisystems.com ([151.199.66.145]) by ietf-mx with esmtp (Exim 4.12) id 1BJe8X-0007j2-00 for ips@ietf.org; Fri, 30 Apr 2004 15:57:29 -0400 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 650A740142; Fri, 30 Apr 2004 15:57:25 -0400 (EDT) In-Reply-To: <4092A5F8.8070009@cisco.com> References: <20040417035358.26558.qmail@web21323.mail.yahoo.com> <4083DCB2.2010203@cisco.com> <13DAC1DE-921F-11D8-BB10-000A95D14BEC@wasabisystems.com> <408401E9.2020707@cisco.com> <40929DA5.2070207@cisco.com> <04506B82-9AD9-11D8-A1CF-000A95D14BEC@wasabisystems.com> <4092A5F8.8070009@cisco.com> Mime-Version: 1.0 (Apple Message framework v613) Content-Type: multipart/signed; protocol="application/pgp-signature"; micalg=pgp-sha1; boundary="Apple-Mail-4--178863958" Message-Id: <939EA3B8-9AE0-11D8-A1CF-000A95D14BEC@wasabisystems.com> Content-Transfer-Encoding: 7bit Cc: IPS , Josh Tseng From: William Studenmund Subject: Re: [Ips] New iscsi-slp draft Date: Fri, 30 Apr 2004 12:57:14 -0700 To: Mark Bakke 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--178863958 Content-Type: text/plain; charset=US-ASCII; format=flowed Content-Transfer-Encoding: 7bit On Apr 30, 2004, at 12:16 PM, Mark Bakke wrote: > Bill- > > It's not a typo; the line right after the definition is the default to > use > if nothing is returned. The line after the description is the set of > possible literal values. Ok! Take care, Bill --Apple-Mail-4--178863958 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) iD8DBQFAkq+hDJT2Egh26K0RApaCAJ0TN900FfPY8Vxb8ytANeaQLM6BugCgi6wc ea6MmPWUYCxgJYHBCxV8Z8E= =3RP5 -----END PGP SIGNATURE----- --Apple-Mail-4--178863958-- _______________________________________________ Ips mailing list Ips@ietf.org https://www1.ietf.org/mailman/listinfo/ips From exim@www1.ietf.org Fri Apr 30 18:11:53 2004 Received: from optimus.ietf.org (www.iesg.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA08636 for ; Fri, 30 Apr 2004 18:11:53 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BJg6q-0000QQ-Io for ips-archive@odin.ietf.org; Fri, 30 Apr 2004 18:03:52 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i3UM3qTg001635 for ips-archive@odin.ietf.org; Fri, 30 Apr 2004 18:03:52 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BJg3i-0005xb-0X for ips-web-archive@optimus.ietf.org; Fri, 30 Apr 2004 18:00:38 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA07349 for ; Fri, 30 Apr 2004 18:00:34 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BJg3f-0007nL-AW for ips-web-archive@ietf.org; Fri, 30 Apr 2004 18:00:35 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BJg2g-0007g0-00 for ips-web-archive@ietf.org; Fri, 30 Apr 2004 17:59:35 -0400 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1BJg20-0007Zz-00 for ips-web-archive@ietf.org; Fri, 30 Apr 2004 17:58:52 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BJfrV-0003FC-6M; Fri, 30 Apr 2004 17:48:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BJKgB-0006GN-J5 for ips@optimus.ietf.org; Thu, 29 Apr 2004 19:10:55 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA09744 for ; Thu, 29 Apr 2004 19:10:48 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BJKg3-0006rx-0Y for ips@ietf.org; Thu, 29 Apr 2004 19:10:47 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BJKfH-0006mI-00 for ips@ietf.org; Thu, 29 Apr 2004 19:09:59 -0400 Received: from web42204.mail.yahoo.com ([66.218.93.205]) by ietf-mx with smtp (Exim 4.12) id 1BJKeR-0006eK-00 for ips@ietf.org; Thu, 29 Apr 2004 19:09:07 -0400 Message-ID: <20040429230841.77644.qmail@web42204.mail.yahoo.com> Received: from [208.35.40.2] by web42204.mail.yahoo.com via HTTP; Thu, 29 Apr 2004 16:08:41 PDT Date: Thu, 29 Apr 2004 16:08:41 -0700 (PDT) From: Ravi Wijayaratne To: ips@ietf.org, mitzel@acm.org, joes@windows.microsoft.com MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Subject: [Ips] Micorsoft ISNS server : Source attribute 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 Hi Joe, I was testing the Micorsoft ISNS Server and am puzzled by the following behaviors I observe. This behavior is relavant to mitzels postings in https://www1.ietf.org/mail-archive/working-groups/ips/current/msg00425.html >From Joes statement in that email I gether that the Sourc attribute must be any storage node already registered under the entity. 1. so initially I have 2 ISCSI disks iqn.hstname1.disk0 and iqn.hstname.dsk1. I register the entity and the nodes as follows Source attr: iqn.hstname1.disk0 op attrs: iqn.hstname1.disk0 and iqn.hstname.disk1 The registration with the micorsoft ISNS server succeeds 2. Now I delete the disk0 and the deregister PDU looks the following Source attr: iqn.hstname1.disk0 op attrs: iqn.hstname1.disk0 The deregistration succeeds 3. Now I recreate iqn.hstname1.dsk0 and re register the disk source attr:iqn.hstname1.disk0 op attrs: iqn.hstname1.disk0 The registration succeeds. But when I try to login to iqn.hstname1.disk0 from the microsoft initiator the the login fails with the message "Invalid access to memory location" at the W2k box. I am pretty sure it is internal I am guessing that we are corrupting the ISNS server database keys by doing the above operation. As long as we dont delete the target which has the name which we chose for the source attributes we are fine. But the moment we try to deregister that specific target out ISNS data base mappings get messed up. Are there any guide lines besides the standard (I am looking at draft-ietf-ips-isns-22.txt) that gives us some guidelines about the contents of the source attribute field in the ISNS PDU ? Is it right to say that microsoft has deviated from the standard by requiring the source attribute to be a registered or registering storage node of the network entity ? I dont see such restrictions in the standard, I interpret it to be any string as long as it uniquely identifies a network entity. Some insight will be very useful. If you wish I will be happy to provide the ethereal traces Thanks Ravi ===== ------------------------------ Ravi Wijayaratne __________________________________ Do you Yahoo!? Win a $20,000 Career Makeover at Yahoo! HotJobs http://hotjobs.sweepstakes.yahoo.com/careermakeover _______________________________________________ Ips mailing list Ips@ietf.org https://www1.ietf.org/mailman/listinfo/ips From exim@www1.ietf.org Fri Apr 30 22:14:48 2004 Received: from optimus.ietf.org (www.iesg.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA19661 for ; Fri, 30 Apr 2004 22:14:48 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BJjzc-0001CX-HP for ips-archive@odin.ietf.org; Fri, 30 Apr 2004 22:12:40 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i412Ce1S004613 for ips-archive@odin.ietf.org; Fri, 30 Apr 2004 22:12:40 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BJjxe-0000p7-1y for ips-web-archive@optimus.ietf.org; Fri, 30 Apr 2004 22:10:38 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA19264 for ; Fri, 30 Apr 2004 22:10:32 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BJjxa-0001ek-VM for ips-web-archive@ietf.org; Fri, 30 Apr 2004 22:10:34 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BJjwg-0001YE-00 for ips-web-archive@ietf.org; Fri, 30 Apr 2004 22:09:40 -0400 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1BJjw1-0001S5-00 for ips-web-archive@ietf.org; Fri, 30 Apr 2004 22:08:57 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BJjsE-0007wA-4p; Fri, 30 Apr 2004 22:05:02 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BJjpl-0007T4-K3 for ips@optimus.ietf.org; Fri, 30 Apr 2004 22:02:29 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA19039 for ; Fri, 30 Apr 2004 22:02:24 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BJjpi-0000rR-IV for ips@ietf.org; Fri, 30 Apr 2004 22:02:26 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BJjot-0000mb-00 for ips@ietf.org; Fri, 30 Apr 2004 22:01:36 -0400 Received: from web60707.mail.yahoo.com ([216.109.117.230]) by ietf-mx with smtp (Exim 4.12) id 1BJjoO-0000gM-00 for ips@ietf.org; Fri, 30 Apr 2004 22:01:04 -0400 Message-ID: <20040501020035.67034.qmail@web60707.mail.yahoo.com> Received: from [12.18.164.157] by web60707.mail.yahoo.com via HTTP; Fri, 30 Apr 2004 19:00:35 PDT Date: Fri, 30 Apr 2004 19:00:35 -0700 (PDT) From: Joe Souza Subject: Re: [Ips] Micorsoft ISNS server : Source attribute To: Ravi Wijayaratne , ips@ietf.org, mitzel@acm.org Cc: iscsi@microsoft.com In-Reply-To: <20040429230841.77644.qmail@web42204.mail.yahoo.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="0-597674095-1083376835=:66731" 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=HTML_MESSAGE autolearn=no version=2.60 --0-597674095-1083376835=:66731 Content-Type: text/plain; charset=us-ascii Hi Ravi, I am no longer employed at Microsoft so I will not be able to help with the invalid memory access problem, but I can comment on the use of the Source Attribute and how the Microsoft iSNS server enforces this. One question I have about this, though. You state that this memory access error occurs on the "W2k box". Is this machine running the iSCSI initiator or the iSNS server? It is unclear in the email below. Please read section 5.6.1 "Source Attribute" of the iSNS spec, especially the third paragraph. This states that the Source Attribute identifies a Storage Node (not an Entity). Also, the third paragraph defines the reason for the Microsoft iSNS server's enforcing of the Source Attribute. It basically says that if a request is going to change the contents of the iSNS database, then this request must originate from a Node that belongs to the Entity that is being affected by the request. Please let me know if this is not clear. Thanks, -Joe Ravi Wijayaratne wrote: Hi Joe, I was testing the Micorsoft ISNS Server and am puzzled by the following behaviors I observe. This behavior is relavant to mitzels postings in https://www1.ietf.org/mail-archive/working-groups/ips/current/msg00425.html >From Joes statement in that email I gether that the Sourc attribute must be any storage node already registered under the entity. 1. so initially I have 2 ISCSI disks iqn.hstname1.disk0 and iqn.hstname.dsk1. I register the entity and the nodes as follows Source attr: iqn.hstname1.disk0 op attrs: iqn.hstname1.disk0 and iqn.hstname.disk1 The registration with the micorsoft ISNS server succeeds 2. Now I delete the disk0 and the deregister PDU looks the following Source attr: iqn.hstname1.disk0 op attrs: iqn.hstname1.disk0 The deregistration succeeds 3. Now I recreate iqn.hstname1.dsk0 and re register the disk source attr:iqn.hstname1.disk0 op attrs: iqn.hstname1.disk0 The registration succeeds. But when I try to login to iqn.hstname1.disk0 from the microsoft initiator the the login fails with the message "Invalid access to memory location" at the W2k box. I am pretty sure it is internal I am guessing that we are corrupting the ISNS server database keys by doing the above operation. As long as we dont delete the target which has the name which we chose for the source attributes we are fine. But the moment we try to deregister that specific target out ISNS data base mappings get messed up. Are there any guide lines besides the standard (I am looking at draft-ietf-ips-isns-22.txt) that gives us some guidelines about the contents of the source attribute field in the ISNS PDU ? Is it right to say that microsoft has deviated from the standard by requiring the source attribute to be a registered or registering storage node of the network entity ? I dont see such restrictions in the standard, I interpret it to be any string as long as it uniquely identifies a network entity. Some insight will be very useful. If you wish I will be happy to provide the ethereal traces Thanks Ravi ===== ------------------------------ Ravi Wijayaratne __________________________________ Do you Yahoo!? Win a $20,000 Career Makeover at Yahoo! HotJobs http://hotjobs.sweepstakes.yahoo.com/careermakeover _______________________________________________ Ips mailing list Ips@ietf.org https://www1.ietf.org/mailman/listinfo/ips --0-597674095-1083376835=:66731 Content-Type: text/html; charset=us-ascii
Hi Ravi,
 
I am no longer employed at Microsoft so I will not be able to help with the invalid memory access problem, but I can comment on the use of the Source Attribute and how the Microsoft iSNS server enforces this.  One question I have about this, though.  You state that this memory access error occurs on the "W2k box".  Is this machine running the iSCSI initiator or the iSNS server?  It is unclear in the email below.
 
Please read section 5.6.1 "Source Attribute" of the iSNS spec, especially the third paragraph.  This states that the Source Attribute identifies a Storage Node (not an Entity).  Also, the third paragraph defines the reason for the Microsoft iSNS server's enforcing of the Source Attribute.  It basically says that if a request is going to change the contents of the iSNS database, then this request must originate from a Node that belongs to the Entity that is being affected by the request.  Please let me know if this is not clear.
 
Thanks,
-Joe


Ravi Wijayaratne <ravi_wija@yahoo.com> wrote:
Hi Joe,

I was testing the Micorsoft ISNS Server and am puzzled by the following
behaviors I observe. This behavior is relavant to mitzels postings in

https://www1.ietf.org/mail-archive/working-groups/ips/current/msg00425.html

From Joes statement in that email I gether that the Sourc attribute must be
any storage node already registered under the entity.

1. so initially I have 2 ISCSI disks iqn.hstname1.disk0 and iqn.hstname.dsk1.
I register the entity and the nodes as follows
Source attr: iqn.hstname1.disk0
op attrs:

iqn.hstname1.disk0 and iqn.hstname.disk1

The registration with the micorsoft ISNS server succeeds

2. Now I delete the disk0 and the deregister PDU looks the following
Source attr: iqn.hstname1.disk0
op attrs:
iqn.hstname1.disk0

The deregistration succeeds

3.! Now I recreate iqn.hstname1.dsk0 and re register the disk

source attr:iqn.hstname1.disk0
op attrs:
iqn.hstname1.disk0

The registration succeeds.

But when I try to login to iqn.hstname1.disk0 from the microsoft initiator the
the login fails with the message

"Invalid access to memory location" at the W2k box. I am pretty sure it is internal

I am guessing that we are corrupting the ISNS server database keys
by doing the above operation. As long as we dont delete the target which
has the name which we chose for the source attributes we are fine. But the moment
we try to deregister that specific target out ISNS data base mappings get messed
up.

Are there any guide lines besides the standard (I am looking at draft-ietf-ips-isns-22.txt)
that gives us some guidelines about the contents of the source attribute field in the
ISNS PDU ? Is it right to say that microsoft has deviated from the standard by requiring
th! e source attribute to be a registered or registering storage node of the network entity ?
I dont see such restrictions in the standard, I interpret it to be any string as long as it
uniquely identifies a network entity.

Some insight will be very useful. If you wish I will be happy to provide the ethereal traces

Thanks
Ravi




=====
------------------------------
Ravi Wijayaratne




__________________________________
Do you Yahoo!?
Win a $20,000 Career Makeover at Yahoo! HotJobs
http://hotjobs.sweepstakes.yahoo.com/careermakeover

_______________________________________________
Ips mailing list
Ips@ietf.org
https://www1.ietf.org/mailman/listinfo/ips
--0-597674095-1083376835=:66731-- _______________________________________________ Ips mailing list Ips@ietf.org https://www1.ietf.org/mailman/listinfo/ips