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

["Dijk, Esko" <[e-mail]>]

Hello,

> 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
That's possible, if we have some 'typical' use case for which reasonable Trickle parameters are known.
On second thought: in practice the SEED_SET_LIFETIME selection may be linked to the Imin/Imax selection. So giving a default for only SEED_SET_LIFETIME may not work. E.g. SEED_SET_LIFETIME = 100 ms, and Imin=5 sec., would not really work well I assume.

regards,
Esko

-----Original Message-----
From: Abdussalam Baryun [mailto:[e-mail]]
Sent: Thursday 31 January 2013 17:32
To: Dijk, Esko
Cc: Jonathan Hui (johui); [e-mail] WG
Subject: Re: [Roll] Review draft-ietf-roll-trickle-mcast-03 (was: RE: I-D Action: draft-ietf-roll-trickle-mcast-03.txt)

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

________________________________
The information contained in this message may be confidential and legally protected under applicable law. The message is intended solely for the addressee(s). If you are not the intended recipient, you are hereby notified that any use, forwarding, dissemination, or reproduction of this message is strictly prohibited and may be unlawful. If you are not the intended recipient, please contact the sender by return e-mail and destroy all copies of the original message.