[Interop-dev] Continuing Round 3: added dhcp and encryption examples
Nemesis
(spam-protected)
Fri Nov 21 19:39:31 CET 2014
Hi Jernej,
On 11/21/2014 08:56 AM, Jernej Kos wrote:
> Hello!
>
> On 20. 11. 2014 17:59, Nemesis wrote:
>> Could you paste a couple JSON examples please?
> Ok, so I thought about this again, and I now think that for reporting
> the current state, you will probably only report the currently active
> addresses on an interface.
>
> So something like this under the interface section:
>
> "addresses": [
> {
> "family": "ipv4",
> "address": "192.168.0.17",
> "mask": 24
> },
> {
> "family": "ipv6",
> "address": "2001:db8::dead:beef:1",
> "mask": 64
> }
> ]
Thanks for this example.
I have to anticpate something, in the next round I would have liked to
compare the current result with what is actually in ubus and try to make
our JSON more similar to that one, when possible, to speed up adoption.
If we look at some output from ubus (an example is also available here:
http://wiki.openwrt.org/doc/techref/ubus) we will notice that your
proposal is very similar to what openwrt is already doing, so I think
that's good.
Just "family" doesn't convince me. Think about it: if all attributes are
really optional, even if we add "family" in the specification probably
many implementers will choose to omit it because it doesn really tell
you anything that you can't already know just by looking at it.
> So these would be the addresses that are currently active on an
> interface. I believe this is enough and I am not sure whether we should
> also report things like "this address has been obtained via DHCP"
> because the question then is how to reliably get this (on OpenWrt it can
> probably be obtained by checking with netifd via ubus)?
>
Not sure either, we are still at version 0 after all.
Any other views on this?
-------------- 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/20141121/8534ccc3/attachment.sig>
More information about the Interop-dev
mailing list