Re: [Roll] I-D Action: draft-ietf-roll-rpl-observations-06.txt

["Pascal Thubert (pthubert)" <[e-mail]>]

Hello Phil:


Both cases were discussed at the mike during IETF several iterations ago.

Seemed to me that the issues reported in the document were misreading of the spec, but since people could read it like that I suggested to add some of the text you see below. Personally I do not see an ambiguity, and I agree with your comments below. 

It all falls in the better safe than sorry category. Probably it shouldn't be uppercase text since it is clarifying another spec not defining anything new.

Keep safe;

Pascal


> -----Original Message-----
> From: Roll <[e-mail]> On Behalf Of Philip Levis
> Sent: lundi 14 juin 2021 21:23
> To: [e-mail]
> Subject: Re: [Roll] I-D Action: draft-ietf-roll-rpl-observations-06.txt
> 
> I was looking at this draft and wanted to clarify a little of the text, in
> Section 5:
> 
>    "In context to multicast DIS/DIO operation, this implies that if the
>    DIO trickle timer is already at Imin and if the node hears a
>    multicast DIS, then the timer does nothing.  It MUST NOT reset the
>    timer again in this case.”
> 
> The first paragraph at first seemed redundant with the Trickle specification:
> if it is already at Imin, it does nothing, which means it does not reset the
> timer. Or is the ambiguity about resetting the timer? If so, then I think
> this refinement is correct. External events should be able to be considered
> inconsistencies, not hard-reset the timer. In retrospect, the sentence
> 
>   Trickle can also reset its timer in response to external “events"
> 
> Perhaps could have been
> 
>   External events can also cause Trickle to act as if it has detected an
> inconsistency.
> 
> So I think this paragraph makes sense, but the way to characterize it is that
> a multicast DIS resets the timer only if I > Imin.
> 
> The next paragraph I’m a little more confused about:
> 
>    "An implementation MUST never restart the timer within an interval.
>    For e.g., in the above figure, if the timer is in interval I2, the
>    implementation MUST never restart the timer to the beginning of the
>    current interval i.e., I2.  If the timer is in interval T2 and if the
>    reset is to be done then the interval is set back to Imin.  If the
>    timer is already in Imin, then the reset should do nothing.”
> 
> Trickle never “restarts” a timer. It can reset a timer to Imin, but not
> restart the timer within a particular interval. Under what circumstances
> would an implementation “restart” a timer to the beginning of the current
> interval?
> 
> Phil
> 
> 
> 
> > On Jun 3, 2021, at 5:32 AM, [e-mail] wrote:
> >
> >
> > A New Internet-Draft is available from the on-line Internet-Drafts
> directories.
> > This draft is a work item of the Routing Over Low power and Lossy networks
> WG of the IETF.
> >
> >        Title           : RPL Observations
> >        Authors         : Rahul Arvind Jadhav
> >                          Rabi Narayan Sahoo
> >                          Yuefeng Wu
> > 	Filename        : draft-ietf-roll-rpl-observations-06.txt
> > 	Pages           : 20
> > 	Date            : 2021-06-03
> >
> > Abstract:
> >   This document describes RPL protocol design issues, various
> >   observations and possible consequences of the design and
> >   implementation choices.
> >
> >
> > The IETF datatracker status page for this draft is:
> > https://datatracker.ietf.org/doc/draft-ietf-roll-rpl-observations/
> >
> > There is also an htmlized version available at:
> > https://datatracker.ietf.org/doc/html/draft-ietf-roll-rpl-observations
> > -06
> >
> > A diff from the previous version is available at:
> > https://www.ietf.org/rfcdiff?url2=draft-ietf-roll-rpl-observations-06
> >
> >
> > Internet-Drafts are also available by anonymous FTP at:
> > ftp://ftp.ietf.org/internet-drafts/
> >
> >
> > _______________________________________________
> > Roll mailing list
> > [e-mail]
> > https://www.ietf.org/mailman/listinfo/roll
> 
> ———————
> Philip Levis (he/him)
> Associate Professor, Computer Science and Electrical Engineering Faculty
> Director, lab64 Maker Space Stanford University http://csl.stanford.edu/~pal
> 
> _______________________________________________
> Roll mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/roll