Re: [nfsv4] WG last call for draft-ietf-nfsv4-rpcrdma-cm-pvt-data-02.txt (Ends May 31st)
Tom Talpey <tom@talpey.com> Thu, 30 May 2019 18:31 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 6FDFD120046 for <nfsv4@ietfa.amsl.com>; Thu, 30 May 2019 11:31:01 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.897
X-Spam-Level:
X-Spam-Status: No, score=-1.897 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, 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 B52Spwsm0_zO for <nfsv4@ietfa.amsl.com>; Thu, 30 May 2019 11:30:59 -0700 (PDT)
Received: from p3plsmtpa06-04.prod.phx3.secureserver.net (p3plsmtpa06-04.prod.phx3.secureserver.net [173.201.192.105]) (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 458C3120323 for <nfsv4@ietf.org>; Thu, 30 May 2019 11:30:54 -0700 (PDT)
Received: from [192.168.0.67] ([24.218.182.144]) by :SMTPAUTH: with ESMTPSA id WPpFh6woMZelWWPpFhR2Tq; Thu, 30 May 2019 11:30:53 -0700
To: nfsv4@ietf.org
References: <CAFt6BanN_L9EyLyf3Hfpd1nBHaRNh5-jppcXNEGugCfiFvOKww@mail.gmail.com>
From: Tom Talpey <tom@talpey.com>
Message-ID: <3d25b43c-cbb7-1681-e647-fc4b3c6ba0ba@talpey.com>
Date: Thu, 30 May 2019 14:30:52 -0400
User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:60.0) Gecko/20100101 Thunderbird/60.7.0
MIME-Version: 1.0
In-Reply-To: <CAFt6BanN_L9EyLyf3Hfpd1nBHaRNh5-jppcXNEGugCfiFvOKww@mail.gmail.com>
Content-Type: text/plain; charset="utf-8"; format="flowed"
Content-Language: en-US
Content-Transfer-Encoding: 8bit
X-CMAE-Envelope: MS4wfK8+GKOR84GtverxhQ5zpPP6+Myk3xrNHF32GbXKkpFtEtRdHRgev4jxOPS2TeEAisM3f6qkCyJaZw4H9GC22g5ERaNqB/rAsSfC5EqvofnBTvtEMj8R 5SEBQ4O5G1WWPhnMn+FSpwHXuY6xz6h4CBulRARswUOQEK5IzUiwGS0A
Archived-At: <https://mailarchive.ietf.org/arch/msg/nfsv4/F1lW6vW3zhbjvgrIdadxvsVTHsQ>
Subject: Re: [nfsv4] WG last call for draft-ietf-nfsv4-rpcrdma-cm-pvt-data-02.txt (Ends May 31st)
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: Thu, 30 May 2019 18:31:02 -0000
On 5/6/2019 12:46 PM, spencer shepler wrote: > > All, > > Thanks to Chuck, we have the following I-D entering working group last call. > > “RDMA Connection Manager Private Data For RPC-Over-RDMA Version 1” > > We will start the review today and end on May 31^st . > > The source of the I-D can be found here and comments should be sent to > the WG alias. > > https://datatracker.ietf.org/doc/draft-ietf-nfsv4-rpcrdma-cm-pvt-data/ I have some comments on final review. In the Abstract, it should be stated that the addition of the private data payload specified in the draft is an optional extension, and that the rpcrdmav1 protocol does not require it. In the Introduction final paragraph the statement "The message format can be extended as needed" is perhaps overly broad. I think the better way to state what is meant here is that the specification is intended to be further extensible, within the normal scope of such IETF work, and it defines an IANA registry for this. A forward reference to section 5 would help. In section 3.2 third paragraph two comments. First, it describes an advantage of avoiding a context switch. This is a local implementation matter, and not really something the protocol can or cannot proscribe. It would be state the benefit in protocol terms, such as "avoids processing of the invalidate completion", then go on to say which may enable avoiding interrupt(s) and context switch(es). Second, a nit - the word "upshot" is slang. Suggest "benefit". At the end of section 3.2, the final paragraph is quite mysterious. It refers to "a simple signaling mechanism" and "some NFS/RDMA client". Really, something more needs to be said here. If this signaling mechanism involves a protocol payload, then definitely so. Can you elaborate? I admit I don't fully understand what is meant here. In section 4, the scope of the properties are correctly confined to the connection on which they are exchanged. But, this does not mention the visibility of the properties to the upper layer consumer, which must be aware of them, especially when reconnecting since RDMA behaviors may change. I suggest a short statement in sectin 4.1 Interoperability Considerations to this point. In section 7, the vulnerability is in the RDMA-CM protocol, not this protocol. And, private data is carried differently by different lower layers - for example in the IETF iWARP family, it's part of MPA. Honestly, I'm not sure this is relevant to this document. It basically inherits all the considerations of the protocols it extends. Tom.
- [nfsv4] WG last call for draft-ietf-nfsv4-rpcrdma… spencer shepler
- Re: [nfsv4] WG last call for draft-ietf-nfsv4-rpc… Tom Talpey
- Re: [nfsv4] WG last call for draft-ietf-nfsv4-rpc… Chuck Lever
- Re: [nfsv4] WG last call for draft-ietf-nfsv4-rpc… Tom Talpey
- Re: [nfsv4] WG last call for draft-ietf-nfsv4-rpc… Chuck Lever
- Re: [nfsv4] WG last call for draft-ietf-nfsv4-rpc… Tom Talpey