idnits 2.17.1 draft-bierman-netmod-system-mgmt-01.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 184 has weird spacing: '...address ine...' == Line 498 has weird spacing: '...atabase http:...' == The document seems to lack the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords. (The document does seem to have the reference to RFC 2119 which the ID-Checklist requires). -- The document date (October 30, 2011) is 4556 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) == Outdated reference: A later version (-07) exists of draft-ietf-netconf-access-control-05 == Outdated reference: A later version (-05) exists of draft-lear-iana-timezone-database-04 -- Possible downref: Non-RFC (?) normative reference: ref. 'IEEE-1003.1-2008' ** Downref: Normative reference to an Informational RFC: RFC 1321 ** Obsolete normative reference: RFC 6021 (Obsoleted by RFC 6991) Summary: 2 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 Brocade 4 Intended status: Standards Track M. Bjorklund 5 Expires: May 2, 2012 Tail-f Systems 6 October 30, 2011 8 YANG Data Model for System Management 9 draft-bierman-netmod-system-mgmt-01 11 Abstract 13 This document defines a YANG data model for the configuration and 14 identification of the management system of a device. 16 Status of this Memo 18 This Internet-Draft is submitted in full conformance with the 19 provisions of BCP 78 and BCP 79. 21 Internet-Drafts are working documents of the Internet Engineering 22 Task Force (IETF). Note that other groups may also distribute 23 working documents as Internet-Drafts. The list of current Internet- 24 Drafts is at http://datatracker.ietf.org/drafts/current/. 26 Internet-Drafts are draft documents valid for a maximum of six months 27 and may be updated, replaced, or obsoleted by other documents at any 28 time. It is inappropriate to use Internet-Drafts as reference 29 material or to cite them other than as "work in progress." 31 This Internet-Draft will expire on May 2, 2012. 33 Copyright Notice 35 Copyright (c) 2011 IETF Trust and the persons identified as the 36 document authors. All rights reserved. 38 This document is subject to BCP 78 and the IETF Trust's Legal 39 Provisions Relating to IETF Documents 40 (http://trustee.ietf.org/license-info) in effect on the date of 41 publication of this document. Please review these documents 42 carefully, as they describe your rights and restrictions with respect 43 to this document. Code Components extracted from this document must 44 include Simplified BSD License text as described in Section 4.e of 45 the Trust Legal Provisions and are provided without warranty as 46 described in the Simplified BSD License. 48 Table of Contents 50 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 51 1.1. Terminology . . . . . . . . . . . . . . . . . . . . . . . 3 52 1.1.1. Terms . . . . . . . . . . . . . . . . . . . . . . . . 3 53 2. Objectives . . . . . . . . . . . . . . . . . . . . . . . . . . 4 54 2.1. System Identification . . . . . . . . . . . . . . . . . . 4 55 2.2. System Time Management . . . . . . . . . . . . . . . . . . 4 56 2.3. User Authentication . . . . . . . . . . . . . . . . . . . 4 57 3. System Data Model . . . . . . . . . . . . . . . . . . . . . . 5 58 3.1. System Identification . . . . . . . . . . . . . . . . . . 5 59 3.2. System Time Management . . . . . . . . . . . . . . . . . . 5 60 3.3. DNS Resolver Model . . . . . . . . . . . . . . . . . . . . 5 61 3.4. User Authentication Model . . . . . . . . . . . . . . . . 6 62 3.4.1. SSH Public Key Authentication . . . . . . . . . . . . 7 63 3.4.2. Local User Password Authentication . . . . . . . . . . 7 64 3.4.3. RADIUS Password Authentication . . . . . . . . . . . . 8 65 3.5. System Control . . . . . . . . . . . . . . . . . . . . . . 8 66 4. System YANG module . . . . . . . . . . . . . . . . . . . . . . 9 67 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 23 68 6. Security Considerations . . . . . . . . . . . . . . . . . . . 24 69 7. Normative References . . . . . . . . . . . . . . . . . . . . . 25 70 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 27 72 1. Introduction 74 This document defines a YANG [RFC6020] data model for the 75 configuration and identification of the management system of a 76 device. 78 Devices that are managed by NETCONF and perhaps other mechanisms have 79 common properties that need to be configured and monitored in a 80 standard way. 82 The YANG module defined in this document provides the following 83 features: 85 o system administrative data configuration 87 o system identification monitoring 89 o system time-of-day configuration and monitoring 91 o user authentication configuration 93 o local users configuration 95 1.1. Terminology 97 The keywords "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 98 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 99 "OPTIONAL" in this document are to be interpreted as described in BCP 100 14, [RFC2119]. 102 1.1.1. Terms 104 The following terms are used within this document: 106 o system: This term refers to the embodiment of the entire set of 107 management interfaces that a single NETCONF server is supporting 108 at a given moment. The set of physical entities managed by a 109 single NETCONF server can be static or it can change dynamically. 111 2. Objectives 113 2.1. System Identification 115 There are many common properties used to identify devices, operating 116 systems, software versions, etc. that need to be supported in the 117 system data module. These objects are defined as operational data 118 and intended to be specific to the device vendor. 120 Some user-configurable administrative strings are also provided such 121 as the system location and description. 123 2.2. System Time Management 125 The management of the date and time used by the system need to be 126 supported. Use of one or more NTP servers to automatically set the 127 system date and time need to be possible. Utilization of the 128 Timezone database [I-D.lear-iana-timezone-database] also need to be 129 supported. 131 2.3. User Authentication 133 The authentication mechanism need to support password authentication 134 over RADIUS, to support deployment scenarios with centralized 135 authentication servers. Additionally, local users need to be 136 supported, for scenarios when no centralized authentication server 137 exists, or for situations where the centralized authentication server 138 cannot be reached from the device. 140 Since the mandatory transport protocol for NETCONF is SSH [RFC6242] 141 the authentication model need to support SSH's "publickey" and 142 "password" authentication methods [RFC4252]. 144 The model for authentication configuration should be flexible enough 145 to support authentication methods defined by other standard documents 146 or by vendors. 148 3. System Data Model 150 3.1. System Identification 152 The data model for system identification has the following structure: 154 +--rw system 155 +--rw contact? string 156 +--rw name? string 157 +--rw location? string 158 +--ro platform 159 +--ro os-name? string 160 +--ro os-release? string 161 +--ro os-version? string 162 +--ro machine? string 163 +--ro nodename? string 165 3.2. System Time Management 167 The data model for system time management has the following 168 structure: 170 +--rw system 171 +--rw clock 172 | +--ro current-datetime? yang:date-and-time 173 | +--ro boot-datetime? yang:date-and-time 174 | +--rw (timezone)? 175 | +--:(timezone-location) 176 | | +--rw timezone-location? string 177 | +--:(timezone-name) 178 | | +--rw timezone-name? string 179 | +--:(timezone-utc-offset) 180 | +--rw timezone-utc-offset? int16 181 +--rw ntp 182 +--rw use-ntp? boolean 183 +--rw ntp-server [address] 184 +--rw address inet:host 186 3.3. DNS Resolver Model 188 The data model for configuration of the DNS resolver has the 189 following structure: 191 +--rw system 192 +--rw dns 193 +--rw search* inet:host 194 +--rw server* inet:ip-address 195 +--rw options 196 +--rw ndots? uint8 197 +--rw timeout? uint8 198 +--rw attempts? uint8 200 3.4. User Authentication Model 202 This document defines three authentication methods for use with 203 NETCONF: 205 o publickey for local users over SSH 207 o password for local users over any transport 209 o password for RADIUS users over any transport 211 Additional methods can be defined by other standard documents or by 212 vendors. 214 This document defines two optional YANG features, "local-users" and 215 "radius", which the server advertises to indicate support for 216 configuring local users on the device, and for configuring RADIUS 217 access, respectively. 219 The authentication parameters defined in this document are primarily 220 used to configure authentication of NETCONF users, but MAY also be 221 used by other interfaces, e.g., a Command Line Interface or a Web- 222 based User Interface. 224 The data model for user authentication has the following structure: 226 +--rw system 227 +--rw authentication 228 +--rw user-authentication-order* identityref 229 +--rw radius 230 | +--rw server [address] 231 | | +--rw address inet:host 232 | | +--rw port? inet:port-number 233 | | +--rw shared-secret? string 234 | +--rw options 235 | +--rw timeout? uint8 236 | +--rw attempts? uint8 237 +--rw user [name] 238 +--rw name string 239 +--rw password? crypt-hash 240 +--rw ssh-dsa? binary 241 +--rw ssh-rsa? binary 243 3.4.1. SSH Public Key Authentication 245 If the NETCONF server advertises the "local-users" feature, 246 configuration of local users and their SSH public keys is supported 247 in the /system/authentication/user list. 249 Public key authentication is requested by the SSH client. If the 250 "local-users" feature is supported, then when a NETCONF client starts 251 an SSH session towards the server using the "publickey" 252 authentication "method name" [RFC4252], the SSH server looks up the 253 user name given in the SSH authentication request in the /system/ 254 authentication/user list, and verifies the key as described in 255 [RFC4253]. 257 3.4.2. Local User Password Authentication 259 If the NETCONF server advertises the "local-users" feature, 260 configuration of local users and their passwords is supported in the 261 /system/authentication/user list. 263 For NETCONF transport protocols that support password authentication, 264 the leaf-list "user-authentication-order" is used to control if local 265 user password authentication should be used. 267 In SSH, password authentication is requested by the client. Other 268 NETCONF transport protocols MAY also support password authentication. 270 When local user password authentication is requested, the NETCONF 271 transport looks up the user name provided by the client in the 272 /system/ authentication/user list, and verifies the password. 274 3.4.3. RADIUS Password Authentication 276 If the NETCONF server advertises the "radius" feature, the device 277 supports user authentication RADIUS. 279 For NETCONF transport protocols that support password authentication, 280 the leaf-list "user-authentication-order" is used to control if 281 RADIUS password authentication should be used. 283 In SSH, password authentication is requested by the client. Other 284 NETCONF transport protocols MAY also support password authentication. 286 3.5. System Control 288 Two protocol operations are included to restart or shutdown the 289 system. The 'system-restart' operation can be used to restart the 290 entire system (not just the NETCONF server). The 'system-shutdown' 291 operation can be used to power off the entire system. 293 4. System YANG module 295 RFC Ed.: update the date below with the date of RFC publication and 296 remove this note. 298 This YANG module imports YANG extensions from 299 [I-D.ietf-netconf-access-control], imports YANG types from [RFC6021], 300 and references [RFC1321], [RFC2865], [RFC3418], [RFC5607], 301 [IEEE-1003.1-2008], and [FIPS.180-3.2008]. 303 file "ietf-system@2011-10-30.yang" 305 module ietf-system { 306 namespace "urn:ietf:params:xml:ns:yang:ietf-system"; 307 prefix "sys"; 309 import ietf-yang-types { 310 prefix yang; 311 } 313 import ietf-inet-types { 314 prefix inet; 315 } 317 import ietf-netconf-acm { 318 prefix nacm; 319 } 321 organization 322 "IETF NETMOD (NETCONF Data Modeling Language) Working Group"; 324 contact 325 "WG Web: 326 WG List: 328 WG Chair: David Kessens 329 331 WG Chair: Juergen Schoenwaelder 332 334 Editor: Andy Bierman 335 337 Editor: Martin Bjorklund 338 "; 340 description 341 "This module contains a collection of YANG definitions for the 342 configuration and identification of the management system of a 343 device. 345 Copyright (c) 2011 IETF Trust and the persons identified as 346 authors of the code. All rights reserved. 348 Redistribution and use in source and binary forms, with or 349 without modification, is permitted pursuant to, and subject 350 to the license terms contained in, the Simplified BSD License 351 set forth in Section 4.c of the IETF Trust's Legal Provisions 352 Relating to IETF Documents 353 (http://trustee.ietf.org/license-info). 355 This version of this YANG module is part of RFC XXXX; see 356 the RFC itself for full legal notices."; 358 // RFC Ed.: replace XXXX with actual RFC number and remove this 359 // note. 361 // RFC Ed.: remove this note 362 // Note: extracted from draft-bierman-netmod-system-mgmt-01.txt 364 // RFC Ed.: update the date below with the date of RFC publication 365 // and remove this note. 366 revision 2011-10-30 { 367 description 368 "Initial revision."; 369 reference 370 "RFC XXXX: A YANG Data Model for System Management"; 371 } 373 /* 374 * Typedefs 375 */ 377 typedef crypt-hash { 378 type string { 379 pattern "$0$.* | $1|5|6$[a-zA-Z0-9./]{2,16}$.*"; 380 } 381 description 382 "The crypt-hash type is used to store passwords using 383 a hash function. This type is implemented in various UNIX 384 systems as the function crypt(3). 386 When a clear text value is set to a leaf of this type, the 387 server calculates a password hash, and stores the result 388 in the datastore. Thus, the password is never stored in 389 clear text. 391 When a leaf of this type is read, the stored password hash is 392 returned. 394 A value of this type matches one of the forms: 396 $0$ 397 $$$ 399 The '$0$' prefix signals that the value is clear text. When 400 such a value is received by the server, a hash value is 401 calculated, and the string '$$$' is prepended to the 402 result, where is a random 2-16 characters long salt 403 used to generate the digest. This value is stored in the 404 configuration data store. 406 If a value starting with '$$$' is received, the 407 server knows that the value already represents a hashed value, 408 and stores it as is in the data store. 410 When a server needs to verify a password given by a user, it 411 finds the stored password hash string for that user, extracts 412 the salt, and calculates the hash with the salt and given 413 password as input. If the calculated hash value is the same 414 as the stored value, the password given by the client is 415 correct. 417 This type defines the following hash functions: 419 id | hash function | feature 420 ---+---------------+------------------- 421 1 | MD5 | crypt-hash-md5 422 5 | SHA-256 | crypt-hash-sha-256 423 6 | SHA-512 | crypt-hash-sha-512 425 The server indicates support for the different hash functions 426 by advertising the corresponding feature."; 427 reference 428 "IEEE Std 1003.1-2008 - crypt() function 429 Wikipedia: http://en.wikipedia.org/wiki/Crypt_(Unix) 430 RFC 1321: The MD5 Message-Digest Algorithm 431 FIPS.180-3.2008: Secure Hash Standard"; 432 } 434 /* 435 * Features 436 */ 438 feature authentication { 439 description 440 "Indicates that the device can be configured 441 to do authentication of users."; 442 } 444 feature radius { 445 if-feature authentication; 446 description 447 "Indicates that the device can be 448 configured to act as a NAS and authenticate users 449 with RADIUS."; 450 reference 451 "RFC 2865: Remote Authentication Dial In User Service (RADIUS) 452 RFC 5607: Remote Authentication Dial-In User Service (RADIUS) 453 Authorization for Network Access Server (NAS) 454 Management"; 455 } 457 feature local-users { 458 if-feature authentication; 459 description 460 "Indicates that the device supports 461 local user authentication."; 462 } 464 feature crypt-hash-md5 { 465 description 466 "Indicates that the device supports the MD5 467 hash function in 'crypt-hash' values"; 468 reference "RFC 1321: The MD5 Message-Digest Algorithm"; 469 } 471 feature crypt-hash-sha-256 { 472 description 473 "Indicates that the device supports the SHA-256 474 hash function in 'crypt-hash' values"; 475 reference "FIPS.180-3.2008: Secure Hash Standard"; 476 } 478 feature crypt-hash-sha-512 { 479 description 480 "Indicates that the device supports the SHA-512 481 hash function in 'crypt-hash' values"; 482 reference "FIPS.180-3.2008: Secure Hash Standard"; 483 } 485 feature ntp { 486 description 487 "Indicates that the device can be configured 488 to use one or more NTP servers to set the 489 system date and time."; 490 } 492 feature timezone-location { 493 description 494 "Indicates that the local timezone on the device 495 can be configured to use the TZ database 496 to set the timezone and manage daylight savings time."; 497 reference 498 "TZ Database http://www.twinsun.com/tz/tz-link.htm 499 Maintaining the Timezone Database 500 http://www.ietf.org/id/draft-lear-iana-timezone-database-04.txt 501 "; 502 } 504 feature timezone-name { 505 description 506 "Indicates that the local timezone on the device 507 can be configured using the timezone enumeration 508 strings as an alias for an UTC offset."; 509 reference 510 "Wikipedia: http://en.wikipedia.org/wiki/" 511 + "List_of_time_zone_abbreviations"; 512 } 514 /* 515 * Identities 516 */ 518 identity authentication-method { 519 description 520 "Base identity for user authentication methods."; 521 } 523 identity radius { 524 base authentication-method; 525 description 526 "Indicates user authentication using RADIUS."; 527 reference 528 "RFC 2865: Remote Authentication Dial In User Service (RADIUS) 529 RFC 5607: Remote Authentication Dial-In User Service (RADIUS) 530 Authorization for Network Access Server (NAS) 531 Management"; 532 } 533 identity local-users { 534 base authentication-method; 535 description 536 "Indicates password-based authentication of locally 537 configured users."; 538 } 540 /* 541 * Top-level container 542 */ 544 container system { 545 description 546 "System group configuration."; 548 leaf contact { 549 type string { 550 length "0..255"; 551 } 552 default ""; 553 reference 554 "RFC 3418 - Management Information Base (MIB) for the 555 Simple Network Management Protocol (SNMP) 556 SNMPv2-MIB.sysContact"; 557 } 559 leaf name { 560 type string { 561 length "0..255"; 562 } 563 default ""; 564 reference 565 "RFC 3418 - Management Information Base (MIB) for the 566 Simple Network Management Protocol (SNMP) 567 SNMPv2-MIB.sysName"; 568 } 570 leaf location { 571 type string { 572 length "0..255"; 573 } 574 default ""; 575 reference 576 "RFC 3418 - Management Information Base (MIB) for the 577 Simple Network Management Protocol (SNMP) 578 SNMPv2-MIB.sysLocation"; 579 } 580 container platform { 581 description 582 "Contains vendor-specific information for 583 identifying the system platform and operating system."; 584 reference 585 "IEEE Std 1003.1-2008 - sys/utsname.h"; 587 config false; 589 leaf os-name { 590 type string; 591 description 592 "The name of the operating system in use, 593 for example 'Linux'"; 594 reference 595 "IEEE Std 1003.1-2008 - utsname.sysname"; 596 } 598 leaf os-release { 599 type string; 600 description 601 "The current release level of the operating 602 system in use. This string MAY indicate 603 the OS source code revision."; 604 reference 605 "IEEE Std 1003.1-2008 - utsname.release"; 606 } 608 leaf os-version { 609 type string; 610 description 611 "The current version level of the operating 612 system in use. This string MAY indicate 613 the specific OS build date and target variant 614 information."; 615 reference 616 "IEEE Std 1003.1-2008 - utsname.version"; 617 } 619 leaf machine { 620 type string; 621 description 622 "A vendor-specific identifier string representing 623 the hardware in use."; 624 reference 625 "IEEE Std 1003.1-2008 - utsname.machine"; 626 } 627 leaf nodename { 628 type string; 629 description 630 "The host name of this system."; 631 reference 632 "IEEE Std 1003.1-2008 - utsname.nodename"; 633 } 634 } 636 container clock { 637 description 638 "Configuration and monitoring of the system 639 date and time properties."; 641 leaf current-datetime { 642 description 643 "The current system date and time."; 644 type yang:date-and-time; 645 config false; 646 } 648 leaf boot-datetime { 649 description 650 "The system date and time when the NETCONF 651 server last restarted."; 652 type yang:date-and-time; 653 config false; 654 } 656 choice timezone { 657 description 658 "Configure the system timezone information."; 660 leaf timezone-location { 661 if-feature timezone-location; 662 description 663 "The TZ database location identifier string 664 to use for the system, such as 'Europe/Stockholm'."; 665 type string; 666 } 668 leaf timezone-name { 669 if-feature timezone-name; 670 description 671 "The timezone enumeration string to use 672 for the system, such as 'CET'."; 673 type string; 674 // FIXME: use TimezoneEnum typedef instead 675 // see http://en.wikipedia.org/wiki/ 676 // List_of_time_zone_abbreviations 677 } 679 leaf timezone-utc-offset { 680 description 681 "The number of minutes to add to UTC time to 682 identify the timezone for this system. 683 For example, 'UTC - 8:00 hours' would be 684 represented as '-480'."; 685 type int16 { 686 range "-1439 .. 1439"; 687 } 688 } 689 } 690 } 692 container ntp { 693 if-feature ntp; 695 description 696 "Configuration of the NTP client. 697 FIXME: should NTP server mode be supported here, 698 or in a submodule? Should NTP client and server 699 mode be kept together in the same container?"; 701 leaf use-ntp { 702 description 703 "Indicates that the system should attempt 704 to synchronize the system clock with an 705 NTP server from the 'ntp-server' list."; 706 type boolean; 707 default true; 708 } 710 list ntp-server { 711 description 712 "List of NTP servers to use for 713 system clock synchronization. If 'use-ntp' 714 is 'true', then the system will attempt to 715 contact and utilize the specified NTP servers."; 717 key address; 719 leaf address { 720 description 721 "The IP address or domain name of the NTP server."; 722 type inet:host; 724 } 725 } 726 } 728 container dns { 729 description 730 "Configuration of the DNS resolver."; 732 leaf-list search { 733 type inet:host; 734 ordered-by user; 735 } 736 leaf-list server { 737 type inet:ip-address; 738 ordered-by user; 739 description 740 "Addresses of the name servers that the resolver should 741 query. 743 Implementations MAY limit the number of entries in this 744 leaf list."; 745 } 746 container options { 747 description 748 "Resolver options. The set of available options has been 749 limited to those that are generally available across 750 different resolver implementations, and generally useful."; 751 leaf ndots { 752 type uint8; 753 default "1"; 754 } 755 leaf timeout { 756 type uint8; 757 units "seconds"; 758 default "5"; 759 } 760 leaf attempts { 761 type uint8; 762 default "2"; 763 } 764 } 765 } 767 container authentication { 768 nacm:default-deny-write; 769 if-feature authentication; 771 description 772 "The authentication configuration subtree."; 774 leaf-list user-authentication-order { 775 type identityref { 776 base authentication-method; 777 } 778 must '(. = "sys:radius" and ../radius/server) or' 779 + '(. != "sys:radius")' { 780 error-message 781 "When 'radius' is used, a radius server 782 must be configured."; 783 } 784 ordered-by user; 786 description 787 "When the device authenticates a user with 788 a password, it tries the authentication methods in this 789 leaf-list in order. If authentication with one method 790 fails, the next method is used. If no method succeeds, 791 the user is denied access. 793 If the 'radius' feature is advertised by the NETCONF 794 server, the 'radius' identity can be added to this 795 list. 797 If the 'local-users' feature is advertised by the 798 NETCONF server, the 'local-users' identity can be 799 added to this list."; 800 } 802 container radius { 803 if-feature radius; 805 description 806 "The RADIUS configuration for authentication."; 808 list server { 809 key address; 810 ordered-by user; 812 description 813 "The RADIUS server configuration used by 814 the device."; 816 leaf address { 817 type inet:host; 818 description 819 "The address of the RADIUS server."; 821 } 822 leaf port { 823 type inet:port-number; 824 default "1812"; 825 description 826 "The port number of the RADIUS server."; 827 } 828 leaf shared-secret { 829 type string; 830 nacm:default-deny-all; 831 description 832 "The shared secret which is known to both the RADIUS 833 client and server."; 834 reference 835 "RFC 2865: Remote Authentication Dial In User Service"; 836 } 837 } 838 container options { 839 description 840 "RADIUS client options."; 842 leaf timeout { 843 type uint8; 844 units "seconds"; 845 default "5"; 846 description 847 "The number of seconds the device will wait for a 848 response from a RADIUS server before trying with a 849 different server."; 850 } 851 leaf attempts { 852 type uint8; 853 default "2"; 854 description 855 "The number of times the device will send a query to 856 the RADIUS servers before giving up."; 857 } 858 } 859 } 861 list user { 862 if-feature local-users; 863 key name; 865 description 866 "The list of local users configured on this device."; 868 leaf name { 869 type string; 870 description 871 "The user name string identifying this entry."; 872 } 873 leaf password { 874 type crypt-hash; 875 description 876 "The password for this entry."; 877 } 878 leaf ssh-dsa { 879 type binary; 880 description 881 "The public DSA key for this entry."; 882 } 883 leaf ssh-rsa { 884 type binary; 885 description 886 "The public RSA key for this entry."; 887 } 888 } 889 } 890 } 892 rpc set-current-datetime { 893 nacm:default-deny-all; 894 description 895 "Manually set the /system/clock/current-datetime leaf 896 to the specified value. 898 If the /system/ntp/ntp-in-use leaf exists and 899 is set to 'true', then this operation will 900 fail with error-tag 'operation-failed', 901 and error-app-tag value of 'ntp-active'"; 902 input { 903 leaf current-datetime { 904 description 905 "The current system date and time."; 906 type yang:date-and-time; 907 mandatory true; 908 } 909 } 910 } 912 rpc system-restart { 913 nacm:default-deny-all; 914 description 915 "Request that the entire system be restarted immediately. 916 A server SHOULD send an rpc reply to the client before 917 restarting the system."; 918 } 920 rpc system-shutdown { 921 nacm:default-deny-all; 922 description 923 "Request that the entire system be shut down immediately. 924 A server SHOULD send an rpc reply to the client before 925 shutting down the system."; 926 } 928 } 930 932 5. IANA Considerations 934 This document registers a URI in the IETF XML registry [RFC3688]. 935 Following the format in RFC 3688, the following registration is 936 requested to be made. 938 URI: urn:ietf:params:xml:ns:yang:ietf-system 940 Registrant Contact: The NETMOD WG of the IETF. 942 XML: N/A, the requested URI is an XML namespace. 944 This document registers a YANG module in the YANG Module Names 945 registry [RFC6020]. 947 name: ietf-system 948 namespace: urn:ietf:params:xml:ns:yang:ietf-system 949 prefix: sys 950 reference: RFC XXXX 952 6. Security Considerations 954 TBD. 956 7. Normative References 958 [FIPS.180-3.2008] 959 National Institute of Standards and Technology, "Secure 960 Hash Standard", FIPS PUB 180-3, October 2008, . 964 [I-D.ietf-netconf-access-control] 965 Bierman, A. and M. Bjorklund, "Network Configuration 966 Protocol (NETCONF) Access Control Model", 967 draft-ietf-netconf-access-control-05 (work in progress), 968 October 2011. 970 [I-D.lear-iana-timezone-database] 971 Lear, E. and P. Eggert, "IANA Procedures for Maintaining 972 the Timezone Database", 973 draft-lear-iana-timezone-database-04 (work in progress), 974 May 2011. 976 [IEEE-1003.1-2008] 977 Institute of Electrical and Electronics Engineers, 978 "POSIX.1-2008", IEEE Standard 1003.1, March 2008. 980 [RFC1321] Rivest, R., "The MD5 Message-Digest Algorithm", RFC 1321, 981 April 1992. 983 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 984 Requirement Levels", BCP 14, RFC 2119, March 1997. 986 [RFC2865] Rigney, C., Willens, S., Rubens, A., and W. Simpson, 987 "Remote Authentication Dial In User Service (RADIUS)", 988 RFC 2865, June 2000. 990 [RFC3418] Presuhn, R., "Management Information Base (MIB) for the 991 Simple Network Management Protocol (SNMP)", STD 62, 992 RFC 3418, December 2002. 994 [RFC3688] Mealling, M., "The IETF XML Registry", BCP 81, RFC 3688, 995 January 2004. 997 [RFC4252] Ylonen, T. and C. Lonvick, "The Secure Shell (SSH) 998 Authentication Protocol", RFC 4252, January 2006. 1000 [RFC4253] Ylonen, T. and C. Lonvick, "The Secure Shell (SSH) 1001 Transport Layer Protocol", RFC 4253, January 2006. 1003 [RFC5607] Nelson, D. and G. Weber, "Remote Authentication Dial-In 1004 User Service (RADIUS) Authorization for Network Access 1005 Server (NAS) Management", RFC 5607, July 2009. 1007 [RFC6020] Bjorklund, M., "YANG - A Data Modeling Language for the 1008 Network Configuration Protocol (NETCONF)", RFC 6020, 1009 October 2010. 1011 [RFC6021] Schoenwaelder, J., "Common YANG Data Types", RFC 6021, 1012 October 2010. 1014 [RFC6242] Wasserman, M., "Using the NETCONF Protocol over Secure 1015 Shell (SSH)", RFC 6242, June 2011. 1017 Authors' Addresses 1019 Andy Bierman 1020 Brocade 1022 Email: andy.bierman@brocade.com 1024 Martin Bjorklund 1025 Tail-f Systems 1027 Email: mbj@tail-f.com