idnits 2.17.00 (12 Aug 2021) /tmp/idnits22702/draft-ietf-roll-capabilities-03.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** There is 1 instance of too long lines in the document, the longest one being 13 characters in excess of 72. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year == Using lowercase 'not' together with uppercase 'MUST', 'SHALL', 'SHOULD', or 'RECOMMENDED' is not an accepted usage according to RFC 2119. Please use uppercase 'NOT' together with RFC 2119 keywords (if that is what you mean). Found 'MUST not' in this paragraph: III: Non-Storing mode P-DAO Routing resource capabablity sent in DIO message has link local scope and it MUST not be forwarded. -- The document date (April 16, 2020) is 765 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) == Missing Reference: 'TODO' is mentioned on line 464, but not defined == Unused Reference: 'I-D.ietf-roll-dao-projection' is defined on line 470, but no explicit reference was found in the text == Unused Reference: 'I-D.thubert-roll-turnon-rfc8138' is defined on line 475, but no explicit reference was found in the text == Unused Reference: 'RFC8138' is defined on line 492, but no explicit reference was found in the text == Unused Reference: 'I-D.ietf-lwig-nbr-mgmt-policy' is defined on line 499, but no explicit reference was found in the text == Outdated reference: A later version (-25) exists of draft-ietf-roll-dao-projection-09 == Outdated reference: A later version (-04) exists of draft-ietf-roll-mopex-00 Summary: 1 error (**), 0 flaws (~~), 9 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 ROLL R. Jadhav, Ed. 3 Internet-Draft Huawei Tech 4 Intended status: Standards Track P. Thubert 5 Expires: October 18, 2020 Cisco 6 M. Richardson 7 Sandelman Software Works 8 R. Sahoo, Ed. 9 April 16, 2020 11 RPL Capabilities 12 draft-ietf-roll-capabilities-03 14 Abstract 16 This draft enables the discovery, advertisement and query of 17 capabilities for RPL nodes. 19 Status of This Memo 21 This Internet-Draft is submitted in full conformance with the 22 provisions of BCP 78 and BCP 79. 24 Internet-Drafts are working documents of the Internet Engineering 25 Task Force (IETF). Note that other groups may also distribute 26 working documents as Internet-Drafts. The list of current Internet- 27 Drafts is at https://datatracker.ietf.org/drafts/current/. 29 Internet-Drafts are draft documents valid for a maximum of six months 30 and may be updated, replaced, or obsoleted by other documents at any 31 time. It is inappropriate to use Internet-Drafts as reference 32 material or to cite them other than as "work in progress." 34 This Internet-Draft will expire on October 18, 2020. 36 Copyright Notice 38 Copyright (c) 2020 IETF Trust and the persons identified as the 39 document authors. All rights reserved. 41 This document is subject to BCP 78 and the IETF Trust's Legal 42 Provisions Relating to IETF Documents 43 (https://trustee.ietf.org/license-info) in effect on the date of 44 publication of this document. Please review these documents 45 carefully, as they describe your rights and restrictions with respect 46 to this document. Code Components extracted from this document must 47 include Simplified BSD License text as described in Section 4.e of 48 the Trust Legal Provisions and are provided without warranty as 49 described in the Simplified BSD License. 51 Table of Contents 53 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 54 1.1. Requirements Language and Terminology . . . . . . . . . . 3 55 1.2. What are Capabilities? . . . . . . . . . . . . . . . . . 3 56 2. Requirements for this document . . . . . . . . . . . . . . . 4 57 2.1. How are Capabilities different from MOP or DIO 58 Configuration Option? . . . . . . . . . . . . . . . . . . 4 59 3. Capabilities . . . . . . . . . . . . . . . . . . . . . . . . 4 60 3.1. Capability Categories . . . . . . . . . . . . . . . . . . 5 61 3.2. Capability Control Message Option . . . . . . . . . . . . 5 62 3.3. Capabilities Handshake . . . . . . . . . . . . . . . . . 6 63 4. Guidelines for defining new capabilities . . . . . . . . . . 6 64 4.1. Handling Capability flags . . . . . . . . . . . . . . . . 7 65 4.1.1. Rules to handle capabilities flag . . . . . . . . . . 7 66 5. ROLL Capabilities . . . . . . . . . . . . . . . . . . . . . . 7 67 5.1. Capability Indicators . . . . . . . . . . . . . . . . . . 7 68 5.1.1. Format of Capability Indicators . . . . . . . . . . . 7 69 5.2. Routing Resource Capability . . . . . . . . . . . . . . . 8 70 5.2.1. Format of Routing Resource Capability . . . . . . . . 9 71 6. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 9 72 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 9 73 7.1. New option: Capabilities . . . . . . . . . . . . . . . . 9 74 7.2. New Registry for Capabilities Flags . . . . . . . . . . . 10 75 7.3. New Registry for Capabilities Indicators . . . . . . . . 10 76 8. Security Considerations . . . . . . . . . . . . . . . . . . . 10 77 9. References . . . . . . . . . . . . . . . . . . . . . . . . . 10 78 9.1. Normative References . . . . . . . . . . . . . . . . . . 11 79 9.2. Informative References . . . . . . . . . . . . . . . . . 11 80 Appendix A. Capability Handshake Example . . . . . . . . . . . . 12 81 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 12 83 1. Introduction 85 RPL [RFC6550] specifies a proactive distance-vector based routing 86 scheme. The protocol creates a DAG-like structure which operates 87 with a given "Mode of Operation" (MOP) determining the minimal and 88 mandatory set of primitives to be supported by all the participating 89 nodes. 91 This document adds a notion of capabilities using which the nodes in 92 the network could inform its peers about its additional capabilities/ 93 features. This document highlights the differences of capabilities 94 from that of Mode of operation and explains the necessity of it. 96 1.1. Requirements Language and Terminology 98 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 99 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 100 document are to be interpreted as described in RFC 2119 [RFC2119]. 102 MOP: Mode of Operation. Identifies the mode of operation of the RPL 103 Instance as administratively provisioned at and distributed by the 104 DODAG root. 106 MOPex: Extended MOP: As defined in [I-D.ietf-roll-mopex]. 108 Capabilities: Additional features or capabilities which might 109 possibly be optional that are supported by the node. 111 DAO: DODAG Advertisement Object. An RPL message used to advertise 112 the target information in order to establish routing adjacencies. 114 DIO: DODAG Information Object. An RPL message initiated by the root 115 and is used to advertise the network configuration information. 117 Current parent: Parent 6LR node before switching to the new path. 119 NPDAO: No-Path DAO. A DAO message which has target with lifetime 0. 121 MOPex: MOP extension as defined in this document. 123 Upstream path/direction: Path or direction from the node to the Root 124 in a DAG. 126 Downstream path/direction: Path or direction to the node from the 127 Root in a DAG. 129 This document uses terminology described in [RFC6550]. For the sake 130 of readability all the known relevant terms are repeated in this 131 section. 133 1.2. What are Capabilities? 135 Currently RPL specification does not have a mechanism whereby a node 136 can signal the set of features that are available on its end. Such a 137 mechanism could help the root to advertise its capabilities and in 138 response also determine some advanced information about the 139 capabilities of the joining nodes. This document defines 140 Capabilities which could be supported by the nodes and handshaked as 141 part of RPL signaling. Capabilities are embedded as RPL control 142 message option as defined Section 6.7 of [RFC6550] in the base 143 messages of DIO, DAO and DAO-ACK signaling. 145 2. Requirements for this document 147 Following are the requirements considered for this documents: 149 REQ1: Backwards compatibility. The new options and new fields in 150 the DIO message should be backward compatible i.e. if there 151 are nodes which support old MOPs they could still operate in 152 their own instances. 154 REQ2: Optional capabilities handshake. Capabilities are features, 155 possibly optional, which could be handshaked between the nodes 156 and the root within an RPL Instance. 158 REQ3: Capabilities handshake could be optionally added with existing 159 MOPs. Capabilities been optional in nature could be put to 160 use with existing MOPs. Capabilities and MOP-extension is 161 mutually independent i.e. a DIO can have a capabilities 162 option, MOP-extension option or both in the same message. 164 REQ4: Capabilities could be explicitly queried. 166 2.1. How are Capabilities different from MOP or DIO Configuration 167 Option? 169 The Mode of Operation (MOP) field in RPL mandates the operational 170 requirement for the nodes joining as routers. MOP and DIO 171 Configuration Option is strictly controlled by the Root node in RPL. 172 Intermediate 6LRs could not modify the values. Also, the MOP never 173 changes for the lifetime of the RPL Instance. Changes in DIO 174 Configuration Option are possible but are very rare. Capabilities, 175 on the other hand, might change more dynamically. 177 RPL DIO message also carries routing metrics and constraints as 178 specified in [RFC6551]. Metrics and constraints are used as part of 179 objective function which aids in node's rank calculation. A router 180 may use capabilities carried in DIO message as additional metrics/ 181 constraints. However, capabilities have a larger scope and may be 182 carried in other messages other than DIO and can flow in both the 183 directions (upstream and downstream). 185 3. Capabilities 187 Handling of Capabilities MUST be supported if the network uses MOPex 188 [I-D.ietf-roll-mopex]. 190 Note that capabilities and MOPex are mutually exclusive and it is 191 possible for an implementation to support either or both of the 192 options. 194 3.1. Capability Categories 196 Capabilities can be divided into two broad categories: 198 Global Capabilities: These include the capabilities supported across 199 an RPL instance and are advertised by the Root of the DODAG. If a 200 node in the LLN doesn't support a particular global capability it may 201 have to join the RPL instance as a leaf node, as indicated by that 202 individual capability option. Example of such capabilities are 203 Compression Methods Supported, Support for TE paths (P-DAO). 205 Local Capabilities: It will include the capabilities very specific to 206 a node in the LLN. Example of such capabilities are NBR Cache 207 information, Routing table information. 209 3.2. Capability Control Message Option 211 0 1 2 3 212 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 213 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 214 | Type = TODO | Option Length | Capabilities TLVs 215 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 217 Figure 1: Capabilities Option 219 Multiple capabilities could be sent in the same message. The length 220 field allows the message parser to skip the capability TLV parsing. 222 0 1 2 3 223 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 224 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 225 | CAPType |J|I|G|C|.|.|.|.| CAPInfo(Opt) 226 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 228 Figure 2: Capabilities TLV 230 Every capability is identified by its type and it may have an 231 optional Capability Info. Note that a given capability may or may 232 not be diseminated with additional information depending on the scope 233 of the capability indicated by the I bit. 235 J = Join only as leaf if capability not understood 237 I = Capability Info present 239 C = Flag indicating that the capability MUST be copied in the 240 downstream messages 241 G = If set indicates a Global Capability else its a local. For a 242 capability if it's mandatory and global bit is set then node those 243 either doesn't understand the capability or doesn't have this 244 capability should not join the DODAG as a router. All the global 245 capablities MUST be diseminated across the network. 6LRs in the 246 network MUST copy the global capabilities in their DIOs. 248 0 1 2 3 249 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 250 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 251 | CAPLen | Cap Info(format decided by individual cap spec) 252 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 254 Figure 3: Capabilities Info 256 Capability Information provides additional information for the given 257 capability. The format of this field should be defined as part the 258 individual capability specification and is beyond the scope of this 259 document. This document provides a container format for carrying the 260 capability and its context information. 262 3.3. Capabilities Handshake 264 The root node could advertise the set of capabilities it supports in 265 the DIO message. A node could take advantage of the knowledge that 266 the root supports a particular capability. Similarly a node could 267 advertise its capabilities in the DAO message using the capability 268 control message option defined in this document. Capabilities 269 advertised by non-root nodes are strictly a subset of the 270 capabilities advertised by the root. 272 In storing MOP, the DAO message from the 6LR could contain multiple 273 target options because of the DAO-Aggregation. The targets of the 274 capabilities option are indicated by one or more Target options that 275 precede the Capabilties Option. This handling is similar to the 276 Transit Information Option as supported in Section 6.7.8. of 277 [RFC6550]. 279 4. Guidelines for defining new capabilities 281 This section provides guidelines/recommendations towards defining new 282 capabilities. Note that the capabilities might be carried as part of 283 the multicast messaging such as DIO and hence the set should be used 284 in restrictive manner as far as possible. 286 4.1. Handling Capability flags 288 The 'G' (global) flag indicating global capability should be set only 289 by the root. However, it is not mandatory for the root to set this 290 flag for all capabilities it indicates. It should set this flag only 291 for those capabilities which the 6LRs downstream must propagate 292 further downstream. 294 The 'I' (information) flag is set only when there is additional 295 information to be set in context to the capability. 297 The 'J' (join) flag can be set in context to a capability either by a 298 6LR or the root. The 'J' flag indicates that if the capability is 299 not supported by a node then it can join the instance only as a 6LN 300 (or do not join as 6LR). 302 The 'C' (copy) flag is set by the node indicating that the 303 capabilities MUST be copied downstream by the node. 305 4.1.1. Rules to handle capabilities flag 306 On receiving a capability it does not support, the node MUST check 307 the 'J' flag of the capability before joining the Instance. If the 308 'J' flag is set then it can only join as a 6LN. 309 If the node is operating as 6LR and subsequently it receives a 310 capability which it doesn't understand with 'J' flag set, then the 311 node has to switch itself to 6LN mode. During switching the node 312 needs to inform its downstream peers of its changed status by sending 313 a DIO with infinite rank as mentioned in [RFC6550]. 314 Capabilities are used to indicate a feature that is supported by the 315 node. Capabilities are not meant for configuration management for 316 e.g., setting a threshold./>. 318 5. ROLL Capabilities 320 5.1. Capability Indicators 322 Capability Indicators indicates the capabilities supported by the 323 node in the form of simple flags. Capabilities who do not have 324 additional information to be specified could make use of these flags 325 to indicate their support. 327 5.1.1. Format of Capability Indicators 328 0 1 2 3 329 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 330 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 331 | Type=0x01 |J|I|G|C|. . . .| Len=3 |. . . . . Indic| 332 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 333 |ators . . . . . . . . . . . .|T| 334 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 336 Figure 4: Capability Indicators TLV 338 Flags: LRs MUST set it to 0. I bit will always be set to 0. 340 24-bit Indicators: Currently right most bit is used to indicate 'T' 341 bit indicating support for 6LoRH. All the unused Indicator bits MUST 342 be set to zero. 344 5.2. Routing Resource Capability 346 Storing mode of operation requires each intermediate router in the 347 LLN to maintain routing states' information in the routing table. 348 LLN routers typically operate with constraints on processing power, 349 memory, and energy (battery power). Memory limits the number of 350 routing states an LR and BR can maintain. When the routing table of 351 an LR or BR is full, it will either reject the new DAO messages 352 received or will use some replacement policy to remove a routing 353 entry and add the new one. Rejection of DAO messages will lead to an 354 increase in DAO message transmission that impacts the energy and 355 network convergence time. Routing state replacement leads to 356 downward path downtime. 358 One possible way to solve problems due to routing table size 359 constraint is to use this information to add neighbors to the DAO 360 parent set.Routing resource capability can be used by LR and BR to 361 advertise their current routing table usage details in the network. 362 LR or LNs in LLN can use this information in the selection of the DAO 363 parent set. PCE can use this information to select intermediate 364 routers for the projected routes. Routing Resource is an optional 365 local capability. 367 Routing reource capability TLV can occur multiple times in the 368 capability control message option to advertise below possible routing 369 table information. 371 I: Master Routing Table Storing 373 II: Storing mode P-DAO Table 375 III: Non-Storing mode P-DAO 376 Routing resource capabablity sent in DIO message has link local scope 377 and it MUST not be forwarded. 379 5.2.1. Format of Routing Resource Capability 381 0 1 2 3 382 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 383 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 384 | Type=0x03 |J|I|G|C|. . . .| CAPLen | Reserved | 385 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 386 | Total Capacity | 387 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 389 Figure 5: Routing Resource Capability TLV 391 Type: 0x03. 393 Flags: G bit MUST be set to 0. I bit will always be set to 1. 395 CAPLen: 8-bit unsigned integer, representing the length in octets of 396 the option, not including the Option Type and Length fields. 398 Resvd: 8-bit unused field. It MUST be initialized to zero by the 399 sender and MUST be ignored by the receiver. 401 Total Capacity: 16 bit unsigned integer representing the the routing 402 table size. 404 6. Acknowledgements 406 Thanks to Georgios Papadopoulos, Li Zhao for early review and 407 feedback. 409 7. IANA Considerations 411 7.1. New option: Capabilities 413 New entry is required for supporting new Capabilities option in the 414 "RPL Control Message Options" space [RFC6550]. 416 +-------+--------------+---------------+ 417 | Value | Meaning | Reference | 418 +-------+--------------+---------------+ 419 | TBD1 | Capabilities | This document | 420 +-------+--------------+---------------+ 422 New options 424 7.2. New Registry for Capabilities Flags 426 IANA is requested to create a registry for the Capabilities flags as 427 described in Section 2.1 of this document. This registry should be 428 located in TODO. New Capabilities flags may be allocated only by an 429 IETF review. Currently no flags are defined by this document. Each 430 value is tracked with the following qualities: 432 o Flag 434 o Description 436 o Defining RFC 438 7.3. New Registry for Capabilities Indicators 440 IANA is requested to create a registry for the Capabilities 441 Indicators as described in Section 5.1 of this document. This 442 registry should be located in TODO. New Capabilities indicators may 443 be allocated only by an IETF review. Each value is tracked with the 444 following qualities: 446 o Flag 448 o Description 450 o Defining RFC 452 8. Security Considerations 454 The options defined in this document are carried in the base message 455 objects as defined in [RFC6550]. The RPL control message options are 456 protected by the same security mechanisms that protect the base 457 messages. 459 Capabilities flag can reveal that the node has been upgraded or is 460 running a old feature set. This document assumes that the base 461 messages that carry these options are protected by RPL security 462 mechanisms and thus are not visible to a malicious node. 464 [TODO] implications of malicious attack involving setting the 465 capability flags. 467 9. References 468 9.1. Normative References 470 [I-D.ietf-roll-dao-projection] 471 Thubert, P., Jadhav, R., and M. Gillmore, "Root initiated 472 routing state in RPL", draft-ietf-roll-dao-projection-09 473 (work in progress), November 2019. 475 [I-D.thubert-roll-turnon-rfc8138] 476 Thubert, P. and L. Zhao, "Configuration option for RFC 477 8138", draft-thubert-roll-turnon-rfc8138-03 (work in 478 progress), July 2019. 480 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 481 Requirement Levels", BCP 14, RFC 2119, 482 DOI 10.17487/RFC2119, March 1997, 483 . 485 [RFC6550] Winter, T., Ed., Thubert, P., Ed., Brandt, A., Hui, J., 486 Kelsey, R., Levis, P., Pister, K., Struik, R., Vasseur, 487 JP., and R. Alexander, "RPL: IPv6 Routing Protocol for 488 Low-Power and Lossy Networks", RFC 6550, 489 DOI 10.17487/RFC6550, March 2012, 490 . 492 [RFC8138] Thubert, P., Ed., Bormann, C., Toutain, L., and R. Cragie, 493 "IPv6 over Low-Power Wireless Personal Area Network 494 (6LoWPAN) Routing Header", RFC 8138, DOI 10.17487/RFC8138, 495 April 2017, . 497 9.2. Informative References 499 [I-D.ietf-lwig-nbr-mgmt-policy] 500 Jadhav, R., Sahoo, R., Duquennoy, S., and J. Eriksson, 501 "Neighbor Management Policy for 6LoWPAN", draft-ietf-lwig- 502 nbr-mgmt-policy-03 (work in progress), February 2019. 504 [I-D.ietf-roll-mopex] 505 Jadhav, R., Thubert, P., and M. Richardson, "Mode of 506 Operation extension", draft-ietf-roll-mopex-00 (work in 507 progress), April 2020. 509 [RFC6551] Vasseur, JP., Ed., Kim, M., Ed., Pister, K., Dejean, N., 510 and D. Barthel, "Routing Metrics Used for Path Calculation 511 in Low-Power and Lossy Networks", RFC 6551, 512 DOI 10.17487/RFC6551, March 2012, 513 . 515 Appendix A. Capability Handshake Example 517 Root 6LR 6LN 518 | | | 519 | DIO(CS1) | | 520 |------------>| DIO(CS1) | 521 | |----------->| 522 | | | 523 | | DAO(CS2) | 524 | |<-----------| 525 | DAO(CS2) | | 526 |<------------| | 527 | | | 528 CS: Capabilities Set 529 CS1: Capabilities set advertised by root 530 CS2: Capabilities set advertised by node. CS2 is a subset of CS1. 532 Figure 6: Capabilities Option 534 Authors' Addresses 536 Rahul Arvind Jadhav (editor) 537 Huawei Tech 538 Kundalahalli Village, Whitefield, 539 Bangalore, Karnataka 560037 540 India 542 Phone: +91-080-49160700 543 Email: rahul.ietf@gmail.com 545 Pascal Thubert 546 Cisco Systems, Inc 547 Building D 548 45 Allee des Ormes - BP1200 549 MOUGINS - Sophia Antipolis 06254 550 France 552 Phone: +33 497 23 26 34 553 Email: pthubert@cisco.com 555 Michael Richardson 556 Sandelman Software Works 558 Email: mcr+ietf@sandelman.ca 559 Rabi Narayan Sahoo (editor) 561 Email: rabinarayans0828@gmail.com