Re: [nfsv4] Benjamin Kaduk's No Objection on draft-ietf-nfsv4-rpcrdma-cm-pvt-data-07: (with COMMENT)
Tom Talpey <tom@talpey.com> Wed, 04 March 2020 04:10 UTC
Return-Path: <tom@talpey.com>
X-Original-To: nfsv4@ietfa.amsl.com
Delivered-To: nfsv4@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4684A3A0D7E for <nfsv4@ietfa.amsl.com>; Tue, 3 Mar 2020 20:10:53 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.895
X-Spam-Level:
X-Spam-Status: No, score=-1.895 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_MSPIKE_H3=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_HELO_NONE=0.001, SPF_NONE=0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LEphzpUwXPcO for <nfsv4@ietfa.amsl.com>; Tue, 3 Mar 2020 20:10:51 -0800 (PST)
Received: from p3plsmtpa06-08.prod.phx3.secureserver.net (p3plsmtpa06-08.prod.phx3.secureserver.net [173.201.192.109]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 95EB53A0D7F for <nfsv4@ietf.org>; Tue, 3 Mar 2020 20:10:51 -0800 (PST)
Received: from [172.20.1.219] ([50.235.29.75]) by :SMTPAUTH: with ESMTPSA id 9LMwjqpwEq7EN9LMwjSwZH; Tue, 03 Mar 2020 21:10:51 -0700
X-CMAE-Analysis: v=2.3 cv=caKsUULM c=1 sm=1 tr=0 a=VA9wWQeJdn4CMHigaZiKkA==:117 a=VA9wWQeJdn4CMHigaZiKkA==:17 a=jpOVt7BSZ2e4Z31A5e1TngXxSK0=:19 a=IkcTkHD0fZMA:10 a=yPCof4ZbAAAA:8 a=SEc3moZ4AAAA:8 a=48vgC7mUAAAA:8 a=h9i9pHyzog1lwhY_DtkA:9 a=QEXdDO2ut3YA:10 a=mYAOWqAtFUkA:10 a=1dbGxDndw2gA:10 a=5oRCH6oROnRZc2VpWJZ3:22 a=w1C3t2QeGrPiZgrLijVG:22 a=pHzHmUro8NiASowvMSCR:22 a=Ew2E2A-JSTLzCXPT_086:22
X-SECURESERVER-ACCT: tom@talpey.com
To: nfsv4@ietf.org
References: <158216101788.17661.6926758160404035704.idtracker@ietfa.amsl.com> <E718C1B8-B96B-4A64-8B92-C4ABEC7B5E5F@oracle.com> <20200220195155.GJ97652@kduck.mit.edu> <e74002a7-e1f1-a738-20d4-fa7d3395dd66@talpey.com> <BE0ECB52-596B-467C-BEB4-D76319016E32@oracle.com> <276AED2C-DD15-44F6-BA17-D74376B51D98@oracle.com>
From: Tom Talpey <tom@talpey.com>
Message-ID: <e70711cc-9d7e-a531-deec-7b09d1837c0b@talpey.com>
Date: Tue, 03 Mar 2020 20:10:50 -0800
User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:68.0) Gecko/20100101 Thunderbird/68.5.0
MIME-Version: 1.0
In-Reply-To: <276AED2C-DD15-44F6-BA17-D74376B51D98@oracle.com>
Content-Type: text/plain; charset="utf-8"; format="flowed"
Content-Language: en-US
Content-Transfer-Encoding: 7bit
X-CMAE-Envelope: MS4wfPGAch2X4ukMX5iXsCdHLYZxje0p5iR0Rhr6pPqhl3n4o3BS8n3FLgSxHN3CLAFnuOxuBAJyKDDQ/OpuGIx+5wzK92LreOL6qSKwW3qr2f/RDAs36ySS awmCxgtmNL4LYZaOIKVeK0m1p/fD5VEFy9kcAWJjD2omxsN4At409a/+
Archived-At: <https://mailarchive.ietf.org/arch/msg/nfsv4/F77EfYcuYx72fw3-WNt5gdtwPNE>
Subject: Re: [nfsv4] Benjamin Kaduk's No Objection on draft-ietf-nfsv4-rpcrdma-cm-pvt-data-07: (with COMMENT)
X-BeenThere: nfsv4@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: NFSv4 Working Group <nfsv4.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/nfsv4>, <mailto:nfsv4-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/nfsv4/>
List-Post: <mailto:nfsv4@ietf.org>
List-Help: <mailto:nfsv4-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/nfsv4>, <mailto:nfsv4-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 04 Mar 2020 04:10:53 -0000
On 3/3/2020 6:45 AM, Chuck Lever wrote: > Hello - > >> On Mar 1, 2020, at 1:13 PM, Chuck Lever <chuck.lever@oracle.com> wrote: >> >> >> >>> On Mar 1, 2020, at 12:24 PM, Tom Talpey <tom@talpey.com> wrote: >>> >>> On 2/20/2020 11:51 AM, Benjamin Kaduk wrote: >>>> Hi Chuck, >>>> On Thu, Feb 20, 2020 at 10:13:26AM -0500, Chuck Lever wrote: >>>>> Hi Ben, thanks for your comments! Responses and questions below. >>>>> >>>>> >>>>>> On Feb 19, 2020, at 8:10 PM, Benjamin Kaduk via Datatracker <noreply@ietf.org> wrote: >>>>>> >>>>>> Benjamin Kaduk has entered the following ballot position for >>>>>> draft-ietf-nfsv4-rpcrdma-cm-pvt-data-07: No Objection >>>>>> >>>>>> When responding, please keep the subject line intact and reply to all >>>>>> email addresses included in the To and CC lines. (Feel free to cut this >>>>>> introductory paragraph, however.) >>>>>> >>>>>> >>>>>> Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html >>>>>> for more information about IESG DISCUSS and COMMENT positions. >>>>>> >>>>>> >>>>>> The document, along with other ballot positions, can be found here: >>>>>> https://datatracker.ietf.org/doc/draft-ietf-nfsv4-rpcrdma-cm-pvt-data/ >>>>>> >>>>>> ... >>>>>> Section 6 >>>>>> >>>>>> The RPC-over-RDMA version 1 protocol framework depends on the >>>>>> semantics of the Reliable Connected (RC) queue pair (QP) type, as >>>>>> defined in Section 9.7.7 of [IBA]. The integrity of CM Private Data >>>>>> >>>>>> It's interesting to see such a reference to [IBA], when IIUC the RFC >>>>>> 8166 protocol is not limited to Infiniband as the underlying transport. >>>>> >>>>> Correct, RPC/RDMA can operate on iWARP and RoCE as well. However: >>>>> >>>>> - both of those RDMA fabric types also support RC QPs, and >>>>> - [IBA] appears to be the only publication where "RC QP type" >>>>> is defined, though I could be wrong. >>>>> >>>>> I don't read this text as suggesting that RPC/RDMA cannot operate >>>>> on those alternate fabrics, but perhaps I am "too close to the >>>>> code". >>>> I don't read it that way, either; I was just noting that it was surprising >>>> that this is the only reference available. If it is, then it is, though, >>>> so no need to change anything. >>> >>> The term "RC" or "Reliable Connected" is an InfiniBand-specific term. >>> The iWARP protocol has neither a datagram nor unreliable mode, therefore >>> it is an "RC" transport by definition, in InfiniBand-speak. >>> >>> I do agree that referring normatively to the IB Architecture is odd, >>> and perhaps unnecessary. Alternatively, the sentence could be relaxed >>> to avoid this IB-specific term, and describe the situation in an >>> informative way. "Supports RC-type Infiniband and iWARP Queue Pairs." >> >> No objection to that phrasing, and that certainly explains why RFC 8166 >> does not refer directly to RC. > > Because this was directly commented on several times during IESG balloting, > I'm providing an update via this email thread. The new second paragraph of > the Security Considerations section will read: > > On InfiniBand, the RPC-over-RDMA version 1 protocol framework depends > on the semantics of the Reliable Connected (RC) queue pair (QP) type, > as defined in Section 9.7.7 of [IBA]. iWARP queue pairs have neither > a datagram nor an unreliable mode, therefore they are always reliable > connections [RFC5040]. The integrity of CM Private Data and the > authenticity of its source are ensured by the exclusive use of > reliable queue pairs. Any attempt to interfere with or hijack data > in transit on an RC connection results in the RDMA provider > terminating the connection. > > Also, the IBA reference has been moved back to the Informative References > subsection. > > I will request these updates be made to the document during AUTH48, unless > there are objections or further corrections. I agree with the changes, but stylistically I might suggest rearranging the sentences for emphasis and flow, such as: The integrity of CM Private Data and the authenticity of its source are ensured by the exclusive use of reliable queue pairs. iWARP queue pairs are always reliable connections [RFC5040]. On InfiniBand, the RPC-over-RDMA version 1 protocol framework depends on the semantics of the Reliable Connected (RC) queue pair (QP) type, as defined in Section 9.7.7 of [IBA]. Any attempt to interfere with or hijack data in transit on a reliable connection in either transport protocol results in the RDMA provider terminating the connection. Just a suggestion! Tom. >>> There is a document describing the iWARP consumer-visible semantics, >>> in 2003's https://tools.ietf.org/html/draft-hilland-rddp-verbs-00 >>> However, this document was never adopted as an RDDP work item, and >>> was not developed further. It is nonetheless an excellent reference >>> and is frequently referred to. >>> >>> Tom. >> >> -- >> Chuck Lever > > -- > Chuck Lever > > > > _______________________________________________ > nfsv4 mailing list > nfsv4@ietf.org > https://www.ietf.org/mailman/listinfo/nfsv4 > >
- [nfsv4] Benjamin Kaduk's No Objection on draft-ie… Benjamin Kaduk via Datatracker
- Re: [nfsv4] Benjamin Kaduk's No Objection on draf… Chuck Lever
- Re: [nfsv4] Benjamin Kaduk's No Objection on draf… Benjamin Kaduk
- Re: [nfsv4] Benjamin Kaduk's No Objection on draf… Chuck Lever
- Re: [nfsv4] Benjamin Kaduk's No Objection on draf… Benjamin Kaduk
- Re: [nfsv4] Benjamin Kaduk's No Objection on draf… Tom Talpey
- Re: [nfsv4] Benjamin Kaduk's No Objection on draf… Chuck Lever
- Re: [nfsv4] Benjamin Kaduk's No Objection on draf… Chuck Lever
- Re: [nfsv4] Benjamin Kaduk's No Objection on draf… Tom Talpey
- Re: [nfsv4] Benjamin Kaduk's No Objection on draf… Chuck Lever