## ROLL IETF 118 - Minutes   {#roll-ietf-118---minutes}

Meeting Materials: https://datatracker.ietf.org/meeting/118/session/roll

Meetecho:https://meetings.conf.meetecho.com/ietf118/?session=31755

### Wednesday, 8th November, Session II   {#wednesday-8th-november-session-ii}

| Time | Topic | Presenter |
|----------
| 13:00 - 13:15 | WG Introduction | Ines/Dominique |
| 13:15 - 13:25 | draft-ietf-roll-rnfd | Chairs/Authors |
| 13:25 - 13:35 | draft-ietf-roll-mopex | Chairs/Authors |
| 13:35 - 13:45 | draft-ietf-roll-enrollment-priority | Chairs/Authors |
| 13:45 - 13:55 | draft-ietf-roll-nsa-extension | Chairs/Authors |
| 13:55 - 14:00 | Open Floor | Everyone |

## 1) Introduction (15 minutes):   {#1-introduction-15-minutes}

*   status  
    Pascal: any news about the reviews of dao-proection?  
    Sue: review done, did not have time to report back  
    John: is behind on it, but aware and will move as fast as can.

Have a session at IETF119 Brisbane?  
MCR: probably not  
MCR: encourages Virtual interim meetings to pick dates.  
MIC: 1pm UTC is 5am California, why such an early time?  
Ines: We do doodle polls to pick times, this is what came out of the
poll.  
 (MCR: we could pick some different times for subsequent meetings)  
Pascal: agree for not meeting at Brisbane, hard to get a quorum.  
Pascal: value of mailing list to decide on meetings is debatable.  
 Meeting in a different time zone might bring new participants in that
are not on the mailing list

## 2) draft-ietf-roll-rnfd (10 minutes):   {#2-draft-ietf-roll-rnfd-10-minutes}

## 3) draft-ietf-roll-mopex   {#3-draft-ietf-roll-mopex}

what does it mean for the extended field to have the old values? Does
network operate the exact same way, or almost same with some options now
mandatory?  
Now it is an issue https://github.com/roll-wg/mopex/issues/12 .   
Pascal: Same value, but includes v2 support. List of such v2 options to
be defined.  
MCR: same memory of this discussion as Pascal's.  
Dominique: but we haven't defined what v2 is yet. What do we write in
this document?  
MCR: make them RESERVED, since we haven't defined v2 exactly yet.  
Dominique: maybe RESERVED-foobar-v2, to hint that they correspond to
foobar mode of current RPL, with v2-mandatory options. Just symbolic
name, no specification.  
Dominique: will update the ticket with this discussion.

## 4) draft-ietf-roll-enrollment-priority (10 minutes):   {#4-draft-ietf-roll-enrollment-priority-10-minutes}

Only issue #17 still open. Think #17 done in MCR's copy, to be checked.
Maybe recent review to be acted upon.  
Rest are done. Change of mantisse size done (was discussed at last
meeting).

## 5) draft-ietf-roll-nsa-extension (10 minutes):   {#5-draft-ietf-roll-nsa-extension-10-minutes}

-12 has been published right before the meeting.  
Dominique "the node MUST NOT select the candidate neighbor as its AP".
Is this not duplicating some other specification?  
Pascal: it's in MRHOF, not in RFC6550.  
Aris: this is meant as a clarification.  
Dominique: then write "as per RFCxxx, the node will not select ..."

Pascal: could have used infinite rank, FFFF (defined in RFC6550). Would
remove dependency on MRHOF.  
Pascal: MRHOR relies on ETX as a metric. Behavior of NSA does not depend
on the metric used.  
Pascal: does not make sense for NSA to rely on ETX. It could be an
extension to any Objective Function.  
Remous-Aris(RA): if we make it generic, then we don't wind up with
anything concrete. Don't know how to express in a draft.  
Pascal: basing NSA on MRHOF reduces the applicability of the draft.  
Pascal: The NSA goals are not to create a new objective function, but
rather than work with any objective function to enhance what is
computed.  
Pascal: RPL describes what an objective function does. You would update
this by saying "in the case of NSA, the objective function also has to
do X"  
Aris: need to cancle the WGLC because big changes potentially ahead.  
Pascal: not big changes.  
Aris: editorial still big.  
D: Let's think about it.   
Pascal: MRHOF is not generic, OF0 is more generic. MRHOF only
implemented in Contiki, not in industry AFAIK.  
Dominique: implementations have their own OF, unspecified.  
Pascal: exactly. If this draft does not rely on a specific OF, can be
applied to any OF.  
Dominique: think MRHOF does a lot more than computing the rank, yet
still called an OF!  
RA: will take a few weeks to try implementing this new idea, in a
separate branch on git.  
Dominique: or could setup a little design session.  
Dominique: we'll synch offline.  
Ines: keep the ML informed.

## 6) Open Floor (5 minutes)   {#6-open-floor-5-minutes}

Discussion about if DAO-projection should be marked experimental?  
Sue: question was: you are changing a lot in the protocol, do you have
an implementation of your proposal?  
Pascal: this is not revising the protocol, but augmenting it, so it's
incremental.  
Pascal: building new DODAGs, but in a centralized way, skipping the
first RPL phase.  
Sue: not complaining about the additional features, but rather asking
the operational question: has this been prototyped yet?  
Pascal: have not built this out yet.  
Sue: had experience on adding new features to existing spec. Comment was
feedback to you and AD. May chose to ignore.  
Pascal: experience in this WG is that open source implementors not been
interested in experimental specs. AODV-RPL was designed as a replacement
of P2P-RPL, which has never been implemented.  
Sue: realize the dynamics. Still stand by comment.  
John: lack of implementation will be captured and exposed in the
shephard write-up.  
John: different WGs may have different standards on requiring
implementations.  
John: BGP high risk and large scale, RPL not so much. OK if this WG
applies a different standard.  
MCR: RPL not too chatty, good for long latency deep-space networking.
Propagation delays in dozens of minutes.  
Ines: Deep-space side meeting yestersday, no recording available.  
MCR: Another side meeting tomorrow. See the slides. Discussion was on
QUIC on long delay networks.