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