Subject: [TICTOC] Enterprise Profile

From: Douglas Arnold <[email-masked]>
Date: Sun, 5 Nov 2017 18:09:34 +0100

There was a error in the last version of the Enterprise Profile.  The
Profile Identifier was missing two hex digits for the profile number.  This
has been corrected in the attached file.  I will officially upload version
9 with this fix after the upload lockout is lifted.

Thanks to Jeffry Dwight for catching this.

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

---

From: Jeffry Dwight <[email-masked]>
Date: Sun, 05 Nov 2017 17:12:54 -0600

Thanks, Doug! It's nice to be able to associate a number with the name. We'll update our documentation and our internal database.

Jeffry Dwight

Greyware Automation Products, Inc.

---- On Sun, 05 Nov 2017 11:09:34 -0600 Douglas Arnold &lt;[email-masked]&gt; wrote ----

There was a error in the last version of the Enterprise Profile.  The Profile Identifier was missing two hex digits for the profile number.  This has been corrected in the attached file.  I will officially upload version 9 with this fix after the upload lockout is lifted.

-- 

Doug Arnold

Principal Technologist

Meinberg USA

+1-508-309-6268

---

From: Jeffry Dwight <[email-masked]>
Date: Mon, 20 Nov 2017 18:07:01 -0600

With regard to section 12:

12.     Management and Signaling Messages

    PTP Management messages MAY be used.  Any PTP management message

    which is sent with the targetPortIdentity.clockIdentity set to all

    1s (all clocks) MUST be sent as a multicast message.  Management

    messages with any other value of for the Clock Identity is

    intended for a specific clock and MUST be sent as a unicast

    message.  Similarly, if any signaling messages are used they

    MUST also be sent as unicast messages whenever the message is

    intended for a specific clock.

This restriction (not allowing all 1's for unicast management messages) seems unnecessary and slightly bothersome. A node's portIdentity is as easily obtainable as its IP address. In fact, the easiest way to determine a node's portIdentity is to send a management message (any one, really) to the node's IP, with the targetPortIdentity set to all  1's. The reply reveals the portIdentity. We have tools that use this trick to identify nodes so that other management messages may be addressed more properly, either by unicast or multicast. In particular, we have a test tool that allows an admin to enter only the IP address and find all the node's information, such as domain, portState, etc.

Since the query message is unicast, it avoids the messiness of sorting through dozens, or hundreds, of multicast replies. I suggest that a unicast message, regardless of the targetPortIdentity is pretty much, by definition, intended for a specific clock. I would like to see this restriction removed.

Additionally, you only mention a clockIdentity of all 1's. We often use all 1's for the clockIdentity and all 1's for the portNumber. This allows the node to respond without the query having prior knowledge of either the clockIdentity or the portNumber.

Jeffry Dwight