Skip to main content

Last Call Review of draft-ietf-perc-private-media-framework-08

Request Review of draft-ietf-perc-private-media-framework
Requested revision No specific revision (document currently at 12)
Type Last Call Review
Team Transport Area Review Team (tsvart)
Deadline 2019-02-13
Requested 2019-01-30
Authors Paul Jones , David Benham , Christian Groves
Draft last updated 2019-02-04
Completed reviews Secdir Last Call review of -08 by Vincent Roca (diff)
Genart Last Call review of -08 by Linda Dunbar (diff)
Tsvart Last Call review of -08 by Gorry Fairhurst (diff)
Secdir Telechat review of -10 by Vincent Roca (diff)
Genart Telechat review of -09 by Linda Dunbar (diff)
Assignment Reviewer Gorry Fairhurst
State Completed
Review review-ietf-perc-private-media-framework-08-tsvart-lc-fairhurst-2019-02-04
Reviewed revision 08 (document currently at 12)
Result Ready with Nits
Completed 2019-02-04
This document has been reviewed as part of the transport area review team's
ongoing effort to review key IETF documents. These comments were written
primarily for the transport area directors, but are copied to the document's
authors and WG to allow them to address any issues raised and also to the IETF
discussion list for information. The authors should consider this
review as part of the last-call comments they receive. Please always CC if you reply to or forward this review.

There are two other IETF drafts cited normally by this document, also in last call.

This document defines a security architecture based around an IETF transport, 
but does not itself propose updates to the transport mechanisms. I did
not find additional transport concerns, but have a number of general 
comments I'd like you to consider in the LC.


General comments

Some keywords appear not defined before first used - whilst these are likely
to be well-known by the coimmunity of interest, it would none-the-less
be helpful to define these:


In section 8.1, there is a sentence starting "Off-path atttackers may" ... while this
is lower case, the authors may wish toi consider using "could" to remove any
possibility of this being regarded as permissive.

In 8.1, the text "could incorrectly assuming their packets..." probably ought to
read could incorrectly assume their packets..." 

In section 8.2.1. there is a dscription of a resource consumption attack, but
no miitigation is described. It could be possible to consider using  rate-limiting 
of requests to reduce the impact - a mthod commonly suggested in other
attacks on the transport endpoints.