[pim] Roman Danyliw's No Objection on draft-ietf-pim-igmp-mld-yang-13: (with COMMENT)

[Roman Danyliw via Datatracker <[e-mail]>]

Roman Danyliw has entered the following ballot position for
draft-ietf-pim-igmp-mld-yang-13: No Objection

When responding, please keep the subject line intact and reply to all
email addresses included in the To and CC lines. (Feel free to cut this
introductory paragraph, however.)


Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html
for more information about IESG DISCUSS and COMMENT positions.


The document, along with other ballot positions, can be found here:
https://datatracker.ietf.org/doc/draft-ietf-pim-igmp-mld-yang/



----------------------------------------------------------------------
COMMENT:
----------------------------------------------------------------------

(1) I support Ben Kaduk’s DISCUSS about privacy considerations.

(2) Thanks for Section 1.3.  This upfront cross-reference was very helpful!

(3) Section 2.2.
   On the other hand, operational state parameters are not so widely
   designated as features, as there are many cases where the defaulting
   of an operational state parameter would not cause any harm to the
   system, and it is much more likely that an implementation without
   native support for a piece of operational state would be able to
   derive a suitable value for a state variable that is not natively
   supported.

I struggled to understand this very dense single sentence paragraph.
-- What does it mean for “operational state parameters are not so widely
designated as features”? -- What is a “defaulting of an operational state
parameter”?

(4) Section 3.  Does the sentence “This model augments the core routing data
model specification in [RFC8349]” suggest that this draft should update
[RFC8349]?

(5) Reference Nits
** Section 1.  I would have expected a reference to NMDA (i.e., [RFC8342]). 
This is done later in the draft but not the first time it is mentioned (here).

** idnits returned the following valid reference issues:

  == Missing Reference: 'I-D.ietf-netconf-yang-push' is mentioned on line
     178, but not defined

  == Missing Reference: 'RFC 8446' is mentioned on line 1910, but not defined

  == Missing Reference: 'RFC8341' is mentioned on line 1912, but not defined

  == Unused Reference: 'RFC5246' is defined on line 2085, but no explicit
     reference was found in the text

  == Unused Reference: 'RFC6536' is defined on line 2099, but no explicit
     reference was found in the text

  == Unused Reference: 'RFC5790' is defined on line 2145, but no explicit
     reference was found in the text

  ** Downref: Normative reference to an Informational RFC: RFC 3569

  ** Obsolete normative reference: RFC 5246 (Obsoleted by RFC 8446)

  ** Obsolete normative reference: RFC 6536 (Obsoleted by RFC 8341)

(6) Editorial Nits

** Section 2.1.  The sentence “Even though there is no protocol specific
notifications are defined in this model, the subscription and push mechanism
defined in [I-D.ietf-netconf-subscribed-   notifications] and
[I-D.ietf-netconf-yang-push]” doesn’t parse.  Likely remove the “are”.

** Section 2.1.  Per the sentence “Depending on the implementation choices,
some systems may not allow some of the advanced parameters   configurable”,
what is a “advanced parameters configurable”?  I think there is a typo there.

**  Section 2.3.  Per “The current document defines …”, shouldn’t this just be
“The document defines …” since when published as an RFC there would be no
notion of versioning as suggested by “current”?

** Section 2.3.  s/supports and only supports/only supports/

** Section 4.  Typo.  s/refered/referred/

** Section 4. Missing space.  /Querier.In RFC3376,/Querier. In RFC3376,/