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

From: Murray Kucherawy via Datatracker <[email-masked]>
Date: Wed, 06 Jan 2021 22:34:41 -0800

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.

---

From: Barry Leiba <[email-masked]>
Date: Thu, 7 Jan 2021 08:15:28 -0500

> working group, as the contact email address for registrations over which the

What we actually decided is this:
- Change control should be with "IETF".
- The contact address can be a working group mailing list, a mailing
list specifically set up for the purpose, or the IESG list.
- IANA will record the contact address, then the RFC Editor will
remove it from the published RFC.  That way, the address is not
recorded in an unchangeable place, but it with IANA, where it can be
changed if necessary (if the working group mailing list is closed, or
a new working group becomes a more appropriate place for discussion
later).

So what's there is actually OK, but the address of the QUIC working
group will not appear in the RFC.

Barry