| 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, 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> 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. 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).
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.
Thanks again, cheers,
Brian
In Section 2.4, I had to read this sentence several times in order to parse it:
The content of Initial packets is encrypted using Initial Secrets,
which are derived from a per-version constant and the client's
destination connection ID; they are therefore observable by any on-
path device that knows the per-version constant and considered
visible in this illustration.
I suggest saying "and are considered" to reduce the possibility of confusion.
|
--
last-call mailing list
last-call@xxxxxxxx
https://www.ietf.org/mailman/listinfo/last-call
