[pim] Yangdoctors last call review of draft-ietf-pim-msdp-yang-12
Reshad Rahman via Datatracker <noreply@ietf.org> Wed, 29 January 2020 03:05 UTC
Return-Path: <noreply@ietf.org>
X-Original-To: pim@ietf.org
Delivered-To: pim@ietfa.amsl.com
Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id D1D31120137; Tue, 28 Jan 2020 19:05:44 -0800 (PST)
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 8bit
From: Reshad Rahman via Datatracker <noreply@ietf.org>
To: yang-doctors@ietf.org
Cc: last-call@ietf.org, draft-ietf-pim-msdp-yang.all@ietf.org, pim@ietf.org
X-Test-IDTracker: no
X-IETF-IDTracker: 6.116.1
Auto-Submitted: auto-generated
Precedence: bulk
Reply-To: Reshad Rahman <rrahman@cisco.com>
Message-ID: <158026714472.4559.17171044234392202915@ietfa.amsl.com>
Date: Tue, 28 Jan 2020 19:05:44 -0800
Archived-At: <https://mailarchive.ietf.org/arch/msg/pim/i8q8FGRsHIiCLa0GJOPZy4SlxLI>
Subject: [pim] Yangdoctors last call review of draft-ietf-pim-msdp-yang-12
X-BeenThere: pim@ietf.org
X-Mailman-Version: 2.1.29
List-Id: Protocol Independent Multicast <pim.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/pim>, <mailto:pim-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/pim/>
List-Post: <mailto:pim@ietf.org>
List-Help: <mailto:pim-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/pim>, <mailto:pim-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 29 Jan 2020 03:05:45 -0000
Reviewer: Reshad Rahman Review result: Almost Ready YANG Doctor review of draft-ietf-pim-msdp-yang-12 by Reshad Rahman 1 module in this draft: - ietf-msdp@2020-01-24.yang No YANG validation errors or warnings Thank you for addressing comments which were provided on rev-01 of the document. - Page 21, the YANG module has the augmentation of “/rt:…/rt:control-plane-protocol” but there is a missing when statement. This means that on a device which supports this YANG model, the “msdp” container node will appear in all instances of “rt:control-plane-protocol”, even the non-MSDP ones. If you need an example of how to fix this with when statement, please take a look at OSPF and BFD YANG models. - There are no examples. Just a couple of simple XML examples would help a lot. - There are IMO still too many (14?) features for a fairly straight-forward YANG model. An explanation for this is provided in section 3.1, but this does not comply with 4.17 of RFC8407: The set of YANG features defined in a module should be considered carefully. Very fine granular features increase interoperability complexity and should be avoided. A likely misuse of the feature mechanism is the tagging of individual leafs (e.g., counters) with separate features. - Page 12, the if-feature was taken out of password (to address a comment regarding duplicate if-feature), but I believe the remaining one should be moved up from case key-chain to container authentication. - There is an as-number leaf in the YANG model, but no such thing in RFC3618. Do we need a reference here? - Page 24, RPC clear-sa-cache has source-addr using type ipv4-multi-cast-source-address. But in the operational model (container sa-cache), source-addr is a union of either * or ipv4-address. Why the difference? Same question, wrt inconsistency, for leaf group (ipv4-multicast-group-address in RPC and ipv4-address in operational model). - Page 22, rp-address is of type ip-address, should that be ipv4-address just like rpf-peer? Or am I misunderstanding this? - Many of the descriptions are still very terse, e.g. up-time, expire. - I’m not an MSDP expert, but I believe adding, where appropriate in the YANG module, more references to the appropriate sections of RFC3618 or other PIM RFCs would improve the document. e.g. this could help for RPF-related nodes. - Section 6: s/one new URIs/one new URI/
- [pim] Yangdoctors last call review of draft-ietf-… Reshad Rahman via Datatracker