Subject: [Roll] Opinion please

From: JP Vasseur <[email-masked]>
Date: Thu, 5 Nov 2009 08:24:52 +0100

Dear all,

/co-chair hat off/

We would welcome your opinion on the following issue:

Suppose that a DAG is formed that support OFx. A new node willing to  
join the DAG does not support OFx but OFy. Note that by OF we actually  
mean the Objective function and the metric.

We have two options here.

Option 1: The node simply joins the DAG as a leaf. In order words, the  
node has connectivity since it joins the DAG but will not act as a  
router for others since it does not understand the OF. Parent  
selection could be a simply a "random".

Option 2: The node joins the DAG and falls back to the "default" OCP.  
 From there is prolongs the DAG but with OF0 (of course inconsistent  
metrics are not added). This also means that everynode MUST implement  
OF0 and that the network may compromise nodes with different OF at  
some point. Several options even more complex have been discussed  
where one could use common denominator to get as close as possible to  
the desired OF, allow a node not to be so "altruistic", ...

My personal view is that OF management can quick get fairly complex  
and hard to manage. Option 1 is extremely simple and easy to manage.  
If a node is mis-configured (does not support the OF of the DAG) it  
can join it as a leaf in order to have connectivity and send an alarm  
to fix its configuration. We now just need to specify OF in some  
document and this is it.

Several of you mentioned that they were leaning toward option 1, but  
could you please express your opinion, we would like to have it solved  
for the next revision next week.

Thanks.

JP.

---

From: "Julien Abeille (jabeille)" <[email-masked]>
Date: Thu, 5 Nov 2009 10:21:19 +0100

Hi JP,

I am for option 1. As you say OF mismatch is a configuration problem,
joining as a leaf works fine. I am also not too keen having extra code
on a sensor just because the admin did not do a rather simple task
properly.

Best,
Julien

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On 
> Behalf Of JP Vasseur (jvasseur)
> Sent: jeudi 5 novembre 2009 08:25
> To: roll WG
> Subject: [Roll] Opinion please
> 
> Dear all,
> 
> /co-chair hat off/
> 
> Suppose that a DAG is formed that support OFx. A new node 
> willing to join the DAG does not support OFx but OFy. Note 
> that by OF we actually mean the Objective function and the metric.
> 
> Option 1: The node simply joins the DAG as a leaf. In order 
> words, the node has connectivity since it joins the DAG but 
> will not act as a router for others since it does not 
> understand the OF. Parent selection could be a simply a "random".
> 
>  From there is prolongs the DAG but with OF0 (of course 
> inconsistent metrics are not added). This also means that 
> everynode MUST implement OF0 and that the network may 
> compromise nodes with different OF at some point. Several 
> options even more complex have been discussed where one could 
> use common denominator to get as close as possible to the 
> desired OF, allow a node not to be so "altruistic", ...
> 
> My personal view is that OF management can quick get fairly 
> complex and hard to manage. Option 1 is extremely simple and 
> easy to manage.  
> If a node is mis-configured (does not support the OF of the 
> DAG) it can join it as a leaf in order to have connectivity 
> and send an alarm to fix its configuration. We now just need 
> to specify OF in some document and this is it.
> 
> Several of you mentioned that they were leaning toward option 
> 1, but could you please express your opinion, we would like 
> to have it solved for the next revision next week.
> 
> Thanks.
> 
> JP.
> 
> _______________________________________________
> Roll mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/roll
>

---

From: Zach Shelby <[email-masked]>
Date: Thu, 5 Nov 2009 11:29:53 +0200

I would prefer Option 1. For all scenarios I have RPL in mind for,  
there is not a problem in setting the OF. So for exceptions, falling  
back as a leaf node works fine.

Zach

On Nov 5, 2009, at 9:24 , JP Vasseur wrote:

> join the DAG does not support OFx but OFy. Note that by OF we  
> actually mean the Objective function and the metric.
>
> Option 1: The node simply joins the DAG as a leaf. In order words,  
> the node has connectivity since it joins the DAG but will not act as  
> a router for others since it does not understand the OF. Parent  
> Option 2: The node joins the DAG and falls back to the "default"  
> OCP. From there is prolongs the DAG but with OF0 (of course  
> inconsistent metrics are not added). This also means that everynode  
> MUST implement OF0 and that the network may compromise nodes with  
> different OF at some point. Several options even more complex have  
> been discussed where one could use common denominator to get as  
> close as possible to the desired OF, allow a node not to be so  
> "altruistic", ...
>
> can join it as a leaf in order to have connectivity and send an  
> alarm to fix its configuration. We now just need to specify OF in  
> some document and this is it.
>
> could you please express your opinion, we would like to have it  
> solved for the next revision next week.
>
> Thanks.
>
> JP.
>

-- 
http://www.sensinode.com
http://zachshelby.org - My blog “On the Internet of Things”
Mobile: +358 40 7796297

Zach Shelby
Head of Research
Sensinode Ltd.
Kidekuja 2
88610 Vuokatti, FINLAND

This e-mail and all attached material are confidential and may contain  
legally privileged information. If you are not the intended recipient,  
please contact the sender and delete the e-mail from your system  
without producing, distributing or retaining copies thereof.

---

From: Richard Kelsey <[email-masked]>
Date: Thu, 05 Nov 2009 08:56:37 -0500

Date: Thu, 5 Nov 2009 10:21:19 +0100
   From: "Julien Abeille (jabeille)" <[email-masked]>

   Hi JP,

+1
                 -Richard Kelsey

-----Original Message-----

Dear all,

/co-chair hat off/

Option 2: The node joins the DAG and falls back to the 
"default" OCP.  

Thanks.

JP.

---

From: Emmanuel Baccelli <[email-masked]>
Date: Thu, 5 Nov 2009 15:14:54 +0100

Hi JP,

I also root for option 1. It will indeed make the draft simpler. Actually I
already mentionned this subject in my previous email to the list, giving
feedback on the overview section (section 3).

Emmanuel

---

From: Geoff Mulligan <[email-masked]>
Date: Thu, 05 Nov 2009 11:14:26 -0700

I support option 1.  The node has connectivity and we don't have to
complicate the code on all of the nodes.

	geoff

---

From: Michael Richardson <[email-masked]>
Date: Thu, 05 Nov 2009 13:25:07 -0500

>>>>> "Geoff" == Geoff Mulligan <[email-masked]> writes:
    Geoff> I support option 1.  The node has connectivity and we don't
    Geoff> have to complicate the code on all of the nodes.

  I think I agree. It's a MUST --- node connects.
  If it doesn't connect, operator can not ask it why it isn't acting as
a router!

  Option 2, could be a MAY.
  Connectivity for downstreams nodes is only affected if the node is
only way to get connected.  The downstream nodes can compromise on OF0,
or get no connectivity --- that's their local decision. 

-- 
]       He who is tired of Weird Al is tired of life!           |  firewalls  [
]   Michael Richardson, Sandelman Software Works, Ottawa, ON    |net architect[
] [email-masked] http://www.sandelman.ottawa.on.ca/ |device driver[
   Kyoto Plus: watch the video <http://www.youtube.com/watch?v=kzx1ycLXQSE>
	               then sign the petition.

---

From: "Pete St. Pierre" <[email-masked]>
Date: Thu, 05 Nov 2009 10:29:09 -0800

Option 1 looks appropriate to me.  At this point I think simple is good.

...Pete

>> actually
>> the

---

From: Jonathan Hui <[email-masked]>
Date: Thu, 5 Nov 2009 10:32:22 -0800

I prefer option 1.

--
Jonathan Hui

---

From: [email-masked]
Date: Thu, 5 Nov 2009 13:23:07 -0600

I pick Option 1 under duress.

I certainly favor the simplicity of Option 1 over Option 2; however last 
week we also had an Option 3 which was my favorite - that being that the 
node simply does not join the DAG.  Option 1 as described, indicates that 
the node joins the DAG as a leaf node.  My question is - how does a node 
even know it's a leaf node?  My understanding is that DAG children know 
their parents, but DAG parents do not know who their children are or even 
if they have children.  If there is a way to know that a node is a leaf 
node, then what does it do to maintain its status of a leaf node; that is 
not allowing other nodes to attach to it in the future as children? 

If someone can help me understand these mechanics, I will change my vote.

Thanks,

Jerry

JP Vasseur <[email-masked]> 
Sent by: [email-masked]
11/05/2009 03:17 AM

To
roll WG <[email-masked]>
cc

Subject
[Roll] Opinion please

Dear all,

/co-chair hat off/

Thanks.

JP.

---

From: Michael Richardson <[email-masked]>
Date: Thu, 05 Nov 2009 15:32:42 -0500

{again, you emailed [email-masked]. Fix your MUA}

>>>>> "Jerald" == Jerald P Martocci <[email-masked]> writes:
    Jerald> I pick Option 1 under duress.

    Jerald> I certainly favor the simplicity of Option 1 over Option 2;
    Jerald> however last week we also had an Option 3 which was my
    Jerald> favorite - that being that the node simply does not join the
    Jerald> DAG.  Option 1 as described, indicates that the node joins
    Jerald> the DAG as a leaf node.  My question is - how does a node
    Jerald> even know it's a leaf node?  My understanding is that DAG

  It knows it's a left node because it knows that it failed to find a
compatible OFy.  

  When it's a leaf node, it does not process the DIOs that it receives,
and does not forward that information (list of prefixes, etc.) to it's parent. 

- --

---

From: [email-masked]
Date: Thu, 5 Nov 2009 17:00:33 -0600

Hi Michael,

Comments below ...

Michael Richardson <[email-masked]> 
Sent by: [email-masked]
11/05/2009 02:32 PM

To
roll WG <[email-masked]>
cc

Subject
Re: [Roll] Opinion please

Why is this a discriminator?  The node could have other child nodes 
already attached to itself prior to the node attaching onto the DAG.  This 
set of nodes could all ascribe to the same OFy, yet be different that the 
OFx of the main DAG.

  When it's a leaf node, it does not process the DIOs that it receives,
and does not forward that information (list of prefixes, etc.) to it's 
parent. 

Ok.  I assumed that to eliminate newly found children the node would stop 
sending DIOs.  However, I wasn't sure if DIOs are needed to be sent out 
periodically for other reasons.

- -- 
]       He who is tired of Weird Al is tired of life!           | 
firewalls  [
]   Michael Richardson, Sandelman Software Works, Ottawa, ON    |net 
architect[
] [email-masked] http://www.sandelman.ottawa.on.ca/ |device 
driver[
   Kyoto Plus: watch the video <http://www.youtube.com/watch?v=kzx1ycLXQSE
                                then sign the petition.

---

From: Michael Richardson <[email-masked]>
Date: Thu, 05 Nov 2009 20:18:10 -0500

mcr>   It knows it's a left node because it knows that it failed
    mcr> to find a compatible OFy.

    Jerald> Why is this a discriminator?  The node could have other
    Jerald> child nodes already attached to itself prior to the node
    Jerald> attaching onto the DAG.  This set of nodes could all ascribe
    Jerald> to the same OFy, yet be different that the OFx of the main
    Jerald> DAG.

okay, so if a node (AA) that implements OFy picks a new parent that has only
OF0, it could then tell all it's children that it now has OF0, and
those children, expecting OFy, would be in the same situation as AA.
It can't forward OFx, because it really doesn't understand OFx.

    mcr>   When it's a leaf node, it does not process the DIOs that
    mcr> it receives, and does not forward that information (list of
    mcr> prefixes, etc.) to it's parent.

    Jerald> Ok.  I assumed that to eliminate newly found children the
    Jerald> node would stop sending DIOs.  However, I wasn't sure if
    Jerald> DIOs are needed to be sent out periodically for other
    Jerald> reasons.

I'm a bit vague on this myself. I think that it has to unicast DIOs to
it's parent.  It should not be multicasting DIOs if it doesn't want to
be a parent.

---

From: "Julien Abeille (jabeille)" <[email-masked]>
Date: Fri, 6 Nov 2009 08:45:28 +0100

Hi all,

To eliminate children the parent can send DIO with infinite rank right
away? Or just resetting trickle, and starting T, which would expire
quickly.

Julien

> Behalf Of Michael Richardson
> Sent: vendredi 6 novembre 2009 02:18
> To: roll WG
> Subject: Re: [Roll] Opinion please
> 
> 
> okay, so if a node (AA) that implements OFy picks a new 
> parent that has only OF0, it could then tell all it's 
> children that it now has OF0, and those children, expecting 
> OFy, would be in the same situation as AA.
> I'm a bit vague on this myself. I think that it has to 
> unicast DIOs to it's parent.  It should not be multicasting 
> DIOs if it doesn't want to be a parent.
> 
> -- 
> ] [email-masked] 
> http://www.sandelman.ottawa.on.ca/ |device driver[
>    Kyoto Plus: watch the video 
> <http://www.youtube.com/watch?v=kzx1ycLXQSE>
> 	               then sign the petition.

---

From: JP Vasseur <[email-masked]>
Date: Fri, 6 Nov 2009 13:15:47 +0100

> away? Or just resetting trickle, and starting T, which would expire

I think that the agreement is simply to join as a leaf if you do not  
understand the OF
(simply do not send DIO).

Cheers.

JP.

---

From: [email-masked]
Date: Fri, 6 Nov 2009 08:35:32 -0600

Julien, Michael,

Yeah, I guess so.  Presumably, the kids will find a new parent if the 
parent advertises infinite rank.  The only special case we need to 
consider is if some of the children have no other possible connection 
point to the DAG from a physical radio point-of-view.

Thanks for the clarification

Jerry

"Julien Abeille (jabeille)" <[email-masked]> 
Sent by: [email-masked]
11/06/2009 01:45 AM

To
"Michael Richardson" <[email-masked]>, "roll WG" <[email-masked]>
cc

Subject

Hi all,

Julien

---

From: JP Vasseur <[email-masked]>
Date: Mon, 9 Nov 2009 11:05:59 +0100

Strong consensus towards Option 1.

This closes the ticket #10 and will be reflected in rev-05.

Thanks.

JP.

---

From: JP Vasseur <[email-masked]>
Date: Mon, 9 Nov 2009 11:08:26 +0100

Sorry the tile of the previous email should read "Ticket #10" closed.

On Nov 9, 2009, at 11:05 AM, JP Vasseur wrote:

>> Suppose that a DAG is formed that support OFx. A new node willing  
>> to join the DAG does not support OFx but OFy. Note that by OF we  
>> the node has connectivity since it joins the DAG but will not act  
>> as a router for others since it does not understand the OF. Parent  
>> and hard to manage. Option 1 is extremely simple and easy to  
>> manage. If a node is mis-configured (does not support the OF of the  
>> DAG) it can join it as a leaf in order to have connectivity and  
>> send an alarm to fix its configuration. We now just need to specify  
>> OF in some document and this is it.
>>
>> Several of you mentioned that they were leaning toward option 1,  
>> but could you please express your opinion, we would like to have it

---

From: JP Vasseur <[email-masked]>
Date: Mon, 9 Nov 2009 11:58:54 +0100

So here is the plan for rev-5.

First OCP0 will be removed from the core specification. There will no  
longer be any requirement
for a node to support OCP0. Various OCPs will be defined in separate  
drafts and each node will
be provisioned to support one or more OCPs

If a node receives a DIO referring to an OCP that it does not support/ 
understand, it may join the
DAG as a leaf and log the issue.

In the absence of comments, we will update rev-05 accordingly.

Thanks.

JP.

---

From: "Pascal Thubert (pthubert)" <[email-masked]>
Date: Mon, 9 Nov 2009 12:11:59 +0100

Hi JP:

I'm anxious that the term of the resolution that you propose (remove OCP
0) opens the way to:

- 2 implementation that could never interop (no ocp in common)
- mandatory config (no working 'out of the box' default behavior)

Is that really what this group wants?

Pascal

>From: [email-masked] [mailto:[email-masked]] On Behalf Of
JP Vasseur (jvasseur)
>Sent: lundi 9 novembre 2009 11:59
>To: roll WG
>Subject: Re: [Roll] Ticket #10: Closed
>

---

From: JP Vasseur <[email-masked]>
Date: Mon, 9 Nov 2009 12:16:19 +0100

Hi Pascal,

> - mandatory config (no working 'out of the box' default behavior)

Here is another way to look at it. You simply configure an OCP and all  
nodes willing
to participate to a DAG have to implement that same OCP.

If you mandate the use of an OCP like the OCP0, that also means that  
ALL nodes MUST
implement OCP0, even if they do not want to implement that OCP.

In other words, this is a trivial implementation issue easy to fix:  
specify the OCP to use
on the node.

---

From: "Pascal Thubert (pthubert)" <[email-masked]>
Date: Mon, 9 Nov 2009 12:25:27 +0100

>to participate to a DAG have to implement that same OCP.
Simply configure... 

In industrial, tools for doing that will certainly exist. What about
game boys and McDo toys? Can't they do RPL?

>implement OCP0, even if they do not want to implement that OCP.

Yes, that was the goal. Making it fairly simple but implemented in every
node so if I buy something from brand A and something from brand B, I'm
sure there's at least one OCP that both implement.

Doesn't that scare you that we allow for 2 RPL-compliant nodes to be by
design unable to talk together whatever the way we configure them? 

>In other words, this is a trivial implementation issue easy to fix:

The OCP must be implemented in the node first. There's code associated
to it.

It makes sense that an implementation should have a mechanism to add
more OCPs over time, and that's what I indicated by calling OCPs
plug-ins.

Pascal

>>>>> inconsistent metrics are not added). This also means that
everynode
>>>>> My personal view is that OF management can quick get fairly
complex

---

From: "Julien Abeille (jabeille)" <[email-masked]>
Date: Mon, 9 Nov 2009 13:34:00 +0100

Hi Pascal, JP, 

> Behalf Of Pascal Thubert (pthubert)
> Sent: lundi 9 novembre 2009 12:25
> To: JP Vasseur (jvasseur)
> Cc: roll WG
> >nodes willing to participate to a DAG have to implement that 
> same OCP.
> >
> Simply configure... 
> 
> In industrial, tools for doing that will certainly exist. 
> What about game boys and McDo toys? Can't they do RPL?
> 
> 
> >ALL nodes MUST implement OCP0, even if they do not want to implement 
> >that OCP.
> 
> Yes, that was the goal. Making it fairly simple but 
> implemented in every node so if I buy something from brand A 
> and something from brand B, I'm sure there's at least one OCP 
> that both implement.
> 
The root has to be configured. If it sends OCPx in the DIO, the game boy
will join as a leaf anyway

Again, I do not think this is worth extra code on a node.

> Doesn't that scare you that we allow for 2 RPL-compliant 
> nodes to be by design unable to talk together whatever the 
> way we configure them? 
> 
> >
> The OCP must be implemented in the node first. There's code 
> associated to it.
> 
> It makes sense that an implementation should have a mechanism 
> to add more OCPs over time, and that's what I indicated by 
> calling OCPs plug-ins.
> 
> Pascal
> 
> 
> >
> >>> From: [email-masked] 
> [mailto:[email-masked]] On Behalf 
> >>> Of
> >> JP Vasseur (jvasseur)
> >>> drafts and each node will be provisioned to support one 
> or more OCPs
> >>>
> >>> If a node receives a DIO referring to an OCP that it does not 
> >>> support/ understand, it may join the DAG as a leaf and log the 
> >>> issue.
> >>>

---

From: "Pascal Thubert (pthubert)" <[email-masked]>
Date: Mon, 9 Nov 2009 13:56:23 +0100

Hi Julien:

How do I form a network of game boys is my question. 

Pascal

>From: Julien Abeille (jabeille)
>Sent: lundi 9 novembre 2009 13:34
>To: Pascal Thubert (pthubert); JP Vasseur (jvasseur)
>Cc: roll WG
>Subject: RE: [Roll] Ticket #10: Closed
>
>Hi Pascal, JP,
>
>The root has to be configured. If it sends OCPx in the DIO, the game
boy will join as a leaf anyway
>> >>> First OCP0 will be removed from the core specification. There
will
>> no
"default"
>> >>>>> but could you please express your opinion, we would like to
have
>> it

---

From: "Julien Abeille (jabeille)" <[email-masked]>
Date: Mon, 9 Nov 2009 14:01:27 +0100

Just game boys would all support the same OCP. Game boy + PSP may indeed
not support the same one. 
For me this is interop, and does not happen by magic. People that want
their device to interoperate have to check they implement the same
things. Otherwise IETF ends up mandating that all device implement the
same OCP, same instance, as well as the same transport, the same
application layer protocol, the same application, same security, the
same data structures.... For me this is the role of an application
specific SDO/Forum.

Best,
Julien

> From: Pascal Thubert (pthubert) 
> Sent: lundi 9 novembre 2009 13:56
> To: Julien Abeille (jabeille); JP Vasseur (jvasseur)
> Cc: 'roll WG'
> >> From: [email-masked] [mailto:[email-masked]] 
> On Behalf 
> >> Of Pascal Thubert (pthubert)
> >> Yes, that was the goal. Making it fairly simple but implemented in 
> >> every node so if I buy something from brand A and something from 
> >> brand B, I'm sure there's at least one OCP that both implement.
> >>
> nodes to be 
> >> by design unable to talk together whatever the way we 
> configure them?
> >>
> >> >
> >> >>>>> manage. If a node is mis-configured (does not 
> support the OF of
> >> the

---

From: Michael Richardson <[email-masked]>
Date: Mon, 09 Nov 2009 09:42:31 -0500

>>>>> "Julien" == Julien Abeille <(jabeille)" <[email-masked]>> writes:
    Julien> Just game boys would all support the same OCP. Game boy +
    Julien> PSP may indeed not support the same one. For me this is
    Julien> interop, and does not happen by magic. People that want
    Julien> their device to interoperate have to check they implement
    Julien> the same things. Otherwise IETF ends up mandating that all
    Julien> device implement the same OCP, same instance, as well as the
    Julien> same transport, the same application layer protocol, the
    Julien> same application, same security, the same data
    Julien> structures.... 

Yes, that's certainly true.  It is a good, not a bad.

And if done correctly, interop does happen by magic.
You are reading this email, because email was standardized.  
It did not need to be standardized for technical discussion seperately
from being standardized for use with close relatives.

The precise profile of what is MUST, and what is MAY, is sometimes
delegated to other documents, but the base specification should not have
dozens of options if we expect to get anywhere.

    >> How do I form a network of game boys is my question.

You have to use OCP0. We have to specify that.
The document will likely want to say SHOULD for it.

- --

---

From: "Julien Abeille (jabeille)" <[email-masked]>
Date: Mon, 9 Nov 2009 18:28:19 +0100

Hi Michael, 

> Sent: lundi 9 novembre 2009 15:43
> To: roll WG
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
> 
> 
Well I am reading this email because I have a laptop that supports a
bunch of RFCs, and  bunch of email standards. 

So I guess we disagree on benefits vs costs. And again if the root does
not send OCP0, the game boy having OCP0 is useless. Are we trying to
solve an adhoc network problem? Do the requirements drafts and RFCs
require this kind of scenario?

Best,
Julien 

> It did not need to be standardized for technical discussion 
> seperately from being standardized for use with close relatives.
> 
> The precise profile of what is MUST, and what is MAY, is 
> sometimes delegated to other documents, but the base 
> specification should not have dozens of options if we expect 
> to get anywhere.
> 
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v1.4.9 (GNU/Linux)
> Comment: Finger me for keys
> 
> iQEVAwUBSvgqVYCLcPvd0N1lAQL9xgf7BR/WMiVbwCZTwMBfRC66LSNEcMac4WfM
> LzBCkupWl7HCiyf9oJ0kOIqUaYbTIK5tRItEuaW1LiqKEZksWr4Gxsel3EyTgodL
> aMwbzoBmxheUdmvQiqMTJnoIYB9A2uZfAb2D36z8JLjWV/IGy9Ijze7sVdExe1s2
> 1Yl5ZHGKbPwcYOU5meAWaLNmVjPNTNjd+mtyS1SGUkEYTWgDK4ydCdJ9anqd2gfF
> 5M0Vkr2zgaYVbn0l6t6Ni3KC6eQ0wcoSP9hB8LaT26lEx3Vo/Hr/eucbR8QoGhxb
> g/wS1kxTVO9pINjMklEeD5sGg0lRnztsl8MCBN0D8wtF4VkLGS6xuw==
> =aI9Q
> -----END PGP SIGNATURE-----

---

From: Michael Richardson <[email-masked]>
Date: Mon, 09 Nov 2009 19:22:03 -0500

>> And if done correctly, interop does happen by magic.  You are
    >> reading this email, because email was standardized.

    Julien> Well I am reading this email because I have a laptop that
    Julien> supports a bunch of RFCs, and bunch of email standards.

Right. When you purchased the laptop, did you have to tell the
salesperson that you would be using the laptop for *IETF* emails?
Did you load an *IETF* *WG* profile into your email system?

You can, ad-hoc, send email to any other email system in the world, for
a variety of purposes.  You can even send voice mail between systems
using SMTP, but it turned out that a restricted profile (a subset) of
SMTP (vpim) is useful. 

    Julien> So I guess we disagree on benefits vs costs. And again if
    Julien> the root does not send OCP0, the game boy having OCP0 is
    Julien> useless. Are we trying to solve an adhoc network problem? Do
    Julien> the requirements drafts and RFCs require this kind of
    Julien> scenario?

If the root node your game boy can see right now does not send OCP0,
then the DAG anchored by that root node is not useful to your game boy.

Being a game boy, it's mobile, and it might see another root node that
is more to its liking.  Also, being mobile, it may well *BECOME* a root
node (an ungrounded one), and maybe I'll play head to head with some
other guy in the next train car.

If that original root node has been configured not to send the OCP0, that's a
configuration decision.  If it can not be configured to send OCP0, then
it's not interoperable.  That might be okay -- you might write a subset
profile of RPL that mandates a different OCPx, and permits OCP0 to be
eliminated -- but you'd claim compliance to that RFC, not the RPL STD.

Almost all WGs (and other SDOs) that build general protocols where there
is not a minimal subset that is MUST, have wound up having to multiple
"profile" documents, and in the end, regularly fail to interop in the field.
(X.500->X509->X509.v3->PKIX->PKI4IPSEC comes to mind)

So the answer is: if a device claims that it supports RPL, then it yes,
it should be possible to configure it to work in an adhoc network.
If all light switches in a home automation application need to support
OCP4 (as specified in RFCXYZQ), and you order them from the factory 
with that as the default, then great.  If the device supports RPL, I
expect to be able to pull the units out of my home (after that kitchen
fire which writes my house off, maybe), and use them at my cottage,
where OCP0 is going to be used.  Maybe I gotta tweak some config
options.

(my last email on this)

- --