--- 1/draft-ietf-tictoc-1588v2-yang-08.txt 2018-07-23 23:13:13.229192256 -0700 +++ 2/draft-ietf-tictoc-1588v2-yang-09.txt 2018-07-23 23:13:13.285193605 -0700 @@ -1,29 +1,30 @@ 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: January 2019 July 2, 2018 +Expires: January 2019 July 24, 2018 YANG Data Model for IEEE 1588-2008 - draft-ietf-tictoc-1588v2-yang-08 + draft-ietf-tictoc-1588v2-yang-09 Abstract This document defines a YANG data model for the configuration of IEEE 1588-2008 devices and clocks, and also retrieval of the configuration information, data set and running states of IEEE - 1588-2008 clocks. + 1588-2008 clocks. The YANG module in this document conforms to the + Network Management Datastore Architecture (NMDA). 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. @@ -33,21 +34,21 @@ 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 http://www.ietf.org/ietf/1id-abstracts.txt The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html - This Internet-Draft will expire on January 2, 2019. + This Internet-Draft will expire on January 24, 2019. Copyright Notice Copyright (c) 2018 IETF Trust and the persons identified as the document authors. All rights reserved. This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents @@ -63,27 +64,27 @@ 1.1. Conventions used in this document ....................... 4 1.2. Terminology ............................................. 4 2. IEEE 1588-2008 YANG Model hierarchy ........................ 5 2.1. Interpretations from IEEE 1588 Working Group ............ 8 2.2. Configuration and state ................................. 8 3. IEEE 1588-2008 YANG Module ................................. 9 4. Security Considerations ................................... 22 5. IANA Considerations ....................................... 23 6. References ................................................ 23 6.1. Normative References ................................... 23 - 6.2. Informative References ................................. 23 - 7. Acknowledgments ........................................... 24 - Appendix A Transferring YANG Work to IEEE 1588 WG ............. 25 - A.1. Assumptions for the Transfer ........................... 26 - A.2. Intellectual Property Considerations ................... 26 - A.3. Namespace and Module Name .............................. 27 - A.4. IEEE 1588 YANG Modules in ASCII Format ................. 28 + 6.2. Informative References ................................. 24 + 7. Acknowledgments ........................................... 25 + Appendix A Transferring YANG Work to IEEE 1588 WG ............. 26 + A.1. Assumptions for the Transfer ........................... 27 + A.2. Intellectual Property Considerations ................... 27 + A.3. Namespace and Module Name .............................. 28 + A.4. IEEE 1588 YANG Modules in ASCII Format ................. 29 1. Introduction As a synchronization protocol, IEEE 1588-2008 [IEEE1588] is widely supported in the carrier networks, industrial networks, automotive networks, and many other applications. It can provide high precision time synchronization as fine as nano-seconds. The protocol depends on a Precision Time Protocol (PTP) engine to decide its own state automatically, and a PTP transportation layer to carry the PTP timing and various quality messages. The @@ -100,37 +101,39 @@ Network Management Protocol (SNMP), furthermore, configuration of PTP data sets is not considered in [RFC8173]. Some service providers and applications require that the management of the IEEE 1588-2008 synchronization network be flexible and more Internet-based (typically overlaid on their transport networks). Software Defined Network (SDN) is another driving factor, which demands an improved configuration capability of synchronization networks. - YANG [RFC6020] 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 protocols like the Network Configuration Protocol (NETCONF) [RFC6241]. A small set of built-in data types are defined in - [RFC6020], and a collection of common data types are further + [RFC7950], and a collection of common data types are further defined in [RFC6991]. Advantages of YANG include Internet based configuration capability, validation, rollback and so on. All of these characteristics make it attractive to become another candidate modeling language for IEEE 1588-2008. - This document defines a YANG [RFC6020] data model for the - configuration of IEEE 1588-2008 devices and clocks, and retrieval - of the state data of IEEE 1588-2008 clocks. The data model is based - on the PTP data sets as specified in [IEEE1588]. The technology - specific IEEE 1588-2008 information, e.g., those specifically - implemented by a bridge, a router or a telecom profile, is out of - scope of this document. + This document defines a YANG data model for the configuration of + IEEE 1588-2008 devices and clocks, and retrieval of the state data + of IEEE 1588-2008 clocks. The data model is based on the PTP data + sets as specified in [IEEE1588]. The technology specific IEEE 1588- + 2008 information, e.g., those specifically implemented by a bridge, + a router or a telecom profile, is out of scope of this document. + + The YANG module in this document conforms to the Network Management + Datastore Architecture (NMDA) [RFC8342]. When used in practice, network products in support of synchronization typically conform to one or more IEEE 1588-2008 profiles. Each profile specifies how IEEE 1588-2008 is used in a given industry (e.g. telecom, automotive) and application. A profile can require features that are optional in IEEE 1588-2008, and it can specify new features that use IEEE 1588-2008 as a foundation. It is expected that the IEEE 1588-2008 YANG module be used as @@ -153,23 +156,25 @@ 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 can 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", "MAY", and "OPTIONAL" in - this document are to be interpreted as described in [RFC2119]. + 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 Most terminologies used in this document are extracted from [IEEE1588]. BC Boundary Clock, see Section 3.1.3 of [IEEE1588] DS Data Set @@ -225,42 +230,23 @@ default-ds. - Port-specific data set attributes, including: port-ds and transparent-clock-port-ds. The readers are assumed to be familiar with IEEE 1588-2008. As all PTP terminologies and PTP data set attributes are described in details in IEEE 1588-2008 [IEEE1588], this document only outlines each of them in the YANG module. - A simplified graphical representation of the data model is - typically used by YANG modules as described in [RFC8040]. This - document uses the same representation and the meaning of the - symbols in these diagrams is as follows: - - o Brackets "[" and "]" enclose list keys. - - o Abbreviations before data node names: "rw" means configuration - data (read-write) and "ro" state data (read-only). For IEEE 1588- - 2008, most data nodes are marked "rw" (see 2.2). - - o Symbols after data node names: "?" means an optional node, "!" - means a presence container, and "*" denotes a list or leaf-list. - - o Parentheses enclose choice and case nodes, and case nodes are - also marked with a colon (":"). - - o Ellipsis ("...") stands for contents of subtrees that are not - shown. - - o Arrow ("->") stands for a reference to a particular leaf - instance in the tree. + A simplified YANG tree diagram [RFC8340] representing the data + model is typically used by YANG modules. This document uses the + same tree diagram syntax as described in [RFC8340]. module: ietf-ptp +--rw ptp +--rw instance-list* [instance-number] | +--rw instance-number uint32 | +--rw default-ds | | +--rw two-step-flag? boolean | | +--ro clock-identity? clock-identity-type | | +--rw number-ports? uint16 | | +--rw clock-quality @@ -275,21 +261,21 @@ | | +--rw steps-removed? uint16 | | +--rw offset-from-master? time-interval-type | | +--rw mean-path-delay? time-interval-type | +--rw parent-ds | | +--rw parent-port-identity | | | +--rw clock-identity? clock-identity-type | | | +--rw port-number? uint16 | | +--rw parent-stats? boolean | | +--rw observed-parent-offset-scaled-log-variance? uint16 | | +--rw observed-parent-clock-phase-change-rate? int32 - | | +--rw grandmaster-identity? binary + | | +--rw grandmaster-identity? clock-identity-type | | +--rw grandmaster-clock-quality | | | +--rw clock-class? uint8 | | | +--rw clock-accuracy? uint8 | | | +--rw offset-scaled-log-variance? uint16 | | +--rw grandmaster-priority1? uint8 | | +--rw grandmaster-priority2? uint8 | +--rw time-properties-ds | | +--rw current-utc-offset-valid? boolean | | +--rw current-utc-offset? int16 | | +--rw leap59? boolean @@ -323,21 +309,21 @@ 2.1. Interpretations from IEEE 1588 Working Group The preceding model and the associated YANG module have some subtle differences from the data set specifications of IEEE Std 1588-2008. These differences are based on interpretation from the IEEE 1588 Working Group, and are intended to provide compatibility with future revisions of the IEEE 1588 standard. In IEEE Std 1588-2008, a physical product can implement multiple - PTP clocks (i.e. ordinary, boundary, or transparent clock). As + PTP clocks (i.e., ordinary, boundary, or transparent clock). As specified in 1588-2008 subclause 7.1, each of the multiple clocks operates in an independent domain. However, the organization 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 described in the new revision of IEEE 1588. 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, most transparent clock products have interpreted the transparent @@ -366,50 +352,52 @@ 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 This module imports typedef "interface-ref" from [RFC8343]. Most attributes are based on the information model defined in [IEEE1588], but their names are adapted to the YANG style of naming. - file "ietf-ptp@2018-07-02.yang" - + file "ietf-ptp@2018-07-24.yang" + //Note to RFC Editor: update the date to date of publication module ietf-ptp { + yang-version 1.1; namespace "urn:ietf:params:xml:ns:yang:ietf-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: - WG Chair: Karen O'Donoghue - - WG Chair: Yaakov Stein - Editor: Yuanlong Jiang Editor: Rodney Cummings "; 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-07-02" { - description "Version 8.0"; - reference "draft-ietf-tictoc-1588v2-yang"; + revision "2018-07-24" { + //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 { @@ -544,47 +532,46 @@ } 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 + 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)."; leaf two-step-flag { type boolean; description - "When set, the clock is a two-step clock; otherwise, - the clock is a one-step clock."; + "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 { @@ -614,21 +601,21 @@ leaf domain-number { type uint8; description "The domain number of the current syntonization domain."; } leaf slave-only { type boolean; description - "When set, the clock is a slave-only clock."; + "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)."; leaf steps-removed { @@ -677,21 +664,21 @@ type uint16; description "Port number"; } } leaf parent-stats { type boolean; default false; description - "When set, the values of + "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 @@ -699,23 +686,21 @@ } 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 binary { - length "8"; - } + 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; } @@ -734,66 +719,68 @@ } 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, the current UTC offset is valid."; + "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, i.e., when ptp-timescale - is TRUE; otherwise, the value has no meaning."; + 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, the last minute of the current UTC day - contains 59 seconds."; + "When set to true, the last minute of the current UTC + day contains 59 seconds."; } leaf leap61 { type boolean; description - "When set, the last minute of the current UTC day - contains 61 seconds."; + "When set to true, the last minute of the current UTC + day contains 61 seconds."; } leaf time-traceable { type boolean; description - "When set, the timescale and the currentUtcOffset are - traceable to a primary reference."; + "When set to true, the timescale and the + currentUtcOffset are traceable to a primary + reference."; } leaf frequency-traceable { type boolean; description - "When set, the frequency determining the timescale - is traceable to a primary reference."; + "When set to true, the frequency determining the + timescale is traceable to a primary reference."; } leaf ptp-timescale { type boolean; description - "When set, the clock timescale of the grandmaster - clock is PTP; otherwise, the timescale is ARB + "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 { @@ -800,33 +787,33 @@ key "port-number"; description "List of port data sets of the clock (see IEEE Std 1588-2008 subclause 8.2.5)."; leaf port-number{ type uint16; description "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 portDS.portIdentity, which uses a typed struct with members clockIdentity and portNumber. 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)."; + (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 { @@ -922,27 +909,30 @@ description "The number of PTP ports on the transparent clock."; } leaf delay-mechanism { type delay-mechanism-enumeration; description "The propagation delay measuring option used by the transparent clock."; } + leaf primary-domain { type uint8; default 0; description - "The domainNumber of the primary syntonization domain."; + "The domainNumber of the primary syntonization domain (see + IEEE Std 1588-2008 subclause 10.1)."; } } + list transparent-clock-port-ds-list { key "port-number"; description "List of transparentClockPort data sets of the transparent clock (see IEEE Std 1588-2008 subclause 8.3.3)."; leaf port-number { type uint16; description "Port number. @@ -939,21 +929,21 @@ list transparent-clock-port-ds-list { key "port-number"; description "List of transparentClockPort data sets of the transparent clock (see IEEE Std 1588-2008 subclause 8.3.3)."; leaf port-number { type uint16; description "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 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, 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- @@ -968,21 +958,21 @@ description "The logarithm to the base 2 of the minPdelayReqInterval (minimum permitted mean time interval between successive Pdelay_Req messages)."; } leaf faulty-flag { type boolean; default false; description - "When set, the port is faulty."; + "When set to true, the port is faulty."; } leaf peer-mean-path-delay { type time-interval-type; default 0; description "An estimate of the current one-way propagation delay on the link when the delayMechanism is P2P; otherwise, it is zero."; } @@ -996,123 +986,151 @@ 4. Security Considerations YANG modules are designed to be accessed via the NETCONF protocol [RFC6241], thus security considerations in [RFC6241] apply here. Security measures such as using the NETCONF over SSH [RFC6242] and restricting its use with access control [RFC8341] can further improve its security, avoid injection attacks and misuse of the protocol. Furthermore, general security considerations of time protocols are discussed in [RFC7384]. - Most data nodes defined in this YANG module are writable, and an - inappropriate use of them may adversely impact a synchronization - network. For example, loss of synchronization on a clock, accuracy - degradation on a set of clocks, or even break down of a whole - synchronization network. + All subtrees and most data nodes defined in this YANG module are + writable: + + /ptp/instance-list specifies an instance (i.e., PTP data sets) for + an OC or BC. + + /ptp/transparent-clock-default-ds specifies a default data set for + a TC. + + /ptp/transparent-clock-port-ds-list specifies a list of port data + sets for a TC. + + An inappropriate use of them may adversely impact a PTP + synchronization network. For example, loss of synchronization on a + clock, accuracy degradation on a set of clocks, or even break down + of a whole synchronization network. 5. IANA Considerations - This document registers a URI in the IETF XML registry, and the - following registration is requested to be made: + This document registers the following URI in the "IETF XML + registry" [RFC3688]: URI: urn:ietf:params:xml:ns:yang:ietf-ptp + Registrant Contact: The IESG + XML: N/A; the requested URI is an XML namespace - This document registers a YANG module in the YANG Module Names: - name: ietf-ptp namespace: urn:ietf:params:xml:ns:yang:ietf-ptp + This document registers the following YANG module in the "YANG + Module Names" registry [RFC6020]: + Name: ietf-ptp + Namespace: urn:ietf:params:xml:ns:yang:ietf-ptp + Prefix: ptp + Reference: RFC XXXX 6. References 6.1. Normative References [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997 + [RFC3688] Mealling, M., "The IETF XML Registry", RFC 3688, + 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 A. + Bierman, "Network Configuration Protocol (NETCONF)", RFC + 6241, June 2011 + + [RFC6242] Wasserman, M., "Using the NETCONF Protocol over Secure + Shell (SSH)", RFC 6242, June 2011 + [RFC6991] Schoenwaelder, J., "Common YANG Data Types", RFC 6991, July 2013 [RFC7950] Bjorklund, M., "The YANG 1.1 Data Modeling Language", RFC 7950, August 2016 + [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC + 2119 Key Words", BCP 14, RFC 8174, May 2017 + + [RFC8341] Bierman, A. and Bjorklund, M., "Network Configuration + Protocol (NETCONF) Access Control Model", RFC 8341, March + 2018 + + [RFC8342] Bjorklund, M., Schoenwaelder, J., Shafer, P., Watsen, K., + and R. Wilton, "Network Management Datastore Architecture + (NMDA)", RFC 8342, March 2018 + [RFC8343] Bjorklund, M., "A YANG Data Model for Interface Management", RFC 8343, March 2018 [IEEE1588] IEEE, "IEEE Standard for a Precision Clock Synchronization Protocol for Networked Measurement and Control Systems", IEEE Std 1588-2008, July 2008 6.2. Informative References [IEEE8021AS] IEEE, "Timing and Synchronizations for Time-Sensitive Applications in Bridged Local Area Networks", IEEE 802.1AS-2001, 2011 [RFC3444] Pras, A. and J. Schoenwaelder, "On the Difference between Information Models and Data Models", RFC 3444, January 2003 [RFC4663] Harrington, D., "Transferring MIB Work from IETF Bridge MIB WG to IEEE 802.1 WG", RFC 4663, September 2006 - [RFC6241] Enns, R., Bjorklund, M., Schoenwaelder, J., and A. - Bierman, "Network Configuration Protocol (NETCONF)", RFC - 6241, June 2011 - - [RFC6242] Wasserman, M., "Using the NETCONF Protocol over Secure - Shell (SSH)", RFC 6242, June 2011 - - [RFC8341] Bierman, A. and M. Bjorklund, "Network Configuration - Protocol (NETCONF) Access Control Model", RFC 8341, March - 2018 - [RFC7384] Mizrahi, T., "Security Requirements of Time Protocols in Packet Switched Networks", RFC 7384, October 2014 - [RFC8040] Bierman, A., Bjorklund, M., and Watsen, K., "RESTCONF - protocol", RFC 8040, January 2017 + [RFC8340] Bjorklund, M., and Berger, L., "YANG Tree Diagrams", RFC + 8340, March 2018 [RFC8173] Shankarkumar, V., Montini, L., Frost, T., and Dowd, G., "Precision Time Protocol Version 2 (PTPv2) Management Information Base", RFC 8173, June 2017 7. Acknowledgments - The authors would like to thank Joe Gwinn, Mahesh Jethanandani, Tal - Mizrahi, Opher Ronen, Liang Geng, Alex Campbell, Tom Petch, John - Fletcher and Dave Thaler for their valuable reviews and suggestions, - and thank Benoit Claise and Radek Krejci for their validation of - the YANG module. + The authors would like to thank Tom Petch, Mahesh Jethanandani, Tal + Mizrahi, Opher Ronen, Liang Geng, Alex Campbell, Joe Gwinn, John + Fletcher, William Zhao and Dave Thaler for their valuable reviews + and suggestions, 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. Appendix A Transferring YANG Work to IEEE 1588 WG This Appendix is informational. This appendix describes a future plan to transition responsibility for IEEE 1588 YANG modules from the IETF TICTOC Working Group (WG) to the IEEE 1588 WG, which develops the time synchronization technology that the YANG modules are designed to manage. This appendix is forward-looking with regard to future standardization roadmaps in IETF and IEEE. Since those roadmaps cannot be predicted with significant accuracy, this appendix is informational, and it does not specify imperatives or normative specifications of any kind. The IEEE 1588-2008 YANG module of this standard represents a cooperation between IETF (for YANG) and IEEE (for 1588). For the initial standardization of IEEE-1588 YANG modules, the information - model is relatively clear (i.e. IEEE 1588 data sets), but expertise - in YANG is required, making IETF an appropriate location for the - standards. The TICTOC WG has expertise with IEEE 1588, making it - the appropriate location within IETF. + model is relatively clear (i.e., IEEE 1588 data sets), but + expertise in YANG is required, making IETF an appropriate location + for the standards. The TICTOC WG has expertise with IEEE 1588, + making it the appropriate location within IETF. The IEEE 1588 WG anticipates future changes to its standard on an ongoing basis. As IEEE 1588 WG members gain practical expertise with YANG, the IEEE 1588 WG will become more appropriate for standardization of its YANG modules. As the IEEE 1588 standard is revised and/or amended, IEEE 1588 members can more effectively synchronize the revision of this YANG module with future versions of the IEEE 1588 standard. This appendix is meant to establish some clear expectations between @@ -1180,24 +1198,24 @@ 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, 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 availability of this RFC's authors at the time of its publication, the IEEE Standards Association department of Risk Management and Licensing provided the appropriate forms and mechanisms for this document's authors to assign a non-exclusive license for IEEE to create derivative works from this document. Those IEEE forms and mechanisms will be updated as needed during the development of this - document (Note: update it to the actual RFC if published) and any - future IETF YANG modules for IEEE 1588. This will help to make the - future transfer of work from IETF to IEEE occur as smoothly as - possible. + document (Note: i.e., RFC XXXX, update it to the actual RFC if + published) and any future IETF YANG modules for IEEE 1588. This + will help to make the 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 this document conforms to the provisions of BCP 78. The IETF will retain all the rights granted at the time of publication in the published RFCs. A.3. Namespace and Module Name As specified in Section 5 "IANA Considerations", the YANG module in this document uses IETF as the root of its URN namespace and YANG @@ -1222,21 +1240,21 @@ urn:ieee:Std:1588:yang:ieee1588-ptp where "ieee1588-ptp" is the registered YANG module name in the IEEE. Under the assumptions of section A.1, the first IEEE 1588 YANG module prefix can be the same as the last IETF 1588 YANG module prefix (i.e. "ptp"), since the nodes within both YANG modules are compatible. The result of these name changes are that for complete - compatibility, a server (i.e. IEEE 1588 node) can choose to + compatibility, a server (i.e., IEEE 1588 node) can choose to implement a YANG module for the last IETF 1588 YANG module (with IETF root) as well as the first IEEE 1588 YANG module (with IEEE root). Since the content of the YANG module transferred are the same, the server implementation is effectively common for both. 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 client of the first IEEE 1588 YANG module (or later) looks for the IEEE-rooted module name.