[AVTCORE] Comments on draft-ietf-avtcore-rfc5285bis-03

[Magnus Westerlund <[e-mail]>]

Hi,

I did a review to see if this was ready for WG last call. I have found 
some issues that needs to be addressed prior to the WG last call.

1. Abstract:
The abstract is not explicit that this document obsoletes RFC5285.

2. Section 1:
"   This document removes a limitation from RFC5285 that did not allow
    sending both one byte and two bytes header extensions in the same RTP
    stream".

This needs to say explicitly that is obsoletes RFC5285. When it comes to 
the changes, this is clearly the major one, but it is not the only one. 
I think the document should have a more explicit list of the changes 
compared to RFC5285. I would actually recommend that a new section is 
created that discusses the changes related to RFC 5285. This will not be 
super long, but I think when you summarize the changes there are 
actually a couple of paragraphs.

3. Section 4.1.1:

some general considerations for getting the header extensions
    delivered to the receiver:

Should the "some" not be "Some"?

4. Section 4.1.2:

Since it is expected that (a) the number of extensions in
    any given RTP session is small and (b) the extensions themselves are
    small, the one-byte header form is preferred and MUST be supported by
    all receivers.

I know this would be an updated requirement, but shouldn't we clarify 
the implementation requirements to actually include both one and two 
byte headers for receivers, if following this version of the 
specification? The usage of switching is still only after having 
successfully negotiated support for it.

5. Section 4.1.2:

One-byte and two-byte headers MUST NOT be mixed in a
    single RTP packet.

As this is not possible as the one and two byte headers for the RTP 
header extension are different and only one of them can be present in a 
given RTP packet. I fear that this sentence causes confusion and are 
interpreted such that the extensions with IDs assigned in 1-14 range 
can't be used in two-byte header when such signaled. I think this 
sentence to be rewritten so that it says: Each RTP packet with an RTP 
header extension following this specification will indicate if it 
contains one or two byte header extensions through the use of the 
"defined by profile" field. Only the extension element types that match 
the header extension format, i.e. one- or two-byte, MUST be used in that 
RTP packet.

6. Section 4:

I think this section, possibly in 4.3 needs to be more explicit that 
header extensions that are configured using value 1-14 and thus supports 
the one-byte header format, can equally be used in the two-byte header. 
And in this case they use the same code-point values. I.e. there is not 
two different ID spaces (0-256, 15 reserved, and 0 is padding), only one.

7. Section 5:

and <direction> is one of
    "sendonly", "recvonly", "sendrecv", or "inactive" (without the
    quotes).

My interpretation of the above is that this applies in relation to the 
endpoint being configured. However, that could be made more clear as 
this is basically the declarative rules.

8. Section 6:
    When doing SDP Offer/Answer [RFC3264] an offering client that wishes
    to use both one and two bytes extensions MUST include the attribute
    "a= extmap-allow-mixed " in the SDP offer.

The above text fails to define that it applies to using both formats 
with an individual RTP stream. To my understanding if one would fail to 
negotiate this SDP attribute, but can negotiate both ID in the range 
1-14 and in 16-256 then one can on an RTP stream basis select which 
format one will persistently use for that SSRC. I wonder if that should 
be made clear also?

9. Section 7:

A "sendonly" direction
    indicates an ability to send; a "recvonly" direction indicates a
    desire to receive; a "sendrecv" direction indicates both.  An
    "inactive" direction indicates neither, but later re-negotiation MAY
    make an extension active.

I think this text should be removed and replaced with a pointer to the 
definitions in RFC 3264 as it fails to take into account how the 
directions are interpreted in relation to ones role for creating or 
receiving the SDP message.

10. Section 9:

I think the security consideration could point out that there exist 
alternative protection mechanisms as discussed in RFC 7201 that also can 
provide confidentiality for RTP header extensions.

11. Section 9:

This section is actually quite bad at raising the issues with the 
mechanisms it creates. First of all it is important that the signaling 
is protecting the negotiation to prevent blocking use of the extensions, 
or in some case even enabling extensions that has known vulnerabilities. 
Thus indicating need for integrity and source authentication.

On the RTP plane the header extension mechanism is vulnerable to denial 
of service attacks through modification of the RTP header extension 
structure. Possible force an alternative interpretation of data as well 
as data modifications.

12. Section 10.1:

       2.  that the extension complies with the requirements of RTP and
           this specification, for extensions (notably, that the stream
           is still decodable if the extension is ignored or not
           recognized);

I believe there is need to tweak this bullet.

13. Section 10.2:

I would recommend that you update this section to use the template for 
the information for the SDP attribute (as 10.3 uses), so that 10.2 and 
10.3 looks similar. I note that the registry for the existing attribute 
should actually be updated to point at the new RFC when completed. This 
should be indicated also.

14. Section 12.2:
This section lacks the following RFCs: 3611, 4585, 4588, 5109. All are 
mentioned in the text, but all lacks a reference.

Cheers

Magnus Westerlund

----------------------------------------------------------------------
Services, Media and Network features, Ericsson Research EAB/TXM
----------------------------------------------------------------------
Ericsson AB                 | Phone  [phone]
Färögatan 6                 | Mobile [phone]
SE-164 80 Stockholm, Sweden | mailto: [e-mail]
----------------------------------------------------------------------