Hi, Thanks for version -10. I appreciate the clarification to the title etc.
(All the same, a BCP is just as mandatory as a Draft Standard. But it's a judgment call, of course.) Regards Brian Carpenter On 30/08/2016 07:50, Adamson, Andy wrote: > >> On Aug 26, 2016, at 1:10 AM, Brian E Carpenter <[email protected]> >> wrote: >> >> I am the assigned Gen-ART reviewer for this draft. The General Area >> Review Team (Gen-ART) reviews all IETF documents being processed >> by the IESG for the IETF Chair. Please wait for direction from your >> document shepherd or AD before posting a new version of the draft. >> >> For more information, please see the FAQ at >> <http://wiki.tools.ietf.org/area/gen/trac/wiki/GenArtfaq>. >> >> Document: draft-ietf-nfsv4-multi-domain-fs-reqs-09.txt >> Reviewer: Brian Carpenter >> Review Date: 2016-08-26 >> IETF LC End Date: 2016-07-06 >> IESG Telechat date: 2016-09-01 >> >> Summary: Ready with issues >> -------- >> >> Comment: After my Last Call review I expected to see a new version, >> -------- but that hasn't happened yet. > > Hi Brian > > Thanks for the review. I left draft-09 until I heard other comments. > >> >> >> Minor issue: >> ------------ >> >> "This document provides guidance on the deployment of..." >> >> I understand that the AD suggested the standards track, but the document >> reads more like a BCP than a Proposed Standard to me. As I read through the >> document, it describes alternatives and differing scenarios. > > > This latest round of comments - including the SecDir review from Russ Housley > shows that there is still an impedence mis-match between the title/abstract > and the intended status of Standards Track versus an Informational draft or > best practices. > > I feel that the use of "Guidelines" in the title, and "guidance" in the > abstract point to an Informational draft rather than a Standards track. > > This draft is a Proposed Standard (not an Informational or BCP) because the > MUST and REQUIRED noted in section 6 of the doc are absolute requirements for > an NFSv4 multi-domain file name space to work. These can not be BCP as an > NFSv4 multi-domain file name space will _not_ work without these requirements. > > I have completed a draft-ietf-nfsv4-multi-domain-fs-reqs-10 with the > following changes: > > 1) The title to be changed from > > "Multiple NFSv4 Domain Namespace Deployment Guidelines" > > to > > "Multiple NFSv4 Domain Namespace Deployment Requirements" > > > 2) The first sentence in the abstract (and in the introduction) to be changed > from > > This document provides guidance on the deployment of the NFSv4 > protocols for the construction of an NFSv4 file name space in > environments with multiple NFSv4 Domains. > > to > This document presents requirements on the deployment of the NFSv4 > protocols for the construction of an NFSv4 file name space in > environments with multiple NFSv4 Domains. > > > Another common area of comment concerned the “Stand-alone Examples" examples > section 5 and "Stand-alone Examples and Multiple NFSv4 Domain Namespaces” > section 8. These section describe "alternatives and differing scenarios” to > highlight the need for the requirements described in section 6. > > I addressed the example sections comments by adding clarifying text to each > of these sections as well as moving the second section from 8 to section 7. > > I have also addressed the remaining comments from Brian, Russ, Alexey > Melnikov, and Kathleen Moriarty. > > I’ll upload the new draft soon. > > —>Andy > >> >> Nits: >> ----- >> >> ** Downref: Normative reference to an Informational RFC: RFC 1813 >> >> This reference was added in the -09 version. I believe it should be >> Informative instead of Normative. >> >> ** Obsolete normative reference: RFC 1831 (Obsoleted by RFC 5531) >> >> This needs to be fixed. > _______________________________________________ Gen-art mailing list [email protected] https://www.ietf.org/mailman/listinfo/gen-art
