From ntpwg-bounces+ntp-archives-ahfae6za=lists.ietf.org@lists.ntp.org Wed Jul 4 11:34:14 2012 Return-Path: X-Original-To: ietfarch-ntp-archives-ahFae6za@ietfa.amsl.com Delivered-To: ietfarch-ntp-archives-ahFae6za@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BD19B21F86B6 for ; Wed, 4 Jul 2012 11:34:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.67 X-Spam-Level: X-Spam-Status: No, score=-5.67 tagged_above=-999 required=5 tests=[AWL=0.929, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id otymtrGoxU58 for ; Wed, 4 Jul 2012 11:34:13 -0700 (PDT) Received: from lists.ntp.org (lists.ntp.org [149.20.68.7]) by ietfa.amsl.com (Postfix) with ESMTP id 95D1F21F8697 for ; Wed, 4 Jul 2012 11:34:13 -0700 (PDT) Received: from lists.ntp.org (lists.ntp.org [149.20.68.7]) by lists.ntp.org (Postfix) with ESMTP id AA09B86DAB7 for ; Wed, 4 Jul 2012 18:34:24 +0000 (UTC) X-Original-To: ntpwg@lists.ntp.org Delivered-To: ntpwg@lists.ntp.org Received: from mail1.ntp.org (mail1.ntp.org [IPv6:2001:4f8:fff7:1::5]) by lists.ntp.org (Postfix) with ESMTP id 2160486D333 for ; Wed, 4 Jul 2012 17:14:24 +0000 (UTC) Received: from louie.udel.edu ([128.4.40.12] helo=mail.eecis.udel.edu) by mail1.ntp.org with esmtp (Exim 4.77 (FreeBSD)) (envelope-from ) id 1SmT9h-000PZp-1P for ntpwg@lists.ntp.org; Wed, 04 Jul 2012 17:14:24 +0000 Received: from [192.168.1.2] (pool-173-62-174-206.phlapa.fios.verizon.net [173.62.174.206]) (Authenticated sender: mills@mail.eecis.udel.edu) by mail.eecis.udel.edu (Postfix) with ESMTP id 0A2AECA3; Wed, 4 Jul 2012 13:14:20 -0400 (EDT) Message-ID: <4FF479EA.3030806@udel.edu> Date: Wed, 04 Jul 2012 17:14:18 +0000 From: "David L. Mills" User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US; rv:1.7.2) Gecko/20040804 Netscape/7.2 (ax) X-Accept-Language: en-us, en MIME-Version: 1.0 To: "Marlow, David T CIV NSWCDD, W64" References: <4DF03979.5070204@pobox.com> In-Reply-To: X-SA-Exim-Connect-IP: 128.4.40.12 X-SA-Exim-Rcpt-To: ntpwg@lists.ntp.org X-SA-Exim-Mail-From: mills@udel.edu X-SA-Exim-Version: 4.2 X-SA-Exim-Scanned: Yes (on mail1.ntp.org) Cc: ntpwg@lists.ntp.org, tictoc@ietf.org Subject: Re: [ntpwg] Renamed: Interleave Questions X-BeenThere: ntpwg@lists.ntp.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: IETF Working Group for Network Time Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed" Errors-To: ntpwg-bounces+ntp-archives-ahfae6za=lists.ietf.org@lists.ntp.org Sender: ntpwg-bounces+ntp-archives-ahfae6za=lists.ietf.org@lists.ntp.org David , The primary purpose of the scenarios illustrated in the book was to quantify the output delay and the antisymmetric Ethernet card delays, especially with Solaris. The GPS servers used for primary synchronization operate only in client/server mode and so far as I know, not in any interleave mode. There has been recent interest in stateful servers, such as might be supported using the MRU list now used for rate management. If this works out, it might be possible to support an interleaved client/server mode. This might be a topic for further research. Dave Marlow, David T CIV NSWCDD, W64 wrote: >Dave, > A while back in an email thread you pointed out that our ID (draft-marlow-tictoc-computer-clock-accuracy-00.txt) only addressed interleaved broadcast and did not include interleaved symmetric mode and that a lot of the detail information is in your book. We bought the book and have learned a lot particularly in section 16.6 where you have measurement data for interleave mode operation. Your Backroom LAN example is similar to the experiments we ran. We had some questions: > >1) In your Backroom LAN example the GPS clock server ran in client/server mode with clients Macabre and Mort. Would you expect better accuracy if client/server mode is used (as you did) versus if interleave broadcast mode were used between this server and these two clients? > >2)Similar in your Campus LAN example you used client/server mode in some of the operations versus using interleave broadcast, where is client/server mode better than interleave broadcast to use? > >3) In your Backroom LAN example, Macabre and Mort ran interleaved symmetric mode between each other. Would not the dominant synchronization factor come from the GPS clock server, given its lower stratum number? Is the interleaved symmetric mode exchanges providing a secondary effect to keep these two together? > > Dave > > >-----Original Message----- >From: tictoc-bounces@ietf.org [mailto:tictoc-bounces@ietf.org] On Behalf Of Karen O'Donoghue >Sent: Wednesday, June 08, 2011 23:10 >To: NTP Working Group; tictoc@ietf.org >Subject: [TICTOC] Fwd: Re: [ntpwg] Fwd: reminder for remote participation in today's tictoc meeting > >Folks, > >This came to me personally, and I neglected to send it on to the ntp and tictoc wg lists. My apologies for the delay. The question before us is whether or not the interleave capability should be properly documented and where the resources will come from to complete the effort. > >Karen > >-------- Original Message -------- >Subject: Re: [ntpwg] Fwd: [TICTOC] reminder for remote participation in today's tictoc meeting >Date: Tue, 12 Apr 2011 18:18:43 +0000 >From: David L. Mills >To: kodonog@pobox.com > > >Karen, > >The following is in response to the ID you distributed. I offer it as a candidate for distribution to th eWG members. > >Dave > >This internet draft describes experiments using the interleaved broadcast mode recently incorporated in the NTP reference implementation. The experiments do not include the interleaved symmetric mode, which provides similar functionality in peer-to-peer configurations. For reference, these modes, their relevance to PTP and related information are discussed in detail in Chapters 15 through 17 of the book "Network Time Synchronization - the Network Time Protocol on Earth and in Space, Second Edition, CRC Press 2011, as cited on my web page www.eedis.udel.edu/~mills . However, most of the information relevant to the followings discussion can be found in the white papers at www.eecis.udel.edu/~mills/ntp.html . Of particular interest are the documents "Analysis and Simulation of the NTP On-Wire Protocol" and "Security Analysis of the NTP Protocol." Both of these documents represent an update since th! >! >e book was published late last year. > >Readers may wonder why these documents have not been published as an update to the protocol specification RFC-5905, which would have been the expectation several years ago in the adolescent Internet. However, the effort necessary to publish an ID with figures, tables and equations is nowadays simply unacceptable. My experience with RFC-5905 and RFC-5906 over the last five years of publishing effort is not sustainable. Thus, unless some collaboration, perhaps the TICTOC working group, chose to publish them as IDs, I will not commit that adventure myself. > >First some nomenclature that may help in the following discussion. Timestamps captured for the clock discipline are classed as hardstamps, drivestamps and softstamps. Softstamps are captured during the course of user-space processing; they may be corrupted by operating system and device latencies, as well as transmission delays. Drivestamps are captured during the packet interrupt routines, so are much less affected by operating system scheduling and competition with other programs. Hardstamps are captured by dedicated hardware means, typically in the PHY layer of the network interface card (NIC). While the details vary, the typical intercept point is the media independent interface (MII), which monitors the frame level interface on a character by character basis. The capture means is usuallt a field-programmable gate array (FPGA) that parses the packeet, inserts timestamp data and recomputes the UDP checksum. > >The interleaved capability was originally not intended for NTP, but for the Proximity-1 protocol specified by the Consultive Committee on Space Data systems (CCSDS). The Proximity-1 protocol is designed for communication between spacecraft in the vicinity of Mars and for future missions in the vicinity of the Moon. Space data links are often operated at very low data rates compared to typical Ethernet links. Typical rates range from 1 kb/s to 256 kb/s with very different data rates in each direction. Due to various queuing and transmission operations, the output delay can reach 30 s, so it is imparities that timestamps be captured close to the PHY layer. In the Proximity-1 desing, hardstamps are captured upon the passage of the ASM code combination at the beginning of each transmitted frame.. > >Queuing and transmission delays are not the only contributors to space data link delay. Reed-Solomon and convolutional encoding delays can be a large contribution to the link delay; however, these delays are a constant contribution to the lightwave transmission delay. These contributions - up to many seconds - can dwarf the lightwave transmission delays. > >In the NTP interleaved design, drivestamps are captured in the device interrupt routine - on input immediately after the frame has been received and before copying to an input buffer; on output shortly after the frame has been transmitted and before the buffer is released for the following input or output frame. This can become rather awkward in the case of NICs of the PCNET architecture, as data are copied directly from user space to device buffers directed by DMA descriptors. Drivestamps have been used on input for many years, but for output this is possible only using the interleaved modes. The result avoids the latencies due to the message digest computation, Autokey protocol data units, output queuing and frame transmissions, typically some 10-40 microseconds. > >It should be obvious from the documents that a primary motivation for the NTP interleaved design was protection from network errors and intruder attack. The detailed analysis and simulation are designed to demonstrate resistance to common corruptions such as dropped or duplicate packets and possible bogus attacks. The NTP design includes a four-level security model, the lower two levels might be considered for a PTP application. This is one of the most important difference between the PTP and NTP protocol designs; however, the NTP design might be considered overkill in a sheltered, isolated Ethernet network. > >Careful observers may notice an interesting anomaly with the interleaved broadcast mode. The preliminary volley intended to measure the roundtrip time uses basic mode, not interleaved mode. The reason for this requires some explanation. In times of old, the dominant concern was the 6-bone, an international consortium of multicast application developers. In that context with historic multicast configurations, including DVMRP and PIM, the multicast spanning tree was far different than the unicast spanning tree. Therefore, the preliminary volley was important to estimate the offset of the multicast server to the multicast client and thus the apparent one-way delay. In principle, with adroit protocolmanship, it would be possible to change the protocol to measure the interleaved roundtrip delay, which would be more appropriate for modern high-speed Ethernet networks. > >Karen O'Donoghue wrote: > > > > > -------- Original Message -------- >Subject: [TICTOC] reminder for remote participation in today's tictoc meeting >Date: Thu, 31 Mar 2011 09:56:35 +0200 >From: Karen O'Donoghue >Reply-To: odonoghue@isoc.org >Organization: ISOC >To: tictoc@ietf.org, NTP Working Group > > > Folks, > > This is a reminder that the tictoc working group will meet today from > 17:40 - 19:40 CEST (15:40 - 17:40 UTC). The tools agenda for the IETF > meeting (http://tools.ietf.org/agenda/80/) has links for the drafts, > presentations, jabber chat room, and audio streaming to facilitate > remote participation. > > Regards, > Karen > > _______________________________________________ > TICTOC mailing list > TICTOC@ietf.org > https://www.ietf.org/mailman/listinfo/tictoc > > >________________________________ > > > _______________________________________________ > ntpwg mailing list > ntpwg@lists.ntp.org > http://lists.ntp.org/listinfo/ntpwg > > > > _______________________________________________ ntpwg mailing list ntpwg@lists.ntp.org http://lists.ntp.org/listinfo/ntpwg From ntpwg-bounces+ntp-archives-ahfae6za=lists.ietf.org@lists.ntp.org Mon Jul 30 22:59:33 2012 Return-Path: X-Original-To: ietfarch-ntp-archives-ahFae6za@ietfa.amsl.com Delivered-To: ietfarch-ntp-archives-ahFae6za@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 28DF511E810C for ; Mon, 30 Jul 2012 22:59:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -105.098 X-Spam-Level: X-Spam-Status: No, score=-105.098 tagged_above=-999 required=5 tests=[AWL=1.500, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id TpCT2KZGCpN0 for ; Mon, 30 Jul 2012 22:59:32 -0700 (PDT) Received: from lists.ntp.org (lists.ntp.org [IPv6:2001:4f8:fff7:1::7]) by ietfa.amsl.com (Postfix) with ESMTP id 0F2F511E80EE for ; Mon, 30 Jul 2012 22:59:28 -0700 (PDT) Received: from lists.ntp.org (lists.ntp.org [149.20.68.7]) by lists.ntp.org (Postfix) with ESMTP id 103A686D58F for ; Tue, 31 Jul 2012 05:59:28 +0000 (UTC) X-Original-To: ntpwg@lists.ntp.org Delivered-To: ntpwg@lists.ntp.org Received: from mail1.ntp.org (mail1.ntp.org [IPv6:2001:4f8:fff7:1::5]) by lists.ntp.org (Postfix) with ESMTP id 379D286D33D for ; Tue, 31 Jul 2012 05:28:37 +0000 (UTC) Received: from mail-pb0-f41.google.com ([209.85.160.41]) by mail1.ntp.org with esmtps (TLSv1:RC4-SHA:128) (Exim 4.77 (FreeBSD)) (envelope-from ) id 1Sw50V-000PsI-HJ for ntpwg@lists.ntp.org; Tue, 31 Jul 2012 05:28:37 +0000 Received: by pbbrp2 with SMTP id rp2so12559827pbb.14 for ; Mon, 30 Jul 2012 22:28:29 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=sender:message-id:date:from:reply-to:user-agent:mime-version:to :subject:references:in-reply-to:x-forwarded-message-id:content-type; bh=Ck2GXaBhMdgfCZjRhStOv1IbxHKv3j3j+GLvsBbIzlo=; b=BguXu/WA5fMZRgoeTCgW91lXQ+UfwE8bewcgwNxqvDDS3ccJt2/u5ptgQ5+Ls0ThXV gBC1N14/1BirLkg0MDJZEVjoGqh9NxjEvTVSlWPdzleuPJx0+wSahFhJfNfrLy7k4AlL 7dSHJ0Bh16xyP6NO2w+i9v/Re3+FCzCnzsyLMzIH9vlX2M4WzB0JKvaon/2cIPZZj7MO V6JnBj90a4pP8289Nw/FIBmTTTRii/wFUMPKv1uiSHk77C6XgDYHgDN4RioN2sBaySPO dAU1dxjeE9YetTS10inN0lB5QcuMH12EWitwgWaOqriYjmB6dQsXPqOs8xss32YSQ4d8 LoxQ== Received: by 10.68.200.101 with SMTP id jr5mr18646073pbc.9.1343712509558; Mon, 30 Jul 2012 22:28:29 -0700 (PDT) Received: from dhcp-45ce.meeting.ietf.org (dhcp-45ce.meeting.ietf.org. [130.129.69.206]) by mx.google.com with ESMTPS id wh7sm5751777pbc.33.2012.07.30.22.28.27 (version=SSLv3 cipher=OTHER); Mon, 30 Jul 2012 22:28:28 -0700 (PDT) Message-ID: <50176CF9.5090309@pobox.com> Date: Mon, 30 Jul 2012 22:28:25 -0700 From: Karen O'Donoghue User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:13.0) Gecko/20120614 Thunderbird/13.0.1 MIME-Version: 1.0 To: "tictoc@ietf.org" , NTP Working Group References: <20120730032233.17770.35790.idtracker@ietfa.amsl.com> In-Reply-To: <20120730032233.17770.35790.idtracker@ietfa.amsl.com> X-Forwarded-Message-Id: <20120730032233.17770.35790.idtracker@ietfa.amsl.com> X-SA-Exim-Connect-IP: 209.85.160.41 X-SA-Exim-Rcpt-To: ntpwg@lists.ntp.org X-SA-Exim-Mail-From: kodonog@gmail.com X-SA-Exim-Version: 4.2 X-SA-Exim-Scanned: Yes (on mail1.ntp.org) Subject: [ntpwg] Fwd: Need volunteers for the NomCom X-BeenThere: ntpwg@lists.ntp.org X-Mailman-Version: 2.1.14 Precedence: list Reply-To: kodonog@pobox.com List-Id: IETF Working Group for Network Time Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============5700715265153362768==" Errors-To: ntpwg-bounces+ntp-archives-ahfae6za=lists.ietf.org@lists.ntp.org Sender: ntpwg-bounces+ntp-archives-ahfae6za=lists.ietf.org@lists.ntp.org This is a multi-part message in MIME format. --===============5700715265153362768== Content-Type: multipart/alternative; boundary="------------030701050703050800070900" This is a multi-part message in MIME format. --------------030701050703050800070900 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Folks, Here's a reminder that the call for nomcom volunteers is open until the Sunday only. Thanks, Karen -------- Original Message -------- Subject: Need volunteers for the NomCom Date: Sun, 29 Jul 2012 20:22:33 -0700 From: NomCom Chair To: Working Group Chairs We are currently looking for volunteers to serve on the 2012-2013 NomCom. As you know, the success of the NomCom process depends crucially on having a large pool of volunteers from throughout the IETF community. In particular, it is valuable for the pool of volunteers to have strong representation from all of the technical areas within the IETF. I understand that not all IETF participants read the IETF announce list frequently. Therefore, if you would be willing to inform active participants in your working groups about this year's call for NomCom volunteers, I would greatly appreciate it. The NomCom 2012-2013 Call for Volunteers is open until this Sunday, August 5. Details can be found at: https://datatracker.ietf.org/ann/nomcom/49851/ Thank you for your help, - Matt Lepinski mlepinski.ietf@gmail.com nomcom-chair@ietf.org --------------030701050703050800070900 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: 7bit Folks,

Here's a reminder that the call for nomcom volunteers is open until the Sunday only.

Thanks,
Karen


-------- Original Message --------
Subject: Need volunteers for the NomCom
Date: Sun, 29 Jul 2012 20:22:33 -0700
From: NomCom Chair <nomcom-chair@ietf.org>
To: Working Group Chairs <wgchairs@ietf.org> 


We are currently looking for volunteers to serve on the 2012-2013 NomCom.
As you know, the success of the NomCom process depends crucially on 
having a large pool of volunteers from throughout the IETF community. 
In particular, it is valuable for the pool of volunteers to have strong 
representation from all of the technical areas within the IETF. 

I understand that not all IETF participants read the IETF announce list 
frequently. Therefore, if you would be willing to inform active participants 
in your working groups about this year's call for NomCom volunteers, I 
would greatly appreciate it. 

The NomCom 2012-2013 Call for Volunteers is open until this Sunday, 
August 5. Details can be found at: https://datatracker.ietf.org/ann/nomcom/49851/

Thank you for your help,
- Matt Lepinski
  mlepinski.ietf@gmail.com
  nomcom-chair@ietf.org



--------------030701050703050800070900-- --===============5700715265153362768== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ ntpwg mailing list ntpwg@lists.ntp.org http://lists.ntp.org/listinfo/ntpwg --===============5700715265153362768==-- From ntpwg-bounces+ntp-archives-ahfae6za=lists.ietf.org@lists.ntp.org Tue Jul 31 10:32:07 2012 Return-Path: X-Original-To: ietfarch-ntp-archives-ahFae6za@ietfa.amsl.com Delivered-To: ietfarch-ntp-archives-ahFae6za@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9A10221F87F9 for ; Tue, 31 Jul 2012 10:32:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -104.932 X-Spam-Level: X-Spam-Status: No, score=-104.932 tagged_above=-999 required=5 tests=[AWL=1.667, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ouC69ZbSRW03 for ; Tue, 31 Jul 2012 10:32:07 -0700 (PDT) Received: from lists.ntp.org (lists.ntp.org [149.20.68.7]) by ietfa.amsl.com (Postfix) with ESMTP id EF13B21F8746 for ; Tue, 31 Jul 2012 10:31:59 -0700 (PDT) Received: from lists.ntp.org (lists.ntp.org [149.20.68.7]) by lists.ntp.org (Postfix) with ESMTP id 7C44D86DAB4 for ; Tue, 31 Jul 2012 17:31:59 +0000 (UTC) X-Original-To: ntpwg@lists.ntp.org Delivered-To: ntpwg@lists.ntp.org Received: from mail1.ntp.org (mail1.ntp.org [IPv6:2001:4f8:fff7:1::5]) by lists.ntp.org (Postfix) with ESMTP id 88E5086D33D for ; Tue, 31 Jul 2012 16:43:15 +0000 (UTC) Received: from smtp128.dfw.emailsrvr.com ([67.192.241.128]) by mail1.ntp.org with esmtps (TLSv1:AES256-SHA:256) (Exim 4.77 (FreeBSD)) (envelope-from ) id 1SwFXK-0006ZY-O1 for ntpwg@lists.ntp.org; Tue, 31 Jul 2012 16:43:15 +0000 Received: from localhost (localhost.localdomain [127.0.0.1]) by smtp22.relay.dfw1a.emailsrvr.com (SMTP Server) with ESMTP id C920C170BAB; Tue, 31 Jul 2012 12:43:04 -0400 (EDT) X-Virus-Scanned: OK Received: by smtp22.relay.dfw1a.emailsrvr.com (Authenticated sender: odonoghue-AT-isoc.org) with ESMTPSA id 845EF17054E; Tue, 31 Jul 2012 12:43:04 -0400 (EDT) Message-ID: <50180B17.2040805@isoc.org> Date: Tue, 31 Jul 2012 09:43:03 -0700 From: Karen O'Donoghue Organization: ISOC User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:13.0) Gecko/20120614 Thunderbird/13.0.1 MIME-Version: 1.0 To: "tictoc@ietf.org" , NTP Working Group X-SA-Exim-Connect-IP: 67.192.241.128 X-SA-Exim-Rcpt-To: ntpwg@lists.ntp.org X-SA-Exim-Mail-From: odonoghue@isoc.org X-SA-Exim-Version: 4.2 X-SA-Exim-Scanned: Yes (on mail1.ntp.org) Subject: [ntpwg] reminder for remote participants, ntp/tictoc meeting, 1300 PDT (2000 UTC) X-BeenThere: ntpwg@lists.ntp.org X-Mailman-Version: 2.1.14 Precedence: list Reply-To: odonoghue@isoc.org List-Id: IETF Working Group for Network Time Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed" Errors-To: ntpwg-bounces+ntp-archives-ahfae6za=lists.ietf.org@lists.ntp.org Sender: ntpwg-bounces+ntp-archives-ahfae6za=lists.ietf.org@lists.ntp.org Folks, This is just a quick reminder for any remote participants that the tictoc and ntp working groups will be meeting jointly later today at 1:00 pm PDT (8:00 pm UTC) here at IETF84. Links to the audio stream and the jabber group are available on the following agenda page: http://tools.ietf.org/agenda/84/ Karen _______________________________________________ ntpwg mailing list ntpwg@lists.ntp.org http://lists.ntp.org/listinfo/ntpwg