[Interop-dev] Round 2: Network Device Config JSON Schema

[Nemesis]

Hi Ralf,

On 11/10/2014 12:02 PM, Ralf Schlatterbeck wrote:
> Just joining the discussion now, thanks Federico for starting this.
> I'm referring to the google docs document, not the github version
> (which I haven't compared, it might be the same).

Thank you for joining the discussion.

> Several points from my side:
> - My use-cases come mostly from a node database perspective

I see your point.

I think i'm not wrong if I say that we discussed that this schema should
not be concerned too much about the different node-db implementations,
it should be concerned mostly about what is the lowest common
denominator of the attributes needed to represent a network device: its
configuration, its hardware attributes, its software and return this
information as a JSON schema that is shared by our libraries and
applications.

All the attributes should be optional and consumers should ignore all
unknown attributes.

> - We currently distinguish a device from a device type.
>   The latter contains all attributes that are common to a device
>   made by a certain manufacturer, e.g. Linksys WRT54GL.
>   We have the following attributes there some of which we may
>   want to add to our common schema:
>   - name (e.g. Linksys WRT54GL)
>   - model_no (e.g. WRT54GL)
>   - revision: Devices often come in several revisions that may
>     *completely* change the hardware in the device. The model number
>     usually doesn't change. An example for complete hardware change with
>     revision number is the ASUS WL500G Premium, see
>     http://wiki.openwrt.org/toh/asus/wl500gp (sorry for an example with
>     a very old device, I happen to have several of these)
>   - The manufacturer is a company, we model companies (with lots of
>     optional attributes like address and phone number) as a separate
>     entity and link it to the device type.
>
>   The device would get all the attributes that are *not* common
>   to all devices-types made by a manufacturer. This includes
>   (static) configuration like IP addresses.
>
>   I *think* the current hardware section captures some of
>   the attributes above, I'd add revision and flash memory.
>   Our use-case for capturing the hardware attributes separately
>   is that most users really don't know much about their device,
>   so they can simply chose something pre-configured.
>   I would also keep the *typical* RAM, Flash, and CPU Frequency
>   configuration for the device there. If we later model more complex
>   devices where some of these aspects can be changed we could override
>   this in another section that only applies to the concrete device.
>   I've added my comments to the hardware section.

To recap:

  * model_revision
  * CPU_frequency
  * Flash_memory


> - We have an optional "description" attribute for almost anything, this
>   is very useful for comments and a more verbose description. Since we
>   said that attributes would be optional, I'd add that in.

We also have it in nodeshot, although it is a node-db related
information and not strictly something that is stored in the device
configuration.

I'm ok to add it if needed.

> - Regarding 'maintainer' in the general section: We have quite a complex
>   model for persons and legal entities, and several attributes for
>   ownership and maintainership of a device. In fact we store this info
>   not with the device but with the node (to which the device belongs).
>   Although this decision has spawned some discussions.
>   So I'd vote for a separate section for modelling ownership and not put
>   this into an attribute of the device. Note that Funkfeuer thinks that
>   personal information should be visible only to members of the network,
>   not generally in an API (privacy issue).

Regarding this attribute, it's contained in the SNMP responses of the
default snmp agent on OpenWRT, so I was just mirroring what is there.

I think the attribue should be there even if some communities do not use
it (for whatever reason).

A potential openwrt-agent that returns the JSON might be configured to
not show certain attributes like this one.

> - Since we currently aim at wireless devices I'd vote for 'firmware' and
>   'firmware_version' instead of os. Note that the os type and -version
>   might be attributes of a separate firmware datatype to be modelled
>   later.

In ninux we are not interested only in wireless devices.

Infact I'm working both in my daily job and with ninux on servers, linux
containers (I know in confine they're using virtual boxes on research
devices that can be used by community networkers too to host their
private services) and sensors (lots of fablabs interested in our network
and I guess yours too).

A possible solution would be to have two different terms, one for os and
one for firmware.

Since it's common to name a firmware <my cool firmware name>OS I thought
"os" would be enough. Managing only one attribute would be also easier
from the point of view of a programmer who is implementing something
that deals with different device types.

I hope we can find an agreement on these last attributes soon so I'll
proceed with iteration round 3.

It's also useful to recap all this discussion in a short structured
summary in the README.

Federico
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.funkfeuer.at/pipermail/interop-dev/attachments/20141110/4471b929/attachment.html>