idnits 2.17.1 draft-ietf-netmod-system-mgmt-14.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 245 has weird spacing: '...address ine...' == Line 267 has weird spacing: '...rw name str...' == Line 271 has weird spacing: '...address ine...' == Line 337 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 15, 2014) is 3662 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 17, 2014 Tail-f Systems 6 April 15, 2014 8 A YANG Data Model for System Management 9 draft-ietf-netmod-system-mgmt-14 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 17, 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 10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 38 92 10.1. Normative References . . . . . . . . . . . . . . . . . . . 38 93 10.2. Informative References . . . . . . . . . . . . . . . . . . 39 94 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 40 96 1. Introduction 98 This document defines a YANG [RFC6020] data model for the 99 configuration and identification of some common properties within a 100 device containing a NETCONF server. 102 Devices that are managed by NETCONF and perhaps other mechanisms have 103 common properties that need to be configured and monitored in a 104 standard way. 106 The "ietf-system" YANG module defined in this document provides the 107 following features: 109 o system identification configuration and monitoring 111 o system time-of-day configuration and monitoring 113 o user authentication configuration 115 o local users configuration 117 o DNS resolver configuration 119 o system control operations (shutdown, restart, setting time) 121 1.1. Terminology 123 The keywords "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 124 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 125 "OPTIONAL" in this document are to be interpreted as described in BCP 126 14, [RFC2119]. 128 The following terms are defined in [RFC6241] and are not redefined 129 here: 131 o client 133 o configuration data 135 o server 137 o state data 139 1.2. Tree Diagrams 141 A simplified graphical representation of the data model is used in 142 this document. The meaning of the symbols in these diagrams is as 143 follows: 145 o Brackets "[" and "]" enclose list keys. 147 o Abbreviations before data node names: "rw" means configuration 148 (read-write) and "ro" state data (read-only). 150 o Symbols after data node names: "?" means an optional node, "!" 151 means a presence container, and "*" denotes a list and leaf-list. 153 o Parentheses enclose choice and case nodes, and case nodes are also 154 marked with a colon (":"). 156 o Ellipsis ("...") stands for contents of subtrees that are not 157 shown. 159 2. Objectives 161 2.1. System Identification 163 There are many common properties used to identify devices, operating 164 systems, software versions, etc. that need to be supported in the 165 system data module. These objects are defined as operational state 166 data and the information returned by the server is intended to be 167 specific to the device vendor. 169 Some user-configurable administrative strings are also provided, such 170 as the system location and description. 172 2.2. System Time Management 174 The management of the date and time used by the system need to be 175 supported. Use of one or more NTP servers to automatically set the 176 system date and time need to be possible. Utilization of the 177 Timezone database [RFC6557] also need to be supported. It should be 178 possible to configure the system to use NTP. 180 2.3. User Authentication 182 The authentication mechanism needs to support password authentication 183 over RADIUS, to support deployment scenarios with centralized 184 authentication servers. Additionally, local users need to be 185 supported, for scenarios when no centralized authentication server 186 exists, or for situations where the centralized authentication server 187 cannot be reached from the device. 189 Since the mandatory transport protocol for NETCONF is SSH [RFC6242] 190 the authentication model needs to support SSH's "publickey" and 191 "password" authentication methods [RFC4252]. 193 The model for authentication configuration should be flexible enough 194 to support authentication methods defined by other standard documents 195 or by vendors. It should be possible to configure the system 196 authentication properties. 198 2.4. DNS Resolver 200 The configuration of the DNS resolver within the system containing 201 the NETCONF server is required in order to control how domain names 202 are resolved. 204 2.5. System Control 206 A few operations are needed to support common tasks such as 207 restarting the device or setting the system date and time. 209 3. System Data Model 211 3.1. System Identification 213 The data model for system identification has the following structure: 215 +--rw system 216 | +--rw contact? string 217 | +--rw hostname? inet:domain-name 218 | +--rw location? string 219 +--ro system-state 220 +--ro platform 221 +--ro os-name? string 222 +--ro os-release? string 223 +--ro os-version? string 224 +--ro machine? string 226 3.2. System Time Management 228 The data model for system time management has the following 229 structure: 231 +--rw system 232 | +--rw clock 233 | | +--rw (timezone)? 234 | | +--:(timezone-name) 235 | | | +--rw timezone-name? timezone-name 236 | | +--:(timezone-utc-offset) 237 | | +--rw timezone-utc-offset? int16 238 | +--rw ntp! 239 | +--rw enabled? boolean 240 | +--rw server* [name] 241 | +--rw name string 242 | +--rw (transport) 243 | | +--:(udp) 244 | | +--rw udp 245 | | +--rw address inet:host 246 | | +--rw port? inet:port-number 247 | +--rw association-type? enumeration 248 | +--rw iburst? boolean 249 | +--rw prefer? boolean 250 +--ro system-state 251 +--ro clock 252 +--ro current-datetime? yang:date-and-time 253 +--ro boot-datetime? yang:date-and-time 255 New "case" statements can be added over time or augmented to the 256 "transport" choice to support other transport protocols. 258 3.3. DNS Resolver Model 260 The data model for configuration of the DNS resolver has the 261 following structure: 263 +--rw system 264 +--rw dns-resolver 265 +--rw search* inet:domain-name 266 +--rw server* [name] 267 | +--rw name string 268 | +--rw (transport) 269 | +--:(udp-and-tcp) 270 | +--udp-and-tcp 271 | +--rw address inet:ip-address 272 | +--rw port? inet:port-number 273 +--rw options 274 +--rw timeout? uint8 275 +--rw attempts? uint8 277 New "case" statements can be added over time or augmented to the 278 "transport" choice to support other transport protocols. 280 3.4. RADIUS Client Model 282 The data model for configuration of the RADIUS client has the 283 following structure: 285 +--rw system 286 +--rw radius 287 +--rw server* [name] 288 | +--rw name string 289 | +--rw (transport) 290 | | +--:(udp) 291 | | +--rw udp 292 | | +--rw address inet:host 293 | | +--rw authentication-port? inet:port-number 294 | | +--rw shared-secret string 295 | +--rw authentication-type? identityref 296 +--rw options 297 +--rw timeout? uint8 298 +--rw attempts? uint8 300 New "case" statements can be added over time or augmented to the 301 "transport" choice to support other transport protocols. 303 3.5. User Authentication Model 305 This document defines three authentication methods for use with 306 NETCONF: 308 o publickey for local users over SSH 310 o password for local users over any secure transport 312 o password for RADIUS users over any secure transport 314 Additional methods can be defined by other standard documents or by 315 vendors. 317 This document defines two optional YANG features, "local-users" and 318 "radius-authentication", which the server advertises to indicate 319 support for configuring local users on the device, and support for 320 using RADIUS for authentication, respectively. 322 The authentication parameters defined in this document are primarily 323 used to configure authentication of NETCONF users, but MAY also be 324 used by other interfaces, e.g., a Command Line Interface or a Web- 325 based User Interface. 327 The data model for user authentication has the following structure: 329 +--rw system 330 +--rw authentication 331 +--rw user-authentication-order* identityref 332 +--rw user* [name] 333 +--rw name string 334 +--rw password? ianach:crypt-hash 335 +--rw ssh-key* [name] 336 +--rw name string 337 +--rw algorithm string 338 +--rw key-data binary 340 3.5.1. SSH Public Key Authentication 342 If the NETCONF server advertises the "local-users" feature, 343 configuration of local users and their SSH public keys is supported 344 in the /system/authentication/user list. 346 Public key authentication is requested by the SSH client. If the 347 "local-users" feature is supported, then when a NETCONF client starts 348 an SSH session towards the server using the "publickey" 349 authentication "method name" [RFC4252], the SSH server looks up the 350 user name given in the SSH authentication request in the /system/ 351 authentication/user list, and verifies the key as described in 352 [RFC4253]. 354 3.5.2. Local User Password Authentication 356 If the NETCONF server advertises the "local-users" feature, 357 configuration of local users and their passwords is supported in the 358 /system/authentication/user list. 360 For NETCONF transport protocols that support password authentication, 361 the leaf-list "user-authentication-order" is used to control if local 362 user password authentication should be used. 364 In SSH, password authentication is requested by the client. Other 365 NETCONF transport protocols MAY also support password authentication. 367 When local user password authentication is requested, the NETCONF 368 transport looks up the user name provided by the client in the 369 /system/authentication/user list, and verifies the password. 371 3.5.3. RADIUS Password Authentication 373 If the NETCONF server advertises the "radius-authentication" feature, 374 the device supports user authentication using RADIUS. 376 For NETCONF transport protocols that support password authentication, 377 the leaf-list "user-authentication-order" is used to control if 378 RADIUS password authentication should be used. 380 In SSH, password authentication is requested by the client. Other 381 NETCONF transport protocols MAY also support password authentication. 383 3.6. System Control 385 The following operations are defined: 387 set-current-datetime 388 system-restart 389 system-shutdown 391 Two protocol operations are included to restart or shutdown the 392 system. The 'system-restart' operation can be used to restart the 393 entire system (not just the NETCONF server). The 'system-shutdown' 394 operation can be used to power off the entire system. 396 4. Relationship to the SNMPv2-MIB 398 If a device implements the SNMPv2-MIB [RFC3418], there are two 399 objects that MAY be mapped by the implementation. See the YANG 400 module definition in Section 6 for details. The following table 401 lists the YANG data nodes with corresponding objects in the SNMPv2- 402 MIB. 404 +----------------+-------------------+ 405 | YANG data node | SNMPv2-MIB object | 406 +----------------+-------------------+ 407 | contact | sysContact | 408 | location | sysLocation | 409 +----------------+-------------------+ 411 YANG interface configuration data nodes and related SNMPv2-MIB 412 objects 414 5. IANA Crypt Hash YANG module 416 This YANG module references [RFC1321], [IEEE-1003.1-2008], and 417 [FIPS.180-3.2008]. 419 file "iana-crypt-hash@2014-04-04.yang" 421 module iana-crypt-hash { 422 namespace "urn:ietf:params:xml:ns:yang:iana-crypt-hash"; 423 prefix ianach; 425 organization "IANA"; 426 contact 427 " Internet Assigned Numbers Authority 429 Postal: ICANN 430 4676 Admiralty Way, Suite 330 431 Marina del Rey, CA 90292 433 Tel: +1 310 823 9358 434 E-Mail: iana&iana.org"; 435 description 436 "This YANG module defines a typedef for storing passwords 437 using a hash function, and features to indicate which hash 438 functions are supported by an implementation. 440 The latest revision of this YANG module can be obtained from 441 the IANA web site. 443 Requests for new values should be made to IANA via 444 email (iana&iana.org). 446 Copyright (c) 2014 IETF Trust and the persons identified as 447 authors of the code. All rights reserved. 449 Redistribution and use in source and binary forms, with or 450 without modification, is permitted pursuant to, and subject 451 to the license terms contained in, the Simplified BSD License 452 set forth in Section 4.c of the IETF Trust's Legal Provisions 453 Relating to IETF Documents 454 (http://trustee.ietf.org/license-info). 456 The initial version of this YANG module is part of RFC XXXX; 457 see the RFC itself for full legal notices."; 458 // RFC Ed.: replace XXXX with actual RFC number and remove this 459 // note. 461 // RFC Ed.: update the date below with the date of RFC publication 462 // and remove this note. 463 revision 2014-04-04 { 464 description 465 "Initial revision."; 466 reference 467 "RFC XXXX: A YANG Data Model for System Management"; 468 } 470 typedef crypt-hash { 471 type string { 472 pattern 473 '$0$.*' 474 + '|$1$[a-zA-Z0-9./]{1,8}$[a-zA-Z0-9./]{22}' 475 + '|$5$(rounds=\d+$)?[a-zA-Z0-9./]{1,16}$[a-zA-Z0-9./]{43}' 476 + '|$6$(rounds=\d+$)?[a-zA-Z0-9./]{1,16}$[a-zA-Z0-9./]{86}'; 477 } 478 description 479 "The crypt-hash type is used to store passwords using 480 a hash function. The algorithms for applying the hash 481 function and encoding the result are implemented in 482 various UNIX systems as the function crypt(3). 484 A value of this type matches one of the forms: 486 $0$ 487 $$$ 488 $$$$ 490 The '$0$' prefix signals that the value is clear text. When 491 such a value is received by the server, a hash value is 492 calculated, and the string '$$$' or 493 $$$$ is prepended to the result. This 494 value is stored in the configuration data store. 496 If a value starting with '$$', where is not '0', is 497 received, the server knows that the value already represents a 498 hashed value, and stores it as is in the data store. 500 When a server needs to verify a password given by a user, it 501 finds the stored password hash string for that user, extracts 502 the salt, and calculates the hash with the salt and given 503 password as input. If the calculated hash value is the same 504 as the stored value, the password given by the client is 505 accepted. 507 This type defines the following hash functions: 509 id | hash function | feature 510 ---+---------------+------------------- 511 1 | MD5 | crypt-hash-md5 512 5 | SHA-256 | crypt-hash-sha-256 513 6 | SHA-512 | crypt-hash-sha-512 515 The server indicates support for the different hash functions 516 by advertising the corresponding feature."; 517 reference 518 "IEEE Std 1003.1-2008 - crypt() function 519 RFC 1321: The MD5 Message-Digest Algorithm 520 FIPS.180-3.2008: Secure Hash Standard"; 521 } 523 feature crypt-hash-md5 { 524 description 525 "Indicates that the device supports the MD5 526 hash function in 'crypt-hash' values"; 527 reference "RFC 1321: The MD5 Message-Digest Algorithm"; 528 } 530 feature crypt-hash-sha-256 { 531 description 532 "Indicates that the device supports the SHA-256 533 hash function in 'crypt-hash' values"; 534 reference "FIPS.180-3.2008: Secure Hash Standard"; 535 } 537 feature crypt-hash-sha-512 { 538 description 539 "Indicates that the device supports the SHA-512 540 hash function in 'crypt-hash' values"; 541 reference "FIPS.180-3.2008: Secure Hash Standard"; 542 } 544 } 546 548 6. System YANG module 550 This YANG module imports YANG extensions from [RFC6536], and imports 551 YANG types from [RFC6991]. It also references [RFC1035], [RFC2865], 552 [RFC3418], [RFC5607], [RFC5966], [RFC6557]. 554 RFC Ed.: update the date below with the date of RFC publication and 555 remove this note. 557 file "ietf-system@2014-04-04.yang" 559 module ietf-system { 560 namespace "urn:ietf:params:xml:ns:yang:ietf-system"; 561 prefix "sys"; 563 import ietf-yang-types { 564 prefix yang; 565 } 567 import ietf-inet-types { 568 prefix inet; 569 } 571 import ietf-netconf-acm { 572 prefix nacm; 573 } 575 import iana-crypt-hash { 576 prefix ianach; 577 } 579 organization 580 "IETF NETMOD (NETCONF Data Modeling Language) Working Group"; 582 contact 583 "WG Web: 584 WG List: 586 WG Chair: Thomas Nadeau 587 589 WG Chair: Juergen Schoenwaelder 590 592 Editor: Andy Bierman 593 595 Editor: Martin Bjorklund 596 "; 598 description 599 "This module contains a collection of YANG definitions for the 600 configuration and identification of some common system 601 properties within a device containing a NETCONF server. This 602 includes data node definitions for system identification, 603 time-of-day management, user management, DNS resolver 604 configuration, and some protocol operations for system 605 management. 607 Copyright (c) 2014 IETF Trust and the persons identified as 608 authors of the code. All rights reserved. 610 Redistribution and use in source and binary forms, with or 611 without modification, is permitted pursuant to, and subject 612 to the license terms contained in, the Simplified BSD License 613 set forth in Section 4.c of the IETF Trust's Legal Provisions 614 Relating to IETF Documents 615 (http://trustee.ietf.org/license-info). 617 This version of this YANG module is part of RFC XXXX; see 618 the RFC itself for full legal notices."; 620 // RFC Ed.: replace XXXX with actual RFC number and remove this 621 // note. 623 // RFC Ed.: remove this note 624 // Note: extracted from draft-ietf-netmod-system-mgmt-07.txt 626 // RFC Ed.: update the date below with the date of RFC publication 627 // and remove this note. 628 revision "2014-04-04" { 629 description 630 "Initial revision."; 631 reference 632 "RFC XXXX: A YANG Data Model for System Management"; 633 } 635 /* 636 * Typedefs 637 */ 639 typedef timezone-name { 640 type string; 641 description 642 "A timezone name as used by the Time Zone Database, sometimes 643 referred to as the 'Olson Database'. 645 The exact set of valid values is an implementation-specific 646 matter. Client discovery of the exact set of time zone names 647 for a particular server is out of scope."; 648 reference 649 "RFC 6557: Procedures for Maintaining the Time Zone Database"; 650 } 652 /* 653 * Features 654 */ 656 feature radius { 657 description 658 "Indicates that the device can be configured as a RADIUS 659 client."; 660 reference 661 "RFC 2865: Remote Authentication Dial In User Service " 662 + "(RADIUS)"; 663 } 665 feature authentication { 666 description 667 "Indicates that the device supports configuration 668 for user authentication."; 669 } 671 feature local-users { 672 if-feature authentication; 673 description 674 "Indicates that the device supports configuration of 675 local user authentication."; 676 } 678 feature radius-authentication { 679 if-feature radius; 680 if-feature authentication; 681 description 682 "Indicates that the device supports configuration of user 683 authentication over RADIUS."; 684 reference 685 "RFC 2865: Remote Authentication Dial In User Service (RADIUS) 686 RFC 5607: Remote Authentication Dial-In User Service (RADIUS) 687 Authorization for Network Access Server (NAS) 688 Management"; 689 } 691 feature ntp { 692 description 693 "Indicates that the device can be configured 694 to use one or more NTP servers to set the 695 system date and time."; 696 } 698 feature ntp-udp-port { 699 if-feature ntp; 700 description 701 "Indicates that the device supports the configuration of 702 the UDP port for NTP servers. 704 This is a 'feature' since many implementations do not support 705 any other port than the default port."; 706 } 708 feature timezone-name { 709 description 710 "Indicates that the local timezone on the device 711 can be configured to use the TZ database 712 to set the timezone and manage daylight savings time."; 713 reference 714 "RFC 6557: Procedures for Maintaining the Time Zone Database"; 715 } 717 feature dns-udp-tcp-port { 718 description 719 "Indicates that the device supports the configuration of 720 the UDP and TCP port for DNS servers. 722 This is a 'feature' since many implementations do not support 723 any other port than the default port."; 724 } 726 /* 727 * Identities 728 */ 730 identity authentication-method { 731 description 732 "Base identity for user authentication methods."; 733 } 735 identity radius { 736 base authentication-method; 737 description 738 "Indicates user authentication using RADIUS."; 739 reference 740 "RFC 2865: Remote Authentication Dial In User Service (RADIUS) 741 RFC 5607: Remote Authentication Dial-In User Service (RADIUS) 742 Authorization for Network Access Server (NAS) 743 Management"; 744 } 746 identity local-users { 747 base authentication-method; 748 description 749 "Indicates password-based authentication of locally 750 configured users."; 751 } 753 identity radius-authentication-type { 754 description 755 "Base identity for RADIUS authentication types."; 756 } 758 identity radius-pap { 759 base radius-authentication-type; 760 description 761 "The device requests PAP authentication from the RADIUS 762 server."; 763 reference 764 "RFC 2865: Remote Authentication Dial In User Service"; 765 } 767 identity radius-chap { 768 base radius-authentication-type; 769 description 770 "The device requests CHAP authentication from the RADIUS 771 server."; 772 reference 773 "RFC 2865: Remote Authentication Dial In User Service"; 774 } 776 /* 777 * Configuration data nodes 778 */ 780 container system { 781 description 782 "System group configuration."; 784 leaf contact { 785 type string; 786 description 787 "The administrator contact information for the system. 789 A server implementation MAY map this leaf to the sysContact 790 MIB object. Such an implementation needs to use some 791 mechanism to handle the differences in size and characters 792 allowed between this leaf and sysContact. The definition of 793 such a mechanism is outside the scope of this document."; 794 reference 795 "RFC 3418: Management Information Base (MIB) for the 796 Simple Network Management Protocol (SNMP) 797 SNMPv2-MIB.sysContact"; 798 } 799 leaf hostname { 800 type inet:domain-name; 801 description 802 "The name of the host. This name can be a single domain 803 label, or the fully qualified domain name of the host."; 804 } 805 leaf location { 806 type string; 807 description 808 "The system location. 810 A server implementation MAY map this leaf to the sysLocation 811 MIB object. Such an implementation needs to use some 812 mechanism to handle the differences in size and characters 813 allowed between this leaf and sysLocation. The definition 814 of such a mechanism is outside the scope of this document."; 815 reference 816 "RFC 3418: Management Information Base (MIB) for the 817 Simple Network Management Protocol (SNMP) 818 SNMPv2-MIB.sysLocation"; 819 } 821 container clock { 822 description 823 "Configuration of the system date and time properties."; 825 choice timezone { 826 description 827 "The system timezone information."; 829 case timezone-name { 830 if-feature timezone-name; 831 leaf timezone-name { 832 type timezone-name; 833 description 834 "The TZ database name to use for the system, such 835 as 'Europe/Stockholm'."; 836 } 838 } 839 case timezone-utc-offset { 840 leaf timezone-utc-offset { 841 type int16 { 842 range "-1500 .. 1500"; 843 } 844 units "minutes"; 845 description 846 "The number of minutes to add to UTC time to 847 identify the timezone for this system. For example, 848 'UTC - 8:00 hours' would be represented as '-480'. 849 Note that automatic daylight savings time adjustment 850 is not provided, if this object is used."; 851 } 852 } 853 } 854 } 856 container ntp { 857 if-feature ntp; 858 presence 859 "Enables the NTP client unless the 'enabled' leaf 860 (which defaults to 'true') is set to 'false'"; 861 description 862 "Configuration of the NTP client."; 864 leaf enabled { 865 type boolean; 866 default true; 867 description 868 "Indicates that the system should attempt 869 to synchronize the system clock with an 870 NTP server from the 'ntp/server' list."; 871 } 872 list server { 873 key name; 874 description 875 "List of NTP servers to use for 876 system clock synchronization. If '/system/ntp/enabled' 877 is 'true', then the system will attempt to 878 contact and utilize the specified NTP servers."; 880 leaf name { 881 type string; 882 description 883 "An arbitrary name for the NTP server."; 884 } 885 choice transport { 886 mandatory true; 887 description 888 "The transport protocol specific parameters for this 889 server."; 891 case udp { 892 container udp { 893 description 894 "Contains UDP specific configuration parameters 895 for NTP."; 896 leaf address { 897 type inet:host; 898 mandatory true; 899 description 900 "The address of the NTP server."; 901 } 902 leaf port { 903 if-feature ntp-udp-port; 904 type inet:port-number; 905 default 123; 906 description 907 "The port number of the NTP server."; 908 } 909 } 910 } 911 } 912 leaf association-type { 913 type enumeration { 914 enum server { 915 description 916 "Use client association mode. This device 917 will not provide synchronization to the 918 configured NTP server."; 919 } 920 enum peer { 921 description 922 "Use symmetric active association mode. 923 This device may provide synchronization 924 to the configured NTP server."; 925 } 926 enum pool { 927 description 928 "Use client association mode with one or 929 more of the NTP servers found by DNS 930 resolution of the domain name given by 931 the 'address' leaf. This device will not 932 provide synchronization to the servers."; 933 } 935 } 936 default server; 937 description 938 "The desired association type for this NTP server."; 939 } 940 leaf iburst { 941 type boolean; 942 default false; 943 description 944 "Indicates whether this server should enable burst 945 synchronization or not."; 946 } 947 leaf prefer { 948 type boolean; 949 default false; 950 description 951 "Indicates whether this server should be preferred 952 or not."; 953 } 954 } 955 } 957 container dns-resolver { 958 description 959 "Configuration of the DNS resolver."; 961 leaf-list search { 962 type inet:domain-name; 963 ordered-by user; 964 description 965 "An ordered list of domains to search when resolving 966 a host name."; 967 } 968 list server { 969 key name; 970 ordered-by user; 971 description 972 "List of the DNS servers that the resolver should query. 974 When the resolver is invoked by a calling application, it 975 sends the query to the first name server in this list. If 976 no response has been received within 'timeout' seconds, 977 the resolver continues with the next server in the list. 978 If no response is received from any server, the resolver 979 continues with the first server again. When the resolver 980 has traversed the list 'attempts' times without receiving 981 any response, it gives up and returns an error to the 982 calling application. 984 Implementations MAY limit the number of entries in this 985 list."; 987 leaf name { 988 type string; 989 description 990 "An arbitrary name for the DNS server."; 991 } 992 choice transport { 993 mandatory true; 994 description 995 "The transport protocol specific parameters for this 996 server."; 998 case udp-and-tcp { 999 container udp-and-tcp { 1000 description 1001 "Contains UDP and TCP specific configuration 1002 parameters for DNS."; 1003 reference 1004 "RFC 1035: Domain Implementation and Specification 1005 RFC 5966: DNS over TCP"; 1007 leaf address { 1008 type inet:ip-address; 1009 mandatory true; 1010 description 1011 "The address of the DNS server."; 1012 } 1013 leaf port { 1014 if-feature dns-udp-tcp-port; 1015 type inet:port-number; 1016 default 53; 1017 description 1018 "The UDP and TCP port number of the DNS server."; 1019 } 1020 } 1021 } 1022 } 1023 } 1024 container options { 1025 description 1026 "Resolver options. The set of available options has been 1027 limited to those that are generally available across 1028 different resolver implementations, and generally 1029 useful."; 1030 leaf timeout { 1031 type uint8 { 1032 range "1..max"; 1033 } 1034 units "seconds"; 1035 default "5"; 1036 description 1037 "The amount of time the resolver will wait for a 1038 response from each remote name server before 1039 retrying the query via a different name server."; 1040 } 1041 leaf attempts { 1042 type uint8 { 1043 range "1..max"; 1044 } 1045 default "2"; 1046 description 1047 "The number of times the resolver will send a query to 1048 all its name servers before giving up and returning an 1049 error to the calling application."; 1050 } 1051 } 1052 } 1054 container radius { 1055 if-feature radius; 1057 description 1058 "Configuration of the RADIUS client."; 1060 list server { 1061 key name; 1062 ordered-by user; 1063 description 1064 "List of RADIUS servers used by the device. 1066 When the RADIUS client is invoked by a calling 1067 application, it sends the query to the first server in 1068 this list. If no response has been received within 1069 'timeout' seconds, the client continues with the next 1070 server in the list. If no response is received from any 1071 server, the client continues with the first server again. 1072 When the client has traversed the list 'attempts' times 1073 without receiving any response, it gives up and returns an 1074 error to the calling application."; 1076 leaf name { 1077 type string; 1078 description 1079 "An arbitrary name for the RADIUS server."; 1081 } 1082 choice transport { 1083 mandatory true; 1084 description 1085 "The transport protocol specific parameters for this 1086 server."; 1088 case udp { 1089 container udp { 1090 description 1091 "Contains UDP specific configuration parameters 1092 for RADIUS."; 1093 leaf address { 1094 type inet:host; 1095 mandatory true; 1096 description 1097 "The address of the RADIUS server."; 1098 } 1099 leaf authentication-port { 1100 type inet:port-number; 1101 default "1812"; 1102 description 1103 "The port number of the RADIUS server."; 1104 } 1105 leaf shared-secret { 1106 type string; 1107 mandatory true; 1108 nacm:default-deny-all; 1109 description 1110 "The shared secret which is known to both the 1111 RADIUS client and server."; 1112 reference 1113 "RFC 2865: Remote Authentication Dial In User 1114 Service"; 1115 } 1116 } 1117 } 1118 } 1119 leaf authentication-type { 1120 type identityref { 1121 base radius-authentication-type; 1122 } 1123 default radius-pap; 1124 description 1125 "The authentication type requested from the RADIUS 1126 server."; 1127 } 1128 } 1129 container options { 1130 description 1131 "RADIUS client options."; 1133 leaf timeout { 1134 type uint8 { 1135 range "1..max"; 1136 } 1137 units "seconds"; 1138 default "5"; 1139 description 1140 "The number of seconds the device will wait for a 1141 response from each RADIUS server before trying with a 1142 different server."; 1143 } 1144 leaf attempts { 1145 type uint8 { 1146 range "1..max"; 1147 } 1148 default "2"; 1149 description 1150 "The number of times the device will send a query to 1151 all its RADIUS servers before giving up."; 1152 } 1153 } 1154 } 1156 container authentication { 1157 nacm:default-deny-write; 1158 if-feature authentication; 1160 description 1161 "The authentication configuration subtree."; 1163 leaf-list user-authentication-order { 1164 type identityref { 1165 base authentication-method; 1166 } 1167 must '(. != "sys:radius" or ../../radius/server)' { 1168 error-message 1169 "When 'radius' is used, a RADIUS server" 1170 + " must be configured."; 1171 description 1172 "When 'radius' is used as an authentication method, 1173 a RADIUS server must be configured."; 1174 } 1175 ordered-by user; 1176 description 1177 "When the device authenticates a user with a password, 1178 it tries the authentication methods in this leaf-list in 1179 order. If authentication with one method fails, the next 1180 method is used. If no method succeeds, the user is 1181 denied access. 1183 An empty user-authentication-order leaf-list still allows 1184 authentication of users using mechanisms that do not 1185 involve a password. 1187 If the 'radius-authentication' feature is advertised by 1188 the NETCONF server, the 'radius' identity can be added to 1189 this list. 1191 If the 'local-users' feature is advertised by the 1192 NETCONF server, the 'local-users' identity can be 1193 added to this list."; 1194 } 1196 list user { 1197 if-feature local-users; 1198 key name; 1199 description 1200 "The list of local users configured on this device."; 1202 leaf name { 1203 type string; 1204 description 1205 "The user name string identifying this entry."; 1206 } 1207 leaf password { 1208 type ianach:crypt-hash; 1209 description 1210 "The password for this entry."; 1211 } 1212 list ssh-key { 1213 key name; 1214 description 1215 "A list of public SSH keys for this user."; 1216 reference 1217 "RFC 4253: The Secure Shell (SSH) Transport Layer 1218 Protocol"; 1220 leaf name { 1221 type string; 1222 description 1223 "An arbitrary name for the ssh key."; 1225 } 1226 leaf algorithm { 1227 type string; 1228 mandatory true; 1229 description 1230 "The public key algorithm name for this ssh key. 1232 Valid values are the values in the IANA Secure Shell 1233 (SSH) Protocol Parameters registry, Public Key 1234 Algorithm Names"; 1235 reference 1236 "IANA Secure Shell (SSH) Protocol Parameters registry, 1237 Public Key Algorithm Names"; 1238 } 1239 leaf key-data { 1240 type binary; 1241 mandatory true; 1242 description 1243 "The binary key data for this ssh key."; 1244 } 1245 } 1246 } 1247 } 1248 } 1250 /* 1251 * Operational state data nodes 1252 */ 1254 container system-state { 1255 config false; 1256 description 1257 "System group operational state."; 1259 container platform { 1260 description 1261 "Contains vendor-specific information for 1262 identifying the system platform and operating system."; 1263 reference 1264 "IEEE Std 1003.1-2008 - sys/utsname.h"; 1266 leaf os-name { 1267 type string; 1268 description 1269 "The name of the operating system in use, 1270 for example 'Linux'"; 1271 reference 1272 "IEEE Std 1003.1-2008 - utsname.sysname"; 1274 } 1275 leaf os-release { 1276 type string; 1277 description 1278 "The current release level of the operating 1279 system in use. This string MAY indicate 1280 the OS source code revision."; 1281 reference 1282 "IEEE Std 1003.1-2008 - utsname.release"; 1283 } 1284 leaf os-version { 1285 type string; 1286 description 1287 "The current version level of the operating 1288 system in use. This string MAY indicate 1289 the specific OS build date and target variant 1290 information."; 1291 reference 1292 "IEEE Std 1003.1-2008 - utsname.version"; 1293 } 1294 leaf machine { 1295 type string; 1296 description 1297 "A vendor-specific identifier string representing 1298 the hardware in use."; 1299 reference 1300 "IEEE Std 1003.1-2008 - utsname.machine"; 1301 } 1302 } 1304 container clock { 1305 description 1306 "Monitoring of the system 1307 date and time properties."; 1309 leaf current-datetime { 1310 type yang:date-and-time; 1311 description 1312 "The current system date and time."; 1313 } 1314 leaf boot-datetime { 1315 type yang:date-and-time; 1316 description 1317 "The system date and time when the system last restarted."; 1318 } 1319 } 1320 } 1321 rpc set-current-datetime { 1322 nacm:default-deny-all; 1323 description 1324 "Set the /system-state/clock/current-datetime leaf 1325 to the specified value. 1327 If the system is using NTP (i.e., /system/ntp/enabled 1328 is set to 'true'), then this operation will 1329 fail with error-tag 'operation-failed', 1330 and error-app-tag value of 'ntp-active'"; 1331 input { 1332 leaf current-datetime { 1333 type yang:date-and-time; 1334 mandatory true; 1335 description 1336 "The current system date and time."; 1337 } 1338 } 1339 } 1341 rpc system-restart { 1342 nacm:default-deny-all; 1343 description 1344 "Request that the entire system be restarted immediately. 1345 A server SHOULD send an rpc reply to the client before 1346 restarting the system."; 1347 } 1349 rpc system-shutdown { 1350 nacm:default-deny-all; 1351 description 1352 "Request that the entire system be shut down immediately. 1353 A server SHOULD send an rpc reply to the client before 1354 shutting down the system."; 1355 } 1357 } 1359 1361 7. IANA Considerations 1363 This document defines first version of the IANA-maintained 1364 "iana-crypt-hash" YANG module, which will allow for new hash 1365 algorithms to be added to the type "crypt-hash". An Expert Review, 1366 as defined by [RFC5226], is REQUIRED, for each modification. 1368 This document registers two URIs in the IETF XML registry [RFC3688]. 1369 Following the format in RFC 3688, the following registrations are 1370 requested to be made. 1372 URI: urn:ietf:params:xml:ns:yang:iana-crypt-hash 1373 Registrant Contact: The IESG. 1374 XML: N/A, the requested URI is an XML namespace. 1376 URI: urn:ietf:params:xml:ns:yang:ietf-system 1377 Registrant Contact: The IESG. 1378 XML: N/A, the requested URI is an XML namespace. 1380 This document registers two YANG modules in the YANG Module Names 1381 registry [RFC6020]. 1383 name: iana-crypt-hash 1384 namespace: urn:ietf:params:xml:ns:yang:iana-crypt-hash 1385 prefix: ianach 1386 reference: RFC XXXX 1388 name: ietf-system 1389 namespace: urn:ietf:params:xml:ns:yang:ietf-system 1390 prefix: sys 1391 reference: RFC XXXX 1393 8. Security Considerations 1395 The YANG modules defined in this memo are designed to be accessed via 1396 the NETCONF protocol [RFC6241]. The lowest NETCONF layer is the 1397 secure transport layer and the mandatory-to-implement secure 1398 transport is SSH [RFC6242]. Authorization for access to specific 1399 portions of conceptual data and operations within this module is 1400 provided by the NETCONF access control model (NACM) [RFC6536]. 1402 There are a number of data nodes defined in the "ietf-system" YANG 1403 module which are writable/creatable/deletable (i.e., config true, 1404 which is the default). These data nodes may be considered sensitive 1405 or vulnerable in some network environments. Write operations to 1406 these data nodes can have a negative effect on network operations. 1407 It is thus important to control write access (e.g., via edit-config) 1408 to these data nodes. These are the subtrees and data nodes and their 1409 sensitivity/vulnerability: 1411 o /system/clock/timezone: This choice contains the objects used to 1412 control the timezone used by the device. 1414 o /system/ntp: This container contains the objects used to control 1415 the Network Time Protocol servers used by the device. 1417 o /system/dns-resolver: This container contains the objects used to 1418 control the Domain Name System servers used by the device. 1420 o /system/radius: This container contains the objects used to 1421 control the Remote Authentication Dial-In User Service servers 1422 used by the device. 1424 o /system/authentication/user-authentication-order: This leaf 1425 controls how user login attempts are authenticated by the device. 1427 o /system/authentication/user: This list contains the local users 1428 enabled on the system. 1430 Some of the readable data nodes in the "ietf-system" YANG module may 1431 be considered sensitive or vulnerable in some network environments. 1432 It is thus important to control read access (e.g., via get, get- 1433 config, or notification) to these data nodes. These are the subtrees 1434 and data nodes and their sensitivity/vulnerability: 1436 o /system/platform: This container has objects which may help 1437 identify the specific NETCONF server and/or operating system 1438 implementation used on the device. 1440 o /system/authentication/user: This list has objects that may help 1441 identify the specific user names and password information in use 1442 on the device. 1444 Some of the remote procedure call (RPC) operations in the 1445 "ietf-system" YANG module may be considered sensitive or vulnerable 1446 in some network environments. It is thus important to control access 1447 to these operations. These are the operations and their sensitivity/ 1448 vulnerability: 1450 o set-current-datetime: Changes the current date and time on the 1451 device. 1453 o system-restart: Reboots the device. 1455 o system-shutdown: Shuts down the device. 1457 Since this document describes the use of RADIUS for purposes of 1458 authentication, it is vulnerable to all of the threats that are 1459 present in other RADIUS applications. For a discussion of such 1460 threats, see [RFC2865] and [RFC3162]. 1462 The "iana-crypt-hash" YANG module defines a type "crypt-hash" that 1463 can be used to store MD5 hashes. [RFC6151] discusses security 1464 considerations for MD5. The usage of MD5 is NOT RECOMMENDED. 1466 9. Change Log 1468 -- RFC Ed.: remove this section before publication. 1470 9.1. 00-01 1472 o added configuration-source identities 1474 o added configuration-source leaf to ntp and dns (via grouping) to 1475 choose configuration source 1477 o added association-type, iburst, prefer, and true leafs to the ntp- 1478 server list 1480 o extended the ssh keys for a user to a list of keys. support all 1481 defined key algorithms, not just dsa and rsa 1483 o clarified timezone-utc-offset description-stmt 1485 o removed '/system/ntp/server/true' leaf from data model 1487 9.2. 01-02 1489 o added default-stmts to ntp-server/iburst and ntp-server/prefer 1490 leafs 1492 o changed timezone-location leaf to use iana-timezone typedef 1493 instead of a string 1495 9.3. 02-03 1497 o removed configuration-source identities and leafs 1499 9.4. 03-04 1501 o removed ndots dns resolver option 1503 o added radius-authentication-type identity, and identities for pap 1504 and chap, and a leaf to control which authentication type to use 1505 when communicating with the radius server 1507 o made 0 an invalid value for timeouts and attempts 1509 9.5. 04-05 1511 o updated tree diagram explanation text 1513 9.6. 05-06 1515 o changed ntp/use-ntp to ntp/enabled 1517 o changed ntp/ntp-server to ntp/server 1519 o removed /system/platform/nodename leaf 1521 o changed /system/name to /system/hostname 1523 o simplified must expression in user-authentication-order 1525 o added optional rounds to sha hash definition 1527 o clarified the crypt-hash description 1529 o clarified ntp descriptions 1531 o clarified YANG module description to indicate that some system 1532 properties are supported, not the entire system 1534 o clarified that system identification values are vendor specific, 1535 not the data node objects 1537 o clarified sec. 2.2 and 2.3 to indicate that the server should also 1538 be capable of configuring these properties 1540 o changed /system/dns/search from inet:host to inet:domain-name 1542 o changed RFC6021 reference to 6021-bis 1544 o changed /system/platform/nodename to /system/platform/hostname 1546 o changed /system/radius/server/{leafs} to be within a choice and 1547 'udp' case statement so other transport specific parameters can 1548 augment this list or they can be added by the WG to a future 1549 version of this module. {leafs} are authentication-port and 1550 shared-secret. 1552 o updated YANG tree diagrams for objects added in -05 and -06 1554 9.7. 06-07 1556 o updated the Abstract and Introduction 1558 o updated Tree diagram notation 1559 o identify all external servers (dns, ntp, radius) by name instead 1560 of address, in order to make the data model extensible for 1561 additional transport protocol. 1563 o updated the Security Considerations section with a reference to 1564 NACM. 1566 9.8. 07-08 1568 o renamed the DNS transport to 'udp-and-tcp' and added references. 1570 o moved the operational state nodes into /system-state. 1572 9.9. 08-09 1574 o made "ntp" node a presence container 1576 o added reference to RFC 6151 1578 o updated reference from 6021-bis to RFC 6991 1580 o cleaned up usage of config false in the YANG module 1582 9.10. 09-10 1584 o clarified relationship with SNMPv2-MIB 1586 9.11. 11-12 1588 o added typedef "timezone-name", and removed reference to 1589 draft-ietf-netmod-iana-timezones 1591 9.12. 13-14 1593 o moved the "crypt-hash" typedef to an IANA maintained module. 1595 o updated securoty considerations to mention RADIUS threats. 1597 10. References 1599 10.1. Normative References 1601 [FIPS.180-3.2008] 1602 National Institute of Standards and Technology, "Secure 1603 Hash Standard", FIPS PUB 180-3, October 2008, . 1607 [IEEE-1003.1-2008] 1608 Institute of Electrical and Electronics Engineers, 1609 "POSIX.1-2008", IEEE Standard 1003.1, March 2008. 1611 [RFC1035] Mockapetris, P., "Domain names - implementation and 1612 specification", STD 13, RFC 1035, November 1987. 1614 [RFC1321] Rivest, R., "The MD5 Message-Digest Algorithm", RFC 1321, 1615 April 1992. 1617 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 1618 Requirement Levels", BCP 14, RFC 2119, March 1997. 1620 [RFC2865] Rigney, C., Willens, S., Rubens, A., and W. Simpson, 1621 "Remote Authentication Dial In User Service (RADIUS)", 1622 RFC 2865, June 2000. 1624 [RFC3162] Aboba, B., Zorn, G., and D. Mitton, "RADIUS and IPv6", 1625 RFC 3162, August 2001. 1627 [RFC3418] Presuhn, R., "Management Information Base (MIB) for the 1628 Simple Network Management Protocol (SNMP)", STD 62, 1629 RFC 3418, December 2002. 1631 [RFC4252] Ylonen, T. and C. Lonvick, "The Secure Shell (SSH) 1632 Authentication Protocol", RFC 4252, January 2006. 1634 [RFC4253] Ylonen, T. and C. Lonvick, "The Secure Shell (SSH) 1635 Transport Layer Protocol", RFC 4253, January 2006. 1637 [RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an 1638 IANA Considerations Section in RFCs", BCP 26, RFC 5226, 1639 May 2008. 1641 [RFC5607] Nelson, D. and G. Weber, "Remote Authentication Dial-In 1642 User Service (RADIUS) Authorization for Network Access 1643 Server (NAS) Management", RFC 5607, July 2009. 1645 [RFC5966] Bellis, R., "DNS Transport over TCP - Implementation 1646 Requirements", RFC 5966, August 2010. 1648 [RFC6020] Bjorklund, M., "YANG - A Data Modeling Language for the 1649 Network Configuration Protocol (NETCONF)", RFC 6020, 1650 October 2010. 1652 [RFC6151] Turner, S. and L. Chen, "Updated Security Considerations 1653 for the MD5 Message-Digest and the HMAC-MD5 Algorithms", 1654 RFC 6151, March 2011. 1656 [RFC6241] Enns, R., Ed., Bjorklund, M., Ed., Schoenwaelder, J., Ed., 1657 and A. Bierman, Ed., "Network Configuration Protocol 1658 (NETCONF)", RFC 6241, June 2011. 1660 [RFC6242] Wasserman, M., "Using the NETCONF Protocol over Secure 1661 Shell (SSH)", RFC 6242, June 2011. 1663 [RFC6536] Bierman, A. and M. Bjorklund, "Network Configuration 1664 Protocol (NETCONF) Access Control Model", RFC 6536, 1665 March 2012. 1667 [RFC6991] Schoenwaelder, J., "Common YANG Data Types", RFC 6991, 1668 July 2013. 1670 10.2. Informative References 1672 [RFC3688] Mealling, M., "The IETF XML Registry", BCP 81, RFC 3688, 1673 January 2004. 1675 [RFC6557] Lear, E. and P. Eggert, "Procedures for Maintaining the 1676 Time Zone Database", BCP 175, RFC 6557, February 2012. 1678 Authors' Addresses 1680 Andy Bierman 1681 YumaWorks 1683 Email: andy@yumaworks.com 1685 Martin Bjorklund 1686 Tail-f Systems 1688 Email: mbj@tail-f.com