Murray Kucherawy's Yes on draft-ietf-quic-transport-33: (with COMMENT)

[Murray Kucherawy via Datatracker <[e-mail]>]

Murray Kucherawy has entered the following ballot position for
draft-ietf-quic-transport-33: Yes

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-quic-transport/



----------------------------------------------------------------------
COMMENT:
----------------------------------------------------------------------

This is really great technical and written work.  Kudos to everyone involved,
and I'm happy to join the "Yes" pile.

There were some SHOULDs in the document that had me wondering why one might
legitimately do something other than what's being recommended, since SHOULD
does leave the implementer a choice.  For instance, in Section 10.2.2 there's
this:

   An endpoint MAY enter the draining state from the closing state if it
   receives a CONNECTION_CLOSE frame, which indicates that the peer is
   also closing or draining.  In this case, the draining state SHOULD
   end when the closing state would have ended.  In other words, the
   endpoint uses the same end time, but ceases transmission of any
   packets on this connection.

This left me wondering why the endpoint would ever do something other than
what's specified as SHOULD here.  There might be a good reason, but the prose
doesn't say what that might be (or I managed to miss it).  Or maybe "SHOULD
end" should simply be "ends"?

Also, I have the same question as Ben about Section 22.1.4.  I think it's
appropriate that a permanent registration refers to a specification that is
also likely to be permanent, as we do with Standards Track RFCs.

Lastly, also on 22.1.4: I believe (though my colleagues can correct me if I'm
wrong) that the IESG's current preference is to list the IESG, and not a
working group, as the contact email address for registrations over which the
IETF has change control.