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

Sorin,

Is the information or position you plan to present unsuitable for
the initial discussion via the WG alias?  My preference is that
we start here and finish at the WG meeting to trim a few weeks
from closing on these items.

Spencer

> -----Original Message-----
> From: nfsv4-bounces@ietf.org [mailto:nfsv4-bounces@ietf.org] On Behalf Of
> sfaibish
> Sent: Monday, October 18, 2010 12:41 PM
> To: Thomas Haynes
> Cc: nfsv4@ietf.org
> Subject: Re: [nfsv4] I-D Action:draft-ietf-nfsv4-ipv4v6-00.txt
> 
> Tom and Spencer,
> 
> 
> I propose to have a discussion on this topic at the IETF meeting. 10
> minutes should be enough. I have a problem with pushing this to 4.2 when
> we may need to address the issue sooner.
> 
> /Sorin
> 
> On Mon, 18 Oct 2010 15:28:05 -0400, Thomas Haynes <thomas@netapp.com>
> wrote:
> 
> > 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.
> >
> 
> 
> 
> --
> Best Regards
> 
> Sorin Faibish
> Corporate Distinguished Engineer
> Unified Storage Division
>          EMC²
> where information lives
> 
> Phone: 508-249-5745
> Cellphone: 617-510-0422
> Email : sfaibish@emc.com
> _______________________________________________
> nfsv4 mailing list
> nfsv4@ietf.org
> https://www.ietf.org/mailman/listinfo/nfsv4