Subject: [AVTCORE] AD review of draft-ietf-avtcore-multi-party-rtt-mix

From: "Murray S. Kucherawy" <[email-masked]>
Date: Wed, 7 Apr 2021 21:45:08 -0700

Hello friends, sorry for the delay getting this review done.

I think this is generally in good shape, though I admit my understanding of
WebRTC isn't as strong as I'd like.  My review is therefore mostly about
form rather than substance.

At any rate, I have the following comments to offer after a first review.
Please let me know what you think.

--

The Abstract is unusually long.  I would suggest reducing it to a paragraph
or two, or maybe three.  My lay opinion is that the first two paragraphs
could be left for the Introduction section, but other approaches are also
probably available.

In many places, references look odd (e.g., "RFC3550[RFC3550]").  This may
be an artifact of the way the XML generates the text or HTML forms but it
might be worth a quick review to get it to look right.

In Section 1.1, please use the new BCP 14 boilerplate (combining RFC 2119
and RFC 8174).  Also in that section, "as defined in" should be "are
defined in".

In Section 1.3, "where a calltaker want to take" should use "wants" instead
of "want".

Is the "SHOULD" in Section 2.2 a piece of interoperability advice, or is it
advice about presentation?

In Sections 2.4, 3.20, and 7, in multiple places, "sdp" should be in all
caps.

In Section 3.2, remove "being".

Section 3.4 has a bunch of "SHOULD" and "RECOMMENDED" that are not
explained.  See comment below about Section 8 for my thinking here.  This
continues throughout the rest of Section 3's subsections and much of
Section 4.

In Section 3.20, "this sections shows" should be "this section shows".

In Section 4.2.6, "these facts makes" should be "these facts make".

Section 8 has a bare "SHOULD", by which I mean advice is given with no
context.  "SHOULD" and "RECOMMENDED" present a choice; why might an
implementer legitimately decide not to follow this advice?  If there's no
good reason, should these be "SHALL"/"MUST" instead?

Section 11, second paragraph: "restricted of privacy reasons" should
probably be "restricted for privacy reasons".

Section 11, third paragraph: "masquerading" should be "masquerade".

Section 11 should also probably refer to Section 3.19.

Commonly, a "Changes" section (Section 12 here) is marked with a note like:

    [RFC Editor: Please remove this section prior to publication.]

(At least I presume that's the intent for this section as well.)

-MSK

---

From: Gunnar Hellström <[email-masked]>
Date: Thu, 8 Apr 2021 23:18:23 +0200

Hello Murray,

Thanks for the review,

I have answered and acted on all but the SHOULD and RECOMMENDED etc. in 
sections 3.4 -4. The response on them will be provided soon.

See answers inline,

Den 2021-04-08 kl. 06:45, skrev Murray S. Kucherawy:
> I think this is generally in good shape, though I admit my 
> understanding of WebRTC isn't as strong as I'd like.  My review is 
> therefore mostly about form rather than substance.
>
> At any rate, I have the following comments to offer after a first 
> review.  Please let me know what you think.
>
> --
>
> The Abstract is unusually long.  I would suggest reducing it to a 
> paragraph or two, or maybe three.  My lay opinion is that the first 
> two paragraphs could be left for the Introduction section, but other 
> approaches are also probably available.
[GH] Moved one paragraph to the intro, deleted another because it had 
similar wording in the intro.
>
> In many places, references look odd (e.g., "RFC3550[RFC3550]").  This 
> may be an artifact of the way the XML generates the text or HTML forms 
> but it might be worth a quick review to get it to look right.
[GH]Done
>
> In Section 1.1, please use the new BCP 14 boilerplate (combining RFC 
> 2119 and RFC 8174).  Also in that section, "as defined in" should be 
> "are defined in".
[GH]Done
>
> In Section 1.3, "where a calltaker want to take" should use "wants" 
> instead of "want".
[GH]Done
>
> Is the "SHOULD" in Section 2.2 a piece of interoperability advice, or 
> is it advice about presentation?

[GH] Intended to be for interoperability.   I suggest to insert wording 
to result in:

SHOULD *in order to maintain interoperability,* if nothing else is 
specified for the application, format transmitted text to that 
participant....

>
> In Sections 2.4, 3.20, and 7, in multiple places, "sdp" should be in 
> all caps.
[GH] Done
> In Section 3.2, remove "being".

[GH] Would it be even more clear to replace "being" with "is" ?

    "As soon as a participant is known to participate in a session with
    another entity and is available for text reception, a Unicode BOM
    character SHALL be sent to it....."

> explained.  See comment below about Section 8 for my thinking here.  
> This continues throughout the rest of Section 3's subsections and much 
> of Section 4.

[GH] For 3.4, the explanation is at the end of the section: "The 
intention is to keep the latency low and network load limited while 
keeping a good protection against text loss in bursty packet loss 
conditions."

But that is a summary explanation. I can insert explanations for each 
timing figure in the section.

I stop handling this comment here for now and will return to it soon 
with another response..

> In Section 3.20, "this sections shows" should be "this section shows".
[GH] Done
> In Section 4.2.6, "these facts makes" should be "these facts make".
[GH] Done

> implementer legitimately decide not to follow this advice?  If there's 
> no good reason, should these be "SHALL"/"MUST" instead?
[GH] Agreed, in this case SHALL is right.
> probably be "restricted for privacy reasons".
[GH] Done
> Section 11, third paragraph: "masquerading" should be "masquerade".
[GH] Done
> Section 11 should also probably refer to Section 3.19.
[GH] A reference added last in 11: "Further security considerations 
specific for this application are specified in section 3.19."
> (At least I presume that's the intent for this section as well.)

[GH] Done

Thanks,

Gunnar

> -MSK
>
>
> _______________________________________________
> Audio/Video Transport Core Maintenance
> [email-masked]
> https://www.ietf.org/mailman/listinfo/avt

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

---

From: "Murray S. Kucherawy" <[email-masked]>
Date: Thu, 8 Apr 2021 14:31:53 -0700

Hi Gunnar,

All of this looks good, thank you!

If you post a new version with those changes (you may have already; I
haven't checked), I'm comfortable sending the Last Call now.  We can sort
out specific text for the SHOULDs, etc., along the way; the various
reviewers might have suggestions on that topic, and maybe we can do some of
this in parallel.

-MSK

On Thu, Apr 8, 2021 at 2:18 PM Gunnar Hellström <
[email-masked]> wrote:

> I think this is generally in good shape, though I admit my understanding
> of WebRTC isn't as strong as I'd like.  My review is therefore mostly about
> paragraph or two, or maybe three.  My lay opinion is that the first two
> paragraphs could be left for the Introduction section, but other approaches
> are also probably available.
>
> Is the "SHOULD" in Section 2.2 a piece of interoperability advice, or is
> it advice about presentation?
>
> [GH] Intended to be for interoperability.   I suggest to insert wording to
> result in:
>
> [GH] For 3.4, the explanation is at the end of the section: "The intention
> is to keep the latency low and network load limited while keeping a good
> protection against text loss in bursty packet loss conditions."
>
> I stop handling this comment here for now and will return to it soon with
> another response..
>
>
> Audio/Video Transport Core [email-masked]://www.ietf.org/mailman/listinfo/avt
>
> --
> Gunnar Hellström
> [email-masked]
>
>

---

From: Gunnar Hellström <[email-masked]>
Date: Fri, 9 Apr 2021 11:47:19 +0200

Hi Murray,

A couple of questions before I produce next version:

-On including RFC8174 in a group reference to BCP 14:

I think RFC 8174 is a good clarification for use of "SHOULD" and 
"should" etc., but I failed to create the proper reference to BCP 14 in 
xml for xml2rfc v.3.
There are various instructions and examples available, but I cannot make 
them work in practice.
Temporarily I copied the way that draft-ietf-avtcore-rtp-vvc-08 handles 
it, by just mentioning BCP 14 in text in the boilerplate and not include 
it in the reference list.
Do you know a good xml template for the BCP 14 boilerplate?

-On review of SHOULD etc. in sections 3 and 4.

Do you mean that I shall review the use of the RFC 2119 words in 
sections 3 and 4 and judge if I can use the SHALL/MUST wording, and if I 
want to keep SHOULD, then insert advice for decision of when to follow 
the advice.

A possibility is to have SHOULD only in the introduction in 4.2 and then 
SHALL in the rest of 4.2.x because it is only applicable for 
implementations selecting to implement the procedures introduced in 4.2.

The current wording in 4.2 is:

"4.2.  Multi-party mixing for multi-party unaware endpoints

    When the mixer has indicated RTT multi-party capability in an SDP
    negotiation, but the multi-party capability negotiation fails with an
    endpoint, then the agreed "text/red" or "text/t140" format SHALL be
    used and the mixer SHOULD compose a best-effort presentation of
    multi-party real-time text in one stream intended to be presented by
    an endpoint with no multi-party awareness."

Could it be sufficient to use SHALL in most places in all 4.2.x sections 
and change the beginning of 4.2 to:

"4.2.  Multi-party mixing for multi-party unaware endpoints

    When the mixer has indicated RTT multi-party capability in an SDP
    negotiation, but the multi-party capability negotiation fails with an
    endpoint, then the agreed "text/red" or "text/t140" format SHALL be
    used and the mixer SHOULD compose a best-effort presentation of
    multi-party real-time text in one stream intended to be presented by
    an endpoint with no multi-party awareness,*when that is desired in 
the actual implementation. The following specifies a procedure for that 
situation"*

- and then mainly use SHALL in the rest of section 4.2.

?

Regards

Gunnar

Den 2021-04-08 kl. 23:31, skrev Murray S. Kucherawy:
> haven't checked), I'm comfortable sending the Last Call now.  We can 
> sort out specific text for the SHOULDs, etc., along the way; the 
> various reviewers might have suggestions on that topic, and maybe we 
> can do some of this in parallel.
>
> -MSK
>
> On Thu, Apr 8, 2021 at 2:18 PM Gunnar Hellström 
> <[email-masked] <mailto:[email-masked]>> 
> wrote:
>
>     Hello Murray,
>
>     Thanks for the review,
>
>     I have answered and acted on all but the SHOULD and RECOMMENDED
>     etc. in sections 3.4 -4. The response on them will be provided soon.
>
>     See answers inline,
>
>>     understanding of WebRTC isn't as strong as I'd like.  My review
>>     is therefore mostly about form rather than substance.
>>
>>     paragraph or two, or maybe three.  My lay opinion is that the
>>     first two paragraphs could be left for the Introduction section,
>>     but other approaches are also probably available.
>     [GH] Moved one paragraph to the intro, deleted another because it
>     had similar wording in the intro.
>>
>>     In many places, references look odd (e.g., "RFC3550[RFC3550]"). 
>>     This may be an artifact of the way the XML generates the text or
>>     HTML forms but it might be worth a quick review to get it to look
>>     right.
>     [GH]Done
>>
>>     In Section 1.1, please use the new BCP 14 boilerplate (combining
>>     RFC 2119 and RFC 8174).  Also in that section, "as defined in"
>>     should be "are defined in".
>     [GH]Done
>>
>>     In Section 1.3, "where a calltaker want to take" should use
>>     "wants" instead of "want".
>     [GH]Done
>>
>>     Is the "SHOULD" in Section 2.2 a piece of interoperability
>>     advice, or is it advice about presentation?
>
>     [GH] Intended to be for interoperability.   I suggest to insert
>     wording to result in:
>
>>     In Sections 2.4, 3.20, and 7, in multiple places, "sdp" should be
>>     in all caps.
>     [GH] Done
>>
>>     Section 3.4 has a bunch of "SHOULD" and "RECOMMENDED" that are
>>     not explained.  See comment below about Section 8 for my thinking
>>     here.  This continues throughout the rest of Section 3's
>>     subsections and much of Section 4.
>
>     intention is to keep the latency low and network load limited
>     while keeping a good protection against text loss in bursty packet
>     loss conditions."
>
>     But that is a summary explanation. I can insert explanations for
>     each timing figure in the section.
>
>     I stop handling this comment here for now and will return to it
>     soon with another response..
>
>>
>>     Section 8 has a bare "SHOULD", by which I mean advice is given
>>     with no context.  "SHOULD" and "RECOMMENDED" present a choice;
>>     why might an implementer legitimately decide not to follow this
>>     advice?  If there's no good reason, should these be
>>     "SHALL"/"MUST" instead?
>>     Section 11, second paragraph: "restricted of privacy reasons"
>>     should probably be "restricted for privacy reasons".
>     [GH] Done
>>
>     [GH] A reference added last in 11: "Further security
>     considerations specific for this application are specified in
>     section 3.19."
>>
>>     [email-masked]  <mailto:[email-masked]>
>>     https://www.ietf.org/mailman/listinfo/avt  <https://www.ietf.org/mailman/listinfo/avt>
>
>     -- 
>     Gunnar Hellström
>     GHAccess
>     [email-masked]  <mailto:[email-masked]>
>

---

From: Gunnar Hellström <[email-masked]>
Date: Fri, 9 Apr 2021 23:39:11 +0200

Hi Murray,

I have prepared changes from many SHOULD to SHALL in sections 3 and 4, 
and some SHOULD remaining but with explanations.

So, I am ready to submit, just waiting to see if I get any hint on 
suitable xml for the BCP 14 reference.

Thanks,

Gunnar

Den 2021-04-09 kl. 11:47, skrev Gunnar Hellström:
> "should" etc., but I failed to create the proper reference to BCP 14 
> in xml for xml2rfc v.3.
> There are various instructions and examples available, but I cannot 
> make them work in practice.
> Temporarily I copied the way that draft-ietf-avtcore-rtp-vvc-08 
> handles it, by just mentioning BCP 14 in text in the boilerplate and 
> not include it in the reference list.
> sections 3 and 4 and judge if I can use the SHALL/MUST wording, and if 
> I want to keep SHOULD, then insert advice for decision of when to 
> follow the advice.
>
> A possibility is to have SHOULD only in the introduction in 4.2 and 
> then SHALL in the rest of 4.2.x because it is only applicable for 
> Could it be sufficient to use SHALL in most places in all 4.2.x 
> sections and change the beginning of 4.2 to:
>
> the actual implementation. The following specifies a procedure for 
> that situation"*
>
>>>     At any rate, I have the following comments to offer after a
>>>     first review.  Please let me know what you think.
>>>
>>>     --
>>>
>>>     The Abstract is unusually long.  I would suggest reducing it to
>>>     a paragraph or two, or maybe three. My lay opinion is that the
>>>     HTML forms but it might be worth a quick review to get it to
>>>     look right.
>>     [GH]Done
>>>
>>     SHOULD *in order to maintain interoperability,* if nothing else
>>     is specified for the application, format transmitted text to that
>>     participant....
>>
>>
>>>
>>>     In Sections 2.4, 3.20, and 7, in multiple places, "sdp" should
>>>     be in all caps.
>>     [GH] Done
>>>
>>>     not explained.  See comment below about Section 8 for my
>>>     thinking here.  This continues throughout the rest of Section
>>>     3's subsections and much of Section 4.
>>
>>     while keeping a good protection against text loss in bursty
>>     packet loss conditions."
>>

---

From: "Murray S. Kucherawy" <[email-masked]>
Date: Fri, 9 Apr 2021 15:26:05 -0700

On Fri, Apr 9, 2021 at 2:47 AM Gunnar Hellström <
[email-masked]> wrote:

> I think RFC 8174 is a good clarification for use of "SHOULD" and "should"
> etc., but I failed to create the proper reference to BCP 14 in xml for
> xml2rfc v.3.
> it, by just mentioning BCP 14 in text in the boilerplate and not include it
> in the reference list.
It appears to be common to just include normative references to RFC 8174
and RFC 2119.

> Do you mean that I shall review the use of the RFC 2119 words in sections
> 3 and 4 and judge if I can use the SHALL/MUST wording, and if I want to
> keep SHOULD, then insert advice for decision of when to follow the advice.
>
Generally I believe SHOULD provides an implementer with a choice.  Clearly
that choice is weighted (unlike MAY), but still when the reader is left
with a choice but doesn't know how to make it, the document may actually be
making things worse.  Thus my advice is to say something of the form "you
SHOULD do X, unless Y".

>    an endpoint with no multi-party awareness,* when that is desired in

Yes, that's a definite improvement.  The other alternative is to avoid the
ambiguous use of SHOULD, such as:

"When the mixer has indicated RTT multi-party capability in an SDP
negotiation, but the multi-party capability negotiation fails with an
endpoint, then the agreed "text/red" or "text/140" format SHALL be used and
the mixer will then typically compose a best-effort presentation of
multi-party real-time text in one stream intended to be presented by an
endpoint with no multi-party awareness."

Here you would avoid use of SHOULD altogether, which is something to
consider if the thing you're describing has nothing to do with
interoperability between components anyway.

-MSK

---

From: Gunnar Hellström <[email-masked]>
Date: Sun, 11 Apr 2021 23:09:35 +0200

A new version is available at

https://datatracker.ietf.org/doc/draft-ietf-avtcore-multi-party-rtt-mix/

It is intended to fulfill all review comments.

Section 4.2 with all SHOULDs has to do with interoperability between components. Most SHOULDs are now changed to SHALL. The reason to have SHOULD before, was that the section is about achieving interoperability with currently installed implementations, and in some future or in controlled environments there may be no such legacy devices and implementation of 4.2 should therefore be optional. That is now indicated in the leading paragraph of 4.2, and the rest can therefore be SHALLs.

Some places in section 3, where SHOULD and RECOMMENDED were used without motivation of alternatives or assignment of specific figures, are now changed either to SHALL or to include motivations.

Thanks

Gunnar

Den 2021-04-10 kl. 00:26, skrev Murray S. Kucherawy:
> On Fri, Apr 9, 2021 at 2:47 AM Gunnar Hellström 
>     "should" etc., but I failed to create the proper reference to BCP
>     14 in xml for xml2rfc v.3.
>     There are various instructions and examples available, but I
>     cannot make them work in practice.
>     handles it, by just mentioning BCP 14 in text in the boilerplate
>     and not include it in the reference list.
> It appears to be common to just include normative references to RFC 
> 8174 and RFC 2119.
>
>     sections 3 and 4 and judge if I can use the SHALL/MUST wording,
>     and if I want to keep SHOULD, then insert advice for decision of
>     when to follow the advice.
>
>     A possibility is to have SHOULD only in the introduction in 4.2
>     and then SHALL in the rest of 4.2.x because it is only applicable
>     for implementations selecting to implement the procedures
>     introduced in 4.2.
>
> Generally I believe SHOULD provides an implementer with a choice.  
> Clearly that choice is weighted (unlike MAY), but still when the 
> reader is left with a choice but doesn't know how to make it, the 
> document may actually be making things worse.  Thus my advice is to 
> say something of the form "you SHOULD do X, unless Y".
>
>        an endpoint with no multi-party awareness,*when that is desired
>     in the actual implementation. The following specifies a procedure
>     for that situation"*
>
> Yes, that's a definite improvement.  The other alternative is to avoid 
> the ambiguous use of SHOULD, such as:
>
> endpoint, then the agreed "text/red" or "text/140" format SHALL be 
> used and the mixer will then typically compose a best-effort 
> presentation of multi-party real-time text in one stream intended to 
> be presented by an endpoint with no multi-party awareness."
>