Subject: [pim] Mirja Kühlewind's No Objection on draft-ietf-pim-igmp-mld-yang-13: (with COMMENT)

From: Mirja Kühlewind via Datatracker <[email-masked]>
Date: Fri, 24 May 2019 10:37:17 -0700

Mirja Kühlewind 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:
----------------------------------------------------------------------

Two quick questions:

1) Not sure about the current practice about YANG models but shouldn’t this
document eventually update RFC8349?

2) Also maybe it would make sense to discuss the sensitivity of
explicit-tracking separately in the security consideration section?

---

From: Xufeng Liu <[email-masked]>
Date: Tue, 28 May 2019 10:04:19 -0400

Hi Mirja,

Thanks for the review. We have proposed the changes in details below.
Regards,
- Xufeng

> https://datatracker.ietf.org/doc/draft-ietf-pim-igmp-mld-yang/
[Xufeng]:  The current practice is not to update RFC8349, but to reference
it.

> explicit-tracking separately in the security consideration section?
[Xufeng]: Since RFC6636 does not describe the security risks in details, we
can add the following to this this document.

[OLD]:5. Security Considerations
  igmp-mold:interfaces/interface

     This subtree specifies the configuration for the IGMP attributes
     at the interface level on an IGMP instance.  Modifying the
     configuration can cause IGMP membership deleted or reconstructed
     on a specific interface of an IGMP instance.[NEW]:5. Security
Considerations
  igmp-mold:interfaces/interface

     This subtree specifies the configuration for the IGMP attributes
     at the interface level on an IGMP instance.  Modifying the
     configuration can cause IGMP membership deleted or reconstructed
     on a specific interface of an IGMP instance.The explicit-tracking
leaf enables the explicit membership tracking function on this
multicast router. Enabling this function will cause the router to
record more multicast membership information including all hosts that
receive multicast messages.
[OLD]:      /rt:routing/rt:control-plane-protocols
   /rt:control-plane-protocol/igmmp-mld:igmp

   /rt:routing/rt:control-plane-protocols
   /rt:control-plane-protocol/igmp-mld:mld

   Unauthorized access to any data node of the above subtree can
   disclose the operational state information of IGMP or MLD on this
   device.[NEW]:      /rt:routing/rt:control-plane-protocols
   /rt:control-plane-protocol/igmmp-mld:igmp

   /rt:routing/rt:control-plane-protocols
   /rt:control-plane-protocol/igmp-mld:mld

   Unauthorized access to any data node of the above subtree can
   disclose the operational state information of IGMP or MLD on this
   device.Under /rt:routing/rt:control-plane-protocols
/rt:control-plane-protocol/igmp-mld:igmp,
and /rt:routing/rt:control-plane-protocols
/rt:control-plane-protocol/igmp-mld:mld,
igmp-mLd:interfaces/interfaceThe explicit-tracking leaf shows whether
the explicit membership tracking function is enabled on this multicast
router. When this function is enabled, the sub-tree group/source/host
contains the membership information of all the hosts that receive
multicast messages. Unauthorized access to this sub-tree may disclose
such information.
In addition, we will RFC6636 to the reference list, and add a
“reference” statement to the description of the leaf
“explicit-tracking” in the model.

Is it ok to make such changes?

Thanks,

- Xufeng