Proposed FedFS Agenda for 10/2/2008

We will be holding our weekly FedFS call today.

    Time: Thursdays 1:30-2:30 PM EST/10:30-11:30 AM PST
 Dial-in: 1-888-765-3653 # 2354843

As a reminder, all IETF contributions are governed by the IETF's Note 
Well agreement. See 

  http://www.ietf.org/NOTEWELL.html

Our work to date has bee governed under this agreement. With our 
addition to the NFSv4 working group this week, Spencer asked me to 
remind everyone of this agreement.

We have the following agenda items:

+ Note Well

+ Drafts re-published as NFSv4 WG documents

+ Decomision SDSC mailing list?

+ security considerations and requirements

+ root fileset, particularly the issue of one root NSDB 
                versus multiple root NSDBs
_______________________________________________
nfsv4 mailing list
nfsv4 <at> ietf.org

Please note...

In case you skipped over James's previous note because you aren't concerned
with the agenda for today -- please note this anyway.

The federated-fs mailing list may be going away.  Whether we'll just
use the nfsv4
mailing list, or create a new ietf list just for this is another
question, but if you're
interested in keeping track of the fed-fs stuff, watch for further
news about what's
happening with the mailing lists.  Don't get left behind.

-Dan

On Thu, Oct 2, 2008 at 9:58 AM, James Lentini <jlentini <at> netapp.com> wrote:
>
> We will be holding our weekly FedFS call today.
>
>    Time: Thursdays 1:30-2:30 PM EST/10:30-11:30 AM PST
>  Dial-in: 1-888-765-3653 # 2354843
>
>
> As a reminder, all IETF contributions are governed by the IETF's Note
> Well agreement. See
>
>  http://www.ietf.org/NOTEWELL.html
>
> Our work to date has bee governed under this agreement. With our
> addition to the NFSv4 working group this week, Spencer asked me to
> remind everyone of this agreement.
>

FedFS Meeting Minutes, 10/2/2008

FedFS Meeting Minutes, 10/2/2008
--------------------------------

Attendees
---------

Dan Ellard (BBN)
Craig Everhart (NetApp)
Paul Lemahieu (EMC)
James Lentini (NetApp)
Manoj Naik (IBM/ARC)
Renu Tewari (IBM/ARC)

Minutes
-------

+ IETF Note Well Agreement

  This is a reminder that our discussions are governed by the 
  IETF Note Well Agreement. See:

    http://www.ietf.org/NOTEWELL.html

  We will start each weeks meeting with this announcement.

+ NFSv4 WG publication

  The 4 FedFS drafts were published last Friday as NFSv4 working 
  group documents. The documents are now linked from the NFSv4 

Re: Please note...

On Oct 2, 2008, at 9:08 AM, Daniel Ellard wrote:

> In case you skipped over James's previous note because you aren't  
> concerned
> with the agenda for today -- please note this anyway.
>
> The federated-fs mailing list may be going away.  Whether we'll just
> use the nfsv4
> mailing list, or create a new ietf list just for this is another
> question, but if you're
> interested in keeping track of the fed-fs stuff, watch for further
> news about what's
> happening with the mailing lists.  Don't get left behind.
>
> -Dan

Please keep the traffic on the v4-wg mail list.

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

Re: Please note...

On Thu, 2 Oct 2008, Robert Gordon wrote:

> 
> On Oct 2, 2008, at 9:08 AM, Daniel Ellard wrote:
> 
> > In case you skipped over James's previous note because you aren't concerned
> > with the agenda for today -- please note this anyway.
> > 
> > The federated-fs mailing list may be going away.  Whether we'll just
> > use the nfsv4
> > mailing list, or create a new ietf list just for this is another
> > question, but if you're
> > interested in keeping track of the fed-fs stuff, watch for further
> > news about what's
> > happening with the mailing lists.  Don't get left behind.
> > 
> > -Dan
> 
> Please keep the traffic on the v4-wg mail list.
> 
> Robert.

We will keep the traffic on the v4-wg mail list.
_______________________________________________
nfsv4 mailing list
nfsv4 <at> ietf.org
https://www.ietf.org/mailman/listinfo/nfsv4

Proposed FedFS Agenda for 10/9/2008

We will be holding our weekly FedFS call today.

    Time: Thursdays 1:30-2:30 PM EST/10:30-11:30 AM PST
 Dial-in: 1-888-765-3653 # 2354843

We have the following agenda items from last week:

+ IETF Note Well Agreement

  This is a reminder that our discussions are governed by the 
  IETF Note Well Agreement. See:

    http://www.ietf.org/NOTEWELL.html

  We will start each weeks meeting with this announcement.

+ Review action items

  [AI] James Lentini will research how to deprecate the old 
       individuals drafts.

  [AI] James Lentini will send message to fedfs list notifying subscribers that 
       the fedfs list will be deprecated and instructing people to switch to 
       the NFSv4 list.

+ Root Fileset Schema
_______________________________________________
nfsv4 mailing list
nfsv4 <at> ietf.org

FedFS Meeting Minutes, 10/9/2008

FedFS Meeting Minutes, 10/9/2008
--------------------------------

Attendees
---------

Dan Ellard (BBN)
Craig Everhart (NetApp)
Paul Lemahieu (EMC)
James Lentini (NetApp)
Renu Tewari (IBM/ARC)
Robert Thurlow (Sun)
Mario Wurzl (EMC)

Minutes
-------

+ IETF Note Well Agreement

  This is a reminder that our discussions are governed by the 
  IETF Note Well Agreement. See:

    http://www.ietf.org/NOTEWELL.html

  We will start each weeks meeting with this announcement.

+ Review action items

  [AI] James Lentini will research how to deprecate the old 

I-D Action:draft-ietf-nfsv4-rpcsec-gss-v2-06.txt

A New Internet-Draft is available from the on-line Internet-Drafts directories.
This draft is a work item of the Network File System Version 4 Working Group of the IETF.

	Title           : RPCSEC_GSS Version 2
	Author(s)       : M. Eisler
	Filename        : draft-ietf-nfsv4-rpcsec-gss-v2-06.txt
	Pages           : 15
	Date            : 2008-10-09

This Internet-Draft describes version 2 of the RPCSEC_GSS protocol.
Version 2 is the same as Version 1 but adds support for channel
bindings.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-nfsv4-rpcsec-gss-v2-06.txt

Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/

Below is the data which will enable a MIME compliant mail reader
implementation to automatically retrieve the ASCII version of the
Internet-Draft.

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

minor discrepancy between notify_type4 and notify_deviceid_type4?

Mike, it seems like notify_type4 defines the bit
offsets of the corresponding directory notifications:

   enum notify_type4 {
           NOTIFY4_CHANGE_CHILD_ATTRS = 0,
           NOTIFY4_CHANGE_DIR_ATTRS = 1,
           NOTIFY4_REMOVE_ENTRY = 2,
           NOTIFY4_ADD_ENTRY = 3,
           NOTIFY4_RENAME_ENTRY = 4,
           NOTIFY4_CHANGE_COOKIE_VERIFIER = 5
   };

but since notify_deviceid_type4 starts at "1" and has only
the values "1" and "2" it is not absolutely clear if the spec
means bit offsets or the actual bitmap mask (like it had
been interpreted when implementing the xdr for cb_notify_deviceid).

   enum notify_deviceid_type4 {
           NOTIFY_DEVICEID4_CHANGE = 1,
           NOTIFY_DEVICEID4_DELETE = 2
   };

It'd be clearer if this was changed to 
   enum notify_deviceid_type4 {
           NOTIFY_DEVICEID4_CHANGE = 0,
           NOTIFY_DEVICEID4_DELETE = 1
   };

Since it's probably way too late to change the I-D for that
I just wanted to clarify this point.

Re: minor discrepancy between notify_type4 and notify_deviceid_type4?

On Fri, October 10, 2008 8:14 am, Benny Halevy wrote:
> Mike, it seems like notify_type4 defines the bit
> offsets of the corresponding directory notifications:
>
>    enum notify_type4 {
>            NOTIFY4_CHANGE_CHILD_ATTRS = 0,
>            NOTIFY4_CHANGE_DIR_ATTRS = 1,
>            NOTIFY4_REMOVE_ENTRY = 2,
>            NOTIFY4_ADD_ENTRY = 3,
>            NOTIFY4_RENAME_ENTRY = 4,
>            NOTIFY4_CHANGE_COOKIE_VERIFIER = 5
>    };
>
> but since notify_deviceid_type4 starts at "1" and has only
> the values "1" and "2" it is not absolutely clear if the spec
> means bit offsets or the actual bitmap mask (like it had
> been interpreted when implementing the xdr for cb_notify_deviceid).

Benny,

Since these numbers are used to set bits in the bitmap4 data type,
it seemed clear to me that:

   The position of the integer in the array that contains bit n
   can be computed from the expression (n / 32) and its bit within that
   integer is (n mod 32).

It would be clearer if the bitmap4 data type had its own section, and
all prose that discussed data types that use bitmap4 refer to that section.