Re: [Roll] Review of draft-ietf-roll-enrollment-priority-04

[Michael Richardson <[e-mail]>]

{I'm getting emails in funny orders because roll-chairs gets to be faster, as
I'm the secretary}

Konrad Iwanicki <[e-mail]> wrote:
    > Below I just quickly reply inline to Michael's comments as they led to
    > a new version of the draft. I was actually replying to Pascal's and
    > Rahul's comments while the new draft version appeared, and the new
    > version still has some issues, which I wanted to point out in those
    > replies.

    > So what do I do then, write another review for the new version where I
    > can explain those issues?

You can do that, or open issues at
https://github.com/roll-wg/draft-ietf-roll-enrollment-priority
(or I can do that).

(Then we can iterate on the issue, but in general I prefer using the ML)

I have opened an issue:
   https://github.com/roll-wg/draft-ietf-roll-enrollment-priority/issues/5

It might be that we need a create a ConfigurationNumber lollilop counter.
I could live with that.   I note that DIO Configuration essentially has the
same problem, right?

    > I believe RFC 6550 uses term "parent" for any neighbor with a rank
    > lower than the node itself and "preferred parent" for the parent
    > (conceptually a single one) that the node uses as the next hop on its
    > upward routes. This may be one of the sources of my confusion. After
    > your explanation, I understand your point of view on the
    > protocol. Thanks.

If you think that we should use the word "preferred parent", I'm good with
that.

The nice thing about having new eyes (like yours) on things is that after 5-6
reads of a document, one tends to think we know what it says, and often we
are subtly wrong.

    >> A root that did this, would have to increment the DTSN right each time
    >> it changed it's mind.

    > OK but:

    > 1. This is not mentioned in the new version of the draft.

I agree that it needs to be explained.
I resist adding a new lollipop counter, because that's something new that
needs to be written to flash.

I think that I am wrong to suggest DTSN increment...  I claim heat stroke. :-)

I think that incrementing DODAGVersionNumber is the right answer.
I think that all of the Configuration work we've been discussing would also
depend upon DODAGVersionNumber, and this is just among that group of things.

    > 3. Even if the this approach were covered in the draft, it still has
    > some issues, which I was about to explain but the new version of the
    > draft appeared.

Every version has a diff, so most of us deal with the diff to know if the
things we want fixed are actually fixed.

    >>> We agreed to merge two drafts.  The DODAG_Size came from the other
    >>> draft.  We think that the two values are very much related and it
    >>> made sense to send them together.

    > OK, now I understand. However, this also generates some further issues
    > I wanted to point in my reply to Rahul's and Pascal's comments.

if it turns out that the two things change at significantly different rates,
then combining them may have been a poor choice.

--
]               Never tell me the odds!                 | ipv6 mesh networks [
]   Michael Richardson, Sandelman Software Works        |    IoT architect   [
]     [e-mail]  http://www.sandelman.ca/        |   ruby on rails    [


--
Michael Richardson <[e-mail]>   . o O ( IPv6 IøT consulting )
           Sandelman Software Works Inc, Ottawa and Worldwide