Re: [nfsv4] I-D Action:draft-ietf-nfsv4-ipv4v6-00.txt

[Thomas Haynes <[e-mail]>]

Minor nits:

Page 7:

        same server identifier.  An example of well generated server
        identifier can be the one that includes the following:
   (c)
        (a)  a) MAC address
        (b)  b) Machine serial number

I would expect these items to be part of (b) above (The ':' gives me that expectation).

I find the (a) a) to be confusing.

----

Page 10:

   instead of the client IP address, for the indexing, as explained here
   -

   As mentioned in Client Identification (Section 6) -

   The client SHOULD always send the same client string, irrespective of
I can't tell if this is bad formatting or if two paragraphs are missing.


----

   There are scenarios where NFS implementations need to store IP
   addresses in persistent storage, like -

   NSM monitor/notify database.

   persistent reply cache.

I believe you want this lettered.

-------

A larger question on the draft as a whole would be whether we could add some
additional operations to NFSv4.2 to get rid of the guessing. I.e., could a client
send a server a list of IPv4 and IPv6 addresses that it is using and in return the
server respond with the equivalence addresses that it is using?

One issue I can see is that the machines might be on different subnets that use the
same IP addresses. I.e., 192.168.2.14 on the filer's e0a might be a different private subnet
than the 192.168.2.15 on the client's e1.

---------

Finally, it is understated, so I think you should bring more attention to it, but the problem
you deal with in Section 6 applies to symmetric single stack mode topologies as well. I.e.,
all current multi-homed IPv4 deployments.