[Interop-dev] JSON formats update

[Nemesis]

Hi Nico,

thanks for joining!

On 11/26/2014 04:51 AM, Nicolás Echániz wrote:
> With the baby and the house building I haven't been able to follow all
> the discussion but I'll pop in now that there's an update, with a couple
> of observations; please forgive me if these have already been discussed.
>
> Maybe it would make things more clear if we were to split the
> information that is now present in the DeviceConfiguration example into
> three different components:
>
> 0) Social/Community information (community, owner, admin, etc.)
> 1) Static device information
> 2) Configuration data
>
> Static and Config might be difficult to diferentiate, but I would
> deffinitely move Social/Community data away from DeviceConfiguration.

I think we are on the same line of tought.

Could you be more precise to which attributes you refer to when
mentioning social / community data?

I see two attributes that might interpreted as "social" or "community"
data: mantainer and description.

mantainer it is a possible value that ca be saved in the device
configuration and can be taken via SNMP.

The description field was suggested by Ralf because it is often used in
NodeDBs, then after investigation I noticed that is also returned by
SNMP, this is (part of) the default output of a vanilla openwrt flashed
device with minisnmpd:

iso.3.6.1.2.1.1.4.0 = STRING: "(spam-protected)"
iso.3.6.1.2.1.1.5.0 = STRING: "HeartOfGold"
iso.3.6.1.2.1.1.6.0 = STRING: "office"

In this case, (spam-protected) can be "mantainer", "HearthOfGold" should
be the "hostname" attribute and "office" can correspond to "description".

Since we previously wrote that all attributes should be optional, if an
implementation doesn't want to return this info it can omit it.

Regarding the static / configuration attribute division, we could find a
definition that can include both meanings or we can justify keeping them
in a single object with the fact that attributes like RAM can be
configuration options in virtual settings like VMs. You might ask, why
consider a VM a network device? You might use a VM to host a pfsense
instance for example.

I should add this info in the spec asap to avoid repeating it.

Any other doubts, other attributes or missing stuff?

Federico