NFSv4 IETF-120 Vancouver
Agenda
Chairs Welcome (10 Minutes)
Welcome / Note Well / Agenda
Document Status
Agenda Bashing
Milestones (20 minutes)
Noveck: 61/62bis documents (20 minutes)
Document Status
Chris has requested help on the recursively setting draft.
Want to know what we can fix to continue interim meeting. Christoph:
time is suboptimal, but not sure calls are productive. If you continue
meeting, publish agenda ahead of time and follow up with minutes.
Dave: Would like greater attendance.
Tom: Action items and ownership to drive interim meetings.
Chris: agenda early, focus on issues covered, will revsit meeting time
for European members as necessary.
Chris is requesting input from working group on milestones. Chris is
suggesting the documents just presented.
Christoph: whatever we update the milestones to, we should cover the
work. Primary activity is on the mail list. A lot of the work work we're
discussing are controversial, so unsure we can update milestones until
consensus on what the work items should be.
Chris: bring I18N across the finish line (Christoph agrees). Chris can
write up to start.
David Black: Agrees with Christoph. What is working group going to do? -
Triage the work into three buckets (clear path to completion, needs
significant work, and oh my ...). Then assign dates - dates are not
contracts, date revisions are inevitable.
Christoph: sees path to I18N. There seems to be work for ACLs - but no
consensus, and a broader discussion on security needs to be brought to
ground. The scope of the -bis document is problematic from the way it is
split up. Other than that, unsure. Tom will talk about flexfiles, we'll
see where that draft is. Christoph wants t do a tiny draft on NVME
layout.
Tom: FlexFiles v2. Presenting today. When is it ready, it is a year out?
18 months?
I18N end of year. ACLs 18 months. FlexFiles in 18 months. Christoph - we
can put a milestone in for pNFS NVMe layout update. Security - consensus
is rough, and we're struggling with adoption call. At a minimum -bis is
24 months out. We can put security milestone out there for 18 to 24
months. Milestone updates in a week or so.
Dave: Following up on comments on list, will address structural issues.
Chris: text editor help would be useful here.
Christoph: is available for editing for the smaller drafts. One issue he
raised on I18N is when we do split out documents (I18N and security) -
trying to update 4.0 and 4.1 ain one document. Christoph is not sure
this will work, and questions updating 4.0 at all.
Tom: if we put docs under git, Tom is willing to help.
Chris has added peolpe to git, and Dave can be added.
(Dave is Dave Noveck, David is David black)
Dave is willing to use git, chairs will work on adding git to workflow.
Focus on protection types.
Christoph: can you take three steps back and explain what you are trying
to do. Chris concurs.
Chris: where does this go and why.
Tom: different implementations of Mojette or Reed-Solomon.
Chris: for data, not metadata.
Tom: yes.
Tom: he sees four issues. Security, encoding protection types,
projection header, and WRITE holes. (see slides)
Tom: we are going towards IANA registered protection type encoding. Do
we want all to have a separate layout type, or a common implementation.
Tom then discussed Mojette projection header info. Concerned about
performance cost of XDR of projection header. Tom wants feedback from
David on block, was there a header? No. In object the headers were XDR
encoded.
Christoph: slides leave him confused, we are deep into details and has
concerns this can be done over NFS. Simply we want to erasure coding
over a set of data servers. Think just of replication (mirroring). We
need to track the state of the mirrors, how do you determine what is
most recent, and how are partial writes detected? There are approaches
for traditional systems, but perhaps difficult to implement in a
(highly) distributed fashion. Christoph wants to take a step back to
understand strategy choices and which works best over NFS. We need a lot
more architecture work with diagrams, and who does the recovery.
Christoph: Wants a high level approach before we start defining
algorithms. Tom agrees.
Tom: going over the write hole problem. The recovery issues. Partial
writes. Partial "stripe" failure. How to recover?
Chris: you mentioned unpacking security model for v2 that is not v1.
This may be a can of worms. What is the simple threat model? Worried
that since there is not a current threat model for v4.x; that this could
become doing the work of doing the threat model for v4.x. Tom wants to
have some form of protection over the wire. Chris: is there a split name
space for IANA, part public part private. Finally, scariest thing in
failure modes is not a pure failure, but a network partition (split
brain).
Tom: this is not finished. Wnated to move the converstaion.
Christoph: we need to figure out ... clients understanding which
algorithms, these algorithms change over time. He is scared of every
client having to understand the erasure encoding protection types. Tom
suggested interoperability can be solved with a portal at a performance
cost.
David seconds Christoph comment: Better to have protection algorithm
inside the storage system rather than outside (here that means on the
server side rather than in the client).
Dave has detailed slides. Dave is focusing on framing the items needing
consensus in his talk. Not to close today.
4.1 specification lacks sufficient semantic description. We tried to
accomodate various ACL implementation, and Posix draft ACL specs. But
unsure this was ever successful.
Dave wants to conceptually restructure document into core that is close
to draft Posix ACLs, then separate out the optional attributes
supporting other models. That is an extension to the protocol, which is
causing discussion on the mail list.
Dave is separating the problem into core of ACL support, clarification
necessary for POSIX suport amd then extensions.
Dave says we need consensus. Some short term other long term.
Dave defines core as that required by all versions (?) of NFS 4, and
they are required. (see slides).
Christoph asked for clarification of core UNIX ACLs vs POSIX ACLs. More
discussion. Issues in draft Posix docs included issues in inheritance,
etc.
Dave: we need to discuss further on mail list.
Dave - ACE mask bits. Detailed slide.
Dave - UNIX ACLs as basis of description.
Dave ACL choice attribute is optional.
Christoph - what are we actualy trying to do here? There is a very good
discussion on the mail list. We need to clearly define what problem we
are trying to solve. Having a document that describes UNIX ACLs mapping
to NFSv4. Some servers have nearly full NFSv4 ACL support. What is the
problem statement we are atually trying to solve here? What clients
benefit from any changes?
Christoph: we need a clear problem statement.
Jeffrey Layton doesn't understand ACL choice extension.
beepy talked about history of client and server have to make it right.
The NFS v4 protocol defines an abstract file system. The wire protocol
is a loose definition, and the client and server have to map their
(possibly very different) models/capabilities to that wire model.
Christoph: unsure he sees problem of rename.
Dave: if creates of new files are prevented, rename should be blocked.
Dave suggests that we may need to bring semantics of Posix into the NFS
protocol.
Dave - we might be able to get to agreement on making Posix ACL support
is NFS.
Major issues are clarifying I18N and security. Other issues were lack of
directory delegations, errata reports, and a multidocument model.
The slides are detailed on the issues Dave has been trying to tackle.
With an eye towards matching what implementations are doing with regard
to spec.
Directory delegations missing, and persistent reply cache.
Dave is going over the split of the documents into base, security and
I18N. Some discussion about recombining. Christoph says it slows
implementers, but he sees how it works within the IETF process. Zahed
will support our discussion.
Christoph is concerned 5661-bis will need to subsume I18N.
David thinks the separate document approach can help - clustering
related documents with dependencies enables independent IETF last call
and IESG review - the cluster comes together for RFC publication which
respects dependencies among documents.
RAN OUT OF TIME TO COVER FULL AGENDA MATERIALS