idnits 2.17.1 draft-jholland-taps-api-yang-02.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 120 has weird spacing: '...ference pre...' -- The document date (March 09, 2019) is 1874 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 853, but no explicit reference was found in the text == Unused Reference: 'RFC8343' is defined on line 869, but no explicit reference was found in the text == Outdated reference: A later version (-19) exists of draft-ietf-taps-arch-02 == Outdated reference: A later version (-26) exists of draft-ietf-taps-interface-02 Summary: 0 errors (**), 0 flaws (~~), 6 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 March 09, 2019 5 Expires: September 10, 2019 7 A YANG Data Model for a Transport Services API at Endpoints 8 draft-jholland-taps-api-yang-02 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 September 10, 2019. 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. Prohibit Specific Interface . . . . . . . . . . . . . 5 60 3.2.2. Require Wi-Fi . . . . . . . . . . . . . . . . . . . . 6 61 3.3. Send and Receive Multicast . . . . . . . . . . . . . . . 6 62 3.4. Connecting Through a Stun Server . . . . . . . . . . . . 8 63 4. YANG Module . . . . . . . . . . . . . . . . . . . . . . . . . 9 64 5. Security Considerations . . . . . . . . . . . . . . . . . . . 18 65 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 18 66 7. Normative References . . . . . . . . . . . . . . . . . . . . 19 67 Appendix A. Future Work . . . . . . . . . . . . . . . . . . . . 20 68 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 20 70 1. Introduction 72 This document is an attempt to concretize the properties and objects 73 of the TAPS interface described in [I-D.ietf-taps-interface], under 74 the architecture described in [I-D.ietf-taps-arch]. 76 A TAPS-compliant implementation SHOULD provide a language-appropriate 77 way to configure a PreConnection using YANG instance data for this 78 model, and SHOULD provide an API that outputs the YANG instance data 79 for an established Connection. 81 An implementation MAY also provide appropriate APIs for directly 82 editing the objects without using YANG. It's RECOMMENDED where 83 possible to use names that mechanically translate to the names in the 84 YANG data model, using capitalization and punctuation conventions as 85 expected for the language of the implementation. 87 Non-TAPS extensions to API objects that directly edit TAPS properties 88 are RECOMMENDED to include "ext", "EXT", or "Ext" as a prefix to any 89 extension properties or methods, to avoid colliding with future TAPS 90 extensions. 92 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 93 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 94 "OPTIONAL" in this document are to be interpreted as described in BCP 95 14 [RFC2119] [RFC8174] when, and only when, they appear in all 96 capitals, as shown here. 98 1.1. A Note On The Use Of YANG 100 Although YANG was originally designed to model data for NETCONF, YANG 101 can be used in other ways as well, as described by Section 4.1 of 102 [RFC7950]. 104 This usage is not primarily targeted at NETCONF, but rather at 105 Application Programming Interfaces for libraries that set up 106 connections for sending and receiving data over the internet. 107 However, use of YANG in this context provides a semantically clear, 108 well defined, extensible, cross-platform method for configuring 109 connection objects suitable for replacing BSD sockets in a wide 110 variety of applications. 112 2. Tree Diagram 114 Tree diagrams used in this document follow the notation defined in 115 [RFC8340]. 117 module: ietf-taps-api 118 +--rw preconnection 119 | +--rw properties* [type preference] 120 | | +--rw preference preference-level 121 | | +--rw type identityref 122 | | +--rw iftype* identityref 123 | | +--rw ifref* if:interface-ref 124 | | +--rw address* inet:ip-address 125 | | +--rw port* inet:port-number 126 | | +--rw host* inet:host 127 | | +--rw stun-info 128 | | +--rw host? inet:host 129 | | +--rw port? inet:port-number 130 | | +--rw identity? string 131 | | +--rw algorithm? identityref 132 | | +--rw pre-shared-key? string 133 | | +--rw private-key? string 134 | | +--rw private-key-callback-handle? string 135 | | +--rw public-key? string 136 | +--rw security 137 | +--rw credentials* [identity algorithm] 138 | | +--rw identity string 139 | | +--rw algorithm identityref 140 | | +--rw pre-shared-key? string 141 | | +--rw private-key? string 142 | | +--rw private-key-callback-handle? string 143 | | +--rw public-key? string 144 | +--rw session-cache-capacity? uint32 145 | +--rw session-cache-lifetime? uint32 146 +--ro connection 147 +--ro properties* [] 148 +--ro type? identityref 149 +--ro iftype* identityref 150 +--ro ifref* if:interface-ref 151 +--ro address* inet:ip-address 152 +--ro port* inet:port-number 153 +--ro host* inet:host 154 +--ro stun-info 155 +--ro host? inet:host 156 +--ro port? inet:port-number 157 +--ro identity? string 158 +--ro algorithm? identityref 159 +--ro pre-shared-key? string 160 +--ro private-key? string 161 +--ro private-key-callback-handle? string 162 +--ro public-key? string 164 Tree Diagram 166 3. Examples 168 3.1. Basic Client Connection 170 The API is designed to allow defaults to fill out almost everything. 171 This example shows the minimal preconnection configuration input data 172 to open a reliable transfer to example.com, via any supported 173 reliable transport protocol on the default port or ports. 175 { 176 "ietf-taps-api:preconnection":{ 177 "properties":[ 178 { 179 "type":"remote-host", 180 "preference":"require", 181 "host":["example.com"] 182 } 183 ] 184 } 185 } 187 Basic Client Connection 189 Due to the defaults recommended in (TBD: fix reference) Section 5 of 190 draft-ietf-taps-interface-02, implementations SHOULD treat this basic 191 example equivalently to the same example with the defaults explicitly 192 provided: 194 { 195 "ietf-taps-api:preconnection":{ 196 "properties":[ 197 { 198 "type":"remote-host", 199 "host":["example.com"], 200 "preference":"require" 201 }, 202 { 203 "type":"reliable", 204 "preference":"require" 205 }, 206 { 207 "type":"preserve-order", 208 "preference":"require" 209 }, 210 { 211 "type":"congestion-control", 212 "preference":"require" 213 } 214 ] 215 } 216 } 218 Basic Client Connection Explicitly Declaring Defaults 220 3.2. Customized Connections 222 In some cases, applications may have explicit preferences, either 223 dynamically inferred from past statistics or configured via system or 224 app preferences of some kind. 226 These examples demonstrates adding constraints on the endpoints when 227 opening a connection. 229 3.2.1. Prohibit Specific Interface 231 In this example, an app needs to avoid using a local proxy for a 232 specific set of connections, so it might configure those connections 233 to prohibit connecting through a specific loopback interface: 235 { 236 "ietf-taps-api:preconnection":{ 237 "properties":[ 238 { 239 "type":"remote-host", 240 "preference":"require", 241 "host":["example.com"] 242 }, 243 { 244 "type":"local-interface-selection", 245 "preference":"prohibit", 246 "ifref":["lo0"] 247 } 248 ] 249 } 250 } 252 Figure 1: Customized to avoid lo0 254 3.2.2. Require Wi-Fi 256 This example demonstrates an app that requires the use of a wireless 257 interface: 259 { 260 "ietf-taps-api:preconnection":{ 261 "properties":[ 262 { 263 "type":"remote-host", 264 "preference":"require", 265 "host":["example.com"] 266 }, 267 { 268 "type":"local-interface-selection", 269 "preference":"require", 270 "iftype":["iana-if-type:capwapDot11Profile"] 271 } 272 ] 273 } 274 } 276 Figure 2: Customized to require wireless. 278 3.3. Send and Receive Multicast 280 Sending to a multicast group is the same as any non-reliable, non- 281 ordered connection: 283 { 284 "ietf-taps-api:preconnection":{ 285 "properties":[ 286 { 287 "type":"local-address", 288 "preference":"require", 289 "address":["192.0.2.15"] 290 }, 291 { 292 "type":"remote-host", 293 "preference":"require", 294 "host":["232.252.0.2"] 295 }, 296 { 297 "type":"remote-port", 298 "preference":"require", 299 "port":["30000"] 300 }, 301 { 302 "type":"udp", 303 "preference":"require" 304 } 305 ] 306 } 307 } 309 Figure 3: PreConnection for Sending Multicast 311 Receiving multicast is similar. It may use remote-endpoint to 312 specify a source-specific multicast subscription, or exclude it to 313 specify any-source multicast. 315 { 316 "ietf-taps-api:preconnection":{ 317 "properties":[ 318 { 319 "type":"remote-host", 320 "preference":"require", 321 "host":["192.0.2.15"] 322 }, 323 { 324 "type":"local-address", 325 "preference":"require", 326 "address":["232.252.0.2"] 327 }, 328 { 329 "type":"local-port", 330 "preference":"require", 331 "port":["30000"] 332 }, 333 { 334 "type":"udp", 335 "preference":"require" 336 } 337 ] 338 } 339 } 341 Figure 4: PreConnection for Source-specific Multicast Receive 343 3.4. Connecting Through a Stun Server 345 STUN server connections are a local-endpoint property, and can be 346 configured the same way. 348 { 349 "ietf-taps-api:preconnection":{ 350 "properties":[ 351 { 352 "type":"remote-host", 353 "host":["example.com"], 354 "preference":"require" 355 }, 356 { 357 "type":"stun-server", 358 "stun-info":{ 359 "host":"203.0.113.4", 360 "port":"10000", 361 "identity":"user@mail.example.com", 362 "pre-shared-key":"" 363 } 364 } 365 ] 366 } 367 } 369 Figure 5: Connect through a STUN server 371 4. YANG Module 373 file ietf-taps-api@2019-03-11.yang 374 module ietf-taps-api { 375 yang-version 1.1; 377 namespace "urn:ietf:params:xml:ns:yang:ietf-taps-api"; 378 prefix "taps"; 380 import ietf-inet-types { 381 prefix "inet"; 382 reference "RFC 6991 Section 4"; 383 } 385 import ietf-interfaces { 386 prefix "if"; 387 reference "RFC 8343 Section 5"; 388 } 390 import iana-if-type { 391 prefix "ianaift"; 392 reference "RFC 7224 Section 2"; 393 } 395 organization "IETF"; 396 contact 397 "Author: Jake Holland 398 399 "; 401 description 402 "This module contains the definition for the TAPS 403 interface. 405 Copyright (c) 2018 IETF Trust and the persons identified as 406 authors of the code. All rights reserved. 408 Redistribution and use in source and binary forms, with or 409 without modification, is permitted pursuant to, and subject 410 to the license terms contained in, the Simplified BSD License 411 set forth in Section 4.c of the IETF Trust's Legal Provisions 412 Relating to IETF Documents 413 (http://trustee.ietf.org/license-info). 415 This version of this YANG module is part of 416 draft-jholland-taps-api-yang, 417 see the internet draft itself for full legal notices."; 419 revision 2019-03-09 { 420 description "Draft -01 revision."; 421 reference 422 "draft-jholland-taps-api-yang"; 423 } 425 typedef preference-level { 426 type enumeration { 427 enum require { 428 description 429 "select only options providing this property, fail otherwise"; 430 } 431 enum prefer { 432 description 433 "prefer options providing this property, proceed otherwise"; 434 } 435 enum ignore { 436 description 437 "cancel any system default preference for this property"; 438 } 439 enum avoid { 440 description 441 "prefer options not providing the property, 442 proceed otherwise"; 443 } 444 enum prohibit { 445 description 446 "select only options not proiding ths property, fail 447 otherwise"; 448 } 449 } 450 description 451 "This value represents the preference level of a property."; 452 } 454 identity connection-config-property { 455 description "Base identity for configuring connections"; 456 } 458 identity transport-property { 459 base connection-config-property; 460 description "Base identity for transport properties"; 461 } 463 identity local-endpoint-property { 464 base connection-config-property; 465 description "Base identity for local endpoint properties"; 466 } 468 identity local-address { 469 base local-endpoint-property; 470 description 471 "Identity for the address of a local endpoint"; 472 } 474 identity local-port { 475 base local-endpoint-property; 476 description 477 "Identity for the port of a local endpoint"; 478 } 480 identity stun-server { 481 base local-endpoint-property; 482 description 483 "Identity for using a stun server"; 484 } 486 identity remote-endpoint-property { 487 base connection-config-property; 488 description "Base identity for remote endpoint properties"; 489 } 491 identity remote-host { 492 base remote-endpoint-property; 493 description 494 "Identity for the host of a remote endpoint"; 495 } 497 identity remote-port { 498 base remote-endpoint-property; 499 description 500 "Identity for the port of a remote endpoint"; 501 } 503 identity reliable { 504 base transport-property; 505 description "Reliable Transport"; 506 } 507 identity per-message-reliable { 508 base transport-property; 509 description "Per-message Reliable Transport"; 510 } 511 identity preserve-order { 512 base transport-property; 513 description "Per-message Reliable Transport"; 514 } 515 identity zero-rtt-establishment { 516 base transport-property; 517 description 518 "Use 0-RTT session establishment with an idempotent Message"; 519 } 520 identity multistream-connections-in-group { 521 base transport-property; 522 description "Multistream Connections in Group"; 523 } 524 identity control-checksum-coverage { 525 base transport-property; 526 description "Control checksum coverage on sending or receiving 527 TBD: draft-ietf-taps-interface-02#section-5.2.6 seems to 528 indicate some parameters are in order with this type, 529 not sure exactly what it should look like? Use case?"; 530 } 531 identity congestion-control { 532 base transport-property; 533 description "Congestion control"; 534 } 535 identity local-interface-selection { 536 base transport-property; 537 description "Interface Instance or Type 538 TBD: should this be a local-endpoint-property?"; 539 } 540 identity provisioning-domain { 541 base transport-property; 542 description "Base for provisioning domain. 543 TBD: add relevant provisioning domain types"; 544 reference "RFC 7556: Multiple Provisioning Domain Architecture"; 545 } 547 identity transport-protocol { 548 base transport-property; 549 description "Identity for a transport selection. 550 TBD: finish the rest of the protocols in 551 https://tools.ietf.org/html/rfc8095#section-3.1 552 maybe add quic, maybe use as external augment demo. 553 note: this isn't in taps-interface, but is available in 554 e.g. NEAT-project/neat/examples/client.c"; 555 reference "Section 3 of RFC 8095: Existing Transport Protocols"; 556 } 558 identity tcp { 559 base transport-protocol; 560 description "Identity for TCP"; 561 reference "RFC 793: Transmission Control Protocol. 562 See also RFC 7414: A Roadmap for TCP Specification Documents."; 563 } 564 identity mptcp { 565 base transport-protocol; 566 description "Identity for MPTCP"; 567 reference 568 "RFC 6824: TCP Extensions for Multipath Operation"; 569 } 570 identity udp { 571 base transport-protocol; 572 description "Identity for UDP"; 573 reference "TBD"; 574 } 575 identity udp-lite { 576 base transport-protocol; 577 description "Identity for UDP-Lite"; 578 reference "TBD"; 579 } 580 identity sctp { 581 base transport-protocol; 582 description "Identity for SCTP"; 583 reference "TBD"; 584 } 585 identity dccp { 586 base transport-protocol; 587 description "Identity for DCCP"; 588 reference "TBD"; 589 } 590 identity tls { 591 base transport-protocol; 592 description "Identity for TLS"; 593 reference "TBD"; 594 } 595 identity rtp { 596 base transport-protocol; 597 description "Identity for RTP"; 598 reference "TBD"; 599 } 600 identity http { 601 base transport-protocol; 602 description "Identity for HTTP"; 603 reference "TBD"; 604 } 605 identity flute { 606 base transport-protocol; 607 description "Identity for FLUTE"; 608 reference "TBD"; 609 } 610 identity norm { 611 base transport-protocol; 612 description "Identity for NORM"; 613 reference "TBD"; 614 } 615 identity icmp { 616 base transport-protocol; 617 description "Identity for ICMP"; 618 reference "TBD"; 619 } 621 identity security-algorithm { 622 description "Base identity for security algorithms."; 623 } 625 identity cipher-suite { 626 base security-algorithm; 627 description "Base identity for security cipher suites."; 628 } 630 identity signature-algorithm { 631 base security-algorithm; 632 description "Base identity for security signature algorithms."; 633 } 635 identity ed25519 { 636 base signature-algorithm; 637 description "Identity for ED25519"; 638 } 640 identity TLS_ECDHE_ECDSA_WITH_CHACHA20_POLY1305_SHA256 { 641 base cipher-suite; 642 description "Identity for ECDHE ECDSA with ChaCha20, Poly1305, 643 and SHA256"; 644 } 646 grouping security-credentials { 647 description "security credentials"; 649 leaf identity { 650 type string; 651 description "identity for security credentials"; 652 } 654 leaf algorithm { 655 type identityref { 656 base security-algorithm; 657 } 658 description "security algorithm for credentials"; 659 } 661 leaf pre-shared-key { 662 type string; 663 description "pre-shared key for security credentials"; 664 } 666 leaf private-key { 667 type string; 668 description "private key for security credentials"; 669 } 671 leaf private-key-callback-handle { 672 type string; 673 description "private key callback handle for 674 externally managed security credentials"; 675 } 677 leaf public-key { 678 type string; 679 description "public key for security credentials"; 680 } 681 } 683 grouping transport-property-info { 684 description "grouping of transport info, used by preconnection 685 and connection"; 687 leaf type { 688 type identityref { 689 base "connection-config-property"; 690 } 691 description "type of the property"; 692 } 694 leaf-list iftype { 695 when "derived-from-or-self(../type, 696 'taps:local-interface-selection')"; 697 type identityref { 698 base "ianaift:iana-interface-type"; 699 } 700 description "interface type constraint for local 701 interface selection"; 702 reference "RFC 7224 Section 2"; 703 } 705 leaf-list ifref { 706 when "derived-from-or-self(../type, 707 'taps:local-interface-selection')"; 708 type if:interface-ref { 709 require-instance false; 710 } 711 description "specific interface constraint for local 712 interface selection."; 713 } 715 leaf-list address { 716 when "derived-from-or-self(../type, 717 'taps:local-address')"; 718 type inet:ip-address; 719 description "ip address of local endpoint"; 720 } 722 leaf-list port { 723 when "derived-from-or-self(../type, 724 'taps:local-port') or 725 derived-from-or-self(../type, 726 'taps:remote-port')"; 727 type inet:port-number; 728 description "port value of an endpoint port"; 729 } 731 leaf-list host { 732 when "derived-from-or-self(../type, 733 'taps:remote-host')"; 734 type inet:host; 735 description "host value of a remote endpoint"; 736 } 738 container stun-info { 739 when "derived-from-or-self(../type, 740 'taps:stun-server')"; 741 description "config for the stun server"; 743 leaf host { 744 type inet:host; 745 description "stun server host"; 746 } 747 leaf port { 748 type inet:port-number; 749 description "port number for the stun server"; 750 } 751 uses security-credentials; 752 } 753 } 755 container preconnection { 756 description "preconnection config for a taps connection"; 757 list properties { 758 key "type preference"; 759 description "list of transport property constraints."; 761 leaf preference { 762 type preference-level; 763 /* TBD: would be nice if i could set default and have 764 less verbose config file. 765 default require; */ 766 description "preference level for the property"; 767 } 769 uses transport-property-info; 770 } 772 container security { 773 description "Security properties for the connection"; 774 list credentials { 775 key "identity algorithm"; 777 uses security-credentials; 778 description "security credentials"; 779 } 780 leaf session-cache-capacity { 781 type uint32; 782 description "Max number of cache elements"; 783 } 784 leaf session-cache-lifetime { 785 type uint32; 786 description "Number of seconds of session cache lifetime"; 787 } 788 } 789 } 791 container connection { 792 config false; 794 description "information about connections"; 795 list properties { 796 description "list of transport properties for live connections."; 798 uses transport-property-info; 799 } 800 } 801 } 803 805 Figure 6: TAPS Interface YANG model 807 5. Security Considerations 809 This document describes a configuration system for an API that may 810 replace sockets. All security considerations applicable to socket 811 programming should be carefully considered by implementors. 813 (TBD: surely there is a sane reference, but also fill this out with 814 something less laughable. In particular, enumerate which options 815 should be privileged operations or not to preserve the security of 816 BSD sockets, such as it is. And maybe another layer of restriction 817 recommendations for sandboxed or browser systems.) 819 6. IANA Considerations 821 IANA is requested to add the YANG model in Section 4 to the yang- 822 parameters registry. 824 +-----------+-------------------------------------------+ 825 | Field | Value | 826 +-----------+-------------------------------------------+ 827 | Name | ietf-taps-api | 828 | Namespace | urn:ietf:params:xml:ns:yang:ietf-taps-api | 829 | Prefix | taps | 830 | Reference | [TBD: this document] | 831 +-----------+-------------------------------------------+ 833 7. Normative References 835 [I-D.ietf-taps-arch] 836 Pauly, T., Trammell, B., Brunstrom, A., Fairhurst, G., 837 Perkins, C., Tiesel, P., and C. Wood, "An Architecture for 838 Transport Services", draft-ietf-taps-arch-02 (work in 839 progress), October 2018. 841 [I-D.ietf-taps-interface] 842 Trammell, B., Welzl, M., Enghardt, T., Fairhurst, G., 843 Kuehlewind, M., Perkins, C., Tiesel, P., and C. Wood, "An 844 Abstract Application Layer Interface to Transport 845 Services", draft-ietf-taps-interface-02 (work in 846 progress), October 2018. 848 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 849 Requirement Levels", BCP 14, RFC 2119, 850 DOI 10.17487/RFC2119, March 1997, 851 . 853 [RFC6991] Schoenwaelder, J., Ed., "Common YANG Data Types", 854 RFC 6991, DOI 10.17487/RFC6991, July 2013, 855 . 857 [RFC7950] Bjorklund, M., Ed., "The YANG 1.1 Data Modeling Language", 858 RFC 7950, DOI 10.17487/RFC7950, August 2016, 859 . 861 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 862 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 863 May 2017, . 865 [RFC8340] Bjorklund, M. and L. Berger, Ed., "YANG Tree Diagrams", 866 BCP 215, RFC 8340, DOI 10.17487/RFC8340, March 2018, 867 . 869 [RFC8343] Bjorklund, M., "A YANG Data Model for Interface 870 Management", RFC 8343, DOI 10.17487/RFC8343, March 2018, 871 . 873 [RFC8407] Bierman, A., "Guidelines for Authors and Reviewers of 874 Documents Containing YANG Data Models", BCP 216, RFC 8407, 875 DOI 10.17487/RFC8407, October 2018, 876 . 878 Appendix A. Future Work 880 TBD if adopted: 882 o Review [RFC8407] guidelines for YANG authors and reviewers, make 883 sure they are followed. 885 o Start a reference implementation. No doubt it will highlight many 886 model problems. 888 o many more config examples with use cases 890 o Look into providing explicit layers that support some kind of 891 pass-thru, instead of having all properties in big groups of 892 properties. 894 Author's Address 896 Jake Holland 897 Akamai Technologies, Inc. 898 150 Broadway 899 Cambridge, MA 02144 900 United States of America 902 Email: jakeholland.net@gmail.com