Re: [nfsv4] Genart last call review of draft-ietf-nfsv4-rpc-tls-07 Thu, 28 May 2020 03:02 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 0F2523A0B55 for <>; Wed, 27 May 2020 20:02:59 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.639
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: (amavisd-new); dkim=pass (2048-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id kBzPI21sy9_y for <>; Wed, 27 May 2020 20:02:58 -0700 (PDT)
Received: from ( [IPv6:2001:558:fe21:29:69:252:207:38]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id CEE853A0B54 for <>; Wed, 27 May 2020 20:02:57 -0700 (PDT)
Received: from ([]) by with ESMTP id e8nzjmoglaccEe8opjFauj; Thu, 28 May 2020 03:02:56 +0000
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20180828_2048; t=1590634976; bh=+cDLzLA/DxmaYd/hH7rEZHH/iHG96gI5aja722HQXCI=; h=Received:Received:Received:Received:From:To:Subject:Date: Message-ID; b=o66cIIzrkBuIWWdfaGIxbSOFWeHvDVOURFWh7NVzQQJJlGpRF1oubC8QlhxtBjlXi 2ADmaSnjGhCpuE0OO71GDZ6haxCC6ll9gUVOYXXv/fjk+mAmRxrmauKvLPYbevDKgw yfyankoWW1enBCUnrMBrp/J2pCPMx29Epy5hR4M8Gu6k87dejxlUCrVm9OJvwp9+V0 yiWraU8khQKhB7/eTUXMTrq0mQbC45xSopm17i2pAYXN7bAW0SrdC7rHgq9pysW+OY HSTlyLaftQKC7HAJSeFspMXbeN88n/tP3jeo70EhLcsUS+eN7/GBaHS281ODe0Y7HS kPLO0RM88+PLQ==
Received: from ([IPv6:2601:192:4a00:430:222:fbff:fe91:d396]) by with ESMTPA id e8ogj7dHQtcQpe8okjtuNT; Thu, 28 May 2020 03:02:52 +0000
X-Xfinity-VMeta: sc=-100.00;st=legit
Received: from ( []) by (8.14.7/8.14.7) with ESMTP id 04S32jcn025019; Wed, 27 May 2020 23:02:45 -0400
Received: (from worley@localhost) by (8.14.7/8.14.7/Submit) id 04S32jLB025016; Wed, 27 May 2020 23:02:45 -0400
X-Authentication-Warning: worley set sender to using -f
To: Chuck Lever <>
In-Reply-To: <> (
Date: Wed, 27 May 2020 23:02:45 -0400
Message-ID: <>
Archived-At: <>
Subject: Re: [nfsv4] Genart last call review of draft-ietf-nfsv4-rpc-tls-07
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: NFSv4 Working Group <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Thu, 28 May 2020 03:02:59 -0000

Chuck Lever <> writes:
>> Somewhere in this section you need to specify the semi-obvious:
>>   [...]
> I can add something like this in Section 4.1, but note that Sections
> 5.1.1 and 5.1.2 already explain the relationships between TCP/UDP
> and TLS/DTLS, respectively.

Hmmm, I want to answer "yes and no".  I think those passages were
written with the presupposition that those relationships were already
known and specified, and the text talks *about* that relationship.
E.g., 5.1.1 qualifies the sentence with "Typically", and neither section
uses normative language.

The point is that if you upgrade, if you start with TCP, you MUST
upgrade to TLS, and if you start with UDP, you MUST upgrade to DTLS.
Whereas it is conceivable that one could start with UDP to port 111,
discover rpc-tls support and then do a TLS connection to TCP port 111
("the same port") to continue.  (After all, every NFS server listens on
111 both with UDP and TCP, right?)  And you have to state that
explicitly as a requirement.

>> I can't find any discussion of "backchannel operation" in RFC 5531.
>> Might this need an additional reference?
> I agree that a deeper introduction of "backchannel operation" would
> be helpful in this section.
> There doesn't seem to be any adequate explanation for backchannel
> operation in documents prior to RFC 8167, which explains reverse-
> direction RPC operation over an RDMA transport.
> Perhaps the best I can do here is add a paragraph introducing the
> concept, and use the RFC 8167 terminology instead of "backchannel"?
> Let me review RFC 8167 and see if I can reference it sensibly in
> the context of RPC on TCP.

I wouldn't even go that far.  Reading the I-D, I did not feel that I
needed any additional knowledge of how "backchannel" is done to
understand what the I-D was requiring.  But the fact that I couldn't
trace from any reference to the specification of backchannel seems like
an inadequacy.  IMO just a reference here to 8167 would suffice.

>> I suspect that "iPAddress" is not capitalized correctly.
> This is the capitalization used in RFC 6125, which is cited nearby
> this text.

So I'm wrong there!