Here is a PR which I think addresses most of the comments - https://github.com/emu-wg/charter/pull/5/files. It removes text that refers to work items that have already left the working group.
On Tue, Jun 3, 2025 at 2:00 PM Joseph Salowey <j...@salowey.net> wrote: > Thanks for the review, responses inline: > > On Mon, Jun 2, 2025 at 6:51 AM Éric Vyncke via Datatracker < > nore...@ietf.org> wrote: > >> Éric Vyncke has entered the following ballot position for >> charter-ietf-emu-07-00: Block >> >> When responding, please keep the subject line intact and reply to all >> email addresses included in the To and CC lines. (Feel free to cut this >> introductory paragraph, however.) >> >> >> >> The document, along with other ballot positions, can be found here: >> https://datatracker.ietf.org/doc/charter-ietf-emu/ >> >> >> >> ---------------------------------------------------------------------- >> BLOCK: >> ---------------------------------------------------------------------- >> >> Thanks for the rechartering effort, as usual in a charter, I am expecting >> to >> see the intended status of all work items (probably PS in all the work >> items). >> >> > Yes, the intended status is proposed standard, > > "In summary, the working group shall produce the following standards track > documents:" > > >> The charter also mention OoB work but nothing appears to be listed so in >> the >> work items list. >> >> > [Joe] This work has mostly been completed, EAP-NOOB has been published as RFC > 9140 <https://datatracker.ietf.org/doc/rfc9140/>. Also EAP-TLS-POK is a > working group item that is also based on out-of-band DPP provisioning - > https://datatracker.ietf.org/doc/draft-ietf-emu-bootstrapped-tls/. This > work should go to the iESG after I finish the Shepherd writeup for a > related TLS spec. If you still think we need to make a change I think we > could resolve this by either modifying the following item for EAP-TLS-POK > to make it clear that there is an out of band piece > > "Define mechanisms by which EAP methods can support creation of long-term > credentials for the peer based on initial limited-use credentials exchanged > out of band." > > Or we can remove the paragraph about OOB from the charter since it is > completed work. > > >> The two above blocking points should be trivial to be addressed. >> >> >> ---------------------------------------------------------------------- >> COMMENT: >> ---------------------------------------------------------------------- >> >> And, here are some non-blocking comments: >> >> Should there be a "used" in `AP is now more broadly in mobile network >> authentication` (also noted by Erik Kline) else I cannot parse it. >> > > Yes the sentence should be: > > "At the same time, some new use cases for EAP have been identified. EAP is > now more broadly used in mobile network authentication." > > >> While adding PFS as a requirement, what about post-quantum or randomised >> and >> changing MAC addresses (with my MADINAS bias here). Should there be some >> links >> with IEEE 802 work ? >> > > [Joe] We do have an item for the maintenance of existing EAP methods which > could cover updates for PQ. Do you think we should call it out > specifically? > > EAP does not deal directly with the MAC address layer, I think it may be > distracting to point to MAC address randomization work in the charter. > > >> >> I also cannot parse the rather complex (and possibly incomplete) ` for >> keeping >> the identity provider for that user from tracking what networks or >> services a >> specific user is accessing` >> >> Is this better? > > "An EAP method that provides privacy by preventing a visited network or > service from knowing the identity of a user, and for keeping the user's > identity provider from tracking what networks or services the user is > accessing." >
_______________________________________________ Emu mailing list -- emu@ietf.org To unsubscribe send an email to emu-le...@ietf.org
