A YANG Data Model for NTPHuaweiHuawei Bld., No.156 Beiqing Rd.Beijing100095Chinaeric.wu@huawei.comRtBrick Inc.BangaloreKanatakaIndiaanil.ietf@gmail.comEricssonChina Digital Kingdom Bld., No.1 WangJing North Rd.Beijing100102Chinayi.z.zhao@ericsson.comHuaweiDivyashree Techno Park, WhitefieldBangaloreKanataka560066Indiadhruv.ietf@gmail.comRtBrick Inc.BangaloreKanatakaIndiaankit.ietf@gmail.com
Internet
NTP Working GroupThis document defines a YANG data model for Network Time Protocol (NTP)
implementations. The data model includes configuration data and state
data.The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL
NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED",
"MAY", and "OPTIONAL" in this document are to be interpreted as
described in BCP 14 when, and only when, they
appear in all capitals, as shown here.This document defines a YANG data model for
Network Time Protocol implementations.The data model convers configuration of system parameters of NTP,
such as access rules, authentication and VPN Routing and Forwarding (VRF) binding, and also
associations of NTP in different modes and parameters of per-interface.
It also provides information about running state of NTP
implementations.NTP Operational State is included in the same tree as NTP configuration,
consistent with Network Management Datastore Architecture .
NTP current state and statistics are also maintained
in the operational state. Additionally, the operational state also
include the associations state.The terminology used in this document is aligned to .A simplified graphical representation of the data model is used in
this document.
This document uses the graphical representation of data models
defined in .
In this document, names of data nodes and other data
model objects are often used without a prefix, as long as it is clear
from the context in which YANG module each name is defined.
Otherwise, names are prefixed using the standard prefix associated
with the corresponding YANG module, as shown in .PrefixYANG moduleReferenceyangietf-yang-typesinetietf-inet-typesifietf-interfacesianachiana-crypt-hashkey-chainietf-key-chainaclietf-access-control-listrt-typesietf-routing-typesThis document defines the YANG module "ietf-ntp", which has the
following structure:This data model defines one top-level container which includes both
the NTP configuration and the NTP running state including access rules,
authentication, associations, unicast configurations, interfaces, system status and associations.If the device implements the NTPv4-MIB , data
nodes from YANG module can be mapped
to table entries in NTPv4-MIB.The following tables list the YANG data nodes with corresponding
objects in the NTPv4-MIB.YANG data nodes in /ntp/NTPv4-MIB objectsntp-enabledntpEntStatusCurrentMode YANG data nodes in /ntp/associationsNTPv4-MIB objectsaddressntpAssocAddressTypentpAssocAddressYANG NTP Configuration Data Nodes and Related NTPv4-MIB ObjectsYANG data nodes in /ntp/clock-state/system-statusNTPv4-MIB objectsclock-statentpEntStatusCurrentModeclock-stratumntpEntStatusStratumclock-refidntpEntStatusActiveRefSourceIdntpEntStatusActiveRefSourceNameclock-precisionntpEntTimePrecisionclock-offsetntpEntStatusActiveOffsetroot-dispersionntpEntStatusDispersionYANG data nodes in /ntp/associations/NTPv4-MIB objectsaddressntpAssocAddressTypentpAssocAddressstratumntpAssocStratumrefidntpAssocRefIdoffsetntpAssocOffsetdelayntpAssocStatusDelaydispersionntpAssocStatusDispersionntp-statistics/packet-sentntpAssocStatOutPktsntp-statistics/packet-receivedntpAssocStatInPktsntp-statistics/packet-droppedntpAssocStatProtocolErrorYANG NTP State Data Nodes and Related NTPv4-MIB ObjectsThis section describes the relationship with NTP definition in
Section 3.2 System Time Management of .
YANG data nodes in /ntp/ also supports per-interface
configurations which is not supported in /system/ntp YANG data nodes in /ntp/ YANG data nodes in /system/ntpntp-enabledenabledunicast-configurationserverserver/nameunicast-configuration/addressserver/transport/udp/addressunicast-configuration/portserver/transport/udp/portunicast-configuration/typeserver/association-typeunicast-configuration/iburstserver/iburstunicast-configuration/preferserver/preferYANG NTP Configuration Data Nodes and counterparts in RFC 7317 ObjectsBelow is the example on how to configure a preferred unicast server present at 192.0.2.1 running at port 1025 with authentication-key 10 and version 4An example with IPv6 would used the an IPv6 address (say 2001:DB8::1) in the "address" leaf with no change in any other data tree.Below is the example on how to get unicast configurationBelow is the example on how to configure reference clock with stratum 8Below is the example on how to get reference clock configurationBelow is the example on how to enable authentication and configure authentication key 10 with mode as md5 and password as abcdBelow is the example on how to get authentication related configurationBelow is the example on how to configure acess type peer associated with acl 2000Below is the example on how to get access related configurationBelow is the example on how to configure multicast-server with address as "224.1.1.1", port as 1025 and authentication keyid as 10Below is the example on how to get multicast-server related configurationBelow is the example on how to configure multicast-client with address as "224.1.1.1"Below is the example on how to get multicast-client related configurationBelow is the example on how to configure manycast-client with address as "224.1.1.1", port as 1025 and authentication keyid as 10Below is the example on how to get manycast-client related configurationBelow is the example on how to configure manycast-server with address as "224.1.1.1"Below is the example on how to get manycast-server related configurationBelow is the example on how to get clock current stateBelow is the example on how to get all association presentBelow is the example on how to get clock current stateThis document registers a URI in the "IETF XML Registry" . Following the format in RFC 3688, the following
registration has been made.URI: urn:ietf:params:xml:ns:yang:ietf-ntpRegistrant Contact: The NETMOD WG of the IETF.XML: N/A; the requested URI is an XML namespace.This document registers a YANG module in the "YANG Module Names"
registry [RFC6020].Name: ietf-ntpNamespace: urn:ietf:params:xml:ns:yang:ietf-ntpPrefix: ntpReference: RFC XXXXThe YANG module specified in this document defines a schema for data that is designed to be accessed via network management protocols such as NETCONF or RESTCONF . The lowest NETCONF layer is the secure transport layer, and the mandatory-to-implement secure transport is Secure Shell (SSH) . The lowest RESTCONF layer is HTTPS, and the mandatory-to-implement secure transport is TLS .The NETCONF access control model provides the means to restrict access for particular NETCONF or RESTCONF users to a preconfigured subset of all available NETCONF or RESTCONF protocol operations and content.There are a number of data nodes defined in this YANG module that are writable/creatable/deletable (i.e., config true, which is the default). These data nodes may be considered sensitive or vulnerable in some network environments. Write operations (e.g., edit-config) to these data nodes without proper protection can have a negative effect on network operations. These are the subtrees and data nodes and their sensitivity/vulnerability:
/ntp/port - This data node specify the port number to be used to send NTP packets. Unexpected changes could lead to disruption and/or network misbehavior./ntp/authentication and /ntp/access-rules - The entries in the list include the authentication and access control configurations. Car should be taken while setting these parameters./ntp/unicast-configuration - The entries in the list include all unicast configurations (server or peer mode), and indirectly creates or modify the NTP
associations. Unexpected changes could lead to disruption and/or network misbehavior./ntp/interfaces/interface - The entries in the list inclide all per-interface configurations related to broadcast, multicast and manycast mode, and indirectly creates or modify the NTP
associations. Unexpected changes could lead to disruption and/or network misbehavior.Some of the readable data nodes in this YANG module may be considered sensitive or vulnerable in some network environments. It is thus important to control read access (e.g., via get, get-config, or notification) to these data nodes. These are the subtrees and data nodes and their sensitivity/vulnerability:
/ntp/associations - The entries in the list includes all active NTP associations of all modes. Unauthorized access to this needs to be curtailed. The authors would like to express their thanks to Sladjana Zoric,
Danny Mayer, Harlan Stenn, Ulrich Windl, Miroslav Lichvar, and Maurice Angermann for their
review and suggestions.