Network File System (NFS) Version 4 Minor Version 1 Protocol
draft-ietf-nfsv4-rfc5661sesqui-msns-04
Revision differences
Document history
Date | Rev. | By | Action |
---|---|---|---|
2020-08-10
|
04 | (System) | RFC Editor state changed to AUTH48-DONE from AUTH48 |
2020-07-27
|
04 | (System) | RFC Editor state changed to AUTH48 from RFC-EDITOR |
2020-05-05
|
04 | (System) | RFC Editor state changed to RFC-EDITOR from EDIT |
2020-03-09
|
03 | (System) | RFC Editor state changed to EDIT |
2020-03-04
|
04 | (System) | IANA Action state changed to RFC-Ed-Ack from Waiting on RFC Editor |
2020-03-04
|
04 | (System) | IANA Action state changed to Waiting on RFC Editor from In Progress |
2020-03-04
|
04 | (System) | IANA Action state changed to In Progress from Waiting on Authors |
2020-03-03
|
04 | (System) | IANA Action state changed to Waiting on Authors from In Progress |
2020-03-03
|
04 | (System) | IANA Action state changed to In Progress from Waiting on Authors |
2020-03-02
|
04 | (System) | IANA Action state changed to Waiting on Authors from In Progress |
2020-03-02
|
04 | (System) | RFC Editor state changed to EDIT |
2020-03-02
|
04 | (System) | IESG state changed to RFC Ed Queue from Approved-announcement sent |
2020-03-02
|
04 | (System) | Announcement was received by RFC Editor |
2020-03-02
|
04 | (System) | IANA Action state changed to In Progress |
2020-03-02
|
04 | Amy Vezza | IESG state changed to Approved-announcement sent from Approved-announcement to be sent |
2020-03-02
|
04 | Amy Vezza | IESG has approved the document |
2020-03-02
|
04 | Amy Vezza | Closed "Approve" ballot |
2020-03-02
|
04 | Amy Vezza | Ballot approval text was generated |
2020-03-02
|
04 | Magnus Westerlund | IESG state changed to Approved-announcement to be sent from IESG Evaluation::AD Followup |
2020-03-01
|
04 | Benjamin Kaduk | [Ballot comment] Thank you for addressing my Discuss and Comment points! [I did not exhaustively check all the comments but I think the updates generally … [Ballot comment] Thank you for addressing my Discuss and Comment points! [I did not exhaustively check all the comments but I think the updates generally look good.] A few final remarks on the -04, which do not necessarily need any changes or response: The RFC Editor is probably going to tweak a lot of commas, but perhaps it's best to leave it to them and not try to churn things around more ourselves. Section 11.1.2 o File system location entries provide the individual file system locations within the file system location attributes. Each such entry specifies a server, in the form of a host name or an address, and an fs name, which designates the location of the file system within the server's local namespace. A file system location entry designates a set of server endpoints to which the client may establish connections. There may be multiple endpoints because a host name may map to multiple network addresses and because multiple connection types may be used to communicate with a single network address. However, except where an explicit port numbers are used to designate a set of server within a single server node, all such endpoints MUST designate a way of connecting to a single server. The exact form of the location entry varies with the particular file system location attribute used, as described in Section 11.2. I'm not entirely sure I understand what is being excluded in the "designate a set of server [sic] within a single server node". Section 11.5.4.1 o When the fs_locations_info attribute shows the two entries as not having the same simultaneous-use class, trunking is inhibited and the two access paths cannot be used together. In this case the two paths can be used serially with no transition activity required on the part of the client. In this case, any I expect that most readers will know what "used serially" means, so it may not be necessary to clarify. |
2020-03-01
|
04 | Benjamin Kaduk | [Ballot Position Update] Position for Benjamin Kaduk has been changed to No Objection from Discuss |
2020-02-03
|
04 | Gunter Van de Velde | Closed request for Last Call review by OPSDIR with state 'Overtaken by Events' |
2020-01-28
|
04 | (System) | Sub state has been changed to AD Followup from Revised ID Needed |
2020-01-28
|
04 | (System) | IANA Review state changed to Version Changed - Review Needed from IANA OK - Actions Needed |
2020-01-28
|
04 | David Noveck | New version available: draft-ietf-nfsv4-rfc5661sesqui-msns-04.txt |
2020-01-28
|
04 | (System) | New version approved |
2020-01-28
|
04 | (System) | Request for posting confirmation emailed to previous authors: David Noveck , Chuck Lever |
2020-01-28
|
04 | David Noveck | Uploaded new revision |
2020-01-19
|
03 | Gunter Van de Velde | Assignment of request for Last Call review by OPSDIR to Tim Wicinski was marked no-response |
2019-12-19
|
03 | Amy Vezza | IESG state changed to IESG Evaluation::Revised I-D Needed from IESG Evaluation |
2019-12-19
|
03 | Alvaro Retana | [Ballot Position Update] New position, No Objection, has been recorded for Alvaro Retana |
2019-12-18
|
03 | Adam Roach | [Ballot comment] Thanks for the work put into this revision, and especially for the work that went into creating a minimal set of changes to … [Ballot comment] Thanks for the work put into this revision, and especially for the work that went into creating a minimal set of changes to the predecessor document, and for the careful documentation of the changes and their rationale. This is a model update document. I have only editorial comments on the document. --------------------------------------------------------------------------- Abstract: > This document obsoletes RFC5661. It substantialy revises the > treatment of features relating to multi-server namesapce superseding > the description of those features appearing in RFC5661. Nit: "RFC 5661" (see RFC 7322 §3.5) --------------------------------------------------------------------------- §1.1: > description of the NFS 4.1 protocol previously defined in RFC5661 Nit: "RFC 5661" > [62]. RFC5661 is obsoleted by this document. However, the update Nit: "RFC 5661" > o Work would have to be done with regard to RFC8178 [63] which Nit: "RFC 8178" > establishes NFSv4-wide versioning rules. As RFC5661 is curretly Nit: "RFC 5661" > arrive at a situation in which there would be no need for RFC8178 Nit: "RFC 8178" > o Work would have to be done with regard to RFC8434 [66], which Nit: "RFC 8434" > clearly defined in RFC5661. When that work is done and the Nit: "RFC 5661" --------------------------------------------------------------------------- §11.1.1: > Despite the support for trunking detection there was no > description of trunking discovery provided in RFC5661 [62], making > it necessary to provide those means in this document. Nit: "RFC 5661" > Two network addresses connected to the same server are said to be > server-trunkable. Two such addresses support the use of clientid ID > trunking, as described in Section 2.10.5. Nit: "client ID trunking" --------------------------------------------------------------------------- §11.1.1: > 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 Section 2.10.5, 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. This is a long and complex sentence, and is difficult to understand. Consider breaking up into several smaller sentences. --------------------------------------------------------------------------- §11.1.2: > Discussion of the term "replica" is complicated by the fact that the > term was used in RFC5661 [62], with a meaning different from that in Nit: "RFC 5661" --------------------------------------------------------------------------- §22.1: > This update does not require any modification of or additions to > registry entries or registry rules associated with NFSv4.1. However, > since this document is intended to obsolete RFC5661, it will be Nit: "RFC 5661" --------------------------------------------------------------------------- Appendix A: > As a result of the following problems in RFC5661 [62], it is Nit: "RFC 5661" > o RFC5661 [62], while it dealt with situations in which various Nit: "RFC 5661" > Migration was first explained cearly in RFC7530 [64] and corrected Nit: "early... RFC 7530" > and clarified by RFC7931 [65]. No correesponding explanation for Nit: "RFC 7931" > simultaneously in RFC5661 [62] was not clear as it covered the two Nit: "RFC 5661" > presenting in Section 11 a replacement for Section 11 within RFC5661 Nit: "RFC 5661" > In addition, there are also updates to other sections of RFC5661 Nit: "RFC 5661" ---------------------------------------------------------------------- §B.1: > replacing existing sub-sections within section 11 of RFC5661 [62]: Nit: "RFC 5661" > replaces the existing material in RFC5661 [62] ranging from the Nit: "RFC 5661" > Sections 11.4 and 11.5 (of RFC5661 [62]) is necessary. The Nit: "RFC 5661" > o A major replacement for the existing Section 11.7 of RFC5661 [62] Nit: "RFC 5661" > o A replacement for the existing Section 11.10 of RFC5661 [62] Nit: "RFC 5661" > addressed in RFC5661 [62] where the concepts of a replica and a Nit: "RFC 5661" ---------------------------------------------------------------------- §B.1.1: > in a separate Section 11.5 of RFC5661 [62]. Because of the new Nit: "RFC 5661" > As a result, Section 11.5 which will replace Section 11.4 of RFC5661 Nit: "RFC 5661" > the material in Section 11.4 of RFC5661 [62] exclusive of Nit: "RFC 5661" > 11.4.3 of RFC5661 [62]. 11.4.4, and 11.4.5. Nit: "RFC 5661" ---------------------------------------------------------------------- §B.1.2: > in Section 11.7 of RFC5661 [62] has been reorganized and augmented as Nit: "RFC 5661" > transitions while the bulk of the former Section 11.7 (in RFC5661 Nit: "RFC 5661" > As part of this general re-organization, Section 11.7 of RFC5661 [62] Nit: "RFC 5661" > o Sections 11.7 and 11.7.1 of RFC5661 [62] are to be replaced by Nit: "RFC 5661" > o Section 11.7.2 (and included subsections) of RFC5661 [62] are to Nit: "RFC 5661" > o Sections 11.7.3, 11.7.4. 11.7.5, 11.7.5.1, and 11.7.6 of RFC5661 Nit: "RFC 5661" > o Section 11.7.7 of RFC5661 [62] is to be replaced by Nit: "RFC 5661" > o Sections 11.7.8, 11.7.9. and 11.7.10 of RFC5661 [62] are to be Nit: "RFC 5661" ---------------------------------------------------------------------- §B.1.3: > Section 11.10 of RFC5661 [62]) does not clearly distinguish these Nit: "RFC 5661" > in effect at the time RFC5661 [62] was written, and needed to be Nit: "RFC 5661" > RFC8178 [63]. Nit: "RFC 8178" ---------------------------------------------------------------------- §B.2: > o The existing treatment of EXCHANGE_ID (in Section 18.35 of RFC5661 Nit: "RFC 5661" > RFC5661 [62]) is not sufficiently clear about the purpose and use Nit: "RFC 5661" > differences between it and the treatment within RFC5661 [62] are Nit: "RFC 5661" ---------------------------------------------------------------------- §B.2.1: > (in RFC5661 [62]) that cause problems for Transparent State Migration Nit: "RFC 5661" > intended to supersede the treatment in Section 18.35 of RFC5661 [62]. Nit: "RFC 5661" > RFC5661 [62]. Nit: "RFC 5661" ---------------------------------------------------------------------- §B.2.2: > in RFC5661 [62] to arrive at the treatment in Section 18.51. Nit: "RFC 5661" ---------------------------------------------------------------------- §B.3: > issues, some uses of the term "replica" in RFC5661 [62] have Nit: "RFC 5661" > RFC5661 [62]) needs to be updated to reflect the different Nit: "RFC 5661" > of reclaim-related errors in Section 15 of RFC5661 [62], so the Nit: "RFC 5661" > many other RFC5661 erratas, is addressed in this document because Nit: "RFC 5661" ---------------------------------------------------------------------- §B.4: > o The summary that appeared in Section 1.7.3.3 of RFC5661 [62] was Nit: "RFC 5661" > RFC5661 [62] needed to be replaced, since the previous text Nit: "RFC 5661" > RFC5661 [62] needed to be revised, to more clearly explain the Nit: "RFC 5661" ---------------------------------------------------------------------- Appendix C: > o The Security Considerations Section of RFC5661 [62] is not written Nit: "RFC 5661" > in accord with RFC3552 [68] (also BCP72). Of particular concern Nit: "RFC 3552" > pervasive monitoring attacks such as those described in RFC7258 Nit: "RFC 7258" > type of protocol artifact alluded to in RFC7258, which can enable Nit: "RFC 7258" |
2019-12-18
|
03 | Adam Roach | [Ballot Position Update] New position, No Objection, has been recorded for Adam Roach |
2019-12-18
|
03 | Martin Vigoureux | [Ballot Position Update] New position, No Objection, has been recorded for Martin Vigoureux |
2019-12-18
|
03 | Alissa Cooper | [Ballot Position Update] New position, No Objection, has been recorded for Alissa Cooper |
2019-12-18
|
03 | Warren Kumari | [Ballot comment] Kerphew! |
2019-12-18
|
03 | Warren Kumari | [Ballot Position Update] New position, No Objection, has been recorded for Warren Kumari |
2019-12-18
|
03 | Barry Leiba | [Ballot Position Update] New position, No Objection, has been recorded for Barry Leiba |
2019-12-18
|
03 | Benjamin Kaduk | [Ballot discuss] Thank you for this document (and its predecessor); it's important to get these points clarified, and sooner rather than later. I expect that … [Ballot discuss] Thank you for this document (and its predecessor); it's important to get these points clarified, and sooner rather than later. I expect that the following few issues should be quickly resolvable. Section 11.10.1 includes a reference to "Section 11.7.2.1 of RFC5661", but this document is obsoleting that document. It seems internally inconsistent to both obsolete and depend on the same source -- if we rely on that content, it should be included in this document. This is somewhat awkward since the limited nature of the update results in my not having the full context of the rest of the document; with that limitation in my understanding in mind, I'd like to confirm that we're comfortable with the use of "network address" in the context of trunking/migration, specifically the extent to which we do not discuss port numbers. The relevant XDR types do allow for optional port numbers to be included, with a default to be used when not specified, but in this document we do have a new note that different ports may be used for different connection types to the same logical server, and also that different ports "is not the essence of the distinction between the two endpoints". I think there might be cases where the port is relevant for a distinction, but the main ones I can think of are of questionable relevance (essentially, roughly equivalent to multiple userspace NFS servers on a single host but in different trust/privilege domains) -- I'd like another opinion or several. In a similar "discuss discuss" vein, Section 11.10.8 describes a scenario that does not give much clarity, at a protocol level, into what degree of replication synchronization a client can expect from a given file system that advertises multiple replicas. I recognize that this is de facto just stating the deployed reality, but it's also hard to feel good about having this level of ambiguity in a propsed standard, and the (unchanged) text in Section 11.5.5 seems to impose a stricter consistency requirement, at least on potential migration targets. (A bit more detail in the COMMENT section.) Section 11.13.2 mentions that "[i]ssues connected with a client impersonating another by presenting another client's id string are discussed in Section 21", but I failed to find this discussion in Section 21. (The discuss-level issue is just the internal inconsistency; there's a decent argument that this is covered by Appendix C's "not written in accord with RFC3552". Though if the text was already written for draft-ietf-nfsv4-mv1-msns-update, not including it here seems a little silly.) |
2019-12-18
|
03 | Benjamin Kaduk | [Ballot comment] I think I may have mistakenly commented on some sections that are actually just moved text, since my lookahead window in the diff … [Ballot comment] I think I may have mistakenly commented on some sections that are actually just moved text, since my lookahead window in the diff was too small. I expect it's most appropriate to defer those to for the full -bis, so sorry to have them lumped in here. Thank you for all the effort put in to get the diff against RFC 5661 to be minimal! I know that the current default output formatting is rather different than what is done in RFC 5661, but this diff is pretty easy to read. Thank you also for the detailed discussion in Appendix C; I do not think I could add anything more! While the security posture of the current deployed state of NFSv4 is not great (though, arguably, somewhat understandable given the path we took to get there), this is the right start to making any sort of improvement. Since the "Updates:" header is part of the immutable RFC text (though "Updated by:" is mutable), we should probably explicitly state that "the updates that RFCs 8178 and 8434 made to RFC 5661 apply equally to this document". I note inline (in what is probably too many places; please don't reply at all of them!) some question about how clear the text is that a file system migration is something done at a per-file-system granularity, and that migrating a client at a time is not possible. As was the case for my Discuss point about addresses/port-numbers, I'm missing the context of the rest of the document, so perhaps this is a non-issue, but the consequences of getting it wrong seem severe enough that I wanted to check. Does a client have any way to know in advance that two addresses will be session-trunkable other than the one listed in Section 11.1.1 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"? It seems like mostly we're defining the property by saying that the client has to try it and see if it works; I'd love to be wrong about that. Section 1.1 The revised description of the NFS version 4 minor version 1 (NFSv4.1) protocol presented in this update is necessary to enable full use of trunking in connection with multi-server namespace features and to enable the use of transparent state migration in connection with NFSv4.1. [...] nit: do we expect all readers to know what is meant by "trunking" with no other lead-in? This limited scope update is applied to the main NFSv4.1 RFC with the nit: hyphenate "limited-scope" scope as could expected by a full update of the protocol. Below are some areas which are known to need addressing in a future update of the protocol. [...] side note: I'd be interested in better understanding the preference for the subjunctive verb tense for most of these points ("work would have to be done"); my naive expectation would be that since there are plans to undertake the work, just "work needs to be done" or "work will be done" might suffice. o Work would have to be done with regard to RFC8178 [63] which establishes NFSv4-wide versioning rules. As RFC5661 is curretly inconsistent with this document, changes are needed in order to arrive at a situation in which there would be no need for RFC8178 to update the NFSv4.1 specfication. nit: s/this document/that document/ -- "this document" is draft-ietf-nfsv4-rfc5661sesqui-msns. o Work would have to be done with regard to RFC8434 [66], which establishes the requirements for pNFS layout types, which are not clearly defined in RFC5661. When that work is done and the resulting documents approved, the new NFSv4.1 specfication document will provide a clear set of requirements for layout types and a description of the file layout type that conforms to those requirements. Other layout types will have their own specfication documents that conforms to those requirements as well. It's not entirely clear to me that the other layout types need to get mentioned in this document; how do they relate to the formal status of the "current NFSv4.1 core protocol specification document"? o Work would have to be done to address many erratas relevant to RFC 5661, other than errata 2006 [60], which is addressed in this document. That errata was not deferrable because of the interaction of the changes suggested in that errata and handling of state and session migration. The erratas that have been deferred include changes originally suggested by a particular errata, which change consensus decisions made in RFC 5661, which need to be changed to ensure compatibility with existing implementations that do not follow the handling delineated in RFC 5661. Note that it is expected that such erratas will remain This sentence is pretty long and hard to follow; maybe it could be split after "change consensus decisions made in RFC 5661" and the second half start with a more declarative statement about existing implementations? (E.g., "Existing implementations did not perform handling as delineated in RFC 5661 since the procedures therein were not workable, and in order to have the specification accurately reflect the existing deployment base, changes are needed [...]") relevant to implementers and the authors of an eventual rfc5661bis, despite the fact that this document, when approved, will obsolete RFC 5661. (I assume the RFC Editor can tweak this line to reflect what actually happens; my understanding is that the errata reports will get cloned to this-RFC.) [rant about "errata" vs. "erratum" elided] Section 2.10.4 Servers each specify a server scope value in the form of an opaque string eir_server_scope returned as part of the results of an EXCHANGE_ID operation. The purpose of the server scope is to allow a group of servers to indicate to clients that a set of servers sharing the same server scope value has arranged to use compatible values of otherwise opaque identifiers. Thus, the identifiers generated by two servers within that set can be assumed compatible so that, in some cases, identifiers generated by one server in that set may be presented to another server of the same scope. Is there more that we can say than "in some cases"? The previous text implies a higher level of reliability than just "some cases", to me. Section 2.10.4 I see the list of identifier types for which same-scope compatibility applies got reduced from RFC 5661 to this document, by removing session ID, client ID, and state ID values. For at least one of those I can see this making sense as only being workable when the server really is "the same server", inline with the improved discussion of migration vs. trunking that is a main focus of this document. Does that justification apply to all of them, or are there more reasons involved? We also remove the text about a client needing to compare server scope values during a potential migration event, to determine whether the migration preserved state or a reclaim is needed. I thought this scenario would still be possible (and thus still need to be listed), though perhaps we are claiming that it is so under-specified so as to be never workable in practice? Section 2.10.5 o When eir_server_scope changes, the client has no assurance that any id's it obtained previously (e.g. file handles, state ids, client ids) can be validly used on the new server, and, even if It's interesting to see file handles, state ids, and client ids listed together here (nit: also with lowercase "id"), when in the previous section we have removed state IDs and client IDs from a list that includes all three in RFC 5661. o When eir_server_scope remains the same and eir_server_owner.so_major_id changes, the client can use the filehandles it has, consider its locking state lost, and attempt to reclaim or otherwise re-obtain its locks. It may find that its file handle IS now stale but if NFS4ERR_STALE is not received, it can proceed to reclaim or otherwise re-obtain its open locking state. nit(?): this bit about "It may find that its file handle IS now stale but if NFS4ERR_STALE is not received" seems to assume some familiarity by the reader as to what actions would be performed that would get NFS4ERR_STALE back. Section 2.10.5.1 When the server responds using two different connections claim matching or partially matching eir_server_owner, eir_server_scope, nit: The grammar got wonky here; maybe s/claim/claiming/? Section 11.1.1 In the case of NFS version 4.1 and later minor versions, the means of trunking detection are as described in this document and are available to every client. Two network addresses connected to the same server are always server-trunkable but cannot necessarily be used together to access a single session. nit: we haven't defined "server-trunkable" yet, so it may be worth a hint that the definition is coming soon. The combination of a server network address and a particular connection type to be used by a connection is referred to as a "server endpoint". Although using different connection types may result in different ports being used, the use of different ports by multiple connections to the same network address is not the essence of the distinction between the two endpoints used. There's perhaps a fine line to walk here, as the port can still have significant relevance, in general, and we are frequently in the IETF told to make no assumption about what is behind specific port values at a given network address. (Consider, for example, a hypothetical virtual hosting service that provides "DS-as-a-service" where customers run their own MDS that point to configured DSes for actual storage. Different ports on that cloud provider would represent entirely different customers/servers!) [This became a discuss point but it didn't end up including all the discussion here, so I left it as an informational thing; discussion should happen in the Discuss section] Section 11.1.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 "multi-server namespace". o A file system present in a server's pseudo-fs may have multiple file system instances on different servers associated with it. All such instances are considered replicas of one another. [Some readers might take this as requiring live read/write replication such that all writes to any instance are immediately visible on all other instances. The rest of the document ought to disabuse them of that notion, and yet...] o File system location entries provide the individual file system locations within the file system location attributes. Each such entry specifies a server, in the form of a host name or IP an address, and an fs name, which designates the location of the file nit: s/IP an/an IP/. client may establish connections. There may be multiple endpoints because a host name may map to multiple network addresses and because multiple connection types may be used to communicate with a single network address. However, all such endpoints MUST provide a way of connecting to a single server. The exact form of nit: "MUST provide" feels strange here, since it implies in some sense an extra layer of indirection ("A lists X, and X among other things provides Y"); would a different word like "indicate" work? element derives from a corresponding location entry. When a location entry specifies an IP address there is only a single corresponding location element. File system location entries that contain a host name are resolved using DNS, and may result in one or more location elements. All location elements consist of a location address which is the IP address of an interface to a server and an fs name which is the location of the file system within the server's local namespace. The fs name can be empty if I can't decide whether both instances of "IP address" are pedantically correct, in the presence of the potential for port information to be included/available. The former is probably okay, but the latter might need some clarification. Section 11.2 The fs_locations attribute defined in NFSv4.0 is also a part of NFSv4.1. This attribute only allows specification of the file system locations where the data corresponding to a given file system may be found. Servers should make this attribute available whenever fs_locations_info is supported, but client use of fs_locations_info is preferable, as it provides more information. I think this was probably okay as "SHOULD make this attribute available" (as it was in 5661), but don't object to the lowercase version either. Section 11.5 Where a file system had been absent, specification of file system I guess I'm probably in the rough on this one (since 5661 had my more-preferred language), but it still feels like "had been absent" implies that it is no longer absent, i.e., that it is now present or has otherwise changed. What's going on here with referrals is more like a "was never present" case, though using "never" is of course problematic as it's more absolute than is appropriate. If we're going to talk about "pure referral"s, do we want to make mention of or otherwise differentiate/characterize "non-pure" ("impure"?) referrals? Section 11.5.1 In order to simplify client handling and allow the best choice of replicas to access, the server should adhere to the following guidelines. Just to check: these are just informal "guidelines" and not something that a server SHOULD or even MUST adhere to? Section 11.5.2 Locations entries used to discover candidate addresses for use in nit(?): is this supposed to just be "Location" singular? Section 11.5.3 Irrespective of the particular attribute used, when there is no indication that a step-up operation can be performed, a client supporting RDMA operation can establish a new RDMA connection and it can be bound to the session already established by the TCP connection, allowing the TCP connection to be dropped and the session converted to further use in RDMA node. Should we say something to make this contingent on the server also supporting RDMA? Section 11.5.5 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 nit: the grammar here got wonky; maybe s/as a/is a/? Section ?? The old (RFC 5661) Section 11.5 mentioned several things, and I'd like to check that we have either covered or disavowed all of them. My current understanding is that: The first paragraph basically talked about trunking detection, and is covered elsewhere. The second paragraph talks about something that I would call "implicit replication" with the 5661 definition of "replica", but in the new model is essentially definitionally true, since we consider all addresses for the same server to be ... part of the same server, so of course that server's namespaces match up. Though perhaps the discussion about not all of the cartesian product of (addresses-for-server, local path) being listed is still worth having? The third paragraph basically talks about the need for trunking detection, and includes some guidance to clients about assuming server misconfiguration that seems of questionable merit. Section 11.5.7 o Deletions from the list of network addresses for the current file system instance need not be acted on immediately, although the client might need to be prepared for a shift in access whenever the server indicates that a network access path is not usable to access the current file system, by returning NFS4ERR_MOVED. I think this should be wordsmithed a bit more, as (IIUC) the idea here is that if a client notices in a location response that the address the client is currently using for a filesystem has disappeared from the list, the client should be prepared for imminent changes in server behavior relating to the presumed-move. Those imminent changes would most likely be reflected in the form of the server returning NFS4ERR_MOVED, but there is no NFS4ERR_MOVED involved in the actual deletion from the list of network instances of the current system instance. Section 11.6 corresponding attribute is interrogated subsequently. In the case of a multi-server namespace, that same promise applies even if server boundaries have been crossed. Similarly, when the owner attribute of a file is derived from the securiy principal which created the file, that attribute should have the same value even if the interrogation occurs on a different server from the file creation. I can see how the interrogation would be on a different server from file creation for "simple" replication scenarios, but I'm not sure I'm seeing how non-replication cases would arise, paritulcarly that cross server boundaries in a multi-server (hierarchical?) namespace. Am I missing something obvious? nit: s/securiy/security/ o All servers support a common set of domains which includes all of the domains clients use and expect to see returned as the domain portion of an owner or group in the form "id@domain". Note that although this set most ofen consists of a single domain, it is possible for mutiple domains to be supported. I a little bit wonder if the "most often" still holds when client principals come from an AD forest. o All servers recognize the same set of security principals, and each principal, the same credential are required, independent of the server being accessed. In addition, the group membership for nit: I think there's a missing word here, maybe "and for each principal"? Note that there is no requirment that the users corresponding to nit: "requirement" o The "local" representation of all owners and groups must be the same on all servers. The word "local" is used here since that is the way that numeric user and group ids are described in Section 5.9. However, when AUTH_SYS or stringified owners or group are used, these identifiers are not truly local, since they are known tothe clients as well as the server. I am trying to find a way to note that the AUTH_SYS case mentioned here is precisely because of the requirement being imposed by this bullet point, while acknowledging that the "stringified owners or group" case is separate, but not having much luck. Also, nit: "to the" Section 11.9 o When use of a particular address is to cease and there is also one currently in use which is server-trunkable with it, requests that would have been issued on the address whose use is to be discontinued can be issued on the remaining address(es). When an address is not a session-trunkable one, the request might need to be modified to reflect the fact that a different session will be used. I suggest writing this as "when an address is server-trunkable but not session-trunkable,". o When use of a particular connection is to cease, as indicated by receiving NFS4ERR_MOVED when using that connection but that address is still indicated as accessible according to the appropriate file system location entries, it is likely that requests can be issued on a new connection of a different connection type, once that connection is established. Since any two server endpoints that share a network address are inherently session-trunkable, the client can use BIND_CONN_TO_SESSION to access the existing session using the new connection and proceed to access the file system using the new connection. I'm not entirely sure how "inherent" this is (in the vein of my Discuss point, and what we mean by "network address"). o When there are no potential replacement addresses in use but there What is a "replacement address"? 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 is no longer accessible. In this case, the client can create a new session to enable continued access to the existing instance and provide for use of existing filehandles, stateids, and client ids while providing continuity of locking state. I'm not sure I understand this last sentence. On its own, the "new session to enable continued access to the existing instance" sounds like the continued access would be on the address whose use is to cease, and thus the new session would be there. But why make a new session when the old one is still good, especially when we just said in the previous sentence that the old session can't be moved to the new connection/address? Perhaps a forward reference down to Section 11.12.{4,5} for this and the next bullet point would help as well as rewording? Section 11.10.6 In a file system transition, the two file systems might be clustered in the handling of unstably written data. When this is the case, and What does "clustered in the handling of unstably written data" mean? the two file systems belong to the same write-verifier class, write How is the client supposed to determine "when this is the case"? Section 11.10.7 In a file system transition, the two file systems might be consistent in their handling of READDIR cookies and verifiers. When this is the case, and the two file systems belong to the same readdir class, As above, how is the client supposed to determine "when this is the case"? READDIR cookies and verifiers from one system may be recognized by the other and READDIR operations started on one server may be validly continued on the other, simply by presenting the cookie and verifier returned by a READDIR operation done on the first file system to the second. Are these "may be"s supposed to admit the possibility that the destination server can just decide to not honor them arbitrarily? Section 11.10.8 the degree indicated by the fs_locations_info attribute). However, when multiple file systems are presented as replicas of one another, the precise relationship between the data of one and the data of another is not, as a general matter, specified by the NFSv4.1 protocol. It is quite possible to present as replicas file systems where the data of those file systems is sufficiently different that some applications have problems dealing with the transition between replicas. The namespace will typically be constructed so that applications can choose an appropriate level of support, so that in one position in the namespace a varied set of replicas will be listed, while in another only those that are up-to-date may be considered replicas. [...] This seems quite wishy-washy for a standards-track protocol! We give no hard bounds on how "different" replicas may be, no protocol element to convey even a qualitative sense of where on the spectrum of replication fidelity a replica may lie, and no indication as to how the namespace might be constructed to indicate a level of support. The protocol does define three special cases of the relationship among replicas to be specified by the server and relied upon by clients: I'd like to hear from the rest of the IESG, but we may need to consider limiting "replication" to just these special cases until we can be more precise about the other cases. o When multiple replicas exist and are used simultaneously by a client (see the FSLIB4_CLSIMUL definition within fs_locations_info), they must designate the same data. Where file systems are writable, a change made on one instance must be visible on all instances, immediately upon the earlier of the return of the modifying requester or the visibility of that change on any of the associated replicas. This allows a client to use Hmm, how would this "earlier of [...]" work when there are three nominally equivalent machines? Assume the RPC is made to A, and the other two are B and C. If the update first goes visible on B, it must also be visible on C, instilling what is apparently a hard requirement for exact synchronization between B an C, perhaps by some sort of negotiated "make visible at timestamp X" mechanism. But if the RPC returns from A first, then the change still has to be visible on B and C at the same time. Does this phrasing give any weaker a requirement than "must be visible on all machines at the same time", in practice? (There are, of course, various distributed-consensus protocols that can do this, as could a scenario where all NFS servers are connected to a common file store backend.) Section 11.10.9 When access is transferred between replicas, clients need to be assured that the actions disallowed by holding these locks cannot To check my understanding: this "access is transferred" means *all* clients' access (not just one particular client)? Otherwise I'm not sure how the destination would know to enforce the grace period. Section 11.11.1 I think the last two paragraphs might be duplicating some things mentioned earlier in the section, but the repetition is probably not harmful. Section 11.12.1 Because of the absence of NFSV4ERR_LEASE_MOVED, it is possible for file systems whose access path has not changed to be successfully It might be worth phrasing this as "SEQ4_STATUS_LEASE_MOVED is not an error condition". Section 11.12.2 o No action needs to be taken for such indications received by the those performing migration discovery, since continuation of that work will address the issue. nit: "by the those" is not right, but the proper fix eludes me, as this bullet point needs to be more specific somehow than the next one. o If the fs_status attribute indicates that the file system is a migrated one (i.e. fss_absent is true and fss_type != STATUS4_REFERRAL) and thus that it is likely that the fetch of the file system location attribute has cleared one the file systems contributing to the lease-migrated indication. This looks like a sentence fragment -- it's of the form "If X, and thus Y." with no concluding clause. Section 11.12.4 Once the client has determined the initial migration status, and determined that there was a shift to a new server, it needs to re- establish its locking state, if possible. To enable this to happen without loss of the guarantees normally provided by locking, the destination server needs to implement a per-fs grace period in all cases in which lock state was lost, including those in which Transparent State Migration was not implemented. Similarly to above, does this imply that the migration has to happen for all clients concurrently, as opposed to clients getting migrated in sequence? Section 11.3.1 In this case, destination server need have no knowledge of the locks nit: singular/plural mismatch "destination server"/"need" Section 11.13.3 o Not responding with NFS4ERR_SEQ_MISORDERED for the initial request on a slot within a transferred session, since the destination Does this then translate to "process as usual in the absence of migration"? "Don't return error X" tells me what not to do, but doesn't really tell me what to do instead. Section 11.16.1 With the exception of the transport-flag field (at offset FSLI4BX_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. Is it clear that this applies only to the fields defined by this specification (since, as mentioned later, future extensions must specify whether they apply to the replica or the entry)? Section 15.1.1.3 o When NFS4ERR_DELAY is returned on an operation other than the first within a request and there has been a non-idempotent operation processed before the NFS4ERR_DELAY was returned, the reissued request should avoid the non-idempotent operation. The request still must use a SEQUENCE operation with either a different slot id or sequence value from the SEQUENCE in the original request. Because this is done, there is no way the replier could avoid spuriously re-executing the non-idempotent operation since the different SEQUENCE parameters prevent the requester from recognizing that the non-idempotent operation is being retried. I don't think that this is very clear about the counterfactual scenario in which the replier is trying to avoid spuriously re-executing the non-idempotent operation. Is it supposed to be explaining why the client has to use a different slot or sequence value, because the replier would reexecute the non-idempotent operation otherwise? Section 18.35.3 I a little bit wonder if we want to reaffirm that co_verifier remains fixed when the client is establishing multiple connections for trunking usage -- the "incarnation of the client" language here could make a reader wonder, though I think the discussion of its use elsewhere as relating to "client restart" is sufficiently clear. The eia_clientowner field is composed of a co_verifier field and a co_ownerid string. As noted in s Section 2.4, the co_ownerid s/s // Section 18.51.4 o When a server might become the destination for a file system being migrated, inappropriate use of per-fs RECLAIM_COMPLETE is more concerning. In the case in which the file system designated is not within a per-fs grace period, the per-fs RECLAIM_COMPLETE SHOULD be ignored, with the negative consequences of accepting it being limited, as in the case in which migration is not supported. However, if the server encounters a file system undergoing migration, the operation cannot be accepted as if it were a global RECLAIM_COMPLETE without invalidating its intended use. This seems to be the only place where we acknowledge that the "misuse" in question was to "treat rca_one_fs of TRUE as if it was FALSE", which is probably not so great for clarity. Section 21 Some other topics at least somewhat related to trunking and migration that we could potentially justify including in the current, limited-scope, update (as opposed to deferring for a full -bis) include: - clients that lie about reclaimed locks during a post-migration grace period - how attacker capabilities compare by using a compromised server to give bogus referrals/etc. as opposed to just giving bogus data/etc. - an attacker in the network trying to shift client traffic (in terms of what endpoints/connections they use) to overload a server - how asynchronous replication can cause clients to repeat non-idempotent actions - the potential for state skew and/or data loss if migration events happen in close succession and the client "misses a notification" - cases where a filesystem moves and there's no longer anything running at the old network endpoint to return NFS4ERR_MOVED - what can happen when non-idempotent requests are in a COMPOUND before a request that gets NFS4ERR_MOVED - how bad it is if the client messes up at Transparent State Migration discovery, most notably in the case when some lock state is lost - the interactions between cached replies and migration(-like) events, though a lot of this is discussed in section 11.13.X and 15.1.1.3 already but I defer to the WG as to what to cover now vs. later. In light of the ongoing work on draft-ietf-nfsv4-rpc-tls, it might be reasonable to just talk about "integrity protection" as an abstract thing without the specific focus on RPCSEC_GSS's integrity protection (or authentication) being returned. These include cases in which the client is directed a server under the control of an attacker, who might get nit: "directed to" o Despite the fact that it is a requirement that "implementations" provide "support" for use of RPCSEC_GSS, it cannot be assumed that use of RPCSEC_GSS is always available between any particular client-server pair. side note: scare-quotes around "support" makes sense to me, but not around "implementations". the destination. Even when RPCSEC_GSS authentication is available on the destination, the server might validly represent itself as the server to which the client was erroneously directed. Without a way Something about the wording here tickles me funny; at first I thought it was the "validly", but now I think it's "represent itself", perhaps because that phrasing can have connotations of "falsely represent". ("Valid" is fine -- the attack here is the misdirection, and the target of the misdirection doesn't have to misbehave at all for it to be a damaging attack.) The best remedy I can come up with is a somewhat drastic change, and thus questionable: "Even when [...], the server might still properly authenticate as the server to which the client was erroneously directed." I'd also consider adding a third bullet point to the final list ("to summarize considerations regarding the use of RPCSEC_GSS"): % o The integrity protection afforded to results by RPCSEC_GSS protects % only a given request/response transaction; RPCSEC_GSS does not % protect the binding from one server to another as part of a referral % or migration event. The source server must be trusted to provide % the correct information, based on whatever factors are available to % the client. Section 22.1 Thank you for thinking about how the IANA considerations should be presented in the post-update document. (I think I've had to place at least two Discuss positions on bis documents that did not...) Section 23.2 I'm not sure that all of the moves from Normative to Informative should stick; e.g., HMAC (which went from [11] to [59]) is needed for SSV calculation. Hmm, actually, maybe that's the only one. Appendix B I have mixed feelings about whether to keep this content for the final RFC. (Appendix A seems clearly useful; the specific details of the reorganization are less clear, as to some extent they can be deduced from the changes themselves. But only to some extent...) Appendix B.1.2 o The new Sections 11.8 and 11.9 have resulted in existing sections wit these numbers to be renumbered. s/wit/with/ Section B.2.1 The new treatment can be found in Section 18.35 below. It is s/below/above/ intended to supersede the treatment in Section 18.35 of RFC5661 [62]. Publishing a complete replacement for Section 18.35 allows the corrected definition to be read as a whole, in place of the one in RFC5661 [62]. This seems like it was more appropriate in the scope of draft-ietf-nfsv4-mv1-msns-update but could be obsolete here. Section B.4 o The discussion of trunking which appeared in Section 2.10.5 of RFC5661 [62] needed to be revised, to more clearly explain the multiple types of trunking supporting and how the client can be made aware of the existing trunking configuration. In addition the last paragraph (exclusive of sub-sections) of that section, dealing with server_owner changes, is literally true, it has been a source of confusion. [...] nit: the grammar here is weird; I think there's a missing "while" or similar. |
2019-12-18
|
03 | Benjamin Kaduk | [Ballot Position Update] New position, Discuss, has been recorded for Benjamin Kaduk |
2019-12-17
|
03 | Roman Danyliw | [Ballot comment] I conducted this review in the spirit of draft-roach-bis-documents-00 and the significant security caveats enumerated in Appendix C. A big thanks to Sean … [Ballot comment] I conducted this review in the spirit of draft-roach-bis-documents-00 and the significant security caveats enumerated in Appendix C. A big thanks to Sean Turner for his SECDIR reviews and the authors for incorporating this feedback where appropriate. ** Section 1.1. The motivation for the editorial approach taken in this document is cited as being in [I.D-roach-bis-documents] but there is not such reference in the document. ** The SECDIR review asked about retaining id-sha1 in Section 14.3. The WG was going to be consulted. What was the resolution? In the spirit of this focused review, keeping it REQUIRED doesn’t present an issue, IMO. However, would there be a reduced set of algorithms that could be RECOMMENDED in the Security Considerations? ** Section 21, Per “When DNS is used to convert server names to addresses and DNSSEC [29] is not available, the validity of the network addresses returned cannot be relied upon.”, this concern about the fidelity of the DNS information is a helpful consideration. It would be worth mentioning/recommending the use of other DNS technologies such as DNS over TLS [RFC7858] and DNS over HTTPS [RFC8484] that could provide additional/alternatives confidence mechanisms in the DNS data. |
2019-12-17
|
03 | Roman Danyliw | [Ballot Position Update] New position, No Objection, has been recorded for Roman Danyliw |
2019-12-17
|
03 | Vijay Gurbani | Request for Last Call review by GENART Completed: Ready with Nits. Reviewer: Vijay Gurbani. Sent review to list. |
2019-12-17
|
03 | Mirja Kühlewind | [Ballot Position Update] New position, No Objection, has been recorded for Mirja Kühlewind |
2019-12-17
|
03 | Magnus Westerlund | [Ballot comment] Reminder that this is a limited scope update to address a specific set of short comings, so think through if your discuss is … [Ballot comment] Reminder that this is a limited scope update to address a specific set of short comings, so think through if your discuss is on the changes or not. This document will not address errata on issues outside of the scope of the update. Those errata will be duplicated to also apply to this document when it has been published as RFC. I have already communicated with the RFC-editor and they can easily do this. An rfcdiff for just the changes: https://tools.ietf.org/rfcdiff?url1=https://www.rfc-editor.org/rfc/rfc5661.txt&url2=https://www.ietf.org/id/draft-ietf-nfsv4-rfc5661sesqui-msns-03.txt |
2019-12-17
|
03 | Magnus Westerlund | Ballot comment text updated for Magnus Westerlund |
2019-12-16
|
03 | Alexey Melnikov | [Ballot comment] Thank you for this well written document. I have a few nits to report: The new section 1.1 should be spellchecked. (I given … [Ballot comment] Thank you for this well written document. I have a few nits to report: The new section 1.1 should be spellchecked. (I given up reporting them.) In 14.1.1: o If NFS4ERR_DELAY is returned on an operation other than SEQUENCE which validly appears as the first operation of a request, handling is similar. The request can be retired in full without s/retired/retried ? modification. In 21: The use of the multi-server bamespace features described in s/bamespace/namespace Section 11 raises the possibility that requests to determine the set of network addresses corresponding to a given server might be interfered with or have their responses modified in flight. In light of this possibility, the following considerations should be taken note of: |
2019-12-16
|
03 | Alexey Melnikov | [Ballot Position Update] New position, No Objection, has been recorded for Alexey Melnikov |
2019-12-15
|
03 | Suresh Krishnan | [Ballot Position Update] New position, No Objection, has been recorded for Suresh Krishnan |
2019-12-12
|
03 | Deborah Brungard | [Ballot Position Update] New position, No Objection, has been recorded for Deborah Brungard |
2019-12-09
|
03 | Sean Turner | Request for Last Call review by SECDIR Completed: Ready. Reviewer: Sean Turner. Sent review to list. |
2019-12-04
|
03 | Amy Vezza | Placed on agenda for telechat - 2019-12-19 |
2019-12-04
|
03 | Magnus Westerlund | [Ballot comment] Reminder that this is a limited scope update to address a specific set of short comings, so think through if your discuss is … [Ballot comment] Reminder that this is a limited scope update to address a specific set of short comings, so think through if your discuss is on the changes or not. An rfcdiff for just the changes: https://tools.ietf.org/rfcdiff?url1=https://www.rfc-editor.org/rfc/rfc5661.txt&url2=https://www.ietf.org/id/draft-ietf-nfsv4-rfc5661sesqui-msns-03.txt |
2019-12-04
|
03 | Magnus Westerlund | Ballot comment text updated for Magnus Westerlund |
2019-12-04
|
03 | Magnus Westerlund | IESG state changed to IESG Evaluation from Waiting for AD Go-Ahead |
2019-12-04
|
03 | Magnus Westerlund | Ballot has been issued |
2019-12-04
|
03 | Magnus Westerlund | [Ballot Position Update] New position, Yes, has been recorded for Magnus Westerlund |
2019-12-04
|
03 | Magnus Westerlund | Created "Approve" ballot |
2019-11-25
|
03 | (System) | IANA Review state changed to IANA OK - Actions Needed from IANA - Review Needed |
2019-11-25
|
03 | Amanda Baber | (Via drafts-lastcall@iana.org): IESG/Authors/WG Chairs: The IANA Functions Operator has completed its review of draft-ietf-nfsv4-rfc5661sesqui-msns-03. If any part of this review is inaccurate, please let … (Via drafts-lastcall@iana.org): IESG/Authors/WG Chairs: The IANA Functions Operator has completed its review of draft-ietf-nfsv4-rfc5661sesqui-msns-03. If any part of this review is inaccurate, please let us know. The IANA Functions Operator understands that upon approval of this document, there are eight registries that need to be updated. We have questions about completing these actions. The following seven registries are to have their references and any references in the registrations they contain updated from RFC 5661 to [ RFC-to-be ]: NFSv4 ${ietf.org:CPU_ARCH} Value Registry https://www.iana.org/assignments/nfsv4-path-variables NFSv4 ${ietf.org:OS_TYPE} Value Registry https://www.iana.org/assignments/nfsv4-path-variables NFSv4 Device ID Notifications Registry https://www.iana.org/assignments/nfsv4-device-id-notifications NFSv4 Named Attribute Definitions Registry https://www.iana.org/assignments/nfsv4-named-attributes NFSv4 Path Variables Registry https://www.iana.org/assignments/nfsv4-path-variables NFSv4 Recallable Object Types Registry https://www.iana.org/assignments/nfsv4-recallable-object-types pNFS Layout Types Registry https://www.iana.org/assignments/pnfs-layout-types In addition, although it doesn't appear to be listed in the document, we understand that in the GSSAPI/Kerberos/SASL Service Names registry at https://www.iana.org/assignments/gssapi-service-names, the following registration should have its reference to RFC 5661 updated: nfs distributed file system protocol [RFC2623][RFC7530][RFC5661] If this is incorrect, please let us know. We also have the following questions: 1) The tables of initial registries do not include registrations made after RFC 5661 was published. Can you confirm that those post-RFC 5661 registrations should remain in the registry? 2) For the NFSv4 ${ietf.org:CPU_ARCH} Value Registry and NFSv4 ${ietf.org:OS_TYPE} Value Registry, given the instructions in 22.5.1.1 and 22.6.1.1, would it be appropriate for IANA to change the name of the column "RFC" to "RFC/Explanation" or "RFC/Explanation/Reference"? 3) Would it be acceptable for IANA to remove the word "Registry" from the names of these registries? (In that case, "NFSv4 ${ietf.org:CPU_ARCH} Value Registry" and "NFSv4 ${ietf.org:OS_TYPE} Value Registry" would be changed to "NFSv4 ${ietf.org:OS_TYPE} Values" and "NFSv4 ${ietf.org:OS_TYPE} Values." No other changes would be required.) Note: The actions requested in this document will not be completed until the document has been approved for publication as an RFC. This message is meant only to confirm the list of actions that will be performed. Thank you, Amanda Baber Lead IANA Services Specialist |
2019-11-25
|
03 | (System) | IESG state changed to Waiting for AD Go-Ahead from In Last Call |
2019-11-14
|
03 | Gunter Van de Velde | Request for Last Call review by OPSDIR is assigned to Tim Wicinski |
2019-11-14
|
03 | Gunter Van de Velde | Request for Last Call review by OPSDIR is assigned to Tim Wicinski |
2019-11-08
|
03 | Jean Mahoney | Request for Last Call review by GENART is assigned to Vijay Gurbani |
2019-11-08
|
03 | Jean Mahoney | Request for Last Call review by GENART is assigned to Vijay Gurbani |
2019-11-07
|
03 | Tero Kivinen | Request for Last Call review by SECDIR is assigned to Sean Turner |
2019-11-07
|
03 | Tero Kivinen | Request for Last Call review by SECDIR is assigned to Sean Turner |
2019-11-04
|
03 | Amy Vezza | IANA Review state changed to IANA - Review Needed |
2019-11-04
|
03 | Amy Vezza | The following Last Call announcement was sent out (ends 2019-11-25): From: The IESG To: IETF-Announce CC: draft-ietf-nfsv4-rfc5661sesqui-msns@ietf.org, magnus.westerlund@ericsson.com, nfsv4-chairs@ietf.org, nfsv4@ietf.org Reply-To: last-call@ietf.org … The following Last Call announcement was sent out (ends 2019-11-25): From: The IESG To: IETF-Announce CC: draft-ietf-nfsv4-rfc5661sesqui-msns@ietf.org, magnus.westerlund@ericsson.com, nfsv4-chairs@ietf.org, nfsv4@ietf.org Reply-To: last-call@ietf.org Sender: Subject: Last Call: (Network File System (NFS) Version 4 Minor Version 1 Protocol) to Proposed Standard The IESG has received a request from the Network File System Version 4 WG (nfsv4) to consider the following document: - 'Network File System (NFS) Version 4 Minor Version 1 Protocol' 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 last-call@ietf.org mailing lists by 2019-11-25. 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 describes the Network File System (NFS) version 4 minor version 1, including features retained from the base protocol (NFS version 4 minor version 0, which is specified in RFC 7530) and protocol extensions made subsequently. The later minor version has no dependencies on NFS version 4 minor version 0, and is considered a separate protocol. This document obsoletes RFC5661. It substantialy revises the treatment of features relating to multi-server namesapce superseding the description of those features appearing in RFC5661. The file can be obtained via https://datatracker.ietf.org/doc/draft-ietf-nfsv4-rfc5661sesqui-msns/ IESG discussion can be tracked via https://datatracker.ietf.org/doc/draft-ietf-nfsv4-rfc5661sesqui-msns/ballot/ This document is a narrowly scoped update to address the multi-name space functionalities. The document does not address some known issues regarding e.g. security and internationalization that would be expected when we in IETF normally updates a specification fully. The IESG rejected the form of the update originally had, and requested the update to be in the form of a full specification. Some of the motivation and reasoning behind this form of focused replacement document is captured in https://datatracker.ietf.org/doc/draft-roach-bis-documents/ The documents introduction and an appendix discusses the scope of the update to the protocol and what has not been addressed. Reviewers may be helped by this RFC diff showing changes compared to RFC 5661: https://tools.ietf.org/rfcdiff?url1=https://www.rfc-editor.org/rfc/rfc5661.txt&url2=https://www.ietf.org/id/draft-ietf-nfsv4-rfc5661sesqui-msns-03.txt No IPR declarations have been submitted directly on this I-D. However, there exists an IPR declaration on RFC 5661: https://datatracker.ietf.org/ipr/1361/ |
2019-11-04
|
03 | Amy Vezza | IESG state changed to In Last Call from Last Call Requested |
2019-11-04
|
03 | Magnus Westerlund | Last call was requested |
2019-11-04
|
03 | Magnus Westerlund | Ballot approval text was generated |
2019-11-04
|
03 | Magnus Westerlund | IESG state changed to Last Call Requested from AD Evaluation |
2019-11-04
|
03 | Magnus Westerlund | Last call announcement was changed |
2019-10-24
|
03 | Magnus Westerlund | Ballot writeup was changed |
2019-10-24
|
03 | Magnus Westerlund | Ballot writeup was generated |
2019-10-24
|
03 | Magnus Westerlund | Note field has been cleared |
2019-10-22
|
03 | Magnus Westerlund | Last call announcement was changed |
2019-10-22
|
03 | Magnus Westerlund | IESG state changed to AD Evaluation from Publication Requested |
2019-10-22
|
03 | Magnus Westerlund | Note added 'This document is scoped update of RFC 5661 (NFS v. 4.1). It does not address all of the known issues as discussed in … Note added 'This document is scoped update of RFC 5661 (NFS v. 4.1). It does not address all of the known issues as discussed in introduction and an appendix. This is a trial attempt to run a process like the one discussed in https://datatracker.ietf.org/doc/draft-roach-bis-documents/. Therefore it is requested that review comments etc are limited to things related to the parts actually updated in this document. These sections are noted in the introduction and an RFC-diff against RFC5661 makes the changes evident. https://tools.ietf.org/rfcdiff?url1=https://www.rfc-editor.org/rfc/rfc5661.txt&url2=https://www.ietf.org/id/draft-ietf-nfsv4-rfc5661sesqui-msns-03.txt' |
2019-10-22
|
03 | Magnus Westerlund | IESG process started in state Publication Requested |
2019-10-22
|
03 | (System) | Earlier history may be found in the Comment Log for /doc/draft-ietf-nfsv4-rfc5661-msns-update/ |
2019-10-22
|
03 | Magnus Westerlund | Working group state set to Submitted to IESG for Publication |
2019-10-22
|
03 | Magnus Westerlund | Intended Status changed to Proposed Standard from None |
2019-10-22
|
03 | Magnus Westerlund | Changed consensus to Yes from Unknown |
2019-10-22
|
03 | Magnus Westerlund | IETF WG state changed to Submitted to IESG for Publication from In WG Last Call |
2019-10-22
|
03 | Magnus Westerlund | Working Group: NFSv4 Area Director: Magnus Westerlund Document Shepherd: Magnus Westerlund Internet Draft: Network File System (NFS) Version 4 Minor Version 1 Protocol draft-ietf-nfsv4-rfc5661sesqui-msns-03 (1) … Working Group: NFSv4 Area Director: Magnus Westerlund Document Shepherd: Magnus Westerlund Internet Draft: Network File System (NFS) Version 4 Minor Version 1 Protocol draft-ietf-nfsv4-rfc5661sesqui-msns-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 replaces RFC 5661. (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 is an update to NFS version 4.1 that 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 replaces RFC5661, the current version of NFS 4.1. This document is focused update to addresses the above specific issues. It is not a full update that addresses all known issues with NFS 4.1. Working Group Summary The working group was well aligned on the work that is the core of the update and it moved through the review process with good input ' but nothing contentious. The format of the original update (draft-ietf-nfsv4-mv1-msns-update-04) was rejected by IESG. The issues raised by the IESG resulted in this updated full document that doesn't address all known issues to avoid the additional delay resolving those issues would result in. 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 ability to draft quality, useful text. As the update is focused on a specific scope and the document is long, reviewers likely need to focus on the updated parts, for example as shown by rfcdiff: https://tools.ietf.org/rfcdiff?url1=https://www.rfc-editor.org/rfc/rfc5661.txt&url2=https://www.ietf.org/id/draft-ietf-nfsv4-rfc5661sesqui-msns-03.txt Personnel Magnus Westerlund & Spencer Shepler is the document shepherd. Magnus Westerlund 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. Spencer Shepler have read and reviewed the document as part of the working group last call and have been supportive of the work from first suggestion. Magnus Westerlund have reviewed the resulting changes from the format change of the update. (4) Does the document Shepherd have any concerns about the depth or breadth of the reviews that have been performed? As shepherds, we 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. There are known shortcommings in the areas that would require special review, namely security and internationalization. (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. There are no new IPR declarations on this document. However, there are one IPR declaration on RFC 5661: https://datatracker.ietf.org/ipr/1361/ (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.) 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. ID nits warns about: == There are 3 instances of lines with non-RFC2606-compliant FQDNs in the document. == There are 8 instances of lines with non-RFC6890-compliant IPv4 addresses in the document. If these are example addresses, they should be changed. These are no relevant. There is one reference to RFC 3491 which is obsoleted by RFC 5891. However as there has been no changes related to that reference that is outside of the scope of this update and therefore not addressed. (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? No. (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. Yes, it will obsolete 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-10-22
|
03 | Magnus Westerlund | Working Group: NFSv4 Area Director: Magnus Westerlund Document Shepherd: Magnus Westerlund Internet Draft: Network File System (NFS) Version 4 Minor Version 1 Protocol draft-ietf-nfsv4-rfc5661sesqui-msns-03 (1) … Working Group: NFSv4 Area Director: Magnus Westerlund Document Shepherd: Magnus Westerlund Internet Draft: Network File System (NFS) Version 4 Minor Version 1 Protocol draft-ietf-nfsv4-rfc5661sesqui-msns-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 replaces RFC 5661. (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 is an update to NFS version 4.1 that 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 replaces RFC5661, the current version of NFS 4.1. This document is focused update to addresses the above specific issues. It is not a full update that addresses all known issues with NFS 4.1. Working Group Summary The working group was well aligned on the work that is the core of the update and it moved through the review process with good input ' but nothing contentious. The format of the original update (draft-ietf-nfsv4-mv1-msns-update-04) was rejected by IESG. The issues raised by the IESG resulted in this updated full document that doesn't address all known issues to avoid the additional delay resolving those issues would result in. 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 Magnus Westerlund & Spencer Shepler is the document shepherd. Magnus Westerlund 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. Spencer Shepler have read and reviewed the document as part of the working group last call and have been supportive of the work from first suggestion. Magnus Westerlund have reviewed the resulting changes from the format change of the update. (4) Does the document Shepherd have any concerns about the depth or breadth of the reviews that have been performed? As shepherds, we 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. There are known shortcommings in the areas that would require special review, namely security and internationalization. (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. There are no new IPR declarations on this document. However, there are one IPR declaration on RFC 5661: https://datatracker.ietf.org/ipr/1361/ (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.) 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. ID nits warns about: == There are 3 instances of lines with non-RFC2606-compliant FQDNs in the document. == There are 8 instances of lines with non-RFC6890-compliant IPv4 addresses in the document. If these are example addresses, they should be changed. These are no relevant. There is one reference to RFC 3491 which is obsoleted by RFC 5891. However as there has been no changes related to that reference that is outside of the scope of this update and therefore not addressed. (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? No. (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. Yes, it will obsolete 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-10-22
|
03 | Magnus Westerlund | Notification list changed to Magnus Westerlund <magnus.westerlund@ericsson.com> |
2019-10-22
|
03 | Magnus Westerlund | Document shepherd changed to Magnus Westerlund |
2019-10-22
|
03 | Magnus Westerlund | Working Group: NFSv4 Area Director: Magnus Westerlund Document Shepherd: Magnus Westerlund Internet Draft: Network File System (NFS) Version 4 Minor Version 1 Protocol draft-ietf-nfsv4-rfc5661sesqui-msns-03 (1) … Working Group: NFSv4 Area Director: Magnus Westerlund Document Shepherd: Magnus Westerlund Internet Draft: Network File System (NFS) Version 4 Minor Version 1 Protocol draft-ietf-nfsv4-rfc5661sesqui-msns-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 replaces RFC 5661. (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 is an update to NFS version 4.1 that 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 replaces RFC5661, the current version of NFS 4.1. This document is focused update to addresses the above specific issues. It is not a full update that addresses all known issues with NFS 4.1. Working Group Summary The working group was well aligned on the work that is the core of the update and it moved through the review process with good input ' but nothing contentious. The format of the original update (draft-ietf-nfsv4-mv1-msns-update-04) was rejected by IESG. The issues raised by the IESG resulted in this updated full document that doesn't address all known issues to avoid the additional delay resolving those issues would result in. 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 Magnus Westerlund & Spencer Shepler is the document shepherd. Magnus Westerlund 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. Spencer Shepler have read and reviewed the document as part of the working group last call and have been supportive of the work from first suggestion. Magnus Westerlund have reviewed the resulting changes from the format change of the update. (4) Does the document Shepherd have any concerns about the depth or breadth of the reviews that have been performed? As shepherds, we 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. There are known shortcommings in the areas that would require special review, namely security and internationalization. (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. There are no new IPR declarations on this document. However, there are one IPR declaration on RFC 5661: https://datatracker.ietf.org/ipr/1361/ (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.) 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. (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? No. (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. Yes, it will obsolete 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-10-20
|
03 | David Noveck | New version available: draft-ietf-nfsv4-rfc5661sesqui-msns-03.txt |
2019-10-20
|
03 | (System) | New version approved |
2019-10-20
|
03 | (System) | Request for posting confirmation emailed to previous authors: David Noveck , Chuck Lever |
2019-10-20
|
03 | David Noveck | Uploaded new revision |
2019-10-04
|
02 | Magnus Westerlund | Shepherding AD changed to Magnus Westerlund |
2019-10-03
|
02 | David Noveck | New version available: draft-ietf-nfsv4-rfc5661sesqui-msns-02.txt |
2019-10-03
|
02 | (System) | New version approved |
2019-10-03
|
02 | (System) | Request for posting confirmation emailed to previous authors: David Noveck , Chuck Lever |
2019-10-03
|
02 | David Noveck | Uploaded new revision |
2019-09-14
|
01 | Spencer Shepler | In last call and will end on Sept 23rd with updates coming based on applicable errata. May extend last call to consider the errata updates … In last call and will end on Sept 23rd with updates coming based on applicable errata. May extend last call to consider the errata updates (if any). |
2019-09-14
|
01 | Spencer Shepler | IETF WG state changed to In WG Last Call from WG Document |
2019-08-04
|
01 | David Noveck | New version available: draft-ietf-nfsv4-rfc5661sesqui-msns-01.txt |
2019-08-04
|
01 | (System) | New version approved |
2019-08-04
|
01 | (System) | Request for posting confirmation emailed to previous authors: David Noveck , Chuck Lever |
2019-08-04
|
01 | David Noveck | Uploaded new revision |
2019-06-25
|
00 | Spencer Shepler | This document now replaces draft-ietf-nfsv4-rfc5661-msns-update instead of None |
2019-06-25
|
00 | David Noveck | New version available: draft-ietf-nfsv4-rfc5661sesqui-msns-00.txt |
2019-06-25
|
00 | (System) | WG -00 approved |
2019-06-25
|
00 | David Noveck | Set submitter to "David Noveck ", replaces to draft-ietf-nfsv4-rfc5661-msns-update and sent approval email to group chairs: nfsv4-chairs@ietf.org |
2019-06-25
|
00 | David Noveck | Uploaded new revision |