From cbm@chadalapaka.com Sun Jul 1 16:01:28 2012 Return-Path: X-Original-To: storm@ietfa.amsl.com Delivered-To: storm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0376321F8715 for ; Sun, 1 Jul 2012 16:01:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.998 X-Spam-Level: X-Spam-Status: No, score=-2.998 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_35=0.6, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id UbTupqlGw301 for ; Sun, 1 Jul 2012 16:01:24 -0700 (PDT) Received: from db3outboundpool.messaging.microsoft.com (db3ehsobe006.messaging.microsoft.com [213.199.154.144]) by ietfa.amsl.com (Postfix) with ESMTP id E60D521F8709 for ; Sun, 1 Jul 2012 16:01:23 -0700 (PDT) Received: from mail23-db3-R.bigfish.com (10.3.81.226) by DB3EHSOBE002.bigfish.com (10.3.84.22) with Microsoft SMTP Server id 14.1.225.23; Sun, 1 Jul 2012 22:59:31 +0000 Received: from mail23-db3 (localhost [127.0.0.1]) by mail23-db3-R.bigfish.com (Postfix) with ESMTP id 5CF7F320358 for ; Sun, 1 Jul 2012 22:59:31 +0000 (UTC) X-Forefront-Antispam-Report: CIP:157.56.240.117; KIP:(null); UIP:(null); IPV:NLI; H:BL2PRD0610HT001.namprd06.prod.outlook.com; RD:none; EFVD:NLI X-SpamScore: -9 X-BigFish: PS-9(zzc85fh103dK1a09J14ffIzz1202hzz8275bh8275dh5eeeKz2fh2a8h668h839hd25hf0ah) Received-SPF: pass (mail23-db3: domain of chadalapaka.com designates 157.56.240.117 as permitted sender) client-ip=157.56.240.117; envelope-from=cbm@chadalapaka.com; helo=BL2PRD0610HT001.namprd06.prod.outlook.com ; .outlook.com ; Received: from mail23-db3 (localhost.localdomain [127.0.0.1]) by mail23-db3 (MessageSwitch) id 1341183567876518_12923; Sun, 1 Jul 2012 22:59:27 +0000 (UTC) Received: from DB3EHSMHS010.bigfish.com (unknown [10.3.81.247]) by mail23-db3.bigfish.com (Postfix) with ESMTP id CA05B160047 for ; Sun, 1 Jul 2012 22:59:27 +0000 (UTC) Received: from BL2PRD0610HT001.namprd06.prod.outlook.com (157.56.240.117) by DB3EHSMHS010.bigfish.com (10.3.87.110) with Microsoft SMTP Server (TLS) id 14.1.225.23; Sun, 1 Jul 2012 22:59:25 +0000 Received: from BL2PRD0610MB361.namprd06.prod.outlook.com ([169.254.11.249]) by BL2PRD0610HT001.namprd06.prod.outlook.com ([10.255.101.36]) with mapi id 14.16.0164.004; Sun, 1 Jul 2012 23:01:19 +0000 From: Mallikarjun Chadalapaka To: "storm@ietf.org" Thread-Topic: iSCSI -06 candidate-1 version Thread-Index: Ac1X3WE3rLXBUcNiQ46+fgKU7SCbYA== Date: Sun, 1 Jul 2012 23:01:18 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [76.22.17.63] Content-Type: multipart/alternative; boundary="_000_E160851FCED17643AE5F53B5D4D0783A235D7DAFBL2PRD0610MB361_" MIME-Version: 1.0 X-OriginatorOrg: chadalapaka.com Subject: [storm] iSCSI -06 candidate-1 version X-BeenThere: storm@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Storage Maintenance WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 01 Jul 2012 23:01:28 -0000 --_000_E160851FCED17643AE5F53B5D4D0783A235D7DAFBL2PRD0610MB361_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi All, Since the -05 version, iSCSI Consolidated draft received invaluable feedbac= k from a few folks, most notably from our AD Martin Stiemerling and Rob Ell= iott. Many thanks to both of them. I have now incorporated all the feedback - most of it is editorial/non-norm= ative in nature - with the exception of one major item, the X-/X# key-relat= ed changes that David sent out to the list last week - which the authors ar= e in agreement with. I will give it a few days for the list feedback, befor= e I incorporate those changes and submit the -06 version. I am including a list of all normative changes below. You can find the curr= ent working version of the draft, including the changes below, here: http://www.chadalapaka.com/Documents/draft-ietf-storm-iscsi-cons-06.pdf Please let the authors know of your feedback. Thanks! Mallikarjun Section 4.2.2.1 [from] The initiator and target must ensure that the task management commands act= as specified by [SAM2]. [to] The initiator and target MUST ensure that the SCSI task management function= s specified in [SAM2] act in accordance with the [SAM2] specification. Section 6.2 [from] An iSCSI initiator or target MAY terminate a negotiation that does not end = within a reasonable time or number of exchanges. [to] An iSCSI initiator or target MAY terminate a negotiation that does not term= inate within an implementation-specific reasonable time or number of exchan= ges, but SHOULD allow at least 6 exchanges. Section 6.2.2 [from] Proposing a value not admissible (e.g., not within the specified bounds) M= AY be answered with the constant "Reject" or the acceptor MAY select an a= dmissible value. [to] Proposing a value not admissible (e.g., not within the specified bounds) MA= Y be answered with the constant "Reject", otherwise the acceptor MUST selec= t an admissible value. Section 6.2.2 [from] For a numerical range the value selected must be an integer within the pro= posed range or "Reject" (if the range is unacceptable). [to] For a numerical range the value selected MUST be an integer within the prop= osed range or "Reject" (if the range is unacceptable). Section 6.3.3 [from] If the target responds to a Login request that has the T bit set to 1 with = a Login response that has the T bit set to 0, the initiator should keep sen= ding the Login request (even empty) with the T bit set to 1, while it still= wants to switch stage, until it receives the Login Response that has the T= bit set to 1 or it receives a key that requires it to set the T bit to 0. [to] Even when the initiator indicates its intent to switch stage by setting the= T bit to 1 in a Login request, the target MAY respond with a Login respons= e with the T bit set to 0. In that case, the initiator SHOULD continue to s= et the T bit to 1 in subsequent Login requests (even empty) that it sends, = until target sends a Login response with the T bit set to 1 or sends a key = that requires initiator to set the T bit to 0. Section 6.4 [from] if the target responds to a text request with the f bit set to 1 with a text response with the f bit set to 0, the initiator should keep sending the text request (even empty) with the f bit set to 1, while it still wants to finish the negotiation, until it receives the text response with the f bit set to 1. responding to a text request with the f bit set to 1 with an empty (no key=3Dvalue pairs) response with the f bit set to 0 is discouraged. [to] Even when the initiator indicates its intent to finish the negotiation by s= etting the F bit to 1 in a Text request, the target MAY respond with a Text= response with the F bit set to 0. In that case, the initiator SHOULD conti= nue to set the F bit to 1 in subsequent Text requests (even empty) that it = sends, until target sends the final Text response with the F bit set to 1. = Note that in the same case of Text request with the F bit set to 1, target = SHOULD NOT respond with an empty (no key=3Dvalue pairs) Text response with = the F bit set to 0, because such a response may cause the initiator to aban= don negotiation. Section 9.2 [from] Therefore, a method using clear text (or equivalent) passwords is not accep= table [to] Therefore, a method using clear text (or equivalent) passwords MUST NOT be = used Section 11.3.1 [from] Setting both the W and the F bit to 0 is an error [to] At least one of the W and F bits MUST be set to 1. Section 11.4.3 [from] A non-zero response field indicates a failure to execute the command in whi= ch case the Status and Flag fields are undefined. [to] A non-zero response field indicates a failure to execute the command in whi= ch case the Status and Flag fields are undefined and MUST be ignored on rec= eption. Section 11.4.5.1 [from] The Residual Count field MUST be valid in the case where either the U bit o= r the O bit is set. If neither bit is set, the Residual Count field is rese= rved. [to] The Residual Count field MUST be valid in the case where either the U bit o= r the O bit is set. If neither bit is set, the Residual Count field MUST be= ignored on reception and SHOULD be set to 0 when sending. Appendix C [add] The text in this Appendix is a normative part of this document. --_000_E160851FCED17643AE5F53B5D4D0783A235D7DAFBL2PRD0610MB361_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi All,

 

Since the -05 version, iSCSI Consolidated draft rece= ived invaluable feedback from a few folks, most notably from our AD Martin Stiemerling and Rob Elliott. Many t= hanks to both of them.

 

I have now incorpor= ated all the feedback - most of it is editorial/non-normative in nature = 211; with the exception of one major item, the X-/X# key-related changes th= at David sent out to the list last week – which the authors are in agreement with. I will give it a few days for the= list feedback, before I incorporate those changes and submit the -06 versi= on.

 

I am including a li= st of all normative changes below. You can find the current working version= of the draft, including the changes below, here:

 

http://www= .chadalapaka.com/Documents/draft-ietf-storm-iscsi-cons-06.pdf

 

Please let the auth= ors know of your feedback.

 

Thanks!<= /span>

 

Mallikarjun

 

 

<= /p>

Section 4.2.2.1

[from]

The initiator and target must  ensure that the ta= sk management commands act as specified by  [SAM2].

 

[to]

The initiator and target MUST ensure that the SCSI tas= k management functions specified in [SAM2] act in accordance with the [SAM2= ] specification.

 

Section 6.2

[from]

An iSCSI initiator or target MAY terminate a negotiati= on that does not end within a reasonable time or number of exchanges.<= /o:p>

 

[to]

An iSCSI initiator or target MAY terminate a negotiati= on that does not terminate within an implementation-specific reasonable tim= e or number of exchanges, but SHOULD allow at least 6 exchanges.=

 

Section 6.2.2

[from]

Proposing a value not admissible (e.g., not within the= specified  bounds) MAY be answered with the constant "Reject&quo= t; or the acceptor   MAY select an admissible value.

 

[to]

Proposing a value not admissible (e.g., not within the= specified bounds) MAY be answered with the constant "Reject", ot= herwise the acceptor MUST select an admissible value.

 

Section 6.2.2

[from]

For a numerical range the value selected must be an in= teger within  the proposed range or "Reject" (if the range i= s unacceptable).

 

 

[to]

For a numerical range the value selected MUST be an in= teger within the proposed range or "Reject" (if the range is unac= ceptable).

 

Section 6.3.3

[from]

If the target responds to a Login request that has the= T bit set to 1 with a Login response that has the T bit set to 0, the init= iator should keep sending the Login request (even empty) with the T bit set= to 1, while it still wants to switch stage, until it receives the Login Response that has the T bit set to 1 or= it receives a key that requires it to set the T bit to 0.

[to]

Even when the initi= ator indicates its intent to switch stage by setting the T bit to 1 in a Lo= gin request, the target MAY respond with a Login response with the T bit set to 0. In that case, the initiator SHOULD conti= nue to set the T bit to 1 in subsequent Login requests (even empty) that it= sends, until target sends a Login response with the T bit set to 1 or send= s a key that requires initiator to set the T bit to 0.

 

Section 6.4

[from]

  if the target responds to a text request with t= he f bit set to 1

  with a text response with the f bit set to 0, t= he initiator should

  keep sending the text request (even empty) with= the f bit set to

  1, while it still wants to finish the negotiati= on, until it

  receives the text response with the f bit set t= o 1. responding to

  a text request with the f bit set to 1 with an = empty (no key=3Dvalue

  pairs) response with the f bit set to 0 is disc= ouraged.

 

[to]

Even when the initiator indicates its intent to finish= the negotiation by setting the F bit to 1 in a Text request, the target MA= Y respond with a Text response with the F bit set to 0. In that case, the i= nitiator SHOULD continue to set the F bit to 1 in subsequent Text requests (even empty) that it sends, until t= arget sends the final Text response with the F bit set to 1. Note that in t= he same case of Text request with the F bit set to 1, target SHOULD NOT res= pond with an empty (no key=3Dvalue pairs) Text response with the F bit set to 0, because such a response may = cause the initiator to abandon negotiation.

 

Section 9.2

[from]

Therefore, a method using clear text (or equivalent) p= asswords is not acceptable

[to]

Therefore, a method using clear text (or equivalent) p= asswords MUST NOT be used

 

Section 11.3.1

[from]

Setting both the W and the F bit to 0 is an error

 

[to]

At least one of the W and F bits MUST be set to 1.

 

Section 11.4.3

[from]

A non-zero response field indicates a failure to execu= te the command in which case the Status and Flag fields are undefined.=

 

[to]

A non-zero response field indicates a failure to execu= te the command in which case the Status and Flag fields are undefined and M= UST be ignored on reception.

 

Section 11.4.5.1

[from]

The Residual Count field MUST be valid in the case whe= re either the U bit or the O bit is set. If neither bit is set, the Residua= l Count field is reserved.

 

[to]

The Residual Count field MUST be valid in the case whe= re either the U bit or the O bit is set. If neither bit is set, the Residua= l Count field MUST be ignored on reception and SHOULD be set to 0 when send= ing.

 

Appendix C

[add]

The text in this Appendix is a normative part of this docu= ment.

 

 

--_000_E160851FCED17643AE5F53B5D4D0783A235D7DAFBL2PRD0610MB361_-- From david.black@emc.com Mon Jul 2 14:22:48 2012 Return-Path: X-Original-To: storm@ietfa.amsl.com Delivered-To: storm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 963F921F8513 for ; Mon, 2 Jul 2012 14:22:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.455 X-Spam-Level: X-Spam-Status: No, score=-103.455 tagged_above=-999 required=5 tests=[AWL=1.144, BAYES_00=-2.599, GB_I_LETTER=-2, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id t3nlb4QgOfAb for ; Mon, 2 Jul 2012 14:22:47 -0700 (PDT) Received: from mexforward.lss.emc.com (hop-nat-141.emc.com [168.159.213.141]) by ietfa.amsl.com (Postfix) with ESMTP id 9713421F84B2 for ; Mon, 2 Jul 2012 14:22:47 -0700 (PDT) Received: from hop04-l1d11-si02.isus.emc.com (HOP04-L1D11-SI02.isus.emc.com [10.254.111.55]) by mexforward.lss.emc.com (Switch-3.4.3/Switch-3.4.3) with ESMTP id q62LMnRm024701 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Mon, 2 Jul 2012 17:22:51 -0400 Received: from mailhub.lss.emc.com (mailhubhoprd04.lss.emc.com [10.254.222.226]) by hop04-l1d11-si02.isus.emc.com (RSA Interceptor) for ; Mon, 2 Jul 2012 17:22:40 -0400 Received: from mxhub05.corp.emc.com (mxhub05.corp.emc.com [128.222.70.202]) by mailhub.lss.emc.com (Switch-3.4.3/Switch-3.4.3) with ESMTP id q62LMdbK016526 for ; Mon, 2 Jul 2012 17:22:39 -0400 Received: from mx15a.corp.emc.com ([169.254.1.189]) by mxhub05.corp.emc.com ([128.222.70.202]) with mapi; Mon, 2 Jul 2012 17:22:39 -0400 From: To: , Importance: high X-Priority: 1 Date: Mon, 2 Jul 2012 17:22:37 -0400 Thread-Topic: iSCSI: Protocol extension items Thread-Index: Ac1WKPOAo6f8UxMERK2SRvioM8mwngCaz7cg Message-ID: <8D3D17ACE214DC429325B2B98F3AE71208D3ABD4@MX15A.corp.emc.com> References: <8D3D17ACE214DC429325B2B98F3AE71208D3A987@MX15A.corp.emc.com> In-Reply-To: <8D3D17ACE214DC429325B2B98F3AE71208D3A987@MX15A.corp.emc.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-EMM-MHVC: 1 Subject: Re: [storm] iSCSI: Protocol extension items X-BeenThere: storm@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Storage Maintenance WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 02 Jul 2012 21:22:48 -0000 Thinking more about this ... > 1. Existing private X-keys may continue to remain private as before. > However, new private keys SHOULD NOT use the X- prefix in keeping > with [RFC6648]. Instead, new keys SHOULD start with a "V-" prefix, > followed by a reversed domain name, e.g. V-com.example.do_something RFC 6648 recommends against both X- and V-, so there's little value to that= change. Applying the "ain't broke, don't fix it" principle, it becomes hard to just= ify a cosmetic change from X- to V-. Hence I strongly suggest that we not do i= tem 1, and instead, just leave the X- private keys as-is, and explain that name= space separation has been working fine for iSCSI. Assuming that we get rid of the X#, Y# and Z# formats, the larger issue is that we would then have a very high hurdle for "registration" of experiment= al and testing parameters, namely Standards Action plus a namespace structure = that requires names that will be even uglier to standardize if a private text ke= y (or other extension item) needs to go into widespread use without a name ch= ange. One possibility would be to change the criteria for IANA registration of authentication methods, digests and Login/Text keys from the current "Stand= ards Action" (standards track RFC required) to either "IETF Review" (IESG must=20 approve, including an IETF Last Call, Informational or Experimental RFC is ok) or "RFC Required" (adds ability to use an independent submission to the RFC Editor). See RFC 5226 for details. It looks like "IETF Review" may be a good choice that reflects the limited = need (so far) for these values, but provides more flexibility than requiring a s= tandards track RFC. FWIW, I believe that this is roughly what's done to add crypto algorithms to IPsec (the resulting documents are often published as Informa= tional RFCs). Thoughts? Thanks, --David > -----Original Message----- > From: Black, David > Sent: Friday, June 29, 2012 2:57 PM > To: storm@ietf.org > Cc: Black, David > Subject: iSCSI: Protocol extension items > Importance: High >=20 > >=20 > The recent publication of RFC 6648 requires that we make some changes > to negotiation of iSCSI protocol extensions. This email explains why > changes are needed, describes what appears to be necessary and summarizes > the proposed detailed changes to requirements. >=20 > These proposed changes are to be made in the consolidated iSCSI draft, > and hence will apply to existing implementations. These proposed changes > should be backwards compatible with existing implementations, although > implementers should comment, especially on whether the migration from > X- to V- as the prefix for newly defined private extension text keys is > likely to cause problems. An example of such a problem is - receipt > of a key using the V- format is likely to generate a protocol error > instead of a NotUnderstood response to the V- new key. >=20 > Existing X- private use text keys are *not affected* by these proposed > changes, and can continue to be used. >=20 > > >=20 > iSCSI currently allows extension text keys (for negotiation), digest > (checksum) algorithms and authentication methods to be defined using > X, Y and Z (respectively) as the first character of the identifier. > In each case, there are two defined formats, e.g., for text keys: >=20 > X-reversed.vendor.dns_name.do_something [dash-based] > X<#> [hash-based] >=20 > The dash-based form (X-) is for private parameters, the hash-based > form (X#) is for public parameters registered with IANA. >=20 > RFC 6648 has recently been published. To borrow a line from Sesame Stree= t, > this RFC was brought to you by the letter X ;-). That RFC strongly recomm= ends > against use of the letter X in this fashion for non-private parameters, > and similarly discourages analogous prefixes that do not contain the lett= er > X. For iSCSI, RFC 6648 applies to the X#, Y# and Z# formats. >=20 > The history to date of use of the X#, Y# and Z# formats is that there has > been exactly one use, X#NodeArchitecture, which wound up being standardiz= ed > as a fully standard key. That full standardization is an example of why > RFC 6648 recommends not using an X-based prefix for public parameters - i= f > the parameter is successful, it will become part of the standard. Hence t= he > proposed approach is to retire the hash-based formats (MUST NOT use) for > public extensions with the exception that the X#NodeArchitecture key need= s > to be preserved. >=20 > It is still highly desirable to keep the dash-based formats (e.g., Y-) in > order to cleanly separate the private and public namespaces for each of t= hese > extension items. Among the reasons for doing so is that IANA is in the > process > of authorizing a number of new top-level domains that will make it somewh= at > harder to recognize a reversed domain name. >=20 > Nonetheless, in keeping with the spirit of RFC 6648, it seems prudent to > encourage use of a prefix other than X- for new text keys, without doing > anything to break current X- text keys. V- is suggested as the new prefi= x > (V can be thought of a short for "vendor"). OTOH, if this will break exi= sting > implementations, it's a bad idea (and we'll need to stick with X-) - see > the first part of this email. >=20 > The following approach is therefore currently proposed: >=20 > 1. Existing private X-keys may continue to remain private as before. > However, new private keys SHOULD NOT use the X- prefix in keeping > with [RFC6648]. Instead, new keys SHOULD start with a "V-" prefix, > followed by a reversed domain name, e.g. V-com.example.do_something >=20 > Note: If IANA registers something starting with V- as a new top > level domain, this approach still works because the V- prefix is > always added. For example, if V-org is a new top level domain, > an iSCSI text key for example.v-org would have the form > V-V-org.example.do_something, which is clearly identifiable as > a private extension key, even under case-insensitive character > string processing. >=20 > 2. Each new public key in the course of standardization MUST define the > acceptable responses to the key, including NotUnderstood as > appropriate. There is no need for a standard name prefix for keys > that allow NotUnderstood response. Note that NotUnderstood will > generally have to be allowed for new public keys for backwards > compatibility. >=20 > 3. Thus the name prefix "X#" in new public key names does not carry any > significance. New public key names MUST NOT begin with "X#" prefix > to avoid confusion. >=20 > 4. The existing public X# key - X#NodeArchitecture - will remain unchange= d. >=20 > 5. Based on our decade-long iSCSI usage experience, we know that Y# and > Z# name prefixes, for digest and authentication method extensions > respectively, were never used in practice. Similar to X# name prefix > for keys, there is no need for this namespace separation either. So > for the same reasons cited as for X# prefix, new digest and > authentication method extensions MUST NOT respectively use Y# and Z# > name prefixes. >=20 > 6. Private digest and authentication method extensions can continue to > respectively use Y- and Z- prefixes as in the current specification. >=20 > 7. IANA will be requested to do the following: > - Move X#NodeArchitecture to the iSCSI Login/Text Keys registry > - Remove the iSCSI extended key registry > - Not accept registrations of Y# extended digest algorithms or > Z# extended authentication methods (and hence not create > registries for these extension items). >=20 > Please comment, particularly on whether moving from X- to V- for new > text keys is likely to cause problems. >=20 > Thanks, > --David > ---------------------------------------------------- > David L. Black, Distinguished Engineer > EMC Corporation, 176 South St., Hopkinton, MA=A0 01748 > +1 (508) 293-7953=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 FAX: +1 (508) 293-7= 786 > david.black@emc.com=A0=A0=A0=A0=A0=A0=A0 Mobile: +1 (978) 394-7754 > ---------------------------------------------------- >=20 From david.black@emc.com Tue Jul 3 09:33:01 2012 Return-Path: X-Original-To: storm@ietfa.amsl.com Delivered-To: storm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2573221F86D9 for ; Tue, 3 Jul 2012 09:33:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.579 X-Spam-Level: X-Spam-Status: No, score=-102.579 tagged_above=-999 required=5 tests=[AWL=0.020, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hAZuAKuRnJYg for ; Tue, 3 Jul 2012 09:33:00 -0700 (PDT) Received: from mexforward.lss.emc.com (hop-nat-141.emc.com [168.159.213.141]) by ietfa.amsl.com (Postfix) with ESMTP id 72CD421F86D3 for ; Tue, 3 Jul 2012 09:33:00 -0700 (PDT) Received: from hop04-l1d11-si02.isus.emc.com (HOP04-L1D11-SI02.isus.emc.com [10.254.111.55]) by mexforward.lss.emc.com (Switch-3.4.3/Switch-3.4.3) with ESMTP id q63GX4vv000459 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Tue, 3 Jul 2012 12:33:07 -0400 Received: from mailhub.lss.emc.com (mailhub.lss.emc.com [10.254.222.130]) by hop04-l1d11-si02.isus.emc.com (RSA Interceptor) for ; Tue, 3 Jul 2012 12:32:51 -0400 Received: from mxhub20.corp.emc.com (mxhub20.corp.emc.com [10.254.93.49]) by mailhub.lss.emc.com (Switch-3.4.3/Switch-3.4.3) with ESMTP id q63GWpCv011691 for ; Tue, 3 Jul 2012 12:32:51 -0400 Received: from mx15a.corp.emc.com ([169.254.1.189]) by mxhub20.corp.emc.com ([10.254.93.49]) with mapi; Tue, 3 Jul 2012 12:32:51 -0400 From: To: Importance: high X-Priority: 1 Date: Tue, 3 Jul 2012 12:32:49 -0400 Thread-Topic: iSCSI - exchange count Thread-Index: Ac1ZOXxpax03poRETBq12DKtgGMvyA== Message-ID: <8D3D17ACE214DC429325B2B98F3AE71208D3ACC3@MX15A.corp.emc.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-EMM-MHVC: 1 Subject: [storm] iSCSI - exchange count X-BeenThere: storm@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Storage Maintenance WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 03 Jul 2012 16:33:01 -0000 I wanted to extract this change from Mallikarjun's long list of normative c= hanges to call it out for attention. The important question is: Is "6" the right number of exchanges that SHOULD= be allowed? There's nothing special about that number ... it "seemed like a good idea a= t the time". Alternate suggestions are welcome, especially if this change could cause an= y problems for current implementations. Section 6.2 [from] An iSCSI initiator or target MAY terminate a negotiation that does not end = within a reasonable time or number of exchanges. [to] An iSCSI initiator or target MAY terminate a negotiation that does not term= inate within an implementation-specific reasonable time or number of exchan= ges, but SHOULD allow at least 6 exchanges. Thanks, --David ---------------------------------------------------- David L. Black, Distinguished Engineer EMC Corporation, 176 South St., Hopkinton, MA=A0 01748 +1 (508) 293-7953=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 FAX: +1 (508) 293-778= 6 david.black@emc.com=A0=A0=A0=A0=A0=A0=A0 Mobile: +1 (978) 394-7754 ---------------------------------------------------- From cbm@chadalapaka.com Thu Jul 5 11:08:18 2012 Return-Path: X-Original-To: storm@ietfa.amsl.com Delivered-To: storm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 06B0A21F8585 for ; Thu, 5 Jul 2012 11:08:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.599 X-Spam-Level: X-Spam-Status: No, score=-5.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, GB_I_LETTER=-2, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ww1nhPiZSV50 for ; Thu, 5 Jul 2012 11:08:16 -0700 (PDT) Received: from db3outboundpool.messaging.microsoft.com (db3ehsobe003.messaging.microsoft.com [213.199.154.141]) by ietfa.amsl.com (Postfix) with ESMTP id ED61C21F84DC for ; Thu, 5 Jul 2012 11:08:15 -0700 (PDT) Received: from mail99-db3-R.bigfish.com (10.3.81.245) by DB3EHSOBE003.bigfish.com (10.3.84.23) with Microsoft SMTP Server id 14.1.225.23; Thu, 5 Jul 2012 18:06:23 +0000 Received: from mail99-db3 (localhost [127.0.0.1]) by mail99-db3-R.bigfish.com (Postfix) with ESMTP id 380F9180107; Thu, 5 Jul 2012 18:06:23 +0000 (UTC) X-Forefront-Antispam-Report: CIP:157.56.240.117; KIP:(null); UIP:(null); IPV:NLI; H:BL2PRD0610HT005.namprd06.prod.outlook.com; RD:none; EFVD:NLI X-SpamScore: -32 X-BigFish: PS-32(zz9371Ic0cK542M1432I4015I1447Izz1202hzz1033IL8275bh8275dhz2fh2a8h668h839hd25hf0ah107ah) Received-SPF: pass (mail99-db3: domain of chadalapaka.com designates 157.56.240.117 as permitted sender) client-ip=157.56.240.117; envelope-from=cbm@chadalapaka.com; helo=BL2PRD0610HT005.namprd06.prod.outlook.com ; .outlook.com ; Received: from mail99-db3 (localhost.localdomain [127.0.0.1]) by mail99-db3 (MessageSwitch) id 1341511580787770_14246; Thu, 5 Jul 2012 18:06:20 +0000 (UTC) Received: from DB3EHSMHS010.bigfish.com (unknown [10.3.81.240]) by mail99-db3.bigfish.com (Postfix) with ESMTP id B8D8AA0048; Thu, 5 Jul 2012 18:06:20 +0000 (UTC) Received: from BL2PRD0610HT005.namprd06.prod.outlook.com (157.56.240.117) by DB3EHSMHS010.bigfish.com (10.3.87.110) with Microsoft SMTP Server (TLS) id 14.1.225.23; Thu, 5 Jul 2012 18:06:20 +0000 Received: from BL2PRD0610MB361.namprd06.prod.outlook.com ([169.254.11.249]) by BL2PRD0610HT005.namprd06.prod.outlook.com ([10.255.101.40]) with mapi id 14.16.0164.004; Thu, 5 Jul 2012 18:08:24 +0000 From: Mallikarjun Chadalapaka To: "david.black@emc.com" , "storm@ietf.org" Thread-Topic: iSCSI: Protocol extension items Thread-Index: Ac1WKPOAo6f8UxMERK2SRvioM8mwngCaz7cgACwNJBA= Date: Thu, 5 Jul 2012 18:08:23 +0000 Message-ID: References: <8D3D17ACE214DC429325B2B98F3AE71208D3A987@MX15A.corp.emc.com> <8D3D17ACE214DC429325B2B98F3AE71208D3ABD4@MX15A.corp.emc.com> In-Reply-To: <8D3D17ACE214DC429325B2B98F3AE71208D3ABD4@MX15A.corp.emc.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [131.107.174.123] Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: chadalapaka.com Subject: Re: [storm] iSCSI: Protocol extension items X-BeenThere: storm@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Storage Maintenance WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 05 Jul 2012 18:08:18 -0000 David, Thanks for the follow-up. I'd be OK leaving X-keys intact, assuming that's an acceptable answer to IE= SG.=20 Regarding "IETF Review" requirement, I think we are already on that path. S= ection 5 in RFC 4850 already effectively makes these changes. Excerpt: 4) In Section 13.3, the description of allowed RFC types for extension items is changed from "The RFC may be informational rather than Standards-Track," to "The RFC MUST be standards track, experimental, or informational," 5) In Section 13.5.2, the phrase "standards track" is changed to "standards track or experimental" in the last sentence of the first paragraph, so that the sentence reads: "If the specification is a standards track or experimental document, the usual IETF procedures for such documents are followed." I was planning to bring these changes over into current text in consolidate= d draft, in my promised updates for this thread. Mallikarjun =20 -----Original Message----- From: storm-bounces@ietf.org [mailto:storm-bounces@ietf.org] On Behalf Of d= avid.black@emc.com Sent: Monday, July 02, 2012 2:23 PM To: david.black@emc.com; storm@ietf.org Subject: Re: [storm] iSCSI: Protocol extension items Importance: High Thinking more about this ... > 1. Existing private X-keys may continue to remain private as before. > However, new private keys SHOULD NOT use the X- prefix in keeping > with [RFC6648]. Instead, new keys SHOULD start with a "V-" prefix, > followed by a reversed domain name, e.g.=20 > V-com.example.do_something RFC 6648 recommends against both X- and V-, so there's little value to that= change. Applying the "ain't broke, don't fix it" principle, it becomes hard to just= ify a cosmetic change from X- to V-. Hence I strongly suggest that we not = do item 1, and instead, just leave the X- private keys as-is, and explain t= hat namespace separation has been working fine for iSCSI. Assuming that we get rid of the X#, Y# and Z# formats, the larger issue is = that we would then have a very high hurdle for "registration" of experiment= al and testing parameters, namely Standards Action plus a namespace structu= re that requires names that will be even uglier to standardize if a private= text key (or other extension item) needs to go into widespread use without= a name change. One possibility would be to change the criteria for IANA registration of au= thentication methods, digests and Login/Text keys from the current "Standar= ds Action" (standards track RFC required) to either "IETF Review" (IESG mus= t approve, including an IETF Last Call, Informational or Experimental RFC i= s ok) or "RFC Required" (adds ability to use an independent submission to the= RFC Editor). See RFC 5226 for details. It looks like "IETF Review" may be a good choice that reflects the limited = need (so far) for these values, but provides more flexibility than requirin= g a standards track RFC. FWIW, I believe that this is roughly what's done = to add crypto algorithms to IPsec (the resulting documents are often publis= hed as Informational RFCs). Thoughts? Thanks, --David > -----Original Message----- > From: Black, David > Sent: Friday, June 29, 2012 2:57 PM > To: storm@ietf.org > Cc: Black, David > Subject: iSCSI: Protocol extension items > Importance: High >=20 > >=20 > The recent publication of RFC 6648 requires that we make some changes=20 > to negotiation of iSCSI protocol extensions. This email explains why=20 > changes are needed, describes what appears to be necessary and=20 > summarizes the proposed detailed changes to requirements. >=20 > These proposed changes are to be made in the consolidated iSCSI draft,=20 > and hence will apply to existing implementations. These proposed=20 > changes should be backwards compatible with existing implementations,=20 > although implementers should comment, especially on whether the=20 > migration from > X- to V- as the prefix for newly defined private extension text keys=20 > is likely to cause problems. An example of such a problem is -=20 > receipt of a key using the V- format is likely to generate a protocol=20 > error instead of a NotUnderstood response to the V- new key. >=20 > Existing X- private use text keys are *not affected* by these proposed=20 > changes, and can continue to be used. >=20 > > >=20 > iSCSI currently allows extension text keys (for negotiation), digest > (checksum) algorithms and authentication methods to be defined using=20 > X, Y and Z (respectively) as the first character of the identifier. > In each case, there are two defined formats, e.g., for text keys: >=20 > X-reversed.vendor.dns_name.do_something [dash-based] > X<#> [hash-based] >=20 > The dash-based form (X-) is for private parameters, the hash-based=20 > form (X#) is for public parameters registered with IANA. >=20 > RFC 6648 has recently been published. To borrow a line from Sesame=20 > Street, this RFC was brought to you by the letter X ;-). That RFC=20 > strongly recommends against use of the letter X in this fashion for=20 > non-private parameters, and similarly discourages analogous prefixes=20 > that do not contain the letter X. For iSCSI, RFC 6648 applies to the X#,= Y# and Z# formats. >=20 > The history to date of use of the X#, Y# and Z# formats is that there=20 > has been exactly one use, X#NodeArchitecture, which wound up being=20 > standardized as a fully standard key. That full standardization is an=20 > example of why RFC 6648 recommends not using an X-based prefix for=20 > public parameters - if the parameter is successful, it will become=20 > part of the standard. Hence the proposed approach is to retire the=20 > hash-based formats (MUST NOT use) for public extensions with the=20 > exception that the X#NodeArchitecture key needs to be preserved. >=20 > It is still highly desirable to keep the dash-based formats (e.g., Y-)=20 > in order to cleanly separate the private and public namespaces for=20 > each of these extension items. Among the reasons for doing so is that=20 > IANA is in the process of authorizing a number of new top-level=20 > domains that will make it somewhat harder to recognize a reversed=20 > domain name. >=20 > Nonetheless, in keeping with the spirit of RFC 6648, it seems prudent=20 > to encourage use of a prefix other than X- for new text keys, without=20 > doing anything to break current X- text keys. V- is suggested as the=20 > new prefix (V can be thought of a short for "vendor"). OTOH, if this=20 > will break existing implementations, it's a bad idea (and we'll need=20 > to stick with X-) - see the first part of this email. >=20 > The following approach is therefore currently proposed: >=20 > 1. Existing private X-keys may continue to remain private as before. > However, new private keys SHOULD NOT use the X- prefix in keeping > with [RFC6648]. Instead, new keys SHOULD start with a "V-" prefix, > followed by a reversed domain name, e.g.=20 > V-com.example.do_something >=20 > Note: If IANA registers something starting with V- as a new top > level domain, this approach still works because the V- prefix is > always added. For example, if V-org is a new top level domain, > an iSCSI text key for example.v-org would have the form > V-V-org.example.do_something, which is clearly identifiable as > a private extension key, even under case-insensitive character > string processing. >=20 > 2. Each new public key in the course of standardization MUST define the > acceptable responses to the key, including NotUnderstood as > appropriate. There is no need for a standard name prefix for keys > that allow NotUnderstood response. Note that NotUnderstood will > generally have to be allowed for new public keys for backwards > compatibility. >=20 > 3. Thus the name prefix "X#" in new public key names does not carry any > significance. New public key names MUST NOT begin with "X#" prefix > to avoid confusion. >=20 > 4. The existing public X# key - X#NodeArchitecture - will remain unchange= d. >=20 > 5. Based on our decade-long iSCSI usage experience, we know that Y# and > Z# name prefixes, for digest and authentication method extensions > respectively, were never used in practice. Similar to X# name prefix > for keys, there is no need for this namespace separation either. So > for the same reasons cited as for X# prefix, new digest and > authentication method extensions MUST NOT respectively use Y# and Z# > name prefixes. >=20 > 6. Private digest and authentication method extensions can continue to > respectively use Y- and Z- prefixes as in the current specification. >=20 > 7. IANA will be requested to do the following: > - Move X#NodeArchitecture to the iSCSI Login/Text Keys registry > - Remove the iSCSI extended key registry > - Not accept registrations of Y# extended digest algorithms or > Z# extended authentication methods (and hence not create > registries for these extension items). >=20 > Please comment, particularly on whether moving from X- to V- for new=20 > text keys is likely to cause problems. >=20 > Thanks, > --David > ---------------------------------------------------- > David L. Black, Distinguished Engineer EMC Corporation, 176 South St.,=20 > Hopkinton, MA=A0 01748 > +1 (508) 293-7953=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 FAX: +1 (508) 293-7= 786 > david.black@emc.com=A0=A0=A0=A0=A0=A0=A0 Mobile: +1 (978) 394-7754 > ---------------------------------------------------- >=20 _______________________________________________ storm mailing list storm@ietf.org https://www.ietf.org/mailman/listinfo/storm From david.black@emc.com Thu Jul 5 12:10:46 2012 Return-Path: X-Original-To: storm@ietfa.amsl.com Delivered-To: storm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 010B221F86C3 for ; Thu, 5 Jul 2012 12:10:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.491 X-Spam-Level: X-Spam-Status: No, score=-103.491 tagged_above=-999 required=5 tests=[AWL=1.108, BAYES_00=-2.599, GB_I_LETTER=-2, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id TKPwVmMc8PZK for ; Thu, 5 Jul 2012 12:10:41 -0700 (PDT) Received: from mexforward.lss.emc.com (hop-nat-141.emc.com [168.159.213.141]) by ietfa.amsl.com (Postfix) with ESMTP id BC18321F8661 for ; Thu, 5 Jul 2012 12:10:38 -0700 (PDT) Received: from hop04-l1d11-si01.isus.emc.com (HOP04-L1D11-SI01.isus.emc.com [10.254.111.54]) by mexforward.lss.emc.com (Switch-3.4.3/Switch-3.4.3) with ESMTP id q65JAiGp026999 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 5 Jul 2012 15:10:50 -0400 Received: from mailhub.lss.emc.com (mailhubhoprd02.lss.emc.com [10.254.221.253]) by hop04-l1d11-si01.isus.emc.com (RSA Interceptor); Thu, 5 Jul 2012 15:10:19 -0400 Received: from mxhub21.corp.emc.com (mxhub21.corp.emc.com [128.222.70.133]) by mailhub.lss.emc.com (Switch-3.4.3/Switch-3.4.3) with ESMTP id q65JAIDI029039; Thu, 5 Jul 2012 15:10:18 -0400 Received: from mx15a.corp.emc.com ([169.254.1.189]) by mxhub21.corp.emc.com ([128.222.70.133]) with mapi; Thu, 5 Jul 2012 15:10:18 -0400 From: To: , Date: Thu, 5 Jul 2012 15:10:16 -0400 Thread-Topic: iSCSI: Protocol extension items Thread-Index: Ac1WKPOAo6f8UxMERK2SRvioM8mwngCaz7cgACwNJBAAZsIs4A== Message-ID: <8D3D17ACE214DC429325B2B98F3AE71208D3AE47@MX15A.corp.emc.com> References: <8D3D17ACE214DC429325B2B98F3AE71208D3A987@MX15A.corp.emc.com> <8D3D17ACE214DC429325B2B98F3AE71208D3ABD4@MX15A.corp.emc.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-EMM-MHVC: 1 Subject: Re: [storm] iSCSI: Protocol extension items X-BeenThere: storm@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Storage Maintenance WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 05 Jul 2012 19:10:46 -0000 Mallikarjun, >> I'd be OK leaving X-keys intact, assuming that's an acceptable answer to= IESG. Good - I think we can make it acceptable to the IESG ;-). Specifically: > Applying the "ain't broke, don't fix it" principle, it becomes hard to ju= stify > a cosmetic change from X- to V-. Hence I strongly suggest that we not do= item > 1, and instead, just leave the X- private keys as-is, and explain that > namespace separation has been working fine for iSCSI. I'm signing up to have this discussion with the IESG if we attract a DISCUS= S on this topic. I think that discussion will boil down to three key points: 1) "IETF Review" is good enough for the base namespaces wrt RFC 6648 and the strength of "IETF Review" is important to iSCSI's stability. 2) At least for text keys, we clearly need an ability for individual implementers to define keys with a much lower bar than "IETF Review". That's what the X- prefix is for (and likewise for Y- and Z-). 3) RFC 6648 suggests that we SHOULD allow X- prefixed text keys to be registered in the base key registry (requires "IETF Review") in order to avoid a name change for a key that becomes popular. We should do this (heck, we already have an X# key there, the X- keys with reversed domain names are not that much worse and are encouraged by RFC 6648), plus likewise for Y- and Z- items. > Regarding "IETF Review" requirement, I think we are already on that path. > Section 5 in RFC 4850 already effectively makes these changes. Those changes would also need to be reflected in the IANA Considerations section, along with item 3) above, as I don't think IANA's picked them up, and two of the registries are currently "RFC Required" (which is=20 weaker/broader) courtesy of not having separate Y# and Z# registries. I'll volunteer to help with the IANA Considerations text is my "copious spare time" ;-), as IANA will need to be told exactly what is supposed to change and how on this page: http://www.iana.org/assignments/iscsi-parameters/iscsi-parameters.xml I may not be able to spend time on this until the first part of next week. Thanks, --David > -----Original Message----- > From: Mallikarjun Chadalapaka [mailto:cbm@chadalapaka.com] > Sent: Thursday, July 05, 2012 2:08 PM > To: Black, David; storm@ietf.org > Cc: Martin Stiemerling (martin.stiemerling@neclab.eu) > Subject: RE: iSCSI: Protocol extension items >=20 > David, >=20 > Thanks for the follow-up. >=20 > I'd be OK leaving X-keys intact, assuming that's an acceptable answer to = IESG. >=20 > Regarding "IETF Review" requirement, I think we are already on that path. > Section 5 in RFC 4850 already effectively makes these changes. Excerpt: >=20 > 4) In Section 13.3, the description of allowed RFC types for > extension items is changed from "The RFC may be informational > rather than Standards-Track," to "The RFC MUST be standards track, > experimental, or informational," >=20 > 5) In Section 13.5.2, the phrase "standards track" is changed to > "standards track or experimental" in the last sentence of the > first paragraph, so that the sentence reads: "If the specification > is a standards track or experimental document, the usual IETF > procedures for such documents are followed." >=20 >=20 > I was planning to bring these changes over into current text in consolida= ted > draft, in my promised updates for this thread. >=20 > Mallikarjun >=20 >=20 > -----Original Message----- > From: storm-bounces@ietf.org [mailto:storm-bounces@ietf.org] On Behalf Of > david.black@emc.com > Sent: Monday, July 02, 2012 2:23 PM > To: david.black@emc.com; storm@ietf.org > Subject: Re: [storm] iSCSI: Protocol extension items > Importance: High >=20 > >=20 > Thinking more about this ... >=20 > > 1. Existing private X-keys may continue to remain private as before. > > However, new private keys SHOULD NOT use the X- prefix in keeping > > with [RFC6648]. Instead, new keys SHOULD start with a "V-" prefix, > > followed by a reversed domain name, e.g. > > V-com.example.do_something >=20 > RFC 6648 recommends against both X- and V-, so there's little value to th= at > change. >=20 > Applying the "ain't broke, don't fix it" principle, it becomes hard to ju= stify > a cosmetic change from X- to V-. Hence I strongly suggest that we not do= item > 1, and instead, just leave the X- private keys as-is, and explain that > namespace separation has been working fine for iSCSI. >=20 > Assuming that we get rid of the X#, Y# and Z# formats, the larger issue i= s > that we would then have a very high hurdle for "registration" of experime= ntal > and testing parameters, namely Standards Action plus a namespace structur= e > that requires names that will be even uglier to standardize if a private = text > key (or other extension item) needs to go into widespread use without a n= ame > change. >=20 > One possibility would be to change the criteria for IANA registration of > authentication methods, digests and Login/Text keys from the current > "Standards Action" (standards track RFC required) to either "IETF Review" > (IESG must approve, including an IETF Last Call, Informational or Experim= ental > RFC is > ok) or "RFC Required" (adds ability to use an independent submission to t= he > RFC Editor). See RFC 5226 for details. >=20 > It looks like "IETF Review" may be a good choice that reflects the limite= d > need (so far) for these values, but provides more flexibility than requir= ing a > standards track RFC. FWIW, I believe that this is roughly what's done to= add > crypto algorithms to IPsec (the resulting documents are often published a= s > Informational RFCs). >=20 > Thoughts? >=20 > Thanks, > --David >=20 >=20 > > -----Original Message----- > > From: Black, David > > Sent: Friday, June 29, 2012 2:57 PM > > To: storm@ietf.org > > Cc: Black, David > > Subject: iSCSI: Protocol extension items > > Importance: High > > > > > > > > The recent publication of RFC 6648 requires that we make some changes > > to negotiation of iSCSI protocol extensions. This email explains why > > changes are needed, describes what appears to be necessary and > > summarizes the proposed detailed changes to requirements. > > > > These proposed changes are to be made in the consolidated iSCSI draft, > > and hence will apply to existing implementations. These proposed > > changes should be backwards compatible with existing implementations, > > although implementers should comment, especially on whether the > > migration from > > X- to V- as the prefix for newly defined private extension text keys > > is likely to cause problems. An example of such a problem is - > > receipt of a key using the V- format is likely to generate a protocol > > error instead of a NotUnderstood response to the V- new key. > > > > Existing X- private use text keys are *not affected* by these proposed > > changes, and can continue to be used. > > > > > > > > > > iSCSI currently allows extension text keys (for negotiation), digest > > (checksum) algorithms and authentication methods to be defined using > > X, Y and Z (respectively) as the first character of the identifier. > > In each case, there are two defined formats, e.g., for text keys: > > > > X-reversed.vendor.dns_name.do_something [dash-based] > > X<#> [hash-based] > > > > The dash-based form (X-) is for private parameters, the hash-based > > form (X#) is for public parameters registered with IANA. > > > > RFC 6648 has recently been published. To borrow a line from Sesame > > Street, this RFC was brought to you by the letter X ;-). That RFC > > strongly recommends against use of the letter X in this fashion for > > non-private parameters, and similarly discourages analogous prefixes > > that do not contain the letter X. For iSCSI, RFC 6648 applies to the X= #, Y# > and Z# formats. > > > > The history to date of use of the X#, Y# and Z# formats is that there > > has been exactly one use, X#NodeArchitecture, which wound up being > > standardized as a fully standard key. That full standardization is an > > example of why RFC 6648 recommends not using an X-based prefix for > > public parameters - if the parameter is successful, it will become > > part of the standard. Hence the proposed approach is to retire the > > hash-based formats (MUST NOT use) for public extensions with the > > exception that the X#NodeArchitecture key needs to be preserved. > > > > It is still highly desirable to keep the dash-based formats (e.g., Y-) > > in order to cleanly separate the private and public namespaces for > > each of these extension items. Among the reasons for doing so is that > > IANA is in the process of authorizing a number of new top-level > > domains that will make it somewhat harder to recognize a reversed > > domain name. > > > > Nonetheless, in keeping with the spirit of RFC 6648, it seems prudent > > to encourage use of a prefix other than X- for new text keys, without > > doing anything to break current X- text keys. V- is suggested as the > > new prefix (V can be thought of a short for "vendor"). OTOH, if this > > will break existing implementations, it's a bad idea (and we'll need > > to stick with X-) - see the first part of this email. > > > > The following approach is therefore currently proposed: > > > > 1. Existing private X-keys may continue to remain private as before. > > However, new private keys SHOULD NOT use the X- prefix in keeping > > with [RFC6648]. Instead, new keys SHOULD start with a "V-" prefix, > > followed by a reversed domain name, e.g. > > V-com.example.do_something > > > > Note: If IANA registers something starting with V- as a new top > > level domain, this approach still works because the V- prefix is > > always added. For example, if V-org is a new top level domain, > > an iSCSI text key for example.v-org would have the form > > V-V-org.example.do_something, which is clearly identifiable as > > a private extension key, even under case-insensitive character > > string processing. > > > > 2. Each new public key in the course of standardization MUST define the > > acceptable responses to the key, including NotUnderstood as > > appropriate. There is no need for a standard name prefix for keys > > that allow NotUnderstood response. Note that NotUnderstood will > > generally have to be allowed for new public keys for backwards > > compatibility. > > > > 3. Thus the name prefix "X#" in new public key names does not carry any > > significance. New public key names MUST NOT begin with "X#" prefix > > to avoid confusion. > > > > 4. The existing public X# key - X#NodeArchitecture - will remain unchan= ged. > > > > 5. Based on our decade-long iSCSI usage experience, we know that Y# and > > Z# name prefixes, for digest and authentication method extensions > > respectively, were never used in practice. Similar to X# name prefi= x > > for keys, there is no need for this namespace separation either. So > > for the same reasons cited as for X# prefix, new digest and > > authentication method extensions MUST NOT respectively use Y# and Z= # > > name prefixes. > > > > 6. Private digest and authentication method extensions can continue to > > respectively use Y- and Z- prefixes as in the current specification= . > > > > 7. IANA will be requested to do the following: > > - Move X#NodeArchitecture to the iSCSI Login/Text Keys registry > > - Remove the iSCSI extended key registry > > - Not accept registrations of Y# extended digest algorithms or > > Z# extended authentication methods (and hence not create > > registries for these extension items). > > > > Please comment, particularly on whether moving from X- to V- for new > > text keys is likely to cause problems. > > > > Thanks, > > --David > > ---------------------------------------------------- > > David L. Black, Distinguished Engineer EMC Corporation, 176 South St., > > Hopkinton, MA=A0 01748 > > +1 (508) 293-7953=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 FAX: +1 (508) 293= -7786 > > david.black@emc.com=A0=A0=A0=A0=A0=A0=A0 Mobile: +1 (978) 394-7754 > > ---------------------------------------------------- > > >=20 > _______________________________________________ > storm mailing list > storm@ietf.org > https://www.ietf.org/mailman/listinfo/storm >=20 From david.black@emc.com Mon Jul 9 17:13:33 2012 Return-Path: X-Original-To: storm@ietfa.amsl.com Delivered-To: storm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B879821F8661 for ; Mon, 9 Jul 2012 17:13:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.51 X-Spam-Level: X-Spam-Status: No, score=-102.51 tagged_above=-999 required=5 tests=[AWL=0.088, BAYES_00=-2.599, HTML_MESSAGE=0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zB231aq08ku4 for ; Mon, 9 Jul 2012 17:13:28 -0700 (PDT) Received: from mexforward.lss.emc.com (hop-nat-141.emc.com [168.159.213.141]) by ietfa.amsl.com (Postfix) with ESMTP id 248A121F8643 for ; Mon, 9 Jul 2012 17:13:18 -0700 (PDT) Received: from hop04-l1d11-si01.isus.emc.com (HOP04-L1D11-SI01.isus.emc.com [10.254.111.54]) by mexforward.lss.emc.com (Switch-3.4.3/Switch-3.4.3) with ESMTP id q6A0DiPH017711 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Mon, 9 Jul 2012 20:13:44 -0400 Received: from mailhub.lss.emc.com (mailhubhoprd01.lss.emc.com [10.254.221.251]) by hop04-l1d11-si01.isus.emc.com (RSA Interceptor) for ; Mon, 9 Jul 2012 20:13:29 -0400 Received: from mxhub28.corp.emc.com (mxhub28.corp.emc.com [10.254.110.184]) by mailhub.lss.emc.com (Switch-3.4.3/Switch-3.4.3) with ESMTP id q6A0DSRA004531 for ; Mon, 9 Jul 2012 20:13:28 -0400 Received: from mx15a.corp.emc.com ([169.254.1.189]) by mxhub28.corp.emc.com ([10.254.110.184]) with mapi; Mon, 9 Jul 2012 20:13:27 -0400 From: To: Date: Mon, 9 Jul 2012 20:13:26 -0400 Thread-Topic: [storm] iSER - what to do Thread-Index: Ac1Ty+GpVpipEWmqT+25wCmH5a9MOgAASPsgApjLkWA= Message-ID: <8D3D17ACE214DC429325B2B98F3AE71208D3B0CA@MX15A.corp.emc.com> References: <8D3D17ACE214DC429325B2B98F3AE71208C14966@MX15A.corp.emc.com> <8D3D17ACE214DC429325B2B98F3AE71208C14A8F@MX15A.corp.emc.com> In-Reply-To: <8D3D17ACE214DC429325B2B98F3AE71208C14A8F@MX15A.corp.emc.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: multipart/alternative; boundary="_000_8D3D17ACE214DC429325B2B98F3AE71208D3B0CAMX15Acorpemccom_" MIME-Version: 1.0 X-EMM-MHVC: 1 Subject: Re: [storm] iSER - what to do X-BeenThere: storm@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Storage Maintenance WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 10 Jul 2012 00:13:33 -0000 --_000_8D3D17ACE214DC429325B2B98F3AE71208D3B0CAMX15Acorpemccom_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable I think we have a couple of choices. - A revised draft this week as outlined in this thread below. - Pick up discussion again in August or September after the Vancouver meeti= ngs. At this point, I think we're headed for August or September. Thanks, --David From: storm-bounces@ietf.org [mailto:storm-bounces@ietf.org] On Behalf Of d= avid.black@emc.com Sent: Tuesday, June 26, 2012 3:02 PM To: mkosjc@gmail.com Cc: storm@ietf.org Subject: Re: [storm] iSER - what to do Mike, Thanks for responding - we will eventually get to a conclusion in this disc= ussion :-). I'm adding two comments to try to sharpen the discussion of the current sol= ution: > The current solution is for the initiator to post an extra buffer before > sending the last Login Request as the target most probably sends the next > NOP-IN only after some timeout period measuring in seconds or hundreds of > milliseconds. But this is not a foolproof solution as the target MAY > theoretically send up to MaxOustandingUnexpectedPUDs to the initiator. Right - my thought about how to make it fool-resistant is to require that the target MUST NOT send the next unsolicited PDU until at least 200ms after the first one or after receipt of a full-phase PDU from the initiator (that requirement could be a "SHOULD NOT" with a warning that sending sooner risks the initiator closing the RCaP connection). I pulled 200ms out of my proverbial "hat" and would like to see comments on what a good number would be for both IB and iWarp. > But if we look at the current solution, the initiator is already > posting an extra buffer before sending the last Login Request. Given > that the existing implementation is broken and has to be fixed anyway, > how difficult would it be for it to post MaxOustandingUnexpectedPDU > instead of just an extra one before sending the last Login Request? That's a question for Alexander and other implementers. My guess is that we're talking about quite a few buffers, and there may be resource manageme= nt advantages to not allocating that full set of resources until the initiator is committed to the connection. Thanks, --David From: Michael Ko [mailto:mkosjc@gmail.com] Sent: Tuesday, June 26, 2012 2:45 PM To: Black, David Cc: storm@ietf.org Subject: Re: [storm] iSER - what to do The last minute problem as related by Alex stems from the fact that the iSE= R initiator posts its RX buffers for that connection only after the final L= ogin Response arrives. During that time (after the target had sent the Las= t Login Response but before the Full Featured phase related RX-buffers are posted on the initiator side= ) the target may send the first NOP-IN as it considers the connection in Fu= ll Featured phase already and MaxOutstandingUnexpectedPDUs has been negotia= ted to a non-zero value. The current solution is for the initiator to post an extra buffer before se= nding the last Login Request as the target most probably sends the next NOP= -IN only after some timeout period measuring in seconds or hundreds of mill= iseconds. But this is not a foolproof solution as the target MAY theoretic= ally send up to MaxOustandingUnexpectedPUDs to the initiator. The new proposed solution is to require iSER Hello exchanges in order to de= lay the onset of the iSER assisted Full Featured phase until the iSERHelloR= eply PDU has arrived at the target. This allows the initiator to delay pos= ting its RX buffers until after receiving the final LoginResponse returns b= ut before sending the iSER Hello PDU. To support this new proposed solutio= n, the iSERHelloRequired key must be negotiated to Yes. This require both = sides support the new iSERHelloRequired key, leading to the need for clarif= ying texts suggested by David in the spec in order to specify what should b= e done otherwise. But if we look at the current solution, the initiator is already posting an= extra buffer before sending the last Login Request. Given that the existi= ng implementation is broken and has to be fixed anyway, how difficult would= it be for it to post MaxOustandingUnexpectedPDU instead of just an extra o= ne before sending the last Login Request? This complies with the spec and = is guaranteed to work. The alternative is to require the use of and implem= ent iSER Hello exchanges. If the partner does not support the new iSERHell= oRequired key, the solution fails anyway. It seems to me it makes more sen= se (and a cleaner soluton besides) for the initiator to allocate the iSER r= esources, i.e., MaxOustandingUnexpectedPDUs, before sending the last Login = Request as stated in the spec than requiring both sides to support iSER Hel= lo exchanges and negotiate the new key. Mike On Tue, Jun 26, 2012 at 6:16 AM, > wrote: The discussion about whether the buffer behavior of the Linux iSER implementation complies with RFC 5046 is missing at least one important point - to my knowledge, there are *no* iSER implementations that comply with RFC 5046. After RFC 5046 was issued, implementers looked at its requirements and decided to do a number of things differently - the important difference for this discussion is that the iSER Hello exchange is not implemented, even though RFC 5046 requires that it be used. There are a number of other "running code" changes in the current iSER draft that reflect implementations and that are incompatible with RFC 5046, see Appendix A of the draft for details. The iSER work item was added to the storm WG's charter in order to produce an RFC specification of iSER that matches the "running code" and hence will interoperate with existing implementations. Here's the text from the WG charter: (6) iSER: Experience with Infiniband implementations suggest a few minor updates to reflect what has been done in practice. As WG chair, I'm going to insist on the following: 1) The iSER draft has to match the implementations in order to be published as an RFC. Replacing RFC 5046 with another RFC that won't interoperate with the implementations is pointless. 2) The issue encountered by the Linux iSER implementation cannot be ignored by the WG. The workaround (1 extra buffer, at most one unsolicited PDU until initiator has time to deploy resources) at least needs to be explained in the draft. 3) While requiring the iSER Hello exchange may be the proverbial "right thing to do" going forward, it is necessary to provide at least guidance on how to interoperate with current iSER implementations that don't support the Hello exchange. In contrast, as WG chair, I'm not going to insist that we adopt the workaround as part of the standard. For example, it's possible to recommend (SHOULD) use of the iSER Hello exchange (explicitly negotiated using the new key) and explain the workaround as what should be done in order to interoperate if that key results in a NotUnderstood response. For this approach to the workaround, I think a lower case "should" may be acceptable (e.g., as opposed to a "SHOULD" or "MUST", but that's subject to further discussion. Thanks, --David ---------------------------------------------------- David L. Black, Distinguished Engineer EMC Corporation, 176 South St., Hopkinton, MA 01748 +1 (508) 293-7953 FAX: +1 (508= ) 293-7786 david.black@emc.com Mobile: +1 (978) 394= -7754 ---------------------------------------------------- _______________________________________________ storm mailing list storm@ietf.org https://www.ietf.org/mailman/listinfo/storm --_000_8D3D17ACE214DC429325B2B98F3AE71208D3B0CAMX15Acorpemccom_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

<WG chair hat on&= gt;

 

I think we have a couple of choices.

 

- A revised draft = this week as outlined in this thread below.

- Pick up discussion again in August or September after the Vancou= ver meetings.

 

At this point, I think we’re headed for August = or September.

 

Thanks,
--David

=

 

From: storm-bounces@ietf.org [mailto:storm-bounces@ie= tf.org] On Behalf Of david.black@emc.com
Sent: Tuesday, Ju= ne 26, 2012 3:02 PM
To: mkosjc@gmail.com
Cc: storm@ietf= .org
Subject: Re: [storm] iSER - what to do

=

 

= Mike= ,

 

<WG chair hat off>

 

Thanks for responding - we will = eventually get to a conclusion in this discussion :-).

 

I’m ad= ding two comments to try to sharpen the discussion of the current solution:=

 

> The current solution is for the initiator to post an extra bu= ffer before

> sending the last Log= in Request as the target most probably sends the next

=

> NOP-IN only after some timeout period measuring in se= conds or hundreds of

> millisecon= ds.  But this is not a foolproof solution as the target MAY=

> theoretica= lly send up to MaxOustandingUnexpectedPUDs to the initiator.

Right - my thought about how to make it fool-resist= ant is to require that

the target MUS= T NOT send the next unsolicited PDU until at least 200ms<= /p>

after the first one or after receipt of a full-phase PD= U from the initiator

(that requireme= nt could be a “SHOULD NOT” with a warning that sending

sooner risks the initiator closing the RCaP c= onnection).  I pulled 200ms

= out = of my proverbial “hat” and would like to see comments on what a=

good number would be for both IB and= iWarp.

 

<= p class=3DMsoNormal>> But if we look at the current solution, the initiator = is already

> posting an extra buff= er before sending the last Login Request.  Given

=

> that the existing implementation is broken and has to= be fixed anyway,

> how difficult = would it be for it to post MaxOustandingUnexpectedPDU

=

> instead of just an extra one before sending the last = Login Request? 

 

That’s a question for Alexander and oth= er implementers.  My guess is that

we’re talking about quite a few buffers, and there may be resource= management

advantages to not allocat= ing that full set of resources until the initiator

is committed to the connection.

 

Thanks,
--Da= vid

 =

From: Michael Ko [mailto:mkosjc= @gmail.com]
Sent: Tuesday, June 26, 2012 2:45 PM
To: B= lack, David
Cc: storm@ietf.org
Subject: Re: [storm] iSE= R - what to do

&= nbsp;

The last= minute problem as related by Alex stems from the fact that the iSER initia= tor posts its RX buffers for that connection only after the final Login Res= ponse arrives.  During that time (after the target had sent the Last L= ogin Response but before
the Full Featured phase related RX-buffers are = posted on the initiator side) the target may send the first NOP-IN as it co= nsiders the connection in Full Featured phase already and MaxOutstandingUne= xpectedPDUs has been negotiated to a non-zero value.

The current sol= ution is for the initiator to post an extra buffer before sending the last = Login Request as the target most probably sends the next NOP-IN only after = some timeout period measuring in seconds or hundreds of milliseconds. = But this is not a foolproof solution as the target MAY theoretically send = up to MaxOustandingUnexpectedPUDs to the initiator.

The new proposed= solution is to require iSER Hello exchanges in order to delay the onset of= the iSER assisted Full Featured phase until the iSERHelloReply PDU has arr= ived at the target.  This allows the initiator to delay posting its RX= buffers until after receiving the final LoginResponse returns but before s= ending the iSER Hello PDU.  To support this new proposed solution, the= iSERHelloRequired key must be negotiated to Yes.  This require both s= ides support the new iSERHelloRequired key, leading to the need for clarify= ing texts suggested by David in the spec in order to specify what should be= done otherwise.

But if we look at the current solution, the initiat= or is already posting an extra buffer before sending the last Login Request= .  Given that the existing implementation is broken and has to be fixe= d anyway, how difficult would it be for it to post MaxOustandingUnexpectedP= DU instead of just an extra one before sending the last Login Request? = ; This complies with the spec and is guaranteed to work.  The alternat= ive is to require the use of and implement iSER Hello exchanges.  If t= he partner does not support the new iSERHelloRequired key, the solution fai= ls anyway.  It seems to me it makes more sense (and a cleaner soluton = besides) for the initiator to allocate the iSER resources, i.e., MaxOustand= ingUnexpectedPDUs, before sending the last Login Request as stated in the s= pec than requiring both sides to support iSER Hello exchanges and negotiate= the new key.

Mike

On Tue, J= un 26, 2012 at 6:16 AM, <david.black@emc.com> wrote:

<WG chair hat on>

The discussion about whether the buff= er behavior of the Linux iSER
implementation complies with RFC 5046 is m= issing at least one
important point - to my knowledge, there are *no* iS= ER
implementations that comply with RFC 5046.

After RFC 5046 was = issued, implementers looked at its requirements and
decided to do a numb= er of things differently - the important difference
for this discussion = is that the iSER Hello exchange is not implemented,
even though RFC 5046= requires that it be used.  There are a number of
other "runni= ng code" changes in the current iSER draft that reflect
implementat= ions and that are incompatible with RFC 5046, see Appendix A
of the draf= t for details.

The iSER work item was added to the storm WG's charte= r in order to produce
an RFC specification of iSER that matches the &quo= t;running code" and hence will
interoperate with existing implement= ations.  Here's the text from the
WG charter:

    =    (6) iSER: Experience with Infiniband implementations suggest       a few minor updates to reflect what has been d= one in practice.

As WG chair, I'm going to insist on the following:<= br>1) The iSER draft has to match the implementations in order to be
&nb= sp;      published as an RFC.  Replacing RFC 5046 with = another RFC that
       won't interoperate with the = implementations is pointless.
2) The issue encountered by the Linux iSER= implementation cannot be
       ignored by the WG. =  The workaround (1 extra buffer, at most
       = ;one unsolicited PDU until initiator has time to deploy
    &n= bsp;  resources) at least needs to be explained in the draft.
3) Wh= ile requiring the iSER Hello exchange may be the proverbial
   = ;    "right thing to do" going forward, it is necessary= to provide
       at least guidance on how to inter= operate with current iSER
       implementations tha= t don't support the Hello exchange.

In contrast, as WG chair, I'm no= t going to insist that we adopt the
workaround as part of the standard. =  For example, it's possible to
recommend (SHOULD) use of the iSER H= ello exchange (explicitly negotiated
using the new key) and explain the = workaround as what should be
done in order to interoperate if that key r= esults in a NotUnderstood
response.  For this approach to the worka= round, I think a lower case
"should" may be acceptable (e.g., = as opposed to a "SHOULD" or "MUST",
but that's subje= ct to further discussion.

Thanks,
--David
--------------------= --------------------------------
David L. Black, Distinguished Engineer<= br>EMC Corporation, 176 South St., Hopkinton, MA  01748
+1 (508) 293-7953   &nb= sp;         FAX: +1 (508) 293-7786
david.black@emc.com      &= nbsp; Mobile: +1 (978) 394-7754=
----------------------------------------------------


___= ____________________________________________
storm mailing list
storm@ietf.org
https://www.ietf.org/mail= man/listinfo/storm

 =

= --_000_8D3D17ACE214DC429325B2B98F3AE71208D3B0CAMX15Acorpemccom_-- From david.black@emc.com Mon Jul 9 17:21:11 2012 Return-Path: X-Original-To: storm@ietfa.amsl.com Delivered-To: storm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8D66611E8168 for ; Mon, 9 Jul 2012 17:21:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.513 X-Spam-Level: X-Spam-Status: No, score=-102.513 tagged_above=-999 required=5 tests=[AWL=0.086, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id O8aMa+LwDQzF for ; Mon, 9 Jul 2012 17:21:10 -0700 (PDT) Received: from mexforward.lss.emc.com (hop-nat-141.emc.com [168.159.213.141]) by ietfa.amsl.com (Postfix) with ESMTP id 4D27811E8163 for ; Mon, 9 Jul 2012 17:21:10 -0700 (PDT) Received: from hop04-l1d11-si02.isus.emc.com (HOP04-L1D11-SI02.isus.emc.com [10.254.111.55]) by mexforward.lss.emc.com (Switch-3.4.3/Switch-3.4.3) with ESMTP id q6A0LZHx002302 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Mon, 9 Jul 2012 20:21:36 -0400 Received: from mailhub.lss.emc.com (mailhubhoprd03.lss.emc.com [10.254.221.145]) by hop04-l1d11-si02.isus.emc.com (RSA Interceptor) for ; Mon, 9 Jul 2012 20:21:17 -0400 Received: from mxhub09.corp.emc.com (mxhub09.corp.emc.com [10.254.92.104]) by mailhub.lss.emc.com (Switch-3.4.3/Switch-3.4.3) with ESMTP id q6A0LGQd030579 for ; Mon, 9 Jul 2012 20:21:17 -0400 Received: from mx15a.corp.emc.com ([169.254.1.189]) by mxhub09.corp.emc.com ([10.254.92.104]) with mapi; Mon, 9 Jul 2012 20:21:16 -0400 From: To: Importance: high X-Priority: 1 Date: Mon, 9 Jul 2012 20:21:15 -0400 Thread-Topic: Draft cutoff in 1 week Thread-Index: Ac1eMetMsgvVaTzjSHaXTvpdFbDEtA== Message-ID: <8D3D17ACE214DC429325B2B98F3AE71208D3B0CD@MX15A.corp.emc.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-EMM-MHVC: 1 Subject: [storm] Draft cutoff in 1 week X-BeenThere: storm@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Storage Maintenance WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 10 Jul 2012 00:21:12 -0000 Reminder to all draft authors: The draft submission cutoff for the Vancouve= r meetings is next Monday (July 16) at 5pm Pacific Time. Please don't miss i= t! Revised versions of a number of the WG's drafts are expected by then - at l= east the two iSCSI drafts and the iSCSI MIB by then, and there may be slightly r= evised versions of the iSER and RDMAP extensions drafts coming as well. Thanks, --David ---------------------------------------------------- David L. Black, Distinguished Engineer EMC Corporation, 176 South St., Hopkinton, MA=A0 01748 +1 (508) 293-7953=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 FAX: +1 (508) 293-778= 6 david.black@emc.com=A0=A0=A0=A0=A0=A0=A0 Mobile: +1 (978) 394-7754 ---------------------------------------------------- From internet-drafts@ietf.org Tue Jul 10 14:11:48 2012 Return-Path: X-Original-To: storm@ietfa.amsl.com Delivered-To: storm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4E4D511E80E6; Tue, 10 Jul 2012 14:11:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.449 X-Spam-Level: X-Spam-Status: No, score=-102.449 tagged_above=-999 required=5 tests=[AWL=0.151, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id elwGlSxH4Gl3; Tue, 10 Jul 2012 14:11:47 -0700 (PDT) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B01FC11E80C4; Tue, 10 Jul 2012 14:11:47 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 4.30p3 Message-ID: <20120710211147.2049.33194.idtracker@ietfa.amsl.com> Date: Tue, 10 Jul 2012 14:11:47 -0700 Cc: storm@ietf.org Subject: [storm] I-D Action: draft-ietf-storm-rdmap-ext-03.txt X-BeenThere: storm@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Storage Maintenance WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 10 Jul 2012 21:11:48 -0000 A New Internet-Draft is available from the on-line Internet-Drafts director= ies. This draft is a work item of the STORage Maintenance Working Group of the = IETF. Title : RDMA Protocol Extensions Author(s) : Hemal Shah Felix Marti Wael Noureddine Asgeir Eiriksson Robert Sharp Filename : draft-ietf-storm-rdmap-ext-03.txt Pages : 31 Date : 2012-07-10 Abstract: This document specifies extensions to the IETF Remote Direct Memory Access Protocol (RDMAP [RFC5040]). RDMAP provides read and write services directly to applications and enables data to be transferred directly into Upper Layer Protocol (ULP) Buffers without intermediate data copies. The extensions specified in this document provide the following capabilities and/or improvements: Atomic Operations and Immediate Data. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-storm-rdmap-ext There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-storm-rdmap-ext-03 A diff from previous version is available at: http://tools.ietf.org/rfcdiff?url2=3Ddraft-ietf-storm-rdmap-ext-03 Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From david.black@emc.com Tue Jul 10 14:51:53 2012 Return-Path: X-Original-To: storm@ietfa.amsl.com Delivered-To: storm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2A7BC11E8121 for ; Tue, 10 Jul 2012 14:51:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.499 X-Spam-Level: X-Spam-Status: No, score=-102.499 tagged_above=-999 required=5 tests=[AWL=0.100, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ei1jcTp5oW6T for ; Tue, 10 Jul 2012 14:51:52 -0700 (PDT) Received: from mexforward.lss.emc.com (hop-nat-141.emc.com [168.159.213.141]) by ietfa.amsl.com (Postfix) with ESMTP id 613CF11E8119 for ; Tue, 10 Jul 2012 14:51:52 -0700 (PDT) Received: from hop04-l1d11-si03.isus.emc.com (HOP04-L1D11-SI03.isus.emc.com [10.254.111.23]) by mexforward.lss.emc.com (Switch-3.4.3/Switch-3.4.3) with ESMTP id q6ALqHdV031055 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Tue, 10 Jul 2012 17:52:17 -0400 Received: from mailhub.lss.emc.com (mailhub.lss.emc.com [10.254.221.253]) by hop04-l1d11-si03.isus.emc.com (RSA Interceptor) for ; Tue, 10 Jul 2012 17:52:05 -0400 Received: from mxhub36.corp.emc.com (mxhub36.corp.emc.com [10.254.93.84]) by mailhub.lss.emc.com (Switch-3.4.3/Switch-3.4.3) with ESMTP id q6ALq5Ro007621 for ; Tue, 10 Jul 2012 17:52:05 -0400 Received: from mx15a.corp.emc.com ([169.254.1.189]) by mxhub36.corp.emc.com ([::1]) with mapi; Tue, 10 Jul 2012 17:52:05 -0400 From: To: Date: Tue, 10 Jul 2012 17:52:04 -0400 Thread-Topic: I-D Action: draft-ietf-storm-rdmap-ext-03.txt Thread-Index: Ac1e4LlASeE3PpgiTcysanoqHR9RhAABS02g Message-ID: <8D3D17ACE214DC429325B2B98F3AE71208D3B203@MX15A.corp.emc.com> References: <20120710211147.2049.33194.idtracker@ietfa.amsl.com> In-Reply-To: <20120710211147.2049.33194.idtracker@ietfa.amsl.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-EMM-MHVC: 1 Subject: Re: [storm] I-D Action: draft-ietf-storm-rdmap-ext-03.txt X-BeenThere: storm@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Storage Maintenance WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 10 Jul 2012 21:51:53 -0000 I asked the authors to post this update in order to avoid the draft expirin= g, as I'd been hoping that we'd finish off the iSER draft a while ago. It loo= ks like they've also made some minor changes to queue number usage for the new RDMA operations. I do want to send this draft to WG Last Call not too long after the IETF Vancouver meetings (and I intend to review it prior to those meetings). Thanks, --David > -----Original Message----- > From: i-d-announce-bounces@ietf.org [mailto:i-d-announce-bounces@ietf.org= ] On > Behalf Of internet-drafts@ietf.org > Sent: Tuesday, July 10, 2012 5:12 PM > To: i-d-announce@ietf.org > Cc: storm@ietf.org > Subject: I-D Action: draft-ietf-storm-rdmap-ext-03.txt >=20 >=20 > A New Internet-Draft is available from the on-line Internet-Drafts > directories. > This draft is a work item of the STORage Maintenance Working Group of th= e > IETF. >=20 > Title : RDMA Protocol Extensions > Author(s) : Hemal Shah > Felix Marti > Wael Noureddine > Asgeir Eiriksson > Robert Sharp > Filename : draft-ietf-storm-rdmap-ext-03.txt > Pages : 31 > Date : 2012-07-10 >=20 > Abstract: > This document specifies extensions to the IETF Remote Direct Memory > Access Protocol (RDMAP [RFC5040]). RDMAP provides read and write > services directly to applications and enables data to be transferred > directly into Upper Layer Protocol (ULP) Buffers without > intermediate data copies. The extensions specified in this document > provide the following capabilities and/or improvements: Atomic > Operations and Immediate Data. >=20 >=20 >=20 >=20 > The IETF datatracker status page for this draft is: > https://datatracker.ietf.org/doc/draft-ietf-storm-rdmap-ext >=20 > There's also a htmlized version available at: > http://tools.ietf.org/html/draft-ietf-storm-rdmap-ext-03 >=20 > A diff from previous version is available at: > http://tools.ietf.org/rfcdiff?url2=3Ddraft-ietf-storm-rdmap-ext-03 >=20 >=20 > Internet-Drafts are also available by anonymous FTP at: > ftp://ftp.ietf.org/internet-drafts/ >=20 > _______________________________________________ > I-D-Announce mailing list > I-D-Announce@ietf.org > https://www.ietf.org/mailman/listinfo/i-d-announce > Internet-Draft directories: http://www.ietf.org/shadow.html > or ftp://ftp.ietf.org/ietf/1shadow-sites.txt From Mark_Bakke@DELL.com Wed Jul 11 06:05:25 2012 Return-Path: X-Original-To: storm@ietfa.amsl.com Delivered-To: storm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BE7D121F8685 for ; Wed, 11 Jul 2012 06:05:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -104.595 X-Spam-Level: X-Spam-Status: No, score=-104.595 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4, TRACKER_ID=2.003, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ORshkbq4wkNA for ; Wed, 11 Jul 2012 06:05:13 -0700 (PDT) Received: from aussmtpmrkps320.us.dell.com (aussmtpmrkps320.us.dell.com [143.166.224.254]) by ietfa.amsl.com (Postfix) with ESMTP id 55D4B21F861E for ; Wed, 11 Jul 2012 06:05:11 -0700 (PDT) X-Loopcount0: from 64.238.244.148 X-IronPort-AV: E=Sophos;i="4.77,567,1336366800"; d="scan'208,217";a="536988610" Received: from mail.compellent.com ([64.238.244.148]) by aussmtpmrkps320.us.dell.com with ESMTP; 11 Jul 2012 08:05:42 -0500 From: Mark Bakke To: "Storm (storm@ietf.org)" Date: Wed, 11 Jul 2012 08:05:31 -0500 Thread-Topic: MIB Doctor Review for iSCSI MIB, proposed changes, and list questions Thread-Index: Ac1d7t+U2g2vOeQ/QtWQihiahn+w8QBdtJpw Message-ID: <975552A94CBC0F4DA60ED7B36C949CBA03F17813D9@shandy.Beer.Town> References: <975552A94CBC0F4DA60ED7B36C949CBA03F1781133@shandy.Beer.Town> In-Reply-To: <975552A94CBC0F4DA60ED7B36C949CBA03F1781133@shandy.Beer.Town> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: multipart/alternative; boundary="_000_975552A94CBC0F4DA60ED7B36C949CBA03F17813D9shandyBeerTow_" MIME-Version: 1.0 X-Mailman-Approved-At: Wed, 11 Jul 2012 08:02:15 -0700 Cc: "mrm@vmware.com" , "prakashvn@hcl.com" Subject: [storm] FW: MIB Doctor Review for iSCSI MIB, proposed changes, and list questions X-BeenThere: storm@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Storage Maintenance WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 11 Jul 2012 13:05:25 -0000 --_000_975552A94CBC0F4DA60ED7B36C949CBA03F17813D9shandyBeerTow_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Everyone, We are in the process of updating the iSCSI MIB module, to match the latest= storm changes. Mike MacFaden has also done a MIB Doctor review, which bro= ught back a number of comments on things that are potentially missing from = the original iSCSI MIB RFC. Prakash, David, Tom and I have been reviewing the MIB doctor requests. Thi= s message is intended to answer some of the MIB doctor comments as well as = generate discussion on the list about possible changes. We intend to post = another draft (-02) before the July 16th deadline for the next round of dis= cussion. Here is a brief summary. The full responses to comments are below. * Several editorial changes * A few new fields are added to objects that are either useful or w= ere missed the first time around * More complex additions that we believe will need a separate revis= ion and may affect the object model. The latter changes would require supp= ort from those intending to implement or use them. I will start separate discussion threads on a few items: * Heartbeat counters for NOP-In and NOP-Out usage * TCP MIB correlation for sessions and connections * iscsiInstanceSsnErrorStatsTable session details For reference, we have: * The previous draft of the new iSCSI MIB - http://www.ietf.org/id/= draft-ietf-storm-iscsimib-01.txt * The initial MIB doctor review - http://www.macfaden.com/ietf/iscs= i-mib-1-reviewed.txt * An additional MIB doctor review with VMware engineers - http://ma= cfaden.com/ietf/iscsi-mib-notes.txt Detailed responses to MIB doctor review: February 17, 2012 MIB DOCTOR Review: http://www.ietf.org/id/draft-ietf-stor= m-iscsimib-01.txt Performed by Michael R. MacFaden, VMware, Inc According to http://tools.ietf.org/html/rfc4181 This review only covers syntax, SMIv2 rules usage of the MIB module itself,= not the draft. Some of the things mentioned below exist the prior version of the mib, not = this update. 1 boiler plate - check 2. Narrative Sections - check 3. Security Considerations - check 4. IANA Considerations - missing editors' note. Section 9 needs the following verbiage to be added. Editor's Note (to be removed prior to publication): this draft makes no additional requests of the IANA. Editors: We will fix this. 5. No new namespaces 6. References section - check 7. copyright notice - check 8. Intellectual Property section - missing Editors: We will add the section: Copyright (c) 2011 IETF Trust and the persons identified as authors of the code. All rights reserved. Redistribution and use in source and binary forms, with or without modification, is permitted pursuant to, and subject to the license terms contained in, the Simplified BSD License set forth in Section 4.c of the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info)." 9. This change updates existing mib rfc http://www.ietf.org/rfc/rfc4544.txt= - check Backward compatibility checks: (oids, object-identities, remained the sa= me) Other items checked -- syntax check: smilint -l9 - no errors smicng : not run spelling: Aspell --- no misspellings found. URLs validated: checked for valid, not-broken links: http://www.iana.org/assignments/protocol-numbers References in MIB module not found in normative (sec 10.1) IscsiTransportProtocol TC -> "RFC791, RFC1700 Editors: We will fix this. enumerations: each element described - IscsiDigestMethod Editors: We had this in the description - is there something else that need= s to be added? DiscontinuityTime is syntax: TimeStamp All Counters: define their discontinuity timestamp. Editors: We checked the descriptions in each of the Counter32 and Counter64= fields, and they all reference a discontinuity timestamp. Isn't that enou= gh? Uncommon stuff: 1) In IscsiPortalAttributesEntry has RowStatus as second item in the conce= ptual row, not after iscsiPortalStorageType. Editors: We currently don't put StorageType and RowStatus together in any o= f our objects, and didn't originally realize there was some tradition aroun= d this. Changing numbering now would cause backward compatibility problems= , so we cannot make this change. 2) iscsiPortalRoles does not have a DEFVAL when most others do in this conc= eptual table. iscsiPortalAddrType has def val of IPV4? when the iscsiPortalAddr has no de= fault to go with it? Editors: There isn't a reasonable DEFVAL for iscsiPortalRoles. It has to = be set when creating the row, so we will leave this one. 3) iscsiNodeAttributesEntry sez: An entry (row) containing mana vs 'conceptual row' which is used inconsistently. Editors: We will change this description from: An entry (row) containing management information applicable to a particular iSCSI node. To A conceptual row containing management information applicable to a particular iSCSI node. 4) (e.g. not created via this MIB). vs MIB module. There is but one MIB a= s Dr Case would say. Editors: We will fix this one. 5) 64 bit counters with SNMPv1 support for 32 bit high/low? kinda iscsiSsnTxDataOctets, iscsiSsnRxDataOctets, provides only low word: iscsi= SsnLCTxDataOctets, iscsiSsnLCRxDataOctets Compliance phrasing is a bit odd: "A Low Capacity shadow object of iscsiSsnTxDataOctets for those systems that don't support Counter64. instead of 'for those systems which are accessible via SNMPv1 only' Editors: We will fix the wording for SNMPv1. We don't see a reason to add= objects for high octets. 6) Notifications are required to have a rate limited implementation by a de= scription, yet the number of times the failure occurred is not conveyed in the no= tifcation varbind list. iscsiTgtLoginFailure, iscsiIntrLoginFailure, iscsiInstSessionFailure To avoid sending an excessive number of notifications due to multiple errors counted, an SNMP agent implementing this notification SHOULD NOT send more than 3 notifications of this type in any 10-second time period." Editors: We believe that this is covered by the counter "iscsiTgtLoginFail= ures": iscsiTgtLoginFailure NOTIFICATION-TYPE OBJECTS { iscsiTgtLoginFailures, iscsiTgtLastFailureType, iscsiTgtLastIntrFailureName, iscsiTgtLastIntrFailureAddrType, iscsiTgtLastIntrFailureAddr } The following section addresses comments from the VMware iSCSI-MIB review: Notes from VMware ISCIS-MIB review meeting March 21, 2012 Attendees: Andy Banta, Kun Huang, Mike MacFaden General comments: 1. Many objects lacking REFERENCE clause or offer only vague references. For those managed objects having a Reference clause, nedd to fix up 'RFC cc= cc' For example: "RFC cccc, Section 7.5, Connection Timeout Management" Example of vague reference: REFERENCE "SCSI-MIB" Editors: OK, we can update in the next draft. 2. Descriptions are short and simple but in some case seem a bit too short for an IETF standard mib module. Editors: We can look for opportunities to clarify but don't think we want t= o go through and rewrite a lot. If there are particular descriptions that = cause confusion please bring them up. Here's the comments by object in the MIB module: draft-ietf-storm-iscsimib-= 01.txt iscsiMibModule(1.3.6.1.2.1.142) | +--iscsiNotifications(0) | | | +--iscsiTgtLoginFailure(1) [iscsiTgtLoginFailures,iscsiTgtLastFailureT= ype,iscsiTgtLastIntrFailureName,iscsiTgtLastIntrFailureAddrType,iscsiTgtLas= tIntrFailureAddr] Consider adding port number. Editors: LastFailurePortNumber would be easy enough to add. Should we do a= n OrZero for implementations that can't get the port number? | +--iscsiIntrLoginFailure(2) [iscsiIntrLoginFailures,iscsiIntrLastFailu= reType,iscsiIntrLastTgtFailureName,iscsiIntrLastTgtFailureAddrType,iscsiInt= rLastTgtFailureAddr] Can't determine if the failure is due to failure of the underlying transpor= t or not. When transport is TCP there should be some way to get to the TCP-MIB/TCP-ES= TATS-MIB diagnostics. See notes on iscsiInstanceSsnErrorStatsTable. Consider adding port number. Editors: Same as above. On the failure, is it useful to have both local an= d remote addr and port number? Will the TCP MIB keep these connections aro= und long enough to go index it on a failed connection? If we add these fie= lds, will someone use them? | +--iscsiInstSessionFailure(3) [iscsiInstSsnFailures,iscsiInstLastSsnFa= ilureType,iscsiInstLastSsnRmtNodeName] Consider handling the event "Target Unmapped" by updatingiscsiInstLastSsnF= ailureType of a Session failure, as well. Editors: FailureType is an OID pointing to a stat in iscsiInstSsnErrorStats= Table, so we would need to add to this: iscsiInstSsnTgtUnmappedErrors Counter32 Are there others that would be needed? Consider adding summary notification in the case of larger scales (number o= f targets) what about large scales, # of targets, each target have a failure of simila= r sort. Editors: Would such a notification really be used? If there was a large sc= ale failure of many targets, we believe the administrator would see enough = of the notifications to notice it as a larger problem. | | +--iscsiInstanceSsnErrorStatsTable(2) | | | | | +--iscsiInstanceSsnErrorStatsEntry(1) [iscsiInstIndex] | | | | | +-- r-n Counter32 iscsiInstSsnDigestErrors(1) | | +-- r-n Counter32 iscsiInstSsnCxnTimeoutErrors(2) | | +-- r-n Counter32 iscsiInstSsnFormatErrors(3) Related states for transport are not provided in this table. Either a RowPo= inter to another mib module is needed or a generic transport counter to indicate = failure at that layer was detected by iscsiInstance. Editors: If connection timeout errors are seen, wouldn't the user check tra= nsport connectivity via ping and other tools? We are not sure that adding = more objects here would add enough value. Consider separate counters for HB vs data timeouts. Consider specific heartbeat no-op timeout error countes. Editors: We will start another thread for this discussion. It does seem us= eful since most implementations use NOP for keep-alive heartbeats. | +--iscsiPortal(2) | | | | | +--iscsiPortalAttributesTable(1) | | | | | +--iscsiPortalAttributesEntry(1) [iscsiInstIndex,iscsiPortalInde= x] | | | | | +-- --- Unsigned32 iscsiPortalIndex(1) | | +-- rwn RowStatus iscsiPortalRowStatus(2) | | +-- rwn Bits iscsiPortalRoles(3) | | +-- rwn InetAddressType iscsiPortalAddrType(4) | | +-- rwn InetAddress iscsiPortalAddr(5) | | +-- rwn IscsiTransportProtocol iscsiPortalProtocol(6) | | +-- rwn Unsigned32 iscsiPortalMaxRecvDataSegLengt= h(7) | | +-- rwn IscsiDigestMethod iscsiPortalPrimaryHdrDigest(8) | | +-- rwn IscsiDigestMethod iscsiPortalPrimaryDataDigest(9= ) | | +-- rwn IscsiDigestMethod iscsiPortalSecondaryHdrDigest(= 10) | | +-- rwn IscsiDigestMethod iscsiPortalSecondaryDataDigest= (11) | | +-- rwn TruthValue iscsiPortalRecvMarker(12) | | +-- rwn StorageType iscsiPortalStorageType(13) Digests are negotiated and implementations may have additional levels (tert= iary, quaternary) as well as constraints that are not modelled here. Editors: There's only one standardized digest method currently in use (CRC3= 2C) that we know of. Are there implementations that extend this beyond two= ? Digests can also be configured in iscsiNodeAttributesTable. (Is there a pre= cecence between node and portal?) Editors: There is no digests field currently in NodeAttributesTable, so Por= tal is the only place to configure it. Need to be able to set/show port number as well as iscsiPortalAddr. Editors: We can add this one. Regarding iscsiCxnRecvMarker, iscsiCxnSendMarker these are to be deprecate= d and are redundant in session and connection. Editors: These will be removed. The V2 object groups in the draft do not c= ontain the deprecated objects. ** note: I Checked with INET-ADDRESS-MIB about iscsiPortalAddrType, if set = to 16 dns(16) A DNS domain name as defined by the InetAddressDNS textual convention. Then iscsiPortalAddr can be a dns hostname. Appears the MIB Portal Attributes and Node Atributes are sort os a mish-mash or Node, Lhba, Phba, various Portal properties. Editors: Not sure we understand this one - the MIB follows iSCSI node and = portal definitions for portals and nodes. HBAs are outside the scope of th= e MIB and of iSCSI. Using a table rather than Primary and Secondary would be the right approach for Header and Data digests, since the whole point of these negotiations is to provide a list of what each side is willing to settle on. Editors: Technically, yes, but practically it seems over-complicated. Additionally, a list for authentication negotiation would be useful, also. There are five different authentication methods defined by the original RFC 3720, and a few additional ones that have since sprung up. Editors: Isn't the list of authorized entities sufficient, since the method= s are included by reference?] There's also the idea of mutual authentication, where each side verfies the identity of the other, rathern than just a target authenticatiing a host. Editors: Is this comment referring to the iscsiSsnAuthIdentity? We do see = that this is just one per session, and we didn't identify it as an initiato= r or target identity (most people likely assumed initiator). We'd need to change this name to iscsiSsnAuthIntrIdentity and add iscsiSsnA= uthTgtIdentity to show both identities in a session where this is used. Additional useful information at the Portal level might be at least some identification of what type of initiator it is, and some identifying information about it. Maybe not the level of detail you'll find in IMA_PHBA_PROPERTIES, but the model, description and version. Editors: this seems useful for troubleshooting. We can add something simil= ar to iscsiInstDescr: iscsiPortalDescr OBJECT-TYPE SYNTAX SnmpAdminString MAX-ACCESS read-only STATUS current DESCRIPTION "A UTF-8 string, determined by the implementation to describe the iSCSI portal. When only a single instance is present, this object may be set to the zero-length string; with multiple iSCSI portals, it may be used in an implementation-dependent manner to describe the respective portal, and could include information such as HBA model, description and version or software driver and version." I don't think that we'd want to try to structure it more than just a string= . | +--iscsiNode(5) | | | | | +--iscsiNodeAttributesTable(1) | | | | | +--iscsiNodeAttributesEntry(1) [iscsiInstIndex,iscsiNodeIndex] | | | | | +-- --- Unsigned32 iscsiNodeIndex(1) | | +-- r-n IscsiName iscsiNodeName(2) | | +-- r-n SnmpAdminString iscsiNodeAlias(3) | | +-- r-n Bits iscsiNodeRoles(4) | | +-- r-n RowPointer iscsiNodeTransportType(5) | | +-- r-n TruthValue iscsiNodeInitialR2T(6) | | +-- rwn TruthValue iscsiNodeImmediateData(7) | | +-- rwn Unsigned32 iscsiNodeMaxOutstandingR2T(8) | | +-- rwn Unsigned32 iscsiNodeFirstBurstLength(9) | | +-- rwn Unsigned32 iscsiNodeMaxBurstLength(10) | | +-- rwn Unsigned32 iscsiNodeMaxConnections(11) | | +-- rwn TruthValue iscsiNodeDataSequenceInOrder(12) | | +-- rwn TruthValue iscsiNodeDataPDUInOrder(13) | | +-- rwn Unsigned32 iscsiNodeDefaultTime2Wait(14) | | +-- rwn Unsigned32 iscsiNodeDefaultTime2Retain(15) | | +-- rwn Unsigned32 iscsiNodeErrorRecoveryLevel(16) | | +-- r-n TimeStamp iscsiNodeDiscontinuityTime(17) | | +-- rwn StorageType iscsiNodeStorageType(18) Digests as found in scsiPortalAttributesTable, may be provisioned at this l= evel. Editors: Is there a need to provision digest at this level via the MIB modu= le? | +--iscsiInitiator(8) | | | | | +--iscsiInitiatorAttributesTable(1) | | | | | | | +--iscsiInitiatorAttributesEntry(1) [iscsiInstIndex,iscsiNodeInd= ex] | | | | | | | +-- r-n Counter32 iscsiIntrLoginFailures(1) | | | +-- r-n TimeStamp iscsiIntrLastFailureTime(2) | | | +-- r-n AutonomousType iscsiIntrLastFailureType(3) | | | +-- r-n IscsiName iscsiIntrLastTgtFailureName(4) | | | +-- r-n InetAddressType iscsiIntrLastTgtFailureAddrType(5) | | | +-- r-n InetAddress iscsiIntrLastTgtFailureAddr(6) No port number provided. Editors: We will add iscsiIntrLastTgtFailurePort | | +--iscsiInitiatorLoginStatsTable(2) | | | | | | | +--iscsiInitiatorLoginStatsEntry(1) [iscsiInstIndex,iscsiNodeInd= ex] | | | | | | | +-- r-n Counter32 iscsiIntrLoginAcceptRsps(1) | | | +-- r-n Counter32 iscsiIntrLoginOtherFailRsps(2) | | | +-- r-n Counter32 iscsiIntrLoginRedirectRsps(3) | | | +-- r-n Counter32 iscsiIntrLoginAuthFailRsps(4) | | | +-- r-n Counter32 iscsiIntrLoginAuthenticateFails(5) | | | +-- r-n Counter32 iscsiIntrLoginNegotiateFails(6) No way to get to transport layer (tcp, etc) related errors not shown here o= r provided through RowPointer/etc. Editors: We are not sure that this will add enough value. | | +--iscsiInitiatorLogoutStatsTable(3) | | | | | +--iscsiInitiatorLogoutStatsEntry(1) [iscsiInstIndex,iscsiNodeIn= dex] | | | | | +-- r-n Counter32 iscsiIntrLogoutNormals(1) | | +-- r-n Counter32 iscsiIntrLogoutOthers(2) The counter iscsiIntrLogoutOthers does not cover cases where no ack is retu= rned (timeout case) due to failure of transport to deliver logout ack. Editors: Adding a timeout counter for this seems to make sense. | +--iscsiIntrAuthorization(9) | | | | | +--iscsiIntrAuthAttributesTable(1) | | | | | +--iscsiIntrAuthAttributesEntry(1) [iscsiInstIndex,iscsiNodeInde= x,iscsiIntrAuthIndex] | | | | | +-- --- Unsigned32 iscsiIntrAuthIndex(1) | | +-- rwn RowStatus iscsiIntrAuthRowStatus(2) | | +-- rwn RowPointer iscsiIntrAuthIdentity(3) | | +-- rwn StorageType iscsiIntrAuthStorageType(4) The reference for iscsiIntrAuthIdentity is too vague. Only provides the RFC= ?: REFERENCE "IPS-AUTH MIB, RFC 4545" Editors: We will fix this. | +--iscsiSession(10) | | | | | +--iscsiSessionAttributesTable(1) | | | | | | | +--iscsiSessionAttributesEntry(1) [iscsiInstIndex,iscsiSsnNodeIn= dex,iscsiSsnIndex] | | | | | | | +-- --- Unsigned32 iscsiSsnNodeIndex(1) | | | +-- --- Unsigned32 iscsiSsnIndex(2) | | | +-- r-n Enumeration iscsiSsnDirection(3) | | | +-- r-n IscsiName iscsiSsnInitiatorName(4) | | | +-- r-n IscsiName iscsiSsnTargetName(5) | | | +-- r-n Unsigned32 iscsiSsnTSIH(6) | | | +-- r-n OctetString iscsiSsnISID(7) | | | +-- r-n SnmpAdminString iscsiSsnInitiatorAlias(8) | | | +-- r-n SnmpAdminString iscsiSsnTargetAlias(9) | | | +-- r-n TruthValue iscsiSsnInitialR2T(10) | | | +-- r-n TruthValue iscsiSsnImmediateData(11) | | | +-- r-n Enumeration iscsiSsnType(12) | | | +-- r-n Unsigned32 iscsiSsnMaxOutstandingR2T(13) | | | +-- r-n Unsigned32 iscsiSsnFirstBurstLength(14) | | | +-- r-n Unsigned32 iscsiSsnMaxBurstLength(15) | | | +-- r-n Gauge32 iscsiSsnConnectionNumber(16) | | | +-- r-n RowPointer iscsiSsnAuthIdentity(17) | | | +-- r-n TruthValue iscsiSsnDataSequenceInOrder(18) | | | +-- r-n TruthValue iscsiSsnDataPDUInOrder(19) | | | +-- r-n Unsigned32 iscsiSsnErrorRecoveryLevel(20) | | | +-- r-n TimeStamp iscsiSsnDiscontinuityTime(21) Consider reporting the digest negotiated for this session. Consider reporting the error-recovery-level (ERL). Consider reporting type(?) negotiated. | | +--iscsiSessionStatsTable(2) | | | | | | | +--iscsiSessionStatsEntry(1) [iscsiInstIndex,iscsiSsnNodeIndex,i= scsiSsnIndex] | | | | | | | +-- r-n Counter32 iscsiSsnCmdPDUs(1) | | | +-- r-n Counter32 iscsiSsnRspPDUs(2) | | | +-- r-n Counter64 iscsiSsnTxDataOctets(3) | | | +-- r-n Counter64 iscsiSsnRxDataOctets(4) | | | +-- r-n Counter32 iscsiSsnLCTxDataOctets(5) | | | +-- r-n Counter32 iscsiSsnLCRxDataOctets(6) Consider reporting missing PDU. Break down counters for data pdus in and out. Add counter for async pdus in. Editors: The above seem like good ideas - will anyone use these? Also, bre= aking down the existing counters might break current implementations. We w= ould likely have to create new ones. | | +--iscsiSessionCxnErrorStatsTable(3) | | | | | +--iscsiSessionCxnErrorStatsEntry(1) [iscsiInstIndex,iscsiSsnNod= eIndex,iscsiSsnIndex] | | | | | +-- r-n Counter32 iscsiSsnCxnDigestErrors(1) | | +-- r-n Counter32 iscsiSsnCxnTimeoutErrors(2) Description should discuss when these counters are most likely provided suc= h as when the error-recovery-level is 1 or 2. Editors: We will update the descriptions. | +--iscsiConnection(11) | | | +--iscsiConnectionAttributesTable(1) | | | +--iscsiConnectionAttributesEntry(1) [iscsiInstIndex,iscsiSsnNod= eIndex,iscsiSsnIndex,iscsiCxnIndex] | | | +-- --- Unsigned32 iscsiCxnIndex(1) | +-- r-n Unsigned32 iscsiCxnCid(2) | +-- r-n Enumeration iscsiCxnState(3) | +-- r-n InetAddressType iscsiCxnAddrType(4) | +-- r-n InetAddress iscsiCxnLocalAddr(5) | +-- r-n IscsiTransportProtocol iscsiCxnProtocol(6) | +-- r-n InetPortNumber iscsiCxnLocalPort(7) | +-- r-n InetAddress iscsiCxnRemoteAddr(8) | +-- r-n InetPortNumber iscsiCxnRemotePort(9) | +-- r-n Unsigned32 iscsiCxnMaxRecvDataSegLength(1= 0) | +-- r-n Unsigned32 iscsiCxnMaxXmitDataSegLength(1= 1) | +-- r-n IscsiDigestMethod iscsiCxnHeaderIntegrity(12) | +-- r-n IscsiDigestMethod iscsiCxnDataIntegrity(13) | +-- r-n TruthValue iscsiCxnRecvMarker(14) | +-- r-n TruthValue iscsiCxnSendMarker(15) | +-- r-n Unsigned32 iscsiCxnVersionActive(16) Consider adding initial remote ip addr and port to this table. Editors: Not sure what the value in initial remote IP addr and port would = be - if they change wouldn't this be a new connection? | +--iscsiTarget(6) | | | | | +--iscsiTargetAttributesTable(1) | | | | | | | +--iscsiTargetAttributesEntry(1) [iscsiInstIndex,iscsiNodeIndex] | | | | | | | +-- r-n Counter32 iscsiTgtLoginFailures(1) | | | +-- r-n TimeStamp iscsiTgtLastFailureTime(2) | | | +-- r-n AutonomousType iscsiTgtLastFailureType(3) | | | +-- r-n IscsiName iscsiTgtLastIntrFailureName(4) | | | +-- r-n InetAddressType iscsiTgtLastIntrFailureAddrType(5) | | | +-- r-n InetAddress iscsiTgtLastIntrFailureAddr(6) | | +--iscsiTargetLoginStatsTable(2) | | | | | | | +--iscsiTargetLoginStatsEntry(1) [iscsiInstIndex,iscsiNodeIndex] | | | | | | | +-- r-n Counter32 iscsiTgtLoginAccepts(1) | | | +-- r-n Counter32 iscsiTgtLoginOtherFails(2) | | | +-- r-n Counter32 iscsiTgtLoginRedirects(3) | | | +-- r-n Counter32 iscsiTgtLoginAuthorizeFails(4) | | | +-- r-n Counter32 iscsiTgtLoginAuthenticateFails(5) | | | +-- r-n Counter32 iscsiTgtLoginNegotiateFails(6) | | +--iscsiTargetLogoutStatsTable(3) | | | | | +--iscsiTargetLogoutStatsEntry(1) [iscsiInstIndex,iscsiNodeIndex= ] | | | | | +-- r-n Counter32 iscsiTgtLogoutNormals(1) | | +-- r-n Counter32 iscsiTgtLogoutOthers(2) | +--iscsiTgtAuthorization(7) | | | | | +--iscsiTgtAuthAttributesTable(1) | | | | | +--iscsiTgtAuthAttributesEntry(1) [iscsiInstIndex,iscsiNodeIndex= ,iscsiTgtAuthIndex] | | | | | +-- --- Unsigned32 iscsiTgtAuthIndex(1) | | +-- rwn RowStatus iscsiTgtAuthRowStatus(2) | | +-- rwn RowPointer iscsiTgtAuthIdentity(3) | | +-- rwn StorageType iscsiTgtAuthStorageType(4) Additional Comments: There's no information in any of this regarding iSCSI discovery information. That would be potentially useful information, especially in the case of discovered targets that have no sessions. That could be an indication of a network problem of a mis-configuration. The type of discovery performed and the discovered targets could be put in there and provide this information. Editors: This MIB module currently represents only the initiators and targe= ts provided by the entity being queried. The remote objects do not appear = here and are part of someone else's entity. So if you had a target-only de= vice, it wouldn't have objects for the initiators connecting to it and vise= -versa. Since we don't currently support remote objects, adding this capability wou= ld be a significant new MIB development by the WG, rather than a fix given = the current review. End of File. --_000_975552A94CBC0F4DA60ED7B36C949CBA03F17813D9shandyBeerTow_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

=  

Everyone,

 

We are in the p= rocess of updating the iSCSI MIB module, to match the latest storm changes.=   Mike MacFaden has also done a MIB Doctor review, which brought back = a number of comments on things that are potentially missing from the origin= al iSCSI MIB RFC.

 

<= p class=3DMsoNormal>Prakash, David, Tom and I have been reviewing the MIB d= octor requests.  This message is intended to answer some of the MIB do= ctor comments as well as generate discussion on the list about possible cha= nges.  We intend to post another draft (-02) before the July 16th= deadline for the next round of discussion.

 

Here is a brief summary= .  The full responses to comments are below.

·  &n= bsp;      Several e= ditorial changes

·        = ; A few new fields are added to objects that= are either useful or were missed the first time around

· &n= bsp;       Mor= e complex additions that we believe will need a separate revision and may a= ffect the object model.  The latter changes would require support from= those intending to implement or use them.

 

I will start separate discussi= on threads on a few items:

·      =    Heartbeat counters for NOP-In a= nd NOP-Out usage

·        = ; TCP MIB correlation for sessions and conne= ctions

·         <= /span>iscsiInstanceSsnErrorStatsTable session details=

 

Fo= r reference, we have:

·       = ;  The previous draft of the new iSCSI = MIB - h= ttp://www.ietf.org/id/draft-ietf-storm-iscsimib-01.txt

· = ;        = The initial MIB doctor review - http://www.macfaden.com/ietf/iscsi-mib-1-reviewed.tx= t

·         An additional MIB doctor review with VMware engineers= - http://macfaden= .com/ietf/iscsi-mib-notes.txt

&= nbsp;

Detailed responses to MIB doctor review= :

 

February 17, 2012 MIB DOCTOR Review: http://www.= ietf.org/id/draft-ietf-storm-iscsimib-01.txt 

 

Performed by Micha= el R. MacFaden, VMware, Inc

According to http://tools.ietf.org/html/rfc4181

 

This review only covers= syntax, SMIv2 rules usage of the MIB module itself, not the draft.

Some of th= e things mentioned below exist the prior version of the mib, not this updat= e.

=  

1 boiler plate - check

2. Narrative Sections - check

=

3. Security Consideratio= ns - check

4. IANA Considerations - missing editors’ note.

  &nb= sp;Section 9 needs the following verbiage to be added.

    = ;   Editor's Note (to be removed prior to publication):  thi= s draft

      makes no additional requests of the IAN= A.

 

Editors: We will fix this.

 

5. No new namespaces

6. References sec= tion - check

7. copyright notice - check

8. Intellectual Property section –= missing

 

Editors: We will add the section:

 =

        &n= bsp;   Copyright (c) 2011 IETF Trust and the persons identified a= s

=             authors = of the code.  All rights reserved.<= o:p>

 = ;

      = ;      Redistribution and use in source and binary= forms, with or

          &= nbsp; without modification, is permitted pursuant to, and subject

  = ;          to the license term= s contained in, the Simplified BSD<= /o:p>

       =      License set forth in Section 4.c of the IETF Trust= 's Legal

           = Provisions Relating to IETF Documents

      &n= bsp;     (http://trustee.ietf.org/license-info)."

<= b> 

 

9. This change updates existing= mib rfc http://www.ietf.or= g/rfc/rfc4544.txt - check

   Backward compatibility checks: (oid= s, object-identities, remained the same)

 

Other items checked --

syntax check= : smilint -l9 - no errors

smicng : not run

spelling: Aspell --- no misspellings f= ound.

URLs validated: checked for valid, not-broken links:

   &nbs= p;         http://www.iana.org/assignments/protoc= ol-numbers

 

References in MIB module  not found in normative (sec = 10.1)

IscsiTransportProtocol TC ->  "RFC791, RFC1700

 

 =

Edit= ors: We will fix this.

 

 

enumerations: each element described <= /o:p>

 &n= bsp;- IscsiDigestMethod

 

Editors: We had this in the description –= is there something else that needs to be added?

<= p class=3DMsoNormal> <= /p>

DiscontinuityTime is = syntax: TimeStamp

All Counters: define their discontinuity timestamp.

 =

Edit= ors: We checked the descriptions in each of the Counter32 and Counter64 fie= lds, and they all reference a discontinuity timestamp.  Isn’t th= at enough?

 

Uncommon stuff:

<= span style=3D'color:#1F497D'>1)  In IscsiPortalAttributesEntry has Row= Status as second item in the conceptual row,

not after iscsiPortalStorageType= .

<= o:p> 

Editors: We currently don’t put StorageType and RowStatus toget= her in any of our objects, and didn’t originally realize there was so= me tradition around this.  Changing numbering now would cause backward= compatibility problems, so we cannot make this change.

 <= /span>

2) iscsiPortal= Roles does not have a DEFVAL when most others do in this conceptual table.<= o:p>

isc= siPortalAddrType has def val of IPV4? when the iscsiPortalAddr has no defau= lt to go with it?

 

Editors:&= nbsp; There isn’t a reasonable DEFVAL for iscsiPortalRoles.  It = has to be set when creating the row, so we will leave this one.<= /b>

 = ;

3) isc= siNodeAttributesEntry  sez:

=    An entry (row) containing mana

&nbs= p;  vs 'conceptual row' which is used inconsistently.

 <= /span>

Editors: We= will change this description from:

 

An entry (row) containing management infor= mation applicable
        to a particular iSCSI node=
.

 

To

 

A conceptual row containing management information appli=
cable
 =
       to a particular iSCSI node.=

&n= bsp;

 

4)  (e.g. not created via this MIB).  vs MIB module. There is bu= t one MIB as Dr Case would say.

<= span style=3D'color:#1F497D'> 

Editors: We will fix this one.

&n= bsp;

5) = 64 bit counters with SNMPv1 support for 32 bit high/low? kinda

  iscsiSsn= TxDataOctets, iscsiSsnRxDataOctets, provides only low word: iscsiSsnLCTxDat= aOctets, iscsiSsnLCRxDataOctets

<= span style=3D'color:#1F497D'>  Compliance phrasing is a bit odd: =

 &= nbsp; "A Low Capacity shadow object of iscsiSsnTxDataOctets<= /o:p>

 &n= bsp;      for those systems that don't support Cou= nter64.

    instead of 'for those systems which are accessible = via SNMPv1 only'

 

Editors:  We will fix the wording for SNMPv1.&nbs= p; We don’t see a reason to add objects for high octets.

 =

6) Noti= fications are required to have a rate limited implementation by a descripti= on,

   yet the number of times the failure occurred  = ; is not conveyed in the notifcation varbind list.

    iscsiTgt= LoginFailure, iscsiIntrLoginFailure, iscsiInstSessionFailure

 =

  &= nbsp; To avoid sending an excessive number of notifications due<= /span>

  &n= bsp;     to multiple errors counted, an SNMP agent impl= ementing this

        notification SHOULD N= OT send more than 3 notifications of

       = ; this type in any 10-second time period."

 

Editors:  We belie= ve that this is covered by the counter “iscsiTgtLoginFailures”:=

 

iscsiTgtLogi=
nFailure NOTIFICATION-TYPE
    OBJECTS {
        iscsiTgtLoginF=
ailures,
 &nbs=
p;      iscsiTgtLastFailureType,=

      =
  iscsiTgtLastIntrFailureName,
        iscsiTgtLastInt=
rFailureAddrType,
&=
nbsp;       iscsiTgtLastIntrFailureAddr<=
/o:p>
    }

 

=  

The following section addresses comments from the VMware iSCSI-MIB revi= ew:

 

 

Notes from VMware ISCIS-M= IB review meeting

March 21, 2012=

Attendees: Andy Banta, Kun Huang, Mike Ma= cFaden

 

1. M= any objects lacking REFERENCE clause or offer only vague references.

For those managed objects having a Referenc= e clause, nedd to fix up 'RFC cccc'

F= or example: "RFC cccc, Section 7.5, Connection Timeout Management"= ;

Example of vague reference:

    REFERENCE

        "SCS= I-MIB"

 <= /p>

 

Edito= rs: OK, we can update in the next draft.

 

 

2. Descriptions are short and simple but in some ca= se seem a bit too short

for an IETF s= tandard mib module.

 

 

Editors: We can look for opportunities to clarify but donR= 17;t think we want to go through and rewrite a lot.  If there are part= icular descriptions that cause confusion please bring them up.

 

 

Here's the comments b= y object in the MIB module: draft-ietf-storm-iscsimib-01.txt

 

iscsiM= ibModule(1.3.6.1.2.1.142)

  |

  +--iscsiNotifications(0)

  |  |

  |  +--iscsiTgtLoginFailure(1) [iscsiTgtLoginFailures= ,iscsiTgtLastFailureType,iscsiTgtLastIntrFailureName,iscsiTgtLastIntrFailur= eAddrType,iscsiTgtLastIntrFailureAddr]

Consider adding port number.=

 

 

Editors: = LastFailurePortNumber would be easy enough to add.  Should we do an Or= Zero for implementations that can’t get the port number?

 

=  

  |  +--iscsiI= ntrLoginFailure(2) [iscsiIntrLoginFailures,iscsiIntrLastFailureType,iscsiIn= trLastTgtFailureName,iscsiIntrLastTgtFailureAddrType,iscsiIntrLastTgtFailur= eAddr]

 

<= p class=3DMsoNormal>Can't determine if the failure is due to failure of the und= erlying transport or not.

When transp= ort is TCP there should be some way to get to the TCP-MIB/TCP-ESTATS-MIB di= agnostics.

See notes on iscsiInstance= SsnErrorStatsTable.

 

Consider adding port number. 

 

<= o:p> 

Editors: Same as above.&nb= sp; On the failure, is it useful to have both local and remote addr and por= t number?  Will the TCP MIB keep these connections around long enough = to go index it on a failed connection?  If we add these fields, will s= omeone use them?

 

 

  |  +--iscsiInstSessionFailure(3) [iscsiInstSsnFailures,is= csiInstLastSsnFailureType,iscsiInstLastSsnRmtNodeName]

 

 <= /o:p>

Consider handling the event "Target U= nmapped"  by updatingiscsiInstLastSsnFailureType of a Session fai= lure, as well.

 

 

Editors: FailureType is an OID pointing to a stat in iscsiInstSsnError= StatsTable, so we would need to add to this:

&nbs= p;   iscsiInstSsnTgtUnmappedErrors     &= nbsp; Counter32

 <= /o:p>

Are there others that would be ne= eded?

 =

 

<= span style=3D'font-size:10.0pt;font-family:"Courier New";color:black'>Consi= der adding summary notification in the case of larger scales (number of tar= gets)

what about large scales, # of = targets, each target have a failure of similar sort.

<= p class=3DMsoNormal> 

 

Editors: Would such a notification real= ly be used?  If there was a large scale failure of many targets, we be= lieve the administrator would see enough of the notifications to notice it = as a larger problem.

&nbs= p;

 

<snip>

 

  |  |  +--iscsiInstanceSsnEr= rorStatsTable(2)

  |  |&nbs= p;    |

  | = |     +--iscsiInstanceSsnErrorStatsEntry(1) [iscsiInst= Index]

  |  |  &n= bsp;     |

 = |  |        +-- r-n Counter32 iscs= iInstSsnDigestErrors(1)

  | = ; |        +-- r-n Counter32 iscsiInstSs= nCxnTimeoutErrors(2)

  |  = |        +-- r-n Counter32 iscsiInstSsnF= ormatErrors(3)

 

Related states for transport are not provided in thi= s table. Either a RowPointer

to anoth= er mib module is needed or a generic transport counter to indicate failure<= o:p>

at that layer was detected by iscsiIn= stance.

 

<= p class=3DMsoNormal> 

<= b>= Editors: If connection timeout errors are seen, wouldn’t the user che= ck transport connectivity via ping and other tools?  We are not sure t= hat adding more objects here would add enough value.<= /p>

 

<= o:p> 

Consider separate counters for = HB vs data timeouts.

Consider specif= ic heartbeat no-op timeout error countes.

 

 

Editors: We will start another thread for= this discussion.  It does seem useful since most implementations use = NOP for keep-alive heartbeats.

 

 

  |  +--iscsiPortal(2)

  |  |  |

  |  |  +--iscsiPortalAttributesTable(1)

  |  |     |

  |  |     +--= iscsiPortalAttributesEntry(1) [iscsiInstIndex,iscsiPortalIndex]<= /span>

  |  |     &n= bsp;  |

  |  | &n= bsp;      +-- --- Unsigned32   &nbs= p;         iscsiPortalIndex(1)=

  |  |    &= nbsp;   +-- rwn RowStatus       &nb= sp;      iscsiPortalRowStatus(2)

  |  |     &nb= sp;  +-- rwn Bits         = ;          iscsiPortalRoles(3)=

  |  |   &n= bsp;    +-- rwn InetAddressType     = ;   iscsiPortalAddrType(4)

=   |  |        +-- rwn InetAddr= ess            iscsi= PortalAddr(5)

  |  | &= nbsp;      +-- rwn IscsiTransportProtocol iscsiPor= talProtocol(6)

  |  | =        +-- rwn Unsigned32   &n= bsp;         iscsiPortalMaxRecvData= SegLength(7)

  |  | &n= bsp;      +-- rwn IscsiDigestMethod  &nb= sp;   iscsiPortalPrimaryHdrDigest(8)

  |  |        +-- rw= n IscsiDigestMethod      iscsiPortalPrimaryDataDig= est(9)

  |  |  &n= bsp;     +-- rwn IscsiDigestMethod   &nb= sp;  iscsiPortalSecondaryHdrDigest(10)

  |  |        +-- rwn= IscsiDigestMethod      iscsiPortalSecondaryDataDi= gest(11)

  |  |  =       +-- rwn TruthValue    &n= bsp;        iscsiPortalRecvMarker(12)

  |  |    = ;    +-- rwn StorageType      =       iscsiPortalStorageType(13)=

 

Digests a= re negotiated and implementations may have additional levels (tertiary, qua= ternary)

as well as constraints that = are not modelled here.

 

 

Editors: There’s only one standardized digest method = currently in use (CRC32C) that we know of.  Are there implementations = that extend this beyond two?

=  

 <= /p>

Digests can also be configured in iscsiNodeAttributesTa= ble. (Is there a prececence between node and portal?)

=

 

 = ;

Editors: There is no digests fi= eld currently in NodeAttributesTable, so Portal is the only place to config= ure it.

 

 

Nee= d to be able to set/show port number as well as iscsiPortalAddr.=

 

 

Editors: We can add this on= e.

 

 

Regardin= g iscsiCxnRecvMarker, iscsiCxnSendMarker these are to be  deprecated a= nd are redundant in session and connection.

 

 

Editors: These will be removed.  The V2 o= bject groups in the draft do not contain the deprecated objects.=

       &= nbsp;           &nbs= p;

 

** note: I Checked with INET-ADDRESS-MIB about iscsiPortalAddrT= ype, if set to 16

   &= nbsp;  dns(16)     A DNS domain name as defined by= the

     &n= bsp;  InetAddressDNS textual convention.

      Then iscsiPortalAddr can be a dns h= ostname.

 

=

Appears the MIB Portal Attributes and Node Atributes are s= ort os a

mish-mash or Node, Lhba, Phb= a, various Portal properties.

&n= bsp;

 

Editors:  Not sure we understand this one – the MI= B follows iSCSI node and portal definitions for portals and nodes.  HB= As are outside the scope of the MIB and of iSCSI.

=

 

&= nbsp;

Using a table rather than Primary an= d Secondary would be the right

approa= ch for Header and Data digests, since the whole point of these

negotiations is to provide a list of what each si= de is willing to

settle on.

 

<= o:p> 

Editors: Technically, yes,= but practically it seems over-complicated.

 

 

Additionally, a list for authentication negotiati= on would be useful,

also.  The= re are five different authentication methods defined by the

original RFC 3720, and a few additional ones that ha= ve since sprung

up.=

 

&nbs= p;

Editors: Isn’t the list of a= uthorized entities sufficient, since the methods are included by reference?= ]

 

 

There's also th= e idea of mutual authentication, where each side

verfies the identity of the other, rathern than just a target

authenticatiing a host.

 

&= nbsp;

Editors: Is this comment referr= ing to the iscsiSsnAuthIdentity?  We do see that this is just one per = session, and we didn’t identify it as an initiator or target identity= (most people likely assumed initiator).

 

We̵= 7;d need to change this name to iscsiSsnAuthIntrIdentity and add iscsiSsnAu= thTgtIdentity to show both identities in a session where this is used.=

 

 

Addition= al useful information at the Portal level might be at least

some identification of what type of initiator it is,= and some

identifying information abo= ut it. Maybe not the level of detail you'll

find in IMA_PHBA_PROPERTIES, but the model, description and versio= n.

 

Editors: this seems useful for troubleshooting.  We ca= n add something similar to iscsiInstDescr:

 

iscsiP= ortalDescr OBJECT-TYPE

 = ;   SYNTAX        SnmpAdminStr= ing

    MAX-A= CCESS    read-only

    STATUS        c= urrent

    DE= SCRIPTION

   =      "A UTF-8 string, determined by the implementa= tion to

   &n= bsp;    describe the iSCSI portal.  When only a single = instance

   &= nbsp;    is present, this object may be set to the zero-leng= th

    &= nbsp;   string; with multiple iSCSI portals, it may be used in

     =    an implementation-dependent manner to describe the =

      &n= bsp; respective portal, and could include information such as

       = ; HBA model, description and version or software driver and

        = version."

 

I don’t think that we’= d want to try to structure it more than just a string.

 

<= o:p> 

<snip><= /p>

 

 &nb= sp;|  +--iscsiNode(5)

  |&n= bsp; |  |

  |  | = +--iscsiNodeAttributesTable(1)

<= span style=3D'font-size:10.0pt;font-family:"Courier New";color:black'> = ; |  |     |

  |  |     +--iscsiNodeAttributesEntry(1) [i= scsiInstIndex,iscsiNodeIndex]

  = |  |        |

=

  |  |       = +-- --- Unsigned32      iscsiNodeIndex(1)

  |  |    &nbs= p;   +-- r-n IscsiName       iscsiN= odeName(2)

  |  | &nbs= p;      +-- r-n SnmpAdminString iscsiNodeAlias(3)<= o:p>

  |  |   &nb= sp;    +-- r-n Bits       = ;     iscsiNodeRoles(4)

  |  |        +-- r-n= RowPointer      iscsiNodeTransportType(5)

  |  |    &nbs= p;   +-- r-n TruthValue      iscsiNodeIn= itialR2T(6)

  |  | &nb= sp;      +-- rwn TruthValue    = ;  iscsiNodeImmediateData(7)

&nb= sp; |  |        +-- rwn Unsigned32&= nbsp;     iscsiNodeMaxOutstandingR2T(8)

  |  |      =   +-- rwn Unsigned32      iscsiNodeFirstBurst= Length(9)

  |  |  = ;      +-- rwn Unsigned32    &= nbsp; iscsiNodeMaxBurstLength(10)

&nb= sp; |  |        +-- rwn Unsigned32&= nbsp;     iscsiNodeMaxConnections(11)=

  |  |      &n= bsp; +-- rwn TruthValue      iscsiNodeDataSequence= InOrder(12)

  |  | &nb= sp;      +-- rwn TruthValue    = ;  iscsiNodeDataPDUInOrder(13)

&= nbsp; |  |        +-- rwn Unsigned3= 2      iscsiNodeDefaultTime2Wait(14)

  |  |     &nbs= p;  +-- rwn Unsigned32      iscsiNodeDefaultT= ime2Retain(15)

  |  | =        +-- rwn Unsigned32   &n= bsp;  iscsiNodeErrorRecoveryLevel(16)

  |  |        +-- r-n Ti= meStamp       iscsiNodeDiscontinuityTime(17)<= o:p>

  |  |   &nb= sp;    +-- rwn StorageType     iscsiNode= StorageType(18)

 

Digests as found in scsiPortalAttributesTable, may = be provisioned at this level.

&n= bsp;

 

Editors: Is there a need to provision digest at this level vi= a the MIB module?

 

 

  |  +--iscsiInitiator(8)

  |  |  |

  = |  |  +--iscsiInitiatorAttributesTable(1)

  |  |  |  +--iscsiInitiatorAttributesEntry(= 1) [iscsiInstIndex,iscsiNodeIndex]

&n= bsp; |  |  |     |

  |  |  |     +-- r-n Counte= r32       iscsiIntrLoginFailures(1)

  |  |  |   &nbs= p; +-- r-n TimeStamp       iscsiIntrLastFailu= reTime(2)

  |  |  |&nb= sp;    +-- r-n AutonomousType  iscsiIntrLastFailureType= (3)

  |  |  | &nb= sp;   +-- r-n IscsiName       iscsi= IntrLastTgtFailureName(4)

  |&nb= sp; |  |     +-- r-n InetAddressType iscsiIntrLast= TgtFailureAddrType(5)

  |  = |  |     +-- r-n InetAddress   &nbs= p; iscsiIntrLastTgtFailureAddr(6)

 

No port number provided.

 

=  

Editors: We will add iscs= iIntrLastTgtFailurePort

&nbs= p;

 

  |  |  +--iscsiInitiatorLoginStatsTable(2)=

  |  |  |  |

  |  |  |  +--iscsiInitiatorLog= inStatsEntry(1) [iscsiInstIndex,iscsiNodeIndex]

  |  |  |     |

  |  |  |     += -- r-n Counter32 iscsiIntrLoginAcceptRsps(1)

  |  |  |     +-- r-n Counter32= iscsiIntrLoginOtherFailRsps(2)

<= span style=3D'font-size:10.0pt;font-family:"Courier New";color:black'> = ; |  |  |     +-- r-n Counter32 iscsiIntrLogi= nRedirectRsps(3)

  |  |&nbs= p; |     +-- r-n Counter32 iscsiIntrLoginAuthFailRsps(4= )

  |  |  |  = ;   +-- r-n Counter32 iscsiIntrLoginAuthenticateFails(5)

  |  |  |   &nb= sp; +-- r-n Counter32 iscsiIntrLoginNegotiateFails(6)

=

 

No way to get= to transport layer (tcp, etc) related errors not shown here or provided th= rough RowPointer/etc.

 

 

Editors: We are not sure that this will add enough value.

 

=  

  |  |  +--iscs= iInitiatorLogoutStatsTable(3)

  = |  |     |

&= nbsp; |  |     +--iscsiInitiatorLogoutStatsEntry(1= ) [iscsiInstIndex,iscsiNodeIndex]

&nb= sp; |  |        |=

  |  |      &n= bsp; +-- r-n Counter32 iscsiIntrLogoutNormals(1)

  |  |        +-- = r-n Counter32 iscsiIntrLogoutOthers(2)

The counter iscsiIntrLogoutO= thers does not cover cases where no ack is returned (timeout case) due=

to failure of transport to deliver logout= ack.

 

 

Editors: Ad= ding a timeout counter for this seems to make sense.<= /p>

         &= nbsp;           &nbs= p;  

 

  |  +--iscsiIntrAuthorization(9)

  |  |  |

  |  |  +--iscsiIntrAuthAttributesT= able(1)

  |  |  &= nbsp;  |

  |  | &= nbsp;   +--iscsiIntrAuthAttributesEntry(1) [iscsiInstIndex,iscsiN= odeIndex,iscsiIntrAuthIndex]

  |=   |        |

<= p class=3DMsoNormal>  |  |        = +-- --- Unsigned32  iscsiIntrAuthIndex(1)

  |  |        +-- rw= n RowStatus   iscsiIntrAuthRowStatus(2)

  |  |        +--= rwn RowPointer  iscsiIntrAuthIdentity(3)

  |  |        +-- rw= n StorageType iscsiIntrAuthStorageType(4)

 

The reference for iscsiIn= trAuthIdentity is too vague. Only provides the RFC?:

<= p class=3DMsoNormal>REFERENCE

  = ;      "IPS-AUTH MIB, RFC 4545"

 

Editors: We will fix this.

&= nbsp;

  |  +--iscsiSe= ssion(10)

  |  |  |

  |  |  +--iscsiSessionA= ttributesTable(1)

  |  |&nb= sp; |  |

  |  |  = |  +--iscsiSessionAttributesEntry(1) [iscsiInstIndex,iscsiSsnNodeIndex= ,iscsiSsnIndex]

  |  | = ; |     |

  = |  |  |     +-- --- Unsigned32  &nb= sp;   iscsiSsnNodeIndex(1)

=   |  |  |     +-- --- Unsigned32 &n= bsp;    iscsiSsnIndex(2)

  |  |  |     +-- r-n Enumeration&nbs= p;    iscsiSsnDirection(3)

  |  |  |     +-- r-n IscsiName&nbs= p;      iscsiSsnInitiatorName(4)=

  |  |  |     +-- r= -n IscsiName       iscsiSsnTargetName(5)=

  |  |  |   = ;  +-- r-n Unsigned32      iscsiSsnTSIH(6)

  |  |  |  &nb= sp;  +-- r-n OctetString     iscsiSsnISID(7)<= /o:p>

  |  |  |   =   +-- r-n SnmpAdminString iscsiSsnInitiatorAlias(8)<= /p>

  |  |  |     +-- r-= n SnmpAdminString iscsiSsnTargetAlias(9)

  |  |  |     +-- r-n TruthValue&nbs= p;     iscsiSsnInitialR2T(10)

  |  |  |     +-- r-n Truth= Value      iscsiSsnImmediateData(11)

  |  |  |     += -- r-n Enumeration     iscsiSsnType(12)

  |  |  |     +--= r-n Unsigned32      iscsiSsnMaxOutstandingR2T(13)=

  |  |  |  =    +-- r-n Unsigned32      iscsiSsnFirst= BurstLength(14)

  |  | = ; |     +-- r-n Unsigned32     = ; iscsiSsnMaxBurstLength(15)

  |=   |  |     +-- r-n Gauge32   &= nbsp;     iscsiSsnConnectionNumber(16)

  |  |  |     +-- = r-n RowPointer      iscsiSsnAuthIdentity(17)<= /o:p>

  |  |  |   =   +-- r-n TruthValue      iscsiSsnDataSequenc= eInOrder(18)

  |  |  |=      +-- r-n TruthValue      i= scsiSsnDataPDUInOrder(19)

  |&nb= sp; |  |     +-- r-n Unsigned32   &= nbsp;  iscsiSsnErrorRecoveryLevel(20)

  |  |  |     +-- r-n TimeStamp&nb= sp;      iscsiSsnDiscontinuityTime(21)<= /span>

 

Con= sider reporting the digest negotiated for this session.

Consider reporting the error-recovery-level (ERL).<= /o:p>

Consider reporting type(?) negotiated.

 

  |  |  +--iscsiSessionStatsTable(2)<= /p>

  |  |  |  |

<= p class=3DMsoNormal>  |  |  |  +--iscsiSessionStatsEntry(1)= [iscsiInstIndex,iscsiSsnNodeIndex,iscsiSsnIndex]

  |  |  |     |<= /span>

  |  |  |    = +-- r-n Counter32 iscsiSsnCmdPDUs(1)

  |  |  |     +-- r-n Counter32 iscsiSs= nRspPDUs(2)

  |  |  |&= nbsp;    +-- r-n Counter64 iscsiSsnTxDataOctets(3)

  |  |  |   &nbs= p; +-- r-n Counter64 iscsiSsnRxDataOctets(4)

  |  |  |     +-- r-n Counter32= iscsiSsnLCTxDataOctets(5)

  |&n= bsp; |  |     +-- r-n Counter32 iscsiSsnLCRxDataOc= tets(6)

 

<= p class=3DMsoNormal>Consider reporting missing PDU.

Break down counters for data pdus in and out.<= /p>

Add counter for async pdus in.

 

 

Editors: The above seem like good ideas = – will anyone use these?  Also, breaking down the existing count= ers might break current implementations.  We would likely have to crea= te new ones.

 

 

<= span style=3D'font-size:10.0pt;font-family:"Courier New";color:black'> = ; |  |  +--iscsiSessionCxnErrorStatsTable(3)

  |  |     |

  |  |     +--iscsiSe= ssionCxnErrorStatsEntry(1) [iscsiInstIndex,iscsiSsnNodeIndex,iscsiSsnIndex]=

  |  |   &n= bsp;    |

  |&nbs= p; |        +-- r-n Counter32 iscsiSsnCx= nDigestErrors(1)

  |  |&nbs= p;       +-- r-n Counter32 iscsiSsnCxnTimeout= Errors(2)

 

Description should discuss when these counters are most l= ikely provided such as when the error-recovery-level

<= p class=3DMsoNormal>is 1 or 2.

 = ;

 

Editors: We will update the descriptions.

 

 =

  |  +--iscsiConnection(11)

  |     |<= /o:p>

  |     +--iscsiC= onnectionAttributesTable(1)

  |&= nbsp;       |

  |        +--iscsiConnect= ionAttributesEntry(1) [iscsiInstIndex,iscsiSsnNodeIndex,iscsiSsnIndex,iscsi= CxnIndex]

  |   &= nbsp;       |

  |         &nbs= p; +-- --- Unsigned32         =     iscsiCxnIndex(1)

&= nbsp; |           +-- r-n= Unsigned32          &nbs= p;  iscsiCxnCid(2)

  | = ;          +-- r-n Enumeration=             iscsiCxn= State(3)

  |   &n= bsp;       +-- r-n InetAddressType  = ;      iscsiCxnAddrType(4)

  |           +-= - r-n IscsiTransportProtocol iscsiCxnProtocol(6)

  |         &= nbsp; +-- r-n InetPortNumber        = ; iscsiCxnLocalPort(7)

  | =           +-- r-n InetAddress&= nbsp;           iscsiCxnR= emoteAddr(8)

  |  &nbs= p;        +-- r-n InetPortNumber &n= bsp;       iscsiCxnRemotePort(9)

  |       = ;    +-- r-n Unsigned32      &= nbsp;      iscsiCxnMaxRecvDataSegLength(10)

  |      = ;     +-- r-n Unsigned32     &= nbsp;       iscsiCxnMaxXmitDataSegLength(11)<= o:p>

 |     =       +-- r-n IscsiDigestMethod   &= nbsp;  iscsiCxnHeaderIntegrity(12)

  |           +--= r-n IscsiDigestMethod      iscsiCxnDataIntegrity(= 13)

  |    &= nbsp;      +-- r-n TruthValue   &nb= sp;         iscsiCxnRecvMarker(14)<= o:p>

  |     = ;      +-- r-n TruthValue    &= nbsp;        iscsiCxnSendMarker(15)=

  |     &nb= sp;     +-- r-n Unsigned32     = ;        iscsiCxnVersionActive(16)<= /o:p>

 

Consider adding initial remote  ip addr and port to this table.

 

 

Editors:  Not s= ure what the value in initial remote IP addr and port would be – if t= hey change wouldn’t this be a new connection?

 

 =

  |  +--iscsiTarget(6)

  |  |  |

  |  |  +--iscsiTargetAttributesTable(1)

  |  |  |  |<= /o:p>

  |  |  |  +--iscsiTar= getAttributesEntry(1) [iscsiInstIndex,iscsiNodeIndex]

=

  |  |  |     |

  |  |  |   &n= bsp; +-- r-n Counter32       iscsiTgtLoginFai= lures(1)

  |  |  |&nbs= p;    +-- r-n TimeStamp       = iscsiTgtLastFailureTime(2)

  |&n= bsp; |  |     +-- r-n AutonomousType  iscsiTg= tLastFailureType(3)

  |  = |  |     +-- r-n IscsiName    =    iscsiTgtLastIntrFailureName(4)

  |  |  |     +-- r-n InetAddre= ssType iscsiTgtLastIntrFailureAddrType(5)

  |  |  |     +-- r-n InetAddress&n= bsp;    iscsiTgtLastIntrFailureAddr(6)

=

 

  <= /o:p>

  |  |  +--iscsiTarget= LoginStatsTable(2)

  |  |&n= bsp; |  |

  |  | = |  +--iscsiTargetLoginStatsEntry(1) [iscsiInstIndex,iscsiNodeIndex]

  |  |  |  &n= bsp;  |

  |  |  |=      +-- r-n Counter32 iscsiTgtLoginAccepts(1)

  |  |  |   &nb= sp; +-- r-n Counter32 iscsiTgtLoginOtherFails(2)

  |  |  |     +-- r-n Counte= r32 iscsiTgtLoginRedirects(3)

  = |  |  |     +-- r-n Counter32 iscsiTgtLoginAu= thorizeFails(4)

  |  | = ; |     +-- r-n Counter32 iscsiTgtLoginAuthenticateFail= s(5)

  |  |  | &n= bsp;   +-- r-n Counter32 iscsiTgtLoginNegotiateFails(6)

 

&= nbsp; |  |  +--iscsiTargetLogoutStatsTable(3)

  |  |     |

  |  |     +--iscsiT= argetLogoutStatsEntry(1) [iscsiInstIndex,iscsiNodeIndex]<= /p>

  |  |      &nb= sp; |

  |  |  &nb= sp;     +-- r-n Counter32 iscsiTgtLogoutNormals(1)=

  |  |    &= nbsp;   +-- r-n Counter32 iscsiTgtLogoutOthers(2)

 

  = |  +--iscsiTgtAuthorization(7)

&= nbsp; |  |  |

  | = ; |  +--iscsiTgtAuthAttributesTable(1)

  |  |     |

  |  |     &= nbsp;  |

  |  | &= nbsp;      +-- --- Unsigned32  iscsiTgtAuthIn= dex(1)

  |  |  &n= bsp;     +-- rwn RowStatus   iscsiTgtAuthRowS= tatus(2)

  |  |  =       +-- rwn RowPointer  iscsiTgtAuthIdentit= y(3)

  |  |  &nbs= p;     +-- rwn StorageType iscsiTgtAuthStorageType(4)

 

 

Additional Comments:<= o:p>

 

There's no information in any of this regarding iSCSI discovery

information.  That would be potent= ially useful information,

especially = in the case of discovered targets that have no sessions.<= /p>

That could be an indication of a network problem of a

mis-configuration.  The type of d= iscovery performed and the discovered

targets could be put in there and provide this information.

 

E= ditors: This MIB module currently represents only the initiators and target= s provided by the entity being queried.  The remote objects do not app= ear here and are part of someone else’s entity.  So if you had a= target-only device, it wouldn’t have objects for the initiators conn= ecting to it and vise-versa.

=  

Since we don’t= currently support remote objects, adding this capability would be a signif= icant new MIB development by the WG, rather than a fix given the current re= view.

 

 

 <= /o:p>

End of File.

 

 

= --_000_975552A94CBC0F4DA60ED7B36C949CBA03F17813D9shandyBeerTow_-- From Mark_Bakke@DELL.com Thu Jul 12 06:29:34 2012 Return-Path: X-Original-To: storm@ietfa.amsl.com Delivered-To: storm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4C74D21F876F for ; Thu, 12 Jul 2012 06:29:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -105.596 X-Spam-Level: X-Spam-Status: No, score=-105.596 tagged_above=-999 required=5 tests=[AWL=1.002, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id iFZigTIw-3aJ for ; Thu, 12 Jul 2012 06:29:32 -0700 (PDT) Received: from aussmtpmrkpc120.us.dell.com (aussmtpmrkpc120.us.dell.com [143.166.82.159]) by ietfa.amsl.com (Postfix) with ESMTP id A53BD21F8629 for ; Thu, 12 Jul 2012 06:29:32 -0700 (PDT) X-Loopcount0: from 64.238.244.148 X-IronPort-AV: E=Sophos;i="4.77,574,1336366800"; d="scan'208,217";a="508005053" Received: from mail.compellent.com ([64.238.244.148]) by aussmtpmrkpc120.us.dell.com with ESMTP; 12 Jul 2012 08:30:05 -0500 From: Mark Bakke To: "Storm (storm@ietf.org)" Date: Thu, 12 Jul 2012 08:28:45 -0500 Thread-Topic: iSCSI MIB: Heartbeat counters for NOP-In and NOP-Out Usage Thread-Index: Ac1fZpN1pUNbVByGSYmBlR/YJY9UBQ== Message-ID: <975552A94CBC0F4DA60ED7B36C949CBA03F1834043@shandy.Beer.Town> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: multipart/alternative; boundary="_000_975552A94CBC0F4DA60ED7B36C949CBA03F1834043shandyBeerTow_" MIME-Version: 1.0 Cc: "mrm@vmware.com" , "prakashvn@hcl.com" Subject: [storm] iSCSI MIB: Heartbeat counters for NOP-In and NOP-Out Usage X-BeenThere: storm@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Storage Maintenance WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 12 Jul 2012 13:29:34 -0000 --_000_975552A94CBC0F4DA60ED7B36C949CBA03F1834043shandyBeerTow_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Everyone, One of things pointed out during the MIB doctor review is that although mos= t implementations use NOP-In and NOP-Out as a heartbeat / keepalive mechani= sm, we don't provide counters for them or for timeouts based on missing hea= rtbeats in the MIB module. Since this requires a few new objects to be added to the MIB, I wanted to v= et this by the list with two questions: 1. Will it be useful to provide these counters? 2. If so, which counters? For example, to count the NOPs themselves, we can add to either iscsiSessio= nStatsTable or iscsiConnectionStatsTable if we want to keep track of Nop-Ins and Nop-Outs per connection. This shou= ld go to the list. Is Counter32 sufficient for Nops since it is OK for com= mands and responses? I think so: iscsiSsnNopIns Counter32, iscsiSsnNopOuts Counter32, If we do this, do we want per-session or per-connection? If it's per-conne= ction it would require an additional table. Is Counter32 sufficient? I believe so, since it's what we use for commands= and responses, and the number of NOPs certainly won't exceed these. The second part is to provide counters that indicate timeouts based on non-= receipt of NOP responses. This would likely be added to the session's erro= r stats table. Mike MacFaden asked us to consider separate counters for heartbeat / noop v= s data timeouts. | | +--iscsiInstanceSsnErrorStatsTable(2) | | | | | +--iscsiInstanceSsnErrorStatsEntry(1) [iscsiInstIndex] | | | | | +-- r-n Counter32 iscsiInstSsnDigestErrors(1) | | +-- r-n Counter32 iscsiInstSsnCxnTimeoutErrors(2) | | +-- r-n Counter32 iscsiInstSsnFormatErrors(3) Adding something like this might do the trick: iscsiInstSsnNopTimeoutErrors Counter32 iscsiInstSsnDataTimeoutErrors Counter32 Any thoughts on what would be useful for that? Anyone already count these = in your implementations for other purposes? Thanks, Mark --_000_975552A94CBC0F4DA60ED7B36C949CBA03F1834043shandyBeerTow_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Everyone,

 

One = of things pointed out during the MIB doctor review is that although most im= plementations use NOP-In and NOP-Out as a heartbeat / keepalive mechanism, = we don’t provide counters for them or for timeouts based on missing h= eartbeats in the MIB module.

 =

Since this requires a few new objects to be = added to the MIB, I wanted to vet this by the list with two questions:=

 

1.      Will it be u= seful to provide these counters?

<= span style=3D'mso-list:Ignore'>2.  |  |  +--iscsiInstanceSsnErrorStatsTable(2)

  |  |     |

  |  |    = +--iscsiInstanceSsnErrorStatsEntry(1) [iscsiInstIndex]

  |  |      &nbs= p; |

  |  |  &nbs= p;     +-- r-n Counter32 iscsiInstSsnDigestErrors(1)

  |  |    = ;    +-- r-n Counter32 iscsiInstSsnCxnTimeoutErrors(2)<= /o:p>

  |  |    &n= bsp;   +-- r-n Counter32 iscsiInstSsnFormatErrors(3)

 

= Addi= ng something like this might do the trick:

 

    =     iscsiInstSsnNopTimeoutErrors    Counter32=

      =   iscsiInstSsnDataTimeoutErrors   Counter32

       

Any thoughts on what would be useful for that?=   Anyone already count these in your implementations for other purpose= s?

 

Thanks,

 =

Mark

 =

 

= --_000_975552A94CBC0F4DA60ED7B36C949CBA03F1834043shandyBeerTow_-- From david.black@emc.com Fri Jul 13 06:25:09 2012 Return-Path: X-Original-To: storm@ietfa.amsl.com Delivered-To: storm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0347221F86E4 for ; Fri, 13 Jul 2012 06:25:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.475 X-Spam-Level: X-Spam-Status: No, score=-102.475 tagged_above=-999 required=5 tests=[AWL=0.123, BAYES_00=-2.599, HTML_MESSAGE=0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 90qBd4ypTi+4 for ; Fri, 13 Jul 2012 06:25:06 -0700 (PDT) Received: from mexforward.lss.emc.com (hop-nat-141.emc.com [168.159.213.141]) by ietfa.amsl.com (Postfix) with ESMTP id 157D421F869E for ; Fri, 13 Jul 2012 06:25:05 -0700 (PDT) Received: from hop04-l1d11-si02.isus.emc.com (HOP04-L1D11-SI02.isus.emc.com [10.254.111.55]) by mexforward.lss.emc.com (Switch-3.4.3/Switch-3.4.3) with ESMTP id q6DDORPR004245 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 13 Jul 2012 09:24:29 -0400 Received: from mailhub.lss.emc.com (mailhubhoprd02.lss.emc.com [10.254.221.253]) by hop04-l1d11-si02.isus.emc.com (RSA Interceptor); Fri, 13 Jul 2012 09:24:11 -0400 Received: from mxhub15.corp.emc.com (mxhub15.corp.emc.com [128.222.70.236]) by mailhub.lss.emc.com (Switch-3.4.3/Switch-3.4.3) with ESMTP id q6DDOBsx027319; Fri, 13 Jul 2012 09:24:11 -0400 Received: from mx15a.corp.emc.com ([169.254.1.189]) by mxhub15.corp.emc.com ([128.222.70.236]) with mapi; Fri, 13 Jul 2012 09:24:11 -0400 From: To: , Date: Fri, 13 Jul 2012 09:24:09 -0400 Thread-Topic: iSCSI MIB: Heartbeat counters for NOP-In and NOP-Out Usage Thread-Index: Ac1fZpN1pUNbVByGSYmBlR/YJY9UBQBkbhag Message-ID: <8D3D17ACE214DC429325B2B98F3AE71208D3B54C@MX15A.corp.emc.com> References: <975552A94CBC0F4DA60ED7B36C949CBA03F1834043@shandy.Beer.Town> In-Reply-To: <975552A94CBC0F4DA60ED7B36C949CBA03F1834043@shandy.Beer.Town> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: multipart/alternative; boundary="_000_8D3D17ACE214DC429325B2B98F3AE71208D3B54CMX15Acorpemccom_" MIME-Version: 1.0 X-EMM-MHVC: 1 Cc: mrm@vmware.com, prakashvn@hcl.com Subject: Re: [storm] iSCSI MIB: Heartbeat counters for NOP-In and NOP-Out Usage X-BeenThere: storm@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Storage Maintenance WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 13 Jul 2012 13:25:09 -0000 --_000_8D3D17ACE214DC429325B2B98F3AE71208D3B54CMX15Acorpemccom_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi Mark, The MIB Doctor review contained a number of suggestions for functional enha= ncements. My view is that significant enhancements need to be worked on in a new draf= t in the WG, unless their absence is a significant problem for MIB usabilit= y. Obviously, whether an enhancement is "significant" or its absence cause= s a "significant problem" is a judgment call, so YMMV. I view addition of a new table as being significant, so my suggestions woul= d be: - Add the NOP counters at session scope to avoid a new table. - Add the NOP timeout counters at connection scope. This is based on the current MIB structure that tracks activity at a sessio= n level (sufficient if things are working) and tracks errors by connection = (useful if something has gone wrong, as the problem may be connection-speci= fic). Counter32 values ought to suffice, as they're used for commands and respons= es (as you note). Also, NOPs, whether used for heartbeats or otherwise sho= uld not be sent at any significant fraction of the line rate. It probably doesn't hurt to add the data timeout counter, but that seems le= ss important (IMHO) by comparison to the NOP timeout counter as data timeou= t will manifest as a failed SCSI command, of which notice will be taken hi= gher in the SCSI stack. In contrast, iSCSI NOP timeouts aren't SCSI errors= . I strongly suggest that these new counters not be required for MODULE-COMPL= IANCE. Thanks, --David From: Mark Bakke [mailto:Mark_Bakke@DELL.com] Sent: Thursday, July 12, 2012 9:29 AM To: Storm (storm@ietf.org) Cc: MacFaden, Michael (VMware); prakashvn@hcl.com; Black, David; ttalpey@mi= crosoft.com Subject: iSCSI MIB: Heartbeat counters for NOP-In and NOP-Out Usage Everyone, One of things pointed out during the MIB doctor review is that although mos= t implementations use NOP-In and NOP-Out as a heartbeat / keepalive mechani= sm, we don't provide counters for them or for timeouts based on missing hea= rtbeats in the MIB module. Since this requires a few new objects to be added to the MIB, I wanted to v= et this by the list with two questions: 1. Will it be useful to provide these counters? 2. If so, which counters? For example, to count the NOPs themselves, we can add to either iscsiSessio= nStatsTable or iscsiConnectionStatsTable if we want to keep track of Nop-Ins and Nop-Outs per connection. This shou= ld go to the list. Is Counter32 sufficient for Nops since it is OK for com= mands and responses? I think so: iscsiSsnNopIns Counter32, iscsiSsnNopOuts Counter32, If we do this, do we want per-session or per-connection? If it's per-conne= ction it would require an additional table. Is Counter32 sufficient? I believe so, since it's what we use for commands= and responses, and the number of NOPs certainly won't exceed these. The second part is to provide counters that indicate timeouts based on non-= receipt of NOP responses. This would likely be added to the session's erro= r stats table. Mike MacFaden asked us to consider separate counters for heartbeat / noop v= s data timeouts. | | +--iscsiInstanceSsnErrorStatsTable(2) | | | | | +--iscsiInstanceSsnErrorStatsEntry(1) [iscsiInstIndex] | | | | | +-- r-n Counter32 iscsiInstSsnDigestErrors(1) | | +-- r-n Counter32 iscsiInstSsnCxnTimeoutErrors(2) | | +-- r-n Counter32 iscsiInstSsnFormatErrors(3) Adding something like this might do the trick: iscsiInstSsnNopTimeoutErrors Counter32 iscsiInstSsnDataTimeoutErrors Counter32 Any thoughts on what would be useful for that? Anyone already count these = in your implementations for other purposes? Thanks, Mark --_000_8D3D17ACE214DC429325B2B98F3AE71208D3B54CMX15Acorpemccom_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi Mark,<= /span>

 

<= ;WG chair hat off>

 

The MIB Doctor review contained a number of s= uggestions for functional enhancements.

 

My view is that significant= enhancements need to be worked on in a new draft in the WG, unless their a= bsence is a significant problem for MIB usability.  Obviously, whether= an enhancement is “significant” or its absence causes a “= ;significant problem” is a judgment call, so YMMV.<= /p>

 

I view add= ition of a new table as being significant, so my suggestions would be:=

- Add the NOP = counters at session scope to avoid a new table.

- Add the NOP timeout counters at con= nection scope.

This is based on the c= urrent MIB structure that tracks activity at a session level (sufficient if= things are working) and tracks errors by connection (useful if something h= as gone wrong, as the problem may be connection-specific).

 

Counter3= 2 values ought to suffice, as they’re used for commands and responses= (as you note).  Also, NOPs, whether used for heartbeats or otherwise = should not be sent at any significant fraction of the line rate.=

 

It= probably doesn’t hurt to add the data timeout counter, but that seem= s less important (IMHO) by comparison to the NOP timeout counter as data ti= meout  will manifest as a failed SCSI command, of which notice will be= taken higher in the SCSI stack.  In contrast, iSCSI NOP timeouts aren= ’t SCSI errors.

 

I strongly suggest that these new counters no= t be required for MODULE-COMPLIANCE.

=  

Thanks,
--David

 

From: Mark Bakke [mailto:Mark_= Bakke@DELL.com]
Sent: Thursday, July 12, 2012 9:29 AM
To:<= /b> Storm (storm@ietf.org)
Cc: MacFaden, Michael (VMware); prakas= hvn@hcl.com; Black, David; ttalpey@microsoft.com
Subject: iSCSI M= IB: Heartbeat counters for NOP-In and NOP-Out Usage

 

Ev= eryone,

 

One of things pointed out during the MIB doctor review is that al= though most implementations use NOP-In and NOP-Out as a heartbeat / keepali= ve mechanism, we don’t provide counters for them or for timeouts base= d on missing heartbeats in the MIB module.

 

Since this requires a few new = objects to be added to the MIB, I wanted to vet this by the list with two q= uestions:

 

1.      Will it be useful to provide these counters?

2.      If= so, which counters?

 

For example, to count the NOPs themselves, we can ad= d to either iscsiSessionStatsTable or iscsiConnectionStatsTable<= /p>

 

if we wan= t to keep track of Nop-Ins and Nop-Outs per connection.  This should g= o to the list.  Is Counter32 sufficient for Nops since it is OK for co= mmands and responses?  I think so:

=  

    iscsiSsnNopIns=              &n= bsp;    Counter32,

&= nbsp;   iscsiSsnNopOuts       =         Counter32,

 

If we do this, do w= e want per-session or per-connection?  If it’s per-connection it= would require an additional table.

 

Is Counter32 sufficient?  I beli= eve so, since it’s what we use for commands and responses, and the nu= mber of NOPs certainly won’t exceed these.

 

The second part is to pr= ovide counters that indicate timeouts based on non-receipt of NOP responses= .  This would likely be added to the session’s error stats table= .

 

Mike MacFaden asked us to consider separate counters for heartbeat / no= op vs data timeouts.

 

  |  |  +--iscsiInstanceSsnErrorStatsTabl= e(2)

  |  |  &nbs= p;  |

  |  | &nbs= p;   +--iscsiInstanceSsnErrorStatsEntry(1) [iscsiInstIndex]<= /o:p>

  |  |    &n= bsp;   |

  |  |&n= bsp;       +-- r-n Counter32 iscsiInstSsnDige= stErrors(1)

  |  | &nb= sp;      +-- r-n Counter32 iscsiInstSsnCxnTimeoutE= rrors(2)

  |  |  =       +-- r-n Counter32 iscsiInstSsnFormatErrors(3= )

 

Adding something like this might do the trick:<= /p>

 

 &nbs= p;      iscsiInstSsnNopTimeoutErrors   &= nbsp;Counter32

   &nbs= p;    iscsiInstSsnDataTimeoutErrors   Counter32

      &nb= sp;

Any thoughts on what would be us= eful for that?  Anyone already count these in your implementations for= other purposes?

 

Thanks,

 = ;

Mark

 

 

= --_000_8D3D17ACE214DC429325B2B98F3AE71208D3B54CMX15Acorpemccom_-- From david.black@emc.com Fri Jul 13 06:49:04 2012 Return-Path: X-Original-To: storm@ietfa.amsl.com Delivered-To: storm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 776AF21F8624 for ; Fri, 13 Jul 2012 06:49:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.506 X-Spam-Level: X-Spam-Status: No, score=-101.506 tagged_above=-999 required=5 tests=[AWL=-0.911, BAYES_00=-2.599, HTML_MESSAGE=0.001, TRACKER_ID=2.003, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id awN5F8MyUgSo for ; Fri, 13 Jul 2012 06:48:49 -0700 (PDT) Received: from mexforward.lss.emc.com (hop-nat-141.emc.com [168.159.213.141]) by ietfa.amsl.com (Postfix) with ESMTP id 619CB21F867E for ; Fri, 13 Jul 2012 06:48:49 -0700 (PDT) Received: from hop04-l1d11-si01.isus.emc.com (HOP04-L1D11-SI01.isus.emc.com [10.254.111.54]) by mexforward.lss.emc.com (Switch-3.4.3/Switch-3.4.3) with ESMTP id q6DDnG06030791 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 13 Jul 2012 09:49:17 -0400 Received: from mailhub.lss.emc.com (mailhub.lss.emc.com [10.254.222.130]) by hop04-l1d11-si01.isus.emc.com (RSA Interceptor); Fri, 13 Jul 2012 09:49:01 -0400 Received: from mxhub34.corp.emc.com (mxhub34.corp.emc.com [10.254.93.82]) by mailhub.lss.emc.com (Switch-3.4.3/Switch-3.4.3) with ESMTP id q6DDn0DS004049; Fri, 13 Jul 2012 09:49:00 -0400 Received: from mx15a.corp.emc.com ([169.254.1.189]) by mxhub34.corp.emc.com ([::1]) with mapi; Fri, 13 Jul 2012 09:48:59 -0400 From: To: , Date: Fri, 13 Jul 2012 09:48:57 -0400 Thread-Topic: MIB Doctor Review for iSCSI MIB, proposed changes, and list questions Thread-Index: Ac1d7t+U2g2vOeQ/QtWQihiahn+w8QBdtJpwAGVWj/A= Message-ID: <8D3D17ACE214DC429325B2B98F3AE71208D3B568@MX15A.corp.emc.com> References: <975552A94CBC0F4DA60ED7B36C949CBA03F1781133@shandy.Beer.Town> <975552A94CBC0F4DA60ED7B36C949CBA03F17813D9@shandy.Beer.Town> In-Reply-To: <975552A94CBC0F4DA60ED7B36C949CBA03F17813D9@shandy.Beer.Town> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: multipart/alternative; boundary="_000_8D3D17ACE214DC429325B2B98F3AE71208D3B568MX15Acorpemccom_" MIME-Version: 1.0 X-EMM-MHVC: 1 X-Mailman-Approved-At: Fri, 13 Jul 2012 07:20:34 -0700 Cc: mrm@vmware.com, prakashvn@hcl.com Subject: Re: [storm] MIB Doctor Review for iSCSI MIB, proposed changes, and list questions X-BeenThere: storm@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Storage Maintenance WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 13 Jul 2012 13:49:04 -0000 --_000_8D3D17ACE214DC429325B2B98F3AE71208D3B568MX15Acorpemccom_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable DLB> Global comment - please be careful about compliance wrt anything that'= s added. DLB> I also noticed that the description of the V2 compliance statement nee= ds to DLB> be updated, as this is no longer the initial version of the MIB module= . DLB> Some comments on the proposed courses of action: | +--iscsiPortal(2) | | | | | +--iscsiPortalAttributesTable(1) | | | | | +--iscsiPortalAttributesEntry(1) [iscsiInstIndex,iscsiPortalInde= x] > Additionally, a list for authentication negotiation would be useful, > also. There are five different authentication methods defined by the > original RFC 3720, and a few additional ones that have since sprung up. DLB> That sounds potentially useful, although ... DLB> ... of the five authentication methods defined in RFC 3720, only the DLB> required CHAP method is in widespread use and the two SPKM methods DLB> are being removed by the new iSCSI draft. FWIW, the Kerberos method DLB> is considered to be the "wrong approach" by the Kerberos experts DLB> because it's not GSSAPI-based, and there hasn't been much interest DLB> in defining a GSSAPI method. DLB> The method list would have to be strings, because any additional DLB> methods would be using private text keys based that are based on DLB> reversed domain names. | | +--iscsiSessionStatsTable(2) | | | | | | | +--iscsiSessionStatsEntry(1) [iscsiInstIndex,iscsiSsnNodeIndex,i= scsiSsnIndex] | | | | | | | +-- r-n Counter32 iscsiSsnCmdPDUs(1) | | | +-- r-n Counter32 iscsiSsnRspPDUs(2) | | | +-- r-n Counter64 iscsiSsnTxDataOctets(3) | | | +-- r-n Counter64 iscsiSsnRxDataOctets(4) | | | +-- r-n Counter32 iscsiSsnLCTxDataOctets(5) | | | +-- r-n Counter32 iscsiSsnLCRxDataOctets(6) > Consider reporting missing PDU. > Break down counters for data pdus in and out. > Add counter for async pdus in. Editors: The above seem like good ideas - will anyone use these? Also, bre= aking down the existing counters might break current implementations. We w= ould likely have to create new ones. DLB> Definitely do not remove or deprecate the existing counters. > There's no information in any of this regarding iSCSI discovery > information. That would be potentially useful information, > especially in the case of discovered targets that have no sessions. > That could be an indication of a network problem of a > mis-configuration. The type of discovery performed and the discovered > targets could be put in there and provide this information. Editors: This MIB module currently represents only the initiators and targe= ts provided by the entity being queried. The remote objects do not appear = here and are part of someone else's entity. So if you had a target-only de= vice, it wouldn't have objects for the initiators connecting to it and vice= -versa. Since we don't currently support remote objects, adding this capability wou= ld be a significant new MIB development by the WG, rather than a fix given = the current review. DLB> I agree with Mark - (with ) this feels like it's DLB> well beyond the scope of what the WG was chartered to do with this MIB= . Thanks, --David From: Mark Bakke [mailto:Mark_Bakke@DELL.com] Sent: Wednesday, July 11, 2012 9:06 AM To: Storm (storm@ietf.org) Cc: Black, David; prakashvn@hcl.com; ttalpey@microsoft.com; MacFaden, Micha= el (VMware) Subject: FW: MIB Doctor Review for iSCSI MIB, proposed changes, and list qu= estions Everyone, We are in the process of updating the iSCSI MIB module, to match the latest= storm changes. Mike MacFaden has also done a MIB Doctor review, which bro= ught back a number of comments on things that are potentially missing from = the original iSCSI MIB RFC. Prakash, David, Tom and I have been reviewing the MIB doctor requests. Thi= s message is intended to answer some of the MIB doctor comments as well as = generate discussion on the list about possible changes. We intend to post = another draft (-02) before the July 16th deadline for the next round of dis= cussion. Here is a brief summary. The full responses to comments are below. * Several editorial changes * A few new fields are added to objects that are either useful or w= ere missed the first time around * More complex additions that we believe will need a separate revis= ion and may affect the object model. The latter changes would require supp= ort from those intending to implement or use them. I will start separate discussion threads on a few items: * Heartbeat counters for NOP-In and NOP-Out usage * TCP MIB correlation for sessions and connections * iscsiInstanceSsnErrorStatsTable session details For reference, we have: * The previous draft of the new iSCSI MIB - http://www.ietf.org/id/= draft-ietf-storm-iscsimib-01.txt * The initial MIB doctor review - http://www.macfaden.com/ietf/iscs= i-mib-1-reviewed.txt * An additional MIB doctor review with VMware engineers - http://ma= cfaden.com/ietf/iscsi-mib-notes.txt Detailed responses to MIB doctor review: February 17, 2012 MIB DOCTOR Review: http://www.ietf.org/id/draft-ietf-stor= m-iscsimib-01.txt Performed by Michael R. MacFaden, VMware, Inc According to http://tools.ietf.org/html/rfc4181 This review only covers syntax, SMIv2 rules usage of the MIB module itself,= not the draft. Some of the things mentioned below exist the prior version of the mib, not = this update. 1 boiler plate - check 2. Narrative Sections - check 3. Security Considerations - check 4. IANA Considerations - missing editors' note. Section 9 needs the following verbiage to be added. Editor's Note (to be removed prior to publication): this draft makes no additional requests of the IANA. Editors: We will fix this. 5. No new namespaces 6. References section - check 7. copyright notice - check 8. Intellectual Property section - missing Editors: We will add the section: Copyright (c) 2011 IETF Trust and the persons identified as authors of the code. All rights reserved. Redistribution and use in source and binary forms, with or without modification, is permitted pursuant to, and subject to the license terms contained in, the Simplified BSD License set forth in Section 4.c of the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info)." 9. This change updates existing mib rfc http://www.ietf.org/rfc/rfc4544.txt= - check Backward compatibility checks: (oids, object-identities, remained the sa= me) Other items checked -- syntax check: smilint -l9 - no errors smicng : not run spelling: Aspell --- no misspellings found. URLs validated: checked for valid, not-broken links: http://www.iana.org/assignments/protocol-numbers References in MIB module not found in normative (sec 10.1) IscsiTransportProtocol TC -> "RFC791, RFC1700 Editors: We will fix this. enumerations: each element described - IscsiDigestMethod Editors: We had this in the description - is there something else that need= s to be added? DiscontinuityTime is syntax: TimeStamp All Counters: define their discontinuity timestamp. Editors: We checked the descriptions in each of the Counter32 and Counter64= fields, and they all reference a discontinuity timestamp. Isn't that enou= gh? Uncommon stuff: 1) In IscsiPortalAttributesEntry has RowStatus as second item in the conce= ptual row, not after iscsiPortalStorageType. Editors: We currently don't put StorageType and RowStatus together in any o= f our objects, and didn't originally realize there was some tradition aroun= d this. Changing numbering now would cause backward compatibility problems= , so we cannot make this change. 2) iscsiPortalRoles does not have a DEFVAL when most others do in this conc= eptual table. iscsiPortalAddrType has def val of IPV4? when the iscsiPortalAddr has no de= fault to go with it? Editors: There isn't a reasonable DEFVAL for iscsiPortalRoles. It has to = be set when creating the row, so we will leave this one. 3) iscsiNodeAttributesEntry sez: An entry (row) containing mana vs 'conceptual row' which is used inconsistently. Editors: We will change this description from: An entry (row) containing management information applicable to a particular iSCSI node. To A conceptual row containing management information applicable to a particular iSCSI node. 4) (e.g. not created via this MIB). vs MIB module. There is but one MIB a= s Dr Case would say. Editors: We will fix this one. 5) 64 bit counters with SNMPv1 support for 32 bit high/low? kinda iscsiSsnTxDataOctets, iscsiSsnRxDataOctets, provides only low word: iscsi= SsnLCTxDataOctets, iscsiSsnLCRxDataOctets Compliance phrasing is a bit odd: "A Low Capacity shadow object of iscsiSsnTxDataOctets for those systems that don't support Counter64. instead of 'for those systems which are accessible via SNMPv1 only' Editors: We will fix the wording for SNMPv1. We don't see a reason to add= objects for high octets. 6) Notifications are required to have a rate limited implementation by a de= scription, yet the number of times the failure occurred is not conveyed in the no= tifcation varbind list. iscsiTgtLoginFailure, iscsiIntrLoginFailure, iscsiInstSessionFailure To avoid sending an excessive number of notifications due to multiple errors counted, an SNMP agent implementing this notification SHOULD NOT send more than 3 notifications of this type in any 10-second time period." Editors: We believe that this is covered by the counter "iscsiTgtLoginFail= ures": iscsiTgtLoginFailure NOTIFICATION-TYPE OBJECTS { iscsiTgtLoginFailures, iscsiTgtLastFailureType, iscsiTgtLastIntrFailureName, iscsiTgtLastIntrFailureAddrType, iscsiTgtLastIntrFailureAddr } The following section addresses comments from the VMware iSCSI-MIB review: Notes from VMware ISCIS-MIB review meeting March 21, 2012 Attendees: Andy Banta, Kun Huang, Mike MacFaden General comments: 1. Many objects lacking REFERENCE clause or offer only vague references. For those managed objects having a Reference clause, nedd to fix up 'RFC cc= cc' For example: "RFC cccc, Section 7.5, Connection Timeout Management" Example of vague reference: REFERENCE "SCSI-MIB" Editors: OK, we can update in the next draft. 2. Descriptions are short and simple but in some case seem a bit too short for an IETF standard mib module. Editors: We can look for opportunities to clarify but don't think we want t= o go through and rewrite a lot. If there are particular descriptions that = cause confusion please bring them up. Here's the comments by object in the MIB module: draft-ietf-storm-iscsimib-= 01.txt iscsiMibModule(1.3.6.1.2.1.142) | +--iscsiNotifications(0) | | | +--iscsiTgtLoginFailure(1) [iscsiTgtLoginFailures,iscsiTgtLastFailureT= ype,iscsiTgtLastIntrFailureName,iscsiTgtLastIntrFailureAddrType,iscsiTgtLas= tIntrFailureAddr] Consider adding port number. Editors: LastFailurePortNumber would be easy enough to add. Should we do a= n OrZero for implementations that can't get the port number? | +--iscsiIntrLoginFailure(2) [iscsiIntrLoginFailures,iscsiIntrLastFailu= reType,iscsiIntrLastTgtFailureName,iscsiIntrLastTgtFailureAddrType,iscsiInt= rLastTgtFailureAddr] Can't determine if the failure is due to failure of the underlying transpor= t or not. When transport is TCP there should be some way to get to the TCP-MIB/TCP-ES= TATS-MIB diagnostics. See notes on iscsiInstanceSsnErrorStatsTable. Consider adding port number. Editors: Same as above. On the failure, is it useful to have both local an= d remote addr and port number? Will the TCP MIB keep these connections aro= und long enough to go index it on a failed connection? If we add these fie= lds, will someone use them? | +--iscsiInstSessionFailure(3) [iscsiInstSsnFailures,iscsiInstLastSsnFa= ilureType,iscsiInstLastSsnRmtNodeName] Consider handling the event "Target Unmapped" by updatingiscsiInstLastSsnF= ailureType of a Session failure, as well. Editors: FailureType is an OID pointing to a stat in iscsiInstSsnErrorStats= Table, so we would need to add to this: iscsiInstSsnTgtUnmappedErrors Counter32 Are there others that would be needed? Consider adding summary notification in the case of larger scales (number o= f targets) what about large scales, # of targets, each target have a failure of simila= r sort. Editors: Would such a notification really be used? If there was a large sc= ale failure of many targets, we believe the administrator would see enough = of the notifications to notice it as a larger problem. | | +--iscsiInstanceSsnErrorStatsTable(2) | | | | | +--iscsiInstanceSsnErrorStatsEntry(1) [iscsiInstIndex] | | | | | +-- r-n Counter32 iscsiInstSsnDigestErrors(1) | | +-- r-n Counter32 iscsiInstSsnCxnTimeoutErrors(2) | | +-- r-n Counter32 iscsiInstSsnFormatErrors(3) Related states for transport are not provided in this table. Either a RowPo= inter to another mib module is needed or a generic transport counter to indicate = failure at that layer was detected by iscsiInstance. Editors: If connection timeout errors are seen, wouldn't the user check tra= nsport connectivity via ping and other tools? We are not sure that adding = more objects here would add enough value. Consider separate counters for HB vs data timeouts. Consider specific heartbeat no-op timeout error countes. Editors: We will start another thread for this discussion. It does seem us= eful since most implementations use NOP for keep-alive heartbeats. | +--iscsiPortal(2) | | | | | +--iscsiPortalAttributesTable(1) | | | | | +--iscsiPortalAttributesEntry(1) [iscsiInstIndex,iscsiPortalInde= x] | | | | | +-- --- Unsigned32 iscsiPortalIndex(1) | | +-- rwn RowStatus iscsiPortalRowStatus(2) | | +-- rwn Bits iscsiPortalRoles(3) | | +-- rwn InetAddressType iscsiPortalAddrType(4) | | +-- rwn InetAddress iscsiPortalAddr(5) | | +-- rwn IscsiTransportProtocol iscsiPortalProtocol(6) | | +-- rwn Unsigned32 iscsiPortalMaxRecvDataSegLengt= h(7) | | +-- rwn IscsiDigestMethod iscsiPortalPrimaryHdrDigest(8) | | +-- rwn IscsiDigestMethod iscsiPortalPrimaryDataDigest(9= ) | | +-- rwn IscsiDigestMethod iscsiPortalSecondaryHdrDigest(= 10) | | +-- rwn IscsiDigestMethod iscsiPortalSecondaryDataDigest= (11) | | +-- rwn TruthValue iscsiPortalRecvMarker(12) | | +-- rwn StorageType iscsiPortalStorageType(13) Digests are negotiated and implementations may have additional levels (tert= iary, quaternary) as well as constraints that are not modelled here. Editors: There's only one standardized digest method currently in use (CRC3= 2C) that we know of. Are there implementations that extend this beyond two= ? Digests can also be configured in iscsiNodeAttributesTable. (Is there a pre= cecence between node and portal?) Editors: There is no digests field currently in NodeAttributesTable, so Por= tal is the only place to configure it. Need to be able to set/show port number as well as iscsiPortalAddr. Editors: We can add this one. Regarding iscsiCxnRecvMarker, iscsiCxnSendMarker these are to be deprecate= d and are redundant in session and connection. Editors: These will be removed. The V2 object groups in the draft do not c= ontain the deprecated objects. ** note: I Checked with INET-ADDRESS-MIB about iscsiPortalAddrType, if set = to 16 dns(16) A DNS domain name as defined by the InetAddressDNS textual convention. Then iscsiPortalAddr can be a dns hostname. Appears the MIB Portal Attributes and Node Atributes are sort os a mish-mash or Node, Lhba, Phba, various Portal properties. Editors: Not sure we understand this one - the MIB follows iSCSI node and = portal definitions for portals and nodes. HBAs are outside the scope of th= e MIB and of iSCSI. Using a table rather than Primary and Secondary would be the right approach for Header and Data digests, since the whole point of these negotiations is to provide a list of what each side is willing to settle on. Editors: Technically, yes, but practically it seems over-complicated. Additionally, a list for authentication negotiation would be useful, also. There are five different authentication methods defined by the original RFC 3720, and a few additional ones that have since sprung up. Editors: Isn't the list of authorized entities sufficient, since the method= s are included by reference?] There's also the idea of mutual authentication, where each side verfies the identity of the other, rathern than just a target authenticatiing a host. Editors: Is this comment referring to the iscsiSsnAuthIdentity? We do see = that this is just one per session, and we didn't identify it as an initiato= r or target identity (most people likely assumed initiator). We'd need to change this name to iscsiSsnAuthIntrIdentity and add iscsiSsnA= uthTgtIdentity to show both identities in a session where this is used. Additional useful information at the Portal level might be at least some identification of what type of initiator it is, and some identifying information about it. Maybe not the level of detail you'll find in IMA_PHBA_PROPERTIES, but the model, description and version. Editors: this seems useful for troubleshooting. We can add something simil= ar to iscsiInstDescr: iscsiPortalDescr OBJECT-TYPE SYNTAX SnmpAdminString MAX-ACCESS read-only STATUS current DESCRIPTION "A UTF-8 string, determined by the implementation to describe the iSCSI portal. When only a single instance is present, this object may be set to the zero-length string; with multiple iSCSI portals, it may be used in an implementation-dependent manner to describe the respective portal, and could include information such as HBA model, description and version or software driver and version." I don't think that we'd want to try to structure it more than just a string= . | +--iscsiNode(5) | | | | | +--iscsiNodeAttributesTable(1) | | | | | +--iscsiNodeAttributesEntry(1) [iscsiInstIndex,iscsiNodeIndex] | | | | | +-- --- Unsigned32 iscsiNodeIndex(1) | | +-- r-n IscsiName iscsiNodeName(2) | | +-- r-n SnmpAdminString iscsiNodeAlias(3) | | +-- r-n Bits iscsiNodeRoles(4) | | +-- r-n RowPointer iscsiNodeTransportType(5) | | +-- r-n TruthValue iscsiNodeInitialR2T(6) | | +-- rwn TruthValue iscsiNodeImmediateData(7) | | +-- rwn Unsigned32 iscsiNodeMaxOutstandingR2T(8) | | +-- rwn Unsigned32 iscsiNodeFirstBurstLength(9) | | +-- rwn Unsigned32 iscsiNodeMaxBurstLength(10) | | +-- rwn Unsigned32 iscsiNodeMaxConnections(11) | | +-- rwn TruthValue iscsiNodeDataSequenceInOrder(12) | | +-- rwn TruthValue iscsiNodeDataPDUInOrder(13) | | +-- rwn Unsigned32 iscsiNodeDefaultTime2Wait(14) | | +-- rwn Unsigned32 iscsiNodeDefaultTime2Retain(15) | | +-- rwn Unsigned32 iscsiNodeErrorRecoveryLevel(16) | | +-- r-n TimeStamp iscsiNodeDiscontinuityTime(17) | | +-- rwn StorageType iscsiNodeStorageType(18) Digests as found in scsiPortalAttributesTable, may be provisioned at this l= evel. Editors: Is there a need to provision digest at this level via the MIB modu= le? | +--iscsiInitiator(8) | | | | | +--iscsiInitiatorAttributesTable(1) | | | | | | | +--iscsiInitiatorAttributesEntry(1) [iscsiInstIndex,iscsiNodeInd= ex] | | | | | | | +-- r-n Counter32 iscsiIntrLoginFailures(1) | | | +-- r-n TimeStamp iscsiIntrLastFailureTime(2) | | | +-- r-n AutonomousType iscsiIntrLastFailureType(3) | | | +-- r-n IscsiName iscsiIntrLastTgtFailureName(4) | | | +-- r-n InetAddressType iscsiIntrLastTgtFailureAddrType(5) | | | +-- r-n InetAddress iscsiIntrLastTgtFailureAddr(6) No port number provided. Editors: We will add iscsiIntrLastTgtFailurePort | | +--iscsiInitiatorLoginStatsTable(2) | | | | | | | +--iscsiInitiatorLoginStatsEntry(1) [iscsiInstIndex,iscsiNodeInd= ex] | | | | | | | +-- r-n Counter32 iscsiIntrLoginAcceptRsps(1) | | | +-- r-n Counter32 iscsiIntrLoginOtherFailRsps(2) | | | +-- r-n Counter32 iscsiIntrLoginRedirectRsps(3) | | | +-- r-n Counter32 iscsiIntrLoginAuthFailRsps(4) | | | +-- r-n Counter32 iscsiIntrLoginAuthenticateFails(5) | | | +-- r-n Counter32 iscsiIntrLoginNegotiateFails(6) No way to get to transport layer (tcp, etc) related errors not shown here o= r provided through RowPointer/etc. Editors: We are not sure that this will add enough value. | | +--iscsiInitiatorLogoutStatsTable(3) | | | | | +--iscsiInitiatorLogoutStatsEntry(1) [iscsiInstIndex,iscsiNodeIn= dex] | | | | | +-- r-n Counter32 iscsiIntrLogoutNormals(1) | | +-- r-n Counter32 iscsiIntrLogoutOthers(2) The counter iscsiIntrLogoutOthers does not cover cases where no ack is retu= rned (timeout case) due to failure of transport to deliver logout ack. Editors: Adding a timeout counter for this seems to make sense. | +--iscsiIntrAuthorization(9) | | | | | +--iscsiIntrAuthAttributesTable(1) | | | | | +--iscsiIntrAuthAttributesEntry(1) [iscsiInstIndex,iscsiNodeInde= x,iscsiIntrAuthIndex] | | | | | +-- --- Unsigned32 iscsiIntrAuthIndex(1) | | +-- rwn RowStatus iscsiIntrAuthRowStatus(2) | | +-- rwn RowPointer iscsiIntrAuthIdentity(3) | | +-- rwn StorageType iscsiIntrAuthStorageType(4) The reference for iscsiIntrAuthIdentity is too vague. Only provides the RFC= ?: REFERENCE "IPS-AUTH MIB, RFC 4545" Editors: We will fix this. | +--iscsiSession(10) | | | | | +--iscsiSessionAttributesTable(1) | | | | | | | +--iscsiSessionAttributesEntry(1) [iscsiInstIndex,iscsiSsnNodeIn= dex,iscsiSsnIndex] | | | | | | | +-- --- Unsigned32 iscsiSsnNodeIndex(1) | | | +-- --- Unsigned32 iscsiSsnIndex(2) | | | +-- r-n Enumeration iscsiSsnDirection(3) | | | +-- r-n IscsiName iscsiSsnInitiatorName(4) | | | +-- r-n IscsiName iscsiSsnTargetName(5) | | | +-- r-n Unsigned32 iscsiSsnTSIH(6) | | | +-- r-n OctetString iscsiSsnISID(7) | | | +-- r-n SnmpAdminString iscsiSsnInitiatorAlias(8) | | | +-- r-n SnmpAdminString iscsiSsnTargetAlias(9) | | | +-- r-n TruthValue iscsiSsnInitialR2T(10) | | | +-- r-n TruthValue iscsiSsnImmediateData(11) | | | +-- r-n Enumeration iscsiSsnType(12) | | | +-- r-n Unsigned32 iscsiSsnMaxOutstandingR2T(13) | | | +-- r-n Unsigned32 iscsiSsnFirstBurstLength(14) | | | +-- r-n Unsigned32 iscsiSsnMaxBurstLength(15) | | | +-- r-n Gauge32 iscsiSsnConnectionNumber(16) | | | +-- r-n RowPointer iscsiSsnAuthIdentity(17) | | | +-- r-n TruthValue iscsiSsnDataSequenceInOrder(18) | | | +-- r-n TruthValue iscsiSsnDataPDUInOrder(19) | | | +-- r-n Unsigned32 iscsiSsnErrorRecoveryLevel(20) | | | +-- r-n TimeStamp iscsiSsnDiscontinuityTime(21) Consider reporting the digest negotiated for this session. Consider reporting the error-recovery-level (ERL). Consider reporting type(?) negotiated. | | +--iscsiSessionStatsTable(2) | | | | | | | +--iscsiSessionStatsEntry(1) [iscsiInstIndex,iscsiSsnNodeIndex,i= scsiSsnIndex] | | | | | | | +-- r-n Counter32 iscsiSsnCmdPDUs(1) | | | +-- r-n Counter32 iscsiSsnRspPDUs(2) | | | +-- r-n Counter64 iscsiSsnTxDataOctets(3) | | | +-- r-n Counter64 iscsiSsnRxDataOctets(4) | | | +-- r-n Counter32 iscsiSsnLCTxDataOctets(5) | | | +-- r-n Counter32 iscsiSsnLCRxDataOctets(6) Consider reporting missing PDU. Break down counters for data pdus in and out. Add counter for async pdus in. Editors: The above seem like good ideas - will anyone use these? Also, bre= aking down the existing counters might break current implementations. We w= ould likely have to create new ones. | | +--iscsiSessionCxnErrorStatsTable(3) | | | | | +--iscsiSessionCxnErrorStatsEntry(1) [iscsiInstIndex,iscsiSsnNod= eIndex,iscsiSsnIndex] | | | | | +-- r-n Counter32 iscsiSsnCxnDigestErrors(1) | | +-- r-n Counter32 iscsiSsnCxnTimeoutErrors(2) Description should discuss when these counters are most likely provided suc= h as when the error-recovery-level is 1 or 2. Editors: We will update the descriptions. | +--iscsiConnection(11) | | | +--iscsiConnectionAttributesTable(1) | | | +--iscsiConnectionAttributesEntry(1) [iscsiInstIndex,iscsiSsnNod= eIndex,iscsiSsnIndex,iscsiCxnIndex] | | | +-- --- Unsigned32 iscsiCxnIndex(1) | +-- r-n Unsigned32 iscsiCxnCid(2) | +-- r-n Enumeration iscsiCxnState(3) | +-- r-n InetAddressType iscsiCxnAddrType(4) | +-- r-n InetAddress iscsiCxnLocalAddr(5) | +-- r-n IscsiTransportProtocol iscsiCxnProtocol(6) | +-- r-n InetPortNumber iscsiCxnLocalPort(7) | +-- r-n InetAddress iscsiCxnRemoteAddr(8) | +-- r-n InetPortNumber iscsiCxnRemotePort(9) | +-- r-n Unsigned32 iscsiCxnMaxRecvDataSegLength(1= 0) | +-- r-n Unsigned32 iscsiCxnMaxXmitDataSegLength(1= 1) | +-- r-n IscsiDigestMethod iscsiCxnHeaderIntegrity(12) | +-- r-n IscsiDigestMethod iscsiCxnDataIntegrity(13) | +-- r-n TruthValue iscsiCxnRecvMarker(14) | +-- r-n TruthValue iscsiCxnSendMarker(15) | +-- r-n Unsigned32 iscsiCxnVersionActive(16) Consider adding initial remote ip addr and port to this table. Editors: Not sure what the value in initial remote IP addr and port would = be - if they change wouldn't this be a new connection? | +--iscsiTarget(6) | | | | | +--iscsiTargetAttributesTable(1) | | | | | | | +--iscsiTargetAttributesEntry(1) [iscsiInstIndex,iscsiNodeIndex] | | | | | | | +-- r-n Counter32 iscsiTgtLoginFailures(1) | | | +-- r-n TimeStamp iscsiTgtLastFailureTime(2) | | | +-- r-n AutonomousType iscsiTgtLastFailureType(3) | | | +-- r-n IscsiName iscsiTgtLastIntrFailureName(4) | | | +-- r-n InetAddressType iscsiTgtLastIntrFailureAddrType(5) | | | +-- r-n InetAddress iscsiTgtLastIntrFailureAddr(6) | | +--iscsiTargetLoginStatsTable(2) | | | | | | | +--iscsiTargetLoginStatsEntry(1) [iscsiInstIndex,iscsiNodeIndex] | | | | | | | +-- r-n Counter32 iscsiTgtLoginAccepts(1) | | | +-- r-n Counter32 iscsiTgtLoginOtherFails(2) | | | +-- r-n Counter32 iscsiTgtLoginRedirects(3) | | | +-- r-n Counter32 iscsiTgtLoginAuthorizeFails(4) | | | +-- r-n Counter32 iscsiTgtLoginAuthenticateFails(5) | | | +-- r-n Counter32 iscsiTgtLoginNegotiateFails(6) | | +--iscsiTargetLogoutStatsTable(3) | | | | | +--iscsiTargetLogoutStatsEntry(1) [iscsiInstIndex,iscsiNodeIndex= ] | | | | | +-- r-n Counter32 iscsiTgtLogoutNormals(1) | | +-- r-n Counter32 iscsiTgtLogoutOthers(2) | +--iscsiTgtAuthorization(7) | | | | | +--iscsiTgtAuthAttributesTable(1) | | | | | +--iscsiTgtAuthAttributesEntry(1) [iscsiInstIndex,iscsiNodeIndex= ,iscsiTgtAuthIndex] | | | | | +-- --- Unsigned32 iscsiTgtAuthIndex(1) | | +-- rwn RowStatus iscsiTgtAuthRowStatus(2) | | +-- rwn RowPointer iscsiTgtAuthIdentity(3) | | +-- rwn StorageType iscsiTgtAuthStorageType(4) Additional Comments: There's no information in any of this regarding iSCSI discovery information. That would be potentially useful information, especially in the case of discovered targets that have no sessions. That could be an indication of a network problem of a mis-configuration. The type of discovery performed and the discovered targets could be put in there and provide this information. Editors: This MIB module currently represents only the initiators and targe= ts provided by the entity being queried. The remote objects do not appear = here and are part of someone else's entity. So if you had a target-only de= vice, it wouldn't have objects for the initiators connecting to it and vise= -versa. Since we don't currently support remote objects, adding this capability wou= ld be a significant new MIB development by the WG, rather than a fix given = the current review. End of File. --_000_8D3D17ACE214DC429325B2B98F3AE71208D3B568MX15Acorpemccom_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

<WG chair hat off= >

 

DLB> Global comment - please be careful about compliance wr= t anything that’s added.

&= nbsp;

DLB> I also noticed that the desc= ription of the V2 compliance statement needs to

DLB> be updated, as this is no longer the initial version of = the MIB module.

 

DLB> Some comments on the proposed courses of ac= tion:

 

 

  |  = +--iscsiPortal(2)

  |  |&nb= sp; |

  |  |  +--iscsi= PortalAttributesTable(1)

  |&nbs= p; |     |

 = |  |     +--iscsiPortalAttributesEntry(1) [iscsiI= nstIndex,iscsiPortalIndex]

 = ;

 

> Additionally, a list for authentication negotiation would be usef= ul,

> also.  There are five d= ifferent authentication methods defined by the

> original RFC 3720, and a few additional ones that have since= sprung up.

 <= /p>

DLB> That sounds potentially useful, although ...

 

DLB> ... of the five authentication methods defined in RFC 3720, o= nly the

DLB> required CHAP method = is in widespread use and the two SPKM methods

DLB> are being removed by the new iSCSI draft.  FWIW, the = Kerberos method

DLB> is considered= to be the “wrong approach” by the Kerberos experts<= /span>

DLB> because it’s not GSSAPI-based, and= there hasn’t been much interest

DLB> The method list woul= d have to be strings, because any additional

DLB> methods would be using private text keys based that are ba= sed on

DLB> reversed domain names.=

 

  |  |  +--iscsiSessionStatsTable(2)

  |  |  |  |<= /p>

  |  |  |  +--iscsiSessionStatsEntr= y(1) [iscsiInstIndex,iscsiSsnNodeIndex,iscsiSsnIndex]

=

  |  |  |     |

  |  |  |   &n= bsp; +-- r-n Counter32 iscsiSsnCmdPDUs(1)

  |  |  |     +-- r-n Counter32 isc= siSsnRspPDUs(2)

  |  | = ; |     +-- r-n Counter64 iscsiSsnTxDataOctets(3)<= /o:p>

  |  |  |   =   +-- r-n Counter64 iscsiSsnRxDataOctets(4)

  |  |  |     +-- r-n Counte= r32 iscsiSsnLCTxDataOctets(5)

  = |  |  |     +-- r-n Counter32 iscsiSsnLCRxDat= aOctets(6)

 

> Consider reporting missing PDU.

> Break down counters for data pdus in and out.<= /o:p>

> Add counter for async pdus in.

 

Editors: The above seem like good ideas – will anyone use these?=   Also, breaking down the existing counters might break current implem= entations.  We would likely have to create new ones.=

 

<= span style=3D'font-size:10.0pt;font-family:"Courier New";color:black'>DLB&g= t; Definitely do not remove or deprecate the existing counters.<= /span>

 

>= ; There's no information in any of this regarding iSCSI discovery

> information.  That would be potentia= lly useful information,

> especial= ly in the case of discovered targets that have no sessions.

> That could be an indication of a network proble= m of a

> mis-configuration.  = The type of discovery performed and the discovered

> targets could be put in there and provide this informati= on.

 

Since we= don’t currently support remote objects, adding this capability would= be a significant new MIB development by the WG, rather than a fix given th= e current review.

 

DLB> I agree with Mark - (with <WG chai= r hat off>) this feels like it’s

DLB> well beyond the scope of what the WG was chartered to do with = this MIB.

 

Thanks,
--David

 

F= rom: Mark Bakke [mailto:Mark_Bakke@DELL.com]
Sent: Wednesday,= July 11, 2012 9:06 AM
To: Storm (storm@ietf.org)
Cc: B= lack, David; prakashvn@hcl.com; ttalpey@microsoft.com; MacFaden, Michael (V= Mware)
Subject: FW: MIB Doctor Review for iSCSI MIB, proposed cha= nges, and list questions

 

 

Everyone,

 

We are in the process of updat= ing the iSCSI MIB module, to match the latest storm changes.  Mike Mac= Faden has also done a MIB Doctor review, which brought back a number of com= ments on things that are potentially missing from the original iSCSI MIB RF= C.

 

Prakash, David, Tom and I have been reviewing the MIB doctor requests.=   This message is intended to answer some of the MIB doctor comments a= s well as generate discussion on the list about possible changes.  We = intend to post another draft (-02) before the July 16th deadline= for the next round of discussion.

=  

Here is a brief summary.  The ful= l responses to comments are below.

·= ;     = ;    Several editorial change= s

·         A few new fields are added to objects that are either use= ful or were missed the first time around

&= middot;    = ;     More complex addit= ions that we believe will need a separate revision and may affect the objec= t model.  The latter changes would require support from those intendin= g to implement or use them.

 <= /o:p>

I will start separate discussion threads on a= few items:

·         Heartbeat counters for NOP-In and NOP-Out usage=

·         = TCP MIB correlation for sessions and connections

··         The previous draft of the new iSCSI MIB - http://www.ietf.or= g/id/draft-ietf-storm-iscsimib-01.txt

= ·   &nbs= p;     The initial MIB d= octor review - http://www.macfaden.com/ietf/iscsi-mib-1-reviewed.txt<= /p>

·=          An additional MIB doctor review with VMware engineers - http://macfaden.com/ietf/iscsi-m= ib-notes.txt

 

Detailed responses to MIB doctor review:

<= p class=3DMsoNormal> 

February 17, 2012 MIB DOCTOR Review: http://www.ietf.org/id/dra= ft-ietf-storm-iscsimib-01.txt 

 

Performed by Michael R. MacFaden= , VMware, Inc

According to htt= p://tools.ietf.org/html/rfc4181

 

This review only covers syntax, SMIv2= rules usage of the MIB module itself, not the draft.

=

Some of the things menti= oned below exist the prior version of the mib, not this update.<= /span>

 

1 boiler p= late - check

2. Narrative Sections - check

3. Security Considerations - check

4. IAN= A Considerations - missing editors’ note.

   Section 9 n= eeds the following verbiage to be added.

       = Editor's Note (to be removed prior to publication):  this draft

 &nb= sp;    makes no additional requests of the IANA. =

 

Editor= s: We will fix this.

 

5. No new namespaces

6. References section - check

7. c= opyright notice - check

8. Intellectual Property section – missing<= /o:p>

&nb= sp;

E= ditors: We will add the section:

 

          &nbs= p; Copyright (c) 2011 IETF Trust and the persons identified as

  &n= bsp;         authors of the code.&n= bsp; All rights reserved.

 

        &= nbsp;   Redistribution and use in source and binary forms, with o= r

=             without = modification, is permitted pursuant to, and subject

    &= nbsp;       to the license terms contained in= , the Simplified BSD

         &n= bsp;  License set forth in Section 4.c of the IETF Trust's Legal

 &= nbsp;          Provisions Rela= ting to IETF Documents=

         =    (http://trustee.ietf.org/license-info)."

 

 

9. This change updates existing mib rfc http://www.ietf.org/rfc/rfc4544= .txt - check

   Backward compatibility checks: (oids, object-ide= ntities, remained the same)

 

<= span style=3D'color:#1F497D'>Other items checked --

syntax check: smilint -l9 = - no errors

smicng : not run

spelling: Aspell --- no misspellings found.

URLs valida= ted: checked for valid, not-broken links:

      =        http://www.iana.org/assignments/protocol-numbers=

 

References in MIB module  not found in normative (sec 10.1)

IscsiTransp= ortProtocol TC ->  "RFC791, RFC1700

 

<= p class=3DMsoNormal> <= /p>

Editors: We will f= ix this.

 

 

enumerations: each element described <= /p>

  - IscsiDi= gestMethod

 

Editors: We had this in the description – is there som= ething else that needs to be added?

 

DiscontinuityTime is syntax: Tim= eStamp

All Counters: define their discontinuity timestamp.

 

Editors: We che= cked the descriptions in each of the Counter32 and Counter64 fields, and th= ey all reference a discontinuity timestamp.  Isn’t that enough?<= o:p>

 

Uncommon stuff:

1)  In IscsiPortalAttributesEntry has RowStatus as = second item in the conceptual row,

not after iscsiPortalStorageType.

 <= /o:p>

Edito= rs: We currently don’t put StorageType and RowStatus together in any = of our objects, and didn’t originally realize there was some traditio= n around this.  Changing numbering now would cause backward compatibil= ity problems, so we cannot make this change.

 

<= p class=3DMsoNormal>2) iscsiPortalRoles does = not have a DEFVAL when most others do in this conceptual table.<= /span>

iscsiPortalAdd= rType has def val of IPV4? when the iscsiPortalAddr has no default to go wi= th it?

 

Editors:  There= isn’t a reasonable DEFVAL for iscsiPortalRoles.  It has to be s= et when creating the row, so we will leave this one.<= /p>

 

3) iscsiNodeAttri= butesEntry  sez:

   An entry (row) containing mana

   vs= 'conceptual row' which is used inconsistently.

 

<= p class=3DMsoNormal>Editors: We will chang= e this description from:

<= span style=3D'color:#1F497D'> 

An entry (row) containing management information appl=
icable
 =
;       to a particular iSCSI node.

 

To

 

A conceptual row containing management information applicable<=
/o:p>
   =
;     to a particular iSCSI node.=

 <= /span>

 

4)  (= e.g. not created via this MIB).  vs MIB module. There is but one MIB a= s Dr Case would say.

 

Editors: We will fix this one.<= /b>

 =

5) 64 bit cou= nters with SNMPv1 support for 32 bit high/low? kinda

<= p class=3DMsoNormal>  iscsiSsnTxDataOcte= ts, iscsiSsnRxDataOctets, provides only low word: iscsiSsnLCTxDataOctets, i= scsiSsnLCRxDataOctets

  Compliance phrasing is a bit odd:

   = ;"A Low Capacity shadow object of iscsiSsnTxDataOctets

   =      for those systems that don't support Counter64.

 = ;   instead of 'for those systems which are accessible via SNMPv1= only'

 

Editors:  We will fix the wording for SNMPv1.  We don&= #8217;t see a reason to add objects for high octets.<= /p>

 

6) Notifications = are required to have a rate limited implementation by a description, <= /o:p>

 &n= bsp; yet the number of times the failure occurred   is not c= onveyed in the notifcation varbind list.

    iscsiTgtLoginFailu= re, iscsiIntrLoginFailure, iscsiInstSessionFailure

 

    To a= void sending an excessive number of notifications due

=

    =     to multiple errors counted, an SNMP agent implementing t= his

        notification SHOULD NOT send mo= re than 3 notifications of

        this typ= e in any 10-second time period."

 

Editors:  We believe that th= is is covered by the counter “iscsiTgtLoginFailures”:

&nb= sp;

iscsiTgtLoginFailure N=
OTIFICATION-TYPE
&n=
bsp;   OBJECTS {
        iscsiTgtLoginFailures,
   &n=
bsp;    iscsiTgtLastFailureType,
        isc= siTgtLastIntrFailureName,
        iscsiTgtLastIntrFailureAd=
drType,
  =
;      iscsiTgtLastIntrFailureAddr
    }

 

 = ;

The fo= llowing section addresses comments from the VMware iSCSI-MIB review:

&nbs= p;

=  

Notes from VMware ISCIS-MIB review = meeting

March 21, 2012

Attendees: Andy Banta, Kun Huang, Mike MacFaden

 

General comments:

1. Many object= s lacking REFERENCE clause or offer only vague references.

For those managed objects having a Reference clause, = nedd to fix up 'RFC cccc'

For example= : "RFC cccc, Section 7.5, Connection Timeout Management"

Example of vague reference:=

    REFERENCE

        "SCSI-MIB"= ;

 

 

Editors: OK, = we can update in the next draft.

=  

 

for an IETF standard m= ib module.

 

 

Editors: We can look for opportunities to clarify but don’t think = we want to go through and rewrite a lot.  If there are particular desc= riptions that cause confusion please bring them up.

 

 

Here's the comments by object in= the MIB module: draft-ietf-storm-iscsimib-01.txt

 

iscsiMibModule(= 1.3.6.1.2.1.142)

  |<= /span>

  +--iscsiNotifications(0)

  |  |

&n= bsp;

Consider adding port number.

 

 

Editors: LastFailu= rePortNumber would be easy enough to add.  Should we do an OrZero for = implementations that can’t get the port number?=

 

 

  |  +--iscsiIntrLoginF= ailure(2) [iscsiIntrLoginFailures,iscsiIntrLastFailureType,iscsiIntrLastTgt= FailureName,iscsiIntrLastTgtFailureAddrType,iscsiIntrLastTgtFailureAddr]

 

Can't determine if the failure is due to failure of the underlying= transport or not.

When transport is = TCP there should be some way to get to the TCP-MIB/TCP-ESTATS-MIB diagnosti= cs.

See notes on iscsiInstanceSsnErro= rStatsTable.

 =

Consider adding port number.  <= /p>

 

 = ;

Editors: Same as above.  On th= e failure, is it useful to have both local and remote addr and port number?=   Will the TCP MIB keep these connections around long enough to go ind= ex it on a failed connection?  If we add these fields, will someone us= e them?

 

 

&nb= sp; |  +--iscsiInstSessionFailure(3) [iscsiInstSsnFailures,iscsiInstLa= stSsnFailureType,iscsiInstLastSsnRmtNodeName]

 

 

Consider handling the event "Target Unmapped&q= uot;  by updatingiscsiInstLastSsnFailureType of a Session failure, as = well.

 

 

Edit= ors: FailureType is an OID pointing to a stat in iscsiInstSsnErrorStatsTabl= e, so we would need to add to this:

 

  &= nbsp; iscsiInstSsnTgtUnmappedErrors       Cou= nter32

 

Are there others that would be needed?

 

<= p class=3DMsoNormal> 

Consider addin= g summary notification in the case of larger scales (number of targets)

what about large scales, # of targets, = each target have a failure of similar sort.

 

 

Editors: Would such a notification really be u= sed?  If there was a large scale failure of many targets, we believe t= he administrator would see enough of the notifications to notice it as a la= rger problem.

 

 

<snip>

 

  |  |  +--iscsiInstanceSsnErrorSta= tsTable(2)

  |  | &nbs= p;   |

  |  |&nbs= p;    +--iscsiInstanceSsnErrorStatsEntry(1) [iscsiInstIndex]=

  |  |   &n= bsp;    |

  |&nbs= p; |        +-- r-n Counter32 iscsiInstS= snDigestErrors(1)

  |  |&nb= sp;       +-- r-n Counter32 iscsiInstSsnCxnTi= meoutErrors(2)

  |  | =        +-- r-n Counter32 iscsiInstSsnFormatEr= rors(3)

 

<= p class=3DMsoNormal>Related states for transport are not provided in this table= . Either a RowPointer

to another mib = module is needed or a generic transport counter to indicate failure

at that layer was detected by iscsiInstance.=

 

 

Editors= : If connection timeout errors are seen, wouldn’t the user check tran= sport connectivity via ping and other tools?  We are not sure that add= ing more objects here would add enough value.

 

&nb= sp;

Consider separate counters for HB vs d= ata timeouts.

Consider specific heart= beat no-op timeout error countes.

 

 =

Editors: We will start another thread for this di= scussion.  It does seem useful since most implementations use NOP for = keep-alive heartbeats.

=  

 

  |  +--iscsiPortal(2)

  |  |  |

&n= bsp; |  |  +--iscsiPortalAttributesTable(1)

=

  |  |     |

  |  |     +--iscsiPor= talAttributesEntry(1) [iscsiInstIndex,iscsiPortalIndex]

  |  |      &nbs= p; |

  |  |  &nbs= p;     +-- --- Unsigned32     =         iscsiPortalIndex(1)

  |  |     &nb= sp;  +-- rwn RowStatus         = ;     iscsiPortalRowStatus(2)

  |  |       = ; +-- rwn Bits          &= nbsp;        iscsiPortalRoles(3)

  |  |    &nbs= p;   +-- rwn InetAddressType      &= nbsp; iscsiPortalAddrType(4)

  |=   |        +-- rwn InetAddress = ;           iscsiPortalAd= dr(5)

  |  |  &nb= sp;     +-- rwn IscsiTransportProtocol iscsiPortalProto= col(6)

  |  |  &n= bsp;     +-- rwn Unsigned32    &nbs= p;        iscsiPortalMaxRecvDataSegLengt= h(7)

  |  |  &nbs= p;     +-- rwn IscsiDigestMethod    = ;  iscsiPortalPrimaryHdrDigest(8)

  |  |   &nbs= p;    +-- rwn IscsiDigestMethod     = ; iscsiPortalSecondaryHdrDigest(10)

&= nbsp; |  |        +-- rwn IscsiDige= stMethod      iscsiPortalSecondaryDataDigest(11)

  |  |   &nbs= p;    +-- rwn TruthValue      =        iscsiPortalRecvMarker(12)

  |  |     &nb= sp;  +-- rwn StorageType       &nbs= p;    iscsiPortalStorageType(13)

 

Digests are negotia= ted and implementations may have additional levels (tertiary, quaternary)

as well as constraints that are not mo= delled here.

 

 

Editors: There’s only one standardized digest method currently = in use (CRC32C) that we know of.  Are there implementations that exten= d this beyond two?

&nbs= p;

 

Digests can also be configured in iscsiNodeAttributesTable. (Is t= here a prececence between node and portal?)

 

 <= /span>

Editors: There is no digests field curr= ently in NodeAttributesTable, so Portal is the only place to configure it.<= o:p>

 

 

Need to be = able to set/show port number as well as iscsiPortalAddr.<= /p>

 

 = ;

Editors: We can add this one.<= /o:p>

 

 

Regarding iscsi= CxnRecvMarker, iscsiCxnSendMarker these are to be  deprecated and are = redundant in session and connection.

=  

 

Editors: These will be removed.  The V2 object gro= ups in the draft do not contain the deprecated objects.

        &nbs= p;            <= /o:p>

 

** note: I Checked with INET-ADDRESS-MIB about iscsiPortalAddrType, if s= et to 16

    &nbs= p; dns(16)     A DNS domain name as defined by the=

       = ; InetAddressDNS textual convention.

=       Then iscsiPortalAddr can be a dns hostname.<= o:p>

 

Appears the MIB Portal Attributes and Node Atributes are sort os a=

mish-mash or Node, Lhba, Phba, vario= us Portal properties.

 

 

Editors:  Not sure we understand this one – the MIB follows= iSCSI node and portal definitions for portals and nodes.  HBAs are ou= tside the scope of the MIB and of iSCSI.

 

 

Using a table rather than Primary and Second= ary would be the right

approach for H= eader and Data digests, since the whole point of these

negotiations is to provide a list of what each side is wi= lling to

settle on.=

 

&nbs= p;

Editors: Technically, yes, but pra= ctically it seems over-complicated.

 

 

Additionally, a list for authentication negotiation would= be useful,

also.  There are fiv= e different authentication methods defined by the

original RFC 3720, and a few additional ones that have since s= prung

up.

 

 

Editors: Isn’t the list of authorized = entities sufficient, since the methods are included by reference?]

 

 

There's also the idea of m= utual authentication, where each side

verfies the identity of the other, rathern than just a target

authenticatiing a host.

 

 

Editors: Is this comment referring to th= e iscsiSsnAuthIdentity?  We do see that this is just one per session, = and we didn’t identify it as an initiator or target identity (most pe= ople likely assumed initiator).

 

We’d need t= o change this name to iscsiSsnAuthIntrIdentity and add iscsiSsnAuthTgtIdent= ity to show both identities in a session where this is used.

 

 

Additional useful = information at the Portal level might be at least

some identification of what type of initiator it is, and some<= o:p>

identifying information about it. May= be not the level of detail you'll

fin= d in IMA_PHBA_PROPERTIES, but the model, description and version.

 

Editors: this seems useful for troubleshooting.  We can add someth= ing similar to iscsiInstDescr:

 

iscsiPortalDescr O= BJECT-TYPE

   = ; SYNTAX        SnmpAdminString

    MAX-ACCESS &= nbsp;  read-only

 =    STATUS        current<= /o:p>

    DESCRIPTION

     =    "A UTF-8 string, determined by the implementation to=

     &n= bsp;  describe the iSCSI portal.  When only a single instance

     &= nbsp;  is present, this object may be set to the zero-length

      &= nbsp; string; with multiple iSCSI portals, it may be used in

       = an implementation-dependent manner to describe the <= /p>

        respect= ive portal, and could include information such as

=

        HBA model,= description and version or software driver and

        version.&quo= t;

 <= /b>

I don’t think that we’d want to tr= y to structure it more than just a string.

 

 

<snip>

 

  |  = +--iscsiNode(5)

  |  | = ; |

  |  |  +--iscsiNo= deAttributesTable(1)

  |  = |     |

  |&= nbsp; |     +--iscsiNodeAttributesEntry(1) [iscsiInstIn= dex,iscsiNodeIndex]

  |  = |        |

  |  |        +-- ---= Unsigned32      iscsiNodeIndex(1)

  |  |      =   +-- r-n IscsiName       iscsiNodeName(= 2)

  |  |   =      +-- r-n SnmpAdminString iscsiNodeAlias(3)

  |  |     = ;   +-- r-n Bits        &= nbsp;   iscsiNodeRoles(4)

&= nbsp; |  |        +-- r-n RowPointe= r      iscsiNodeTransportType(5)=

  |  |      &n= bsp; +-- r-n TruthValue      iscsiNodeInitialR2T(6= )

  |  |   &= nbsp;    +-- rwn TruthValue      is= csiNodeImmediateData(7)

  | = ; |        +-- rwn Unsigned32  = ;    iscsiNodeMaxOutstandingR2T(8)

  |  |        +--= rwn Unsigned32      iscsiNodeFirstBurstLength(9)<= o:p>

  |  |    &n= bsp;   +-- rwn Unsigned32      iscs= iNodeMaxBurstLength(10)

  | = ; |        +-- rwn Unsigned32  = ;    iscsiNodeMaxConnections(11)

  |  |        +-- r= wn TruthValue      iscsiNodeDataSequenceInOrder(12= )

  |  |   &= nbsp;    +-- rwn TruthValue      is= csiNodeDataPDUInOrder(13)

  |&nb= sp; |        +-- rwn Unsigned32 &nb= sp;    iscsiNodeDefaultTime2Wait(14)

  |  |  &nbs= p;     +-- rwn Unsigned32     = iscsiNodeErrorRecoveryLevel(16)

= &nbs= p; |  |        +-- r-n TimeStamp&nb= sp;      iscsiNodeDiscontinuityTime(17)=

  |  |     &= nbsp;  +-- rwn StorageType     iscsiNodeStorageTyp= e(18)

 

Digests as found in scsiPortalAttributesTable, may be provisi= oned at this level.

 

 

Editors: Is there a need to provision digest at this level via the MIB= module?

 =

 

 &n= bsp;|  +--iscsiInitiator(8)

= &nbs= p; |  |  |

  |  = |  +--iscsiInitiatorAttributesTable(1)

  |  |  |  |

  |  |  |  +--iscsiInitiatorAttributesEntry(1) [is= csiInstIndex,iscsiNodeIndex]

  |=   |  |     |

  |  |  |     +-- r-n Counter32&nb= sp;      iscsiIntrLoginFailures(1)

  |  |  |     +--= r-n TimeStamp       iscsiIntrLastFailureTime= (2)

  |  |  | &nb= sp;   +-- r-n AutonomousType  iscsiIntrLastFailureType(3)

  |  |  |  &nb= sp;  +-- r-n IscsiName       iscsiIntrLa= stTgtFailureName(4)

  |  = |  |     +-- r-n InetAddressType iscsiIntrLastTgtF= ailureAddrType(5)

  |  |&nb= sp; |     +-- r-n InetAddress     i= scsiIntrLastTgtFailureAddr(6)

&n= bsp;

No port number provided.

 

=  

Editors: We will add iscsiInt= rLastTgtFailurePort

 

 

  |  |  |  |<= /p>

  |  |  |  +--iscsiInitiatorLoginSt= atsEntry(1) [iscsiInstIndex,iscsiNodeIndex]

  |  |  |     |

  |  |  |     +--= r-n Counter32 iscsiIntrLoginAcceptRsps(1)

  |  |  |     +-- r-n Counter32 is= csiIntrLoginOtherFailRsps(2)

  |=   |  |     +-- r-n Counter32 iscsiIntrLoginRe= directRsps(3)

  |  |  = |     +-- r-n Counter32 iscsiIntrLoginAuthFailRsps(4)

  |  |  |  &n= bsp;  +-- r-n Counter32 iscsiIntrLoginAuthenticateFails(5)<= /span>

  |  |  |    = +-- r-n Counter32 iscsiIntrLoginNegotiateFails(6)

 

No way to get t= o transport layer (tcp, etc) related errors not shown here or provided thro= ugh RowPointer/etc.

 

 

Editors: We are not sure that this will add enough value.

 

=  

  |  |  +--iscs= iInitiatorLogoutStatsTable(3)

  = |  |     |

&= nbsp; |  |     +--iscsiInitiatorLogoutStatsEntry(1= ) [iscsiInstIndex,iscsiNodeIndex]

&nb= sp; |  |        |=

  |  |      &n= bsp; +-- r-n Counter32 iscsiIntrLogoutNormals(1)

  |  |        +-- = r-n Counter32 iscsiIntrLogoutOthers(2)

The counter iscsiIntrLogoutO= thers does not cover cases where no ack is returned (timeout case) due=

to failure of transport to deliver logout= ack.

 

 

Editors: Ad= ding a timeout counter for this seems to make sense.<= /p>

         &= nbsp;           &nbs= p;  

 

  |  +--iscsiIntrAuthorization(9)

  |  |  |

  |  |  +--iscsiIntrAuthAttributesT= able(1)

  |  |  &= nbsp;  |

  |  | &= nbsp;   +--iscsiIntrAuthAttributesEntry(1) [iscsiInstIndex,iscsiN= odeIndex,iscsiIntrAuthIndex]

  |=   |        |

<= p class=3DMsoNormal>  |  |        = +-- --- Unsigned32  iscsiIntrAuthIndex(1)

  |  |        +-- rw= n RowStatus   iscsiIntrAuthRowStatus(2)

  |  |        +--= rwn RowPointer  iscsiIntrAuthIdentity(3)

  |  |        +-- rw= n StorageType iscsiIntrAuthStorageType(4)

 

The reference for iscsiIn= trAuthIdentity is too vague. Only provides the RFC?:

<= p class=3DMsoNormal>REFERENCE

  = ;      "IPS-AUTH MIB, RFC 4545"

 

Editors: We will fix this.

&= nbsp;

  |  +--iscsiSe= ssion(10)

  |  |  |

  |  |  +--iscsiSessionA= ttributesTable(1)

  |  |&nb= sp; |  |

  |  |  = |  +--iscsiSessionAttributesEntry(1) [iscsiInstIndex,iscsiSsnNodeIndex= ,iscsiSsnIndex]

  |  | = ; |     |

  = |  |  |     +-- --- Unsigned32  &nb= sp;   iscsiSsnNodeIndex(1)

=   |  |  |     +-- --- Unsigned32 &n= bsp;    iscsiSsnIndex(2)

  |  |  |     +-- r-n Enumeration&nbs= p;    iscsiSsnDirection(3)

  |  |  |     +-- r-n IscsiName&nbs= p;      iscsiSsnInitiatorName(4)=

  |  |  |     +-- r= -n IscsiName       iscsiSsnTargetName(5)=

  |  |  |   = ;  +-- r-n Unsigned32      iscsiSsnTSIH(6)

  |  |  |  &nb= sp;  +-- r-n OctetString     iscsiSsnISID(7)<= /o:p>

  |  |  |   =   +-- r-n SnmpAdminString iscsiSsnInitiatorAlias(8)<= /p>

  |  |  |     +-- r-= n SnmpAdminString iscsiSsnTargetAlias(9)

  |  |  |     +-- r-n TruthValue&nbs= p;     iscsiSsnInitialR2T(10)

  |  |  |     +-- r-n Truth= Value      iscsiSsnImmediateData(11)

  |  |  |     += -- r-n Enumeration     iscsiSsnType(12)

  |  |  |     +--= r-n Unsigned32      iscsiSsnMaxOutstandingR2T(13)=

  |  |  |  =    +-- r-n Unsigned32      iscsiSsnFirst= BurstLength(14)

  |  | = ; |     +-- r-n Unsigned32     = ; iscsiSsnMaxBurstLength(15)

  |=   |  |     +-- r-n Gauge32   &= nbsp;     iscsiSsnConnectionNumber(16)

  |  |  |     +-- = r-n RowPointer      iscsiSsnAuthIdentity(17)<= /o:p>

  |  |  |   =   +-- r-n TruthValue      iscsiSsnDataSequenc= eInOrder(18)

  |  |  |=      +-- r-n TruthValue      i= scsiSsnDataPDUInOrder(19)

  |&nb= sp; |  |     +-- r-n Unsigned32   &= nbsp;  iscsiSsnErrorRecoveryLevel(20)

  |  |  |     +-- r-n TimeStamp&nb= sp;      iscsiSsnDiscontinuityTime(21)<= /span>

 

Con= sider reporting the digest negotiated for this session.

Consider reporting the error-recovery-level (ERL).<= /o:p>

Consider reporting type(?) negotiated.

 

  |  |  +--iscsiSessionStatsTable(2)<= /p>

  |  |  |  |

<= p class=3DMsoNormal>  |  |  |  +--iscsiSessionStatsEntry(1)= [iscsiInstIndex,iscsiSsnNodeIndex,iscsiSsnIndex]

  |  |  |     |<= /span>

  |  |  |    = +-- r-n Counter32 iscsiSsnCmdPDUs(1)

  |  |  |     +-- r-n Counter32 iscsiSs= nRspPDUs(2)

  |  |  |&= nbsp;    +-- r-n Counter64 iscsiSsnTxDataOctets(3)

  |  |  |   &nbs= p; +-- r-n Counter64 iscsiSsnRxDataOctets(4)

  |  |  |     +-- r-n Counter32= iscsiSsnLCTxDataOctets(5)

  |&n= bsp; |  |     +-- r-n Counter32 iscsiSsnLCRxDataOc= tets(6)

 

<= p class=3DMsoNormal>Consider reporting missing PDU.

Break down counters for data pdus in and out.<= /p>

Add counter for async pdus in.

 

 

Editors: The above seem like good ideas = – will anyone use these?  Also, breaking down the existing count= ers might break current implementations.  We would likely have to crea= te new ones.

 

 

<= span style=3D'font-size:10.0pt;font-family:"Courier New";color:black'> = ; |  |  +--iscsiSessionCxnErrorStatsTable(3)

  |  |     |

  |  |     +--iscsiSe= ssionCxnErrorStatsEntry(1) [iscsiInstIndex,iscsiSsnNodeIndex,iscsiSsnIndex]=

  |  |   &n= bsp;    |

  |&nbs= p; |        +-- r-n Counter32 iscsiSsnCx= nDigestErrors(1)

  |  |&nbs= p;       +-- r-n Counter32 iscsiSsnCxnTimeout= Errors(2)

 

Description should discuss when these counters are most l= ikely provided such as when the error-recovery-level

<= p class=3DMsoNormal>is 1 or 2.

 = ;

 

Editors: We will update the descriptions.

 

 =

  |  +--iscsiConnection(11)

  |     |<= /o:p>

  |     +--iscsiC= onnectionAttributesTable(1)

  |&= nbsp;       |

  |        +--iscsiConnect= ionAttributesEntry(1) [iscsiInstIndex,iscsiSsnNodeIndex,iscsiSsnIndex,iscsi= CxnIndex]

  |   &= nbsp;       |

  |         &nbs= p; +-- --- Unsigned32         =     iscsiCxnIndex(1)

&= nbsp; |           +-- r-n= Unsigned32          &nbs= p;  iscsiCxnCid(2)

  | = ;          +-- r-n Enumeration=             iscsiCxn= State(3)

  |   &n= bsp;       +-- r-n InetAddressType  = ;      iscsiCxnAddrType(4)

  |           +-= - r-n IscsiTransportProtocol iscsiCxnProtocol(6)

  |         &= nbsp; +-- r-n InetPortNumber        = ; iscsiCxnLocalPort(7)

  | =           +-- r-n InetAddress&= nbsp;           iscsiCxnR= emoteAddr(8)

  |  &nbs= p;        +-- r-n InetPortNumber &n= bsp;       iscsiCxnRemotePort(9)

  |       = ;    +-- r-n Unsigned32      &= nbsp;      iscsiCxnMaxRecvDataSegLength(10)

  |      = ;     +-- r-n Unsigned32     &= nbsp;       iscsiCxnMaxXmitDataSegLength(11)<= o:p>

 |     =       +-- r-n IscsiDigestMethod   &= nbsp;  iscsiCxnHeaderIntegrity(12)

  |           +--= r-n IscsiDigestMethod      iscsiCxnDataIntegrity(= 13)

  |    &= nbsp;      +-- r-n TruthValue   &nb= sp;         iscsiCxnRecvMarker(14)<= o:p>

  |     = ;      +-- r-n TruthValue    &= nbsp;        iscsiCxnSendMarker(15)=

  |     &nb= sp;     +-- r-n Unsigned32     = ;        iscsiCxnVersionActive(16)<= /o:p>

 

Consider adding initial remote  ip addr and port to this table.

 

 

Editors:  Not s= ure what the value in initial remote IP addr and port would be – if t= hey change wouldn’t this be a new connection?

 

 =

  |  +--iscsiTarget(6)

  |  |  |

  |  |  +--iscsiTargetAttributesTable(1)

  |  |  |  |<= /o:p>

  |  |  |  +--iscsiTar= getAttributesEntry(1) [iscsiInstIndex,iscsiNodeIndex]

=

  |  |  |     |

  |  |  |   &n= bsp; +-- r-n Counter32       iscsiTgtLoginFai= lures(1)

  |  |  |&nbs= p;    +-- r-n TimeStamp       = iscsiTgtLastFailureTime(2)

  |&n= bsp; |  |     +-- r-n AutonomousType  iscsiTg= tLastFailureType(3)

  |  = |  |     +-- r-n IscsiName    =    iscsiTgtLastIntrFailureName(4)

  |  |  |     +-- r-n InetAddre= ssType iscsiTgtLastIntrFailureAddrType(5)

  |  |  |     +-- r-n InetAddress&n= bsp;    iscsiTgtLastIntrFailureAddr(6)

=

 

  <= /o:p>

  |  |  +--iscsiTarget= LoginStatsTable(2)

  |  |&n= bsp; |  |

  |  | = |  +--iscsiTargetLoginStatsEntry(1) [iscsiInstIndex,iscsiNodeIndex]

  |  |  |  &n= bsp;  |

  |  |  |=      +-- r-n Counter32 iscsiTgtLoginAccepts(1)

  |  |  |   &nb= sp; +-- r-n Counter32 iscsiTgtLoginOtherFails(2)

  |  |  |     +-- r-n Counte= r32 iscsiTgtLoginRedirects(3)

  = |  |  |     +-- r-n Counter32 iscsiTgtLoginAu= thorizeFails(4)

  |  | = ; |     +-- r-n Counter32 iscsiTgtLoginAuthenticateFail= s(5)

  |  |  | &n= bsp;   +-- r-n Counter32 iscsiTgtLoginNegotiateFails(6)

 

&= nbsp; |  |  +--iscsiTargetLogoutStatsTable(3)

  |  |     |

  |  |     +--iscsiT= argetLogoutStatsEntry(1) [iscsiInstIndex,iscsiNodeIndex]<= /p>

  |  |      &nb= sp; |

  |  |  &nb= sp;     +-- r-n Counter32 iscsiTgtLogoutNormals(1)=

  |  |    &= nbsp;   +-- r-n Counter32 iscsiTgtLogoutOthers(2)

 

  = |  +--iscsiTgtAuthorization(7)

&= nbsp; |  |  |

  | = ; |  +--iscsiTgtAuthAttributesTable(1)

  |  |     |

  |  |     &= nbsp;  |

  |  | &= nbsp;      +-- --- Unsigned32  iscsiTgtAuthIn= dex(1)

  |  |  &n= bsp;     +-- rwn RowStatus   iscsiTgtAuthRowS= tatus(2)

  |  |  =       +-- rwn RowPointer  iscsiTgtAuthIdentit= y(3)

  |  |  &nbs= p;     +-- rwn StorageType iscsiTgtAuthStorageType(4)

 

 

Additional Comments:<= o:p>

 

There's no information in any of this regarding iSCSI discovery

information.  That would be potent= ially useful information,

especially = in the case of discovered targets that have no sessions.<= /p>

That could be an indication of a network problem of a

mis-configuration.  The type of d= iscovery performed and the discovered

targets could be put in there and provide this information.

 

E= ditors: This MIB module currently represents only the initiators and target= s provided by the entity being queried.  The remote objects do not app= ear here and are part of someone else’s entity.  So if you had a= target-only device, it wouldn’t have objects for the initiators conn= ecting to it and vise-versa.

=  

Since we don’t= currently support remote objects, adding this capability would be a signif= icant new MIB development by the WG, rather than a fix given the current re= view.

 

 

 <= /o:p>

End of File.

 

 

= --_000_8D3D17ACE214DC429325B2B98F3AE71208D3B568MX15Acorpemccom_-- From Mark_Bakke@DELL.com Fri Jul 13 15:54:15 2012 Return-Path: X-Original-To: storm@ietfa.amsl.com Delivered-To: storm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 62CA511E80CB for ; Fri, 13 Jul 2012 15:54:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.097 X-Spam-Level: X-Spam-Status: No, score=-106.097 tagged_above=-999 required=5 tests=[AWL=0.501, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Eo0nX8bxGgJC for ; Fri, 13 Jul 2012 15:54:13 -0700 (PDT) Received: from aussmtpmrkps320.us.dell.com (aussmtpmrkps320.us.dell.com [143.166.224.254]) by ietfa.amsl.com (Postfix) with ESMTP id 506B911E8116 for ; Fri, 13 Jul 2012 15:54:12 -0700 (PDT) X-Loopcount0: from 64.238.244.148 X-IronPort-AV: E=Sophos;i="4.77,583,1336366800"; d="scan'208,217";a="537322445" Received: from mail.compellent.com ([64.238.244.148]) by aussmtpmrkps320.us.dell.com with ESMTP; 13 Jul 2012 17:54:50 -0500 From: Mark Bakke To: "Storm (storm@ietf.org)" Date: Fri, 13 Jul 2012 17:54:48 -0500 Thread-Topic: iSCSI MIB: Matching connections to the TCP/TCP-ESTATS MIBs Thread-Index: Ac1fgTiIrOMUDrA1QV2yDNd7eQgXvA== Message-ID: <975552A94CBC0F4DA60ED7B36C949CBA03F19A9137@shandy.Beer.Town> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: multipart/alternative; boundary="_000_975552A94CBC0F4DA60ED7B36C949CBA03F19A9137shandyBeerTow_" MIME-Version: 1.0 Cc: "mrm@vmware.com" , "prakashvn@hcl.com" Subject: [storm] iSCSI MIB: Matching connections to the TCP/TCP-ESTATS MIBs X-BeenThere: storm@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Storage Maintenance WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 13 Jul 2012 22:54:15 -0000 --_000_975552A94CBC0F4DA60ED7B36C949CBA03F19A9137shandyBeerTow_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Fellow iSCSI MIB enthusiasts, During our latest review, one suggestion was to provide better troubleshoot= ing connectivity with the TCP MIB module. I have a few questions for the l= ist, below. >From MIB Doctor Review: iscsiMibModule(1.3.6.1.2.1.142) | +--iscsiNotifications(0) | | | +--iscsiTgtLoginFailure(1) [iscsiTgtLoginFailures,iscsiTgtLastFailureT= ype,iscsiTgtLastIntrFailureName,iscsiTgtLastIntrFailureAddrType,iscsiTgtLas= tIntrFailureAddr] Consider adding port number. | +--iscsiIntrLoginFailure(2) [iscsiIntrLoginFailures,iscsiIntrLastFailu= reType,iscsiIntrLastTgtFailureName,iscsiIntrLastTgtFailureAddrType,iscsiInt= rLastTgtFailureAddr] Can't determine if the failure is due to failure of the underlying transpor= t or not. When transport is TCP there should be some way to get to the TCP-MIB/TCP-ES= TATS-MIB diagnostics. See notes on iscsiInstanceSsnErrorStatsTable. Consider adding port number. [Mark] Although we can navigate to the TCP-MIB for connections that are al= ive (these provide local and remote IP addresses and port numbers, for the = LastFailures for initiator and target entries, adding the port number as su= ggested would allow these to be potentially matched with these MIBs. The question to the list is: 1. Will this provide better troubleshooting capabilities for failed c= onnections? 2. Will implementations be likely to provide and use these fields? Thanks, Mark --_000_975552A94CBC0F4DA60ED7B36C949CBA03F19A9137shandyBeerTow_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Fellow iSCSI MIB= enthusiasts,

 

During our latest review, one suggestion was to provide bet= ter troubleshooting connectivity with the TCP MIB module.  I have a fe= w questions for the list, below.

&n= bsp;

From MIB Doctor Review:

 

iscsiMibModule(1.3= .6.1.2.1.142)

  |

  +--iscsiNotifications(0)

  |  |

&= nbsp; |  +--iscsiTgtLoginFailure(1) [iscsiTgtLoginFailures,iscsiTgtLas= tFailureType,iscsiTgtLastIntrFailureName,iscsiTgtLastIntrFailureAddrType,is= csiTgtLastIntrFailureAddr]

 = ;

Consider adding port number.<= /span>

 

&n= bsp; |  +--iscsiIntrLoginFailure(2) [iscsiIntrLoginFailures,iscsi= IntrLastFailureType,iscsiIntrLastTgtFailureName,iscsiIntrLastTgtFailureAddr= Type,iscsiIntrLastTgtFailureAddr]

&nb= sp;

Can't determine if the failure i= s due to failure of the underlying transport or not.

<= p class=3DMsoNormal>When transport is TCP there should be some way to get to th= e TCP-MIB/TCP-ESTATS-MIB diagnostics.

See notes on iscsiInstanceSsnErrorStatsTable.

 

Consider adding port= number. 

 =

[Mark]  Although we can navigate to the TCP-M= IB for connections that are alive (these provide local and remote IP addres= ses and port numbers, for the LastFailures for initiator and target entries= , adding the port number as suggested would allow these to be potentially m= atched with these MIBs.

 

The question to the list is:

= 1.       Will this provide better troubleshooting capabilities for failed= connections?

2.  &nbs= p;    Will implementations be likely= to provide and use these fields?

&= nbsp;

Thanks,

 

Mark

 

 

= --_000_975552A94CBC0F4DA60ED7B36C949CBA03F19A9137shandyBeerTow_-- From Mark_Bakke@DELL.com Fri Jul 13 15:59:05 2012 Return-Path: X-Original-To: storm@ietfa.amsl.com Delivered-To: storm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BE86B11E80CB for ; Fri, 13 Jul 2012 15:59:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.264 X-Spam-Level: X-Spam-Status: No, score=-106.264 tagged_above=-999 required=5 tests=[AWL=0.334, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id nZOj91wPKScT for ; Fri, 13 Jul 2012 15:59:04 -0700 (PDT) Received: from aussmtpmrkpc120.us.dell.com (aussmtpmrkpc120.us.dell.com [143.166.82.159]) by ietfa.amsl.com (Postfix) with ESMTP id 7199111E8088 for ; Fri, 13 Jul 2012 15:59:04 -0700 (PDT) X-Loopcount0: from 64.238.244.148 X-IronPort-AV: E=Sophos;i="4.77,583,1336366800"; d="scan'208,217";a="508191242" Received: from mail.compellent.com ([64.238.244.148]) by aussmtpmrkpc120.us.dell.com with ESMTP; 13 Jul 2012 17:59:41 -0500 From: Mark Bakke To: "Storm (storm@ietf.org)" Date: Fri, 13 Jul 2012 17:59:39 -0500 Thread-Topic: iSCSI MIB: Questions on session details Thread-Index: Ac1fgVc2zFVnq+O0ShO1HEnDUAdIRg== Message-ID: <975552A94CBC0F4DA60ED7B36C949CBA03F19A913F@shandy.Beer.Town> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: multipart/alternative; boundary="_000_975552A94CBC0F4DA60ED7B36C949CBA03F19A913FshandyBeerTow_" MIME-Version: 1.0 Cc: "mrm@vmware.com" , "prakashvn@hcl.com" Subject: [storm] iSCSI MIB: Questions on session details X-BeenThere: storm@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Storage Maintenance WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 13 Jul 2012 22:59:05 -0000 --_000_975552A94CBC0F4DA60ED7B36C949CBA03F19A913FshandyBeerTow_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Fellow iSCSI MIB fans, One more question for the list. Another MIB review suggestion was to add m= ore transport information: | | +--iscsiInstanceSsnErrorStatsTable(2) | | | | | +--iscsiInstanceSsnErrorStatsEntry(1) [iscsiInstIndex] | | | | | +-- r-n Counter32 iscsiInstSsnDigestErrors(1) | | +-- r-n Counter32 iscsiInstSsnCxnTimeoutErrors(2) | | +-- r-n Counter32 iscsiInstSsnFormatErrors(3) Related states for transport are not provided in this table. Either a RowPo= inter to another mib module is needed or a generic transport counter to indicate = failure at that layer was detected by iscsiInstance. [Mark] This table was originally provided as just an error count table augm= enting the whole iSCSI instance, and simply counts failures. We (MIB autho= rs) don't see a way for session-level details to fit into this purpose. If= anyone disagrees or sees a better way to do this, please speak up. Thanks, Mark --_000_975552A94CBC0F4DA60ED7B36C949CBA03F19A913FshandyBeerTow_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Fellow iSCSI MIB= fans,

 

One more question for the list.  Another MIB review suggestio= n was to add more transport information:

 

  |  |  +--iscsiInsta= nceSsnErrorStatsTable(2)

  |&nbs= p; |     |

 = |  |     +--iscsiInstanceSsnErrorStatsEntry(1) [i= scsiInstIndex]

  |  | =        |

 = ; |  |        +-- r-n Counter32 isc= siInstSsnCxnTimeoutErrors(2)

  |=   |        +-- r-n Counter32 iscsiI= nstSsnFormatErrors(3)

 

Related states for transport are not provided= in this table. Either a RowPointer

t= o another mib module is needed or a generic transport counter to indicate f= ailure

at that layer was detected by = iscsiInstance.

 

[Mark] This table was originally provided as just an error cou= nt table augmenting the whole iSCSI instance, and simply counts failures.&n= bsp; We (MIB authors) don’t see a way for session-level details to fi= t into this purpose.  If anyone disagrees or sees a better way to do t= his, please speak up.

Thanks,=

 

Mark=

= --_000_975552A94CBC0F4DA60ED7B36C949CBA03F19A913FshandyBeerTow_-- From cbm@chadalapaka.com Sat Jul 14 15:30:06 2012 Return-Path: X-Original-To: storm@ietfa.amsl.com Delivered-To: storm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1F42821F852E for ; Sat, 14 Jul 2012 15:30:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.998 X-Spam-Level: X-Spam-Status: No, score=-2.998 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_35=0.6, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8EzckLBwUgfl for ; Sat, 14 Jul 2012 15:30:02 -0700 (PDT) Received: from co1outboundpool.messaging.microsoft.com (co1ehsobe002.messaging.microsoft.com [216.32.180.185]) by ietfa.amsl.com (Postfix) with ESMTP id 2EEDA21F84FF for ; Sat, 14 Jul 2012 15:30:01 -0700 (PDT) Received: from mail151-co1-R.bigfish.com (10.243.78.227) by CO1EHSOBE010.bigfish.com (10.243.66.73) with Microsoft SMTP Server id 14.1.225.23; Sat, 14 Jul 2012 22:30:41 +0000 Received: from mail151-co1 (localhost [127.0.0.1]) by mail151-co1-R.bigfish.com (Postfix) with ESMTP id 06AF5480157 for ; Sat, 14 Jul 2012 22:30:41 +0000 (UTC) X-Forefront-Antispam-Report: CIP:157.56.234.133; KIP:(null); UIP:(null); IPV:NLI; H:SN2PRD0610HT005.namprd06.prod.outlook.com; RD:none; EFVD:NLI X-SpamScore: -35 X-BigFish: PS-35(zz9371Ic85fh103dK1b0bM1a09J14ffIzz1202hzz1033IL8275bh8275dh5eeeKz2fh2a8h668h839hd25hf0ah107ah) Received-SPF: pass (mail151-co1: domain of chadalapaka.com designates 157.56.234.133 as permitted sender) client-ip=157.56.234.133; envelope-from=cbm@chadalapaka.com; helo=SN2PRD0610HT005.namprd06.prod.outlook.com ; .outlook.com ; Received: from mail151-co1 (localhost.localdomain [127.0.0.1]) by mail151-co1 (MessageSwitch) id 1342305037898571_28149; Sat, 14 Jul 2012 22:30:37 +0000 (UTC) Received: from CO1EHSMHS007.bigfish.com (unknown [10.243.78.251]) by mail151-co1.bigfish.com (Postfix) with ESMTP id CF75420059 for ; Sat, 14 Jul 2012 22:30:37 +0000 (UTC) Received: from SN2PRD0610HT005.namprd06.prod.outlook.com (157.56.234.133) by CO1EHSMHS007.bigfish.com (10.243.66.17) with Microsoft SMTP Server (TLS) id 14.1.225.23; Sat, 14 Jul 2012 22:30:37 +0000 Received: from SN2PRD0610MB372.namprd06.prod.outlook.com ([169.254.4.8]) by SN2PRD0610HT005.namprd06.prod.outlook.com ([10.255.117.40]) with mapi id 14.16.0164.004; Sat, 14 Jul 2012 22:30:36 +0000 From: Mallikarjun Chadalapaka To: "storm@ietf.org" Thread-Topic: iSCSI -06 candidate-2 version Thread-Index: Ac1iD+mthi+syxhOQ6S3Cs1ilP7ycg== Date: Sat, 14 Jul 2012 22:30:37 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [76.22.17.63] Content-Type: multipart/alternative; boundary="_000_E160851FCED17643AE5F53B5D4D0783A3498F1F2SN2PRD0610MB372_" MIME-Version: 1.0 X-OriginatorOrg: chadalapaka.com Subject: Re: [storm] iSCSI -06 candidate-2 version X-BeenThere: storm@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Storage Maintenance WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 14 Jul 2012 22:30:06 -0000 --_000_E160851FCED17643AE5F53B5D4D0783A3498F1F2SN2PRD0610MB372_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi all, I have just published the "candidate-2" revision for iSCSI Consolidated dr= aft -06 at the same URL. http://www.chadalapaka.com/Documents/draft-ietf-storm-iscsi-cons-06.pdf I plan to submit this tomorrow for publication. FYI. Mallikarjun From: storm-bounces@ietf.org [mailto:storm-bounces@ietf.org] On Behalf Of M= allikarjun Chadalapaka Sent: Sunday, July 01, 2012 4:01 PM To: storm@ietf.org Subject: [storm] iSCSI -06 candidate-1 version Hi All, Since the -05 version, iSCSI Consolidated draft received invaluable feedbac= k from a few folks, most notably from our AD Martin Stiemerling and Rob Ell= iott. Many thanks to both of them. I have now incorporated all the feedback - most of it is editorial/non-norm= ative in nature - with the exception of one major item, the X-/X# key-relat= ed changes that David sent out to the list last week - which the authors ar= e in agreement with. I will give it a few days for the list feedback, befor= e I incorporate those changes and submit the -06 version. I am including a list of all normative changes below. You can find the curr= ent working version of the draft, including the changes below, here: http://www.chadalapaka.com/Documents/draft-ietf-storm-iscsi-cons-06.pdf Please let the authors know of your feedback. Thanks! Mallikarjun Section 4.2.2.1 [from] The initiator and target must ensure that the task management commands act= as specified by [SAM2]. [to] The initiator and target MUST ensure that the SCSI task management function= s specified in [SAM2] act in accordance with the [SAM2] specification. Section 6.2 [from] An iSCSI initiator or target MAY terminate a negotiation that does not end = within a reasonable time or number of exchanges. [to] An iSCSI initiator or target MAY terminate a negotiation that does not term= inate within an implementation-specific reasonable time or number of exchan= ges, but SHOULD allow at least 6 exchanges. Section 6.2.2 [from] Proposing a value not admissible (e.g., not within the specified bounds) M= AY be answered with the constant "Reject" or the acceptor MAY select an a= dmissible value. [to] Proposing a value not admissible (e.g., not within the specified bounds) MA= Y be answered with the constant "Reject", otherwise the acceptor MUST selec= t an admissible value. Section 6.2.2 [from] For a numerical range the value selected must be an integer within the pro= posed range or "Reject" (if the range is unacceptable). [to] For a numerical range the value selected MUST be an integer within the prop= osed range or "Reject" (if the range is unacceptable). Section 6.3.3 [from] If the target responds to a Login request that has the T bit set to 1 with = a Login response that has the T bit set to 0, the initiator should keep sen= ding the Login request (even empty) with the T bit set to 1, while it still= wants to switch stage, until it receives the Login Response that has the T= bit set to 1 or it receives a key that requires it to set the T bit to 0. [to] Even when the initiator indicates its intent to switch stage by setting the= T bit to 1 in a Login request, the target MAY respond with a Login respons= e with the T bit set to 0. In that case, the initiator SHOULD continue to s= et the T bit to 1 in subsequent Login requests (even empty) that it sends, = until target sends a Login response with the T bit set to 1 or sends a key = that requires initiator to set the T bit to 0. Section 6.4 [from] if the target responds to a text request with the f bit set to 1 with a text response with the f bit set to 0, the initiator should keep sending the text request (even empty) with the f bit set to 1, while it still wants to finish the negotiation, until it receives the text response with the f bit set to 1. responding to a text request with the f bit set to 1 with an empty (no key=3Dvalue pairs) response with the f bit set to 0 is discouraged. [to] Even when the initiator indicates its intent to finish the negotiation by s= etting the F bit to 1 in a Text request, the target MAY respond with a Text= response with the F bit set to 0. In that case, the initiator SHOULD conti= nue to set the F bit to 1 in subsequent Text requests (even empty) that it = sends, until target sends the final Text response with the F bit set to 1. = Note that in the same case of Text request with the F bit set to 1, target = SHOULD NOT respond with an empty (no key=3Dvalue pairs) Text response with = the F bit set to 0, because such a response may cause the initiator to aban= don negotiation. Section 9.2 [from] Therefore, a method using clear text (or equivalent) passwords is not accep= table [to] Therefore, a method using clear text (or equivalent) passwords MUST NOT be = used Section 11.3.1 [from] Setting both the W and the F bit to 0 is an error [to] At least one of the W and F bits MUST be set to 1. Section 11.4.3 [from] A non-zero response field indicates a failure to execute the command in whi= ch case the Status and Flag fields are undefined. [to] A non-zero response field indicates a failure to execute the command in whi= ch case the Status and Flag fields are undefined and MUST be ignored on rec= eption. Section 11.4.5.1 [from] The Residual Count field MUST be valid in the case where either the U bit o= r the O bit is set. If neither bit is set, the Residual Count field is rese= rved. [to] The Residual Count field MUST be valid in the case where either the U bit o= r the O bit is set. If neither bit is set, the Residual Count field MUST be= ignored on reception and SHOULD be set to 0 when sending. Appendix C [add] The text in this Appendix is a normative part of this document. --_000_E160851FCED17643AE5F53B5D4D0783A3498F1F2SN2PRD0610MB372_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi all,

 

I have just published = the “candidate-2” revision for  iSCSI Consolidated draft -= 06 at the same URL.

 

http://www= .chadalapaka.com/Documents/draft-ietf-storm-iscsi-cons-06.pdf

 

I plan to submit this = tomorrow for publication. FYI.

 

Mallikarjun

 

 

From: storm-bo= unces@ietf.org [mailto:storm-bounces@ietf.org] On Behalf Of Mallikarjun Chadalapaka
Sent: Sunday, July 01, 2012 4:01 PM
To: storm@ietf.org
Subject: [storm] iSCSI -06 candidate-1 version

 

Hi All,

 

Since the -05 version, iSCSI Consolidated draft rece= ived invaluable feedback from a few folks, most notably from our AD Martin Stiemerling and Rob Elliott. Many t= hanks to both of them.

 

I have now incorpor= ated all the feedback - most of it is editorial/non-normative in nature = 211; with the exception of one major item, the X-/X# key-related changes th= at David sent out to the list last week – which the authors are in agreement with. I will give it a few days for the= list feedback, before I incorporate those changes and submit the -06 versi= on.

 

I am including a li= st of all normative changes below. You can find the current working version= of the draft, including the changes below, here:

 

http://www= .chadalapaka.com/Documents/draft-ietf-storm-iscsi-cons-06.pdf

 

Please let the auth= ors know of your feedback.

 

Thanks!<= /span>

 

Mallikarjun

 

 

 

Section 4.2.2.1

[from]

The initiator and target must  ensure that the ta= sk management commands act as specified by  [SAM2].

 

[to]

The initiator and target MUST ensure that the SCSI tas= k management functions specified in [SAM2] act in accordance with the [SAM2= ] specification.

 

Section 6.2

[from]

An iSCSI initiator or target MAY terminate a negotiati= on that does not end within a reasonable time or number of exchanges.<= /o:p>

 

[to]

An iSCSI initiator or target MAY terminate a negotiati= on that does not terminate within an implementation-specific reasonable tim= e or number of exchanges, but SHOULD allow at least 6 exchanges.=

 

Section 6.2.2

[from]

Proposing a value not admissible (e.g., not within the= specified  bounds) MAY be answered with the constant "Reject&quo= t; or the acceptor   MAY select an admissible value.

 

[to]

Proposing a value not admissible (e.g., not within the= specified bounds) MAY be answered with the constant "Reject", ot= herwise the acceptor MUST select an admissible value.

 

Section 6.2.2

[from]

For a numerical range the value selected must be an in= teger within  the proposed range or "Reject" (if the range i= s unacceptable).

 

 

[to]

For a numerical range the value selected MUST be an in= teger within the proposed range or "Reject" (if the range is unac= ceptable).

 

Section 6.3.3

[from]

If the target responds to a Login request that has the= T bit set to 1 with a Login response that has the T bit set to 0, the init= iator should keep sending the Login request (even empty) with the T bit set= to 1, while it still wants to switch stage, until it receives the Login Response that has the T bit set to 1 or= it receives a key that requires it to set the T bit to 0.

[to]

Even when the initi= ator indicates its intent to switch stage by setting the T bit to 1 in a Lo= gin request, the target MAY respond with a Login response with the T bit set to 0. In that case, the initiator SHOULD conti= nue to set the T bit to 1 in subsequent Login requests (even empty) that it= sends, until target sends a Login response with the T bit set to 1 or send= s a key that requires initiator to set the T bit to 0.

 

Section 6.4

[from]

  if the target responds to a text request with t= he f bit set to 1

  with a text response with the f bit set to 0, t= he initiator should

  keep sending the text request (even empty) with= the f bit set to

  1, while it still wants to finish the negotiati= on, until it

  receives the text response with the f bit set t= o 1. responding to

  a text request with the f bit set to 1 with an = empty (no key=3Dvalue

  pairs) response with the f bit set to 0 is disc= ouraged.

 

[to]

Even when the initiator indicates its intent to finish= the negotiation by setting the F bit to 1 in a Text request, the target MA= Y respond with a Text response with the F bit set to 0. In that case, the i= nitiator SHOULD continue to set the F bit to 1 in subsequent Text requests (even empty) that it sends, until t= arget sends the final Text response with the F bit set to 1. Note that in t= he same case of Text request with the F bit set to 1, target SHOULD NOT res= pond with an empty (no key=3Dvalue pairs) Text response with the F bit set to 0, because such a response may = cause the initiator to abandon negotiation.

 

Section 9.2

[from]

Therefore, a method using clear text (or equivalent) p= asswords is not acceptable

[to]

Therefore, a method using clear text (or equivalent) p= asswords MUST NOT be used

 

Section 11.3.1

[from]

Setting both the W and the F bit to 0 is an error

 

[to]

At least one of the W and F bits MUST be set to 1.

 

Section 11.4.3

[from]

A non-zero response field indicates a failure to execu= te the command in which case the Status and Flag fields are undefined.=

 

[to]

A non-zero response field indicates a failure to execu= te the command in which case the Status and Flag fields are undefined and M= UST be ignored on reception.

 

Section 11.4.5.1

[from]

The Residual Count field MUST be valid in the case whe= re either the U bit or the O bit is set. If neither bit is set, the Residua= l Count field is reserved.

 

[to]

The Residual Count field MUST be valid in the case whe= re either the U bit or the O bit is set. If neither bit is set, the Residua= l Count field MUST be ignored on reception and SHOULD be set to 0 when send= ing.

 

Appendix C

[add]

The text in this Appendix is a normative part of this docu= ment.

 

 

--_000_E160851FCED17643AE5F53B5D4D0783A3498F1F2SN2PRD0610MB372_-- From nezhinsky@gmail.com Sun Jul 15 00:26:44 2012 Return-Path: X-Original-To: storm@ietfa.amsl.com Delivered-To: storm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D4AF921F858A for ; Sun, 15 Jul 2012 00:26:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.999 X-Spam-Level: X-Spam-Status: No, score=-2.999 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, J_CHICKENPOX_72=0.6, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7cQcX2fvnSuZ for ; Sun, 15 Jul 2012 00:26:43 -0700 (PDT) Received: from mail-ob0-f172.google.com (mail-ob0-f172.google.com [209.85.214.172]) by ietfa.amsl.com (Postfix) with ESMTP id 747F021F8589 for ; Sun, 15 Jul 2012 00:26:43 -0700 (PDT) Received: by obbwc20 with SMTP id wc20so8406171obb.31 for ; Sun, 15 Jul 2012 00:27:24 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :content-type; bh=SCfHkiV8F8LZiYRbRLL8oa2WZ4H1Y5OgcwkXbAOSngU=; b=yJopP6kMy4M97HDF8I1c/+G24i676bIL0jMXS+xlpD3A7WHWQ7myk5l0NoIZECifDK z9n/pysXltwasYC+7X1YXU7PChS5nJKfxa/EiXAOC7H0W2hkf6FPCWiE4lLpfp82b9d5 kDAJ4C+Xzol5tNnuu6GUrj7XSGXaOOapRBqxItBO/5QEm8BaLfKyiDpzFXcS+B83zV8V 0OhBgYLIfsrSP5yTcq4eKuS2TVjM1CCdfdcugjArblCPho/xdLs/EsoVBfS/XiXMs/jZ FgggKTKqWhcs6KV9Y5WIGf+ZreZrWxrVkKla5foZaUa+yBOnVvd/8JZZibiWbpPzEDwj 3IJw== MIME-Version: 1.0 Received: by 10.60.6.73 with SMTP id y9mr9702129oey.17.1342337244264; Sun, 15 Jul 2012 00:27:24 -0700 (PDT) Received: by 10.182.183.101 with HTTP; Sun, 15 Jul 2012 00:27:24 -0700 (PDT) In-Reply-To: <8D3D17ACE214DC429325B2B98F3AE71208D3B0CA@MX15A.corp.emc.com> References: <8D3D17ACE214DC429325B2B98F3AE71208C14966@MX15A.corp.emc.com> <8D3D17ACE214DC429325B2B98F3AE71208C14A8F@MX15A.corp.emc.com> <8D3D17ACE214DC429325B2B98F3AE71208D3B0CA@MX15A.corp.emc.com> Date: Sun, 15 Jul 2012 10:27:24 +0300 Message-ID: From: Alexander Nezhinsky To: storm@ietf.org, David Black , Mike Ko , Paul Koning , Mallikarjun Chadalapaka , Or Gerlitz , Mike Christie Content-Type: text/plain; charset=UTF-8 Subject: Re: [storm] iSER - what to do X-BeenThere: storm@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Storage Maintenance WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 15 Jul 2012 07:26:45 -0000 Hi, all Sorry for a late answer (again). I have been thinking over this issue hesitantly for a long time being close to just agree with the latest set of suggestions. But then I realized there is a simple counter-argument which complicates things even more. When the initiator sends its final Login Request it is not guaranteed that the next Login Response it receives is the "final" one, too. If the target has more text data to send than the hardcoded 8KB, it will split it into two (or more) PDUs by raising Continue bit in all its responses except the last. This is a rare event but it means that to be fully compliant and full-proof the initiator can't just post another N buffers to anticipate all "unexpected" PDUs from target. It posts one 8KB buffer for the next Login Response, but it should be ready for the case where the response contains C=1. In such case it would post another 8KB buffer and answer ok to continue. Regular initiator rx-buffers are much smaller than 8KB. Implementation-wise they are usually allocated from a separate pool or some other kind of discrimination is made between the login and full-featured-phase buffers. As there is no acceptable way to reclaim the buffers after they have been posted, the only way out is to post a few 8KB buffers, but it will make the implementation even more complicated and cumbersome. All in all, I suggest that we bite the bullet, complete the spec and head towards fully spec-compliant implementations of both initiator and target as soon as possible. On pratical grounds we can address the distro maintainers to employ all possible means to distribute compliant updates sooner than later, as those will represent a special, critical change. To minimize the damages i suggest taking the following path: 1. iSERHelloRequired remains defined as is, with default=No. 2. It becomes *mandatory* for a fully-spec compliant initiator implementation to communicate iSERHelloRequired=Yes. * If this key is not sent then the "new" target knows that it has encountered an "old" initiator. * If the initiator sends iSERHelloRequired=No, it means it choses (for some bizarre reasons) to behave as an "old" one - while such behavior is strongly discouraged. I guess the requirement that: "the initiator SHOULD send iSERHelloRequired=Yes" reflects the situation, correct me if i'm wrong. 3. "New" initiator will recognize an "old" target by receiving "NotUnderstood" in response to iSERHelloRequired=Yes. Then it can either refuse to deal with it, or to employ a range of tricky means used until now. We can describe those means as the guidelines, e.g. : * posting one or better MaxOutstandingUnexpectedPDUs buffers * to be really on the safe side, having those buffers at least 8KB long. As we are trying to neutralize the shortcomings of the existing targets, the initiator can bet that the target won't send split login responses, as it regularly does not do so today. 4. "New" target will recognize an "old" initiator by having received iSERHelloRequired=No either implicitly or explicitly. Then it must ignore the iSERHello absense and may also take some precautions, like: * delaying sending any "unexpected" PDUs until the first PDU is received from the initiator after the final login response has been sent * taking a reasonable timeout, say a second (the exact value does not matter as the initiator can't count on it anyway and no value will solve the problem in full, theoretically). * doing both, that is waiting for the first incoming PDU and taking a timer to start sending NOP-INs in case no PDUs arrived during the timeout period, to be able to detect silent connection failures. 5. "New" target and "new" initiator will count on ISERHello as the guarantee of proper buffer posting 6. "Old" target and "old" initiator will work as they do now, in their double bliss of ignorance. By the way, the initiator patch alleviating the problem by posting one additional login buffer was submitted relatively recently and all previous deployed implementations of the initiator are exposed. Eventually, the new better code is making its way to the users of all distros. This is a common situation encountered by the linux kernel community quite often. Let's take this as a working example, make the spec fool-proof and advise the implementors how to minimize the damages with the old software, while keeping everything as simple as possible under these already over-complicated circumstances. Alexander From internet-drafts@ietf.org Mon Jul 16 03:24:51 2012 Return-Path: X-Original-To: storm@ietfa.amsl.com Delivered-To: storm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BCA0521F8781; Mon, 16 Jul 2012 03:24:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.524 X-Spam-Level: X-Spam-Status: No, score=-102.524 tagged_above=-999 required=5 tests=[AWL=0.075, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 18FBtRlU2eOb; Mon, 16 Jul 2012 03:24:51 -0700 (PDT) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A85A921F8780; Mon, 16 Jul 2012 03:24:50 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 4.30p3 Message-ID: <20120716102450.26627.92864.idtracker@ietfa.amsl.com> Date: Mon, 16 Jul 2012 03:24:50 -0700 Cc: storm@ietf.org Subject: [storm] I-D Action: draft-ietf-storm-iscsimib-02.txt X-BeenThere: storm@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Storage Maintenance WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 16 Jul 2012 10:24:52 -0000 A New Internet-Draft is available from the on-line Internet-Drafts director= ies. This draft is a work item of the STORage Maintenance Working Group of the = IETF. Title : Definitions of Managed Objects for Internet Small Comput= er System Interface (iSCSI) Author(s) : Mark Bakke Prakash Venkatesen Filename : draft-ietf-storm-iscsimib-02.txt Pages : 87 Date : 2012-07-16 Abstract: This document defines a portion of the Management Information Base (MIB) for use with network management protocols. In particular, it defines objects for managing a client using the Internet Small Computer System Interface (iSCSI) protocol (SCSI over TCP). This document obsoletes RFC4544. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-storm-iscsimib There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-storm-iscsimib-02 A diff from previous version is available at: http://tools.ietf.org/rfcdiff?url2=3Ddraft-ietf-storm-iscsimib-02 Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From prakashvn@hcl.com Mon Jul 16 04:36:20 2012 Return-Path: X-Original-To: storm@ietfa.amsl.com Delivered-To: storm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 21E3E21F87C0 for ; Mon, 16 Jul 2012 04:36:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.595 X-Spam-Level: X-Spam-Status: No, score=-0.595 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, TRACKER_ID=2.003] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id PUnMklHAdaLB for ; Mon, 16 Jul 2012 04:36:04 -0700 (PDT) Received: from GWS07.hcl.com (gws07.hcl.com [192.8.186.130]) by ietfa.amsl.com (Postfix) with ESMTP id 4592C21F87CB for ; Mon, 16 Jul 2012 04:35:59 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.77,593,1336329000"; d="scan'208,217";a="2042415" Received: from unknown (HELO CSEZ-CORP-HT02.CORP.HCL.IN) ([10.249.2.36]) by GWS07.hcl.com with ESMTP/TLS/AES128-SHA; 16 Jul 2012 17:01:07 +0530 Received: from CHN-HCLT-CASHT2.HCLT.CORP.HCL.IN (10.108.45.28) by CSEZ-CORP-HT02.CORP.HCL.IN (10.249.2.36) with Microsoft SMTP Server (TLS) id 8.2.254.0; Mon, 16 Jul 2012 17:06:42 +0530 Received: from CHN-HCLT-EVS16.HCLT.CORP.HCL.IN ([fe80::ed0c:1af0:55cb:a6fc]) by CHN-HCLT-CASHT2.HCLT.CORP.HCL.IN ([::1]) with mapi; Mon, 16 Jul 2012 17:06:42 +0530 From: "Prakash Venkatesen, ERS-HCLTech" To: "Storm (storm@ietf.org)" Date: Mon, 16 Jul 2012 17:06:40 +0530 Thread-Topic: MIB Doctor Review for iSCSI MIB, proposed changes, and list questions Thread-Index: Ac1d7t+U2g2vOeQ/QtWQihiahn+w8QBdtJpwAPeLuqA= Message-ID: <62DC16C614A9554F81C8E2E5C174A98837D8636D4E@CHN-HCLT-EVS16.HCLT.CORP.HCL.IN> References: <975552A94CBC0F4DA60ED7B36C949CBA03F1781133@shandy.Beer.Town> <975552A94CBC0F4DA60ED7B36C949CBA03F17813D9@shandy.Beer.Town> In-Reply-To: <975552A94CBC0F4DA60ED7B36C949CBA03F17813D9@shandy.Beer.Town> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: multipart/alternative; boundary="_000_62DC16C614A9554F81C8E2E5C174A98837D8636D4ECHNHCLTEVS16H_" MIME-Version: 1.0 X-Mailman-Approved-At: Mon, 16 Jul 2012 08:05:56 -0700 Cc: "mrm@vmware.com" Subject: Re: [storm] MIB Doctor Review for iSCSI MIB, proposed changes, and list questions X-BeenThere: storm@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Storage Maintenance WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 16 Jul 2012 11:36:20 -0000 --_000_62DC16C614A9554F81C8E2E5C174A98837D8636D4ECHNHCLTEVS16H_ Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable Hi All, We have posted the next version, 02, of the iSCSI MIB module draft. This in= cludes the following changes: * Updated the Intellectual Property Section * Fixed incorrect reference to iscsiInstSsnErrorStatsTable. This has= been changed to iscsiInstanceSsnErrorStatsTable. * Changed reference to MIB as MIB module * Included editors note to IANA Considerations * Added editors note on fixing 'RFC cccc' * Fixed references in MIB module not found in normative (sec 10.1) * Updated iscsiNodeAttributesEntry description * Updated low word counter to 32 bit SNMPv1 counter * Corrected REFERENCE for iscsiIntrAuthIdentity * Updated Description for iscsiSsnCxnDigestErrors, iscsiSsnCxnTimeou= tErrors * Added SCSI-MIB RFC and section references on iscsiNodeTransportType * Clarified the three IPS-AUTH MIB references to refer to ipsAuthIde= ntAttributesEntry object http://www.ietf.org/internet-drafts/draft-ietf-storm-iscsimib-02.txt The IETF datatracker page for this Internet-Draft is: https://datatracker.ietf.org/doc/draft-ietf-storm-iscsimib/ Diff from previous version: http://tools.ietf.org/rfcdiff?url2=3Ddraft-ietf-storm-iscsimib-02 regards Prakash From: Mark Bakke [mailto:Mark_Bakke@DELL.com] Sent: Wednesday, July 11, 2012 6:36 PM To: Storm (storm@ietf.org) Cc: david.black@emc.com; Prakash Venkatesen, ERS-HCLTech; ttalpey@microsoft= .com; mrm@vmware.com Subject: FW: MIB Doctor Review for iSCSI MIB, proposed changes, and list qu= estions Everyone, We are in the process of updating the iSCSI MIB module, to match the latest= storm changes. Mike MacFaden has also done a MIB Doctor review, which bro= ught back a number of comments on things that are potentially missing from = the original iSCSI MIB RFC. Prakash, David, Tom and I have been reviewing the MIB doctor requests. Thi= s message is intended to answer some of the MIB doctor comments as well as = generate discussion on the list about possible changes. We intend to post = another draft (-02) before the July 16th deadline for the next round of dis= cussion. Here is a brief summary. The full responses to comments are below. * Several editorial changes * A few new fields are added to objects that are either useful or we= re missed the first time around * More complex additions that we believe will need a separate revisi= on and may affect the object model. The latter changes would require suppo= rt from those intending to implement or use them. I will start separate discussion threads on a few items: * Heartbeat counters for NOP-In and NOP-Out usage * TCP MIB correlation for sessions and connections * iscsiInstanceSsnErrorStatsTable session details For reference, we have: * The previous draft of the new iSCSI MIB - http://www.ietf.org/id/d= raft-ietf-storm-iscsimib-01.txt * The initial MIB doctor review - http://www.macfaden.com/ietf/iscsi= -mib-1-reviewed.txt * An additional MIB doctor review with VMware engineers - http://mac= faden.com/ietf/iscsi-mib-notes.txt Detailed responses to MIB doctor review: February 17, 2012 MIB DOCTOR Review: http://www.ietf.org/id/draft-ietf-stor= m-iscsimib-01.txt Performed by Michael R. MacFaden, VMware, Inc According to http://tools.ietf.org/html/rfc4181 This review only covers syntax, SMIv2 rules usage of the MIB module itself,= not the draft. Some of the things mentioned below exist the prior version of the mib, not = this update. 1 boiler plate - check 2. Narrative Sections - check 3. Security Considerations - check 4. IANA Considerations - missing editors' note. Section 9 needs the following verbiage to be added. Editor's Note (to be removed prior to publication): this draft makes no additional requests of the IANA. Editors: We will fix this. 5. No new namespaces 6. References section - check 7. copyright notice - check 8. Intellectual Property section - missing Editors: We will add the section: Copyright (c) 2011 IETF Trust and the persons identified as authors of the code. All rights reserved. Redistribution and use in source and binary forms, with or without modification, is permitted pursuant to, and subject to the license terms contained in, the Simplified BSD License set forth in Section 4.c of the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info)." 9. This change updates existing mib rfc http://www.ietf.org/rfc/rfc4544.txt= - check Backward compatibility checks: (oids, object-identities, remained the sa= me) Other items checked -- syntax check: smilint -l9 - no errors smicng : not run spelling: Aspell --- no misspellings found. URLs validated: checked for valid, not-broken links: http://www.iana.org/assignments/protocol-numbers References in MIB module not found in normative (sec 10.1) IscsiTransportProtocol TC -> "RFC791, RFC1700 Editors: We will fix this. enumerations: each element described - IscsiDigestMethod Editors: We had this in the description - is there something else that need= s to be added? DiscontinuityTime is syntax: TimeStamp All Counters: define their discontinuity timestamp. Editors: We checked the descriptions in each of the Counter32 and Counter64= fields, and they all reference a discontinuity timestamp. Isn't that enou= gh? Uncommon stuff: 1) In IscsiPortalAttributesEntry has RowStatus as second item in the conce= ptual row, not after iscsiPortalStorageType. Editors: We currently don't put StorageType and RowStatus together in any o= f our objects, and didn't originally realize there was some tradition aroun= d this. Changing numbering now would cause backward compatibility problems= , so we cannot make this change. 2) iscsiPortalRoles does not have a DEFVAL when most others do in this conc= eptual table. iscsiPortalAddrType has def val of IPV4? when the iscsiPortalAddr has no de= fault to go with it? Editors: There isn't a reasonable DEFVAL for iscsiPortalRoles. It has to = be set when creating the row, so we will leave this one. 3) iscsiNodeAttributesEntry sez: An entry (row) containing mana vs 'conceptual row' which is used inconsistently. Editors: We will change this description from: An entry (row) containing management information applicable to a particular iSCSI node. To A conceptual row containing management information applicable to a particular iSCSI node. 4) (e.g. not created via this MIB). vs MIB module. There is but one MIB a= s Dr Case would say. Editors: We will fix this one. 5) 64 bit counters with SNMPv1 support for 32 bit high/low? kinda iscsiSsnTxDataOctets, iscsiSsnRxDataOctets, provides only low word: iscsi= SsnLCTxDataOctets, iscsiSsnLCRxDataOctets Compliance phrasing is a bit odd: "A Low Capacity shadow object of iscsiSsnTxDataOctets for those systems that don't support Counter64. instead of 'for those systems which are accessible via SNMPv1 only' Editors: We will fix the wording for SNMPv1. We don't see a reason to add= objects for high octets. 6) Notifications are required to have a rate limited implementation by a de= scription, yet the number of times the failure occurred is not conveyed in the no= tifcation varbind list. iscsiTgtLoginFailure, iscsiIntrLoginFailure, iscsiInstSessionFailure To avoid sending an excessive number of notifications due to multiple errors counted, an SNMP agent implementing this notification SHOULD NOT send more than 3 notifications of this type in any 10-second time period." Editors: We believe that this is covered by the counter "iscsiTgtLoginFail= ures": iscsiTgtLoginFailure NOTIFICATION-TYPE OBJECTS { iscsiTgtLoginFailures, iscsiTgtLastFailureType, iscsiTgtLastIntrFailureName, iscsiTgtLastIntrFailureAddrType, iscsiTgtLastIntrFailureAddr } The following section addresses comments from the VMware iSCSI-MIB review: Notes from VMware ISCIS-MIB review meeting March 21, 2012 Attendees: Andy Banta, Kun Huang, Mike MacFaden General comments: 1. Many objects lacking REFERENCE clause or offer only vague references. For those managed objects having a Reference clause, nedd to fix up 'RFC cc= cc' For example: "RFC cccc, Section 7.5, Connection Timeout Management" Example of vague reference: REFERENCE "SCSI-MIB" Editors: OK, we can update in the next draft. 2. Descriptions are short and simple but in some case seem a bit too short for an IETF standard mib module. Editors: We can look for opportunities to clarify but don't think we want t= o go through and rewrite a lot. If there are particular descriptions that = cause confusion please bring them up. Here's the comments by object in the MIB module: draft-ietf-storm-iscsimib-= 01.txt iscsiMibModule(1.3.6.1.2.1.142) | +--iscsiNotifications(0) | | | +--iscsiTgtLoginFailure(1) [iscsiTgtLoginFailures,iscsiTgtLastFailureT= ype,iscsiTgtLastIntrFailureName,iscsiTgtLastIntrFailureAddrType,iscsiTgtLas= tIntrFailureAddr] Consider adding port number. Editors: LastFailurePortNumber would be easy enough to add. Should we do a= n OrZero for implementations that can't get the port number? | +--iscsiIntrLoginFailure(2) [iscsiIntrLoginFailures,iscsiIntrLastFailu= reType,iscsiIntrLastTgtFailureName,iscsiIntrLastTgtFailureAddrType,iscsiInt= rLastTgtFailureAddr] Can't determine if the failure is due to failure of the underlying transpor= t or not. When transport is TCP there should be some way to get to the TCP-MIB/TCP-ES= TATS-MIB diagnostics. See notes on iscsiInstanceSsnErrorStatsTable. Consider adding port number. Editors: Same as above. On the failure, is it useful to have both local an= d remote addr and port number? Will the TCP MIB keep these connections aro= und long enough to go index it on a failed connection? If we add these fie= lds, will someone use them? | +--iscsiInstSessionFailure(3) [iscsiInstSsnFailures,iscsiInstLastSsnFa= ilureType,iscsiInstLastSsnRmtNodeName] Consider handling the event "Target Unmapped" by updatingiscsiInstLastSsnF= ailureType of a Session failure, as well. Editors: FailureType is an OID pointing to a stat in iscsiInstSsnErrorStats= Table, so we would need to add to this: iscsiInstSsnTgtUnmappedErrors Counter32 Are there others that would be needed? Consider adding summary notification in the case of larger scales (number o= f targets) what about large scales, # of targets, each target have a failure of simila= r sort. Editors: Would such a notification really be used? If there was a large sc= ale failure of many targets, we believe the administrator would see enough = of the notifications to notice it as a larger problem. | | +--iscsiInstanceSsnErrorStatsTable(2) | | | | | +--iscsiInstanceSsnErrorStatsEntry(1) [iscsiInstIndex] | | | | | +-- r-n Counter32 iscsiInstSsnDigestErrors(1) | | +-- r-n Counter32 iscsiInstSsnCxnTimeoutErrors(2) | | +-- r-n Counter32 iscsiInstSsnFormatErrors(3) Related states for transport are not provided in this table. Either a RowPo= inter to another mib module is needed or a generic transport counter to indicate = failure at that layer was detected by iscsiInstance. Editors: If connection timeout errors are seen, wouldn't the user check tra= nsport connectivity via ping and other tools? We are not sure that adding = more objects here would add enough value. Consider separate counters for HB vs data timeouts. Consider specific heartbeat no-op timeout error countes. Editors: We will start another thread for this discussion. It does seem us= eful since most implementations use NOP for keep-alive heartbeats. | +--iscsiPortal(2) | | | | | +--iscsiPortalAttributesTable(1) | | | | | +--iscsiPortalAttributesEntry(1) [iscsiInstIndex,iscsiPortalInde= x] | | | | | +-- --- Unsigned32 iscsiPortalIndex(1) | | +-- rwn RowStatus iscsiPortalRowStatus(2) | | +-- rwn Bits iscsiPortalRoles(3) | | +-- rwn InetAddressType iscsiPortalAddrType(4) | | +-- rwn InetAddress iscsiPortalAddr(5) | | +-- rwn IscsiTransportProtocol iscsiPortalProtocol(6) | | +-- rwn Unsigned32 iscsiPortalMaxRecvDataSegLengt= h(7) | | +-- rwn IscsiDigestMethod iscsiPortalPrimaryHdrDigest(8) | | +-- rwn IscsiDigestMethod iscsiPortalPrimaryDataDigest(9) | | +-- rwn IscsiDigestMethod iscsiPortalSecondaryHdrDigest(= 10) | | +-- rwn IscsiDigestMethod iscsiPortalSecondaryDataDigest= (11) | | +-- rwn TruthValue iscsiPortalRecvMarker(12) | | +-- rwn StorageType iscsiPortalStorageType(13) Digests are negotiated and implementations may have additional levels (tert= iary, quaternary) as well as constraints that are not modelled here. Editors: There's only one standardized digest method currently in use (CRC3= 2C) that we know of. Are there implementations that extend this beyond two? Digests can also be configured in iscsiNodeAttributesTable. (Is there a pre= cecence between node and portal?) Editors: There is no digests field currently in NodeAttributesTable, so Por= tal is the only place to configure it. Need to be able to set/show port number as well as iscsiPortalAddr. Editors: We can add this one. Regarding iscsiCxnRecvMarker, iscsiCxnSendMarker these are to be deprecate= d and are redundant in session and connection. Editors: These will be removed. The V2 object groups in the draft do not c= ontain the deprecated objects. ** note: I Checked with INET-ADDRESS-MIB about iscsiPortalAddrType, if set = to 16 dns(16) A DNS domain name as defined by the InetAddressDNS textual convention. Then iscsiPortalAddr can be a dns hostname. Appears the MIB Portal Attributes and Node Atributes are sort os a mish-mash or Node, Lhba, Phba, various Portal properties. Editors: Not sure we understand this one - the MIB follows iSCSI node and = portal definitions for portals and nodes. HBAs are outside the scope of th= e MIB and of iSCSI. Using a table rather than Primary and Secondary would be the right approach for Header and Data digests, since the whole point of these negotiations is to provide a list of what each side is willing to settle on. Editors: Technically, yes, but practically it seems over-complicated. Additionally, a list for authentication negotiation would be useful, also. There are five different authentication methods defined by the original RFC 3720, and a few additional ones that have since sprung up. Editors: Isn't the list of authorized entities sufficient, since the method= s are included by reference?] There's also the idea of mutual authentication, where each side verfies the identity of the other, rathern than just a target authenticatiing a host. Editors: Is this comment referring to the iscsiSsnAuthIdentity? We do see = that this is just one per session, and we didn't identify it as an initiato= r or target identity (most people likely assumed initiator). We'd need to change this name to iscsiSsnAuthIntrIdentity and add iscsiSsnA= uthTgtIdentity to show both identities in a session where this is used. Additional useful information at the Portal level might be at least some identification of what type of initiator it is, and some identifying information about it. Maybe not the level of detail you'll find in IMA_PHBA_PROPERTIES, but the model, description and version. Editors: this seems useful for troubleshooting. We can add something simil= ar to iscsiInstDescr: iscsiPortalDescr OBJECT-TYPE SYNTAX SnmpAdminString MAX-ACCESS read-only STATUS current DESCRIPTION "A UTF-8 string, determined by the implementation to describe the iSCSI portal. When only a single instance is present, this object may be set to the zero-length string; with multiple iSCSI portals, it may be used in an implementation-dependent manner to describe the respective portal, and could include information such as HBA model, description and version or software driver and version." I don't think that we'd want to try to structure it more than just a string. | +--iscsiNode(5) | | | | | +--iscsiNodeAttributesTable(1) | | | | | +--iscsiNodeAttributesEntry(1) [iscsiInstIndex,iscsiNodeIndex] | | | | | +-- --- Unsigned32 iscsiNodeIndex(1) | | +-- r-n IscsiName iscsiNodeName(2) | | +-- r-n SnmpAdminString iscsiNodeAlias(3) | | +-- r-n Bits iscsiNodeRoles(4) | | +-- r-n RowPointer iscsiNodeTransportType(5) | | +-- r-n TruthValue iscsiNodeInitialR2T(6) | | +-- rwn TruthValue iscsiNodeImmediateData(7) | | +-- rwn Unsigned32 iscsiNodeMaxOutstandingR2T(8) | | +-- rwn Unsigned32 iscsiNodeFirstBurstLength(9) | | +-- rwn Unsigned32 iscsiNodeMaxBurstLength(10) | | +-- rwn Unsigned32 iscsiNodeMaxConnections(11) | | +-- rwn TruthValue iscsiNodeDataSequenceInOrder(12) | | +-- rwn TruthValue iscsiNodeDataPDUInOrder(13) | | +-- rwn Unsigned32 iscsiNodeDefaultTime2Wait(14) | | +-- rwn Unsigned32 iscsiNodeDefaultTime2Retain(15) | | +-- rwn Unsigned32 iscsiNodeErrorRecoveryLevel(16) | | +-- r-n TimeStamp iscsiNodeDiscontinuityTime(17) | | +-- rwn StorageType iscsiNodeStorageType(18) Digests as found in scsiPortalAttributesTable, may be provisioned at this l= evel. Editors: Is there a need to provision digest at this level via the MIB modu= le? | +--iscsiInitiator(8) | | | | | +--iscsiInitiatorAttributesTable(1) | | | | | | | +--iscsiInitiatorAttributesEntry(1) [iscsiInstIndex,iscsiNodeInd= ex] | | | | | | | +-- r-n Counter32 iscsiIntrLoginFailures(1) | | | +-- r-n TimeStamp iscsiIntrLastFailureTime(2) | | | +-- r-n AutonomousType iscsiIntrLastFailureType(3) | | | +-- r-n IscsiName iscsiIntrLastTgtFailureName(4) | | | +-- r-n InetAddressType iscsiIntrLastTgtFailureAddrType(5) | | | +-- r-n InetAddress iscsiIntrLastTgtFailureAddr(6) No port number provided. Editors: We will add iscsiIntrLastTgtFailurePort | | +--iscsiInitiatorLoginStatsTable(2) | | | | | | | +--iscsiInitiatorLoginStatsEntry(1) [iscsiInstIndex,iscsiNodeInd= ex] | | | | | | | +-- r-n Counter32 iscsiIntrLoginAcceptRsps(1) | | | +-- r-n Counter32 iscsiIntrLoginOtherFailRsps(2) | | | +-- r-n Counter32 iscsiIntrLoginRedirectRsps(3) | | | +-- r-n Counter32 iscsiIntrLoginAuthFailRsps(4) | | | +-- r-n Counter32 iscsiIntrLoginAuthenticateFails(5) | | | +-- r-n Counter32 iscsiIntrLoginNegotiateFails(6) No way to get to transport layer (tcp, etc) related errors not shown here o= r provided through RowPointer/etc. Editors: We are not sure that this will add enough value. | | +--iscsiInitiatorLogoutStatsTable(3) | | | | | +--iscsiInitiatorLogoutStatsEntry(1) [iscsiInstIndex,iscsiNodeIn= dex] | | | | | +-- r-n Counter32 iscsiIntrLogoutNormals(1) | | +-- r-n Counter32 iscsiIntrLogoutOthers(2) The counter iscsiIntrLogoutOthers does not cover cases where no ack is retu= rned (timeout case) due to failure of transport to deliver logout ack. Editors: Adding a timeout counter for this seems to make sense. | +--iscsiIntrAuthorization(9) | | | | | +--iscsiIntrAuthAttributesTable(1) | | | | | +--iscsiIntrAuthAttributesEntry(1) [iscsiInstIndex,iscsiNodeInde= x,iscsiIntrAuthIndex] | | | | | +-- --- Unsigned32 iscsiIntrAuthIndex(1) | | +-- rwn RowStatus iscsiIntrAuthRowStatus(2) | | +-- rwn RowPointer iscsiIntrAuthIdentity(3) | | +-- rwn StorageType iscsiIntrAuthStorageType(4) The reference for iscsiIntrAuthIdentity is too vague. Only provides the RFC= ?: REFERENCE "IPS-AUTH MIB, RFC 4545" Editors: We will fix this. | +--iscsiSession(10) | | | | | +--iscsiSessionAttributesTable(1) | | | | | | | +--iscsiSessionAttributesEntry(1) [iscsiInstIndex,iscsiSsnNodeIn= dex,iscsiSsnIndex] | | | | | | | +-- --- Unsigned32 iscsiSsnNodeIndex(1) | | | +-- --- Unsigned32 iscsiSsnIndex(2) | | | +-- r-n Enumeration iscsiSsnDirection(3) | | | +-- r-n IscsiName iscsiSsnInitiatorName(4) | | | +-- r-n IscsiName iscsiSsnTargetName(5) | | | +-- r-n Unsigned32 iscsiSsnTSIH(6) | | | +-- r-n OctetString iscsiSsnISID(7) | | | +-- r-n SnmpAdminString iscsiSsnInitiatorAlias(8) | | | +-- r-n SnmpAdminString iscsiSsnTargetAlias(9) | | | +-- r-n TruthValue iscsiSsnInitialR2T(10) | | | +-- r-n TruthValue iscsiSsnImmediateData(11) | | | +-- r-n Enumeration iscsiSsnType(12) | | | +-- r-n Unsigned32 iscsiSsnMaxOutstandingR2T(13) | | | +-- r-n Unsigned32 iscsiSsnFirstBurstLength(14) | | | +-- r-n Unsigned32 iscsiSsnMaxBurstLength(15) | | | +-- r-n Gauge32 iscsiSsnConnectionNumber(16) | | | +-- r-n RowPointer iscsiSsnAuthIdentity(17) | | | +-- r-n TruthValue iscsiSsnDataSequenceInOrder(18) | | | +-- r-n TruthValue iscsiSsnDataPDUInOrder(19) | | | +-- r-n Unsigned32 iscsiSsnErrorRecoveryLevel(20) | | | +-- r-n TimeStamp iscsiSsnDiscontinuityTime(21) Consider reporting the digest negotiated for this session. Consider reporting the error-recovery-level (ERL). Consider reporting type(?) negotiated. | | +--iscsiSessionStatsTable(2) | | | | | | | +--iscsiSessionStatsEntry(1) [iscsiInstIndex,iscsiSsnNodeIndex,i= scsiSsnIndex] | | | | | | | +-- r-n Counter32 iscsiSsnCmdPDUs(1) | | | +-- r-n Counter32 iscsiSsnRspPDUs(2) | | | +-- r-n Counter64 iscsiSsnTxDataOctets(3) | | | +-- r-n Counter64 iscsiSsnRxDataOctets(4) | | | +-- r-n Counter32 iscsiSsnLCTxDataOctets(5) | | | +-- r-n Counter32 iscsiSsnLCRxDataOctets(6) Consider reporting missing PDU. Break down counters for data pdus in and out. Add counter for async pdus in. Editors: The above seem like good ideas - will anyone use these? Also, bre= aking down the existing counters might break current implementations. We w= ould likely have to create new ones. | | +--iscsiSessionCxnErrorStatsTable(3) | | | | | +--iscsiSessionCxnErrorStatsEntry(1) [iscsiInstIndex,iscsiSsnNod= eIndex,iscsiSsnIndex] | | | | | +-- r-n Counter32 iscsiSsnCxnDigestErrors(1) | | +-- r-n Counter32 iscsiSsnCxnTimeoutErrors(2) Description should discuss when these counters are most likely provided suc= h as when the error-recovery-level is 1 or 2. Editors: We will update the descriptions. | +--iscsiConnection(11) | | | +--iscsiConnectionAttributesTable(1) | | | +--iscsiConnectionAttributesEntry(1) [iscsiInstIndex,iscsiSsnNod= eIndex,iscsiSsnIndex,iscsiCxnIndex] | | | +-- --- Unsigned32 iscsiCxnIndex(1) | +-- r-n Unsigned32 iscsiCxnCid(2) | +-- r-n Enumeration iscsiCxnState(3) | +-- r-n InetAddressType iscsiCxnAddrType(4) | +-- r-n InetAddress iscsiCxnLocalAddr(5) | +-- r-n IscsiTransportProtocol iscsiCxnProtocol(6) | +-- r-n InetPortNumber iscsiCxnLocalPort(7) | +-- r-n InetAddress iscsiCxnRemoteAddr(8) | +-- r-n InetPortNumber iscsiCxnRemotePort(9) | +-- r-n Unsigned32 iscsiCxnMaxRecvDataSegLength(1= 0) | +-- r-n Unsigned32 iscsiCxnMaxXmitDataSegLength(1= 1) | +-- r-n IscsiDigestMethod iscsiCxnHeaderIntegrity(12) | +-- r-n IscsiDigestMethod iscsiCxnDataIntegrity(13) | +-- r-n TruthValue iscsiCxnRecvMarker(14) | +-- r-n TruthValue iscsiCxnSendMarker(15) | +-- r-n Unsigned32 iscsiCxnVersionActive(16) Consider adding initial remote ip addr and port to this table. Editors: Not sure what the value in initial remote IP addr and port would = be - if they change wouldn't this be a new connection? | +--iscsiTarget(6) | | | | | +--iscsiTargetAttributesTable(1) | | | | | | | +--iscsiTargetAttributesEntry(1) [iscsiInstIndex,iscsiNodeIndex] | | | | | | | +-- r-n Counter32 iscsiTgtLoginFailures(1) | | | +-- r-n TimeStamp iscsiTgtLastFailureTime(2) | | | +-- r-n AutonomousType iscsiTgtLastFailureType(3) | | | +-- r-n IscsiName iscsiTgtLastIntrFailureName(4) | | | +-- r-n InetAddressType iscsiTgtLastIntrFailureAddrType(5) | | | +-- r-n InetAddress iscsiTgtLastIntrFailureAddr(6) | | +--iscsiTargetLoginStatsTable(2) | | | | | | | +--iscsiTargetLoginStatsEntry(1) [iscsiInstIndex,iscsiNodeIndex] | | | | | | | +-- r-n Counter32 iscsiTgtLoginAccepts(1) | | | +-- r-n Counter32 iscsiTgtLoginOtherFails(2) | | | +-- r-n Counter32 iscsiTgtLoginRedirects(3) | | | +-- r-n Counter32 iscsiTgtLoginAuthorizeFails(4) | | | +-- r-n Counter32 iscsiTgtLoginAuthenticateFails(5) | | | +-- r-n Counter32 iscsiTgtLoginNegotiateFails(6) | | +--iscsiTargetLogoutStatsTable(3) | | | | | +--iscsiTargetLogoutStatsEntry(1) [iscsiInstIndex,iscsiNodeIndex] | | | | | +-- r-n Counter32 iscsiTgtLogoutNormals(1) | | +-- r-n Counter32 iscsiTgtLogoutOthers(2) | +--iscsiTgtAuthorization(7) | | | | | +--iscsiTgtAuthAttributesTable(1) | | | | | +--iscsiTgtAuthAttributesEntry(1) [iscsiInstIndex,iscsiNodeIndex= ,iscsiTgtAuthIndex] | | | | | +-- --- Unsigned32 iscsiTgtAuthIndex(1) | | +-- rwn RowStatus iscsiTgtAuthRowStatus(2) | | +-- rwn RowPointer iscsiTgtAuthIdentity(3) | | +-- rwn StorageType iscsiTgtAuthStorageType(4) Additional Comments: There's no information in any of this regarding iSCSI discovery information. That would be potentially useful information, especially in the case of discovered targets that have no sessions. That could be an indication of a network problem of a mis-configuration. The type of discovery performed and the discovered targets could be put in there and provide this information. Editors: This MIB module currently represents only the initiators and targe= ts provided by the entity being queried. The remote objects do not appear = here and are part of someone else's entity. So if you had a target-only de= vice, it wouldn't have objects for the initiators connecting to it and vise= -versa. Since we don't currently support remote objects, adding this capability wou= ld be a significant new MIB development by the WG, rather than a fix given = the current review. End of File. ::DISCLAIMER:: ---------------------------------------------------------------------------= ------------------------------------------------------------------------- The contents of this e-mail and any attachment(s) are confidential and inte= nded for the named recipient(s) only. E-mail transmission is not guaranteed to be secure or error-free as informa= tion could be intercepted, corrupted, lost, destroyed, arrive late or incomplete, or may contain viruses in trans= mission. The e mail and its contents (with or without referred errors) shall therefore not attach any liability = on the originator or HCL or its affiliates. Views or opinions, if any, presented in this email are solely those of the = author and may not necessarily reflect the views or opinions of HCL or its affiliates. Any form of reproduction, disse= mination, copying, disclosure, modification, distribution and / or publication of this message without the prior written= consent of authorized representative of HCL is strictly prohibited. If you have received this email in error please= delete it and notify the sender immediately. Before opening any email and/or attachments, please check them for viruses = and other defects. ---------------------------------------------------------------------------= ------------------------------------------------------------------------- --_000_62DC16C614A9554F81C8E2E5C174A98837D8636D4ECHNHCLTEVS16H_ Content-Type: text/html; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable

Hi All,

We have posted the next = version, 02, of the iSCSI MIB module draft. This includes the following changes:

= ·      =   Updated the Intellectual Property Section

= ·      =   Fixed incorrect reference to iscsiInstSsnErrorStatsTable. This has been changed to iscsiInstanceSsnErrorStatsTable.

= ·      =   Changed refere= nce to MIB as MIB module

= ·      =   Included edito= rs note to IANA Considerations

= ·      =   Added editors = note on fixing 'RFC cccc'

= ·      =   Fixed referenc= es in MIB module not found in normative (sec 10.1)

= ·      =   Updated iscsiNodeAttributesEntry description

= ·      =   Updated low wo= rd counter to 32 bit SNMPv1 counter

= ·      =   Corrected REFE= RENCE for iscsiIntrAuthIdentity

= ·      =   Updated Descri= ption for iscsiSsnCxnDigestErrors, iscsiSsnCxnTimeoutErrors

= ·      =   Added SCSI-MIB= RFC and section references on iscsiNodeTransportType

= ·      =   Clarified the = three IPS-AUTH MIB references to refer to ipsAuthIdentAttributesEntry object=

 =

http://www.ietf.org/internet-drafts/draft-ietf-storm-iscsimib-02.txt=

 

 

The IETF datatracker page for this Internet-Draft i= s:

https:= //datatracker.ietf.org/doc/draft-ietf-storm-iscsimib/

 

Diff from previous version:

= http://tools.ietf.org/rfcdiff?url2=3Ddraft-ietf-storm-iscsimib-02<= /o:p>

 =

regards

Prakash

 =

From: Mark Bakke [mailto:Mark_Bakke@DELL.com]
Sent: Wednesday, July 11, 2012 6:36 PM
To: Storm (storm@ietf.org)
Cc: david.black@emc.com; Prakash Venkatesen, ERS-HCLTech; ttalpey@microsoft.com; mrm@vmware.com
Subject: FW: MIB Doctor Review for iSCSI MIB, proposed changes, and = list questions

 

 

Everyone,

 

We are in the process of updating the iSCSI MIB module= , to match the latest storm changes.  Mike MacFaden has also done a MIB Doc= tor review, which brought back a number of comments on things that are potentia= lly missing from the original iSCSI MIB RFC.

 

Prakash, David, Tom and I have been reviewing the MIB = doctor requests.  This message is intended to answer some of the MIB doctor comments as well as generate discussion on the list about possible changes.  We intend to post another draft (-02) before the July 16th deadline for the next round of discussion.

 

Here is a brief summary.  The full responses to comments are below.

·      =   Several editorial changes

·      =   A few new fields are added to objects that a= re either useful or were missed the first time around

·      =   More complex additions that we believe will = need a separate revision and may affect the object model.  The latter chang= es would require support from those intending to implement or use them.

 

I will start separate discussion threads on a few item= s:

·      =   Heartbeat counters for NOP-In and NOP-Out us= age

·      =   TCP MIB correlation for sessions and connect= ions

·      =   iscsiInstanceSsnErrorStatsTable session deta= ils

 

For reference, we have:

·      =   The previous draft of the new iSCSI MIB - http://www= .ietf.org/id/draft-ietf-storm-iscsimib-01.txt

·      =   The initial MIB doctor review - http://www.m= acfaden.com/ietf/iscsi-mib-1-reviewed.txt

·      =   An additional MIB doctor review with VMware = engineers - http://macfaden.= com/ietf/iscsi-mib-notes.txt

 

Detailed responses to MIB doctor review:

 

February 17, 2012 MIB DO= CTOR Review: http://www.ietf.org/id/draft-ietf-storm-iscsimib-01.txt 

 =

Performed by Michael R. MacFaden, VMware, Inc

According to http://tools.ietf.org/html/rfc4= 181

 =

This review only covers = syntax, SMIv2 rules usage of the MIB module itself, not the draft.

Some of the things menti= oned below exist the prior version of the mib, not this update.

 =

1 boiler plate - check

2. Narrative Sections - = check

3. Security Consideratio= ns - check

4. IANA Considerations -= missing editors’ note.

   Sectio= n 9 needs the following verbiage to be added.

    =    Editor's Note (to be removed prior to publication):  this draft

    =   makes no additional requests of the IANA.

 =

Editors: We will fix = this.

 =

5. No new namespaces

6. References section - = check

7. copyright notice - ch= eck

8. Intellectual Property= section – missing

 =

Editors: We will add = the section:

 

          &n= bsp; Copyright (c) 2011 IETF Trust and the persons identified as

          &n= bsp; authors of the code.  All rights reserved.

 

          &n= bsp; Redistribution and use in source and binary forms, with or

          &n= bsp; without modification, is permitted pursuant to, and subject

          &n= bsp; to the license terms contained in, the Simplified BSD

          &n= bsp; License set forth in Section 4.c of the IETF Trust's Legal

          &n= bsp; Provisions Relating to IETF Documents

          &n= bsp; (http:/= /trustee.ietf.org/license-info)."

 

 =

9. This change updates e= xisting mib rfc http://www.ietf.org= /rfc/rfc4544.txt - check

   Backward compatibility checks: (oids, object-identities, remained the same)

 =

Other items checked --

syntax check: smilint -l= 9 - no errors

smicng : not run

spelling: Aspell --- no misspellings found.

URLs validated: checked = for valid, not-broken links:

    =          http://www.ian= a.org/assignments/protocol-numbers

 =

References in MIB module=   not found in normative (sec 10.1)

IscsiTransportProtocol TC ->  "RFC791, RFC1700

 =

 =

Editors: We will fix = this.

 =

 =

enumerations: each eleme= nt described

  - IscsiDiges= tMethod

 =

Editors: We had this = in the description – is there something else that needs to be added?

 =

DiscontinuityTime is syn= tax: TimeStamp

All Counters: define the= ir discontinuity timestamp.

 =

Editors: We checked t= he descriptions in each of the Counter32 and Counter64 fields, and they all reference a discontinuity timestamp.  Isn’t that enough?

 =

Uncommon stuff:

1)  In IscsiPortalAttributesEntry has RowStatus as second item in the conceptual r= ow,

not after iscsiPortalStorageType.

 =

Editors: We currently don’t put StorageType and RowStatus together in any of our objects, a= nd didn’t originally realize there was some tradition around this.  Changing numbering now would cause backward compatibility problems, so we cannot make this change.

 =

2) iscsiPortalRoles does= not have a DEFVAL when most others do in this conceptual table.

iscsiPortalAddrType has = def val of IPV4? when the iscsiPortalAddr has no default to go with it?

 =

Editors:  There isn’t a reasonable DEFVAL for iscsiPortalRoles.  It has to be set when creating the row, so we will leave this one.

 =

3) iscsiNodeAttributesEntry  sez:

   An entry (r= ow) containing mana

   vs 'concept= ual row' which is used inconsistently.

 =

Editors: We will chan= ge this description from:

 

An entry (row) containing management in=
formation applicable
        to a parti=
cular iSCSI node.

 

To<= /b>

 

A conceptual row containing management =
information applicable
        to a parti=
cular iSCSI node.

 =

 =

4)  (e.g. not creat= ed via this MIB).  vs MIB module. There is but one MIB as Dr Case would say.<= o:p>

 =

Editors: We will fix = this one.

 =

5) 64 bit counters with = SNMPv1 support for 32 bit high/low? kinda

  iscsiSsnTxDataOct= ets, iscsiSsnRxDataOctets, provides only low word: iscsiSsnLCTxDataOctets, iscsiSsnLCRxDataOctets

  Compliance phrasi= ng is a bit odd:

   "= A Low Capacity shadow object of iscsiSsnTxDataOctets

    =     for those systems that don't support Counter64.

    inste= ad of 'for those systems which are accessible via SNMPv1 only'<= /p>

 =

Editors:  We wil= l fix the wording for SNMPv1.  We don’t see a reason to add objects for high octets.

 =

6) Notifications are req= uired to have a rate limited implementation by a description,

   yet th= e number of times the failure occurred   is not conveyed in the notifcation varbind list.

    iscsiTgtLoginFailure, iscsiIntrLoginFailure, iscsiInstSessionFailure

 =

    To av= oid sending an excessive number of notifications due

    =     to multiple errors counted, an SNMP agent implementing this

    =     notification SHOULD NOT send more than 3 notifications of=

    =     this type in any 10-second time period."

 =

Editors:  We bel= ieve that this is covered by the counter “iscsiTgtLoginFailures”:

 = 

iscsiTgtLoginFailure NOTIFICATION-TYPE
    OBJECTS {
<= pre>        iscsiTgtLo= ginFailures,
        iscsiTgtLa=
stFailureType,
        iscsiTgtLa=
stIntrFailureName,
        iscsiTgtLa=
stIntrFailureAddrType,
        iscsiTgtLa=
stIntrFailureAddr
    }

 =

 =

The following section ad= dresses comments from the VMware iSCSI-MIB review:

 =

 =

Notes from VMware ISCIS-MIB review meeting

March 21, 2012

Attendees: Andy Banta, Kun Huang, Mike MacFaden

 

General comments:

1. Many objects lacking REFERENCE clause or offer only vague references.

For those managed objects having a Reference clause, nedd to f= ix up 'RFC cccc'

For example: "RFC cccc, Section 7.5, Connection Timeout Management"

Example of vague reference:

    REFERENCE

        "SCSI-MIB"= ;

 

 

Editors: OK, we can update in the next draft.

 

 

2. Descriptions are short and simple but in some case seem a b= it too short

for an IETF standard mib module.

 

 

Editors: We can look for opportunities to clarify but don’t think we want to go through and rewrite a lot.  If there a= re particular descriptions that cause confusion please bring them up.

 

 

Here's the comments by object in the MIB module: draft-ietf-storm-iscsimib-01.txt

 

iscsiMibModule(1.3.6.1.2.1.142)

  |

  +--iscsiNotifications(0)

  |  |

  |  +--iscsiTgtLoginFailure(1) [iscsiTgtLoginFailures,iscsiTgtLastFailureType,iscsiTgtLastIntrFailureName,= iscsiTgtLastIntrFailureAddrType,iscsiTgtLastIntrFailureAddr]

 

Consider adding port number.

 

 

Editors: LastFailurePortNumber would be easy enough to add.  Should we do an OrZero for implementations that can’t get = the port number?

 

 

  |  +--iscsiIntrLoginFailure(2) [iscsiIntrLoginFailures,iscsiIntrLastFailureType,iscsiIntrLastTgtFailureNam= e,iscsiIntrLastTgtFailureAddrType,iscsiIntrLastTgtFailureAddr]

 

Can't determine if the failure is due to failure of the underl= ying transport or not.

When transport is TCP there should be some way to get to the TCP-MIB/TCP-ESTATS-MIB diagnostics.

See notes on iscsiInstanceSsnErrorStatsTable.

 

Consider adding port number. 

 

 

Editors: Same as above.  On the failure, is it useful to have both local and remote addr and port number?  Will the TCP MIB keep these connections around long enough to go index it on a failed connection?  If we add these fields, will someone use them?=

 

 

  |  +--iscsiInstSessionFailure(3) [iscsiInstSsnFailures,iscsiInstLastSsnFailureType,iscsiInstLastSsnRmtNodeNa= me]

 

 

Consider handling the event "Target Unmapped"  = by updatingiscsiInstLastSsnFailureType of a Session failure, as well.

 

 

Editors: FailureType is an OID pointing to a stat in iscsiInstSsnErrorStatsTable, so we would need to add to this:

 

    iscsiInstSsnTgtUnmappedErrors       Counter32=

 

Are there others that would be needed?=

 

 

Consider adding summary notification in the case of larger sca= les (number of targets)

what about large scales, # of targets, each target have a fail= ure of similar sort.

 

 

Editors: Would such a notification really be used?  If there was a large scale failure of many targets, we believe the administrat= or would see enough of the notifications to notice it as a larger problem.

 

 

<snip>

 

  |  |  +--iscsiInstanceSsnErrorStatsTable(2)

  |  |     |

  |  |     +--iscsiInstanceSsnErrorStatsEntry(1) [iscsiInstIndex]

  |  |        |

  |  |        +--= r-n Counter32 iscsiInstSsnDigestErrors(1)

  |  |        +--= r-n Counter32 iscsiInstSsnCxnTimeoutErrors(2)

  |  |        +--= r-n Counter32 iscsiInstSsnFormatErrors(3)

 

Related states for transport are not provided in this table. Either a RowPointer

to another mib module is needed or a generic transport counter= to indicate failure

at that layer was detected by iscsiInstance.=

 

 

Editors: If connection timeout errors are seen, wouldn’= ;t the user check transport connectivity via ping and other tools?  We are not sure that adding more objects here would add enough value.

 

 

Consider separate counters for HB vs data timeouts.=

Consider specific heartbeat no-op timeout error countes.<= /o:p>

 

 

Editors: We will start another thread for this discussion.&n= bsp; It does seem useful since most implementations use NOP for keep-alive heartbeats.

 

 

  |  +--iscsiPortal(2)

  |  |  |

  |  |  +--iscsiPortalAttributesTable(1)

  |  |     |

  |  |     +--iscsiPortalAttributesEntry(1) [iscsiInstIndex,iscsiPortalIndex]

  |  |        |

  |  |        +--= --- Unsigned32           = ;  iscsiPortalIndex(1)

  |  |        +--= rwn RowStatus              isc= siPortalRowStatus(2)

  |  |        +--= rwn Bits            = ;       iscsiPortalRoles(3)

  |  |        +--= rwn InetAddressType        iscsiPortalAddrType(4)

  |  |        +--= rwn InetAddress          &nbs= p; iscsiPortalAddr(5)

  |  |        +--= rwn IscsiTransportProtocol iscsiPortalProtocol(6)

  |  |        +--= rwn Unsigned32           = ;  iscsiPortalMaxRecvDataSegLength(7)

  |  |        +--= rwn IscsiDigestMethod      iscsiPortalPrimaryHdrDigest= (8)

  |  |        +--= rwn IscsiDigestMethod      iscsiPortalPrimaryDataDiges= t(9)

  |  |        +--= rwn IscsiDigestMethod      iscsiPortalSecondaryHdrDigest(10)

  |  |        +--= rwn IscsiDigestMethod      iscsiPortalSecondaryDataDig= est(11)

  |  |        +--= rwn TruthValue           = ;  iscsiPortalRecvMarker(12)

  |  |        +--= rwn StorageType          &nbs= p; iscsiPortalStorageType(13)

 

Digests are negotiated and implementations may have additional levels (tertiary, quaternary)

as well as constraints that are not modelled here. =

 

 

Editors: There’s only one standardized digest method currently in use (CRC32C) that we know of.  Are there implementations = that extend this beyond two?

 

 

Digests can also be configured in iscsiNodeAttributesTable. (Is there a prececence between node and portal?)

 

 

Editors: There is no digests field currently in NodeAttributesTable, so Portal is the only place to configure it.

 

 

Need to be able to set/show port number as well as iscsiPortalAddr.

 

 

Editors: We can add this one.

 

 

Regarding iscsiCxnRecvMarker, iscsiCxnSendMarker these are to be  deprecated and are redundant in session and connection.=

 

 

Editors: These will be removed.  The V2 object groups in the draft do not contain the deprecated objects.

          &n= bsp;         

 

** note: I Checked with INET-ADDRESS-MIB about iscsiPortalAddrType, if set to 16

      dns(16)    = A DNS domain name as defined by the

        InetAddressDNS text= ual convention.

      Then iscsiPortalAddr can be a d= ns hostname.

 

Appears the MIB Portal Attributes and Node Atributes are sort = os a

mish-mash or Node, Lhba, Phba, various Portal properties.=

 

 

Editors:  Not sure we understand this one – the M= IB follows iSCSI node and portal definitions for portals and nodes.  HBAs= are outside the scope of the MIB and of iSCSI.

 

 

Using a table rather than Primary and Secondary would be the r= ight

approach for Header and Data digests, since the whole point of these

negotiations is to provide a list of what each side is willing= to

settle on.

 

 

Editors: Technically, yes, but practically it seems over-complicated.

 

 

Additionally, a list for authentication negotiation would be useful,

also.  There are five different authentication methods defined by the

original RFC 3720, and a few additional ones that have since sprung

up.

 

 

Editors: Isn’t the list of authorized entities suffici= ent, since the methods are included by reference?]

 

 

There's also the idea of mutual authentication, where each sid= e

verfies the identity of the other, rathern than just a target<= o:p>

authenticatiing a host.

 

 

Editors: Is this comment referring to the iscsiSsnAuthIdentity?  We do see that this is just one per session, an= d we didn’t identify it as an initiator or target identity (most people li= kely assumed initiator).

 

We’d need to change this name to iscsiSsnAuthIntrIdent= ity and add iscsiSsnAuthTgtIdentity to show both identities in a session where = this is used.

 

 

Additional useful information at the Portal level might be at least

some identification of what type of initiator it is, and some<= o:p>

identifying information about it. Maybe not the level of detail you'll

find in IMA_PHBA_PROPERTIES, but the model, description and version.

 

Editors: this seems useful for troubleshooting.  We can= add something similar to iscsiInstDescr:

 

iscsiPortalDescr OBJECT-TYPE

    SYNTAX        SnmpAdminString=

    MAX-ACCESS    read-only

    STATUS        current<= /b>

    DESCRIPTION

        "A UTF-8 str= ing, determined by the implementation to

        describe the iSCSI portal.  When only a single instance

        is present, this object may be set to the zero-length

        string; with mult= iple iSCSI portals, it may be used in

        an implementation-dependent manner to describe the

        respective portal, and could include information such as

        HBA model, description and version or software driver and

        version."

 

I don’t think that we’d want to try to structure= it more than just a string.

 

 

<snip>

 

  |  +--iscsiNode(5)

  |  |  |

  |  |  +--iscsiNodeAttributesTable(1)

  |  |     |

  |  |     +--iscsiNodeAttributesEntry(1) [iscsiInstIndex,iscsiNodeIndex]

  |  |        |

  |  |        +--= --- Unsigned32      iscsiNodeIndex(1)

  |  |        +--= r-n IscsiName       iscsiNodeName(2)

  |  |        +--= r-n SnmpAdminString iscsiNodeAlias(3)

  |  |        +--= r-n Bits            iscsiNodeRoles(4)

  |  |        +--= r-n RowPointer      iscsiNodeTransportType(5)

  |  |        +--= r-n TruthValue      iscsiNodeInitialR2T(6)<= /span>

  |  |        +--= rwn TruthValue      iscsiNodeImmediateData(7)

  |  |        +--= rwn Unsigned32      iscsiNodeMaxOutstandingR2T(8)=

  |  |        +--= rwn Unsigned32      iscsiNodeFirstBurstLength(9)<= /o:p>

  |  |        +--= rwn Unsigned32      iscsiNodeMaxBurstLength(10)

  |  |        +--= rwn Unsigned32      iscsiNodeMaxConnections(11)

  |  |        +--= rwn TruthValue      iscsiNodeDataSequenceInOrder(12)

  |  |        +--= rwn TruthValue      iscsiNodeDataPDUInOrder(13)

  |  |        +--= rwn Unsigned32      iscsiNodeDefaultTime2Wait(14)=

  |  |        +--= rwn Unsigned32      iscsiNodeDefaultTime2Retain(15)

  |  |        +--= rwn Unsigned32      iscsiNodeErrorRecoveryLevel(16)

  |  |        +--= r-n TimeStamp       iscsiNodeDiscontinuityTime(17= )

  |  |        +--= rwn StorageType     iscsiNodeStorageType(18)

 

Digests as found in scsiPortalAttributesTable, may be provisio= ned at this level.

 

 

Editors: Is there a need to provision digest at this level v= ia the MIB module?

 

 

  |  +--iscsiInitiator(8)

  |  |  |

  |  |  +--iscsiInitiatorAttributesTable(1)

  |  |  |  |

  |  |  |  +--iscsiInitiatorAttributesEntr= y(1) [iscsiInstIndex,iscsiNodeIndex]

  |  |  |     |<= /span>

  |  |  |     +-- r-n Counter32       iscsiIntrLoginFailures(1)

  |  |  |     +-- r-n TimeStamp       iscsiIntrLastFailureTime(2)

  |  |  |     +-- r-n AutonomousType  iscsiIntrLastFailureType(3)

  |  |  |     +-- r-n IscsiName       iscsiIntrLastTgtFailureName(4= )

  |  |  |     +-- r-n InetAddressType iscsiIntrLastTgtFailureAddrType(5)

  |  |  |     +-- r-n InetAddress     iscsiIntrLastTgtFailureAddr(6)

 

No port number provided.

 

 

Editors: We will add iscsiIntrLastTgtFailurePort<= /span>

 

 

  |  |  +--iscsiInitiatorLoginStatsTable(2)

  |  |  |  |

  |  |  |  +--iscsiInitiatorLoginStatsEntr= y(1) [iscsiInstIndex,iscsiNodeIndex]

  |  |  |     |<= /span>

  |  |  |     +-- r-n Count= er32 iscsiIntrLoginAcceptRsps(1)

  |  |  |     +-- r-n Count= er32 iscsiIntrLoginOtherFailRsps(2)

  |  |  |     +-- r-n Count= er32 iscsiIntrLoginRedirectRsps(3)

  |  |  |     +-- r-n Count= er32 iscsiIntrLoginAuthFailRsps(4)

  |  |  |     +-- r-n Count= er32 iscsiIntrLoginAuthenticateFails(5)

  |  |  |     +-- r-n Count= er32 iscsiIntrLoginNegotiateFails(6)

 

No way to get to transport layer (tcp, etc) related errors not shown here or provided through RowPointer/etc.

 

 

Editors: We are not sure that this will add enough value.

 

 

  |  |  +--iscsiInitiatorLogoutStatsTable(3)

  |  |     |

  |  |     +--iscsiInitiatorLogoutStatsEntry(1) [iscsiInstIndex,iscsiNodeIndex]

  |  |        |

  |  |        +--= r-n Counter32 iscsiIntrLogoutNormals(1)

  |  |        +--= r-n Counter32 iscsiIntrLogoutOthers(2)

 

The counter iscsiIntrLogoutOthers does not cover cases where no ack is returned (timeout case) due

to failure of transport to deliver logout ack.

 

 

Editors: Adding a timeout counter for this seems to make sen= se.

          &n= bsp;            = ; 

 

  |  +--iscsiIntrAuthorization(9)

  |  |  |

  |  |  +--iscsiIntrAuthAttributesTable(1)=

  |  |     |

  |  |     +--iscsiIntrAuthAttributesEntry(1) [iscsiInstIndex,iscsiNodeIndex,iscsiIntrAuthIndex]

  |  |        |

  |  |        +--= --- Unsigned32  iscsiIntrAuthIndex(1)

  |  |        +--= rwn RowStatus   iscsiIntrAuthRowStatus(2)

  |  |        +--= rwn RowPointer  iscsiIntrAuthIdentity(3)

  |  |        +--= rwn StorageType iscsiIntrAuthStorageType(4)

 

The reference for iscsiIntrAuthIdentity is too vague. Only provides the RFC?:

REFERENCE

        "IPS-AUTH MIB,= RFC 4545"

 

Editors: We will fix this.

 

  |  +--iscsiSession(10)

  |  |  |

  |  |  +--iscsiSessionAttributesTable(1)<= /o:p>

  |  |  |  |

  |  |  |  +--iscsiSessionAttributesEntry(= 1) [iscsiInstIndex,iscsiSsnNodeIndex,iscsiSsnIndex]

  |  |  |     |<= /span>

  |  |  |     +-- --- Unsigned32      iscsiSsnNodeIndex(1)

  |  |  |     +-- --- Unsigned32      iscsiSsnIndex(2)=

  |  |  |     +-- r-n Enumeration     iscsiSsnDirection(3)<= /p>

  |  |  |     +-- r-n IscsiName       iscsiSsnInitiatorName(4)=

  |  |  |     +-- r-n IscsiName       iscsiSsnTargetName(5)

  |  |  |     +-- r-n Unsigned32      iscsiSsnTSIH(6)<= /p>

  |  |  |     +-- r-n OctetString     iscsiSsnISID(7)

  |  |  |     +-- r-n SnmpAdminString iscsiSsnInitiatorAlias(8)

  |  |  |     +-- r-n SnmpAdminString iscsiSsnTargetAlias(9)

  |  |  |     +-- r-n TruthValue      iscsiSsnInitialR2T(10)<= /span>

  |  |  |     +-- r-n TruthValue      iscsiSsnImmediateData(11)

  |  |  |     +-- r-n Enumeration     iscsiSsnType(12)

  |  |  |     +-- r-n Unsigned32      iscsiSsnMaxOutstandingR2T(13)=

  |  |  |     +-- r-n Unsigned32      iscsiSsnFirstBurstLength(14)<= /o:p>

  |  |  |     +-- r-n Unsigned32      iscsiSsnMaxBurstLength(15)

  |  |  |     +-- r-n Gauge32         iscsiSsnConnectionN= umber(16)

  |  |  |     +-- r-n RowPointer      iscsiSsnAuthIdentity(17)

  |  |  |     +-- r-n TruthValue      iscsiSsnDataSequenceInOrder(18)

  |  |  |     +-- r-n TruthValue      iscsiSsnDataPDUInOrder(19)

  |  |  |     +-- r-n Unsigned32      iscsiSsnErrorRecoveryLevel(20)

  |  |  |     +-- r-n TimeStamp       iscsiSsnDiscontinuityTime(21)=

 

Consider reporting the digest negotiated for this session.

Consider reporting the error-recovery-level (ERL).<= /span>

Consider reporting type(?) negotiated.

 

  |  |  +--iscsiSessionStatsTable(2)=

  |  |  |  |

  |  |  |  +--iscsiSessionStatsEntry(1) [iscsiInstIndex,iscsiSsnNodeIndex,iscsiSsnIndex]

  |  |  |     |<= /span>

  |  |  |     +-- r-n Count= er32 iscsiSsnCmdPDUs(1)

  |  |  |     +-- r-n Count= er32 iscsiSsnRspPDUs(2)

  |  |  |     +-- r-n Count= er64 iscsiSsnTxDataOctets(3)

  |  |  |     +-- r-n Count= er64 iscsiSsnRxDataOctets(4)

  |  |  |     +-- r-n Count= er32 iscsiSsnLCTxDataOctets(5)

  |  |  |     +-- r-n Count= er32 iscsiSsnLCRxDataOctets(6)

 

Consider reporting missing PDU.

Break down counters for data pdus in and out.

Add counter for async pdus in.

 

 

Editors: The above seem like good ideas – will anyone = use these?  Also, breaking down the existing counters might break current implementations.  We would likely have to create new ones.<= /span>

 

 

  |  |  +--iscsiSessionCxnErrorStatsTable(3)

  |  |     |

  |  |     +--iscsiSessionCxnErrorStatsEntry(1) [iscsiInstIndex,iscsiSsnNodeIndex,iscsiSsnIndex]

  |  |        |

  |  |        +--= r-n Counter32 iscsiSsnCxnDigestErrors(1)

  |  |        +--= r-n Counter32 iscsiSsnCxnTimeoutErrors(2)

 

Description should discuss when these counters are most likely provided such as when the error-recovery-level

is 1 or 2.

 

 

Editors: We will update the descriptions.<= /b>

 

 

  |  +--iscsiConnection(11)

  |     |

  |     +--iscsiConnectionAttributesTable(1)

  |        |

  |        +--iscsiConnectionAttributesEntry(1) [iscsiInstIndex,iscsiSsnNodeIndex,iscsiSsnIndex,iscsiCxnIndex]

  |           |<= /span>

  |           +-- --- Unsigned32           = ;  iscsiCxnIndex(1)

  |           +-- r-n Unsigned32           = ;  iscsiCxnCid(2)

  |           +-- r-n Enumeration          &nbs= p; iscsiCxnState(3)

  |           +-- r-n InetAddressType        iscsiCxnAddrType(= 4)

  |           +-- r-n InetAddress          &nbs= p; iscsiCxnLocalAddr(5)

  |           +-- r-n IscsiTransportProtocol iscsiCxnProtocol(6)

  |           +-- r-n InetPortNumber         iscsiCxnLocalPort(7)

  |           +-- r-n InetAddress            iscsiCxnRemoteA= ddr(8)

  |           +-- r-n InetPortNumber         iscsiCxnRemotePort(9)

  |         =   +-- r-n Unsigned32           = ;  iscsiCxnMaxRecvDataSegLength(10)

  |           +-- r-n Unsigned32           = ;  iscsiCxnMaxXmitDataSegLength(11)

 |         &= nbsp; +-- r-n IscsiDigestMethod      iscsiCxnHeaderIntegrity(12)

  |           +-- r-n IscsiDigestMethod      iscsiCxnDataIntegrity(13)

  |           +-- r-n TruthValue           = ;  iscsiCxnRecvMarker(14)

  |           +-- r-n TruthValue           = ;  iscsiCxnSendMarker(15)

  |           +-- r-n Unsigned32           = ;  iscsiCxnVersionActive(16)

 

Consider adding initial remote  ip addr and port to this table.

 

 

Editors:  Not sure what the value in initial remote IP = addr and port would be – if they change wouldn’t this be a new connection?

 

 

  |  +--iscsiTarget(6)

  |  |  |

  |  |  +--iscsiTargetAttributesTable(1)

  |  |  |  |

  |  |  |  +--iscsiTargetAttributesEntry(1) [iscsiInstIndex,iscsiNodeIndex]

  |  |  |     |<= /span>

  |  |  |     +-- r-n Counter32       iscsiTgtLoginFailures(1)=

  |  |  |     +-- r-n TimeStamp       iscsiTgtLastFailureTime(2)

  |  |  |     +-- r-n AutonomousType  iscsiTgtLastFailureType(3)

  |  |  |     +-- r-n IscsiName       iscsiTgtLastIntrFailureName(4= )

  |  |  |     +-- r-n InetAddressType iscsiTgtLastIntrFailureAddrType(5)

  |  |  |     +-- r-n InetAddress     iscsiTgtLastIntrFailureAddr(6)

 

 

  |  |  +--iscsiTargetLoginStatsTable(2)

  |  |  |  |

  |  |  |  +--iscsiTargetLoginStatsEntry(1) [iscsiInstIndex,iscsiNodeIndex]

  |  |  |     |<= /span>

  |  |  |     +-- r-n Count= er32 iscsiTgtLoginAccepts(1)

  |  |  |     +-- r-n Count= er32 iscsiTgtLoginOtherFails(2)

  |  |  |     +-- r-n Count= er32 iscsiTgtLoginRedirects(3)

  |  |  |     +-- r-n Count= er32 iscsiTgtLoginAuthorizeFails(4)

  |  |  |     +-- r-n Count= er32 iscsiTgtLoginAuthenticateFails(5)

  |  |  |     +-- r-n Count= er32 iscsiTgtLoginNegotiateFails(6)

 

  |  |  +--iscsiTargetLogoutStatsTable(3)<= /o:p>

  |  |     |

  |  |     +--iscsiTargetLogoutStatsEntry(1) [iscsiInstIndex,iscsiNodeIndex]

  |  |        |

  |  |        +--= r-n Counter32 iscsiTgtLogoutNormals(1)

  |  |        +--= r-n Counter32 iscsiTgtLogoutOthers(2)

 

  |  +--iscsiTgtAuthorization(7)

  |  |  |

  |  |  +--iscsiTgtAuthAttributesTable(1)<= /o:p>

  |  |     |

  |  |     +--iscsiTgtAuthAttributesEntry(1) [iscsiInstIndex,iscsiNodeIndex,iscsiTgtAuthIndex]

  |  |        |

  |  |        +--= --- Unsigned32  iscsiTgtAuthIndex(1)

  |  |        +--= rwn RowStatus   iscsiTgtAuthRowStatus(2)

  |  |        +--= rwn RowPointer  iscsiTgtAuthIdentity(3)

  |  |        +--= rwn StorageType iscsiTgtAuthStorageType(4)

 

 

Additional Comments:

 

There's no information in any of this regarding iSCSI discover= y

information.  That would be potentially useful informatio= n,

especially in the case of discovered targets that have no sessions.

That could be an indication of a network problem of a

mis-configuration.  The type of discovery performed and t= he discovered

targets could be put in there and provide this information.

 

Editors: This MIB module currently represents only the initiators and targets provided by the entity being queried.  The remo= te objects do not appear here and are part of someone else’s entity.&nbs= p; So if you had a target-only device, it wouldn’t have objects for the initiators connecting to it and vise-versa.

 

Since we don’t currently support remote objects, adding this capability would be a significant new MIB development by the WG, rather than a fix given the current review.

 

 

 

End of File.

 =

 



::DISCLAIMER= ::
---------------------------------------------------------------------= ---------------------------------------------------------------------------= ----

The contents of thi= s e-mail and any attachment(s) are confidential and intended for the named = recipient(s) only.
E-mail transmission is not guaranteed to be secure or= error-free as information could be intercepted, corrupted,
lost, destr= oyed, arrive late or incomplete, or may contain viruses in transmission. Th= e e mail and its contents
(with or without referred errors) shall there= fore not attach any liability on the originator or HCL or its affiliates. <= br>Views or opinions, if any, presented in this email are solely those of t= he author and may not necessarily reflect the
views or opinions of HCL = or its affiliates. Any form of reproduction, dissemination, copying, disclo= sure, modification,
distribution and / or publication of this message w= ithout the prior written consent of authorized representative of
HCL is= strictly prohibited. If you have received this email in error please delet= e it and notify the sender immediately.
Before opening any email and/or= attachments, please check them for viruses and other defects.

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

--_000_62DC16C614A9554F81C8E2E5C174A98837D8636D4ECHNHCLTEVS16H_-- From internet-drafts@ietf.org Mon Jul 16 11:40:22 2012 Return-Path: X-Original-To: storm@ietfa.amsl.com Delivered-To: storm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D813921F8820; Mon, 16 Jul 2012 11:40:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.455 X-Spam-Level: X-Spam-Status: No, score=-102.455 tagged_above=-999 required=5 tests=[AWL=0.144, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 97KnG70a32C5; Mon, 16 Jul 2012 11:40:21 -0700 (PDT) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 04FF621F87A1; Mon, 16 Jul 2012 11:40:19 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 4.30p3 Message-ID: <20120716184019.16394.70723.idtracker@ietfa.amsl.com> Date: Mon, 16 Jul 2012 11:40:19 -0700 Cc: storm@ietf.org Subject: [storm] I-D Action: draft-ietf-storm-iscsi-cons-06.txt X-BeenThere: storm@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Storage Maintenance WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 16 Jul 2012 18:40:22 -0000 A New Internet-Draft is available from the on-line Internet-Drafts director= ies. This draft is a work item of the STORage Maintenance Working Group of the = IETF. Title : iSCSI Protocol (Consolidated) Author(s) : Mallikarjun Chadalapaka Julian Satran Kalman Meth David Black Filename : draft-ietf-storm-iscsi-cons-06.txt Pages : 344 Date : 2012-07-16 Abstract: This document describes a transport protocol for SCSI that works on top of TCP. The iSCSI protocol aims to be fully compliant with the standardized SCSI Architecture Model (SAM-2). RFC 3720 defined the original iSCSI protocol. RFC 3721 discusses iSCSI Naming examples and discovery techniques. Subsequently, RFC 3980 added an additional naming format to iSCSI protocol. RFC 4850 followed up by adding a new public extension key to iSCSI. RFC 5048 offered a number of clarifications and a few improvements and corrections to the original iSCSI protocol. This document obsoletes RFCs 3720, 3980, 4850 and 5048 by consolidating them into a single document and making additional updates to the consolidated specification. This document also updates RFC 3721 and RFC 3723. The text in this document thus supersedes the text in all the noted RFCs wherever there is a difference in semantics. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-storm-iscsi-cons There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-storm-iscsi-cons-06 A diff from previous version is available at: http://tools.ietf.org/rfcdiff?url2=3Ddraft-ietf-storm-iscsi-cons-06 Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From internet-drafts@ietf.org Mon Jul 16 12:33:14 2012 Return-Path: X-Original-To: storm@ietfa.amsl.com Delivered-To: storm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5501A21F87F7; Mon, 16 Jul 2012 12:33:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.484 X-Spam-Level: X-Spam-Status: No, score=-102.484 tagged_above=-999 required=5 tests=[AWL=0.115, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Sv1sTpXPZnoL; Mon, 16 Jul 2012 12:33:13 -0700 (PDT) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7151621F8701; Mon, 16 Jul 2012 12:33:13 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 4.30p3 Message-ID: <20120716193313.25597.87683.idtracker@ietfa.amsl.com> Date: Mon, 16 Jul 2012 12:33:13 -0700 Cc: storm@ietf.org Subject: [storm] I-D Action: draft-ietf-storm-iscsi-sam-06.txt X-BeenThere: storm@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Storage Maintenance WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 16 Jul 2012 19:33:14 -0000 A New Internet-Draft is available from the on-line Internet-Drafts director= ies. This draft is a work item of the STORage Maintenance Working Group of the = IETF. Title : Internet Small Computer Systems Interface (iSCSI) SCSI F= eatures Update Author(s) : Frederick Knight Mallikarjun Chadalapaka Filename : draft-ietf-storm-iscsi-sam-06.txt Pages : 1 Date : 2012-07-16 Abstract: Internet Small Computer Systems Interface (iSCSI) is a SCSI transport protocol that maps the SCSI family of protocols onto TCP/IP. The iSCSI protocol as specified in [draft-ietf-storm- iscsi-cons-xx] (and as previously specified by the combination of RFC 3720 and RFC 5048) is based on the SAM-2 (SCSI Architecture Model - 2) version of the SCSI family of protocols. This document defines enhancements to the iSCSI protocol to support certain additional features of the SCSI protocol that were defined in SAM-3, SAM-4, and SAM-5. This document is a companion document to [draft-ietf-storm- iscsi-cons-xx]. -------------------------------------------------------- RFC EDITORS NOTE: The above references to [draft-ietf-storm- iscsi-cons-xx] should reference the RFC number assigned to that document, and this note should be removed. -------------------------------------------------------- The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-storm-iscsi-sam There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-storm-iscsi-sam-06 A diff from previous version is available at: http://tools.ietf.org/rfcdiff?url2=3Ddraft-ietf-storm-iscsi-sam-06 Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From Frederick.Knight@netapp.com Mon Jul 16 13:06:17 2012 Return-Path: X-Original-To: storm@ietfa.amsl.com Delivered-To: storm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B348111E8275 for ; Mon, 16 Jul 2012 13:06:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.599 X-Spam-Level: X-Spam-Status: No, score=-10.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id OUcPOMfrMg3M for ; Mon, 16 Jul 2012 13:06:17 -0700 (PDT) Received: from mx2.netapp.com (mx2.netapp.com [216.240.18.37]) by ietfa.amsl.com (Postfix) with ESMTP id EB41111E8159 for ; Mon, 16 Jul 2012 13:06:16 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.77,596,1336374000"; d="scan'208";a="666199552" Received: from smtp1.corp.netapp.com ([10.57.156.124]) by mx2-out.netapp.com with ESMTP; 16 Jul 2012 13:07:02 -0700 Received: from vmwexceht03-prd.hq.netapp.com (vmwexceht03-prd.hq.netapp.com [10.106.76.241]) by smtp1.corp.netapp.com (8.13.1/8.13.1/NTAP-1.6) with ESMTP id q6GK72Gb012973 for ; Mon, 16 Jul 2012 13:07:02 -0700 (PDT) Received: from SACEXCMBX04-PRD.hq.netapp.com ([169.254.6.188]) by vmwexceht03-prd.hq.netapp.com ([10.106.76.241]) with mapi id 14.02.0298.004; Mon, 16 Jul 2012 13:07:02 -0700 From: "Knight, Frederick" To: "storm@ietf.org" Thread-Topic: [storm] I-D Action: draft-ietf-storm-iscsi-sam-06.txt Thread-Index: AQHNY4oCQU71ZSIz/E+fDHzXW/PsVJcsUoyA Date: Mon, 16 Jul 2012 20:07:01 +0000 Message-ID: References: <20120716193313.25597.87683.idtracker@ietfa.amsl.com> In-Reply-To: <20120716193313.25597.87683.idtracker@ietfa.amsl.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.104.60.115] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: [storm] FW: I-D Action: draft-ietf-storm-iscsi-sam-06.txt X-BeenThere: storm@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Storage Maintenance WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 16 Jul 2012 20:06:17 -0000 This posting is to make changes from the AD review: The original [RFC3720] was built based on the [SAM2] model for... To The original iSCSI protocol [RFC3720] was built based on the ... Nothing else changed (other than the dates). Fred -----Original Message----- From: storm-bounces@ietf.org [mailto:storm-bounces@ietf.org] On Behalf Of i= nternet-drafts@ietf.org Sent: Monday, July 16, 2012 3:33 PM To: i-d-announce@ietf.org Cc: storm@ietf.org Subject: [storm] I-D Action: draft-ietf-storm-iscsi-sam-06.txt A New Internet-Draft is available from the on-line Internet-Drafts director= ies. This draft is a work item of the STORage Maintenance Working Group of the = IETF. Title : Internet Small Computer Systems Interface (iSCSI) SCSI F= eatures Update Author(s) : Frederick Knight Mallikarjun Chadalapaka Filename : draft-ietf-storm-iscsi-sam-06.txt Pages : 1 Date : 2012-07-16 Abstract: Internet Small Computer Systems Interface (iSCSI) is a SCSI transport protocol that maps the SCSI family of protocols onto TCP/IP. The iSCSI protocol as specified in [draft-ietf-storm- iscsi-cons-xx] (and as previously specified by the combination of RFC 3720 and RFC 5048) is based on the SAM-2 (SCSI Architecture Model - 2) version of the SCSI family of protocols. This document defines enhancements to the iSCSI protocol to support certain additional features of the SCSI protocol that were defined in SAM-3, SAM-4, and SAM-5. This document is a companion document to [draft-ietf-storm- iscsi-cons-xx]. -------------------------------------------------------- RFC EDITORS NOTE: The above references to [draft-ietf-storm- iscsi-cons-xx] should reference the RFC number assigned to that document, and this note should be removed. -------------------------------------------------------- The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-storm-iscsi-sam There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-storm-iscsi-sam-06 A diff from previous version is available at: http://tools.ietf.org/rfcdiff?url2=3Ddraft-ietf-storm-iscsi-sam-06 Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ _______________________________________________ storm mailing list storm@ietf.org https://www.ietf.org/mailman/listinfo/storm From iesg-secretary@ietf.org Mon Jul 16 14:18:52 2012 Return-Path: X-Original-To: storm@ietfa.amsl.com Delivered-To: storm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C24E911E8161; Mon, 16 Jul 2012 14:18:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.391 X-Spam-Level: X-Spam-Status: No, score=-102.391 tagged_above=-999 required=5 tests=[AWL=0.208, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id eci-qmvBBTdg; Mon, 16 Jul 2012 14:18:51 -0700 (PDT) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EBD2911E8143; Mon, 16 Jul 2012 14:18:50 -0700 (PDT) Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit From: The IESG To: IETF-Announce X-Test-IDTracker: no X-IETF-IDTracker: 4.30p3 Message-ID: <20120716211850.4308.53226.idtracker@ietfa.amsl.com> Date: Mon, 16 Jul 2012 14:18:50 -0700 Cc: storm@ietf.org Subject: [storm] Last Call: (iSCSI Protocol (Consolidated)) to Proposed Standard X-BeenThere: storm@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: ietf@ietf.org List-Id: Storage Maintenance WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 16 Jul 2012 21:18:52 -0000 The IESG has received a request from the STORage Maintenance WG (storm) to consider the following document: - 'iSCSI Protocol (Consolidated)' as Proposed Standard The IESG plans to make a decision in the next few weeks, and solicits final comments on this action. Please send substantive comments to the ietf@ietf.org mailing lists by 2012-08-13. Exceptionally, comments may be sent to iesg@ietf.org instead. In either case, please retain the beginning of the Subject line to allow automated sorting. Please note the concurrent Last Call for draft-ietf-storm-iscsi-sam, as both drafts should be reviewed together. Abstract This document describes a transport protocol for SCSI that works on top of TCP. The iSCSI protocol aims to be fully compliant with the standardized SCSI Architecture Model (SAM-2). RFC 3720 defined the original iSCSI protocol. RFC 3721 discusses iSCSI Naming examples and discovery techniques. Subsequently, RFC 3980 added an additional naming format to iSCSI protocol. RFC 4850 followed up by adding a new public extension key to iSCSI. RFC 5048 offered a number of clarifications and a few improvements and corrections to the original iSCSI protocol. This document obsoletes RFCs 3720, 3980, 4850 and 5048 by consolidating them into a single document and making additional updates to the consolidated specification. This document also updates RFC 3721 and RFC 3723. The text in this document thus supersedes the text in all the noted RFCs wherever there is a difference in semantics. This last call explicitly identifies these downrefs in the normative references of this document: [EUI] "Guidelines for 64-bit Global Identifier (EUI-64)", http://standards.ieee.org/regauth/oui/tutorials/EUI64.html [FC-FS] INCITS 373-2003, Fibre Channel Framing and Signaling Interface (FC-FS). [OUI] "IEEE OUI and Company_Id Assignments", http://standards.ieee.org/regauth/oui [SAM2] T10/1157-D, SCSI Architecture Model - 2 (SAM-2). [SAM3] T10/1561-D, SCSI Architecture Model - 3 (SAM-3). [SAM4] T10/1683-D, SCSI Architecture Model - 4 (SAM-4). [SBC2] NCITS.405-205, SCSI Block Commands - 2 (SBC-2). [SPC3] T10/1416-D, SCSI Primary Commands-3. [UML] ISO/IEC 19501, Unified Modeling Language Specification Version 1.4.2. [UNICODE] Unicode Standard Annex #15, "Unicode Normalization Forms", http://www.unicode.org/unicode/reports/tr15 The file can be obtained via http://datatracker.ietf.org/doc/draft-ietf-storm-iscsi-cons/ IESG discussion can be tracked via http://datatracker.ietf.org/doc/draft-ietf-storm-iscsi-cons/ballot/ No IPR declarations have been submitted directly on this I-D. From iesg-secretary@ietf.org Mon Jul 16 14:19:40 2012 Return-Path: X-Original-To: storm@ietfa.amsl.com Delivered-To: storm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6B87311E8248; Mon, 16 Jul 2012 14:19:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.411 X-Spam-Level: X-Spam-Status: No, score=-102.411 tagged_above=-999 required=5 tests=[AWL=0.188, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 87YQ+tmtcxSw; Mon, 16 Jul 2012 14:19:39 -0700 (PDT) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6857711E814E; Mon, 16 Jul 2012 14:19:39 -0700 (PDT) Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit From: The IESG To: IETF-Announce X-Test-IDTracker: no X-IETF-IDTracker: 4.30p3 Message-ID: <20120716211939.22533.77051.idtracker@ietfa.amsl.com> Date: Mon, 16 Jul 2012 14:19:39 -0700 Cc: storm@ietf.org Subject: [storm] Last Call: (Internet Small Computer Systems Interface (iSCSI) SCSI Features Update) to Proposed Standard X-BeenThere: storm@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: ietf@ietf.org List-Id: Storage Maintenance WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 16 Jul 2012 21:19:40 -0000 The IESG has received a request from the STORage Maintenance WG (storm) to consider the following document: - 'Internet Small Computer Systems Interface (iSCSI) SCSI Features Update' as Proposed Standard The IESG plans to make a decision in the next few weeks, and solicits final comments on this action. Please send substantive comments to the ietf@ietf.org mailing lists by 2012-08-13. Exceptionally, comments may be sent to iesg@ietf.org instead. In either case, please retain the beginning of the Subject line to allow automated sorting. Please note the concurrent Last Call for draft-ietf-storm-iscsi-cons, as both drafts should be reviewed together. Abstract Internet Small Computer Systems Interface (iSCSI) is a SCSI transport protocol that maps the SCSI family of protocols onto TCP/IP. The iSCSI protocol as specified in [draft-ietf-storm- iscsi-cons-xx] (and as previously specified by the combination of RFC 3720 and RFC 5048) is based on the SAM-2 (SCSI Architecture Model - 2) version of the SCSI family of protocols. This document defines enhancements to the iSCSI protocol to support certain additional features of the SCSI protocol that were defined in SAM-3, SAM-4, and SAM-5. This document is a companion document to [draft-ietf-storm- iscsi-cons-xx]. -------------------------------------------------------- RFC EDITORS NOTE: The above references to [draft-ietf-storm- iscsi-cons-xx] should reference the RFC number assigned to that document, and this note should be removed. -------------------------------------------------------- This last call explicitly identifies these downrefs in the normative references of this document: [SAM2] T10/1157D, SCSI Architecture Model - 2 (SAM-2). [SAM4] ISO/IEC 14776-414, SCSI Architecture Model - 4 (SAM- 4). [SAM5] T10/2104D rev r04, SCSI Architecture Model - 5 (SAM- 5), Committee Draft. [SPC4] T10/1731D rev r23, SCSI Primary Commands - 4 (SPC-4), Committee Draft. The file can be obtained via http://datatracker.ietf.org/doc/draft-ietf-storm-iscsi-sam/ IESG discussion can be tracked via http://datatracker.ietf.org/doc/draft-ietf-storm-iscsi-sam/ballot/ No IPR declarations have been submitted directly on this I-D. From david.black@emc.com Mon Jul 16 18:20:24 2012 Return-Path: X-Original-To: storm@ietfa.amsl.com Delivered-To: storm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 365F521F87FF for ; Mon, 16 Jul 2012 18:20:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.194 X-Spam-Level: X-Spam-Status: No, score=-102.194 tagged_above=-999 required=5 tests=[AWL=-0.195, BAYES_00=-2.599, J_CHICKENPOX_72=0.6, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bPdbFjku5lCn for ; Mon, 16 Jul 2012 18:20:23 -0700 (PDT) Received: from mexforward.lss.emc.com (hop-nat-141.emc.com [168.159.213.141]) by ietfa.amsl.com (Postfix) with ESMTP id 0FC6C21F87FE for ; Mon, 16 Jul 2012 18:20:22 -0700 (PDT) Received: from hop04-l1d11-si01.isus.emc.com (HOP04-L1D11-SI01.isus.emc.com [10.254.111.54]) by mexforward.lss.emc.com (Switch-3.4.3/Switch-3.4.3) with ESMTP id q6H1L6PB014481 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 16 Jul 2012 21:21:07 -0400 Received: from mailhub.lss.emc.com (mailhub.lss.emc.com [10.254.222.130]) by hop04-l1d11-si01.isus.emc.com (RSA Interceptor); Mon, 16 Jul 2012 21:20:46 -0400 Received: from mxhub03.corp.emc.com (mxhub03.corp.emc.com [10.254.141.105]) by mailhub.lss.emc.com (Switch-3.4.3/Switch-3.4.3) with ESMTP id q6H1KklI012966; Mon, 16 Jul 2012 21:20:46 -0400 Received: from mx15a.corp.emc.com ([169.254.1.189]) by mxhub03.corp.emc.com ([10.254.141.105]) with mapi; Mon, 16 Jul 2012 21:20:45 -0400 From: To: , Date: Mon, 16 Jul 2012 21:20:44 -0400 Thread-Topic: [storm] iSER - what to do Thread-Index: Ac1iW1TGtSebRbE7RA28PPzcQVgFZwBU/mAQ Message-ID: <8D3D17ACE214DC429325B2B98F3AE71208DD882E@MX15A.corp.emc.com> References: <8D3D17ACE214DC429325B2B98F3AE71208C14966@MX15A.corp.emc.com> <8D3D17ACE214DC429325B2B98F3AE71208C14A8F@MX15A.corp.emc.com> <8D3D17ACE214DC429325B2B98F3AE71208D3B0CA@MX15A.corp.emc.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-EMM-MHVC: 1 Subject: Re: [storm] iSER - what to do X-BeenThere: storm@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Storage Maintenance WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 17 Jul 2012 01:20:24 -0000 QWxleGFuZGVyLA0KDQpUaGFuayB5b3UgZm9yIHRoZSByZXNwb25zZS4NCg0KPiBBbGwgaW4gYWxs LCBJIHN1Z2dlc3QgdGhhdCB3ZSBiaXRlIHRoZSBidWxsZXQsIGNvbXBsZXRlIHRoZSBzcGVjIGFu ZCBoZWFkDQo+IHRvd2FyZHMgZnVsbHkgc3BlYy1jb21wbGlhbnQgaW1wbGVtZW50YXRpb25zIG9m IGJvdGggaW5pdGlhdG9yIGFuZCB0YXJnZXQNCj4gYXMgc29vbiBhcyBwb3NzaWJsZS4NCj4NCj4g T24gcHJhY3RpY2FsIGdyb3VuZHMgd2UgY2FuIGFkZHJlc3MgdGhlIGRpc3RybyBtYWludGFpbmVy cyB0byBlbXBsb3kgYWxsDQo+IHBvc3NpYmxlIG1lYW5zIHRvIGRpc3RyaWJ1dGUgY29tcGxpYW50 IHVwZGF0ZXMgc29vbmVyIHRoYW4gbGF0ZXIsDQo+IGFzIHRob3NlIHdpbGwgcmVwcmVzZW50IGEg c3BlY2lhbCwgY3JpdGljYWwgY2hhbmdlLg0KDQpXZSBjYW4gdXBkYXRlIHRoZSBzcGVjIG5vdyAt IHdoYXQgZG8geW91IHRoaW5rIGEgcmVhc29uYWJsZSB0aW1lZnJhbWUNCmlzIHRvIHB1c2ggb3V0 IHRoYXQgY29kZT8NCg0KUnVubmluZyB0aHJvdWdoIHlvdXIgc3VnZ2VzdGVkIGFwcHJvYWNoOg0K DQo+IDEuIGlTRVJIZWxsb1JlcXVpcmVkIHJlbWFpbnMgZGVmaW5lZCBhcyBpcywgd2l0aCBkZWZh dWx0PU5vLg0KDQpPay4NCg0KPiAyLiBJdCBiZWNvbWVzICptYW5kYXRvcnkqIGZvciBhIGZ1bGx5 LXNwZWMgY29tcGxpYW50IGluaXRpYXRvcg0KPiAgICBpbXBsZW1lbnRhdGlvbiB0byBjb21tdW5p Y2F0ZSBpU0VSSGVsbG9SZXF1aXJlZD1ZZXMuDQo+ICAgICogSWYgdGhpcyBrZXkgaXMgbm90IHNl bnQgdGhlbiB0aGUgIm5ldyIgdGFyZ2V0IGtub3dzIHRoYXQgaXQgaGFzDQo+ICAgICAgZW5jb3Vu dGVyZWQgYW4gIm9sZCIgaW5pdGlhdG9yLg0KPiAgICAqIElmIHRoZSBpbml0aWF0b3Igc2VuZHMg IGlTRVJIZWxsb1JlcXVpcmVkPU5vLCBpdCBtZWFucyBpdCBjaG9vc2VzDQo+ICAgICAgKGZvciBz b21lIGJpemFycmUgcmVhc29ucykgdG8gYmVoYXZlIGFzIGFuICJvbGQiIG9uZSAtIHdoaWxlDQo+ ICAgICAgc3VjaCBiZWhhdmlvciBpcyBzdHJvbmdseSBkaXNjb3VyYWdlZC4NCj4gICAgICBJIGd1 ZXNzIHRoZSByZXF1aXJlbWVudCB0aGF0Og0KPiAgICAgICJ0aGUgaW5pdGlhdG9yIFNIT1VMRCBz ZW5kIGlTRVJIZWxsb1JlcXVpcmVkPVllcyINCj4gICAgICByZWZsZWN0cyB0aGUgc2l0dWF0aW9u LCBjb3JyZWN0IG1lIGlmIEknbSB3cm9uZy4NCg0KT2ssIHRoYXQgc2VlbXMgY29ycmVjdCAuLi4g cmV3cml0aW5nIHVzaW5nIG15IG93biB3b3JkcyAuLi4NCg0KU3BlY2lmaWNhbGx5LCBhIHNwZWMt Y29tcGxpYW50IGluaXRpYXRvciBTSE9VTEQgYmVnaW4gdGhlIG5lZ290aWF0aW9uDQp3aXRoIGEg IlllcyIgdmFsdWUuICBJbiBhZGRpdGlvbiwgYSBzcGVjLWNvbXBsaWFudCB0YXJnZXQgU0hPVUxE DQpyZXNwb25kIHRvIGlTRVJIZWxsb1JlcXVpcmVkPVllcyB3aXRoIGlTRVJIZWxsb1JlcXVpcmVk PVllcy4NCg0KQSBzcGVjLWNvbXBsaWFudCB0YXJnZXQgTVVTVCB0cmVhdCBub24tcmVjZWlwdCBv Zg0KaVNFUkhlbGxvUmVxdWlyZWQgYW5kIHJlY2VpcHQgb2YgaVNFUkhlbGxvUmVxdWlyZWQ9Tm8g aW4gdGhlIHNhbWUNCmZhc2hpb24gLSB0aGV5IGJvdGggaW5kaWNhdGUgYW4gb2xkIGluaXRpYXRv ci4gW29sZCA9IGRvZXMgbm90IHVzZQ0KaVNFUiBIZWxsb10uDQoNCkZ1cnRoZXIsIGEgc3BlYy1j b21wbGlhbnQgaW5pdGlhdG9yIFNIT1VMRCBiZSBwcmVwYXJlZCB0byByZWNlaXZlDQpib3RoIGlT RVJIZWxsb1JlcXVpcmVkPU5vdFVuZGVyc3Rvb2QgYW5kIGlTRVJIZWxsb1JlcXVpcmVkPU5vIHJl c3BvbnNlcywNCmFuZCBNVVNUIHRyZWF0IGJvdGggcmVzcG9uc2VzIGluIHRoZSBzYW1lIGZhc2hp b24gLSB0aGV5IGJvdGgNCmluZGljYXRlIGFuIG9sZCB0YXJnZXQgW29sZCA9IGRvZXMgbm90IHVz ZSBpU0VSIEhlbGxvXS4NCg0KDQo+IDMuICJOZXciIGluaXRpYXRvciB3aWxsIHJlY29nbml6ZSBh biAib2xkIiB0YXJnZXQgYnkgcmVjZWl2aW5nDQo+ICAgICJOb3RVbmRlcnN0b29kIiBpbiByZXNw b25zZSB0byBpU0VSSGVsbG9SZXF1aXJlZD1ZZXMuDQoNCk9yIGJ5IHJlY2VpdmluZyBpU0VSSGVs bG9SZXF1aXJlZD1ObyBpbiByZXNwb25zZS4NCg0KPiAgICBUaGVuIGl0IGNhbiBlaXRoZXIgcmVm dXNlIHRvIGRlYWwgd2l0aCBpdCwgb3IgdG8gZW1wbG95IGEgcmFuZ2Ugb2YNCj4gICAgdHJpY2t5 IG1lYW5zIHVzZWQgdW50aWwgbm93Lg0KPiAgICBXZSBjYW4gZGVzY3JpYmUgdGhvc2UgbWVhbnMg YXMgdGhlIGd1aWRlbGluZXMsIGUuZy4gOg0KPiAgICAqIHBvc3Rpbmcgb25lIG9yIGJldHRlciBN YXhPdXRzdGFuZGluZ1VuZXhwZWN0ZWRQRFVzIGJ1ZmZlcnMNCj4gICAgKiB0byBiZSByZWFsbHkg b24gdGhlIHNhZmUgc2lkZSwgaGF2aW5nIHRob3NlIGJ1ZmZlcnMgYXQgbGVhc3QgOEtCIGxvbmcu DQoNCkkgd291bGQgc2F5ICJTSE9VTEQgcG9zdCIgYXQgbGVhc3Qgb25lIG9yIG1vcmUgYnVmZmVy cyB0aGF0IGFyZSBzaXplZA0KZm9yIG5lZ290aWF0aW9uIChhbmQgbm90IHNheSA4S0IgZXhwbGlj aXRseSksIGV4cGxhaW4gdGhpcyByZWR1Y2VzIHRoZQ0KcG9zc2liaWxpdHkgdGhhdCBlYXJseSB1 bnNvbGljaXRlZCBQRFVzIHdpbGwgY2F1c2UgdGhlIFJDYVAgY29ubmVjdGlvbg0KdG8gY2xvc2Us IGFuZCBzdGF0ZSB0aGF0IHRoaXMgdGVjaG5pcXVlIGlzIGtub3duIHRvIHdvcmsgd2l0aCBleGlz dGluZw0KSW5maW5pQmFuZCBpU0VSIHRhcmdldHMuDQogDQo+ICAgIEFzIHdlIGFyZSB0cnlpbmcg dG8gbmV1dHJhbGl6ZSB0aGUgc2hvcnRjb21pbmdzIG9mIHRoZSBleGlzdGluZw0KPiAgICB0YXJn ZXRzLCB0aGUgaW5pdGlhdG9yIGNhbiBiZXQgdGhhdCB0aGUgdGFyZ2V0IHdvbid0IHNlbmQgc3Bs aXQNCj4gICAgbG9naW4gcmVzcG9uc2VzLCBhcyBpdCByZWd1bGFybHkgZG9lcyBub3QgZG8gc28g dG9kYXkuDQoNCk9rLCB0aGlzIGRvZXMgbmVlZCB0byBiZSBzdGF0ZWQgYXMgc29tZXRoaW5nIHRo YXQgZXhpc3RpbmcgdGFyZ2V0cw0KZG8gbm90IGRvLg0KDQo+IDQuICJOZXciIHRhcmdldCB3aWxs IHJlY29nbml6ZSBhbiAib2xkIiBpbml0aWF0b3IgYnkgaGF2aW5nIHJlY2VpdmVkDQo+ICAgIGlT RVJIZWxsb1JlcXVpcmVkPU5vIGVpdGhlciBpbXBsaWNpdGx5IG9yIGV4cGxpY2l0bHkuDQoNCiJp bXBsaWNpdGx5IG9yIGV4cGxpY2l0bHkiIG1lYW5zIGVpdGhlciBpU0VSSGVsbG9SZXF1aXJlZCB3 YXMgbm90DQpyZWNlaXZlZCBvciBpU0VSSGVsbG9SZXF1aXJlZD1ObyB3YXMgcmVjZWl2ZWQuICBC b3RoIGNhc2VzIE1VU1QgYmUNCnRyZWF0ZWQgaW4gdGhlIHNhbWUgZmFzaGlvbi4NCg0KPiAgICBU aGVuIGl0IG11c3QNCj4gICAgaWdub3JlIHRoZSBpU0VSSGVsbG8gYWJzZW5jZSANCg0KVGhvc2Ug YXJlbid0IHRoZSByaWdodCB3b3Jkcy4gIFRoZSB0YXJnZXQga25vd3MgdGhhdCBpU0VSSGVsbG8g d2lsbA0Kbm90IGJlIHVzZWQgLSBpdCBjYW4gY2hvb3NlIHRvIHRlcm1pbmF0ZSB0aGUgbmVnb3Rp YXRpb24gd2l0aG91dCBzZXR0aW5nDQp1cCBpU0VSLiAgSWYgaXQgZG9lcyBub3QgLi4uDQoNCmFu ZCBtYXkgYWxzbyB0YWtlIHNvbWUgcHJlY2F1dGlvbnMsDQo+ICAgIGxpa2U6DQoNCi4uLiB0aGVu IHRoZSB0YXJnZXQgU0hPVUxEIGRvIG9uZSBvZiB0aGUgZm9sbG93aW5nOg0KDQo+ICAgICogZGVs YXlpbmcgc2VuZGluZyBhbnkgInVuZXhwZWN0ZWQiIFBEVXMgdW50aWwgdGhlIGZpcnN0IFBEVSBp cw0KPiAgICAgIHJlY2VpdmVkIGZyb20gdGhlIGluaXRpYXRvciBhZnRlciB0aGUgZmluYWwgbG9n aW4gcmVzcG9uc2UNCj4gICAgICBoYXMgYmVlbiBzZW50DQo+ICAgICogdGFraW5nIGEgcmVhc29u YWJsZSB0aW1lb3V0LCBzYXkgYSBzZWNvbmQgKHRoZSBleGFjdCB2YWx1ZQ0KPiAgICAgIGRvZXMg bm90IG1hdHRlciBhcyB0aGUgaW5pdGlhdG9yIGNhbid0IGNvdW50IG9uIGl0IGFueXdheSBhbmQN Cj4gICAgICBubyB2YWx1ZSB3aWxsIHNvbHZlIHRoZSBwcm9ibGVtIGluIGZ1bGwsIHRoZW9yZXRp Y2FsbHkpLg0KPiAgICAqIGRvaW5nIGJvdGgsIHRoYXQgaXMgd2FpdGluZyBmb3IgdGhlIGZpcnN0 IGluY29taW5nIFBEVSBhbmQNCj4gICAgICB0YWtpbmcgYSB0aW1lciB0byBzdGFydCBzZW5kaW5n IE5PUC1JTnMgaW4gY2FzZSBubyBQRFVzIGFycml2ZWQNCj4gICAgICBkdXJpbmcgdGhlIHRpbWVv dXQgcGVyaW9kLCB0byBiZSBhYmxlIHRvIGRldGVjdCBzaWxlbnQgY29ubmVjdGlvbg0KPiAgICAg IGZhaWx1cmVzLg0KDQpJIGJlbGlldmUgdGhlIHNlY29uZCBhbmQgdGhpcmQgYnVsbGV0cyBvdWdo dCB0byBiZSBjb21iaW5lZCwgaW4gdGhhdA0KcmVjZWlwdCBvZiBhIFBEVSBpcyBzdWZmaWNpZW50 IHJlYXNvbiB0byBlbmQgdGhlIHRpbWVvdXQgcGVyaW9kIGJlZm9yZQ0KaXQgd291bGQgb3RoZXJ3 aXNlIGV4cGlyZS4NCg0KPiA1LiAiTmV3IiB0YXJnZXQgYW5kICJuZXciIGluaXRpYXRvciB3aWxs IGNvdW50IG9uIGlTRVJIZWxsbyBhcyB0aGUNCj4gICAgZ3VhcmFudGVlIG9mIHByb3BlciBidWZm ZXIgcG9zdGluZw0KPiANCj4gNi4gIk9sZCIgdGFyZ2V0IGFuZCAib2xkIiBpbml0aWF0b3Igd2ls bCB3b3JrIGFzIHRoZXkgZG8gbm93LCBpbiB0aGVpcg0KPiAgICBkb3VibGUgYmxpc3Mgb2YgaWdu b3JhbmNlLg0KDQpXZSBhbHNvIG5lZWQgdG8gaXNzdWUgYSB3YXJuaW5nIGFib3V0IHRoZSBsYXR0 ZXIgY29tYmluYXRpb24gcmlza2luZw0KUkNhUCBzZXNzaW9uIHRlcm1pbmF0aW9uIGlmIHVuc29s aWNpdGVkIFBEVXMgc2hvdyB1cCBmcm9tIHRoZSB0YXJnZXQNCmJlZm9yZSB0aGUgaW5pdGlhdG9y IGlzIHJlYWR5Lg0KDQpJZiB0aGUgYWJvdmUgbG9va3MgY2xvc2UgdG8gY29ycmVjdCwgd2UgY2Fu IHN0YXJ0IHdvcmtpbmcgb24gdGV4dCBmb3INCnRoZSBkcmFmdCAuLi4NCg0KVGhhbmtzLA0KLS1E YXZpZA0KDQo+IC0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tDQo+IEZyb206IEFsZXhhbmRlciBO ZXpoaW5za3kgW21haWx0bzpuZXpoaW5za3lAZ21haWwuY29tXQ0KPiBTZW50OiBTdW5kYXksIEp1 bHkgMTUsIDIwMTIgMzoyNyBBTQ0KPiBUbzogc3Rvcm1AaWV0Zi5vcmc7IEJsYWNrLCBEYXZpZDsg TWlrZSBLbzsgUGF1bCBLb25pbmc7IE1hbGxpa2FyanVuDQo+IENoYWRhbGFwYWthOyBPciBHZXJs aXR6OyBNaWtlIENocmlzdGllDQo+IFN1YmplY3Q6IFJlOiBbc3Rvcm1dIGlTRVIgLSB3aGF0IHRv IGRvDQo+IA0KPiBIaSwgYWxsDQo+IA0KPiBTb3JyeSBmb3IgYSBsYXRlIGFuc3dlciAoYWdhaW4p Lg0KPiANCj4gSSBoYXZlIGJlZW4gdGhpbmtpbmcgb3ZlciB0aGlzIGlzc3VlIGhlc2l0YW50bHkg Zm9yIGEgbG9uZyB0aW1lIGJlaW5nDQo+IGNsb3NlIHRvIGp1c3QgYWdyZWUgd2l0aCB0aGUgbGF0 ZXN0IHNldCBvZiBzdWdnZXN0aW9ucy4NCj4gQnV0IHRoZW4gSSByZWFsaXplZCB0aGVyZSBpcyBh IHNpbXBsZSBjb3VudGVyLWFyZ3VtZW50IHdoaWNoDQo+IGNvbXBsaWNhdGVzIHRoaW5ncyBldmVu IG1vcmUuDQo+IA0KPiBXaGVuIHRoZSBpbml0aWF0b3Igc2VuZHMgaXRzIGZpbmFsIExvZ2luIFJl cXVlc3QgaXQgaXMgbm90IGd1YXJhbnRlZWQNCj4gdGhhdCB0aGUgbmV4dCBMb2dpbiBSZXNwb25z ZSBpdCByZWNlaXZlcyBpcyB0aGUgImZpbmFsIiBvbmUsIHRvby4NCj4gSWYgdGhlIHRhcmdldCBo YXMgbW9yZSB0ZXh0IGRhdGEgdG8gc2VuZCB0aGFuIHRoZSBoYXJkY29kZWQgOEtCLCBpdA0KPiB3 aWxsIHNwbGl0IGl0IGludG8gdHdvIChvciBtb3JlKSBQRFVzIGJ5IHJhaXNpbmcgQ29udGludWUg Yml0IGluIGFsbA0KPiBpdHMgcmVzcG9uc2VzIGV4Y2VwdCB0aGUgbGFzdC4NCj4gDQo+IFRoaXMg aXMgYSByYXJlIGV2ZW50IGJ1dCBpdCBtZWFucyB0aGF0IHRvIGJlIGZ1bGx5IGNvbXBsaWFudCBh bmQNCj4gZnVsbC1wcm9vZiB0aGUgaW5pdGlhdG9yIGNhbid0IGp1c3QgcG9zdCBhbm90aGVyIE4g YnVmZmVycyB0byBhbnRpY2lwYXRlDQo+IGFsbCAidW5leHBlY3RlZCIgUERVcyBmcm9tIHRhcmdl dC4NCj4gDQo+IEl0IHBvc3RzIG9uZSA4S0IgYnVmZmVyIGZvciB0aGUgbmV4dCBMb2dpbiBSZXNw b25zZSwgYnV0IGl0IHNob3VsZCBiZQ0KPiByZWFkeSBmb3IgdGhlIGNhc2Ugd2hlcmUgdGhlIHJl c3BvbnNlIGNvbnRhaW5zIEM9MS4gSW4gc3VjaCBjYXNlDQo+IGl0IHdvdWxkIHBvc3QgYW5vdGhl ciA4S0IgYnVmZmVyIGFuZCBhbnN3ZXIgb2sgdG8gY29udGludWUuDQo+IA0KPiBSZWd1bGFyIGlu aXRpYXRvciByeC1idWZmZXJzIGFyZSBtdWNoIHNtYWxsZXIgdGhhbiA4S0IuDQo+IEltcGxlbWVu dGF0aW9uLXdpc2UgdGhleSBhcmUgdXN1YWxseSBhbGxvY2F0ZWQgZnJvbSBhIHNlcGFyYXRlIHBv b2wgb3INCj4gc29tZSBvdGhlciBraW5kIG9mIGRpc2NyaW1pbmF0aW9uIGlzIG1hZGUgYmV0d2Vl biB0aGUgbG9naW4gYW5kDQo+IGZ1bGwtZmVhdHVyZWQtcGhhc2UgYnVmZmVycy4NCj4gDQo+IEFz IHRoZXJlIGlzIG5vIGFjY2VwdGFibGUgd2F5IHRvIHJlY2xhaW0gdGhlIGJ1ZmZlcnMgYWZ0ZXIg dGhleSBoYXZlDQo+IGJlZW4gcG9zdGVkLCB0aGUgb25seSB3YXkgb3V0IGlzIHRvIHBvc3QgYSBm ZXcgOEtCIGJ1ZmZlcnMsIGJ1dCBpdCB3aWxsDQo+IG1ha2UgdGhlIGltcGxlbWVudGF0aW9uIGV2 ZW4gbW9yZSBjb21wbGljYXRlZCBhbmQgY3VtYmVyc29tZS4NCj4gDQo+IEFsbCBpbiBhbGwsIEkg c3VnZ2VzdCB0aGF0IHdlIGJpdGUgdGhlIGJ1bGxldCwgY29tcGxldGUgdGhlIHNwZWMgYW5kIGhl YWQNCj4gdG93YXJkcyBmdWxseSBzcGVjLWNvbXBsaWFudCBpbXBsZW1lbnRhdGlvbnMgb2YgYm90 aCBpbml0aWF0b3IgYW5kIHRhcmdldA0KPiBhcyBzb29uIGFzIHBvc3NpYmxlLg0KPiBPbiBwcmF0 aWNhbCBncm91bmRzIHdlIGNhbiBhZGRyZXNzIHRoZSBkaXN0cm8gbWFpbnRhaW5lcnMgdG8gZW1w bG95IGFsbA0KPiBwb3NzaWJsZSBtZWFucyB0byBkaXN0cmlidXRlIGNvbXBsaWFudCB1cGRhdGVz IHNvb25lciB0aGFuIGxhdGVyLA0KPiBhcyB0aG9zZSB3aWxsIHJlcHJlc2VudCBhIHNwZWNpYWws IGNyaXRpY2FsIGNoYW5nZS4NCj4gDQo+IFRvIG1pbmltaXplIHRoZSBkYW1hZ2VzIGkgc3VnZ2Vz dCB0YWtpbmcgdGhlIGZvbGxvd2luZyBwYXRoOg0KPiANCj4gMS4gaVNFUkhlbGxvUmVxdWlyZWQg cmVtYWlucyBkZWZpbmVkIGFzIGlzLCB3aXRoIGRlZmF1bHQ9Tm8uDQo+IA0KPiAyLiBJdCBiZWNv bWVzICptYW5kYXRvcnkqIGZvciBhIGZ1bGx5LXNwZWMgY29tcGxpYW50IGluaXRpYXRvcg0KPiAg ICBpbXBsZW1lbnRhdGlvbiB0byBjb21tdW5pY2F0ZSBpU0VSSGVsbG9SZXF1aXJlZD1ZZXMuDQo+ ICAgICogSWYgdGhpcyBrZXkgaXMgbm90IHNlbnQgdGhlbiB0aGUgIm5ldyIgdGFyZ2V0IGtub3dz IHRoYXQgaXQgaGFzDQo+ICAgICAgZW5jb3VudGVyZWQgYW4gIm9sZCIgaW5pdGlhdG9yLg0KPiAg ICAqIElmIHRoZSBpbml0aWF0b3Igc2VuZHMgIGlTRVJIZWxsb1JlcXVpcmVkPU5vLCBpdCBtZWFu cyBpdCBjaG9zZXMNCj4gICAgICAoZm9yIHNvbWUgYml6YXJyZSByZWFzb25zKSB0byBiZWhhdmUg YXMgYW4gIm9sZCIgb25lIC0gd2hpbGUNCj4gICAgICBzdWNoIGJlaGF2aW9yIGlzIHN0cm9uZ2x5 IGRpc2NvdXJhZ2VkLg0KPiAgICAgIEkgZ3Vlc3MgdGhlIHJlcXVpcmVtZW50IHRoYXQ6DQo+ICAg ICAgInRoZSBpbml0aWF0b3IgU0hPVUxEIHNlbmQgaVNFUkhlbGxvUmVxdWlyZWQ9WWVzIg0KPiAg ICAgIHJlZmxlY3RzIHRoZSBzaXR1YXRpb24sIGNvcnJlY3QgbWUgaWYgaSdtIHdyb25nLg0KPiAN Cj4gMy4gIk5ldyIgaW5pdGlhdG9yIHdpbGwgcmVjb2duaXplIGFuICJvbGQiIHRhcmdldCBieSBy ZWNlaXZpbmcNCj4gICAgIk5vdFVuZGVyc3Rvb2QiIGluIHJlc3BvbnNlIHRvIGlTRVJIZWxsb1Jl cXVpcmVkPVllcy4NCj4gICAgVGhlbiBpdCBjYW4gZWl0aGVyIHJlZnVzZSB0byBkZWFsIHdpdGgg aXQsIG9yIHRvIGVtcGxveSBhIHJhbmdlIG9mDQo+ICAgIHRyaWNreSBtZWFucyB1c2VkIHVudGls IG5vdy4NCj4gICAgV2UgY2FuIGRlc2NyaWJlIHRob3NlIG1lYW5zIGFzIHRoZSBndWlkZWxpbmVz LCBlLmcuIDoNCj4gICAgKiBwb3N0aW5nIG9uZSBvciBiZXR0ZXIgTWF4T3V0c3RhbmRpbmdVbmV4 cGVjdGVkUERVcyBidWZmZXJzDQo+ICAgICogdG8gYmUgcmVhbGx5IG9uIHRoZSBzYWZlIHNpZGUs IGhhdmluZyB0aG9zZSBidWZmZXJzIGF0IGxlYXN0IDhLQiBsb25nLg0KPiANCj4gICAgQXMgd2Ug YXJlIHRyeWluZyB0byBuZXV0cmFsaXplIHRoZSBzaG9ydGNvbWluZ3Mgb2YgdGhlIGV4aXN0aW5n DQo+ICAgIHRhcmdldHMsIHRoZSBpbml0aWF0b3IgY2FuIGJldCB0aGF0IHRoZSB0YXJnZXQgd29u J3Qgc2VuZCBzcGxpdA0KPiAgICBsb2dpbiByZXNwb25zZXMsIGFzIGl0IHJlZ3VsYXJseSBkb2Vz IG5vdCBkbyBzbyB0b2RheS4NCj4gDQo+IDQuICJOZXciIHRhcmdldCB3aWxsIHJlY29nbml6ZSBh biAib2xkIiBpbml0aWF0b3IgYnkgaGF2aW5nIHJlY2VpdmVkDQo+ICAgIGlTRVJIZWxsb1JlcXVp cmVkPU5vIGVpdGhlciBpbXBsaWNpdGx5IG9yIGV4cGxpY2l0bHkuIFRoZW4gaXQgbXVzdA0KPiAg ICBpZ25vcmUgdGhlIGlTRVJIZWxsbyBhYnNlbnNlIGFuZCBtYXkgYWxzbyB0YWtlIHNvbWUgcHJl Y2F1dGlvbnMsDQo+ICAgIGxpa2U6DQo+ICAgICogZGVsYXlpbmcgc2VuZGluZyBhbnkgInVuZXhw ZWN0ZWQiIFBEVXMgdW50aWwgdGhlIGZpcnN0IFBEVSBpcw0KPiAgICAgIHJlY2VpdmVkIGZyb20g dGhlIGluaXRpYXRvciBhZnRlciB0aGUgZmluYWwgbG9naW4gcmVzcG9uc2UNCj4gICAgICBoYXMg YmVlbiBzZW50DQo+ICAgICogdGFraW5nIGEgcmVhc29uYWJsZSB0aW1lb3V0LCBzYXkgYSBzZWNv bmQgKHRoZSBleGFjdCB2YWx1ZQ0KPiAgICAgIGRvZXMgbm90IG1hdHRlciBhcyB0aGUgaW5pdGlh dG9yIGNhbid0IGNvdW50IG9uIGl0IGFueXdheSBhbmQNCj4gICAgICBubyB2YWx1ZSB3aWxsIHNv bHZlIHRoZSBwcm9ibGVtIGluIGZ1bGwsIHRoZW9yZXRpY2FsbHkpLg0KPiAgICAqIGRvaW5nIGJv dGgsIHRoYXQgaXMgd2FpdGluZyBmb3IgdGhlIGZpcnN0IGluY29taW5nIFBEVSBhbmQNCj4gICAg ICB0YWtpbmcgYSB0aW1lciB0byBzdGFydCBzZW5kaW5nIE5PUC1JTnMgaW4gY2FzZSBubyBQRFVz IGFycml2ZWQNCj4gICAgICBkdXJpbmcgdGhlIHRpbWVvdXQgcGVyaW9kLCB0byBiZSBhYmxlIHRv IGRldGVjdCBzaWxlbnQgY29ubmVjdGlvbg0KPiAgICAgIGZhaWx1cmVzLg0KPiANCj4gNS4gIk5l dyIgdGFyZ2V0IGFuZCAibmV3IiBpbml0aWF0b3Igd2lsbCBjb3VudCBvbiBJU0VSSGVsbG8gYXMg dGhlDQo+ICAgIGd1YXJhbnRlZSBvZiBwcm9wZXIgYnVmZmVyIHBvc3RpbmcNCj4gDQo+IDYuICJP bGQiIHRhcmdldCBhbmQgIm9sZCIgaW5pdGlhdG9yIHdpbGwgd29yayBhcyB0aGV5IGRvIG5vdywg aW4gdGhlaXINCj4gICAgZG91YmxlIGJsaXNzIG9mIGlnbm9yYW5jZS4NCj4gDQo+IEJ5IHRoZSB3 YXksIHRoZSBpbml0aWF0b3IgcGF0Y2ggYWxsZXZpYXRpbmcgdGhlIHByb2JsZW0gYnkgcG9zdGlu ZyBvbmUNCj4gYWRkaXRpb25hbCBsb2dpbiBidWZmZXIgd2FzIHN1Ym1pdHRlZCByZWxhdGl2ZWx5 IHJlY2VudGx5IGFuZCBhbGwgcHJldmlvdXMNCj4gZGVwbG95ZWQgaW1wbGVtZW50YXRpb25zIG9m IHRoZSBpbml0aWF0b3IgYXJlIGV4cG9zZWQuDQo+IEV2ZW50dWFsbHksIHRoZSBuZXcgYmV0dGVy IGNvZGUgaXMgbWFraW5nIGl0cyB3YXkgdG8gdGhlIHVzZXJzIG9mIGFsbCBkaXN0cm9zLg0KPiBU aGlzIGlzIGEgY29tbW9uIHNpdHVhdGlvbiBlbmNvdW50ZXJlZCBieSB0aGUgbGludXgga2VybmVs IGNvbW11bml0eQ0KPiBxdWl0ZSBvZnRlbi4gTGV0J3MgdGFrZSB0aGlzIGFzIGEgd29ya2luZyBl eGFtcGxlLCBtYWtlIHRoZSBzcGVjIGZvb2wtcHJvb2YNCj4gYW5kIGFkdmlzZSB0aGUgaW1wbGVt ZW50b3JzIGhvdyB0byBtaW5pbWl6ZSB0aGUgZGFtYWdlcyB3aXRoIHRoZSBvbGQNCj4gc29mdHdh cmUsIHdoaWxlIGtlZXBpbmcgZXZlcnl0aGluZyBhcyBzaW1wbGUgYXMgcG9zc2libGUgdW5kZXIg dGhlc2UNCj4gYWxyZWFkeSBvdmVyLWNvbXBsaWNhdGVkIGNpcmN1bXN0YW5jZXMuDQo+IA0KPiBB bGV4YW5kZXINCg0K From nezhinsky@gmail.com Tue Jul 17 11:44:59 2012 Return-Path: X-Original-To: storm@ietfa.amsl.com Delivered-To: storm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0A58D21F869A for ; Tue, 17 Jul 2012 11:44:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.299 X-Spam-Level: X-Spam-Status: No, score=-3.299 tagged_above=-999 required=5 tests=[AWL=0.300, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Tfi327KsRFrR for ; Tue, 17 Jul 2012 11:44:58 -0700 (PDT) Received: from mail-gg0-f172.google.com (mail-gg0-f172.google.com [209.85.161.172]) by ietfa.amsl.com (Postfix) with ESMTP id 4CBE421F84BF for ; Tue, 17 Jul 2012 11:44:58 -0700 (PDT) Received: by ggnc4 with SMTP id c4so835508ggn.31 for ; Tue, 17 Jul 2012 11:45:46 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=lGWE6TZNnN3jTmmUNY99htsvy3mjmAFixLu9sK4sIx8=; b=f03O8HtIOTF102wy40k3BqLT8K9UIVBEPrdIb519xWqm1UIQqxJjMF4EbsCGK+nj28 dd0bK3wOEaXzQ13L3rqGPTTzOiCR2yUwl7VnJjs0gQXbPYMXQtfeRKe0bq83Ko1ijtDt w9Nw1Adtdq1ZItDVCcZkFP79bdl026btAa0LhQ5kN2drey4O/w9uG+N3otIlGeA7jHfu Hy0EMDow36xGqVct8VL7/l6QrKcNRtdF9zZzSYo6UlQ6SQHX7Hg6KB90ZLYN8FSIhNCR HwXI+Cro9h5lZ8dUOZ2I7vkU93gZaxYr6q8bzHN9AGVZLyG45vQ+T7JNUQaBnjvIcEkq Vjmw== MIME-Version: 1.0 Received: by 10.60.12.8 with SMTP id u8mr4820992oeb.46.1342550746163; Tue, 17 Jul 2012 11:45:46 -0700 (PDT) Received: by 10.182.183.101 with HTTP; Tue, 17 Jul 2012 11:45:46 -0700 (PDT) In-Reply-To: <8D3D17ACE214DC429325B2B98F3AE71208DD882E@MX15A.corp.emc.com> References: <8D3D17ACE214DC429325B2B98F3AE71208C14966@MX15A.corp.emc.com> <8D3D17ACE214DC429325B2B98F3AE71208C14A8F@MX15A.corp.emc.com> <8D3D17ACE214DC429325B2B98F3AE71208D3B0CA@MX15A.corp.emc.com> <8D3D17ACE214DC429325B2B98F3AE71208DD882E@MX15A.corp.emc.com> Date: Tue, 17 Jul 2012 21:45:46 +0300 Message-ID: From: Alexander Nezhinsky To: david.black@emc.com Content-Type: text/plain; charset=UTF-8 Cc: storm@ietf.org Subject: Re: [storm] iSER - what to do X-BeenThere: storm@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Storage Maintenance WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 17 Jul 2012 18:44:59 -0000 On Tue, Jul 17, 2012 at 4:20 AM, wrote: > We can update the spec now - what do you think a reasonable timeframe > is to push out that code? I can estimate that the target part can be ready within a month. It's harder for me to make a correct estimation about the initiator. But I would bet on a similar time frame. >From there it should be taken up by the distributions. Each one has its own pace. At least RHEL 6.3 was released a couple of weeks ago, so if all goes well we can be pretty sure that the changes are included in RH 6.4. >> As we are trying to neutralize the shortcomings of the existing >> targets, the initiator can bet that the target won't send split >> login responses, as it regularly does not do so today. > > Ok, this does need to be stated as something that existing targets > do not do. Hmm, my second thought is that this may be incorrect in general. They don't do it in a "normal" setup, where the initiator sends a small number of keys, so the target answers with the response of a comparable size. I need to check how well split responses are generated and tolerated right now. Probably we should not bet on their absence anyway. >> 4. "New" target will recognize an "old" initiator by having received >> iSERHelloRequired=No either implicitly or explicitly. > > "implicitly or explicitly" means either iSERHelloRequired was not > received or iSERHelloRequired=No was received. Both cases MUST be > treated in the same fashion. > >> Then it must >> ignore the iSERHello absence > > Those aren't the right words. The target knows that iSERHello will > not be used - it can choose to terminate the negotiation without setting > up iSER. At least in theory, there could be an "old" home-grown initiator implementation which will not send iSERHelloRequired=Yes but will send iSERHello. Should not we allow this ? > ... then the target SHOULD do one of the following: > >> * delaying sending any "unexpected" PDUs until the first PDU is >> received from the initiator after the final login response >> has been sent >> * taking a reasonable timeout, say a second (the exact value >> does not matter as the initiator can't count on it anyway and >> no value will solve the problem in full, theoretically). >> * doing both, that is waiting for the first incoming PDU and >> taking a timer to start sending NOP-INs in case no PDUs arrived >> during the timeout period, to be able to detect silent connection >> failures. > > I believe the second and third bullets ought to be combined, in that > receipt of a PDU is sufficient reason to end the timeout period before > it would otherwise expire. I agree > >> 5. "New" target and "new" initiator will count on iSERHello as the >> guarantee of proper buffer posting >> >> 6. "Old" target and "old" initiator will work as they do now, in their >> double bliss of ignorance. > > We also need to issue a warning about the latter combination risking > RCaP session termination if unsolicited PDUs show up from the target > before the initiator is ready. Ok > If the above looks close to correct, we can start working on text for > the draft ... I'm ok with this Alexander From mkosjc@gmail.com Tue Jul 17 12:06:01 2012 Return-Path: X-Original-To: storm@ietfa.amsl.com Delivered-To: storm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1304721F8703 for ; Tue, 17 Jul 2012 12:06:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.598 X-Spam-Level: X-Spam-Status: No, score=-3.598 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id iytP+99c4MV7 for ; Tue, 17 Jul 2012 12:05:59 -0700 (PDT) Received: from mail-qc0-f172.google.com (mail-qc0-f172.google.com [209.85.216.172]) by ietfa.amsl.com (Postfix) with ESMTP id 8962C21F8712 for ; Tue, 17 Jul 2012 12:05:59 -0700 (PDT) Received: by qcac10 with SMTP id c10so557933qca.31 for ; Tue, 17 Jul 2012 12:06:47 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=nbk00qjyWYy5FeVI+NAYGoHyrWKjQUomQPPZFfREztM=; b=UjhFKkmybyaiAVEaWGvZN6HCc8yV1dbcYBPXeeVkvfzKnHKbKCh1I3wwlRb0afRfAs EGNjk8v587zPGITYBTOSdOllWFLFqPUJHFOFXNOUmA+DFR414vwXG/K4OWJ0blWVHQW8 d1hyTELvA+N7A0t1+2/1gQ9nYSI5H2lhwYJo7TX4mssykZkBrb4wqlF2CfKL4WRd3CN5 4RgxMI+W8Gni1ain3Mq63YhkWGin0zqwWDIl3N4jijUmDzBSP5D858MhOdxnlcZIcJEy fqJWRpgIVNN9hhrTh3QMtO9DjoePcVnB8h3fIoFBd9iNLJ07oKuXPye5bWxBFyOF5fOo t9mg== MIME-Version: 1.0 Received: by 10.224.202.136 with SMTP id fe8mr1258288qab.17.1342552007080; Tue, 17 Jul 2012 12:06:47 -0700 (PDT) Received: by 10.229.130.233 with HTTP; Tue, 17 Jul 2012 12:06:46 -0700 (PDT) In-Reply-To: References: <8D3D17ACE214DC429325B2B98F3AE71208C14966@MX15A.corp.emc.com> <8D3D17ACE214DC429325B2B98F3AE71208C14A8F@MX15A.corp.emc.com> <8D3D17ACE214DC429325B2B98F3AE71208D3B0CA@MX15A.corp.emc.com> <8D3D17ACE214DC429325B2B98F3AE71208DD882E@MX15A.corp.emc.com> Date: Tue, 17 Jul 2012 12:06:46 -0700 Message-ID: From: Michael Ko To: Alexander Nezhinsky Content-Type: multipart/alternative; boundary=20cf3010edad797a2204c50b3f35 Cc: storm@ietf.org Subject: Re: [storm] iSER - what to do X-BeenThere: storm@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Storage Maintenance WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 17 Jul 2012 19:06:01 -0000 --20cf3010edad797a2204c50b3f35 Content-Type: text/plain; charset=ISO-8859-1 An ""old" home-grown initiator implementation which will not send iSERHelloRequired=Yes but will send iSERHello" should not cause any problems. An old target which does not support iSERHello will fail. A new target will assume it is dealing with an old initiator which does not use iSERHello and will act according to the new spec for dealing with old initiators. So when iSERHello shows up, it will follows the new spec for dealing with new initiators. There are two other issues which need to be resolved. 1. Should the spec say anything about the timeout value? I agree with Alex that there is no practical value that will work in all cases. So how about simply stating that the timeout values is outside the scope of the document? 2. In the current iSER spec, section 5.1.1 states that: "If the outcome of the iSCSI negotiation is to enable iSER-assisted mode, then on the initiator side, prior to sending the Login Request with the T (Transit) bit set to 1 and the NSG (Next Stage) field set to FullFeaturePhase, the iSCSI Layer MUST request the iSER Layer to allocate the connection resources necessary to support RCaP by invoking the Allocate_Connection_Resources Operational Primitive." Should the MUST requirement be weakened to a SHOULD as MaxOutstandingUnexpectedPDUs will not be allocated beofre Login Request is sent? Mike On Tue, Jul 17, 2012 at 11:45 AM, Alexander Nezhinsky wrote: > On Tue, Jul 17, 2012 at 4:20 AM, wrote: > > We can update the spec now - what do you think a reasonable timeframe > > is to push out that code? > > I can estimate that the target part can be ready within a month. > It's harder for me to make a correct estimation about the initiator. > But I would bet on a similar time frame. > > From there it should be taken up by the distributions. Each one has > its own pace. > At least RHEL 6.3 was released a couple of weeks ago, so if all goes > well we can > be pretty sure that the changes are included in RH 6.4. > > >> As we are trying to neutralize the shortcomings of the existing > >> targets, the initiator can bet that the target won't send split > >> login responses, as it regularly does not do so today. > > > > Ok, this does need to be stated as something that existing targets > > do not do. > > Hmm, my second thought is that this may be incorrect in general. > They don't do it in a "normal" setup, where the initiator sends a > small number of keys, > so the target answers with the response of a comparable size. > I need to check how well split responses are generated and tolerated right > now. > Probably we should not bet on their absence anyway. > > >> 4. "New" target will recognize an "old" initiator by having received > >> iSERHelloRequired=No either implicitly or explicitly. > > > > "implicitly or explicitly" means either iSERHelloRequired was not > > received or iSERHelloRequired=No was received. Both cases MUST be > > treated in the same fashion. > > > >> Then it must > >> ignore the iSERHello absence > > > > Those aren't the right words. The target knows that iSERHello will > > not be used - it can choose to terminate the negotiation without setting > > up iSER. > > At least in theory, there could be an "old" home-grown initiator > implementation > which will not send iSERHelloRequired=Yes but will send iSERHello. > Should not we allow this ? > > > ... then the target SHOULD do one of the following: > > > >> * delaying sending any "unexpected" PDUs until the first PDU is > >> received from the initiator after the final login response > >> has been sent > >> * taking a reasonable timeout, say a second (the exact value > >> does not matter as the initiator can't count on it anyway and > >> no value will solve the problem in full, theoretically). > >> * doing both, that is waiting for the first incoming PDU and > >> taking a timer to start sending NOP-INs in case no PDUs arrived > >> during the timeout period, to be able to detect silent connection > >> failures. > > > > I believe the second and third bullets ought to be combined, in that > > receipt of a PDU is sufficient reason to end the timeout period before > > it would otherwise expire. > > I agree > > > > >> 5. "New" target and "new" initiator will count on iSERHello as the > >> guarantee of proper buffer posting > >> > >> 6. "Old" target and "old" initiator will work as they do now, in their > >> double bliss of ignorance. > > > > We also need to issue a warning about the latter combination risking > > RCaP session termination if unsolicited PDUs show up from the target > > before the initiator is ready. > > Ok > > > If the above looks close to correct, we can start working on text for > > the draft ... > > I'm ok with this > > Alexander > _______________________________________________ > storm mailing list > storm@ietf.org > https://www.ietf.org/mailman/listinfo/storm > --20cf3010edad797a2204c50b3f35 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable An ""old" home-grown initiator implementation which will not= send iSERHelloRequired=3DYes but will send iSERHello" should not caus= e any problems.=A0 An old target which does not support iSERHello will fail= .=A0 A new target will assume it is dealing with an old initiator which doe= s not use iSERHello and will act according to the new spec for dealing with= old initiators.=A0 So when iSERHello shows up, it will follows the new spe= c for dealing with new initiators.

There are two other issues which need to be resolved.

1. Should = the spec say anything about the timeout value?=A0 I agree with Alex that th= ere is no practical value that will work in all cases.=A0 So how about simp= ly stating that the timeout values is outside the scope of the document?
2. In the current iSER spec, section 5.1.1 states that:

"If= the outcome of the iSCSI negotiation is to enable iSER-assisted mode, then= on the initiator side, prior to sending the Login Request with the T (Tran= sit) bit set to 1 and the NSG (Next Stage) field set to FullFeaturePhase, t= he iSCSI Layer MUST request the iSER Layer to allocate the connection resou= rces necessary to support RCaP by
invoking the Allocate_Connection_Resources Operational Primitive."
=
Should the MUST requirement be weakened to a SHOULD as MaxOutstandingUn= expectedPDUs will not be allocated beofre Login Request is sent?

Mike

On Tue, Jul 17, 2012 at 11:45 AM, Al= exander Nezhinsky <nezhinsky@gmail.com> wrote:
On Tue, Jul 17, 2012 at 4:20 AM, =A0<david.black@emc.com> wrote:
> We can update the spec now - what do you think a reasonable timeframe<= br> > is to push out that code?

I can estimate that the target part can be ready within a month.
It's harder for me to make a correct estimation about the initiator. But I would bet on a similar time frame.

>From there it should be taken up by the distributions. Each one has
its own pace.
At least RHEL 6.3 was released a couple of weeks ago, so if all goes
well we can
be pretty sure that the changes are included in RH 6.4.

>> =A0 =A0As we are trying to neutralize the shortcomings of the exis= ting
>> =A0 =A0targets, the initiator can bet that the target won't se= nd split
>> =A0 =A0login responses, as it regularly does not do so today.
>
> Ok, this does need to be stated as something that existing targets
> do not do.

Hmm, my second thought is that this may be incorrect in general.
They don't do it in a "normal" setup, where the initiator sen= ds a
small number of keys,
so the target answers with the response of a comparable size.
I need to check how well split responses are generated and tolerated right = now.
Probably we should not bet on their absence anyway.

>> 4. "New" target will recognize an "old" initia= tor by having received
>> =A0 =A0iSERHelloRequired=3DNo either implicitly or explicitly.
>
> "implicitly or explicitly" means either iSERHelloRequired wa= s not
> received or iSERHelloRequired=3DNo was received. =A0Both cases MUST be=
> treated in the same fashion.
>
>> =A0 =A0Then it must
>> =A0 =A0ignore the iSERHello absence
>
> Those aren't the right words. =A0The target knows that iSERHello w= ill
> not be used - it can choose to terminate the negotiation without setti= ng
> up iSER.

At least in theory, there could be an "old" home-grown initiator = implementation
which will not send =A0iSERHelloRequired=3DYes but will send iSERHello.
Should not we allow this ?

> ... then the target SHOULD do one of the following:
>
>> =A0 =A0* delaying sending any "unexpected" PDUs until th= e first PDU is
>> =A0 =A0 =A0received from the initiator after the final login respo= nse
>> =A0 =A0 =A0has been sent
>> =A0 =A0* taking a reasonable timeout, say a second (the exact valu= e
>> =A0 =A0 =A0does not matter as the initiator can't count on it = anyway and
>> =A0 =A0 =A0no value will solve the problem in full, theoretically)= .
>> =A0 =A0* doing both, that is waiting for the first incoming PDU an= d
>> =A0 =A0 =A0taking a timer to start sending NOP-INs in case no PDUs= arrived
>> =A0 =A0 =A0during the timeout period, to be able to detect silent = connection
>> =A0 =A0 =A0failures.
>
> I believe the second and third bullets ought to be combined, in that > receipt of a PDU is sufficient reason to end the timeout period before=
> it would otherwise expire.

I agree

>
>> 5. "New" target and "new" initiator will count= on iSERHello as the
>> =A0 =A0guarantee of proper buffer posting
>>
>> 6. "Old" target and "old" initiator will work = as they do now, in their
>> =A0 =A0double bliss of ignorance.
>
> We also need to issue a warning about the latter combination risking > RCaP session termination if unsolicited PDUs show up from the target > before the initiator is ready.

Ok

> If the above looks close to correct, we can start working on text for<= br> > the draft ...

I'm ok with this

Alexander
_______________________________________________
storm mailing list
storm@ietf.org
h= ttps://www.ietf.org/mailman/listinfo/storm

--20cf3010edad797a2204c50b3f35-- From david.black@emc.com Tue Jul 17 12:57:28 2012 Return-Path: X-Original-To: storm@ietfa.amsl.com Delivered-To: storm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B930D21F8621 for ; Tue, 17 Jul 2012 12:57:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.49 X-Spam-Level: X-Spam-Status: No, score=-102.49 tagged_above=-999 required=5 tests=[AWL=0.108, BAYES_00=-2.599, HTML_MESSAGE=0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id G9-BKUBAy0oL for ; Tue, 17 Jul 2012 12:57:24 -0700 (PDT) Received: from mexforward.lss.emc.com (hop-nat-141.emc.com [168.159.213.141]) by ietfa.amsl.com (Postfix) with ESMTP id 1819D21F86FC for ; Tue, 17 Jul 2012 12:57:23 -0700 (PDT) Received: from hop04-l1d11-si04.isus.emc.com (HOP04-L1D11-SI04.isus.emc.com [10.254.111.24]) by mexforward.lss.emc.com (Switch-3.4.3/Switch-3.4.3) with ESMTP id q6HJw9eo020362 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 17 Jul 2012 15:58:09 -0400 Received: from mailhub.lss.emc.com (mailhub.lss.emc.com [10.254.222.226]) by hop04-l1d11-si04.isus.emc.com (RSA Interceptor); Tue, 17 Jul 2012 15:57:54 -0400 Received: from mxhub02.corp.emc.com (mxhub02.corp.emc.com [10.254.141.104]) by mailhub.lss.emc.com (Switch-3.4.3/Switch-3.4.3) with ESMTP id q6HJvsKg003929; Tue, 17 Jul 2012 15:57:54 -0400 Received: from mx15a.corp.emc.com ([169.254.1.189]) by mxhub02.corp.emc.com ([10.254.141.104]) with mapi; Tue, 17 Jul 2012 15:57:54 -0400 From: To: Date: Tue, 17 Jul 2012 15:57:51 -0400 Thread-Topic: [storm] iSER - what to do Thread-Index: Ac1kT3Uzbd1tgTEcQhi1cB7kUBqG1QABbz0g Message-ID: <8D3D17ACE214DC429325B2B98F3AE71208DD8957@MX15A.corp.emc.com> References: <8D3D17ACE214DC429325B2B98F3AE71208C14966@MX15A.corp.emc.com> <8D3D17ACE214DC429325B2B98F3AE71208C14A8F@MX15A.corp.emc.com> <8D3D17ACE214DC429325B2B98F3AE71208D3B0CA@MX15A.corp.emc.com> <8D3D17ACE214DC429325B2B98F3AE71208DD882E@MX15A.corp.emc.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: multipart/alternative; boundary="_000_8D3D17ACE214DC429325B2B98F3AE71208DD8957MX15Acorpemccom_" MIME-Version: 1.0 X-EMM-MHVC: 1 Cc: storm@ietf.org Subject: Re: [storm] iSER - what to do X-BeenThere: storm@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Storage Maintenance WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 17 Jul 2012 19:57:28 -0000 --_000_8D3D17ACE214DC429325B2B98F3AE71208DD8957MX15Acorpemccom_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Mike, In particular, we need to say that a new target MUST respond to iSERHello w= ith iSERHello when the iSERHelloRequired key was omitted from the negotiati= on. OTOH, if iSERHelloRequired was negotiated to No, target receipt of iSE= RHello indicates a protocol error by the initiator - the target MAY choose = to treat that as an error (e.g., and close the RCaP connection) or the targ= et MAY choose to continue by responding with an iSERHello. We need to state a recommended timeout value, at least as a default. 1 sec= ond seems like a reasonable default, and it could be adjusted via other mea= ns (e.g., system configuration). There's no need to state a single value t= hat MUST be used in all implementations. I believe the quoted text has to be changed to align with this discussion. Thanks, --David From: Michael Ko [mailto:mkosjc@gmail.com] Sent: Tuesday, July 17, 2012 3:07 PM To: Alexander Nezhinsky Cc: Black, David; storm@ietf.org Subject: Re: [storm] iSER - what to do An ""old" home-grown initiator implementation which will not send iSERHello= Required=3DYes but will send iSERHello" should not cause any problems. An = old target which does not support iSERHello will fail. A new target will a= ssume it is dealing with an old initiator which does not use iSERHello and = will act according to the new spec for dealing with old initiators. So whe= n iSERHello shows up, it will follows the new spec for dealing with new ini= tiators. There are two other issues which need to be resolved. 1. Should the spec say anything about the timeout value? I agree with Alex= that there is no practical value that will work in all cases. So how abou= t simply stating that the timeout values is outside the scope of the docume= nt? 2. In the current iSER spec, section 5.1.1 states that: "If the outcome of the iSCSI negotiation is to enable iSER-assisted mode, t= hen on the initiator side, prior to sending the Login Request with the T (T= ransit) bit set to 1 and the NSG (Next Stage) field set to FullFeaturePhase= , the iSCSI Layer MUST request the iSER Layer to allocate the connection re= sources necessary to support RCaP by invoking the Allocate_Connection_Resources Operational Primitive." Should the MUST requirement be weakened to a SHOULD as MaxOutstandingUnexpe= ctedPDUs will not be allocated beofre Login Request is sent? Mike On Tue, Jul 17, 2012 at 11:45 AM, Alexander Nezhinsky > wrote: On Tue, Jul 17, 2012 at 4:20 AM, > wrote: > We can update the spec now - what do you think a reasonable timeframe > is to push out that code? I can estimate that the target part can be ready within a month. It's harder for me to make a correct estimation about the initiator. But I would bet on a similar time frame. >From there it should be taken up by the distributions. Each one has its own pace. At least RHEL 6.3 was released a couple of weeks ago, so if all goes well we can be pretty sure that the changes are included in RH 6.4. >> As we are trying to neutralize the shortcomings of the existing >> targets, the initiator can bet that the target won't send split >> login responses, as it regularly does not do so today. > > Ok, this does need to be stated as something that existing targets > do not do. Hmm, my second thought is that this may be incorrect in general. They don't do it in a "normal" setup, where the initiator sends a small number of keys, so the target answers with the response of a comparable size. I need to check how well split responses are generated and tolerated right = now. Probably we should not bet on their absence anyway. >> 4. "New" target will recognize an "old" initiator by having received >> iSERHelloRequired=3DNo either implicitly or explicitly. > > "implicitly or explicitly" means either iSERHelloRequired was not > received or iSERHelloRequired=3DNo was received. Both cases MUST be > treated in the same fashion. > >> Then it must >> ignore the iSERHello absence > > Those aren't the right words. The target knows that iSERHello will > not be used - it can choose to terminate the negotiation without setting > up iSER. At least in theory, there could be an "old" home-grown initiator implementa= tion which will not send iSERHelloRequired=3DYes but will send iSERHello. Should not we allow this ? > ... then the target SHOULD do one of the following: > >> * delaying sending any "unexpected" PDUs until the first PDU is >> received from the initiator after the final login response >> has been sent >> * taking a reasonable timeout, say a second (the exact value >> does not matter as the initiator can't count on it anyway and >> no value will solve the problem in full, theoretically). >> * doing both, that is waiting for the first incoming PDU and >> taking a timer to start sending NOP-INs in case no PDUs arrived >> during the timeout period, to be able to detect silent connection >> failures. > > I believe the second and third bullets ought to be combined, in that > receipt of a PDU is sufficient reason to end the timeout period before > it would otherwise expire. I agree > >> 5. "New" target and "new" initiator will count on iSERHello as the >> guarantee of proper buffer posting >> >> 6. "Old" target and "old" initiator will work as they do now, in their >> double bliss of ignorance. > > We also need to issue a warning about the latter combination risking > RCaP session termination if unsolicited PDUs show up from the target > before the initiator is ready. Ok > If the above looks close to correct, we can start working on text for > the draft ... I'm ok with this Alexander _______________________________________________ storm mailing list storm@ietf.org https://www.ietf.org/mailman/listinfo/storm --_000_8D3D17ACE214DC429325B2B98F3AE71208DD8957MX15Acorpemccom_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Mike,

 

In par= ticular, we need to say that a new target MUST respond to iSERHello with iS= ERHello when the iSERHelloRequired key was omitted from the negotiation.&nb= sp; OTOH, if iSERHelloRequired was negotiated to No, target receipt of iSER= Hello indicates a protocol error by the initiator - the target MAY choose t= o treat that as an error (e.g., and close the RCaP connection) or the targe= t MAY choose to continue by responding with an iSERHello.=

 

We need t= o state a recommended timeout value, at least as a default.  1 second = seems like a reasonable default, and it could be adjusted via other means (= e.g., system configuration).  There’s no need to state a single = value that MUST be used in all implementations.

 

I believe the quote= d text has to be changed to align with this discussion.

 

Thanks= ,
--David 

From: Michael Ko [mail= to:mkosjc@gmail.com]
Sent: Tuesday, July 17, 2012 3:07 PM
= To: Alexander Nezhinsky
Cc: Black, David; storm@ietf.org
<= b>Subject: Re: [storm] iSER - what to do

 

An ""old" home-grown initiator impleme= ntation which will not send iSERHelloRequired=3DYes but will send iSERHello= " should not cause any problems.  An old target which does not su= pport iSERHello will fail.  A new target will assume it is dealing wit= h an old initiator which does not use iSERHello and will act according to t= he new spec for dealing with old initiators.  So when iSERHello shows = up, it will follows the new spec for dealing with new initiators.

Th= ere are two other issues which need to be resolved.

1. Should the sp= ec say anything about the timeout value?  I agree with Alex that there= is no practical value that will work in all cases.  So how about simp= ly stating that the timeout values is outside the scope of the document?
2. In the current iSER spec, section 5.1.1 states that:

"I= f the outcome of the iSCSI negotiation is to enable iSER-assisted mode, the= n on the initiator side, prior to sending the Login Request with the T (Tra= nsit) bit set to 1 and the NSG (Next Stage) field set to FullFeaturePhase, = the iSCSI Layer MUST request the iSER Layer to allocate the connection reso= urces necessary to support RCaP by
invoking the Allocate_Connection_Reso= urces Operational Primitive."

Should the MUST requirement be we= akened to a SHOULD as MaxOutstandingUnexpectedPDUs will not be allocated be= ofre Login Request is sent?

Mike

On Tue, Jul 17, 2012 at 11:45 AM, Alexander Nezhinsky <nezhinsky@gmail.com> wr= ote:

On Tue, Jul 17, 2012 at 4:20 AM, &n= bsp;<david.black@emc.com> = wrote:
> We can update the spec now - what do you think a reasonable = timeframe
> is to push out that code?

I can estimate that the = target part can be ready within a month.
It's harder for me to make a co= rrect estimation about the initiator.
But I would bet on a similar time = frame.

From there it should be taken up by the distributions. Each o= ne has
its own pace.
At least RHEL 6.3 was released a couple of weeks= ago, so if all goes
well we can
be pretty sure that the changes are = included in RH 6.4.

>>    As we are trying to neutra= lize the shortcomings of the existing
>>    targets, the= initiator can bet that the target won't send split
>>   &nbs= p;login responses, as it regularly does not do so today.
>
> Ok= , this does need to be stated as something that existing targets
> do= not do.

Hmm, my second thought is that this may be incorrect in gen= eral.
They don't do it in a "normal" setup, where the initiato= r sends a
small number of keys,
so the target answers with the respon= se of a comparable size.
I need to check how well split responses are ge= nerated and tolerated right now.
Probably we should not bet on their abs= ence anyway.

>> 4. "New" target will recognize an &q= uot;old" initiator by having received
>>    iSERHel= loRequired=3DNo either implicitly or explicitly.
>
> "impl= icitly or explicitly" means either iSERHelloRequired was not
> r= eceived or iSERHelloRequired=3DNo was received.  Both cases MUST be> treated in the same fashion.
>
>>    Then it= must
>>    ignore the iSERHello absence
>
>= Those aren't the right words.  The target knows that iSERHello will> not be used - it can choose to terminate the negotiation without set= ting
> up iSER.

At least in theory, there could be an "ol= d" home-grown initiator implementation
which will not send  iS= ERHelloRequired=3DYes but will send iSERHello.
Should not we allow this = ?

> ... then the target SHOULD do one of the following:
>>>    * delaying sending any "unexpected" PDUs = until the first PDU is
>>      received from the in= itiator after the final login response
>>      has = been sent
>>    * taking a reasonable timeout, say a sec= ond (the exact value
>>      does not matter as the= initiator can't count on it anyway and
>>      no = value will solve the problem in full, theoretically).
>>   &n= bsp;* doing both, that is waiting for the first incoming PDU and
>>= ;      taking a timer to start sending NOP-INs in case no PD= Us arrived
>>      during the timeout period, to be= able to detect silent connection
>>      failures.=
>
> I believe the second and third bullets ought to be combine= d, in that
> receipt of a PDU is sufficient reason to end the timeout= period before
> it would otherwise expire.

I agree

>= ;
>> 5. "New" target and "new" initiator will = count on iSERHello as the
>>    guarantee of proper buff= er posting
>>
>> 6. "Old" target and "old&= quot; initiator will work as they do now, in their
>>    = ;double bliss of ignorance.
>
> We also need to issue a warning= about the latter combination risking
> RCaP session termination if u= nsolicited PDUs show up from the target
> before the initiator is rea= dy.

Ok

> If the above looks close to correct, we can start= working on text for
> the draft ...

I'm ok with this

A= lexander
_______________________________________________
storm mailin= g list
storm@ietf.org
https://= www.ietf.org/mailman/listinfo/storm

 

= --_000_8D3D17ACE214DC429325B2B98F3AE71208DD8957MX15Acorpemccom_-- From Mark_Bakke@DELL.com Thu Jul 19 15:39:44 2012 Return-Path: X-Original-To: storm@ietfa.amsl.com Delivered-To: storm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F140211E80A6 for ; Thu, 19 Jul 2012 15:39:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.348 X-Spam-Level: X-Spam-Status: No, score=-106.348 tagged_above=-999 required=5 tests=[AWL=0.250, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id yqNQgWQC+Tqs for ; Thu, 19 Jul 2012 15:39:40 -0700 (PDT) Received: from aussmtpmrkpc120.us.dell.com (aussmtpmrkpc120.us.dell.com [143.166.82.159]) by ietfa.amsl.com (Postfix) with ESMTP id 91CED11E8087 for ; Thu, 19 Jul 2012 15:39:39 -0700 (PDT) X-Loopcount0: from 64.238.244.148 X-IronPort-AV: E=Sophos;i="4.77,618,1336366800"; d="scan'208,217";a="508773640" Received: from mail.compellent.com ([64.238.244.148]) by aussmtpmrkpc120.us.dell.com with ESMTP; 19 Jul 2012 17:40:33 -0500 From: Mark Bakke To: "david.black@emc.com" , "storm@ietf.org" Date: Thu, 19 Jul 2012 17:40:31 -0500 Thread-Topic: iSCSI MIB: Heartbeat counters for NOP-In and NOP-Out Usage Thread-Index: Ac1fZpN1pUNbVByGSYmBlR/YJY9UBQBkbhagAUGWQoA= Message-ID: <975552A94CBC0F4DA60ED7B36C949CBA03F3D38388@shandy.Beer.Town> References: <975552A94CBC0F4DA60ED7B36C949CBA03F1834043@shandy.Beer.Town> <8D3D17ACE214DC429325B2B98F3AE71208D3B54C@MX15A.corp.emc.com> In-Reply-To: <8D3D17ACE214DC429325B2B98F3AE71208D3B54C@MX15A.corp.emc.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: multipart/alternative; boundary="_000_975552A94CBC0F4DA60ED7B36C949CBA03F3D38388shandyBeerTow_" MIME-Version: 1.0 Cc: "mrm@vmware.com" , "prakashvn@hcl.com" Subject: Re: [storm] iSCSI MIB: Heartbeat counters for NOP-In and NOP-Out Usage X-BeenThere: storm@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Storage Maintenance WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 19 Jul 2012 22:39:44 -0000 --_000_975552A94CBC0F4DA60ED7B36C949CBA03F3D38388shandyBeerTow_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable I agree with David on the new functionality being added separately from the= MIB Doctor review. That said, we'll need to figure out what's significant= work and what isn't. So, on the particular question of heartbeats, is there support for: * Adding NOP counters at session scope (simple enough to add in the= next version) * Adding NOP counters at connection scope (requires a new table, so= it would be a more significant change) * Adding nothing I also agree with David that the above would be useful (at either session o= r connection) and that they would need to be optional for compliance. Mark From: david.black@emc.com [mailto:david.black@emc.com] Sent: Friday, July 13, 2012 8:24 AM To: Mark Bakke; storm@ietf.org Cc: mrm@vmware.com; prakashvn@hcl.com; ttalpey@microsoft.com; david.black@e= mc.com Subject: RE: iSCSI MIB: Heartbeat counters for NOP-In and NOP-Out Usage Hi Mark, The MIB Doctor review contained a number of suggestions for functional enha= ncements. My view is that significant enhancements need to be worked on in a new draf= t in the WG, unless their absence is a significant problem for MIB usabilit= y. Obviously, whether an enhancement is "significant" or its absence cause= s a "significant problem" is a judgment call, so YMMV. I view addition of a new table as being significant, so my suggestions woul= d be: - Add the NOP counters at session scope to avoid a new table. - Add the NOP timeout counters at connection scope. This is based on the current MIB structure that tracks activity at a sessio= n level (sufficient if things are working) and tracks errors by connection = (useful if something has gone wrong, as the problem may be connection-speci= fic). Counter32 values ought to suffice, as they're used for commands and respons= es (as you note). Also, NOPs, whether used for heartbeats or otherwise sho= uld not be sent at any significant fraction of the line rate. It probably doesn't hurt to add the data timeout counter, but that seems le= ss important (IMHO) by comparison to the NOP timeout counter as data timeou= t will manifest as a failed SCSI command, of which notice will be taken hi= gher in the SCSI stack. In contrast, iSCSI NOP timeouts aren't SCSI errors= . I strongly suggest that these new counters not be required for MODULE-COMPL= IANCE. Thanks, --David From: Mark Bakke [mailto:Mark_Bakke@DELL.com] Sent: Thursday, July 12, 2012 9:29 AM To: Storm (storm@ietf.org) Cc: MacFaden, Michael (VMware); prakashvn@hcl.com; Black, David; ttalpey@mi= crosoft.com Subject: iSCSI MIB: Heartbeat counters for NOP-In and NOP-Out Usage Everyone, One of things pointed out during the MIB doctor review is that although mos= t implementations use NOP-In and NOP-Out as a heartbeat / keepalive mechani= sm, we don't provide counters for them or for timeouts based on missing hea= rtbeats in the MIB module. Since this requires a few new objects to be added to the MIB, I wanted to v= et this by the list with two questions: 1. Will it be useful to provide these counters? 2. If so, which counters? For example, to count the NOPs themselves, we can add to either iscsiSessio= nStatsTable or iscsiConnectionStatsTable if we want to keep track of Nop-Ins and Nop-Outs per connection. This shou= ld go to the list. Is Counter32 sufficient for Nops since it is OK for com= mands and responses? I think so: iscsiSsnNopIns Counter32, iscsiSsnNopOuts Counter32, If we do this, do we want per-session or per-connection? If it's per-conne= ction it would require an additional table. Is Counter32 sufficient? I believe so, since it's what we use for commands= and responses, and the number of NOPs certainly won't exceed these. The second part is to provide counters that indicate timeouts based on non-= receipt of NOP responses. This would likely be added to the session's erro= r stats table. Mike MacFaden asked us to consider separate counters for heartbeat / noop v= s data timeouts. | | +--iscsiInstanceSsnErrorStatsTable(2) | | | | | +--iscsiInstanceSsnErrorStatsEntry(1) [iscsiInstIndex] | | | | | +-- r-n Counter32 iscsiInstSsnDigestErrors(1) | | +-- r-n Counter32 iscsiInstSsnCxnTimeoutErrors(2) | | +-- r-n Counter32 iscsiInstSsnFormatErrors(3) Adding something like this might do the trick: iscsiInstSsnNopTimeoutErrors Counter32 iscsiInstSsnDataTimeoutErrors Counter32 Any thoughts on what would be useful for that? Anyone already count these = in your implementations for other purposes? Thanks, Mark --_000_975552A94CBC0F4DA60ED7B36C949CBA03F3D38388shandyBeerTow_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

I agree w= ith David on the new functionality being added separately from the MIB Doct= or review.  That said, we’ll need to figure out what’s sig= nificant work and what isn’t.

 

So, on th= e particular question of heartbeats, is there support for:

·      = ;   Adding NOP counters at = session scope (simple enough to add in the next version)<= /p>

·       &n= bsp; Adding NOP counters at connectio= n scope (requires a new table, so it would be a more significant change)

&middo= t;    &nbs= p;    Adding nothing

 

I also agree with David that the above would b= e useful (at either session or connection) and that they would need to be o= ptional for compliance.

 

Mark

 

=

From: david.black@emc.com [mailto:david.black@emc.com] <= br>Sent: Friday, July 13, 2012 8:24 AM
To: Mark Bakke; sto= rm@ietf.org
Cc: mrm@vmware.com; prakashvn@hcl.com; ttalpey@micros= oft.com; david.black@emc.com
Subject: RE: iSCSI MIB: Heartbeat co= unters for NOP-In and NOP-Out Usage

 

Hi Mark,

 

<= span style=3D'font-size:10.0pt;font-family:"Courier New";color:black'><W= G chair hat off>

 

The MIB Doctor review contained a number of s= uggestions for functional enhancements.

 

My view is that significant= enhancements need to be worked on in a new draft in the WG, unless their a= bsence is a significant problem for MIB usability.  Obviously, whether= an enhancement is “significant” or its absence causes a “= ;significant problem” is a judgment call, so YMMV.<= /p>

 

I view add= ition of a new table as being significant, so my suggestions would be:=

- Add the NOP = counters at session scope to avoid a new table.

- Add the NOP timeout counters at con= nection scope.

This is based on the c= urrent MIB structure that tracks activity at a session level (sufficient if= things are working) and tracks errors by connection (useful if something h= as gone wrong, as the problem may be connection-specific).

 

Counter3= 2 values ought to suffice, as they’re used for commands and responses= (as you note).  Also, NOPs, whether used for heartbeats or otherwise = should not be sent at any significant fraction of the line rate.=

 

It= probably doesn’t hurt to add the data timeout counter, but that seem= s less important (IMHO) by comparison to the NOP timeout counter as data ti= meout  will manifest as a failed SCSI command, of which notice will be= taken higher in the SCSI stack.  In contrast, iSCSI NOP timeouts aren= ’t SCSI errors.

 

I strongly suggest that these new counters no= t be required for MODULE-COMPLIANCE.

=  

Thanks,
--David

 

From: Mark Bakke [mailto:Mark_= Bakke@DELL.com]
Sent: Thursday, July 12, 2012 9:29 AM
To:<= /b> Storm (storm@ietf.org)
Cc: MacFaden, Michael (VMware); prakas= hvn@hcl.com; Black, David; ttalpey@microsoft.com
Subject: iSCSI M= IB: Heartbeat counters for NOP-In and NOP-Out Usage

 

Ev= eryone,

 

One of things pointed out during the MIB doctor review is that al= though most implementations use NOP-In and NOP-Out as a heartbeat / keepali= ve mechanism, we don’t provide counters for them or for timeouts base= d on missing heartbeats in the MIB module.

 

Since this requires a few new = objects to be added to the MIB, I wanted to vet this by the list with two q= uestions:

 

1.      Will it be useful to provide these counters?

2.      If= so, which counters?

 

For example, to count the NOPs themselves, we can ad= d to either iscsiSessionStatsTable or iscsiConnectionStatsTable<= /p>

 

if we wan= t to keep track of Nop-Ins and Nop-Outs per connection.  This should g= o to the list.  Is Counter32 sufficient for Nops since it is OK for co= mmands and responses?  I think so:

=  

    iscsiSsnNopIns=              &n= bsp;    Counter32,

&= nbsp;   iscsiSsnNopOuts       =         Counter32,

 

If we do this, do w= e want per-session or per-connection?  If it’s per-connection it= would require an additional table.

 

Is Counter32 sufficient?  I beli= eve so, since it’s what we use for commands and responses, and the nu= mber of NOPs certainly won’t exceed these.

 

The second part is to pr= ovide counters that indicate timeouts based on non-receipt of NOP responses= .  This would likely be added to the session’s error stats table= .

 

Mike MacFaden asked us to consider separate counters for heartbeat / no= op vs data timeouts.

 

  |  |  +--iscsiInstanceSsnErrorStatsTabl= e(2)

  |  |  &nbs= p;  |

  |  | &nbs= p;   +--iscsiInstanceSsnErrorStatsEntry(1) [iscsiInstIndex]<= /o:p>

  |  |    &n= bsp;   |

  |  |&n= bsp;       +-- r-n Counter32 iscsiInstSsnDige= stErrors(1)

  |  | &nb= sp;      +-- r-n Counter32 iscsiInstSsnCxnTimeoutE= rrors(2)

  |  |  =       +-- r-n Counter32 iscsiInstSsnFormatErrors(3= )

 

Adding something like this might do the trick:<= /p>

 

 &nbs= p;      iscsiInstSsnNopTimeoutErrors   &= nbsp;Counter32

   &nbs= p;    iscsiInstSsnDataTimeoutErrors   Counter32

      &nb= sp;

Any thoughts on what would be us= eful for that?  Anyone already count these in your implementations for= other purposes?

 

Thanks,

 = ;

Mark

 

 

= --_000_975552A94CBC0F4DA60ED7B36C949CBA03F3D38388shandyBeerTow_-- From Frederick.Knight@netapp.com Fri Jul 20 12:08:45 2012 Return-Path: X-Original-To: storm@ietfa.amsl.com Delivered-To: storm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6AB4711E80C4 for ; Fri, 20 Jul 2012 12:08:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.598 X-Spam-Level: X-Spam-Status: No, score=-10.598 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id aZZUBZkqkyoN for ; Fri, 20 Jul 2012 12:08:44 -0700 (PDT) Received: from mx2.netapp.com (mx2.netapp.com [216.240.18.37]) by ietfa.amsl.com (Postfix) with ESMTP id 7380211E80C9 for ; Fri, 20 Jul 2012 12:08:44 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.77,625,1336374000"; d="scan'208,217";a="667425052" Received: from smtp1.corp.netapp.com ([10.57.156.124]) by mx2-out.netapp.com with ESMTP; 20 Jul 2012 12:09:26 -0700 Received: from vmwexceht02-prd.hq.netapp.com (vmwexceht02-prd.hq.netapp.com [10.106.76.240]) by smtp1.corp.netapp.com (8.13.1/8.13.1/NTAP-1.6) with ESMTP id q6KJ9QGh021006 for ; Fri, 20 Jul 2012 12:09:26 -0700 (PDT) Received: from SACEXCMBX04-PRD.hq.netapp.com ([169.254.6.188]) by vmwexceht02-prd.hq.netapp.com ([10.106.76.240]) with mapi id 14.02.0298.004; Fri, 20 Jul 2012 12:09:25 -0700 From: "Knight, Frederick" To: "storm@ietf.org" Thread-Topic: iSCSI new features (SAM-5 update) draft rev 6 Thread-Index: Ac1mqXNesUa0E5JwS1Sa/iuNpTjlXA== Date: Fri, 20 Jul 2012 19:09:24 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.104.60.116] Content-Type: multipart/alternative; boundary="_000_FFEE311F0EC80C4EA64EC8757CAD0CD22F3F66SACEXCMBX04PRDhqn_" MIME-Version: 1.0 Subject: [storm] iSCSI new features (SAM-5 update) draft rev 6 X-BeenThere: storm@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Storage Maintenance WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 20 Jul 2012 19:08:45 -0000 --_000_FFEE311F0EC80C4EA64EC8757CAD0CD22F3F66SACEXCMBX04PRDhqn_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable After this was submitted, it was noticed that the .txt version has several = formatting issues - particularly in the ASCII diagrams and figures and the = table that shows the concept mappings between iSCSI and SAM. The .PDF version of the document is correct. Obviously, I'll make sure this gets fixed. Fred Knight --_000_FFEE311F0EC80C4EA64EC8757CAD0CD22F3F66SACEXCMBX04PRDhqn_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

After this was submitted, it was noticed that the .t= xt version has several formatting issues – particularly in the ASCII = diagrams and figures and the table that shows the concept mappings between = iSCSI and SAM.

 

The .PDF version of the document is correct.

 

Obviously, I’ll make sure this gets fixed.

 

   &n= bsp;            Fred Knight

 

--_000_FFEE311F0EC80C4EA64EC8757CAD0CD22F3F66SACEXCMBX04PRDhqn_-- From mkosjc@gmail.com Tue Jul 24 17:27:03 2012 Return-Path: X-Original-To: storm@ietfa.amsl.com Delivered-To: storm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AA45411E8080 for ; Tue, 24 Jul 2012 17:27:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.598 X-Spam-Level: X-Spam-Status: No, score=-3.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kkhnxFen3boO for ; Tue, 24 Jul 2012 17:27:02 -0700 (PDT) Received: from mail-vb0-f44.google.com (mail-vb0-f44.google.com [209.85.212.44]) by ietfa.amsl.com (Postfix) with ESMTP id 6502D21F84DF for ; Tue, 24 Jul 2012 17:27:02 -0700 (PDT) Received: by vbbez10 with SMTP id ez10so119418vbb.31 for ; Tue, 24 Jul 2012 17:27:01 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:date:message-id:subject:from:to:content-type; bh=EmQoVL4a2Zt/xiihJX31AxepBhoL8h4O5wljy8M1+EA=; b=OqcQEsUM0f40UYNqoI1W+39OCiSclj83o+iwRIfxZwLFqRomkpC1Un8VD/p0aFUfii r/9re5VLg9k+/xmo0jmkCu9NidU1PYN4SdItFLVp4IAwpSJO9riPN1IXozAyJVnqXeYM +/837dK7f2uu87EISzaTm6DH4LArbaHbqooZLqcxTX0KsPsY6QVGVO6bX6fXgfxjSrzY BOTrm2Z+qf1OtJCViyGOUacOEuFU41T1fZwy7iV7Tv19UvhjOnfJ5ZePHHcWv3+XMfew lkJPEZsPHFcLg/eWzEEEmf3XwuwUCpj/Xz62F2/C3tj+nJ3mtmipnZEv6rquKthNvvhY D/oQ== MIME-Version: 1.0 Received: by 10.52.173.39 with SMTP id bh7mr7695418vdc.101.1343176021459; Tue, 24 Jul 2012 17:27:01 -0700 (PDT) Received: by 10.220.92.210 with HTTP; Tue, 24 Jul 2012 17:27:01 -0700 (PDT) Date: Tue, 24 Jul 2012 17:27:01 -0700 Message-ID: From: Michael Ko To: storm@ietf.org Content-Type: multipart/alternative; boundary=bcaec51b9d01a141f104c59c890b Subject: [storm] Proposed text changes for the connection allocation problem X-BeenThere: storm@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Storage Maintenance WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 25 Jul 2012 00:27:03 -0000 --bcaec51b9d01a141f104c59c890b Content-Type: text/plain; charset=ISO-8859-1 These are the changes I intend to incorporate into the existing draft to solve the connection allocation problem by using the iSER Hello exchanges. Please comment. 5.1.1 Initiator Behavior original: If the outcome of the iSCSI negotiation is to enable iSER-assisted mode, then on the initiator side, prior to sending the Login Request with the T (Transit) bit set to 1 and the NSG (Next Stage) field set to FullFeaturePhase, the iSCSI Layer MUST request the iSER Layer to allocate the connection resources necessary to support RCaP by invoking the Allocate_Connection_Resources Operational Primitive. replacement: If the outcome of the iSCSI negotiation is to enable iSER-assisted mode, then on the initiator side, prior to sending the Login Request with the T (Transit) bit set to 1 and the NSG (Next Stage) field set to FullFeaturePhase, the iSCSI Layer SHOULD request the iSER Layer to allocate the connection resources necessary to support RCaP by invoking the Allocate_Connection_Resources Operational Primitive. deleted: If the iSER Layer at the initiator is successful in allocating the connection resources necessary to support RCaP, the following events MUST occur in the specified sequence: [The numbered items will be retained but without the numbering.] new: If the iSCSI Layer on the initiator side allocates the connection resources to support RCaP only after it receives the final Login Response PDU from the target, then it may not be able to handle the number of unexpected iSCSI control-type PDUs (as declared by the MaxOutstandingUnexpectedPDUs key from the initiator) that can be sent by the target before the buffer resources are allocated at the initiator side. In this case the iSERHelloRequired key MUST be negotiated to Yes so that the initiator can allocate the connection resources before sending the iSER Hello Message. See section 5.1.3 for more details. 5.1.3 iSER Hello Exchange new: The connection resources can be allocated at the initiator side after it has received the final Login Response PDU from the target. To prevent the potential problem caused by the target sending the number of unexpected iSCSI control-type PDUs as determined by the MaxOustandingUnexpectedPDUs key allowed in the FullFeaturePhase, the iSER Hello exchanges can be used. This allows the initiator to allocate the connection resources before sending the iSER Hello Message. The iSERHelloRequired key is used by the initiator to determine if it is dealing with a target that supports the iSER Hello exchanges. As the iSERHelloRequired key is not defined in [RFC5046], an initiator/target must be able to deal with a target/initiator that does not understand the key or support the iSER Hello exchanges. For a target, if the iSERHelloRequired key is not negotiated, it MUST still respond with the iSER HelloReply Message when it recieves the iSER Hello Message. If the iSERHelloRequired key is negotiated to No or NotUnderstood, a target MAY choose to terminate the connection; otherwise it SHOULD delay sending any unexpected control-type PDUs until one of the following events has occurred: 1. A PDU is received from the initiator after it sends the final Login Response PDU. 2. A system configurable timeout period, say one second, has expired. For an initiator, if the iSERHelloRequired key is negotiated to No or NotUnderstood, it MAY choose to terminate the connection; otherwise it SHOULD do one of the following: 1. Allocate the connection resources before sending the final Login Request PDU. 2. Allocate one or more buffers for receiving unexpected control-type PDUs from the target before sending the final Login Request PDU. This reduces the possibility of the unexpected control-type PDUs causing the RCaP connection to close before the connection resources have been allocated. 10.1.3.4 iSER Protocol Errors original: Conversely, it is a protocol error if the iSER Hello Message is sent by the iSER Layer at the initiator when iSERHelloRequired is negotiated to "No". new: Conversely, if the iSER Hello Message is sent by the iSER Layer at the initiator when iSERHelloRequired is negotiated to "No", the iSER Layer at the target MAY treat this as a protocol error or respond with an iSER HelloReply Message. Mike --bcaec51b9d01a141f104c59c890b Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable These are the changes I intend to incorporate into the existing draft to so= lve the connection allocation problem by using the iSER Hello exchanges.=A0= Please comment.

5.1.1=A0 Initiator Behavior

original:
If the outcome of the iSCSI negotiation is to enable iSER-assisted mode, th= en on the initiator side, prior to sending the Login Request with the T (Tr= ansit) bit set to 1 and the NSG (Next Stage) field set to FullFeaturePhase,= the iSCSI Layer MUST request the iSER Layer to allocate the connection res= ources necessary to support RCaP by invoking the Allocate_Connection_Resour= ces Operational Primitive.

replacement:

If the outcome of the iSCSI negotiation is to enabl= e iSER-assisted mode, then on the initiator side, prior to sending the Logi= n Request with the T (Transit) bit set to 1 and the NSG (Next Stage) field = set to FullFeaturePhase, the iSCSI Layer SHOULD request the iSER Layer to a= llocate the connection resources necessary to support RCaP by invoking the = Allocate_Connection_Resources Operational Primitive.

deleted:

If the iSER Layer at the initiator is successful in all= ocating the connection resources necessary to support RCaP, the following e= vents MUST occur in the specified sequence:=A0 [The numbered items will be = retained but without the numbering.]

new:

If the iSCSI Layer on the initiator side allocates the conn= ection resources to support RCaP only after it receives the final Login Res= ponse PDU from the target, then it may not be able to handle the number of = unexpected iSCSI control-type PDUs (as declared by the MaxOutstandingUnexpe= ctedPDUs key from the initiator) that can be sent by the target before the = buffer resources are allocated at the initiator side.=A0 In this case the i= SERHelloRequired key MUST be negotiated to Yes so that the initiator can al= locate the connection resources before sending the iSER Hello Message.=A0 S= ee section 5.1.3 for more details.

5.1.3=A0 iSER Hello Exchange

new:

The connection resource= s can be allocated at the initiator side after it has received the final Lo= gin Response PDU from the target.=A0 To prevent the potential problem cause= d by the target sending the number of unexpected iSCSI control-type PDUs as= determined by the MaxOustandingUnexpectedPDUs key allowed in the FullFeatu= rePhase, the iSER Hello exchanges can be used.=A0 This allows the initiator= to allocate the connection resources before sending the iSER Hello Message= .=A0 The iSERHelloRequired key is used by the initiator to determine if it = is dealing with a target that supports the iSER Hello exchanges.

As the iSERHelloRequired key is not defined in [RFC5046], an initiator/= target must be able to deal with a target/initiator that does not understan= d the key or support the iSER Hello exchanges.

For a target, if the = iSERHelloRequired key is not negotiated, it MUST still respond with the iSE= R HelloReply Message when it recieves the iSER Hello Message.=A0 If the iSE= RHelloRequired key is negotiated to No or NotUnderstood, a target MAY choos= e to terminate the connection; otherwise it SHOULD delay sending any unexpe= cted control-type PDUs until one of the following events has occurred:

1. A PDU is received from the initiator after it sends the final Login = Response PDU.

2. A system configurable timeout period, say one secon= d, has expired.

For an initiator, if the iSERHelloRequired key is ne= gotiated to No or NotUnderstood, it MAY choose to terminate the connection;= otherwise it SHOULD do one of the following:

1. Allocate the connection resources before sending the final Login Req= uest PDU.

2. Allocate one or more buffers for receiving unexpected c= ontrol-type PDUs from the target before sending the final Login Request PDU= .=A0 This reduces the possibility of the unexpected control-type PDUs causi= ng the RCaP connection to close before the connection resources have been a= llocated.

10.1.3.4 iSER Protocol Errors

original:

Conversely, it is= a protocol error if the iSER Hello Message is sent by the iSER Layer at th= e initiator when iSERHelloRequired is negotiated to "No".

new:

Conversely, if the iSER Hello Message is sent by the iSER L= ayer at the initiator when iSERHelloRequired is negotiated to "No"= ;, the iSER Layer at the target MAY treat this as a protocol error or respo= nd with an iSER HelloReply Message.

Mike

--bcaec51b9d01a141f104c59c890b-- From david.black@emc.com Wed Jul 25 15:23:35 2012 Return-Path: X-Original-To: storm@ietfa.amsl.com Delivered-To: storm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 642AF21F860F; Wed, 25 Jul 2012 15:23:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.467 X-Spam-Level: X-Spam-Status: No, score=-102.467 tagged_above=-999 required=5 tests=[AWL=0.132, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6sMlfx-ONYKB; Wed, 25 Jul 2012 15:23:34 -0700 (PDT) Received: from mexforward.lss.emc.com (hop-nat-141.emc.com [168.159.213.141]) by ietfa.amsl.com (Postfix) with ESMTP id 7776621F860D; Wed, 25 Jul 2012 15:23:34 -0700 (PDT) Received: from hop04-l1d11-si01.isus.emc.com (HOP04-L1D11-SI01.isus.emc.com [10.254.111.54]) by mexforward.lss.emc.com (Switch-3.4.3/Switch-3.4.3) with ESMTP id q6PMNXj2006170 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 25 Jul 2012 18:23:33 -0400 Received: from mailhub.lss.emc.com (mailhub.lss.emc.com [10.254.221.253]) by hop04-l1d11-si01.isus.emc.com (RSA Interceptor); Wed, 25 Jul 2012 18:23:21 -0400 Received: from mxhub25.corp.emc.com (mxhub25.corp.emc.com [10.254.110.181]) by mailhub.lss.emc.com (Switch-3.4.3/Switch-3.4.3) with ESMTP id q6PMNL4i021907; Wed, 25 Jul 2012 18:23:21 -0400 Received: from mx15a.corp.emc.com ([169.254.1.189]) by mxhub25.corp.emc.com ([10.254.110.181]) with mapi; Wed, 25 Jul 2012 18:23:21 -0400 From: To: Date: Wed, 25 Jul 2012 18:23:19 -0400 Thread-Topic: [storm] Last Call: (Internet Small Computer Systems Interface (iSCSI) SCSI Features Update) to Proposed Standard Thread-Index: Ac1jmPAUY2+NTO/yRKSSSk6Mu3Kr0wHGedfA Message-ID: <8D3D17ACE214DC429325B2B98F3AE71208DD9404@MX15A.corp.emc.com> References: <20120716211939.22533.77051.idtracker@ietfa.amsl.com> In-Reply-To: <20120716211939.22533.77051.idtracker@ietfa.amsl.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-EMM-MHVC: 1 Cc: storm@ietf.org Subject: Re: [storm] Last Call: (Internet Small Computer Systems Interface (iSCSI) SCSI Features Update) to Proposed Standard X-BeenThere: storm@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Storage Maintenance WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 25 Jul 2012 22:23:35 -0000 A number of the documents referenced by this draft are T10 (SCSI) standards that are access-restricted to members of that organization unless a copy is purchased - this requirement has been imposed by the parent organization of T10; please do not complain to T10 about this. As the official liaison from T10 to the IETF, I am authorized to provide copies of these standards to IETF participants for their personal use in IETF activity. Of course, if you work for a company that is a T10 or T11 member, you can get these documents directly, and I'd ask that you do so. This applies to the following documents: - Normative references: -- T10 [SAM2] T10/1157D, SCSI Architecture Model - 2 (SAM-2). [SAM4] ISO/IEC 14776-414, SCSI Architecture Model - 4 (SAM-4). The Committee Drafts of [SAM5] and [SPC4] are public documents. I can help with access to them if there are problems. If you would like copies of any of these standards, please send me an email directly (please *don't* cc: either the IETF or STORM mailing lists) and indicate which standards you would like copies of. Of course, if you work for a company that is a T10 or T11 member, you can obtain these documents directly, and I'd ask that you do so. Thanks, --David ---------------------------------------------------- David L. Black, Distinguished Engineer EMC Corporation, 176 South St., Hopkinton, MA=A0 01748 +1 (508) 293-7953=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 FAX: +1 (508) 293-778= 6 david.black@emc.com=A0=A0=A0=A0=A0=A0=A0 Mobile: +1 (978) 394-7754 ---------------------------------------------------- > -----Original Message----- > From: storm-bounces@ietf.org [mailto:storm-bounces@ietf.org] On Behalf Of= The > IESG > Sent: Monday, July 16, 2012 5:20 PM > To: IETF-Announce > Cc: storm@ietf.org > Subject: [storm] Last Call: (Internet > Small Computer Systems Interface (iSCSI) SCSI Features Update) to Propose= d > Standard >=20 >=20 > The IESG has received a request from the STORage Maintenance WG (storm) > to consider the following document: > - 'Internet Small Computer Systems Interface (iSCSI) SCSI Features > Update' > as Proposed Standard >=20 > The IESG plans to make a decision in the next few weeks, and solicits > final comments on this action. Please send substantive comments to the > ietf@ietf.org mailing lists by 2012-08-13. Exceptionally, comments may be > sent to iesg@ietf.org instead. In either case, please retain the > beginning of the Subject line to allow automated sorting. >=20 > Please note the concurrent Last Call for draft-ietf-storm-iscsi-cons, as = both > drafts should be reviewed together. >=20 > Abstract >=20 >=20 > Internet Small Computer Systems Interface (iSCSI) is a SCSI > transport protocol that maps the SCSI family of protocols onto > TCP/IP. The iSCSI protocol as specified in [draft-ietf-storm- > iscsi-cons-xx] (and as previously specified by the combination > of RFC 3720 and RFC 5048) is based on the SAM-2 (SCSI > Architecture Model - 2) version of the SCSI family of > protocols. This document defines enhancements to the iSCSI > protocol to support certain additional features of the SCSI > protocol that were defined in SAM-3, SAM-4, and SAM-5. >=20 > This document is a companion document to [draft-ietf-storm- > iscsi-cons-xx]. >=20 > -------------------------------------------------------- > RFC EDITORS NOTE: The above references to [draft-ietf-storm- > iscsi-cons-xx] should reference the RFC number assigned to > that document, and this note should be removed. > -------------------------------------------------------- >=20 > This last call explicitly identifies these downrefs in the normative > references > of this document: >=20 > [SAM2] T10/1157D, SCSI Architecture Model - 2 (SAM-2). >=20 > [SAM4] ISO/IEC 14776-414, SCSI Architecture Model - 4 (SAM- > 4). >=20 > [SAM5] T10/2104D rev r04, SCSI Architecture Model - 5 (SAM- > 5), Committee Draft. >=20 > [SPC4] T10/1731D rev r23, SCSI Primary Commands - 4 (SPC-4), > Committee Draft. >=20 >=20 > The file can be obtained via > http://datatracker.ietf.org/doc/draft-ietf-storm-iscsi-sam/ >=20 > IESG discussion can be tracked via > http://datatracker.ietf.org/doc/draft-ietf-storm-iscsi-sam/ballot/ >=20 >=20 > No IPR declarations have been submitted directly on this I-D. >=20 >=20 > _______________________________________________ > storm mailing list > storm@ietf.org > https://www.ietf.org/mailman/listinfo/storm From david.black@emc.com Wed Jul 25 15:24:44 2012 Return-Path: X-Original-To: storm@ietfa.amsl.com Delivered-To: storm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A823B21F8611; Wed, 25 Jul 2012 15:24:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.454 X-Spam-Level: X-Spam-Status: No, score=-102.454 tagged_above=-999 required=5 tests=[AWL=0.145, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Zfi8HQEjKJI3; Wed, 25 Jul 2012 15:24:42 -0700 (PDT) Received: from mexforward.lss.emc.com (hop-nat-141.emc.com [168.159.213.141]) by ietfa.amsl.com (Postfix) with ESMTP id 8F03121F8605; Wed, 25 Jul 2012 15:24:42 -0700 (PDT) Received: from hop04-l1d11-si02.isus.emc.com (HOP04-L1D11-SI02.isus.emc.com [10.254.111.55]) by mexforward.lss.emc.com (Switch-3.4.3/Switch-3.4.3) with ESMTP id q6PMOJxs008981 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 25 Jul 2012 18:24:19 -0400 Received: from mailhub.lss.emc.com (mailhubhoprd02.lss.emc.com [10.254.221.253]) by hop04-l1d11-si02.isus.emc.com (RSA Interceptor); Wed, 25 Jul 2012 18:24:07 -0400 Received: from mxhub06.corp.emc.com (mxhub06.corp.emc.com [128.222.70.203]) by mailhub.lss.emc.com (Switch-3.4.3/Switch-3.4.3) with ESMTP id q6PMO6vC022621; Wed, 25 Jul 2012 18:24:06 -0400 Received: from mxhub38.corp.emc.com (128.222.70.105) by mxhub06.corp.emc.com (128.222.70.203) with Microsoft SMTP Server (TLS) id 8.3.213.0; Wed, 25 Jul 2012 18:24:06 -0400 Received: from mx15a.corp.emc.com ([169.254.1.189]) by mxhub38.corp.emc.com ([128.222.70.105]) with mapi; Wed, 25 Jul 2012 18:24:05 -0400 From: To: Date: Wed, 25 Jul 2012 18:24:05 -0400 Thread-Topic: [storm] Last Call: (iSCSI Protocol (Consolidated)) to Proposed Standard Thread-Index: Ac1jmNrMAsNJQSnqTqmIPlssgGmhSQHGIIiQ Message-ID: <8D3D17ACE214DC429325B2B98F3AE71208DD9405@MX15A.corp.emc.com> References: <20120716211850.4308.53226.idtracker@ietfa.amsl.com> In-Reply-To: <20120716211850.4308.53226.idtracker@ietfa.amsl.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-EMM-MHVC: 1 Cc: storm@ietf.org Subject: Re: [storm] Last Call: (iSCSI Protocol (Consolidated)) to Proposed Standard X-BeenThere: storm@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Storage Maintenance WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 25 Jul 2012 22:24:44 -0000 A number of the documents referenced by this draft are T10 (SCSI) and T11 (= FC) standards that are access-restricted to members of those organizations unle= ss a copy is purchased - this requirement has been imposed by the parent organ= ization of T10 and T11; please do not complain to T10 or T11 about this. As the official liaison from both T10 and T11 to the IETF, I am authorized to prov= ide copies of these standards to IETF participants for their personal use in IETF activity. This applies to the following documents: - Normative references: -- T10 [SAM2] T10/1157-D, SCSI Architecture Model - 2 (SAM-2). [SAM3] T10/1561-D, SCSI Architecture Model - 3 (SAM-3). [SAM4] T10/1683-D, SCSI Architecture Model - 4 (SAM-4). [SBC2] NCITS.405-205, SCSI Block Commands - 2 (SBC-2). [SPC3] T10/1416-D, SCSI Primary Commands-3. -- T11 [FC-FS] INCITS 373-2003, Fibre Channel Framing and Signaling Interface (FC-FS). - Informative References -- T10 [SAS] INCITS 376-2003, Serial Attached SCSI (SAS). [SRP] INCITS 365-2002, SCSI RDMA Protocol (SRP). If you would like copies of any of these standards, please send me an email directly (please *don't* cc: either the IETF or STORM mailing lists) and indicate which standards you would like copies of. Of course, if you work for a company that is a T10 or T11 member, you can get these documents directly, and I'd ask that you do so. Thanks, --David > -----Original Message----- > From: storm-bounces@ietf.org [mailto:storm-bounces@ietf.org] On Behalf Of= The > IESG > Sent: Monday, July 16, 2012 5:19 PM > To: IETF-Announce > Cc: storm@ietf.org > Subject: [storm] Last Call: (iSCSI > Protocol (Consolidated)) to Proposed Standard >=20 >=20 > The IESG has received a request from the STORage Maintenance WG (storm) > to consider the following document: > - 'iSCSI Protocol (Consolidated)' > as Proposed Standard >=20 > The IESG plans to make a decision in the next few weeks, and solicits > final comments on this action. Please send substantive comments to the > ietf@ietf.org mailing lists by 2012-08-13. Exceptionally, comments may be > sent to iesg@ietf.org instead. In either case, please retain the > beginning of the Subject line to allow automated sorting. >=20 > Please note the concurrent Last Call for draft-ietf-storm-iscsi-sam, as b= oth > drafts should be reviewed together. >=20 > Abstract >=20 >=20 > This document describes a transport protocol for SCSI that works > on top of TCP. The iSCSI protocol aims to be fully compliant with > the standardized SCSI Architecture Model (SAM-2). RFC 3720 > defined the original iSCSI protocol. RFC 3721 discusses iSCSI > Naming examples and discovery techniques. Subsequently, RFC 3980 > added an additional naming format to iSCSI protocol. RFC 4850 > followed up by adding a new public extension key to iSCSI. RFC > 5048 offered a number of clarifications and a few improvements and > corrections to the original iSCSI protocol. >=20 >=20 > This document obsoletes RFCs 3720, 3980, 4850 and 5048 by > consolidating them into a single document and making additional > updates to the consolidated specification. This document also > updates RFC 3721 and RFC 3723. The text in this document thus > supersedes the text in all the noted RFCs wherever there is a > difference in semantics. >=20 > This last call explicitly identifies these downrefs in the normative > references > of this document: > [EUI] "Guidelines for 64-bit Global Identifier (EUI-64)", > http://standards.ieee.org/regauth/oui/tutorials/EUI64.html >=20 > [FC-FS] INCITS 373-2003, Fibre Channel Framing and Signaling > Interface (FC-FS). >=20 > [OUI] "IEEE OUI and Company_Id Assignments", > http://standards.ieee.org/regauth/oui >=20 > [SAM2] T10/1157-D, SCSI Architecture Model - 2 (SAM-2). >=20 > [SAM3] T10/1561-D, SCSI Architecture Model - 3 (SAM-3). >=20 > [SAM4] T10/1683-D, SCSI Architecture Model - 4 (SAM-4). >=20 > [SBC2] NCITS.405-205, SCSI Block Commands - 2 (SBC-2). >=20 > [SPC3] T10/1416-D, SCSI Primary Commands-3. >=20 > [UML] ISO/IEC 19501, Unified Modeling Language > Specification Version 1.4.2. >=20 > [UNICODE] Unicode Standard Annex #15, "Unicode Normalization > Forms", http://www.unicode.org/unicode/reports/tr15 >=20 >=20 >=20 > The file can be obtained via > http://datatracker.ietf.org/doc/draft-ietf-storm-iscsi-cons/ >=20 > IESG discussion can be tracked via > http://datatracker.ietf.org/doc/draft-ietf-storm-iscsi-cons/ballot/ >=20 >=20 > No IPR declarations have been submitted directly on this I-D. >=20 >=20 > _______________________________________________ > storm mailing list > storm@ietf.org > https://www.ietf.org/mailman/listinfo/storm From david.black@emc.com Thu Jul 26 06:46:47 2012 Return-Path: X-Original-To: storm@ietfa.amsl.com Delivered-To: storm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2A0B221F876C for ; Thu, 26 Jul 2012 06:46:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.457 X-Spam-Level: X-Spam-Status: No, score=-102.457 tagged_above=-999 required=5 tests=[AWL=0.142, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tj0BJ5KxsOeh for ; Thu, 26 Jul 2012 06:46:46 -0700 (PDT) Received: from mexforward.lss.emc.com (hop-nat-141.emc.com [168.159.213.141]) by ietfa.amsl.com (Postfix) with ESMTP id 8D0A521F8767 for ; Thu, 26 Jul 2012 06:46:46 -0700 (PDT) Received: from hop04-l1d11-si01.isus.emc.com (HOP04-L1D11-SI01.isus.emc.com [10.254.111.54]) by mexforward.lss.emc.com (Switch-3.4.3/Switch-3.4.3) with ESMTP id q6QDkgoC009232 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Thu, 26 Jul 2012 09:46:44 -0400 Received: from mailhub.lss.emc.com (mailhubhoprd03.lss.emc.com [10.254.221.145]) by hop04-l1d11-si01.isus.emc.com (RSA Interceptor) for ; Thu, 26 Jul 2012 09:46:34 -0400 Received: from mxhub22.corp.emc.com (mxhub22.corp.emc.com [128.222.70.134]) by mailhub.lss.emc.com (Switch-3.4.3/Switch-3.4.3) with ESMTP id q6QDkY4I008746 for ; Thu, 26 Jul 2012 09:46:34 -0400 Received: from mx15a.corp.emc.com ([169.254.1.189]) by mxhub22.corp.emc.com ([128.222.70.134]) with mapi; Thu, 26 Jul 2012 09:46:34 -0400 From: To: Date: Thu, 26 Jul 2012 09:46:33 -0400 Thread-Topic: iSCSI drafts - T10 and T11 references Thread-Index: Ac1rNRGDFlJk/LPPRq2a5Pa224AxSw== Message-ID: <8D3D17ACE214DC429325B2B98F3AE71208DD94B1@MX15A.corp.emc.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-EMM-MHVC: 1 Subject: [storm] iSCSI drafts - T10 and T11 references X-BeenThere: storm@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Storage Maintenance WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 26 Jul 2012 13:46:47 -0000 In making up the lists of T10 and T11 documents that are currently referenced, some of those references don't look right to me, for example: - T10: I'm not sure whether we need to reference SAM-2, -3 and -4. - T11: The FC-FS reference is out of date. As part of dealing with the comments from IETF Last Call, we'll need to go over all of the T10 and T11 references (and should check all the references) to make sure that they're up to date and necessary. Thanks, --David ---------------------------------------------------- David L. Black, Distinguished Engineer EMC Corporation, 176 South St., Hopkinton, MA=A0 01748 +1 (508) 293-7953=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 FAX: +1 (508) 293-778= 6 david.black@emc.com=A0=A0=A0=A0=A0=A0=A0 Mobile: +1 (978) 394-7754 ----------------------------------------------------