Subject: [TICTOC] FW: I-D Action: draft-ietf-tictoc-1588v2-yang-08.txt

From: Jiangyuanlong <[email-masked]>
Date: Mon, 2 Jul 2018 03:50:39 +0000

Hi experts,

As there have been quite a few comments raised during the Last Call process and in the Intdir early review stage, we have produced this new version with all the suggestions and resolutions incorporated.
A summary of the changes introduced in this document:
1. According to IEEE 1588 and per the discussions in the mailing list, we changed two attribute members to "config false" in the YANG module (default-ds. clock-identity and transparent-clock-default-ds. clock-identity), i.e., they are changed to read-only.
It seems YANG has a requirement that if a leaf key is config false, then its container list must also be config false. Otherwise, the parser will not pass.
Therefore, key "port-number" in both list port-ds-list and list transparent-clock-port-ds-list remain writable. 

2. As noted in the mailing list, leaf member "clock-identity" is removed from transparent-clock-port-ds-list (since portIdentity.clockIdentity is already provided as the clock-identity leaf in transparent-clock-default-ds).

3.The last paragraph of Section 2.2 is updated to: "Under certain circumstances, the classification of an IEEE 1588 data set member may change for a YANG implementation, for example, a configurable member needs to be changed to read-only. In such a 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]." We hope the new texts make it clear how an implementer may change the behavior of YANG attributes in practice.

4. we added references to [IEEE1588] for terms BC, OC and TC as commented by Dave.

5. RFC7950 is added as a normative reference; since two RFC references are obsoleted, we updated them with their newest version (i.e., RFC 8341 and RFC 8343).

6. we add editorial improvements as our reviewers proposed, and use RFC2119 key words in several sentences in Section 1 and Section 2.2. 

In fact, the main technical changes were already presented in the last IETF meeting, the new changes are mostly editorial.  
Thanks a lot to our reviewers! Further reviews and opinions will be appreciated.

Thanks,
Yuanlong on behalf of all co-authors

-----Original Message-----
From: TICTOC [mailto:[email-masked]] On Behalf Of [email-masked]
Sent: Monday, July 02, 2018 10:52 AM
To: [email-masked]
Cc: [email-masked]
Subject: [TICTOC] I-D Action: draft-ietf-tictoc-1588v2-yang-08.txt

A New Internet-Draft is available from the on-line Internet-Drafts directories.
This draft is a work item of the Timing over IP Connection and Transfer of Clock WG of the IETF.

        Title           : YANG Data Model for IEEE 1588-2008
        Authors         : Yuanlong Jiang
                          Xian Liu
                          Jinchun Xu
                          Rodney Cummings
	Filename        : draft-ietf-tictoc-1588v2-yang-08.txt
	Pages           : 30
	Date            : 2018-07-01

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.

The IETF datatracker status page for this draft is:
https://datatracker.ietf.org/doc/draft-ietf-tictoc-1588v2-yang/

There are also htmlized versions available at:
https://tools.ietf.org/html/draft-ietf-tictoc-1588v2-yang-08
https://datatracker.ietf.org/doc/html/draft-ietf-tictoc-1588v2-yang-08

A diff from the previous version is available at:
https://www.ietf.org/rfcdiff?url2=draft-ietf-tictoc-1588v2-yang-08

Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org.

Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/

---

From: Alex Campbell <[email-masked]>
Date: Mon, 2 Jul 2018 05:24:36 +0000

> Therefore, key "port-number" in both list port-ds-list and list transparent-clock-port-ds-list remain writable.

I would just like to clarify on the reason for this particular restriction, as the wording of this comment makes me suspect it might not be understood.

Keys' values are used to identify a list entry.
A "config true" list with "config false" keys doesn't seem to make a lot of sense, because it would mean the management station can add an entry, but it can't set the keys, so it can't identify which entry it is adding. At least, that is my interpretation - please correct me if I'm wrong here.

In any case (even with "config true") the value of a key in an existing list entry cannot be overwritten. At best the entry can be removed and a new entry with different key values can be added.

Regards,
  Alex

________________________________________
From: TICTOC <[email-masked]> on behalf of Jiangyuanlong <[email-masked]>
Sent: Monday, 2 July 2018 3:50 p.m.
To: [email-masked]
Cc: [email-masked]; ZHAO, WILLIAM; t.petch; Dave Thaler
Subject: EXTERNAL: [TICTOC] FW:  I-D Action: draft-ietf-tictoc-1588v2-yang-08.txt

Hi experts,

Thanks,

-----Original Message-----
From: TICTOC [mailto:[email-masked]] On Behalf Of [email-masked]
Sent: Monday, July 02, 2018 10:52 AM
To: [email-masked]
Cc: [email-masked]
Subject: [TICTOC] I-D Action: draft-ietf-tictoc-1588v2-yang-08.txt

Abstract:

_______________________________________________
TICTOC mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/tictoc

---

From: Jiangyuanlong <[email-masked]>
Date: Mon, 2 Jul 2018 06:00:57 +0000

Dear Alex,

Thanks for your clarification on this YANG restriction. 
I totally agree with you that "the value of a key in an existing list entry cannot be overwritten. At best the entry can be removed and a new entry with different key values can be added."
This predicate implies that when "port-number" is a key in both list port-ds-list and list transparent-clock-port-ds-list, it is read-only in effect.

Cheers,
Yuanlong

-----Original Message-----
From: Alex Campbell [mailto:[email-masked]] 
Sent: Monday, July 02, 2018 1:25 PM
To: Jiangyuanlong <[email-masked]>; [email-masked]
Cc: [email-masked]; ZHAO, WILLIAM <[email-masked]>; t.petch <[email-masked]>; Dave Thaler <[email-masked]>
Subject: Re: EXTERNAL: [TICTOC] FW: I-D Action: draft-ietf-tictoc-1588v2-yang-08.txt

Regards,
  Alex

Hi experts,

Thanks,

-----Original Message-----
From: TICTOC [mailto:[email-masked]] On Behalf Of [email-masked]
Sent: Monday, July 02, 2018 10:52 AM
To: [email-masked]
Cc: [email-masked]
Subject: [TICTOC] I-D Action: draft-ietf-tictoc-1588v2-yang-08.txt

Abstract:

---

From: "t.petch" <[email-masked]>
Date: Mon, 2 Jul 2018 16:39:37 +0100

It's been a while and YANG moves on:-(  I think that you need some
changes to the YANG module for which draft-ietf-netmod-rfc6087bis is
your friend while other issues have surfaced as IESG comments at IESG
Review

Abstract needs to say if the module is NMDA compliant

You have lower case 'may' and there is now  revised boiler plate to
cater for this in RFC8174

YANG Tree diagrams is now RFC8340 and the expectation is that you have
an Informative Reference to that and include no further explanation in
the I-D

The RFC Editor would appreciate a Note asking them to update the two
dates in the YANG module to date of publication

     import ietf-interfaces
lacks a reference to the RFC.  If this is 8343, which is YANG 1.1, then
this module must specify YANG 1.1 as version number.

The YANG module needs a Copyright which will include a reference to
XXXX, the number assigned to the I-D on publication.  The RFC Editor
would appreciate a Note asking them to replace all occurrences of XXXX
with the published number (the RFC Editor told me that they like this
Note at the start of the ID as opposed to tucked away on each
occurrence).

The revision should say 'Initial Revision'

contact
should  be editor and author not WG Chair

Security Considerations needs to identify which objects are sensitive or
say that none are.

The RFC listed in Security Considerations need to be Normative; there is
a wiki section this.

IANA Considerations lacks detail, such as the RFC XXXX, Registrant
Contact etc

Tom Petch

----- Original Message -----
From: "Jiangyuanlong" <[email-masked]>
Sent: Monday, July 02, 2018 4:50 AM

Hi experts,

As there have been quite a few comments raised during the Last Call
process and in the Intdir early review stage, we have produced this new
version with all the suggestions and resolutions incorporated.
A summary of the changes introduced in this document:
1. According to IEEE 1588 and per the discussions in the mailing list,
we changed two attribute members to "config false" in the YANG module
(default-ds. clock-identity and transparent-clock-default-ds.
clock-identity), i.e., they are changed to read-only.
It seems YANG has a requirement that if a leaf key is config false, then
its container list must also be config false. Otherwise, the parser will
not pass.
Therefore, key "port-number" in both list port-ds-list and list
transparent-clock-port-ds-list remain writable.

2. As noted in the mailing list, leaf member "clock-identity" is removed
from transparent-clock-port-ds-list (since portIdentity.clockIdentity is
already provided as the clock-identity leaf in
transparent-clock-default-ds).

3.The last paragraph of Section 2.2 is updated to: "Under certain
circumstances, the classification of an IEEE 1588 data set member may
change for a YANG implementation, for example, a configurable member
needs to be changed to read-only. In such a 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]." We hope the new texts make it clear how an
implementer may change the behavior of YANG attributes in practice.

4. we added references to [IEEE1588] for terms BC, OC and TC as
commented by Dave.

5. RFC7950 is added as a normative reference; since two RFC references
are obsoleted, we updated them with their newest version (i.e., RFC 8341
and RFC 8343).

6. we add editorial improvements as our reviewers proposed, and use
RFC2119 key words in several sentences in Section 1 and Section 2.2.

In fact, the main technical changes were already presented in the last
IETF meeting, the new changes are mostly editorial.
Thanks a lot to our reviewers! Further reviews and opinions will be
appreciated.

Thanks,

-----Original Message-----
From: TICTOC [mailto:[email-masked]] On Behalf Of
[email-masked]
Sent: Monday, July 02, 2018 10:52 AM
To: [email-masked]
Cc: [email-masked]
Subject: [TICTOC] I-D Action: draft-ietf-tictoc-1588v2-yang-08.txt

A New Internet-Draft is available from the on-line Internet-Drafts
directories.
This draft is a work item of the Timing over IP Connection and Transfer
of Clock WG of the IETF.

Abstract:

Please note that it may take a couple of minutes from the time of
submission until the htmlized version and diff are available at
tools.ietf.org.

---

From: Jiangyuanlong <[email-masked]>
Date: Tue, 3 Jul 2018 06:50:29 +0000

Dear Tom,

Many thanks to your thorough review and thoughtful comments.
We will update the draft accordingly.

Cheers,
Yuanlong 

-----Original Message-----
From: t.petch [mailto:[email-masked]] 
Sent: Monday, July 02, 2018 11:40 PM
To: Jiangyuanlong <[email-masked]>; [email-masked]
Cc: [email-masked]; Dave Thaler <[email-masked]>; ZHAO, WILLIAM <[email-masked]>
Subject: Re: [TICTOC] I-D Action: draft-ietf-tictoc-1588v2-yang-08.txt

It's been a while and YANG moves on:-(  I think that you need some changes to the YANG module for which draft-ietf-netmod-rfc6087bis is your friend while other issues have surfaced as IESG comments at IESG Review

You have lower case 'may' and there is now  revised boiler plate to cater for this in RFC8174

YANG Tree diagrams is now RFC8340 and the expectation is that you have an Informative Reference to that and include no further explanation in the I-D

The RFC Editor would appreciate a Note asking them to update the two dates in the YANG module to date of publication

     import ietf-interfaces
lacks a reference to the RFC.  If this is 8343, which is YANG 1.1, then this module must specify YANG 1.1 as version number.

The YANG module needs a Copyright which will include a reference to XXXX, the number assigned to the I-D on publication.  The RFC Editor would appreciate a Note asking them to replace all occurrences of XXXX with the published number (the RFC Editor told me that they like this Note at the start of the ID as opposed to tucked away on each occurrence).

contact

Security Considerations needs to identify which objects are sensitive or say that none are.

The RFC listed in Security Considerations need to be Normative; there is a wiki section this.

IANA Considerations lacks detail, such as the RFC XXXX, Registrant Contact etc

Tom Petch

----- Original Message -----
From: "Jiangyuanlong" <[email-masked]>
Sent: Monday, July 02, 2018 4:50 AM

Hi experts,

1. According to IEEE 1588 and per the discussions in the mailing list, we changed two attribute members to "config false" in the YANG module (default-ds. clock-identity and transparent-clock-default-ds.

Thanks,

-----Original Message-----
From: TICTOC [mailto:[email-masked]] On Behalf Of [email-masked]
Sent: Monday, July 02, 2018 10:52 AM
To: [email-masked]
Cc: [email-masked]
Subject: [TICTOC] I-D Action: draft-ietf-tictoc-1588v2-yang-08.txt

Abstract:

---

From: "t.petch" <[email-masked]>
Date: Tue, 3 Jul 2018 10:11:17 +0100

Here are some more thoughts from looking at the body of YANG module
(some may reflect the fact that I have not accessed IEEE Std
1588-2008:-)

I see now that you say in s.3 you import the YANG 1.1 version of
ietf-interfaces, RFC8343, which means that this module must be
     yang-version 1.1;
In which case, I think that your references to RFC6020 in the body of
the document should be to RFC7950

You have lots of references - good - but do not use the YANG reference
statement - I think this ok, if not the usual practice.

You have no examples, which sometimes get asked for by such as the IESG,
YANG doctor and such like - they are nice to see if tedious and error
prone to create.

           leaf grandmaster-identity {  type binary {  length "8";
why binary and not type clock-identity-type?
In passing I am curious about the choice of binary length 8 as opposed
to uint8; not wrong, just something that strikes me.

           leaf current-utc-offset {
what are the units?
should there be a default or should there be something to indicate an
invalid value i.e. can
leaf current-utc-offset-valid {
get set to true before there is a valid value in the offset in which
case a value of e.g. infinity would alert the user to this condition.
.
           leaf time-source {  type uint8; description
               "The source of time used by the grandmaster clock.";
How does a uint8 tell me the source?  What namespace is this uint8 in?

I see that there are no notifications; might events such as
...occurrence of the event ANNOUNCE_RECEIPT_TIMEOUT_
EXPIRES.";
ever generate notifications?

primary syntonization domain
I cannot find 'syntonization'in my dictionary

I wonder about
'when set'
which appears in many places; I infer this is when set to true, which I
would spell out (although others take this for granted).

Tom Petch

----- Original Message -----
From: "Jiangyuanlong" <[email-masked]>
To: "t.petch" <[email-masked]>; <[email-masked]>
Cc: <[email-masked]>; "Dave Thaler" <[email-masked]>;
"ZHAO, WILLIAM" <[email-masked]>
Sent: Tuesday, July 03, 2018 7:50 AM

Dear Tom,

Cheers,
Yuanlong

-----Original Message-----
From: t.petch [mailto:[email-masked]]
Sent: Monday, July 02, 2018 11:40 PM
To: Jiangyuanlong <[email-masked]>; [email-masked]
Cc: [email-masked]; Dave Thaler <[email-masked]>; ZHAO,
WILLIAM <[email-masked]>
Subject: Re: [TICTOC] I-D Action: draft-ietf-tictoc-1588v2-yang-08.txt

     import ietf-interfaces

contact

Tom Petch

----- Original Message -----
From: "Jiangyuanlong" <[email-masked]>
Sent: Monday, July 02, 2018 4:50 AM

Hi experts,

Thanks,

-----Original Message-----

Abstract:

---

From: Jiangyuanlong <[email-masked]>
Date: Thu, 5 Jul 2018 08:30:33 +0000

Tom, 

Please see my comments inline with [YJ].

Thanks again,
Yuanlong

-----Original Message-----
From: t.petch [mailto:[email-masked]] 
Sent: Tuesday, July 03, 2018 5:11 PM
To: Jiangyuanlong <[email-masked]>; [email-masked]
Cc: [email-masked]; Dave Thaler <[email-masked]>; ZHAO, WILLIAM <[email-masked]>
Subject: Re: [TICTOC] I-D Action: draft-ietf-tictoc-1588v2-yang-08.txt

Here are some more thoughts from looking at the body of YANG module (some may reflect the fact that I have not accessed IEEE Std
1588-2008:-)

I see now that you say in s.3 you import the YANG 1.1 version of ietf-interfaces, RFC8343, which means that this module must be
     yang-version 1.1;
In which case, I think that your references to RFC6020 in the body of the document should be to RFC7950

[YJ] We will consider changing several references to RFC7950. Both references are included already, and I must say most materials used in this document are accommodated by both RFC 6020 and 7950.

You have lots of references - good - but do not use the YANG reference statement - I think this ok, if not the usual practice.

[YJ] This module only imports ietf-interfaces, and we will add a reference sentence for it in the next version

You have no examples, which sometimes get asked for by such as the IESG, YANG doctor and such like - they are nice to see if tedious and error prone to create.

[YJ] there is an example on how to augment this module in an ONF PoC project:
https://github.com/OpenNetworkingFoundation/CENTENNIAL/tree/master/models/yang/onf-ptp-dataset.yang, 
Of course, we can add one or two appendix into the document if requested.

           leaf grandmaster-identity {  type binary {  length "8"; why binary and not type clock-identity-type?
In passing I am curious about the choice of binary length 8 as opposed to uint8; not wrong, just something that strikes me.
[YJ] binary length 8 is actually Octet[8] in IEEE 1588, not uint8. Yes, it is also of type clock-identity-type, will change it.

[YJ] in seconds. 

should there be a default or should there be something to indicate an invalid value i.e. can leaf current-utc-offset-valid { get set to true before there is a valid value in the offset in which case a value of e.g. infinity would alert the user to this condition.

[YJ] not in the original IEEE 1588-2008, according to 1588-2008, its initialization is complicated and dependent on primary reference or the time when the node is designed: 
"The initialization value shall be selected as follows:
a) If the timePropertiesDS.ptpTimescale (see 8.2.4.8) is TRUE, the value is the value obtained from a
primary reference if the value is known at the time of initialization, else.
b) The value shall be the current number of leap seconds (7.2.3) when the node is designed."
Thus, if leaf current-utc-offset-valid is set to TRUE, then leaf current-utc-offset must be set accordingly by PTP protocols or manually.

.
           leaf time-source {  type uint8; description
               "The source of time used by the grandmaster clock."; How does a uint8 tell me the source?  What namespace is this uint8 in?

[YJ] the value represents a category of time source enumeration, such ATOMIC_CLOCK, GPS and etc. See Table 7 of IEEE1588 for details.

I see that there are no notifications; might events such as ...occurrence of the event ANNOUNCE_RECEIPT_TIMEOUT_ EXPIRES."; ever generate notifications?

[YJ] interestingly, service providers have shown little interest in event notifications during the development of this draft (perhaps because events are mostly transient). 
BTW, some of the events are implementation specific, or dependent on the BMCA used. Thus, event notification is out of our radar.

[YJ] syntonization is defined in Section 12.1. My understanding is, a TC may have multiple frequency sources (clocks), and it needs to syntonize to the primary clock (i.e., the grandmaster).
Section 10.1 of IEEE1588: "For clocks implementing syntonization, the term "primary syntonization domain" is defined to be
domainNumber 0, or if the default is configured to a new domain, the configured default domain."

I wonder about
'when set'
which appears in many places; I infer this is when set to true, which I would spell out (although others take this for granted).

[YJ] OK.

Tom Petch

----- Original Message -----
From: "Jiangyuanlong" <[email-masked]>
To: "t.petch" <[email-masked]>; <[email-masked]>
Cc: <[email-masked]>; "Dave Thaler" <[email-masked]>; "ZHAO, WILLIAM" <[email-masked]>
Sent: Tuesday, July 03, 2018 7:50 AM

Dear Tom,

Cheers,
Yuanlong

-----Original Message-----
From: t.petch [mailto:[email-masked]]
Sent: Monday, July 02, 2018 11:40 PM
To: Jiangyuanlong <[email-masked]>; [email-masked]
Cc: [email-masked]; Dave Thaler <[email-masked]>; ZHAO, WILLIAM <[email-masked]>
Subject: Re: [TICTOC] I-D Action: draft-ietf-tictoc-1588v2-yang-08.txt

     import ietf-interfaces

contact

Tom Petch

----- Original Message -----
From: "Jiangyuanlong" <[email-masked]>
Sent: Monday, July 02, 2018 4:50 AM

Hi experts,

Thanks,

-----Original Message-----
From: TICTOC [mailto:[email-masked]] On Behalf Of [email-masked]
Sent: Monday, July 02, 2018 10:52 AM
To: [email-masked]
Cc: [email-masked]
Subject: [TICTOC] I-D Action: draft-ietf-tictoc-1588v2-yang-08.txt

Abstract:

---

From: "t.petch" <[email-masked]>
Date: Fri, 6 Jul 2018 12:41:59 +0100

Thank you for the erudition.

Top posting to pick up on the points remaining at my end.

My point about YANG 1.1 is that YANG rules require any module importing
a YANG 1.1 module (which you do) to itself  be YANG 1.1 so specifying
     yang-version 1.1;
is required.  It is good to make everything possible YANG 1.0 but unless
you import the older version of
ietf-interfaces
which would likely raise more complications,  I see
     yang-version 1.1;
in this module as unavoidable

My mention of uint8 was an aberration - I had in mind a character string
or a long integer.  This is an area where different languages take
different views and translation can be problematic.
YANG binary allows any bit configuration and is displayed as base64
YANG string limits the possible bit configurations to certain
'characters'
I don't know which is better here.

           leaf current-utc-offset {
YANG has constraints!  I think this would be better with a
 when
so that the object only appears when
           leaf current-utc-offset-valid {
is set to true.

syntonization
I think worth defining or referencing, perhaps a reference to IEEE1588
in the description clauses where it appears (my preference); or add it
to s.1.2

Generally, whereever you have a time, and the type is an integer as
opposed to a derived type, I think that you need units; I think that
           leaf current-utc-offset {
is the only such case here.

Tom Petch

----- Original Message -----
From: "Jiangyuanlong" <[email-masked]>
To: "t.petch" <[email-masked]>; <[email-masked]>
Cc: <[email-masked]>; "Dave Thaler" <[email-masked]>;
"ZHAO, WILLIAM" <[email-masked]>
Sent: Thursday, July 05, 2018 9:30 AM

Tom,

Thanks again,
Yuanlong

-----Original Message-----
From: t.petch [mailto:[email-masked]]
Sent: Tuesday, July 03, 2018 5:11 PM
To: Jiangyuanlong <[email-masked]>; [email-masked]
Cc: [email-masked]; Dave Thaler <[email-masked]>; ZHAO,

[YJ] We will consider changing several references to RFC7950. Both
references are included already, and I must say most materials used in
this document are accommodated by both RFC 6020 and 7950.

[YJ] This module only imports ietf-interfaces, and we will add a
reference sentence for it in the next version

[YJ] there is an example on how to augment this module in an ONF PoC
project:
https://github.com/OpenNetworkingFoundation/CENTENNIAL/tree/master/model
s/yang/onf-ptp-dataset.yang,
Of course, we can add one or two appendix into the document if
requested.

           leaf grandmaster-identity {  type binary {  length "8"; why
binary and not type clock-identity-type?
In passing I am curious about the choice of binary length 8 as opposed
to uint8; not wrong, just something that strikes me.
[YJ] binary length 8 is actually Octet[8] in IEEE 1588, not uint8. Yes,
it is also of type clock-identity-type, will change it.

[YJ] in seconds.

should there be a default or should there be something to indicate an
invalid value i.e. can leaf current-utc-offset-valid { get set to true
before there is a valid value in the offset in which case a value of
e.g. infinity would alert the user to this condition.

[YJ] not in the original IEEE 1588-2008, according to 1588-2008, its
initialization is complicated and dependent on primary reference or the
time when the node is designed:
"The initialization value shall be selected as follows:
a) If the timePropertiesDS.ptpTimescale (see 8.2.4.8) is TRUE, the value
is the value obtained from a
primary reference if the value is known at the time of initialization,
else.
b) The value shall be the current number of leap seconds (7.2.3) when
the node is designed."
Thus, if leaf current-utc-offset-valid is set to TRUE, then leaf
current-utc-offset must be set accordingly by PTP protocols or manually.

.
           leaf time-source {  type uint8; description
               "The source of time used by the grandmaster clock."; How
does a uint8 tell me the source?  What namespace is this uint8 in?

[YJ] the value represents a category of time source enumeration, such
ATOMIC_CLOCK, GPS and etc. See Table 7 of IEEE1588 for details.

I see that there are no notifications; might events such as
...occurrence of the event ANNOUNCE_RECEIPT_TIMEOUT_ EXPIRES."; ever
generate notifications?

[YJ] interestingly, service providers have shown little interest in
event notifications during the development of this draft (perhaps
because events are mostly transient).
BTW, some of the events are implementation specific, or dependent on the
BMCA used. Thus, event notification is out of our radar.

[YJ] syntonization is defined in Section 12.1. My understanding is, a TC
may have multiple frequency sources (clocks), and it needs to syntonize
to the primary clock (i.e., the grandmaster).
Section 10.1 of IEEE1588: "For clocks implementing syntonization, the
term "primary syntonization domain" is defined to be
domainNumber 0, or if the default is configured to a new domain, the
configured default domain."

I wonder about
'when set'

[YJ] OK.

Tom Petch

----- Original Message -----
From: "Jiangyuanlong" <[email-masked]>
To: "t.petch" <[email-masked]>; <[email-masked]>
Cc: <[email-masked]>; "Dave Thaler" <[email-masked]>;

Dear Tom,

Cheers,
Yuanlong

-----Original Message-----
From: t.petch [mailto:[email-masked]]
Sent: Monday, July 02, 2018 11:40 PM
To: Jiangyuanlong <[email-masked]>; [email-masked]
Cc: [email-masked]; Dave Thaler <[email-masked]>; ZHAO,

     import ietf-interfaces

contact

Tom Petch

----- Original Message -----
From: "Jiangyuanlong" <[email-masked]>
Sent: Monday, July 02, 2018 4:50 AM

Hi experts,

Thanks,

-----Original Message-----

Abstract:

---

From: Jiangyuanlong <[email-masked]>
Date: Fri, 6 Jul 2018 15:22:20 +0000

Dear Tom,
Thanks for your considerate comments.
Please see my replies in the line.

BR,
Yuanlong
> in this module as unavoidable
[YJ] Yes, the version in preparation already added this line.

>            leaf current-utc-offset-valid {
[YJ] I agree this may be a better option, we will consider it. The original 1588 information model is more rigid in its structure.  

> in the description clauses where it appears (my preference); or add it
[YJ] it is a tradeoff in the document, usually we only refer to the exact subsection of IEEE 1588 for each YANG container or list, but not for each attribute member.
IEEE 1588 already provides a well structured information model for these data sets (container or list in YANG), if a reader looks up the specific section for a container or list, he will easily get all information on each of its attribute member. However, we will add a reference for this term as it is an unusual one.

> is the only such case here.
[YJ] The version in preparation already addressed this.

---

From: "t.petch" <[email-masked]>
Date: Sat, 7 Jul 2018 12:10:35 +0100

Fine with me

Tom Petch

----- Original Message -----
From: "Jiangyuanlong" <[email-masked]>
Sent: Friday, July 06, 2018 4:22 PM

Dear Tom,

BR,
Yuanlong

>            leaf current-utc-offset-valid {
[YJ] I agree this may be a better option, we will consider it. The
original 1588 information model is more rigid in its structure.

> in the description clauses where it appears (my preference); or add it
[YJ] it is a tradeoff in the document, usually we only refer to the
exact subsection of IEEE 1588 for each YANG container or list, but not
for each attribute member.
IEEE 1588 already provides a well structured information model for these
data sets (container or list in YANG), if a reader looks up the specific
section for a container or list, he will easily get all information on
each of its attribute member. However, we will add a reference for this
term as it is an unusual one.

> (some may reflect the fact that I have not accessed IEEE Std
How