Subject: [Roll] Soliciting WG comments on DIS for RPL Last Call

From: Nicolas DEJEAN <[email-masked]>
Date: Tue, 20 Jul 2010 17:56:31 +0200

Hello all,

Based on our experience of having deployed many smart metering
networks (totalling several million nodes), we have an issue with the
way DIS and DIOs are currently handled by RPL. To solve this issue, we
suggest minor modifications into the RPL core spec that only impacts
the connection process of a leaf node to the LLN.

As part of the everyday life of a smart metering network, every so
often, a meter needs to be replaced or an extra one needs to be added.
After physical installation, the technician stands by to witness the
network hook-up. He/she will not leave the premises before the meter
is satisfactorily connected. Every elapsed minute is an operation
cost. We are talking real money. There's no way a meter will wait for
a DIO to arrive by itself after some random number of hours. The meter
has to solicit DIOs from yet unknown neighbor routers, and that's done
by multicasting DIS'es. In our case of interest, the meter will be a
leaf node, therefore its presence will not modify the network
topology. Currently, RPL mandates that, in response to a multicast
DIS, DIOs are multicasted and Trickle timers at the routers are reset.

Firstly, resetting the Trickle timers generates much more control
traffic than is needed. Neither the meter being installed nor neighbor
nodes need the frequent repeats of the very same DIO (remember the
topology is not changing). This is only a waste of energy at the
routers and at the nodes that are the destination of the DIOs.

Secondly, multicast makes the problem even worse by enlarging the
audience for the DIO. Other than the meter being installed, nodes
nearby do not need to receive the DIO, because they have long settled
and the topology is not changing.

In dense environments, the two effects combine to drastically reduce
the network lifetime compared to our currently deployed, non-RPL,
protocol.

It is our industrial experience that this is a real and significant
problem and we worked hard to solve it.
Let's leverage that experience to the benefit of RPL users.

Therefore, here are two possibilites for RPL.

Option A)
* In section 5.2, specify an L bit ("Leaf node") in the DIS format.
* In section 7.3, change the third item of the list to read "When a
node receives a multicast DIS with a cleared L-bit and a Solicited
Information option and when the node matches all of the predicates in
the Solicited Information option."
* In section 7.3, specify the algorithm to be run for responding with
a unicast DIO to a multicast DIS with L-bit set. This text shall be
described in a further email. This could advantageously be a temporary
Trickle timer.

Option B)
* In section 7.3, change the third item of the list to read "When a
node receives a multicast DIS with a Solicited Information option and
the node matches all of the predicates in the Solicited Information
option, unless a DIS flag restricts this behavior."
* describe the L bit and RPL behavior in a separate I-D, together with
the DIS option TLVs.

Would the WG please voice their opinion on these options?

Thanks

---

From: JP Vasseur <[email-masked]>
Date: Tue, 20 Jul 2010 18:05:41 +0200

Hi Nicolas,

On Jul 20, 2010, at 5:56 PM, Nicolas DEJEAN wrote:

> topology.

Thanks for sharing your experience, and we can expect similar behavior  
in
a number of situations.

> Currently, RPL mandates that, in response to a multicast
> topology is not changing).

Indeed, because the newly inserted node is a leaf.

> This is only a waste of energy at the

Agree.

> * describe the L bit and RPL behavior in a separate I-D, together with

You raise an important point. Agree with the conclusion.
At this point, I would vote for B.

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

---

From: Jonathan Hui <[email-masked]>
Date: Tue, 20 Jul 2010 09:13:53 -0700

Nicolas,

> Would the WG please voice their opinion on these options?

Without a better understanding of the "response algorithm" and additional information needed to drive how nodes respond, I would lean to have this functionality described in a separate I-D and not change the current RPL spec.  For example, it's unclear to me whether it should be a flag, an option, or a sub-option of an updated solicited information option.  Note that the rules in Section 7.3 are SHOULDs, so it is OK to do something else if there is a valid and well-understood reason.  

--
Jonathan Hui

---

From: Jonathan Hui <[email-masked]>
Date: Tue, 20 Jul 2010 09:34:31 -0700

> Without a better understanding of the "response algorithm" and additional information needed to drive how nodes respond, I would lean to have this functionality described in a separate I-D and not…

Oops.  I remembered Section 7.3 wrong and it does read MUST, my mistake.  My preference is still for Option B.  I'm OK with including a flag to that disables the Trickle reset.  But does it make sense to limit its use to the Solicited Information option, as you proposed?  If you claim that the link-layer will guarantee collision-free unicast transmissions, then I guess it would be OK to allow neighbors to reply.  But in either case, we might want to put some text in describing the dangers of the "disable Trickle reset" flag.

--
Jonathan Hui

---

From: Philip Levis <[email-masked]>
Date: Tue, 20 Jul 2010 09:38:13 -0700

> Oops.  I remembered Section 7.3 wrong and it does read MUST, my mistake.  My preference is still for Option B.  I'm OK with including a flag to that disables the Trickle reset.  But does it make se…

My concern is that we're adding a specialized mechanism under the assumptions of how the underlying link layer operates. Using this mechanism with link layers that do not have that property could be disastrous (response implosion, hidden terminal collisions).

That being said, it's clear we need to figure out if there's a safer way for RPL to meet the application requirements.

Phil

---

From: Jonathan Hui <[email-masked]>
Date: Tue, 20 Jul 2010 09:43:10 -0700

Phil,

> That being said, it's clear we need to figure out if there's a safer way for RPL to meet the application requirements.

I share your concerns.  What I wanted to convey in my mail wasn't clear, but I meant to say that disabling a Trickle reset in response to a DIS is OK from my perspective - it's what other actions nodes do after that we need to think carefully about, and I'm arguing that those latter mechanisms go in a separate (possibly domain specific) draft.  Or is it that you do not want any mechanism to avoid a Trickle reset?

--
Jonathan Hui

---

From: JP Vasseur <[email-masked]>
Date: Tue, 20 Jul 2010 18:48:37 +0200

On Jul 20, 2010, at 6:43 PM, Jonathan Hui wrote:

>>> Oops.  I remembered Section 7.3 wrong and it does read MUST, my  
>>> mistake.  My preference is still for Option B.  I'm OK with  
>>> including a flag to that disables the Trickle reset.  But does it  
>>> make sense to limit its use to the Solicited Information option,  
>>> as you proposed?  If you claim that the link-layer will guarantee  
>>> collision-free unicast transmissions, then I guess it would be OK  
>>> to allow neighbors to reply.  But in either case, we might want to  
>>> put some text in describing the dangers of the "disable Trickle  
>>> reset" flag.
>>
>> My concern is that we're adding a specialized mechanism under the  
>> assumptions of how the underlying link layer operates. Using this  
>> mechanism with link layers that do not have that property could be  
>> disastrous (response implosion, hidden terminal collisions).
>>
>> That being said, it's clear we need to figure out if there's a  
>> safer way for RPL to meet the application requirements.
>
> I share your concerns.  What I wanted to convey in my mail wasn't  
> clear, but I meant to say that disabling a Trickle reset in response  
> to a DIS is OK from my perspective - it's what other actions nodes  
> do after that we need to think carefully about, and I'm arguing that  
> those latter mechanisms go in a separate (possibly domain specific)  
> draft.

Agree, this is option B.

> Or is it that you do not want any mechanism to avoid a Trickle reset?
>
> --
> Jonathan Hui
>

---

From: "Pascal Thubert (pthubert)" <[email-masked]>
Date: Tue, 20 Jul 2010 20:27:51 +0200

Hi Nicolas:

Thanks a bunch for these excellent suggestions. In my view, this is
related to section 16.7 and we could have some words there about the
first discovery as we have words about maintenance.

Like for 16.7, I tend to think that there might be more than one
behavior to address different media, and that your option B is the one
that enables further drafts and eventually different drafts / specs in
different environments to specify the behavior that they expect.  What's
different though is that the mechanism needs to be related to RPL,
because of the DIS filters.

You have my vote to adopt B).

Pascal

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On Behalf
Of
> Nicolas DEJEAN
> Sent: Tuesday, July 20, 2010 5:57 PM
> To: roll WG
> Subject: [Roll] Soliciting WG comments on DIS for RPL Last Call
> 
> Hello all,
> 
networks
> (totalling several million nodes), we have an issue with the way DIS
and DIOs
> are currently handled by RPL. To solve this issue, we suggest minor
> modifications into the RPL core spec that only impacts the connection
process
> of a leaf node to the LLN.
> 
often, a
> meter needs to be replaced or an extra one needs to be added.
network
> hook-up. He/she will not leave the premises before the meter is
satisfactorily
> connected. Every elapsed minute is an operation cost. We are talking
real
> money. There's no way a meter will wait for a DIO to arrive by itself
after some
> random number of hours. The meter has to solicit DIOs from yet unknown
> neighbor routers, and that's done by multicasting DIS'es. In our case
of interest,
> the meter will be a leaf node, therefore its presence will not modify
the
> network topology. Currently, RPL mandates that, in response to a
multicast DIS,
> DIOs are multicasted and Trickle timers at the routers are reset.
> 
traffic than is
> needed. Neither the meter being installed nor neighbor nodes need the
> frequent repeats of the very same DIO (remember the topology is not
> changing). This is only a waste of energy at the routers and at the
nodes that
> are the destination of the DIOs.
> 
audience
> for the DIO. Other than the meter being installed, nodes nearby do not
need to
> receive the DIO, because they have long settled and the topology is
not
> changing.
the
> network lifetime compared to our currently deployed, non-RPL,
protocol.
> It is our industrial experience that this is a real and significant
problem and we
> worked hard to solve it.
node receives
> a multicast DIS with a cleared L-bit and a Solicited Information
option and when
> the node matches all of the predicates in the Solicited Information
option."
> * In section 7.3, specify the algorithm to be run for responding with
a unicast
> DIO to a multicast DIS with L-bit set. This text shall be described in
a further
> email. This could advantageously be a temporary Trickle timer.
> 
> Option B)
node receives
> a multicast DIS with a Solicited Information option and the node
matches all of
> the predicates in the Solicited Information option, unless a DIS flag
restricts this
> behavior."
the DIS
> option TLVs.

---

From: Philip Levis <[email-masked]>
Date: Tue, 20 Jul 2010 11:28:40 -0700

> I share your concerns.  What I wanted to convey in my mail wasn't clear, but I meant to say that disabling a Trickle reset in response to a DIS is OK from my perspective - it's what other actions n…

Let's be more precise: we're not really talking about disabling a Trickle reset, we're talking about requesting an immediate response. The transmission is independent of Trickle timers, although it could affect suppression.

This is fine as a mechanism: currently, unicast DIS transmissions cause this behavior (e.g., to obtain the DODAG Configuration). My concern is that the proposal is to allow this from a multicast transmission.

A protocol shouldn't allow a node to trigger immediate responses from many nodes simultaneously, due to the MAC layer failures this can introduce in wireless. The proposed solution is even a worst-case scenario, where the responses are all unicast so cannot suppress each other. The failure scenario is: I have a hundred nodes in a box, one node sends a multicast DIS that requests immediate unicast responses. If your link layer does not promise collision free unicast transmissions (any CSMA scheme), you waste an enormous amount of energy to create a lot of packet collisions. This seems to be a mechanism that only works for certain link layers and could be disastrous in others.

Phil

---

From: Yoav Ben-Yehezkel <[email-masked]>
Date: Tue, 20 Jul 2010 21:58:05 +0300

I have an alternative suggestion to this.

If instead of disable trickle reset bit we say that we put a few more bits
specifying the amount of time nodes may respond - this would at least put
a time-limit on the congestion of the channel.

BTW - the worst case scenario is when you install a large group of nodes
in network (can be hundreds) and turn all of them on, and have a
technician run around till he sees all nodes are connected. This is a
typical installation scenario in metering applications as well sometimes
denoted as "synchronous wakeup".

Thanks,
Yoav

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of
Philip Levis
Sent: Tuesday, July 20, 2010 9:29 PM
To: Jonathan Hui
Cc: roll WG
Subject: Re: [Roll] Soliciting WG comments on DIS for RPL Last Call

>>> Oops.  I remembered Section 7.3 wrong and it does read MUST, my
mistake.  My preference is still for Option B.  I'm OK with including a
flag to that disables the Trickle reset.  But does it make sense to limit
its use to the Solicited Information option, as you proposed?  If you
claim that the link-layer will guarantee collision-free unicast
transmissions, then I guess it would be OK to allow neighbors to reply.
But in either case, we might want to put some text in describing the
dangers of the "disable Trickle reset" flag.
>>
>> That being said, it's clear we need to figure out if there's a safer
way for RPL to meet the application requirements.
>
> I share your concerns.  What I wanted to convey in my mail wasn't clear,
but I meant to say that disabling a Trickle reset in response to a DIS is
OK from my perspective - it's what other actions nodes do after that we
need to think carefully about, and I'm arguing that those latter
mechanisms go in a separate (possibly domain specific) draft.  Or is it
that you do not want any mechanism to avoid a Trickle reset?

Let's be more precise: we're not really talking about disabling a Trickle
reset, we're talking about requesting an immediate response. The
transmission is independent of Trickle timers, although it could affect
suppression.

This is fine as a mechanism: currently, unicast DIS transmissions cause
this behavior (e.g., to obtain the DODAG Configuration). My concern is
that the proposal is to allow this from a multicast transmission.

A protocol shouldn't allow a node to trigger immediate responses from many
nodes simultaneously, due to the MAC layer failures this can introduce in
wireless. The proposed solution is even a worst-case scenario, where the
responses are all unicast so cannot suppress each other. The failure
scenario is: I have a hundred nodes in a box, one node sends a multicast
DIS that requests immediate unicast responses. If your link layer does not
promise collision free unicast transmissions (any CSMA scheme), you waste
an enormous amount of energy to create a lot of packet collisions. This
seems to be a mechanism that only works for certain link layers and could
be disastrous in others.

Phil

---

From: Yoav Ben-Yehezkel <[email-masked]>
Date: Tue, 20 Jul 2010 22:54:44 +0300

I take this idea back.
Reviewing the list of related emails once more - option B seems good to
me.

Yoav

-----Original Message-----
From: Yoav Ben-Yehezkel [mailto:[email-masked]]
Sent: Tuesday, July 20, 2010 9:58 PM
To: 'Philip Levis'; 'Jonathan Hui'
Cc: 'roll WG'
Subject: RE: [Roll] Soliciting WG comments on DIS for RPL Last Call

Thanks,
Yoav

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

Phil

---

From: JP Vasseur <[email-masked]>
Date: Wed, 21 Jul 2010 07:15:35 +0200

On Jul 20, 2010, at 6:38 PM, Philip Levis wrote:

>>> Without a better understanding of the "response algorithm" and  
>>> additional information needed to drive how nodes respond, I would  
>>> lean to have this functionality described in a separate I-D and  
>>> not change the current RPL spec.  For example, it's unclear to me  
>>> whether it should be a flag, an option, or a sub-option of an  
>>> updated solicited information option.  Note that the rules in  
>>> Section 7.3 are SHOULDs, so it is OK to do something else if there  
>>> is a valid and well-understood reason.
>>
>>
>> make sense to limit its use to the Solicited Information option, as  
>> you proposed?  If you claim that the link-layer will guarantee  
> assumptions of how the underlying link layer operates.

I do not think that we do.We just define a simple mechanism that  
allows for reducing the number of messages when inserting a node
(leaf node). This is true regardless of the link layer in use.

JP.

> Using this mechanism with link layers that do not have that property  
> could be disastrous (response implosion, hidden terminal collisions).
>

---

From: JP Vasseur <[email-masked]>
Date: Wed, 21 Jul 2010 07:57:11 +0200

On Jul 20, 2010, at 8:28 PM, Philip Levis wrote:

>>>> to allow neighbors to reply.  But in either case, we might want  
>>>> to put some text in describing the dangers of the "disable  
>>>> Trickle reset" flag.
>>>
>> clear, but I meant to say that disabling a Trickle reset in  
>> response to a DIS is OK from my perspective - it's what other  
>> actions nodes do after that we need to think carefully about, and  
>> I'm arguing that those latter mechanisms go in a separate (possibly  
>> domain specific) draft.  Or is it that you do not want any  
>> mechanism to avoid a Trickle reset?
>
> Let's be more precise: we're not really talking about disabling a  
> Trickle reset, we're talking about requesting an immediate response.  
> The transmission is independent of Trickle timers, although it could  
> affect suppression.
>
> This is fine as a mechanism: currently, unicast DIS transmissions  
> cause this behavior (e.g., to obtain the DODAG Configuration). My  
> concern is that the proposal is to allow this from a multicast  
> transmission.
>
> A protocol shouldn't allow a node to trigger immediate responses  
> from many nodes simultaneously, due to the MAC layer failures this  
> can introduce in wireless. The proposed solution is even a worst- 
> case scenario, where the responses are all unicast so cannot  
> suppress each other. The failure scenario is: I have a hundred nodes  
> in a box, one node sends a multicast DIS that requests immediate  
> unicast responses. If your link layer does not promise collision  
> free unicast transmissions (any CSMA scheme), you waste an enormous  
> amount of energy to create a lot of packet collisions. This seems to  
> be a mechanism that only works for certain link layers and could be  
> disastrous in others.

Phil, I think that you go further than the proposal. The point is to  
allow for unicast reply of DIO and not general reset timer (could be  
according to a different algorithm to be determined by option B by the  
way ! It does not say that all nodes will immediately reply of course).

JP.

---

From: "Mathilde Durvy (mdurvy)" <[email-masked]>
Date: Wed, 21 Jul 2010 11:43:23 +0200

Hi Nicolas,

I think the scenario is interesting and should be addressed.
I would favor Option B, to avoid modifying RPL too much at this stage. Note
that you probably want to use the solicited option anyway to restrict the
number of unicast DIOs that come back.

Best,
Mathilde

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of
Nicolas DEJEAN
Sent: mardi, 20. juillet 2010 17:57
To: roll WG
Subject: [Roll] Soliciting WG comments on DIS for RPL Last Call

Hello all,

Option A)

Option B)

Thanks

---

From: Nicolas DEJEAN <[email-masked]>
Date: Wed, 21 Jul 2010 12:31:29 +0200

Hello Mathilde,

> number of unicast DIOs that come back.

Yes clearly, this is the idea.

Thanks for your feedback.

Nicolas.

---

From: Tim Winter <[email-masked]>
Date: Wed, 21 Jul 2010 09:21:26 -0400

I also support Option B.

-Tim

On 07/21/2010 06:31 AM, Nicolas DEJEAN wrote:
> Hello Mathilde,
>
> 2010/7/21 Mathilde Durvy (mdurvy)<[email-masked]>:
>> Hi Nicolas,
>>

---

From: Philip Levis <[email-masked]>
Date: Wed, 21 Jul 2010 08:56:29 -0700

On Jul 20, 2010, at 10:15 PM, JP Vasseur wrote:

>> My concern is that we're adding a specialized mechanism under the assumptions of how the underlying link layer operates.
> 
> I do not think that we do.We just define a simple mechanism that allows for reducing the number of messages when inserting a node

JP -- the scheme assumes that unicast transmissions are collision-free. Otherwise a set of correlated responses lead to a rash of collisions and terrible network discovery: it doesn't work. This is a well known problem in wireless[1,2], and one of the major motivations behind Trickle.

Phil

[1] Ni et al. "The broadcast storm problem in a mobile ad hoc network" http://portal.acm.org/citation.cfm?id=313525
[2] Ganesan et al. "Complex Behavior at Scale: An Experimental Study of Low-Power Wireless Sensor Networks (2002)" http://citeseerx.ist.psu.edu/viewdoc/summary?doi=10.1.1.19.770

---

From: <[email-masked]>
Date: Thu, 22 Jul 2010 01:19:00 +0200

In order not to delay the RPL core spec and give more time to thoroughly think through the proposed fixes, I'm in favor of Option B
Best regards,

Dominique 

-----Message d'origine-----
De : [email-masked] [mailto:[email-masked]] De la part de Nicolas DEJEAN
Envoyé : mardi 20 juillet 2010 17:57
À : roll WG
Objet : [Roll] Soliciting WG comments on DIS for RPL Last Call

Hello all,

Based on our experience of having deployed many smart metering networks (totalling several million nodes), we have an issue with the way DIS and DIOs are currently handled by RPL. To solve this issue, we suggest minor modifications into the RPL core spec that only impacts the connection process of a leaf node to the LLN.

As part of the everyday life of a smart metering network, every so often, a meter needs to be replaced or an extra one needs to be added.
After physical installation, the technician stands by to witness the network hook-up. He/she will not leave the premises before the meter is satisfactorily connected. Every elapsed minute is an operation cost. We are talking real money. There's no way a meter will wait for a DIO to arrive by itself after some random number of hours. The meter has to solicit DIOs from yet unknown neighbor routers, and that's done by multicasting DIS'es. In our case of interest, the meter will be a leaf node, therefore its presence will not modify the network topology. Currently, RPL mandates that, in response to a multicast DIS, DIOs are multicasted and Trickle timers at the routers are reset.

Firstly, resetting the Trickle timers generates much more control traffic than is needed. Neither the meter being installed nor neighbor nodes need the frequent repeats of the very same DIO (remember the topology is not changing). This is only a waste of energy at the routers and at the nodes that are the destination of the DIOs.

Secondly, multicast makes the problem even worse by enlarging the audience for the DIO. Other than the meter being installed, nodes nearby do not need to receive the DIO, because they have long settled and the topology is not changing.

In dense environments, the two effects combine to drastically reduce the network lifetime compared to our currently deployed, non-RPL, protocol.

It is our industrial experience that this is a real and significant problem and we worked hard to solve it.
Let's leverage that experience to the benefit of RPL users.

Option A)
* In section 5.2, specify an L bit ("Leaf node") in the DIS format.
* In section 7.3, change the third item of the list to read "When a node receives a multicast DIS with a cleared L-bit and a Solicited Information option and when the node matches all of the predicates in the Solicited Information option."
* In section 7.3, specify the algorithm to be run for responding with a unicast DIO to a multicast DIS with L-bit set. This text shall be described in a further email. This could advantageously be a temporary Trickle timer.

Option B)
* In section 7.3, change the third item of the list to read "When a node receives a multicast DIS with a Solicited Information option and the node matches all of the predicates in the Solicited Information option, unless a DIS flag restricts this behavior."
* describe the L bit and RPL behavior in a separate I-D, together with the DIS option TLVs.

Thanks

---

From: "Pascal Thubert (pthubert)" <[email-masked]>
Date: Thu, 22 Jul 2010 11:51:25 +0200

Phil:

I understand the CA/CD aspect. The group also understands that we need
to do something for this case. What we are being asked is really to
allow the opportunity to do something specific as opposed to MUST a one
fits it all. Would you propose an alternate text that would have the
benefits of B) ? In my view, text that exposes a default behavior but
allows adaptations would be appreciated.

Pascal

> From: [email-masked] [mailto:[email-masked]] On Behalf
Of Philip
> Levis
> Sent: Wednesday, July 21, 2010 5:56 PM
> To: JP Vasseur
> Cc: roll WG
(leaf
> node). This is true regardless of the link layer in use.
> >
> > JP.
> 
> JP -- the scheme assumes that unicast transmissions are
collision-free.
> Otherwise a set of correlated responses lead to a rash of collisions
and terrible
> network discovery: it doesn't work. This is a well known problem in
> wireless[1,2], and one of the major motivations behind Trickle.
> 
> Phil
> 
> 
> [1] Ni et al. "The broadcast storm problem in a mobile ad hoc network"
> http://portal.acm.org/citation.cfm?id=313525
> [2] Ganesan et al. "Complex Behavior at Scale: An Experimental Study
of Low-
> Power Wireless Sensor Networks (2002)"
> http://citeseerx.ist.psu.edu/viewdoc/summary?doi=10.1.1.19.770
> 
>

---

From: JP Vasseur <[email-masked]>
Date: Thu, 22 Jul 2010 21:10:43 +0200

Hi Pascal,

> allows adaptations would be appreciated.

As discussed today i'll work with Phil on the modified text compliant  
with the option B for which
we have a consensus on the mailing list.

JP.

---

From: Philip Levis <[email-masked]>
Date: Thu, 22 Jul 2010 15:43:56 -0700

> allows adaptations would be appreciated.

It looks like there's consensus around option B:

"Option B)
the DIS option TLVs."

With respect to updating the text, I think we can get away without changing anything. Couldn't a future draft simply add a flag whose predicate is always false? The way the current text is written, the flags include the condition under which their predicate is true/false. Does that make sense?

Phil

---

From: JP Vasseur <[email-masked]>
Date: Fri, 23 Jul 2010 08:57:46 +0200

On Jul 23, 2010, at 12:43 AM, Philip Levis wrote:

> With respect to updating the text, I think we can get away without  
> changing anything. Couldn't a future draft simply add a flag whose  
> predicate is always false? The way the current text is written, the  
> flags include the condition under which their predicate is true/ 
> false. Does that make sense?

There may be room for mis-interpretation. I'd suggest to tweak the  
text a little bit though. Let me propose something in a few minutes in  
the ticket#71 and we will close.

Thanks.

JP.