idnits 2.17.1 draft-ietf-netmod-system-mgmt-15.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 246 has weird spacing: '...address ine...' == Line 268 has weird spacing: '...rw name str...' == Line 272 has weird spacing: '...address ine...' == Line 338 has weird spacing: '...gorithm str...' == 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 (April 29, 2014) is 3649 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) -- Possible downref: Non-RFC (?) normative reference: ref. 'IEEE-1003.1-2008' ** Downref: Normative reference to an Informational RFC: RFC 1321 ** Obsolete normative reference: RFC 5226 (Obsoleted by RFC 8126) ** Obsolete normative reference: RFC 5966 (Obsoleted by RFC 7766) ** Downref: Normative reference to an Informational RFC: RFC 6151 ** Obsolete normative reference: RFC 6536 (Obsoleted by RFC 8341) Summary: 5 errors (**), 0 flaws (~~), 6 warnings (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group A. Bierman 3 Internet-Draft YumaWorks 4 Intended status: Standards Track M. Bjorklund 5 Expires: October 31, 2014 Tail-f Systems 6 April 29, 2014 8 A YANG Data Model for System Management 9 draft-ietf-netmod-system-mgmt-15 11 Abstract 13 This document defines a YANG data model for the configuration and 14 identification of some common system properties within a device 15 containing a NETCONF server. This includes data node definitions for 16 system identification, time-of-day management, user management, DNS 17 resolver configuration, and some protocol operations for system 18 management. 20 Status of this Memo 22 This Internet-Draft is submitted in full conformance with the 23 provisions of BCP 78 and BCP 79. 25 Internet-Drafts are working documents of the Internet Engineering 26 Task Force (IETF). Note that other groups may also distribute 27 working documents as Internet-Drafts. The list of current Internet- 28 Drafts is at http://datatracker.ietf.org/drafts/current/. 30 Internet-Drafts are draft documents valid for a maximum of six months 31 and may be updated, replaced, or obsoleted by other documents at any 32 time. It is inappropriate to use Internet-Drafts as reference 33 material or to cite them other than as "work in progress." 35 This Internet-Draft will expire on October 31, 2014. 37 Copyright Notice 39 Copyright (c) 2014 IETF Trust and the persons identified as the 40 document authors. All rights reserved. 42 This document is subject to BCP 78 and the IETF Trust's Legal 43 Provisions Relating to IETF Documents 44 (http://trustee.ietf.org/license-info) in effect on the date of 45 publication of this document. Please review these documents 46 carefully, as they describe your rights and restrictions with respect 47 to this document. Code Components extracted from this document must 48 include Simplified BSD License text as described in Section 4.e of 49 the Trust Legal Provisions and are provided without warranty as 50 described in the Simplified BSD License. 52 Table of Contents 54 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 55 1.1. Terminology . . . . . . . . . . . . . . . . . . . . . . . 3 56 1.2. Tree Diagrams . . . . . . . . . . . . . . . . . . . . . . 3 57 2. Objectives . . . . . . . . . . . . . . . . . . . . . . . . . . 5 58 2.1. System Identification . . . . . . . . . . . . . . . . . . 5 59 2.2. System Time Management . . . . . . . . . . . . . . . . . . 5 60 2.3. User Authentication . . . . . . . . . . . . . . . . . . . 5 61 2.4. DNS Resolver . . . . . . . . . . . . . . . . . . . . . . . 5 62 2.5. System Control . . . . . . . . . . . . . . . . . . . . . . 6 63 3. System Data Model . . . . . . . . . . . . . . . . . . . . . . 7 64 3.1. System Identification . . . . . . . . . . . . . . . . . . 7 65 3.2. System Time Management . . . . . . . . . . . . . . . . . . 7 66 3.3. DNS Resolver Model . . . . . . . . . . . . . . . . . . . . 8 67 3.4. RADIUS Client Model . . . . . . . . . . . . . . . . . . . 8 68 3.5. User Authentication Model . . . . . . . . . . . . . . . . 9 69 3.5.1. SSH Public Key Authentication . . . . . . . . . . . . 9 70 3.5.2. Local User Password Authentication . . . . . . . . . . 10 71 3.5.3. RADIUS Password Authentication . . . . . . . . . . . . 10 72 3.6. System Control . . . . . . . . . . . . . . . . . . . . . . 10 73 4. Relationship to the SNMPv2-MIB . . . . . . . . . . . . . . . . 11 74 5. IANA Crypt Hash YANG module . . . . . . . . . . . . . . . . . 12 75 6. System YANG module . . . . . . . . . . . . . . . . . . . . . . 15 76 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 32 77 8. Security Considerations . . . . . . . . . . . . . . . . . . . 33 78 9. Change Log . . . . . . . . . . . . . . . . . . . . . . . . . . 35 79 9.1. 00-01 . . . . . . . . . . . . . . . . . . . . . . . . . . 35 80 9.2. 01-02 . . . . . . . . . . . . . . . . . . . . . . . . . . 35 81 9.3. 02-03 . . . . . . . . . . . . . . . . . . . . . . . . . . 35 82 9.4. 03-04 . . . . . . . . . . . . . . . . . . . . . . . . . . 35 83 9.5. 04-05 . . . . . . . . . . . . . . . . . . . . . . . . . . 35 84 9.6. 05-06 . . . . . . . . . . . . . . . . . . . . . . . . . . 36 85 9.7. 06-07 . . . . . . . . . . . . . . . . . . . . . . . . . . 36 86 9.8. 07-08 . . . . . . . . . . . . . . . . . . . . . . . . . . 37 87 9.9. 08-09 . . . . . . . . . . . . . . . . . . . . . . . . . . 37 88 9.10. 09-10 . . . . . . . . . . . . . . . . . . . . . . . . . . 37 89 9.11. 11-12 . . . . . . . . . . . . . . . . . . . . . . . . . . 37 90 9.12. 13-14 . . . . . . . . . . . . . . . . . . . . . . . . . . 37 91 9.13. 14-15 . . . . . . . . . . . . . . . . . . . . . . . . . . 37 92 10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 38 93 10.1. Normative References . . . . . . . . . . . . . . . . . . . 38 94 10.2. Informative References . . . . . . . . . . . . . . . . . . 39 95 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 40 97 1. Introduction 99 This document defines a YANG [RFC6020] data model for the 100 configuration and identification of some common properties within a 101 device containing a NETCONF server. 103 Devices that are managed by NETCONF and perhaps other mechanisms have 104 common properties that need to be configured and monitored in a 105 standard way. 107 The "ietf-system" YANG module defined in this document provides the 108 following features: 110 o system identification configuration and monitoring 112 o system time-of-day configuration and monitoring 114 o user authentication configuration 116 o local users configuration 118 o DNS resolver configuration 120 o system control operations (shutdown, restart, setting time) 122 1.1. Terminology 124 The keywords "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 125 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 126 "OPTIONAL" in this document are to be interpreted as described in BCP 127 14, [RFC2119]. 129 The following terms are defined in [RFC6241] and are not redefined 130 here: 132 o client 134 o configuration data 136 o server 138 o state data 140 1.2. Tree Diagrams 142 A simplified graphical representation of the data model is used in 143 this document. The meaning of the symbols in these diagrams is as 144 follows: 146 o Brackets "[" and "]" enclose list keys. 148 o Abbreviations before data node names: "rw" means configuration 149 (read-write) and "ro" state data (read-only). 151 o Symbols after data node names: "?" means an optional node, "!" 152 means a presence container, and "*" denotes a list and leaf-list. 154 o Parentheses enclose choice and case nodes, and case nodes are also 155 marked with a colon (":"). 157 o Ellipsis ("...") stands for contents of subtrees that are not 158 shown. 160 2. Objectives 162 2.1. System Identification 164 There are many common properties used to identify devices, operating 165 systems, software versions, etc. that need to be supported in the 166 system data module. These objects are defined as operational state 167 data and the information returned by the server is intended to be 168 specific to the device vendor. 170 Some user-configurable administrative strings are also provided, such 171 as the system location and description. 173 2.2. System Time Management 175 The management of the date and time used by the system need to be 176 supported. Use of one or more NTP servers to automatically set the 177 system date and time need to be possible. Utilization of the 178 Timezone database [RFC6557] also need to be supported. It should be 179 possible to configure the system to use NTP. 181 2.3. User Authentication 183 The authentication mechanism needs to support password authentication 184 over RADIUS, to support deployment scenarios with centralized 185 authentication servers. Additionally, local users need to be 186 supported, for scenarios when no centralized authentication server 187 exists, or for situations where the centralized authentication server 188 cannot be reached from the device. 190 Since the mandatory transport protocol for NETCONF is SSH [RFC6242] 191 the authentication model needs to support SSH's "publickey" and 192 "password" authentication methods [RFC4252]. 194 The model for authentication configuration should be flexible enough 195 to support authentication methods defined by other standard documents 196 or by vendors. It should be possible to configure the system 197 authentication properties. 199 2.4. DNS Resolver 201 The configuration of the DNS resolver within the system containing 202 the NETCONF server is required in order to control how domain names 203 are resolved. 205 2.5. System Control 207 A few operations are needed to support common tasks such as 208 restarting the device or setting the system date and time. 210 3. System Data Model 212 3.1. System Identification 214 The data model for system identification has the following structure: 216 +--rw system 217 | +--rw contact? string 218 | +--rw hostname? inet:domain-name 219 | +--rw location? string 220 +--ro system-state 221 +--ro platform 222 +--ro os-name? string 223 +--ro os-release? string 224 +--ro os-version? string 225 +--ro machine? string 227 3.2. System Time Management 229 The data model for system time management has the following 230 structure: 232 +--rw system 233 | +--rw clock 234 | | +--rw (timezone)? 235 | | +--:(timezone-name) 236 | | | +--rw timezone-name? timezone-name 237 | | +--:(timezone-utc-offset) 238 | | +--rw timezone-utc-offset? int16 239 | +--rw ntp! 240 | +--rw enabled? boolean 241 | +--rw server* [name] 242 | +--rw name string 243 | +--rw (transport) 244 | | +--:(udp) 245 | | +--rw udp 246 | | +--rw address inet:host 247 | | +--rw port? inet:port-number 248 | +--rw association-type? enumeration 249 | +--rw iburst? boolean 250 | +--rw prefer? boolean 251 +--ro system-state 252 +--ro clock 253 +--ro current-datetime? yang:date-and-time 254 +--ro boot-datetime? yang:date-and-time 256 New "case" statements can be added over time or augmented to the 257 "transport" choice to support other transport protocols. 259 3.3. DNS Resolver Model 261 The data model for configuration of the DNS resolver has the 262 following structure: 264 +--rw system 265 +--rw dns-resolver 266 +--rw search* inet:domain-name 267 +--rw server* [name] 268 | +--rw name string 269 | +--rw (transport) 270 | +--:(udp-and-tcp) 271 | +--udp-and-tcp 272 | +--rw address inet:ip-address 273 | +--rw port? inet:port-number 274 +--rw options 275 +--rw timeout? uint8 276 +--rw attempts? uint8 278 New "case" statements can be added over time or augmented to the 279 "transport" choice to support other transport protocols. 281 3.4. RADIUS Client Model 283 The data model for configuration of the RADIUS client has the 284 following structure: 286 +--rw system 287 +--rw radius 288 +--rw server* [name] 289 | +--rw name string 290 | +--rw (transport) 291 | | +--:(udp) 292 | | +--rw udp 293 | | +--rw address inet:host 294 | | +--rw authentication-port? inet:port-number 295 | | +--rw shared-secret string 296 | +--rw authentication-type? identityref 297 +--rw options 298 +--rw timeout? uint8 299 +--rw attempts? uint8 301 New "case" statements can be added over time or augmented to the 302 "transport" choice to support other transport protocols. 304 3.5. User Authentication Model 306 This document defines three authentication methods for use with 307 NETCONF: 309 o publickey for local users over SSH 311 o password for local users over any secure transport 313 o password for RADIUS users over any secure transport 315 Additional methods can be defined by other standard documents or by 316 vendors. 318 This document defines two optional YANG features, "local-users" and 319 "radius-authentication", which the server advertises to indicate 320 support for configuring local users on the device, and support for 321 using RADIUS for authentication, respectively. 323 The authentication parameters defined in this document are primarily 324 used to configure authentication of NETCONF users, but MAY also be 325 used by other interfaces, e.g., a Command Line Interface or a Web- 326 based User Interface. 328 The data model for user authentication has the following structure: 330 +--rw system 331 +--rw authentication 332 +--rw user-authentication-order* identityref 333 +--rw user* [name] 334 +--rw name string 335 +--rw password? ianach:crypt-hash 336 +--rw ssh-key* [name] 337 +--rw name string 338 +--rw algorithm string 339 +--rw key-data binary 341 3.5.1. SSH Public Key Authentication 343 If the NETCONF server advertises the "local-users" feature, 344 configuration of local users and their SSH public keys is supported 345 in the /system/authentication/user list. 347 Public key authentication is requested by the SSH client. If the 348 "local-users" feature is supported, then when a NETCONF client starts 349 an SSH session towards the server using the "publickey" 350 authentication "method name" [RFC4252], the SSH server looks up the 351 user name given in the SSH authentication request in the /system/ 352 authentication/user list, and verifies the key as described in 353 [RFC4253]. 355 3.5.2. Local User Password Authentication 357 If the NETCONF server advertises the "local-users" feature, 358 configuration of local users and their passwords is supported in the 359 /system/authentication/user list. 361 For NETCONF transport protocols that support password authentication, 362 the leaf-list "user-authentication-order" is used to control if local 363 user password authentication should be used. 365 In SSH, password authentication is requested by the client. Other 366 NETCONF transport protocols MAY also support password authentication. 368 When local user password authentication is requested, the NETCONF 369 transport looks up the user name provided by the client in the 370 /system/authentication/user list, and verifies the password. 372 3.5.3. RADIUS Password Authentication 374 If the NETCONF server advertises the "radius-authentication" feature, 375 the device supports user authentication using RADIUS. 377 For NETCONF transport protocols that support password authentication, 378 the leaf-list "user-authentication-order" is used to control if 379 RADIUS password authentication should be used. 381 In SSH, password authentication is requested by the client. Other 382 NETCONF transport protocols MAY also support password authentication. 384 3.6. System Control 386 The following operations are defined: 388 set-current-datetime 389 system-restart 390 system-shutdown 392 Two protocol operations are included to restart or shutdown the 393 system. The 'system-restart' operation can be used to restart the 394 entire system (not just the NETCONF server). The 'system-shutdown' 395 operation can be used to power off the entire system. 397 4. Relationship to the SNMPv2-MIB 399 If a device implements the SNMPv2-MIB [RFC3418], there are two 400 objects that MAY be mapped by the implementation. See the YANG 401 module definition in Section 6 for details. The following table 402 lists the YANG data nodes with corresponding objects in the SNMPv2- 403 MIB. 405 +----------------+-------------------+ 406 | YANG data node | SNMPv2-MIB object | 407 +----------------+-------------------+ 408 | contact | sysContact | 409 | location | sysLocation | 410 +----------------+-------------------+ 412 YANG interface configuration data nodes and related SNMPv2-MIB 413 objects 415 5. IANA Crypt Hash YANG module 417 This YANG module references [RFC1321], [IEEE-1003.1-2008], and 418 [FIPS.180-3.2008]. 420 file "iana-crypt-hash@2014-04-04.yang" 422 module iana-crypt-hash { 423 namespace "urn:ietf:params:xml:ns:yang:iana-crypt-hash"; 424 prefix ianach; 426 organization "IANA"; 427 contact 428 " Internet Assigned Numbers Authority 430 Postal: ICANN 431 4676 Admiralty Way, Suite 330 432 Marina del Rey, CA 90292 434 Tel: +1 310 823 9358 435 E-Mail: iana&iana.org"; 436 description 437 "This YANG module defines a typedef for storing passwords 438 using a hash function, and features to indicate which hash 439 functions are supported by an implementation. 441 The latest revision of this YANG module can be obtained from 442 the IANA web site. 444 Requests for new values should be made to IANA via 445 email (iana&iana.org). 447 Copyright (c) 2014 IETF Trust and the persons identified as 448 authors of the code. All rights reserved. 450 Redistribution and use in source and binary forms, with or 451 without modification, is permitted pursuant to, and subject 452 to the license terms contained in, the Simplified BSD License 453 set forth in Section 4.c of the IETF Trust's Legal Provisions 454 Relating to IETF Documents 455 (http://trustee.ietf.org/license-info). 457 The initial version of this YANG module is part of RFC XXXX; 458 see the RFC itself for full legal notices."; 459 // RFC Ed.: replace XXXX with actual RFC number and remove this 460 // note. 462 // RFC Ed.: update the date below with the date of RFC publication 463 // and remove this note. 464 revision 2014-04-04 { 465 description 466 "Initial revision."; 467 reference 468 "RFC XXXX: A YANG Data Model for System Management"; 469 } 471 typedef crypt-hash { 472 type string { 473 pattern 474 '$0$.*' 475 + '|$1$[a-zA-Z0-9./]{1,8}$[a-zA-Z0-9./]{22}' 476 + '|$5$(rounds=\d+$)?[a-zA-Z0-9./]{1,16}$[a-zA-Z0-9./]{43}' 477 + '|$6$(rounds=\d+$)?[a-zA-Z0-9./]{1,16}$[a-zA-Z0-9./]{86}'; 478 } 479 description 480 "The crypt-hash type is used to store passwords using 481 a hash function. The algorithms for applying the hash 482 function and encoding the result are implemented in 483 various UNIX systems as the function crypt(3). 485 A value of this type matches one of the forms: 487 $0$ 488 $$$ 489 $$$$ 491 The '$0$' prefix signals that the value is clear text. When 492 such a value is received by the server, a hash value is 493 calculated, and the string '$$$' or 494 $$$$ is prepended to the result. This 495 value is stored in the configuration data store. 497 If a value starting with '$$', where is not '0', is 498 received, the server knows that the value already represents a 499 hashed value, and stores it as is in the data store. 501 When a server needs to verify a password given by a user, it 502 finds the stored password hash string for that user, extracts 503 the salt, and calculates the hash with the salt and given 504 password as input. If the calculated hash value is the same 505 as the stored value, the password given by the client is 506 accepted. 508 This type defines the following hash functions: 510 id | hash function | feature 511 ---+---------------+------------------- 512 1 | MD5 | crypt-hash-md5 513 5 | SHA-256 | crypt-hash-sha-256 514 6 | SHA-512 | crypt-hash-sha-512 516 The server indicates support for the different hash functions 517 by advertising the corresponding feature."; 518 reference 519 "IEEE Std 1003.1-2008 - crypt() function 520 RFC 1321: The MD5 Message-Digest Algorithm 521 FIPS.180-3.2008: Secure Hash Standard"; 522 } 524 feature crypt-hash-md5 { 525 description 526 "Indicates that the device supports the MD5 527 hash function in 'crypt-hash' values"; 528 reference "RFC 1321: The MD5 Message-Digest Algorithm"; 529 } 531 feature crypt-hash-sha-256 { 532 description 533 "Indicates that the device supports the SHA-256 534 hash function in 'crypt-hash' values"; 535 reference "FIPS.180-3.2008: Secure Hash Standard"; 536 } 538 feature crypt-hash-sha-512 { 539 description 540 "Indicates that the device supports the SHA-512 541 hash function in 'crypt-hash' values"; 542 reference "FIPS.180-3.2008: Secure Hash Standard"; 543 } 545 } 547 549 6. System YANG module 551 This YANG module imports YANG extensions from [RFC6536], and imports 552 YANG types from [RFC6991]. It also references [RFC1035], [RFC2865], 553 [RFC3418], [RFC5607], [RFC5966], [RFC6557]. 555 RFC Ed.: update the date below with the date of RFC publication and 556 remove this note. 558 file "ietf-system@2014-04-04.yang" 560 module ietf-system { 561 namespace "urn:ietf:params:xml:ns:yang:ietf-system"; 562 prefix "sys"; 564 import ietf-yang-types { 565 prefix yang; 566 } 568 import ietf-inet-types { 569 prefix inet; 570 } 572 import ietf-netconf-acm { 573 prefix nacm; 574 } 576 import iana-crypt-hash { 577 prefix ianach; 578 } 580 organization 581 "IETF NETMOD (NETCONF Data Modeling Language) Working Group"; 583 contact 584 "WG Web: 585 WG List: 587 WG Chair: Thomas Nadeau 588 590 WG Chair: Juergen Schoenwaelder 591 593 Editor: Andy Bierman 594 596 Editor: Martin Bjorklund 597 "; 599 description 600 "This module contains a collection of YANG definitions for the 601 configuration and identification of some common system 602 properties within a device containing a NETCONF server. This 603 includes data node definitions for system identification, 604 time-of-day management, user management, DNS resolver 605 configuration, and some protocol operations for system 606 management. 608 Copyright (c) 2014 IETF Trust and the persons identified as 609 authors of the code. All rights reserved. 611 Redistribution and use in source and binary forms, with or 612 without modification, is permitted pursuant to, and subject 613 to the license terms contained in, the Simplified BSD License 614 set forth in Section 4.c of the IETF Trust's Legal Provisions 615 Relating to IETF Documents 616 (http://trustee.ietf.org/license-info). 618 This version of this YANG module is part of RFC XXXX; see 619 the RFC itself for full legal notices."; 621 // RFC Ed.: replace XXXX with actual RFC number and remove this 622 // note. 624 // RFC Ed.: remove this note 625 // Note: extracted from draft-ietf-netmod-system-mgmt-07.txt 627 // RFC Ed.: update the date below with the date of RFC publication 628 // and remove this note. 629 revision "2014-04-04" { 630 description 631 "Initial revision."; 632 reference 633 "RFC XXXX: A YANG Data Model for System Management"; 634 } 636 /* 637 * Typedefs 638 */ 640 typedef timezone-name { 641 type string; 642 description 643 "A timezone name as used by the Time Zone Database, sometimes 644 referred to as the 'Olson Database'. 646 The exact set of valid values is an implementation-specific 647 matter. Client discovery of the exact set of time zone names 648 for a particular server is out of scope."; 649 reference 650 "RFC 6557: Procedures for Maintaining the Time Zone Database"; 651 } 653 /* 654 * Features 655 */ 657 feature radius { 658 description 659 "Indicates that the device can be configured as a RADIUS 660 client."; 661 reference 662 "RFC 2865: Remote Authentication Dial In User Service " 663 + "(RADIUS)"; 664 } 666 feature authentication { 667 description 668 "Indicates that the device supports configuration 669 for user authentication."; 670 } 672 feature local-users { 673 if-feature authentication; 674 description 675 "Indicates that the device supports configuration of 676 local user authentication."; 677 } 679 feature radius-authentication { 680 if-feature radius; 681 if-feature authentication; 682 description 683 "Indicates that the device supports configuration of user 684 authentication over RADIUS."; 685 reference 686 "RFC 2865: Remote Authentication Dial In User Service (RADIUS) 687 RFC 5607: Remote Authentication Dial-In User Service (RADIUS) 688 Authorization for Network Access Server (NAS) 689 Management"; 690 } 692 feature ntp { 693 description 694 "Indicates that the device can be configured 695 to use one or more NTP servers to set the 696 system date and time."; 697 } 699 feature ntp-udp-port { 700 if-feature ntp; 701 description 702 "Indicates that the device supports the configuration of 703 the UDP port for NTP servers. 705 This is a 'feature' since many implementations do not support 706 any other port than the default port."; 707 } 709 feature timezone-name { 710 description 711 "Indicates that the local timezone on the device 712 can be configured to use the TZ database 713 to set the timezone and manage daylight savings time."; 714 reference 715 "RFC 6557: Procedures for Maintaining the Time Zone Database"; 716 } 718 feature dns-udp-tcp-port { 719 description 720 "Indicates that the device supports the configuration of 721 the UDP and TCP port for DNS servers. 723 This is a 'feature' since many implementations do not support 724 any other port than the default port."; 725 } 727 /* 728 * Identities 729 */ 731 identity authentication-method { 732 description 733 "Base identity for user authentication methods."; 734 } 736 identity radius { 737 base authentication-method; 738 description 739 "Indicates user authentication using RADIUS."; 740 reference 741 "RFC 2865: Remote Authentication Dial In User Service (RADIUS) 742 RFC 5607: Remote Authentication Dial-In User Service (RADIUS) 743 Authorization for Network Access Server (NAS) 744 Management"; 745 } 747 identity local-users { 748 base authentication-method; 749 description 750 "Indicates password-based authentication of locally 751 configured users."; 752 } 754 identity radius-authentication-type { 755 description 756 "Base identity for RADIUS authentication types."; 757 } 759 identity radius-pap { 760 base radius-authentication-type; 761 description 762 "The device requests PAP authentication from the RADIUS 763 server."; 764 reference 765 "RFC 2865: Remote Authentication Dial In User Service"; 766 } 768 identity radius-chap { 769 base radius-authentication-type; 770 description 771 "The device requests CHAP authentication from the RADIUS 772 server."; 773 reference 774 "RFC 2865: Remote Authentication Dial In User Service"; 775 } 777 /* 778 * Configuration data nodes 779 */ 781 container system { 782 description 783 "System group configuration."; 785 leaf contact { 786 type string; 787 description 788 "The administrator contact information for the system. 790 A server implementation MAY map this leaf to the sysContact 791 MIB object. Such an implementation needs to use some 792 mechanism to handle the differences in size and characters 793 allowed between this leaf and sysContact. The definition of 794 such a mechanism is outside the scope of this document."; 795 reference 796 "RFC 3418: Management Information Base (MIB) for the 797 Simple Network Management Protocol (SNMP) 798 SNMPv2-MIB.sysContact"; 799 } 800 leaf hostname { 801 type inet:domain-name; 802 description 803 "The name of the host. This name can be a single domain 804 label, or the fully qualified domain name of the host."; 805 } 806 leaf location { 807 type string; 808 description 809 "The system location. 811 A server implementation MAY map this leaf to the sysLocation 812 MIB object. Such an implementation needs to use some 813 mechanism to handle the differences in size and characters 814 allowed between this leaf and sysLocation. The definition 815 of such a mechanism is outside the scope of this document."; 816 reference 817 "RFC 3418: Management Information Base (MIB) for the 818 Simple Network Management Protocol (SNMP) 819 SNMPv2-MIB.sysLocation"; 820 } 822 container clock { 823 description 824 "Configuration of the system date and time properties."; 826 choice timezone { 827 description 828 "The system timezone information."; 830 case timezone-name { 831 if-feature timezone-name; 832 leaf timezone-name { 833 type timezone-name; 834 description 835 "The TZ database name to use for the system, such 836 as 'Europe/Stockholm'."; 837 } 839 } 840 case timezone-utc-offset { 841 leaf timezone-utc-offset { 842 type int16 { 843 range "-1500 .. 1500"; 844 } 845 units "minutes"; 846 description 847 "The number of minutes to add to UTC time to 848 identify the timezone for this system. For example, 849 'UTC - 8:00 hours' would be represented as '-480'. 850 Note that automatic daylight savings time adjustment 851 is not provided, if this object is used."; 852 } 853 } 854 } 855 } 857 container ntp { 858 if-feature ntp; 859 presence 860 "Enables the NTP client unless the 'enabled' leaf 861 (which defaults to 'true') is set to 'false'"; 862 description 863 "Configuration of the NTP client."; 865 leaf enabled { 866 type boolean; 867 default true; 868 description 869 "Indicates that the system should attempt 870 to synchronize the system clock with an 871 NTP server from the 'ntp/server' list."; 872 } 873 list server { 874 key name; 875 description 876 "List of NTP servers to use for 877 system clock synchronization. If '/system/ntp/enabled' 878 is 'true', then the system will attempt to 879 contact and utilize the specified NTP servers."; 881 leaf name { 882 type string; 883 description 884 "An arbitrary name for the NTP server."; 885 } 886 choice transport { 887 mandatory true; 888 description 889 "The transport protocol specific parameters for this 890 server."; 892 case udp { 893 container udp { 894 description 895 "Contains UDP specific configuration parameters 896 for NTP."; 897 leaf address { 898 type inet:host; 899 mandatory true; 900 description 901 "The address of the NTP server."; 902 } 903 leaf port { 904 if-feature ntp-udp-port; 905 type inet:port-number; 906 default 123; 907 description 908 "The port number of the NTP server."; 909 } 910 } 911 } 912 } 913 leaf association-type { 914 type enumeration { 915 enum server { 916 description 917 "Use client association mode. This device 918 will not provide synchronization to the 919 configured NTP server."; 920 } 921 enum peer { 922 description 923 "Use symmetric active association mode. 924 This device may provide synchronization 925 to the configured NTP server."; 926 } 927 enum pool { 928 description 929 "Use client association mode with one or 930 more of the NTP servers found by DNS 931 resolution of the domain name given by 932 the 'address' leaf. This device will not 933 provide synchronization to the servers."; 934 } 936 } 937 default server; 938 description 939 "The desired association type for this NTP server."; 940 } 941 leaf iburst { 942 type boolean; 943 default false; 944 description 945 "Indicates whether this server should enable burst 946 synchronization or not."; 947 } 948 leaf prefer { 949 type boolean; 950 default false; 951 description 952 "Indicates whether this server should be preferred 953 or not."; 954 } 955 } 956 } 958 container dns-resolver { 959 description 960 "Configuration of the DNS resolver."; 962 leaf-list search { 963 type inet:domain-name; 964 ordered-by user; 965 description 966 "An ordered list of domains to search when resolving 967 a host name."; 968 } 969 list server { 970 key name; 971 ordered-by user; 972 description 973 "List of the DNS servers that the resolver should query. 975 When the resolver is invoked by a calling application, it 976 sends the query to the first name server in this list. If 977 no response has been received within 'timeout' seconds, 978 the resolver continues with the next server in the list. 979 If no response is received from any server, the resolver 980 continues with the first server again. When the resolver 981 has traversed the list 'attempts' times without receiving 982 any response, it gives up and returns an error to the 983 calling application. 985 Implementations MAY limit the number of entries in this 986 list."; 988 leaf name { 989 type string; 990 description 991 "An arbitrary name for the DNS server."; 992 } 993 choice transport { 994 mandatory true; 995 description 996 "The transport protocol specific parameters for this 997 server."; 999 case udp-and-tcp { 1000 container udp-and-tcp { 1001 description 1002 "Contains UDP and TCP specific configuration 1003 parameters for DNS."; 1004 reference 1005 "RFC 1035: Domain Implementation and Specification 1006 RFC 5966: DNS over TCP"; 1008 leaf address { 1009 type inet:ip-address; 1010 mandatory true; 1011 description 1012 "The address of the DNS server."; 1013 } 1014 leaf port { 1015 if-feature dns-udp-tcp-port; 1016 type inet:port-number; 1017 default 53; 1018 description 1019 "The UDP and TCP port number of the DNS server."; 1020 } 1021 } 1022 } 1023 } 1024 } 1025 container options { 1026 description 1027 "Resolver options. The set of available options has been 1028 limited to those that are generally available across 1029 different resolver implementations, and generally 1030 useful."; 1031 leaf timeout { 1032 type uint8 { 1033 range "1..max"; 1034 } 1035 units "seconds"; 1036 default "5"; 1037 description 1038 "The amount of time the resolver will wait for a 1039 response from each remote name server before 1040 retrying the query via a different name server."; 1041 } 1042 leaf attempts { 1043 type uint8 { 1044 range "1..max"; 1045 } 1046 default "2"; 1047 description 1048 "The number of times the resolver will send a query to 1049 all its name servers before giving up and returning an 1050 error to the calling application."; 1051 } 1052 } 1053 } 1055 container radius { 1056 if-feature radius; 1058 description 1059 "Configuration of the RADIUS client."; 1061 list server { 1062 key name; 1063 ordered-by user; 1064 description 1065 "List of RADIUS servers used by the device. 1067 When the RADIUS client is invoked by a calling 1068 application, it sends the query to the first server in 1069 this list. If no response has been received within 1070 'timeout' seconds, the client continues with the next 1071 server in the list. If no response is received from any 1072 server, the client continues with the first server again. 1073 When the client has traversed the list 'attempts' times 1074 without receiving any response, it gives up and returns an 1075 error to the calling application."; 1077 leaf name { 1078 type string; 1079 description 1080 "An arbitrary name for the RADIUS server."; 1082 } 1083 choice transport { 1084 mandatory true; 1085 description 1086 "The transport protocol specific parameters for this 1087 server."; 1089 case udp { 1090 container udp { 1091 description 1092 "Contains UDP specific configuration parameters 1093 for RADIUS."; 1094 leaf address { 1095 type inet:host; 1096 mandatory true; 1097 description 1098 "The address of the RADIUS server."; 1099 } 1100 leaf authentication-port { 1101 type inet:port-number; 1102 default "1812"; 1103 description 1104 "The port number of the RADIUS server."; 1105 } 1106 leaf shared-secret { 1107 type string; 1108 mandatory true; 1109 nacm:default-deny-all; 1110 description 1111 "The shared secret which is known to both the 1112 RADIUS client and server."; 1113 reference 1114 "RFC 2865: Remote Authentication Dial In User 1115 Service"; 1116 } 1117 } 1118 } 1119 } 1120 leaf authentication-type { 1121 type identityref { 1122 base radius-authentication-type; 1123 } 1124 default radius-pap; 1125 description 1126 "The authentication type requested from the RADIUS 1127 server."; 1128 } 1129 } 1130 container options { 1131 description 1132 "RADIUS client options."; 1134 leaf timeout { 1135 type uint8 { 1136 range "1..max"; 1137 } 1138 units "seconds"; 1139 default "5"; 1140 description 1141 "The number of seconds the device will wait for a 1142 response from each RADIUS server before trying with a 1143 different server."; 1144 } 1145 leaf attempts { 1146 type uint8 { 1147 range "1..max"; 1148 } 1149 default "2"; 1150 description 1151 "The number of times the device will send a query to 1152 all its RADIUS servers before giving up."; 1153 } 1154 } 1155 } 1157 container authentication { 1158 nacm:default-deny-write; 1159 if-feature authentication; 1161 description 1162 "The authentication configuration subtree."; 1164 leaf-list user-authentication-order { 1165 type identityref { 1166 base authentication-method; 1167 } 1168 must '(. != "sys:radius" or ../../radius/server)' { 1169 error-message 1170 "When 'radius' is used, a RADIUS server" 1171 + " must be configured."; 1172 description 1173 "When 'radius' is used as an authentication method, 1174 a RADIUS server must be configured."; 1175 } 1176 ordered-by user; 1177 description 1178 "When the device authenticates a user with a password, 1179 it tries the authentication methods in this leaf-list in 1180 order. If authentication with one method fails, the next 1181 method is used. If no method succeeds, the user is 1182 denied access. 1184 An empty user-authentication-order leaf-list still allows 1185 authentication of users using mechanisms that do not 1186 involve a password. 1188 If the 'radius-authentication' feature is advertised by 1189 the NETCONF server, the 'radius' identity can be added to 1190 this list. 1192 If the 'local-users' feature is advertised by the 1193 NETCONF server, the 'local-users' identity can be 1194 added to this list."; 1195 } 1197 list user { 1198 if-feature local-users; 1199 key name; 1200 description 1201 "The list of local users configured on this device."; 1203 leaf name { 1204 type string; 1205 description 1206 "The user name string identifying this entry."; 1207 } 1208 leaf password { 1209 type ianach:crypt-hash; 1210 description 1211 "The password for this entry."; 1212 } 1213 list ssh-key { 1214 key name; 1215 description 1216 "A list of public SSH keys for this user."; 1217 reference 1218 "RFC 4253: The Secure Shell (SSH) Transport Layer 1219 Protocol"; 1221 leaf name { 1222 type string; 1223 description 1224 "An arbitrary name for the ssh key."; 1226 } 1227 leaf algorithm { 1228 type string; 1229 mandatory true; 1230 description 1231 "The public key algorithm name for this ssh key. 1233 Valid values are the values in the IANA Secure Shell 1234 (SSH) Protocol Parameters registry, Public Key 1235 Algorithm Names"; 1236 reference 1237 "IANA Secure Shell (SSH) Protocol Parameters registry, 1238 Public Key Algorithm Names"; 1239 } 1240 leaf key-data { 1241 type binary; 1242 mandatory true; 1243 description 1244 "The binary key data for this ssh key."; 1245 } 1246 } 1247 } 1248 } 1249 } 1251 /* 1252 * Operational state data nodes 1253 */ 1255 container system-state { 1256 config false; 1257 description 1258 "System group operational state."; 1260 container platform { 1261 description 1262 "Contains vendor-specific information for 1263 identifying the system platform and operating system."; 1264 reference 1265 "IEEE Std 1003.1-2008 - sys/utsname.h"; 1267 leaf os-name { 1268 type string; 1269 description 1270 "The name of the operating system in use, 1271 for example 'Linux'"; 1272 reference 1273 "IEEE Std 1003.1-2008 - utsname.sysname"; 1275 } 1276 leaf os-release { 1277 type string; 1278 description 1279 "The current release level of the operating 1280 system in use. This string MAY indicate 1281 the OS source code revision."; 1282 reference 1283 "IEEE Std 1003.1-2008 - utsname.release"; 1284 } 1285 leaf os-version { 1286 type string; 1287 description 1288 "The current version level of the operating 1289 system in use. This string MAY indicate 1290 the specific OS build date and target variant 1291 information."; 1292 reference 1293 "IEEE Std 1003.1-2008 - utsname.version"; 1294 } 1295 leaf machine { 1296 type string; 1297 description 1298 "A vendor-specific identifier string representing 1299 the hardware in use."; 1300 reference 1301 "IEEE Std 1003.1-2008 - utsname.machine"; 1302 } 1303 } 1305 container clock { 1306 description 1307 "Monitoring of the system 1308 date and time properties."; 1310 leaf current-datetime { 1311 type yang:date-and-time; 1312 description 1313 "The current system date and time."; 1314 } 1315 leaf boot-datetime { 1316 type yang:date-and-time; 1317 description 1318 "The system date and time when the system last restarted."; 1319 } 1320 } 1321 } 1322 rpc set-current-datetime { 1323 nacm:default-deny-all; 1324 description 1325 "Set the /system-state/clock/current-datetime leaf 1326 to the specified value. 1328 If the system is using NTP (i.e., /system/ntp/enabled 1329 is set to 'true'), then this operation will 1330 fail with error-tag 'operation-failed', 1331 and error-app-tag value of 'ntp-active'"; 1332 input { 1333 leaf current-datetime { 1334 type yang:date-and-time; 1335 mandatory true; 1336 description 1337 "The current system date and time."; 1338 } 1339 } 1340 } 1342 rpc system-restart { 1343 nacm:default-deny-all; 1344 description 1345 "Request that the entire system be restarted immediately. 1346 A server SHOULD send an rpc reply to the client before 1347 restarting the system."; 1348 } 1350 rpc system-shutdown { 1351 nacm:default-deny-all; 1352 description 1353 "Request that the entire system be shut down immediately. 1354 A server SHOULD send an rpc reply to the client before 1355 shutting down the system."; 1356 } 1358 } 1360 1362 7. IANA Considerations 1364 This document defines first version of the IANA-maintained 1365 "iana-crypt-hash" YANG module, which will allow for new hash 1366 algorithms to be added to the type "crypt-hash". An Expert Review, 1367 as defined by [RFC5226], is REQUIRED, for each modification. 1369 This document registers two URIs in the IETF XML registry [RFC3688]. 1370 Following the format in RFC 3688, the following registrations are 1371 requested to be made. 1373 URI: urn:ietf:params:xml:ns:yang:iana-crypt-hash 1374 Registrant Contact: The IESG. 1375 XML: N/A, the requested URI is an XML namespace. 1377 URI: urn:ietf:params:xml:ns:yang:ietf-system 1378 Registrant Contact: The IESG. 1379 XML: N/A, the requested URI is an XML namespace. 1381 This document registers two YANG modules in the YANG Module Names 1382 registry [RFC6020]. 1384 name: iana-crypt-hash 1385 namespace: urn:ietf:params:xml:ns:yang:iana-crypt-hash 1386 prefix: ianach 1387 reference: RFC XXXX 1389 name: ietf-system 1390 namespace: urn:ietf:params:xml:ns:yang:ietf-system 1391 prefix: sys 1392 reference: RFC XXXX 1394 8. Security Considerations 1396 The YANG modules defined in this memo are designed to be accessed via 1397 the NETCONF protocol [RFC6241]. The lowest NETCONF layer is the 1398 secure transport layer and the mandatory-to-implement secure 1399 transport is SSH [RFC6242]. Authorization for access to specific 1400 portions of conceptual data and operations within this module is 1401 provided by the NETCONF access control model (NACM) [RFC6536]. 1403 There are a number of data nodes defined in the "ietf-system" YANG 1404 module which are writable/creatable/deletable (i.e., config true, 1405 which is the default). These data nodes may be considered sensitive 1406 or vulnerable in some network environments. Write operations to 1407 these data nodes can have a negative effect on network operations. 1408 It is thus important to control write access (e.g., via edit-config) 1409 to these data nodes. These are the subtrees and data nodes and their 1410 sensitivity/vulnerability: 1412 o /system/clock/timezone: This choice contains the objects used to 1413 control the timezone used by the device. 1415 o /system/ntp: This container contains the objects used to control 1416 the Network Time Protocol servers used by the device. 1418 o /system/dns-resolver: This container contains the objects used to 1419 control the Domain Name System servers used by the device. 1421 o /system/radius: This container contains the objects used to 1422 control the Remote Authentication Dial-In User Service servers 1423 used by the device. 1425 o /system/authentication/user-authentication-order: This leaf 1426 controls how user login attempts are authenticated by the device. 1428 o /system/authentication/user: This list contains the local users 1429 enabled on the system. 1431 Some of the readable data nodes in the "ietf-system" YANG module may 1432 be considered sensitive or vulnerable in some network environments. 1433 It is thus important to control read access (e.g., via get, get- 1434 config, or notification) to these data nodes. These are the subtrees 1435 and data nodes and their sensitivity/vulnerability: 1437 o /system/platform: This container has objects which may help 1438 identify the specific NETCONF server and/or operating system 1439 implementation used on the device. 1441 o /system/authentication/user: This list has objects that may help 1442 identify the specific user names and password information in use 1443 on the device. 1445 Some of the remote procedure call (RPC) operations in the 1446 "ietf-system" YANG module may be considered sensitive or vulnerable 1447 in some network environments. It is thus important to control access 1448 to these operations. These are the operations and their sensitivity/ 1449 vulnerability: 1451 o set-current-datetime: Changes the current date and time on the 1452 device. 1454 o system-restart: Reboots the device. 1456 o system-shutdown: Shuts down the device. 1458 Since this document describes the use of RADIUS for purposes of 1459 authentication, it is vulnerable to all of the threats that are 1460 present in other RADIUS applications. For a discussion of such 1461 threats, see [RFC2865] and [RFC3162]. 1463 This document provides configuration parameters for SSH's "publickey" 1464 and "password" authentication mechanisms. Section 9.4 of [RFC4251] 1465 and section 11 of [RFC4252] discuss security considerations for these 1466 mechanisms. 1468 The "iana-crypt-hash" YANG module defines a type "crypt-hash" that 1469 can be used to store MD5 hashes. [RFC6151] discusses security 1470 considerations for MD5. The usage of MD5 is NOT RECOMMENDED. 1472 9. Change Log 1474 -- RFC Ed.: remove this section before publication. 1476 9.1. 00-01 1478 o added configuration-source identities 1480 o added configuration-source leaf to ntp and dns (via grouping) to 1481 choose configuration source 1483 o added association-type, iburst, prefer, and true leafs to the ntp- 1484 server list 1486 o extended the ssh keys for a user to a list of keys. support all 1487 defined key algorithms, not just dsa and rsa 1489 o clarified timezone-utc-offset description-stmt 1491 o removed '/system/ntp/server/true' leaf from data model 1493 9.2. 01-02 1495 o added default-stmts to ntp-server/iburst and ntp-server/prefer 1496 leafs 1498 o changed timezone-location leaf to use iana-timezone typedef 1499 instead of a string 1501 9.3. 02-03 1503 o removed configuration-source identities and leafs 1505 9.4. 03-04 1507 o removed ndots dns resolver option 1509 o added radius-authentication-type identity, and identities for pap 1510 and chap, and a leaf to control which authentication type to use 1511 when communicating with the radius server 1513 o made 0 an invalid value for timeouts and attempts 1515 9.5. 04-05 1517 o updated tree diagram explanation text 1519 9.6. 05-06 1521 o changed ntp/use-ntp to ntp/enabled 1523 o changed ntp/ntp-server to ntp/server 1525 o removed /system/platform/nodename leaf 1527 o changed /system/name to /system/hostname 1529 o simplified must expression in user-authentication-order 1531 o added optional rounds to sha hash definition 1533 o clarified the crypt-hash description 1535 o clarified ntp descriptions 1537 o clarified YANG module description to indicate that some system 1538 properties are supported, not the entire system 1540 o clarified that system identification values are vendor specific, 1541 not the data node objects 1543 o clarified sec. 2.2 and 2.3 to indicate that the server should also 1544 be capable of configuring these properties 1546 o changed /system/dns/search from inet:host to inet:domain-name 1548 o changed RFC6021 reference to 6021-bis 1550 o changed /system/platform/nodename to /system/platform/hostname 1552 o changed /system/radius/server/{leafs} to be within a choice and 1553 'udp' case statement so other transport specific parameters can 1554 augment this list or they can be added by the WG to a future 1555 version of this module. {leafs} are authentication-port and 1556 shared-secret. 1558 o updated YANG tree diagrams for objects added in -05 and -06 1560 9.7. 06-07 1562 o updated the Abstract and Introduction 1564 o updated Tree diagram notation 1565 o identify all external servers (dns, ntp, radius) by name instead 1566 of address, in order to make the data model extensible for 1567 additional transport protocol. 1569 o updated the Security Considerations section with a reference to 1570 NACM. 1572 9.8. 07-08 1574 o renamed the DNS transport to 'udp-and-tcp' and added references. 1576 o moved the operational state nodes into /system-state. 1578 9.9. 08-09 1580 o made "ntp" node a presence container 1582 o added reference to RFC 6151 1584 o updated reference from 6021-bis to RFC 6991 1586 o cleaned up usage of config false in the YANG module 1588 9.10. 09-10 1590 o clarified relationship with SNMPv2-MIB 1592 9.11. 11-12 1594 o added typedef "timezone-name", and removed reference to 1595 draft-ietf-netmod-iana-timezones 1597 9.12. 13-14 1599 o moved the "crypt-hash" typedef to an IANA maintained module. 1601 o updated security considerations to mention RADIUS threats. 1603 9.13. 14-15 1605 o updated security considerations to mention SSH authentication 1606 method threats. 1608 10. References 1610 10.1. Normative References 1612 [FIPS.180-3.2008] 1613 National Institute of Standards and Technology, "Secure 1614 Hash Standard", FIPS PUB 180-3, October 2008, . 1618 [IEEE-1003.1-2008] 1619 Institute of Electrical and Electronics Engineers, 1620 "POSIX.1-2008", IEEE Standard 1003.1, March 2008. 1622 [RFC1035] Mockapetris, P., "Domain names - implementation and 1623 specification", STD 13, RFC 1035, November 1987. 1625 [RFC1321] Rivest, R., "The MD5 Message-Digest Algorithm", RFC 1321, 1626 April 1992. 1628 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 1629 Requirement Levels", BCP 14, RFC 2119, March 1997. 1631 [RFC2865] Rigney, C., Willens, S., Rubens, A., and W. Simpson, 1632 "Remote Authentication Dial In User Service (RADIUS)", 1633 RFC 2865, June 2000. 1635 [RFC3162] Aboba, B., Zorn, G., and D. Mitton, "RADIUS and IPv6", 1636 RFC 3162, August 2001. 1638 [RFC3418] Presuhn, R., "Management Information Base (MIB) for the 1639 Simple Network Management Protocol (SNMP)", STD 62, 1640 RFC 3418, December 2002. 1642 [RFC4251] Ylonen, T. and C. Lonvick, "The Secure Shell (SSH) 1643 Protocol Architecture", RFC 4251, January 2006. 1645 [RFC4252] Ylonen, T. and C. Lonvick, "The Secure Shell (SSH) 1646 Authentication Protocol", RFC 4252, January 2006. 1648 [RFC4253] Ylonen, T. and C. Lonvick, "The Secure Shell (SSH) 1649 Transport Layer Protocol", RFC 4253, January 2006. 1651 [RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an 1652 IANA Considerations Section in RFCs", BCP 26, RFC 5226, 1653 May 2008. 1655 [RFC5607] Nelson, D. and G. Weber, "Remote Authentication Dial-In 1656 User Service (RADIUS) Authorization for Network Access 1657 Server (NAS) Management", RFC 5607, July 2009. 1659 [RFC5966] Bellis, R., "DNS Transport over TCP - Implementation 1660 Requirements", RFC 5966, August 2010. 1662 [RFC6020] Bjorklund, M., "YANG - A Data Modeling Language for the 1663 Network Configuration Protocol (NETCONF)", RFC 6020, 1664 October 2010. 1666 [RFC6151] Turner, S. and L. Chen, "Updated Security Considerations 1667 for the MD5 Message-Digest and the HMAC-MD5 Algorithms", 1668 RFC 6151, March 2011. 1670 [RFC6241] Enns, R., Ed., Bjorklund, M., Ed., Schoenwaelder, J., Ed., 1671 and A. Bierman, Ed., "Network Configuration Protocol 1672 (NETCONF)", RFC 6241, June 2011. 1674 [RFC6242] Wasserman, M., "Using the NETCONF Protocol over Secure 1675 Shell (SSH)", RFC 6242, June 2011. 1677 [RFC6536] Bierman, A. and M. Bjorklund, "Network Configuration 1678 Protocol (NETCONF) Access Control Model", RFC 6536, 1679 March 2012. 1681 [RFC6991] Schoenwaelder, J., "Common YANG Data Types", RFC 6991, 1682 July 2013. 1684 10.2. Informative References 1686 [RFC3688] Mealling, M., "The IETF XML Registry", BCP 81, RFC 3688, 1687 January 2004. 1689 [RFC6557] Lear, E. and P. Eggert, "Procedures for Maintaining the 1690 Time Zone Database", BCP 175, RFC 6557, February 2012. 1692 Authors' Addresses 1694 Andy Bierman 1695 YumaWorks 1697 Email: andy@yumaworks.com 1699 Martin Bjorklund 1700 Tail-f Systems 1702 Email: mbj@tail-f.com