[Captive-portals] thoughts on two documents

[Erik Kline <[e-mail]>]

All,

I have the vague feeling that there might be some general agreement around
the idea of having an ICMP unreachable code for captive portals (like an
HTTP 511 code [https://tools.ietf.org/html/rfc6585#section-6] for ICMP :-),
and it seems like there's no objection from captive portal implementers
with respect to the basic functional elements captured in
draft-larose-capport-architecture.

Where I think some rough spots might lie for both of these is in their
integration with as-yet-undecided new behaviour.

To that point, I would like to take my co-chair hat off and ask the authors
and the group for opinions of the following.

[ draft-wkumari-capport-icmp-unreach ]

There was some unresolved discussion about the contents of any included
extension. I wonder if the extra payload parts might be removed (Dave
Dolson's comment, I think?) and thereby simplify this version of the
document.  Given that Destination Unreachable is a TCP soft error (vis. RFC
5461) I'm not sure how much the proposed extra validation semantics are
really adding.

If the document simply said that receiving and authenticating an ICMP
message with the capport code generically "MAY/SHOULD trigger the receiving
node's captive portal handling subsystem", would that be something that
folks might agree on?

We'll need to run this whole thing by intarea and 6man as well, of course.

And nothing stops us from proposing a mulit-part extension to be optionally
included in a future document, once the captive portal interaction
recommendations are more fully understood.

[ draft-larose-capport-architecture ]

I felt it was promising to hear some agreement about the functional
elements of a captive portal system as documented.

Given that the captive portal interaction process is still on-going work,
would the document authors think it worth trying to advance the document
with either (a) section 3 removed or (b) section 3 rewritten to describe
broadly how most clients behave today?  Even given the variety of clients I
think it could be roughly captured (e.g. make a few sacrificial queries to
trigger DNS/HTTP rewrites, keep trying until a sacrificial query produces
an expected result while launching an HTTP-capable application, and so on).

-Erik