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

From: Roman Danyliw via Datatracker <[email-masked]>
Date: Mon, 06 Jul 2020 09:13:16 -0700

Roman Danyliw has entered the following ballot position for
draft-ietf-pim-igmp-mld-snooping-yang-15: 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-snooping-yang/

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

** It caught me by surprise for a standards track document not to use RFC2119
words in a normative way

** Section 2.2.  Per “On the other hand, operational state parameters are not
so widely designated as features …”, I didn’t follow the intent of this
paragraph.  I’m not sure what it means to designate a operational state
parameter.

** Section 5.  It would be worth noting that devices that use this YANG model
should heed the Security Considerations in Section 6 of RFC4541.

** Section 5.  Per “If unauthorized action is invoked, the IGMP and MLD
Snooping group tables will be cleared unexpectedly”, could the impact of this
table flush please be explicitly stated.

** Editorial

-- Section 2.  Editorial. s/to avoid bandwidth waste/to avoid wasting bandwidth/
-- Section 5.  Editorial.  The sentence “Some of the actions in this YANG
module may be considered sensitive or vulnerable in some network environments.
“ appears to be included twice.  It’s only needed once.

---

From: Hongji Zhao <[email-masked]>
Date: Tue, 7 Jul 2020 07:37:57 +0000

Hi Roman,

Thanks a lot for your supporting and comments. We have already addressed your comments and submitted as draft-ietf-pim-igmp-mld-snooping-yang-16.

We define some features. Most of them are defined for configuration parameters, and few of them are for operational state parameters. 
The operational state default value would not cause any harm to the system. If an operational state variable is not natively supported, the default value could be derived.

BR/Hongji

-----Original Message-----
From: Roman Danyliw via Datatracker <[email-masked]> 
Sent: Tuesday, July 7, 2020 12:13 AM
To: The IESG <[email-masked]>
Cc: [email-masked]; [email-masked]; [email-masked]; Stig Venaas <[email-masked]>; [email-masked]; [email-masked]
Subject: Roman Danyliw's No Objection on draft-ietf-pim-igmp-mld-snooping-yang-15: (with COMMENT)

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.)

** It caught me by surprise for a standards track document not to use RFC2119 words in a normative way

** Section 2.2.  Per “On the other hand, operational state parameters are not so widely designated as features …”, I didn’t follow the intent of this paragraph.  I’m not sure what it means to designate a operational state parameter.

** Section 5.  It would be worth noting that devices that use this YANG model should heed the Security Considerations in Section 6 of RFC4541.

** Section 5.  Per “If unauthorized action is invoked, the IGMP and MLD Snooping group tables will be cleared unexpectedly”, could the impact of this table flush please be explicitly stated.

** Editorial

-- Section 2.  Editorial. s/to avoid bandwidth waste/to avoid wasting bandwidth/
-- Section 5.  Editorial.  The sentence “Some of the actions in this YANG module may be considered sensitive or vulnerable in some network environments.
“ appears to be included twice.  It’s only needed once.