Last Call Review of draft-ietf-httpbis-origin-frame-04
review-ietf-httpbis-origin-frame-04-genart-lc-carpenter-2017-11-25-00

Request Review of draft-ietf-httpbis-origin-frame
Requested rev. no specific revision (document currently at 06)
Type Last Call Review
Team General Area Review Team (Gen-ART) (genart)
Deadline 2017-11-30
Requested 2017-11-16
Other Reviews Opsdir Last Call review of -04 by Jouni Korhonen (diff)
Review State Completed
Reviewer Brian Carpenter
Review review-ietf-httpbis-origin-frame-04-genart-lc-carpenter-2017-11-25
Posted at https://mailarchive.ietf.org/arch/msg/gen-art/qwY0Y91VaFLKqnMIpG284tmWWHY
Reviewed rev. 04 (document currently at 06)
Review result Ready with Issues
Draft last updated 2017-11-25
Review completed: 2017-11-25

Review
review-ietf-httpbis-origin-frame-04-genart-lc-carpenter-2017-11-25

Gen-ART Last Call review of draft-ietf-httpbis-origin-frame-04

I am the assigned Gen-ART reviewer for this draft. The General Area
Review Team (Gen-ART) reviews all IETF documents being processed
by the IESG for the IETF Chair.  Please treat these comments just
like any other last call comments.

For more information, please see the FAQ at
<http://wiki.tools.ietf.org/area/gen/trac/wiki/GenArtfaq>.

Document: draft-ietf-httpbis-origin-frame-04.txt
Reviewer: Brian Carpenter
Review Date: 2017-11-
IETF LC End Date: 2017-11-30
IESG Telechat date: 

Summary: Ready with (minor) issues
--------


Minor Issues:
-------------

> 2.1.  Syntax
...
> Origin: An OPTIONAL sequence of characters ... that the
> sender believes this connection is or could be authoritative for.

So, that implies that all data in the ORIGIN frame might be false.
Doesn't that deserve a bit of a health warning at the beginning of the
Security Considerations? Also, using the word "believes" of a server
is strange. How would the server acquire uncertain knowledge in the
first place, and what algorithm would decide what it "believes"?

Appendix A doesn't show any sign of a client checking whether an
Origin-Entry is real.


> 2.3.  The Origin Set
...
>   o  Host: the value sent in Server Name Indication (SNI, [RFC6066]
>      Section 3), converted to lower case

In that reference:

>>  Literal IPv4 and IPv6 addresses are not permitted in "HostName".

Is that an intended or unintended restriction for the ORIGIN frame?
In any case it should probably be mentioned explicitly to avoid confusion.
(If IPv6 literals were allowed, they might be very convenient for server
load balancing. But RFC6066 excludes that.)