Re: [Roll] WG Last Call draft-ietf-roll-trickle-mcast-04

I agree with the below message proposal, and to add that I think this
I-D should define the trickle parameters not leaving them for open
test. I think IMAX should not equal IMIN [1] for this protocol, but
mostly tests will proof best. IMO, the use of trickle parameter to
make change in MPL forwarding is better than enabling transit node to
change option content [2], Could transit nodes change trickle
parameter value when that chg bit is 1, but not change option content?

[I-D>Abstract] Different Trickle parameter configurations allow MPL to
trade between dissemination latency and transmission efficiency.
[AB] The I-D does not show parameter values/relations/equations, how
can I test their consistency with the protocol?

[1] http://www.ietf.org/mail-archive/web/roll/current/msg07887.html
[2] http://www.ietf.org/mail-archive/web/roll/current/msg07880.html

Just thoughts, if not reasonable please ignore.

Regards
AB

If you think didn't understand the protocol - I already know that, you
don't need to remind me :-)

On 4/1/13, Ralph Droms <rdroms.ietf@gmail.com> wrote:
> I apologize for the late feedback...
>
> 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.
>
> Multicast scope 0x03 has never been formally defined as "subnet-local".
> Delete the references to "subnet-local" in sections 5.1 and 8, leaving just
> "scope value of 3".  Note that scope value 3 is currently defined as
> "reserved" in RFC 4291.  I am working on publication of an RFC that will
> re-define scope value 3 as "(unassigned)" so it can be used as specified in
> draft-ietf-roll-trickle-mcast-04.
>
> 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".
>
> - Ralph
>
> _______________________________________________
> Roll mailing list
> Roll@ietf.org

On 4/1/13, Ralph Droms <rdroms.ietf@gmail.com> wrote:
> I apologize for the late feedback...
>
> 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.
>
> Multicast scope 0x03 has never been formally defined as "subnet-local".
> Delete the references to "subnet-local" in sections 5.1 and 8, leaving just
> "scope value of 3".  Note that scope value 3 is currently defined as
> "reserved" in RFC 4291.  I am working on publication of an RFC that will
> re-define scope value 3 as "(unassigned)" so it can be used as specified in
> draft-ietf-roll-trickle-mcast-04.
>
> 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".
>
> - Ralph
>
> _______________________________________________
> Roll mailing list
> Roll@ietf.org
> https://www.ietf.org/mailman/listinfo/roll
>