> 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. Thank you, Dale, for the detailed feedback. I will reply to this e-mail thread with specific text corrections in the next few days. I do have a few initial reactions/follow-ups for you that appear inline below. > Nits: > > 4.1. Discovering Server-side TLS Support > > Somewhere in this section you need to specify the semi-obvious: > > In principle, RPC is transport-agnostic. In the context of > RPC-Over-TLS, the initial request MUST be sent using either TCP or > UDP. If an initial TCP request is successful, a TLS connection is > established. If an initial UDP request is successful, a DTLS > association is established. I can add something like this in Section 4.1, but note that Sections 5.1.1 and 5.1.2 already explain the relationships between TCP/UDP and TLS/DTLS, respectively. > 5.1.1. Protected Operation on TCP > > The server does not attempt to establish a TLS session > on a TCP connection for backchannel operation. > > I think "... does not attempt to establish a separate TLS session ..." > is clearer. > > I can't find any discussion of "backchannel operation" in RFC 5531. > Might this need an additional reference? I agree that a deeper introduction of "backchannel operation" would be helpful in this section. There doesn't seem to be any adequate explanation for backchannel operation in documents prior to RFC 8167, which explains reverse- direction RPC operation over an RDMA transport. Perhaps the best I can do here is add a paragraph introducing the concept, and use the RFC 8167 terminology instead of "backchannel"? Let me review RFC 8167 and see if I can reference it sensibly in the context of RPC on TCP. > 5.2.1. X.509 Certificates Using PKIX trust > > o For services accessed by their network identifiers (netids) and > universal network addresses (uaddr), the iPAddress subjectAltName > SHOULD be present in the certificate and must exactly match the > address represented by universal address. > > I suspect that "iPAddress" is not capitalized correctly. This is the capitalization used in RFC 6125, which is cited nearby this text. -- Chuck Lever -- last-call mailing list last-call@xxxxxxxx https://www.ietf.org/mailman/listinfo/last-call
