Re: [pim] Last Call: <draft-ietf-pim-igmp-mld-yang-10.txt> (A YANG data model for Internet Group Management Protocol (IGMP) and Multicast Listener Discovery (MLD)) to Proposed Standard

Xufeng Liu <xufeng.liu.ietf@gmail.com> Thu, 09 May 2019 14:10 UTC

Return-Path: <xufeng.liu.ietf@gmail.com>
X-Original-To: pim@ietfa.amsl.com
Delivered-To: pim@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 83C9D12004C; Thu, 9 May 2019 07:10:44 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.999
X-Spam-Level:
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: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zQLJHjbyzHOc; Thu, 9 May 2019 07:10:40 -0700 (PDT)
Received: from mail-io1-xd2d.google.com (mail-io1-xd2d.google.com [IPv6:2607:f8b0:4864:20::d2d]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7FD4C120118; Thu, 9 May 2019 07:10:40 -0700 (PDT)
Received: by mail-io1-xd2d.google.com with SMTP id m7so1703870ioa.6; Thu, 09 May 2019 07:10:40 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=eq9g1gffZTM9ATJ12W4676D92G5pcPqk3sZX4dvQlaY=; b=TknOiLUs7o1mm0U0woF5VWAgc0W7KPFMIyIr7Uw4xovHQNaakdqc1HQu4w9rxskNDq mZ/5Fs/8xGjBOp9kEPjUJ+QK0iSl8cINeho/fhIpSiVS97yVkIxsFpVBiourv+/MiyZt icj47Kjxs9S6q1qYBTf5opFQUhEZ1zQAYkcveLHjz3hFxQ1y+KeU/kYh5+THOrF96HrL vjo5JlT4/mhQ3HC9W/xO4p3OEelZx0OH90gyA13ksE05vJf6rarhxUZjnI6Al+x3sJir 2nIBCTy26tWTw8q9kI7hzcJEHjqBy8LGhS4NtqjkAicVTKZ32q5+lK/9I9jNLK2MAb0X gMWA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=eq9g1gffZTM9ATJ12W4676D92G5pcPqk3sZX4dvQlaY=; b=dWIHH4llrEhKKhiMOXtCo1LP2OOlOp6v+5Q2hOa1IFnYHRfCLLKakpqvp8eC64oojI E3rfhjWP4iS+vgjGLhpfq6HffkD5s1JnxNJ3cspIp2nQY6HAJCkLuYptbluSVTwfu+lP i4mHUpGe3f1qdHek0Z9XSsNnHJQjkSKosP9lqoU0MK6KnTmXZ8K5me/N8lVeKzwBYZXj z6YCpRBe3UsW2COQhlErXO7Les7Ie10U4lnbrtWnZttWUmLlWilvnLU/4YaCB1iWGSm3 YB8AIwxITh9d33KqnR2ze/wcvk5BRgYJPBFMBWExYFoyVS3XHcuzauizM/jMm5xPGZsG bXAQ==
X-Gm-Message-State: APjAAAXCZ5pgRX17LngoHJfg9lCSFVwUtJ/EwG8wQSOB+remdqRXUdxS OgzS6ttumahNuY9V4rDcpl/X220gzCDtDHo7TRA=
X-Google-Smtp-Source: APXvYqzA7OOx6s+YEIrAyUPjfuCXPHmY8aYZeZBlcCm6Nro4Nivx/dUllN6xVZCLlYD2J+UlKesKJwK4ZeOzxX8J9FI=
X-Received: by 2002:a6b:37c2:: with SMTP id e185mr2513719ioa.143.1557411039628; Thu, 09 May 2019 07:10:39 -0700 (PDT)
MIME-Version: 1.0
References: <154844808422.29188.6676721895526799.idtracker@ietfa.amsl.com> <016301d4b598$12950700$4001a8c0@gateway.2wire.net> <01cc01d4b897$017f9d20$4001a8c0@gateway.2wire.net> <CAEz6PPQXHvG2A8Q_RhgyEbKBx0DK4ZHjZh9eMMwMh84rE9QVpw@mail.gmail.com> <04c601d4ff3d$77e3e920$4001a8c0@gateway.2wire.net>
In-Reply-To: <04c601d4ff3d$77e3e920$4001a8c0@gateway.2wire.net>
From: Xufeng Liu <xufeng.liu.ietf@gmail.com>
Date: Thu, 9 May 2019 10:10:28 -0400
Message-ID: <CAEz6PPTzbomdDYuYr3nwzs+Q=k7sCPSOnxXfppXPkwj9xyRzGQ@mail.gmail.com>
To: tom petch <daedulus@btconnect.com>
Cc: "ietf@ietf.org" <ietf@ietf.org>, "pim-chairs@ietf.org" <pim-chairs@ietf.org>, "draft-ietf-pim-igmp-mld-yang@ietf.org" <draft-ietf-pim-igmp-mld-yang@ietf.org>, "pim@ietf.org" <pim@ietf.org>
Content-Type: multipart/alternative; boundary="000000000000c9545005887503d9"
Archived-At: <https://mailarchive.ietf.org/arch/msg/pim/qqnpHBPfnid-5sVjMSF_PsN1WeI>
Subject: Re: [pim] Last Call: <draft-ietf-pim-igmp-mld-yang-10.txt> (A YANG data model for Internet Group Management Protocol (IGMP) and Multicast Listener Discovery (MLD)) to Proposed Standard
X-BeenThere: pim@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Protocol Independent Multicast <pim.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/pim>, <mailto:pim-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/pim/>
List-Post: <mailto:pim@ietf.org>
List-Help: <mailto:pim-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/pim>, <mailto:pim-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 09 May 2019 14:10:45 -0000

Hi Tom,

Thanks for the further comments. The fixes have been posted at
https://tools.ietf.org/html/draft-ietf-pim-igmp-mld-yang-12.

Best regards,
- Xufeng

On Tue, Apr 30, 2019 at 6:17 AM tom petch <daedulus@btconnect.com>; wrote:

> Yes, much revised, much clearer to me.
>
> A few small glitches
>
> "   The terminology for describing YANG data models is found in
>    [RFC6020] and [RFC7950]."
>
> The terminology keeps moving on.  If you look at RFC8341, you can see a
> more expansive summary of the terminology; I have not been through and
> checked it but, knowing the author, it is unlikely I could find fault
> with it:-)  I am not saying use it, but it is worth thinking about.
> YANG Guidelines says there must be a Terminology section but not what
> must be in it.
>
[Xufeng]: Fortunately the YANG terms used in this document are
traditionally stable ones. I do agree that listing some terms would benefit
the readers by the convenience and clarity. We have listed a few ones that
are important to this document and have been used many times.

>
> ACL is now RFC8519 which you have in the list of prefixes but not in the
> References for the I-D
>
[Xufeng]: Fixed the reference.

>
> s.3.1
> " The identity "igmp" derived from  the "rt:control-plane-protocol" base
> identity is defined to indicate   a control-plane-protocol instance is
> for IGMP.
> "
>
> Not clear what this is saying; perhaps
>
> The identity "igmp" is derived from
>    the "rt:control-plane-protocol" base identity and indicates that
>    a control-plane-protocol instance is IGMP.
>
[Xufeng]: Right. Fixed as suggested.

>
> s.3.2 likewise for mld
>
[Xufeng]: Fixed.

>
> In passing, can there be more than one IGMP or MLD instance in a router
> or not?  I do not know the answer to that; OSPF, e.g., can and I see
> that, BGP can but I do not; this would affect the English in some places
>
[Xufeng]: This model allows multiple instances because of the augmented
module ietf-routing and its convention in [RFC8349]. Usual implementations
do not allow multiple instances, in which case the restriction may be added
to the model during implementation. I went through the text, and the
descriptions seem to be ok. Two sentences have been added to make this
explicit.

>
>
> "       leaf group-policy {
>          type leafref {
>            path "/acl:acls/acl:acl/acl:name";
> "
> could do with a reference to RFC8519; and since the RFC says
>
> " length "1..64";
>         }
>         description
>           "The name of the access list.  A device MAY further
>            restrict the length of this name; space and special
>            characters are not allowed.";
> "
>
> then I think the description needs to reflect that.  A device can
> restrict the length but cannot be greater than the 64 of the RFC.  And
> the RFC bans space and special characters - again, the device cannot
> gainsay that (unless you are into deviations which are a bad thing IMO).
>
[Xufeng]: Modified as suggested.

>
> "     rpc clear-igmp-groups {
> ...
>               If it is not specified, IGMP groups from all interfaces
>               are cleared.";
> "
> Mmm is this wise?  it is fail danger, someone makes a mistake and all it
> lost.  I wonder if there should be a default which the user has to
> wilfully override in order to clear everything.  Something to ponder.
>
> "     rpc clear-mld-groups { "
> ditto
>
[Xufeng]: Glad that you brought this up. Using unspecified argument to
clear all entries is convenient and often implemented. However, as you
mentioned, the fail danger does exist. We have modified the parameters to
use explicit “all-interfaces” instead of empty interface name, and the
special value “*” to indicate all addresses.

>
> Reference
>
> "   [RFC8407] Bierman, A., "Guidelines for Authors and Reviewers of YANG
>              Data Model Documents", draft-ietf-netmod-rfc6087bis-
>              20(work in progress), March 2018.
> "
> Um, nearly but not quite:-)
>
[Xufeng]: Fixed.

>
> Tom Petch
>
>
> ---- Original Message -----
> From: "Xufeng Liu" <xufeng.liu.ietf@gmail.com>;
> Sent: Monday, April 29, 2019 4:51 PM
>
> Hi Tom,
>
> Thanks for the comments. We have posted the updated
> https://tools.ietf.org/html/draft-ietf-pim-igmp-mld-yang-11 to address
> these issues, along with other review comments.
> Best regards,
> - Xufeng
>
> On Wed, Jan 30, 2019 at 7:27 AM tom petch <daedulus@btconnect.com>;
> wrote:
>
> > Looking into the technical aspects of this, I am inclined to think
> that
> > it is not ready to become an RFC, needing widespread revision; the
> > problem is the language.  In places, I can guess what is meant, in
> > others, I cannot.  An example of the latter is
> > "Interface-global: Only including configuration data nodes that
> >    IGMP configuration attributes are applicable to all the interfaces
> >    whose interface-level corresponding attributes are not existing,
> >    with same attributes' value for these interfaces."
> > which is differentiated from "Global level" and "Interface-level".
> That
> > combination of 'not existing' and 'same value' leaves me uncertain as
> to
> > the meaning.
> >
> [Xufeng]: Rephrased a bit to see if the description is improved.
>
> >
> > (When these terms are used in the YANG descriptions, the hyphens are
> > missing).
> >
> > 'Global level' (no hyphen) is defined as "configuration and
> operational
> > state attributes for the entire routing system."  Is that the entire
> > routing system of all routers and hosts? or just everything regardless
> > of protocol in this router? or just IGMP in this router?  ...
> >
> [Xufeng]: Should be just the IGMP instance in this router. Fixed.
>
> >
> > SSM/ssm appears in dozens of places and is never expanded nor is there
> a
> > single reference.  I imagine that this is RFC3569 in which case, that
> > must be a Normative Reference.
> >
> [Xufeng]: Right. Added an entry in Sec 1.1, and added the references
> ([RFC3569] and [RFC4607])
>
> >
> > 'IGMP or MLD' appears in a dozen places and gives me the most
> heartache;
> > I do not know what it means.  Thus
> > "The maximum number of entries in IGMP or MLD.";
> > could be a maximum for IGMP which is also a maximum for MLD, same
> value;
> > or it could mean the maximum for IGMP or MLD combined, regardless of
> > which.  I cannot tell which is meant
> >
> [Xufeng]: I think that the confusion comes from the fact that such a
> grouping is used in either IGMP schema or MLD schema. It could be better
> to
> split above statement into two separate statements: one for IGMP and one
> for MLD. The document has been updated for all such occurrences.
>
> >
> > Likewise, with
> > grouping global-config-attributes/ leaf enable /type boolean;
> > you have enable or disable coupled with IGMP and MLD; that is four
> > choices, while a boolean only has two values - does not compute.
> >
> > Ditto
> >
> [Xufeng]: Fixed in the same way as above.
>
> > grouping interface-specific-config-attributes / leaf enable / type
> > boolean
> >
> > Is interface specific the same as interface level?
> >
> [Xufeng]: Yes. For consistency, it has been renamed to
> “interface-level-...
> ”.
>
> >
> > Interestingly, where I was expecting ambiguity,
> > leaf discontinuity-time
> > ...
> > description "The time on the most recent occasion at which any one
> >               or more of the statistic counters suffered a
> >               discontinuity. "
> > is perfectly clear; that ' any one or more' leaves me in no doubt.
> >
> > IGMP and MLD do get expanded on first use but it would be helpful to
> > have the RFC reference there - you give it for YANG (surely everyone
> > knows those RFC numbers off by heart by now:-) but not for the less
> > widely used MLD.
> >
> [Xufeng]: I think that you mean the first use in the YANG module, whose
> description has be updated as such.
>
> >
> > And then there are many places where the English is understandable but
> > quirky and might be left to the RFC Editor but here, probably worth
> > changing sooner rather than later; e.g.
> >
> > - not all included in this document of the data model
> > - including some with basic subsets of the IGMP and MLD protocols.
> > - any major now-existing implementation may be said to support the
> basic
> > model
> > - operational state parameters are not so widely designated as
> features
> > - Where fields are not genuinely essential to protocol operation
> > - The MLD YANG model uses the same structure as IGMP YANG model
> > - MLD module also defines in a three-level hierarchy structure
> > - IGMP and MLD RPC clears
> > - group-addrss?
> > - definitions common for IGMP and MLD
> > - whose are not existing in interface global level
> > - it prunes off the group
> > - that IGMP ro MLD can join
> > - If present, IGMP/MLD-based explicit membership tracking function for
> > multicast routers and IGMP/MLD proxy devices supporting IGMPv3/MLDv2.
> > - lightweight IGMPv3 and MLDv2 protocols will run on the which
> simplify
> > the
> > - List of multicast membership hosts
> > - The last host address which has sent the report to
> > - the MLD attributes at all of the interfaces level on a device
> >
> [Xufeng]: Went through these, and did some adjustments. Please let us
> know
> for any further issues.
>
> >
> > HTH:-(
> >
> > Tom Petch
> >
> >
> > ----- Original Message -----
> > From: "tom petch" <daedulus@btconnect.com>;
> >
> > Sent: Saturday, January 26, 2019 4:57 PM
> >
> >
> > > Some initial  thoughts on this I-D
> > >
> > > Prefer 'Abstract' before 'Copyright' and 'Status'
> > >
> > >    | acl       | ietf-access-control-list | [I-D.ietf-acl-yang] |
> > > better to have
> > >    | acl       | ietf-access-control-list | [RFC YYYY] |
> > > Note to RFC Editor please replace YYYY with number assigned to
> draft-
> > > ietf-netmod-acl-model
> > >
> > > YANG module needs the Copyright statement
> > >
> > > 4. IGMP and MLD YANG Modules
> > > suggests that there are two modules but I only see one
> > >
> > >       import ietf-inet-types {
> > > and other imports need a reference clause to identify the RFC; for
> acl
> > > you need such as
> > > RFC YYYY "Network Access Control List (ACL) YANG Data Model",
> > > Note to RFC Editor please replace YYYY with number assigned to
> draft-
> > > ietf-netmod-acl-model
> > > ( you can put all RFC Editor Notes in one place at the front - they
> > > prefer it this way)
> > >
> > >       revision 2019-01-03 {
> > > there must only be one revision clause stating 'Initial revision'
> with
> > > date of publication supplied by RFC Editor to match that on the file
> > > statement
> > >
> > > several lines are too long e.g.
> > >              If QQIC >= 128, QQIC represents a floating-point value
> as
> > > follows:
> > >
> > > 5. Security Considerations
> > >    transport is TLS [RFC5246].
> > > this is now superseded
> > >
> > > 6. IANA Considerations
> > >    Names registry [RFC7950]:
> > > this is a poor reference since all it does is tell you to go to
> > RFC6020;
> > > better to tell the reader to go straight there.
> > >
> > >    [I-D.ietf-netmod-rfc6087bis] Bierman, A., "Guidelines for Authors
> > > this is now out of date - RFC8407
> > > (and it tells you to do most of what I have listed above:-)
> > >
> > > Tom Petch
> > >
> > > ----- Original Message -----
> > > From: "The IESG" <iesg-secretary@ietf.org>;
> > > To: "IETF-Announce" <ietf-announce@ietf.org>;
> > > Cc: <pim-chairs@ietf.org>;; <pim@ietf.org>;;
> > > <draft-ietf-pim-igmp-mld-yang@ietf.org>;
> > > Sent: Friday, January 25, 2019 8:28 PM
> > >
> > > > The IESG has received a request from the Protocols for IP
> Multicast
> > WG
> > > (pim)
> > > > to consider the following document: - 'A YANG data model for
> > Internet
> > > Group
> > > > Management Protocol (IGMP) and
> > > >    Multicast Listener Discovery (MLD)'
> > > >   <draft-ietf-pim-igmp-mld-yang-10.txt> as Proposed Standard
> > > >
> > > > The IESG plans to make a decision in the next few weeks, and
> > solicits
> > > final
> > > > comments on this action. Please send substantive comments to the
> > > > ietf@ietf.org mailing lists by 2019-02-08. Exceptionally, comments
> > may
> > > be
> > > > sent to iesg@ietf.org instead. In either case, please retain the
> > > beginning of
> > > > the Subject line to allow automated sorting.
> > > >
> > > > Abstract
> > > >
> > > >
> > > >    This document defines a YANG data model that can be used to
> > > >    configure and manage Internet Group Management Protocol (IGMP)
> > and
> > > >    Multicast Listener Discovery (MLD) devices.
> > > >
> > > > The file can be obtained via
> > > > https://datatracker.ietf.org/doc/draft-ietf-pim-igmp-mld-yang/
> > > >
> > > > IESG discussion can be tracked via
> > > >
> > https://datatracker.ietf.org/doc/draft-ietf-pim-igmp-mld-yang/ballot/
> > > >
> > > >
> > > > No IPR declarations have been submitted directly on this I-D.
>
>