Re: [yang-doctors] [MBONED] yangdoctors - Last Call review

<zhang.zheng@zte.com.cn> Fri, 27 September 2019 01:01 UTC

Return-Path: <zhang.zheng@zte.com.cn>
X-Original-To: yang-doctors@ietfa.amsl.com
Delivered-To: yang-doctors@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7197C120227; Thu, 26 Sep 2019 18:01:28 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.197
X-Spam-Level:
X-Spam-Status: No, score=-4.197 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, UNPARSEABLE_RELAY=0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9pfRYYGhSnyg; Thu, 26 Sep 2019 18:01:25 -0700 (PDT)
Received: from mxhk.zte.com.cn (mxhk.zte.com.cn [63.217.80.70]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D038712013C; Thu, 26 Sep 2019 18:01:24 -0700 (PDT)
Received: from mse-fl1.zte.com.cn (unknown [10.30.14.238]) by Forcepoint Email with ESMTPS id 55E514B58BEA9DC8B6BE; Fri, 27 Sep 2019 09:01:22 +0800 (CST)
Received: from njxapp04.zte.com.cn ([10.41.132.203]) by mse-fl1.zte.com.cn with SMTP id x8R10rKq090644; Fri, 27 Sep 2019 09:00:53 +0800 (GMT-8) (envelope-from zhang.zheng@zte.com.cn)
Received: from mapi (njxapp01[null]) by mapi (Zmail) with MAPI id mid203; Fri, 27 Sep 2019 09:00:53 +0800 (CST)
Date: Fri, 27 Sep 2019 09:00:53 +0800
X-Zmail-TransId: 2af95d8d5f4526d8274f
X-Mailer: Zmail v1.0
Message-ID: <201909270900532132682@zte.com.cn>
In-Reply-To: <3F848FD0-F0B7-4134-B6CF-5A4CABC43CA9@gmail.com>
References: 3F848FD0-F0B7-4134-B6CF-5A4CABC43CA9@gmail.com
Mime-Version: 1.0
From: zhang.zheng@zte.com.cn
To: mjethanandani@gmail.com
Cc: yang-doctors@ietf.org, mboned@ietf.org, ietf@ietf.org, draft-ietf-mboned-multicast-yang-model.all@ietf.org
Content-Type: multipart/mixed; boundary="=====_001_next====="
X-MAIL: mse-fl1.zte.com.cn x8R10rKq090644
Archived-At: <https://mailarchive.ietf.org/arch/msg/yang-doctors/MvccEp-Pr81K281UKkJbfBy0omQ>
Subject: Re: [yang-doctors] [MBONED] 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: Fri, 27 Sep 2019 01:01:29 -0000

Hi Mahesh,






Much appreciate for your review and comments. We will modify the draft and submit a new version later.


Thank you very much!






Best regards,


Sandy







原始邮件



发件人:MaheshJethanandani <mjethanandani@gmail.com>
收件人:YANG Doctors <yang-doctors@ietf.org>;
抄送人:mboned@ietf.org <mboned@ietf.org>;ietf@ietf.org <ietf@ietf.org>;draft-ietf-mboned-multicast-yang-model.all@ietf.org <draft-ietf-mboned-multicast-yang-model.all@ietf.org>;
日 期 :2019年09月26日 21:16
主 题 :[MBONED] yangdoctors - Last Call review




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.

Summary:

   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.

Review

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 

https://mailarchive.ietf.org/arch/msg/yang-doctors/Kw2o-kLv4MnGsiGgHHgZcKeakYY

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:

OLD:

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

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

Thanks

Mahesh Jethanandani
mjethanandani@gmail.com



_______________________________________________
MBONED mailing list
MBONED@ietf.org
https://www.ietf.org/mailman/listinfo/mboned