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 protected]> wrote: > 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) > > _______________________________________________ > Captive-portals mailing list > [email protected] > https://www.ietf.org/mailman/listinfo/captive-portals > >
_______________________________________________ Captive-portals mailing list [email protected] https://www.ietf.org/mailman/listinfo/captive-portals
