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

Hongji Zhao <hongji.zhao@ericsson.com> Wed, 15 July 2020 03:47 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 4FC9A3A0E31; Tue, 14 Jul 2020 20:47:35 -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=unavailable 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 OgCbq45FQkFM; Tue, 14 Jul 2020 20:47:32 -0700 (PDT)
Received: from EUR05-AM6-obe.outbound.protection.outlook.com (mail-am6eur05on2069.outbound.protection.outlook.com [40.107.22.69]) (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 0DCBC3A0E36; Tue, 14 Jul 2020 20:47:31 -0700 (PDT)
ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=YNU3IqJALf3F33sYmDU55V73kUbct7bj6J1xkyH3N51FGBfoXqOeOG2DLwYvLLByXB/qeHpTLyhGHgns6hkYRTNkajnPRzk3FXF4xWeGzDWbqyzzLCy/kfkvrp2p9aojcOTlOwg/VRqLWdRlCTeZPacS6DJjMjMV0nDbKcJWOWmmsGsaaaV9yKAbWXrZkauYJD4zGpnMGBWUiZNXmicZzU2pyj5vauQQB8kf1Q1F7Wm+SWN1AV1axkvw9EqPTPAG3uub/evWF1cbWLG62vE6IPjtPPB3Sqj2Hmc0i3usVrbPr/f0faBABZmxZC6Xy12jPB9Xjqx4kopRlFnjCCmeSQ==
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=WEhGKkMw2xja3nH6spo8rPZ4MTsaPU7grkO6Krc+szg=; b=AJA0OWVaqrGrDtnUQXF46ikBHow6I9U82RFuNHucllNLVDudqLrL6d9sDyfii0nKlmV85d6itIn1hBPgy3E69DE+xXU2dsmUyQFuJUwHONYDtcYCd0L09qupxGTTGSXVF32iA7a43Gr5ikB9+cO8OHrZlfK6uM1VPr8hDF4tCFn91cJ96OsdhKWDBUifLFjfNRodg3c8gVba8wwhZRZjqRQyBIsKklKvJEjBz6zhwZMTVkIfD02iHVExVlATw2wNrn9LHmOZ+xlQFf0BTa9kCA/ZPfBG4UKRCcicVYV5jyyNvEM7TAA5e5TBrTmn90zN3XyDwHGW+AyxNL7jB3BSNw==
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=WEhGKkMw2xja3nH6spo8rPZ4MTsaPU7grkO6Krc+szg=; b=EF7dqDXHsKJK9fVxXT4AkrdWHB7QoiNpSb8js1n6PO0D847AtJm0Yb9z6NcNITqAagu2WeEI6mYg4a01R3uAPPMCPdl1G2PFxdBkxafiQ3TJKxKRTp2fHsYmPJSgBxPK0t7cIhJa0SuZUGtrFDRhlCT1Ri/Xo6iXagzBw9icXEE=
Received: from HE1PR0701MB2492.eurprd07.prod.outlook.com (2603:10a6:3:71::22) by HE1PR0702MB3803.eurprd07.prod.outlook.com (2603:10a6:7:84::11) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3195.11; Wed, 15 Jul 2020 03:47:29 +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.018; Wed, 15 Jul 2020 03:47:29 +0000
From: Hongji Zhao <hongji.zhao@ericsson.com>
To: "Rob Wilton (rwilton)" <rwilton@cisco.com>, "Eric Vyncke (evyncke)" <evyncke=40cisco.com@dmarc.ietf.org>, The IESG <iesg@ietf.org>
CC: Stig Venaas <stig@venaas.com>, "pim-chairs@ietf.org" <pim-chairs@ietf.org>, "pim@ietf.org" <pim@ietf.org>, "draft-ietf-pim-igmp-mld-snooping-yang@ietf.org" <draft-ietf-pim-igmp-mld-snooping-yang@ietf.org>, "aretana.ietf@gmail.com" <aretana.ietf@gmail.com>
Thread-Topic: Robert Wilton's Discuss on draft-ietf-pim-igmp-mld-snooping-yang-17: (with DISCUSS and COMMENT)
Thread-Index: AQHWVdcXmlpukUvGqE2bmmz/z85+SqkGcErggABdioCAAEuigP//5MqAgAEK7jA=
Date: Wed, 15 Jul 2020 03:47:29 +0000
Message-ID: <HE1PR0701MB249250BD7D8FCBE0DD101BE0967E0@HE1PR0701MB2492.eurprd07.prod.outlook.com>
References: <159428852777.7283.9711125025293117565@ietfa.amsl.com> <HE1PR0701MB249249C361CB7EAE14C9E8BF96610@HE1PR0701MB2492.eurprd07.prod.outlook.com> <BY5PR11MB435511BEE3DAF693888E91E2B5610@BY5PR11MB4355.namprd11.prod.outlook.com> <FCA2400B-CC22-47DB-9E0C-9BD100107A0F@cisco.com> <MN2PR11MB43666D4D3FBB12BD1F618254B5610@MN2PR11MB4366.namprd11.prod.outlook.com>
In-Reply-To: <MN2PR11MB43666D4D3FBB12BD1F618254B5610@MN2PR11MB4366.namprd11.prod.outlook.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
authentication-results: cisco.com; dkim=none (message not signed) header.d=none;cisco.com; 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: 2276804d-e850-4d5d-4ef0-08d82871cc3e
x-ms-traffictypediagnostic: HE1PR0702MB3803:
x-microsoft-antispam-prvs: <HE1PR0702MB3803A8B0704F1EE1CA04672D967E0@HE1PR0702MB3803.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: GUEp1DNdlCYlvKeE6PuTaSPDStnit/k0qKRVknG3n427v1Z/fX7f/hMbHJGxvuFisYKsCZxE7XzymW6Ie3NrJ8kmpyWN7Alkrlotiu0xuLEBXAV8sylS1mHTOVQgjkbQyTXvkfum22XDRqWPfPmxONJWCkQAoWZquYWSum6xKOpm5bOB/z3zlelOZY1TB3CCbM/bUiiwZBR4yW8JtdU7Ar30+rPLmubAaMYxO2X3a7E5nx2Nequv/KQ4VxEpax6t89T8DX2SMoeU6UIkUUMeEnX7DjlXOPW5oO5wSMzpxYgztjraj14R0bslTyKmEhqzzVX9/u74yB6F2+wvmdydIFxXNaop+4VA+kbUiuCl7avP25DVeJlBHe5PseSXNqO1qp+2mDVWheIj+f7guye8yQlkc8mvBiwPPnqHBHI2AkRrLAPe0bwPLin0+Tn8A27+KVDuTpU1NB2s9muM2sxHLw==
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)(376002)(396003)(346002)(39860400002)(136003)(366004)(26005)(6506007)(53546011)(33656002)(316002)(9686003)(7696005)(110136005)(55016002)(54906003)(186003)(30864003)(52536014)(66946007)(66476007)(5660300002)(66556008)(66446008)(64756008)(76116006)(86362001)(71200400001)(44832011)(478600001)(966005)(83380400001)(66574015)(4326008)(2906002)(8676002)(8936002)(21314003); DIR:OUT; SFP:1101;
x-ms-exchange-antispam-messagedata: BacFBldzK9Xf0RrhEZ3OLJMVajrkF5RqiZLuE3vSMlE7vJajsoqf+fax7QRUHE+old+UNHEpiyodefhP5XssZpOyO1AkoYpLfYyaYUTJkgbx1QsIfBraZftLFtvWz+7OVWSKTv1cV2D+mQMlQyKGvD1Np/RFW0sEEElP66pIwYEvKt7twE5fX7N1wi/y4BshfkU6a2PZu4etmcDC1bRTAHeNLswYPOKzd+Y0pIieCF39wGFCJqJMyvwaO/Altkw4KF4EfJQ5L1x1xpBpoyFhv0DxB7/ztsaUmlYUnKUxAqTTRMO3JfI+mm+B2NujoOsWkZ2u51z4FY65i7s5rkSML1p7E1WM/nAHOqszNTQ3GLdErMKHT6as3pr75Luof9yK3pQUsKBLg8pmll3YgKeaNEQaLmRSQ4O+uqq9EDhrtzRk8gaxPs2JlXt41rsoVngIdMZ+bLdhp5C7vcRB1WIWBjXV9J1uUaTyqHJGqQM0VmI=
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: 2276804d-e850-4d5d-4ef0-08d82871cc3e
X-MS-Exchange-CrossTenant-originalarrivaltime: 15 Jul 2020 03:47:29.1588 (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: OSkY66oPC6T6W72TgPmiG4wvdEsArLpr2pR/DPi4brgPWMJhzNJABc43nfqjPny3YYkaaygKF7FFI/3IFA8EM0y4I59RMw8Zm7AI5ApGDOs=
X-MS-Exchange-Transport-CrossTenantHeadersStamped: HE1PR0702MB3803
Archived-At: <https://mailarchive.ietf.org/arch/msg/pim/PiqxsFL3N2BJ2B1DbiG6xGYAUrI>
Subject: Re: [pim] Robert Wilton'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: Wed, 15 Jul 2020 03:47:35 -0000

Hi Rob & Eric,

Authors will hold a meeting to discuss your suggestions. Thanks a lot for your comments.

BR/Hongji

-----Original Message-----
From: Rob Wilton (rwilton) <rwilton@cisco.com> 
Sent: Tuesday, July 14, 2020 7:50 PM
To: Eric Vyncke (evyncke) <evyncke=40cisco.com@dmarc.ietf.org>rg>; Hongji Zhao <hongji.zhao@ericsson.com>om>; The IESG <iesg@ietf.org>rg>; aretana.ietf@gmail.com
Cc: Stig Venaas <stig@venaas.com>om>; pim-chairs@ietf.org; pim@ietf.org; draft-ietf-pim-igmp-mld-snooping-yang@ietf.org
Subject: RE: Robert Wilton's Discuss on draft-ietf-pim-igmp-mld-snooping-yang-17: (with DISCUSS and COMMENT)

Hi Hongji,

Having discussed this with Eric, I would also be happy with the suggestion that he proposes (i.e. of having a single combined tree that covers both IGMP snooping and MLD snooping), so it is another option for you to please consider.

Regards,
Rob


> -----Original Message-----
> From: Eric Vyncke (evyncke) <evyncke=40cisco.com@dmarc.ietf.org>
> Sent: 14 July 2020 12:28
> To: Rob Wilton (rwilton) <rwilton@cisco.com>om>; Hongji Zhao 
> <hongji.zhao@ericsson.com>om>; The IESG <iesg@ietf.org>rg>; 
> aretana.ietf@gmail.com
> Cc: Stig Venaas <stig@venaas.com>om>; pim-chairs@ietf.org; pim@ietf.org; 
> draft-ietf-pim-igmp-mld-snooping-yang@ietf.org
> Subject: Re: Robert Wilton's Discuss on 
> draft-ietf-pim-igmp-mld-snooping-
> yang-17: (with DISCUSS and COMMENT)
> 
> It seems that similar issues keep repeating for IPv4 and IPv6 (e.g. 
> RFC 8652)... Either two trees in one module or two modules (one per 
> address family).
> 
> While I am not a YANG expert, I would assume that network operators 
> would prefer a unified models (of course with specific leaves & 
> containers) when operating a dual-stack network rather than 
> duplicating their automation effort.
> 
> As long as IPv6 is covered, I am OK (per my COMMENT on this I-D) but 
> unsure whether 2 modules/2 trees should be the 'way to go'... For 
> SNMP, RFC 4292/4293 was made protocol version independent which is a 
> big plus IMHO for operations.
> 
> -éric
> 
> -----Original Message-----
> From: iesg <iesg-bounces@ietf.org> on behalf of "Rob Wilton (rwilton)"
> <rwilton=40cisco.com@dmarc.ietf.org>
> Date: Tuesday, 14 July 2020 at 10:58
> To: Hongji Zhao <hongji.zhao@ericsson.com>om>, The IESG <iesg@ietf.org>rg>, 
> "aretana.ietf@gmail.com" <aretana.ietf@gmail.com>
> Cc: Stig Venaas <stig@venaas.com>om>, "pim-chairs@ietf.org" <pim- 
> chairs@ietf.org>gt;, "pim@ietf.org" <pim@ietf.org>rg>, 
> "draft-ietf-pim-igmp-mld- snooping-yang@ietf.org" 
> <draft-ietf-pim-igmp-mld-snooping-yang@ietf.org>
> Subject: RE: Robert Wilton's Discuss on 
> draft-ietf-pim-igmp-mld-snooping-
> yang-17: (with DISCUSS and COMMENT)
> 
>     Hi Hongji,
> 
>     There are 3 choices here:
> 
>     (1) Put both models in the same YANG module, use common groupings, 
> and then use top level features to enable/disable the functionality.  
> I.e., this is what the draft currently does.
> 
>     Benefits:
>      - One module
>      - Use of groupings ensure the contents are aligned.
> 
>     Downsides:
>      - Undesirable top level IGMP/MLD features
>      - Somewhat unclear description statements (since the descriptions 
> reference both IGMP and MLD even when they only apply to one protocol).
> 
> 
>     (2) Split the work into 3 YANG models:
>       (i) Common IGMP/MLD groupings/features, i.e. the same shared 
> groupings that you have now.
>       (ii) IGMP snooping module (importing shared groupings)
>       (iii) MLD snooping module (importing shared groupings)
> 
>     Benefits:
>      - Avoids top level IGMP/MLD features
>      - Use of groupings ensures the contents are aligned
> 
>     Downsides:
>       - Somewhat unclear description statements (since the 
> descriptions reference both IGMP and MLD even when they only apply to one protocol).
>       - Note, the 'refine' statement could be used where the groupings 
> are used (RFC 7950 sec 7.13.2) to potentially improve the descriptions.
> Otherwise possibly some of the description statements could be 
> slightly reworded to avoid referencing back to IGMP or MLD.
>       - Some features would need to belong the common module unless 
> the data nodes using those features were taken out of the common 
> groupings
> 
>     (3) Split the work into 2 separate modules
>       (i) IGMP snooping module
>       (ii) MLD snooping module
> 
>     Benefits:
>      - Avoids top level IGMP/MLD features
>      - Description statements are clear (since they always only refer 
> to the protocol they act on)
>      - Features are controllable for each protocol separately (not 
> sure if this is a benefit or a downside)
> 
>     Downsides:
>      - Duplicate definitions, more potential to get out of sync in 
> future, although given that they are both defined in the same 
> document, that doesn't seem too likely.
> 
> 
>     My preference is for (3).  I believe that makes it much 
> easier/clearer to an operator to see whether one/both IGMP and MLD snooping is supported.
> 
>     However, this is just a preference, and I also want to see IETF 
> YANG models completed and standardized.  I.e., I will not block 
> progression of this document if the authors & Alvaro thinks that the 
> existing module structure is sufficient, or choose to do (2) instead.
> 
>     Regards,
>     Rob
> 
> 
> 
>     > -----Original Message-----
>     > From: Hongji Zhao <hongji.zhao@ericsson.com>
>     > Sent: 14 July 2020 04:26
>     > To: Rob Wilton (rwilton) <rwilton@cisco.com>om>; 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
>     > Subject: RE: Robert Wilton's Discuss on draft-ietf-pim-igmp-mld-
> snooping-
>     > yang-17: (with DISCUSS and COMMENT)
>     >
>     > Hi Robert,
>     >
>     > Thanks a lot for your comments.
>     >
>     > In this YANG model, four of six groupings are common for both igmp
>     > snooping and mld snooping.
>     > If it is splitted into two separate YANG models, there will be a 
> lot of
>     > duplicated contents.  Is it ok?   Thank you very much.
>     >
>     >
>     >
>     > BR/Hongji
>     >
>     > -----Original Message-----
>     > From: Robert Wilton via Datatracker <noreply@ietf.org>
>     > Sent: Thursday, July 9, 2020 5:55 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: Robert Wilton's Discuss on draft-ietf-pim-igmp-mld-
> snooping-yang-
>     > 17: (with DISCUSS and COMMENT)
>     >
>     > Robert Wilton 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:
>     > 
> --------------------------------------------------------------------
> --
>     >
>     > Hi,
>     >
>     > I appreciate that this YANG model has already passed a YANG 
> doctor review,
>     > but this discuss is to understand the reasoning as to why both IGMP
>     > snooping and MLD snooping are in the same YANG module, yet have 
> top level
>     > features to separate their functionality.
>     >
>     >     4. IGMP and MLD Snooping YANG Module
>     >
>     >       feature igmp-snooping {
>     >         description
>     >           "Support IGMP snooping.";
>     >         reference
>     >           "RFC 4541";
>     >       }
>     >
>     >       feature mld-snooping {
>     >         description
>     >           "Support MLD snooping.";
>     >         reference
>     >           "RFC 4541";
>     >       }
>     >
>     > It seems strange to me to have the entire YANG Model split under two
>     > separate feature statements. I believe that it would have been 
> better to
>     > split this into two separate YANG models, both following the same
>     > structure.  Possibly, a common YANG module could have been used 
> to share
>     > groupings and definitions, but even then duplicating the 
> contents of the
>     > model so that the description statements could be 
> correct/accurate would
>     > be more helpful.
>     >
>     >
>     > 
> --------------------------------------------------------------------
> --
>     > COMMENT:
>     > 
> --------------------------------------------------------------------
> --
>     >
>     > Thank you for your work on this document and YANG model.  I also 
> have a
>     > few minor comments/suggestions that may improve the document and 
> YANG
>     > module:
>     >
>     >     2. Design of Data Model
>     >
>     >     An IGMP/MLD snooping switch [RFC4541] analyzes IGMP/MLD packets
> and
>     > sets
>     >     up forwarding tables for multicast traffic. If a switch does not
> run
>     >     IGMP/MLD snooping, multicast traffic will be flooded in the
> broadcast
>     >     domain. If a switch runs IGMP/MLD snooping, multicast traffic
> will be
>     >     forwarded based on the forwarding tables to avoid wasting
> bandwidth.
>     > The
>     >     IGMP/MLD snooping switch does not need to run any of the
> IGMP/MLD
>     >     protocols. Because the IGMP/MLD snooping is independent of the
>     > IGMP/MLD
>     >     protocols, the data model defined in this document does not
> augment,
>     > or
>     >     even require, the IGMP/MLD data model defined in [RFC8652].
>     >     The model covers considerations for Internet Group Management
> Protocol
>     >     (IGMP) and Multicast Listener Discovery (MLD) Snooping Switches
>     >     [RFC4541].
>     >
>     > It wasn't clear to me what the final sentence was trying to say.
> Perhaps
>     > it should be merged with the penultimate sentence in the paragraph?
>     >
>     >     The YANG module includes IGMP and MLD Snooping instance
> definition,
>     >     using instance in the scenario of BRIDGE [dot1Qcp] and L2VPN
> [draft-
>     >     ietf-bess-l2vpn-yang]. The module also includes actions for
> clearing
>     >     IGMP and MLD Snooping group tables.
>     >
>     > I find the use of the terminology of "scenario of " to be somewhat
>     > strange.  I would probably have referred to these a "L2 forwarding
>     > pradigms" or "L2 forwarding instances".  If this terminology is 
> changed
>     > then it would need to be fixed elsewhere in this document and 
> the YANG
>     > model.
>     >
>     >     On the other hand, operational state parameters are not so
> widely
>     >     designated as features, as there are many cases where the
> defaulting
>     >     of an operational state parameter would not cause any harm to
> the
>     >     system, and it is much more likely that an implementation
> without
>     >     native support for a piece of operational state would be able to
>     > derive
>     >     a suitable value for a state variable that is not natively
> supported.
>     >
>     > With NMDA, the server also has the option of not returning a 
> value for a
>     > given item of operational data (RFC 8342, section 5,3, paragraph 4).
>     > Although this doesn't conform to the data model, the semantics 
> are well
>     > defined - i.e. the client cannot infer anything about the value 
> that has
>     > not been returned.
>     >
>     >     2.3. Position of Address Family in Hierarchy
>     >
>     >     IGMP Snooping only supports IPv4, while MLD Snooping only
> supports
>     > IPv6.
>     >     The data model defined in this document can be used for both
> IPv4 and
>     >     IPv6 address families.
>     >
>     >     This document defines IGMP Snooping and MLD Snooping as separate
>     > schema
>     >     branches in the structure. The benefits are:
>     >
>     >     *  The model can support IGMP Snooping (IPv4), MLD Snooping
> (IPv6), or
>     >     both optionally and independently. Such flexibility cannot be
> achieved
>     >     cleanly with a combined branch.
>     >
>     >     *  The separate branches for IGMP Snooping and MLD Snooping can
>     >     accommodate their differences better and cleaner. The two
> branches can
>     >     better support different features and node types.
>     >
>     > I would suggest rewording this first sentence to something like:
>     >
>     > "Having separate branches for IGMP Snooping and MLD Snooping 
> allows minor
>     > differences in their  behavior to be modelled more simply and 
> cleanly".
>     >
>     >     3. Module Structure
>     >
>     >     A configuration data node is marked as mandatory only when its
> value
>     >     must be provided by the user. Where nodes are not essential to
>     > protocol
>     >     operation, they are marked as optional.  Some other nodes are
>     > essential
>     >     but have a default specified, so that they are also optional and
> need
>     >     not be configured explicitly.
>     >
>     > This paragraph seems to just describe standard YANG modelling 
> and can be
>     > removed.
>     >
>     >     3.1. IGMP Snooping Instances
>     >
>     >     The value of scenario in igmp-snooping-instance is bridge or
> l2vpn.
>     > When it
>     >     is bridge, igmp-snooping-instance will be used in the BRIDGE
>     >
>     > As per previous comments, this first sentence does not read well 
> for me.
>     >
>     >     The values of bridge-mrouter-interface, l2vpn-mrouter-interface-
> ac,
>     >     l2vpn-mrouter-interface-pw are filled by the snooping device
>     > dynamically.
>     >     They are different from static-bridge-mrouter-interface,
>     >     static-l2vpn-mrouter-interface-ac, and static-l2vpn-mrouter-
> interface-
>     > pw
>     >     which are configured
>     >
>     > Ideally, these static nodes would not have been necessary, 
> instead relying
>     > on the NMDA split between configuration and state, but that 
> would probably
>     > require the default model to always allow them to be statically
>     > configured.  In NMDA, features can be implemented per-datastore 
> but it is
>     > not clear how well that would work here.
>     >
>     >       units one-tenth-second;
>     >
>     > Perhaps "units deciseconds" would be better?
>     >
>     >   grouping igmp-snooping-statistics {
>     >     description
>     >       "The statistics attributes for IGMP snooping.";
>     >
>     >       leaf num-query {
>     >         type yang:counter64;
>     >         description
>     >           "The number of Membership Query messages.";
>     >         reference
>     >           "RFC 2236";
>     >       }
>     >
>     > For these counters, rather than "num-XXX", I think that they 
> would be
>     > better as "XXX-count", or if these relate to the number of 
> packets
> "XXX-
>     > pkts" (as per RFC 8343).
>     >
>     >            container statistics {
>     >              description
>     >                "The interface statistics for IGMP snooping";
>     >
>     >              container received {
>     >                description
>     >                  "Statistics of received IGMP snooping packets.";
>     >
>     >                uses igmp-snooping-statistics;
>     >              }
>     >              container sent {
>     >                description
>     >                  "Statistics of sent IGMP snooping packets.";
>     >
>     >                uses igmp-snooping-statistics;
>     >              }
>     >            }
>     >
>     > Should the descriptions for received and sent be for "snooped IGMP
>     > packets"?
>     > The equivalent MLD structure probably also needs a similar fix.
>     >
>     >
>