Re: [Gen-art] Gen-art LC review of draft-ietf-nfsv4-minorversion2-39

["Adamson, Andy" <[e-mail]>]

> On Jan 5, 2016, at 12:31 PM, Elwyn Davies <[e-mail]> wrote:
> Hi.
> 
> One oops: The comment for rpcsec-gssv3 should apply to s2.7.1.4 and not s2.3.1.4.

No problem - I noticed that. 
> 
> On 04/01/2016 16:44, Adamson, Andy wrote:
>>> On Jan 1, 2016, at 7:18 PM, Elwyn Davies <[e-mail]> wrote:
>>> 
>>> Hi.
>>> 
>>> Happy New Year!
>> Happy New Year :)
>>> I trust you have had a good break.  Now back to the action...
>>> 
>>> Regarding the definition of 'structured privilege'... I ascertained that 'structured privilege' entered the story at v05 of rpsec_gssv3 so I trawled through the nfsv4 mail archive around the time of -05's genesis to see how this came about.
>>> 
>>> At the end of a fairly lengthy thread on "Soliciting next steps for RPCSEC_GSSv3", I was amused to see that message
>>> https://mailarchive.ietf.org/arch/msg/nfsv4/zpEIx3aC6bwNWQSQ1rjfxqli8nE
>>> ends with Andy asking exactly the same question as I did :-)))
>>>> Where can I find the definition of "structured privilege"? A quick
>>>> google search just turns up a SAP HANA reference ;)
>>> I had actually turned up the same SAP HANA ref.. Having read all this I think I understand that I was trying to read more into the the term than is intended. My understanding is that it just implies that there is an agreed data structure that is associated with a privilege assertion defined by whatever application intends to use the privilege and known to both client and server that support the relevant application.
>>> 
>>> Assuming this is correct I suggest redrafting s 1.1 (bullet 2) and s2.3.1.4 of rpcsec-gssv3-05 as follows:
>>> For s1.1, bullet 2:
>>> OLD:
>>>   o  Application-specific structured privileges.  For an example see
>>>      server-side copy [NFSv4.2].
>>> NEW:
>>>   o  Application-specific structured privileges.  These allow a RPC
>>>      application client to pass structured information to the
>>>      corresponding application code in a server to control the
>>>      applicability of the privilege and/or the conditions in which
>>>      the privilege may be exercised.  For an example see
>>>      server-side copy [NFSv4.2].
>>> END
>>> 
>>> For s2.3.1.4, para after code:
>>> 
>>> OLD:
>>>   A structured privilege is an RPC application defined privilege.
>>>   RPCSEC_GSSv3 clients MAY assert a structured privilege by binding the
>>>   privilege to the RPCSEC_GSSv3 context handle.  This is done by
>>>   including an assertion of type rgss3_privs in the RPCSEC_GSS_CREATE
>>>   rgss3_create_args rca_assertions call data.  Encoding, server
>>>   verification and any policies for structured privileges are described
>>>   by the RPC application definition.
>>> NEW:
>>>   A structured privilege is a capability defined by a specific RPC
>>>   application.  To support the assertion of this privilege, by a client
>>>   using the application, in a server that also supports the application,
>>>   the application may define a private data structure that is understood
>>>   by clients and servers implementing the RPC application.
>>> 
>>>   RPCSEC_GSSv3 clients MAY assert a structured privilege by binding the
>>>   privilege to the RPCSEC_GSSv3 context handle.  This is done by
>>>   including an assertion of type rgss3_privs in the RPCSEC_GSS_CREATE
>>>   rgss3_create_args rca_assertions call data.
>>> 
>>>   The privilege is identified by the description string that is used by
>>>   RPCSEC_GSSv3 to identify the privilege and communicate the private data
>>>   between the relevant RPC application-specific code without needing to
>>>   be aware of the details of the structure used.  Thus, as far as
>>>   RPCSEC_GSSv3 is concerned, the defined structure is passed between client
>>>   and server as opaque data  encoded in the rpc_gss3_privs rp_privilege field.
>>> 
>>>   Encoding, server verification and any server policies for structured
>>>   privileges are described by the RPC application definition.  The
>>>   rp_name field of rpc_gss3_privs carries the description string used to
>>>   identify and list the privilege.
>>> END
>> 
>> That is quite complete and very clear. Thanks!
> :-) .. and it is fpr s2.7.1.4 as mentioned above.

>>> Assuming the RPCSEC_GSS_CREATE call can carry multiple label specifications and structured privilege assertions, I am not clear how a client would discover which label or which assertion caused an error, if the server rejects the creation.
>> You are partially correct.
>> 
>> For labels: a set of labels is sent to the server. The labels that are accepted by the server MUST be enumerated in the rcr_assertions field of the rgss3_create_res RPCSEC_GSS_CREATE reply. So those that fail will not be enumerated.
>> The RPCSEC_GSS_LABEL_PROBLEM AUTH_ERROR is used only if the server does not support labeling, or that does not support labeling under the LSF. The client can get a list of supported LSF’s with the RPCSEC_GSS_LIST operation.
>> So we do know which label(s) were not accepted.
>> 
>> For structured privileges, the client needs to assert the RPC application defined privilege - a partial success does not seem useful to me. It is true that a rejection of a structured privilege due to verification failure returns the RPCSEC_GSS_PRIVILEGE_PROBLEM AUTH_ERROR, so if there are multiple structured privileges in one RPCSEC_GSS_CREATE payload, you will not know which one failed. I don’t think this is a problem as it should be an all or nothing assertion.
>> 
> Thanks for the explanation.  Can I suggest that this could be made more explicit by slightly modifying the text of the next to last para of s2.7.1.4:
> OLD;
>   If a server receives a structured privilege assertion that it fails
>   to verify according to the requirements of the RPC application
>   defined behavior, the assertion is rejected with a reply status of
>   MSG_DENIED, a reject_status of AUTH_ERROR, and an auth_stat of
>   RPCSEC_GSS_PRIVILEGE_PROBLEM.
> NEW:
>   It is assumed that a client asserting more than one privilege to
>   be bound to a context handle would require all the privilege
>   assertions to succeed.
> 
>   If a server receives an RPCSEC_GSS_CREATE request containing one
>   or more  structured privilege assertions, any of which it fails
>   to verify according to the requirements of the RPC application
>   defined behavior, the request is rejected with a reply status of
>   MSG_DENIED, a reject_status of AUTH_ERROR, and an auth_stat of
>   RPCSEC_GSS_PRIVILEGE_PROBLEM.
> END
>>> 
>>> =======
>>> 
>>> At the other end of this in minorversion2-39,  some minor updates to s4.10.1.1 should be  made to tie in with this definition.  In particular minorversion3 needs to specify how the data structure is encoded - RPCSEC_GSSv3 doesn't know or care since it is treated at as opaque data at the GSS level.  Clearly it is intended that XDR encoding is used but this should be stated explicitly.   I suggest adding a new para after the existing para 3 and making it clear that the string at the beginning of each section is passed in the rp_name field (also alter the "We define" which is not the correct style) :
>>> OLD (para 4):
>>> 
>>>   We define three RPCSEC_GSSv3 structured privilege assertions that
>>>   work in tandem to authorize the copy:
>>> 
>>> NEW:
>>>   For each structured privilege assertion defined by a RPC application
>>>   RPCSEC_GSSv3 requires the application to define a name string and a
>>>   data structure that will be encoded and passed between client and server
>>>   as opaque data.  For NFSv4 the data structures specified below MUST
>>>   be serialized using XDR.
>>> 
>>>   Three RPCSEC_GSSv3 structured privilege assertions that
>>>   work together to authorize the copy are defined here.  For each of
>>>   the assertions the description starts with the name string passed in
>>>   the rp_name field of the rgss3_privs structure defined in
>>>   Section 2.7.1.4 of [rpcsec_gssv3] and specifies the XDR encoding of
>>>   the associated structured data passed via the rp_privilege field of
>>>   the structure.
>>> END

I like it. 


>>> 
>>> A question that occurred to me:  MUST a server support all three assertion types if supports any?
>> Yes. The Security Considerations comments on this issue:
>> 
>> 4.10.  Security Considerations
>> 
>> ….
>> 
>>  If the server-to-
>>    server copy protocol is ONC RPC based, the servers are also REQUIRED
>>    to implement [rpcsec_gssv3] including the RPCSEC_GSSv3 copy_to_auth,
>>    copy_from_auth, and copy_confirm_auth structured privileges.
>> 
>> Is the above clear enough?
> Sorry - I missed that comment.  However, it would appear to be logically possible to have source only and destination only servers.  I think a source server would only need to implement copy_from_auth and copy_confirm_auth whereas the destination server would only need to implement copy_to_auth.  Whether this is something that an implementer would wish to allow is beyond the scope of my knowledge but I could see that it might be something that might be interesting if the roles of servers need to be constrained.  Thus it seems to me that requiring that all three are implemented is not essential.  Alternatively, there could be an option to always implement, but set a policy that always denies privileges not appropriate to the defined role of the server.

Well, I think it wiser to have it all or none - e.g. to always implement, and let the policy define privileges appropriate to the role of the server. Furthermore, once one structured privilege is coded, the others are not that big a deal. So I think the existing text is good. 


>> 
>> Thanks again for the review
> :-)
> Will you be updating again before the IESG review on Thursday?  I have to write a Telechat review...
> 
> Cheers,
> Elwyn
>> 
>> —>Andy
>> 
>> 
>>> I spotted a nit in this area that I missed on the previous pass:
>>> s4.10.1.1, para 3: s/This features allow/This feature allows/
>>> 
>>> I also missed a number of instances (17, I think) of the "we <do something>" construction familiar from scientific papers.
>>> (There was one in the paragraph changed above).  This is not appropriate phraseology for an RFC and needs to be
>>> changed to avoid the "we", e..g.,
>>> s1.4.5: s/We introduce WRITE_SAME (see Section 15.12)/The WRITE_SAME operation (see Section 15.12) is introduced/
>>> 
>>> Regards,
>>> Elwyn
>>> 
>>> 
>>> 
>>> 
>>> 
>>> 
>>> On 22/12/2015 16:27, Adamson, Andy wrote:
>>>>> On Dec 22, 2015, at 10:30 AM, Adamson, Andy<[e-mail]>  wrote:
>>>>> 
>>>>>> On Dec 18, 2015, at 11:28 PM, Tom Haynes<[e-mail]>  wrote:
>>>>>> 
>>>>>> 
>>>>>>> On Dec 13, 2015, at 11:22 AM, Elwyn Davies<[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-minorversion2-39.txt
>>>>>>> Reviewer: Elwyn Davies
>>>>>>> Review Date: 2015-12-13
>>>>>>> IETF LC End Date: 2015-12-09
>>>>>>> IESG Telechat date: (if known) -
>>>>>>> 
>>>>>>> Summary: Almost ready.  There are a fair number of minor nits and editorial suggestions.  The couple of 'minor issues' are predominantly questions that came into my mind that might be interesting to a reader/implementer but are probably unlikely to affect the performance of the protocol.  However, the comments on s11.2, s12.1, s13 and s15.2.3 appear to be actual omissions or errors.
>>>>>>> 
>>>>>>> Major issues:
>>>>>>> None.
>>>>>>> 
>>>>>> Hi Elwyn,
>>>>>> 
>>>>>> Thanks as always for making me think!
>>>>>> 
>>>>>> Replies are inline, I have some questions for you and Andy.
>>>>>> 
>>>>>> Hi Andy,
>>>>>> 
>>>>>> There is a question about Inter-Server Copy Security below!
>>>>>> 
>>>>>> 
>>>>>>> Minor issues:
>>>>>>> s4:  There is no discussion in s4 of the Named Attributes associated with a file and the restriction of server-to-server copy to 'regular files' seems to indicate that Named Attributes cannot be copied by this mechanism.  Is there anything to be said about getting the Named Attributes across?
>>>>>> Actually, from Section 5.8.1.2 of RFC 5661:
>>>>>> 
>>>>>>   o  The phrases "is an ordinary file" and "is a regular file" mean
>>>>>>      that the object's type attribute is NF4REG or NF4NAMEDATTR.
>>>>>> 
>>>>>> (I’ll quote from RFC 5661 and not RFC 7530 because of the pnfs aspects.)
>>>>>> 
>>>>>>> s4/s9:  Does server-to-server copy interact (badly, or otherwise) with Labeled NFS?  Nothing is said, but I wonder whether there are issues around atomicity and MAC between the different servers for inter-server copy.
>>>>>> Good question - I think even though we’ve published the Labeled NFS to allow for heterogeneous MAC deployments, sites are going to run a specific variant.
>>>>>> 
>>>>>> In that model, I would expect the object label to travel with the object and still be applied on the destination until modified by someone with those capabilities.
>>>>>> 
>>>>>> For the other model, the object label would control whether the file could be copied to another system or not. And if that system had a different MAC model, then according to the requirements in Section 3.3 of RFC 7204:
>>>>>> 
>>>>>>   A negotiation scheme SHOULD be provided, allowing systems from
>>>>>>   different Label Formats to agree on how they will interpret or
>>>>>>   translate each other's foreign labels.  Multiple concurrent
>>>>>>   agreements may be current between a server and a client.
>>>>>> 
>>>>>> 
>>>>>> 
>>>>>>> s4.10.1.1.1: Size and reuse for random number used as a shared secret for inter-server copy.
>>>>>>> No advice is given on the desirable size/length of the random number or the risks or otherwise of reusing the same context for multiple file copies.  This maybe a non-issue - I defer to those with more security clue than me.
>>>>>> Back to RFC 7530, 3.2.1.1, when we had a similar discussion in the WG about the required algorithms fodeplying Kerberos:
>>>>>> 
>>>>>>   At the time this document was specified, the Advanced Encryption
>>>>>>   Standard (AES) with HMAC-SHA1 was a required algorithm set for
>>>>>>   Kerberos V5.  In contrast, when NFSv4.0 was first specified in
>>>>>>   [RFC3530], weaker algorithm sets were REQUIRED for Kerberos V5, and
>>>>>>   were REQUIRED in the NFSv4.0 specification, because the Kerberos V5
>>>>>>   specification at the time did not specify stronger algorithms.  The
>>>>>>   NFSv4 specification does not specify required algorithms for Kerberos
>>>>>>   V5, and instead, the implementer is expected to track the evolution
>>>>>>   of the Kerberos V5 standard if and when stronger algorithms are
>>>>>>   specified.
>>>>>> 
>>>>>> 3.2.1.1.1.  Security Considerations for Cryptographic Algorithms in
>>>>>>            Kerberos V5
>>>>>> 
>>>>>>   When deploying NFSv4, the strength of the security achieved depends
>>>>>>   on the existing Kerberos V5 infrastructure.  The algorithms of
>>>>>>   Kerberos V5 are not directly exposed to or selectable by the client
>>>>>>   or server, so there is some due diligence required by the user of
>>>>>>   NFSv4 to ensure that security is acceptable where needed.  Guidance
>>>>>>   is provided in [RFC6649] as to why weak algorithms should be disabled
>>>>>>   by default.
>>>>>> 
>>>>>> I.e., I would prefer to not specify a policy on size and reuse of the random number as a shared secret. Well, strike that, the random number should not be reused and the length is determined by the algorithm used to generate that secret.
>>>>>> 
>>>>>> I can craft text to that effect.
>>>>>> 
>>>>>> 
>>>>>>> Nits/editorial comments:
>>>>>>> General: bytes or octets?
>>>>>> RFC 5661:
>>>>>> 
>>>>>>   Byte:  In this document, a byte is an octet, i.e., a datum exactly 8
>>>>>>      bits in length.
>>>>>> 
>>>>>> So bytes.
>>>>>> 
>>>>>>> Abstract: Probably ought to expand i/O.
>>>>>> done
>>>>>> 
>>>>>>> s1/s1.1: I think you could safely delete the s1.1 header leaving the text as the body of s1 - this is generally considered better practice than leaving s1 itself empty.
>>>>>> done
>>>>>> 
>>>>>> 
>>>>>>> s1.2, 3rd bullet: s/protocols.  I.e.,/protocols, that is/; s/apply/apply only/
>>>>>> Done
>>>>>> 
>>>>>> 
>>>>>>> s1.4:  The overview doesn't cover the two LAYOUT related operations and there is is no section describing what their usage might be in with sections 4-10.
>>>>>>> 
>>>>>> 1.3.7.  Layout Enhancements
>>>>>> 
>>>>>>   In the parallel NFS implementations of NFSv4.1 (see Section 12 of
>>>>>>   [RFC5661]), the client cannot communicate back to the metadata server
>>>>>>   any errors or performance characteristics with the storage devices.
>>>>>>   NFSv4.2 provides two new operations to do so respectively: LAYOUTERROR
>>>>>>   (see Section 15.6) and LAYOUTSTATS (see Section 15.7).
>>>>>> 
>>>>>>> s1.4: Similarly, there is noting about the CLONE operation.
>>>>>> 1.3.1.  Server Side Clone and Copy
>>>>>> 
>>>>>>   A traditional file copy of a remotely accessed file, whether from one
>>>>>>   server to another or between locations in the same server, results in
>>>>>>   the data being put on the network twice - source to client and then
>>>>>>   client to destination.  New operations are introduced to allow
>>>>>>   unnecessary traffic to be eliminated:
>>>>>> 
>>>>>>   o  The intra-server clone feature allows the client to request a
>>>>>>      synchronous cloning, perhaps by copy-on-write semantics.
>>>>>> 
>>>>>>   o  The intra-server copy feature allows the client to request the
>>>>>>      server to perform the copy internally, avoiding unnecessary
>>>>>>      network traffic.
>>>>>> 
>>>>>>   o  The inter-server copy feature allows the client to authorize the
>>>>>>      source and destination servers to interact directly.
>>>>>> 
>>>>>>> s1.4.1, para 1: s/remotely accessed/remotely accessed file/; s/location/locations/
>>>>>> done
>>>>>> 
>>>>>>> s1.4.1: (very nitty!) Suggest making the descriptions of the two cases (intra- and inter-server) into bulleted paragraphs to make it clearer that they are separate features.
>>>>>>> 
>>>>>> Done
>>>>>> 
>>>>>> 
>>>>>> 
>>>>>>> s1.4.2: (as with the Abstract) expand I/O on first occurrence.
>>>>>> Done
>>>>>> 
>>>>>>> s1.4.2: It would be worth putting in the reference for posix_fadvise here.
>>>>>> Done
>>>>>> 
>>>>>>> s1.4.3: If you write the data in the hole, it isn't really a hole ;-) ….
>>>>>> Ha!
>>>>>> 
>>>>>>> OLD:
>>>>>>> Such holes are typically transferred as 0s during I/O.
>>>>>>> NEW:
>>>>>>> Such holes are typically transferred as 0s when read from the file.
>>>>>>> END
>>>>>> Done
>>>>>> 
>>>>>>> s1.5: Suggest s/I.e., READ becomes either/For instance, READ would have to be replaced or supplemented by, say, either/
>>>>>> Done
>>>>>> 
>>>>>>> s2, last bullet: Need to expand pNFS on first use (and maybe remind readers that it is a feature of NFS4.1 - Section 12 of RFC 5661)
>>>>>> Done
>>>>>> 
>>>>>>> s2, last bullet: s/metadata sever/metadata server/ - again a pointer to (say) Sections 1.7.2.2 and 12.2.2 of RFC 5661 would clarify what a metadata server is.
>>>>>>> 
>>>>>> Done
>>>>>> 
>>>>>>> s4.2.1:  The first para reads:
>>>>>>> OLD:
>>>>>>>  COPY_NOTIFY:  Used by the client to notify the source server of a
>>>>>>>     future file copy from a given destination server for the given
>>>>>>>     user.  (Section 15.3)
>>>>>>> 
>>>>>>> I completely misread this on first pass, but I understand that it is correct.  Having checked with s15.3 and thought a bit more about it, it is the 'copy from a given destination' that threw me - I guess it means 'the copy will be made from' rather than 'the file being copied from the destination'... Doh!
>>>>>>>> A client sends this
>>>>>>>>   operation in a COMPOUND request to the source server to authorize a
>>>>>>>>   destination server identified by cna_destination_server to read the
>>>>>>>>   file specified by CURRENT_FH on behalf of the given user.
>>>>>>> I suggest the following might be avoid this brain fade:
>>>>>>> NEW:
>>>>>>>  COPY_NOTIFY:  Used by the client to request the source server to authorize a
>>>>>>>     future file copy that will be made by a given destination server on behalf of the given
>>>>>>>     user.  (Section 15.3)
>>>>>>> END
>>>>>> done
>>>>>> 
>>>>>>> s4.2.2, para 5:  s/support all these operations/support these operations/ ('all' is confusing given that only two are then explicitly mentioned).
>>>>>>> 
>>>>>> done - BTW note that we had some WG revisions made to introduce the CLONE operation here. Those
>>>>>> changes are considered part of this review cycle. In other words, please let me know when you want
>>>>>> a revised draft copy published.
>>>>>> 
>>>>>> 
>>>>>>> s4.3, para 1:  s/Inter-server copy is driven/The specification of inter-server copy is driven/
>>>>>>> 
>>>>>> done
>>>>>> 
>>>>>>> s4.4.1, last para: s/The source MUST equate/The source MUST interpret/
>>>>>> done
>>>>>> 
>>>>>>> s4.6/Figures 4 and 5: Need a 'key' to explain os1 and os2.
>>>>>> Done in that I expanded the names in the figure and also made it clear which wa being released
>>>>>> 
>>>>>>> s4.7.2:  Adding a reference to Section 15.3(.3) would help.
>>>>>> Went with 15.3 - let me know if you’d like 15.3.3 better.
>>>>>> 
>>>>>> 
>>>>>>> s4.7.3, para 2: idnits identifies RFC 2616 as obsoleted by RFC 7230, etc.  A more recent ref is desirable.
>>>>>> Done
>>>>>> 
>>>>>>> s4.8, para after code fragment: LDAP and NIS  need to be expanded (DNS and URL are well-known).
>>>>>> Done
>>>>>> 
>>>>>>> s4.9, para 3: Is it possible to add a little explanation as to *why* seqid = 0 is ambiguous?  My limited knowledge doesn't grok this.
>>>>>>> 
>>>>>> The stateid might be that of a lock, which has the provision that it cannot be 0
>>>>>> 
>>>>>> Section 8.2.2 of RFC 5661:
>>>>>> 
>>>>>>   When such a set of locks is first created, the server returns a
>>>>>>   stateid with seqid value of one.  On subsequent operations that
>>>>>>   modify the set of locks, the server is required to increment the
>>>>>>   "seqid" field by one whenever it returns a stateid for the same
>>>>>>   state-owner/file/type combination and there is some change in the set
>>>>>>   of locks actually designated.  In this case, the server will return a
>>>>>>   stateid with an "other" field the same as previously used for that
>>>>>>   state-owner/file/type combination, with an incremented "seqid" field.
>>>>>>   This pattern continues until the seqid is incremented past
>>>>>>   NFS4_UINT32_MAX, and one (not zero) is the next seqid value.
>>>>>> 
>>>>>> Let me know if you want a citation here (and a little bit of explanatory text).
>>>>>> 
>>>>>> Note, RFC 5661 uses “zero” and not “0”. I’ve changed this text to match.
>>>>>> 
>>>>>>> s4.10: Is it possible to provide an abstract definition of 'structured privilege'?  The rpcsec-gssv3 draft appears to punt on this, pointing to the 'example' in the NFSv4.2 draft.
>>>>>>> I think I get the idea but a succinct definition would help I believe.   I guess the definition ought to be in the rpcsec-gss document and referenced from this doc.
>>>>>>> 
>>>>> The succinct definition is here:
>>>>> 
>>>>> From draft-ietf-nfsv4-rpcsec-gssv3-14 Section 2.7.1.4.  Structured Privilege Assertions first sentence, first paragraph:
>>>>> 
>>>>> "A structured privilege is an RPC application defined privilege.”
>>>>> 
>>>>> and at the end of the first paragraph:
>>>>> 
>>>>> "Encoding, server verification and any policies for structured privileges are described by the RPC application definition.”
>>>>> 
>>>>> NFSv4.2 is the RPC application that defines the inter server to server copy structured privileges.
>>>>> 
>>>>> There is really nothing else to add to the definition.
>>>>> 
>>>>>> ^^ Andy???
>>>>>> 
>>>>>> 
>>>>>>> s4.10.1.1.1, 2nd bullet: Need to expand QOP.
>>>>>> Andy, RFC 2203 uses this term, but does not expand it.
>>>>> Actually, it does in a very round-about manner.
>>>>> 
>>>>> rfc2203:
>>>>> 
>>>>> 5.2.1.  Mechanism and QOP Selection
>>>>> 
>>>>>   There is no facility in the RPCSEC_GSS protocol to negotiate GSS-API
>>>>>   mechanism identifiers or QOP values. At minimum, it is expected that
>>>>>   implementations of the RPCSEC_GSS protocol provide a means to:
>>>>> 
>>>>>   *    specify mechanism identifiers, QOP values, and RPCSEC_GSS
>>>>>        service values on the client side, and to
>>>>> 
>>>>>   *    enforce mechanism identifiers, QOP values, and RPCSEC_GSS
>>>>>        service values on a per-request basis on the server side.
>>>>> 
>>>>>   It is necessary that above capabilities exist so that applications
>>>>>   have the means to conform the required set of required set of
>>>>>   <mechanism, QOP, service> tuples (See the section entitled Set of GSS-API Mechanisms).
>>>>>                                                          ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
>>>>> 
>>>>> 6.  Set of GSS-API Mechanisms
>>>>> 
>>>>>   RPCSEC_GSS is effectively a "pass-through" to the GSS-API layer, and
>>>>>   as such it is inappropriate for the RPCSEC_GSS specification to
>>>>>   enumerate a minimum set of required security mechanisms and/or
>>>>>   quality of protections.
>>>>> 
>>>>> so QOP is "Quality of Protection"
>>>>> 
>>>>>> And RFC 5403 does not use it.
>>>>>> 
>>>>>> It is a field in one of the structures?
>>>>> Here is are some references:
>>>>> 
>>>>> rfc2743  "Generic Security Service Application Program Interface Version 2, Update 1"
>>>>> 
>>>>> 
>>>>> Section 1.2.4:  Quality of Protection
>>>>> 
>>>>>   Some mech_types provide their users with fine granularity control
>>>>>   over the means used to provide per-message protection, allowing
>>>>>   callers to trade off security processing overhead dynamically against
>>>>>   the protection requirements of particular messages. A per-message
>>>>>   quality-of-protection parameter (analogous to quality-of-service, or
>>>>>   QOS) selects among different QOP options supported by that mechanism.
>>>>>   On context establishment for a multi-QOP mech_type, context-level
>>>>>   data provides the prerequisite data for a range of protection
>>>>>   qualities.
>>>>> 
>>>>> 
>>>>> 
>>>>> 
>>>>> rfc4121: "The Kerberos Version 5 Generic Security Service Application Program Interface (GSS-API) Mechanism: Version 2"
>>>>> 
>>>>> Section 3.  Quality of Protection
>>>>> 
>>>>> 
>>>>>   The GSS-API specification [RFC2743] provides Quality of Protection
>>>>>   (QOP) values that can be used by applications to request a certain
>>>>>   type of encryption or signing.  A zero QOP value is used to indicate
>>>>>   the "default" protection; applications that do not use the default
>>>>>   QOP are not guaranteed to be portable across implementations, or even
>>>>>   to inter-operate with different deployment configurations of the same
>>>>>   implementation.  Using a different algorithm than the one for which
>>>>>   the key is defined may not be appropriate.  Therefore, when the new
>>>>>   method in this document is used, the QOP value is ignored.
>>>>> 
>>>>>            ……...
>>>>> 
>>>>> 
>>>>>>> s4.10.1.2, para 2: s/uiniquely/uniquely/
>>>>>> Done
>>>>>> 
>>>>>>> s5, title: s?IO?I/O?
>>>>>> fixed
>>>>>> 
>>>>>>> s6.1: This heading could be deleted turning the text in 6.1 into Section 6 which is then not empty.
>>>>>>> 
>>>>>> Done
>>>>>> 
>>>>>> 
>>>>>>> s6.1: The term 'inode' is used four times in this section.  Whilst this is well understood, it is strictly associated with *nix file systems. It would be desirable to find an alternative term or, if you can't think of suitable short generic term (I spent a little time thinking about it and couldn't think of one immediately), some weasel words added to the first occurrence saying that it is intended to cover equivalent structures in other sorts of filing system.
>>>>>> Let me try to weasel!
>>>>>> 
>>>>>> I’ve related it to metadata.
>>>>>> 
>>>>>> 
>>>>>>> s6.1, para 2: s/can thought as holes/can thought of as holes/
>>>>>> can be thought of as holes
>>>>>> 
>>>>>> 
>>>>>>> s6.1, para 4:  s/couple/few/  ('couple hundred' is a USA specific colloquialism - UK would use 'couple of’)
>>>>>> done
>>>>>> 
>>>>>>> s6.1, last para: s/punching.  I.e., an application/punching, where an application/
>>>>>>> 
>>>>>> done
>>>>>> 
>>>>>> 
>>>>>>> s7, para 1: s/One example is the posix_fallocate/One example is the posix_fallocate operation/
>>>>>>> 
>>>>>> Done
>>>>>> 
>>>>>>> s7
>>>>>>> OLD:
>>>>>>>  space_freed  This attribute specifies the space freed when a file is
>>>>>>>     deleted, taking block sharing into consideration.
>>>>>>> NEW:
>>>>>>>  space_freed  This attribute reports the space that would be freed when a file is
>>>>>>>     deleted, taking block sharing into consideration.
>>>>>> Done
>>>>>> 
>>>>>> 
>>>>>>> s8, bullet #2:
>>>>>>> I found the 2nd sentence hard to parse.  Suggested alternative below.
>>>>>>> OLD:
>>>>>>>  2.  Fields to describe the state of the ADB and a means to detect
>>>>>>>      block corruption.  For both pieces of data, a useful property is
>>>>>>>      that allowed values be unique in that if passed across the
>>>>>>>      network, corruption due to translation between big and little
>>>>>>>      endian architectures are detectable.  For example, 0xF0DEDEF0 has
>>>>>>>      the same bit pattern in both architectures.
>>>>>>> NEW:
>>>>>>>  2.  Fields to describe the state of the ADB and a means to detect
>>>>>>>      block corruption.  For both pieces of data, a useful property would be
>>>>>>>      that the allowed values are specially selected so that if passed across the
>>>>>>>      network, corruption due to translation between big and little
>>>>>>>      endian architectures is detectable.  For example, 0xF0DEDEF0 has
>>>>>>>      the same (32 wide) bit pattern in both architectures, making it inappropriate.
>>>>>>> END
>>>>>> Done
>>>>>> 
>>>>>>> PS: The example is relevant to 32 bit memory architectures... It has never occurred to me to ask if there are 64 bit big and little endian architectures!  Well the IA-64 is bi-endian...
>>>>>>> 
>>>>>>> s8.3:  The pictures of the memory patterns don't match the specification in that the guard pattern appears to be at octet offset 4 in each ADB - You can't tell where the checksum is from the pictures, but as specified there would be a 4 octet gap between the guard pattern and the checksum - I presume this is intentional. Would it be guaranteed to be zero?
>>>>>>> 
>>>>>> Not on purpose - does this work?
>>>>>> 
>>>>>>   Further, assume the application writes a single ADB at 16k, changing
>>>>>>   the guard pattern to 0xcafedead, we would then have in memory:
>>>>>> 
>>>>>>       0k ->   (4k - 1) : 00 00 00 00 ... fe ed fa ce 00 00 ... 00
>>>>>>       4k ->   (8k - 1) : 00 00 00 01 ... fe ed fa ce 00 00 ... 00
>>>>>>       8k ->  (12k - 1) : 00 00 00 02 ... fe ed fa ce 00 00 ... 00
>>>>>>      12k ->  (16k - 1) : 00 00 00 03 ... fe ed fa ce 00 00 ... 00
>>>>>>      16k ->  (20k - 1) : 00 00 00 04 ... ca fe de ad 00 00 ... 00
>>>>>>      20k ->  (24k - 1) : 00 00 00 05 ... fe ed fa ce 00 00 ... 00
>>>>>>      24k ->  (28k - 1) : 00 00 00 06 ... fe ed fa ce 00 00 ... 00
>>>>>>         ...
>>>>>>     396k -> (400k - 1) : 00 00 00 63 ... fe ed fa ce 00 00 ... 00
>>>>>> 
>>>>>> 
>>>>>>> s9.1:  Again it would be best to delete the title of s9.1 and leave the text as s9.
>>>>>>> 
>>>>>> Done
>>>>>> 
>>>>>> 
>>>>>>> s9.1, para 2: Expand ACL please.
>>>>>> Done
>>>>>> 
>>>>>>> s9.1/s9.6.1.3: I am dubious about referring back to the requirements doc [RFC7204] for definitions (rather than indicating what requirements were met/not met) . For the ref in s9.1, I think that the MAC definition in RFC 4949 would suffice.
>>>>>> Done
>>>>>> 
>>>>>> 
>>>>>>> [I noted when reviewing the rpcsec-gssv3 draft a couple of days ago that it makes *normative* reference to RFC 7204 - this is even more undesirable
>>>>> Starting with draft-ietf-nfsv4-rpcsec-gssv3-14, rfc7204 is an informative reference, and each reference includes a section number.
>>>>> 
>>>>>>> - my feeling is that it should be possible to find out what implementers need to know from the NFSv4.2 standard, other standards or the security glossary as there is no certainty that what is said in the requirements was actually put into the standard, which could cause confusion for future implementers.]
>>>>> the information that draft-ietf-nfsv4-rpcsec-gssv3-14 references in rfc7402 is ‘big picture’ info:
>>>> Tom - I’ll review Section 9.6 "MAC Security NFS Modes of Operation" of draft-ietf-nfsv4-minorversion2 and suggest some changes (if needed) so that draft-ietf-nfsv4-rpcsec-gssv3 can simply reference draft-ietf-nfsv4-minorversion2 for MAC security issues and get rid of the RFC7204 reference.
>>>> 
>>>> —>Andy
>>>>> 1.  Introduction and Motivation
>>>>> 
>>>>>   Labeled NFS (see Section 9 of [NFSv4.2]) uses an MLS policy with
>>>>>   Mandatory Access Control (MAC) systems as defined in [RFC4949].
>>>>>   Labeled NFS stores MAC file object labels on the NFS server and
>>>>>   enables client Guest Mode MAC as described in Section 4.3 of
>>>>>   [RFC7204].  RPCSEC_GSSv3 label assertions assert client MAC process
>>>>>   subject labels to enable Full Mode MAC when combined with Labeled NFS
>>>>>   as described in Section 3.3 of [RFC7204].
>>>>> 
>>>>> 
>>>>> 1.1.  Added Functionality
>>>>>           ………..
>>>>>  o  Security labels for Full Mode security type enforcement, and other
>>>>>      labeled security models (See Section 5.5.1 in [RFC7204]).
>>>>> 
>>>>>  An option for enumerating server supported label format specifiers
>>>>>   (LFS) is provided.  See Section 2 and Section 3.3 in [RFC7204] for
>>>>>   detail.
>>>>> 
>>>>> 
>>>>>>>  Is it possible to get everything an rpcsec-gssv3 implementer needs to know into this document?
>>>>>>> My impression is that it is almost all there already.
>>>>> I think WRT this issue, draft-ietf-nfsv4-rpcsec-gssv3-14 does give everything an implementor of rpcsec-gssv3 neeeds to know.
>>>>> 
>>>>> —>Andy
>>>>> 
>>>>>> Andy???
>>>>>> 
>>>>>> 
>>>>>>> s9.2, MLS definition: RFC 2401 has been obsoleted by RFC 4301... can this be referenced instead?
>>>>>> MLS appears in RFC 2401 and not RFC 4301.
>>>>>> 
>>>>>> But I wasn’t aware of RFC 4949 - do you want to use it here as well?
>>>>>> 
>>>>>> 
>>>>>>> s9.4: Expand DS and MDS on first occurrence (these should probably go back in s3 where metadata servers and data servers are referred to but without the abbreviations).
>>>>>> Oh, I don’t like using them at all. I think I was supposed to go back and expand them. :-)
>>>>>> 
>>>>>> 
>>>>>>> s11.2, Table 2: The operation IO_ADVISE is missing from the table. [CAVEAT: I don't claim to have checked the possible error codes!] Aesthetically, this table would be better with horizontal separators between the operation items.
>>>>>> Done on the first part.
>>>>>> 
>>>>>> And the newer versions of xml2rfc has allowed me to add the horizontal separators
>>>>>> 
>>>>>> 
>>>>>>> s12.1, Table 4:  The data types of clone_blksize (length4 vs uint32_t) and space_freed (length4 vs uint64_t) do not match between this draft and the XDR draft.
>>>>>> Fixed as per the email on the XDR draft.
>>>>>> 
>>>>>>> s12.2.3, NFS4_CHANGE_TYPE_IS_MONOTONIC_INCR:
>>>>>>> Monotonic is not really a good name for this I think.  This is because the technical definition is either non-increasing or non-decreasing so that it would theoretically cover situations where the change attribute doesn't actually change! IMO a better name would be NFS4_CHANGE_TYPE_STRICTLY_INCR.  This would imply that the value actually increases whenever the info changes.
>>>>>>> 
>>>>>> Researching this one!  Will get back to you...
>>>>>> 
>>>>>> 
>>>>>>> s12.2.3:  With reference to the previous comment...
>>>>>>> OLD:
>>>>>>>  If either NFS4_CHANGE_TYPE_IS_MONOTONIC_INCR,
>>>>>>>  NFS4_CHANGE_TYPE_IS_VERSION_COUNTER, or
>>>>>>>  NFS4_CHANGE_TYPE_IS_TIME_METADATA are set, then the client knows at
>>>>>>>  the very least that the change attribute is monotonically increasing,
>>>>>>>  which is sufficient to resolve the question of which value is the
>>>>>>>  most recent.
>>>>>>> NEW:
>>>>>>>  If either NFS4_CHANGE_TYPE_IS_MONOTONIC_INCR,
>>>>>>>  NFS4_CHANGE_TYPE_IS_VERSION_COUNTER, or
>>>>>>>  NFS4_CHANGE_TYPE_IS_TIME_METADATA are set, then the client knows at
>>>>>>>  the very least that the change attribute is strictly increasing,
>>>>>>>  which is sufficient to resolve the question of which value is the
>>>>>>>  most recent.
>>>>>>> END
>>>>>>> 
>>>>>>> s13, Operations table:  The abbreviation EOL in the title line does not seem to be expanded anywhere (and isn't used in the table either).  It would be good to have table numbers for the tables.
>>>>>>> 
>>>>>> Yes, I think it was taken out in an earlier draft - striking.
>>>>>> 
>>>>>> Table numbers added
>>>>>> 
>>>>>> 
>>>>>>> s13, Operations table: Does not include IO_ADVISE
>>>>>> Added
>>>>>> 
>>>>>> 
>>>>>>> ( and technically doesn't include ILLEGAL, and CB_ILLEGAL isn't in Callbacks).
>>>>>> Added
>>>>>> 
>>>>>>> s15.2.3:
>>>>>>>>   If it cannot make that determination, it must set to false the one it
>>>>>>>>   can and set to true the other.
>>>>>>> The setting of true and false appears to be the inverse of the meaning implied in the previous part of the section.
>>>>>> Agreed
>>>>>> 
>>>>>>> s15.5.6/s15.5.6.1: Pointers into the appropriate parts of the NFS v4.1 RFC would be helpful in giving the background needed to understand what is going on here.    The discussion of dense and sparse packing in s15.5.6.1 is particularly obscure if you are not very well versed in pNFS lore.
>>>>>> Done - added a reference for the COMMIT semantics and the packing.
>>>>>> 
>>>>>>> ss15.6 and 15.7: An overview of the LAYOUT* operations in the earlier part of the document would be helpful, as mentioned above, plus some pointers to parts of the NFSv4.1 document that ties in with the pNFS layout story would be helpful.
>>>>>>> 
>>>>>> Note that we have been trying to shift from pulling in everything every minor version to just the bare minimum.
>>>>>> 
>>>>>> And I’ll note you are saying I’m not at that bar. :-)
>>>>>> 
>>>>>> Still not sure...
>>>>>> 
>>>>>>> s19.2, [Quigley14]:  This is now RFC 7569.  Also I think this should be normative.
>>>>>> Done
>>>>>> 
>>>>>>> s19.2, [BL73]: Can you point me to a copy of this? I have found some closely related work which was originally published as MITRE Technical Report 2547 Vols I and II  athttp://www.albany.edu/acc/courses/ia/classics/belllapadula1.pdf  (belllapadula2.pdf) and in the Journal of Computer Security  but the original doesn't seem to be visible.
>>>>>>> 
>>>>>>> 
>>>>>> I don’t have a copy either - during the work on RFC 7569, Ran Atkinson provided this citation in the review process. Perhaps you can ask him? (Ask me offline and I’ll provide his email.)
>