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 <[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 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.
>
_______________________________________________
Gen-art mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/gen-art
