Hi this is my ARTART review of draft-ietf-emu-aka-pfs-10. Note that I provided comments on an early version of this I-D when it was still being working in EMU.  I am going to read this with my ARTART glasses on.

Since all of my comments were editorial nits, I submitted them via the following PR:
https://github.com/emu-wg/eap-aka-pfs/pull/45

I included them here too.

1) abstract & intro: SIM expanded later so move it up.

  1st para: s/SIM/Subscriber Identity Module (SIM)
  2nd para: s/Subscriber Identity Module (SIM)/SIM

2) In the abstract this is a bit awkward:

  However, the danger of resourceful
  attackers for these systems is still a concern.  Always assuming
  breach such as key compromise and minimizing the impact of breach are
  essential zero-trust principles.

Maybe:

  However, resourceful attackers are always a cause for concern.  Always assuming a
  breach, such as key compromise, and minimizing the impact of breach are
  essential zero-trust principles.

3) s1 includes the following:

   They are a high-value target and concern a large number of
   people.

Is it that a large number of people are concerned about the high-value target or that it affects a large number of people if compromised? I assume the later based on text later in this section.

4) s1 includes the following:

  … gaining unlawful access to key material

Is it unlawful or unauthorized? I assume unauthorized as it includes unlawful.

5) s1 includes the following:

OLD:

While the better protection
   of manufacturing and other processes is essential in protecting
   against this, there is one question that we as protocol designers can
   ask.  Is there something that we can do to limit the consequences of
   attacks, should they occur?

Could this be restated as:

  While better protections for manufacturing
  and other processes are essential to mitigate these attacks, there
  is one question that protocol designers can ask: is there
  something that we can do to limit the consequences of attacks,
  should they occur?

6) s1 contains the following:

  The authors want to provide a public specification of an extension
  that helps defend against one aspect of pervasive surveillance.

Could this be restated as:

  This document specifies an
  extension that helps defend against one aspect of pervasive
  surveillance.

Likewise:

  While adding forward secrecy to the existing mobile network
  infrastructure can be done in multiple different ways, the authors
  believe that the approach chosen here is relatively easily
  deployable.

Could this be restated as:

  While adding forward secrecy to the existing mobile network
  infrastructure can be done in multiple different ways, this document
  specifies a solution that is relatively easily
  deployable.

7) s3.2: s/our goal/the goal

8) s3.2, Table 1 end of 1st box: Could this be rephrased from:

 … used in creating
 … used to create

9) s3.2, Table 1 2nd box:  Could this be rephrased:

   The two names are compared for discrepancies,
   and if necessary, the authentication is aborted

to 

 The two names  are compared for discrepancies,
 and if they do not match, the authentication is aborted

10) s3.2, Table 1 last box: Could this be rephrased:

  to be found correct.

as

  compared values match, respectively. 

11) Since we trying to do FS, maybe “retain” isn’t the best word :) Also, isn’t it the session that new keys provide the security for?

s/To retain the security of the keys,/To ensure the security of the session

12) s6.2: s/This specification only specifies /This document only specifies 

13) s6.3:

s/[RFC9048] EAP-AKA’/EAP-AKA' [RFC9048] 

Added ref for “privacy-friendly identifier” -> see RFC 9048.

14) s6.5.3: Maybe instead of this:

  Finally, the operation in case an error occurs is
   specified in Section 6.3.1. of [RFC4187].

this:

   Finally, if there is an error, see Section 6.3.1. of [RFC4187].

15) s6.5.4: Maybe instead of this (not sure if it’s these attributes - where these refers to the two attributes defined herein or this attribute - where this refers to AT_RES? - assumed the latter):

  Only if these attribute
   is verified to be valid, the Server derives keys and verifies AT_MAC.

this:

  The Server derives keys and verifies AT_MAC inly when this attribute
  is verified to be valid.

16) s7: Maybe instead of:

  It is RECOMMENDED to long term completely phase out
   AKA without forward secrecy.

this:

  It is RECOMMENDED
   that AKA without forward secrecy be phased out.

17) s8: Missing a ) in the middle paragraph.

18) s8: Minor edits to 3rd para to tell IANA to make a registry ;) It’s not like they wouldn’t follow the should, but you never know ;)