[RTG-DIR] Rtgdir last call review of draft-ietf-opsawg-rfc7125-update-02

Ketan Talaulikar via Datatracker <noreply@ietf.org> Tue, 02 May 2023 14:32 UTC

Return-Path: <noreply@ietf.org>
X-Original-To: rtg-dir@ietf.org
Delivered-To: rtg-dir@ietfa.amsl.com
Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id F1CA1C13AE40; Tue, 2 May 2023 07:32:03 -0700 (PDT)
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 7bit
From: Ketan Talaulikar via Datatracker <noreply@ietf.org>
To: rtg-dir@ietf.org
Cc: draft-ietf-opsawg-rfc7125-update.all@ietf.org, last-call@ietf.org, opsawg@ietf.org
X-Test-IDTracker: no
X-IETF-IDTracker: 10.1.0
Auto-Submitted: auto-generated
Precedence: bulk
Message-ID: <168303792397.28529.6821762685052418298@ietfa.amsl.com>
Reply-To: Ketan Talaulikar <ketant.ietf@gmail.com>
Date: Tue, 02 May 2023 07:32:03 -0700
Archived-At: <https://mailarchive.ietf.org/arch/msg/rtg-dir/UP-of23HJEqUPdIcHbnVzd7c_0o>
Subject: [RTG-DIR] Rtgdir last call review of draft-ietf-opsawg-rfc7125-update-02
X-BeenThere: rtg-dir@ietf.org
X-Mailman-Version: 2.1.39
List-Id: Routing Area Directorate <rtg-dir.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/rtg-dir>, <mailto:rtg-dir-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/rtg-dir/>
List-Post: <mailto:rtg-dir@ietf.org>
List-Help: <mailto:rtg-dir-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/rtg-dir>, <mailto:rtg-dir-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 02 May 2023 14:32:04 -0000

Reviewer: Ketan Talaulikar
Review result: Has Nits

1) This document is Standards Track while the RFC7125 that it obsoletes is
Informational. Standards Track seems correct to me. This may not be an issue -
simply calling attention to this change in status to be explained perhaps in
the Shepherd Write-up down the line?

2) In Sec 1, please check if the paragraph should be updated as below:

This document fixes that problem by removing stale information from the IPFIX
registry [IPFIX] and avoiding future conflicts with the authoritative TCP
registry [TCP-FLAGS].

3) Sec 3 does not cover all the fields of the IPFIX IANA Table. Notably
"Additional Information" field chould have been supplied here instead of being
described in IANA Section 4. Perhaps if everything is stated in Sec 3 then the
IANA considerations become simpler and clearer?

4) Please consider if the additional text from Security And Privacy
Considerations from RFC7125 is required in addition to the reference to the
RFC7011. There is discussion related to DDOS in section 1 of the document.