Original text:
Upon joining the system, each client stores its initial cryptographic key material with the Delivery Service.  This key material, called a KeyPackage, advertises the functional abilities of the client such as <del> supported protocol versions, extensions, and the following </del>  cryptographic information: A credential from the Authentication Service attesting to the 6. <del> A fully functional deployment of MLS requires a number of infrastructure services to be available, as well as several policies and design trade-offs that are decided by the application.  This section lists all of the dependencies of an MLS deployment that are external to the protocol specification, but would still need to be aligned for two deployments to potentially interoperate. MLS has the built-in ability to negotiate protocol versions, ciphersuites, extensions, and credential types.  For two deployments to interoperate, they must have overlapping support in each of these categories. </del>  MLS relies on the following network services.  These network services <del> would either need to be the same, or compatible at the wire-format level, in order for two different deployments based on them to interoperate. </del>  An *Authentication Service*, described fully in authentication- service, defines the types of credentials which may be used in a Issuing new credentials, <del> Validating existing credentials against a reference identifier, and </del>  Validating whether or not two credentials represent the same user. keys but should still only be considered a single client. A policy on how long to allow a member to stay in a group without <del> updating its leaf keys, and whether there should be any attempt to resolve a stale leaf key before removing the member. </del>  Finally, there are some additional application-defined behaviors that are partially an individual application's decision but may overlap

Reviewer comments:
Replaces Not compact.
When deploying MLS, the deployer/implementer needs a certain set of choices made. For example, authentication authorities, transport choices, how to interpret application data, etc. This draft could create a succinct summary format that a deployer could use as a checklist to make sure they've done the legwork necessary to be able to deploy MLS safely. this came up in the IETF 113 meeting.
If the draft describes such a summary as a template, then maybe some of the existing deployments could try filling it in, so we could see whether it's sufficient.
I actually think the answer here is fairly compact, and mostly laid out in the arch spec, so it's mainly a question of pulling together the threads. Basically, the application needs to define: An authentication service A delivery service What the content of the messages will be
compact is good and it looks like your list aligns roughly with the intuitions i opened this issue with, so that's good too. Are there any choices about cryptographic primitives that need to be decided as well (e.g. ciphersuite limitations or requirements, expected credential types)? What about MLS extensions or MLS proposals that clients connected to this deployment are expected to support or avoid?
I have no idea whether the template i outlined in is correct, let alone exhuastive. I offer it as a starting point, and won't be upset if anyone wants to step in to improve/correct it.
Really like this direction, few small tweaks.This looks good. Thanks Brendan, Thanks Richard!

Revised text:
Upon joining the system, each client stores its initial cryptographic key material with the Delivery Service.  This key material, called a KeyPackage, advertises the functional abilities of the client such as  <ins> supported protocol versions, supported extensions, and the following </ins> cryptographic information: A credential from the Authentication Service attesting to the 6.  <ins> MLS is a security layer that needs to be integrated with an application.  A fully-functional deployment of MLS will have to make a number of decisions about how MLS is configured and operated. Deployments that wish to interoperate will need to make compatible decisions.  This section lists all of the dependencies of an MLS deployment that are external to the protocol specification, but would still need to be aligned within a given MLS deployment, or for two deployments to potentially interoperate. The protocol has a built-in ability to negotiate protocol versions, ciphersuites, extensions, credential types, and additional proposal types.  For two deployments to interoperate, they must have overlapping support in each of these categories.  A "required_capabilities" extension can help maintain interoperability with a wider set of clients by ensuring that certain functionality continues to be supported by a group, even if the clients in the group aren't currently relying on it. </ins> MLS relies on the following network services.  These network services  <ins> would need to be compatible in order for two different deployments based on them to interoperate. </ins> An *Authentication Service*, described fully in authentication- service, defines the types of credentials which may be used in a Issuing new credentials,  <ins> Validating a credential against a reference identifier, and </ins> Validating whether or not two credentials represent the same user. keys but should still only be considered a single client. A policy on how long to allow a member to stay in a group without  <ins> updating its leaf keys before removing them. </ins> Finally, there are some additional application-defined behaviors that are partially an individual application's decision but may overlap