draft-ietf-tictoc-1588v2-yang-11.txt   rfc8575.txt 
Internet Working Group Y. Jiang, Ed.
Huawei
Internet-Draft X. Liu
Independent
Intended status: Standards Track J. Xu
Huawei
R. Cummings, Ed.
National Instruments
Expires: July 2019 January 3, 2019
YANG Data Model for IEEE 1588-2008 Internet Engineering Task Force (IETF) Y. Jiang, Ed.
draft-ietf-tictoc-1588v2-yang-11 Request for Comments: 8575 Huawei
Category: Standards Track X. Liu
ISSN: 2070-1721 Independent
J. Xu
Huawei
R. Cummings, Ed.
National Instruments
May 2019
YANG Data Model for the Precision Time Protocol (PTP)
Abstract Abstract
This document defines a YANG data model for the configuration of This document defines a YANG data model for the configuration of
IEEE 1588-2008 devices and clocks, and also retrieval of the devices and clocks using the Precision Time Protocol (PTP) as
configuration information, data set and running states of IEEE specified in IEEE Std 1588-2008. It also defines the retrieval of
1588-2008 clocks. The YANG module in this document conforms to the the configuration information, the data sets and the running states
of PTP clocks. The YANG module in this document conforms to the
Network Management Datastore Architecture (NMDA). Network Management Datastore Architecture (NMDA).
Status of this Memo Status of This Memo
This Internet-Draft is submitted to IETF in full conformance with
the provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that
other groups may also distribute working documents as Internet-
Drafts.
Internet-Drafts are draft documents valid for a maximum of six
months and may be updated, replaced, or obsoleted by other
documents at any time. It is inappropriate to use Internet-Drafts
as reference material or to cite them other than as "work in
progress."
The list of current Internet-Drafts can be accessed at This is an Internet Standards Track document.
http://www.ietf.org/ietf/1id-abstracts.txt
The list of Internet-Draft Shadow Directories can be accessed at This document is a product of the Internet Engineering Task Force
http://www.ietf.org/shadow.html (IETF). It represents the consensus of the IETF community. It has
received public review and has been approved for publication by the
Internet Engineering Steering Group (IESG). Further information on
Internet Standards is available in Section 2 of RFC 7841.
This Internet-Draft will expire on July 3, 2019. Information about the current status of this document, any errata,
and how to provide feedback on it may be obtained at
https://www.rfc-editor.org/info/rfc8575.
Copyright Notice Copyright Notice
Copyright (c) 2019 IETF Trust and the persons identified as the Copyright (c) 2019 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of (https://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents publication of this document. Please review these documents
carefully, as they describe your rights and restrictions with carefully, as they describe your rights and restrictions with respect
respect to this document. Code Components extracted from this to this document. Code Components extracted from this document must
document must include Simplified BSD License text as described in include Simplified BSD License text as described in Section 4.e of
Section 4.e of the Trust Legal Provisions and are provided without the Trust Legal Provisions and are provided without warranty as
warranty as described in the Simplified BSD License. described in the Simplified BSD License.
Table of Contents Table of Contents
1. Introduction .............................................. 2 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2
1.1. Conventions used in this document ...................... 4 1.1. Conventions Used in This Document . . . . . . . . . . . . 4
1.2. Terminology ............................................ 4 1.2. Terminology . . . . . . . . . . . . . . . . . . . . . . . 4
2. IEEE 1588-2008 YANG Model hierarchy ....................... 5 2. IEEE Std 1588-2008 YANG Data Model Hierarchy . . . . . . . . 5
2.1. Interpretations from IEEE 1588 Working Group ........... 8 2.1. Interpretations from IEEE 1588 Working Group . . . . . . 7
2.2. Configuration and state ................................ 8 2.2. Configuration and State . . . . . . . . . . . . . . . . . 8
3. IEEE 1588-2008 YANG Module ................................ 9 3. IEEE Std 1588-2008 YANG Module . . . . . . . . . . . . . . . 9
4. Security Considerations .................................. 22 4. Security Considerations . . . . . . . . . . . . . . . . . . . 21
5. IANA Considerations ...................................... 23 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 22
6. References ............................................... 23 6. References . . . . . . . . . . . . . . . . . . . . . . . . . 22
6.1. Normative References .................................. 23 6.1. Normative References . . . . . . . . . . . . . . . . . . 22
6.2. Informative References ................................ 24 6.2. Informative References . . . . . . . . . . . . . . . . . 23
7. Acknowledgments .......................................... 25 Appendix A. Transferring YANG Work to the IEEE 1588 WG . . . . . 25
Appendix A Transferring YANG Work to IEEE 1588 WG ............ 26 A.1. Assumptions for the Transfer . . . . . . . . . . . . . . 26
A.1. Assumptions for the Transfer .......................... 27 A.2. Intellectual Property Considerations . . . . . . . . . . 26
A.2. Intellectual Property Considerations .................. 27 A.3. Namespace and Module Name . . . . . . . . . . . . . . . . 27
A.3. Namespace and Module Name ............................. 28 A.4. IEEE 1588 YANG Modules in ASCII Format . . . . . . . . . 28
A.4. IEEE 1588 YANG Modules in ASCII Format ................ 29 Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . . 29
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 30
1. Introduction 1. Introduction
As a synchronization protocol, IEEE 1588-2008 [IEEE1588] is widely As a synchronization protocol, IEEE Std 1588-2008 [IEEE1588] is
supported in the carrier networks, industrial networks, automotive widely supported in the carrier networks, industrial networks,
networks, and many other applications. It can provide high automotive networks, and many other applications. It can provide
precision time synchronization as fine as nano-seconds. The high precision time synchronization as fine as nanoseconds. The
protocol depends on a Precision Time Protocol (PTP) engine to protocol depends on a Precision Time Protocol (PTP) engine to decide
decide its own state automatically, and a PTP transportation layer its own state automatically, and a PTP transportation layer to carry
to carry the PTP timing and various quality messages. The the PTP timing and various quality messages. The configuration
configuration parameters and state data sets of IEEE 1588-2008 are parameters and state data sets of IEEE Std 1588-2008 are numerous.
numerous.
According to the concepts described in [RFC3444], IEEE 1588-2008 According to the concepts described in [RFC3444], IEEE Std 1588-2008
itself provides an information model in its normative itself provides an information model in its normative specifications
specifications for the data sets (in IEEE 1588-2008 clause 8). Some for the data sets (in IEEE Std 1588-2008 clause 8). Some
standardization organizations including the IETF have specified standardization organizations, including the IETF, have specified
data models in MIBs (Management Information Bases) for IEEE 1588- data models in MIBs (Management Information Bases) for IEEE Std
2008 data sets (e.g. [RFC8173], [IEEE8021AS]). These MIBs are 1588-2008 data sets (e.g., [RFC8173] and [IEEE8021AS]). These MIBs
typically focused on retrieval of state data using the Simple are typically focused on retrieval of state data using the Simple
Network Management Protocol (SNMP), furthermore, configuration of Network Management Protocol (SNMP); furthermore, configuration of PTP
PTP data sets is not considered in [RFC8173]. data sets is not considered in [RFC8173].
Some service providers and applications require that the management Some service providers and applications require that the management
of the IEEE 1588-2008 synchronization network be flexible and more of the IEEE Std 1588-2008 synchronization network be flexible and
Internet-based (typically overlaid on their transport networks). more Internet based (typically overlaid on their transport networks).
Software Defined Network (SDN) is another driving factor, which Software-Defined Networking (SDN) is another driving factor, which
demands an improved configuration capability of synchronization demands an improved configuration capability of synchronization
networks. networks.
YANG [RFC7950] is a data modeling language used to model YANG [RFC7950] is a data modeling language used to model
configuration and state data manipulated by network management configuration and state data manipulated by network management
protocols like the Network Configuration Protocol (NETCONF) protocols like the Network Configuration Protocol (NETCONF)
[RFC6241]. A small set of built-in data types are defined in [RFC6241]. A small set of built-in data types is defined in
[RFC7950], and a collection of common data types are further [RFC7950]; a collection of common data types is also defined in
defined in [RFC6991]. Advantages of YANG include Internet based [RFC6991]. Advantages of YANG include Internet-based configuration
configuration capability, validation, rollback and so on. All of capabilities, validation, rollback, and so on. All of these
these characteristics make it attractive to become another characteristics make it attractive to become another candidate
candidate modeling language for IEEE 1588-2008. modeling language for IEEE Std 1588-2008.
This document defines a YANG data model for the configuration of This document defines a YANG data model for the configuration of IEEE
IEEE 1588-2008 devices and clocks, and retrieval of the state data Std 1588-2008 devices and clocks as well as retrieval of the state
of IEEE 1588-2008 clocks. The data model is based on the PTP data data of IEEE Std 1588-2008 clocks. The data model is based on the
sets as specified in [IEEE1588]. The technology specific IEEE 1588- PTP data sets as specified in [IEEE1588]. The technology-specific
2008 information, e.g., those specifically implemented by a bridge, PTP information (e.g., those specifically implemented by a bridge, a
a router or a telecom profile, is out of scope of this document. router, or a telecom profile) is out of scope of this document.
The YANG module in this document conforms to the Network Management The YANG module in this document conforms to the Network Management
Datastore Architecture (NMDA) [RFC8342]. Datastore Architecture (NMDA) [RFC8342].
When used in practice, network products in support of When used in practice, network products in support of synchronization
synchronization typically conform to one or more IEEE 1588-2008 typically conform to one or more IEEE Std 1588-2008 profiles. Each
profiles. Each profile specifies how IEEE 1588-2008 is used in a profile specifies how IEEE Std 1588-2008 is used in a given industry
given industry (e.g. telecom, automotive) and application. A (e.g., telecom or automotive) and application. A profile can require
profile can require features that are optional in IEEE 1588-2008, features that are optional in IEEE Std 1588-2008, and it can specify
and it can specify new features that use IEEE 1588-2008 as a new features that use IEEE Std 1588-2008 as a foundation.
foundation.
It is expected that the IEEE 1588-2008 YANG module be used as The readers are assumed to be familiar with IEEE Std 1588-2008. It
is expected that the IEEE Std 1588-2008 YANG module will be used as
follows: follows:
o The IEEE 1588-2008 YANG module can be used as-is for products - The IEEE Std 1588-2008 YANG module can be used as is for products
that conform to one of the default profiles specified in IEEE 1588- that conform to one of the default profiles specified in IEEE Std
2008. 1588-2008.
o When the IEEE 1588 standard is revised (e.g. the IEEE 1588
revision in progress at the time of writing this document), it will
add some new optional features to its data sets. The YANG module
of this document can be revised and extended to support these new
features. Moreover, the YANG "revision" MUST be used to indicate
changes to the YANG module under such a circumstance.
o A profile standard based on IEEE 1588-2008 may create a
dedicated YANG module for its profile. The profile's YANG module
SHOULD use YANG "import" to import the IEEE 1588-2008 YANG module
as its foundation. Then the profile's YANG module SHOULD use YANG
"augment" to add any profile-specific enhancements.
o A product that conforms to a profile standard may also create
its own YANG module. The product's YANG module SHOULD "import" the
profile's module, and then use YANG "augment" to add any product-
specific enhancements.
1.1. Conventions used in this document
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 [RFC2119] [RFC8174] when, and only when, they
appear in all capitals, as shown here.
1.2. Terminology - When the IEEE Std 1588 standard is revised (e.g., the IEEE Std
1588 revision in progress at the time of writing this document),
it will add some new optional features to its data sets. The YANG
module of this document can be revised and extended to support
these new features. Moreover, the YANG "revision" MUST be used to
indicate changes to the YANG module under such a circumstance.
Most terminologies used in this document are extracted from - A profile standard based on IEEE Std 1588-2008 may create a
[IEEE1588]. dedicated YANG module for its profile. The profile's YANG module
SHOULD use YANG "import" to import the IEEE Std 1588-2008 YANG
module as its foundation. Then the profile's YANG module SHOULD
use YANG "augment" to add any profile-specific enhancements.
BC Boundary Clock, see Section 3.1.3 of [IEEE1588] - A product that conforms to a profile standard may also create its
own YANG module. The product's YANG module SHOULD "import" the
profile's module, and then use YANG "augment" to add any product-
specific enhancements.
DS Data Set 1.1. Conventions Used in This Document
E2E End-to-End 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 [RFC2119] [RFC8174] when, and only when, they appear in all
capitals, as shown here.
EUI Extended Unique Identifier 1.2. Terminology
GPS Global Positioning System Most terminology used in this document is extracted from [IEEE1588].
IANA Internet Assigned Numbers Authority
IP Internet Protocol BC Boundary Clock, see Section 3.1.3 of [IEEE1588]
NIST National Institute of Standards and Technology DS Data Set, see Section 8.1.1 of [IEEE1588]
NTP Network Time Protocol E2E End-to-End, see Section 3.2 of [IEEE1588]
OC Ordinary Clock, see Section 3.1.22 of [IEEE1588] IANA Internet Assigned Numbers Authority
P2P Peer-to-Peer OC Ordinary Clock, see Section 3.1.22 of [IEEE1588]
P2P Peer-to-Peer, see Section 3.2 of [IEEE1588]
PTP Precision Time Protocol PTP Precision Time Protocol, see Section 3.1.28 of [IEEE1588]
TAI International Atomic Time TAI International Atomic Time, see Section 3.2 of [IEEE1588]
TC Transparent Clock, see Section 3.1.46 of [IEEE1588] TC Transparent Clock, see Section 3.1.46 of [IEEE1588]
UTC Coordinated Universal Time UTC Coordinated Universal Time, see Section 3.2 of [IEEE1588]
PTP data set PTP data set
Structured attributes of clocks (an OC, BC or TC) used for Structured attributes of clocks (an OC, BC, or TC) used for PTP
PTP protocol decisions and for providing values for PTP decisions and for providing values for PTP message fields; see
message fields, see Section 8 of [IEEE1588]. Section 8 of [IEEE1588].
PTP instance PTP instance
A PTP implementation in the device (i.e., an OC or BC) A PTP implementation in the device (i.e., an OC or BC)
represented by a specific PTP data set. represented by a specific PTP data set.
2. IEEE 1588-2008 YANG Model hierarchy 2. IEEE Std 1588-2008 YANG Data Model Hierarchy
This section describes the hierarchy of an IEEE 1588-2008 YANG This section describes the hierarchy of a YANG module for IEEE Std
module. Query and configuration of device wide or port specific 1588-2008; specifically, query and configuration of device-wide or
configuration information and clock data set are described for this port-specific configuration information and clock data sets are
version. described.
Query and configuration of clock information include: Query and configuration of clock information include:
(Note: The attribute names are consistent with IEEE 1588-2008, but (Note: The attribute names are consistent with IEEE Std 1588-2008,
changed to the YANG style, i.e., using all lower-case, with dashes but changed to the YANG style, i.e., using all lowercase, with dashes
between words.) between words.)
- Clock data set attributes in a clock node, including: current-ds, - Clock data set attributes in a clock node, including the
parent-ds, default-ds, time-properties-ds, and transparent-clock- following: current-ds, parent-ds, default-ds, time-properties-ds,
default-ds. and transparent-clock-default-ds.
- Port-specific data set attributes, including: port-ds and - Port-specific data set attributes, including the following:
transparent-clock-port-ds. port-ds and transparent-clock-port-ds.
The readers are assumed to be familiar with IEEE 1588-2008. As all As all PTP terminology and PTP data set attributes are described in
PTP terminologies and PTP data set attributes are described in detail in IEEE Std 1588-2008, this document only outlines each of
details in IEEE 1588-2008 [IEEE1588], this document only outlines them in the YANG module.
each of them in the YANG module.
A simplified YANG tree diagram [RFC8340] representing the data A simplified YANG tree diagram [RFC8340] representing the data model
model is typically used by YANG modules. This document uses the is typically used by YANG modules. This document uses the same tree
same tree diagram syntax as described in [RFC8340]. diagram syntax as described in [RFC8340].
module: ietf-ptp module: ietf-ptp
+--rw ptp +--rw ptp
+--rw instance-list* [instance-number] +--rw instance-list* [instance-number]
| +--rw instance-number uint32 | +--rw instance-number uint32
| +--rw default-ds | +--rw default-ds
| | +--rw two-step-flag? boolean | | +--rw two-step-flag? boolean
| | +--ro clock-identity? clock-identity-type | | +--ro clock-identity? clock-identity-type
| | +--rw number-ports? uint16 | | +--rw number-ports? uint16
| | +--rw clock-quality | | +--rw clock-quality
skipping to change at page 8, line 5 skipping to change at page 7, line 22
| +--ro clock-identity? clock-identity-type | +--ro clock-identity? clock-identity-type
| +--rw number-ports? uint16 | +--rw number-ports? uint16
| +--rw delay-mechanism? delay-mechanism-enumeration | +--rw delay-mechanism? delay-mechanism-enumeration
| +--rw primary-domain? uint8 | +--rw primary-domain? uint8
+--rw transparent-clock-port-ds-list* [port-number] +--rw transparent-clock-port-ds-list* [port-number]
+--rw port-number uint16 +--rw port-number uint16
+--rw log-min-pdelay-req-interval? int8 +--rw log-min-pdelay-req-interval? int8
+--rw faulty-flag? boolean +--rw faulty-flag? boolean
+--rw peer-mean-path-delay? time-interval-type +--rw peer-mean-path-delay? time-interval-type
2.1. Interpretations from IEEE 1588 Working Group 2.1. Interpretations from IEEE 1588 Working Group
The preceding model and the associated YANG module have some subtle The preceding model and the associated YANG module have some subtle
differences from the data set specifications of IEEE Std 1588-2008. differences from the data set specifications of IEEE Std 1588-2008.
These differences are based on interpretation from the IEEE 1588 These differences are based on interpretation from the IEEE 1588
Working Group, and are intended to provide compatibility with Working Group, and they are intended to provide compatibility with
future revisions of the IEEE 1588 standard. future revisions of the IEEE Std 1588 standard.
In IEEE Std 1588-2008, a physical product can implement multiple In IEEE Std 1588-2008, a physical product can implement multiple PTP
PTP clocks (i.e., ordinary, boundary, or transparent clock). As clocks (i.e., an ordinary, boundary, or transparent clock). As
specified in 1588-2008 subclause 7.1, each of the multiple clocks specified in IEEE Std 1588-2008 subclause 7.1, each of the multiple
operates in an independent domain. However, the organization of clocks operates in an independent domain. However, the organization
multiple PTP domains was not clear in the data sets of IEEE Std of multiple PTP domains was not clear in the data sets of IEEE Std
1588-2008. This document introduces the concept of PTP instance as 1588-2008. This document introduces the concept of a PTP instance,
described in the new revision of IEEE 1588. The instance concept is which is a PTP implementation in a device (i.e., an OC or BC)
used exclusively to allow for optional support of multiple domains. represented by a specific PTP data set. Each instance operates in
The instance number has no usage within PTP messages. exactly one domain. The instance concept is used exclusively to
allow for optional support of multiple domains. The instance number
has no usage within PTP messages.
Based on statements in IEEE 1588-2008 subclauses 8.3.1 and 10.1, Based on statements in IEEE Std 1588-2008 subclauses 8.3.1 and 10.1,
most transparent clock products have interpreted the transparent most transparent clock products have interpreted the transparent
clock data sets to reside as a singleton at the root level of the clock data sets to reside as a singleton at the root level of the
managed product, and this YANG model reflects that location. managed product, and this YANG data model reflects that location.
2.2. Configuration and state 2.2. Configuration and State
The information model of IEEE Std 1588-2008 classifies each member The information model of IEEE Std 1588-2008 classifies each member in
in PTP data sets as one of the following: PTP data sets as one of the following:
- Configurable: Writable by management. Configurable: Writable by management.
- Dynamic: Read-only to management, and the value is changed by Dynamic: Read-only to management, and the value is changed by
1588 protocol operation. PTP protocol operation.
- Static: Read-only to management, and the value typically does not Static: Read-only to management, and the value typically does
change. not change.
For details on the classification of each PTP data set member, For details on the classification of each PTP data set member, refer
refer to the IEEE Std 1588-2008 specification for that member. to the specification of that member in IEEE Std 1588-2008.
Under certain circumstances, the classification of an IEEE 1588 Under certain circumstances, the classification of an IEEE Std 1588
data set member may change for a YANG implementation, for example, data set member may change for a YANG implementation, for example, a
a configurable member needs to be changed to read-only. In such a configurable member needs to be changed to read-only. In such a
case, an implementation SHOULD choose to return a warning upon case, an implementation SHOULD choose to return a warning upon
writing to a read-only member, or use the deviation mechanism to writing to a read-only member or use the deviation mechanism to
develop a new deviation model as described in Section 7.20.3 of develop a new deviation model as described in Section 7.20.3 of
[RFC7950]. [RFC7950].
3. IEEE 1588-2008 YANG Module 3. IEEE Std 1588-2008 YANG Module
This module imports typedef "interface-ref" from [RFC8343]. Most This module imports typedef "interface-ref" from [RFC8343]. Most
attributes are based on the information model defined in [IEEE1588], attributes are based on the information model defined in [IEEE1588],
but their names are adapted to the YANG style of naming. but their names are adapted to the YANG style of naming.
<CODE BEGINS> file "ietf-ptp@2018-09-10.yang" <CODE BEGINS> file "ietf-ptp@2019-05-07.yang"
//Note to RFC Editor: update the date to date of publication module ietf-ptp {
module ietf-ptp { yang-version 1.1;
yang-version 1.1; namespace "urn:ietf:params:xml:ns:yang:ietf-ptp";
namespace "urn:ietf:params:xml:ns:yang:ietf-ptp"; prefix ptp;
prefix "ptp";
import ietf-interfaces {
prefix if;
reference
"RFC8343: A YANG Data Model for Interface Management";
}
organization "IETF TICTOC Working Group";
contact
"WG Web: http://tools.ietf.org/wg/tictoc/
WG List: <mailto:tictoc@ietf.org>
Editor: Yuanlong Jiang
<mailto:jiangyuanlong@huawei.com>
Editor: Rodney Cummings
<mailto:rodney.cummings@ni.com>";
description
"This YANG module defines a data model for the configuration
of IEEE 1588-2008 clocks, and also for retrieval of the state
data of IEEE 1588-2008 clocks.";
revision "2018-09-10" {
//Note to RFC Editor: update the date to date of publication
description "Initial version";
reference "RFC XXXX: YANG Data Model for IEEE 1588-2008";
//Note to RFC Editor: update RFC XXXX to the actual RFC number
}
typedef delay-mechanism-enumeration {
type enumeration {
enum e2e {
value 1;
description
"The port uses the delay request-response mechanism.";
}
enum p2p {
value 2;
description
"The port uses the peer delay mechanism.";
}
enum disabled {
value 254;
description
"The port does not implement any delay mechanism.";
}
}
description
"The propagation delay measuring option used by the
port. Values for this enumeration are specified
by the IEEE 1588 standard exclusively.";
reference
"IEEE Std 1588-2008: 8.2.5.4.4";
}
typedef port-state-enumeration {
type enumeration {
enum initializing {
value 1;
description
"The port is initializing its data sets, hardware, and
communication facilities.";
}
enum faulty {
value 2;
description
"The port is in the fault state.";
}
enum disabled {
value 3;
description
"The port is disabled, and is not communicating PTP
messages (other than possibly PTP management
messages).";
}
enum listening {
value 4;
description
"The port is listening for an Announce message.";
}
enum pre-master {
value 5;
description
"The port is in the pre-master state.";
}
enum master {
value 6;
description
"The port is behaving as a master port.";
}
enum passive {
value 7;
description
"The port is in the passive state.";
}
enum uncalibrated {
value 8;
description
"A master port has been selected, but the port is still
in the uncalibrated state.";
}
enum slave {
value 9;
description
"The port is synchronizing to the selected master port.";
}
}
description
"The current state of the protocol engine associated
with the port. Values for this enumeration are specified
by the IEEE 1588 standard exclusively.";
reference
"IEEE Std 1588-2008: 8.2.5.3.1, 9.2.5";
}
typedef time-interval-type {
type int64;
description
"Derived data type for time interval, represented in units of
nanoseconds and multiplied by 2^16";
reference
"IEEE Std 1588-2008: 5.3.2";
}
typedef clock-identity-type {
type binary {
length "8";
}
description
"Derived data type to identify a clock";
reference
"IEEE Std 1588-2008: 5.3.4";
}
grouping clock-quality-grouping {
description
"Derived data type for quality of a clock, which contains
clockClass, clockAccuracy and offsetScaledLogVariance.";
reference
"IEEE Std 1588-2008: 5.3.7";
leaf clock-class {
type uint8;
default 248;
description
"The clockClass denotes the traceability of the time
or frequency distributed by the clock.";
}
leaf clock-accuracy {
type uint8;
description
"The clockAccuracy indicates the expected accuracy
of the clock.";
}
leaf offset-scaled-log-variance {
type uint16;
description
"The offsetScaledLogVariance provides an estimate of
the variations of the clock from a linear timescale
when it is not synchronized to another clock
using the protocol.";
}
}
container ptp {
description
"The PTP struct containing all attributes of PTP data set,
other optional PTP attributes can be augmented as well.";
list instance-list {
key "instance-number";
description
"List of one or more PTP data sets in the device (see IEEE
Std 1588-2008 subclause 6.3).
Each PTP data set represents a distinct instance of
PTP implementation in the device (i.e., distinct
Ordinary Clock or Boundary Clock).";
leaf instance-number {
type uint32;
description
"The instance number of the current PTP instance.
This instance number is used for management purposes
only. This instance number does not represent the PTP
domain number, and is not used in PTP messages.";
}
container default-ds {
description
"The default data set of the clock (see IEEE Std
1588-2008 subclause 8.2.1). This data set represents
the configuration/state required for operation
of Precision Time Protocol (PTP) state machines.";
leaf two-step-flag {
type boolean;
description
"When set to true, the clock is a two-step clock;
otherwise,the clock is a one-step clock.";
}
leaf clock-identity {
type clock-identity-type;
config false;
description
"The clockIdentity of the local clock";
}
leaf number-ports {
type uint16;
description
"The number of PTP ports on the instance.";
}
container clock-quality {
description
"The clockQuality of the local clock.";
uses clock-quality-grouping;
}
leaf priority1 {
type uint8;
description
"The priority1 attribute of the local clock.";
}
leaf priority2{
type uint8;
description
"The priority2 attribute of the local clock.";
}
leaf domain-number {
type uint8;
description
"The domain number of the current syntonization
domain.";
}
leaf slave-only {
type boolean;
description
"When set to true, the clock is a slave-only clock.";
}
}
container current-ds {
description
"The current data set of the clock (see IEEE Std
1588-2008 subclause 8.2.2). This data set represents
local states learned from the exchange of
Precision Time Protocol (PTP) messages.";
leaf steps-removed {
type uint16;
default 0;
description
"The number of communication paths traversed
between the local clock and the grandmaster clock.";
}
leaf offset-from-master {
type time-interval-type;
description
"The current value of the time difference between
a master and a slave clock as computed by the slave.";
}
leaf mean-path-delay {
type time-interval-type;
description
"The current value of the mean propagation time between
a master and a slave clock as computed by the slave.";
}
}
container parent-ds {
description
"The parent data set of the clock (see IEEE Std 1588-2008
subclause 8.2.3).";
container parent-port-identity {
description
"The portIdentity of the port on the master, it
contains two members: clockIdentity and portNumber.";
reference
"IEEE Std 1588-2008: 5.3.5";
leaf clock-identity {
type clock-identity-type;
description
"Identity of the clock";
}
leaf port-number {
type uint16;
description
"Port number";
}
}
leaf parent-stats {
type boolean;
default false;
description
"When set to true, the values of
observedParentOffsetScaledLogVariance and
observedParentClockPhaseChangeRate of parentDS
have been measured and are valid.";
}
leaf observed-parent-offset-scaled-log-variance {
type uint16;
default 65535;
description
"An estimate of the parent clock's PTP variance
as observed by the slave clock.";
}
leaf observed-parent-clock-phase-change-rate {
type int32;
description
"An estimate of the parent clock's phase change rate
as observed by the slave clock.";
}
leaf grandmaster-identity {
type clock-identity-type;
description
"The clockIdentity attribute of the grandmaster clock.";
}
container grandmaster-clock-quality {
description
"The clockQuality of the grandmaster clock.";
uses clock-quality-grouping;
}
leaf grandmaster-priority1 {
type uint8;
description
"The priority1 attribute of the grandmaster clock.";
}
leaf grandmaster-priority2 {
type uint8;
description
"The priority2 attribute of the grandmaster clock.";
}
}
container time-properties-ds {
description
"The timeProperties data set of the clock (see
IEEE Std 1588-2008 subclause 8.2.4).";
leaf current-utc-offset-valid {
type boolean;
description
"When set to true, the current UTC offset is valid.";
}
leaf current-utc-offset {
when "../current-utc-offset-valid='true'";
type int16;
description
"The offset between TAI and UTC when the epoch of the
PTP system is the PTP epoch in units of seconds, i.e.,
when ptp-timescale is TRUE; otherwise, the value has
no meaning.";
}
leaf leap59 {
type boolean;
description
"When set to true, the last minute of the current UTC
day contains 59 seconds.";
}
leaf leap61 { import ietf-interfaces {
type boolean; prefix if;
description reference
"When set to true, the last minute of the current UTC "RFC 8343: A YANG Data Model for Interface Management";
day contains 61 seconds."; }
}
leaf time-traceable { organization
type boolean; "IETF TICTOC Working Group";
description contact
"When set to true, the timescale and the "WG Web: https://datatracker.ietf.org/wg/tictoc/
currentUtcOffset are traceable to a primary WG List: <mailto:tictoc@ietf.org>
reference."; Editor: Yuanlong Jiang
} <mailto:jiangyuanlong@huawei.com>
Editor: Rodney Cummings
<mailto:rodney.cummings@ni.com>";
description
"This YANG module defines a data model for the configuration
of IEEE Std 1588-2008 clocks, and also for retrieval of the state
data of IEEE Std 1588-2008 clocks.";
leaf frequency-traceable { revision 2019-05-07 {
type boolean; description
description "Initial version";
"When set to true, the frequency determining the reference
timescale is traceable to a primary reference."; "RFC 8575: YANG Data Model for the Precision Time Protocol";
} }
leaf ptp-timescale {
type boolean;
description
"When set to true, the clock timescale of the
grandmaster clock is PTP; otherwise, the timescale is
ARB
(arbitrary).";
}
leaf time-source { typedef delay-mechanism-enumeration {
type uint8; type enumeration {
description enum e2e {
"The source of time used by the grandmaster clock."; value 1;
} description
} "The port uses the delay request-response mechanism.";
}
enum p2p {
value 2;
description
"The port uses the peer delay mechanism.";
}
enum disabled {
value 254;
description
"The port does not implement any delay mechanism.";
}
}
description
"The propagation-delay measuring option used by the
port. Values for this enumeration are specified
by the IEEE Std 1588 standard exclusively.";
reference
"IEEE Std 1588-2008: 8.2.5.4.4";
}
list port-ds-list { typedef port-state-enumeration {
key "port-number"; type enumeration {
description enum initializing {
"List of port data sets of the clock (see IEEE Std value 1;
1588-2008 subclause 8.2.5)."; description
"The port is initializing its data sets, hardware, and
communication facilities.";
}
enum faulty {
value 2;
description
"The port is in the fault state.";
}
enum disabled {
value 3;
description
"The port is disabled and is not communicating PTP
messages (other than possibly PTP management
messages).";
}
enum listening {
value 4;
description
"The port is listening for an Announce message.";
}
enum pre-master {
value 5;
description
"The port is in the pre-master state.";
}
enum master {
value 6;
description
"The port is behaving as a master port.";
}
enum passive {
value 7;
description
"The port is in the passive state.";
}
enum uncalibrated {
value 8;
description
"A master port has been selected, but the port is still
in the uncalibrated state.";
}
enum slave {
value 9;
description
"The port is synchronizing to the selected master port.";
}
}
description
"The current state of the protocol engine associated
with the port. Values for this enumeration are specified
by the IEEE Std 1588 standard exclusively.";
reference
"IEEE Std 1588-2008: 8.2.5.3.1, 9.2.5";
}
leaf port-number { typedef time-interval-type {
type uint16; type int64;
description
"Derived data type for time interval, represented in units of
nanoseconds and multiplied by 2^16";
reference
"IEEE Std 1588-2008: 5.3.2";
}
description typedef clock-identity-type {
"Port number. type binary {
The data sets (i.e., information model) of IEEE Std length "8";
1588-2008 specify a member portDS.portIdentity, which }
uses a typed struct with members clockIdentity and description
portNumber. "Derived data type to identify a clock";
reference
"IEEE Std 1588-2008: 5.3.4";
}
grouping clock-quality-grouping {
description
"Derived data type for quality of a clock, which contains
clockClass, clockAccuracy, and offsetScaledLogVariance.";
reference
"IEEE Std 1588-2008: 5.3.7";
leaf clock-class {
type uint8;
default "248";
description
"The clockClass denotes the traceability of the time
or frequency distributed by the clock.";
}
leaf clock-accuracy {
type uint8;
description
"The clockAccuracy indicates the expected accuracy
of the clock.";
}
leaf offset-scaled-log-variance {
type uint16;
description
"The offsetScaledLogVariance provides an estimate of
the variations of the clock from a linear timescale
when it is not synchronized to another clock
using the protocol.";
}
}
In this YANG data model, portIdentity is not modeled container ptp {
in the port-ds-list, however, its members are provided description
as follows: "The PTP struct containing all attributes of PTP data set,
portIdentity.portNumber is provided as this port- other optional PTP attributes can be augmented as well.";
number leaf in port-ds-list; and list instance-list {
portIdentity.clockIdentity is provided as the clock- key "instance-number";
identity leaf in default-ds of the instance description
(i.e., ../../default-ds/clock-identity)."; "List of one or more PTP data sets in the device (see IEEE
} Std 1588-2008 subclause 6.3).
Each PTP data set represents a distinct instance of
PTP implementation in the device (i.e., distinct
Ordinary Clock or Boundary Clock).";
leaf instance-number {
type uint32;
description
"The instance number of the current PTP instance.
This instance number is used for management purposes
only. This instance number does not represent the PTP
domain number and is not used in PTP messages.";
leaf port-state { }
type port-state-enumeration; container default-ds {
default "initializing"; description
description "The default data set of the clock (see IEEE Std
"Current state associated with the port."; 1588-2008 subclause 8.2.1). This data set represents
the configuration/state required for operation
of Precision Time Protocol (PTP) state machines.";
reference
"IEEE Std 1588-2008: 8.2.1";
leaf two-step-flag {
type boolean;
description
"When set to true, the clock is a two-step clock;
otherwise,the clock is a one-step clock.";
}
leaf clock-identity {
type clock-identity-type;
config false;
description
"The clockIdentity of the local clock.";
}
leaf number-ports {
type uint16;
description
"The number of PTP ports on the instance.";
}
container clock-quality {
description
"The clockQuality of the local clock.";
uses clock-quality-grouping;
}
leaf priority1 {
type uint8;
description
"The priority1 attribute of the local clock.";
}
leaf priority2 {
type uint8;
description
"The priority2 attribute of the local clock.";
}
leaf domain-number {
type uint8;
description
"The domain number of the current syntonization
domain.";
}
leaf slave-only {
type boolean;
description
"When set to true, the clock is a slave-only clock.";
}
}
container current-ds {
description
"The current data set of the clock (see IEEE Std
1588-2008 subclause 8.2.2). This data set represents
local states learned from the exchange of
Precision Time Protocol (PTP) messages.";
reference
"IEEE Std 1588-2008: 8.2.2";
leaf steps-removed {
type uint16;
default "0";
description
"The number of communication paths traversed
between the local clock and the grandmaster clock.";
}
leaf offset-from-master {
type time-interval-type;
description
"The current value of the time difference between
a master and a slave clock as computed by the slave.";
}
leaf mean-path-delay {
type time-interval-type;
description
"The current value of the mean propagation time between
a master and a slave clock as computed by the slave.";
}
}
container parent-ds {
description
"The parent data set of the clock (see IEEE Std 1588-2008
subclause 8.2.3).";
reference
"IEEE Std 1588-2008: 8.2.3";
container parent-port-identity {
description
"The portIdentity of the port on the master, it
contains two members: clockIdentity and portNumber.";
reference
"IEEE Std 1588-2008: 5.3.5";
leaf clock-identity {
type clock-identity-type;
description
"Identity of the clock.";
}
leaf port-number {
type uint16;
description
"Port number.";
}
}
leaf parent-stats {
type boolean;
default "false";
description
"When set to true, the values of
observedParentOffsetScaledLogVariance and
observedParentClockPhaseChangeRate of parentDS
have been measured and are valid.";
}
leaf observed-parent-offset-scaled-log-variance {
type uint16;
default "65535";
description
"An estimate of the parent clock's PTP variance
as observed by the slave clock.";
}
leaf observed-parent-clock-phase-change-rate {
type int32;
description
"An estimate of the parent clock's phase change rate
as observed by the slave clock.";
}
leaf grandmaster-identity {
type clock-identity-type;
description
"The clockIdentity attribute of the grandmaster clock.";
}
container grandmaster-clock-quality {
description
"The clockQuality of the grandmaster clock.";
uses clock-quality-grouping;
}
leaf grandmaster-priority1 {
type uint8;
description
"The priority1 attribute of the grandmaster clock.";
}
leaf grandmaster-priority2 {
type uint8;
description
"The priority2 attribute of the grandmaster clock.";
}
}
container time-properties-ds {
description
"The timeProperties data set of the clock (see
IEEE Std 1588-2008 subclause 8.2.4).";
reference
"IEEE Std 1588-2008: 8.2.4";
leaf current-utc-offset-valid {
type boolean;
description
"When set to true, the current UTC offset is valid.";
}
leaf current-utc-offset {
when "../current-utc-offset-valid='true'";
type int16;
description
"The offset between TAI and UTC when the epoch of the
PTP system is the PTP epoch in units of seconds, i.e.,
when ptp-timescale is TRUE; otherwise, the value has
no meaning.";
}
leaf leap59 {
type boolean;
description
"When set to true, the last minute of the current UTC
day contains 59 seconds.";
}
leaf leap61 {
type boolean;
description
"When set to true, the last minute of the current UTC
day contains 61 seconds.";
}
leaf time-traceable {
type boolean;
description
"When set to true, the timescale and the
currentUtcOffset are traceable to a primary
reference.";
}
leaf frequency-traceable {
type boolean;
description
"When set to true, the frequency determining the
timescale is traceable to a primary reference.";
} }
leaf ptp-timescale {
type boolean;
description
"When set to true, the clock timescale of the
grandmaster clock is PTP; otherwise, the timescale is
ARB (arbitrary).";
}
leaf time-source {
type uint8;
description
"The source of time used by the grandmaster clock.";
}
}
list port-ds-list {
key "port-number";
description
"List of port data sets of the clock (see IEEE Std
1588-2008 subclause 8.2.5).";
reference
"IEEE Std 1588-2008: 8.2.5";
leaf port-number {
type uint16;
description
"Port number.
The data sets (i.e., information model) of IEEE Std
1588-2008 specify a member portDS.portIdentity, which
uses a typed struct with members clockIdentity and
portNumber.
leaf underlying-interface { In this YANG data model, portIdentity is not modeled
in the port-ds-list. However, its members are provided
as follows:
portIdentity.portNumber is provided as this
port-number leaf in port-ds-list, and
portIdentity.clockIdentity is provided as the
clock-identity leaf in default-ds of the instance
(i.e., ../../default-ds/clock-identity).";
}
leaf port-state {
type port-state-enumeration;
default "initializing";
description
"Current state associated with the port.";
}
leaf underlying-interface {
type if:interface-ref; type if:interface-ref;
description description
"Reference to the configured underlying interface that "Reference to the configured underlying interface that
is used by this PTP Port (see RFC 8343)."; is used by this PTP port (see RFC 8343).";
} reference
"RFC 8343: A YANG Data Model for Interface Management";
leaf log-min-delay-req-interval { }
type int8; leaf log-min-delay-req-interval {
description type int8;
"The base-two logarithm of the minDelayReqInterval description
(the minimum permitted mean time interval between "The base-2 logarithm of the minDelayReqInterval
successive Delay_Req messages)."; (the minimum permitted mean time interval between
} successive Delay_Req messages).";
}
leaf peer-mean-path-delay { leaf peer-mean-path-delay {
type time-interval-type; type time-interval-type;
default 0; default "0";
description description
"An estimate of the current one-way propagation delay "An estimate of the current one-way propagation delay
on the link when the delayMechanism is P2P; otherwise, on the link when the delayMechanism is P2P; otherwise,
it is zero."; it is zero.";
} }
leaf log-announce-interval {
leaf log-announce-interval { type int8;
type int8; description
description "The base-2 logarithm of the mean
"The base-two logarithm of the mean announceInterval (mean time interval between
announceInterval (mean time interval between successive Announce messages).";
successive Announce messages)."; }
} leaf announce-receipt-timeout {
type uint8;
leaf announce-receipt-timeout { description
type uint8; "The number of announceIntervals that have to pass
description without receipt of an Announce message before the
"The number of announceInterval that have to pass occurrence of the event ANNOUNCE_RECEIPT_TIMEOUT_
without receipt of an Announce message before the EXPIRES.";
occurrence of the event ANNOUNCE_RECEIPT_TIMEOUT_ }
EXPIRES."; leaf log-sync-interval {
} type int8;
description
leaf log-sync-interval { "The base-2 logarithm of the mean SyncInterval
type int8; for multicast messages. The rates for unicast
description transmissions are negotiated separately on a per-port
"The base-two logarithm of the mean SyncInterval basis and are not constrained by this attribute.";
for multicast messages. The rates for unicast }
transmissions are negotiated separately on a per port leaf delay-mechanism {
basis and are not constrained by this attribute."; type delay-mechanism-enumeration;
} description
"The propagation delay measuring option used by the
leaf delay-mechanism { port in computing meanPathDelay.";
type delay-mechanism-enumeration; }
description leaf log-min-pdelay-req-interval {
"The propagation delay measuring option used by the type int8;
port in computing meanPathDelay."; description
} "The base-2 logarithm of the
minPdelayReqInterval (minimum permitted mean time
leaf log-min-pdelay-req-interval { interval between successive Pdelay_Req messages).";
type int8; }
description leaf version-number {
"The base-two logarithm of the type uint8;
minPdelayReqInterval (minimum permitted mean time description
interval between successive Pdelay_Req messages)."; "The PTP version in use on the port.";
}
} }
leaf version-number {
type uint8;
description
"The PTP version in use on the port.";
}
}
} }
container transparent-clock-default-ds { container transparent-clock-default-ds {
description description
"The members of the transparentClockDefault data set (see "The members of the transparentClockDefault data set (see
IEEE Std 1588-2008 subclause 8.3.2)."; IEEE Std 1588-2008 subclause 8.3.2).";
reference
"IEEE Std 1588-2008: 8.3.2";
leaf clock-identity { leaf clock-identity {
type clock-identity-type; type clock-identity-type;
config false; config false;
description description
"The clockIdentity of the transparent clock."; "The clockIdentity of the transparent clock.";
} }
leaf number-ports { leaf number-ports {
type uint16; type uint16;
description description
"The number of PTP ports on the transparent clock."; "The number of PTP ports on the transparent clock.";
} }
leaf delay-mechanism { leaf delay-mechanism {
type delay-mechanism-enumeration; type delay-mechanism-enumeration;
description description
"The propagation delay measuring option "The propagation delay measuring option
used by the transparent clock."; used by the transparent clock.";
skipping to change at page 21, line 10 skipping to change at page 19, line 45
type uint16; type uint16;
description description
"The number of PTP ports on the transparent clock."; "The number of PTP ports on the transparent clock.";
} }
leaf delay-mechanism { leaf delay-mechanism {
type delay-mechanism-enumeration; type delay-mechanism-enumeration;
description description
"The propagation delay measuring option "The propagation delay measuring option
used by the transparent clock."; used by the transparent clock.";
} }
leaf primary-domain { leaf primary-domain {
type uint8; type uint8;
default 0; default "0";
description description
"The domainNumber of the primary syntonization domain (see "The domainNumber of the primary syntonization domain (see
IEEE Std 1588-2008 subclause 10.1)."; IEEE Std 1588-2008 subclause 10.1).";
reference
"IEEE Std 1588-2008: 10.1";
} }
} }
list transparent-clock-port-ds-list { list transparent-clock-port-ds-list {
key "port-number"; key "port-number";
description description
"List of transparentClockPort data sets of the transparent "List of transparentClockPort data sets of the transparent
clock (see IEEE Std 1588-2008 subclause 8.3.3)."; clock (see IEEE Std 1588-2008 subclause 8.3.3).";
reference
"IEEE Std 1588-2008: 8.3.3";
leaf port-number { leaf port-number {
type uint16; type uint16;
description description
"Port number. "Port number.
The data sets (i.e., information model) of IEEE Std The data sets (i.e., information model) of IEEE Std
1588-2008 specify a member 1588-2008 specify a member
transparentClockPortDS.portIdentity, which uses a typed transparentClockPortDS.portIdentity, which uses a typed
struct with members clockIdentity and portNumber. struct with members clockIdentity and portNumber.
In this YANG data model, portIdentity is not modeled in
the transparent-clock-port-ds-list, however, its
members are provided as follows:
portIdentity.portNumber is provided as this leaf member
in transparent-clock-port-ds-list; and
portIdentity.clockIdentity is provided as the clock-
identity leaf in transparent-clock-default-ds
(i.e., ../../transparent-clock-default-ds/clock-
identity).";
In this YANG data model, portIdentity is not modeled in
the transparent-clock-port-ds-list. However, its
members are provided as follows:
portIdentity.portNumber is provided as this leaf member
in transparent-clock-port-ds-list and
portIdentity.clockIdentity is provided as the
clock-identity leaf in transparent-clock-default-ds
(i.e., ../../transparent-clock-default-ds/clock-
identity).";
} }
leaf log-min-pdelay-req-interval { leaf log-min-pdelay-req-interval {
type int8; type int8;
description description
"The logarithm to the base 2 of the "The logarithm to the base 2 of the
minPdelayReqInterval (minimum permitted mean time minPdelayReqInterval (minimum permitted mean time
interval between successive Pdelay_Req messages)."; interval between successive Pdelay_Req messages).";
} }
leaf faulty-flag { leaf faulty-flag {
type boolean; type boolean;
default false; default "false";
description description
"When set to true, the port is faulty."; "When set to true, the port is faulty.";
} }
leaf peer-mean-path-delay { leaf peer-mean-path-delay {
type time-interval-type; type time-interval-type;
default 0; default "0";
description description
"An estimate of the current one-way propagation delay "An estimate of the current one-way propagation delay
on the link when the delayMechanism is P2P; otherwise, on the link when the delayMechanism is P2P; otherwise,
it is zero."; it is zero.";
} }
}
}
}
} <CODE ENDS>
}
}
<CODE ENDS>
4. Security Considerations 4. Security Considerations
The YANG module specified in this document defines a schema for The YANG module specified in this document defines a schema for data
data that is designed to be accessed via network management that is designed to be accessed via network management protocols such
protocols such as NETCONF [RFC6241] or RESTCONF [RFC8040]. The as NETCONF [RFC6241] or RESTCONF [RFC8040]. The lowest NETCONF layer
lowest NETCONF layer is the secure transport layer, and the is the secure transport layer, and the mandatory-to-implement secure
mandatory-to-implement secure transport is Secure Shell (SSH) transport is Secure Shell (SSH) [RFC6242]. The lowest RESTCONF layer
[RFC6242]. The lowest RESTCONF layer is HTTPS, and the mandatory- is HTTPS, and the mandatory-to-implement secure transport is TLS
to-implement secure transport is TLS [RFC8446]. Furthermore, [RFC8446]. Furthermore, general security considerations of time
general security considerations of time protocols are discussed in protocols are discussed in [RFC7384].
[RFC7384].
The NETCONF access control model [RFC8341] provides the means to The Network Configuration Access Control Model (NACM) [RFC8341]
restrict access for particular NETCONF or RESTCONF users to a provides the means to restrict access for particular NETCONF or
preconfigured subset of all available NETCONF or RESTCONF protocol RESTCONF users to a preconfigured subset of all available NETCONF or
operations and content. RESTCONF protocol operations and content.
There are a number of data nodes defined in this YANG module are There are a number of data nodes defined in this YANG module that are
writable, and the involved subtrees that are sensitive include: writable, and the involved subtrees that are sensitive include:
/ptp/instance-list specifies an instance (i.e., PTP data sets) for /ptp/instance-list specifies an instance (i.e., PTP data sets) for an
an OC or BC. OC or BC.
/ptp/transparent-clock-default-ds specifies a default data set for /ptp/transparent-clock-default-ds specifies a default data set for a
a TC. TC.
/ptp/transparent-clock-port-ds-list specifies a list of port data /ptp/transparent-clock-port-ds-list specifies a list of port data
sets for a TC. sets for a TC.
Write operations (e.g., edit-config) to these data nodes without Write operations (e.g., edit-config) to these data nodes without
proper protection can have a negative effect on network operations. proper protection can have a negative effect on network operations.
Specifically, an inappropriate configuration of them may adversely Specifically, an inappropriate configuration of them may adversely
impact a PTP synchronization network. For example, loss of impact a PTP synchronization network. For example, loss of
synchronization on a clock, accuracy degradation on a set of clocks, synchronization on a clock, accuracy degradation on a set of clocks,
or even break down of a whole synchronization network. or even break down of a whole synchronization network.
5. IANA Considerations 5. IANA Considerations
This document registers the following URI in the "IETF XML Registry"
[RFC3688]:
This document registers the following URI in the "IETF XML
registry" [RFC3688]:
URI: urn:ietf:params:xml:ns:yang:ietf-ptp URI: urn:ietf:params:xml:ns:yang:ietf-ptp
Registrant Contact: The IESG Registrant Contact: The IESG
XML: N/A; the requested URI is an XML namespace XML: N/A; the requested URI is an XML namespace
This document registers the following YANG module in the "YANG This document registers the following YANG module in the "YANG Module
Module Names" registry [RFC6020]: Names" registry [RFC6020]:
Name: ietf-ptp Name: ietf-ptp
Namespace: urn:ietf:params:xml:ns:yang:ietf-ptp Namespace: urn:ietf:params:xml:ns:yang:ietf-ptp
Prefix: ptp Prefix: ptp
Reference: RFC XXXX Reference: RFC 8575
6. References 6. References
6.1. Normative References 6.1. Normative References
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997 Requirement Levels", BCP 14, RFC 2119,
DOI 10.17487/RFC2119, March 1997,
[RFC3688] Mealling, M., "The IETF XML Registry", RFC 3688, <https://www.rfc-editor.org/info/rfc2119>.
January 2004
[RFC6020] Bjorklund, M., "YANG - A Data Modeling Language for the
Network Configuration Protocol (NETCONF) ", RFC 6020,
October 2010
[RFC6241] Enns, R., Bjorklund, M., Schoenwaelder, J., and Bierman, [RFC3688] Mealling, M., "The IETF XML Registry", BCP 81, RFC 3688,
A., "Network Configuration Protocol (NETCONF)", RFC 6241, DOI 10.17487/RFC3688, January 2004,
June 2011 <https://www.rfc-editor.org/info/rfc3688>.
[RFC6242] Wasserman, M., "Using the NETCONF Protocol over Secure [RFC6020] Bjorklund, M., Ed., "YANG - A Data Modeling Language for
Shell (SSH)", RFC 6242, June 2011 the Network Configuration Protocol (NETCONF)", RFC 6020,
DOI 10.17487/RFC6020, October 2010,
<https://www.rfc-editor.org/info/rfc6020>.
[RFC6991] Schoenwaelder, J., "Common YANG Data Types", RFC 6991, [RFC6241] Enns, R., Ed., Bjorklund, M., Ed., Schoenwaelder, J., Ed.,
July 2013 and A. Bierman, Ed., "Network Configuration Protocol
(NETCONF)", RFC 6241, DOI 10.17487/RFC6241, June 2011,
<https://www.rfc-editor.org/info/rfc6241>.
[RFC7950] Bjorklund, M., "The YANG 1.1 Data Modeling Language", RFC [RFC6242] Wasserman, M., "Using the NETCONF Protocol over Secure
7950, August 2016 Shell (SSH)", RFC 6242, DOI 10.17487/RFC6242, June 2011,
<https://www.rfc-editor.org/info/rfc6242>.
[RFC8040] Bierman, A., Bjorklund, M., and K. Watsen, "RESTCONF [RFC6991] Schoenwaelder, J., Ed., "Common YANG Data Types",
Protocol", RFC 8040, January 2017 RFC 6991, DOI 10.17487/RFC6991, July 2013,
<https://www.rfc-editor.org/info/rfc6991>.
[RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC [RFC7950] Bjorklund, M., Ed., "The YANG 1.1 Data Modeling Language",
2119 Key Words", BCP 14, RFC 8174, May 2017 RFC 7950, DOI 10.17487/RFC7950, August 2016,
<https://www.rfc-editor.org/info/rfc7950>.
[RFC8341] Bierman, A. and Bjorklund, M., "Network Configuration [RFC8040] Bierman, A., Bjorklund, M., and K. Watsen, "RESTCONF
Protocol (NETCONF) Access Control Model", RFC 8341, March Protocol", RFC 8040, DOI 10.17487/RFC8040, January 2017,
2018 <https://www.rfc-editor.org/info/rfc8040>.
[RFC8342] Bjorklund, M., Schoenwaelder, J., Shafer, P., Watsen, K., [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC
and R. Wilton, "Network Management Datastore Architecture 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174,
(NMDA)", RFC 8342, March 2018 May 2017, <https://www.rfc-editor.org/info/rfc8174>.
[RFC8343] Bjorklund, M., "A YANG Data Model for Interface [RFC8341] Bierman, A. and M. Bjorklund, "Network Configuration
Management", RFC 8343, March 2018 Access Control Model", STD 91, RFC 8341,
DOI 10.17487/RFC8341, March 2018,
<https://www.rfc-editor.org/info/rfc8341>.
[RFC8446] Rescorla, E., "The Transport Layer Security (TLS) [RFC8342] Bjorklund, M., Schoenwaelder, J., Shafer, P., Watsen, K.,
Protocol Version 1.3", RFC 8446, August 2018 and R. Wilton, "Network Management Datastore Architecture
(NMDA)", RFC 8342, DOI 10.17487/RFC8342, March 2018,
<https://www.rfc-editor.org/info/rfc8342>.
[IEEE1588] IEEE, "IEEE Standard for a Precision Clock [RFC8343] Bjorklund, M., "A YANG Data Model for Interface
Synchronization Protocol for Networked Measurement and Management", RFC 8343, DOI 10.17487/RFC8343, March 2018,
Control Systems", IEEE Std 1588-2008, July 2008 <https://www.rfc-editor.org/info/rfc8343>.
6.2. Informative References [RFC8446] Rescorla, E., "The Transport Layer Security (TLS) Protocol
Version 1.3", RFC 8446, DOI 10.17487/RFC8446, August 2018,
<https://www.rfc-editor.org/info/rfc8446>.
[IEEE8021AS] IEEE, "Timing and Synchronizations for Time-Sensitive [IEEE1588] IEEE, "IEEE Standard for a Precision Clock Synchronization
Applications in Bridged Local Area Networks", IEEE Protocol for Networked Measurement and Control Systems",
802.1AS-2001, 2011 IEEE Std 1588-2008, DOI 10.1109/IEEESTD.2008.4579760, July
2008.
[RFC3444] Pras, A. and J. Schoenwaelder, "On the Difference between 6.2. Informative References
Information Models and Data Models", RFC 3444, January
2003
[RFC4663] Harrington, D., "Transferring MIB Work from IETF Bridge [IEEE8021AS]
MIB WG to IEEE 802.1 WG", RFC 4663, September 2006 IEEE, "IEEE Standard for Local and Metropolitan Area
Networks - Timing and Synchronizations for Time-Sensitive
Applications in Bridged Local Area Networks", IEEE
802.1AS-2001.
[RFC7384] Mizrahi, T., "Security Requirements of Time Protocols in [RFC3444] Pras, A. and J. Schoenwaelder, "On the Difference between
Packet Switched Networks", RFC 7384, October 2014 Information Models and Data Models", RFC 3444,
DOI 10.17487/RFC3444, January 2003,
<https://www.rfc-editor.org/info/rfc3444>.
[RFC8340] Bjorklund, M., and Berger, L., "YANG Tree Diagrams", RFC [RFC4663] Harrington, D., "Transferring MIB Work from IETF Bridge
8340, March 2018 MIB WG to IEEE 802.1 WG", RFC 4663, DOI 10.17487/RFC4663,
September 2006, <https://www.rfc-editor.org/info/rfc4663>.
[RFC8173] Shankarkumar, V., Montini, L., Frost, T., and Dowd, G., [RFC7384] Mizrahi, T., "Security Requirements of Time Protocols in
"Precision Time Protocol Version 2 (PTPv2) Management Packet Switched Networks", RFC 7384, DOI 10.17487/RFC7384,
Information Base", RFC 8173, June 2017 October 2014, <https://www.rfc-editor.org/info/rfc7384>.
7. Acknowledgments [RFC8340] Bjorklund, M. and L. Berger, Ed., "YANG Tree Diagrams",
BCP 215, RFC 8340, DOI 10.17487/RFC8340, March 2018,
<https://www.rfc-editor.org/info/rfc8340>.
The authors would like to thank Tom Petch, Radek Krejci, Mahesh [RFC8173] Shankarkumar, V., Montini, L., Frost, T., and G. Dowd,
Jethanandani, Tal Mizrahi, Opher Ronen, Liang Geng, Alex Campbell, "Precision Time Protocol Version 2 (PTPv2) Management
Joe Gwinn, John Fletcher, William Zhao and Dave Thaler for their Information Base", RFC 8173, DOI 10.17487/RFC8173, June
valuable reviews and suggestions, thank Benoit Claise and Radek 2017, <https://www.rfc-editor.org/info/rfc8173>.
Krejci for their validation of the YANG module, and thank Jingfei
Lv and Zitao Wang for their discussions on IEEE 1588 and YANG
respectively.
Appendix A Transferring YANG Work to IEEE 1588 WG Appendix A. Transferring YANG Work to the IEEE 1588 WG
This Appendix is informational. This Appendix is informational.
This appendix describes a future plan to transition responsibility This appendix describes a future plan to transition responsibility
for IEEE 1588 YANG modules from the IETF TICTOC Working Group (WG) for IEEE Std 1588 YANG modules from the IETF TICTOC Working Group
to the IEEE 1588 WG, which develops the time synchronization (WG) to the IEEE 1588 WG, which develops the time synchronization
technology that the YANG modules are designed to manage. technology that the YANG modules are designed to manage.
This appendix is forward-looking with regard to future This appendix is forward-looking with regard to future
standardization roadmaps in IETF and IEEE. Since those roadmaps standardization roadmaps in the IETF and IEEE. Since those roadmaps
cannot be predicted with significant accuracy, this appendix is cannot be predicted with significant accuracy, this appendix is
informational, and it does not specify imperatives or normative informational, and it does not specify imperatives or normative
specifications of any kind. specifications of any kind.
The IEEE 1588-2008 YANG module of this standard represents a The IEEE Std 1588-2008 YANG module of this standard represents a
cooperation between IETF (for YANG) and IEEE (for 1588). For the cooperation between the IETF (for YANG) and IEEE (for 1588). For the
initial standardization of IEEE-1588 YANG modules, the information initial standardization of IEEE-1588 YANG modules, the information
model is relatively clear (i.e., IEEE 1588 data sets), but model is relatively clear (i.e., IEEE Std 1588 data sets), but
expertise in YANG is required, making IETF an appropriate location expertise in YANG is required, making IETF an appropriate location
for the standards. The TICTOC WG has expertise with IEEE 1588, for the standards. The TICTOC WG has expertise with IEEE Std 1588,
making it the appropriate location within IETF. making it the appropriate location within the IETF.
The IEEE 1588 WG anticipates future changes to its standard on an The IEEE 1588 WG anticipates future changes to its standard on an
ongoing basis. As IEEE 1588 WG members gain practical expertise ongoing basis. As IEEE 1588 WG members gain practical expertise with
with YANG, the IEEE 1588 WG will become more appropriate for YANG, the IEEE 1588 WG will become more appropriate for
standardization of its YANG modules. As the IEEE 1588 standard is standardization of its YANG modules. As the IEEE 1588 standard is
revised and/or amended, IEEE 1588 members can more effectively revised and/or amended, IEEE 1588 members can more effectively
synchronize the revision of this YANG module with future versions synchronize the revision of this YANG module with future versions of
of the IEEE 1588 standard. the IEEE 1588 standard.
This appendix is meant to establish some clear expectations between This appendix is meant to establish some clear expectations between
IETF and IEEE about the future transfer of IEEE 1588 YANG modules IETF and IEEE about the future transfer of IEEE 1588 YANG modules to
to the IEEE 1588 WG. The goal is to assist in making the future the IEEE 1588 WG. The goal is to assist in making the future
transfer as smooth as possible. As the transfer takes place, some transfer as smooth as possible. As the transfer takes place, some
case-by-case situations are likely to arise, which can be handled case-by-case situations are likely to arise, which can be handled by
by discussion on the IETF TICTOC WG mailing lists and/or discussion on the IETF TICTOC WG mailing lists and/or appropriate
appropriate liaisons. liaisons.
This appendix obtained insight from [RFC4663], an informational This appendix obtained insight from [RFC4663], an informational memo
memo that described a similar transfer of MIB work from the IETF that described a similar transfer of MIB work from the IETF Bridge
Bridge MIB WG to the IEEE 802.1 WG. MIB WG to the IEEE 802.1 WG.
A.1. Assumptions for the Transfer A.1. Assumptions for the Transfer
For the purposes of discussion in this appendix, assume that the For the purposes of discussion in this appendix, assume that the IESG
IESG has approved the publication of an RFC containing a YANG has approved the publication of an RFC containing a YANG module for a
module for a published IEEE 1588 standard. As of this writing, published IEEE 1588 standard. As of this writing, this is IEEE Std
this is IEEE Std 1588-2008, but it is possible that YANG modules 1588-2008, but it is possible that YANG modules for subsequent 1588
for subsequent 1588 revisions could be published from the IETF revisions could be published from the IETF TICTOC WG. For discussion
TICTOC WG. For discussion in this appendix, we use the phrase in this appendix, we use the phrase "last IETF 1588 YANG" to refer to
"last IETF 1588 YANG" to refer to the most recently published 1588 the most recently published 1588 YANG module from the IETF TICTOC WG.
YANG module from the IETF TICTOC WG.
The IEEE-SA Standards Board New Standards Committee (NesCom) The IEEE-SA Standards Board New Standards Committee (NesCom) handles
handles new Project Authorization Requests (PARs) (see new Project Authorization Requests (PARs) (see
http://standards.ieee.org/board/nes/). PARs are roughly the <http://standards.ieee.org/board/nes/>). PARs are roughly the
equivalent of IETF Working Group Charters and include information equivalent of IETF Working Group Charters and include information
concerning the scope, purpose, and justification for concerning the scope, purpose, and justification for standardization
standardization projects. projects.
Assume that IEEE 1588 has an approved PAR that explicitly specifies Assume that IEEE 1588 has an approved PAR that explicitly specifies
development of a YANG module. The transfer of YANG work will occur development of a YANG module. The transfer of YANG work will occur
in the context of this IEEE 1588 PAR. For discussion in this in the context of this IEEE 1588 PAR. For discussion in this
appendix, we use the phrase "first IEEE 1588 YANG" to refer to the appendix, we use the phrase "first IEEE 1588 YANG" to refer to the
first IEEE 1588 standard for YANG. first IEEE 1588 standard for YANG.
Assume that as part of the transfer of YANG work, the IETF TICTOC Assume that as part of the transfer of YANG work, the IETF TICTOC WG
WG agrees to cease all work on standard YANG modules for IEEE 1588. agrees to cease all work on standard YANG modules for IEEE 1588.
Assume that the IEEE 1588 WG has participated in the development of Assume that the IEEE 1588 WG has participated in the development of
the last IETF 1588 YANG module, such that the first IEEE 1588 YANG the last IETF 1588 YANG module, such that the first IEEE 1588 YANG
module will effectively be a revision of it. In other words, the module will effectively be a revision of it. In other words, the
transfer of YANG work will be relatively clean. transfer of YANG work will be relatively clean.
The actual conditions for the future transfer can be such that the The actual conditions for the future transfer can be such that the
preceding assumptions do not hold. Exceptions to the assumptions preceding assumptions do not hold. Exceptions to the assumptions
will need to be addressed on a case-by-case basis at the time of will need to be addressed on a case-by-case basis at the time of the
the transfer. This appendix describes topics that can be addressed transfer. This appendix describes topics that can be addressed based
based on the preceding assumptions. on the preceding assumptions.
A.2. Intellectual Property Considerations A.2. Intellectual Property Considerations
During review of the legal issues associated with transferring During review of the legal issues associated with transferring Bridge
Bridge MIB WG documents to the IEEE 802.1 WG (Section 3.1 and MIB WG documents to the IEEE 802.1 WG (Sections 3.1 and 9 of
Section 9 of [RFC4663]), it was concluded that the IETF does not [RFC4663]), it was concluded that the IETF does not have sufficient
have sufficient legal authority to make the transfer to IEEE legal authority to make the transfer to the IEEE without the consent
without the consent of the document authors. of the document authors.
If the last IETF 1588 YANG is published as a RFC, the work is If the last IETF 1588 YANG is published as an RFC, the work is
required to be transferred from the IETF to the IEEE, so that IEEE required to be transferred from the IETF to the IEEE, so that IEEE
1588 WG can begin working on the first IEEE 1588 YANG. 1588 WG can begin working on the first IEEE 1588 YANG.
When work on the first IEEE YANG module begins in the IEEE 1588 WG, When work on the first IEEE YANG module begins in the IEEE 1588 WG,
that work derives from the last IETF YANG module of this RFC, that work derives from the last IETF YANG module of this RFC,
requiring a transfer of that work from the IETF to the IEEE. In requiring a transfer of that work from the IETF to the IEEE. In
order to avoid having the transfer of that work be dependent on the order to avoid having the transfer of that work be dependent on the
availability of this RFC's authors at the time of its publication, availability of this RFC's authors at the time of its publication,
the IEEE Standards Association department of Risk Management and the IEEE Standards Association department of Risk Management and
Licensing provided the appropriate forms and mechanisms for this Licensing provided the appropriate forms and mechanisms for this
document's authors to assign a non-exclusive license for IEEE to document's authors to assign a non-exclusive license for IEEE to
create derivative works from this document. Those IEEE forms and create derivative works from this document. Those IEEE forms and
mechanisms will be updated as needed for any future IETF YANG mechanisms will be updated as needed for any future IETF YANG modules
modules for IEEE 1588 (The signed forms are held by the IEEE for IEEE 1588 (the signed forms are held by the IEEE Standards
Standards Association department of Risk Management and Licensing.). Association department of Risk Management and Licensing.). This will
This will help to make the future transfer of work from IETF to help to make the future transfer of work from the IETF to the IEEE
IEEE occur as smoothly as possible. occur as smoothly as possible.
As stated in the initial "Status of this Memo", the YANG module in As stated in the initial "Status of this Memo", the YANG module in
this document conforms to the provisions of BCP 78. The IETF will this document conforms to the provisions of BCP 78. The IETF will
retain all the rights granted at the time of publication in the retain all the rights granted at the time of publication in the
published RFCs. published RFCs.
A.3. Namespace and Module Name A.3. Namespace and Module Name
As specified in Section 5 "IANA Considerations", the YANG module in As specified in Section 5 "IANA Considerations", the YANG module in
this document uses IETF as the root of its URN namespace and YANG this document uses IETF as the root of its URN namespace and YANG
module name. module name.
Use of IETF as the root of these names implies that the YANG module Use of IETF as the root of these names implies that the YANG module
is standardized in a Working Group of IETF, using the IETF is standardized in a Working Group of IETF, using the IETF processes.
processes. If the IEEE 1588 Working Group were to continue using If the IEEE 1588 Working Group were to continue using these names
these names rooted in IETF, the IEEE 1588 YANG standardization rooted in IETF, the IEEE 1588 YANG standardization would need to
would need to continue in the IETF. The goal of transferring the continue in the IETF. The goal of transferring the YANG work is to
YANG work is to avoid this sort of dependency between standards avoid this sort of dependency between standards organizations.
organizations.
IEEE 802 has an active PAR (IEEE P802d) for creating a URN IEEE 802 has an active PAR (IEEE P802d) for creating a URN namespace
namespace for IEEE use (see for IEEE use (see <http://standards.ieee.org/develop/
http://standards.ieee.org/develop/project/802d.html). It is likely project/802d.html>). It is likely that this IEEE 802 PAR will be
that this IEEE 802 PAR will be approved and published prior to the approved and published prior to the transfer of YANG work to the IEEE
transfer of YANG work to the IEEE 1588 WG. If so, the IEEE 1588 WG 1588 WG. If so, the IEEE 1588 WG can use the IEEE URN namespace for
can use the IEEE URN namespace for the first IEEE 1588 YANG module, the first IEEE 1588 YANG module, such as:
such as:
urn:ieee:Std:1588:yang:ieee1588-ptp urn:ieee:Std:1588:yang:ieee1588-ptp
where "ieee1588-ptp" is the registered YANG module name in the IEEE. where "ieee1588-ptp" is the registered YANG module name in the IEEE.
Under the assumptions of section A.1, the first IEEE 1588 YANG Under the assumptions of Appendix A.1, the first IEEE 1588 YANG
module's prefix will be the same as the last IETF 1588 YANG module's prefix will be the same as the last IETF 1588 YANG module's
module's prefix (i.e. "ptp"). Consequently, other YANG modules can prefix (i.e., "ptp"). Consequently, other YANG modules can preserve
preserve the same import prefix "ptp" to access PTP nodes during the same import prefix "ptp" to access PTP nodes during the migration
the migration from the last IETF 1588 YANG module to the first IEEE from the last IETF 1588 YANG module to the first IEEE 1588 YANG
1588 YANG module. module.
The result of these name changes are that for complete The result of these name changes are that for complete compatibility,
compatibility, a server (i.e., IEEE 1588 node) can choose to a server (i.e., IEEE 1588 node) can choose to implement a YANG module
implement a YANG module for the last IETF 1588 YANG module (with for the last IETF 1588 YANG module (with IETF root) as well as the
IETF root) as well as the first IEEE 1588 YANG module (with IEEE first IEEE 1588 YANG module (with IEEE root). Since the content of
root). Since the content of the YANG module transferred are the the YANG module transferred are the same, the server implementation
same, the server implementation is effectively common for both. is effectively common for both.
From a client's perspective, a client of the last IETF 1588 YANG From a client's perspective, a client of the last IETF 1588 YANG
module (or earlier) looks for the IETF-rooted module name; and a module (or earlier) looks for the IETF-rooted module name; and a
client of the first IEEE 1588 YANG module (or later) looks for the client of the first IEEE 1588 YANG module (or later) looks for the
IEEE-rooted module name. IEEE-rooted module name.
A.4. IEEE 1588 YANG Modules in ASCII Format A.4. IEEE 1588 YANG Modules in ASCII Format
Although IEEE 1588 can certainly decide to publish YANG modules Although IEEE 1588 can certainly decide to publish YANG modules only
only in the PDF format that they use for their standard documents, in the PDF format that they use for their standard documents, without
without publishing an ASCII version, most network management publishing an ASCII version, most network management systems cannot
systems cannot import the YANG module directly from the PDF. Thus, import the YANG module directly from the PDF. Thus, not publishing
not publishing an ASCII version of the YANG module would negatively an ASCII version of the YANG module would negatively impact
impact implementers and deployers of YANG modules and would make implementers and deployers of YANG modules and would make potential
potential IETF reviews of YANG modules more difficult. IETF reviews of YANG modules more difficult.
This appendix recommends that the IEEE 1588 WG consider future This appendix recommends that the IEEE 1588 WG consider future plans
plans for: for:
o Public availability of the ASCII YANG modules during project - Public availability of the ASCII YANG modules during project
development. These ASCII files allow IETF participants to access development. These ASCII files allow IETF participants to access
these documents for pre-standard review purposes. these documents for pre-standard review purposes.
o Public availability of the YANG portion of published IEEE 1588 - Public availability of the YANG portion of published IEEE 1588
standards, provided as an ASCII file for each YANG module. standards, provided as an ASCII file for each YANG module. These
These ASCII files are intended for use of the published IEEE ASCII files are intended for use of the published IEEE 1588
1588 standard. standard.
As an example of public availability during project development, As an example of public availability during project development, IEEE
IEEE 802 uses the same repository that IETF uses for YANG module 802 uses the same repository that IETF uses for YANG module
development (see https://github.com/YangModels/yang). IEEE branches development (see <https://github.com/YangModels/yang>). IEEE
are provided for experimental work (i.e. pre-PAR) as well as branches are provided for experimental work (i.e., pre-PAR) as well
standard work (post-PAR drafts). IEEE-SA has approved use of this as standard work (post-PAR drafts). IEEE-SA has approved use of this
repository for project development, but not for published standards. repository for project development, but not for published standards.
As an example of public availability of YANG modules for published As an example of public availability of YANG modules for published
standards, IEEE 802.1 provides a public list of ASCII files for MIB standards, IEEE 802.1 provides a public list of ASCII files for MIB
(see http://www.ieee802.org/1/files/public/MIBs/ and (see <http://www.ieee802.org/1/files/public/MIBs/> and
http://www.ieee802.org/1/pages/MIBS.html), and analogous lists are <http://www.ieee802.org/1/pages/MIBS.html>), and analogous lists are
planned for IEEE 802.1 YANG files. planned for IEEE 802.1 YANG files.
Authors' Addresses Acknowledgments
Yuanlong Jiang (Editor) The authors would like to thank Tom Petch, Radek Krejci, Mahesh
Huawei Technologies Co., Ltd. Jethanandani, Tal Mizrahi, Opher Ronen, Liang Geng, Alex Campbell,
Joe Gwinn, John Fletcher, William Zhao, and Dave Thaler for their
valuable reviews and suggestions. They would like to thank Benoit
Claise and Radek Krejci for their validation of the YANG module, and
thank Jingfei Lv and Zitao Wang for their discussions on IEEE 1588
and YANG, respectively.
Authors' Addresses
Yuanlong Jiang (editor)
Huawei
Bantian, Longgang district Bantian, Longgang district
Shenzhen 518129, China Shenzhen 518129
China
Email: jiangyuanlong@huawei.com Email: jiangyuanlong@huawei.com
Xian Liu Xian Liu
Independent Independent
Shenzhen 518129, China Shenzhen 518129
lene.liuxian@foxmail.com China
Email: lene.liuxian@foxmail.com
Jinchun Xu Jinchun Xu
Huawei Technologies Co., Ltd. Huawei
Bantian, Longgang district Bantian, Longgang district
Shenzhen 518129, China Shenzhen 518129
xujinchun@huawei.com China
Rodney Cummings (Editor) Email: xujinchun@huawei.com
Rodney Cummings (editor)
National Instruments National Instruments
11500 N. Mopac Expwy 11500 N. Mopac Expwy Bldg. C
Bldg. C Austin, TX 78759-3504
Austin, TX 78759-3504 United States of America
Email: Rodney.Cummings@ni.com Email: Rodney.Cummings@ni.com
 End of changes. 167 change blocks. 
967 lines changed or deleted 923 lines changed or added

This html diff was produced by rfcdiff 1.47. The latest version is available from http://tools.ietf.org/tools/rfcdiff/