Re: [Roll] roll WG Virtual Meeting: 2020-09-30 - Call for Agenda Items-

[Rahul Jadhav <[e-mail]>]

Will now be the right time to check consensus with the WG on what behaviour may have to be mandated as part of RPLv2?

Following are some of the points which immediately comes to my mind:

1. Use of revised Option Type (0x23) in RPI ... (Obsolete use of 0x63 RPI Option Type value).
2. Mandating the use of 6LoRH (RFC 8138) ... (Allows compression of SRH (non-storing) and RPI (storing mode)). This is something that was discussed in context to turnon-8138 T-bit draft recently.
3. Use of MOPex (This is how we know the instance is RPLv2)
4. Support for Ext Control Options. (Allows Backward compatibility for new extns... part for same mopex draft)
5. Support for Capabilities. (Enables backward compatibility, allows incremental feature support)

There are some points from RPL Observations draft [2] which could be clarified as part of this work item. Not sure if those points could go in as part of this draft? For e.g., Path Control Bits handling issue in 6550 [1] ... 2) Mandating handling (not sending) of multiple targets in DAO [3]

WG could provide feedback on the following aspects:
1. Do you feel one of the points above need not be mandated?
2. Do you feel there is some other point which needs to be addressed?

[1] https://tools.ietf.org/html/draft-ietf-roll-rpl-observations-04#section-10
[2] RPL Observations: https://tools.ietf.org/html/draft-ietf-roll-rpl-observations-04
[3] https://tools.ietf.org/html/draft-ietf-roll-rpl-observations-04#section-7


________________________________
From: Roll <[e-mail]> on behalf of Michael Richardson <[e-mail]>
Sent: 14 September 2020 02:09 PM
To: Routing Over Low power and Lossy networks <[e-mail]>
Subject: Re: [Roll] roll WG Virtual Meeting: 2020-09-30 - Call for Agenda Items-


Georgios PAPADOPOULOS <[e-mail]> wrote:
    > Regarding the RPLv2, do you think it would be possible to have at the
    > end of the day everything in one single document?

Yes, eventually, we'd do rfc6550bis, and we'd merge in all the documents,
throw out the pieces that we didn't implement, and maybe advance to Internet Standard.

    > In stead of going over multiple documents, and multiple RFCs tomorrow,
    > imho, it would be more efficient to have one single RFC for the RPLv2
    > like the RFC 6550 for RPL.

    > What do you think?

It's just too soon.
We actually need to sort out the things we want to do.
Editing the huge rfc6550 won't be productive at this point.

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