idnits 2.17.00 (12 Aug 2021) /tmp/idnits21522/draft-bierman-netmod-system-mgmt-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 : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year == Line 419 has weird spacing: '...atabase http:...' == The document seems to lack the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords. (The document does seem to have the reference to RFC 2119 which the ID-Checklist requires). -- The document date (June 2, 2011) is 4005 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) == Outdated reference: draft-ietf-netconf-rfc4742bis has been published as RFC 6242 == Outdated reference: draft-lear-iana-timezone-database has been published as RFC 6557 Summary: 0 errors (**), 0 flaws (~~), 5 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group A. Bierman 3 Internet-Draft Brocade 4 Intended status: Standards Track M. Bjorklund 5 Expires: December 4, 2011 Tail-f Systems 6 June 2, 2011 8 YANG Data Model for System Management 9 draft-bierman-netmod-system-mgmt-00 11 Abstract 13 This document defines a YANG data model for the configuration and 14 identification of the management system of a device. 16 Status of this Memo 18 This Internet-Draft is submitted in full conformance with the 19 provisions of BCP 78 and BCP 79. 21 Internet-Drafts are working documents of the Internet Engineering 22 Task Force (IETF). Note that other groups may also distribute 23 working documents as Internet-Drafts. The list of current Internet- 24 Drafts is at http://datatracker.ietf.org/drafts/current/. 26 Internet-Drafts are draft documents valid for a maximum of six months 27 and may be updated, replaced, or obsoleted by other documents at any 28 time. It is inappropriate to use Internet-Drafts as reference 29 material or to cite them other than as "work in progress." 31 This Internet-Draft will expire on December 4, 2011. 33 Copyright Notice 35 Copyright (c) 2011 IETF Trust and the persons identified as the 36 document authors. All rights reserved. 38 This document is subject to BCP 78 and the IETF Trust's Legal 39 Provisions Relating to IETF Documents 40 (http://trustee.ietf.org/license-info) in effect on the date of 41 publication of this document. Please review these documents 42 carefully, as they describe your rights and restrictions with respect 43 to this document. Code Components extracted from this document must 44 include Simplified BSD License text as described in Section 4.e of 45 the Trust Legal Provisions and are provided without warranty as 46 described in the Simplified BSD License. 48 Table of Contents 50 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 51 1.1. Terminology . . . . . . . . . . . . . . . . . . . . . . . 3 52 1.1.1. Terms . . . . . . . . . . . . . . . . . . . . . . . . 3 53 2. Objectives . . . . . . . . . . . . . . . . . . . . . . . . . . 4 54 2.1. System Identification . . . . . . . . . . . . . . . . . . 4 55 2.2. System Time Management . . . . . . . . . . . . . . . . . . 4 56 2.3. User Authentication . . . . . . . . . . . . . . . . . . . 4 57 3. System Data Model . . . . . . . . . . . . . . . . . . . . . . 5 58 3.1. User Authentication Model . . . . . . . . . . . . . . . . 5 59 3.2. SSH Public Key Authentication . . . . . . . . . . . . . . 5 60 3.3. Local User Password Authentication . . . . . . . . . . . . 6 61 3.4. RADIUS Password Authentication . . . . . . . . . . . . . . 6 62 4. System YANG module . . . . . . . . . . . . . . . . . . . . . . 7 63 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 20 64 6. Security Considerations . . . . . . . . . . . . . . . . . . . 21 65 7. Normative References . . . . . . . . . . . . . . . . . . . . . 22 66 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 23 68 1. Introduction 70 This document defines a YANG [RFC6020] data model for the 71 configuration and identification of the management system of a 72 device. 74 Devices which are managed by NETCONF and perhaps other mechanisms 75 have common properties which need to be configured and monitored in a 76 standard way. 78 The YANG module defined in this document provides the following 79 features: 81 o system administrative data configuration 83 o system identification monitoring 85 o system time-of-day configuration and monitoring 87 o user authentication configuration 89 o local users configuration 91 1.1. Terminology 93 The keywords "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 94 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 95 "OPTIONAL" in this document are to be interpreted as described in BCP 96 14, [RFC2119]. 98 1.1.1. Terms 100 The following terms are used within this document: 102 o system: This term refers to the embodiment of the entire set of 103 management interfaces that a single NETCONF server is supporting 104 at a given moment. The set of physical entities managed by a 105 single NETCONF server can be static or it can change dynamically. 107 2. Objectives 109 2.1. System Identification 111 There are many common properties used to identify devices, operating 112 systems, software versions, etc. that need to be supported in the 113 system data module. These objects are defined as operational data 114 and intended to be specific to the device vendor. 116 Some user-configurable administrative strings are also provided such 117 as the system location and description. 119 2.2. System Time Management 121 The management of the date and time used by the system must be 122 supported. Use of one or more NTP servers to automatically set the 123 system date and time must be possible. Utilization of the Timezone 124 database [I-D.lear-iana-timezone-database] must also be supported. 126 2.3. User Authentication 128 The authentication mechanism must support password authentication 129 over RADIUS, to support deployment scenarios with centralized 130 authentication servers. Additionally, local users must be supported, 131 for scenarios when no centralized authentication server exists, or 132 for situations where the centralized authentication server cannot be 133 reached from the device. 135 Since the mandatory transport protocol for NETCONF is SSH 136 [I-D.ietf-netconf-rfc4742bis] the authentication model must support 137 SSH's "publickey" and "password" authentication methods [RFC4252]. 139 The model for authentication configuration should be flexible enough 140 to support authentication methods defined by other standard documents 141 or by vendors. 143 3. System Data Model 145 [FIXME: this section currently just talks about authentication. Add 146 description of the rest of the data model, like we do in snmp-cfg? 147 Otherwise, rename this section to Authentication ...] 149 [FIXME: introduce a set of submodules to allow for future 150 enhancements of the system data model?] 152 3.1. User Authentication Model 154 This document defines three authentication methods for use with 155 NETCONF: 157 o publickey for local users over SSH 159 o password for local users over any transport 161 o password for RADIUS users over any transport 163 Additional methods may be defined by other standard documents or by 164 vendors. 166 This document defines two optional YANG features, 'local-users' and 167 'radius', which the server advertises to indicate support for 168 configuring local users on the device, and for configuring RADIUS 169 access, respectively. 171 The authentication parameters defined in this document are primarily 172 used to configure authentication of NETCONF users, but MAY also be 173 used by other interfaces, e.g., a Command Line Interface or a Web- 174 based User Interface. 176 3.2. SSH Public Key Authentication 178 If the NETCONF server advertises the 'local-users' feature, 179 configuration of local users and their SSH public keys is supported 180 in the /system/authentication/user list. 182 Public key authentication is requested by the SSH client. The SSH 183 server looks up the user name provided by the client in the /system/ 184 authentication/user list, and verifies the key as described in 185 [RFC4253]. 187 If the 'local-users' feature is supported, then when a NETCONF client 188 starts an SSH session towards the server, using the "publickey" 189 authentication 'method name' [RFC4252], the SSH server looks up the 190 user name given in the SSH authentication request in the /system/ 191 authentication/user list, 193 3.3. Local User Password Authentication 195 If the NETCONF server advertises the 'local-users' feature, 196 configuration of local users and their passwords is supported in the 197 /system/authentication/user list. 199 For NETCONF transport protocols that support password authentication, 200 the leaf-list 'user-authentication-order' is used to control if local 201 user password authentication should be used. 203 In SSH, password authentication is requested by the client. Other 204 NETCONF transport protocols may also support password authentication. 206 When local user password authentication is requested, the NETCONF 207 transport looks up the user name provided by the client in the 208 /system/ authentication/user list, and verifies the password. 210 3.4. RADIUS Password Authentication 212 If the NETCONF server advertises the 'radius' feature, the device 213 supports user authentication RADIUS. 215 For NETCONF transport protocols that support password authentication, 216 the leaf-list 'user-authentication-order' is used to control if 217 RADIUS password authentication should be used. 219 In SSH, password authentication is requested by the client. Other 220 NETCONF transport protocols may also support password authentication. 222 4. System YANG module 224 RFC Ed.: update the date below with the date of RFC publication and 225 remove this note. 227 This YANG module imports YANG extensions from ... and references ... 228 [Editor's Note: add proper references] 230 file "ietf-system@2011-06-02.yang" 232 module ietf-system { 233 namespace "urn:ietf:params:xml:ns:yang:ietf-system"; 234 prefix "sys"; 236 import ietf-inet-types { 237 prefix inet; 238 } 240 import ietf-netconf-acm { 241 prefix nacm; 242 } 244 import ietf-yang-types { 245 prefix yang; 246 } 248 organization 249 "IETF NETMOD (NETCONF Data Modeling Language) Working Group"; 251 contact 252 "WG Web: 253 WG List: 255 WG Chair: David Kessens 256 258 WG Chair: Juergen Schoenwaelder 259 261 Editor: Andy Bierman 262 264 Editor: Martin Bjorklund 265 "; 267 description 268 "This module contains a collection of YANG definitions for the 269 configuration and identification of the management system of a 270 device. 272 Copyright (c) 2011 IETF Trust and the persons identified as 273 authors of the code. All rights reserved. 275 Redistribution and use in source and binary forms, with or 276 without modification, is permitted pursuant to, and subject 277 to the license terms contained in, the Simplified BSD License 278 set forth in Section 4.c of the IETF Trust's Legal Provisions 279 Relating to IETF Documents 280 (http://trustee.ietf.org/license-info). 282 This version of this YANG module is part of RFC XXXX; see 283 the RFC itself for full legal notices."; 285 // RFC Ed.: replace XXXX with actual RFC number and remove this 286 // note. 288 // RFC Ed.: update the date below with the date of RFC publication 289 // and remove this note. 290 revision 2011-06-02 { 291 description 292 "Initial revision."; 293 reference 294 "RFC XXXX: A YANG Data Model for System Management"; 295 } 297 /* 298 * Typedefs 299 */ 301 typedef crypt-hash { 302 type string { 303 pattern "$0$.* | $1|5|6$[a-zA-Z0-9./]{2,16}$.*"; 304 } 305 description 306 "The crypt-hash type is used to store passwords using 307 a hash function. This type is implemented in various UNIX 308 systems as the function crypt(3). 310 When a clear text value is set to a leaf of this type, the 311 server calculates a password hash, and stores the result 312 in the datastore. Thus, the password is never stored in 313 clear text. 315 When a leaf of this type is read, the stored password hash is 316 returned. 318 A value of this type matches one of the forms: 320 $0$ 321 $$$ 323 The '$0$' prefix signals that the value is clear text. When 324 such a value is received by the server, a hash value is 325 calculated, and the string '$$$' is prepended to the 326 result, where is a random 2-16 characters long salt 327 used to generate the digest. This value is stored in the 328 configuration data store. 330 If a value starting with '$$$' is received, the 331 server knows that the value already represents a hashed value, 332 and stores it as is in the data store. 334 When a server needs to verify a password given by a user, it 335 finds the stored password hash string for that user, extracts 336 the salt, and calculates the hash with the salt and given 337 password as input. If the calculated hash value is the same 338 as the stored value, the password given by the client is 339 correct. 341 This type defines the following hash functions: 343 id | hash function | feature 344 ---+---------------+------------------- 345 1 | MD5 | crypt-hash-md5 346 5 | SHA-256 | crypt-hash-sha-256 347 6 | SHA-512 | crypt-hash-sha-512 349 The server indicates support for the different hash functions 350 by advertising the corresponding feature."; 351 reference 352 "Wikipedia: http://en.wikipedia.org/wiki/Crypt_(Unix) 353 RFC 1321: The MD5 Message-Digest Algorithm 354 FIPS.180-3.2008: Secure Hash Standard"; 355 } 357 /* 358 * Features 359 */ 361 feature authentication { 362 description 363 "Indicates that the device can be configured 364 to do authentication of users."; 365 } 366 feature radius { 367 if-feature authentication; 368 description 369 "Indicates that the device can be 370 configured to act as a NAS and authenticate users 371 with RADIUS."; 372 reference 373 "RFC 2865: Remote Authentication Dial In User Service (RADIUS) 374 RFC 5607: Remote Authentication Dial-In User Service (RADIUS) 375 Authorization for Network Access Server (NAS) 376 Management"; 377 } 379 feature local-users { 380 if-feature authentication; 381 description 382 "Indicates that the device supports 383 local user authentication."; 384 } 386 feature crypt-hash-md5 { 387 description 388 "Indicates that the device supports the MD5 389 hash function in 'crypt-hash' values"; 390 reference "RFC 1321: The MD5 Message-Digest Algorithm"; 391 } 393 feature crypt-hash-sha-256 { 394 description 395 "Indicates that the device supports the SHA-256 396 hash function in 'crypt-hash' values"; 397 reference "FIPS.180-3.2008: Secure Hash Standard"; 398 } 400 feature crypt-hash-sha-512 { 401 description 402 "Indicates that the device supports the SHA-512 403 hash function in 'crypt-hash' values"; 404 reference "FIPS.180-3.2008: Secure Hash Standard"; 405 } 407 feature ntp { 408 description 409 "Indicates that the device can be configured 410 to use one or more NTP servers to set the 411 system date and time."; 412 } 413 feature tz-database { 414 description 415 "Indicates that the local timezone on the device 416 can be configured to use the TZ database 417 to set the timezone and manage daylight savings time."; 418 reference 419 "TZ Database http://www.twinsun.com/tz/tz-link.htm 420 Maintaining the Timezone Database 421 http://www.ietf.org/id/draft-lear-iana-timezone-database-04.txt 422 "; 423 } 425 feature tz-enumeration { 426 description 427 "Indicates that the local timezone on the device 428 can be configured using the timezone enumeration 429 strings as an alias for an UTC offset."; 430 reference 431 "Wikipedia: http://en.wikipedia.org/wiki/" 432 + "List_of_time_zone_abbreviations"; 433 } 435 /* 436 * Identities 437 */ 439 identity authentication-method { 440 description 441 "Base identity for user authentication methods."; 442 } 444 identity radius { 445 base authentication-method; 446 description 447 "Indicates user authentication using RADIUS."; 448 reference 449 "RFC 2865: Remote Authentication Dial In User Service (RADIUS) 450 RFC 5607: Remote Authentication Dial-In User Service (RADIUS) 451 Authorization for Network Access Server (NAS) 452 Management"; 453 } 455 identity local-users { 456 base authentication-method; 457 description 458 "Indicates password-based authentication of locally 459 configured users."; 460 } 461 /* 462 * Top-level container 463 */ 465 container system { 466 description 467 "System group configuration."; 469 leaf contact { 470 type string { 471 length "0..255"; 472 } 473 default ""; 474 reference 475 "RFC 3418 - Management Information Base (MIB) for the 476 Simple Network Management Protocol (SNMP) 477 SNMPv2-MIB.sysContact"; 478 } 480 leaf name { 481 type string { 482 length "0..255"; 483 } 484 default ""; 485 reference 486 "RFC 3418 - Management Information Base (MIB) for the 487 Simple Network Management Protocol (SNMP) 488 SNMPv2-MIB.sysName"; 489 } 491 leaf location { 492 type string { 493 length "0..255"; 494 } 495 default ""; 496 reference 497 "RFC 3418 - Management Information Base (MIB) for the 498 Simple Network Management Protocol (SNMP) 499 SNMPv2-MIB.sysLocation"; 500 } 502 container platform { 503 description 504 "Contains vendor-specific information for 505 identifying the system platform and operating system."; 506 reference 507 "GNU coreutils homepage: 508 http://www.gnu.org/software/coreutils 510 Wikipedia: http://en.wikipedia.org/wiki/Uname"; 512 config false; 514 leaf os-name { 515 type string; 516 description 517 "The name of the operating system in use, 518 for example 'Linux'"; 519 reference 520 "uname --kernel-name"; 521 } 523 leaf os-release { 524 type string; 525 description 526 "The current release level of the operating 527 system in use. This string MAY indicate 528 the OS source code revision."; 529 reference 530 "uname --kernel-release"; 531 } 533 leaf os-version { 534 type string; 535 description 536 "The current version level of the operating 537 system in use. This string MAY indicate 538 the specific OS build date and target variant 539 information."; 540 reference 541 "uname --kernel-version"; 542 } 544 leaf machine { 545 type string; 546 description 547 "A vendor-specific identifier string representing 548 the hardware in use."; 549 reference 550 "uname --machine"; 551 } 553 leaf nodename { 554 type string; 555 description 556 "The host name of this system."; 557 reference 558 "uname --nodename"; 559 } 560 } 562 container clock { 563 description 564 "Configuration and monitoring of the system 565 date and time properties."; 567 leaf current-datetime { 568 description 569 "The current system date and time."; 570 type yang:date-and-time; 571 config false; 572 } 574 leaf boot-datetime { 575 description 576 "The system date and time when the NETCONF 577 server last restarted."; 578 type yang:date-and-time; 579 config false; 580 } 582 choice timezone-info { 583 description 584 "Configure the system timezone information."; 586 leaf tz-database-id { 587 if-feature tz-database; 588 description 589 "The TZ database location identifier string 590 to use for the system, such as 'Europe/Stockholm'."; 591 type string; 592 } 594 leaf tz-enumeration-id { 595 if-feature tz-enumeration; 596 description 597 "The timezone enumeration string to use 598 for the system, such as 'CET'."; 599 type string; 600 // FIXME: use TimezoneEnum typedef instead 601 // see http://en.wikipedia.org/wiki/ 602 // List_of_time_zone_abbreviations 603 } 605 leaf utc-offset { 606 description 607 "The number of minutes to add to UTC time to 608 identify the timezone for this system. 609 For example, 'UTC - 8:00 hours' would be 610 represented as '-480'."; 611 type int16 { 612 range "-1439 .. 1439"; 613 } 614 } 615 } 616 } 618 container ntp { 619 if-feature ntp; 621 description 622 "Configuration of the NTP client."; 624 leaf use-ntp { 625 description 626 "Indicates that the system should attempt 627 to synchronize the system clock with an 628 NTP server from the 'ntp-server' list."; 629 type boolean; 630 default true; 631 } 633 list ntp-server { 634 description 635 "List of NTP servers to use for 636 system clock synchronization. If 'use-ntp' 637 is 'true', then the system will attempt to 638 contact and utilize the specified NTP servers."; 640 key address; 642 leaf address { 643 description 644 "The IP address or domain name of the NTP server."; 645 type inet:host; 646 } 648 // TBD: add more parameters here 649 // and/or vendors can add parameters via augment 650 } 651 } 653 container dns { 654 description 655 "Configuration of the DNS resolver. 657 The 'domain' keyword of /etc/resolv.conf is not supported, 658 since it is equivalent to 'search' with a single domain."; 660 leaf-list search { 661 type inet:host; 662 ordered-by user; 663 } 664 leaf-list server { 665 type inet:ip-address; 666 ordered-by user; 667 description 668 "Addresses of the name servers that the resolver should 669 query. 671 Implementations MAY limit the number of entries in this 672 leaf list."; 673 } 674 container options { 675 description 676 "Resolver options. The set of available options has been 677 limited to those that are generally available across 678 different resolver implementations, and generally useful."; 679 leaf ndots { 680 type uint8; 681 default "1"; 682 } 683 leaf timeout { 684 type uint8; 685 units "seconds"; 686 default "5"; 687 } 688 leaf attempts { 689 type uint8; 690 default "2"; 691 } 692 } 693 } 695 container authentication { 696 nacm:secure; 697 if-feature authentication; 699 description 700 "The authentication configuration subtree."; 702 leaf-list user-authentication-order { 703 type identityref { 704 base authentication-method; 705 } 706 must '(. = "sys:radius" and ../radius/server) or' 707 + '(. != "sys:radius")' { 708 error-message 709 "When 'radius' is used, a radius server 710 must be configured."; 711 } 712 ordered-by user; 714 description 715 "When the device authenticates a user with 716 a password, it tries the authentication methods in this 717 leaf-list in order. If authentication with one method 718 fails, the next method is used. If no method succeeds, 719 the user is denied access. 721 If the 'radius' feature is advertised by the NETCONF 722 server, the 'radius' identity can be added to this 723 list. 725 If the 'local-users' feature is advertised by the 726 NETCONF server, the 'local-users' identity can be 727 added to this list."; 728 } 730 container radius { 731 if-feature radius; 733 description 734 "The RADIUS configuration for authentication."; 736 list server { 737 key address; 738 ordered-by user; 740 description 741 "The RADIUS server configuration used by 742 the device."; 744 leaf address { 745 type inet:host; 746 description 747 "The address of the RADIUS server."; 748 } 749 leaf port { 750 type inet:port-number; 751 default "1812"; 752 description 753 "The port number of the RADIUS server."; 754 } 755 leaf shared-secret { 756 type string; 757 nacm:very-secure; 758 description 759 "The shared secret which is known to both the RADIUS 760 client and server."; 761 reference 762 "RFC 2865: Remote Authentication Dial In User Service"; 763 } 764 } 765 container options { 766 description 767 "RADIUS client options."; 769 leaf timeout { 770 type uint8; 771 units "seconds"; 772 default "5"; 773 description 774 "The number of seconds the device will wait for a 775 response from a RADIUS server before trying with a 776 different server."; 777 } 778 leaf attempts { 779 type uint8; 780 default "2"; 781 description 782 "The number of times the device will send a query to 783 the RADIUS servers before giving up."; 784 } 785 } 786 } 788 list user { 789 if-feature local-users; 790 key name; 792 description 793 "The list of local users configured on this device."; 795 leaf name { 796 type string; 797 description 798 "The user name string identifying this entry."; 799 } 800 leaf password { 801 type crypt-hash; 802 description 803 "The password for this entry."; 804 } 805 leaf ssh-dsa { 806 type binary; 807 description 808 "The public DSA key for this entry."; 809 } 810 leaf ssh-rsa { 811 type binary; 812 description 813 "The public RSA key for this entry."; 814 } 815 } 816 } 817 } 819 rpc set-current-datetime { 820 nacm:secure; 821 description 822 "Manually set the /system/clock/current-datetime leaf 823 to the specified value. 825 If the /system/ntp/ntp-in-use leaf exists and 826 is set to 'true', then this operation will 827 fail with error-tag 'operation-failed', 828 and error-app-tag value of 'ntp-active'"; 829 input { 830 leaf current-datetime { 831 description 832 "The current system date and time."; 833 type yang:date-and-time; 834 mandatory true; 835 } 836 } 837 } 839 } 841 843 5. IANA Considerations 845 This document registers a URI in the IETF XML registry [RFC3688]. 846 Following the format in RFC 3688, the following registration is 847 requested to be made. 849 URI: urn:ietf:params:xml:ns:yang:ietf-system 851 Registrant Contact: The NETMOD WG of the IETF. 853 XML: N/A, the requested URI is an XML namespace. 855 This document registers a YANG module in the YANG Module Names 856 registry [RFC6020]. 858 name: ietf-system 859 namespace: urn:ietf:params:xml:ns:yang:ietf-system 860 prefix: sys 861 reference: RFC XXXX 863 6. Security Considerations 865 TBD. 867 7. Normative References 869 [I-D.ietf-netconf-rfc4742bis] 870 Wasserman, M. and T. Goddard, "Using the NETCONF 871 Configuration Protocol over Secure Shell (SSH)", 872 draft-ietf-netconf-rfc4742bis-08 (work in progress), 873 March 2011. 875 [I-D.lear-iana-timezone-database] 876 Lear, E. and P. Eggert, "IANA Procedures for Maintaining 877 the Timezone Database", 878 draft-lear-iana-timezone-database-04 (work in progress), 879 May 2011. 881 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 882 Requirement Levels", BCP 14, RFC 2119, March 1997. 884 [RFC3688] Mealling, M., "The IETF XML Registry", BCP 81, RFC 3688, 885 January 2004. 887 [RFC4252] Ylonen, T. and C. Lonvick, "The Secure Shell (SSH) 888 Authentication Protocol", RFC 4252, January 2006. 890 [RFC4253] Ylonen, T. and C. Lonvick, "The Secure Shell (SSH) 891 Transport Layer Protocol", RFC 4253, January 2006. 893 [RFC6020] Bjorklund, M., "YANG - A Data Modeling Language for the 894 Network Configuration Protocol (NETCONF)", RFC 6020, 895 October 2010. 897 Authors' Addresses 899 Andy Bierman 900 Brocade 902 Email: andy.bierman@brocade.com 904 Martin Bjorklund 905 Tail-f Systems 907 Email: mbj@tail-f.com