[AVTCORE] Artart early review of draft-ietf-avtcore-rtp-scip-01

Jim Fenton via Datatracker <noreply@ietf.org> Sun, 10 July 2022 22:13 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 226F6C157B58; Sun, 10 Jul 2022 15:13:27 -0700 (PDT)
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 7bit
From: Jim Fenton via Datatracker <noreply@ietf.org>
To: <art@ietf.org>
Cc: avt@ietf.org, draft-ietf-avtcore-rtp-scip.all@ietf.org
X-Test-IDTracker: no
X-IETF-IDTracker: 8.6.0
Auto-Submitted: auto-generated
Precedence: bulk
Message-ID: <165749120713.5488.9020157214711903696@ietfa.amsl.com>
Reply-To: Jim Fenton <fenton@bluepopcorn.net>
Date: Sun, 10 Jul 2022 15:13:27 -0700
Archived-At: <https://mailarchive.ietf.org/arch/msg/avt/9uj1aUqz2tpA-eDQEhlvridfLII>
Subject: [AVTCORE] Artart early review of draft-ietf-avtcore-rtp-scip-01
X-BeenThere: avt@ietf.org
X-Mailman-Version: 2.1.39
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: Sun, 10 Jul 2022 22:13:27 -0000

Reviewer: Jim Fenton
Review result: Not Ready

I am the designated ARTART reviewer for this early review of

Abstract: SCIP-214.2 is mentioned here but nowhere else in the document except
as a reference and in the media subtype registration. It seems inappropriate
for the sole mention to be in the abstract; should it also appear in Section 4
along with SCIP-210?

The abstract and introduction seem to present differing objectives for the
document, with the abstract focusing on the protocols themselves and the
introduction focusing more on usage.

Section 2: Might it be helpful to provide an informative reference to the FNBDT

Section 2: The fourth and fifth paragraphs don't seem like background

Section 3: While SHALL is an acceptable normative key word, I would prefer to
see MUST in this context (in addition to being more common in IETF documents).

Section 4: SCIP-210 (and perhaps SCIP-214.2) seem like they are required to
implement SCIP, and should therefore be normative references.

Section 4: "SCIP traffic may not always be..." should be reworded with better
normative language such as "The bit rate specified in SDP [RFC8866] is OPTIONAL
since discontinuous..."

Section 4.1: "The Timestamp field increments" should use normative language,
i.e., "The Timestamp field MUST increment"

Sections 5.1 and 5.2: These media subtypes are already registered with IANA and
should not be repeated here (some things like contact addresses may change, and
RFCs are immutable).

Section 6 paragraph 2: "unlikely to pose": Bad implementations might still pose
an DoS threat. Suggest "do not inherently pose".

Section 7: Please add instructions to IANA that upon publication as an RFC, the
registrations for [AUDIOSCIP] and [VIDEOSCIP] should be updated to cite this
document as a reference.

References: As suggested in the references, I requested copies of SCIP-210 and
SCIP-214.2 for my review three working days ago, and have received no response.
Section 6 of draft-kucherawy-bcp97bis-01 (not approved yet, but which seems
likely to be approved as a BCP before this document publishes) states: "At a
minimum, authors/editors of source documents need to secure freely available
copies of the target documents for use by all anticipated reviewers during the
source document's life cycle, which includes working group participants, any
member of the community that chooses to participate in Last Call discussions,
area review teams, IANA expert reviewers, and members of the IESG." You might
want to determine if that requirement can be met here.

Authors' Addresses: The SCIP Working Group is not an author of this document,
and should not be in Authors' Addresses.