Re: [Roll] WGLC - Working Group Last Call - draft-ietf-roll-trickle-mcast-05

On Wed, Sep 4, 2013 at 3:45 PM, Michael Richardson <mcr+ietf@sandelman.ca>wrote:

>
> A number of issues were raised this past spring by IESG and other reviewers
> on draft-ietf-roll-trickle-mcast.  You can review them using the custom
> query:
>
>
> http://trac.tools.ietf.org/wg/roll/trac/query?status=assigned&status=closed&status=new&status=reopened&component=trickle-mcast&group=component&col=id&col=summary&col=component&col=status&col=type&col=priority&col=milestone&order=priority
>
> The chairs, Document Shephard and Document Authors believe that current
> issues are closed in the -05 revision at:
>        https://datatracker.ietf.org/doc/draft-ietf-roll-trickle-mcast/
> A diff is available at:
>
> https://www.ietf.org/rfcdiff?url1=draft-ietf-roll-trickle-mcast-04&difftype=--html&submit=Go%21&url2=draft-ietf-roll-trickle-mcast-05
>
> We are starting another WG Last Call.
> It will run until Friday 2013-09-13 at 9am EST.
>
> Please read the document.  Do you concur that it is done?
> Please post any and all comments.
>

The draft is looking good, but I have a few comments.

Editorial:

- In section 4.3, on Proactive Forwarding, the phrase "MPL Data Message
message"
  is redundant and should be "MPL Data Message".

- In the last paragraph of section 4.3 the phrase "a new MPL Data messages"
  should be "a new MPL Data Message".

- [I-D.droms-6man-multicast-scopes] should be moved from section 14.1 to
14.2.

Technical:

- I have argued that to increase MPL's applicability, PROACTIVE_FORWARDING
  should be a per-interface and not a per-forwarder setting.  I can
imagine, for
  example, a router that has both LLN and traditional interfaces and
proactive
  forwarding seems unnecessary for the latter.  As [RFC 4007] states: "Zone
  boundaries cut through nodes, not links."  Suggested wording in section
5.4
  could be "PROACTIVE_FORWARDING has a default value of TRUE on links
  where Realm-Local scope is defined, and FALSE otherwise."

- Section 4.1 states: "When used with MPL, Realm-Local scope is
administratively
  defined and used to define the boundaries of multicast message
dissemination
  by MPL."  This begs the question, why don't we just use scope = 0x04?  We
  probably need more discussion on if and how a scope 0x03 zone boundary
  is automatically defined (i.e. without human intervention) and how
forwarding
  works for scope 0x03.  One suggested definition is that Realm-Local
applies
  to links where a single interface may belong to multiple Link-Local
scopes.

- The DATA_MESSAGE_IMIN and CONTROL_MESSAGE_IMIN parameters
  described in section 5.5 will ultimately have to be expressed in units of
time
  (either in this document or elsewhere) for a given link-layer in order to
avoid
  the "Mismatched min" issues discussed in [RFC 6206, sect. 6.2].  The same
  reference states: "a protocol SHOULD set k and Imin such that Imin is at
least
  two to three times as long as it takes to transmit k packets."

Regards, -K-

> If there is something you do not like, please provide a suggestion (a diff)
> about what to fix.
>
> Thank you.
>
> Michael and JP.
>
> --
> Michael Richardson <mcr+IETF@sandelman.ca>, Sandelman Software Works
> IETF ROLL WG co-chair.    http://datatracker.ietf.org/wg/roll/charter/
>
>
> _______________________________________________
> Roll mailing list
> Roll@ietf.org
> https://www.ietf.org/mailman/listinfo/roll
>
>