Re: Artart early review of draft-ietf-avtcore-rtp-scip-01

Comments below with [DH].

Dan Hanson
General Dynamics Mission Systems

-----Original Message-----
From: Jim Fenton via Datatracker <[email protected]> 
Sent: Sunday, July 10, 2022 6:13 PM
To: [email protected]
Cc: [email protected]; [email protected]
Subject: Artart early review of draft-ietf-avtcore-rtp-scip-01

----
External E-mail --- CAUTION: This email originated from outside GDMS. Do not click links or open attachments unless you recognize the sender and know the content is safe.

Reviewer: Jim Fenton
Review result: Not Ready

I am the designated ARTART reviewer for this early review of
draft-ietf-avtcore-rtp-scip-01

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?
[DH] The reference to SCIP-214.2 may be removed from the draft document.

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 protocol?
[DH] FNBDT was renamed to SCIP, so everything that was in the FNBDT protocol is in SCIP.

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

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).
[DH] SHALL will be changed to MUST.

Section 4: SCIP-210 (and perhaps SCIP-214.2) seem like they are required to implement SCIP, and should therefore be normative references.
[DH] The AVTCORE WG determined that SCIP will be treated as an opaque standard.

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..."
[DH] The text will be updated.

Section 4.1: "The Timestamp field increments" should use normative language, i.e., "The Timestamp field MUST increment"
[DH] The text will be updated.

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).
[DH] To be discussed at IETF 114.

Section 6 paragraph 2: "unlikely to pose": Bad implementations might still pose an DoS threat. Suggest "do not inherently pose".
[DH] The text will be updated.

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.
[DH] To be discussed at IETF 114.

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.
[DH] SCIP documents are controlled by The SCIP Working Group/NATO and are released on a need-to-know basis.  We have been working to making these available to IETF reviewers.

Authors' Addresses: The SCIP Working Group is not an author of this document, and should not be in Authors' Addresses.
[DH] We will add section "9.1. Change Control Address" for the SCIP Working Group.