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

[Christer Holmberg <[e-mail]>]

Hi Lars,

Thank You for the review! Please see inline.

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

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

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

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 :)

----

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

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

I will add a comma.

---

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

I will add a comma.

---

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

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

---

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.

I will change "less" to "fewer".

---

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

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.

---

>These URLs point to tools.ietf.org, which is being deprecated:
> * 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