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

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

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:
>
> 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]
>
> _______________________________________________
> Audio/Video Transport Core Maintenance
> [e-mail]
> https://www.ietf.org/mailman/listinfo/avt

-- 
Gunnar Hellström
GHAccess
[e-mail]