[yang-doctors] Yangdoctors last call review of draft-ietf-opsawg-vpn-common-06

Radek Krejčí via Datatracker <noreply@ietf.org> Sun, 28 March 2021 15:04 UTC

Return-Path: <noreply@ietf.org>
X-Original-To: yang-doctors@ietf.org
Delivered-To: yang-doctors@ietfa.amsl.com
Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 89A893A1E55; Sun, 28 Mar 2021 08:04:18 -0700 (PDT)
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 8bit
From: =?utf-8?q?Radek_Krej=C4=8D=C3=AD_via_Datatracker?= <noreply@ietf.org>
To: <yang-doctors@ietf.org>
Cc: draft-ietf-opsawg-vpn-common.all@ietf.org, last-call@ietf.org, opsawg@ietf.org
X-Test-IDTracker: no
X-IETF-IDTracker: 7.27.0
Auto-Submitted: auto-generated
Precedence: bulk
Message-ID: <161694385847.20490.9530808274534750800@ietfa.amsl.com>
Reply-To: =?utf-8?b?UmFkZWsgS3JlasSNw60=?= <rkrejci@cesnet.cz>
Date: Sun, 28 Mar 2021 08:04:18 -0700
Archived-At: <https://mailarchive.ietf.org/arch/msg/yang-doctors/WZJU8-tPAQlUeeIKZzDUBwNhUy0>
Subject: [yang-doctors] Yangdoctors last call review of draft-ietf-opsawg-vpn-common-06
X-BeenThere: yang-doctors@ietf.org
X-Mailman-Version: 2.1.29
List-Id: Email list of the yang-doctors directorate <yang-doctors.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/yang-doctors>, <mailto:yang-doctors-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/yang-doctors/>
List-Post: <mailto:yang-doctors@ietf.org>
List-Help: <mailto:yang-doctors-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/yang-doctors>, <mailto:yang-doctors-request@ietf.org?subject=subscribe>
X-List-Received-Date: Sun, 28 Mar 2021 15:04:19 -0000

Reviewer: Radek Krejčí
Review result: Ready with Nits

The I-D document contains a single YANG module ietf-vpn-common.

The I-D as well as the module itself are in a good shape, I have just two notes:

* module's description
This is my fault since I came with it in the previous review. There should be
really `Section 4.c` as you had. What confused me is how the RFC shows it in
its htmlized version, where the link is connected just with the 'Section 4'
string and pointing to the RFC itself instead of actually referenced Trust
legal document.

* `service-status` grouping
While the `status-timestamp` grouping was modified since my previous review,
the `service-status` still contains only the service-status/status/oper-status
container with the config false flag. My arguments are still the same, the
description of the other items there says that they are status information, so
they should be specified that way. The uses statement doesn't have its own
config statement, so if you want to place the mentioned groupings into config
true data, an extra grouping or refine will be required.