Subject: [netmod] review of draft-ietf-pim-yang-03.txt

From: Dean Bogdanovic <[email-masked]>
Date: Sat, 22 Oct 2016 08:21:09 -0400

Authors,

I don’t have deep knowledge of PIM, so if some protocol specifics haven’t been modeled right, I missed them. For application comparison, was looking at  Juniper PIM configuration. The modules are using draft-ietf-netmod-routing-cfg as base, and follows the routing-instance-centric model, hence didn’t have problems mapping it to Junos PIM config style. The model design by using base module and build for each specific variant a separate module is a good approach, as it enables simpler application of the modules by vendors and users.

Throughout the draft authors are using abbreviations (many of them not widely known) and the terminology section is not complete for PIM.  It would be good to write them out when first time used in the text

example,

the configuration for PIM-SM that is not relevant for an SSM-only implementation is collected in an ASM container.

Same thing is in the YANG module descriptions

enum new-dr {
           description
             "A new DR was elected on the connected network.";
         }
         enum new-df {
           description
             "A new DF was elected on the connected network.";
         }

DR and DF should be spelled out in the description

Make the descriptions in the code consistent, like in following example
typedef pim-mode {
       type enumeration {
         enum none {
           description
             "PIM is not operating.";
         }
         enum ssm {
           description
             "Source-Specific Multicast (SSM) with PIM Sparse Mode.";
         }
         enum asm {
           description
            "Any Source Multicast (ASM) with PIM Sparse Mode.";
         }

Why are the PIM related RFC not listed in the introduction section, as there are clearly relations between the model and PIM related RFCs

In chapter 2.2, why are you stating vendors will augment with required restrictions, but features might be added

It is expected that vendors
   will augment the model with any specific restrictions that might be
   required.  Vendors may also extend the features list with proprietary
   extensions.

It is expected that vendors will augment the model with any specific extensions and restrictions needed to adapt it to their vendor specific implementation. 

In chapter 3.1 bullet 2, the chapter finishes with statement

which does not make sense for PIM.

It would be nice to explain why does it not make sense for PIM. Why is there only 1 instances of PIM per VRF

From YANG perspective, the authors followed recommendations in the draft-ietf-netmod-rfc6087-bis-08

Hope this helps

Dean

---

From: Benoit Claise <[email-masked]>
Date: Mon, 24 Oct 2016 14:46:31 +0200

Dean,

Thanks.
As this is part of the early YANG doctor process, let me copy the YANG 
doctors, WG chairs, and ADs (as described at 
https://www.ietf.org/iesg/directorate/yang-doctors.html)

Regards, Benoit

> Authors,
>
> I don’t have deep knowledge of PIM, so if some protocol specifics 
> haven’t been modeled right, I missed them. For application comparison, 
> was looking at  Juniper PIM configuration. The modules are using 
> draft-ietf-netmod-routing-cfg as base, and follows the 
> routing-instance-centric model, hence didn’t have problems mapping it 
> to Junos PIM config style. The model design by using base module and 
> build for each specific variant a separate module is a good approach, 
> as it enables simpler application of the modules by vendors and users.
>
> Throughout the draft authors are using abbreviations (many of them not 
> widely known) and the terminology section is not complete for PIM.  It 
> would be good to write them out when first time used in the text
>
> example,
>
> Why are the PIM related RFC not listed in the introduction section, as 
> there are clearly relations between the model and PIM related RFCs
>
> In chapter 2.2, why are you stating vendors will augment with required 
> restrictions, but features might be added
>
> It is expected that vendors will augment the model with any specific 
> extensions and restrictions needed to adapt it to their vendor 
> specific implementation.
>
> _______________________________________________
> netmod mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/netmod