-13 looks good. Security considerations mentions the use of NACM; some authors put a default deny all under the Action or RPC; is clearing statistics that sensitive? Up to you. And as the YANG doctor implied, there are two lower case 'should' which may or may not call for the RFC8174 boilerplate - I have lost track of what we are meant to do if we only have lower case. Tom Petch ----- Original Message ----- From: tom petch <daedulus@xxxxxxxxxxxxx> Sent: 11/06/2020 12:19:48 ________________________________________________________________________________ --- New Outlook Express and Windows Live Mail replacement - get it here: https://www.oeclassic.com/ Separately, two more YANG quirks The augment have no conditional - rather the YANG 'when' is one level down on the container, not something I am used to nor the practice in other pim yang. YANG must be plain text - [RFC 4541] looks like a markup Tom Petch On 10/06/2020 12:44, tom petch wrote: > > The RPC to clear the tables are somewhat insecure. The default is to clear all so a mistake in entering a valid address will clear everything. It would be more secure to have an explicit option for clear all. > > The RPC to clear the tables has no restrictions; a NACM deny all might be appropriate > > RPC or ACTION? the latter may be suitable. > > RFC5790 is referenced by the YANG module but is not in the I-D References > > feature feature* is unusual; that an identifier is a feature is usually apparent from the context in which the identifier is used and so including 'feature' in the name is redundant > > And to state the obvious the formatting lacks leading spaces which will doubtless get fixed some time. > > Tom Petch > > > > ----- Original Message ----- > From: tom petch <ietfid@xxxxxxxxxxxxx> > To: tom petch <daedulus@xxxxxxxxxxxxx> > Sent: 10/06/2020 12:31:25 > Subject: Fw: Last Call: <draft-ietf-pim-igmp-mld-snooping-yang-12.txt> (A Yang Data Model for IGMP and MLD Snooping) to Proposed Standard > ________________________________________________________________________________ > > > > ________________________________________ > From: IETF-Announce <ietf-announce-bounces@xxxxxxxx> on behalf of The IESG <iesg-secretary@xxxxxxxx> > Sent: 01 June 2020 14:10 > To: IETF-Announce > Cc: draft-ietf-pim-igmp-mld-snooping-yang@xxxxxxxx; pim-chairs@xxxxxxxx; pim@xxxxxxxx > Subject: Last Call: <draft-ietf-pim-igmp-mld-snooping-yang-12.txt> (A Yang Data Model for IGMP and MLD Snooping) to Proposed Standard > > > The IESG has received a request from the Protocols for IP Multicast WG (pim) > to consider the following document: - 'A Yang Data Model for IGMP and MLD > Snooping' > <draft-ietf-pim-igmp-mld-snooping-yang-12.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 > last-call@xxxxxxxx mailing lists by 2020-06-15. Exceptionally, comments may > be sent to iesg@xxxxxxxx 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) Snooping devices. The YANG module in this > document conforms to Network Management Datastore Architecture (NMDA). > > > > > The file can be obtained via > https://datatracker.ietf.org/doc/draft-ietf-pim-igmp-mld-snooping-yang/ > > > > No IPR declarations have been submitted directly on this I-D. > > > The document contains these normative downward references. > See RFC 3967 for additional information: > rfc4541: Considerations for Internet Group Management Protocol (IGMP) and Multicast Listener Discovery (MLD) Snooping Switches (Informational - IETF stream) > > > > > _______________________________________________ > IETF-Announce mailing list > IETF-Announce@xxxxxxxx > https://www.ietf.org/mailman/listinfo/ietf-announce > -- last-call mailing list last-call@xxxxxxxx https://www.ietf.org/mailman/listinfo/last-call -- last-call mailing list last-call@xxxxxxxx https://www.ietf.org/mailman/listinfo/last-call
