Subject: [pim] Éric Vyncke's No Objection on draft-ietf-pim-igmp-mld-yang-12: (with COMMENT)

From: Éric Vyncke via Datatracker <[email-masked]>
Date: Mon, 20 May 2019 05:53:46 -0700

Éric Vyncke has entered the following ballot position for
draft-ietf-pim-igmp-mld-yang-12: 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:
----------------------------------------------------------------------

Thanks for the work everyone has put into this document.

I only have a couple of comments (but one important one about the 2 branches)
and a couple of nits.

== COMMENTS ==

-- Section 2.1.1 and section 2.1.2 --

Those sections are about configuration parameters not covered at global or
interface level. But, what about operational states, can the reader assume that
they are all covered by this document ? It is really unclear.

-- Section 2.3 --

As I am not a multicast expert, I did not put a DISCUSS on this one. But, are
MLD and IGMP so different? Why having TWO different branches for each address
family... For SNMP, RFC 4292/4293 was made protocol version independent which
is a big plus IMHO for operations. In any case, there should be more
explanations why there are two branches than the one paragraph/two sentences in
section 2.3. Moreover, it seems that the two schema branches are quite similar
so having one protocol version independent branch appears to be doable.

== NITS ==

-- Section 1 --

Add a reference to NMDA (expanding the acronym is not really sufficient, state
RFC 8342) ?

Expand CLI even if well-known.

---

From: Xufeng Liu <[email-masked]>
Date: Thu, 23 May 2019 14:26:27 -0400

Hi Éric,

Thanks for the review. We have posted an updated revision
https://tools.ietf.org/html/draft-ietf-pim-igmp-mld-yang-13, to address
these comments.

Best regards,
- Xufeng

> https://datatracker.ietf.org/doc/draft-ietf-pim-igmp-mld-yang/
[Xufeng]: These parameters should cover both configuration parameters and
operational states. Since we are following NMDA structure, the same
parameter can be for both configuration and operational state. We have
changed the phrase “The configuration parameters” to “The configuration
parameters and operational states”.

> so having one protocol version independent branch appears to be doable.
[Xufeng]: We agree that one branch is doable, but the current structure
reflects the result of the discussions from the design team and working
group. The reasons are:

- The model can support IGMP, MLD, or both optionally and independently.
Such a flexibility cannot be achieved cleanly with a combined branch.

- The structure is consistent with other YANG models such as RFC8344, which
uses separate branches for ipv4 and ipv6. It is true that some SNMP modules
are address-family-independent, such as ipForward in RFC4292, but there are
also address-family-separated objects like
ipv4InterfaceTable/ipv6InterfaceTable in RFC4293. IGMP and MLD are
specified as separate protocols, specified as separate RFCs. Naturally
separate protocol identities can be defined for each. This is similar to
the structures specified for OSPFv2 and OSPFv3, in
*https://tools.ietf.org/html/draft-ietf-ospf-yang
<https://tools.ietf.org/html/draft-ietf-ospf-yang>*.

- The separate branches for IGMP and MLD can accommodate their differences
better and cleaner. The two branches can better support different features
and node types.

We have expanded the text a bit more to explain.

> Add a reference to NMDA (expanding the acronym is not really sufficient,
[Xufeng]: Added the reference.

> Expand CLI even if well-known.
[Xufeng]: Modified as suggested.

---

From: "Eric Vyncke (evyncke)" <[email-masked]>
Date: Fri, 24 May 2019 07:24:24 +0000

Xufeng

Thank you for the updated document and the actions on my comments.

I am still unsure whether having two branches (IPv4 & IPv6) is the right thing to do but I am trusting the WG as well as the YANG doctors on this topic.

Regards

-éric

From: Xufeng Liu <[email-masked]>
Date: Thursday, 23 May 2019 at 20:26
To: Eric Vyncke <[email-masked]>
Cc: The IESG <[email-masked]>, "[email-masked]" <[email-masked]>, Stig Venaas <[email-masked]>, Alvaro Retana <[email-masked]>, "[email-masked]" <[email-masked]>, "[email-masked]" <[email-masked]>
Subject: Re: Éric Vyncke's No Objection on draft-ietf-pim-igmp-mld-yang-12: (with COMMENT)

Hi Éric,

Thanks for the review. We have posted an updated revision https://tools.ietf.org/html/draft-ietf-pim-igmp-mld-yang-13, to address these comments.

Best regards,
- Xufeng

On Mon, May 20, 2019 at 8:53 AM Éric Vyncke via Datatracker <[email-masked]<mailto:[email-masked]>> wrote:
Éric Vyncke has entered the following ballot position for
draft-ietf-pim-igmp-mld-yang-12: No Objection

== COMMENTS ==

[Xufeng]: These parameters should cover both configuration parameters and operational states. Since we are following NMDA structure, the same parameter can be for both configuration and operational state. We have changed the phrase “The configuration parameters” to “The configuration parameters and operational states”.

-- Section 2.3 --

[Xufeng]: We agree that one branch is doable, but the current structure reflects the result of the discussions from the design team and working group. The reasons are:

- The model can support IGMP, MLD, or both optionally and independently. Such a flexibility cannot be achieved cleanly with a combined branch.

- The structure is consistent with other YANG models such as RFC8344, which uses separate branches for ipv4 and ipv6. It is true that some SNMP modules are address-family-independent, such as ipForward in RFC4292, but there are also address-family-separated objects like ipv4InterfaceTable/ipv6InterfaceTable in RFC4293. IGMP and MLD are specified as separate protocols, specified as separate RFCs. Naturally separate protocol identities can be defined for each. This is similar to the structures specified for OSPFv2 and OSPFv3, in https://tools.ietf.org/html/draft-ietf-ospf-yang.

- The separate branches for IGMP and MLD can accommodate their differences better and cleaner. The two branches can better support different features and node types.

== NITS ==

-- Section 1 --