# Shepherd Writeup for The ORIGIN HTTP/2 Frame
## 1. Summary
Patrick McManus is the document shepherd; Alexey Melnikov is the
responsible Area Director.
This document creates an [HTTP/2](https://tools.ietf.org/html/rfc7540)
extension for finer grained control of connection management than is
provided by the base HTTP/2 specification. In this context that
specifically means the set of origin names that may be served on one
connection. The document provides for changing that set to be both
smaller or larger than the default.
## 2. Review and Consensus
Participation in the document's review and discussion was unusually
broad based with members of the community from many roles taking part
(browsers, servers, CDNs, security engineers, etc..). There is broad
agreement that the functionality provides benefits to HTTP latency,
efficiency, and administrative flexibility.
Two key aspects of the draft, the ability to remove origin names from
the default set and the syntax to manage the set, underwent several
iterations based on the working group's feedback and arrived at a
The aspects of this document dealing with the relationship of HTTPS
connection management and DNS were the most controversial and required
the most change to reach consensus. This mechanism addresses
experience with RFC 7540 which shows the existing DNS based mechanism
is administratively onerous and error prone. The change also has
benefits for performance and confidentiality. On the other hand, the
change increases the importance of proper certificate security because
key compromise can now be exploited without being an on-path attacker.
The final position of the draft is that an Origin extension relaxes
the requirements for name resolution (but never certificate
verification) if a client concludes the new risks are mitigated by
alternative signals that boost confidence in the certificate. The
Security Considerations deals with the topic at some length. This
position reached rough consensus.
There are statements of intent to implement from browser, servers,
and CDNs. There is an existing browser implementation.
## 3. Intellectual Property
Each author has stated that their direct, personal knowledge of any
IPR related to this document has already been disclosed, in
conformance with BCPs 78 and 79. No IPR disclosures have been
submitted regarding this document.
## 4. Other Points
The IANA Considerations are clear and there are no downward references.