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> Mon, 29 April 2019 15:52 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 792561200F9; Mon, 29 Apr 2019 08:52:03 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.998
X-Spam-Level:
X-Spam-Status: No, score=-1.998 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, URIBL_BLOCKED=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 YgG7eMWMnstL; Mon, 29 Apr 2019 08:52:00 -0700 (PDT)
Received: from mail-io1-xd43.google.com (mail-io1-xd43.google.com [IPv6:2607:f8b0:4864:20::d43]) (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 D19DC120086; Mon, 29 Apr 2019 08:51:59 -0700 (PDT)
Received: by mail-io1-xd43.google.com with SMTP id v9so9358567iol.10; Mon, 29 Apr 2019 08:51:59 -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=hOsm1LNTogF2ne0h9+mKOBBsQo6G/srbzhToOHkqcVs=; b=fJCC/ZPEBbVfPXu5hT9lOapyj65AuoQYJS04pkn5OmaxnfgvA9iTOw6DHu7VQH2PJa F4D+xDFb7InGjJ4xvUov83BQvw5pDDqnFaFf4G4WZeCOAU9+YdsicBZYYB/SxVlfLcur SLCRFYWFl5xK0b5WoLPkYevdTaIShF6EQ9obQmtCSSS3i2v5sZh0rqZkvj5NyhyF/YOr PxpDpvLprScauMS532NniqicEcGdCZ+LWcPVpUe1+lfCBym2D9N47f+X2bhBcEfekARU YwFaWbrasAY4uk+UESLXHYhViytmvuxpxmYKGLcnigizMjkkOI5fJELKTJNn6hypeWTI fIOA==
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=hOsm1LNTogF2ne0h9+mKOBBsQo6G/srbzhToOHkqcVs=; b=jnmw+nXvw67zAnwcKeRduRFnFDSulH6GR8+9tXq1VtR3VNGOXzPSxmCF3e/WoGOMao PWazF2HSx5kLphDjZ5ggpDielSjjqycH2C5KFuf18z+t611Q2RQOocf8wHng9rDbEFzH aiegiVcvjwTtbLBq54m4oPuYcSIxd3Plyr3rHL93e11H2dCYbZKNHvk2nWrIgH0g+2xD u3W/FxC8X++a9Qm7YDY0x02bgZWX3kKE5ambp2SiAtZzsR9jAFKcTZyF3aiKGAgiesLS 7Trfx7Aj0M3+Zn7FsbGhjGGpRcdLt1JpPsTsaGYTPLaWISulIdJEEm/IResdeLmJAfvL t4Qw==
X-Gm-Message-State: APjAAAWwSMRKJa9nA2RhvQRaVlK2x0D29BvIfnaWwIZGrZ8+Jte1SLSW ErvlzRncU7R74DLh69xvx278ETtL8l9Ssc/XCfc=
X-Google-Smtp-Source: APXvYqwSzB+gyH8lxrwEvNyZffq9Z9yZHjkLFrNTajCWYutAL9hHw8t0tOLZARznl5UIGkfHF8msJNjQMRuxMLQiILk=
X-Received: by 2002:a6b:37c2:: with SMTP id e185mr32775739ioa.143.1556553119102; Mon, 29 Apr 2019 08:51:59 -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>
In-Reply-To: <01cc01d4b897$017f9d20$4001a8c0@gateway.2wire.net>
From: Xufeng Liu <xufeng.liu.ietf@gmail.com>
Date: Mon, 29 Apr 2019 11:51:47 -0400
Message-ID: <CAEz6PPQXHvG2A8Q_RhgyEbKBx0DK4ZHjZh9eMMwMh84rE9QVpw@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="000000000000bcfbdd0587ad4344"
Archived-At: <https://mailarchive.ietf.org/arch/msg/pim/dVYTZXE0re_uaoHXhtr3r_Vuv7w>
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: Mon, 29 Apr 2019 15:52:04 -0000

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