[Interop-dev] Network Device JSON Schema

[Nemesis]

Hi everybody,

I'm back from the US, sorry for responding so late, I had a very bad jetlag.

let me clarify:

initially my intention was to define a representation of a network device:

  * device name
  * device model
  * hardware stuff that is easy to retrieve programmatically
  * configuration of interfaces
  * wireless configuration

I was not attempting - *yet* - to define a standard for node monitoring,
but we can work on it in parallel, I'd be happy to deal with it sooner
rather than later.

It's true that the schema contains also dynamic attributes (like noise
and dbm) which change over time, and after you pointed that I realized
it might not have sense to put it there.

But that's why I like doing stuff collaboratively, rather than by
myself, I know that by doing it alone it would take me years to get it
right, and moreover, we risk doing everyone a different thing that is
not able to talk to each other, it would be much better to do it
together than one group or one person going solo.

We could start to define a few object to start with.

I see that we have two different priorities:

  * network device configuration
  * monitoring data

Latelly i've been working more on the network device configuration
object, which I simplified by calling it network-device-schema.

@Ralf:
I have taken a look at the link you posted.

What I'm trying to do is related but slightly different.
It's not an API, but a JSON schema that I would like to use to represent
some of those points listed in
https://github.com/Common-Node-DB/paper/blob/master/common-api.txt (eg:
net device, net interfaces, net wireless)

You can immagine it like GeoJSON which is widely used in GIS apps and
GIS libraries.
You can pass a GeoJSON to most GIS low level libraries and it will be
converted to a geographic object of that specific library, that approach
has been very successfull.

It would be really cool if we could define a schema for network "stuff"
that we could pass to libraries and apps like it already happens with
GeoJSON.

One example:

 1. web app A returns NetJSON from its HTTP API
 2. library B parses the NetJSON and does some calculations
 3. library B passes the NetJSON to web app C
 4. web app C converts the NetJSON in its own specific database object

app A, library B and web app C might be developed by completely
different people, in different communities, from opposite sides of the
world, but would be collaborating in creating an ecosystem rather than
redeveloping apps and libraries that do not talk to each other like we
have been doing latelly. The problem with what we have been doing
latelly is that every project is all or nothing: you either buy the
entire stack or redevelop your own, like proprietary systems :-D :-P

Sure we should split the NetJSON in more components, and we can surely
work on it in parallel.

So my next questions are

  * is it clearer now? If not I might spend some more time trying to
    explain myself clearer
  * do you think it's worth it? if not could you explain what
    alternative you would prefer?
  * do you have time to start collaborating on defining the components
    you are most interested in?
  * which are the components you are most interested in right now?

Federico


On 10/28/2014 07:43 AM, L. Aaron Kaplan wrote:
> On Oct 28, 2014, at 7:27 AM, Jernej Kos <(spam-protected)> wrote:
>
>> Hello!
>>
>> On 28. 10. 2014 03:14, Nicolás Echániz wrote:
>>> So... uptime is the only "telemetry" information in that document?
>> No, all attributes could be interpreted as telemetry (reports about
>> addresses and MTU configured on interfaces, we have all that in our
>> nodewatcher-agent telemetry reports, routing protocol package versions,
>> etc.).
>>
>> Also see the "dbm" and "noise" reported on the wireless radio.
>>
>> So Federico should comment if this is meant as static configuration
>> and/or network device telemetry. I still believe it is the latter.
> I believe the most useful for us right now would be static config.
> At lest from my perspective. For sure, telemetry is *also* important, but for me personally right now it has a lower importance value.
>
> my 2 cents,
> a.
>
>>
>> Jernej
>>
>> _______________________________________________
>> 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/20141101/b2c6eb5d/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/20141101/b2c6eb5d/attachment.sig>