A logical entity in the ENTITY-MIB boils down to the SNMP parameters needed to talk to an SNMP agent that provides a context view on say a bridge. This all was needed because the original bridge MIB module design was not prepared to expose virtual lans, multiple spanning trees etc. I assume that YANG data model written for bridges in the 21st century would be able to expose that without requiring contexts (that do not even exist as a concept in YANG/NETCONF/RESTCONF). Perhaps the closest are schema mounts.
/js On Tue, Aug 22, 2017 at 08:28:40PM +0000, Marta Seda wrote: > RFC6933 Entity MIB contains the following tables: > > * entPhysicalContainsTable (this is modeled in ietf-hardware-yang > module) > * entLPPhysicalTable (describes the mapping of logical entities and > physical components supporting that entity). > > There are some solution spaces that need to support logical entities (e.g., > bridges, and other virtual entities). The draft-ietf-netmod-entity-04 only > addresses the entPhysicalContains Table. Could someone comment as to the > reason for the omission of logical entities? Is this by design > (ietf-netmod-entity is intended only to cover physical components and > physical ports)? Or simply that it has not been gotten around to? > > Thank you. > > Regards, > > Marta Seda > Calix > > _______________________________________________ > netmod mailing list > [email protected] > https://www.ietf.org/mailman/listinfo/netmod -- Juergen Schoenwaelder Jacobs University Bremen gGmbH Phone: +49 421 200 3587 Campus Ring 1 | 28759 Bremen | Germany Fax: +49 421 200 3103 <http://www.jacobs-university.de/> _______________________________________________ netmod mailing list [email protected] https://www.ietf.org/mailman/listinfo/netmod
