[nfsv4] Ben Campbell's Discuss on draft-ietf-nfsv4-rfc3530-migration-update-07: (with DISCUSS and COMMENT)

["Ben Campbell" <[e-mail]>]

Ben Campbell has entered the following ballot position for
draft-ietf-nfsv4-rfc3530-migration-update-07: Discuss

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-rfc3530-migration-update/



----------------------------------------------------------------------
DISCUSS:
----------------------------------------------------------------------

This draft recommends the use of the uniform client-ID string approach. I
admit to not being an NFS expert, but that seems to add a lot of
complexity. It seems counter to advice in 7530. Section 4.7 of this draft
points out that this may create interop problems with some servers. It
seems to increase the privacy impact of persistent and potentially user
and hardware identifying client-ID strings. There seems to be an issue of
balancing harms here. I'd like to see some text describing how the harm
avoided by the uniform approach balances out with the other issues. 

The security considerations seem incomplete. This draft makes a number of
normative changes and clarifications that are likely to introduce new
security and/or privacy considerations that are not mentioned. This is
especially true for the guidance about using uniform client-IDs.


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

I support Alissa's DISCUSS comments concerning the privacy implications
of a persistent client ID.  I am also concerned that the suggested
approaches might help enable client fingerprinting. 

- 4.2 (occurs twice)
The text says clients MAY send different strings to different servers. I
think there may be privacy and tracking implications here, even if the
client-ID is constructed without IP addresses or hardware identifiers. Is
MAY strong enough? This ties in with the recommendations throughout the
document about using persistent IDs across multiple servers. Perhaps
there should be guidance to use different strings in general, except in
cases where state-sharing is likely to come into play? (e.g. across
completely different mount points?)

-4.2, paragraph starting with "As a security measure"
It might be helpful to briefly describe the security concern.
-- paragraph starting with "The difficulty is more severe..."
I think this paragraph warrants some normative guidance.

- 4.3:
How terrible is it if client state is prematurely deleted? Much of this
draft, including the guidance to use uniform IDs across servers, seem to
treat premature deletion as an ultimate harm, and do not balance that
risk against the privacy and complexity issues that it may create.

- 4.7, 2nd bullet list:
How does the client know whether a server might return NFS4ERR_MOVED?

-7.5, 2nd bullet:
"trust relationship" by itself doesn't mean much. Who trusts what to do
what?


Editorial:

- 3, paragraph starting with "Specification of requirements for the
server..."
The first sentence hard to parse. The last sentence is also confusing. I
think you mean to say that NFV4.0 non-normatively encourages the
practice? A careless reader is likely to interpret "not 'RECOMMENDED'" as
"NOT RECOMMENDED".

-3, paragraph starting with "to further complicate matters":
The paragraph uses confusing language. I _think_ you mean that servers
have assumed a particular client implementation pattern, and can’t work
with others. But it sounds like it says clients have universally adopted
a particular pattern, in which case the interop problem doesn’t make
sense.

-3, 4th paragraph from end:
Please don't use 2119 keywords to talk about how the other text uses 2119
keywords. Or at least put "RECOMMENDs" in quotes.

- 4.2, bullet entry starting with "The verifier is a client incarnation
identifier..."
The second sentence is hard to parse. (The original version was hard, and
this version is harder.)
--bullet starting with "The string MAY...":
redundant to similar guidance earlier in section.
-- paragraph starting with "Distinct servers MAY assign..."
What do you mean by "trunking"? I don't see the term defined anywhere.

- 4.6, "... cause us to RECOMMEND use of the uniform client id string"
I don't think that sentence should use the 2119 "RECOMMEND" keyword.

- 4.8: The repeated use of first person pronouns in this section (and
elsewhere) is confusing. It's not always clear if "we" means the draft
authors, implementors, or the implementation itself.
-- paragraph before 2nd bullet list:
First sentence is hard to parse.

- 7.4.5, first paragraph:
What does it mean to "make the following notations"?

- 7.5, third bullet:
First sentence is hard to parse.

- section 7.6 and 8:
The structure is confusing. 7.6 says it modifies the security
considerations, but is not clear whether that means the security
considerations in 7530, or in this document. 8 says "It is to be modified
in section 7.6", without a clear antecedent for "It".