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

From: Suresh Krishnan via Datatracker <[email-masked]>
Date: Wed, 29 May 2019 15:04:05 -0700

Suresh Krishnan 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:
----------------------------------------------------------------------

I do have a general concern with the document in relation to its handling of
multiple protocol versions. There are features in the yang models that should
be conditional but they do not seem to be. Here are some examples.

* The source specific features are to be used with IGMPv3 and MLDv2 and will
not work with the earlier versions * The router alert check is not optional for
MLD or IGMPv3, but is required to be disabled for compatibility with earlier
versions of IGMP. I would also make this feature conditional on the IGMP
version. If not you need to rethink the defaults for this.

I would like to understand the authors' views on how they plan to address the
potential consistency issues due to these features being unbound in the model.
I would be fine if it is either addressed with yang constructs or with some
explanatory text to this point.

---

From: Xufeng Liu <[email-masked]>
Date: Thu, 30 May 2019 07:19:22 -0400

Hi Suresh,

Thanks for the review and comments. Some of the version check could be done
in YANG, while the concern was the complexity added to the model, with a
cost to the usability. The authors will examine these cases and address
them using either approach as suggested. Maybe some of them use YANG and
others use explanation descriptions. In the case of the explanation
description, the system can do the validation at the backend and provide
feedback.

Thanks,
- Xufeng