Hi Trond- > On May 25, 2020, at 8:04 AM, Trond Myklebust <trondmy@xxxxxxxxxxxxxxx> wrote: > > On Mon, 2020-05-25 at 07:46 -0400, David Noveck wrote: >> > 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. > > There really is no mention in RFC5531 of RPC being unidirectional either. It does describe a client-server model, but imposes no limitations on the number of services a single transport can support, or on directionality of the calls. Ultimately, the only special thing about a backchannel is that it is a service on one side of the transport that is associated with a different service on the other side of the channel. > > Is that really a nuance that needs to be explained in this document? We've already determined the TLS behaviour when a transport supports multiple services. True. The discussion of reverse-direction operation here is implementation advice rather than the statement of more compliance rules. I added this paragraph because it feels valuable to point out this very fact: reverse-direction operation is not an exception to the "multiple services on a connection" rule. I believe that as a putative implementer I would appreciate seeing this statement in clear black-and-white letters. We are likely to get asked for clarification -- or worse, have to deal with improper implementations -- without this statement. >> On Sun, May 24, 2020 at 5:58 PM Chuck Lever <chuck.lever@xxxxxxxxxx> wrote: >>> >>> >>> > 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 >>> >>> >>> > -- > Trond Myklebust > CTO, Hammerspace Inc > 4984 El Camino Real, Suite 208 > Los Altos, CA 94022 > <Hammerspace-email.png> > www.hammer.space > -- Chuck Lever -- last-call mailing list last-call@xxxxxxxx https://www.ietf.org/mailman/listinfo/last-call
