Hi Murray, Thanks for the review!
> On Feb 1, 2022, at 9:45 PM, Murray Kucherawy via Datatracker > <[email protected]> wrote: > > Murray Kucherawy has entered the following ballot position for > draft-ietf-quic-datagram-08: 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/blog/handling-iesg-ballot-positions/ > for more information about how to handle DISCUSS and COMMENT positions. > > > The document, along with other ballot positions, can be found here: > https://datatracker.ietf.org/doc/draft-ietf-quic-datagram/ > > > > ---------------------------------------------------------------------- > COMMENT: > ---------------------------------------------------------------------- > > Section 3: > > * "... transport parameter greater or equal to ..." -- s/greater/greater > than/ (two instances) Good point! I’ve opened a PR to fix this nit here: https://github.com/quicwg/datagram/pull/77 <https://github.com/quicwg/datagram/pull/77> > > Section 4: > > * I also tripped on the thing John pointed out. Thanks. We’ll follow up in the reply to John. > > Section 5: > > * I don't understand the two SHOULDs in this section. When/why would you > ever do otherwise? I assume you’re referring to: "This frame SHOULD be sent as soon as possible...” and: “...it SHOULD deliver the data to the application immediately…” These are requirements that were added pretty early on, given that there was a lot of discussion around queueing of data and what layer would be responsible for determining timing. Note that some frame types don’t get sent “immediately” always (such as ACKs, etc), and there was confusion early on about if the QUIC layer would be responsible for more scheduling or queueing. I think it is important to maintain these to be extra clear (although I agree that they can seem obvious once you’re in the mindset). Best, Tommy > > >
