Enterprise networks definitely span timezones - if not now then eventually through mergers and acquisition. I think having the wrong local time is worse than having no local time. I support disabling the capability for this profile.
Kevin Gross +1-303-447-0517 Media Network Consultant AVA Networks - www.AVAnw.com <http://www.avanw.com/> On Mon, Oct 28, 2013 at 2:05 PM, Douglas Arnold <[email protected]>wrote: > Hello John, > > I agree that local time is useful. I would not be averse to creating a > TLV to distribute local time offset, so that end node can convert to local > time and present it to users. > > However, I do not support the idea of using a local time epoch in the PTP > timestamp fields. This is an allowed option in IEEE 1588-2008, but I > believe that this is likely to cause interoperability problems, when some > vendors support it and others do not. Also some system architechs have > indicated that they deploy PTP across large networks, which span time > zones. This is the feature that should be forbidden. > > In the NTP standard (RFC5905) the timestamps in the packet all use a > specific time epoch, and generate all other desired time epoch as > corrections performed at the end points. Note also that in most computer > operating systems a single standard time epoch is used in and local time is > generated at the presentation layer for human readable interfaces. > > Doug > > > On Mon, Oct 28, 2013 at 8:10 AM, John Fletcher <[email protected]>wrote: > >> I'd also like to ask that you don't prohibit the Alternate Timescales >> option. This is potentially useful to distribute "local time" (your >> time-zone and dst) and there doesn't seem to be any need to prohibit it. >> >> John >> ------------------------------ >> *From:* [email protected] [[email protected]] on behalf of >> John Fletcher [[email protected]] >> *Sent:* 25 October 2013 11:01 >> *To:* Douglas Arnold >> *Cc:* [email protected] >> *Subject:* Re: [TICTOC] Enterprise Profile >> >> Doug, >> >> >> >> I would be interested to know the circumstances when you see the maximum >> phase adjustment information being used. >> >> >> >> Some comments: >> >> >> >> In section 6, you say, “In all three of the delay measurement modes…”. >> At that point in the text you have not yet mentioned multicast, hybrid and >> unicast modes so it’s not clear which modes you are referring to. >> >> >> >> In section 9, you say, “Slaves SHOULD NOT Synchronize to a Rogue >> Master.” It’s not clear how a slave would know that a master is rogue; >> presumably it would need to examine the announce messages of all masters >> and do its own BMCA evaluation. A more realistic “rogue” master would >> probably meet the BMCA criteria for selection. >> >> >> >> In section 12, “Alternative Time Scales” should be “Alternate Timescales”. >> >> >> >> >> >> Regards, >> >> John Fletcher >> >> >> >> *From:* [email protected] [mailto:[email protected]] *On >> Behalf Of *Douglas Arnold >> *Sent:* 25 October 2013 01:35 >> *To:* [email protected] >> *Subject:* [TICTOC] Enterprise Profile >> >> >> >> Hello Everyone, >> >> >> >> Attached is an updated version of the Enterprise profile. Sorry I missed >> the upload deadline for the Vancouver meeting. If you get a chance to >> look at it before then I will be there and would love to discuss it. >> >> >> >> Summary of changes: >> >> >> >> I also changed the TLV format to fit the latest proposal in the 1588 >> revision. >> >> >> >> I added a statement about not going into the master state unless one had >> a current UTC offset. >> >> >> >> I added to the TLV fields to indicate maximum phase correction over a >> sync cycle. >> >> >> >> -- >> >> Doug Arnold >> >> Principal Technologist >> >> *JTime!* Meinberg USA >> >> +1-707-303-5559 >> >> >> >> >> >> >> >> ---------------------------- >> >> 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. >> >> --------------------- >> >> >> >> ---------------------------- >> >> 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. >> >> --------------------- >> > > > > -- > Doug > > _______________________________________________ > TICTOC mailing list > [email protected] > https://www.ietf.org/mailman/listinfo/tictoc > >
_______________________________________________ TICTOC mailing list [email protected] https://www.ietf.org/mailman/listinfo/tictoc
