Address follow-up comments from RFC Editor

[bifurcation]

We spotted a typo in Section 8.1 where there is a line break missing:

Current:

• Change Controller: Who is authorized to update the row in the registry
  Initial contents:

Should be fixed now.

7. [rfced] Section 4.4.2. The following line exceeds the
   72-character limit. Please let us know how this line can be modified.

Current:
sframe_salt = HKDF-Expand(sframe_secret, sframe_salt_label, AEAD.Nn)

[JM] Although this line was updated, it is still one char over the limit.

I have updated it so that it should be within the limit.

12. Section 6.1.1. The clause in the following sentence
    appears to be missing a subject: it's unclear what is carrying the media.

Original:
This means that in the same transport-level stream (e.g., an RTP
stream defined by either SSRC or MID) may carry media from different
streams of different participants.

Perhaps (removing the preposition "in" so that "the same transport-level
stream" becomes the subject and expanding "MID"):
This means that the same transport-level stream (e.g., an RTP
stream defined by either SSRC or Media Identification (MID)) may
carry media from different streams of different participants.

[JM] We had expanded MID in the text, so it may have appeared that we
had made the other suggested update. The sentence still needs
clarification, though. Would removing the preposition "in" make it clearer?

Yeah, removing "in" is the right answer.

14. [rfced] IANA Considerations. The text indicates the that
    registration policy for the "SFrame Cipher Suites" is Specification
    Required. However, it later refers to Standards Action and Private Use,
    and the IANA registry includes ranges for Standards Action and Private
    Use. Are the ranges as defined on the IANA page correct? For clarity,
    may we specify the ranges as follows? In addition, perhaps the text
    should be moved to Section 8.1, appearing after the valid range of
    cipher suites is noted.

Original:
This registry should be under a heading of "SFrame", and assignments
are made via the Specification Required policy [RFC8126].

Perhaps:
IANA has created a new registry called "SFrame Cipher Suites"
(Section 8.1) under the "SFrame" group registry heading.
Assignments are made per the following registration procedures
[RFC8126]:

0-0xEFFF  Specification Required
0-0xEFFF  Standards Action
0xF000-0xFFFF  Private Use

[JM] Please let us know if the ranges on the IANA page are correct and
if the ranges for registration procedures should also be specified in
the document. IANA would like the text in the IANA Considerations
section to align closely with the information in the registry
https://www.iana.org/assignments/sframe/.

We don't need to state this twice. (And the "Perhaps" text here doesn't even make sense; there are two policies for the same range.) I moved this sentence into the registry definition section, and added "Except as noted below...". In any case, the instructions on the IANA web page for the registry are correct.

20. Please review the "Inclusive Language" portion of the
    online Style Guide
    https://www.rfc-editor.org/styleguide/part2/#inclusive_language and
    let us know if any changes are needed. For example, please consider
    whether the following should be updated: whitespace

[JM] Perhaps using "spaces" in the following?

Current:
Line breaks and whitespace within values are inserted to conform to
the width requirements of the RFC format.

Considered and rejected. The "white" here is literal and value-neutral; it literally refers to the color of paper.