NFSv4.0 Migration: Specification Update
draft-ietf-nfsv4-rfc3530-migration-update-08

Thanks for addressing my DISCUSS. 

---

My comments are about the example given in Section 4.9. 

I understand from 4.2 that the requirements for the construction of the client id are:

1) It should be unique per client.
2) It should persist through reboots.

As best I can tell, embedding the client's IP address in the client id is not a requirement (but I admit to not fully understanding NFS!). So why is it suggested that the client's network address be embedded in the client id?

There are also a few privacy-related issues with the example:

- Some clients will change their IP addresses over time to avoid being tracked. By suggesting that some prior address be used in the client id, there is an implied requirement on the client to maintain a history of previously used addresses, which could be exploited for tracking purposes. 

- Permanent device identifiers (such as a serial numbers) should not be embedded in a client id on the wire, again to avoid facilitating tracking by any other party that knows the serial number.

It seems to me that to avoid all of the issues above, perhaps a better example to provide would be hash(some client secret, some source of uniqueness, server identity). That gives the client id a good chance of being unique without exposing other identifiers related to the client. And then if the existing guidance about saving and re-using the value is followed, it won't be necessary to try to shoehorn in an old IP address or persistent device identifiers when the clientid needs to be regenerated.

No objection, but I have to wonder why this work wasn't folded into RFC7530 (which work seems to have been around long enough).

My co-ART-ADs have this very much in hand with their DISCUSS points, and I won't add to that.

[ I've cleared my discuss since discussion is happening. I moved the following two discuss points into the comment section:

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.]


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".

Quick update from Victor Kuarsingh, part of the OPS DIR review:
I am still going through the draft.  I is taking me long then normal since the writing style is making it hard to parse faster.  So far, here is where my analysis is going.

    edits needed to fix up language (very conversational in nature – not sure if that’s what the IETf normally wants)
    it’s hard to extract the updated requirements in the document as they appear both in bullet points, and in paragraphs (thus far)
    Quite a bit of time spent on what should not be done by servers/systems (seems helpful).
    However, the entire document was focused on fixing implementation problems/challenges conducting migrations for NFSv4.0 which should be benefiting (given it’s based on real world implementation challenges)
    I had pre-scanned the document ahead of time, and it appears the guidance in section 5/6 will be where the meat of the discussion is.
    Nothing really bad jumps out at me just yet (other then hard to follow).

No objection to the publication of this document, but I do have a few non-blocking points:

1. I support Alissa's DISCUSS on the privacy issues surrounding the client ID and will be following the discussion intently.

2. It would be nice if pointers to the actual definition of data types like verifier4 and cb_client4 were provided.

I agree with Alissa's discuss about client ids and
apologies also from me for not spotting that in 7530.  The
persistent-across-reboots-forever thing that this seems to
be encouraging (if I'm reading it correctly) is just a bit
much really. But maybe we're lucky in that we now have a
chance to improve on that. (Further apologies for not 
having actually had time to read this properly, I'm happy
to be part of a discussion on how what to do here if
that helps though and will read it properly if involved
in that;-)