The Messaging Layer Security (MLS) Protocol
draft-ietf-mls-protocol-20

[Ballot comment]
# GEN AD review of draft-ietf-mls-protocol-17

CC @larseggert

## Comments

### Section 2.1, paragraph 0
```
    We use the TLS presentation language [RFC8446] to describe the
    structure of protocol messages.  In addition to the base syntax, we
    add two additional features, the ability for fields to be optional
    and the ability for vectors to have variable-size length headers.
```
It might be worthwhile to extract the TLS syntax and its additions into a
separate RFC at some point.

### Section 17.1, paragraph 24
```
    The mandatory-to-implement ciphersuite for MLS 1.0 is
    MLS_128_DHKEMX25519_AES128GCM_SHA256_Ed25519 which uses Curve25519
    for key exchange, AES-128-GCM for HPKE, HKDF over SHA2-256, and
    Ed25519 for signatures.
```
If it's "mandatory-to-implement", please use RFC2119 terms?

### "Appendix D.", paragraph 9
```
            L = self.root
            R = Node.blank_subtree(self.depth)
            self.root = Node(None, left=self.root, right=R)
            self.depth += 1
```
L is never used after assignment?

### Too many authors

The document has six authors, which exceeds the recommended author limit. Has
the sponsoring AD agreed that this is appropriate?

### Inclusive language

Found terminology that should be reviewed for inclusivity; see
https://www.rfc-editor.org/part2/#inclusive_language for background and more
guidance:

* Term `traditional`; alternatives might be `classic`, `classical`, `common`,
  `conventional`, `customary`, `fixed`, `habitual`, `historic`,
  `long-established`, `popular`, `prescribed`, `regular`, `rooted`,
  `time-honored`, `universal`, `widely used`, `widespread`

## Nits

All comments below are about very minor potential issues that you may choose to
address in some way - or ignore - as you see fit. Some were flagged by
automated tools (via https://github.com/larseggert/ietf-reviewtool), so there
will likely be some false positives. There is no need to let me know what you
did with these suggestions.

### Paragraph 0

The mix of SVG and ASCII art in the figures is a bit odd. I guess the SVG
tools aren't capable enough for some of the images?

### Outdated references

Document references `draft-irtf-cfrg-aead-limits-05`, but `-06` is the latest
available revision.

Reference `[RFC7540]` to `RFC7540`, which was obsoleted by `RFC9113` (this may
be on purpose).

### Grammar/style

#### Section 3, paragraph 9
```
ts thus maintain the property that the the epoch secret is confidential to th
                                  ^^^^^^^
```
Possible typo: you repeated a word.

#### "A", paragraph 4
```
rs are removed from the group in a similar way, as shown in Figure 5. Any me
                              ^^^^^^^^^^^^^^^^
```
Consider replacing this phrase with the adverb "similarly" to avoid wordiness.

#### "A", paragraph 4
```
orce access control policies on top of these basic mechanism. Group A B ...
                                      ^^^^^^^^^^^^^^^^^^^^^
```
The plural demonstrative "these" does not agree with the singular noun
"mechanism".

#### Section 7.3, paragraph 6
```
sulting node secrets and key pairs. Thus A would have the private keys to nod
                                    ^^^^
```
A comma may be missing after the conjunctive/linking adverb "Thus".

#### Section 7.3, paragraph 8
```
n use it to derive the node secret and and key pair for the node Y'. As requ
                                  ^^^^^^^
```
Possible typo: you repeated a word.

#### Section 7.9, paragraph 15
```
he previous epoch. This is done when an new member is joining via an external
                                    ^^
```
Use "a" instead of "an" if the following word doesn't start with a vowel sound,
e.g. "a sentence", "a university".

#### Section 8.3, paragraph 3
```
bel KeyPackageTBS and a content comprising of all of the fields except for th
                                ^^^^^^^^^^^^^
```
Did you mean "comprising" or "consisting of"?

#### Section 11, paragraph 17
```
roposal type describe how each individual proposals is applied. When creatin
                          ^^^^^^^^^^^^^^^^^^^^^^^^^
```
Use a singular noun after the quantifier "each", or change it to "all".

#### Section 12.1.7, paragraph 6
```
Content message as described in Section Section 6.1. * Verify that the propos
                                ^^^^^^^^^^^^^^^
```
Possible typo: you repeated a word.

#### Section 12.4.3.1, paragraph 33
```
also set a new encryption_secret. Hence this change MUST be applied before
                                  ^^^^^
```
A comma may be missing after the conjunctive/linking adverb "Hence".

#### Section 12.4.3.2, paragraph 15
```
a variant of the HN1 construction analyzed in [NAN]. A sample of the ciphert
                                  ^^^^^^^^
```
Do not mix variants of the same word ("analyze" and "analyse") within a single
text.

#### Section 14, paragraph 3
```
ended item to "Y" or "D", or changing a item whose current value is "Y" or "D
                                      ^
```
Use "an" instead of "a" if the following word starts with a vowel sound, e.g.
"an article", "an hour".

#### Section 14, paragraph 5
```
ETF might have consensus to leave an items marked as "N" on the basis of it
                                  ^^^^^^^^
```
The plural noun "items" cannot be used with the article "an". Did you mean "an
item" or "items"?

#### Section 16.7, paragraph 3
```
presentation language [RFC8446]. Therefore MLS messages need to be treated a
                                ^^^^^^^^^
```
A comma may be missing after the conjunctive/linking adverb "Therefore".

## Notes

This review is in the ["IETF Comments" Markdown format][ICMF], You can use the
[`ietf-comments` tool][ICT] to automatically convert this review into
individual GitHub issues. Review generated by the [`ietf-reviewtool`][IRT].

[ICMF]: https://github.com/mnot/ietf-comments/blob/main/format.md
[ICT]: https://github.com/mnot/ietf-comments
[IRT]: https://github.com/larseggert/ietf-reviewtool

Notification list changed to benjamin.beurdouche@ens.fr, karthikeyan.bhargavan@inria.fr, cremers@cispa.de, alan@wire.com, ekr@rtfm.com, tjvdmerwe@gmail.com, sean@sn3rd.com from benjamin.beurdouche@ens.fr, karthikeyan.bhargavan@inria.fr, cas.cremers@gmail.com, alan@wire.com, ekr@rtfm.com, tjvdmerwe@gmail.com, sean@sn3rd.com

Notification list changed to benjamin.beurdouche@ens.fr, karthikeyan.bhargavan@inria.fr, cas.cremers@gmail.com, alan@wire.com, ekr@rtfm.com, tjvdmerwe@gmail.com, sean@sn3rd.com from benjamin.beurdouche@ens.fr, karthikeyan.bhargavan@inria.fr, cas.cremers@cs.ox.ac.uk, alan@wire.com, singuva@twitter.com, kwonal@mit.edu, ekr@rtfm.com, tjvdmerwe@gmail.com, sean@sn3rd.com

[Ballot comment]
Sorry for the late ballot on this document and the MLS architecture document but I've struggled to decide whether to ballot no obj or abstain.

In the end I decided to ballot abstain because I'm unsure whether standardizing MLS in really the right thing to do for end users (which may just be my ignorance).  I'm strongly supportive of efforts to make messaging platforms interoperate cleanly (e.g., I'm supportive of the MIMI WG being chartered) and I appreciate that MLS is likely to underpin some of that work, but I also question whether the IETF standardizing this will ultimately be beneficial for societies and humanity (and note - I'm not advocating for pervasive monitoring, but preventing any ability for judicially supported interceptions for criminal investigations concerns me).  In the limited cases where IETF standardization and technology choices are could directly impact the effectiveness of law enforcement or conflict with democratically elected government policies then I think that it would be great if the IETF was able to receive and consider a wider range of views in the consensus process to ensure that we really are making the right choices.

Regards,
Rob

[Ballot comment]
Thank you for the work on this document.

Many thanks to Rich Salz for his early ART ART review: https://mailarchive.ietf.org/arch/msg/art/cPgtxv10gxxU8_MXCai5iGHG8WE/ and to the authors for addressing Rich's comments.

I only have had time to scan the document, and I haven't identified any ART issues.

[Ballot comment]

# Éric Vyncke, INT AD, comments for draft-ietf-mls-protocol-17
CC @evyncke

Thank you for the work put into this document. It is obviously a very much needed protocol. Please note that my work schedule was hectic for my day job, and I was unable to review in depth this document, hence I am trusting the SEC ADs for the security aspects (notably sections 5, 7-10, 16), else I would have balloted a YES. SVG graphics are also very nice to read (except for figure 9 and others ;-) ). Section 13 on extensibility is also a nice and important idea.

The document is really easy to read, in my opinion, it is even a better architecture document than draft-ietf-mls-architecture-10 and *I would even suggest that the IETF does not publish the latter* as the former contains a better introduction to MLS.

Please find below some non-blocking COMMENT points (but replies would be appreciated even if only for my own education), and some nits.

Special thanks to Sean Turner for the shepherd's detailed write-up including the WG consensus ***and*** the justification of the intended status.

Other thanks to Suresh Krishnan, the Internet directorate reviewer (at my request), please consider this int-dir review:
https://datatracker.ietf.org/doc/review-ietf-mls-protocol-17-intdir-telechat-krishnan-2023-01-30/ and I read that Martin & Richard have already replied to Suresh.

I hope that this review helps to improve the document,

Regards,

-éric

## COMMENTS

### Intended Status

I second Lars' point about the intended status. As the IETF Last Call clearly indicated 'proposed standard', a revised I-D will be enough IMHO.

### Implementation of complex protocol

Based on my affiliation, I obviously know about one implementation (unsure whether it is a project or it is deployed). It would be nice to know whether there are other implementations of this protocol, which looks quite complex to implement.

### Ratchet

As the whole concept of MLS relies on "ratchet trees", an early short introduction to them would have made reading easier. The reader has to wait until section 4 to get some explanations.

### Section 1.1

Suggestion: swap the introduction of AD and DS as it sounds more logical timewise.

For DS, at this point in the document, readers can only guess what `KeyPackage` and `Proposal` are. Suggest not to use the capitalised words but simply their lowercase equivalent.

### Section 2.1.2

In `encoded on the remaining bits, in network byte order` I find weird to use *byte* order for *bits*. Should it rather be *MSB first* ? Or even suppress it as all other bit encoding in IETF document implicitly used this notation ?

Does this compressed encoding add value in a world with long crypto material ? (just curious here)

`up to 2^30 bytes` is about 1 Gbytes, this is huge and for sure will not often be used (written by the guy supporting 128-bit addresses). Feel free to ignore this comment of course ;-)

### Section 3.2

Where was "leaf secret" in `Updating the leaf secret of a member` defined ?

Which is the relationship between the directory/service provider and AS/DS ?

As it seems that the group channel is part of DS, then let's make it clear in the figure ?

`Once A has updated its state, the new member has processed the Welcome, and any other group members have processed the Commit,` should this rather be `Once A has updated its state and the new member has processed the Welcome and any other group members have processed the Commit,` i.e., no Oxford comma as the "once" applies to all three conditions ? Bear with me as I am not an English speaker.

`a rate that overwhelms the transport` is transport really the only bottleneck ? I would assume that crypto processing could be another one (but could be wrong). While is seems really smart and nice on the 3 parties example, I wonder how it could scale to thousands of nodes (per -architecture) with frequent join/leave by members.

### Section 3.3

Suggest to explicitly refer to figure numbers and not only by "next figure" (or even nothing in the text pointing to the figure).

### Section 4

Some justification of the log(N) would be nice for the reader (or an external reference), does it come from the binary tree ? Does the amount of subgroups influence the number of crypto operations ?

### Section 4.1.1

To be honest, I failed to understand the example because "unmerged" is explained later in the text. No suggestion though...

### Section 4.2

s/all the intermediate nodes they're below/all the intermediate nodes that are below/ ?

### Section 5.1.3

Probably due to my lack of knowledge about "TLS syntax", but I find imposing a syntax `label = "MLS 1.0 " + Label;` on an *opaque* field a little weird...

### Section 11

`The creator ... verify that the chosen version and ciphersuite is the best option supported by all members.`, but how can the creator do that when creating the group ?

### Section 16

This section basically confirms my point of view of the -architecture I-D, i.e., it is about security considerations of the -protocol.

## NITS

### Figure numbers

There are a lot of nice and useful figures in the I-D, may I suggest to add a label/reference to all of them ?

### Section 2

s/shared cryptographic state/shared cryptographic states/ ?

### Section 4.1

Suggest either remove the last paragraph (about implementations) or move it after the 1st paragraph of 4.1.1 (where the *index* is introduced).

### Section 8.4

s/Groups which already have an out-of-band mechanism/Groups that already have an out-of-band mechanism/ ?

## Notes

This review is in the ["IETF Comments" Markdown format][ICMF], You can use the
[`ietf-comments` tool][ICT] to automatically convert this review into
individual GitHub issues.

[ICMF]: https://github.com/mnot/ietf-comments/blob/main/format.md
[ICT]: https://github.com/mnot/ietf-comments

[Ballot comment]
Thanks for working on this interesting topic. Thanks for Gorry fairhost for this TSVART review.

I have few comments, which I believe if addressed will improve the document.

- There is a mismatch between intended status of this spec (PS) and what in the doc header (Informational). I see Lars already have a discuss on it, so supporting it.

- The specification says the UPDATE messages SHOULD be periodically sent and expects the applications to decided on the period between UPDATE messages. As I can see there are multiple implementations, can't we also recommend some guidelines and considerations on how to select the period? In some discussions I saw we were talking about hours and months..

- it says -
    " In general, however, applications should take care that they do not send MLS messages at a rate that overwhelms the transport over which messages are being sent."
 
  I am not sure I understand what "overwhelms the transport" means. Are we talking about the congestion control or bandwidth estimation part of transport protocols? Usually the application have no or very vague information about the internal protocol states, in that case how the applications are expected to take care of this? are we suggesting some interaction application rate control?

Notification list changed to benjamin.beurdouche@ens.fr, karthikeyan.bhargavan@inria.fr, cas.cremers@cs.ox.ac.uk, alan@wire.com, singuva@twitter.com, kwonal@mit.edu, ekr@rtfm.com, tjvdmerwe@gmail.com, sean@sn3rd.com from benjamin.beurdouche@ens.fr, karthikeyan.bhargavan@inria.fr, cas.cremers@cs.ox.ac.uk, alan@wire.com, singuva@twitter.com, kwonal@mit.edu, ekr@rtfm.com, thyla.van.der@merwe.tech, sean@sn3rd.com

[Ballot comment]
** Section 2. 
  Handshake Message:  A PublicMessage or PrivateMessage carrying an MLS
      Proposal or Commit object, as opposed to application data.

This definition of a handshake message is being defined in terms of a Proposal or Commit object, neither of which are defined in this session.  Furthermore, PublicMessage or PrivateMessage aren’t defined either as this point in the text.  To improve clarity, consider defining these key terms.

** Section 2.  Editorial.
  The PublicMessage and PrivateMessage formats are defined in
  Section 6; they represent integrity-protected and confidentiality-
  protected messages, respectively. 

The use of “respectively” in the text is suggesting that PrivateMessages don’t have integrity protection which is not accurate. 

** Section 3.1.  Typo. s/the the/the/

** Section 5.1.1.
(see the Cryptographic Dependencies section of
  the HPKE specification for more information).

Is this Section 4 of RFC9180?  If so, why not say that?

** Section 5.3.3.

  However, applications SHOULD NOT rely on the data in an
  application_id extension as if it were authenticated by the
  Authentication Service,

What would be the circumstance where the application_id extension would be treated with equal standing as something from the AS?  Why can’t this be a “MUST”?

** Section 12.2.

  A group member creating a commit and a group member processing a
  commit MUST verify that the list of committed proposals is valid
  using one of the following procedures, depending on whether the
  commit is external or not.

Unsaid is what to do if the proposal list is not valid.  Please clarify.

** Section 12.2

  *  It contains multiple Update and/or Remove proposals that apply to
      the same leaf.  If the committer has received multiple such
      proposals they SHOULD prefer any Remove received, or the most
      recent Update if there are no Removes.

Is this normative behavior required, or could it be left up to application?  The mixing of updates/removes on the same node and the SHOULD guidance already means that this “recovery from an invalid node” may not be consistent across clients/DS-es.

Same observation on recovering from ReInit with any other proposals.

** Section 12.4.

  Due to the asynchronous nature of proposals, receivers of a Commit
  SHOULD NOT enforce that all valid proposals sent within the current
  epoch are referenced by the next Commit.  In the event that a valid
  proposal is omitted from the next Commit, and that proposal is still
  valid in the current epoch, the sender of the proposal MAY resend it
  after updating it to reflect the current epoch.

Is there any additional retry mechanism?  Let’s say the sender of the proposal doesn’t see it reflect in the epoch after it sent proposal.  And then not in the next epoch.  Does it try resending indefinitely?

** Section 15.1.
  If Alice asks
  Bob "When are we going to the movie?", then the answer "Wednesday"
  could be leaked to an adversary solely by the ciphertext length.

This setup seems a little simplistic.  If the application data is encrypted to begin with, how does the adversary know the question being posed by Alice?

[Ballot discuss]
# GEN AD review of draft-ietf-mls-protocol-17

CC @larseggert

## Discuss

### Section 17.1, paragraph 11
```
    *  Recommended: Whether support for this ciphersuite is recommended
        by the IETF MLS WG.  Valid values are "Y", "N", and "D", as
        described below.  The default value of the "Recommended" column is
        "N".  Setting the Recommended item to "Y" or "D", or changing a
        item whose current value is "Y" or "D", requires Standards Action
        [RFC8126].
```
The IETF MLS WG may (should) close at some future point. I think the text should
talk about the IETF recommending a ciphersuite, not the MLS WG.

### Unclear RFC status

Intended RFC status in datatracker is "Proposed Standard", but document says
"Informational".

[Ballot comment]
## Comments

### Section 2.1, paragraph 0
```
    We use the TLS presentation language [RFC8446] to describe the
    structure of protocol messages.  In addition to the base syntax, we
    add two additional features, the ability for fields to be optional
    and the ability for vectors to have variable-size length headers.
```
It might be worthwhile to extract the TLS syntax and its additions into a
separate RFC at some point.

### Section 17.1, paragraph 24
```
    The mandatory-to-implement ciphersuite for MLS 1.0 is
    MLS_128_DHKEMX25519_AES128GCM_SHA256_Ed25519 which uses Curve25519
    for key exchange, AES-128-GCM for HPKE, HKDF over SHA2-256, and
    Ed25519 for signatures.
```
If it's "mandatory-to-implement", please use RFC2119 terms?

### "Appendix D.", paragraph 9
```
            L = self.root
            R = Node.blank_subtree(self.depth)
            self.root = Node(None, left=self.root, right=R)
            self.depth += 1
```
L is never used after assignment?

### Too many authors

The document has six authors, which exceeds the recommended author limit. Has
the sponsoring AD agreed that this is appropriate?

### Inclusive language

Found terminology that should be reviewed for inclusivity; see
https://www.rfc-editor.org/part2/#inclusive_language for background and more
guidance:

* Term `traditional`; alternatives might be `classic`, `classical`, `common`,
  `conventional`, `customary`, `fixed`, `habitual`, `historic`,
  `long-established`, `popular`, `prescribed`, `regular`, `rooted`,
  `time-honored`, `universal`, `widely used`, `widespread`

## Nits

All comments below are about very minor potential issues that you may choose to
address in some way - or ignore - as you see fit. Some were flagged by
automated tools (via https://github.com/larseggert/ietf-reviewtool), so there
will likely be some false positives. There is no need to let me know what you
did with these suggestions.

### Paragraph 0

The mix of SVG and ASCII art in the figures is a bit odd. I guess the SVG
tools aren't capable enough for some of the images?

### Outdated references

Document references `draft-irtf-cfrg-aead-limits-05`, but `-06` is the latest
available revision.

Reference `[RFC7540]` to `RFC7540`, which was obsoleted by `RFC9113` (this may
be on purpose).

### Grammar/style

#### Section 3, paragraph 9
```
ts thus maintain the property that the the epoch secret is confidential to th
                                  ^^^^^^^
```
Possible typo: you repeated a word.

#### "A", paragraph 4
```
rs are removed from the group in a similar way, as shown in Figure 5. Any me
                              ^^^^^^^^^^^^^^^^
```
Consider replacing this phrase with the adverb "similarly" to avoid wordiness.

#### "A", paragraph 4
```
orce access control policies on top of these basic mechanism. Group A B ...
                                      ^^^^^^^^^^^^^^^^^^^^^
```
The plural demonstrative "these" does not agree with the singular noun
"mechanism".

#### Section 7.3, paragraph 6
```
sulting node secrets and key pairs. Thus A would have the private keys to nod
                                    ^^^^
```
A comma may be missing after the conjunctive/linking adverb "Thus".

#### Section 7.3, paragraph 8
```
n use it to derive the node secret and and key pair for the node Y'. As requ
                                  ^^^^^^^
```
Possible typo: you repeated a word.

#### Section 7.9, paragraph 15
```
he previous epoch. This is done when an new member is joining via an external
                                    ^^
```
Use "a" instead of "an" if the following word doesn't start with a vowel sound,
e.g. "a sentence", "a university".

#### Section 8.3, paragraph 3
```
bel KeyPackageTBS and a content comprising of all of the fields except for th
                                ^^^^^^^^^^^^^
```
Did you mean "comprising" or "consisting of"?

#### Section 11, paragraph 17
```
roposal type describe how each individual proposals is applied. When creatin
                          ^^^^^^^^^^^^^^^^^^^^^^^^^
```
Use a singular noun after the quantifier "each", or change it to "all".

#### Section 12.1.7, paragraph 6
```
Content message as described in Section Section 6.1. * Verify that the propos
                                ^^^^^^^^^^^^^^^
```
Possible typo: you repeated a word.

#### Section 12.4.3.1, paragraph 33
```
also set a new encryption_secret. Hence this change MUST be applied before
                                  ^^^^^
```
A comma may be missing after the conjunctive/linking adverb "Hence".

#### Section 12.4.3.2, paragraph 15
```
a variant of the HN1 construction analyzed in [NAN]. A sample of the ciphert
                                  ^^^^^^^^
```
Do not mix variants of the same word ("analyze" and "analyse") within a single
text.

#### Section 14, paragraph 3
```
ended item to "Y" or "D", or changing a item whose current value is "Y" or "D
                                      ^
```
Use "an" instead of "a" if the following word starts with a vowel sound, e.g.
"an article", "an hour".

#### Section 14, paragraph 5
```
ETF might have consensus to leave an items marked as "N" on the basis of it
                                  ^^^^^^^^
```
The plural noun "items" cannot be used with the article "an". Did you mean "an
item" or "items"?

#### Section 16.7, paragraph 3
```
presentation language [RFC8446]. Therefore MLS messages need to be treated a
                                ^^^^^^^^^
```
A comma may be missing after the conjunctive/linking adverb "Therefore".

## Notes

This review is in the ["IETF Comments" Markdown format][ICMF], You can use the
[`ietf-comments` tool][ICT] to automatically convert this review into
individual GitHub issues. Review generated by the [`ietf-reviewtool`][IRT].

[ICMF]: https://github.com/mnot/ietf-comments/blob/main/format.md
[ICT]: https://github.com/mnot/ietf-comments
[IRT]: https://github.com/larseggert/ietf-reviewtool

[Ballot comment]
# Internet AD comments for draft-ietf-mls-protocol-17
CC @ekline

## Comments

* Thank you very much for all of the explicitly worked examples.

### S7.3

* What is the reason for MUST vs RECOMMENDED difference in the two different
  circumstances when validating the `lifetime` field?

* Consider adding a platitude about communicating nodes SHOULD use some
  method of time synchronization...

## Nits

### S3.2

* "top of these basic mechanism" -> "top of these basic mechanisms"
  (or maybe "top of this basic mechanism")

### S6.3.1

* "in an PrivateContentTBE structure" -> "in a PrivateContentTBE structure"

# Document Shepherd Write-Up for Group Documents

## Document History

1. Does the working group (WG) consensus represent the strong concurrence of a
  few individuals, with others being silent, or did it reach broad agreement?

The WG consensus was broad. MLS is not the biggest WG, but there were enough
WG that were active participants during its development that agreed the I-D
was ready to proceed down the road to satisfy both chairs; many of the
participants are implementers. Additionally, some of WG participants are also
part of the security research community and they agreed that the protocol
was provably secure. Without this research, the chairs would not progress this
I-D.

2. Was there controversy about particular points, or were there decisions where
  the consensus was particularly rough?

Surprisingly, no. There was lots of back and forth as well as some frustration,
but generally speaking this development of this I-D was what I hope happens
for most I-Ds.

3. Has anyone threatened an appeal or otherwise indicated extreme discontent? If
  so, please summarize the areas of conflict in separate email messages to the
  responsible Area Director. (It should be in a separate email because this
  questionnaire is publicly available.)

No.

4. For protocol documents, are there existing implementations of the contents of
  the document? Have a significant number of potential implementers indicated
  plans to implement? Are any existing implementations reported somewhere,
  either in the document itself (as [RFC 7942][3] recommends) or elsewhere
  (where)?

We have a github implementation repo that can be found at:
https://github.com/mlswg/mls-implementations

But, a more accurate list of implementations is:

- MLSpp = open source, deployed in production
- OpenMLS = open source
- Wickr's implementation = closed source
- RingCentral's implementation = closed source, deployed in production
- Element's Typescript implementation = open source, only prototype-grade

## Additional Reviews

5. Do the contents of this document closely interact with technologies in other
  IETF working groups or external organizations, and would it therefore benefit
  from their review? Have those reviews occurred? If yes, describe which
  reviews took place.

MLS was intentionally written to be independent of the application layer. See
draft-ietf-mls-architecture for more information.

6. Describe how the document meets any required formal expert review criteria,
  such as the MIB Doctor, YANG Doctor, media type, and URI type reviews.

MLS uses the TLS presentation language. There is no formal expert review
criteria for the TLS presentation language.

There is a Media Type defined. IANA performed an early review and noted that
a few this needed to be addressed; a PR was created:
https://github.com/mlswg/mls-protocol/pull/730/files
The revised registration was shared with the media-types@ietf.org mailing
list.

7. If the document contains a YANG module, has the final version of the module
  been checked with any of the [recommended validation tools][4] for syntax and
  formatting validation? If there are any resulting errors or warnings, what is
  the justification for not fixing them at this time? Does the YANG module
  comply with the Network Management Datastore Architecture (NMDA) as specified
  in [RFC 8342][5]?

N/A

8. Describe reviews and automated checks performed to validate sections of the
  final version of the document written in a formal language, such as XML code,
  BNF rules, MIB definitions, CBOR's CDDL, etc.

N/A

## Document Shepherd Checks

9. Based on the shepherd's review of the document, is it their opinion that this
  document is needed, clearly written, complete, correctly designed, and ready
  to be handed off to the responsible Area Director?

Yes.

10. Several IETF Areas have assembled [lists of common issues that their
    reviewers encounter][6]. For which areas have such issues been identified
    and addressed? For which does this still need to happen in subsequent
    reviews?

After reviewing the list, it is not clear that most of the common issues apply
to this particular I-D. Remember, that there is also a companion archiecture
draft: draft-ietf-mls-architecture.

11. What type of RFC publication is being requested on the IETF stream ([Best
    Current Practice][12], [Proposed Standard, Internet Standard][13],
    [Informational, Experimental or Historic][14])? Why is this the proper type
    of RFC? Do all Datatracker state attributes correctly reflect this intent?

PS is the intended status. PS is the proper status for this on-the-wire
protocol. Yes, the datatracker state attributes correctly reflect PS.

12. Have reasonable efforts been made to remind all authors of the intellectual
    property rights (IPR) disclosure obligations described in [BCP 79][8]? To
    the best of your knowledge, have all required disclosures been filed? If
    not, explain why. If yes, summarize any relevant discussion, including links
    to publicly-available messages when applicable.

Yes, I have personally verified with the authors that they have met the IPR
disclosure obligations in [BCP79].

****
  NOTE: A 3rd party IPR disclosure was filed. Based on advice from Ben Kaduk,
  who was our AD at the time, I sent the following email during WGLC to
  determine how the WG wanted to handle the disclosure:
  https://mailarchive.ietf.org/arch/msg/mls/BB9WsfNDgLp_dEQ60Uw3S75qBmA/
  As you can see in the thread, the WG was comfortable progressing the I-D.
****

13. Has each author, editor, and contributor shown their willingness to be
    listed as such? If the total number of authors and editors on the front page
    is greater than five, please provide a justification.

I have personally verified that all authors are willing to be listed as such.

There are 6 authors listed and for a working group this size that might seem like
a lot, but each of the listed authors provided thrust at one point or another
to move this document along and I would be disinclined to remove one of them.

14. Document any remaining I-D nits in this document. Simply running the [idnits
    tool][8] is not enough; please review the ["Content Guidelines" on
    authors.ietf.org][15]. (Also note that the current idnits tool generates
    some incorrect warnings; a rewrite is underway.)

Lots of nits about lines too long. These seem to relate to the figures; SVG FTW.

Complaints about non-ascii text. These relate to authors' names.

There are two warnings related to references:

Outdated reference: draft-ietf-mls-architecture will likely always be out of
synch or the reference to this I-D in draft-ietf-mls-architecture to this I-D
will be out of synch.

Obsolete informational reference: RFC 7540 - this draft references HTTP/2 so
7540 is the correct reference. Also, review the text and you will note leaving
this alone is fine, i.e., the I-D does not need to update the reference to HTTP/3.

15. Should any informative references be normative or vice-versa? See the [IESG
    Statement on Normative and Informative References][16].

I think the references are fine. Richard wanted me to note that during WGLC
we did move one normative reference to informative.

16. List any normative references that are not freely available to anyone. Did
    the community have sufficient access to review any such normative
    references?

All normative references are to RFCs.

17. Are there any normative downward references (see [RFC 3967][9] and [BCP
    97][10]) that are not already listed in the [DOWNREF registry][17]? If so,
    list them.

[AD fixup: Yes. RFC-9180 HPKE is an IRTF document and is Informational. 9180
should be added to the DOWNREF registry as other protocols (eg cose) are also
using HPKE, so this will come up more often.]

18. Are there normative references to documents that are not ready to be
    submitted to the IESG for publication or are otherwise in an unclear state?
    If so, what is the plan for their completion?

No.

19. Will publication of this document change the status of any existing RFCs? If
    so, does the Datatracker metadata correctly reflect this and are those RFCs
    listed on the title page, in the abstract, and discussed in the
    introduction? If not, explain why and point to the part of the document
    where the relationship of this document to these other RFCs is discussed.

No.

20. Describe the document shepherd's review of the IANA considerations section,
    especially with regard to its consistency with the body of the document.
    Confirm that all aspects of the document requiring IANA assignments are
    associated with the appropriate reservations in IANA registries. Confirm
    that any referenced IANA registries have been clearly identified. Confirm
    that each newly created IANA registry specifies its initial contents,
    allocations procedures, and a reasonable name (see [RFC 8126][11]).

The Shepherd reviewed the assignment for consistency with the body of the I-D.

The Shepherd confirmed the following:
- All aspects of the document requiring IANA assignments are
  associated with the appropriate reservations in IANA registries.
- Any referenced IANA registries have been clearly identified.
- Each newly created IANA registry specifies its initial contents,
  allocations procedures, and a reasonable name (see [RFC 8126][11]).

NOTE: Submitted an issue to expand the definition of the Recommended column
to include a "D" for discouraged; the consensus for RFC 8447bis at saag was
to add this new value to the registry.

21. List any new IANA registries that require Designated Expert Review for
    future allocations. Are the instructions to the Designated Expert clear?
    Please include suggestions of designated experts, if appropriate.

There are four registry created by this I-D and all require DEs. Section
17.5 includes text for the DEs. Note that this text is based on the DE
text in RFC 8447.

[1]: https://www.ietf.org/about/groups/iesg/
[2]: https://www.rfc-editor.org/rfc/rfc4858.html
[3]: https://www.rfc-editor.org/rfc/rfc7942.html
[4]: https://trac.ietf.org/trac/ops/wiki/yang-review-tools
[5]: https://www.rfc-editor.org/rfc/rfc8342.html
[6]: https://trac.ietf.org/trac/iesg/wiki/ExpertTopics
[7]: https://www.rfc-editor.org/info/bcp79
[8]: https://www.ietf.org/tools/idnits/
[9]: https://www.rfc-editor.org/rfc/rfc3967.html
[10]: https://www.rfc-editor.org/info/bcp97
[11]: https://www.rfc-editor.org/rfc/rfc8126.html
[12]: https://www.rfc-editor.org/rfc/rfc2026.html#section-5
[13]: https://www.rfc-editor.org/rfc/rfc2026.html#section-4.1
[14]: https://www.rfc-editor.org/rfc/rfc2026.html#section-4.2
[15]: https://authors.ietf.org/en/content-guidelines-overview
[16]: https://www.ietf.org/about/groups/iesg/statements/normative-informative-references/
[17]: https://datatracker.ietf.org/doc/downref/

(Via drafts-lastcall@iana.org): IESG/Authors/WG Chairs:

The IANA Functions Operator has completed its review of draft-ietf-mls-protocol-17. If any part of this review is inaccurate, please let us know.

The IANA Functions Operator has questions about two of the actions requested in the IANA Considerations section of this document.

The IANA Functions Operator understands that, upon approval of this document, there are three actions that we must complete.

First, a new registry page will be created called the Messaging Layer Security page on the IANA Matrix at:

https://www.iana.org/protocols

IANA notes that the following actions create eight new registries on the new registry page and each of the eight new registries are to be managed via Specification Required as defined in RFC8126.

Second, on the registry page created above, a new registry will be created called the MLS Ciphersuites registry. The registry is to be managed via Specification Required as defined by RFC 8126. There are initial registrations in the new registry as follows:

MLS Ciphersuites
Component Contents Reference
---------+-------------------------------------------------------------+-------------
LVL The security level (in bits) [ RFC-to-be ]
KEM The KEM algorithm used for HPKE in ratchet tree operations [ RFC-to-be ]
AEAD The AEAD algorithm used for HPKE and message protection [ RFC-to-be ]
HASH The hash algorithm used for HPKE and the MLS transcript hash [ RFC-to-be ]
SIG The Signature algorithm used for message authentication [ RFC-to-be ]

Third, on the registry page created above, a new registry will be created called the MLS Wire Formats registry. The registry is to be managed via Specification Required as defined by RFC 8126. There are initial registrations in the new registry as follows:

MLS Wire Formats
Value Name Recommended Reference
--------+---------------+-----------------+-------------
0x0000 RESERVED N/A [ RFC-to-be ]
0x0001 mls_plaintext Y [ RFC-to-be ]
0x0002 mls_ciphertext Y [ RFC-to-be ]
0x0003 mls_welcome Y [ RFC-to-be ]
0x0004 mls_group_info Y [ RFC-to-be ]
0x0005 mls_key_package Y [ RFC-to-be ]
0x0006 - Unassigned
0xefff
0xf000 - Reserved for N/A [ RFC-to-be ]
0xffff Private Use

Fourth, on the registry page created above, a new registry will be created called the MLS Extension Types registry. The registry is to be managed via Specification Required as defined by RFC 8126. There are initial registrations in the new registry as follows:

MLS Extension Types
Value Name Message(s) Recommended Reference
-------+----------------------+----------+-----------+-------------
0x0000 RESERVED N/A N/A [ RFC-to-be ]
0x0001 application_id LN Y [ RFC-to-be ]
0x0002 ratchet_tree GI Y [ RFC-to-be ]
0x0003 required_capabilities GC Y [ RFC-to-be ]
0x0004 external_pub GI Y [ RFC-to-be ]
0x0005 external_senders GC Y [ RFC-to-be ]
0x0006 - Unassigned
0xefff
0xf000 - Reserved for Private N/A N/A [ RFC-to-be ]
0xffff Use

Fifth, on the registry page created above, a new registry will be created called the MLS Proposal Types registry. The registry is to be managed via Specification Required as defined by RFC 8126. There are initial registrations in the new registry as follows:

MLS Proposal Types
Value Name Recommended Path Required Reference
--------+------------------------+-----------+-------------+-------------
0x0000 RESERVED N/A N/A [ RFC-to-be ]
0x0001 add Y N [ RFC-to-be ]
0x0002 update Y Y [ RFC-to-be ]
0x0003 remove Y Y [ RFC-to-be ]
0x0004 psk Y N [ RFC-to-be ]
0x0005 reinit Y N [ RFC-to-be ]
0x0006 external_init Y Y [ RFC-to-be ]
0x0007 group_context_extensions Y Y [ RFC-to-be ]
0x0008 - Unassigned
0xefff
0xf000 - Reserved for Private Use N/A N/A [ RFC-to-be ]
0xffff

Sixth, on the registry page created above, a new registry will be created called the MLS Credential Types registry. The registry is to be managed via Specification Required as defined by RFC 8126. There are initial registrations in the new registry as follows:

MLS Credential Types
Value Name Recommended Reference
--------+------------+-----------------+-------------
0x0000 RESERVED N/A [ RFC-to-be ]
0x0001 basic Y [ RFC-to-be ]
0x0002 x509 Y [ RFC-to-be ]
0x0003 - Unassigned
0xefff
0xf000 - Reserved for N/A [ RFC-to-be ]
0xffff Private Use

Seventh, on the registry page created above, a new registry will be created called the MLS Signature Labels registry. The registry is to be managed via Specification Required as defined by RFC 8126. There are initial registrations in the new registry as follows:

MLS Signature Labels
Label Recommended Reference
------------------+------------+-------------
"FramedContentTBS" Y [ RFC-to-be ]
"LeafNodeTBS" Y [ RFC-to-be ]
"KeyPackageTBS" Y [ RFC-to-be ]
"GroupInfoTBS" Y [ RFC-to-be ]



IANA QUESTION --> Should the label strings appear in the registry with quotemarks or without?



Eighth, on the registry page created above, a new registry will be created called the MLS Public Key Encryption Labels registry. The registry is to be managed via Specification Required as defined by RFC 8126. There are initial registrations in the new registry as follows:

MLS Public Key Encryption Labels
Label Recommended Reference
-----------------+-------------+-------------
"UpdatePathNode" Y [ RFC-to-be ]
"Welcome" Y [ RFC-to-be ]



IANA QUESTION --> A similar question to the question about Signature Labels. Should the encryption label strings appear in the registry with quotemarks or without?



Ninth, on the registry page created above, a new registry will be created called the MLS Exporter Labels registry. The registry is to be managed via Specification Required as defined by RFC 8126. There are no initial registrations in the new registry.

The IANA Functions Operator understands that these are the only actions required to be completed upon approval of this document.

Note:  The actions requested in this document will not be completed until the document has been approved for publication as an RFC. This message is meant only to confirm the list of actions that will be performed.

For definitions of IANA review states, please see:

https://datatracker.ietf.org/help/state/draft/iana-review

Thank you,

David Dong
IANA Services Specialist

The following Last Call announcement was sent out (ends 2023-01-16):

From: The IESG
To: IETF-Announce
CC: alan@wire.com, benjamin.beurdouche@ens.fr, cas.cremers@cs.ox.ac.uk, draft-ietf-mls-protocol@ietf.org, ekr@rtfm.com, karthikeyan.bhargavan@inria.fr, kwonal@mit.edu, mls-chairs@ietf.org, mls@ietf.org, paul.wouters@aiven.io, sean@sn3rd.com, singuva@twitter.com, thyla.van.der@merwe.tech
Reply-To: last-call@ietf.org
Sender:
Subject: Last Call:  (The Messaging Layer Security (MLS) Protocol) to Proposed Standard


The IESG has received a request from the Messaging Layer Security WG (mls) to
consider the following document: - 'The Messaging Layer Security (MLS)
Protocol'
  as Proposed Standard

The IESG plans to make a decision in the next few weeks, and solicits final
comments on this action. Please send substantive comments to the
last-call@ietf.org mailing lists by 2023-01-16. Exceptionally, comments may
be sent to iesg@ietf.org instead. In either case, please retain the beginning
of the Subject line to allow automated sorting.

Abstract


  Messaging applications are increasingly making use of end-to-end
  security mechanisms to ensure that messages are only accessible to
  the communicating endpoints, and not to any servers involved in
  delivering messages.  Establishing keys to provide such protections
  is challenging for group chat settings, in which more than two
  clients need to agree on a key but may not be online at the same
  time.  In this document, we specify a key establishment protocol that
  provides efficient asynchronous group key establishment with forward
  secrecy and post-compromise security for groups in size ranging from
  two to thousands.




The file can be obtained via
https://datatracker.ietf.org/doc/draft-ietf-mls-protocol/


The following IPR Declarations may be related to this I-D:

  https://datatracker.ietf.org/ipr/4015/



The document contains these normative downward references.
See RFC 3967 for additional information:
    rfc9180: Hybrid Public Key Encryption (Informational - Internet Research Task Force (IRTF))

Request for posting confirmation emailed to previous authors: Benjamin Beurdouche , Emad Omara , Jon Millican , Katriel Cohn-Gordon , Raphael Robert , Richard Barnes , mls-chairs@ietf.org

# Document Shepherd Write-Up for Group Documents

## Document History

1. Does the working group (WG) consensus represent the strong concurrence of a
  few individuals, with others being silent, or did it reach broad agreement?

The WG consensus was broad. MLS is not the biggest WG, but there were enough
WG that were active participants during its development that agreed the I-D
was ready to proceed down the road to satisfy both chairs; many of the
participants are implementers. Additionally, some of WG participants are also
part of the security research community and they agreed that the protocol
was provably secure. Without this research, the chairs would not progress this
I-D.

2. Was there controversy about particular points, or were there decisions where
  the consensus was particularly rough?

Surprisingly, no. There was lots of back and forth as well as some frustration,
but generally speaking this development of this I-D was what I hope happens
for most I-Ds.

3. Has anyone threatened an appeal or otherwise indicated extreme discontent? If
  so, please summarize the areas of conflict in separate email messages to the
  responsible Area Director. (It should be in a separate email because this
  questionnaire is publicly available.)

No.

4. For protocol documents, are there existing implementations of the contents of
  the document? Have a significant number of potential implementers indicated
  plans to implement? Are any existing implementations reported somewhere,
  either in the document itself (as [RFC 7942][3] recommends) or elsewhere
  (where)?

We have a github implementation repo that can be found at:
https://github.com/mlswg/mls-implementations

But, a more accurate list of implementations is:

- MLSpp = open source, deployed in production
- OpenMLS = open source
- Wickr's implementation = closed source
- RingCentral's implementation = closed source, deployed in production
- Element's Typescript implementation = open source, only prototype-grade

## Additional Reviews

5. Do the contents of this document closely interact with technologies in other
  IETF working groups or external organizations, and would it therefore benefit
  from their review? Have those reviews occurred? If yes, describe which
  reviews took place.

MLS was intentionally written to be independent of the application layer. See
draft-ietf-mls-architecture for more information.

6. Describe how the document meets any required formal expert review criteria,
  such as the MIB Doctor, YANG Doctor, media type, and URI type reviews.

MLS uses the TLS presentation language. There is no formal expert review
criteria for the TLS presentation language.

There is a Media Type defined. IANA performed an early review and noted that
a few this needed to be addressed; a PR was created:
https://github.com/mlswg/mls-protocol/pull/730/files
The revised registration was shared with the media-types@ietf.org mailing
list.

7. If the document contains a YANG module, has the final version of the module
  been checked with any of the [recommended validation tools][4] for syntax and
  formatting validation? If there are any resulting errors or warnings, what is
  the justification for not fixing them at this time? Does the YANG module
  comply with the Network Management Datastore Architecture (NMDA) as specified
  in [RFC 8342][5]?

N/A

8. Describe reviews and automated checks performed to validate sections of the
  final version of the document written in a formal language, such as XML code,
  BNF rules, MIB definitions, CBOR's CDDL, etc.

N/A

## Document Shepherd Checks

9. Based on the shepherd's review of the document, is it their opinion that this
  document is needed, clearly written, complete, correctly designed, and ready
  to be handed off to the responsible Area Director?

Yes.

10. Several IETF Areas have assembled [lists of common issues that their
    reviewers encounter][6]. For which areas have such issues been identified
    and addressed? For which does this still need to happen in subsequent
    reviews?

After reviewing the list, it is not clear that most of the common issues apply
to this particular I-D. Remember, that there is also a companion archiecture
draft: draft-ietf-mls-architecture.

11. What type of RFC publication is being requested on the IETF stream ([Best
    Current Practice][12], [Proposed Standard, Internet Standard][13],
    [Informational, Experimental or Historic][14])? Why is this the proper type
    of RFC? Do all Datatracker state attributes correctly reflect this intent?

PS is the intended status. PS is the proper status for this on-the-wire
protocol. Yes, the datatracker state attributes correctly reflect PS.

12. Have reasonable efforts been made to remind all authors of the intellectual
    property rights (IPR) disclosure obligations described in [BCP 79][8]? To
    the best of your knowledge, have all required disclosures been filed? If
    not, explain why. If yes, summarize any relevant discussion, including links
    to publicly-available messages when applicable.

Yes, I have personally verified with the authors that they have met the IPR
disclosure obligations in [BCP79].

****
  NOTE: A 3rd party IPR disclosure was filed. Based on advice from Ben Kaduk,
  who was our AD at the time, I sent the following email during WGLC to
  determine how the WG wanted to handle the disclosure:
  https://mailarchive.ietf.org/arch/msg/mls/BB9WsfNDgLp_dEQ60Uw3S75qBmA/
  As you can see in the thread, the WG was comfortable progressing the I-D.
****

13. Has each author, editor, and contributor shown their willingness to be
    listed as such? If the total number of authors and editors on the front page
    is greater than five, please provide a justification.

I have personally verified that all authors are willing to be listed as such.

There are 6 authors listed and for a working group this size that might seem like
a lot, but each of the listed authors provided thrust at one point or another
to move this document along and I would be disinclined to remove one of them.

14. Document any remaining I-D nits in this document. Simply running the [idnits
    tool][8] is not enough; please review the ["Content Guidelines" on
    authors.ietf.org][15]. (Also note that the current idnits tool generates
    some incorrect warnings; a rewrite is underway.)

Lots of nits about lines too long. These seem to relate to the figures; SVG FTW.

Complaints about non-ascii text. These relate to authors' names.

There are two warnings related to references:

Outdated reference: draft-ietf-mls-architecture will likely always be out of
synch or the reference to this I-D in draft-ietf-mls-architecture to this I-D
will be out of synch.

Obsolete informational reference: RFC 7540 - this draft references HTTP/2 so
7540 is the correct reference. Also, review the text and you will note leaving
this alone is fine, i.e., the I-D does not need to update the reference to HTTP/3.

15. Should any informative references be normative or vice-versa? See the [IESG
    Statement on Normative and Informative References][16].

I think the references are fine. Richard wanted me to note that during WGLC
we did move one normative reference to informative.

16. List any normative references that are not freely available to anyone. Did
    the community have sufficient access to review any such normative
    references?

All normative references are to RFCs.

17. Are there any normative downward references (see [RFC 3967][9] and [BCP
    97][10]) that are not already listed in the [DOWNREF registry][17]? If so,
    list them.

No.

18. Are there normative references to documents that are not ready to be
    submitted to the IESG for publication or are otherwise in an unclear state?
    If so, what is the plan for their completion?

No.

19. Will publication of this document change the status of any existing RFCs? If
    so, does the Datatracker metadata correctly reflect this and are those RFCs
    listed on the title page, in the abstract, and discussed in the
    introduction? If not, explain why and point to the part of the document
    where the relationship of this document to these other RFCs is discussed.

No.

20. Describe the document shepherd's review of the IANA considerations section,
    especially with regard to its consistency with the body of the document.
    Confirm that all aspects of the document requiring IANA assignments are
    associated with the appropriate reservations in IANA registries. Confirm
    that any referenced IANA registries have been clearly identified. Confirm
    that each newly created IANA registry specifies its initial contents,
    allocations procedures, and a reasonable name (see [RFC 8126][11]).

The Shepherd reviewed the assignment for consistency with the body of the I-D.

The Shepherd confirmed the following:
- All aspects of the document requiring IANA assignments are
  associated with the appropriate reservations in IANA registries.
- Any referenced IANA registries have been clearly identified.
- Each newly created IANA registry specifies its initial contents,
  allocations procedures, and a reasonable name (see [RFC 8126][11]).

NOTE: Submitted an issue to expand the definition of the Recommended column
to include a "D" for discouraged; the consensus for RFC 8447bis at saag was
to add this new value to the registry.

21. List any new IANA registries that require Designated Expert Review for
    future allocations. Are the instructions to the Designated Expert clear?
    Please include suggestions of designated experts, if appropriate.

There are four registry created by this I-D and all require DEs. Section
17.5 includes text for the DEs. Note that this text is based on the DE
text in RFC 8447.

[1]: https://www.ietf.org/about/groups/iesg/
[2]: https://www.rfc-editor.org/rfc/rfc4858.html
[3]: https://www.rfc-editor.org/rfc/rfc7942.html
[4]: https://trac.ietf.org/trac/ops/wiki/yang-review-tools
[5]: https://www.rfc-editor.org/rfc/rfc8342.html
[6]: https://trac.ietf.org/trac/iesg/wiki/ExpertTopics
[7]: https://www.rfc-editor.org/info/bcp79
[8]: https://www.ietf.org/tools/idnits/
[9]: https://www.rfc-editor.org/rfc/rfc3967.html
[10]: https://www.rfc-editor.org/info/bcp97
[11]: https://www.rfc-editor.org/rfc/rfc8126.html
[12]: https://www.rfc-editor.org/rfc/rfc2026.html#section-5
[13]: https://www.rfc-editor.org/rfc/rfc2026.html#section-4.1
[14]: https://www.rfc-editor.org/rfc/rfc2026.html#section-4.2
[15]: https://authors.ietf.org/en/content-guidelines-overview
[16]: https://www.ietf.org/about/groups/iesg/statements/normative-informative-references/
[17]: https://datatracker.ietf.org/doc/downref/

# Document Shepherd Write-Up for Group Documents

## Document History

1. Does the working group (WG) consensus represent the strong concurrence of a
  few individuals, with others being silent, or did it reach broad agreement?

The WG consensus was broad. MLS is not the biggest WG, but there were enough
WG that were active participants during its development that agreed the I-D
was ready to proceed down the road to satisfy both chairs; many of the
participants are implementers. Additionally, some of WG participants are also
part of the security research community and they agreed that the protocol
was provably secure. Without this research, the chairs would not progress this
I-D.

2. Was there controversy about particular points, or were there decisions where
  the consensus was particularly rough?

Surprisingly, no. There was lots of back and forth as well as some frustration,
but generally speaking this development of this I-D was what I hope happens
for most I-Ds.

3. Has anyone threatened an appeal or otherwise indicated extreme discontent? If
  so, please summarize the areas of conflict in separate email messages to the
  responsible Area Director. (It should be in a separate email because this
  questionnaire is publicly available.)

No.

4. For protocol documents, are there existing implementations of the contents of
  the document? Have a significant number of potential implementers indicated
  plans to implement? Are any existing implementations reported somewhere,
  either in the document itself (as [RFC 7942][3] recommends) or elsewhere
  (where)?

We have a github implementation repo that can be found at:
https://github.com/mlswg/mls-implementations

But, a more accurate list of implementations is:

- MLSpp = open source, deployed in production
- OpenMLS = open source
- Wickr's implementation = closed source
- RingCentral's implementation = closed source, deployed in production
- Element's Typescript implementation = open source, only prototype-grade

## Additional Reviews

5. Do the contents of this document closely interact with technologies in other
  IETF working groups or external organizations, and would it therefore benefit
  from their review? Have those reviews occurred? If yes, describe which
  reviews took place.

MLS was intentionally written to be independent of the application layer. See
draft-ietf-mls-architecture for more information.

6. Describe how the document meets any required formal expert review criteria,
  such as the MIB Doctor, YANG Doctor, media type, and URI type reviews.

MLS uses the TLS presentation language. There is no formal expert review
criteria for the TLS presentation language.

There is a Media Type defined. IANA performed an early review and noted that
a few this needed to be addressed; a PR was created:
https://github.com/mlswg/mls-protocol/pull/730/files
The revised registration was shared with the media-types@ietf.org mailing
list.

7. If the document contains a YANG module, has the final version of the module
  been checked with any of the [recommended validation tools][4] for syntax and
  formatting validation? If there are any resulting errors or warnings, what is
  the justification for not fixing them at this time? Does the YANG module
  comply with the Network Management Datastore Architecture (NMDA) as specified
  in [RFC 8342][5]?

N/A

8. Describe reviews and automated checks performed to validate sections of the
  final version of the document written in a formal language, such as XML code,
  BNF rules, MIB definitions, CBOR's CDDL, etc.

N/A

## Document Shepherd Checks

9. Based on the shepherd's review of the document, is it their opinion that this
  document is needed, clearly written, complete, correctly designed, and ready
  to be handed off to the responsible Area Director?

Yes.

10. Several IETF Areas have assembled [lists of common issues that their
    reviewers encounter][6]. For which areas have such issues been identified
    and addressed? For which does this still need to happen in subsequent
    reviews?

After reviewing the list, it is not clear that most of the common issues apply
to this particular I-D. Remember, that there is also a companion archiecture
draft: draft-ietf-mls-architecture.

11. What type of RFC publication is being requested on the IETF stream ([Best
    Current Practice][12], [Proposed Standard, Internet Standard][13],
    [Informational, Experimental or Historic][14])? Why is this the proper type
    of RFC? Do all Datatracker state attributes correctly reflect this intent?

PS is the intended status. PS is the proper status for this on-the-wire
protocol. Yes, the datatracker state attributes correctly reflect PS.

12. Have reasonable efforts been made to remind all authors of the intellectual
    property rights (IPR) disclosure obligations described in [BCP 79][8]? To
    the best of your knowledge, have all required disclosures been filed? If
    not, explain why. If yes, summarize any relevant discussion, including links
    to publicly-available messages when applicable.

Yes, I have personally verified with the authors that they have met the IPR
disclosure obligations in [BCP79].

****
  NOTE: A 3rd party IPR disclosure was filed. Based on advice from Ben Kaduk,
  who was our AD at the time, I sent the following email during WGLC to
  determine how the WG wanted to handle the disclosure:
  https://mailarchive.ietf.org/arch/msg/mls/BB9WsfNDgLp_dEQ60Uw3S75qBmA/
  As you can see in the thread, the WG was comfortable progressing the I-D.
****

13. Has each author, editor, and contributor shown their willingness to be
    listed as such? If the total number of authors and editors on the front page
    is greater than five, please provide a justification.

I have personally verified that all authors are willing to be listed as such.

There are 6 authors listed and for a working group this size that might seem like
a lot, but each of the listed authors provided thrust at one point or another
to move this document along and I would be disinclined to remove one of them.

14. Document any remaining I-D nits in this document. Simply running the [idnits
    tool][8] is not enough; please review the ["Content Guidelines" on
    authors.ietf.org][15]. (Also note that the current idnits tool generates
    some incorrect warnings; a rewrite is underway.)

Lots of nits about lines too long. These seem to relate to the figures; SVG FTW.

Complaints about non-ascii text. These relate to authors' names.

There are two warnings related to references:

Outdated reference: draft-ietf-mls-architecture will likely always be out of
synch or the reference to this I-D in draft-ietf-mls-architecture to this I-D
will be out of synch.

Obsolete informational reference: RFC 7540 - this draft references HTTP/2 so
7540 is the correct reference. Also, review the text and you will note leaving
this alone is fine, i.e., the I-D does not need to update the reference to HTTP/3.

15. Should any informative references be normative or vice-versa? See the [IESG
    Statement on Normative and Informative References][16].

I think the references are fine. Richard wanted me to note that during WGLC
we did move one normative reference to informative.

16. List any normative references that are not freely available to anyone. Did
    the community have sufficient access to review any such normative
    references?

All normative references are to RFCs.

17. Are there any normative downward references (see [RFC 3967][9] and [BCP
    97][10]) that are not already listed in the [DOWNREF registry][17]? If so,
    list them.

No.

18. Are there normative references to documents that are not ready to be
    submitted to the IESG for publication or are otherwise in an unclear state?
    If so, what is the plan for their completion?

No.

19. Will publication of this document change the status of any existing RFCs? If
    so, does the Datatracker metadata correctly reflect this and are those RFCs
    listed on the title page, in the abstract, and discussed in the
    introduction? If not, explain why and point to the part of the document
    where the relationship of this document to these other RFCs is discussed.

No.

20. Describe the document shepherd's review of the IANA considerations section,
    especially with regard to its consistency with the body of the document.
    Confirm that all aspects of the document requiring IANA assignments are
    associated with the appropriate reservations in IANA registries. Confirm
    that any referenced IANA registries have been clearly identified. Confirm
    that each newly created IANA registry specifies its initial contents,
    allocations procedures, and a reasonable name (see [RFC 8126][11]).

The Shepherd reviewed the assignment for consistency with the body of the I-D.

The Shepherd confirmed the following:
- All aspects of the document requiring IANA assignments are
  associated with the appropriate reservations in IANA registries.
- Any referenced IANA registries have been clearly identified.
- Each newly created IANA registry specifies its initial contents,
  allocations procedures, and a reasonable name (see [RFC 8126][11]).

NOTE: Submitted an issue to expand the definition of the Recommended column
to include a "D" for discouraged; the consensus for RFC 8447bis at saag was
to add this new value to the registry.

21. List any new IANA registries that require Designated Expert Review for
    future allocations. Are the instructions to the Designated Expert clear?
    Please include suggestions of designated experts, if appropriate.

There are four registry created by this I-D and all require DEs. Section
17.5 includes text for the DEs. Note that this text is based on the DE
text in RFC 8447.

[1]: https://www.ietf.org/about/groups/iesg/
[2]: https://www.rfc-editor.org/rfc/rfc4858.html
[3]: https://www.rfc-editor.org/rfc/rfc7942.html
[4]: https://trac.ietf.org/trac/ops/wiki/yang-review-tools
[5]: https://www.rfc-editor.org/rfc/rfc8342.html
[6]: https://trac.ietf.org/trac/iesg/wiki/ExpertTopics
[7]: https://www.rfc-editor.org/info/bcp79
[8]: https://www.ietf.org/tools/idnits/
[9]: https://www.rfc-editor.org/rfc/rfc3967.html
[10]: https://www.rfc-editor.org/info/bcp97
[11]: https://www.rfc-editor.org/rfc/rfc8126.html
[12]: https://www.rfc-editor.org/rfc/rfc2026.html#section-5
[13]: https://www.rfc-editor.org/rfc/rfc2026.html#section-4.1
[14]: https://www.rfc-editor.org/rfc/rfc2026.html#section-4.2
[15]: https://authors.ietf.org/en/content-guidelines-overview
[16]: https://www.ietf.org/about/groups/iesg/statements/normative-informative-references/
[17]: https://datatracker.ietf.org/doc/downref/

# Document Shepherd Write-Up for Group Documents

## Document History

1. Does the working group (WG) consensus represent the strong concurrence of a
  few individuals, with others being silent, or did it reach broad agreement?

The WG consensus was broad. MLS is not the biggest WG, but there were enough
WG that were active participants during its development that agreed the I-D
was ready to proceed down the road to satisfy both chairs; many of the
participants are implementers. Additionally, some of WG participants are also
part of the security research community and they agreed that the protocol
was provably secure. Without this research, the chairs would not progress this
I-D.

2. Was there controversy about particular points, or were there decisions where
  the consensus was particularly rough?

Surprisingly, no. There was lots of back and forth as well as some frustration,
but generally speaking this development of this I-D was what I hope happens
for most I-Ds.

3. Has anyone threatened an appeal or otherwise indicated extreme discontent? If
  so, please summarize the areas of conflict in separate email messages to the
  responsible Area Director. (It should be in a separate email because this
  questionnaire is publicly available.)

No.

4. For protocol documents, are there existing implementations of the contents of
  the document? Have a significant number of potential implementers indicated
  plans to implement? Are any existing implementations reported somewhere,
  either in the document itself (as [RFC 7942][3] recommends) or elsewhere
  (where)?

We have a github implementation repo that can be found at:
https://github.com/mlswg/mls-implementations

But, a more accurate list of implementations is:

- MLSpp = open source, deployed in production
- OpenMLS = open source
- Wickr's implementation = closed source
- RingCentral's implementation = closed source, deployed in production
- Element's Typescript implementation = open source, only prototype-grade

## Additional Reviews

5. Do the contents of this document closely interact with technologies in other
  IETF working groups or external organizations, and would it therefore benefit
  from their review? Have those reviews occurred? If yes, describe which
  reviews took place.

MLS was intentionally written to be independent of the application layer. See
draft-ietf-mls-architecture for more information.

6. Describe how the document meets any required formal expert review criteria,
  such as the MIB Doctor, YANG Doctor, media type, and URI type reviews.

MLS uses the TLS presentation language. There is no formal expert review
criteria for the TLS presentation language.

There is a Media Type defined. IANA performed an early review and noted that
a few this needed to be addressed; a PR was created:
https://github.com/mlswg/mls-protocol/pull/730/files
The revised registration was shared with the media-types@ietf.org mailing
list.

7. If the document contains a YANG module, has the final version of the module
  been checked with any of the [recommended validation tools][4] for syntax and
  formatting validation? If there are any resulting errors or warnings, what is
  the justification for not fixing them at this time? Does the YANG module
  comply with the Network Management Datastore Architecture (NMDA) as specified
  in [RFC 8342][5]?

N/A

8. Describe reviews and automated checks performed to validate sections of the
  final version of the document written in a formal language, such as XML code,
  BNF rules, MIB definitions, CBOR's CDDL, etc.

N/A

## Document Shepherd Checks

9. Based on the shepherd's review of the document, is it their opinion that this
  document is needed, clearly written, complete, correctly designed, and ready
  to be handed off to the responsible Area Director?

Yes.

10. Several IETF Areas have assembled [lists of common issues that their
    reviewers encounter][6]. For which areas have such issues been identified
    and addressed? For which does this still need to happen in subsequent
    reviews?

After reviewing the list, it is not clear that most of the common issues apply
to this particular I-D. Remember, that there is also a companion archiecture
draft: draft-ietf-mls-architecture.

11. What type of RFC publication is being requested on the IETF stream ([Best
    Current Practice][12], [Proposed Standard, Internet Standard][13],
    [Informational, Experimental or Historic][14])? Why is this the proper type
    of RFC? Do all Datatracker state attributes correctly reflect this intent?

PS is the intended status. PS is the proper status for this on-the-wire
protocol. Yes, the datatracker state attributes correctly reflect PS.

12. Have reasonable efforts been made to remind all authors of the intellectual
    property rights (IPR) disclosure obligations described in [BCP 79][8]? To
    the best of your knowledge, have all required disclosures been filed? If
    not, explain why. If yes, summarize any relevant discussion, including links
    to publicly-available messages when applicable.

Yes, I have personally verified with the 5 authors that they have met the IPR
disclosure obligations in [BCP79].

****
  NOTE: A 3rd party IPR disclosure was filed. Based on advice from Ben Kaduk,
  who was our AD at the time, I sent the following email during WGLC to
  determine how the WG wanted to handle the disclosure:
  https://mailarchive.ietf.org/arch/msg/mls/BB9WsfNDgLp_dEQ60Uw3S75qBmA/
  As you can see in the thread, the WG was comfortable progressing the I-D.
****

13. Has each author, editor, and contributor shown their willingness to be
    listed as such? If the total number of authors and editors on the front page
    is greater than five, please provide a justification.

I have personally verified that all authors are willing to be listed as such.

There are 6 authors listed and for a working group this size that might seem like
a lot, but each of the listed authors provided thrust at one point or another
to move this document along and I would be disinclined to remove one of them.

14. Document any remaining I-D nits in this document. Simply running the [idnits
    tool][8] is not enough; please review the ["Content Guidelines" on
    authors.ietf.org][15]. (Also note that the current idnits tool generates
    some incorrect warnings; a rewrite is underway.)

Lots of nits about lines too long. These seem to relate to the figures; SVG FTW.

Complaints about non-ascii text. These relate to authors' names.

There are two warnings related to references:

Outdated reference: draft-ietf-mls-architecture will likely always be out of
synch or the reference to this I-D in draft-ietf-mls-architecture to this I-D
will be out of synch.

Obsolete informational reference: RFC 7540 - this draft references HTTP/2 so
7540 is the correct reference. Also, review the text and you will note leaving
this alone is fine, i.e., the I-D does not need to update the reference to HTTP/3.

15. Should any informative references be normative or vice-versa? See the [IESG
    Statement on Normative and Informative References][16].

I think the references are fine. Richard wanted me to note that during WGLC
we did move one normative reference to informative.

16. List any normative references that are not freely available to anyone. Did
    the community have sufficient access to review any such normative
    references?

All normative references are to RFCs.

17. Are there any normative downward references (see [RFC 3967][9] and [BCP
    97][10]) that are not already listed in the [DOWNREF registry][17]? If so,
    list them.

No.

18. Are there normative references to documents that are not ready to be
    submitted to the IESG for publication or are otherwise in an unclear state?
    If so, what is the plan for their completion?

No.

19. Will publication of this document change the status of any existing RFCs? If
    so, does the Datatracker metadata correctly reflect this and are those RFCs
    listed on the title page, in the abstract, and discussed in the
    introduction? If not, explain why and point to the part of the document
    where the relationship of this document to these other RFCs is discussed.

No.

20. Describe the document shepherd's review of the IANA considerations section,
    especially with regard to its consistency with the body of the document.
    Confirm that all aspects of the document requiring IANA assignments are
    associated with the appropriate reservations in IANA registries. Confirm
    that any referenced IANA registries have been clearly identified. Confirm
    that each newly created IANA registry specifies its initial contents,
    allocations procedures, and a reasonable name (see [RFC 8126][11]).

The Shepherd reviewed the assignment for consistency with the body of the I-D.

The Shepherd confirmed the following:
- All aspects of the document requiring IANA assignments are
  associated with the appropriate reservations in IANA registries.
- Any referenced IANA registries have been clearly identified.
- Each newly created IANA registry specifies its initial contents,
  allocations procedures, and a reasonable name (see [RFC 8126][11]).

NOTE: Submitted an issue to expand the definition of the Recommended column
to include a "D" for discouraged; the consensus for RFC 8447bis at saag was
to add this new value to the registry.

21. List any new IANA registries that require Designated Expert Review for
    future allocations. Are the instructions to the Designated Expert clear?
    Please include suggestions of designated experts, if appropriate.

There are four registry created by this I-D and all require DEs. Section
17.5 includes text for the DEs. Note that this text is based on the DE
text in RFC 8447.

[1]: https://www.ietf.org/about/groups/iesg/
[2]: https://www.rfc-editor.org/rfc/rfc4858.html
[3]: https://www.rfc-editor.org/rfc/rfc7942.html
[4]: https://trac.ietf.org/trac/ops/wiki/yang-review-tools
[5]: https://www.rfc-editor.org/rfc/rfc8342.html
[6]: https://trac.ietf.org/trac/iesg/wiki/ExpertTopics
[7]: https://www.rfc-editor.org/info/bcp79
[8]: https://www.ietf.org/tools/idnits/
[9]: https://www.rfc-editor.org/rfc/rfc3967.html
[10]: https://www.rfc-editor.org/info/bcp97
[11]: https://www.rfc-editor.org/rfc/rfc8126.html
[12]: https://www.rfc-editor.org/rfc/rfc2026.html#section-5
[13]: https://www.rfc-editor.org/rfc/rfc2026.html#section-4.1
[14]: https://www.rfc-editor.org/rfc/rfc2026.html#section-4.2
[15]: https://authors.ietf.org/en/content-guidelines-overview
[16]: https://www.ietf.org/about/groups/iesg/statements/normative-informative-references/
[17]: https://datatracker.ietf.org/doc/downref/

# Document Shepherd Write-Up for Group Documents

## Document History

1. Does the working group (WG) consensus represent the strong concurrence of a
  few individuals, with others being silent, or did it reach broad agreement?

The WG reach broad agreement. MLS is not the biggest WG, but there were enough
WG that were active participants during its development that agreed the I-D
was ready to proceed down the road to satisfy both chairs. Additionally, some
of WG participants are also part of the security research community and the
chair did not want to progress this I-D until we heard from enough of them
to make the chairs comfortable that analysis has completed.

2. Was there controversy about particular points, or were there decisions where
  the consensus was particularly rough?

Surprisingly, no. There was lots of back and forth as well as some frustration,
but generally speaking this development of this I-D was what I hope happens
for most I-Ds.

3. Has anyone threatened an appeal or otherwise indicated extreme discontent? If
  so, please summarize the areas of conflict in separate email messages to the
  responsible Area Director. (It should be in a separate email because this
  questionnaire is publicly available.)

No.

4. For protocol documents, are there existing implementations of the contents of
  the document? Have a significant number of potential implementers indicated
  plans to implement? Are any existing implementations reported somewhere,
  either in the document itself (as [RFC 7942][3] recommends) or elsewhere
  (where)?

There are existing implementations; by my count 4 (possibly 5). One of these
is an open source project.

We have a github implementation repo that can be found at:
https://github.com/mlswg/mls-implementations

## Additional Reviews

5. Do the contents of this document closely interact with technologies in other
  IETF working groups or external organizations, and would it therefore benefit
  from their review? Have those reviews occurred? If yes, describe which
  reviews took place.

MLS was intentionally written to be independent of the application layer. See
draft-ietf-mls-architecture for more information.

6. Describe how the document meets any required formal expert review criteria,
  such as the MIB Doctor, YANG Doctor, media type, and URI type reviews.

MLS uses the TLS presentation language. There is no formal expert review
criteria for the TLS presentation language.

There is a Media Type defined. IANA performed an early review and noted that
a few this needed to be addressed; a PR was created:
https://github.com/mlswg/mls-protocol/pull/730/files
The revised registration was shared with the media-types@ietf.org mailing
list.

7. If the document contains a YANG module, has the final version of the module
  been checked with any of the [recommended validation tools][4] for syntax and
  formatting validation? If there are any resulting errors or warnings, what is
  the justification for not fixing them at this time? Does the YANG module
  comply with the Network Management Datastore Architecture (NMDA) as specified
  in [RFC 8342][5]?

N/A

8. Describe reviews and automated checks performed to validate sections of the
  final version of the document written in a formal language, such as XML code,
  BNF rules, MIB definitions, CBOR's CDDL, etc.

N/A

## Document Shepherd Checks

9. Based on the shepherd's review of the document, is it their opinion that this
  document is needed, clearly written, complete, correctly designed, and ready
  to be handed off to the responsible Area Director?

Yes.

10. Several IETF Areas have assembled [lists of common issues that their
    reviewers encounter][6]. For which areas have such issues been identified
    and addressed? For which does this still need to happen in subsequent
    reviews?

After reviewing the list, it is not clear that most of the common issues apply
to this particular I-D. Remember, that there is also a companion archiecture
draft: draft-ietf-mls-architecture.

11. What type of RFC publication is being requested on the IETF stream ([Best
    Current Practice][12], [Proposed Standard, Internet Standard][13],
    [Informational, Experimental or Historic][14])? Why is this the proper type
    of RFC? Do all Datatracker state attributes correctly reflect this intent?

PS is the intended status. PS is the proper status for this on-the-wire
protocol. Yes, the datatracker state attributes correctly reflect PS.

12. Have reasonable efforts been made to remind all authors of the intellectual
    property rights (IPR) disclosure obligations described in [BCP 79][8]? To
    the best of your knowledge, have all required disclosures been filed? If
    not, explain why. If yes, summarize any relevant discussion, including links
    to publicly-available messages when applicable.

Yes, I have personally verified with the 5 authors that they have met the IPR
disclosure obligations in [BCP79].

****
  NOTE: A 3rd party IPR disclosure was filed. Based on advice from Ben Kaduk,
  who was our AD at the time, I sent the following email during WGLC to
  determine how the WG wanted to handle the disclosure:
  https://mailarchive.ietf.org/arch/msg/mls/BB9WsfNDgLp_dEQ60Uw3S75qBmA/
  As you can see in the thread, the WG was comfortable progressing the I-D.
****

13. Has each author, editor, and contributor shown their willingness to be
    listed as such? If the total number of authors and editors on the front page
    is greater than five, please provide a justification.

I have personally verified that all authors are willing to be listed as such.

14. Document any remaining I-D nits in this document. Simply running the [idnits
    tool][8] is not enough; please review the ["Content Guidelines" on
    authors.ietf.org][15]. (Also note that the current idnits tool generates
    some incorrect warnings; a rewrite is underway.)

Lots of nits about lines too long. These seem to relate to the figures; SVG FTW.

Complaints about non-ascii text. These relate to authors' names.

There are two warnings releated to references:

Outdated reference: draft-ietf-mls-architecture will likely always be out of
synch or the reference to this I-D in draft-ietf-mls-architecture to this I-D
will be out of synch.

Obsolete informational reference: RFC 7540 - this draft references HTTP/2 so
7540 is the correct reference. Also, review the text and you will note leaving
this alone is fine, i.e., the I-D does not need to update the reference to HTTP/3.

15. Should any informative references be normative or vice-versa? See the [IESG
    Statement on Normative and Informative References][16].

I think the references are fine.

16. List any normative references that are not freely available to anyone. Did
    the community have sufficient access to review any such normative
    references?

All normative references are to RFCs.

17. Are there any normative downward references (see [RFC 3967][9] and [BCP
    97][10]) that are not already listed in the [DOWNREF registry][17]? If so,
    list them.

No.

18. Are there normative references to documents that are not ready to be
    submitted to the IESG for publication or are otherwise in an unclear state?
    If so, what is the plan for their completion?

No.

19. Will publication of this document change the status of any existing RFCs? If
    so, does the Datatracker metadata correctly reflect this and are those RFCs
    listed on the title page, in the abstract, and discussed in the
    introduction? If not, explain why and point to the part of the document
    where the relationship of this document to these other RFCs is discussed.

No.

20. Describe the document shepherd's review of the IANA considerations section,
    especially with regard to its consistency with the body of the document.
    Confirm that all aspects of the document requiring IANA assignments are
    associated with the appropriate reservations in IANA registries. Confirm
    that any referenced IANA registries have been clearly identified. Confirm
    that each newly created IANA registry specifies its initial contents,
    allocations procedures, and a reasonable name (see [RFC 8126][11]).

The Shepherd reviewed the assignment for consistency with the body of the I-D.

The Shepherd confirmed the following:
- All aspects of the document requiring IANA assignments are
  associated with the appropriate reservations in IANA registries.
- Any referenced IANA registries have been clearly identified.
- Each newly created IANA registry specifies its initial contents,
  allocations procedures, and a reasonable name (see [RFC 8126][11]).

NOTE: Submitted an issue to expand the definition of the Recommended column
to include a "D" for discouraged; the consensus for RFC 8447bis at saag was
to add this new value to the registry.

21. List any new IANA registries that require Designated Expert Review for
    future allocations. Are the instructions to the Designated Expert clear?
    Please include suggestions of designated experts, if appropriate.

There are four registry created by this I-D and all require DEs. Section
17.5 includes text for the DEs. Note that this text is based on the DE
text in RFC 8447.

[1]: https://www.ietf.org/about/groups/iesg/
[2]: https://www.rfc-editor.org/rfc/rfc4858.html
[3]: https://www.rfc-editor.org/rfc/rfc7942.html
[4]: https://trac.ietf.org/trac/ops/wiki/yang-review-tools
[5]: https://www.rfc-editor.org/rfc/rfc8342.html
[6]: https://trac.ietf.org/trac/iesg/wiki/ExpertTopics
[7]: https://www.rfc-editor.org/info/bcp79
[8]: https://www.ietf.org/tools/idnits/
[9]: https://www.rfc-editor.org/rfc/rfc3967.html
[10]: https://www.rfc-editor.org/info/bcp97
[11]: https://www.rfc-editor.org/rfc/rfc8126.html
[12]: https://www.rfc-editor.org/rfc/rfc2026.html#section-5
[13]: https://www.rfc-editor.org/rfc/rfc2026.html#section-4.1
[14]: https://www.rfc-editor.org/rfc/rfc2026.html#section-4.2
[15]: https://authors.ietf.org/en/content-guidelines-overview
[16]: https://www.ietf.org/about/groups/iesg/statements/normative-informative-references/
[17]: https://datatracker.ietf.org/doc/downref/

# Document Shepherd Write-Up for Group Documents

## Document History

1. Does the working group (WG) consensus represent the strong concurrence of a
  few individuals, with others being silent, or did it reach broad agreement?

The WG reach broad agreement. MLS is not the biggest WG, but there were enough
WG that were active participants during its development that agreed the I-D
was ready to proceed down the road to satisfy both chairs. Additionally, some
of WG participants are also part of the security research community and the
chair did not want to progress this I-D until we heard from enough of them
to make the chairs comfortable that analysis has completed.

2. Was there controversy about particular points, or were there decisions where
  the consensus was particularly rough?

Surprisingly, no. There was lots of back and forth as well as some frustration,
but generally speaking this development of this I-D was what I hope happens
for most I-Ds.

3. Has anyone threatened an appeal or otherwise indicated extreme discontent? If
  so, please summarize the areas of conflict in separate email messages to the
  responsible Area Director. (It should be in a separate email because this
  questionnaire is publicly available.)

No.

4. For protocol documents, are there existing implementations of the contents of
  the document? Have a significant number of potential implementers indicated
  plans to implement? Are any existing implementations reported somewhere,
  either in the document itself (as [RFC 7942][3] recommends) or elsewhere
  (where)?

There are existing implementations; by my count 4 (possibly 5). One of these
is an open source project.

We have a github implementation repo that can be found at:
https://github.com/mlswg/mls-implementations

## Additional Reviews

5. Do the contents of this document closely interact with technologies in other
  IETF working groups or external organizations, and would it therefore benefit
  from their review? Have those reviews occurred? If yes, describe which
  reviews took place.

MLS was intentionally written to be independent of the application layer. See
draft-ietf-mls-architecture for more information.

6. Describe how the document meets any required formal expert review criteria,
  such as the MIB Doctor, YANG Doctor, media type, and URI type reviews.

MLS uses the TLS presentation language. There is no formal expert review
criteria for the TLS presentation language.

7. If the document contains a YANG module, has the final version of the module
  been checked with any of the [recommended validation tools][4] for syntax and
  formatting validation? If there are any resulting errors or warnings, what is
  the justification for not fixing them at this time? Does the YANG module
  comply with the Network Management Datastore Architecture (NMDA) as specified
  in [RFC 8342][5]?

N/A

8. Describe reviews and automated checks performed to validate sections of the
  final version of the document written in a formal language, such as XML code,
  BNF rules, MIB definitions, CBOR's CDDL, etc.

N/A

## Document Shepherd Checks

9. Based on the shepherd's review of the document, is it their opinion that this
  document is needed, clearly written, complete, correctly designed, and ready
  to be handed off to the responsible Area Director?

Yes.

10. Several IETF Areas have assembled [lists of common issues that their
    reviewers encounter][6]. For which areas have such issues been identified
    and addressed? For which does this still need to happen in subsequent
    reviews?

After reviewing the list, it is not clear that most of the common issues apply
to this particular I-D. Remember, that there is also a companion archiecture
draft: draft-ietf-mls-architecture.

11. What type of RFC publication is being requested on the IETF stream ([Best
    Current Practice][12], [Proposed Standard, Internet Standard][13],
    [Informational, Experimental or Historic][14])? Why is this the proper type
    of RFC? Do all Datatracker state attributes correctly reflect this intent?

This I-D intended for PS. PS is the proper status for this on-the-wire protocol.
Yes the datatracker state attributes correctly reflect this intent.

12. Have reasonable efforts been made to remind all authors of the intellectual
    property rights (IPR) disclosure obligations described in [BCP 79][8]? To
    the best of your knowledge, have all required disclosures been filed? If
    not, explain why. If yes, summarize any relevant discussion, including links
    to publicly-available messages when applicable.

Yes, I have personally verified with the 5 authors that they have followed the
IPR disclosure obligations in [BCP79].

****
  NOTE: A 3rd party IPR disclosure was filed. Based on advice from Ben Kaduk,
  who was our AD at the time, I sent the following email during WGLC to
  determine how the WG wanted to handle the disclosure:
  https://mailarchive.ietf.org/arch/msg/mls/BB9WsfNDgLp_dEQ60Uw3S75qBmA/
  As you can see in the thread the WG was comfortable progressing the I-D.
****

13. Has each author, editor, and contributor shown their willingness to be
    listed as such? If the total number of authors and editors on the front page
    is greater than five, please provide a justification.

Yes, I have personally verified that all authors are willing to be listed as such.

14. Document any remaining I-D nits in this document. Simply running the [idnits
    tool][8] is not enough; please review the ["Content Guidelines" on
    authors.ietf.org][15]. (Also note that the current idnits tool generates
    some incorrect warnings; a rewrite is underway.)

Lots of nits about lines too long. These seem to relate to the figures; SVG FTW.

Complaints about non-ascii text. These relate to authors' names.

There are two warnings releated to references:

Outdated reference: draft-ietf-mls-architecture will likely always be out of
synch or the reference to this I-D in draft-ietf-mls-architecture to this I-D
will be out of synch.

Obsolete informational reference: RFC 7540 - this draft references HTTP/2 so
7540 is the correct reference. Also, review the text and you will note leaving
this alone is fine, i.e., the I-D does not need to update the reference to HTTP/3.

15. Should any informative references be normative or vice-versa? See the [IESG
    Statement on Normative and Informative References][16].

I think the references are fine.

16. List any normative references that are not freely available to anyone. Did
    the community have sufficient access to review any such normative
    references?

All normative references are to RFCs.

17. Are there any normative downward references (see [RFC 3967][9] and [BCP
    97][10]) that are not already listed in the [DOWNREF registry][17]? If so,
    list them.

No.

18. Are there normative references to documents that are not ready to be
    submitted to the IESG for publication or are otherwise in an unclear state?
    If so, what is the plan for their completion?

No.

19. Will publication of this document change the status of any existing RFCs? If
    so, does the Datatracker metadata correctly reflect this and are those RFCs
    listed on the title page, in the abstract, and discussed in the
    introduction? If not, explain why and point to the part of the document
    where the relationship of this document to these other RFCs is discussed.

No.

20. Describe the document shepherd's review of the IANA considerations section,
    especially with regard to its consistency with the body of the document.
    Confirm that all aspects of the document requiring IANA assignments are
    associated with the appropriate reservations in IANA registries. Confirm
    that any referenced IANA registries have been clearly identified. Confirm
    that each newly created IANA registry specifies its initial contents,
    allocations procedures, and a reasonable name (see [RFC 8126][11]).

To be completed.

21. List any new IANA registries that require Designated Expert Review for
    future allocations. Are the instructions to the Designated Expert clear?
    Please include suggestions of designated experts, if appropriate.

There are four registry created by this I-D and all require DEs. Section
17.5 includes text for the DEs. Note that this text is based on the DE
text in RFC 8447.

[1]: https://www.ietf.org/about/groups/iesg/
[2]: https://www.rfc-editor.org/rfc/rfc4858.html
[3]: https://www.rfc-editor.org/rfc/rfc7942.html
[4]: https://trac.ietf.org/trac/ops/wiki/yang-review-tools
[5]: https://www.rfc-editor.org/rfc/rfc8342.html
[6]: https://trac.ietf.org/trac/iesg/wiki/ExpertTopics
[7]: https://www.rfc-editor.org/info/bcp79
[8]: https://www.ietf.org/tools/idnits/
[9]: https://www.rfc-editor.org/rfc/rfc3967.html
[10]: https://www.rfc-editor.org/info/bcp97
[11]: https://www.rfc-editor.org/rfc/rfc8126.html
[12]: https://www.rfc-editor.org/rfc/rfc2026.html#section-5
[13]: https://www.rfc-editor.org/rfc/rfc2026.html#section-4.1
[14]: https://www.rfc-editor.org/rfc/rfc2026.html#section-4.2
[15]: https://authors.ietf.org/en/content-guidelines-overview
[16]: https://www.ietf.org/about/groups/iesg/statements/normative-informative-references/
[17]: https://datatracker.ietf.org/doc/downref/

# Document Shepherd Write-Up for Group Documents

## Document History

1. Does the working group (WG) consensus represent the strong concurrence of a
  few individuals, with others being silent, or did it reach broad agreement?

The WG reach broad agreement. MLS is not the biggest WG, but there were enough
WG that were active participants during its development that agreed the I-D
was ready to proceed down the road to satisfy both chairs. Additionally, some
of WG participants are also part of the security research community and the
chair did not want to progress this I-D until we heard from enough of them
to make the chairs comfortable that analysis has completed.

2. Was there controversy about particular points, or were there decisions where
  the consensus was particularly rough?

Surprisingly, no. There was lots of back and forth as well as some frustration,
but generally speaking this development of this I-D was what I hope happens
for most I-Ds.

3. Has anyone threatened an appeal or otherwise indicated extreme discontent? If
  so, please summarize the areas of conflict in separate email messages to the
  responsible Area Director. (It should be in a separate email because this
  questionnaire is publicly available.)

No.

4. For protocol documents, are there existing implementations of the contents of
  the document? Have a significant number of potential implementers indicated
  plans to implement? Are any existing implementations reported somewhere,
  either in the document itself (as [RFC 7942][3] recommends) or elsewhere
  (where)?

There are existing implementations; by my count 4 (possibly 5). One of these
is an open source project.

We have a github implementation repo that can be found at:
https://github.com/mlswg/mls-implementations

## Additional Reviews

5. Do the contents of this document closely interact with technologies in other
  IETF working groups or external organizations, and would it therefore benefit
  from their review? Have those reviews occurred? If yes, describe which
  reviews took place.

MLS was intentionally written to be independent of the application layer. See
draft-ietf-mls-architecture for more information.

6. Describe how the document meets any required formal expert review criteria,
  such as the MIB Doctor, YANG Doctor, media type, and URI type reviews.

MLS uses the TLS presentation language. There is no formal expert review
criteria for the TLS presentation language.

7. If the document contains a YANG module, has the final version of the module
  been checked with any of the [recommended validation tools][4] for syntax and
  formatting validation? If there are any resulting errors or warnings, what is
  the justification for not fixing them at this time? Does the YANG module
  comply with the Network Management Datastore Architecture (NMDA) as specified
  in [RFC 8342][5]?

N/A

8. Describe reviews and automated checks performed to validate sections of the
  final version of the document written in a formal language, such as XML code,
  BNF rules, MIB definitions, CBOR's CDDL, etc.

N/A

## Document Shepherd Checks

9. Based on the shepherd's review of the document, is it their opinion that this
  document is needed, clearly written, complete, correctly designed, and ready
  to be handed off to the responsible Area Director?

Yes.

10. Several IETF Areas have assembled [lists of common issues that their
    reviewers encounter][6]. For which areas have such issues been identified
    and addressed? For which does this still need to happen in subsequent
    reviews?

After reviewing the list, it is not clear that most of the common issues apply
to this particular I-D. Remember, that there is also a companion archiecture
draft: draft-ietf-mls-architecture.

11. What type of RFC publication is being requested on the IETF stream ([Best
    Current Practice][12], [Proposed Standard, Internet Standard][13],
    [Informational, Experimental or Historic][14])? Why is this the proper type
    of RFC? Do all Datatracker state attributes correctly reflect this intent?

This I-D intended for PS. PS is the proper status for this on-the-wire protocol.
Yes the datatracker state attributes correctly reflect this intent.

12. Have reasonable efforts been made to remind all authors of the intellectual
    property rights (IPR) disclosure obligations described in [BCP 79][8]? To
    the best of your knowledge, have all required disclosures been filed? If
    not, explain why. If yes, summarize any relevant discussion, including links
    to publicly-available messages when applicable.

Yes, I have personally verify that the 5 authors

13. Has each author, editor, and contributor shown their willingness to be
    listed as such? If the total number of authors and editors on the front page
    is greater than five, please provide a justification.

Yes, I have personally verified that all authors are willing to be listed as such.

14. Document any remaining I-D nits in this document. Simply running the [idnits
    tool][8] is not enough; please review the ["Content Guidelines" on
    authors.ietf.org][15]. (Also note that the current idnits tool generates
    some incorrect warnings; a rewrite is underway.)

Lots of nits about lines too long. These seem to relate to the figures; SVG FTW.

Complaints about non-ascii text. These relate to authors' names.

There are two warnings releated to references:

Outdated reference: draft-ietf-mls-architecture will likely always be out of
synch or the reference to this I-D in draft-ietf-mls-architecture to this I-D
will be out of synch.

Obsolete informational reference: RFC 7540 - this draft references HTTP/2 so
7540 is the correct reference. Also, review the text and you will note leaving
this alone is fine, i.e., the I-D does not need to update the reference to HTTP/3.

15. Should any informative references be normative or vice-versa? See the [IESG
    Statement on Normative and Informative References][16].

I think the references are fine.

16. List any normative references that are not freely available to anyone. Did
    the community have sufficient access to review any such normative
    references?

All normative references are to RFCs.

17. Are there any normative downward references (see [RFC 3967][9] and [BCP
    97][10]) that are not already listed in the [DOWNREF registry][17]? If so,
    list them.

No.

18. Are there normative references to documents that are not ready to be
    submitted to the IESG for publication or are otherwise in an unclear state?
    If so, what is the plan for their completion?

No.

19. Will publication of this document change the status of any existing RFCs? If
    so, does the Datatracker metadata correctly reflect this and are those RFCs
    listed on the title page, in the abstract, and discussed in the
    introduction? If not, explain why and point to the part of the document
    where the relationship of this document to these other RFCs is discussed.

No.

20. Describe the document shepherd's review of the IANA considerations section,
    especially with regard to its consistency with the body of the document.
    Confirm that all aspects of the document requiring IANA assignments are
    associated with the appropriate reservations in IANA registries. Confirm
    that any referenced IANA registries have been clearly identified. Confirm
    that each newly created IANA registry specifies its initial contents,
    allocations procedures, and a reasonable name (see [RFC 8126][11]).

To be completed.

21. List any new IANA registries that require Designated Expert Review for
    future allocations. Are the instructions to the Designated Expert clear?
    Please include suggestions of designated experts, if appropriate.

There are four registry created by this I-D and all require DEs. Section
17.5 includes text for the DEs. Note that this text is based on the DE
text in RFC 8447.

[1]: https://www.ietf.org/about/groups/iesg/
[2]: https://www.rfc-editor.org/rfc/rfc4858.html
[3]: https://www.rfc-editor.org/rfc/rfc7942.html
[4]: https://trac.ietf.org/trac/ops/wiki/yang-review-tools
[5]: https://www.rfc-editor.org/rfc/rfc8342.html
[6]: https://trac.ietf.org/trac/iesg/wiki/ExpertTopics
[7]: https://www.rfc-editor.org/info/bcp79
[8]: https://www.ietf.org/tools/idnits/
[9]: https://www.rfc-editor.org/rfc/rfc3967.html
[10]: https://www.rfc-editor.org/info/bcp97
[11]: https://www.rfc-editor.org/rfc/rfc8126.html
[12]: https://www.rfc-editor.org/rfc/rfc2026.html#section-5
[13]: https://www.rfc-editor.org/rfc/rfc2026.html#section-4.1
[14]: https://www.rfc-editor.org/rfc/rfc2026.html#section-4.2
[15]: https://authors.ietf.org/en/content-guidelines-overview
[16]: https://www.ietf.org/about/groups/iesg/statements/normative-informative-references/
[17]: https://datatracker.ietf.org/doc/downref/

Notification list changed to benjamin.beurdouche@ens.fr, karthikeyan.bhargavan@inria.fr, cas.cremers@cs.ox.ac.uk, alan@wire.com, singuva@twitter.com, kwonal@mit.edu, ekr@rtfm.com, thyla.van.der@merwe.tech, sean@sn3rd.com from benjamin.beurdouche@ens.fr, karthikeyan.bhargavan@inria.fr, cas.cremers@cs.ox.ac.uk, alan@wire.com, singuva@twitter.com, kwonal@mit.edu, ekr@rtfm.com, thyla.van.der@merwe.tech because the document shepherd was set

This is the 2nd WGLC for this I-D. A number of issues were raised during the WGLC and after. We held 4 virtual interim meetings to quickly work through these. As of 16 July 2022 @ 1240, we are back again to no issues (and no comments that I am aware of) and no outstanding pull requests.

Request for posting confirmation emailed to previous authors: Benjamin Beurdouche , Emad Omara , Jon Millican , Katriel Cohn-Gordon , Raphael Robert , Richard Barnes , mls-chairs@ietf.org

Notification list changed to benjamin.beurdouche@ens.fr, karthikeyan.bhargavan@inria.fr, cas.cremers@cs.ox.ac.uk, alan@wire.com, singuva@twitter.com, kwonal@mit.edu, ekr@rtfm.com, thyla.van.der@merwe.tech from Benjamin Beurdouche <benjamin.beurdouche@ens.fr>, Karthikeyan Bhargavan <karthikeyan.bhargavan@inria.fr>, Cas Cremers <cas.cremers@cs.ox.ac.uk>, Alan Duric <alan@wire.com>, Srinivas Inguva <singuva@twitter.com>, Albert Kwon <kwonal@mit.edu>

Notification list changed to Benjamin Beurdouche <benjamin.beurdouche@ens.fr>, Karthikeyan Bhargavan <karthikeyan.bhargavan@inria.fr>, Cas Cremers <cas.cremers@cs.ox.ac.uk>, Alan Duric <alan@wire.com>, Srinivas Inguva <singuva@twitter.com>, Albert Kwon <kwonal@mit.edu>