Subject: [Captive-portals] IETF 100: agenda and administrative items

From: Erik Kline <[email-masked]>
Date: Mon, 30 Oct 2017 11:38:34 +0900

All,

A few requests for our meeting in Singapore.  If anyone has additional
agenda items they would like to present or see discussed, please reply
and let us know.

Thanks,
-Erik

--

[1] In the absence of a newly uploaded draft-ietf version of the
adopted API document the group will take a few minutes to consider
appointing new editors.

[2] Would someone be willing to present on requirements for
identifiers used by infrastructure to correlate activity with captive
clients?  (See the thread "client identifying info between API and
enforcement".)

A discussion of link layer based identifiers versus IP based
identifiers would be worth having.  We might want to define the
general requirements, and then make explicit recommendations for what
to do when the enforcement point is on-link and when it's off-link.

[3] In light of [2], would {David Bird or Kyle Larose / Dave Dolson}
be willing to lead a discussion of the contents of the proposed
extended captive portal ICMP option?

Issues include:

    - Scope: How should the client interpret the breadth of the
captivity: limited to the given source address, to the destination
address, the src-dst pair, full 5-tuple?

    - Correlation: How does the client use the signalled information
in its communications with the API endpoint?  (and can the information
be reduced to a single, opaque token)

---

From: David Bird <[email-masked]>
Date: Mon, 30 Oct 2017 06:10:44 -0700

I will not be in Singapore, but here are slides about Capport ICMP from the
last meeting:
https://datatracker.ietf.org/meeting/99/materials/slides-99-capport-icmp/

It doesn't surprise me that the (adopted) API draft hasn't made progress;
its purpose, necessity, and requirements haven't been well established.
We've seen several suggestions of functions (from both API and PvD), but
those have largely been downgraded, removed, or moved to Appendices. I
think today we are (finally, after more than 2 years) talking about ICMP
for signaling, but still the emphasis is on the "API". The only function I
can think of for the API is a iteration on WISPr (an XML based API that
exists today) for pre-credentialed clients to automatically login.

On Sun, Oct 29, 2017 at 7:38 PM, Erik Kline <[email-masked]> wrote:

> _______________________________________________
> Captive-portals mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/captive-portals
>
>