Subject: [Roll] New proposed charter

From: Ines Robles <[email-masked]>
Date: Fri, 11 Dec 2015 17:01:15 +0200

Dear all:

We propose the following text to replace the current (much longer) charter [
https://datatracker.ietf.org/wg/roll/charter/], please let us know your
opinion about this.

If you think that other specific topic should be included, please let us
know as well.

Charter proposed might be:

RFC 6550 was published in 2012, and has seen several successful deployments.

Over time, additional issues have come up, including issues in the data
plane of when to use IPinIP headers, and how to compress them, as well as
the standardization of a mixed storing/non-storing mechanism.

The WG is chartered to look at enhancements and maintenance to the RPL
protocol, with the aim of eventually revising and advancing RFC 6550 to
Internet Standard.

Thank you very much,

Michael and Ines.

---

From: Csaba Kiraly <[email-masked]>
Date: Fri, 11 Dec 2015 17:25:02 +0100

Hi Ines,

With Joakim we are working on DAO-ACK semantics and syntax changes, 
aiming both to clarify DAO-ACK related parts of RFC 6550, as well as to 
make storing mode operation more reliable and scalable.
The draft is still in its infancy, but the topic might worth adding to 
the charter.

Regards,
Csaba

On 11/12/15 16:01, Ines Robles wrote:
>
> Dear all:
>
>
> We propose the following text to replace the current (much longer) 
> charter [https://datatracker.ietf.org/wg/roll/charter/], please let us 
> know your opinion about this.
>
>
> If you think that other specific topic should be included, please let 
> us know as well.
>
>
> Over time, additional issues have come up, including issues in the 
> data plane of when to use IPinIP headers, and how to compress them, as 
> well as the standardization of a mixed storing/non-storing mechanism.
>
> protocol, with the aim of eventually revising and advancing RFC 6550 
> to Internet Standard.
>
>
> Thank you very much,
>
>
> Michael and Ines.
>
>
> _______________________________________________
> Roll mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/roll

---

From: Randy Turner <[email-masked]>
Date: Fri, 11 Dec 2015 11:31:21 -0500 (EST)

Hi Ines,

We might want to consider rolling items from 6553, 6551, etc. back into an overall “RPL Protocol” RFC – not everything, but items that we have found in implementation to be a requirement for a workable RPL implementation.

It would make it easier for implementers to have fewer docs to read and understand – I could come up with a few examples in a future email. Some of what I'm talking about would be the IP-in-IP stuff, as well as extension headers.

Also, I would like to consider other options for routing besides strictly storing and non-storing, or mixed storing/non-storing

Also, re-visiting the recent DAO/DAO-ACK discussions and possibly clarifying behavior (as alluded to by Csaba in an earlier email)

Randy

On December 11, 2015 at 10:01 AM Ines Robles <[email-masked]> wrote:

Dear all:

We propose the following text to replace the current (much longer) charter [https://datatracker.ietf.org/wg/roll/charter/], please let us know your opinion about this.

If you think that other specific topic should be included, please let us know as well.

Over time, additional issues have come up, including issues in the data plane of when to use IPinIP headers, and how to compress them, as well as the standardization of a mixed storing/non-storing mechanism.

The WG is chartered to look at enhancements and maintenance to the RPL protocol, with the aim of eventually revising and advancing RFC 6550 to Internet Standard.

Thank you very much,

Michael and Ines.

---

From: "Pascal Thubert (pthubert)" <[email-masked]>
Date: Fri, 11 Dec 2015 17:47:31 +0000

Hello Ines

I like the proposal because it is open enough to include the various items we discussed recently. Great work!

I’m in  full support for this proposal as you may have guessed,

Pascal

From: Roll [mailto:[email-masked]] On Behalf Of Ines Robles
Sent: vendredi 11 décembre 2015 16:01
To: roll <[email-masked]>
Cc: Michael Richardson <[email-masked]>
Subject: [Roll] New proposed charter

Dear all:

Thank you very much,

Michael and Ines.

---

From: Abdussalam Baryun <[email-masked]>
Date: Fri, 11 Dec 2015 20:12:39 +0200

Dear All,

I think  we should not look only into enhancement of RPL but looking into
one new proposed protocol (experimental). My question is why we only have
one standard protocol for ROLL? we may need to look into different/new
scenarios now, so YES we chosen the one routing RPL as a general purpose
protocol for ROLL, now we need to do maintain RPL with its future work, but
we also can now see special cases where we need new protocols for ROLL. We
noticed that ROLL is more a special case of other routing protocols in the
internet but still we didn't go for experimental drafts that cover special
cases and implementations.

AB
University of Tripoli,

On Fri, Dec 11, 2015 at 7:47 PM, Pascal Thubert (pthubert) <
[email-masked]> wrote:

> *From:* Roll [mailto:[email-masked]] *On Behalf Of *Ines Robles
> *Sent:* vendredi 11 décembre 2015 16:01
> *To:* roll <[email-masked]>
> *Cc:* Michael Richardson <[email-masked]>
> *Subject:* [Roll] New proposed charter
>
>
>
>
>
> Dear all:
>
>
>
> We propose the following text to replace the current (much longer) charter
> [https://datatracker.ietf.org/wg/roll/charter/], please let us know your
> opinion about this.
>
>
>

---

From: Michael Richardson <[email-masked]>
Date: Fri, 11 Dec 2015 16:20:12 -0500

Csaba Kiraly <[email-masked]> wrote:
    > make storing mode operation more reliable and scalable.  The draft is
    > still in its infancy, but the topic might worth adding to the charter.

The intention of the words:

    >     The WG is chartered to look at ***enhancements*** and maintenance to the
    > RPL protocol, with the aim of eventually revising and advancing RFC
    > 6550 to Internet Standard.

Is to be inclusive of items such as you describe, without having to enumerate
them.  If we adopt a document, then it would get a milestone, etc, but we
don't have to go back to the IESG for that.

--
Michael Richardson <[email-masked]>, Sandelman Software Works
IETF ROLL WG co-chair.    http://datatracker.ietf.org/wg/roll/charter/

---

From: Michael Richardson <[email-masked]>
Date: Fri, 11 Dec 2015 16:23:51 -0500

Randy Turner <[email-masked]> wrote:
    > We might want to consider rolling items from 6553, 6551, etc. back into
    > an overall “RPL Protocol” RFC – not everything, but items that we have
    > found in implementation to be a requirement for a workable RPL
    > implementation.

That's entirely doable if we have the editorial cycles, and it's included in:

    ines>     Over time, additional issues have come up, including issues in the
    ines> data plane of when to use IPinIP headers, and how to compress them, as
    ines> well as the standardization of a mixed storing/non-storing mechanism.

So, we'd be *updating* 6554,6553,6551, etc. in explaining how to compress
things.

    ines> aim of eventually revising and advancing RFC
    ines> 6550 to Internet Standard.

And this item includes the possibility that we could combine multiple
documents as we go to IS.
When it says "RFC6550" it should mean the entire RPL document set.
So perhaps that part should be more explicit?

    > Also, I would like to consider other options for routing besides
    > strictly storing and non-storing, or mixed storing/non-storing

Explicitely already mentioned: we didn't pick a solution in the charter
above:      **standardization of a mixed storing/non-storing mechanism**

    > Randy

So, are you in favour of this change, or can you suggest specific text?

---

From: Michael Richardson <[email-masked]>
Date: Fri, 11 Dec 2015 16:26:46 -0500

Abdussalam Baryun <[email-masked]> wrote:
    > I think we should not look only into enhancement of RPL but looking
    > into one new proposed protocol (experimental). My question is why we
    > only have one standard protocol for ROLL?

Because that was in our original charter.

    > different/new scenarios now, so YES we chosen the one routing RPL as a
    > general purpose protocol for ROLL, now we need to do maintain RPL with
    > its future work, but we also can now see special cases where we need
    > new protocols for ROLL. We noticed that ROLL is more a special case of
    > other routing protocols in the internet but still we didn't go for
    > experimental drafts that cover special cases and implementations.

If you have new use cases that you believe can not be satisfied by RPL, then
you should detail them in an ID.

This is exactly how RPL-P2P came about.

If extensions (whether experimental or not), can address the need then they
would be in scope for this WG.  If an entirely new routing protocol is
needed, then that would be out of scope and would be up to the routing Area
Directors to decide where that work would be done.

---

From: Randy Turner <[email-masked]>
Date: Fri, 11 Dec 2015 18:05:33 -0500

Hi Michael,

RFC 6550 mentions the possibility of hybrid storing/non-storing approaches, but only mentions the possibility and declares it out of scope.  I do think it would be nice to re-visit this topic and see if there’s something there of value.

The additional type of routing I was referring to was similar to this “hybrid”, but specific to multicast. Something like “Non-storing with multicast-storing”

This would be basically a non-storing mode of operation, except a node would  just store multicast memberships that have been declared - if someone joins a multicast group, you store this…since memberships can be aggregated, it shouldn’t mean too much of a burden on the amount of memory required to store multicast routes.

Randy

> On Dec 11, 2015, at 4:23 PM, Michael Richardson <[email-masked]> wrote:
> 
>

---

From: Abdussalam Baryun <[email-masked]>
Date: Sun, 13 Dec 2015 00:22:02 +0200

My previous message was my reply to the request of the chair that welcome
opinions and new recharter, so I did not understand that there are things
out of scope.

> you should detail them in an ID.

There were discussions about use cases before, but I just need to discuss
first, then see if we can do ID. No protocol can satisfy all use cases.

So we can discuss first, and then decide if their is availability,

> This is exactly how RPL-P2P came about.

Yes there was discussions, some may prefer to do it off-line, and then
write IDs,

> would be in scope for this WG.

Ok, but that is why I am replying to the proposing call, so I am discussing
that issue and others,

>   If an entirely new routing protocol is

I don't think it is out of scope.

Participants are the ones to decide/discuss where new protocols go (don't
forget directors can participate without hats), and directors only have the
final decision after our discussions. Therefore, I hope we discuss
recharter without initial directions/force.

 So I think that new proposal for the recharter should make the option open
for new one experimental ROLL-protocol, to encourage new ideas.

AB

---

From: Carsten Bormann <[email-masked]>
Date: Sat, 12 Dec 2015 23:33:45 +0100

> The additional type of routing I was referring to was similar to this “hybrid”, but specific to multicast. Something like “Non-storing with multicast-storing”

While you are talking about multicast:

Any interest in working on constrained-cast (multicast that works with
non-storing)?

https://tools.ietf.org/html/draft-bergmann-bier-ccast-00

Grüße, Carsten

---

From: Don Sturek <[email-masked]>
Date: Sat, 12 Dec 2015 15:15:31 -0800

Hi Carsten,

Definite interest here.   I know there was some discussion about using
Bier for multicast but we need something that scales to networks on the
order of 5-10 thousand devices.

Don Sturek

On 12/12/15 2:33 PM, "Roll on behalf of Carsten Bormann"
<[email-masked] on behalf of [email-masked]> wrote:

>Randy Turner wrote:
>> The additional type of routing I was referring to was similar to this
>>³hybrid², but specific to multicast. Something like ³Non-storing with
>>multicast-storing²
>

---

From: "Turner, Randy" <[email-masked]>
Date: Sat, 12 Dec 2015 23:38:19 +0000

Yes, I think it would be worth looking into these non-storing multicast hybrids - the hybrid I spoke of earlier, as well as the Bier ideas that have been topics at the last 2 (or more) plenaries

R.

> On Dec 12, 2015, at 6:15 PM, Don Sturek <[email-masked]> wrote:
>
> Hi Carsten,
>

P PLEASE CONSIDER OUR ENVIRONMENT BEFORE PRINTING THIS EMAIL.

This e-mail (including any attachments) is confidential and may be legally privileged. If you are not an intended recipient or an authorized representative of an intended recipient, you are prohibited from using, copying or distributing the information in this e-mail or its attachments. If you have received this e-mail in error, please notify the sender immediately by return e-mail and delete all copies of this message and any attachments. Thank you.

---

From: Michael Richardson <[email-masked]>
Date: Sun, 13 Dec 2015 13:25:44 -0500

Randy Turner <[email-masked]> wrote:
    > “hybrid”, but specific to multicast. Something like “Non-storing with
    > multicast-storing”

    > This would be basically a non-storing mode of operation, except a node
    > would just store multicast memberships that have been declared - if
    > someone joins a multicast group, you store this…since memberships can
    > be aggregated, it shouldn’t mean too much of a burden on the amount of
    > memory required to store multicast routes.

Write an ID, slides, etc.. 
If the IESG approves the proposed charter, it would be in scope.
(Today, it is not)

---

From: Michael Richardson <[email-masked]>
Date: Sun, 13 Dec 2015 13:34:48 -0500

Abdussalam Baryun <[email-masked]> wrote:
    > My previous message was my reply to the request of the chair that
    > welcome opinions and new recharter, so I did not understand that there
    > are things out of scope.

New routing protocols should not be in scope in my opinion.
I'm pretty sure that the Area Directors would share that opinion.

So, your suggestion to amend the charter to work on additional routing
protocols (vs extensions to 6550) is not well received.  But, even if it were
well received, the first step would not be to assume a solution ("a new
routing protocol"), but rather to establish clearly what the problem is.

    > There were discussions about use cases before, but I just need to
    > discuss first, then see if we can do ID. No protocol can satisfy all
    > use cases.

You can discuss anything mesh-over, LLN-related you like on the list.
If it clearly has a better home, we may ask you to change venues, but that's
all.  

    > Participants are the ones to decide/discuss where new protocols go
    > (don't forget directors can participate without hats), and directors
    > only have the final decision after our discussions. Therefore, I hope
    > we discuss recharter without initial directions/force.

    > So I think that new proposal for the recharter should make the option
    > open for new one experimental ROLL-protocol, to encourage new ideas.

Perhaps we are using different words.

What is a "new one experimental ROLL-protocol"?
Maybe what you are proposing is what I would call an extension to 6550.
Or maybe you are talking about something entirely different
.
Does this new protocol exist already?  It is conceptually different than RPL
or BABEL or OLSR or AODV?  
If such a thing is justified, why wouldn't it justify a new working group?

---

From: "Pascal Thubert (pthubert)" <[email-masked]>
Date: Sun, 13 Dec 2015 19:13:08 +0000

Pascal

> Le 13 déc. 2015 à 19:34, Michael Richardson <[email-masked]> a écrit :
> 
> 

+1

---

From: Randy Turner <[email-masked]>
Date: Sun, 13 Dec 2015 16:49:12 -0500

I thought the discussion was around developing a new charter. If that's the case then nothing is "in scope" yet. If we're not discussing potential work items for a new charter then what is this thread about again?  I would be happy to work up a draft if that's what is required to get things "in scope"

R.

> On Dec 13, 2015, at 1:25 PM, Michael Richardson <[email-masked]> wrote:
> 
>

---

From: Michael Richardson <[email-masked]>
Date: Sun, 13 Dec 2015 22:35:09 -0500

Randy Turner <[email-masked]> wrote:
    > I thought the discussion was around developing a new charter. If that's
    > the case then nothing is "in scope" yet. If we're not discussing
    > potential work items for a new charter then what is this thread about
    > again?  I would be happy to work up a draft if that's what is required
    > to get things "in scope"

Step 1a) adjust charter.  The PROPOSED charter text ALREADY says:

    ***the standardization of a mixed storing/non-storing mechanism***

so anything that you want to write about a "non-storing with multicast-storing"
would fit into that wording.

1b) the text also says, "look at enhancements and maintenance to the RPL
   protocol"

So, anything which ads to RPL is in scope.

2) Step 2, when the new charter is in place, PLEASE:
   "Write an ID, slides, etc.."

about "non-storing with multicast-storing", and see if there is a reason/support for
the IETF to standardize it.  It could be that only you care, in which case
you can write it up as a non-WG submission, not subject to standardization.
Or it could be that it's the coolest thing since HTTP, and everyone wants to
run it...

---

From: Randy Turner <[email-masked]>
Date: Sun, 13 Dec 2015 23:47:12 -0500

I think there are other ROLL drafts to be discussed on the document tracker - one is using DIOs to distribute compression context, and the larger discussion about usage of DIOs to obviate the need for RFC 6775 or other ND traffic.   Would this be picked up in the new charter ?  If not, what would be the disposition of these discussions ?

Randy

> On Dec 13, 2015, at 10:35 PM, Michael Richardson <[email-masked]> wrote:
> 
>

---

From: peter van der Stok <[email-masked]>
Date: Mon, 14 Dec 2015 08:56:20 +0100

Hi Ines, Michael,

The charter seems to cover my expectations for a continuation of the WG.
Would writing a YANG module for MPL and RPL fit within maintenance?

Peter

Pascal Thubert (pthubert) schreef op 2015-12-11 18:47:
> FROM: Roll [mailto:[email-masked]] ON BEHALF OF Ines Robles
> SENT: vendredi 11 décembre 2015 16:01
> TO: roll <[email-masked]>
> CC: Michael Richardson <[email-masked]>
> SUBJECT: [Roll] New proposed charter
> 
> Dear all:
> 
> charter [https://datatracker.ietf.org/wg/roll/charter/ [1]], please
> let us know your opinion about this.
> 
> Links:
> ------
> [1] https://datatracker.ietf.org/wg/roll/charter/
>

---

From: Michael Richardson <[email-masked]>
Date: Mon, 14 Dec 2015 10:07:53 -0500

Randy Turner <[email-masked]> wrote:
    > I think there are other ROLL drafts to be discussed on the document
    > tracker - one is using DIOs to distribute compression context, and the
    > larger discussion about usage of DIOs to obviate the need for RFC 6775
    > or other ND traffic.  Would this be picked up in the new charter ?

Yes:

    >> 1b) the text also says, "look at enhancements and maintenance to the
    >> RPL protocol"

---

From: "Pascal Thubert (pthubert)" <[email-masked]>
Date: Mon, 14 Dec 2015 15:47:12 +0000

+1

Cheers,

Pascal

> -----Original Message-----
> From: Roll [mailto:[email-masked]] On Behalf Of Don Sturek
> Sent: dimanche 13 décembre 2015 00:16
> To: Routing Over Low power and Lossy networks <[email-masked]>
> Subject: Re: [Roll] New proposed charter
> 
> Hi Carsten,
> 
> Bier for multicast but we need something that scales to networks on the order
> of 5-10 thousand devices.
> 
> Don Sturek
> 
>

---

From: "Pascal Thubert (pthubert)" <[email-masked]>
Date: Mon, 14 Dec 2015 15:47:12 +0000

I hope so and my reading is yes. 
And we must not forget SLLAO and MTU if we really want to avoid RAs between routers...

Cheers,

Pascal

> From: Roll [mailto:[email-masked]] On Behalf Of Randy Turner
> Sent: lundi 14 décembre 2015 05:47
> I think there are other ROLL drafts to be discussed on the document tracker -
> one is using DIOs to distribute compression context, and the larger discussion
> about usage of DIOs to obviate the need for RFC 6775 or other ND traffic.
> Would this be picked up in the new charter ?  If not, what would be the
> disposition of these discussions ?
> 
> Randy
> 
> 
> >> I thought the discussion was around developing a new charter. If
> >> that's the case then nothing is "in scope" yet. If we're not
> >> discussing potential work items for a new charter then what is this
> >> thread about again?  I would be happy to work up a draft if that's
> >> what is required to get things "in scope"
> >
> > about "non-storing with multicast-storing", and see if there is a
> > reason/support for the IETF to standardize it.  It could be that only
> > you care, in which case you can write it up as a non-WG submission, not
> subject to standardization.
> > Or it could be that it's the coolest thing since HTTP, and everyone
> > wants to run it...
> >
> > --

---

From: Robert Cragie <[email-masked]>
Date: Mon, 14 Dec 2015 16:33:05 +0000

This is probably aimed at Pascal but relevant to ROLL. A lot of the text
in draft-ietf-6lo-routing-dispatch-00 (esp. section 7) is aimed at
enhancements specific to RPL packet information, so should this work really
be done in ROLL? Or do people think this work is better off done in 6lo as
it is all about compression? There is a clear overlap so perhaps at least
the charter should acknowledge relevant work done in 6lo as well.

Robert

---

From: Michael Richardson <[email-masked]>
Date: Mon, 14 Dec 2015 18:31:28 -0500

Robert Cragie <[email-masked]> wrote:
    > This is probably aimed at Pascal but relevant to ROLL. A lot of the
    > text in draft-ietf-6lo-routing-dispatch-00 (esp. section 7) is aimed at
    > enhancements specific to RPL packet information, so should this work
    > really be done in ROLL? Or do people think this work is better off done
    > in 6lo as it is all about compression? There is a clear overlap so
    > perhaps at least the charter should acknowledge relevant work done in
    > 6lo as well.

The discussion among ADs was that the requirements would come from ROLL, but
as 6lo is responsible for the IPHC/NHC/etc. that the work needed to occur
there.
I anticipate a joint WGLC though.

---

From: peter van der Stok <[email-masked]>
Date: Tue, 15 Dec 2015 08:24:12 +0100

+1
peter

---

From: Robert Cragie <[email-masked]>
Date: Tue, 15 Dec 2015 07:45:05 +0000

OK, that's fine.

Robert

---

From: "Alvaro Retana (aretana)" <[email-masked]>
Date: Thu, 17 Dec 2015 19:17:24 +0000

Hi!

I like the direction of the proposed charter, and the discussion that it has generated - and will support it then the time comes.

However, the IESG will want to see clear progress on the currently chartered items (use of RPI..) before approving a a new one.

Thanks!

Alvaro.

On 12/11/15, 10:01 AM, "Ines Robles" <[email-masked]<mailto:[email-masked]>> wrote:

Dear all:

Thank you very much,

Michael and Ines.

---

From: Ines Robles <[email-masked]>
Date: Fri, 18 Dec 2015 07:03:13 -0300

Hi,

Agree, thank you very much Alvaro.

Apologizes for late reply, I was in a trip and I am still on a trip and I
dont have permanent access to Internet.

Cheers,

Ines.

2015-12-17 16:17 GMT-03:00 Alvaro Retana (aretana) <[email-masked]>:

> Hi!
>
> I like the direction of the proposed charter, and the discussion that it
> has generated — and will support it then the time comes.
>
> However, the IESG will want to see clear progress on the currently
> chartered items (use of RPI..) before approving a a new one.
>
> Thanks!
>
> Alvaro.
>
> On 12/11/15, 10:01 AM, "Ines Robles" <[email-masked]>
> wrote:
>
>
> Dear all:
>

---

From: Abdussalam Baryun <[email-masked]>
Date: Fri, 18 Dec 2015 16:26:30 +0200

I agree with you. I think The problem is that the chair has to ask the
working group to say what they want to be in scope. What is done so far is
that our group chair is asking for new charter but still has the old scope
of one protocol for the group. I only know that the WG has the power to
change the scope if necessary when they prove that by discussion.
So hope the chair does not make conclusions on what is out of scope because
nothing is out of scope until WG decides. We only know what is in scope
when we get the approvals of our suggested addition out-scope to be
in-scope. Therefore, we can support Turner's proposals.

On Sunday, December 13, 2015, Randy Turner <[email-masked]>
wrote:

> the case then nothing is "in scope" yet. If we're not discussing potential
> work items for a new charter then what is this thread about again?  I would
> be happy to work up a draft if that's what is required to get things "in
> scope"
>
> R.
>
> > On Dec 13, 2015, at 1:25 PM, Michael Richardson <[email-masked]
> <javascript:;>> wrote:
> >
> >
> > Randy Turner <[email-masked] <javascript:;>> wrote:
> > Michael Richardson <[email-masked] <javascript:;>>, Sandelman
> Software Works
> [email-masked] <javascript:;>

---

From: Michael Richardson <[email-masked]>
Date: Fri, 18 Dec 2015 12:05:40 -0500

Abdussalam Baryun <[email-masked]> wrote:
    > that our group chair is asking for new charter but still has the old scope of
    > one protocol for the group. I only know that the WG has the power to change
    > the scope if necessary when they prove that by discussion.

I am quite certain:
  a) that the IESG will not approve a WG charter that includes more than one
     routing protocol.
  b) that I don't want to be chair of a group that works on multiple
     protocols in the same WG.
  c) that should the IESG do such a thing, that I will have significant
     feedback for nomcom.

Meanwhile, I will repeat:
  https://mailarchive.ietf.org/arch/msg/roll/odYLTGE2dkRP-SNrRSvx2-h-pU8

++ the first step would not be to assume a solution ("a new
++ routing protocol"), but rather to establish clearly what the problem is.

So, if you have a draft that explains why another protocol is necessary,
please point us to it.  It would certainly help figure out where the problem
should be discussed; it could turn out that it's a trivial extension to the
existing specification.

---

From: Robert Cragie <[email-masked]>
Date: Fri, 18 Dec 2015 17:55:27 +0000

+1. I cannot under any circumstance envisage the need for ROLL to work on a
new routing protocol. Extensions to RPL, for sure. But not a new routing
protocol.

Robert