headers
Karen Rochford | 2 Nov 2006 16:14
Picon

SEQUENCE and lease renewal clarification

Hi,

Need some clarification on SEQUENCE and lease renewal, can not find this 
info in the current draft-ietf-nfsv4-minorversion1-08 draft.

I'm assuming, that if a SEQUENCE op fails (say due to 
NFS4ERR_SEQ_MISORDERED), the lease is NOT renewed, and I'm also assuming 
that if the SEQUENCE is completed from the replay cache, that the lease 
IS renewed?  However I do not see clear indicated of this in the draft. 
  I do see, "Each time a session is used, the state leased to it 
associated clientid is automatically renewed".  However its not clear 
what "used" really means.

The draft also says "When a request is issued for a given session,
execution of a SEQUENCE operation will result in all leases for the
associated client to be implicitly renewed."  However again, it is not 
clear what "execution" is, does this mean a successful completion of 
SEQUENCE, does it include a replay also, does it include even executions 
of SEQUENCE that return a failed status?

Can this be clarified?

Thanks,

Karen Rochford

_______________________________________________
nfsv4 mailing list
nfsv4 <at> ietf.org
https://www1.ietf.org/mailman/listinfo/nfsv4
(Continue reading)

Permalink | Reply | 3 comments |
headers
vanderputten_thomas | 2 Nov 2006 16:27

RE: SEQUENCE and lease renewal clarification

I think our interpretation is such that anytime a client presents a
valid id that we can resolve, we renew the lease.
We err on the side of being lenient. The thinking is that there is a
client that is obviously trying to use this session, and it would be
more hurtful to the client if it was to expire than if it was renewed.
It may not be to the letter of the spec, but it seems to fit the spirit
at any rate.

On the other hand, perhaps a malfunctioning client would prefer to have
the lease expire.

-- Tom Vanderputten

-----Original Message-----
From: Karen Rochford [mailto:Karen.Rochford <at> Sun.COM] 
Sent: Thursday, November 02, 2006 10:14 AM
To: nfsv4 <at> ietf.org; sessions-core <at> Sun.COM
Subject: [nfsv4] SEQUENCE and lease renewal clarification

Hi,

Need some clarification on SEQUENCE and lease renewal, can not find this

info in the current draft-ietf-nfsv4-minorversion1-08 draft.

I'm assuming, that if a SEQUENCE op fails (say due to 
NFS4ERR_SEQ_MISORDERED), the lease is NOT renewed, and I'm also assuming

that if the SEQUENCE is completed from the replay cache, that the lease 
IS renewed?  However I do not see clear indicated of this in the draft.
(Continue reading)

Permalink | Reply | 2 comments |
headers
Mike Eisler | 2 Nov 2006 17:05
Picon
Favicon

RE: SEQUENCE and lease renewal clarification


> -----Original Message-----
> From: Karen Rochford [mailto:Karen.Rochford <at> Sun.COM] 
> Sent: Thursday, November 02, 2006 10:14 AM
> To: nfsv4 <at> ietf.org; sessions-core <at> Sun.COM
> Subject: [nfsv4] SEQUENCE and lease renewal clarification
> 
> Hi,
> 
> Need some clarification on SEQUENCE and lease renewal, can not find
> this
> 
> info in the current draft-ietf-nfsv4-minorversion1-08 draft.
> 
> I'm assuming, that if a SEQUENCE op fails (say due to 
> NFS4ERR_SEQ_MISORDERED), the lease is NOT renewed, and I'm also
> assuming
> 
> that if the SEQUENCE is completed from the replay cache, that the
> lease 
> IS renewed?  However I do not see clear indicated of this in the
> draft. 
>   I do see, "Each time a session is used, the state leased to it 
> associated clientid is automatically renewed".  However its not clear
> 
> what "used" really means.

Karen, (and Thomas),

Thanks for raising some excellent points.
(Continue reading)

Permalink | Reply | 1 comment |
headers
Spencer Shepler | 2 Nov 2006 18:26
Picon

Re: SEQUENCE and lease renewal clarification

On Thu, Mike Eisler wrote:
> 
> > -----Original Message-----
> > From: Karen Rochford [mailto:Karen.Rochford <at> Sun.COM] 
> > Sent: Thursday, November 02, 2006 10:14 AM
> > To: nfsv4 <at> ietf.org; sessions-core <at> Sun.COM
> > Subject: [nfsv4] SEQUENCE and lease renewal clarification
> > 
> > Hi,
> > 
> > Need some clarification on SEQUENCE and lease renewal, can not find
> > this
> > 
> > info in the current draft-ietf-nfsv4-minorversion1-08 draft.
> > 
> > I'm assuming, that if a SEQUENCE op fails (say due to 
> > NFS4ERR_SEQ_MISORDERED), the lease is NOT renewed, and I'm also
> > assuming
> > 
> > that if the SEQUENCE is completed from the replay cache, that the
> > lease 
> > IS renewed?  However I do not see clear indicated of this in the
> > draft. 
> >   I do see, "Each time a session is used, the state leased to it 
> > associated clientid is automatically renewed".  However its not clear
> > 
> > what "used" really means.
> 
> Karen, (and Thomas),
>
(Continue reading)

Permalink | Reply | 0 comments |
headers
Yoder, Alan | 2 Nov 2006 19:57
Picon

RE: automatic inheritance

Could we please change "acl_auto_inherited" to
"acl_auto_inherit"?  The flag specifies something
to do, not something that's been done.

Looks fine to me, otherwise.

Thanks,

Alan 

> -----Original Message-----
> From: J. Bruce Fields [mailto:bfields <at> fieldses.org] 
> Sent: Friday, October 06, 2006 4:21 PM
> To: nfsv4 <at> ietf.org
> Subject: [nfsv4] automatic inheritance
> 
> Here's my attempt at specifying automatic inheritance.  It's 
> in the form
> of a diff against the -07 source.  I hope that's not too annoying to
> read....  Skip down to the section titled "Automatic Inheritance" for
> the meat of it.
> 
> The main requirement here is to provide protocol sufficient to support
> Windows applications using automatic inheritance, and I'll be grateful
> for review from any Windows experts.  I haven't done any 
> actual Windows
> testing, so while I believe I've gotten it right, it's still true that
> in some cases I'm guessing semantics based on incomplete 
> documentation.
>
(Continue reading)

Permalink | Reply | 1 comment |
headers
J. Bruce Fields | 2 Nov 2006 22:09

Re: automatic inheritance

On Thu, Nov 02, 2006 at 10:57:17AM -0800, Yoder, Alan wrote:
> Could we please change "acl_auto_inherited" to
> "acl_auto_inherit"?  The flag specifies something
> to do, not something that's been done.
> 
> Looks fine to me, otherwise.

Yeah, makes sense, thanks.--b.

_______________________________________________
nfsv4 mailing list
nfsv4 <at> ietf.org
https://www1.ietf.org/mailman/listinfo/nfsv4
Permalink | Reply | 0 comments |
headers
J. Bruce Fields | 2 Nov 2006 22:09

Re: automatic inheritance

On Thu, Nov 02, 2006 at 10:42:39AM -0800, Yoder, Alan wrote:
> Is separating the DACL and SACL ACEs, as Windows
> does, out of the question at this point?  I'm
> trying to think about this, and that seems like
> far the best solution so far.

I think it's not out of the question; I've been meaning to write a
revision that does this.  I'll try to get out new language tonight.

I think the idea is to add two new attributes, sacl and dalc, which
would replace the current acl attribute (though we must ensure it's easy
for a server to support all three).

They would be identical to the current acl attribute, except that audit
and alarm aces would go into the sacl and allow/deny into the dacl.  And
we'd add a new flag at the top level, so instead of being a simple
nfsace4<>, the sacl and dacl would each look like

	struct nfsacl4 {
		uint32_t flags;
		nfsace4<> acelist;
	}

and then we could stick the acl_protected and acl_auto_inherit bits in
the flags field instead of requiring separate attributes.

--b.

_______________________________________________
nfsv4 mailing list
(Continue reading)

Permalink | Reply | 501 comments |
headers
Yoder, Alan | 2 Nov 2006 19:42
Picon

RE: automatic inheritance

Is separating the DACL and SACL ACEs, as Windows
does, out of the question at this point?  I'm
trying to think about this, and that seems like
far the best solution so far.

Alan 

> -----Original Message-----
> From: J. Bruce Fields [mailto:bfields <at> fieldses.org] 
> Sent: Friday, October 06, 2006 4:31 PM
> To: nfsv4 <at> ietf.org
> Subject: Re: [nfsv4] automatic inheritance
> 
> On Fri, Oct 06, 2006 at 07:21:16PM -0400, J. Bruce Fields wrote:
> > Here's my attempt at specifying automatic inheritance.  
> It's in the form
> > of a diff against the -07 source.  I hope that's not too annoying to
> > read....  Skip down to the section titled "Automatic 
> Inheritance" for
> > the meat of it.
> 
> By the way, one known issue: Mike Eisler pointed out one subtle
> difference between NFSv4 and NT ACLs during the last conference call,
> which is that Windows separates the "DACL" (ALLOW and DENY ACEs) from
> the "SACL" (AUDIT and ALARM ACEs), whereas we lump them all 
> together in
> one object.
> 
> There's some concern this could cause problems, for example 
> if a client
(Continue reading)

Permalink | Reply | 501 comments |
headers
J. Bruce Fields | 3 Nov 2006 04:51

Re: automatic inheritance

On Thu, Nov 02, 2006 at 04:09:14PM -0500, J. Bruce Fields wrote:
> On Thu, Nov 02, 2006 at 10:42:39AM -0800, Yoder, Alan wrote:
> > Is separating the DACL and SACL ACEs, as Windows
> > does, out of the question at this point?  I'm
> > trying to think about this, and that seems like
> > far the best solution so far.
> 
> I think it's not out of the question; I've been meaning to write a
> revision that does this.  I'll try to get out new language tonight.

OK, here's my attempt.  Again, I hope the form of a diff (this time
against the -08 sources) isn't too awkward to read.

My feeling on the dacl (ALLOW and DENY) / sacl (AUDIT and ALARM)
separation is that it isn't really necessary if we aren't doing
automatic inheritance: if you have a user or system interface that
doesn't understand AUDIT or ALARM ACEs, then it should be easy to
implement the interface using a read-modify-write that preserves any
AUDIT or ALARM ACEs.  Maybe I'm missing something.

But if our goal is to support applications using the automatic
inheritance features introduced in Windows 2000, then I guess we do have
to give them independent control over automatic inheritance for the two
types of acl, since Windows gives them that control.

Introducing the sacl and dacl as new file attributes actually allows
some minor simplification of the handling of backwards compatibility.

As usual, any review (especially from people with experience with
Windows ACLs) is greatly appreciated.
(Continue reading)

Permalink | Reply | 501 comments |
headers
Talpey, Thomas | 7 Nov 2006 01:01
Picon

RPC/RDMA and NFS/RDMA draft updates

The RPC/NFS/RDMA drafts have been updated to include comments
received in the last call since the Ann Arbor interim meeting. Further
comments are welcome on the changes, we're discussing them at
the WG meeting today and Wednesday in San Diego.

Note also that the NFS/RDMA document proposes use of port 2050
for well-known port binding of NFS/RDMA servers, and the RPC/RDMA
specifies a new "rdma" netid for rpcbind dynamic port resolution. These
are being discussed with IANA this week.

 
RPC/RDMA protocol:
<http://www.ietf.org/internet-drafts/draft-ietf-nfsv4-rpcrdma-04.txt>

(diffs from previous version)
<http://tools.ietf.org/tools/rfcdiff/rfcdiff.pyht?url1=http://tools.ietf.org/id/draft-ietf-nfsv4-rpcrdma-03.txt&url2=http://tools.ietf.org/id/draft-ietf-nfsv4-rpcrdma-04.txt>

NFS binding to RPC/RDMA:
<http://www.ietf.org/internet-drafts/draft-ietf-nfsv4-nfsdirect-04.txt>

(diffs)
<http://tools.ietf.org/tools/rfcdiff/rfcdiff.pyht?url1=http://tools.ietf.org/id/draft-ietf-nfsv4-nfsdirect-03.txt&url2=http://tools.ietf.org/id/draft-ietf-nfsv4-nfsdirect-04.txt>

NFS/RDMA Problem Statement (informative specification):
<http://www.ietf.org/internet-drafts/draft-ietf-nfsv4-nfs-rdma-problem-statement-05.txt>

(diffs)
<http://tools.ietf.org/tools/rfcdiff/rfcdiff.pyht?url1=http://tools.ietf.org/id/draft-ietf-nfsv4-nfs-rdma-problem-statement-04.txt&url2=http://tools.ietf.org/id/draft-ietf-nfsv4-nfs-rdma-problem-statement-05.txt>

Thanks,
(Continue reading)

Permalink | Reply | 0 comments |

Gmane