> Does the working group have time now for this document? I think we should come back to this, yes.
Having given it a read over to refresh my understanding, I have a few comments. This draft seems to only be for EAP-TLS, but uses the eap.arpa domain, not tls.eap.arpa. Should this be changed? Secondly, for the 'laptop in coffee shop' example, which I see as the most useful use for something like this, the draft seems a little lacking. After I've connected to the local coffee shop WiFi with this protocol, what do I (as a device) do next? Is a captive portal API mandatory? How do I transition to an unrestricted connection? What do I do with the output of EAP-TLS i.e. the verified domain name of the server? Q Ar Gwen, 25 Gorff 2025 am 16:16 Michael Richardson <mcr+i...@sandelman.ca> ysgrifennodd: > > Peter Yee <pe...@akayla.com> wrote: > > EAP defaults for devices that need to onboard (see > > > https://datatracker.ietf.org/doc/draft-richardson-emu-eap-onboarding/). > Previously > > presented at IETF 114 prior to when the eap.arpa material was > separated > > out into a separate draft. Use unauthenticated EAP-TLS and a captive > > portal to provision credentials for a device. > > Given that EAP.ARPA document has passed WGLC, does the working group have > time now for this document? > > -- > Michael Richardson <mcr+i...@sandelman.ca>, Sandelman Software Works > -= IPv6 IoT consulting =- *I*LIKE*TRAINS* > > > > _______________________________________________ > Emu mailing list -- emu@ietf.org > To unsubscribe send an email to emu-le...@ietf.org >
_______________________________________________ Emu mailing list -- emu@ietf.org To unsubscribe send an email to emu-le...@ietf.org
