[MMUSIC] Lars Eggert's No Objection on draft-ietf-mmusic-rfc8843bis-04: (with COMMENT)

Lars Eggert via Datatracker <noreply@ietf.org> Tue, 24 August 2021 12:50 UTC

MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 7bit
From: Lars Eggert via Datatracker <noreply@ietf.org>
To: The IESG <iesg@ietf.org>
Cc: draft-ietf-mmusic-rfc8843bis@ietf.org, mmusic-chairs@ietf.org, mmusic@ietf.org, fandreas@cisco.com, fandreas@cisco.com
Auto-Submitted: auto-generated
Precedence: bulk
Reply-To: Lars Eggert <lars@eggert.org>
Message-ID: <162980945769.10984.17918040042222826113@ietfa.amsl.com>
Date: Tue, 24 Aug 2021 05:50:58 -0700
Archived-At: <https://mailarchive.ietf.org/arch/msg/mmusic/1hSDd4AIG-1asizYa4ejqOqtIwE>
Subject: [MMUSIC] Lars Eggert's No Objection on draft-ietf-mmusic-rfc8843bis-04: (with COMMENT)

Lars Eggert has entered the following ballot position for
draft-ietf-mmusic-rfc8843bis-04: No Objection

When responding, please keep the subject line intact and reply to all
email addresses included in the To and CC lines. (Feel free to cut this
introductory paragraph, however.)


Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html
for more information about DISCUSS and COMMENT positions.


The document, along with other ballot positions, can be found here:
https://datatracker.ietf.org/doc/draft-ietf-mmusic-rfc8843bis/



----------------------------------------------------------------------
COMMENT:
----------------------------------------------------------------------

Document obsoletes RFC8843, but does not cite it as a reference.

-------------------------------------------------------------------------------
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.

Section 9.1. , paragraph 6, nit:
> er for an offerer and answerer to always be able to associate an RTP stream w
>                                   ^^^^^^^^^
The adverb "always" usually goes after the verb "be".

Section 9.1.1. , paragraph 2, nit:
> ons can implement RTP stacks in many different ways. The algorithm below deta
>                                 ^^^^^^^^^^^^^^
Consider using "many".

Section 9.1.1. , paragraph 7, nit:
> n, then the RTP stream is not decoded and the payload data is discarded. * I
>                                      ^^^^
Use a comma before "and" if it connects two independent clauses (unless they
are closely connected and short).

Section 9.1.1. , paragraph 9, nit:
> erwise, the RTP stream is not decoded and the payload data is discarded. * I
>                                      ^^^^
Use a comma before "and" if it connects two independent clauses (unless they
are closely connected and short).

Section 15. , paragraph 4, nit:
> s, flows over the network, with the exception of the usage of the MID SDES i
>                            ^^^^^^^^^^^^^^^^^^^^^
Consider using "except" or "except for".

Section 15. , paragraph 7, nit:
> p counter, and SHOULD be 3 bytes or less to allow them to efficiently fit in
>                                     ^^^^
Did you mean "fewer"? The noun bytes is countable.

Section 19.1. , paragraph 13, nit:
> d in RFC 3605, yet acted this way. Further assume that the B2BUA was configur
>                                    ^^^^^^^
A comma may be missing after the conjunctive/linking adverb "Further".

Obsolete reference to RFC4566, obsoleted by RFC8866 (this may be on purpose).

These URLs point to tools.ietf.org, which is being deprecated:
 * https://tools.ietf.org/html/draft-ietf-avtext-lrr-07

[MMUSIC] Lars Eggert's No Objection on draft-ietf… Lars Eggert via Datatracker
Re: [MMUSIC] Lars Eggert's No Objection on draft-… Christer Holmberg
Re: [MMUSIC] Lars Eggert's No Objection on draft-… Benjamin Kaduk