Subject: [Emu] Éric Vyncke's No Objection on draft-ietf-emu-eap-tls13-13: (with COMMENT)

From: Éric Vyncke via Datatracker <[email-masked]>
Date: Thu, 10 Dec 2020 06:13:47 -0800

Éric Vyncke has entered the following ballot position for
draft-ietf-emu-eap-tls13-13: No Objection

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/

----------------------------------------------------------------------
COMMENT:
----------------------------------------------------------------------

Thank you for the work put into this document. Improving EAP-TLS is indeed
welcome! BTW, I left the security review to the SEC Area Directors.

Please find below some non-blocking COMMENT points (but replies would be
appreciated), and some nits.

I hope that this helps to improve the document,

Regards,

-éric

== COMMENTS ==

-- Abstract --
Should the abstract briefly talk about EAP?

-- Section 1 --
Should "ietf-tls-oldversions-deprecate" be normative ?

-- Section 2 --
Nicely done to have kept the same sub-section numbers with respect to RFC 5216.
Kudos !

-- Section 2.1.1 & 2.1.3 & 2.1.4 --
I find "This section updates Section 2.1.1 of [RFC5216]." a little ambiguous as
it the 'updated section' is not identified clearly. I.e., as the sections in
RFC 5216 are not too long, why not simply providing whole new sections ?

-- Section 5.9 --
What is the added benefit of this section (pervasive monitoring) compared to
section 5.8 (privacy considerations)? Esp when I am afraid that pervasive
monitoring is deeper in the network rather than in the access network (happy to
be corrected)

== NITS ==

None of us are native English speaker, but "e.g." as "i.e." are usually
followed by a comma while "but" has usually no comma before ;-)

---

From: Mohit Sethi M <[email-masked]>
Date: Wed, 16 Dec 2020 11:18:58 +0000

Hi Éric,

Thank you for your review. Answers in-line:

> https://datatracker.ietf.org/doc/draft-ietf-emu-eap-tls13/
Good point. I have updated the draft in github: 
https://github.com/emu-wg/draft-ietf-emu-eap-tls13/commit/baaf9a03c5f282e9904da60700687e248bebe28c
> Should "ietf-tls-oldversions-deprecate" be normative ?
I believe that informational is the correct choice. We are only 
informing readers and implementers of this draft that old versions of 
TLS (1.0 and 1.1) are being deprecated. They don't strictly need that 
information for implementing EAP-TLS with TLS 1.3. However, I don't have 
strong opinions and can reconsider.
> Nicely done to have kept the same sub-section numbers with respect to RFC 5216.
Thank you for the positive feedback.
> RFC 5216 are not too long, why not simply providing whole new sections ?
You have a valid point. However, since this document updates and not 
obsoletes RFC 5216, we found it sub-optimal to repeat the text. We have 
written this document for a developer who already has an EAP-TLS 
implementation and wants to update it for use with TLS 1.3. Thankfully, 
large parts of the update complexity are actually handled by the 
underlying TLS library leaving only a small amount of change needed from 
an EAP-TLS developer.
> followed by a comma while "but" has usually no comma before ;-)

Good point. I think I have added a comma after all instances now: 
https://github.com/emu-wg/draft-ietf-emu-eap-tls13/commit/7cbce9b8c3ad05a6406a8c48d5b1cbefe23faf47

--Mohit

>
>
>
> _______________________________________________
> Emu mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/emu