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

From: Lars Eggert via Datatracker <[email-masked]>
Date: Tue, 24 Aug 2021 05:50:58 -0700

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

---

From: Christer Holmberg <[email-masked]>
Date: Thu, 26 Aug 2021 17:33:49 +0000

Hi Lars,

Thank You for the review! Please see inline.

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

Do we normally do that?

For example, the only reason RFC 3261 references RFC 2543 is to point out some terminology that has been removed.

>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://protect2.fireeye.com/v1/url?k=1684323e-491f0b3c-168472a5-869a14f4b08c-9166e0a50422ec93&q=1&e=29a83f3a-f874-4b85-bea5-a4b1e41da
>8c1&u=https%3A%2F%2Fgithub.com%2Flarseggert%2Fietf-reviewtool), so there will likely be some false positives. There is no need to let me know what you did with these suggestions.

>The adverb "always" usually goes after the verb "be".

English is not my first language, but "to be always able to" sounds weird to me.

But, if someone tells me it is the correct grammar I have no problem changing it :)

----

> ons can implement RTP stacks in many different ways. The algorithm below deta

I could replace "in many different ways" with "in a number of different ways", or simply with "in different ways".

---

Section 9.1.1. , paragraph 7, nit:
>Use a comma before "and" if it connects two independent clauses (unless they are closely connected and short).

I will add a comma.

---

Section 9.1.1. , paragraph 9, nit:
>Use a comma before "and" if it connects two independent clauses (unless they are closely connected and short).

I will add a comma.

---

> s, flows over the network, with the exception of the usage of the MID SDES i

So, "network, except for the usage of the MID SDES"?

---

>Did you mean "fewer"? The noun bytes is countable.

I will change "less" to "fewer".

---

----

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

Yes. This is due to the decision that all Cluster 238 document would reference RFC 4566. And, while this document technically is not part of that cluster, I think the decision still applies.

---

> * https://tools.ietf.org/html/draft-ietf-avtext-lrr-07

The reference is used in Section 9.2., in the following sentence:

"Layer Refresh Request (LRR):  (PT=PSFB, FMT=10) [LLR-RTCP]."

Has it been replaced with something else? If not, as the reference is information, I assume we can just remove it, and the sentence where it is used.

---

Regards,

Christer

---

From: Benjamin Kaduk <[email-masked]>
Date: Tue, 31 Aug 2021 13:27:35 -0700

Hi Christer,

Just some mundane bits, inline...

> But, if someone tells me it is the correct grammar I have no problem changing it :)

Your intuition is correct; no change is needed here.

> Has it been replaced with something else? If not, as the reference is information, I assume we can just remove it, and the sentence where it is used.

The datatracker will replace the tools site; following the link even now
redirects to https://datatracker.ietf.org/doc/html/draft-ietf-avtext-lrr-07
which is expected to remain stable.

-Ben