Re: [Roll] WGLC for draft-ietf-roll-efficient-npdao-03

Thank you Georgios for the review. I just pushed -04 which
incorporates your comments.
On Tue, 17 Jul 2018 at 07:05, Georgios Z. Papadopoulos
<georgios.papadopoulos@imt-atlantique.fr> wrote:
>
> Hello Rahul,
>
> Many thanks for your quick response.
> Please find my response inline:
>
> Cheers,
> Georgios
>
> > On Jul 16, 2018, at 20:28, Rahul Jadhav <rahul.ietf@gmail.com> wrote:
> >
> > Thank you Georgios for the review.
> > Please find my response inline below.
> >
> > Best,
> > Rahul
> >
> > On Mon, 16 Jul 2018 at 06:53, Georgios Z. Papadopoulos
> > <georgios.papadopoulos@imt-atlantique.fr> wrote:
> >>
> >> Dear Roll, Rahul and co-authors,
> >>
> >> I find this proposal useful, and quite ready to go.
> >> Please find my (perhaps minor) comments below.
> >> — —
> >>
> >> [1] 1.2. Current No-Path DAO messaging
> >> "Subsequently parents or ancestors would release any resources (such as the routing entry) it maintains on behalf of target node.”
> >>
> >> [GP] What could be other type of resources, apart from a routing entry, that a parent or ancestors may release?
> >> Could you provide some more examples?
> >
> > [RJ]: another something usually done in context to route removal is
> > decreasing the ref-cnt for the corresponding next-hop nbr-table entry
> > ... such that if the ref-cnt reaches 0/zero the neighbor table entry
> > could as well be deleted.
>
> [GP] Many thanks for the example.
> I believe it would be helpful to provide such another example in the draft.
>
> >>
> >>
> >> [2] 3.1. Req#1: Tolerant to link failures to the previous parents
> >> “Therefore, it is required that the NPDAO message MUST be tolerant to the link failure during the switching.”
> >>
> >> [GP] How it can be tolerant, when there is a link failure? What could be the potential means to be tolerant?
> >
> > [RJ]: The text states that any new route-invalidation mechanism
> > defined should be tolerant to link failures. The link referred here
> > represents link between the node and its previous parent (from whom
> > the node is now disassociating). The way the draft achieves this
> > tolerance is by having the route invalidation get done through the new
> > route that is newly established and not depend on the previous link
> > which is failed.
>
> [GP] Many thanks for the clarification.
> Do you think you could provide such explanation in the draft?
>
> >>
> >>
> >> [3] 4.1. Change in RPL route invalidation semantics
> >> “The trigger for the common ancestor node to generate this DCO is the change in the next hop for the target on reception of an update message in the form of regular DAO for the target.”
> >>
> >> [GP] I am having some troubles to understand this sentence, is it possible to be rephrased?
> >
> > [RJ]: "The common ancestor node generates this DCO in response to the
> > change in the next-hop on receiving a regular DAO for the target."
> > Do you think this rephrase works better ?
>
> [GP] Yes, definitely. Many thanks.
>
> >>
> >>
> >> [4] 4.3. Destination Cleanup Object (DCO)
> >> “The DCO message always traverses downstream and cleans up route information and other state information associated with the given target.”
> >>
> >> [GP] Similar to comment [1], is it possible to give some examples of state information?
> >
> > [RJ]: mentioned as part of [1] response.
>
> [GP] Great, thanks.
>
> >>
> >> — —
> >> Best,
> >> Georgios
> >>
> >> ____________________________________
> >>
> >> Georgios Z. Papadopoulos, Ph.D.
> >> Associate Professor, IMT Atlantique, Rennes
> >>
> >> web:   www.georgiospapadopoulos.com
> >> twitter:  @gzpapadopoulos
> >> ____________________________________
> >>
> >> On Jul 4, 2018, at 11:40, Ines Robles <mariainesrobles@googlemail.com> wrote:
> >>
> >> Dear all,
> >>
> >> A Working Group Last call (WGLC) starts today (04/07) until 20/07 for draft-ietf-roll-efficient-npdao-03
> >>
> >> The draft is available here:
> >> https://datatracker.ietf.org/doc/draft-ietf-roll-efficient-npdao/
> >>
> >> Please review this draft to see if you think that it is ready for publication and send comments to the list stating your view.
> >>
> >>
> >> Thank you very much in advance,
> >>
> >> Ines and Peter
> >> _______________________________________________
> >> Roll mailing list
> >> Roll@ietf.org
> >> https://www.ietf.org/mailman/listinfo/roll
> >>
> >>
>