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
> 
>