idnits 2.17.00 (12 Aug 2021) /tmp/idnits1555/draft-birkholz-yang-push-coap-problemstatement-00.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 : ---------------------------------------------------------------------------- ** The document seems to lack an Introduction section. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (October 18, 2017) is 1669 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Outdated reference: draft-ietf-anima-bootstrapping-keyinfra has been published as RFC 8995 == Outdated reference: A later version (-10) exists of draft-ietf-core-coap-pubsub-02 == Outdated reference: draft-ietf-core-coap-tcp-tls has been published as RFC 8323 == Outdated reference: A later version (-11) exists of draft-ietf-core-comi-01 == Outdated reference: A later version (-18) exists of draft-ietf-core-sid-01 == Outdated reference: A later version (-20) exists of draft-ietf-core-yang-cbor-05 == Outdated reference: draft-ietf-netconf-subscribed-notifications has been published as RFC 8639 == Outdated reference: draft-ietf-netconf-yang-push has been published as RFC 8641 == Outdated reference: draft-ietf-netconf-zerotouch has been published as RFC 8572 == Outdated reference: A later version (-04) exists of draft-vanderstok-ace-coap-est-02 ** Obsolete normative reference: RFC 7049 (Obsoleted by RFC 8949) Summary: 2 errors (**), 0 flaws (~~), 11 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 SACM Working Group H. Birkholz 3 Internet-Draft Fraunhofer SIT 4 Intended status: Informational T. Zhou 5 Expires: April 21, 2018 Huawei 6 X. Liu 7 Jabil 8 E. Voit 9 Cisco Systems 10 October 18, 2017 12 YANG Push Operations for CoMI 13 draft-birkholz-yang-push-coap-problemstatement-00 15 Abstract 17 This document provides a problem statement, derives an initial gap 18 analysis and illustrates a first set of solution approaches in regard 19 to augmenting YANG data stores based on the CoAP Management Interface 20 with YANG Push capabilities. A binary transfer mechanism for YANG 21 Subscribed Notifications addresses both the requirements of 22 constrained-node networks and the need for semantic interoperability 23 via self-descriptiveness of the corresponding data in motion. 25 Status of This Memo 27 This Internet-Draft is submitted in full conformance with the 28 provisions of BCP 78 and BCP 79. 30 Internet-Drafts are working documents of the Internet Engineering 31 Task Force (IETF). Note that other groups may also distribute 32 working documents as Internet-Drafts. The list of current Internet- 33 Drafts is at https://datatracker.ietf.org/drafts/current/. 35 Internet-Drafts are draft documents valid for a maximum of six months 36 and may be updated, replaced, or obsoleted by other documents at any 37 time. It is inappropriate to use Internet-Drafts as reference 38 material or to cite them other than as "work in progress." 40 This Internet-Draft will expire on April 21, 2018. 42 Copyright Notice 44 Copyright (c) 2017 IETF Trust and the persons identified as the 45 document authors. All rights reserved. 47 This document is subject to BCP 78 and the IETF Trust's Legal 48 Provisions Relating to IETF Documents 49 (https://trustee.ietf.org/license-info) in effect on the date of 50 publication of this document. Please review these documents 51 carefully, as they describe your rights and restrictions with respect 52 to this document. Code Components extracted from this document must 53 include Simplified BSD License text as described in Section 4.e of 54 the Trust Legal Provisions and are provided without warranty as 55 described in the Simplified BSD License. 57 Table of Contents 59 1. Context of the Problem . . . . . . . . . . . . . . . . . . . 2 60 1.1. Binary YANG transfer protocol . . . . . . . . . . . . . . 3 61 1.2. Device-Type Scope . . . . . . . . . . . . . . . . . . . . 3 62 1.3. Subscriptions via CoAP . . . . . . . . . . . . . . . . . 3 63 1.4. Configured Subscriptions and Call-Home . . . . . . . . . 4 64 1.5. Bootstrapping of Drop-Shipped Pledges . . . . . . . . . . 4 65 2. Summary of the Problem Statement . . . . . . . . . . . . . . 5 66 3. Potential Approaches and Solutions . . . . . . . . . . . . . 6 67 3.1. YANG subscription variants . . . . . . . . . . . . . . . 6 68 3.2. YANG Push via CoAP . . . . . . . . . . . . . . . . . . . 6 69 3.3. Dynamic Subscriptions . . . . . . . . . . . . . . . . . . 7 70 3.3.1. YANG Push via GET . . . . . . . . . . . . . . . . . . 7 71 3.3.2. YANG Push via FETCH . . . . . . . . . . . . . . . . . 7 72 3.4. Configured Subscriptions . . . . . . . . . . . . . . . . 7 73 3.4.1. Retaining the Content of a GET Operation as 74 Configuration . . . . . . . . . . . . . . . . . . . . 7 75 3.4.2. Call Home via CoAP . . . . . . . . . . . . . . . . . 8 76 3.4.3. Dynamic Home Discovery . . . . . . . . . . . . . . . 8 77 4. IANA considerations . . . . . . . . . . . . . . . . . . . . . 8 78 5. Security Considerations . . . . . . . . . . . . . . . . . . . 8 79 6. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 8 80 7. Change Log . . . . . . . . . . . . . . . . . . . . . . . . . 8 81 8. Normative References . . . . . . . . . . . . . . . . . . . . 8 82 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 10 84 1. Context of the Problem 86 A binary transfer capability for YANG Subscribed Notifications 87 [I-D.ietf-netconf-subscribed-notifications] based on YANG Push 88 [I-D.ietf-netconf-yang-push] can be realized by using existing RFC 89 and I-D work as building blocks. This section is intended to provide 90 a corresponding overview of the existing ecosystem in order to 91 identify gaps and therefore provide a problem statement. 93 1.1. Binary YANG transfer protocol 95 The CoAP Management Interface I-D (CoMI [I-D.ietf-core-comi]) defines 96 operations for a YANG data store based on the Constrained Application 97 Protocol (CoAP [RFC7252]). CoAP uses a request/response interaction 98 model that is based on HTTP (similar to RESTCONF [RFC8040]) and 99 allows for multiple transports, including UDP or TCP (see 100 [I-D.ietf-core-coap-tcp-tls]). The Concise Binary Object 101 Representation (CBOR [RFC7049]) is used for the serialization of data 102 in motion in respect to CoAP operations and the data modeled with 103 YANG [I-D.ietf-core-yang-cbor]. 105 1.2. Device-Type Scope 107 [I-D.ietf-core-comi] states that CoAP "is designed for Machine to 108 Machine (M2M) applications such as smart energy, smart city and 109 building control. Constrained devices need to be managed in an 110 automatic fashion to handle the large quantities of devices that are 111 expected in future installations. Messages between devices need to 112 be as small and infrequent as possible. The implementation 113 complexity and runtime resources need to be as small as possible." 115 In addition, [I-D.ietf-core-comi] highlights that "CoMI and RESTCONF 116 are intended to work in a stateless client-server fashion. They use 117 a single round-trip to complete a single editing transaction, where 118 NETCONF needs up to 10 round trips. To promote small messages, CoMI 119 uses a YANG to CBOR mapping [I-D.ietf-core-yang-cbor] and numeric 120 identifiers [I-D.ietf-core-sid] to minimize CBOR payloads and URI 121 length." 123 In essence, via CoMI, a small sensor can emit a set of measurements 124 as binary encoded YANG notifications, which would only add a minimal 125 overhead to the data in motion, but would increase interoperability 126 significantly due to the powerful and widely used semantics enabled 127 by YANG (in contrast to a set of raw values that always require 128 additional context information and imperative guidance to be managed 129 and post-processed appropriately). 131 1.3. Subscriptions via CoAP 133 The CoAP pub/sub I-D defines a CoAP Subscribe operation 134 [I-D.ietf-core-coap-pubsub] that is based on observing resources via 135 the Observe option for the GET operation as defined in [RFC7641]. 136 The CoAP pub/sub draft is intended to provide the capabilities and 137 characteristics of MQTT via a CoAP based protocol. The only other 138 CoAP operation that supports the Observe option is the FETCH 139 operation defined in [RFC8132]. 141 The Observe option creates a small corresponding state on the server 142 side that eliminates the need for continuous polling of a resource 143 via subsequent requests. Instead, subsequent responses including 144 both the Observe option and using the token of the request that 145 initiated the observation are returned when the observed resource 146 changes. A subscription (i.e. the observe state retained on the 147 server) can be discarded by the client by sending a correspond CoAP 148 GET with Observe using an Observe parameter of 1 or simply by 149 "forgeting" the observation and return a CoAP Reset after receiving a 150 notification in the context of the subscription. A subscription can 151 also be discarded by the server by sending a corresponding response 152 that does not contain an Observe option. 154 The subscription used in CoAP pub/sub are used to subscribe to a 155 topic provided by a CoAP broker REST API. YANG Push 156 [I-D.ietf-netconf-yang-push] and corresponding YANG Subscribed 157 Notifications are used to subscribe to data node updates provided by 158 a YANG management interface. YANG subscriptions can include a filter 159 expression (either a subtree expression or an XPATH expression). The 160 encoding rules of XPATH expressions in CBOR are covered by 161 [I-D.ietf-core-yang-cbor]. 163 1.4. Configured Subscriptions and Call-Home 165 Configured subscriptions are basically static configuration that 166 creates subscription state on the YANG data store when it is started 167 and persists between boot-cycles without the need of a client to 168 create that subscription state. In consequence, a configured 169 subscription can result in unsolicited pushed notifications in 170 respect to a YANG client. 172 A popular variant of the configured subscription as defined in 173 [I-D.ietf-netconf-yang-push] is the Call Home procedure defined in 174 [RFC8071]. In this approach, a Transport Layer application 175 association with the YANG client is initiated by the YANG data store. 176 After this "initial phase, in which the YANG server is acting like a 177 client", the existing Transport Layer connection (or session, in case 178 of, for example, TLS) is then used to the YANG client to initiate a 179 subscription (i.e. the YANG client is initiating a dynamic 180 subscription based on a pre-configured request retained and issued by 181 the YANG data store). 183 1.5. Bootstrapping of Drop-Shipped Pledges 185 [I-D.ietf-anima-bootstrapping-keyinfra] highlights that effectively 186 "to literally 'pull yourself up by the bootstraps' is an impossible 187 action. Similarly, the secure establishment of a key infrastructure 188 without external help is also an impossibility." 189 According to [I-D.ietf-anima-bootstrapping-keyinfra] the 190 bootstrapping approach Call-Home has problems and limitations, which 191 (amongst others) the draft itself is trying to address: 193 o the pledge requires realtime connectivity to the vendor service 195 o the domain identity is exposed to the vendor service (this is a 196 privacy concern) 198 o the vendor is responsible for making the authorization decisions 199 (this is a liability concern) 201 A Pledge in the context of [I-D.ietf-anima-bootstrapping-keyinfra] is 202 "the prospective device, which has an identity installed by a third- 203 party (e.g., vendor, manufacturer or integrator)." 205 A Pledge can be "drop-shipped", which refers to "the physical 206 distribution of equipment containing the 'factory default' 207 configuration to a final destination. In zero-touch scenarios there 208 is no staging or pre-configuration during drop-ship." 210 In the scope of Call-Home as a part of YANG Push, either the factory 211 default configuration of a drop-shipped Pledge that is a YANG data 212 store would require to include the "home to Call Home" configuration 213 or it has to be configured locally. 215 [I-D.ietf-netconf-zerotouch] is intended to provide more flexibility 216 to the Call-Home procedure already - by allowing to stage connection 217 attempts to a locally administered network and if that fails fall 218 back to connecting to a remotely administered network. Alas, 219 [I-D.ietf-netconf-zerotouch] is either prone to the same limitations 220 as cited above or requires local configuration in order to find the 221 home to Call-Home. 223 The "Join Registrar" defined by 224 [I-D.ietf-anima-bootstrapping-keyinfra] mitigates the cited problems 225 and limitation by introducing "a representative of the domain that is 226 configured, perhaps autonomically, to decide whether a new device is 227 allowed to join the domain. The administrator of the domain 228 interfaces with a Join Registrar (and Coordinator) to control this 229 process. Typically a Join Registrar is "inside" its domain." 231 2. Summary of the Problem Statement 233 Currently, the following gaps are identified: 235 o no CoAP Subscribe procedure for dynamic YANG subscriptions is 236 standardized that is able to convey a filter expression and 237 potentially other metadata required in the context of a YANG 238 Subscribed Notifications application association. Analogously, 239 new payload types (e.g. a FETCH payload media-type) have to be 240 defined. 242 o no CoAP Call Home feature is standardized to support a popular 243 variant of configured YANG subscriptions. 245 o no general Call Home mechanism is standardized that enables the 246 discovery of "a home to Call Home" or that would be able to deal 247 with "changing homes" in a dynamic but secure manner. 249 In addition to the identified gaps, the semantics of metadata - if 250 there are any - that have to be conveyed to or from a YANG data store 251 in order to subscribe to a (filtered) YANG module or data node are 252 not identified. 254 The problem statement could be summarized as follows: 256 "There is no complete solution based on CoAP to enable a freshly 257 unpacked YANG data store ("drop-shipped pledge", e.g. the cliche 258 light bulb) to discover an appropriate home it can than Call-Home to 259 in a secure and trusted manner in order to push (un-)solicited 260 subscribed notifications." 262 3. Potential Approaches and Solutions 264 There are multiple approaches that could lead to viable solutions 265 that address the identified gaps. The following sections illustrate 266 the general solution context and some of the most promising 267 approaches. 269 3.1. YANG subscription variants 271 A YANG Push update subscription service both provides support for 272 dynamic subscription (i.e. subscription state created by a client 273 request, allowing for solicited push notifications in the context of 274 an up-time cycle of the server) and configured subscription (i.e. 275 subscription configuration retained on the server, allowing for 276 unsolicited push notifications across up-time cycles of the server). 278 3.2. YANG Push via CoAP 280 The two CoAP operations that enable a subscription mechanism are GET 281 and FETCH (i.e. by supporting the Observe option). Both operations 282 are viable candidates for creating a CoAP-based YANG Push mechanism 283 for CoMI. 285 3.3. Dynamic Subscriptions 287 Using CoAP, the client issuing the initial subscription request 288 creates the subscription state. Examples are the GET or FETCH 289 operation including an Observe option using an Observe parameter of 0 290 (zero). 292 3.3.1. YANG Push via GET 294 This usage scenario requires two consecutive operations. It is not 295 possible to transfer a filter expression included in a GET operation. 296 In consequence, a POST operation on a collection resource has to be 297 conducted in order to convey a filter expression to the YANG data 298 store, allowing it to return an URI that contains the data node 299 information filtered in respect to the posted filter expression 300 (encoded in CBOR). 302 This variant allows for multiple clients to observe a specific 303 filtered data node without conducting a POST operation, if the 304 corresponding URI is made known to other clients that did not conduct 305 the POST operation or, for example, is canonically linked to/ 306 derivable from a filter expression. 308 3.3.2. YANG Push via FETCH 310 This usage scenario requires only one operation. A FETCH operation 311 can include a body that is capable to contain a filter expression and 312 potentially other metadata that might be required to establish a 313 suitable subscription state on the YANG data store. 315 It might be possible that this variant could introduce a slight delay 316 in respect to response time if providing a filtered resource requires 317 a lot of computation time on a constrained device. I.e. the resource 318 cannot be prepared "beforehand". 320 3.4. Configured Subscriptions 322 Using CoAP, the server retains configuration that creates 323 subscription state when the YANG data store is started. The client 324 has to have or gain knowledge of the CoAP tokens that are included in 325 the responses created in the context of the subscription state create 326 from server configuration. 328 3.4.1. Retaining the Content of a GET Operation as Configuration 330 This usage scenario "mimics" the receiving of a subscription request 331 by storing the corresponding information that are relevant for 332 creating a subscription state as configuration on the YANG data 333 store. I.e. the configuration would be including the YANG client IP 334 address and the CoAP token to be used in the responses that convey 335 the subscribed notifications. 337 This variant requires that the client also knows or gains knowledge 338 of the corresponding CoAP token in order to not discard the incoming 339 responses. 341 3.4.2. Call Home via CoAP 343 This usage scenario defines the Call Home procedure standardized in 344 [RFC8071] as an additional capability of CoAP. DTLS or TLS state is 345 initiated by the YANG data store and triggers a dynamic subscription 346 procedure of the YANG client using the session initiated by the YANG 347 data store. 349 3.4.3. Dynamic Home Discovery 351 This usage scenario is based on the Bootstrapping Remote Secure Key 352 Infrastructures I-D [I-D.ietf-anima-bootstrapping-keyinfra] and EST 353 over secure CoAP I-D [I-D.vanderstok-ace-coap-est] and requires the 354 standardization of a general use of Join Registrars in the context of 355 YANG data stores that support YANG Push via static subscriptions. 357 4. IANA considerations 359 This document includes no requests to IANA, but solutions drafts 360 incubated via this document might. 362 5. Security Considerations 364 This document includes no security considerations, but solution 365 drafts incubated via this document will. 367 6. Acknowledgements 369 Carsten Bormann, Klaus Hartke, Michel Veillette 371 7. Change Log 373 First version -00 375 8. Normative References 377 [I-D.ietf-anima-bootstrapping-keyinfra] 378 Pritikin, M., Richardson, M., Behringer, M., Bjarnason, 379 S., and K. Watsen, "Bootstrapping Remote Secure Key 380 Infrastructures (BRSKI)", draft-ietf-anima-bootstrapping- 381 keyinfra-08 (work in progress), October 2017. 383 [I-D.ietf-core-coap-pubsub] 384 Koster, M., Keranen, A., and J. Jimenez, "Publish- 385 Subscribe Broker for the Constrained Application Protocol 386 (CoAP)", draft-ietf-core-coap-pubsub-02 (work in 387 progress), July 2017. 389 [I-D.ietf-core-coap-tcp-tls] 390 Bormann, C., Lemay, S., Tschofenig, H., Hartke, K., 391 Silverajan, B., and B. Raymor, "CoAP (Constrained 392 Application Protocol) over TCP, TLS, and WebSockets", 393 draft-ietf-core-coap-tcp-tls-09 (work in progress), May 394 2017. 396 [I-D.ietf-core-comi] 397 Veillette, M., Stok, P., Pelov, A., and A. Bierman, "CoAP 398 Management Interface", draft-ietf-core-comi-01 (work in 399 progress), July 2017. 401 [I-D.ietf-core-sid] 402 Veillette, M., Pelov, A., Turner, R., Minaburo, A., and A. 403 Somaraju, "YANG Schema Item iDentifier (SID)", draft-ietf- 404 core-sid-01 (work in progress), May 2017. 406 [I-D.ietf-core-yang-cbor] 407 Veillette, M., Pelov, A., Somaraju, A., Turner, R., and A. 408 Minaburo, "CBOR Encoding of Data Modeled with YANG", 409 draft-ietf-core-yang-cbor-05 (work in progress), August 410 2017. 412 [I-D.ietf-netconf-subscribed-notifications] 413 Voit, E., Clemm, A., Prieto, A., Nilsen-Nygaard, E., and 414 A. Tripathy, "Custom Subscription to Event Notifications", 415 draft-ietf-netconf-subscribed-notifications-05 (work in 416 progress), October 2017. 418 [I-D.ietf-netconf-yang-push] 419 Clemm, A., Voit, E., Prieto, A., Tripathy, A., Nilsen- 420 Nygaard, E., Bierman, A., and B. Lengyel, "Subscribing to 421 YANG datastore push updates", draft-ietf-netconf-yang- 422 push-10 (work in progress), October 2017. 424 [I-D.ietf-netconf-zerotouch] 425 Watsen, K., Abrahamsson, M., and I. Farrer, "Zero Touch 426 Provisioning for NETCONF or RESTCONF based Management", 427 draft-ietf-netconf-zerotouch-17 (work in progress), 428 September 2017. 430 [I-D.vanderstok-ace-coap-est] 431 Kumar, S., Stok, P., Kampanakis, P., Furuhed, M., and S. 432 Raza, "EST over secure CoAP (EST-coaps)", draft- 433 vanderstok-ace-coap-est-02 (work in progress), June 2017. 435 [RFC7049] Bormann, C. and P. Hoffman, "Concise Binary Object 436 Representation (CBOR)", RFC 7049, DOI 10.17487/RFC7049, 437 October 2013, . 439 [RFC7252] Shelby, Z., Hartke, K., and C. Bormann, "The Constrained 440 Application Protocol (CoAP)", RFC 7252, 441 DOI 10.17487/RFC7252, June 2014, 442 . 444 [RFC7641] Hartke, K., "Observing Resources in the Constrained 445 Application Protocol (CoAP)", RFC 7641, 446 DOI 10.17487/RFC7641, September 2015, 447 . 449 [RFC8040] Bierman, A., Bjorklund, M., and K. Watsen, "RESTCONF 450 Protocol", RFC 8040, DOI 10.17487/RFC8040, January 2017, 451 . 453 [RFC8071] Watsen, K., "NETCONF Call Home and RESTCONF Call Home", 454 RFC 8071, DOI 10.17487/RFC8071, February 2017, 455 . 457 [RFC8132] van der Stok, P., Bormann, C., and A. Sehgal, "PATCH and 458 FETCH Methods for the Constrained Application Protocol 459 (CoAP)", RFC 8132, DOI 10.17487/RFC8132, April 2017, 460 . 462 Authors' Addresses 464 Henk Birkholz 465 Fraunhofer SIT 466 Rheinstrasse 75 467 Darmstadt 64295 468 Germany 470 Email: henk.birkholz@sit.fraunhofer.de 471 Tianran Zhou 472 Huawei 473 156 Beiqing Rd. 474 Beijing, Haidian District 475 China 477 Email: zhoutianran@huawei.com 479 Xufeng Liu 480 Jabil 481 8281 Greensboro Drive, Suite 200 482 McLean VA 22102 483 USA 485 Email: Xufeng_Liu@jabil.com 487 Eric Voit 488 Cisco Systems 490 Email: evoit@cisco.com