[apps-discuss] apps-team review of draft-ietf-fecframe-sdp-elements

Dave Cridland <dave@cridland.net> Tue, 07 September 2010 19:33 UTC

MIME-Version: 1.0
Message-Id: <11907.1283888013.974202@puncture>
Date: Tue, 07 Sep 2010 20:33:33 +0100
From: Dave Cridland <dave@cridland.net>
To: General discussion of application-layer protocols <apps-discuss@ietf.org>, The IESG <iesg@ietf.org>, abegen@cisco.com
Content-Type: text/plain; delsp="yes"; charset="iso-8859-1"; format="flowed"
Content-Transfer-Encoding: 8bit
Subject: [apps-discuss] apps-team review of draft-ietf-fecframe-sdp-elements
Precedence: list

Hiya folks,

I have been selected as the Applications Area Review Team reviewer  
for this draft (for background on apps-review, please see  
http://www.apps.ietf.org/content/applications-area-review-team).

Please resolve these comments along with any other Last Call comments  
you may receive. Please wait for direction from your document  
shepherd or AD before posting a new version of the draft.

Document: draft-ietf-fecframe-sdp-elements
Reviewer: Dave Cridland
Review Date: 2010-09-07

Summary: This draft has minor editorial issues, and one potential  
issue. The document could be published as an RFC with the existing  
encoding of repair-window, but some thought should be given to it.

Major Issues: None

Minor Issues:

Section 4.6 describes an SDP attribute "repair-window", which seems  
to have a possibly over-complicated representation. It has two  
different units, one of which is the default. This yields three  
different ways of expressing the same intent:

150
150ms
150000us

It's unclear to me what benefit this brings, and the downside could  
be that implementations only handle a subset of the possibilities,  
resulting in a failure to interoperate.

I would advise serious consideration of restricting this to one unit.  
If microsecond resolutions are required, then obviously this would be  
µs, resulting in the above being written only as:

150000

This is unfortunately not a current option, and if there are existing  
deployments, this may yield further problems.

Nits:

The term "bytes" is sometimes used where I suspect "octets" would be  
more precise.

Security:

I briefly cast my eye over the Security Considerations section -  
please don't grant these comments the same weight as a security  
review.

There is advice that "It is RECOMMENDED [to] follow the security  
considerations of SDP". I would have thought that following those  
recommendations would be a requirement. I'm quite taken with using  
both RECOMMENDED and SHOULD in the same sentence, mind, but I think  
this could be phrased better.

It's also not clear what effect the SDP modification would actually  
have - whether this is a denial of service or if it yields some other  
attack. (My suspicion is that if an attacker is in a position to  
perform this attack, then the attacker can subvert the media streams  
entirely and do something much more interesting).

Dave.
-- 
Dave Cridland - mailto:dave@cridland.net - xmpp:dwd@dave.cridland.net
  - acap://acap.dave.cridland.net/byowner/user/dwd/bookmarks/
  - http://dave.cridland.net/
Infotrope Polymer - ACAP, IMAP, ESMTP, and Lemonade

[apps-discuss] apps-team review of draft-ietf-fec… Dave Cridland
Re: [apps-discuss] apps-team review of draft-ietf… Ali C. Begen (abegen)