[Lsr] Benjamin Kaduk's No Objection on draft-ietf-lsr-yang-isis-reverse-metric-04: (with COMMENT)
Benjamin Kaduk via Datatracker <noreply@ietf.org> Sat, 27 November 2021 23:06 UTC
Return-Path: <noreply@ietf.org>
X-Original-To: lsr@ietf.org
Delivered-To: lsr@ietfa.amsl.com
Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 3B4373A0EA7; Sat, 27 Nov 2021 15:06:56 -0800 (PST)
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 7bit
From: Benjamin Kaduk via Datatracker <noreply@ietf.org>
To: The IESG <iesg@ietf.org>
Cc: draft-ietf-lsr-yang-isis-reverse-metric@ietf.org, lsr-chairs@ietf.org, lsr@ietf.org, acee@cisco.com, jgs@juniper.net, acee@cisco.com
X-Test-IDTracker: no
X-IETF-IDTracker: 7.40.0
Auto-Submitted: auto-generated
Precedence: bulk
Reply-To: Benjamin Kaduk <kaduk@mit.edu>
Message-ID: <163805441583.6735.5675792412886329272@ietfa.amsl.com>
Date: Sat, 27 Nov 2021 15:06:56 -0800
Archived-At: <https://mailarchive.ietf.org/arch/msg/lsr/-RE3AwyP6zUsxDPCsZIppXL7JCg>
Subject: [Lsr] Benjamin Kaduk's No Objection on draft-ietf-lsr-yang-isis-reverse-metric-04: (with COMMENT)
X-BeenThere: lsr@ietf.org
X-Mailman-Version: 2.1.29
List-Id: Link State Routing Working Group <lsr.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/lsr>, <mailto:lsr-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/lsr/>
List-Post: <mailto:lsr@ietf.org>
List-Help: <mailto:lsr-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/lsr>, <mailto:lsr-request@ietf.org?subject=subscribe>
X-List-Received-Date: Sat, 27 Nov 2021 23:06:56 -0000
Benjamin Kaduk has entered the following ballot position for draft-ietf-lsr-yang-isis-reverse-metric-04: No Objection When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) Please refer to https://www.ietf.org/blog/handling-iesg-ballot-positions/ for more information about how to handle DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: https://datatracker.ietf.org/doc/draft-ietf-lsr-yang-isis-reverse-metric/ ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- Thanks for the simple and easy-to-read document! My comments are pretty minor. Section 2.2 grouping reverse-metric-if-config-data { description "IS-IS reverse metric config data."; container reverse-metric { description "IS-IS reverse metric data."; uses reverse-metric-data; leaf exclude-te-metric { type boolean; default false; description "If true and there is a TE metric defined for this interface then do not send the TE metric sub-TLV in the reverse metric TLV."; reference "RFC8500, Section 3.5"; } } } grouping tlv16-reverse-metric { description "IS-IS reverse metric TLV data."; container reverse-metric { description "IS-IS reverse metric TLV data."; uses reverse-metric-data; leaf te-metric { type uint32; description "The TE metric value from the sub-TLV if present."; reference "RFC8500, Section 3.5"; } } } Please confirm that Section 3.5 of RFC 8500 is the right reference for both of these; I didn't really see much there that lined up well with these descriptions. container reverse-metric { description "Announce a reverse metric to neighbors."; uses reverse-metric-if-config-data; container level-1 { description "Announce a reverse metric to level-1 neighbors."; uses reverse-metric-if-config-data; } container level-2 { description "Announce a reverse metric to level-2 neighbors."; uses reverse-metric-if-config-data; } } Are the interactions between the toplevel "reverse-metric-if-config-data" and the per-level uses of that grouping adequately specified by the core draft-ietf-isis-yang-isis-cfg such that we don't need to repeat them here? (I think it probably is.) Section 4 These are the subtrees and data nodes and their sensitivity/ vulnerability: I think the intent of the security considerations template is that we specifically talk about what bad things would happen if some unauthorized entity was writing values to the ("config true") nodes, or reading values from the ("config false") nodes. The current text here seems to just be listing the nodes without saying what happens if they're misconfigured or the contents are leaked to an unauthorized party. (On first glance, it seems like the security considerations of RFC 8500 basically cover everything that we would need to say. It's short, so we could repeat the content, or we could say that these YANG nodes correspond directly to the RFC 8500 functionality and the considerations of the functionality are described in RFC 8500.) Section 5 The core NETCONF/RESTCONF RFCs may not need to be classified as normative (we only reference them from the security considerations boilerplate), but there's not much harm in leaving them here. Appendix A Thank you for including the examples!
- [Lsr] Benjamin Kaduk's No Objection on draft-ietf… Benjamin Kaduk via Datatracker
- Re: [Lsr] Benjamin Kaduk's No Objection on draft-… Christian Hopps