> 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.
The term is introduced in RFC5661. Not sure what you consider an adequate explanation, but this would be a relevant reference that also might be cited. > Perhaps the best I can do here is add a paragraph introducing the > concept, and use the RFC 8167 terminology instead of > "backchannel"? This concept does need to be introduced at the RPC-level and rpc-tls, which is to update RFC5531, is a good place to do it. I think it would be best to explain the connections between the RFC5661 and RFC8167 terminologies Let me review RFC 8167 and see if I can reference it sensibly in the context of RPC on TCP. On Sun, May 24, 2020 at 5:58 PM Chuck Lever <chuck.le...@oracle.com> wrote: > > > > On May 24, 2020, at 4:50 PM, Dale Worley via Datatracker < > nore...@ietf.org> 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 > > > >
_______________________________________________ Gen-art mailing list Gen-art@ietf.org https://www.ietf.org/mailman/listinfo/gen-art
