Subject: [secdir] secdr review of draft-ietf-avtext-rtp-duplication

From: David Harrington <[email-masked]>
Date: Mon, 3 Feb 2014 21:54:34 -0500

I have reviewed this document as part of the security directorate's 
ongoing effort to review all IETF documents being processed by the 
IESG.  These comments were written primarily for the benefit of the 
security area directors.  Document editors and WG chairs should treat 
these comments just like any other last call comments.

From a security perspective, I believe this draft is Ready for publication.

Comments:
I am not an expert is RTP, RTCP, and related protocols. I assume this is a valid extension based largely on the authorship by Ali Begen, and suggestions by Magnus Westerlund.

I have a concern with section 3.4, which lists two states that are REQUIRED to exist for this specification, and then discusses that other approaches could work but would require an additional specification. Doesn't that make this appropriate for SHOULD rather than REQUIRED terminology?

in section 4.2, "We require …"; does the protocol specification REQUIRE this?

s/section section/section/

David Harrington
[email-masked]

---

From: Colin Perkins <[email-masked]>
Date: Tue, 4 Feb 2014 18:05:20 +0000

On 4 Feb 2014, at 02:54, David Harrington <[email-masked]> wrote:
> I have a concern with section 3.4, which lists two states that are REQUIRED to exist for this specification, and then discusses that other approaches could work but would require an additional specification. Doesn’t that make this appropriate for SHOULD rather than REQUIRED terminology?

The intent is to say, “You are currently required to do X or Y, but future extensions to this specification may relax condition Y given appropriate signalling”. We can try to clarify, if that’s not clear.

> in section 4.2, "We require …"; does the protocol specification REQUIRE this?

Changing “We require out-of-band signalling” to “Out-of-band signalling is needed” would cover the intended meaning, and avoid the potential confusion.

-- 
Colin Perkins
http://csperkins.org/