NFS Version 4.0 Trunking Update
draft-ietf-nfsv4-mv0-trunking-update-05
Revision differences
Document history
Date | Rev. | By | Action |
---|---|---|---|
2019-04-30
|
05 | (System) | RFC Editor state changed to AUTH48-DONE from AUTH48 |
2019-04-22
|
05 | (System) | RFC Editor state changed to AUTH48 from RFC-EDITOR |
2019-04-02
|
05 | (System) | RFC Editor state changed to RFC-EDITOR from EDIT |
2019-02-01
|
05 | (System) | IANA Action state changed to No IANA Actions |
2019-02-01
|
05 | (System) | RFC Editor state changed to EDIT |
2019-02-01
|
05 | (System) | IESG state changed to RFC Ed Queue from Approved-announcement sent |
2019-02-01
|
05 | (System) | Announcement was received by RFC Editor |
2019-02-01
|
05 | Cindy Morgan | IESG state changed to Approved-announcement sent from IESG Evaluation::AD Followup |
2019-02-01
|
05 | Cindy Morgan | IESG has approved the document |
2019-02-01
|
05 | Cindy Morgan | Closed "Approve" ballot |
2019-02-01
|
05 | Cindy Morgan | Ballot approval text was generated |
2019-02-01
|
05 | Cindy Morgan | Ballot writeup was changed |
2019-02-01
|
05 | Chuck Lever | New version available: draft-ietf-nfsv4-mv0-trunking-update-05.txt |
2019-02-01
|
05 | (System) | New version approved |
2019-02-01
|
05 | (System) | Request for posting confirmation emailed to previous authors: David Noveck , Chuck Lever |
2019-02-01
|
05 | Chuck Lever | Uploaded new revision |
2019-02-01
|
04 | Benjamin Kaduk | [Ballot comment] Thank you for addressing my DISCUSS points! |
2019-02-01
|
04 | Benjamin Kaduk | [Ballot Position Update] Position for Benjamin Kaduk has been changed to No Objection from Discuss |
2019-02-01
|
04 | (System) | Sub state has been changed to AD Followup from Revised ID Needed |
2019-02-01
|
04 | (System) | IANA Review state changed to Version Changed - Review Needed from IANA OK - No Actions Needed |
2019-02-01
|
04 | Chuck Lever | New version available: draft-ietf-nfsv4-mv0-trunking-update-04.txt |
2019-02-01
|
04 | (System) | New version approved |
2019-02-01
|
04 | (System) | Request for posting confirmation emailed to previous authors: David Noveck , Chuck Lever |
2019-02-01
|
04 | Chuck Lever | Uploaded new revision |
2019-01-10
|
03 | Jean Mahoney | Closed request for Last Call review by GENART with state 'No Response' |
2019-01-10
|
03 | Cindy Morgan | IESG state changed to IESG Evaluation::Revised I-D Needed from IESG Evaluation |
2019-01-09
|
03 | Adam Roach | [Ballot Position Update] New position, No Objection, has been recorded for Adam Roach |
2019-01-09
|
03 | Terry Manderson | [Ballot Position Update] New position, No Objection, has been recorded for Terry Manderson |
2019-01-09
|
03 | Ben Campbell | [Ballot comment] General: I don't expect a change in approach this late in the process, but I think the approach of this update (replacing, inserting, … [Ballot comment] General: I don't expect a change in approach this late in the process, but I think the approach of this update (replacing, inserting, and updating sections in the updated RFC) is pretty unfriendly to the readers. This would make sense if we actually rendered patched versions of updated RFCs, but we do not. This leaves readers to flip back and forth to figure out the context of each update. §1: s/"which enables"/"that enables" §5.1 Does "updated introduction" to section 8.4 mean the same as "replaces section 8.4, but not it's subsections?" §5.2.2 (and other sections that add a new subsection to 8.4). Are these assumed to be inserted in a particular location under 8.4? That is, can you state the new section numbers? Otherwise the reader is left to guess where these would be inserted. §6: What is meant by "outside section 8"? |
2019-01-09
|
03 | Ben Campbell | [Ballot Position Update] New position, No Objection, has been recorded for Ben Campbell |
2019-01-09
|
03 | Deborah Brungard | [Ballot Position Update] New position, No Objection, has been recorded for Deborah Brungard |
2019-01-09
|
03 | Benjamin Kaduk | [Ballot discuss] First off, thanks for the work on this document; it's important to get this behavior clarified and functional even for NFSv4.0. That said, … [Ballot discuss] First off, thanks for the work on this document; it's important to get this behavior clarified and functional even for NFSv4.0. That said, this document (along with the pieces of 7530 and 7931 that I read along the way) still leave me uncertain about how some things are supposed to work. (If it's clarified in parts of those documents that I didn't read, I'll happily clear and apologize for the disruption, of course.) To start with, I'm still lacking a clear high-level picture of why a client needs to care about trunking detection vs. just treating all listed addresses as replicas. There are some parts in the body where we talk about, e.g., lock state and similar maintenance, but I don't have a clear picture of what the risks and benefits of (not) tracking trunking are, and this would be a fine opportunity to add some text. Specifically, in Section 5.2.1, we just say that "[a] client may use file system location elements simultaneously to provide higher-performance access to the target file system"; most of the focus of this document makes me think that this statement was intended to apply only to trunking, but I also think there are supposed to be replication-only scenarios that provide performance gains. I'm not sure if we need to clarify the distinction in that location as well as the high-level overview. It's also unclear to me what parts of migration flows are under the control of the client vs. the server. It's clear that the server has to initiate migration via NFS4ERR_MOVED, but my current understanding is just that this prompts the client to look at fs_locations, and the client has control over which alternate location to move to. But there's also a lot of discussion in all three documents about the servers migrating state along with migration, so it seems like the server should be controlling where the client goes. Is this just supposed to be by limiting the fs_locations data to the specific migration target chosen by the server? (If so, this would probably have potential for poor interaction with the implicit filesystem discovery described in Section 5.3.) On the other hand, Section 5.2.6 talks about the server putting entries "that represent addresses usable with the current server or a migration target before those associated with replicas", which seems to imply that there is some other way to know what the migration target is. Section 5.2.6 also tells the client to rely on that ordering: To keep this process as short as possible, Servers are REQUIRED to place file system location entries that represent addresses usable with the current server or a migration target before those associated with replicas. A client can then cease scanning for trunkable file system location entries once it encounters a file system location element whose fs_name differs but I don't think a client actually can do so, since the client has no way to know that the server implements this document as opposed to stock 7530+7931 (at least, no way that I saw). Finally, removing the last paragraph of Section 8.5 of RFC 7530 could have negative operational impact if updated clients interact with non-updated servers/environments that are misconfigured in the described fashion. It's probably worth stating in the top-level Section 5 that such misconfigured servers are believed to no longer exist (if that's in fact true, of course; if not, we'd need to reconsider the change). |
2019-01-09
|
03 | Benjamin Kaduk | [Ballot comment] Section 1 As part of addressing this need, [RFC7931] introduces trunking into NFS version 4.0 along with a trunking … [Ballot comment] Section 1 As part of addressing this need, [RFC7931] introduces trunking into NFS version 4.0 along with a trunking detection mechanism. This enables a client to determine whether two distinct network addresses are connected to the same NFS version 4.0 server instance. Nevertheless, the use of the concept of server-trunkability is the same in both protocol versions. Er, what are the two protocol versions in question? (I assume 4.0 and 4.1, but you don't say 4.1 anywhere.) o To provide NFS version 4.0 with a means of trunking discovery, compatible with the means of trunking detection introduced by [RFC7931]. We haven't yet mentioned that the distinction between "detection" and "discovery" is important, so it's probably worth a forward reference to the text below. Section 5.1 The fs_locations attribute (described as "RECOMMENDED" in [RFC7530]) If you're going to describe this section as "replacing Section 8.1 of [RFC7530]", then it needs to stand on its own without reference to the current Section 8.1 of RFC 7530. That is, if the "RECOMMENDED" nature is to remain, then it should be described as such de novo in this text. Clients use the existing means for NFSv4.0 trunking detection, defined in [RFC7931], to confirm that such addresses are connected to the same server. The client can ignore addresses found not to be so connected. nit: I would suggest phrasing this as "use the NFSv4.0 trunking detection mechanism [RFC7931] to confirm [...]", as temporal refernces like "existing" may not age well. not-nit: "ignore" is pretty strong; does this imply that a client is free to ignore things like migration, replication, and referrals? location entries. If a file system location entry specifies a network address, there is only a single corresponding location element. When a file system location entry contains a host name, the client resolves the hostname, producing one file system location element for each of the resulting network addresses. Issues regarding the trustworthiness of hostname resolutions are further discussed in Section 7. nit(?) this is confusing if we read "Section 7" as being "Section 7 of RFC 7530", which is a tempting reading since this text is supposed to replace text in that document. Perhaps "Section 7 of [[this document]]" would make more sense (but I also forget the RFC Editor's policy on such self-references). Section 5.2.1 The client utilizes trunking detection and/or discovery, further described in Section 5.2.2 of the current document, to determine a nit(?) perhaps s/the current document/[[this document]]/ as above (for update by the RFC Editor). I'll stop commenting this construction, though of course if such changes are made they should be done globally. Section 5.2.3 Because of the need to support multiple connections, clients face the What need? Where is this need articulated? As a result, clients supporting multiple connection types need to attempt to establish a connection on various connection types allowing it to determine which connection types are supported. nit: maybe describe this as a "trial and error" approach to connection type support determination? To avoid waiting when there is at least one viable network path available, simultaneous attempts to establish multiple connection types are possible. Once a viable connection is established, the client discards less-preferred connections. It's probably worth referencing the "happy eyeballs" technique used elsewhere (e.g., RFC 8305) as being analogous. Section 5.2.5 Such migration can help provide load balancing or general resource reallocation. [...] side note: is this load balancing generally going to be just of a "move a filesystem or ten to a different server when load gets too high" or are people also doing "send different clients to different replicas for the same filesystem" live load-balancing? Section 5.2.6 When the set of network addresses designated by a file system location attribute changes, NFS4ERR_MOVED might or might not result. In some of the cases in which NFS4ERR_MOVED is returned migration has occurred, while in others there is a shift in the network addresses used to access a particular file system with no migration. I got pretty confused when I first read this, thinking there was some implication that a server could introduce a fleeting NFS4ERR_MOVED as a notification that addresses changed, even if the server could otherwise continue handling the client's requests. Perhaps: % When the set of network addresses on a server change in a way that would % affect a file system location attribute, there are several possible % outcomes for clients currently accessing that file system. NFS4ERR_MOVED % is returned only when the server cannot satisfy a request from the client, % whether because the file system has been migrated to a different server, is % only accessible at a different trunked address on the same server, or some % other reason. Similarly, we may want to clarify that (e.g.) case (1) is not going to result in an NFS4ERR_MOVED. 2. When the list of network addresses is a subset of that previously in effect, immediate action is not needed if an address missing in the replacement list is not currently in use by the client. The client should avoid using that address in the future, whether the address is for a replica or an additional path to the server being used. "avoid using that address in the future" needs to be scoped to this filesystem; it's not going to work if clients treat it as a global blacklisting. Although significant harm cannot arise from this misapprehension, it can give rise to disconcerting situations. For example, if a lock has been revoked during the address shift, it will appear to the client as if the lock has been lost during migration, normally calling for it to be recoverable via an fs-specific grace period associated with the migration event. I think this example needs to be clarified more or rewritten to describe what behavior fo which participant that normally happens does not happen (specifically, the "normally ..." clause). from the current fs_name, or whose address is not server-trunkable with the one it is currently using. nit: does it make more sense to put the address clause first, since fs_name is only valid within the scope of a given address/server? Section 5.3 As mentioned above, a single file system location entry may have a server address target in the form of a DNS host name that resolves to multiple network addresses, while multiple file system location entries may have their own server address targets that reference the same server. nit: I'm not sure that "while" is the right word here. Perhaps "and conversely"? When server-trunkable addresses for a server exist, the client may assume that for each file system in the namespace of a given server network address, there exist file systems at corresponding namespace locations for each of the other server network addresses. It may do Pretty sure you need to say "trunkable" here, too. this even in the absence of explicit listing in fs_locations. Such I may be confused, but we're talking about different file systems within a single server's single-server namespace, right? So there is not even a way for them to be listed in the fs_locations for queries on FHs in the current filesystem (unless the server exports the same filesystem under different paths in its namespace for some reason). So, we should probably be saying more about how these are fs_locations results returned for queries against different filesystems hosted on the same server... corresponding file system locations can be used as alternative locations, just as those explicitly specified via the fs_locations attribute. ... (and possibly some related tweaks in this part too). Section 7 We probably need to reiterate the privacy considerations inherent in the UCS approach, mentioned at the end of Section 5.6 of RFC 7931. o When DNS is used to convert NFS server host names to network addresses and DNSSEC [RFC4033] is not available, the validity of the network addresses returned cannot be relied upon. However, when the client uses RPCSEC_GSS [RFC7861] to access NFS servers, it is possible for mutual authentication to detect invalid server addresses. Other forms of transport layer nit: It seems to only sort-of be the case that the mutual authentication detects invalid addresses. I tend to think of the property involved as ensuring that I am talking to who I think I am, which encompasses both the intended network address and the stuff on the other end. On the other hand, one could imagine some bizzare deployments that share kerberos keys across servers where GSS could succeed (if the acceptor didn't have strict host name checking in place) but the address would still be unintended. If I had to rephrase this (unclear that it's really necessary), I might go with something like "to increase confidence in the correctness of server addresses", but there are lots of valid things to say here and it's not a big deal. o Fetching file system location information SHOULD be performed using RPCSEC_GSS with integrity protection, as previously I forget if we have to say "integrity protection or better" or if this phrasing also includes the confidentiality protection case. When a file system location attribute is fetched upon connecting with an NFSv4 server, it SHOULD, as stated above, be done using RPCSEC_GSS with integrity protection. It looks like this is now three places where this normative requirement is stated (7530's security considerations, and earlier in this section). Usually we try to stick to just one, to avoid risk of conflicting interpretations, and restate requirements non-normatively when needed. (It's not even clear that this duplication is needed, though.) For example, if a range of network addresses can be determined that assure that the servers and clients using AUTH_SYS are subject to appropriate constraints (such as physical network isolation and the use of administrative controls within the operating systems), then network adresses in this range can be used with others discarded or restricted in their use of AUTH_SYS. I'd strongly suggest adding a comma or something here to avoid the misparsing of "used with others". To summarize considerations regarding the use of RPCSEC_GSS in fetching file system location information, consider the following possibilities for requests to interrogate location information, with interrogation approaches on the referring and destination servers arrived at separately: I don't understand what this is trying to say, especially in light of the following bullet points being essentially recommendations for behavior (in one case, limited to a specific situation where disrecommended behavior is unavoidable). I do appreciate the good discussions about the provenance and reliability of location data -- it seems to be pretty complete, so thank you! |
2019-01-09
|
03 | Benjamin Kaduk | [Ballot Position Update] New position, Discuss, has been recorded for Benjamin Kaduk |
2019-01-09
|
03 | Alvaro Retana | [Ballot Position Update] New position, No Objection, has been recorded for Alvaro Retana |
2019-01-08
|
03 | Suresh Krishnan | [Ballot Position Update] New position, No Objection, has been recorded for Suresh Krishnan |
2019-01-08
|
03 | Warren Kumari | [Ballot comment] Thank you for this document, and special thanks to Shwetha Bhandari for the OpsDir review. |
2019-01-08
|
03 | Warren Kumari | [Ballot Position Update] New position, No Objection, has been recorded for Warren Kumari |
2019-01-08
|
03 | Mirja Kühlewind | [Ballot Position Update] New position, No Objection, has been recorded for Mirja Kühlewind |
2019-01-07
|
03 | Alexey Melnikov | [Ballot Position Update] New position, No Objection, has been recorded for Alexey Melnikov |
2019-01-03
|
03 | Spencer Dawkins | IESG state changed to IESG Evaluation from Waiting for Writeup |
2019-01-03
|
03 | (System) | IANA Review state changed to IANA OK - No Actions Needed from Version Changed - Review Needed |
2018-12-28
|
03 | Amy Vezza | Placed on agenda for telechat - 2019-01-10 |
2018-12-28
|
03 | Spencer Dawkins | RFC Editor Note was changed |
2018-12-28
|
03 | Spencer Dawkins | Ballot approval text was generated |
2018-12-28
|
03 | Spencer Dawkins | Ballot approval text was generated |
2018-12-28
|
03 | Spencer Dawkins | RFC Editor Note was changed |
2018-12-28
|
03 | Spencer Dawkins | RFC Editor Note was changed |
2018-12-28
|
03 | Spencer Dawkins | RFC Editor Note was changed |
2018-12-28
|
03 | Spencer Dawkins | RFC Editor Note for ballot was generated |
2018-12-28
|
03 | Spencer Dawkins | RFC Editor Note for ballot was generated |
2018-12-28
|
03 | Spencer Dawkins | Ballot has been issued |
2018-12-28
|
03 | Spencer Dawkins | [Ballot Position Update] New position, Yes, has been recorded for Spencer Dawkins |
2018-12-28
|
03 | Spencer Dawkins | Created "Approve" ballot |
2018-12-28
|
03 | Spencer Dawkins | Ballot writeup was changed |
2018-12-27
|
03 | (System) | IANA Review state changed to Version Changed - Review Needed from IANA OK - No Actions Needed |
2018-12-27
|
03 | Chuck Lever | New version available: draft-ietf-nfsv4-mv0-trunking-update-03.txt |
2018-12-27
|
03 | (System) | New version approved |
2018-12-27
|
03 | (System) | Request for posting confirmation emailed to previous authors: David Noveck , Chuck Lever |
2018-12-27
|
03 | Chuck Lever | Uploaded new revision |
2018-12-13
|
02 | Tero Kivinen | Request for Last Call review by SECDIR Completed: Has Nits. Reviewer: Christopher Wood. |
2018-11-27
|
02 | Shwetha Bhandari | Request for Last Call review by OPSDIR Completed: Ready. Reviewer: Shwetha Bhandari. Sent review to list. |
2018-11-27
|
02 | (System) | IESG state changed to Waiting for Writeup from In Last Call |
2018-11-26
|
02 | (System) | IANA Review state changed to IANA OK - No Actions Needed from IANA - Review Needed |
2018-11-26
|
02 | Sabrina Tanamal | (Via drafts-lastcall@iana.org): IESG/Authors/WG Chairs: The IANA Functions Operator has reviewed draft-ietf-nfsv4-mv0-trunking-update-02, 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-mv0-trunking-update-02, 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 |
2018-11-19
|
02 | Gunter Van de Velde | Request for Last Call review by OPSDIR is assigned to Shwetha Bhandari |
2018-11-19
|
02 | Gunter Van de Velde | Request for Last Call review by OPSDIR is assigned to Shwetha Bhandari |
2018-11-09
|
02 | Tero Kivinen | Request for Last Call review by SECDIR is assigned to Christopher Wood |
2018-11-09
|
02 | Tero Kivinen | Request for Last Call review by SECDIR is assigned to Christopher Wood |
2018-11-07
|
02 | Jean Mahoney | Request for Last Call review by GENART is assigned to Jari Arkko |
2018-11-07
|
02 | Jean Mahoney | Request for Last Call review by GENART is assigned to Jari Arkko |
2018-11-05
|
02 | Amy Vezza | IANA Review state changed to IANA - Review Needed |
2018-11-05
|
02 | Amy Vezza | The following Last Call announcement was sent out (ends 2018-11-27): From: The IESG To: IETF-Announce CC: draft-ietf-nfsv4-mv0-trunking-update@ietf.org, Spencer Shepler , nfsv4@ietf.org, nfsv4-chairs@ietf.org, … The following Last Call announcement was sent out (ends 2018-11-27): From: The IESG To: IETF-Announce CC: draft-ietf-nfsv4-mv0-trunking-update@ietf.org, Spencer Shepler , 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.0 Trunking Update) 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.0 Trunking 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 2018-11-27. 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. Please note that this is a three-week Last Call, to allow for review after IETF 103, currently in progress. Abstract The file system location-related attribute in NFS version 4.0, fs_locations, informs clients about alternate locations of file systems. An NFS version 4.0 client can use this information to handle migration and replication of server filesystems. This document describes how an NFS version 4.0 client can additionally use this information to discover an NFS version 4.0 server's trunking capabilities. This document updates RFC 7530. The file can be obtained via https://datatracker.ietf.org/doc/draft-ietf-nfsv4-mv0-trunking-update/ IESG discussion can be tracked via https://datatracker.ietf.org/doc/draft-ietf-nfsv4-mv0-trunking-update/ballot/ No IPR declarations have been submitted directly on this I-D. |
2018-11-05
|
02 | Amy Vezza | IESG state changed to In Last Call from Last Call Requested |
2018-11-05
|
02 | Spencer Dawkins | Last call was requested |
2018-11-05
|
02 | Spencer Dawkins | Ballot approval text was generated |
2018-11-05
|
02 | Spencer Dawkins | Ballot writeup was generated |
2018-11-05
|
02 | Spencer Dawkins | IESG state changed to Last Call Requested from AD Evaluation |
2018-11-05
|
02 | Spencer Dawkins | Last call announcement was changed |
2018-11-05
|
02 | Spencer Dawkins | Last call announcement was generated |
2018-11-05
|
02 | Chuck Lever | New version available: draft-ietf-nfsv4-mv0-trunking-update-02.txt |
2018-11-05
|
02 | (System) | New version approved |
2018-11-05
|
02 | (System) | Request for posting confirmation emailed to previous authors: David Noveck , Chuck Lever |
2018-11-05
|
02 | Chuck Lever | Uploaded new revision |
2018-10-22
|
01 | Spencer Dawkins | IESG state changed to AD Evaluation from Publication Requested |
2018-10-21
|
01 | Spencer Shepler | Working Group: NFSv4 Area Director: Spencer Dawkins Document Author/Shepherd: Spencer Shepler Internet Draft: NFS version 4.0 Trunking Update draft-ietf-nfsv4-mv0-trunking-update-01 (1) What type of RFC is … Working Group: NFSv4 Area Director: Spencer Dawkins Document Author/Shepherd: Spencer Shepler Internet Draft: NFS version 4.0 Trunking Update draft-ietf-nfsv4-mv0-trunking-update-01 (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 7530 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 The location-related attribute in NFS version 4.0, fs_locations, informs clients about alternate locations of file systems. An NFS version 4.0 client can use this information to handle migration and replication of server filesystems. This document describes how an NFS version 4.0 client can additionally use this information to discover an NFS version 4.0 server's trunking capabilities. This document updates RFC 7530. 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 not 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 reference updates required that 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 7530. (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 |
2018-10-21
|
01 | Spencer Shepler | Responsible AD changed to Spencer Dawkins |
2018-10-21
|
01 | Spencer Shepler | IETF WG state changed to Submitted to IESG for Publication from WG Consensus: Waiting for Write-Up |
2018-10-21
|
01 | Spencer Shepler | IESG state changed to Publication Requested |
2018-10-21
|
01 | Spencer Shepler | IESG process started in state Publication Requested |
2018-10-21
|
01 | Spencer Shepler | Changed consensus to Yes from Unknown |
2018-10-21
|
01 | Spencer Shepler | Intended Status changed to Proposed Standard from None |
2018-10-21
|
01 | Spencer Shepler | Changed document writeup |
2018-10-10
|
01 | Spencer Shepler | IETF WG state changed to WG Consensus: Waiting for Write-Up from WG Document |
2018-10-10
|
01 | Spencer Shepler | Notification list changed to Spencer Shepler <spencer.shepler@gmail.com> |
2018-10-10
|
01 | Spencer Shepler | Document shepherd changed to Spencer Shepler |
2018-07-16
|
01 | Chuck Lever | New version available: draft-ietf-nfsv4-mv0-trunking-update-01.txt |
2018-07-16
|
01 | (System) | New version approved |
2018-07-16
|
01 | (System) | Request for posting confirmation emailed to previous authors: David Noveck , Chuck Lever |
2018-07-16
|
01 | Chuck Lever | Uploaded new revision |
2018-07-16
|
00 | (System) | Document has expired |
2018-01-08
|
00 | Chuck Lever | New version available: draft-ietf-nfsv4-mv0-trunking-update-00.txt |
2018-01-08
|
00 | (System) | WG -00 approved |
2018-01-08
|
00 | Chuck Lever | Set submitter to "Charles Lever ", replaces to (none) and sent approval email to group chairs: nfsv4-chairs@ietf.org |
2018-01-08
|
00 | Chuck Lever | Uploaded new revision |