> 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
> 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.
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.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
-- last-call mailing list last-call@xxxxxxxx https://www.ietf.org/mailman/listinfo/last-call
