A YANG Data Model for Protocol Independent Multicast (PIM)

Note: This ballot was opened for revision 12 and is now closed.

(Benoît Claise) (was No Objection) Discuss

Discuss (2018-01-11 for -13)
Thanks to Jürgen, who reminded me that the YANG doctor feedback has not been addressed or replied to.
Comment (2018-01-11 for -13)
No email
send info
[removed the entries taken care of in version 13]

- Question for Alvaro, there is a normative reference to [I-D.ietf-bfd-yang]. 
What is the status?

     import ietf-bfd-types {
       prefix "bfd-types";

     grouping interface-config-attributes {
         "A grouping defining interface attributes.";
       container bfd {
         if-feature bfd;
           "BFD (Bidirectional Forwarding Detection) operation.";
         uses bfd-types:client-cfg-parms;

From https://tools.ietf.org/html/draft-ietf-bfd-yang-07
   grouping client-cfg-parms {
       "BFD grouping for config parameters
        used by clients of BFD, e.g. IGP or MPLS";

     leaf enable {
       type boolean;
       default false;
         "Indicates whether the BFD is enabled.";
     uses base-cfg-parms;

From Jürgen Schönwälder:

I have reviewed this document both as ops-dir reviewer and as yang doctor. A
more detailed review has been submitted as part of the yang doctor review. Here
I am focusing on more general questions from an operational perspective.

- There are a number of parameters without defined defaults. Is the
  idea that every vendor augments in their defaults? Would it not
  overall be simpler if the PIM WG can find agreement on common
  defaults? (Vendors can still publish deviations I think.)

- I wonder how these YANG modules relate to the PIM MIB modules. Are
  for example counters the same or different? I think it would be good
  if the text would discuss relationship of the YANG modules relate to
  corresponding MIB modules.

-  There are no example configurations provided, demonstration how, for
  example, a simple PIM installation would be configured is not
  present in the document (e.g., as an appendix).

Alvaro Retana Yes

(Alia Atlas) No Objection

(Deborah Brungard) No Objection

(Ben Campbell) (was Discuss) No Objection

Comment (2018-01-10 for -12)
No email
send info
[This was originally a DISCUSS. I've cleared because, as Alvaro pointed out,  we've referenced this same experimental RFC in an standards track MIB. But I think the question of what it means in general for a Yang module to be of higher maturity than the protocol it models still stands in the general case. I don't expect that to change for _this_ particular document. ]

Is it reasonable to have a Yang module for an experimental protocol in a standards track RFC? What would that mean from a protocol maturity perspective? (I refer to the module for dense-mode PIM (RFC 3973).

(Alissa Cooper) No Objection

(Spencer Dawkins) No Objection

(Suresh Krishnan) No Objection

Warren Kumari No Objection

(Mirja Kühlewind) No Objection

Comment (2018-01-05 for -12)
No email
send info
I don't know what the convention is but this doc does not contain the section describing the tree diagram syntax that YANG docs usually have. Is the agreement to have that in all YANG docs or is it okay to omit it?

(Alexey Melnikov) No Objection

(Kathleen Moriarty) (was Discuss) No Objection

Comment (2018-01-10 for -13)
No email
send info
Thanks for using the template for the security considerations.

(Adam Roach) No Objection

Comment (2018-01-10 for -13)
No email
send info
This document has the most legible and thoroughly-cited acronym list I think I've ever seen. Thank you so much for taking the extra effort.