Re: [rmcat] Alvaro Retana's No Objection on draft-ietf-rmcat-rtp-cc-feedback-11: (with COMMENT)

[Zaheduzzaman Sarker <[e-mail]>]

I didn't really read the RFC cited as normative, but I would not object if they are moved as normative to make things easier for implementers.

//Zahed

> On 19 Oct 2022, at 00:15, Colin Perkins <[e-mail]> wrote:
> 
> Hi,
> 
> The entire draft is informational guidance, so I wasn’t convinced anything in here is normative. That said, in the sense that you need to understand the material to be able to read the draft, I don’t disagree. I can move the references, if the IESG thinks it would be appropriate.
> 
> Colin
> 
> 
> 
> On 17 Oct 2022, at 21:39, Alvaro Retana via Datatracker wrote:
> 
>> Alvaro Retana has entered the following ballot position for
>> draft-ietf-rmcat-rtp-cc-feedback-11: No Objection
>> 
>> When responding, please keep the subject line intact and reply to all
>> email addresses included in the To and CC lines. (Feel free to cut this
>> introductory paragraph, however.)
>> 
>> 
>> Please refer to https://www.ietf.org/about/groups/iesg/statements/handling-ballot-positions/
>> for more information about how to handle DISCUSS and COMMENT positions.
>> 
>> 
>> The document, along with other ballot positions, can be found here:
>> https://datatracker.ietf.org/doc/draft-ietf-rmcat-rtp-cc-feedback/
>> 
>> 
>> 
>> ----------------------------------------------------------------------
>> COMMENT:
>> ----------------------------------------------------------------------
>> 
>> It caught my attention that this document has no Normative references, which
>> are documents "that must be read to understand...the technology in the new RFC"
>> [1].
>> 
>> In this case, it looks like most of the RFCs cited in the Introduction should
>> be Normative:
>> 
>>   The deployment of WebRTC systems [RFC8825] has resulted in high-
>>   quality video conferencing seeing extremely wide use.  ...
>> 
>>   To develop such congestion control, it is necessary to understand the
>>   sort of congestion feedback that can be provided within the framework
>>   of RTP [RFC3550] and the RTP Control Protocol (RTCP).  It then
>>   becomes possible to determine if this is sufficient for congestion
>>   control, or if some form of RTP extension is needed.
>> 
>>   This memo considers unicast congestion feedback that can be sent
>>   using RTCP under the RTP/SAVPF profile [RFC5124] (the secure version
>>   of the RTP/AVPF profile [RFC4585]).  This profile was chosen as it
>>   forms the basis for media transport in WebRTC [RFC8834] systems.
>>   Nothing in this memo is specific to the secure version of the
>>   profile, or to WebRTC, however.  It is also assumed that the
>>   congestion control feedback mechanism described in [RFC8888], and
>>   common RTCP extensions for efficient feedback [RFC5506], [RFC8108],
>>   [RFC8861], and [RFC8872] are used.
>> 
>> [1]
>> https://www.ietf.org/about/groups/iesg/statements/normative-informative-references/