Draft: draft-ietf-quic-transport

Commentary: As pointed out in , I missed that there 's a CRYPTOBUFFEREXCEEDED that would equally valid to send when a CRYPTO frame exceeds the 2 ^ 62 - 1 limit . 
 I can see how this can simplify some decoding logic , but I am not sure we should consider such a value valid in the first place . If the value is invalid it is meaningless to discuss length and then there is only a frame error left . Otherwise we could probably revisit a gazillion other places where this principle could also apply . 
 yes this is largely what I meant . The PR introduces a new principle . 
 : I 'm confused too . For consistency , I would keep it at FRAMEENCODINGERROR , since that 's what we do for the flow control error too . 
 I am with Let me explain why . There are two reasons we decided to allow use of FLOWCONTROLERROR for STREAM frames : The overflow can be detected by the flow control logic . Then , there is not need to have a logic to detect the error in the frame decoder . The flow control logic might be capable of returning only one error . FLOWCONTROLERROR is more specific than FRAMEENCODINGERROR . These reasons equally hold for CRYPTO streams sending CRYPTOBUFFEREXCEEDED , as CRYPTOBUFFEREXCEEDED is the error code used to indicate flow control error with CRYPTO streams . To paraphrase this PR applies the principles that we agreed for STREAM frame to CRYPTO frames . 
 Thanks for clarifying , This LGTM . 
 From the original issue , the proposed principle was : " If you can detect an error while parsing the frame , and without consulting any connection state , it should be a FRAMEENCODINGERROR . " It seems clear you can do that in this case , but maybe we changed the principle ? 
 That would also apply to the STREAM frame then . I 'd be fine just using the FRAMEENCODINGERROR in all these cases , but people pushed back against that . 
 Yeah I think I should have said that the exceptional rule within the principles . Specifically , I mean the discussion starting from , that talks if we should allow FLOWCONTROLERROR and why . 
 I thought that might have been the relevant discussion . In general , I 'd prefer to have principles decided on issues , but I understand these things happen . I do n't think this is the end of the world , but I prefer the original principle because I think it 's easy to reason about . If we 've decided against that principle , I 'd suggest we state a new principle . 
 I do n't think we ever actually discussed this in the working group . If I remember correctly , using two error codes was a suggestion that came up on my original PR , and then the editors decided in Cupertino that I should update the PR accordingly . Actually , I 'd prefer to take the principled approach , and just use FRAMEENCODINGERROR wherever possible . 
 I think we did discuss at the interim . 
 To be precise , we discussed that two error codes were OK at the interim , then declared that as a consensus in the call started on Oct 22 I do not think we should be revisiting the discussion . 
 I think we should either : 1 ) Espouse a new principle that fits the existing text and this PR and use that going forward 2 ) Stick with the original principle and remove the OR FLOWCONTROLERROR from the text . If we do n't have a principle that matches the text , we 're prone to having this discussion a few more times . 
 kindly shared our principles , and this PR aligns with that . 
  and editors , I think we agree that this is an amendment to that has been shipped as part of -24 . Does that mean that this would be merged as an editorial correction ? Or if not , do we need an issue ? 
 I think we can merge it because it agrees with the stated principles . But its call 
 Let 's open an issue . At this stage , I want to be very particular about this sort of change , even if it is quite clearly within the bounds of established principles . 
 did as . 
 When discussing at Cupertino , we agreed that either of the following two errors can be sent when the payload of the STREAM frame exceeds 2 ^ 62 bytes : FRAMEENCODINGERROR FLOWCONTROLERROR And we 've merged PR that made that change , along with other changes . However , in that PR , we failed to apply the rule that we agreed for SRTEAM frame to CRYPTO frame . Editors ' draft now allows use of FRAMEENCODINGERROR for CRYPTO frames , but not CRYPTOBUFFEREXCEEDED . As CRYPTOBUFFEREXCEEDED is the flow control error for CRYPTO streams , that should be permitted too . To be fixed by PR . 
 Thanks for doing all of this Kazuho . 
 fixed this one . 
 Thank you ! LGTM .
Mailing list commentary: The following issues have proposals for resolution , and discussion so far seems to support consensus to accept them . If you object , please do so on the issue or in response to this message ( changing the Subject appropriately ! ) . Absent any pushback , we 'll direct the editors to incorporate them next week . See for the current state of issues in the Late Stage process , itself defined at . # 3097 : Is CONNECTIONCLOSE ACK - eliciting ? The proposal is # 3085 : Stateless reset detection should be datagram - based The proposal is # 3054 : Label for key updates The proposal is # 3046 : Handling of To field The proposal is # 3037 : Require peers to check if  sequence number is valid The proposal is # 3027 : Codes for frame encoding errors The proposal is # 2944 : Layout of PreferredAddress The proposal is to close with no action . # 2928 : Lift single - packet ClientHello requirement ? The proposal is # 2863 : unrecoverable loss pattern leads to deadlock The proposal is # 2823 : Do Initial secrets change after Retry packet ? The proposal is # 2741 : Re - visit initial keys discard The proposal is to close with no action . # 2152 : Why does stateless reset have to be checked after MAC failure The proposal is
Paragraph (version A):
The largest offset delivered on a stream - the sum of the offset and
data length - cannot exceed 2^62-1.  Receipt of a frame that exceeds
this limit MUST be treated as a connection error of type
FRAME_ENCODING_ERROR.
Paragraph (version B):
The largest offset delivered on a stream - the sum of the offset and
data length - cannot exceed 2^62-1.  Receipt of a frame that exceeds
this limit MUST be treated as a connection error of type
FRAME_ENCODING_ERROR or CRYPTO_BUFFER_EXCEEDED.