The WIP is up on GitHub here: https://github.com/capport-wg/api <https://github.com/capport-wg/api>
Thanks, Tommy > On Jan 16, 2018, at 10:24 AM, David Bird <[email protected]> wrote: > > Do we have a preliminary draft of the API yet? > > Requirements, purpose, whatnot... > > On Mon, Dec 4, 2017 at 12:39 PM, David Bird <[email protected] > <mailto:[email protected]>> wrote: > Looking forward to it! > > > On Mon, Dec 4, 2017 at 12:35 PM, Tommy Pauly <[email protected] > <mailto:[email protected]>> wrote: > Darshak Thakore and I are now the editors of the API document, and will be > posting a new version of the document hopefully soon that addresses the > discussions from the previous two IETF meetings. This definition will be a > lot simpler, and should make it clearer how to interact with the ICMP path. > > Thanks, > Tommy > > >> On Dec 4, 2017, at 9:11 AM, David Bird <[email protected] >> <mailto:[email protected]>> wrote: >> >> I will also point out that the API is not only ill-defined, it doesn't have >> editors... right? >> >> On Mon, Dec 4, 2017 at 9:08 AM, David Bird <[email protected] >> <mailto:[email protected]>> wrote: >> These are good questions for the group to consider and provide feedback on... >> >> While doing so, also consider the fact that the "The basic problem is that >> the enforcement point and API are two different entities." is a problem of >> our own creation in an effort to support an API that we haven't clearly >> defined. >> >> I suggest rethinking the problem, let the extra ICMP semantics sink in, and >> consider the fact that we could achieve similar use-cases (if not identical, >> even more use-cases) without the above "basic problem" ... >> >> The use-cases I speak of specially are: >> >> - A way to better identify captivity in the network and feedback (on a need >> to know basis) of what resources are allowed in the walled garden. >> - A non-redirect (non-flow terminating) way of notifying of pending session >> interruptions or otherwise suggesting a portal visit. >> - A deployment model that doesn't put huge requirements on systems >> integrations and installers. >> >> >> On Sun, Dec 3, 2017 at 11:53 PM, Martin Thomson <[email protected] >> <mailto:[email protected]>> wrote: >> Thanks Kyle for the summary of the discussion. >> >> The chairs would like to focus your attention on the issue of User >> Equipment identification. The basic problem is that the enforcement >> point and API are two different entities. They might also need to >> talk about the UE with other entities (RADIUS servers, logging >> systems, payment systems, and all sorts of backend systems). >> >> How should the UE be identified? >> >> We had a great discussion about this in Singapore and it's the view of >> the chairs that there was no consensus for defining a set of UE >> identifiers for explicit use in the protocols. There were a few >> reasons for this. One was that it would be difficult to find a set of >> identifiers that would work for all deployments. Also, allowing the >> UE to include identifiers would increase the risk that the UE spoofs >> those identifiers. >> >> The two options that were discussed at length both involved having the >> UE identified implicitly. That is, some property of the packets that >> arrive at the enforcement point would be used to identify the UE. The >> concern being that the identifier(s) were not subject to spoofing. >> MAC, IP, or the circuit on which the packets arrive might all be >> acceptable. >> >> There was some discussion about how to manage consistent >> identification between API and enforcement. From the discussion, we >> appear to have two options: >> >> 1. Identify the UE at the API the same way that it is identified at >> enforcement. API and enforcement would have to agree on the >> identifier they use. This would also constrain deployments so that >> the API has to be located on the network in a position where >> spoofing identifiers isn't possible. >> >> 2. Have the enforcement device pass an identifier (a "session ID") to >> the UE for use with the API. The enforcement would probably use an >> ICMP extension to pass this information back. This would need to be >> authenticated, so that the UE couldn't generate a valid identifier. >> There was plenty of discussion about that, but the short summary is >> that this is possible if we want to have it happen. >> >> It seems like there is some sense that the first option was preferred. >> We'd like to get a sense of the list here. Which of these options is >> preferable, and why? >> >> _______________________________________________ >> Captive-portals mailing list >> [email protected] <mailto:[email protected]> >> https://www.ietf.org/mailman/listinfo/captive-portals >> <https://www.ietf.org/mailman/listinfo/captive-portals> >> >> >> _______________________________________________ >> Captive-portals mailing list >> [email protected] <mailto:[email protected]> >> https://www.ietf.org/mailman/listinfo/captive-portals >> <https://www.ietf.org/mailman/listinfo/captive-portals> > > > > _______________________________________________ > 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
