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 > <[email protected]> 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. > > >
