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

[Nemesis]

I try to explain a meta issue that has arised during this round 2. I
think this issue is very important, at least to me.

I started to think about it after these questions:

  * Why would you configure the amount of RAM available on the hardware?
    This is a property of the configured device and not a configuration
    option

  * Ok, but since this is device configuration, how can I configure a
    specific firmware version? For example in wlan slovenija, we have a
    field that can specify the exact version that should be installed
    (or null in case the default version should be used).

I don't think this JSON should contain only configurations that can be
changed by a certain type of software.

I'm not so convinced anymore that calling it "network device
configuration" it's appropiate.

We said that we are not trying to do something too broad and that's
great but we also should not limit too much its scope, immagine this:

virtual devices, linux containers. Someone might develop a system where
you can configure the ram, disk space and other things.

I would like this schema to be able to represent the attributes of
something that it is reachable via a layer2 or layer3 network, even a
virtual-device (immagine hardware unit testing), after all the
discussion I think this schema should have a static part (what we are
doing right now) and a "dynamic" part that is dedicated to attributes
that change rapidly over time (what we before called the
monitoring/telemetry data), pheraphs the two might be used either
together in a single object or separately, that would also be very useful.

This schema should have very few required fields, only the very bare
minimum that is common to all the network objects, this allow the
different implementations to use only what they need.
As we said, it should be subdivided in parts that can be extended, and
implementations should ignore unknown fields.

But it would be VERY useful to MANY people, not just us doing community
networks, if this schema included also (with optional attributes)
information like ram, disk space, cpu and other attributes that are not
strictly related to the fact that you can change its configuration.

Immagine data mining, you could use a library that can extract
information from the network and returns this schema, when you are doing
data mining it is very useful to know ram, cpu, operating system and
many other information you cannot strictly change from its configuration.

I immagine that a software that manages configurations might use only
the attributes that can be changed, while a software that returns all
the info of a device might return all the static attributes, a software
that does monitoring might use only the monitoring data while an HTTP
API might return everything, including the monitoring data in one single
response.

By allowing this flexibility we can lay the ground for something that
could be used by many people, and if many libraries and softwares that
deal with networks start using a common schema it will mean that the
resulting eco system will be richer, which would be very good for everyone.

Federico


On 11/03/2014 08:00 PM, Jernej Kos wrote:
> Hello!
>
> There are some problems with this schema, especially regarding radios
> and VIFs. Radios are not network interfaces and can't have things like
> IP addresses and MTUs configured. Only VIFs are network interfaces.
>
> I have also added inline comments to Google Docs.
>
>
> Jernej
>
> On 03. 11. 2014 19:18, Nemesis wrote:
>> Hey,
>>
>> my latest commits:
>> https://github.com/interop-dev/network-device-schema/compare/937d506ba9...955122b723
>>
>> I removed most of the dynamic attributes, we can define that in a
>> separate step(hopefully soon!).
>>
>> I think mitar's suggestion that we should implement it in a way that
>> parsers ignore unknown arguments is the way to go.
>>
>> I copied the JSON example here:
>> https://docs.google.com/document/d/13uNsnvV4lLjuAf1qXdztXp_kg_uzcfPwjaXGNmzarvE/edit
>> disable "*print layout*" from "*view > print layout*".
>>
>> I hope we can do a few fast iterations there by using the inline
>> comments. Github and email only for this task is a bit clunky.
>>
>> I'm adding a few comments about doubts I have right now.
>>
>> I propose to keep discussing "meta" issues here via email,
>> whilediscussing issues about the schema (eg: why is this info here and
>> not there, is this argument required? ecc.) there on the document.
>>
>> Please participate with some comments so that you can receive further
>> notifications about replies.
>>
>> Federico
>>
>> PS: i'm cross posting this to other ninux lists (ninux-devand nodeshot),
>> for those who haven't followed the entire discussion, hereit is:
>> https://lists.funkfeuer.at//pipermail/interop-dev/2014-October/000169.html
>> https://lists.funkfeuer.at//pipermail/interop-dev/2014-November/000192.html
>>
>>
>>
>> _______________________________________________
>> Interop-dev mailing list
>> (spam-protected)
>> https://lists.funkfeuer.at/mailman/listinfo/interop-dev
>>
>
>
> _______________________________________________
> Interop-dev mailing list
> (spam-protected)
> https://lists.funkfeuer.at/mailman/listinfo/interop-dev

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.funkfeuer.at/pipermail/interop-dev/attachments/20141105/cb383aec/attachment.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 490 bytes
Desc: OpenPGP digital signature
URL: <http://lists.funkfeuer.at/pipermail/interop-dev/attachments/20141105/cb383aec/attachment.sig>