Subject: [Roll] AD review of draft-ietf-roll-trickle-04

From: Adrian Farrel <[email-masked]>
Date: Sat, 09 Oct 2010 12:09:51 +0100

I have performed an AD review of your draft.

Don't panic!

I review all drafts that I am responsible for before putting them forward 
for IETF last call. The main objective is to catch nits and minor issues 
that would show up during the last call or in IESG review. The intention is 
to help polish your document and make sure
it is clean and shiny so that other reviewers will stick to the technical 
details.

Thanks you for a really well-written and clear document. Excellent work!

On reviewing it, there are a couple of small points I think it would be 
helpful to sort out to ensure complete understanding from all your readers. 
I'd like to see a quick respin of the document before I issue the IETF last 
call. As soon as I see a new revision posted, I'll set the ball in motion.

Of course, all of my issues are up for discussion.

Thanks for the work,
Adrian

---

idnits (http://tools.ietf.org/tools/idnits/) reports

  == You're using the IETF Trust Provisions' Section 6.b License Notice
     from 12 Sep 2009 rather than the newer Notice from 28 Dec 2009.
     (See http://trustee.ietf.org/license-info/)

Can you fix this, plase.

---

Good that you pulled "trickle communication rate" out for attention as a 
term. Could you also pull out "trickle transmission rate"?

---

In section 3

   The Trickle
   algorithm balances the load in such a scenario, as each node's
   Trickle transmission rate is 1/nth of the Trickle communication rate.
   Sparser networks require more transmissions per node, but utilization
   of the radio channel over space will not increase.

No issues with the facts.
But this is the first mention of radio channels. Up to this point we would 
have been quite happy thinking of fixed-line connectivity.
Can you tweak something?

---

Section 4.1

   o  The maximum interval size is described as a number of doublings of
      the minimum interval size (the base-2 log(max/min)).  For example,
      a protocol might define the maximum interval as 16.  If the
      minimum interval is 100ms, then the maximum interval is 100ms *
      65536, 6,553.6 seconds, or approximately 109 minutes.

There is a slight discrepency in terminology here, and a little tidying that 
could be done to the expression of the example.

The problem comes that you have "maximum interval sixe" as a number of 
doublings, but you are also trying to state the amount of time it implies.

Can I suggest...

   o  The maximum interval size is described as a number of doublings of
      the minimum interval size (the base-2 log(max/min)).  For example,
      a protocol might define the maximum interval size as 16.  If the
      minimum interval size is 100ms, then the amount of time specified
      by the maximum interval size of 16 is
         100ms * 2^16 = 6,553.6 seconds
      or approximately 109 minutes.

A similar terminology problem shows up in 6.2

   Note that mismatched Imin values and matching
   Imax doubling constants will lead to mismatched Imax values.

Can you go through the document and decide whether Imax is the doubling 
constant or the time period.

---

Section 4.2

   5.  If Trickle hears a transmission that is "inconsistent," the
       Trickle timer resets.  If I is greater than Imin, resetting a
       Trickle timer sets I to Imin and begins a new interval.  If I is
       equal to Imin, resetting a Trickle timer does nothing.  Trickle
       can also reset the timer in response to external "events."

If "resetting a Trickle timer does nothing", how can you justify the word 
"reset"? Doesn't a new interval always start when the timer is
reset? Or are you saying that the timer restarts, but the counter is not 
reset to zero?

---

Section 6.1

OLD
   Hence, the danger of
   mismatched k values is uneven transmission load that can deplete the
   energy of some nodes.
NEW
   Hence, the danger of
   mismatched k values is uneven transmission load that can deplete the
   energy of some nodes in a lower-power network.
END

...because there is no specific limitation to apply this to low-power 
networks..

---

Section 6.5

  having the parameter describe (k-1)

Do you mean k=-1 ?

---

Section 6.6

   Finally, a protocol SHOULD set k and Imin such that Imin is at least
   two to three as long as it takes to transmit k packets.

s/three as/three times as/

---

Section 9

I am worried about this section being so empty. I don't think the algorithm 
needs any security work, but I do think that you can give advice on the 
security implications for protocols that use the algorithm.

For example, what would be the impact of a false positive or a false 
negative? Given that impact, what precautions should a protocol that uses 
Trickle take?

For example, in Section 6 you have:

   It is RECOMMENDED that a protocol which uses Trickle include
   mechanisms to inform nodes of configuration parameters at runtime.

What would happen if these mecahnisms were attacked?

In short, can you add some RECOMMENDations about what protocols that use 
Trickle shold consider in their specifications.