Note: This ballot was opened for revision 04 and is now closed.

Alexey Melnikov Yes

Comment (2018-01-06 for -04)
Need to chase minor changes based on AD review: some small changes were promised by editors.

IDNits reports:

** Downref: Normative reference to an Informational RFC: RFC 2818

RFC 2818 is already in the DownRef registry.

Alia Atlas No Objection

Deborah Brungard No Objection

Ben Campbell No Objection

Comment (2018-01-09 for -04)
I share Adam's concern about removing the need for the DNS check and his question about wildcards.

-2, first sentence: I originally read this as citing RFC 7540 for "Origin HTTTP/2 frame" rather than just "HTTP/2 frame". That is, of course, non-sensical, but the wording seems ambiguous.

Alissa Cooper No Objection

Spencer Dawkins No Objection

Comment (2018-01-08 for -04)
I don't object to publishing this document, but I do have an honest question. Is OCSP sufficiently robust and stable that you're expecting OCSP checks to work as a security mitigation? 

I remember some concerns about that in the SIP community, probably three years ago, and thought I should ask before the document is approved.

Suresh Krishnan No Objection

Warren Kumari No Objection

Comment (2018-01-08 for -04)
Please also see Jouni Korhonen's OpsDir review for nits and similar.

Mirja K├╝hlewind No Objection

Eric Rescorla No Objection

Comment (2018-01-06 for -04)
   The ORIGIN HTTP/2 frame ([RFC7540], Section 4) allows a server to
   indicate what origin(s) [RFC6454] the server would like the client to
The citation here is to the frame format. I think you could make this clearer and also point the user to that section for the conventions,

   The ORIGIN frame type is 0xc (decimal 12), and contains zero to many
Nit: "zero or more" is conventional

      serialization of an origin ([RFC6454], Section 6.2) that the
      sender believes this connection is or could be authoritative for.
What are the semantics of a zero-length origin entry? It seems like an odd thing to allow.

   Note that for a connection to be considered authoritative for a given
   origin, the client is still required to obtain a certificate that
   passes suitable checks; see [RFC7540] Section 9.1.1 for more
"Obtain" seems confusing here. Perhaps "the server is still required to authenticate using"

   viable connection to an origin open at any time.  When this occurs,
   clients SHOULD not emit new requests on any connection whose Origin
   Set is a proper subset of another connection's Origin Set, and SHOULD

Alvaro Retana No Objection

Adam Roach No Objection

Comment (2018-01-09 for -04)
This seems a good mechanism overall. The security property of no longer requiring DNS checks seems a slight bit troublesome, as it (as the draft acknowledges) makes mounting an attack significantly easier: all that is required is exploiting a CA, rather than the two-step process of doing that plus hijacking DNS in some way. Was there consideration given to advising that implementations perform DNS checks after the fact? This would provide the latency benefits this mechanism is defined for while allowing at least for detection of origin hijacking.

Is the omission of wildcard-style origins intentional? Or was this an oversight? It seems that being able to, e.g., send an ORIGIN frame that claims authority over "https://*" would be far more efficient than blasting out the several million or so origins that such machines would be authoritative for (yes, I know this won't be done in practice -- such domains simply won't be able reap the benefits of this mechanism). Ideally, I'd like to see text in here explaining why wildcards shouldn't be specified, or indicating that they might be specified in a future document.

Minor nit in Appendix B:

   Generally, this information is most useful to send before sending any
   part of a response that might initiate a new connection; for example,
   "Link" headers [RFC5988] in a response HEADERS, or links in the
   response body.

Presumably, this should reference [RFC8288].

Kathleen Moriarty No Record

Comment (2018-01-10 for -04)
I'm in agreement with Adam on his first comment and am watching the thread for a resolution.  Whether or not there is a change, more text is clearly needed in the draft.