Requirements for Parallel NFS (pNFS) Layout Types
draft-ietf-nfsv4-layout-types-13
Revision differences
Document history
Date | Rev. | By | Action |
---|---|---|---|
2018-08-16
|
13 | (System) | RFC Editor state changed to AUTH48-DONE from AUTH48 |
2018-08-07
|
13 | (System) | RFC Editor state changed to AUTH48 from RFC-EDITOR |
2018-08-02
|
13 | (System) | RFC Editor state changed to RFC-EDITOR from EDIT |
2018-05-09
|
13 | (System) | IANA Action state changed to No IC from In Progress |
2018-05-08
|
13 | (System) | RFC Editor state changed to EDIT |
2018-05-08
|
13 | (System) | IESG state changed to RFC Ed Queue from Approved-announcement sent |
2018-05-08
|
13 | (System) | Announcement was received by RFC Editor |
2018-05-08
|
13 | (System) | IANA Action state changed to In Progress |
2018-05-08
|
13 | Cindy Morgan | IESG state changed to Approved-announcement sent from IESG Evaluation::AD Followup |
2018-05-08
|
13 | Cindy Morgan | IESG has approved the document |
2018-05-08
|
13 | Cindy Morgan | Closed "Approve" ballot |
2018-05-08
|
13 | Cindy Morgan | Ballot approval text was generated |
2018-05-08
|
13 | Cindy Morgan | Ballot writeup was changed |
2018-05-08
|
13 | Spencer Dawkins | Ballot approval text was generated |
2018-05-07
|
13 | Gunter Van de Velde | Closed request for Telechat review by OPSDIR with state 'Team Will not Review Version' |
2018-04-26
|
13 | Tero Kivinen | Closed request for Last Call review by SECDIR with state 'No Response' |
2018-04-25
|
13 | Thomas Haynes | New version available: draft-ietf-nfsv4-layout-types-13.txt |
2018-04-25
|
13 | (System) | New version approved |
2018-04-25
|
13 | (System) | Request for posting confirmation emailed to previous authors: Thomas Haynes |
2018-04-25
|
13 | Thomas Haynes | Uploaded new revision |
2018-04-19
|
12 | Thomas Haynes | New version available: draft-ietf-nfsv4-layout-types-12.txt |
2018-04-19
|
12 | (System) | New version approved |
2018-04-19
|
12 | (System) | Request for posting confirmation emailed to previous authors: Thomas Haynes |
2018-04-19
|
12 | Thomas Haynes | Uploaded new revision |
2018-04-19
|
11 | (System) | Sub state has been changed to AD Followup from Revised ID Needed |
2018-04-19
|
11 | (System) | IANA Review state changed to Version Changed - Review Needed from IANA OK - No Actions Needed |
2018-04-19
|
11 | Thomas Haynes | New version available: draft-ietf-nfsv4-layout-types-11.txt |
2018-04-19
|
11 | (System) | New version approved |
2018-04-19
|
11 | (System) | Request for posting confirmation emailed to previous authors: Thomas Haynes |
2018-04-19
|
11 | Thomas Haynes | Uploaded new revision |
2018-04-19
|
10 | Cindy Morgan | IESG state changed to IESG Evaluation::Revised I-D Needed from IESG Evaluation |
2018-04-19
|
10 | Benjamin Kaduk | [Ballot comment] Thanks for addressing my discuss/comments; changing to Yes as promised. (Original ballot text preserved below for posterity.) DISCUSS Thanks for writing this up; … [Ballot comment] Thanks for addressing my discuss/comments; changing to Yes as promised. (Original ballot text preserved below for posterity.) DISCUSS Thanks for writing this up; it's good to have better clarity about the requirements placed on various actors in pNFS. I will change to Yes once this issue is resolved: Section 4 leaves me confused about what exactly from RFC 5661 is being updated. That is, the subsections look to be some discussion about how the "real requirements" (i.e., this document) apply to the given layout types, and we are told that these sections do not update the specification for those specific layout types. So it's hard to get a clear picture about which specific requirements are being changed/added; this leads me to wonder if the top-level Section 4 should not say "This section updates Section 12 of [RFC5661]" and leave the "discussed here only to illuminate the updates made to Section 12 of [RFC5661]". COMMENT Section 1 Such matters are defined in a standards-track layout type specification. This could be read as saying that there is a single document, which happens to be a layout-type specification and standards-track, that gives guidance on how layout types differ. Maybe: Each layout type will define the needed details for its usage in the specifciation for that layout type; layout type specifications are always standards-track RFCs. Section 3.3 [..] If the document does not impose implementation requirements sufficient to ensure that these semantic requirements are met, it is not appropriate for the working group to allow the document to move forward. Maybe "it is not appropriate for publication as an IETF-stream RFC"? o If the metadata server does not have a means to invalidate a stateid issued to the storage device to keep a particular client from accessing a specific file, then the layout type specification has to document how the metadata server is going to fence the client from access to the file on that storage device. Is the stateid issued to the storage device or to the client? Section 4 leaves me confused about what exactly from RFC 5661 is being updated. That is, the subsections look to be some discussion about how the "real requirements" (i.e., this document) apply to the given layout types, we are told that these sections do not update the specification for those specific layout types. So it's hard to get a clear picture about which specific things are being updated; this leads me to wonder if the top-level Section 4 should not say "This section updates Section 12 of [RFC5661]" and leave the "discussed here only to illuminate the updates made to Section 12 of [RFC5661[". Section 6 [...] In the latter case, I/O access writes are reflected in layouts [...] s/writes/rights/ |
2018-04-19
|
10 | Benjamin Kaduk | [Ballot Position Update] Position for Benjamin Kaduk has been changed to Yes from Discuss |
2018-04-19
|
10 | Ignas Bagdonas | [Ballot Position Update] New position, No Objection, has been recorded for Ignas Bagdonas |
2018-04-18
|
10 | Suresh Krishnan | [Ballot Position Update] New position, No Objection, has been recorded for Suresh Krishnan |
2018-04-18
|
10 | Adam Roach | [Ballot comment] Thanks to all involved for the work they did on this document. I had the same confusion as Benjamin, and support his discuss. … [Ballot comment] Thanks to all involved for the work they did on this document. I had the same confusion as Benjamin, and support his discuss. I also found one very small grammar nit in §2: > (file) data: is that part of the file system object which contains > the data to read or written. Change to either "...to read or write." or "...to be read or written." |
2018-04-18
|
10 | Adam Roach | [Ballot Position Update] New position, No Objection, has been recorded for Adam Roach |
2018-04-18
|
10 | Deborah Brungard | [Ballot Position Update] New position, No Objection, has been recorded for Deborah Brungard |
2018-04-18
|
10 | Martin Vigoureux | [Ballot Position Update] New position, No Objection, has been recorded for Martin Vigoureux |
2018-04-18
|
10 | Terry Manderson | [Ballot Position Update] New position, No Objection, has been recorded for Terry Manderson |
2018-04-17
|
10 | Alvaro Retana | [Ballot Position Update] New position, No Objection, has been recorded for Alvaro Retana |
2018-04-17
|
10 | Amanda Baber | IANA Review state changed to IANA OK - No Actions Needed from Version Changed - Review Needed |
2018-04-17
|
10 | Benjamin Kaduk | [Ballot discuss] Thanks for writing this up; it's good to have better clarity about the requirements placed on various actors in pNFS. I will change … [Ballot discuss] Thanks for writing this up; it's good to have better clarity about the requirements placed on various actors in pNFS. I will change to Yes once this issue is resolved: Section 4 leaves me confused about what exactly from RFC 5661 is being updated. That is, the subsections look to be some discussion about how the "real requirements" (i.e., this document) apply to the given layout types, and we are told that these sections do not update the specification for those specific layout types. So it's hard to get a clear picture about which specific requirements are being changed/added; this leads me to wonder if the top-level Section 4 should not say "This section updates Section 12 of [RFC5661]" and leave the "discussed here only to illuminate the updates made to Section 12 of [RFC5661]". |
2018-04-17
|
10 | Benjamin Kaduk | [Ballot comment] Section 1 Such matters are defined in a standards-track layout type specification. This could be read as saying that there is … [Ballot comment] Section 1 Such matters are defined in a standards-track layout type specification. This could be read as saying that there is a single document, which happens to be a layout-type specification and standards-track, that gives guidance on how layout types differ. Maybe: Each layout type will define the needed details for its usage in the specifciation for that layout type; layout type specifications are always standards-track RFCs. Section 3.3 [..] If the document does not impose implementation requirements sufficient to ensure that these semantic requirements are met, it is not appropriate for the working group to allow the document to move forward. Maybe "it is not appropriate for publication as an IETF-stream RFC"? o If the metadata server does not have a means to invalidate a stateid issued to the storage device to keep a particular client from accessing a specific file, then the layout type specification has to document how the metadata server is going to fence the client from access to the file on that storage device. Is the stateid issued to the storage device or to the client? Section 4 leaves me confused about what exactly from RFC 5661 is being updated. That is, the subsections look to be some discussion about how the "real requirements" (i.e., this document) apply to the given layout types, we are told that these sections do not update the specification for those specific layout types. So it's hard to get a clear picture about which specific things are being updated; this leads me to wonder if the top-level Section 4 should not say "This section updates Section 12 of [RFC5661]" and leave the "discussed here only to illuminate the updates made to Section 12 of [RFC5661[". Section 6 [...] In the latter case, I/O access writes are reflected in layouts [...] s/writes/rights/ |
2018-04-17
|
10 | Benjamin Kaduk | [Ballot Position Update] New position, Discuss, has been recorded for Benjamin Kaduk |
2018-04-16
|
10 | Ben Campbell | [Ballot Position Update] New position, No Objection, has been recorded for Ben Campbell |
2018-04-16
|
10 | Warren Kumari | [Ballot comment] Thank you for this. I had one readability issue -- I find: " control communication requirements: are for a layout type the … [Ballot comment] Thank you for this. I had one readability issue -- I find: " control communication requirements: are for a layout type the details regarding information on layouts, stateids, file metadata, and file data which must be communicated between the metadata server and the storage devices." to be very hard to read. I tried for a while to break this up into multiple sentences but was unable. It would be nice if the authors could succeed where I failed... |
2018-04-16
|
10 | Warren Kumari | [Ballot Position Update] New position, No Objection, has been recorded for Warren Kumari |
2018-04-16
|
10 | Alissa Cooper | [Ballot Position Update] New position, No Objection, has been recorded for Alissa Cooper |
2018-04-16
|
10 | Alexey Melnikov | [Ballot Position Update] New position, No Objection, has been recorded for Alexey Melnikov |
2018-04-16
|
10 | Eric Rescorla | [Ballot Position Update] New position, No Objection, has been recorded for Eric Rescorla |
2018-04-13
|
10 | Mirja Kühlewind | [Ballot comment] Please use RFC8174 boilerplate and maybe double-check the use of lower case MUSTs and MAYs, e.g. should this sentence in the security considerations … [Ballot comment] Please use RFC8174 boilerplate and maybe double-check the use of lower case MUSTs and MAYs, e.g. should this sentence in the security considerations maybe use an upper case MUST: "The layout type specification must ensure that only data accesses consistent with the NFSV4.1 security model are allowed." |
2018-04-13
|
10 | Mirja Kühlewind | Ballot comment text updated for Mirja Kühlewind |
2018-04-13
|
10 | Mirja Kühlewind | [Ballot comment] Please use RFC8174 boilerplate and maybe double-check the use of lower case MUSTs and MAYs, e.g. should this sentence in the security considerations … [Ballot comment] Please use RFC8174 boilerplate and maybe double-check the use of lower case MUSTs and MAYs, e.g. should this sentence in the security considerations maybe use an upper case MUST: "The layout type specification must ensure that only data accesses consistent with the NFSV4.1 security model are allowed." |
2018-04-13
|
10 | Mirja Kühlewind | [Ballot Position Update] New position, No Objection, has been recorded for Mirja Kühlewind |
2018-03-21
|
10 | Spencer Dawkins | Telechat date has been changed to 2018-04-19 from 2018-04-05 |
2018-03-14
|
10 | Spencer Dawkins | IESG state changed to IESG Evaluation from Waiting for AD Go-Ahead |
2018-03-02
|
10 | Gunter Van de Velde | Request for Telechat review by OPSDIR is assigned to Carlos Martinez |
2018-03-02
|
10 | Gunter Van de Velde | Request for Telechat review by OPSDIR is assigned to Carlos Martinez |
2018-02-27
|
10 | (System) | IANA Review state changed to Version Changed - Review Needed from IANA OK - No Actions Needed |
2018-02-27
|
10 | Thomas Haynes | New version available: draft-ietf-nfsv4-layout-types-10.txt |
2018-02-27
|
10 | (System) | New version approved |
2018-02-27
|
10 | (System) | Request for posting confirmation emailed to previous authors: Thomas Haynes , nfsv4-chairs@ietf.org |
2018-02-27
|
10 | Thomas Haynes | Uploaded new revision |
2018-02-26
|
10 | (System) | IANA Review state changed to IANA OK - No Actions Needed from Version Changed - Review Needed |
2018-02-24
|
09 | Jean Mahoney | Request for Last Call review by GENART Completed: Ready. Reviewer: Meral Shirazipour. |
2018-02-23
|
09 | Spencer Dawkins | Ballot has been issued |
2018-02-23
|
09 | Spencer Dawkins | Ballot writeup was changed |
2018-02-23
|
09 | Spencer Dawkins | [Ballot Position Update] New position, Yes, has been recorded for Spencer Dawkins |
2018-02-23
|
09 | (System) | IESG state changed to Waiting for AD Go-Ahead from In Last Call |
2018-02-20
|
09 | (System) | IANA Review state changed to IANA OK - No Actions Needed from Version Changed - Review Needed |
2018-02-20
|
09 | Sabrina Tanamal | (Via drafts-lastcall@iana.org): IESG/Authors/WG Chairs: The IANA Services Operator has reviewed draft-ietf-nfsv4-layout-types-09, which is currently in Last Call, and has the following comments: We … (Via drafts-lastcall@iana.org): IESG/Authors/WG Chairs: The IANA Services Operator has reviewed draft-ietf-nfsv4-layout-types-09, 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-02-20
|
09 | Spencer Dawkins | Telechat date has been changed to 2018-04-05 from 2015-05-28 |
2018-02-16
|
09 | Tero Kivinen | Request for Last Call review by SECDIR is assigned to Klaas Wierenga |
2018-02-16
|
09 | Tero Kivinen | Request for Last Call review by SECDIR is assigned to Klaas Wierenga |
2018-02-15
|
09 | Jean Mahoney | Request for Last Call review by GENART is assigned to Meral Shirazipour |
2018-02-15
|
09 | Jean Mahoney | Request for Last Call review by GENART is assigned to Meral Shirazipour |
2018-02-09
|
09 | Cindy Morgan | The following Last Call announcement was sent out (ends 2018-02-23): From: The IESG To: IETF-Announce CC: spencer.shepler@gmail.com, nfsv4-chairs@ietf.org, spencerdawkins.ietf@gmail.com, nfsv4@ietf.org, draft-ietf-nfsv4-layout-types@ietf.org … The following Last Call announcement was sent out (ends 2018-02-23): From: The IESG To: IETF-Announce CC: spencer.shepler@gmail.com, nfsv4-chairs@ietf.org, spencerdawkins.ietf@gmail.com, nfsv4@ietf.org, draft-ietf-nfsv4-layout-types@ietf.org Reply-To: ietf@ietf.org Sender: Subject: Last Call: (Requirements for pNFS Layout Types) to Proposed Standard The IESG has received a request from the Network File System Version 4 WG (nfsv4) to consider the following document: - 'Requirements for pNFS Layout Types' 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-02-23. 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 defines the requirements which individual pNFS layout types need to meet in order to work within the parallel NFS (pNFS) framework as defined in RFC5661. In so doing, it aims to clearly distinguish between requirements for pNFS as a whole and those specifically directed to the pNFS File Layout. The lack of a clear separation between the two set of requirements has been troublesome for those specifying and evaluating new Layout Types. In this regard, this document updates RFC5661. The file can be obtained via https://datatracker.ietf.org/doc/draft-ietf-nfsv4-layout-types/ IESG discussion can be tracked via https://datatracker.ietf.org/doc/draft-ietf-nfsv4-layout-types/ballot/ No IPR declarations have been submitted directly on this I-D. |
2018-02-09
|
09 | Cindy Morgan | IESG state changed to In Last Call from Last Call Requested |
2018-02-09
|
09 | Spencer Dawkins | Last call was requested |
2018-02-09
|
09 | Spencer Dawkins | IESG state changed to Last Call Requested from AD Evaluation::AD Followup |
2018-02-09
|
09 | Spencer Dawkins | Last call announcement was generated |
2018-02-05
|
09 | (System) | Sub state has been changed to AD Followup from Revised ID Needed |
2018-02-05
|
09 | Thomas Haynes | New version available: draft-ietf-nfsv4-layout-types-09.txt |
2018-02-05
|
09 | (System) | New version approved |
2018-02-05
|
09 | (System) | Request for posting confirmation emailed to previous authors: Thomas Haynes |
2018-02-05
|
09 | Thomas Haynes | Uploaded new revision |
2018-02-05
|
08 | Spencer Dawkins | IESG state changed to AD Evaluation::Revised I-D Needed from AD Evaluation |
2018-01-24
|
08 | Spencer Dawkins | IESG state changed to AD Evaluation from Publication Requested |
2018-01-14
|
08 | Spencer Shepler | Working Group: NFSv4 Area Director: Spencer Dawkins Document Author/Shepherd: Spencer Shepler Internet Draft: Requirements for pNFS Layout Types draft-ietf-nfsv4-layout-types-15.txt (1) What type of RFC is … Working Group: NFSv4 Area Director: Spencer Dawkins Document Author/Shepherd: Spencer Shepler Internet Draft: Requirements for pNFS Layout Types draft-ietf-nfsv4-layout-types-15.txt (1) What type of RFC is being requested (BCP, Proposed Standard, Internet Standard, Informational, Experimental, or Historic)? Why is this the proper type of RFC? Is this type of RFC indicated in the title page header? Proposed Standard RFC is being requested for this I-D. The purpose of this document was to clarify the requirements between parallel NFS (pNFS) and those for the pNFS File Layout Type. With new Layout Types being proposed, the working group desired to provide a document which clarifies what the new Layout Type specification must capture. (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 Internet-Draft outlines high-level requirements for the introduction of new Layout Types into parallel NFS (pNFS). In RFC5661, the delineation between the requirements for pNFS and the File Layout Type is not clear for all readers. This I-D clarifies the responsibilities of a generic Layout Type by examining all of the existing Layout Types, not just the File Layout Type. Working Group Summary: When discussing new proposed Layout Types, there was a lot of confusion about the role of a Control Protocol between the metadata server, the storage devices, and the clients. The casting of the Control Protocol as a set of requirements has reduced that confusion and has resulted in a broad consensus to support this I-D. Note that working group review of the document continued after publication was requested, and during the period in which the IESG was discussing the document as well. The document was reworked in the WG to address that situation. Document Quality: This Internet Draft reviews and clarifies the requirements for creating a new Layout Type. It uses the three existing Layout Type specification as case studies to show that the requirements were issues considered during the creation of earlier Layout Types. I.e., it captures the relevancy of the requirements. The content of this document has received quality feedback and review throughout its life. Personnel: Spencer Shepler (NFSv4 WG co-chair) 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. The document shepherd has reviewed the document in full (intermediate drafts and the final version). This version is ready for IETF review and publication. (4) Does the document Shepherd have any concerns about the depth or breadth of the reviews that have been performed? The Requirements for pNFS Layout Types I-D covers the topic in the appropriate depth. It uses exisitng Layout Types as case studies to show the applicability of the requirements. (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 outstanding concerns exist 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. No outstanding concerns exist 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. No. No IPR disclosures have been filed in reference to this document. (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? There is solid working group consensus for this document. (10) Has anyone threatened an appeal or otherwise indicated extreme discontent? If so, please summarise the areas of conflict in separate email messages to the Responsible Area Director. (It should be in a separate email because this questionnaire is publicly available.) There is no threat of appeal in regards to this document or its contents. (11) Identify any ID nits the Document Shepherd has found in this document. (See http://www.ietf.org/tools/idnits/ and the Internet-Drafts Checklist). Boilerplate checks are not enough; this check needs to be thorough. There are informative reference issues but they can be handled during the IESG review process. (12) Describe how the document meets any required formal review criteria, such as the MIB Doctor, media type, and URI type reviews. Not applicable. (13) Have all references within this document been identified as either normative or informative? Yes. (14) Are there normative references to documents that are not ready for advancement or are otherwise in an unclear state? If such normative references exist, what is the plan for their completion? 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. Not applicable. (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. Not applicable. (17) Describe the Document Shepherd's review of the IANA considerations section, especially with regard to its consistency with the body of the document. Confirm that all protocol extensions that the document makes are associated with the appropriate reservations in IANA registries. Confirm that any referenced IANA registries have been clearly identified. Confirm that newly created IANA registries include a detailed specification of the initial contents for the registry, that allocations procedures for future registrations are defined, and a reasonable name for the new registry has been suggested (see RFC 5226). Not applicable. (18) List any new IANA registries that require Expert Review for future allocations. Provide any public guidance that the IESG would find useful in selecting the IANA Experts for these new registries. Not applicable. (19) Describe reviews and automated checks performed by the Document Shepherd to validate sections of the document written in a formal language, such as XML code, BNF rules, MIB definitions, etc. Not applicable. |
2018-01-14
|
08 | Spencer Shepler | IETF WG state changed to Submitted to IESG for Publication from WG Consensus: Waiting for Write-Up |
2018-01-14
|
08 | Spencer Shepler | IESG state changed to Publication Requested from AD is watching |
2018-01-14
|
08 | Spencer Dawkins | IESG state changed to AD is watching from Dead |
2018-01-14
|
08 | Spencer Shepler | Working Group: NFSv4 Area Director: Spencer Dawkins Document Author/Shepherd: Spencer Shepler Internet Draft: Requirements for pNFS Layout Types draft-ietf-nfsv4-layout-types-15.txt (1) What type of RFC is … Working Group: NFSv4 Area Director: Spencer Dawkins Document Author/Shepherd: Spencer Shepler Internet Draft: Requirements for pNFS Layout Types draft-ietf-nfsv4-layout-types-15.txt (1) What type of RFC is being requested (BCP, Proposed Standard, Internet Standard, Informational, Experimental, or Historic)? Why is this the proper type of RFC? Is this type of RFC indicated in the title page header? Proposed Standard RFC is being requested for this I-D. The purpose of this document was to clarify the requirements between parallel NFS (pNFS) and those for the pNFS File Layout Type. With new Layout Types being proposed, the working group desired to provide a document which clarifies what the new Layout Type specification must capture. (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 Internet-Draft outlines high-level requirements for the introduction of new Layout Types into parallel NFS (pNFS). In RFC5661, the delineation between the requirements for pNFS and the File Layout Type is not clear for all readers. This I-D clarifies the responsibilities of a generic Layout Type by examining all of the existing Layout Types, not just the File Layout Type. Working Group Summary: When discussing new proposed Layout Types, there was a lot of confusion about the role of a Control Protocol between the metadata server, the storage devices, and the clients. The casting of the Control Protocol as a set of requirements has reduced that confusion and has resulted in a broad consensus to support this I-D. Note that working group review of the document continued after publication was requested, and during the period in which the IESG was discussing the document as well. The document was reworked in the WG to address that situation. Document Quality: This Internet Draft reviews and clarifies the requirements for creating a new Layout Type. It uses the three existing Layout Type specification as case studies to show that the requirements were issues considered during the creation of earlier Layout Types. I.e., it captures the relevancy of the requirements. The content of this document has received quality feedback and review throughout its life. Personnel: Spencer Shepler (NFSv4 WG co-chair) 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. The document shepherd has reviewed the document in full (intermediate drafts and the final version). This version is ready for IETF review and publication. (4) Does the document Shepherd have any concerns about the depth or breadth of the reviews that have been performed? The Requirements for pNFS Layout Types I-D covers the topic in the appropriate depth. It uses exisitng Layout Types as case studies to show the applicability of the requirements. (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 outstanding concerns exist 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. No outstanding concerns exist 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. No. No IPR disclosures have been filed in reference to this document. (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? There is solid working group consensus for this document. (10) Has anyone threatened an appeal or otherwise indicated extreme discontent? If so, please summarise the areas of conflict in separate email messages to the Responsible Area Director. (It should be in a separate email because this questionnaire is publicly available.) There is no threat of appeal in regards to this document or its contents. (11) Identify any ID nits the Document Shepherd has found in this document. (See http://www.ietf.org/tools/idnits/ and the Internet-Drafts Checklist). Boilerplate checks are not enough; this check needs to be thorough. There are informative reference issues but they can be handled during the IESG review process. (12) Describe how the document meets any required formal review criteria, such as the MIB Doctor, media type, and URI type reviews. Not applicable. (13) Have all references within this document been identified as either normative or informative? Yes. (14) Are there normative references to documents that are not ready for advancement or are otherwise in an unclear state? If such normative references exist, what is the plan for their completion? 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. Not applicable. (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. Not applicable. (17) Describe the Document Shepherd's review of the IANA considerations section, especially with regard to its consistency with the body of the document. Confirm that all protocol extensions that the document makes are associated with the appropriate reservations in IANA registries. Confirm that any referenced IANA registries have been clearly identified. Confirm that newly created IANA registries include a detailed specification of the initial contents for the registry, that allocations procedures for future registrations are defined, and a reasonable name for the new registry has been suggested (see RFC 5226). Not applicable. (18) List any new IANA registries that require Expert Review for future allocations. Provide any public guidance that the IESG would find useful in selecting the IANA Experts for these new registries. Not applicable. (19) Describe reviews and automated checks performed by the Document Shepherd to validate sections of the document written in a formal language, such as XML code, BNF rules, MIB definitions, etc. Not applicable. |
2018-01-14
|
08 | Spencer Shepler | Working Group: NFSv4 Area Director: Spencer Dawkins Document Author/Shepherd: Spencer Shepler Internet Draft: Requirements for pNFS Layout Types draft-ietf-nfsv4-layout-types-08.txt (1) What type of RFC is … Working Group: NFSv4 Area Director: Spencer Dawkins Document Author/Shepherd: Spencer Shepler Internet Draft: Requirements for pNFS Layout Types draft-ietf-nfsv4-layout-types-08.txt (1) What type of RFC is being requested (BCP, Proposed Standard, Internet Standard, Informational, Experimental, or Historic)? Why is this the proper type of RFC? Is this type of RFC indicated in the title page header? Proposed Standard RFC is being requested for this I-D. The purpose of this document was to clarify the requirements between parallel NFS (pNFS) and those for the pNFS File Layout Type. With new Layout Types being proposed, the working group desired to provide a document which clarifies what the new Layout Type specification must capture. (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 Internet-Draft outlines high-level requirements for the introduction of new Layout Types into parallel NFS (pNFS). In RFC5661, the delineation between the requirements for pNFS and the File Layout Type is not clear for all readers. This I-D clarifies the responsibilities of a generic Layout Type by examining all of the existing Layout Types, not just the File Layout Type. Working Group Summary: When discussing new proposed Layout Types, there was a lot of confusion about the role of a Control Protocol between the metadata server, the storage devices, and the clients. The casting of the Control Protocol as a set of requirements has reduced that confusion and has resulted in a broad consensus to support this I-D. Note that working group review of the document continued after publication was requested, and during the period in which the IESG was discussing the document as well. The document was reworked in the WG to address that situation. Document Quality: This Internet Draft reviews and clarifies the requirements for creating a new Layout Type. It uses the three existing Layout Type specification as case studies to show that the requirements were issues considered during the creation of earlier Layout Types. I.e., it captures the relevancy of the requirements. The content of this document has received quality feedback and review throughout its life. Personnel: Spencer Shepler (NFSv4 WG co-chair) 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. The document shepherd has reviewed the document in full (intermediate drafts and the final version). This version is ready for IETF review and publication. (4) Does the document Shepherd have any concerns about the depth or breadth of the reviews that have been performed? The Requirements for pNFS Layout Types I-D covers the topic in the appropriate depth. It uses exisitng Layout Types as case studies to show the applicability of the requirements. (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 outstanding concerns exist 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. No outstanding concerns exist 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. No. No IPR disclosures have been filed in reference to this document. (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? There is solid working group consensus for this document. (10) Has anyone threatened an appeal or otherwise indicated extreme discontent? If so, please summarise the areas of conflict in separate email messages to the Responsible Area Director. (It should be in a separate email because this questionnaire is publicly available.) There is no threat of appeal in regards to this document or its contents. (11) Identify any ID nits the Document Shepherd has found in this document. (See http://www.ietf.org/tools/idnits/ and the Internet-Drafts Checklist). Boilerplate checks are not enough; this check needs to be thorough. There are informative reference issues but they can be handled during the IESG review process. (12) Describe how the document meets any required formal review criteria, such as the MIB Doctor, media type, and URI type reviews. Not applicable. (13) Have all references within this document been identified as either normative or informative? Yes. (14) Are there normative references to documents that are not ready for advancement or are otherwise in an unclear state? If such normative references exist, what is the plan for their completion? 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. Not applicable. (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. Not applicable. (17) Describe the Document Shepherd's review of the IANA considerations section, especially with regard to its consistency with the body of the document. Confirm that all protocol extensions that the document makes are associated with the appropriate reservations in IANA registries. Confirm that any referenced IANA registries have been clearly identified. Confirm that newly created IANA registries include a detailed specification of the initial contents for the registry, that allocations procedures for future registrations are defined, and a reasonable name for the new registry has been suggested (see RFC 5226). Not applicable. (18) List any new IANA registries that require Expert Review for future allocations. Provide any public guidance that the IESG would find useful in selecting the IANA Experts for these new registries. Not applicable. (19) Describe reviews and automated checks performed by the Document Shepherd to validate sections of the document written in a formal language, such as XML code, BNF rules, MIB definitions, etc. Not applicable. |
2017-10-31
|
08 | Spencer Shepler | Working Group: NFSv4 Area Director: Spencer Dawkins Document Author/Shepherd: Spencer Shepler Internet Draft: Requirements for pNFS Layout Types draft-ietf-nfsv4-layout-types-08.txt (1) What type of RFC is … Working Group: NFSv4 Area Director: Spencer Dawkins Document Author/Shepherd: Spencer Shepler Internet Draft: Requirements for pNFS Layout Types draft-ietf-nfsv4-layout-types-08.txt (1) What type of RFC is being requested (BCP, Proposed Standard, Internet Standard, Informational, Experimental, or Historic)? Why is this the proper type of RFC? Is this type of RFC indicated in the title page header? Proposed Standard RFC is being requested for this I-D. The purpose of this document was to clarify the requirements between parallel NFS (pNFS) and those for the pNFS File Layout Type. With new Layout Types being proposed, the working group desired to provide a document which clarifies what the new Layout Type specification must capture. (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 Internet-Draft outlines high-level requirements for the introduction of new Layout Types into parallel NFS (pNFS). In RFC5661, the delineation between the requirements for pNFS and the File Layout Type is not clear for all readers. This I-D clarifies the responsibilities of a generic Layout Type by examining all of the existing Layout Types, not just the File Layout Type. Working Group Summary: When discussing new proposed Layout Types, there was a lot of confusion about the role of a Control Protocol between the metadata server, the storage devices, and the clients. The casting of the Control Protocol as a set of requirements has reduced that confusion and has resulted in a broad consensus to support this I-D. Note that working group review of the document continued after publication was requested, and during the period in which the IESG was discussing the document as well. The document was reworked in the WG to address that situation. Document Quality: This Internet Draft reviews and clarifies the requirements for creating a new Layout Type. It uses the three existing Layout Type specification as case studies to show that the requirements were issues considered during the creation of earlier Layout Types. I.e., it captures the relevancy of the requirements. The content of this document has received quality feedback and review throughout its life. Personnel: Spencer Shepler (NFSv4 WG co-chair) 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. The document shepherd has reviewed the document in full (intermediate drafts and the final version). This version is ready for IETF review and publication. (4) Does the document Shepherd have any concerns about the depth or breadth of the reviews that have been performed? The Requirements for pNFS Layout Types I-D covers the topic in the appropriate depth. It uses exisitng Layout Types as case studies to show the applicability of the requirements. (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 outstanding concerns exist 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. No outstanding concerns exist 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. No. No IPR disclosures have been filed in reference to this document. (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? There is solid working group consensus for this document. (10) Has anyone threatened an appeal or otherwise indicated extreme discontent? If so, please summarise the areas of conflict in separate email messages to the Responsible Area Director. (It should be in a separate email because this questionnaire is publicly available.) There is no threat of appeal in regards to this document or its contents. (11) Identify any ID nits the Document Shepherd has found in this document. (See http://www.ietf.org/tools/idnits/ and the Internet-Drafts Checklist). Boilerplate checks are not enough; this check needs to be thorough. There are informative reference issues but they can be handled during the IESG review process. (12) Describe how the document meets any required formal review criteria, such as the MIB Doctor, media type, and URI type reviews. Not applicable. (13) Have all references within this document been identified as either normative or informative? Yes. (14) Are there normative references to documents that are not ready for advancement or are otherwise in an unclear state? If such normative references exist, what is the plan for their completion? 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. Not applicable. (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. Not applicable. (17) Describe the Document Shepherd's review of the IANA considerations section, especially with regard to its consistency with the body of the document. Confirm that all protocol extensions that the document makes are associated with the appropriate reservations in IANA registries. Confirm that any referenced IANA registries have been clearly identified. Confirm that newly created IANA registries include a detailed specification of the initial contents for the registry, that allocations procedures for future registrations are defined, and a reasonable name for the new registry has been suggested (see RFC 5226). Not applicable. (18) List any new IANA registries that require Expert Review for future allocations. Provide any public guidance that the IESG would find useful in selecting the IANA Experts for these new registries. Not applicable. (19) Describe reviews and automated checks performed by the Document Shepherd to validate sections of the document written in a formal language, such as XML code, BNF rules, MIB definitions, etc. Not applicable. |
2017-10-27
|
08 | Spencer Shepler | Working Group: NFSv4 Area Director: Spencer Dawkins Document Author/Shepherd: Spencer Shepler Internet Draft: Requirements for pNFS Layout Types draft-ietf-nfsv4-layout-types-08.txt (1) What type of RFC is … Working Group: NFSv4 Area Director: Spencer Dawkins Document Author/Shepherd: Spencer Shepler Internet Draft: Requirements for pNFS Layout Types draft-ietf-nfsv4-layout-types-08.txt (1) What type of RFC is being requested (BCP, Proposed Standard, Internet Standard, Informational, Experimental, or Historic)? Why is this the proper type of RFC? Is this type of RFC indicated in the title page header? Proposed Standard RFC is being requested for this I-D. The purpose of this document was to clarify the requirements between parallel NFS (pNFS) and those for the pNFS File Layout Type. With new Layout Types being proposed, the working group desired to provide a document which clarifies what the new Layout Type specification must capture. (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 Internet-Draft outlines high-level requirements for the introduction of new Layout Types into parallel NFS (pNFS). In RFC5661, the delineation between the requirements for pNFS and the File Layout Type is not clear for all readers. This I-D clarifies the responsibilities of a generic Layout Type by examining all of the existing Layout Types, not just the File Layout Type. Working Group Summary: When discussing new proposed Layout Types, there was a lot of confusion about the role of a Control Protocol between the metadata server, the storage devices, and the clients. The casting of the Control Protocol as a set of requirements has reduced that confusion and has resulted in a broad consensus to support this I-D. Note that there was a late review inside the group after the document had already been put before the IESG. The document was reworked inside the WG. Document Quality: This Internet Draft reviews and clarifies the requirements for creating a new Layout Type. It uses the three existing Layout Type specification as case studies to show that the requirements were issues considered during the creation of earlier Layout Types. I.e., it captures the relevancy of the requirements. The content of this document has received quality feedback and review throughout its life. Personnel: Spencer Shepler (NFSv4 WG co-chair) 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. The document shepherd has reviewed the document in full (intermediate drafts and the final version). This version is ready for IETF review and publication. (4) Does the document Shepherd have any concerns about the depth or breadth of the reviews that have been performed? The Requirements for pNFS Layout Types I-D covers the topic in the appropriate depth. It uses exisitng Layout Types as case studies to show the applicability of the requirements. (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 outstanding concerns exist 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. No outstanding concerns exist 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. No. No IPR disclosures have been filed in reference to this document. (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? There is solid working group consensus for this document. (10) Has anyone threatened an appeal or otherwise indicated extreme discontent? If so, please summarise the areas of conflict in separate email messages to the Responsible Area Director. (It should be in a separate email because this questionnaire is publicly available.) There is no threat of appeal in regards to this document or its contents. (11) Identify any ID nits the Document Shepherd has found in this document. (See http://www.ietf.org/tools/idnits/ and the Internet-Drafts Checklist). Boilerplate checks are not enough; this check needs to be thorough. There are informative reference issues but they can be handled during the IESG review process. (12) Describe how the document meets any required formal review criteria, such as the MIB Doctor, media type, and URI type reviews. Not applicable. (13) Have all references within this document been identified as either normative or informative? Yes. (14) Are there normative references to documents that are not ready for advancement or are otherwise in an unclear state? If such normative references exist, what is the plan for their completion? 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. Not applicable. (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. Not applicable. (17) Describe the Document Shepherd's review of the IANA considerations section, especially with regard to its consistency with the body of the document. Confirm that all protocol extensions that the document makes are associated with the appropriate reservations in IANA registries. Confirm that any referenced IANA registries have been clearly identified. Confirm that newly created IANA registries include a detailed specification of the initial contents for the registry, that allocations procedures for future registrations are defined, and a reasonable name for the new registry has been suggested (see RFC 5226). Not applicable. (18) List any new IANA registries that require Expert Review for future allocations. Provide any public guidance that the IESG would find useful in selecting the IANA Experts for these new registries. Not applicable. (19) Describe reviews and automated checks performed by the Document Shepherd to validate sections of the document written in a formal language, such as XML code, BNF rules, MIB definitions, etc. Not applicable. |
2017-09-05
|
08 | Spencer Shepler | IETF WG state changed to WG Consensus: Waiting for Write-Up from In WG Last Call |
2017-08-31
|
08 | Thomas Haynes | New version available: draft-ietf-nfsv4-layout-types-08.txt |
2017-08-31
|
08 | (System) | New version approved |
2017-08-31
|
08 | (System) | Request for posting confirmation emailed to previous authors: Thomas Haynes |
2017-08-31
|
08 | Thomas Haynes | Uploaded new revision |
2017-08-29
|
07 | Thomas Haynes | New version available: draft-ietf-nfsv4-layout-types-07.txt |
2017-08-29
|
07 | (System) | New version approved |
2017-08-29
|
07 | (System) | Request for posting confirmation emailed to previous authors: Thomas Haynes |
2017-08-29
|
07 | Thomas Haynes | Uploaded new revision |
2017-08-16
|
06 | Thomas Haynes | New version available: draft-ietf-nfsv4-layout-types-06.txt |
2017-08-16
|
06 | (System) | New version approved |
2017-08-16
|
06 | (System) | Request for posting confirmation emailed to previous authors: Thomas Haynes |
2017-08-16
|
06 | Thomas Haynes | Uploaded new revision |
2017-08-09
|
05 | Spencer Shepler | moved back to WG last call based on recent updates and reviews. |
2017-08-09
|
05 | Spencer Shepler | IETF WG state changed to In WG Last Call from WG Document |
2017-07-19
|
05 | Thomas Haynes | New version available: draft-ietf-nfsv4-layout-types-05.txt |
2017-07-19
|
05 | (System) | New version approved |
2017-07-19
|
05 | (System) | Request for posting confirmation emailed to previous authors: Thomas Haynes |
2017-07-19
|
05 | Thomas Haynes | Uploaded new revision |
2016-07-31
|
04 | (System) | Document has expired |
2016-04-06
|
04 | Cindy Morgan | Shepherding AD changed to Spencer Dawkins |
2016-01-28
|
04 | Thomas Haynes | IANA Review state changed to Version Changed - Review Needed from IANA OK - No Actions Needed |
2016-01-28
|
04 | Thomas Haynes | New version available: draft-ietf-nfsv4-layout-types-04.txt |
2015-10-14
|
03 | (System) | Notify list changed from "Spencer Shepler" to (None) |
2015-08-03
|
03 | (System) | Document has expired |
2015-08-03
|
03 | (System) | IESG state changed to Dead from AD is watching |
2015-07-23
|
03 | Cindy Morgan | Created "Approve" ballot |
2015-07-23
|
03 | Cindy Morgan | Closed "Approve" ballot |
2015-07-21
|
03 | Martin Stiemerling | IETF WG state changed to WG Document from Submitted to IESG for Publication |
2015-07-21
|
03 | Martin Stiemerling | Returned to WG to address pending, late WG comments. |
2015-07-21
|
03 | Martin Stiemerling | IESG state changed to AD is watching from IESG Evaluation |
2015-06-11
|
03 | Meral Shirazipour | Request for Telechat review by GENART Completed: Ready with Nits. Reviewer: Meral Shirazipour. |
2015-05-28
|
03 | Alia Atlas | [Ballot Position Update] New position, No Objection, has been recorded for Alia Atlas |
2015-05-28
|
03 | Brian Haberman | [Ballot Position Update] New position, No Objection, has been recorded for Brian Haberman |
2015-05-28
|
03 | Spencer Dawkins | [Ballot Position Update] New position, No Objection, has been recorded for Spencer Dawkins |
2015-05-28
|
03 | Martin Stiemerling | Intended Status changed to Proposed Standard from Informational |
2015-05-27
|
03 | Alvaro Retana | [Ballot Position Update] New position, No Objection, has been recorded for Alvaro Retana |
2015-05-27
|
03 | Ben Campbell | [Ballot comment] The ballot and shepherd writeup say "informational", but the document says "Standards Track." I assume the former is intended. |
2015-05-27
|
03 | Ben Campbell | [Ballot Position Update] New position, No Objection, has been recorded for Ben Campbell |
2015-05-27
|
03 | Kathleen Moriarty | [Ballot discuss] Thanks for your work on this draft. I would expect the security consideration to discuss the shift to security at the client as … [Ballot discuss] Thanks for your work on this draft. I would expect the security consideration to discuss the shift to security at the client as well as to see some text on access controls and access checks, which may just refer to existing sections. The SecDir review had similar comments with some specific suggestions that do not appear to have been addressed, but please do point me to the thread if there has been follow up. Specifically, better organization of the security considerations is requested and I agree with Joe's assessment. https://www.ietf.org/mail-archive/web/secdir/current/msg05662.html |
2015-05-27
|
03 | Kathleen Moriarty | [Ballot Position Update] New position, Discuss, has been recorded for Kathleen Moriarty |
2015-05-27
|
03 | Deborah Brungard | [Ballot Position Update] New position, No Objection, has been recorded for Deborah Brungard |
2015-05-27
|
03 | Benoît Claise | [Ballot comment] Some nits and editorial comments, as mentioned by Menachem in his OPS-DIR review: NITS ==== The tool has found the following: == Outdated … [Ballot comment] Some nits and editorial comments, as mentioned by Menachem in his OPS-DIR review: NITS ==== The tool has found the following: == Outdated reference: A later version (-05) exists of draft-ietf-nfsv4-flex-files-02 Additional NITS =============== Abstract First Sentence: Repetition of the word "those". This document provides help in distinguishing between the requirements for Network File System (NFS) version 4.1's Parallel NFS (pNFS) and those those specifically directed to the pNFS File Layout. Section 2: Definitions - Not sure whether the word :striped" was intended here. Data Server (DS): is one of the pNFS servers which provide the contents of a file system object which is a regular file. Depending on the layout, there might be one or more data servers over which the data is striped. Section 2: Definitions - Suggest "lay out" rather than "lays out". Layout Type: describes both the storage protocol used to access the data and the aggregation scheme used to lays out the file data on the underlying storage devices. Section 3.3: Editorial Requirements - Suggest "separately" rather than "separably" "While these could be envisioned as one section in that the fencing issue might be the only security issue, it is recommended to deal with them separably." |
2015-05-27
|
03 | Benoît Claise | [Ballot Position Update] New position, No Objection, has been recorded for Benoit Claise |
2015-05-27
|
03 | Stephen Farrell | [Ballot comment] Did I miss a response to the secdir review? [1] I think Joe's questions are worth answering so I hope you do. … [Ballot comment] Did I miss a response to the secdir review? [1] I think Joe's questions are worth answering so I hope you do. [1] https://www.ietf.org/mail-archive/web/secdir/current/msg05662.html |
2015-05-27
|
03 | Stephen Farrell | [Ballot Position Update] New position, No Objection, has been recorded for Stephen Farrell |
2015-05-25
|
03 | Joel Jaeggli | [Ballot comment] Nit, 4.3. Object Layout Type The Object Layout Type focuses security checks to occur during the allocation of the layout. The … [Ballot comment] Nit, 4.3. Object Layout Type The Object Layout Type focuses security checks to occur during the allocation of the layout. The client will typically ask for a layout for each byte-range of either READ or READ/WRITE I don't think focuses is right word in this context... forces? |
2015-05-25
|
03 | Joel Jaeggli | [Ballot Position Update] New position, No Objection, has been recorded for Joel Jaeggli |
2015-05-21
|
03 | Barry Leiba | [Ballot Position Update] New position, No Objection, has been recorded for Barry Leiba |
2015-05-21
|
03 | Jean Mahoney | Request for Telechat review by GENART is assigned to Meral Shirazipour |
2015-05-21
|
03 | Jean Mahoney | Request for Telechat review by GENART is assigned to Meral Shirazipour |
2015-05-15
|
03 | Gunter Van de Velde | Request for Last Call review by OPSDIR Completed: Has Nits. Reviewer: Menachem Dodge. |
2015-05-08
|
03 | Meral Shirazipour | Request for Last Call review by GENART Completed: Ready with Nits. Reviewer: Meral Shirazipour. |
2015-05-07
|
03 | Martin Stiemerling | Telechat date has been changed to 2015-05-28 from 2015-05-14 |
2015-04-23
|
03 | Tero Kivinen | Request for Last Call review by SECDIR Completed: Has Issues. Reviewer: Joseph Salowey. |
2015-04-22
|
03 | Martin Stiemerling | Placed on agenda for telechat - 2015-05-14 |
2015-04-22
|
03 | Martin Stiemerling | IESG state changed to IESG Evaluation from Waiting for AD Go-Ahead |
2015-04-22
|
03 | Martin Stiemerling | IESG state changed to Waiting for AD Go-Ahead from Waiting for Writeup |
2015-04-22
|
03 | Martin Stiemerling | Ballot has been issued |
2015-04-22
|
03 | Martin Stiemerling | [Ballot Position Update] New position, Yes, has been recorded for Martin Stiemerling |
2015-04-22
|
03 | Martin Stiemerling | Created "Approve" ballot |
2015-04-22
|
03 | Martin Stiemerling | Ballot writeup was changed |
2015-04-22
|
03 | Martin Stiemerling | Changed consensus to Yes from Unknown |
2015-04-16
|
03 | (System) | IESG state changed to Waiting for Writeup from In Last Call |
2015-04-08
|
03 | (System) | IANA Review state changed to IANA OK - No Actions Needed from IANA - Review Needed |
2015-04-08
|
03 | Pearl Liang | IESG/Authors/WG Chairs: IANA has reviewed draft-ietf-nfsv4-layout-types-03, which is currently in Last Call, and has the following comments: We understand that, upon approval of this … IESG/Authors/WG Chairs: IANA has reviewed draft-ietf-nfsv4-layout-types-03, which is currently in Last Call, and has the following comments: We understand that, upon approval of this document, there are no IANA Actions that need completion. While it is helpful for the IANA Considerations section of the document to remain in place upon publication, if the authors prefer to remove it, IANA doesn't object. If this assessment is not accurate, please respond as soon as possible. |
2015-04-02
|
03 | Tero Kivinen | Request for Last Call review by SECDIR is assigned to Joseph Salowey |
2015-04-02
|
03 | Tero Kivinen | Request for Last Call review by SECDIR is assigned to Joseph Salowey |
2015-03-28
|
03 | Gunter Van de Velde | Request for Last Call review by OPSDIR is assigned to Menachem Dodge |
2015-03-28
|
03 | Gunter Van de Velde | Request for Last Call review by OPSDIR is assigned to Menachem Dodge |
2015-03-27
|
03 | Jean Mahoney | Request for Last Call review by GENART is assigned to Meral Shirazipour |
2015-03-27
|
03 | Jean Mahoney | Request for Last Call review by GENART is assigned to Meral Shirazipour |
2015-03-26
|
03 | Amy Vezza | IANA Review state changed to IANA - Review Needed |
2015-03-26
|
03 | Amy Vezza | The following Last Call announcement was sent out: From: The IESG To: IETF-Announce CC: Reply-To: ietf@ietf.org Sender: Subject: Last Call: (Requirements for pNFS Layout Types) … The following Last Call announcement was sent out: From: The IESG To: IETF-Announce CC: Reply-To: ietf@ietf.org Sender: Subject: Last Call: (Requirements for pNFS Layout Types) to Informational RFC The IESG has received a request from the Network File System Version 4 WG (nfsv4) to consider the following document: - 'Requirements for pNFS Layout Types' as Informational RFC 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 2015-04-16. 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 provides help in distinguishing between the requirements for Network File System (NFS) version 4.1's Parallel NFS (pNFS) and those those specifically directed to the pNFS File Layout. The lack of a clear separation between the two set of requirements has been troublesome for those specifying and evaluating new Layout Types. As this document clarifies RFC5661, it effectively updates RFC5661. The file can be obtained via http://datatracker.ietf.org/doc/draft-ietf-nfsv4-layout-types/ IESG discussion can be tracked via http://datatracker.ietf.org/doc/draft-ietf-nfsv4-layout-types/ballot/ No IPR declarations have been submitted directly on this I-D. |
2015-03-26
|
03 | Amy Vezza | IESG state changed to In Last Call from Last Call Requested |
2015-03-26
|
03 | Martin Stiemerling | Last call was requested |
2015-03-26
|
03 | Martin Stiemerling | Ballot approval text was generated |
2015-03-26
|
03 | Martin Stiemerling | Ballot writeup was generated |
2015-03-26
|
03 | Martin Stiemerling | IESG state changed to Last Call Requested from AD Evaluation::AD Followup |
2015-03-26
|
03 | Martin Stiemerling | Last call announcement was changed |
2015-03-26
|
03 | Martin Stiemerling | Last call announcement was generated |
2015-03-26
|
03 | Martin Stiemerling | Last call announcement was generated |
2015-03-26
|
03 | Martin Stiemerling | WGLC done? |
2015-03-26
|
03 | Martin Stiemerling | IESG state changed to AD Evaluation::AD Followup from AD Evaluation::Point Raised - writeup needed |
2015-01-30
|
03 | Thomas Haynes | New version available: draft-ietf-nfsv4-layout-types-03.txt |
2015-01-30
|
02 | Martin Stiemerling | double-checking about the intendend status and the intention of this draft. |
2015-01-30
|
02 | Martin Stiemerling | IESG state changed to AD Evaluation::Point Raised - writeup needed from AD Evaluation |
2014-12-10
|
02 | Martin Stiemerling | IESG state changed to AD Evaluation from Publication Requested |
2014-11-18
|
02 | Spencer Shepler | Working Group: NFSv4 Area Director: Martin Stiemerling Document Author/Shepherd: Spencer Shepler (sshepler@microsoft.com) Internet Draft: Requirements for pNFS Layout Types draft-ietf-nfsv4-layout-types-02-shepherd.txt (1) What type … Working Group: NFSv4 Area Director: Martin Stiemerling Document Author/Shepherd: Spencer Shepler (sshepler@microsoft.com) Internet Draft: Requirements for pNFS Layout Types draft-ietf-nfsv4-layout-types-02-shepherd.txt (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? Informational RFC is being requested for this I-D. The purpose of this document was to clarify the requirements between parallel NFS (pNFS) and those for the pNFS File Layout Type. With new Layout Types being proposed, the working group desired to provide a document which clarifies what the new Layout Type specification must capture. (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 Internet-Draft outlines high-level requirements for the introduction of new Layout Types into parallel NFS (pNFS). In RFC5661, the delineation between the requirements for pNFS and the File Layout Type is not clear for all readers. This I-D clarifies the responsibilities of a generic Layout Type by examining all of the existing Layout Types, not just the File Layout Type. Working Group Summary: When discussing new proposed Layout Types, there was a lot of confusion about the role of a Control Protocol between the metadata server, the storage devices, and the clients. The casting of the Control Protocol as a set of requirements has reduced that confusion and has resulted in a broad consensus to support this I-D. Document Quality: This Internet Draft reviews and clarifies the requirements for creating a new Layout Type. It uses the three existing Layout Type specification as case studies to show that the requirements were issues considered during the creation of earlier Layout Types. I.e., it captures the relevancy of the requirements. The content of this document has received quality feedback and review throughout its life. Personnel: Spencer Shepler (NFSv4 WG co-chair) is the document shepherd Martin Stiemerling 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. The document shepherd has reviewed the document in full (intermediate drafts and the final version). This version is ready for IETF review and publication. (4) Does the document Shepherd have any concerns about the depth or breadth of the reviews that have been performed? The Requirements for pNFS Layout Types I-D covers the topic in the appropriate depth. It uses exisitng Layout Types as case studies to show the applicability of the requirements. (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 outstanding concerns exist 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. No outstanding concerns exist 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. No. No IPR disclosures have been filed in reference to this document. (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? There is solid working group consensus for this document. (10) Has anyone threatened an appeal or otherwise indicated extreme discontent? If so, please summarise the areas of conflict in separate email messages to the Responsible Area Director. (It should be in a separate email because this questionnaire is publicly available.) There is no threat of appeal in regards to this document or its contents. (11) Identify any ID nits the Document Shepherd has found in this document. (See http://www.ietf.org/tools/idnits/ and the Internet-Drafts Checklist). Boilerplate checks are not enough; this check needs to be thorough. There are informative reference issues but they can be handled during the IESG review process. (12) Describe how the document meets any required formal review criteria, such as the MIB Doctor, media type, and URI type reviews. Not applicable. (13) Have all references within this document been identified as either normative or informative? Yes. (14) Are there normative references to documents that are not ready for advancement or are otherwise in an unclear state? If such normative references exist, what is the plan for their completion? 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. Not applicable. (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. Not applicable. (17) Describe the Document Shepherd's review of the IANA considerations section, especially with regard to its consistency with the body of the document. Confirm that all protocol extensions that the document makes are associated with the appropriate reservations in IANA registries. Confirm that any referenced IANA registries have been clearly identified. Confirm that newly created IANA registries include a detailed specification of the initial contents for the registry, that allocations procedures for future registrations are defined, and a reasonable name for the new registry has been suggested (see RFC 5226). Not applicable. (18) List any new IANA registries that require Expert Review for future allocations. Provide any public guidance that the IESG would find useful in selecting the IANA Experts for these new registries. Not applicable. (19) Describe reviews and automated checks performed by the Document Shepherd to validate sections of the document written in a formal language, such as XML code, BNF rules, MIB definitions, etc. Not applicable. |
2014-11-18
|
02 | Spencer Shepler | Responsible AD changed to Martin Stiemerling |
2014-11-18
|
02 | Spencer Shepler | IETF WG state changed to Submitted to IESG for Publication from WG Document |
2014-11-18
|
02 | Spencer Shepler | IESG state changed to Publication Requested |
2014-11-18
|
02 | Spencer Shepler | IESG process started in state Publication Requested |
2014-11-18
|
02 | Spencer Shepler | Changed document writeup |
2014-11-18
|
02 | Spencer Shepler | Notification list changed to "Spencer Shepler" <spencer.shepler@gmail.com> |
2014-11-18
|
02 | Spencer Shepler | Document shepherd changed to Spencer Shepler |
2014-11-18
|
02 | Spencer Shepler | Intended Status changed to Informational from None |
2014-10-27
|
02 | Thomas Haynes | New version available: draft-ietf-nfsv4-layout-types-02.txt |
2014-09-22
|
01 | Thomas Haynes | New version available: draft-ietf-nfsv4-layout-types-01.txt |
2014-07-14
|
00 | Thomas Haynes | New version available: draft-ietf-nfsv4-layout-types-00.txt |