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

[Xufeng Liu <[e-mail]>]

Thank Yisong for providing the valuable information. Some of my comments
are:

1. For operational states, we do not need to add constraints. As specified
in RFC8342, semantic constraints MAY be violated in the <operational>
datastore. The server implementations usually do not need to perform such
validations. Moreover, these leaves are not mandatory, so the server does
not need to return any values when the protocol version does not provide.
Such nodes include the “leave” nodes under “statistics”, and the “source”
sub-tree.

2. Based on RFC2236, the IGMPv2 spec requires the presence of the IP Router
Alert option. Should the default value of “require-router-alert” be “true”
for IGMPv2?

3. Should we restrict “ssm-map” sub-tree to IGMPv3/MLDv2 only?

4. We cannot avoid the “source-addr” in the “static-group” sub-tree because
it is a key for the list, but we may add a description to indicate that
(S,G) is only supported by IGMPv3/MLDv2.


Additional proposal:

As the discussions on Benjamin’s review comments, it is proposed to replace
“exclude-lite” with “lite-exclude-filter".

Thanks,

- Xufeng

On Thu, Jun 6, 2019 at 2:17 AM Liuyisong <[e-mail]> wrote:

> Hi
>
>
>
>         I have gone  through the parameters in IGMP & MLD yang model, and
> identified  the differences of the parameters based on version.
>
>
>
> Thanks
>
> Yisong
>
>
>
> *From:* Xufeng Liu [mailto:[e-mail]
> <[e-mail]>]
> *Sent:* Thursday, May 30, 2019 7:19 PM
> *To:* Suresh Krishnan <[e-mail]>
> *Cc:* The IESG <[e-mail]>; [e-mail];
> Stig Venaas <[e-mail]>; Alvaro Retana <[e-mail]>;
> [e-mail]; [e-mail]
> *Subject:* Re: Suresh Krishnan's No Objection on
> draft-ietf-pim-igmp-mld-yang-13: (with COMMENT)
>
>
>
> 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
>
>
>
> On Wed, May 29, 2019 at 6:04 PM Suresh Krishnan via Datatracker <
> [e-mail]> wrote:
>
> 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.
>
>