gmane.ietf.nfsv4

Re: draft-adamson-nfsv4-multi-domain-federated-fs-reqs-02

Spencer Shepler — 2013-05-18T01:54:59

Thanks for the effort here, Andy, and the comments, Chuck.

I am curious if there is interest in this work within the Working Group and does it help solve problems being experienced today?

The long way of saying: is Andy's a) true?

Please speak up...

Spencer

From: Andy Adamson [mailto:androsadamson< at >gmail.com]
Sent: Friday, May 17, 2013 1:33 PM
To: Spencer Shepler
Cc: NFSv4
Subject: draft-adamson-nfsv4-multi-domain-federated-fs-reqs-02

Hi Spencer

So, I have had zero comments on this draft. AFAICS this means:

a) The subject is of no interest
b) The subject is of interest but the draft is horrible
c) The subject is of mild interest and eveyone is busy
d) The subject is of interest and the draft is perfect

I'd like it to be "d" but I don't believe it :)

Anyway,  I'm not putting any more time into multi-domain work until this draft is either put to rest or commented on.

-->Andy


_______________________________________________
nfsv4 mailing list
nfsv4< at >ietf.org
https://www.ietf.org/mailman/listinfo/nfsv

Re: Soliciting Agenda items for IETF 87NFSv4workinggroupmeeting

Spencer Shepler — 2013-05-18T00:41:16

I have this on the list, Marc.

Spencer

From: Marc Eshel [mailto:eshel< at >us.ibm.com]
Sent: Friday, May 17, 2013 5:22 PM
To: Matt W. Benjamin
Cc: nfsv4< at >ietf.org; nfsv4-bounces< at >ietf.org; Spencer Shepler
Subject: Re: [nfsv4] Soliciting Agenda items for IETF 87 NFSv4 working group meeting

I meant to say, I will send an email to the list soon for pre-meeting discussion.
Marc.

"Matt W. Benjamin" <matt< at >linuxbox.com<mailto:matt< at >linuxbox.com>> wrote on 05/17/2013 12:36:29 PM:

_______________________________________________
nfsv4 mailing list
nfsv4< at >ietf.org
https://www.ietf.org/mailman/listinfo/nfsv4

Re: Soliciting Agenda items for IETF 87NFSv4workinggroupmeeting

Marc Eshel — 2013-05-18T00:21:31

I meant to say, I will send an email to the list soon for pre-meeting 
discussion.
Marc.

"Matt W. Benjamin" <matt< at >linuxbox.com> wrote on 05/17/2013 12:36:29 PM:

_______________________________________________
nfsv4 mailing list
nfsv4< at >ietf.org
https://www.ietf.org/mailman/listinfo/nfsv4

Re: NFSv4.2 XDR typo

Haynes, Tom — 2013-05-17T21:26:56

Ack - thanks

On May 17, 2013, at 1:16 PM, Chuck Lever <chuck.lever< at >oracle.com> wrote:


_______________________________________________
nfsv4 mailing list
nfsv4< at >ietf.org
https://www.ietf.org/mailman/listinfo/nfsv4

Re: draft-adamson-nfsv4-multi-domain-federated-fs-reqs-02

Andy Adamson — 2013-05-17T20:38:07

Hi Chuck

Please resend - I can't find them...

Thanks

-->Andy


On Fri, May 17, 2013 at 4:33 PM, Chuck Lever <chuck.lever< at >oracle.com> wrote:

_______________________________________________
nfsv4 mailing list
nfsv4< at >ietf.org
https://www.ietf.org/mailman/listinfo/nfsv4

Re: draft-adamson-nfsv4-multi-domain-federated-fs-reqs-02

Chuck Lever — 2013-05-17T20:33:46

On May 17, 2013, at 4:32 PM, Andy Adamson <androsadamson< at >gmail.com> wrote:


I sent a bunch of comments a week or two ago.  If you didn't see them, I can resend.

draft-adamson-nfsv4-multi-domain-federated-fs-reqs-02

Andy Adamson — 2013-05-17T20:32:32

Hi Spencer

So, I have had zero comments on this draft. AFAICS this means:

a) The subject is of no interest
b) The subject is of interest but the draft is horrible
c) The subject is of mild interest and eveyone is busy
d) The subject is of interest and the draft is perfect

I'd like it to be "d" but I don't believe it :)

Anyway,  I'm not putting any more time into multi-domain work until this
draft is either put to rest or commented on.

-->Andy
_______________________________________________
nfsv4 mailing list
nfsv4< at >ietf.org
https://www.ietf.org/mailman/listinfo/nfsv4

NFSv4.2 XDR typo

Chuck Lever — 2013-05-17T20:16:09

Hi Tom-

   FATTR4_CHNAGE_SEC_LABEL   = 81;

Re: Soliciting Agenda items for IETF 87NFSv4workinggroupmeeting

Matt W. Benjamin — 2013-05-17T19:36:29

I think this would be very interesting.

----- "Marc Eshel" <eshel< at >us.ibm.com> wrote:

Re: Soliciting Agenda items for IETF 87 NFSv4workinggroupmeeting

Marc Eshel — 2013-05-17T19:23:09

I would like to add a 20 minutes presentation to the agenda to propose a 
more coherent data caching for NFS.

The objective of this presentation will be to talk about how to improve 
NFS client caching for NFS4.3. I would like to find out from the group if 
one, others see this as a useful  objective, and two, if extending the 
delegations feature is the right approach. I will post another email with 
more detail for post meeting discussion.
Marc.



From:   Spencer Shepler <sshepler< at >microsoft.com>
To:     "Noveck, David" <david.noveck< at >emc.com>, "nfsv4< at >ietf.org" 
<nfsv4< at >ietf.org>, 
Date:   05/14/2013 10:12 PM
Subject:        Re: [nfsv4] Soliciting Agenda items for IETF 87 NFSv4 
working group   meeting
Sent by:        nfsv4-bounces< at >ietf.org



 
David,
 
We can move the deadline for agenda items 5/28 if you like an there are no 
other objections.
 
Everyone requesting a timeslot for the next meeting should respond to me 
on this thread with their topic, I-D (if applicable), and time needed. 
This doesn?t ne

Re: Lock fairness question

Marc Eshel — 2013-05-16T21:38:06

later in this paragraph it says 

" The server is not required to maintain a list of pending blocked locks 
as it is used to
increase fairness and not correct operation."

Marc.



From:   Frank S Filz/Beaverton/IBM< at >IBMUS
To:     nfsv4< at >ietf.org, 
Date:   05/16/2013 02:18 PM
Subject:        [nfsv4] Lock fairness question
Sent by:        nfsv4-bounces< at >ietf.org



RFC 3530 bis contains the following statement:

Some clients require the support of blocking locks. The NFS version
4 protocol must not rely on a callback mechanism and therefore is
unable to notify a client when a previously denied lock has been
granted. Clients have no choice but to continually poll for the
lock. This presents a fairness problem. Two new lock types are
added, READW and WRITEW, and are used to indicate to the server that
the client is requesting a blocking lock. The server should maintain
an ordered list of pending blocking locks. When the conflicting lock
is released, the server may wait the lease period for the first
waiting client

Lock fairness question

Frank S Filz — 2013-05-16T21:17:18


RFC 3530 bis contains the following statement:

Some clients require the support of blocking locks. The NFS version
4 protocol must not rely on a callback mechanism and therefore is
unable to notify a client when a previously denied lock has been
granted. Clients have no choice but to continually poll for the
lock. This presents a fairness problem. Two new lock types are
added, READW and WRITEW, and are used to indicate to the server that
the client is requesting a blocking lock. The server should maintain
an ordered list of pending blocking locks. When the conflicting lock
is released, the server may wait the lease period for the first
waiting client to re-request the lock. After the lease period
expires the next waiting client request is allowed the lock. Clients
are required to poll at an interval sufficiently small that it is
likely to acquire the lock in a timely manner. The server is not
required to maintain a list of pending blocked locks as it is used to
increase fairness and not correct operation.

Re: Soliciting Agenda items for IETF 87 NFSv4 working groupmeeting

Chuck Lever — 2013-05-16T01:46:01

Comments inline.

--
Chuck Lever
chuck.lever< at >oracle.com


On May 15, 2013, at 8:53 PM, Spencer Shepler <sshepler< at >microsoft.com> wrote:


I recognize that we are talking about different approaches to prototyping this feature, so let me explain my thinking.

Having an application use case or two to drive our prototype is key.

An ongoing issue with this work is how applications will communicate PI data to their local NFS client.  There is no POSIX API today I am aware of that an application can use to perform read and write operations with PI data.

And, there are also no good mechanisms for conveying T10 PI data through a page cache via a standard VFS/VM.  A type 1 Protection Information field stores an LBA in its reference tag.  There's no practical way to get server storage LBAs to an application running on a client.

Thus our guess is that the first users of an NFS end-to-end capability will be non-traditional NFS clients such as hypervisors and user space database clients, and that they will prefer stayin

Re: Soliciting Agenda items for IETF 87 NFSv4 working group meeting

Spencer Shepler — 2013-05-16T00:53:38

My suggestion, Chuck, of using a pNFS layout for this work was not to use data-servers via block mode.
The MDS and DS in my mind would be the same server and the pNFS layout is being used to introduce the new functionality and thus is a files-like layout type that uses the T10 mechanisms (and others) as a way to communicate integrity data.

Spencer

From: Chuck Lever [mailto:chuck.lever< at >oracle.com]
Sent: Wednesday, May 15, 2013 12:02 PM
To: Noveck, David
Cc: Spencer Shepler; nfsv4< at >ietf.org
Subject: Re: [nfsv4] Soliciting Agenda items for IETF 87 NFSv4 working group meeting

On May 15, 2013, at 1:51 PM, "Noveck, David" <david.noveck< at >emc.com<mailto:david.noveck< at >emc.com>> wrote:

Maybe I'm using an automatic weapon on a dead horse here, but ...

First of all, I hope any PETA people will note that the horse is already dead.

I don't believe that the fact that that there nobody able and willing to do RPCSEC_GSSv3 indicates that there is no interest in or energy for doing this or other new work beyond what is

Re: DN contribution to IETF87 meta-discussion

Spencer Shepler — 2013-05-16T00:50:44

There is no strict dependency between rfc3530bis and NFSv4.2.
The FedFS documents are being held by normative reference to rfc3530bis.

NFSv4.2 has a normative reference to RPCSECGSSv3 and I am holding the NFSv4.2 as shepherd until we sort out what we would like to do with the RPCSECGSS work.  I don't have an opinion one way or the other but the working group needs to resolve the issue and either have a plan to move RPCSECGSS forward or remove the dependency in the NFSV4.2 document and update it.  If we have a plan for RPCSECGSS, then we will move the NFSv4.2 I-D forward with our area director.

Spencer

-----Original Message-----
From: Noveck, David [mailto:david.noveck< at >emc.com] 
Sent: Wednesday, May 15, 2013 12:17 PM
To: Haynes, Tom
Cc: Spencer Shepler; J. Bruce Fields; David Quigley; nfsv4< at >ietf.org
Subject: RE: [nfsv4] DN contribution to IETF87 meta-discussion


I didn't even know there was  log jam regarding 3530bis.  I knew there were some annoying comments that you have been dealing with, and I'm grat

Re: Soliciting next steps for RPCSEC_GSSv3

J. Bruce Fields — 2013-05-15T21:08:23

OK, so you're referring to the issues discussed e.g. in
http://tools.ietf.org/html/draft-noveck-nfsv4-migration-issues-00.

I still don't understand what you mean by "opens us up for the same type
of issues".

--b.

_______________________________________________
nfsv4 mailing list
nfsv4< at >ietf.org
https://www.ietf.org/mailman/listinfo/nfsv4

Re: DN contribution to IETF87 meta-discussion

Nico Williams — 2013-05-15T21:03:57

I'm willing to take vacation (i.e.,self-fund) to help finish the
RPCSEC_GSSv3 spec.  I might even attend Berlin.  What I would need in
rewritten is a commitment from reviewers, existing implementors (even if
they've only done a partial implementation only) and my co-author.  And i'd
need to put a cap on hours I'd dedicate to this.

However, it sounds like the problem isn't merely finishing the spec but
making sure there will be implementations.  What's the point of a normative
reference to something no one will ever implement?  Of course client
implementors have strong incentives to implement RPCSEC_GSSv3, particularly
the compound authentication aspect (otherwise the client is vulnerable to
cache poisoning by local users if the client doesn't maintain a per-user
cache).  As someone focused on security I find it hard to do anything other
than beg/cajole/demand that we fix that cache poisoning problem (and since
i don't expect clients to isolate per-user caches...), but we've lived this
long with this problem

Re: Soliciting next steps for RPCSEC_GSSv3

Haynes, Tom — 2013-05-15T20:58:03

On May 15, 2013, at 12:39 PM, J. Bruce Fields <bfields< at >fieldses.org> wrote:


Just a rough feeling that if we leave out inter-server, by the time we get
back to it, we will find issues as implementations diverge from the spec.




Yes, a variant of A.

And yes, tricky, but Spencer did ask for opinions.

I want us to deliver something that people can use and that can grow
to meet future security needs.



_______________________________________________
nfsv4 mailing list
nfsv4< at >ietf.org
https://www.ietf.org/mailman/listinfo/nfsv4

Re: Soliciting next steps for RPCSEC_GSSv3

J. Bruce Fields — 2013-05-15T19:39:56

Could you elaborate?


Which implementations exactly are you referring to?



So I think you're choosing some variant of option a), but I think the
details here are tricky.

--b.



_______________________________________________
nfsv4 mailing list
nfsv4< at >ietf.org
https://www.ietf.org/mailman/listinfo/nfsv4

Re: DN contribution to IETF87 meta-discussion

Noveck, David — 2013-05-15T19:17:16

I didn't even know there was  log jam regarding 3530bis.  I knew there were some annoying comments 
that you have been dealing with, and I'm grateful for your work on that.

If the issue of 3530bis has reached the state where it can be called  a logjam, perhaps we need
to discuss what to do about clearing it, and also,  preventing it from happening again, if that 
doesn't sound too future-oriented for you.

-----Original Message-----
From: Haynes, Tom [mailto:Tom.Haynes< at >netapp.com] 
Sent: Wednesday, May 15, 2013 1:03 PM
To: Noveck, David
Cc: Spencer Shepler; J. Bruce Fields; David Quigley; nfsv4< at >ietf.org
Subject: Re: [nfsv4] DN contribution to IETF87 meta-discussion


On May 14, 2013, at 6:36 PM, "Noveck, David" <david.noveck< at >emc.com> wrote:

 e.

I would prefer we finish up NFSv4.2 before we even discuss a framework for NFSv4.3.

We had that discussion at the interim meeting a couple of years ago and I don't want to rehash it.

We can't proceed on NFSv4.2 until we clear the log jam of 3530bis and the issue

Re: Soliciting Agenda items for IETF 87 NFSv4 workinggroupmeeting

Matt W. Benjamin — 2013-05-15T19:07:58

If a layouts are the preferred delivery mechanism for a growing list of features, that suggests that greater consideration for how layouts may be composed will be important.

My own intuition is that deferring the problem to final integration with a standard might shortchange discussion on how to lower cost of integration, semantics, of multiple layouts, that should be given careful consideration earlier rather than later.

Matt

----- "Chuck Lever" <chuck.lever< at >oracle.com> wrote: