Skip to main content

NFS Version 4.1 Update for Multi-Server Namespace
draft-ietf-nfsv4-mv1-msns-update-04

Revision differences

Document history

Date Rev. By Action
2020-10-02
04 Magnus Westerlund Document was replaced and will not progress.
2020-10-02
04 Magnus Westerlund IESG state changed to Dead::AD Followup from IESG Evaluation::AD Followup
2019-03-27
04 Amy Vezza Shepherding AD changed to Magnus Westerlund
2019-03-07
04 Cindy Morgan IESG state changed to IESG Evaluation::AD Followup from IESG Evaluation
2019-03-07
04 Eric Rescorla [Ballot comment]
I concur with my colleagues that a 100 page document consisting of diffs is not really something we can expect people to process
2019-03-07
04 Eric Rescorla [Ballot Position Update] New position, Abstain, has been recorded for Eric Rescorla
2019-03-07
04 Suresh Krishnan
[Ballot comment]
Thanks to the authors for doing the hard work in creating this document. I sincerely tried to give this document a proper review …
[Ballot comment]
Thanks to the authors for doing the hard work in creating this document. I sincerely tried to give this document a proper review but, like my abstaining co-ADs, I gave up along the way. The biggest issues for me were the reorganizations, lack of information about interoperability and backward compatibility with unupdated implementations, code snippet replacements with no apparent change (e.g. section 14.1 replacing 18.35.1, section 14.2 replacing 18.35.2. etc.) and so on. I also think that doing a new version of RFC5661 with the changes applied is the right way to go about this, but I will abstain so that the WG and the responsible AD can make the call.
2019-03-07
04 Suresh Krishnan [Ballot Position Update] New position, Abstain, has been recorded for Suresh Krishnan
2019-03-07
04 Mirja Kühlewind
[Ballot comment]
I didn't have the time to review this document in depth but I agree with others that the selected approach is hard to …
[Ballot comment]
I didn't have the time to review this document in depth but I agree with others that the selected approach is hard to follow. I would have preferred a bis document or a stand-alone document that updates RFC5661 content-wise but does not have a patch-style and therefore can "simply" be consumed in addition to RFC5661.
2019-03-07
04 Mirja Kühlewind [Ballot Position Update] New position, No Objection, has been recorded for Mirja Kühlewind
2019-03-07
04 Éric Vyncke Request for Last Call review by OPSDIR Completed: Has Issues. Reviewer: Éric Vyncke. Sent review to list.
2019-03-07
04 Terry Manderson
[Ballot comment]
My review of this document took me some time as I had to do a side my side read with RFC5661. While …
[Ballot comment]
My review of this document took me some time as I had to do a side my side read with RFC5661. While not normally a bad way to implement 'updates' I found myself lost more times than not. The complexity of the updates in this way loses readability and technical coherence, even though a lot of thought and effort has been invested in this work. I think that the loss of readability and technical coherence should be avoided for many reasons if not based alone on what we currently see in the set of documents which describes DNS. On this document I am balloting ABSTAIN as I feel that there are better ways to handle the depth breadth of this update, however I will not stand in the way of publication.
2019-03-07
04 Terry Manderson [Ballot Position Update] New position, Abstain, has been recorded for Terry Manderson
2019-03-06
04 Adam Roach
[Ballot comment]
I agree with Ben's comments that this format is hostile to implementors, and that the community would be far better served by a …
[Ballot comment]
I agree with Ben's comments that this format is hostile to implementors, and that the community would be far better served by a bis document.
2019-03-06
04 Adam Roach [Ballot Position Update] New position, Abstain, has been recorded for Adam Roach
2019-03-06
04 Alvaro Retana
[Ballot comment]
I agree with Ben's opinion.  As it is being discussed on the nsfv4 list, there are enough issues and changes to rfc5661 to …
[Ballot comment]
I agree with Ben's opinion.  As it is being discussed on the nsfv4 list, there are enough issues and changes to rfc5661 to justify a bis [1], the most significant seems to be what is already included in this document.

[1] https://mailarchive.ietf.org/arch/msg/nfsv4/Hj5dTm-qYG3dZFyhy1VBqWv44XA
2019-03-06
04 Alvaro Retana [Ballot Position Update] New position, Abstain, has been recorded for Alvaro Retana
2019-03-06
04 Alissa Cooper
[Ballot comment]
I agree with Ben Campbell and am therefore abstaining. It seems like the proper path to a more broadly usable specification would have …
[Ballot comment]
I agree with Ben Campbell and am therefore abstaining. It seems like the proper path to a more broadly usable specification would have been to obsolete RFC 5661 and produce a bis with the changes applied. I don't see an explanation anywhere for why that was not done.

The RFC 8174 boilerplate should be used in Section 2.

The shepherd write-up notes an issue with "minor copyright dates." The issue is not one of dates but rather about whether the pre-RFC5378 disclaimer is needed or not.
2019-03-06
04 Alissa Cooper [Ballot Position Update] New position, Abstain, has been recorded for Alissa Cooper
2019-03-06
04 Deborah Brungard [Ballot Position Update] New position, No Objection, has been recorded for Deborah Brungard
2019-03-06
04 Alexey Melnikov [Ballot comment]
I am borderline between Abstain and No Objections on usefulness of this document as a set of patches to another RFC.
2019-03-06
04 Alexey Melnikov [Ballot Position Update] New position, No Objection, has been recorded for Alexey Melnikov
2019-03-05
04 Benjamin Kaduk
[Ballot discuss]
I think this is a useful document to clarify the proper operation of NFS
4.1, and to clarify the distinction between trunking address …
[Ballot discuss]
I think this is a useful document to clarify the proper operation of NFS
4.1, and to clarify the distinction between trunking address changes and
migration, and intend to change my ballot to Yes once the following
issues are resolved.

The Security Considerations state or imply in multiple places that the
use of RPCSEC_GSS to access a designated server can be used to verify
the target name and address resolution, but this only holds when the
GSSAPI (and Kerberos) implementation refrains from using insecure DNS to
canonicalize the target principal hostname.  (Several major ones do not,
by default.)  It is irresponsible to not note this risk here.

Specifically, the following text from Section 1.3 of RFC 4120 is honored
more in the breach:

  Implementations of Kerberos and protocols based on Kerberos MUST NOT
  use insecure DNS queries to canonicalize the hostname components of
  the service principal names (i.e., they MUST NOT use insecure DNS
  queries to map one name to another to determine the host part of the
  principal name with which one is to communicate).

We are deleting Section 11.7 of 5661, but it talks about encoding
"opaque" values conveyed from server to server via client in big-endian
order, and don't seem to cover that in this document.  Is that problematic?

I also have a few other issues/questions that don't quite rise to
DISCUSS level, but are still important to address; I tagged those with
"IMPORTANT" in the comment section, so they don't get drowned in the
nits.
2019-03-05
04 Benjamin Kaduk
[Ballot comment]
In general, my remarks from mv0-trunking-update about clarity of
references to "the current document" will apply to this document as
well.  But I …
[Ballot comment]
In general, my remarks from mv0-trunking-update about clarity of
references to "the current document" will apply to this document as
well.  But I mention this only so that the authors/AD can note it in
their interactions with the RFC Editor; I don't think we need to discuss
it at all at this point in the process.

There's some stuff in here that, taken literally, is removing
functionality and/or changing assumptions that a client could make, in a
way that is sufficiently incompatible with NFS 4.1 that it should
arguably be a manner for a new minor version of the protocol.  But, I'm
inclined to agree with the assessment of the WG that these are
essentially giant errata fixes and are being made to reflect the intent
of the protocol, remedying internal inconsistencies in 5661.

Section 2

Use the RFC 8174 boilerplate please.  (Sorry, I know this is the Nth
time you're hearing it.)

Section 3.1

  o  Each NFSv4 server is assumed to have a set of IP addresses to
      which NFSv4 requests may be sent by clients.  These are referred

nit: do we want to limit ourselves to only *IP* addresses?  I don't
remember to what extent RDMA connections do/don't use IP.

  o  Two network addresses connected to the same server such that those
      addresses can be used to support a single common session are
      referred to as session-trunkable.  Note that two addresses may be
      server-trunkable without being session-trunkable and that when two
      connections of different connection types are made to the same
      network address and are based on a single file system location
      entry they are always session-trunkable, independent of the
      connection type, as specified by [RFC5661], since their derivation
      from the same file system location entry together with the
      identity of their network addresses assures that both connections
      are to the same server and will return server-owner information
      allowing session trunking to be used.

We may need to hear from some of my IESG colleagues, but I'm not sure
there's anything in principle that prevents a load-balancer or similar
device that presents a single public-facing IP address but dispatches to
different backends based on TCP/UDP port (which could break this
assumption of session-trunkability).

Section 3.2

  o  Reorganization made necessary by the fact that two network access
      paths to the same file system instance needs to be distinguished
      clearly from two different replicas since the former share locking
      state and can share session state.

nit: there's maybe a singular/plural mismatch here, but I think the
clarity is best if we say "the case of two network access paths" and
"the case of two different replicas".

  o  The need for a clear statement regarding the desirability of
      transparent transfer of state together with a recommendation that
      either that or a single-fs grace period be provided.

nit: maybe expand that the transfer of state is across replicas.

  o  A clarification of the fs_locations_info attribute to specify
      which portions of the information provided apply to a specific
      network access path and which to the replica which that path is
      used to access.

nit: s/which to/to which/

Section 4.2

  o  In some cases, a server will have a namespace more extensive than
      its local namespace, by using features associated with attributes
      that provide file system location information.  These features,
      which allow construction of a multi-server namespace are all

nit: comma after "namespace"

  o  File system location elements are derived from location entries
      [...]
      location element.  File system location entries that contain a
      host name, are resolved using DNS, and may result in one or more

nit: no comma after "host name"

Section 4.3


  NFSv4.1 contains RECOMMENDED attributes that provide information
  about how (i.e. at what network address and namespace position) a

nit: comma after "i.e.".

Section 4.4

We don't seem to talk about Section 4.5.3 at all, here.

Section 4.5

  Where a file system was previously absent, specification of file

nit: "previously absent" might be a strange wording; "is absent without
a transition to absent" is perhaps the intended scenario (though it's
also awkward wording).

Section 4.5.2

  o  The client may fetch the file system location attribute for the
      file system.  This will provide either the name of the server
      (which can be turned into a set of network addresses using DNS),
      or a set of server-trunkable location entries.  [...]

If the set of addresses in the server response are not all guaranteed to
be server-trunkable (which is my understanding, since replication
addresses for different instsances can also appear), then this text
should probably acknowledge that somehow.

Section 4.5.3

  Fs_locations_info includes a flag, FSLI4TF_RDMA, which, when set
  indicates that RPC-over-RDMA support is available using the specified
  location entry, by "stepping up" an existing TCP connection to
  include support for RDMA operation.  This flag makes it convenient
  for a client wishing to use RDMA to establish a TCP connection and
  then convert to use of RDMA.  [...]

nit: ambiguous parsing "use RDMA to establish a TCP connection", perhaps
s/ to/, as it can/

Section 4.5.5

  Although a single successor location is typical, multiple locations
  may be provided.  When multiple locations are provided, the client
  will typically use the first one provided.  If that is inaccessible
  for some reason, later ones can be used.  In such cases the client
  might consider that the transition to the new replica as a migration
  event, even though some of the servers involved might not be aware of
  the use of the server which was inaccessible.  In such a case, a
  client might lose access to locking state as a result of the access
  transfer.

Just to double-check: "such cases" are only when the first location is
inaccessible?

Section 4.5.6

(soapbox) There already is an example of a global filesystem namespace,
in the form of AFS.  I trust the WG to make the right decision as to
whether an informational reference is appropriate, though, since I have
a conflict of interest.

  However, there are facilities provided that allow different clients
  to be directed to different sets of data, to enable adaptation to
  such client characteristics as CPU architecture.  These facilities
  are described in Section 11.10.3 of [RFC5661] and in Section 12.2.3
  of the current document.

IMPORTANT: There is no fundamental restriction of this technology to
that use, so some hedging language like "such as to enable adaptation"
may be in order.

Section 4.5.7

  o  Additions to the list of network addresses for the current file
      system instance need not be acted on promptly.  However the client
      can choose to use the new address whenever it needs to switch
      access to a new replica.

Is this "replica" correct, or are we talking about the case of switching
to a different endpoint for the current instance?

Section 5

  o  The additional Section 9 in the current document discusses the
      case in which a shift to a different replica is made and state is
      transferred to allow the client the ability to have continues

nit: "continued"

      access to the accumulated locking state on the new server.

nit: maybe a comma before "on the new server", and/or s/the accumulated/its
accumulated/

  o  Sections 11.7 and 11.7.1 of [RFC5661] are to be replaced by
      Sections 8 8.1 respectively of the current document These sections
      would appear as Section 11.9 and 11.9.1 in an eventual
      consolidated document.

nits: "8 and 8.1, respectively,", and full stop before "These".

  o  Section 11.77 of [RFC5661] is to be replaced by Section 8.9.

nit: "11.7.7"

Section 7


  o  When there are no potential replacement addresses in use but there
      are valid addresses session-trunkable with the one whose use is to
      be discontinued, the client can use BIND_CONN_TO_SESSION to access
      the existing session using the new address.  Although the target
      session will generally be accessible, there may be cases in which
      that session in no longer accessible, in which case a new session
      can be created to provide the client continued access to the
      existing instance.

IMPORTANT: When this new session is created, do I still get to use "the
same filehandles, stateids, and client IDs" as before and have
continuity of lock state?  If not, the intro paragraph needs to have an
appropriate disclaimer on that list.

Section 8

IMPORTANT: I think (but am not 100% sure) that some of the deletions
from Section 11.7.2 and subsections are nominally behavior changes by
their removal, such as preserving the fsid in both locations or fileid
values not changing across the transition.  Can someone help point me to
the right place for all of these bullet points?

Section 8.2

[There appears to be no difference between this text and Section 11.7.3
of RFC 5661.]

Section 8.5

[There appears to be no difference between this text and Section 11.7.6
of RFC 5661.]

Section 10.1

  Note that the specified actions only need to be taken if they are not
  already going on.  For example, when NFS4ERR_MOVED is received when
  accessing a file system for which transition recovery already going
  on, the client merely waits for that recovery to be completed while
  the receipt of SEQ4_STATUS_LEASE_MOVED indication only needs to
  initiate migration discovery for a server if it is not going on for
  that server.

nit: "it" is perhaps unclear; I suggest "if such discovery is not
already underway".

Section 10.3

  1.  Performing an EXCHANGE_ID directed at the location address.  This
      operation is used to register the client-owner with the server,

I'm not seeing "client-owner" used as a term much.  Do we mean a "client
id string" in the terminology introduced in Section 3.1? (Of course, we
do have client_owner and eia_clientowner and such as other options...)

Section 10.4

  In some situations, it is possible for a BIND_CONN_TO_SESSION to
  succeed without session migration having occurred.  If state merger
  has taken place then the associated client ID may have already had a
  set of existing sessions, with it being possible that the sessionid
  of a given session is the same as one that might have been migrated.

Is this a situation that the client can detect and act on?

Section 10.5

  Access to appropriate locking state should need no actions beyond
  access to the session.  [...]

I understand that this is an 8174 lowercase "should", but I think that
we would benefit from some clarity as to this being the expected state
in normal operation but that some exceptional circumstances (examples?)
could cause it to not be the case, and as such the following checks
are not just pro forma.

Section 11

  In the event of file system migration, when the client connects to
  the destination server, it needs to be able to provide the client
  continued to access the files it had open on the source server.
  There are two ways to provide this:

nit: I think the "it" in "it needs to be able to provide" formally binds
to the client, as the subject of the previous clause.  I think we mean
the destination server, though.

      These features are discussed separately in Sections 11.2 and 11.3,
      which discuss Transparent State Migration and session migration
      respectively.

nit: this text is indented as if it is part of the second bullet point,
but it seems to be general discussion that applies to both bullet
points.

Section 11.2

  the file system being migrated.  In addition to client id string and
  verifier, the source server needs to provide, for each stateid:

IMPORTANT: There seem to be security considerations relating to trusting
the client id string (which is, IIRC, spoofable), that are not discussed
in the security considerations section.  Could an attacker, e.g., claim
to be a different client that the attacker knows is going to be
scheduled for migration?

Section 11.3

  One part of the necessary adaptation to these sorts of issues would
  restrict enforcement of normal slot sequence enforcement semantics
  until the client itself, by issuing a request using a particular slot
  on the destination server, established the new starting sequence for
  that slot on the migrated session.

(This means that any reordering that affected the first request received
on a particular slot would cause the loss/rejection of requests sent
prior to it, right?)

Section 12.2.1

  Note that both of these items specify attributes of the file system
  replica and should not be different when there are multiple
  fs_locations_server4 structures for the same replica, each specifying
  a network path to the chosen replica.

I'm not sure what the "both" is referring to, not seeing any class of
things listed where exactly two elements are present.

We may also want to specify some error-handling for when multiple
fs_locations_server4 structures appear for the same replica with
conflicting information.

  With the exception of the transport-flag field (at offset
  FSLIBX_TFLAGS with the fls_info array), all of this data applies to
  the replica specified by the entry, rather that the specific network
  path used to access it.

nit: FSLI4BX_TFLAGS

  o  Explicit definition of the various specific data items within XDR
      would limit expandability in that any extension within would
      require yet another attribute, leading to specification and
      implementation clumsiness.  In the context of the NFSv4 extension
      model in effect at the time fs_locations_info was designed (i.e.
      that described in [RFC5661]), this would necessitate a new minor
      to effect any Standards Track extension to the data in in
      fls_info.

nit: "minor version"

  In light of the new extension model defined in [RFC8178] and the fact
  that the individual items within fls_info are not explicitly
  referenced in the XDR, the following practices should be followed
  when extending or otherwise changing the structure of the data
  returned in fls_info within the scope of a single minor version.

(This text and the items following it suggests that we should have an
IANA registry, which would then have a column for replica vs. path,
etc. Not a good fit for this document, though.)

Section 12.2.3

[There appears to be no difference between this text and Section 11.10.3
of RFC 5661.]

Section 13.1

                    They are all based upon attributes that allow one
  file system to specify alternate, additional, and new location
  information which specifies how the client may access to access that
  file system.

nit: s/to access//
Also maybe s/which/that/ but the RFC Editor is great about this.

Section 13.2

                                  Thus, the identifiers generated by two
  servers within that set can be assumed compatible so that, in some
  cases, identifiers by one server in that set that set may be
  presented to another server of the same scope.

Presumably this is "identifiers *generated* by one server"?

Section 13.3

Please mention the Section number 15.1.2.4 of RFC 5661 here as well as
in the toplevel Section 13.

Setion 13.7.3

  to another client.  This can occur because the reclaim has been done
  outside of a grace period of implemented by the server, after the

nit: s/of implemented/implemented/

Section 14.3

  In situations in which the registration of the client_owner has not
  occurred previously, the client ID must first be used, along with the
  returned eir_sequenceid, in creating an associated session using
  CREATE_SESSION.

Do we want to mention the BIND_CONN_TO_SESSION usage here as well?

  A server MUST NOT provide the same client ID to two different
  incarnations of an eir_clientowner.

I see this is basically unchanged from 5661 so maybe it is out of scope,
but what does the server use to distinguish different "incarnations" or
an eir_clientowner?


Section 15.3

  It should be noted that there are situations in which a client needs
  to issue both forms of RECLAIM_COMPLETE.  An example is an instance
  of file system migration in which the file system is migrated to a
  server for which the client has no clientid.  As a result, the client
  needs to obtain a clientid from the server (incurring the
  responsibility to do RECLAIM_COMPLETE with rca_one_fs set to FALSE)
  as well as RECLAIM_COMPLETE with rca_one_fs set to TRUE to complete
  the per-fs grace period associated with the file system migration.

IMPORTANT: Is there an ordering requirement between the rca_one_fs ==
TRUE/FALSE RECLAIM_COMPLETEs?

Section 15.4

  o  When servers have no support for becoming the destination server
      of a file system subject to migration, there is no possibility of
      a per-fs RECLAIM_COMPLETE being done legitimately and occurrences
      of it SHOULD be ignored.  However, the negative consequences of
      accepting mistaken use are quite limited as long as the does not
      issue it before all necessary reclaims are done.

As long as who does not issue it?

  o  When a server might become the destination for a file system being
      migrated, inappropriate use per-fs RECLAIM_COMPLETE is more
      concerning.  In the case in which the file system designated is

nit: "use of"

      not within a per-fs grace period, it SHOULD be ignored, with the
      negative consequences of accepting it being limited, as in the
      case in which migration is not supported.  However, if it should
      encounter a file system undergoing migration, it cannot be
      accepted as if it were a global RECLAIM_COMPLETE without
      invalidating its intended use.

We seem to be using "it" throughout here to refer both to
RECLAIM_COMPLETE and to the server, which is kind of confusing.

Section 16

It seems that neither RFC 5661 nor this document explicitly note that if
the attacker gets a client to use bad locations and sends the client to
an attacker-controlled server, the attacker can give back arbitrary data
for the filesystem hierarchy for the client to use.  Hopefully this is
obvious, but it may be worth explicitly noting as the motivation for
taking the location information so seriously.

I agree with the secdir reviewer that:

      In light of the above, a server should present file system
      location entries that correspond to file systems on other servers
      using a host name.  This would allow the client to interrogate the

should be an RFC 2119 "SHOULD" (not sure what the WG poll turned up).

I do see several good proposed changes in response to the secdir review;
I'd propose further changing "avoid corruption of data in flight" to
"avoid modification of data in flight" since "corruption" can have a
connotation of randon bit flips, but the intended meaning is that an RFC
3552
attacker can deliberately change things.

(I'm also fairly sympathetic to the desire to not change the MTI
algorithms in this document, even though they really are quite overdue
for updates.  My understanding is that this document is intended as a
glorified errata about the migration/trunking behavior and is trying to
not change anything else.)

Appendix B

      o  Sections 11.8, 11.8.1, 11.8.2, and 11.9, are unchanged although
        they would be renumber as Sections 11.13 (with included

nit: "renumbered"
2019-03-05
04 Benjamin Kaduk [Ballot Position Update] New position, Discuss, has been recorded for Benjamin Kaduk
2019-03-05
04 Ben Campbell
[Ballot comment]
Thanks for the huge amount of work in this draft, but I cannot recommend publishing it in it's current form. I am balloting …
[Ballot comment]
Thanks for the huge amount of work in this draft, but I cannot recommend publishing it in it's current form. I am balloting "ABSTAIN" rather than "DISCUSS", so that I do not get in the way of publication if the rest of the IESG thinks it's fine as is. I apologize for not doing a more technical review, but I think the structural issues need to be addressed first.

I once spent several weeks over a summer in high school applying page updates to a shelf full of US Tax Code binders in a CPAs office. The IRS, (or whoever published the code) would send out boxes of new page-sets, each labeled for which original pages it would replace.  When we were done in the CPA office, we had a coherent set of documents, at least to the degree you can apply words like "coherent" to tax codes.

This draft does something akin to that, except that we don't end up with a coherent document as a result. If the RFC Editor applied patches from RFCs that  "UPDATE" other RFCs to render final text,  things would be different. But that doesn't happen with RFCs.  That being said, I don't object to RFC updates in general, as long as those updates are simple and fairly self-contained. But this draft is over 100 pages of intricate updates, reorganizations, and explanatory text. This will make life very hard for readers that were not involved in the standards process.

I think the right approach for an update of this complexity is to just do a 5661bis draft, and use this one as an input to that. Such a bis draft could be something as simple as applying the changes in this draft (and maybe trunking-update)  and publishing the result.
2019-03-05
04 Ben Campbell [Ballot Position Update] New position, Abstain, has been recorded for Ben Campbell
2019-02-27
04 Sean Turner Request for Last Call review by SECDIR Completed: Has Issues. Reviewer: Sean Turner. Sent review to list.
2019-02-25
04 Brian Carpenter Request for Last Call review by GENART Completed: Ready. Reviewer: Brian Carpenter. Sent review to list.
2019-02-21
04 Jean Mahoney Request for Last Call review by GENART is assigned to Brian Carpenter
2019-02-21
04 Jean Mahoney Request for Last Call review by GENART is assigned to Brian Carpenter
2019-02-20
04 Erik Kline Assignment of request for Last Call review by GENART to Erik Kline was rejected
2019-02-19
04 Spencer Dawkins IESG state changed to IESG Evaluation from Waiting for Writeup
2019-02-19
04 Spencer Dawkins Ballot has been issued
2019-02-19
04 Spencer Dawkins [Ballot Position Update] New position, Yes, has been recorded for Spencer Dawkins
2019-02-19
04 Spencer Dawkins Created "Approve" ballot
2019-02-19
04 Spencer Dawkins Ballot writeup was changed
2019-02-19
04 (System) IESG state changed to Waiting for Writeup from In Last Call
2019-02-15
04 (System) IANA Review state changed to IANA OK - No Actions Needed from IANA - Review Needed
2019-02-15
04 Sabrina Tanamal
(Via drafts-lastcall@iana.org): IESG/Authors/WG Chairs:

The IANA Functions Operator has reviewed draft-ietf-nfsv4-mv1-msns-update-04, which is currently in Last Call, and has the following comments:

We …
(Via drafts-lastcall@iana.org): IESG/Authors/WG Chairs:

The IANA Functions Operator has reviewed draft-ietf-nfsv4-mv1-msns-update-04, which is currently in Last Call, and has the following comments:

We understand that this document doesn't require any registry actions.

While it's often helpful for a document's IANA Considerations section to remain in place upon publication even if there are no actions, if the authors strongly prefer to remove it, we do not object.

If this assessment is not accurate, please respond as soon as possible.

Thank you,

Sabrina Tanamal
Senior IANA Services Specialist
2019-02-12
04 Gunter Van de Velde Request for Last Call review by OPSDIR is assigned to Éric Vyncke
2019-02-12
04 Gunter Van de Velde Request for Last Call review by OPSDIR is assigned to Éric Vyncke
2019-02-07
04 Jean Mahoney Request for Last Call review by GENART is assigned to Erik Kline
2019-02-07
04 Jean Mahoney Request for Last Call review by GENART is assigned to Erik Kline
2019-02-07
04 Amy Vezza Placed on agenda for telechat - 2019-03-07
2019-02-07
04 Tero Kivinen Request for Last Call review by SECDIR is assigned to Sean Turner
2019-02-07
04 Tero Kivinen Request for Last Call review by SECDIR is assigned to Sean Turner
2019-02-05
04 Cindy Morgan IANA Review state changed to IANA - Review Needed
2019-02-05
04 Cindy Morgan
The following Last Call announcement was sent out (ends 2019-02-19):

From: The IESG
To: IETF-Announce
CC: Spencer Shepler , draft-ietf-nfsv4-mv1-msns-update@ietf.org, nfsv4@ietf.org, nfsv4-chairs@ietf.org, …
The following Last Call announcement was sent out (ends 2019-02-19):

From: The IESG
To: IETF-Announce
CC: Spencer Shepler , draft-ietf-nfsv4-mv1-msns-update@ietf.org, nfsv4@ietf.org, nfsv4-chairs@ietf.org, spencer.shepler@gmail.com, spencerdawkins.ietf@gmail.com
Reply-To: ietf@ietf.org
Sender:
Subject: Last Call:  (NFS Version 4.1 Update for Multi-Server Namespace) to Proposed Standard


The IESG has received a request from the Network File System Version 4 WG
(nfsv4) to consider the following document: - 'NFS Version 4.1 Update for
Multi-Server Namespace'
  as Proposed Standard

The IESG plans to make a decision in the next few weeks, and solicits final
comments on this action. Please send substantive comments to the
ietf@ietf.org mailing lists by 2019-02-19. Exceptionally, comments may be
sent to iesg@ietf.org instead. In either case, please retain the beginning of
the Subject line to allow automated sorting.

Abstract


  This document presents necessary clarifications and corrections
  concerning features related to the use of attributes in NFSv4.1
  related to file system location.  These features include migration,
  which transfers responsibility for a file system from one server to
  another, and facilities to support trunking by allowing discovery of
  the set of network addresses to use to access a file system.  This
  document updates RFC5661.




The file can be obtained via
https://datatracker.ietf.org/doc/draft-ietf-nfsv4-mv1-msns-update/

IESG discussion can be tracked via
https://datatracker.ietf.org/doc/draft-ietf-nfsv4-mv1-msns-update/ballot/


No IPR declarations have been submitted directly on this I-D.




2019-02-05
04 Cindy Morgan IESG state changed to In Last Call from Last Call Requested
2019-02-05
04 Spencer Dawkins Last call announcement was generated
2019-02-05
04 Spencer Dawkins Last call was requested
2019-02-05
04 Spencer Dawkins Last call announcement was generated
2019-02-05
04 Spencer Dawkins Ballot approval text was generated
2019-02-05
04 Spencer Dawkins Ballot writeup was generated
2019-02-05
04 Spencer Dawkins IESG state changed to Last Call Requested from AD Evaluation::AD Followup
2019-02-05
04 (System) Sub state has been changed to AD Followup from Revised ID Needed
2019-02-05
04 David Noveck New version available: draft-ietf-nfsv4-mv1-msns-update-04.txt
2019-02-05
04 (System) New version approved
2019-02-05
04 (System) Request for posting confirmation emailed to previous authors: David Noveck , Chuck Lever
2019-02-05
04 David Noveck Uploaded new revision
2019-02-01
03 Spencer Dawkins IESG state changed to AD Evaluation::Revised I-D Needed from AD Evaluation
2019-01-28
03 Spencer Dawkins IESG state changed to AD Evaluation from Publication Requested
2019-01-22
03 Spencer Shepler
Working Group: NFSv4
Area Director: Spencer Dawkins
Document Author/Shepherd:  Spencer Shepler

Internet Draft:

NFS Version 4.1 Update for Multi-Server Namespace
draft-ietf-nfsv4-mv1-msns-update-03

(1) What type of …
Working Group: NFSv4
Area Director: Spencer Dawkins
Document Author/Shepherd:  Spencer Shepler

Internet Draft:

NFS Version 4.1 Update for Multi-Server Namespace
draft-ietf-nfsv4-mv1-msns-update-03

(1) What type of RFC is being requested (BCP, Proposed Standard,
Internet Standard, Informational, Experimental, or Historic)?  Why
is this the proper type of RFC?  Is this type of RFC indicated in the
title page header?

This document is a standards track document and updates RFC 5661 but
does not replace it.

(2) The IESG approval announcement includes a Document Announcement
Write-Up. Please provide such a Document Announcement Write-Up. Recent
examples can be found in the "Action" announcements for approved
documents. The approval announcement contains the following sections:

Technical Summary

  This document presents necessary clarifications and corrections
  concerning features related to the use of attributes in NFSv4.1
  related to file system location.  These features include migration,
  which transfers responsibility for a file system from one server to
  another, and facilities to support trunking by allowing discovery of
  the set of network addresses to use to access a file system.  This
  document updates RFC5661.

Working Group Summary

  The working group was well aligned on this work and it moved
  through the review process with good input but nothing contentious.

Document Quality

  This document was a result of implementation and deployment
  experience and represents input from the NFSv4 community with long
  standing experience.  The authors represent the quality work of the
  working group and are trusted in the community with their
  experience and abilty to draft quality, useful text.

Personnel

  Spencer Shepler is the document shepherd.
  Spencer Dawkins is the responsible area director.


(3) Briefly describe the review of this document that was performed by
the Document Shepherd.  If this version of the document is not ready
for publication, please explain why the document is being forwarded to
the IESG.

As shepherd, I have read and reviewed the document as part of the
working group last call and have been supportive of the work from
first suggestion.


(4) Does the document Shepherd have any concerns about the depth or
breadth of the reviews that have been performed?

As shepherd, I have no concerns about the document and believe it is
needed and adds value to the overall NFSv4 RFC collection.


(5) Do portions of the document need review from a particular or from
broader perspective, e.g., security, operational complexity, AAA, DNS,
DHCP, XML, or internationalization? If so, describe the review that
took place.

No special review is required for this document.


(6) Describe any specific concerns or issues that the Document Shepherd
has with this document that the Responsible Area Director and/or the
IESG should be aware of? For example, perhaps he or she is uncomfortable
with certain parts of the document, or has concerns whether there really
is a need for it. In any event, if the WG has discussed those issues and
has indicated that it still wishes to advance the document, detail those
concerns here.

There are no concerns for this document.

(7) Has each author confirmed that any and all appropriate IPR
disclosures required for full conformance with the provisions of BCP 78
and BCP 79 have already been filed. If not, explain why.

Yes.

(8) Has an IPR disclosure been filed that references this document?
If so, summarize any WG discussion and conclusion regarding the IPR
disclosures.

N/A

(9) How solid is the WG consensus behind this document? Does it
represent the strong concurrence of a few individuals, with others
being silent, or does the WG as a whole understand and agree with it? 

The working group is supportive of this document without exception.

(10) Has anyone threatened an appeal or otherwise indicated extreme
discontent? If so, please summarise the areas of conflict in separate
email messages to the Responsible Area Director. (It should be in a
separate email because this questionnaire is publicly available.)

N/A

(11) Identify any ID nits the Document Shepherd has found in this
document. (See https://www.ietf.org/tools/idnits/ and the Internet-Drafts
Checklist). Boilerplate checks are not enough; this check needs to be
thorough.

Minor copyright dates and minor issues will need to be updated.
These can be done during final edits, if required.


(12) Describe how the document meets any required formal review
criteria, such as the MIB Doctor, media type, and URI type reviews.

N/A

(13) Have all references within this document been identified as
either normative or informative?

Yes.

(14) Are there normative references to documents that are not ready for
advancement or are otherwise in an unclear state? If such normative
references exist, what is the plan for their completion?

N/A

(15) Are there downward normative references references (see RFC 3967)?
If so, list these downward references to support the Area Director in
the Last Call procedure.

N/A

(16) Will publication of this document change the status of any
existing RFCs? Are those RFCs listed on the title page header, listed
in the abstract, and discussed in the introduction? If the RFCs are not
listed in the Abstract and Introduction, explain why, and point to the
part of the document where the relationship of this document to the
other RFCs is discussed. If this information is not in the document,
explain why the WG considers it unnecessary.

No changes beyond the update of RFC 5661.


(17) Describe the Document Shepherd's review of the IANA considerations
section, especially with regard to its consistency with the body of the
document. Confirm that all protocol extensions that the document makes
are associated with the appropriate reservations in IANA registries.
Confirm that any referenced IANA registries have been clearly
identified. Confirm that newly created IANA registries include a
detailed specification of the initial contents for the registry, that
allocations procedures for future registrations are defined, and a
reasonable name for the new registry has been suggested (see RFC 5226).


No updates of the IANA section thus not required.

(18) List any new IANA registries that require Expert Review for future
allocations. Provide any public guidance that the IESG would find
useful in selecting the IANA Experts for these new registries.

N/A

(19) Describe reviews and automated checks performed by the Document
Shepherd to validate sections of the document written in a formal
language, such as XML code, BNF rules, MIB definitions, etc.

N/A
2019-01-22
03 Spencer Shepler Responsible AD changed to Spencer Dawkins
2019-01-22
03 Spencer Shepler IETF WG state changed to Submitted to IESG for Publication from In WG Last Call
2019-01-22
03 Spencer Shepler IESG state changed to Publication Requested from I-D Exists
2019-01-22
03 Spencer Shepler IESG process started in state Publication Requested
2019-01-22
03 Spencer Shepler Changed consensus to Yes from Unknown
2019-01-22
03 Spencer Shepler Intended Status changed to Proposed Standard from None
2019-01-22
03 Spencer Shepler
Working Group: NFSv4
Area Director: Spencer Dawkins
Document Author/Shepherd:  Spencer Shepler

Internet Draft:

NFS Version 4.1 Update for Multi-Server Namespace
draft-ietf-nfsv4-mv1-msns-update-03

(1) What type of …
Working Group: NFSv4
Area Director: Spencer Dawkins
Document Author/Shepherd:  Spencer Shepler

Internet Draft:

NFS Version 4.1 Update for Multi-Server Namespace
draft-ietf-nfsv4-mv1-msns-update-03

(1) What type of RFC is being requested (BCP, Proposed Standard,
Internet Standard, Informational, Experimental, or Historic)?  Why
is this the proper type of RFC?  Is this type of RFC indicated in the
title page header?

This document is a standards track document and updates RFC 5661 but
does not replace it.

(2) The IESG approval announcement includes a Document Announcement
Write-Up. Please provide such a Document Announcement Write-Up. Recent
examples can be found in the "Action" announcements for approved
documents. The approval announcement contains the following sections:

Technical Summary

  This document presents necessary clarifications and corrections
  concerning features related to the use of attributes in NFSv4.1
  related to file system location.  These features include migration,
  which transfers responsibility for a file system from one server to
  another, and facilities to support trunking by allowing discovery of
  the set of network addresses to use to access a file system.  This
  document updates RFC5661.

Working Group Summary

  The working group was well aligned on this work and it moved
  through the review process with good input but nothing contentious.

Document Quality

  This document was a result of implementation and deployment
  experience and represents input from the NFSv4 community with long
  standing experience.  The authors represent the quality work of the
  working group and are trusted in the community with their
  experience and abilty to draft quality, useful text.

Personnel

  Spencer Shepler is the document shepherd.
  Spencer Dawkins is the responsible area director.


(3) Briefly describe the review of this document that was performed by
the Document Shepherd.  If this version of the document is not ready
for publication, please explain why the document is being forwarded to
the IESG.

As shepherd, I have read and reviewed the document as part of the
working group last call and have been supportive of the work from
first suggestion.


(4) Does the document Shepherd have any concerns about the depth or
breadth of the reviews that have been performed?

As shepherd, I have no concerns about the document and believe it is
needed and adds value to the overall NFSv4 RFC collection.


(5) Do portions of the document need review from a particular or from
broader perspective, e.g., security, operational complexity, AAA, DNS,
DHCP, XML, or internationalization? If so, describe the review that
took place.

No special review is required for this document.


(6) Describe any specific concerns or issues that the Document Shepherd
has with this document that the Responsible Area Director and/or the
IESG should be aware of? For example, perhaps he or she is uncomfortable
with certain parts of the document, or has concerns whether there really
is a need for it. In any event, if the WG has discussed those issues and
has indicated that it still wishes to advance the document, detail those
concerns here.

There are no concerns for this document.

(7) Has each author confirmed that any and all appropriate IPR
disclosures required for full conformance with the provisions of BCP 78
and BCP 79 have already been filed. If not, explain why.

Yes.

(8) Has an IPR disclosure been filed that references this document?
If so, summarize any WG discussion and conclusion regarding the IPR
disclosures.

N/A

(9) How solid is the WG consensus behind this document? Does it
represent the strong concurrence of a few individuals, with others
being silent, or does the WG as a whole understand and agree with it? 

The working group is supportive of this document without exception.

(10) Has anyone threatened an appeal or otherwise indicated extreme
discontent? If so, please summarise the areas of conflict in separate
email messages to the Responsible Area Director. (It should be in a
separate email because this questionnaire is publicly available.)

N/A

(11) Identify any ID nits the Document Shepherd has found in this
document. (See https://www.ietf.org/tools/idnits/ and the Internet-Drafts
Checklist). Boilerplate checks are not enough; this check needs to be
thorough.

Minor copyright dates and minor issues will need to be updated.
These can be done during final edits, if required.


(12) Describe how the document meets any required formal review
criteria, such as the MIB Doctor, media type, and URI type reviews.

N/A

(13) Have all references within this document been identified as
either normative or informative?

Yes.

(14) Are there normative references to documents that are not ready for
advancement or are otherwise in an unclear state? If such normative
references exist, what is the plan for their completion?

N/A

(15) Are there downward normative references references (see RFC 3967)?
If so, list these downward references to support the Area Director in
the Last Call procedure.

N/A

(16) Will publication of this document change the status of any
existing RFCs? Are those RFCs listed on the title page header, listed
in the abstract, and discussed in the introduction? If the RFCs are not
listed in the Abstract and Introduction, explain why, and point to the
part of the document where the relationship of this document to the
other RFCs is discussed. If this information is not in the document,
explain why the WG considers it unnecessary.

No changes beyond the update of RFC 5661.


(17) Describe the Document Shepherd's review of the IANA considerations
section, especially with regard to its consistency with the body of the
document. Confirm that all protocol extensions that the document makes
are associated with the appropriate reservations in IANA registries.
Confirm that any referenced IANA registries have been clearly
identified. Confirm that newly created IANA registries include a
detailed specification of the initial contents for the registry, that
allocations procedures for future registrations are defined, and a
reasonable name for the new registry has been suggested (see RFC 5226).


No updates of the IANA section thus not required.

(18) List any new IANA registries that require Expert Review for future
allocations. Provide any public guidance that the IESG would find
useful in selecting the IANA Experts for these new registries.

N/A

(19) Describe reviews and automated checks performed by the Document
Shepherd to validate sections of the document written in a formal
language, such as XML code, BNF rules, MIB definitions, etc.

N/A
2019-01-22
03 Spencer Shepler Notification list changed to Spencer Shepler <spencer.shepler@gmail.com>
2019-01-22
03 Spencer Shepler Document shepherd changed to Spencer Shepler
2018-11-27
03 Spencer Shepler IETF WG state changed to In WG Last Call from WG Document
2018-11-13
03 David Noveck New version available: draft-ietf-nfsv4-mv1-msns-update-03.txt
2018-11-13
03 (System) New version approved
2018-11-13
03 (System) Request for posting confirmation emailed to previous authors: David Noveck , Chuck Lever
2018-11-13
03 David Noveck Uploaded new revision
2018-10-21
02 David Noveck New version available: draft-ietf-nfsv4-mv1-msns-update-02.txt
2018-10-21
02 (System) New version approved
2018-10-21
02 (System) Request for posting confirmation emailed to previous authors: David Noveck , Chuck Lever
2018-10-21
02 David Noveck Uploaded new revision
2018-06-09
01 David Noveck New version available: draft-ietf-nfsv4-mv1-msns-update-01.txt
2018-06-09
01 (System) New version approved
2018-06-09
01 (System) Request for posting confirmation emailed to previous authors: David Noveck , Chuck Lever
2018-06-09
01 David Noveck Uploaded new revision
2018-01-03
00 Spencer Shepler This document now replaces draft-dnoveck-nfsv4-mv1-msns-update instead of None
2018-01-03
00 David Noveck New version available: draft-ietf-nfsv4-mv1-msns-update-00.txt
2018-01-03
00 (System) WG -00 approved
2018-01-03
00 David Noveck Set submitter to "David Noveck ", replaces to draft-dnoveck-nfsv4-mv1-msns-update and sent approval email to group chairs: nfsv4-chairs@ietf.org
2018-01-03
00 David Noveck Uploaded new revision