Subject: [nfsv4] Murray Kucherawy's No Objection on draft-ietf-nfsv4-rpc-tls-08: (with COMMENT)

From: Murray Kucherawy via Datatracker <[email-masked]>
Date: Sun, 05 Jul 2020 23:10:58 -0700

Murray Kucherawy has entered the following ballot position for
draft-ietf-nfsv4-rpc-tls-08: 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-rpc-tls/

----------------------------------------------------------------------
COMMENT:
----------------------------------------------------------------------

I'm having trouble parsing the first paragraph of Section 4.1.

Thank you for including Section 6.

The REQUIRED in Section 7.1 isn't actually an interoperability concern, is it?

---

From: Chuck Lever <[email-masked]>
Date: Mon, 6 Jul 2020 10:47:27 -0400

Hi Murray -

Thanks for your review and comments.

> On Jul 6, 2020, at 2:10 AM, Murray Kucherawy via Datatracker <[email-masked]> wrote:
> 

The second sentence is perhaps overly complex, but the purpose is to
explain the compromise between backwards compatibility and security.
I propose this clarification:

OLD:

   The mechanism described in the current document interoperates fully
   with RPC implementations that do not support RPC-over-TLS.  Policy
   settings on the RPC-over-TLS-enabled peer determine whether RPC
   operation continues without the use of TLS or RPC operation is not
   permitted.

NEW:

   The mechanism described in the current document interoperates fully
   with RPC implementations that do not support RPC-over-TLS.  When an
   RPC server does not support RPC-over-TLS, policy settings on the RPC-
   over-TLS-enabled client determine whether RPC operation continues
   without the use of TLS, or RPC operation is not permitted.

> Thank you for including Section 6.

You're welcome!

> The REQUIRED in Section 7.1 isn't actually an interoperability concern, is it?

That is correct, this language is not addressing an interoperability issue.

The compliance requirement was added at the request of our second early
SecDir reviewer, Derrell Piper. The request was made in a private e-mail
to me.

--
Chuck Lever