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@xxxxxxxxx
