Re: [Roll] Review draft-ietf-roll-trickle-mcast-03 (was: RE: I-D Action: draft-ietf-roll-trickle-mcast-03.txt)

[Abdussalam Baryun <[e-mail]>]

Hi Esko, and Jonathan,

comments in line;

On 1/31/13, Dijk, Esko <[e-mail]> wrote:
> - maybe to add that setting of parameters is out of scope (since RFC 6206
> RECOMMENDS to define such mechanisms - a reader may expect such mechanisms
> in MPL?)

Why not having a default and/or initial values of both the constants
and parameters for MPL, as protocols usually have stated within its
I-D

>
> Section 5.3
> - both parameters are defined but their syntax/name not further used in the
> protocol description. To be fixed?
> - just wondering if default values here would be appropriate?

Yes, I think so,

> Section 6.2
> - The MLP Seed Info array must contain at least one MPL Seed Info entry.
> This can be a problem for MPL Forwarders that just started up with empty
> message buffers. When the Trickle timer fires, such Forwarder may need to
> send an MPL Control Message with 'empty' information in case it has no
> messages buffered yet.

Agree, so we need to know initial MPL states, or define
>
> Section 7.1
> - Shouldn't the Local Interface Tuple contain an identifier of each
> interface? or was this left out because format of such IDs is implementation
> specific.
>   (Interface ID, AddressSet)

I agree with you if MPL is doing multicast, but when discussing with
authors they inform me that MPL only broadcast to interfaces, but by
using Trickel the multicast is done. However, I prefer that we can put
your suggestion as a second mode of  MPL multicast.
>
> Section 7.2
> - Shouldn't the Domain Address be the first component of the MPL Domain
> Tuple?
>   (Domain Address, MPLInterfaceSet)

don't think so,

> The present text already suggests of course that Domain Address is stored
> here so I'd expect it in the tuple too.

Yes, me too,

AB