Subject: [TICTOC] WGLC for draft-ietf-tictoc-1588v2-yang

From: Karen O'Donoghue <[email-masked]>
Date: Wed, 13 Sep 2017 19:16:02 +0000

Folks,

This message begins a 2 week working group last call (WGLC) for the following document: 

YANG Data Model for IEEE 1588v2
https://datatracker.ietf.org/doc/draft-ietf-tictoc-1588v2-yang/

Please review the referenced document and send any comments to the mailing list including your assessment of whether this document is mature enough to proceed to the IESG. Please note that these messages of support for progression to the mailing list are important and will be used to determine WG consensus to proceed. 

Please send all comments in by Thursday 28 September 2017.  

Thank you!
Karen

---

From: Tal Mizrahi <[email-masked]>
Date: Mon, 18 Sep 2017 09:58:44 +0300

Hi,

I believe this draft is almost ready to proceed to the IESG.

Other than the YANG format issues that have already mentioned on the list,
I believe the Security Considerations section should be slightly extended.
- "Some data nodes defined in this YANG module are writable, and any
changes to them may adversely impact a synchronization network."
  Please elaborate about the consequences, i.e., what is the impact on the
network (Clock inaccuracy? Loss of synchronization? Other consequences?).
- The section should probably mention that the security considerations of
time protocols in general are discussed in [RFC 7384].

Cheers,
Tal.

On Wed, Sep 13, 2017 at 10:16 PM, Karen O'Donoghue <[email-masked]>
wrote:

> Please review the referenced document and send any comments to the mailing
> list including your assessment of whether this document is mature enough to
> proceed to the IESG. Please note that these messages of support for
> progression to the mailing list are important and will be used to determine
> WG consensus to proceed.
>
> _______________________________________________
> TICTOC mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/tictoc
>

---

From: John Fletcher <[email-masked]>
Date: Mon, 18 Sep 2017 16:30:22 +0000

Some comments:

There are configurable attributes beyond those listed.  For example: attributes for the optional features of 1588-2008 clauses 16 and 17; the sample period for variance estimation (clause 7.6.3.2) etc.  These should be included.

I find it confusing that the hierarchy shown in section 2 has every node as "rw" even though many are not configurable.  Later, in section 2.2, there is some explanation of this but I think a further note is needed before the hierarchy diagram.

Section 2.1 says that "1588-2008 transparent clocks are domain independent" but I don't think that is correct; transparent clocks have a "primary syntonization domain".

instance-number description makes it sound like there is one PTP dataset for each domain but I think the intention is one set of PTP datasets, the set comprising default-ds, current-ds, parent-ds etc.  However, I don't see any reason to tie instances to domains.  Instances seem to be equivalent to clocks (one clock per instance).  A device can contain mulitple clocks and there is no requirement that all clocks in a device are in different domains.

I think it would help to have a definition of PTP Instance.  A draft of 1588-rev said: "A PTP Instance is one of the following: an Ordinary Clock, a Boundary Clock, or a Transparent Clock".  The yang model here seems to be assuming that a Transparent Clock is not an instance.  It would be confusing to use a different definition of Instance than the one in 1588-rev.  An alternative would be to stick with the terminology of 1588-2008.

number-ports description says "number of PTP ports on the device".  We probably need a definition of "device" here.  You might think that because default-ds is part of an instance, the members refer to the instance (e.g. as clock-identity does).  However, in the case of number-ports, it refers to the device, where a device is the root scope for this model and can contain more than one instance.  Perhaps a root level node for nunber-ports with default-ds/number-ports being a  link to that would help.

Should there be a separate list of port-ds for each instance (as shown) or should there be one list for the device?  Given that port-identity includes clock-identity, it would seem the intention is one list per device.

Regards,
John Fletcher
________________________________________
From: TICTOC [[email-masked]] on behalf of Karen O'Donoghue [[email-masked]]
Sent: 13 September 2017 20:16
To: [email-masked]
Cc: [email-masked]
Subject: [TICTOC] WGLC for draft-ietf-tictoc-1588v2-yang

Folks,

Thank you!
Karen

---

From: Rodney Cummings <[email-masked]>
Date: Mon, 18 Sep 2017 19:08:44 +0000

Great comments John... thanks.

I'll offer some opinion below.

As an introduction of sorts, although this YANG is limited to the published 
IEEE Std 1588-2008, some of the concepts from the ongoing 1588 revision
are having a subtle effect. The reason is simple: When a YANG module is created
for the 1588 revision (likely 1588-2018), ideally it can be done as a revision 
of this 1588-2008 YANG module, such that the YANG revision complies fully 
with RFC 7950 section 11. There's no guarantee that this will be possible, 
but so far it seems feasible by keeping the fundamental hierarchy 
consistent with 1588-rev, while continuing to limit its nodes to 1588-2008.

> There are configurable attributes beyond those listed.  For example:
> attributes for the optional features of 1588-2008 clauses 16 and 17; the
> sample period for variance estimation (clause 7.6.3.2) etc.  These should
> be included.

1588-2008 didn't have a clear definition of "configurable by management" beyond
the 1588-based messages of 1588-2008 clause 15. There are plans to clarify
that topic in 1588-rev by recommending that the 1588 data sets serve as an
information model for management. That already has precedent for 1588-2008
(e.g. RFC8173 and this YANG I-D), so it seems like a safe recommendation as
we move forward.

That being said, you're correct that 1588-2008 specifies data sets for the
optional features in clause 16 and 17. Nevertheless, in 1588-2008 those
data sets are somewhat "disconnected" relative to the other data sets
(i.e. overall management hierarchy). We're clarifying that topic in
1588-rev, so my slight preference would be to defer management of these
features to the creation of a 1588-rev YANG revision. Nevertheless, one
of the goals of this 1588-2008 YANG is to serve shorter-term needs, so
if you have a specific optional feature that you need to manage in
current 1588-2008 products, maybe we should add that to this I-D.

As for the period for variance estimation in 7.6.3.2, that has no data set
member in 1588-2008. I seem to recall discussion in the 1588 working group
of making that period manageable (i.e. a data set member), but that was
rejected, and thus far the draft of 7.6.3.2 hasn't changed from 1588-2008.
If you feel strongly that this period should be manageable, I'd recommend
that you submit a comment for the 1588 revision. If you are an IEEE-SA member,
you can do that during sponsor ballot (probably 1Q2018). If not, feel free to
write something up and I'd be happy to submit it for you.

> I find it confusing that the hierarchy shown in section 2 has every node
> as "rw" even though many are not configurable.  Later, in section 2.2,
> there is some explanation of this but I think a further note is needed
> before the hierarchy diagram.

Sounds good.

> Section 2.1 says that "1588-2008 transparent clocks are domain
> independent" but I don't think that is correct; transparent clocks have a
> "primary syntonization domain".

Correct. For the next draft, we can remove the "domain independent" language.
That came from the NOTE in 1588-2008 subclause 8.3.1, and the concept isn't
needed in this context.

> instance-number description makes it sound like there is one PTP dataset
> for each domain but I think the intention is one set of PTP datasets, the
> set comprising default-ds, current-ds, parent-ds etc.  However, I don't
> see any reason to tie instances to domains.  Instances seem to be
> equivalent to clocks (one clock per instance).  A device can contain
> mulitple clocks and there is no requirement that all clocks in a device
> are in different domains.

Correct. 

1588-2008 implied this "instance" concept, and 1588-rev makes it explicit.
The intention is exactly as you describe. It is simply an instance of the
PTP standard's specifications. Two instances might use different 
domainNumber, or the same domainNumber (e.g. two disjoint physical networks).
I'll work with my co-authors to clarify this in the text.

> I think it would help to have a definition of PTP Instance.  A draft of
> 1588-rev said: "A PTP Instance is one of the following: an Ordinary Clock,
> a Boundary Clock, or a Transparent Clock".  The yang model here seems to
> be assuming that a Transparent Clock is not an instance.  It would be
> confusing to use a different definition of Instance than the one in 1588-
> rev.  An alternative would be to stick with the terminology of 1588-2008.

Correct. I'll work with my co-authors to clarify this in the text.

You found the issue that makes this tricky... transparent clock.

As the 1588 group worked through the 1588 revision, the group decided to 
clarify that each "PTP Instance" (i.e. the explicit instance concept) 
operates on one-and-only-one domain. That's fine for ordinary clock and 
boundary clock, but it was controversial for transparent clock due to 
the preceding "domain independent" concept. Some transparent clock 
implementations operate on all domains, in that the timestamp in the
message is changed regardless of what the domainNumber field contains.
Some other transparent clock implementations operate like a "PTP Instance",
in that they only change the message when the domainNumber field matches
the domainNumber in the transparent clock's data sets. The intent of
1588-2008 was the "instance" way, but it wasn't clear, and now there 
are products in the field today that implement it both ways. If you take
a look at the latest 1588-rev draft, you'll see the current consensus,
which is to a) keep the original transparent clock data sets outside of
the instance, to allow for domain-independent, but recommend against that
implementation in the future, b) add more explicit specs for a transparent
clock to be implemented using the instance data sets.

I agree that the current hierarchy can be confusing (i.e. transparent
clock outside of instance). Nevertheless, it seems to me that 1588-2008
itself is the source of that confusion, in that its transparent clock
specs have been interpreted in contradictory ways. Since this YANG is
for 1588-2008 only, I'd prefer to leave it somewhat open to interpretation
according to 1588-2008 text, rather than bring up the changes coming in
1588-rev. I'd appreciate your thoughts on it.

> number-ports description says "number of PTP ports on the device".  We
> probably need a definition of "device" here.  You might think that because
> default-ds is part of an instance, the members refer to the instance (e.g.
> as clock-identity does).  However, in the case of number-ports, it refers
> to the device, where a device is the root scope for this model and can
> contain more than one instance.  Perhaps a root level node for nunber-
> ports with default-ds/number-ports being a  link to that would help.

The 1588-rev draft currently specifies numberPorts as:
"The attribute, numberPorts, shall indicate the number of PTP Ports 
on the PTP Instance."
and PTP Port is currently defined as:
"A logical access point of a PTP Instance for PTP Communications to the 
communications network."
In other words, 1588's port is a logical entity that serves as the reference
point for the 1588 instance. The 1588 standard tries to keep abstracted from
"physical" ports (interfaces) as much as possible. In the YANG context, 1588 assumes
that ietf-interface provides the list of physical ports (interfaces) in the
product. The "underlying-interface" reference is intended to mean "Here's a 
reference to the physical interface used by this logical PTP port."

I'd recommend that we change the number-ports description to
"number of PTP ports on the instance".

> Should there be a separate list of port-ds for each instance (as shown) or
> should there be one list for the device?  Given that port-identity
> includes clock-identity, it would seem the intention is one list per
> device.

See above. The device's list is ietf-interfaces.

> John Fletcher

Thanks again John.

---

From: Jiangyuanlong <[email-masked]>
Date: Tue, 19 Sep 2017 01:23:41 +0000

Tal,

   Good suggestions! Based on your comments, I would propose the following texts for the 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 [RFC6536] can further
   improve its security, avoid injection attacks and misuse of the
   protocol. Furthermore, general security considerations of time
   protocols are discussed in [RFC7384].

   Some 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.”

  Are you OK with the above texts?

Thanks a lot,
Yuanlong

From: ntp [mailto:[email-masked]] On Behalf Of Tal Mizrahi
Sent: Monday, September 18, 2017 2:59 PM
To: Karen O'Donoghue
Cc: [email-masked]; [email-masked]
Subject: Re: [Ntp] [TICTOC] WGLC for draft-ietf-tictoc-1588v2-yang

Hi,

Other than the YANG format issues that have already mentioned on the list, I believe the Security Considerations section should be slightly extended.
- "Some data nodes defined in this YANG module are writable, and any changes to them may adversely impact a synchronization network."
  Please elaborate about the consequences, i.e., what is the impact on the network (Clock inaccuracy? Loss of synchronization? Other consequences?).
- The section should probably mention that the security considerations of time protocols in general are discussed in [RFC 7384].

Cheers,
Tal.

On Wed, Sep 13, 2017 at 10:16 PM, Karen O'Donoghue <[email-masked]<mailto:[email-masked]>> wrote:
Folks,

Thank you!
Karen
_______________________________________________
TICTOC mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/tictoc

---

From: John Fletcher <[email-masked]>
Date: Tue, 19 Sep 2017 17:16:01 +0000

Responses inline below prefixed [JF]
________________________________________
From: Rodney Cummings [[email-masked]]
Sent: 18 September 2017 20:08
To: John Fletcher; [email-masked]
Subject: RE: WGLC for draft-ietf-tictoc-1588v2-yang

[JF] Examples would be: Unicast negotiation enable, Unicast master table, Acceptable master table.

[JF] 1588-2008 says the sample period shall be the value defined in the applicable PTP profile, which implies that if you want to configure a device according to a profile, you need to manage that value.  I'm not aware of any profiles that define a different value from the default profile, though, so not a big deal.

Sounds good.

Correct.

[JF] After some reading of 1588-2008 and 1588-rev, I agree the current structure is the best choice.  In 1588-2008, it's clear that Transparent Clocks can (should) operate in multiple domains and that a Transparent Clock operating in multiple domains is regarded as a single Transparent Clock with single data sets.  In 1588-rev, this is allowed but deprecated and the preference is "The PTP Node can provide one or more Transparent Clocks (each with an entry in instanceList), and each Transparent Clock supports a single PTP Instance and domain".  In this case, the Transparent Clock uses the same data sets as an Ordinary Clock or Boundary Clock.

[JF] Yes, for defaultDS that seems the best route for compatibility with 1588-rev but for transparentClockDefaultDS it needs to be "number of PTP ports on the device" or maybe "number of PTP ports on the PTP Node".

[JF] I think we need to define what the top level of the hierarchy corresponds to.  I think it would be a "PTP Node" in 1588-rev terminology.  In 1588-2008, a "PTP Node" seems to be a single Clock but 1588-2008 doesn't really allow for multiple "instances" in the same device.

[JF] Addional comment: the title should not refer to 1588v2 but to 1588-2008.  The version will still be 2 in 1588-rev.

> John Fletcher

Thanks again John.
[JF} Thanks for good discussion.

-----------------------------
http://www.bbc.co.uk
This e-mail (and any attachments) is confidential and
may contain personal views which are not the views of the BBC unless specifically stated.
If you have received it in
error, please delete it from your system.
Do not use, copy or disclose the
information in any way nor act in reliance on it and notify the sender
immediately.
Please note that the BBC monitors e-mails
sent or received.
Further communication will signify your consent to
this.
-----------------------------

---

From: Rodney Cummings <[email-masked]>
Date: Wed, 20 Sep 2017 16:18:13 +0000

Thanks John,

Minor follow-up marked as [RC] below.

-
(discussion of number-ports description)

[RC] 1588-2008 wasn't very clear on the node concept. For transparentClockDefaultDS I'd propose "number of PTP ports on the Transparent Clock". That way... however you interpret the 1588-2008 Transparent Clock (node or instance), it works for you.
-

I agree. 1588-rev will be v2.1, which is also "v2", so use of 1588-2008 avoids confusion.

Thanks again,
Rodney

> -----Original Message-----
> From: John Fletcher [mailto:[email-masked]]
> Sent: Tuesday, September 19, 2017 12:16 PM
> To: Rodney Cummings <[email-masked]>; [email-masked]
> [JF] 1588-2008 says the sample period shall be the value defined in the
> applicable PTP profile, which implies that if you want to configure a
> device according to a profile, you need to manage that value.  I'm not
> aware of any profiles that define a different value from the default
> profile, though, so not a big deal.
> 
> [JF] After some reading of 1588-2008 and 1588-rev, I agree the current
> structure is the best choice.  In 1588-2008, it's clear that Transparent
> Clocks can (should) operate in multiple domains and that a Transparent
> Clock operating in multiple domains is regarded as a single Transparent
> Clock with single data sets.  In 1588-rev, this is allowed but deprecated
> and the preference is "The PTP Node can provide one or more Transparent
> Clocks (each with an entry in instanceList), and each Transparent Clock
> supports a single PTP Instance and domain".  In this case, the Transparent
> Clock uses the same data sets as an Ordinary Clock or Boundary Clock.
> 
> [JF] Yes, for defaultDS that seems the best route for compatibility with
> 1588-rev but for transparentClockDefaultDS it needs to be "number of PTP
> ports on the device" or maybe "number of PTP ports on the PTP Node".
> 
> [JF] I think we need to define what the top level of the hierarchy
> corresponds to.  I think it would be a "PTP Node" in 1588-rev terminology.
> In 1588-2008, a "PTP Node" seems to be a single Clock but 1588-2008
> doesn't really allow for multiple "instances" in the same device.
> 
> [JF] Addional comment: the title should not refer to 1588v2 but to 1588-
> 2008.  The version will still be 2 in 1588-rev.
> 
> > Regards,
> > John Fletcher
> 
> Thanks again John.
> https://urldefense.proofpoint.com/v2/url?u=http-
> 3A__www.bbc.co.uk&d=DwIFAg&c=I_0YwoKy7z5LMTVdyO6YCiE2uzI1jjZZuIPelcSjixA&r
> =WA71sf2o7Dw7CbYhFt24DPjt3lJuupswWYdnboKbZ8k&m=ejTjT1jEhX-
> SngMVPjCm1bVRjYLDvvLDU4kpv7c50iY&s=77y1dSLM4cG9ThdZKO8Jxd_UXzZ56up41DfuLxm
> Zpcg&e=

---

From: Jiangyuanlong <[email-masked]>
Date: Sat, 23 Sep 2017 01:46:52 +0000

Hi John and Rodney,

Regarding "optional features", I would like to chime in: 
As we envisioned, this module should be the basic 1588 YANG model, and transport profile, bridge profile and router profile modules can import this module and add their new optional features respectively.
However, it says in A.9 of G.8275.1 (2016):" Other optional features of [IEEE 1588] are not used in this version of the profile. These include unicast message negotiation...". thus, it is clear that ITU-T PTP profile don't need to support these optional features.
Therefore, we'd better exclude unnecessary optional features and make sure the module only include the most fundamental features.

B.R.,
Yuanlong

-----Original Message-----
From: TICTOC [mailto:[email-masked]] On Behalf Of John Fletcher
Sent: Wednesday, September 20, 2017 1:16 AM
To: Rodney Cummings; [email-masked]
Subject: Re: [TICTOC] WGLC for draft-ietf-tictoc-1588v2-yang

As an introduction of sorts, although this YANG is limited to the published IEEE Std 1588-2008, some of the concepts from the ongoing 1588 revision are having a subtle effect. The reason is simple: When a YANG module is created for the 1588 revision (likely 1588-2018), ideally it can be done as a revision of this 1588-2008 YANG module, such that the YANG revision complies fully with RFC 7950 section 11. There's no guarantee that this will be possible, but so far it seems feasible by keeping the fundamental hierarchy consistent with 1588-rev, while continuing to limit its nodes to 1588-2008.

> attributes for the optional features of 1588-2008 clauses 16 and 17; 
> the sample period for variance estimation (clause 7.6.3.2) etc.  These 
> should be included.

1588-2008 didn't have a clear definition of "configurable by management" beyond the 1588-based messages of 1588-2008 clause 15. There are plans to clarify that topic in 1588-rev by recommending that the 1588 data sets serve as an information model for management. That already has precedent for 1588-2008 (e.g. RFC8173 and this YANG I-D), so it seems like a safe recommendation as we move forward.

That being said, you're correct that 1588-2008 specifies data sets for the optional features in clause 16 and 17. Nevertheless, in 1588-2008 those data sets are somewhat "disconnected" relative to the other data sets (i.e. overall management hierarchy). We're clarifying that topic in 1588-rev, so my slight preference would be to defer management of these features to the creation of a 1588-rev YANG revision. Nevertheless, one of the goals of this 1588-2008 YANG is to serve shorter-term needs, so if you have a specific optional feature that you need to manage in current 1588-2008 products, maybe we should add that to this I-D.

As for the period for variance estimation in 7.6.3.2, that has no data set member in 1588-2008. I seem to recall discussion in the 1588 working group of making that period manageable (i.e. a data set member), but that was rejected, and thus far the draft of 7.6.3.2 hasn't changed from 1588-2008.
If you feel strongly that this period should be manageable, I'd recommend that you submit a comment for the 1588 revision. If you are an IEEE-SA member, you can do that during sponsor ballot (probably 1Q2018). If not, feel free to write something up and I'd be happy to submit it for you.

> I find it confusing that the hierarchy shown in section 2 has every 
> node as "rw" even though many are not configurable.  Later, in section 
> 2.2, there is some explanation of this but I think a further note is 
> needed before the hierarchy diagram.

Sounds good.

> independent" but I don't think that is correct; transparent clocks 
> have a "primary syntonization domain".

Correct. For the next draft, we can remove the "domain independent" language.
That came from the NOTE in 1588-2008 subclause 8.3.1, and the concept isn't needed in this context.

> instance-number description makes it sound like there is one PTP 
> dataset for each domain but I think the intention is one set of PTP 
> datasets, the set comprising default-ds, current-ds, parent-ds etc.  
> However, I don't see any reason to tie instances to domains.  
> Instances seem to be equivalent to clocks (one clock per instance).  A 
> device can contain mulitple clocks and there is no requirement that 
> all clocks in a device are in different domains.

Correct.

1588-2008 implied this "instance" concept, and 1588-rev makes it explicit.
The intention is exactly as you describe. It is simply an instance of the PTP standard's specifications. Two instances might use different domainNumber, or the same domainNumber (e.g. two disjoint physical networks).
I'll work with my co-authors to clarify this in the text.

> I think it would help to have a definition of PTP Instance.  A draft 
> of 1588-rev said: "A PTP Instance is one of the following: an Ordinary 
> Clock, a Boundary Clock, or a Transparent Clock".  The yang model here 
> seems to be assuming that a Transparent Clock is not an instance.  It 
> would be confusing to use a different definition of Instance than the 
> one in 1588- rev.  An alternative would be to stick with the terminology of 1588-2008.

As the 1588 group worked through the 1588 revision, the group decided to clarify that each "PTP Instance" (i.e. the explicit instance concept) operates on one-and-only-one domain. That's fine for ordinary clock and boundary clock, but it was controversial for transparent clock due to the preceding "domain independent" concept. Some transparent clock implementations operate on all domains, in that the timestamp in the message is changed regardless of what the domainNumber field contains.
Some other transparent clock implementations operate like a "PTP Instance", in that they only change the message when the domainNumber field matches the domainNumber in the transparent clock's data sets. The intent of
1588-2008 was the "instance" way, but it wasn't clear, and now there are products in the field today that implement it both ways. If you take a look at the latest 1588-rev draft, you'll see the current consensus, which is to a) keep the original transparent clock data sets outside of the instance, to allow for domain-independent, but recommend against that implementation in the future, b) add more explicit specs for a transparent clock to be implemented using the instance data sets.

I agree that the current hierarchy can be confusing (i.e. transparent clock outside of instance). Nevertheless, it seems to me that 1588-2008 itself is the source of that confusion, in that its transparent clock specs have been interpreted in contradictory ways. Since this YANG is for 1588-2008 only, I'd prefer to leave it somewhat open to interpretation according to 1588-2008 text, rather than bring up the changes coming in 1588-rev. I'd appreciate your thoughts on it.

> probably need a definition of "device" here.  You might think that 
> because default-ds is part of an instance, the members refer to the instance (e.g.
> as clock-identity does).  However, in the case of number-ports, it 
> refers to the device, where a device is the root scope for this model 
> and can contain more than one instance.  Perhaps a root level node for 
> nunber- ports with default-ds/number-ports being a  link to that would help.

The 1588-rev draft currently specifies numberPorts as:
"The attribute, numberPorts, shall indicate the number of PTP Ports on the PTP Instance."
and PTP Port is currently defined as:
"A logical access point of a PTP Instance for PTP Communications to the communications network."
In other words, 1588's port is a logical entity that serves as the reference point for the 1588 instance. The 1588 standard tries to keep abstracted from "physical" ports (interfaces) as much as possible. In the YANG context, 1588 assumes that ietf-interface provides the list of physical ports (interfaces) in the product. The "underlying-interface" reference is intended to mean "Here's a reference to the physical interface used by this logical PTP port."

I'd recommend that we change the number-ports description to "number of PTP ports on the instance".

> Should there be a separate list of port-ds for each instance (as 
> shown) or should there be one list for the device?  Given that 
> port-identity includes clock-identity, it would seem the intention is 
> one list per device.

Thanks again John.

-----------------------------
http://www.bbc.co.uk
This e-mail (and any attachments) is confidential and may contain personal views which are not the views of the BBC unless specifically stated.
If you have received it in
error, please delete it from your system.
Do not use, copy or disclose the
information in any way nor act in reliance on it and notify the sender immediately.
Please note that the BBC monitors e-mails sent or received.
Further communication will signify your consent to this.
-----------------------------

---

From: Rodney Cummings <[email-masked]>
Date: Mon, 25 Sep 2017 15:56:34 +0000

Hi John and Yuanlong,

I could be wrong, but I think there is some upcoming work in ITU-T that plans to use 1588's optional unicast negotiation feature. That being said, that feature was enhanced in 1588-rev, so ITU-T may be planning to use those enhancements (not limited to 1588-2008).

Regardless of what ITU-T is planning, for optional features that exist in 1588-2008 as a data set, it is reasonable to request those features in this YANG project.

Nevertheless, my preference is to avoid those optional features in this YANG project. As Yuanlong said:
> As we envisioned, this module should be the basic 1588 YANG model
The authors of this I-D are hoping to keep this YANG focused on the core 1588 data sets only, and avoid optional features. This presumably helps us to reach RFC sooner. A profile or product that needs the optional features can create their own YANG augment for those features.

Does this mean that we will never have 1588-wide (i.e. profile-independent) YANG for the optional features?
	No... at least not in my opinion. We are simply deferring that work.

In the IEEE 1588 working group, there is tentative consensus that as soon as 1588-rev publishes (hopefully 1Q2018), the 1588 working group will create an amendment PAR for 1588-rev YANG. That 1588-rev YANG will include all data sets, including all optional features. My tentative hope is that the 1588-rev YANG will be a revision of this 1588-2008 YANG project. That is one of the reasons I was hoping to avoid optional features in this 1588-2008 YANG, because the more this 1588-2008 YANG focuses on "basic 1588" only, the more likely we can revise it in the future to support the "optional 1588" features.

John... I'd appreciate your thoughts on this.

Rodney

> From: Jiangyuanlong [mailto:[email-masked]]
> Sent: Friday, September 22, 2017 8:47 PM
> To: John Fletcher ; Rodney Cummings ; [email-masked]
> As we envisioned, this module should be the basic 1588 YANG model, and
> transport profile, bridge profile and router profile modules can import
> this module and add their new optional features respectively.
> However, it says in A.9 of G.8275.1 (2016):" Other optional features of
> [IEEE 1588] are not used in this version of the profile. These include
> unicast message negotiation...". thus, it is clear that ITU-T PTP profile
> don't need to support these optional features.
> Therefore, we'd better exclude unnecessary optional features and make sure
> the module only include the most fundamental features.
> 
> B.R.,
> Yuanlong
> 
> As an introduction of sorts, although this YANG is limited to the
> published IEEE Std 1588-2008, some of the concepts from the ongoing 1588
> revision are having a subtle effect. The reason is simple: When a YANG
> module is created for the 1588 revision (likely 1588-2018), ideally it can
> be done as a revision of this 1588-2008 YANG module, such that the YANG
> revision complies fully with RFC 7950 section 11. There's no guarantee
> that this will be possible, but so far it seems feasible by keeping the
> fundamental hierarchy consistent with 1588-rev, while continuing to limit
> its nodes to 1588-2008.
> 
> 1588-2008 didn't have a clear definition of "configurable by management"
> beyond the 1588-based messages of 1588-2008 clause 15. There are plans to
> clarify that topic in 1588-rev by recommending that the 1588 data sets
> serve as an information model for management. That already has precedent
> for 1588-2008 (e.g. RFC8173 and this YANG I-D), so it seems like a safe
> recommendation as we move forward.
> 
> (i.e. overall management hierarchy). We're clarifying that topic in 1588-
> rev, so my slight preference would be to defer management of these
> features to the creation of a 1588-rev YANG revision. Nevertheless, one of
> the goals of this 1588-2008 YANG is to serve shorter-term needs, so if you
> have a specific optional feature that you need to manage in current 1588-
> 2008 products, maybe we should add that to this I-D.
> 
> that you submit a comment for the 1588 revision. If you are an IEEE-SA
> member, you can do that during sponsor ballot (probably 1Q2018). If not,
> feel free to write something up and I'd be happy to submit it for you.
> 
> boundary clock, but it was controversial for transparent clock due to the
> preceding "domain independent" concept. Some transparent clock
> Some other transparent clock implementations operate like a "PTP
> Instance", in that they only change the message when the domainNumber
> field matches the domainNumber in the transparent clock's data sets. The
> intent of
> 1588-2008 was the "instance" way, but it wasn't clear, and now there are
> products in the field today that implement it both ways. If you take a
> look at the latest 1588-rev draft, you'll see the current consensus, which
> is to a) keep the original transparent clock data sets outside of the
> instance, to allow for domain-independent, but recommend against that
> specs have been interpreted in contradictory ways. Since this YANG is for
> 1588-2008 only, I'd prefer to leave it somewhat open to interpretation
> In other words, 1588's port is a logical entity that serves as the
> reference point for the 1588 instance. The 1588 standard tries to keep
> abstracted from "physical" ports (interfaces) as much as possible. In the
> YANG context, 1588 assumes that ietf-interface provides the list of
> physical ports (interfaces) in the product. The "underlying-interface"
> reference is intended to mean "Here's a reference to the physical
> interface used by this logical PTP port."
> 
> 3A__www.bbc.co.uk&d=DwIFgQ&c=I_0YwoKy7z5LMTVdyO6YCiE2uzI1jjZZuIPelcSjixA&r
> =WA71sf2o7Dw7CbYhFt24DPjt3lJuupswWYdnboKbZ8k&m=q08sdix-
> IT4WEtYgvpO5Vc1bUOFvO-
> iWzjpVV7ymSVM&s=n8KVe2hEurlWYuTojP8rcGy5y15wDqyrXhF24XeQGFg&e=
> This e-mail (and any attachments) is confidential and may contain personal
> views which are not the views of the BBC unless specifically stated.
> https://urldefense.proofpoint.com/v2/url?u=https-
> 3A__www.ietf.org_mailman_listinfo_tictoc&d=DwIFgQ&c=I_0YwoKy7z5LMTVdyO6YCi
> E2uzI1jjZZuIPelcSjixA&r=WA71sf2o7Dw7CbYhFt24DPjt3lJuupswWYdnboKbZ8k&m=q08s
> dix-IT4WEtYgvpO5Vc1bUOFvO-iWzjpVV7ymSVM&s=BbZVGr-
> smJLMoDi8n42rSt3QtircWOMV-E3lTmaXjNA&e=