[yang-doctors] yangdoctors - Last Call review

Mahesh Jethanandani <mjethanandani@gmail.com> Thu, 26 September 2019 12:34 UTC

Return-Path: <mjethanandani@gmail.com>
X-Original-To: yang-doctors@ietfa.amsl.com
Delivered-To: yang-doctors@ietfa.amsl.com
Received: from localhost (localhost []) by ietfa.amsl.com (Postfix) with ESMTP id DA80812016E; Thu, 26 Sep 2019 05:34:45 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.998
X-Spam-Status: No, score=-1.998 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com
Received: from mail.ietf.org ([]) by localhost (ietfa.amsl.com []) (amavisd-new, port 10024) with ESMTP id 2tyjU3kY8ENO; Thu, 26 Sep 2019 05:34:44 -0700 (PDT)
Received: from mail-wm1-x332.google.com (mail-wm1-x332.google.com [IPv6:2a00:1450:4864:20::332]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A8837120145; Thu, 26 Sep 2019 05:34:40 -0700 (PDT)
Received: by mail-wm1-x332.google.com with SMTP id m18so2399490wmc.1; Thu, 26 Sep 2019 05:34:40 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=from:content-transfer-encoding:mime-version:subject:message-id:date :cc:to; bh=kVACcJeYXskN6AzKlJfzR0MBO8hJ/iVpU0LPFt4NCOw=; b=qgY+Oh0W55sD7yLLZb9TA18bUu9ID7SaTusUrVfUIyb6Qvtm+yw4ETucWaW8ya2BF+ mEVGn81Vjqd8Ofcy54mYWBRhodk6deP3/bv9GWg0FDUUGic6DQ85eQQFWq+Ax18fCM3g qPZF1PUP/HJLMYT6SQeXqalKwFpXfcr3jMx6oGbUJJ+lOlCw1CeG5eTPcXyz8KnUfVFV /Z7r7MankQANz4UI0mpme8w1QaobyiY+2kVymSWJXue2P8B5gdZWR6eJrS5eCq+2wiz/ yR7cxP/kY1B/ilWS04ETtsT5Uyi0E3Dm4ANGwpLiuDseL7FIWMcyUDobgB/EMovUqa+S c4nw==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:content-transfer-encoding:mime-version :subject:message-id:date:cc:to; bh=kVACcJeYXskN6AzKlJfzR0MBO8hJ/iVpU0LPFt4NCOw=; b=Xnxu9v55wtxOlg/EEtbFDjZmO3UMOPkZkHX6Qh1AjqathYuGDR8vRNgp60NJvqOy96 cqxIQfhnvhobDkbBBhJV77QpLVV7m7oDDOBk17fDysJQXKZ1TAmoeMyr45qk1SOkSbrW mBIrl1NRw0NdncRN5h1dV6YYgAsVV52XkPJgFbv97PQsbavlpSPKMcwvTdE+eaq/Zr1H CviYBKdCEhKIkWCaxZ08tnjc/I0K5/S13flprfOYl1FybcGVTKEeK9L8ZG8ix27El5tN 6z9MGKStha0qDLt9OZiweMUufCGEjUsxGT/+QgubO2l1Hn1mR0oJZaMSnTF5gk93YgBo ByxQ==
X-Gm-Message-State: APjAAAWGnp26QjwMwQyAosZ4pvAODbjbSOuX3eAWW8f0360Ibl6DhJFR xwSYztR5Lq9iJBHXykyJlN4ddrvQGQM=
X-Google-Smtp-Source: APXvYqzSRfO/krmDSNmQRLV4p4BSy6fxsZLl7JPwzvB79WG76LZbzuTtE6wEAYQ0vR2ZjvC3K1Sx8A==
X-Received: by 2002:a1c:720b:: with SMTP id n11mr2685394wmc.23.1569501278789; Thu, 26 Sep 2019 05:34:38 -0700 (PDT)
Received: from [] ([]) by smtp.gmail.com with ESMTPSA id b15sm2339298wmb.28.2019. (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Thu, 26 Sep 2019 05:34:38 -0700 (PDT)
From: Mahesh Jethanandani <mjethanandani@gmail.com>
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: quoted-printable
Mime-Version: 1.0 (Mac OS X Mail 11.5 \(3445.9.1\))
Message-Id: <3F848FD0-F0B7-4134-B6CF-5A4CABC43CA9@gmail.com>
Date: Thu, 26 Sep 2019 14:34:36 +0200
Cc: mboned@ietf.org, ietf@ietf.org, draft-ietf-mboned-multicast-yang-model.all@ietf.org
To: YANG Doctors <yang-doctors@ietf.org>
X-Mailer: Apple Mail (2.3445.9.1)
Archived-At: <https://mailarchive.ietf.org/arch/msg/yang-doctors/dv_-0qZ6mpkNmA4_ArRvczagYLI>
Subject: [yang-doctors] yangdoctors - Last Call review
X-BeenThere: yang-doctors@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
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: Thu, 26 Sep 2019 12:34:46 -0000

Document reviewed: draft-ietf-mboned-multicast-yang-model-02

Status: Not Ready

I am not an expert in multicast technology. If my understanding of the multicast is incorrect, feel free to educate me and everyone else. This review is looking at the draft from a YANG perspective.

Rather than providing one big review, and because some major changes are needed in the draft to be able to provide a comprehensive review, this review will be done in parts. This is part 1 of the review. The expectation is that a revised version of the document will address comments in this review before the review is continued.

Note, this document is reviewed as part of the effort by the ADs of the OPS to review all documents that define a YANG model. These comments are written with the intent of improving the YANG models. Comments that are not addressed in LC should be included in AD review during IESG review. WG and editors should treat these comments as any other LC comments.

Please review Guidelines for Authors and Reviewers of YANG Data Model Documents (RFC 6087) when in doubt or want to know how to write a YANG model.

I was toggling between stating that the document was "Not Ready" and "On the Right Track". While I felt that the document was indeed on the right track, I also felt that the document was just not ready as is.


   This document intents to provide a general and all-round multicast
   YANG data model, which tries to stand at a high level to take full
   advantages of existed multicast protocol models to control the
   multicast network, and guides the deployment of multicast service.
   And also, there will define several possible RPCs about how to
   interact between multicast YANG data model and multicast protocol
   models.  This multicast YANG data model is mainly used by the
   management tools run by the network operators in order to manage,
   monitor and debug the network resources used to deliver multicast
   service, as well as gathering some data from the network.


For a document that claims to be a uber model for all multicast models, it does little to demonstrate how the different models are supposed to work with this model. Lack of examples in the draft, leaves me guessing on how the model is supposed to work, and how the different multicast models are supposed to use this model. A quick look at the PIM YANG model, which is supposed to use this model, shows that that model does not even have a normative or informative reference to this draft. Please demonstrate how this model is supposed to work with examples, and ideally work with all the multicast YANG model draft authors to use this model.

Secondly, it is not clear what the purpose of empty containers is in the YANG model. For example, container bgp has no attributes. Is this an augmentation point or a mount point? If so, who is expected to augment or use as a mount point for the container? The draft gives no guidelines on how the container is expected to be used. Again, an example would have helped. If they are meant to be an indication what the routing protocol for the underlay is, why do you need a container? A boolean leaf should have sufficed. As defined, one can have multiple routing protocols defined for a given underlay. Was this the intent?

Separately, the authors need to address the comments provided on the e-mail thread 


In particular, please collapse the groupings, reduce the tab spaces to 2, and move all RFC references to the reference statement with the full name of the draft. An example of the change would be as follows:


        container bgp {
              "The underlay technology is BGP. BGP protocol RFC4271
               should be triggered to run if BGP is used as
               underlay protocol.";

        container bgp {
            "The underlay technology is BGP. BGP protocol RFC4271
             should be triggered to run if BGP is used as
             underlay protocol.”;
            “RFC 4271: A Border Gateway Protocol 4 (BGP-4)”;


Mahesh Jethanandani