[art] Artart last call review of draft-ietf-mmusic-rfc8843bis-04

Claudio Allocchio via Datatracker <noreply@ietf.org> Mon, 09 August 2021 21:59 UTC

Return-Path: <noreply@ietf.org>
X-Original-To: art@ietf.org
Delivered-To: art@ietfa.amsl.com
Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 077853A1A72; Mon, 9 Aug 2021 14:59:22 -0700 (PDT)
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 7bit
From: Claudio Allocchio via Datatracker <noreply@ietf.org>
To: art@ietf.org
Cc: draft-ietf-mmusic-rfc8843bis.all@ietf.org, last-call@ietf.org, mmusic@ietf.org
X-Test-IDTracker: no
X-IETF-IDTracker: 7.36.0
Auto-Submitted: auto-generated
Precedence: bulk
Message-ID: <162854636194.16087.5815406988959300980@ietfa.amsl.com>
Reply-To: Claudio Allocchio <Claudio.Allocchio@garr.it>
Date: Mon, 09 Aug 2021 14:59:22 -0700
Archived-At: <https://mailarchive.ietf.org/arch/msg/art/vCRligF8bnxVh9TKuHQ7nMrxQTI>
Subject: [art] Artart last call review of draft-ietf-mmusic-rfc8843bis-04
X-BeenThere: art@ietf.org
X-Mailman-Version: 2.1.29
List-Id: Applications and Real-Time Area Discussion <art.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/art>, <mailto:art-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/art/>
List-Post: <mailto:art@ietf.org>
List-Help: <mailto:art-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/art>, <mailto:art-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 09 Aug 2021 21:59:27 -0000

Reviewer: Claudio Allocchio
Review result: Ready

The document is consistent and ready for publication.
Just as a style comment: section 1.4 is a bit unusual in an RFC, specifically
by mentioning what happened during one IETF meeting, etc. Nothing wrong with it
but it mixes a specification (the RFC resulting for publication) with historic
actions. Maybe there is a way to avoid this by changing a bit the text of the
1.4 section.

Another comment: again all fine! but when a document like this updates/fixes
other documents, including errata, new text replacing sections in other
documents, etc, the implementer has a challenging task in putting the pieces
together. I'd for the future suggest not to use this "amendment" technique, but
to publish complete updated RFCs versions instead.