IETF 106 - ROLL Meeting-Tuesday-19Nov MATERIAL: https://datatracker.ietf.org/meeting/106/session/roll Meetecho: https://www.meetecho.com/ietf106/roll/ Meeting Notes: Michael Richardson's colour. Dominique's colour Alexander's color The Tuesday meeting notes are at the bottom of the Etherpad. ------------------------------------------------------------------------------------------- Monday Agenda Monday Nov 18, 2019 15:50-17:50 Singapore time (UTC+8) +--------------------------------------------+-------------+------------------------------+ | Topic | Time 120 mn | Presenter - On site/Remote | +--------------------------------------------+-------------+------------------------------+ | Introduction - WG Status | 16 min | Dominique/Ines | +--------------------------------------------+-------------+------------------------------+ | draft-ietf-roll-rpl-observations-02 | 40 min | Rahul | +--------------------------------------------+-------------+------------------------------+ | draft-ietf-roll-dao-projection | 25 mn | Pascal | +--------------------------------------------+-------------+------------------------------+ | draft-ietf-roll-mopex-cap-01 | 35 mn | Rahul | +--------------------------------------------+-------------+------------------------------+ | Wrap up | 4 min | Ines | +--------------------------------------------+-------------+------------------------------+ Meeting Notes: [15:51] meeting starts Introduction: * Note Well * Thanks to Peter, out-going co-chair, for his excellent work over the last years * Jabber scribe Georgios * minutes takers : Alex Pelov, Laurent Toutain [15:53] Introduction - WG Status (Ines and Dominique) Ines shows the updated milestones. Comments welcome. Pascal Thubert: DAO projection still a bit optimistic. Rather next year, hopefully by IETF107. Ines: See active use of Github for ticket tracking. We are going to watch it as well as the IETF tracker. Ines: shows relationships between currently active drafts. Question: DAO projection: should be a new MOP? Question to be answered today or on the mailing list. Question for tomorrow: should turnon-8138 be implemented as a capability? [15:58, expected 16:05] draft-ietf-roll-rpl-observations-02 | 40 min | Rahul | This draft contains RFC 6550 observations and clarifications with input from implementations Every section has a question: should we do it this way or that way? Draft may not be published as RFC but kept as a work document and update it Parent switching In non-storing mode, DTSN value is directly controled by the root. In storing mode, it is more difficult, can lead to a lot of DAOs or big DOA requiring frag. Pascal: the specification is not clear. In storing mode, the amount of state to be transferred is the same, less bytes over the air if D rebuilds an aggregated DAO to send to C. Pascal: would argue we want to pack many targets in to the DAO to make it reasonably big, also to compress it as much as we can. Radul: talking about compression, each target has different path sequence number and lifetime. Not possible to aggregate them in the same transit info option. A lot of control overhead. having said that, incrementing DTSN and resetting Trickle timer will create an enormous amount of overhead, too. But so easy to implement! Michael Richardson: three questions: 1- procedural next step: when we know hat we want, should we put the fix in 6550 errata or leave in this draft? Question 2: is there an interoperability issue between the two possibilities you mention? Rahal: RFC does not mandate/specify handling of aggregated DAOs. Contiki doesn't work at multiple hops today. Michael: I understand your second option does not work today because the handling of aggregated DAOs not cleary articulated in 6550. We have an erratum here, should say MUST handle multiple DAOs. MCR: The Sender knows it implements aggregated DAO, but does not know if the receiver is able to handle it. We have an interop issue. MCR: not knowing what the receiver accepts, only option for sender is to incremente DTSN and send individual DAOs. Pascal: seems we're mixing 2 problems. Clarifying: PT: Problem 1: does D answer on behalf of its children PT: Problem 2- whether D sends them as individual messages with one target in them or packs them as one big message with lots of targets in them. MCR: sending DTSN down also results in individual DAOs coming back up, and you don't have to package them. PT: D sending single DAO (aggregated) vs multiple DAOs is orthogonal to the question of sending DTSN down. MR: Multiple DAOs - we have problem with interoperability, it sounds like everyone would like to use solution B, it's just that we don't know if we are able to implement it MCR: how many in the room use storing MOP? Anima is using storing. MCR: We should not spend too much time over this issue (we could use capabilities to fix this, discovering if all nodes support DAO aggregation) MCR: Alternatively, we could use non-storing mode and projected DAO as a replacement, regardless. MCR: Write errata - "you should support multiple DAOS, if you don't you have a bug. You should resend them from your storage rather than incrementing DTSN." MCR: We shoud write these two statements, not worry about back compatibility issue. Pascal [at 16:15]: it is in the RPL spec that you can package multiple targets in one DAO. DAO-ACK Handling: in non-storing mode, Ack is sent by the root, to say to the node that application traffic can begin. in storing MOP, DAO is sent hop by hop, relying on the parent to forward it to the root. If parent answers immediatly with a DAO-ACK, it is not a information that the traffic can start. Indeed, something might happen upper in the DAG. Negative status can be transmitted by the upper node, but no way to propagate it down because intermediate node already sent positive ACK down. Pascal: (the new) DCO can be used for the second point MCR: storing mode - DAO-ACK from B is failed, D thinks it can send trafic, but it will not recieve any answer. It's OK to have DAO-Ack mean - "Start trafic" - as there may be other nodes to which the node could communicate. Rahul: yes, but nodes below starting their application traffic just aggravates the problem. Alvaro Retana (as a WG contributor): like the DCO. What other protocols do is wait for ACKs cascading down from the root. Rahul: cascading the DAO-ACK down has implication on amount of state to be held at intermidiary nodes. Pascal: the design was that by ACKing the DAO, a node takes responsibility for propagating the DAO, and also for killing the relationship to the child if node fails to propagate the DAO, because can't serve it as a parent. Before having the DCO, the node had to completely stop being a router. The subtree will find another way. The problem, the time to wait is not known. Michael : notice the last point in slide : does not interoperate. Pascal: there is no other scheme. Contiki has a behavior that is not in the spec. Pascal: the cascading version will have long timeouts. Rahul: Contiki's implementation is another interpretation of RFC6550, not really violated a mandate. Pascal: probably correct, but that behavior was not the intent. Status=0 used as an indication that path is established. Next point: Signaling resource constraints Node D going through node B, B with limited resources, B cannot take any further nodes. There is no metric to send this informaiton downlink. We need to put this information somehow in the metrics. Georgios Papadopoulos: we have a draft on this. Remaining resource, in DIO. MCR: dont undestand why this is not usable at multiple hops. Rahul: The point is when H (connected to F and D) is going to be added do B, but B doesn't have the resources -> D can switch the route to pass through C instead, but C may not have the ressources either for the full sub-DODAG. Rahul: this happens with networks with lots of nodes. Pascal: was discuss during original RPL design to have a message to say, I cannot take more resource. Only thing is to push back. It has been proposed but would have made RPL more complex. The chosen solution was to say that every node needs to have enough resources to store the necessary state for the whole network. Otherwise, the mechanisms to handle when some nodes may not have sufficient resources make the solution too complex. Rahul: this design assumption never came into 6550. Should be mentioned somewhere. Implementers realize it at a late stage. PT: Depends on the assumptions on your hardware. It is mostly a deployment question, not that much developer one. Rahul: use case document says we can use storing mode for networks of thousands of nodes. Maybe shoudl capture the assumption. PT: yes, it should be written somewhere Rahul: we need nodes to have enough resources, all the nodes, if we want storing MOP to be used. Transit Information Option: contains a target-specific flag; the Option cannot have mutliple targets. Pascal: agree, not factorisable Rahul: in this case, no different Path Sequence, but still Path Lifetime. Pascal: factorising Target only works for devices physically tethered together. Eliding Option: 6550 says Configuration Options can be elided, but there is scenario where it is not passible to elided, there is a specific draft for this issue. See next. Rahul: Node needs persistent storage for lollipop counters, otherwise it can be in non-deterministic stage for long time. Node may reboot multiple times. Pascal: there is a linear part to accomodate for several lost messages. Its length has to be tuned to the frequency your are sending. Pascal: size of linear part to be adjusted according to frequency of message, we should revisit each lollipop in RPL and adjust its linear part length. 16 was thought for DIOs. Rahul: problem for DTSN. We don't say which length should the linear part be. Pascal: agree, for DTSN the linear part should be 0. => ACTION POINT: go through RFC6550 and look at each lollipop counter to define its length. Path Control Bit: - not used now. Provide multiple downward routes, allows to do load balancing. Might be used by 6TiSCH. Pascal: this is a basic thing, there are new proposals that are more powerful, this can be deprecated. Pascal: could decide to deprecate this when we revisit 6550, and look at the newer approach. Rahul : nsa-extension has different set of design assumptions, including security. Overhearing requires to have same shared key. Pascal: but nsa has intricated paths instead of bottleneck, still benefits. Sending DAO-ACK when K bit is set is SHOULD in 6550, should be MUST. Pascal agrees. TIO is optional, should be mandatory Rahul suggests to have a mininal-RPL without all the complex features (Path Control, ...) Back to DAO-ACK issue. Pascal: DCO was meant to kill something, now could transport some info. E.g. new status (below 128), such as "route is open". Rahul: maybe we should have used a different name (not "cleanup") - as it does more things (e.g. root reachibility indication) Pascal: DCO is a powerful tool, has RPL status in it, can do more than kill route. Pascal: may find new acronym. More points uncovered: Multi-Sink/BR practices, Multicast operations dependency on ND. Prefix info is part of RPL but other stuff like DNS config still relies on ND. Michael: would rather put some context info in DIO and be ok without ND. However, we need ND for RPL unaware leaves. Both options have value. Michael: we need to have a conversation about configuration information. Pascal: now, we have capabilities to elide config info. Pascal: when designing RPL, separated RA from DIO because of different pace expected for each of them. Rahul: we need numbers, cost of these mechanisms. Ines: feel free to contribute / participate in implementation. Or contribute to a draft on lollipop counters. Newcomers welcome. [16:58, expected 16:45] draft-ietf-roll-dao-projection | 25 mn | Pascal | Pascal presenting Made a lot of additions since last IETF. compressing Via option of P-DAO with RFC8138 P-DAO is a segment per 8138, addresses compressed to the same number of bytes. Otherwise, split in several segments. managing created path needs a Path id A PAth is called a track in 6TiSCH, it's a DODAG to a destination, use the local RPL instance ID + the destination IP to build a Track ID. Georgios: how to define the track, how is it updated? Pascal: the root will send a new P-DAO message with a new Path sequence number A Track is not a just a serial path. Different segments constitute the Track. A segment ID was also missing, added in the latest rev of this draft (this morning!) Added Sibling ID to signal non parents to the root (does not take into account sibling selection) Rahul: path control bits can do that. Multiple Transit Info to the root. Pascal: but only for parents. We want do send info to the rot regarding non parents. Sibling selection may be needed, but not addressed in this draft. May need something similar to an OF to select a few siblings among all of them. Introduced a P-DAO request - unicast packet for a node to request from a second node a path to a third node. And associated P-DAO Request ACK. In the future, add something like a metric container, but with the quality metric of the path that want to be built. Maybe not quite the metrics we have right now. Do we need it? Rahul: SegmentID is purely for management purposes, TrackID may be used in the data plane as well. Pascal: indeed. Signaling the Track in Packet - (Global/Local, Sourc/Dest, Inst)->IPv6.destination - the track is always going to somewhere, never coming back. Therefore the S/D bit is always Destination. Pending issues: Tickets #179, #180, security of P-DAO, config parameters into P-DAO Requests There are a lot of changes in the document. Some of it was discussed on ML, some got feedback, others didn't. Feedback is necessary to see if the progress is in the right direction. Eventually, some optimization can be done after ongoing discussions are cleared. WGLC next IETF. Who's willing to review the draft? 5: Georgios, Michael, Rahul, Remy, xxxx [17:20, expected 17:10] draft-ietf-roll-mopex-cap-01 | 35 mn | Rahul | Rahul presenting What are capabilities (CAP)? Difference between Mode of Operation (MOP) and DIO Configuration options? Design goals: any node can generate it, any option could be sent in any message, upward or downward, could be explicitly queried, ... Earlier version of this draft had only combination of bits, now most capabilities having their TLV. Handling CAP unaware nodes? CAP would be used only for the new MOPs. Need WG opinion. We need to be able to query the CAP. New message altogether? Need WG opinion. MOP numbering: decided to use value carried in extended-MOP as is, not added with MOP field. This way, can still use existing MOP values with CAPs turned on. Pascal: coming back to capabilities: the configuration is when the root imposes something, capabilities inform of what the nodes can do. Management can also be used for the latter. Michael: are you saying you dont want CAPs for 8138 turn on? Pascal: express the capability with this draft, trigger turn on/ok with turnon8138 Pascal: we have devices in the field that need 8138. We need a way to turn compression on, quickly. Let's ship turnon8138. Rahul: Now that we have CAPs, less reliance on number of MOPs. Reduce current 24 bits downto 16? Seeking opinion. Rahul: suggest to split CAP and MOPEX into two different drafts, they are independant things. Pascal: question to Alvaro? Makes more sense to us engineers to split, but IESG might not like it. MOPex very simple, we could flash it through. Alvaro: doesn't really matter. Would prefer one document because easier to handle for IESG. But other considerations. Either way is fine. Michael: I prefer 2 documents. Michael: MOPex is RPL option, TLV format, so dont need to worry about it size now. Maybe have a max to a reasonnable value. Like 4 bytes max. Pascal: agreed. Pascal: we are essentially making a version 2 of rpl which is MOP 7 and MOPEX, packing all the options. Rahul: will do a major revamp of the document based on this discussion. Ines: should P-DAO be a new MOP? Pascal: no. There was great discussion on mailing list (by Rabi?). Use CAP to project routes. No new MOP needeed. Rahul agrees. Willing to review? (after split) Michael, Pascal, Remy Michael: can we split quickly and adopt MOPEX quickly? Ines: if split today, can adopt tomorrow [17:40, expected 17:45] Wrap-up [17:40] Session adjourns =========================================================================================== Tuesday Tuesday Nov 19, 2019 10:00-12:00 Singapore time (UTC+8) +--------------------------------------------+-------------+------------------------------+ | Topic | Time 120 mn | Presenter - On site/Remotely | +--------------------------------------------+-------------+------------------------------+ | Introduction | 5 mn | Dominique/Ines | +--------------------------------------------+-------------+------------------------------+ | draft-ietf-roll-unaware-leaves | 30 mn | Pascal/Michael | +--------------------------------------------+-------------+------------------------------+ | draft-ietf-roll-useofrplinfo | 10 mn | Ines/Pascal/Michael | +--------------------------------------------+-------------+------------------------------+ | draft-thubert-roll-eliding-dio-information | 20 mn | Pascal/Dominique | +--------------------------------------------+-------------+------------------------------+ | draft-ietf-roll-efficient-npdao-17 | 10 mn | Rahul/Pascal | +--------------------------------------------+-------------+------------------------------+ | draft-thubert-roll-turnon-rfc8138 | 15 mn | Pascal | +--------------------------------------------+-------------+------------------------------+ | Open Floor | 30 mn | Everyone | +--------------------------------------------+-------------+------------------------------+ [10:03] session starts Introduction | 5 mn | Dominique/Ines | Introduction (Ines, Dominique) - Note Well - Jabber scribe: Michael, minutes takers: Alex - agenda presented: no comments [10:05, expected 10:05] draft-ietf-roll-unaware-leaves (Pascal) | draft-ietf-roll-unaware-leaves | 30 mn | Pascal/Michael | Pascal presenting The draft is an application of RFC8505, PT: This document is how a leaf would use 8505 to register to RPL services. Changes since last time DCO is the only message that goes down to the leafs. This way the router can say to a leaf that there is a problem. This document replaces an empty message with explicit status. "RPL is like an extention of ND for multihop".. this way at the end-node it is like pure ND There is a need to have a mapping between the way ND expresses things and RPL does. Explanation of how the status works - RPL -> 6LR -> unaware leaf. -- in ND you have ROVR - capability of the host to express that own the address, currently we are not using to protect RPL, maybe in future. For the moment, The ROVR is to signal to 6LBR in case that is not integrated to the root. Currently is piggibacked in RPL The RUL document has a normative reference to useofrplinfo, and not the other way around. Defines the notion of leaf, which was used before but not clearly defined. IPv6 host attached to a RPL network. The RUL document is one way to indicate the route to a RPL unaware, not the only one possible. RUL is leaf that is not aware of RPL. As editor Pascal believes that the draft is ready. 1-2 reviews, than WGLC. Who is willing to review? Rahul,, Rahul: question regarding RPL status. Overlapping a lot of ND stuff onto RPL. Pascal: new format has 64 values for RPL status and 64 values for ND status . Doesn't seem we need more. If the bit on the left is 1 then this indicates an err.-rejection The ND is indicated if the second bit is ON. Using status codes in RPL should be done via IANA. Rahul: now that we have 6LR doing the signaling on behalf of unaware leaf, PT: would not express it that way. In theory you could decompress on every hop. Compressed form is equivallent to uncompressed; Rahul: so 6LR makes the decision on behalf of the RUL, including data plane. PT: yes. If does not know better, will decompress to forward outside of RPL domain, which is the case of link to RUL. [10:22, expected 10:35] | draft-ietf-roll-useofrplinfo | 10 mn | Ines/Pascal/Michael | Ines presenting Terminology is modified. Added definition of RUL and the sections in SM that have destination the RUL. We can have router as a leaf. Pascal: link local encapsulation at every hop is gone. This is important change to 6550, to be noted. Ines: The trafic destination is the 6LR Pascal: question to Alvaro. Since this doc was taken out of RFC Editor queue, what are the next steps? Alvaro (as AD): will look at ML, implement changes, don't think will need to go back to IESG evaluation. [10:27, expected 10:45] | draft-thubert-roll-eliding-dio-information | 20 mn | Pascal/Dominique | Pascal presenting ANIMA likes RPL, cause the configuration of router is learnt as part of the protocol itself. The whole network is self-configuring itself RPL sorts itself out, even with big number of nodes. When everyone understands the configuration, there is no point in repeating it -> you can elide it. However, if there is a modification in the configuration, it must be sent to everyone.. repeat it until everyone got it, but then stop. Prefix informaiton can be such information. 6550 does not say how/when elided info is sent again, how nodes know things have changed. This draft introduces a number in DIO to reflect changes in any option. If node has earlier version number, queries router for updated options. Could have a version number of each option individually, more selective but more costly. Would not scale well with upcoming new options. Pascal suggests one single number for the set of all options. Need review. Pascal goes through the slides describing this. Rahul: node sending DAO does not know which nodes are traversed. If something has changed in the middle of the network, a sender node may not be aware of that change. Pascal: intermediate node has to send full DAO info to parent that is outdated, abbreviated info to parent that is fresh. Rahul: are we expecting to keep every capability in every node? Pascal: capabilities are not part of the DAO message, so they are not concerned with that Rahul: ok, we need to clarify that capabilities are not concerned with this mechanism Pascal: it's a simple draft, but it enables a live network to work much better. It makes the network much more manageable PIO is one of the protected option. Will be able to change prefix during life of network. These changes (nicknamed RPL v2) will help keeping a netwrok alive as opposed to stopping it and restarting it as with current RPL. Child sending last RCSS to which this node is synced. The parent can then send updated information to the child. DIS changed to add flags to query each of the 5 protected options. Is this needed? Is there a case when a child could want to ignore one fo the options? We could send all 5 options in all cases and save the flag bits. Part of discussion - can you detect a reboot of parent? Yes - the straight part is very short, so it can be detected rapidly. Resync would work even when parent is restarted, because the value will increase beyond the last value. Rahul: we need to talk about the lollipop counter. Pascal: doesn't expect that the lollipop mechanisms is an efficient way of detecting reboot. Trying to make the counter be such mechanisms. Rahul: the question is about the length of the straight part. As short as possible, but how long? Alex: does this mean the nodes need to remember the full history of option values as they change? Pascal: only remember version number of last change of each option. Rahul: dis modification draft is going to be included in the dratf, both are going to be combined? Pascal: there was a draft on providing how the answer is sent - multicast / broadcast, whether Trickle timer is reset or not. Pascal: could we package and include it in this draft Dominique (as a contributor): it's on the github (not published yet), can be merged. The two bits in DIS modifications (leftmost in Pascal's draft) - unicast vs multicast DIOs. It's all relevant to Pascal's options. Pascal: if we agree we can put this in this draft. RPL gives a complex behavior, which depends on the request (unicast/multicast) - the logic was hardwired. The bits should not signal if you use trickle or multicast. The point is - do as RPL says, or inverse the behavior. Dominique: I hear what you're saying, but the current RPL behavior is too complex to just say 'reverse'. We need to work on this Pascal: yes, let's discuss on the ML Pascal: the point is to see how DIS / DIO messages work together Dominique: DIO must be send in multicast, you are going a step further, so that the other nodes are also listenting to mutlicast DIS Pascal: how do you derive a multicast address from a prefix. Here, everyone has the same prefix, so we don't care about it. But we want to be able to form this for the parent.. So the point is to have a multicast address that is just for the partent and its children. Rahul: comment on the whole utility about having a way of telling the other nodes to hear the DIS and not sent it . The scenario when a node sends a DIS is a one-off scenario. when all the nodes restart. Let's say that all send DIS the problem is that trickle timer wont be reseted Pascal: there are two things. The first is, that there may be misunderstanding of what it means to reset a trickle timer. If your trickle timer is reset, you need to set i=0. If you reset it again, there is no point in restarting the timer - that would be a mistake and needs to be specified explicitly. Pascal: need to look up in the trickle RFC, if it's not there, it should be corrected. Pascal: example with 200 power meters going down, powering up all they start in the same time, they start sending DIS -> lots of collisons. That's a real problem, it's not unusual. Dominique: we need to define use-cases Rahul: If we stop resetting the trickle timer, and the definition reseting the timer goes to set it to Imin and we let nodes send DIS, the DIO trickle timer wont get reseted and the other nodes will hear the DIOs and will stop sending DIS. Pascal: as soon as the DIO is sent, the cacathony stops, but that's an IF. There is a weird moment where everyone wants to talk and nobody listens. There needs to be a winner. Dominique: what you're describing is a Mediam Access problem. We should be careful to design a solution at Layer 3 for a Layer 2 problem. We can help it, but not pretend we solve it all. Dominique: there was a spreading option in our draft '(dis-modifications) - in this case all parents responded in the same time. Pascal: not because of trickle Dominique: not governed by Trickle, because you have unicast immediate responce. This is where we had the option to delay the response and spread it. We need to discuss. Ines: do we need a document that describes what happens in the case when such nodes get restared? Ines: have a section in each of the documents in cases when a node gets restarted - that seems to be a recurrent issue in many of the discussed points Rahul: add some considerations for future new options and which possible to elide them. Define sequence number and sequence counters. Pascal: if you could write that in mail I'll be able to respond Ines: we can publish the merged document and we'll go for adoption Pascal: Dominique, the ball is in your camp, please make sure behavior is "bit to revert behavior of current RPL". Dominique: yes, believe this is already the case, but will double-check and then publish new version of draft. [11:11, expected 11:05] | draft-ietf-roll-efficient-npdao-17 | 10 mn | Rahul/Pascal | Rahul presenting IESG last call, reviews, update Carrying RPL status as DCO What we have - RPL Status format change Pascal: Status - 'E' bit not set - the future of DCO a lot brither - instead of being always a killer for the path, it can also send informaiton, and so be more useful. One sentence somewhere in that spec, specifying that the 'E' bit is rejection, but otherwise does not invalidate the path, then DCO can be used to propagate information. I'd like to see this change in this draft. In this way we can signal non-error information down the path. Example: not an outright rejection (e.g. parent can signal - I'm getting overloaded, if possible, switch to other) Alvaro: that's a big change. No way to enforce that value doesn't get changed along the way. Not opposed to you doing this stuff, but will need a lot of review. We have to be clear on the cases. Pascal: if we keep the text as it is, that may create incompatibility issue. The point is - if a node doesn't understand a message, the E flag indicates - ignore the message, do not destroy the route. If this E flag is not understood, that would lead to nodes destroying routes in any case. Rahul: no way to enforce, but same is true to NP-DAO mechanism. Ines: request to update draft and we set a WGLC when ready [11:19, expected 11:15] | draft-thubert-roll-turnon-rfc8138 | 15 mn | Pascal | Pascal presenting Need to update brownfield (previously deployed) a network. DAG of thousands of nodes is not possible.. The whole network needs to use the same functions. If there is a mix of new / old software in the same network, that would cause difficulty in operation. Avoid flag day. Be able to upgrade nodes as possible, then when all nodes are upgraded, use a bit to turn the feature on. Compression is one of the things the DODAG must be synchronized on. Its not the same thing as capabilities. Capabilities indicates wheter the new sw can do it or not. There is not a strong tie between the configuration turning the network on and having a capability that says that is available, having capabilites is useful thing but we can live without it, cause we have to manage the devices that are not based on capabilities. Draft is stable. It's the addition of one bit, that should have been there from the start. Michael: was previously not happy with this proposal. The disconnect between capabilities / turning on is now explained. Michael: capability could be used to ask whether functionality is available in node. Would be nice, wish the capability draft were advanced enough. Michael: support doing this - the use-case of having thousands of meters being deployed over a period of several years makes sense. Rahul: agree with the use-case. Is is possible to generalize this mechanism to be used for other uses? Rahul: consuming bits in CIO. Pascal: will have CIO extension to providing more space in the future. Michael: why don't we make this doc Experimental? Thus, then we have allocation of bits revocable. Alternatively, we could reclaim these bits in 6550-bis. Pascal: could also say MOP 7 is RPL v2, and 8138 is mandatory in RPL v2. Pascal: concerned about re-using bits later in the IoT world. Don't expect operators to reflash firmware in field device just because a bit was deprecated. Pascal: MOP = 7 could deprecate the other 2 bits. Michael: we don't have that many of these bits, that's why we are anxious about allocating them *forever*. We want to have a way to reclaim them in the future. Maybe the doc should way that it applies to MOP=7 (both bits sets) (Non-Storing - stroing probably not, open to discussion), and that this bit is undefined for other modes. Pascal: plan is to change draft to say "applies only fro MOP below 7". Alvaro: other bits dependant on MOP or just this one? Pascal: thinks its a first time Alvaro: because, that would mean creation of a registry. You are sort of adding columns to the registry. Adding additional semantics to a bit creates additional columns. The regsitry needs to indicate the MOP to which this applies. Pascal: where do we put it? In which draft? Here we can do it in the two drafts under discussion, but we'll need to specify the generic registration mechanism in a new draft. infrastructure draft to create space. Other draft to use the bits. Michael: new registry for MOP 7. Pascal: one more change to useofrplinfo to indicate the MOP to which the draft applies. Rahul: now we have a dependency on this on PDAO, non-SM as segments in PDAO. We have dependency on non-storing mode. We want the ndoes to know that 8138 is on. Pascal: when you send P-DAO there should be bit. You can have a network in storing or non-storing mode, and only a path within it can support the compression. Rahul: need ref from np-dao to this doc? Pascal: don't think so. Could say decompression is inherited from the DAG. Call for adoption: 8 hands for, no hands against. None on jabber/meetecho. Will confirm on mailing list. [11:54, expected 11:30] | Open Floor | 30 mn | Everyone | No requests/comments from the room. [11:54, expected 12:00] end of session, end of ROLL meeting