On Mon, Dec 7, 2020 at 1:27 AM Erik Kline <[email protected]> wrote: > > Well done, all! > > I look forward to seeing some implementations in the future. When we > can all meet again in person we'll see if we can retry the capport > experiment on the IETF SSIDs.
Yes, probably. What would be super-useful would be if someone would be willing to provide a Captive Portal device (preferably 1: fanless, 2: small and 3: not super power hungry (which is somewhat covered by 1&2 anyway), 4: with an ability to scrub logs/not log) that we could use to actually implement the full experience. Obviously this would be on a dedicated, opt-in SSID.... Getting experiments setup / approved takes some time, and is always "best-effort" only, so starting to get this organized early would be nice... so, anyone have a widget? Or SW for a Pi? Warren "hoping we meet again soon" Kumari > > On Sun, Dec 6, 2020 at 4:45 PM Martin Thomson <[email protected]> wrote: > > > > Hey everyone, > > > > Join me in thanking the editors of the new RFC. This was good work. > > > > I'll be talking to Barry now about formally closing the group. We'll leave > > this list open in case people want to continue to discuss new work on this > > topic. > > > > On Tue, Dec 1, 2020, at 13:51, [email protected] wrote: > > > A new Request for Comments is now available in online RFC libraries. > > > > > > > > > RFC 8952 > > > > > > Title: Captive Portal Architecture > > > Author: K. Larose, > > > D. Dolson, > > > H. Liu > > > Status: Informational > > > Stream: IETF > > > Date: November 2020 > > > Mailbox: [email protected], > > > [email protected], > > > [email protected] > > > Pages: 19 > > > Updates/Obsoletes/SeeAlso: None > > > > > > I-D Tag: draft-ietf-capport-architecture-10.txt > > > > > > URL: https://www.rfc-editor.org/info/rfc8952 > > > > > > DOI: 10.17487/RFC8952 > > > > > > This document describes a captive portal architecture. Network > > > provisioning protocols such as DHCP or Router Advertisements (RAs), > > > an optional signaling protocol, and an HTTP API are used to provide > > > the solution. > > > > > > This document is a product of the Captive Portal Interaction Working > > > Group of the IETF. > > > > > > > > > INFORMATIONAL: This memo provides information for the Internet community. > > > It does not specify an Internet standard of any kind. Distribution of > > > this memo is unlimited. > > > > > > This announcement is sent to the IETF-Announce and rfc-dist lists. > > > To subscribe or unsubscribe, see > > > https://www.ietf.org/mailman/listinfo/ietf-announce > > > https://mailman.rfc-editor.org/mailman/listinfo/rfc-dist > > > > > > For searching the RFC series, see https://www.rfc-editor.org/search > > > For downloading RFCs, see https://www.rfc-editor.org/retrieve/bulk > > > > > > Requests for special distribution should be addressed to either the > > > author of the RFC in question, or to [email protected]. Unless > > > specifically noted otherwise on the RFC itself, all RFCs are for > > > unlimited distribution. > > > > > > > > > The RFC Editor Team > > > Association Management Solutions, LLC > > > > > > > > > _______________________________________________ > > > 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 > > _______________________________________________ > Captive-portals mailing list > [email protected] > https://www.ietf.org/mailman/listinfo/captive-portals -- The computing scientist’s main challenge is not to get confused by the complexities of his own making. -- E. W. Dijkstra _______________________________________________ Captive-portals mailing list [email protected] https://www.ietf.org/mailman/listinfo/captive-portals
