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

Xufeng Liu <> Thu, 23 May 2019 18:26 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id CED24120089; Thu, 23 May 2019 11:26:41 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.999
X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: (amavisd-new); dkim=pass (2048-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id d0IwQyD4RTcr; Thu, 23 May 2019 11:26:39 -0700 (PDT)
Received: from ( [IPv6:2607:f8b0:4864:20::d2b]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 6FFCA120043; Thu, 23 May 2019 11:26:39 -0700 (PDT)
Received: by with SMTP id q21so5624267iog.13; Thu, 23 May 2019 11:26:39 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=FICIBcO3x4+hWoKD596tUseewyoUc2DFiCol+8jvJu4=; b=LKXhRN7p6vpV5L+ppG4otrppmjwPlzzr4o6Xsn8QBmik91d+vq5V6ABUUAWyvE1bqc rlPf2VQU7ZOu9fOu9XQ/MzxOw6pQbujO9XXwjqVlLVS7hnJ7yM4xK0CdPiFMONwRova9 MhlGN5bTxp6a9wIIhfQ5Fb6doRMzLN/3jDnLZd8BbYBcWf06wz9QRzqZCytAg1+y6PVN oCwPA0WbmwjBU5JYu+1FDeDQZdapi03P+MNO4CyWskK/oh0N1nzksETQOgC166CuDki9 Uuc6Zs7MbkBzeuH0ppmIK7uXrUOyM0R9XXGl/U/MWMiaMPHH5oT+NJm2frFB8W3kdpdt HiOA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=FICIBcO3x4+hWoKD596tUseewyoUc2DFiCol+8jvJu4=; b=WRHmCZD7v/HA2q3kqZU9S8R2Nn9das2dnguUv6K+O6YBTakhOz9oMPgxAZfhSyQko8 JRc401hr3sXuvLNMQu2M9cOxGxEOBxiQUQNz3kPUqkpkbMbX7jSWlZh44zZGDF8iLy3d CeD9k3GFVUceRZjh2sY4VsSKUmRGtbqG6Ixc+73ypvnkk9QHWbDv1GGzXx4ZI30ENvT8 cAk10PkR6FSTOvB+E1wUfR/IQv/402/a76aj7TjLRGX4fme/bqgc4GefxkJZrCwH8wNp VQpXdrqZS8Zx3QLalrO7sCLd9qfuLSGZL+kZZOCruHtRNLAtXcm563ujSbOvPccYm0I1 ggjg==
X-Gm-Message-State: APjAAAUBTLj2mgMBHIDts0lfKo7DYqgpeFZghSlq4cqYBtmrUcPmPPis hL5933G8TgWNu+hVhfsRZ9eUvJfIEVuW8Y0Wi4Vf1LC0
X-Google-Smtp-Source: APXvYqxmpMCRQqT7dZqoKiQGl1tjbVAsNkNCILRLdD2iU3SDOzjE0qb3s2aMZ+sqtwPT0EXRc74rBlls3uoBT4yWDkU=
X-Received: by 2002:a5d:8357:: with SMTP id q23mr1984249ior.10.1558635998660; Thu, 23 May 2019 11:26:38 -0700 (PDT)
MIME-Version: 1.0
References: <>
In-Reply-To: <>
From: Xufeng Liu <>
Date: Thu, 23 May 2019 14:26:27 -0400
Message-ID: <>
To: =?UTF-8?B?w4lyaWMgVnluY2tl?= <>
Cc: The IESG <>,, Stig Venaas <>, Alvaro Retana <>,,
Content-Type: multipart/alternative; boundary="00000000000008cec9058992394c"
Archived-At: <>
Subject: Re: [pim] =?utf-8?q?=C3=89ric_Vyncke=27s_No_Objection_on_draft-ietf-?= =?utf-8?q?pim-igmp-mld-yang-12=3A_=28with_COMMENT=29?=
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Protocol Independent Multicast <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Thu, 23 May 2019 18:26:42 -0000

Hi Éric,

Thanks for the review. We have posted an updated revision, to address
these comments.

Best regards,
- Xufeng

On Mon, May 20, 2019 at 8:53 AM Éric Vyncke via Datatracker <> 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
> for more information about IESG DISCUSS and COMMENT positions.
> The document, along with other ballot positions, can be found here:
> ----------------------------------------------------------------------
> ----------------------------------------------------------------------
> 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

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