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
tom petch <daedulus@btconnect.com> Tue, 30 April 2019 10:17 UTC
Return-Path: <daedulus@btconnect.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 14EEF1200E3; Tue, 30 Apr 2019 03:17:49 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 0.248
X-Spam-Level:
X-Spam-Status: No, score=0.248 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RATWARE_MS_HASH=2.148, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=btconnect.onmicrosoft.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 jISrWS27qMm6; Tue, 30 Apr 2019 03:17:45 -0700 (PDT)
Received: from EUR01-DB5-obe.outbound.protection.outlook.com (mail-eopbgr150131.outbound.protection.outlook.com [40.107.15.131]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 11EED1201A3; Tue, 30 Apr 2019 03:17:44 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=btconnect.onmicrosoft.com; s=selector1-btconnect-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=Guoh7IkfPo5Fw45J4ga+bZT/zbqXasDzjcehD/p5NLE=; b=KZodMy9aoPhWG1hWRBUvpi1qsV8rWdV+1/Gpj2uzao3/uRNR5+SHTnRag16iblFzybfKGWA2IPsm3vSO09Eg/MPaGPDuO54xVY7+NAaccfIQB62FDOoctyXmkk4kq40VP+Q+IV6H2fa2cXUEhrtB/mBqF6mAc3wrCUnQqp5wCwg=
Received: from AM5PR0701MB2994.eurprd07.prod.outlook.com (10.168.157.17) by AM5PR0701MB2578.eurprd07.prod.outlook.com (10.173.94.138) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.1856.6; Tue, 30 Apr 2019 10:17:42 +0000
Received: from AM5PR0701MB2994.eurprd07.prod.outlook.com ([fe80::f154:cf92:78af:f2cd]) by AM5PR0701MB2994.eurprd07.prod.outlook.com ([fe80::f154:cf92:78af:f2cd%6]) with mapi id 15.20.1856.008; Tue, 30 Apr 2019 10:17:42 +0000
From: tom petch <daedulus@btconnect.com>
To: Xufeng Liu <xufeng.liu.ietf@gmail.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>
Thread-Topic: 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
Thread-Index: AQHUtZg2w1Jomb9PTEC9rMWTxSatFA==
Date: Tue, 30 Apr 2019 10:17:41 +0000
Message-ID: <04c601d4ff3d$77e3e920$4001a8c0@gateway.2wire.net>
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>
Accept-Language: en-GB, en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-clientproxiedby: LO2P265CA0381.GBRP265.PROD.OUTLOOK.COM (2603:10a6:600:a3::33) To AM5PR0701MB2994.eurprd07.prod.outlook.com (2603:10a6:203:49::17)
authentication-results: spf=none (sender IP is ) smtp.mailfrom=daedulus@btconnect.com;
x-ms-exchange-messagesentrepresentingtype: 1
x-mailer: Microsoft Outlook Express 6.00.2800.1106
x-originating-ip: [86.139.215.234]
x-ms-publictraffictype: Email
x-ms-office365-filtering-correlation-id: 7757b1b0-c3c6-4aa2-07e7-08d6cd55144b
x-microsoft-antispam: BCL:0; PCL:0; RULEID:(2390118)(7020095)(4652040)(8989299)(4534185)(4627221)(201703031133081)(201702281549075)(8990200)(5600141)(711020)(4605104)(2017052603328)(7193020); SRVR:AM5PR0701MB2578;
x-ms-traffictypediagnostic: AM5PR0701MB2578:
x-ms-exchange-purlcount: 3
x-microsoft-antispam-prvs: <AM5PR0701MB2578D92716069C121F2EF869C63A0@AM5PR0701MB2578.eurprd07.prod.outlook.com>
x-ms-oob-tlc-oobclassifiers: OLM:8273;
x-forefront-prvs: 00235A1EEF
x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(366004)(346002)(39860400002)(136003)(376002)(396003)(189003)(199004)(51914003)(51444003)(54094003)(13464003)(66446008)(73956011)(97736004)(66476007)(64756008)(256004)(66556008)(53546011)(8936002)(6506007)(66946007)(386003)(8676002)(68736007)(26005)(186003)(102836004)(81166006)(486006)(81156014)(446003)(6246003)(4326008)(50226002)(14496001)(44736005)(86152003)(25786009)(6486002)(6436002)(14444005)(1556002)(229853002)(86362001)(6116002)(3846002)(53936002)(81816011)(81686011)(84392002)(93886005)(66574012)(99286004)(316002)(6306002)(52116002)(2906002)(305945005)(5660300002)(76176011)(7736002)(478600001)(66066001)(9686003)(54906003)(4720700003)(6916009)(476003)(966005)(44716002)(6512007)(71200400001)(61296003)(62236002)(14454004)(71190400001)(30864003)(74416001)(7726001); DIR:OUT; SFP:1102; SCL:1; SRVR:AM5PR0701MB2578; H:AM5PR0701MB2994.eurprd07.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; MX:1; A:0;
received-spf: None (protection.outlook.com: btconnect.com does not designate permitted sender hosts)
x-ms-exchange-senderadcheck: 1
x-microsoft-antispam-message-info: iesGMreWsumIaDtldd6AbXEiXsZVNWdLQEnuGBBtVOn/g/MHDlmhq49kaEu/AujrVVhshXZ8QAvrtzoUSiLt0N2U+ZvlIjLOZlwAKBQNr1PSg0QvBYxjUHwqbjXXGNFq51AQr0A0tXmAyRudtKuLeAvvp+wySfzZJqPML2Ms/OVSNBuI0GM6PEYMbtFb3DIg/Pb0fw/suTtTuFD+jmNy6ciSUH03WPWWCEtxLltAi6Y9uELluwkoedG7UiwxC9NKAPhVa8wcieO5MwdFD315qfikhxSeRjzfq4gf5cyL7QieKze9tax8KfPP7ny5BEAJ0WcYWxWQbGlfUUcHRNIsbDt5+EgbW5aeXLx6en8kjIxHyhYfejVm3nAZlb4vhzmhDvFLW3DNu1xPOoNDrgXPw8+h1YK6TM86QOctCcyAnWA=
Content-Type: text/plain; charset="utf-8"
Content-ID: <0099E507B0615D4C9C59849ED4FE08EA@eurprd07.prod.outlook.com>
Content-Transfer-Encoding: base64
MIME-Version: 1.0
X-OriginatorOrg: btconnect.com
X-MS-Exchange-CrossTenant-Network-Message-Id: 7757b1b0-c3c6-4aa2-07e7-08d6cd55144b
X-MS-Exchange-CrossTenant-originalarrivaltime: 30 Apr 2019 10:17:41.9554 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: cf8853ed-96e5-465b-9185-806bfe185e30
X-MS-Exchange-CrossTenant-mailboxtype: HOSTED
X-MS-Exchange-Transport-CrossTenantHeadersStamped: AM5PR0701MB2578
Archived-At: <https://mailarchive.ietf.org/arch/msg/pim/lVz31oN4E8wvFf61Qwu6Qsn8WDQ>
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: Tue, 30 Apr 2019 10:17:49 -0000
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. ACL is now RFC8519 which you have in the list of prefixes but not in the References for the I-D 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. s.3.2 likewise for mld 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 " 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). " 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 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:-) 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.
- [pim] Last Call: <draft-ietf-pim-igmp-mld-yang-10… The IESG
- Re: [pim] Last Call: <draft-ietf-pim-igmp-mld-yan… tom petch
- Re: [pim] Last Call: <draft-ietf-pim-igmp-mld-yan… tom petch
- Re: [pim] Last Call: <draft-ietf-pim-igmp-mld-yan… Xufeng Liu
- Re: [pim] Last Call: <draft-ietf-pim-igmp-mld-yan… Xufeng Liu
- Re: [pim] Last Call: <draft-ietf-pim-igmp-mld-yan… tom petch
- Re: [pim] Last Call: <draft-ietf-pim-igmp-mld-yan… Xufeng Liu
- Re: [pim] Last Call: <draft-ietf-pim-igmp-mld-yan… tom petch
- Re: [pim] Last Call: <draft-ietf-pim-igmp-mld-yan… Xufeng Liu