On 3/22/22 6:29 AM, Brian Trammell (IETF) wrote:
Hi Peter,
Many thanks for the review! Apologies for the delay in getting back to
you on this, as this fell through the cracks a bit. The comments here
not addressed in other changes suggested by other reviews are currently
in https://github.com/quicwg/ops-drafts/pull/462
<https://github.com/quicwg/ops-drafts/pull/462>, and will make it into a
published copy of the draft soon.
A couple of points, inline...
On 15 Feb 2022, at 00:30, Peter Saint-Andre via Datatracker
<noreply@xxxxxxxx <mailto:noreply@xxxxxxxx>> wrote:
Reviewer: Peter Saint-Andre
Review result: Ready with Nits
ARTART review for draft-ietf-quic-manageability
Author: Peter Saint-Andre
Date: 2022-02-14
Overall this document is in good shape (in particular, I welcome its
neutral,
explanatory tone). I have only small comments.
In Section 2, the phrase "this document describes version 1 of the QUIC
protocol" could be slightly misleading, because presumably the
protocol itself
is described in the QUIC specifications. I suggest changing "describes" to
"addresses".
It might be helpful to mention that QUIC-specific terminology (e.g., "spin
bit") is defined in the QUIC specifications.
Is there a difference between "long packet headers" and "long header
packets"?
Both phrases are used.
There’s a tiny difference — a long packet header is the header itself,
and a long header packet is a packet containing a long header. I’ve
reviewed the uses in the document and I think, stylistically, we’re
using each appropriately everywhere.
Would it make sense to describe this in the text or, perhaps, to
hyphenate "long-header packet"? (I think the latter is good.)
The phrase "cryptographically obfuscated" (used in Section 2.1 and
elsewhere)
is strange. Typically, to obfuscate something means to make it obscure,
unclear, or unintelligible; this verges on "security by obscurity". It
would be
more accurate to say that constructs like the packet number and key
phase are
cryptographically protected or, even better, that the QUIC protocol
ensures
data confidentiality (e.g., as that term is defined in RFC 4949).
I think you missed some instances in your edits:
Retry (Section 17.2.5 of [QUIC-TRANSPORT]) and Version Negotiation
(Section 17.2.1 of [QUIC-TRANSPORT]) packets are not encrypted or
obfuscated in any way. For other kinds of packets, version 1 of QUIC
cryptographically obfuscates other information in the packet headers:
and
The payload of the Initial packet
is obfuscated using the Initial secret.
and
The Server Initial datagram also exposes version number, source and
destination connection IDs in the clear; the payload of the Initial
packet(s) is obfuscated using the Initial secret.
and
The packet number length
is defined by the seventh and eight bits of the header as described
in Section 17.2 of [QUIC-TRANSPORT], but is obfuscated as described
in Section 5.4 of [QUIC-TLS].
Can we provide a citation for the term 5-tuple?
I couldn’t find a reasonable one here that didn’t come with other
baggage, so I defined it on the first use instead.
Yes, I ran into the same baggage problem when I started to look around;
defining it on first use is good.
Thanks!
Peter
--
last-call mailing list
last-call@xxxxxxxx
https://www.ietf.org/mailman/listinfo/last-call
