Subject: Re: [Ntp] WGLC draft-ietf-tictoc-ptp-enterprise-profile

From: Tal Mizrahi <[email-masked]>
Date: Tue, 3 Jul 2018 10:27:03 +0300

Hi,

I believe this draft is almost ready for publication, with a couple of
comments below.

A couple of comments:
- The section "Forbidden PTP Options" should include also unicast discovery
and unicast negotiation (mentioned in previous sections).
- In the "Security Considerations" section - I suggest to add a general
comment: "General security considerations of time protocols are discussed
in [RFC7384]".

Thanks,
Tal.

On Wed, Jun 27, 2018 at 6:35 AM, Karen O'Donoghue <[email-masked]>
wrote:

> Folks,
>
> This email begins a quick followup WGLC for the following draft:
> https://datatracker.ietf.org/doc/draft-ietf-tictoc-ptp-enterprise-profile/
>
> This document has been around for a long time, and it has been aligned
> with the updates planned to IEEE 1588. Please respond on the mailing list
> with your recommendation on publication of this document along with any
> final comments that you may have. This WGLC will close on Wednesday 11 July
> 2018.
>
> Regards,
> Karen
>
>
> _______________________________________________
> ntp mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/ntp
>
>

---

From: [email-masked]
Date: Tue, 3 Jul 2018 12:28:47 +0200

This draft ist well-written and almost ready to be published. 

I have these comments:

- Introduction: It is true that the application of PTP is complicated in 
financial data centers. But it is also true for other data centers. 
Therefore, I suggest to keep the language more general and to replace "... 
financial data centers" by "... data centers".

- Sec. 7 and 8: I suppose I understand the reason why Unicast Discovery, 
Unicast Message Negotiation, ... shall not be applied. However, it may be 
helpful to give an reason for that.

- Sec. 8: I suppose "unicast negotiation signaling message" should be 
capitalized in accordance with Sec. 7.

Dieter

"ntp" <[email-masked]> schrieb am 27.06.2018 05:35:55:

> Von: "Karen O'Donoghue" <[email-masked]>
> An: "[email-masked]" <[email-masked]>
> Kopie: "[email-masked]" <[email-masked]>
> Datum: 27.06.2018 05:36
> Betreff: [Ntp] WGLC draft-ietf-tictoc-ptp-enterprise-profile
> Gesendet von: "ntp" <[email-masked]>
> 
> Folks, 
> 
> 
> This document has been around for a long time, and it has been 
> aligned with the updates planned to IEEE 1588. Please respond on the
> mailing list with your recommendation on publication of this 
> document along with any final comments that you may have. This WGLC 
> will close on Wednesday 11 July 2018. 
> 
> Regards,
> Karen

---

From: Douglas Arnold <[email-masked]>
Date: Wed, 4 Jul 2018 17:32:58 -0400

I have no objections to Tal's suggestions.

--- Doug

On Tue, Jul 3, 2018 at 3:27 AM, Tal Mizrahi <[email-masked]>
wrote:

> - The section "Forbidden PTP Options" should include also unicast
> discovery and unicast negotiation (mentioned in previous sections).
> On Wed, Jun 27, 2018 at 6:35 AM, Karen O'Donoghue <[email-masked]
> <odonoghue@isoc..org>> wrote:
>
>> Folks,
>>

-- 
Doug Arnold
Principal Technologist
Meinberg USA
+1-508-309-6268

---

From: Douglas Arnold <[email-masked]>
Date: Wed, 4 Jul 2018 17:32:21 -0400

I should add that independent implementations by 5 organizations have been
tested at the ISPCS 1588 plugfest and found to interoperate.

--- Doug Arnold

-- 
Doug

---

From: Rodney Cummings <[email-masked]>
Date: Thu, 5 Jul 2018 21:17:49 +0000

Hello,

I recommend publication of this document.

In section 16 (Security Considerations), the document should mention that PTP Management messages (mentioned as an optional feature in section 12) provide no security. Since management of IEEE Std 1588 features by a malicious actor can have adverse consequences, we could add a statement to section 16 to clarify that management with SNMP, NETCONF, or RESTCONF provides secure management of IEEE Std 1588 features.

Rodney Cummings

From: TICTOC [mailto:[email-masked]] On Behalf Of Karen O'Donoghue
Sent: Tuesday, June 26, 2018 10:36 PM
To: [email-masked]
Cc: [email-masked]
Subject: [TICTOC] WGLC draft-ietf-tictoc-ptp-enterprise-profile

Folks,

This email begins a quick followup WGLC for the following draft:
https://datatracker.ietf.org/doc/draft-ietf-tictoc-ptp-enterprise-profile/<https://urldefense.proofpoint.com/v2/url?u=https-3A__datatracker.ietf.org_doc_draft-2Dietf-2Dtictoc-2Dptp-2Denterprise-2Dprofile_&d=DwMFAg&c=I_0YwoKy7z5LMTVdyO6YCiE2uzI1jjZZuIPelcSjixA&r=WA71sf2o7Dw7CbYhFt24DPjt3lJuupswWYdnboKbZ8k&m=I8S2r7PKYoaoftqqqb_QdqfdQqVINE4utTVmy2DFzbM&s=WmR-BgSyfo7jBRjuLTjwWKHkENuGWevGYnbDjL3Ib4Y&e=>

This document has been around for a long time, and it has been aligned with the updates planned to IEEE 1588. Please respond on the mailing list with your recommendation on publication of this document along with any final comments that you may have. This WGLC will close on Wednesday 11 July 2018.

Regards,
Karen

---

From: Denis Reilly <[email-masked]>
Date: Mon, 9 Jul 2018 01:07:47 +0000

Hello,

I recommend publication of this document. We are one of the organizations who has tested this profile at the IEEE 1588 plugfest, and we are looking forward to its full adoption.

I have a few minor notes, they are mainly minor typos and clarifications:

In the Definitions section:

- The Clock Identity definition states that "Often the Ethernet MAC address is used" as a clock identity. Readers who are new to 1588 may think that the MAC address is used directly, but in IEEE 1588, the 48-bit MAC address is expanded to form a 64-bit Clock Identity. I recommend rewording for clarity, with my additions in brackets:

     Clock Identity: In IEEE 1588-2008 this is a 64-bit number
     assigned to each PTP clock which must be unique. <<On Ethernet netwoks 
     this is often derived from the MAC address>> since there is already an
     international infrastructure for assigning unique <<MAC addresses>> to each
     device manufactured.

-      PTP: The Precision Time Protocol, the timing and synchronization protocol define by IEEE 1588.
"define" should probably be "defined"?

- The definitions of "Grandmaster" and "Master Clock" do not start with a capital letter like the rest of the definitions.
Also, the definition of "Grandmaster" does not end in a period like the rest.

- Section 14:
In addition, the Default Profile would have to operates over IPv4 or IPv6 networks

Shouldn't that be "operate"?

Finally, throughout the document, there is inconsistent capitalization of "Boundary Clock", "Ordinary Clock", Transparent Clock" and "Slave Only Clock".  Since these are all defined, maybe they should be all caps all the time? 

Best Regards,

--
Denis Reilly  |  Lead Engineer  |  [email-masked] (585)321-5837

From: ntp [mailto:[email-masked]] On Behalf Of Douglas Arnold
Sent: Wednesday, July 04, 2018 2:32 PM
To: Karen O'Donoghue
Cc: [email-masked]; [email-masked]
Subject: Re: [Ntp] WGLC draft-ietf-tictoc-ptp-enterprise-profile

I should add that independent implementations by 5 organizations have been tested at the ISPCS 1588 plugfest and found to interoperate.  

--- Doug Arnold

On Tue, Jun 26, 2018 at 11:35 PM, Karen O'Donoghue <[email-masked]> wrote:
Folks, 

Regards,
Karen

-- 
Doug

---

From: Jeffry Dwight <[email-masked]>
Date: Fri, 06 Jul 2018 20:16:32 -0500

Nit. Section 14, "In addition, the Default Profile would have to operates over IPv4 or IPv6 networks" -- should be operate, not operates. ---- On Thu, 05 Jul 2018 16:17:49 -0500 Rodney Cummings <[email-masked]> wrote ---- Hello,   I recommend publication of this document.   In section 16 (Security Considerations), the document should mention that PTP Management messages (mentioned as an optional feature in section 12) provide no security. Since management of IEEE Std 1588 features by a malicious actor can have adverse consequences, we could add a statement to section 16 to clarify that management with SNMP, NETCONF, or RESTCONF provides secure management of IEEE Std 1588 features.   Rodney Cummings   From: TICTOC [mailto:[email-masked]] On Behalf Of Karen O'Donoghue Sent: Tuesday, June 26, 2018 10:36 PM To: [email-masked] Cc: [email-masked] Subject: [TICTOC] WGLC draft-ietf-tictoc-ptp-enterprise-profile   Folks,   This email begins a quick followup WGLC for the following draft: https://datatracker.ietf.org/doc/draft-ietf-tictoc-ptp-enterprise-profile/   This document has been around for a long time, and it has been aligned with the updates planned to IEEE 1588. Please respond on the mailing list with your recommendation on publication of this document along with any final comments that you may have. This WGLC will close on Wednesday 11 July 2018.    Regards, Karen   _______________________________________________ TICTOC mailing list [email-masked] https://www.ietf.org/mailman/listinfo/tictoc

---

From: Heiko Gerstung <[email-masked]>
Date: Mon, 16 Jul 2018 10:12:01 +0200

Neither do I, thanks a lot, Tal!

BR

  Heiko

-- 

Heiko Gerstung 
Managing Director

MEINBERG® Funkuhren GmbH & Co. KG
Lange Wand 9
D-31812 Bad Pyrmont, Germany
Phone:    +49 (0)5281 9309-404
Fax:        +49 (0)5281 9309-9404

Amtsgericht Hannover 17HRA 100322
Geschäftsführer/Management: Günter Meinberg, Werner Meinberg, Andre Hartmann, Heiko Gerstung

On 04.07.18, 23:34  "TICTOC im Auftrag von Douglas Arnold" <[email-masked] im Auftrag von [email-masked]> wrote:

--- Doug

On Tue, Jul 3, 2018 at 3:27 AM, Tal Mizrahi <[email-masked]> wrote:

Hi, 

I believe this draft is almost ready for publication, with a couple of comments below.

A couple of comments:

- The section "Forbidden PTP Options" should include also unicast discovery and unicast negotiation (mentioned in previous sections).

- In the "Security Considerations" section - I suggest to add a general comment: "General security considerations of time protocols are discussed in [RFC7384]".

Thanks,

Tal.

On Wed, Jun 27, 2018 at 6:35 AM, Karen O'Donoghue <[email-masked]> wrote:

Folks, 

Regards,

Karen

 

-- 

Doug Arnold

Principal Technologist

Meinberg USA

+1-508-309-6268

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

---

From: Wojciech Owczarek <[email-masked]>
Date: Mon, 16 Jul 2018 11:15:31 +0100

All,

I might have asked this question before and I think I know the answer, but just to re-state this:

This being an IEEE 1588 profile, a recommendation to set logMessagePeriod in the enterprise profile delay response header to be the configured master delayReq period, rather than the 0x7F as per the standard for any unicast message, is out of the question?

This would allow the delay message interval to be autodiscovered like it is with multicast delayReq/resp. I have seen this done in the field, just like some slave implementations will try unicast delayReq first, and use multicast if no response received. 0x7F makes sense as an indication that the interval should be negotiated, but not where unicast is used without negotiation. This only adds an extra variable to the otherwise automatic slave configuration.

I have not been keeping up with the protocol revision work, but does anyone know if P1588 was able to tackle this?

Regards,
Wojciech

--

Wojciech Owczarek

  Original Message  
From: [email-masked]
Sent: 16 July 2018 9:12 am
To: [email-masked]; [email-masked]
Cc: [email-masked]; [email-masked]; [email-masked]
Subject: Re: [TICTOC] [Ntp] WGLC draft-ietf-tictoc-ptp-enterprise-profile

BR

  Heiko

-- 

Heiko Gerstung 
Managing Director

--- Doug

Hi, 

A couple of comments:

Thanks,

Tal.

Folks,

Regards,

Karen

 

--

Doug Arnold

Principal Technologist

Meinberg USA

+1-508-309-6268

---

From: Jeffry Dwight <[email-masked]>
Date: Mon, 16 Jul 2018 12:07:37 -0500

My understanding of the Enterprise profile is that the logMessageInterval field is simply ignored in favor of a profile-specified value. The profile is designed to live alongside non-Enterprise nodes on the same PTP network. All other profiles are going to put 0x7F in the logMessageInterval field on a unicast reply, so the field can't be used for auto-discovery of parameters with any profile. I think using 0x7F was a bad idea in the first place, but it's a very clear requirement in 1588-2008. I can't think of any good reason to remove useful information simply because a message was unicast instead of multicast. There's already a flag for that in the header. Best regards, Jeffry ---- On Mon, 16 Jul 2018 05:15:31 -0500 Wojciech Owczarek <[email-masked]> wrote ---- All, I might have asked this question before and I think I know the answer, but just to re-state this: This being an IEEE 1588 profile, a recommendation to set logMessagePeriod in the enterprise profile delay response header to be the configured master delayReq period, rather than the 0x7F as per the standard for any unicast message, is out of the question? This would allow the delay message interval to be autodiscovered like it is with multicast delayReq/resp. I have seen this done in the field, just like some slave implementations will try unicast delayReq first, and use multicast if no response received. 0x7F makes sense as an indication that the interval should be negotiated, but not where unicast is used without negotiation. This only adds an extra variable to the otherwise automatic slave configuration. I have not been keeping up with the protocol revision work, but does anyone know if P1588 was able to tackle this? Regards, Wojciech -- Wojciech Owczarek   Original Message   From: [email-masked] Sent: 16 July 2018 9:12 am To: [email-masked]; [email-masked] Cc: [email-masked]; [email-masked]; [email-masked] Subject: Re: [TICTOC] [Ntp] WGLC draft-ietf-tictoc-ptp-enterprise-profile Neither do I, thanks a lot, Tal!   BR   Heiko     --  Heiko Gerstung  Managing Director MEINBERG® Funkuhren GmbH & Co. KG Lange Wand 9 D-31812 Bad Pyrmont, Germany Phone:    +49 (0)5281 9309-404 Fax:        +49 (0)5281 9309-9404 Amtsgericht Hannover 17HRA 100322 Geschäftsführer/Management: Günter Meinberg, Werner Meinberg, Andre Hartmann, Heiko Gerstung   On 04.07.18, 23:34  "TICTOC im Auftrag von Douglas Arnold" <[email-masked] im Auftrag von [email-masked]> wrote:   I have no objections to Tal's suggestions.     --- Doug   On Tue, Jul 3, 2018 at 3:27 AM, Tal Mizrahi <[email-masked]> wrote: Hi,    I believe this draft is almost ready for publication, with a couple of comments below.   A couple of comments: - The section "Forbidden PTP Options" should include also unicast discovery and unicast negotiation (mentioned in previous sections). - In the "Security Considerations" section - I suggest to add a general comment: "General security considerations of time protocols are discussed in [RFC7384]".   Thanks, Tal.   On Wed, Jun 27, 2018 at 6:35 AM, Karen O'Donoghue <[email-masked]> wrote: Folks,   This email begins a quick followup WGLC for the following draft: https://datatracker.ietf.org/doc/draft-ietf-tictoc-ptp-enterprise-profile/   This document has been around for a long time, and it has been aligned with the updates planned to IEEE 1588. Please respond on the mailing list with your recommendation on publication of this document along with any final comments that you may have. This WGLC will close on Wednesday 11 July 2018.    Regards, Karen     _______________________________________________ ntp mailing list [email-masked] https://www.ietf.org/mailman/listinfo/ntp   _______________________________________________ ntp mailing list [email-masked] https://www.ietf.org/mailman/listinfo/ntp   -- Doug Arnold Principal Technologist Meinberg USA +1-508-309-6268   _______________________________________________ TICTOC mailing list [email-masked] https://www.ietf.org/mailman/listinfo/tictoc _______________________________________________ TICTOC mailing list [email-masked] https://www.ietf.org/mailman/listinfo/tictoc