Re: [nfsv4] Genart last call review of draft-ietf-nfsv4-rpc-tls-07

worley@ariadne.com Thu, 28 May 2020 03:06 UTC

Return-Path: <worley@alum.mit.edu>
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 683F93A0B5F for <nfsv4@ietfa.amsl.com>; Wed, 27 May 2020 20:06:59 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.639
X-Spam-Level:
X-Spam-Status: No, score=-1.639 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HEADER_FROM_DIFFERENT_DOMAINS=0.249, SPF_HELO_NONE=0.001, T_SPF_PERMERROR=0.01, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=comcastmailservice.net
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 h_JQxlWTp12H for <nfsv4@ietfa.amsl.com>; Wed, 27 May 2020 20:06:58 -0700 (PDT)
Received: from resqmta-ch2-07v.sys.comcast.net (resqmta-ch2-07v.sys.comcast.net [IPv6:2001:558:fe21:29:69:252:207:39]) (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 764943A0B57 for <nfsv4@ietf.org>; Wed, 27 May 2020 20:06:58 -0700 (PDT)
Received: from resomta-ch2-07v.sys.comcast.net ([69.252.207.103]) by resqmta-ch2-07v.sys.comcast.net with ESMTP id e8kwjmPwpSe0Re8sijkz2H; Thu, 28 May 2020 03:06:56 +0000
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=comcastmailservice.net; s=20180828_2048; t=1590635216; bh=WGMZbltFPJQpBn4ZwYsOmMZVlz6ww3z2DaNggtXKxwM=; h=Received:Received:Received:Received:From:To:Subject:Date: Message-ID; b=F5nCTv0f48KP0m52a6Jxi2dUMBFF8QIUFahOuHE1M8Dnnf2AUm5lja1wdksptVGy7 swcJTlj5fGoas2qneDjKy0vF7YZc8d02sxp+5oR+xSBBQTfmshD+sy75mfYvY3We8y qn8xUJA2Dm0vWgeFuLobrfig1MCMEDwKmNGV0EkBEFQ2HijEEESyr59Oj8wcDHZZUg QPIacxLzoA+1TBwYWb+oihXkJiu5JuAazT9s6yVApn/AjZ8kYl2CS8pSSKkqd2M4J7 PqhB/Cqc8V+GmNb26GzabozIkQtD06OzWOehBNY1nGvR5FEqhau2qXraXniyfYV6gS lsKzOPBzMqLlw==
Received: from hobgoblin.ariadne.com ([IPv6:2601:192:4a00:430:222:fbff:fe91:d396]) by resomta-ch2-07v.sys.comcast.net with ESMTPA id e8shjn9SYD1Lze8shjEzan; Thu, 28 May 2020 03:06:56 +0000
X-Xfinity-VMeta: sc=-100.00;st=legit
Received: from hobgoblin.ariadne.com (hobgoblin.ariadne.com [127.0.0.1]) by hobgoblin.ariadne.com (8.14.7/8.14.7) with ESMTP id 04S36sSP025450; Wed, 27 May 2020 23:06:54 -0400
Received: (from worley@localhost) by hobgoblin.ariadne.com (8.14.7/8.14.7/Submit) id 04S36smN025447; Wed, 27 May 2020 23:06:54 -0400
X-Authentication-Warning: hobgoblin.ariadne.com: worley set sender to worley@alum.mit.edu using -f
From: worley@ariadne.com
To: Chuck Lever <chuck.lever@oracle.com>
Cc: gen-art@ietf.org, last-call@ietf.org, nfsv4@ietf.org, draft-ietf-nfsv4-rpc-tls.all@ietf.org
In-Reply-To: <A3F681DA-F363-4EE5-A045-DF1EB97A55AF@oracle.com> (chuck.lever@oracle.com)
Sender: worley@ariadne.com
Date: Wed, 27 May 2020 23:06:54 -0400
Message-ID: <87imggiwq9.fsf@hobgoblin.ariadne.com>
Archived-At: <https://mailarchive.ietf.org/arch/msg/nfsv4/CASLRVykPCMdW01gFVir0dHBMi8>
Subject: Re: [nfsv4] Genart last call review of draft-ietf-nfsv4-rpc-tls-07
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, 28 May 2020 03:07:00 -0000

Chuck Lever <chuck.lever@oracle.com> writes:
>> I think you want s/must/MUST/.  There's also an unstated requirement
>> that the RPC consumers have some way of accessing this information.
>
> IMHO the non-normative form of "must" is appropriate in this case.
>
>  - The text is not specific enough to be part of an enforceable normative
>    compliance statement.
>
>  - The remark here is about an internal RPC consumer API, as you note.
>    Such APIs are not something on which this document can place hard
>    requirements.
>
> However, I'm open to further comments and discussion.

Hmmm, I think I'll leave that to the Security Directorate.

Dale