Skip to main content

NFSv4.0 Migration: Specification Update
RFC 7931

Revision differences

Document history

Date Rev. By Action
2016-10-06
08 (System) Received changes through RFC Editor sync (added Errata tag)
2016-07-26
08 (System) RFC published
2016-07-19
08 (System) RFC Editor state changed to AUTH48-DONE from AUTH48
2016-07-05
08 (System) RFC Editor state changed to AUTH48 from RFC-EDITOR
2016-07-01
08 (System) RFC Editor state changed to RFC-EDITOR from EDIT
2016-05-24
08 (System) RFC Editor state changed to EDIT
2016-05-24
08 (System) IESG state changed to RFC Ed Queue from Approved-announcement sent
2016-05-24
08 (System) Announcement was received by RFC Editor
2016-05-24
08 (System) IANA Action state changed to No IC from In Progress
2016-05-24
08 (System) IANA Action state changed to In Progress
2016-05-24
08 Amy Vezza IESG state changed to Approved-announcement sent from Approved-announcement to be sent
2016-05-24
08 Amy Vezza IESG has approved the document
2016-05-24
08 Amy Vezza Closed "Approve" ballot
2016-05-24
08 Amy Vezza Ballot approval text was generated
2016-05-24
08 Amy Vezza Ballot writeup was changed
2016-05-24
08 Amy Vezza Ballot writeup was changed
2016-05-24
08 Amy Vezza IESG state changed to Approved-announcement to be sent from IESG Evaluation::AD Followup
2016-05-24
08 Amy Vezza [Ballot Position Update] Position for Spencer Dawkins has been changed to Yes from No Objection by Amy Vezza
2016-05-10
08 Alissa Cooper
[Ballot comment]
Thanks for addressing my DISCUSS.

---

My comments are about the example given in Section 4.9.

I understand from 4.2 that the requirements …
[Ballot comment]
Thanks for addressing my DISCUSS.

---

My comments are about the example given in Section 4.9.

I understand from 4.2 that the requirements for the construction of the client id are:

1) It should be unique per client.
2) It should persist through reboots.

As best I can tell, embedding the client's IP address in the client id is not a requirement (but I admit to not fully understanding NFS!). So why is it suggested that the client's network address be embedded in the client id?

There are also a few privacy-related issues with the example:

- Some clients will change their IP addresses over time to avoid being tracked. By suggesting that some prior address be used in the client id, there is an implied requirement on the client to maintain a history of previously used addresses, which could be exploited for tracking purposes.

- Permanent device identifiers (such as a serial numbers) should not be embedded in a client id on the wire, again to avoid facilitating tracking by any other party that knows the serial number.

It seems to me that to avoid all of the issues above, perhaps a better example to provide would be hash(some client secret, some source of uniqueness, server identity). That gives the client id a good chance of being unique without exposing other identifiers related to the client. And then if the existing guidance about saving and re-using the value is followed, it won't be necessary to try to shoehorn in an old IP address or persistent device identifiers when the clientid needs to be regenerated.
2016-05-10
08 Alissa Cooper [Ballot Position Update] Position for Alissa Cooper has been changed to No Objection from Discuss
2016-04-06
08 Cindy Morgan Shepherding AD changed to Spencer Dawkins
2016-02-02
08 (System) Sub state has been changed to AD Followup from Revised ID Needed
2016-02-02
08 David Noveck IANA Review state changed to Version Changed - Review Needed from IANA OK - No Actions Needed
2016-02-02
08 David Noveck New version available: draft-ietf-nfsv4-rfc3530-migration-update-08.txt
2016-01-28
07 Tero Kivinen Closed request for Last Call review by SECDIR with state 'No Response'
2016-01-26
07 Ben Campbell
[Ballot comment]
[ I've cleared my discuss since discussion is happening. I moved the following two discuss points into the comment section:

This draft recommends …
[Ballot comment]
[ I've cleared my discuss since discussion is happening. I moved the following two discuss points into the comment section:

This draft recommends the use of the uniform client-ID string approach. I admit to not being an NFS expert, but that seems to add a lot of complexity. It seems counter to advice in 7530. Section 4.7 of this draft points out that this may create interop problems with some servers. It seems to increase the privacy impact of persistent and potentially user and hardware identifying client-ID strings. There seems to be an issue of balancing harms here. I'd like to see some text describing how the harm avoided by the uniform approach balances out with the other issues.

The security considerations seem incomplete. This draft makes a number of normative changes and clarifications that are likely to introduce new security and/or privacy considerations that are not mentioned. This is especially true for the guidance about using uniform client-IDs.]


I support Alissa's DISCUSS comments concerning the privacy implications of a persistent client ID.  I am also concerned that the suggested approaches might help enable client fingerprinting.

- 4.2 (occurs twice)
The text says clients MAY send different strings to different servers. I think there may be privacy and tracking implications here, even if the client-ID is constructed without IP addresses or hardware identifiers. Is MAY strong enough? This ties in with the recommendations throughout the document about using persistent IDs across multiple servers. Perhaps there should be guidance to use different strings in general, except in cases where state-sharing is likely to come into play? (e.g. across completely different mount points?)

-4.2, paragraph starting with "As a security measure"
It might be helpful to briefly describe the security concern.
-- paragraph starting with "The difficulty is more severe..."
I think this paragraph warrants some normative guidance.

- 4.3:
How terrible is it if client state is prematurely deleted? Much of this draft, including the guidance to use uniform IDs across servers, seem to treat premature deletion as an ultimate harm, and do not balance that risk against the privacy and complexity issues that it may create.

- 4.7, 2nd bullet list:
How does the client know whether a server might return NFS4ERR_MOVED?

-7.5, 2nd bullet:
"trust relationship" by itself doesn't mean much. Who trusts what to do what?


Editorial:

- 3, paragraph starting with "Specification of requirements for the server..."
The first sentence hard to parse. The last sentence is also confusing. I think you mean to say that NFV4.0 non-normatively encourages the practice? A careless reader is likely to interpret "not 'RECOMMENDED'" as "NOT RECOMMENDED".

-3, paragraph starting with "to further complicate matters":
The paragraph uses confusing language. I _think_ you mean that servers have assumed a particular client implementation pattern, and can’t work with others. But it sounds like it says clients have universally adopted a particular pattern, in which case the interop problem doesn’t make sense.

-3, 4th paragraph from end:
Please don't use 2119 keywords to talk about how the other text uses 2119 keywords. Or at least put "RECOMMENDs" in quotes.

- 4.2, bullet entry starting with "The verifier is a client incarnation identifier..."
The second sentence is hard to parse. (The original version was hard, and this version is harder.)
--bullet starting with "The string MAY...":
redundant to similar guidance earlier in section.
-- paragraph starting with "Distinct servers MAY assign..."
What do you mean by "trunking"? I don't see the term defined anywhere.

- 4.6, "... cause us to RECOMMEND use of the uniform client id string"
I don't think that sentence should use the 2119 "RECOMMEND" keyword.

- 4.8: The repeated use of first person pronouns in this section (and elsewhere) is confusing. It's not always clear if "we" means the draft authors, implementors, or the implementation itself.
-- paragraph before 2nd bullet list:
First sentence is hard to parse.

- 7.4.5, first paragraph:
What does it mean to "make the following notations"?

- 7.5, third bullet:
First sentence is hard to parse.

- section 7.6 and 8:
The structure is confusing. 7.6 says it modifies the security considerations, but is not clear whether that means the security considerations in 7530, or in this document. 8 says "It is to be modified in section 7.6", without a clear antecedent for "It".
2016-01-26
07 Ben Campbell [Ballot Position Update] Position for Ben Campbell has been changed to No Objection from Discuss
2016-01-25
07 Gunter Van de Velde Request for Telechat review by OPSDIR Completed: Has Issues. Reviewer: Victor Kuarsingh.
2016-01-22
07 Elwyn Davies Request for Last Call review by GENART Completed: Ready with Nits. Reviewer: Elwyn Davies.
2016-01-21
07 Cindy Morgan IESG state changed to IESG Evaluation::Revised I-D Needed from IESG Evaluation
2016-01-21
07 Benoît Claise [Ballot Position Update] Position for Benoit Claise has been changed to No Objection from No Record
2016-01-21
07 Stephen Farrell
[Ballot comment]
I agree with Alissa's discuss about client ids and
apologies also from me for not spotting that in 7530.  The
persistent-across-reboots-forever thing that …
[Ballot comment]
I agree with Alissa's discuss about client ids and
apologies also from me for not spotting that in 7530.  The
persistent-across-reboots-forever thing that this seems to
be encouraging (if I'm reading it correctly) is just a bit
much really. But maybe we're lucky in that we now have a
chance to improve on that. (Further apologies for not
having actually had time to read this properly, I'm happy
to be part of a discussion on how what to do here if
that helps though and will read it properly if involved
in that;-)
2016-01-21
07 Stephen Farrell [Ballot Position Update] New position, No Objection, has been recorded for Stephen Farrell
2016-01-21
07 Benoît Claise
[Ballot comment]
Quick update from Victor Kuarsingh, part of the OPS DIR review:
I am still going through the draft.  I is taking me long …
[Ballot comment]
Quick update from Victor Kuarsingh, part of the OPS DIR review:
I am still going through the draft.  I is taking me long then normal since the writing style is making it hard to parse faster.  So far, here is where my analysis is going.

    edits needed to fix up language (very conversational in nature – not sure if that’s what the IETf normally wants)
    it’s hard to extract the updated requirements in the document as they appear both in bullet points, and in paragraphs (thus far)
    Quite a bit of time spent on what should not be done by servers/systems (seems helpful).
    However, the entire document was focused on fixing implementation problems/challenges conducting migrations for NFSv4.0 which should be benefiting (given it’s based on real world implementation challenges)
    I had pre-scanned the document ahead of time, and it appears the guidance in section 5/6 will be where the meat of the discussion is.
    Nothing really bad jumps out at me just yet (other then hard to follow).
2016-01-21
07 Benoît Claise Ballot comment text updated for Benoit Claise
2016-01-21
07 Jari Arkko [Ballot Position Update] New position, No Objection, has been recorded for Jari Arkko
2016-01-20
07 Joel Jaeggli [Ballot Position Update] New position, No Objection, has been recorded for Joel Jaeggli
2016-01-20
07 Martin Stiemerling IESG state changed to IESG Evaluation from Waiting for Writeup
2016-01-20
07 Terry Manderson [Ballot Position Update] New position, No Objection, has been recorded for Terry Manderson
2016-01-20
07 Barry Leiba [Ballot comment]
My co-ART-ADs have this very much in hand with their DISCUSS points, and I won't add to that.
2016-01-20
07 Barry Leiba [Ballot Position Update] New position, No Objection, has been recorded for Barry Leiba
2016-01-20
07 Cindy Morgan Changed consensus to Yes from Unknown
2016-01-20
07 Ben Campbell
[Ballot discuss]
This draft recommends the use of the uniform client-ID string approach. I admit to not being an NFS expert, but that seems to …
[Ballot discuss]
This draft recommends the use of the uniform client-ID string approach. I admit to not being an NFS expert, but that seems to add a lot of complexity. It seems counter to advice in 7530. Section 4.7 of this draft points out that this may create interop problems with some servers. It seems to increase the privacy impact of persistent and potentially user and hardware identifying client-ID strings. There seems to be an issue of balancing harms here. I'd like to see some text describing how the harm avoided by the uniform approach balances out with the other issues.

The security considerations seem incomplete. This draft makes a number of normative changes and clarifications that are likely to introduce new security and/or privacy considerations that are not mentioned. This is especially true for the guidance about using uniform client-IDs.
2016-01-20
07 Ben Campbell
[Ballot comment]
I support Alissa's DISCUSS comments concerning the privacy implications of a persistent client ID.  I am also concerned that the suggested approaches might …
[Ballot comment]
I support Alissa's DISCUSS comments concerning the privacy implications of a persistent client ID.  I am also concerned that the suggested approaches might help enable client fingerprinting.

- 4.2 (occurs twice)
The text says clients MAY send different strings to different servers. I think there may be privacy and tracking implications here, even if the client-ID is constructed without IP addresses or hardware identifiers. Is MAY strong enough? This ties in with the recommendations throughout the document about using persistent IDs across multiple servers. Perhaps there should be guidance to use different strings in general, except in cases where state-sharing is likely to come into play? (e.g. across completely different mount points?)

-4.2, paragraph starting with "As a security measure"
It might be helpful to briefly describe the security concern.
-- paragraph starting with "The difficulty is more severe..."
I think this paragraph warrants some normative guidance.

- 4.3:
How terrible is it if client state is prematurely deleted? Much of this draft, including the guidance to use uniform IDs across servers, seem to treat premature deletion as an ultimate harm, and do not balance that risk against the privacy and complexity issues that it may create.

- 4.7, 2nd bullet list:
How does the client know whether a server might return NFS4ERR_MOVED?

-7.5, 2nd bullet:
"trust relationship" by itself doesn't mean much. Who trusts what to do what?


Editorial:

- 3, paragraph starting with "Specification of requirements for the server..."
The first sentence hard to parse. The last sentence is also confusing. I think you mean to say that NFV4.0 non-normatively encourages the practice? A careless reader is likely to interpret "not 'RECOMMENDED'" as "NOT RECOMMENDED".

-3, paragraph starting with "to further complicate matters":
The paragraph uses confusing language. I _think_ you mean that servers have assumed a particular client implementation pattern, and can’t work with others. But it sounds like it says clients have universally adopted a particular pattern, in which case the interop problem doesn’t make sense.

-3, 4th paragraph from end:
Please don't use 2119 keywords to talk about how the other text uses 2119 keywords. Or at least put "RECOMMENDs" in quotes.

- 4.2, bullet entry starting with "The verifier is a client incarnation identifier..."
The second sentence is hard to parse. (The original version was hard, and this version is harder.)
--bullet starting with "The string MAY...":
redundant to similar guidance earlier in section.
-- paragraph starting with "Distinct servers MAY assign..."
What do you mean by "trunking"? I don't see the term defined anywhere.

- 4.6, "... cause us to RECOMMEND use of the uniform client id string"
I don't think that sentence should use the 2119 "RECOMMEND" keyword.

- 4.8: The repeated use of first person pronouns in this section (and elsewhere) is confusing. It's not always clear if "we" means the draft authors, implementors, or the implementation itself.
-- paragraph before 2nd bullet list:
First sentence is hard to parse.

- 7.4.5, first paragraph:
What does it mean to "make the following notations"?

- 7.5, third bullet:
First sentence is hard to parse.

- section 7.6 and 8:
The structure is confusing. 7.6 says it modifies the security considerations, but is not clear whether that means the security considerations in 7530, or in this document. 8 says "It is to be modified in section 7.6", without a clear antecedent for "It".
2016-01-20
07 Ben Campbell [Ballot Position Update] New position, Discuss, has been recorded for Ben Campbell
2016-01-20
07 Deborah Brungard [Ballot Position Update] New position, No Objection, has been recorded for Deborah Brungard
2016-01-20
07 Alia Atlas [Ballot Position Update] New position, No Objection, has been recorded for Alia Atlas
2016-01-20
07 Spencer Dawkins [Ballot Position Update] New position, No Objection, has been recorded for Spencer Dawkins
2016-01-20
07 Brian Haberman
[Ballot comment]
No objection to the publication of this document, but I do have a few non-blocking points:

1. I support Alissa's DISCUSS on the …
[Ballot comment]
No objection to the publication of this document, but I do have a few non-blocking points:

1. I support Alissa's DISCUSS on the privacy issues surrounding the client ID and will be following the discussion intently.

2. It would be nice if pointers to the actual definition of data types like verifier4 and cb_client4 were provided.
2016-01-20
07 Brian Haberman [Ballot Position Update] New position, No Objection, has been recorded for Brian Haberman
2016-01-19
07 Alissa Cooper
[Ballot discuss]
Per my comment below, it seems like there are some fairly significant privacy considerations related to the choice of how the client id …
[Ballot discuss]
Per my comment below, it seems like there are some fairly significant privacy considerations related to the choice of how the client id is constructed. I think these need to be described in the document so implementors are aware of them. (And my bad for not noticing this before the publication of RFC 7530, since they would have applied there as well.)
2016-01-19
07 Alissa Cooper
[Ballot comment]
My comments are about the example given in Section 4.9.

I understand from 4.2 that the requirements for the construction of the client …
[Ballot comment]
My comments are about the example given in Section 4.9.

I understand from 4.2 that the requirements for the construction of the client id are:

1) It should be unique per client.
2) It should persist through reboots.

As best I can tell, embedding the client's IP address in the client id is not a requirement (but I admit to not fully understanding NFS!). So why is it suggested that the client's network address be embedded in the client id?

There are also a few privacy-related issues with the example:

- Some clients will change their IP addresses over time to avoid being tracked. By suggesting that some prior address be used in the client id, there is an implied requirement on the client to maintain a history of previously used addresses, which could be exploited for tracking purposes.

- Permanent device identifiers (such as a serial numbers) should not be embedded in a client id on the wire, again to avoid facilitating tracking by any other party that knows the serial number.

It seems to me that to avoid all of the issues above, perhaps a better example to provide would be hash(some client secret, some source of uniqueness, server identity). That gives the client id a good chance of being unique without exposing other identifiers related to the client. And then if the existing guidance about saving and re-using the value is followed, it won't be necessary to try to shoehorn in an old IP address or persistent device identifiers when the clientid needs to be regenerated.
2016-01-19
07 Alissa Cooper [Ballot Position Update] New position, Discuss, has been recorded for Alissa Cooper
2016-01-19
07 Alvaro Retana [Ballot comment]
No objection, but I have to wonder why this work wasn't folded into RFC7530 (which work seems to have been around long enough).
2016-01-19
07 Alvaro Retana [Ballot Position Update] New position, No Objection, has been recorded for Alvaro Retana
2016-01-19
07 Martin Stiemerling Ballot has been issued
2016-01-19
07 Martin Stiemerling [Ballot Position Update] New position, Yes, has been recorded for Martin Stiemerling
2016-01-19
07 Martin Stiemerling Created "Approve" ballot
2016-01-19
07 Martin Stiemerling Ballot writeup was changed
2016-01-18
07 (System) IESG state changed to Waiting for Writeup from In Last Call
2016-01-14
07 Jean Mahoney Request for Last Call review by GENART is assigned to Elwyn Davies
2016-01-14
07 Jean Mahoney Request for Last Call review by GENART is assigned to Elwyn Davies
2016-01-11
07 (System) IANA Review state changed to IANA OK - No Actions Needed from IANA - Review Needed
2016-01-11
07 Sabrina Tanamal
(Via drafts-lastcall-comment@iana.org): IESG/Authors/WG Chairs:

IANA has reviewed draft-ietf-nfsv4-rfc3530-migration-update-07.txt, which is currently in Last Call, and has the following comments:

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

IANA has reviewed draft-ietf-nfsv4-rfc3530-migration-update-07.txt, which is currently in Last Call, and has the following comments:

We understand that this document doesn't require any IANA 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, IANA does not object.

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

Thank you,

Sabrina Tanamal
IANA Specialist
ICANN
2016-01-07
07 Jean Mahoney Request for Last Call review by GENART is assigned to Elwyn Davies
2016-01-07
07 Jean Mahoney Request for Last Call review by GENART is assigned to Elwyn Davies
2016-01-07
07 Jean Mahoney Closed request for Last Call review by GENART with state 'Withdrawn'
2016-01-07
07 Tero Kivinen Request for Last Call review by SECDIR is assigned to Alan DeKok
2016-01-07
07 Tero Kivinen Request for Last Call review by SECDIR is assigned to Alan DeKok
2016-01-04
07 Jean Mahoney Request for Last Call review by GENART is assigned to Brian Carpenter
2016-01-04
07 Jean Mahoney Request for Last Call review by GENART is assigned to Brian Carpenter
2016-01-04
07 Gunter Van de Velde Request for Telechat review by OPSDIR is assigned to Victor Kuarsingh
2016-01-04
07 Gunter Van de Velde Request for Telechat review by OPSDIR is assigned to Victor Kuarsingh
2016-01-04
07 Amy Vezza IANA Review state changed to IANA - Review Needed
2016-01-04
07 Amy Vezza
The following Last Call announcement was sent out:

From: The IESG
To: "IETF-Announce"
CC: spencer.shepler@gmail.com, mls.ietf@gmail.com, nfsv4-chairs@ietf.org, draft-ietf-nfsv4-rfc3530-migration-update@ietf.org, nfsv4@ietf.org
Reply-To: ietf@ietf.org …
The following Last Call announcement was sent out:

From: The IESG
To: "IETF-Announce"
CC: spencer.shepler@gmail.com, mls.ietf@gmail.com, nfsv4-chairs@ietf.org, draft-ietf-nfsv4-rfc3530-migration-update@ietf.org, nfsv4@ietf.org
Reply-To: ietf@ietf.org
Sender:
Subject: Last Call:  (NFSv4.0 migration: Specification Update) to Proposed Standard


The IESG has received a request from the Network File System Version 4 WG
(nfsv4) to consider the following document:
- 'NFSv4.0 migration: Specification Update'
  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 2016-01-18. 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


  The migration feature of NFSv4 allows for responsibility for a single
  filesystem to move from one server to another, without disruption to
  clients.  Recent implementation experience has shown problems in the
  existing specification for this feature in NFSv4.0.  This document
  clarifies and corrects RFC7530 (the NFSv4.0 specification) to address
  these problems.




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

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


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


2016-01-04
07 Amy Vezza IESG state changed to In Last Call from Last Call Requested
2016-01-04
07 Amy Vezza Last call announcement was changed
2016-01-03
07 Martin Stiemerling Placed on agenda for telechat - 2016-01-21
2016-01-03
07 Martin Stiemerling Last call was requested
2016-01-03
07 Martin Stiemerling Ballot approval text was generated
2016-01-03
07 Martin Stiemerling Ballot writeup was generated
2016-01-03
07 Martin Stiemerling IESG state changed to Last Call Requested from AD Evaluation
2016-01-03
07 Martin Stiemerling Last call announcement was generated
2015-10-14
07 (System) Notify list changed from "Spencer Shepler"  to (None)
2015-09-30
07 Martin Stiemerling IESG state changed to AD Evaluation from Publication Requested
2015-09-27
07 Spencer Shepler
This shepherding write-up is for the following I-D:

draft-ietf-nfsv4-rfc3530-migration-update-07

(1) What type of RFC is being requested (BCP, Proposed Standard,
Internet Standard, Informational, Experimental, or …
This shepherding write-up is for the following I-D:

draft-ietf-nfsv4-rfc3530-migration-update-07

(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?

Proposed Standard


(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

  The migration feature of NFSv4 allows for responsibility for a single
  filesystem to move from one server to another, without disruption to
  clients.  Recent implementation experience has shown problems in the
  existing specification for this feature in NFSv4.0.  This document
  clarifies and corrects RFC7530 (the NFSv4.0 specification) to address
  these problems.

Working Group Summary

  This I-D represents strong working group consensus and is derived
  from implementation experience of the NFSv4 migration capabilities and
  is therefore representative of needed clarification in specification
  for interoperable implementation.

Document Quality

  As mentioned, this work is derived from implementation experience and
  relates to the needs of the community of NFSv4 implementors such that
  they can create effective and interoperable implementations in the
  context of migration support.

Personnel

  Document Shepherd: Spencer Shepler
  Area Director: Martin Stiemerling

(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.

  I have reviewed the document in full and have followed the working
  group discussions during the development and review of the document.

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

  I am comfortable with the document's content and breadth/depth of
  coverage of the topic.

(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.

  Not applicable.

(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.

  No issues.

(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.

  No.

(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 in full support of the document.
 
(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.)

  No.

(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.

  None applicable.

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

  Not applicable.

(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?

  Not applicable.

(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.

  No.

(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.  This is a clarification/addition to the NFSv4 RFC and will not
  change its current status.

(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).

  Not applicable.

(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.

  Not applicable

(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.

  Not applicable.
2015-09-27
07 Spencer Shepler Responsible AD changed to Martin Stiemerling
2015-09-27
07 Spencer Shepler IETF WG state changed to Submitted to IESG for Publication from WG Consensus: Waiting for Write-Up
2015-09-27
07 Spencer Shepler IESG state changed to Publication Requested
2015-09-27
07 Spencer Shepler IESG process started in state Publication Requested
2015-09-27
07 Spencer Shepler Intended Status changed to Proposed Standard from None
2015-09-27
07 Spencer Shepler IETF WG state changed to WG Consensus: Waiting for Write-Up from In WG Last Call
2015-09-27
07 Spencer Shepler Notification list changed to "Spencer Shepler" <spencer.shepler@gmail.com>
2015-09-27
07 Spencer Shepler Document shepherd changed to Spencer Shepler
2015-09-27
07 Spencer Shepler Changed document writeup
2015-08-17
07 Spencer Shepler IETF WG state changed to In WG Last Call from WG Document
2015-07-04
07 David Noveck New version available: draft-ietf-nfsv4-rfc3530-migration-update-07.txt
2015-01-04
06 David Noveck New version available: draft-ietf-nfsv4-rfc3530-migration-update-06.txt
2014-09-24
05 David Noveck New version available: draft-ietf-nfsv4-rfc3530-migration-update-05.txt
2014-03-30
04 David Noveck New version available: draft-ietf-nfsv4-rfc3530-migration-update-04.txt
2013-10-12
03 David Noveck New version available: draft-ietf-nfsv4-rfc3530-migration-update-03.txt
2013-08-09
02 David Noveck New version available: draft-ietf-nfsv4-rfc3530-migration-update-02.txt
2013-02-15
01 David Noveck New version available: draft-ietf-nfsv4-rfc3530-migration-update-01.txt
2012-11-20
00 David Noveck New version available: draft-ietf-nfsv4-rfc3530-migration-update-00.txt