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

[Xufeng Liu <[e-mail]>]

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 <
[e-mail]> wrote:

> É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.
>
[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 --
>
> 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.
>
[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.


> == NITS ==
>
> -- Section 1 --
>
> Add a reference to NMDA (expanding the acronym is not really sufficient,
> state
> RFC 8342) ?
>
[Xufeng]: Added the reference.

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