HTTP Alternative Services
draft-ietf-httpbis-alt-svc-14

[Ballot comment]
A clear sentence such as this one would have helped me:
OLD:
  This specification defines a new concept in HTTP, "Alternative
  Services", that allows an origin server to nominate additional means
  of interacting with it on the network. 
NEW:
  This specification defines a new concept in HTTP, "Alternative
  Services", applicable to both HTTP 1.1 and HTTP 2.0, that allows
  an origin server to nominate additional means of interacting with
  it on the network. 

I overlooked this info in the following sentence, i.e. the fact that HTTP header = HTTP 1.1:

  It defines a general
  framework for this in Section 2, along with specific mechanisms for
  advertising their existence using HTTP header fields (Section 3) or
  HTTP/2 frames (Section 4), plus a way to indicate that an alternative
  service was used (Section 5).

[Ballot comment]
A couple of very nitty nits.

In this text

  When the protocol does not explicitly carry the scheme (e.g., as is
  usually the case for HTTP/1.1 over TLS, servers can mitigate this
                                        ^
I think there's a missing closing parenthesis right around here.

If there's not, I'm having trouble parsing the sentence.
                                       
  risk by either assuming that all requests have an insecure context,
  or by refraining from advertising alternative services for insecure
  schemes (such as HTTP).
 
If there was an obvious reference for SPDY in this text

  The Alt-Svc header field was influenced by the design of the
  Alternate-Protocol header field in SPDY.
 
that might be useful to include.

[Ballot comment]
Just a few minor comments:

= Substantive =

- 2.2, last paragraph:

Why might a client choose not to to remove non-persistent alternatives from cache on a network change? (i.e., why not MUST)?

- 2.4, first 2 paragraphs:

These paragraphs seem to be equivalent to saying “Clients MAY use alternative services; also they SHOULD.”  Or is the intent that, if a client uses alternative services, it SHOULD do so under these conditions?

= Editorial =

- 2.3, first paragraph:
I find "MUST only" constructions to be confusing and sometimes ambiguous due to the implied NOT. I suggest making that explicit:
OLD
  A client MUST only use a TLS-based alternative service if the client also supports TLS Server Name Indication (SNI).
NEW
  A client MUST NOT use a TLS-based alternative service unless the client supports TLS Server Name Indication (SNI).

[Ballot comment]

- If TLS1.3 continues to have 0rtt replayable early-data,
could that interact badly with Alt-Svc? Or what about
false-start? For example, if such a combination meant that an
otherwise functional replay detection scheme would fail to
spot a replay that would be bad. This is not a DISCUSS, as
neither TLS1.3 nor false-start are formally "done" so blocking
this for that reason would be "odd";-) However, both are
implemented or will be, so I would love to chat about it and
that might lead to some new security considerations text, here
or in a TLS document.

- Does this still all work for opportunistic security for
HTTP? If not, why not? Note: I'm not asking if the WG have
reached consensus on oppo, rather I'd like to be reassured
that if they do, this will still work for that. I think that's
all ok, though, right?

- section 3: with "clear" you say alternatives are to be
invalidated. Does that mean anything about cached resources? I
assume not, but just checking.

- section 5: I wondered why you didn't include the ALPN
identifier here?

- 9.2: What does "might also choose" mean and which "other
requirements" have you in mind? That's very vague.

- 9.5: What are you telling me with the last para?

[Ballot comment]
Couple of places where the language used was confusing for me:

= Sec 2.4 =

s/it can be used until the alternative connection is established./the existing connection can be used until the alternative connection is established./

= Sec 3.1 =

OLD
Unknown parameters MUST be ignored, that is
  the values (alt-value) they appear in MUST be processed as if the
  unknown parameter was not present.

NEW
Unknown parameters MUST be ignored. That is,
  the values (alt-value) in which they appear MUST be processed as if the
  unknown parameters were not present.

(Via drafts-lastcall-comment@iana.org): IESG/Authors/WG Chairs:

IANA has completed its review of draft-ietf-httpbis-alt-svc-12.txt. If any part of this review is inaccurate, please let us know.

IANA understands that, upon approval of this document, there are three actions which IANA needs to complete.

First, in the Permanent Message Header Field Names subregistry of the Message Headers registry located at:

https://www.iana.org/assignments/message-headers/

two new message header fields will be added as follows:

Header Field Name: Alt=Svc
Template:
Protocol: http
Status: standard
Reference: [ RFC-to-be ]

Header Field Name: Alt-Used
Template:
Protocol: http
Status: standard
Reference: [ RFC-to-be ]

As this document requests registrations in an Expert Review or Specification Required (see RFC 5226) registry, we will initiate the required Expert Review via a separate request. Expert review will need to be completed before your document can be approved for publication as an RFC.

Second, in the HTTP/2 Frame Type subregistry of the Hypertext Transfer Protocol version 2 (HTTP/2) Parameters registry located at:

https://www.iana.org/assignments/http2-parameters/

a single, new frame type will be registered as follows:

Code: [ TBD-at-Registratio ]
Frame Type: ALTSVC
Reference: [RFC-to-be, Section 4 ]

IANA notes that the draft requests that the value '0xa' be used for the code in this registration.

Third, a new top-level registry will be created at the IANA Matrix located at:

https://www.iana.org/protocols

named the HTTP Alt-Svc Parameter Registry. This new registry is to be maintained through Expert Review as defined in RFC 5226.

There are initial registrations in the new registry as follows:

+-------------------+----------------------------+
| Alt-Svc Parameter | Reference |
+-------------------+----------------------------+
| ma | [ REC-to-be, Section 3.1 ] |
| persist | [ REC-to-be, Section 3.1 ] |
+-------------------+----------------------------+

IANA understands that these are the only actions required to be completed upon approval of this document.

Note:  The actions requested in this document will not be completed until the document has been approved for publication as an RFC. This message is only to confirm what actions will be performed. 


Thank you,

Sabrina Tanamal
IANA Specialist
ICANN

The following Last Call announcement was sent out:

From: The IESG
To: "IETF-Announce"
CC: httpbis-chairs@ietf.org, michael.bishop@microsoft.com, draft-ietf-httpbis-alt-svc@ietf.org, "Mike Bishop" , ietf-http-wg@w3.org, barryleiba@gmail.com
Reply-To: ietf@ietf.org
Sender:
Subject: Last Call:  (HTTP Alternative Services) to Proposed Standard


The IESG has received a request from the Hypertext Transfer Protocol WG
(httpbis) to consider the following document:
- 'HTTP Alternative Services'
  as Proposed Standard

The IESG plans to make a decision in the next few weeks, and solicits
final comments on this action. Please send substantive comments to the
ietf@ietf.org mailing lists by 2016-02-24. Exceptionally, comments may be
sent to iesg@ietf.org instead. In either case, please retain the
beginning of the Subject line to allow automated sorting.

Abstract


  This document specifies "Alternative Services" for HTTP, which allow
  an origin's resources to be authoritatively available at a separate
  network location, possibly accessed with a different protocol
  configuration.




The file can be obtained via
https://datatracker.ietf.org/doc/draft-ietf-httpbis-alt-svc/

IESG discussion can be tracked via
https://datatracker.ietf.org/doc/draft-ietf-httpbis-alt-svc/ballot/


No IPR declarations have been submitted directly on this I-D.

# Shepherd Writeup for Alt-Svc

## 1. Summary

Mike Bishop is the document shepherd; Barry Leiba is the responsible
Area Director.

This document specifies a method to provide clients authoritative access
to HTTP origins at a different network location and/or using a different
protocol stack.

The requested publication type is Proposed Standard.

## 2. Review and Consensus

The document started as an individual draft which provided a potential
solution to several related problems in the HTTP space, helping clients
become aware of multiple network or protocol endpoints for an origin
that could serve the same content in different ways. It drew inspiration
from an existing proprietary solution, Alternate-Protocol, used by
Chromium during SPDY development.

There was implementation interest from Mozilla Firefox and Akamai, along
with willingness from Google Chrome to migrate from Alternate-Protocol
to Alt-Svc. Other implementers were less interested, but as the behavior
is fully optional for clients, the consensus was to adopt the document.
During the HTTP/2 standardization process, the Alt-Svc document was
discussed and worked on in parallel; HTTP/2-specific pieces were
originally added to the HTTP/2 specification at the time of adoption,
but were moved into this document after HTTP/2's extension story was
agreed upon.

There has been some interest in defining additional ways to discover
Alternative Services, and this document intentionally does not close the
door on that. It discusses client behavior when dealing with
Alternatives of which it is aware, and defines two possible ways a
client can learn about Alternatives. Future drafts may define additional
ways, such as DNS.

Technical discussions involved a broad section of the working group,
with the most focus from a few client and proxy implementers. There has
been some back and forth about the right balance between utility and
security, but the document now reflects general consensus. This is
reflected by a thoroughly-discussed Security Considerations section,
which covers ways in which Alt-Svc could be used to track clients or
persist attacks, and gives guidance to implementations on ways to
minimize the potential impacts.

## 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 disclosures have been submitted regarding prior work in this space.

## 4. Other Points

There are no downward references. The IANA Considerations are clear, and
the Expert Reviewers for the existing registries have been actively
involved in the draft process. A new registry is also created for
parameters modifying properties of Alt-Svc listings.

There was some discussion over whether parameters would be
mandatory-to-understand (ignoring the entire entry otherwise), or always
optional. In the end, parameters were made optional-to-understand in all
cases, to avoid exploding the list of alternatives when multiple
optional parameters were used.