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

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

Hi,

So we have this in the minutes:

> Get status - is it in WG last call. Should it be informational
> or standards draft. Draft clarifies how make all this work.

...i.e. it describes best practice, not protocol details.

> 
> 2119 MUSTs, SHOULDs and MAYs can be used in an informational draft
> says David Black. 

They can, but they are a clear signal to think carefully.

> Martin thinks its wise to put on standards track.

In the end it's a judgment call, of course, but "make this all work"
is surely the goal of most BCPs?

Regards
    Brian




Regards
   Brian Carpenter
   http://orcid.org/0000-0001-7924-6182



On 12/07/2016 02:47, Adamson, Andy wrote:
> 
>> On Jul 5, 2016, at 11:54 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 treat these comments just
>> like any other last call comments.
>>
>> 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-07-05
>> IETF LC End Date: 2016-07-06
>> IESG Telechat date:
>>
>> Summary: Ready with issues
>> --------
>>
>> Comment: I was asked to review -08 but found -09 has been posted, with
>> -------- considerable changes, during Last Call.
>>
>>
>> Minor issues:
>> -------------
>>
>> "This document provides guidance on the deployment of..."
>>
>> Sounds more like a BCP than a Proposed Standard to me.
> 
> 
> Hi Brian
> 
> The “Informational vrs Standards” track issue was discussed at IETF93. From the minutes at https://datatracker.ietf.org/doc/minutes-93-nfsv4/
> 
> -- Multidomain draft (Adamson)
> 
> No slides.
> 
> Similar to layout types. Clarifying issues in NFS V4.0 and 4.1,
> especially with FedFS.
> 
> Get status - is it in WG last call. Should it be informational
> or standards draft. Draft clarifies how make all this work.
> 
> 2119 MUSTs, SHOULDs and MAYs can be used in an informational draft
> says David Black. Martin thinks its wise to put on standards track.
> No errata to speak of - just additional information.
> 
> ----------------
> 
>>  As I read through the
>> document, it describes alternatives and differing scenarios. That also seems
>> like BCP to me. One example:
>>
>>> 7.  Resolving Multi-domain Authorization Information
>>>
>>>  When an RPCSEC_GSS principal is seeking access to files on an NFSv4
>>>  server, after authenticating the principal, the server must obtain in
>>>  a secure manner the principal's authorization context information
>>>  from an authoritative source such as the name service in the
>>>  principal's NFSv4 Domain.
>>
>> That's underspecified for a standard but perfect for a description of
>> best practice.
> 
> I propose to change the above ‘must’ to a ’SHOULD’. The above actually applies to an NFSv4 server using RPCSEC_GSS in any environment as it does no good (e.g. it is insecure) to establish the authentication of a principal in a secure manner, and to then map that principal to local file system representation authorization info for file access determination in an insecure manner.
> 
> I thought this was specified in previous standards - but I can’t find mention of any requirement for security in gathering  authorization information on an RPCSEC_GSS authenticated principal anywhere in RFC7530, RFC5661 nor in the FedFS RFC’s. Section 5.9 of RFC 7530 discusses the translation of security principals into " a common format, generally that used by local storage, to serve as a means of identifying the users corresponding to these security principals.”  but makes no mention of requiring a secure translation method.
> 
> The only mention I find is in the Security Considerations section of draft-cel-nfsv4-federated-fs-security-addendum-05 which states:
> 
> "When deploying FedFS, the use of security mechanisms that maintain
>    the confidentiality of all network communications is recommended."
> 
>>
>> The choices between lower-case and upper-case "must" seem fairly arbitrary.
>> There are only 5 instances of "MUST" and one "REQUIRED". Maybe this document just
>> doesn't need RFC2119 keywords?
> 
> The doc definitely needs RFC2119 keywords - as the MUST and REQUIRED noted in the doc are absolute requirements for an NFSv4 multi-domain file name space to work.
> 
> 
>>  ** 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.
> 
> It is an informative reference. I’ll fix it.
> 
> —>Andy
> 
>> If not, a new Last Call mentioning
>> the downref is necessary.
>>
>>  ** Obsolete normative reference: RFC 1831 (Obsoleted by RFC 5531)
>>
>> This needs to be fixed.
>