Re: [pim] [Last-Call] Last Call: <draft-ietf-pim-igmp-mld-snooping-yang-12.txt> (A Yang Data Model for IGMP and MLD Snooping) to Proposed Standard

[tom petch <[e-mail]>]

-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 <[e-mail]>
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 <[e-mail]>
> To: tom petch <[e-mail]>
> 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 <[e-mail]> on behalf of The IESG <[e-mail]>
> Sent: 01 June 2020 14:10
> To: IETF-Announce
> Cc: [e-mail]; [e-mail]; [e-mail]
> 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
> [e-mail] mailing lists by 2020-06-15. Exceptionally, comments may
> be sent to [e-mail] 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
> [e-mail]
> https://www.ietf.org/mailman/listinfo/ietf-announce
>

-- 
last-call mailing list
[e-mail]
https://www.ietf.org/mailman/listinfo/last-call