Re: [nfsv4] FedFS: Comment about fedfsFslPort

[Chuck Lever <[e-mail]>]

On Oct 19, 2011, at 11:54 AM, James Lentini wrote:

> 
> 
> On Wed, 12 Oct 2011, Robert Thurlow wrote:
> 
>> Chuck Lever wrote:
>> 
>>> Thus there's no need for a separate FSL field to express a port value for
>>> NFS referrals.  Regardless of whether 3530bis is changed as proposed, I
>>> think we should remove the fedfsFslPort field, and leave that detail to the
>>> subclasses of fedfsFsl where it is meaningful.
>> 
>> Agreed.
> 
> Removing the optional fedfsFslPort attribute from the fedfsFsl 
> objectclass makes sense to me. Subclasses of fedfsFsl should include a 
> port when necessary.
> 
> However, I believe that an NFS FSL should include a port attribute.
> 
> As defined in RFC 5661, NFSv4.1 allows for modified universal 
> addresses to be included in a referral (see RFC 5661's definition of 
> the fls_server field in Section 11.10.1).
> 
> As defined in Section 4.2.1.2 of 
> draft-ietf-nfsv4-federated-fs-protocol-11, the format of the 
> fedfsFslHost attribute does not allow universal addresses or port 
> values to be specified.
> 
> The combination of a fedfsFslHost and fedfsFslPort (renamed to be a 
> fedfsNfsFslPort?) provide enough information to generate the modified 
> universal addresses used in NFSv4.1 referrals.

My concern about this is that now the file server would have to perform a DNS lookup to discover the address that is bound to the fedfsFslHost.  Can we guarantee that the client would get the same results from a DNS lookup, given that hostname?  Does that matter?

--
Chuck Lever
chuck[dot]lever[at]oracle[dot]com