Code change:
9.6. <del> The main MLS key schedule provides a "resumption_secret" that is used as a PSK to inject entropy from one epoch into another.  This </del> <ins> The main MLS key schedule provides a "resumption_psk" that is used as a PSK to inject entropy from one epoch into another.  This </ins> functionality is used in the reinitialization and branching processes described in reinitialization and sub-group-branching, but may be used by applications for other purposes. Some uses of resumption PSKs might call for the use of PSKs from historical epochs.  The application SHOULD specify an upper limit on <del> the number of past epochs for which the "resumption_secret" may be </del> <ins> the number of past epochs for which the "resumption_psk" may be </ins> stored. 9.7. <del> The main MLS key schedule provides a per-epoch "authentication_secret".  If one of the parties is being actively impersonated by an attacker, their "authentication_secret" will differ from that of the other group members.  Thus, members of a group MAY use their "authentication_secrets" within an out-of-band authentication protocol to ensure that they share the same view of the group. </del> <ins> The main MLS key schedule provides a per-epoch "authentication_code". If one of the parties is being actively impersonated by an attacker, their "authentication_code" will differ from that of the other group members.  Thus, members of a group MAY verify out of band that their "authentication_code" values are all the same, in order to ensure that they share the same view of the group. </ins> 10.

Related discussion:
text: TLS is generic in 'exporters' after an exportermastersecret is derived. Thus there is alignment of the term 'secret' to things that can be used for keys (have sufficient entropy), not as an alignment to public/secret at different layers. I am strongly opposed to the use of authenticationcode, and see no clear definition for that in your customized taxonomy. As such, it would follow the more standard interpretations, such as message authentication codes, etc. which are indeed explicitly public values. Codes are normally an end-state in themselves, not keys. Perhaps it is a clearer name for the Cisco implementation design, but it is not a clear name for something that can/should be used for further derivations as may be more generally applicable. Following the TLS norm for exporters, the name would be "authenticationmastersecret". The shortened "authenticationsecret" was a good name. If you are going to provide a write-up for the custom taxonomy, then an adjustment to "authenticationexporter" could perhaps be made.
The notion of a having boundary to the protocol and values that may or may not safely be exported across the boundary is not exotic or customized. You see it in FIPS 140-2, PKCS, and WebCrypto, and in tools like ProVerif and Tamarin. The only choice I'm making is in the specific words, in particular reserving "secret" for "something that should not be exposed outside the protocol implementation because it would compromise the protocol". I hope you agree that is different from say in this regard. It would be OK for an MLS implementation to have an API for an application to access the , but it would not be OK to have an API to access the . I'm not wedded to , I just want something other than . If you want to align with the exported values (to which I agree it is similar), we could call it an .
The distinction between those documents and tools, and the MLS spec is that those tools clearly define the boundaries and terminology, vs. just anyone making terminology assumptions without them being specified in the document. Not to be pedantic, but if you want to assume specific meanings for terms relative to a threat model for MLS only, versus a general usage ("exporter secrets" being secrets used in other things), then you really do need to specify those assumptions within the specification itself and not various side discussions.