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

I had the intention to start a discussion and there it is a WG draft
before I had the chance to post the discussion we had at BAT.
I want to be sure that we all understand and address the same issue.
Thanks

/Sorin

On Mon, 18 Oct 2010 15:59:17 -0400, Spencer Shepler  
<spencer.shepler@gmail.com> wrote:

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

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