There have been some recent reviews for EAP-NOOB. I think it would be prudent to wait until this round of comments are resolved before moving forward with the request for early allocation.
On Tue, May 26, 2020 at 1:53 AM Mohit Sethi M <mohit.m.se...@ericsson.com> wrote: > I would add that there is also an early implementation of EAP-TLS-PSK: > https://github.com/rohitshubham/EAP-TLS-PSK > > We had agreed that external PSK authentication for EAP-TLS will use a new > method type number. The draft for EAP-TLS-PSK ( > https://tools.ietf.org/html/draft-mattsson-emu-eap-tls-psk-00) is still > in the early stages and will undergo many changes before it can be > considered for adoption by the working group. However, allocating a method > type number for EAP-NOOB now would ensure that EAP-TLS-PSK doesn't use the > same code point. > > --Mohit > On 5/26/20 6:56 AM, Joseph Salowey wrote: > > The authors of EAP-NOOB (draft-ietf-emu-eap-noob) have requested early > allocation of the EAP type code value 56. If you object to the early code > point assignment please let the list know why by June 14, 2020. > > The criteria for early assignment includes the following: > > A. The code points must be from a space designated as "RFC Required", > "IETF Review", or "Standards Action". Additionally, requests for early > assignment of code points from a "Specification Required" registry are > allowed if the specification will be published as an RFC. > > EAP Methods have an allocation policy of Designated Expert, with > Specification Required. The specification in this case the > draft-ietf-emu-eap-noob. > > B. The format, semantics, processing, and other rules related to handling > the protocol entities defined by the code points henceforth called > "specifications") must be adequately described in an Internet-Draft. > > The specification draft-ietf-emu-eap-noob-00 contains the protocol > specifics. There are implementations based on this specification listed > below > > C. The specifications of these code points must be stable; i.e., if there > is a change, implementations based on the earlier and later specifications > must be seamlessly interoperable. > > Although the document is a 00 document, the predecessor document > draft-aura-eap-noob > <https://datatracker.ietf.org/doc/draft-aura-eap-noob/> has been > discussed for over a year. This call is a request for working group > members to review the document and object if the specification is not > stable. > > D. There is sufficient interest in the community for early (pre-RFC) > implementation and deployment, or that failure to make an early allocation > might lead to contention for the code point in the field. > > Several implementations exist, but it would be good to see if there is > additional interest in implementing this protocol > > The authors note that currently, the following implementations of EAP-NOOB > exist: > > 1. Implementation with wpa_supplicant (client) and hostapd (server): > https://github.com/tuomaura/eap-noob > > 2. Lightweight implementation on Contiki (client only): > https://github.com/eduingles/coap-eap-noob (Tested with server > implementation from #1) > > 3. Minimal EAP-NOOB (based on #1 with cleaner code and updates to match > current draft version): https://github.com/Vogeltak/eap-noob > > Thanks, > > Joe > > _______________________________________________ > Emu mailing listEmu@ietf.orghttps://www.ietf.org/mailman/listinfo/emu > >
_______________________________________________ Emu mailing list Emu@ietf.org https://www.ietf.org/mailman/listinfo/emu
