Re: [AVTCORE] Éric Vyncke's No Objection on draft-ietf-avtcore-cc-feedback-message-08: (with COMMENT)

> On 22 Sep 2020, at 08:43, Éric Vyncke via Datatracker <noreply@ietf.org> wrote:
> 
> Éric Vyncke has entered the following ballot position for
> draft-ietf-avtcore-cc-feedback-message-08: 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/iesg/statement/discuss-criteria.html
> for more information about IESG DISCUSS and COMMENT positions.
> 
> 
> The document, along with other ballot positions, can be found here:
> https://datatracker.ietf.org/doc/draft-ietf-avtcore-cc-feedback-message/
> 
> 
> 
> ----------------------------------------------------------------------
> COMMENT:
> ----------------------------------------------------------------------
> 
> Thank you for the work put into this document.
> 
> Please find below a couple of non-blocking COMMENT points and nits.
> 
> I hope that this helps to improve the document,
> 
> Regards,
> 
> -éric
> 
> == COMMENTS ==
> 
> -- Section 3.1 --
> In "but overlapping reports MAY be sent (and need to be sent in cases" should
> the "need" be a "MUST” ?

Overlapping need to be sent to retrospectively correct the loss reports when reordering occurs across the boundary between reports. Aside from a (slightly) incorrect loss rate estimate nothing will break if the overlapping report isn’t sent. As such, I think “MUST” is too strong.

> -- Section 5 --
> In "then the sender SHOULD rapidly reduce", "sender" is somehow ambiguous: is
> it the feedback transmitter or the media source sender ?

Media sender. Will fix.

> -- Section 6 --
> The mandatory use of "*" appears strange to the non-SDP expert (like myself).
> Why transmitting something that is always identical? What is the value ?

RFC 4585 requires this syntax to indicate the feedback applies to all payload types used in the session.

> == NITS ==
> -- Section 3.1 --
> As some reader may also wonder like me, why the use of 'L' (at least I am
> puzzled)? why not giving one word mnemonic to explain the logic behind this
> choice ?

Renamed to R (Received)

> -- Section 7 --
> Is there a typo in ""a=ecn-capaable-rtp:"” ?

Fixed.

> it is probably redundant to again expand ECN.
> 
> 
> 
> _______________________________________________
> Audio/Video Transport Core Maintenance
> avt@ietf.org
> https://www.ietf.org/mailman/listinfo/avt

-- 
Colin Perkins
https://csperkins.org/