Hi Rob! > -----Original Message----- > From: iesg <iesg-boun...@ietf.org> On Behalf Of Robert Wilton via Datatracker > Sent: Tuesday, January 5, 2021 7:27 AM > To: The IESG <i...@ietf.org> > Cc: draft-ietf-emu-eap-tl...@ietf.org; j...@salowey.net; emu-cha...@ietf.org; > emu@ietf.org > Subject: Robert Wilton's Discuss on draft-ietf-emu-eap-tls13-13: (with > DISCUSS) > > Robert Wilton has entered the following ballot position for > draft-ietf-emu-eap-tls13-13: Discuss > > 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.) > > > Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html > for more information about IESG DISCUSS and COMMENT positions. > > > The document, along with other ballot positions, can be found here: > https://datatracker.ietf.org/doc/draft-ietf-emu-eap-tls13/ > > > > ---------------------------------------------------------------------- > DISCUSS: > ---------------------------------------------------------------------- > > Thank you for updating EAP to support TLS 1.3. > > This document is outside my area of expertise, and others will be able to > give a > better technical review. > > However, I do think that it would be useful to have a brief discussion with > the > authors/ADs about the structure of the document. I.e., this document leaves > RFC 5216 as an active updated RFC, although that RFC depends on TLS version > 1.2 (RFC 5246) that is obsoleted by TLS 1.3. > > I also note that this document contains 30 pages of updates to an RFC that is > only 32 pages long. > > Taking both of these into consideration, I think that it would be better (and > longer term probably an easier reference) if this document could stand on its > own, by obsoleting RFC 5216 and including any text from RFC 5216 that is still > relevant when using EAP with TLS 1.3. > > I appreciate that this would be a significant change and hence would welcome > input from the authors and other ADs as to whether this change would be > worth the effort.
I can see value in the streamlining and the symmetry it would bring with the approach in TLS. It is not an approach the WG considered. We'd have to weigh this tact against the substantial effort in the refactoring. IMO, since we don't have standardized semantics on "updates" (and their cascading impact), it seems easier and consistent (with at least some definition of "updates") to proceed on the slope of least resistance. Regards, Roman > Regards, > Rob > > > > _______________________________________________ Emu mailing list Emu@ietf.org https://www.ietf.org/mailman/listinfo/emu
