<html>
<head>
<meta content="text/html; charset=ISO-8859-1"
http-equiv="Content-Type">
</head>
<body bgcolor="#FFFFFF" text="#000000">
<div class="moz-cite-prefix">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.<br>
<br>
<meta http-equiv="content-type" content="text/html;
charset=ISO-8859-1">
I started to think about it after these questions:<br>
<ul>
<li>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<br>
<br>
</li>
<li>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).<br>
</li>
</ul>
I don't think this JSON should contain only configurations that
can be changed by a certain type of software.<br>
<br>
I'm not so convinced anymore that calling it "network device
configuration" it's appropiate.<br>
<br>
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:<br>
<br>
virtual devices, linux containers. Someone might develop a system
where you can configure the ram, disk space and other things.<br>
<br>
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.<br>
<br>
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.<br>
As we said, it should be subdivided in parts that can be extended,
and implementations should ignore unknown fields.<br>
<br>
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.<br>
<br>
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.<br>
<br>
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.<br>
<br>
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.<br>
<br>
Federico<br>
<br>
<br>
On 11/03/2014 08:00 PM, Jernej Kos wrote:<br>
</div>
<blockquote cite="mid:5457D0D7.70609@kos.mx" type="cite">
<pre wrap="">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:
</pre>
<blockquote type="cite">
<pre wrap="">Hey,
my latest commits:
<a class="moz-txt-link-freetext" href="https://github.com/interop-dev/network-device-schema/compare/937d506ba9...955122b723">https://github.com/interop-dev/network-device-schema/compare/937d506ba9...955122b723</a>
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:
<a class="moz-txt-link-freetext" href="https://docs.google.com/document/d/13uNsnvV4lLjuAf1qXdztXp_kg_uzcfPwjaXGNmzarvE/edit">https://docs.google.com/document/d/13uNsnvV4lLjuAf1qXdztXp_kg_uzcfPwjaXGNmzarvE/edit</a>
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:
<a class="moz-txt-link-freetext" href="https://lists.funkfeuer.at//pipermail/interop-dev/2014-October/000169.html">https://lists.funkfeuer.at//pipermail/interop-dev/2014-October/000169.html</a>
<a class="moz-txt-link-freetext" href="https://lists.funkfeuer.at//pipermail/interop-dev/2014-November/000192.html">https://lists.funkfeuer.at//pipermail/interop-dev/2014-November/000192.html</a>
_______________________________________________
Interop-dev mailing list
<a class="moz-txt-link-abbreviated" href="mailto:Interop-dev@lists.funkfeuer.at">Interop-dev@lists.funkfeuer.at</a>
<a class="moz-txt-link-freetext" href="https://lists.funkfeuer.at/mailman/listinfo/interop-dev">https://lists.funkfeuer.at/mailman/listinfo/interop-dev</a>
</pre>
</blockquote>
<pre wrap="">
</pre>
<br>
<fieldset class="mimeAttachmentHeader"></fieldset>
<br>
<pre wrap="">_______________________________________________
Interop-dev mailing list
<a class="moz-txt-link-abbreviated" href="mailto:Interop-dev@lists.funkfeuer.at">Interop-dev@lists.funkfeuer.at</a>
<a class="moz-txt-link-freetext" href="https://lists.funkfeuer.at/mailman/listinfo/interop-dev">https://lists.funkfeuer.at/mailman/listinfo/interop-dev</a>
</pre>
</blockquote>
<br>
</body>
</html>