[C430] questions - Re: AUTH48 [LB]: RFC 9000 <draft-ietf-quic-transport-34.txt> NOW AVAILABLE

[Alice Russo <[e-mail]>]

Authors,
As we prepare this document for publication, we have 4 questions.

1) May Figure 4 be changed to <artwork>, or is there a reason for <sourcecode type="drawing">?  (The other Client/Server diagrams in this set are <artwork>, as expected. e.g., Figure 5 in RFC 9001)

      <figure anchor="fig-hs">
        <name>Simplified QUIC Handshake</name>
        <sourcecode type="drawing"><![CDATA[                                    
Client                                               Server                     
                                                                                
Initial (CRYPTO)                                                                
0-RTT (*)              ---------->                                              
                                           Initial (CRYPTO)                     
                                         Handshake (CRYPTO)                     
                       <----------                1-RTT (*)                     
Handshake (CRYPTO)                                                              
1-RTT (*)              ---------->                                              
                       <----------   1-RTT (HANDSHAKE_DONE)                     
                                                                                
1-RTT                  <=========>                    1-RTT                     
]]></sourcecode>
      </figure>


2) Capitalization nit in Section 22.1.1: Should these be lowercased to match the actual registries?

OLD:  Status:  "Permanent" or "Provisional".

NEW:  Status:  "permanent" or "provisional".


3) capitalization nit & IANA reg procedure

3a) Would you like the IANA registry to be updated as follows (4 instances to cap 'Date')?  If so, we'll send them a mail.

OLD: provisional registration date field update
NEW: provisional registration Date field update
 
("Date field" is used in the doc; "Date field update" does not appear.)

3b) Section 22.1.1: Should the reg procedure for "provisional registration date field update" -- i.e., First Come First Served -- be stated with those exact words, or is the current text* sufficiently clear? 
* Seems to be "A request to update the date on any provisional registration can be made without review from the designated expert(s)."


4) Revisiting an AQ from earlier in the process:

> On May 2, 2021, Martin Thomson <[e-mail]> replied:
>> 32) Section 22.2: We see the lowercase form "version  
>> negotiation" elsewhere in this document, when used generally.  
>> Should "reserved for Version Negotiation" be "reserved for Version  
>> Negotiation packets" or "reserved for version negotiation"?  
> 
> Yeah, either would do. I'll send a note to IANA.

Just checking if the current state is fine with you; we did not see the note that Martin mentioned. IANA (https://www.iana.org/assignments/quic/quic.xhtml#quic-versions) has:

Reserved for Version Negotiation

vs. Section 22.2:
   ... the note for this
   codepoint indicates that this version is reserved for version                
   negotiation.

Thank you.
RFC Editor/ar