From ips-bounces@ietf.org Tue Aug 01 12:42:08 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1G7xJk-0006UR-2R; Tue, 01 Aug 2006 12:42:04 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1G7xJj-0006Pr-5A for ips@ietf.org; Tue, 01 Aug 2006 12:42:03 -0400 Received: from mx2.netapp.com ([216.240.18.37]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1G7xJh-00012Q-Sv for ips@ietf.org; Tue, 01 Aug 2006 12:42:03 -0400 Received: from smtp2.corp.netapp.com ([10.57.159.114]) by mx2.netapp.com with ESMTP; 01 Aug 2006 09:42:01 -0700 X-IronPort-AV: i="4.07,203,1151910000"; d="scan'208"; a="397385850:sNHT15825080" Received: from [10.61.17.67] ([10.61.17.67]) by smtp2.corp.netapp.com (8.13.1/8.13.1/NTAP-1.6) with ESMTP id k71GfqQx000663; Tue, 1 Aug 2006 09:41:56 -0700 (PDT) Message-ID: <44CF844F.50706@netapp.com> Date: Tue, 01 Aug 2006 12:41:51 -0400 From: David Wysochanski User-Agent: Thunderbird 1.5.0.2 (X11/20060420) MIME-Version: 1.0 To: William Studenmund Subject: Re: [Ips] DRAFT Montreal minutes - X#NodeArchitecture comments References: <44B6CA5B.6090709@netapp.com> <44CE77DA.0@netapp.com> <061162F7-EE64-4D66-A34C-C206EC5A3555@wasabisystems.com> In-Reply-To: <061162F7-EE64-4D66-A34C-C206EC5A3555@wasabisystems.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 4d87d2aa806f79fed918a62e834505ca Cc: ips@ietf.org, Black_David@emc.com X-BeenThere: ips@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IP Storage List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: ips-bounces@ietf.org William Studenmund wrote: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > On Jul 31, 2006, at 2:36 PM, David Wysochanski wrote: > > > Ping on the 2 items below - any comments? > > > > Also adding a 3rd item: > > 3) Change key value format from list-of-values to > > "iSCSI-name-value" (see 7/13/06 post). > > > > For this one, I'd rather leave it as list-of-values, since > > this is simple, underscores are just about as readable as > > spaces, and iSCSI-name-value seems a little strange > > to me in this context. > > Actually, how about "iSCSI-local-name-value". > > The thing I don't like about list-of-values is that it implies, to me > at least, list negotiations. Which we don't want here. :-) Also, list- > of-values just vies us "text-value" plus comma. Among other things, > we don't have spaces, nor do we have CR. > Don't you think this would look a little strange though: X#NodeArchitecture Use: LO, Declarative Senders: Initiator and Target Scope: SW X#NodeArchitecture= The reason I think it looks strange is that what is being defined is not an iSCSI name. The "list-of-values" sounds more generic, especially if you compare the definitions in 3720. Granted, "list-of-values" and "iSCSI-local-name-value" are just tags to describe string rules, but it looks odd. However, it sounds like what you really want is just to expand the character set beyond what text-value defines, to something more broad such as UTF-8. I guess I don't see that much value in expanding it (are underscores that more unreadable than spaces, and do we really need CR's?), but maybe you have some particular use cases in mind. Anyone else on the list have an opinion on the character set? _______________________________________________ Ips mailing list Ips@ietf.org https://www1.ietf.org/mailman/listinfo/ips From ips-bounces@ietf.org Tue Aug 01 13:07:39 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1G7xiS-0000OE-5I; Tue, 01 Aug 2006 13:07:36 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1G7xiQ-0000O3-9g for ips@ietf.org; Tue, 01 Aug 2006 13:07:34 -0400 Received: from mononoke.wasabisystems.com ([66.173.145.228]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1G7xiN-0003gF-Vm for ips@ietf.org; Tue, 01 Aug 2006 13:07:34 -0400 Received: from [10.0.0.10] (h-66-166-188-91.sndacagl.covad.net [66.166.188.91]) by mononoke.wasabisystems.com (Postfix) with ESMTP id DA1AB87152; Tue, 1 Aug 2006 13:07:30 -0400 (EDT) In-Reply-To: <44CF844F.50706@netapp.com> References: <44B6CA5B.6090709@netapp.com> <44CE77DA.0@netapp.com> <061162F7-EE64-4D66-A34C-C206EC5A3555@wasabisystems.com> <44CF844F.50706@netapp.com> Mime-Version: 1.0 (Apple Message framework v752.2) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <3480AE42-8CB6-4BAE-B55D-2E5DB218D8FE@wasabisystems.com> Content-Transfer-Encoding: 7bit From: William Studenmund Subject: Re: [Ips] DRAFT Montreal minutes - X#NodeArchitecture comments Date: Tue, 1 Aug 2006 10:07:23 -0700 To: David Wysochanski X-Pgp-Agent: GPGMail 1.1.2 (Tiger) X-Mailer: Apple Mail (2.752.2) X-Spam-Score: 0.0 (/) X-Scan-Signature: fb6060cb60c0cea16e3f7219e40a0a81 Cc: ips@ietf.org, Black_David@emc.com X-BeenThere: ips@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IP Storage List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: ips-bounces@ietf.org -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 \On Aug 1, 2006, at 9:41 AM, David Wysochanski wrote: > William Studenmund wrote: >> Actually, how about "iSCSI-local-name-value". >> The thing I don't like about list-of-values is that it implies, to >> me at least, list negotiations. Which we don't want here. :-) >> Also, list- >> of-values just vies us "text-value" plus comma. Among other >> things, we don't have spaces, nor do we have CR. > > > Don't you think this would look a little strange though: > > X#NodeArchitecture > > Use: LO, Declarative > Senders: Initiator and Target > Scope: SW > > X#NodeArchitecture= > > > > The reason I think it looks strange is that what is being defined > is not an iSCSI name. The "list-of-values" sounds more generic, > especially if you compare the definitions in 3720. > Granted, "list-of-values" and "iSCSI-local-name-value" are just > tags to describe string rules, but it looks odd. Then let's come up with a new name. > However, it sounds like what you really want is just to expand > the character set beyond what text-value defines, to something > more broad such as UTF-8. I guess I don't see that much value > in expanding it (are underscores that more unreadable than spaces, > and do we really need CR's?), but maybe you have some particular > use cases in mind. Well, here are the examples from the draft: X#NodeArchitecture="Microsoft Software Initiator/1.05a, Microsoft Windows/2003Build1489, Microsoft Cluster Services/2.0, CPU Architecture/x86_64" X#NodeArchitecture="Qlogic iSCSI 4010 Hardware Initiator/rev1, Qlogic Firmware/2.0.0.5, Qlogic Driver/2.0.0.1" X#NodeArchitecture="Linux iSCSI Software Initiator/4:0.1.11-3, Red Hat Enterprise Linux/4u3, Linux Kernel/2.6.9-34.26.ELsmp, CPU Architecture/i686, CPU Speed/3.06GHz, Memory Size/4059364kB" X#NodeArchitecture="NetApp Software Target/7.1, Data ONTAP/7.1, NetApp FAS/270c" Sure looks like spaces and CRs. :-) Take care, Bill -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.1 (Darwin) iD8DBQFEz4pRDJT2Egh26K0RAhF5AJ4g3wMQFTpTzTcKSbFVdPqh/SRz5wCeKE7H vrhDsT23zCIIS0wJGqtFD/Q= =NUFI -----END PGP SIGNATURE----- _______________________________________________ Ips mailing list Ips@ietf.org https://www1.ietf.org/mailman/listinfo/ips From ips-bounces@ietf.org Tue Aug 01 14:40:33 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1G7zAK-00081x-IU; Tue, 01 Aug 2006 14:40:28 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1G7zAJ-00081E-4H for ips@ietf.org; Tue, 01 Aug 2006 14:40:27 -0400 Received: from mx2.netapp.com ([216.240.18.37]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1G7zAH-0007CE-QK for ips@ietf.org; Tue, 01 Aug 2006 14:40:27 -0400 Received: from smtp2.corp.netapp.com ([10.57.159.114]) by mx2.netapp.com with ESMTP; 01 Aug 2006 11:40:23 -0700 X-IronPort-AV: i="4.07,203,1151910000"; d="scan'208"; a="397418153:sNHT49915124" Received: from [10.61.17.67] ([10.61.17.67]) by smtp2.corp.netapp.com (8.13.1/8.13.1/NTAP-1.6) with ESMTP id k71IeLoD000009; Tue, 1 Aug 2006 11:40:22 -0700 (PDT) Message-ID: <44CFA015.6080806@netapp.com> Date: Tue, 01 Aug 2006 14:40:21 -0400 From: David Wysochanski User-Agent: Thunderbird 1.5.0.2 (X11/20060420) MIME-Version: 1.0 To: William Studenmund Subject: Re: [Ips] DRAFT Montreal minutes - X#NodeArchitecture comments References: <44B6CA5B.6090709@netapp.com> <44CE77DA.0@netapp.com> <061162F7-EE64-4D66-A34C-C206EC5A3555@wasabisystems.com> <44CF844F.50706@netapp.com> <3480AE42-8CB6-4BAE-B55D-2E5DB218D8FE@wasabisystems.com> In-Reply-To: <3480AE42-8CB6-4BAE-B55D-2E5DB218D8FE@wasabisystems.com> Content-Type: text/plain; charset=iso-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 4b800b1eab964a31702fa68f1ff0e955 Cc: ips@ietf.org, Black_David@emc.com X-BeenThere: ips@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IP Storage List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: ips-bounces@ietf.org William Studenmund wrote: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > \On Aug 1, 2006, at 9:41 AM, David Wysochanski wrote: > > > William Studenmund wrote: > >> Actually, how about "iSCSI-local-name-value". > >> The thing I don't like about list-of-values is that it implies, to > >> me at least, list negotiations. Which we don't want here. :-) > >> Also, list- > >> of-values just vies us "text-value" plus comma. Among other > >> things, we don't have spaces, nor do we have CR. > > > > > > Don't you think this would look a little strange though: > > > > X#NodeArchitecture > > > > Use: LO, Declarative > > Senders: Initiator and Target > > Scope: SW > > > > X#NodeArchitecture= > > > > > > > > The reason I think it looks strange is that what is being defined > > is not an iSCSI name. The "list-of-values" sounds more generic, > > especially if you compare the definitions in 3720. > > Granted, "list-of-values" and "iSCSI-local-name-value" are just > > tags to describe string rules, but it looks odd. > > Then let's come up with a new name. > > > However, it sounds like what you really want is just to expand > > the character set beyond what text-value defines, to something > > more broad such as UTF-8. I guess I don't see that much value > > in expanding it (are underscores that more unreadable than spaces, > > and do we really need CR's?), but maybe you have some particular > > use cases in mind. > > Well, here are the examples from the draft: > > X#NodeArchitecture="Microsoft Software Initiator/1.05a, > Microsoft Windows/2003Build1489, > Microsoft Cluster Services/2.0, > CPU Architecture/x86_64" > X#NodeArchitecture="Qlogic iSCSI 4010 Hardware Initiator/rev1, > Qlogic Firmware/2.0.0.5, > Qlogic Driver/2.0.0.1" > X#NodeArchitecture="Linux iSCSI Software Initiator/4:0.1.11-3, > Red Hat Enterprise Linux/4u3, > Linux Kernel/2.6.9-34.26.ELsmp, > CPU Architecture/i686, > CPU Speed/3.06GHz, > Memory Size/4059364kB" > X#NodeArchitecture="NetApp Software Target/7.1, > Data ONTAP/7.1, > NetApp FAS/270c" > > Sure looks like spaces and CRs. :-) > Oh, so you're mainly concerned about the examples? Did you see my latest post on 7/13? I corrected the spaces (replaced with underscores) and removed the double quotes. I'm not sure how to express the whole string without splitting lines but will try to figure that out. _______________________________________________ Ips mailing list Ips@ietf.org https://www1.ietf.org/mailman/listinfo/ips From ips-bounces@ietf.org Wed Aug 02 03:15:36 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1G8Awy-00009d-0g; Wed, 02 Aug 2006 03:15:28 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1G8Aww-0008VD-0g for ips@ietf.org; Wed, 02 Aug 2006 03:15:26 -0400 Received: from mail-gw3.adaptec.com ([216.52.22.36]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1G8Awv-0005Bu-F0 for ips@ietf.org; Wed, 02 Aug 2006 03:15:25 -0400 Received: from aime2k03.adaptec.com (aime2k03.adaptec.com [10.25.8.43]) by mail-gw3.adaptec.com (Spam Firewall) with ESMTP id 9ED8BED465; Wed, 2 Aug 2006 00:15:23 -0700 (PDT) Received: from aime2k302.adaptec.com ([10.25.8.48]) by aime2k03.adaptec.com with Microsoft SMTPSVC(5.0.2195.6713); Wed, 2 Aug 2006 00:15:23 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5 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] DRAFT Montreal minutes - X#NodeArchitecture comments Date: Wed, 2 Aug 2006 00:15:23 -0700 Message-ID: <368FBF3D8437A748BA8222526BF9309957F8CD@aime2k302.adaptec.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Ips] DRAFT Montreal minutes - X#NodeArchitecture comments Thread-Index: AcamzIDF7D1NUei6Sq+7+eV4jldMEAPNQmBw From: "Sandars, Ken" To: "David Wysochanski" X-OriginalArrivalTime: 02 Aug 2006 07:15:23.0606 (UTC) FILETIME=[6BC7EF60:01C6B603] X-Virus-Scanned: by Barracuda Spam Firewall at adaptec.com X-Spam-Score: 0.0 (/) X-Scan-Signature: a1f9797ba297220533cb8c3f4bc709a8 Cc: ips@ietf.org X-BeenThere: ips@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IP Storage List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: ips-bounces@ietf.org Hi David, Making an extension key 'Declarative' seems problematic. Implementations which do not recognise the key will reply with X=3DNotUnderstood. This may upset the proposer since = "NotUnderstood" is unlikely to be an acceptable use of the new key. "NotUnderstood" could be treated as a special case, but do we really want a special case? Thoughts? Ken -----Original Message----- From: David Wysochanski [mailto:davidw@netapp.com]=20 Sent: Friday, 14 July 2006 08:34 To: Black_David@emc.com Cc: ips@ietf.org Subject: Re: [Ips] DRAFT Montreal minutes - X#NodeArchitecture comments I think the attached addresses all of the comments below (or is pretty close). I know the format is wrong in some cases (pages too long, etc) but I'll fix that later. Diffing should be simpler. Some remaining points still for discussion: 1) Still not sure about proper use / behavioral text 2) Now explicitly states the key may be sent in either normal or discovery sessions. Specific comments / explanations below. Black_David@emc.com wrote: > Dave, >=20 > > A couple comments a points for clarification, while this is fresh=20 > on > everyone's minds below. > > > > > iSCSI X#NodeArchitecture Key: Dave Wysochanski, Network Appliance > - 30 min > > > (draft-ietf-ips-iscsi-nodearch-key.txt) > > > > > > WG Discussion: > > > - Key should be allowed only after Authentication. Revise=20 > draft > > > to impose this restriction > > > > > This is actually already in there if you read the fine print of the > "Use" > portion of > > the declaration and note that "Any-Stage" is not there (see Section > 12 in > 3720). > > Since it has come up repeatedly though from various people, I will=20 > add some > text to point this out explicitly and refer to Sections 11 > and 12 of 3720. >=20 > Yes, please do that. >=20 This has been fixed with a small change to the first sentence of paragraph 3, section 1.2 and added a second paragraph in section 2. > > > - Make sure it's a regular-size text key (not a big one, like > the > > > one used for the large numbers involved in some > authentication > > > methods). > > > > > Was the comment to limit the value size to 255 bytes, i.e. a single > > "text-value" (or "simple-value"), as defined by 3720, or something else? >=20 > Limiting the value size to 255 bytes was the intention. >=20 > > I liked the comma separated values and list-of-values seemed to >=20 > fit well. But if there are concerns about key length I suppose we >=20 > can add an explicit max length of the list-of-values. Another=20 > reviewer > raised the question about the maximum length early on so=20 > perhaps > an explicit limit is the way to go here. >=20 > An explicit limit is probably a good idea, as an implementation that=20 > receives this key and doesn't recognize it may only log the first > 255 bytes, so imposing that as a max limit may encourage more useful=20 > behavior from implementations that aren't expecting the key. >=20 Addressed in Section 2. > > > - "protocol logic": crucial point is that **behavior** is the > same > > > independent of presence, absence, or content of the=20 > key. > Add > > > or revise text to make this point. > > > > > Was the consensus that the original term, "functional behavior", > > was clear enough, and I just muddied the water by trying to > make it > more crisp? >=20 > The "protocol logic" wording is not inherently a problem, but it is=20 > important that the on-the-wire "behavior" is unchanged, and "behavior" > is an important word. >=20 I put back the "functional behavior" term and made my added "protocol logic" sentence parenthetical. Please let me know if this hits the mark. > > > - Document behavior of RFC 3720-compliant implementation that > > > receives this new key and does not understand it, and > how > > > the other side deals with the resulting response. > > > > > Ok. > > Adddressed with last paragraph added in 1.2. The paragraph starts with a short discussion about possible valid implementations, which complements part of the latter security section. > > > - "configure different levels" text needs to be rephrased > to be > > > specific that the amount of detail is what changes > across levels. > > > > > I'm not sure about this comment because I thought the existing text > > does just that. Here's what the text says today: > > > > all > > implementations of this extension key SHOULD provide an > > administrative mechanism to configure different levels of > > detail in the extension key values and MUST provide an > > administrative mechanism to disable sending the key. >=20 > "levels of detail" seems to be less than perfectly clear. Talking=20 > about being able to set "amount of information" provided to one of=20 > several levels, and perhaps "verbosity" or "verbosity level" of the=20 > key could be clearer. >=20 I think this is clearer now. Please see paragraph 2, section 3. > > > - Align ability to configure amount of details with "SHOULD=20 > NOT" > > > in Section 1.2 about administrative setting of key > value. > > > (the prior "SHOULD NOT" appears to conflict with this > "SHOULD"). > > > > > Point taken - will work on it. > > Also, I think addressed with slight modification to 3rd paragraph of section 1.2 > > > - Double-check there is a 3720-format definition of the key, > > > including description clearly in the draft. > > > > > Was the comment that the existing declaration in section 2 >=20 > conforms to section 12 of 3720, and specifically, section > 12.22? >=20 > If it does, I think you're done. We weren't 100% sure in the meeting. >=20 I double checked this and I think for the most part it is there. However, upon examination and more thinking, I do not see or remember a reason to preclude use in discovery sessions (again, logging may be useful), and 3270 does not seem to forbid declarative keys in discovery sessions (are declarative keys "requests"?). Thus, I've clarified some text to make this clear. Please let me know if there are objections to this. If so, I will add "Irrelevant when: SessionType=3DDiscovery" to = the key declaration and remove the references to discovery sessions. > > > - Make the examples phony (no real company names), and remove > > > the double quotes ("), as they don't appear on the=20 > wire. > > > > > Ok. Main intent in providing company names was to show valid >=20 > examples for implementers but I will remove them. Note that > RFC=20 > 2616 does have valid examples > > > Examples: > > > > User-Agent: CERN-LineMode/2.15 libwww/2.17b3 > > Server: Apache/0.8.4 >=20 > The big concern was use of company names. Example, Inc. is definitely > ok, and non-offensive parodies of the company names used are probably=20 > fair game (Dave Noveck may already be thinking up some of the latter). >=20 Done. > > > - Spaces are forbidden in text strings. See RFC 3720, Section > 5.1, > > > and feel free to ask on the list for options on how to > deal > > > with this. > > > > > Good catch - looks like I got carried away in my intent to provide > > clear examples. >=20 Replaced all spaces with underscores. _______________________________________________ Ips mailing list Ips@ietf.org https://www1.ietf.org/mailman/listinfo/ips From 2dkrCssXX@mail.ru Wed Aug 02 06:13:11 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1G8Diw-00055E-Td; Wed, 02 Aug 2006 06:13:10 -0400 Received: from [124.199.147.208] (helo=mycom) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1G8Dit-0001LG-1q; Wed, 02 Aug 2006 06:13:10 -0400 From: "Marsha Porter" To: Subject: Your nectar-tongued Date: Wed, 2 Aug 2006 10:13:21 -0540 MIME-Version: 1.0 Content-Type: multipart/related; type="multipart/alternative"; boundary="----=_NextPart_000_006A_01C6B667.B87C5300" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1165 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 X-Spam-Score: 3.4 (+++) X-Scan-Signature: 249cd1efd3d5e0d09114abe826a41235 This is a multi-part message in MIME format. ------=_NextPart_000_006A_01C6B667.B87C5300 Content-Type: multipart/alternative; boundary="----=_NextPart_001_006B_01C6B667.B87C5300" ------=_NextPart_001_006B_01C6B667.B87C5300 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable pulled out of his dive=20 from seven thousand feet, a long gray streak firingof my business. Now=20 nothing concerned me any more.nearer to Heaven." Pmber, =20 We recently reme not to see them right now. Not in daylight. =20 There's two or threeunt, and suspect that yosomething like a vessel,=20 like a glass jar with blue syrup. We looked at itaccessepicked up what=20 we needed, and came right back. Like we just went down to the "God,=20 Red! Everybody calls you that.silent, and his eyes looked like a sick=20 dog's-they even watered. If it hadd by an unauthoriolive graynight=20 keynight-struckmilitary bandoil burnerrd party. Prot He wants to=20 go up. And what if something gets you at twenty yards?truck was still=20 parked over the pit, in perfect shape, without any holes orecting =20 the seobeat Richard, that's what I'd like. That bum can really=20 play cards. Can't My skin crawled. You so-and-so fool. Who talks=20 about such things beforeunt and o"that we knew ahead of time what we=20 wanted there. And that means thatncern. =20 Therefore, as prevention measure, throw in that direction.=20 But not straight ahead. Not for anything. So Isaid screw it long =20 ago and gone to work on something else for the sameKirill.count=20 features.We encourage "God, Red! Everybody calls you that. "keep=20 working on love." Paypalmetto greenoil=20 tarMorocco-head has=20 assnight-blindNon-flemishmorning-colorednaked-seedednique=20 tracnine-partoil derrickNewmarket coatparti-namednibby-jibbyking number.=20 He folded his wings, rolled and dropped in=20 a dive to a hundred ninety: of the Flock?" =20 at the horizon itself, flew a few others. New sights, new thoughts,=20 new uniqulaid the tracks to it yet. You know that. So here we come back=20 from the Zoneso on and so forth. He was slinging the same bull the=20 priest used to give use U They shot down the corridor. Faster than=20 racehorses. I waited a minute.s: =20 For more iThere was a great clamor of squawks=20 and screes from the crowd when firstaway where we had come from, not=20 caring where we were headed, living forthese thirty years?"nformation =20 "Let's go have a smoke."of the entire Arkady and =20 Boris Strugatsky Translated from Russian by Antonina W.touched the=20 ground. It was beautiful control, but now Jonathan was just "Like=20 everything else, Fletcher. Practice." By morning the Flock hadem. Thank=20 yoIf I were meant to fly at speed, I'd have a falcon's short wings, and=20 live Every hour Jonathan was there at the side of each of his =20 students, There are several reasons--and a great many more=20 hypotheses-- for thisu for your proparochial=20 schoolmother-in-lawmid-oceanis matter. ------=_NextPart_001_006B_01C6B667.B87C5300 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable =20 =20 =20 =20 =20 =20 =20 =20 =20 =20 =20 =20 =20 =20 3D""
pulled out of his dive from seven=20 thousand feet, a long gray streak firingof my business. Now nothing=20 concerned me any more.nearer to Heaven." Pmber,
=20
We recently reme not to see them right now. Not in =20 daylight. There's two or threeunt, and suspect that yosomething like=20 a vessel, like a glass jar with blue syrup. We looked at =20 itaccessepicked up what we needed, and came right back. Like we just=20 went down to the "God, Red! Everybody calls you that.silent, and his=20 eyes looked like a sick dog's-they even watered. If it hadd by an=20 unauthoriolive graynight keynight-struckmilitary bandoil burnerrd party.=20 Prot He wants to go up. And what if something gets you at=20 twenty yards?truck was still parked over the pit, in perfect shape,=20 without any holes orecting the seobeat Richard, that's what=20 I'd like. That bum can really play cards. Can't My skin crawled.=20 You so-and-so fool. Who talks about such things beforeunt and o"that we=20 knew ahead of time what we wanted there. And that means=20 thatncern. Therefore, as prevention measure, throw=20 in that direction. But not straight ahead. Not for anything. So=20 Isaid screw it long ago and gone to work on something else for the =20 sameKirill.count features.We encourage "God, Red! Everybody=20 calls you that. "keep working on love."

=20 Paypalmetto greenoil=20 tarMorocco-head has=20 assnight-blindNon-flemishmorning-colorednaked-seedednique=20 tracnine-partoil derrickNewmarket coatparti-namednibby-jibbyking=20 number.
=20 He folded his wings, rolled and dropped in a dive to a hundred=20 ninety:
of the=20 Flock?"

at the horizon itself,=20 flew a few others. New sights, new thoughts, new uniqulaid the tracks=20 to it yet. You know that. So here we come back from the Zoneso on and so=20 forth. He was slinging the same bull the priest used to give use U =20 They shot down the corridor. Faster than racehorses. I waited a=20 minute.s:



=20
=20 For more iThere=20 was a great clamor of squawks and screes from the crowd when firstaway=20 where we had come from, not caring where we were headed, living =20 forthese thirty years?"nformation "Let's go have a=20 smoke."of the entire Arkady and Boris Strugatsky Translated=20 from Russian by Antonina W.touched the ground. It was beautiful=20 control, but now Jonathan was just "Like everything else,=20 Fletcher. Practice." By morning the Flock hadem. Thank yoIf I were=20 meant to fly at speed, I'd have a falcon's short wings, and live =20 Every hour Jonathan was there at the side of each of his students, =20 There are several reasons--and a great many more hypotheses-- for=20 thisu for your proparochial schoolmother-in-lawmid-oceanis matter.
=20
------=_NextPart_001_006B_01C6B667.B87C5300-- ------=_NextPart_000_006A_01C6B667.B87C5300 Content-Type: image/png; name="7406Q69E.PNG" Content-Transfer-Encoding: base64 Content-ID: <006901c6b61c$4894ab00$6c822ecf@VOP3N8L8> iVBORw0KGgoAAAANSUhEUgAAAeoAAAFcAQMAAAA9MG8RAAAABlBMVEX///8AAABVwtN+AAAVkklE QVR4nO2c0U8bSZrAq9sOLhzn7EV5QKgVFTUsNB5LEDQ67QNCHnLaYbP7sDt/AcnsniB30tnOy0ye yj1RqG4jhYvmgfVaUV/PyvEwkW7wvUbIl9HiHtAo2nvcJxSNZtHqpE2yLyT7ct9XbcDGhhhHd3N3 wydkmqJ/rurqz99X31dfm5D/2xLhDhuE34KQrGCa4ISStCBajRC9cQocC0H2OuLU22I0wKVgRPwt 4kTXGTng4VioEzrhfMulubeN9ToRS6mMSOa+Mp4XDD3yzvqm8UUkpdc5Hi8R6+1Utt6Oz6y5NJry tkwhZJWK5PkkTy97OlnzOfdpNWSqYyme/6zqmG1DoBzwW6Zb+JasSu9DwW/FZtLS0yNr9lMuqadP rMGxlPDm7ss7HQZfdKljuo5GpPSk4E6UpWVJp2sONxA3k3Ac4OLdDlP3m3laXPAcKqSsrgpe7Gdz 0tXH17auswY+joPP/8y12gcf4XbaWKyU7DrJ1lOLNX6Dli77JW3TW39gyAjXxy7icZ28ept1mLrO wgneKd46zi5ZEEPhRq/4mZzJf6dEgl8G6KQkJIPHCdY9ToX6hRbSJ/gOgJ+id2r8Rz0layy7Tb7y RX47latPX9vuHuefsyrg0ZRYM4WVqhbYCk+J7vG1MU8S9pEUa0lhmdyJrPB2q3ICbnqrhMk5UQxw eirc+3zcW6jxoom4Y045/fdOgUcMZ9OjNWPRF/bvSNZP5fqWs37XuHJFTbeKdQ8e4Ds94xFeqDPl Z0/brRLq/cF0lZ/tDb+4ZrqT6Gd7wvsufu4DDn62J1xD/6j8bE84kQFe7A2niE+in+0Jj9BCfWYS /WxP+Hcr8ensE0F04/VndhTqcZOQc/z1Zx6H0xihVu94HPDlHvH4NIdVR++9m2+Gj3AzRn7X89Tx 7JNl8rjXG/fdSly9MvSqmu+9BA08lQQelilTvexZp51CWsp+baw/AK8aQ1x/PdGKe07S25oHr7pM nE+en/b+x2es5IYzptyi84mYPSUeZVbSdUyF25+I0157P3MAXwSvukxs2cvU+SW7DF51WfPly8en xL9bicvnTzbgGjK94fpFx4QP/KDsEYe1EJ0kZo+BDuBxwOGnN3zmxQJaq55798w3wu+ZdDJEe546 +4mcDM30eOPO5Ey+b7IfR7wryF92Z4afPNJoEJAY+CGOC3UOuazOFYIdxffjiDT4KMreN7nW+ORj VNvI1VDxkwBvj3Qwjkhl66lnUgDuUB7aNq7XUjnGbv50MEN5tW5kqHHFL63X+PpSqg2HOGLKMatp KQr+tH2XazHvLTblMBZ9KGX84rbpyT7+LrW2GPdltb33NZe9inuAv6Bsbw4Gv8EJf+WyWxUpKXXi q/Mafx69//FOUso2F4hxBLMoT9vCo0zitbuAWy5zApyGE8R7N+pZpCMOcQSDyHfujrgH1w64GeC8 CIOnF7co5gzfTZYV7rXfODvNsnV+uSYKf96wnzwifilHeDZt3HjbyMS9asTIRIz074bytYt2/Xj/ rXVuFscCrfI3veJ6EEMz0LQc3YDoO63GAvqjARwG1Yk1FKizLznAwV1KnjrEse8wnDDQQGlbhH0+ lRsdytamne0R0LQAf14z/q2eAvUjsrT+ZNCuJXL1wVzNsLcxmdwisarDRx2WKKQqDhtEPClmGf+K VkH9iPT8EYr/NWWB8fdT1taRvAR1Hc5fioRDv3jFwvv4jB13Qf2IdPPf0MLOtBOXDpvh9L4zcRS3 Z7lIA16x5nXExwFnNmWgfoBbI/R9Av+lcGmcerZ/ZPCAj1psoEh/m3d5gF8F3GSgfsT2rF/KALcY fJzLzpHJP88ySzB1sRvUyzDj5h8p3LjLNUPWGcFccSn/qTEMUxcxcsyw/aJ9ZOqa3y3d8bY2JFgA 6EduXBMeap2VIxIsAHDToVX0U2XY2uSN8AtG9b3p3vGotSVX3gC//3H8TXDPkm9w7dGyNTfQ44oU hBatsVjv+JmcyfdN4iQdZiQOy6cNu9bwpGnStV+nAnEqZcx12EDQlu6+d+o9i6cyVIqYu0YSudpg dcx4vm1oS10OnqfDUzJORfTRZyJRYHTL9GZT4Fu7Gz310mG+R+Vq1K2kpx1CnYnVWXOQtG+5Ho8L uPZ+t8ISgNtz4VkzTPJd4uW5sBfgf2jg/KrJiVye/LILPD40GeIZdeN+AZ6UGHLJuOwbWj3WFX4m Z/J9Ez2WJmSWqMCBxEJ/nOZjJBNW1Qdo/fAU9S8xSxJaezRxbiDAlW0cgAX8+6aQYYwaKFo/dc4J OF15vk1e1ElmCQKuBOD2HBHxVLacyqD149laCv6V3RQv6tMQX8hIKtOKz6bEFehRepKuIP5jMh+e il6fkmj9eJRNSWk54+IKW4H4QpJqS3Is/ujKLpmdEEKu7tFHgO/lSSLMbnEu0folPxJs7+79D3bF 7NgKxBcy4u4d6Z2SWZMIeVuo3qUQNMwgQsmg9UvKNBOSD1AxawLurlJXtOJXKblqYr1KA5cwdW7x Ohdo/ZJFBvio0y+ujt+D+GKh/yh+2SdTYyRbV1O3NC2XSCbEFh9wZf0uLtYgwh2CqZsaXYb4gva5 XWb2OuYPu1+/duxlp70JYvwxnhtTyhNhNx8znU8X/lwKVI6RIA+aEOKYbujFgum9ZarUPkSFP2Sh X3FHp42dWRaEronO9HlDUl4w+Vsm6B64WuaYrl7x7gFOjJs/Na5tk99/Nbhem17v6HNBkSh3KjO8 Qq6YVUlZwUf808cUNDb60IKIuJKEkST8jj6XehU641Q4/0zMTrh7/a4z4eoTj57qdG2e3arc56b4 7D8xCpYdfS7i3FngfAH0igm4dhi8WYHBg8I4FW/YF2tJCjG47OhzG7gH+NVD/LcO4rz4sMypWFuk DhmQnQdf+nncy6kbNzXGMpGZm/6GbnqFp4ZdM268PQQhrV2Bmxg7Gr12I7QRtB4NXbvGg6C1PXQ9 FL314A7JCxLabRgmlakTjVC5j6pESnsnLe+G+rn/gflJA99//3ArGXnn5repDOhexKiOwmeWZy3j C1CwwmDQiJm6fzdy/mq2ZlQfD2afDOZaLmSNzk5J1D1vCwwU8ailo4Ity6ARM3XDoNXSYfo2p3KE Flhz72sfWlzSjUrfjMXZXsT70Lok7wqwPvPYqDJ1TwdfUfnxziWH0/w3tKVGgq7ZOhgWt6Kx/Cyo zScS3g0uXMoENnLM1IXD1jlqEQ64NdKK968VdVgWuhXq5mfBvn2yao36Mga4xEaVqQtzwB0yCoN3 filb8D7vH/4IvZd+HjEEeIo+uVgfWq8DXgoaMVPnGzndyNaGqnUj+6mRa8aVvGZbZP++HrfT2KXx 7ICrrNo1AS8N5ZsHxag1NEXsn4AmVgcrO8iO2Fo1MNaEszDRWAPFxsbIE+qHHjXV543sksGkWN8e ykRI9uvU8BNDi6SySykN9G3byJzn2QLM23SmbzoTode24dU4/ATFLHCggPupsiTCSVb5CNdoVcqq /kPupzzUvWUPjZWekJgMXAHNPMwZ0vvz8hLg9q43HxFW0nvrm5mQ7+5JL/SUQeMe9eblxjWB+Dyl b+2uzEdWtZ0D3EtIzmzhmF6CIs7DmKkTS1zXwWiXBJ7gJtKIJyjldCVBbx9aj1hZyjK7I5yFsuxX gw+7iEuunwMb6Ao8AWM0qQ/g4Ok92e/p8wdTN4QOtAYGrZjpE1n/YfZLmDrMG8PUgZXLwAl+KVuL ZSLwY2T95UxfSXNb7/5hinh/WAela93IYYp4Hz8onHuNgBoIXLnR1riVBX+06Ukn/MAWtuHkNXhk OrcpMkupfe0yvgCl2ibZssjVAhMHapYCo4dleO04XTk/DlFgdV+7uA9KlRLRRVFggYlL4FqOeliG 1473JW6Z4kN5oF1cgFLtCmh0WGDiEjKCTlyV4bWJlnDUknJfu8Bw3daBRTwwcaDq3mqjDK998PeK 42IV8IZ2gbnz9AVRXAQ8MHEDoGYLjTK89qmL3RgVi3W+r12GAKWqiEWYOhaYuFimz6ONMryTbsIJ kjhahnc62TlahncmZ/LdCT2MErK1BKxRZRw/1qwPXsRfnk6rwHMwOEFrL6+4cIiDYSEXPD84Bf2t cM4F27J0H2/rPVr655rh1IntC4tNZ6KuTwfBsV57TMAGOtSDuFWvUxWmpULbarHXglse2jQ0LxaY tehqJU7BsTJOwAYWfA/i1pAppQn2qqrF1GKv5drvf7kz6MQRLwJOb1cotXfd4acEzN2LuAdxqx6X L7+dmadwrBZ7LbjnkbBDSRGNG+DWKsUyUc4JvKGHiKtTag2zhMJxsdeCl+8RXqTkxrhAN4pWkWJw cZ2ADbwHiKnwBVfisVrsteBFjBoipH9ToFmDG0cNcKzZBwRsYGEXt2V1cKwPcLUMx7jY63T/32hf 6g3sWLBnmlYqoYmgfF29gLL14bZ+9zgRwUWwRgCivy5jHOE36++Aaj07D0s4IyOmP3iP5MZSubqh 1WmOG8/bd/ybhXo2XdNiVhoWeDGPigSvCHuuet70dCYdrqfbd/ybpY9fi69p9H4aFnh05sO7K/xf xZ7kt8wNPQKRwaV0+557y5WP/oAmNeqlwcNSWB5C7wRWZc4Y0yng/DU4qI2Z1MzyHC1D9L0qBgDP z3lFk+nj0rk+Oie9kza8InqmDupUnKTFDDUWazEIZiGkvTFmaJuge0OX6/zE/bJw5+bGuu618qNj RtUdfSZn8j8vVM425+KEygl3X6hIMf0rDv/ejyxYd3h09YXKxa37AgJYCF3JEl/fHlyvdYnLKyoX twWr+mQVwgoivK2U7PYhjqicVbm4wp9E/k8ehBVkyXOo7PYRkgDPEyeKAaxc4kQibnc5+AvyKsNc HODOjeqq5MQuOxABdUeTc8YUw1wcPqpTeQhhhbZZtP1St723CDswcT0l6NiBiTspQdcscQ/Cn5cw 5joJPZEv2EwmznNsplBXrzvqqYoTROeccW7i1qduXnQYhUUIvDqmeiXcMU/sHXDCuDlCJNFNbqcR txRudYXPDItBbprkDtEnGvgHO/SV6X28Q/9a487Ea3pn6TA3f0TyJOTPSIiG43yAUVgQFrH36dcO njEdBy+ELjnilEcBlMG1m6+/9oOpm2vgCM4F+Ihjxk7G4cYNqxunT3jPBAU/mwNwDF8LOzzrn4if yZl83wRriVngETVLbSv0KSd7G1uuCXVOn3qtNeo804QNi30ca4kbOAlyxXpQzIktjaSdyh9rrFHn CfhhYjCoJa6lstskc+ed9YKhPTbA6dh3U9rXBhMpWCGvPzYghtUiqs5zyXhGH84f7I6pWuIom3JS QlpJf9kD+4G7mben9KTFxBTEklucR00IIVWdp4CVf5UdbDBhLTH/SPC/7grwkVJ6msUrUlRuc825 zwR/VSYfP5356O5qyFd1nkur6ajH7h7iRZfLNLdogJfILK/YiJOrHuDWvxALopq5MASzqs7zNuIH UTTWEvMimwIcBy9dGHzlDuCeniwjXhGAF1WJclDnOYd4DHP4JKgl5oswdbA4qfN1v6TVjV/UxC++ 5JpfzNZ49j2SrxuLOHWNOs/Jczxb38ePikoLH1NX3IWotPAxdcVncib/KwQ+gxgOJBo2aj+3Nqx+ pwNDxRrHaRI7mnM7wA9EnaxOE024UPjAUTz6MAfRBPxsprQlkv0a4ghYTxofbOMmxTP8nhNj3Q2O +bNIAtN3Y02bNdFqgSVwc59PwerISUIcAaabD8c8HxMa1ZBpbc1zdQw/WHais6ZsRtR7xRKFnUT+ KYeVIZgrB/GZYboh6EYav2nkvsV4cJymjzB996AFt7AuLmHB4jSPuF0bBccxTF0RYQr3EFfH2Dt1 9Ur5EL8A/x1wyIB1nQeDd8iQM8+GTVdQNke9kFm25rk6Ls8Bbrr6Z8XDZMg5mKiYXYvlH+DSDp9S rOlZ18j4JRExJiNcrw/lXUMdD01GEmjufmydkEvR2X4upTl50pJIOSbZokSr7edSmpMnLYmUpmQL FddEIlC4WVQMTLJhzQAoknKsWASlvoNCq6FqiSN7X1SwFjxoVLh+iKuL6oRHS0yAypUgaH1Rh5/B L/oMbdso1KYzugHuFRpvqu+g0CPT2jZZr6cWWnBwZAl/HJ8YumKKK0z6OicpzyYJqYNjxSIom+B3 UOh0RU+JLVZt2ZmKbgCe393IC6x3mo1IqQ9quwE+cwtaJsQ19R0U+j+t4FbXmNuao3YBt0BJ0ljv NEsBD4OmKZzZc9j4A/UdFLqZUDtlrfgFwAesRdd6C+udrvYDzvV/9H6NG6/s13PYaI/j07K6OQD4 1ri7WmvCz+GeV75cyj/GeqepvpKMGNrnxgJuvBoLS9iY2VRPy9Zjmi/WN90O22rkZFU6kzP5fyQR NFC41RWioPazOjrFhh/E2ACjbyycQ8OlWo8+aqSeCIP/hAXi6qR9N6rr6umwlkfqj5SKUXSjuNUV Hlx/Ql5spjJ9GDWE3ktBZKHXEzk0gKS6aWTOD2br8M4GfnHW1/slDZSng62uMN0aIVf4lNSn0I1W qhBZhMyVgjJ32xBixCR+kxjVcWs+ue8l+9F14lZXnOZvQyjAwdqgG624EFnoE4+cOJo7R2d7lH7w LXR3yb4LccPGfu9ugCfCVPwd4hnEXYWXwL45quYTcEHpgIajlXPgiN0DfC7Y6gpTa0Rc5Vzo+HCi wt2QwsHcbWE1FHXoMqHlIrzbAa7cKG51hY38l2DZeLDzpY8xG15h6iJo7vD5RGpgEBEZWlSO+DhF aLLDh2sY0X7eMdJU9XRYcHIsTkXw3KrSDaY16pUwzzvc8I8qsmE0TQLXqUqhjsMPHoFVx004OcBZ Mx4t3ajjtxKBav1+e+QmaB2WlwzmaqkPlL7d3DZu1mBpN/jsgiHPG6E6GX7SVEUT9X5jeqtKtSqp iq1PSWp9zmSBTQ1T5V5j4O/0rXmajuKWmQbrgZHmZeGGM7Fq76JqfbY7+VLnkl5aG8PV3XAf+txr dOYlueTAtUfvS7oB+PA3M02465hhZ1yAaq2ZZh5r7fiaKXOAa4F7ZXnCFe6tYhgr+Ag7xC+4EJ8W /16Aaq0tjORB62j583EJS8FhExttk+XZqDNP56LlhRiEsYL/0j3Ezxk3xoxFV4Bq2RWeqYPWDTmb Jeg9U1fu1TcytSHbNSZpkZ43wFxkP20rQGoKWqUyLacrJG4KWjMK77aQOKzM2G1cfWHaRD++hq+j BHhY4UHLqfC4ofuedpfcVDsUaNNO1zsPmR4Mvp/gDgXatFPiusI/IrhDgTbt1HgZcFzI5ZVNOx3u hcaL5Lb4tdqhQJt2GpqEDH3T0r4kC6paGG3aqb/m5/Dzf7quG3IYHfSEn8np5b8AK2ZBUXaMTrYA AAAASUVORK5CYII= ------=_NextPart_000_006A_01C6B667.B87C5300-- From ips-bounces@ietf.org Wed Aug 02 11:03:39 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1G8IFx-0000tm-4f; Wed, 02 Aug 2006 11:03:33 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1G8IFv-0000tW-U6 for ips@ietf.org; Wed, 02 Aug 2006 11:03:31 -0400 Received: from mx2.netapp.com ([216.240.18.37]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1G8IFt-00051h-Bu for ips@ietf.org; Wed, 02 Aug 2006 11:03:31 -0400 Received: from smtp2.corp.netapp.com ([10.57.159.114]) by mx2.netapp.com with ESMTP; 02 Aug 2006 08:03:27 -0700 X-IronPort-AV: i="4.07,205,1151910000"; d="scan'208"; a="397672620:sNHT25719676" Received: from [10.61.17.67] ([10.61.17.67]) by smtp2.corp.netapp.com (8.13.1/8.13.1/NTAP-1.6) with ESMTP id k72F3PmM022799; Wed, 2 Aug 2006 08:03:25 -0700 (PDT) Message-ID: <44D0BEBC.20804@netapp.com> Date: Wed, 02 Aug 2006 11:03:24 -0400 From: David Wysochanski User-Agent: Thunderbird 1.5.0.2 (X11/20060420) MIME-Version: 1.0 To: "Sandars, Ken" Subject: Re: [Ips] DRAFT Montreal minutes - X#NodeArchitecture comments References: <368FBF3D8437A748BA8222526BF9309957F8CD@aime2k302.adaptec.com> In-Reply-To: <368FBF3D8437A748BA8222526BF9309957F8CD@aime2k302.adaptec.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 515708a075ffdf0a79d1c83b601e2afd Cc: ips@ietf.org X-BeenThere: ips@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IP Storage List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: ips-bounces@ietf.org It is an excellent point which I think also was brought up in Montreal (see Final minutes by David Black). However, I believe I have addressed this concern with the following text in the latest version I posted to the list on 07/13/2006 06:34 PM (see draft-ietf-ips-iscsi-nodearch-key-01r2.txt): Nodes implementing this key may choose to only transmit the key, only log the key values received from other nodes, or both transmit and log the key values. Each node choosing to implement transmission of the key values MUST be prepared to handle the response of [RFC3720] compliant nodes that do not understand the key ([RFC3720] states that compliant nodes MUST respond with X#NodeArchitecture=NotUnderstood). Does this paragraph address your concern? Sandars, Ken wrote: > Hi David, > > Making an extension key 'Declarative' seems problematic. > > Implementations which do not recognise the key will reply with > X=NotUnderstood. This may upset the proposer since "NotUnderstood" > is unlikely to be an acceptable use of the new key. > > "NotUnderstood" could be treated as a special case, but do we really > want a special case? > > Thoughts? > Ken > > > > -----Original Message----- > From: David Wysochanski [mailto:davidw@netapp.com] > Sent: Friday, 14 July 2006 08:34 > To: Black_David@emc.com > Cc: ips@ietf.org > Subject: Re: [Ips] DRAFT Montreal minutes - X#NodeArchitecture comments > > I think the attached addresses all of the comments below (or is pretty > close). I know the format is wrong in some cases (pages too long, etc) > but I'll fix that later. Diffing should be simpler. > > Some remaining points still for discussion: > 1) Still not sure about proper use / behavioral text > 2) Now explicitly states the key may be sent in either normal or > discovery sessions. > > Specific comments / explanations below. > > > Black_David@emc.com wrote: > > Dave, > > > > > A couple comments a points for clarification, while this is fresh > > on > everyone's minds below. > > > > > > > iSCSI X#NodeArchitecture Key: Dave Wysochanski, Network Appliance > > > - 30 min > > > > (draft-ietf-ips-iscsi-nodearch-key.txt) > > > > > > > > WG Discussion: > > > > - Key should be allowed only after Authentication. > Revise > > draft > > > > to impose this restriction > > > > > > > This is actually already in there if you read the fine print of the > > > "Use" > > portion of > > > the declaration and note that "Any-Stage" is not there (see Section > > 12 in > > 3720). > > > Since it has come up repeatedly though from various people, I will > > add some > text to point this out explicitly and refer to Sections 11 > > > and 12 of 3720. > > > > Yes, please do that. > > > > This has been fixed with a small change to the first sentence of > paragraph 3, section 1.2 and added a second paragraph in section 2. > > > > > > - Make sure it's a regular-size text key (not a big one, > like > > the > > > > one used for the large numbers involved in some > > authentication > > > > methods). > > > > > > > Was the comment to limit the value size to 255 bytes, i.e. a single > > > > "text-value" (or "simple-value"), as defined by 3720, or something > else? > > > > Limiting the value size to 255 bytes was the intention. > > > > > I liked the comma separated values and list-of-values seemed to > > > fit well. But if there are concerns about key length I suppose we > > > can add an explicit max length of the list-of-values. Another > > reviewer > raised the question about the maximum length early on so > > perhaps > an explicit limit is the way to go here. > > > > An explicit limit is probably a good idea, as an implementation that > > receives this key and doesn't recognize it may only log the first > > 255 bytes, so imposing that as a max limit may encourage more useful > > behavior from implementations that aren't expecting the key. > > > > Addressed in Section 2. > > > > > > - "protocol logic": crucial point is that **behavior** is > the > > same > > > > independent of presence, absence, or content of > the > > key. > > Add > > > > or revise text to make this point. > > > > > > > Was the consensus that the original term, "functional behavior", > > > > was clear enough, and I just muddied the water by trying to > make it > > > more crisp? > > > > The "protocol logic" wording is not inherently a problem, but it is > > important that the on-the-wire "behavior" is unchanged, and "behavior" > > > is an important word. > > > > I put back the "functional behavior" term and made my added "protocol > logic" sentence parenthetical. > Please let me know if this hits the mark. > > > > > > - Document behavior of RFC 3720-compliant implementation > that > > > > receives this new key and does not understand it, > and > > how > > > > the other side deals with the resulting response. > > > > > > > Ok. > > > > > Adddressed with last paragraph added in 1.2. > The paragraph starts with a short discussion about possible valid > implementations, which complements part of the latter security section. > > > > > > - "configure different levels" text needs to be rephrased > > > to be > > > > specific that the amount of detail is what > changes > > across levels. > > > > > > > I'm not sure about this comment because I thought the existing text > > > > does just that. Here's what the text says today: > > > > > > all > > > implementations of this extension key SHOULD provide an > > > administrative mechanism to configure different levels of > > > detail in the extension key values and MUST provide an > > > administrative mechanism to disable sending the key. > > > > "levels of detail" seems to be less than perfectly clear. Talking > > about being able to set "amount of information" provided to one of > > several levels, and perhaps "verbosity" or "verbosity level" of the > > key could be clearer. > > > > I think this is clearer now. Please see paragraph 2, section 3. > > > > > > - Align ability to configure amount of details with > "SHOULD > > NOT" > > > > in Section 1.2 about administrative setting of > key > > value. > > > > (the prior "SHOULD NOT" appears to conflict with > this > > "SHOULD"). > > > > > > > Point taken - will work on it. > > > > > Also, I think addressed with slight modification to 3rd paragraph of > section 1.2 > > > > > > - Double-check there is a 3720-format definition of the > key, > > > > including description clearly in the draft. > > > > > > > Was the comment that the existing declaration in section 2 > > > conforms to section 12 of 3720, and specifically, section > 12.22? > > > > If it does, I think you're done. We weren't 100% sure in the meeting. > > > > I double checked this and I think for the most part it is there. > However, upon examination and more thinking, I do not see or remember a > reason to preclude use in discovery sessions (again, logging may be > useful), and 3270 does not seem to forbid declarative keys in discovery > sessions (are declarative keys "requests"?). Thus, I've clarified some > text to make this clear. Please let me know if there are objections to > this. If so, I will add "Irrelevant when: SessionType=Discovery" to the > key declaration and remove the references to discovery sessions. > > > > > > - Make the examples phony (no real company names), and > remove > > > > the double quotes ("), as they don't appear on > the > > wire. > > > > > > > Ok. Main intent in providing company names was to show valid > > > examples for implementers but I will remove them. Note that > RFC > > 2616 does have valid examples > > > > Examples: > > > > > > User-Agent: CERN-LineMode/2.15 libwww/2.17b3 > > > Server: Apache/0.8.4 > > > > The big concern was use of company names. Example, Inc. is definitely > > > ok, and non-offensive parodies of the company names used are probably > > fair game (Dave Noveck may already be thinking up some of the latter). > > > > Done. > > > > > > - Spaces are forbidden in text strings. See RFC 3720, > Section > > 5.1, > > > > and feel free to ask on the list for options on > how to > > deal > > > > with this. > > > > > > > Good catch - looks like I got carried away in my intent to provide > > > > clear examples. > > > > Replaced all spaces with underscores. > _______________________________________________ Ips mailing list Ips@ietf.org https://www1.ietf.org/mailman/listinfo/ips From ips-bounces@ietf.org Wed Aug 02 14:40:06 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1G8LdT-0008JR-SI; Wed, 02 Aug 2006 14:40:03 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1G8LdS-0008JJ-HH for ips@ietf.org; Wed, 02 Aug 2006 14:40:02 -0400 Received: from mononoke.wasabisystems.com ([66.173.145.228]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1G8LdR-0004Ui-9c for ips@ietf.org; Wed, 02 Aug 2006 14:40:02 -0400 Received: from [10.0.0.10] (h-66-166-188-91.sndacagl.covad.net [66.166.188.91]) by mononoke.wasabisystems.com (Postfix) with ESMTP id 2AF778715A; Wed, 2 Aug 2006 14:40:00 -0400 (EDT) In-Reply-To: <368FBF3D8437A748BA8222526BF9309957F8CD@aime2k302.adaptec.com> References: <368FBF3D8437A748BA8222526BF9309957F8CD@aime2k302.adaptec.com> Mime-Version: 1.0 (Apple Message framework v752.2) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: Content-Transfer-Encoding: 7bit From: William Studenmund Subject: Re: [Ips] DRAFT Montreal minutes - X#NodeArchitecture comments Date: Wed, 2 Aug 2006 11:39:53 -0700 To: "Sandars, Ken" X-Pgp-Agent: GPGMail 1.1.2 (Tiger) X-Mailer: Apple Mail (2.752.2) X-Spam-Score: 0.0 (/) X-Scan-Signature: 69a74e02bbee44ab4f8eafdbcedd94a1 Cc: ips@ietf.org X-BeenThere: ips@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IP Storage List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: ips-bounces@ietf.org -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On Aug 2, 2006, at 12:15 AM, Sandars, Ken wrote: > Hi David, > > Making an extension key 'Declarative' seems problematic. > > Implementations which do not recognise the key will reply with > X=NotUnderstood. This may upset the proposer since > "NotUnderstood" > is unlikely to be an acceptable use of the new key. > > "NotUnderstood" could be treated as a special case, but do we really > want a special case? We talked about this in Montreal. Or I tried to a bit. At this point, I think we have to accept "NotUnderstood" as a valid response to the key, indicating that the other side doesn't understand. We can't do anything different. We thus should state that "NotUnderstood" is an invalid X#NodeArchitecture value (you MUST never attempt to assert that it's your architecture value), and its presence in a response should be taken to mean the responder doesn't understand the key. Take care, Bill -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.1 (Darwin) iD8DBQFE0PF+DJT2Egh26K0RAo/HAJ9l/P5P2+IXBpxRoFpC7e+8xGFnqACgnK+h a0dpyEyHGiJAE89nyLXFzuk= =dvFt -----END PGP SIGNATURE----- _______________________________________________ Ips mailing list Ips@ietf.org https://www1.ietf.org/mailman/listinfo/ips From ips-bounces@ietf.org Thu Aug 03 02:26:38 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1G8Wf9-0003U4-Rf; Thu, 03 Aug 2006 02:26:31 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1G8Wf8-0003Se-QX for ips@ietf.org; Thu, 03 Aug 2006 02:26:30 -0400 Received: from stsc1260-eth-s1-s1p1-vip.va.neustar.com ([156.154.16.129] helo=chiedprmail1.ietf.org) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1G8NAq-00029o-2i for ips@ietf.org; Wed, 02 Aug 2006 16:18:36 -0400 Received: from mx2.netapp.com ([216.240.18.37]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1G8Mp6-00008h-7s for ips@ietf.org; Wed, 02 Aug 2006 15:56:10 -0400 Received: from smtp2.corp.netapp.com ([10.57.159.114]) by mx2.netapp.com with ESMTP; 02 Aug 2006 12:56:05 -0700 X-IronPort-AV: i="4.07,206,1151910000"; d="scan'208"; a="397742929:sNHT18087376" Received: from [10.61.17.67] ([10.61.17.67]) by smtp2.corp.netapp.com (8.13.1/8.13.1/NTAP-1.6) with ESMTP id k72Jtx7F009496; Wed, 2 Aug 2006 12:56:04 -0700 (PDT) Message-ID: <44D1034F.9000501@netapp.com> Date: Wed, 02 Aug 2006 15:55:59 -0400 From: David Wysochanski User-Agent: Thunderbird 1.5.0.2 (X11/20060420) MIME-Version: 1.0 To: William Studenmund Subject: Re: [Ips] DRAFT Montreal minutes - X#NodeArchitecture comments References: <368FBF3D8437A748BA8222526BF9309957F8CD@aime2k302.adaptec.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: -2.6 (--) X-Scan-Signature: 52f7a77164458f8c7b36b66787c853da Cc: ips@ietf.org, "Sandars, Ken" X-BeenThere: ips@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IP Storage List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: ips-bounces@ietf.org William Studenmund wrote: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > On Aug 2, 2006, at 12:15 AM, Sandars, Ken wrote: > > > Hi David, > > > > Making an extension key 'Declarative' seems problematic. > > > > Implementations which do not recognise the key will reply with > > X=NotUnderstood. This may upset the proposer since > > "NotUnderstood" > > is unlikely to be an acceptable use of the new key. > > > > "NotUnderstood" could be treated as a special case, but do we really > > want a special case? > > We talked about this in Montreal. Or I tried to a bit. > > At this point, I think we have to accept "NotUnderstood" as a valid > response to the key, indicating that the other side doesn't > understand. We can't do anything different. > > We thus should state that "NotUnderstood" is an invalid > X#NodeArchitecture value (you MUST never attempt to assert that it's > your architecture value), and its presence in a response should be > taken to mean the responder doesn't understand the key. > Ah, thanks for pointing out that last part. I think RFC3720 already handles usage of "NotUnderstood" as a value for any key. I can add an explicit sentence forbidding its use as you've stated, but I didn't get that was what was desired from the final minutes. Here's the section from 3720, p. 54 I'm referring to: The constants "None", "Reject", "Irrelevant", and "NotUnderstood" are reserved and MUST ONLY be used as described here. Violation of this rule is a protocol error (in particular the use of "Reject", "Irrelevant", and "NotUnderstood" as proposed values). Here's what the final minutes had: - Document behavior of RFC 3720-compliant implementation that receives this new key and does not understand it, and how the other side deals with the resulting response. Finally, some new proposed text with the explicit forbidding of "NotUnderstood" (see the last sentence). Nodes implementing this key may choose to only transmit the key, only log the key values received from other nodes, or both transmit and log the key values. Each node choosing to implement transmission of the key values MUST be prepared to handle the response of [RFC3720] compliant nodes that do not understand the key ([RFC3720] states that compliant nodes MUST respond with X#NodeArchitecture=NotUnderstood). In addition, a node implementing transmission MUST NOT transmit "NotUnderstood" as its value, as this is a reserved value for all keys [RFC3720]. _______________________________________________ Ips mailing list Ips@ietf.org https://www1.ietf.org/mailman/listinfo/ips From ips-bounces@ietf.org Thu Aug 03 05:25:57 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1G8ZSi-0000CA-HV; Thu, 03 Aug 2006 05:25:52 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1G8ZSh-0000BH-26 for ips@ietf.org; Thu, 03 Aug 2006 05:25:51 -0400 Received: from stsc1260-eth-s1-s1p1-vip.va.neustar.com ([156.154.16.129] helo=chiedprmail1.ietf.org) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1G8XeJ-0004Im-GR for ips@ietf.org; Thu, 03 Aug 2006 03:29:43 -0400 Received: from mail-gw3.adaptec.com ([216.52.22.36]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1G8XYd-0005sm-3n for ips@ietf.org; Thu, 03 Aug 2006 03:23:52 -0400 Received: from aime2k05.adaptec.com (aime2k05.adaptec.com [10.25.8.46]) by mail-gw3.adaptec.com (Spam Firewall) with ESMTP id B831F1349E9; Thu, 3 Aug 2006 00:23:41 -0700 (PDT) Received: from aime2k302.adaptec.com ([10.25.8.48]) by aime2k05.adaptec.com with Microsoft SMTPSVC(5.0.2195.6713); Thu, 3 Aug 2006 00:23:41 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5 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] DRAFT Montreal minutes - X#NodeArchitecture comments Date: Thu, 3 Aug 2006 00:23:40 -0700 Message-ID: <368FBF3D8437A748BA8222526BF9309957F8D4@aime2k302.adaptec.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Ips] DRAFT Montreal minutes - X#NodeArchitecture comments Thread-Index: Aca2bbNA3khFJ+0uSmirz/4rbcAaKgALK4NA From: "Sandars, Ken" To: "David Wysochanski" X-OriginalArrivalTime: 03 Aug 2006 07:23:41.0650 (UTC) FILETIME=[BF0D2B20:01C6B6CD] X-Virus-Scanned: by Barracuda Spam Firewall at adaptec.com X-Spam-Score: -2.6 (--) X-Scan-Signature: cf3becbbd6d1a45acbe2ffd4ab88bdc2 Cc: ips@ietf.org, William Studenmund X-BeenThere: ips@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IP Storage List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: ips-bounces@ietf.org Hi David, It might be clearer to rephrase the paragraph to cover the node's obligations when declaring the key, and when receiving it. Something like: Nodes implementing this key MAY declare the key. Nodes implementing this key MAY discard the key values received from other nodes. Each node which declares the key MUST be prepared to handle the response of [RFC3720] compliant nodes that do not understand the key ([RFC3720] states that compliant nodes MUST respond with X#NodeArchitecture=3DNotUnderstood). In addition, a node which implements this key MUST NOT declare "NotUnderstood" as its value. A node which receives the value "NotUnderstood" for this key SHOULD discard the value. Regardless of whether the received value is discarded, the key MUST be considered to have been declared.=20 =20 Thoughts? Ken -----Original Message----- From: David Wysochanski [mailto:davidw@netapp.com]=20 Sent: Thursday, 3 August 2006 05:56 To: William Studenmund Cc: Sandars, Ken; ips@ietf.org Subject: Re: [Ips] DRAFT Montreal minutes - X#NodeArchitecture comments William Studenmund wrote: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 >=20 > On Aug 2, 2006, at 12:15 AM, Sandars, Ken wrote: >=20 > > Hi David, > > > > Making an extension key 'Declarative' seems problematic. > > > > Implementations which do not recognise the key will reply with >=20 > X=3DNotUnderstood. This may upset the proposer since >=20 > "NotUnderstood" > > is unlikely to be an acceptable use of the new key. > > > > "NotUnderstood" could be treated as a special case, but do we=20 > really > want a special case? >=20 > We talked about this in Montreal. Or I tried to a bit. >=20 > At this point, I think we have to accept "NotUnderstood" as a valid=20 > response to the key, indicating that the other side doesn't=20 > understand. We can't do anything different. >=20 > We thus should state that "NotUnderstood" is an invalid=20 > X#NodeArchitecture value (you MUST never attempt to assert that it's=20 > your architecture value), and its presence in a response should be=20 > taken to mean the responder doesn't understand the key. >=20 Ah, thanks for pointing out that last part. I think RFC3720 already handles usage of "NotUnderstood" as a value for any key. I can add an explicit sentence forbidding its use as you've stated, but I didn't get that was what was desired from the final minutes. Here's the section from 3720, p. 54 I'm referring to: The constants "None", "Reject", "Irrelevant", and "NotUnderstood" are reserved and MUST ONLY be used as described here. Violation of this rule is a protocol error (in particular the use of "Reject", "Irrelevant", and "NotUnderstood" as proposed values). Here's what the final minutes had: - Document behavior of RFC 3720-compliant implementation that receives this new key and does not understand it, and how the other side deals with the resulting response. Finally, some new proposed text with the explicit forbidding of "NotUnderstood" (see the last sentence). Nodes implementing this key may choose to only transmit the key, only log the key values received from other nodes, or both transmit and log the key values. Each node choosing to implement transmission of the key values MUST be prepared to handle the response of [RFC3720] compliant nodes that do not understand the key ([RFC3720] states that compliant nodes MUST respond with X#NodeArchitecture=3DNotUnderstood). In addition, a node = implementing transmission MUST NOT transmit "NotUnderstood" as its value, as this is a reserved value for all keys [RFC3720]. _______________________________________________ Ips mailing list Ips@ietf.org https://www1.ietf.org/mailman/listinfo/ips From ips-bounces@ietf.org Thu Aug 03 14:52:04 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1G8iIT-0007J9-Fb; Thu, 03 Aug 2006 14:51:53 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1G8iIS-0007IP-Ng for ips@ietf.org; Thu, 03 Aug 2006 14:51:52 -0400 Received: from mx2.netapp.com ([216.240.18.37]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1G8iIS-0006cD-9V for ips@ietf.org; Thu, 03 Aug 2006 14:51:52 -0400 Received: from smtp2.corp.netapp.com ([10.57.159.114]) by mx2.netapp.com with ESMTP; 03 Aug 2006 11:51:52 -0700 X-IronPort-AV: i="4.07,209,1151910000"; d="scan'208"; a="398007462:sNHT108678448" Received: from [10.61.17.67] ([10.61.17.67]) by smtp2.corp.netapp.com (8.13.1/8.13.1/NTAP-1.6) with ESMTP id k73IpkIg029708; Thu, 3 Aug 2006 11:51:46 -0700 (PDT) Message-ID: <44D245C1.4050706@netapp.com> Date: Thu, 03 Aug 2006 14:51:45 -0400 From: David Wysochanski User-Agent: Thunderbird 1.5.0.2 (X11/20060420) MIME-Version: 1.0 To: "Sandars, Ken" Subject: Re: [Ips] DRAFT Montreal minutes - X#NodeArchitecture comments References: <368FBF3D8437A748BA8222526BF9309957F8D4@aime2k302.adaptec.com> In-Reply-To: <368FBF3D8437A748BA8222526BF9309957F8D4@aime2k302.adaptec.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 8fbbaa16f9fd29df280814cb95ae2290 Cc: ips@ietf.org, William Studenmund X-BeenThere: ips@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IP Storage List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: ips-bounces@ietf.org Sandars, Ken wrote: > Hi David, > > It might be clearer to rephrase the paragraph to cover the node's > obligations when declaring the key, and when receiving it. Something > like: > We can certainly clarify the wording. > Nodes implementing this key MAY declare the key. Nodes implementing > this key MAY discard the key values received from other nodes. > I'm not sure this is clearer than what I had below but maybe someone else has can chime in. The "declare" wording may be more consistent with 3720 though. > Each node which declares the key MUST be prepared to handle the > response of [RFC3720] compliant nodes that do not understand the > key ([RFC3720] states that compliant nodes MUST respond with > X#NodeArchitecture=NotUnderstood). In addition, a node which > implements this key MUST NOT declare "NotUnderstood" as its > value. > Seems fine. > A node which receives the value "NotUnderstood" for this key SHOULD > discard the value. Regardless of whether the received value is > discarded, the key MUST be considered to have been declared. > Isn't this last sentence in conflict with the RFC paragraph I mention below? Sending "NotUnderstood" in a key value is a protocol error, so why would a node receiving it be forced to consider the other node having declared it? Note also that I added this wording: Nodes implementing this key may choose to only transmit the key, only log the key values received from other nodes, or both transmit and log the key values. Each node choosing to implement to match some of the wording in the security section: For the above target, an appropriate implementation might be logging of received key values, but no transmission of the key. For the initiators, an appropriate implementation might be transmission of the key, but no logging of received key values. I was also thinking from my developer's hat and compartmentalizing the differing parts of the implementation (which have different things to think about). On my end I have two different coding items to track the transmission of the key vs the logging. > Thoughts? > Ken > > -----Original Message----- > From: David Wysochanski [mailto:davidw@netapp.com] > Sent: Thursday, 3 August 2006 05:56 > To: William Studenmund > Cc: Sandars, Ken; ips@ietf.org > Subject: Re: [Ips] DRAFT Montreal minutes - X#NodeArchitecture comments > > William Studenmund wrote: > > -----BEGIN PGP SIGNED MESSAGE----- > > Hash: SHA1 > > > > On Aug 2, 2006, at 12:15 AM, Sandars, Ken wrote: > > > > > Hi David, > > > > > > Making an extension key 'Declarative' seems problematic. > > > > > > Implementations which do not recognise the key will reply with > > > X=NotUnderstood. This may upset the proposer since > > > "NotUnderstood" > > > is unlikely to be an acceptable use of the new key. > > > > > > "NotUnderstood" could be treated as a special case, but do we > > really > want a special case? > > > > We talked about this in Montreal. Or I tried to a bit. > > > > At this point, I think we have to accept "NotUnderstood" as a valid > > response to the key, indicating that the other side doesn't > > understand. We can't do anything different. > > > > We thus should state that "NotUnderstood" is an invalid > > X#NodeArchitecture value (you MUST never attempt to assert that it's > > your architecture value), and its presence in a response should be > > taken to mean the responder doesn't understand the key. > > > > Ah, thanks for pointing out that last part. > > I think RFC3720 already handles usage of "NotUnderstood" as a value for > any key. I can add an explicit sentence forbidding its use as you've > stated, but I didn't get that was what was desired from the final > minutes. > > Here's the section from 3720, p. 54 I'm referring to: > > The constants "None", "Reject", "Irrelevant", and "NotUnderstood" > are > reserved and MUST ONLY be used as described here. Violation of this > rule is a protocol error (in particular the use of "Reject", > "Irrelevant", and "NotUnderstood" as proposed values). > > > Here's what the final minutes had: > > - Document behavior of RFC 3720-compliant implementation that > receives this new key and does not understand it, and > how > the other side deals with the resulting response. > > > Finally, some new proposed text with the explicit forbidding of > "NotUnderstood" (see the last sentence). > > Nodes implementing this key may choose to only transmit the > key, only log the key values received from other nodes, or both > transmit and log the key values. Each node choosing to implement > transmission of the key values MUST be prepared to handle the > response of [RFC3720] compliant nodes that do not understand the > key ([RFC3720] states that compliant nodes MUST respond with > X#NodeArchitecture=NotUnderstood). In addition, a node implementing > transmission MUST NOT transmit "NotUnderstood" as its value, > as this is a reserved value for all keys [RFC3720]. > _______________________________________________ Ips mailing list Ips@ietf.org https://www1.ietf.org/mailman/listinfo/ips From ips-bounces@ietf.org Thu Aug 03 15:04:14 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1G8iUQ-0003Mm-6Z; Thu, 03 Aug 2006 15:04:14 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1G8iUO-0003MU-1M for ips@ietf.org; Thu, 03 Aug 2006 15:04:12 -0400 Received: from sadr.equallogic.com ([66.155.203.134]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1G8iUM-0008Jx-Pz for ips@ietf.org; Thu, 03 Aug 2006 15:04:12 -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 k73J4ARo024408 for ; Thu, 3 Aug 2006 15:04:10 -0400 Received: from M31.equallogic.com (M31.equallogic.com [172.16.1.31]) by sadr.equallogic.com (8.12.8/8.12.8) with SMTP id k73J4AfA024403; Thu, 3 Aug 2006 15:04:10 -0400 Received: from pkoning.equallogic.com ([172.16.1.124]) by M31.equallogic.com with Microsoft SMTPSVC(6.0.3790.211); Thu, 3 Aug 2006 15:04:09 -0400 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <17618.18600.273364.982890@gargle.gargle.HOWL> Date: Thu, 3 Aug 2006 15:04:08 -0400 From: Paul Koning To: davidw@netapp.com Subject: Re: [Ips] DRAFT Montreal minutes - X#NodeArchitecture comments References: <368FBF3D8437A748BA8222526BF9309957F8D4@aime2k302.adaptec.com> <44D245C1.4050706@netapp.com> X-Mailer: VM 7.17 under 21.5 (beta27) "fiddleheads" XEmacs Lucid X-OriginalArrivalTime: 03 Aug 2006 19:04:09.0978 (UTC) FILETIME=[99E315A0:01C6B72F] X-Spam-Score: 0.0 (/) X-Scan-Signature: 8abaac9e10c826e8252866cbe6766464 Cc: ips@ietf.org, wrstuden@wasabisystems.com, ken_sandars@adaptec.com X-BeenThere: ips@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IP Storage List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: ips-bounces@ietf.org >>>>> "David" == David Wysochanski writes: >> Each node which declares the key MUST be prepared to handle the >> response of [RFC3720] compliant nodes that do not understand the >> key ([RFC3720] states that compliant nodes MUST respond with >> X#NodeArchitecture=NotUnderstood). In addition, a node which >> implements this key MUST NOT declare "NotUnderstood" as its value. >> David> Seems fine. Those are just the standard 3720 rules, right? It seems confusing to restate them explicitly, because it creates the impression that this key uses rules that are different in some way from the usual rules. If you do want to state the rules explicitly here, you might include a comment to the effect that "The normal rules for key handling apply, which are ..." >> A node which receives the value "NotUnderstood" for this key >> SHOULD discard the value. Regardless of whether the received value >> is discarded, the key MUST be considered to have been declared. >> David> Isn't this last sentence in conflict with the RFC paragraph I David> mention below? Sending "NotUnderstood" in a key value is a David> protocol error, so why would a node receiving it be forced to David> consider the other node having declared it? I agree. The spec says it's a protocol error, the rules for handling protocol errors are defined already -- don't mess with it. paul _______________________________________________ Ips mailing list Ips@ietf.org https://www1.ietf.org/mailman/listinfo/ips From ips-bounces@ietf.org Thu Aug 03 15:36:34 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1G8izg-0004Ob-Td; Thu, 03 Aug 2006 15:36:32 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1G8izf-0004OW-Ca for ips@ietf.org; Thu, 03 Aug 2006 15:36:31 -0400 Received: from nwkea-mail-2.sun.com ([192.18.42.14]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1G8izd-0006AD-TA for ips@ietf.org; Thu, 03 Aug 2006 15:36:31 -0400 Received: from centralmail4brm.central.Sun.COM ([129.147.62.198]) by nwkea-mail-2.sun.com (8.13.6+Sun/8.12.9) with ESMTP id k73JaSKo011235 for ; Thu, 3 Aug 2006 12:36:29 -0700 (PDT) Received: from binky.Central.Sun.COM (binky.Central.Sun.COM [129.153.128.104]) by centralmail4brm.central.Sun.COM (8.13.6+Sun/8.13.6/ENSMAIL, v2.2) with ESMTP id k73JaR5J007614 for ; Thu, 3 Aug 2006 13:36:28 -0600 (MDT) Received: from binky.Central.Sun.COM (localhost [127.0.0.1]) by binky.Central.Sun.COM (8.13.6+Sun/8.13.6) with ESMTP id k73JaRhq023694; Thu, 3 Aug 2006 14:36:27 -0500 (CDT) Received: (from nw141292@localhost) by binky.Central.Sun.COM (8.13.6+Sun/8.13.6/Submit) id k73JaR8w023693; Thu, 3 Aug 2006 14:36:27 -0500 (CDT) Date: Thu, 3 Aug 2006 14:36:27 -0500 From: Nicolas Williams To: Black_David@emc.com Subject: Re: [Ips] DRAFT Montreal minutes Message-ID: <20060803193626.GX22408@binky.Central.Sun.COM> References: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.7i X-Spam-Score: 0.0 (/) X-Scan-Signature: 082a9cbf4d599f360ac7f815372a6a15 Cc: ips@ietf.org X-BeenThere: ips@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IP Storage List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: ips-bounces@ietf.org On Wed, Jul 12, 2006 at 07:51:58PM -0400, Black_David@emc.com wrote: > iSCSI Security Mechanisms: WG Members - time remaining (if any) > > The IETF Security Area has requested that IETF Working Groups plan > to transition away from usage of MD5. iSCSI CHAP currently uses > MD5 in a fashion not directly threatened by the hash collision > results known for MD5. If time is available in the meeting, it > will be used to discuss what to do instead, as using a different > hash with CHAP is not the only option. > > Above description is copied verbatim from Dallas agenda. There > are two other related concerns: > a) The Kerberos support in iSCSI is frowned upon by Kerberos > experts. iSCSI Kerberos is not GSSAPI-based, and hence > can't be used with GSSAPI-only Kerberos implementations. (a) is no longer an issue for me... > b) The SPKM-1 and SPKM-2 methods are arguably obsolete. Yes, but also it made no sense to specify their use without specifying the use of the GSS-API. > SASL is a potential means of addressing all of these problems: > - SASL has and/or will have methods based on SHA-256, the > next hash of choice (according to the IETF Security Area) > - SASL has GSSAPI-based Kerberos support that has been > designed by Kerberos experts > - SASL has an SPKM-3 method. SASL has no SPKM-3 mechanism. The GSS-API does (see below). SPKM-3 is being revised by individual submitters; it's currently undergoing expert review. SASL's GSS-API bridge currently only really works with the Kerberos V mechanism. There's a new SASL GSS-API bridge in the works that will be much more general and which introduces a SASL-specific channel binding concept. > The approach would be to add SASL methods to iSCSI by doing > mapping the SASL tokens into iSCSI and providing authentication > mechanism names (e.g., the SASL mechanism is negotiated > by iSCSI as the SASL- mechanism). These would be additions > - the current must-implement CHAP mechanism is not broken, and > would not be removed. Sure. > There may be a draft forthcoming that will add SASL to iSCSI - > the sense of the room is that this would be a good thing to > do, although it is not of immediate urgency. I agree. Longer term, when the BTNS WG completes work on "connection latching" (how to construct "IPsec channels") and IPsec APIs then iSCSI should be able to specify a profile of iSCSI using SASL channel binding to IPsec channels and simplify IPsec configuration. Nico -- _______________________________________________ Ips mailing list Ips@ietf.org https://www1.ietf.org/mailman/listinfo/ips From ips-bounces@ietf.org Thu Aug 03 16:34:09 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1G8jtF-0003iT-Ec; Thu, 03 Aug 2006 16:33:57 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1G8jtD-0003bY-BV for ips@ietf.org; Thu, 03 Aug 2006 16:33:55 -0400 Received: from mexforward.lss.emc.com ([128.222.32.20]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1G8jrv-0004zj-8w for ips@ietf.org; Thu, 03 Aug 2006 16:32:36 -0400 Received: from mailhub.lss.emc.com (nagas.lss.emc.com [10.254.144.11]) by mexforward.lss.emc.com (Switch-3.1.8/Switch-3.1.7) with ESMTP id k73KWYjn004217; Thu, 3 Aug 2006 16:32:34 -0400 (EDT) Received: from MAHO3MSX2.corp.emc.com (maho3msx2.corp.emc.com [128.221.11.32]) by mailhub.lss.emc.com (Switch-3.1.8/Switch-3.1.7) with ESMTP id k73KWWCl009075; Thu, 3 Aug 2006 16:32:33 -0400 (EDT) Received: by maho3msx2.corp.emc.com with Internet Mail Service (5.5.2653.19) id ; Thu, 3 Aug 2006 16:32:32 -0400 Message-ID: From: Black_David@emc.com To: Nicolas.Williams@sun.com Subject: RE: [Ips] DRAFT Montreal minutes Date: Thu, 3 Aug 2006 16:32:17 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain X-PMX-Version: 4.7.1.128075, Antispam-Engine: 2.4.0.264935, Antispam-Data: 2006.8.1.75432 X-PerlMx-Spam: Gauge=, SPAM=0%, Reason='EMC_BODY_1+ -3, EMC_FROM_0+ -2, NO_REAL_NAME 0, __C230066_P5 0, __CT 0, __CT_TEXT_PLAIN 0, __HAS_MSGID 0, __HAS_X_MAILER 0, __IMS_MSGID 0, __IMS_MUA 0, __MIME_TEXT_ONLY 0, __MIME_VERSION 0, __SANE_MSGID 0, __STOCK_CRUFT 0' X-Spam-Score: 0.2 (/) X-Scan-Signature: a2c12dacc0736f14d6b540e805505a86 Cc: ips@ietf.org X-BeenThere: ips@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IP Storage List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: ips-bounces@ietf.org > > - SASL has an SPKM-3 method. > > SASL has no SPKM-3 mechanism. The GSS-API does (see below). My sloppiness - what Nico describes about SASL having a generic GSS-API bridge (GS2) in the works that will provide a means to use SPKM3 is what I had in mind. 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: Nicolas Williams [mailto:Nicolas.Williams@sun.com] > Sent: Thursday, August 03, 2006 3:36 PM > To: Black, David > Cc: ips@ietf.org > Subject: Re: [Ips] DRAFT Montreal minutes > > On Wed, Jul 12, 2006 at 07:51:58PM -0400, Black_David@emc.com wrote: > > iSCSI Security Mechanisms: WG Members - time remaining (if any) > > > > The IETF Security Area has requested that IETF Working > Groups plan > > to transition away from usage of MD5. iSCSI CHAP currently uses > > MD5 in a fashion not directly threatened by the hash collision > > results known for MD5. If time is available in the meeting, it > > will be used to discuss what to do instead, as using a different > > hash with CHAP is not the only option. > > > > Above description is copied verbatim from Dallas agenda. There > > are two other related concerns: > > a) The Kerberos support in iSCSI is frowned upon by Kerberos > > experts. iSCSI Kerberos is not GSSAPI-based, and hence > > can't be used with GSSAPI-only Kerberos implementations. > > (a) is no longer an issue for me... > > > b) The SPKM-1 and SPKM-2 methods are arguably obsolete. > > Yes, but also it made no sense to specify their use without specifying > the use of the GSS-API. > > > SASL is a potential means of addressing all of these problems: > > - SASL has and/or will have methods based on SHA-256, the > > next hash of choice (according to the IETF Security Area) > > - SASL has GSSAPI-based Kerberos support that has been > > designed by Kerberos experts > > - SASL has an SPKM-3 method. > > SASL has no SPKM-3 mechanism. The GSS-API does (see below). > > SPKM-3 is being revised by individual submitters; it's currently > undergoing expert review. > > SASL's GSS-API bridge currently only really works with the Kerberos V > mechanism. There's a new SASL GSS-API bridge in the works that will > be much more general and which introduces a SASL-specific channel > binding concept. > > > The approach would be to add SASL methods to iSCSI by doing > > mapping the SASL tokens into iSCSI and providing authentication > > mechanism names (e.g., the SASL mechanism is negotiated > > by iSCSI as the SASL- mechanism). These would be additions > > - the current must-implement CHAP mechanism is not broken, and > > would not be removed. > > Sure. > > > There may be a draft forthcoming that will add SASL to iSCSI - > > the sense of the room is that this would be a good thing to > > do, although it is not of immediate urgency. > > I agree. > > Longer term, when the BTNS WG completes work on "connection latching" > (how to construct "IPsec channels") and IPsec APIs then iSCSI > should be > able to specify a profile of iSCSI using SASL channel binding to IPsec > channels and simplify IPsec configuration. > > Nico > -- > > _______________________________________________ > 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 ips-bounces@ietf.org Thu Aug 03 16:47:53 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1G8k6Y-0004hx-F6; Thu, 03 Aug 2006 16:47:42 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1G8k6X-0004hs-VZ for ips@ietf.org; Thu, 03 Aug 2006 16:47:41 -0400 Received: from brmea-mail-2.sun.com ([192.18.98.43]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1G8k6W-0006od-Ky for ips@ietf.org; Thu, 03 Aug 2006 16:47:41 -0400 Received: from centralmail3brm.Central.Sun.COM ([129.147.62.199]) by brmea-mail-2.sun.com (8.13.6+Sun/8.12.9) with ESMTP id k73Klejb011894 for ; Thu, 3 Aug 2006 14:47:40 -0600 (MDT) Received: from binky.Central.Sun.COM (binky.Central.Sun.COM [129.153.128.104]) by centralmail3brm.Central.Sun.COM (8.13.6+Sun/8.13.6/ENSMAIL, v2.2) with ESMTP id k73Ki8EJ016619 for ; Thu, 3 Aug 2006 14:44:08 -0600 (MDT) Received: from binky.Central.Sun.COM (localhost [127.0.0.1]) by binky.Central.Sun.COM (8.13.6+Sun/8.13.6) with ESMTP id k73KldRB023797; Thu, 3 Aug 2006 15:47:39 -0500 (CDT) Received: (from nw141292@localhost) by binky.Central.Sun.COM (8.13.6+Sun/8.13.6/Submit) id k73Kldfk023796; Thu, 3 Aug 2006 15:47:39 -0500 (CDT) Date: Thu, 3 Aug 2006 15:47:39 -0500 From: Nicolas Williams To: Black_David@emc.com Subject: Re: [Ips] DRAFT Montreal minutes Message-ID: <20060803204724.GD22408@binky.Central.Sun.COM> References: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.7i X-Spam-Score: 0.0 (/) X-Scan-Signature: cf4fa59384e76e63313391b70cd0dd25 Cc: ips@ietf.org X-BeenThere: ips@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IP Storage List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: ips-bounces@ietf.org On Thu, Aug 03, 2006 at 04:32:17PM -0400, Black_David@emc.com wrote: > > > - SASL has an SPKM-3 method. > > > > SASL has no SPKM-3 mechanism. The GSS-API does (see below). > > My sloppiness - what Nico describes about SASL having a generic > GSS-API bridge (GS2) in the works that will provide a means to > use SPKM3 is what I had in mind. Assuming that SPKM-3 progresses. But more importantly, you'll get all GSS-API mechanisms (we'll probably get more GSS mechs over time, starting with GSS bindings of DIGEST-MD5 or something of the sort), and that's architecturally what you want: an hole to be filled by others, that way you leave PKI to SPKM-3 without having to even mention it (except as a REQUIRED mechanism, but I think it'd be hard to REQUIRE anything other than Kerberos V at the moment). _______________________________________________ Ips mailing list Ips@ietf.org https://www1.ietf.org/mailman/listinfo/ips From ips-bounces@ietf.org Fri Aug 04 03:12:57 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1G8trY-0003d8-BZ; Fri, 04 Aug 2006 03:12:52 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1G8trW-0003cr-Jr for ips@ietf.org; Fri, 04 Aug 2006 03:12:50 -0400 Received: from stsc1260-eth-s1-s1p1-vip.va.neustar.com ([156.154.16.129] helo=chiedprmail1.ietf.org) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1G8trW-0006BS-HV for ips@ietf.org; Fri, 04 Aug 2006 03:12:50 -0400 Received: from mail-gw3.adaptec.com ([216.52.22.36]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1G8tqn-0007pG-Ap for ips@ietf.org; Fri, 04 Aug 2006 03:12:08 -0400 Received: from aime2k04.adaptec.com (aime2k04.adaptec.com [10.25.8.45]) by mail-gw3.adaptec.com (Spam Firewall) with ESMTP id C17867473C; Fri, 4 Aug 2006 00:11:55 -0700 (PDT) Received: from aime2k302.adaptec.com ([10.25.8.48]) by aime2k04.adaptec.com with Microsoft SMTPSVC(5.0.2195.6713); Fri, 4 Aug 2006 00:11:55 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5 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] DRAFT Montreal minutes - X#NodeArchitecture comments Date: Fri, 4 Aug 2006 00:11:54 -0700 Message-ID: <368FBF3D8437A748BA8222526BF9309957F8DC@aime2k302.adaptec.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Ips] DRAFT Montreal minutes - X#NodeArchitecture comments Thread-Index: Aca3LeIgVAIx/0XrQJm14Y7F8tS5owATcTVg From: "Sandars, Ken" To: "David Wysochanski" X-OriginalArrivalTime: 04 Aug 2006 07:11:55.0714 (UTC) FILETIME=[44B1A220:01C6B795] X-Virus-Scanned: by Barracuda Spam Firewall at adaptec.com X-Spam-Score: -2.6 (--) X-Scan-Signature: 311e798ce51dbeacf5cdfcc8e9fda21b Cc: ips@ietf.org, William Studenmund X-BeenThere: ips@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IP Storage List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: ips-bounces@ietf.org Hi David, Comments inline [Ken] Cheers Ken=20 > -----Original Message----- > From: David Wysochanski [mailto:davidw@netapp.com]=20 > Sent: Friday, 4 August 2006 04:52 > To: Sandars, Ken > Cc: ips@ietf.org; William Studenmund > Subject: Re: [Ips] DRAFT Montreal minutes -=20 > X#NodeArchitecture comments >=20 > Sandars, Ken wrote: > > Hi David, > >=20 > > It might be clearer to rephrase the paragraph to cover the node's=20 > > obligations when declaring the key, and when receiving it. Something > > like: > >=20 > We can certainly clarify the wording. >=20 >=20 > > Nodes implementing this key MAY declare the key. Nodes=20 > implementing > > this key MAY discard the key values received from other nodes. > >=20 > I'm not sure this is clearer than what I had below but maybe=20 > someone else has can chime in. The "declare" wording may be=20 > more consistent with 3720 though. >=20 >=20 > > Each node which declares the key MUST be prepared to handle the > > response of [RFC3720] compliant nodes that do not understand the > > key ([RFC3720] states that compliant nodes MUST respond with > > X#NodeArchitecture=3DNotUnderstood). In addition, a node which > > implements this key MUST NOT declare "NotUnderstood" as its > > value. > >=20 > Seems fine. >=20 > > A node which receives the value "NotUnderstood" for=20 > this key SHOULD > > discard the value. Regardless of whether the received value is > > discarded, the key MUST be considered to have been declared. > > =20 >=20 > Isn't this last sentence in conflict with the RFC paragraph I=20 > mention below? =20 [Ken] No. The idea is to catch the required behaviour. It has to consider that to the nodes who know, the key is declarative, while for others the key is negotiated (hence the NotUnderstood response is legal). Thus the negotiation engine needs to track that once it has declared the key the other node is only allowed to: (1) declare a valid value for the key, or (2) send a response of "NotUnderstood", or (3) do nothing more with the key. > Sending "NotUnderstood" in a key value is a=20 > protocol error, so why would a node receiving it be forced to=20 > consider the other node having declared it? >=20 [Ken] It's not a protocol error for a node which doesn't implement this extension key. Don't confuse the term 'declare' with 'propose'/'accept'. Nodes which implement this key know it's a Declarative key; for other implementations the key is negotiated. [Ken] The reason it should be considered 'declared' is because it has been received (parameter negotiation engines tend to get this right). It will be a protocol error if the other node sends it again (obviously in error). This applies equally to nodes which are aware of the key and those which are not. I also wanted to indicate that even if the value of the received key is not used in the intended logging role (say is discarded), the parameter negotiation engine still needs to note that the other node has sent it once and to barf if it sees it again.=20 [Ken] For example, consider a broken implementation which thinks it's cute to declare the key, but doesn't update its reception engine to recognise the inbound key (because it isn't interested in logging the info). This is test suite paradise! ;-) > Note also that I added this wording: > Nodes implementing this key may choose to only transmit the > key, only log the key values received from other nodes, or both > transmit and log the key values. Each node choosing to implement >=20 > to match some of the wording in the security section: > For the above target, an appropriate implementation might be > logging of received key values, but no transmission of the key. > For the initiators, an appropriate implementation might be > transmission of the key, but no logging of received key values. >=20 > I was also thinking from my developer's hat and=20 > compartmentalizing the differing parts of the implementation=20 > (which have different things to think about). On my end I=20 > have two different coding items to track the transmission of=20 > the key vs the logging. >=20 [Ken] Fair enough, but what about the option to not send and to not log? That's why I proposed a different set of words for that part. >=20 > > Thoughts? > > Ken > >=20 > > -----Original Message----- > > From: David Wysochanski [mailto:davidw@netapp.com] > > Sent: Thursday, 3 August 2006 05:56 > > To: William Studenmund > > Cc: Sandars, Ken; ips@ietf.org > > Subject: Re: [Ips] DRAFT Montreal minutes - X#NodeArchitecture=20 > > comments > >=20 > > William Studenmund wrote: > > > -----BEGIN PGP SIGNED MESSAGE----- > > > Hash: SHA1 > > > > > > On Aug 2, 2006, at 12:15 AM, Sandars, Ken wrote: > > > > > > > Hi David, > > > > > > > > Making an extension key 'Declarative' seems problematic. > > > > > > > > Implementations which do not recognise the key will=20 > reply with =20 > > > > X=3DNotUnderstood. This may upset the proposer since > = >=20 > > "NotUnderstood" > > > > is unlikely to be an acceptable use of the new key. > > > > > > > > "NotUnderstood" could be treated as a special case,=20 > but do we >=20 > > really > want a special case? > > > > > > We talked about this in Montreal. Or I tried to a bit. > > > > > > At this point, I think we have to accept "NotUnderstood"=20 > as a valid =20 > > > response to the key, indicating that the other side doesn't >=20 > > understand. We can't do anything different. > > > > > > We thus should state that "NotUnderstood" is an invalid >=20 > > X#NodeArchitecture value (you MUST never attempt to assert=20 > that it's =20 > > > your architecture value), and its presence in a response=20 > should be =20 > > > taken to mean the responder doesn't understand the key. > > > > >=20 > > Ah, thanks for pointing out that last part. > >=20 > > I think RFC3720 already handles usage of "NotUnderstood" as a value=20 > > for any key. I can add an explicit sentence forbidding its use as=20 > > you've stated, but I didn't get that was what was desired from the=20 > > final minutes. > >=20 > > Here's the section from 3720, p. 54 I'm referring to: > >=20 > > The constants "None", "Reject", "Irrelevant", and=20 > "NotUnderstood" > > are > > reserved and MUST ONLY be used as described here. =20 > Violation of this > > rule is a protocol error (in particular the use of "Reject", > > "Irrelevant", and "NotUnderstood" as proposed values). > >=20 > >=20 > > Here's what the final minutes had: > >=20 > > - Document behavior of RFC 3720-compliant=20 > implementation that > > receives this new key and does not=20 > understand it, and=20 > > how > > the other side deals with the resulting response. > >=20 > >=20 > > Finally, some new proposed text with the explicit forbidding of=20 > > "NotUnderstood" (see the last sentence). > >=20 > > Nodes implementing this key may choose to only transmit the > > key, only log the key values received from other nodes, or both > > transmit and log the key values. Each node choosing to=20 > implement > > transmission of the key values MUST be prepared to handle the > > response of [RFC3720] compliant nodes that do not understand the > > key ([RFC3720] states that compliant nodes MUST respond with > > X#NodeArchitecture=3DNotUnderstood). In addition, a node=20 > implementing > > transmission MUST NOT transmit "NotUnderstood" as its value, > > as this is a reserved value for all keys [RFC3720]. > >=20 >=20 _______________________________________________ Ips mailing list Ips@ietf.org https://www1.ietf.org/mailman/listinfo/ips From ips-bounces@ietf.org Mon Aug 07 02:31:07 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1G9yda-0001QC-LO; Mon, 07 Aug 2006 02:30:54 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1G9ydZ-0001Q6-2E for ips@ietf.org; Mon, 07 Aug 2006 02:30:53 -0400 Received: from stsc1260-eth-s1-s1p1-vip.va.neustar.com ([156.154.16.129] helo=chiedprmail1.ietf.org) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1G9ydZ-00017n-0a for ips@ietf.org; Mon, 07 Aug 2006 02:30:53 -0400 Received: from mx2.netapp.com ([216.240.18.37]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1G9yTJ-0000WJ-IS for ips@ietf.org; Mon, 07 Aug 2006 02:20:18 -0400 Received: from smtp2.corp.netapp.com ([10.57.159.114]) by mx2.netapp.com with ESMTP; 06 Aug 2006 23:20:14 -0700 X-IronPort-AV: i="4.07,216,1151910000"; d="scan'208"; a="398871709:sNHT15741480" Received: from [10.58.52.232] ([10.58.52.232]) by smtp2.corp.netapp.com (8.13.1/8.13.1/NTAP-1.6) with ESMTP id k776K38t024557; Sun, 6 Aug 2006 23:20:08 -0700 (PDT) Message-ID: <44D6DB95.4070205@netapp.com> Date: Mon, 07 Aug 2006 02:20:05 -0400 From: Dave Wysochanski User-Agent: Mozilla Thunderbird 1.0.7-1.1.fc4 (X11/20050929) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Paul Koning Subject: Re: [Ips] DRAFT Montreal minutes - X#NodeArchitecture comments References: <368FBF3D8437A748BA8222526BF9309957F8D4@aime2k302.adaptec.com><44D245C1.4050706@netapp.com> <17618.18600.273364.982890@gargle.gargle.HOWL> In-Reply-To: <17618.18600.273364.982890@gargle.gargle.HOWL> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: -2.6 (--) X-Scan-Signature: 52e1467c2184c31006318542db5614d5 Cc: ips@ietf.org, wrstuden@wasabisystems.com, ken_sandars@adaptec.com X-BeenThere: ips@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IP Storage List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: ips-bounces@ietf.org Paul Koning wrote: > >>>>> "David" == David Wysochanski writes: > > >> Each node which declares the key MUST be prepared to handle the > >> response of [RFC3720] compliant nodes that do not understand the > >> key ([RFC3720] states that compliant nodes MUST respond with > >> X#NodeArchitecture=NotUnderstood). In addition, a node which > >> implements this key MUST NOT declare "NotUnderstood" as its value. > >> > David> Seems fine. > > Those are just the standard 3720 rules, right? It seems confusing to > restate them explicitly, because it creates the impression that this > key uses rules that are different in some way from the usual rules. > If you do want to state the rules explicitly here, you might include > a comment to the effect that "The normal rules for key handling apply, > which are ..." > Yes, the more I thought about it, I agree. It just muddies the water to explicity state things about how to handle "NotUnderstood", so I'm going to strike that last sentence. > >> A node which receives the value "NotUnderstood" for this key > >> SHOULD discard the value. Regardless of whether the received value > >> is discarded, the key MUST be considered to have been declared. > >> > > David> Isn't this last sentence in conflict with the RFC paragraph I > David> mention below? Sending "NotUnderstood" in a key value is a > David> protocol error, so why would a node receiving it be forced to > David> consider the other node having declared it? > > I agree. The spec says it's a protocol error, the rules for handling > protocol errors are defined already -- don't mess with it. > _______________________________________________ Ips mailing list Ips@ietf.org https://www1.ietf.org/mailman/listinfo/ips From ips-bounces@ietf.org Mon Aug 07 03:05:57 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1G9zBR-0001v5-2L; Mon, 07 Aug 2006 03:05:53 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1G9zBQ-0001uo-5B for ips@ietf.org; Mon, 07 Aug 2006 03:05:52 -0400 Received: from mx2.netapp.com ([216.240.18.37]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1G9zBP-0007Gb-H2 for ips@ietf.org; Mon, 07 Aug 2006 03:05:52 -0400 Received: from smtp2.corp.netapp.com ([10.57.159.114]) by mx2.netapp.com with ESMTP; 07 Aug 2006 00:05:49 -0700 X-IronPort-AV: i="4.07,216,1151910000"; d="scan'208"; a="398877634:sNHT19252868" Received: from [10.58.52.232] ([10.58.52.232]) by smtp2.corp.netapp.com (8.13.1/8.13.1/NTAP-1.6) with ESMTP id k7775je5006127; Mon, 7 Aug 2006 00:05:45 -0700 (PDT) Message-ID: <44D6E648.4020204@netapp.com> Date: Mon, 07 Aug 2006 03:05:44 -0400 From: Dave Wysochanski User-Agent: Mozilla Thunderbird 1.0.7-1.1.fc4 (X11/20050929) X-Accept-Language: en-us, en MIME-Version: 1.0 To: "Sandars, Ken" Subject: Re: [Ips] DRAFT Montreal minutes - X#NodeArchitecture comments References: <368FBF3D8437A748BA8222526BF9309957F8DC@aime2k302.adaptec.com> In-Reply-To: <368FBF3D8437A748BA8222526BF9309957F8DC@aime2k302.adaptec.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 850245b51c39701e2700a112f3032caa Cc: ips@ietf.org, William Studenmund X-BeenThere: ips@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IP Storage List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: ips-bounces@ietf.org Sandars, Ken wrote: > Hi David, > > Comments inline [Ken] > > Cheers > Ken > > > -----Original Message----- > > From: David Wysochanski [mailto:davidw@netapp.com] > > Sent: Friday, 4 August 2006 04:52 > > To: Sandars, Ken > > Cc: ips@ietf.org; William Studenmund > > Subject: Re: [Ips] DRAFT Montreal minutes - > > X#NodeArchitecture comments > > > > Sandars, Ken wrote: > > > Hi David, > > > > > > It might be clearer to rephrase the paragraph to cover the node's > > > obligations when declaring the key, and when receiving it. Something > > > like: > > > > > We can certainly clarify the wording. > > > > > > > Nodes implementing this key MAY declare the key. Nodes > > implementing > > > this key MAY discard the key values received from other nodes. > > > > > I'm not sure this is clearer than what I had below but maybe > > someone else has can chime in. The "declare" wording may be > > more consistent with 3720 though. > > > > > > > Each node which declares the key MUST be prepared to handle the > > > response of [RFC3720] compliant nodes that do not understand the > > > key ([RFC3720] states that compliant nodes MUST respond with > > > X#NodeArchitecture=NotUnderstood). In addition, a node which > > > implements this key MUST NOT declare "NotUnderstood" as its > > > value. > > > > > Seems fine. > > > > > A node which receives the value "NotUnderstood" for > > this key SHOULD > > > discard the value. Regardless of whether the received value is > > > discarded, the key MUST be considered to have been declared. > > > > > > > Isn't this last sentence in conflict with the RFC paragraph I > > mention below? > > [Ken] No. The idea is to catch the required behaviour. It has to > consider that to the nodes who know, the key is declarative, while for > others the key is negotiated (hence the NotUnderstood response is > legal). Thus the negotiation engine needs to track that once it has > declared the key the other node is only allowed to: > (1) declare a valid value for the key, or > (2) send a response of "NotUnderstood", or > (3) do nothing more with the key. > I think I understand where you are coming from though I don't think these last two sentences are necessary - it is an implementation problem right? You have a "key type" of declarative or negotiated, and you have to pick one. If you pick "declarative", then you have the problem of recording the "NotUnderstood" value. But in that case, the code should always handle "NotUnderstood" as a reserved value, and not record it, per the spec. If a node sends a special X# or X- key, it should always know how to respond to other nodes that don't implement the key. When you write the code for the special key you have to take that case into account, which is why I'd guess this case came up in Montreal. Am I on the right track? > > > Sending "NotUnderstood" in a key value is a > > protocol error, so why would a node receiving it be forced to > > consider the other node having declared it? > > > > [Ken] It's not a protocol error for a node which doesn't implement this > extension key. > Don't confuse the term 'declare' with 'propose'/'accept'. Nodes which > implement this key know it's a Declarative key; for other > implementations the key is negotiated. > Ok well, by putting in the sentences you were proposing, it read like people needed to know they couldn't initiate the "NotUnderstood" declaration. This should be clear from the original 3720 rules. > [Ken] The reason it should be considered 'declared' is because it has > been received (parameter negotiation engines tend to get this right). It > will be a protocol error if the other node sends it again (obviously in > error). This applies equally to nodes which are aware of the key and > those which are not. I also wanted to indicate that even if the value of > the received key is not used in the intended logging role (say is > discarded), the parameter negotiation engine still needs to note that > the other node has sent it once and to barf if it sees it again. > Right. Redeclaration of the key is forbidden, per p. 3 of the ID, and 3720. I really think you're stating what should already be clear. It is good discussion for implementors, but I'm not sure we need to add more wording. > [Ken] For example, consider a broken implementation which thinks it's > cute to declare the key, but doesn't update its reception engine to > recognise the inbound key (because it isn't interested in logging the > info). This is test suite paradise! ;-) > But that's clearly a buggy implementation. Do we really need to add more words for that? > > > Note also that I added this wording: > > Nodes implementing this key may choose to only transmit the > > key, only log the key values received from other nodes, or both > > transmit and log the key values. Each node choosing to implement > > > > to match some of the wording in the security section: > > For the above target, an appropriate implementation might be > > logging of received key values, but no transmission of the key. > > For the initiators, an appropriate implementation might be > > transmission of the key, but no logging of received key values. > > > > I was also thinking from my developer's hat and > > compartmentalizing the differing parts of the implementation > > (which have different things to think about). On my end I > > have two different coding items to track the transmission of > > the key vs the logging. > > > > [Ken] Fair enough, but what about the option to not send and to not log? > That's why I proposed a different set of words for that part. > Ah - sure that is valid and a reasonable case - you have switches for sending and logging, and both are off by default. In that case you wouldn't send "NotUnderstood" in response to another node's declaration, but would just silently discard. Is this case the root of your original post where you suggested new wording? If so, I agree that the current wording I have doesn't cover that case, so let me think some more about it. Perhaps some of what you originally proposed is what we want. But I think some of the explicit statements about "NotUnderstood" are redundant and may muddy the water. > > > > > Thoughts? > > > Ken > > > > > > -----Original Message----- > > > From: David Wysochanski [mailto:davidw@netapp.com] > > > Sent: Thursday, 3 August 2006 05:56 > > > To: William Studenmund > > > Cc: Sandars, Ken; ips@ietf.org > > > Subject: Re: [Ips] DRAFT Montreal minutes - X#NodeArchitecture > > > comments > > > > > > William Studenmund wrote: > > > > -----BEGIN PGP SIGNED MESSAGE----- > > > > Hash: SHA1 > > > > > > > > On Aug 2, 2006, at 12:15 AM, Sandars, Ken wrote: > > > > > > > > > Hi David, > > > > > > > > > > Making an extension key 'Declarative' seems problematic. > > > > > > > > > > Implementations which do not recognise the key will > > reply with > > > > > X=NotUnderstood. This may upset the proposer since > > > > > "NotUnderstood" > > > > > is unlikely to be an acceptable use of the new key. > > > > > > > > > > "NotUnderstood" could be treated as a special case, > > but do we > > > > really > want a special case? > > > > > > > > We talked about this in Montreal. Or I tried to a bit. > > > > > > > > At this point, I think we have to accept "NotUnderstood" > > as a valid > > > > response to the key, indicating that the other side doesn't > > > > understand. We can't do anything different. > > > > > > > > We thus should state that "NotUnderstood" is an invalid > > > > X#NodeArchitecture value (you MUST never attempt to assert > > that it's > > > > your architecture value), and its presence in a response > > should be > > > > taken to mean the responder doesn't understand the key. > > > > > > > > > > Ah, thanks for pointing out that last part. > > > > > > I think RFC3720 already handles usage of "NotUnderstood" as a value > > > for any key. I can add an explicit sentence forbidding its use as > > > you've stated, but I didn't get that was what was desired from the > > > final minutes. > > > > > > Here's the section from 3720, p. 54 I'm referring to: > > > > > > The constants "None", "Reject", "Irrelevant", and > > "NotUnderstood" > > > are > > > reserved and MUST ONLY be used as described here. > > Violation of this > > > rule is a protocol error (in particular the use of "Reject", > > > "Irrelevant", and "NotUnderstood" as proposed values). > > > > > > > > > Here's what the final minutes had: > > > > > > - Document behavior of RFC 3720-compliant > > implementation that > > > receives this new key and does not > > understand it, and > > > how > > > the other side deals with the resulting response. > > > > > > > > > Finally, some new proposed text with the explicit forbidding of > > > "NotUnderstood" (see the last sentence). > > > > > > Nodes implementing this key may choose to only transmit the > > > key, only log the key values received from other nodes, or both > > > transmit and log the key values. Each node choosing to > > implement > > > transmission of the key values MUST be prepared to handle the > > > response of [RFC3720] compliant nodes that do not understand the > > > key ([RFC3720] states that compliant nodes MUST respond with > > > X#NodeArchitecture=NotUnderstood). In addition, a node > > implementing > > > transmission MUST NOT transmit "NotUnderstood" as its value, > > > as this is a reserved value for all keys [RFC3720]. > > > > > > _______________________________________________ Ips mailing list Ips@ietf.org https://www1.ietf.org/mailman/listinfo/ips From ips-bounces@ietf.org Mon Aug 07 09:34:17 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GA5F7-00030d-0G; Mon, 07 Aug 2006 09:34:05 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GA5F5-0002zn-JX for ips@ietf.org; Mon, 07 Aug 2006 09:34:03 -0400 Received: from stsc1260-eth-s1-s1p1-vip.va.neustar.com ([156.154.16.129] helo=chiedprmail1.ietf.org) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GA33b-0004Ca-Rl for ips@ietf.org; Mon, 07 Aug 2006 07:14:03 -0400 Received: from mail-gw3.adaptec.com ([216.52.22.36]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1GA2fo-0007J3-Bt for ips@ietf.org; Mon, 07 Aug 2006 06:49:32 -0400 Received: from aime2k05.adaptec.com (aime2k05.adaptec.com [10.25.8.46]) by mail-gw3.adaptec.com (Spam Firewall) with ESMTP id BD010D50C0; Mon, 7 Aug 2006 03:49:21 -0700 (PDT) Received: from aime2k302.adaptec.com ([10.25.8.48]) by aime2k05.adaptec.com with Microsoft SMTPSVC(5.0.2195.6713); Mon, 7 Aug 2006 03:49:21 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5 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] DRAFT Montreal minutes - X#NodeArchitecture comments Date: Mon, 7 Aug 2006 03:49:20 -0700 Message-ID: <368FBF3D8437A748BA8222526BF9309957F8E8@aime2k302.adaptec.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Ips] DRAFT Montreal minutes - X#NodeArchitecture comments Thread-Index: Aca6BmJToYsV8xV1TLKimsOLWzkzFAAB6qtA From: "Sandars, Ken" To: "Dave Wysochanski" X-OriginalArrivalTime: 07 Aug 2006 10:49:21.0643 (UTC) FILETIME=[23E9ABB0:01C6BA0F] X-Virus-Scanned: by Barracuda Spam Firewall at adaptec.com X-Spam-Score: -2.6 (--) X-Scan-Signature: fcb459c204557d9509ce9c1b55d771f1 Cc: ips@ietf.org, William Studenmund X-BeenThere: ips@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IP Storage List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: ips-bounces@ietf.org Hi David, Yes, you've got the angle I'm coming from. It's important to express the idea that while it is a declared key, the rules for declared keys are being slightly bent such that it is not a protocol error to receive a "NotUnderstood" in the context of the other node processing it as an offered key. And yes, if you're going to spell out the use cases, I think you need to cover them all. As you say, little more wordsmithing and it should be gold! Cheers Ken > -----Original Message----- > From: Dave Wysochanski [mailto:davidw@netapp.com]=20 > Sent: Monday, 7 August 2006 17:06 > To: Sandars, Ken > Cc: ips@ietf.org; William Studenmund > Subject: Re: [Ips] DRAFT Montreal minutes -=20 > X#NodeArchitecture comments >=20 > Sandars, Ken wrote: > > Hi David, > >=20 > > Comments inline [Ken] > >=20 > > Cheers > > Ken > >=20 > > > -----Original Message----- > > > From: David Wysochanski [mailto:davidw@netapp.com] >=20 > Sent: Friday,=20 > > 4 August 2006 04:52 > To: Sandars, Ken > Cc:=20 > ips@ietf.org; William=20 > > Studenmund > Subject: Re: [Ips] DRAFT Montreal minutes - >=20 > > X#NodeArchitecture comments > > Sandars, Ken wrote: > > > > Hi David, > > > > > > > > It might be clearer to rephrase the paragraph to cover=20 > the node's =20 > > > > obligations when declaring the key, and when receiving it.=20 > > Something > > like: > > > > > > > We can certainly clarify the wording. > > > > > > > > > > Nodes implementing this key MAY declare the key. Nodes > > > implementing > > > > this key MAY discard the key values received from=20 > other nodes. > > > > > > > I'm not sure this is clearer than what I had below but maybe >=20 > > someone else has can chime in. The "declare" wording may=20 > be > more=20 > > consistent with 3720 though. > > > > > > > > > > Each node which declares the key MUST be prepared=20 > to handle the > > > > response of [RFC3720] compliant nodes that do not=20 > understand the > > > > key ([RFC3720] states that compliant nodes MUST=20 > respond with > > > > X#NodeArchitecture=3DNotUnderstood). In addition, a=20 > node which > > > > implements this key MUST NOT declare "NotUnderstood" as its > > > > value. > > > > > > > Seems fine. > > > > > > > A node which receives the value "NotUnderstood" for > > > this key SHOULD > > > > discard the value. Regardless of whether the=20 > received value is > > > > discarded, the key MUST be considered to have been=20 > declared. > > > > > > > > > > Isn't this last sentence in conflict with the RFC paragraph I >=20 > > mention below? > >=20 > > [Ken] No. The idea is to catch the required behaviour. It has to=20 > > consider that to the nodes who know, the key is=20 > declarative, while for=20 > > others the key is negotiated (hence the NotUnderstood response is=20 > > legal). Thus the negotiation engine needs to track that once it has=20 > > declared the key the other node is only allowed to: > > (1) declare a valid value for the key, or > > (2) send a response of "NotUnderstood", or > > (3) do nothing more with the key. > >=20 >=20 > I think I understand where you are coming from though I don't=20 > think these last two sentences are necessary - it is an=20 > implementation problem right? You have a "key type" of=20 > declarative or negotiated, and you have to pick one. If you=20 > pick "declarative", then you have the problem of recording=20 > the "NotUnderstood" value. But in that case, the code should=20 > always handle "NotUnderstood" as a reserved value, and not=20 > record it, per the spec. If a node sends a special X# or X-=20 > key, it should always know how to respond to other nodes that=20 > don't implement the key. When you write the code for the=20 > special key you have to take that case into account, which is=20 > why I'd guess this case came up in Montreal. >=20 > Am I on the right track? >=20 >=20 > >=20 > > > Sending "NotUnderstood" in a key value is a > protocol=20 > error, so=20 > > why would a node receiving it be forced to > consider the=20 > other node=20 > > having declared it? > > > > >=20 > > [Ken] It's not a protocol error for a node which doesn't implement=20 > > this extension key. > > Don't confuse the term 'declare' with 'propose'/'accept'.=20 > Nodes which=20 > > implement this key know it's a Declarative key; for other=20 > > implementations the key is negotiated. > >=20 > Ok well, by putting in the sentences you were proposing, it=20 > read like people needed to know they couldn't initiate the=20 > "NotUnderstood" > declaration. This should be clear from the original 3720 rules. >=20 >=20 > > [Ken] The reason it should be considered 'declared' is=20 > because it has=20 > > been received (parameter negotiation engines tend to get=20 > this right).=20 > > It will be a protocol error if the other node sends it again=20 > > (obviously in error). This applies equally to nodes which=20 > are aware of=20 > > the key and those which are not. I also wanted to indicate=20 > that even=20 > > if the value of the received key is not used in the=20 > intended logging=20 > > role (say is discarded), the parameter negotiation engine=20 > still needs=20 > > to note that the other node has sent it once and to barf if=20 > it sees it again. > >=20 > Right. Redeclaration of the key is forbidden, per p. 3 of=20 > the ID, and 3720. I really think you're stating what should=20 > already be clear. > It is good discussion for implementors, but I'm not sure we=20 > need to add more wording. >=20 >=20 > > [Ken] For example, consider a broken implementation which=20 > thinks it's=20 > > cute to declare the key, but doesn't update its reception engine to=20 > > recognise the inbound key (because it isn't interested in=20 > logging the=20 > > info). This is test suite paradise! ;-) > >=20 >=20 > But that's clearly a buggy implementation. Do we really need=20 > to add more words for that? >=20 > >=20 > > > Note also that I added this wording: > > > Nodes implementing this key may choose to only transmit the > > > key, only log the key values received from other=20 > nodes, or both > > > transmit and log the key values. Each node choosing=20 > to implement > > > > > > to match some of the wording in the security section: > > > For the above target, an appropriate implementation might be > > > logging of received key values, but no transmission=20 > of the key. > > > For the initiators, an appropriate implementation might be > > > transmission of the key, but no logging of received=20 > key values. > > > > > > I was also thinking from my developer's hat and >=20 > > compartmentalizing the differing parts of the=20 > implementation > (which=20 > > have different things to think about). On my end I > have two=20 > > different coding items to track the transmission of > the=20 > key vs the=20 > > logging. > > > > >=20 > > [Ken] Fair enough, but what about the option to not send=20 > and to not log? > > That's why I proposed a different set of words for that part. > >=20 >=20 > Ah - sure that is valid and a reasonable case - you have=20 > switches for sending and logging, and both are off by=20 > default. In that case you wouldn't send "NotUnderstood" in=20 > response to another node's declaration, but would just=20 > silently discard. >=20 > Is this case the root of your original post where you=20 > suggested new wording? >=20 > If so, I agree that the current wording I have doesn't cover=20 > that case, so let me think some more about it. Perhaps some=20 > of what you originally proposed is what we want. But I think=20 > some of the explicit statements about "NotUnderstood" are=20 > redundant and may muddy the water. >=20 >=20 > > > > > > > Thoughts? > > > > Ken > > > > > > > > -----Original Message----- > > > > From: David Wysochanski [mailto:davidw@netapp.com] > > Sent:=20 > > Thursday, 3 August 2006 05:56 > > To: William Studenmund > > Cc:=20 > > Sandars, Ken; ips@ietf.org > > Subject: Re: [Ips] DRAFT Montreal=20 > > minutes - X#NodeArchitecture > > comments > > > > William=20 > > Studenmund wrote: > > > > > -----BEGIN PGP SIGNED MESSAGE----- > > > Hash:=20 > SHA1 > > > =20 > > > > > On Aug 2, 2006, at 12:15 AM, Sandars, Ken wrote: > > > > > > > > > > > Hi David, > > > > > > > > > > > > Making an extension key 'Declarative' seems problematic. > > > > > > > > > > > > Implementations which do not recognise the key will >=20 > > reply with > > > > X=3DNotUnderstood. This may upset the=20 > > proposer since > > > > "NotUnderstood" > > > > > > is unlikely to be an acceptable use of the new key. > > > > > > > > > > > > "NotUnderstood" could be treated as a special=20 > case, > but=20 > > do we > > > really > want a special case? > > > > > > > > > > We talked about this in Montreal. Or I tried to a bit. > > > > > > > > > > At this point, I think we have to accept "NotUnderstood" > > > as a valid > > > > > response to the key, indicating that the other side=20 > doesn't > =20 > > > > understand. We can't do anything different. > > > > > > > > > > We thus should state that "NotUnderstood" is an=20 > invalid > >=20 > > > X#NodeArchitecture value (you MUST never attempt to=20 > assert > that=20 > > it's > > > your architecture value), and its presence in a=20 > response =20 > > > should be > > > taken to mean the responder doesn't=20 > understand the=20 > > key. > > > > > > > > > > > > > Ah, thanks for pointing out that last part. > > > > > > > > I think RFC3720 already handles usage of "NotUnderstood" as a=20 > > value > > for any key. I can add an explicit sentence=20 > forbidding its=20 > > use as > > you've stated, but I didn't get that was what=20 > was desired=20 > > from the > > final minutes. > > > > > > > > Here's the section from 3720, p. 54 I'm referring to: > > > > > > > > The constants "None", "Reject", "Irrelevant", and > > > "NotUnderstood" > > > > are > > > > reserved and MUST ONLY be used as described here.=20 > > > Violation of this > > > > rule is a protocol error (in particular the use of=20 > "Reject", > > > > "Irrelevant", and "NotUnderstood" as proposed values). > > > > > > > > > > > > Here's what the final minutes had: > > > > > > > > - Document behavior of RFC 3720-compliant > > > implementation that > > > > receives this new key and does not > > > understand it, and > > > > how > > > > the other side deals with the=20 > resulting response. > > > > > > > > > > > > Finally, some new proposed text with the explicit=20 > forbidding of =20 > > > > "NotUnderstood" (see the last sentence). > > > > > > > > Nodes implementing this key may choose to only transmit the > > > > key, only log the key values received from other=20 > nodes, or both > > > > transmit and log the key values. Each node choosing to > > > implement > > > > transmission of the key values MUST be prepared to=20 > handle the > > > > response of [RFC3720] compliant nodes that do not=20 > understand the > > > > key ([RFC3720] states that compliant nodes MUST=20 > respond with > > > > X#NodeArchitecture=3DNotUnderstood). In addition, a node > > > implementing > > > > transmission MUST NOT transmit "NotUnderstood" as=20 > its value, > > > > as this is a reserved value for all keys [RFC3720]. > > > > > > > > >=20 >=20 > _______________________________________________ > Ips mailing list > Ips@ietf.org > https://www1.ietf.org/mailman/listinfo/ips >=20 _______________________________________________ Ips mailing list Ips@ietf.org https://www1.ietf.org/mailman/listinfo/ips From ips-bounces@ietf.org Mon Aug 07 12:20:38 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GA7qD-0002vp-ME; Mon, 07 Aug 2006 12:20:33 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GA7qC-0002vj-26 for ips@ietf.org; Mon, 07 Aug 2006 12:20:32 -0400 Received: from stsc1260-eth-s1-s1p1-vip.va.neustar.com ([156.154.16.129] helo=chiedprmail1.ietf.org) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GA5je-0007my-KZ for ips@ietf.org; Mon, 07 Aug 2006 10:05:38 -0400 Received: from sadr.equallogic.com ([66.155.203.134]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1GA5VA-00037z-6G for ips@ietf.org; Mon, 07 Aug 2006 09:50:41 -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 k77DoXRo014563 for ; Mon, 7 Aug 2006 09:50:33 -0400 Received: from M31.equallogic.com (M31.equallogic.com [172.16.1.31]) by sadr.equallogic.com (8.12.8/8.12.8) with SMTP id k77DoWfA014558; Mon, 7 Aug 2006 09:50:32 -0400 Received: from pkoning.equallogic.com ([172.16.1.124]) by M31.equallogic.com with Microsoft SMTPSVC(6.0.3790.211); Mon, 7 Aug 2006 09:50:32 -0400 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <17623.17702.805793.588473@gargle.gargle.HOWL> Date: Mon, 7 Aug 2006 09:50:30 -0400 From: Paul Koning To: ken_sandars@adaptec.com Subject: RE: [Ips] DRAFT Montreal minutes - X#NodeArchitecture comments References: <368FBF3D8437A748BA8222526BF9309957F8E8@aime2k302.adaptec.com> X-Mailer: VM 7.17 under 21.5 (beta27) "fiddleheads" XEmacs Lucid X-OriginalArrivalTime: 07 Aug 2006 13:50:32.0741 (UTC) FILETIME=[73979550:01C6BA28] X-Spam-Score: -2.6 (--) X-Scan-Signature: 7a6398bf8aaeabc7a7bb696b6b0a2aad Cc: ips@ietf.org, wrstuden@wasabisystems.com X-BeenThere: ips@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IP Storage List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: ips-bounces@ietf.org >>>>> "Ken" == Ken Sandars writes: Ken> Hi David, Yes, you've got the angle I'm coming from. It's Ken> important to express the idea that while it is a declared key, Ken> the rules for declared keys are being slightly bent such that it Ken> is not a protocol error to receive a "NotUnderstood" in the Ken> context of the other node processing it as an offered key. So why is that new? It should be the common rule for all declared keys. paul _______________________________________________ Ips mailing list Ips@ietf.org https://www1.ietf.org/mailman/listinfo/ips From ips-bounces@ietf.org Mon Aug 07 17:05:28 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GACHs-0005I1-4o; Mon, 07 Aug 2006 17:05:24 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GACHr-0005G8-It for ips@ietf.org; Mon, 07 Aug 2006 17:05:23 -0400 Received: from mail-gw3.adaptec.com ([216.52.22.36]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GACHq-0003bz-9y for ips@ietf.org; Mon, 07 Aug 2006 17:05:23 -0400 Received: from aime2k03.adaptec.com (aime2k03.adaptec.com [10.25.8.43]) by mail-gw3.adaptec.com (Spam Firewall) with ESMTP id B4B89102559; Mon, 7 Aug 2006 14:05:20 -0700 (PDT) Received: from aime2k302.adaptec.com ([10.25.8.48]) by aime2k03.adaptec.com with Microsoft SMTPSVC(5.0.2195.6713); Mon, 7 Aug 2006 14:05:20 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5 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] DRAFT Montreal minutes - X#NodeArchitecture comments Date: Mon, 7 Aug 2006 14:05:19 -0700 Message-ID: <368FBF3D8437A748BA8222526BF9309957F8EA@aime2k302.adaptec.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Ips] DRAFT Montreal minutes - X#NodeArchitecture comments Thread-Index: Aca6XFxLqvUE0kO+QJu50kKfbAPu8AABqhfA From: "Sandars, Ken" To: "Paul Koning" X-OriginalArrivalTime: 07 Aug 2006 21:05:20.0674 (UTC) FILETIME=[31364020:01C6BA65] X-Virus-Scanned: by Barracuda Spam Firewall at adaptec.com X-Spam-Score: 0.0 (/) X-Scan-Signature: 39bd8f8cbb76cae18b7e23f7cf6b2b9f Cc: ips@ietf.org, wrstuden@wasabisystems.com X-BeenThere: ips@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IP Storage List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: ips-bounces@ietf.org Hi Paul, In [RFC3720] it is ALWAYS an error when the value of a declared key is "NotUnderstood". Hence this document needs to state the (slightly) altered processing of this key. Cheers Ken > -----Original Message----- > From: Paul Koning [mailto:pkoning@equallogic.com]=20 > Sent: Monday, 7 August 2006 23:51 > To: Sandars, Ken > Cc: ips@ietf.org; wrstuden@wasabisystems.com > Subject: RE: [Ips] DRAFT Montreal minutes -=20 > X#NodeArchitecture comments >=20 > >>>>> "Ken" =3D=3D Ken Sandars writes: >=20 > Ken> Hi David, Yes, you've got the angle I'm coming from.=20 > It's Ken> important to express the idea that while it is a=20 > declared key, Ken> the rules for declared keys are being=20 > slightly bent such that it Ken> is not a protocol error to=20 > receive a "NotUnderstood" in the Ken> context of the other=20 > node processing it as an offered key. >=20 > So why is that new? It should be the common rule for all=20 > declared keys. >=20 > paul >=20 >=20 > _______________________________________________ > Ips mailing list > Ips@ietf.org > https://www1.ietf.org/mailman/listinfo/ips >=20 _______________________________________________ Ips mailing list Ips@ietf.org https://www1.ietf.org/mailman/listinfo/ips From ips-bounces@ietf.org Mon Aug 07 17:24:55 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GACaj-0001Mt-Kc; Mon, 07 Aug 2006 17:24:53 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GACai-0001Ml-F2 for ips@ietf.org; Mon, 07 Aug 2006 17:24:52 -0400 Received: from sadr.equallogic.com ([66.155.203.134]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GACaf-0001Sp-6X for ips@ietf.org; Mon, 07 Aug 2006 17:24:52 -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 k77LOmRo013067 for ; Mon, 7 Aug 2006 17:24:48 -0400 Received: from M31.equallogic.com (M31.equallogic.com [172.16.1.31]) by sadr.equallogic.com (8.12.8/8.12.8) with SMTP id k77LOmfA013062; Mon, 7 Aug 2006 17:24:48 -0400 Received: from pkoning.equallogic.com ([172.16.1.124]) by M31.equallogic.com with Microsoft SMTPSVC(6.0.3790.211); Mon, 7 Aug 2006 17:24:48 -0400 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <17623.44958.429474.97650@gargle.gargle.HOWL> Date: Mon, 7 Aug 2006 17:24:46 -0400 From: Paul Koning To: ken_sandars@adaptec.com Subject: RE: [Ips] DRAFT Montreal minutes - X#NodeArchitecture comments References: <368FBF3D8437A748BA8222526BF9309957F8EA@aime2k302.adaptec.com> X-Mailer: VM 7.17 under 21.5 (beta27) "fiddleheads" XEmacs Lucid X-OriginalArrivalTime: 07 Aug 2006 21:24:48.0390 (UTC) FILETIME=[E9399260:01C6BA67] X-Spam-Score: 0.0 (/) X-Scan-Signature: d6b246023072368de71562c0ab503126 Cc: ips@ietf.org, wrstuden@wasabisystems.com X-BeenThere: ips@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IP Storage List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: ips-bounces@ietf.org >>>>> "Ken" == Ken Sandars writes: Ken> Hi Paul, In [RFC3720] it is ALWAYS an error when the value of a Ken> declared key is "NotUnderstood". Hence this document needs to Ken> state the (slightly) altered processing of this key. Actually, what we have here is a 3720 bug. If a new key is declarative, an old implementation does not know that and will (or may?) treat it as a negotiated key, and reply with NotUnderstood. That case is not specific to X#NodeArchitecture. So it shouldn't be treated as a special case there; instead it should be noted as a bugfix to 3720. The fix is easy: a "NotUnderstood" value for a declarative key is ignored. paul _______________________________________________ Ips mailing list Ips@ietf.org https://www1.ietf.org/mailman/listinfo/ips From ips-bounces@ietf.org Tue Aug 08 05:42:34 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GAO6Z-0002Xj-AQ; Tue, 08 Aug 2006 05:42:31 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GAO6X-0002XX-OY for ips@ietf.org; Tue, 08 Aug 2006 05:42:29 -0400 Received: from mtagate2.de.ibm.com ([195.212.29.151]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GAO6W-0000aN-6d for ips@ietf.org; Tue, 08 Aug 2006 05:42:29 -0400 Received: from d12nrmr1607.megacenter.de.ibm.com (d12nrmr1607.megacenter.de.ibm.com [9.149.167.49]) by mtagate2.de.ibm.com (8.13.7/8.13.7) with ESMTP id k789gRuo158362 for ; Tue, 8 Aug 2006 09:42:27 GMT Received: from d12av04.megacenter.de.ibm.com (d12av04.megacenter.de.ibm.com [9.149.165.229]) by d12nrmr1607.megacenter.de.ibm.com (8.13.6/8.13.6/NCO v8.1.1) with ESMTP id k789k5XC146926 for ; Tue, 8 Aug 2006 11:46:05 +0200 Received: from d12av04.megacenter.de.ibm.com (loopback [127.0.0.1]) by d12av04.megacenter.de.ibm.com (8.12.11.20060308/8.13.3) with ESMTP id k789gQgq017289 for ; Tue, 8 Aug 2006 11:42:26 +0200 Received: from d12mc102.megacenter.de.ibm.com (d12mc102.megacenter.de.ibm.com [9.149.167.114]) by d12av04.megacenter.de.ibm.com (8.12.11.20060308/8.12.11) with ESMTP id k789gQmn017277; Tue, 8 Aug 2006 11:42:26 +0200 In-Reply-To: <17623.44958.429474.97650@gargle.gargle.HOWL> To: Paul Koning Subject: RE: [Ips] DRAFT Montreal minutes - X#NodeArchitecture comments MIME-Version: 1.0 X-Mailer: Lotus Notes Release 7.0.1 January 17, 2006 From: Julian Satran Message-ID: Date: Tue, 8 Aug 2006 12:46:02 +0300 X-MIMETrack: Serialize by Router on D12MC102/12/M/IBM(Release 7.0.1HF269 | June 22, 2006) at 08/08/2006 12:46:04, Serialize complete at 08/08/2006 12:46:04 X-Spam-Score: 0.1 (/) X-Scan-Signature: 3a4bc66230659131057bb68ed51598f8 Cc: ips@ietf.org, wrstuden@wasabisystems.com, ken_sandars@adaptec.com X-BeenThere: ips@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IP Storage List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1476509552==" Errors-To: ips-bounces@ietf.org This is a multipart message in MIME format. --===============1476509552== Content-Type: multipart/alternative; boundary="=_alternative 0035516EC22571C4_=" This is a multipart message in MIME format. --=_alternative 0035516EC22571C4_= Content-Type: text/plain; charset="US-ASCII" Paul is right. Julo Paul Koning 08/08/06 00:24 To ken_sandars@adaptec.com cc ips@ietf.org, wrstuden@wasabisystems.com Subject RE: [Ips] DRAFT Montreal minutes - X#NodeArchitecture comments >>>>> "Ken" == Ken Sandars writes: Ken> Hi Paul, In [RFC3720] it is ALWAYS an error when the value of a Ken> declared key is "NotUnderstood". Hence this document needs to Ken> state the (slightly) altered processing of this key. Actually, what we have here is a 3720 bug. If a new key is declarative, an old implementation does not know that and will (or may?) treat it as a negotiated key, and reply with NotUnderstood. That case is not specific to X#NodeArchitecture. So it shouldn't be treated as a special case there; instead it should be noted as a bugfix to 3720. The fix is easy: a "NotUnderstood" value for a declarative key is ignored. paul _______________________________________________ Ips mailing list Ips@ietf.org https://www1.ietf.org/mailman/listinfo/ips --=_alternative 0035516EC22571C4_= Content-Type: text/html; charset="US-ASCII"
Paul is right. Julo


Paul Koning <pkoning@equallogic.com>

08/08/06 00:24

To
ken_sandars@adaptec.com
cc
ips@ietf.org, wrstuden@wasabisystems.com
Subject
RE: [Ips] DRAFT Montreal minutes - X#NodeArchitecture comments





>>>>> "Ken" == Ken Sandars <Sandars> writes:

Ken> Hi Paul, In [RFC3720] it is ALWAYS an error when the value of a
Ken> declared key is "NotUnderstood". Hence this document needs to
Ken> state the (slightly) altered processing of this key.

Actually, what we have here is a 3720 bug.  If a new key is
declarative, an old implementation does not know that and will (or
may?) treat it as a negotiated key, and reply with NotUnderstood.

That case is not specific to X#NodeArchitecture.  So it shouldn't be
treated as a special case there; instead it should be noted as a
bugfix to 3720.

The fix is easy: a "NotUnderstood" value for a declarative key is
ignored.  

                  paul


_______________________________________________
Ips mailing list
Ips@ietf.org
https://www1.ietf.org/mailman/listinfo/ips
--=_alternative 0035516EC22571C4_=-- --===============1476509552== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Ips mailing list Ips@ietf.org https://www1.ietf.org/mailman/listinfo/ips --===============1476509552==-- From ips-bounces@ietf.org Wed Aug 09 18:34:22 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GAwd2-0001NO-87; Wed, 09 Aug 2006 18:34:20 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GAwd0-0001IS-Se for ips@ietf.org; Wed, 09 Aug 2006 18:34:18 -0400 Received: from sccrmhc12.comcast.net ([204.127.200.82]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GAwcz-0005hc-MH for ips@ietf.org; Wed, 09 Aug 2006 18:34:18 -0400 Received: from ivvtdkv0981 (unknown[209.115.217.214]) by comcast.net (sccrmhc12) with SMTP id <2006080922341601200m5c1ge>; Wed, 9 Aug 2006 22:34:17 +0000 Message-ID: <000601c6bc03$f2e3d8a0$f414a8c0@ivivity.com> From: "Eddy Quicksall" To: Date: Wed, 9 Aug 2006 18:34:15 -0400 MIME-Version: 1.0 X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.2869 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2869 X-Spam-Score: 0.1 (/) X-Scan-Signature: 538aad3a3c4f01d8b6a6477ca4248793 Cc: Amit Kumar Subject: [Ips] Re-sending a command X-BeenThere: ips@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IP Storage List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0816005426==" Errors-To: ips-bounces@ietf.org This is a multi-part message in MIME format. --===============0816005426== Content-Type: multipart/alternative; boundary="----=_NextPart_000_0003_01C6BBE2.6AD58920" This is a multi-part message in MIME format. ------=_NextPart_000_0003_01C6BBE2.6AD58920 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable It was brought to my attention that one initiator being tested will = re-issue a "timed out" command using the same CmdSN after it has issued = a LU Reset. When this happens the command is dropped. Note that this is = on a single connection session. I'm wondering if this could be an initiator bug or if there is a case = where it is actually valid (in the report I have I don't know if the = initiator also reissued the command with a valid CmdSN or not). Does anyone know? Eddy ------=_NextPart_000_0003_01C6BBE2.6AD58920 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
It was brought to my attention that one initiator = being tested=20 will re-issue a "timed out" command using the same CmdSN after = it has=20 issued a LU Reset. When this happens the command is dropped. Note that = this is=20 on a single connection session.
 
I'm wondering if this could be an initiator bug or = if there is=20 a case where it is actually valid (in the report I have I don't know if = the=20 initiator also reissued the command with a valid CmdSN or = not).
 
Does anyone know?
 
Eddy
------=_NextPart_000_0003_01C6BBE2.6AD58920-- --===============0816005426== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Ips mailing list Ips@ietf.org https://www1.ietf.org/mailman/listinfo/ips --===============0816005426==-- From ips-bounces@ietf.org Thu Aug 10 01:46:33 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GB3NI-0001QK-Hf; Thu, 10 Aug 2006 01:46:32 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GB3NG-0001QE-Oj for ips@ietf.org; Thu, 10 Aug 2006 01:46:30 -0400 Received: from stsc1260-eth-s1-s1p1-vip.va.neustar.com ([156.154.16.129] helo=chiedprmail1.ietf.org) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GAxw7-0006oT-Qw for ips@ietf.org; Wed, 09 Aug 2006 19:58:07 -0400 Received: from mail-gw3.adaptec.com ([216.52.22.36]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1GAxh0-0005Oi-9M for ips@ietf.org; Wed, 09 Aug 2006 19:42:32 -0400 Received: from aime2k03.adaptec.com (aime2k03.adaptec.com [10.25.8.43]) by mail-gw3.adaptec.com (Spam Firewall) with ESMTP id 204DD13A827; Wed, 9 Aug 2006 16:42:26 -0700 (PDT) Received: from aime2k302.adaptec.com ([10.25.8.48]) by aime2k03.adaptec.com with Microsoft SMTPSVC(5.0.2195.6713); Wed, 9 Aug 2006 16:42:26 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Subject: RE: [Ips] Re-sending a command Date: Wed, 9 Aug 2006 16:42:22 -0700 Message-ID: <368FBF3D8437A748BA8222526BF9309957F902@aime2k302.adaptec.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Ips] Re-sending a command Thread-Index: Aca8BAhXfj12O+YfTJC3lCWJXmbuvQABR63Q From: "Sandars, Ken" To: "Eddy Quicksall" , X-OriginalArrivalTime: 09 Aug 2006 23:42:26.0115 (UTC) FILETIME=[7809E930:01C6BC0D] X-Virus-Scanned: by Barracuda Spam Firewall at adaptec.com X-Spam-Score: -2.5 (--) X-Scan-Signature: bcd240e64c427d3d3617cfc704e7fd7f Cc: X-BeenThere: ips@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IP Storage List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1474524435==" Errors-To: ips-bounces@ietf.org This is a multi-part message in MIME format. --===============1474524435== Content-class: urn:content-classes:message Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C6BC0D.75AD4D21" This is a multi-part message in MIME format. ------_=_NextPart_001_01C6BC0D.75AD4D21 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi Eddy, =20 There's some reading between the lines needed, but if this is scenario you are describing: =20 I->T: CmdSN=3D25 ITT=3D1 SCSI1
<time out period>
I->T: CmdSN=3D26 (immediate) ITT=3D2 TMF - = LU=20 Reset
T->I: ITT=3D2 ExpCmdSN=3D26 TMF Response - = Function=20 Complete
I->T: CmdSN=3D25 ITT=3D1=20 SCSI1
 
In this case, the target actions for the TMF = - LU Reset=20 will ensure that no responses will be sent for the affected commands = (including=20 CmdSN=3D25) after the TMF response is=20 sent.
 
The initiator is in effect (re)sending a = command=20 outside the CmdSN window, and a working target will discard=20 it.
 
HTH<= /SPAN>
Ken
=

From: Eddy Quicksall=20 [mailto:eddy_quicksall_iVivity_iSCSI@Comcast.net]
Sent: = Thursday,=20 10 August 2006 08:34
To: ips@ietf.org
Cc: Amit=20 Kumar
Subject: [Ips] Re-sending a = command

It was brought to my attention that one initiator = being=20 tested will re-issue a "timed out" command using the same=20 CmdSN after it has issued a LU Reset. When this happens the = command is=20 dropped. Note that this is on a single connection = session.
 
I'm wondering if this could be an initiator bug or = if there=20 is a case where it is actually valid (in the report I have I don't = know if the=20 initiator also reissued the command with a valid CmdSN or = not).
 
Does anyone know?
 
Eddy
------_=_NextPart_001_01C6BC0D.75AD4D21-- --===============1474524435== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Ips mailing list Ips@ietf.org https://www1.ietf.org/mailman/listinfo/ips --===============1474524435==-- From ips-bounces@ietf.org Thu Aug 10 02:18:45 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GB3sM-0005t2-4j; Thu, 10 Aug 2006 02:18:38 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GB3sK-0005sx-Ji for ips@ietf.org; Thu, 10 Aug 2006 02:18:36 -0400 Received: from mtagate3.de.ibm.com ([195.212.29.152]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GB3sJ-0002Ym-1a for ips@ietf.org; Thu, 10 Aug 2006 02:18:36 -0400 Received: from d12nrmr1607.megacenter.de.ibm.com (d12nrmr1607.megacenter.de.ibm.com [9.149.167.49]) by mtagate3.de.ibm.com (8.13.7/8.13.7) with ESMTP id k7A6IYEd101520 for ; Thu, 10 Aug 2006 06:18:34 GMT Received: from d12av02.megacenter.de.ibm.com (d12av02.megacenter.de.ibm.com [9.149.165.228]) by d12nrmr1607.megacenter.de.ibm.com (8.13.6/8.13.6/NCO v8.1.1) with ESMTP id k7A6MF2i101784 for ; Thu, 10 Aug 2006 08:22:15 +0200 Received: from d12av02.megacenter.de.ibm.com (loopback [127.0.0.1]) by d12av02.megacenter.de.ibm.com (8.12.11.20060308/8.13.3) with ESMTP id k7A6IX7e017789 for ; Thu, 10 Aug 2006 08:18:33 +0200 Received: from d12mc102.megacenter.de.ibm.com (d12mc102.megacenter.de.ibm.com [9.149.167.114]) by d12av02.megacenter.de.ibm.com (8.12.11.20060308/8.12.11) with ESMTP id k7A6IXtu017786; Thu, 10 Aug 2006 08:18:33 +0200 In-Reply-To: <000601c6bc03$f2e3d8a0$f414a8c0@ivivity.com> To: "Eddy Quicksall" Subject: Re: [Ips] Re-sending a command MIME-Version: 1.0 X-Mailer: Lotus Notes Release 7.0.1 January 17, 2006 From: Julian Satran Message-ID: Date: Thu, 10 Aug 2006 09:22:13 +0300 X-MIMETrack: Serialize by Router on D12MC102/12/M/IBM(Release 7.0.1HF269 | June 22, 2006) at 10/08/2006 09:22:14, Serialize complete at 10/08/2006 09:22:14 X-Spam-Score: 0.1 (/) X-Scan-Signature: 287c806b254c6353fcb09ee0e53bbc5e Cc: ips@ietf.org, Amit Kumar X-BeenThere: ips@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IP Storage List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0628142100==" Errors-To: ips-bounces@ietf.org This is a multipart message in MIME format. --===============0628142100== Content-Type: multipart/alternative; boundary="=_alternative 0022A5D3C22571C6_=" This is a multipart message in MIME format. --=_alternative 0022A5D3C22571C6_= Content-Type: text/plain; charset="US-ASCII" Eddy, The LU reset "plugs the holes" in command sequence and the old CmdSN should not be used (it is definitely an initiator bug). If you have seen it Mallikarjun may want to mention that dropping the command is the expected behavior of the target after all the task management commands that "plug the holes" in the implementation guide. Julo "Eddy Quicksall" 10/08/06 01:34 To cc Amit Kumar Subject [Ips] Re-sending a command It was brought to my attention that one initiator being tested will re-issue a "timed out" command using the same CmdSN after it has issued a LU Reset. When this happens the command is dropped. Note that this is on a single connection session. I'm wondering if this could be an initiator bug or if there is a case where it is actually valid (in the report I have I don't know if the initiator also reissued the command with a valid CmdSN or not). Does anyone know? Eddy_______________________________________________ Ips mailing list Ips@ietf.org https://www1.ietf.org/mailman/listinfo/ips --=_alternative 0022A5D3C22571C6_= Content-Type: text/html; charset="US-ASCII"
Eddy,

The LU reset "plugs the holes" in command sequence and the old CmdSN should not be used (it is definitely an initiator bug). If you have seen it Mallikarjun may want to mention that dropping the command is the expected behavior of the target after all the task management commands that "plug the holes" in the implementation guide.

Julo


"Eddy Quicksall" <eddy_quicksall_iVivity_iSCSI@Comcast.net>

10/08/06 01:34

To
<ips@ietf.org>
cc
Amit Kumar <Amit_Kumar@ivivity.com>
Subject
[Ips] Re-sending a command





It was brought to my attention that one initiator being tested will re-issue a "timed out" command using the same CmdSN after it has issued a LU Reset. When this happens the command is dropped. Note that this is on a single connection session.
 
I'm wondering if this could be an initiator bug or if there is a case where it is actually valid (in the report I have I don't know if the initiator also reissued the command with a valid CmdSN or not).
 
Does anyone know?
 
Eddy_______________________________________________
Ips mailing list
Ips@ietf.org
https://www1.ietf.org/mailman/listinfo/ips
--=_alternative 0022A5D3C22571C6_=-- --===============0628142100== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Ips mailing list Ips@ietf.org https://www1.ietf.org/mailman/listinfo/ips --===============0628142100==-- From ips-bounces@ietf.org Thu Aug 10 06:57:44 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GB8EN-0000e4-V8; Thu, 10 Aug 2006 06:57:39 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GB8EM-0000dt-Me for ips@ietf.org; Thu, 10 Aug 2006 06:57:38 -0400 Received: from s-utl01-sjpop.stsn.net ([72.254.0.201]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1GB8EM-00045O-2v for ips@ietf.org; Thu, 10 Aug 2006 06:57:38 -0400 Received: from s-utl01-sjpop.stsn.net ([127.0.0.1]) by s-utl01-sjpop.stsn.net (SMSSMTP 4.1.2.20) with SMTP id M2006081003573109204 ; Thu, 10 Aug 2006 03:57:31 -0700 X-Spam-Status: No, hits=0.0 required=9.9 tests=ALL_TRUSTED: -2.867,AWL: -0.139,BAYES_00: -1.665, HTML_70_80: 0.039,HTML_MESSAGE: 0.001,HTML_TAG_EXIST_TBODY: 0.079, SARE_HTML_USL_1CHAR2: 0.2,SARE_RECV_ADDR: 0.027 X-Spam-Level: Received: from IVVTDKV0981 ([10.4.211.214]) by s-utl01-sjpop.stsn.net; Thu, 10 Aug 2006 03:57:30 -0700 Message-ID: <001d01c6bc6b$c61d7660$d6d3040a@ivivity.com> From: "Eddy Quicksall" To: "Julian Satran" References: Subject: Re: [Ips] Re-sending a command Date: Thu, 10 Aug 2006 06:57:19 -0400 MIME-Version: 1.0 X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.2869 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2869 X-Spam-Score: 0.2 (/) X-Scan-Signature: 4166dd0e0c668adc975c3d3e0f1bce3b Cc: ips@ietf.org, Amit Kumar X-BeenThere: ips@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IP Storage List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0166517612==" Errors-To: ips-bounces@ietf.org This is a multi-part message in MIME format. --===============0166517612== Content-Type: multipart/alternative; boundary="----=_NextPart_000_0018_01C6BC4A.38A5CE70" This is a multi-part message in MIME format. ------=_NextPart_000_0018_01C6BC4A.38A5CE70 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Thanks. I have pasted an example from Ken Sanders that is exactly the = case I have seen when using the Microsoft initiator. The initiator then = goes into a loop because every time it tries to reset, it sends the = command again with the old CmdSN which itself causes a timeout and = another reset. Eddy ----- Original Message -----=20 From: Sandars, Ken=20 To: Eddy Quicksall ; ips@ietf.org=20 Sent: Wednesday, August 09, 2006 7:42 PM Subject: RE: [Ips] Re-sending a command Hi Eddy, There's some reading between the lines needed, but if this is scenario = you are describing: I->T: CmdSN=3D25 ITT=3D1 SCSI1