http://tools.ietf.org/html/draft-nottingham-httpbis-alt-svc as a normative reference in http/2

There was some discussion about this at the IETF89 httpbis session, and I
see that there's an altsvc branch in the github http2 repo (
https://github.com/http2/http2-spec/commits/altsvc) with a commit (
https://github.com/http2/http2-spec/commit/0afe05385c2a521079ba3874a20a21ebb1debd99)
that marks this draft as a normative reference.

I wanted to doublecheck what peoples' thoughts on this matter were. I feel
like there was some form of rough consensus assessed in the session,
although the exact details were very ambiguous to me. Currently the alt-svc
draft lists 4 use cases that could be addressed with various proposals:

(1) Upgrading HTTP/1 (" The first use case for Alternate Services is
upgrading a client from HTTP/1 to HTTP/2 for http:// URIs (i.e., without
the use of SSL or TLS).") as an alternative to HTTP Upgrade.
(2) Using TLS with http:// URIs
(3) Mitigating Load Asymmetry
(4) Segmenting Clients that Support TLS SNI

There are two mechanisms proposed for addressing these use cases. They are
the ALTSVC HTTP/2 frame and Alt-Svc HTTP response header.

My personal gauge of the rough consensus at the IETF89 httpbis session was
there was rough consensus for meeting use cases (3) and (4), both of which
require the ALTSVC frame, but not the Alt-Svc response header. Furthermore,
I think there was rough consensus around incorporating the ALTSVC frame
directly into the core HTTP/2 spec, although I remember Rob's disagreement
here (thinking that we should bring back extensible frames, and if that
doesn't get in, we use should MAY rather than SHOULD in the spec as to how
clients should handle this advisory frame).

I think that use case (1) did not get discussed at all, and (2) got raised
very briefly by Pat, but tabled due to lack of time. Both these use cases
rely on the Alt-Svc HTTP response header. I therefore do not believe
there's a rough consensus on including the Alt-Svc HTTP response header.
But perhaps further discussion will reach such a consensus.

I'd like to hear thoughts from folks on, what parts of the alt-svc draft
would be acceptable for inclusion in the HTTP/2 core spec or as a normative
reference.

FWIW, my thought would be to include the ALTSVC frame in the core spec,
with a normative reference to a standalone specification of section 3.1 in
the alt-svc draft.