[art] Artart last call review of draft-ietf-lamps-rfc6712bis-07

Claudio Allocchio via Datatracker <noreply@ietf.org> Mon, 21 October 2024 07:15 UTC

Return-Path: <noreply@ietf.org>
X-Original-To: art@ietf.org
Delivered-To: art@ietfa.amsl.com
Received: from [10.244.8.251] (unknown [104.131.183.230]) by ietfa.amsl.com (Postfix) with ESMTP id 28C80C169416; Mon, 21 Oct 2024 00:15:34 -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
X-Test-IDTracker: no
X-IETF-IDTracker: 12.25.0
Auto-Submitted: auto-generated
Precedence: bulk
Message-ID: <172949493377.1906901.1334502700207332214@dt-datatracker-78dc5ccf94-w8wgc>
Date: Mon, 21 Oct 2024 00:15:33 -0700
Message-ID-Hash: 47CYT7BMUFP3FKD2L7XB3M3ZDBPMXY57
X-Message-ID-Hash: 47CYT7BMUFP3FKD2L7XB3M3ZDBPMXY57
X-MailFrom: noreply@ietf.org
X-Mailman-Rule-Misses: dmarc-mitigation; no-senders; approved; emergency; loop; banned-address; member-moderation; header-match-art.ietf.org-0; nonmember-moderation; administrivia; implicit-dest; max-recipients; max-size; news-moderation; no-subject; digests; suspicious-header
CC: draft-ietf-lamps-rfc6712bis.all@ietf.org, last-call@ietf.org, spasm@ietf.org
X-Mailman-Version: 3.3.9rc6
Reply-To: Claudio Allocchio <Claudio.Allocchio@garr.it>
Subject: [art] Artart last call review of draft-ietf-lamps-rfc6712bis-07
List-Id: Applications and Real-Time Area Discussion <art.ietf.org>
Archived-At: <https://mailarchive.ietf.org/arch/msg/art/8JlAvippscKLuBSzMdlLkI7u6Ls>
List-Archive: <https://mailarchive.ietf.org/arch/browse/art>
List-Help: <mailto:art-request@ietf.org?subject=help>
List-Owner: <mailto:art-owner@ietf.org>
List-Post: <mailto:art@ietf.org>
List-Subscribe: <mailto:art-join@ietf.org>
List-Unsubscribe: <mailto:art-leave@ietf.org>

Reviewer: Claudio Allocchio
Review result: Almost Ready

Good morning, I'm the assigned reviewer from the ARTART area.
This draft is almost ready but I have some suggestions before it is published.

1) as any document "updating" a series of previous RFCs, ensuring an easy and
crystal clear reading of it compared to the other documents being obsoleted or
updated is tricky. I generally suggest some further detailed wording, or a
detailed dedicated "updates and obsolets" section where it is clearly listed
which sections of the previous documents are affected: something like

* RFCxxxx section x.y.z, <text> is obsoleted

etc...

2) clarification about the use of the wide range of HTTP protocol options
(section 3.8). "SHOULD" is inappropriate normative here --> "should".
Furthermore, it may be more useful to create a list of suggested HTTP features
to use or mandatory HTTP features to use, so that all implementation try to
stick with it, instead of just suggesting not to use the not needed HTTP parts.

3) section 3.6 examples: https instead of http ?

4) section 4: shall we suggest also "what to do" (a coherent behaviour) when we
hit implementations with an old non standard approach in transferring CMP over
HTTP?

all the rest is ok for me.

all the best
Claudio