Draft: draft-ietf-mls-architecture

Commentary: 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 : authentication service delivery service 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 wo n't be upset if anyone wants to step in to improve / correct it . 
 Really like this direction , few small tweaks . This looks good . Thanks  , Thanks  !
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.
MLS relies on the following network services.  These network services
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.
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.
MLS relies on the following network services.  These network services
would need to be compatible in order for two different deployments
based on them to interoperate.
A policy on how long to allow a member to stay in a group without
updating its leaf keys, and whether there should be any attempt to
resolve a stale leaf key before removing the member.
A policy on how long to allow a member to stay in a group without
updating its leaf keys before removing them.