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

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

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 
> <[e-mail] <mailto:[e-mail]>> 
> wrote:
>
>     -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?
>
> It appears to be common to just include normative references to RFC 
> 8174 and RFC 2119.
>
>     -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.
>
> 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".
>
>     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.
>
>
> 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

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