[nfsv4] Draft Minutes from San Francisco IETF March 18 meeting

[Brian Pawlowski <[e-mail]>]

NFS Version 4 Working Group
IETF 56 San Francisco minutes

Network File System Version 4 (nfsv4)
-------------------------------------

Chair(s):

    Robert Thurlow <[e-mail]>
    Brian Pawlowski <[e-mail]>

Document Editor:

    Spencer Shepler <[e-mail]>


AGENDA:  Tuesday March 18 0900-1130 (2.5 hours)

    Welcome and Introduction            (Pawlowski)        5 min
    Agenda bash etc.
        - BLUE SHEETS
        - NOTE WELL
        - Status of drafts

    Connectathon results and issues     (Shepler)         10 min

    Where's RFC3010bis?                 (Shepler)         5  min

    Minor revisions to NFSv4            (Thurlow)         20 min

    Recent drafts                       (Eisler)          40 min
        - XDR update: draft-ietf-nfsv4-rfc1832bis-00.txt
        - SECINFO changes: draft-eisler-nfsv4-secinfo-00.txt
        - Credential Cache GSS Mech: draft-eisler-nfsv4-ccm-00.txt

    Migration/replication status        (Thurlow)         10 min

    From Repl/Mig to a global namespace (Thurlow)         20 min

    NFS and RDMA/RDDP work              (Pawlowski)       10 min

    Review of work items                (Shepler/Pawlowski) 15 min
        - API GSSAPI advancement
        - MIB draft resurrection
        - RPC/XDR/RPCSEC_GSS RFC plans

    Open discussion                     (Pawlowski)       10 m

    Wrapup                              (Pawlowski)        5 m

MINUTES

beepy welcomed, blue sheets and noted well.

Agenda bashed mercilessly.

Spencer Shepler reported on RFC 3010 revision.  Waiting for 48 hour
author review - RFC3010bis - in RFC editor's queue.

Connectathon 2003 - good results, had 5 implementations there, did some
recovery testingand Kerberos testting/GSSAPI. We've hit stride with
twice a year off cycle testing, June and October, for implementations..
Next testing is first week of June in Ann Arbor, MI; another bake-a-thon
event October in Austin.

Rob Thurlow reported on minor revisioning.  Minor version is defined by
the base specification.  What remains is policy for management of minor
revisions from a working group perspective.  Rob defined minor revisions
bounding (new minor version does not eliminate previous version support,
client server will negotiate down version).  Can add new ops within
COMPOUND, add mode bits, attributes.  But our policy in when to spin and
why a new revision.  Rob discussed asynchronous feature driven minor
versioning sort of vs.  a train model.  People are tending towards the
"train model".  Rob slides mention all this.  This discussion will be
pursued on the WG alias.  Train model procedure to be defined and vetted
within context of IETF. sob entered with IETF feedback and move to
reduce number of working groups in transport area.  NFS V4 has options
on how to handle minor versions.  Brent Callaghan questioned a 1 year
train model with length of IETF process - sob suggested the IETF process
is fast enough for a well working working group.

Mike Eislers's drafts:

XDR - want to raise it to full standard, needed some work to come into
line with current RFCs, mainly ISOC copyright and IANA considerations,
trademark updates, etc.  Can find change bars on Mike's URL.  Comment
from Scott - will we require some level of review before things get
revised?  Mike will add text.

SECINFO changes - issues from alias.  1) Needs args analogous to LOOKUP,
but can't access a parent directory like LOOKUPP - this will be
SECINFO_NO_NAME, subargs "current" and "parent".  Need to provide a way
to do this.  2) Need to be able to cross a boundary between security
domains 3) Need to permit SECINFO to encode more flavors than a few
explicitly listed.  Question: do we want a style more analogous to
LOOKUP/LOOKUPP and use SECINFOP and SECINFOC instead?  No, probably
better this way for minor rev.  Question: can we not do domain crossing?
Can, but it's not fully specified; this will clarify.  Question: why do
we not just apply this work to currfh?  A: want to limit the ops which
have to handle NFS4ERR_WRONGSEC.

CCM - waited for David Black.  Want to be able to use a cheaper security
mechanism when we're using IPSec/TLS/SSH underneath.  Want to
authenticate heavily just once, bind to the secure transport, and cache
the creds.  -00 draft obsolete - it was proposed that we change to a
simpler wrapper mechanism, and that was accepted.  Issues: MUST specify
channel bindings for end-to-end security?  Without, can have
man-in-the-middle attacks before client and server authentication, in
theory.  Problem: no channel bindings are defined in deployed secure
transports.  Proposal: SHOULD rather than MUST for channel bindings,
SHOULD let users set policy to require it, and CCM should negotiate it.
David Black - agrees that channel bindings are not a MUST. TLS, FCIP
both deal with a nonce handshake to do simpler binding to transport.
FCIP needs it because it does not try to do authentication in-band.
Mike: promote this as a WG item.  David: strongly agree, because we need
this badly for RDDP.

Rob Thurlow summarized migration/replication.  Discussed state of
current draft.  Trying to come up with a protocol good enoughbut not to
complex.  Related to replication/migration is thinking ona global name
space.  The AFS attack.  See Rob's slides.  AFS users seeking one global
name space and delegated management for local control of portions of the
name space.  Automounter has proven an inadequate solution (not
generally applicable).  Rob listed the limitations of Automounter.
Current V4 protocol does not provide mechanism for enumerating the
replicas of a given file system.  Only provides list of possibilities.
(which is not the same thing).  beepy vectored into a little history as
to why we avoided swallowing the AFS whale at the start of the NFS
Version 4 work.  AFS solved the heterogeneous distributed file system
problem by dictating a single solution that made everything look the
same.  Treading carefully in this space.  Rob Thurlow to carefully
investigate delivery date of Informational RFC describing Sun use of
LDAP for naming (Automounter).

(Eisler had paused during his security presentation and resumed when
David Black returned to get some feedback.)

David Black and Eisler discussed fine points.  David said that one thing
on alias was not covered: what about another issue of reuse of cached
credentials reused over another TCP connection - a crucial difference
between iSCSI use and proposed CCM work.  David said iSCSI binds the
credentials to a TCP connection maintaining the IPsec context
(disallowing migration).  Eisler agrees.  Julian Satran jumped in a bit
- a nonce, Eisler to follow up with Julian.  David suggests FCIP plays
this sort of game.  Mike to follow up.  Eisler feels other than issues
WG feels it is worthwhile pursuing.  David strongly seconds that.  In
context of RDDP tie in.

RDDP work items (beepy) - RDDP or RDMA promotes direct data placement by
a smart NIC directly into application buffers.  Our charter now includes
us producing a problem statement and a requirements document for NFS and
related technologies' use of RDDP and RDMA.  Main reason to stop there
is because there is not yet an RDDP protocol, and we don't want to wag
the dog.  After AD review, we will hope to consider making changes to
NFS or RPC or both to make use of the protocol.  Next action: form a
subgroup to whack this together.

Beepy - other documents.  To take NFSv4 to Draft, we need to move a
bunch of normative references ahead, either ourselves or in cooperation
with other groups.  GSS-API C and Java bindings are being worked now,
need to conference with Scott Bradner.  Need to get re-engaged with MIBs
and other

Other issues:

>From Mike Eisler - RPC program # registration - retrieved document from
IANA - but no progress.  Rob needs to follow up.

David Black and Mike Eisler thanked Sun for sponsoring the IETF.

Shepler proposes high bandwidth one day meeting in June in connection
with testing event at UMich.  beepy RTFM the IESG web page.

The group ended with a bug thank you to our outgoing Area Director
Scott Bradner for his guidance and support througout the development
of the V4 protocol.
_______________________________________________
nfsv4 mailing list
[e-mail]
https://www1.ietf.org/mailman/listinfo/nfsv4