Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Use short headers for stateless reset #2599

Closed
martinthomson opened this issue Apr 9, 2019 · 6 comments · Fixed by #2600
Closed

Use short headers for stateless reset #2599

martinthomson opened this issue Apr 9, 2019 · 6 comments · Fixed by #2600
Assignees
Labels
-transport design An issue that affects the design of the protocol; resolution requires consensus. has-consensus An issue that the Chairs have determined has consensus, by canvassing the mailing list.

Comments

@martinthomson
Copy link
Member

We don't want to prohibit the use of long headers in other versions - in case they want to share the stateless reset design, but there is no sense in sending long headers.

@martinthomson martinthomson added -transport proposal-ready An issue which has a proposal that is believed to be ready for a consensus call. labels Apr 9, 2019
@martinthomson martinthomson self-assigned this Apr 9, 2019
@mikkelfj
Copy link
Contributor

While I agree with the issue, the PR says that other versions might want to reset with a long header and therefore the receiver must inspect long headers anyway. I can see this, but given that, I think it is pointless to require the current version to only send resets for short headers. A general advice ought to suffice since the MUST is not enforceable anyway.

@martinthomson
Copy link
Member Author

The requirement exists to protect those packets from detection.

@mnot mnot added the design An issue that affects the design of the protocol; resolution requires consensus. label Apr 23, 2019
@mnot
Copy link
Member

mnot commented Apr 24, 2019

Please don't close issues until AFTER consensus is declared (not just called).

@mnot mnot reopened this Apr 24, 2019
@ianswett
Copy link
Contributor

I suspect Martin was confused because this issue was tagged has-proposal 15 days ago.

@mnot
Copy link
Member

mnot commented Apr 24, 2019

Right. The trigger is has-consensus, not has-proposal.

@ianswett
Copy link
Contributor

But it's understandable Martin would have assumed this was one of the issues that was sent out in the batch of issues a week and a half ago, given this has been tagged with has-proposal for 15 days.

@mnot mnot added has-consensus An issue that the Chairs have determined has consensus, by canvassing the mailing list. and removed proposal-ready An issue which has a proposal that is believed to be ready for a consensus call. labels May 2, 2019
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
-transport design An issue that affects the design of the protocol; resolution requires consensus. has-consensus An issue that the Chairs have determined has consensus, by canvassing the mailing list.
Projects
None yet
Development

Successfully merging a pull request may close this issue.

4 participants