Re: [pim] Benjamin Kaduk's Discuss on draft-ietf-pim-igmp-mld-snooping-yang-17: (with DISCUSS and COMMENT)

Hongji Zhao <hongji.zhao@ericsson.com> Tue, 14 July 2020 03:05 UTC

Return-Path: <hongji.zhao@ericsson.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 07C963A083F; Mon, 13 Jul 2020 20:05:14 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.102
X-Spam-Level:
X-Spam-Status: No, score=-2.102 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, RCVD_IN_MSPIKE_H2=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=ericsson.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 28azx5AsFonp; Mon, 13 Jul 2020 20:05:11 -0700 (PDT)
Received: from EUR04-DB3-obe.outbound.protection.outlook.com (mail-eopbgr60087.outbound.protection.outlook.com [40.107.6.87]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 485CB3A07E7; Mon, 13 Jul 2020 20:05:11 -0700 (PDT)
ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=clkqYuRmosSGKTO6/3rd8Jww0qgfN8OWKq4FoPvE3qbAfv4uFWvkEMcfQUsSAb0A3v9TIz8CPvqF6MkAxBCVk1Tuh+nUqvs93o/9Jdlp/jldB3EMdLgPjLdKeRsop/TA06rI7dfTRKcK/Xu0oarP2Ze16DgCAcHyBLaIqNS2q4PfNz/ajHLx8aAcSQs9xaLkG1NhnuNQjTb1GjO8LvarZkWYCVUf56fdvIEbOulxkumww7N6dhy1VssfNCI7CcGyCddua868SDJSJFGl/YsGGSvVb1do79LOQxJYmO0NIgHZbFBfoEBMX+BhkNKfa/dc0z338aAe4hJPtARaTSO4eQ==
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=wKXhLXGROqSi1kMZUUwtVuos8NYU5aImjHyjNvx/7Ww=; b=d0W8i6d+6S7BUhrK0ZJoELQZremQSdCPHGPPoprn0+wmzgH4C6RGgFVFZXB+PipMyankp+FLz+RgMWvlBSRsy0MC6oUf4kjKag4HmOznnbriOVYIVnRIN/hoM9a/2zeyCIelR3sLobFa+EuTXR25/6UgeLSYFNrtNsOSj/sVuMFs+EKLb2tpr1dUCq77IppRBnLHioL1V37UxfoF5Pp0wGtSS/9l5iZZP2wu7L9Eo87BsaLvfKBqRAnv4lz3ulaGozGUYUO2pXoTeLi5EQt/06+RC5+CFtgbC11wPFav/HZ2QU8CAjk0ly7imEtF31EsdqEYDgWVsm4cFL0vXfAOpw==
ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=ericsson.com; dmarc=pass action=none header.from=ericsson.com; dkim=pass header.d=ericsson.com; arc=none
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ericsson.com; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=wKXhLXGROqSi1kMZUUwtVuos8NYU5aImjHyjNvx/7Ww=; b=tHSRkZjsdWe+RTJIdjMBayCwQa2YT17ymfd/XfNazJU/h5EMgX1/UtbJwFWleKVGcfX2hQbA9vIOYgjGXYjmZxu2ySlq9yN/b26kJYHkYUfgswVZHptpZjazgShDGRvj5gFNYeOIpUnFxfGQkD+SBOOvxno58TpSMSqYHVzwgl8=
Received: from HE1PR0701MB2492.eurprd07.prod.outlook.com (2603:10a6:3:71::22) by HE1PR0702MB3755.eurprd07.prod.outlook.com (2603:10a6:7:8d::33) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3195.13; Tue, 14 Jul 2020 03:04:49 +0000
Received: from HE1PR0701MB2492.eurprd07.prod.outlook.com ([fe80::ec82:bf39:2810:fbb0]) by HE1PR0701MB2492.eurprd07.prod.outlook.com ([fe80::ec82:bf39:2810:fbb0%7]) with mapi id 15.20.3195.009; Tue, 14 Jul 2020 03:04:49 +0000
From: Hongji Zhao <hongji.zhao@ericsson.com>
To: Benjamin Kaduk <kaduk@mit.edu>, The IESG <iesg@ietf.org>
CC: "draft-ietf-pim-igmp-mld-snooping-yang@ietf.org" <draft-ietf-pim-igmp-mld-snooping-yang@ietf.org>, "pim-chairs@ietf.org" <pim-chairs@ietf.org>, "pim@ietf.org" <pim@ietf.org>, Stig Venaas <stig@venaas.com>, "aretana.ietf@gmail.com" <aretana.ietf@gmail.com>
Thread-Topic: Benjamin Kaduk's Discuss on draft-ietf-pim-igmp-mld-snooping-yang-17: (with DISCUSS and COMMENT)
Thread-Index: AQHWVgXV2pJ2HjTThU2chSJUhoijKakGagBg
Date: Tue, 14 Jul 2020 03:04:49 +0000
Message-ID: <HE1PR0701MB2492D5A57C9E2A8EE0F4258696610@HE1PR0701MB2492.eurprd07.prod.outlook.com>
References: <159430697358.25000.8158144534647796320@ietfa.amsl.com>
In-Reply-To: <159430697358.25000.8158144534647796320@ietfa.amsl.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
authentication-results: mit.edu; dkim=none (message not signed) header.d=none;mit.edu; dmarc=none action=none header.from=ericsson.com;
x-originating-ip: [119.28.22.196]
x-ms-publictraffictype: Email
x-ms-office365-filtering-correlation-id: c788f544-7567-4e39-0188-08d827a2abef
x-ms-traffictypediagnostic: HE1PR0702MB3755:
x-microsoft-antispam-prvs: <HE1PR0702MB3755F8B663737ABC1D13BFB396610@HE1PR0702MB3755.eurprd07.prod.outlook.com>
x-ms-oob-tlc-oobclassifiers: OLM:10000;
x-ms-exchange-senderadcheck: 1
x-microsoft-antispam: BCL:0;
x-microsoft-antispam-message-info: Y73GEUZh7C3T4AXzyUWlMdbktGK36Df/GGCf1r9Lm1VCNY24t1X1hA61Ft9FacYzPklFgR4V1HdwRchzmKIW2mNtqLimS6IuRYyYC2uS9mBtXPM8R/h9xfLyUbwsSELqufxDWIj8n9Kq7s+Zi27E5cc5JhgV1WwX1uxEkE6Je/sCNMEMVOVsrG/lj/ODrwQeYVEmuTDBej1qUBJQkwlp32ltrF+lmueanTcAmIEQUjOEh28n70DBGEQPFwuJOL1z7AwCh0972HqrGuibn7Fw3IBWOZhxaUV0vFpthBJtrIYj/5rmXcxslxVvx9oIeZTp+DKAK2TbkPKZ+NAp4w2g3jUx7EIDJsjd7mLkrJCRCQRuHT75Q8LgRu3cdUCVfMFFiW2+DURZLno7K35n1OLDxQ==
x-forefront-antispam-report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:HE1PR0701MB2492.eurprd07.prod.outlook.com; PTR:; CAT:NONE; SFTY:; SFS:(4636009)(366004)(136003)(396003)(346002)(39860400002)(376002)(52536014)(33656002)(44832011)(83380400001)(86362001)(66574015)(110136005)(55016002)(966005)(54906003)(5660300002)(71200400001)(66556008)(66476007)(64756008)(66446008)(76116006)(66946007)(316002)(2906002)(6506007)(53546011)(478600001)(26005)(9686003)(186003)(8676002)(8936002)(4326008)(7696005); DIR:OUT; SFP:1101;
x-ms-exchange-antispam-messagedata: 6WJ7E+q4Ki00F02SFN3bGuAmBCLz9/rLo98R6KtdYjSxL1HWlowdnK1xIOpzg7qbodCo1XTEgE+qulgeJUNkMSajl7RqgDHblt8D59fpxMhK3tNROLkCeD2Enphb035MgMox8+Aik9Zv7HcJP77wy/VJMJfYScWXX0RwLyMT9Wi0eoIniIwg58MHsKlKhWKyT1rnFkAqvKXIBzP50rnT3bpqTFkIUXOxuofRvW/4vK0RTo9olQ/qJ2XyogDalZ/NJ+25W/fGVeinQ8rvG8BY8GotpzHtN600EUf4398bM+cbwPiMCIUBFYvUxiEtNkr3V21kRjcLIytQ98K04qCl/8IzfgskUaRbIkJ0IbIFSQ0I8gL1LsIbGZbwp3OkTG17s5XKrcUpzKH00emRL8ytfbRjpIO4QrqrMaj/0CEjqkhNFJyVDFoRNGW2jVNVag4mKJMyRva0wws+auYLIdxuyZnSlHHIky4QTuz/qPes2Vo=
x-ms-exchange-transport-forked: True
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64
MIME-Version: 1.0
X-OriginatorOrg: ericsson.com
X-MS-Exchange-CrossTenant-AuthAs: Internal
X-MS-Exchange-CrossTenant-AuthSource: HE1PR0701MB2492.eurprd07.prod.outlook.com
X-MS-Exchange-CrossTenant-Network-Message-Id: c788f544-7567-4e39-0188-08d827a2abef
X-MS-Exchange-CrossTenant-originalarrivaltime: 14 Jul 2020 03:04:49.3808 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: 92e84ceb-fbfd-47ab-be52-080c6b87953f
X-MS-Exchange-CrossTenant-mailboxtype: HOSTED
X-MS-Exchange-CrossTenant-userprincipalname: YUlkL7aovHBXUcbgqrHjpwNQH8jBe+ELE3VJvbPO40bzC10RoWfr0JyS/n5gytTGJ7/lWJBeRVSUg8FNFhd+1/P/z8ZACt94SYGs0hf5jQU=
X-MS-Exchange-Transport-CrossTenantHeadersStamped: HE1PR0702MB3755
Archived-At: <https://mailarchive.ietf.org/arch/msg/pim/amQ7OCHaBa596I0w52k40vKXyv4>
Subject: Re: [pim] Benjamin Kaduk's Discuss on draft-ietf-pim-igmp-mld-snooping-yang-17: (with DISCUSS and COMMENT)
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: Tue, 14 Jul 2020 03:05:14 -0000

Hi Benjamin,

Thanks a lot for your comments. 

Regarding your discuss,  we plan to modify exclude-lite leaf as below. 
Is it ok? Thanks.

leaf lite-exclude-filter {
      if-feature lite-exclude-filter;
      type empty;
      description
           "For IGMP Snooping, the presence of this
            leaf enables the support of the simplified EXCLUDE filter 
            in the Lightweight IGMPv3 protocol, which simplifies the
            standard versions of IGMPv3.
            For MLD Snooping, the presence of this
            leaf enables the support of the simplified EXCLUDE filter
            in the Lightweight MLDv2 protocol, which simplifies the
            standard versions of MLDv2.";
      reference
           "RFC 5790: Lightweight Internet Group Management Protocol
            Version 3 (IGMPv3) and Multicast Listener Discovery
            Version 2 (MLDv2) Protocols";
    }

BR/Hongji

-----Original Message-----
From: Benjamin Kaduk via Datatracker <noreply@ietf.org> 
Sent: Thursday, July 9, 2020 11:03 PM
To: The IESG <iesg@ietf.org>
Cc: draft-ietf-pim-igmp-mld-snooping-yang@ietf.org; pim-chairs@ietf.org; pim@ietf.org; Stig Venaas <stig@venaas.com>om>; aretana.ietf@gmail.com; stig@venaas.com
Subject: Benjamin Kaduk's Discuss on draft-ietf-pim-igmp-mld-snooping-yang-17: (with DISCUSS and COMMENT)

Benjamin Kaduk has entered the following ballot position for
draft-ietf-pim-igmp-mld-snooping-yang-17: Discuss

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-snooping-yang/



----------------------------------------------------------------------
DISCUSS:
----------------------------------------------------------------------

Let's discuss whether we need to be a bit more clear about what behavior should be expected when the exclude-lite leaf has value true vs. false -- the apparent inconsistency between "exclude"
in the leaf name and the positive verb "track" in the description left me confused.


----------------------------------------------------------------------
COMMENT:
----------------------------------------------------------------------

Is a gauge type better than an int for the various 'count' fields?

Do we want to put in explicit "discontinuity-time" elements for when the counters last reset?  (I see at least one "up-time" leaf but it's not entirely clear that the semantics match up.)

Section 3.2

    The mld-snooping-instance is the same as IGMP snooping except changing
    IPv4 addresses to IPv6 addresses. One mld-snooping-instance could be

The diff also shows some mechanical changes, like replacing "igmp-version" with "mld-version", and the name of statistics leafs that are tied to protocol version/elements.  There doesn't seem to be a clear need to call out every such difference, though.

Section 4

  feature exclude-lite {
    description
      "Support configuration of per instance exclude-lite.";
    reference
      "RFC 5790";

RFC 5790 does not use the keyword "EXCLUDE-lite" (or actually, "lite" at all), so a little bit more description of which functionality this refers to could be helpful.

    leaf-list bridge-mrouter-interface {
      when 'derived-from-or-self(../scenario,"ims:bridge")';
      type if:interface-ref;
      config false;
      description
        "The mrouter interface in BRIDGE forwarding. When switch
         receives IGMP/MLD queries from multicast router on an
         interface, this interface will become mrouter interface
         for IGMP/MLD snooping.";

nit: the grammar in this description should be revisited; maybe just missing articles.  Similarly for the next few entries.

          leaf last-reporter {
            type inet:ipv4-address;
            description
              "Address of the last host which has sent report
               to join the multicast group.";

I guess I'm not entirely sure what this is used for; it doesn't seem like it would provide a way to reliably get a stream of all hosts that sent a report to join (the "list host" with feature explicit-tracking would be needed for that, right?), and could be stale at any time, but I'm probably just missing something.
(Similarly for the MLD case.)

      container interfaces {
         config false;

         description
           "Interfaces associated with the IGMP snooping instance";

         list interface {
           key "name";

           description
             "Interfaces associated with the IGMP snooping instance";

Should we consider non-verbatim-equivalent descriptions for the container and the list?  (Likewise for MLD.)

Section 5

It's probably worth a brief note in the "readable data nodes" section about any privacy considerations of exposing multicast group membership (e.g., if IP addresses are associated with users, and multicast groups associated with certain types of content, then there is transitively an association between the user and the content, which could be privacy sensitive).

Section 7.1

It's not entirely clear that RFC 8407 needs to be normative.

It is, however, pretty clear that RFC 8652 does not need to be normative, since we reference it basically to say "we don't need to pull this in".

Section 7.2

RFC 6636 is referenced from the YANG module; doesn't that make it normative?

Appendix A

[Just noting that I did not carefully review the examples.]