Re: [netmod] Inventory YANG model (entity-MIB)

Hi Mahesh, 

Agree that the detailed data model for Ethernet Bridging would belong to IEEE 802.1Q.

The inventory model just provide a summary of the functions and capabilities the network nodes and components can support, and Ethernet Bridging is just listed as one of the capabilities.

Best regards,
Jie

> -----Original Message-----
> From: Mahesh Jethanandani [mailto:mjethanandani@gmail.com]
> Sent: Thursday, March 12, 2015 12:15 AM
> To: Juergen Schoenwaelder
> Cc: Dongjie (Jimmy); i2rs-chairs@tools.ietf.org;
> draft-dong-i2rs-network-inventory@tools.ietf.org; NETMOD Working Group
> Subject: Re: [netmod] Inventory YANG model (entity-MIB)
> 
> And I would suggest that Ethernet Bridging Model is something that needs to be
> modeled by IEEE 802.1Q WG, where I have just submitted a PAR for discussion
> to develop just that.
> 
> Mahesh Jethanandani
> mjethanandani@gmail.com
> 
> > On Mar 11, 2015, at 11:22 AM, Juergen Schoenwaelder
> <j.schoenwaelder@jacobs-university.de> wrote:
> >
> >> On Wed, Mar 11, 2015 at 09:43:21AM +0000, Dongjie (Jimmy) wrote:
> >>
> >> As described in the -00 version of draft-dong-inventory, the "generic features
> and capabilities" means the networking functions and services that the network
> nodes and components can provide, e.g. IP unicast, multicast, ethernet bridging,
> mpls, traffic-engineering, etc. The set of the functions will be completed in
> future revision. Our intention is to abstract those control plane independent
> functions in this model, and let the protocol specific models to cover the details
> of each protocol.
> >
> > I think this is not how we organize work in the IETF. If a device
> > supports ethernet briding (for example), it will announce an ethernet
> > bridging data model that is extending the generic interface data model
> > with ethernet bridging specific configuration and state objects. This
> > has already been done for IP and it follows the way the IETF
> > previously organized MIB modules. This is also largely how routing
> > data models that are currently written are organized (a core routing
> > data model plus routing protocol specific extensions).
> >
> > I do not think that what you are describing fits into the scope of an
> > inventory data model given the way the IETF used partion work so far.
> >
> > /js
> >
> > --
> > 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
> > netmod@ietf.org
> > https://www.ietf.org/mailman/listinfo/netmod