Subject: [babel] NetJSON outreach

From: Nemesis <[email-masked]>
Date: Thu, 14 Apr 2016 11:50:15 +0200

Hi everyone,

I joined this list in order to follow the discussion on internal data
structures containing management information and NetJSON.
I have been developing applications that deal with networks since 2012,
but working in this field for me has always been a struggle because of
the lack of a standard format, which usually has meant developing
applications that only worked with firmware X and protocol Y, which is
greatly bad for a number of reasons, which I briefly explain in the
"Motivations" section of the NetJSON README:
https://github.com/interop-dev/netjson#motivations

Me and other developers are currently busy writing, improving and
testing in the wild implementations of all the NetJSON objects that are
defined in the spec, but we need more implementations, more feedback and
faster iteration to improve the current data structures and the RFC.

There's wide room for improvement, but many of us believe the time is ripe.

Best regards
Federico Capoano

---

From: Juliusz Chroboczek <[email-masked]>
Date: Thu, 14 Apr 2016 09:39:29 -0300

> structures containing management information and NetJSON.

Federico (Nemesis) is the main mover behind the NetJSON effort.  I've met
him in person, and he's certainly somebody one can work with.

-- Juliusz

---

From: "STARK, BARBARA H" <[email-masked]>
Date: Thu, 14 Apr 2016 16:20:05 +0000

> I joined this list in order to follow the discussion on internal data structures
> containing management information and NetJSON.
> I have been developing applications that deal with networks since 2012, but
> working in this field for me has always been a struggle because of the lack of
> a standard format, which usually has meant developing applications that only
> worked with firmware X and protocol Y, which is greatly bad for a number of
> reasons, which I briefly explain in the "Motivations" section of the NetJSON
> README:
> Me and other developers are currently busy writing, improving and testing in
> the wild implementations of all the NetJSON objects that are defined in the
> spec, but we need more implementations, more feedback and faster
> iteration to improve the current data structures and the RFC.
> 

I looked over the stuff at the netjson website and think it's great. I've been thinking we need something like this for several years now and kept meaning to try to get something started (but always got side-tracked). I'm thrilled to see that someone has done all this work and really like the quality and readability of the spec, and high-level design choices that have been made. I'll be looking the spec over in more detail to see if I can provide meaningful feedback.

Some additional items I'd like to explore are:
 - Define/register a service name (http://www.iana.org/assignments/service-names-port-numbers/service-names-port-numbers.xml) that can be used by devices wanting to advertise/discover (DNS-SD) URLs where such info is exposed via an HTTP API. 
 - Better define processes that would allow other orgs to extend. I see the custom members registry, but think a little more definition is needed. I'm wondering if it might be possible to define some syntax to make it easy for orgs with formal registered namespace (http://www.iana.org/assignments/urn-namespaces/urn-namespaces.xhtml) to extend. Or define more formal processes.

---

From: nemesis <[email-masked]>
Date: Thu, 14 Apr 2016 23:17:47 +0200

On Thu, 14 Apr 2016 16:20:05 +0000, "STARK, BARBARA H" <[email-masked]> 
 wrote:
>> testing in
> I looked over the stuff at the netjson website and think it's great.
> I've been thinking we need something like this for several years now
> and kept meaning to try to get something started (but always got
> side-tracked). I'm thrilled to see that someone has done all this 
> work
> and really like the quality and readability of the spec, and
> high-level design choices that have been made. I'll be looking the
> spec over in more detail to see if I can provide meaningful feedback.

 Great to hear this!
 
>  - Define/register a service name
> 
> (http://www.iana.org/assignments/service-names-port-numbers/service-names-port-numbers.xml)
> that can be used by devices wanting to advertise/discover (DNS-SD)
> URLs where such info is exposed via an HTTP API.

 I'm not sure I understood what you mean, because NetJSON is a format 
 and is only concerned about the text format and nothing else (Just like 
 GeoJSON: http://geojson.org), so it doesn't use ports. Could you 
 clarify?

>  - Better define processes that would allow other orgs to extend. I
> see the custom members registry, but think a little more definition 
> is
> needed. I'm wondering if it might be possible to define some syntax 
> to
> make it easy for orgs with formal registered namespace
> (http://www.iana.org/assignments/urn-namespaces/urn-namespaces.xhtml)
> to extend. Or define more formal processes.

 You're right, the current registry is really just a stub.
 A more structured (and well documented) process is needed asap.
 Hopefully with more feedback and suggestions I'll be able to prepare 
 something good enough to start.

 I will also have to update the current spec with the latest advancement 
 found in the implementations and fill in the registry with the currently 
 used extensions.

 The current tools we have are already allowing us to bootstrap useful 
 applications quickly, eg:
 http://ninux-graph.netjson.org/topology/e384464c-d1d2-4af3-aae1-4e852a28d956/ 
 (this app is focused on the NetworkGraph object)

 code is here: https://github.com/interop-dev/django-netjsongraph

 Federico

---

From: Dave Taht <[email-masked]>
Date: Thu, 14 Apr 2016 14:43:38 -0700

> code is here: https://github.com/interop-dev/django-netjsongraph

That is a truly stunning demo. *I need this*.  My testbeds have got so
complex that I can no longer find anything nor figure out where it is
or what it is connected to.

> Federico
>
>
> _______________________________________________
> babel mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/babel

-- 
Dave Täht
Let's go make home routers and wifi faster! With better software!
http://blog.cerowrt.org

---

From: "STARK, BARBARA H" <[email-masked]>
Date: Thu, 14 Apr 2016 22:30:04 +0000

> > (http://www.iana.org/assignments/service-names-port-numbers/service-
> na
> > mes-port-numbers.xml) that can be used by devices wanting to
> > advertise/discover (DNS-SD) URLs where such info is exposed via an
> > HTTP API.
> 
>  I'm not sure I understood what you mean, because NetJSON is a format  and
> is only concerned about the text format and nothing else (Just like
>  GeoJSON: http://geojson.org), so it doesn't use ports. Could you  clarify?

That IANA registry is a multi-purpose list. In addition to being home to all the traditional service/port number assignments, it also has the DNS-SD service name assignments. For example, look at the entry for xul-http. Scroll to the far right of that entry and read the description. 

The idea is that a device inside the LAN could send a multicast DNS (mDNS) query (e.g., mDNS query for _netjson._tcp.local.) to discover devices with NetJSON-formatted info exposed by a HTTP API. A router inside the LAN that is exposing NetJSON info by a HTTP API would respond to such a mDNS query with the DNS SRV + TXT records that supply the URL of the info. This has nothing directly to do with NetJSON or the formatting. It's about automating advertisement and discovery, just like printers get discovered today. 

I think this would be as simple as getting "netjson" included in this IANA registry per RFC 6335. See Section 5.2 of that RFC for special DNS-SD instructions.
Barbara

---

From: Henning Rogge <[email-masked]>
Date: Fri, 15 Apr 2016 07:51:59 +0200

> or what it is connected to.

There is also a very simple example in the OONF (olsrd2) repository:
http://olsr.org/git/?p=oonf.git;a=tree;f=files/netjson_viewer;h=6afd72509dac4ea0d9fe357b65e8ccaf1dd89e9e;hb=HEAD

You can hack together a viewer for NetJSON in a few hours... which
proves the format is really nice to work with.

Henning

---

From: Nemesis <[email-masked]>
Date: Fri, 15 Apr 2016 11:16:54 +0200

> or what it is connected to.

Glad to know you find it stunning. I find it quite limited but surely
the best I could do in my free time.
Think about it: this is just one of the first and simplest
implementations, imagine what we can do with more experienced people and
better/more advanced implementations.

Federico

---

From: Nemesis <[email-masked]>
Date: Fri, 15 Apr 2016 12:03:26 +0200

> That IANA registry is a multi-purpose list. In addition to being home to all the traditional service/port number assignments, it also has the DNS-SD service name assignments. For example, look at t…

Are you referring to:

"Defined TXT keys: u=<username> p=<password> path=<path to document>
(Same as for _http._tcp)"

> The idea is that a device inside the LAN could send a multicast DNS (mDNS) query (e.g., mDNS query for _netjson._tcp.local.) to discover devices with NetJSON-formatted info exposed by a HTTP API. A…

In relation to "u=<username> p=<password> path=<path to document>",
does it mean sending a TCP packet to that specific port with those
parameters will return the requested information?

> I think this would be as simple as getting "netjson" included in this IANA registry per RFC 6335. See Section 5.2 of that RFC for special DNS-SD instructions.

This would open up many interesting possibilities!

Probably a generic mechanism to specify the protocol used would be
necessary: it's common to send NetJSON via HTTP, telnet and websocket.

I converted RFC 6335 to epub (I wish tools.ietf.org was able to do this
automatically!) and loaded into my e-reader, I need to read the entire
RFC in order to familiarize more with this concept.

Thank you Barbara!
Federico

---

From: Gabriel Kerneis <[email-masked]>
Date: Fri, 15 Apr 2016 12:36:58 +0200

On Fri, Apr 15, 2016 at 12:03 PM, Nemesis <[email-masked]> wrote:

> automatically!)

>From https://tools.ietf.org/:

Downloading RFCs & I-Ds eBooks
> There is weekly generated ebooks in .epub and .mobi (kindle) format for
> RFCs and Internet-Drafts. The rfc.mobi and rfc.epub files contains all
> RFCs in one big file. For I-Ds there is files for each separate working
> group (i-d.*) and one file per area containing all WGs in the area
> (area.*). In addition to the active WG drafts those files also contain the
> published RFCs and related I-Ds.

You can find them here: https://tools.ietf.org/ebook/

Best,
Gabriel

---

From: Juliusz Chroboczek <[email-masked]>
Date: Fri, 15 Apr 2016 10:49:38 -0300

> Glad to know you find [the demo] stunning. I find it quite limited but
> surely the best I could do in my free time.

This is getting off-topic for this list, perhaps Russ or Donald can tell
us whether it is okay to continue this discussion here.

Federico, I think that the deadline for Google Summer of Code is not over
yet, do you think you could mentor a student on a NetJSON projet?  I'd be
willing to co-mentor with you (but you get full credit), and I might be
able to find you a suitable student.

-- Juliusz

---

From: "Russ White" <[email-masked]>
Date: Fri, 15 Apr 2016 09:55:04 -0400

> This is getting off-topic for this list, perhaps Russ or Donald can tell
us
> whether it is okay to continue this discussion here.

Seems fine to me...

Can you send me a pointer to the demo again? It seems to be lost in the
mists of time.

:-)

Russ

---

From: Juliusz Chroboczek <[email-masked]>
Date: Fri, 15 Apr 2016 11:32:49 -0300

> Seems fine to me...

Cool, glad to hear that.

-- Juliusz

---

From: Nemesis <[email-masked]>
Date: Fri, 15 Apr 2016 18:10:51 +0200

On 04/15/2016 12:36 PM, Gabriel Kerneis wrote:
> On Fri, Apr 15, 2016 at 12:03 PM, Nemesis <[email-masked]
> <mailto:[email-masked]>> wrote:
> 
>     I converted RFC 6335 to epub (I wish tools.ietf.org
>     <http://tools.ietf.org> was able to do this
>     automatically!)
> 
> 
>     There is weekly generated ebooks in .epub and .mobi (kindle) format
>     for RFCs and Internet-Drafts. The rfc.mobi <http://rfc.mobi> and
>     rfc.epub files contains all RFCs in one big file. For I-Ds there is
>     files for each separate working group (i-d.*) and one file per area
>     containing all WGs in the area (area.*). In addition to the active
>     WG drafts those files also contain the published RFCs and related I-Ds. 
> 
> 

Thanks, I didn't know that, I hope it will be possible to download
specific (single) RFC also in the near future.

Federico

---

From: Nemesis <[email-masked]>
Date: Fri, 15 Apr 2016 18:35:47 +0200

>> surely the best I could do in my free time.
[...]
> able to find you a suitable student.

Unfortunately the GSoC proposal submission deadline has passed, but I'm
very happy to hear you'd be available for co-mentoring such an effort.

I have these ideas in my mind:

- prepare for the next GSoC, 1 year goes incredibly fast!

- try to see if there are opportunities for funding in EU projects like
NetCommons [1] or any other similar project

- look for other funding opportunities, eg: prpl foundation, university
grants

[1]: http://netcommons.eu/

Federico