idnits 2.17.1 draft-jholland-taps-api-yang-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 : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year == Line 147 has weird spacing: '...ference pre...' == Line 150 has weird spacing: '...ference pre...' -- The document date (July 07, 2019) is 1748 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) == Unused Reference: 'RFC6991' is defined on line 830, but no explicit reference was found in the text == Unused Reference: 'RFC8343' is defined on line 846, but no explicit reference was found in the text == Outdated reference: A later version (-19) exists of draft-ietf-taps-arch-03 == Outdated reference: A later version (-26) exists of draft-ietf-taps-interface-03 Summary: 0 errors (**), 0 flaws (~~), 7 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Taps J. Holland 3 Internet-Draft Akamai Technologies, Inc. 4 Intended status: Standards Track July 07, 2019 5 Expires: January 8, 2020 7 A YANG Data Model for a Transport Services API at Endpoints 8 draft-jholland-taps-api-yang-03 10 Abstract 12 This document defines a YANG data model that provides a data 13 structure that can be used to configure an implementation of the 14 Transport Services Interface to establish connections suitable for 15 sending and receiving data over the internet or local networks. This 16 document is intended to supplement or merge with draft-ietf-taps- 17 interface. 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 January 8, 2020. 36 Copyright Notice 38 Copyright (c) 2019 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. A Note On The Use Of YANG . . . . . . . . . . . . . . . . 3 55 2. Tree Diagram . . . . . . . . . . . . . . . . . . . . . . . . 3 56 3. Examples . . . . . . . . . . . . . . . . . . . . . . . . . . 4 57 3.1. Basic Client Connection . . . . . . . . . . . . . . . . . 4 58 3.2. Customized Connections . . . . . . . . . . . . . . . . . 5 59 3.2.1. Require Wi-Fi . . . . . . . . . . . . . . . . . . . . 5 60 3.3. Send and Receive Multicast . . . . . . . . . . . . . . . 6 61 3.4. Connecting Through a Stun Server . . . . . . . . . . . . 8 62 4. YANG Module . . . . . . . . . . . . . . . . . . . . . . . . . 9 63 5. Security Considerations . . . . . . . . . . . . . . . . . . . 18 64 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 19 65 7. Normative References . . . . . . . . . . . . . . . . . . . . 19 66 Appendix A. Future Work . . . . . . . . . . . . . . . . . . . . 20 67 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 20 69 1. Introduction 71 This document is an attempt to concretize the properties and objects 72 of the TAPS interface described in [I-D.ietf-taps-interface], under 73 the architecture described in [I-D.ietf-taps-arch]. 75 A TAPS-compliant implementation SHOULD provide a language-appropriate 76 way to configure a PreConnection using YANG instance data for this 77 model, and SHOULD provide an API that outputs the YANG instance data 78 for an established Connection. 80 An implementation MAY also provide appropriate APIs for directly 81 editing the objects without using YANG. It's RECOMMENDED where 82 possible to use names that mechanically translate to the names in the 83 YANG data model, using capitalization and punctuation conventions as 84 expected for the language of the implementation. 86 Non-TAPS extensions to API objects that directly edit TAPS properties 87 are RECOMMENDED to include "ext", "EXT", or "Ext" as a prefix to any 88 extension properties or methods, to avoid colliding with future TAPS 89 extensions. 91 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 92 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 93 "OPTIONAL" in this document are to be interpreted as described in BCP 94 14 [RFC2119] [RFC8174] when, and only when, they appear in all 95 capitals, as shown here. 97 1.1. A Note On The Use Of YANG 99 Although YANG was originally designed to model data for NETCONF, YANG 100 can be used in other ways as well, as described by Section 4.1 of 101 [RFC7950]. 103 This usage is not primarily targeted at NETCONF, but rather at 104 Application Programming Interfaces for libraries that set up 105 connections for sending and receiving data over the internet. 106 However, use of YANG in this context provides a semantically clear, 107 well defined, extensible, cross-platform method for configuring 108 connection objects suitable for replacing BSD sockets in a wide 109 variety of applications. 111 2. Tree Diagram 113 Tree diagrams used in this document follow the notation defined in 114 [RFC8340]. 116 module: ietf-taps-api 117 +--rw preconnection 118 +--rw local-endpoints* [id] 119 | +--rw id string 120 | +--rw local-address? inet:ip-address 121 | +--rw local-port? inet:port-number 122 | +--rw stun-info 123 | +--rw host? inet:host 124 | +--rw port? inet:port-number 125 | +--rw identity? string 126 | +--rw trust-ca? string 127 | +--rw algorithm? identityref 128 | +--rw pre-shared-key? string 129 | +--rw private-key? string 130 | +--rw private-key-callback-handle? string 131 | +--rw public-key? string 132 +--rw remote-endpoints* [id] 133 | +--rw id string 134 | +--rw remote-host? inet:host 135 | +--rw remote-port? inet:port-number 136 +--rw transport-properties 137 | +--rw reliability? preference-level 138 | +--rw preserve-msg-boundaries? preference-level 139 | +--rw per-message-reliability? preference-level 140 | +--rw preserve-order? preference-level 141 | +--rw zero-rtt-msg? preference-level 142 | +--rw multistreaming? preference-level 143 | +--rw per-msg-checksum-len-send? preference-level 144 | +--rw per-msg-checksum-len-recv? preference-level 145 | +--rw congestion-control? preference-level 146 | +--rw interface* [preference value] 147 | | +--rw preference preference-level 148 | | +--rw value union 149 | +--rw pvd* [preference value] 150 | | +--rw preference preference-level 151 | | +--rw value identityref 152 | +--rw multipath? preference-level 153 | +--rw direction? enumeration 154 | +--rw retransmit-notify? preference-level 155 | +--rw soft-error-notify? preference-level 156 +--rw security 157 +--rw credentials* [identity algorithm] 158 | +--rw identity string 159 | +--rw trust-ca? string 160 | +--rw algorithm identityref 161 | +--rw pre-shared-key? string 162 | +--rw private-key? string 163 | +--rw private-key-callback-handle? string 164 | +--rw public-key? string 165 +--rw session-cache-capacity? uint32 166 +--rw session-cache-lifetime? uint32 168 Tree Diagram 170 3. Examples 172 3.1. Basic Client Connection 174 The API is designed to allow defaults to fill out almost everything. 175 This example shows the minimal preconnection configuration input data 176 to open a reliable transfer to example.com, via any supported 177 reliable transport protocol on the default port or ports. 179 { 180 "ietf-taps-api:preconnection":{ 181 "remote-endpoints":[ 182 { 183 "id":"option1", 184 "remote-host":"example.com" 185 } 186 ] 187 } 188 } 190 Basic Client Connection 192 Due to the defaults recommended in (TBD: fix reference) Section 5 of 193 draft-ietf-taps-interface-02, implementations SHOULD treat this basic 194 example equivalently to the same example with the defaults explicitly 195 provided: 197 { 198 "ietf-taps-api:preconnection":{ 199 "remote-endpoints":[ 200 { 201 "id":"option1", 202 "remote-host":"example.com" 203 } 204 ], 205 "transport-properties":{ 206 "reliability":"require", 207 "preserve-order":"require", 208 "congestion-control":"require" 209 } 210 } 211 } 213 Basic Client Connection Explicitly Declaring Defaults 215 3.2. Customized Connections 217 In some cases, applications may have explicit preferences, either 218 dynamically inferred from past statistics or configured via system or 219 app preferences of some kind. 221 These examples demonstrates adding constraints on the endpoints when 222 opening a connection. 224 3.2.1. Require Wi-Fi 226 This example demonstrates an app that requires the use of a wireless 227 interface: 229 { 230 "ietf-taps-api:preconnection":{ 231 "remote-endpoints":[ 232 { 233 "id":"option1", 234 "remote-host":"example.com" 235 } 236 ], 237 "transport-properties":{ 238 "interface":[ 239 { 240 "preference":"avoid", 241 "value":"iana-if-type:capwapDot11Profile" 242 } 243 ] 244 } 245 } 246 } 248 Figure 1: Customized to require wireless. 250 3.3. Send and Receive Multicast 252 Sending to a multicast group is the same as any non-reliable, non- 253 ordered connection: 255 { 256 "ietf-taps-api:preconnection":{ 257 "local-endpoints":[ 258 { 259 "id":"option1", 260 "local-address":"192.0.2.15" 261 } 262 ], 263 "remote-endpoints":[ 264 { 265 "id":"option1", 266 "remote-host":"232.252.0.2", 267 "remote-port":"30000" 268 } 269 ], 270 "transport-properties": { 271 "congestion-control":"ignore", 272 "reliability":"ignore", 273 "preserve-order":"ignore" 274 } 275 } 276 } 278 Figure 2: PreConnection for Sending Multicast 280 Receiving multicast is similar. It may use remote-endpoint to 281 specify a source-specific multicast subscription, or exclude it to 282 specify any-source multicast. 284 { 285 "ietf-taps-api:preconnection":{ 286 "remote-endpoints":[ 287 { 288 "id":"1", 289 "remote-host":"192.0.2.15" 290 } 291 ], 292 "local-endpoints":[ 293 { 294 "id":"1", 295 "local-address":"232.252.0.2", 296 "local-port":"30000" 297 } 298 ], 299 "transport-properties": { 300 "congestion-control":"ignore", 301 "reliability":"ignore", 302 "preserve-order":"ignore", 303 "direction":"unidirection-receive" 304 } 305 } 306 } 308 Figure 3: PreConnection for Source-specific Multicast Receive 310 3.4. Connecting Through a Stun Server 312 STUN server connections are a local-endpoint property, and can be 313 configured the same way. 315 { 316 "ietf-taps-api:preconnection":{ 317 "remote-endpoints":[ 318 { 319 "id":"option1", 320 "remote-host":"example.com" 321 } 322 ], 323 "local-endpoints":[ 324 { 325 "id":"option1", 326 "stun-info":{ 327 "host":"203.0.113.4", 328 "port":"10000", 329 "identity":"user@mail.example.com", 330 "pre-shared-key":"" 331 } 332 } 333 ] 334 } 335 } 337 Figure 4: Connect through a STUN server 339 4. YANG Module 341 file ietf-taps-api@2019-07-07.yang 342 module ietf-taps-api { 343 yang-version 1.1; 345 namespace "urn:ietf:params:xml:ns:yang:ietf-taps-api"; 346 prefix "taps"; 348 import ietf-inet-types { 349 prefix "inet"; 350 reference "RFC 6991 Section 4"; 351 } 353 import ietf-interfaces { 354 prefix "if"; 355 reference "RFC 8343 Section 5"; 356 } 358 import iana-if-type { 359 prefix "ianaift"; 360 reference "RFC 7224 Section 2"; 361 } 362 organization "IETF"; 364 contact 365 "Author: Jake Holland 366 367 "; 369 description 370 "This module contains the definition for the TAPS 371 interface. 373 Copyright (c) 2018 IETF Trust and the persons identified as 374 authors of the code. All rights reserved. 376 Redistribution and use in source and binary forms, with or 377 without modification, is permitted pursuant to, and subject 378 to the license terms contained in, the Simplified BSD License 379 set forth in Section 4.c of the IETF Trust's Legal Provisions 380 Relating to IETF Documents 381 (http://trustee.ietf.org/license-info). 383 This version of this YANG module is part of 384 draft-jholland-taps-api-yang, 385 see the internet draft itself for full legal notices."; 387 revision 2019-03-09 { 388 description "Draft -01 revision."; 389 reference 390 "draft-jholland-taps-api-yang"; 391 } 393 typedef preference-level { 394 type enumeration { 395 enum require { 396 description 397 "select only options providing this property, fail otherwise"; 398 } 399 enum prefer { 400 description 401 "prefer options providing this property, proceed otherwise"; 402 } 403 enum ignore { 404 description 405 "cancel any system default preference for this property"; 406 } 407 enum avoid { 408 description 409 "prefer options not providing the property, 410 proceed otherwise"; 411 } 412 enum prohibit { 413 description 414 "select only options not proiding ths property, fail 415 otherwise"; 416 } 417 } 418 description 419 "This value represents the preference level of a property."; 420 } 422 identity transport-property-type { 423 description "Base identity for transport properties"; 424 } 426 identity provisioning-domain { 427 base transport-property-type; 428 description "Base for provisioning domain. 429 TBD: add relevant provisioning domain types"; 430 reference "RFC 7556: Multiple Provisioning Domain Architecture"; 431 } 433 identity transport-protocol { 434 base transport-property-type; 435 description "Identity for a transport selection. 436 TBD: finish the rest of the protocols in 437 https://tools.ietf.org/html/rfc8095#section-3.1 438 maybe add quic, maybe use as external augment demo. 439 note: this isn't in taps-interface, but is available in 440 e.g. NEAT-project/neat/examples/client.c"; 441 reference "Section 3 of RFC 8095: Existing Transport Protocols"; 442 } 444 identity tcp { 445 base transport-protocol; 446 description "Identity for TCP"; 447 reference "RFC 793: Transmission Control Protocol. 448 See also RFC 7414: A Roadmap for TCP Specification Documents."; 449 } 450 identity mptcp { 451 base transport-protocol; 452 description "Identity for MPTCP"; 453 reference 454 "RFC 6824: TCP Extensions for Multipath Operation"; 455 } 456 identity udp { 457 base transport-protocol; 458 description "Identity for UDP"; 459 reference "TBD"; 460 } 461 identity udp-lite { 462 base transport-protocol; 463 description "Identity for UDP-Lite"; 464 reference "TBD"; 465 } 466 identity sctp { 467 base transport-protocol; 468 description "Identity for SCTP"; 469 reference "TBD"; 470 } 471 identity dccp { 472 base transport-protocol; 473 description "Identity for DCCP"; 474 reference "TBD"; 475 } 476 identity tls { 477 base transport-protocol; 478 description "Identity for TLS"; 479 reference "TBD"; 480 } 481 identity rtp { 482 base transport-protocol; 483 description "Identity for RTP"; 484 reference "TBD"; 485 } 486 identity http { 487 base transport-protocol; 488 description "Identity for HTTP"; 489 reference "TBD"; 490 } 491 identity flute { 492 base transport-protocol; 493 description "Identity for FLUTE"; 494 reference "TBD"; 495 } 496 identity norm { 497 base transport-protocol; 498 description "Identity for NORM"; 499 reference "TBD"; 500 } 501 identity icmp { 502 base transport-protocol; 503 description "Identity for ICMP"; 504 reference "TBD"; 505 } 506 identity security-algorithm { 507 description "Base identity for security algorithms."; 508 } 510 identity cipher-suite { 511 base security-algorithm; 512 description "Base identity for security cipher suites."; 513 } 515 identity signature-algorithm { 516 base security-algorithm; 517 description "Base identity for security signature algorithms."; 518 } 520 identity ed25519 { 521 base signature-algorithm; 522 description "Identity for ED25519"; 523 } 525 identity TLS_ECDHE_ECDSA_WITH_CHACHA20_POLY1305_SHA256 { 526 base cipher-suite; 527 description "Identity for ECDHE ECDSA with ChaCha20, Poly1305, 528 and SHA256"; 529 } 531 grouping security-credentials { 532 description "security credentials"; 534 leaf identity { 535 type string; 536 description "identity for security credentials"; 537 } 539 leaf trust-ca { 540 type string; 541 description "trust-ca for security credentials"; 542 } 544 leaf algorithm { 545 type identityref { 546 base security-algorithm; 547 } 548 description "security algorithm for credentials"; 549 } 551 leaf pre-shared-key { 552 type string; 553 description "pre-shared key for security credentials"; 555 } 557 leaf private-key { 558 type string; 559 description "private key for security credentials"; 560 } 562 leaf private-key-callback-handle { 563 type string; 564 description "private key callback handle for 565 externally managed security credentials"; 566 } 568 leaf public-key { 569 type string; 570 description "public key for security credentials"; 571 } 572 } 574 container preconnection { 575 description "preconnection config for a taps connection"; 577 list local-endpoints { 578 key "id"; 579 description "list of local endpoints"; 581 leaf id { 582 type string; 583 description "id of the local endpoint"; 584 } 586 leaf local-address { 587 type inet:ip-address; 588 description "ip address of local endpoint"; 589 } 590 leaf local-port { 591 type inet:port-number; 592 description "port value of an endpoint port"; 593 } 595 container stun-info { 596 description "config for the stun server"; 598 leaf host { 599 type inet:host; 600 description "stun server host"; 601 } 602 leaf port { 603 type inet:port-number; 604 description "port number for the stun server"; 605 } 606 uses security-credentials; 607 } 608 /* TBD: multicast-subscription: source-specific */ 609 } 611 list remote-endpoints { 612 key "id"; 613 description "list of remote endpoints"; 615 leaf id { 616 type string; 617 description "id of the remote endpoint"; 618 } 620 leaf remote-host { 621 type inet:host; 622 description "host value of a remote endpoint"; 623 } 625 leaf remote-port { 626 type inet:port-number; 627 description "port value of an endpoint port"; 628 } 629 } 631 container transport-properties { 632 description "transport property constraints"; 634 leaf reliability { 635 type preference-level; 636 default "require"; 637 description "Section 5.2.1 of draft-ietf-taps-interface-03"; 638 } 640 leaf preserve-msg-boundaries { 641 type preference-level; 642 default "prefer"; 643 description "Section 5.2.2 of draft-ietf-taps-interface-03"; 644 } 646 leaf per-message-reliability { 647 type preference-level; 648 default "ignore"; 649 description "Section 5.2.3 of draft-ietf-taps-interface-03"; 650 } 651 leaf preserve-order { 652 type preference-level; 653 default "require"; 654 description "Section 5.2.4 of draft-ietf-taps-interface-03"; 655 } 657 leaf zero-rtt-msg { 658 type preference-level; 659 default "prefer"; 660 description "Section 5.2.5 of draft-ietf-taps-interface-03"; 661 } 663 leaf multistreaming { 664 type preference-level; 665 default "prefer"; 666 description "Section 5.2.6 of draft-ietf-taps-interface-03"; 667 } 669 leaf per-msg-checksum-len-send { 670 type preference-level; 671 default "ignore"; 672 description "Section 5.2.7 of draft-ietf-taps-interface-03"; 673 } 675 leaf per-msg-checksum-len-recv { 676 type preference-level; 677 default "ignore"; 678 description "Section 5.2.8 of draft-ietf-taps-interface-03"; 679 } 681 leaf congestion-control { 682 type preference-level; 683 default "require"; 684 description "Section 5.2.9 of draft-ietf-taps-interface-03"; 685 } 687 list interface { 688 key "preference value"; 689 leaf preference { 690 type preference-level; 691 description "preference for this interface or interface type"; 692 } 693 leaf value { 694 type union { 695 type identityref { 696 base "ianaift:iana-interface-type"; 697 } 698 type if:interface-ref { 699 require-instance false; 700 } 701 } 702 description "name or type of interface constraint"; 703 reference "RFC 7224 Section 2"; 704 } 706 description "Section 5.2.10 of draft-ietf-taps-interface-03"; 707 } 709 list pvd { 710 key "preference value"; 711 leaf preference { 712 type preference-level; 713 description "preference for this pvd"; 714 } 715 leaf value { 716 type identityref { 717 base "provisioning-domain"; 718 } 719 description "the provisioning domain constraint"; 720 } 722 description "Section 5.2.11 of draft-ietf-taps-interface-03"; 723 } 725 leaf multipath { 726 type preference-level; 727 default "prefer"; 728 description "Section 5.2.12 of draft-ietf-taps-interface-03"; 729 } 731 leaf direction { 732 type enumeration { 733 enum bidirectional { 734 description "Bidirectional connection"; 735 } 736 enum unidirection-send { 737 description "Unidirectional sending connection"; 738 } 739 enum unidirection-receive { 740 description "Unidirectional receiving connection"; 741 } 742 } 743 default "bidirectional"; 744 description "Section 5.2.13 of draft-ietf-taps-interface-03"; 745 } 746 leaf retransmit-notify { 747 type preference-level; 748 default "ignore"; 749 description "Section 5.2.14 of draft-ietf-taps-interface-03"; 750 } 752 leaf soft-error-notify { 753 type preference-level; 754 default "ignore"; 755 description "Section 5.2.15 of draft-ietf-taps-interface-03"; 756 } 757 } 759 container security { 760 description "Security properties for the connection"; 761 list credentials { 762 key "identity algorithm"; 764 uses security-credentials; 765 description "security credentials"; 766 } 768 leaf session-cache-capacity { 769 type uint32; 770 description "Max number of cache elements"; 771 } 772 leaf session-cache-lifetime { 773 type uint32; 774 description "Number of seconds of session cache lifetime"; 775 } 776 } 777 } 778 } 780 782 Figure 5: TAPS Interface YANG model 784 5. Security Considerations 786 This document describes a configuration system for an API that may 787 replace sockets. All security considerations applicable to socket 788 programming should be carefully considered by implementors. 790 (TBD: surely there is a sane reference, but also fill this out with 791 something less laughable. In particular, enumerate which options 792 should be privileged operations or not to preserve the security of 793 BSD sockets, such as it is. And maybe another layer of restriction 794 recommendations for sandboxed or browser systems.) 796 6. IANA Considerations 798 IANA is requested to add the YANG model in Section 4 to the yang- 799 parameters registry. 801 +-----------+-------------------------------------------+ 802 | Field | Value | 803 +-----------+-------------------------------------------+ 804 | Name | ietf-taps-api | 805 | Namespace | urn:ietf:params:xml:ns:yang:ietf-taps-api | 806 | Prefix | taps | 807 | Reference | [TBD: this document] | 808 +-----------+-------------------------------------------+ 810 7. Normative References 812 [I-D.ietf-taps-arch] 813 Pauly, T., Trammell, B., Brunstrom, A., Fairhurst, G., 814 Perkins, C., Tiesel, P., and C. Wood, "An Architecture for 815 Transport Services", draft-ietf-taps-arch-03 (work in 816 progress), March 2019. 818 [I-D.ietf-taps-interface] 819 Trammell, B., Welzl, M., Enghardt, T., Fairhurst, G., 820 Kuehlewind, M., Perkins, C., Tiesel, P., and C. Wood, "An 821 Abstract Application Layer Interface to Transport 822 Services", draft-ietf-taps-interface-03 (work in 823 progress), March 2019. 825 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 826 Requirement Levels", BCP 14, RFC 2119, 827 DOI 10.17487/RFC2119, March 1997, 828 . 830 [RFC6991] Schoenwaelder, J., Ed., "Common YANG Data Types", 831 RFC 6991, DOI 10.17487/RFC6991, July 2013, 832 . 834 [RFC7950] Bjorklund, M., Ed., "The YANG 1.1 Data Modeling Language", 835 RFC 7950, DOI 10.17487/RFC7950, August 2016, 836 . 838 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 839 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 840 May 2017, . 842 [RFC8340] Bjorklund, M. and L. Berger, Ed., "YANG Tree Diagrams", 843 BCP 215, RFC 8340, DOI 10.17487/RFC8340, March 2018, 844 . 846 [RFC8343] Bjorklund, M., "A YANG Data Model for Interface 847 Management", RFC 8343, DOI 10.17487/RFC8343, March 2018, 848 . 850 [RFC8407] Bierman, A., "Guidelines for Authors and Reviewers of 851 Documents Containing YANG Data Models", BCP 216, RFC 8407, 852 DOI 10.17487/RFC8407, October 2018, 853 . 855 Appendix A. Future Work 857 TBD if adopted: 859 o Review [RFC8407] guidelines for YANG authors and reviewers, make 860 sure they are followed. 862 o Start a reference implementation. No doubt it will highlight many 863 model problems. 865 o many more config examples with use cases 867 o Look into providing explicit layers that support some kind of 868 pass-thru, instead of having all properties in big groups of 869 properties. 871 Author's Address 873 Jake Holland 874 Akamai Technologies, Inc. 875 150 Broadway 876 Cambridge, MA 02144 877 United States of America 879 Email: jakeholland.net@gmail.com