[AVTCORE] Benjamin Kaduk's No Objection on draft-ietf-avtcore-multiplex-guidelines-12: (with COMMENT)

Benjamin Kaduk via Datatracker <noreply@ietf.org> Wed, 17 June 2020 03:32 UTC

Return-Path: <noreply@ietf.org>
X-Original-To: avt@ietf.org
Delivered-To: avt@ietfa.amsl.com
Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 509D33A0E0F; Tue, 16 Jun 2020 20:32:53 -0700 (PDT)
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 7bit
From: Benjamin Kaduk via Datatracker <noreply@ietf.org>
To: The IESG <iesg@ietf.org>
Cc: draft-ietf-avtcore-multiplex-guidelines@ietf.org, avtcore-chairs@ietf.org, avt@ietf.org, Jonathan Lennox <jonathan.lennox42@gmail.com>, jonathan.lennox42@gmail.com
X-Test-IDTracker: no
X-IETF-IDTracker: 7.3.2
Auto-Submitted: auto-generated
Precedence: bulk
Reply-To: Benjamin Kaduk <kaduk@mit.edu>
Message-ID: <159236477330.24380.13617768880911328228@ietfa.amsl.com>
Date: Tue, 16 Jun 2020 20:32:53 -0700
Archived-At: <https://mailarchive.ietf.org/arch/msg/avt/kcnkOsXhj3TTW8BlMpy9anm0WIA>
Subject: [AVTCORE] Benjamin Kaduk's No Objection on draft-ietf-avtcore-multiplex-guidelines-12: (with COMMENT)
X-BeenThere: avt@ietf.org
X-Mailman-Version: 2.1.29
List-Id: Audio/Video Transport Core Maintenance <avt.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/avt>, <mailto:avt-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/avt/>
List-Post: <mailto:avt@ietf.org>
List-Help: <mailto:avt-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/avt>, <mailto:avt-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 17 Jun 2020 03:32:53 -0000

Benjamin Kaduk has entered the following ballot position for
draft-ietf-avtcore-multiplex-guidelines-12: No Objection

When responding, please keep the subject line intact and reply to all
email addresses included in the To and CC lines. (Feel free to cut this
introductory paragraph, however.)

Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html
for more information about IESG DISCUSS and COMMENT positions.

The document, along with other ballot positions, can be found here:


Thank you for addressing my Discuss point.

A couple things I noticed while reviewing the diff:

Section 3.1's "might not be the choice suitable in another
situation or combination of reasons" seems like it's comparing things of different types.

Section 4.3.1 now has:

   SRTP [RFC3711] as specified uses per SSRC unique keys, however the
   original assumption was a single session master key from which SSRC
   specific RTP and RTCP keys where derived.  However, that assumption
   was proven incorrect, as the application usage and the developed key-
   mamangement mechanisms have chosen many different methods for
   ensuring SSRC unique keys.  The key-management functions have

I didn't try to look at RFC 3711 and see if there was now-believed-to-be-incorrect
text in need of an update or not.  I guess any potential violations of 3711 are
in the "application usage and the developed-key-management techniques" that
we describe, not in this document itself, so there's not really a question of this
document being in conflict with 3711.
Also, nit: s/mamangement/management/