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

active_connection_id_limit description is unclear about whose connection ID might be zero length #3427

Closed
nharper opened this issue Feb 5, 2020 · 1 comment · Fixed by #3426
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

@nharper
Copy link
Contributor

nharper commented Feb 5, 2020

The current language defining the active_connection_id_limit transport parameter refers to "a zero-length connection ID is being used". It's unclear whether the zero-length CID is the CID of the sender of the TP or the receiver of the TP. Since this TP limits how many CIDs the peer can send, the references to using a zero-length CID only make sense if it's the peer using a zero-length CID, but it would be useful to clean up that language.

I've created PR #3426 to clarify this language, including that checking whether the peer is using a zero-length CID can only be done by the server.

@mnot mnot added this to Triage in Late Stage Processing Feb 5, 2020
@larseggert larseggert added the editorial An issue that does not affect the design of the protocol; does not require consensus. label Feb 6, 2020
@project-bot project-bot bot moved this from Triage to Editorial Issues in Late Stage Processing Feb 6, 2020
@martinthomson martinthomson removed the editorial An issue that does not affect the design of the protocol; does not require consensus. label Apr 7, 2020
@martinthomson
Copy link
Member

Chairs, the fix here turned out to be more complex. Let's get wider review for this.

@martinthomson martinthomson moved this from Editorial Issues to Triage in Late Stage Processing Apr 7, 2020
@LPardue LPardue added the design An issue that affects the design of the protocol; resolution requires consensus. label Apr 7, 2020
@project-bot project-bot bot moved this from Triage to Design Issues in Late Stage Processing Apr 7, 2020
@martinthomson martinthomson added proposal-ready An issue which has a proposal that is believed to be ready for a consensus call. and removed design An issue that affects the design of the protocol; resolution requires consensus. labels Apr 7, 2020
@project-bot project-bot bot moved this from Design Issues to Consensus Emerging in Late Stage Processing Apr 7, 2020
@martinthomson martinthomson added the design An issue that affects the design of the protocol; resolution requires consensus. label Apr 7, 2020
@project-bot project-bot bot moved this from Consensus Emerging to Design Issues in Late Stage Processing Apr 7, 2020
@martinthomson martinthomson moved this from Design Issues to Consensus Emerging in Late Stage Processing Apr 7, 2020
@LPardue LPardue added call-issued An issue that the Chairs have issued a Consensus call for. and removed proposal-ready An issue which has a proposal that is believed to be ready for a consensus call. labels Apr 29, 2020
@project-bot project-bot bot moved this from Consensus Emerging to Consensus Call issued in Late Stage Processing Apr 29, 2020
@LPardue LPardue added has-consensus An issue that the Chairs have determined has consensus, by canvassing the mailing list. and removed call-issued An issue that the Chairs have issued a Consensus call for. labels May 13, 2020
@project-bot project-bot bot moved this from Consensus Call issued to Consensus Declared in Late Stage Processing May 13, 2020
Late Stage Processing automation moved this from Consensus Declared to Issue Handled May 17, 2020
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
Late Stage Processing
  
Issue Handled
Development

Successfully merging a pull request may close this issue.

4 participants