Subject: Re: [Roll] OF0 draft v9: preferred metric, Stretch-of-Rank, configuring parameters, and editorial comments

From: "Pascal Thubert (pthubert)" <[email-masked]>
Date: Thu, 5 May 2011 18:07:25 +0200

Hi Phoebus:

I made editorial changes to follow your late but welcome advice, and
published a OF0-11.

Please let me know if I covered your points as expected.

Cheers,

Pascal
http://www.xtranormal.com/watch/7011357/

> -----Original Message-----
> From: Phoebus Chen [mailto:[email-masked]]
> Sent: Thursday, April 21, 2011 4:56 PM
> To: Pascal Thubert (pthubert)
> Cc: [email-masked]
> Subject: Re: OF0 draft v9: preferred metric, Stretch-of-Rank,
configuring
> parameters, and editorial comments
> 
> Pascal,
> 
> 	Thanks for your responses.  I've replied inline below, preceded
by
> PC>.
> 
> --
> Phoebus Chen
> Postdoctoral Researcher
> Automatic Control Lab, KTH (Royal Institute of Technology)
> http://www.ee.kth.se/~phoebus
> 
> 
> On 4/21/11 10:41 AM, Pascal Thubert (pthubert) wrote:
> > Hello Phoebus : )
> >
> > Where have you been? We've been missing your excellent comments.
> >
> >> 	Sorry these comments are coming so late, after last call.  I
> > hope you
> >> can at least incorporate some of them.
> >
> > [Pascal] That's beyond me. I suppose that the shepherd has to
decide.
> > Let's see:
> >
> >
> >>
> >> 	My comments below are based on my current understanding that
> >> Phil and you are no longer using hop-count as the rank increment.
> > Instead,
> >> each node will have an implementation specific way of converting a
> > node or
> >> link cost to a rank.  I'm still unclear if there is a preference
rule
> > to try to stick
> >> with using the same metrics as the metrics advertised in a received
> > DIO, if
> >> the current node has access to multiple types of metrics (energy,
LQI,
> > ETX,
> >> etc.).  That would allow the root node to specify a preferred type
of
> > metric to
> >> use in the instance.
> >>
> >>
> >> Major Points:
> >> *************
> >> 1) I'm still hoping that the format for writing Objective Function
> > specifications
> >> can be more uniform, as I mentioned in an earlier comment (point
> > number 7
> >> in
http://www.ietf.org/mail-archive/web/roll/current/msg03240.html).
> >> Comparing MRHOF and OF0, I think that the discussion on
Step-of-Rank /
> >> Stretch-of-Rank etc. can be moved to it's own subsection.
> >>
> >> I suggest the following reorganization of sections:
> >>
> >>      3.  Objective Function 0
> >>      3.1. Computing Rank-increase
> >>      3.2. Parent / Backup Successor Selection
> >>        3.2.1. Selection of the Preferred Parent
> >>        3.2.2. Selection of the backup feasible successor
> >>      3.3. Advertising Rank-increase
> >>      4.  Interface with RPL core
> >>
> > [Pascal] Looks good. That much is doc organization and I suppose I
can
> > accommodate it at this stage.
> > It would certainly be beneficial if both OF drafts have a common
> > structure.
> >
> >> If you are allowing the root to specified a preferred metric type,
> > then Section
> >> 3.3. should state how to propagate this preference.  I would have
> > assumed
> >> it's by propagating an empty DAG/Metric Container, but in (Section
> > 2.1, draft-
> >> ietf-roll-routing-metrics-19) it says "The object body carries one
or
> > more sub-
> >> objects defined later in this document"
> >> which means you cannot have empty containers.
> >
> > [Pascal] OF0 does not have metric containers at all, so they do not
need
> > to be empty. That's because OF0 is generic, for the better or the
worse.
> > Because we want all implementations to interop with OF0, regardless
of
> > the medium etc...
> >
> > So the idea is to have no constraint on what the implementation uses
to
> > derive the Rank, no container, no configuration option, just the
base
> > RPL spec.
> >
> > Rather, we normalize the resulting values so they can compare
between
> > implementations.
> 
> PC> OK.  I thought allowing the root to specify a preferred metric
would
> PC>  be nice, but I see that it's not necessary for basic operations.
> 
> >
> > Now, I understand that a configuration container could help make the
OF
> > more self-contained/autonomic.
> >
> >> Maybe the overview in Section 3 should also state explicitly that
the
> >> processing rules of a DIO must do 3.1, then 3.2, then 3.3, in that
> > order.
> >
> > [Pascal] Yes, and this is what we mean by
> >    " As it scans all the candidate neighbors, OF0 keeps the parent
that
> > is
> >     the best for the following criteria (in order):"
> > the language may not be perfect but I hardly think the reader can be
> > getting the text wrong.
> > I'm open to an editorial change if the sense is conserved.
> >
> 
> PC> I think the text you quoted above is very clear, but given its
> PC> location in the text (Section 4 of draft-ietf-roll-of0-10, or
> PC> Section 3.2.1 of the suggested new order), it applies to
> PC> parent selection. I'm saying there should be a sentence in the new
> PC> Section 3 (overview) saying that we first compute
> PC> Rank-Increase (Sec. 3.1), then select the preferred parent
> PC> (Sec. 3.2.1), then select the backup successor (Sec. 3.2.2), then
> PC> advertise Rank-Increase (Sec. 3.3).
> PC>
> PC> Maybe this is obvious, but I think it helps to state it
explicitly.
> PC> Especially since the guidelines given in
> PC> (Section 14.1, draft-ietf-roll-rpl-19) are suggestions,
> PC> rather than MUSTs:
> PC> "Most Objective Functions are expected to follow..."
> PC> And these suggestions don't say the steps must be followed in
> PC> order either.
> 
> >>
> >>
> >> 2) There have been two variables and one parameter defined in the
> >> overview section, but they are not mentioned in Section 7, OF0
> > Constants
> >> and Variables.
> >> Variables: Step-of-Rank, Stretch-of-Rank
> >> Parameters: Rank-factor
> >> (I noticed that there is no MINIMUM_RANK_STRETCH and
> >> DEFAULT_RANK_STRETCH and presume this is intentional.)
> >>
> > [Pascal] You're right. A stretch of 0 is acceptable so there is no
> > MINIMUM.
> >   If there was a DEFAULT I expect it should be zero as well. By
> > compliance with the main spec.
> > I'm fine adding it. What do you think?
> >
> 
> PC> That would be nice for clarity. I think most implementors will
> PC> use default values in a spec without a second thought unless they
> PC> have a strong reason to do otherwise.
> 
> >> Also, it would be nice to use underscore instead of hyphen for
> >> variables, like in MRHOF (and use capital letters for parameters).
> >>
> > [Pascal] OK. I did not really mean those as variables, but why not.
> >
> >> Finally, how is Stretch-of-Rank computed?  Implementation
dependent?
> >
> > [Pascal] It is not computed. It is configured and can be left to 0.
Does
> > not have to be there at all in an implementation.
> > I can clarify that.
> >
> 
> PC> OK.
> 
> >> 3) How does one configure the parameter(s) (Rank-Factor) from the
> > root?
> >>    (I just realized that this same comment applies to the
parameters in
> >> MRHOF as well).   Or is that not configurable from the root, but
must
> > be
> >> configured before deployment of the nodes?
> >
> > [Pascal] The Rank factor has to be a per node policy, like the
> > Stretch-of-Rank. Right now, we do not have config containers to
> > distribute it.
> >
> >
> >>
> >> 4) I think it would be nice to adopt the format of
> >> draft-ietf-roll-rpl-19 and draft-ietf-roll-minrank-hysteresis-of
for
> > the
> >> Terminology section.  That is, write the word, then the definition
> > (this
> >> is not done for "feasible successor" in this section).  Some other
> > words
> >> to define in this section are "Rank-increase," "RPL core," and
"higher
> >> order interface."  Unless the last one is common IPv6 terminology
that
> > I
> >> am unaware of... I was unable to tell if that meant the higher
order
> >> bits of the interface are higher, or if the interface is somehow
> > preferred.
> >
> > I think that the RPL terminology is the place for having those in
> > common.
> 
> PC> Do you mean you or JP will add those terms and definitions to
> PC> (draft-ietf-roll-terminology-05) or
> PC> (Section 2, draft-ietf-roll-rpl-19)? I think the definition of
> PC> "Rank-increase" belongs in OF0.
> 
> >
> >>
> >> 5) Just a reminder that the discussion on Rank-increase in the
> >> introduction section
> >> "OF0 uses a unit of Rank-increase of 0x100 so that Rank value can
be
> >> stored in one octet."
> >> needs to be aligned with text in Section 3,
> >> "Ri = Rf*Sp + Sr"
> >> so that they are consistent.  I see you are discussing this with
> > Omprakash.
> >
> > Sp and Sr are expressed as units of 0x100 and Rf is integer, so they
are
> > consistent. Do I miss something?
> >
> 
> PC> I see.  I didn't realize that step_of_rank had to be a multiple of
> PC> 0x100.  You only mention at the bottom of page 3 that "The exact
> PC> method for computing the Step-of-Rank is implementation-dependent"
> PC> and give bounds MINIMUM_STEP_OF_RANK and
> MAXIMUM_STEP_OF_RANK
> PC> that are multiples of MinHopRankIncrease.
> PC>
> PC> On a related note, there's a recent discussion of using the ETX
> PC> directly (identity) as the rank, which doesn't match this
> PC> requirement that step_of_rank be a multiple of 0x100 in OF0.  In
> PC> (Section 4.3.1, draft-ietf-roll-routing-metrics-19) ETX is a
> PC> multiple of 128, not 256 (0x100).
> PC>
> PC> Is it actually necessary to mention "rank-increase" in the
> PC> introduction, before the terminology section?  Can we remove
>     "The Rank
>     of a node is obtained by adding a normalized scalar Rank-increase
to
>     the Rank of a selected preferred parent.  OF0 uses a unit of Rank-
>     increase of 0x100 so that Rank value can be stored in one octet.
>     This allows up to at least 28 hops even when default settings are
>     used and each hop has the worst Rank-increase of 9."
> PC> Or move it some point later?  It may be a bit confusing to bring
up
> PC> so much detail at this point in the text.
> 
> >>
> >> 6) I like the "Abstract Interface with RPL core" section, but would
it
> >> be better to separate them into "Input" and "Output"?  That would
end
> > up
> >> splitting up "Providing DAG information" and "Providing a Parent
List"
> >> into two pieces though.
> >>
> >>
> >> More minor editorial comments to follow below, preceded by PC>.
> >
> > Thanks for those. I'll include them in a rev.
> >
> >>
> >> --
> >> Phoebus Chen
> >> Postdoctoral Researcher
> >> Automatic Control Lab, KTH (Royal Institute of Technology)
> >> http://www.ee.kth.se/~phoebus
> >>
> >>

---

From: Phoebus Chen <[email-masked]>
Date: Tue, 10 May 2011 15:12:27 +0200

Pascal,

	You covered most of the points.

I.
Regarding the point I made below (reformatted for easy reading):

...
PC> Maybe the overview in Section 3 should also state explicitly that 
PC> the processing rules of a DIO must do 3.1, then 3.2, then 3.3, in
PC> that order.

PT> Yes, and this is what we mean by
PT> " As it scans all the candidate neighbors, OF0 keeps the parent
PT> that is the best for the following criteria (in order):"
PT> the language may not be perfect but I hardly think the reader can be
PT> getting the text wrong.
PT> I'm open to an editorial change if the sense is conserved.

 > PC> advertise Rank-Increase (Sec. 3.3).
...

I think you made edits with regard to your initial interpretation of my 
comment.  I did NOT want you change the sentence in Section 4.2.1, and 
actually, I liked the original wording of "As it scans ..." in 
draft-ietf-roll-of0-10 better.  I was suggesting a sentence in what is 
now Section 4, before Section 4.1, stating the steps in the subsections 
MUST be executed in that order.

It looks like there is nothing written about advertising the rank (a 
Section 4.3).  I guess that's OK if you feel there is nothing to say.  I 
would have preferred a short paragraph there for completeness.  It might 
just restate the obvious, that advertisements are triggered by the 
Trickle timer or changes in the rank after it is recomputed.

II.
 >> PC>  so much detail at this point in the text.

I think JP's comments about pointing out where many of the variables are 
defined can be handled by not going into so much detail in the 
introduction, and stating the details later.

III.
I presume you will still add Configuration Options for the configurable 
parameters in 6.2?

IV.
As for any remaining comments I have after rereading the document, they 
are about how to present and explain OF0.  Since I get the sense that 
there is some urgency to publish OF0, you can incorporate them if you 
have time - these comments shouldn't "hold the document hostage."  A few 
points in addition to JP's comments:

0) I've had trouble understanding the consensus of the discussion on the 
mailing list on OF0 not being the default objective function.  The last 
paragraph of Section 1 still doesn't make it clear to me.  As far as I 
understand, OF0 is the default objective function when no objective 
function is specified - if an implementation does not  support another 
objective function, it must support OF0.  This is the definition of 
"default," right?  If not, someone please define "default" to me... I 
must be missing something.  I would be glad to propose shorter text if I 
understood the consensus.

"  Since there is no default OF or metric container in the RPL main
    specification, it might happen that, unless two given implementations
    follow the same guidance for a specific problem or environment, those
    implementations will not support a common OF with which they could
    interoperate.  OF0 is designed to be common to all implementations
    that are not specifically designed to apply to a given case for which
    further guidance is provided.  This is why it is very abstract as to
    how the link properties are transformed into a rank_increase and
    leaves that responsibility to implementation; rather, OF0 enforces
    normalized values for the rank_increase of a normal link and its
    acceptable range, as opposed to formulating the details of its
    computation.  This is also why OF0 ignores metric containers.
"

1) You might consider adding a clarification to Section 4 is how the 
objective function is "triggered," when it enters the process of 
computing the rank, checking whether to change parents and successors, 
and readvertising the rank.  I believe there are at least 2 entry points:
	1) DIO processing
	2) change in "step_of_rank", which is implementation dependent and may 
come from layer 2.

The latter should be mentioned explicitly... it's only mentioned at the 
end of Section 3 in the last sentence.

I'm not sure if the objective function code is triggered by other timer 
expirations, like when information becomes stale.  Anyhow, it's your 
call if this is too much detail and should be left to the implementers 
to figure out on their own.

2)  I think that the paragraph at the end of Section 3:
"  OF0 assigns a step_of_rank to each link to another node that it
    monitors.  The exact method for computing the step_of_rank is
    implementation-dependent.  "
belongs somewhere in Section 4.1, maybe after the sentence:
"An implementation MUST maintain the stretched step_of_rank between
MINIMUM_STEP_OF_RANK and MAXIMUM_STEP_OF_RANK, which allows to
reflect a large variation of link quality."

3) Search and replace all "rank-increase" with "rank_increase" for 
consistency.  Search and replace "Rank-factor" with "rank_factor."

Is there a convention of writing names for distinguishing variables from 
configurable parameters?  I'm assuming that "lowercase with underscores" 
(e.g., rank_factor) can be used interchangeably with "a mix of capital 
letters and lowercase letters with no underscores" (e.g., 
MinHopRankIncrease).  Do we care to distinguish the two, say using "a 
mix of capital letters and lowercase letters with no underscores" for 
parameters and "lowercase with underscores" for variables?

4) Typo, extra word "as":
    "One trivial OF0 implementation might compute the step_of_rank from 
as a classical administrative..."

5) Rewrite the equation:
R(N) = R(P) + Ri where Ri = (Rf*Sp + Sr) * MinHopRankIncrease
as

R(N) = R(P) + rank_increase
where
rank_increase = (rank_factor * step_of_rank + stretch_of_rank) *
                 MinHopRankIncrease

So we have less new variables (Ri, Rf, Sp, Sr).

6) Defining the terms "higher order interface" and "RPL Core" in the 
ROLL terminology document.

---

From: "Pascal Thubert (pthubert)" <[email-masked]>
Date: Tue, 17 May 2011 17:41:46 +0200

Hi Phoebus:
 
[Pascal] I posted a 12 to resync with you. I try to address the below as

> draft-ietf-roll-of0-10 better.  I was suggesting a sentence in what is
now
> Section 4, before Section 4.1, stating the steps in the subsections
MUST be
> executed in that order.

[Pascal] I'll restore then. I did prefer the original too.

> It looks like there is nothing written about advertising the rank (a
Section
> 4.3).  I guess that's OK if you feel there is nothing to say.  I would
have
> preferred a short paragraph there for completeness.  It might just
restate
> the obvious, that advertisements are triggered by the Trickle timer or
> changes in the rank after it is recomputed.

[Pascal] There's text in the end of the ' Abstract Interface with RPL
core' section that I thought would cover this.

>  >> PC>  On a related note, there's a recent discussion of using the
ETX  >>
> PC>  directly (identity) as the rank, which doesn't match this  >> PC>
> requirement that step_of_rank be a multiple of 0x100 in OF0.  In  >>
PC>
> (Section 4.3.1, draft-ietf-roll-routing-metrics-19) ETX is a  >> PC>
multiple of
> 128, not 256 (0x100).
> introduction, before the terminology section?  Can we remove
>  >>      "The Rank
>  >> PC>  Or move it some point later?  It may be a bit confusing to
bring  > up
> defined can be handled by not going into so much detail in the
introduction,
> and stating the details later.

[Pascal] Agreed

> I presume you will still add Configuration Options for the
configurable

[Pascal] That would be beyond what I can do after last call. I'm only
fixing editorials now.

> understood the consensus.

[Pascal] 
I think that those words for that belong to RPL. 
We negotiated them with the IESG reviewers who raised the issue.
I'm not sure we all have the same understanding of those words though.
My understanding was that the AD wished that 2 implementations would
always have at least one OF in common.
If those implementations follow a given guidance that's outside RPL,
fine. Otherwise they have to implement OF0.
I suspect that some conformance test will verify that. 
>     computation.  This is also why OF0 ignores metric containers.
[Pascal] What do you think of:

"   Since there is no default OF or metric container in the RPL main
   specification, it might happen that, unless two given implementations
   follow the same guidance for a specific problem or environment, those
   implementations will not support a common OF with which they could
   interoperate.  OF0 is designed as a default OF that will allow
   interoperation between implementations in a wide spectrum of use
   cases.  This is why it is not specific as to how the link properties
   are transformed into a rank_increase and leaves that responsibility
   to the implementation; rather, OF0 enforces normalized values for the
   rank_increase of a normal link and its acceptable range, as opposed
   to formulating the details of its computation.  This is also why OF0
   ignores metric containers."
> 	2) change in "step_of_rank", which is implementation dependent
[Pascal] What about:
"

5.  Abstract Interface with RPL core

   Objective Function 0 interacts with the RPL core in the following
   ways:

   Processing DIO:  When a new DIO is received, the RPL core calls the
      OF that corresponds to the Objective Code Point OCP) in the DIO .
      OF0 corresponds to the OCP 0 (to be validated by IANA).

   Providing DAG information:  The OF0 support provides an interface
      that returns information about a given instance.  This includes
      material from the DIO base header, the role (router, leaf), and
      the Rank of this node.

   Providing a Parent List:  The OF0 support provide an interface that
      returns the ordered list of the parents and feasible successors
      for a given instance to the RPL core.  This includes the material
      that is contained in the transit option for each entry.

   Calling back:  The RPL core provides a call back interface for the
      OF0 support to inform it that a change in DAG information or
      Parent List as occurred.  This can be caused by an interaction
      with another system component such as configuration, timers, and
      device drivers, and the change may cause the RPL core to fire a
      new DIO or reset trickle timers.
"
> reflect a large variation of link quality."
[Pascal] I do not follow you on that. This section has been talking
about rank increase and now it points at the place where it is defined
(following JP's suggestion)
"
   OF0 assigns a rank_increase to each link to another node that it
   monitors.  Though the exact method for computing the rank_increase is
   implementation-dependent, the computation must follow the rules that
   are specified in Section 4.1.

"

> consistency.  Search and replace "Rank-factor" with "rank_factor."
[Pascal] OK

> parameters and "lowercase with underscores" for variables?
[Pascal] Not that I know of. I made separate subsections to
differentiate them.

> as a classical administrative..."
[Pascal] Thanks

> So we have less new variables (Ri, Rf, Sp, Sr).
[Pascal] OK...

> ROLL terminology document.

[Pascal] I'll pass that that to JP.

---

From: Phoebus Chen <[email-masked]>
Date: Wed, 18 May 2011 22:51:32 +0200

Pascal,

	Your changes look good enough.  I have some minor comments, but maybe 
you're tired of respinning the document.  Anyhow, answers to some of 
your questions inline below.

On 5/17/11 5:41 PM, Pascal Thubert (pthubert) wrote:
...

> core' section that I thought would cover this.

PC> OK.  I guess the recommendations in the "Abstract Interface with RPL
PC> core" together with "Section 8.3 DIO Transmissions" in
PC> (draft-ietf-roll-rpl-19) will be good enough.

...

PC> OK.

>     ignores metric containers."

PC> The reader will have to figure out what is meant by "guidance," but
PC> again, OK, good enough.

...

PC> OK.

...
>> So we have less new variables (Ri, Rf, Sp, Sr).

PC> ??  I don't see the changes in version 12.  You will add them in 13, 
I presume.

PC>
And three more typos (look at Diff2 between 11 and 12 to spot them):

(pg. 3, around line 28) ...OF0 only requires the information in the RPL 
DIO obtained from provisionning ...
s/provisionning/provisioning/

(pg. 7 around line 57) text in "Processing DIO:"
s/Objective Code Point OCP)/Objective Code Point (OCP)/

(pg. 7) text in "Calling back:"
s/Parent List as occurred/Parent List has occurred/

---

From: "Pascal Thubert (pthubert)" <[email-masked]>
Date: Thu, 19 May 2011 14:37:26 +0200

Hello Phoebus,

> PC> ??  I don't see the changes in version 12.  You will add them in
13,

[Pascal] I did half of the way actually; 

  The step_of_rank Sp that is computed for that link is multiplied by
   the rank_factor Rf and then possibly stretched by a stretch_of_rank
   Sr. The resulting rank_increase is added to the Rank of preferred
   parent R(P) to obtain that of this node R(N):

   R(N) = R(P) + rank_increase where:

   rank_increase = (Rf*Sp + Sr) * MinHopRankIncrease [Pascal] 

The full version was harder to read IMHO.

> s/Parent List as occurred/Parent List has occurred/

[Pascal] Sorry for those. We can still fix that with the RCF editor.

Pascal

---

From: C Chauvenet <[email-masked]>
Date: Thu, 19 May 2011 10:01:00 -0700

Hi all, 

About the step_of_rank computation : 

I understand it means but I fail to see how to compute it.

There is a reference to the MRHOF draft in the beginning of section 4.1 of OF0.
Does it means that we should refer to that draft to compute it ?
or it is voluntary not to define it and let to the implementation ?

I'm wondering about interoperability issues between different implementations using OF0.

Best, 

Cédric.

-----Message d'origine-----
De : [email-masked] [mailto:[email-masked]] De la part de Pascal Thubert (pthubert)
Envoyé : jeudi 19 mai 2011 14:37
À : [email-masked]; [email-masked]
Objet : Re: [Roll] OF0 draft v9: preferred metric, Stretch-of-Rank, configuring parameters, and editorial comments

Hello Phoebus,

> >> 5) Rewrite the equation:
> >> R(N) = R(P) + Ri where Ri = (Rf*Sp + Sr) * MinHopRankIncrease as
> >>

Pascal

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

---

From: "Pascal Thubert (pthubert)" <[email-masked]>
Date: Fri, 20 May 2011 08:50:21 +0200

Hi Cedric:

The spec explicitly DOES NOT tell you how to compute step_of_rank. You get to implement what you prefer. What allows interop is that the whatever qualifies has best has a step of 1, worst acceptable a step of 9, and the normal expected a step of 3. So you compare normal with normal but you do not know how a different implementation computes normal.

The rationale behind this is that OF0 must be applicable regardless of the Link layer. So we cannot be any specific in that regard.

Cheers,

Pascal

> From: C Chauvenet [mailto:[email-masked]]
> Sent: Thursday, May 19, 2011 7:01 PM
> To: Pascal Thubert (pthubert); [email-masked]
> Cc: [email-masked]
> Subject: RE: [Roll] OF0 draft v9: preferred metric, Stretch-of-Rank,configuring
> De : [email-masked] [mailto:[email-masked]] De la part de Pascal
> Thubert (pthubert) Envoyé : jeudi 19 mai 2011 14:37 À : [email-masked];
> [email-masked] Objet : Re: [Roll] OF0 draft v9: preferred metric, Stretch-of-
> Rank, configuring parameters, and editorial comments
> 
> Hello Phoebus,
> 
> 
> > >> 5) Rewrite the equation:

---

From: C Chauvenet <[email-masked]>
Date: Fri, 20 May 2011 00:16:10 -0700

Hi Pascal, 

Thank you for this explanation, 
It is now very clear.

Cédric.

-----Message d'origine-----
De : Pascal Thubert (pthubert) [mailto:[email-masked]] 
Envoyé : vendredi 20 mai 2011 08:50
À : C Chauvenet; [email-masked]
Cc : [email-masked]
Objet : RE: [Roll] OF0 draft v9: preferred metric, Stretch-of-Rank,configuring parameters, and editorial comments

Hi Cedric:

Cheers,

Pascal

> Subject: RE: [Roll] OF0 draft v9: preferred metric, 
> Stretch-of-Rank,configuring parameters, and editorial comments
> 
> Hi all,
> 
> De : [email-masked] [mailto:[email-masked]] De la part 
> de Pascal Thubert (pthubert) Envoyé : jeudi 19 mai 2011 14:37 À : 
> [email-masked]; [email-masked] Objet : Re: [Roll] OF0 draft v9: 
> preferred metric, Stretch-of- Rank, configuring parameters, and 
> editorial comments
> 
> Hello Phoebus,
> 
> 
> > >> 5) Rewrite the equation: