Subject: [Roll] summary of tickets on trickle-mcast

From: Michael Richardson <[email-masked]>
Date: Tue, 22 Jan 2013 16:17:46 -0500

http://trac.tools.ietf.org/wg/roll/trac/report/8
contains the list of open tickets.  There are some threads
linked in each ticket.

http://trac.tools.ietf.org/wg/roll/trac/ticket/103
  trickle-mcast: suppress ICMP messages for PROACTIVE_TIMER_EXPIRATIONS
  http://www.ietf.org/mail-archive/web/roll/current/msg07424.html

  This ticket has had no significant discussion.  Is there an issue
  here?

http://trac.tools.ietf.org/wg/roll/trac/ticket/104
  security considerations.
  We need to have a discussion about what are the implications 
  of this protocol.  See next message.

http://trac.tools.ietf.org/wg/roll/trac/ticket/105
trickle-mcast: how to determine scope of MPL domain
  We have several options from Robert Craigie in the ticket system.
  Alternatives 3 and 4 were discussed, and I think that we preferred
  option 4 with the multicast option always present.
  Please post if you disagree.

http://trac.tools.ietf.org/wg/roll/trac/ticket/106
trickle-mcast: always use 6in6 encapsulation for non-link-local multicast
  no clear resolution, but ticket #105 suggests answer.

http://trac.tools.ietf.org/wg/roll/trac/ticket/108
trickle-mcast: should there be an explicit version field?
  suggested answer was YES.

http://trac.tools.ietf.org/wg/roll/trac/ticket/107
trickle-mcast: should multiple parameter sets be supported
  my conclusion: There is has been little discussion about this
     issue. My inclination is to not include multiple sets at this
     time. 

http://trac.tools.ietf.org/wg/roll/trac/ticket/109
trickle-mcast: should all MPL packets be destined to all-MPL-forwarders

-- 
Michael Richardson <[email-masked]>, Sandelman Software Works 
IETF ROLL WG co-chair.    http://datatracker.ietf.org/wg/roll/charter/

---

From: Michael Richardson <[email-masked]>
Date: Tue, 22 Jan 2013 16:20:18 -0500

missed one. 
I think that the question is out of scope.

http://trac.tools.ietf.org/wg/roll/trac/ticket/110
trickle-mcast: do applications receive all multicast, or just MPL
	       encapsulated ones 

 There's still the case that multicasts from non-MPL nodes are received
 by MPL-forwarder-nodes (presumably). Should there be guidelines here?
 Example: if an application on my MPL-forwarder node joins multicast
 group FF05::1234, will the application then receive IP multicasts sent
 with destination FF05::1234, or will it only receive those IP multicasts
 to FF05::1234 that were delivered encapsulated in an FF0X::MPL packet ?
 That decision could be out of scope; but on the other hand may lead to
 different implementers making different choices here.

---

From: Abdussalam Baryun <[email-masked]>
Date: Wed, 23 Jan 2013 16:55:00 +0100

Hi Michael, and authors of the I-D

In your message you mention *we need to have discussion* but I think
we need something else. IMO, *We need replies from the authors*

The document after its last issue got many comments and tickets but
never updated even once, does it mean the authors didn't think that
people have difficulty in reading or understanding?

IMHO, please update considering why the comments, so you encourage
discussions and people to read again, including me :)

AB