Hi Dale- One additional thought. > On May 24, 2020, at 4:50 PM, Dale Worley via Datatracker <noreply@xxxxxxxx> wrote: > > Reviewer: Dale Worley > Review result: Ready with Nits > > 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 > > <https://trac.ietf.org/trac/gen/wiki/GenArtfaq>. > > Document: draft-ietf-nfsv4-rpc-tls-07 > Reviewer: Dale R. Worley > Review Date: 2020-05-24 > IETF LC End Date: 2020-05-27 > IESG Telechat date: unknown > > Summary: > > Note that I am not familiar with the operations of TLS, so I have not > reviewed issues that are specific to security implementations. I > assume the SECDIR review has adequately covered those. > > This draft is quite solid and nearly ready for publication, but has > nits that should be fixed before publication. > > Nits: ... > 7.1. Limitations of an Opportunistic Approach > > Implementations of > the mechanism described in the current document must take care to > accurately represent to all RPC consumers the level of security that > is actually in effect, ... > > I think you want s/must/MUST/. There's also an unstated requirement > that the RPC consumers have some way of accessing this information. IMHO the non-normative form of "must" is appropriate in this case. - The text is not specific enough to be part of an enforceable normative compliance statement. - The remark here is about an internal RPC consumer API, as you note. Such APIs are not something on which this document can place hard requirements. However, I'm open to further comments and discussion. -- Chuck Lever -- last-call mailing list last-call@xxxxxxxx https://www.ietf.org/mailman/listinfo/last-call
