Subject: [AVTCORE] AD Review: draft-ietf-avtcore-srtp-encrypted-header-ext-03

From: Robert Sparks <[email-masked]>
Date: Thu, 03 Jan 2013 13:18:45 -0600

Summary: There is one issue to adjust with a revised ID before 
proceeding to IETF LC.

(Based on a brief voice conversation with Jonathan Lennox)

The ABNF in Figure 3 is recursive as written. It allows productions like

a=extmap:1 urn:ietf:params:rtp-hdrext:encrypt 
urn:ietf:params:rtp-hdrext:toffset 
urn:ietf:params:rtp-hdrext:ssrc-audio-level
and worse
a=extmap:1 urn:ietf:params:rtp-hdrext:encrypt 
urn:ietf:params:rtp-hdrext:toffset token1 token 2 
urn:ietf:params:rtp-hdrext:ssrc-audio-level

etc.

I suggest to avoid this instead extend the rule for extmap in RFC5285 
(please explicitly call out that's where to look for the base
definition of extmap, extensionname, and extensionattributes) as follows:

extmap /= mapentry SP "urn:ietf:params:rtp-hdrext:encrypt" extensionname 
[SP extensionattributes]

Jonathan notes that RFC5234's quoted-strings are by definition case 
insensitive. If extensionnames are intended to be case-sensitive
(RFC5285 is silent on that point), the quoted string above would need to 
be replaced with hex expansions for the individual characters:

 >>> [hex(ord(ch)) for ch in list('urn:ietf:params:rtp-hdrext:encrypt')]
['0x75', '0x72', '0x6e', '0x3a', '0x69', '0x65', '0x74', '0x66', '0x3a', 
'0x70', '0x61', '0x72', '0x61', '0x6d', '0x73', '0x3a', '0x72', '0x74', 
'0x70', '0x2d', '0x68', '0x64', '0x72', '0x65', '0x78', '0x74', '0x3a', 
'0x65', '0x6e', '0x63', '0x72', '0x79', '0x70', '0x74']

Nits:

In the abstract, I suggest s/require that all SRTP/require that all 
future SRTP/

Introduction, 1st paragraph, s/using of the Real-Time/using the Real-Time/

---

From: Jonathan Lennox <[email-masked]>
Date: Thu, 3 Jan 2013 15:05:44 -0500

Hello, all --

I've submitted a revised version -04 of the draft, fixing the ABNF syntax and Robert's other nits.

I've proceeded on the assumption that RFC 5285's extensionname values are indeed case-sensitive, so in the new version of the draft I've written out the extensionname value in hex in the ABNF syntax.

This case-sentivity question is probably an issue that should be explicitly defined somewhere.  Is this something that's in scope of the Errata process, or would it need to be addressed in an update to RFC 5285?

(Regardless, I don't think the encrypted-header-ext draft would be the right place to fix it.)

On Jan 3, 2013, at 2:18 PM, Robert Sparks wrote:

> Summary: There is one issue to adjust with a revised ID before proceeding to IETF LC.
> 
> a=extmap:1 urn:ietf:params:rtp-hdrext:encrypt urn:ietf:params:rtp-hdrext:toffset urn:ietf:params:rtp-hdrext:ssrc-audio-level
> and worse
> a=extmap:1 urn:ietf:params:rtp-hdrext:encrypt urn:ietf:params:rtp-hdrext:toffset token1 token 2 urn:ietf:params:rtp-hdrext:ssrc-audio-level
> 
> etc.
> 
> I suggest to avoid this instead extend the rule for extmap in RFC5285 (please explicitly call out that's where to look for the base
> extmap /= mapentry SP "urn:ietf:params:rtp-hdrext:encrypt" extensionname [SP extensionattributes]
> 
> Jonathan notes that RFC5234's quoted-strings are by definition case insensitive. If extensionnames are intended to be case-sensitive
> (RFC5285 is silent on that point), the quoted string above would need to be replaced with hex expansions for the individual characters:
> 
> ['0x75', '0x72', '0x6e', '0x3a', '0x69', '0x65', '0x74', '0x66', '0x3a', '0x70', '0x61', '0x72', '0x61', '0x6d', '0x73', '0x3a', '0x72', '0x74', '0x70', '0x2d', '0x68', '0x64', '0x72', '0x65', '0x78', '0x74', '0x3a', '0x65', '0x6e', '0x63', '0x72', '0x79', '0x70', '0x74']
> 
> 
> Nits:
> 
> In the abstract, I suggest s/require that all SRTP/require that all future SRTP/
> 
> _______________________________________________
> Audio/Video Transport Core Maintenance
> [email-masked]
> https://www.ietf.org/mailman/listinfo/avt

--
Jonathan Lennox
[email-masked]