IETF Logo Mail Archive

Re: [nfsv4] Review of draft-ietf-nfsv4-rfc5667bis-09

Tom Talpey <tom@talpey.com> Thu, 27 April 2017 16:12 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 3E1AE12941D for <nfsv4@ietfa.amsl.com>; Thu, 27 Apr 2017 09:12:04 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.899
X-Spam-Level:
X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, 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 Dqc34TOWLUl9 for <nfsv4@ietfa.amsl.com>; Thu, 27 Apr 2017 09:12:02 -0700 (PDT)
Received: from p3plsmtpa12-04.prod.phx3.secureserver.net (p3plsmtpa12-04.prod.phx3.secureserver.net [68.178.252.233]) (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 67AEB1270A0 for <nfsv4@ietf.org>; Thu, 27 Apr 2017 09:10:10 -0700 (PDT)
Received: from [192.168.0.56] ([24.218.182.144]) by :SMTPAUTH: with SMTP id 3lz8dO6X3P32L3lz9dSKsL; Thu, 27 Apr 2017 09:09:39 -0700
To: nfsv4@ietf.org
References: <CADaq8jdkGgL+H-yoO-+bTNbSYiE_1us9cN5SXY8QV0gfYfK0Ng@mail.gmail.com> <ce42960d-d1e9-8fa6-e98e-3e9b1a2af7d6@oracle.com> <f66e8e66-ba54-ff57-945a-7951eab2f8b1@talpey.com> <BB65A737-BDBD-4A23-9CEE-2EA153293842@oracle.com> <33468014-6695-a2da-1af8-f1f355fbe986@talpey.com> <CADaq8jcJJQ3TiVX6fFURg22YgNg=Cd7ezNQewjt6fgNK4LrPVg@mail.gmail.com> <F417EA11-D49F-420D-A64F-AE6A382B920C@oracle.com> <7213a956-6157-d0a6-432d-1da8d555d8e9@talpey.com> <A7BB8A22-53E3-4910-A6DE-C6103343D309@oracle.com> <6974E7E7-051B-4F28-A61A-DF6F841B248B@oracle.com> <af6ed8c5-6a7d-08ed-590b-1774f34e05f2@talpey.com> <6f23e91a-2d66-cbd8-aea9-2753ddfb9b79@oracle.com> <9726D6E8-0A9E-46C9-9DCF-FB2FB492622D@oracle.com> <700f84d2-a514-bfa8-7f0b-5ffd4173c16d@talpey.com> <EBC491EB-860B-401C-B192-9A8E9F8176B0@oracle.com>
From: Tom Talpey <tom@talpey.com>
Message-ID: <bc79d597-a165-9702-7358-397d11e20783@talpey.com>
Date: Thu, 27 Apr 2017 12:09:38 -0400
User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.8.0
MIME-Version: 1.0
In-Reply-To: <EBC491EB-860B-401C-B192-9A8E9F8176B0@oracle.com>
Content-Type: text/plain; charset="windows-1252"; format="flowed"
Content-Transfer-Encoding: 7bit
X-CMAE-Envelope: MS4wfDyx4f1IpReFK79ce4N4JqqxRgN5o+A9tofoIpN1aXZQKhtpY6B8E16sAFzbOdZCaR45KpbD6LeiDEJQdDmR69l7dK7pjOjN9gVhFvSv01A9E8gtQS1c +kWUA3inyLvJLo4V5JokjGoEvB5BHfy2KnxuvUgdaH5YnDYtQyirq+LH
Archived-At: <https://mailarchive.ietf.org/arch/msg/nfsv4/X_K4_WRuQb3qxw72gAewdNdu1bY>
Subject: Re: [nfsv4] Review of draft-ietf-nfsv4-rfc5667bis-09
X-BeenThere: nfsv4@ietf.org
X-Mailman-Version: 2.1.22
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: Thu, 27 Apr 2017 16:12:04 -0000

On 4/27/2017 11:53 AM, Chuck Lever wrote:
>
>> On Apr 27, 2017, at 8:46 AM, Tom Talpey <tom@talpey.com> wrote:
>>
>> On 4/27/2017 11:35 AM, Chuck Lever wrote:
>>> We could do something clever like add these limits to the
>>> RDMA CM private data.
>>
>> Please, no. Placing a message in that data is in itself a protocol,
>> and the size and support for that data is implementation defined,
>> in the RDMA layer.
>
> So you would object strenuously to
>
> https://datatracker.ietf.org/doc/draft-cel-nfsv4-rpcrdma-cm-pvt-msg/

Experimentally, I'm fine with it. As a Standard, I'm not as thrilled,
but you are correct I have not previously commented on your draft.
I'll try to find time to do so.

Tom.


>
>
>> If such a parameter exchange is required (and remember it needs to
>> go both ways), just define it as a full-blown negotiation, at the
>> RPC-RDMA, or better, the NFS layer. There are already some RDMA
>> values exchanged in the NFSv4.1 Session establishment, which could
>> be extended.
>
>
> --
> Chuck Lever
>
>
>
> _______________________________________________
> nfsv4 mailing list
> nfsv4@ietf.org
> https://www.ietf.org/mailman/listinfo/nfsv4
>
>

v2.23.0 | Report a Bug | By Email