Subject: [Roll] Closure text for ticket #86

From: Mukul Goyal <[email-masked]>
Date: Tue, 10 Apr 2012 21:51:25 -0500 (CDT)

#86: G flag: do we need that text?

Problem
------------------------------
 Disagreement on the meaning of 'G' bit and imposed setting to 0;

Proposed resolution
---------------------------
Add the following text to the draft:

"The origin sets the G flag to indicate the relative importance of the route discovery it is initiating. The G flag is set to one if this particular route discovery is more important from application's perspective than some other route discovery. In other words, the origin sets the G flag to one if this particular route discovery helps meet the application defined goal \cite{rpl}. Thus, the G flag setting helps an intermediate router choose which route discoveries to participate in if it cannot participate in all route discoveries. An intermediate router SHOULD participate in route discoveries with G flag set to one (in preference to ones with G flag set to zero)."

Discussion:
-----------------

 [Pascal]
 " Grounded (G) Flag: MUST be set to zero since this DAG is temporary in
 nature, is created solely for the purpose of P2P-RPL route discovery and
 MUST NOT be used for packet routing."

 On the contrary I'd set it to 1. The goal -being to reach the origin- is
 actually achieved by this DAG.

 [Mukul]
 Actually, the DAG is temporary in nature and vanishes after a short
 while. Even when it exists, it must/should not be used for routing
 packets back to the origin. So, I think the Grounded flag should be
 zero.

 [Pascal2] Please revisit RFC 6650 page 12.
 G means that a goal is achieved. So first you define the goal and then
 the bit becomes obvious. What's your goal?
 Can there be P2P DAGs that achieve the goal and others that make sense
 to build and yet do not achieve the goal?
 If you accept that your operation can actually depend on OF logic, then
 the setting of the goal influences that logic.
 By forcing a value to the goal in the PTP spec, we actually limit the
 applicability of the draft.
 Maybe you can define a default goal and a default setting. But do not
 MUST that it is set to 0...

 [Mukul2]
 When a node joins a temporary P2P DAG, it does not get any additional
 routing information. The DAG is going to disappear after some time,
 should not be used for routing while it exists and which nodes end up
 being on the discovered route is not known until the DRO message comes
 back. So, I think, by default, the G flag has to be zero. However, if
 the setting of G flag may affect how an intermediate node may calculate
 its rank (as per the OF being used), the origin should have the
 flexibility of setting the flag to 1. So, I could modify the text to say
 that "the origin sets the G flag based on its perception of how the
 flag's value would affect the rank calculation under the OF being used.
 By default, the G flag is set to zero given the temporary nature of the
 DAG being created."

 [Pascal3] Why do you feel the need to add anything above what RFC 6550
 says? I do not see any benefit or additional clarity from doing this.

 [Mukul3] RFC 6550 is actually kind of confusing in this regard. On page
 9, it says

 "A typical Goal is to construct the DODAG
         according to a specific Objective Function and to keep
         connectivity to a set of hosts (e.g., to use an Objective
         Function that minimizes a metric and is connected to a specific
         database host to store the collected data)."

 This seems to associate the goal with both OF and reachability to
 certain hosts. Later invocations of the term "goal" seem to refer just
 to the connectivity aspect, e.g., on page 18 RFC 6550 says

 "A grounded DODAG offers connectivity to hosts that are
   required for satisfying the application-defined goal."

 So, my understanding so far was that the "goal" defines connectivity to
 a certain hosts. The relation to objective function is not clear at all
 (if one restricts oneself to reading RFC 6550). The temporary DAGs
 created in P2P-RPL route discovery provide no connectivity whatsoever to
 the joining nodes. So, the only reason to set the G flag to 1 would be
 to allow correct use of an OF. So, I think P2P-RPL spec should use the
 text I offered above (and repeat below):

 "The origin sets the G flag based on its perception of whether joining
 how the flag's value would affect the rank calculation under the OF
 being used. By default, the G flag is set to zero given the temporary
 nature of the DAG being created."

 What do you think?

 [Pascal4] If you think this adds value, I will not oppose. Let's keep
 that as the proposed resolution

 [Mukul4] Sounds good.

Proposed resolution text:

"The origin sets the G flag based on its perception of whether joining
 how the flag's value would affect the rank calculation under the OF
 being used. By default, the G flag is set to zero given the temporary
 nature of the DAG being created."

[Richard5]
I disagree with the proposed resolution.  It adds needless confusion.
The G flag is 0 if and only if the DODAG is floating.
There is no point to allowing floating DODAGs with a P2P-RDO option.  I suggest that the G bit be set to 1 and that routers be explicitly prohibited from creating floating DODAGs with a P2P-RDO option.

[Mukul5]
>The G flag is 0 if and only if the DODAG is floating.

I think that the G flag is 1 if and only if the DODAG is grounded. The temporary DAGs used in P2P-RPL are not grounded, they are temporary. I think that all transient/temporary DAGs are floating by their very nature.

[Michael5]
> I think we need to determine what a grounded DODAG is.
> Does it mean that a node announcing such a thing is attached to the Internet? (In which case P2P usage should G=0)
> Or does it mean that a node is attached to the resource named in the DIO? (In which case origin P2P should G=1)
> 

[Phillip5]
The text in 6550 is pretty clear: 

   Goal: The Goal is an application-specific goal that is defined
         outside the scope of RPL.  Any node that roots a DODAG will
         need to know about this Goal to decide whether or not the Goal
         can be satisfied.  A typical Goal is to construct the DODAG
         according to a specific Objective Function and to keep
         connectivity to a set of hosts (e.g., to use an Objective
         Function that minimizes a metric and is connected to a specific
         database host to store the collected data).

   Grounded: A DODAG is grounded when the DODAG root can satisfy the
         Goal.

   Floating: A DODAG is floating if it is not grounded.  A floating
         DODAG is not expected to have the properties required to
         satisfy the goal.  It may, however, provide connectivity to
         other nodes within the DODAG.

The common case of the Goal is "has connectivity to the Internet" but that's not the only case. I think given the Goal for P2P traffic, I agree with Pascal and Richard that it should be 1.

[Pascal6]
Floating vs. Grounded depends on the goal of the DODAG. I asked you and will ask again what is your goal?
If the goal is to reach the root, then G is 1... If you want to signal something to the OF using the G bit, leave it  open.

[Mukul6]
>If the goal is to reach the root, then G is 1...

I have told you multiple times that joining a P2P-RPL DAG does not give any sort of connectivity to the node.

[Pascal7]
I think we disagree because of the definition of goal itself. The goal is an abstraction. Same goes for the term Objective in OF. RFC 6550 only gives examples of what G could be used for but that is not limiting. Certainly the abstraction may for instance mean that external nodes are reachable via the root. But it could be something else entirely. For instance it could designate a root that can aggregate data.

In practice, G is used to favor a root that reaches the goal vs. one that does not. But that's senseless for local instances that have by definition a single root.

So whatever you set it to does not make a difference for RFC 6550 operations. I figure it could be used for signaling a "transient goal" information to an OF that could use it for a purpose I can't fathom.

In any case, as I suggested earlier and as Richard also suggest now, G SHOULD probably be 1 by default but MAY be set otherwise.

[Mukul7]
Richard wants the flag to always be either 0 or 1. He prefers it to be always 1 but would settle for it being always zero.

I think this is not a critical point. I am OK with whatever resolution you and Richard arrive at. Kindly provide me the resolution text I should put in the draft.

[Pascal8]
I suggest a sentence that says that:

1) For a local instance there can be only one root and one DODAG. G bit cannot and is not used for DODAG selection within an instance. 
2) In a given deployment, a goal can be defined that some P2P DODAGs achieve and others do not. The roots that achieve that goal will set the G bit in their P2P DAGs.
3) the default goal is to create connectivity between origin and target. So by default G should be set to 1.
4) if an intermediate router does not have enough resources to participate to all DODAGs then it should favor DODAGs with the G bit on.

The exact wording is yours...

[Mukul8]
>1) For a local instance there can be only one root and one DODAG. G bit cannot and is not used for DODAG selection within an instance. 

The statement above seems to be at odds with following two statements

>2) In a given deployment, a goal can be defined that some P2P DODAGs achieve and others do not. The roots that achieve that goal will set the G bit in their P2P DAGs.
3) the default goal is to create connectivity between origin and target. So by default G should be set to 1.

As per statement 1, the G flag can never be 1 for P2P-RPL DAGs because they use local instance ids.
As per statement 2/3, the G flag could be 1 and is 1 by default.

I am OK with setting G flag to 1 always (as you, Richard and Phil seem to prefer) but I dont know how to reason this. Do we need to provide a reason at all?

[Pascal9]
Statement 1 does not say that at all. Can't fathom how you concluded that... Let me try to reword: There is only what DODAG for a given local instance so there cannot be a selection => G cannot be used for a selection that cannot happen.

>As per statement 2/3, the G flag could be 1 and is 1 by default.

Yes. I added an item to help the device prioritize when it is asker to participate to many DODAGs (for many P2P flows that it happens to be on the path of). In that case, and if the device cannot particpater to all the P2P DODAGs, then the G bit could be use to decide which are the most important. 

If you define a default goal that the DODAG fills, then you set G to one. For instance, G could mean 'important stuff' like swithing a light on. You'd set it for switching lights but not for reporting the hygrometry of your orchids, which anyway will be retried in a half hour. As a result, if the 2 DAG formations collide, the light on will have precedence...

[Mukul9]
How about the following text:

"The origin sets the G flag to indicate the relative importance of the route discovery it is initiating. The G flag is set to one if this particular route discovery is more important from application's perspective than some other route discovery. In other words, the origin sets the G flag to one if this particular route discovery helps meet the application defined goal \cite{rpl}. Thus, the G flag setting helps an intermediate router choose which route discoveries to participate in if it cannot participate in all route discoveries. An intermediate router SHOULD participate in route discoveries with G flag set to one (in preference to ones with G flag set to zero)."

[Pascal10]
As far as I'm concerned you've captured it and I'm happy with this text.

---

From: Richard Kelsey <[email-masked]>
Date: Wed, 11 Apr 2012 07:31:42 -0400

> Date: Tue, 10 Apr 2012 21:51:25 -0500
> From: Mukul Goyal <[email-masked]>
>
> "The origin sets the G flag to indicate the relative importance of the
> route discovery it is initiating. The G flag is set to one if this
> particular route discovery is more important from application's
> perspective than some other route discovery. In other words, the
> origin sets the G flag to one if this particular route discovery helps
> meet the application defined goal \cite{rpl}. Thus, the G flag setting
> helps an intermediate router choose which route discoveries to
> participate in if it cannot participate in all route discoveries. An
> intermediate router SHOULD participate in route discoveries with G
> flag set to one (in preference to ones with G flag set to zero)."

If you want to repurpose the G flag in this way you need to be
clear that the usage in RFC 6550 no longer applies.  I think that
the best way to do this would be to say that clause 3 of 8.2.2.2
does not apply to P2P DAGs:

  8.2.2.2. DODAG Roots

   ...
   3.  A node whose DODAG parent set is empty MAY become the DODAG root
       of a floating DODAG.  ...

Not having floating DODAGs would mean that the original use of
the G flag is no longer necessary.

                                -Richard Kelsey

---

From: JP Vasseur <[email-masked]>
Date: Wed, 11 Apr 2012 16:17:36 +0200

Thanks Mukul and the WG - Ticket closed.

JP.

---

From: Michael Richardson <[email-masked]>
Date: Thu, 12 Apr 2012 10:45:43 -0400

>>>>> "Mukul" == Mukul Goyal <[email-masked]> writes:
    Mukul> #86: G flag: do we need that text?

    Mukul> Problem ------------------------------ Disagreement on the
    Mukul> meaning of 'G' bit and imposed setting to 0;

    Mukul> Proposed resolution --------------------------- Add the
    Mukul> following text to the draft:

    Mukul> "The origin sets the G flag to indicate the relative
    Mukul> importance of the route discovery it is initiating. The G
    Mukul> flag is set to one if this particular route discovery is more
    Mukul> important from application's perspective than some other
    Mukul> route discovery. In other words, the origin sets the G flag
    Mukul> to one if this particular route discovery helps meet the
    Mukul> application defined goal \cite{rpl}. Thus, the G flag setting
    Mukul> helps an intermediate router choose which route discoveries
    Mukul> to participate in if it cannot participate in all route
    Mukul> discoveries. An intermediate router SHOULD participate in
    Mukul> route discoveries with G flag set to one (in preference to
    Mukul> ones with G flag set to zero)."

I concur.

{I can conceive of a situation where the target node creates a DODAG
with G=0, seeking the originating end, but this is outside of the scope of
what P2P describes.}

-- 
]       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, 12 Apr 2012 13:40:02 -0400

>>>>> "Richard" == Richard Kelsey <[email-masked]> writes:
    >> "The origin sets the G flag to indicate the relative importance
    >> of the route discovery it is initiating. The G flag is set to one
    >> if this particular route discovery is more important from
    >> application's perspective than some other route discovery. In
    >> other words, the origin sets the G flag to one if this particular
    >> route discovery helps meet the application defined goal
    >> \cite{rpl}. Thus, the G flag setting helps an intermediate router
    >> choose which route discoveries to participate in if it cannot
    >> participate in all route discoveries. An intermediate router
    >> SHOULD participate in route discoveries with G flag set to one
    >> (in preference to ones with G flag set to zero)."

    Richard> If you want to repurpose the G flag in this way you need to
    Richard> be clear that the usage in RFC 6550 no longer applies.  I
    Richard> think that the best way to do this would be to say that
    Richard> clause 3 of 8.2.2.2 does not apply to P2P DAGs:

I would like to understand why you feel that in the P2P case, setting
G=1 is somehow repurposing the G flag.

    Richard> Not having floating DODAGs would mean that the original use
    Richard> of the G flag is no longer necessary.

There is no use in floating DODAGs... *for the P2P case*.
I think that floating DODAGs have many uses in the P2MP case, during
DODAG construction and repair.

---

From: "Pascal Thubert (pthubert)" <[email-masked]>
Date: Fri, 13 Apr 2012 10:11:35 +0200

Hi Michael:

I tend to agree that we are somewhat repurposing G... or extending it if
that's a better word.
The clear part of G's meaning is related to floating DAGs which is a
concept that comes with global instances.
Local instances were defined and reserved in RFC 6550 for use in P2P.
RFC 6550 did not push as far as locking meaning for the G bit.
It actually makes sense that the draft that really defines a use of
local instances also defines what G does in that world.
And here we thought is that instead of comparing DODAGs within a DAG
associated to a global instance, G would now be used to compare DODAGs
that are each a DAG associated to a local instance.
The semantic shift is that now, G eventually compares the applicative
value of different apps for a user as opposed to the routing value of
various DODAGs for an application. We went up a level.
That's actually not a bad idea since P2P is getting us deeper in the
world of autonomic networks and thus into higher level abstractions.
I do not see that there is any opposition in doing it. The wish here is
that the text must indicate more clearly that we are doing this shift.
I think that Mukul will provide the additional informative sentence that
we'd like to see. 
In any case, I see no point in keeping that ticket open. Too much ML
bandwidth was used on that discussion. Unless Richard speaks up again
which I doubt, I think we really want the ticket and discussion closed.
 
Cheers,

Pascal

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of
Michael Richardson
Sent: jeudi 12 avril 2012 19:40
To: [email-masked]
Subject: Re: [Roll] Closure text for ticket #86

-- 
]       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: Mukul Goyal <[email-masked]>
Date: Mon, 16 Apr 2012 09:59:38 -0500 (CDT)

Hi all

On further thoughts, I think we should defer for the time being using G bit to indicate route discovery priority. There is no real usecase for this at the moment. We can reconsider adding this functionality when we go standards track. So, I propose modifying the resolution text to the following:

"The origin always sets the G flag to one. Unlike a global RPL instance, the concept of a floating DAG, used to provide connectivity within a sub-DAG detached from a grounded DAG, does not apply to a local RPL instance. Hence, an origin MUST always set the G flag to one when initiating a P2P-RPL route discovery. Further, a node MUST NOT initiate a new DAG (with G flag set to zero) if it does not have any parent left in a P2P-RPL DAG."

Thanks
Mukul

----- Original Message -----
From: "Mukul Goyal" <[email-masked]>
To: "JP Vasseur" <[email-masked]>
Cc: "roll" <[email-masked]>, "Michael Richardson" <[email-masked]>
Sent: Tuesday, April 10, 2012 9:51:25 PM
Subject: [Roll] Closure text for ticket #86

Problem

Proposed resolution

Discussion:
-----------------

 [Pascal]

 [Mukul]

 [Mukul2]

 What do you think?

 [Mukul4] Sounds good.

[Richard5]

[Mukul5]

[Michael5]

[Phillip5]

[Pascal6]

[Mukul6]

[Pascal7]

[Mukul7]

[Pascal8]

[Mukul8]

[Pascal9]

[Mukul9]

[Pascal10]

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

---

From: "Pascal Thubert (pthubert)" <[email-masked]>
Date: Mon, 16 Apr 2012 18:40:28 +0200

I'm fine with that...

Thanks for the hard work, Mukul;

Pascal

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of
Mukul Goyal
Sent: lundi 16 avril 2012 17:00
To: JP Vasseur
Cc: roll; Michael Richardson
Subject: Re: [Roll] Closure text for ticket #86

Hi all

On further thoughts, I think we should defer for the time being using G
bit to indicate route discovery priority. There is no real usecase for
this at the moment. We can reconsider adding this functionality when we
go standards track. So, I propose modifying the resolution text to the
following:

"The origin always sets the G flag to one. Unlike a global RPL instance,
the concept of a floating DAG, used to provide connectivity within a
sub-DAG detached from a grounded DAG, does not apply to a local RPL
instance. Hence, an origin MUST always set the G flag to one when
initiating a P2P-RPL route discovery. Further, a node MUST NOT initiate
a new DAG (with G flag set to zero) if it does not have any parent left
in a P2P-RPL DAG."

Thanks
Mukul

----- Original Message -----
From: "Mukul Goyal" <[email-masked]>
To: "JP Vasseur" <[email-masked]>
Cc: "roll" <[email-masked]>, "Michael Richardson" <[email-masked]>
Sent: Tuesday, April 10, 2012 9:51:25 PM
Subject: [Roll] Closure text for ticket #86

Problem

Proposed resolution

"The origin sets the G flag to indicate the relative importance of the
route discovery it is initiating. The G flag is set to one if this
particular route discovery is more important from application's
perspective than some other route discovery. In other words, the origin
sets the G flag to one if this particular route discovery helps meet the
application defined goal \cite{rpl}. Thus, the G flag setting helps an
intermediate router choose which route discoveries to participate in if
it cannot participate in all route discoveries. An intermediate router
SHOULD participate in route discoveries with G flag set to one (in
preference to ones with G flag set to zero)."

Discussion:
-----------------

 [Pascal]

 On the contrary I'd set it to 1. The goal -being to reach the origin-
is  actually achieved by this DAG.

 [Mukul]

 [Mukul2]

 What do you think?

 [Mukul4] Sounds good.

[Richard5]
I disagree with the proposed resolution.  It adds needless confusion.
The G flag is 0 if and only if the DODAG is floating.
There is no point to allowing floating DODAGs with a P2P-RDO option.  I
suggest that the G bit be set to 1 and that routers be explicitly
prohibited from creating floating DODAGs with a P2P-RDO option.

[Mukul5]
>The G flag is 0 if and only if the DODAG is floating.

I think that the G flag is 1 if and only if the DODAG is grounded. The
temporary DAGs used in P2P-RPL are not grounded, they are temporary. I
think that all transient/temporary DAGs are floating by their very
nature.

[Michael5]
> Does it mean that a node announcing such a thing is attached to the 
> Internet? (In which case P2P usage should G=0) Or does it mean that a 
> node is attached to the resource named in the DIO? (In which case 
> origin P2P should G=1)
> 

[Phillip5]

The common case of the Goal is "has connectivity to the Internet" but
that's not the only case. I think given the Goal for P2P traffic, I
agree with Pascal and Richard that it should be 1.

[Pascal6]
Floating vs. Grounded depends on the goal of the DODAG. I asked you and
will ask again what is your goal?
If the goal is to reach the root, then G is 1... If you want to signal
something to the OF using the G bit, leave it  open.

[Mukul6]
>If the goal is to reach the root, then G is 1...

I have told you multiple times that joining a P2P-RPL DAG does not give
any sort of connectivity to the node.

[Pascal7]
I think we disagree because of the definition of goal itself. The goal
is an abstraction. Same goes for the term Objective in OF. RFC 6550 only
gives examples of what G could be used for but that is not limiting.
Certainly the abstraction may for instance mean that external nodes are
reachable via the root. But it could be something else entirely. For
instance it could designate a root that can aggregate data.

In practice, G is used to favor a root that reaches the goal vs. one
that does not. But that's senseless for local instances that have by
definition a single root.

So whatever you set it to does not make a difference for RFC 6550
operations. I figure it could be used for signaling a "transient goal"
information to an OF that could use it for a purpose I can't fathom.

In any case, as I suggested earlier and as Richard also suggest now, G
SHOULD probably be 1 by default but MAY be set otherwise.

[Mukul7]
Richard wants the flag to always be either 0 or 1. He prefers it to be
always 1 but would settle for it being always zero.

I think this is not a critical point. I am OK with whatever resolution
you and Richard arrive at. Kindly provide me the resolution text I
should put in the draft.

[Pascal8]

1) For a local instance there can be only one root and one DODAG. G bit
cannot and is not used for DODAG selection within an instance. 
2) In a given deployment, a goal can be defined that some P2P DODAGs
achieve and others do not. The roots that achieve that goal will set the
G bit in their P2P DAGs.
3) the default goal is to create connectivity between origin and target.
So by default G should be set to 1.
4) if an intermediate router does not have enough resources to
participate to all DODAGs then it should favor DODAGs with the G bit on.

[Mukul8]
>1) For a local instance there can be only one root and one DODAG. G bit
cannot and is not used for DODAG selection within an instance. 

>2) In a given deployment, a goal can be defined that some P2P DODAGs
achieve and others do not. The roots that achieve that goal will set the
G bit in their P2P DAGs.
3) the default goal is to create connectivity between origin and target.
So by default G should be set to 1.

As per statement 1, the G flag can never be 1 for P2P-RPL DAGs because
they use local instance ids.
As per statement 2/3, the G flag could be 1 and is 1 by default.

I am OK with setting G flag to 1 always (as you, Richard and Phil seem
to prefer) but I dont know how to reason this. Do we need to provide a
reason at all?

[Pascal9]
Statement 1 does not say that at all. Can't fathom how you concluded
that... Let me try to reword: There is only what DODAG for a given local
instance so there cannot be a selection => G cannot be used for a
selection that cannot happen.

>As per statement 2/3, the G flag could be 1 and is 1 by default.

Yes. I added an item to help the device prioritize when it is asker to
participate to many DODAGs (for many P2P flows that it happens to be on
the path of). In that case, and if the device cannot particpater to all
the P2P DODAGs, then the G bit could be use to decide which are the most
important. 

If you define a default goal that the DODAG fills, then you set G to
one. For instance, G could mean 'important stuff' like swithing a light
on. You'd set it for switching lights but not for reporting the
hygrometry of your orchids, which anyway will be retried in a half hour.
As a result, if the 2 DAG formations collide, the light on will have
precedence...

[Mukul9]

"The origin sets the G flag to indicate the relative importance of the
route discovery it is initiating. The G flag is set to one if this
particular route discovery is more important from application's
perspective than some other route discovery. In other words, the origin
sets the G flag to one if this particular route discovery helps meet the
application defined goal \cite{rpl}. Thus, the G flag setting helps an
intermediate router choose which route discoveries to participate in if
it cannot participate in all route discoveries. An intermediate router
SHOULD participate in route discoveries with G flag set to one (in
preference to ones with G flag set to zero)."

[Pascal10]

---

From: JP Vasseur <[email-masked]>
Date: Sat, 21 Apr 2012 10:23:41 +0200

I sort of reached the same conclusion …
ROLL WG, let us know by April 27th if there is a disagreement.

Thanks.

JP.