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

[dhawal bhagwat <[e-mail]>]

>} Date: Mon, 18 Oct 2010 14:28:05 -0500
>} From: Thomas Haynes <[e-mail]>
>} Cc: [e-mail]
>} Subject: Re: [nfsv4] I-D Action:draft-ietf-nfsv4-ipv4v6-00.txt
>} 
>} 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.
>} 

Noted; will correct that in the next version.  ... 


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

No missing text/paragraphs there.  I suppose it would have been better 
formatted this way -- 

As mentioned in Client Identification (Section 6) - The client SHOULD 
always send the same client string, irrespective of

Will try to sort that out in the next version.  ... 


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

Noted; will correct that in the next version.  ... 

The remaining points below; I'll respond to the subsequent posts.

thanks,

-dhawal.


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