[AVTCORE] AD review: draft-ietf-avtcore-feedback-suppression-rtp-13

[Robert Sparks <[e-mail]>]

Summary: There are some clarifications needed (and some questions to 
discuss) before forwarding this to IETF LC.

1) Section 3, paragraph 3, says a receiver MUST follow the rules for 
NACK suppression on receipt of a third partly loss report. Section 4 
says receivers MAY ignore third party lost reports, and then confusingly 
says the SHOULD not ignore them. The security considerations section 
says that receivers would be "well advised to ignore" (effectively 
SHOULD ignore) third party reports unless they are authenticated. This 
needs to be reconciled.

Are you trying to say the following?

    *) MUST follow the suppression rules if packets are authenticated
    *) SHOULD NOT follow the suppression rules if the packets are not 
authenticated

Or something else? Either way, please make the document internally 
consistent.

2) Why aren't RFC3711 and RFC5124 normative references? They're the only 
offered tools for authenticating these messages in the document. Even if 
other mechanisms might exist, there needs to be discussion somewhere of 
what's required of this authentication, and the security consideration 
sections of those documents would suffice.

3) The first part of the IANA considerations section is not clear. Is 
this trying to create a new registry with two initial values, or add two 
values to an existing registry. If it's creating a new one, please 
provide a registry name, and suggest where it should appear.

4) The security considerations section speaks about attacks based on 
spurious reports, but doesn't really discuss more directed attacks. In 
particular, if a receiver accepts unauthenticated feedback suppression 
messages, an attacker could cause packetloss disrupting an important 
part of a session, preemptively sending feedback suppression. An 
attacker that is also a receiver has enough information to suppress 
_all_ feedback from any other listeners that don't unauthenticated 
packets. Please make it clearer that these risks exist.

5) At the end of section 3, the document says messages SHOULD be 
suppressed "for a period of time". Can that be made more precise?

Editorial suggestions:

Please expand acronyms on first use (There are a _lot_ of acronyms, many 
of which need references to where they are defined. Consider adding a 
glossary so you can get that out of the way without interrupting the 
flow of the text).

The protocol definition part of this document (section 4) is a bit of a 
puzzle for a new reader. It would help to guide the reader through the 
definition more directly. Here's a suggested modification - feel free to 
ignore it:

Before section 4.1 say "The following two sections each define a third 
party loss report message. Both messages are feedback messages as 
defined in section 6.1 of RFC4585, and use the header format defined 
there. Each section defines how to populate the PT, FMT, length, SSRC or 
packet sender, SSRC of media source, and FCI fields in that header."

That will make it more obvious to the reader that they need to go look 
at the referenced section in 4585 right away, and makes it possible to 
simplify the text in 4.1 and 4.2. 4.1 can state clearly and early that 
it is defining the TLLEI, etc.

Whether you choose to act on this suggestion or not, please change the 
TBDs to TBD1 and TBD2, and say "length field in the" instead of "length 
of" when talking about setting the length field in each message.

Nits sent directly to editors.