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

Consolidate connection ID negotiation section with prior text #1888

Merged
merged 3 commits into from Oct 23, 2018

Conversation

martinthomson
Copy link
Member

The text here was mostly good, and I believe that this is a good place
for that text. However, some of the text was expository in nature, and
I moved that up to the connection ID definition section. There is some
new stuff in there, mostly just to point forward to the negotiation
section.

The text here was mostly good, and I believe that this is a good place
for that text.  However, some of the text was expository in nature, and
I moved that up to the connection ID definition section.  There is some
new stuff in there, mostly just to point forward to the negotiation
section.
@martinthomson martinthomson added editorial An issue that does not affect the design of the protocol; does not require consensus. -transport labels Oct 19, 2018
draft-ietf-quic-transport.md Outdated Show resolved Hide resolved
Packets with short headers ({{short-header}}) only include the Destination
Connection ID and omit the explicit length. The length of the Destination
Connection ID field is expected to be known to endpoints. Endpoints using a
connection-ID based load balancer could agree with the load balancer on a fixed
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

connection-ID -> Connection ID

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I think what was meant here is "Connection ID-based load balancer" (dash between ID and based). This would look odd because Connection ID is two words. This can be reworded as "using a load balancer based on Connection IDs."

Copy link
Contributor

@MikeBishop MikeBishop left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

LGTM.

draft-ietf-quic-transport.md Outdated Show resolved Hide resolved
draft-ietf-quic-transport.md Outdated Show resolved Hide resolved
Packets with short headers ({{short-header}}) only include the Destination
Connection ID and omit the explicit length. The length of the Destination
Connection ID field is expected to be known to endpoints. Endpoints that use a
load balancer that routes based on connection ID could agree with the load
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Run on sentence ("that ... that"). I prefer the earlier construction: "Endpoints using a connection-ID based load balancer could agree with the load balancer on a fixed or minimum length and on an encoding for connection IDs."

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

It has all the problems already highlighted, plus the precedence of the "or" and "and" toward the end is unclear. I've tweaked again.

@janaiyengar janaiyengar merged commit c49a405 into master Oct 23, 2018
@martinthomson martinthomson deleted the fix-cid-nego branch October 25, 2018 03:11
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
-transport editorial An issue that does not affect the design of the protocol; does not require consensus.
Projects
None yet
Development

Successfully merging this pull request may close these issues.

None yet

6 participants