On Mon, Dec 7, 2020 at 1:27 AM Erik Kline <ek.i...@gmail.com> 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 <m...@lowentropy.net> 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, rfc-edi...@rfc-editor.org 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: k...@agilicus.com, > > > ddol...@acm.org, > > > liucou...@google.com > > > 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 rfc-edi...@rfc-editor.org. 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 > > > Captive-portals@ietf.org > > > https://www.ietf.org/mailman/listinfo/captive-portals > > > > > > > _______________________________________________ > > Captive-portals mailing list > > Captive-portals@ietf.org > > https://www.ietf.org/mailman/listinfo/captive-portals > > _______________________________________________ > Captive-portals mailing list > Captive-portals@ietf.org > 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 Captive-portals@ietf.org https://www.ietf.org/mailman/listinfo/captive-portals
