The ALPN HTTP Header Field
draft-ietf-httpbis-tunnel-protocol-05

ABNF is (has?) been fixed as a part of the Gen-ART review comments from Christer. Make sure these edits are folded in before the draft is approved.

I support Stephen's discuss and comments.

It looks like the discussion on Stephen's comments addressed the concern I had as a discuss, so I removed that and will follow along with his discuss and comments to address authentication.

I'm a no-objection, because I'm assuming that this specification doesn't also map to CoAP and DTLS. If that's a bad assumption, please tell me, and I'll look at it through those lenses.

In this text,

   The HTTP CONNECT method (Section 4.3.6 of [RFC7231]) requests that
   the recipient establish a tunnel to the identified origin server and
   thereafter forward packets, in both directions, until the tunnel is
   closed.  Such tunnels are commonly used to create end-to-end virtual
   connections, through one or more proxies.
                        ^^^^^^^^^^^
                        
it may be obvious to everyone else how to do this through multiple proxies, and I bet I could guess how given two or three guesses, but I didn't see any description in the document of how to do that. 

Is any description needed?

Thanks for handling my discuss. 

--- OLD COMMENTS below, I didnt' check 'em.

- I can see situations where I might want to not tell the proxy
what protocol I'll be using inside TLS and when TLS1.3 hides
ALPM from the proxy (I hope:-) then could there be value
registering a "I'm not telling" ALPN value so that a UA
wouldn't have to lie to the proxy?

- I think you ought say what you expect a proxy to do if the
ALPN header field and the ALPN TLS extension value do not match
and I think that ought say that a CONNECT recipient in such
cases SHOULD NOT drop the connection solely on that basis.  If
they have some policy about it fine, but they shouldn't barf
just because there's a different order or spelling or just a
different value.

- Replicating values at multiple protocol layers produces a
common failure mode where code only uses one copy to do access
control or authorization or where two nodes in sequence use
different copies, with unexpected behaviour resulting. I think
you should call that out in the security considerations section
as it keeps happening.