Some link present on the website would do better on a dedicated content page rather than a section in the github README.

In particular I'm referring to:

• motivations and goals
• implementations
• how to send feedback
• how to register extensions
• FAQs

The phy field should probably be required.

See this mail and the related follow-up: https://lists.funkfeuer.at/pipermail/interop-dev/2015-May/000405.html

Hi,

I have just started on this and noticed a small problem...

olsrd2 is "multitopology capable", which means it can run multiple
topologies at the same time.

How do we resolve this for the "routes" and "graph" output? Do we need
to add another layer which allows multiple metrics, each with
graph/routes?

Henning

See also: https://lists.funkfeuer.at/pipermail/interop-dev/2015-May/000406.html

Okay,

first implementation is finished (is available as the
"json_for_networks" plugin in the OONF repository), but I think we
need a few changes in our JSON definition.

I have attached both "routes" and "graph" output of my plugin, that
should make it easier to explain the changes.

The major change is a new level of indirection, both for routes and
graph objects to allow multiple topologies for both of them. This is
relevant for dualstack support, because olsrv2 has a different
"originator ID" for IPv4 and IPv6. It would also become very useful
for running multiple routing metrics at the same time.

Attachements:

• graph.json http://lists.funkfeuer.at/pipermail/interop-dev/attachments/20150528/e9b7ed5a/attachment.json
• routes.json http://lists.funkfeuer.at/pipermail/interop-dev/attachments/20150528/e9b7ed5a/attachment-0001.json

Add detailed specification of "wireless", "encryption" and "addresses" for the DeviceConfiguration object.

Things like:

"load": {
                "type": "array",
                "items": [
                    {
                        "type": "number"
                    },
                    {
                        "type": "number"
                    },
                    {
                        "type": "number"
                    }
                ]
            },

Are wrong. Better use attributes like minItems and maxItems.

Not sure if this is the best place to comment on the RFC, but I see that for key names there are only primitive JSON types specified. Wouldn't it be better if a JSON schema type with JSON schema formatter definition would also be specified?

And along the lines of #45, it would be great if a semantic URI of the key definition would be specified/defined. It would be great to have semantic schema definitions for network objects in the standard.

sent by Thijs van Veen

In the Route object, you suggest a Device field to reference the
actual interface you're targeting.
I suggest changing the name Device to Destination Interface or something
similar to differentiate in terminology between devices (nodes) and
their interfaces.

We forgot to address this.

Is there difference between phy0 and radio0?

In the nodewatcher-agent example posted in #1 both are mentioned but only radio0 has a definition.

Via openwrt ubus I see no mention of any phy object, but I see mention of radio0 (via ubus call network.wireless status, just it doesnt have the information contained in our physical_devices section, but something slightly different.

Via the iw command I see that interfaces reference a phy object, and iw phy returns all the capabilities of the physical device.

I am a bit confused. Can anyone bring some clarity?

See: https://lists.funkfeuer.at/pipermail/interop-dev/2015-May/000406.html

The last change was in the Routes object... I have added a "next-id"
field, which will contain the router_id of the next hop. This is VERY
useful when you work with linklocal IPs, because you cannot recognize
the next-hop router by the IP!

Add same pattern attribute as interface name.

a state can be: up or e.g. broken.
or what is a good method for visualizing that?

• make clear what an ID is (eg: can it be also a non-address, like a hash?)
• you use the concept of ID also for routes but you expect addresses, please clarify
• which attributes do refer to IDs in NetworkGraph and NetworkRoutes

Different protocols can use different metrics which might be converted to a different textual representation.

How to deal with this problem?

• an additional attribute with a textual representation for each link
• one attribute for the entire NetworkGraph object

A third option would be:

• delegate the interpretation to the consumer application and discuss this issue again when we have more implementations.

Rename revision to version.

arbitrary is not spelled correctly and "These" has a capital letter that shouldn't be there.

While JSON schema is useful to validate if the JSON is of valid structure and types, JSON-LD allows one to assign semantic values to the JSON properties. This allows then even greater interoperability. I started looking into this for nodewatcher and the idea is that if we describe nodewatcher API with JSON-LD, and netjson with JSON-LD, then we get automatically convert between each other. So then our API REST endpoint can offer multiple formats, JSON (plain nodewatcher structure), JSON-LD (JSON with added JSON-LD @context attributes) and netjson (JSON-LD converted to netjson using netjson JSON-LD specification).

So, at least theoretically, this would allow us to define schemas for our APIs only once and then interchange them even if they are internally stored differently.

Because netjson is very similar to our nodewatcher API I think this could be a good proof of concept if we can get it to work.

So what we will have to do is annotate each property of netjson with its definition URI (often URI which points to https://schema.org/, or some other common schema from http://vocab.cc, http://lov.okfn.org/dataset/lov). Probably we would have to define some our own, which is also good and could be hosted at the netjson domain.

See a similar attempt at GeoJSON: https://github.com/geojson/geojson-ld
And their definition of properties: http://geojson.org/vocab
And JSON-LD context: http://geojson.org/contexts/geojson-base.jsonld

We could then create:

• http://netjson.org/vocab for netjson specific property definitions (like routing metrics and stuff, which probably does not exist elsewhere), those same would then be used by nodewatcher JSON-LD context
• http://netjson.org/contexts/v1.0/base.jsonld

So even if maybe our APIs have fields in different places inside JSON, they do share meaning of fields. (Moreover, it would be interesting to see for which fields we understand different meaning.)

cc @kostko

@kostko, can you show a full example of how nodewatcher agent outputs device (router) description? I talked with @nemesisdesign about trying to create a common schema for that.

ipv6 ula_prefix is currently missing from the spec.

It could go in the general section.

Remove the specification from the README and link the RFC instead. This way we avoid duplication of efforts and we keep the README small.

Should we model the static routes of a device (what's in ip route or route -n)?

Ubus does this but inserts the routes in each interface (same for dns-servers and dns-search).

Since we have one dns_servers block and one dns_search block, it would make sense to make a single routes section for consistency, unless we think it's more practical to have this information stored at interface level like ubus does.

Since Henning Rogge (core OLSR developer) confirmed that we can reuse the structure in https://github.com/interop-dev/json-for-networks/blob/master/examples/network-routes.json also for static routes (https://lists.funkfeuer.at///pipermail/interop-dev/2014-November/000308.html) we could add something like this to DeviceConfiguration:

"routes": [
        {
            "destination": "ID",
            "source": "ID",
            "next" : "ID",
            "device": "DEVICE",
            "cost": 1
        }
]

sent by Thijs van Veen

You suggest a Source field for source-specific routing.
I suggest adding a Source Interface field, this way (it seems to me) you
can more easily handle multi-interface devices.

In my experiences, multi-interface devices have always caused issues
when trying to describe them and it would be great to take care of that
issue in what is supposed to become a standard.

We forgot to address this

How to deal with infinity?

Perhaps the best thing would be to forbid links with infinite weight because they are not usable so it's like not having them.

We need a protocol attribute that can be either 802.11n, 802.11ac, 802.11a, 802.11b, 802.11g, ecc.

Theid attributes are used incorrectly, they have to be removed from the schemas.

See openwisp/netjsonconfig#37

There are a few attributes in the JSON Schema definitions for which it would be more appropiate to use "Integer" instead of "number".

See http://ml.ninux.org/pipermail/battlemesh/2016-May/004953.html

I believe adding a "Goals" statement under each definition (eg: NetworkGraph, DeviceConfiguration), will help us to focus our scope.

If we don't achieve some focus, we could keep spinning in a wheel trying to add more and more details, so the question, rather than "should we add x"? in my opinion should be does adding x help us to reach our goal?.

The current NetJSON DeviceConfiguration spec and its relative JSON-schema does not specify any default gateway attribute for the interfaces.

We should probably add it, don't you agree?

Actually the spec lists only "wds", without specifying if it should be a wds access point or a wds station.

It would probably be more self-evident and less ambiguous.

Referring to the DeviceConfiguration object.

The RFC is not clear on whether NetworkGraph should contain the full network or just what is known to a node.

@fhuberts was deceived by this ambiguity with the first version of the olsrd1 netjson plugin.

I think it would be acceptable to mandate that every implementation returns all the information it has about the network graph. This should be ok for distance vector too.

Another proposal related to this one is #25 (how to distinguish between full graph and partial/local graph?).

CC: @HRogge @gabri94

Currently we have one attribute called enabled, while we have a few other ones called disabled.

It would probably be better to be consistent and chose one of the two.

I would prefer that if a block if present is enabled by default but can be disabled by adding { "disabled": true } if needed. It's easy to read and handy because it allows to temporarily disable a config block without removing it.

Quoting from here:
https://www.reddit.com/r/darknetplan/comments/3l6226/netjson_rfc_draft_0/

If you're considering wider applicability, some things that come to mind:

• "Strictly defining the types of interfaces"

It was mentioned in several discussions on the mailing list that we need an object to represent neighbour link data.

This was also referred to as "link-specific" or "interface-specific".

the 1st proposed solution is to add a new top-level member in NetworkGraph would be sufficient, we have to find a good name for this member and add it to the spec.

the other (2nd) possible solution is changing the value of the type attribute but keeping the exact same structure of NetworkGraph. This could be an acceptable solution IMHO: we keep the compatibility with NetworkGraph, we avoid adding too many attributes but at the same time we also make a clear distinction between the use case of the two objects.

In my opinion, the first thing we should try to do is to have a discussion about the terminology used by different routing protocols to refer to this type of data.

The second thing we have to do is to clearly state the goal / use case for this object, what do we need to do with it? Why did we add it?

I think we need to add a standard timezone attribute, the allowed values should probably be the ones in the tz database compiled by IANA, eg:

• UTC
• Europe/Amsterdam
• Europe/Berlin

Some OpenWRT developers suggested to add a distinction between physical interface names and logical names. This because physical names can be automatically generated and vary a lot from manufacturer to manufacturer.

I think the current name attribute of interface objects could refer to logical names while an optional device attribute may refer to the physical name of the interface.

It makes sense to define "country" in the general section, since it doesn't make much sense to define different radios with different country settings.

Therefore I think a similar configuration:

{
    "type": "DeviceConfiguration",
    "general": {
        "country": "EN"
    },
    "radios": [
        {
            "name": "radio0",
            "phy": "phy0",
            "protocol": "802.11n",
            "channel": 140,
            "channel_width": 20
        },
        {
            "name": "radio1",
            "phy": "phy1",
            "protocol": "802.11n",
            "channel": 132,
            "channel_width": 40
        }
    ]
}

it's better than:

{
    "type": "DeviceConfiguration",
    "radios": [
        {
            "name": "radio0",
            "phy": "phy0",
            "protocol": "802.11n",
            "channel": 140,
            "channel_width": 20,
            "country": "EN"
        },
        {
            "name": "radio1",
            "phy": "phy1",
            "protocol": "802.11n",
            "channel": 132,
            "channel_width": 40,
            "country": "EN"
        }
    ]
}

Because the latter repeats the "country" option for each radio.

PS: this is somewhat similar to #41, in which an interface related setting is included in the "general" section because it affects several parts of the configuration and not a specific one.

What do you think about having a fourth type of possible object, which merges DeviceConfiguration and DeviceMonitoring?

Since the two structures are compatible, in some cases someone might need to retrieve all in one go.

See: https://lists.funkfeuer.at/pipermail/interop-dev/2015-May/000406.html

The second major change is an array of "endpoints" in the graph object.

Links are connections between Nodes, but Endpoints are connections of
a (Router) Node with an external prefix. Similar data than Links, I
just renamed "target" into "prefix" to make sure you don't mix up
Links and Endpoints. Maybe they should have the same key.

In the current spec we refer to JSON RFC 4627, but there's a more recent one: https://tools.ietf.org/html/rfc7159

I'll update the README and RFC.

See https://lists.funkfeuer.at/pipermail/interop-dev/2015-May/000407.html

do we maybe want to add the fixed field "hops" to the routes? The
number of intermediate stations might be interesting to judge a route
in addition to the total cost.

e.g. wired / wireless / tunnel or even more special:
'10baseT-HD' or
'802.11a/n' or
'bluetooth' or
'zigbee' or
'tuntap'

Current schema does not allow multiple SSID. We should allow it.

The Extension Registry is just a stub.

Two things must be done asap:

• add existing extensions
• define how to register extensions

A lot of routing protocols can have multiple IDs (aliases) for the same node.
In OLSR this is called MID, in batman-adv primary and secondary id.
We should find a standard way to rapresent it in the various json.

I propose to add this optional attribute inside of the elements of the list "nodes":

"aliases": [
    "172.16.40.25",
    "172.16.40.26"
]

so "nodes" would become something like:

"nodes": [
    {
        "id": "172.16.40.24",
        "aliases": [
            "172.16.40.25",
            "172.16.40.26"
        ],
        "label": "node-A",
        "properties": {
            "hostname": "node1.my.net"
        }
    }
]

See ML thread: https://lists.funkfeuer.at/pipermail/interop-dev/2015-June/000421.html

The wireless section should be an object, not an array.

Multiple SSIDs should be defined by defining more wireless interfaces.

See also openwisp/netjsonconfig#27

Open802.11s introduces the mesh_id concept.

This adds a bit of complexity to the validation of wireless interfaces because SSID should not be required if 802.11s is selected, while mesh_id should be required.

I don't understand why you open two times an array of links.

 "links": [
    [
        {
            "source": "172.16.40.24",
            "target": "172.16.40.60",
            "weight": 1.000,
            "properties": {
                "lq": 1.000,
                "nlq": 0.497
            }
        }
    ]
]

Next, device and cost are missing.

There's also an interface (brwifi) with a mask which is a string instead of an integer.