From david.black@emc.com Fri Jul 1 12:23:37 2011 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 282C39E800C for ; Fri, 1 Jul 2011 12:23:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.599 X-Spam-Level: X-Spam-Status: No, score=-106.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qiC7r2H-wQgm for ; Fri, 1 Jul 2011 12:23:36 -0700 (PDT) Received: from mexforward.lss.emc.com (mexforward.lss.emc.com [128.222.32.20]) by ietfa.amsl.com (Postfix) with ESMTP id 8BD659E8008 for ; Fri, 1 Jul 2011 12:23:36 -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 p61JNVfT022198 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Fri, 1 Jul 2011 15:23:32 -0400 Received: from mailhub.lss.emc.com (mailhub.lss.emc.com [10.254.222.226]) by hop04-l1d11-si02.isus.emc.com (RSA Interceptor) for ; Fri, 1 Jul 2011 15:23:16 -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 p61JMa0L006159 for ; Fri, 1 Jul 2011 15:22:37 -0400 Received: from mx14a.corp.emc.com ([169.254.1.245]) by mxhub20.corp.emc.com ([10.254.93.49]) with mapi; Fri, 1 Jul 2011 15:22:36 -0400 From: To: Date: Fri, 1 Jul 2011 15:22:34 -0400 Thread-Topic: Preliminary Quebec City meeting agenda Thread-Index: Acw4JDsUcJvKTmMfT+uuChZDEn0+RA== Message-ID: <7C4DFCE962635144B8FAE8CA11D0BF1E0589392344@MX14A.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="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-EMM-MHVC: 1 Subject: [storm] Preliminary Quebec City meeting agenda 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, 01 Jul 2011 19:23:37 -0000 FYI, expect this to be slightly revised next week, Thanks, --David ----------------------------------- IETF storm (STORage Maintenance) WG Meeting agenda (v1) Tuesday, July 26, 2011, 1710-1810 Quebec City, QC, Canada ----------------------------------- Administrivia, agenda bashing, etc. - 10 min David L. Black, EMC & Tom Talpey, Microsoft (WG co-chairs) Blue sheets Note Well Milestones Note-taker Draft status - 5 min David L. Black, EMC (co-chair) iFCP update and associated iFCP MIB update - Published as RFCs 6172 and 61= 73 MPA update - Publication Requested, AD is processing iSCSI drafts (Consolidated, SAM and MIB) iSER draft RDMA extensions (not currently a WG draft) iSCSI Drafts (draft-ietf-storm-iscsi-cons-02, draft-ietf-storm-iscsi-sam-02= ) - 10 min Fred Knight, NetApp & WG co-chairs Issues that need attention from WG Last Call (to start in early July), if = any Status of engagement of iSCSI implementers to review these drafts iSCSI MIB draft (if needed, status report under "Draft status" above may su= ffice) - 5 min iSER draft (draft-ietf-storm-iser-02) - 10 min Mike Ko, HuaweiSymantec (on behalf of draft authors) Summarize known topics & issues that need attention RDMA Protocol Extensions Draft (draft-ietf-storm-rdmap-ext-00) - 20 min Hemal Shah, Broadcom (on behalf of draft authors) NOTE: Despite its filename, this is not an official storm WG draft. Discussion of draft contents and rationale. Question: Should WG should adopt this draft as a work item. From david.black@emc.com Fri Jul 1 13:43:06 2011 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 8EDF411E81C3 for ; Fri, 1 Jul 2011 13:43:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.599 X-Spam-Level: X-Spam-Status: No, score=-106.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id G7Hn3xgnW7eX for ; Fri, 1 Jul 2011 13:43:05 -0700 (PDT) Received: from mexforward.lss.emc.com (mexforward.lss.emc.com [128.222.32.20]) by ietfa.amsl.com (Postfix) with ESMTP id A969911E81C1 for ; Fri, 1 Jul 2011 13:43:05 -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 p61Kh4au022379 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Fri, 1 Jul 2011 16:43:04 -0400 Received: from mailhub.lss.emc.com (mailhubhoprd01.lss.emc.com [10.254.221.251]) by hop04-l1d11-si04.isus.emc.com (RSA Interceptor) for ; Fri, 1 Jul 2011 16:42:52 -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 p61KgC8U004527 for ; Fri, 1 Jul 2011 16:42:13 -0400 Received: from mx14a.corp.emc.com ([169.254.1.245]) by mxhub09.corp.emc.com ([10.254.92.104]) with mapi; Fri, 1 Jul 2011 16:42:12 -0400 From: To: Date: Fri, 1 Jul 2011 16:42:11 -0400 Thread-Topic: Nomcom announcement Thread-Index: Acw4L1pEZK4h+t8ATOSm8B2zN1LZUw== Message-ID: <7C4DFCE962635144B8FAE8CA11D0BF1E0589392375@MX14A.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="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-EMM-MHVC: 1 Subject: [storm] Nomcom announcement 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, 01 Jul 2011 20:43:06 -0000 Forwarded for Suresh Krishnan, IETF Nomcom chair 2011-12 This is the Second call for Volunteers for the 2011-12 Nomcom. We are just about halfway through the volunteer period so if you are considering volunteering, please do so very soon.=20 We have had a very good response to the initial call for volunteers and I am pleased to report that we have 50 volunteers thus far whose qualifications have been confirmed by the secretariat. I have notified each of these volunteers by email. =20 However, we would like to have many more volunteers. The more volunteers, the better chance we have of choosing a random yet representative cross=20 section of the IETF population. You have until 11:59 pm EDT July 10, 2011=20 to volunteer for Nomcom but it would be much better if you can volunteer=20 as early as possible.=20 If you volunteered before 21:00 EDT on June 21 to serve as a voting member and have not received a confirmation email from me, please re-submit and=20 bring to my attention right away! =20 Details about the process for volunteering for the Nomcom and the list=20 of open positions for which the nominating committee is responsible are summarized in the initial announcement: https://datatracker.ietf.org/ann/nomcom/2938/ The 50 volunteers who have thus far been qualified by the secretariat are:=20 Alia Atlas , Juniper Networks Lixia Zhang , UCLA Wassim Haddad , Ericsson Glen Zorn , Network Zen Richard Barnes , BBN Technologies Stephen Kent , BBN Technologies Scott Mansfield , Ericsson Tina TSOU , FutureWei Technologies Fernando Gont , UTN/FRH Karen Seo , BBN Technologies Jie Dong , Huawei Technologies Mach Chen , Huawei Technologies Co. Sheng Jiang , Huawei Technologies Co. Ltd. Dimitri Papadimitriou , Alcatel-Lucent Thomas D. Nadeau , CA Technologies David Meyer , Cisco Systems/University of Oregon Wesley George , Time Warner Cable Cullen Jennings , Cisco Stephen Hanna , Juniper Networks Stephan Wenger , Bidyo Keyur Patel , Cisco Systems Michael Hamilton , BreakingPoint Systems Behcet Sarikaya , Huawei USA Mark Townsley , Cisco Systems Fred Baker , Cisco Systems Brian Trammell , ETH Zurich Sam Hartman , Painless Security Chris Griffiths , Comcast George Michaelson , APNIC Jiankang Yao , CNNIC Sohel Khan , Comcast Dacheng Zhang , Huawei Lianshu Zheng , Huawei Technologies Hui Deng , China Mobile Gang Chen , China Mobile Mirja Kuhlewind , University of Stuttgart John E Drake , Juniper Networks Matt Lepinski , BBN Technologies Subir Das , Telcordia Technologies Inc Yi Zhao , Huawei John Scudder , Juniper Networks Christer Holmberg , LM Ericsson Teemu Savolainen , Nokia Samita Chakrabarti , Ericsson Jaap Akkerhuis , NLnet labs Jason Weil , Time Warner Cable Randy Bush , Internet Initiative Japan Christian Schmidt , Nokia Siemens Networks Sean Shen , CNNIC Lou Berger , LabN Consulting The primary activity for this nomcom will begin during IETF-81 in Quebec City and should be completed by January 2012. The nomcom will be collecting requirements from the community, as well as talking to candidates and to community members about candidates. There will be regularly scheduled conference calls to ensure progress. Thus, being a nomcom member does require some time commitment. =20 Please volunteer by sending an email to me before=20 11:59 pm EDT July 10, 2011 as follows: To: suresh.krishnan@ericsson.com Subject: Nomcom 2011-12 Volunteer Please include the following information in the body of the mail: Full Name: // As you enter in the IETF Registration Form, // First/Given name followed by Last/Family Name Current Primary Affiliation: // typically what goes in the Company=20 // field in the IETF Registration Form Email Address(es): // all email addresses used to Register for the=20 // past 5 IETF meetings // Please designate a Preferred email address for // contact if there is more than one email address Telephone number: // With country code (for confirmation if selected) Please expect an email response from me within 3 business days stating whether or not you are qualified. If you do not receive a response in this timeframe, please re-send your email with the tag "RESEND:" added to the subject line. If you are not yet sure you would like to volunteer, please consider that Nomcom members play a very important role in shaping the leadership of the IETF. Ensuring the leadership of the IETF is fair and balanced and comprised of those who can lead the IETF in the right direction is an important responsibility that rests on the IETF participants at large. Volunteering for the Nomcom is a good way of contributing in that direction. I will be publishing a more detailed target timetable, as well as details of the randomness seeds to be used for the RFC 3797 selection process within the next few days. Thank you in advance for your participation. Suresh Krishnan Nomcom Chair 2011-2012 Email: nomcom-chair@ietf.org, suresh.krishnan@ericsson.com From arkady.kanevsky@gmail.com Sun Jul 3 14:26:37 2011 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 4B00D21F85BA for ; Sun, 3 Jul 2011 14:26:37 -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 ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id htbQ85FAP2Zk for ; Sun, 3 Jul 2011 14:26:36 -0700 (PDT) Received: from mail-pv0-f172.google.com (mail-pv0-f172.google.com [74.125.83.172]) by ietfa.amsl.com (Postfix) with ESMTP id A801721F85A8 for ; Sun, 3 Jul 2011 14:26:36 -0700 (PDT) Received: by pvh18 with SMTP id 18so5940237pvh.31 for ; Sun, 03 Jul 2011 14:26:36 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=jvdXeCSrmy/3jm2WaMwhasvzISmTkC6Kp6kXvGofc0w=; b=kwDA2tyHcFkPN9Db1rjWE2mE0fUUwfPLBJK1wLSW0hkumb40DZqs8w9TJ09Wizfceg zv/T7oGD6qnmdYeSWmIpc5FpGR98LZBS4m3Cp0qWQbgz8QrGHLxHXqHEWsqyPbYO0qfx IzF+HjqBFI9lBVJEE70KFGBm49kN2ap0qJ2Ro= MIME-Version: 1.0 Received: by 10.142.150.19 with SMTP id x19mr2713120wfd.112.1309728395880; Sun, 03 Jul 2011 14:26:35 -0700 (PDT) Received: by 10.142.174.11 with HTTP; Sun, 3 Jul 2011 14:26:35 -0700 (PDT) In-Reply-To: <7C4DFCE962635144B8FAE8CA11D0BF1E0589392344@MX14A.corp.emc.com> References: <7C4DFCE962635144B8FAE8CA11D0BF1E0589392344@MX14A.corp.emc.com> Date: Sun, 3 Jul 2011 17:26:35 -0400 Message-ID: From: arkady kanevsky To: david.black@emc.com Content-Type: multipart/alternative; boundary=000e0cd23050c9eada04a730e74f Cc: storm@ietf.org Subject: Re: [storm] Preliminary Quebec City meeting agenda 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, 03 Jul 2011 21:26:37 -0000 --000e0cd23050c9eada04a730e74f Content-Type: text/plain; charset=ISO-8859-1 David, do you expect a phone bridge for the STORM session? Thanks, Arkady On Fri, Jul 1, 2011 at 3:22 PM, wrote: > FYI, expect this to be slightly revised next week, Thanks, --David > > ----------------------------------- > IETF storm (STORage Maintenance) WG > Meeting agenda (v1) > Tuesday, July 26, 2011, 1710-1810 > Quebec City, QC, Canada > ----------------------------------- > > Administrivia, agenda bashing, etc. - 10 min > David L. Black, EMC & Tom Talpey, Microsoft (WG co-chairs) > Blue sheets > Note Well > Milestones > Note-taker > > Draft status - 5 min > David L. Black, EMC (co-chair) > iFCP update and associated iFCP MIB update - Published as RFCs 6172 > and 6173 > MPA update - Publication Requested, AD is processing > iSCSI drafts (Consolidated, SAM and MIB) > iSER draft > RDMA extensions (not currently a WG draft) > > iSCSI Drafts (draft-ietf-storm-iscsi-cons-02, > draft-ietf-storm-iscsi-sam-02) - 10 min > Fred Knight, NetApp & WG co-chairs > Issues that need attention from WG Last Call (to start in early > July), if any > Status of engagement of iSCSI implementers to review these drafts > > iSCSI MIB draft (if needed, status report under "Draft status" above may > suffice) - 5 min > > iSER draft (draft-ietf-storm-iser-02) - 10 min > Mike Ko, HuaweiSymantec (on behalf of draft authors) > Summarize known topics & issues that need attention > > RDMA Protocol Extensions Draft (draft-ietf-storm-rdmap-ext-00) - 20 min > Hemal Shah, Broadcom (on behalf of draft authors) > NOTE: Despite its filename, this is not an official storm WG draft. > > Discussion of draft contents and rationale. > Question: Should WG should adopt this draft as a work item. > > _______________________________________________ > storm mailing list > storm@ietf.org > https://www.ietf.org/mailman/listinfo/storm > -- Cheers, Arkady Kanevsky --000e0cd23050c9eada04a730e74f Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable David,
do you expect a phone bridge for the STORM session?
Thanks,Arkady

On Fri, Jul 1, 2011 at 3:22 PM, = <david.black@em= c.com> wrote:
FYI, expect this to be slightly revised nex= t week, Thanks, --David

-----------------------------------
IETF storm (STORage Maintenance) WG
Meeting agenda (v1)
Tuesday, July 26, 2011, 1710-1810
Quebec City, QC, Canada
-----------------------------------

Administrivia, agenda bashing, etc. - 10 min
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0David L. Black, EMC & Tom Talpey, Micro= soft (WG co-chairs)
=A0 =A0 =A0 =A0Blue sheets
=A0 =A0 =A0 =A0Note Well
=A0 =A0 =A0 =A0Milestones
=A0 =A0 =A0 =A0Note-taker

Draft status - 5 min
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0David L. Black, EMC (co-chair)
=A0 =A0 =A0 =A0iFCP update and associated iFCP MIB update - Published as R= FCs 6172 and 6173
=A0 =A0 =A0 =A0MPA update - Publication Requested, AD is processing
=A0 =A0 =A0 =A0iSCSI drafts (Consolidated, SAM and MIB)
=A0 =A0 =A0 =A0iSER draft
=A0 =A0 =A0 =A0RDMA extensions (not currently a WG draft)

iSCSI Drafts (draft-ietf-storm-iscsi-cons-02, draft-ietf-storm-iscsi-sam-02= ) - 10 min
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0Fred Knight, NetApp & WG co-chairs
=A0 =A0 =A0 =A0Issues that need attention from WG Last Call (to start in e= arly July), if any
=A0 =A0 =A0 =A0Status of engagement of iSCSI implementers to review these = drafts

iSCSI MIB draft (if needed, status report under "Draft status" ab= ove may suffice) - 5 min

iSER draft (draft-ietf-storm-iser-02) - 10 min
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0Mike Ko, HuaweiSymantec (on behalf of draft= authors)
=A0 =A0 =A0 =A0Summarize known topics & issues that need attention

RDMA Protocol Extensions Draft (draft-ietf-storm-rdmap-ext-00) - 20 min
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0Hemal Shah, Broadcom (on behalf of draft au= thors)
=A0 =A0 =A0 =A0NOTE: Despite its filename, this is not an official storm W= G draft.

=A0 =A0 =A0 =A0Discussion of draft contents and rationale.
=A0 =A0 =A0 =A0Question: Should WG should adopt this draft as a work item.=

_______________________________________________
storm mailing list
storm@ietf.org
h= ttps://www.ietf.org/mailman/listinfo/storm



--
Cheers,
Arkady Kanev= sky
--000e0cd23050c9eada04a730e74f-- From mbakke@cisco.com Sun Jul 3 20:51:23 2011 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 5629B21F852C for ; Sun, 3 Jul 2011 20:51:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id BdSkpjhPKP0I for ; Sun, 3 Jul 2011 20:51:22 -0700 (PDT) Received: from rcdn-iport-1.cisco.com (rcdn-iport-1.cisco.com [173.37.86.72]) by ietfa.amsl.com (Postfix) with ESMTP id 3417221F852A for ; Sun, 3 Jul 2011 20:51:22 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=mbakke@cisco.com; l=7297; q=dns/txt; s=iport; t=1309751482; x=1310961082; h=mime-version:content-transfer-encoding:subject:date: message-id:in-reply-to:references:from:to; bh=lDh5CO8OPr+pZ4P4CDhIDQ32WoIy0solJH5zQuMpRCg=; b=Cup5TWZLwvR9CCmhwyIqF5GaIvi713pfK8D5PEDtFzOUR+c6Uawv9Td0 7CCz/P5gw4qR3HY9bt1bP5lmPaGsxkMl7lQbcYQBRKW7jNg6WCS6ixyOG hiRKRtoS7z+Ih4G+7gNx1Hvpcc3qpvIuQLnxZNQl7bnNPtjyf/UYYQUFK c=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgIBABY4EU6tJXG8/2dsb2JhbABMBhCYOI80d64qnQmCP3yCewSHP494in5V X-IronPort-AV: E=Sophos;i="4.65,470,1304294400"; d="scan'208";a="85646" Received: from rcdn-core2-1.cisco.com ([173.37.113.188]) by rcdn-iport-1.cisco.com with ESMTP; 04 Jul 2011 03:51:20 +0000 Received: from xbh-rcd-202.cisco.com (xbh-rcd-202.cisco.com [72.163.62.201]) by rcdn-core2-1.cisco.com (8.14.3/8.14.3) with ESMTP id p643pK7J002367; Mon, 4 Jul 2011 03:51:20 GMT Received: from xmb-rcd-105.cisco.com ([72.163.62.147]) by xbh-rcd-202.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Sun, 3 Jul 2011 22:51:20 -0500 X-Mimeole: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Date: Sun, 3 Jul 2011 22:51:18 -0500 Message-ID: <97CC2D4896BE5D48825529CE9A16882505E23845@XMB-RCD-105.cisco.com> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [storm] Consolidated iSCSI draft and TaskReporting Thread-Index: AQDeOsqbPwyi4a8ddBcbQxUWgjUBFQKxRZHdAgOPlpyWjMTOgIAFGOsg References: <1308321497.3882.10.camel@chiron.ofa><7C4DFCE962635144B8FAE8CA11D0BF1E0589310372@MX14A.corp.emc.com> From: "Mark Bakke (mbakke)" To: "Mallikarjun Chadalapaka" , , , X-OriginalArrivalTime: 04 Jul 2011 03:51:20.0546 (UTC) FILETIME=[A2A9FC20:01CC39FD] Subject: Re: [storm] Consolidated iSCSI draft and TaskReporting 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, 04 Jul 2011 03:51:23 -0000 Mallikarjun and David, In the iSCSI MIB (draft-00 will be posted by tomorrow morning PST), we = have added iSCSIProtocolLevel to the Session attributes: iscsiSsnProtocolLevel OBJECT-TYPE SYNTAX Unsigned32 (1..65535) MAX-ACCESS read-only STATUS current DESCRIPTION "The iSCSI protocol level negotiated for this session." REFERENCE "[iSCSI-SAM], Section 7.1.1, iSCSIProtocolLevel" DEFVAL { 1 } ::=3D { iscsiSessionAttributesEntry 22 } Instead of describing what the numbers mean as below, we are just = referencing the SAM draft. Is that the right thing, or is there more = description we should be adding? I'm fine with just referencing another spec, since that means we won't = have to respin the MIB if another protocol level is added. Thanks, Mark -----Original Message----- From: storm-bounces@ietf.org [mailto:storm-bounces@ietf.org] On Behalf = Of Mallikarjun Chadalapaka Sent: Thursday, June 30, 2011 5:07 PM To: david.black@emc.com; pmacarth@iol.unh.edu; storm@ietf.org Subject: Re: [storm] Consolidated iSCSI draft and TaskReporting I'm OK with leaving out the phrase you point out - I meant it to cover = the case of an acceptor in a key negotiation. But I see your point. I was thinking along the lines of each spec "claiming" a number for the iSCSIProtocolLevel key, so no one spec necessarily has a table of all = the keys. Currently, Consolidated draft claims "1", and SAM draft claims = "2". Sounds like you're thinking a table with currently claimed iSCSIProtocolLevel values in this spec? I am fine with that too. Thanks. Mallikarjun -----Original Message----- From: david.black@emc.com [mailto:david.black@emc.com] Sent: Thursday, June 30, 2011 1:31 PM To: cbm@chadalapaka.com; pmacarth@iol.unh.edu; storm@ietf.org Subject: RE: [storm] Consolidated iSCSI draft and TaskReporting =20 =20 We should do what Mallikarjun proposes. A table will be needed that = lists the RFCs for each value of the iSCSIProtocolLevel key. =20 One change - "(or would have offered)" should be removed from Mallikarjun's proposed text. Hypothetical requirements tend to be difficult to test and moreover are usually pointless - the values that are = actually used in negotiation are what should govern protocol behavior. =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-7786 david.black@emc.com=A0=A0=A0=A0=A0=A0=A0 Mobile: +1 (978) 394-7754 ---------------------------------------------------- =20 > -----Original Message----- > From: storm-bounces@ietf.org [mailto:storm-bounces@ietf.org] On Behalf > Of Mallikarjun Chadalapaka > Sent: Friday, June 17, 2011 8:24 PM > To: 'Patrick MacArthur'; storm@ietf.org > Subject: Re: [storm] Consolidated iSCSI draft and TaskReporting > > Hi Patrick, > > I tend to agree with you, you raise a valid point. > > The problem lies in special-casing RFC 3720. I think the right way = to > address your comment is to require that an implementation's "NotUnderstood" > response should correlate to the highest protocol version that it = has > offered (or would have offered) for the iSCSIProtocolLevel key in a > negotiation. E.g., let's say if an iSCSI implementation has = *offered* a > value of 2 in a negotiation (even though the other side has = negotiated > it down to 1), it means that the offering implementation can > comprehend all text keys defined through the spec with > iSCSIProtocolLevel=3D2. So it must not respond to any of those text = keys with a "NotUnderstood". > > So the formal verbiage would look something like the following: > > An iSCSI implementation MUST comprehend all text keys defined in = iSCSI > Protocol specifications from [RFC3720] through the RFC keyed to the > highest protocol version that the implementation has offered (or = would > have offered) for the iSCSIProtocolLevel key in a negotiation. > Returning a NotUnderstood response on any of these text keys = therefore > MUST be considered a protocol error and handled accordingly. For = all > other "later" keys, i.e. text keys defined in specifications keyed = to > higher values of iSCSIProtocolLevel, a NotUnderstood answer = concludes > the negotiation for a negotiated key whereas for a declarative key, = a > NotUnderstood answer simply informs the declarer of a lack of comprehension by the receiver. > > Please let me know if you have comments or questions. Thanks. > > Mallikarjun > > > > -----Original Message----- > From: storm-bounces@ietf.org [mailto:storm-bounces@ietf.org] On Behalf > Of Patrick MacArthur > Sent: Friday, June 17, 2011 7:38 AM > To: storm@ietf.org > Subject: [storm] Consolidated iSCSI draft and TaskReporting > > Hi, > > I wanted to ask for clarification on an item appearing in the consolidated > iSCSI draft. > > "All keys defined in [RFC3720] MUST be supported by all > compliant implementations; a NotUnderstood answer on any of = the > [RFC3720] keys therefore MUST be considered a protocol error = and > handled accordingly. For all other later keys, a NotUnderstood > answer concludes the negotiation for a negotiated key whereas = for > a declarative key, a NotUnderstood answer simply informs the > declarer of a lack of comprehension by the receiver." > > I would like to request that the references to RFC3720 above be changed to > RFC3720 and RFC5048. The comments on this list seem to indicate = that the > baseline for the iSCSI work is on the combination of RFC 3720 and = RFC > 5048, which I interpret to mean that it would be applicable only = to > implementations compliant with both RFCs. An implementation that > claims to be RFC 5048-compliant and responds with > TaskReporting=3DNotUnderstood is broken IMHO. In that case, is = there a > reason that we allow a NotUnderstood response on an RFC 5048 key > (TaskReporting)? > > If the STORM WG is trying to ensure compatibility with the requirements of > RFC 3720 and RFC 5048 combined, it seems strange to be allowing > implementers not to implement the key requirement of RFC 5048. > > Thanks, > > -- > Patrick MacArthur > Research and Development > iSCSI/OFA/IPv6 Consortia > UNH InterOperability Laboratory > > _______________________________________________ > storm mailing list > storm@ietf.org > https://www.ietf.org/mailman/listinfo/storm > > _______________________________________________ > storm mailing list > storm@ietf.org > https://www.ietf.org/mailman/listinfo/storm _______________________________________________ storm mailing list storm@ietf.org https://www.ietf.org/mailman/listinfo/storm From internet-drafts@ietf.org Mon Jul 4 00:53:42 2011 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 D81BC21F8602; Mon, 4 Jul 2011 00:53:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.591 X-Spam-Level: X-Spam-Status: No, score=-102.591 tagged_above=-999 required=5 tests=[AWL=0.008, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id aAiPmdZ1AlCr; Mon, 4 Jul 2011 00:53:40 -0700 (PDT) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DB09A21F8453; Mon, 4 Jul 2011 00:53:39 -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: 3.55 Message-ID: <20110704075339.13788.9113.idtracker@ietfa.amsl.com> Date: Mon, 04 Jul 2011 00:53:39 -0700 Cc: storm@ietf.org Subject: [storm] I-D Action: draft-ietf-storm-iscsimib-00.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, 04 Jul 2011 07:53:42 -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-00.txt Pages : 86 Date : 2011-07-04 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. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-storm-iscsimib-00.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ This Internet-Draft can be retrieved at: ftp://ftp.ietf.org/internet-drafts/draft-ietf-storm-iscsimib-00.txt From david.black@emc.com Tue Jul 5 05:40:03 2011 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 3ED2421F8730 for ; Tue, 5 Jul 2011 05:40:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.599 X-Spam-Level: X-Spam-Status: No, score=-106.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Sg0aFTw5xysz for ; Tue, 5 Jul 2011 05:40:02 -0700 (PDT) Received: from mexforward.lss.emc.com (mexforward.lss.emc.com [128.222.32.20]) by ietfa.amsl.com (Postfix) with ESMTP id EDD8B21F8676 for ; Tue, 5 Jul 2011 05:40:01 -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 p65Cdwnx009417 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 5 Jul 2011 08:39:58 -0400 Received: from mailhub.lss.emc.com (mailhub.lss.emc.com [10.254.222.226]) by hop04-l1d11-si03.isus.emc.com (RSA Interceptor); Tue, 5 Jul 2011 08:39:47 -0400 Received: from mxhub27.corp.emc.com (mxhub27.corp.emc.com [10.254.110.183]) by mailhub.lss.emc.com (Switch-3.4.3/Switch-3.4.3) with ESMTP id p65CdK75018769; Tue, 5 Jul 2011 08:39:20 -0400 Received: from mx14a.corp.emc.com ([169.254.1.245]) by mxhub27.corp.emc.com ([10.254.110.183]) with mapi; Tue, 5 Jul 2011 08:39:20 -0400 From: To: , , , Date: Tue, 5 Jul 2011 08:39:18 -0400 Thread-Topic: [storm] Consolidated iSCSI draft and TaskReporting Thread-Index: AQDeOsqbPwyi4a8ddBcbQxUWgjUBFQKxRZHdAgOPlpyWjMTOgIAFGOsggAImkaA= Message-ID: <7C4DFCE962635144B8FAE8CA11D0BF1E0589392435@MX14A.corp.emc.com> References: <1308321497.3882.10.camel@chiron.ofa><7C4DFCE962635144B8FAE8CA11D0BF1E0589310372@MX14A.corp.emc.com> <97CC2D4896BE5D48825529CE9A16882505E23845@XMB-RCD-105.cisco.com> In-Reply-To: <97CC2D4896BE5D48825529CE9A16882505E23845@XMB-RCD-105.cisco.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] Consolidated iSCSI draft and TaskReporting 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, 05 Jul 2011 12:40:03 -0000 Mark, That will suffice for now. The next version of the SAM draft will create a= n IANA registry for these values; I would reference the SAM draft for the d= efinition of iSCSIProtocolLevel (as you've done) plus the registry for the = values. Thanks, --David > -----Original Message----- > From: Mark Bakke (mbakke) [mailto:mbakke@cisco.com] > Sent: Sunday, July 03, 2011 11:51 PM > To: Mallikarjun Chadalapaka; Black, David; pmacarth@iol.unh.edu; storm@ie= tf.org > Subject: RE: [storm] Consolidated iSCSI draft and TaskReporting >=20 > Mallikarjun and David, >=20 > In the iSCSI MIB (draft-00 will be posted by tomorrow morning PST), we ha= ve added iSCSIProtocolLevel > to the Session attributes: >=20 > iscsiSsnProtocolLevel OBJECT-TYPE > SYNTAX Unsigned32 (1..65535) > MAX-ACCESS read-only > STATUS current > DESCRIPTION > "The iSCSI protocol level negotiated for this session." > REFERENCE > "[iSCSI-SAM], Section 7.1.1, iSCSIProtocolLevel" > DEFVAL { 1 } > ::=3D { iscsiSessionAttributesEntry 22 } >=20 > Instead of describing what the numbers mean as below, we are just referen= cing the SAM draft. Is that > the right thing, or is there more description we should be adding? >=20 > I'm fine with just referencing another spec, since that means we won't ha= ve to respin the MIB if > another protocol level is added. >=20 > Thanks, >=20 > Mark >=20 >=20 > -----Original Message----- > From: storm-bounces@ietf.org [mailto:storm-bounces@ietf.org] On Behalf Of= Mallikarjun Chadalapaka > Sent: Thursday, June 30, 2011 5:07 PM > To: david.black@emc.com; pmacarth@iol.unh.edu; storm@ietf.org > Subject: Re: [storm] Consolidated iSCSI draft and TaskReporting >=20 > I'm OK with leaving out the phrase you point out - I meant it to cover th= e > case of an acceptor in a key negotiation. But I see your point. >=20 > I was thinking along the lines of each spec "claiming" a number for the > iSCSIProtocolLevel key, so no one spec necessarily has a table of all the > keys. Currently, Consolidated draft claims "1", and SAM draft claims "2= ". > Sounds like you're thinking a table with currently claimed > iSCSIProtocolLevel values in this spec? I am fine with that too. >=20 > Thanks. >=20 > Mallikarjun >=20 >=20 > -----Original Message----- > From: david.black@emc.com [mailto:david.black@emc.com] > Sent: Thursday, June 30, 2011 1:31 PM > To: cbm@chadalapaka.com; pmacarth@iol.unh.edu; storm@ietf.org > Subject: RE: [storm] Consolidated iSCSI draft and TaskReporting >=20 > >=20 > We should do what Mallikarjun proposes. A table will be needed that li= sts > the RFCs for each value of the iSCSIProtocolLevel key. >=20 > One change - "(or would have offered)" should be removed from > Mallikarjun's proposed text. Hypothetical requirements tend to be > difficult > to test and moreover are usually pointless - the values that are actual= ly > used in negotiation are what should govern protocol behavior. >=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= -7786 > david.black@emc.com=A0=A0=A0=A0=A0=A0=A0 Mobile: +1 (978) 394-7754 > ---------------------------------------------------- >=20 > > -----Original Message----- > > From: storm-bounces@ietf.org [mailto:storm-bounces@ietf.org] On > Behalf > > Of Mallikarjun Chadalapaka > > Sent: Friday, June 17, 2011 8:24 PM > > To: 'Patrick MacArthur'; storm@ietf.org > > Subject: Re: [storm] Consolidated iSCSI draft and TaskReporting > > > > Hi Patrick, > > > > I tend to agree with you, you raise a valid point. > > > > The problem lies in special-casing RFC 3720. I think the right way t= o > > address your comment is to require that an implementation's > "NotUnderstood" > > response should correlate to the highest protocol version that it has > > offered (or would have offered) for the iSCSIProtocolLevel key in a > > negotiation. E.g., let's say if an iSCSI implementation has *offere= d* > a > > value of 2 in a negotiation (even though the other side has negotiate= d > > it down to 1), it means that the offering implementation can > > comprehend all text keys defined through the spec with > > iSCSIProtocolLevel=3D2. So it must not respond to any of those text = keys > with a "NotUnderstood". > > > > So the formal verbiage would look something like the following: > > > > An iSCSI implementation MUST comprehend all text keys defined in iSCS= I > > Protocol specifications from [RFC3720] through the RFC keyed to the > > highest protocol version that the implementation has offered (or woul= d > > have offered) for the iSCSIProtocolLevel key in a negotiation. > > Returning a NotUnderstood response on any of these text keys therefor= e > > MUST be considered a protocol error and handled accordingly. For all > > other "later" keys, i.e. text keys defined in specifications keyed to > > higher values of iSCSIProtocolLevel, a NotUnderstood answer conclude= s > > the negotiation for a negotiated key whereas for a declarative key, a > > NotUnderstood answer simply informs the declarer of a lack of > comprehension by the receiver. > > > > Please let me know if you have comments or questions. Thanks. > > > > Mallikarjun > > > > > > > > -----Original Message----- > > From: storm-bounces@ietf.org [mailto:storm-bounces@ietf.org] On > Behalf > > Of Patrick MacArthur > > Sent: Friday, June 17, 2011 7:38 AM > > To: storm@ietf.org > > Subject: [storm] Consolidated iSCSI draft and TaskReporting > > > > Hi, > > > > I wanted to ask for clarification on an item appearing in the > consolidated > > iSCSI draft. > > > > "All keys defined in [RFC3720] MUST be supported by all > > compliant implementations; a NotUnderstood answer on any of the > > [RFC3720] keys therefore MUST be considered a protocol error an= d > > handled accordingly. For all other later keys, a NotUnderstood > > answer concludes the negotiation for a negotiated key whereas f= or > > a declarative key, a NotUnderstood answer simply informs the > > declarer of a lack of comprehension by the receiver." > > > > I would like to request that the references to RFC3720 above be > changed > to > > RFC3720 and RFC5048. The comments on this list seem to indicate th= at > the > > baseline for the iSCSI work is on the combination of RFC 3720 and R= FC > > 5048, which I interpret to mean that it would be applicable only to > > implementations compliant with both RFCs. An implementation that > > claims to be RFC 5048-compliant and responds with > > TaskReporting=3DNotUnderstood is broken IMHO. In that case, is ther= e a > > reason that we allow a NotUnderstood response on an RFC 5048 key > > (TaskReporting)? > > > > If the STORM WG is trying to ensure compatibility with the > requirements > of > > RFC 3720 and RFC 5048 combined, it seems strange to be allowing > > implementers not to implement the key requirement of RFC 5048. > > > > Thanks, > > > > -- > > Patrick MacArthur > > Research and Development > > iSCSI/OFA/IPv6 Consortia > > UNH InterOperability Laboratory > > > > _______________________________________________ > > storm mailing list > > storm@ietf.org > > https://www.ietf.org/mailman/listinfo/storm > > > > _______________________________________________ > > storm mailing list > > storm@ietf.org > > https://www.ietf.org/mailman/listinfo/storm >=20 >=20 > _______________________________________________ > storm mailing list > storm@ietf.org > https://www.ietf.org/mailman/listinfo/storm From david.black@emc.com Tue Jul 5 05:42:31 2011 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 7C54621F86A9 for ; Tue, 5 Jul 2011 05:42:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.599 X-Spam-Level: X-Spam-Status: No, score=-106.599 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pUaiKDTWVvlg for ; Tue, 5 Jul 2011 05:42:29 -0700 (PDT) Received: from mexforward.lss.emc.com (mexforward.lss.emc.com [128.222.32.20]) by ietfa.amsl.com (Postfix) with ESMTP id 9DB2A21F869D for ; Tue, 5 Jul 2011 05:42:28 -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 p65CgQst013234 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 5 Jul 2011 08:42:27 -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, 5 Jul 2011 08:42:10 -0400 Received: from mxhub27.corp.emc.com (mxhub27.corp.emc.com [10.254.110.183]) by mailhub.lss.emc.com (Switch-3.4.3/Switch-3.4.3) with ESMTP id p65CedrG019648; Tue, 5 Jul 2011 08:40:39 -0400 Received: from mx14a.corp.emc.com ([169.254.1.245]) by mxhub27.corp.emc.com ([10.254.110.183]) with mapi; Tue, 5 Jul 2011 08:40:39 -0400 From: To: Date: Tue, 5 Jul 2011 08:40:38 -0400 Thread-Topic: [storm] Preliminary Quebec City meeting agenda Thread-Index: Acw5x+2ZqFiwuaYVSqS66CJSVTH5IwBSKbvw Message-ID: <7C4DFCE962635144B8FAE8CA11D0BF1E0589392436@MX14A.corp.emc.com> References: <7C4DFCE962635144B8FAE8CA11D0BF1E0589392344@MX14A.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_7C4DFCE962635144B8FAE8CA11D0BF1E0589392436MX14Acorpemcc_" MIME-Version: 1.0 X-EMM-MHVC: 1 Cc: storm@ietf.org Subject: Re: [storm] Preliminary Quebec City meeting agenda 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, 05 Jul 2011 12:42:31 -0000 --_000_7C4DFCE962635144B8FAE8CA11D0BF1E0589392436MX14Acorpemcc_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Yes and WebEx - I'll pass along logistics when available. Phone bridge may be for presenters only - multicast will be available for t= hose who only want to listen (+ jabber for questions). Thanks, --David From: arkady kanevsky [mailto:arkady.kanevsky@gmail.com] Sent: Sunday, July 03, 2011 5:27 PM To: Black, David Cc: storm@ietf.org Subject: Re: [storm] Preliminary Quebec City meeting agenda David, do you expect a phone bridge for the STORM session? Thanks, Arkady On Fri, Jul 1, 2011 at 3:22 PM, > wrote: FYI, expect this to be slightly revised next week, Thanks, --David ----------------------------------- IETF storm (STORage Maintenance) WG Meeting agenda (v1) Tuesday, July 26, 2011, 1710-1810 Quebec City, QC, Canada ----------------------------------- Administrivia, agenda bashing, etc. - 10 min David L. Black, EMC & Tom Talpey, Microsoft (WG co-chairs) Blue sheets Note Well Milestones Note-taker Draft status - 5 min David L. Black, EMC (co-chair) iFCP update and associated iFCP MIB update - Published as RFCs 6172 = and 6173 MPA update - Publication Requested, AD is processing iSCSI drafts (Consolidated, SAM and MIB) iSER draft RDMA extensions (not currently a WG draft) iSCSI Drafts (draft-ietf-storm-iscsi-cons-02, draft-ietf-storm-iscsi-sam-02= ) - 10 min Fred Knight, NetApp & WG co-chairs Issues that need attention from WG Last Call (to start in early July= ), if any Status of engagement of iSCSI implementers to review these drafts iSCSI MIB draft (if needed, status report under "Draft status" above may su= ffice) - 5 min iSER draft (draft-ietf-storm-iser-02) - 10 min Mike Ko, HuaweiSymantec (on behalf of draft authors) Summarize known topics & issues that need attention RDMA Protocol Extensions Draft (draft-ietf-storm-rdmap-ext-00) - 20 min Hemal Shah, Broadcom (on behalf of draft authors) NOTE: Despite its filename, this is not an official storm WG draft. Discussion of draft contents and rationale. Question: Should WG should adopt this draft as a work item. _______________________________________________ storm mailing list storm@ietf.org https://www.ietf.org/mailman/listinfo/storm -- Cheers, Arkady Kanevsky --_000_7C4DFCE962635144B8FAE8CA11D0BF1E0589392436MX14Acorpemcc_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Yes and WebEx –= ; I’ll pass along logistics when available.

 

Phone bridge ma= y be for presenters only – multicast will be available for those who = only want to listen (+ jabber for questions).

 

Thanks,
--David=

 

<= div>

From: arkady kanevsky [mailto:arkady.kanevs= ky@gmail.com]
Sent: Sunday, July 03, 2011 5:27 PM
To: = Black, David
Cc: storm@ietf.org
Subject: Re: [storm] Pr= eliminary Quebec City meeting agenda

 

David,
do you expect a phone bridge for the STORM session?=
Thanks,
Arkady

On Fri, Jul 1= , 2011 at 3:22 PM, <david.black@e= mc.com> wrote:

FYI, expect this t= o be slightly revised next week, Thanks, --David

-------------------= ----------------
IETF storm (STORage Maintenance) WG
Meeting agenda (= v1)
Tuesday, July 26, 2011, 1710-1810
Quebec City, QC, Canada
----= -------------------------------

Administrivia, agenda bashing, etc. = - 10 min
               David L.= Black, EMC & Tom Talpey, Microsoft (WG co-chairs)
    &nb= sp;  Blue sheets
       Note Well
  &nb= sp;    Milestones
       Note-taker
Draft status - 5 min
              &= nbsp;David L. Black, EMC (co-chair)
       iFCP upda= te and associated iFCP MIB update - Published as RFCs 6172 and 6173
&nbs= p;      MPA update - Publication Requested, AD is processing=
       iSCSI drafts (Consolidated, SAM and MIB)
=        iSER draft
       RDMA ex= tensions (not currently a WG draft)

iSCSI Drafts (draft-ietf-storm-i= scsi-cons-02, draft-ietf-storm-iscsi-sam-02) - 10 min
    &nbs= p;          Fred Knight, NetApp & WG co-chairs=
       Issues that need attention from WG Last Call= (to start in early July), if any
       Status of e= ngagement of iSCSI implementers to review these drafts

iSCSI MIB dra= ft (if needed, status report under "Draft status" above may suffi= ce) - 5 min

iSER draft (draft-ietf-storm-iser-02) - 10 min
 =              Mike Ko, HuaweiSymantec (o= n behalf of draft authors)
       Summarize known to= pics & issues that need attention

RDMA Protocol Extensions Draft= (draft-ietf-storm-rdmap-ext-00) - 20 min
        &n= bsp;      Hemal Shah, Broadcom (on behalf of draft authors)<= br>       NOTE: Despite its filename, this is not an of= ficial storm WG draft.

       Discussion of draf= t contents and rationale.
       Question: Should WG= should adopt this draft as a work item.

___________________________= ____________________
storm mailing list
storm@ietf.org
https://www.ietf.org/mailman/listinfo/storm




--
Chee= rs,
Arkady Kanevsky

= --_000_7C4DFCE962635144B8FAE8CA11D0BF1E0589392436MX14Acorpemcc_-- From david.black@emc.com Tue Jul 5 05:44:45 2011 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 440C121F86A9 for ; Tue, 5 Jul 2011 05:44:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -96.35 X-Spam-Level: X-Spam-Status: No, score=-96.35 tagged_above=-999 required=5 tests=[AWL=-10.250, BAYES_99=3.5, J_CHICKENPOX_23=0.6, J_CHICKENPOX_26=0.6, J_CHICKENPOX_27=0.6, J_CHICKENPOX_33=0.6, J_CHICKENPOX_35=0.6, J_CHICKENPOX_39=0.6, J_CHICKENPOX_43=0.6, J_CHICKENPOX_44=0.6, J_CHICKENPOX_45=0.6, J_CHICKENPOX_46=0.6, J_CHICKENPOX_47=0.6, J_CHICKENPOX_48=0.6, J_CHICKENPOX_54=0.6, J_CHICKENPOX_55=0.6, J_CHICKENPOX_56=0.6, J_CHICKENPOX_57=0.6, J_CHICKENPOX_62=0.6, J_CHICKENPOX_63=0.6, J_CHICKENPOX_64=0.6, J_CHICKENPOX_65=0.6, J_CHICKENPOX_66=0.6, J_CHICKENPOX_75=0.6, J_CHICKENPOX_82=0.6, J_CHICKENPOX_83=0.6, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2uUON-xZ4Kpn for ; Tue, 5 Jul 2011 05:44:44 -0700 (PDT) Received: from mexforward.lss.emc.com (mexforward.lss.emc.com [128.222.32.20]) by ietfa.amsl.com (Postfix) with ESMTP id 6B1D221F867E for ; Tue, 5 Jul 2011 05:44:44 -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 p65Cihwf016327 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Tue, 5 Jul 2011 08:44:43 -0400 Received: from mailhub.lss.emc.com (mailhubhoprd03.lss.emc.com [10.254.221.145]) by hop04-l1d11-si03.isus.emc.com (RSA Interceptor) for ; Tue, 5 Jul 2011 08:44:37 -0400 Received: from mxhub22.corp.emc.com (mxhub22.corp.emc.com [128.221.56.108]) by mailhub.lss.emc.com (Switch-3.4.3/Switch-3.4.3) with ESMTP id p65Ci4Im014366 for ; Tue, 5 Jul 2011 08:44:05 -0400 Received: from mx14a.corp.emc.com ([169.254.1.245]) by mxhub22.corp.emc.com ([128.221.56.108]) with mapi; Tue, 5 Jul 2011 08:44:04 -0400 From: To: Date: Tue, 5 Jul 2011 08:44:03 -0400 Thread-Topic: Nomcom 2011-2012: Third Call for Volunteers Thread-Index: Acw6Yg/hbT/igRpAQtCenU4mJGEpugArweQw Message-ID: <7C4DFCE962635144B8FAE8CA11D0BF1E0589392439@MX14A.corp.emc.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: multipart/mixed; boundary="_002_7C4DFCE962635144B8FAE8CA11D0BF1E0589392439MX14Acorpemcc_" MIME-Version: 1.0 X-EMM-MHVC: 1 Subject: [storm] FW: Nomcom 2011-2012: Third Call for Volunteers 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, 05 Jul 2011 12:44:45 -0000 --_002_7C4DFCE962635144B8FAE8CA11D0BF1E0589392439MX14Acorpemcc_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 Rm9yd2FyZGVkIGZvciB0aGUgTm9tY29tIGNoYWlyLg0KDQpUaGlzIGlzIHRoZSBUaGlyZCBjYWxs IGZvciBWb2x1bnRlZXJzIGZvciB0aGUgMjAxMS0xMiBOb21jb20uICBXZSBhcmUNCmFsbW9zdCB0 aHJvdWdoIHRoZSB2b2x1bnRlZXIgcGVyaW9kIHNvIGlmIHlvdSBhcmUgY29uc2lkZXJpbmcNCnZv bHVudGVlcmluZywgcGxlYXNlIGRvIHNvIHZlcnkgc29vbi4gDQoNCldlIGhhdmUgaGFkIGEgdmVy eSBnb29kIHJlc3BvbnNlIHRvIHRoZSBpbml0aWFsIGNhbGwgZm9yIHZvbHVudGVlcnMgYW5kDQpJ IGFtIHBsZWFzZWQgdG8gcmVwb3J0IHRoYXQgd2UgaGF2ZSA4NCB2b2x1bnRlZXJzIHRodXMgZmFy IHdob3NlDQpxdWFsaWZpY2F0aW9ucyBoYXZlIGJlZW4gY29uZmlybWVkIGJ5IHRoZSBzZWNyZXRh cmlhdC4gSSBoYXZlIG5vdGlmaWVkDQplYWNoIG9mIHRoZXNlIHZvbHVudGVlcnMgYnkgZW1haWwu ICANCg0KSG93ZXZlciwgd2Ugd291bGQgbGlrZSB0byBoYXZlIG1hbnkgbW9yZSB2b2x1bnRlZXJz LiBUaGUgbW9yZSB2b2x1bnRlZXJzLA0KdGhlIGJldHRlciBjaGFuY2Ugd2UgaGF2ZSBvZiBjaG9v c2luZyBhIHJhbmRvbSB5ZXQgcmVwcmVzZW50YXRpdmUgY3Jvc3MgDQpzZWN0aW9uIG9mIHRoZSBJ RVRGIHBvcHVsYXRpb24uIFlvdSBoYXZlIHVudGlsIDExOjU5IHBtIEVEVCBKdWx5IDEwLCAyMDEx IA0KdG8gdm9sdW50ZWVyIGZvciBOb21jb20gYnV0IGl0IHdvdWxkIGJlIG11Y2ggYmV0dGVyIGlm IHlvdSBjYW4gdm9sdW50ZWVyIA0KYXMgZWFybHkgYXMgcG9zc2libGUuIA0KDQpJZiB5b3Ugdm9s dW50ZWVyZWQgYmVmb3JlIDA5OjAwIEVEVCBvbiBKdW5lIDI5IHRvIHNlcnZlIGFzIGEgdm90aW5n IG1lbWJlcg0KYW5kIGhhdmUgbm90IHJlY2VpdmVkIGEgY29uZmlybWF0aW9uIGVtYWlsIGZyb20g bWUsIHBsZWFzZSByZS1zdWJtaXQgYW5kIA0KYnJpbmcgdG8gbXkgYXR0ZW50aW9uIHJpZ2h0IGF3 YXkhDQogICANCkRldGFpbHMgYWJvdXQgdGhlIHByb2Nlc3MgZm9yIHZvbHVudGVlcmluZyBmb3Ig dGhlIE5vbWNvbSBhbmQgdGhlIGxpc3QgDQpvZiBvcGVuIHBvc2l0aW9ucyBmb3Igd2hpY2ggdGhl IG5vbWluYXRpbmcgY29tbWl0dGVlIGlzIHJlc3BvbnNpYmxlIGFyZQ0Kc3VtbWFyaXplZCBpbiB0 aGUgaW5pdGlhbCBhbm5vdW5jZW1lbnQ6DQoNCmh0dHBzOi8vZGF0YXRyYWNrZXIuaWV0Zi5vcmcv YW5uL25vbWNvbS8yOTM4Lw0KDQpUaGUgODQgdm9sdW50ZWVycyB3aG8gaGF2ZSB0aHVzIGZhciBi ZWVuIHF1YWxpZmllZCBieSB0aGUgc2VjcmV0YXJpYXQNCmFyZToNCg0KQWxpYSBBdGxhcyxKdW5p cGVyIE5ldHdvcmtzDQpMaXhpYSBaaGFuZyxVQ0xBDQpXYXNzaW0gSGFkZGFkICxFcmljc3Nvbg0K R2xlbiBab3JuLE5ldHdvcmsgWmVuDQpSaWNoYXJkIEJhcm5lcyxCQk4gVGVjaG5vbG9naWVzDQpT dGVwaGVuIEtlbnQsQkJOIFRlY2hub2xvZ2llcw0KU2NvdHQgTWFuc2ZpZWxkLEVyaWNzc29uDQpU aW5hIFRTT1UgKFRpbmcgWk9VKSxGdXR1cmVXZWkgVGVjaG5vbG9naWVzDQpGZXJuYW5kbyBHb250 LFVUTi9GUkgNCkthcmVuIFNlbyxCQk4gVGVjaG5vbG9naWVzDQpKaWUgRG9uZyxIdWF3ZWkgVGVj aG5vbG9naWVzDQpNYWNoIENoZW4sSHVhd2VpIFRlY2hub2xvZ2llcyBDby4gTHRkLg0KU2hlbmcg SmlhbmcsSHVhd2VpIFRlY2hub2xvZ2llcyBDby4gTHRkLg0KRGltaXRyaSBQYXBhZGltaXRyaW91 LEFsY2F0ZWwtTHVjZW50DQpUaG9tYXMgRC4gTmFkZWF1LENBIFRlY2hub2xvZ2llcw0KRGF2aWQg TWV5ZXIsQ2lzY28gU3lzdGVtcy9Vbml2ZXJzaXR5IG9mIE9yZWdvbg0KV2VzbGV5IEdlb3JnZSxU aW1lIFdhcm5lciBDYWJsZQ0KQ3VsbGVuIEplbm5pbmdzLENpc2NvDQpTdGVwaGVuIEhhbm5hLEp1 bmlwZXIgTmV0d29ya3MNClN0ZXBoYW4gV2VuZ2VyLEJpZHlvIEluYy4NCktleXVyIFBhdGVsLENp c2NvIFN5c3RlbXMNCk1pY2hhZWwgKE1pa2UpIEhhbWlsdG9uLEJyZWFraW5nUG9pbnQgU3lzdGVt cw0KQmVoY2V0IFNhcmlrYXlhLEh1YXdlaSBVU0ENCk1hcmsgVG93bnNsZXksQ2lzY28gU3lzdGVt cw0KRnJlZCBCYWtlcixDaXNjbyBTeXN0ZW1zDQpCcmlhbiBUcmFtbWVsbCxFVEggWu+/vXJpY2gN ClNhbSBIYXJ0bWFuLFBhaW5sZXNzIFNlY3VyaXR5DQpDaHJpcyBHcmlmZml0aHMsQ29tY2FzdA0K R2VvcmdlIE1pY2hhZWxzb24sQVBOSUMNCkppYW5rYW5nIFlhbyxDTk5JQw0KU29oZWwgS2hhbixD b21jYXN0DQpEYWNoZW5nIFpoYW5nLEh1YXdlaQ0KTGlhbnNodSBaaGVuZyxIdWF3ZWkgVGVjaG5v bG9naWVzDQpIdWkgRGVuZyxDaGluYSBNb2JpbGUNCkdhbmcgQ2hlbixDaGluYSBNb2JpbGUNCk1p cmphIEvvv71obGV3aW5kLFVuaXZlcnNpdHkgb2YgU3R1dHRnYXJ0IElLUg0KSm9obiBFIERyYWtl LEp1bmlwZXIgTmV0d29ya3MNCk1hdHQgTGVwaW5za2ksQkJOIFRlY2hub2xvZ2llcw0KU3ViaXIg RGFzLFRlbGNvcmRpYSBUZWNobm9sb2dpZXMgSW5jDQpZaSBaaGFvLEh1YXdlaQ0KSm9obiBTY3Vk ZGVyLEp1bmlwZXIgTmV0d29ya3MNCkNocmlzdGVyIEhvbG1iZXJnLExNIEVyaWNzc29uDQpUZWVt dSBTYXZvbGFpbmVuLE5va2lhDQpTYW1pdGEgQ2hha3JhYmFydGksRXJpY3Nzb24NCkphYXAgQWtr ZXJodWlzLE5MbmV0IGxhYnMNCkphc29uIFdlaWwsVGltZSBXYXJuZXIgQ2FibGUNClJhbmR5IEJ1 c2gsSW50ZXJuZXQgSW5pdGlhdGl2ZSBKYXBhbg0KQ2hyaXN0aWFuIFNjaG1pZHQsTm9raWEgU2ll bWVucyBOZXR3b3Jrcw0KU2VhbiBTaGVuLENOTklDDQpMb3UgQmVyZ2VyLExhYk4gQ29uc3VsdGlu ZyBMLkwuQy4NCkRvbmFsZCBFYXN0bGFrZSxIdWF3ZWkNClhpYW9odSBYdSxIdWF3ZWkgVGVjaG5v bG9naWVzIGNvLiBMdGQuDQpC77+9cmplIE9obG1hbixFcmljc3Nvbg0KRGVib3JhaCBCcnVuZ2Fy ZCxBVCZUDQpNYWdudXMgV2VzdGVybHVuZCxFcmljc3Nvbg0KWmhlbiBDYW8sQ2hpbmEgTW9iaWxl DQpIYWRyaWVsIEthcGxhbixBY21lIFBhY2tldA0KTGlsbGEgRG92bmVyLEVyaWNzc29uDQpKb2hu IEphc29uIEJyem96b3dza2ksQ29tY2FzdA0KSm9ubmUgU29pbmluZW4sUmVuZXNhcyBNb2JpbGUN CkphdmllciBVYmlsbG9zLFN3ZWRpc2ggSW5zdGl0dXRlIG9mIENvbXB1dGVyIFNjaWVuY2UNCkVy aWMgR3JheSxFcmljc3Nvbg0KVGhvbWFzIEhlcmJzdCxTaWx2ZXIgU3ByaW5nIE5ldHdvcmtzDQpO aW5nIFpvbmcsSHVhd2VpIFRlY2hub2xvZ2llcw0KSGFpYmluIFNvbmcsSHVhd2VpIFRlY2hub2xv Z2llcw0KWWluZ2ppZSBHdSxIdWF3ZWkgVGVjaG5vbG9naWVzDQpIb25neXUgTGksSHVhd2VpIFRl Y2hub2xvZ2llcw0KVGVycnkgTWFuZGVyc29uLElDQU5ODQpBcmkgS2VyYW5lbixFcmljc3Nvbg0K Sm91bmkgS29yaG9uZW4sTm9raWEgU2llbWVucyBOZXR3b3Jrcw0KQmh1bWlwIEtoYXNuYWJpc2gs WlRFIFVTQSBJbmMuDQpEYXBlbmcgTGl1LENoaW5hIE1vYmlsZQ0KRmFuZ3dlaSBIdSxaVEUgQ29y cG9yYXRpb24NCk9sZSBUcm9hbixDaXNjbw0KUGFzY2FsIFRodWJlcnQsQ2lzY28NCldvamNpZWNo IERlYyxDaXNjbw0KR3VudGVyIFZhbiBkZSBWZWxkZSxDaXNjbw0KTmluZyBTbyxWZXJpem9uIElu Yy4vVW5pdmVyc2l0eSBvZiBUZXhhcyBhdCBEYWxsYXMNCkd1b21hbiBsaXUsWlRFDQpTaW1vbiBQ aWV0cm8gUm9tYW5vLE1lZXRlY2hvL1VuaXZlcnNpdHkgb2YgTmFwb2xpDQpMdWNhIE1hcnRpbmks Q2lzY28NCkJpbGwgVmVyU3RlZWcsQ2lzY28NClRvZXJsZXNzIEVja2VydCxDaXNjbyBTeXN0ZW1z DQpKb3NlcGggU2Fsb3dleSxDaXNjbyBTeXN0ZW1zDQoNClRoZSBwcmltYXJ5IGFjdGl2aXR5IGZv ciB0aGlzIG5vbWNvbSB3aWxsIGJlZ2luIGR1cmluZyBJRVRGLTgxIGluDQpRdWViZWMgQ2l0eSBh bmQgc2hvdWxkIGJlIGNvbXBsZXRlZCBieSBKYW51YXJ5IDIwMTIuIFRoZSBub21jb20gd2lsbA0K YmUgY29sbGVjdGluZyByZXF1aXJlbWVudHMgZnJvbSB0aGUgY29tbXVuaXR5LCBhcyB3ZWxsIGFz IHRhbGtpbmcgdG8NCmNhbmRpZGF0ZXMgYW5kIHRvIGNvbW11bml0eSBtZW1iZXJzIGFib3V0IGNh bmRpZGF0ZXMuIFRoZXJlIHdpbGwgYmUNCnJlZ3VsYXJseSBzY2hlZHVsZWQgY29uZmVyZW5jZSBj YWxscyB0byBlbnN1cmUgcHJvZ3Jlc3MuIFRodXMsIGJlaW5nIGENCm5vbWNvbSBtZW1iZXIgZG9l cyByZXF1aXJlIHNvbWUgdGltZSBjb21taXRtZW50Lg0KIA0KUGxlYXNlIHZvbHVudGVlciBieSBz ZW5kaW5nIGFuIGVtYWlsIHRvIG1lIGJlZm9yZSANCjExOjU5IHBtIEVEVCBKdWx5IDEwLCAyMDEx IGFzIGZvbGxvd3M6DQoNClRvOiBzdXJlc2gua3Jpc2huYW5AZXJpY3Nzb24uY29tDQpTdWJqZWN0 OiBOb21jb20gMjAxMS0xMiBWb2x1bnRlZXINCg0KUGxlYXNlIGluY2x1ZGUgdGhlIGZvbGxvd2lu ZyBpbmZvcm1hdGlvbiBpbiB0aGUgYm9keSBvZiB0aGUgbWFpbDoNCg0KRnVsbCBOYW1lOiAgLy8g QXMgeW91IGVudGVyIGluIHRoZSBJRVRGIFJlZ2lzdHJhdGlvbiBGb3JtLA0KICAgICAgICAgICAg Ly8gRmlyc3QvR2l2ZW4gbmFtZSBmb2xsb3dlZCBieSBMYXN0L0ZhbWlseSBOYW1lDQoNCkN1cnJl bnQgUHJpbWFyeSBBZmZpbGlhdGlvbjogLy8gdHlwaWNhbGx5IHdoYXQgZ29lcyBpbiB0aGUgQ29t cGFueSANCiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgLy8gZmllbGQgaW4gdGhlIElFVEYg UmVnaXN0cmF0aW9uIEZvcm0NCg0KRW1haWwgQWRkcmVzcyhlcyk6IC8vIGFsbCBlbWFpbCBhZGRy ZXNzZXMgdXNlZCB0byBSZWdpc3RlciBmb3IgdGhlIA0KICAgICAgICAgICAgICAgICAgIC8vIHBh c3QgNSBJRVRGIG1lZXRpbmdzDQoJCSAgIC8vIFBsZWFzZSBkZXNpZ25hdGUgYSBQcmVmZXJyZWQg ZW1haWwgYWRkcmVzcyBmb3INCiAgICAgICAgICAgICAgICAgICAvLyBjb250YWN0IGlmIHRoZXJl IGlzIG1vcmUgdGhhbiBvbmUgZW1haWwgYWRkcmVzcw0KDQpUZWxlcGhvbmUgbnVtYmVyOiAgLy8g V2l0aCBjb3VudHJ5IGNvZGUgKGZvciBjb25maXJtYXRpb24gaWYgc2VsZWN0ZWQpDQoNClBsZWFz ZSBleHBlY3QgYW4gZW1haWwgcmVzcG9uc2UgZnJvbSBtZSB3aXRoaW4gMyBidXNpbmVzcyBkYXlz IHN0YXRpbmcNCndoZXRoZXIgb3Igbm90IHlvdSBhcmUgcXVhbGlmaWVkLiAgSWYgeW91IGRvIG5v dCByZWNlaXZlIGEgcmVzcG9uc2UgaW4NCnRoaXMgdGltZWZyYW1lLCBwbGVhc2UgcmUtc2VuZCB5 b3VyIGVtYWlsIHdpdGggdGhlIHRhZyAiUkVTRU5EOiIgYWRkZWQNCnRvIHRoZSBzdWJqZWN0IGxp bmUuDQoNCklmIHlvdSBhcmUgbm90IHlldCBzdXJlIHlvdSB3b3VsZCBsaWtlIHRvIHZvbHVudGVl ciwgcGxlYXNlIGNvbnNpZGVyDQp0aGF0IE5vbWNvbSBtZW1iZXJzIHBsYXkgYSB2ZXJ5IGltcG9y dGFudCByb2xlIGluIHNoYXBpbmcgdGhlDQpsZWFkZXJzaGlwIG9mIHRoZSBJRVRGLiAgRW5zdXJp bmcgdGhlIGxlYWRlcnNoaXAgb2YgdGhlIElFVEYgaXMgZmFpcg0KYW5kIGJhbGFuY2VkIGFuZCBj b21wcmlzZWQgb2YgdGhvc2Ugd2hvIGNhbiBsZWFkIHRoZSBJRVRGIGluIHRoZSByaWdodA0KZGly ZWN0aW9uIGlzIGFuIGltcG9ydGFudCByZXNwb25zaWJpbGl0eSB0aGF0IHJlc3RzIG9uIHRoZSBJ RVRGDQpwYXJ0aWNpcGFudHMgYXQgbGFyZ2UuIFZvbHVudGVlcmluZyBmb3IgdGhlIE5vbWNvbSBp cyBhIGdvb2Qgd2F5IG9mDQpjb250cmlidXRpbmcgaW4gdGhhdCBkaXJlY3Rpb24uDQoNCkkgd2ls bCBiZSBwdWJsaXNoaW5nIGEgbW9yZSBkZXRhaWxlZCB0YXJnZXQgdGltZXRhYmxlLCBhcyB3ZWxs IGFzDQpkZXRhaWxzIG9mIHRoZSByYW5kb21uZXNzIHNlZWRzIHRvIGJlIHVzZWQgZm9yIHRoZSBS RkMgMzc5NyBzZWxlY3Rpb24NCnByb2Nlc3MgdmVyeSBzb29uLg0KDQpUaGFuayB5b3UgaW4gYWR2 YW5jZSBmb3IgeW91ciBwYXJ0aWNpcGF0aW9uLg0KDQpTdXJlc2ggS3Jpc2huYW4NCk5vbWNvbSBD aGFpciAyMDExLTIwMTINCkVtYWlsOiBub21jb20tY2hhaXJAaWV0Zi5vcmcsIHN1cmVzaC5rcmlz aG5hbkBlcmljc3Nvbi5jb20NCg== --_002_7C4DFCE962635144B8FAE8CA11D0BF1E0589392439MX14Acorpemcc_ Content-Type: text/plain; name="ATT00001..txt" Content-Description: ATT00001..txt Content-Disposition: attachment; filename="ATT00001..txt"; size=154; creation-date="Mon, 04 Jul 2011 11:50:13 GMT"; modification-date="Mon, 04 Jul 2011 11:50:13 GMT" Content-Transfer-Encoding: base64 X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCklFVEYtQW5u b3VuY2UgbWFpbGluZyBsaXN0DQpJRVRGLUFubm91bmNlQGlldGYub3JnDQpodHRwczovL3d3dy5p ZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL2lldGYtYW5ub3VuY2UNCg== --_002_7C4DFCE962635144B8FAE8CA11D0BF1E0589392439MX14Acorpemcc_-- From mbakke@cisco.com Tue Jul 5 10:54:11 2011 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 C5D1321F88EF for ; Tue, 5 Jul 2011 10:54:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[AWL=4.000, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id trB2P2aEGfcO for ; Tue, 5 Jul 2011 10:54:10 -0700 (PDT) Received: from sj-iport-4.cisco.com (sj-iport-4.cisco.com [171.68.10.86]) by ietfa.amsl.com (Postfix) with ESMTP id BB9E721F88C1 for ; Tue, 5 Jul 2011 10:54:10 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=mbakke@cisco.com; l=8568; q=dns/txt; s=iport; t=1309888450; x=1311098050; h=mime-version:content-transfer-encoding:subject:date: message-id:in-reply-to:references:from:to; bh=LCQdlz9VKhVnluYu0hds/EAPYICc9cM/mhzg3TZ4QOk=; b=lFTkofWKLqqx1uimZtDG6l5ZzytbUmZ2QyuKGnjdK7VafamyxXp2KfSO FDbOlM5AcZoNnTQviBN2xap94+1WiaacFKGAoG7PbV/mLGlUwn7mdLsE4 nrNUxnLLEAps0fInsfuK30ouRrKCa5+3T80MLxlCoP+vSLCEyb3edCF9C k=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AvIAAFhPE06rRDoI/2dsb2JhbABNBhCYQY84d604nXaCP3yCewSHP494in5V X-IronPort-AV: E=Sophos;i="4.65,480,1304294400"; d="scan'208";a="290486815" Received: from mtv-core-3.cisco.com ([171.68.58.8]) by sj-iport-4.cisco.com with ESMTP; 05 Jul 2011 17:53:04 +0000 Received: from xbh-rcd-201.cisco.com (xbh-rcd-201.cisco.com [72.163.62.200]) by mtv-core-3.cisco.com (8.14.3/8.14.3) with ESMTP id p65Hr4iu013846; Tue, 5 Jul 2011 17:53:04 GMT Received: from xmb-rcd-105.cisco.com ([72.163.62.147]) by xbh-rcd-201.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Tue, 5 Jul 2011 12:53:04 -0500 X-Mimeole: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Date: Tue, 5 Jul 2011 12:53:02 -0500 Message-ID: <97CC2D4896BE5D48825529CE9A16882505F688E1@XMB-RCD-105.cisco.com> In-Reply-To: <7C4DFCE962635144B8FAE8CA11D0BF1E0589392435@MX14A.corp.emc.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [storm] Consolidated iSCSI draft and TaskReporting Thread-Index: AQDeOsqbPwyi4a8ddBcbQxUWgjUBFQKxRZHdAgOPlpyWjMTOgIAFGOsggAImkaCAAFgpsA== References: <1308321497.3882.10.camel@chiron.ofa><7C4DFCE962635144B8FAE8CA11D0BF1E0589310372@MX14A.corp.emc.com> <97CC2D4896BE5D48825529CE9A16882505E23845@XMB-RCD-105.cisco.com> <7C4DFCE962635144B8FAE8CA11D0BF1E0589392435@MX14A.corp.emc.com> From: "Mark Bakke (mbakke)" To: , , , X-OriginalArrivalTime: 05 Jul 2011 17:53:04.0115 (UTC) FILETIME=[638CCC30:01CC3B3C] Subject: Re: [storm] Consolidated iSCSI draft and TaskReporting 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, 05 Jul 2011 17:54:11 -0000 Great; thanks, David. Mark -----Original Message----- From: david.black@emc.com [mailto:david.black@emc.com]=20 Sent: Tuesday, July 05, 2011 7:39 AM To: Mark Bakke (mbakke); cbm@chadalapaka.com; pmacarth@iol.unh.edu; = storm@ietf.org Subject: RE: [storm] Consolidated iSCSI draft and TaskReporting Mark, That will suffice for now. The next version of the SAM draft will = create an IANA registry for these values; I would reference the SAM = draft for the definition of iSCSIProtocolLevel (as you've done) plus the = registry for the values. Thanks, --David > -----Original Message----- > From: Mark Bakke (mbakke) [mailto:mbakke@cisco.com] > Sent: Sunday, July 03, 2011 11:51 PM > To: Mallikarjun Chadalapaka; Black, David; pmacarth@iol.unh.edu; = storm@ietf.org > Subject: RE: [storm] Consolidated iSCSI draft and TaskReporting >=20 > Mallikarjun and David, >=20 > In the iSCSI MIB (draft-00 will be posted by tomorrow morning PST), we = have added iSCSIProtocolLevel > to the Session attributes: >=20 > iscsiSsnProtocolLevel OBJECT-TYPE > SYNTAX Unsigned32 (1..65535) > MAX-ACCESS read-only > STATUS current > DESCRIPTION > "The iSCSI protocol level negotiated for this session." > REFERENCE > "[iSCSI-SAM], Section 7.1.1, iSCSIProtocolLevel" > DEFVAL { 1 } > ::=3D { iscsiSessionAttributesEntry 22 } >=20 > Instead of describing what the numbers mean as below, we are just = referencing the SAM draft. Is that > the right thing, or is there more description we should be adding? >=20 > I'm fine with just referencing another spec, since that means we won't = have to respin the MIB if > another protocol level is added. >=20 > Thanks, >=20 > Mark >=20 >=20 > -----Original Message----- > From: storm-bounces@ietf.org [mailto:storm-bounces@ietf.org] On Behalf = Of Mallikarjun Chadalapaka > Sent: Thursday, June 30, 2011 5:07 PM > To: david.black@emc.com; pmacarth@iol.unh.edu; storm@ietf.org > Subject: Re: [storm] Consolidated iSCSI draft and TaskReporting >=20 > I'm OK with leaving out the phrase you point out - I meant it to cover = the > case of an acceptor in a key negotiation. But I see your point. >=20 > I was thinking along the lines of each spec "claiming" a number for = the > iSCSIProtocolLevel key, so no one spec necessarily has a table of all = the > keys. Currently, Consolidated draft claims "1", and SAM draft claims = "2". > Sounds like you're thinking a table with currently claimed > iSCSIProtocolLevel values in this spec? I am fine with that too. >=20 > Thanks. >=20 > Mallikarjun >=20 >=20 > -----Original Message----- > From: david.black@emc.com [mailto:david.black@emc.com] > Sent: Thursday, June 30, 2011 1:31 PM > To: cbm@chadalapaka.com; pmacarth@iol.unh.edu; storm@ietf.org > Subject: RE: [storm] Consolidated iSCSI draft and TaskReporting >=20 > >=20 > We should do what Mallikarjun proposes. A table will be needed that = lists > the RFCs for each value of the iSCSIProtocolLevel key. >=20 > One change - "(or would have offered)" should be removed from > Mallikarjun's proposed text. Hypothetical requirements tend to be > difficult > to test and moreover are usually pointless - the values that are = actually > used in negotiation are what should govern protocol behavior. >=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-7786 > david.black@emc.com=A0=A0=A0=A0=A0=A0=A0 Mobile: +1 (978) 394-7754 > ---------------------------------------------------- >=20 > > -----Original Message----- > > From: storm-bounces@ietf.org [mailto:storm-bounces@ietf.org] On > Behalf > > Of Mallikarjun Chadalapaka > > Sent: Friday, June 17, 2011 8:24 PM > > To: 'Patrick MacArthur'; storm@ietf.org > > Subject: Re: [storm] Consolidated iSCSI draft and TaskReporting > > > > Hi Patrick, > > > > I tend to agree with you, you raise a valid point. > > > > The problem lies in special-casing RFC 3720. I think the right = way to > > address your comment is to require that an implementation's > "NotUnderstood" > > response should correlate to the highest protocol version that it = has > > offered (or would have offered) for the iSCSIProtocolLevel key in = a > > negotiation. E.g., let's say if an iSCSI implementation has = *offered* > a > > value of 2 in a negotiation (even though the other side has = negotiated > > it down to 1), it means that the offering implementation can > > comprehend all text keys defined through the spec with > > iSCSIProtocolLevel=3D2. So it must not respond to any of those = text keys > with a "NotUnderstood". > > > > So the formal verbiage would look something like the following: > > > > An iSCSI implementation MUST comprehend all text keys defined in = iSCSI > > Protocol specifications from [RFC3720] through the RFC keyed to = the > > highest protocol version that the implementation has offered (or = would > > have offered) for the iSCSIProtocolLevel key in a negotiation. > > Returning a NotUnderstood response on any of these text keys = therefore > > MUST be considered a protocol error and handled accordingly. For = all > > other "later" keys, i.e. text keys defined in specifications keyed = to > > higher values of iSCSIProtocolLevel, a NotUnderstood answer = concludes > > the negotiation for a negotiated key whereas for a declarative = key, a > > NotUnderstood answer simply informs the declarer of a lack of > comprehension by the receiver. > > > > Please let me know if you have comments or questions. Thanks. > > > > Mallikarjun > > > > > > > > -----Original Message----- > > From: storm-bounces@ietf.org [mailto:storm-bounces@ietf.org] On > Behalf > > Of Patrick MacArthur > > Sent: Friday, June 17, 2011 7:38 AM > > To: storm@ietf.org > > Subject: [storm] Consolidated iSCSI draft and TaskReporting > > > > Hi, > > > > I wanted to ask for clarification on an item appearing in the > consolidated > > iSCSI draft. > > > > "All keys defined in [RFC3720] MUST be supported by all > > compliant implementations; a NotUnderstood answer on any of = the > > [RFC3720] keys therefore MUST be considered a protocol error = and > > handled accordingly. For all other later keys, a = NotUnderstood > > answer concludes the negotiation for a negotiated key = whereas for > > a declarative key, a NotUnderstood answer simply informs the > > declarer of a lack of comprehension by the receiver." > > > > I would like to request that the references to RFC3720 above be > changed > to > > RFC3720 and RFC5048. The comments on this list seem to indicate = that > the > > baseline for the iSCSI work is on the combination of RFC 3720 = and RFC > > 5048, which I interpret to mean that it would be applicable only = to > > implementations compliant with both RFCs. An implementation = that > > claims to be RFC 5048-compliant and responds with > > TaskReporting=3DNotUnderstood is broken IMHO. In that case, is = there a > > reason that we allow a NotUnderstood response on an RFC 5048 key > > (TaskReporting)? > > > > If the STORM WG is trying to ensure compatibility with the > requirements > of > > RFC 3720 and RFC 5048 combined, it seems strange to be allowing > > implementers not to implement the key requirement of RFC 5048. > > > > Thanks, > > > > -- > > Patrick MacArthur > > Research and Development > > iSCSI/OFA/IPv6 Consortia > > UNH InterOperability Laboratory > > > > _______________________________________________ > > storm mailing list > > storm@ietf.org > > https://www.ietf.org/mailman/listinfo/storm > > > > _______________________________________________ > > storm mailing list > > storm@ietf.org > > https://www.ietf.org/mailman/listinfo/storm >=20 >=20 > _______________________________________________ > storm mailing list > storm@ietf.org > https://www.ietf.org/mailman/listinfo/storm From BMT@zurich.ibm.com Tue Jul 5 15:49:13 2011 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 DF87921F88EC for ; Tue, 5 Jul 2011 15:49:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.489 X-Spam-Level: X-Spam-Status: No, score=-5.489 tagged_above=-999 required=5 tests=[AWL=1.110, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pSrcbYsSEYbo for ; Tue, 5 Jul 2011 15:49:13 -0700 (PDT) Received: from mtagate2.uk.ibm.com (mtagate2.uk.ibm.com [194.196.100.162]) by ietfa.amsl.com (Postfix) with ESMTP id E32D521F88EB for ; Tue, 5 Jul 2011 15:49:12 -0700 (PDT) Received: from d06nrmr1707.portsmouth.uk.ibm.com (d06nrmr1707.portsmouth.uk.ibm.com [9.149.39.225]) by mtagate2.uk.ibm.com (8.13.1/8.13.1) with ESMTP id p65MnBei008269 for ; Tue, 5 Jul 2011 22:49:11 GMT Received: from d06av08.portsmouth.uk.ibm.com (d06av08.portsmouth.uk.ibm.com [9.149.37.249]) by d06nrmr1707.portsmouth.uk.ibm.com (8.13.8/8.13.8/NCO v10.0) with ESMTP id p65Mn4ho1974508 for ; Tue, 5 Jul 2011 23:49:11 +0100 Received: from d06av08.portsmouth.uk.ibm.com (loopback [127.0.0.1]) by d06av08.portsmouth.uk.ibm.com (8.14.4/8.13.1/NCO v10.0 AVout) with ESMTP id p65Mn3MU010452 for ; Tue, 5 Jul 2011 23:49:04 +0100 Received: from d12mc302.megacenter.de.ibm.com (d12mc302.megacenter.de.ibm.com [9.149.170.82]) by d06av08.portsmouth.uk.ibm.com (8.14.4/8.13.1/NCO v10.0 AVin) with ESMTP id p65Mn3gm010449; Tue, 5 Jul 2011 23:49:03 +0100 To: storm@ietf.org MIME-Version: 1.0 X-KeepSent: 68B8817A:D6C70115-C12578C4:0052797F; type=4; name=$KeepSent X-Mailer: Lotus Notes Release 8.5.1 September 28, 2009 Message-ID: From: Bernard Metzler Date: Wed, 6 Jul 2011 00:49:03 +0200 X-MIMETrack: Serialize by Router on D12MC302/12/M/IBM(Release 8.5.2FP1HF342 | May 5, 2011) at 06/07/2011 00:49:03, Serialize complete at 06/07/2011 00:49:03 Content-Type: text/plain; charset="US-ASCII" Subject: [storm] more comments on http://tools.ietf.org/html/draft-ietf-storm-rdmap-ext-00 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, 05 Jul 2011 22:49:14 -0000 Some comments on the RDMA Protocol Extension draft (sorry when partially overlapping with Arkady's email from 3 May). The terms "Data Source" and "Data Sink" are used for Immediate Data and Atomic Operations as well. For Atomics I found it confusing and would prefer to have the 'Requester' and 'Responder' terms used throughout the whole document. Immediate Data The specification introduces a new RDMAP message format. Section 1 and 6 are limiting its usage to Writes, eg.: "Immediate Data messages allow the ULP at the sender to provide a small amount of data following an RDMA Write payload." Why not Sends, while SendWithImm is defined for other RDMA transports and is part of a well established RDMA verbs interface (OpenFabrics)? While potentially out of the primary business of the specification of a wire protocol - I assume Immediate Data will consume a peers Receive Queue Element? A short discussion including appropriate RQ sizing might be helpful for the reader (and implementer). It might go into section 6.1. Atomics 5.1.1: I found it difficult to understand the FetchAdd decription. In particular, the statement of "The setting of "Add Mask" field to 0x0000000000000000 results in Atomic Add of 64-bit Original Remote Data Value and 64-bit "Add Data"." was surprising to me. I would have expected all bits set to 1. FetchAdd sometimes extends to FetchAndAdd. I would prefer one term only. The abbreviation of RMW seem to refer to ReadModifyWrite. Better to be written in full length? It could be confused with RemoteMemoryWindow. Ordering and Completion Table Section 7 provides a table of operation ordering. For Immediate Data, I found the term "Placement" inappropriate. Immediate Data are not placed in a target buffer. Immediate Data are received and delivered to the ULP. Maybe exchanging "Immediate Data is Placed at Remote Peer" with "Immediate Data is received at Remote Peer" would clarify? I see the same issue for Atomic Responses, which are also not Placed but received. The discussion of the two consecutive Atomic operations (page 22) seem to allow re-ordering of Atomic responses. Is that true? It might complicate response processing. General/Implementation It might be a good idea to try an implementation of the proposed RDMAP extension. The SoftiWARP stack might be a good candidate for that. Thanks, Bernard. From hemal@broadcom.com Fri Jul 8 14:41:14 2011 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 D889321F8C0D for ; Fri, 8 Jul 2011 14:41:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lNm0Uxp-CkPI for ; Fri, 8 Jul 2011 14:41:14 -0700 (PDT) Received: from mms1.broadcom.com (mms1.broadcom.com [216.31.210.17]) by ietfa.amsl.com (Postfix) with ESMTP id 1546821F8C0C for ; Fri, 8 Jul 2011 14:41:14 -0700 (PDT) Received: from [10.9.200.133] by mms1.broadcom.com with ESMTP (Broadcom SMTP Relay (Email Firewall v6.3.2)); Fri, 08 Jul 2011 14:46:08 -0700 X-Server-Uuid: 02CED230-5797-4B57-9875-D5D2FEE4708A Received: from IRVEXCHCCR02.corp.ad.broadcom.com ([10.9.200.183]) by IRVEXCHHUB02.corp.ad.broadcom.com ([10.9.200.133]) with mapi; Fri, 8 Jul 2011 14:40:50 -0700 From: "Hemal Shah" To: "Bernard Metzler" , "storm@ietf.org" Date: Fri, 8 Jul 2011 14:39:51 -0700 Thread-Topic: [storm] more comments on http://tools.ietf.org/html/draft-ietf-storm-rdmap-ext-00 Thread-Index: Acw7ZebW2MkusTSzQHOtcGFcP3CoYwCOQCpw Message-ID: <76DBE161893C324BA6D4BB507EE4C3849513514FC9@IRVEXCHCCR02.corp.ad.broadcom.com> References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US MIME-Version: 1.0 X-WSS-ID: 6209A52A3B416905848-01-01 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Subject: Re: [storm] more comments on http://tools.ietf.org/html/draft-ietf-storm-rdmap-ext-00 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, 08 Jul 2011 21:41:15 -0000 Bernard, Thanks for the comments! We will incorporate them in our next rev of the dr= aft! Below are the responses to your comments! Hemal -----Original Message----- From: storm-bounces@ietf.org [mailto:storm-bounces@ietf.org] On Behalf Of B= ernard Metzler Sent: Tuesday, July 05, 2011 3:49 PM To: storm@ietf.org Subject: [storm] more comments on http://tools.ietf.org/html/draft-ietf-sto= rm-rdmap-ext-00 Some comments on the RDMA Protocol Extension draft (sorry when partially overlapping with Arkady's email from 3 May). The terms "Data Source" and "Data Sink" are used for Immediate Data and Atomic Operations as well. For Atomics I found it confusing and would prefer to have the 'Requester' and 'Responder' terms used throughout the whole document. [Hemal] Good comment! For Atomics, we will make sure that we use terms "Req= uester" and "Responder" instead of "Data Source" and "Data Sink".=20 Immediate Data The specification introduces a new RDMAP message format. Section 1 and 6 are limiting its usage to Writes, eg.: "Immediate Data messages allow the ULP at the sender to provide a small amount of data following an RDMA Write payload." Why not Sends, while SendWithImm is defined for other RDMA transports and is part of a well established RDMA verbs interface (OpenFabrics)? [Hemal] Good point! The primary intent for ImmData was to use it with the R= DMA Write. That being said, we can change the wording in Section 1 and 6 to= allow the Immediate data's usage with any other RDMA message. But, in real= ity the verbs definition will not allow it to be used with Send Operations = (as it will consume two RQ entries which is as good as sending two Send Mes= sages). While potentially out of the primary business of the specification of a wire protocol - I assume Immediate Data will consume a peers Receive Queue Element?[Hemal] Yes A short discussion including appropriate RQ sizing might be helpful for the reader (and implementer). It might go into section 6.1.[Hemal] This is a protocol specification. RQ sizing is ou= tside the scope of this specification. That being said, Section 6.3 talks a= bout ImmData consuming one Untagged Buffer. I think that text is sufficient= .=20 Atomics 5.1.1: I found it difficult to understand the FetchAdd decription. In particular, the statement of "The setting of "Add Mask" field to 0x0000000000000000 results in Atomic Add of 64-bit Original Remote Data Value and 64-bit "Add Data"." was surprising to me. I would have expected all bits set to 1. [Hemal] The "Add Mask" is used to exclude the bits from the operation rathe= r than include the bits for the operations. The pseudo-code described in th= e spec reflects that. FetchAdd sometimes extends to FetchAndAdd. I would prefer one term only. [Hemal] Good catch! We will use FetchAdd consistently in the doc and remove= FetchAndAdd occurrences. The abbreviation of RMW seem to refer to ReadModifyWrite. Better to be written in full length? It could be confused with RemoteMemoryWindow. [Hemal] OK! We will spell out ReadModifyWrite. Ordering and Completion Table Section 7 provides a table of operation ordering. For Immediate Data, I found the term "Placement" inappropriate. Immediate Data are not placed in a target buffer. Immediate Data are received and delivered to the ULP. Maybe exchanging "Immediate Data is Placed at Remote Peer" with "Immediate Data is received at Remote Peer" would clarify? I see the same issue for Atomic Responses, which are also not Placed but received. [Hemal] We would like to follow DDP layer term "Placement" here and be cons= istent with the RDMAP spec. So, we will keep the Section 7 text as it is. The discussion of the two consecutive Atomic operations (page 22) seem to allow re-ordering of Atomic responses. Is that true? It might complicate response processing.=20 [Hemal] Re-ordering is allowed only from the Placement perspective. The ge= neration of Response Messages is still done in order. So, I do not think it= complicates the response processing. General/Implementation It might be a good idea to try an implementation of the proposed RDMAP extension. The SoftiWARP stack might be a good candidate for that. [Hemal] Agree! Thanks, Bernard. _______________________________________________ storm mailing list storm@ietf.org https://www.ietf.org/mailman/listinfo/storm From Internet-Drafts@ietf.org Fri Jul 8 14:45:02 2011 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 E97D221F8AF9; Fri, 8 Jul 2011 14:45:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.583 X-Spam-Level: X-Spam-Status: No, score=-102.583 tagged_above=-999 required=5 tests=[AWL=0.016, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Qq9Wjl9N1mt9; Fri, 8 Jul 2011 14:45:02 -0700 (PDT) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 47C7521F8AE5; Fri, 8 Jul 2011 14:45:02 -0700 (PDT) MIME-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" From: Internet-Drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 3.55 Message-ID: <20110708214502.4349.32886.idtracker@ietfa.amsl.com> Date: Fri, 08 Jul 2011 14:45:02 -0700 Cc: storm@ietf.org Subject: [storm] I-D ACTION:draft-ietf-storm-iscsi-cons-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: Fri, 08 Jul 2011 21:45:03 -0000 --NextPart 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 the IETF. Title : iSCSI Protocol (Consolidated) Author(s) : M. Chadalapaka, et al Filename : draft-ietf-storm-iscsi-cons-03.txt Pages : 340 Date : 2011-07-08 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). 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 consolidates RFCs 3720, 3980, 4850 and 5048 into a single document and makes additional updates to the consolidated specification. This document also updates RFC 3721. The text in this document thus supersedes the text in RFCs 3720, 3721, 3980, 4850 and 5048 whenever there is such a question. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-storm-iscsi-cons-03.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Message/External-body; name="draft-ietf-storm-iscsi-cons-03.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2011-07-08143206.I-D@ietf.org> --NextPart-- From internet-drafts@ietf.org Fri Jul 8 15:35:12 2011 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 1306421F8CA8; Fri, 8 Jul 2011 15:35:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.583 X-Spam-Level: X-Spam-Status: No, score=-102.583 tagged_above=-999 required=5 tests=[AWL=0.016, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fQzd13Nm+yPF; Fri, 8 Jul 2011 15:35:11 -0700 (PDT) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6E54721F8C92; Fri, 8 Jul 2011 15:35:11 -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: 3.55 Message-ID: <20110708223511.18751.91176.idtracker@ietfa.amsl.com> Date: Fri, 08 Jul 2011 15:35:11 -0700 Cc: storm@ietf.org Subject: [storm] I-D Action: draft-ietf-storm-mpa-peer-connect-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: Fri, 08 Jul 2011 22:35:12 -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 : Enhanced RDMA Connection Establishment Author(s) : Arkady Kanevsky Caitlin Bestler Robert Sharp Steve Wise Filename : draft-ietf-storm-mpa-peer-connect-06.txt Pages : 20 Date : 2011-07-08 This document updates RFC5043 and RFC5044 by extending MPA negotiation for RDMA connection establishment. The first enhancement extends RFC5043, enabling peer-to-peer connection establishment over MPA/TCP. The second enhancement extends both RFC5043 and RFC5044, by providing an option for standardized exchange of RDMA-layer connection configuration. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-storm-mpa-peer-connect-06.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ This Internet-Draft can be retrieved at: ftp://ftp.ietf.org/internet-drafts/draft-ietf-storm-mpa-peer-connect-06.txt From internet-drafts@ietf.org Mon Jul 11 12:14:28 2011 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 EEF6D21F8D2D; Mon, 11 Jul 2011 12:14:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.589 X-Spam-Level: X-Spam-Status: No, score=-102.589 tagged_above=-999 required=5 tests=[AWL=0.010, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kc7wwBmTwCml; Mon, 11 Jul 2011 12:14:28 -0700 (PDT) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 01BBE11E8160; Mon, 11 Jul 2011 12:14:28 -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: 3.55 Message-ID: <20110711191428.15124.23157.idtracker@ietfa.amsl.com> Date: Mon, 11 Jul 2011 12:14:28 -0700 Cc: storm@ietf.org Subject: [storm] I-D Action: draft-ietf-storm-iscsi-sam-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: Mon, 11 Jul 2011 19:14:29 -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) SAM Author(s) : Frederick Knight Mallikarjun Chadalapaka Filename : draft-ietf-storm-iscsi-sam-03.txt Pages : 1 Date : 2011-07-11 Internet Small Computer Systems Interface (iSCSI) is a SCSI transport protocol that maps the SCSI family of protocols onto TCP/IP. RFC 3720 defines the iSCSI protocol. The current iSCSI protocol (RFC 3720 and RFC 5048) is based on the SAM-2 version of the SCSI family of protocols). This document defines additions and changes to the iSCSI protocol to enabled additional features that were added to the SCSI family of protocols through SAM-3, SAM-4, and SAM-5. This document updates RFC 3720 and RFC 5048 and the text in this document supersedes the text in RFC 3720 and RFC 5048 when the two differ. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-storm-iscsi-sam-03.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ This Internet-Draft can be retrieved at: ftp://ftp.ietf.org/internet-drafts/draft-ietf-storm-iscsi-sam-03.txt From internet-drafts@ietf.org Mon Jul 11 13:16:45 2011 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 C71B521F8F42; Mon, 11 Jul 2011 13:16:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.589 X-Spam-Level: X-Spam-Status: No, score=-102.589 tagged_above=-999 required=5 tests=[AWL=0.010, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NKeN2yXb43xh; Mon, 11 Jul 2011 13:16:45 -0700 (PDT) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5E4CB21F8EF5; Mon, 11 Jul 2011 13:16:45 -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: 3.55 Message-ID: <20110711201645.11642.41672.idtracker@ietfa.amsl.com> Date: Mon, 11 Jul 2011 13:16:45 -0700 Cc: storm@ietf.org Subject: [storm] I-D Action: draft-ietf-storm-rdmap-ext-01.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, 11 Jul 2011 20:16:46 -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-01.txt Pages : 30 Date : 2011-07-11 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. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-storm-rdmap-ext-01.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ This Internet-Draft can be retrieved at: ftp://ftp.ietf.org/internet-drafts/draft-ietf-storm-rdmap-ext-01.txt From david.black@emc.com Tue Jul 12 21:35:59 2011 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 0C3CA11E808D for ; Tue, 12 Jul 2011 21:35:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.599 X-Spam-Level: X-Spam-Status: No, score=-106.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bsC1S-Rhq8Ky for ; Tue, 12 Jul 2011 21:35:58 -0700 (PDT) Received: from mexforward.lss.emc.com (mexforward.lss.emc.com [128.222.32.20]) by ietfa.amsl.com (Postfix) with ESMTP id 3FF5D11E8085 for ; Tue, 12 Jul 2011 21:35:57 -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 p6D4Ztxo022379 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Wed, 13 Jul 2011 00:35:55 -0400 Received: from mailhub.lss.emc.com (mailhub.lss.emc.com [10.254.221.253]) by hop04-l1d11-si04.isus.emc.com (RSA Interceptor) for ; Wed, 13 Jul 2011 00:35:39 -0400 Received: from mxhub01.corp.emc.com (mxhub01.corp.emc.com [10.254.141.103]) by mailhub.lss.emc.com (Switch-3.4.3/Switch-3.4.3) with ESMTP id p6D4YSv0032721 for ; Wed, 13 Jul 2011 00:34:28 -0400 Received: from mx14a.corp.emc.com ([169.254.1.245]) by mxhub01.corp.emc.com ([10.254.141.103]) with mapi; Wed, 13 Jul 2011 00:34:27 -0400 From: To: Importance: high X-Priority: 1 Date: Wed, 13 Jul 2011 00:34:25 -0400 Thread-Topic: WG Last Call: iSCSI drafts Thread-Index: AcxBFiUh10FbTCnMQGmdRPTSXlUg8g== Message-ID: <7C4DFCE962635144B8FAE8CA11D0BF1E0589413621@MX14A.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] WG Last Call: iSCSI drafts 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, 13 Jul 2011 04:35:59 -0000 This message announces a storm Working Group Last Call on the following two= iSCSI drafts: iSCSI Protocol (Consolidated) draft-ietf-storm-iscsi-cons-03.txt Internet Small Computer Systems Interface (iSCSI) SAM draft-ietf-storm-iscsi-sam-03.txt Please send all technical comments to the storm mailing list (storm@ietf.or= g). Editorial comments may be sent directly to the draft editors: - iSCSI Protocol (Consolidated): Mallikarjun Chadalapaka - iSCSI SAM (new features): Frederick Knight This is going to be a long Working Group Last Call because we need feedback= from implementers. Nonetheless, it would be good to have some WG Last Call review input before= the storm WG meeting in two weeks in Quebec City (Tuesday, July 26, 1710-1810). This Working Group Last Call will end at midnight, US Eastern Time on Sunda= y, August 21. Not counting the IETF meeting week, that's about a 4 week last call time period= . =20 The Protocol draft is enormous, and mostly unchanged, so I don't expect imp= lementers to read the whole thing. Please direct implementers to the "Summary of Changes" se= ction on pp.23-24 of the Protocol draft and ask them to look at the additions in the SAM draf= t. I will be contacting the EMC and VMware iSCSI implementers, plus the Linux = iSCSI maintainers. I believe that Mallikarjun and Fred have Microsoft and NetApp covered. Fee= dback from other implementers is strongly encouraged - anyone who can arrange for feedback f= rom another iSCSI implementation, should please do so, and send a note identifying the implem= entation to the list or directly to the WG chairs: Tom Talpey and David Black . I'll get this started with several comments on the SAM draft (these comment= s are as an individual, not as a WG co-chair): (1) The draft title should change. The SAM acronym needs to be expanded, a= nd the title needs to convey that there are new iSCSI features being added. (2) It makes sense to use the IANA registry for the new iSCSIProtocolLevel = key as the source of the revision numbers for the SCSI version descriptors for iSCSI = - see section D.8 in Annex D of SPC-3 or the current draft of SPC-4, and see the specifi= cation of the INQUIRY command for their usage. In order to do this, the draft needs= a couple of changes: - The value range for iSCSIProtocolLevel needs to be limited to 0-31. We'= ll be assigning the values 0, 1 and 2 to start with. - For assignment of new values, review by a T10 expert reviewer should be = added to the requirement for a published standards track RFC. How to state this p= rocess requirement will be a topic for discussion at the storm WG meeting in Que= bec City. Plus one on the Consolidated Draft - it's enormous ... while I don't think = that the main draft can be split (getting this all into one document was a goal), we shou= ld consider whether the Annexes can be put into a separate document. Unfortunately, Annex D on= SendTargets is definitely normative, and Annex E on clearing effects may be normative, plu= s all the annexes were originally included in the main draft because they are useful to imple= menters. This is for discussion on the list and in Quebec City. 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 ttalpey@microsoft.com Wed Jul 13 07:21:23 2011 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 BC5B321F88CE for ; Wed, 13 Jul 2011 07:21:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.599 X-Spam-Level: X-Spam-Status: No, score=-110.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Y3VuIMtYG4dV for ; Wed, 13 Jul 2011 07:21:23 -0700 (PDT) Received: from smtp.microsoft.com (mailb.microsoft.com [131.107.115.215]) by ietfa.amsl.com (Postfix) with ESMTP id 0B42511E807E for ; Wed, 13 Jul 2011 07:21:22 -0700 (PDT) Received: from TK5EX14HUBC102.redmond.corp.microsoft.com (157.54.7.154) by TK5-EXGWY-E802.partners.extranet.microsoft.com (10.251.56.168) with Microsoft SMTP Server (TLS) id 8.2.176.0; Wed, 13 Jul 2011 07:21:21 -0700 Received: from TK5EX14MBXC111.redmond.corp.microsoft.com ([169.254.2.64]) by TK5EX14HUBC102.redmond.corp.microsoft.com ([157.54.7.154]) with mapi id 14.01.0323.002; Wed, 13 Jul 2011 07:21:21 -0700 From: Tom Talpey To: "Frederick.Knight@netapp.com" , "storm@ietf.org" Thread-Topic: Comments on draft-ietf-storm-iscsi-sam-03.txt Thread-Index: AcxBZwzvVGfG7hhLTh+MiHwcBVZYEw== Date: Wed, 13 Jul 2011 14:21:20 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [157.54.51.33] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: [storm] Comments on draft-ietf-storm-iscsi-sam-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: Wed, 13 Jul 2011 14:21:23 -0000 Several initial comments on the Abstract: > Internet Small Computer Systems Interface (iSCSI) is a SCSI > transport protocol that maps the SCSI family of protocols onto > TCP/IP. RFC 3720 defines the iSCSI protocol. The current > iSCSI protocol (RFC 3720 and RFC 5048) is based on the SAM-2 > version of the SCSI family of protocols). This document > defines additions and changes to the iSCSI protocol to enabled > additional features that were added to the SCSI family of > protocols through SAM-3, SAM-4, and SAM-5. > > This document updates RFC 3720 and RFC 5048 and the text in > this document supersedes the text in RFC 3720 and RFC 5048 > when the two differ. 1) Recommend deleting the second sentence "RFC3720 defines the iSCSI protoc= ol". It's in contradiction with the third sentence, and is only historicall= y correct. 2) Delete the word "current" in the third sentence, as it will become obsol= ete. Perhaps reword as "The iSCSI protocol as specified in RFC3720 and RFC5= 048 is based on the SAM-2...". Also note there is a mismatched ")" at the e= nd. 3) The fourth sentence says "added ... through SAM-3, SAM-4 and SAM-5". Thi= s is a very general statement, and seems too strong. Also note the typo "en= abled". How about "This document defines extensions to the iSCSI protocol t= o support certain additional features of the SCSI protocol defined in SAM-3= , SAM-4 and SAM-5." =20 4) The last sentence is unclear on which "two" differ - 3720 differs from 5= 048? Current document differs from 3720? Current document differs from both= ? Also, "supersede" is definitely too strong - there is no requirement made= to support these higher SAM levels. Suggest simply saying that the documen= t "updates" both RFC3720 and RFC5048, and let the body of the text sort out= the applicability. But, an overall question. Should this applicability statement be instead = made to the new consolidated draft? This document will apply in general, no= t merely to RFC3720/5048. Tom. From ttalpey@microsoft.com Wed Jul 13 08:12:58 2011 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 6122321F8695 for ; Wed, 13 Jul 2011 08:12:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.598 X-Spam-Level: X-Spam-Status: No, score=-110.598 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zNkzcVDkBOXD for ; Wed, 13 Jul 2011 08:12:57 -0700 (PDT) Received: from smtp.microsoft.com (mailc.microsoft.com [131.107.115.214]) by ietfa.amsl.com (Postfix) with ESMTP id 4E6D121F8663 for ; Wed, 13 Jul 2011 08:12:57 -0700 (PDT) Received: from TK5EX14HUBC106.redmond.corp.microsoft.com (157.54.80.61) by TK5-EXGWY-E803.partners.extranet.microsoft.com (10.251.56.169) with Microsoft SMTP Server (TLS) id 8.2.176.0; Wed, 13 Jul 2011 08:12:56 -0700 Received: from TK5EX14MBXC111.redmond.corp.microsoft.com ([169.254.2.64]) by TK5EX14HUBC106.redmond.corp.microsoft.com ([157.54.80.61]) with mapi id 14.01.0323.002; Wed, 13 Jul 2011 08:12:56 -0700 From: Tom Talpey To: Alexander Nezhinsky , Michael Ko Thread-Topic: [storm] iSER draft Thread-Index: AQHMNlPpov6tD7xTq0WTfzkPhGmP2JTUcDZAgABph/mAAdAuAIATxsXg Date: Wed, 13 Jul 2011 15:12:56 +0000 Message-ID: References: <971779FD6B314A40B1A3658E521C0D4A@china.huawei.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [157.54.51.33] Content-Type: multipart/alternative; boundary="_000_F83812DF4B59B9499C1BC978336D91745EE0279DTK5EX14MBXC111r_" MIME-Version: 1.0 Cc: "storm@ietf.org" Subject: Re: [storm] iSER draft 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, 13 Jul 2011 15:12:58 -0000 --_000_F83812DF4B59B9499C1BC978336D91745EE0279DTK5EX14MBXC111r_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 WWVzLCB1bmRlcnN0b29kIG9uIHRoZSBaQlZBL0luZmluaWJhbmQgaXNzdWUuIFJlZ2FyZGluZyB0 aGUgVkEgdGVybeKAmXMgcHJlc2VuY2UgaW4gYW4gZWFybGllciBkcmFmdCwgSSBkaWQgbm90IHNl ZSBpdCBpbiBSRkM1MDQ2IGFuZCBJIGRpZCBub3QgcmV2aWV3IHRoZSBleHBpcmVkIGRyYWZ0LCBz byBjb25zaWRlciB0aGVzZSBjb21tZW50cyB0byBiZSBvbiB0aGUgb3ZlcmFsbCBjaGFuZ2UsIG5v dCB0aGUgbGFzdCByZXZpc2lvbi4NCg0KTGV0IG1lIHRyeSBhIGRpZmZlcmVudCBhcHByb2FjaCB0 byBwZXJoYXBzIG1ha2UgbXlzZWxmIGNsZWFyZXIuDQoNCkZpcnN0LCBpdCBzZWVtcyB0byBtZSB0 aGF0IGEg4oCcdmlydHVhbCBhZGRyZXNz4oCdIGhhcyBubyByZWFsIG1lYW5pbmcgdG8gdGhlIG5l dHdvcmsgcHJvdG9jb2wuIEl0IGJlZ2lucywgcGVyaGFwcywgYXMgc29tZSB2YWx1ZSBpbiBhbiBh ZGRyZXNzIHNwYWNlIG9uIHRoZSBpbml0aWF0b3IsIGJ1dCBpdOKAmXMgbm90IG1lYW5pbmdmdWwg b24gdGhlIHRhcmdldCBpbiB0aGlzIHdheSwgaXTigJlzIG9ubHkgdXNlZCB0byByZXF1ZXN0IHRo YXQgdGhlIHJlbW90ZSBSTklDIHBlcmZvcm0gYSB0cmFuc2ZlciB0byB0aGF0IG9yaWdpbmFsbHkg cmVnaXN0ZXJlZCByZW1vdGUgYWRkcmVzcy4gU28gY2FsbGluZyBpdCBhIFZpcnR1YWwgQWRkcmVz cyBhcyBhbiBpU0VSIHByb3RvY29sIG9iamVjdCBzZWVtcywgdG8gbWUsIGFuIGFydGlmaWNpYWwg YW5kIHNvbWV3aGF0IGxlYWRpbmcgY29udmVudGlvbi4NCg0KU2Vjb25kLCB0aGUgVmlydHVhbCBB ZGRyZXNzIGdvZXMgb3V0IGZyb20gdGhlIGluaXRpYXRvciB0byB0aGUgdGFyZ2V0IGluIGEgQ29u dHJvbCBQRFUsIGJ1dCB3aGVyZSBkb2VzIGl0IGNvbWUgYmFjaz8gVGhlIFJETUEgUmVhZCBvciBX cml0ZSBhcyBkZXBpY3RlZCBpbiAoeHgpIHNob3dzIG9ubHkgYSBUYWdnZWQgT2Zmc2V0LiBTbywg aXTigJlzIG5vdCBjbGVhciB3aGF0IGl0cyBwcm90b2NvbCBtZWFuaW5nIGlzLg0KDQpUaGlyZCwg SSBkb27igJl0IGV2ZXIgc2VlIGEgVGFnZ2VkIEJ1ZmZlciBkZXNjcmliZWQgYnkgYSBmdWxseSBx dWFsaWZpZWQgZm91ci10dXBsZS4gSSBzZWUgaXQgYXBwZWFyaW5nIGFzIGVpdGhlciB7IFN0YWcs IFRPLCBsZW5ndGggfSBvciB7IFN0YWcsIFZBLCBsZW5ndGggfSwgZGVwZW5kaW5nIG9uIHRoZSBh ZGRyZXNzaW5nIG1vZGUuDQoNCkkgdGhpbmsgdGhlIG5vbi1aQlZBIG1vZGUgaXMgcmVhbGx5IGp1 c3QgYSBzcGVjaWFsIGNhc2Ugb2YgdGhlIGV4aXN0aW5nIG9uZSwgYnV0IHdoZXJlIHRoZSBtZWFu aW5nIG9mIFRPIGhhcyBjaGFuZ2VkIGZyb20gYSBzbWFsbCBvZmZzZXQgdG8gc29tZSBvdGhlciB0 b2tlbiwgZ2VuZXJhdGVkIGFuZCBtYW5hZ2VkIG9ubHkgYXQgdGhlIGluaXRpYXRvci4gU28sIGl0 IHNlZW1zIGFydGlmaWNpYWwgdG8gZGVmaW5lIGl0IGFzIGRpc3RpbmN0LCBhbmQgZG9jdW1lbnQg aXQgYXMgcG9zc2Vzc2luZyBzb21lIG5ldyBwcm9wZXJ0aWVzLiBJc27igJl0IGl0IGp1c3QgYSBU YXJnZXQgT2Zmc2V0LCBzdGlsbD8NCg0KVG9tLg0KDQoNCg0KRnJvbTogQWxleGFuZGVyIE5lemhp bnNreSBbbWFpbHRvOm5lemhpbnNreUBnbWFpbC5jb21dDQpTZW50OiBUaHVyc2RheSwgSnVuZSAz MCwgMjAxMSAyOjA4IFBNDQpUbzogTWljaGFlbCBLbw0KQ2M6IFRvbSBUYWxwZXk7IHN0b3JtQGll dGYub3JnDQpTdWJqZWN0OiBSZTogW3N0b3JtXSBpU0VSIGRyYWZ0DQoNCg0KT24gVGh1LCBKdW4g MzAsIDIwMTEgYXQgMTI6MjYgQU0sIE1pY2hhZWwgS28gPE1pY2hhZWxAaHVhd2Vpc3ltYW50ZWMu Y29tPG1haWx0bzpNaWNoYWVsQGh1YXdlaXN5bWFudGVjLmNvbT4+IHdyb3RlOg0KVG9tLA0KDQpB cyBvcmlnaW5hbGx5IHdyaXR0ZW4sIHRoZSBpU0VSIHNwZWMgYWx3YXlzIGFzc3VtZXMgWkJWQSAo emVyby1iYXNlZCB2aXJ0dWFsIGFkZHJlc3MpLiAgQnV0IHdoZW4gaVNFUiBpcyB1c2VkIGluIGNv bmp1bmN0aW9uIHdpdGggdHJhbnNwb3J0cyBvdGhlciB0aGFuIGlXQVJQLCB0aGVyZSBpcyBhIG5l ZWQgdG8gaW5jbHVkZSB0aGUgdmlydHVhbCBhZGRyZXNzIGZvciB0aGUgdGFnZ2VkIGJ1ZmZlci4g IFN1Y2ggaXMgdGhlIGNhc2UgZm9yIEluZmluaWJhbmQuICBBY2NvcmRpbmdseSwgdGhlIFZpcnR1 YWwgQWRkcmVzcyBmaWVsZCBoYXMgYmVlbiBhZGRlZCB0byB0aGUgaVNDU0kgQ29udHJvbCBUeXBl IFBEVXMgKHNlYy4gOS4yKS4gIEFsZXggcG9pbnRlZCBvdXQgdGhhdCB0aGUgdGFnZ2VkIGJ1ZmZl ciBzaG91bGQgbm93IGJlIGlkZW50aWZpZWQgYnkgdGhlIDQtdHVwbGUgKFNUYWcsIFZBLCBUTywg YW5kIGxlbmd0aCkgaW5zdGVhZC4gIFRoaXMgc2hvdWxkIGJlIHVwZGF0ZWQgZXZlcnl3aGVyZSB3 aGVyZSB0aGUgdGVybSAidGFnZ2VkIGJ1ZmZlciIgaXMgbWVudGlvbmVkIGluIHRoZSBzcGVjLiAg Rm9yIGV4YW1wbGUsIGluIHNlYy4gMS4xIHVuZGVyIEFkdmVydGlzZW1lbnQsIHRoZSBzZW50ZW5j ZSAiQSB0eXBpY2FsIG1ldGhvZCB3b3VsZCBiZSBmb3IgdGhlIGlTRVIgTGF5ZXIgdG8gZW1iZWQg dGhlIFRhZ2dlZCBCdWZmZXIncyBTVGFnLCBUTywgYW5kIGJ1ZmZlciBsZW5ndGggaW4gYSBTZW5k IE1lc3NhZ2UgZGVzdGluZWQgZm9yIHRoZSByZW1vdGUgaVNFUiBMYXllciIgc2hvdWxkIGJlIG1v ZGlmaWVkIHRvICJBIHR5cGljYWwgbWV0aG9kIHdvdWxkIGJlIGZvciB0aGUgaVNFUiBMYXllciB0 byBlbWJlZCB0aGUgVGFnZ2VkIEJ1ZmZlcidzIFNUYWcsIFZBLCBUTywgYW5kIGJ1ZmZlciBsZW5n dGggaW4gYSBTZW5kIE1lc3NhZ2UgZGVzdGluZWQgZm9yIHRoZSByZW1vdGUgaVNFUiBMYXllci4i ICBCVFcsIHRoaXMgc2VudGVuY2UgYWxzbyBhbnN3ZXJzIHlvdXIgcXVlc3Rpb24gYXMgdG8gd2hl dGhlciBWQSBpcyBwYXNzZWQgb24gdGhlIHdpcmUuDQoNCg0KQWdyZWUsIHVzaW5nIFZBIHdhcyBp biB0aGUgZHJhZnQgYWxyZWFkeSwgSSBvbmx5IHN1Z2dlc3RlZCB0byBjbGFyaWZ5IGl0cyB1c2Ug KGFuZCBtb2RlcyBvZiB1c2UpIGZyb20gdGhlIGxldmVsIG9mIGRlZmluaXRpb25zIGFuZCB1cCwN CnNvIHRoYXQgaXQgd29uJ3QgInN1ZGRlbmx5IiBhcHBlYXIgaW4gdGhlIGhlYWRlciBmb3JtYXQg ZGVzY3JpcHRpb24gc2VjdGlvbi4NCg0KVGhlIFZpcnR1YWwgQWRkcmVzcyBpcyBsaXRlcmFsbHkg dGhlIHZpcnR1YWwgYWRkcmVzcyBvZiB0aGUgdGFnZ2VkIGJ1ZmZlci4gIFRoZSB0YWdnZWQgb2Zm c2V0IGlzIHRoZSBkaXNwbGFjZW1lbnQgcmVsYXRpdmUgdG8gdGhlIGJlZ2lubmluZyBvZiB0aGUg YnVmZmVyIHN0YXJ0aW5nIGF0IHRoZSB2aXJ0dWFsIGFkZHJlc3MuDQoNCldlIGNvdWxkIHJlcGhy YXNlIHRoZSBkZWZpbml0aW9uIG9mIFZpcnR1YWwgQWRkcmVzcyBpbiBzZWMuIDEuMSBhcyBmb2xs b3dzOg0KDQoiVmlydHVhbCBBZGRyZXNzIChWQSkgLSBUaGlzIGlzIHRoZSB2aXJ0dWFsIGFkZHJl c3Mgb2YgdGhlIFRhZ2dlZCBCdWZmZXIgb24gYSBOb2RlLiAgV2hlbiBzZXQgdG8gMCwgaXQgaW5k aWNhdGVzIHRoYXQgYSB2aXJ0dWFsIGFkZHJlc3MgaXMgbm90IG5lZWRlZCB0byBsb2NhdGUgdGhl IFRhZ2dlZCBCdWZmZXIuIg0KDQoNClJlYWQgYW5kIHdyaXRlIGJ1ZmZlcnMgYXJlIGlkZW50aWZp ZWQgYnkgdGhlIGNvbWJpbmF0aW9uIG9mIFNUYWcgYW5kIFZBLg0KDQpPSy4gSSB0cmllZCB0byBt YWtlIHRoZSBzYW1lIHBvaW50IGluIHRoZSBmb2xsb3dpbmc6DQpCb3RoIGZpZWxkcyBzaG91bGQg YmUgcmVxdWlyZWQgZm9yIGFueSB0cmFuc3BvcnQuIFRoaXMgcmVxdWlyZW1lbnQgZG9lcyBub3Qg cHJlY2x1ZGUNCnVzaW5nIFpCVkEgd2hlcmUgcG9zc2libGUuIFdoZW4gVkEgaXMgbm90IHVzZWQg KGFzIGluIGlXQVJQKSBpdCBpcyBzZXQgdG8gMC4NCg0KQmVsb3cgaXMgdGhlIGFjdHVhbGx5IHVz ZWQgZm9ybWF0Og0KDQpzdHJ1Y3QgaXNlcl9oZHIgew0KICB1aW50OF90ICAgZmxhZ3M7DQogIHVp bnQ4X3QgICByc3ZkWzNdOw0KICB1aW50MzJfdCAgd3JpdGVfc3RhZzsgLyogd3JpdGUgcmtleSBp biBJQiAqLw0KICB1aW50NjRfdCAgd3JpdGVfdmE7DQogIHVpbnQzMl90ICByZWFkX3N0YWc7ICAv KiByZWFkIHJrZXkgaW4gSUIgKi8NCiAgdWludDY0X3QgIHJlYWRfdmE7DQp9DQpJIHdvdWxkIGxp a2UgdG8gYWRkIHRoYXQgSW5maW5pQmFuZCBkb2VzIGhhdmUgWkJWQSBtb2RlLiBJdCBzdXBwb3Nl ZGx5IHByb3ZpZGVzIGxlc3MgdGhhbiBvcHRpbWFsIHBlcmZvcm1hbmNlIHdpdGggSUIuDQpBbmQg aXQgaXMgbm90IGV4cG9ydGVkIHRocm91Z2ggdGhlIGN1cnJlbnQgcmRtYS1jbSBBUEksIHdoaWNo IHN1cHBvcnRzIFJETUEvRXRoZXJuZXQgYXMgd2VsbCwgYW5kIGlzIHRoZSBvbmx5IG9wdGlvbg0K dG8gdXNlIFJETUEgaW4gdXNlciBzcGFjZSBsaW51eCBhcHBzLCBhcyBvZiB0b2RheS4NCg0KU28g eW91IGNvdWxkIGxvb2sgYXQgdGhlIGFkZGl0aW9uYWwgZmllbGRzIGFzIGEga2luZCBvZiAicmVz ZXJ2ZWQiIGluIGNhc2Ugb2Ygc3RhbmRhcmQgWkJWQSBpbXBsZW1lbnRhdGlvbiwNCnVzZWQgdG8g cHJhY3RpY2FsbHkgc3VwcG9ydCBjZXJ0YWluIEFQSXMgYW5kIGdldCBlbmhhbmNlZCBwZXJmb3Jt YW5jZSBpbiBzb21lIGNhc2VzLg0KDQpBbGV4DQo= --_000_F83812DF4B59B9499C1BC978336D91745EE0279DTK5EX14MBXC111r_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTQgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6 Q2FsaWJyaTsNCglwYW5vc2UtMToyIDE1IDUgMiAyIDIgNCAzIDIgNDt9DQpAZm9udC1mYWNlDQoJ e2ZvbnQtZmFtaWx5OlRhaG9tYTsNCglwYW5vc2UtMToyIDExIDYgNCAzIDUgNCA0IDIgNDt9DQov KiBTdHlsZSBEZWZpbml0aW9ucyAqLw0KcC5Nc29Ob3JtYWwsIGxpLk1zb05vcm1hbCwgZGl2Lk1z b05vcm1hbA0KCXttYXJnaW46MGluOw0KCW1hcmdpbi1ib3R0b206LjAwMDFwdDsNCglmb250LXNp emU6MTIuMHB0Ow0KCWZvbnQtZmFtaWx5OiJUaW1lcyBOZXcgUm9tYW4iLCJzZXJpZiI7fQ0KYTps aW5rLCBzcGFuLk1zb0h5cGVybGluaw0KCXttc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJY29sb3I6 Ymx1ZTsNCgl0ZXh0LWRlY29yYXRpb246dW5kZXJsaW5lO30NCmE6dmlzaXRlZCwgc3Bhbi5Nc29I eXBlcmxpbmtGb2xsb3dlZA0KCXttc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJY29sb3I6cHVycGxl Ow0KCXRleHQtZGVjb3JhdGlvbjp1bmRlcmxpbmU7fQ0Kc3Bhbi5FbWFpbFN0eWxlMTcNCgl7bXNv LXN0eWxlLXR5cGU6cGVyc29uYWwtcmVwbHk7DQoJZm9udC1mYW1pbHk6IkNhbGlicmkiLCJzYW5z LXNlcmlmIjsNCgljb2xvcjojMUY0OTdEO30NCi5Nc29DaHBEZWZhdWx0DQoJe21zby1zdHlsZS10 eXBlOmV4cG9ydC1vbmx5Ow0KCWZvbnQtZmFtaWx5OiJDYWxpYnJpIiwic2Fucy1zZXJpZiI7fQ0K QHBhZ2UgV29yZFNlY3Rpb24xDQoJe3NpemU6OC41aW4gMTEuMGluOw0KCW1hcmdpbjoxLjBpbiAx LjBpbiAxLjBpbiAxLjBpbjt9DQpkaXYuV29yZFNlY3Rpb24xDQoJe3BhZ2U6V29yZFNlY3Rpb24x O30NCi0tPjwvc3R5bGU+PCEtLVtpZiBndGUgbXNvIDldPjx4bWw+DQo8bzpzaGFwZWRlZmF1bHRz IHY6ZXh0PSJlZGl0IiBzcGlkbWF4PSIxMDI2IiAvPg0KPC94bWw+PCFbZW5kaWZdLS0+PCEtLVtp ZiBndGUgbXNvIDldPjx4bWw+DQo8bzpzaGFwZWxheW91dCB2OmV4dD0iZWRpdCI+DQo8bzppZG1h cCB2OmV4dD0iZWRpdCIgZGF0YT0iMSIgLz4NCjwvbzpzaGFwZWxheW91dD48L3htbD48IVtlbmRp Zl0tLT4NCjwvaGVhZD4NCjxib2R5IGxhbmc9IkVOLVVTIiBsaW5rPSJibHVlIiB2bGluaz0icHVy cGxlIj4NCjxkaXYgY2xhc3M9IldvcmRTZWN0aW9uMSI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48 c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1 b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+WWVzLCB1bmRlcnN0b29k IG9uIHRoZSBaQlZBL0luZmluaWJhbmQgaXNzdWUuIFJlZ2FyZGluZyB0aGUgVkEgdGVybeKAmXMg cHJlc2VuY2UgaW4gYW4gZWFybGllciBkcmFmdCwgSSBkaWQgbm90IHNlZSBpdCBpbiBSRkM1MDQ2 IGFuZCBJIGRpZCBub3QgcmV2aWV3IHRoZSBleHBpcmVkDQogZHJhZnQsIHNvIGNvbnNpZGVyIHRo ZXNlIGNvbW1lbnRzIHRvIGJlIG9uIHRoZSBvdmVyYWxsIGNoYW5nZSwgbm90IHRoZSBsYXN0IHJl dmlzaW9uLjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFu IHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDss JnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj48bzpwPiZuYnNwOzwvbzpwPjwv c3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEx LjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVv dDs7Y29sb3I6IzFGNDk3RCI+TGV0IG1lIHRyeSBhIGRpZmZlcmVudCBhcHByb2FjaCB0byBwZXJo YXBzIG1ha2UgbXlzZWxmIGNsZWFyZXIuDQo8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTom cXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+ PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4g c3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90Oywm cXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPkZpcnN0LCBpdCBzZWVtcyB0byBt ZSB0aGF0IGEg4oCcdmlydHVhbCBhZGRyZXNz4oCdIGhhcyBubyByZWFsIG1lYW5pbmcgdG8gdGhl IG5ldHdvcmsgcHJvdG9jb2wuIEl0IGJlZ2lucywgcGVyaGFwcywgYXMgc29tZSB2YWx1ZSBpbiBh biBhZGRyZXNzIHNwYWNlIG9uIHRoZSBpbml0aWF0b3IsDQogYnV0IGl04oCZcyBub3QgbWVhbmlu Z2Z1bCBvbiB0aGUgdGFyZ2V0IGluIHRoaXMgd2F5LCBpdOKAmXMgb25seSB1c2VkIHRvIHJlcXVl c3QgdGhhdCB0aGUgcmVtb3RlIFJOSUMgcGVyZm9ybSBhIHRyYW5zZmVyIHRvIHRoYXQgb3JpZ2lu YWxseSByZWdpc3RlcmVkIHJlbW90ZSBhZGRyZXNzLiBTbyBjYWxsaW5nIGl0IGEgVmlydHVhbCBB ZGRyZXNzIGFzIGFuIGlTRVIgcHJvdG9jb2wgb2JqZWN0IHNlZW1zLCB0byBtZSwgYW4gYXJ0aWZp Y2lhbCBhbmQgc29tZXdoYXQNCiBsZWFkaW5nIGNvbnZlbnRpb24uPG86cD48L286cD48L3NwYW4+ PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7 Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2Nv bG9yOiMxRjQ5N0QiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29O b3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0Nh bGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj5TZWNvbmQs IHRoZSBWaXJ0dWFsIEFkZHJlc3MgZ29lcyBvdXQgZnJvbSB0aGUgaW5pdGlhdG9yIHRvIHRoZSB0 YXJnZXQgaW4gYSBDb250cm9sIFBEVSwgYnV0IHdoZXJlIGRvZXMgaXQgY29tZSBiYWNrPyBUaGUg UkRNQSBSZWFkIG9yIFdyaXRlIGFzIGRlcGljdGVkIGluICh4eCkNCiBzaG93cyBvbmx5IGEgVGFn Z2VkIE9mZnNldC4gU28sIGl04oCZcyBub3QgY2xlYXIgd2hhdCBpdHMgcHJvdG9jb2wgbWVhbmlu ZyBpcy48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBz dHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZx dW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+PG86cD4mbmJzcDs8L286cD48L3Nw YW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4w cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7 O2NvbG9yOiMxRjQ5N0QiPlRoaXJkLCBJIGRvbuKAmXQgZXZlciBzZWUgYSBUYWdnZWQgQnVmZmVy IGRlc2NyaWJlZCBieSBhIGZ1bGx5IHF1YWxpZmllZCBmb3VyLXR1cGxlLiBJIHNlZSBpdCBhcHBl YXJpbmcgYXMgZWl0aGVyIHsgU3RhZywgVE8sIGxlbmd0aCB9IG9yIHsgU3RhZywgVkEsIGxlbmd0 aCB9LA0KIGRlcGVuZGluZyBvbiB0aGUgYWRkcmVzc2luZyBtb2RlLjxvOnA+PC9vOnA+PC9zcGFu PjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0 O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztj b2xvcjojMUY0OTdEIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtD YWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+SSB0aGlu ayB0aGUgbm9uLVpCVkEgbW9kZSBpcyByZWFsbHkganVzdCBhIHNwZWNpYWwgY2FzZSBvZiB0aGUg ZXhpc3Rpbmcgb25lLCBidXQgd2hlcmUgdGhlIG1lYW5pbmcgb2YgVE8gaGFzIGNoYW5nZWQgZnJv bSBhIHNtYWxsIG9mZnNldCB0byBzb21lIG90aGVyIHRva2VuLA0KIGdlbmVyYXRlZCBhbmQgbWFu YWdlZCBvbmx5IGF0IHRoZSBpbml0aWF0b3IuIFNvLCBpdCBzZWVtcyBhcnRpZmljaWFsIHRvIGRl ZmluZSBpdCBhcyBkaXN0aW5jdCwgYW5kIGRvY3VtZW50IGl0IGFzIHBvc3Nlc3Npbmcgc29tZSBu ZXcgcHJvcGVydGllcy4gSXNu4oCZdCBpdCBqdXN0IGEgVGFyZ2V0IE9mZnNldCwgc3RpbGw/PG86 cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZv bnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5z LXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQt ZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjoj MUY0OTdEIj5Ub20uPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+ PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZx dW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPjxvOnA+Jm5ic3A7PC9v OnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNp emU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJp ZiZxdW90Oztjb2xvcjojMUY0OTdEIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWls eTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3 RCI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PGI+ PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7VGFob21hJnF1 b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDsiPkZyb206PC9zcGFuPjwvYj48c3BhbiBzdHlsZT0i Zm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtUYWhvbWEmcXVvdDssJnF1b3Q7c2Fu cy1zZXJpZiZxdW90OyI+IEFsZXhhbmRlciBOZXpoaW5za3kgW21haWx0bzpuZXpoaW5za3lAZ21h aWwuY29tXQ0KPGJyPg0KPGI+U2VudDo8L2I+IFRodXJzZGF5LCBKdW5lIDMwLCAyMDExIDI6MDgg UE08YnI+DQo8Yj5Ubzo8L2I+IE1pY2hhZWwgS288YnI+DQo8Yj5DYzo8L2I+IFRvbSBUYWxwZXk7 IHN0b3JtQGlldGYub3JnPGJyPg0KPGI+U3ViamVjdDo8L2I+IFJlOiBbc3Rvcm1dIGlTRVIgZHJh ZnQ8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNw OzwvbzpwPjwvcD4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpw PjwvcD4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5PbiBUaHUsIEp1biAzMCwgMjAxMSBh dCAxMjoyNiBBTSwgTWljaGFlbCBLbyAmbHQ7PGEgaHJlZj0ibWFpbHRvOk1pY2hhZWxAaHVhd2Vp c3ltYW50ZWMuY29tIj5NaWNoYWVsQGh1YXdlaXN5bWFudGVjLmNvbTwvYT4mZ3Q7IHdyb3RlOjxv OnA+PC9vOnA+PC9wPg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBz dHlsZT0iZm9udC1zaXplOjEwLjBwdCI+VG9tLDwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjwvZGl2 Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPC9k aXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTox MC4wcHQiPkFzIG9yaWdpbmFsbHkgd3JpdHRlbiwgdGhlIGlTRVIgc3BlYyBhbHdheXMgYXNzdW1l cyBaQlZBICh6ZXJvLWJhc2VkIHZpcnR1YWwgYWRkcmVzcykuJm5ic3A7IEJ1dCB3aGVuIGlTRVIg aXMgdXNlZCBpbiBjb25qdW5jdGlvbiB3aXRoIHRyYW5zcG9ydHMgb3RoZXIgdGhhbiBpV0FSUCwg dGhlcmUgaXMgYSBuZWVkIHRvIGluY2x1ZGUgdGhlIHZpcnR1YWwgYWRkcmVzcw0KIGZvciB0aGUg dGFnZ2VkIGJ1ZmZlci4mbmJzcDsgU3VjaCBpcyB0aGUgY2FzZSBmb3IgSW5maW5pYmFuZC4mbmJz cDsgQWNjb3JkaW5nbHksIHRoZSBWaXJ0dWFsIEFkZHJlc3MgZmllbGQgaGFzIGJlZW4gYWRkZWQg dG8gdGhlIGlTQ1NJIENvbnRyb2wgVHlwZSBQRFVzIChzZWMuIDkuMikuJm5ic3A7IEFsZXggcG9p bnRlZCBvdXQgdGhhdCB0aGUgdGFnZ2VkIGJ1ZmZlciBzaG91bGQgbm93IGJlIGlkZW50aWZpZWQg YnkgdGhlIDQtdHVwbGUgKFNUYWcsIFZBLCBUTywgYW5kIGxlbmd0aCkNCiBpbnN0ZWFkLiZuYnNw OyBUaGlzIHNob3VsZCBiZSB1cGRhdGVkIGV2ZXJ5d2hlcmUgd2hlcmUgdGhlIHRlcm0gJnF1b3Q7 dGFnZ2VkIGJ1ZmZlciZxdW90OyBpcyBtZW50aW9uZWQgaW4gdGhlIHNwZWMuJm5ic3A7IEZvciBl eGFtcGxlLCBpbiBzZWMuIDEuMSB1bmRlciBBZHZlcnRpc2VtZW50LCZuYnNwO3RoZSBzZW50ZW5j ZSAmcXVvdDtBIHR5cGljYWwgbWV0aG9kIHdvdWxkIGJlIGZvciB0aGUgaVNFUiBMYXllciB0byBl bWJlZCB0aGUgVGFnZ2VkIEJ1ZmZlcidzIFNUYWcsIFRPLCBhbmQgYnVmZmVyDQogbGVuZ3RoIGlu IGEgU2VuZCBNZXNzYWdlIGRlc3RpbmVkIGZvciB0aGUgcmVtb3RlIGlTRVIgTGF5ZXImcXVvdDsg c2hvdWxkIGJlIG1vZGlmaWVkIHRvICZxdW90O0EgdHlwaWNhbCBtZXRob2Qgd291bGQgYmUgZm9y IHRoZSBpU0VSIExheWVyIHRvIGVtYmVkIHRoZSBUYWdnZWQgQnVmZmVyJ3MgU1RhZywgVkEsIFRP LCBhbmQgYnVmZmVyIGxlbmd0aCBpbiBhIFNlbmQgTWVzc2FnZSBkZXN0aW5lZCBmb3IgdGhlIHJl bW90ZSBpU0VSIExheWVyLiZxdW90OyZuYnNwOyBCVFcsIHRoaXMNCiBzZW50ZW5jZSBhbHNvIGFu c3dlcnMgeW91ciBxdWVzdGlvbiBhcyB0byB3aGV0aGVyIFZBIGlzIHBhc3NlZCBvbiB0aGUgd2ly ZS48L3NwYW4+PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIj4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xh c3M9Ik1zb05vcm1hbCI+PGJyPg0KQWdyZWUsIHVzaW5nIFZBIHdhcyBpbiB0aGUgZHJhZnQgYWxy ZWFkeSwgSSBvbmx5IHN1Z2dlc3RlZCB0byBjbGFyaWZ5IGl0cyB1c2UgKGFuZCBtb2RlcyBvZiB1 c2UpIGZyb20gdGhlIGxldmVsIG9mIGRlZmluaXRpb25zIGFuZCB1cCwNCjxicj4NCnNvIHRoYXQg aXQgd29uJ3QgJnF1b3Q7c3VkZGVubHkmcXVvdDsgYXBwZWFyIGluIHRoZSBoZWFkZXIgZm9ybWF0 IGRlc2NyaXB0aW9uIHNlY3Rpb24uPGJyPg0KJm5ic3A7PG86cD48L286cD48L3A+DQo8L2Rpdj4N CjxibG9ja3F1b3RlIHN0eWxlPSJib3JkZXI6bm9uZTtib3JkZXItbGVmdDpzb2xpZCAjQ0NDQ0ND IDEuMHB0O3BhZGRpbmc6MGluIDBpbiAwaW4gNi4wcHQ7bWFyZ2luLWxlZnQ6NC44cHQ7bWFyZ2lu LXJpZ2h0OjBpbiI+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0 eWxlPSJmb250LXNpemU6MTAuMHB0Ij5UaGUgVmlydHVhbCBBZGRyZXNzIGlzIGxpdGVyYWxseSB0 aGUgdmlydHVhbCBhZGRyZXNzIG9mIHRoZSB0YWdnZWQgYnVmZmVyLiZuYnNwOyBUaGUgdGFnZ2Vk IG9mZnNldCBpcyB0aGUgZGlzcGxhY2VtZW50IHJlbGF0aXZlIHRvIHRoZSBiZWdpbm5pbmcgb2Yg dGhlIGJ1ZmZlciBzdGFydGluZyBhdCB0aGUgdmlydHVhbCBhZGRyZXNzLjwvc3Bhbj48bzpwPjwv bzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPiZuYnNwOzxvOnA+ PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5 bGU9ImZvbnQtc2l6ZToxMC4wcHQiPldlIGNvdWxkIHJlcGhyYXNlIHRoZSBkZWZpbml0aW9uIG9m IFZpcnR1YWwgQWRkcmVzcyBpbiBzZWMuIDEuMSBhcyBmb2xsb3dzOjwvc3Bhbj48bzpwPjwvbzpw PjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPiZuYnNwOzxvOnA+PC9v OnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9 ImZvbnQtc2l6ZToxMC4wcHQiPiZxdW90O1ZpcnR1YWwgQWRkcmVzcyAoVkEpIC0gVGhpcyBpcyB0 aGUgdmlydHVhbCBhZGRyZXNzIG9mIHRoZSZuYnNwO1RhZ2dlZCBCdWZmZXIgb24gYSBOb2RlLiZu YnNwOyBXaGVuIHNldCB0byAwLCBpdCBpbmRpY2F0ZXMgdGhhdCBhIHZpcnR1YWwgYWRkcmVzcyBp cyBub3QgbmVlZGVkIHRvIGxvY2F0ZSB0aGUgVGFnZ2VkIEJ1ZmZlci4mcXVvdDs8L3NwYW4+PGJy Pg0KJm5ic3A7PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9ibG9ja3F1b3RlPg0K PGJsb2NrcXVvdGUgc3R5bGU9ImJvcmRlcjpub25lO2JvcmRlci1sZWZ0OnNvbGlkICNDQ0NDQ0Mg MS4wcHQ7cGFkZGluZzowaW4gMGluIDBpbiA2LjBwdDttYXJnaW4tbGVmdDo0LjhwdDttYXJnaW4t cmlnaHQ6MGluIj4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+Jm5ic3A7PG86 cD48L286cD48L3A+DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPlJlYWQgYW5kIHdyaXRl IGJ1ZmZlcnMgYXJlIGlkZW50aWZpZWQgYnkgdGhlIGNvbWJpbmF0aW9uIG9mIFNUYWcgYW5kIFZB LjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Jsb2NrcXVvdGU+DQo8ZGl2Pg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCI+PGJyPg0KT0suIEkgdHJpZWQgdG8gbWFrZSB0aGUgc2FtZSBwb2ludCBpbiB0 aGUgZm9sbG93aW5nOjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8YmxvY2txdW90ZSBzdHlsZT0i Ym9yZGVyOm5vbmU7Ym9yZGVyLWxlZnQ6c29saWQgI0NDQ0NDQyAxLjBwdDtwYWRkaW5nOjBpbiAw aW4gMGluIDYuMHB0O21hcmdpbi1sZWZ0OjQuOHB0O21hcmdpbi1yaWdodDowaW4iPg0KPGRpdj4N CjxibG9ja3F1b3RlIHN0eWxlPSJib3JkZXI6bm9uZTtib3JkZXItbGVmdDpzb2xpZCBibGFjayAx LjVwdDtwYWRkaW5nOjBpbiAwaW4gMGluIDQuMHB0O21hcmdpbi1sZWZ0OjMuNzVwdDttYXJnaW4t dG9wOjUuMHB0O21hcmdpbi1yaWdodDowaW47bWFyZ2luLWJvdHRvbTo1LjBwdCI+DQo8ZGl2Pg0K PGRpdj4NCjxkaXY+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJt c28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+Qm90aCBm aWVsZHMgc2hvdWxkIGJlIHJlcXVpcmVkIGZvciBhbnkgdHJhbnNwb3J0LiBUaGlzIHJlcXVpcmVt ZW50IGRvZXMgbm90IHByZWNsdWRlPGJyPg0KdXNpbmcgWkJWQSB3aGVyZSBwb3NzaWJsZS4gV2hl biBWQSBpcyBub3QgdXNlZCAoYXMgaW4gaVdBUlApIGl0IGlzIHNldCB0byAwLjxicj4NCjxicj4N CkJlbG93IGlzIHRoZSBhY3R1YWxseSB1c2VkIGZvcm1hdDo8YnI+DQo8YnI+DQo8c3BhbiBzdHls ZT0iZm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDsiPnN0cnVjdCBpc2VyX2hkciB7 PGJyPg0KJm5ic3A7IHVpbnQ4X3QmbmJzcDsmbmJzcDsgZmxhZ3M7PGJyPg0KJm5ic3A7IHVpbnQ4 X3QmbmJzcDsmbmJzcDsgcnN2ZFszXTs8YnI+DQombmJzcDsgdWludDMyX3QmbmJzcDsgd3JpdGVf c3RhZzsgLyogd3JpdGUgcmtleSBpbiBJQiAqLzxicj4NCiZuYnNwOyB1aW50NjRfdCZuYnNwOyB3 cml0ZV92YTs8YnI+DQombmJzcDsgdWludDMyX3QmbmJzcDsgcmVhZF9zdGFnOyZuYnNwOyAvKiBy ZWFkIHJrZXkgaW4gSUIgKi88YnI+DQombmJzcDsgdWludDY0X3QmbmJzcDsgcmVhZF92YTs8YnI+ DQp9PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+ DQo8L2Rpdj4NCjwvYmxvY2txdW90ZT4NCjwvZGl2Pg0KPC9ibG9ja3F1b3RlPg0KPGRpdj4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiPkkgd291bGQgbGlrZSB0byBhZGQgdGhhdCBJbmZpbmlCYW5kIGRv ZXMgaGF2ZSBaQlZBIG1vZGUuIEl0IHN1cHBvc2VkbHkgcHJvdmlkZXMgbGVzcyB0aGFuIG9wdGlt YWwgcGVyZm9ybWFuY2Ugd2l0aCBJQi4NCjxicj4NCkFuZCBpdCBpcyBub3QgZXhwb3J0ZWQgdGhy b3VnaCB0aGUgY3VycmVudCByZG1hLWNtIEFQSSwgd2hpY2ggc3VwcG9ydHMgUkRNQS9FdGhlcm5l dCBhcyB3ZWxsLCBhbmQgaXMgdGhlIG9ubHkgb3B0aW9uDQo8YnI+DQp0byB1c2UgUkRNQSBpbiB1 c2VyIHNwYWNlIGxpbnV4IGFwcHMsIGFzIG9mIHRvZGF5LiA8YnI+DQo8YnI+DQpTbyB5b3UgY291 bGQgbG9vayBhdCB0aGUgYWRkaXRpb25hbCBmaWVsZHMgYXMgYSBraW5kIG9mICZxdW90O3Jlc2Vy dmVkJnF1b3Q7IGluIGNhc2Ugb2Ygc3RhbmRhcmQgWkJWQSBpbXBsZW1lbnRhdGlvbiwNCjxicj4N CnVzZWQgdG8gcHJhY3RpY2FsbHkgc3VwcG9ydCBjZXJ0YWluIEFQSXMgYW5kIGdldCBlbmhhbmNl ZCBwZXJmb3JtYW5jZSBpbiBzb21lIGNhc2VzLjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rp dj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxicj4NCkFsZXg8bzpwPjwvbzpwPjwvcD4NCjwvZGl2 Pg0KPC9kaXY+DQo8L2JvZHk+DQo8L2h0bWw+DQo= --_000_F83812DF4B59B9499C1BC978336D91745EE0279DTK5EX14MBXC111r_-- From cait@asomi.com Wed Jul 13 22:16:23 2011 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 01F6321F8B27 for ; Wed, 13 Jul 2011 22:16:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DliB4KPjUGli for ; Wed, 13 Jul 2011 22:16:18 -0700 (PDT) Received: from p3plsmtpa06-04.prod.phx3.secureserver.net (p3plsmtpa06-04.prod.phx3.secureserver.net [173.201.192.105]) by ietfa.amsl.com (Postfix) with SMTP id C31D821F8588 for ; Wed, 13 Jul 2011 22:16:15 -0700 (PDT) Received: (qmail 25498 invoked from network); 14 Jul 2011 04:49:34 -0000 Received: from unknown (108.80.57.164) by p3plsmtpa06-04.prod.phx3.secureserver.net (173.201.192.105) with ESMTP; 14 Jul 2011 04:49:34 -0000 Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=windows-1252 From: Caitlin Bestler In-Reply-To: Date: Wed, 13 Jul 2011 21:49:32 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: References: <971779FD6B314A40B1A3658E521C0D4A@china.huawei.com> To: Tom Talpey X-Mailer: Apple Mail (2.1084) Cc: "storm@ietf.org" Subject: Re: [storm] iSER draft 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, 14 Jul 2011 05:16:23 -0000 On Jul 13, 2011, at 8:12 AM, Tom Talpey wrote: > Yes, understood on the ZBVA/Infiniband issue. Regarding the VA term=92s = presence in an earlier draft, I did not see it in RFC5046 and I did not = review the expired draft, so consider these comments to be on the = overall change, not the last revision. > =20 > Let me try a different approach to perhaps make myself clearer. > =20 > First, it seems to me that a =93virtual address=94 has no real meaning = to the network protocol. It begins, perhaps, as some value in an address = space on the initiator, but it=92s not meaningful on the target in this = way, it=92s only used to request that the remote RNIC perform a transfer = to that originally registered remote address. So calling it a Virtual = Address as an iSER protocol object seems, to me, an artificial and = somewhat leading convention. > =20 > Second, the Virtual Address goes out from the initiator to the target = in a Control PDU, but where does it come back? The RDMA Read or Write as = depicted in (xx) shows only a Tagged Offset. So, it=92s not clear what = its protocol meaning is. > =20 > Third, I don=92t ever see a Tagged Buffer described by a fully = qualified four-tuple. I see it appearing as either { Stag, TO, length } = or { Stag, VA, length }, depending on the addressing mode. > =20 > I think the non-ZBVA mode is really just a special case of the = existing one, but where the meaning of TO has changed from a small = offset to some other token, generated and managed only at the initiator. = So, it seems artificial to define it as distinct, and document it as = possessing some new properties. Isn=92t it just a Target Offset, still? > =20 > Tom. > =20 > =20 I agree, so far we have not seen a protocol justification for the need = to add "Virtual Address" to the glossary as something distinct from = Target Offset for the purpose of defining an IETF protocol. I am sympathetic to the interoperability issues raised, but I don't = think those can justify something that has *no* justification in the = protocol. If someone could site a class of implementation where there is a real = need for this distinction in an iSER adapter, but as far as I can see = the adapters have to be able to translate to TO *anyway* in order to use an RDMA Write or = RDMA Read. Local Interface compatibility with IB can make a *lot* of sense, but why = does it have to make its way into the *wire* protocol? -- Caitlin Bestler cait@asomi.com http://www.asomi.com/CaitlinBestlerResume.html From Michael@huaweisymantec.com Thu Jul 14 11:38:53 2011 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 1F7B121F85C5 for ; Thu, 14 Jul 2011 11:38:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.598 X-Spam-Level: X-Spam-Status: No, score=-2.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dZLKCXJpEC0W for ; Thu, 14 Jul 2011 11:38:48 -0700 (PDT) Received: from mta1.huaweisymantec.com (mta1.huaweisymantec.com [218.17.155.14]) by ietfa.amsl.com (Postfix) with ESMTP id 559C021F85A0 for ; Thu, 14 Jul 2011 11:38:48 -0700 (PDT) MIME-version: 1.0 Content-type: multipart/alternative; boundary="Boundary_(ID_rZZvc9bNcNIPnrYQnnC/DQ)" Received: from hstml01-in.huaweisymantec.com ([172.26.3.41]) by hstga01-in.huaweisymantec.com (Sun Java(tm) System Messaging Server 6.3-8.03 (built Apr 24 2009; 32bit)) with ESMTP id <0LOC0092G6HMWZ60@hstga01-in.huaweisymantec.com> for storm@ietf.org; Fri, 15 Jul 2011 02:39:22 +0800 (CST) Received: from m90003900a ([10.47.146.217]) by hstml01-in.huaweisymantec.com (Sun Java(tm) System Messaging Server 6.3-8.03 (built Apr 24 2009; 32bit)) with ESMTPA id <0LOC007GO6HJXN00@hstml01-in.huaweisymantec.com> for storm@ietf.org; Fri, 15 Jul 2011 02:39:28 +0800 (CST) Message-id: <1680F0051D794095A86AF16343CAD400@china.huawei.com> From: Michael Ko To: Caitlin Bestler , Tom Talpey References: <971779FD6B314A40B1A3658E521C0D4A@china.huawei.com> Date: Thu, 14 Jul 2011 11:38:36 -0700 X-Priority: 3 X-MSMail-priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.5931 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.6109 Cc: storm@ietf.org Subject: Re: [storm] iSER draft 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, 14 Jul 2011 18:38:53 -0000 This is a multi-part message in MIME format. --Boundary_(ID_rZZvc9bNcNIPnrYQnnC/DQ) Content-type: text/plain; charset=Windows-1252 Content-transfer-encoding: quoted-printable When "Virtual Address" is not used, as in iWARP, the initiator side = needs to translate the "Tagged Offset" which is just the offset into the = buffer, into a usable address by adding it to the starting base address = of the buffer. If the starting base address is communicated to the = target side, as is done in some RCaPs, then the "Tagged Offset" is the = usable address itself at the initiator where data is to be fetched or = stored. Alex suggested that perhaps we can change the name "Virtual = Address" to "Steering Address". Then it can be defined in the glossary = without tripping over the common term "virtual address". Mike ----- Original Message -----=20 From: Caitlin Bestler=20 To: Tom Talpey=20 Cc: Alexander Nezhinsky ; Michael Ko ; storm@ietf.org=20 Sent: Wednesday, July 13, 2011 9:49 PM Subject: Re: [storm] iSER draft On Jul 13, 2011, at 8:12 AM, Tom Talpey wrote: > Yes, understood on the ZBVA/Infiniband issue. Regarding the VA = term=92s presence in an earlier draft, I did not see it in RFC5046 and I = did not review the expired draft, so consider these comments to be on = the overall change, not the last revision. > =20 > Let me try a different approach to perhaps make myself clearer. > =20 > First, it seems to me that a =93virtual address=94 has no real = meaning to the network protocol. It begins, perhaps, as some value in an = address space on the initiator, but it=92s not meaningful on the target = in this way, it=92s only used to request that the remote RNIC perform a = transfer to that originally registered remote address. So calling it a = Virtual Address as an iSER protocol object seems, to me, an artificial = and somewhat leading convention. > =20 > Second, the Virtual Address goes out from the initiator to the = target in a Control PDU, but where does it come back? The RDMA Read or = Write as depicted in (xx) shows only a Tagged Offset. So, it=92s not = clear what its protocol meaning is. > =20 > Third, I don=92t ever see a Tagged Buffer described by a fully = qualified four-tuple. I see it appearing as either { Stag, TO, length } = or { Stag, VA, length }, depending on the addressing mode. > =20 > I think the non-ZBVA mode is really just a special case of the = existing one, but where the meaning of TO has changed from a small = offset to some other token, generated and managed only at the initiator. = So, it seems artificial to define it as distinct, and document it as = possessing some new properties. Isn=92t it just a Target Offset, still? > =20 > Tom. > =20 > =20 I agree, so far we have not seen a protocol justification for the need = to add "Virtual Address" to the glossary as something distinct from = Target Offset for the purpose of defining an IETF protocol. I am sympathetic to the interoperability issues raised, but I don't = think those can justify something that has *no* justification in the = protocol. If someone could site a class of implementation where there is a real = need for this distinction in an iSER adapter, but as far as I can see = the adapters have to be able to translate to TO *anyway* in order to use an RDMA Write = or RDMA Read. Local Interface compatibility with IB can make a *lot* of sense, but = why does it have to make its way into the *wire* protocol? -- Caitlin Bestler cait@asomi.com http://www.asomi.com/CaitlinBestlerResume.html --Boundary_(ID_rZZvc9bNcNIPnrYQnnC/DQ) Content-type: text/html; charset=Windows-1252 Content-transfer-encoding: quoted-printable
When "Virtual Address" is not used, as in iWARP, the = initiator=20 side needs to translate the "Tagged Offset" which is just the offset = into the=20 buffer, into a usable address by adding it to the starting base address = of the=20 buffer.  If the starting base address is communicated to the target = side,=20 as is done in some RCaPs, then the "Tagged Offset" is the = usable=20 address itself at the initiator where data is to be fetched or=20 stored.  Alex suggested that perhaps we can change the name = "Virtual=20 Address" to "Steering Address".  Then it can be defined in the = glossary=20 without tripping over the common term "virtual address".
 
Mike
----- Original Message -----
From:=20 Caitlin = Bestler=20
Cc: Alexander Nezhinsky ; Michael Ko ; storm@ietf.org
Sent: Wednesday, July 13, 2011 = 9:49=20 PM
Subject: Re: [storm] iSER = draft


On Jul 13, 2011, at 8:12 AM, Tom Talpey = wrote:

>=20 Yes, understood on the ZBVA/Infiniband issue. Regarding the VA = term=92s presence=20 in an earlier draft, I did not see it in RFC5046 and I did not review = the=20 expired draft, so consider these comments to be on the overall change, = not the=20 last revision.
> 
> Let me try a different approach = to=20 perhaps make myself clearer.
> 
> First, it seems to = me that=20 a =93virtual address=94 has no real meaning to the network protocol. = It begins,=20 perhaps, as some value in an address space on the initiator, but = it=92s not=20 meaningful on the target in this way, it=92s only used to request that = the=20 remote RNIC perform a transfer to that originally registered remote = address.=20 So calling it a Virtual Address as an iSER protocol object seems, to = me, an=20 artificial and somewhat leading convention.
> 
> = Second, the=20 Virtual Address goes out from the initiator to the target in a Control = PDU,=20 but where does it come back? The RDMA Read or Write as depicted in = (xx) shows=20 only a Tagged Offset. So, it=92s not clear what its protocol meaning=20 is.
> 
> Third, I don=92t ever see a Tagged Buffer = described=20 by a fully qualified four-tuple. I see it appearing as either { Stag, = TO,=20 length } or { Stag, VA, length }, depending on the addressing=20 mode.
> 
> I think the non-ZBVA mode is really just = a=20 special case of the existing one, but where the meaning of TO has = changed from=20 a small offset to some other token, generated and managed only at the=20 initiator. So, it seems artificial to define it as distinct, and = document it=20 as possessing some new properties. Isn=92t it just a Target Offset,=20 still?
> 
> Tom.
> 
>  =

I=20 agree, so far we have not seen a protocol justification for the need = to add=20 "Virtual Address" to the glossary as something distinct from Target=20 Offset
for the purpose of defining an IETF protocol.

I am=20 sympathetic to the interoperability issues raised, but I don't think = those can=20 justify something that has *no* justification in the = protocol.

If=20 someone could site a class of implementation where there is a real = need for=20 this distinction in an iSER adapter, but as far as I can see the = adapters=20 have
to be able to translate to TO *anyway* in order to use an RDMA = Write=20 or RDMA Read.

Local Interface compatibility with IB can make a = *lot* of=20 sense, but why does it have to make its way into the *wire*=20 protocol?

--
Caitlin Bestler
cait@asomi.com
http://www.asomi.= com/CaitlinBestlerResume.html



--Boundary_(ID_rZZvc9bNcNIPnrYQnnC/DQ)-- From ttalpey@microsoft.com Thu Jul 14 13:16:21 2011 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 19FC611E80C9 for ; Thu, 14 Jul 2011 13:16:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.598 X-Spam-Level: X-Spam-Status: No, score=-110.598 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2G0QtUH3bWN9 for ; Thu, 14 Jul 2011 13:16:17 -0700 (PDT) Received: from smtp.microsoft.com (smtp.microsoft.com [131.107.115.215]) by ietfa.amsl.com (Postfix) with ESMTP id D4C2A11E807B for ; Thu, 14 Jul 2011 13:16:16 -0700 (PDT) Received: from TK5EX14MLTC104.redmond.corp.microsoft.com (157.54.79.159) by TK5-EXGWY-E802.partners.extranet.microsoft.com (10.251.56.168) with Microsoft SMTP Server (TLS) id 8.2.176.0; Thu, 14 Jul 2011 13:16:16 -0700 Received: from TK5EX14MBXC111.redmond.corp.microsoft.com ([169.254.2.64]) by TK5EX14MLTC104.redmond.corp.microsoft.com ([157.54.79.159]) with mapi id 14.01.0323.002; Thu, 14 Jul 2011 13:16:16 -0700 From: Tom Talpey To: Michael Ko , Caitlin Bestler Thread-Topic: [storm] iSER draft Thread-Index: AQHMNlPpov6tD7xTq0WTfzkPhGmP2JTUcDZAgABph/mAAdAuAIATxsXggAFa2ACAAHJheIAAD/iA Date: Thu, 14 Jul 2011 20:16:15 +0000 Message-ID: References: <971779FD6B314A40B1A3658E521C0D4A@china.huawei.com> <1680F0051D794095A86AF16343CAD400@china.huawei.com> In-Reply-To: <1680F0051D794095A86AF16343CAD400@china.huawei.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [157.54.51.33] Content-Type: multipart/alternative; boundary="_000_F83812DF4B59B9499C1BC978336D91745EE039F9TK5EX14MBXC111r_" MIME-Version: 1.0 Cc: "storm@ietf.org" Subject: Re: [storm] iSER draft 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, 14 Jul 2011 20:16:21 -0000 --_000_F83812DF4B59B9499C1BC978336D91745EE039F9TK5EX14MBXC111r_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Changing the name doesn't address the core issues here. There are no proces= sing rules defined in the draft to support the arithmetic you describe belo= w, or even to use the Steering/Virtual Address. For example, section 7.3.5 states the target MUST use the Buffer Offset of = the Data-In PDU as the Tagged Offset of an RDMA Write. Where does the new S= teering Address in the control PDU header get folded into the Tagged Offset= ? And what protocol state would trigger the target to do so, including perf= orm the arithmetic? Same question for several other sections. From: Michael Ko [mailto:Michael@huaweisymantec.com] Sent: Thursday, July 14, 2011 2:39 PM To: Caitlin Bestler; Tom Talpey Cc: Alexander Nezhinsky; storm@ietf.org Subject: Re: [storm] iSER draft When "Virtual Address" is not used, as in iWARP, the initiator side needs t= o translate the "Tagged Offset" which is just the offset into the buffer, i= nto a usable address by adding it to the starting base address of the buffe= r. If the starting base address is communicated to the target side, as is = done in some RCaPs, then the "Tagged Offset" is the usable address itself a= t the initiator where data is to be fetched or stored. Alex suggested that= perhaps we can change the name "Virtual Address" to "Steering Address". T= hen it can be defined in the glossary without tripping over the common term= "virtual address". Mike ----- Original Message ----- From: Caitlin Bestler To: Tom Talpey Cc: Alexander Nezhinsky ; Michael Ko ; storm@ietf.org Sent: Wednesday, July 13, 2011 9:49 PM Subject: Re: [storm] iSER draft On Jul 13, 2011, at 8:12 AM, Tom Talpey wrote: > Yes, understood on the ZBVA/Infiniband issue. Regarding the VA term's pre= sence in an earlier draft, I did not see it in RFC5046 and I did not review= the expired draft, so consider these comments to be on the overall change,= not the last revision. > > Let me try a different approach to perhaps make myself clearer. > > First, it seems to me that a "virtual address" has no real meaning to the= network protocol. It begins, perhaps, as some value in an address space on= the initiator, but it's not meaningful on the target in this way, it's onl= y used to request that the remote RNIC perform a transfer to that originall= y registered remote address. So calling it a Virtual Address as an iSER pro= tocol object seems, to me, an artificial and somewhat leading convention. > > Second, the Virtual Address goes out from the initiator to the target in = a Control PDU, but where does it come back? The RDMA Read or Write as depic= ted in (xx) shows only a Tagged Offset. So, it's not clear what its protoco= l meaning is. > > Third, I don't ever see a Tagged Buffer described by a fully qualified fo= ur-tuple. I see it appearing as either { Stag, TO, length } or { Stag, VA, = length }, depending on the addressing mode. > > I think the non-ZBVA mode is really just a special case of the existing o= ne, but where the meaning of TO has changed from a small offset to some oth= er token, generated and managed only at the initiator. So, it seems artific= ial to define it as distinct, and document it as possessing some new proper= ties. Isn't it just a Target Offset, still? > > Tom. > > I agree, so far we have not seen a protocol justification for the need to a= dd "Virtual Address" to the glossary as something distinct from Target Offs= et for the purpose of defining an IETF protocol. I am sympathetic to the interoperability issues raised, but I don't think t= hose can justify something that has *no* justification in the protocol. If someone could site a class of implementation where there is a real need = for this distinction in an iSER adapter, but as far as I can see the adapte= rs have to be able to translate to TO *anyway* in order to use an RDMA Write or RDM= A Read. Local Interface compatibility with IB can make a *lot* of sense, but why do= es it have to make its way into the *wire* protocol? -- Caitlin Bestler cait@asomi.com http://www.asomi.com/CaitlinBestlerResume.html --_000_F83812DF4B59B9499C1BC978336D91745EE039F9TK5EX14MBXC111r_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Changing the name doesn&#= 8217;t address the core issues here. There are no processing rules defined = in the draft to support the arithmetic you describe below, or even to use the Steering/Virtual Address.

 <= /p>

For example, section 7.3.= 5 states the target MUST use the Buffer Offset of the Data-In PDU as the Ta= gged Offset of an RDMA Write. Where does the new Steering Address in the control PDU header get folded into the Tagged Offset? And w= hat protocol state would trigger the target to do so, including perform the= arithmetic? Same question for several other sections.

 <= /p>

 <= /p>

 <= /p>

From: Michael = Ko [mailto:Michael@huaweisymantec.com]
Sent: Thursday, July 14, 2011 2:39 PM
To: Caitlin Bestler; Tom Talpey
Cc: Alexander Nezhinsky; storm@ietf.org
Subject: Re: [storm] iSER draft

 

When "Virtual = Address" is not used, as in iWARP, the initiator side needs to transla= te the "Tagged Offset" which is just the offset into the buffer, = into a usable address by adding it to the starting base address of the buffer.  If the starting base address is communicated = to the target side, as is done in some RCaPs, then the "Tagged Of= fset" is the usable address itself at the initiator where data is= to be fetched or stored.  Alex suggested that perhaps we can change the name "Virtual Address" to "Steering Address&= quot;.  Then it can be defined in the glossary without tripping over t= he common term "virtual address".

 

Mike

----- Original Message -----

Sent: Wednesday,= July 13, 2011 9:49 PM

Subject: Re: [st= orm] iSER draft

 


On Jul 13, 2011, at 8:12 AM, Tom Talpey wrote:

> Yes, understood on the ZBVA/Infiniband issue. Regarding the VA term= 217;s presence in an earlier draft, I did not see it in RFC5046 and I did n= ot review the expired draft, so consider these comments to be on the overal= l change, not the last revision.
> 
> Let me try a different approach to perhaps make myself clearer.
> 
> First, it seems to me that a “virtual address” has no real= meaning to the network protocol. It begins, perhaps, as some value in an a= ddress space on the initiator, but it’s not meaningful on the target = in this way, it’s only used to request that the remote RNIC perform a transfer to that originally registered remote address. So c= alling it a Virtual Address as an iSER protocol object seems, to me, an art= ificial and somewhat leading convention.
> 
> Second, the Virtual Address goes out from the initiator to the target = in a Control PDU, but where does it come back? The RDMA Read or Write as de= picted in (xx) shows only a Tagged Offset. So, it’s not clear what it= s protocol meaning is.
> 
> Third, I don’t ever see a Tagged Buffer described by a fully qua= lified four-tuple. I see it appearing as either { Stag, TO, length } or { S= tag, VA, length }, depending on the addressing mode.
> 
> I think the non-ZBVA mode is really just a special case of the existin= g one, but where the meaning of TO has changed from a small offset to some = other token, generated and managed only at the initiator. So, it seems arti= ficial to define it as distinct, and document it as possessing some new properties. Isn’t it just a Targe= t Offset, still?
> 
> Tom.
> 
> 

I agree, so far we have not seen a protocol justification for the need to a= dd "Virtual Address" to the glossary as something distinct from T= arget Offset
for the purpose of defining an IETF protocol.

I am sympathetic to the interoperability issues raised, but I don't think t= hose can justify something that has *no* justification in the protocol.

If someone could site a class of implementation where there is a real need = for this distinction in an iSER adapter, but as far as I can see the adapte= rs have
to be able to translate to TO *anyway* in order to use an RDMA Write or RDM= A Read.

Local Interface compatibility with IB can make a *lot* of sense, but why do= es it have to make its way into the *wire* protocol?

--
Caitlin Bestler
cait@asomi.com
http://www.asomi= .com/CaitlinBestlerResume.html


--_000_F83812DF4B59B9499C1BC978336D91745EE039F9TK5EX14MBXC111r_-- From Michael@huaweisymantec.com Thu Jul 14 13:53:24 2011 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 C9BF111E80D1 for ; Thu, 14 Jul 2011 13:53:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.598 X-Spam-Level: X-Spam-Status: No, score=-2.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0sX6ESnUBVUy for ; Thu, 14 Jul 2011 13:53:20 -0700 (PDT) Received: from mta1.huaweisymantec.com (mta1.huaweisymantec.com [218.17.155.14]) by ietfa.amsl.com (Postfix) with ESMTP id D9C5811E8076 for ; Thu, 14 Jul 2011 13:53:19 -0700 (PDT) MIME-version: 1.0 Content-type: multipart/alternative; boundary="Boundary_(ID_o3Vcd5zWsGjdOCIVrO9Pdw)" Received: from hstml01-in.huaweisymantec.com ([172.26.3.41]) by hstga01-in.huaweisymantec.com (Sun Java(tm) System Messaging Server 6.3-8.03 (built Apr 24 2009; 32bit)) with ESMTP id <0LOC009RUCPTWZ70@hstga01-in.huaweisymantec.com> for storm@ietf.org; Fri, 15 Jul 2011 04:53:53 +0800 (CST) Received: from m90003900a ([10.47.146.217]) by hstml01-in.huaweisymantec.com (Sun Java(tm) System Messaging Server 6.3-8.03 (built Apr 24 2009; 32bit)) with ESMTPA id <0LOC004WICPRQA00@hstml01-in.huaweisymantec.com> for storm@ietf.org; Fri, 15 Jul 2011 04:53:59 +0800 (CST) Message-id: <70CC5C8CCDD74EA0A9CEFF6DDC8145ED@china.huawei.com> From: Michael Ko To: Tom Talpey , Caitlin Bestler References: <971779FD6B314A40B1A3658E521C0D4A@china.huawei.com> <1680F0051D794095A86AF16343CAD400@china.huawei.com> Date: Thu, 14 Jul 2011 13:53:08 -0700 X-Priority: 3 X-MSMail-priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.5931 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.6109 Cc: storm@ietf.org Subject: Re: [storm] iSER draft 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, 14 Jul 2011 20:53:24 -0000 This is a multi-part message in MIME format. --Boundary_(ID_o3Vcd5zWsGjdOCIVrO9Pdw) Content-type: text/plain; charset=iso-8859-1 Content-transfer-encoding: 7BIT For clarity, I need to update in the next revision of the spec everywhere where "Tagged Offset", "Steering Tag", etc. are mentioned to specify how the Tagged Offset is computed from the "Steering Address" and the buffer offset. So for example, in the example you cited in section 7.3.5, the target computes the Tagged Offset using the Steering Address and the Buffer Offset. For iWARP, the Steering Address is zero, and so the Tagged Offset is the Buffer Offset in the SCSI Data-in PDU as defined in RFC 5046. Mike ----- Original Message ----- From: Tom Talpey To: Michael Ko ; Caitlin Bestler Cc: Alexander Nezhinsky ; storm@ietf.org Sent: Thursday, July 14, 2011 1:16 PM Subject: RE: [storm] iSER draft Changing the name doesn't address the core issues here. There are no processing rules defined in the draft to support the arithmetic you describe below, or even to use the Steering/Virtual Address. For example, section 7.3.5 states the target MUST use the Buffer Offset of the Data-In PDU as the Tagged Offset of an RDMA Write. Where does the new Steering Address in the control PDU header get folded into the Tagged Offset? And what protocol state would trigger the target to do so, including perform the arithmetic? Same question for several other sections. From: Michael Ko [mailto:Michael@huaweisymantec.com] Sent: Thursday, July 14, 2011 2:39 PM To: Caitlin Bestler; Tom Talpey Cc: Alexander Nezhinsky; storm@ietf.org Subject: Re: [storm] iSER draft When "Virtual Address" is not used, as in iWARP, the initiator side needs to translate the "Tagged Offset" which is just the offset into the buffer, into a usable address by adding it to the starting base address of the buffer. If the starting base address is communicated to the target side, as is done in some RCaPs, then the "Tagged Offset" is the usable address itself at the initiator where data is to be fetched or stored. Alex suggested that perhaps we can change the name "Virtual Address" to "Steering Address". Then it can be defined in the glossary without tripping over the common term "virtual address". Mike ----- Original Message ----- From: Caitlin Bestler To: Tom Talpey Cc: Alexander Nezhinsky ; Michael Ko ; storm@ietf.org Sent: Wednesday, July 13, 2011 9:49 PM Subject: Re: [storm] iSER draft On Jul 13, 2011, at 8:12 AM, Tom Talpey wrote: > Yes, understood on the ZBVA/Infiniband issue. Regarding the VA term's presence in an earlier draft, I did not see it in RFC5046 and I did not review the expired draft, so consider these comments to be on the overall change, not the last revision. > > Let me try a different approach to perhaps make myself clearer. > > First, it seems to me that a "virtual address" has no real meaning to the network protocol. It begins, perhaps, as some value in an address space on the initiator, but it's not meaningful on the target in this way, it's only used to request that the remote RNIC perform a transfer to that originally registered remote address. So calling it a Virtual Address as an iSER protocol object seems, to me, an artificial and somewhat leading convention. > > Second, the Virtual Address goes out from the initiator to the target in a Control PDU, but where does it come back? The RDMA Read or Write as depicted in (xx) shows only a Tagged Offset. So, it's not clear what its protocol meaning is. > > Third, I don't ever see a Tagged Buffer described by a fully qualified four-tuple. I see it appearing as either { Stag, TO, length } or { Stag, VA, length }, depending on the addressing mode. > > I think the non-ZBVA mode is really just a special case of the existing one, but where the meaning of TO has changed from a small offset to some other token, generated and managed only at the initiator. So, it seems artificial to define it as distinct, and document it as possessing some new properties. Isn't it just a Target Offset, still? > > Tom. > > I agree, so far we have not seen a protocol justification for the need to add "Virtual Address" to the glossary as something distinct from Target Offset for the purpose of defining an IETF protocol. I am sympathetic to the interoperability issues raised, but I don't think those can justify something that has *no* justification in the protocol. If someone could site a class of implementation where there is a real need for this distinction in an iSER adapter, but as far as I can see the adapters have to be able to translate to TO *anyway* in order to use an RDMA Write or RDMA Read. Local Interface compatibility with IB can make a *lot* of sense, but why does it have to make its way into the *wire* protocol? -- Caitlin Bestler cait@asomi.com http://www.asomi.com/CaitlinBestlerResume.html --Boundary_(ID_o3Vcd5zWsGjdOCIVrO9Pdw) Content-type: text/html; charset=iso-8859-1 Content-transfer-encoding: quoted-printable
For clarity, I need to update in the next revision = of the spec=20 everywhere where "Tagged Offset", "Steering Tag", etc. are mentioned to=20 specify how the Tagged Offset is computed from the "Steering=20 Address" and the buffer offset. 
 
So for example, in the example you cited in section=20 7.3.5, the target computes the Tagged Offset using the Steering = Address and=20 the Buffer Offset.  For iWARP, the Steering Address is zero, and so = the=20 Tagged Offset is the Buffer Offset in the SCSI Data-in PDU as defined in = RFC=20 5046.
 
Mike
----- Original Message -----
From:=20 Tom=20 Talpey
To: Michael Ko ; Caitlin = Bestler
Cc: Alexander Nezhinsky ; storm@ietf.org
Sent: Thursday, July 14, 2011 = 1:16=20 PM
Subject: RE: [storm] iSER = draft

Changing=20 the name doesn=92t address the core issues here. There are no = processing rules=20 defined in the draft to support the arithmetic you describe below, or = even to=20 use the Steering/Virtual Address.

 

For=20 example, section 7.3.5 states the target MUST use the Buffer Offset of = the=20 Data-In PDU as the Tagged Offset of an RDMA Write. Where does the new = Steering=20 Address in the control PDU header get folded into the Tagged Offset? = And what=20 protocol state would trigger the target to do so, including perform = the=20 arithmetic? Same question for several other = sections.

 

 

 

From: Michael = Ko=20 [mailto:Michael@huaweisymantec.com]
Sent: Thursday, July = 14, 2011=20 2:39 PM
To: Caitlin Bestler; Tom Talpey
Cc: = Alexander=20 Nezhinsky; storm@ietf.org
Subject: Re: [storm] iSER=20 draft

 

When "Virtual = Address" is not=20 used, as in iWARP, the initiator side needs to translate the "Tagged = Offset"=20 which is just the offset into the buffer, into a usable address by = adding it=20 to the starting base address of the buffer.  If the starting base = address=20 is communicated to the target side, as is done in some RCaPs, = then the=20 "Tagged Offset" is the usable address itself at the initiator = where data=20 is to be fetched or stored.  Alex suggested that perhaps we = can=20 change the name "Virtual Address" to "Steering Address".  Then it = can be=20 defined in the glossary without tripping over the common term "virtual = address".

 

Mike

----- = Original=20 Message -----

From: Caitlin = Bestler=20

To: Tom=20 Talpey

Cc: Alexander=20 Nezhinsky ; Michael Ko ; storm@ietf.org=20

Sent: = Wednesday, July=20 13, 2011 9:49 PM

Subject: Re: = [storm] iSER=20 draft

 


On Jul 13, = 2011, at 8:12=20 AM, Tom Talpey wrote:

> Yes, understood on the = ZBVA/Infiniband=20 issue. Regarding the VA term=92s presence in an earlier draft, I did = not see=20 it in RFC5046 and I did not review the expired draft, so consider = these=20 comments to be on the overall change, not the last = revision.
> =20
> Let me try a different approach to perhaps make myself=20 clearer.
> 
> First, it seems to me that a = =93virtual=20 address=94 has no real meaning to the network protocol. It begins, = perhaps, as=20 some value in an address space on the initiator, but it=92s not = meaningful on=20 the target in this way, it=92s only used to request that the remote = RNIC=20 perform a transfer to that originally registered remote address. So = calling=20 it a Virtual Address as an iSER protocol object seems, to me, an = artificial=20 and somewhat leading convention.
> 
> Second, the = Virtual=20 Address goes out from the initiator to the target in a Control PDU, = but=20 where does it come back? The RDMA Read or Write as depicted in (xx) = shows=20 only a Tagged Offset. So, it=92s not clear what its protocol meaning = is.
> 
> Third, I don=92t ever see a Tagged Buffer = described=20 by a fully qualified four-tuple. I see it appearing as either { = Stag, TO,=20 length } or { Stag, VA, length }, depending on the addressing=20 mode.
> 
> I think the non-ZBVA mode is really = just a=20 special case of the existing one, but where the meaning of TO has = changed=20 from a small offset to some other token, generated and managed only = at the=20 initiator. So, it seems artificial to define it as distinct, and = document it=20 as possessing some new properties. Isn=92t it just a Target Offset,=20 still?
> 
> Tom.
> 
>  =

I=20 agree, so far we have not seen a protocol justification for the need = to add=20 "Virtual Address" to the glossary as something distinct from Target=20 Offset
for the purpose of defining an IETF protocol.

I am=20 sympathetic to the interoperability issues raised, but I don't think = those=20 can justify something that has *no* justification in the = protocol.

If=20 someone could site a class of implementation where there is a real = need for=20 this distinction in an iSER adapter, but as far as I can see the = adapters=20 have
to be able to translate to TO *anyway* in order to use an = RDMA Write=20 or RDMA Read.

Local Interface compatibility with IB can make = a *lot*=20 of sense, but why does it have to make its way into the *wire*=20 protocol?

--
Caitlin Bestler
cait@asomi.com
http://www.asomi.= com/CaitlinBestlerResume.html


= --Boundary_(ID_o3Vcd5zWsGjdOCIVrO9Pdw)-- From cbm@chadalapaka.com Thu Jul 14 18:26:20 2011 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 8041421F86C1 for ; Thu, 14 Jul 2011 18:26:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.299 X-Spam-Level: X-Spam-Status: No, score=-2.299 tagged_above=-999 required=5 tests=[AWL=-0.300, BAYES_00=-2.599, J_CHICKENPOX_46=0.6] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Jr+U3IrUExzI for ; Thu, 14 Jul 2011 18:26:16 -0700 (PDT) Received: from snt0-omc1-s28.snt0.hotmail.com (snt0-omc1-s28.snt0.hotmail.com [65.55.90.39]) by ietfa.amsl.com (Postfix) with ESMTP id 6A12521F86C0 for ; Thu, 14 Jul 2011 18:26:16 -0700 (PDT) Received: from SNT131-DS10 ([65.55.90.7]) by snt0-omc1-s28.snt0.hotmail.com with Microsoft SMTPSVC(6.0.3790.4675); Thu, 14 Jul 2011 18:26:15 -0700 X-Originating-IP: [131.107.0.94] X-Originating-Email: [cbm@chadalapaka.com] Message-ID: From: Mallikarjun Chadalapaka To: "'Michael Ko'" , "Tom Talpey" , "'Caitlin Bestler'" References: <971779FD6B314A40B1A3658E521C0D4A@china.huawei.com> <1680F0051D794095A86AF16343CAD400@china.huawei.com> <70CC5C8CCDD74EA0A9CEFF6DDC8145ED@china.huawei.com> In-Reply-To: <70CC5C8CCDD74EA0A9CEFF6DDC8145ED@china.huawei.com> Date: Thu, 14 Jul 2011 18:26:15 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQIwSeqJJoVLyHMsNGW+iMTc16Ka+AD+40JOArGQ7j4BoviyegGIyVhfA1WikwgAjxH9YgF8HPDwAkrFNGmTsDmN0A== Content-Language: en-us X-OriginalArrivalTime: 15 Jul 2011 01:26:15.0842 (UTC) FILETIME=[30CCD020:01CC428E] Cc: storm@ietf.org Subject: Re: [storm] iSER draft 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, 15 Jul 2011 01:26:20 -0000 I suggest we have to be explicit about the responsibilities of each = protocol layer because the phrase =93initiator side needs to translate the Tagged Offset" sounds vague to me. Also, it may be worth formalizing the = notion of "if Virtual Address was used for this command" via a negotiated = connection attribute.=20 If I followed this thread right, it seems like we are talking roughly = about the following: 1) A shared iSCSI/iSER-level connection attribute (connection-scoped = text key?) that indicates whether Steering Address ("Address") or Tagged = Offset ("Offset") is required by the RCaP in the RDMA requests on the wire for = that connection. How the RCaP API exposes this capability to its local iSER layer is implementation-dependent, and we do not need spec it. 2) If the connection attribute =3D "Offset:,=20 a) the semantic requirement on the RCaP layer on the initiator is that it treats the incoming RDMA memory references as offsets, and does = the appropriate base+offset local translation for RDMA Reads and RDMA = Writes. =20 b) The initiator iSER layer must only use ZB-VA, and must set the Steering Address to 0 in appropriate control-type PDUs.=20 c) The target iSER layer must assume that zero TO for the advertised STag points to the beginning of the initiator I/O Buffer in all the RDMA Writes and RDMA Reads that it issues (same as now). 3) If the connection attribute =3D "Address": a) the semantic requirement on the RCaP layer on the initiator is that it treats incoming RDMA memory references as complete Steering Addresses in RDMA Reads and RDMA Writes. =20 b) The initiator iSER layer must use non-ZB-VA, and must set the Steering Address to the RCaP-API-returned Virtual Address in appropriate control-type PDUs. c) The target iSER layer must assume that the Steering Address for the advertised STag points to the beginning of the initiator I/O Buffer, = and compute the Tagged Offset in all the RDMA Writes and RDMA Reads that it issues by adding the Steering Address to the Buffer Offset received from = the Data_Descriptor of Datamover API. Mallikarjun =20 From: storm-bounces@ietf.org [mailto:storm-bounces@ietf.org] On Behalf = Of Michael Ko Sent: Thursday, July 14, 2011 1:53 PM To: Tom Talpey; Caitlin Bestler Cc: storm@ietf.org Subject: Re: [storm] iSER draft For clarity, I need to update in the next revision of the spec = everywhere where "Tagged Offset", "Steering Tag", etc. are mentioned to = specify=A0how the Tagged Offset is computed from the "Steering Address"=A0and the buffer offset.=A0 =A0 So for example, in the example you cited in section 7.3.5,=A0the target computes the Tagged Offset using the Steering Address and the Buffer Offset.=A0 For iWARP, the Steering Address is zero, and so the Tagged = Offset is the Buffer Offset in the SCSI Data-in PDU as defined in RFC 5046. =A0 Mike ----- Original Message -----=20 From: Tom Talpey=20 To: Michael Ko ; Caitlin Bestler=20 Cc: Alexander Nezhinsky ; storm@ietf.org=20 Sent: Thursday, July 14, 2011 1:16 PM Subject: RE: [storm] iSER draft Changing the name doesn=92t address the core issues here. There are no processing rules defined in the draft to support the arithmetic you = describe below, or even to use the Steering/Virtual Address. For example, section 7.3.5 states the target MUST use the Buffer Offset = of the Data-In PDU as the Tagged Offset of an RDMA Write. Where does the = new Steering Address in the control PDU header get folded into the Tagged Offset? And what protocol state would trigger the target to do so, = including perform the arithmetic? Same question for several other sections. From: Michael Ko [mailto:Michael@huaweisymantec.com]=20 Sent: Thursday, July 14, 2011 2:39 PM To: Caitlin Bestler; Tom Talpey Cc: Alexander Nezhinsky; storm@ietf.org Subject: Re: [storm] iSER draft When "Virtual Address" is not used, as in iWARP, the initiator side = needs to translate the "Tagged Offset" which is just the offset into the buffer, = into a usable address by adding it to the starting base address of the = buffer.=A0 If the starting base address is communicated to the target side, as is = done in some RCaPs, then=A0the "Tagged Offset" is=A0the usable address itself = at the initiator where data is to be fetched or stored.=A0=A0Alex suggested = that perhaps we can change the name "Virtual Address" to "Steering = Address".=A0 Then it can be defined in the glossary without tripping over the common = term "virtual address". =A0 Mike ----- Original Message -----=20 From: Caitlin Bestler=20 To: Tom Talpey=20 Cc: Alexander Nezhinsky ; Michael Ko ; storm@ietf.org=20 Sent: Wednesday, July 13, 2011 9:49 PM Subject: Re: [storm] iSER draft On Jul 13, 2011, at 8:12 AM, Tom Talpey wrote: > Yes, understood on the ZBVA/Infiniband issue. Regarding the VA = term=92s presence in an earlier draft, I did not see it in RFC5046 and I did not review the expired draft, so consider these comments to be on the = overall change, not the last revision. >=A0=20 > Let me try a different approach to perhaps make myself clearer. >=A0=20 > First, it seems to me that a =93virtual address=94 has no real meaning = to the network protocol. It begins, perhaps, as some value in an address space = on the initiator, but it=92s not meaningful on the target in this way, = it=92s only used to request that the remote RNIC perform a transfer to that = originally registered remote address. So calling it a Virtual Address as an iSER protocol object seems, to me, an artificial and somewhat leading = convention. >=A0=20 > Second, the Virtual Address goes out from the initiator to the target = in a Control PDU, but where does it come back? The RDMA Read or Write as = depicted in (xx) shows only a Tagged Offset. So, it=92s not clear what its = protocol meaning is. >=A0=20 > Third, I don=92t ever see a Tagged Buffer described by a fully = qualified four-tuple. I see it appearing as either { Stag, TO, length } or { Stag, = VA, length }, depending on the addressing mode. >=A0=20 > I think the non-ZBVA mode is really just a special case of the = existing one, but where the meaning of TO has changed from a small offset to some other token, generated and managed only at the initiator. So, it seems artificial to define it as distinct, and document it as possessing some = new properties. Isn=92t it just a Target Offset, still? >=A0=20 > Tom. >=A0=20 >=A0=20 I agree, so far we have not seen a protocol justification for the need = to add "Virtual Address" to the glossary as something distinct from Target Offset for the purpose of defining an IETF protocol. I am sympathetic to the interoperability issues raised, but I don't = think those can justify something that has *no* justification in the protocol. If someone could site a class of implementation where there is a real = need for this distinction in an iSER adapter, but as far as I can see the adapters have to be able to translate to TO *anyway* in order to use an RDMA Write or = RDMA Read. Local Interface compatibility with IB can make a *lot* of sense, but why does it have to make its way into the *wire* protocol? -- Caitlin Bestler cait@asomi.com http://www.asomi.com/CaitlinBestlerResume.html From Michael@huaweisymantec.com Thu Jul 14 18:50:33 2011 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 8D03721F87A2 for ; Thu, 14 Jul 2011 18:50:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.877 X-Spam-Level: X-Spam-Status: No, score=-1.877 tagged_above=-999 required=5 tests=[AWL=0.121, BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_46=0.6] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dozTxJ+z8itc for ; Thu, 14 Jul 2011 18:50:29 -0700 (PDT) Received: from mta2.huaweisymantec.com (mta2.huaweisymantec.com [218.17.155.15]) by ietfa.amsl.com (Postfix) with ESMTP id 33D7121F879F for ; Thu, 14 Jul 2011 18:50:24 -0700 (PDT) MIME-version: 1.0 Content-type: multipart/alternative; boundary="Boundary_(ID_rY2at5EF9D90x9YlgSnn5A)" Received: from hstml01-in.huaweisymantec.com ([172.26.3.42]) by hstga02-in.huaweisymantec.com (Sun Java(tm) System Messaging Server 6.3-8.03 (built Apr 24 2009; 32bit)) with ESMTP id <0LOC00MM1QFX9LA0@hstga02-in.huaweisymantec.com> for storm@ietf.org; Fri, 15 Jul 2011 09:50:22 +0800 (CST) Received: from m90003900a ([69.199.248.19]) by hstml01-in.huaweisymantec.com (Sun Java(tm) System Messaging Server 6.3-8.03 (built Apr 24 2009; 32bit)) with ESMTPA id <0LOC008O3QGWS610@hstml01-in.huaweisymantec.com> for storm@ietf.org; Fri, 15 Jul 2011 09:51:03 +0800 (CST) Message-id: From: Michael Ko To: Mallikarjun Chadalapaka , Tom Talpey , 'Caitlin Bestler' References: <971779FD6B314A40B1A3658E521C0D4A@china.huawei.com> <1680F0051D794095A86AF16343CAD400@china.huawei.com> <70CC5C8CCDD74EA0A9CEFF6DDC8145ED@china.huawei.com> Date: Thu, 14 Jul 2011 18:50:12 -0700 X-Priority: 3 X-MSMail-priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.5931 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.6109 Cc: storm@ietf.org Subject: Re: [storm] iSER draft 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, 15 Jul 2011 01:50:33 -0000 This is a multi-part message in MIME format. --Boundary_(ID_rY2at5EF9D90x9YlgSnn5A) Content-type: text/plain; charset=iso-8859-1 Content-transfer-encoding: 7BIT Mallikarjun, Nice to hear from you! I have embedded my comments in your response. Mike ----- Original Message ----- From: Mallikarjun Chadalapaka To: 'Michael Ko' ; Tom Talpey ; 'Caitlin Bestler' Cc: storm@ietf.org Sent: Thursday, July 14, 2011 6:26 PM Subject: RE: [storm] iSER draft I suggest we have to be explicit about the responsibilities of each protocol layer because the phrase "initiator side needs to translate the Tagged Offset" sounds vague to me. [mk] That statement is only meant to convey what would be done by the initiator if it uses address for referencing the buffer rather than using buffer offset to reference the buffer, and the Steering Address is not sent to the target as currently defined in RFC 5046. It does not appear in the spec. Also, it may be worth formalizing the notion of "if Virtual Address was used for this command" via a negotiated connection attribute. [mk] The use of the Steering Address is up to the RCaP. For iWARP, the Steering Address is set to zero. By adding the explanation (as I indicated in my previous note) on how the Tagged Offset is computed from the Steering Address and the Buffer Offset, it is up to the RCaP to determine what they want to do. If I followed this thread right, it seems like we are talking roughly about the following: 1) A shared iSCSI/iSER-level connection attribute (connection-scoped text key?) that indicates whether Steering Address ("Address") or Tagged Offset ("Offset") is required by the RCaP in the RDMA requests on the wire for that connection. How the RCaP API exposes this capability to its local iSER layer is implementation-dependent, and we do not need spec it. [mk] Both the Steering Address and the Tagged Offset will be required. When the Steering Address is set to zero, we have the iWARP mode of behavior as defined in RFC 5046. 2) If the connection attribute = "Offset:, [mk] I don't think a new connection attribute is needed. The RCaP just needs to set the Steering Address to the appropriate value. So for iWARP, set the Steering Address to zero. a) the semantic requirement on the RCaP layer on the initiator is that it treats the incoming RDMA memory references as offsets, and does the appropriate base+offset local translation for RDMA Reads and RDMA Writes. b) The initiator iSER layer must only use ZB-VA, and must set the Steering Address to 0 in appropriate control-type PDUs. c) The target iSER layer must assume that zero TO for the advertised STag points to the beginning of the initiator I/O Buffer in all the RDMA Writes and RDMA Reads that it issues (same as now). 3) If the connection attribute = "Address": a) the semantic requirement on the RCaP layer on the initiator is that it treats incoming RDMA memory references as complete Steering Addresses in RDMA Reads and RDMA Writes. b) The initiator iSER layer must use non-ZB-VA, and must set the Steering Address to the RCaP-API-returned Virtual Address in appropriate control-type PDUs. c) The target iSER layer must assume that the Steering Address for the advertised STag points to the beginning of the initiator I/O Buffer, and compute the Tagged Offset in all the RDMA Writes and RDMA Reads that it issues by adding the Steering Address to the Buffer Offset received from the Data_Descriptor of Datamover API. Mallikarjun From: storm-bounces@ietf.org [mailto:storm-bounces@ietf.org] On Behalf Of Michael Ko Sent: Thursday, July 14, 2011 1:53 PM To: Tom Talpey; Caitlin Bestler Cc: storm@ietf.org Subject: Re: [storm] iSER draft For clarity, I need to update in the next revision of the spec everywhere where "Tagged Offset", "Steering Tag", etc. are mentioned to specify how the Tagged Offset is computed from the "Steering Address" and the buffer offset. So for example, in the example you cited in section 7.3.5, the target computes the Tagged Offset using the Steering Address and the Buffer Offset. For iWARP, the Steering Address is zero, and so the Tagged Offset is the Buffer Offset in the SCSI Data-in PDU as defined in RFC 5046. Mike ----- Original Message ----- From: Tom Talpey To: Michael Ko ; Caitlin Bestler Cc: Alexander Nezhinsky ; storm@ietf.org Sent: Thursday, July 14, 2011 1:16 PM Subject: RE: [storm] iSER draft Changing the name doesn't address the core issues here. There are no processing rules defined in the draft to support the arithmetic you describe below, or even to use the Steering/Virtual Address. For example, section 7.3.5 states the target MUST use the Buffer Offset of the Data-In PDU as the Tagged Offset of an RDMA Write. Where does the new Steering Address in the control PDU header get folded into the Tagged Offset? And what protocol state would trigger the target to do so, including perform the arithmetic? Same question for several other sections. From: Michael Ko [mailto:Michael@huaweisymantec.com] Sent: Thursday, July 14, 2011 2:39 PM To: Caitlin Bestler; Tom Talpey Cc: Alexander Nezhinsky; storm@ietf.org Subject: Re: [storm] iSER draft When "Virtual Address" is not used, as in iWARP, the initiator side needs to translate the "Tagged Offset" which is just the offset into the buffer, into a usable address by adding it to the starting base address of the buffer. If the starting base address is communicated to the target side, as is done in some RCaPs, then the "Tagged Offset" is the usable address itself at the initiator where data is to be fetched or stored. Alex suggested that perhaps we can change the name "Virtual Address" to "Steering Address". Then it can be defined in the glossary without tripping over the common term "virtual address". Mike ----- Original Message ----- From: Caitlin Bestler To: Tom Talpey Cc: Alexander Nezhinsky ; Michael Ko ; storm@ietf.org Sent: Wednesday, July 13, 2011 9:49 PM Subject: Re: [storm] iSER draft On Jul 13, 2011, at 8:12 AM, Tom Talpey wrote: > Yes, understood on the ZBVA/Infiniband issue. Regarding the VA term's presence in an earlier draft, I did not see it in RFC5046 and I did not review the expired draft, so consider these comments to be on the overall change, not the last revision. > > Let me try a different approach to perhaps make myself clearer. > > First, it seems to me that a "virtual address" has no real meaning to the network protocol. It begins, perhaps, as some value in an address space on the initiator, but it's not meaningful on the target in this way, it's only used to request that the remote RNIC perform a transfer to that originally registered remote address. So calling it a Virtual Address as an iSER protocol object seems, to me, an artificial and somewhat leading convention. > > Second, the Virtual Address goes out from the initiator to the target in a Control PDU, but where does it come back? The RDMA Read or Write as depicted in (xx) shows only a Tagged Offset. So, it's not clear what its protocol meaning is. > > Third, I don't ever see a Tagged Buffer described by a fully qualified four-tuple. I see it appearing as either { Stag, TO, length } or { Stag, VA, length }, depending on the addressing mode. > > I think the non-ZBVA mode is really just a special case of the existing one, but where the meaning of TO has changed from a small offset to some other token, generated and managed only at the initiator. So, it seems artificial to define it as distinct, and document it as possessing some new properties. Isn't it just a Target Offset, still? > > Tom. > > I agree, so far we have not seen a protocol justification for the need to add "Virtual Address" to the glossary as something distinct from Target Offset for the purpose of defining an IETF protocol. I am sympathetic to the interoperability issues raised, but I don't think those can justify something that has *no* justification in the protocol. If someone could site a class of implementation where there is a real need for this distinction in an iSER adapter, but as far as I can see the adapters have to be able to translate to TO *anyway* in order to use an RDMA Write or RDMA Read. Local Interface compatibility with IB can make a *lot* of sense, but why does it have to make its way into the *wire* protocol? -- Caitlin Bestler cait@asomi.com http://www.asomi.com/CaitlinBestlerResume.html --Boundary_(ID_rY2at5EF9D90x9YlgSnn5A) Content-type: text/html; charset=iso-8859-1 Content-transfer-encoding: 7BIT
Mallikarjun,
 
Nice to hear from you!
 
I have embedded my comments in your response.
 
Mike
----- Original Message -----
Sent: Thursday, July 14, 2011 6:26 PM
Subject: RE: [storm] iSER draft

I suggest we have to be explicit about the responsibilities of each protocol
layer because the phrase "initiator side needs to translate the Tagged
Offset" sounds vague to me. 
 
[mk] That statement is only meant to convey what would be done by the initiator if it uses address for referencing the buffer rather than using buffer offset to reference the buffer, and the Steering Address is not sent to the target as currently defined in RFC 5046.  It does not appear in the spec.
 
Also, it may be worth formalizing the notion of
"if Virtual Address was used for this command" via a negotiated connection
attribute.
 
[mk] The use of the Steering Address is up to the RCaP.  For iWARP, the Steering Address is set to zero.  By adding the explanation (as I indicated in my previous note) on how the Tagged Offset is computed from the Steering Address and the Buffer Offset, it is up to the RCaP to determine what they want to do.

If I followed this thread right, it seems like we are talking roughly about
the following:

1) A shared iSCSI/iSER-level connection attribute (connection-scoped text
key?) that indicates whether Steering Address ("Address") or Tagged Offset
("Offset") is required by the RCaP in the RDMA requests on the wire for that
connection.  How the RCaP API exposes this capability to its local iSER
layer is implementation-dependent, and we do not need spec it.
 
[mk] Both the Steering Address and the Tagged Offset will be required.  When the Steering Address is set to zero, we have the iWARP mode of behavior as defined in RFC 5046.

2) If the connection attribute = "Offset:,
 
[mk] I don't think a new connection attribute is needed.  The RCaP just needs to set the Steering Address to the appropriate value.  So for iWARP, set the Steering Address to zero.
 
a) the semantic requirement on the RCaP layer on the initiator is
that it treats the incoming RDMA memory references as offsets, and does the
appropriate base+offset local translation for RDMA Reads and RDMA Writes.  
b) The initiator iSER layer must only use ZB-VA, and must set the
Steering Address to 0 in appropriate control-type PDUs.
c) The target iSER layer must assume that zero TO for the advertised
STag points to the beginning of the initiator I/O Buffer in all the RDMA
Writes and RDMA Reads that it issues (same as now).
3) If the connection attribute = "Address":
a)  the semantic requirement on the RCaP layer on the initiator is
that it treats incoming RDMA memory references as complete Steering
Addresses in RDMA Reads and RDMA Writes. 
b) The initiator iSER layer must use non-ZB-VA, and must set the
Steering Address to the RCaP-API-returned Virtual Address in appropriate
control-type PDUs.
c) The target iSER layer must assume that the Steering Address for
the advertised STag points to the beginning of the initiator I/O Buffer, and
compute the Tagged Offset in all the RDMA Writes and RDMA Reads that it
issues by adding the Steering Address to the Buffer Offset received from the
Data_Descriptor of Datamover API.


Mallikarjun

 






From: storm-bounces@ietf.org [mailto:storm-bounces@ietf.org] On Behalf Of
Michael Ko
Sent: Thursday, July 14, 2011 1:53 PM
To: Tom Talpey; Caitlin Bestler
Cc: storm@ietf.org
Subject: Re: [storm] iSER draft

For clarity, I need to update in the next revision of the spec everywhere
where "Tagged Offset", "Steering Tag", etc. are mentioned to specify how the
Tagged Offset is computed from the "Steering Address" and the buffer
offset.

So for example, in the example you cited in section 7.3.5, the target
computes the Tagged Offset using the Steering Address and the Buffer
Offset. For iWARP, the Steering Address is zero, and so the Tagged Offset
is the Buffer Offset in the SCSI Data-in PDU as defined in RFC 5046.

Mike
----- Original Message -----
From: Tom Talpey
To: Michael Ko ; Caitlin Bestler
Cc: Alexander Nezhinsky ; storm@ietf.org
Sent: Thursday, July 14, 2011 1:16 PM
Subject: RE: [storm] iSER draft

Changing the name doesn't address the core issues here. There are no
processing rules defined in the draft to support the arithmetic you describe
below, or even to use the Steering/Virtual Address.

For example, section 7.3.5 states the target MUST use the Buffer Offset of
the Data-In PDU as the Tagged Offset of an RDMA Write. Where does the new
Steering Address in the control PDU header get folded into the Tagged
Offset? And what protocol state would trigger the target to do so, including
perform the arithmetic? Same question for several other sections.



From: Michael Ko [mailto:Michael@huaweisymantec.com]
Sent: Thursday, July 14, 2011 2:39 PM
To: Caitlin Bestler; Tom Talpey
Cc: Alexander Nezhinsky; storm@ietf.org
Subject: Re: [storm] iSER draft

When "Virtual Address" is not used, as in iWARP, the initiator side needs to
translate the "Tagged Offset" which is just the offset into the buffer, into
a usable address by adding it to the starting base address of the buffer.
If the starting base address is communicated to the target side, as is done
in some RCaPs, then the "Tagged Offset" is the usable address itself at the
initiator where data is to be fetched or stored. Alex suggested that
perhaps we can change the name "Virtual Address" to "Steering Address".
Then it can be defined in the glossary without tripping over the common term
"virtual address".

Mike
----- Original Message -----
From: Caitlin Bestler
To: Tom Talpey
Cc: Alexander Nezhinsky ; Michael Ko ; storm@ietf.org
Sent: Wednesday, July 13, 2011 9:49 PM
Subject: Re: [storm] iSER draft


On Jul 13, 2011, at 8:12 AM, Tom Talpey wrote:

> Yes, understood on the ZBVA/Infiniband issue. Regarding the VA term's
presence in an earlier draft, I did not see it in RFC5046 and I did not
review the expired draft, so consider these comments to be on the overall
change, not the last revision.
>
> Let me try a different approach to perhaps make myself clearer.
>
> First, it seems to me that a "virtual address" has no real meaning to the
network protocol. It begins, perhaps, as some value in an address space on
the initiator, but it's not meaningful on the target in this way, it's only
used to request that the remote RNIC perform a transfer to that originally
registered remote address. So calling it a Virtual Address as an iSER
protocol object seems, to me, an artificial and somewhat leading convention.
>
> Second, the Virtual Address goes out from the initiator to the target in a
Control PDU, but where does it come back? The RDMA Read or Write as depicted
in (xx) shows only a Tagged Offset. So, it's not clear what its protocol
meaning is.
>
> Third, I don't ever see a Tagged Buffer described by a fully qualified
four-tuple. I see it appearing as either { Stag, TO, length } or { Stag, VA,
length }, depending on the addressing mode.
>
> I think the non-ZBVA mode is really just a special case of the existing
one, but where the meaning of TO has changed from a small offset to some
other token, generated and managed only at the initiator. So, it seems
artificial to define it as distinct, and document it as possessing some new
properties. Isn't it just a Target Offset, still?
>
> Tom.
>
>

I agree, so far we have not seen a protocol justification for the need to
add "Virtual Address" to the glossary as something distinct from Target
Offset
for the purpose of defining an IETF protocol.

I am sympathetic to the interoperability issues raised, but I don't think
those can justify something that has *no* justification in the protocol.

If someone could site a class of implementation where there is a real need
for this distinction in an iSER adapter, but as far as I can see the
adapters have
to be able to translate to TO *anyway* in order to use an RDMA Write or RDMA
Read.

Local Interface compatibility with IB can make a *lot* of sense, but why
does it have to make its way into the *wire* protocol?

--
Caitlin Bestler
cait@asomi.com
http://www.asomi.com/CaitlinBestlerResume.html


--Boundary_(ID_rY2at5EF9D90x9YlgSnn5A)-- From ttalpey@microsoft.com Fri Jul 15 11:16:45 2011 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 EFF8221F8B61 for ; Fri, 15 Jul 2011 11:16:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.298 X-Spam-Level: X-Spam-Status: No, score=-110.298 tagged_above=-999 required=5 tests=[AWL=-0.300, BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_46=0.6, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id nG-sOhmy4rRr for ; Fri, 15 Jul 2011 11:16:39 -0700 (PDT) Received: from smtp.microsoft.com (smtp.microsoft.com [131.107.115.215]) by ietfa.amsl.com (Postfix) with ESMTP id 5366021F8B44 for ; Fri, 15 Jul 2011 11:16:39 -0700 (PDT) Received: from TK5EX14HUBC102.redmond.corp.microsoft.com (157.54.7.154) by TK5-EXGWY-E802.partners.extranet.microsoft.com (10.251.56.168) with Microsoft SMTP Server (TLS) id 8.2.176.0; Fri, 15 Jul 2011 11:16:38 -0700 Received: from TK5EX14MBXC111.redmond.corp.microsoft.com ([169.254.2.64]) by TK5EX14HUBC102.redmond.corp.microsoft.com ([157.54.7.154]) with mapi id 14.01.0323.002; Fri, 15 Jul 2011 11:16:38 -0700 From: Tom Talpey To: Michael Ko , Mallikarjun Chadalapaka , 'Caitlin Bestler' Thread-Topic: [storm] iSER draft Thread-Index: AQHMNlPpov6tD7xTq0WTfzkPhGmP2JTUcDZAgABph/mAAdAuAIATxsXggAFa2ACAAHJheIAAD/iAgAAmeC+AALC4gP//kWlMgAEM23A= Date: Fri, 15 Jul 2011 18:16:38 +0000 Message-ID: References: <971779FD6B314A40B1A3658E521C0D4A@china.huawei.com> <1680F0051D794095A86AF16343CAD400@china.huawei.com> <70CC5C8CCDD74EA0A9CEFF6DDC8145ED@china.huawei.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [157.54.51.36] Content-Type: multipart/alternative; boundary="_000_F83812DF4B59B9499C1BC978336D91745EE03EADTK5EX14MBXC111r_" MIME-Version: 1.0 Cc: "storm@ietf.org" Subject: Re: [storm] iSER draft 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, 15 Jul 2011 18:16:46 -0000 --_000_F83812DF4B59B9499C1BC978336D91745EE03EADTK5EX14MBXC111r_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable This discussion is starting to fork, but I'll do my best to reply to the to= p of the thread. I'm glad we're making progress, but I don't think we're on the same page ye= t. In particular, I disagree with your statement that "for iWARP, the Steer= ing Address is set to zero." The choice of addressing mode is not made on a= per-protocol basis, it is a local issue on the initiator. If ZBVA mode is = used, then the addressing mode is zero-based. However local verbs support s= everal other modes, and the "steering address" is not at all constrained to= be an "address". Depending on several factors, it can be a virtual address= , a physical address, or a completely arbitrary value. To my reading, the new draft is proposing that an additional value be sent = in the Control PDU header, to be added to the BufferOffset of the individua= l SCSI control PDU payload when the target performs RDMA Read or RDMA Write= . To me, this value is not an address, and has no semantics beyond being an= initiator-provided value needed to direct the expected RDMA, when it is pe= rformed by the target. Personally, I think it would be better defined as a = "Base Offset", or "Tagged Base Offset", to which the BufferOffset is added = to form the resulting TaggedOffset. There's no further requirement than to = have the two values to add together. I think that any proposed addition of a connection attribute for "iWARP" or= "offset" to the normative discussion is incorrect, for the reasons above. = While it's true that iWARP may support addressing modes that another RDMA p= rotocol may not, it's neither necessary or desirable to require iSER or iSC= SI to change behavior depending on the lower RDMA layer. iSER is appropriat= ely a transport adaptation layer, and should be defined in such a way as to= be agnostic to the needs of the lower layer. So again, I would like to see: - Virtual Address renamed to agnostic term (perhaps) Base Offset - Clearly stated processing at the target to compute the necessary= TaggedOffset - Avoidance of discussion of addressing mode requirements or local= verb semantics. From: Michael Ko [mailto:Michael@huaweisymantec.com] Sent: Thursday, July 14, 2011 9:50 PM To: Mallikarjun Chadalapaka; Tom Talpey; 'Caitlin Bestler' Cc: storm@ietf.org Subject: Re: [storm] iSER draft Mallikarjun, Nice to hear from you! I have embedded my comments in your response. Mike ----- Original Message ----- From: Mallikarjun Chadalapaka To: 'Michael Ko' ; Tom Talpey ; 'Caitlin Bestler' Cc: storm@ietf.org Sent: Thursday, July 14, 2011 6:26 PM Subject: RE: [storm] iSER draft I suggest we have to be explicit about the responsibilities of each protoco= l layer because the phrase "initiator side needs to translate the Tagged Offset" sounds vague to me. [mk] That statement is only meant to convey what would be done by the initi= ator if it uses address for referencing the buffer rather than using buffer= offset to reference the buffer, and the Steering Address is not sent to th= e target as currently defined in RFC 5046. It does not appear in the spec. Also, it may be worth formalizing the notion of "if Virtual Address was used for this command" via a negotiated connection attribute. [mk] The use of the Steering Address is up to the RCaP. For iWARP, the Ste= ering Address is set to zero. By adding the explanation (as I indicated in= my previous note) on how the Tagged Offset is computed from the Steering A= ddress and the Buffer Offset, it is up to the RCaP to determine what they w= ant to do. If I followed this thread right, it seems like we are talking roughly about the following: 1) A shared iSCSI/iSER-level connection attribute (connection-scoped text key?) that indicates whether Steering Address ("Address") or Tagged Offset ("Offset") is required by the RCaP in the RDMA requests on the wire for tha= t connection. How the RCaP API exposes this capability to its local iSER layer is implementation-dependent, and we do not need spec it. [mk] Both the Steering Address and the Tagged Offset will be required. Whe= n the Steering Address is set to zero, we have the iWARP mode of behavior a= s defined in RFC 5046. 2) If the connection attribute =3D "Offset:, [mk] I don't think a new connection attribute is needed. The RCaP just nee= ds to set the Steering Address to the appropriate value. So for iWARP, set= the Steering Address to zero. a) the semantic requirement on the RCaP layer on the initiator is that it treats the incoming RDMA memory references as offsets, and does the appropriate base+offset local translation for RDMA Reads and RDMA Writes. b) The initiator iSER layer must only use ZB-VA, and must set the Steering Address to 0 in appropriate control-type PDUs. c) The target iSER layer must assume that zero TO for the advertised STag points to the beginning of the initiator I/O Buffer in all the RDMA Writes and RDMA Reads that it issues (same as now). 3) If the connection attribute =3D "Address": a) the semantic requirement on the RCaP layer on the initiator is that it treats incoming RDMA memory references as complete Steering Addresses in RDMA Reads and RDMA Writes. b) The initiator iSER layer must use non-ZB-VA, and must set the Steering Address to the RCaP-API-returned Virtual Address in appropriate control-type PDUs. c) The target iSER layer must assume that the Steering Address for the advertised STag points to the beginning of the initiator I/O Buffer, an= d compute the Tagged Offset in all the RDMA Writes and RDMA Reads that it issues by adding the Steering Address to the Buffer Offset received from th= e Data_Descriptor of Datamover API. Mallikarjun From: storm-bounces@ietf.org [mailto:storm-b= ounces@ietf.org] On Behalf Of Michael Ko Sent: Thursday, July 14, 2011 1:53 PM To: Tom Talpey; Caitlin Bestler Cc: storm@ietf.org Subject: Re: [storm] iSER draft For clarity, I need to update in the next revision of the spec everywhere where "Tagged Offset", "Steering Tag", etc. are mentioned to specify how th= e Tagged Offset is computed from the "Steering Address" and the buffer offset. So for example, in the example you cited in section 7.3.5, the target computes the Tagged Offset using the Steering Address and the Buffer Offset. For iWARP, the Steering Address is zero, and so the Tagged Offset is the Buffer Offset in the SCSI Data-in PDU as defined in RFC 5046. Mike ----- Original Message ----- From: Tom Talpey To: Michael Ko ; Caitlin Bestler Cc: Alexander Nezhinsky ; storm@ietf.org Sent: Thursday, July 14, 2011 1:16 PM Subject: RE: [storm] iSER draft Changing the name doesn't address the core issues here. There are no processing rules defined in the draft to support the arithmetic you describ= e below, or even to use the Steering/Virtual Address. For example, section 7.3.5 states the target MUST use the Buffer Offset of the Data-In PDU as the Tagged Offset of an RDMA Write. Where does the new Steering Address in the control PDU header get folded into the Tagged Offset? And what protocol state would trigger the target to do so, includin= g perform the arithmetic? Same question for several other sections. From: Michael Ko [mailto:Michael@huaweisymantec.com] Sent: Thursday, July 14, 2011 2:39 PM To: Caitlin Bestler; Tom Talpey Cc: Alexander Nezhinsky; storm@ietf.org Subject: Re: [storm] iSER draft When "Virtual Address" is not used, as in iWARP, the initiator side needs t= o translate the "Tagged Offset" which is just the offset into the buffer, int= o a usable address by adding it to the starting base address of the buffer. If the starting base address is communicated to the target side, as is done in some RCaPs, then the "Tagged Offset" is the usable address itself at the initiator where data is to be fetched or stored. Alex suggested that perhaps we can change the name "Virtual Address" to "Steering Address". Then it can be defined in the glossary without tripping over the common ter= m "virtual address". Mike ----- Original Message ----- From: Caitlin Bestler To: Tom Talpey Cc: Alexander Nezhinsky ; Michael Ko ; storm@ietf.org Sent: Wednesday, July 13, 2011 9:49 PM Subject: Re: [storm] iSER draft On Jul 13, 2011, at 8:12 AM, Tom Talpey wrote: > Yes, understood on the ZBVA/Infiniband issue. Regarding the VA term's presence in an earlier draft, I did not see it in RFC5046 and I did not review the expired draft, so consider these comments to be on the overall change, not the last revision. > > Let me try a different approach to perhaps make myself clearer. > > First, it seems to me that a "virtual address" has no real meaning to the network protocol. It begins, perhaps, as some value in an address space on the initiator, but it's not meaningful on the target in this way, it's only used to request that the remote RNIC perform a transfer to that originally registered remote address. So calling it a Virtual Address as an iSER protocol object seems, to me, an artificial and somewhat leading convention= . > > Second, the Virtual Address goes out from the initiator to the target in = a Control PDU, but where does it come back? The RDMA Read or Write as depicte= d in (xx) shows only a Tagged Offset. So, it's not clear what its protocol meaning is. > > Third, I don't ever see a Tagged Buffer described by a fully qualified four-tuple. I see it appearing as either { Stag, TO, length } or { Stag, VA= , length }, depending on the addressing mode. > > I think the non-ZBVA mode is really just a special case of the existing one, but where the meaning of TO has changed from a small offset to some other token, generated and managed only at the initiator. So, it seems artificial to define it as distinct, and document it as possessing some new properties. Isn't it just a Target Offset, still? > > Tom. > > I agree, so far we have not seen a protocol justification for the need to add "Virtual Address" to the glossary as something distinct from Target Offset for the purpose of defining an IETF protocol. I am sympathetic to the interoperability issues raised, but I don't think those can justify something that has *no* justification in the protocol. If someone could site a class of implementation where there is a real need for this distinction in an iSER adapter, but as far as I can see the adapters have to be able to translate to TO *anyway* in order to use an RDMA Write or RDM= A Read. Local Interface compatibility with IB can make a *lot* of sense, but why does it have to make its way into the *wire* protocol? -- Caitlin Bestler cait@asomi.com http://www.asomi.com/CaitlinBestlerResume.html --_000_F83812DF4B59B9499C1BC978336D91745EE03EADTK5EX14MBXC111r_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

This discussion is starti= ng to fork, but I’ll do my best to reply to the top of the thread.

 <= /p>

I’m glad we’r= e making progress, but I don’t think we’re on the same page yet= . In particular, I disagree with your statement that “for iWARP, the = Steering Address is set to zero.” The choice of addressing mode is not made on a per-= protocol basis, it is a local issue on the initiator. If ZBVA mode is used,= then the addressing mode is zero-based. However local verbs support severa= l other modes, and the “steering address” is not at all constrained to be an “address”. Depending on sev= eral factors, it can be a virtual address, a physical address, or a complet= ely arbitrary value.

 <= /p>

To my reading, the new dr= aft is proposing that an additional value be sent in the Control PDU header= , to be added to the BufferOffset of the individual SCSI control PDU payload when the target performs RDMA Read or RDMA Write. To m= e, this value is not an address, and has no semantics beyond being an initi= ator-provided value needed to direct the expected RDMA, when it is performe= d by the target. Personally, I think it would be better defined as a “Base Offset”, or “Tagge= d Base Offset”, to which the BufferOffset is added to form the result= ing TaggedOffset. There’s no further requirement than to have the two= values to add together.

 <= /p>

I think that any proposed= addition of a connection attribute for “iWARP” or “offse= t” to the normative discussion is incorrect, for the reasons above. W= hile it’s true that iWARP may support addressing modes that another RDMA = protocol may not, it’s neither necessary or desirable to require iSER= or iSCSI to change behavior depending on the lower RDMA layer. iSER is app= ropriately a transport adaptation layer, and should be defined in such a way as to be agnostic to the needs of the lowe= r layer.

 <= /p>

So again, I would like to= see:

- =          Virtual Address r= enamed to agnostic term (perhaps) Base Offset

- =          Clearly stated pr= ocessing at the target to compute the necessary TaggedOffset

- =          Avoidance of disc= ussion of addressing mode requirements or local verb semantics.<= /span>

 <= /p>

From: Michael = Ko [mailto:Michael@huaweisymantec.com]
Sent: Thursday, July 14, 2011 9:50 PM
To: Mallikarjun Chadalapaka; Tom Talpey; 'Caitlin Bestler'
Cc: storm@ietf.org
Subject: Re: [storm] iSER draft

 

Mallikarjun,=

 

Nice to hear from y= ou!

 

I have embedded my = comments in your response.

 

Mike

----- Original Message -----

Sent: Thursday, = July 14, 2011 6:26 PM

Subject: RE: [st= orm] iSER draft

 

I suggest we have to be explicit about the responsib= ilities of each protocol
layer because the phrase "initiator side needs to translate the Tagged=
Offset" sounds vague to me. 

 

[mk] That statement= is only meant to convey what would be done by the initiator if it use= s address for referencing the buffer rather than using buffer offset to ref= erence the buffer, and the Steering Address is not sent to the target as currently defined in RFC 5046.  It does = not appear in the spec.

 

Also, it may be worth formalizing the notion of
"if Virtual Address was used for this command" via a negotiated c= onnection
attribute.

 

[mk] The use of the= Steering Address is up to the RCaP.  For iWARP, the Steering Address = is set to zero.  By adding the explanation (as I indicated in my previ= ous note) on how the Tagged Offset is computed from the Steering Address and the Buffer Offset, it is up to the RCaP to d= etermine what they want to do.

If I followed this thread right, it seems like we are talking roughly about=
the following:

1) A shared iSCSI/iSER-level connection attribute (connection-scoped text key?) that indicates whether Steering Address ("Address") or Tagg= ed Offset
("Offset") is required by the RCaP in the RDMA requests on the wi= re for that
connection.  How the RCaP API exposes this capability to its local iSE= R
layer is implementation-dependent, and we do not need spec it.

 

[mk] Both the Steer= ing Address and the Tagged Offset will be required.  When the Steering= Address is set to zero, we have the iWARP mode of behavior as defined in R= FC 5046.

2) If the connection attribute =3D "Offset:,

 

[mk] I don't think a new connection attribute i= s needed.  The RCaP just needs to set the Steering Address to the appr= opriate value.  So for iWARP, set the Steering Address to zero.

 
a) the semantic requirement on the RCaP layer on the initiator is
that it treats the incoming RDMA memory references as offsets, and does the=
appropriate base+offset local translation for RDMA Reads and RDMA Write= s.  
b) The initiator iSER layer must only use ZB-VA, and must set the
Steering Address to 0 in appropriate control-type PDUs.

c) The target iSER layer must assume that zero TO fo= r the advertised
STag points to the beginning of the initiator I/O Buffer in all the RDMA Writes and RDMA Reads that it issues (same as now).

3) If the connection = attribute =3D "Address":
a)  the semantic requirement on the RCaP layer on the initiator is
that it treats incoming RDMA memory references as complete Steering
Addresses in RDMA Reads and RDMA Writes. 
b) The initiator iSER layer must use non-ZB-VA, and must set the
Steering Address to the RCaP-API-returned Virtual Address in appropriate control-type PDUs.
c) The target iSER layer must assume that the Steering Address for
the advertised STag points to the beginning of the initiator I/O Buffer, an= d
compute the Tagged Offset in all the RDMA Writes and RDMA Reads that it
issues by adding the Steering Address to the Buffer Offset received from th= e
Data_Descriptor of Datamover API.


Mallikarjun

 






From: storm-bounces@ietf.org = [mailto:storm-bounces@ietf.org] On Behalf Of
Michael Ko
Sent: Thursday, July 14, 2011 1:53 PM
To: Tom Talpey; Caitlin Bestler
Cc: storm@ietf.org
Subject: Re: [storm] iSER draft

For clarity, I need to update in the next revision of the spec everywhere where "Tagged Offset", "Steering Tag", etc. are mention= ed to specify how the
Tagged Offset is computed from the "Steering Address" and the buf= fer
offset.

So for example, in the example you cited in section 7.3.5, the target
computes the Tagged Offset using the Steering Address and the Buffer
Offset. For iWARP, the Steering Address is zero, and so the Tagged Offset is the Buffer Offset in the SCSI Data-in PDU as defined in RFC 5046.

Mike
----- Original Message -----
From: Tom Talpey
To: Michael Ko ; Caitlin Bestler
Cc: Alexander Nezhinsky ; storm@ietf.org<= /a>
Sent: Thursday, July 14, 2011 1:16 PM
Subject: RE: [storm] iSER draft

Changing the name doesn't address the core issues here. There are no
processing rules defined in the draft to support the arithmetic you describ= e
below, or even to use the Steering/Virtual Address.

For example, section 7.3.5 states the target MUST use the Buffer Offset of<= br> the Data-In PDU as the Tagged Offset of an RDMA Write. Where does the new Steering Address in the control PDU header get folded into the Tagged
Offset? And what protocol state would trigger the target to do so, includin= g
perform the arithmetic? Same question for several other sections.



From: Michael Ko [ma= ilto:Michael@huaweisymantec.com]
Sent: Thursday, July 14, 2011 2:39 PM
To: Caitlin Bestler; Tom Talpey
Cc: Alexander Nezhinsky; storm@ietf.org
Subject: Re: [storm] iSER draft

When "Virtual Address" is not used, as in iWARP, the initiator si= de needs to
translate the "Tagged Offset" which is just the offset into the b= uffer, into
a usable address by adding it to the starting base address of the buffer. <= br> If the starting base address is communicated to the target side, as is done=
in some RCaPs, then the "Tagged Offset" is the usable address its= elf at the
initiator where data is to be fetched or stored. Alex suggested that
perhaps we can change the name "Virtual Address" to "Steerin= g Address".
Then it can be defined in the glossary without tripping over the common ter= m
"virtual address".

Mike
----- Original Message -----
From: Caitlin Bestler
To: Tom Talpey
Cc: Alexander Nezhinsky ; Michael Ko ; st= orm@ietf.org
Sent: Wednesday, July 13, 2011 9:49 PM
Subject: Re: [storm] iSER draft


On Jul 13, 2011, at 8:12 AM, Tom Talpey wrote:

> Yes, understood on the ZBVA/Infiniband issue. Regarding the VA term's<= br> presence in an earlier draft, I did not see it in RFC5046 and I did not
review the expired draft, so consider these comments to be on the overall change, not the last revision.
>
> Let me try a different approach to perhaps make myself clearer.
>
> First, it seems to me that a "virtual address" has no real m= eaning to the
network protocol. It begins, perhaps, as some value in an address space on<= br> the initiator, but it's not meaningful on the target in this way, it's only=
used to request that the remote RNIC perform a transfer to that originally<= br> registered remote address. So calling it a Virtual Address as an iSER
protocol object seems, to me, an artificial and somewhat leading convention= .
>
> Second, the Virtual Address goes out from the initiator to the target = in a
Control PDU, but where does it come back? The RDMA Read or Write as depicte= d
in (xx) shows only a Tagged Offset. So, it's not clear what its protocol meaning is.
>
> Third, I don't ever see a Tagged Buffer described by a fully qualified=
four-tuple. I see it appearing as either { Stag, TO, length } or { Stag, VA= ,
length }, depending on the addressing mode.
>
> I think the non-ZBVA mode is really just a special case of the existin= g
one, but where the meaning of TO has changed from a small offset to some other token, generated and managed only at the initiator. So, it seems
artificial to define it as distinct, and document it as possessing some new=
properties. Isn't it just a Target Offset, still?
>
> Tom.
>
>

I agree, so far we have not seen a protocol justification for the need to add "Virtual Address" to the glossary as something distinct from = Target
Offset
for the purpose of defining an IETF protocol.

I am sympathetic to the interoperability issues raised, but I don't think those can justify something that has *no* justification in the protocol.
If someone could site a class of implementation where there is a real need<= br> for this distinction in an iSER adapter, but as far as I can see the
adapters have
to be able to translate to TO *anyway* in order to use an RDMA Write or RDM= A
Read.

Local Interface compatibility with IB can make a *lot* of sense, but why does it have to make its way into the *wire* protocol?

--
Caitlin Bestler
cait@asomi.com
http://www.asomi= .com/CaitlinBestlerResume.html

--_000_F83812DF4B59B9499C1BC978336D91745EE03EADTK5EX14MBXC111r_-- From cbm@chadalapaka.com Fri Jul 15 11:21:21 2011 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 E950D21F8B7F for ; Fri, 15 Jul 2011 11:21:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.224 X-Spam-Level: X-Spam-Status: No, score=-2.224 tagged_above=-999 required=5 tests=[AWL=-0.225, BAYES_00=-2.599, J_CHICKENPOX_46=0.6] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lvCVt6EEUDSu for ; Fri, 15 Jul 2011 11:21:21 -0700 (PDT) Received: from snt0-omc1-s4.snt0.hotmail.com (snt0-omc1-s4.snt0.hotmail.com [65.55.90.15]) by ietfa.amsl.com (Postfix) with ESMTP id E68B821F8B7E for ; Fri, 15 Jul 2011 11:21:20 -0700 (PDT) Received: from SNT131-DS13 ([65.55.90.8]) by snt0-omc1-s4.snt0.hotmail.com with Microsoft SMTPSVC(6.0.3790.4675); Fri, 15 Jul 2011 11:21:20 -0700 X-Originating-IP: [131.107.0.94] X-Originating-Email: [cbm@chadalapaka.com] Message-ID: From: Mallikarjun Chadalapaka To: "'Michael Ko'" , "Tom Talpey" , "'Caitlin Bestler'" References: <971779FD6B314A40B1A3658E521C0D4A@china.huawei.com> <1680F0051D794095A86AF16343CAD400@china.huawei.com> <70CC5C8CCDD74EA0A9CEFF6DDC8145ED@china.huawei.com> In-Reply-To: Date: Fri, 15 Jul 2011 11:21:16 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQIwSeqJJoVLyHMsNGW+iMTc16Ka+AD+40JOArGQ7j4BoviyegGIyVhfA1WikwgAjxH9YgF8HPDwAkrFNGkBgNblZQLgBWmrk45PnuA= Content-Language: en-us X-OriginalArrivalTime: 15 Jul 2011 18:21:20.0823 (UTC) FILETIME=[FEFF6470:01CC431B] Cc: storm@ietf.org Subject: Re: [storm] iSER draft 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, 15 Jul 2011 18:21:22 -0000 Hi Mike, A few responses to your comments, :) >[mk] The use of the Steering Address is up to the RCaP. Understood. But iSER layer has differing protocol requirements (see my bullets 2-b-c, 3-b-c), keyed to RCaP semantics. So IMHO, it would be useful to formally spec these differences and relate them to an iSER-level protocol parameter. >[mk] Both the Steering Address and the Tagged Offset will be required. Sure, I agree for control-type PDUs. That's the reason I said (emphasis added) " Steering Address ("Address") or Tagged Offset ("Offset") is required by the RCaP in the *RDMA requests*." RDMA Reads/Writes generated due to iSCSI Data-type PDUs contain only one 64-bit reference - for iWARP, it is an Offset when used with ZB-VA; for IB, it's a full Virtual Address (although I am not an IB-expert, that's what I understand so far) >[mk] I don't think a new connection attribute is needed. While adding clarification text in several places in the draft might address the issue that Tom pointed out, I think a formal iSCSI or iSER state variable (either through text key negotiation or iSER Hello negotiation) gives a hook for you to hang those semantics off of in a formal way - both to spec, and validate wire protocol behavior for compliance later on. E.g., let's say the attribute name is "Reference Type" with 0 - for Address, and 1 for Offset, you could say "When the operational Reference Type is 1 for the connection, initiator iSER layer MUST.....". Finally, this is probably better modeled as an iSER Hello parameter rather than iSCSI text key, to minimize layer "rototilling". For the RCaP that does not have a Hello negotiation (e.g. IB), you could specify in the spec that Reference Type=0 is the default iSER behavior. My 0.02. Mallikarjun > >From: Michael Ko [mailto:Michael@huaweisymantec.com] >Sent: Thursday, July 14, 2011 6:50 PM >To: Mallikarjun Chadalapaka; Tom Talpey; 'Caitlin Bestler' >Cc: storm@ietf.org >Subject: Re: [storm] iSER draft > >Mallikarjun, > >Nice to hear from you! > >I have embedded my comments in your response. > >Mike >----- Original Message ----- >From: Mallikarjun Chadalapaka >To: 'Michael Ko' ; Tom Talpey ; 'Caitlin Bestler' >Cc: storm@ietf.org >Sent: Thursday, July 14, 2011 6:26 PM >Subject: RE: [storm] iSER draft > >I suggest we have to be explicit about the responsibilities of each protocol >layer because the phrase "initiator side needs to translate the Tagged >Offset" sounds vague to me. > >[mk] That statement is only meant to convey what would be done by the initiator if it uses address for referencing the buffer rather than using buffer offset to reference the buffer, and the Steering Address is not sent to the target as currently defined in RFC 5046. It does not appear in the spec. > >Also, it may be worth formalizing the notion of >"if Virtual Address was used for this command" via a negotiated connection >attribute. > >[mk] The use of the Steering Address is up to the RCaP. For iWARP, the Steering Address is set to zero. By adding the explanation (as I indicated in my previous note) on how the Tagged Offset is computed from the Steering Address and the Buffer Offset, it is up to the RCaP to determine what they want to do. > >If I followed this thread right, it seems like we are talking roughly about >the following: > >1) A shared iSCSI/iSER-level connection attribute (connection-scoped text >key?) that indicates whether Steering Address ("Address") or Tagged Offset >("Offset") is required by the RCaP in the RDMA requests on the wire for that >connection. How the RCaP API exposes this capability to its local iSER >layer is implementation-dependent, and we do not need spec it. > >[mk] Both the Steering Address and the Tagged Offset will be required. When the Steering Address is set to zero, we have the iWARP mode of behavior as defined in RFC 5046. > >2) If the connection attribute = "Offset:, > >[mk] I don't think a new connection attribute is needed. The RCaP just needs to set the Steering Address to the appropriate value. So for iWARP, set the Steering Address to zero. > >a) the semantic requirement on the RCaP layer on the initiator is >that it treats the incoming RDMA memory references as offsets, and does the >appropriate base+offset local translation for RDMA Reads and RDMA Writes. >b) The initiator iSER layer must only use ZB-VA, and must set the >Steering Address to 0 in appropriate control-type PDUs. >c) The target iSER layer must assume that zero TO for the advertised >STag points to the beginning of the initiator I/O Buffer in all the RDMA >Writes and RDMA Reads that it issues (same as now). >3) If the connection attribute = "Address": >a) the semantic requirement on the RCaP layer on the initiator is >that it treats incoming RDMA memory references as complete Steering >Addresses in RDMA Reads and RDMA Writes. >b) The initiator iSER layer must use non-ZB-VA, and must set the >Steering Address to the RCaP-API-returned Virtual Address in appropriate >control-type PDUs. >c) The target iSER layer must assume that the Steering Address for >the advertised STag points to the beginning of the initiator I/O Buffer, and >compute the Tagged Offset in all the RDMA Writes and RDMA Reads that it >issues by adding the Steering Address to the Buffer Offset received from the >Data_Descriptor of Datamover API. > > >Mallikarjun > > > > > > > > >From: storm-bounces@ietf.org [mailto:storm-bounces@ietf.org] On Behalf Of >Michael Ko >Sent: Thursday, July 14, 2011 1:53 PM >To: Tom Talpey; Caitlin Bestler >Cc: storm@ietf.org >Subject: Re: [storm] iSER draft > >For clarity, I need to update in the next revision of the spec everywhere >where "Tagged Offset", "Steering Tag", etc. are mentioned to specify how the >Tagged Offset is computed from the "Steering Address" and the buffer >offset. > >So for example, in the example you cited in section 7.3.5, the target >computes the Tagged Offset using the Steering Address and the Buffer >Offset. For iWARP, the Steering Address is zero, and so the Tagged Offset >is the Buffer Offset in the SCSI Data-in PDU as defined in RFC 5046. > >Mike >----- Original Message ----- >From: Tom Talpey >To: Michael Ko ; Caitlin Bestler >Cc: Alexander Nezhinsky ; storm@ietf.org >Sent: Thursday, July 14, 2011 1:16 PM >Subject: RE: [storm] iSER draft > >Changing the name doesn't address the core issues here. There are no >processing rules defined in the draft to support the arithmetic you describe >below, or even to use the Steering/Virtual Address. > >For example, section 7.3.5 states the target MUST use the Buffer Offset of >the Data-In PDU as the Tagged Offset of an RDMA Write. Where does the new >Steering Address in the control PDU header get folded into the Tagged >Offset? And what protocol state would trigger the target to do so, including >perform the arithmetic? Same question for several other sections. > > > >From: Michael Ko [mailto:Michael@huaweisymantec.com] >Sent: Thursday, July 14, 2011 2:39 PM >To: Caitlin Bestler; Tom Talpey >Cc: Alexander Nezhinsky; storm@ietf.org >Subject: Re: [storm] iSER draft > >When "Virtual Address" is not used, as in iWARP, the initiator side needs to >translate the "Tagged Offset" which is just the offset into the buffer, into >a usable address by adding it to the starting base address of the buffer. >If the starting base address is communicated to the target side, as is done >in some RCaPs, then the "Tagged Offset" is the usable address itself at the >initiator where data is to be fetched or stored. Alex suggested that >perhaps we can change the name "Virtual Address" to "Steering Address". >Then it can be defined in the glossary without tripping over the common term >"virtual address". > >Mike >----- Original Message ----- >From: Caitlin Bestler >To: Tom Talpey >Cc: Alexander Nezhinsky ; Michael Ko ; storm@ietf.org >Sent: Wednesday, July 13, 2011 9:49 PM >Subject: Re: [storm] iSER draft > > >On Jul 13, 2011, at 8:12 AM, Tom Talpey wrote: > >> Yes, understood on the ZBVA/Infiniband issue. Regarding the VA term's >presence in an earlier draft, I did not see it in RFC5046 and I did not >review the expired draft, so consider these comments to be on the overall >change, not the last revision. >> >> Let me try a different approach to perhaps make myself clearer. >> >> First, it seems to me that a "virtual address" has no real meaning to the >network protocol. It begins, perhaps, as some value in an address space on >the initiator, but it's not meaningful on the target in this way, it's only >used to request that the remote RNIC perform a transfer to that originally >registered remote address. So calling it a Virtual Address as an iSER >protocol object seems, to me, an artificial and somewhat leading convention. >> >> Second, the Virtual Address goes out from the initiator to the target in a >Control PDU, but where does it come back? The RDMA Read or Write as depicted >in (xx) shows only a Tagged Offset. So, it's not clear what its protocol >meaning is. >> >> Third, I don't ever see a Tagged Buffer described by a fully qualified >four-tuple. I see it appearing as either { Stag, TO, length } or { Stag, VA, >length }, depending on the addressing mode. >> >> I think the non-ZBVA mode is really just a special case of the existing >one, but where the meaning of TO has changed from a small offset to some >other token, generated and managed only at the initiator. So, it seems >artificial to define it as distinct, and document it as possessing some new >properties. Isn't it just a Target Offset, still? >> >> Tom. >> >> > >I agree, so far we have not seen a protocol justification for the need to >add "Virtual Address" to the glossary as something distinct from Target >Offset >for the purpose of defining an IETF protocol. > >I am sympathetic to the interoperability issues raised, but I don't think >those can justify something that has *no* justification in the protocol. > >If someone could site a class of implementation where there is a real need >for this distinction in an iSER adapter, but as far as I can see the >adapters have >to be able to translate to TO *anyway* in order to use an RDMA Write or RDMA >Read. > >Local Interface compatibility with IB can make a *lot* of sense, but why >does it have to make its way into the *wire* protocol? > >-- >Caitlin Bestler >cait@asomi.com >http://www.asomi.com/CaitlinBestlerResume.html > > From Michael@huaweisymantec.com Fri Jul 15 12:05:49 2011 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 03B4121F8500 for ; Fri, 15 Jul 2011 12:05:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.598 X-Spam-Level: X-Spam-Status: No, score=-2.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id OZL7Q9tKdVy5 for ; Fri, 15 Jul 2011 12:05:48 -0700 (PDT) Received: from mta1.huaweisymantec.com (mta1.huaweisymantec.com [218.17.155.14]) by ietfa.amsl.com (Postfix) with ESMTP id 5DD9C21F84FD for ; Fri, 15 Jul 2011 12:05:48 -0700 (PDT) MIME-version: 1.0 Content-type: multipart/alternative; boundary="Boundary_(ID_iwDX1ddYtgvg6jis05+9fw)" Received: from hstml02-in.huaweisymantec.com ([172.26.3.41]) by hstga01-in.huaweisymantec.com (Sun Java(tm) System Messaging Server 6.3-8.03 (built Apr 24 2009; 32bit)) with ESMTP id <0LOE00MDW2EM1V60@hstga01-in.huaweisymantec.com> for storm@ietf.org; Sat, 16 Jul 2011 03:06:22 +0800 (CST) Received: from m90003900a ([10.47.154.218]) by hstml02-in.huaweisymantec.com (Sun Java(tm) System Messaging Server 6.3-8.03 (built Apr 24 2009; 32bit)) with ESMTPA id <0LOE00IM82DFJX40@hstml02-in.huaweisymantec.com> for storm@ietf.org; Sat, 16 Jul 2011 03:05:45 +0800 (CST) Message-id: From: Michael Ko To: storm@ietf.org Date: Fri, 15 Jul 2011 12:05:38 -0700 X-Priority: 3 X-MSMail-priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.5931 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.6109 Subject: [storm] On Virtual Address, Steering Address, Base Offset, Tagged Base Offset and more 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, 15 Jul 2011 19:05:49 -0000 This is a multi-part message in MIME format. --Boundary_(ID_iwDX1ddYtgvg6jis05+9fw) Content-type: text/plain; charset=iso-8859-1 Content-transfer-encoding: 7BIT I will combine my responses to Mallikarjun and Tom in one e-mail. I am fine with using the term "Base Offset" instead of "Virtual Address". It will be defined in the Definition section as "This represents a value to be added to the Buffer Offset in order to obtain the Tagged Offset." So in sec. 2.4.1, the text "The base Tagged Offset is not explicitly specified, but the target must always assume it as zero" will be deleted. In sec. 7.3.5 on SCSI Data-in, the original text "It MUST use the Buffer Offset from the SCSI Data-in PDU as the Data Sink Tagged Offset of the RDMA Write Message" will be replaced with: "It MUST add the Buffer Offset from the SCSI Data-in PDU to the Base Offset as the Data Sink Tagged Offset of the RDMA Write Message." Similarly, in sec. 7.3.6 on Ready To Transfer, the original text "MUST use the Buffer Offset from the R2T PDU as the Data Source Tagged Offset of the RDMA Read Request Message" will be replaced with: "MUST add the Buffer Offset from the R2T PDU to the Base Offset as the Data Source Tagged Offset of the RDMA Read Request Message." Mike --Boundary_(ID_iwDX1ddYtgvg6jis05+9fw) Content-type: text/html; charset=iso-8859-1 Content-transfer-encoding: 7BIT
I will combine my responses to Mallikarjun and Tom in one e-mail.
 
I am fine with using the term "Base Offset" instead of "Virtual Address".  It will be defined in the Definition section as "This represents a value to be added to the Buffer Offset in order to obtain the Tagged Offset."  So in sec. 2.4.1, the text "The base Tagged Offset is not explicitly specified, but the target must always assume it as zero" will be deleted.
 
In sec. 7.3.5 on SCSI Data-in, the original text "It MUST use the Buffer Offset from the SCSI Data-in PDU as the Data Sink Tagged Offset of the RDMA Write Message" will be replaced with:
 
"It MUST add the Buffer Offset from the SCSI Data-in PDU to the Base Offset as the Data Sink Tagged Offset of the RDMA Write Message."
 
Similarly, in sec. 7.3.6 on Ready To Transfer, the original text "MUST use the Buffer Offset from the R2T PDU as the Data
Source Tagged Offset of the RDMA Read Request Message" will be replaced with:
 
"MUST add the Buffer Offset from the R2T PDU to the Base Offset as the Data Source Tagged Offset of the RDMA Read Request Message."
 
Mike
 --Boundary_(ID_iwDX1ddYtgvg6jis05+9fw)-- From ttalpey@microsoft.com Fri Jul 15 12:14:35 2011 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 1837321F8AFE for ; Fri, 15 Jul 2011 12:14:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.548 X-Spam-Level: X-Spam-Status: No, score=-110.548 tagged_above=-999 required=5 tests=[AWL=0.050, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id nt-3QbaOd-+I for ; Fri, 15 Jul 2011 12:14:33 -0700 (PDT) Received: from smtp.microsoft.com (smtp.microsoft.com [131.107.115.215]) by ietfa.amsl.com (Postfix) with ESMTP id 98E4A21F8AF2 for ; Fri, 15 Jul 2011 12:14:33 -0700 (PDT) Received: from TK5EX14MLTC104.redmond.corp.microsoft.com (157.54.79.159) by TK5-EXGWY-E802.partners.extranet.microsoft.com (10.251.56.168) with Microsoft SMTP Server (TLS) id 8.2.176.0; Fri, 15 Jul 2011 12:14:32 -0700 Received: from TK5EX14MBXC111.redmond.corp.microsoft.com ([169.254.2.64]) by TK5EX14MLTC104.redmond.corp.microsoft.com ([157.54.79.159]) with mapi id 14.01.0323.002; Fri, 15 Jul 2011 12:14:32 -0700 From: Tom Talpey To: Michael Ko , "storm@ietf.org" Thread-Topic: [storm] On Virtual Address, Steering Address, Base Offset, Tagged Base Offset and more Thread-Index: AQHMQyJAOFlwK00ElE28ipXGIqoEp5Ttvxrw Date: Fri, 15 Jul 2011 19:14:32 +0000 Message-ID: References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [157.54.51.36] Content-Type: multipart/alternative; boundary="_000_F83812DF4B59B9499C1BC978336D91745EE0405BTK5EX14MBXC111r_" MIME-Version: 1.0 Subject: Re: [storm] On Virtual Address, Steering Address, Base Offset, Tagged Base Offset and more 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, 15 Jul 2011 19:14:35 -0000 --_000_F83812DF4B59B9499C1BC978336D91745EE0405BTK5EX14MBXC111r_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Sounds good. I assume you'll scan the document for other instances of the t= erm "address" etc. I also spot a few uses of the term "points to" in 6.9 an= d 7.3.1. The one in 7.3.1 is associated with some questionable text indicat= ing that the arithmetic is not needed (Base Offset =3D=3D Tagged Offset). I= assume you will investigate those as part of tightening up the TO calculat= ion rules.. Tom. From: storm-bounces@ietf.org [mailto:storm-bounces@ietf.org] On Behalf Of M= ichael Ko Sent: Friday, July 15, 2011 3:06 PM To: storm@ietf.org Subject: [storm] On Virtual Address, Steering Address, Base Offset, Tagged = Base Offset and more I will combine my responses to Mallikarjun and Tom in one e-mail. I am fine with using the term "Base Offset" instead of "Virtual Address". = It will be defined in the Definition section as "This represents a value to= be added to the Buffer Offset in order to obtain the Tagged Offset." So i= n sec. 2.4.1, the text "The base Tagged Offset is not explicitly specified,= but the target must always assume it as zero" will be deleted. In sec. 7.3.5 on SCSI Data-in, the original text "It MUST use the Buffer Of= fset from the SCSI Data-in PDU as the Data Sink Tagged Offset of the RDMA W= rite Message" will be replaced with: "It MUST add the Buffer Offset from the SCSI Data-in PDU to the Base Offset= as the Data Sink Tagged Offset of the RDMA Write Message." Similarly, in sec. 7.3.6 on Ready To Transfer, the original text "MUST use = the Buffer Offset from the R2T PDU as the Data Source Tagged Offset of the RDMA Read Request Message" will be replaced wit= h: "MUST add the Buffer Offset from the R2T PDU to the Base Offset as the Data= Source Tagged Offset of the RDMA Read Request Message." Mike --_000_F83812DF4B59B9499C1BC978336D91745EE0405BTK5EX14MBXC111r_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Sounds good. I assume you= ’ll scan the document for other instances of the term “address&= #8221; etc. I also spot a few uses of the term “points to” in 6= .9 and 7.3.1. The one in 7.3.1 is associated with some questionable text indicating that= the arithmetic is not needed (Base Offset =3D=3D Tagged Offset). I assume = you will investigate those as part of tightening up the TO calculation rule= s..

 <= /p>

Tom.

 <= /p>

From: storm-bo= unces@ietf.org [mailto:storm-bounces@ietf.org] On Behalf Of Michael Ko
Sent: Friday, July 15, 2011 3:06 PM
To: storm@ietf.org
Subject: [storm] On Virtual Address, Steering Address, Base Offset, = Tagged Base Offset and more

 

I will combine my r= esponses to Mallikarjun and Tom in one e-mail.

 

I am fine with usin= g the term "Base Offset" instead of "Virtual Address&qu= ot;.  It will be defined in the Definition section as "= This represents a value to be added to the Buffer Offset in order to obtain= the Tagged Offset."  So in sec. 2.4.1, the text "The base Tagged Offse= t is not explicitly specified, but the target must always assume it as zero= " will be deleted.

 

In sec. 7.3.5 on SC= SI Data-in, the original text "It MUST use the Buffer Offset from the = SCSI Data-in PDU as the Data Sink Tagged Offset of the RDMA Write Message&q= uot; will be replaced with:

 

"It MUST add t= he Buffer Offset from the SCSI Data-in PDU to the Base Offset as the Data S= ink Tagged Offset of the RDMA Write Message."

 

Similarly, in sec. = 7.3.6 on Ready To Transfer, the original text "MUST use the Buffer Off= set from the R2T PDU as the Data
Source Tagged Offset of the RDMA Read Request Message" will be replace= d with:

 

"MUST add the = Buffer Offset from the R2T PDU to the Base Offset as the Data Source Tagged= Offset of the RDMA Read Request Message."

 

Mike

--_000_F83812DF4B59B9499C1BC978336D91745EE0405BTK5EX14MBXC111r_-- From Michael@huaweisymantec.com Fri Jul 15 13:00:27 2011 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 80D5C21F8C5E for ; Fri, 15 Jul 2011 13:00:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.598 X-Spam-Level: X-Spam-Status: No, score=-2.598 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id sWSvgophYfK0 for ; Fri, 15 Jul 2011 13:00:26 -0700 (PDT) Received: from mta1.huaweisymantec.com (mta1.huaweisymantec.com [218.17.155.14]) by ietfa.amsl.com (Postfix) with ESMTP id 5552021F8C50 for ; Fri, 15 Jul 2011 13:00:26 -0700 (PDT) MIME-version: 1.0 Content-type: multipart/alternative; boundary="Boundary_(ID_5Fx/h/86AnEUzhRbzQs1lg)" Received: from hstml02-in.huaweisymantec.com ([172.26.3.41]) by hstga01-in.huaweisymantec.com (Sun Java(tm) System Messaging Server 6.3-8.03 (built Apr 24 2009; 32bit)) with ESMTP id <0LOE00M034XP1V70@hstga01-in.huaweisymantec.com> for storm@ietf.org; Sat, 16 Jul 2011 04:01:02 +0800 (CST) Received: from m90003900a ([10.47.154.218]) by hstml02-in.huaweisymantec.com (Sun Java(tm) System Messaging Server 6.3-8.03 (built Apr 24 2009; 32bit)) with ESMTPA id <0LOE0001A4WK2R00@hstml02-in.huaweisymantec.com> for storm@ietf.org; Sat, 16 Jul 2011 04:00:25 +0800 (CST) Message-id: From: Michael Ko To: Tom Talpey , storm@ietf.org References: Date: Fri, 15 Jul 2011 13:00:19 -0700 X-Priority: 3 X-MSMail-priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.5931 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.6109 Subject: Re: [storm] On Virtual Address, Steering Address, Base Offset, Tagged Base Offset and more 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, 15 Jul 2011 20:00:27 -0000 This is a multi-part message in MIME format. --Boundary_(ID_5Fx/h/86AnEUzhRbzQs1lg) Content-type: text/plain; charset=iso-8859-1 Content-transfer-encoding: 7BIT Yes. I will scan all occurrences of "virtual address" and "tagged offset" in the current draft to update them to the latest terminology and usage. Mike ----- Original Message ----- From: Tom Talpey To: Michael Ko ; storm@ietf.org Sent: Friday, July 15, 2011 12:14 PM Subject: RE: [storm] On Virtual Address, Steering Address, Base Offset, Tagged Base Offset and more Sounds good. I assume you'll scan the document for other instances of the term "address" etc. I also spot a few uses of the term "points to" in 6.9 and 7.3.1. The one in 7.3.1 is associated with some questionable text indicating that the arithmetic is not needed (Base Offset == Tagged Offset). I assume you will investigate those as part of tightening up the TO calculation rules.. Tom. From: storm-bounces@ietf.org [mailto:storm-bounces@ietf.org] On Behalf Of Michael Ko Sent: Friday, July 15, 2011 3:06 PM To: storm@ietf.org Subject: [storm] On Virtual Address, Steering Address, Base Offset, Tagged Base Offset and more I will combine my responses to Mallikarjun and Tom in one e-mail. I am fine with using the term "Base Offset" instead of "Virtual Address". It will be defined in the Definition section as "This represents a value to be added to the Buffer Offset in order to obtain the Tagged Offset." So in sec. 2.4.1, the text "The base Tagged Offset is not explicitly specified, but the target must always assume it as zero" will be deleted. In sec. 7.3.5 on SCSI Data-in, the original text "It MUST use the Buffer Offset from the SCSI Data-in PDU as the Data Sink Tagged Offset of the RDMA Write Message" will be replaced with: "It MUST add the Buffer Offset from the SCSI Data-in PDU to the Base Offset as the Data Sink Tagged Offset of the RDMA Write Message." Similarly, in sec. 7.3.6 on Ready To Transfer, the original text "MUST use the Buffer Offset from the R2T PDU as the Data Source Tagged Offset of the RDMA Read Request Message" will be replaced with: "MUST add the Buffer Offset from the R2T PDU to the Base Offset as the Data Source Tagged Offset of the RDMA Read Request Message." Mike --Boundary_(ID_5Fx/h/86AnEUzhRbzQs1lg) Content-type: text/html; charset=iso-8859-1 Content-transfer-encoding: quoted-printable
Yes.  I will scan all occurrences of "virtual = address"=20 and "tagged offset" in the current draft to update them to the latest=20 terminology and usage.
 
Mike
----- Original Message -----
From:=20 Tom=20 Talpey
To: Michael Ko ; storm@ietf.org
Sent: Friday, July 15, 2011 = 12:14=20 PM
Subject: RE: [storm] On Virtual = Address,=20 Steering Address, Base Offset, Tagged Base Offset and more

Sounds=20 good. I assume you=92ll scan the document for other instances of the = term=20 =93address=94 etc. I also spot a few uses of the term =93points to=94 = in 6.9 and=20 7.3.1. The one in 7.3.1 is associated with some questionable text = indicating=20 that the arithmetic is not needed (Base Offset =3D=3D Tagged Offset). = I assume you=20 will investigate those as part of tightening up the TO calculation=20 rules..

 

Tom.

 

From: storm-bounces@ietf.org=20 [mailto:storm-bounces@ietf.org] On Behalf Of Michael = Ko
Sent:=20 Friday, July 15, 2011 3:06 PM
To: = storm@ietf.org
Subject:=20 [storm] On Virtual Address, Steering Address, Base Offset, Tagged Base = Offset=20 and more

 

I will combine my = responses=20 to Mallikarjun and Tom in one e-mail.

 

I am fine with = using the=20 term "Base Offset" instead of "Virtual Address".  It = will be=20 defined in the Definition section as "This represents a value to = be added=20 to the Buffer Offset in order to obtain the Tagged Offset."  So = in sec.=20 2.4.1, the text "The base Tagged Offset is not explicitly specified, = but the=20 target must always assume it as zero" will be=20 deleted.

 

In sec. 7.3.5 on = SCSI=20 Data-in, the original text "It MUST use the Buffer Offset from the = SCSI=20 Data-in PDU as the Data Sink Tagged Offset of the RDMA Write Message" = will be=20 replaced with:

 

"It MUST add the = Buffer=20 Offset from the SCSI Data-in PDU to the Base Offset as the Data Sink = Tagged=20 Offset of the RDMA Write Message."

 

Similarly, in = sec. 7.3.6 on=20 Ready To Transfer, the original text "MUST use the Buffer Offset from = the R2T=20 PDU as the Data
Source Tagged Offset of the RDMA Read Request = Message" will=20 be replaced with:

 

"MUST add the = Buffer Offset=20 from the R2T PDU to the Base Offset as the Data Source Tagged Offset = of the=20 RDMA Read Request Message."

 

Mike

--Boundary_(ID_5Fx/h/86AnEUzhRbzQs1lg)-- From dbharrington@comcast.net Sun Jul 17 22:55:37 2011 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 3144A21F8B12 for ; Sun, 17 Jul 2011 22:55:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qrQz4sCfKH2a for ; Sun, 17 Jul 2011 22:55:33 -0700 (PDT) Received: from qmta02.westchester.pa.mail.comcast.net (qmta02.westchester.pa.mail.comcast.net [76.96.62.24]) by ietfa.amsl.com (Postfix) with ESMTP id DAA7E21F8B11 for ; Sun, 17 Jul 2011 22:55:32 -0700 (PDT) Received: from omta14.westchester.pa.mail.comcast.net ([76.96.62.60]) by qmta02.westchester.pa.mail.comcast.net with comcast id 9HvY1h0011HzFnQ52HvZ1i; Mon, 18 Jul 2011 05:55:33 +0000 Received: from davidPC ([67.189.235.106]) by omta14.westchester.pa.mail.comcast.net with comcast id 9HvY1h00M2JQnJT3aHvYXt; Mon, 18 Jul 2011 05:55:33 +0000 From: "David B Harrington" To: "'David Harrington'" , , , References: In-Reply-To: Date: Mon, 18 Jul 2011 01:55:28 -0400 Message-ID: <95DEF288D9FA451B8C4BCA4ACAE1C6DA@davidPC> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 Thread-Index: AcwW/3OnDAJozBeCSrOODdtKJWAnhguALxNA X-MIMEOLE: Produced By Microsoft MimeOLE V6.1.7601.17609 Subject: Re: [storm] AD Review of draft-ietf-storm-mpa-peer-connect 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, 18 Jul 2011 05:55:37 -0000 Hi, AD Review update for -06- comments inline dbh > -----Original Message----- > From: David Harrington [mailto:ietfdbh@comcast.net] > Sent: Friday, May 20, 2011 11:06 AM > To: draft-ietf-storm-mpa-peer-connect@tools.ietf.org; > storm-chairs@ietf.org; storm@ietf.org > Subject: AD Review of draft-ietf-storm-mpa-peer-connect > > AD Review of draft-ietf-storm-mpa-peer-connect > > I have reviewed this document and have comments. I think this work is > important, but the way this document explains it could be better. > > My goal as AD is to have this document go through IETF Last Call and > IESG review without any issues delaying advancement. > > Some comments are technical/process comments that refer to text that > will likely cause delays during IESG Evaluation. > > Some are stylistic, such as capitalization and wording consistency, > that are distracting and are likely to make readers wonder "is there > something special here that I need to understand?" and to waste time > trying to determine if there is or is not something special that led > to your capitalizing the text, or using different wording than > elsewhere. These could lead to IESG members raising unnecessary > questions that would delay advancement. > > Others are editorial in nature, mostly about writing clear and > unambiguous text. Generally, if it is simply a small editorial thing, > I ignored it, expecting the RFC Editor to clean up the text a bit. But > sometimes, the lack of clarity could lead to differing interpretations > of the text, or lack of understanding of the text, and those should be > fixed before I bring this to the IESG. > > In some cases, I have asked a question. If I had to ask a question, > then the document apparently didn't explain it clearly enough. The > answer to the question usually needs to be explained "in the > document", not just in a private email to me. > > 1) idnits complains about unreachable reference: > http://www.rdmaconsortium.org/home/draft-hilland-iwarp-verbs-v1.0-RDMA > C.pdf I can reach this, but idnits seems to have a problem parsing it. > > 2) abstracts cannot contain references. fixed. > > 3) in 4.3.2, the conclusion could be stated more clearly, such as "If > a nop approach was used, it would require lower layers to know the > usage model, and would disrupt the calculations ..." fixed. > > 4) in 4.3.3, I have no idea what this text is saying or why it is > relevant to the problem at hand. I don't know what an untagged message > is; I don't know why a WC can only be generated by an untagged > message. Can you expand on this so readers that are not RDMA experts > understand what you're talking about? The IESG will need to review and > approve this document, and to my knowledge none of them are RDMA > experts. fixed. > > 5) It would be helpful to explain why taking the bit from RES is > backwards compatible. > Explain why older implementation will not have a problem with the new > bit, and why new implemntations will be able to benefit from the new > bit. fixed. text is still a bit rough though. > > 6) Rev "MUST be set to two"; would this be better as "two or higher?" > to allow for a version three+ that would be backward compatible with > the enhanced features of version two? fixed. relative to a note from dblack, you changed "nop" to dummy operation. 'nop' is still used in 4.3 > > 7) I don't understand "The Enhanced Reject function code SHOULD be > used to indicate a configuration that would have been accepted." Would > have been accepted except was not because of what condition? Why is > this only a SHOULD and not a MUST? fixed. > 8) How can the private data be zero length if it must begin with > Enhanced RDMA Connection establishment data? fixed. > 9) sometimes "Enhanced RDMA Connection Establishment Data" is > capitalized, sometimes not. Be consistent. fixed. > 10) Received extended ... message SHOULD be reported to the ULP. Why > is this not a MUST? Anytime there is a SHOULD, the text should > identify when the rule is not mandatory - what are the valid > exceptions that make this not a MUST? fixed. > 11) What is "enhanced DDP stream management"? I didn't see this addressed, but it might be clear enough. We'll see if IESG has concerns over this terminology. > 12) "It should be noted that" - you're noting it, so this lead-in > phrase is totally unnecessary. If you leave it as "It should be noted > that", then explain WHY it should be noted. If "it is especially > important to recognize that" then say that, and explain WHY it is > important to recognize. > It appears that it is important only because you've made a case for > peer-to-peer needing to initiate from either side, and the SCTP > adaption layer allows for that already. So you should probably explain > why you're duplicating that capability. fixed. > 13) additional legal sequences - but then you don't seem to define any > **sequences**. Is "Legal Sequences" a special term? If so, please > explain where it is defined. if not, why is it capitalized? > 14) I cannot parse "The protocol layers on which RDMA connection > establishment is layered upon [RFC5040] and [RFC5041] define layers > and error types." > 15) if 5043 and 5044 do not define error codes, then how are the error > codes used? are they carried in messages? which messages? fixed. > 16) In looking for the answer to 15, I found that error codes ARE > defined in RFC5044 section 8. So your text is apparently wrong. fixed. > 17) in section 9, the responder SHOULD NOT set its IRD higher than > Initiator ORD. Why is this not a MUST? Under what conditions is it > acceptable to set this higher than Initiator ORD? What are the > implications of doing so? > the responder SHOULD set its ORD lower. What are the valid exceptions > to this? in -06-, Responder SHOULD set its IRD at least to Initiator ORD "at least" seems to indicate that setting it higher than or equal to Initiator ORD is expected. But the next sentence says "Responder SHOULD NOT set its IRD higher than Initiator ORD." But the next sentence says "Responder MAY set IRD to one if Initiator ORD is zero if ..." so the logic seems unclear. I think this paragraph should be rewritten to be much clearer than the current text. It is possiblr that the text is actually a clear description of the way things should be processed. If that is true, then you might want to see if you could simplify the processing. > 18) the Initiator MUST set its IRD to a value at least as large as the > responder ORD if it has sufficient resources > "MUST if" means this is a SHOULD, and lack of resources is the > exception. If this is truly a MUST (which the following sentences seem > to say, requiring a termination if ti doesn't do so, then I would > remove the if clause from the first sentence, making it a definite > MUST. (same as #17 - please rewrite the paragraph for clarity) > 19) "Control flag for using" doesn't discuss whatthe values are. Does > this mean that if A has a value 1, then FULPDU has a zero length? > This section might be better organized by defining what the fields are > (control flags and depths), then describing how the values are set. > You do that for A,B,C but describe IRD and ORD in-line. I am not sure how you interpeted my suggestion. In -04-, you had the descriptions of the flags AFTER defining the fields, but you had the descriptions of IRD and ORD in line. Now you seem to have moved the descriptions for IRD and ORD out of line, but put the descriptions for the flags inline. I recommend that for ALL of these fields, you define the field, and then put the descriptions of the values AFTER the field definitions. -06- describes the meanings of the flags differently than -04- Is this consistent with WG consensus? The description says to set the flags to TRUE, but doesn't define TRUE. These flags are all 1-bit, so the choice seems to be 0 or 1. Is TRUE equal to 1? Then why not say 1 rather than TRUE? If TRUE has some special meaning for RDMA, please provide a reference "Control flag for using a zero length FULPDU as the RTR message." This is a little ambiguous. Please describe what the values mean for each flag, as you do for flag A. > 20) In section 9, "If there is no Standard RDMAP Configuration Data in > the MPA Reply Frame, and the Enhanced Connection Establishment version > number is used, it is the equivalent of setting 'A', 'B' and 'C'. " > Why do we need this extra complexity? Why not require that these be > set ONE way, not two? I also have concerns about "THE enhanced > connectiosn establshment version number"; will this document need to > be updated if a version three is ever developed? > 21) "Setting no Control Flags in the MPA Reply indicates that an RDMA > Send message will be required. As this option will require the > initiator ULP to be involved it SHOULD NOT be used unless necessary. " > Please define what necessary is. I think this would be better as a > MUST NOT. wow. this text has become way more complicated than the -04- version. Can this be simplified? Can you start by saying "If the value of A is 0, then: B,C,D flags must be set to zero and ignored by the reciever. processing steps for client-server mode are: and then provide bullets for the processing steps for client-server support? "If the value of A is 1, then:" and then provide bullets for the processing steps for peer-to-peer support? > 22) "Initiator or Responder SHOULD generate the TERM message" - why is > thi snot a MUST? What are the valid exceptions to this? fixed. > in section 10: > 23) "An initiator SHOULD NOT use the Enhanced DDP Connection > Establishment formats or function codes when no enhanced functionality > is desired. " what are the valid exceptions that make this a SHOULD > rather than a MUST? fixed > 24) the paragraph containing "If a responder does not support received > extended MPA message, then it MUST close the TCP connection and exit > MPA since MPA frame is improperly formatted for it as stated in > [RFC5044]." needs a bit of English cleanup. fixed. > 25) section11 This document defines error codes; so does RFC5044. > Implementers and operators will need to hunt through documents to find > the various error codes. This document apparently overlooks the error > codes defined in 5044 section 8. Should there be a registry, > maintained by IANA, for the MPA error codes? I repeat my question. Should there be a registry for the error codes so there is a consistent place to look for which error codes are defined, and their values and meanings? > section 12: > 26) I am always concerned when a security coinsiderations section says > this document does not introduce any new security considerations. This > is also a red flag during IESG Evaluation. I suggest you document WHY > these changes do not impact security compared to 5043 and 5044. > Demonstrate that the WG actually **considered** the security issues. well, this wasn't handled, but the refernce to 5044 secCons might be enough. We'll see if IESG has any comments. > > 27) expand acronyms on first use (MPA, RDMA, RDDP, ULP, iWARP, etc.) fixed, although not always on first usage. A large section was added to the Introduction that uses the words before what used to be the first use. I can live with this, and the RFC Editor can fix if necessary. > > 28) references for sctp, infiniband, fixed. > > 29) in 4.3.1, "required only for one transport" - mention the one > transport? fixed. > > 30) an explanation/definition of MPA Fencing would help readers. Maybe > a terminology section would be helpful, given all the acronyms, etc. fixed. > > 31) The information in 4.4 would be helful in the Introduction > section. This would help to organize the document into "Here's how it > works now; here is why the client/server model is undesirable in a P2P > environment; and this is how to modify the existing standard to > address this problem." fixed. > > 32) Is section 5 a description of how things currently work, or the > way this document proposes they work? Section 5 mentions "Enhanced > Connection Setup"; is that the same as "Enhanced RDMA Connection > Establishment"? if so, then naming section 5 "Enhanced RDMA Connection > Establishment" or "Enhanced MPA Connection Setup" might be helful. Use > terminology consistently, please. fixed > > I hope these suggestions help improve the document so we can advance > it through the approval process quickly, > > > > > > > > > > David Harrington > Director, IETF Transport Area > ietfdbh@comcast.net (preferred for ietf) > dbharrington@huaweisymantec.com > +1 603 828 1401 (cell) > > From stpeter@stpeter.im Tue Jul 19 11:51:23 2011 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 C0CD511E8070 for ; Tue, 19 Jul 2011 11:51:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.741 X-Spam-Level: X-Spam-Status: No, score=-102.741 tagged_above=-999 required=5 tests=[AWL=-0.142, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 51XlAivE8Z9t for ; Tue, 19 Jul 2011 11:51:23 -0700 (PDT) Received: from stpeter.im (mailhost.stpeter.im [207.210.219.225]) by ietfa.amsl.com (Postfix) with ESMTP id E8000228018 for ; Tue, 19 Jul 2011 11:51:22 -0700 (PDT) Received: from dhcp-64-101-72-201.cisco.com (unknown [64.101.72.201]) (Authenticated sender: stpeter) by stpeter.im (Postfix) with ESMTPSA id D16594005A for ; Tue, 19 Jul 2011 12:52:02 -0600 (MDT) Message-ID: <4E25D229.5020809@stpeter.im> Date: Tue, 19 Jul 2011 12:51:21 -0600 From: Peter Saint-Andre User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.5; en-US; rv:1.9.2.15) Gecko/20110303 Thunderbird/3.1.9 MIME-Version: 1.0 To: storm@ietf.org Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Subject: [storm] Fwd: [apps-discuss] i18n intro, Sunday 14:00-16:00 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, 19 Jul 2011 18:51:23 -0000 This might be of interest given use of stringprep in iSCSI... -------- Original Message -------- Subject: [apps-discuss] i18n intro, Sunday 14:00-16:00 Date: Tue, 19 Jul 2011 12:48:39 -0600 From: Peter Saint-Andre To: apps-discuss@ietf.org You might have noticed a curious item on the agenda at 14:00 on Sunday: "Apps Area Preparatory Meeting for Internationalization Working Groups". At that time, I will present an introduction to internationalization, assisted by Pete Resnick (who will correct me where I go wrong). The intent of this session is to help apps-area folks learn more about internationalization, especially in preparation for the PRECIS WG meeting on Thursday. The room we've been assigned (2103) holds up to 60 people so we should have plenty of space, and there is no need to sign up if you want to attend. If this session goes well, Pete and I might offer a more general tutorial at a future IETF meeting. Consider Sunday's session a dry run. See you in Quebec City! Peter -- Peter Saint-Andre https://stpeter.im/ _______________________________________________ apps-discuss mailing list apps-discuss@ietf.org https://www.ietf.org/mailman/listinfo/apps-discuss From david.black@emc.com Fri Jul 22 17:01:01 2011 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 B592F21F8C41 for ; Fri, 22 Jul 2011 17:01:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -105.467 X-Spam-Level: X-Spam-Status: No, score=-105.467 tagged_above=-999 required=5 tests=[AWL=1.132, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id sZceX+0cSMsu for ; Fri, 22 Jul 2011 17:01:01 -0700 (PDT) Received: from mexforward.lss.emc.com (mexforward.lss.emc.com [128.222.32.20]) by ietfa.amsl.com (Postfix) with ESMTP id 2918721F8C39 for ; Fri, 22 Jul 2011 17:01:00 -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 p6N00w0x008638 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Fri, 22 Jul 2011 20:00:58 -0400 Received: from mailhub.lss.emc.com (mailhub.lss.emc.com [10.254.222.226]) by hop04-l1d11-si03.isus.emc.com (RSA Interceptor) for ; Fri, 22 Jul 2011 20:00:48 -0400 Received: from mxhub05.corp.emc.com (mxhub05.corp.emc.com [128.221.46.113]) by mailhub.lss.emc.com (Switch-3.4.3/Switch-3.4.3) with ESMTP id p6N00mCc026388 for ; Fri, 22 Jul 2011 20:00:48 -0400 Received: from mx14a.corp.emc.com ([169.254.1.245]) by mxhub05.corp.emc.com ([128.221.46.113]) with mapi; Fri, 22 Jul 2011 20:00:48 -0400 From: To: Date: Fri, 22 Jul 2011 20:00:45 -0400 Thread-Topic: Quebec storm agenda Thread-Index: AcxIy5IztHFejigtTkON8eBso3+ULA== Message-ID: <7C4DFCE962635144B8FAE8CA11D0BF1E058948BD1D@MX14A.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="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-EMM-MHVC: 1 Subject: [storm] Quebec storm agenda 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, 23 Jul 2011 00:01:01 -0000 The major v1 -> v2 change is updated draft version numbers. No change to t= ime slots or responsible presenters. IETF storm (STORage Maintenance) WG Meeting agenda (v2) Tuesday, July 26, 2011, 1710-1810 Quebec City, QC, Canada ----------------------------------- Administrivia, agenda bashing, etc. - 10 min David L. Black, EMC & Tom Talpey, Microsoft (WG co-chairs) Blue sheets Note Well Milestones Note-taker Draft status - 5 min David L. Black, EMC (co-chair) iFCP update and associated iFCP MIB update - Published as RFCs 6172 and 61= 73 MPA update - Publication Requested, AD is processing iSCSI drafts (Consolidated, SAM and MIB) iSER draft RDMA extensions (not currently a WG draft) iSCSI Drafts (draft-ietf-storm-iscsi-cons-03, draft-ietf-storm-iscsi-sam-03= ) - 10 min Fred Knight, NetApp & WG co-chairs Issues that need attention from ongoing WG Last Call, if any Status of engagement of iSCSI implementers to review these drafts iSCSI MIB draft (draft-ietf-storm-iscsimib-00) - 5 min If time needed, status report under "Draft status" above may suffice iSER draft (draft-ietf-storm-iser-02) - 10 min Mike Ko, HuaweiSymantec (on behalf of draft authors) Summarize known topics & issues that need attention RDMA Protocol Extensions Draft (draft-ietf-storm-rdmap-ext-01) - 20 min Hemal Shah, Broadcom (on behalf of draft authors) NOTE: Despite its filename, this is not an official storm WG draft. Discussion of draft contents and rationale. Question: Should WG should adopt this draft as a work item. From arkady.kanevsky@gmail.com Sat Jul 23 17:38:52 2011 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 8062D21F8BD8 for ; Sat, 23 Jul 2011 17:38:52 -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 ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2GI4mpnSV1ou for ; Sat, 23 Jul 2011 17:38:50 -0700 (PDT) Received: from mail-pz0-f53.google.com (mail-pz0-f53.google.com [209.85.210.53]) by ietfa.amsl.com (Postfix) with ESMTP id 4A3B421F8BC8 for ; Sat, 23 Jul 2011 17:38:50 -0700 (PDT) Received: by pzk6 with SMTP id 6so5686220pzk.26 for ; Sat, 23 Jul 2011 17:38:50 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=P1GimVzgE2R2gWjFx59UMijJHT3Nkkx9s/xHGnETC40=; b=fZ8Wdf8S9bnqm/ADQvx+hbtQ8fZXReX07PZJHlD7efQcy1+Wi6XUbd0SAJiTMa0dRm jbz9QrJJ7xYjL8u3Q9QfUPSQcJooJZNO0n52DiTWXRN4mDmi6XuJHxXEk7STEOaBLE+T p8dcC6Pd7JMwOo+fAxw0vqhQP4PXA4iH9e35s= MIME-Version: 1.0 Received: by 10.142.55.1 with SMTP id d1mr1730884wfa.387.1311467929806; Sat, 23 Jul 2011 17:38:49 -0700 (PDT) Received: by 10.142.131.11 with HTTP; Sat, 23 Jul 2011 17:38:49 -0700 (PDT) In-Reply-To: <95DEF288D9FA451B8C4BCA4ACAE1C6DA@davidPC> References: <95DEF288D9FA451B8C4BCA4ACAE1C6DA@davidPC> Date: Sat, 23 Jul 2011 19:38:49 -0500 Message-ID: From: arkady kanevsky To: David B Harrington Content-Type: multipart/alternative; boundary=001636e90b3d17266704a8c5ecef Cc: draft-ietf-storm-mpa-peer-connect@tools.ietf.org, storm-chairs@ietf.org, storm@ietf.org Subject: Re: [storm] AD Review of draft-ietf-storm-mpa-peer-connect 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, 24 Jul 2011 00:38:52 -0000 --001636e90b3d17266704a8c5ecef Content-Type: text/plain; charset=ISO-8859-1 David, Again thank you very much for your comments. Enclosed, please, find the latest draft for you review before submission. Also in-line below I included responses to your comments. Thanks, Arkady On Mon, Jul 18, 2011 at 12:55 AM, David B Harrington < dbharrington@comcast.net> wrote: > Hi, > > AD Review update for -06- > comments inline > > dbh > > > -----Original Message----- > > From: David Harrington [mailto:ietfdbh@comcast.net] > > Sent: Friday, May 20, 2011 11:06 AM > > To: draft-ietf-storm-mpa-peer-connect@tools.ietf.org; > > storm-chairs@ietf.org; storm@ietf.org > > Subject: AD Review of draft-ietf-storm-mpa-peer-connect > > > > AD Review of draft-ietf-storm-mpa-peer-connect > > > > I have reviewed this document and have comments. I think this work > is > > important, but the way this document explains it could be better. > > > > My goal as AD is to have this document go through IETF Last Call and > > IESG review without any issues delaying advancement. > > > > Some comments are technical/process comments that refer to text that > > will likely cause delays during IESG Evaluation. > > > > Some are stylistic, such as capitalization and wording consistency, > > that are distracting and are likely to make readers wonder "is there > > something special here that I need to understand?" and to waste time > > trying to determine if there is or is not something special that led > > to your capitalizing the text, or using different wording than > > elsewhere. These could lead to IESG members raising unnecessary > > questions that would delay advancement. > > > > Others are editorial in nature, mostly about writing clear and > > unambiguous text. Generally, if it is simply a small editorial > thing, > > I ignored it, expecting the RFC Editor to clean up the text a bit. > But > > sometimes, the lack of clarity could lead to differing > interpretations > > of the text, or lack of understanding of the text, and those should > be > > fixed before I bring this to the IESG. > > > > In some cases, I have asked a question. If I had to ask a question, > > then the document apparently didn't explain it clearly enough. The > > answer to the question usually needs to be explained "in the > > document", not just in a private email to me. > > > > 1) idnits complains about unreachable reference: > > > http://www.rdmaconsortium.org/home/draft-hilland-iwarp-verbs-v1.0-RDMA > > C.pdf > > I can reach this, but idnits seems to have a problem parsing it. > > > > > 2) abstracts cannot contain references. > > fixed. > > > > > 3) in 4.3.2, the conclusion could be stated more clearly, such as > "If > > a nop approach was used, it would require lower layers to know the > > usage model, and would disrupt the calculations ..." > > fixed. > > > > > 4) in 4.3.3, I have no idea what this text is saying or why it is > > relevant to the problem at hand. I don't know what an untagged > message > > is; I don't know why a WC can only be generated by an untagged > > message. Can you expand on this so readers that are not RDMA experts > > understand what you're talking about? The IESG will need to review > and > > approve this document, and to my knowledge none of them are RDMA > > experts. > > fixed. > > > > > 5) It would be helpful to explain why taking the bit from RES is > > backwards compatible. > > Explain why older implementation will not have a problem with the > new > > bit, and why new implemntations will be able to benefit from the new > > bit. > > fixed. text is still a bit rough though. > Cleaned the text: Res: One bit smaller than in [RFC5044], otherwise unchanged. In [RFC5044] 'Res' with 'S' is reserved for future use. [RFC5044] specifies that 'RES' MUST be set to zero when sending, and MUST NOT be checked on reception, making use of S bit backwards compatible with the original MPA frame format. When the S bit is set to zero, no additional private data is used for enhanced RDMA connection establishment, and therefore the resulting MPA request and reply frames are identical to the unenhanced protocol. > > > > > 6) Rev "MUST be set to two"; would this be better as "two or > higher?" > > to allow for a version three+ that would be backward compatible with > > the enhanced features of version two? > > fixed. > > relative to a note from dblack, you changed "nop" to dummy operation. > 'nop' is still used in 4.3 > > Good catch. Fixed 4.3 as The natural question is why the application layer would not simply generate a dummy message when there was no other message to submit. > > > > 7) I don't understand "The Enhanced Reject function code SHOULD be > > used to indicate a configuration that would have been accepted." > Would > > have been accepted except was not because of what condition? Why is > > this only a SHOULD and not a MUST? > > fixed. > > > 8) How can the private data be zero length if it must begin with > > Enhanced RDMA Connection establishment data? > > fixed. > > > 9) sometimes "Enhanced RDMA Connection Establishment Data" is > > capitalized, sometimes not. Be consistent. > > fixed. > > > 10) Received extended ... message SHOULD be reported to the ULP. Why > > is this not a MUST? Anytime there is a SHOULD, the text should > > identify when the rule is not mandatory - what are the valid > > exceptions that make this not a MUST? > > fixed. > > > 11) What is "enhanced DDP stream management"? > > I didn't see this addressed, but it might be clear enough. We'll see > if IESG has concerns over this terminology. > > > 12) "It should be noted that" - you're noting it, so this lead-in > > phrase is totally unnecessary. If you leave it as "It should be > noted > > that", then explain WHY it should be noted. If "it is especially > > important to recognize that" then say that, and explain WHY it is > > important to recognize. > > It appears that it is important only because you've made a case for > > peer-to-peer needing to initiate from either side, and the SCTP > > adaption layer allows for that already. So you should probably > explain > > why you're duplicating that capability. > > fixed. > > > 13) additional legal sequences - but then you don't seem to define > any > > **sequences**. Is "Legal Sequences" a special term? If so, please > > explain where it is defined. if not, why is it capitalized? > > 14) I cannot parse "The protocol layers on which RDMA connection > > establishment is layered upon [RFC5040] and [RFC5041] define layers > > and error types." > > 15) if 5043 and 5044 do not define error codes, then how are the > error > > codes used? are they carried in messages? which messages? > > fixed. > > > 16) In looking for the answer to 15, I found that error codes ARE > > defined in RFC5044 section 8. So your text is apparently wrong. > > fixed. > > > 17) in section 9, the responder SHOULD NOT set its IRD higher than > > Initiator ORD. Why is this not a MUST? Under what conditions is it > > acceptable to set this higher than Initiator ORD? What are the > > implications of doing so? > > the responder SHOULD set its ORD lower. What are the valid > exceptions > > to this? > > in -06-, > Responder SHOULD set its IRD at least to Initiator ORD > "at least" seems to indicate that setting it higher than or equal to > Initiator ORD is expected. > But the next sentence says "Responder SHOULD NOT set its IRD higher > than Initiator ORD." > But the next sentence says "Responder MAY set IRD to one if Initiator > ORD is zero if ..." > so the logic seems unclear. > I think this paragraph should be rewritten to be much clearer than the > current text. > > It is possiblr that the text is actually a clear description of the > way things should be processed. > If that is true, then you might want to see if you could simplify the > processing. > Section 9 is rewritten to address comments 17-21. > > > 18) the Initiator MUST set its IRD to a value at least as large as > the > > responder ORD if it has sufficient resources > > "MUST if" means this is a SHOULD, and lack of resources is the > > exception. If this is truly a MUST (which the following sentences > seem > > to say, requiring a termination if ti doesn't do so, then I would > > remove the if clause from the first sentence, making it a definite > > MUST. > > (same as #17 - please rewrite the paragraph for clarity) > > > > 19) "Control flag for using" doesn't discuss whatthe values are. > Does > > this mean that if A has a value 1, then FULPDU has a zero length? > > This section might be better organized by defining what the fields > are > > (control flags and depths), then describing how the values are set. > > You do that for A,B,C but describe IRD and ORD in-line. > > I am not sure how you interpeted my suggestion. In -04-, you had the > descriptions of the flags AFTER defining the fields, > but you had the descriptions of IRD and ORD in line. Now you seem to > have moved the descriptions for IRD and ORD out of line, but put the > descriptions for the flags inline. I recommend that for ALL of these > fields, you define the field, and then put the descriptions of the > values AFTER the field definitions. > > -06- describes the meanings of the flags differently than -04- > Is this consistent with WG consensus? > > The description says to set the flags to TRUE, but doesn't define > TRUE. > These flags are all 1-bit, so the choice seems to be 0 or 1. > Is TRUE equal to 1? Then why not say 1 rather than TRUE? > If TRUE has some special meaning for RDMA, please provide a reference > > "Control flag for using a zero length FULPDU as the RTR message." > This is a little ambiguous. > Please describe what the values mean for each flag, as you do for flag > A. > Done. > > > 20) In section 9, "If there is no Standard RDMAP Configuration Data > in > > the MPA Reply Frame, and the Enhanced Connection Establishment > version > > number is used, it is the equivalent of setting 'A', 'B' and 'C'. " > > Why do we need this extra complexity? Why not require that these be > > set ONE way, not two? I also have concerns about "THE enhanced > > connectiosn establshment version number"; will this document need to > > be updated if a version three is ever developed? > > 21) "Setting no Control Flags in the MPA Reply indicates that an > RDMA > > Send message will be required. As this option will require the > > initiator ULP to be involved it SHOULD NOT be used unless necessary. > " > > Please define what necessary is. I think this would be better as a > > MUST NOT. > > wow. this text has become way more complicated than the -04- version. > Can this be simplified? > Can you start by saying > "If the value of A is 0, then: > B,C,D flags must be set to zero and ignored by the reciever. > processing steps for client-server mode are: > and then provide bullets for the processing steps for > client-server support? > "If the value of A is 1, then:" > and then provide bullets for the processing steps for > peer-to-peer support? > > > 22) "Initiator or Responder SHOULD generate the TERM message" - why > is > > thi snot a MUST? What are the valid exceptions to this? > > fixed. > > > in section 10: > > 23) "An initiator SHOULD NOT use the Enhanced DDP Connection > > Establishment formats or function codes when no enhanced > functionality > > is desired. " what are the valid exceptions that make this a SHOULD > > rather than a MUST? > > fixed > > > 24) the paragraph containing "If a responder does not support > received > > extended MPA message, then it MUST close the TCP connection and exit > > MPA since MPA frame is improperly formatted for it as stated in > > [RFC5044]." needs a bit of English cleanup. > > fixed. > > > 25) section11 This document defines error codes; so does RFC5044. > > Implementers and operators will need to hunt through documents to > find > > the various error codes. This document apparently overlooks the > error > > codes defined in 5044 section 8. Should there be a registry, > > maintained by IANA, for the MPA error codes? > > I repeat my question. Should there be a registry for the error codes > so there is a consistent place to look for which error codes are > defined, and their values and meanings? > Since RFC5044 does not have any IANA consideration and RFC5043 only uses IANA since it extends IANA registered SCTP PPIDs we do not feel that IANA registry is needed. > > > > section 12: > > 26) I am always concerned when a security coinsiderations section > says > > this document does not introduce any new security considerations. > This > > is also a red flag during IESG Evaluation. I suggest you document > WHY > > these changes do not impact security compared to 5043 and 5044. > > Demonstrate that the WG actually **considered** the security issues. > > well, this wasn't handled, but the refernce to 5044 secCons might be > enough. We'll see if IESG has any comments. > > > > > 27) expand acronyms on first use (MPA, RDMA, RDDP, ULP, iWARP, etc.) > > fixed, although not always on first usage. > A large section was added to the Introduction that uses the words > before what used to be the first use. > I can live with this, and the RFC Editor can fix if necessary. > > > > > 28) references for sctp, infiniband, > > fixed. > > > > > 29) in 4.3.1, "required only for one transport" - mention the one > > transport? > > fixed. > > > > > 30) an explanation/definition of MPA Fencing would help readers. > Maybe > > a terminology section would be helpful, given all the acronyms, etc. > > fixed. > > > > > 31) The information in 4.4 would be helful in the Introduction > > section. This would help to organize the document into "Here's how > it > > works now; here is why the client/server model is undesirable in a > P2P > > environment; and this is how to modify the existing standard to > > address this problem." > > fixed. > > > > 32) Is section 5 a description of how things currently work, or the > > way this document proposes they work? Section 5 mentions "Enhanced > > Connection Setup"; is that the same as "Enhanced RDMA Connection > > Establishment"? if so, then naming section 5 "Enhanced RDMA > Connection > > Establishment" or "Enhanced MPA Connection Setup" might be helful. > Use > > terminology consistently, please. > > fixed > > > > I hope these suggestions help improve the document so we can advance > > it through the approval process quickly, > > > > > > > > > > > > > > > > > > > > David Harrington > > Director, IETF Transport Area > > ietfdbh@comcast.net (preferred for ietf) > > dbharrington@huaweisymantec.com > > +1 603 828 1401 (cell) > > > > > > _______________________________________________ > storm mailing list > storm@ietf.org > https://www.ietf.org/mailman/listinfo/storm > -- Cheers, Arkady Kanevsky --001636e90b3d17266704a8c5ecef Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable David,
Again thank you very much for your comments.
Enclosed, please,= find the latest draft for you review before submission.
Also in-line be= low I included responses to your comments.
Thanks,
Arkady

On Mon, Jul 18, 2011 at 12:55 AM, David B Harrington <= dbharrington@= comcast.net> wrote:
Hi,

AD Review update for -06-
comments inline

dbh

> -----Original Message-----
> From: David Harrington [mailto:ietfdbh@comcast.net]
> Sent: Friday, May 20, 2011 11:06 AM
> To: draft-ietf-storm-mpa-peer-connect@tools.ietf.org; > storm-chair= s@ietf.org; storm@i= etf.org
> Subject: AD Review of draft-ietf-storm-mpa-peer-connect
>
> AD Review of draft-ietf-storm-mpa-peer-connect
>
> I have reviewed this document and have comments. I think this work
is
> important, but the way this document explains it could be better.
>
> My goal as AD is to have this document go through IETF Last Call and > IESG review without any issues delaying advancement.
>
> Some comments are technical/process comments that refer to text that > will likely cause delays during IESG Evaluation.
>
> Some are stylistic, such as capitalization and wording consistency, > that are distracting and are likely to make readers wonder "is th= ere
> something special here that I need to understand?" and to waste t= ime
> trying to determine if there is or is not something special that led > to your capitalizing the text, or using different wording than
> elsewhere. These could lead to IESG members raising unnecessary
> questions that would delay advancement.
>
> Others are editorial in nature, mostly about writing clear and
> unambiguous text. Generally, if it is simply a small editorial
thing,
> I ignored it, expecting the RFC Editor to clean up the text a bit.
But
> sometimes, the lack of clarity could lead to differing
interpretations
> of the text, or lack of understanding of the text, and those should be
> fixed before I bring this to the IESG.
>
> In some cases, I have asked a question. If I had to ask a question, > then the document apparently didn't explain it clearly enough. The=
> answer to the question usually needs to be explained "in the
> document", not just in a private email to me.
>
> 1) idnits complains about unreachable reference:
>
http://www.rdmaconsortium.org/home/draft-hilland-= iwarp-verbs-v1.0-RDMA
> C.pdf

I can reach this, but idnits seems to have a problem parsing it= .

>
> 2) abstracts cannot contain references.

fixed.

>
> 3) in 4.3.2, the conclusion could be stated more clearly, such as
"If
> a nop approach was used, it would require lower layers to know the
> usage model, and would disrupt the calculations ..."

fixed.

>
> 4) in 4.3.3, I have no idea what this text is saying or why it is
> relevant to the problem at hand. I don't know what an untagged
message
> is; I don't know why a WC can only be generated by an untagged
> message. Can you expand on this so readers that are not RDMA experts > understand what you're talking about? The IESG will need to review=
and
> approve this document, and to my knowledge none of them are RDMA
> experts.

fixed.

>
> 5) It would be helpful to explain why taking the bit from RES is
> backwards compatible.
> Explain why older implementation will not have a problem with the
new
> bit, and why new implemntations will be able to benefit from the new > bit.

fixed. text is still a bit rough though.

Cle= aned the text:
Res:  One bit smaller than in [RFC5044], otherwise u=
nchanged.  In
      [RFC5044] 'Res' with 'S' is reserved for future use. =
 [RFC5044]
      specifies that 'RES' MUST be set to zero when sending, and MU=
ST
      NOT be checked on reception, making use of S bit backwards
      compatible with the original MPA frame format.  When the S bit is
      set to zero, no additional private data is used for enhanced RDMA
      connection establishment, and therefore the resulting MPA request
      and reply frames are identical to the unenhanced protocol.
=A0

>
> 6) Rev "MUST be set to two"; would this be better as "t= wo or
higher?"
> to allow for a version three+ that would be backward compatible with > the enhanced features of version two?

fixed.

relative to a note from dblack, you changed "nop" to dummy operat= ion.
'nop' is still used in 4.3

Good catch.
Fixed 4.3 as
The
   natural question is why the application layer would not simply
   generate a dummy message when there was no other message to submit.=A0
>
> 7) I don't understand "The Enhanced Reject function code SHOU= LD be
> used to indicate a configuration that would have been accepted."<= br> Would
> have been accepted except was not because of what condition? Why is > this only a SHOULD and not a MUST?

fixed.

> =A08) How can the private data be zero length if it must begin with > Enhanced RDMA Connection establishment data?

fixed.

> 9) sometimes "Enhanced RDMA Connection Establishment Data" i= s
> capitalized, sometimes not. Be consistent.

fixed.

> 10) Received extended ... message SHOULD be reported to the ULP. Why > is this not a MUST? Anytime there is a SHOULD, the text should
> identify when the rule is not mandatory - what are the valid
> exceptions that make this not a MUST?

fixed.

> 11) What is "enhanced DDP stream management"?

I didn't see this addressed, but it might be clear enough. We'= ;ll see
if IESG has concerns over this terminology.

> 12) "It should be noted that" - you're noting it, so thi= s lead-in
> phrase is totally unnecessary. If you leave it as "It should be noted
> that", then explain WHY it should be noted. If "it is especi= ally
> important to recognize that" then say that, and explain WHY it is=
> important to recognize.
> It appears that it is important only because you've made a case fo= r
> peer-to-peer needing to initiate from either side, and the SCTP
> adaption layer allows for that already. So you should probably
explain
> why you're duplicating that capability.

fixed.

> 13) additional legal sequences - but then you don't seem to define=
any
> **sequences**. Is "Legal Sequences" a special term? If so, p= lease
> explain where it is defined. if not, why is it capitalized?
> 14) I cannot parse "The protocol layers on which RDMA connection<= br> > establishment is layered upon [RFC5040] and [RFC5041] define layers > and error types."
> 15) if 5043 and 5044 do not define error codes, then how are the
error
> codes used? are they carried in messages? which messages?

fixed.

> 16) In looking for the answer to 15, I found that error codes ARE
> defined in RFC5044 section 8. So your text is apparently wrong.

fixed.

> 17) in section 9, the responder SHOULD NOT set its IRD higher than
> Initiator ORD. Why is this not a MUST? Under what conditions is it
> acceptable to set this higher than Initiator ORD? What are the
> implications of doing so?
> the responder SHOULD set its ORD lower. What are the valid
exceptions
> to this?

in -06-,
=A0 =A0 =A0 =A0Responder SHOULD set its IRD at least to Initiator ORD
"at least" seems to indicate that setting it higher than or equal= to
Initiator ORD is expected.
But the next sentence says "Responder SHOULD NOT set its IRD higher than Initiator ORD."
But the next sentence says "Responder MAY set IRD to one if Initiator<= br> ORD is zero if ..."
so the logic seems unclear.
I think this paragraph should be rewritten to be much clearer than the
current text.

It is possiblr that the text is actually a clear description of the
way things should be processed.
If that is true, then you might want to see if you could simplify the
processing.

Section 9 is rewritten to address comm= ents 17-21.

> 18) the Initiator MUST set its IRD to a value at least as large as
the
> responder ORD if it has sufficient resources
> "MUST if" means this is a SHOULD, and lack of resources is t= he
> exception. If this is truly a MUST (which the following sentences
seem
> to say, requiring a termination if ti doesn't do so, then I would<= br> > remove the if clause from the first sentence, making it a definite
> MUST.

(same as #17 - please rewrite the paragraph for clarity)


> 19) "Control flag for using" doesn't discuss whatthe val= ues are.
Does
> this mean that if A has a value 1, then FULPDU has a zero length?
> This section might be better organized by defining what the fields
are
> (control flags and depths), then describing how the values are set. > You do that for A,B,C but describe IRD and ORD in-line.

I am not sure how you interpeted my suggestion. In -04-, you had the<= br> descriptions of the flags AFTER defining the fields,
but you had the descriptions of IRD and ORD in line. Now you seem to
have moved the descriptions for IRD and ORD out of line, but put the
descriptions for the flags inline. I recommend that for ALL of these
fields, you define the field, and then put the descriptions of the
values AFTER the field definitions.

-06- describes the meanings of the flags differently than -04-
Is this consistent with WG consensus?

The description says to set the flags to TRUE, but doesn't define
TRUE.
These flags are all 1-bit, so the choice seems to be 0 or 1.
Is TRUE equal to 1? Then why not say 1 rather than TRUE?
If TRUE has some special meaning for RDMA, please provide a reference

"Control flag for using a zero length FULPDU as the RTR message."=
This is a little ambiguous.
Please describe what the values mean for each flag, as you do for flag
A.

Done.

> 20) In section 9, "If there is no Standard RDMAP Configuration Da= ta
in
> the MPA Reply Frame, and the Enhanced Connection Establishment
version
> number is used, it is the equivalent of setting 'A', 'B= 9; and 'C'. "
> Why do we need this extra complexity? Why not require that these be > set ONE way, not two? I also have concerns about "THE enhanced > connectiosn establshment version number"; will this document need= to
> be updated if a version three is ever developed?
> 21) "Setting no Control Flags in the MPA Reply indicates that an<= br> RDMA
> Send message will be required. As this option will require the
> initiator ULP to be involved it SHOULD NOT be used unless necessary. "
> Please define what necessary is. I think this would be better as a
> MUST NOT.

wow. this text has become way more complicated than the -04- version.=
Can this be simplified?
Can you start by saying
"If the value of A is 0, then:
=A0 =A0 =A0 =A0B,C,D flags must be set to zero and ignored by the reciever= .
=A0 =A0 =A0 =A0processing steps for client-server mode are:
=A0 =A0 =A0 =A0and then provide bullets for the processing steps for
client-server support?
"If the value of A is 1, then:"
=A0 =A0 =A0 =A0and then provide bullets for the processing steps for
peer-to-peer support?

> 22) "Initiator or Responder SHOULD generate the TERM message"= ; - why
is
> thi snot a MUST? What are the valid exceptions to this?

fixed.

> in section 10:
> 23) "An initiator SHOULD NOT use the Enhanced DDP Connection
> Establishment formats or function codes when no enhanced
functionality
> is desired. " what are the valid exceptions that make this a SHOU= LD
> rather than a MUST?

fixed

> 24) the paragraph containing "If a responder does not support
received
> extended MPA message, then it MUST close the TCP connection and exit > MPA since MPA frame is improperly formatted for it as stated in
> [RFC5044]." needs a bit of English cleanup.

fixed.

> 25) section11 This document defines error codes; so does RFC5044.
> Implementers and operators will need to hunt through documents to
find
> the various error codes. This document apparently overlooks the
error
> codes defined in 5044 section 8. Should there be a registry,
> maintained by IANA, for the MPA error codes?

I repeat my question. Should there be a registry for the error codes<= br> so there is a consistent place to look for which error codes are
defined, and their values and meanings?

Since RFC5= 044 does not have any IANA consideration and RFC5043 only uses IANA
sinc= e it extends IANA registered SCTP=A0 PPIDs we do not feel that IANA registr= y is needed.


> section 12:
> 26) I am always concerned when a security coinsiderations section
says
> this document does not introduce any new security considerations.
This
> is also a red flag during IESG Evaluation. I suggest you document
WHY
> these changes do not impact security compared to 5043 and 5044.
> Demonstrate that the WG actually **considered** the security issues.
well, this wasn't handled, but the refernce to 5044 secCons might= be
enough. We'll see if IESG has any comments.

>
> 27) expand acronyms on first use (MPA, RDMA, RDDP, ULP, iWARP, etc.)
fixed, although not always on first usage.
A large section was added to the Introduction that uses the words
before what used to be the first use.
I can live with this, and the RFC Editor can fix if necessary.

>
> 28) references for sctp, infiniband,

fixed.

>
> 29) in 4.3.1, "required only for one transport" - mention th= e one
> transport?

fixed.

>
> 30) an explanation/definition of MPA Fencing would help readers.
Maybe
> a terminology section would be helpful, given all the acronyms, etc.
fixed.

>
> 31) The information in 4.4 would be helful in the Introduction
> section. This would help to organize the document into "Here'= s how
it
> works now; here is why the client/server model is undesirable in a
P2P
> environment; and this is how to modify the existing standard to
> address this problem."

fixed.
>
> 32) Is section 5 a description of how things currently work, or the > way this document proposes they work? Section 5 mentions "Enhance= d
> Connection Setup"; is that the same as "Enhanced RDMA Connec= tion
> Establishment"? if so, then naming section 5 "Enhanced RDMA<= br> Connection
> Establishment" or "Enhanced MPA Connection Setup" might= be helful.
Use
> terminology consistently, please.

fixed
>
> I hope these suggestions help improve the document so we can advance > it through the approval process quickly,
>
>
>
>
>
>
>
>
>
> David Harrington
> Director, IETF Transport Area
> ietfdbh@comca= st.net (preferred for ietf)
> d= bharrington@huaweisymantec.com
> +1 603 828 1401 (cell)
>
>

_______________________________________________
storm mailing list
storm@ietf.org
h= ttps://www.ietf.org/mailman/listinfo/storm



--
Cheers,
= Arkady Kanevsky
--001636e90b3d17266704a8c5ecef-- From david.black@emc.com Tue Jul 26 15:59:05 2011 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 3321911E80C0 for ; Tue, 26 Jul 2011 15:59:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -105.586 X-Spam-Level: X-Spam-Status: No, score=-105.586 tagged_above=-999 required=5 tests=[AWL=1.013, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qXjvZymqN7Sk for ; Tue, 26 Jul 2011 15:59:04 -0700 (PDT) Received: from mexforward.lss.emc.com (mexforward.lss.emc.com [128.222.32.20]) by ietfa.amsl.com (Postfix) with ESMTP id 77C17228010 for ; Tue, 26 Jul 2011 15:59:04 -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 p6QMx1D7020932 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Tue, 26 Jul 2011 18:59:01 -0400 Received: from mailhub.lss.emc.com (mailhub.lss.emc.com [10.254.221.145]) by hop04-l1d11-si01.isus.emc.com (RSA Interceptor) for ; Tue, 26 Jul 2011 18:58:49 -0400 Received: from mxhub13.corp.emc.com (mxhub13.corp.emc.com [128.221.56.102]) by mailhub.lss.emc.com (Switch-3.4.3/Switch-3.4.3) with ESMTP id p6QMwn1n001506 for ; Tue, 26 Jul 2011 18:58:49 -0400 Received: from mx14a.corp.emc.com ([169.254.1.245]) by mxhub13.corp.emc.com ([128.221.56.102]) with mapi; Tue, 26 Jul 2011 18:58:48 -0400 From: To: Date: Tue, 26 Jul 2011 18:58:47 -0400 Thread-Topic: storm Quebec City - draft minutes Thread-Index: AcxL55PLAYadNzwiRlascH4lzeeyfw== Message-ID: <7C4DFCE962635144B8FAE8CA11D0BF1E058948C331@MX14A.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] storm Quebec City - draft minutes 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, 26 Jul 2011 22:59:05 -0000 IETF storm (STORage Maintenance) WG Meeting minutes (draft) Tuesday, July 26, 2011, 1710-1810 Quebec City, QC, Canada ----------------------------------- Administrivia, agenda bashing, etc. - 10 min David L. Black, EMC & Tom Talpey, Microsoft (WG co-chairs) Blue sheets Note Well Review of WG milestones Note-taker Notes being taken in copy of agenda. Draft status - 5 min David L. Black, EMC (co-chair) iFCP update and associated iFCP MIB update - Published as RFCs 6172 and 61= 73 MPA update - Publication Requested, AD is processing Dave Harrington will review proposed new -06 from Arkady. iSCSI drafts (Consolidated, SAM and MIB) In WG Last Call iSER draft Has gotten unstalled - covered later in meeting. RDMA extensions (not currently a WG draft) Draft status was reviewed - see IETF web site. iSCSI Drafts (draft-ietf-storm-iscsi-cons-03, draft-ietf-storm-iscsi-sam-03= ) - 10 min Fred Knight, NetApp & WG co-chairs Issues that need attention from ongoing WG Last Call, if any iSCSI Protocol Level for version descriptors - approach is ok (T10 SPC-4 editor was on phone for this part of meeting), details will appear in nex= t version of draft. Status of engagement of iSCSI implementers to review these drafts Engagement ongoing, WG Last Call will be extended if needed for implement= er input. David Black can provide info that's useful to engage implementers without= asking them to read the entire multi-hundred page iSCSI draft. iSCSI MIB draft (draft-ietf-storm-iscsimib-00) - 5 min David L. Black, EMC (co-chair) on behalf of draft authors If time needed, status report under "Draft status" above may suffice Authors - please double-check that new conformance statements are being a= dded -> don't modify or delete old ones. iSER draft (draft-ietf-storm-iser-02) - 10 min Mike Ko, HuaweiSymantec (on behalf of draft authors) Summarize known topics & issues that need attention Summary discussed, see slides. RDMA Protocol Extensions Draft (draft-ietf-storm-rdmap-ext-01) - 20 min Hemal Shah, Broadcom (on behalf of draft authors) NOTE: Despite its filename, this is not an official storm WG draft. Discussion of draft contents and rationale. Number of bytes of immediate data - for subsequent discussion. 8 is a small number, but there are serious implementation limits. Question: Should WG should adopt this draft as a work item. Sense of room: Yes. Next actions: (1) Confirm that sense of room on the mailing list. (2) Send updated charter text with new item to AD. Make sure to characterize the work as new functionality. 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 david.black@emc.com Wed Jul 27 11:41:46 2011 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 2141E228006 for ; Wed, 27 Jul 2011 11:41:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.599 X-Spam-Level: X-Spam-Status: No, score=-106.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Q+wPNUH60fWo for ; Wed, 27 Jul 2011 11:41:45 -0700 (PDT) Received: from mexforward.lss.emc.com (mexforward.lss.emc.com [128.222.32.20]) by ietfa.amsl.com (Postfix) with ESMTP id 7999F21F8B6B for ; Wed, 27 Jul 2011 11:41:45 -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 p6RIfgPM031551 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Wed, 27 Jul 2011 14:41:43 -0400 Received: from mailhub.lss.emc.com (mailhubhoprd01.lss.emc.com [10.254.221.251]) by hop04-l1d11-si02.isus.emc.com (RSA Interceptor) for ; Wed, 27 Jul 2011 14:41:34 -0400 Received: from mxhub19.corp.emc.com (mxhub19.corp.emc.com [10.254.93.48]) by mailhub.lss.emc.com (Switch-3.4.3/Switch-3.4.3) with ESMTP id p6RIfSFB003511 for ; Wed, 27 Jul 2011 14:41:32 -0400 Received: from mx14a.corp.emc.com ([169.254.1.245]) by mxhub19.corp.emc.com ([10.254.93.48]) with mapi; Wed, 27 Jul 2011 14:41:31 -0400 From: To: Date: Wed, 27 Jul 2011 14:41:29 -0400 Thread-Topic: RDMA extensions of the work Thread-Index: AcxMjMyZDqKqpb3bQIaZLJxVw8PmdQ== Message-ID: <7C4DFCE962635144B8FAE8CA11D0BF1E058951349B@MX14A.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] RDMA extensions of the work 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, 27 Jul 2011 18:41:46 -0000 The sense of the storm WG meeting in Quebec City was that the storm WG should adopt draft-ietf-storm-rdmap-ext-01 as a WG draft, and work on the RDMA protocol extensions proposed therein. This new draft would progress behind our existing work - the iSCSI drafts are in WG Last Call, with the iSCSI MIB and iSER drafts intended to go to WG last Call in the next few months. If there are any objections to this, please send them to the list quickly. =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-778= 6 david.black@emc.com=A0=A0=A0=A0=A0=A0=A0 Mobile: +1 (978) 394-7754 ----------------------------------------------------