Picon

New Version Notification for draft-marlow-tictoc-computer-clock-accuracy-01.txt

A new version of I-D, draft-marlow-tictoc-computer-clock-accuracy-01.txt has been successfully
submitted and posted to the IETF repository.

Filename:	 draft-marlow-tictoc-computer-clock-accuracy
Revision:	 01
Title:		 Network Time Mechanisms for Improving Computer Clock Accuracy
Creation date:	 2011-10-28
WG ID:		 Individual Submission
Number of pages: 14

Abstract:
        This draft describes network time synchronization mechanisms that
        may enable increased accuracy, beyond that possible with the current
        Network Time Protocol version 4 standard, to the time of computer
        clocks. The mechanisms considered are those that will provide
        improved estimates as to when a packet is put on the network,
        transferred across a network, or taken from the network. Potential
        standardization actions will be considered for the mechanisms
        considered, though no such actions are recommended at this time.

Download the draft at the following link:

https://datatracker.ietf.org/doc/draft-marlow-tictoc-computer-clock-accuracy/

--
***********************************************************
Timothy R. Plunkett
NSWC-DD, Code W64
Building 1500 Room A104
17214 AVENUE B SUITE 126
(Continue reading)

Peter.Meyer | 4 Nov 15:03 2011

Re: draft-ietf-tictoc-1588overmpls-02.txt / Annex


Hi Manav et al,

In speaking with Stefano last week, it seems if the mapping is PTP over IP over MPLS, or PTP over Ethernet over MPLS then we may be able to re-use the existing IEEE 1588 Annexes for IPv4 and Ethernet mappings.  This may save some time to develop this IETF specification.

Regards,

Microsemi Corporation
Peter Meyer
Timing & Synchronization
Communication and Medical Products Group
Office: +1-613-270-7203  |  Fax: +1-613-592-1010
peter.meyer <at> zarlink.com  | www.zarlink.com




<Peter.Meyer <at> zarlink.com>
Sent by: <tictoc-bounces <at> ietf.org>

25/10/2011 12:39 PM

To
"Bhatia, Manav (Manav)" <manav.bhatia <at> alcatel-lucent.com>
cc
"tictoc <at> ietf.org" <tictoc <at> ietf.org>, <tictoc-bounces <at> ietf.org>
Subject
Re: [TICTOC] FW: I-D Action: draft-ietf-tictoc-1588overmpls-02.txt






Hi Manav et al,

I'm also wondering if we need to fill out something similar to IEEE 1588-2008 Annex D-F, or include such information in this document.

For example, the protocol address used for the portAddress.

The Annex D - F seem to have generally the same structure.


Annex E Transport of PTP over UDP over IPv4
D.1 General
D.2 UDP port numbers
D.3 IPv4 multicast addresses
D.4 transportSpecific field values
D.5 Optional values
D.6 IPv4 Options
D.7 Protocol addresses

Annex E Transport of PTP over UDP over IPv6
E.1 General
E.2 UDP port numbers
E.3 IPv6 multicast addresses
E.4 transportSpecific field values
E.5 Optional values
E.6 Protocol addresses

Annex F Transport of PTP over IEEE 802.3/Ethernet
F.1 General
F.2 Ethertype
F.3 Multicast MAC Addresses
F.4 transportSpecific field values
F.5 Optional values
F.6 Protocol addresses

Microsemi Corporation
Peter Meyer
Timing & Synchronization
Communication and Medical Products Group
Office: +1-613-270-7203  |  Fax: +1-613-592-1010
peter.meyer <at> zarlink.com  | www.zarlink.com



"Bhatia, Manav (Manav)" <manav.bhatia <at> alcatel-lucent.com>
Sent by: <tictoc-bounces <at> ietf.org>

07/10/2011 01:48 AM


To
"tictoc <at> ietf.org" <tictoc <at> ietf.org>
cc
Subject
[TICTOC] FW:  I-D Action: draft-ietf-tictoc-1588overmpls-02.txt







Hi Tictocers,

This version incorporates whatever comments we had recived till date. Would appreciate if the WG can review this updated version.

Cheers, Manav

-----Original Message-----
From: tictoc-bounces <at> ietf.org [mailto:tictoc-bounces <at> ietf.org] On Behalf Of internet-drafts <at> ietf.org
Sent: Friday, October 07, 2011 10:53 AM
To: i-d-announce <at> ietf.org
Cc: tictoc <at> ietf.org
Subject: [TICTOC] I-D Action: draft-ietf-tictoc-1588overmpls-02.txt

A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Timing over IP Connection and Transfer of Clock Working Group of the IETF.

               Title           : Transporting PTP messages (1588) over MPLS Networks
               Author(s)       : Shahram Davari
                        Amit Oren
                        Manav Bhatia
                        Peter Roberts
                        Laurent Montini
               Filename        : draft-ietf-tictoc-1588overmpls-02.txt
               Pages           : 34
               Date            : 2011-10-06

 This document defines the method for transporting PTP messages (PDUs)
 over an MPLS network.  The method allows for the easy identification
 of these PDUs at the port level to allow for port level processing of
 these PDUs in both LERs and LSRs.

 The basic idea is to transport PTP messages inside dedicated MPLS
 LSPs.  These LSPs only carry PTP messages and possibly Control and
 Management packets, but they do not carry customer traffic.

 Two methods for transporting 1588 over MPLS are defined.  The first
 method is to transport PTP messages directly over the dedicated MPLS
 LSP via UDP/IP encapsulation, which is suitable for IP/MPLS networks.
 The second method is to transport PTP messages inside a PW via
 Ethernet encapsulation, which is more suitable for MPLS-TP networks.


A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-tictoc-1588overmpls-02.txt

Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/

This Internet-Draft can be retrieved at:
ftp://ftp.ietf.org/internet-drafts/draft-ietf-tictoc-1588overmpls-02.txt
_______________________________________________
TICTOC mailing list
TICTOC <at> ietf.org
https://www.ietf.org/mailman/listinfo/tictoc
_______________________________________________
TICTOC mailing list
TICTOC <at> ietf.org
https://www.ietf.org/mailman/listinfo/tictoc

_______________________________________________
TICTOC mailing list
TICTOC <at> ietf.org
https://www.ietf.org/mailman/listinfo/tictoc

_______________________________________________
TICTOC mailing list
TICTOC <at> ietf.org
https://www.ietf.org/mailman/listinfo/tictoc
Shahram Davari | 4 Nov 16:09 2011

Re: draft-ietf-tictoc-1588overmpls-02.txt / Annex

Peter,

This is exactly what the spec says right now.

Thx
SD
 
From: Peter.Meyer <at> Zarlink.Com [mailto:Peter.Meyer <at> Zarlink.Com]
Sent: Friday, November 04, 2011 07:03 AM
Cc: tictoc <at> ietf.org <tictoc <at> ietf.org>
Subject: Re: [TICTOC] draft-ietf-tictoc-1588overmpls-02.txt / Annex
 

Hi Manav et al,

In speaking with Stefano last week, it seems if the mapping is PTP over IP over MPLS, or PTP over Ethernet over MPLS then we may be able to re-use the existing IEEE 1588 Annexes for IPv4 and Ethernet mappings.  This may save some time to develop this IETF specification.

Regards,

Microsemi Corporation
Peter Meyer
Timing & Synchronization
Communication and Medical Products Group
Office: +1-613-270-7203  |  Fax: +1-613-592-1010
peter.meyer <at> zarlink.com  | www.zarlink.com




<Peter.Meyer <at> zarlink.com>
Sent by: <tictoc-bounces <at> ietf.org>

25/10/2011 12:39 PM

To
"Bhatia, Manav (Manav)" <manav.bhatia <at> alcatel-lucent.com>
cc
"tictoc <at> ietf.org" <tictoc <at> ietf.org>, <tictoc-bounces <at> ietf.org>
Subject
Re: [TICTOC] FW: I-D Action: draft-ietf-tictoc-1588overmpls-02.txt






Hi Manav et al,

I'm also wondering if we need to fill out something similar to IEEE 1588-2008 Annex D-F, or include such information in this document.

For example, the protocol address used for the portAddress.

The Annex D - F seem to have generally the same structure.


Annex E Transport of PTP over UDP over IPv4
D.1 General
D.2 UDP port numbers
D.3 IPv4 multicast addresses
D.4 transportSpecific field values
D.5 Optional values
D.6 IPv4 Options
D.7 Protocol addresses

Annex E Transport of PTP over UDP over IPv6
E.1 General
E.2 UDP port numbers
E.3 IPv6 multicast addresses
E.4 transportSpecific field values
E.5 Optional values
E.6 Protocol addresses

Annex F Transport of PTP over IEEE 802.3/Ethernet
F.1 General
F.2 Ethertype
F.3 Multicast MAC Addresses
F.4 transportSpecific field values
F.5 Optional values
F.6 Protocol addresses

Microsemi Corporation
Peter Meyer
Timing & Synchronization
Communication and Medical Products Group
Office: +1-613-270-7203  |  Fax: +1-613-592-1010
peter.meyer <at> zarlink.com  | www.zarlink.com



"Bhatia, Manav (Manav)" <manav.bhatia <at> alcatel-lucent.com>
Sent by: <tictoc-bounces <at> ietf.org>

07/10/2011 01:48 AM


To
"tictoc <at> ietf.org" <tictoc <at> ietf.org>
cc
Subject
[TICTOC] FW:  I-D Action: draft-ietf-tictoc-1588overmpls-02.txt







Hi Tictocers,

This version incorporates whatever comments we had recived till date. Would appreciate if the WG can review this updated version.

Cheers, Manav

-----Original Message-----
From: tictoc-bounces <at> ietf.org [mailto:tictoc-bounces <at> ietf.org] On Behalf Of internet-drafts <at> ietf.org
Sent: Friday, October 07, 2011 10:53 AM
To: i-d-announce <at> ietf.org
Cc: tictoc <at> ietf.org
Subject: [TICTOC] I-D Action: draft-ietf-tictoc-1588overmpls-02.txt

A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Timing over IP Connection and Transfer of Clock Working Group of the IETF.

               Title           : Transporting PTP messages (1588) over MPLS Networks
               Author(s)       : Shahram Davari
                        Amit Oren
                        Manav Bhatia
                        Peter Roberts
                        Laurent Montini
               Filename        : draft-ietf-tictoc-1588overmpls-02.txt
               Pages           : 34
               Date            : 2011-10-06

 This document defines the method for transporting PTP messages (PDUs)
 over an MPLS network.  The method allows for the easy identification
 of these PDUs at the port level to allow for port level processing of
 these PDUs in both LERs and LSRs.

 The basic idea is to transport PTP messages inside dedicated MPLS
 LSPs.  These LSPs only carry PTP messages and possibly Control and
 Management packets, but they do not carry customer traffic.

 Two methods for transporting 1588 over MPLS are defined.  The first
 method is to transport PTP messages directly over the dedicated MPLS
 LSP via UDP/IP encapsulation, which is suitable for IP/MPLS networks.
 The second method is to transport PTP messages inside a PW via
 Ethernet encapsulation, which is more suitable for MPLS-TP networks.


A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-tictoc-1588overmpls-02.txt

Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/

This Internet-Draft can be retrieved at:
ftp://ftp.ietf.org/internet-drafts/draft-ietf-tictoc-1588overmpls-02.txt
_______________________________________________
TICTOC mailing list
TICTOC <at> ietf.org
https://www.ietf.org/mailman/listinfo/tictoc
_______________________________________________
TICTOC mailing list
TICTOC <at> ietf.org
https://www.ietf.org/mailman/listinfo/tictoc

_______________________________________________
TICTOC mailing list
TICTOC <at> ietf.org
https://www.ietf.org/mailman/listinfo/tictoc

_______________________________________________
TICTOC mailing list
TICTOC <at> ietf.org
https://www.ietf.org/mailman/listinfo/tictoc
Yaakov Stein | 16 Nov 15:09 2011

Re: Hello, everyone, I submit a new draft: draft-zhang-tictoc-pdv-lsp-00, Welcome comments and suggestions! Thank You!

Junhui

 

I have read through your draft, and have some problems with it.

 

1.       You call the draft PDV-based PTP LSP Setup, but only a small portion of the text deals with PDV.

A lot deals with congestion and its detection, bandwidth reservation, recovery mechanisms, etc.

Yes, these are related in some way to PDV, but they aren't the same.

I would prefer a draft focusing on one issue and solving it, rather than touching on a lot of different issues.

 

2.       It is not clear whether this draft is trying to improve frequency distribution or time distribution.

If both, then please point out which parts relate to which.

 

3.       Many abbreviations are defined up at the top, but I don't see them ever used.

BC, MBB, and even PDV PTP LSP seem to have been thought up, but never made it into the text.

 

4.       The text says: The packet networks are Ethernet, MPLS, T-MPLS or  IP. 

First, I guess you mean T-MPLS -> MPLS-TP. Second the rest of the text seems to be only for MPLS (TP?).

 

5.       But the third part networks(e.g.  MPLS  networks) may introduce the PDV noise.

I guess this should be    third part -> third party.  

In any case, all networks, whatever party, have PDV.

Some of the effect of PDV may be reduced by on-path support, whether in your own network or someone elses.

 

These problems left me unsure as to what this draft aspires to achieve.

 

6.       I have a fundamental problem with the discussion of PDV metrics.

Saying "If the PDV exceeds network limits" is not meaningful for timing recovery, except for worst case behavior.

G.8260 quoted in the draft merely states that for time recovery delay measurement is important,

while for frequency distribution delay variation may be more important.

It specifically leaves the definition of PDV metrics for further study.

As the author probably know, several metrics have been proposed,

but I know of no explicit relationship between any metric and actual recovery performance

(once again, I am not talking about very loose worst case limits).

I can easily create two scenarios, one with large very white PDV that can be easily filtered out,

and one with much smaller PDV but very low-pass, that strongly limits recovery.

 

7.       The whole section on LSP recovery left me confused. When switching over everything changes

and reconvergence may be lengthy. This hit may be much more significant than a slight PDV advantage

even were we know how to define a metric. The draft speaks of setting up 1+1 path protection.

This I really don't understand. How does the 1588 application know which path was taken ?

What rules out it receiving a few packets that traverse one path and then a few that traversed the other ?

 

8.       The security section is not relevant to the draft, and points to a non-normative section of 1588v2.

There is a lot of much more relevant security work that you could reference,

but since I don't understand what this draft is addressing, I can't tell what is needed here either.

 

Y(J)S

 

 

_______________________________________________
TICTOC mailing list
TICTOC <at> ietf.org
https://www.ietf.org/mailman/listinfo/tictoc
fu.xihua | 16 Nov 15:22 2011
Picon

Re: Hello, everyone, I submit a new draft: draft-zhang-tictoc-pdv-lsp-00, Welcome comments and suggestions! Thank You!


Hi Yaakov,

I read through your comments.

In my understand, this draft is talking how to switch PTP LSP to secondary PTP LSP when the performance (delay,jitter and loss) of primary LSP is going worse.

It propose the slave dected the performace in the dataplane and notify performance failure to master, then master can switch it to secondary PTP LSP.

You may refere to some drafts in MPLS WG about the delay-loss TE.

draft-fuxh-mpls-delay-loss-te-framework

Best Regards,

Xihua Fu



Yaakov Stein <yaakov_s <at> rad.com>
发件人:  tictoc-bounces <at> ietf.org

2011-11-16 22:09

收件人
"zhang.junhui1 <at> zte.com.cn" <zhang.junhui1 <at> zte.com.cn>
抄送
"tictoc <at> ietf.org" <tictoc <at> ietf.org>
主题
Re: [TICTOC] Hello, everyone, I submit a new draft: draft-zhang-tictoc-pdv-lsp-00, Welcome comments and suggestions! Thank You!





Junhui
 
I have read through your draft, and have some problems with it.
 
1.       You call the draft PDV-based PTP LSP Setup, but only a small portion of the text deals with PDV.
A lot deals with congestion and its detection, bandwidth reservation, recovery mechanisms, etc.
Yes, these are related in some way to PDV, but they aren't the same.
I would prefer a draft focusing on one issue and solving it, rather than touching on a lot of different issues.
 
2.       It is not clear whether this draft is trying to improve frequency distribution or time distribution.
If both, then please point out which parts relate to which.
 
3.       Many abbreviations are defined up at the top, but I don't see them ever used.
BC, MBB, and even PDV PTP LSP seem to have been thought up, but never made it into the text.
 
4.       The text says: The packet networks are Ethernet, MPLS, T-MPLS or  IP.  
First, I guess you mean T-MPLS -> MPLS-TP. Second the rest of the text seems to be only for MPLS (TP?).
 
5.       But the third part networks(e.g.  MPLS  networks) may introduce the PDV noise.
I guess this should be    third part -> third party.  
In any case, all networks, whatever party, have PDV.
Some of the effect of PDV may be reduced by on-path support, whether in your own network or someone elses.
 
These problems left me unsure as to what this draft aspires to achieve.
 
6.       I have a fundamental problem with the discussion of PDV metrics.
Saying "If the PDV exceeds network limits" is not meaningful for timing recovery, except for worst case behavior.
 G.8260 quoted in the draft merely states that for time recovery delay measurement is important,
while for frequency distribution delay variation may be more important.
It specifically leaves the definition of PDV metrics for further study.
As the author probably know, several metrics have been proposed,
but I know of no explicit relationship between any metric and actual recovery performance
(once again, I am not talking about very loose worst case limits).
I can easily create two scenarios, one with large very white PDV that can be easily filtered out,
and one with much smaller PDV but very low-pass, that strongly limits recovery.
 
7.       The whole section on LSP recovery left me confused. When switching over everything changes
and reconvergence may be lengthy. This hit may be much more significant than a slight PDV advantage
even were we know how to define a metric. The draft speaks of setting up 1+1 path protection.
This I really don't understand. How does the 1588 application know which path was taken ?
What rules out it receiving a few packets that traverse one path and then a few that traversed the other ?
 
8.       The security section is not relevant to the draft, and points to a non-normative section of 1588v2.
There is a lot of much more relevant security work that you could reference,
but since I don't understand what this draft is addressing, I can't tell what is needed here either.
 
Y(J)S
 
 _______________________________________________
TICTOC mailing list
TICTOC <at> ietf.org
https://www.ietf.org/mailman/listinfo/tictoc

_______________________________________________
TICTOC mailing list
TICTOC <at> ietf.org
https://www.ietf.org/mailman/listinfo/tictoc
Yaakov Stein | 16 Nov 15:31 2011

Re: Hello, everyone, I submit a new draft: draft-zhang-tictoc-pdv-lsp-00, Welcome comments and suggestions! Thank You!

Yes, I see that SOME of this draft is about detecting performance degradation and switching to a secondary LSP.

I just don't see anything about how to detect such performance degradation and how to hitlessly switch to the backup.

 

The drafts in the MPLS WG about delay and loss are completely irrelevant to timing flows.

 

Y(J)S

 

 

From: fu.xihua <at> zte.com.cn [mailto:fu.xihua <at> zte.com.cn]
Sent: Wednesday, November 16, 2011 16:22
To: Yaakov Stein
Cc: tictoc <at> ietf.org; tictoc-bounces <at> ietf.org; zhang.junhui1 <at> zte.com.cn
Subject: Re: Re: [TICTOC] Hello, everyone, I submit a new draft: draft-zhang-tictoc-pdv-lsp-00, Welcome comments and suggestions! Thank You!

 


Hi Yaakov,

I read through your comments.

In my understand, this draft is talking how to switch PTP LSP to secondary PTP LSP when the performance (delay,jitter and loss) of primary LSP is going worse.

It propose the slave dected the performace in the dataplane and notify performance failure to master, then master can switch it to secondary PTP LSP.

You may refere to some drafts in MPLS WG about the delay-loss TE.

draft-fuxh-mpls-delay-loss-te-framework

Best Regards,

Xihua Fu


Yaakov Stein <yaakov_s <at> rad.com>
发件人:  tictoc-bounces <at> ietf.org

2011-11-16 22:09

收件人

"zhang.junhui1 <at> zte.com.cn" <zhang.junhui1 <at> zte.com.cn>

抄送

"tictoc <at> ietf.org" <tictoc <at> ietf.org>

主题

Re: [TICTOC] Hello, everyone, I submit a new draft: draft-zhang-tictoc-pdv-lsp-00, Welcome comments and suggestions! Thank You!

 




Junhui
 
I have read through your draft, and have some problems with it.
 
1.       You call the draft PDV-based PTP LSP Setup, but only a small portion of the text deals with PDV.
A lot deals with congestion and its detection, bandwidth reservation, recovery mechanisms, etc.
Yes, these are related in some way to PDV, but they aren't the same.
I would prefer a draft focusing on one issue and solving it, rather than touching on a lot of different issues.
 
2.       It is not clear whether this draft is trying to improve frequency distribution or time distribution.
If both, then please point out which parts relate to which.
 
3.       Many abbreviations are defined up at the top, but I don't see them ever used.
BC, MBB, and even PDV PTP LSP seem to have been thought up, but never made it into the text.
 
4.       The text says: The packet networks are Ethernet, MPLS, T-MPLS or  IP.  
First, I guess you mean T-MPLS -> MPLS-TP. Second the rest of the text seems to be only for MPLS (TP?).
 
5.       But the third part networks(e.g.  MPLS  networks) may introduce the PDV noise.
I guess this should be    third part -> third party.  
In any case, all networks, whatever party, have PDV.
Some of the effect of PDV may be reduced by on-path support, whether in your own network or someone elses.
 
These problems left me unsure as to what this draft aspires to achieve.
 
6.       I have a fundamental problem with the discussion of PDV metrics.
Saying "If the PDV exceeds network limits" is not meaningful for timing recovery, except for worst case behavior.
 G.8260 quoted in the draft merely states that for time recovery delay measurement is important,
while for frequency distribution delay variation may be more important.
It specifically leaves the definition of PDV metrics for further study.
As the author probably know, several metrics have been proposed,
but I know of no explicit relationship between any metric and actual recovery performance
(once again, I am not talking about very loose worst case limits).
I can easily create two scenarios, one with large very white PDV that can be easily filtered out,
and one with much smaller PDV but very low-pass, that strongly limits recovery.
 
7.       The whole section on LSP recovery left me confused. When switching over everything changes
and reconvergence may be lengthy. This hit may be much more significant than a slight PDV advantage
even were we know how to define a metric. The draft speaks of setting up 1+1 path protection.
This I really don't understand. How does the 1588 application know which path was taken ?
What rules out it receiving a few packets that traverse one path and then a few that traversed the other ?
 
8.       The security section is not relevant to the draft, and points to a non-normative section of 1588v2.
There is a lot of much more relevant security work that you could reference,
but since I don't understand what this draft is addressing, I can't tell what is needed here either.
 
Y(J)S
 
 _______________________________________________
TICTOC mailing list
TICTOC <at> ietf.org
https://www.ietf.org/mailman/listinfo/tictoc

_______________________________________________
TICTOC mailing list
TICTOC <at> ietf.org
https://www.ietf.org/mailman/listinfo/tictoc
Karen O'Donoghue | 16 Nov 21:58 2011

reminder: tictoc meeting, Thursday, 17 Nov, 2011, 13:00-15:00 Taipei (05:00 UTC)

Folks,

The tictoc working group meeting at IETF82 will be later today:

Remote participation information is available via:
http://www.ietf.org/meeting/82/remote-participation.html

The webex session will just be for the display of the slides. The audio 
channel will be the standard IETF streaming audio. Note there is the 
normal buffering delay in the audio stream.

Regards,
Karen
Danny Mayer | 17 Nov 01:01 2011

Re: reminder: tictoc meeting, Thursday, 17 Nov, 2011, 13:00-15:00 Taipei (05:00 UTC)

I have no idea what time this. It needs to be specified in UTC if you
expect remote participation.

Please let us know.

Danny

On 11/16/2011 3:58 PM, Karen O'Donoghue wrote:
> Folks,
> 
> The tictoc working group meeting at IETF82 will be later today:
> 
> Remote participation information is available via:
> http://www.ietf.org/meeting/82/remote-participation.html
> 
> The webex session will just be for the display of the slides. The audio
> channel will be the standard IETF streaming audio. Note there is the
> normal buffering delay in the audio stream.
> 
> Regards,
> Karen
> 
> _______________________________________________
> TICTOC mailing list
> TICTOC <at> ietf.org
> https://www.ietf.org/mailman/listinfo/tictoc
> 
Greg Dowd | 17 Nov 01:29 2011

Re: reminder: tictoc meeting, Thursday, 17 Nov, 2011, 13:00-15:00 Taipei (05:00 UTC)

The title says 05:00 UTC.  Is this wrong?

Greg Dowd
gdowd at symmetricom dot com (antispam format)
Symmetricom, Inc.
www.symmetricom.com
"A clever person solves a problem.  A wise person avoids it." Albert Einstein

-----Original Message-----
From: tictoc-bounces <at> ietf.org [mailto:tictoc-bounces <at> ietf.org] On Behalf Of Danny Mayer
Sent: Wednesday, November 16, 2011 4:01 PM
To: odonoghue <at> isoc.org
Cc: tictoc <at> ietf.org
Subject: Re: [TICTOC] reminder: tictoc meeting, Thursday, 17 Nov, 2011, 13:00-15:00 Taipei (05:00 UTC)

I have no idea what time this. It needs to be specified in UTC if you
expect remote participation.

Please let us know.

Danny

On 11/16/2011 3:58 PM, Karen O'Donoghue wrote:
> Folks,
> 
> The tictoc working group meeting at IETF82 will be later today:
> 
> Remote participation information is available via:
> http://www.ietf.org/meeting/82/remote-participation.html
> 
> The webex session will just be for the display of the slides. The audio
> channel will be the standard IETF streaming audio. Note there is the
> normal buffering delay in the audio stream.
> 
> Regards,
> Karen
> 
> _______________________________________________
> TICTOC mailing list
> TICTOC <at> ietf.org
> https://www.ietf.org/mailman/listinfo/tictoc
> 

_______________________________________________
TICTOC mailing list
TICTOC <at> ietf.org
https://www.ietf.org/mailman/listinfo/tictoc
Tim Frost | 17 Nov 01:57 2011

Re: reminder: tictoc meeting, Thursday, 17 Nov, 2011, 13:00-15:00 Taipei (05:00 UTC)

Hi Greg, 
No it is not wrong, 05:00 UTC is the correct time for the meeting. 

Tim

On 17 Nov 2011, at 08:29, "Greg Dowd" <gdowd <at> symmetricom.com> wrote:

> The title says 05:00 UTC.  Is this wrong?
> 
> Greg Dowd
> gdowd at symmetricom dot com (antispam format)
> Symmetricom, Inc.
> www.symmetricom.com
> "A clever person solves a problem.  A wise person avoids it." Albert Einstein
> 
> 
> -----Original Message-----
> From: tictoc-bounces <at> ietf.org [mailto:tictoc-bounces <at> ietf.org] On Behalf Of Danny Mayer
> Sent: Wednesday, November 16, 2011 4:01 PM
> To: odonoghue <at> isoc.org
> Cc: tictoc <at> ietf.org
> Subject: Re: [TICTOC] reminder: tictoc meeting, Thursday, 17 Nov, 2011, 13:00-15:00 Taipei (05:00 UTC)
> 
> I have no idea what time this. It needs to be specified in UTC if you
> expect remote participation.
> 
> Please let us know.
> 
> Danny
> 
> On 11/16/2011 3:58 PM, Karen O'Donoghue wrote:
>> Folks,
>> 
>> The tictoc working group meeting at IETF82 will be later today:
>> 
>> Remote participation information is available via:
>> http://www.ietf.org/meeting/82/remote-participation.html
>> 
>> The webex session will just be for the display of the slides. The audio
>> channel will be the standard IETF streaming audio. Note there is the
>> normal buffering delay in the audio stream.
>> 
>> Regards,
>> Karen
>> 
>> _______________________________________________
>> TICTOC mailing list
>> TICTOC <at> ietf.org
>> https://www.ietf.org/mailman/listinfo/tictoc
>> 
> 
> _______________________________________________
> TICTOC mailing list
> TICTOC <at> ietf.org
> https://www.ietf.org/mailman/listinfo/tictoc
> _______________________________________________
> TICTOC mailing list
> TICTOC <at> ietf.org
> https://www.ietf.org/mailman/listinfo/tictoc

Gmane