Orie Steele has entered the following ballot position for
draft-ietf-tictoc-ptp-enterprise-profile-26: No Objection

When responding, please keep the subject line intact and reply to all
email addresses included in the To and CC lines. (Feel free to cut this
introductory paragraph, however.)


Please refer to 
https://www.ietf.org/about/groups/iesg/statements/handling-ballot-positions/ 
for more information about how to handle DISCUSS and COMMENT positions.


The document, along with other ballot positions, can be found here:
https://datatracker.ietf.org/doc/draft-ietf-tictoc-ptp-enterprise-profile/



----------------------------------------------------------------------
COMMENT:
----------------------------------------------------------------------

# Orie Steele, ART AD, comments for draft-ietf-tictoc-ptp-enterprise-profile-26
CC @OR13

https://author-tools.ietf.org/api/idnits?url=https://www.ietf.org/archive/id/draft-ietf-tictoc-ptp-enterprise-profile-26.txt&submitcheck=True

I agree with the comments from Deb Cooley regarding framing of normative
language.

## Comments

### Grandmaster term

```
157        *  Best timeTransmitter: A clock with a PTP Port in the
158           timeTransmitter state, operating as the Grandmaster of a PTP
159           domain.
```

Does IEEE1588g define an alternative term for Grandmaster?

Given the other terminology changes, perhaps `primaryTimeTransmitter`, is a
better term to use.

Later, the term `Preferred timeTransmitter` is used, is a "Preferred
timeTransmitter" always a "primary timeTransmitter Clock within a domain of a
PTP system". It seems odd to have the concept of a "preferred primary..." that
is a backup... is the alternate timeTransmitter flag set when the "Preferred
timeTransmitter" is a backup?

Consider defining Grandmaster cluster as well, given the term appears later:

```
479        timing for delay measurement.  Grandmaster Clusters are NOT ALLOWED.
```

### How to operate in the presence of a rogue timeTransmitter?

```
429        timeTransmitters in their clock control subsystems.  TimeReceiver
430        Clocks MUST be able to operate properly in the presence of a rogue
431        timeTransmitter.  TimeReceivers SHOULD NOT Synchronize to a
```

Its not clear to me how to comply with this MUST, based on the surrounding
context. Perhaps there is a citation that could be given for to answer the
question of "how?".

## Nits

### aloted -> alloted

```
357        Section D.3.  These addresses are aloted by IANA, see the Ipv6
```

### ensembled -> assembled

```
373        Domain.  Redundant sources of timing can be ensembled, and/or
```

ensembled is ok, but a more common word might be easier to comprehend for most
readers.

### syntonize -> synchronize

```
456        Clocks which syntonize to the timeTransmitter Clock might need to
```



_______________________________________________
TICTOC mailing list -- [email protected]
To unsubscribe send an email to [email protected]

Reply via email to