Subject: Re: [6lowapp] Reference implementation

From: JP Vasseur <[email-masked]>
Date: Wed, 6 Jan 2010 12:39:27 +0100

Hi,

On Dec 30, 2009, at 6:11 PM, Jon Smirl wrote:

> What are the plans for a 6lowapp reference implementation?
>
> For example there is a 6lowpan implementation in Contiki, but nobody
> is updating it to track the current proposals.
> Does a ROLL reference implementation exist?

The IETF does not produce "reference implementation" but protocol
specifications and applicability statement. For ROLL we have plans to
work on such documents that will provide guidance on how to use
RPL in different environments. Is this what you had in mind ?

Thanks.

JP.

>
> -- 
> Jon Smirl
> [email-masked]
> _______________________________________________
> 6lowapp mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/6lowapp

---

From: Jon Smirl <[email-masked]>
Date: Wed, 6 Jan 2010 10:44:01 -0500

> RPL in different environments. Is this what you had in mind ?

Standards often have problem with specifying behavior in mainstream
cases and leaving the corner cases ambiguous. Nobody knows about these
corner case problems until some kind of interop event occurs.  Another
method for achieving conforming standards implementations is to
produce an open source implementation of the spec that everyone can
use and contribute to.  Then all of the people with private
implementations can test against the public one. Since the reference
code base was produced as a joint effort from all people involved it
becomes the arbiter for behavior in the corner cases.

-- 
Jon Smirl
[email-masked]

---

From: Jorge Amodio <[email-masked]>
Date: Wed, 6 Jan 2010 10:19:12 -0600

> RPL in different environments. Is this what you had in mind ?

Yes you are right the IETF does not produce "reference implementation"
but the original question I believe was not directed to the IETF but
to the individuals interested in 6LoWPAN (I'm one among them) and as
you probably know there is an old standing and still current mantra
clearly expressed for years in the Tao of IETF (RFC4677):

""We reject kings, presidents and voting.  We believe in rough
consensus and running code"

So no harm, and nothing wrong for somebody to ask for "running code" ...

On the other hand, while the formal specification of a protocol can be
expressed in a RFC, there is nothing better than pseudo-code or
running code to clearly show how the protocol should be or must be
implemented.

My .02
Regards
Jorge

---

From: JP Vasseur <[email-masked]>
Date: Wed, 6 Jan 2010 19:14:18 +0100

> So no harm, and nothing wrong for somebody to ask for "running  

Oh we're strongly agreeing here, I was trying to understand what you  
were requesting,
that's all.

> running code to clearly show how the protocol should be or must be

But still ... could you tell us what you would like to get ?

Thanks.

JP.

---

From: Philip Levis <[email-masked]>
Date: Wed, 6 Jan 2010 12:49:01 -0800

> becomes the arbiter for behavior in the corner cases.

Well, that sounds like an excellent reason for you to go implement it! :)

There's an open-source implementation in TinyOS. It's currently behind the drafts, but that's going to change in the next month or so.

Phil

---

From: Jon Smirl <[email-masked]>
Date: Wed, 6 Jan 2010 19:54:42 -0500

> Well, that sounds like an excellent reason for you to go implement it! :)

I've already released open source support for IPv6 with 6lowpan on the
mc13224. I have used it  to implement a web server. It is based on the
Atmel Raven support already in Contiki.

I'm also working on serial support for the mc13224 to get it working
with the internal Linux 802.15.4 implementation by Seimens.

> There's an open-source implementation in TinyOS. It's currently behind the drafts, but that's going to change in the next month or so.

I'll check it out. Maybe I can move my mc13224 radio driver into
TinyOS or pull the ROLL code into Contiki.

Working together on BSD licensed code means everyone can pull it back
into their proprietary products if they choose. The BSD code could
also be pulled into the Linux kernel, but not the other way.

-- 
Jon Smirl
[email-masked]