draft-ietf-tictoc-1588v2-yang-07.txt   draft-ietf-tictoc-1588v2-yang-08.txt 
Internet Working Group Y. Jiang, Ed. Internet Working Group Y. Jiang, Ed.
Huawei Huawei
Internet-Draft X. Liu Internet-Draft X. Liu
Independent Independent
Intended status: Standards Track J. Xu Intended status: Standards Track J. Xu
Huawei Huawei
R. Cummings, Ed. R. Cummings, Ed.
National Instruments National Instruments
Expires: May 2018 November 28, 2017 Expires: January 2019 July 2, 2018
YANG Data Model for IEEE 1588-2008 YANG Data Model for IEEE 1588-2008
draft-ietf-tictoc-1588v2-yang-07 draft-ietf-tictoc-1588v2-yang-08
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 IEEE 1588-2008 devices and clocks, and also retrieval of the
configuration information, data set and running states of IEEE configuration information, data set and running states of IEEE
1588-2008 clocks. 1588-2008 clocks.
Status of this Memo Status of this Memo
skipping to change at page 1, line 44 skipping to change at page 1, line 44
documents at any time. It is inappropriate to use Internet-Drafts documents at any time. It is inappropriate to use Internet-Drafts
as reference material or to cite them other than as "work in as reference material or to cite them other than as "work in
progress." progress."
The list of current Internet-Drafts can be accessed at The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt http://www.ietf.org/ietf/1id-abstracts.txt
The list of Internet-Draft Shadow Directories can be accessed at The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html http://www.ietf.org/shadow.html
This Internet-Draft will expire on May 28, 2018. This Internet-Draft will expire on January 2, 2019.
Copyright Notice Copyright Notice
Copyright (c) 2017 IETF Trust and the persons identified as the Copyright (c) 2018 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 (http://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 to this document. Code Components extracted from this respect to this document. Code Components extracted from this
document must include Simplified BSD License text as described in document must include Simplified BSD License text as described in
Section 4.e of the Trust Legal Provisions and are provided without Section 4.e of the Trust Legal Provisions and are provided without
warranty as described in the Simplified BSD License. warranty as 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 1588-2008 YANG Model hierarchy ........................ 5
2.1. Interpretations from IEEE 1588 Working Group ........... 8 2.1. Interpretations from IEEE 1588 Working Group ............ 8
2.2. Configuration and state ................................ 8 2.2. Configuration and state ................................. 8
3. IEEE 1588-2008 YANG Module ................................ 9 3. IEEE 1588-2008 YANG Module ................................. 9
4. Security Considerations .................................. 22 4. Security Considerations ................................... 22
5. IANA Considerations ...................................... 23 5. IANA Considerations ....................................... 23
6. References ............................................... 23 6. References ................................................ 23
6.1. Normative References .................................. 23 6.1. Normative References ................................... 23
6.2. Informative References ................................ 23 6.2. Informative References ................................. 23
7. Acknowledgments .......................................... 24 7. Acknowledgments ........................................... 24
Appendix A Transferring YANG Work to IEEE 1588 WG (Informational) Appendix A Transferring YANG Work to IEEE 1588 WG ............. 25
............................................................... 25 A.1. Assumptions for the Transfer ........................... 26
A.1. Assumptions for the Transfer .......................... 25 A.2. Intellectual Property Considerations ................... 26
A.2. Intellectual Property Considerations .................. 26 A.3. Namespace and Module Name .............................. 27
A.3. Namespace and Module Name ............................. 27 A.4. IEEE 1588 YANG Modules in ASCII Format ................. 28
A.4. IEEE 1588 YANG Modules in ASCII Format ................ 28
1. Introduction 1. Introduction
As a synchronization protocol, IEEE 1588-2008 [IEEE1588] is widely As a synchronization protocol, IEEE 1588-2008 [IEEE1588] is widely
supported in the carrier networks, industrial networks, automotive supported in the carrier networks, industrial networks, automotive
networks, and many other applications. It can provide high networks, and many other applications. It can provide high
precision time synchronization as fine as nano-seconds. The precision time synchronization as fine as nano-seconds. The
protocol depends on a Precision Time Protocol (PTP) engine to protocol depends on a Precision Time Protocol (PTP) engine to
decide its own state automatically, and a PTP transportation layer decide its own state automatically, and a PTP transportation layer
to carry the PTP timing and various quality messages. The to carry the PTP timing and various quality messages. The
skipping to change at page 4, line 10 skipping to change at page 4, line 6
foundation. foundation.
It is expected that the IEEE 1588-2008 YANG module be used as It is expected that the IEEE 1588-2008 YANG module be used as
follows: follows:
o The IEEE 1588-2008 YANG module can be used as-is for products o The IEEE 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 1588-
2008. 2008.
o When the IEEE 1588 standard is revised (e.g. the IEEE 1588 o When the IEEE 1588 standard is revised (e.g. the IEEE 1588
revision in progress scheduled to be published in 2017), it will revision in progress at the time of writing this document), it will
add some new optional features to its data sets. The YANG module add some new optional features to its data sets. The YANG module
of this document can be revised and extended to add the new of this document MAY be revised and extended to support these new
features (e.g. of IEEE 1588-2017). The YANG "revision" can be used features. Moreover, the YANG "revision" SHOULD be used to indicate
to indicate changes to the YANG module. changes to the YANG module under such a circumstance.
o A profile standard based on IEEE 1588-2008 may create a o A profile standard based on IEEE 1588-2008 may create a
dedicated YANG module for its profile. The profile's YANG module dedicated YANG module for its profile. The profile's YANG module
may use YANG "import" to import the IEEE 1588-2008 YANG module as SHOULD use YANG "import" to import the IEEE 1588-2008 YANG module
its foundation. Then the profile's YANG module can use YANG as its foundation. Then the profile's YANG module SHOULD use YANG
"augment" to add any profile-specific enhancements. "augment" to add any profile-specific enhancements.
o A product that conforms to a profile standard can also create o A product that conforms to a profile standard can also create
its own YANG module. The product's YANG module can "import" the its own YANG module. The product's YANG module SHOULD "import" the
profile's module, and then use YANG "augment" to add any product- profile's module, and then use YANG "augment" to add any product-
specific enhancements. specific enhancements.
1.1. Conventions used in this document 1.1. Conventions used in this document
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in
this document are to be interpreted as described in [RFC2119]. this document are to be interpreted as described in [RFC2119].
1.2. Terminology 1.2. Terminology
Most terminologies used in this document are extracted from Most terminologies used in this document are extracted from
[IEEE1588]. [IEEE1588].
BC Boundary Clock BC Boundary Clock, see Section 3.1.3 of [IEEE1588]
DS Data Set DS Data Set
E2E End-to-End E2E End-to-End
EUI Extended Unique Identifier. EUI Extended Unique Identifier
GPS Global Positioning System GPS Global Positioning System
IANA Internet Assigned Numbers Authority IANA Internet Assigned Numbers Authority
IP Internet Protocol IP Internet Protocol
NIST National Institute of Standards and Technology NIST National Institute of Standards and Technology
NTP Network Time Protocol NTP Network Time Protocol
OC Ordinary Clock, see Section 3.1.22 of [IEEE1588]
OC Ordinary Clock
P2P Peer-to-Peer P2P Peer-to-Peer
PTP Precision Time Protocol PTP Precision Time Protocol
TAI International Atomic Time TAI International Atomic Time
TC Transparent Clock TC Transparent Clock, see Section 3.1.46 of [IEEE1588]
UTC Coordinated Universal Time UTC Coordinated Universal Time
PTP dataset 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 protocol decisions and for providing values for PTP PTP protocol decisions and for providing values for PTP
message fields, see Section 8 of [IEEE1588]. message fields, see 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 dataset. represented by a specific PTP data set.
2. IEEE 1588-2008 YANG Model hierarchy 2. IEEE 1588-2008 YANG Model hierarchy
This section describes the hierarchy of an IEEE 1588-2008 YANG This section describes the hierarchy of an IEEE 1588-2008 YANG
module. Query and configuration of device wide or port specific module. Query and configuration of device wide or port specific
configuration information and clock data set are described for this configuration information and clock data set are described for this
version. version.
Query and configuration of clock information include: Query and configuration of clock information include:
skipping to change at page 6, line 19 skipping to change at page 6, line 14
A simplified graphical representation of the data model is A simplified graphical representation of the data model is
typically used by YANG modules as described in [RFC8040]. This typically used by YANG modules as described in [RFC8040]. This
document uses the same representation and the meaning of the document uses the same representation and the meaning of the
symbols in these diagrams is as follows: symbols in these diagrams is as follows:
o Brackets "[" and "]" enclose list keys. o Brackets "[" and "]" enclose list keys.
o Abbreviations before data node names: "rw" means configuration o Abbreviations before data node names: "rw" means configuration
data (read-write) and "ro" state data (read-only). For IEEE 1588- data (read-write) and "ro" state data (read-only). For IEEE 1588-
2008, all data nodes are marked "rw" (see 2.2). 2008, most data nodes are marked "rw" (see 2.2).
o Symbols after data node names: "?" means an optional node, "!" o Symbols after data node names: "?" means an optional node, "!"
means a presence container, and "*" denotes a list and leaf-list. means a presence container, and "*" denotes a list or leaf-list.
o Parentheses enclose choice and case nodes, and case nodes are o Parentheses enclose choice and case nodes, and case nodes are
also marked with a colon (":"). also marked with a colon (":").
o Ellipsis ("...") stands for contents of subtrees that are not o Ellipsis ("...") stands for contents of subtrees that are not
shown. shown.
o Arrow ("->") stands for a reference to a particular leaf o Arrow ("->") stands for a reference to a particular leaf
instance in the tree. instance in the tree.
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
| | +--rw 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
| | | +--rw clock-class? uint8 | | | +--rw clock-class? uint8
| | | +--rw clock-accuracy? uint8 | | | +--rw clock-accuracy? uint8
| | | +--rw offset-scaled-log-variance? uint16 | | | +--rw offset-scaled-log-variance? uint16
| | +--rw priority1? uint8 | | +--rw priority1? uint8
| | +--rw priority2? uint8 | | +--rw priority2? uint8
| | +--rw domain-number? uint8 | | +--rw domain-number? uint8
| | +--rw slave-only? boolean | | +--rw slave-only? boolean
| +--rw current-ds | +--rw current-ds
skipping to change at page 7, line 41 skipping to change at page 7, line 36
| +--rw underlying-interface? if:interface-ref | +--rw underlying-interface? if:interface-ref
| +--rw log-min-delay-req-interval? int8 | +--rw log-min-delay-req-interval? int8
| +--rw peer-mean-path-delay? time-interval-type | +--rw peer-mean-path-delay? time-interval-type
| +--rw log-announce-interval? int8 | +--rw log-announce-interval? int8
| +--rw announce-receipt-timeout? uint8 | +--rw announce-receipt-timeout? uint8
| +--rw log-sync-interval? int8 | +--rw log-sync-interval? int8
| +--rw delay-mechanism? delay-mechanism-enumeration | +--rw delay-mechanism? delay-mechanism-enumeration
| +--rw log-min-pdelay-req-interval? int8 | +--rw log-min-pdelay-req-interval? int8
| +--rw version-number? uint8 | +--rw version-number? uint8
+--rw transparent-clock-default-ds +--rw transparent-clock-default-ds
| +--rw 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 clock-identity? clock-identity-type
+--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 are intended to provide compatibility with
skipping to change at page 8, line 41 skipping to change at page 8, line 41
in PTP data sets as one of the following: in 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. 1588 protocol operation.
- Static: Read-only to management, and the value typically does not - Static: Read-only to management, and the value typically does not
change. change.
For details on the classification of each PTP data set member,
refer to the IEEE Std 1588-2008 specification for that member.
Under certain circumstances, the classification of an IEEE 1588 Under certain circumstances, the classification of an IEEE 1588
data set member can change. For details on the classification of data set member may change for a YANG implementation, for example,
each PTP data set member, refer to the IEEE Std 1588-2008 a configurable member needs to be changed to read-only. In such a
specification for that member. case, an implementation MAY choose to return a warning upon 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 [RFC7950].
3. IEEE 1588-2008 YANG Module 3. IEEE 1588-2008 YANG Module
This module imports typedefs from [RFC7223]. Most attribute names This module imports typedef "interface-ref" from [RFC8343]. Most
are based on the information model defined in [IEEE1588], but attributes are based on the information model defined in [IEEE1588],
adapted to the YANG style of naming. but their names are adapted to the YANG style of naming.
<CODE BEGINS> file "ietf-ptp@2017-11-28.yang" <CODE BEGINS> file "ietf-ptp@2018-07-02.yang"
module ietf-ptp { module ietf-ptp {
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 { import ietf-interfaces {
prefix if; prefix if;
} }
organization "IETF TICTOC Working Group"; organization "IETF TICTOC Working Group";
skipping to change at page 9, line 38 skipping to change at page 9, line 38
<mailto: Yaakov_s@rad.com> <mailto: Yaakov_s@rad.com>
Editor: Yuanlong Jiang Editor: Yuanlong Jiang
<mailto:jiangyuanlong@huawei.com> <mailto:jiangyuanlong@huawei.com>
Editor: Rodney Cummings Editor: Rodney Cummings
<mailto:rodney.cummings@ni.com>"; <mailto:rodney.cummings@ni.com>";
description description
"This YANG module defines a data model for the configuration "This YANG module defines a data model for the configuration
of IEEE 1588-2008 clocks, and also for retrieval of the state of IEEE 1588-2008 clocks, and also for retrieval of the state
data of IEEE 1588-2008 clocks."; data of IEEE 1588-2008 clocks.";
revision "2017-11-28" { revision "2018-07-02" {
description "Version 7.0"; description "Version 8.0";
reference "draft-ietf-tictoc-1588v2-yang"; reference "draft-ietf-tictoc-1588v2-yang";
} }
typedef delay-mechanism-enumeration { typedef delay-mechanism-enumeration {
type enumeration { type enumeration {
enum e2e { enum e2e {
value 1; value 1;
description description
"The port uses the delay request-response mechanism."; "The port uses the delay request-response mechanism.";
} }
skipping to change at page 12, line 41 skipping to change at page 12, line 41
description description
"The offsetScaledLogVariance provides an estimate of "The offsetScaledLogVariance provides an estimate of
the variations of the clock from a linear timescale the variations of the clock from a linear timescale
when it is not synchronized to another clock when it is not synchronized to another clock
using the protocol."; using the protocol.";
} }
} }
container ptp { container ptp {
description description
"The PTP struct containing all attributes of PTP Dataset, "The PTP struct containing all attributes of PTP data set,
other optional PTP attributes can be augmented as well."; other optional PTP attributes can be augmented as well.";
list instance-list { list instance-list {
key "instance-number"; key "instance-number";
description description
"List of one or more PTP datasets in the device (see IEEE "List of one or more PTP data sets in the device (see IEEE
Std 1588-2008 subclause 6.3). Std 1588-2008 subclause 6.3).
Each PTP dataset represents a distinct instance of Each PTP data set represents a distinct instance of
PTP implementation in the device (i.e. distinct PTP implementation in the device (i.e. distinct
Ordinary Clock or Boundary Clock)."; Ordinary Clock or Boundary Clock).";
leaf instance-number { leaf instance-number {
type uint32; type uint32;
description description
"The instance number of the current PTP instance. "The instance number of the current PTP instance.
This instance number is used for management purposes This instance number is used for management purposes
only. This instance number does not represent the PTP only. This instance number does not represent the PTP
domain number, and is not used in PTP messages."; domain number, and is not used in PTP messages.";
skipping to change at page 13, line 33 skipping to change at page 13, line 33
leaf two-step-flag { leaf two-step-flag {
type boolean; type boolean;
description description
"When set, the clock is a two-step clock; otherwise, "When set, the clock is a two-step clock; otherwise,
the clock is a one-step clock."; the clock is a one-step clock.";
} }
leaf clock-identity { leaf clock-identity {
type clock-identity-type; type clock-identity-type;
config false;
description description
"The clockIdentity of the local clock"; "The clockIdentity of the local clock";
} }
leaf number-ports { leaf number-ports {
type uint16; type uint16;
description description
"The number of PTP ports on the instance."; "The number of PTP ports on the instance.";
} }
skipping to change at page 13, line 49 skipping to change at page 14, line 4
description description
"The number of PTP ports on the instance."; "The number of PTP ports on the instance.";
} }
container clock-quality { container clock-quality {
description description
"The clockQuality of the local clock."; "The clockQuality of the local clock.";
uses clock-quality-grouping; uses clock-quality-grouping;
} }
leaf priority1 { leaf priority1 {
type uint8; type uint8;
description description
"The priority1 attribute of the local clock."; "The priority1 attribute of the local clock.";
} }
leaf priority2{ leaf priority2{
type uint8; type uint8;
description description
"The priority2 attribute of the local clock. "; "The priority2 attribute of the local clock.";
} }
leaf domain-number { leaf domain-number {
type uint8; type uint8;
description description
"The domain number of the current syntonization "The domain number of the current syntonization
domain."; domain.";
} }
leaf slave-only { leaf slave-only {
skipping to change at page 15, line 23 skipping to change at page 15, line 24
container parent-ds { container parent-ds {
description description
"The parent data set of the clock (see IEEE Std 1588-2008 "The parent data set of the clock (see IEEE Std 1588-2008
subclause 8.2.3)."; subclause 8.2.3).";
container parent-port-identity { container parent-port-identity {
description description
"The portIdentity of the port on the master, it "The portIdentity of the port on the master, it
contains two members: clockIdentity and portNumber."; contains two members: clockIdentity and portNumber.";
reference reference
"IEEE Std 1588-2008: 5.3.5"; "IEEE Std 1588-2008: 5.3.5";
leaf clock-identity { leaf clock-identity {
type clock-identity-type; type clock-identity-type;
description description
"Identity of the clock"; "Identity of the clock";
} }
leaf port-number { leaf port-number {
type uint16; type uint16;
description description
skipping to change at page 18, line 33 skipping to change at page 18, line 37
uses a typed struct with members clockIdentity and uses a typed struct with members clockIdentity and
portNumber. portNumber.
In this YANG data model, portIdentity is not modeled In this YANG data model, portIdentity is not modeled
in the port-ds-list, however, its members are provided in the port-ds-list, however, its members are provided
as follows: as follows:
portIdentity.portNumber is provided as this port- portIdentity.portNumber is provided as this port-
number leaf in port-ds-list; and number leaf in port-ds-list; and
portIdentity.clockIdentity is provided as the clock- portIdentity.clockIdentity is provided as the clock-
identity leaf in default-ds of the instance identity leaf in default-ds of the instance
(i.e. ../../default-ds /clock-identity)."; (i.e. ../../default-ds/clock-identity).";
} }
leaf port-state { leaf port-state {
type port-state-enumeration; type port-state-enumeration;
default "initializing"; default "initializing";
description description
"Current state associated with the port."; "Current state associated with the port.";
} }
leaf underlying-interface { 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 7223)."; is used by this PTP Port (see RFC 8343).";
} }
leaf log-min-delay-req-interval { leaf log-min-delay-req-interval {
type int8; type int8;
description description
"The base-two logarithm of the minDelayReqInterval "The base-two logarithm of the minDelayReqInterval
(the minimum permitted mean time interval between (the minimum permitted mean time interval between
successive Delay_Req messages)."; successive Delay_Req messages).";
} }
leaf peer-mean-path-delay { leaf peer-mean-path-delay {
type time-interval-type; type time-interval-type;
skipping to change at page 20, line 27 skipping to change at page 20, line 29
type uint8; type uint8;
description description
"The PTP version in use on the port."; "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).";
leaf clock-identity { leaf clock-identity {
type clock-identity-type; type clock-identity-type;
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.";
} }
leaf primary-domain { leaf primary-domain {
type uint8; type uint8;
default 0; default 0;
description description
"The domainNumber of the primary syntonization domain."; "The domainNumber of the primary syntonization domain.";
} }
} }
list transparent-clock-port-ds-list { list transparent-clock-port-ds-list {
key "port-number"; key "port-number";
description description
skipping to change at page 21, line 25 skipping to change at page 21, line 27
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 In this YANG data model, portIdentity is not modeled in
the transparent-clock-port-ds-list, however, the transparent-clock-port-ds-list, however, its
members are provided as follows:
portIdentity.portNumber is provided as this leaf member portIdentity.portNumber is provided as this leaf member
in transparent-clock-port-ds-list."; 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-
leaf clock-identity { identity).";
type clock-identity-type;
description
"clock-identity.
The data sets (i.e. information model) of IEEE Std
1588-2008 specify a member
transparentClockPortDS.portIdentity, which uses a typed
struct with members clockIdentity and portNumber.
In this YANG data model, portIdentity is not modeled in
the transparent-clock-port-ds-list, however,
portIdentity.clockIdentity is provided as this leaf
member in transparent-clock-port-ds-list.";
} }
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).";
} }
skipping to change at page 22, line 34 skipping to change at page 22, line 28
} }
} }
<CODE ENDS> <CODE ENDS>
4. Security Considerations 4. Security Considerations
YANG modules are designed to be accessed via the NETCONF protocol YANG modules are designed to be accessed via the NETCONF protocol
[RFC6241], thus security considerations in [RFC6241] apply here. [RFC6241], thus security considerations in [RFC6241] apply here.
Security measures such as using the NETCONF over SSH [RFC6242] and Security measures such as using the NETCONF over SSH [RFC6242] and
restricting its use with access control [RFC6536] can further restricting its use with access control [RFC8341] can further
improve its security, avoid injection attacks and misuse of the improve its security, avoid injection attacks and misuse of the
protocol. Furthermore, general security considerations of time protocol. Furthermore, general security considerations of time
protocols are discussed in [RFC7384]. protocols are discussed in [RFC7384].
Some data nodes defined in this YANG module are writable, and an Most data nodes defined in this YANG module are writable, and an
inappropriate use of them may adversely impact a synchronization inappropriate use of them may adversely impact a synchronization
network. For example, loss of synchronization on a clock, accuracy network. For example, loss of synchronization on a clock, accuracy
degradation on a set of clocks, or even break down of a whole degradation on a set of clocks, or even break down of a whole
synchronization network. synchronization network.
5. IANA Considerations 5. IANA Considerations
This document registers a URI in the IETF XML registry, and the This document registers a URI in the IETF XML registry, and the
following registration is requested to be made: following registration is requested to be made:
URI: urn:ietf:params:xml:ns:yang:ietf-ptp URI: urn:ietf:params:xml:ns:yang:ietf-ptp
skipping to change at page 23, line 28 skipping to change at page 23, line 28
[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, March 1997
[RFC6020] Bjorklund, M., "YANG - A Data Modeling Language for the [RFC6020] Bjorklund, M., "YANG - A Data Modeling Language for the
Network Configuration Protocol (NETCONF) ", RFC 6020, Network Configuration Protocol (NETCONF) ", RFC 6020,
October 2010 October 2010
[RFC6991] Schoenwaelder, J., "Common YANG Data Types", RFC 6991, [RFC6991] Schoenwaelder, J., "Common YANG Data Types", RFC 6991,
July 2013 July 2013
[RFC7223] Bjorklund, M., "A YANG Data Model for Interface [RFC7950] Bjorklund, M., "The YANG 1.1 Data Modeling Language", RFC
Management", RFC 7223, May 2014 7950, August 2016
[RFC8343] Bjorklund, M., "A YANG Data Model for Interface
Management", RFC 8343, March 2018
[IEEE1588] IEEE, "IEEE Standard for a Precision Clock [IEEE1588] IEEE, "IEEE Standard for a Precision Clock
Synchronization Protocol for Networked Measurement and Synchronization Protocol for Networked Measurement and
Control Systems", IEEE Std 1588-2008, July 2008 Control Systems", IEEE Std 1588-2008, July 2008
6.2. Informative References 6.2. Informative References
[IEEE8021AS] IEEE, "Timing and Synchronizations for Time-Sensitive [IEEE8021AS] IEEE, "Timing and Synchronizations for Time-Sensitive
Applications in Bridged Local Area Networks", IEEE Applications in Bridged Local Area Networks", IEEE
802.1AS-2001, 2011 802.1AS-2001, 2011
skipping to change at page 24, line 8 skipping to change at page 24, line 12
[RFC4663] Harrington, D., "Transferring MIB Work from IETF Bridge [RFC4663] Harrington, D., "Transferring MIB Work from IETF Bridge
MIB WG to IEEE 802.1 WG", RFC 4663, September 2006 MIB WG to IEEE 802.1 WG", RFC 4663, September 2006
[RFC6241] Enns, R., Bjorklund, M., Schoenwaelder, J., and A. [RFC6241] Enns, R., Bjorklund, M., Schoenwaelder, J., and A.
Bierman, "Network Configuration Protocol (NETCONF)", RFC Bierman, "Network Configuration Protocol (NETCONF)", RFC
6241, June 2011 6241, June 2011
[RFC6242] Wasserman, M., "Using the NETCONF Protocol over Secure [RFC6242] Wasserman, M., "Using the NETCONF Protocol over Secure
Shell (SSH)", RFC 6242, June 2011 Shell (SSH)", RFC 6242, June 2011
[RFC6536] Bierman, A. and M. Bjorklund, "Network Configuration [RFC8341] Bierman, A. and M. Bjorklund, "Network Configuration
Protocol (NETCONF) Access Control Model", RFC 6536, March Protocol (NETCONF) Access Control Model", RFC 8341, March
2012 2018
[RFC7384] Mizrahi, T., "Security Requirements of Time Protocols in [RFC7384] Mizrahi, T., "Security Requirements of Time Protocols in
Packet Switched Networks", RFC 7384, October 2014 Packet Switched Networks", RFC 7384, October 2014
[RFC8040] Bierman, A., Bjorklund, M., and Watsen, K., "RESTCONF [RFC8040] Bierman, A., Bjorklund, M., and Watsen, K., "RESTCONF
protocol", RFC 8040, January 2017 protocol", RFC 8040, January 2017
[RFC8173] Shankarkumar, V., Montini, L., Frost, T., and Dowd, G., [RFC8173] Shankarkumar, V., Montini, L., Frost, T., and Dowd, G.,
"Precision Time Protocol Version 2 (PTPv2) Management "Precision Time Protocol Version 2 (PTPv2) Management
Information Base", RFC 8173, June 2017 Information Base", RFC 8173, June 2017
7. Acknowledgments 7. Acknowledgments
The authors would like to thank Joe Gwinn, Mahesh Jethanandani, Tal The authors would like to thank Joe Gwinn, Mahesh Jethanandani, Tal
Mizrahi, Opher Ronen, Liang Geng, Alex Campbell, Tom Petch and John Mizrahi, Opher Ronen, Liang Geng, Alex Campbell, Tom Petch, John
Fletcher for their valuable reviews and suggestions, and thank Fletcher and Dave Thaler for their valuable reviews and suggestions,
Benoit Claise and Radek Krejci for their validation of the YANG and thank Benoit Claise and Radek Krejci for their validation of
module. the YANG module.
Appendix A Transferring YANG Work to IEEE 1588 WG (Informational) Appendix A Transferring YANG Work to IEEE 1588 WG
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 1588 YANG modules from the IETF TICTOC Working Group (WG)
to the IEEE 1588 WG, which develops the time synchronization 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 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
skipping to change at page 25, line 49 skipping to change at page 26, line 8
by discussion on the IETF TICTOC WG mailing lists and/or by discussion on the IETF TICTOC WG mailing lists and/or
appropriate liaisons. appropriate liaisons.
This appendix obtained insight from [RFC4663], an informational This appendix obtained insight from [RFC4663], an informational
memo that described a similar transfer of MIB work from the IETF memo that described a similar transfer of MIB work from the IETF
Bridge MIB WG to the IEEE 802.1 WG. Bridge 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
IETF TICTOC WG has approved a standard YANG module for a published IESG has approved the publication of an RFC containing a YANG
IEEE 1588 standard. As of this writing, this is IEEE Std 1588-2008, module for a published IEEE 1588 standard. As of this writing,
but it is possible that YANG for subsequent 1588 revisions could be this is IEEE Std 1588-2008, but it is possible that YANG modules
published from the IETF TICTOC WG. For discussion in this appendix, for subsequent 1588 revisions could be published from the IETF
we use the phrase "last IETF 1588 YANG" to refer to most recently TICTOC WG. For discussion in this appendix, we use the phrase
published 1588 YANG from the IETF TICTOC WG. "last IETF 1588 YANG" to refer to the most recently published 1588
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 new Project Authorization Requests (PARs) (see handles 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 projects. standardization 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
skipping to change at page 27, line 11 skipping to change at page 27, line 19
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 during the development of this mechanisms will be updated as needed during the development of this
document and any future IETF YANG modules for IEEE 1588. This will document (Note: update it to the actual RFC if published) and any
help to make the future transfer of work from IETF to IEEE occur as future IETF YANG modules for IEEE 1588. This will help to make the
smoothly as possible. future transfer of work from IETF to IEEE 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 the "IANA Considerations" section, the YANG module As specified in Section 5 "IANA Considerations", the YANG module in
in this document uses IETF as the root of its URN namespace and this document uses IETF as the root of its URN namespace and YANG
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. If the IEEE 1588 Working Group were to continue using processes. If the IEEE 1588 Working Group were to continue using
these names rooted in IETF, the IEEE 1588 YANG standardization these names rooted in IETF, the IEEE 1588 YANG standardization
would need to continue in the IETF. The goal of transferring the would need to continue in the IETF. The goal of transferring the
YANG work is to avoid this sort of dependency between standards YANG work is to 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
 End of changes. 52 change blocks. 
104 lines changed or deleted 106 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/