Original text:
For convenience, this document adopts the representation of these services being standalone servers, however the MLS protocol design is <del> made so that it is not necessarily the case. </del>  It is important to note that the Authentication Service functionality can be completely abstract in the case of a Service Provider which

Reviewer comments:
That looks good. Thank you for drafting it.
Thanks Richard!
This is a discussion point for the WG, regarding choice of terminology for the AS / DS. For those within the WG, these terms are clear - there have been several issues/PRs to enhance clarity or functionalities (, , , , , etc.), and the AS / DS describe core functionalities. These are not server components but conceptual representations, e.g. those functionalities could be realized through a "separate directory functionality or service" (spec). However, I have noticed a very strong trend for people reading the documents / determining use-case applicability to interpret the AS / DS "services" as an absolute requirement for centralized "servers". This does not seem to be a set of random side cases; there is a natural association of terminology and that could result in unnecessary avoidance of the protocol under such a restricted interpretation. I suggest that we consider a slight terminology change that could avoid these issues. For example, some options may be AM / DM (Authentication Management / Distribution Management), AP / DM (Authentication Provisioning, Distribution Management). I.e. 'management', 'provider / provisioning', 'function', etc. avoid the key word association to 'server' and leave the reader assumptions open to other options.
Rather than change the terminology, I would prefer we just elaborate on the variety of ways that the "service" could be realized -- centralized vs. decentralized, client vs. server, etc. Changing the terminology everywhere at this point would be a pretty invasive change.
Well, services certainly can be distributed or even federated, as in, for instance, the X.500 directory service, so I don't think that "Service" implies that there is a single server. It's not clear to me that "Function" is better than service and the other alternatives you propose seem more confusing.
There has been discussion in the protocol document on changing out core components that affect cryptographic analysis, so a keyword search-and-replace is relatively not very invasive by comparison. However, I agree that it would be easier to keep changes to a minimum. What we must avoid is burying a description on different ways to realize these somewhere in the architecture document - that is arguably already there and has not mitigated the issue, it seems. If keeping "service" and adding clarification is a preferred way to go, then it needs to be prominently stated with organization to match. The fact that "service" has other uses than an analogous "server" has not evaded misrepresentation/misinterpretation - a clear specification in this is really dependent on the broader community understanding the goal vs any one sense of clarity/confusion.
It would need to be clarified under the General Setting, where the AS/DS are introduced, in particular.
NAME I took a stab at this in

Revised text:
For convenience, this document adopts the representation of these services being standalone servers, however the MLS protocol design is  <ins> made so that it is not necessarily the case.  These services may reside on the same server or different servers; they may be distributed between server and client components; and they may even involve some action by users.  For example: Several secure messaging services today provide a centralized DS, and rely on manual comparison of clients' public keys as the AS. MLS clients connected to a peer-to-peer network could instantiate a decentralized DS by transmitting MLS messages over that network. In an MLS group using a PKI for authentication, the AS would comprise the certificate issuance and validation processes, both of which involve logic inside MLS clients as well as various servers. </ins> It is important to note that the Authentication Service functionality can be completely abstract in the case of a Service Provider which