Draft: draft-ietf-quic-transport

Commentary:   said : 
 No , but yes . The Unused field is defined in Invariants to be whatever the sender wants , so it 's perhaps inconsistent to re - slice the fields in Transport . However , proposes removing this SHOULD entirely , which would also address this issue . 
 Since is design , marking this as such , too . 
 To make it clear what happened here as it several redirects . This issue was closely related to . Which was resolved by a better explanation . So I consider it resolved . 
 Closing this now that the IESG have approved the document(s ) . 
   said : 
 I think that  's suggestion to remove the " SHOULD " is ideal . 
 Does someone remember why this SHOULD was ? The fixed bit is useful in the client - to - server direction because it allows servers to demultiplex QUIC with other protocols , but I do n't remember what benefit it provided in the server - to - client direction . 
 I believe there ' could ' be applications(ie : WebRTC ) which share a port with QUIC and might want to use this bit to demux even on the client side , but that 's seems like a pretty theoretical problem , so I 'd be inclined to drop the SHOULD . 
 In a p2p setup , you might run QUIC clients and servers on the same port ( in fact , that 's what we 're doing in libp2p ) , so demultiplexing might be important for both sides in that case . 
 Yes , this was to avoid collision with p2p protocols . As I recall , we had decided that this would be something we would recommend for v1 , but not require this for future versions ... and that if both endpoints agreed , then they could set the bit to something other than 1 . I do n't see why we should change this . 
 In a P2P setup where we 're demultiplexing with another bootstrapping protocol over UDP , is there a need for version negotiation packets at all ? I 'd expect the bootstrapping protocol to convey the supported QUIC versions , and at that point you do n't need version negotiation . I 'm in favor of removing the SHOULD on VN packets . 
 My thinking is along the lines of but I also do n't care much about whether we remove this or not . 
 The VN packet is version - independent . v1 should n't be constraining its contents . However , implementations are free to select the value they put there any way they wish , so if they find it useful to always set that bit , they may . 
 This is n't constraining the contents of a VN packet broadly , it is constraining what a v1 sender sends in a VN packet . And , I do n't think it 's reasonable to require that P2P protocols should n't need to use VN . My high - level point is this : IIRC , we had this SHOULD for co - existence with P2P protocols , and we went through a lot of discussion , especially with ART folks on this . Do we really want to re - litigate this point at this stage in the process ? Maybe I 'm mis - remembering . If I am , and this SHOULD was there for a different reason that is no longer valid ( or never was important ) , I 'm happy to remove this . 
 That 's right . Maybe we should have been more studious in capturing reasons . I think that for those P2P applications that care about multiplexing , this is a non - issue . Those applications can use their signaling channel to ensure that version negotiation does not happen . If things get badly out of hand , endpoints can ensure that Version Negotiation packets are sent with the bit set to conform to other constraints . 
 That applies to peers discovered during the execution of the p2p protocol . Every p2p network has some hard - coded bootstrap nodes though , for which the QUIC version might not be known in advance . 
 are those hard - coded bootstrap nodes QUIC clients or servers ? We 're only talking about receipt of VN packets here . 
 I think that we can keep the inconsistency , but we need someone ( to follow up with  . 
 At this point , I 'd rather not change what was a design decision made by the wg , so I propose close with no action to this issue ( not merge ) . Can you see if the is satisfactory to you ? 
 To check that my understanding is correct : VN packets ( as per the Invariants doc ) MAY set the fixed bit . VN packets for QUIC version 1 ( as per the transport doc ) SHOULD set the fixed bit . This behaviour is consistent , but the documents need to explain this more clearly . Particularly , because the the first sentence of section 17.2.1 states : " A Version Negotiation packet is inherently not version - specific , " and yet the value set in this field might be version specific . Hence , I would suggest that you expand the description in the transport draft to explain that it SHOULD be set for QUIC version 1 , but that other versions of QUIC may relax this requirement . Noting that the transport draft already talks about future versions having different requirements on the length of connection ids . 
 Just to close the loop here . I 've an explanation of two things to the draft that is about to go out : that this recommendation is to allow for multiplexing , and that this recommendation is not guaranteed to apply when other QUIC versions are in use . I think that is in line with what suggests . If you disagree , we might be able to tweak this more later , but I need to publish  so that the wheels of the process can continue to turn . 
 Just to confirm that I am happy with the committed text change . Thanks for accommodating . 
 A bit late , but LGTM
Paragraph (version A):
The value in the Unused field is selected randomly by the server.
Clients MUST ignore the value of this field.  Servers SHOULD set the
most significant bit of this field (0x40) to 1 so that Version
Negotiation packets appear to have the Fixed Bit field.
Paragraph (version B):
The value in the Unused field is set to an arbitrary value by the
server.  Clients MUST ignore the value of this field.  Where QUIC
might be multiplexed with other protocols (see RFC7983), servers
SHOULD set the most significant bit of this field (0x40) to 1 so that
Version Negotiation packets appear to have the Fixed Bit field.  Note
that other versions of QUIC might not make a similar recommendation.