Subject: [netmod] Structure of data models

From: <[email-masked]>
Date: Mon, 21 May 2012 15:51:19 +0100

Hi,

As a newcomer to writing and implementing YANG modules, I have a general
question. I am trying to create a data model for radios. Should the
radio data model comprise a set of independent top-level modules that
address different aspects of radio configuration (system management,
routing, airside interface, etc.), or should there be one top-level
module that imports and includes modules and submodules? And if it is
personal preference, is there at least a strong steer one way or the
other?

Thanks,

Jonathan Hansford 

This email and any files attached are intended for the addressee and may contain information of a confidential nature. If you are not the intended recipient, be aware that this email was sent to you in error and you should not disclose, distribute, print, copy or make other use of this email or its attachments. Such actions, in fact, may be unlawful. In compliance with the various Regulations and Acts, General Dynamics United Kingdom Limited reserves the right to monitor (and examine for viruses) all emails and email attachments, both inbound and outbound. Email communications and their attachments may not be secure or error- or virus-free and the company does not accept liability or responsibility for such matters or the consequences thereof. General Dynamics United Kingdom Limited, Registered Office: 21 Holborn Viaduct, London EC1A 2DY. Registered in England and Wales No: 1911653.

---

From: Ladislav Lhotka <[email-masked]>
Date: Mon, 21 May 2012 17:07:13 +0200

Hi,

On May 21, 2012, at 4:51 PM, <[email-masked]> wrote:

> As a newcomer to writing and implementing YANG modules, I have a general question. I am trying to create a data model for radios. Should the radio data model comprise a set of independent top-level modules that address different aspects of radio configuration (system management, routing, airside interface, etc.), or should there be one top-level module that imports and includes modules and submodules? And if it is personal preference, is there at least a strong steer one way or the other?

Both are possible although the first option (multiple top-level modules) is simpler and the existing NETMOD modules use it.

Lada

--
Ladislav Lhotka, CZ.NIC Labs
PGP Key ID: E74E8C0C

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Mon, 21 May 2012 18:49:45 +0200

> Both are possible although the first option (multiple top-level modules) is simpler and the existing NETMOD modules use it.

Simpler tends to be subjective. ;-) What we need is a simple to
understand list of technical trade-off so that people can determine
for themself what is best concerning their requirements. Using
submodules for instance makes related stuff live in one namespace,
using multiple modules requires to deal with a different namespace for
each module. Using one gigantic module might make change management
complicated (but that again depends how stuff is 'published'). In
other words, we would need a list of criteria and then people have
something to work through in order to make their own informed
decision.

/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/>

---

From: Martin Bjorklund <[email-masked]>
Date: Mon, 21 May 2012 22:46:19 +0200 (CEST)

Juergen Schoenwaelder <[email-masked]> wrote:
> > > question. I am trying to create a data model for radios. Should the radio
> > > data model comprise a set of independent top-level modules that address
> > > different aspects of radio configuration (system management, routing,
> > > airside interface, etc.), or should there be one top-level module that
> > > imports and includes modules and submodules? And if it is personal
> > > preference, is there at least a strong steer one way or the other?
> > 
> > Both are possible although the first option (multiple top-level modules) is
> > simpler and the existing NETMOD modules use it.
> > 
> 

Another thing to think about is if existing generic data models can be
used.  I do not know enough about this radio config to know if it
makes sense to use the ietf-interface model for the "airside
interfaces", or if the ietf-routing framework could be used for this
routing.

/martin

---

From: Ladislav Lhotka <[email-masked]>
Date: Tue, 22 May 2012 10:38:19 +0200

On May 21, 2012, at 4:51 PM, <[email-masked]> <[email-masked]> wrote:

> As a newcomer to writing and implementing YANG modules, I have a general question. I am trying to create a data model for radios. Should the radio data model comprise a set of independent top-level modules that address different aspects of radio configuration (system management, routing, airside interface, etc.), or should there be one top-level module that imports and includes modules and submodules? And if it is personal

Just one note: importing a module doesn't mean that the data tree of the imported module becomes part of the importing module's tree - it only makes top-level groupings, typedefs etc. available inside the importing module.

Lada

---

From: <[email-masked]>
Date: Tue, 22 May 2012 09:46:06 +0100

So if the imported module has a top-level container with everything you
want, but you need to augment some nodes, you need to define an
equivalent top-level container as well as the augmentation?

Jonathan

> -----Original Message-----
> From: Ladislav Lhotka [mailto:[email-masked]]
> Sent: 22 May 2012 09:38
> To: Jonathan Hansford
> Cc: [email-masked]
> Subject: Re: [netmod] Structure of data models
> 
> 
> On May 21, 2012, at 4:51 PM,
<[email-masked]>
> <[email-masked]> wrote:
> 
radio
> Just one note: importing a module doesn't mean that the data tree of
the
> imported module becomes part of the importing module's tree - it only
> makes top-level groupings, typedefs etc. available inside the
importing
> module.

---

From: Ladislav Lhotka <[email-masked]>
Date: Tue, 22 May 2012 11:59:34 +0200

> equivalent top-level container as well as the augmentation?

I am not sure that I understand your question but:

If module A imports module B, it can augment stuff anywhere in the B's data tree. However, in order to get the augmented module B into your data model, you have to advertise both A and B in <hello>.

Lada

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Tue, 22 May 2012 12:13:13 +0200

> If module A imports module B, it can augment stuff anywhere in the B's data tree. However, in order to get the augmented module B into your data model, you have to advertise both A and B in <hello>.

... because this is the way you get to know the different namespaces
that are involved.

/js

---

From: "Romascanu, Dan (Dan)" <[email-masked]>
Date: Tue, 22 May 2012 13:12:50 +0200

> From: [email-masked] [mailto:[email-masked]] On
> Behalf Of Martin Bjorklund
> Sent: Monday, May 21, 2012 11:46 PM
> To: [email-masked]
> Cc: [email-masked]; [email-masked]
> > > wrote:
> > > > airside interface, etc.), or should there be one top-level
module
> that

[[DR]] ... which is an implicit argument for the multiple top-level
design. 

Dan