Thanks, Tommy... all good!

Barry

On Wed, Apr 22, 2020 at 1:11 PM Tommy Pauly <[email protected]> wrote:
>
> Hi Barry,
>
> Thanks for the review! You can find an updated version of the document here:
>
> https://ietf-tapswg.github.io/draft-ietf-taps-transport-security/draft-ietf-taps-transport-security.html
>
> Responses to your individual points inline.
>
>
> On Apr 7, 2020, at 10:48 PM, Barry Leiba via Datatracker <[email protected]> 
> wrote:
>
> Barry Leiba has entered the following ballot position for
> draft-ietf-taps-transport-security-11: No Objection
>
> When responding, please keep the subject line intact and reply to all
> email addresses included in the To and CC lines. (Feel free to cut this
> introductory paragraph, however.)
>
>
> Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html
> for more information about IESG DISCUSS and COMMENT positions.
>
>
> The document, along with other ballot positions, can be found here:
> https://datatracker.ietf.org/doc/draft-ietf-taps-transport-security/
>
>
>
> ----------------------------------------------------------------------
> COMMENT:
> ----------------------------------------------------------------------
>
> Thanks for this helpful document.  Just some editorial comments beyond what
> others have mentioned:
>
> — Section 1 —
>
>   It examines Transport Layer Security
>   (TLS), Datagram Transport Layer Security (DTLS), IETF QUIC, Google
>   QUIC (gQUIC), tcpcrypt, Internet Key Exchange with Encapsulating
>   Security Protocol (IKEv2 + ESP), SRTP (with DTLS), WireGuard,
>   CurveCP, and MinimalT.
>
> It’s funny that this carefully expands every abbreviation except “SRTP”.
> Please do that one too.
>
>
> Expanded!
>
>
>   Ubiquitous IETF protocols such as (D)TLS, as well as non-standard
>   protocols such as gQUIC, are both included
>
> The word “both” doesn’t work here.  I think a reasonable fix is just to remove
> the single word.  Maybe a better fix is to slightly reword, as, “Ubiquitous
> IETF protocols such as (D)TLS are included, and so are non-standard protocols
> such as gQUIC, despite...”
>
>
> Fixed by removing the word.
>
>
> — Section 1.1 —
>
>   For example, a security
>   protocol that expects to run over a reliable stream of bytes, like
>   TLS, restrict the set of transport protocols that can be used
> Number agreement: make it “restricts” to match the singular subject “a 
> security
> protocol”.
>
>
> Fixed.
>
>
> — Section 2 —
>
>      Examples include
>      confidentiality, reliable delivery, ordered delivery, message-
>      versus-stream orientation, etc.
>
> You don’t need both “examples include” and “etc.”; I suggest eliminating the
> latter (and sticking in an “and”).
>
>
> Fixed.
>
>
> — Section 3.1.1 —
>
>   to marshal (possibly encrypted) data from one peer to the other.
>
> Possibly?  I understand you’re covering the handshake there as well, but for a
> summary as (reasonably) brief as this I think it’s misleading to say 
> “possibly”.
>
>
> This is now:
>
> "The record protocol is used to marshal and, once the handshake has 
> sufficiently progressed, encrypt, data from one peer to the other. "
>
>
> — Section 3.2.1 —
>
>   ZRTP [RFC6189] is an alternative key agreement and identity
>   management protocols for SRTP.
>
> Number agreement: “protocol”
>
>
> Fixed!
>
>
> — Section 3.4.3 —
>
>   For key establishment, OpenVPN can use TLS as a handshake protocol or
>   pre-shared keys.
>
> This reads oddly, as though there are two things OpenVPN can use TLS for.  I
> would make it, “...or it can use pre-shared keys.”
>
>
> Changed to:
>
> "For key establishment, OpenVPN can either use TLS as a handshake protocol or 
> use pre-shared keys."
>
>
> — Section 5.1 —
>
>   *  Extensions (Application-Layer Protocol Negotiation) (EXT): The
>      application enables or configures extensions that are to be
>      negotiated by the security protocol, such as ALPN [RFC7301].
>
> Isn’t the expansion of “ALPN” misplaced here?
>
>
> This is now written out in expanded form "Application-Layer Protocol 
> Negotiation (ALPN) [RFC7301]"
>
>
>
>
> Thanks,
> Tommy
>

_______________________________________________
Taps mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/taps

Reply via email to