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

[Gunnar Hellström <[e-mail]>]

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:
> 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 
> <[e-mail] <mailto:[e-mail]>> 
> 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,
>
>     Den 2021-04-08 kl. 06:45, skrev Murray S. Kucherawy:
>>     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.
>     [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....."
>
>
>>
>>     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.
>
>     [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
>
>
>>     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?
>     [GH] Agreed, in this case SHALL is right.
>>
>>     Section 11, second paragraph: "restricted of privacy reasons"
>>     should 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."
>>
>>     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.)
>
>     [GH] Done
>
>
>     Thanks,
>
>     Gunnar
>
>
>>     -MSK
>>
>>
>>     _______________________________________________
>>     Audio/Video Transport Core Maintenance
>>     [e-mail]  <mailto:[e-mail]>
>>     https://www.ietf.org/mailman/listinfo/avt  <https://www.ietf.org/mailman/listinfo/avt>
>
>     -- 
>     Gunnar Hellström
>     GHAccess
>     [e-mail]  <mailto:[e-mail]>
>
-- 
Gunnar Hellström
GHAccess
[e-mail]