Re: [Roll] RPI Option Type in useofrplinfo

[Ines Robles <[e-mail]>]

Thank you very much Rahul! We'll fix it and post new version

Best,

Ines.

On Thu, Mar 12, 2020 at 3:08 PM Rahul Jadhav <[e-mail]> wrote:

> Thanks Ines. The updated text is more clear and in sync with other text in
> the section. Please find my resp inline.
>
> Best,
> Rahul
>
>
> [IR] Thank you, we could delete the para if people/other coauthors agree.
> But in case that we want to specify the case on rebooting, would it the
> following make sense?
>
> "In the case of rebooting, the node (6LN or 6LR) does not remember the
> RPI Option Type (i.e., whether or not the flag is set), so the node will
> not trigger DIO
> messages until a DIO message is received indicating the RPI
> value to be used. The node will use the value 0x23 if the network supports
> this feature."
>
> [RJ] Yes this para is more clear for me. Thanks.
>
> Regarding the terminology: The draft terms, the new option type as "RPI
> Option Type" (value 0x23) and the old "RPL Option Type" (value 0x63). Is
> this correct?
>
>
> [IR] we define RPI here as follows:
>
> RPL Packet Information (RPI): The abstract information that [RFC6550 <https://tools.ietf.org/html/rfc6550>]
>    places in IP packets.  The term is commonly used, including in this
>    document, to refer to the RPL Option [RFC6553 <https://tools.ietf.org/html/rfc6553>] that transports that
>
>    abstract information in an IPv6 Hob-by-Hop Header
>
> Yes, with RPI Option Type we refer to the RPL Option described in 6553
>
> [RJ] Great! Please also check the PR I raised on GitHub and use the
> changes if it makes sense.
>
>