Re: [Gen-art] Gen-ART telechat review of draft-ietf-nfsv4-multi-domain-fs-reqs-09

[Brian E Carpenter <[e-mail]>]

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 <[e-mail]> 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.
>