[RTG-DIR]Rtgdir last call review of draft-ietf-opsawg-ntw-attachment-circuit-12

Joel Halpern via Datatracker <noreply@ietf.org> Thu, 15 August 2024 02:30 UTC

Return-Path: <noreply@ietf.org>
X-Original-To: rtg-dir@ietf.org
Delivered-To: rtg-dir@ietfa.amsl.com
Received: from [10.244.2.52] (unknown [104.131.183.230]) by ietfa.amsl.com (Postfix) with ESMTP id CF2B8C1CAE8E; Wed, 14 Aug 2024 19:30:17 -0700 (PDT)
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 7bit
From: Joel Halpern via Datatracker <noreply@ietf.org>
To: rtg-dir@ietf.org
X-Test-IDTracker: no
X-IETF-IDTracker: 12.22.0
Auto-Submitted: auto-generated
Precedence: bulk
Message-ID: <172368901734.1101532.16586232777117530138@dt-datatracker-6df4c9dcf5-t2x2k>
Date: Wed, 14 Aug 2024 19:30:17 -0700
Message-ID-Hash: 5T35S72ZEYZP2AFSGP224GMJWLYF4DN4
X-Message-ID-Hash: 5T35S72ZEYZP2AFSGP224GMJWLYF4DN4
X-MailFrom: noreply@ietf.org
X-Mailman-Rule-Misses: dmarc-mitigation; no-senders; approved; emergency; loop; banned-address; member-moderation; header-match-rtg-dir.ietf.org-0; nonmember-moderation; administrivia; implicit-dest; max-recipients; max-size; news-moderation; no-subject; digests; suspicious-header
CC: draft-ietf-opsawg-ntw-attachment-circuit.all@ietf.org, last-call@ietf.org, opsawg@ietf.org
X-Mailman-Version: 3.3.9rc4
Reply-To: Joel Halpern <jmh@joelhalpern.com>
Subject: [RTG-DIR]Rtgdir last call review of draft-ietf-opsawg-ntw-attachment-circuit-12
List-Id: Routing Area Directorate <rtg-dir.ietf.org>
Archived-At: <https://mailarchive.ietf.org/arch/msg/rtg-dir/vbEWds2sukbhsomERLr4XD6UmMM>
List-Archive: <https://mailarchive.ietf.org/arch/browse/rtg-dir>
List-Help: <mailto:rtg-dir-request@ietf.org?subject=help>
List-Owner: <mailto:rtg-dir-owner@ietf.org>
List-Post: <mailto:rtg-dir@ietf.org>
List-Subscribe: <mailto:rtg-dir-join@ietf.org>
List-Unsubscribe: <mailto:rtg-dir-leave@ietf.org>

Reviewer: Joel Halpern
Review result: Ready

Hello,

I have been selected as the Routing Directorate reviewer for this draft. The
Routing Directorate seeks to review all routing or routing-related drafts as
they pass through IETF last call and IESG review, and sometimes on special
request. The purpose of the review is to provide assistance to the Routing ADs.
For more information about the Routing Directorate, please see
https://wiki.ietf.org/en/group/rtg/RtgDir

Although these comments are primarily for the use of the Routing ADs, it would
be helpful if you could consider them along with any other IETF Last Call
comments that you receive, and strive to resolve them through discussion or by
updating the draft.

Document: draft-name-version
Reviewer: your-name
Review Date: date
IETF LC End Date: date-if-known
Intended Status: copy-from-I-D

Summary:
Choose from this list...

No issues found. This document is ready for publication.
    I have a few minor comments that should be considered.

This is a truly impressive piece of work.  The editors have pulled together
information from a myriad sources into a usable (if massive) YANG module that
addresses the range of needs very well.

Major Issues: N/A

Minor Issues:
    I note that section 5.1 in discussing parent relationships specifies that
    if a parent AC is deleted, all the child ACs MUST be deleted.   Given that
    there is no reference from a parent to its children (unless I missed it),
    it seems to this reader that it would really help implementors to tell them
    how this is to be done?  Are all children to be delted first, and the
    client give an error if there are any active children?  Is the client to
    silently find and delete all ACs which point to the deleted AC as a parent?
     Or some other means?

   In section 5.2 (References) in describing the groupings the tree diagram
   shows a number of peer entities.  However, unless I am misreading the YANG,
   they are, in almost all cases, actually nested.  Was this a deliberate
   simplification, on artifact of the tree generation tool, or an error in my
   reading?

    I note that the document refers to RIP in multiple places.  Unless I missed
    something, this references RIPv2, but not RIPng (RFC 20808).  I can imagine
    reasons for such an omission.  If there is a good reason, then please state
    it.  Otherwise, sorry, please also cover 2080.