Hello, my draft does not involve writable MIB modules, so it seems to be hard to get some attention.
So, let me just add another data point to this, hoping I can stir up some responses: Firefox OS is showing interest in a) a standard way of configuring EAP; b) our spec in particular; so there is real-world demand out there. There's a (long) bug report on the whole topic of Enterprise-Wifi-or-not; and if yes, how to do it right. https://bugzilla.mozilla.org/show_bug.cgi?id=775499 Greetings, Stefan Winter On 10.02.2014 13:53, Stefan Winter wrote: > Hello, > > I would like to draw your attention to my submission of > draft-winter-opsawg-eap-metadata-00 ( > http://datatracker.ietf.org/doc/draft-winter-opsawg-eap-metadata/ ). > > I would like to ask the community how they feel about this work - is it > needed, are we on the right track, etc. > > As a teaser for why our group thinks this piece of work is important and > useful, please see the beginning of the Problem Statement section, > pasted here for your convenience: > > "The IETF has produced the Extensible Authentication Protocol (EAP, > [RFC3748] and numerous EAP methods (for example EAP-TTLS [RFC5281], > EAP-TLS [RFC5216] and [RFC5931]); the methods have many properties > which need to be setup on the EAP server and matched as configuration > items on the EAP peer for a secure EAP deployment. > > Setting up these configuration items is comparatively easy if the > end-user devices which implement the EAP peer functionality are under > central administrative control, e.g. in closed enterprise > environments. Group policies or device provisioning by the IT > department can push the settings to user devices. > > In other environments, for example "BYOD" scenarios where users bring > their own devices which are not under enterprise control, or in EAP- > based WISP environments (see e.g. [HS20] and > [I-D.wierenga-ietf-eduroam]) where it is not desired neither for the > ISP nor for his user that the device control is in the ISPs hands, > configuration of EAP is significantly harder as it has to be done by > potentially very non-technical end users." > > There's plenty of proprietary approaches, they all vary in richness of > expressability, most don't have complete public schemas or are even in > binary with no explanations on how to construct them as an outsider. > > We find the lack of a public specification disturbing. > > It leads to duplication of efforts in numerous organisations, > incompatiblities between the produced formats, and sometimes simply > leads to bad quality specs. > > BTW, I have teased the list earlier (see my posting on 18 Dec 2013), and > already got an on-list response (as well as offline). > > I believe this warrants allocation of slot time in London, and I would > at this point ask the chairs if it's possible to get 5 mins (more if you > have plenty :-) ) to discuss the problem itself and the solution we've > put together in this first draft. > > Greetings, > > Stefan Winter > > > > _______________________________________________ > OPSAWG mailing list > [email protected] > https://www.ietf.org/mailman/listinfo/opsawg > -- Stefan WINTER Ingenieur de Recherche Fondation RESTENA - Réseau Téléinformatique de l'Education Nationale et de la Recherche 6, rue Richard Coudenhove-Kalergi L-1359 Luxembourg Tel: +352 424409 1 Fax: +352 422473 PGP key updated to 4096 Bit RSA - I will encrypt all mails if the recipient's key is known to me http://pgp.mit.edu:11371/pks/lookup?op=get&search=0xC0DE6A358A39DC66
0x8A39DC66.asc
Description: application/pgp-keys
signature.asc
Description: OpenPGP digital signature
_______________________________________________ OPSAWG mailing list [email protected] https://www.ietf.org/mailman/listinfo/opsawg
