Subject: [Roll] [roll] #127: Editorial Comments for draft-ietf-roll-trickle-mcast-04

From: "roll issue tracker" <[email-masked]>
Date: Tue, 21 May 2013 00:01:34 -0000

#127: Editorial Comments for draft-ietf-roll-trickle-mcast-04

 From: peter van der Stok <[email-masked]>

 I have a few editing remarks for mpl-4 document:

   end of page 8, end of Reactive forwarding paragraph. I suggest to
 replace <..... using the Trickle algorithm> by
 <.....using proactive forwarding>.

 page 11, default value of DATA_MESSAGE_IMIN "10 times the worst-case
 link-layer latency"
 given the medium sensing and back-off in the MAC, the worst case
 link-layer latency becomes easily 100 ms, giving a default value of 1
 second or more.
 May be you mean the transmission time which has a value of 3 ms ?

 page 11, default value of DATA_MESSAGE_K has value of 5, before the
 value of 1 was encouraged. Personally for me, the value 1 seems adquate.

 page 15 MPL Seed Info [0..n], page 14 MPL Seed Info [1..n], Given the
 other text with bit i=0 meaning the message with seq nr min-seqno, I
 would suggest MPL Seed Info [0..n-1]

-- 
---------------------------------------+-----------------------------
 Reporter:  [email-masked]  |      Owner:  [email-masked]
     Type:  defect                     |     Status:  new
 Priority:  minor                      |  Milestone:
Component:  applicability-ami          |    Version:
 Severity:  In WG Last Call            |   Keywords:
---------------------------------------+-----------------------------

Ticket URL: <https://svn.tools.ietf.org/wg/roll/trac/ticket/127>
roll <http://tools.ietf.org/wg/roll/>

---

From: "roll issue tracker" <[email-masked]>
Date: Tue, 21 May 2013 00:07:33 -0000

Changes (by [email-masked]):

 * component:  applicability-ami => trickle-mcast

-- 
---------------------------------------+------------------------------
 Reporter:  [email-masked]  |       Owner:  [email-masked]
     Type:  defect                     |      Status:  new
 Priority:  minor                      |   Milestone:
Component:  trickle-mcast              |     Version:
 Severity:  In WG Last Call            |  Resolution:
 Keywords:                             |
---------------------------------------+------------------------------

Ticket URL: <https://svn.tools.ietf.org/wg/roll/trac/ticket/127#comment:1>
roll <http://tools.ietf.org/wg/roll/>

---

From: "roll issue tracker" <[email-masked]>
Date: Tue, 21 May 2013 01:27:56 -0000

Comment (by [email-masked]):

 From Kerry Lynn

 Lastly, to improve the clarity of section 11.2, the first bullet should
 read:

    o  This document defines a "consistent" transmission as receiving an
       MPL Control Message that results in a determination that neither the
       receiving nor transmitting node has any new MPL Data Messages to
 offer.

 (The transmission indicates nothing about state at the receiver.)
 Similarly,
 the second bullet should read:

    o  This document defines an "inconsistent" transmission as receiving
       an MPL Control Message that results in a determination that either
 the
       receiving or transmitting node has at least one new MPL Data Message
       to offer.

 It might be helpful to add a penultimate sentence to section 11.2:

       The Trickle timer is reset in response to external "events".

 Thread: http://www.ietf.org/mail-archive/web/roll/current/msg07845.html

 From Ralph Droms

 Section 8 seems somewhat out of place, as well as redundant with the
 definition of "MPL Domain" in section 2 and the contents of section 5.1.

 In section 10.1, "the MPL Domain Address" is a little confusing.  Does a
 device belong to just a single MPL Domain, in which case it might be
 clearer to write "the MPL Domain Address to which the source interface
 belongs".  Otherwise - and I don't think I see any text in the document
 that explicitly constrains an interface to belonging to one MPL domain -
 the text should read "an MPL Domain Address to which the source interface
 belongs".

 Thread: http://www.ietf.org/mail-archive/web/roll/current/msg07863.html

Ticket URL: <http://trac.tools.ietf.org/wg/roll/trac/ticket/127#comment:2>
roll <http://tools.ietf.org/wg/roll/>

---

From: "roll issue tracker" <[email-masked]>
Date: Wed, 22 May 2013 18:54:06 -0000

From Adrian Farrel

 The first paragraph of Section 1 would benefit from some citations for
 "traditional IPv6 multicast routing and forwarding."

Ticket URL: <https://svn.tools.ietf.org/wg/roll/trac/ticket/127#comment:3>
roll <http://tools.ietf.org/wg/roll/>