Subject: [Last-Call] Genart last call review of draft-ietf-avtcore-multi-party-rtt-mix-14

From: Peter Yee via Datatracker <[email-masked]>
Date: Wed, 05 May 2021 20:41:51 -0700

Reviewer: Peter Yee
Review result: Ready with Issues

I am the assigned Gen-ART reviewer for this draft. The General Area
Review Team (Gen-ART) reviews all IETF documents being processed
by the IESG for the IETF Chair.  Please treat these comments just
like any other last call comments.

For more information, please see the FAQ at

<https://trac.ietf.org/trac/gen/wiki/GenArtfaq>.

Document: draft-ietf-avtcore-multi-party-rtt-mix-14
Reviewer: Peter Yee
Review Date: 2021-05-05
IETF LC End Date: 2021-05-03
IESG Telechat date: Not scheduled for a telechat

Summary: This draft specifies updates to RFC 4103 to allow real-time text
mixing for both multiparty-aware and multiparty-unaware participants. It has
some minor issues that should be addressed before publication. [Ready with
issues]

Major issues: None

Minor issues:

Page 7, 1st block, 13th sentence: what constitutes a “reasonable effort”? It
might be best to drop this sentence.

Page 7, 2nd block, 2nd sentence, “300 ms”: would it make sense to append
“period” or “timeout” after this value?

Page 13, section 3.4, 2nd paragraph, 1st sentence: in regards to “only part”,
how is this calculated?

Page 15, section 3.12, 2nd paragraph, 1st sentence: The placing of all
available redundant levels in the packet is presumably subject to a maximum
packet size or the “CPS” limit, if there are obnoxious levels of redundancy
specified?

Page 17, section 3.17.2, 4th paragraph, 2nd sentence: “SHALL prefer” seems odd.
It doesn’t say that the marking will actually be done. It’s just preferred. If
you’re not going to require the marking in that sentence, then perhaps change
“SHALL” to “SHOULD”.

Page 19, section 3.20, 2nd paragraph, 2nd sentence: I don’t find the “something
specific” particularly enlightening. Like what? An identifier for the method?

Page 27, section 4.2.2, 4th paragraph: can you elaborate on these “Integrity
considerations”? Otherwise, it’s difficult to comply with the SHALL in any
meaningful way.

Page 33, 3rd paragraph, 1st sentence: any reason for the change from “T.140” in
the previous and following paragraphs to “t140” in this one?

Page 33, 6th paragraph: how is disappearance determined?

Page 35, section 11, 3rd paragraph, 2nd sentence before creating a new sentence
(see nits, below): I’m having troubles tying the adjective “secure” to each of
the nouns in the sentence. It works for “signaling” and perhaps “media”, but
for “authentication”, one sort of assumes that authentication mechanism is
secure and helping to provide the security. Perhaps you could reword that
sentence?

Nits/editorial comments:

General:
Change “multi-party” to “multiparty” throughout the document. While we are a
bit inconsistent about that particular hyphenation within the IETF, all major
dictionaries I sampled spell this as a single, non-hyphenated word.

Append a comma after each instance of “e.g.”.

Change “multiparty aware” to “multiparty-aware” throughout the document except
in two cases where you “multiparty awareness”, which should be left alone.
These are located in section 4.2, 1st paragraph, 1st sentence and section 6.1,
2nd paragraph, 2nd sentence.

Change “fall-back” to “fallback” in a few places in the document. Both uses are
found in the document.

Change “RTP-mixer based” to “RTP-mixer-based” throughout the document.

Change “multiparty capable” to “multiparty-capable” throughout the document.

Delete periods at the end of section/subsection titles, e.g., section 6.2.

Specific:

Page 1, Abstract, 1st sentence: I’d rewrite it in the active voice as: “This
document provides enhancements for RFC 4103 real-time text mixing suitable for
a centralized conference model that enables source identification and rapidly
interleaved transmission of text from different sources.”

Page 1, Abstract, 3rd paragraph, 1st sentence: insert a hyphen between
“multiparty” and “coded”.

Page 5, 3rd paragraph, 1st sentence: I think I would change “in” to “at”.

Page 5, 7th paragraph, 3rd sentence: delete “any”. Change “way” to “ways”.

Page 6, section 1.1, 2nd paragraph: insert “are” before “as”.

Page 6, section 1.1, “WebRTC” term: change “web based” to “web-based”. Insert
“real-time” before “communication”.

Page 6, “DTLS-SRTP” term: delete “stands for security”. Insert “is a DTLS
extension for use with SRTP/SRTCP” before “specified”.

Page 6, “multiparty-aware” term: change “stands for” to “describes”. Append a
comma after “real-time” before “separated”. Append a comma after “source”.

Page 6, “multiparty-unaware”: change “stands for” to “describes”.

Pages 7 and 8: delete the period after each of the non-indented lines, e.g., at
the end of “Multiple RTP streams, one per participant.”

Page 7, 1st block, 4th sentence: change “end to end” to “end-to-end”.

Page 7, 1st block, 11th sentence: append a comma after “participant”. Delete
the following “and”. Insert “with” before “no”.

Page 7, 1st block, 14th sentence: change “implementation” to “implementations”
and delete “technologies” unless you really want the problem is in regards to
technologies and not particular implementations.

Page 7, 1st block 15th sentence: change “made” to “led to”. Insert “being”
before “only”.

Page 7, 2nd block, 1st sentence: insert “a” before “shorter”. Insert “the”
before source”. Insert “the” before “CSRC”. Append field after “CSRC”.

Page 7, 2nd block, 2nd sentence: insert “a” before the quoted “text/t140”.

Page 7, 2nd block, 3rd sentence: delete the whole sentence.

Page 7, 2nd block, 6th sentence: move “with” before “receivers”. Insert “having
the” before “default”.

Page 8, 1st partial block, 2nd full sentence: insert “it” before “corresponds”.

Page 8, 1st full block, 6th sentence: change “be varying” to “vary”.

Page 8, 1st full block, 9th sentence: change “while” to “When”.

Page 9, section 1.3, 1st paragraph, 3rd sentence: change “calltaker” to “call
taker”. Change “observing” to “to observe”.

Page 11, section 2.4, 3rd paragraph: append a comma after “CSRC-list”.

Page 12, section 3.1, 4th paragraph: change “From other aspects” to “In other
regards”.

Page 13, section 3.4, 1st paragraph, 3rd sentence: insert a hyphen between “10”
and “second”.

Page 13, section 3.4, 1st paragraph, 4th sentence: delete “a” before “good”.

Page 13, section 3.4, 2nd paragraph, 1st sentence: insert “SHALL be” before
“sent”. Insert “the” before “end”.

Page 13, section 3.4, 2nd paragraph, 2nd sentence: Append a period at the end
of the sentence.

Page 13, section 3.4, 3rd paragraph: change “in” to “as”.

Page 13, section 3.6: insert a hyphen between “locally” and “produced”. Append
“text” after “produced”.

Page 14, 1st paragraph, 3rd sentence: delete the comma after “T140blocks”.

Page 14, section 3.10, 1st paragraph after the bullet points, 1st sentence:
insert “the” before “time”.

Page 15, section 3.11, 2nd paragraph: append a comma after “switch”. Change
“poulated” to “populated”.

Page 15, section 3.12, 1st paragraph, 1st sentence: insert “the” before “next”.

Page 15, section 3.12, 1st paragraph, 2nd sentence: insert “the” before “next”.

Page 15, section 3.12, 2nd paragraph, 2nd sentence: change “number” to “level”.

Page 16, section 3.14, 1st paragraph, 1st sentence: delete an extraneous space
after “(“.

Page 16, section 3.14, 1st paragraph, last sentence: insert “self-sourced”
before “data”. Delete “that it is source of itself”.

Page 16, section 3.16, 1st paragraph, 1st sentence: append a comma after
“CNAME”.

Page 17, section 3.17.2, 1st paragraph, 1st sentence: insert “The receiver
SHALL monitor”. Change “The” to “the”. Delete “SHALL be monitored”.

Page 17, section 3.17.2, 2nd paragraph, 2nd sentence: append a comma after
“case”. Insert “the receiver SHALL create” before “a t140block”. Delete “SHALL
be created”. I’m suggesting but not certain that you might want to change “and
assigned” to “associated with”.

Page 17, section 3.17.2, 4th paragraph, 1st sentence: change “if” to “whether”
if you are amenable to that wording.

Page 18, 2nd paragraph: delete an extraneous blank line before this paragraph.

Page 18, section 3.18, 1st sentence: insert a hyphen between “10” and “second”.

Page 19, section 3.19, 1st sentence: insert “the” before “session”. Insert
“the” before “media”.

Page 19, section 3.19, 2nd sentence: insert “the” before “media”. Consider
deleting “security by”.

Page 19, section 3.19, 5th sentence: change “is” to “are”.

Page 20, section 3.21, 4th sentence: append a period after “etc”.

Page 21, 1st partial paragraph, 1st full sentence: insert “a” before “dropped”.

Page 21, 1st full paragraph, 1st sentence: delete an extraneous space after
“(“. Where the word “area” occurs, would that make more sense as “buffer” or
“queue”?

Page 21, 1st full paragraph, 2nd sentence: insert “initial” before the first
“text”.

Page 22, 1st paragraph, 2nd sentence: change “in” to “due to”.

Page 22, 2nd paragraph, 1st sentence: insert “packets” before “103”. Delete the
comma after “103”.

Page 22, 2nd paragraph, 2nd sentence: there appears to be an adverb missing
before “the”. Perhaps “during”?

Page 22, 3rd paragraph, 2nd sentence: change “21040” to “21060”.

Page 22, 4th paragraph, 1st sentence: change “needs” to “need”.

Page 22, 4th paragraph, 2nd sentence: change “21150” to “21160”.

Page 23, section 4, 1st paragraph, 2nd sentence: delete “and”.

Page 23, section 4, 3rd paragraph: consider changing “of” before “the text” to
“conveyed in”.

Page 24, 1st full paragraph, 3rd sentence: insert “a” before “replacement”.

Page 24, 1st full paragraph, 4th sentence: change “just” to “the same”.

Page 26, section 4.2, 3rd paragraph, 2nd sentence: insert a hyphen between
“best” and “effort”.

Page 26, section 4.2, 4th paragraph, 1st sentence: append a comma after
“simulated”.

Page 26, section 4.2, 4th paragraph, 4th sentence: change “is depending” to
“depends”.

Page 26, section 4.2, 4th paragraph, 5th sentence: change “switch” to
“switching”. Append a comma after “can”. Append a comma after “example”.

Page 26, section 4.2.1, 3rd sentence: append a comma after “keep-alive”.

Page 27, 5th bullet point: insert “the” before “next”. Change “if even” to
“even if”. Insert “a” between “for” and “word delimiter”.

Page 28, section 4.2.4, 1st paragraph: insert “the” before “UTF-8”. Change
“transform” to “transformation”.

Page 28, section 4.2.4, “BEL”: change the comma after “session” to a period.
Capitalize “provides”.

Page 28, section 4.2.4, “NEW LINE”, 3rd sentence: insert “the” before “display”.

Page 28, section 4.2.4, “CR LF”, 1st sentence: delete the comma after
“supported”.

Page 28, section 4.2.4, “CR LF”, 3rd sentence: insert “the” before “display”.

Page 28, section 4.2.4, “INT ESC”, 1st sentence: insert “the” before “mode”.

Page 28, section 4.2.4, “SGR”, 2nd sentence: insert “the” before “rendition”.

Page 29, 1st partial sentence: insert a hyphen between “256” and “bytes”. Then
change “bytes” to “byte”.

Page 29, “BOM”, 1st sentence: insert “it” before “SHALL”.

Page 29, “Missing text mark”, 1st sentence: change the comma after “apostrophe
‘” to a period. Insert “It” before “marks”. Insert “the” before “place”. Insert
“the” before “stream”.

Page 29, “SGR”, 1st sentence: delete the comma after “(SGR)”. Insert “the”
before “status”.

Page 29, “SGR”, 2nd sentence: change “originated” to “originating”.

Page 29, BS, last sentence: change “not” to “be”.

Page 32, section 6.1, title: drop the “e.g.” in the subsection title.

Page 32, section 6.1, 2nd paragraph, parenthetical: perhaps you want “i.e.,”
instead of “e.g.” here given that further down you put “TTYS” in another
parenthetical as though it weren’t just an example but the only exemplar of
this type of device under discussion.

Page 32, section 6.1, 2nd paragraph, last sentence: delete “make”. Change
“adaptions” to “adapt”. Delete “for” before “the functional”. Delete “(TTY)”.

Page 32, section 6.1, 3rd paragraph: delete “(TTYs)”.

Page 33, 2nd paragraph, 2nd sentence: insert “a” before “two-way”.

Page 33, 3rd paragraph, 2nd sentence: insert “the” before “NAME”.

Page 33, section 7: insert a hyphen between “multiparty” and “mixing” in this
one instance of that term. Other uses of the term in the document should not be
hyphenated.

Page 34, section 8, 1st paragraph: I like the sound of the sentence better if
you swap “valid” and “also”. That’s just me. 

Page 34, section 8, 3rd paragraph, 1st sentence: insert a space between
“second” and “(“CPS”)”.

Page 34, section 8, 3rd paragraph, 3rd sentence: insert “an” before “RTP”.
Regarding “excess”: in excess of what?

Page 35, section 11, 1st paragraph, 1st sentence: append a comma after “pack”.

Page 35, section 11, 2nd paragraph, 1st sentence: append a comma after “CNAME”.

Page 35, section 11, 3rd paragraph, 1st sentence: I suggest inserting
“emitting” before “a continuous”. Change the comma after “flow of text” to a
period. Delete the following “or”. Change the rest of that sentence to read
something like: “They may also send text that appears to originate from other
participants.” I rewrote that because the malicious participants don’t
themselves masquerade as text, although that might be a mildly amusing
Halloween costume.

Page 35, section 11, 4th paragraph: delete one of “section” or “Section”. You
capitalize that term interchangeably, so it’s your choice.

Page 35, section 12.1 (when discussing -14 only): change “Cucherawy” to
“Kucherawy” unless we’re talking about someone else. Yeah, I know these will
all be deleted upon publication, but it caught my eye. I have not reviewed the
remainder of the change history entries.

---

From: Gunnar Hellström <[email-masked]>
Date: Thu, 6 May 2021 23:14:06 +0200

Thank you for the thorough review. Please see comments inline.

I will split the answers, and start here with answers and change 
proposals for the minor issues:

> might be best to drop this sentence.

[GH] This reason is important for the desicion on technology selection.

I suggest a change from:

"For best deployment opportunity, it should be possible to upgrade 
existing endpoint solutions to be multi-party aware with a reasonable 
effort."

to

"For best deployment opportunity, it should be feasible to upgrade 
existing endpoint solutions to become multiparty-aware."

> “period” or “timeout” after this value?

[GH] I suggest to change from "every 300 ms." to "with 300 ms intervals."

> Page 13, section 3.4, 2nd paragraph, 1st sentence: in regards to “only part”,

[GH] I suggest to change from "If the "CPS" value is reached, longer 
transmission intervals SHALL be applied and only part of the text queued 
for transmission sent at end of each transmission interval, until the 
transmission rate falls under the "CPS" value again."

to

"If the "CPS" value is reached, longer transmission intervals SHALL be 
applied and only as much of the text queued for transmission sent at end 
of each transmission interval that can be allowed without exceeding the 
"CPS" value, until the transmission rate falls under the "CPS" value 
again. Division of text for partial transmission MUST then be made at 
T140block borders. "

> packet size or the “CPS” limit, if there are obnoxious levels of redundancy

[GH] Thanks, a good observation. It is already covered in section 3.10, 
but it could be more emphasized there. In 3.12 we are only dealing with 
the redundancy, which must be possible to send and is not included in 
the "CPS" value.

I suggest that the following part of 3.10 is improved from:

"Redundant text SHALL also be included.  See Section 3.12"

to;
"Redundant text SHALL also be included, and the assessment of how much 
new text can be included within the maximum packet size MUST take into 
account that the redundancy has priority to be transmitted in its 
entirety.  See Section 3.12."

> you’re not going to require the marking in that sentence, then perhaps change
[GH] Agreed. Done as proposed.
> specific” particularly enlightening. Like what? An identifier for the method?

[GH] Proposed to be changed from:

" In that case, the
    SDP of the offer will include something specific for that method, and
    an answer acknowledging the use of that method would accept it by
    something specific included in the SDP."

to:

"In that case, the
    SDP of the offer will include something specific for that method, 
e.g. an SDP attribute or another media format. An answer selecting the 
use of that method would accept it by
    a corresponding acknowledgement included in the SDP."

> considerations”? Otherwise, it’s difficult to comply with the SHALL in any

[GH] The sentence was inserted after discussions with emergency service 
providers, who had an example that it would be valuable to have a 
detailed personalized label of an emergency service agent shown to other 
agents while a less personal label should be used when sent to the 
calling users in emergency.

The security aspects on the label are quite similar to the security 
aspects on the <display-text> elements specified in RFC 4575. Its 
security aspects are specified in 
https://tools.ietf.org/html/rfc4575#section-8

You are right that that example contains mainly SHOULD and RECOMMENDED 
and no SHALL.

I suggest changing:

"Integrity considerations SHALL be taken when composing the label."

to:

"Information available to the mixer for composing the label may contain 
sensitive personal information that SHOULD not be revealed in sessions 
not securely authenticated and protected. Integrity considerations 
regarding how much personal information is included in the label SHOULD 
therefore be taken when composing the label."

> the previous and following paragraphs to “t140” in this one?
[GH] No, they should be "T.140 data channels" for all cases in that 
paragraph.
I have changed.
> Page 33, 6th paragraph: how is disappearance determined?
[GH]The disappearance may be signaled by the SIP conference system RFC 
4353, RFC 4575 etc. as a conference notification if that system is used, 
or simply by removal of the text media in an RTP session modification. 
There may also be a malfunction detected by keep-alive transactions not 
being maintained. I suggest to not detail how it disappears.
> secure and helping to provide the security. Perhaps you could reword that

[GH] I propose to change the sentence from:

"Counteractions should be to require
    secure signaling, media and authentication, and to provide higher
    level conference functions e.g. for blocking and expelling
    participants."

to:

"Counteractions should be to require authentication, secure session 
signaling and secure media. Higher level conference functions should 
also be used e.g., for blocking and expelling participants who caused 
security concerns."

Thanks,

Gunnar Hellstrom

-- 
Gunnar Hellström
GHAccess
[email-masked]

---

From: Gunnar Hellström <[email-masked]>
Date: Fri, 7 May 2021 20:35:51 +0200

Continuing with comments and edit proposals from "Nits/editorial 
comments:" below.

> some minor issues that should be addressed before publication. [Ready with
[GH] Covered in a recent response.
> dictionaries I sampled spell this as a single, non-hyphenated word.
[GH] Accepted and done.
> Append a comma after each instance of “e.g.”.
[GH] Accepted and done.
> 2nd paragraph, 2nd sentence.
[GH] Accepted and done.
> Change “fall-back” to “fallback” in a few places in the document. Both uses are
[GH] Accepted and done.
> Change “RTP-mixer based” to “RTP-mixer-based” throughout the document.
[GH] Accepted and done.
> Change “multiparty capable” to “multiparty-capable” throughout the document.
[GH] I suggest to change to "multiparty-aware" instead for consistency.
> Delete periods at the end of section/subsection titles, e.g., section 6.2.
[GH] Accepted and done.
> interleaved transmission of text from different sources.”
[GH] Accepted and done.
> “multiparty” and “coded”.
[GH] Accepted and done.
> Page 5, 3rd paragraph, 1st sentence: I think I would change “in” to “at”.
[GH] Accepted and done.
> Page 5, 7th paragraph, 3rd sentence: delete “any”. Change “way” to “ways”.
[GH] Accepted and done.
> Page 6, section 1.1, 2nd paragraph: insert “are” before “as”.
[GH] Recently changed to just "are defined in" by proposal in another 
review. I suggest to keep that.
> “real-time” before “communication”.
[GH] Accepted and done.
> extension for use with SRTP/SRTCP” before “specified”.
[GH] Accepted and done.
> comma after “real-time” before “separated”. Append a comma after “source”.
[GH] Accepted and done.
> Page 6, “multiparty-unaware”: change “stands for” to “describes”.
[GH] Accepted and done.Your use of hyphen in "multiparty-unaware" made 
me understand that that term also should be hyphenated all through the 
document. Done.
> the end of “Multiple RTP streams, one per participant.”
[GH] Accepted and done.
> Page 7, 1st block, 4th sentence: change “end to end” to “end-to-end”.
[GH] Accepted and done. Done also in one more location in 3.19 inserted 
in version -16.
> the following “and”. Insert “with” before “no”.
[GH] Accepted and done.
> technologies and not particular implementations.
[GH] Accepted and done, it looks better this way even if the problem may 
be common in certain implementation technologies.
> Page 7, 1st block 15th sentence: change “made” to “led to”. Insert “being”
[GH] Accepted and done. From here all comments are accepted and done as 
proposed except where a specific answer is provided.
> assigned” to “associated with”.

[GH] Accepted and done, but also "accociated" is changed to "associate 
it" and "inserted" to "insert it" to match the grammar in the beginning 
of the sentence.

> “(“. Where the word “area” occurs, would that make more sense as “buffer” or
[GH] Accepted and done. "area" changed to "buffer" only for this 
occurrance.
> before “the”. Perhaps “during”?
[GH] Accepted and done. "during" used.
> “transform” to “transformation”.
[GH] "Encoding" used instead. It seems commonly used.
> Page 29, “BOM”, 1st sentence: insert “it” before “SHALL”.

[GH] Accepted, but part of the first statement is separated out to a 
sentence of its own: "  It SHALL be deleted from incoming streams."

> Page 32, section 6.1, title: drop the “e.g.” in the subsection title.
[GH] Not done. Many countries have their own terms for textphones. In 
USA and a few other countries (Canada, Australia) they are called TTY. 
That term is not understood in other countries. "Textphone" may not be 
understood in USA. Therefore I prefer having both the general term and 
the (e.g., TTYs) in the heading.
> this type of device under discussion.

[GH] No. I did not mean "i.e.,". "TTY" is just one example with specific 
technology.

So, I suggest to keep this sentence:    "One case that may occur is a 
gateway to PSTN for communication with textphones (e.g., TTYs)."  While 
in the other places where (TTY) was mentioned it is deleted with its 
parenthesis.

> “adaptions” to “adapt”. Delete “for” before “the functional”. Delete “(TTY)”.

[GH] I also needed to insert "to" before "adapt" to make:

"This solution makes it possible to adapt
    to the functional limitations of the textphone."

> you swap “valid” and “also”. That’s just me. 
[GH] Accepted so that you will like to read it again.
> remainder of the change history entries.
Thanks again for the thorough review. I have next version ready, also 
including changed caused by security comments and discussed in other mail.

Do you want me to submit the new version.

Regards

Gunnar

---

From: "Peter Yee" <[email-masked]>
Date: Fri, 7 May 2021 11:55:57 -0700

Thanks for the quick response, Gunnar. I've prefaced my replies below with [PEY].

		-Peter

-----Original Message-----
From: Gunnar Hellström [mailto:[email-masked]] 
Sent: Thursday, May 06, 2021 2:14 PM
To: Peter Yee; [email-masked]
Cc: [email-masked]; [email-masked]; [email-masked]
Subject: Re: Genart last call review of draft-ietf-avtcore-multi-party-rtt-mix-14

I suggest a change from:

to

[PEY] I'm fine with that.

[PEY] Works for me.

to

[PEY] That's clearer. I'd insert "the" before "end".

to;

[PEY] That works.

" In that case, the

to:

"In that case, the

[PEY] That helps. With a comma after the "e.g.". ;-)

I suggest changing:

to:

[PEY] That's much clearer.

[PEY] Okay by me if that's well understood in this ecosystem. The verb disappearance just made it sound somewhat mysterious as opposed to something that can be signaled.

to:

[PEY] Yes, I like that. Along with my usual nit about an Oxford comma after "signaling". And a hyphen between "Higher" and "layer". Sorry, that's just how my eyes/brain work. ;-)

Thanks,

Gunnar Hellstrom

---

From: "Peter Yee" <[email-masked]>
Date: Fri, 7 May 2021 12:14:33 -0700

Responses prefixed with [PEY] below.

		Kind regards,
		-Peter

-----Original Message-----
From: Gunnar Hellström [mailto:[email-masked]] 
Sent: Friday, May 07, 2021 11:36 AM
To: Peter Yee; [email-masked]
Cc: [email-masked]; [email-masked]; [email-masked]
Subject: Re: Genart last call review of draft-ietf-avtcore-multi-party-rtt-mix-14

[PEY] Fine by me.

[PEY] Agreed. 

[PEY] Yes, I failed to include that hyphenation in the general nits although I marked all of them in my review copy.

[PEY] That's fine. I didn't fuss so much over sentence structure for the definitions.

[PEY] With that understanding, I'm fine leaving an examples or two in the body text. As a matter of style, I don't think examples should appear in the title, but I won't argue the point. It's only style. :-)

[PEY] Okay.

[PEY] I'm fine with the that sentence.

[PEY] If you have no further changes pending from other reviews, it probably makes sense to submit a new version with everything incorporated. I admit that I didn't thoroughly check the diffs between -14 and -16 to see if any of my proposed changes clashed.

Regards

Gunnar

---

From: Gunnar Hellström <[email-masked]>
Date: Fri, 7 May 2021 21:42:45 +0200

Peter,

I have made the extra few adjustments you proposed.

For the use of "disappeared", I agree that it is an unusual term in this 
context.

I checked RFC 4575, and there it is said that users "depart" or 
"disconnect" from a conference. "Disconnect" feels most familiar, so I 
propose to change the sentence to:

"When a participant on the RTP side is disconnected from the multiparty 
session, the corresponding T.140 data channel(s) SHOULD be closed."

Thanks,

Gunnar

-- 

Gunnar Hellström

GHAccess

[email-masked]  <mailto:[email-masked]>

---

From: Gunnar Hellström <[email-masked]>
Date: Fri, 7 May 2021 22:14:41 +0200

Version -17 of the draft is submitted, with intention to have all Genart 
and Secdir review comments resolved.

The IETF datatracker status page for this draft is:
https://datatracker.ietf.org/doc/draft-ietf-avtcore-multi-party-rtt-mix/

There is also an HTML version available at:
https://www.ietf.org/archive/id/draft-ietf-avtcore-multi-party-rtt-mix-17.html

A diff from the previous version is available at:
https://www.ietf.org/rfcdiff?url2=draft-ietf-avtcore-multi-party-rtt-mix-17

Regards

Gunnar

---

From: Lars Eggert <[email-masked]>
Date: Mon, 10 May 2021 14:27:22 +0300

Peter, thank you for your review. I have entered a No Objection ballot for this document.

Lars

On 2021-5-6, at 6:41, Peter Yee via Datatracker <[email-masked]> wrote:
> last-call mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/last-call