I am the assigned ART directorate reviewer for this document. These comments
were written primarily for the benefit of the ART area directors.  Document
editors and WG chairs should treat these comments just like any other last call
comments.

I reviewed the -09 and -10 versions of the draft before. Some of my concerns were
addressed in the -13 version. I still have the following minor issues with the
document.

1) It is still unclear to me if it is ever possible for a client (let it be Alice) that support only version x 
of the protocol to join the group that was formed using version y (y > x) of the protocol, 
even when all the members of this group support both versions. In other words, if the group
originally included Alice, the members would have negotiated using version x.
But if the Alice tries to join the group later, then it is not clear for me whether she is able to do it.
The document seems to allow upgrading version of the group, but seems to not allow downgrading it
(even for a legitimate user wishing to join).

2) After adding a few clarification words into the document I now seem to understand
that DS type (Strongly Consistent / Eventually Consistent) also influences 
clients' behavior. At least clients must be able to handle rejected messages to 
to work with Strongly Consistent DS. I still would like to see
more words in the document discussing possible (in?)compatibility between
clients and Delivery Services depending on the type of the latters.

3) The issue of inability for a client to remove itself from the group by
its own seems unsolvable in the MLS architecture. I still think that some recommendations 
in the document for clients wishing to exclude themselves in situations when other members for
some reasons don't cooperate in this process would be helpful.

Nits:
URL provided in the [CAPBR] reference doesn't contain full article, only its abstract,
that makes it difficult for readers to independently verify claims made in the draft
regarding "CAP theorem".

While I think these issues are important, I'd leave them on ADs' discretion.