Summary: Has 2 DISCUSSes. Has enough positions to pass once DISCUSS positions are resolved.
Thanks for your response to the SecDir review. I see the proposed changes have not been integrated yet. This discuss will be resolved when the SecDir review changes have been included. https://mailarchive.ietf.org/arch/msg/secdir/HKdT2KjnWJFmzEPxlGcNH0OnUDg
I concur with Kathleen's discuss. To put a finer point on it, I think the security considerations section here needs to really clearly state what the security properties of this design are and how they differ from existing NFS. That's not true yes.
- I'm a bit confused on whether the client can tell which model the server is using. I see: An implementation can always be deployed as a loosely coupled model. There is however no way for a storage device to indicate over a NFS protocol that it can definitively participate in a tightly coupled model: But then there is a flag that you use to indicate you are tightly coupled. So I'm confused. - I note that some of your PDUs have /// in front and some do not. E.g., Section 5. Is that a bug. - S 2.2. " Note: it is recommended to implement common access control methods at" Do you want RECOMMENDED.
-1.2: Please consider using the boilerplate from RFC 8174. There are several instances of lower case keywords.
I understand that v16 is foreseen based on Linda Dunbar's OPS DIR review.
Thanks for responding to Linda Dunbar's comments. I'm not an NFS person in any way, so much of the document was over my head. On an editorial note, I found the way the definitions were written to be interesting (the term, and then the "is a ...") - this is no way a criticism, I just found it unusual (and actually quite engaging, I might steal that!) Also, props on the embedding of the XDR; I hadn't seen that particular way (the ` grep "^ *///" | sed 's?^ */// ??' | sed 's?^ *///$??' ` ) of embedding code in a draft -- this seems to be fairly popular in the NFS WG (which is probably why I hadn't seen it. :-)