From nobody Mon Oct 2 00:00:24 2017 Return-Path: X-Original-To: ntp@ietfa.amsl.com Delivered-To: ntp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6435E134D66 for ; Mon, 2 Oct 2017 00:00:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.8 X-Spam-Level: X-Spam-Status: No, score=0.8 tagged_above=-999 required=5 tests=[BAYES_50=0.8, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fyyacqR4FlkH for ; Mon, 2 Oct 2017 00:00:22 -0700 (PDT) Received: from chessie.everett.org (chessie.everett.org [IPv6:2001:470:1:205::234]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id BF1F0134DCE for ; Mon, 2 Oct 2017 00:00:21 -0700 (PDT) Received: from hms-mbp11.pfcs.com (96-41-166-181.dhcp.mdfd.or.charter.com [96.41.166.181]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by chessie.everett.org (Postfix) with ESMTPSA id 12E03B992; Mon, 2 Oct 2017 07:00:20 +0000 (UTC) To: "ntp@ietf.org" From: Harlan Stenn Message-ID: Date: Mon, 2 Oct 2017 00:00:19 -0700 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.12; rv:52.0) Gecko/20100101 Thunderbird/52.3.0 MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 7bit Archived-At: Subject: [Ntp] Updates to draft-stenn-ntp-extension-fields X-BeenThere: ntp@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 02 Oct 2017 07:00:23 -0000 Folks, I've updated https://github.com/hstenn/ietf-ntp-extension-field.git to include my pseudocde examples, clean up some sentences, and copy/clarify parts of RFC5906 over to RFC5905. It probably needs more polish before I update it to -03, but it should be pretty close. Feedback welcome. -- Harlan Stenn http://networktimefoundation.org - be a member! From nobody Mon Oct 2 06:38:23 2017 Return-Path: X-Original-To: ntp@ietfa.amsl.com Delivered-To: ntp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 000D0134647 for ; Mon, 2 Oct 2017 06:38:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.021 X-Spam-Level: X-Spam-Status: No, score=-5.021 tagged_above=-999 required=5 tests=[BAYES_40=-0.001, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 61YIkcBuE9td for ; Mon, 2 Oct 2017 06:38:20 -0700 (PDT) Received: from mx1.redhat.com (mx1.redhat.com [209.132.183.28]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8F2F8134646 for ; Mon, 2 Oct 2017 06:38:20 -0700 (PDT) Received: from smtp.corp.redhat.com (int-mx05.intmail.prod.int.phx2.redhat.com [10.5.11.15]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.redhat.com (Postfix) with ESMTPS id 971425F7B7; Mon, 2 Oct 2017 13:38:19 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.3.2 mx1.redhat.com 971425F7B7 Authentication-Results: ext-mx10.extmail.prod.ext.phx2.redhat.com; dmarc=none (p=none dis=none) header.from=redhat.com Authentication-Results: ext-mx10.extmail.prod.ext.phx2.redhat.com; spf=fail smtp.mailfrom=mlichvar@redhat.com Received: from localhost (unknown [10.43.2.117]) by smtp.corp.redhat.com (Postfix) with ESMTPS id CF118841C0; Mon, 2 Oct 2017 13:38:18 +0000 (UTC) Date: Mon, 2 Oct 2017 15:38:17 +0200 From: Miroslav Lichvar To: Harlan Stenn Cc: "ntp@ietf.org" Message-ID: <20171002133817.GA30411@localhost> References: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.8.3 (2017-05-23) X-Scanned-By: MIMEDefang 2.79 on 10.5.11.15 X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.5.16 (mx1.redhat.com [10.5.110.39]); Mon, 02 Oct 2017 13:38:19 +0000 (UTC) Archived-At: Subject: Re: [Ntp] Updates to draft-stenn-ntp-extension-fields X-BeenThere: ntp@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 02 Oct 2017 13:38:23 -0000 On Mon, Oct 02, 2017 at 12:00:19AM -0700, Harlan Stenn wrote: > Folks, > > I've updated https://github.com/hstenn/ietf-ntp-extension-field.git to > include my pseudocde examples, clean up some sentences, and copy/clarify > parts of RFC5906 over to RFC5905. Before we get back to the discussion about reserving the highest bits of the EF type field for EF-specific purposes and requiring parsers to have access to keys, I'd like to point out that this proposal is not consistent with the current use of EF types in the reference implementation. If the type field is shortened to 8 bits, ntpd will use types 0-9, and the leapseconds EF (type 5) will conflict with the checksum complement EF. -- Miroslav Lichvar From nobody Mon Oct 2 09:06:40 2017 Return-Path: X-Original-To: ntp@ietfa.amsl.com Delivered-To: ntp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 258B413293A for ; Mon, 2 Oct 2017 09:06:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ei8fY5c3iwqX for ; Mon, 2 Oct 2017 09:06:38 -0700 (PDT) Received: from chessie.everett.org (chessie.everett.org [IPv6:2001:470:1:205::234]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 04EBC13234B for ; Mon, 2 Oct 2017 09:06:37 -0700 (PDT) Received: from [10.66.3.3] (96-41-166-181.dhcp.mdfd.or.charter.com [96.41.166.181]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by chessie.everett.org (Postfix) with ESMTPSA id 216F2B837; Mon, 2 Oct 2017 16:06:37 +0000 (UTC) To: Miroslav Lichvar Cc: "ntp@ietf.org" References: <20171002133817.GA30411@localhost> From: Harlan Stenn Message-ID: Date: Mon, 2 Oct 2017 09:06:37 -0700 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.3.0 MIME-Version: 1.0 In-Reply-To: <20171002133817.GA30411@localhost> Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 8bit Archived-At: Subject: Re: [Ntp] Updates to draft-stenn-ntp-extension-fields X-BeenThere: ntp@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 02 Oct 2017 16:06:39 -0000 On 10/2/2017 6:38 AM, Miroslav Lichvar wrote: > On Mon, Oct 02, 2017 at 12:00:19AM -0700, Harlan Stenn wrote: >> Folks, >> >> I've updated https://github.com/hstenn/ietf-ntp-extension-field.git to >> include my pseudocde examples, clean up some sentences, and copy/clarify >> parts of RFC5906 over to RFC5905. > > Before we get back to the discussion about reserving the highest bits > of the EF type field for EF-specific purposes and requiring parsers to > have access to keys, I'd like to point out that this proposal is not > consistent with the current use of EF types in the reference > implementation. > > If the type field is shortened to 8 bits, ntpd will use types 0-9, and > the leapseconds EF (type 5) will conflict with the checksum complement > EF. The leapseconds Code 5 is an Autokey (EF Type 2) subtype. From RFC 5906: 0x0502 (Autokey) Lepaseconds Value Message Request 0x8502 (Autokey) Lepaseconds Value Message Response 0xC502 (Autokey) Lepaseconds Value Message Error Response and the Checksum Complement is: 0x2005 Checksum Complement. In 5906, the first octet used the leftmost 2 bits for flags, and the rightmost bits for the code. The EF type was the 2nd octet. The new proposal uses the leftmost 4 bits for flags, and the rightmost bits are still for the code. It's just that there are now only 4 bits available for the code. This shouldn't be a problem as that gives us 16 types per EF Type, and we've never used more than 10 before. If we have an EF Type that wants more than 16 Codes, we just need to use 2 (or more) types for it. From what has been suggested so far, this won't be an issue. NTS should be looking for 4 or 5 codes. The Extended Information EF proposal uses 1, and if/when it grows it has 14 more opportunities. This reduction from potentially 64 codes to 16 codes doesn't appear to be an issue. Does this make sense? Am I missing something? -- Harlan Stenn, Network Time Foundation http://nwtime.org - be a Member! From nobody Tue Oct 3 01:00:36 2017 Return-Path: X-Original-To: ntp@ietfa.amsl.com Delivered-To: ntp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6E13B134B2E for ; Tue, 3 Oct 2017 01:00:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.921 X-Spam-Level: X-Spam-Status: No, score=-6.921 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rIYEkj8HeGaA for ; Tue, 3 Oct 2017 01:00:26 -0700 (PDT) Received: from mx1.redhat.com (mx1.redhat.com [209.132.183.28]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5609B134317 for ; Tue, 3 Oct 2017 01:00:16 -0700 (PDT) Received: from smtp.corp.redhat.com (int-mx04.intmail.prod.int.phx2.redhat.com [10.5.11.14]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.redhat.com (Postfix) with ESMTPS id 8C555914EB; Tue, 3 Oct 2017 08:00:15 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.3.2 mx1.redhat.com 8C555914EB Authentication-Results: ext-mx02.extmail.prod.ext.phx2.redhat.com; dmarc=none (p=none dis=none) header.from=redhat.com Authentication-Results: ext-mx02.extmail.prod.ext.phx2.redhat.com; spf=fail smtp.mailfrom=mlichvar@redhat.com Received: from localhost (unknown [10.43.2.117]) by smtp.corp.redhat.com (Postfix) with ESMTPS id CBEB85D728; Tue, 3 Oct 2017 08:00:14 +0000 (UTC) Date: Tue, 3 Oct 2017 10:00:13 +0200 From: Miroslav Lichvar To: Harlan Stenn Cc: "ntp@ietf.org" Message-ID: <20171003080013.GD30411@localhost> References: <20171002133817.GA30411@localhost> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.8.3 (2017-05-23) X-Scanned-By: MIMEDefang 2.79 on 10.5.11.14 X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.5.16 (mx1.redhat.com [10.5.110.26]); Tue, 03 Oct 2017 08:00:15 +0000 (UTC) Archived-At: Subject: Re: [Ntp] Updates to draft-stenn-ntp-extension-fields X-BeenThere: ntp@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 03 Oct 2017 08:00:28 -0000 On Mon, Oct 02, 2017 at 09:06:37AM -0700, Harlan Stenn wrote: > On 10/2/2017 6:38 AM, Miroslav Lichvar wrote: > > If the type field is shortened to 8 bits, ntpd will use types 0-9, and > > the leapseconds EF (type 5) will conflict with the checksum complement > > EF. > > The leapseconds Code 5 is an Autokey (EF Type 2) subtype. From RFC 5906: > > 0x0502 (Autokey) Lepaseconds Value Message Request > 0x8502 (Autokey) Lepaseconds Value Message Response > 0xC502 (Autokey) Lepaseconds Value Message Error Response This is in the RFC and IANA registry, but it's not what ntpd is actually using. We discussed this before. Check the include/ntp_crypto.h file in the distribution. -- Miroslav Lichvar From nobody Tue Oct 3 02:00:51 2017 Return-Path: X-Original-To: ntp@ietfa.amsl.com Delivered-To: ntp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6547D134C1B for ; Tue, 3 Oct 2017 02:00:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id j_7FcQX5yWtO for ; Tue, 3 Oct 2017 02:00:48 -0700 (PDT) Received: from chessie.everett.org (chessie.everett.org [66.220.13.234]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1F09D134BFD for ; Tue, 3 Oct 2017 02:00:48 -0700 (PDT) Received: from hms-mbp11.pfcs.com (96-41-166-181.dhcp.mdfd.or.charter.com [96.41.166.181]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by chessie.everett.org (Postfix) with ESMTPSA id 502C4B835; Tue, 3 Oct 2017 09:00:47 +0000 (UTC) To: Miroslav Lichvar Cc: "ntp@ietf.org" References: <20171002133817.GA30411@localhost> <20171003080013.GD30411@localhost> From: Harlan Stenn Message-ID: Date: Tue, 3 Oct 2017 02:00:46 -0700 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.12; rv:52.0) Gecko/20100101 Thunderbird/52.3.0 MIME-Version: 1.0 In-Reply-To: <20171003080013.GD30411@localhost> Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 8bit Archived-At: Subject: Re: [Ntp] Updates to draft-stenn-ntp-extension-fields X-BeenThere: ntp@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 03 Oct 2017 09:00:49 -0000 On 10/3/17 1:00 AM, Miroslav Lichvar wrote: > On Mon, Oct 02, 2017 at 09:06:37AM -0700, Harlan Stenn wrote: >> On 10/2/2017 6:38 AM, Miroslav Lichvar wrote: >>> If the type field is shortened to 8 bits, ntpd will use types 0-9, and >>> the leapseconds EF (type 5) will conflict with the checksum complement >>> EF. >> >> The leapseconds Code 5 is an Autokey (EF Type 2) subtype. From RFC 5906: >> >> 0x0502 (Autokey) Lepaseconds Value Message Request >> 0x8502 (Autokey) Lepaseconds Value Message Response >> 0xC502 (Autokey) Lepaseconds Value Message Error Response > > This is in the RFC and IANA registry, but it's not what ntpd is > actually using. We discussed this before. Check the > include/ntp_crypto.h file in the distribution. I haven't looked at a packet trace in a long time. The code says: /* * Extension field definitions */ #define CRYPTO_MAXLEN 1024 /* max extension field length */ #define CRYPTO_VN 2 /* current protocol version number */ #define CRYPTO_CMD(x) (((CRYPTO_VN << 8) | (x)) << 16) #define CRYPTO_NULL CRYPTO_CMD(0) /* no operation */ #define CRYPTO_ASSOC CRYPTO_CMD(1) /* association */ #define CRYPTO_CERT CRYPTO_CMD(2) /* certificate */ #define CRYPTO_COOK CRYPTO_CMD(3) /* cookie value */ #define CRYPTO_AUTO CRYPTO_CMD(4) /* autokey values */ #define CRYPTO_LEAP CRYPTO_CMD(5) /* leapsecond values */ #define CRYPTO_SIGN CRYPTO_CMD(6) /* certificate sign */ #define CRYPTO_IFF CRYPTO_CMD(7) /* IFF identity scheme */ #define CRYPTO_GQ CRYPTO_CMD(8) /* GQ identity scheme */ #define CRYPTO_MV CRYPTO_CMD(9) /* MV identity scheme */ #define CRYPTO_RESP 0x80000000 /* response */ #define CRYPTO_ERROR 0x40000000 /* error */ In the code above, VN (2) is the Autokey EF type. So this code produces an internal format of high-order 8 bits of the EF type, and the low order 8 bits of the "code" field, shifted left by 16 bits for the length. I have not looked to see if this is a big-endian/little endian thing (almost certainly not, but I wanted to mention it for thoroughness), or if it's an internal representation v. an external representation thing (far more likely, and probably not the way I would have written it). And it may be a bug. If it's a bug in the code, the good news is that with NTS on the horizon and https://tools.ietf.org/html/draft-stenn-ntp-extended-information-00, which specifically includes a way to get the TAI offset, there should soon be no need for Autokey. But to start using a new idom, we could just as easily talk about: 2.0 Autokey: No-op 2.1 Autokey: Assoc ... 2.5 Autokey: leapsecond ... 2.9 Autokey: MV identity 3.0 MAC-EF 4.0 NTS 4.1 NTS whatever1 4.2 NTS whatever2 ... 5.0 Checksum Complement 6.0 Suggested REFID 7.0 I-DO 8.0 LAST-EF 9.1 Extended Information (suggestion) and aside from this, we're looking at whether or not there's a bug in the code. If so, it hasn't been reported, and that code is over 16 years' old. We're looking at this, thanks! -- Harlan Stenn http://networktimefoundation.org - be a member! From nobody Tue Oct 10 09:52:54 2017 Return-Path: X-Original-To: ntp@ietf.org Delivered-To: ntp@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 3E073133055; Tue, 10 Oct 2017 09:52:52 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: IETF Meeting Session Request Tool To: Cc: ntp-chairs@ietf.org, ntp@ietf.org, suresh@kaloom.com, smccammon@amsl.com X-Test-IDTracker: no X-IETF-IDTracker: 6.63.1 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <150765437220.13583.11721328089430860937.idtracker@ietfa.amsl.com> Date: Tue, 10 Oct 2017 09:52:52 -0700 Archived-At: Subject: [Ntp] ntp - Update to a Meeting Session Request for IETF 100 X-BeenThere: ntp@ietf.org X-Mailman-Version: 2.1.22 List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 10 Oct 2017 16:52:52 -0000 An update to a meeting session request has just been submitted by Stephanie McCammon, on behalf of the ntp working group. --------------------------------------------------------- Working Group Name: Network Time Protocol Area Name: Internet Area Session Requester: Stephanie McCammon Number of Sessions: 1 Length of Session(s): 2 Hours Number of Attendees: 30 Conflicts to Avoid: First Priority: oauth sacm saag cfrg tls trans ippm bmwg detnet acme ace People who must be present: Karen O'Donoghue Suresh Krishnan Dieter Sibold Resources Requested: Special Requests: Please schedule jointly with the tictoc wg. Also, we would prefer a morning slot if possible because of regular remote participants from the US. --------------------------------------------------------- From nobody Mon Oct 16 00:38:23 2017 Return-Path: X-Original-To: ntp@ietfa.amsl.com Delivered-To: ntp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8D4D2134457 for ; Mon, 16 Oct 2017 00:38:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.799 X-Spam-Level: X-Spam-Status: No, score=-2.799 tagged_above=-999 required=5 tests=[BAYES_05=-0.5, RCVD_IN_DNSWL_MED=-2.3, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wBH5tdMONSrr for ; Mon, 16 Oct 2017 00:38:20 -0700 (PDT) Received: from rrzmta1.uni-regensburg.de (rrzmta1.uni-regensburg.de [194.94.155.51]) (using TLSv1 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D9ED4134338 for ; Mon, 16 Oct 2017 00:38:19 -0700 (PDT) Received: from rrzmta1.uni-regensburg.de (localhost [127.0.0.1]) by localhost (Postfix) with SMTP id B0ADE5DD8C for ; Mon, 16 Oct 2017 09:38:17 +0200 (CEST) Received: from gwsmtp1.uni-regensburg.de (gwsmtp1.uni-regensburg.de [132.199.5.51]) by rrzmta1.uni-regensburg.de (Postfix) with ESMTP id 61FCD5E001 for ; Mon, 16 Oct 2017 09:38:01 +0200 (CEST) Received: from uni-regensburg-smtp1-MTA by gwsmtp1.uni-regensburg.de with Novell_GroupWise; Mon, 16 Oct 2017 09:31:12 +0200 Message-Id: <59E4603E020000A1000285FC@gwsmtp1.uni-regensburg.de> X-Mailer: Novell GroupWise Internet Agent 14.2.2 Date: Mon, 16 Oct 2017 09:31:10 +0200 From: "Ulrich Windl" To: Cc: "ntp@ietf.org" References: <20171002133817.GA30411@localhost> In-Reply-To: Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: quoted-printable Content-Disposition: inline Archived-At: Subject: [Ntp] Antw: Re: Updates to draft-stenn-ntp-extension-fields X-BeenThere: ntp@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 16 Oct 2017 07:38:22 -0000 >>> Harlan Stenn schrieb am 02.10.2017 um 18:06 in = Nachricht : >=20 > On 10/2/2017 6:38 AM, Miroslav Lichvar wrote: >> On Mon, Oct 02, 2017 at 12:00:19AM -0700, Harlan Stenn wrote: >>> Folks, >>> >>> I've updated https://github.com/hstenn/ietf-ntp-extension-field.git to >>> include my pseudocde examples, clean up some sentences, and copy/clarif= y >>> parts of RFC5906 over to RFC5905. >>=20 >> Before we get back to the discussion about reserving the highest bits >> of the EF type field for EF-specific purposes and requiring parsers to >> have access to keys, I'd like to point out that this proposal is not >> consistent with the current use of EF types in the reference >> implementation. >>=20 >> If the type field is shortened to 8 bits, ntpd will use types 0-9, and >> the leapseconds EF (type 5) will conflict with the checksum complement >> EF. >=20 > The leapseconds Code 5 is an Autokey (EF Type 2) subtype. From RFC = 5906: >=20 > 0x0502 (Autokey) Lepaseconds Value Message Request > 0x8502 (Autokey) Lepaseconds Value Message Response > 0xC502 (Autokey) Lepaseconds Value Message Error Response >=20 > and the Checksum Complement is: >=20 > 0x2005 Checksum Complement. >=20 > In 5906, the first octet used the leftmost 2 bits for flags, and the > rightmost bits for the code. The EF type was the 2nd octet. >=20 > The new proposal uses the leftmost 4 bits for flags, and the rightmost > bits are still for the code. It's just that there are now only 4 bits > available for the code. This shouldn't be a problem as that gives us 16 > types per EF Type, and we've never used more than 10 before. If we have > an EF Type that wants more than 16 Codes, we just need to use 2 (or > more) types for it. From what has been suggested so far, this won't be > an issue. NTS should be looking for 4 or 5 codes. The Extended > Information EF proposal uses 1, and if/when it grows it has 14 more > opportunities. >=20 > This reduction from potentially 64 codes to 16 codes doesn't appear to > be an issue. What I absolutely dislike on this specification is that the extension = field's specification is like 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |R|E| Code | Field Type | Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ but you register (R,E,Code, and Field Type) just as one opaque number = (actually more than one due to flags being included). Now you are = suggesting to change the field widths. This would give the numbers already = registered a new meaning. Also, according to the specification "Field = Type" is asically the NTP autokey version. Why have 8 bits for the = version, but only 4 bits for the field? Can't you put additional flags = elsewhere? >=20 > Does this make sense? Am I missing something? I didn't have time to read the whole revised specification. Regards, Ulrich > --=20 > Harlan Stenn, Network Time Foundation > http://nwtime.org - be a Member! >=20 > _______________________________________________ > ntp mailing list > ntp@ietf.org=20 > https://www.ietf.org/mailman/listinfo/ntp=20 From nobody Mon Oct 16 01:05:45 2017 Return-Path: X-Original-To: ntp@ietfa.amsl.com Delivered-To: ntp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5AC4113235C for ; Mon, 16 Oct 2017 01:05:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id TOQeBArvzXxB for ; Mon, 16 Oct 2017 01:05:42 -0700 (PDT) Received: from chessie.everett.org (chessie.everett.org [IPv6:2001:470:1:205::234]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1D1AE1320D9 for ; Mon, 16 Oct 2017 01:05:42 -0700 (PDT) Received: from [10.66.3.3] (96-41-166-181.dhcp.mdfd.or.charter.com [96.41.166.181]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by chessie.everett.org (Postfix) with ESMTPSA id A11B4B871; Mon, 16 Oct 2017 08:05:41 +0000 (UTC) To: Ulrich Windl Cc: "ntp@ietf.org" References: <20171002133817.GA30411@localhost> <59E4603E020000A1000285FC@gwsmtp1.uni-regensburg.de> From: Harlan Stenn Message-ID: Date: Mon, 16 Oct 2017 01:05:40 -0700 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.4.0 MIME-Version: 1.0 In-Reply-To: <59E4603E020000A1000285FC@gwsmtp1.uni-regensburg.de> Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 8bit Archived-At: Subject: Re: [Ntp] Antw: Re: Updates to draft-stenn-ntp-extension-fields X-BeenThere: ntp@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 16 Oct 2017 08:05:44 -0000 On 10/16/2017 12:31 AM, Ulrich Windl wrote: >>>> Harlan Stenn schrieb am 02.10.2017 um 18:06 in Nachricht > : > >> >> On 10/2/2017 6:38 AM, Miroslav Lichvar wrote: >>> On Mon, Oct 02, 2017 at 12:00:19AM -0700, Harlan Stenn wrote: >>>> Folks, >>>> >>>> I've updated https://github.com/hstenn/ietf-ntp-extension-field.git to >>>> include my pseudocde examples, clean up some sentences, and copy/clarify >>>> parts of RFC5906 over to RFC5905. >>> >>> Before we get back to the discussion about reserving the highest bits >>> of the EF type field for EF-specific purposes and requiring parsers to >>> have access to keys, I'd like to point out that this proposal is not >>> consistent with the current use of EF types in the reference >>> implementation. >>> >>> If the type field is shortened to 8 bits, ntpd will use types 0-9, and >>> the leapseconds EF (type 5) will conflict with the checksum complement >>> EF. >> >> The leapseconds Code 5 is an Autokey (EF Type 2) subtype. From RFC 5906: >> >> 0x0502 (Autokey) Lepaseconds Value Message Request >> 0x8502 (Autokey) Lepaseconds Value Message Response >> 0xC502 (Autokey) Lepaseconds Value Message Error Response >> >> and the Checksum Complement is: >> >> 0x2005 Checksum Complement. >> >> In 5906, the first octet used the leftmost 2 bits for flags, and the >> rightmost bits for the code. The EF type was the 2nd octet. >> >> The new proposal uses the leftmost 4 bits for flags, and the rightmost >> bits are still for the code. It's just that there are now only 4 bits >> available for the code. This shouldn't be a problem as that gives us 16 >> types per EF Type, and we've never used more than 10 before. If we have >> an EF Type that wants more than 16 Codes, we just need to use 2 (or >> more) types for it. From what has been suggested so far, this won't be >> an issue. NTS should be looking for 4 or 5 codes. The Extended >> Information EF proposal uses 1, and if/when it grows it has 14 more >> opportunities. >> >> This reduction from potentially 64 codes to 16 codes doesn't appear to >> be an issue. > > What I absolutely dislike on this specification is that the extension field's specification is like > 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > |R|E| Code | Field Type | Length | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > > but you register (R,E,Code, and Field Type) just as one opaque number (actually more than one due to flags being included). Now you are suggesting to change the field widths. This would give the numbers already registered a new meaning. Also, according to the specification "Field Type" is asically the NTP autokey version. Why have 8 bits for the version, but only 4 bits for the field? Can't you put additional flags elsewhere? Nothing changes with the already registered numbers. The only numbers already allocated are for Autokey, and they are not affected by this change. OK, there's also the experimental Checksum Complement EF, but that number was assigned with the proposed changes in mind, as it uses the "MAC Optional" flag bit. If you want to look at is as Field Type 1 was Autokey V1, and Field Type 2 is Autokey V2, that's fine with me. It is not "generic versions". The values 1-7 were thought of as the Autokey version field 10 years' ago, but not in a "concrete" way. Even if you want to make that argument, that leaves ~248 more Field Types allowed for use by "other than Autokey". I don't know where you're getting "4 bits for the field". I think you mean "4 bits for the code", and that gives 16 sub-codes for each Field Type. >From everything I've seen, this works out just fine. The Field Type list I'm working from says: 0x0002 Autokey V2 0x0003 MAC Extension Field 0x0004 NTS 0x0005 Checksum Complement ... 0x0009 Extended Information 0x1000 MAC included 0x2000 MAC optional 0x4000 Error 0x8000 Response Additional values for I-DO payload: 0xFFFE I-DO Leap Smear REFIDs 0xFFFF I-DO IPv6 REFID hash H -- >> >> Does this make sense? Am I missing something? > > I didn't have time to read the whole revised specification. > > Regards, > Ulrich > >> -- >> Harlan Stenn, Network Time Foundation >> http://nwtime.org - be a Member! >> >> _______________________________________________ >> ntp mailing list >> ntp@ietf.org >> https://www.ietf.org/mailman/listinfo/ntp > > > > > -- Harlan Stenn, Network Time Foundation http://nwtime.org - be a Member! From nobody Thu Oct 26 02:56:05 2017 Return-Path: X-Original-To: ntp@ietf.org Delivered-To: ntp@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 2BC371344A9; Fri, 20 Oct 2017 17:24:16 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: "\"IETF Secretariat\"" To: , Cc: ntp@ietf.org, suresh@kaloom.com X-Test-IDTracker: no X-IETF-IDTracker: 6.63.2 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <150854545617.20809.16423490643049613357.idtracker@ietfa.amsl.com> Date: Fri, 20 Oct 2017 17:24:16 -0700 Archived-At: X-Mailman-Approved-At: Thu, 26 Oct 2017 02:56:04 -0700 Subject: [Ntp] ntp - Requested session has been scheduled for IETF 100 X-BeenThere: ntp@ietf.org X-Mailman-Version: 2.1.22 List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 21 Oct 2017 00:24:16 -0000 Dear Karen O'Donoghue, The session(s) that you have requested have been scheduled. Below is the scheduled session information followed by the original request. ntp Session 1 (2:00:00) Monday, Afternoon Session I 1330-1530 Room Name: VIP A size: 100 --------------------------------------------- Special Note: Joint session with TICTOC Request Information: --------------------------------------------------------- Working Group Name: Network Time Protocol Area Name: Internet Area Session Requester: Karen O'Donoghue Number of Sessions: 1 Length of Session(s): 2 Hours Number of Attendees: 30 Conflicts to Avoid: First Priority: ace acme detnet bmwg ippm trans tls cfrg saag sacm oauth People who must be present: Karen O'Donoghue Suresh Krishnan Dieter Sibold Karen O'Donoghue Suresh Krishnan Dieter Sibold Resources Requested: Special Requests: Please schedule jointly with the tictoc wg. Also, we would prefer a morning slot if possible because of regular remote participants from the US. --------------------------------------------------------- From nobody Thu Oct 26 09:47:43 2017 Return-Path: X-Original-To: ntp@ietf.org Delivered-To: ntp@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 554A013F5CB; Thu, 26 Oct 2017 09:47:41 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: Cc: ntp@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.63.2 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <150903646127.24084.10360230606128354472@ietfa.amsl.com> Date: Thu, 26 Oct 2017 09:47:41 -0700 Archived-At: Subject: [Ntp] I-D Action: draft-ietf-ntp-packet-timestamps-00.txt X-BeenThere: ntp@ietf.org X-Mailman-Version: 2.1.22 List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 26 Oct 2017 16:47:41 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Network Time Protocol WG of the IETF. Title : Guidelines for Defining Packet Timestamps Authors : Tal Mizrahi Joachim Fabini Al Morton Filename : draft-ietf-ntp-packet-timestamps-00.txt Pages : 14 Date : 2017-10-26 Abstract: This document specifies guidelines for defining binary packet timestamp formats in networking protocols at various layers. It also presents three recommended timestamp formats. The target audience of this memo includes network protocol designers. It is expected that a new network protocol that requires a packet timestamp will, in most cases, use one of the recommended timestamp formats. If none of the recommended formats fits the protocol requirements, the new protocol specification should specify the format of the packet timestamp according to the guidelines in this document. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-ntp-packet-timestamps/ There are also htmlized versions available at: https://tools.ietf.org/html/draft-ietf-ntp-packet-timestamps-00 https://datatracker.ietf.org/doc/html/draft-ietf-ntp-packet-timestamps-00 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Sat Oct 28 01:42:52 2017 Return-Path: X-Original-To: ntp@ietf.org Delivered-To: ntp@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 3E3B913F5F6; Sat, 28 Oct 2017 01:42:50 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: Cc: ntp@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.63.2 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <150918017021.2767.5190940800985405391@ietfa.amsl.com> Date: Sat, 28 Oct 2017 01:42:50 -0700 Archived-At: Subject: [Ntp] I-D Action: draft-ietf-ntp-yang-data-model-01.txt X-BeenThere: ntp@ietf.org X-Mailman-Version: 2.1.22 List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 28 Oct 2017 08:42:50 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Network Time Protocol WG of the IETF. Title : A YANG Data Model for NTP Authors : Nan Wu Anil Kumar S N Yi Zhao Dhruv Dhody Ankit kumar Sinha Filename : draft-ietf-ntp-yang-data-model-01.txt Pages : 43 Date : 2017-10-28 Abstract: This document defines a YANG data model for Network Time Protocol implementations. The data model includes configuration data and state data. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-ntp-yang-data-model/ There are also htmlized versions available at: https://tools.ietf.org/html/draft-ietf-ntp-yang-data-model-01 https://datatracker.ietf.org/doc/html/draft-ietf-ntp-yang-data-model-01 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-ntp-yang-data-model-01 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Mon Oct 30 11:29:06 2017 Return-Path: X-Original-To: ntp@ietf.org Delivered-To: ntp@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 5FDF913F5A8; Mon, 30 Oct 2017 11:29:04 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: Cc: ntp@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.63.2 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <150938814435.7882.1040431566088833394@ietfa.amsl.com> Date: Mon, 30 Oct 2017 11:29:04 -0700 Archived-At: Subject: [Ntp] I-D Action: draft-ietf-ntp-using-nts-for-ntp-10.txt X-BeenThere: ntp@ietf.org X-Mailman-Version: 2.1.22 List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 30 Oct 2017 18:29:04 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Network Time Protocol WG of the IETF. Title : Network Time Security for the Network Time Protocol Authors : Daniel Fox Franke Dieter Sibold Kristof Teichel Filename : draft-ietf-ntp-using-nts-for-ntp-10.txt Pages : 27 Date : 2017-10-30 Abstract: This memo specifies Network Time Security (NTS), a mechanism for using Transport Layer Security (TLS) and Authenticated Encryption with Associated Data (AEAD) to provide cryptographic security for the Network Time Protocol. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-ntp-using-nts-for-ntp/ There are also htmlized versions available at: https://tools.ietf.org/html/draft-ietf-ntp-using-nts-for-ntp-10 https://datatracker.ietf.org/doc/html/draft-ietf-ntp-using-nts-for-ntp-10 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-ntp-using-nts-for-ntp-10 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Mon Oct 30 12:48:37 2017 Return-Path: X-Original-To: ntp@ietf.org Delivered-To: ntp@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id B7A7913FAF0; Mon, 30 Oct 2017 12:48:35 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: Cc: ntp@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.63.2 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <150939291573.7748.7204061647170712817@ietfa.amsl.com> Date: Mon, 30 Oct 2017 12:48:35 -0700 Archived-At: Subject: [Ntp] I-D Action: draft-ietf-ntp-mac-02.txt X-BeenThere: ntp@ietf.org X-Mailman-Version: 2.1.22 List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 30 Oct 2017 19:48:36 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Network Time Protocol WG of the IETF. Title : Message Authentication Code for the Network Time Protocol Authors : Aanchal Malhotra Sharon Goldberg Filename : draft-ietf-ntp-mac-02.txt Pages : 4 Date : 2017-10-30 Abstract: RFC 5905 [RFC5905] states that Network Time Protocol (NTP) packets should be authenticated by appending a 128-bit key to the NTP data, and hashing the result with MD5 to obtain a 128-bit tag. This document deprecates MD5-based authentication, which is considered to be too weak, and recommends the use of AES-CMAC [RFC4493] as a replacement. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-ntp-mac/ There are also htmlized versions available at: https://tools.ietf.org/html/draft-ietf-ntp-mac-02 https://datatracker.ietf.org/doc/html/draft-ietf-ntp-mac-02 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-ntp-mac-02 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Mon Oct 30 12:54:03 2017 Return-Path: X-Original-To: ntp@ietf.org Delivered-To: ntp@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 05BF713FB0A; Mon, 30 Oct 2017 12:54:02 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: Cc: ntp@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.63.2 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <150939324198.7886.1306469755415565041@ietfa.amsl.com> Date: Mon, 30 Oct 2017 12:54:02 -0700 Archived-At: Subject: [Ntp] I-D Action: draft-ietf-ntp-mac-03.txt X-BeenThere: ntp@ietf.org X-Mailman-Version: 2.1.22 List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 30 Oct 2017 19:54:02 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Network Time Protocol WG of the IETF. Title : Message Authentication Code for the Network Time Protocol Authors : Aanchal Malhotra Sharon Goldberg Filename : draft-ietf-ntp-mac-03.txt Pages : 4 Date : 2017-10-30 Abstract: RFC 5905 [RFC5905] states that Network Time Protocol (NTP) packets should be authenticated by appending a 128-bit key to the NTP data, and hashing the result with MD5 to obtain a 128-bit tag. This document deprecates MD5-based authentication, which is considered to be too weak, and recommends the use of AES-CMAC [RFC4493] as a replacement. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-ntp-mac/ There are also htmlized versions available at: https://tools.ietf.org/html/draft-ietf-ntp-mac-03 https://datatracker.ietf.org/doc/html/draft-ietf-ntp-mac-03 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-ntp-mac-03 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Tue Oct 31 02:01:46 2017 Return-Path: X-Original-To: ntp@ietfa.amsl.com Delivered-To: ntp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4A45D13F6F5 for ; Tue, 31 Oct 2017 02:01:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.901 X-Spam-Level: X-Spam-Status: No, score=-6.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XnjNPZeDzB_U for ; Tue, 31 Oct 2017 02:01:43 -0700 (PDT) Received: from mx1.redhat.com (mx1.redhat.com [209.132.183.28]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id AE37813F6F1 for ; Tue, 31 Oct 2017 02:01:42 -0700 (PDT) Received: from smtp.corp.redhat.com (int-mx04.intmail.prod.int.phx2.redhat.com [10.5.11.14]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.redhat.com (Postfix) with ESMTPS id 4279480C1B; Tue, 31 Oct 2017 09:01:42 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.3.2 mx1.redhat.com 4279480C1B Authentication-Results: ext-mx02.extmail.prod.ext.phx2.redhat.com; dmarc=none (p=none dis=none) header.from=redhat.com Authentication-Results: ext-mx02.extmail.prod.ext.phx2.redhat.com; spf=fail smtp.mailfrom=mlichvar@redhat.com Received: from localhost (unknown [10.43.2.117]) by smtp.corp.redhat.com (Postfix) with ESMTPS id 8794A5D969; Tue, 31 Oct 2017 09:01:41 +0000 (UTC) Date: Tue, 31 Oct 2017 10:01:39 +0100 From: Miroslav Lichvar To: ntp@ietf.org Cc: Aanchal Malhotra Message-ID: <20171031090139.GD15597@localhost> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.8.3 (2017-05-23) X-Scanned-By: MIMEDefang 2.79 on 10.5.11.14 X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.5.16 (mx1.redhat.com [10.5.110.26]); Tue, 31 Oct 2017 09:01:42 +0000 (UTC) Archived-At: Subject: [Ntp] Drafts on interleaved modes and correction field X-BeenThere: ntp@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 31 Oct 2017 09:01:45 -0000 Hi, there are two new drafts intended for the NTP working group. Aanchal and I have been working on a draft that would specify the interleaved modes which are supported in some NTP implementations. https://tools.ietf.org/html/draft-mlichvar-ntp-interleaved-modes-00 The second draft describes the PTP-like correction field that I proposed on this list a couple times, but it never had a more detailed specification. https://tools.ietf.org/html/draft-mlichvar-ntp-correction-field-00 Comments and suggestions are welcome. -- Miroslav Lichvar From nobody Tue Oct 31 04:53:57 2017 Return-Path: X-Original-To: ntp@ietfa.amsl.com Delivered-To: ntp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4FCCA138FA0 for ; Tue, 31 Oct 2017 04:53:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.699 X-Spam-Level: X-Spam-Status: No, score=-2.699 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1IfvwKbsOrLx for ; Tue, 31 Oct 2017 04:53:54 -0700 (PDT) Received: from mail-oi0-x231.google.com (mail-oi0-x231.google.com [IPv6:2607:f8b0:4003:c06::231]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B507C13F6BC for ; Tue, 31 Oct 2017 04:53:53 -0700 (PDT) Received: by mail-oi0-x231.google.com with SMTP id c202so26240218oih.9 for ; Tue, 31 Oct 2017 04:53:53 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=wdNZYdPbnplgTnqydoJwqKffy9yvH+WRPG9bsfNxfzY=; b=YVD6q40kumxoZgtLx9AGIKmezFk+YZIGE/0zCFyUHwJo/5RR/HsPmuO6utxbnWFfVt F2zxNsSxh/rJiWy0hwlYETc2uy5xVqleD7jfiEBnxl+1UrOyCLMyelZi9xt0jgfDb/Iu uBedHnTXkDBEOezOzuJQ6TPJo6b9eo1Z3pAtzBRUkmR//TSIDHeuBpJE0/jdWNin8O90 b3gsR6ccuaDSXjm49XJ2hBuyDVD2Y9SCCX7ZhFz6cWF0qvNXo/nI33S83oBuzGV+/DZy Swh+F+XxDTYN98WfZdoQ4fjuLYpMk1TGPPTzp9j628Wc1lfKrc7hq3cmSmd1rJp7zGX1 w9aw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=wdNZYdPbnplgTnqydoJwqKffy9yvH+WRPG9bsfNxfzY=; b=lYnN0LF82DTvA6hd1uUOOWYmb1XhQkuy3zb6L4QMllGcc9in08loxWncGTaUwvwTfx LvdV8aIvkYeuhI7fcWTUBjr8UgXy3+RClZMADgrgH2VUxBksUMDzUDs0y77mEOBX5XpT NBvhoUicozReIf8G309zmzOTetMarITGP45Z5FjozHlYgYAVQ2BebF+0o662Yx0Knlzt LYmCUfpYFFhQr+EWbx52PIQUEBGIDgPVLQD53lJB6+bQoUxF4PbJXf0PcGZqEgWPL0nP r5bG5e2bo5C/PzgOL6XBcu64By+tGXyqcbbNV+iuvRVeYe6u27EOWLN8iOS5Wh2Lyybv mAcA== X-Gm-Message-State: AMCzsaUxJc+8Q09akp1GUWxqi+Ls/aREv8NQlK7+3STX94oLvtttMVHt f9URADxUMXh3QehgHl+auetjj7O2UAyiGv5Ng4k= X-Google-Smtp-Source: ABhQp+T7x5eQns5Rz0FfdPodwzNqFvTnjUfAf+CqbksguVEzEGMHh9az/uPzFUF+O7/y8K7+ZdYL6JxNilfJUzPx4ro= X-Received: by 10.157.89.163 with SMTP id u35mr946980oth.416.1509450833024; Tue, 31 Oct 2017 04:53:53 -0700 (PDT) MIME-Version: 1.0 Received: by 10.168.25.194 with HTTP; Tue, 31 Oct 2017 04:53:52 -0700 (PDT) In-Reply-To: <20171031090139.GD15597@localhost> References: <20171031090139.GD15597@localhost> From: Tal Mizrahi Date: Tue, 31 Oct 2017 13:53:52 +0200 Message-ID: To: Miroslav Lichvar Cc: ntp@ietf.org, Aanchal Malhotra Content-Type: multipart/alternative; boundary="f4030435babcb55c21055cd6684a" Archived-At: Subject: Re: [Ntp] Drafts on interleaved modes and correction field X-BeenThere: ntp@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 31 Oct 2017 11:53:56 -0000 --f4030435babcb55c21055cd6684a Content-Type: text/plain; charset="UTF-8" Hi Miroslav, Aanchal, Regarding the correction field draft: very interesting draft. A few comments: 1. Section 3 says that the delay is the time difference between the end of reception until the beginning of transmission. It seems to make more sense to measure the delay as the beginning of reception until the beginning of transmission, because that is the actual delay of the packet in practice. BTW, this is also the way IEEE 1588 measures the correctionField. 2. "TBD: Requirements on frequency accuracy of the clock." NTP does not define accuracy requirements, and I would suggest to refrain from defining these here as well. 3. "Delay Correction" - please consider using a format that is identical to the one defined in IEEE 1588. 4. Section 2 - it would be great if you could clarify the fields "Receive Correction", "Transmit Correction", and "Origin Correction". Having read this section a couple of times, I could not figure out the units of these fields, how they are used, and the rationale of why these fields are required. 5. "The device MAY update the checksum complement field in order to keep the UDP checksum valid." Since this is a "MAY", please clarify the alternatives: either clear the UDP Checksum field (in IPv4 only), or recompute the UDP Checksum. 6. Security considerations - I would point out that an attacker that tampers with the correction extension is (roughly) equivalent to a delay attacker in terms of the potential damage. Therefore, arguably there is no point in securing the correction extension. I would recommend to leave the correction extension out of the integrity protection. This possibility is mentioned on the second par of Section 7, but I would suggest to rephrase it to "this is what we recommend". 7. Finally, one may consider a slightly different approach, where each hop along the path adds a separate extension field, representing the residence time of the current hop. Obviously this approach has some disadvantages, but the advantage is that it provides detailed information about the delay and delay variation in each hop. There is also potential to secure each extension field separately using its own HMAC. Something to consider... Regards, Tal. On Tue, Oct 31, 2017 at 11:01 AM, Miroslav Lichvar wrote: > Hi, > > there are two new drafts intended for the NTP working group. > > Aanchal and I have been working on a draft that would specify the > interleaved modes which are supported in some NTP implementations. > > https://tools.ietf.org/html/draft-mlichvar-ntp-interleaved-modes-00 > > The second draft describes the PTP-like correction field that I > proposed on this list a couple times, but it never had a more detailed > specification. > > https://tools.ietf.org/html/draft-mlichvar-ntp-correction-field-00 > > Comments and suggestions are welcome. > > -- > Miroslav Lichvar > > _______________________________________________ > ntp mailing list > ntp@ietf.org > https://www.ietf.org/mailman/listinfo/ntp > --f4030435babcb55c21055cd6684a Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hi Miroslav, Aanchal,

Regarding the cor= rection field draft: very interesting draft.

= A few comments:

1. Section 3 says that the del= ay is the time difference between the end of reception until the beginning = of transmission.

=C2=A0 It seems to make more sens= e to measure the delay as the beginning of reception until the beginning of= transmission, because that is the actual delay of the packet in practice. = BTW, this is also the way IEEE 1588 measures the correctionField.

2. "TBD: Requirements on frequency accuracy of the clo= ck."

=C2=A0 =C2=A0NTP does not define accurac= y requirements, and I would suggest to refrain from defining these here as = well.

3. "Delay Correction" - please con= sider using a format that is identical to the one defined in IEEE 1588.=C2= =A0

4. Section 2 - it would be great if you could = clarify the fields "Receive Correction", "Transmit Correctio= n", and "Origin Correction". Having read this section a coup= le of times, I could not figure out the units of these fields, how they are= used, and the rationale of why these fields are required.

5. "The device MAY update the checksum complement field in or= der to keep the UDP checksum valid."
=C2=A0 =C2=A0Since this= is a "MAY", please clarify the alternatives: either clear the UD= P Checksum field (in IPv4 only), or recompute the UDP Checksum.
<= br>
6. Security considerations - I would point out that an attack= er that tampers with the correction extension is (roughly) equivalent to a = delay attacker in terms of the potential damage. Therefore, arguably there = is no point in securing the correction extension. I would recommend to leav= e the correction extension out of the integrity protection. This possibilit= y is mentioned on the second par of Section 7, but I would suggest to rephr= ase it to "this is what we recommend".

=
7. Finally, one may consider a slightly different approach, where each= hop along the path adds a separate extension field, representing the resid= ence time of the current hop. Obviously this approach has some disadvantage= s, but the advantage is that it provides detailed information about the del= ay and delay variation in each hop. There is also potential to secure each = extension field separately using its own HMAC. Something to consider...


Regards,
Tal.

=


On Tue, Oct 31, 2017 at 11:01 AM, Miroslav Lichvar &l= t;mlichvar@redhat.= com> wrote:
Hi,

there are two new drafts intended for the NTP working group.

Aanchal and I have been working on a draft that would specify the
interleaved modes which are supported in some NTP implementations.

https://tools.ietf.org/html/= draft-mlichvar-ntp-interleaved-modes-00

The second draft describes the PTP-like correction field that I
proposed on this list a couple times, but it never had a more detailed
specification.

https://tools.ietf.org/html/d= raft-mlichvar-ntp-correction-field-00

Comments and suggestions are welcome.

--
Miroslav Lichvar

_______________________________________________
ntp mailing list
ntp@ietf.org
https://www.ietf.org/mailman/listinfo/ntp

--f4030435babcb55c21055cd6684a-- From nobody Tue Oct 31 06:52:56 2017 Return-Path: X-Original-To: ntp@ietfa.amsl.com Delivered-To: ntp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E4BF4139504 for ; Tue, 31 Oct 2017 06:52:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.901 X-Spam-Level: X-Spam-Status: No, score=-6.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2bKtF7ZdqBa5 for ; Tue, 31 Oct 2017 06:52:50 -0700 (PDT) Received: from mx1.redhat.com (mx1.redhat.com [209.132.183.28]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C718D1386DE for ; Tue, 31 Oct 2017 06:52:50 -0700 (PDT) Received: from smtp.corp.redhat.com (int-mx05.intmail.prod.int.phx2.redhat.com [10.5.11.15]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.redhat.com (Postfix) with ESMTPS id 6743C2D6E47; Tue, 31 Oct 2017 13:52:50 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.3.2 mx1.redhat.com 6743C2D6E47 Authentication-Results: ext-mx05.extmail.prod.ext.phx2.redhat.com; dmarc=none (p=none dis=none) header.from=redhat.com Authentication-Results: ext-mx05.extmail.prod.ext.phx2.redhat.com; spf=fail smtp.mailfrom=mlichvar@redhat.com Received: from localhost (unknown [10.43.2.117]) by smtp.corp.redhat.com (Postfix) with ESMTPS id 7A9885D6A3; Tue, 31 Oct 2017 13:52:49 +0000 (UTC) Date: Tue, 31 Oct 2017 14:52:47 +0100 From: Miroslav Lichvar To: Tal Mizrahi Cc: ntp@ietf.org, Aanchal Malhotra Message-ID: <20171031135247.GB7648@localhost> References: <20171031090139.GD15597@localhost> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.8.3 (2017-05-23) X-Scanned-By: MIMEDefang 2.79 on 10.5.11.15 X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.5.16 (mx1.redhat.com [10.5.110.29]); Tue, 31 Oct 2017 13:52:50 +0000 (UTC) Archived-At: Subject: Re: [Ntp] Drafts on interleaved modes and correction field X-BeenThere: ntp@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 31 Oct 2017 13:52:53 -0000 On Tue, Oct 31, 2017 at 01:53:52PM +0200, Tal Mizrahi wrote: > Regarding the correction field draft: very interesting draft. > > A few comments: Thanks for the comments, Tal. > 1. Section 3 says that the delay is the time difference between the end of > reception until the beginning of transmission. > > It seems to make more sense to measure the delay as the beginning of > reception until the beginning of transmission, because that is the actual > delay of the packet in practice. BTW, this is also the way IEEE 1588 > measures the correctionField. I think it should to be the same as what the clients and servers use, otherwise it would create an asymmetric correction when switching between different link speeds. As I understand it, PTP assumes that all devices in the network support PTP (as BC or TC), so it can take the simpler approch using preamble timestamps for both TX and RX. With NTP there is generally no HW support, so clients and servers should use trailer RX timestamps and preamble TX timestamps to avoid an asymmetric delay with different link speeds. The following document explains the issue nicely. https://www.eecis.udel.edu/~mills/stamp.html Do you think it will be difficult to implement? If the link speed and length of the packet is known, the timestamp can be transposed. In any case, I guess this should be explained in the draft. > 2. "TBD: Requirements on frequency accuracy of the clock." > > NTP does not define accuracy requirements, and I would suggest to > refrain from defining these here as well. Ok, I was not really sure how it would be specified. > 3. "Delay Correction" - please consider using a format that is identical to > the one defined in IEEE 1588. Do you think it will be easier to implement that way? Using a nanosecond field in NTP packets feels dirty to me :). > 4. Section 2 - it would be great if you could clarify the fields "Receive > Correction", "Transmit Correction", and "Origin Correction". Having read > this section a couple of times, I could not figure out the units of these > fields, how they are used, and the rationale of why these fields are > required. All these fields are in 1/(2^48) of a second. The receive and transmit corrections are just extensions of the receive and transmit timestamps. When put together they make fixed point numbers with 32 integer bits and 32 + 16 fractional bits. The reason for a separate origin field is to allow the client to check both values before they are applied. If the server adjusted its timestamp instead, the client wouldn't know by how much and couldn't limit the impact of a MITM attack. The reason for a separate transmit correction is to support the interleaved modes. The receive correction might not be necessary. If you have a better use for the 2 octets, I think it could be dropped and included in the origin correction instead. > 5. "The device MAY update the checksum complement field in order to keep > the UDP checksum valid." > Since this is a "MAY", please clarify the alternatives: either clear the > UDP Checksum field (in IPv4 only), or recompute the UDP Checksum. Good point. > 6. Security considerations - I would point out that an attacker that > tampers with the correction extension is (roughly) equivalent to a delay > attacker in terms of the potential damage. Therefore, arguably there is no > point in securing the correction extension. I would recommend to leave the > correction extension out of the integrity protection. This possibility is > mentioned on the second par of Section 7, but I would suggest to rephrase > it to "this is what we recommend". Ok, I'll do that. > 7. Finally, one may consider a slightly different approach, where each hop > along the path adds a separate extension field, representing the residence > time of the current hop. Obviously this approach has some disadvantages, > but the advantage is that it provides detailed information about the delay > and delay variation in each hop. There is also potential to secure each > extension field separately using its own HMAC. Something to consider... I did briefly consider an approach like that, but it seemed to me there are at least two issues: - It may allow traffic amplification. - The growing length of the packet may create an asymmetric delay, which I suspect could be completely avoided only in the case where all devices on the path support the correction field and preamble timestamps are used everywhere. -- Miroslav Lichvar From nobody Tue Oct 31 07:59:58 2017 Return-Path: X-Original-To: ntp@ietfa.amsl.com Delivered-To: ntp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9A18013F72A for ; Tue, 31 Oct 2017 07:59:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.699 X-Spam-Level: X-Spam-Status: No, score=-2.699 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FfQUQMHw9jnU for ; Tue, 31 Oct 2017 07:59:54 -0700 (PDT) Received: from mail-oi0-x230.google.com (mail-oi0-x230.google.com [IPv6:2607:f8b0:4003:c06::230]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id DE1CD13F6DB for ; Tue, 31 Oct 2017 07:59:53 -0700 (PDT) Received: by mail-oi0-x230.google.com with SMTP id g125so27021257oib.12 for ; Tue, 31 Oct 2017 07:59:53 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=lHCmTSawHsxxADLgCLPmS79NkYxhSuJDtW9dCv7euIY=; b=a+OVK3rp8m5ZOUTO11gF7FCGYqIyS3aYNOxVI9YFNzUA4vU5bURCfihCdiBVCmsZfx 1ZE4HUActxcIDmc317O+hTvR11OCOS3DGb9GCLVrcsaXzWoRtJsEJ5oJwnvWUC8x5fAT Z++lmWnVn6NacGN0aGKt1UfaOZEpUFEGSWOvL6WFYsfN7n/Qyk+5ROQPA4wJGDJwST+H AIY2K38EyUN0DmbsHPzDb95pbMvh48XXxmbOHz7IpZFKIOj7NGLdQGfxZ1+5Q0LUToep ez5jljvfty8C6calASW1Y1UPOvXnsOLz57nMA19Js7IkEPmW6W5+1cNOFuvoL9XMizVG 88uQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=lHCmTSawHsxxADLgCLPmS79NkYxhSuJDtW9dCv7euIY=; b=oMsYxGebLYaiU/yK9EmT2x/EqEeCPtSohTD0888TbWcbd/ouwLg8qAOaxN2SKknEQU H6P4llYVu2JufsTW0P6y8BRh2TRlv8L3gqg/9qKMQ1f56Wm3yDdTGLKvZ0ZGqBg4vZ+c KcOeFu1RLVqoQFl2IeJys8+SmCI3wRPkQtZiIM8uWG+nDjAUc0AK2bnzxlqgaIc73oE8 pl6WYCCsLdm757dg9bKr7mEqqyHweqvtzy2pWQkSxOnUhMdF9q668x6FFugDdhJd5vig 69xX4UVlhMYiC7jIKdYw4gfglENYpK8tECXPZ1oc1wA0l26/FnmYhVCOBA3hiScCg6Ct zZ1A== X-Gm-Message-State: AMCzsaWn8m8rlOBVCjXpP8Q8Ar6l42hTSlkJJXoFWQmu4PY0STwevNiq FyEqbZhGH51XQgUoAgp73nh9dCiQPJ23mlyK3gU= X-Google-Smtp-Source: ABhQp+TVz7vtDyWba9eLmPDfl81CuteQAsrn2GFSF/mcKA6ewAa4nKkwoubhMY+EVf7Bx+8r+GEjMNrsHRolV3FVlzo= X-Received: by 10.202.81.16 with SMTP id f16mr1078848oib.157.1509461993216; Tue, 31 Oct 2017 07:59:53 -0700 (PDT) MIME-Version: 1.0 Received: by 10.168.25.194 with HTTP; Tue, 31 Oct 2017 07:59:52 -0700 (PDT) In-Reply-To: <20171031135247.GB7648@localhost> References: <20171031090139.GD15597@localhost> <20171031135247.GB7648@localhost> From: Tal Mizrahi Date: Tue, 31 Oct 2017 16:59:52 +0200 Message-ID: To: Miroslav Lichvar Cc: ntp@ietf.org, Aanchal Malhotra Content-Type: multipart/alternative; boundary="001a113d77d4e86147055cd9011b" Archived-At: Subject: Re: [Ntp] Drafts on interleaved modes and correction field X-BeenThere: ntp@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 31 Oct 2017 14:59:56 -0000 --001a113d77d4e86147055cd9011b Content-Type: text/plain; charset="UTF-8" Hi Miroslav, Thanks for the quick response. >With NTP there is generally no HW support, so clients and servers >should use trailer RX timestamps and preamble TX timestamps to avoid >an asymmetric delay with different link speeds. The following document >explains the issue nicely. > >https://www.eecis.udel.edu/~mills/stamp.html > >Do you think it will be difficult to implement? If the link speed and >length of the packet is known, the timestamp can be transposed. The link speed is not necessarily known to the end points. Furthermore, the link speed may change several times along the path. Maybe I am missing something, but it appears that when measuring last-bit-in-to-first-bit-out we are ignoring the packet reception time; it seems to make sense to include the packet reception time in the residence time. Moreover, we never know which nodes along the path use store-and-forward, and which nodes use cut-through. In cut-through forwarding the packet transmission may start before the last bit is received, so it certainly makes more sense to measure the first-bit-in-to-first-bit-out. >The reason for a separate transmit correction is to support the >interleaved modes. The receive correction might not be necessary. If >you have a better use for the 2 octets, I think it could be dropped >and included in the origin correction instead. So it looks like two correction fields would suffice: one for the forward direction, and one for the reverse direction. Right? Thanks, Tal. On Tue, Oct 31, 2017 at 3:52 PM, Miroslav Lichvar wrote: > On Tue, Oct 31, 2017 at 01:53:52PM +0200, Tal Mizrahi wrote: > > Regarding the correction field draft: very interesting draft. > > > > A few comments: > > Thanks for the comments, Tal. > > > 1. Section 3 says that the delay is the time difference between the end > of > > reception until the beginning of transmission. > > > > It seems to make more sense to measure the delay as the beginning of > > reception until the beginning of transmission, because that is the actual > > delay of the packet in practice. BTW, this is also the way IEEE 1588 > > measures the correctionField. > > I think it should to be the same as what the clients and servers use, > otherwise it would create an asymmetric correction when switching > between different link speeds. > > As I understand it, PTP assumes that all devices in the network > support PTP (as BC or TC), so it can take the simpler approch using > preamble timestamps for both TX and RX. > > With NTP there is generally no HW support, so clients and servers > should use trailer RX timestamps and preamble TX timestamps to avoid > an asymmetric delay with different link speeds. The following document > explains the issue nicely. > > https://www.eecis.udel.edu/~mills/stamp.html > > Do you think it will be difficult to implement? If the link speed and > length of the packet is known, the timestamp can be transposed. > > In any case, I guess this should be explained in the draft. > > > 2. "TBD: Requirements on frequency accuracy of the clock." > > > > NTP does not define accuracy requirements, and I would suggest to > > refrain from defining these here as well. > > Ok, I was not really sure how it would be specified. > > > 3. "Delay Correction" - please consider using a format that is identical > to > > the one defined in IEEE 1588. > > Do you think it will be easier to implement that way? Using a > nanosecond field in NTP packets feels dirty to me :). > > > 4. Section 2 - it would be great if you could clarify the fields "Receive > > Correction", "Transmit Correction", and "Origin Correction". Having read > > this section a couple of times, I could not figure out the units of these > > fields, how they are used, and the rationale of why these fields are > > required. > > All these fields are in 1/(2^48) of a second. The receive and transmit > corrections are just extensions of the receive and transmit > timestamps. When put together they make fixed point numbers with 32 > integer bits and 32 + 16 fractional bits. > > The reason for a separate origin field is to allow the client to check > both values before they are applied. If the server adjusted its > timestamp instead, the client wouldn't know by how much and couldn't > limit the impact of a MITM attack. > > The reason for a separate transmit correction is to support the > interleaved modes. The receive correction might not be necessary. If > you have a better use for the 2 octets, I think it could be dropped > and included in the origin correction instead. > > > 5. "The device MAY update the checksum complement field in order to keep > > the UDP checksum valid." > > Since this is a "MAY", please clarify the alternatives: either clear > the > > UDP Checksum field (in IPv4 only), or recompute the UDP Checksum. > > Good point. > > > 6. Security considerations - I would point out that an attacker that > > tampers with the correction extension is (roughly) equivalent to a delay > > attacker in terms of the potential damage. Therefore, arguably there is > no > > point in securing the correction extension. I would recommend to leave > the > > correction extension out of the integrity protection. This possibility is > > mentioned on the second par of Section 7, but I would suggest to rephrase > > it to "this is what we recommend". > > Ok, I'll do that. > > > 7. Finally, one may consider a slightly different approach, where each > hop > > along the path adds a separate extension field, representing the > residence > > time of the current hop. Obviously this approach has some disadvantages, > > but the advantage is that it provides detailed information about the > delay > > and delay variation in each hop. There is also potential to secure each > > extension field separately using its own HMAC. Something to consider... > > I did briefly consider an approach like that, but it seemed to me > there are at least two issues: > - It may allow traffic amplification. > - The growing length of the packet may create an asymmetric delay, > which I suspect could be completely avoided only in the case where > all devices on the path support the correction field and preamble > timestamps are used everywhere. > > -- > Miroslav Lichvar > --001a113d77d4e86147055cd9011b Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hi Miroslav,

Thanks for the quick respo= nse.


>With NTP there is gen= erally no HW support, so clients and servers
>should use trail= er RX timestamps and preamble TX timestamps to avoid
>an asymm= etric delay with different link speeds. The following document
&g= t;explains the issue nicely.
>
>
>Do you think it will be difficul= t to implement? If the link speed and
>length of the packet is= known, the timestamp can be transposed.

The= link speed is not necessarily known to the end points. Furthermore, the li= nk speed may change several times along the path.
Maybe I am miss= ing something, but it appears that when measuring last-bit-in-to-first-bit-= out we are ignoring the packet reception time; it seems to make sense to in= clude the packet reception time in the residence time.

=
Moreover, we never know which nodes along the path use store-and-forwa= rd, and which nodes use cut-through. In cut-through forwarding the packet t= ransmission may start before the last bit is received, so it certainly make= s more sense to measure the first-bit-in-to-first-bit-out.


>The reason for a separate transmit correct= ion is to support the
>interleaved modes. The receive correcti= on might not be necessary. If
>you have a better use for the 2= octets, I think it could be dropped
>and included in the orig= in correction instead.

So it looks like two = correction fields would suffice: one for the forward direction, and one for= the reverse direction. Right?

Thanks,
T= al.





On Tue, Oct 31, 2017 at= 3:52 PM, Miroslav Lichvar <mlichvar@redhat.com> wrote:
O= n Tue, Oct 31, 2017 at 01:53:52PM +0200, Tal Mizrahi wrote:
> Regarding the correction field draft: very interesting draft.
>
> A few comments:

Thanks for the comments, Tal.

> 1. Section 3 says that the delay is the time difference between the en= d of
> reception until the beginning of transmission.
>
>=C2=A0 =C2=A0It seems to make more sense to measure the delay as the be= ginning of
> reception until the beginning of transmission, because that is the act= ual
> delay of the packet in practice. BTW, this is also the way IEEE 1588 > measures the correctionField.

I think it should to be the same as what the clients and servers use= ,
otherwise it would create an asymmetric correction when switching
between different link speeds.

As I understand it, PTP assumes that all devices in the network
support PTP (as BC or TC), so it can take the simpler approch using
preamble timestamps for both TX and RX.

With NTP there is generally no HW support, so clients and servers
should use trailer RX timestamps and preamble TX timestamps to avoid
an asymmetric delay with different link speeds. The following document
explains the issue nicely.

https://www.eecis.udel.edu/~mills/stamp.html
Do you think it will be difficult to implement? If the link speed and
length of the packet is known, the timestamp can be transposed.

In any case, I guess this should be explained in the draft.

> 2. "TBD: Requirements on frequency accuracy of the clock." >
>=C2=A0 =C2=A0 NTP does not define accuracy requirements, and I would su= ggest to
> refrain from defining these here as well.

Ok, I was not really sure how it would be specified.

> 3. "Delay Correction" - please consider using a format that = is identical to
> the one defined in IEEE 1588.

Do you think it will be easier to implement that way? Using a
nanosecond field in NTP packets feels dirty to me :).

> 4. Section 2 - it would be great if you could clarify the fields "= ;Receive
> Correction", "Transmit Correction", and "Origin Co= rrection". Having read
> this section a couple of times, I could not figure out the units of th= ese
> fields, how they are used, and the rationale of why these fields are > required.

All these fields are in 1/(2^48) of a second. The receive and transm= it
corrections are just extensions of the receive and transmit
timestamps. When put together they make fixed point numbers with 32
integer bits and 32 + 16 fractional bits.

The reason for a separate origin field is to allow the client to check
both values before they are applied. If the server adjusted its
timestamp instead, the client wouldn't know by how much and couldn'= t
limit the impact of a MITM attack.

The reason for a separate transmit correction is to support the
interleaved modes. The receive correction might not be necessary. If
you have a better use for the 2 octets, I think it could be dropped
and included in the origin correction instead.

> 5. "The device MAY update the checksum complement field in order = to keep
> the UDP checksum valid."
>=C2=A0 =C2=A0 Since this is a "MAY", please clarify the alter= natives: either clear the
> UDP Checksum field (in IPv4 only), or recompute the UDP Checksum.

Good point.

> 6. Security considerations - I would point out that an attacker that > tampers with the correction extension is (roughly) equivalent to a del= ay
> attacker in terms of the potential damage. Therefore, arguably there i= s no
> point in securing the correction extension. I would recommend to leave= the
> correction extension out of the integrity protection. This possibility= is
> mentioned on the second par of Section 7, but I would suggest to rephr= ase
> it to "this is what we recommend".

Ok, I'll do that.

> 7. Finally, one may consider a slightly different approach, where each= hop
> along the path adds a separate extension field, representing the resid= ence
> time of the current hop. Obviously this approach has some disadvantage= s,
> but the advantage is that it provides detailed information about the d= elay
> and delay variation in each hop. There is also potential to secure eac= h
> extension field separately using its own HMAC. Something to consider..= .

I did briefly consider an approach like that, but it seemed to me there are at least two issues:
- It may allow traffic amplification.
- The growing length of the packet may create an asymmetric delay,
=C2=A0 which I suspect could be completely avoided only in the case where =C2=A0 all devices on the path support the correction field and preamble =C2=A0 timestamps are used everywhere.

--
Miroslav Lichvar

--001a113d77d4e86147055cd9011b-- From nobody Tue Oct 31 08:58:01 2017 Return-Path: X-Original-To: ntp@ietfa.amsl.com Delivered-To: ntp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D233F13F87A for ; Tue, 31 Oct 2017 08:57:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.901 X-Spam-Level: X-Spam-Status: No, score=-6.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id VftO81Kn_pRb for ; Tue, 31 Oct 2017 08:57:56 -0700 (PDT) Received: from mx1.redhat.com (mx1.redhat.com [209.132.183.28]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3B3F313F88C for ; Tue, 31 Oct 2017 08:57:26 -0700 (PDT) Received: from smtp.corp.redhat.com (int-mx05.intmail.prod.int.phx2.redhat.com [10.5.11.15]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.redhat.com (Postfix) with ESMTPS id D2F6F624C9; Tue, 31 Oct 2017 15:57:25 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.3.2 mx1.redhat.com D2F6F624C9 Authentication-Results: ext-mx10.extmail.prod.ext.phx2.redhat.com; dmarc=none (p=none dis=none) header.from=redhat.com Authentication-Results: ext-mx10.extmail.prod.ext.phx2.redhat.com; spf=fail smtp.mailfrom=mlichvar@redhat.com Received: from localhost (unknown [10.43.2.117]) by smtp.corp.redhat.com (Postfix) with ESMTPS id E98355D754; Tue, 31 Oct 2017 15:57:24 +0000 (UTC) Date: Tue, 31 Oct 2017 16:57:17 +0100 From: Miroslav Lichvar To: Tal Mizrahi Cc: ntp@ietf.org, Aanchal Malhotra Message-ID: <20171031155717.GC7648@localhost> References: <20171031090139.GD15597@localhost> <20171031135247.GB7648@localhost> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.8.3 (2017-05-23) X-Scanned-By: MIMEDefang 2.79 on 10.5.11.15 X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.5.16 (mx1.redhat.com [10.5.110.39]); Tue, 31 Oct 2017 15:57:26 +0000 (UTC) Archived-At: Subject: Re: [Ntp] Drafts on interleaved modes and correction field X-BeenThere: ntp@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 31 Oct 2017 15:57:59 -0000 On Tue, Oct 31, 2017 at 04:59:52PM +0200, Tal Mizrahi wrote: > >With NTP there is generally no HW support, so clients and servers > >should use trailer RX timestamps and preamble TX timestamps to avoid > >an asymmetric delay with different link speeds. The following document > >explains the issue nicely. > > > >https://www.eecis.udel.edu/~mills/stamp.html > > > >Do you think it will be difficult to implement? If the link speed and > >length of the packet is known, the timestamp can be transposed. > > The link speed is not necessarily known to the end points. I meant that the devices which are supposed to modify the correction field know the link speed and can transpose preamble timestamps if necessary. The end points don't need to know the link speed on the path. Just the speed of their own link if they need to transpose their timestamps. > Furthermore, the > link speed may change several times along the path. In such case we want the correction to still be symmetric, right? > Maybe I am missing something, but it appears that when measuring > last-bit-in-to-first-bit-out we are ignoring the packet reception time; it > seems to make sense to include the packet reception time in the residence > time. For PTP yes, but not for NTP. The reception time is included in the network delay as measured by the client, which will be symmetric as long as no device on the path includes in the correction the transmission time or reception time. > Moreover, we never know which nodes along the path use store-and-forward, > and which nodes use cut-through. In cut-through forwarding the packet > transmission may start before the last bit is received, so it certainly > makes more sense to measure the first-bit-in-to-first-bit-out. That's a good point. With cut-through switching the correction would be negative and generally couldn't be determined in time to be put in the packet as the length is unknown. Are there any switches that can cut-through from a faster link to slower link? Maybe it would make sense to allow corrections from preamble RX timestamps when the link speeds are equal. > >The reason for a separate transmit correction is to support the > >interleaved modes. The receive correction might not be necessary. If > >you have a better use for the 2 octets, I think it could be dropped > >and included in the origin correction instead. > > So it looks like two correction fields would suffice: one for the forward > direction, and one for the reverse direction. Right? I think it's three fields if we want both support the interleaved modes and allow the client to check the delay correction in both directions. Where would be the transmit correction included if there were only two fields? -- Miroslav Lichvar From nobody Tue Oct 31 08:59:37 2017 Return-Path: X-Original-To: ntp@ietfa.amsl.com Delivered-To: ntp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4B49E13F8AC for ; Tue, 31 Oct 2017 08:59:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.92 X-Spam-Level: X-Spam-Status: No, score=-1.92 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=mscc365.onmicrosoft.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LH5Nbuo5aIwc for ; Tue, 31 Oct 2017 08:59:31 -0700 (PDT) Received: from NAM02-CY1-obe.outbound.protection.outlook.com (mail-cys01nam02on0041.outbound.protection.outlook.com [104.47.37.41]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 350A613F769 for ; Tue, 31 Oct 2017 08:59:02 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=mscc365.onmicrosoft.com; s=selector1-microsemi-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=nvDisa4Uk5VdCZEbknCUFEZaair6v+QCsYqpb5hyxKE=; b=GAXJLN0oi2jHrDejIlcvOSZe8lno0Q2dbH2r3mdVqw9MXw5jK0OF39vRUW3qbRgM7FvzZgvaEbUenmRmAGCcQ5UJK2um7bdbThVVLAy9NHlesJ9OrMdfq5y8cqbXVSjSdEH0Zt9gES1MwauKTJPql39u9aj/nPG3VnkcUS+WLME= Received: from MWHPR02CA0052.namprd02.prod.outlook.com (10.164.133.41) by CY1PR0201MB1834.namprd02.prod.outlook.com (10.163.55.152) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P256) id 15.20.178.6; Tue, 31 Oct 2017 15:58:59 +0000 Received: from BY2FFO11OLC007.protection.gbl (2a01:111:f400:7c0c::194) by MWHPR02CA0052.outlook.office365.com (2603:10b6:301:60::41) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384) id 15.20.178.6 via Frontend Transport; Tue, 31 Oct 2017 15:58:59 +0000 Authentication-Results: spf=pass (sender IP is 208.19.100.20) smtp.mailfrom=microsemi.com; bu.edu; dkim=none (message not signed) header.d=none;bu.edu; dmarc=bestguesspass action=none header.from=microsemi.com; Received-SPF: Pass (protection.outlook.com: domain of microsemi.com designates 208.19.100.20 as permitted sender) receiver=protection.outlook.com; client-ip=208.19.100.20; helo=avsrvexchhts2.microsemi.net; Received: from avsrvexchhts2.microsemi.net (208.19.100.20) by BY2FFO11OLC007.mail.protection.outlook.com (10.1.14.254) with Microsoft SMTP Server (version=TLS1_0, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA_P384) id 15.20.178.5 via Frontend Transport; Tue, 31 Oct 2017 15:58:59 +0000 Received: from SJSRVEXCHHTS1.microsemi.net (10.241.34.105) by avsrvexchhts2.microsemi.net (10.100.34.106) with Microsoft SMTP Server (TLS) id 14.3.361.1; Tue, 31 Oct 2017 08:58:42 -0700 Received: from SJSRVEXCHMBX2.microsemi.net ([fe80::6da0:6f9d:d5d1:3d5d]) by sjsrvexchhts1.microsemi.net ([::1]) with mapi id 14.03.0361.001; Tue, 31 Oct 2017 08:58:41 -0700 From: Greg Dowd To: Tal Mizrahi , Miroslav Lichvar CC: Aanchal Malhotra , "ntp@ietf.org" Thread-Topic: [Ntp] Drafts on interleaved modes and correction field Thread-Index: AQHTUibko2qH9HHhdE6MN2nq8y+qG6L+TuIAgAAhOYCAABK/AP//mkcA Date: Tue, 31 Oct 2017 15:58:41 +0000 Message-ID: <8D2BF679AAC7C346848A489074F9F8BFF3535068@sjsrvexchmbx2.microsemi.net> References: <20171031090139.GD15597@localhost> <20171031135247.GB7648@localhost> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.241.128.48] Content-Type: multipart/alternative; boundary="_000_8D2BF679AAC7C346848A489074F9F8BFF3535068sjsrvexchmbx2mi_" MIME-Version: 1.0 X-EOPAttributedMessage: 0 X-MS-Office365-Filtering-HT: Tenant X-Forefront-Antispam-Report: CIP:208.19.100.20; IPV:NLI; CTRY:US; EFV:NLI; SFV:NSPM; SFS:(10009020)(39860400002)(376002)(346002)(2980300002)(438002)(189002)(51914003)(24454002)(199003)(50986999)(54356999)(76176999)(7696004)(5660300001)(2950100002)(86362001)(189998001)(49446005)(55846006)(316002)(5250100002)(54906003)(110136005)(106002)(93886005)(16586007)(69596002)(7736002)(356003)(33656002)(2900100001)(2920100001)(53416004)(97736004)(81156014)(8936002)(81166006)(512874002)(8676002)(54896002)(6306002)(790700001)(9686003)(68736007)(236005)(3846002)(6116002)(102836003)(106466001)(39060400002)(53546010)(606006)(2906002)(229853002)(72206003)(478600001)(4326008)(6246003)(966005)(84326002)(53936002); DIR:OUT; SFP:1101; SCL:1; SRVR:CY1PR0201MB1834; H:avsrvexchhts2.microsemi.net; FPR:; SPF:Pass; PTR:InfoDomainNonexistent; MX:1; A:1; LANG:en; X-Microsoft-Exchange-Diagnostics: 1; BY2FFO11OLC007; 1:0k6hf64Ofr5tNW9fwHYQNSfmJDHlrnQtILiipWqDGDjmvhkMp9175D1oSVbxDJZzrEFHE8swqdXVHzRVfS8PbU6WbtFhtctJzGLsKRLoh1nIf8ew9zL7L3fZmEpXECPP X-MS-PublicTrafficType: Email X-MS-Office365-Filtering-Correlation-Id: 261e9ff3-5bbd-4ee2-1181-08d520784c9d X-Microsoft-Antispam: UriScan:; BCL:0; PCL:0; RULEID:(22001)(8251501002)(4534020)(4602075)(2017052603238); SRVR:CY1PR0201MB1834; X-Microsoft-Exchange-Diagnostics: 1; CY1PR0201MB1834; 3:mgyZa1Ppdky15DRcchzaarNQp071qtWV+PP/Ey/qMoJqqc/RNPPdFK+/ycOteNDOH579moMLq0JrhhjkOUKWL1A9qcqNZpcv9bAIHJpUOQPE0JVFHgA4K9tayAx/XmFps8eUlbOs0626ZBok5glWEguvX6VjT/ca0WMPQ1YbQq1rp2Z/rKkEe9+LfIjpXgvwSzrQS8QjU3uje8algjpMa2w17/wzwvEBQ9cwhGix7fSa3Owud9YZu8p1hG0ug1bxpfj7e8k6wPoyDc7IyNB+vqmEebG2zvIP/qNeP2/8QNmKJf+awO0CtP04zkvhyQGtflBrmabckOznLy/GPsjQQfY+pkC5MP6NXY4SrP4H4eg=; 25:EZD3ZNWyVPc4aAmvnRivflMOs6ksZVYRL9PHsfDEWq5VYzxRsne9CASImjcAhXwivnlgnQB0pNlIqDVhvT77FCk75mp7wekeV9OgKlLpiZeIHYsWT6AlCt62XvLYT2K2LQddL7HY9pP6Zfg3wyOH1xVD6n7zesGVzYom3HLdygld8yC1G6jeG5zHcktpwt6we/ZSjvWMWItr8wjFml68XmCl3C0f6vebkNQQ7tI7OzLbPkfKEJdaRlrLkol21nyiSisOLUzU28MuGbWI9l5N0IdT0U0MecjI+BpSIhDdbDl9UuESgMj6H8ZVXK4CuJOCwnvJFdxmhFhjB0d/1VLefA== X-MS-TrafficTypeDiagnostic: CY1PR0201MB1834: X-Microsoft-Exchange-Diagnostics: 1; CY1PR0201MB1834; 31:w8ahqPxNBAveaGVoQob21oOP59MzDWIpZIMoX7XUmlu21bCRSHFv2ANCIvbJz3OTF7Sq1i7vM/EKr6XCzSlsYn9blPL9tlB2lkhqlu68JLc7HsVeVfPBV38ZFm6bLrCaCc0j9eKCpIZtI6raZtm8hDJg8Tq6TXjVu96/jWWyCkUhu4wVM3BIYm8wzw9qUkjdkt6EFfcraIvFUV+PjqJ7OjGelDzcwAJA+vVZuBfbf1w=; 20:uQ9/Ah5XxfnCUovPZTxHkdaRg2fBXfUhNq4eYcTcnXx/72AB/dwVYnogt0Hukqo0fMoVARwQXk1NqKTg0iVe8iWeW7gjXwHwZyf8Et7pFB9EMsSaJo5cK0ul+7XE1g6vAhi25mig1R3d8/66OC/Hq2HucBxcALAFJwhWYZRn7x2D4n1IWqs1xHLFIsfS4oL0KDJdLY5wVIBMKtW5kmwsXB6HYf5rR7d4JI1WcFykv30GPP/e66rp0+YQU1T6oXNLk6p58dadkf3Vs7kKgROi7tl0JhAKEu972cbcG7UU6hxoEmaWolyHMB/hf74lJV8VNAvp03FnZFH5gXWnWyfDJOldTPY9X9U/sy0nv7AUmvxIVUVxT/Jl7k6EVgk2xs5qt4/nUzKXEIGvOMBc2O3HKwFeeZhHunJILQPt3aNSY0xPhjox8anf7HFgHYsuE6L6+TbqwaXAPCvyAKbfEqn3Pgf/w29OhCJz9zf/QItjkwN4wumTy5aaEOLSRsLmACmB X-Exchange-Antispam-Report-Test: UriScan:(158342451672863)(192374486261705)(238701278423138)(21748063052155)(226873365582246); X-Microsoft-Antispam-PRVS: X-Exchange-Antispam-Report-CFA-Test: BCL:0; PCL:0; RULEID:(100000700101)(100105000095)(100000701101)(100105300095)(100000702101)(100105100095)(6040450)(2401047)(5005006)(8121501046)(93006095)(93004095)(100000703101)(100105400095)(3231020)(3002001)(10201501046)(6055026)(6041248)(20161123558100)(20161123560025)(20161123564025)(20161123562025)(20161123555025)(201703131423075)(201702281528075)(201703061421075)(201703061406153)(6072148)(201708071742011)(100000704101)(100105200095)(100000705101)(100105500095); SRVR:CY1PR0201MB1834; BCL:0; PCL:0; RULEID:(100000800101)(100110000095)(100000801101)(100110300095)(100000802101)(100110100095)(100000803101)(100110400095)(100000804101)(100110200095)(100000805101)(100110500095); SRVR:CY1PR0201MB1834; X-Microsoft-Exchange-Diagnostics: 1; CY1PR0201MB1834; 4:3fanslHzwwX2phEbPd67fBvRDRL2f2vzmoOSKx9KpqsQ51ndENNWe0L938z61t1ZHm1Wy144v9w0fVWLYLxKhne+TYcLZwmWsz9yR10y9tm8W4zeL3u7/YUB+8YO1x1NcH/sH4dUzSqAxe5pYLmWdwAX2nYG9pmm3JZFHiMiHxYvoZPbIkOzv0C2os8Oyd5mhQeIyLd58yI2wqBxywIGEgwooK7syTPri52MdkUNpBfw+lT44hgBPP37iTRtaFhdkwxD+F0NIqpouaD5ZDhoUTQ5DiI4FsIhw4QTp1/hZRxwsb2ClyV0Bnsp0qyEGWzn914BBBBMrVt8wQhbY6yKWRGCUUMf3BIQhYSvZy2Fwud9Ih+Il4C/UpxXzQuwTD68xvpPcmGpC4XYQASKaKnOPgJtteCnqE7xP+ViVUHZvz2DWKDbNwMbQQ0E0yMUkV9I1bi7BVWyueKw2HJKaWk+Sw== X-Forefront-PRVS: 04772EA191 X-Microsoft-Exchange-Diagnostics: =?us-ascii?Q?1; CY1PR0201MB1834; 23:Eho09HfEjRBMl0KB1w3xxnqo5JrLkc1PWZ+osjB?= =?us-ascii?Q?HheEKsL505m6JO4COUVfZa8p9AEDu4khaq+XDzIdp3w4QNjk4Oz94e/BEQpz?= =?us-ascii?Q?vLBc/qSzA27kttQ0MXceh9BsLL5c2bwqkWOs8DOUUkGa9hA3EepQAfJ5/mP3?= =?us-ascii?Q?6+Wp2BwKESHE9Iwv6Em5Ztj216ewW9PxTCSpv0iPZToEBXmjFEHrFA1ePlmG?= =?us-ascii?Q?Br1H179l+HK4jcBI6MkvrlAAm1TF4kX8m6KqzC3Ucbq6j5OOfdJRQdbOhxfp?= =?us-ascii?Q?vr9mtlW2OClKvalE37l5lJXKLvr+IV6iF9DGztO224P+KojOb0urK4apjt9v?= =?us-ascii?Q?8CpZzEU7hAQ+W8zOBYZ8iT7mOmbIGq6+VkteIR9eiZogFw/mThIOobX1xvOq?= =?us-ascii?Q?b7o+gMx/wYBQ7LgH/TQHZCvqv6OvB7FaXHt/DKSJISZHoe/8GkhFrsYl1NRA?= =?us-ascii?Q?rVc/B+QrZpIOj04MXY/m235XhHUQ3svBCUCFMfmjpcaTlQ1nPJqQCDhzYwdc?= =?us-ascii?Q?WMzWf2g5grnC3qkJud6fYGmSgoSwzVVfo61OMpxtc0tUTo/NCdLKZtjuXgzN?= =?us-ascii?Q?P1UzSGjPpF3jisXW0XWN26zBM3aUhQDE2C5B7Avo2VKjMYhui5Q4pdSUdNtj?= =?us-ascii?Q?sZC7mo9jnfLYe7bNaDWYD9WdZ5YBSLb9pis8KFAzXK6buZUFxyyQUZfGq1SC?= =?us-ascii?Q?MT8qHlumMVnaEIxiNtwLKcHtbNruvFfpvsolhrMn3t8SLm8WoaMijH4fs/94?= =?us-ascii?Q?UgUzzAtdIaUr7rR6ndr2x3K+DNmOQR8r+c9zlbcPLxuL1bBIPwD/Wt1vdjY7?= =?us-ascii?Q?cx2TZ05lUhbuXUidCaR5OoeBvgs+D1VDxKiEYnhGT6NVxeevQOBWcMXT7H5k?= =?us-ascii?Q?t5v7L/e99aCr+h23UkDPCyS/G2/9fEyDk1UpRwOqAWq9v9qDKgFGtmiXsCSU?= =?us-ascii?Q?qOuLnlEHNNNuv5Lnr0FZiphvhqTMAhWOcsrDof6ICJfJXobiUVd51aF21aWX?= =?us-ascii?Q?xRqnOiOyvyd31Q1N3JO6QzK4iKt+SKII3d7RrNTf3pQMYWQP0eFBjRtznZ5K?= =?us-ascii?Q?JKXNajZ544Sg4vVfhxLF0t+Pgm2RN3ZgvKQvPYaKLBp6NxKrZJ/YEEqIvWkL?= =?us-ascii?Q?alEzI/BZrn/kKX7MXOwsPEiqrUNA4E7PIvVLZ4BbrI48GVZcx3pgh8pSmE1l?= =?us-ascii?Q?loV82+NYMjH1vYfixdk4t0MNgVugdzc7VHQL62ytmcnm4pafct/jj5UQpNrk?= =?us-ascii?Q?hZ2BsYALy3Sn1OAvVrq6hxpXerJNQQQAl4/H/I6Y6lNjFLhflXOcz6ABNwKK?= =?us-ascii?Q?49C9OXjfCG2VkT8an/9CDbjNnuOXjzbcTwJwbymCpOFdhJbFJyPhy8YXDHyd?= =?us-ascii?Q?eheXNZ0eHh/1rdLbxv71D6+kd24XNG0i61IzXE+IV5qyz5hNR?= X-Microsoft-Exchange-Diagnostics: 1; CY1PR0201MB1834; 6:hv54Xd8o5ay1GVTaBzuY6KvrBaTyAFw7cOJSnsOiMlwU2EIL3H64LJgGPvswFebvkTwBpfDg4k+qcXB4p3DAtr+/2X4hbg8US/lbr1rlJ/mWOmPJAUK/TNsmtChoCnkauV/OB/sMleJ3UDOhl+jd1Q4Ke/g8Zg4QvWURyPEwUqbgt1v4TYsdhJwsq/OOa5JN+oMIoa0h0d9kVJDs/8KcvdelPXRogLoKVOkoHVv7yZqb4VqeFSrisrOoT0JdQMF0aKXXZfv4ShewRM2d+vfGpPHkrKsu5nN8tVCXbBm2MruUuTYiXQJORXurIhkm7pDVWxiwfYHEsyicwL1MUYTVrHUsrAqs8YdnB1U+g9irhiM=; 5:LsS3tjRl+YYEaqdj9rjhyM4s02A6umX7wyslXwKFuOvU80EWiLS4WJ8HgiAQfxwe2/2+Hm4c1CGe2oTQxdtDg6HXwLeKoqfXRQLtvZxocU6CiN9vzdmSAb7/PuvHC36PFrGHK3cE7CNpclzmOt9KSWcCbg//79B/MfDsKsXIAQY=; 24:d1flntzar8SN/3CQkI30Fz1PWpxsOPHQ9d+pOmOHEReqYbzAOnEVvfLIGdux8TV2tn5PZtb7KnK0LxTOI2Zr+IISB2ljuAR3DMIZKNlO+ps=; 7:U1709KAzNbE5t7LkhaKoo4E24gvtnaRluftTiqL3o2r9RRPD+UngCdUGw7kbHYPQTVBQjUX3pN1ocRKSjyb8TveFJM4+LzrTrbjpz+TLeu87expBr4Os4JjSjGGzCkV1RBWjfPHTydmwhozyWrGeEeiL1S0xPjgfqyKIdcw7GEqkHAn8lkhuvlvPqu1P56wASYwJzS7ZhpF3yEtTvIhLbs51bMpnc4vyKcalgJfJY1M30++yGjurIQtmMWtQAVF3 SpamDiagnosticOutput: 1:99 SpamDiagnosticMetadata: NSPM X-OriginatorOrg: microsemi.com X-MS-Exchange-CrossTenant-OriginalArrivalTime: 31 Oct 2017 15:58:59.4135 (UTC) X-MS-Exchange-CrossTenant-Network-Message-Id: 261e9ff3-5bbd-4ee2-1181-08d520784c9d X-MS-Exchange-CrossTenant-Id: f267a5c8-86d8-4cc9-af71-1fd2c67c8fad X-MS-Exchange-CrossTenant-OriginalAttributedTenantConnectingIp: TenantId=f267a5c8-86d8-4cc9-af71-1fd2c67c8fad; Ip=[208.19.100.20]; Helo=[avsrvexchhts2.microsemi.net] X-MS-Exchange-CrossTenant-FromEntityHeader: HybridOnPrem X-MS-Exchange-Transport-CrossTenantHeadersStamped: CY1PR0201MB1834 Archived-At: Subject: Re: [Ntp] Drafts on interleaved modes and correction field X-BeenThere: ntp@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 31 Oct 2017 15:59:35 -0000 --_000_8D2BF679AAC7C346848A489074F9F8BFF3535068sjsrvexchmbx2mi_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SW4gZ2VuZXJhbCwgbmV0d29yayBwcm90b2NvbHMgb3RoZXIgdGhhbiBQVFAgKGUuZy4sIE5UUCwg WS4xNTQ0KSB1c2UgYmVnaW5uaW5nIG9mIHRyYW5zbWl0IGFuZCBlbmQgb2YgcmVjZWlwdC4gIFBU UCB3YXMgc29tZXdoYXQgdW5pcXVlIGluIGl0cyBhd2FyZW5lc3Mgb2YgaGFyZHdhcmUgdGltZXN0 YW1waW5nIGF0IHRoZSBhcHBsaWNhdGlvbiBsYXllci4gIENhbiB3ZSBqdXN0IGZpeHVwIHRoZSB0 aW1lc3RhbXAgYXMgdGhlIGhhcmR3YXJlIHdpbGwga25vdyB0aGUgbGluayBzcGVlZD8NCg0K4oCm R3JlZw0KDQpGcm9tOiBudHAgW21haWx0bzpudHAtYm91bmNlc0BpZXRmLm9yZ10gT24gQmVoYWxm IE9mIFRhbCBNaXpyYWhpDQpTZW50OiBUdWVzZGF5LCBPY3RvYmVyIDMxLCAyMDE3IDg6MDAgQU0N ClRvOiBNaXJvc2xhdiBMaWNodmFyIDxtbGljaHZhckByZWRoYXQuY29tPg0KQ2M6IEFhbmNoYWwg TWFsaG90cmEgPGFhbmNoYWw0QGJ1LmVkdT47IG50cEBpZXRmLm9yZw0KU3ViamVjdDogUmU6IFtO dHBdIERyYWZ0cyBvbiBpbnRlcmxlYXZlZCBtb2RlcyBhbmQgY29ycmVjdGlvbiBmaWVsZA0KDQpF WFRFUk5BTCBFTUFJTA0KSGkgTWlyb3NsYXYsDQoNClRoYW5rcyBmb3IgdGhlIHF1aWNrIHJlc3Bv bnNlLg0KDQoNCj5XaXRoIE5UUCB0aGVyZSBpcyBnZW5lcmFsbHkgbm8gSFcgc3VwcG9ydCwgc28g Y2xpZW50cyBhbmQgc2VydmVycw0KPnNob3VsZCB1c2UgdHJhaWxlciBSWCB0aW1lc3RhbXBzIGFu ZCBwcmVhbWJsZSBUWCB0aW1lc3RhbXBzIHRvIGF2b2lkDQo+YW4gYXN5bW1ldHJpYyBkZWxheSB3 aXRoIGRpZmZlcmVudCBsaW5rIHNwZWVkcy4gVGhlIGZvbGxvd2luZyBkb2N1bWVudA0KPmV4cGxh aW5zIHRoZSBpc3N1ZSBuaWNlbHkuDQo+DQo+aHR0cHM6Ly93d3cuZWVjaXMudWRlbC5lZHUvfm1p bGxzL3N0YW1wLmh0bWwNCj4NCj5EbyB5b3UgdGhpbmsgaXQgd2lsbCBiZSBkaWZmaWN1bHQgdG8g aW1wbGVtZW50PyBJZiB0aGUgbGluayBzcGVlZCBhbmQNCj5sZW5ndGggb2YgdGhlIHBhY2tldCBp cyBrbm93biwgdGhlIHRpbWVzdGFtcCBjYW4gYmUgdHJhbnNwb3NlZC4NCg0KVGhlIGxpbmsgc3Bl ZWQgaXMgbm90IG5lY2Vzc2FyaWx5IGtub3duIHRvIHRoZSBlbmQgcG9pbnRzLiBGdXJ0aGVybW9y ZSwgdGhlIGxpbmsgc3BlZWQgbWF5IGNoYW5nZSBzZXZlcmFsIHRpbWVzIGFsb25nIHRoZSBwYXRo Lg0KTWF5YmUgSSBhbSBtaXNzaW5nIHNvbWV0aGluZywgYnV0IGl0IGFwcGVhcnMgdGhhdCB3aGVu IG1lYXN1cmluZyBsYXN0LWJpdC1pbi10by1maXJzdC1iaXQtb3V0IHdlIGFyZSBpZ25vcmluZyB0 aGUgcGFja2V0IHJlY2VwdGlvbiB0aW1lOyBpdCBzZWVtcyB0byBtYWtlIHNlbnNlIHRvIGluY2x1 ZGUgdGhlIHBhY2tldCByZWNlcHRpb24gdGltZSBpbiB0aGUgcmVzaWRlbmNlIHRpbWUuDQoNCk1v cmVvdmVyLCB3ZSBuZXZlciBrbm93IHdoaWNoIG5vZGVzIGFsb25nIHRoZSBwYXRoIHVzZSBzdG9y ZS1hbmQtZm9yd2FyZCwgYW5kIHdoaWNoIG5vZGVzIHVzZSBjdXQtdGhyb3VnaC4gSW4gY3V0LXRo cm91Z2ggZm9yd2FyZGluZyB0aGUgcGFja2V0IHRyYW5zbWlzc2lvbiBtYXkgc3RhcnQgYmVmb3Jl IHRoZSBsYXN0IGJpdCBpcyByZWNlaXZlZCwgc28gaXQgY2VydGFpbmx5IG1ha2VzIG1vcmUgc2Vu c2UgdG8gbWVhc3VyZSB0aGUgZmlyc3QtYml0LWluLXRvLWZpcnN0LWJpdC1vdXQuDQoNCg0KPlRo ZSByZWFzb24gZm9yIGEgc2VwYXJhdGUgdHJhbnNtaXQgY29ycmVjdGlvbiBpcyB0byBzdXBwb3J0 IHRoZQ0KPmludGVybGVhdmVkIG1vZGVzLiBUaGUgcmVjZWl2ZSBjb3JyZWN0aW9uIG1pZ2h0IG5v dCBiZSBuZWNlc3NhcnkuIElmDQo+eW91IGhhdmUgYSBiZXR0ZXIgdXNlIGZvciB0aGUgMiBvY3Rl dHMsIEkgdGhpbmsgaXQgY291bGQgYmUgZHJvcHBlZA0KPmFuZCBpbmNsdWRlZCBpbiB0aGUgb3Jp Z2luIGNvcnJlY3Rpb24gaW5zdGVhZC4NCg0KU28gaXQgbG9va3MgbGlrZSB0d28gY29ycmVjdGlv biBmaWVsZHMgd291bGQgc3VmZmljZTogb25lIGZvciB0aGUgZm9yd2FyZCBkaXJlY3Rpb24sIGFu ZCBvbmUgZm9yIHRoZSByZXZlcnNlIGRpcmVjdGlvbi4gUmlnaHQ/DQoNClRoYW5rcywNClRhbC4N Cg0KDQoNCg0KDQpPbiBUdWUsIE9jdCAzMSwgMjAxNyBhdCAzOjUyIFBNLCBNaXJvc2xhdiBMaWNo dmFyIDxtbGljaHZhckByZWRoYXQuY29tPG1haWx0bzptbGljaHZhckByZWRoYXQuY29tPj4gd3Jv dGU6DQpPbiBUdWUsIE9jdCAzMSwgMjAxNyBhdCAwMTo1Mzo1MlBNICswMjAwLCBUYWwgTWl6cmFo aSB3cm90ZToNCj4gUmVnYXJkaW5nIHRoZSBjb3JyZWN0aW9uIGZpZWxkIGRyYWZ0OiB2ZXJ5IGlu dGVyZXN0aW5nIGRyYWZ0Lg0KPg0KPiBBIGZldyBjb21tZW50czoNCg0KVGhhbmtzIGZvciB0aGUg Y29tbWVudHMsIFRhbC4NCg0KPiAxLiBTZWN0aW9uIDMgc2F5cyB0aGF0IHRoZSBkZWxheSBpcyB0 aGUgdGltZSBkaWZmZXJlbmNlIGJldHdlZW4gdGhlIGVuZCBvZg0KPiByZWNlcHRpb24gdW50aWwg dGhlIGJlZ2lubmluZyBvZiB0cmFuc21pc3Npb24uDQo+DQo+ICAgSXQgc2VlbXMgdG8gbWFrZSBt b3JlIHNlbnNlIHRvIG1lYXN1cmUgdGhlIGRlbGF5IGFzIHRoZSBiZWdpbm5pbmcgb2YNCj4gcmVj ZXB0aW9uIHVudGlsIHRoZSBiZWdpbm5pbmcgb2YgdHJhbnNtaXNzaW9uLCBiZWNhdXNlIHRoYXQg aXMgdGhlIGFjdHVhbA0KPiBkZWxheSBvZiB0aGUgcGFja2V0IGluIHByYWN0aWNlLiBCVFcsIHRo aXMgaXMgYWxzbyB0aGUgd2F5IElFRUUgMTU4OA0KPiBtZWFzdXJlcyB0aGUgY29ycmVjdGlvbkZp ZWxkLg0KDQpJIHRoaW5rIGl0IHNob3VsZCB0byBiZSB0aGUgc2FtZSBhcyB3aGF0IHRoZSBjbGll bnRzIGFuZCBzZXJ2ZXJzIHVzZSwNCm90aGVyd2lzZSBpdCB3b3VsZCBjcmVhdGUgYW4gYXN5bW1l dHJpYyBjb3JyZWN0aW9uIHdoZW4gc3dpdGNoaW5nDQpiZXR3ZWVuIGRpZmZlcmVudCBsaW5rIHNw ZWVkcy4NCg0KQXMgSSB1bmRlcnN0YW5kIGl0LCBQVFAgYXNzdW1lcyB0aGF0IGFsbCBkZXZpY2Vz IGluIHRoZSBuZXR3b3JrDQpzdXBwb3J0IFBUUCAoYXMgQkMgb3IgVEMpLCBzbyBpdCBjYW4gdGFr ZSB0aGUgc2ltcGxlciBhcHByb2NoIHVzaW5nDQpwcmVhbWJsZSB0aW1lc3RhbXBzIGZvciBib3Ro IFRYIGFuZCBSWC4NCg0KV2l0aCBOVFAgdGhlcmUgaXMgZ2VuZXJhbGx5IG5vIEhXIHN1cHBvcnQs IHNvIGNsaWVudHMgYW5kIHNlcnZlcnMNCnNob3VsZCB1c2UgdHJhaWxlciBSWCB0aW1lc3RhbXBz IGFuZCBwcmVhbWJsZSBUWCB0aW1lc3RhbXBzIHRvIGF2b2lkDQphbiBhc3ltbWV0cmljIGRlbGF5 IHdpdGggZGlmZmVyZW50IGxpbmsgc3BlZWRzLiBUaGUgZm9sbG93aW5nIGRvY3VtZW50DQpleHBs YWlucyB0aGUgaXNzdWUgbmljZWx5Lg0KDQpodHRwczovL3d3dy5lZWNpcy51ZGVsLmVkdS9+bWls bHMvc3RhbXAuaHRtbA0KDQpEbyB5b3UgdGhpbmsgaXQgd2lsbCBiZSBkaWZmaWN1bHQgdG8gaW1w bGVtZW50PyBJZiB0aGUgbGluayBzcGVlZCBhbmQNCmxlbmd0aCBvZiB0aGUgcGFja2V0IGlzIGtu b3duLCB0aGUgdGltZXN0YW1wIGNhbiBiZSB0cmFuc3Bvc2VkLg0KDQpJbiBhbnkgY2FzZSwgSSBn dWVzcyB0aGlzIHNob3VsZCBiZSBleHBsYWluZWQgaW4gdGhlIGRyYWZ0Lg0KDQo+IDIuICJUQkQ6 IFJlcXVpcmVtZW50cyBvbiBmcmVxdWVuY3kgYWNjdXJhY3kgb2YgdGhlIGNsb2NrLiINCj4NCj4g ICAgTlRQIGRvZXMgbm90IGRlZmluZSBhY2N1cmFjeSByZXF1aXJlbWVudHMsIGFuZCBJIHdvdWxk IHN1Z2dlc3QgdG8NCj4gcmVmcmFpbiBmcm9tIGRlZmluaW5nIHRoZXNlIGhlcmUgYXMgd2VsbC4N Cg0KT2ssIEkgd2FzIG5vdCByZWFsbHkgc3VyZSBob3cgaXQgd291bGQgYmUgc3BlY2lmaWVkLg0K DQo+IDMuICJEZWxheSBDb3JyZWN0aW9uIiAtIHBsZWFzZSBjb25zaWRlciB1c2luZyBhIGZvcm1h dCB0aGF0IGlzIGlkZW50aWNhbCB0bw0KPiB0aGUgb25lIGRlZmluZWQgaW4gSUVFRSAxNTg4Lg0K DQpEbyB5b3UgdGhpbmsgaXQgd2lsbCBiZSBlYXNpZXIgdG8gaW1wbGVtZW50IHRoYXQgd2F5PyBV c2luZyBhDQpuYW5vc2Vjb25kIGZpZWxkIGluIE5UUCBwYWNrZXRzIGZlZWxzIGRpcnR5IHRvIG1l IDopLg0KDQo+IDQuIFNlY3Rpb24gMiAtIGl0IHdvdWxkIGJlIGdyZWF0IGlmIHlvdSBjb3VsZCBj bGFyaWZ5IHRoZSBmaWVsZHMgIlJlY2VpdmUNCj4gQ29ycmVjdGlvbiIsICJUcmFuc21pdCBDb3Jy ZWN0aW9uIiwgYW5kICJPcmlnaW4gQ29ycmVjdGlvbiIuIEhhdmluZyByZWFkDQo+IHRoaXMgc2Vj dGlvbiBhIGNvdXBsZSBvZiB0aW1lcywgSSBjb3VsZCBub3QgZmlndXJlIG91dCB0aGUgdW5pdHMg b2YgdGhlc2UNCj4gZmllbGRzLCBob3cgdGhleSBhcmUgdXNlZCwgYW5kIHRoZSByYXRpb25hbGUg b2Ygd2h5IHRoZXNlIGZpZWxkcyBhcmUNCj4gcmVxdWlyZWQuDQoNCkFsbCB0aGVzZSBmaWVsZHMg YXJlIGluIDEvKDJeNDgpIG9mIGEgc2Vjb25kLiBUaGUgcmVjZWl2ZSBhbmQgdHJhbnNtaXQNCmNv cnJlY3Rpb25zIGFyZSBqdXN0IGV4dGVuc2lvbnMgb2YgdGhlIHJlY2VpdmUgYW5kIHRyYW5zbWl0 DQp0aW1lc3RhbXBzLiBXaGVuIHB1dCB0b2dldGhlciB0aGV5IG1ha2UgZml4ZWQgcG9pbnQgbnVt YmVycyB3aXRoIDMyDQppbnRlZ2VyIGJpdHMgYW5kIDMyICsgMTYgZnJhY3Rpb25hbCBiaXRzLg0K DQpUaGUgcmVhc29uIGZvciBhIHNlcGFyYXRlIG9yaWdpbiBmaWVsZCBpcyB0byBhbGxvdyB0aGUg Y2xpZW50IHRvIGNoZWNrDQpib3RoIHZhbHVlcyBiZWZvcmUgdGhleSBhcmUgYXBwbGllZC4gSWYg dGhlIHNlcnZlciBhZGp1c3RlZCBpdHMNCnRpbWVzdGFtcCBpbnN0ZWFkLCB0aGUgY2xpZW50IHdv dWxkbid0IGtub3cgYnkgaG93IG11Y2ggYW5kIGNvdWxkbid0DQpsaW1pdCB0aGUgaW1wYWN0IG9m IGEgTUlUTSBhdHRhY2suDQoNClRoZSByZWFzb24gZm9yIGEgc2VwYXJhdGUgdHJhbnNtaXQgY29y cmVjdGlvbiBpcyB0byBzdXBwb3J0IHRoZQ0KaW50ZXJsZWF2ZWQgbW9kZXMuIFRoZSByZWNlaXZl IGNvcnJlY3Rpb24gbWlnaHQgbm90IGJlIG5lY2Vzc2FyeS4gSWYNCnlvdSBoYXZlIGEgYmV0dGVy IHVzZSBmb3IgdGhlIDIgb2N0ZXRzLCBJIHRoaW5rIGl0IGNvdWxkIGJlIGRyb3BwZWQNCmFuZCBp bmNsdWRlZCBpbiB0aGUgb3JpZ2luIGNvcnJlY3Rpb24gaW5zdGVhZC4NCg0KPiA1LiAiVGhlIGRl dmljZSBNQVkgdXBkYXRlIHRoZSBjaGVja3N1bSBjb21wbGVtZW50IGZpZWxkIGluIG9yZGVyIHRv IGtlZXANCj4gdGhlIFVEUCBjaGVja3N1bSB2YWxpZC4iDQo+ICAgIFNpbmNlIHRoaXMgaXMgYSAi TUFZIiwgcGxlYXNlIGNsYXJpZnkgdGhlIGFsdGVybmF0aXZlczogZWl0aGVyIGNsZWFyIHRoZQ0K PiBVRFAgQ2hlY2tzdW0gZmllbGQgKGluIElQdjQgb25seSksIG9yIHJlY29tcHV0ZSB0aGUgVURQ IENoZWNrc3VtLg0KDQpHb29kIHBvaW50Lg0KDQo+IDYuIFNlY3VyaXR5IGNvbnNpZGVyYXRpb25z IC0gSSB3b3VsZCBwb2ludCBvdXQgdGhhdCBhbiBhdHRhY2tlciB0aGF0DQo+IHRhbXBlcnMgd2l0 aCB0aGUgY29ycmVjdGlvbiBleHRlbnNpb24gaXMgKHJvdWdobHkpIGVxdWl2YWxlbnQgdG8gYSBk ZWxheQ0KPiBhdHRhY2tlciBpbiB0ZXJtcyBvZiB0aGUgcG90ZW50aWFsIGRhbWFnZS4gVGhlcmVm b3JlLCBhcmd1YWJseSB0aGVyZSBpcyBubw0KPiBwb2ludCBpbiBzZWN1cmluZyB0aGUgY29ycmVj dGlvbiBleHRlbnNpb24uIEkgd291bGQgcmVjb21tZW5kIHRvIGxlYXZlIHRoZQ0KPiBjb3JyZWN0 aW9uIGV4dGVuc2lvbiBvdXQgb2YgdGhlIGludGVncml0eSBwcm90ZWN0aW9uLiBUaGlzIHBvc3Np YmlsaXR5IGlzDQo+IG1lbnRpb25lZCBvbiB0aGUgc2Vjb25kIHBhciBvZiBTZWN0aW9uIDcsIGJ1 dCBJIHdvdWxkIHN1Z2dlc3QgdG8gcmVwaHJhc2UNCj4gaXQgdG8gInRoaXMgaXMgd2hhdCB3ZSBy ZWNvbW1lbmQiLg0KDQpPaywgSSdsbCBkbyB0aGF0Lg0KDQo+IDcuIEZpbmFsbHksIG9uZSBtYXkg Y29uc2lkZXIgYSBzbGlnaHRseSBkaWZmZXJlbnQgYXBwcm9hY2gsIHdoZXJlIGVhY2ggaG9wDQo+ IGFsb25nIHRoZSBwYXRoIGFkZHMgYSBzZXBhcmF0ZSBleHRlbnNpb24gZmllbGQsIHJlcHJlc2Vu dGluZyB0aGUgcmVzaWRlbmNlDQo+IHRpbWUgb2YgdGhlIGN1cnJlbnQgaG9wLiBPYnZpb3VzbHkg dGhpcyBhcHByb2FjaCBoYXMgc29tZSBkaXNhZHZhbnRhZ2VzLA0KPiBidXQgdGhlIGFkdmFudGFn ZSBpcyB0aGF0IGl0IHByb3ZpZGVzIGRldGFpbGVkIGluZm9ybWF0aW9uIGFib3V0IHRoZSBkZWxh eQ0KPiBhbmQgZGVsYXkgdmFyaWF0aW9uIGluIGVhY2ggaG9wLiBUaGVyZSBpcyBhbHNvIHBvdGVu dGlhbCB0byBzZWN1cmUgZWFjaA0KPiBleHRlbnNpb24gZmllbGQgc2VwYXJhdGVseSB1c2luZyBp dHMgb3duIEhNQUMuIFNvbWV0aGluZyB0byBjb25zaWRlci4uLg0KDQpJIGRpZCBicmllZmx5IGNv bnNpZGVyIGFuIGFwcHJvYWNoIGxpa2UgdGhhdCwgYnV0IGl0IHNlZW1lZCB0byBtZQ0KdGhlcmUg YXJlIGF0IGxlYXN0IHR3byBpc3N1ZXM6DQotIEl0IG1heSBhbGxvdyB0cmFmZmljIGFtcGxpZmlj YXRpb24uDQotIFRoZSBncm93aW5nIGxlbmd0aCBvZiB0aGUgcGFja2V0IG1heSBjcmVhdGUgYW4g YXN5bW1ldHJpYyBkZWxheSwNCiAgd2hpY2ggSSBzdXNwZWN0IGNvdWxkIGJlIGNvbXBsZXRlbHkg YXZvaWRlZCBvbmx5IGluIHRoZSBjYXNlIHdoZXJlDQogIGFsbCBkZXZpY2VzIG9uIHRoZSBwYXRo IHN1cHBvcnQgdGhlIGNvcnJlY3Rpb24gZmllbGQgYW5kIHByZWFtYmxlDQogIHRpbWVzdGFtcHMg YXJlIHVzZWQgZXZlcnl3aGVyZS4NCg0KLS0NCk1pcm9zbGF2IExpY2h2YXINCg0K --_000_8D2BF679AAC7C346848A489074F9F8BFF3535068sjsrvexchmbx2mi_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTUgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6 IkNhbWJyaWEgTWF0aCI7DQoJcGFub3NlLTE6MiA0IDUgMyA1IDQgNiAzIDIgNDt9DQpAZm9udC1m YWNlDQoJe2ZvbnQtZmFtaWx5OkNhbGlicmk7DQoJcGFub3NlLTE6MiAxNSA1IDIgMiAyIDQgMyAy IDQ7fQ0KQGZvbnQtZmFjZQ0KCXtmb250LWZhbWlseTpDYW1icmlhOw0KCXBhbm9zZS0xOjIgNCA1 IDMgNSA0IDYgMyAyIDQ7fQ0KLyogU3R5bGUgRGVmaW5pdGlvbnMgKi8NCnAuTXNvTm9ybWFsLCBs aS5Nc29Ob3JtYWwsIGRpdi5Nc29Ob3JtYWwNCgl7bWFyZ2luOjBpbjsNCgltYXJnaW4tYm90dG9t Oi4wMDAxcHQ7DQoJZm9udC1zaXplOjExLjBwdDsNCglmb250LWZhbWlseToiQ2FsaWJyaSIsc2Fu cy1zZXJpZjt9DQphOmxpbmssIHNwYW4uTXNvSHlwZXJsaW5rDQoJe21zby1zdHlsZS1wcmlvcml0 eTo5OTsNCgljb2xvcjpibHVlOw0KCXRleHQtZGVjb3JhdGlvbjp1bmRlcmxpbmU7fQ0KYTp2aXNp dGVkLCBzcGFuLk1zb0h5cGVybGlua0ZvbGxvd2VkDQoJe21zby1zdHlsZS1wcmlvcml0eTo5OTsN Cgljb2xvcjpwdXJwbGU7DQoJdGV4dC1kZWNvcmF0aW9uOnVuZGVybGluZTt9DQpwLm1zb25vcm1h bDAsIGxpLm1zb25vcm1hbDAsIGRpdi5tc29ub3JtYWwwDQoJe21zby1zdHlsZS1uYW1lOm1zb25v cm1hbDsNCgltc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzsNCgltYXJnaW4tcmlnaHQ6MGluOw0KCW1z by1tYXJnaW4tYm90dG9tLWFsdDphdXRvOw0KCW1hcmdpbi1sZWZ0OjBpbjsNCglmb250LXNpemU6 MTEuMHB0Ow0KCWZvbnQtZmFtaWx5OiJDYWxpYnJpIixzYW5zLXNlcmlmO30NCnNwYW4uZ21haWwt DQoJe21zby1zdHlsZS1uYW1lOmdtYWlsLTt9DQpzcGFuLmdtYWlsLWhvZW56Yg0KCXttc28tc3R5 bGUtbmFtZTpnbWFpbC1ob2VuemI7fQ0Kc3Bhbi5FbWFpbFN0eWxlMjANCgl7bXNvLXN0eWxlLXR5 cGU6cGVyc29uYWwtcmVwbHk7DQoJZm9udC1mYW1pbHk6IkNhbGlicmkiLHNhbnMtc2VyaWY7DQoJ Y29sb3I6d2luZG93dGV4dDt9DQouTXNvQ2hwRGVmYXVsdA0KCXttc28tc3R5bGUtdHlwZTpleHBv cnQtb25seTsNCglmb250LXNpemU6MTAuMHB0O30NCkBwYWdlIFdvcmRTZWN0aW9uMQ0KCXtzaXpl OjguNWluIDExLjBpbjsNCgltYXJnaW46MS4waW4gMS4waW4gMS4waW4gMS4waW47fQ0KZGl2Lldv cmRTZWN0aW9uMQ0KCXtwYWdlOldvcmRTZWN0aW9uMTt9DQotLT48L3N0eWxlPjwhLS1baWYgZ3Rl IG1zbyA5XT48eG1sPg0KPG86c2hhcGVkZWZhdWx0cyB2OmV4dD0iZWRpdCIgc3BpZG1heD0iMTAy NiIgLz4NCjwveG1sPjwhW2VuZGlmXS0tPjwhLS1baWYgZ3RlIG1zbyA5XT48eG1sPg0KPG86c2hh cGVsYXlvdXQgdjpleHQ9ImVkaXQiPg0KPG86aWRtYXAgdjpleHQ9ImVkaXQiIGRhdGE9IjEiIC8+ DQo8L286c2hhcGVsYXlvdXQ+PC94bWw+PCFbZW5kaWZdLS0+DQo8L2hlYWQ+DQo8Ym9keSBsYW5n PSJFTi1VUyIgbGluaz0iYmx1ZSIgdmxpbms9InB1cnBsZSI+DQo8ZGl2IGNsYXNzPSJXb3JkU2Vj dGlvbjEiPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+SW4gZ2VuZXJhbCwgbmV0d29yayBwcm90b2Nv bHMgb3RoZXIgdGhhbiBQVFAgKGUuZy4sIE5UUCwgWS4xNTQ0KSB1c2UgYmVnaW5uaW5nIG9mIHRy YW5zbWl0IGFuZCBlbmQgb2YgcmVjZWlwdC4mbmJzcDsgUFRQIHdhcyBzb21ld2hhdCB1bmlxdWUg aW4gaXRzIGF3YXJlbmVzcyBvZiBoYXJkd2FyZSB0aW1lc3RhbXBpbmcgYXQgdGhlIGFwcGxpY2F0 aW9uIGxheWVyLiZuYnNwOyBDYW4gd2UganVzdCBmaXh1cCB0aGUgdGltZXN0YW1wDQogYXMgdGhl IGhhcmR3YXJlIHdpbGwga25vdyB0aGUgbGluayBzcGVlZD88bzpwPjwvbzpwPjwvcD4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1h bCI+4oCmR3JlZzxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJz cDs8L286cD48L3A+DQo8ZGl2Pg0KPGRpdiBzdHlsZT0iYm9yZGVyOm5vbmU7Ym9yZGVyLXRvcDpz b2xpZCAjRTFFMUUxIDEuMHB0O3BhZGRpbmc6My4wcHQgMGluIDBpbiAwaW4iPg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCI+PGI+RnJvbTo8L2I+IG50cCBbbWFpbHRvOm50cC1ib3VuY2VzQGlldGYub3Jn XSA8Yj5PbiBCZWhhbGYgT2YNCjwvYj5UYWwgTWl6cmFoaTxicj4NCjxiPlNlbnQ6PC9iPiBUdWVz ZGF5LCBPY3RvYmVyIDMxLCAyMDE3IDg6MDAgQU08YnI+DQo8Yj5Ubzo8L2I+IE1pcm9zbGF2IExp Y2h2YXIgJmx0O21saWNodmFyQHJlZGhhdC5jb20mZ3Q7PGJyPg0KPGI+Q2M6PC9iPiBBYW5jaGFs IE1hbGhvdHJhICZsdDthYW5jaGFsNEBidS5lZHUmZ3Q7OyBudHBAaWV0Zi5vcmc8YnI+DQo8Yj5T dWJqZWN0OjwvYj4gUmU6IFtOdHBdIERyYWZ0cyBvbiBpbnRlcmxlYXZlZCBtb2RlcyBhbmQgY29y cmVjdGlvbiBmaWVsZDxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5 bGU9Im1hcmdpbi1ib3R0b206MTIuMHB0Ij48c3BhbiBzdHlsZT0iZm9udC1zaXplOjE0LjBwdDtm b250LWZhbWlseTomcXVvdDtDYW1icmlhJnF1b3Q7LHNlcmlmO2NvbG9yOnJlZCI+RVhURVJOQUwg RU1BSUw8L3NwYW4+PG86cD48L286cD48L3A+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29O b3JtYWwiPkhpIE1pcm9zbGF2LCA8bzpwPjwvbzpwPjwvcD4NCjxkaXY+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiPlRoYW5rcyBmb3IgdGhlIHF1aWNrIHJlc3BvbnNlLjxvOnA+PC9vOnA+PC9wPg0K PC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+ DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwv cD4NCjwvZGl2Pg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj4mZ3Q7V2l0aCBO VFAgdGhlcmUgaXMgZ2VuZXJhbGx5IG5vIEhXIHN1cHBvcnQsIHNvIGNsaWVudHMgYW5kIHNlcnZl cnM8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPiZn dDtzaG91bGQgdXNlIHRyYWlsZXIgUlggdGltZXN0YW1wcyBhbmQgcHJlYW1ibGUgVFggdGltZXN0 YW1wcyB0byBhdm9pZDxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1z b05vcm1hbCI+Jmd0O2FuIGFzeW1tZXRyaWMgZGVsYXkgd2l0aCBkaWZmZXJlbnQgbGluayBzcGVl ZHMuIFRoZSBmb2xsb3dpbmcgZG9jdW1lbnQ8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiPiZndDtleHBsYWlucyB0aGUgaXNzdWUgbmljZWx5LjxvOnA+ PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+Jmd0OzxvOnA+ Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+Jmd0 OzxhIGhyZWY9Imh0dHBzOi8vd3d3LmVlY2lzLnVkZWwuZWR1L35taWxscy9zdGFtcC5odG1sIj5o dHRwczovL3d3dy5lZWNpcy51ZGVsLmVkdS9+bWlsbHMvc3RhbXAuaHRtbDwvYT48bzpwPjwvbzpw PjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPiZndDs8bzpwPiZuYnNw OzwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPiZndDtEbyB5 b3UgdGhpbmsgaXQgd2lsbCBiZSBkaWZmaWN1bHQgdG8gaW1wbGVtZW50PyBJZiB0aGUgbGluayBz cGVlZCBhbmQ8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiPiZndDtsZW5ndGggb2YgdGhlIHBhY2tldCBpcyBrbm93biwgdGhlIHRpbWVzdGFtcCBjYW4g YmUgdHJhbnNwb3NlZC48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8ZGl2Pg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIj5UaGUgbGluayBzcGVlZCBpcyBub3QgbmVjZXNzYXJpbHkga25v d24gdG8gdGhlIGVuZCBwb2ludHMuIEZ1cnRoZXJtb3JlLCB0aGUgbGluayBzcGVlZCBtYXkgY2hh bmdlIHNldmVyYWwgdGltZXMgYWxvbmcgdGhlIHBhdGguPG86cD48L286cD48L3A+DQo8L2Rpdj4N CjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5NYXliZSBJIGFtIG1pc3Npbmcgc29tZXRoaW5n LCBidXQgaXQgYXBwZWFycyB0aGF0IHdoZW4gbWVhc3VyaW5nIGxhc3QtYml0LWluLXRvLWZpcnN0 LWJpdC1vdXQgd2UgYXJlIGlnbm9yaW5nIHRoZSBwYWNrZXQgcmVjZXB0aW9uIHRpbWU7IGl0IHNl ZW1zIHRvIG1ha2Ugc2Vuc2UgdG8gaW5jbHVkZSB0aGUgcGFja2V0IHJlY2VwdGlvbiB0aW1lIGlu IHRoZSByZXNpZGVuY2UgdGltZS48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCI+TW9yZW92ZXIsIHdlIG5ldmVyIGtub3cgd2hpY2ggbm9kZXMgYWxv bmcgdGhlIHBhdGggdXNlIHN0b3JlLWFuZC1mb3J3YXJkLCBhbmQgd2hpY2ggbm9kZXMgdXNlIGN1 dC10aHJvdWdoLiBJbiBjdXQtdGhyb3VnaCBmb3J3YXJkaW5nIHRoZSBwYWNrZXQgdHJhbnNtaXNz aW9uIG1heSBzdGFydCBiZWZvcmUgdGhlIGxhc3QgYml0IGlzIHJlY2VpdmVkLCBzbyBpdCBjZXJ0 YWlubHkgbWFrZXMgbW9yZSBzZW5zZSB0bw0KIG1lYXN1cmUgdGhlIGZpcnN0LWJpdC1pbi10by1m aXJzdC1iaXQtb3V0LjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1z b05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxkaXY+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIj4mZ3Q7VGhlIHJlYXNvbiBmb3IgYSBzZXBhcmF0ZSB0cmFuc21p dCBjb3JyZWN0aW9uIGlzIHRvIHN1cHBvcnQgdGhlPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxk aXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj4mZ3Q7aW50ZXJsZWF2ZWQgbW9kZXMuIFRoZSByZWNl aXZlIGNvcnJlY3Rpb24gbWlnaHQgbm90IGJlIG5lY2Vzc2FyeS4gSWY8bzpwPjwvbzpwPjwvcD4N CjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPiZndDt5b3UgaGF2ZSBhIGJldHRl ciB1c2UgZm9yIHRoZSAyIG9jdGV0cywgSSB0aGluayBpdCBjb3VsZCBiZSBkcm9wcGVkPG86cD48 L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj4mZ3Q7YW5kIGlu Y2x1ZGVkIGluIHRoZSBvcmlnaW4gY29ycmVjdGlvbiBpbnN0ZWFkLjxvOnA+PC9vOnA+PC9wPg0K PC9kaXY+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwv bzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPlNvIGl0IGxvb2tz IGxpa2UgdHdvIGNvcnJlY3Rpb24gZmllbGRzIHdvdWxkIHN1ZmZpY2U6IG9uZSBmb3IgdGhlIGZv cndhcmQgZGlyZWN0aW9uLCBhbmQgb25lIGZvciB0aGUgcmV2ZXJzZSBkaXJlY3Rpb24uIFJpZ2h0 PzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86 cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5U aGFua3MsPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFs Ij5UYWwuPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFs Ij48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05v cm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiPk9uIFR1ZSwgT2N0IDMxLCAyMDE3IGF0IDM6NTIgUE0sIE1pcm9zbGF2IExpY2h2YXIgJmx0 OzxhIGhyZWY9Im1haWx0bzptbGljaHZhckByZWRoYXQuY29tIiB0YXJnZXQ9Il9ibGFuayI+bWxp Y2h2YXJAcmVkaGF0LmNvbTwvYT4mZ3Q7IHdyb3RlOjxvOnA+PC9vOnA+PC9wPg0KPGJsb2NrcXVv dGUgc3R5bGU9ImJvcmRlcjpub25lO2JvcmRlci1sZWZ0OnNvbGlkICNDQ0NDQ0MgMS4wcHQ7cGFk ZGluZzowaW4gMGluIDBpbiA2LjBwdDttYXJnaW4tbGVmdDo0LjhwdDttYXJnaW4tcmlnaHQ6MGlu Ij4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGNsYXNzPSJnbWFpbC0iPk9uIFR1ZSwgT2N0 IDMxLCAyMDE3IGF0IDAxOjUzOjUyUE0gJiM0MzswMjAwLCBUYWwgTWl6cmFoaSB3cm90ZTo8L3Nw YW4+PGJyPg0KPHNwYW4gY2xhc3M9ImdtYWlsLSI+Jmd0OyBSZWdhcmRpbmcgdGhlIGNvcnJlY3Rp b24gZmllbGQgZHJhZnQ6IHZlcnkgaW50ZXJlc3RpbmcgZHJhZnQuPC9zcGFuPjxicj4NCjxzcGFu IGNsYXNzPSJnbWFpbC0iPiZndDs8L3NwYW4+PGJyPg0KPHNwYW4gY2xhc3M9ImdtYWlsLSI+Jmd0 OyBBIGZldyBjb21tZW50czo8L3NwYW4+PGJyPg0KPGJyPg0KVGhhbmtzIGZvciB0aGUgY29tbWVu dHMsIFRhbC48YnI+DQo8YnI+DQo8c3BhbiBjbGFzcz0iZ21haWwtIj4mZ3Q7IDEuIFNlY3Rpb24g MyBzYXlzIHRoYXQgdGhlIGRlbGF5IGlzIHRoZSB0aW1lIGRpZmZlcmVuY2UgYmV0d2VlbiB0aGUg ZW5kIG9mPC9zcGFuPjxicj4NCjxzcGFuIGNsYXNzPSJnbWFpbC0iPiZndDsgcmVjZXB0aW9uIHVu dGlsIHRoZSBiZWdpbm5pbmcgb2YgdHJhbnNtaXNzaW9uLjwvc3Bhbj48YnI+DQo8c3BhbiBjbGFz cz0iZ21haWwtIj4mZ3Q7PC9zcGFuPjxicj4NCjxzcGFuIGNsYXNzPSJnbWFpbC0iPiZndDsmbmJz cDsgJm5ic3A7SXQgc2VlbXMgdG8gbWFrZSBtb3JlIHNlbnNlIHRvIG1lYXN1cmUgdGhlIGRlbGF5 IGFzIHRoZSBiZWdpbm5pbmcgb2Y8L3NwYW4+PGJyPg0KPHNwYW4gY2xhc3M9ImdtYWlsLSI+Jmd0 OyByZWNlcHRpb24gdW50aWwgdGhlIGJlZ2lubmluZyBvZiB0cmFuc21pc3Npb24sIGJlY2F1c2Ug dGhhdCBpcyB0aGUgYWN0dWFsPC9zcGFuPjxicj4NCjxzcGFuIGNsYXNzPSJnbWFpbC0iPiZndDsg ZGVsYXkgb2YgdGhlIHBhY2tldCBpbiBwcmFjdGljZS4gQlRXLCB0aGlzIGlzIGFsc28gdGhlIHdh eSBJRUVFIDE1ODg8L3NwYW4+PGJyPg0KPHNwYW4gY2xhc3M9ImdtYWlsLSI+Jmd0OyBtZWFzdXJl cyB0aGUgY29ycmVjdGlvbkZpZWxkLjwvc3Bhbj48YnI+DQo8YnI+DQpJIHRoaW5rIGl0IHNob3Vs ZCB0byBiZSB0aGUgc2FtZSBhcyB3aGF0IHRoZSBjbGllbnRzIGFuZCBzZXJ2ZXJzIHVzZSw8YnI+ DQpvdGhlcndpc2UgaXQgd291bGQgY3JlYXRlIGFuIGFzeW1tZXRyaWMgY29ycmVjdGlvbiB3aGVu IHN3aXRjaGluZzxicj4NCmJldHdlZW4gZGlmZmVyZW50IGxpbmsgc3BlZWRzLjxicj4NCjxicj4N CkFzIEkgdW5kZXJzdGFuZCBpdCwgUFRQIGFzc3VtZXMgdGhhdCBhbGwgZGV2aWNlcyBpbiB0aGUg bmV0d29yazxicj4NCnN1cHBvcnQgUFRQIChhcyBCQyBvciBUQyksIHNvIGl0IGNhbiB0YWtlIHRo ZSBzaW1wbGVyIGFwcHJvY2ggdXNpbmc8YnI+DQpwcmVhbWJsZSB0aW1lc3RhbXBzIGZvciBib3Ro IFRYIGFuZCBSWC48YnI+DQo8YnI+DQpXaXRoIE5UUCB0aGVyZSBpcyBnZW5lcmFsbHkgbm8gSFcg c3VwcG9ydCwgc28gY2xpZW50cyBhbmQgc2VydmVyczxicj4NCnNob3VsZCB1c2UgdHJhaWxlciBS WCB0aW1lc3RhbXBzIGFuZCBwcmVhbWJsZSBUWCB0aW1lc3RhbXBzIHRvIGF2b2lkPGJyPg0KYW4g YXN5bW1ldHJpYyBkZWxheSB3aXRoIGRpZmZlcmVudCBsaW5rIHNwZWVkcy4gVGhlIGZvbGxvd2lu ZyBkb2N1bWVudDxicj4NCmV4cGxhaW5zIHRoZSBpc3N1ZSBuaWNlbHkuPGJyPg0KPGJyPg0KPGEg aHJlZj0iaHR0cHM6Ly93d3cuZWVjaXMudWRlbC5lZHUvfm1pbGxzL3N0YW1wLmh0bWwiIHRhcmdl dD0iX2JsYW5rIj5odHRwczovL3d3dy5lZWNpcy51ZGVsLmVkdS9+bWlsbHMvc3RhbXAuaHRtbDwv YT48YnI+DQo8YnI+DQpEbyB5b3UgdGhpbmsgaXQgd2lsbCBiZSBkaWZmaWN1bHQgdG8gaW1wbGVt ZW50PyBJZiB0aGUgbGluayBzcGVlZCBhbmQ8YnI+DQpsZW5ndGggb2YgdGhlIHBhY2tldCBpcyBr bm93biwgdGhlIHRpbWVzdGFtcCBjYW4gYmUgdHJhbnNwb3NlZC48YnI+DQo8YnI+DQpJbiBhbnkg Y2FzZSwgSSBndWVzcyB0aGlzIHNob3VsZCBiZSBleHBsYWluZWQgaW4gdGhlIGRyYWZ0Ljxicj4N Cjxicj4NCjxzcGFuIGNsYXNzPSJnbWFpbC0iPiZndDsgMi4gJnF1b3Q7VEJEOiBSZXF1aXJlbWVu dHMgb24gZnJlcXVlbmN5IGFjY3VyYWN5IG9mIHRoZSBjbG9jay4mcXVvdDs8L3NwYW4+PGJyPg0K PHNwYW4gY2xhc3M9ImdtYWlsLSI+Jmd0Ozwvc3Bhbj48YnI+DQo8c3BhbiBjbGFzcz0iZ21haWwt Ij4mZ3Q7Jm5ic3A7ICZuYnNwOyBOVFAgZG9lcyBub3QgZGVmaW5lIGFjY3VyYWN5IHJlcXVpcmVt ZW50cywgYW5kIEkgd291bGQgc3VnZ2VzdCB0bzwvc3Bhbj48YnI+DQo8c3BhbiBjbGFzcz0iZ21h aWwtIj4mZ3Q7IHJlZnJhaW4gZnJvbSBkZWZpbmluZyB0aGVzZSBoZXJlIGFzIHdlbGwuPC9zcGFu Pjxicj4NCjxicj4NCk9rLCBJIHdhcyBub3QgcmVhbGx5IHN1cmUgaG93IGl0IHdvdWxkIGJlIHNw ZWNpZmllZC48YnI+DQo8YnI+DQo8c3BhbiBjbGFzcz0iZ21haWwtIj4mZ3Q7IDMuICZxdW90O0Rl bGF5IENvcnJlY3Rpb24mcXVvdDsgLSBwbGVhc2UgY29uc2lkZXIgdXNpbmcgYSBmb3JtYXQgdGhh dCBpcyBpZGVudGljYWwgdG88L3NwYW4+PGJyPg0KPHNwYW4gY2xhc3M9ImdtYWlsLSI+Jmd0OyB0 aGUgb25lIGRlZmluZWQgaW4gSUVFRSAxNTg4Ljwvc3Bhbj48YnI+DQo8YnI+DQpEbyB5b3UgdGhp bmsgaXQgd2lsbCBiZSBlYXNpZXIgdG8gaW1wbGVtZW50IHRoYXQgd2F5PyBVc2luZyBhPGJyPg0K bmFub3NlY29uZCBmaWVsZCBpbiBOVFAgcGFja2V0cyBmZWVscyBkaXJ0eSB0byBtZSA6KS48YnI+ DQo8YnI+DQo8c3BhbiBjbGFzcz0iZ21haWwtIj4mZ3Q7IDQuIFNlY3Rpb24gMiAtIGl0IHdvdWxk IGJlIGdyZWF0IGlmIHlvdSBjb3VsZCBjbGFyaWZ5IHRoZSBmaWVsZHMgJnF1b3Q7UmVjZWl2ZTwv c3Bhbj48YnI+DQo8c3BhbiBjbGFzcz0iZ21haWwtIj4mZ3Q7IENvcnJlY3Rpb24mcXVvdDssICZx dW90O1RyYW5zbWl0IENvcnJlY3Rpb24mcXVvdDssIGFuZCAmcXVvdDtPcmlnaW4gQ29ycmVjdGlv biZxdW90Oy4gSGF2aW5nIHJlYWQ8L3NwYW4+PGJyPg0KPHNwYW4gY2xhc3M9ImdtYWlsLSI+Jmd0 OyB0aGlzIHNlY3Rpb24gYSBjb3VwbGUgb2YgdGltZXMsIEkgY291bGQgbm90IGZpZ3VyZSBvdXQg dGhlIHVuaXRzIG9mIHRoZXNlPC9zcGFuPjxicj4NCjxzcGFuIGNsYXNzPSJnbWFpbC0iPiZndDsg ZmllbGRzLCBob3cgdGhleSBhcmUgdXNlZCwgYW5kIHRoZSByYXRpb25hbGUgb2Ygd2h5IHRoZXNl IGZpZWxkcyBhcmU8L3NwYW4+PGJyPg0KPHNwYW4gY2xhc3M9ImdtYWlsLSI+Jmd0OyByZXF1aXJl ZC48L3NwYW4+PGJyPg0KPGJyPg0KQWxsIHRoZXNlIGZpZWxkcyBhcmUgaW4gMS8oMl40OCkgb2Yg YSBzZWNvbmQuIFRoZSByZWNlaXZlIGFuZCB0cmFuc21pdDxicj4NCmNvcnJlY3Rpb25zIGFyZSBq dXN0IGV4dGVuc2lvbnMgb2YgdGhlIHJlY2VpdmUgYW5kIHRyYW5zbWl0PGJyPg0KdGltZXN0YW1w cy4gV2hlbiBwdXQgdG9nZXRoZXIgdGhleSBtYWtlIGZpeGVkIHBvaW50IG51bWJlcnMgd2l0aCAz Mjxicj4NCmludGVnZXIgYml0cyBhbmQgMzIgJiM0MzsgMTYgZnJhY3Rpb25hbCBiaXRzLjxicj4N Cjxicj4NClRoZSByZWFzb24gZm9yIGEgc2VwYXJhdGUgb3JpZ2luIGZpZWxkIGlzIHRvIGFsbG93 IHRoZSBjbGllbnQgdG8gY2hlY2s8YnI+DQpib3RoIHZhbHVlcyBiZWZvcmUgdGhleSBhcmUgYXBw bGllZC4gSWYgdGhlIHNlcnZlciBhZGp1c3RlZCBpdHM8YnI+DQp0aW1lc3RhbXAgaW5zdGVhZCwg dGhlIGNsaWVudCB3b3VsZG4ndCBrbm93IGJ5IGhvdyBtdWNoIGFuZCBjb3VsZG4ndDxicj4NCmxp bWl0IHRoZSBpbXBhY3Qgb2YgYSBNSVRNIGF0dGFjay48YnI+DQo8YnI+DQpUaGUgcmVhc29uIGZv ciBhIHNlcGFyYXRlIHRyYW5zbWl0IGNvcnJlY3Rpb24gaXMgdG8gc3VwcG9ydCB0aGU8YnI+DQpp bnRlcmxlYXZlZCBtb2Rlcy4gVGhlIHJlY2VpdmUgY29ycmVjdGlvbiBtaWdodCBub3QgYmUgbmVj ZXNzYXJ5LiBJZjxicj4NCnlvdSBoYXZlIGEgYmV0dGVyIHVzZSBmb3IgdGhlIDIgb2N0ZXRzLCBJ IHRoaW5rIGl0IGNvdWxkIGJlIGRyb3BwZWQ8YnI+DQphbmQgaW5jbHVkZWQgaW4gdGhlIG9yaWdp biBjb3JyZWN0aW9uIGluc3RlYWQuPGJyPg0KPGJyPg0KPHNwYW4gY2xhc3M9ImdtYWlsLSI+Jmd0 OyA1LiAmcXVvdDtUaGUgZGV2aWNlIE1BWSB1cGRhdGUgdGhlIGNoZWNrc3VtIGNvbXBsZW1lbnQg ZmllbGQgaW4gb3JkZXIgdG8ga2VlcDwvc3Bhbj48YnI+DQo8c3BhbiBjbGFzcz0iZ21haWwtIj4m Z3Q7IHRoZSBVRFAgY2hlY2tzdW0gdmFsaWQuJnF1b3Q7PC9zcGFuPjxicj4NCjxzcGFuIGNsYXNz PSJnbWFpbC0iPiZndDsmbmJzcDsgJm5ic3A7IFNpbmNlIHRoaXMgaXMgYSAmcXVvdDtNQVkmcXVv dDssIHBsZWFzZSBjbGFyaWZ5IHRoZSBhbHRlcm5hdGl2ZXM6IGVpdGhlciBjbGVhciB0aGU8L3Nw YW4+PGJyPg0KPHNwYW4gY2xhc3M9ImdtYWlsLSI+Jmd0OyBVRFAgQ2hlY2tzdW0gZmllbGQgKGlu IElQdjQgb25seSksIG9yIHJlY29tcHV0ZSB0aGUgVURQIENoZWNrc3VtLjwvc3Bhbj48YnI+DQo8 YnI+DQpHb29kIHBvaW50Ljxicj4NCjxicj4NCjxzcGFuIGNsYXNzPSJnbWFpbC0iPiZndDsgNi4g U2VjdXJpdHkgY29uc2lkZXJhdGlvbnMgLSBJIHdvdWxkIHBvaW50IG91dCB0aGF0IGFuIGF0dGFj a2VyIHRoYXQ8L3NwYW4+PGJyPg0KPHNwYW4gY2xhc3M9ImdtYWlsLSI+Jmd0OyB0YW1wZXJzIHdp dGggdGhlIGNvcnJlY3Rpb24gZXh0ZW5zaW9uIGlzIChyb3VnaGx5KSBlcXVpdmFsZW50IHRvIGEg ZGVsYXk8L3NwYW4+PGJyPg0KPHNwYW4gY2xhc3M9ImdtYWlsLSI+Jmd0OyBhdHRhY2tlciBpbiB0 ZXJtcyBvZiB0aGUgcG90ZW50aWFsIGRhbWFnZS4gVGhlcmVmb3JlLCBhcmd1YWJseSB0aGVyZSBp cyBubzwvc3Bhbj48YnI+DQo8c3BhbiBjbGFzcz0iZ21haWwtIj4mZ3Q7IHBvaW50IGluIHNlY3Vy aW5nIHRoZSBjb3JyZWN0aW9uIGV4dGVuc2lvbi4gSSB3b3VsZCByZWNvbW1lbmQgdG8gbGVhdmUg dGhlPC9zcGFuPjxicj4NCjxzcGFuIGNsYXNzPSJnbWFpbC0iPiZndDsgY29ycmVjdGlvbiBleHRl bnNpb24gb3V0IG9mIHRoZSBpbnRlZ3JpdHkgcHJvdGVjdGlvbi4gVGhpcyBwb3NzaWJpbGl0eSBp czwvc3Bhbj48YnI+DQo8c3BhbiBjbGFzcz0iZ21haWwtIj4mZ3Q7IG1lbnRpb25lZCBvbiB0aGUg c2Vjb25kIHBhciBvZiBTZWN0aW9uIDcsIGJ1dCBJIHdvdWxkIHN1Z2dlc3QgdG8gcmVwaHJhc2U8 L3NwYW4+PGJyPg0KPHNwYW4gY2xhc3M9ImdtYWlsLSI+Jmd0OyBpdCB0byAmcXVvdDt0aGlzIGlz IHdoYXQgd2UgcmVjb21tZW5kJnF1b3Q7Ljwvc3Bhbj48YnI+DQo8YnI+DQpPaywgSSdsbCBkbyB0 aGF0Ljxicj4NCjxicj4NCjxzcGFuIGNsYXNzPSJnbWFpbC0iPiZndDsgNy4gRmluYWxseSwgb25l IG1heSBjb25zaWRlciBhIHNsaWdodGx5IGRpZmZlcmVudCBhcHByb2FjaCwgd2hlcmUgZWFjaCBo b3A8L3NwYW4+PGJyPg0KPHNwYW4gY2xhc3M9ImdtYWlsLSI+Jmd0OyBhbG9uZyB0aGUgcGF0aCBh ZGRzIGEgc2VwYXJhdGUgZXh0ZW5zaW9uIGZpZWxkLCByZXByZXNlbnRpbmcgdGhlIHJlc2lkZW5j ZTwvc3Bhbj48YnI+DQo8c3BhbiBjbGFzcz0iZ21haWwtIj4mZ3Q7IHRpbWUgb2YgdGhlIGN1cnJl bnQgaG9wLiBPYnZpb3VzbHkgdGhpcyBhcHByb2FjaCBoYXMgc29tZSBkaXNhZHZhbnRhZ2VzLDwv c3Bhbj48YnI+DQo8c3BhbiBjbGFzcz0iZ21haWwtIj4mZ3Q7IGJ1dCB0aGUgYWR2YW50YWdlIGlz IHRoYXQgaXQgcHJvdmlkZXMgZGV0YWlsZWQgaW5mb3JtYXRpb24gYWJvdXQgdGhlIGRlbGF5PC9z cGFuPjxicj4NCjxzcGFuIGNsYXNzPSJnbWFpbC0iPiZndDsgYW5kIGRlbGF5IHZhcmlhdGlvbiBp biBlYWNoIGhvcC4gVGhlcmUgaXMgYWxzbyBwb3RlbnRpYWwgdG8gc2VjdXJlIGVhY2g8L3NwYW4+ PGJyPg0KPHNwYW4gY2xhc3M9ImdtYWlsLSI+Jmd0OyBleHRlbnNpb24gZmllbGQgc2VwYXJhdGVs eSB1c2luZyBpdHMgb3duIEhNQUMuIFNvbWV0aGluZyB0byBjb25zaWRlci4uLjwvc3Bhbj48YnI+ DQo8YnI+DQpJIGRpZCBicmllZmx5IGNvbnNpZGVyIGFuIGFwcHJvYWNoIGxpa2UgdGhhdCwgYnV0 IGl0IHNlZW1lZCB0byBtZTxicj4NCnRoZXJlIGFyZSBhdCBsZWFzdCB0d28gaXNzdWVzOjxicj4N Ci0gSXQgbWF5IGFsbG93IHRyYWZmaWMgYW1wbGlmaWNhdGlvbi48YnI+DQotIFRoZSBncm93aW5n IGxlbmd0aCBvZiB0aGUgcGFja2V0IG1heSBjcmVhdGUgYW4gYXN5bW1ldHJpYyBkZWxheSw8YnI+ DQombmJzcDsgd2hpY2ggSSBzdXNwZWN0IGNvdWxkIGJlIGNvbXBsZXRlbHkgYXZvaWRlZCBvbmx5 IGluIHRoZSBjYXNlIHdoZXJlPGJyPg0KJm5ic3A7IGFsbCBkZXZpY2VzIG9uIHRoZSBwYXRoIHN1 cHBvcnQgdGhlIGNvcnJlY3Rpb24gZmllbGQgYW5kIHByZWFtYmxlPGJyPg0KJm5ic3A7IHRpbWVz dGFtcHMgYXJlIHVzZWQgZXZlcnl3aGVyZS48YnI+DQo8c3BhbiBzdHlsZT0iY29sb3I6Izg4ODg4 OCI+PGJyPg0KPHNwYW4gY2xhc3M9ImdtYWlsLWhvZW56YiI+LS08L3NwYW4+PGJyPg0KPHNwYW4g Y2xhc3M9ImdtYWlsLWhvZW56YiI+TWlyb3NsYXYgTGljaHZhcjwvc3Bhbj48L3NwYW4+PG86cD48 L286cD48L3A+DQo8L2Jsb2NrcXVvdGU+DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxv OnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Jv ZHk+DQo8L2h0bWw+DQo= --_000_8D2BF679AAC7C346848A489074F9F8BFF3535068sjsrvexchmbx2mi_-- From nobody Tue Oct 31 09:05:06 2017 Return-Path: X-Original-To: ntp@ietfa.amsl.com Delivered-To: ntp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 32A8313F85D for ; Tue, 31 Oct 2017 09:05:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=mscc365.onmicrosoft.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id iDgkMG-z4RB8 for ; Tue, 31 Oct 2017 09:05:02 -0700 (PDT) Received: from NAM01-BY2-obe.outbound.protection.outlook.com (mail-by2nam01on0055.outbound.protection.outlook.com [104.47.34.55]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 471C213F93D for ; Tue, 31 Oct 2017 09:02:42 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=mscc365.onmicrosoft.com; s=selector1-microsemi-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=duPsnCrgGSBSbjM70Npy6nQnfcptl6frKmXv/7HOVsc=; b=ewpN436PUo+OfyBkTz0M+XjRpbmKMoveO4so3WxXI42a5nrBXSKlL4g8GpLDGa5TB7fTCdui+QOIYCIHR7kwzxJttDc1JOowAt1pgg3/zj9bQfjyYNRC9zq5HYSZrPlMNFrrioMtiD3kLcHxXitPjMvfioudMUszNFa8GVK29Vo= Received: from BLUPR0201CA0017.namprd02.prod.outlook.com (10.163.116.27) by BLUPR0201MB1826.namprd02.prod.outlook.com (10.162.239.24) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P256) id 15.20.178.6; Tue, 31 Oct 2017 16:02:41 +0000 Received: from BL2FFO11FD017.protection.gbl (2a01:111:f400:7c09::105) by BLUPR0201CA0017.outlook.office365.com (2a01:111:e400:52e7::27) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384) id 15.20.178.6 via Frontend Transport; Tue, 31 Oct 2017 16:02:41 +0000 Authentication-Results: spf=pass (sender IP is 208.19.100.23) smtp.mailfrom=microsemi.com; redhat.com; dkim=none (message not signed) header.d=none;redhat.com; dmarc=bestguesspass action=none header.from=microsemi.com; Received-SPF: Pass (protection.outlook.com: domain of microsemi.com designates 208.19.100.23 as permitted sender) receiver=protection.outlook.com; client-ip=208.19.100.23; helo=AVMBX3.microsemi.net; Received: from AVMBX3.microsemi.net (208.19.100.23) by BL2FFO11FD017.mail.protection.outlook.com (10.173.161.35) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256) id 15.20.178.5 via Frontend Transport; Tue, 31 Oct 2017 16:02:40 +0000 Received: from AVMBX1.microsemi.net (10.100.34.31) by AVMBX3.microsemi.net (10.100.34.33) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.1261.35; Tue, 31 Oct 2017 09:02:39 -0700 Received: from AVMBX3.microsemi.net (10.100.34.33) by AVMBX1.microsemi.net (10.100.34.31) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.1261.35; Tue, 31 Oct 2017 09:02:38 -0700 Received: from SJSRVEXCHHTS1.microsemi.net (10.241.34.105) by avmbx3.microsemi.net (10.100.34.33) with Microsoft SMTP Server (version=TLS1_0, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA) id 15.1.1261.35 via Frontend Transport; Tue, 31 Oct 2017 09:02:38 -0700 Received: from SJSRVEXCHMBX2.microsemi.net ([fe80::6da0:6f9d:d5d1:3d5d]) by sjsrvexchhts1.microsemi.net ([::1]) with mapi id 14.03.0361.001; Tue, 31 Oct 2017 09:02:32 -0700 From: Greg Dowd To: Miroslav Lichvar , Tal Mizrahi CC: Aanchal Malhotra , "ntp@ietf.org" Thread-Topic: [Ntp] Drafts on interleaved modes and correction field Thread-Index: AQHTUibko2qH9HHhdE6MN2nq8y+qG6L+TuIAgAAhOYCAABK/AIAAEAqA//+LpxA= Date: Tue, 31 Oct 2017 16:02:32 +0000 Message-ID: <8D2BF679AAC7C346848A489074F9F8BFF35350A4@sjsrvexchmbx2.microsemi.net> References: <20171031090139.GD15597@localhost> <20171031135247.GB7648@localhost> <20171031155717.GC7648@localhost> In-Reply-To: <20171031155717.GC7648@localhost> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.241.128.48] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-EOPAttributedMessage: 0 X-MS-Office365-Filtering-HT: Tenant X-Forefront-Antispam-Report: CIP:208.19.100.23; IPV:NLI; CTRY:US; EFV:NLI; SFV:NSPM; SFS:(10009020)(6009001)(39860400002)(346002)(376002)(2980300002)(438002)(199003)(24454002)(13464003)(189002)(54906003)(97736004)(110136005)(2906002)(6246003)(68736007)(53416004)(106466001)(69596002)(478600001)(33656002)(189998001)(4326008)(7696004)(46406003)(966005)(5660300001)(2920100001)(2900100001)(356003)(7736002)(305945005)(50466002)(106002)(316002)(229853002)(39060400002)(86362001)(23726003)(8676002)(5250100002)(8746002)(53546010)(53936002)(97756001)(3846002)(6116002)(102836003)(8936002)(2950100002)(93886005)(9686003)(55846006)(72206003)(6306002)(81156014)(81166006)(47776003)(50986999)(76176999)(54356999); DIR:OUT; SFP:1101; SCL:1; SRVR:BLUPR0201MB1826; H:AVMBX3.microsemi.net; FPR:; SPF:Pass; PTR:InfoDomainNonexistent; A:1; MX:1; LANG:en; X-Microsoft-Exchange-Diagnostics: 1; BL2FFO11FD017; 1:xpl8amJAd2dbx+TQDf+5OIcs7fnKBeuvZOA47izwoANWEM94VgFDgJPYFcP+1EYuVeTRBXzseCkz/VSJD/k1frSDZ+3OdY1SY3hEaf1ot06qB4mal7Cd850xhIEIYRSy X-MS-PublicTrafficType: Email X-MS-Office365-Filtering-Correlation-Id: e8c85330-6ab2-4f0d-579d-08d52078d08f X-Microsoft-Antispam: UriScan:; BCL:0; PCL:0; RULEID:(22001)(8251501002)(4534020)(4602075)(2017052603199); SRVR:BLUPR0201MB1826; X-Microsoft-Exchange-Diagnostics: 1; BLUPR0201MB1826; 3:WW1AGBipsCUP3kS7nJ0DTUzcxm1CNN6xQUXr8caCK3D7TxHIezP3zS+Oj5Z/30RB8mRk4pRoEUUOuiaODwnm3WWr3K4trP7C4EPX4iRpGyi4yeL47eX9CdUiF7j4HQFN/6sR9JwNcl+GhRXl4ZzdbzK7Jr59avinx/iaRhemQtwon5tfWAlGPwl9Y5f7jHFsy1mBm7Wu5wsKcaQhX/56GUnX8DB2jKXvAR7tAetzmcTDyau0KXVOpV8h5RDyor5SFFCOloJiRUVlhoKx2BSodkOL9n7LVt9TR3iNvV2R/LjpXAg+v+NiE+eKXmwrqR84+I2XyFfUO1AqIWK5aG1xBUmlUP4p60NnrUi5Hq340MM=; 25:JcRRCTZDxFSwCbZQ5HiUrNLwWZ/4XmKIBooFd+b6kqvxBxY2U1crgvkYvDMkU1TsAjCmR/7Mw7T23bvhYfxZdAAvPDraVA+7BOAkLjcsJhI4zzXegY9g1IDrSTx5xVUbZu9AndZYg96d+fvopnCtrc37LhXS6aNNUxn+ZfvE8JlysSsySpdqky/03yCBOMakFvBP9Z+e74PJI9e45R7bV2lGVrSf0YYFUiGlQA2YaKJaD6sN22jJ4oiqdvTVDa1Hjx40xUSVLForqWqUHF7lY/hQeRUfIfB7MgjjY+GbMz4p/UbTW3NvwCC1ugLhpbSW0qc1B2O6om5cXtzT67xUXA== X-MS-TrafficTypeDiagnostic: BLUPR0201MB1826: X-Microsoft-Exchange-Diagnostics: 1; BLUPR0201MB1826; 31:5wuhm7BNmgEpF99TwrGFwVGErTFukmn/zRExxZSLFiv9RBapPiwJhnE2khgsSRa9Pk2GpmGONh/Mrv+Rcjmf9aobas1busIw7+s4310RgPnoDRw/THMAFWWSw1+sJKrJx4zTU7DcRkre+4W5PZ2cn0Mrh6uTGras4V7z0bLulahDPXktc0YeTu0K5qUehL/jhBBvAUFTa3hAjE4t9Ha9AoCUKkoPccmPJFEH80+vKZ0=; 20:6J6jaL3vSHU91AKhYzgnwo2YeaBY6citBV28sGHuYZgGM2J486qmseI+WeL6t3JX0agRj9gVOJEEC3zMXdze2honDrFL6VkJ0efn5ukmdQesFTEIAnZsUbBO0icuRUX/ZkxWNFzwu7TWfcgxrEqdP+IilzseuR0qdkYUyMh0ZaACYriwhexw7FbGH5Iy1ExTy6SPzqp2+HCD/VE/EXxDLRKZGZfg6a75nITgRX5yqwjA8L8n1yxNly36S79wd9w+/LTE5Kw1I4pS+1dFPHDSmOqHJ+C0txs1YqJFvV8eIKQhDP6Ha6PYE0iFgCOEFnP1EJ6b0E/7H+Y72GGj0clhZM65lWCI2ZZcBUY9sMlJZedoSvpUTaoHxjHBnYDXqVIJl8flADxetNQc6jJt5Th3KEqvU0E76Ysl2TIkFEukUXIYKNXWdfRYat7sBzEhwck1AWrwwj5/v/Goc+Zpg8JxgxneH4T36VJwTD8nYg+otPBN594swUcq3/CHlJjzdzHx X-Exchange-Antispam-Report-Test: UriScan:(238701278423138)(226873365582246); X-Microsoft-Antispam-PRVS: X-Exchange-Antispam-Report-CFA-Test: BCL:0; PCL:0; RULEID:(100000700101)(100105000095)(100000701101)(100105300095)(100000702101)(100105100095)(6040450)(2401047)(5005006)(8121501046)(10201501046)(93006095)(93004095)(3231020)(100000703101)(100105400095)(3002001)(6055026)(6041248)(20161123558100)(201703131423075)(201702281528075)(201703061421075)(201703061406153)(20161123555025)(20161123564025)(20161123562025)(20161123560025)(6072148)(201708071742011)(100000704101)(100105200095)(100000705101)(100105500095); SRVR:BLUPR0201MB1826; BCL:0; PCL:0; RULEID:(100000800101)(100110000095)(100000801101)(100110300095)(100000802101)(100110100095)(100000803101)(100110400095)(100000804101)(100110200095)(100000805101)(100110500095); SRVR:BLUPR0201MB1826; X-Microsoft-Exchange-Diagnostics: 1; BLUPR0201MB1826; 4:yqVt/x/UZGvp4Tn4UOn/ZG0hUGjeD64hCOWl6RvYJV/ehpZa+jrofZziVM7vJmOJk5Hb7igJy+JYpcvH+7bP+IvEgSq6oqEyzVewCYdHVc8HDhQs332Yw1s6BOJP7iekP3cz8F3PI0aCcea6+QlqsMTlpWL4Qhf0TjalxvcQ+frnNGwdQl9fjlO7wIT+f+3OZstvqLnll3cND9RFABjwXo+5DIrXt4242R5CsM/9WcIBB2ZQN2WziTU2HWBTwBbXV9AEyCVbKq/rbO9ENpdvQ6fzpeNHVt/h0VVVNlgDccwWxEaSuCHh6Cfm7iTM/CTiuWQoDf14qo60pnSoTLn55cbDENE+sn+5MNPW/5gf1lo= X-Forefront-PRVS: 04772EA191 X-Microsoft-Exchange-Diagnostics: =?us-ascii?Q?1; BLUPR0201MB1826; 23:RvoesEsiifNZAZLFgQLrvanFo/4aq6A7LXwy2vC?= =?us-ascii?Q?IF6NmtHbJgYNvMdFxvHDiBdVThauggEZUX2xZKALB5YclPiNiq6Ti7j0iIG2?= =?us-ascii?Q?aTvA/nU9WXZaQI/83v5d2yDz36xsnOHvzZGjVwQOlthQwDhjz6pg2bLY6U1Y?= =?us-ascii?Q?S0zs3x4wpssgSeuMdJG66wmcHqtLZ5SbazpZk1VciRLDXTXQOz1h87lEFXj0?= =?us-ascii?Q?jb/2SuqUQg6VINh1ptnFX9A4RpxZvI3sRolft6gFprNgeu9aetGIr6VBq2aS?= =?us-ascii?Q?razWrz7LY1Lly4F6mQHjzTsi2WakHHQI6Eun0RGGJAzBvvxnLeI4A8fDLuBF?= =?us-ascii?Q?E/5OV5Vf91nIJiN0qddfVDNg9J9O+QRzXKLE4PzXkYAQy0wsXYhTcLwFXiMc?= =?us-ascii?Q?e39Ijytqn1DvF7XchA9wiy/2T1y/s0+EGQq3aIjJc9RBBY/B9DfwmJs8PAS7?= =?us-ascii?Q?Ky1R/V7aqeZ4lnnqh6lBuZTNIIJLLo+ZS57E2gmxckdmj4NSXuIrx1NdfeAn?= =?us-ascii?Q?f3PO5Vi0FwKumJYuPG/8yD5qyJyJHt8P4IrXoE6qmrU7GnoSNf83rOtVaWEa?= =?us-ascii?Q?NAmKSW9GKQqqa7QPqmq+Q3syNnEoHswh1VNj0QIpTzOnQvlDUP7RU25WalcS?= =?us-ascii?Q?kB7tpjmvmguiai0vYh+xY1DK3rs0wnHJCUzxREQ89YtligL0orbmuMoH+YWL?= =?us-ascii?Q?FTmZlBkegG5wVkUVu95HlDOcrKAaH3r1Hj9lyIr1w4ZO/zmTrw0IhB4XgAYY?= =?us-ascii?Q?RVSKdSZovfeo/P+/N0zAULJJ7wYpO+4rQda79O9VYnbsNQo91nfWC70hCwPl?= =?us-ascii?Q?vSs7z/U8X9toPjeGk8/6PGq5fLvv7qQCYButS+WYVZogeiJQmxDVpR1XlDVn?= =?us-ascii?Q?hp+D8CjmPyAr/jTZWKe4U/u5j0qwnk9BXZW6+tBMxbdSO7hEE4Xwt9hx19Pe?= =?us-ascii?Q?Py/6EgkbHDp6WZzsnPWNcg6LDEduuBPbCij1/zryln5czMJMfgRKc/gvi+K2?= =?us-ascii?Q?81rP5s5g6tL1A9pg42HUoxliE6eBWKB4bw/R3K1aGm7bc4vZAA9uB7GSIl+X?= =?us-ascii?Q?uOmlk6Hu5wkoaD6rePhIqTdnhjtDhRI6InL7sPcs8Q8hHjzLlAr5VKb34whI?= =?us-ascii?Q?ulNLhC6le3bzAkz3NygwzmSwiK2kIcAFR8K8AYQgjc1BA65FrLHaNYGqvLks?= =?us-ascii?Q?wF1Kluau+NP+iLctgr+XbSDDPoGE5yqLSEtVY0xvbQIKqiqXjua8EkEcDcZN?= =?us-ascii?Q?k6CJrI3x4AN8tEzEpBZF9dE5jNXAOLBY8Nc3L3kbnT9yH434m80b3bYrX1ic?= =?us-ascii?Q?XYrWZB9bYAcbJAghYZSdCNUUUS7Otmx0ui3fSSTnY5Yq1LxNuCfmLas6obV/?= =?us-ascii?Q?vNAvuFmvHq+6YoDnZGHcC64B/9UNN09jvaWyYU1IE2QFyVhj5?= X-Microsoft-Exchange-Diagnostics: 1; BLUPR0201MB1826; 6:q4NnF1tgQaPyxEFvkCbTgxZlhUCU1iVxDZpEHE8Avg4TFwRQqjmbDxxN9R6a8Kf/QxHTWdtnIJrRf1KfboxkXMBzwersT2ERyoS3Ovc26JiGRWZ7uqKy26qOiw8l4rr5Dnisl+PlP7v+aZUup7mFIvulI6msW4VAvTcTEwZCQXRY22gKRv9Psl5ASbMsmqc7gEclumoqE423KDdF+nZkl0Nvfc4Qm7gwen5EaCDijXNQWDHFOQOxJgbtrg9oiXwdUO4t3gBo1cIT7zdm3L60QSRU2EN9okYvt5rjbB3Tr59xLNFpJO8GiNw9gFTZbKf4CrmgUqdIWGjr9dO6Xm3R3MGSSocC4SYMXEnO8sa7nWQ=; 5:u2QEFbzOTe/IYgvxvKrrRcvAU5lw/UE9Sdwrs+INjPMl7a81KzQJIL4Mf0yOuWDhpKe3sEo55tjQ35mA4i3to9tNDALaqOiN6na07cEFHZ2HBpjY75qSbyeKS07n/XiXk65K/TnJH19t/EfGw3qGs8iwNQWYSAD7OgX8XRLMm48=; 24:Dqov+yKQKWtU+ZYiP/nK2Q9BbilRNnqHX1vhQ7DO+uQG+vqhX290XoH0EOXx2YHGagwMXCr2/BqBa2FNAoqu5aleRN64O+LF+D7mxlhuNGM=; 7:TWrsE9DtVxiY0Fx629k/wuI1yTCNxg8i+YtDmpos4pv24TDyIrwsj3GyV3aMkMsMkv16fMb3KutGFVoY8ht0HlPmQR8x4I3w3sRweacOWbcTycVrDLatFKhLkaV1pAr7CXJ4f1LkasFzuusW39K550+bpaEfuMPvraOGyuVHDNhamM5JKu+vBAZru4DhuABI604bH1rdujBlw7LuDhfL6U9NvIHq0uaQWV5410mFH5dbVLvNkoOZBVURKMn8U3VP SpamDiagnosticOutput: 1:99 SpamDiagnosticMetadata: NSPM X-OriginatorOrg: microsemi.com X-MS-Exchange-CrossTenant-OriginalArrivalTime: 31 Oct 2017 16:02:40.8608 (UTC) X-MS-Exchange-CrossTenant-Network-Message-Id: e8c85330-6ab2-4f0d-579d-08d52078d08f X-MS-Exchange-CrossTenant-Id: f267a5c8-86d8-4cc9-af71-1fd2c67c8fad X-MS-Exchange-CrossTenant-OriginalAttributedTenantConnectingIp: TenantId=f267a5c8-86d8-4cc9-af71-1fd2c67c8fad; Ip=[208.19.100.23]; Helo=[AVMBX3.microsemi.net] X-MS-Exchange-CrossTenant-FromEntityHeader: HybridOnPrem X-MS-Exchange-Transport-CrossTenantHeadersStamped: BLUPR0201MB1826 Archived-At: Subject: Re: [Ntp] Drafts on interleaved modes and correction field X-BeenThere: ntp@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 31 Oct 2017 16:05:05 -0000 I think switches have to use store and forward on link speed changes. In t= heory maybe fast to slow doesn't have to but slow to fast of course does. = Tal may know more. =20 -----Original Message----- From: ntp [mailto:ntp-bounces@ietf.org] On Behalf Of Miroslav Lichvar Sent: Tuesday, October 31, 2017 8:57 AM To: Tal Mizrahi Cc: Aanchal Malhotra ; ntp@ietf.org Subject: Re: [Ntp] Drafts on interleaved modes and correction field EXTERNAL EMAIL On Tue, Oct 31, 2017 at 04:59:52PM +0200, Tal Mizrahi wrote: > >With NTP there is generally no HW support, so clients and servers=20 > >should use trailer RX timestamps and preamble TX timestamps to avoid=20 > >an asymmetric delay with different link speeds. The following=20 > >document explains the issue nicely. > > > >https://www.eecis.udel.edu/~mills/stamp.html > > > >Do you think it will be difficult to implement? If the link speed and=20 > >length of the packet is known, the timestamp can be transposed. > > The link speed is not necessarily known to the end points. I meant that the devices which are supposed to modify the correction field = know the link speed and can transpose preamble timestamps if necessary. The end points don't need to know the link speed on the path. Just the spee= d of their own link if they need to transpose their timestamps. > Furthermore, the > link speed may change several times along the path. In such case we want the correction to still be symmetric, right? > Maybe I am missing something, but it appears that when measuring=20 > last-bit-in-to-first-bit-out we are ignoring the packet reception=20 > time; it seems to make sense to include the packet reception time in=20 > the residence time. For PTP yes, but not for NTP. The reception time is included in the network= delay as measured by the client, which will be symmetric as long as no dev= ice on the path includes in the correction the transmission time or recepti= on time. > Moreover, we never know which nodes along the path use=20 > store-and-forward, and which nodes use cut-through. In cut-through=20 > forwarding the packet transmission may start before the last bit is=20 > received, so it certainly makes more sense to measure the first-bit-in-to= -first-bit-out. That's a good point. With cut-through switching the correction would be neg= ative and generally couldn't be determined in time to be put in the packet = as the length is unknown. Are there any switches that can cut-through from = a faster link to slower link? Maybe it would make sense to allow corrections from preamble RX timestamps = when the link speeds are equal. > >The reason for a separate transmit correction is to support the=20 > >interleaved modes. The receive correction might not be necessary. If=20 > >you have a better use for the 2 octets, I think it could be dropped=20 > >and included in the origin correction instead. > > So it looks like two correction fields would suffice: one for the=20 > forward direction, and one for the reverse direction. Right? I think it's three fields if we want both support the interleaved modes and= allow the client to check the delay correction in both directions. Where w= ould be the transmit correction included if there were only two fields? -- Miroslav Lichvar _______________________________________________ ntp mailing list ntp@ietf.org https://www.ietf.org/mailman/listinfo/ntp From nobody Tue Oct 31 23:48:55 2017 Return-Path: X-Original-To: ntp@ietfa.amsl.com Delivered-To: ntp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C8F0713F8CD for ; Tue, 31 Oct 2017 23:48:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.698 X-Spam-Level: X-Spam-Status: No, score=-2.698 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id L4R8AEXh5Dia for ; Tue, 31 Oct 2017 23:48:51 -0700 (PDT) Received: from mail-oi0-x233.google.com (mail-oi0-x233.google.com [IPv6:2607:f8b0:4003:c06::233]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9FBEA13FDFB for ; Tue, 31 Oct 2017 23:48:49 -0700 (PDT) Received: by mail-oi0-x233.google.com with SMTP id h6so2075240oia.10 for ; Tue, 31 Oct 2017 23:48:49 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=ti87NJSBhLgu0ZCtsWGr+LhJKupbqej1MTNMOk/wJZo=; b=KzYUUv0MFnpnOvzmVjtgQGvsCxuN0Q3aRp82JKX+8lAvDxwN/k+4bVLRmcdGYWxaoc vF2Cvb/B9fDUD6Hir0uObm3liD8+adir+UKO7FLm2UMDYR8Yyx7H4Hrl/5pM7srWohk8 2MgQ4WwdGk411fcjHpLs8AMvxNGgDCAvX7mk4S+PjffjyMOlIDedQlxOxyOYmONzqTug RCK+Kbd1QrVy8TjmuG/ac0z7+f4gTsmtyaIxCAU3I4xoVoL3r7Kp7G6pkJ8i6A+ev7aM LoSnA3WYEIy8BUpdhAx0zpTAWjM+qkCf01KVzZSjBW5ARBKGPtAAQuMZIN+BxkK2uuLI wgaQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=ti87NJSBhLgu0ZCtsWGr+LhJKupbqej1MTNMOk/wJZo=; b=DiI+vptHIr7deHynz+uwiBQ+msgS0pciMujCCGgo4Zqxa3PzkelQHXu3dJWqkDDz1L NgnNXHfmg6vsHDw8+PYDbQtoZz9vzcGpXRv61tAJ6fAMabQNXtQAiWN2ib7JcI07nEBC IwM83dmDD66DQ3SGT3BaCYbstOElUIU8vWbSL0ozH0H/srRc5Z0Lcqk/8H4bAB9PQL3o ZVXATYU0HtIpScmhWQg/5w6V93ZrnyJqB1s7msIPn8aKG5qUzAITsTTwB+aJLWO3pnL3 a8wj2x3xxXUSqtyTDzGr06Qme/W4F+Vcpo9nh1iwX/GYbyU3g22b4VUGEdte+DQkYwuO WGVQ== X-Gm-Message-State: AMCzsaUlLcuixJ6mxhCSrBjwWYTBQFWP5pmZkmU+NNAyxGI5uU/n+xWv QSbMm4VcVmf4XOPJb0hJd3XMA25axS5TZx+VONE= X-Google-Smtp-Source: ABhQp+SbPu4aygXSl1rB7l0OGu+4xh02E9/IlOTlSyJCdbkjdNzvtW2JimUDiGWN69bnxhzkk7Fu7BnBAuiwdmp20hk= X-Received: by 10.202.64.136 with SMTP id n130mr2348738oia.154.1509518929068; Tue, 31 Oct 2017 23:48:49 -0700 (PDT) MIME-Version: 1.0 Received: by 10.168.25.194 with HTTP; Tue, 31 Oct 2017 23:48:48 -0700 (PDT) In-Reply-To: <20171031155717.GC7648@localhost> References: <20171031090139.GD15597@localhost> <20171031135247.GB7648@localhost> <20171031155717.GC7648@localhost> From: Tal Mizrahi Date: Wed, 1 Nov 2017 08:48:48 +0200 Message-ID: To: Miroslav Lichvar Cc: ntp@ietf.org, Aanchal Malhotra Content-Type: multipart/alternative; boundary="001a113db4928c85d1055ce64371" Archived-At: Subject: Re: [Ntp] Drafts on interleaved modes and correction field X-BeenThere: ntp@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 01 Nov 2017 06:48:54 -0000 --001a113db4928c85d1055ce64371 Content-Type: text/plain; charset="UTF-8" Hi Miroslav, >> Moreover, we never know which nodes along the path use store-and-forward, >> and which nodes use cut-through. In cut-through forwarding the packet >> transmission may start before the last bit is received, so it certainly >> makes more sense to measure the first-bit-in-to-first-bit-out. > >That's a good point. With cut-through switching the correction would >be negative and generally couldn't be determined in time to be put in >the packet as the length is unknown. Are there any switches that can >cut-through from a faster link to slower link? To the best of my knowledge cut-through from a fast link to a slow link is not possible. Cut-through from a slow link to a fast link is certainly possible, and of course between ports that have the same link speed. In the two latter cases the transmission may start before the end of the reception. Regards, Tal. On Tue, Oct 31, 2017 at 5:57 PM, Miroslav Lichvar wrote: > On Tue, Oct 31, 2017 at 04:59:52PM +0200, Tal Mizrahi wrote: > > >With NTP there is generally no HW support, so clients and servers > > >should use trailer RX timestamps and preamble TX timestamps to avoid > > >an asymmetric delay with different link speeds. The following document > > >explains the issue nicely. > > > > > >https://www.eecis.udel.edu/~mills/stamp.html > > > > > >Do you think it will be difficult to implement? If the link speed and > > >length of the packet is known, the timestamp can be transposed. > > > > The link speed is not necessarily known to the end points. > > I meant that the devices which are supposed to modify the correction > field know the link speed and can transpose preamble timestamps if > necessary. > > The end points don't need to know the link speed on the path. Just the > speed of their own link if they need to transpose their timestamps. > > > Furthermore, the > > link speed may change several times along the path. > > In such case we want the correction to still be symmetric, right? > > > Maybe I am missing something, but it appears that when measuring > > last-bit-in-to-first-bit-out we are ignoring the packet reception time; > it > > seems to make sense to include the packet reception time in the residence > > time. > > For PTP yes, but not for NTP. The reception time is included in the > network delay as measured by the client, which will be symmetric as > long as no device on the path includes in the correction the > transmission time or reception time. > > > Moreover, we never know which nodes along the path use store-and-forward, > > and which nodes use cut-through. In cut-through forwarding the packet > > transmission may start before the last bit is received, so it certainly > > makes more sense to measure the first-bit-in-to-first-bit-out. > > That's a good point. With cut-through switching the correction would > be negative and generally couldn't be determined in time to be put in > the packet as the length is unknown. Are there any switches that can > cut-through from a faster link to slower link? > > Maybe it would make sense to allow corrections from preamble RX > timestamps when the link speeds are equal. > > > >The reason for a separate transmit correction is to support the > > >interleaved modes. The receive correction might not be necessary. If > > >you have a better use for the 2 octets, I think it could be dropped > > >and included in the origin correction instead. > > > > So it looks like two correction fields would suffice: one for the forward > > direction, and one for the reverse direction. Right? > > I think it's three fields if we want both support the interleaved > modes and allow the client to check the delay correction in both > directions. Where would be the transmit correction included if there > were only two fields? > > -- > Miroslav Lichvar > --001a113db4928c85d1055ce64371 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hi Miroslav,

>> Moreover, we= never know which nodes along the path use store-and-forward,
>= ;> and which nodes use cut-through. In cut-through forwarding the packet=
>> transmission may start before the last bit is received,= so it certainly
>> makes more sense to measure the first-b= it-in-to-first-bit-out.
>
>That's a good poin= t. With cut-through switching the correction would
>be negativ= e and generally couldn't be determined in time to be put in
&= gt;the packet as the length is unknown. Are there any switches that can
>cut-through from a faster link to slower link?
<= br>
To the best of my knowledge cut-through from a fast link to a= slow link is not possible.=C2=A0Cut-through from a slow link to a fast lin= k is certainly possible, and of course between ports that have the same lin= k speed.
In the two latter cases the transmission may start befor= e the end of the reception.

Regards,
Tal= .



<= div class=3D"gmail_quote">On Tue, Oct 31, 2017 at 5:57 PM, Miroslav Lichvar= <mlichvar@redhat.com> wrote:
On Tue, Oct 31, 2017 at 04:59:52PM +0200, Tal Mizrah= i wrote:
> >With NTP there is generally no HW support, so clients and servers<= br> > >should use trailer RX timestamps and preamble TX timestamps to avo= id
> >an asymmetric delay with different link speeds. The following docu= ment
> >explains the issue nicely.
> >
> >https://www.eecis.udel.edu/~mills/stamp.ht= ml
> >
> >Do you think it will be difficult to implement? If the link speed = and
> >length of the packet is known, the timestamp can be transposed. >
> The link speed is not necessarily known to the end points.

I meant that the devices which are supposed to modify the correction=
field know the link speed and can transpose preamble timestamps if
necessary.

The end points don't need to know the link speed on the path. Just the<= br> speed of their own link if they need to transpose their timestamps.

> Furthermore, the
> link speed may change several times along the path.

In such case we want the correction to still be symmetric, right?
> Maybe I am missing something, but it appears that when measuring
> last-bit-in-to-first-bit-out we are ignoring the packet reception time= ; it
> seems to make sense to include the packet reception time in the reside= nce
> time.

For PTP yes, but not for NTP. The reception time is included in the<= br> network delay as measured by the client, which will be symmetric as
long as no device on the path includes in the correction the
transmission time or reception time.

> Moreover, we never know which nodes along the path use store-and-forwa= rd,
> and which nodes use cut-through. In cut-through forwarding the packet<= br> > transmission may start before the last bit is received, so it certainl= y
> makes more sense to measure the first-bit-in-to-first-bit-out.

That's a good point. With cut-through switching the correction w= ould
be negative and generally couldn't be determined in time to be put in the packet as the length is unknown. Are there any switches that can
cut-through from a faster link to slower link?

Maybe it would make sense to allow corrections from preamble RX
timestamps when the link speeds are equal.

> >The reason for a separate transmit correction is to support the > >interleaved modes. The receive correction might not be necessary. = If
> >you have a better use for the 2 octets, I think it could be droppe= d
> >and included in the origin correction instead.
>
> So it looks like two correction fields would suffice: one for the forw= ard
> direction, and one for the reverse direction. Right?

I think it's three fields if we want both support the interleave= d
modes and allow the client to check the delay correction in both
directions. Where would be the transmit correction included if there
were only two fields?

--
Miroslav Lichvar

--001a113db4928c85d1055ce64371--