impact of 9.2.2 changes and discussions on opportunistic encryption draft

In light of the discussion around 9.2.2, are there changes we want to
consider
making to draft-ietf-httpbis-http2-encryption that could improve
interoperability
when it is used?  Should that draft strongly encourage using TLS with
DHE/ECDHE key exchange for (P)FS, or does that dive too deeply into
the same problems with 9.2.2?

One thought that I had was that we may want the localhost Alt-Svc to
indicate
when the server does not plan to offer valid authentication.  In these
cases we may want to require key exchange via DHE/ECDHE but also pass along
an indicator so that clients requiring authentication can ignore that
Alt-Svc response.  For example,
returning this in a cleartext HTTP/1.1 response over port 80:

     Alt-Svc: h2=":443"; ma=3600; noauth

Would have the "noauth" token make it clear to clients not to expect
authentication.
I worry that without this we'll have similar interop issues where
some clients will follow the Alt-Svc expecting/requiring strong
authentication and will fail to connect when it is not present,
making it hard to use draft-ietf-httpbis-http2-encryption in any
practical manner, i.e.  for using http scheme HTTP/2 over unauthenticated
TLS for the purposes of getting past middleboxes (and for "opportunistic
security").

    Erik