Subject: [nfsv4] DRAFT Minutes from Montreal July 11 Meeting

From: Brian Pawlowski <[email-masked]>
Date: Fri, 4 Aug 2006 08:20:25 -0700 (PDT)

Apologies for late posting.

----------------------------------------------------------------

NFS Version 4 (nfsv4) WG Meeting Minutes - DRAFT
Tuesday, July 11, 2006 - 09:00 - 11:30
Montreal, Quebec, Canada
-----------------------------------

Minutes compiled primarily by Lisa Weeks (THANKS! Lisa!), some
editing by beepy.  pNFS summary from Garth Goodson with
additions by Lisa Weeks (thanks Garth!)

  o Welcome and Introduction (Pawlowski)
        Agenda bash etc. 
        BLUE SHEETS
        NOTE WELL 

Agenda bashed and noted well.

David Black announced that pNFS blocks draft converging for last
call in a month or so. (Nothing to discuss in the meeting).

  o IPR disclosures (beepy)
  https://datatracker.ietf.org/public/ipr_detail_show.cgi?&ipr_id=721

What is the impact of the disclosure?

        * Disclosure was on the published RFC and mentions previous
        versions  of NFS.  This is not a major deal.  We can't
        really do anything about this....it is a RFC

        * There were no disclosures on the Individual Drafts.
        Determine if a disclosure on the Drafts will be forthcoming.
        Make sure we don't get into a similar case when 4.1 is
        published.  Area director needs

        * The wording of the IPR say that "For reason of implementing
        the  RFCs, the license is free".

        * The working group needs to determine if they want to do
        to the specification in order to get around the IPR.  And
        also decide how  they want to move forward.

        * Have we formally asked for a specific explanation of the
        IPR from IBM?  The IPR is stated so vaguely that it is hard
        to know what it actually covers.

beepy owns action item to determine working group action, if any, with
regard to the IBM IPR disclosure against RFC 3530 for the current
work in progress and publish a plan.

  o NFS/RDMA Last Call preparation (Talpey)

Tom Talpey reported on the updates to the problem statement and
NFS-RDMA drafts.

Wants to move independent drafts to working group last call.

        (NFS-RDMA work dependent on Remote Direct Data Placement
        WG work). David Black gave a brief status of RDDP drafts
        moving in three pairs:

                - applicability
                - security
                - RDMAP and DDP going to last call, open issue
                closing in a week, this week or next...

                - SCTP and ADD IP dependency... will effect
                RFC Editor release - no IESG approval issue
                but may slow down doc approval

Back to NFS-RDMA - Talpey reported there are two implementations:

        Linux
        - NFSv2,3,4 tested and passing Cthon, etc
        - Tested over infiniband, iWarp

        OpenSolaris client server
        - NFSv3 tested and passing Connectathon

Linux client, Solaris server interoperating.

  o Multi-server Namespace Functionality (Noveck)

Noveck rewrote migration/replication chapter originally in RFC 3530.
Takes discussion from a single server name space to multi-server
name space issues (replication, migration and referrals).

    - Eliminated contradictions
    - Clarified stuff
    - Cleanup and corrections from ID (draft-noveck-nfsv4-migrep-00)

Referrals are now explicitly mentioned and discussed.  Uses
draft-ietf-nfsv4-referrals-00 approach.  Referrals document applies
to 4.0 and should be taken forward as Informational RFC approval?

Some more details (see slides also)

        *Options when effecting fs transitions
        * New attributes;
            -fs_absent: simple boolean "is it here?"
            - fs_locations_info: fs_locations on steroids
            - fs_status: migration/replication

        fs_locations_info:
        - to deal with todays problems and the future's
        - more replicas
        - more different kinds of replicas
        - more knowledge helpful to client
          more ability for server control
        - more support for cont... (on slides)
        - Go into the different type of replicas (i.e. there are
        differences between two paths to the same server and two
        paths to different servers)

        * Deleted stuff due to perceived lack of interest...

There was a major back and forth regarding what it means to be a
replica, and how they are consistent, and how a client knew when
one "object" was a replica of another.

        Replicas are identical data.  Slightly different is probably
        not where we want to go.  Stale bit issue... David Black
        brings up.

        This discussion will be taken to the working group alias
        for resolution.

Bring back up transparently splitting a FS.

Get IBM implementation experience...

        Mike Kazar is a living fossil... :-) (note to have
        Mike review this section of the draft from an AFS
        experience perspective)

Status: Mostly ready for thorough review

 o pNFS Issues (Goodson)

Brief summary of discussion around open issues at IETF meeting.

* Issue #21: CB_SIZECHANGED

   - Discussion around whether we really need it for files and objects.
     Came to the conclusion it is only really necessary to close the hole
     between WRITE COMMITs and followed by READs.  LAYOUTCOMMIT and
     SETATTR should extend the files on the DSs so it isn't an issue
     there.  It also does not currently violate open-close consistency.

   - People are still confused about what it does in the block's case.
     David Black gave an example that helped some understand, others not.
     I think it needs to be made very clear how this is not an
     optimization but rather required for correctness.

    beepy noted the issues seem to lay around semantics of Layout
    COMMIT and EOF and client "consistent" view. beepy believes he
    cautioned at this point that the WG was not revisiting issues
    of overall data consistency semantics of NFS - and that the
    resolution here was to drive towards correctness of the pNFS
    additions.

    For the record: in the panasas fs, they used the push model and
    it worked better than the pull model.

* Issue #40: DS and MDS w/different security mechanisms
   - No disagreement on Mike Eisler's proposed text - only applicable
   to files based.
   - Seems like Andy has comments brought up on mailing list, will
     close once discussion has completed - and declare consensus.

* Issue #55: Attribute for when to write through MDS
   - Seemed to be general agreement that this sort of "hint"
     represented as an optional attribute would be useful
   - Options based on size of writes; offset in file
     Garth posted a proposal on two ways of doing this.  Only heard
     back from Mark Eshel.  Would like more feedback before adding
     it as text...  Benny thinks we need more research (not
     another attribute but an operation).
   - We have examples from two existing systems that say that this
     is a good thing.
   - Garth will pick structure and repost proposal - Benny would
     like something more dynamic in nature (to reflect
     changing workloads); it was agreed a proposal on this could
     come after we have closed on current attribute

* Issue #57: Private layout range
   - Agreed that we will have a private layout range (high-bit set)
   - Agreed that we will use IANA registry for layout type definitions
   - Agreed that we will require a RFC for new layout types
     IANA the layout types - mechanical... RFC 2434 has some default
     policies... Figure proposal - expert review... Publish RFC to
     get a layout type...
   - Garth will write up this section and close the issue

* Issue #58: Layout return/recall flags
   - Some discussion over RETURN_ALL/RECALL_ALL flags
     New flags: FSID returns, RETURN_ALL, RECALL_ALL
   - Problem of Clients and servers getting out of sync: when they
     get out of sync, we have a reasonable ability to get back 
     in sync. Wasn't clear if this is really necessary to get client 
     and server back in sync
   - Will attach Marc Eshel's proposal of flushing client device ID cache
     to RETURN_ALL or FSID returns
   - Benny will update current proposal and repost for more discussion

* Issue #61: Lingering writes
   - No objections, will close using posted paragraph

* Issue #69: File-layout striping structure
   - Save space on the clients for layouts that contain pretty much
     the same information.  Makes device in the file layout case 
     more complex, but it is just  an optimization.
   - No real disagreement
   - Issue was raised that these simple/complex device IDs might be
     useful in a generic sense (across all layouts); will revisit this
     once we have it defined for files
   - Garth will update proposal with specifics and repost

Other discussion:

Mark Eshel would like to revisit client-side device flushing op.
Upon RETURN_ALL, the server has no responsibility for the server
to keep the same deviceid mapping.  Need to have clear text that
describes layout return meta op (it was suggested that we need
pairing of recall/return layouts to facilitate correctness)

There is general agreement and just needs to be more discussion.

  o NFSv4.1 I-D schedule and work item planning (Shepler/Noveck)

Went over specs in progress. Reconcile with charter and milestones,
deliver to the ADs in toto.

Off cycle spec review with Bakeathon.

Dave Noveck presented an end game strategy of dividing up the 4.1
spec editorship into pieces under overall editing done by Spencer
to move a bit more quickly on the large document.  Email describing
the specific responsibilities and ownership going forward to be
sent out.

        - Three editors and Sourceforge notion to be worked out
        amongst Eisler, Shepler and Noveck...

  o pNFS Objects (Halevy)

See slides - they were fairly complete and descriptive of current
status and issues with recommended resolutions.  No actions to be
taken.

(Apologies to Halevy - we seriously ran out of time and a bit over
and cut his presentation time down to almost nothing).

  o NFSv4.1 last call rules - discussion (beepy + ADs)

Need to put the bounds on what is going to be included in the NFSv4.1  
draft.

We will be switching to having more scrutiny based on the issues  
opened.  We are "closing down"...

Implementation experience requirements: First we will get the list
of what people will bring to the Bakeathon then we will have the
discussion about what increases our comfort in knowing the
specifications are valid.

  o Sept 2006 Bakeathon Planning (Trond)

Trond brought up the need for a Bakeathon to be held at the
University of Michigan in September to test NFS Version 4 and
proposed 4.1 extensions (including pNFS).

Trond is to take to WG alias driving the features to be tested.

beepy mentioned possibility of final spec issue review and
resolution via interim meeting overlapping Baekathon.

  o Adding Data Retention attributes (Eisler):

2 attributes for data retention.

    retained (boolean)
    retention date

Intent that this is mandatory, but it they are "Recommended"  attributes...

David Black is concerned that the attributes are moving in parallel  to 
the SNIA FIxed Content Aware Storage WG.

beepy mentioned that this is new work not currently in draft.
Discussion to be taken to the list.

  o Charter / Milestones (beepy, Shepler, ADs)

Charter hasn't been updated to cover the pNFS discussion, Beepy  
will give the ADs a paragraph.

ADs say: This group is clearly doing lots of technical work, but  
publications are low.  Need to close the door on saying that anything  
NFSv4 is on the wg's charter.  Have your charter say what is in  scope.  
Then anything outside of that will require a re-chartering.

This group has a history of picking up a lot of individual drafts and  
rolling them into a larger document.  Usually, each working group has  
to have milestones for all working group items.

Spencer taking AI to reflect the milestones for the drafts in progress.
Quick discussion on current drafts:

1.) nfsv4.1 draft
2.) pNFS blocks draft
3.) pNFS object draft
4.) 3 RDMA drafts moving toward WG last call
5.) Referrals draft (pulled into 4.1) - Referrals would be informative.
6.) ACLs draft (pulled into 4.1) - ACLs would be normative.
7.) Channel bindings draft - will be published as a individual  
submission.  Security ADs don't feel like it should be a Security WG  
item.  Will be last called soon.  Lars will touch base with the  
Security ADs.
8.) Discussion of Mapping NFSv4 to POSIX-draft ACLs

Come up with milestones/schedule for each of the authors.  Send  update 
to IESG.

The WG needs to relate each draft to a charter item.
AD: Wants charter update and milestones produced together.

Make sure not to forget about byte-range delegations, SPKM (still  
doesn't have a home)

  o ACLs (Falkner):

Take action to keep responding to Andreas on ACL issues.  Beepy to
figure out how to converge.

ACL document pertaining to NFSv4.0 should be Informational RFC (?)   
This doesn't have to be decided right now.

_______________________________________________
nfsv4 mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/nfsv4

---

From: Spencer Shepler <[email-masked]>
Date: Fri, 4 Aug 2006 11:29:39 -0500

> Apologies for late posting.

Thanks for putting this together, Beepy.

The deadline for minute submission and most corrections is Aug 11th.
Please provide your comments by then.

With the addition of the minutes, all of the meeting materials
have been submitted to the secretariate and may be found here:
https://datatracker.ietf.org/public/meeting_materials.cgi?meeting_num=66

Along with the other WGs.

If something is missing, please let me know.

Spencer